AutoGen / Multi-Agent Conversation / Orchestration 解读

面向对象: AI Architect / AI PM / AI BA / AI Platform PM / Workflow Automation Lead。 核心问题: 多智能体系统什么时候有价值，什么时候只是把单个 agent 的问题放大？ 学习目标: 能把 multi-agent 从“多个机器人聊天”转成角色、状态、工具、审批、评估、成本和责任边界清楚的企业工作流。

---

Source Anchors

本文不把 AutoGen 当成唯一框架，也不鼓励“凡事多 agent”。它的价值是帮助 PM/BA/架构师理解 multi-agent 的抽象: 可对话的角色、可配置的能力、可编排的交互、可插入的人类参与。

---

AutoGen 论文的核心问题

AutoGen 关注的问题是:

如何通过多个可对话 agent 组合 LLM、人类、工具和代码执行能力，支持更复杂的应用开发？

它把应用建模为多个 agent 之间的 conversation。不同 agent 可以有不同角色、系统提示、工具、人类输入方式和执行能力。

企业 AI 要吸收的关键点:

1. 复杂任务需要角色分工，但角色分工必须服务流程，不是为了炫技。
2. Agent 之间的 handoff 要有契约，不能只靠自然语言自由聊天。
3. Human-in-the-loop 是系统能力，不是失败后的临时人工介入。
4. 多 agent 会放大成本、状态、权限和评估复杂度。

---

从 ReAct 到 Multi-Agent

ReAct 可以表示单 agent 的循环:

Thought -> Action -> Observation -> Thought -> ...

Multi-agent 则进一步引入角色间协作:

User / Event
  -> Planner agent
  -> Retriever agent
  -> Domain analyst agent
  -> Verifier / critic agent
  -> Human approver
  -> Executor / drafting agent
  -> Audit and feedback

但企业系统不应暴露无限自由的 agent 对话。更好的表达是:

Role
  -> Responsibility
  -> Input contract
  -> Output contract
  -> Tool permission
  -> State access
  -> Escalation rule
  -> Eval criteria

这也是 BA/PM/架构师能发挥价值的地方。

---

Multi-Agent Taxonomy

角色不是 prompt 名字

如果一个 agent 的责任、输入、输出、工具、权限、评估都没有定义，它只是一个 prompt persona，不是企业角色。

企业要的不是:

你是一个优秀的合规专家。

而是:

Compliance Reviewer Agent
- Input: draft answer, cited sources, risk tier
- Output: pass/fail + issue tags + required escalation
- Tools: read-only policy search
- Forbidden: customer communication, account action
- Eval: policy violation detection, false pass rate

---

什么时候不要用 Multi-Agent

多 agent 的常见误区是把复杂度当能力。

不建议多 agent 的场景:

PM 需要能说出“不做多 agent”的理由。架构师需要能设计单 agent 到多 agent 的演进路径。

---

Orchestration Patterns

Sequential Pipeline

Retrieve -> Analyze -> Draft -> Verify -> Human approve

适合:

• KYC checklist。
• 信贷 memo draft。
• 合规政策问答。

优点是易评估、易审计。缺点是灵活性较低。

Manager-Worker

Manager plans and assigns
  -> Worker A retrieves
  -> Worker B analyzes
  -> Worker C drafts
  -> Manager consolidates

适合:

• AML investigation。
• 复杂投诉根因分析。
• 商户风险复核。

风险是 manager 可能过度拆分或错误路由。

Critique / Review

Draft agent -> Critic agent -> Revision -> Human

适合:

• 客户沟通草稿。
• SAR narrative draft。
• 信贷 adverse action reason review。

需要评估 critic 的 false pass 和 false block。

Blackboard / Shared State

多个 agent 读写一个 shared state:

Case state
  <- Retriever evidence
  <- Analyst findings
  <- Risk tags
  <- Human notes
  <- Final narrative

适合复杂 case，但必须严格控制 schema、版本和权限。

Event-Driven Agents

Agent 被事件触发:

• 新 alert 到达。
• KYC 文件上传。
• 支付争议进入 SLA 风险。
• 商户退款率异常。

