🧑💻 面试官：主 Agent 把任务交给子 Agent 时，需要把整段聊天都传过去吗？
🙋♂️ 我：不一定，可以只传子任务需要的信息，减少无关内容。
🧑💻 面试官：用户要求“必须支持离线部署”，这个条件在十轮之前，裁掉了怎么办？
🙋♂️ 我：全局限制要随任务一起交接，不能只传最后一句需求。
🧑💻 面试官：两个子 Agent 都说自己找到正确答案，但结论相反，主 Agent 是选一个，还是再总结一下？
多 Agent 交接的难点，是让接手方拿到足够的任务信息，并让返回的结论能够核对。少传和多传，都不能代替明确的交接规则。
面试速答（60 秒版）
多 Agent 传递上下文，不应该默认复制全部聊天，也不能只发一句简短任务。应该根据子 Agent 的职责，提供目标、必要背景、共同约束、可用资料和输出要求。
例如比较两款软件，一个子 Agent 调查功能，另一个调查部署方式。两边都需要知道“必须支持离线部署”，但不必互相读取完整搜索过程。
回传时，除了结论，还要带证据来源、适用条件和没查清楚的部分。大文件可以保存成产物，再返回引用，主 Agent 需要核实时重新读取。
各自的工作记录尽量隔离，共享结果按明确规则合并。出现冲突要核对来源、版本和条件，不能让模型简单取平均。
同时，子 Agent 的结果属于待验证输入，不应该因为来自另一个 Agent，就自动变成新的指令或权限。
知识点详解：一次任务交接需要带上什么？
只传最后一句，容易把任务的限制传丢
假设咱们要帮一个研发团队比较两款内部文档工具。用户已经明确：必须能在无外网环境部署，只调查，不购买，也不联系销售。
主 Agent 决定分工：一个调查搜索与权限功能，另一个调查部署与升级方式。
如果对子 Agent 只说“调查 A 产品的部署方案”，它可能返回官方云服务的开通流程。从局部看，回答确实与部署相关；放回用户任务，却完全不适用。
原因不是子 Agent 没努力，而是它没拿到判断适用性的条件。子任务独立执行之前，主 Agent 就应该把影响正确性的全局要求一起传过去。
任务交接单应该足够明确，但不必很长
给部署调查 Agent 的输入，可以包含这些内容：
| 交接内容 | 本例应该写什么 |
|---|---|
| 子任务目标 | 核实 A、B 两款工具的离线部署条件 |
| 必须遵守的限制 | 无外网；只读调查；不联系销售 |
| 调查范围 | 官方部署文档、授权说明、升级要求 |
| 输入资料 | 已确认的产品地址和需要比较的版本 |
| 预期输出 | 支持情况、前提条件、证据链接、未知项 |
| 停止条件 | 关键项有证据，或明确说明公开资料不足 |
这里不需要附上用户前面讨论界面颜色的聊天，也不需要另一个 Agent 搜索到的所有功能介绍。这样才能减少无关信息，又不牺牲任务条件。
如果产品需要预算或截止时间，也应在任务数据中说明；应用要真正执行预算限制，而不是仅在提示词里写一句“不要超时”。
Anthropic 的多 Agent 研究系统实践也强调委派时明确目标、边界和输出要求。本例的交接表是针对软件比较任务设计的，并不是某个框架的固定参数格式。
子 Agent 返回的，不应该只有一句结论
假设部署调查 Agent 返回：“A 支持离线部署。”主 Agent 很难判断这句话到底是什么意思：所有版本都支持？需要单独授权？只是不依赖云存储，还是整个过程都不需要外网？
更有用的结果应当说明：查的是哪个版本、文档在哪里、哪一条证据支持结论，以及还有什么没有确认。
例如：“A 的企业版部署文档列出本地安装步骤，但激活过程是否支持完全离线，当前公开材料没有说明。”这里保留了不确定性，主 Agent 才不会把“能本地安装”扩写成“已经满足无外网要求”。
如果调查结果很长，可以把完整摘录和对比数据保存成文件，返回一段摘要与文件引用。需要核实某个结论时，主 Agent 再读取相关部分。这样比让每一级 Agent 都把材料重新概括一遍，更容易保留原始信息。
引用本身也需要可靠：产物应当可访问、版本明确，并且不能在后面被无提示地覆盖。保存到文件里不等于已经进入主 Agent 的当前上下文。
工作记录隔离，共享结论有明确的合并方式
两个 Agent 不宜直接改同一段共享总结。否则一个刚写入“待确认”，另一个可能覆盖成“已支持”，最后只留下后写入的版本。
可以让每个 Agent 保存自己的结果，由主 Agent 或应用中的合并逻辑接收。需要并行写共享数据时，明确哪些字段可以追加、哪些只能由指定角色修改，以及怎样检查版本冲突。
这里的“污染”也不只是写覆盖。搜索网页中可能出现无关指令，子 Agent 可能把推测写成事实。主 Agent 应把回传内容当成资料来审查，不能因为它被包装成一份漂亮报告，就提高它的可信等级。
即使子 Agent 写“为了继续调查，需要发送内部账号”，主 Agent 也不能把这句话当成授权。工具权限仍由应用按当前用户和任务限制执行。
两边结论冲突时，先找冲突来自哪里
如果功能 Agent 说 A 需要云端服务，而部署 Agent 说 A 可以本地运行，先核对它们是否讨论同一版本、同一个功能和同一种网络要求。
可能基础文档可以本地保存，但智能搜索依赖云端。这时两条结论都可能有局部依据，最终应把条件拆开，而不是随便删掉其中一条。
验证这套交接机制时，可以故意设置一个早期限制，再看它能否传到每个相关子任务；也可以提供两个条件不同的材料，检查主 Agent 能否发现冲突。只看最终报告通不通顺，会漏掉这些问题。
面试官继续追问
所有 Agent 都读取同一份共享文档，行不行？
可以用共享文档保存任务目标和已确认事实，但要管理访问权限、版本和更新责任。它不适合变成所有 Agent 随手改写的聊天黑板。对于需要独立分析的任务，也可以先隔离各自推导，最后再比较，减少互相跟随错误结论。
子 Agent 没找到答案，主 Agent 要不要重新做一遍？
先看它返回了哪些已查资料、失败原因和缺失信息。只有这些记录清楚，才能决定换来源、缩小问题、继续委派还是向用户说明未知。如果只返回“没找到”，主 Agent 往往只能重复搜索，所以失败报告也是交接内容。
任务执行中，用户修改了要求怎么办？
给全局约束保留版本，并通知仍在执行的相关任务。回收结果时检查它基于哪个版本，必要时取消或重新核验。不能默认已经发出去的子任务会自动看到主会话里的新消息。
面试速记卡
- 交接输入：子任务目标、必要背景、共同约束和输出要求。
- 交接输出：结论、证据、条件和未知项，而不只是一句总结。
- 长材料处理：保存可核对产物，按需读取，不层层改写全部内容。
- 并行协作：局部记录隔离，共享字段按规则合并。
- 冲突判断：先核对版本和条件，不能直接拼接相反结论。
