Otari AI 治理：Mozilla AI 将模型选择与 Agent 限制整合至同一网关

Mozilla AI 于 11 月 4 日概述了其 Otari AI 治理方案，将模型选择与对 Agent 工具及支出的限制纳入同一体系。该公司将 Otari 描述为一个治理操作系统，尽管产品本身是一个开源网关。网关位于应用程序与 AI 服务之间，为路由请求和应用规则提供统一入口。

这一方案旨在解决一个实际矛盾：团队希望能够自由更换模型，而无需重建围绕模型设置的控制机制。Mozilla AI 表示，Otari 集成了工作区权限、预算检查和使用情况可见性。这对由每个应用程序自行维护供应商连接和保障措施的做法构成了挑战。

Otari 进入的是一个已有成熟产品的领域，LiteLLM 等替代方案已提供集中式访问和支出控制。真正的问题在于：当 Agent 能够选择下一步行动以及下一次付费请求时，决策权应归属于何处。

Otari AI 治理将模型选择与权限整合

Mozilla AI 将模型访问和 Agent 权限视为同一项基础设施决策的组成部分。

在其 AI 治理公告中，Mozilla AI 描述了涵盖允许使用的模型、网页搜索、代码执行及必需检查项的工作区规则。该公司表示，被标记的请求可在到达供应商之前被拦截。预算可关联至用户和应用程序密钥，即应用程序用于访问网关的凭据。

这些能力界定了该产品预期承担的边界。开发者可以围绕统一访问入口构建应用程序，管理员则决定这些应用程序可使用哪些服务。更换模型与赋予 Agent 另一项能力，因而成为相互关联的决策。

这一差异很重要，因为模型的回答与 Agent 的权限会带来不同的责任。错误的草稿或许只需编辑；错误的操作则可能在任何人审查结果之前，就修改记录、暴露信息或启动额外工作。

共享网关让组织能够在与模型的对话之外表达限制条件。这改变了谁来作出最终访问决策：应用程序可以请求某项能力，但基础设施可以拒绝该请求。

设想一个假设的客户支持助手，它使用经批准的文档起草回复。其既定任务并不自动意味着它应当获得无限制浏览器或执行环境的访问权限。即使这些能力能提升其在无关任务上的表现，也需要独立的授权依据。

这个例子也揭示了围绕自主性讨论中常见的模糊之处。向 Agent 提供更多有用信息，与允许它采取更多行动并非一回事。产品可以通过更好的文档变得更有帮助，却不必获得修改客户记录的许可。

因此，对于询问 Otari 是什么的读者而言，更有用的答案在于其架构定位。它是一个协调 AI 应用程序访问决策的场所，而 Mozilla AI 将治理与供应商选择一并定位。

“操作系统”的说法仍是一种比喻。买家应将其理解为对协调能力的主张，而非 Otari 能管理组织所有 AI 活动的证据。数据访问、应用程序行为和业务审批仍需有明确的责任人。

这项 11 月的公告最好被理解为一份产品方向声明。它说明 Mozilla AI 希望团队控制什么，以及这些控制应部署在哪里。它并未证明该产品在安全性、可靠性或运营成本方面已有独立测量的改善。

实际变化在于，应用程序团队与平台所有者之间形成了更明确的约定。开发者通过接口请求访问；管理员界定允许的范围。这一约定是否有效，取决于应用程序实际使用的路径。

平台团队承接 Agent 无法自行作出的决策

集中式访问让责任更加可见，但仍需有人界定每项工作流应获得何种权限。

直接的压力落在平台工程师、安全团队和应用程序所有者身上。他们必须将“负责任地使用 AI”这类宽泛要求，转化为关于凭据、允许服务、支出和审查的具体决策。

Mozilla AI 此前的 Agent 基础设施观点区分了指令与约束。书面规则告诉 Agent 应如何行动；强制执行的限制则决定它实际上能够做什么。

当工作流处理由外部人士提供的材料时，这一区分尤为关键。提示注入是指内容试图重定向模型行为，而非仅仅提供信息。因此，支持工单、检索到的文档或网页都可能成为不受欢迎指令的来源。

基础设施层面的限制并不要求模型识别每一段恶意内容。如果工作流没有使用某项特定能力的权限，即使模型判断失误，这一边界仍可发挥作用。

