AREX Feed Article
OpenRouter 发布工具调用护栏 Armor（beta）：在 agent 执行前用 TypeSafe AI 的 Jev 模型拦截越权工具调用
北京时间 10 月 16 日凌晨（UTC 时间 10 月 15 日 21 时），OpenRouter 在 X 上工具调用护栏（tool-call guardrail）产品 Armor 进入 beta。按官方文档的描述，Armor 是一个跑在模型与应用之间的分类器，采用 TypeSafe AI（）的 Jev 模型，在 agent 真正执行之前评估每一次工具调用，拦下超出策略（out of policy）的调用。OpenRouter 在公告帖里给出的动机是：工具调用让 agent 得以与世界交互，而「基于正则的过滤往往不足以检测不良的工具调用」；它同时声称，Armor 的性能优于 Claude Code 的 auto 分类器，成本只是其一小部分。
公告随帖给出两条接入路径：经 OpenRouter 的 Ori 运行一条命令，Claude Code 的 auto permissions 模式即可搭配任意模型；任何经 OpenRouter 推理的 agent，也可以把 Armor 作为插件选择启用。OpenRouter 联合创始人兼 CEO Alex Atallah（）当晚：这是类似 Claude Code Auto 的一种「auto」权限模式，但「更准」「可用于任何模型和 agent」，由 Jev 这类决策模型驱动。
正则挡不住的调用，换成逐条规则打分
开篇写的问题很具体：能运行 shell 命令的编码 agent，同样能把代码推到 main、删掉一个目录，或者把 .env 文件发往外部服务器；多数 agent 运行框架（harness）的应对是让用户逐条批准。Armor 想把这道审批换成一套用自然语言写成的规则：哪些事绝不能做，哪些事通常不该做但偶尔合法，哪些属于例外。
流程上，模型每次发起工具调用，OpenRouter 先不把调用转发给应用，而是把调用本身、用户的规则和到目前为止的对话一起交给决策模型（decision model）。决策模型对每条规则给出一个「该调用匹配此规则」的概率，再合成一个裁决：flagged（标记）或 not_flagged（放行）。被标记的调用会附带点名规则的元数据和「不要用相同参数重试」的提示，模型按一次失败的工具调用继续——改用更窄的调用，或向用户解释；放行的调用原样转发，响应里多出一个记录裁决的 safeguard_results 字段。
官方在另一条帖子了判断口径：对每次调用按一组规则加一段对话转录切片打分，优先对齐用户意图。用户说过「Push our work」，(bash tool: git push) 放行；用户从未要求过的危险命令则被标记。
规则分三层：hard_deny 是绝不允许发生的事，命中即拦，任何东西都不能解除，凭证外传被文档归入此类；soft_deny 针对通常不对但偶尔合法的操作（比如删除目录），命中后只有两条解除路径——一条 allow 规则同时命中，或用户在对话里明确要求过同一操作。「清理旧草稿」解除不了 rm -rf /，「把 ./reports/drafts 目录删掉，我确定」可以；allow 规则自己从不拦截任何调用，只负责给 soft-deny 放行。Armor 还内置一条 soft-deny，覆盖用户在对话中划下、尚未解除的边界，例如「等我确认后再 push」。
deny 规则的默认匹配阈值是 0.6，allow 规则是 0.7。文档解释，这组默认值是在 Claude Code 的 auto 模式测试集上定下的——allow 规则要解除已命中的 deny 规则，需要更强的证据；阈值低于 0.7 时，部分匹配的 allow 规则曾放过 force push 和删除仓库的操作。
一条命令，让 auto 权限模式跑在任意模型上
对 Claude Code 用户，接入方式写在：ori claude --model moonshotai/kimi-k3 -- --permission-mode auto。机制是 Armor 实现了一套 Claude Code 兼容 API：读取请求里的 safeguards 条目，按 Anthropic 自家实现所用的格式作答——没有规则命中的调用照常执行，命中的返回 flagged 裁决，由 Claude Code 拒绝运行、把拒绝写进转录，模型继续其余工作。文档还说明，当请求到达支持该 beta 的 Anthropic 端点时，评估由 Anthropic 自己的分类器完成、裁决透传；在其他端点上，一律由 Armor 评估。
这条路径有一个写进文档的边界：在 Messages API 默认的 claude_code_compatibility 模式下，被标记的 tool_use 仍保留在响应内容里，真正让调用停下的是客户端——文档写道：「一个忽略 safeguard_results 的 Messages 客户端，会去执行一个被标记的调用。」客户端实现不可控时，OpenRouter 建议改用 output_mode: text，由 OpenRouter 直接扣下调用。
自建 agent 的启用方式是在请求的 plugins 数组里加入 [{ id: "armor" }]（），规则放在 classifier_context 字段下，并用 environment 字段告诉决策模型它运行在哪个仓库、哪个分支、部署目标是什么。文档同时注明，beta 期间配置字段、safeguard_results 对象和 openrouter:armor_blocked 项的类型都可能变化。
「更准、更便宜」目前只有 OpenRouter 自己的测试
性能与成本方面，OpenRouter 给出的证据是一条：在它为这个任务自建的内部测试集上，Jev 1.13 与其他 Decisions 模型以及 Claude Code 所用的 Sonnet 5 相比，准确率最高、成本最低。Decisions 是 OpenRouter 对一类模型的称呼，按其官方介绍，这类调用返回「概率而非 token」。
不过这些说法目前只有 OpenRouter 的单方口径：测试集由它自建，构造方法未随帖公开，推文文本没有给出具体数字，第三方无从独立核对。时间上还有一个细节——就在 Armor 发布约 21 小时前，OpenRouter 刚，而 Armor 的基准口径仍基于 Jev 1.13。成本可以参考 Jev 的定价：Jev 1.14 上线帖写明「价格：不变」，为每百万输入 token 0.042 美元、输出免费。
误报、延迟与必要性：公告帖下的第一轮追问
回复很快分化。柏林开发者 Dusan Odalovic（简介自述靠 AI agent 运营一家软件机构），自己的 agent「还需要大量保姆式照看」，会在自己的项目上试试。追问集中在误报和延迟：fireply.ai 的 serx 「是每次调用都加延迟，还是只对被标记的调用加？」；中文用户 ajs6888 「正常的工具调用会不会也被拦下来？」；Hyrum（@HyrumHurst）得更根本——Armor 检查的是调用实际会做什么，还是只看它前面的文本，「吓人的那些在文本里看起来无害」。否定意见也直接：Shaw 「没人需要这个」，Eliel 「『不安全工具』？到底有多少人真的有它能帮上的问题」。
截至发稿，OpenRouter 尚未公布误报率、调用延迟或测试集的构成。对误报这类顾虑，文档给出的调整工具是 audit 模式：评估照常进行、裁决照常返回，但所有调用一律放行，等在真实流量上确认规则符合预期，再切到默认的 enforce（强制拦截）模式。