B4 · Agentic 与多智能体 Control Plane——多智能体 = 新型微服务，编排面才是护城河

系列第 8 篇 · B 线（AI 工程化）第 4 篇
定位：架构师选型视角 · 深度长文
承接：B1（架构优先）/ B2（RAG 知识层）/ B3（MCP 工具层）
衔接：B5（模型路由与成本——Control Plane 里的 Model Gateway 正是其落点）

---

0. 一句话立论

单 Agent 是个实验，多 Agent 协作才是生产系统；而决定它能不能上生产的，不是某个 Agent 有多聪明，是那层把"谁下一步跑、传什么状态、失败怎么恢复、人何时介入"管起来的 Control Plane（控制面）。 多智能体本质是"会自己决策的新型微服务"，你当年在微服务治理上踩过的坑（可观测、重试、权限、审批、回退），在 Agent 世界里一个都不会少，而且放大了不确定性。

对架构师而言，2026 年最被低估的一层，不是模型，不是 Agent 框架，而是编排面 / 治理面。

---

1. 范式跃迁：从 Copilot 到 Agent

B1 说过，AI 应用正从"UI 层 Copilot"走向"控制面 Agent"。把这条线画清楚：

形态	模型角色	谁决策	典型场景
Copilot（补全/建议）	生成草稿，人执行	人	IDE 补全、文档助手
Chatbot（问答）	答，不动作	无	客服问答
Agent（单）	调工具、跑循环	Agent（低风险内）	单意图任务自动化
Multi-Agent（编排）	多个专精 Agent 协作	Control Plane + 各 Agent	复杂跨域工作流

关键区别：Agent 拥有"执行权"（能调工具、改状态），Multi-Agent 拥有"调度权"（能分解任务、派给专精 Agent、聚合结果）。一旦有了执行权，你就不能再把它当"文本生成器"——它是一段会影响真实系统的代码，需要和可观测、权限、回退、审批同等对待。

立论延伸：工具调用权限才是真正的风险，不是模型有多聪明。 一个跑错权限的 Agent，比一个"不太聪明"的 Agent 危险得多。便宜的约束（策略拦截）胜过昂贵的"请小心点"提示词。

---

2. 编排模式：别再扔"一袋 Agent"

2026 年生产部署里，绝大多数是几种可命名的拓扑。最危险的反模式是"bag of agents"（一袋代理）——把一群 Agent 甩给问题却没有定义拓扑。Towards Data Science 2026-01 分析：无结构多智能体系统，错误会在每次 handoff 处复合并放大，错误率可达单 Agent 的 17 倍。

所以选型第一原则：拓扑要刻意设计，不是哲学问题，由你的容错要求、可观测需求、成本模型驱动。

2.1 四种主导模式（覆盖 95% 生产）

模式	结构	最佳场景	优势	致命弱点
Single-agent looped	1 Agent + 多工具 + 1 循环	单意图、单结果、可独立完成的任务	易推理、易调试	受限于单 Agent 上下文与工具管理力
Supervisor / Hierarchical	1 主管分解→派给专精 Worker→聚合	分解清晰的复合任务（调研→综合→格式化）	单一责任点、易 human-in-the-loop、易审计	主管成瓶颈 + 单点故障；主管失误全传导
Sequential Pipeline	Agent 顺序链，后者收前者输出	线性、阶段明确（摄取→抽取→富化→存储）	简单、可调试、易埋点	无并行无提速；每阶单点失败毒化下游
Decentralized Swarm / P2P	Agent 点对点按 handoff 规则互调，无中心	无状态、 embarrassingly parallel（批量分类/富化）	无单点失败、横向扩展好	可观测噩梦，无中心状态机需分布式日志重建路径

此外还有 Parallel Fan-out with Merge（并行派发、合并输出，延迟最低）和 Mixed Topology（真实世界默认：管道中间夹一个 supervisor-workers，层级里某分支 fan-out 成小 swarm）。

2.2 用研究数据定默认

