Agent 自主权的边界

讨论 Agent 时，我们经常落入一个错误的二选一：系统要么按照预设 Workflow 工作，要么把过程完全交给 Agent。

前者安全但僵硬，后者聪明却不可控。于是产品开始寻找一个抽象刻度：这个 Agent 应该有多少自主权？30%，还是 80%？

这个问题本身就不准确。

一个 Agent 可以自由搜索整个仓库，却不能修改任何文件；可以在 Sandbox 中重构代码，却不能 Push；可以选择执行路径，却不能扩大预算；可以代表用户整理草稿，却不能代表用户发出消息。

它并不是“自主程度为 60%”。它拥有一些决策权，同时没有另一些决策权。

所以真正的问题不是：

Agent 有多自主？

而是：

这个 Agent 在什么条件下，已经赢得了哪些决策的权利？

自主权不是模型能力的别名，也不是产品人格。它是一套动态分配的 Authority。

能力不等于权力

模型能够做一件事，只能说明这项行动存在技术可能性。它是否有权执行，是另一个系统问题。

一个模型可能具备生成 SQL、调用付款接口、删除云资源和发送邮件的能力。但能力本身无法回答：

这是不是用户当前真正要求的行动；
它可以影响哪些资源与多少用户；
失败后是否能够恢复；
谁承担错误结果；
什么证据足以让它继续；
什么时候必须把决定交还给人。

传统软件通过确定性代码预先回答这些问题。Agent System 则允许一部分判断在 Runtime 里发生。这不是取消 Control，而是把 Control 从固定路径改造成明确的决策边界。

因此，我会严格区分：

Capability：系统是否能够执行某类行动；
Authority：当前 Agent 是否被允许在特定条件下决定并执行它；
Accountability：行动发生后，系统能否解释、验证并承担后果。

一个成熟产品不会因为 Capability 存在，就默认授予 Authority。

自主权是一组决策权

与其给 Agent 一个整体等级，不如把自主权拆成可以分别授予的权利。

决策权	Agent 可以决定什么	典型边界
观察权	读取哪些文件、数据和外部材料	数据 Scope、敏感级别、网络边界
规划权	如何拆解目标、探索多少分支、何时重规划	时间、Token、候选数量、任务 Scope
工具选择权	在允许的工具集中选择下一步行动	Tool Allowlist、参数约束、调用频率
修改权	改变文件、草稿、记录或本地状态	Workspace、Diff 大小、可逆性
外部行动权	发送消息、发布内容、修改线上资源	审批、收件人、环境、影响用户数
消费权	使用模型、计算、API 或真实资金	单步预算、任务预算、时间窗口
完成判定权	判断目标是否已经完成、何时停止	Verifier、成功契约、人工验收
委托权	把任务和权限交给其他 Agent 或工具	权限继承、最大深度、责任归属

这些权利之间没有必然递进关系。

一个研究 Agent 可以拥有很大的观察权和规划权，却没有任何外部行动权。Coding Agent 可以在隔离 Worktree 中拥有修改权，但 Push 和部署仍需要批准。一个运维 Agent 可能可以自动重启已知无状态服务，却无权修改数据库或重新定义事故已经结束。

这也是为什么“Human in the Loop”仍然太粗。人的参与不应该被理解成整个任务中有或没有审批，而应该落在具体决策权的边界上。

一份自主权契约

每次授权至少应该包含以下维度：

Authority Grant =
  Actor
  × Action
  × Resource Scope
  × Preconditions
  × Budget
  × Evidence Requirement
  × Expiry

换成一份具体契约，可以是：

Actor:       当前 Coding Agent
Action:      修改与运行测试
Scope:       当前 Worktree，不包含 Git Push
Precondition: 已读取项目指令，Worktree 状态已记录
Budget:      最多 20 次命令，禁止网络
Evidence:    Targeted tests + typecheck + final diff
Expiry:      当前 Task 结束或用户撤回授权

这比“允许 Agent 自动操作”精确得多。

Scope 让权限只覆盖相关资源；Precondition 规定获得权力前必须满足什么；Budget 限制即使判断错误，损失也不会无限扩大；Evidence Requirement 把继续与完成绑定到外部证据；Expiry 防止一次授权永久泄漏到未来任务。

权限还应该是不可传递的，除非契约明确允许委托。Agent 获得文件写入权限，不代表它调用的任意脚本或子 Agent 自动拥有相同边界；调用链越深，越需要明确 authority 是否继承、收窄或重新审批。

