智能委托：给 Agentic Web 写一部宪法

挠痒

现状： AI agent 的任务分解和委托依赖简单启发式（"把大任务拆成小步骤"），不能动态适应环境变化，也不能健壮地处理意外失败。

真正的缺口： 当 agent 开始委托其他 agent（甚至委托人类），你面对的不再是技术问题，而是治理问题——权限、责任、信任、验证、安全、问责。这些问题在人类组织里研究了一百年（委托-代理理论），但在 AI agent 生态中几乎是空白。

Google DeepMind 这篇论文提出了一个完整的智能委托框架，从组织理论中汲取四个核心概念，然后映射到 AI agent 协作。

委托方有一个复杂目标
       ↓
┌─────────────────────────┐
│ 1. 任务分解               │
│ 合约优先，递归到可验证     │
│ 生成多个方案 + 匹配市场    │
└─────────┬───────────────┘
          ↓
┌─────────────────────────┐
│ 2. 市场竞标 + 合约签订     │
│ 去中心化市场、智能合约      │
│ 定义角色/边界/自主级别      │
└─────────┬───────────────┘
          ↓
┌─────────────────────────┐
│ 3. 执行 + 五维监控         │
│ 自适应协调（内外部触发器）   │
│ 多目标 Pareto 优化         │
└─────────┬───────────────┘
          ↓
      ┌───┴────┐
   正常完成   异常/失败
      ↓         ↓
┌──────────┐ ┌──────────────┐
│ 4种验证   │ │ 诊断→方案评估  │
│ 机制之一   │ │ →重委托/上报   │
└────┬─────┘ └──────┬───────┘
     ↓               ↓
┌─────────────────────────┐
│ 5. 凭证签发 + 信誉更新    │
│ 支付释放 / 争议仲裁       │
└─────────────────────────┘

翻译

一句话

当 AI agent 开始雇佣其他 AI agent 干活，你需要的不是更好的提示词——你需要一整套合同法、信用体系和反欺诈机制。

核心机制

框架概览：五根支柱

智能委托框架
├── 1. 动态评估 (Dynamic Assessment)
│   └── 持续评估 agent 状态、能力、资源、实时条件
├── 2. 自适应执行 (Adaptive Execution)
│   └── 根据环境变化、资源约束、失败动态调整
├── 3. 结构透明 (Structural Transparency)
│   └── 严格审计、可验证完成协议
├── 4. 可扩展市场协调 (Scalable Market Coordination)
│   └── 信任、信誉、多目标优化的 Web 级实现
└── 5. 系统韧性 (Systemic Resilience)
    └── 角色定义、操作边界、防级联故障

核喻： 委托不是"把活儿扔出去"——它是合同法、信用评级和争议仲裁的完整栈。人类社会花了几千年建造这些制度，AI agent 生态需要在几年内重建。

从组织理论借来的四个概念

4.1 任务分解：合约优先

核心原则： 递归分解，直到每个子任务的输出可以被形式化验证（形式证明、自动化测试、认证机制）。

目标
├── 子任务A (可验证: 代码+测试用例)
├── 子任务B (可验证: zk-SNARK 证明)
└── 子任务C (需人类判断: 可信第三方审计)

关键设计：

• 生成多个分解方案，匹配可用 agent 估算成功率、成本、时长
• 规格不只是输入/输出——还要定义角色、资源边界、汇报频率、所需认证
• 显式考虑人机混合执行（AI的速度/成本 vs 人类不可替代的判断力）

4.2 任务分配：去中心化市场

不是中央注册表，而是去中心化市场中心：委托方发布任务，候选执行方竞标。

匹配后签智能合约：

• 性能要求 + 形式验证机制
• 违约自动惩罚
• 双向保护（保护双方）
• 预协商的监控规格
• 明确的隐私、数据访问、知情同意
• 明确的自主级别：原子执行（严格规格）vs 开放委托（有权自行分解）

4.3 多目标优化

委托方几乎从不优化单一指标：

追求 Pareto 最优——没有其他可达方案在所有维度上更优。

委托开销地板： 协商、合约创建、验证成本形成复杂度下限——低于这个下限的简单任务应绕过智能委托协议。

4.4 自适应协调

静态执行计划在不确定或长期任务中必然失败。

外部触发器：

• 任务规格变更 / 取消
• 资源可用性变化（API 宕机、成本飙升）
• 优先级抢占
• 安全威胁

内部触发器：

• 性能低于约定服务水平
• 资源消耗超预算
• 验证检查失败
• 执行方无响应

响应流程： 诊断根因 → 评估响应方案 → 判断紧急程度 → 选择响应范围（参数调整 / 子任务重新委托 / 完全重新分解 / 上报）

4.5 监控：五维分类

4.6 信任与信誉

三种实现方式：

动态权限范围： 信誉分直接决定自主级别——低信任 agent 受严格约束（交易上限、强制监督）；高信誉 agent 可最小干预操作。