OWASP 的 过度代理指导将过度功能、权限和自主性列为造成破坏性操作的独立原因。其建议包括限制工具、收紧下游权限，并对具有重大影响的操作要求审批。

这是独立的安全指导，并非对 Otari 的认可。它支持将限制置于模型判断之外的根本理由，也说明网关为何应融入更广泛的权限体系。

设想一个能够搜索公开材料并总结发现的研究助手。其所有者或许可以合理批准网页访问，但不授予其向外部发布结论的权限。查找信息与代表组织发声，是不同的责任。

集中控制点有助于显露这种差异，但它并不会替组织决定政策。仍需有人确定助手可以访问哪些信息、哪些输出需要审查，以及由谁处理例外情况。

对于知识工作者而言，这与 个人知识库和共享组织资源之间的区别直接相关。有用的检索并不自动意味着可以扩大访问范围或获得采取行动的许可。

因此，应用程序所有者面临的压力是具体的。他们需要足够准确地描述工作流，才能让权限匹配其目的。“研究 Agent”这类标签提供的指引，远少于对获准输入和允许输出的清晰说明。

安全团队也承担相应责任。限制应足够易于理解，使开发者能够预测应用程序的行为。无法解释的拒绝会增加排障难度，并促使人们请求更广泛的访问权限。

财务和运营团队也应参与讨论，因为 Agent 的选择可能持续产生付费活动。他们需要将消耗与负责任的工作流关联起来的归因机制。缺乏明确责任人的共享凭据会削弱这种问责。

Otari AI 治理将这些决策拉得更近。其组织层面的结果是共同责任：应用程序团队定义工作，平台团队执行边界，业务所有者决定哪些结果足以证明继续授予访问权限是合理的。

Otari 与 LiteLLM 的比较聚焦于执行细节

有意义的比较在于控制措施在部署中如何运作，而不是产品是否列出了预算和模型路由功能。

LiteLLM 是一个有用的参照，因为其文档已描述集中式支出控制。其 预算执行文档涵盖个人、团队、团队成员和 Agent 预算，同时指出预算执行依赖于已连接的数据库。

这一前提说明，仅凭功能名称无法完成比较。仪表盘可以显示预算，但底层部署可能缺乏执行预算所需的状态。运营人员需要了解每项控制措施得以成立的条件。

因此，对 Otari 与 LiteLLM 的评估应从应用程序的实际请求路径开始。哪些凭据用于识别调用方？哪些限制适用？当会计信息不可用时会发生什么？这些答案比冗长的受支持集成列表更重要。

这也是集中式基础设施与各应用程序分别嵌入保障措施的区别所在。独立实现可以满足本地需求，但每个实现都需要维护。共享控制点为跨这些应用程序的一致行为创造了机会。

当团队更换供应商或引入另一种工作流时，这种一致性具有价值。管理员应能够判断此类变更是否保留既有规则。否则，每一次集成都可能成为政策逐渐偏离的另一个机会。

Mozilla AI 表示，Otari 提供一个统一的应用程序编程接口，即 API，应用程序通过它访问模型。该公司还描述了当供应商不可用时重新路由请求的回退规则。

回退可以维持可用性，但也可能改变任务的其他属性。替代模型可能以不同方式遵循指令、生成不同的回答格式，或需要额外审查。因此，维持服务并不等同于维持等效行为。

这正是更换供应商仍应作为经过测试的运营决策的原因。接口可以减少集成工作，却无法消除评估输出质量的必要性。应用程序仍然依赖模型如何理解其指令，以及如何使用可用工具。

同样的逻辑也适用于开放权重模型，其模型参数可依照适用条款获取和使用。仅能访问这些参数，本身并不能提供应用程序所期望的周边服务。

Mozilla AI 关于 开放模型基础设施的讨论，将搜索和代码执行等工具视为缺失的周边层的一部分。其观点是，当应用程序能够继续使用这些能力时，模型选择会变得更具可行性。

对买家而言，这意味着应在等效条件下比较已完成的工作。一款能快速给出看似合理答案的模型，仍可能需要大量核查；另一款模型则可能以更少的修改完成同一项任务。

这些差异会影响供应商可移植性的价值。只有当组织也能判断替代方案是否符合其要求时，轻松路由才最有意义。没有这种评估，更换能力大多仍停留在理论层面。