适合生产工作流，但要有幂等性、重试、死信、限流和人工接管。

Policy Supervisor

Policy supervisor 不负责业务分析，而负责:

• 是否允许继续。
• 是否需要人工。
• 是否触发 kill switch。
• 是否违反工具权限。
• 是否超出成本或循环上限。

这是金融零售多 agent 的核心控制点。

---

金融零售案例

AML Investigation Team

禁止:

• 自动关闭 alert。
• 自动提交 SAR。
• 用未确认假设作为事实。

KYC Onboarding Squad

Credit Memo Reviewer

重点:

• Agent 不能作出信贷决定。
• 解释必须可引用政策和申请事实。
• 客户影响决策需要人工和合规控制。

---

Shared State Schema

多 agent 系统最容易失败在状态混乱。每个 agent 都写自然语言，最后没人知道哪些是事实、假设、建议、决定。

建议使用结构化 shared state:

BA 可以用这个 schema 写 requirement。架构师可以用它设计数据库、event log 和 trace。PM 可以用它定义 UI 中哪些内容给用户看，哪些只给审核员看。

---

Multi-Agent Eval

Release gate 示例:

---

PM / BA / Architect 输出

---

30 秒面试表达

我不会默认用多 agent。只有任务确实需要角色分工、证据检索、专业判断、验证和人工审批时，多 agent 才有价值。企业 multi-agent 的关键不是让多个模型聊天，而是定义 role charter、handoff contract、shared state、tool permission、policy supervisor、eval scorecard 和 audit trace。

2 分钟面试表达

多 agent 可以把复杂工作流拆成 planner、retriever、domain specialist、verifier、executor 和 human approver，但它也会放大状态、权限、成本和评估问题。所以我会先判断单 agent 加工具是否足够。如果确实需要多 agent，我会设计每个 agent 的输入输出契约、允许工具、共享状态 schema、停止条件、人工 checkpoint 和 policy supervisor。金融场景如 AML investigation 可以用 summarizer、evidence retriever、network analyst、narrative drafter、compliance verifier 和 human investigator，但 AI 不自动提交 SAR 或关闭 alert。评估上我会看 task success、handoff accuracy、tool correctness、unsafe action attempts、cost per case、human override rate 和 trace completeness。

CTO 深挖回答

技术上我会避免自由对话式的无限 multi-agent。更可控的是 workflow orchestrator + typed shared state + tool gateway + policy supervisor。每个 agent 的输出必须符合 schema，工具调用经过权限和风险检查，所有 handoff、tool result、model output、human decision 都进入 trace。高风险 action 必须有 human checkpoint 和 kill switch。

CRO 深挖回答

风险上，多 agent 不应稀释责任。每个步骤要有 owner、risk tier 和 evidence requirement。AI 可以生成建议和草稿，但客户影响、监管提交、账户限制、信贷决定等必须保留人工责任和审批记录。监督指标包括 unsafe action attempt、policy block、override rate、incident tags 和 residual risk。

PM 深挖回答

PM 要防止多 agent 变成昂贵 demo。我要定义的是业务结果和单位经济: 每 case 节省多少时间、减少多少返工、提高多少证据完整性、增加多少人工审核负担、每次处理成本多少。若多 agent 比单 agent 的增益不能覆盖成本和风险，就不应该扩大范围。

---

输出练习

读完本文后，产出五个资产:

1. Agent Role Charter: 为一个 AML/KYC case 定义 5 个 agent 和 1 个 human role。
2. Handoff Contract: 定义每次交接的输入、输出、schema 和 failure handling。
3. Shared State Schema: 区分 facts、hypotheses、draft、human decision。
4. Supervisor Policy Table: 定义哪些动作允许、阻断、升级、双人审批。
5. Multi-Agent Eval Scorecard: 定义 task、safety、cost、trace、human burden 指标。

作品集表达:

我设计 multi-agent 不追求“多个模型互聊”，而是把复杂金融工作流拆成可治理角色，用 handoff contract、shared state、tool permission、human checkpoint 和 eval scorecard 控制风险。这证明我能把 agentic AI 转成生产级工作流。