You Don’t Just Need Better AI. You Need Better Infrastructure.

你不仅需要更先进的 AI，还需要更完善的基础设施

专家观点

如今，编码代理可以编辑代码库、运行测试并创建拉取请求，但 AGENTS.md 文件中的规则是指导原则，而非约束条件。随着我们越来越多地将任务委托给代理，我们需要在模型判断失效时依然有效的限制机制，需要记录每一次决策，并拥有开放的基础设施，使规则能够超越任何代理的生命周期。

#### Alejandro Gonzalez

2026 年 10 月 5 日

—

4 分钟阅读

两年前，让 AI 系统代表你执行操作还只是实验。如今，编码代理已能编辑代码库、运行测试并创建拉取请求。我们赋予它们访问文件、工具和凭证的权限，然后要求它们自行完成工作。

一段时间内，人们关注的是模型是否能达到我们的标准。但更困难的问题是：在执行过程中，模型应该被允许做哪些事情？以及我们如何在事后确认它始终遵守这些限制？

我们已经习惯了将执行任务的权限委托给代理。但我不确定我们是否已经理清了这种委托对责任划分意味着什么。

权限鸿沟

我们赋予编码代理的许多规则都包含在描述代码库规范的 AGENTS.md 文件中，或包含在解释它们应避免操作的系统提示中。代理会将这些指令与上下文其他内容一同阅读，并自行决定如何应用它们。如果没有其他机制强制执行这些规则，我们只能依赖代理对规则的解读贯穿整个任务。

“模型能做什么？”是一个有明确基准的问题。它有评分、图表、发布文章和一周的讨论。每个实验室都在这个领域竞争，因为它是一个可以“赢得”的问题。

“模型被允许做什么？”则更难以衡量。答案取决于组织、任务和委托人。治理领域没有排行榜，因此它通常不会引起关注，直到出现问题发生。

现有权限仍然重要。代理无法访问其凭证不允许访问的系统。但这些权限范围通常远超任务需求。拥有写入代码库的权限，并不意味着代码库中的每一次修改都被授权。

指令不等于约束

一份精心撰写的 AGENTS.md 文件可以用极简的机制引导代理遵循代码库规范、测试要求和工作流程。但指令和约束是两种截然不同的事物，这种区别并不单纯取决于模型能力的强弱。

一个代理 99% 的时间都遵守某条规则，听起来非常理想。但当这条规则需要应用于数千个相关操作时，那剩下的 1% 就会成为运营问题。权限边界的本质在于：合规性不应完全依赖于发起请求的软件的判断。

当规则规定“不要修改生成的文件”时，代理会自行判断这份文件是否属于生成文件。它可能还会认为任务本身暗示了例外情况，或认为小幅修正并不构成修改。如果我明确禁止了某项更改，就不希望代理自行判断这个特定情况是否合理。我希望操作立即停止，并记录是哪条规则阻止了它。

某些决策需要解释。我们委托代理执行任务，部分原因是我们希望代理能行使判断。但我们需要明确哪些判断被委托，哪些限制仍然超出代理的裁量范围。

赋予代理执行任务的责任不应等同于允许其重新解释与该任务相关的所有限制。执行这些限制的检查机制必须独立于其推理过程运行。

Raffi Krikorian 在最近的一篇论文中精准概括了这一区别："一个句子指引方向，但不会设限。" 他描述了将编码代理与个人系统凭证分离的实践，通过本地运行的代理来中介访问权限。但他也指出了遗留问题：将密钥存储在其他位置虽能实现隔离，但让另一个模型来判断允许范围，仍会将判断权留在系统内部。

随着模型对惯例的理解、对敏感数据的识别能力提升，以及知道何时需要介入人类判断的能力增强，我认为这将避免大量错误。但当我们改进应用程序编写时，并未移除数据库权限。随着我们赋予代理更多访问权限并监督更少的单个步骤，系统将越来越依赖于即使在判断错误时仍能生效的限制机制。

决策记录

执行规则解决了问题的一部分。但当代理做出意外行为时，你还需要重建它是如何被允许发生的过程。如果它修改了本应保持不变的文件，这个修改本身提供的信息非常有限。可能是规则缺失了，可能是例外被批准了，或者操作可能通过了检查机制从未覆盖的路径。这些情况可能导致相同的结果，但需要截然不同的应对方式。

代理自身的解释无法解决这个问题。"我遵循了仓库的惯例"是一个可能需要调查的声明，而要求代理解释自身只会提供来自同一系统的另一份说明。工具追踪提供了更可靠的依据：它可以显示被请求的操作以及后续发生的事情。但除非策略决策被记录在案，你仍然不知道适用了哪条规则、生效的是哪个版本，或者该操作是被允许、拒绝还是仅仅被警告。

评估规则的系统应留下足够的证据，将尝试的操作与管控它的策略以及后续的决策联系起来。这不一定能解释模型为何选择特定方法，但应能让我们在不依赖模型记忆或拼凑可能已变更的设置的情况下，明确系统为何允许该操作。

每项代理操作都应有记录可查。

值得拥有的内容

我之前曾论证过开源不是一种美德，而是一种所有权模式。该论点聚焦于连接应用程序与模型的基础设施：路由、凭证以及在提供商改变方向时保持运行的能力。

当基础设施开始管控操作时，这一论点变得更具现实意义。

模型、代理和接口将持续更迭，但描述你的系统可以执行哪些操作的规则，以及记录它们实际执行了什么的文档，将超越所有这些技术。它们共同构成了你的运营策略及其应用方式的完整记录。

更换代理不应意味着需要重建规则，调查旧决策也不应需要访问你已不再使用的产品。这两点都是你可能需要长期运营的基础设施的常规要求。

开放本身并不能使这一层变得可信。这意味着你可以检查它，在自己的边界内运行它，即使供应商消失，你仍然可以保留它。但实现方式仍需赢得你的信任。

这些问题正在塑造我们在 Mozilla.ai 对 Otari 的工作，包括最近在代码代理方面基于仓库定义规则的 Agent Guardrails 工作。

我预计未来几年我们将使用的代理会发生显著变化。我希望我们能够更改它们，而不会失去对它们所遵循规则的控制，或对它们所做事情的记录的访问权限。

在 GitHub 上探索 Otari。