R

R02 用 Requisite Variety 估 Orchestrator 容量

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

你接到一个 agent 任务，第一个该问的问题不是”用哪个模型”，而是”这个 orchestrator 能不能在结构上控住这个任务”——而 Ashby 的必要多样性定律给了你一把粗糙但可算的尺子。本节要解决的问题是:在动手写 orchestrator 之前,如何用 variety(状态多样性)思路估一个任务需要多少”控制器多样性”(工具种类 × 上下文容量 × 可分支决策),并据此判断现有 orchestrator 配置是不是”先天不够”。框架名:Requisite Variety 容量估算表(下称 RV 估算)。这是一篇操作手册,不是理论复述——理论基础在本专题的概念层节点,这里只做一件事:把抽象的 V(R) ≥ V(D) 落成一张你能在选型会上填的表。

§0 为什么用 variety 估容量,而不是”试试看再说”

PM 面对 agent 任务的默认框架通常是两个:一是能力框架(“换更强的模型就行”),二是调参框架(“失败了就加 prompt、加重试”)。这两个框架都把失控当成”还不够努力”的问题。RV 估算挡掉的正是这个默认错误:Ashby 的定律说的是,如果调节器(regulator)的状态多样性小于扰动(disturbance)的状态多样性,控制在信息论上根本不可能完备——这不是”模型不够聪明”,而是”控制器的可表征状态空间装不下任务的状态空间”,是结构性约束。

Ashby 在《An Introduction to Cybernetics》(1956)里把这条定律和 Shannon 的信道容量定理(Theorem 10)直接对应:“The quantity of regulation that can be achieved is bounded by the quantity of information that can be transmitted in a certain channel.”(可达成的调节量,受限于某信道能传输的信息量。)翻译成 agent 工程的话:orchestrator 的控制能力上界 = 它能在上下文里可靠表征并区分的状态多样性。Context 不够 → requisite variety 不够 → 失控,这条因果链不是比喻,是信道容量的直接推论。

所以 RV 估算不预测”会不会成功”,它只回答一个否定性问题:这个 orchestrator 配置是不是注定不够?这是它的价值,也是它的边界(见 §5)——它能可靠地告诉你”不够”,但”够”只是必要条件,不是充分条件。

§1 三个 variety 来源:把”控制器多样性”拆成可数的三件

Ashby 的 variety 是个计数概念——“a set of possible states that a system may take”,可离散计数,不是隐喻(来源:Ashby 1956,Panarchy.org 原文节选)。要把它用在 orchestrator 上,先把”控制器的状态多样性”拆成三个可数维度:

维度物理含义怎么数(粗粒度)信息论近似
工具 variety V_toolorchestrator 能调用的动作种类工具数 × 每个工具的有效参数组合(取数量级)log₂(可区分动作数) bit
上下文 variety V_ctxorchestrator 能同时”看见并区分”的状态有效上下文窗口能稳定承载的独立信息片段数受 needle-in-haystack 衰减约束
分支 variety V_branch决策点上 orchestrator 能走的不同路径数每个决策节点的合法分支数 × 决策深度log₂(可达终态数) bit

控制器的总 variety 不是三者简单相加,而是受最短板约束:三者中任何一项不足,整体控制能力就被卡在那一项的上界。这正是 Stafford Beer 在 VSM(Viable System Model)里反复强调的——variety 必须在每一层、每个接口同时匹配,否则该层控制失效(来源:Beer《Brain of the Firm》1972;Wikipedia VSM)。Beer 给出的两个工具值得记牢:衰减器(attenuator) 减少流入控制器的 variety,放大器(amplifier) 增加控制器输出的 variety。后面 §3 的”省 variety”手段,本质都是这两个算子。

§2 估算框架:四步填一张表

RV 估算的核心是把”任务需要多少 variety”(V(D),扰动侧)和”orchestrator 有多少 variety”(V(R),调节器侧)分别估出来,比一比。

第一步:估扰动侧 V(D)——任务到底有多”野”

不要试图精确计算,取数量级即可。问三个问题:

  1. 任务过程中环境/工具会返回多少种质上不同的状态?(成功/各类失败/部分成功/需澄清……)
  2. 有多少种是 orchestrator 必须区分对待的?(能合并的算一种)
  3. 这些状态会组合吗?(若状态独立组合,variety 是乘法,会爆炸)

