Mozilla AI Agent Infrastructure 将规则置于模型判断之上

Mozilla AI 对编程智能体背后的一项核心假设提出了挑战：仅靠更好的模型判断，无法让委托执行的软件工作变得安全。

随着智能体获得检查代码仓库、编辑代码、运行测试及准备拉取请求的权限，其关于智能体基础设施的论述也随之而来。这些能力可以将数小时的工作压缩至几分钟，但也让概率性系统得以操作会带来持久后果的任务。

Mozilla AI 的智能体基础设施主张，将竞争焦点从能力与能力的对比，转向指令与可执行控制之间的对比。AGENTS.md 文件可以告诉智能体应当做什么；只有基础设施能够阻止它采取绝不能采取的行动。

这一差异给每一家正在扩大智能体自主权的组织带来压力。OpenAI、Anthropic、Google、GitHub 以及独立开发者都提供了不同的智能体体验。然而，每一项部署最终都要面对同一个问题：当模型误解一项规则时，哪些事情依然成立？

Mozilla AI Agent Infrastructure 改变了什么

Mozilla AI 正将有关智能体的讨论，从模型智能转向围绕每一次模型决策的系统。

编程智能体不再只是聊天界面。它们可以搜索代码库、修改多个文件、执行 shell 命令、运行测试套件，并组装一项拟议变更。有些系统还能在开发者处理另一项任务时持续工作。

更广泛的工作范围，使基础设施成为产品的一部分，而非实现细节。聊天窗口中的错误答案会带来一种风险；拥有代码仓库、网络或凭证访问权限的错误命令，则会带来另一种风险。

Mozilla AI 的介入之所以重要，在于它区分了团队经常混为一谈的三项职责。指令描述期望的行为；模型解读这些指令；基础设施决定哪些行动在技术上可行。

这一区分听起来简单，但许多智能体部署颠倒了这种层级关系。它们先授予广泛访问权限，再要求模型通过自然语言规则保持克制。这样的设计使模型既是执行者，也是自身最主要的控制系统。

一项代码仓库指令可能会要求，绝不直接从功能分支发布。它可能要求在修改身份验证代码前获得批准，也可能禁止读取特定目录之外的文件。

当智能体能够正确读取、解读并确定这些规则的优先级时，这些表述能够改善其行为。但它们无法建立操作系统边界、网络策略或审批关卡。模型仍然可以请求违反书面规则的操作。

被广泛采用的智能体指令格式为项目上下文提供了一项有用的约定。其公开网站将 AGENTS.md 描述为构建命令、测试说明、约定和安全注意事项的固定位置，并称其已被超过 60,000 个开源项目采用。

这种采用规模说明了可移植指令的重要性。团队不应为每一种编程产品重写相同的代码仓库指引。共享格式让规则能在不同智能体之间流转，并在代码旁保持可见。

不过，可移植性并不会把文字变成强制执行机制。Markdown 对 shell、云账户、软件包注册表或生产数据库没有约束力。它影响阅读它的模型，而运行时环境仍控制着可触及的世界。

因此，Mozilla AI 指出了一个缺失层：智能体部署需要模型循环之外的控制机制，在那里，错误的解读无法悄然为自己授予例外。

这并不会降低 AGENTS.md 的价值，反而让该文件的职责更明确。指令应传达意图，而基础设施应执行围绕该意图的边界。

这种实践上的逆转意义重大。团队一直将更强的推理能力视为实现更安全自主性的路径。Mozilla AI 则认为，可靠的自主性始于承认推理有时会失败。

编程智能体将建议转化为副作用

智能体能完成的工作越多，就越不能把良好判断当作最终安全边界。

传统代码助手主要提出供人审查的文本建议。开发者决定是否插入建议、运行命令或将变更提交至上游。人为操作构成了一道天然的检查点。

智能体工具则压缩了这些检查点。一项任务即可触发文件发现、依赖安装、代码生成、测试执行和代码仓库操作。每一步都会创造影响下一次模型决策的新上下文。

这一循环之所以有用，是因为软件工作很少能装进一次提示和一次回答之中。智能体必须观察结果、修正假设并尝试另一种方法。同一循环也会放大早期错误。

设想一个被要求修复失败集成测试的智能体。它可能检查环境文件、启动服务、更新依赖项并重新生成快照。一项含糊的指令，就可能让它远远超出目标测试的范围。

这种失败不需要恶意行为。智能体可能推断破坏性清理命令属于常规操作，也可能把测试凭证理解为可随意处置，或者信任从议题、依赖项或网页中检索到的文本。

