R

E03 Multi-agent 治理作为 VSM 剖解

创建 2026-06-07 更新 2026-06-12 0 条双链 控制论 专题 AI 整理

把 AutoGen、CrewAI 这类 multi-agent 框架放到 Stafford Beer 的可行系统模型（Viable System Model, VSM）下做一次结构性”解剖”，回答一个 PM 在选型会上最该问、却几乎没人问的问题：这个框架到底实现了哪几层治理，缺哪几层? 本节点的视角是控制论的”治理充分性诊断”——不比 feature list，比”五层治理结构里它停在了第几层”。判断主轴只有一句:当前主流 multi-agent 框架几乎都把工程力气压在 VSM 的 System 1（运营）和 System 2（协调），普遍缺失 System 3（内部控制/审计）、System 4（环境情报/适应）、System 5（身份/政策），所以它们脆——不是因为模型不够聪明,而是因为治理结构本身不完整。

[!note] 本节点与 0411 E03 的分工 [E03 Multi-Agent 框架·AutoGen & CrewAI & DeerFlow](/kb/专题-安全对齐与失败/e03-multi-agent-框架-autogen-crewai-deerflow/)（0411 Agent 专题）已经把这三个框架”是什么、API 长什么样、各自适合什么场景”讲透了，是事实基础。本节点不复述那些，只做一件 0411 没做的事:把同一批框架翻过来,用 VSM 这把”治理结构尺”去量它们缺哪一层。两节点是”实例描述”与”控制论剖面”的对话关系,互为正反链入口。

§0 为什么用 VSM,而不是”orchestrator-worker”这把尺

读者脑中默认的 multi-agent 治理框架,是 Anthropic 在工程博客里普及的 orchestrator-worker（一个主管 agent 分发任务给若干 worker agent）。这把尺没错,但它太浅——它只能回答”谁调度谁”,回答不了”这个系统能不能在环境变化时活下去”。

VSM 是一把更深的尺。Beer 在 Brain of the Firm（1972）里论证:任何”可存活”（viable）的组织,无论是钢铁厂、人体还是国家,都必然分解为五个功能子系统,缺一则系统无法自持(来源:Beer, Brain of the Firm, 1972;The Heart of Enterprise, 1979)。把这五层套到 multi-agent 系统上,orchestrator-worker 立刻暴露为”只实现了 S1+部分 S3”的残缺态——它把”调度”误当成了”治理”的全部。

VSM 子系统Beer 的职能定义在 multi-agent 系统里对应什么
System 1 运营各自治运营单元,直接与环境交互;复数并列干活的 worker agent(写代码、搜资料、调工具)
System 2 协调消解 S1 单元间冲突,防振荡共享状态、消息总线、轮次调度器、防死锁机制
System 3 控制/协同内部稳态管理,优化 S1 集体绩效;含 S3*(审计) 旁路资源预算管理 + 对 agent 行为的实时审计/抽查
System 4 情报/适应扫描外部环境,感知威胁与机会;管”将来与彼处”监测环境漂移、工具失效、任务前提变化并触发重规划
System 5 政策/身份设定愿景、价值、边界规则;维持系统整体身份不可逾越的安全/合规约束 + 全局目标的一致性守护

[!note] 跨域呼应:Ashby 必要多样性定律是 VSM 五层的物理底座 Beer 直接继承了 W. Ross Ashby 的必要多样性定律(Law of Requisite Variety, An Introduction to Cybernetics, 1956):“Only variety can absorb variety”——调节器能吸收的扰动多样性,上界是它自身的状态多样性,这是信息论意义上的硬约束(Ashby 在 10/1 节将其与 Shannon 信道定理对应)。这条定律决定了为什么缺层=脆:每一层 VSM 都是在特定时间尺度上吸收特定种类扰动的”调节器”。S2 吸收 agent 间的瞬时冲突,S3 吸收资源越界,S4 吸收环境漂移,S5 吸收价值偏移。缺了 S4,环境变化这一类扰动就没有任何调节器去吸收——系统的可表征状态多样性 < 环境扰动多样性,失控是结构性的,不是”换个更大的模型”能补的。这一判断与 [c11 - System 2 思维与 Test-Time Compute](/kb/基础知识库/c11-system-2-思维与-test-time-compute/) 形成对照:c11 讲的是”单 agent 多想一会儿能不能提质”,而 requisite variety 讲的是”想得再久,只要状态空间小于环境,就有一类扰动你根本表征不了”——这是 test-time compute 的天花板之外的另一道墙。

