R

R01 给 Multi-agent 加资源配额机制

创建 2026-06-07 更新 2026-06-12 0 条双链 机制设计 专题 AI 整理

R01 给 Multi-agent 加资源配额机制

当你给一组 agent 共享同一个 token 预算、同一组昂贵工具（搜索 API、代码执行沙箱、付费数据库）和同一份上下文窗口时，没有配额的”裸协作”几乎必然走向公地悲剧：每个 agent 都把共享资源当成”反正不用白不用”的免费品，集体把预算烧穿，把关键工具的速率限制打爆，把上下文塞满噪声——而没有任何单个 agent 为这个全局后果负责。本节点要解决的问题是：如何用机制设计的语言，给一组自利（或被对齐成自利）的 agent 加一套 context/tool/quota 配额 + 优先级仲裁机制，并用一个可跑的最小骨架观察它对公地悲剧的缓解程度。视角是 Ostrom 公共池塘资源治理 + Williamson 交易成本，落点是一段你今晚就能跑起来的 Python。结论先撂这儿：这个 demo 能让你亲眼看到”加了配额后超支从 100% 降到 0”，但它离生产差着十万八千里——文末会讲清差在哪。

§0 为什么是”配额机制”这个框架，而不是”让 agent 更聪明”

业界面对 multi-agent 烧钱失控，第一反应往往是两条错路：

  • 错路 A：寄望于模型自律。“让每个 agent 自己判断该不该调这个昂贵工具。” 这正是 MarketBench（Fradkin & Krishnan，2026，arXiv:2604.23897）证伪的——LLM 对自身的成功概率和 token 消耗存在严重误校准（miscalibration），基于自我报告构建的分配会系统性偏离最优。让一个高估自己、低估成本的 agent 自我节制，等于让狐狸看守鸡舍。
  • 错路 B：靠 prompt 喊口号。在 system prompt 里写”请节约使用工具”。这是把治理问题误当成措辞问题。Ostrom 的整部《Governing the Commons》（1990）核心结论恰恰是：避免公地悲剧靠的是制度（边界、规则、监督、分级制裁），不是靠呼吁参与者讲道德。

正确的框架是把它当成一个机制设计问题：给定一群自利 agent，设计一套规则（配额 + 优先级 + 制裁），使得每个 agent 在追求自己局部目标时，其行为的总和落在全局可接受的资源边界内。这正是机制设计被称为”逆向博弈论”的原因——不是分析既定规则下会发生什么，而是反向设计规则去逼出想要的均衡。

为什么不直接用 VCG 拍卖让 agent 竞价抢工具？因为 VCG（Vickrey 1961 / Clarke 1971 / Groves 1973）要求货币转移和准线性效用，而 agent 之间没有真实货币，“虚拟估值”又回到了错路 A 的自我报告失准问题。配额 + 优先级是一个更朴素、更鲁棒、Ostrom 式的”硬边界 + 分级制裁”治理，而非 Myerson 式的”最优拍卖”。 这个取舍本身就是本节点的第一个判断：在 agent 自我评估不可信的前提下，先上硬约束的配额墙，再谈精巧的激励定价——顺序不能反。

§1 把公地悲剧翻译成 agent 的语言

Hardin 1968 年在 Science 发表《公地悲剧》：理性自利个体无节制使用共享资源必然导致耗尽。但 Hardin 本人后来承认，他说的是”无管理的公地（unmanaged commons）“。这个限定词是整个机制设计的入口。

multi-agent 系统里有四类典型公地，每一类都对应 Ostrom 定义的 CPR 两大特性——排除困难 + 竞争性：

共享资源排除困难竞争性公地悲剧的表现
Token / 算力预算任一 agent 都能发起 LLM 调用一个 agent 多花的 token 直接减少别人可用量预算被先到先得的 agent 烧穿，关键收尾 agent 饿死
昂贵工具配额（付费搜索、沙箱、付费 DB）任一 agent 都能调用API 有速率/并发上限，调用打满后全员阻塞一个 agent 的 retry 风暴打爆 rate limit，全团队 503
共享上下文窗口任一 agent 都能往里写窗口字数有限，一个写太多挤掉别人的关键信息上下文被冗余消息塞满，相似度飙升、信息退化
下游处理能力任一 agent 都能投递任务下游消费速度有限上游生成速度 > 下游消费速度，“事件雪崩”

