53
17
AI Agent 交接模式实战：Agent 对 Agent 与 Agent 对人的状态机
2026-11-10 19:04:50
0点赞
0收藏
0评论
大多数多 Agent 工作流不是死在写代码、跑测试或提 Pull Request 上，而是死在「接缝」上：后端 Agent 做完接口，前端 Agent 从不知道它好了；一次重构落进 worktree 测试全绿，却因没人被告知去看而躺着。任务没坏，交接坏了。
本文梳理在实践中站得住的 AI Agent 交接（Handoff）模式：Agent 对 Agent 与 Agent 对人，拆解四状态门禁、工单 SH-312 端到端流转，以及三种交接失败的结构性修法。原文链接：https://hifox.com/blog/ai-agent-handoffs-agent-to-agent-and-agent-to-human-patterns
一、Agent 交接到底是什么？
只在一个终端跑 1 个编程 Agent 时，交接是隐形的。一旦跑 2 个 Agent，或 1 个 Agent 加 1 个审阅人，每个完成的步骤都必须落到下一个执行者找得到的地方。
一次干净的交接包含 3 部分，漏掉任何一部分工作就会丢：
产物：diff、PR、数据库迁移。
上下文：问的是什么、改了什么、还有什么不确定。
接收者：拥有下一步的那个具体 Agent 或人。
终端工作流带上了产物，却丢了另外两个：推理只活在某个 Agent 的滚屏缓冲里，「下一个是谁」取决于谁碰巧来查。用 HiFox 作为编程 Agent 之上的工作流层时，执行、阻塞、结果和讨论都回到任务时间线，下一个执行者只需读一份记录，而不是重建三份。
图 1：多终端滚屏丢失上下文与共享任务时间线带齐交接三要素对比图 1：终端滚屏丢推理与归属，共享任务带齐三要素
二、两种交接模式：自动继续 vs 停下等待
Agent 对 Agent 与 Agent 对人看起来相似，默认值却完全相反：
维度Agent 对 AgentAgent 对人触发子任务被标为就绪工作到达审阅门默认自动继续停下等待携带产物 + 上下文 + 验收标准diff + 改动摘要 + 已知限制缺失风险重复或冲突的工作未审代码被盲目合并
选型判断标准：
自动化 Agent 对 Agent 交接：下一步定义清楚、验收标准已写好，如「跑测试套件」「生成迁移」「更新 OpenAPI 规格」。
强制 Agent 对人交接：下一步需要 Agent 无法拥有的判断，如合并到
main、改公开契约、碰鉴权或计费，或验收最终结果。
全部自动流动会合并未审的工作；全部设门又会重建更慢的手工流水线。核心是让 Agent 在代价高的错误前停下，而非每件小事后都停。
图 2：Agent 对 Agent 自动接力与 Agent 对人停在审阅门双模式四维对照图 2：两类交接默认方向相反：自动接力与审阅门禁
三、四个状态：让交接成为门，而不是指望
运行模型归结为 4 个动词：谁分配、谁运行、谁审阅、谁验收。通过 4 个状态可将契约变成机械动作：
[待办] -> [进行中 (隔离 worktree)] -> [待审阅 (Agent边界)] -> [已完成 (人的边界)]
待办：已分配未开始，由人或小组队长放入。
进行中：Agent 已认领，正在隔离 worktree 里工作。
待审阅：Agent 的边界。跑过类型检查、测试和构建，附上改动摘要和已知限制后停下。
已完成：人的边界。有人验收结果，做出合并和发布决定。
核心规则只有一句：Agent 把任务移到待审阅，人把它移到已完成。 10 个 Agent 在跑时，不用扫 10 个终端，读看板就能看清什么在等你、什么在等另一个 Agent。
图 3：待办、进行中、待审阅、已完成四状态泳道与三种交接断裂结构性防线图 3：四状态泳道锁死交接边界，结构性托住三种断裂
四、完整例子：从工单 SH-312 到已合并的 PR
以任务 SH-312（「给公开 API 加限流」）为例：
task: SH-312 (给公开 API 加限流)
criteria: [按 API Key 限流, 返回 429 并带 Retry-After 头, 覆盖最忙的 3 个接口]
subtasks: 3 个可执行子任务 (后端 Agent 限流逻辑 + 测试 Agent 覆盖, 独立 worktree)
gate: { status: 待审阅, limitation: "Redis 计数器假设单区域；多区域需要后续处理。" }
第一次 Agent 对 Agent 交接：人用自然语言描述需求并分配。小组队长调研代码库和历史任务，写出范围与验收标准（按 API Key 限流、返回 429 并带
Retry-After头、覆盖最忙的 3 个接口），拆成 3 个可执行子任务。子任务自动流动：后端 Agent 认领限流逻辑，测试 Agent 认领覆盖。各自跑在隔离 worktree 里互不相撞，结果都回到
SH-312。后端做完不 ping 人，直接把子任务标为就绪，测试 Agent 接上真实实现而非桩代码。翻转到 Agent 对人的门：限流器建好、检查和测试全绿，Agent 把
SH-312移到「待审阅」，附上 diff、改动摘要和已知限制：「Redis 计数器假设单区域；多区域需要后续处理。」人在一处读到，检查 429 行为，移到「已完成」并触发合并。
五、交接在哪里断，怎么用结构托住？
交接以 3 种可预测的方式失败，每种都有结构性修法：
上下文蒸发：Agent 知道为什么这样选，审阅人不知道。修法：移到待审阅时就把改动摘要和已知限制带上。
归属模糊：两个 Agent 抢同一件工作或没人接。修法：每个任务和子任务都有处理人字段。
审阅从不发生：自主工作被直接合并。修法：设置 Agent 不能独自跨过的「待审阅」状态。
当 Agent、任务和仓库数量爬上来，手工纪律总是第一个丢的。如果你已经在跑多个编程 Agent，可以用 HiFox 管理它们的任务和结果：保留现有的 Claude Code 或 Codex，加上共享任务、处理人、隔离 worktree 和「待审阅 -> 已完成」的状态泳道。
图 4：HiFox 把任务指派给 Agent 并在同一任务时间线内归档执行与审阅记录图 4：把任务指派给 Agent，执行与审阅回到同一时间线