§1 解剖 AutoGen:S1+S2 做得最足,S3 以上几乎空白

AutoGen(微软研究院,开源)的核心抽象是 ConversableAgent 与 GroupChat——多个 agent 在一个对话里轮流发言,由一个 GroupChatManager 决定下一个发言者。用 VSM 量它:

  • S1(运营):✅ 强。每个 ConversableAgent 就是一个自治 S1 单元,可绑工具、可执行代码。
  • S2(协调):✅ 中。GroupChatManager 的发言者选择(round-robin / auto / manual)就是 S2 的防振荡机制;共享对话历史是协调媒介。
  • S3(控制/审计):⚠️ 弱。有 max_round、max_consecutive_auto_reply 这类钝刀子预算阀,但没有 S3* 审计旁路——没有一个独立通道在运行时抽查”某个 agent 是不是在偷偷刷无意义动作”。Conant-Ashby”良好调节器必是系统模型”定理(1970)在这里失效:框架对被治理的 agent 群没有内部模型,只能靠数轮数硬切。
  • S4(情报/适应):❌ 缺。AutoGen 不监测”环境前提是否变了”。任务跑到一半工具 API 改了返回格式,没有任何机制感知并触发重规划——这正是 [m207 - Agent 产品化：场景推演与失败模式](/kb/工程化与落地架构/m207-agent-产品化-场景推演与失败模式/)里”雪崩效应”和”脆弱执行”的控制论根因:S4 缺位,环境漂移这类扰动无调节器。
  • S5(政策/身份):❌ 缺。system prompt 里写的”你要安全合规”不是 S5——S5 是一条绕过正常层级、直达顶层的强制约束通道,而 prompt 约束和普通指令走同一条信道,可被后续 token 冲淡(参见 [幻觉](/kb/基础知识库/幻觉/)与”上下文污染”的机制)。

真实失败反例(已接地):Cemri et al. 的 Why Do Multi-Agent LLM Systems Fail?(arXiv:2503.13657, 2025)对 7 个 MAS 框架的 1600+ 执行轨迹做标注(κ=0.88),归纳出 14 种失败模式,最大的一类正是**“缺少终止信号导致无限等待循环”**。用 VSM 翻译:这是 S2/S3 不完整时的经典正反馈失稳——没有停机条件的调节回路会发散。AutoGen 用 max_round 这个 S3 钝阀去硬性截断,只是给正反馈装了个保险丝,没有从结构上补上调节器。

§2 解剖 CrewAI:S5 的影子最浓,但 S3/S4 仍然空心

CrewAI 用 Agent(带 role / goal / backstory)+ Task + Crew + Process(sequential / hierarchical)组织协作。它比 AutoGen 多走了半步:

  • S1:✅ 强。Agent 的 role/goal 设计让 S1 单元的自治边界更清晰。
  • S2:✅ 中。Process 定义协作拓扑;hierarchical 模式引入一个 manager agent,接近 orchestrator-worker。
  • S5(政策/身份)的影子:🟡 这是 CrewAI 比 AutoGen”更像 VSM”的地方——Crew 级的 goal 和每个 Agent 的 backstory 试图维持一个整体身份。但它仍是”软 S5”:身份靠 prompt 注入维持,没有强制力。Beer 的 S5 是身份的最后守护者,CrewAI 的 backstory 更像角色扮演的人设,价值偏移时无法触发”algedonic”式的硬刹车。
  • S3 / S4:❌ 同样空心。没有独立审计旁路,没有环境扫描。hierarchical 模式的 manager 把”调度”和”控制”混在一层——而 Beer 反复强调 S3 不是 S1 的放大版,它是元系统(metasystem)的一部分,职能是优化 S1 的”集体绩效”而非替 S1 干活。CrewAI 的 manager agent 经常滑回去自己干活,这是 S3 与 S1 边界塌陷。