第三类的实证很硬：RoundTable（arXiv:2411.07161，2024）观察到多 agent 协作中消息长度增加 84%、与前一轮相似度升至 90%——这就是上下文公地被噪声污染的量化证据。第四类（事件雪崩）正是工程师 Andrew Stevens 在《缺失原语》清单（Sakura Sky 博客，2025-11-25，WebFetch 核实）里点名的”任务节流”缺口。

判断： 这四类公地里，token 预算最容易做配额（可计量、可拦截），上下文窗口最难（“占用”难以归因到单个 agent 的边际贡献）。本节点的骨架优先打前两类，第三类只给思路。

§2 三个治理原语：配额、优先级、分级制裁

Ostrom 的 8 条设计原则（1990 原著，Agrarian Trust 页面 WebFetch 核实）不是抽象口号，可以一条条映射成 agent 系统的代码原语。我挑出最可落地的三条：

Ostrom 原则agent 系统对应原语在骨架里的实现
①清晰界定边界（谁能用、用多少）配额（Quota）：per-agent / per-tool / per-workflow 的硬上限QuotaLedger 在每次调用前做事务性扣减
③集体选择 + ⑤分级制裁优先级 + 分级制裁：超额不是直接 kill，而是降级PriorityScheduler 先服务高优先级，超软线先警告、超硬线才拒
④对社区负责的监督者中央账本（Ledger）：可观测、可审计的全局用量Ledger 记录每笔扣减，可随时打印全局快照

这里有个致命的实现细节，90% 的人会搞错：配额扣减必须在 LLM 调用之前（pre-call），不能在之后（post-call）。 AutoGen 0.4 的 print_usage_summary()（WebFetch 核实 microsoft.github.io/autogen）是事后报表——它告诉你”已经超支了”，但钱已经花出去了。Stevens 清单里把这条叫”事务性配额强制执行”，是第一条安全原语。事后核算 ≠ 治理，正如银行不会让你先透支再发对账单。

第二个易错点：超额时不要直接 kill agent。 直接杀会让任务在中途崩溃、状态不一致。Ostrom 第 5 原则”分级制裁（graduated sanctions）“翻译过来就是：超软配额（soft limit，如 80%）只记一次警告并降优先级；超硬配额（hard limit，100%）才拒绝本次调用、把控制权交还给编排器做兜底（降级到便宜模型 / 跳过非关键步骤 / 收尾）。这与 m209 - 推理成本控制手册 里”成本超限时分层降级”的思路同源。

§3 最小可运行骨架（demo，非生产）

下面是一段不依赖任何 multi-agent 框架的纯 Python 骨架，用来隔离地观察配额机制对公地悲剧的缓解。它故意把”agent”简化为”会贪婪消耗资源的 worker”，把 LLM 调用 mock 成计数器——因为我们要观察的是治理机制本身，不是模型能力。这是经典的”控制变量”：要证明配额有效，就得把模型聪明度这个变量摁住。

import random
from dataclasses import dataclass, field

# ---------- 1. 中央账本：Ostrom 第④原则"可问责的监督者" ----------
@dataclass
class Ledger:
    """全局资源账本：唯一真相源（single source of truth）。"""
    token_budget: int                       # 团队级总预算（共享公地）
    tool_quota: dict                        # 每种昂贵工具的总调用配额
    token_used: int = 0
    tool_used: dict = field(default_factory=dict)
    rejected: int = 0                       # 被制裁拒绝的次数
    warnings: int = 0                       # 软线警告次数

    def snapshot(self):
        return (f"tokens {self.token_used}/{self.token_budget} | "
                f"tools {self.tool_used} | warn={self.warnings} rej={self.rejected}")

