多 Agent 协作要如何设计？

背后工程点：多 Agent 是不确定任务的并行治理，不是默认升级。
专业术语：
Task Decomposition 是任务拆分；
Coordination Cost 是协作和汇总成本；
Shared State 是多个执行体共同依赖的状态；
Verification Surface 是子任务结果可验证的证据面；
Single-agent Baseline 是单 Agent 基线。
为什么这样回答：先讲“不该用”的边界，能显示你不会用多 Agent 装饰架构。资深判断是先有单 Agent 基线，再证明拆分收益。
小白解析：不是每件事都适合多人做。写一封短邮件，一个人更快；同时检查三个模块，三个人可能更快。关键是能不能清楚分工。
关联知识点：Anthropic 强调从简单模式开始；learn-agent Delegation Runtime 说委派要保留控制权；Deep Agents subagents 主要价值是隔离上下文。

背后工程点：协作形态要匹配控制权边界。
专业术语：
Manager-as-tool 是父 Agent 把子 Agent 当工具调用；
Handoff 是对话控制权交接；
Active Agent 是当前直接响应用户的 Agent；
Handoff Span 是交接轨迹；
Return Condition 是交接返回条件。
为什么这样回答：这能把主流方案讲清楚，不把所有多 Agent 都混成一个模式。
小白解析：一种是经理派人查资料，最后经理汇报；另一种是客服把你转给技术同事，技术同事直接跟你说话。
关联知识点：OpenAI Agents SDK 区分 agents as tools 和 handoffs；LangChain multi-agent 也区分 tool calling 与 handoffs。

背后工程点：委派接口是运行时 contract，不是 prompt 字符串。
专业术语：
Task Package 是结构化子任务包；
Context Ref 是上下文证据引用；
Output Contract 是结果格式要求；
Abort Signal 是取消信号；
Risk Level 是任务风险等级。
为什么这样回答：schema 能证明你把多 Agent 当工程接口，而不是“给另一个模型发消息”。字段越具体，越能抗追问。
小白解析：派工单不能只写“你帮我看看”。要写清楚目标、范围、能用什么工具、什么时候停、最后交什么。
关联知识点：learn-agent 00-18 把 delegation 做成特殊工具；OpenAI agent-as-tool 也强调工具描述和输出格式影响路由质量。

背后工程点：子任务上下文是投影，不是父上下文复制。
专业术语：
Context Quarantine 是上下文隔离；
Delegated Context 是专门投影给子任务的上下文；
Read-back Ref 是需要细节时回读的证据引用；
Clarifying Result 是子 Agent 返回“缺少信息”的结构化结果；
Noise Budget 是可接受噪声预算。
为什么这样回答：多 Agent 的价值之一就是隔离噪声。你要说明缺上下文时怎么补，而不是把隔离原则放弃。
小白解析：让审计同事看所有公司聊天记录不现实，也不安全。给他审计所需材料，不够再补。
关联知识点：Deep Agents subagents 强调主 Agent 不吃掉子任务工具噪声；Guga context 投影思想同样适用于 delegated context。

背后工程点：权限继承必须单调收缩，审批要保留子任务身份。
专业术语：
Permission Intersection 是权限交集；
Blocked Tools 是禁止工具列表；
Permission Bridge 是子权限请求回父级的桥；
Delegated Identity 是子 Agent 身份；
Approval Scope 是授权范围和期限。
为什么这样回答：多 Agent 容易权限放大。把身份、目标和工具展示出来，才能让 HITL 有意义。
小白解析：项目经理能进机房，不代表所有外包同事都能进。外包要进，必须说明是谁、进去干什么、多久。
关联知识点：learn-agent 00-18 强调子 Agent 权限不能自动拥有父级全部能力；Deep Agents 支持 per-subagent tools 和 permissions。

背后工程点：子 Agent 提出高风险动作，不等于可以直接执行。
专业术语：
Action Proposal 是动作申请；
Action-level Gate 是动作级审批；
Impact Scope 是影响范围；
Rollback Path 是回滚路径；
Global Objective 是父任务全局目标。
为什么这样回答：多 Agent 权限最怕“局部授权变全局事故”。高风险动作回父级，是为了保留用户可见控制面。
小白解析：实习生可以建议删一个文件，但主管要看影响范围再决定。
关联知识点：Guga 工具运行时强调模型只提出意图、runtime 执行权限；Deep Agents HITL 也围绕具体动作审批。

