AutoGen：Multi-Agent 编排与 HITL
AutoGen 的原理是把单个 agent 的观察、推理、工具调用循环扩展成多个 agent 之间的可编排对话。不同 agent 可以拥有不同角色、提示、工具、终止条件和人类参与方式；复杂任务由消息传递、共享状态和中间产物逐步推进，而不是由一个模型一次性完成。
AutoGen / Multi-Agent Conversation / Orchestration 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_MULTI_AGENT_ORCHESTRATION_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
状态标注（2026-07-01）：AutoGen 已进入维护模式——微软已将 AutoGen 与 Semantic Kernel 合并为 Microsoft Agent Framework 1.0（2026-04-03 GA）作为生产级统一继任者，AutoGen 仓库转社区维护。本篇保留为 multi-agent conversation 思想的历史锚点：正文所讲的 role contract、shared state、tool gateway、termination、evidence trail 等构件是框架无关的，不随框架过时；但生产选型不要再选 AutoGen。现役对照见文末「SOTA 检查」。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| ReAct | https://arxiv.org/abs/2210.03629 | 理解 reasoning + acting 的 agent 基础循环（论文 2022-10） |
| Toolformer | https://arxiv.org/abs/2302.04761 | 理解模型使用工具的基础机制（论文 2023-02） |
| AutoGen | https://arxiv.org/abs/2308.08155 | 理解 multi-agent conversation framework 的基本思想（论文 2023-08；框架已维护模式，见顶部状态标注） |
| NIST GenAI Profile | https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence | 把多 agent 风险放入治理、评估和管理闭环（NIST AI 600-1，2024-07） |
核心导读
AutoGen 的原理是把单个 agent 的观察、推理、工具调用循环扩展成多个 agent 之间的可编排对话。不同 agent 可以拥有不同角色、提示、工具、终止条件和人类参与方式；复杂任务由消息传递、共享状态和中间产物逐步推进，而不是由一个模型一次性完成。
它的价值不在“多放几个 agent 就更强”，而在于把复杂任务拆成可协作、可审查、可替换的执行单元。证据收集、政策解释、草稿生成、独立复核和人工确认可以分开设计，工具权限也可以最小化分配。这样一来，错误更容易归因，成本更容易分层，高风险步骤更容易设置门禁。
边界是 multi-agent 会放大状态、权限、轮次、延迟、成本和责任问题。角色如果只有名字和 prompt，而没有输入输出契约、共享状态、工具边界、终止条件、预算上限和审计证据，就只是文本表演。金融零售系统应把 multi-agent 当成工作流架构问题，由 workflow engine、policy engine、tool gateway、eval 和 human gate 共同治理。
1. AutoGen 论文真正提出的问题
单个 agent 的基本循环是：观察任务，推理下一步，调用工具，读取结果，再继续。这个模式适合边界清楚的任务，但复杂知识工作往往不是一个角色完成的。
例如一个 AML case，不只是“读取交易后生成总结”。它包含证据收集、typology 判断、客户画像比对、政策解释、质量复核、升级路径和最终记录。把所有能力塞进一个 agent，会出现几类问题：
| 问题 | 单 agent 中的表现 |
|---|---|
| 角色混杂 | 同一个模型既收集证据、又判断风险、又复核自己的结论 |
| 状态混乱 | 工具结果、假设、审批意见和最终决定混在一个上下文里 |
| 责任不清 | 出错时无法判断是检索、分析、工具、策略还是复核失败 |
| 成本失控 | 每一步都用同一个大模型，无法做能力分层 |
| 审计困难 | 对话看似完整，但缺少结构化中间产物 |
AutoGen 的启发，是把复杂任务组织成多个可配置 agent 之间的 conversation。每个 agent 可以有不同角色、工具、提示、终止条件和人类参与方式。
但这只是抽象起点。企业 multi-agent 不是“几个聊天机器人互相讨论”，而是一个分布式工作流系统：角色、状态、工具权限、消息协议、评估标准和审计证据都必须显式化。
2. 从 ReAct 到 Multi-Agent
ReAct 给了 agent 一个核心循环：
Thought -> Action -> Observation -> Thought -> ...
AutoGen 把这个循环扩展到多个参与者：
Agent A message
-> Agent B interprets
-> Agent B calls tool or responds
-> Agent C reviews
-> Human approves or redirects
-> shared state updates
这个变化看似只是“多几个模型消息”，本质上改变了系统设计对象。
| 维度 | 单 agent | Multi-agent |
|---|---|---|
| 主要边界 | 模型和工具之间 | agent、工具、人类、共享状态之间 |
| 失败定位 | 输出错了 | 哪个 agent、哪条消息、哪个状态转移错了 |
| 评估单位 | 一次回答或一次工具调用 | 整个协作轨迹和最终业务结果 |
| 权限模型 | 一个 agent 拿一组工具 | 每个 agent 有独立 action authority |
| 成本治理 | 控制单次调用 | 控制轮次、模型分层、停止条件和重试 |
因此，multi-agent 的核心不是“角色越多越智能”，而是把任务分解成更容易控制、复核和替换的协作单元。
3. 什么任务适合 Multi-Agent
Multi-agent 有价值的前提，是任务天然存在角色分离、阶段分离或复核需求。
适合的任务通常有这些特征：
| 特征 | 原因 |
|---|---|
| 需要多个专业视角 | 例如法律、风险、产品、技术、安全必须分别判断 |
| 有明确中间产物 | 例如 evidence table、risk hypothesis、draft memo、review note |
| 需要独立复核 | 例如生成和审核不能由同一执行路径完成 |
| 工具权限差异明显 | 有的 agent 可读数据，有的可写工单，有的只能评论 |
| 失败代价较高 | 需要分步门禁、人类确认和可追溯记录 |
不适合的任务也很明确：
| 不适合场景 | 原因 |
|---|---|
| 简单问答 | 增加轮次和成本，没有增加可靠性 |
| 需求本身不清 | 多 agent 会把模糊目标放大成更多噪音 |
| 缺少共享状态模型 | agent 互相传话但没有事实源，最终难以审计 |
| 只靠 prompt 区分角色 | 角色没有工具、权限、输入输出契约，实际只是文本表演 |
| 没有终止条件 | agent 讨论会无限扩散或过度优化 |
评估 multi-agent 是否值得，不应问“能不能做”，而应问“是否让责任、质量和控制更清楚”。
4. Multi-Agent 的核心构件
一个可上线的 multi-agent 系统至少需要六类构件。
4.1 Role Contract
角色不是名字，而是输入、输出、权限和责任边界。
| 字段 | 示例 |
|---|---|
| Role purpose | Evidence Collector 只负责收集和结构化证据 |
| Inputs | case id、允许的数据源、当前任务状态 |
| Outputs | evidence table，不能输出最终判断 |
| Tools | read-only transaction API、document retrieval |
| Prohibited actions | 不能关闭 case，不能联系客户，不能修改事实记录 |
| Escalation | 证据缺失或冲突时交给 investigator/human |
如果角色只有 prompt 描述，而没有工具和输出契约，它无法成为可靠系统边界。
4.2 Shared State
Multi-agent 最常见的失败，是多个 agent 各自在对话里维护自己的世界观。
共享状态应把事实、假设、计划和决定分开：
| State object | 含义 |
|---|---|
| Facts | 来自系统或文档的可追溯事实 |
| Hypotheses | 模型或人提出的待验证判断 |
| Evidence links | 每个事实或假设对应的来源 |
| Decisions | 已审批或正式记录的决定 |
| Tasks | 当前待执行步骤和 owner |
| Exceptions | 数据缺失、冲突、失败、越权尝试 |
共享状态不能只是 chat transcript。Transcript 是审计材料之一，不应成为唯一状态源。
4.3 Orchestrator
Orchestrator 决定谁在什么时候做什么。
常见模式：
| 模式 | 适合场景 | 风险 |
|---|---|---|
| Sequential pipeline | 固定流程，如资料抽取 -> 判断 -> 复核 | 对例外处理不灵活 |
| Manager-worker | 任务可拆分，如多文件审查 | manager 可能错误分解任务 |
| Critic-reviewer | 需要独立质量审查 | reviewer 可能只做形式化批评 |
| Blackboard | 多 agent 共同更新共享状态 | 状态冲突和覆盖风险 |
| Event-driven | 外部事件触发 agent 行动 | 需要强幂等和重试控制 |
| Policy supervisor | 高风险动作前做权限和政策判断 | 不能只靠另一个 LLM 审批 |
企业架构中，orchestrator 往往不应完全由 LLM 承担。状态转移、权限判断、重试和审计更适合由 workflow engine、policy engine 和 durable runtime 管理。
4.4 Tool Gateway
每个 agent 的工具权限必须最小化。
| Agent | 工具权限示例 |
|---|---|
| Evidence Collector | read-only transaction/document APIs |
| Policy Interpreter | policy retrieval，不允许读客户完整资料 |
| Draft Writer | 读取已确认 facts 和 hypotheses，不直接调用生产系统 |
| Quality Reviewer | 读取 draft、evidence、rubric，输出 review findings |
| Human Operator | 批准、驳回、补充证据、提交正式决定 |
“所有 agent 共用全部工具”是高风险设计。它会让 prompt injection、confused deputy、数据外泄和错误写入更难控制。
4.5 Termination and Budget
Multi-agent 系统必须有停止条件。
停止条件可以来自：
- 业务状态完成，例如 case ready for human review。
- 质量门槛达到，例如 evidence coverage 过线。
- 成本或轮次达到上限。
- 出现冲突或不确定性，需要人工介入。
- 工具失败或权限不足。
没有停止条件，多 agent 很容易产生“讨论很长但没有交付”的假工作。
4.6 Evidence Trail
每次 agent 消息和工具调用都应能回答：
| 问题 | 原因 |
|---|---|
| 谁触发了这一步？ | 责任归属 |
| 使用了哪些输入？ | 复盘上下文 |
| 调用了什么工具？ | 权限和安全审计 |
| 写入了哪个状态对象？ | 状态可追踪 |
| 哪些内容进入最终输出？ | 证据链 |
| 哪些冲突被忽略？ | 风险复盘 |
如果只能看到最终答案，看不到协作轨迹，multi-agent 反而降低可解释性。
5. 金融零售案例：AML Investigation Team
一个高质量 AML multi-agent 设计不应让 agent “自己决定是否可疑”。更合理的是把调查工作分解为可审查的产物。
Case Intake
-> Evidence Collector
-> Typology Analyst
-> Customer Profile Analyst
-> Policy Interpreter
-> Narrative Drafter
-> Independent Reviewer
-> Human Investigator
各角色形成的中间对象：
| 角色 | 输出 |
|---|---|
| Evidence Collector | 交易序列、对手方、账户画像、历史 alert、缺失证据 |
| Typology Analyst | 可能 typology、支持证据、反证、置信度 |
| Customer Profile Analyst | 行为是否偏离预期画像 |
| Policy Interpreter | 当前政策、阈值、升级要求、引用来源 |
| Narrative Drafter | 只基于确认事实和标记假设生成 draft |
| Independent Reviewer | 检查事实遗漏、过度表述、证据不足、政策冲突 |
| Human Investigator | 最终决定、补充判断、提交或关闭 |
这个设计的价值不是“模拟一个调查团队”，而是把复杂认知工作拆成证据、假设、政策、叙事和复核几个层次，降低遗漏和过度自动化风险。
6. 金融零售案例：KYC Onboarding Squad
KYC onboarding 适合 multi-agent，是因为它天然跨文档、规则、客户沟通和审批。
可设计为：
| Agent | 职责 |
|---|---|
| Document Intake | 识别文件类型、版本、缺失字段 |
| Entity Resolver | 统一客户、UBO、法人、地址和注册信息 |
| Policy Matcher | 根据地区、产品、客户类型匹配 KYC 要求 |
| Risk Screener | 汇总 sanctions、PEP、adverse media 结果 |
| Customer Communication Drafter | 生成补件说明，但不能发送 |
| Review Coordinator | 汇总缺口和升级路径给人工 |
核心状态不是对话，而是 onboarding case：
| State field | 示例 |
|---|---|
| required_documents | 需要哪些文件 |
| received_documents | 已收到哪些文件 |
| validation_status | 每份文件的验证状态 |
| risk_flags | 命中的风险信号 |
| unresolved_gaps | 仍需补充的问题 |
| communication_drafts | 待审核客户消息 |
| human_decisions | 人工批准、驳回或升级理由 |
Multi-agent 在这里的价值，是把“复杂但重复”的 onboarding 判断变成可复用工作流，而不是让一个大模型直接给出最终通过/拒绝。
7. 评价 Multi-Agent 是否比 Single-Agent 更好
多 agent 不是天然更强，必须用结果证明。
| 评价维度 | 关注点 |
|---|---|
| Task success | 最终业务任务是否更稳定完成 |
| Evidence quality | 中间产物是否更完整、可追溯 |
| Error attribution | 出错后能否定位到角色、工具或状态 |
| Human load | 是否减少人工低价值工作，还是增加复核负担 |
| Cost and latency | 轮次增加是否可接受 |
| Safety | 权限越界、注入、错误写入是否下降 |
| Maintainability | 修改一个角色是否不影响整条链路 |
一个常见结果是：multi-agent 在复杂任务上质量更高，但成本和延迟更高。成熟产品需要根据风险分层决定何时启用多 agent：
- 低风险、简单问答：single-agent 或普通 RAG。
- 中风险、需要结构化产物：single-agent + reviewer。
- 高风险、跨角色工作流：multi-agent + workflow runtime + human gate。
8. 常见误读
| 误读 | 更准确的理解 |
|---|---|
| 多 agent 比单 agent 更智能 | 多 agent 主要改善分工、复核和责任边界，不保证能力提升 |
| 每个业务角色都应该变成一个 agent | 只有输入、输出、权限和评估边界清楚的角色才值得 agent 化 |
| Agent 互相聊天就是协作 | 协作必须落到共享状态、中间产物和可追踪决策 |
| Reviewer agent 可以替代人类复核 | Reviewer 可发现部分问题，但高风险决定仍需要人类责任 |
| Orchestrator 用 LLM 更灵活 | 状态转移、权限和重试通常应由确定性系统控制 |
9. 学习验证
读完这篇后，建议不要写“多 agent 产品机会清单”，而是画一个可执行的 orchestration design。
最小设计包：
| 设计部分 | 内容 |
|---|---|
| Task boundary | 哪个业务任务真的需要多角色协作 |
| Agent contracts | 每个 agent 的输入、输出、工具和禁止动作 |
| Shared state schema | facts、hypotheses、tasks、decisions 如何分开 |
| Orchestration pattern | sequential、manager-worker、review、event-driven 中选哪一种 |
| Human gates | 哪些状态必须人工确认 |
| Eval plan | 如何比较 single-agent、multi-agent 和 human-only baseline |
| Failure handling | 工具失败、证据冲突、agent disagreement、预算超限如何处理 |
真正掌握 AutoGen 的标志，是能解释为什么 multi-agent 本质上是架构问题，而不是 prompt 组织技巧。
SOTA 检查 (2026-07-01)
- AutoGen 本体：维护模式。微软将 AutoGen 与 Semantic Kernel 合并为 Microsoft Agent Framework 1.0（2026-04-03 GA），AutoGen 仓库转社区维护（AG2 分支亦为社区维护）。本篇价值在框架无关的编排构件，不在框架 API。
- 现役编排选型（2026-07）：Microsoft Agent Framework 1.0（2026-04 GA）、LangGraph（durable execution 线）、Claude Agent SDK、OpenAI Agents SDK。库内对比笔记：
docs/llm/day131-claude-47-agent-sdk.md、docs/llm/day134-langgraph-autogen.md、docs/llm/day139-multi-agent-orchestration-patterns.md、docs/llm/day149-sota-review-deprecation-list.md。 - 协议层演进：多 agent 互操作正向 MCP（稳定版 2025-11-25；2026-07-28 计划发布最终规范）与 A2A 收敛，编排框架锁定成本下降——选型先定协议边界，再选框架。
- 本篇定位：历史回顾/经典锚点（符合 CLAUDE.md 时效例外条款）；本篇正文的 role contract / shared state / termination / evidence trail 结论在现役框架中仍然成立。