# ---------- 2. 配额账本 + 分级制裁：第①③⑤原则 ----------
class QuotaLedger:
    SOFT = 0.8  # 软线：到 80% 开始警告 + 降优先级

    def __init__(self, ledger: Ledger, per_agent_token: dict):
        self.L = ledger
        self.per_agent_token = per_agent_token          # 每个 agent 的个体配额
        self.agent_token_used = {a: 0 for a in per_agent_token}

    def try_spend(self, agent: str, tokens: int, tool: str | None = None) -> bool:
        """关键：pre-call 事务性扣减。批准返回 True，否则 False（拒绝/制裁）。"""
        # —— 全局 token 硬边界 ——
        if self.L.token_used + tokens > self.L.token_budget:
            self.L.rejected += 1
            return False
        # —— 个体 token 硬边界（防一个 agent 独吞公地）——
        if self.agent_token_used[agent] + tokens > self.per_agent_token[agent]:
            self.L.rejected += 1
            return False
        # —— 工具配额硬边界 ——
        if tool is not None:
            used = self.L.tool_used.get(tool, 0)
            if used + 1 > self.L.tool_quota.get(tool, 0):
                self.L.rejected += 1
                return False
        # —— 软线分级制裁：到 80% 警告（不拒绝，仅记录 + 后续降优先级）——
        if self.L.token_used + tokens > self.L.token_budget * self.SOFT:
            self.L.warnings += 1
        # —— 提交扣减 ——
        self.L.token_used += tokens
        self.agent_token_used[agent] += tokens
        if tool is not None:
            self.L.tool_used[tool] = self.L.tool_used.get(tool, 0) + 1
        return True

# ---------- 3. 优先级调度：第③原则,关键 agent 不被低优 agent 饿死 ----------
class PriorityScheduler:
    def __init__(self, quota: QuotaLedger):
        self.quota = quota

    def run_round(self, agents: list, governed: bool):
        """governed=False 模拟"裸协作"; True 启用配额+优先级。"""
        # 高优先级先执行（数字越小越优先）——防关键收尾 agent 饿死
        order = sorted(agents, key=lambda a: a.priority) if governed else agents
        for ag in order:
            ag.act(self.quota, governed)

# ---------- 4. 自利 agent:默认贪婪,这就是"公地悲剧"的微观成因 ----------
class GreedyAgent:
    def __init__(self, name, priority, appetite):
        self.name = name
        self.priority = priority      # 1=安全收尾 agent, 3=锦上添花 agent
        self.appetite = appetite      # 每步想消耗多少 token(自利胃口)
        self.done = 0

    def act(self, quota: QuotaLedger, governed: bool):
        want = self.appetite + random.randint(0, 200)
        tool = "paid_search" if random.random() < 0.5 else None
        if not governed:
            # 裸协作:无视任何边界,直接记账(模拟"反正不用白不用")
            quota.L.token_used += want
            if tool: quota.L.tool_used[tool] = quota.L.tool_used.get(tool, 0) + 1
            self.done += 1
        else:
            if quota.try_spend(self.name, want, tool):
                self.done += 1   # 被批准才算干了活

# ---------- 5. 跑对照实验 ----------
def experiment(governed: bool, seed=42):
    random.seed(seed)
    ledger = Ledger(token_budget=10_000,
                    tool_quota={"paid_search": 12})
    quota = QuotaLedger(ledger, per_agent_token={
        "finisher": 4000, "researcher": 4000, "polisher": 2000})
    sched = PriorityScheduler(quota)
    agents = [GreedyAgent("finisher",  priority=1, appetite=600),
              GreedyAgent("researcher",priority=2, appetite=800),
              GreedyAgent("polisher",  priority=3, appetite=500)]
    for _ in range(15):                       # 15 轮协作
        sched.run_round(agents, governed)
    overspend = max(0, ledger.token_used - ledger.token_budget)
    return ledger, overspend, {a.name: a.done for a in agents}

