任务契约与上下文交接
任务契约是调用方与执行方对一次子任务的约定：要解决什么问题，可以使用哪些输入，交付什么，以及怎样判断交付是否合格。它可以写在提示词、工具参数或结构化消息中，不要求使用专门的通信协议。
上下文交接负责把这份约定和必要资料传给执行方，再把结果交给后续步骤。子 Agent 有自己的上下文时，不能假定它已经看过主管的完整对话；主管也不能凭一句“查完了”就知道子任务完成了哪些要求。
下面沿用采购助手的任务：比较 A、B、C，预算不超过 6000 元，重量不超过 1.5kg，用于 Python 开发，只给建议、不购买。主管将 C 的资料核实交给一个子 Agent，随后把各候选的结果交给写作 Agent。
从用户要求形成子任务
如果主管只发“查一下 C 好不好”，子 Agent 可能查跑分，也可能列出品牌历史，最终仍然缺少比较所需的价格和重量。分派时应保留影响判断的条件，并限定本次要查的对象。
{
"task_id": "verify-c",
"task_revision": 1,
"assignee": "product_researcher",
"goal": "核实 C 的指定配置是否满足当前采购条件",
"input": {
"product_id": "C",
"variant": "16GB / 512GB",
"max_total_price_cny": 6000,
"max_weight_kg": 1.5,
"use_case": "Python 开发",
"working_assumption": "暂按日常脚本、IDE 和轻量 Web 开发理解，尚未向用户确认具体负载"
},
"scope": {
"required_fields": ["配置", "当前总价", "重量", "来源与查询时间"],
"excluded_actions": ["购买", "修改其他候选的资料"]
},
"acceptance": [
"每条数值对应同一型号和配置，并附可读取的来源",
"无法核实的字段明确标记为未知",
"区分用户硬条件与执行方的建议"
],
"budget": {
"max_model_calls": 6,
"max_tool_calls": 8,
"timeout_seconds": 120
},
"deliverable": "结构化核实结果，包含结论、证据和未完成项"
}goal 描述期望结果，scope 限制查什么和做什么，acceptance 让主管有条件核对交付。三者解决的问题不同：输出符合 JSON 格式，只能说明格式可解析，不能说明价格属于正确配置。
这里按 16GB 版本分派核实任务，但用户并没有要求“内存必须达到 16GB”。子 Agent 不能把本次待查配置改写成整个采购任务的硬条件。working_assumption 则保留了主管对使用场景的暂定理解，下游不能把它改写成用户确认过的要求。
预算字段需要执行程序落实。程序在调用前检查剩余额度，为正在执行的并发调用预留额度，到期后停止启动新动作，并按工具支持的能力处理取消。仅在提示词里写“最多调用 8 次”，无法保证不会超出。跨子任务的总预算和取消传播见子任务生命周期与失败恢复。
结果里要保留哪些关系
子 Agent 查到 C 的价格和重量后，返回“C 满足要求”会丢掉结论成立的条件。主管至少需要知道具体配置、数值、来源，以及是否还有未核实事项。
{
"task_id": "verify-c",
"task_revision": 1,
"status": "completed",
"conclusion": "C 的 16GB / 512GB 版本满足已核实的预算与重量条件",
"evidence": [
{
"evidence_id": "c-price-01",
"field": "total_price_cny",
"value": 5999,
"source_ref": "sources/c-offer",
"locator": "16GB / 512GB 配置报价",
"observed_at": "2026-09-28T10:00:00+08:00"
},
{
"evidence_id": "c-weight-01",
"field": "weight_kg",
"value": 1.42,
"source_ref": "sources/c-spec",
"locator": "规格表中的整机重量",
"observed_at": "2026-09-28T10:00:00+08:00"
}
],
"artifacts": ["results/verify-c.json"],
"unresolved": [],
"limitations": ["未验证重度容器开发或本地模型训练的适用性"]
}source_ref 应由应用映射到实际 URL、文件或存储记录，并向接收方提供读取能力。只交一个无法解析的 source_1，下游仍然不能核对证据。文件型产物还应携带版本或内容哈希，避免主管稍后读到已经改变的内容。
这份结果中的 completed 表示执行方认为约定工作已经完成。主管还要检查所需字段是否齐全、来源是否可用、配置是否一致，然后记录验收结果。如果只有重量得到核实，结果应标明价格未完成；不能把一项工具失败包装成全部完成，也不能把“未找到”写成“没有”。
需要补查时，主管可以要求执行方补齐价格，并保留这次请求与原任务的关联。如果用户已经把预算降到 5500 元，应更新任务修订号并重新判断；旧版结果中的 5999 元仍是一次查询事实，旧版的“满足预算”结论则已不再适用。
交给写作 Agent 的上下文怎样组织
主管收到各候选的结果后，要让写作 Agent 形成比较。写作 Agent 不需要重新经历每一次搜索，但需要能够追溯最终采用的证据。
目标
比较 A、B、C，给出带来源的建议；只建议，不购买。
当前条件
总价不超过 6000 元，重量不超过 1.5kg。
暂按日常 Python 开发比较，具体负载尚未向用户确认；优先考虑 16GB 是选型建议，不是用户硬条件。
已验收记录
A：分别保留 8GB 和 16GB 版本，记录见 results/verify-a.json；不得拼接两个版本的价格与配置。
B：重量超出条件，相关记录见 results/verify-b.json。
C：16GB / 512GB，5999 元、1.42kg；证据见 results/verify-c.json。
写作要求
解释取舍，引用各数值对应的来源。
需要扩展性信息时读取原始规格；现有结果没有验证重度开发负载。这样的交接把当前条件、已验收结果与写作要求放到了一起。具体数值可以直接提供，也可以通过结果文件按需读取；采用后一种方式时，必须确保写作 Agent 有相应工具和读取权限。
完整历史、摘要和原文定位各有用途，取舍应根据下游任务决定。
| 下游要做什么 | 值得传递的内容 |
|---|---|
| 汇总多个独立调查 | 任务条件、结论、证据、未知项，以及必要的产物引用 |
| 继续用户对话 | 相关对话原文、当前状态，尤其是指代和条件变更所依赖的消息 |
| 判断一段原话是否被曲解 | 原话及其前后文，摘要不足以支持这种判断 |
| 排查重复失败 | 已尝试的关键方法、失败原因与日志定位，避免重新走同一条失败路径 |
| 接续尚未结束的工具循环 | 接口要求的工具调用与对应结果，保持调用编号等关联完整 |
短历史可以直接传递；较长历史可以保留近期交互，对更早内容做摘要，并提供回查入口。摘要要保住条件、否定、例外和来源，不能只留下一个结论。压缩方法可继续看记忆压缩。
数据交接与控制权交接
调研 Agent 返回结果，主管继续执行，再调用写作 Agent，这是数据沿工作流传递。主管始终负责下一步决策。
Handoff 则涉及执行控制权的转移。例如接待 Agent 将售后会话交给维修 Agent，由后者继续处理后续用户消息。任务资料如何传过去，仍然需要本篇的契约与上下文设计；但“传了一个结果对象”本身不意味着发生了 Handoff。两种控制方式的执行过程见路由与 Handoff。
无论哪种交接，信息来源都要保留。工具读到的网页、另一个 Agent 的推测、用户的明确要求具有不同含义。上游把网页内容写进摘要后，它仍然是外部资料；子 Agent 的“建议执行购买”也不会自动变成用户授权。工具的实际可用范围由执行端控制，消息字段用于表达和校验已有约定。
参考资料
- Anthropic：Effective context engineering for AI agents：上下文选取、压缩与子 Agent 架构。
- LangChain：Multi-agent systems：协作模式及上下文设计。
- OpenAI Agents SDK：Handoffs：控制权交接及输入过滤。