举例:一个”B2B 销售线索挖掘”任务(对照 m207 - Agent 产品化：场景推演与失败模式 的五步推演),Step 3”抓取并核实公司信息”的扰动状态大致有:网页正常返回、反爬拦截、信息缺失、信息冲突、信息过期、需要登录——6 种质上不同的扰动。若同时处理 N 家公司且状态独立,V(D) ≈ 6^N,这就是为什么并行抓取的 orchestrator 极易失控:扰动 variety 随并行度指数增长。

第二步:估调节器侧 V(R)——orchestrator 装得下多少

按 §1 三维度各取数量级,取最小项作为 V(R) 的实际上界(短板约束)。重点诚实评估 V_ctx:不要用标称窗口(1M token),要用有效窗口。公开测量显示,长上下文模型在远低于标称窗口处性能已显著下降(1M–2M 窗口模型在约 100K token 处性能下降超 50%),拒绝有害请求的概率也随上下文长度非单调变化(arXiv:2512.02445《When Refusals Fail》,已核实 2026-06-12)。把这条记进 V_ctx 的折扣里:有效 variety 远小于标称 variety。

第三步:比值与判读

余量 margin = V(R)_有效 / V(D)
  • margin ≥ 1:必要条件满足——orchestrator 在结构上可能控住(注意:仅可能,见 §5)。
  • 0.1 ≤ margin < 1:临界——单层 orchestrator 大概率不够,需用 §3 手段把 V(D) 衰减下来或把 V(R) 放大上去。
  • margin < 0.1:结构性不可控——别再调 prompt 了,换架构(分层/分治)。

第四步:若不够,选衰减还是放大

不够时有两条路,分别对应 Beer 的两个算子;衰减器/放大器在多层治理里的工程落地见本专题 R03 VSM 风格多层 Agent 治理模板(按 S1–S5 各层分配 variety 预算)。这里只给判据:优先衰减 V(D),其次放大 V(R)。因为放大 V(R)(加工具、加上下文、加分支)会同时放大 orchestrator 自身的失稳风险(见 §4);而衰减 V(D)(限制任务输入空间、预处理归一化、缩小动作面)几乎总是更便宜、更稳。

§3 判断主轴:估容量时 90% 的人会栽的四个坑

这是本节的命门。RV 估算用错,比不用更危险——因为它会给你一个虚假的安全感。四个高频错误,每个带”症状 → 为什么错 → 正确做法 → 真实反例”:

坑 1:用标称上下文窗口当 V_ctx

  • 症状:“我们用了 1M context,variety 肯定够。”
  • 为什么错:标称窗口 ≠ 可靠区分状态的有效窗口。Ashby 的信道容量约束看的是实际能无失真传输的信息量,被噪声淹没的状态不计入 variety。塞进去但读不准的上下文,不增加 V(R),只增加噪声。
  • 正确做法:V_ctx 用有效窗口(经验上打 3–10 倍折扣),并把”上下文污染”(context pollution)当作 V_ctx 的衰减项。
  • 真实反例:多 agent 系统失败模式研究(Cemri et al., arXiv:2503.13657, 2025;1600+ 标注轨迹,14 种失败模式)中,“上下文污染”是反复出现的失败原型之一——上下文被噪声充满,决策质量下降,恰是 V_ctx 看似很大、实则坍缩的表现。

坑 2:把 variety 当加法,忽略组合爆炸

  • 症状:“任务有 5 种工具、3 种状态,一共 8 种情况,小 case。”
  • 为什么错:扰动若独立组合,V(D) 是乘法不是加法。5 工具 × 3 状态 × N 并行 ≈ 15^N,而非 8。
  • 正确做法:估 V(D) 时先问”状态独立还是互斥”。互斥取加法,独立取乘法,有依赖的画状态机数实际可达终态。
  • 真实反例:同一研究里”无终止信号导致无限等待/循环”是最大一类失败——多个 agent 独立修改共享计划,推理上的微小差异被放大成不兼容分叉(incompatible forks)。这正是 V(D) 组合爆炸 + 缺停机条件(正反馈无负反馈钳制)的合体。

坑 3:把”加工具/加上下文”当免费午餐

  • 症状:“控制不住?那就再给 orchestrator 多挂几个工具、多给点上下文。”
  • 为什么错:放大 V(R) 会同时放大 orchestrator 自身的决策状态空间——它现在要在更大的空间里选对动作,选错的 variety 也变大了。这是 §4 要讲的失稳来源。
  • 正确做法:先用衰减器压 V(D)(归一化输入、限制动作面、预过滤),把”任务变简单”放在”控制器变复杂”之前。
  • 真实反例:IBM 研究者(Gorelkin, Medium, 2024–2025)把 Beer 的 VSM 用于企业 agentic 系统,明确指出完整 VSM 架构(多层放大/衰减)在按 token 计费下成本可能”令人望而却步”——放大 V(R) 不是免费的,既有钱的代价,也有失稳的代价。