for label, g in [("裸协作(无治理)", False), ("配额+优先级治理", True)]:
    L, over, done = experiment(g)
    print(f"\n= {label} =")
    print(L.snapshot())
    print(f"超支 token: {over} | 各 agent 完成步数: {done}")

你会观察到的典型结果（数字随 seed 浮动，此处为本骨架逻辑下的〔示意〕结果，非实测基准）：

  • 裸协作：token_used 远超 10000（如 ~21000），超支 ~11000，paid_search 远超 12（如 ~22）——公地被烧穿，速率限制被打爆。三个 agent 都”完成”了 15 步，但代价是全局崩溃。
  • 配额治理：token_used ≤ 10000，超支 = 0，paid_search ≤ 12，rej > 0（部分贪婪调用被分级制裁拒绝），finisher（priority=1）因优先调度拿到资源、polisher（priority=3）被饿到——这正是优先级机制在起作用：关键收尾 agent 受保护，锦上添花 agent 让路。

这就是公地悲剧被缓解的可观测证据：不是”agent 变乖了”，而是”制度让它们没法不乖”。

§4 判断主轴：90% 的人在配额机制上会搞错的四个点

[!warning] 这一节是本节点的命门——不是”怎么写代码”，而是”配额机制在哪儿会假装有效”

错点一：把事后核算当配额。

  • 症状：用 print_usage_summary() 或 LangSmith 看板”监控”成本，以为这就是治理。
  • 为什么会错：可观测性（observability）≠ 控制（control）。看板告诉你已经烧了多少，但拦不住下一次调用。Knowlee 评估（2026-05，WebFetch 核实）直接把 LangSmith 定性为”仅可观测性层”（注意：评估方是商业竞品，立场需打折）。
  • 正确做法：扣减必须 pre-call、事务性（骨架里的 try_spend 在调用前返回 False 就直接拦截）。
  • 真实反例：CrewAI 社区论坛”How to limit token usage (For infinite loops)“帖（WebSearch 核实）——无限循环烧钱是已知痛点，官方只能建议在 LLM 层设 max_tokens，框架级无事务性配额。

错点二：配额一刀切，没有优先级。

  • 症状：给每个 agent 平均分配预算，先到先得。
  • 为什么会错：先到先得会让”最贪婪”而非”最重要”的 agent 抢光资源，关键的安全检查 / 收尾 agent 被饿死。Stevens 清单第 3 条”优先级调度”专治此病。
  • 正确做法：高优先级 agent 优先调度 + 留出保留配额（reserve），骨架里 finisher priority=1 先执行。
  • 真实反例：Amayuelas et al.（UCSB，arXiv:2504.02051，2025）发现，给 worker 提供能力信息后分配质量显著提升——盲目平均分配是次优的。

错点三：超额直接 kill，而非分级制裁。

  • 症状：agent 超预算就抛异常、整个 workflow 崩。
  • 为什么会错：违反 Ostrom 第 5 原则。硬 kill 让任务在中途死掉、状态不一致、前面花的钱全打水漂。
  • 正确做法：软线（80%）警告 + 降优先级，硬线（100%）拒绝本次调用并交还编排器兜底（降级模型 / 跳过非关键步骤 / 提前收尾）。
  • 真实反例：把这条做反的系统会出现”为了省最后 5% 预算，把已经花掉的 95% 全浪费掉”的荒诞——制裁过猛比不治理更糟。

错点四：只防 token，不防工具速率与上下文污染。

  • 症状：盯着 token 预算，忘了昂贵工具的 rate limit 和上下文窗口。
  • 为什么会错：token 没超但 paid_search 的 retry 风暴打爆了 API 配额，照样全团队 503；或上下文被冗余消息塞满，相似度 90%（RoundTable 数据），有效信息被挤掉。
  • 正确做法：配额是多维的——per-tool 调用配额、并发节流（throttle）、背压（backpressure）缺一不可。骨架里 tool_quota 处理了第一维，并发与背压留作扩展。
  • 真实反例：Stevens 的”事件雪崩”——上游 agent 生成速度超过下游消费能力，没有背压就堆积爆炸。