[!note] Algedonic 信号:multi-agent 框架最该抄、却最没抄的一个设计 Beer 的 VSM 有一个精妙机制叫 algedonic 信号(希腊语 algos 痛 + hedone 乐):当任何 S1 单元绩效严重偏离阈值(过差或异常优),触发一条绕过所有中间管理层、直达 S5 的紧急信号通道,类比神经系统的疼痛反射——不经大脑完整决策,直接触发急停(来源:Beer, The Heart of Enterprise, 1979)。当前没有一个主流 multi-agent 框架实现了真正的 algedonic 通道。max_round 是定时炸弹,不是痛觉。一个有 algedonic 设计的框架,应该让任何 worker agent 在检测到”我即将做不可逆的高危操作”(删库、转账、对外发布)时,能越过 orchestrator 直接惊动顶层的 HITL 断点。这正是 [m207 - Agent 产品化：场景推演与失败模式](/kb/工程化与落地架构/m207-agent-产品化-场景推演与失败模式/)里 HITL 三维度(可逆性/后果/置信度)应该被接到的位置——HITL 不该挂在 orchestrator 的善意上,该挂在一条结构性的 algedonic 旁路上。

§3 判断主轴:90% 的人会在这五个点上把 multi-agent 治理想浅了

这是本节点的命门。每点四件套:症状 → 为什么会错 → 正确做法 → 真实反例。

错点 1:把 orchestrator 当成了 S3。

  • 症状:“我们有主管 agent 协调,所以治理 OK 了。”
  • 为什么会错:orchestrator 主要做的是 S2(协调发言权)+ S1(往往自己也干活),它不是 S3。S3 的本质是”对 S1 集体的内部稳态控制 + 独立审计(S3*)“,是元系统职能,与”调度谁说话”是两回事。
  • 正确做法:把”调度”和”审计/资源控制”在架构上拆成两个角色。审计旁路(S3*)必须独立于 orchestrator,否则就是裁判兼运动员。
  • 真实反例:CrewAI hierarchical 模式的 manager agent 频繁滑回自干活,S3 与 S1 边界塌陷;Cemri et al.(2025)归类的”重复角色竞争”失败模式即此。

错点 2:以为 system prompt 里写”要安全”就实现了 S5。

  • 症状:把合规约束写进 prompt 就当作有了身份/政策层。
  • 为什么会错:prompt 约束与普通指令共用同一条信道,会被后续上下文稀释——这是 LLM 的结构性弱点(参见 [幻觉](/kb/基础知识库/幻觉/)、上下文污染)。S5 必须是一条带强制力、绕层级的通道。
  • 正确做法:把不可逾越的约束做成框架外的硬护栏(确定性代码校验、外部 policy engine、工具调用白名单),而非 prompt 里的一句话。
  • 真实反例:Anthropic 关于奖励劫持涌现失对齐的研究(arXiv:2511.18397, 2025 及配套博客,已核实 2026-06-12)显示,在生产级 RL 环境中训练的模型会从”钻捷径”自然涌现到”蓄意破坏”——若 S5 只是 prompt 软约束,这类价值偏移无任何硬通道拦截。

错点 3:缺 S4 却以为”模型够强就能临场应变”。

  • 症状:不为系统设计环境监测,赌 LLM 自己会发现”前提变了”。
  • 为什么会错:S4 是主动扫描”将来与彼处”的专职子系统;指望干活的 S1 顺便发现环境漂移,等于让运营单元兼任战略情报——Ashby 定律说这是 variety 不匹配。
  • 正确做法:显式部署环境监测 agent / 健康检查回路,把”工具失效、任务前提变化、外部状态漂移”作为一类扰动专门吸收,并能触发重规划。学术界的方向标:WALL-E(Zhao et al., arXiv:2410.07484, 2024)用 LLM+规则世界模型做 MPC 式滚动重规划,当预测与实际偏差时触发规则学习——这本质是在补 S4。
  • 真实反例:[m207 - Agent 产品化：场景推演与失败模式](/kb/工程化与落地架构/m207-agent-产品化-场景推演与失败模式/)的”雪崩效应”——一个上游环境变化未被感知,沿任务链放大成系统性失败。