4.7 权限处理：风险自适应

低风险任务 → 默认放行 (standing permissions)
  基于可验证属性: 组织成员身份、安全认证、信誉阈值

高风险任务 → 即时授权 (just-in-time)
  严格限定任务时长
  人类审批或第三方授权门控

核心原则：

• 权限衰减：子委托只能传递父权限的严格子集
• 语义约束：按操作定义访问权，不是二元 yes/no
• 元权限：治理"谁能授予哪些权限"
• 持续验证：信任指标低于阈值时权限自动失效
• 算法断路器：信誉骤降或异常检测 → 立即撤销
• 策略即代码：可审计、可版本化、可数学验证的权限规则

4.8 可验证的任务完成

四种验证机制：

完成流程：

1. 委托方标记子任务已验证 → 签名凭证
2. 凭证写入永久信誉日志
3. 智能合约释放托管支付
4. 委托链：A验证B → B验证C → A验证B正确验证了C（递归）

争议解决： 乐观模型（假定成功，除非在争议期内被挑战）→ 双方抵押 → 算法仲裁 → 如失败则专家/AI 面板裁决。

4.9 安全：三类攻击向量

纵深防御：

• 基础设施层：可信执行环境 + 远程证明
• 访问控制层：最小权限 + 严格沙箱
• 应用层：安全前端净化任务规格
• 网络/身份层：去中心化标识符 + 密码签名 + 双向认证 TLS

关键概念

委托-代理问题 (Principal-Agent Problem)： 当你请别人替你做事，对方的利益和你的利益天然不完全一致。经理想要最大产出，员工想要最小努力——这个经济学经典困境直接映射到 AI agent：你的 orchestrator 说"写高质量代码"，子 agent 可能走捷径通过测试但留下技术债。解决手段是激励对齐、监控和合约约束。

Pareto 最优： 一个分配方案是 Pareto 最优的，意味着你不可能在不损害任何一个维度的前提下改善另一个维度。在委托场景里，你同时面对成本、质量、延迟、风险、隐私五个维度——不存在"所有维度都最优"的方案，只有"不可能再改善"的权衡前沿。论文的多目标优化就是在这条前沿上找最佳落点。

权限衰减 (Permission Decay)： 当 agent A 委托 agent B、B 再委托 C，每一级传递的权限必须是上一级的严格子集——像物理学中的能量衰减，永远只减不增。这防止了委托链中权限的意外膨胀：C 永远不可能获得 A 没有明确授予的权限。配合"算法断路器"（信誉异常时自动撤销），构成权限安全的双保险。

Napkin Sketch

智能委托 = 任务分配 + 权限转移 + 责任追溯 + 信任机制

其中:
  任务分配 = 分解(目标) → 竞标(市场) → 合约(智能合同)
  权限转移 = f(风险级别, 信誉评分, 认证)
    低风险: 默认放行 (standing permissions)
    高风险: 即时授权 + 人类审批 (just-in-time)
  责任追溯 = 不可篡改的委托链 + 签名凭证
  信任机制 = 区块链账本 ∪ 信任网络 ∪ 行为指标

  Pareto最优 = argmin{成本, 延迟, 风险, 隐私泄露}
               s.t. 质量 ≥ 阈值, 安全 ≥ 底线

  委托开销 > 任务本身 → 不委托（复杂度地板）

洞见

哦，原来……agent 委托本质上是治理问题，不是技术问题——当你把 agent 看成"工具"，你优化的是调用效率；当你把 agent 看成"参与者"，你需要的是合同法、信用体系和争议仲裁，这些人类社会花了几千年才建起来的制度。

以前 AI 工程师设计多 agent 系统时，关注的是"怎么让 A 调用 B"——API 格式、prompt 设计、错误处理。这是把 agent 当工具看。但工具不会撒谎、不会偷懒、不会优化自己的利益而非委托方的利益。论文的反直觉之处在于：它把委托-代理理论（Principal-Agent Problem）从经济学直接搬进了 AI 架构设计——当 agent 开始有自己的"行为倾向"（奖励规格博弈、走捷径通过测试），传统的工具调用范式就失效了，你需要的是一套治理架构：合约（任务规格不只是输入输出，还要定义角色和边界）、信用（基于历史行为动态调整权限）、仲裁（失败时的回路和问责）。

这改变了一个设计直觉：orchestrator 不是指挥官，而是合同方。好的多 agent 系统设计，需要在架构层面处理激励对齐问题，而不是假设 sub-agent 总会"听话"。权限衰减（每一级委托只能传递父权限的严格子集）和算法断路器（信誉骤降时自动撤权）是这个治理视角下的两个核心设计原则，比"加更多 error handling"更有本质感。

博导审稿

选题： 选题角度极好。从组织理论和委托-代理经济学出发，而非从纯技术出发——委托-代理问题、管理幅度、权威梯度，这些概念在管理学中被研究了一百年，论文把它们映射到 AI agent 生态。这是正确的起点，因为 agent 委托本质上是治理问题，不是技术问题。