提示注入使最后一种情形尤其重要。智能体可能在被要求处理的内容中遇到恶意指令。模型随后必须在继续工作时区分任务数据与命令。

自然语言指引有所帮助，但模型仍是负责判断其他自然语言是否可信的组件。将最终边界置于此处并不稳定。

执行基础设施可以缩小后果范围。OpenAI 的沙盒架构将可信执行框架与模型指令驱动命令所运行的环境分离开来。该框架可以在执行容器之外负责审批、追踪、恢复和状态管理。

这种分离说明了更广泛的机制。智能体可以在某个环境中工作，却不会自动继承组织可用的每一项凭证或资源。基础设施负责调节跨越边界的内容。

被指派更新文档的编程智能体不应需要软件包发布凭证。修复一项服务的智能体不应自动访问无关代码仓库。编写测试的任务不应携带生产数据库权限。

这些是能力决策，而不是提示词编写决策。能力是运行时允许的操作，例如写入某个目录或调用获批准的端点。良好的基础设施会根据当前任务授予能力。

压力首先落在平台和安全团队身上。开发者希望智能体在更少监督下行动，因为自主性带来了生产力收益。安全团队则必须确保减少监督不会变成无限权限。

这同样会影响供应商。精致的智能体界面可能掩盖薄弱的操作控制。买方必须超越基准测试结果，了解系统如何处理身份、凭证、审批、日志、重试与恢复。

同一问题也影响个人开发者。本地智能体可能看似受到限制，因为它运行在一台笔记本电脑上。然而，这台机器可能存有源代码、浏览器会话、云凭证、个人文档和签名密钥。

智能体不需要管理员权限也能造成实质损害。它只需要一项权限高于任务所需的凭证。基础设施必须让这种权限不匹配更难发生。

因此，这则新闻并非只是再次呼吁负责任的 AI。Mozilla AI 正将责任从模型行为转移至系统设计。这让责任落在组织能够检查和测试的组件上。

AGENTS.md 说明规则，但无法执行规则

核心冲突如今已十分明确：指令文件表达人的意图，而运行时控制决定智能体实际能够做什么。

AGENTS.md 解决了一个真实的协作问题。编程智能体需要命令、代码仓库约定、验证要求和本地警告。将这些上下文保留在代码附近，可使其可见、可版本控制且可复用。

这种格式还让团队能够在大型代码仓库中定义更细粒度的指令。某项服务可以采用与代码仓库根目录不同的测试命令或限制。这类似于人类早已使用的分层文档体系。

但每条指令仍要经过模型解读。智能体必须找到相关文件、解决相互重叠的规则、将它们应用于当前任务，并在长时间执行过程中记住它们。

这条链路中的任何失败都可能削弱规则。文件可能不完整，上下文可能被截断，嵌套指令可能与根指令冲突，模型也可能过度泛化某项例外。

即便完美遵循指令，也无法解决所有问题。一条规则可能要求在发布软件包之前取得批准，但智能体仍需要可靠的审批机制，以及有权批准的身份。

如果批准只是上下文中的另一条消息，不可信内容就能仿冒它。更强的系统会将批准表示为模型无法伪造的外部状态。运行时会在放行操作前检查这一状态。

同一原则也适用于支出限制。要求智能体节省 token 是有用的指引；而当循环运行时间超出预期时，由控制平面执行的预算仍会有效。

可审计性揭示了另一项限制。指令可以要求智能体解释自己的选择，但这种解释并不会自动成为工具输入、权限状态、文件变更、重试或被拒绝操作的完整记录。

可靠的审计轨迹必须捕获智能体叙述之外的事件。它应显示哪个身份请求了操作、评估了什么策略、哪些输入进入工具，以及返回了什么结果。

记录还应保留失败信息。一个在找到允许路径前尝试了三项被禁止操作的智能体，与一个立即选择允许路径的智能体，呈现的是不同情况。仅看最终输出会掩盖这种差异。

这在事件发生期间尤为重要。团队需要重建智能体当时看到了什么，以及它在那一刻拥有什么权限。如果策略、提示词或凭证在之后发生变化，当前文档并不足够。

因此，基础设施应将操作绑定至特定运行、策略版本、工具版本和审批状态。这使后续审查更少依赖记忆或重建的聊天记录。

日志也支持工程改进。团队可以识别反复需要人工干预的命令、产生误报的策略，以及超出预期范围的任务。这些模式可以指导更严格的权限和更好的工作流。

开发者仍需要编写良好的指令。目标并不是用僵化策略取代人的意图。许多软件决策需要无法通过文件系统规则捕获的上下文。

更好的设计是让每一层承担恰当职责。AGENTS.md 告诉智能体项目如何运作。策略层则决定一项拟议操作是否符合任务允许的范围。