不变量、Policy 与模型判断

一个可靠 Agent 产品通常需要三层不同性质的控制。

不变量：无论模型如何判断都不能被违反

例如：不能读取某类敏感数据，不能超过账户余额，不能向未授权对象发送内容，不能修改 Scope 之外的生产资源。

不变量应该由确定性系统执行。它们不能只写在 Prompt 里，因为 Prompt 影响行为，却不构成 Enforcement。

Policy：在明确条件下自动授权或要求审批

例如：读取 Workspace 内文件可以自动允许；修改超过 10 个文件需要批准；访问网络只允许特定域名；对测试环境的可恢复写入可以自动执行，对 Production 的写入必须由人确认。

Policy 把组织风险偏好转成运行规则，也可以结合身份、环境、金额和历史证据动态计算。

模型判断：在被允许的空间内选择路径

Agent 应该有权决定搜索哪些关键词、先读哪个文件、生成几个候选、某个失败是否值得换一条路，以及当前证据支持哪一种假设。

这里才是自主性真正创造价值的地方。产品保留不可越过的边界，但不预先规定每一步方法。

Hard invariants define the world that must remain true.
Policy decides which actions may cross a boundary.
The agent chooses a path inside the granted space.

如果把三者全部塞进 Prompt，系统会既不可靠又难以调试；如果把所有判断都写成 Workflow，Agent 又只剩下生成文本的自由。

风险不只来自失败概率

授予自主权时，仅仅问“Agent 做对的概率是多少”不够。

一次只读搜索与一次不可逆付款，即使成功率相同，也不应该获得同样授权。可以用一个非严格但实用的风险视角思考：

Operational Risk ≈
  Probability of error
  × Impact radius
  × Irreversibility
  × Time to detection

这不是用来精确计算分数，而是提醒我们：错误能否被看见、影响是否局部、行动能否撤销，往往比模型平均准确率更重要。

因此，自主权应该优先从三类行动开始扩张：

可观察：系统能迅速知道行动与结果；
可逆：失败后可以恢复原状态；
局部影响：错误不会跨越当前用户、Workspace 或测试环境。

Sandbox 的价值也在这里。它不只是阻止危险操作，而是创造一个允许 Agent 更自主的环境。相同行动在隔离 Worktree 与 Production 主分支上，拥有完全不同的风险结构。

对不可逆或难以检测的行动，产品应采用更窄的 Scope、更强的 Preconditions、更独立的 Verification，或者让 Agent 只提出建议而不执行。

自主权如何被赢得

“赢得自主权”不是让一个 Agent 积累某种全局信誉分。证据必须和具体决策权、任务类型、环境与影响范围绑定。

一个 Agent 在前端代码修改上表现可靠，不代表它自动获得数据库 Migration 权限；在测试环境正确发送通知，不代表它可以向全部真实用户群发；擅长完成十分钟任务，也不能证明它能在数月任务中判断长期结果。

更合理的放权路径是：

Shadow
  Agent 只观察并记录自己会怎么做
      ↓
Recommend
  Agent 提出行动，人执行或拒绝
      ↓
Approve-before-act
  Agent 准备具体行动，经批准后执行
      ↓
Bounded autonomy
  Agent 在小 Scope、低预算、可恢复环境中自动执行
      ↓
Expanded autonomy
  证据持续成立后，扩大某一个维度

每一级都应该收集决策质量，而不只是最终成功率：

是否选择了正确的行动类型；
是否识别出需要审批的情况；
是否在证据不足时停止；
失败后是否避免重复副作用；
是否保持在原始 Scope 内；
Verifier 是否真的覆盖用户结果。

扩张也应该一次只改变一个主要变量。例如先扩大文件 Scope，而不是同时扩大文件 Scope、网络访问和外部写权限。否则失败后无法知道哪一个新边界出了问题。

Evaluation 延迟决定自主权上限

有些任务几秒钟就能验证：编译是否通过、文件是否存在、Schema 是否有效。有些任务需要几天甚至几个月，才能知道最初的判断是不是好判断。

这对 Long-horizon Task 尤其重要。Agent 可以连续运行、不断重规划并保存 Durable State，却仍然无法回答最关键的问题：几个月后，我们如何知道今天的行动是对的？

产品常常尝试用即时 Proxy 缩短反馈周期，例如点击率、模拟环境、Judge Model 或人工打分。这些信号有用，但它们只能验证契约的一部分，不能自动替代真实结果。