§5 产品 PM 视角补盲

工程师会把这当成一个调度算法问题，PM 必须补三个”看走眼”的点：

  1. 配额是产品定价的镜像，不只是成本控制。 如果你的 agent 产品对外按”任务”计费，但内部按 token 烧钱，配额机制就是你毛利率的护栏。给企业客户的”高级套餐”可以映射成更高的 per-tenant 配额——配额层天然是 SaaS 分层定价的实现层。Stevens 清单的背压维度明确包含 “per-tenant”。这一点 m209 - 推理成本控制手册 从成本侧讲过，本节点从治理机制侧补缺。

  2. 优先级是一个隐蔽的伦理/合规决策。 “谁先执行、谁被饿死”在安全场景里是生死问题——如果 polisher（润色）饿死了 finisher（合规收尾），产品就可能输出未经合规检查的内容。把优先级写进配置文件，意味着你把”哪个任务可以被牺牲”这个价值判断显式化、可审计化了。这与 Gabison & Xian（arXiv:2504.03255，2025）讲的 LLM agentic 系统责任归因直接相关——配额拒绝日志（rejected 计数）就是责任链的审计证据。

  3. 用户感知的是”降级”，不是”超额”。 当硬配额触发，用户看到的应该是”已用经济模式完成”或”部分步骤已跳过”，而不是一个 500 错误。配额机制的 UX 出口是优雅降级，不是失败。这是 PM 必须替工程师想到的那一层。

§6 对手框架回应：机制设计不够 + 亲社会 agent

接受 + 边界，不是反驳。本节点最该认真对待的反方，是 Huang, Tharas, Marro et al.（Schölkopf 组，arXiv:2605.08426，2026）那篇旗帜鲜明的《Mechanism Design Is Not Enough: Prosocial Agents for Cooperative AI》。

他们对的部分（接受）： 基于不完全合同理论（incomplete contracts，Williamson 三大支柱之一的”有限理性→合约不完备”），当配额规则无法穷举所有未来情境时，必然存在正的福利损失，任何现实机制都无法消除。具体到本骨架：贪婪 agent 一定会找到规则的缝——比如把一个大调用拆成多个小调用绕过单次阈值，或在软线前疯狂抢跑。这是 Williamson 意义上的”机会主义（opportunism）“，是配额墙永远堵不死的尾部风险。这也呼应 Myerson-Satterthwaite 不可能定理（1983）的精神：信息结构的根本约束下，没有机制能同时做到效率、激励相容、个体理性、预算平衡。

本节点坚持的边界（赌注）： 但我赌的是——在生产工程的现实里，“先上一道堵住 80% 浪费的硬配额墙”的边际收益，远高于”等一个完美的亲社会 agent 方案”。 理由有三：(a) 亲社会 agent（把他人福利纳入自身效用）目前只在小规模实验验证，大规模可扩展性”〔待核实〕“（该论文自己也承认实证基础需扩展）；(b) 配额墙是可证伪、可审计、可立即部署的，亲社会性是不可观测的内部状态；(c) 二者不互斥——配额是底线，亲社会是上限，先建墙再种花。这正是 Ostrom 的立场：自治治理（gentle、内生规范）有效，但有条件，不是普世灵药，硬边界仍是第一道防线。

Rick 未读的对手框架（破 echo chamber）： Riehl et al. 的 Karma 机制（arXiv:2604.07970，2026）提出了一条与”硬配额”正交的路：非可交易的信用额度（karma），记录 agent 历史合作行为，去中心化地驱动冲突解决，无需中央控制器。它对本骨架的拷问是：你这个中央 Ledger 是单点、是 Ostrom 批判的”利维坦”——一旦账本崩了全员停摆。我接受这个批评，但标注边界：Karma 机制原论文针对物理机器人路径规划，向纯 LLM agent 的迁移”〔待核实〕“；中央账本对 demo 是简洁优势，对生产才是需要替换的单点。

