上一期我们聊了 Agent Registry 是什么。通过 Agent Registry，协调 Agent 可以找到具有特定能力的专业 Agent，再把合适的任务交给它。

不过，找到对的 Agent 只是第一步。真到了交接任务的时候，协调方是需要说明任务目标、执行范围、必要材料和交付要求的。如果这些信息没有传递清楚，接手任务的 Agent 即使具备完成任务的能力，也会偏离原先的目标。

这就是本文要讨论的话题：Agent 之间如何传递上下文？

懒人图解版

任务交接需要哪些信息

假设产研团队现在准备发布新版本，需要根据功能变更记录整理出一份产品更新说明。

针对这个任务，协调 Agent 将工作分成两个子任务：资料 Agent 负责根据版本的发布记录和产品文档，整理上线的功能；写作 Agent 则根据整理结果，撰写面向用户的更新说明。

资料 Agent 完成工作后，协调 Agent 将材料交给写作 Agent。但写作 Agent 发现，任务只要求“根据功能变更记录撰写更新说明”，没有交代文稿是面向普通用户还是开发者，也没有明确哪些功能允许对外发布。

这些没说清楚的细节会直接影响最后呈现的内容。面向开发者的说明可能需要接口变化和兼容性信息；面向普通用户的说明则更关注功能的变化和使用体验。如果这次发布的部分功能还在测试阶段，是不能直接写成已经正式上线的。

因此，一次完整的任务交接，通常需要包含四类信息：

• 任务目标：接手的 Agent 要完成什么工作，解决什么问题。
• 范围与约束：需要处理哪些内容，哪些事项不能执行。
• 参考材料：完成任务需要哪些文件、事实和已有结论。
• 交付要求：最终需要返回什么结果，怎样判断任务完成。

协调 Agent 可以把这些内容整理成结构化的任务说明：

任务：撰写产品 v2.4 更新说明

目标：向普通用户介绍本次版本更新

范围与约束：
- 只介绍已经正式发布的功能
- 不包含内部计划和测试功能

参考材料：
- 已确认的版本变更记录
- 功能说明及对应来源

交付要求：
- 输出一份用户可读的更新说明
- 重要功能描述保留依据
- 无法确认的信息单独标注

这份任务说明可以看作是 Agent 之间的输入契约。它让接收方知道应该完成什么，也为协调方后续验证结果提供了依据。

上下文为什么要筛选

协调 Agent 会掌握完整的任务历史，包括用户讨论、功能变更、内部评审和其他 Agent 的执行记录。但不同 Agent 承担的工作不同，需要“看到”的上下文也不一样。

例如，资料 Agent 需要检查功能是否正式上线，写作 Agent 则主要需要已经确认的功能信息、目标受众和发布要求。至于协调方之前是怎样分配任务、内部讨论过哪些方案，对写作 Agent 来说并没有直接帮助，不用放进上下文。

如果把全部的对话历史和文件直接交给接收方，会增加它的整理工作。接收 Agent 要重新寻找关键条件，还可能把已经被否定的旧方案当成最新决定。同时，冗余内容会占用上下文窗口，增加模型处理信息的成本。

因此，协调方需要根据子任务重新组织上下文，通常可以分成三个层次。

必须直接提供的信息。 包括任务目标、当前有效的约束、已确认结论和交付条件。这些内容决定执行方向，应该明确写入任务说明。

需要时可以查阅的材料。 包括原始文档、测试记录和其他 Agent 的工作结果。对于较长的文件，可以提供带出处的摘录，或允许接收方通过工具按权限读取。

暂时无关的信息。 包括其他任务的历史记录、已失效的计划，以及与当前工作无关的内部资料。这些信息可以留在原系统中，需要时再补充。

筛选也不能只追求内容越少越好。如果协调方只告诉写作 Agent“新版优化了搜索体验”，却没有说明具体变化和信息来源，接收方就很难判断这句话能否写进正式公告。

因此，交接的重点是让接收方获得足以完成任务、核对结论的有效信息。关键事实应保留来源和适用范围，原始材料则可以按需获取。

信息不足时如何继续任务

即使协调方提前整理了相关的任务说明，也很难保证一次性提供全部接收 Agent 所需的信息。接收方执行任务时，可能会发现某个条件不明确，或者缺少判断所需的必要证据。

例如，写作 Agent 发现变更记录中有一项功能标注为“灰度发布”，但任务又要求只介绍正式上线的功能。它无法确定这项功能是否应该出现在更新说明里，就需要向协调 Agent 请求确认。

协调 Agent 可以根据发布规则作出判断：如果现有的信息不足以做出判断，协调 Agent 就需要向有权决定发布范围的人员确认。得到“本次发布不包含灰度功能”的答复后，再把这条决定补回原来的写作任务。

这时，写作 Agent 可以继续处理收到的材料，同时按照新的范围排除灰度功能，不用从头开始整个写作任务。

图 1：上下文交接与补充流程。协调 Agent 下发任务说明，专业 Agent 检查信息、请求澄清，协调方补充确认结果，专业 Agent 继续执行并返回交付物。

这里有两个关键点。首先，接收方要能够明确地提出缺少什么信息，让协调方知道应该补充哪一项条件。其次，新增的信息要关联原任务，避免在多个并行任务之间发生混淆。

任务要求变化后的上下文更新

除了补充缺失的信息，协调方还可能在执行中途变更原有要求。这种情况比单纯的补充材料更复杂，因为之前的部分工作可能白做了。