沙箱会限制暴露给执行环境的资源。审批服务负责处理具有重大影响的例外情况。审计系统记录决策及其结果。

这些组件共同确保规则能够经受模型替换。团队可以更换代理，而无需在另一家供应商的提示词格式中重新构建最重要的边界。

这种持久性是 Mozilla AI 论点的核心。模型会频繁变化，而代码库所有权、合规责任和生产风险则会持续得更久。

控制平面成为真正的安全机制

可靠的代理基础设施会在模型请求与每一项具有重大影响的工具操作之间设置可强制执行的策略。

控制平面是负责管理访问、策略、路由、预算和运行状态的可信层。模型可以提出操作建议，但由控制平面决定是否执行以及如何执行。

这种架构始于身份管理。每次代理运行都需要一个与人工操作员及其他自动化流程相区分的身份。共享凭据会使归因变得困难，也会让权限撤销不够精确。

下一个要求是最小权限原则。每项任务只能获得其所需的文件、命令、服务和网络目标。权限应随任务到期，而不应继续保留给未来的运行。

OpenAI 的沙箱安全指南建议采用隔离工作负载、受限的出站流量、分离的凭据，以及对第三方服务的经纪式访问。这些控制独立于模型意图而运作。

经纪式凭据尤其有用。执行环境可以发送已获批准的请求，却无需看到可重复使用的密钥。受信任的代理仅为获准目标提供凭据。

这种设计降低了意外泄露的价值。如果生成的代码打印其环境，长期有效的生产密钥无需出现。撤销操作也在凭据代理处进行，而不是在每个工作空间内部执行。

工具中介机制提供了另一个执行点。基础设施可以验证参数、拒绝危险路径、限制请求速率，并要求对特定操作进行审批。

Mozilla AI 通过 mcpd policy plugins探索了这种模式。Mozilla 将身份验证、验证、速率限制和日志记录描述为可置于代理与工具服务器之间的功能。

这一位置很重要，因为 Model Context Protocol 服务器可以暴露跨文件、数据库和外部应用程序的操作。中央中介层可以实施一致的策略，无需信任每个代理都能自行复现这些策略。

成熟的控制平面还会管理状态。代理工作流可能在完成部分操作后、记录成功前失败。盲目重试整个任务可能会重复产生外部副作用。

基础设施应当了解哪些步骤已经完成，哪些仍可安全重试，以及哪些需要对账。创建拉取请求、发出付款指令或向客户发送消息，并不总能像读取本地文件一样被重复执行。

人工审批应设置在特定边界处，而不是每一步之后。持续请求审批会抹去委派的大部分价值。完全不审批则会让具有重大影响的决策完全留在模型循环之中。

有用的中间方案是基于风险的升级机制。读取代码库可以自动进行。在临时分支内写入也可以继续。发布、部署、修改权限或联系客户，则可能需要明确授权。

策略应检查操作周围的上下文。一条命令在隔离测试环境中可能可以接受，但针对生产环境则应被禁止。网络请求可能被允许用于查阅文档，却应被阻止访问未知端点。

预算也需要类似的强制机制。协调多个子代理的代理，其成本增长速度可能快于监看一个聊天窗口的人。控制平面可以按任务、团队、提供商或结果设定上限。

Mozilla AI 的开放控制平面将这一治理论点与模型路由联系起来。Otari 被定位为跨提供商进行路由、预算管理、访问控制、部署和故障转移的一层。

路由不仅是成本优化。不同任务可能需要不同的隐私边界、延迟目标或模型能力。基础设施可以一致地应用这些选择，而不是将其分散嵌入整个应用代码中。

这种方法也提高了可移植性。组织可以替换模型，而不会放弃其策略逻辑、历史追踪记录或运行控制。代理成为组织自有系统中的一个组件。

对于工程团队而言，这可以保留机构知识。可搜索的技术知识库可以保存架构决策和本地文档。运行时策略仍必须控制代理如何使用这些知识。

关键在于分离。知识为模型提供信息。策略约束其操作。审计记录发生了什么。恢复机制处理未完成的工作。

没有任何单一组件能让代理变得可靠。控制平面协调这些组件，以避免一次错误判断决定整个结果。

开放基础设施带来控制，而非自动安全

拥有代理技术栈可以提高可检查性和可移植性，但开放代码本身并不能消除运行风险。

Mozilla AI 将基础设施控制与开放性联系起来。这种联系可以理解。如果控制系统只存在于某一家供应商的服务边界之后，组织就无法全面检查、修改或保留它。