• Supervisor 是生产最常见默认：通信开销与 Agent 数呈线性关系，组织有单一可审计控制点。但 LangGraph 实测：supervisor 因"telephone game"问题（主管转述子 Agent 结果失真）初始比优化版差 50%；修复手法是 forward_message——让子 Agent 在结果终态时直传用户，绕开主管转述。
• Sequential Pipeline 最稳最便宜（大规模）：金融文档基准验证其在 10 万文档/天 下稳定，适合步骤真需固定顺序的高吞吐结构化流。
• Parallel Fan-out 延迟最低：任务能干净拆成独立并行子任务时优先（如同时从多个不相关数据源取数再合成）。
• Adaptive Topology 是高端方向：SWE-bench Verified 上，能按任务动态选 hybrid/parallel/hierarchical 的系统，比单一最佳固定拓扑高 22.9%；该 router 选 hybrid 62% / parallel 24% / hierarchical 14%。说明最成熟的系统正转向"按任务选拓扑"的编排层，而非全工作流绑死一种。

架构师口诀：从最简单能解决问题的拓扑起步，只在能量化收益时才加复杂度；多数团队起步高估了一档。最常踩的协调税——超过 4 个 Agent 阈值后，accuracy 增益平台期，通信开销开始侵蚀回报。

---

3. Control Plane 是什么：编排面 + 治理面

剥掉抽象，编排回答四个问题：谁下一步跑？传什么状态？失败怎么办？人何时介入？ 框架把前两个（谁跑、传什么）管得不错；后两个（失败恢复、人介入）通常是团队"发现框架不够用"的地方。

2026 年这套东西收敛成一个清晰分层——Control Plane（控制面），它把多个编排/治理模式叠成一层。vdf.ai 的七模式栈（它们彼此叠加，而非互斥）：

层	模式	职责
Coordination 协调	Orchestrator-worker / Supervisor	分解并派发工作
Knowledge 知识	RAG-grounded agents	把动作锚定在私有、有权限的数据上
Models 模型	Model Gateway	路由、治理、围住模型调用
Control 控制	Human-in-the-loop gates	高风险步骤强制人审批
Quality 质量	Evaluation loop	度量并防漂移
Evidence 证据	Observability & audit plane	捕获并留存溯源

这就是 B1 八层架构的"生产落地版"：B2 的 RAG = Knowledge 层，B3 的 MCP = 工具接入（被 Control 层治理），B4 的 Control Plane = 把协调/模型/人/质量/证据拧成一个可治理系统。有这层，是生产 Agent 平台；没有，是 POC。

---

4. 治理的第一刀：风险分级（Tier 0–4）

Control Plane 最实用的一招，是把 Agent 动作按风险分级，让组织能用同一套语言谈安全：

级别	动作	控制
Tier 0 只读	检索、搜索、摘要、看日志	无需审批
Tier 1 低风险写	起草工单、加标签、约会议	事后审计
Tier 2 业务影响写	权限变更、工作流编辑、面向客户配置	策略检查 + 抽样复核
Tier 3 高风险	生产部署、支付、破坏性操作	显式审批 + 回滚预案
Tier 4 不可逆/监管	留存策略、薪酬/HR、永久删除	双控 + 全审计轨迹

落地手法：autonomy 是个旋钮不是开关。低风险步骤让 Agent 自由跑，高风险步骤由平台强制审批——审批门是运行时控制、职责分离：Agent 提议、具相应角色的人批准、提议与决定都进审计轨迹。这就是"自动化的速度 + 不交出问责"。

---

5. Agent Contract：把治理写成代码

最被低估的工程实践——用一份 YAML Agent Contract 描述一个 Agent 的边界，存 Git、像代码一样评审、像服务一样部署。平台团队据此强制全局规则（日志无 PII、无静态 key、无意外写路径），产品团队保留工作流逻辑控制权。