还是刚才的更新说明。假设写作 Agent 已经完成面向普通用户的初稿，协调方随后收到新要求：这份说明需要改成面向开发者，增加接口变化和兼容性说明。

此时，协调方需要传递新的受众要求，并明确它替代了此前的决定。写作 Agent 收到更新后，也要检查已有初稿：哪些段落可以保留，哪些描述需要修改，是否还缺少新的技术资料。

如果接收方同时保留“面向普通用户”和“面向开发者”两个内容受众要求，写作 Agent 可能会生成不符合两方任何一方预期的内容。

因此，系统还需要维护任务的当前版本。对于可能发生变化的目标、范围和约束，可以记录版本号、更新时间或变更记录，让接收方知道哪些信息仍然有效。

例如：

任务：撰写产品 v2.4 更新说明

要求版本：v2

本次变更：
- 目标受众改为开发者
- 增加接口变化和兼容性说明
- 正式发布范围保持不变

执行要求：
- 检查已有初稿是否需要修改
- 缺少技术资料时请求补充

这里的版本记录是任务管理系统可以采用的一种设计，并非所有 Agent 通信协议都内置这样的机制。

通过这类更新规则，接收方可以在原有工作基础上继续执行，同时避免使用已经过期的任务要求。

A2A 如何关联交接任务

对于运行在同一个系统的 Agent，协调方可以通过内部接口、消息队列或共享任务状态等方式来完成任务的交接。对于运行在不同服务或系统中的 Agent，可以借助 A2A（Agent2Agent）等通信协议来完成消息的传递和任务的追踪。

A2A 允许 Agent 通过消息进行交互，也支持具有执行状态的任务。其中，两个标识与上下文关联有关：

• taskId：标识一项具体任务，用于将后续消息关联到已经创建的任务。
• contextId：将多个相关任务和消息归入同一个交互上下文，便于保持交互连续性。

例如，协调 Agent 首次向写作 Agent 发起任务请求时，接收方可以创建任务并返回 taskId。如果后续需要确认灰度功能的发布范围，写作 Agent 可以将任务置于 input-required 状态，表示需要额外输入。

协调方确认后，通过原来的 taskId 发送补充信息，写作 Agent 就能在对应的任务中继续处理。

如果后续还需要审核 Agent 检查更新说明，可以建立另一项任务。相关的任务可以使用同一个 contextId，但各自拥有独立的 taskId，并分别维护执行状态和交付结果。

需要注意，contextId 用于关联交互，并不保证所有 Agent 自动共享完整上下文。不同 Agent 实际能够看到哪些消息、文件和历史状态，仍取决于具体的实现和权限配置。

A2A 负责提供任务与消息交互的协议机制，而哪些信息应该传递、旧要求如何更新、接收方是否具备访问权限，仍需要协调系统进行管理。

执行结果如何交还

上下文传递还包括任务完成后的结果回传。协调 Agent 需要了解接收方完成了什么、使用了哪些依据，以及哪些问题还没有解决。

例如，写作 Agent 已经生成更新说明，但发现其中一项性能改进缺少可以公开引用的数据。它可以返回初稿，同时把尚未确认的内容单独列出：

任务：撰写产品 v2.4 更新说明

结果：初稿已生成，存在一项待确认内容

已完成：
- 整理正式上线的功能变化
- 按当前受众要求生成说明
- 排除尚未正式发布的功能

待确认：
- 性能改进缺少可公开引用的数据

交付：
- 更新说明初稿
- 功能描述对应的来源记录

在 A2A 中，Message 可以用于发送请求、补充信息和交流进度；文档、数据等任务的交付物则可以通过 Artifact 表示。

协调 Agent 收到交付物后，还要根据最初的任务目标和最新的要求检查交付结果。如果部分内容还缺少依据，协调 Agent 就需要标记出来，等补齐相关的资料后再进行核实。

如果再安排审核 Agent 检查说明，协调方只需传递当前有效的发布要求、最新初稿、来源材料和待确认事项。审核 Agent 不需要重新阅读此前全部的讨论，就能继续完成工作。

上下文传递的安全边界

Agent 之间能够交换信息，并不意味着接收方可以访问协调 Agent 掌握的全部资料。

例如，一份版本变更记录会同时包含公开功能、未发布计划和内部测试结果。写作 Agent 只需要正式上线的功能资料，就没有必要接收其他内容。

因此，协调方在传递上下文之前，需要检查材料是否与任务相关、接收方是否有权访问，以及是否包含不应传递的敏感信息。

如果接收方需要读取原始文件，也应通过具备权限控制的工具或文件服务访问。提供文件路径或文档链接，并不等于授予了访问权限。

此外，其他 Agent 返回的内容和外部文档也可能包含错误信息，甚至带有试图改变模型行为的指令。系统需要区分可信的任务要求与待核实的参考材料，防止接收方把材料中的指令直接当成新的任务要求。

对于重要结论，还应保留信息来源和版本信息。这样，多个 Agent 即使在不同时间处理相关任务，也能判断自己使用的材料是否过期，避免基于互相冲突的条件继续工作。

结语

Agent 之间传递上下文，需要明确任务目标、范围、必要材料和交付要求，并在执行过程中处理必要的信息补充与要求更新。协调方还需要把新增信息关联到正确的任务，让接收方能够依据最新条件来继续执行任务。

交付结果时，Agent 应返回完成情况、依据和待验证事项，方便协调方检查结果并安排后续的工作。这样，多 Agent 系统才能在任务拆分和多轮交接中保持信息一致。