背后工程点：多 Agent 可靠性来自结果协议和父级证据审阅。
专业术语：
Claim 是子 Agent 提出的结论；
Evidence Ref 是证据引用；
Unknowns 是未确认事项；
Synthesis Review 是父级综合审阅；
Hypothesis 是待验证假设。
为什么这样回答：“多个模型互相确认”不是可靠性。真正可靠的是证据可查、置信度可解释、父级可复核。
小白解析：三个同事都说“没问题”不够。你要看他们查了什么材料，证据是不是同一份，漏洞有没有遗漏。
关联知识点：learn-agent 的 result contract 要求 structured output；OpenAI tracing 可以记录 handoff/tool span，支撑父级审阅。

背后工程点：冲突裁决靠证据和验证任务，不靠 Agent 互辩。
专业术语：
Evidence Ranking 是证据排序；
Targeted Verification 是定向验证；
Review Round 是审阅轮次；
Stop Reason 是停止原因；
Need Human 是需要人工判断。
为什么这样回答：这能避免多 Agent 变成无界讨论。父级要把冲突转成可验证动作。
小白解析：两个同事争论谁对，不如拿原始文件和测试结果出来核对。
关联知识点：AutoGen teams 需要 termination condition；learn-agent 强调父 Agent 合并证据，不是投票表决。

背后工程点：并发写入要隔离副作用，父级集中合并。
专业术语：
Resource Lock 是资源锁；
Worktree Isolation 是独立工作区隔离；
Patch Artifact 是补丁产物；
Merge Review 是合并审查；
Verification Gate 是合并后的验证门禁。
为什么这样回答：多 Agent coding 最容易互相踩文件。只说路径锁不够，要讲独立产物和父级合并。
小白解析：三个人同时改同一份合同，最后必须由一个负责人合并，而不是各自直接覆盖云文档。
关联知识点：SWE-agent 强调 Agent-Computer Interface 影响软件工程质量；learn-agent delegation 也把写任务和读任务的并发策略区分开。

背后工程点：子 Agent 输出也是外部数据，不能天然可信。
专业术语：
Untrusted Result Data 是不可信结果数据；
Trust Level 是可信等级；
Instruction/Data Boundary 是指令和数据边界；
Raw Excerpt 是原始摘录；
Evidence Sanitization 是证据清洗。
为什么这样回答：多 Agent 会扩大 prompt injection 面。父 Agent 不能因为来源是“内部子 Agent”就忽略数据边界。
小白解析：同事转述网页内容，网页里的“忽略上级命令”还是网页内容，不是同事的新命令。
关联知识点：MCP 和工具安全强调外部内容不能升级为指令；Guga context policy 的 trust/source descriptor 也适用于子结果。

背后工程点：子 Agent 不能绕过长期资产治理。
专业术语：
Memory Candidate 是候选记忆；
Skill Candidate 是候选技能；
Rationale 是写入理由；
Asset Governance 是资产治理；
Scope 是适用范围。
为什么这样回答：多 Agent 会产生更多“发现”，但不是每个发现都值得长期保存。要把 memory/skill 写入权收回治理层。
小白解析：临时工发现一个小技巧，可以写进报告，但不能直接改公司操作手册。
关联知识点：learn-agent memory governance 强调候选账本；Hermes background review 把 memory 和 skill 创建放到后台治理。

背后工程点：父子轨迹要保留因果链，摘要回流不等于证据丢失。
专业术语：
parent_run_id 是父运行编号；
child_run_id 是子运行编号；
Causation Id 是因果关系编号；
Trace Merge 是轨迹归并；
Evidence Ref 是可追溯证据引用。
为什么这样回答：多 Agent 让问题定位更难，trace 设计是承重能力。必须能从最终结论追到子任务事实。
小白解析：最终报告里写“安全同事确认过”，还要能点进去看到他看了哪些文件、跑了哪些检查。
关联知识点：learn-agent 00-18 和 00-19 都强调 sub-agent trace 归并；OpenAI tracing 记录 handoff span 和 tool span。

背后工程点：恢复依赖任务账本和幂等语义，不能重跑副作用。
专业术语：
Task Ledger 是子任务账本；
Output Hash 是结果指纹；
Idempotency Key 是幂等键；
Effect Log 是副作用日志；
Verification Task 是重新验证任务。
为什么这样回答：恢复是生产级多 Agent 的硬问题。重跑子任务可能重复写文件、发请求或浪费成本。
小白解析：快递已经发出，系统恢复时不能再发一次。应该查发货记录和物流单号。
关联知识点：Guga replay 默认不重跑 provider、tool 或 mutating hook；learn-agent durable execution 也区分诊断回放和真实重试。

