Agent 委派协议设计：子 Agent 输入输出与责任边界

把复杂任务拆给多个 Agent 听起来很自然：研究 Agent 找资料，执行 Agent 调工具，审阅 Agent 检查结果。但如果委派只是把一段聊天记录转发给“另一个模型”，系统很快会出现循环委派、上下文丢失、权限扩大和无法追责的结论。多 Agent 的核心不是增加角色数量，而是把角色之间的接口设计得像可靠服务一样明确。

一份委派契约至少需要定义五类内容：任务目标、允许输入、预期输出、资源边界和完成判据。目标不应是“研究一下这个问题”，而应写成“比较三个候选方案，输出带来源的风险矩阵，不执行任何外部写操作”。允许输入明确哪些上下文会被传递，避免把用户隐私或管理员 token 无差别扩散；预期输出则应该是 schema，而不是一段自由文本。

让输出先通过 schema 再进入下一层

子 Agent 的返回结果要先经过确定性验证，再被调度器消费。可以要求每个结果具有 status、summary、evidence、openQuestions、artifacts 和 handoff 字段。status 只允许 completed、needs_input、blocked 或 failed；evidence 必须提供来源或工具调用 ID；handoff 明确下一步建议而不是直接触发执行。

{
  "status": "completed",
  "summary": "三个方案中 A 的延迟最低，但缺少租户隔离证据。",
  "evidence": [{"source": "tool:metrics-query", "artifactId": "art_123"}],
  "openQuestions": ["A 是否支持按项目隔离缓存？"],
  "handoff": {"recommendedRole": "security-review", "reason": "需要核验隔离模型"}
}

若 schema 校验失败，调度器应将结果标记为无效并要求重试或人工处理，而不是把不完整文本继续传给下一个 Agent。这样能阻止一个幻觉字段成为下游写操作的依据。

权限和预算沿委派链收缩

父 Agent 不应把自己的全部权限复制给子 Agent。委派时生成一个范围更小、时效更短的能力令牌，例如只允许读取某个项目的文档，最多调用两次搜索工具，不能创建或删除资源。能力应随着链路向下收缩而不是扩张。子 Agent 要调用新工具时，必须回到调度器申请，不能自己改变 scope。

同样要传递预算：最大模型调用次数、总 token、最长运行时间、最大外部成本和最大并发。没有预算的委派容易变成递归扩张，尤其在“请再找一个专家确认”的提示下。调度器要记录委派树和预算消耗，达到阈值后进入总结或人工审批，而不是继续生成角色。

责任要能回收，而不是只会转发

每个任务应有一个唯一 owner。即使它委派给十个子 Agent，最终也由 owner 整合、验证和决定是否提交结果。子 Agent 可以产出证据，不能悄悄把责任转给另一个未知角色。委派记录需要保存父子 run ID、输入摘要哈希、分配时间、超时、能力范围和最终结果状态。

一个实用的验证场景是故意让子 Agent 返回缺少证据的结论，或请求超出 scope 的工具。正确系统应拒绝该结果或能力请求，并把失败关联到原始委派，而不是让任务静默消失。再模拟父 Agent 超时，确认未完成子任务被取消或收回，避免后台继续产生无主成本。

何时应使用单 Agent

多 Agent 不是默认答案。若任务目标单一、工具很少、上下文必须完整共享，单 Agent 加明确工具边界通常更可靠、更便宜。只有当角色确实需要不同的上下文、权限、并发或验证职责时，委派契约才值得引入。先写清接口，再增加角色，能避免把组织结构幻觉带进系统架构。

延伸阅读

• 多 Agent 通信
• Agent 循环设计
• 可靠工具调用