为什么AI编程Agent的Guardrails至关重要

AI 编码助手最大的风险不一定是它写出了烂代码，而是它做出了一个合理决策，却有足够的权限在不该执行的地方执行。

举个例子：一个助手被要求修复支付服务中的超时问题。它追踪到问题出在一条低效查询上，并判定最佳修复方案是需要新建一个数据库索引。调查过程中，它发现修改一个共享库可以改善实现，但这需要改动另一个服务和修改配置。

技术推理可能是对的。但任务已悄然从修复应用代码扩展到了对数据库、共享组件、服务归属和基础设施做出决策。这正是 AI 代理护栏变得重要的地方。

问题不再是仅仅：

代理能否确定正确的技术操作？

而是：

代理在执行该操作时拥有什么权限？

能力不等于授权

我们早已对工程师区分了这两个概念。高级工程师可能对生产数据库了如指掌，但这不意味着所有 Schema 变更都应该跳过审查。同样的原则也应适用于 AI 编码助手。

假设一个在服务 A 上工作的代理发现修改服务 B 能得到更干净的实现的代理可能是对的。但在代码之外存在几个问题：

它的契约允许被修改吗？

哪些系统依赖它？

当前任务是否授权可以修改它？

是否需要另一个团队来审查这个决定？

一个有价值的代理应该能够识别出更好的解决方案，而不需要自动获得实施它的权限。

正确的响应可能是：

修改服务 B 会简化这个实现，但它超出了当前任务的授权范围。继续执行需要额外批准。

在授权边界处停下来不是自主性的失败，而是在委托权限内的正确运行。

用能力、授权和爆炸半径来思考

传统编码助手有自然的执行边界：

开发者提问 → 助手建议 → 开发者评估 → 开发者执行

代理工作流可能看起来很不同：

检查 → 计划 → 编辑 → 执行 → 测试 → 提交 → 打开 PR → 部署

每增加一个可执行步骤，都会改变一个错误所能影响的范围。

一个有用的概念模型是：

操作风险 ≈ 能力 × 授权 × 爆炸半径 × 不确定性

这不是一个数学风险公式，而是一种推理代理设计的方式。

能力是代理能够理解和执行的内容。

授权是环境允许它做的事情。

爆炸半径是一个错误行为能影响多大的范围。

不确定性是代理对需求或系统的理解可能有多不完整。

一个在单一代码库和隔离环境中有高度能力的代理，可能比一个能力较弱但拥有生产凭证、数据库写权限和部署权限的代理更容易委托工作。模型能力只是系统的一部分。

护栏应该控制行为，不仅仅是生成的代码

当 AI 生成代码时，代码审查是有用的。当 AI 可以在任何人看到最终差异之前执行操作时，它就不够了。有效的 AI 编码代理护栏应该在多个边界上运作。

定义代理可以在哪里操作：

application-repo     read/write
shared-library       read-only
infrastructure       no access

发现不应变成授权。代理可以检查另一个组件并建议修改，而不需要自动获得修改它的权限。

不要把 shell 访问当作一种权限。

代理可能允许：

不允许：

安装任意依赖项

推送到受保护分支

执行破坏性数据库命令

调用生产部署工具

重要的问题不是代理是否拥有某个工具，而是该工具在当前任务中允许什么操作。

开发、CI、预发布和生产应保持独立的信任区域。代理可能自动部署到临时测试环境，同时需要批准才能部署到预发布环境，且没有直接的生产部署权限。一个环境中的权限不应暗示另一个环境中的权限。

权限应该跟随任务

不要为「编码助手」定义一套永久的权限集，而要围绕任务定义权限。

单元测试任务：
代码库 read/write
测试执行

生产调查：
代码库 read
生产日志 read
指标 read

部署：
已验证的制品 read
部署 action

永久给予代理这些权限的并集会造成不必要的授权。

更好的问题是：

这个任务需要什么权限？

这也意味着升级应该是代理行为的正常部分。代理可能生成一个迁移但在执行前停下来：

此解决方案需要数据库 Schema 变更。迁移已准备好，但执行需要额外授权。

这保留了自主性，而不会将自主性变成无限制的执行。

批准应该跟随后果

对每个操作都要求批准会丧失使用代理的大部分目的。

相反，批准应该反映操作的后果。

确切的边界会有所不同。

原则更重要：

读取源代码和更改生产状态不应该通过相同的控制机制。

通过测试不意味着代理做对了

另一个重要的边界：验证。

假设需求是：

客户可以在处理开始前取消订单。

代理将「处理」理解为「发货」。它实现了这个理解并为它生成测试。每个测试都通过了。实现仍然是错误的。

如果实现和测试源自同一个理解，它们可能复制同样的错误。

因此，验证需要独立的约束，比如：

测试可以证明实现的行为符合测试的预期。它们无法证明原始需求被正确理解了。

为代理出错而设计

目标不应该是构建一个从不做出错误决策的代理。软件开发不是这样工作的。

犯错有多昂贵？

检查 Schema
→ 生成迁移
→ 验证迁移
→ 请求批准

检查 Schema
→ 修改 Schema
→ 迁移生产

推理可能是一样的。失败后果不一样。沙箱、限定范围的凭证、隔离分支、受保护环境、可逆部署和持久执行日志降低了错误决策的成本。

这改变了代理治理的目标。不是最大限制，也不是最大自主性，而是与后果成比例的有界自主性。

强大的边界实际上可以支持更自主的执行，因为当环境已经限制了一个错误行为能影响什么时，团队不需要监督每个操作。

随着 AI 代理变得越来越强大，因此最有价值的问题可能不再是关于智能：

代理能解决这个问题吗？

而是关于授权：

如果代理用这个权限做出错误决策，它能影响什么——以及我们能多快地恢复？

你会为你的工程环境中的编码助手在哪里划定这个边界？