因此，Otari 与 LiteLLM 的比较是部署层面的比较，而非对谁是赢家的宣告。允许的工作流及其故障条件都应决定评估结果。无论是文档还是功能清单，都无法证明哪款产品会在特定环境中表现更好。

预算控制取决于请求所经过的路径

支出限额的有效性取决于其核算规则、覆盖范围，以及在并发请求下的表现。

Otari 的预算安全说明提供了一些限定条件，值得与公告内容一并关注。其中描述了针对并发、按 token 计价及图像请求的成本预留机制。Token 是模型在处理、生成文本时使用的单位。

预留机制会在工作被派发前核算预估成本。当请求同时到达时，这一点十分重要：每个请求都不应假定自己可以使用同一笔剩余额度。

安全说明还将这些预留与事后导入、批处理以及当前尚未预留的固定价格路径区分开来。这些路径并未被描述为严格的实时上限。因此，承诺的适用范围至关重要。

这并不意味着预算控制没有帮助。它意味着其运行边界本身就是采购决策的一部分。团队应了解其预期工作负载是走预留路径，还是依赖后续才发生的核算。

例如，设想一款假设性的文档处理应用以批处理方式提交任务。其运营者不应仅因它与交互式助手出现在同一支出仪表板中，就认为两者的行为相同。

关键在于系统何时承诺执行工作。如果核算发生在该承诺之后，显示出的余额与请求前限制所承担的作用便不同。二者都能支持财务管理，但回答的问题并不相同。

模型定价是另一项依赖条件。Otari 的安全政策称，默认必须提供定价信息；根据已记录的规则，未定价模型的请求会被拒绝。这是一项具体的保障措施，可避免将未知成本视为零成本。

不过，运营者可以调整配置，而同一份说明也指出了例外情况。部署评估需要依据实际生效的设置和真实端点，而不能仅凭默认配置作出假设。

更广泛的教训是，成本控制属于请求处理的一部分。它依赖身份、定价信息、核算状态，以及工作获准执行的时点。仅靠报告无法建立所有这些条件。

人工审查带来了另一层边界。即使代理始终处于支出额度内，仍可能生成不可用的输出。预算限制的是风险暴露；它并不能证明这项工作值得花费。

这种区别应影响内部报告方式。应用负责人需要将使用情况与被接受的结果、修正工作和放弃的尝试关联起来。否则，即使工作流只是完成了更少的有用工作，较低的消耗也可能看起来像是成功。

团队比较模型时也应采用同样的审视标准。一次更便宜的请求，若导致反复重试或大量清理工作，可能形成昂贵的工作流。真正相关的价值单位是已完成的任务。

Otari AI governance 为团队协调这些决策提供了一个拟议的场所，但其安全文档限制了对“控制”一词的宽泛解读。采购方在编写需求时应保留这些限定条件。

负责任的评估应在获得授权的环境中测试常规请求和边界条件。结果应明确哪些行为会被停止、何时停止，以及哪些活动仍不受严格上限约束。

这样的证据比简单宣称存在预算功能更有价值。它能将产品记录在案的机制与组织实际面临的财务风险联系起来。

追踪使可见性与内容留存之间出现取舍

团队需要区分：看见发生了什么，与保留代理读取或生成的全部内容，并不是一回事。

会话追踪会将活动关联为一条时间线，使运营者能够调查工作流的推进过程。Mozilla AI 的公告称，追踪不会存储提示词、回复或工具结果。这是其所述可见性方案的重要组成部分。

然而，项目的发布历史增加了一项限定。日期为 11 月 4 日的 0.38.0 版本列出了对保留明确要求此功能的路由请求内容的支持。

这些表述不应被合并解读为对存储的无条件承诺。公告描述的是一种内容最小化方法，而发布说明则显示存在可选的内容留存能力。因此，部署选择值得关注。

对运营者而言，这些模式支持不同的调查方式。时间线可以帮助定位失败的请求或路由变化。要还原某个回答为何包含特定错误，可能需要了解所涉及的材料。

这形成了现实中的张力。保留较少内容可以减少为调试而收集的敏感材料；保留更多内容则能让某些事件更容易理解。任何一种偏好都无法满足所有运营需求。

设想一个处理内部研究的假设性助手，就能具体说明这种取舍。其活动记录可能表明哪个服务处理了请求，以及请求是否失败。要理解一份误导性摘要，也可能需要检查原始段落。