坑 4:把 margin ≥ 1 当”会成功”

  • 症状:“算出来余量够了,可以上了。”
  • 为什么错:Conant-Ashby 的 Good Regulator 定理说,光有足够的状态数(数量约束)还不够,这些状态还必须与被控对象的状态形成映射——“Every good regulator of a system must be a model of that system”(Conant & Ashby, 1970, Int. J. Systems Science)。margin ≥ 1 只满足数量约束,不保证 orchestrator 内部”装的是对的状态”(结构约束)。
  • 正确做法:把 margin ≥ 1 当必要条件报告,绝不当充分条件。够了,只是”没被先天判死”,还要看 orchestrator 是否真的内含任务的有效模型。
  • 真实反例:Good Regulator 定理本身就有证明缺口的争议——批评者(如 Goker Erdogan, 2021)指出原论文的”model”更接近 RL 里的 policy(策略)而非 transition model(转移模型),且形式证明支持的结论比标题弱。所以连”有模型”这个充分性补丁,本身也不是铁律。诚实地说:RV 估算只能告诉你”不够”,不能担保”够了就行”。

§4 产品 PM 视角补盲:估容量看不见的三件事

跳出工程视角,RV 估算容易漏掉三个 PM 必须看的点:

  1. 用户心理模型的 variety 也是扰动:用户会用你没设计过的方式描述需求、中途改主意、给模糊指令。这些是 V(D) 里最难数的一块,且无法靠加工具解决——只能靠产品侧的输入约束(表单化、选项化)做衰减。把”用户多样性”漏算进 V(D),是 demo 能跑、上线就崩的常见原因。

  2. 放大 V(R) 的成本是真金白银:每加一个工具、每扩一截上下文,都是 token 成本 + 延迟。RV 估算给的是”要不要加”,成本核算(对照 m208 - AI 基础设施与中间件选型 的选型逻辑)给的是”加得起吗”。两张表要一起看:有时结构上需要更多 variety,但商业上养不起,这时正确答案是缩任务范围(衰减),不是硬上。

  3. 合规边界是不可放大的 V(D):有些扰动状态(违规请求、隐私边界)你不能用增加动作 variety 去”控制”,必须用硬性拒绝(把这些状态映射到单一终态)。这是 variety 工程里少见的”故意把 V(R) 在某方向上压到 1”的场景——不是装不下,是不该装下。

§5 对手框架回应:RV 估算到底能不能”算”

接受业界对必要多样性定律的两条主要批评,它们是对的:

其一,可操作性批评(Graham Berrisford 等长期指出):必要多样性定律逻辑严密,但”如何量化现实系统的 variety”没有标准答案,定律也不告诉你哪种结构最经济。这条批评直接打在 RV 估算的命门上——我承认:本节给的”数工具、数状态、数分支”是数量级估算,不是精确测量,误差可能一个数量级以上。

边界(我赌的是什么):即便如此,RV 估算仍有用,因为它服务的是否定性判断。要可靠地说”margin < 0.1,结构性不可控”,你不需要精确的 variety 值,只需要量级正确。一个 10⁶ 量级的 V(D) 配 10² 量级的 V(R),无论估算误差多大,结论都是”不够”。我赌的是:在 agent 工程里,判死比判活更有价值——它能在选型会上止损,挡掉那些注定要烧三个月预算才发现”架构选错了”的项目。

其二,LLM 是否真在”控制”的争议(本专题贯穿的开放问题):反方认为 LLM 本质是概率采样,不是动力系统,把它叫”调节器”是比喻而非工程意义上的稳定性保证。接受:RV 估算确实把 LLM-orchestrator 当作一个 Ashby 意义的调节器来估,这是一个建模选择,不是已证事实。边界:这个建模在”估容量上界”这个有限用途上是站得住的——因为 Shannon 信道容量约束对任何信息处理系统都成立,无论它内部是确定性还是概率性的。我不主张 LLM 是经典控制器,我只主张它的 variety 受信道容量约束,这一条够支撑 RV 估算了。

§6 跨域呼应:这把尺子量的是”可表征性”,不是”智能”

调度 Ashby 的信道容量约束(信息论 × 控制论的交汇点)作为本节的认识论支点。它改变的判断是:agent 失控的根因常被归错地方。