agent:
  name: refund-assistant
  owner: finance-ops
  model_routing:
    default: small-fast
    escalate_on:
      tool_error_rate_gt: 0.05
      amount_usd_ge: 200
  budgets:
    max_steps: 12
    max_input_tokens: 12000
    max_output_tokens: 1500
    max_cost_usd_per_run: 0.75
  tools:
    allowlist:
      - name: zendesk.read_ticket
      - name: stripe.lookup_charge
      - name: stripe.create_refund
        requires_approval: true        # Tier 3 强制审批
  identity:
    mode: on_behalf_of                 # 以用户身份、最小权限
    token_ttl_seconds: 900             # 短时效凭证
  logging:
    trace_level: full
    pii_redaction: strict

配套用 OPA（Open Policy Agent） 做 deny-by-default 的策略拦截，把"请小心"变成"架构上很难危险"：

allow { input.action.type == "ticket.create" }
allow {
  input.action.type == "deploy.prod"
  input.approvals.count >= 1
  not input.change.includes["iam:PassRole"]
}
deny[msg] {
  input.action.type == "db.delete"
  msg := "Deletion actions require Tier 4 dual-control"
}

关键洞察：你可以容忍模型偶尔犯错，只要你的架构让它很难危险。 策略拦截 + 分级审批 + 短时效凭证，比换更聪明的模型更值钱。

---

6. 身份与权限：共享 key 是死路

Agent 当"运维账号"跑，是 2026 年最贵的一类事故来源。三条让 Agent 安全"无聊化"的规则：

1. 禁止变更类工具用共享静态 key——不过期就会流到错误的地方。
2. 读写路径分离——检索当查询、写入当事务，不同策略不同日志。
3. 不可逆动作设门——退款、删除、授权授予、生产部署，需显式审批（人或独立系统）。

身份层面：共享 key 死路，Agent 需专属身份 + 最小权限 scope + 短时效凭证（Vault / 云 KMS），绑定工作流与风险级。监管环境里，审计日志必须能回答：谁发起、系统计划了什么、执行了什么、系统记录变了什么——无需含糊其辞。

---

7. 可观测与评估：trace 替代直觉

最贵的失败是安静的：一个工具调用超时又重试、一次检索返回空触发长推理、一次 prompt 改动悄悄改变高吞吐流的工具用法。没有可见性，你只在账单暴涨或客户投诉后才发现。

Control Plane 把每次运行归一化成一个 schema 的 trace：选了哪个模型、token 进出、工具调用与延迟、重试/错误/回退、最终输出、是否被人工覆盖。用 OTel（GenAI 语义约定）+ LangSmith / Arize Phoenix / Whelm & Biases Weave 等收集，但控制面应归一化，否则答不出"哪个版本改了退款行为"。

评估是另一半：经典单测不覆盖随机输出，生产团队叠四道防线——(1) 严格工具 schema 校验；(2) 黄金集回归测试；(3) 自动裁判（常是另一个模型）判正确性/风格；(4) canary 灰度 + 快速回滚。

一句话：没有数据你只是又一个有观点的人（Deming）。 Control Plane 让你用证据而非 anecdote 发版。

---

8. 框架对比：框架跑 Agent，Control Plane 治理 Agent

2026 年主流编排框架（注意：框架 ≠ 控制面，框架跑 Agent，控制面管边界）：

框架	强项拓扑	适用	备注
LangGraph	有向图 + 类型化 state channel；supervisor、network、swarm 均一等公民	复杂有状态、需精确控制流	自带 create_supervisor / create_swarm；telephone-game 需 forward_message 修
CrewAI	Hierarchical process + role-based crews	角色化团队、快速搭	“Crew” 默认 supervisor
AutoGen / AG2	对话式 GroupChat（peer agents）	P2P 辩论、多视角评审	易 spiral，需收敛约束
Google ADK	agent tree + 内建 A2A	多 Agent + Agent 互调	A2A 一等公民
OpenAI Agents SDK	manager pattern（swarm 演进而来）	轻量 handoff	实验 Swarm 已被取代
Spring AI Agent	Java 栈、MCP 原生集成	后端团队、与现有 Spring 微服务共治	接 B3 的 MCP Server 自然