当 Evaluation 延迟很长或结果不可观察时，系统应该诚实地下调自主权：缩短 Commitment、让关键方向阶段性审批、限制不可逆投入，并保留退出选项。

无法及时评价结果的系统，不应该仅仅因为能够持续执行，就获得更长时间的自主权。

完成判定权经常被低估

工具权限很显眼，停止权限却常常被忽略。

允许 Agent 自己宣布完成，实际上授予了它一种高影响决策权。过早停止会交付不完整结果；拒绝停止会不断消耗成本、扩大 Diff，甚至重复外部行动。

所以完成判定应该拥有独立契约：

Completion Authority
├── success criteria
├── required evidence
├── maximum unresolved risks
├── verifier identity
└── human acceptance boundary

对于低风险任务，Agent 可以根据测试结果自动结束。对于跨系统写入，它可能需要从 System of Record 回读状态。对于审美、策略或高风险业务判断，系统最多只能说明“执行完成并提供材料”，最终是否接受仍属于人。

Agent 可以拥有执行路径，却不一定拥有定义“什么算好”的权力。

委托不能稀释责任

Multi-Agent 系统会进一步放大 Authority 问题。

主 Agent 把研究交给子 Agent 时，应该传递完成子任务所需的最小权限，而不是复制自己的全部 Capability。子 Agent 产生建议后，最终执行者仍需要重新检查 Scope、证据与副作用。

Parent authority
  ├── delegated subset → Research agent
  ├── delegated subset → Coding agent
  └── retained rights  → approval / external action / completion

委托可以分散工作，不能分散最终责任。系统必须始终知道：谁提出了行动、谁批准了行动、谁真正执行，以及哪个 Verifier 接受了结果。

否则 Multi-Agent 只会让权限来源更难追踪，让每个 Agent 都相信另一个 Agent 已经完成了必要检查。

权限必须能够撤回和降级

自主权不是一次授予后永久增长。

环境变化、模型升级、工具更新、新攻击方式、异常成本和一次严重失败，都可能让旧证据失效。系统需要能够：

让授权自动过期；
在异常率或成本上升时收窄 Scope；
暂停某类 Tool 或外部行动；
从自动执行降级到执行前审批；
立即取消尚未开始的行动；
对已经发生但结果未知的副作用进入人工处理。

降级不是失败，而是动态系统的正常控制动作。

一套只能扩大、不能撤回的自主权机制，最终会把过去的成功变成未来的隐性权限债务。

界面应该展示控制关系

透明不等于把每次 Tool Call、每个 Token 和全部内部活动做成时间线。用户真正需要理解的是有后果的控制关系：

Agent 当前追求的目标；
它已经拥有哪些决策权；
正在使用多少预算；
哪些行动已经产生外部结果；
什么证据会让它停止；
哪些决定仍然属于用户。

一次好的审批也不应该只显示一条 Shell Command。它应该说明意图、影响范围、可逆性和拒绝后的替代路径。

用户不需要监督每一步，但必须能够预测“让它继续”意味着什么。

自主权是一套治理系统

把这些部分放在一起，Agent 的自主权并不位于模型内部，而是由 Harness 与产品共同执行：

User / Organization Policy
              │
              ↓
      Authority Controller
      ├── invariants
      ├── grants & expiry
      ├── budgets
      └── approval rules
              │
              ↓
Agent Decision → Tool Executor → Environment
      ↑               │               │
      │               ↓               ↓
      └──── Context / State ← Evidence / Effects
                             │
                             ↓
                    Verification & Eval
                             │
                  expand / retain / revoke

《Agent Systems：从模型调用到可靠执行》讨论 Harness 如何让行动受到约束并获得证据；《Coding Agent 的执行系统》讨论一个工程目标如何被推进到交付。这篇文章回答的是另一层问题：在这些机制存在之后，哪些判断应该交给 Agent？

答案不会是“全部”，也不会是“固定 60%”。

产品应该把自主权拆成一组具体决策权，为每一项权力声明 Scope、Budget、Evidence 与 Expiry，在可观察、可逆、局部的环境里逐步扩大，并在证据失效时毫不犹豫地撤回。

真正成熟的 Agent 不是永远不问人的 Agent。

它知道哪些决定已经被授权，哪些证据允许它继续，哪些边界绝对不能越过，以及什么时候必须把判断交还给承担后果的人。