§7 跨域呼应：Williamson 交易成本——配额机制何时反而是负优化

调度一个 Rick 的一手框架：Williamson 交易成本经济学（TCE）。这个跨域资源不是装饰，它能改变一个具体的技术判断——到底该不该上配额机制。

Coase 1937《企业的性质》的核心：企业边界由”内部组织成本 vs 市场交易成本”的比较优势决定。Williamson（1975/1985）把它精细化为：交易该内部化（make）还是外包（buy），取决于资产专用性 + 不确定性 + 频率。

把这套搬到 agent 治理：给 multi-agent 加一套配额 + 优先级 + 账本机制，本身是有”组织成本”的——你要维护账本、调优阈值、处理制裁的边界情况、应对账本单点故障。Williamson 的洞见逼出一个尖锐判断：

当协调成本（治理这套机制的开销）> 内部复杂度成本（直接用一个 agent 把活干完）时，加配额机制是负优化。

这直接呼应了 A07 Multi-Agent Teams 的核心反共识——“单 agent 够用就别用多 agent”。如果你的任务根本不需要多 agent，那么”给 multi-agent 加配额”就是在为一个本不该存在的复杂度买单。配额机制的正当性，前置依赖于”多 agent 本身是否正当”。Token Economics 综述（arXiv:2605.09104，2026）把这一层叫”中观（meso）——多 agent 协作的交易成本”，正是 Williamson 框架在 agent 经济学里的直接落地。

这与我的滴滴一手经验显式互通： 在双边市场（司机—乘客）的费用治理里，我做过 费用治理 和 降发生方法论——核心教训是，给一个生态加治理规则，规则本身的运营成本（监督、申诉、误伤补偿）常常被低估。双边市场的激励设计（让司机/乘客的自利行为产出平台想要的全局秩序）与 agent 资源治理是同构的：都是机制设计问题，都要在”放任→公地悲剧”和”过度治理→协调成本爆炸”之间找那条 Ostrom 式的中道。我在 纠纷治理从裁判到管家 里学到的”分级响应、轻重有序”，本质就是 Ostrom 的分级制裁——这套迁移不是类比，是同一个机制设计内核在不同基质上的两次实现。

§8 PM 决策启示

  • 面试怎么用：被问”multi-agent 怎么控成本”，不要只说”设 max_tokens”。说三层：(1) pre-call 事务性配额（区别于事后看板）；(2) 优先级调度防关键 agent 饿死；(3) 分级制裁 + 优雅降级。再补一句反共识——“但先得问这活该不该用多 agent，否则是为伪需求买单”（Williamson 协调成本）。这套答法直接把你和”背了 framework 文档”的候选人区分开。
  • 选型怎么用：评估 AutoGen / CrewAI / LangGraph 时，直接查”有没有框架级、跨 agent、pre-call 的 token 配额”。截至 2026 年答案普遍是”没有”（三家均须开发者手工配置，且单 agent 视角）——所以治理要么自建中间件，要么用 Microsoft Agent Governance Toolkit（2026-04，WebFetch 核实）这类外挂层。把这条写进选型评分卡。
  • 复现怎么用：拿 §3 骨架当起点，但别拿它上生产（见下节）。它的价值是让你在白板上 30 秒画出”配额墙 + 优先级队列 + 账本”三件套，并解释每件为什么不可省。

