Agent 该什么时候交回给人，交接的时候要一起递过去什么
内容截至 2026-07。本篇讲的是交接件的字段设计与时机判断，不绑定具体框架；各家 Agent 框架对”挂起 / 恢复 / 人工审批”的支持程度差别很大，且在快速变化，落地前请以你所用框架的官方最新说明为准。
大多数团队在”人接不住 Agent 的活”这件事上归错了因：他们以为是介入点选早了或选晚了，于是反复调阈值、加确认框。真正卡住人的，是交接那一刻递过去的信息不足以支撑一个决定——人看到的是一句”需要你确认是否继续”，而做判断需要的是它改了什么、为什么这么改、不批会怎样、批了之后它下一步干什么。 信息缺了，人就只能反问；反问一轮，Agent 的上下文又滚了一截，回答质量继续下滑。你调阈值调不出来的东西，本质上是一份交接件的字段设计。
这篇和站内另外两篇的分工说清楚：Agent 里的人工介入怎么设计 讲的是介入机制本身——动作分级、中断点落在哪、状态怎么持久化；Agent 说任务已完成实际没改成 讲的是产物验收，怎么绕开 Agent 的自述去核实。本篇只管两件事之间那条缝：在决定交回给人的那一刻，把哪些信息装进同一个包裹递过去，让接手的人一眼能判、不用回问。机制是管子，验收是出口，交接件是管子里流的东西。
一、先分因：人接不住有四种，不要一起治
看到”人卡住了、任务停在半路”的现象，先别动介入策略。按下面的顺序判别，四种成因的处置动作完全不同。
第一种，该交没交。 Agent 在一个它没有判断依据的岔路口自己拍板了，人是在事后才发现方向不对。典型信号是回滚频率高，但每次回滚的都不是代码质量问题，而是”这不是我们要的方案”。
第二种，交早了。 每一步小改动都弹给人，人被打断得没脾气，最后养成无脑批的习惯。这时介入形同虚设，比不介入更危险——因为你以为有人把关。
第三种，时机对但交接件残缺。 这是最常见也最难看出来的一种。介入点选得没问题，人也认真看了，但递过来的只有一句请求和一段模型自述，人必须自己去翻 diff、翻日志、猜它的意图。判断成本高到一定程度，人的行为会退化成两个极端：全批，或者全打回。
第四种，人根本没被通知到。 后台跑的任务停在等待状态，通知落在一个没人看的频道里，或者干脆只在终端输出里滚了过去。任务不是被拒绝，是被遗忘。
| 现象 | 大概率成因 | 怎么验证 | 处置动作 |
|---|---|---|---|
| 事后才发现方向错，回滚的是方案不是代码 | 该交没交，高不可逆动作没设卡点 | 把最近 10 次回滚列出来，标注”回滚原因是方案分歧还是实现缺陷” | 按不可逆性重新划动作分级，方案岔路口强制交回 |
| 人几分钟被打断一次，批准记录清一色秒批 | 交早了，粒度过细 | 统计相邻两次介入请求的间隔和人的响应耗时，响应耗时普遍在几秒内即为无脑批 | 合并同类动作，改成阶段性交回而非逐步交回 |
| 人看到请求后先反问一句”你改了哪些文件” | 交接件残缺 | 抽查几条介入请求，看是否包含变更清单、依据、影响面、后续计划 | 补齐交接件字段，模板化 |
| 任务长时间停在等待，无人响应也无人报警 | 通知链路断，或没有超时兜底 | 主动查一次待处理队列，看是否有超过预期时长仍在等待的条目 | 通知加确认回执，等待状态设超时后自动降级或告警 |
| 人批准后 Agent 重头跑一遍或问了重复问题 | 状态没持久化，属于介入机制问题 | 对比批准前后的动作日志是否重复 | 走 人工介入设计 那条线，不在本篇范围 |
| 人批准后产物和描述对不上 | 验收缺失，不是交接件问题 | 直接查文件系统和版本控制状态 | 走产物校验那条线 |
判别的关键是别把最后两行和前四行混在一起治。状态丢失和产物不符是另外两类问题，改交接件模板对它们没有任何帮助。
二、交回给人的时机：按不可逆性分，不按复杂度分
很多人用”任务复杂度”当交回标准，这个标准不好用——复杂但可逆的操作，让 Agent 自己跑完再看结果，效率高得多；简单但不可逆的操作，再简单也得交。
我的判断顺序是三问：
第一问：这个动作能不能一键撤销。 能撤销的（在工作区改文件、跑测试、生成草稿），让它自己干完。不能撤销或撤销代价高的（推远端、动数据库结构、发通知给外部、花钱的调用），交。这条线画在”撤销代价”上，不是画在”危险程度”这种模糊感受上。
第二问：这个决定依赖的信息 Agent 有没有。 涉及业务优先级、团队约定、历史包袱、和别的团队的接口约定——这些信息大概率不在它的上下文里。它做出来的选择不是推理错误，是无中生有。这类岔路口必须交，而且要在它动手之前交，不是做完了再问。
第三问：错了之后谁来收拾。 如果错了只是浪费一次运行，不交；如果错了要人花半天回滚加沟通，交。
三问之外还有一条经验：交回的时机要卡在”决定点”，不是”完成点”。 做完了再问”这样行吗”，人只能选接受或者推翻重来，沉没成本会逼着人接受。在动手之前给两三个方案让人选，人的判断成本反而更低。这一点和 Agent 上下文管理 是配套的——决定点前的上下文最干净，跑完一大段之后上下文已经被中间产物挤满，那时候交回，Agent 自己都说不清早期的选择理由了。
三、交接件里放什么：六项，缺一项人就得反问
交接件的设计目标只有一个：让接手的人不用打开第二个窗口就能做出决定。 按这个目标倒推，需要下面六项。
一、当前状态一句话。 它现在停在哪、已经做完了什么、正在等什么。不要写模型的心路历程，写状态。
二、变更清单，要能核对的那种。 不是”我修改了几个文件”，而是具体路径加变更性质（新增/修改/删除），最好带上可以直接跑的核对命令：
git status --short
git diff --stat
如果 Agent 工作在独立分支或工作区里，把分支名一并给出来，人才能自己去看。这一步的价值在于它把”相信自述”变成了”相信版本控制”，成本低得多。
三、这个决定的选项和推荐。 不要只抛问题。给二到三个可选项，每个选项写清楚代价，标出 Agent 推荐哪个以及理由。原因很实在：做选择题时人只需要比较有限的几个已知代价，做问答题时人得先自己把方案空间想出来，后者要慢得多，也更容易因为想不动而直接放行。
四、依据与不确定点分开写。 有依据的地方写依据来自哪里（哪个文件、哪段配置、哪条报错）；没依据靠推测的地方明确标”这是推测”。这一条极其重要——人最怕的是把 Agent 的推测当成它查证过的结论。让它自己把这条线画出来，比人事后去分辨便宜。
五、影响面与回滚方式。 批准之后会碰到哪些东西、影响哪些人、如果错了怎么退回去。回滚方式要写成可执行的，比如说明该回退哪个提交、该恢复哪份备份文件，而不是一句”可以回滚”。
六、不批准的后果。 这一项经常被漏掉，但它决定了人的判断基准。是任务直接终止，还是走备选方案继续，还是它会一直等着。人只有知道”不批会怎样”，才能判断”批”的相对代价。
六项里如果只能保三项，保变更清单、选项与推荐、影响面与回滚。这三项撑起了决定所需的最小信息。
至于权限层面的边界——哪些动作 Agent 压根不该有能力执行，那是另一个话题，见 Agent 权限给太大。交接件解决的是”该问的问清楚”，权限解决的是”不该做的做不了”，两者不能互相替代。
四、什么情况下别再折腾了
调交接流程这件事有明显的边际递减，下面三条是我的止损线。
止损点：同一个任务交回三次以上还没推进。 这通常说明任务本身的边界没定义清楚，不是交接件的问题。第三次交回的时候就该停下来，把任务拆小或者重新描述目标，而不是继续优化那份交接模板。反复交回本身是个信号：Agent 每次都撞在同一堵墙上，而那堵墙是需求模糊。
回滚点：人已经开始不看内容直接批。 一旦出现这个行为，介入机制就已经失效了，继续加字段只会让人更不想看。这时候正确的动作是回滚——把介入点数量砍掉一大半，只保留不可逆动作那一档，让每一次弹出来的请求都值得读。宁可少设卡点也别让卡点贬值。
换条路的判断依据：交接的沟通成本超过了人自己干的成本。 具体点说，如果人读交接件加做判断的时间，已经接近人自己动手完成这段工作的时间，那这段工作就不该交给 Agent 做。它适合做的是”人来判断成本低、执行成本高”的部分。判断成本高、执行成本低的部分，直接人做。这条线每个团队不一样，但它确实存在，别硬撑。
还有一种情况要及时收手：任务已经跑歪但 Agent 在自我修补的循环里出不来。这种时候交接件写得再全也没用，因为它交回来的信息本身就是错的。识别方法和处置见 AI 修不好的思维循环，处置原则是丢弃当前会话、带着已知结论重开，而不是在原会话里继续拉扯。
五、避坑清单
坑一：把交接件写成模型的思考过程。 为什么会踩——最省事的做法就是让 Agent 把它的推理直接吐出来，看起来信息量很大。但推理过程是给它自己用的，人需要的是结论和依据。怎么避：模板里固定字段，字段之外的自由发挥全部折叠或砍掉，宁可短。
坑二：只给摘要不给可核对的入口。 为什么会踩——摘要读起来舒服，人容易接受。但摘要是 Agent 生成的文本，和实际改动之间没有强制绑定。怎么避：每份交接件必须带一个”人可以自己去看”的入口，分支名、diff 命令、日志路径任选，让人两秒钟能验证。
坑三：把不确定当确定写。 为什么会踩——模型的输出天然是笃定语气，它不会主动标注”这一句我是猜的”。怎么避：在交接件里单独留”不确定点”字段并要求必填，允许填”无”，但不允许不写这个字段。字段存在本身就会拉出一部分被掩盖的推测。
坑四：通知发出去就算交接完成。 为什么会踩——发送成功和有人看见是两回事，尤其是后台长跑任务，通知发到某个群里就沉底了。怎么避：等待状态设超时，超时后升级通知或者自动降级到安全动作（比如停在原地不再往下跑，而不是自己选一个继续）。默认行为一定要选保守那个。
坑五：交接的信息量随会话变长而衰减。 为什么会踩——跑到后期，上下文里堆满了中间产物，Agent 复述早期的决策理由时会失真，甚至张冠李戴。怎么避：关键决策在发生的当时就落成文件，交接的时候引用文件而不是引用记忆。这也是长任务要中途落盘的原因之一。
坑六：只给”批准/拒绝”两个按钮。 为什么会踩——二元选择实现最简单。但现实中人的第三种反应最常见：方向对，但某个细节要改。没有这个通道，人只能拒绝然后重新描述一遍需求，前面的工作全废。怎么避：留一个”带修改意见继续”的口子，把人的意见作为新输入接回执行流程。
坑七：交回给人之后，Agent 还在后台继续跑。 为什么会踩——异步执行的实现里，如果没有真正挂起，只是发了个通知，它会接着做下去。等人批准的时候，它早就跑到别的地方去了。怎么避：交回必须是真挂起，挂起前的状态要能落盘。这属于介入机制的实现细节，前面那篇讲得更细。
坑八：多个 Agent 并发时交接件互相污染。 为什么会踩——几条线同时跑，交接请求混在一个队列里，人分不清哪个请求属于哪条线。怎么避：每份交接件带任务标识和工作区标识，队列按任务分组展示。并发场景下的更多冲突问题见 多会话并发冲突。
六、收尾
交接这件事的本质，是把 Agent 手里的信息压缩成人能在一分钟内消化的形状。它跑了几十步，人只有一分钟；这中间的落差不是靠人多花时间去补，而是靠交接件的结构去填。设计得好，人的判断质量会明显高于自己从头读一遍代码——因为它替你做了信息整理，而把判断权留给了你。
上线前拿这份清单自查一遍：
- 交回的时机是按撤销代价划的，还是按任务复杂度拍的？
- 交接件里有没有一个人可以自己去核对的入口（分支、diff、日志）？
- 有没有”不确定点”字段，且强制填写？
- 有没有写清楚不批准会发生什么？
- 是不是只有批准和拒绝两个选项，缺不缺”带意见继续”？
- 等待状态有没有超时兜底，超时后的默认行为是不是保守的？
- 最近十次介入里，人的平均响应耗时是不是短得像没看？
最后一条是最好用的体检指标。人认真读了，交接件就是有用的；人秒批，说明你设的卡点已经贬值，该砍了。