开放基础设施可以减少供应商锁定。团队可以在更换模型提供商时保留策略。他们可以检查执行代码、添加集成，并在自己控制的环境中部署敏感组件。

它还可以让治理更贴近承担风险的组织。医院、银行、公共机构或软件公司可能需要不同的审批规则和保留策略。一项托管默认设置无法代表所有义务。

然而，所有权也意味着责任转移。自托管控制平面需要安全更新、访问审查、备份、监控和经过测试的恢复机制。过时的开放组件可能成为新的弱点。

透明度并不保证配置正确。团队可能部署具有宽松默认设置、共享凭据、不完整日志或不受限网络访问的可检查软件。源代码可以是开放的，部署却仍然不安全。

日志也会带来自身的权衡。丰富的追踪记录有助于调查，但也可能捕获专有代码、个人信息、提示词和工具结果。无限期保留所有内容可能与隐私和数据最小化目标相冲突。

团队需要明确的保留边界。他们应记录足以确定责任的信息，同时避免让审计系统变成每一项敏感输入的永久副本。

策略复杂性是另一项风险。庞大的规则集可能难以推理。重叠的例外情况可能造成漏洞，而过度严格的控制则可能驱使开发者转向未经批准的工具。

答案并不只是增加更多策略。团队需要与具体风险相关联、规模小且可测试的控制措施。每条规则都应有负责人、制定理由和验证方法。

模型行为同样仍然重要。基础设施可以阻止被禁止的操作，但无法保证产出有用的代码。代理可能在权限范围内活动，却仍然给出错误实现或遗漏重要要求。

因此，测试和人工审查仍是系统的一部分。私有或独立维护的评估案例可以帮助发现那些只针对可见检查进行优化的代理。代码所有权规则可以将敏感变更路由给合适的审查者。

这正是 Mozilla AI 代理基础设施论点的审慎边界。更好的基础设施能够控制故障、保留证据并使恢复成为可能。它不会将不确定的推理转化为确定性的软件工程。

组织还应避免将审计日志视为安全性的证明。详细记录可以准确展示事件如何发生。要防止事件发生，行动之前就需要可强制执行的控制措施和经过验证的策略。

谁来控制控制平面，也涉及治理问题。中央策略可以保护组织，但也可能形成不透明的内部权威。开发者需要了解操作为何被拒绝，以及例外如何运作。

开放实现有助于进行这种审查，但流程同样重要。策略变更应经过审查、测试和版本控制。紧急覆盖应会过期，并在记录中保持可见。

最有力的方法是将开放性视为一种所有权模式，而不是安全标签。组织获得检查和修改系统的能力，也接受将其良好运行的责任。

这种权衡比承诺自动安全更可信。它承认，可靠的委派来自工程纪律，而不是某一项产品功能。

三个信号将检验 Mozilla 的基础设施论点

下一项检验在于，代理平台能否将基础设施原则转化为开发者无需拖慢日常工作即可验证的默认能力。

第一个信号是任务范围权限的普及。观察编程代理是否获得对指定代码库、目录、命令和网络目标的临时访问权限。即使供应商在其他方面宣传安全，广泛的机器级权限也会在实践中削弱 Mozilla AI 的论点。

第二个信号是证据质量。平台应暴露关于工具调用、审批、策略决策、文件变更和重试状态的持久记录。仅有聊天记录无法回答某项操作发生时拥有哪些权限。

第三个信号是可移植性。团队在切换模型或部署环境时，应能够保留策略、追踪记录和工作流状态。如果治理仍绑定于单一提供商，模型选择依然会控制周边系统。

这些信号彼此强化。范围受限的权限减少可能造成的损害。审计记录揭示这些边界是否有效。可移植性防止这些边界在下一次模型迁移中消失。

开发者还应关注日常工作流摩擦。一个不断中断低风险操作的控制层将面临阻力。一个隐藏策略决策的控制层则难以获得信任和调试。

成功的系统将让安全操作成为常态，让例外操作明确可见。它们将允许代理在有边界的环境中读取、推理、测试和准备变更。它们会在具有外部或不可逆后果的操作前暂停。

当这些功能成为标准产品预期时，Mozilla AI 的代理基础设施论点将得到加强。如果代理不断获得权限，而控制措施仍只是可选仪表板或提示词模板，这一论点则会被削弱。

对于现在采用编程代理的团队，眼前的问题并不是最新模型的分数是否更高。应当问：代理能接触什么，哪些操作需要审批，以及每项决策能否在之后被重建。接着再问：这些保护措施属于你的组织，还是会随供应商一同消失。更好的 AI 仍将有用，但基础设施决定了这种智能能否被负责任地委派。