大多数多 Agent 工作流不是死在难的部分。Agent 写出代码、跑完测试、打开 pull request。它们死在接缝上：工作离开一个 Agent、本该到达另一个地方的那一刻。后端 Agent 做完一个接口，前端 Agent 从不知道它好了。一次重构落进 worktree，绿着躺在那儿，因为没人被告知去看。任务没坏，交接坏了。
AI Agent 交接，是把一件工作连同上下文，从一个执行者交给下一个：Agent 给 Agent，或者 Agent 给人。你只在一个终端里跑一个编程 Agent 时，交接是隐形的，因为根本没有。一旦你跑两个 Agent，或者一个 Agent 加一个审阅人，每个完成的步骤都必须落到下一个执行者找得到的地方。落点就是全部。
这篇走一遍在实践中站得住的交接模式，用 HiFox 作为工作流：它在你编程 Agent 之上，让上下文、进度、阻塞、结果和人工审阅从提出到交付都可见。你已经有编程 Agent，本文解决的是它们之间空隙里发生的事。
短版本
交接是工作和它的上下文，从一个执行者移动到下一个的地方。Agent 对 Agent 的交接，把完成的子任务交给下一个 Agent；Agent 对人的交接，在审阅门前停下自主工作。两种都靠两套状态说清楚：任务可以仍是进行中，Agent 工作状态改为「等人审阅」；人验收之后，再分别决定合并、发布，以及是否改为已完成。状态名随空间配置，常见是待办、进行中、待验收、已完成。当交接变成共享任务上的状态变化，而不是终端里的一条消息，就不会有东西被悄悄丢掉。
Agent 交接到底是什么
一次交接有三部分，漏掉任何一部分，工作就会丢：产物（diff、PR、迁移）、上下文（问的是什么、改了什么、还有什么不确定）、接收者（拥有下一步的那个具体 Agent 或人）。
基于终端的工作流带上了产物，丢了另外两个。提交存在，但推理只活在某个 Agent 看过的滚屏缓冲里，而「下一个是谁」取决于谁碰巧来查。这就是为什么编排 Agent 的重点不在启动它们，而在路由它们产出什么。
干净的交接把三样一起移动：改动、做了什么和没做什么的摘要，以及一个明确的「轮到你了」信号。用 HiFox 的话说，执行、阻塞、结果和后续讨论都回到任务时间线，下一个执行者读一份记录，而不是重建三份。
两种交接模式
两种模式看起来相似，默认值却相反。Agent 对 Agent 的交接可以在验收标准写好后继续：队长把子任务指派给下一个 Agent，而不是默认自动认领。Agent 对人的交接默认应该停：Agent 做完自己那一块就等，因为要人来决定。
| Agent 对 Agent | Agent 对人 | |
|---|---|---|
| 触发 | 队长指派子任务 | 工作到达审阅门 |
| 默认 | 自动继续 | 停下等待 |
| 携带 | 产物 + 上下文 + 验收标准 | diff + 改动摘要 + 已知限制 |
| 缺失风险 | 重复或冲突的工作 | 未审代码被盲目合并 |
这里有一组让你保持诚实的判断。下一步定义清楚、验收标准已经写好时，自动化 Agent 对 Agent 的交接：「跑测试套件」「生成迁移」「更新 OpenAPI 规格」。下一步需要 Agent 无法拥有的判断时，强制 Agent 对人的交接：合并到 main、改公开契约、碰鉴权或计费，或者把结果当作完成来验收。
错误是把所有交接当成一样。全部自动流动，你会合并未审的工作；全部设门，你又重建了一条更慢、步骤更多的手工流水线。这跟知道审批门该放在哪有关：让 Agent 在代价高的错误前停下，而不是每件小事之后都停。
状态让交接成为门，而不是指望
运行模型归结为四个动词，以及各自归谁：谁分配、谁运行、谁审阅、谁验收。Agent 调研、执行、测试、汇报。人定方向、授权、验收结果。
状态让这份契约落在任务上。状态名随空间配置，下面是常见例子，不是固定四列：
- 待办：已分配，未开始。由人或小队队长放进来。
- 进行中：处理人已接手，可在隔离 worktree 里工作。要人看结果时，任务仍可停在进行中，Agent 工作状态改为等人审阅。
- 待验收：空间若配置了待验收或待验证，表示等人检查。Agent 跑完约定的检查，附上改动摘要和已知限制，然后停下。
- 已完成：人验收之后再决定要不要改到已完成。合并和发布另计，改成已完成，也不会合并代码。
可读的约定是：Agent 停在等人审阅，人来验收。人也不用手猜一个绿色的任务安不安全。状态就是交接。十个 Agent 在跑时，你不用扫十个终端，而是读看板，看清什么在等你、什么在等另一个 Agent、什么还在执行。这种可见性，就是追踪 Agent 完成了什么和指望提交日志以后讲故事之间的区别。
完整例子：从工单到已合并的 PR
拿一个真实形状的任务，SH-312：「给公开 API 加限流。」看交接，不看代码。
人用自然语言描述需求并分配。小队队长调研代码库和历史任务，写出范围和验收标准（按 API Key 限流、返回 429 并带 Retry-After 头、覆盖最忙的三个接口），把 SH-312 拆成三个可执行子任务，再指派给成员。这是第一次 Agent 对 Agent 交接：目标进去，可执行的子任务出来。
小队队长把子任务指派给成员：后端 Agent 做限流器逻辑，测试 Agent 做覆盖。因为各自跑在隔离 worktree 里，不会在同一批文件上相撞，每个结果都回到 SH-312，而不是某个私有会话。后端 Agent 做完后不去 ping 人，而是把结果写回子任务；队长再让测试 Agent 接上真实实现，而不是桩。这不是产品默认的自动认领。
然后交接类型翻转。限流器建好、类型检查干净、测试通过、构建绿了，工作到达 Agent 对人的门。Agent 把 diff、改动摘要和一条已知限制写回 SH-312：「Redis 计数器假设单区域；多区域需要后续处理。」工作状态改为等人审阅，任务可以仍是进行中。人在一个地方读到，检查 429 行为；验收通过后，再分别决定合并，以及是否把任务改为已完成。工单到已合并的 PR，每个接缝都有谁做了什么的记录。这就是同一条从需求到代码的可追踪路径，端到端走通。
交接在哪里断，怎么托住
交接以三种可预测的方式失败，每一种都有结构性修法，而不是「努力记住」的修法。
上下文蒸发。Agent 知道自己为什么这样选，审阅人不知道。修法：交接在 Agent 进入等人审阅时，就把改动摘要和已知限制写回任务，而不是事后补。归属模糊。两个 Agent 抢同一件工作，或者没人接。修法：每个任务和子任务都有处理人，「轮到你了」是一个字段，不是感觉。审阅从不发生。自主工作被合并，因为没人被告知要拦。修法：按团队约定，验收前把任务留在进行中，Agent 工作状态改为等人审阅；人验收之后，再分别决定合并、发布，以及是否改为已完成。
这些你都可以用 worktree、命名规范和纪律手工搭。它能撑到 Agent、任务和仓库数量爬上来，而纪律总是第一个丢的。如果你已经在跑多个 Agent，HiFox 给你一个地方管理它们的任务和结果：共享任务、每个任务的处理人、隔离 worktree，以及一条能看见 Agent 进入等人审阅、由人决定是否改为已完成的记录。保留你已经在用的编程 Agent，加上让交接可见的那一层。下载 HiFox，等你 Agent 之间的接缝开始比工作本身更贵的时候。
常见问题
什么是 AI Agent 交接？是把一个任务连同上下文和「现在轮到别人」的信号，从一个执行者交给下一个。两种形式是 Agent 对 Agent（完成的子任务流向下一个 Agent）和 Agent 对人（自主工作停在审阅门）。
Agent 对 Agent 和 Agent 对人的交接有什么区别？下一步的验收标准已经定义好时，Agent 对 Agent 的交接应该自动继续。Agent 对人的交接应该停下等待，因为人要行使判断：合并、改公开契约，或者验收结果。
Agent 应该把自己的工作标成已完成吗？默认不应该。让 Agent 跑完测试、附上摘要后进入工作状态「等人审阅」，任务可以仍是进行中。人验收之后，再分别决定合并、发布，以及是否把任务改为已完成。完成验证不等于合并。见 人在回路的编程 Agent。
状态怎么防止工作被丢下？当交接是共享任务上的状态变化，而不是终端里的消息，下一个执行者能准确看到什么在等他。没有任何东西取决于某人在正确时刻盯着正确的滚屏。Agent 收件箱会把需要你的条目浮上来。
我需要工具，还是可以手工做？你可以用 worktree 和共享看板跑起来。当你跨多个仓库协调多个 Agent、手工追踪成为瓶颈时，专门的一层才开始回本。可以对照助手和队友的心智模型来决定。
HiFox