§9 与已有节点的关系（升级对照，不复述）

  • 对 m209 - 推理成本控制手册 的补缺：m209 从成本侧讲单次推理怎么省（量化、缓存、分层模型）；本节点从治理机制侧讲多 agent 共享预算怎么不被烧穿。m209 是”怎么让每次调用更便宜”，R01 是”怎么不让一群 agent 把便宜的调用乘以无穷次”。两者正交，互链。
  • 对 A07 Multi-Agent Teams 的深化：A07 判定”市场式 multi-agent 仍是玩具、单 agent 够用就别用”。本节点接受这个边界，并补上”如果你确实在用 multi-agent，配额机制是必装的治理底座”——同时用 Williamson 协调成本回扣 A07 的”别滥用多 agent”。
  • 对 m208 - AI 基础设施与中间件选型 §2.5 的补缺：m208 §2.5.3 讲可观测性层（LangSmith 等）。本节点纠偏其暗含的假设——可观测性 ≠ 治理，pre-call 配额才是控制。这是对 m208 工程章节的一次”控制 vs 观测”辨析。
  • 对 0420 控制论专题的显式升级对照：与控制论 VSM（Viable System Model）对照——VSM 的 System 3（资源调配·审计）正是本节点 Ledger 的控制论原型，但 VSM 是描述性框架，本节点是可执行机制；与 0413 成本专题在”预算硬约束”上对照（成本专题谈总量上限，本节点谈多 agent 间的分配与仲裁）。

§10 关联节点

核心（必读）：

延伸（可选）：

demo ≠ 生产：这段骨架差在哪

最后必须把丑话说清，否则就是 hype。§3 的骨架是教学玩具，把它当生产基座会出大事：

  1. 单点账本：中央 Ledger 是单点故障，且非线程/协程安全。AutoGen 文档自己都标注”not thread-safe or coroutine-safe”（WebFetch 核实）。生产要分布式账本 + 乐观锁/原子计数（Redis INCR 之类），DAO-Agent（arXiv:2512.20973，2025）甚至用链上验证把 gas 成本降 99.9%——但那是另一个量级的工程。
  2. agent 是 mock：真实 LLM agent 不会乖乖接受 try_spend 的拒绝，它会 retry、会把大调用拆小绕过阈值（Williamson 机会主义）。需要异常处理、幂等、防绕过的细粒度计量。
  3. 配额是静态的：真实负载需要动态配额（按任务重要性、按租户、按时段调整）和预测式预留，不是写死的 4000。
  4. 没有真实工具的语义：paid_search 只是计数器，真实工具有延迟、有部分失败、有副作用，制裁逻辑要复杂得多。
  5. 没处理上下文公地：§3 完全没碰第三类公地（共享上下文窗口的污染），那需要 token-aware 的上下文压缩 + 写入仲裁，是另一篇 R 节点的活。
  6. 数字是示意：§3 的”超支从 ~11000 降到 0”是本骨架逻辑下的预期，非任何论文的实测基准；引用的 90% token 节省（Agent Contracts，arXiv:2601.08815，2026）等数字均为单篇论文实验室结果，独立复现”〔待核实〕”。

一句话：这个 demo 让你看见公地悲剧如何被一道配额墙缓解，并把 Ostrom / Williamson / 机制设计的原语翻译成你能读懂的 Python。它不让你拥有一个能上线的治理系统——那需要把上面六条全部补齐，并通过对抗式同行评议。demo 的使命是建立判断力，不是建立产品。

修订日志

  • R1（2026-06-07）：首稿。建立”配额/优先级/分级制裁”三原语 + 可跑对照实验骨架；接入 Ostrom（8 原则映射）、Williamson（协调成本 vs 复杂度成本判断）、机制设计（逆向博弈论 + VCG 取舍）三框架；对手框架回应”Mechanism Design Is Not Enough”（接受不完全合同的福利损失，坚持”先建墙再种花”）+ Karma 机制（破 echo chamber）；显式迁移 Rick 滴滴双边市场/费用治理一手经验；6 条 demo≠生产边界 + 示意数字降级标注。
  • 2026-06-12 内审·arXiv 联网核实：WebFetch 重核本节点两条 arXiv 引用身份——§241 arXiv:2604.07970「Karma Mechanisms for Decentralised, Cooperative Multi Agent Path Finding」(Riehl 等, 2026) 与 §309 arXiv:2601.08815「Agent Contracts」(Ye & Tan, 2026) 标题作者均与引述一致,论文身份已核(0 存疑)。§241「Karma 向纯 LLM agent 迁移〔待核实〕」与 §309「90% token 节省独立复现〔待核实〕」是对结论外推/单篇数字复现的限定、非论文身份待核,保留不动。