背后工程点：子任务失败是可分类事件，不应默认等于父任务失败。
专业术语：
Failure Taxonomy 是失败分类；
Partial Result 是部分结果；
Budget Exceeded 是预算耗尽；
Unsafe 是安全拦截；
Fallback Path 是降级路径。
为什么这样回答：这能体现可靠性。复杂任务不可能所有子任务都完美，父级要知道如何降级和继续。
小白解析：一个同事没查到资料，不代表项目失败；但唯一负责验收的人没验过，就不能说项目完成。
关联知识点：learn-agent delegation 有 validation/capability/runtime/contract failure；Agent eval 应测失败恢复率。

背后工程点：递归委派是高风险能力，第一版应关闭。
专业术语：
max_depth 是最大委派深度；
Global Budget 是父子共享总预算；
Loop Detection 是循环检测；
Role Allowlist 是允许角色列表；
Delegation Tree 是委派树。
为什么这样回答：这体现复杂度控制。先单层，等 trace、权限、预算成熟再考虑递归。
小白解析：你让一个同事帮忙，不代表他可以再招十个人，还都花你的预算。
关联知识点：Hermes 和 learn-agent 的工程取舍都偏向单层受控委派；swarm 适合后期而非 MVP。

背后工程点：多 Agent 价值要用基线和指标证明。
专业术语：
Wall-clock Time 是用户等待时间；
Parent Rework Rate 是父级返工率；
Conflict Rate 是结果或写入冲突率；
Fan out 是并行分发；
Partial Synthesis 是基于部分结果综合。
为什么这样回答：面试官会攻击成本。你要先承认代价，再给出评测和并发控制。
小白解析：请三个人干活会更快，但工资更高、沟通更多。要算清楚是不是值得。
关联知识点：Anthropic 提醒 agentic system 会以成本和延迟换表现；AutoGen teams 需要 termination condition 控制无界对话。

背后工程点：多 Agent 产品化要让用户理解、控制和接管并行任务。
专业术语：
Task Timeline 是任务事件线；
Child Task Status 是子任务状态；
Cancellation Propagation 是取消传播；
Evidence Summary 是证据摘要；
Permission Request 是权限请求。
为什么这样回答：生产系统不只后端能跑，还要用户能看懂并控制。多 Agent 黑盒会降低信任。
小白解析：你请了三个人办事，应该看到每个人在做什么，可以叫停某个人，而不是等最后一个大结论。
关联知识点：Guga 的事件账本和 UI 投影能支持 timeline；OpenAI tracing 和 AutoGen teams 都显示协作需要可观测性。

背后工程点：多 Agent eval 要评过程、成本和协作质量。
专业术语：
Baseline 是对照基线；
SLA 是服务水平目标；
Trace-based Eval 是基于轨迹的评测；
Join Quality 是父级合并质量；
Unknown Handling 是未解问题处理。
为什么这样回答：多 Agent 常见假象是“看起来更努力”。用指标比较才能判断值不值得。
小白解析：多请两个人让成功率高 1%，但花费翻倍，未必划算。要看任务重要程度。
关联知识点：Anthropic 建议用 eval 证明复杂 agentic system 增益；learn-agent trace analysis 可检查 delegation join failure。

背后工程点：子 Agent 角色是版本化能力，不是散落 prompt。
专业术语：
Role Registry 是角色注册表；
Prompt Version 是提示词版本；
Output Schema 是输出结构；
Conformance Test 是契约一致性测试；
Owner 是角色维护负责人。
为什么这样回答：多 Agent 系统后期难维护，角色漂移会导致路由和结果不稳定。版本化和测试是治理手段。
小白解析：“安全审查员”这个岗位要有岗位说明书和考核标准，不能每周换一种工作方式。
关联知识点：AutoGen teams 和 Deep Agents 都用 agent definitions；Guga 插件/能力注册表思路可扩展到 Agent roles。

背后工程点：多 Agent MVP 要先压控制面，不追求炫技。
专业术语：
MVP 是最小可用版本；
Concurrency Limit 是并发上限；
Patch Artifact 是补丁产物；
Trace Merge 是轨迹归并；
Swarm 是更自由的多 Agent 协作形态。
为什么这样回答：这能收束整章。先单层、受控、可审计，是从单 Agent 过渡到多 Agent 的稳妥路径。
小白解析：先做一个能派单、收单、验单的小团队系统，别第一天就做大型组织协同平台。
关联知识点：Hermes delegate_task 和 learn-agent Delegation Runtime 都偏单层受控；Anthropic 也建议先从简单模式做起。