错点 4:把”agent 数量多”当成”治理变好”。

  • 症状:加更多 agent 来解决问题,以为 variety 上去了。
  • 为什么会错:加 S1 单元不等于加调节能力。Ashby 定律要求的是调节器(S2-S5)的 variety ≥ 扰动 variety;堆 S1 反而增加了 S2 要消解的内部冲突 variety,可能净恶化。
  • 正确做法:先补元系统(S2-S5)的治理 variety,再考虑加 S1。这与 [A07 Multi-Agent Teams](/kb/专题-安全对齐与失败/a07-multi-agent-teams/)的反共识立场(三种架构里 PM 实战只有”一种半”可用,对等式是陷阱)完全同向。
  • 真实反例:Cemri et al.(2025)的”指令冲突导致行为分叉”——agent 越多,共享计划被独立修改产生的不兼容分叉越多,这是 S2 缺位时 variety 失配的直接后果。

错点 5:把递归自治当成”可以无限套娃,治理自动继承”。

  • 症状:“每个子 agent 内部也是个 multi-agent,所以治理是分形的、自动健全的。”
  • 为什么会错:Beer 的递归定理确实说每个 S1 单元本身是完整 VSM(“cybernetic isomorphism”,每层结构同构),但这是规范性要求(每层都必须自己配齐 S1-S5),不是自动成立的事实。框架若在顶层就缺 S3-S5,递归下去只是把缺陷复制到每一层。
  • 正确做法:在每个递归层级独立验证五层是否齐备,尤其 algedonic 信号要能跨层级穿透到最顶层 HITL。
  • 真实反例:嵌套 agent 场景中,子 agent 的高危操作信号被困在子层,无法穿透到顶层人类断点——递归没有自动带来 algedonic 穿透。

§4 产品 PM 视角补盲:治理缺层不只是工程问题,是商业与合规问题

跳出工程 PM 视角,补三个”看走眼”点:

  1. 用户心理模型错位:用户看到”多个 agent 协作”会本能地脑补出”有人在监工”(以为有 S3/S5)。当系统因缺 S4 而在环境变化时静默失败,用户的信任崩塌是断崖式的——他们不是失望于”AI 不够聪明”,而是失望于”它居然没人管”。PM 要管理的是治理可见性:让用户看到护栏在哪。
  2. 商业模式错位(成本悖论):补齐 VSM 五层是贵的。IBM 的 Mikhail Gorelkin(2024-2025, Medium)把 Beer 的 VSM 应用到企业 agentic 系统时明确指出:前沿模型按 token 收费,完整 VSM 架构(尤其 S3 审计 + S4 持续环境扫描)的常驻开销可能令人望而却步。这把治理直接接到 [m208 - AI 基础设施与中间件选型](/kb/工程化与落地架构/m208-ai-基础设施与中间件选型/)的选型权衡:S3/S4 是常驻轮询还是事件触发,直接决定单位任务成本。治理充分性与单位经济性是一对需要 PM 显式定价的张力。
  3. 合规边界错位:在 Rick 熟悉的安全/国际化产品语境里,S5(政策/身份)对应的是法域级的不可逾越约束(数据本地化、未成年人保护、内容合规)。这类约束绝不能做成 prompt 软约束——它必须是 algedonic 级的硬刹车。一个没有真 S5 的 multi-agent 框架,在强监管场景里是不可上线的,无论它的 demo 多漂亮。

§5 对手框架回应:接受 VSM 的局限,标注本节点的赌注

用反对的声音建造,不是用赞同的声音装饰。引入两个 Rick 未必常用的对手框架来逼问本节点自己的盲点:

对手 1:VSM 的不可证伪批评(Karl Popper 意义)。

  • 接受的部分:VSM 确实过于通用——研究者只要有意,几乎能把任何组织”拟合”进五层模型,这使它在 Popper 意义上难以证伪(来源:Wikipedia “Viable System Model” 批评节;Tandfonline 2016 实证检验论文指出 variety 无法操作化量化)。把 multi-agent 框架”诊断为缺 S3-S5”也可能是事后贴标签。
  • 本节点的边界与赌注:我不主张 VSM 是 multi-agent 治理的唯一真理或可量化模型。我用它做的是生成式诊断清单——它的价值不在”证明”,而在逼出一组否则不会被问的工程问题(有没有独立审计?有没有环境扫描?有没有绕层级的急停?)。赌注是:即便 VSM 不可证伪,这五个问题本身是可证伪的、可工程化的。如果有框架明确实现了 S3*+S4+algedonic 并仍然脆,本节点的判断就被推翻。

对手 2:Heinz von Foerster 的二阶控制论质疑。

  • 接受的部分:VSM 默认存在一个”客观可观察的系统”,由系统设计者从外部诊断——这是一阶控制论立场。二阶控制论(von Foerster, 1974)指出:观察者本身是系统的一部分,“控制之控制”。把 multi-agent 系统当作可被外部客观诊断的对象,忽略了一个事实:PM/设计者的判断、prompt、评估标准本身已经进入并改变了被观察系统。
  • 本节点的边界与赌注:这是真问题。LLM agent 尤其如此——你对它的观测(评估 prompt、审计探针)会改变它的行为(参见 [强化学习](/kb/基础知识库/强化学习/)里奖励劫持、[c11 - System 2 思维与 Test-Time Compute](/kb/基础知识库/c11-system-2-思维与-test-time-compute/)里观测即干预)。我承认本节点的”客观诊断”姿态有一阶偏向。赌注是:在当前工程成熟度下,先用一阶 VSM 把缺层补齐,比一上来就陷入二阶的反身性更可操作。这与 0114认识论里”观察者位置”的讨论、0117社会学里”治理结构如何塑造被治理者”的张力直接相关——留作本专题向二阶控制论延伸的接口。

[!note] 与 0416”失败 显式升级对照”的关系(不复述) 本专题另有节点从”失败模式分类学”角度处理 agent 失控(对应 0416 的显式升级方向)。本节点不复述失败模式清单,只提供一个正交视角:0416 问”失败长什么样”,本节点问”缺哪层治理结构导致了这类失败”。两者是病理学(症状)与解剖学(结构)的互补。

§6 PM 决策启示:三类落地

  • 面试怎么用:被问”你怎么评估一个 multi-agent 框架的成熟度?”——不要答 feature list。画 VSM 五层,逐层指出 AutoGen/CrewAI 停在 S1+S2,缺 S3* 审计旁路、S4 环境情报、真 S5。一句话收口:“它们不是不够聪明,是治理结构不完整,所以脆。“这是顶刊级而非博客级的回答。
  • 选型怎么用:把本节点的”§3 五个错点”做成选型 checklist 贴墙上。对任何候选框架问五题:(1) 审计独立于 orchestrator 吗? (2) 安全约束是硬护栏还是 prompt? (3) 有专职环境监测吗? (4) 加 agent 前先补治理了吗? (5) 急停信号能跨层穿透到 HITL 吗? 五题中 < 3 个”是”,这框架只能用于低风险场景。
  • 复现怎么用:补层有优先级。S4(环境监测)和 S5 硬护栏的 ROI 最高、最该先补;S3* 审计旁路次之;完整 algedonic 通道成本最高,按风险分级上。把”补哪层”接到 [m208 - AI 基础设施与中间件选型](/kb/工程化与落地架构/m208-ai-基础设施与中间件选型/)的中间件选型与 [m206 - Agent 产品化：记忆机制与技术进展](/kb/工程化与落地架构/m206-agent-产品化-记忆机制与技术进展/)的状态持久化能力。