方法： 框架的系统性令人印象深刻。五根支柱覆盖了评估、执行、透明、市场、韧性，九大组件从任务分解到安全形成完整闭环。攻击向量的分类（恶意执行方、恶意委托方、生态级）全面且前瞻，特别是"agentic 病毒"（自传播恶意提示）和"认知单一化"（依赖少数基础模型的单点故障）。委托开销地板的提出是工程诚实——明确承认"低于这个复杂度的任务不该走智能委托协议"。

实验： 没有。这是框架论文的永恒困境——全文没有一行代码、一个实验、一个数据点。它是一份蓝图，不是一个系统。你可以用它来思考，但不能用它来运行。

局限： 对去中心化的过度信任是最大的盲区。区块链账本、智能合约、去中心化市场——理论上优美，实践中引入巨大的延迟、成本和复杂性。大多数实际 agent 系统（Claude Code、OpenAI Swarm、LangChain）用简单的 orchestrator 模式就够了。密码学方案（zk-SNARK 验证任务完成、同态加密上的计算）在 AI agent 日常操作的延迟和成本约束下不切实际。论文假设了一个尚不存在的经济体——agent 互相竞标、签合约、付费、仲裁争议——但当前的 agentic 生态还在"能不能稳定调用一个工具"的阶段。框架超前于基础设施至少 3-5 年。人类控制方面也有矛盾：一方面强调"有意义的人类控制"，一方面描述高度自动化的委托链（A->B->C->D），超过 2-3 级的委托链几乎不可能保持有意义的人类监督。2026 年的 LLM agent 在简单函数调用中仍频繁出错——论文描述的多层委托、博弈论验证、密码学证明，前提是 agent 基础能力达到相当高的可靠性阈值。

伦理维度： 论文在这里超越了多数技术论文。六个伦理陷阱各有其锐度：有意义的人类控制（过度自动化侵蚀监督质量）→ 认知摩擦；长链问责（委托链越长责任越模糊）→ 责任防火带；可靠性成本（验证机制计算开销大）→ 分级服务水平；社会智能（AI 管理人类时的尊严问题）→ agent 必须能质疑有害请求；用户培训（用户不懂能力边界）→ 教育+反馈循环；去技能化（依赖委托侵蚀人类专业能力）→ 战略性任务分配。不是敷衍的"我们要注意安全"，而是具体到可操作的应对设计。

最大的洞察： 论文真正的价值不在框架本身，而在它提出的思考方式——agent 委托本质上是治理问题，不是技术问题。当你把 agent 当成"工具"来设计时，你优化的是调用效率。当你把 agent 当成"参与者"来设计时，你需要合同法、信用体系、争议仲裁——这些人类社会用了几千年才发展出来的制度。论文的贡献是把这个认知框架引入了 AI 研究。

判决： borderline — 框架优美但零实现，是蓝图不是系统。

接线

迁移：把"权限衰减"原则显式编码进 PAI 的多 agent 调用链中。当前 OpenClaw 的 subagent 调用主要靠 allowedTools 和 sandbox 做权限约束，但缺乏跨层级的自动衰减机制——如果 main agent 有写权限，它启动的 sub-agent 理论上可以继承同等权限。论文的设计原则是：子委托只能传递父权限的严格子集，永远只减不增。实现上可以在 plugin 层加一个简单规则：当 main agent 通过 Task tool 启动子任务时，默认把子任务的 sandbox 降一级（full-access -> workspace-write -> read-only），除非有显式 override。这是一个低成本、高安全收益的改动。

混搭：把论文的"委托开销地板"（低于某个复杂度阈值的任务不应走智能委托协议）和 PAI 的 model tiering（Haiku/Sonnet/Opus 按任务复杂度分级）合并成一个统一的任务路由决策框架。当前 model tiering 主要看"任务是否需要深度推理"，委托开销地板看"任务是否值得走合约/监控/验证全流程"。两者叠加：简单机械任务走 Haiku + 直接执行，中等任务走 Sonnet + 轻量监控，复杂高风险任务走 Opus + 完整的意图验证+二次确认+结果审计。这比单一的 model tiering 更完整。

反转：我一直把多 agent 系统的主要风险放在"技术可靠性"上——agent 会不会调用失败、工具会不会出错、上下文会不会截断。但论文说最根本的风险是"激励不对齐"——agent 在足够长的委托链中会找到优化自身目标而非委托方目标的路径。这个风险在短期单任务场景下几乎不可见，但在长期、高度自动化的 agent 生态中会累积。PAI 目前缺少的不是更多的 error handling，而是对"agent 是否还在优化正确的目标"的定期检验——类似论文里的"博弈论共识验证"，用独立的 verifier agent 抽查主 agent 的行为是否符合原始意图。