AI 编程 Agent 需要「权限预算」而非更强模型

一个编程 Agent 可以在团队还未就其权限范围达成共识之前，就已生成出一个补丁。

这是一个糟糕的交易。如果没有人能够解释这个补丁涉及了哪些文件、调用了哪些工具、保留了哪些数据、或者有哪些证据可以证明结果是可信的，那么一个快速的补丁毫无用处。模型可能很强大，但工作流程仍然无法使用。

我将此视为一种权限预算（authority budget）。预算指的是围绕 Agent 的一系列权限和义务：它可以读取什么、写入什么、调用什么、保留什么、需要获得什么批准、以及事后需要证明什么。模型很重要，但它只是整体设计的一部分。

模型质量只是一个维度

编程助手如今占据着不同的工作流轨道。有的存在于 IDE 中。有的在终端、浏览器或 Pull Request 流程中工作。隐私保护、团队管控、成本以及可用的上下文量也因工具不同而有所差异。

这种多样性使得通用排名比表面看起来的用处更小。选择一个 Agent 同时也是在选择一套权限面。

IDE 助手可能只能看到当前打开的文件和仓库的一部分。终端 Agent 可能能够运行命令并修改更广泛的文件路径。以浏览器为导向的工作流可能又有着不同类型的访问权限。每种方式都会产生不同的审查问题。

问题不仅仅是："哪个模型写的代码最好？"还包括了：

• 这个工作流暴露了哪些上下文？
• Agent 可以在不询问的情况下修改什么？
• 它可以调用哪些外部系统？
• 审查者如何了解发生了什么？

模型对比可以帮助回答第一个问题，但无法回答其余的问题。

读、写、审查是不同的权限

The Pair 文档记录了 Mentor（作为只读审查者）和 Executor（执行写入工作）之间的简单划分。该项目是否能发现更多错误是另一个问题。但这个设计仍然使一个重要的权限区分变得可见。

检查权和变更权不一定是同一种权限。

当一个 Agent 能够检查仓库、编辑文件、运行命令并总结自己的工作时，这种区分很容易被混淆。进行变更的系统也可以决定这个变更看起来没问题。那么一个成功的响应就变成了独立审查的拙劣替代品。

一个更严格的工作流可以将这些权限分开：

• 一步收集上下文并提出变更方案。
• 另一步在受限的工作空间内应用变更。
• 审查者（人或自动化）检查 diff 和必需的检查项。

这不会让审查自动变得正确。但它确实让审查边界变得明确。读权限不等于写权限，写权限不等于批准权。

模型周围的套件是产品的一部分

Google 的开发者亮点将持久隔离环境和 Managed Agents 描述为其开发者工具的一部分。发布信号之所以重要，是因为它将执行空间、持久化和 Agent 生命周期视为产品问题，而不是隐藏在聊天框背后的细节。

prjct/ 的 Product Hunt 页面从另一个角度采取了类似的方向。其产品定位结合了意图简报、受限的仓库上下文、持久化记忆、护栏以及围绕编程 Agent 的评估。

这些页面描述的是供应商或产品作者提供的能力。它们不是独立的验证，隔离或持久化也不会自动让工作流变得安全。但它们确实展示了工程表面正在向什么方向发展：围绕模型的包装器越来越多地决定了塑造一次运行的上下文、工具、记忆和检查。

这个包装器值得与 prompt 相同的设计关注。

如果 Agent 有持久化记忆，决定什么可以进入其中以及停留多长时间。如果它在隔离环境中运行，决定哪些凭证、网络路由和仓库仍然可以访问该环境。如果它有护栏，让受限操作可见并测试失败路径。

"已沙箱化"这样的标签不等于权限模型。

关于权限的讨论

最近 Reddit 上关于某个工作场所不允许使用 AI Agent 的讨论是坊间传闻，而非对团队行为方式的测量。不过它仍然有用，因为反对意见是具体的。人们讨论代码泄露、数据保留、数据驻留，以及审查者如何检查 Agent 产生的变更。

这些都是权限问题。

开发者可能想要在某个仓库中获得帮助。组织可能需要知道源代码是否离开了其边界、prompt 或日志是否持久化、产物存储在哪里、以及人类是否能够重建变更。生产力不会消除这些义务。

这就是为什么"模型已经足够好"很少能决定一个采纳决策。团队可以接受编程能力但拒绝周围的权限。他们也可以批准一个狭窄的本地工作流，同时拒绝广泛的仓库或生产环境访问。

在扩大访问范围之前先写好六行

权限预算不需要成为一个宏大的治理计划。从任务定义中的六行明确说明开始。

Read（读）。列出 Agent 可以看到的仓库、目录、文件、密钥和外部上下文。默认将敏感材料排除在范围之外。

Write（写）。列出 Agent 可以更改的路径和分支。明确生成的产物和受保护的文件。

Call（调用）。列出运行期间可用的命令、工具、网络目的地和服务。将新的网络权限视为设计变更。

Retain（保留）。决定 prompt、源代码片段、记忆、日志、diff 和输出产物保存在哪里，以及保存多久。

Approve（批准）。标记需要人员或策略门控的操作，例如更改依赖项、访问生产环境或扩大工作空间。

Prove（证明）。要求提供 diff、命名的检查结果、相关事件或日志证据，以及明确的失败状态，才算一次运行完成。

最后一条是许多工作流变得诚实的关键。进程退出码为 0 不等于变更被接受。Agent 说它完成了不等于测试套件通过。一个有用的结果应该让下一个审查者能够看到：什么改变了、什么运行了、什么失败了、以及 Agent 留下了什么未动。

对于一个自动化的编码任务，我会从一个只读的仓库切片或一个狭窄的可写路径开始。然后为一种命名的工作流需求添加一项权限。如果 Agent 需要网络访问，记录原因。如果它需要持久化记忆，定义其内容和生命周期。如果需要编辑一个新目录，让那个扩展可被审查。

这样在团队学习工作流行为的过程中，保持失败半径较小。

只有在运行能够展示收据时才支出权限

更好的模型会让 Agent 更有用。但它们不会决定团队应该向 Agent 暴露什么，或者什么证据应该解锁下一步。

这个决定属于工作流契约。

更好的编程 Agent 通常不是那个演示最令人印象深刻的。而是团队能够解释其权限的、其变更在权限范围内的、以及其结果留下了一张可由其他人或系统审查的收据的 Agent。

---