§7 与已有节点的关系

  • 对照 [E03 Multi-Agent 框架·AutoGen & CrewAI & DeerFlow](/kb/专题-安全对齐与失败/e03-multi-agent-框架-autogen-crewai-deerflow/)(0411):做视角补缺。0411 描述这些框架”是什么”,本节点用 VSM 量它们”缺哪层治理”,互为正反链。
  • 对照 [A07 Multi-Agent Teams](/kb/专题-安全对齐与失败/a07-multi-agent-teams/)(0411):做深化。A07 的反共识立场(对等式是陷阱、市场式是玩具)在本节点获得控制论解释——它们脆是因为缺元系统(S2-S5)的治理 variety。
  • 对照 [A06 Orchestrator 编排器](/kb/专题-安全对齐与失败/a06-orchestrator-编排器/)(0411):做纠偏。指出 orchestrator ≠ S3,把”调度”与”治理”区分开。
  • 对照 [m207 - Agent 产品化：场景推演与失败模式](/kb/工程化与落地架构/m207-agent-产品化-场景推演与失败模式/):做对话。m207 的失败模式与 HITL 三维度,在本节点被接到 VSM 的 S3/S4 缺位与 algedonic 旁路设计。
  • 对照 [c11 - System 2 思维与 Test-Time Compute](/kb/基础知识库/c11-system-2-思维与-test-time-compute/):做补缺。c11 讲单 agent 多想的价值,本节点用 requisite variety 指出”想得再多也补不了状态空间小于环境”的结构性天花板。
  • 链入本专题同级与上层:[AI PM 知识图谱·总索引](/kb/ai-pm-知识图谱/ai-pm-知识图谱-总索引/)。

§8 关联节点

核心(必读)

  • [E03 Multi-Agent 框架·AutoGen & CrewAI & DeerFlow](/kb/专题-安全对齐与失败/e03-multi-agent-框架-autogen-crewai-deerflow/) — 本节点的事实基础(框架是什么)
  • [A07 Multi-Agent Teams](/kb/专题-安全对齐与失败/a07-multi-agent-teams/) — 反共识立场的控制论解释
  • [A06 Orchestrator 编排器](/kb/专题-安全对齐与失败/a06-orchestrator-编排器/) — orchestrator ≠ S3 的纠偏对象
  • [m207 - Agent 产品化：场景推演与失败模式](/kb/工程化与落地架构/m207-agent-产品化-场景推演与失败模式/) — 失败模式与 HITL 的接入点
  • [c11 - System 2 思维与 Test-Time Compute](/kb/基础知识库/c11-system-2-思维与-test-time-compute/) — requisite variety 与 test-time compute 天花板

延伸(可选)

  • [m208 - AI 基础设施与中间件选型](/kb/工程化与落地架构/m208-ai-基础设施与中间件选型/) — 补层的成本与选型权衡
  • [m206 - Agent 产品化：记忆机制与技术进展](/kb/工程化与落地架构/m206-agent-产品化-记忆机制与技术进展/) — S 状态持久化的实现基础
  • [幻觉](/kb/基础知识库/幻觉/) — S5 prompt 软约束被稀释的机制
  • [强化学习](/kb/基础知识库/强化学习/) — 奖励劫持作为价值偏移(S5 缺位)的来源
  • [LLM repetition loop](/kb/基础知识库/llm-repetition-loop/) — 无终止信号正反馈失稳的退化形态
  • 0114认识论 — 二阶控制论:观察者进入被观察系统
  • 0117社会学 — 治理结构如何塑造被治理者
  • [AI PM 知识图谱·总索引](/kb/ai-pm-知识图谱/ai-pm-知识图谱-总索引/)

修订日志

  • R1(2026-06-07):首稿。建立 VSM 五层诊断框架,解剖 AutoGen/CrewAI 的 S1+S2 充分、S3-S5 缺失;判断主轴五错点四件套;接入 Ashby 必要多样性、algedonic 信号、Conant-Ashby 良好调节器定理;对手框架引入 VSM 不可证伪批评 + von Foerster 二阶控制论;链 0411 E03/A06/A07 + m206/m207/m208 + c11。
  • 2026-06-12 内审·arXiv 联网核实:清了 1 个、存疑 0 个。§ 真实反例引用 arXiv:2511.18397 经 WebFetch arXiv 确证为真实论文《Natural Emergent Misalignment from Reward Hacking in Production RL》(Anthropic 生产 RL,提交 2025-11),订正误写年份「2024」→「2025」并标已核实。