与协议栈的关系（回扣 B3）：MCP 是 Agent↔工具/数据层（主导），A2A 是 Agent↔Agent 互调层（Google 主导），Control Plane 治理两者。一个生产 Agent 系统同时用一整套协议，各占一层、互不替代。

---

9. 生产陷阱清单（下发版）

1. 别造 bag of agents：无拓扑多 Agent 错误率可放大 17x；拓扑刻意设计。
2. 协调税阈值：Agent 数 >4 后 accuracy 增益平台期，通信开销侵蚀回报——别为"多"而多。
3. Telephone game：supervisor 转述失真，初始可差 50%；终态结果用 forward_message 直传用户。
4. Swarm 先建分布式追踪：无中心状态机，失败靠分布式日志重建路径——没 tracing 别去中心化。
5. 起步低估一档：从 single-agent looped 起步，只在量化收益时升级。
6. 风险分级 Tier 0–4 + 审批门是运行时控制，不是 prompt 里"请审批"。
7. Agent Contract 入 Git：model_routing + budgets + tools allowlist + identity + logging，像代码评审、像服务部署。
8. 共享静态 key 禁令：读写分离、不可逆动作设门、短时效凭证。
9. 可观测先于一切：B6 细讲，但原则是"建它就便宜， retrofit 痛"。
10. 协议栈分层：MCP（工具）+ A2A（Agent 互调）+ Control Plane（治理），别混为一谈。
11. 监管合规：EU AI Act 要求可追溯/审计/模型文档/治理框架；高风险的金融/医疗/HR 动作需 human oversight。

---

10. 架构师决策框架

你的处境	推荐
单意图、单结果、一个 Agent 能扛	single-agent looped，先跑再谈升级
分解清晰的复合任务、要审计点	supervisor / hierarchical（最稳默认）
高吞吐、步骤固定顺序	sequential pipeline（10 万文档/天验证稳）
延迟是硬约束、可并行拆	parallel fan-out + merge
无状态批量、supervisor 成瓶颈	decentralized swarm（先备分布式 tracing）
跨域复杂、单一 supervisor 撑不住	hierarchical（supervisor of supervisors）
任何生产部署	Control Plane 优先：风险分级 + Agent Contract + OPA + 身份治理 + 可观测/评估，先于加 Agent 数量

最重要的元决策：先建 Control Plane 这个"铺好的路"（paved road：合理默认、快迭代、少事故），再让 Agent 上路。 多数组织已有底层组件（K8s/Serverless 跑 worker、OTel 收集 trace、OPA 判 allow/deny、Vault 管 secret），缺的只是给每次运行套一个统一信封：run ID、owner、principal、budget、policy context，贯穿每一跳。

---

11. 收尾与系列衔接

B4 把整条 B 线收束成一个生产系统：B2 的 RAG 是知识层、B3 的 MCP 是工具层、B4 的 Control Plane 是治理层——三者由编排面串成"多智能体 = 新型微服务"。你当年在微服务治理上学的每一课（可观测、重试、权限、审批、回退），在 Agent 世界原样适用，且因不确定性被放大。

下一站 B5《模型路由与成本——架构师的省钱放大器》：Control Plane 里的 Model Gateway 正是模型路由的落点——小模型做分类/结构化、大模型做推理，成本砍 60–80%；SLM+LLM 混合、按任务/置信度升级、预算护栏。这把本文 §5 的 model_routing 和 B1 的"模型无关抽象层"落到可量化的省钱动作。

回扣全系列：架构优先于模型（B1）。Control Plane 是这句话最硬的工程证据——你围绕模型建的治理架构，才是抄不走、能换模型、能抗事故的护城河。

---

下一篇预告：B5 · 模型路由与成本——Model Gateway 怎么做 SLM+LLM 混合、按置信度升级、预算护栏，把每一分钱花在刀刃上。