把「不要访问敏感文件」「不要超支」写进 Agent 提示词，不能代替执行时的检查。Mozilla AI 的 Otari 把控制分成两层：网关在模型请求发出前检查可用模型、工具和预算；仓库里的 Agent Guardrails 借助编程 Agent 的 hook，在工具调用前或一轮工作结束时检查命令与代码改动。对准备让 Agent 处理真实仓库和业务数据的团队，这比只检查最终回答更接近风险发生的位置。
但「有治理层」不等于所有动作都被拦住。预算只管经过网关的请求，Agent Guardrails 依赖 hook 实际安装和启用；有些写入只能在事后发现，已经读走的秘密也无法靠工作区差异追回。部署时应先画清流量和工具路径，再决定把哪条规则设为阻断。
问题：权限、花费和证据散落在不同位置
一个客服 Agent 可能只需知识库和模型，一个研究 Agent 需要网页搜索，编程 Agent 还要改文件、运行命令。如果只给它们同一组默认工具，管理员很难说清某次失败究竟是模型调用、工具调用，还是人为开放了多余权限。Mozilla 在发布文章中把这些问题归为三个判断：Agent 能走多远、能花多少、出错后如何查。
Otari 的思路是把应用与 Agent 的模型请求汇到同一个 gateway，再按 workspace 配置可用模型、网页搜索、代码执行和必须经过的 inference guardrail。官方称被标记的请求会在到达模型提供方前拦截。这里的前提很重要：绕过 gateway 的直连调用，不会自动受这套配置约束；工具执行本身还需要另一层检查。
机制一：网关先检查请求，再结算预算
在网关层，管理员选择 workspace 可用的模型与工具，并配置请求检查。预算则需要明确绑定对象。Otari 预算文档区分预算定义和 spend ceiling：只创建预算而没有将它用于组织、workspace 或指定提供方，不会阻断请求。API key 也可以单独设限。预算可按花费、Token 或请求量配置，未设置的维度没有上限。
请求进入模型前，Otari 为预计的最坏花费预留额度；完成后按实际用量结算，未用完的预留量释放。并发请求也要一起占用余额，因此靠近上限时，哪怕本次最终可能很便宜，仍可能因预留额不足被拒。已经进入执行中的请求会完成，不能把预算理解为任意时刻精确刹停的总账。官方还列明批处理和导入的外部用量是事后结算或追认路径，不能把它们当成同样严格的实时上限。
管理员因此要亲自确定预算周期、适用的 workspace 或 key、输出 Token 上限，并检查是否有调用绕开 gateway。预算页面显示已花费与限额；拒绝请求有错误码和范围信息，便于定位是哪道限额生效。模型可切换和故障回退也在这个网关完成，但回退后的提供方仍须通过适用预算，不能把 fallback 当成免费通道。
机制二：仓库规则检查命令和改动
编程 Agent 的风险还在模型请求之外：它可以运行 shell、读取文件、修改仓库。Otari 的Agent Guardrails 指南要求把规则放进仓库的 .otari/ 目录，由 otari hook 接收 Agent 的工具事件。它可独立于 gateway 工作；只有选择上报时，检查结果才进入 Otari 服务端。
一条规则由意图和 gate 组成。command 可在命令运行前匹配并拒绝某种调用；path 可在编辑工具执行前检查目标文件，并在一轮结束时检查 Git 工作区。command_if_changed 用来要求文件变动后执行指定命令，verifier 运行仓库提供的脚本。judge 让模型判断 diff，文档只允许它作为提醒，不能设置为强制阻断。每个 gate 还要标明 required 或 advisory，以及在工具调用前还是一轮结束时运行。
关键差别在证据时点。编辑工具明确报出目标路径时，可以写入前拦截；shell 命令可能间接改文件，路径规则只能在本轮结束后从 git status 看到结果，此时文件已改，仍需回滚。命令匹配只识别规则写出的调用形式，不能证明脚本内部不会另做危险操作。读取秘密更难：如果通过未拦住的 shell 命令读走文件，工作区没有变化，事后路径检查找不到证据。官方明确说这不是抵御主动绕过的完整安全边界。
怎么做：先用一个仓库验证规则是否真会触发
可复现的起点是选一项低风险编程任务，先列出允许的模型、工具和预算，再选一条能机械判断的仓库规则，例如禁止手工编辑生成文件。把规则提交到 .otari/guardrails.yml，为明确的编辑工具调用和本轮结束后的工作区检查都配置运行时点。先设为 advisory 观察误报，确认覆盖真实调用后再改成 required。
随后按安装指南为实际使用的编程 Agent 注册 hook，运行 otari guardrails validate，并用 --path、--command 做 dry run，检查预期规则是否显示触发。Codex 的项目 hook 还需要开发者在仓库内接受；规则文件存在不代表已运行。团队要在 CI 中再跑 otari guardrails check，并从受信任的基线读取检查规则，避免提交者顺手修改自己的规则。CI 能检验代码差异，却没有会话工具记录，无法补查当时的命令 gate。
最后做一次可控演练：尝试被禁止的编辑与命令，记录拦截时点、Agent 收到的提示、仓库状态和预算拒绝信息。若要集中看 gate 执行情况，还需配置 Otari 上报地址与凭据；默认的本地 hook 不会自动形成服务端审计记录。上报文档还说明，额外上报命令与路径内容是单独开关，应先决定哪些证据可以留存。
坑：可见性和阻断不是同一回事
Mozilla 说 usage view 能看调用、失败与成本，session tracing 能把相关步骤连成时间线，默认不保存提示词、回复或工具结果。这有利于排查高成本步骤，但也意味着不能仅凭时间线还原所有输入内容。需要内容级取证时，要另外决定采集范围与保留策略。更不能把 tracing 的存在写成已经验证的防泄漏保证。
Otari 自己列出的限制也值得放进验收项：hook 按仓库注册，未安装的环境不会执行；Stop gate 有执行次数边界；Codex 的部分模式可绕过工具调用前的 hook。实践中应把运行环境、hook 状态、CI 检查和网关路由一起验收，而不是看到规则 YAML 就认定治理已生效。
这对 HiFox 的启发在于把「谁派的任务、在哪台电脑运行、用了什么权限、留下什么证据」放到同一条任务链里看。HiFox 帮助文档已说明任务会关联运行状态、触发者、运行详情与执行转录，并根据触发者和 Agent 所有者确定可访问资源的权限上限。由 Otari 可推导的产品设计问题是：在任务创建、运行前和交付前分别展示可执行的限制及其检查结果。这里是设计借鉴，不代表 HiFox 已有 Otari 式预算或 hook gate；这些能力的现状待核实。
结论：让限制在动作发生的位置生效
Otari 的价值是把请求限额、工具可用性、仓库检查和执行记录放到相邻的位置，但每层都有适用范围。上线前最有用的检查不是问「有没有 guardrail」，而是用一项真实任务证明：请求确实经过网关，预算绑定到了正确主体，hook 在实际 Agent 中启用，拒绝与放行都有可查记录。
如果团队已经用 HiFox 派工，可以先在任务运行详情核对触发者、电脑、执行转录与结果，再把尚缺的预算或工具约束列为运行前检查项。这样既保留任务级证据，也不会把记录误当成阻断。
HiFox