组织应决定这些调查材料应存放在何处。它们可能已存在于应用自身的记录中，并受到独立的访问限制约束。在另一套系统中复制它们，会增加一个需要治理的位置。

这正是为什么关于追踪的说法不能替代覆盖全组织的数据留存政策。应用、模型服务、搜索服务和执行工具可能在工作流中处于不同位置。

网关的配置与这一全景有关，但它无法描述所有其他组件。团队应在承诺信息会流向何处或持续保存于何处之前，先绘制所涉及的服务图谱。

运营可见性与输出问责之间也存在区别。追踪记录可以证明某项操作发生过。要判断该操作是否恰当，仍需要结合工作流的目的及其治理规则。

调查事件的审查人员应能将活动关联到相关应用及其责任人。否则，即使时间线很详细，仍可能难以解读。

同样的原则也适用于被阻止的操作。当获授权的运营者能够理解是哪项规则导致拒绝时，拒绝会更有用。这支持修正问题，而不会自动扩大代理的权限。

开源可用性带来了审查实现选择的机会。但它不能证明每个已部署实例都使用相同配置，或保留相同信息。

对采购方而言，结论很具体：询问启用了哪种追踪模式、谁能更改它，以及谁能查看产生的记录。这些答案能将笼统的隐私主张转化为运营承诺。

这种选择应遵循工作流的敏感性和调查需求。公共研究助手与处理机密文档的助手，无须保留相同的证据来支持负责任的运行。

接下来应关注什么：执行证据、可移植性与采用情况

当用户能够将 Otari 的控制措施与真实工作流中可观察到的行为联系起来时，其进展将最为清晰。

未来几个月首先值得关注的信号，是可复现的执行证据。有用的报告应展示某个具名部署如何处理被拒绝的工具、耗尽的预算和并发请求，并应说明版本及相关配置。

这将通过把文档化的控制措施与观察到的结果联系起来，强化 Mozilla AI 的价值主张。即便最终结果听起来令人鼓舞，若报告省略请求路径或设置，其可信度也会较低。

最具信息价值的示例既应包括尝试跨越边界的情况，也应包括正常运行。成功的回答证明其有用性；被恰当地拒绝的请求则证明在测试条件下，某项特定限制确实生效。

第二个信号是在等效约束下的提供商可移植性。团队应寻找这样的比较：应用保持相同任务、允许使用的工具和审查标准，同时更换其背后的模型。

这将揭示更容易的路由是否转化为实际选择。如果切换仍需要大规模修复工作流，那么集成收益依然存在，但会比操作系统的比喻所暗示的范围更窄。

输出质量仍应是评估的一部分。若提供商变更保留了接口，却增加了修正工作，就会在别处制造工作。当组织能够接受由此产生的行为时，可移植性才具有价值。

第三个信号是由明确运营责任支撑的持续采用。相关案例应说明谁维护网关、审查政策变更、调查故障，以及决定代理是否应获得更广泛的访问权限。

这些细节将表明，集中式治理是减少了重复工作，还是仅仅将其转移。一个有说服力的部署案例应在说明收益的同时，承认维护工作和例外情况。

这也是开源方法变得可检验的地方。组织可以审查软件并选择自行运行它，但必须有人负责更新、配置和事件响应。

稳定责任归属的证据，将增强把网关视为共享组织基础设施的理由。无论其功能覆盖多广，一个只能依靠未记录干预才能运行的部署都会削弱这一理由。

这些信号使讨论扎根于 Mozilla AI 已描述的事件。Otari 提出了一套协调模型访问、代理权限和支出的连贯方案。其长期价值取决于这些部分如何共同运作。

公司的治理框架在促使人们提出精确问题时最有价值。助手可以请求哪些操作？基础设施可以拒绝哪些操作？系统能在工作开始前限制哪些成本？

评估 Otari AI governance 的团队，应从一个其目的和可接受输出已被充分理解的工作流开始。这样更容易识别失败，也更容易评估改进。在考察权限、支出行为以及发生问题后可获得的证据时，应保持任务稳定。

在扩大访问权限前，请应用负责人说明新增能力能够实现什么，以及谁对其使用承担责任。请平台负责人展示该权限在何处得到执行。然后比较另一种模型是否能在这些边界下完成相同工作。当代理犯错时，哪些决策仍然可被执行？