工程团队遇到 orchestrator 失控,默认归因是”模型推理能力不足”(认识论上,这是把问题归到”主体的智能”)。Ashby 的视角把归因从”智能”切换到”可表征状态多样性”(链入 0114认识论:这是一次从”能力本体论”到”信息论约束”的归因迁移)。同一个失控现象,在能力框架下是”换 GPT-5 就好”,在 variety 框架下是”控制器的状态空间装不下任务的状态空间,换更强的模型也只是把上界抬高一点点,治不了结构性短板”。

这个迁移的产品后果很实在:它把”无限堆模型能力”这条路打上了天花板标记——Ashby 告诉你,控制能力的上界是信道容量,不是模型聪明程度。在 0117社会学 的组织视角下,这正对应 Beer VSM 的核心洞见:可存活的系统靠结构(多层 variety 匹配)而非靠某个超级节点维持稳定。把这条用回 agent:与其追求一个全能 orchestrator,不如设计一个 variety 在各层都匹配的分治结构。

§7 PM 决策启示:三类场景怎么用

  • 面试:被问”怎么判断一个 agent 任务该不该用单个 orchestrator”,不要答”看任务复杂度”(空话)。答:“我会先估扰动侧 variety 和控制器侧 variety 的量级比——如果余量小于一个数量级,单层 orchestrator 结构上就不够,要么用衰减器缩小任务输入空间,要么分层。这是 Ashby 必要多样性定律的工程化:控制能力受信道容量约束,不是模型能力问题。” 一句话把”调参思维”升级成”结构思维”。
  • 选型:在选型会上填一张 RV 估算表(§2 四步),把 V(D)、V(R)、margin 三个量级写在白板上。这能把”我觉得够/不够”的口水仗,变成”量级差几个零”的事实判断。重点用它做止损:margin < 0.1 的方案直接砍,省下试错预算。
  • 复现:动手写 orchestrator 前(对照本专题最小可运行模板),先用 RV 估算判断该选哪一档架构——margin 足够选单层 ReAct 式;临界选带衰减器的单层;不足直接上分治/分层。让架构选择先于编码,而不是写完发现控制不住再返工。

§8 与已有节点的关系

  • 对 m207 - Agent 产品化：场景推演与失败模式 做深化:m207 给了六类失败模式和五步场景推演的”现象学”,本节给出其中”规划失败/无限循环/雪崩效应”三类的结构性诊断工具——用 variety 量级解释”为什么会循环/雪崩”,不复述失败模式清单本身。
  • 对 m208 - AI 基础设施与中间件选型 做对话:m208 算”加 variety 的钱够不够”,本节算”该不该加 variety、加多少”,两表合用。
  • 对 m206 - Agent 产品化：记忆机制与技术进展 做补缺:记忆机制本质是扩展 V_ctx 的一种手段(把状态外置到检索),本节给出”该扩多少”的容量判据,m206 给出”怎么扩”的技术实现。
  • 与 c11 - System 2 思维与 Test-Time Compute 互补:c11 讲”该不该多想”(算力维度的 variety),本节讲”该不该多控”(控制维度的 variety),两者都是”给 agent 多少资源”问题的不同切面。
  • 与 LLM repetition loop、幻觉 对照:repetition loop 是 V(R) 在生成侧坍缩(分布退化为单点循环),幻觉是 V(R) 看似很大但与真实状态失配(有 variety 无 model,对应 §3 坑 4)——两者都是”variety 估算”在生成层的微观对应物。

[!note] 我赌的边界 RV 估算是一把只能判死、不能判活的尺子(§5)。它对得起”结构性不可控”这个结论,对不起”够了就会成功”这个承诺。把它当止损工具,别当成功保证——这是我对它能力边界的诚实承担。

§9 修订日志

  • R1(2026-06-07):首稿。建立 RV 估算四步框架 + 三维 variety 拆解 + 四坑判断主轴 + 接受/边界双立场对手回应。Good Regulator 定理、Cemri 失败模式研究、Ashby 信道容量约束均接地;长上下文衰减具体数值标〔待核实〕。
  • 2026-06-12 内审修复:§2 长上下文衰减由〔待核实〕统一为已核实——arXiv:2512.02445《When Refusals Fail: Unstable Safety Mechanisms in Long-Context LLM Agents》经 WebFetch arXiv 摘要确证(1M–2M 窗口模型在 100K token 处良性与有害任务性能均降超 50%、拒绝概率非单调),补回论文名与编号并去除〔待核实〕标记。