可靠的 Coding Agent 团队交接，传递的是可以检查的项目状态，而不只是一段聊天摘要。接手者需要当前文件、预期结果、Preview 或可复现命令、验证证据、已知风险，以及一个清楚的下一步。
这样，团队成员无需拿到别人的上游账号或密码，也能 Review 或继续工作。即使换了人或 Agent harness，证据仍然跟项目放在一起，交接不会依赖某个人的记忆。
好交接传递的是状态，不是隐藏上下文
聊天摘要可以提供帮助，却不足以证明实际发生了什么。它可能漏掉失败测试，描述一份从未保存的文件，也可能在实现方向已经变化后继续保留最早的计划。
权威的交接内容应该由接手者可以检查的材料组成：
- 需求与验收条件；
- 当前已经保存的项目文件；
- 准确的 Diff 或改动文件清单；
- 视觉产出对应的 Preview、截图或复现步骤；
- 实际运行过的命令和测试，以及真实结果；
- 已作出的决定、关键假设、未解决风险和下一个边界明确的任务。
Agent.Space 会把 Workspace 文件、Session 与受支持的 Preview 放在共享项目上下文中，但不会声称新 Session 可以读取另一个 Agent 的私有推理。因此，重要背景必须明确写入文件、测试输出或简短交接记录，而不是留在隐含上下文里。
更换负责人之前，先准备交接
不要等到原操作者已经离开，或 Agent Session 难以重建时才补交接。趁当前状态仍然清楚，更新交接材料。
可以按下面的顺序操作：
1. 重新说明目标
用当前有效的表述写清预期结果和验收检查。如果需求发生过变化，应记录已经接受的新决定，不要让接手者从旧 Prompt 中猜。
2. 标出当前唯一事实来源
写明相关文件；使用版本控制时，再标出对应分支或 Revision；仍然约束工作的外部需求也要注明。接手者不应该在三份相似草稿中猜哪一份才是最新版本。
3. 留下可 Review 的结果
代码任务应提供 Diff 与验证输出；网页任务应提供源码和当前 Preview；研究或内容任务应提供最终文件及支撑关键事实的来源。
4. 区分已完成工作与未解决风险
明确写出什么通过、什么失败、什么没运行，以及什么仍然不确定。“已完成”不能用来掩盖跳过的检查。
5. 给接手者一个明确的第一步
用一个窄任务结束交接，例如“根据这三个案例 Review 定价计算”或“修复这个 Preview 中显示的移动端溢出”。一长串没有顺序的待办不算交接。
如果多个 Agent Session 同时工作，应先使用多 Agent 编程工作流划分不重叠的所有权，再分别准备交接。
有意识地使用 Owner、Editor 与 Viewer
截至 2026 年 8 月 28 日核验，Agent.Space Workspace 使用三种成员角色。应该为接手者选择能完成工作所需的最小角色。
只需要检查当前状态的 Reviewer 可能适合 Viewer；需要继续实现的团队成员则需要 Editor 或 Owner 能力。不要因为对方未来“也许会需要”，就提前授予编辑权限。
创建邀请前，可以先阅读 Agent.Space Workspace 角色指南，确认不同成员职责如何划分。
示例：产品负责人 → Codex → Reviewer → Claude Code
假设一个团队正在更新产品 Onboarding 页面。
- **产品负责人定义目标。**他们把已确认文案、验收条件和参考素材加入 Workspace。初始任务保持窄范围：更新 Onboarding 页面，并检查响应式 Preview。
- **Codex 实现改动。**Session 修改相关文件，运行当前可用检查，并留下简短记录：改了哪些文件、验证结果如何，以及一项仍未解决的移动端问题。
- **人类 Reviewer 检查候选结果。**他们对照已确认文案与验收条件查看 Preview。只需要检查时，Viewer 可能已经足够；需要编辑时，再使用合适角色。
- **Claude Code 获得一项新的窄任务。**由于更换了 harness，团队在同一 Workspace 中启动新 Session。它可以查看当前已保存文件和明确的 Review 发现，但不会继承 Codex 的私有推理。
- **由人接受最终状态。**团队重新运行相关检查、审查当前 Diff，再决定发布、导出或继续修改。
真正让工作连续起来的是已保存材料与共享项目边界。即使参与者发生变化，私人聊天也不会成为项目唯一副本。
如果团队还在判断审阅与接力应该围绕 Codex 还是 GitHub 的 Coding 产品展开，可以先阅读 Codex vs GitHub Copilot 对比。先完成产品路径选择，再把同一套明确交接合同应用到最终工作流。
Preview、发布与导出是三种不同的交接证据
应根据接手者要做的决定选择证据。
- 短期链接或 Inspector Preview 适合在工作进行中检查渲染结果。
- 只有项目已经适合提供稳定版本时，才应使用正式发布。
- 导出普通文件，适合让团队在其他环境继续，或按现有格式保存结果。
这些动作都不会自动证明工作正确。Preview 不能替代验证，已发布 URL 不能替代 Review，导出也不会保存 Agent 的隐藏上下文。Preview、发布与导出指南会进一步说明如何选择合适的审查材料。
不共享上游账号或密码也能继续
团队协作应该建立在 Workspace 成员关系上，而不是交换 Credential。Agent.Space 说明平台会管理服务访问与资源匹配，因此团队成员继续受支持的 Agent 工作时，不需要互相传递上游账号、登录凭据或密码。
这条产品边界不代表其他 Credential 可以安全放进项目文件。项目 Secret 仍然需要单独管理：
- 不要把 API Key 或密码放进 Prompt、已提交文件、截图和交接记录；
- 通过任务获批的环境变量或 Secret 管理路径提供凭据；
- 只给接手者完成任务所需的成员权限与外部系统访问；
- 如果无法确定 Credential 是否暴露，及时轮换或撤销；
- 检查下一步能够访问哪个 Provider、仓库、部署账号或数据源。
“不共享上游登录”只解决了一类协作风险，不能替代项目其他部分的最小权限控制。
使用一份简短交接清单
接手者开始工作前，确认交接材料能回答下面的问题。
目标与范围
- 预期结果是什么？
- 哪些内容明确不在范围内？
- 最终由谁接受结果？
当前状态
- 哪些文件是当前版本？
- 哪个 Session 或任务产出了候选结果？
- 是否能看到版本控制 Revision 或 Diff？
证据
- 运行了哪些测试或命令？
- 当前 Preview 显示什么？
- 哪些检查失败、被跳过或暂时无法运行？
边界
- 接手者可以修改什么？
- 他需要哪种角色？
- 哪些 Secret、账号或生产操作仍然不能碰？
下一步
- 第一项边界明确的任务是什么？
- 出现什么情况时，接手者应该停止并请求决定？
清单应该短到容易维护。直接链接真实文件与证据，不要把大量可能过期的上下文复制到第二份文档。
常见交接失败
需要警惕这些情况：
- **只有摘要，没有状态：**说明看似完整，却缺少当前文件或 Diff。
- **只有截图，没有源码：**接手者能看到结果，却无法复现或修改。
- **声称通过，没有输出：**没人知道哪条命令、哪个版本或哪份项目状态通过了检查。
- **有访问权限，没有所有权：**多位 Editor 都能改同一批文件，却没人负责下一项决定。
- **权限过大：**只读 Reviewer 获得编辑权限或不必要的外部 Credential。
- **假设上下文自动继承：**新 Agent 被期待了解上一 Session 的决定，却没有任何明确材料。
- **没有停止条件：**接手者不断扩大任务，而不是在产品、安全或架构决定前停下。
修复这些问题通常需要更好的证据和更小的下一步，而不是更长的聊天记录。
从一次真实的团队交接开始
选择一个能让他人从项目本身看懂的边界任务。保存需求、当前文件、Preview 或复现方式、验证输出、决定、风险和下一步。给接手者完成工作所需的最小角色，并确认对方无需拿到别人的密码或私有上下文就能继续。
当团队需要把受支持的 Agent Session、已保存文件、Preview 与成员角色放进一个共同位置时，可以打开 Agent.Space Workspace。第一次交接成功的标志，是下一位成员理解当前状态与证据，而不是继续要求原操作者靠记忆重建整个项目。