Anthropic Inference Hooks 把拦截点挪到了模型运行之前：这对你的路由架构意味着什么

做路由的团队，基本上都在某个地方做了 prompt 过滤。请求到达 gateway，检查内容，违规的拒掉，通过的记日志，完事。Anthropic 的 Inference Hooks 现在进入 Claude Enterprise 公测阶段，它把这套动作的一部分挪到了不同的位置。对于在 Claude 前面跑着路由层的团队，有一个问题值得在部署之前想清楚，谁过滤什么，在哪里过滤。

Inference Hooks 实际做的事情

机制不复杂。用户向受管的界面（claude.ai、Cowork 或 Claude Code）发送一条 prompt，Anthropic 先把请求挂住，向你的组织运营的 AI 安全服务器发一个带签名的 HTTPS POST，然后才继续处理。你的服务器读取对话记录，按照你的策略做评估，然后返回一个裁定。

{"action": "allow"}

或者

{"action": "deny", "deny_reason": "包含 X 项目的机密数据"}

被拒绝的请求永远不会到达模型。deny_reason 会展示给用户，管理员可以配置一条附加的说明文字（比如找谁申请例外）。每次拒绝都会记录进组织的 Activity Feed，供合规审查用。

请求签名遵循 Standard Webhooks 规范，这意味着已经能处理 webhook 验签的 SSPM 或 CASB 工具不需要额外的协议工作就可以接入。Cato Networks、Cisco AI Defense、Netskope 和 Reco 都已经发布了集成。

失败处理可以配置。如果安全服务器不可达或者超时（默认 5 秒），你自己决定请求是放行还是阻断。Shadow 模式和按比例灰度让你在真正开始拦截之前先观察实际流量上的裁定。

一个运维细节值得注意，transcript 可能有好几兆字节。参考实现用 HTTP/1.1 持久连接，目的就是避免每次裁定都做一次 TCP 握手。如果你自己写安全服务器，注意支持 Connection: keep-alive。

安全服务器能看到什么，看不到什么

你的服务器收到的是用户能看到的对话内容，包括 prompt 文本、tool call、tool result，以及从附件里提取的文本。它看不到 system prompt 和 Anthropic 内部的上下文，也拿不到原始的文件或图片字节。

这条边界在 DLP 场景里很重要。如果你担心的是用户把 PII 粘进 prompt 框，inference hooks 能拦住。如果你担心的是 gateway 层注入的 system prompt 里带出了敏感数据，inference hooks 看不到那部分，你的 gateway 才能看到。

路由团队面对的架构选择

大多数在 gateway 层跑 Claude 流量的团队，多少都在 gateway 处做了一些 prompt 过滤。Inference Hooks 带出的真正问题是哪些东西应该移过去，哪些留在原处，哪些本来就是在重复做。

答案取决于你的 gateway 过滤实际上在做什么。

可以移进 inference hooks 的是用户提交的、违反数据策略的文本，比如凭据格式、受管制的 PII、保密项目名称、竞争对手品牌限制等。这类检查放在 provider 层有个优势，即使用户绕开你的 gateway 直接访问 Claude Code 或 claude.ai，hook 也会触发。一条只存在于路由层的 DLP 规则，只能保护 API 流量，保护不了直接访问的界面。

应该留在 gateway 的是 system prompt 注入、模型级路由决策（选哪个 provider、哪个模型等级、fallback 链怎么走）、请求变形、按 API key 的费用归因，以及多 provider fallback 逻辑。Inference hooks 看不到 system prompt，也没有模型选择权。任何涉及请求形态或路由的事情，gateway 仍然是正确的位置。

可能一直在重复做的是通用的有害内容过滤和宽泛的内容策略，这些是整合的候选对象。如果你的 gateway 对每条 prompt 跑了一个内容分类器，而 DLP 供应商的 inference hooks 集成又跑了类似的分类器，两份延迟换了同一个结论。审查一下哪些检查是真正与 provider 界面无关的（可以移到 hooks），哪些是路由规则专属的（留在 gateway）。

和其他 provider 的比较

目前没有其他主要 provider 提供同等协议完整度的预推理 webhook。AWS Bedrock Guardrails 在模型推理层做内容策略执行，guardrail 对输入输出做评估，但执行逻辑运行在 Bedrock 自己的基础设施里，不是在你的服务器上。Vertex AI 有模型级安全过滤和有限的可配置性，但没有等价的由客户运营、接收签名 webhook 调用的安全服务器机制。

这意味着 inference hooks 目前是 Anthropic 独有的能力。如果你的路由策略需要在所有 provider 上做统一的 prompt 检查，覆盖 Claude、Gemini、DeepSeek 以及其他，那执行逻辑必须留在你的 gateway，因为 provider 层的 webhook 只在 Claude 请求上触发。Inference hooks 是对 gateway 层检查的补充，在多 provider 场景里不能替代它。

部署前需要配置的三件事

公测向 Claude Enterprise 组织开放，配置入口需要 claude.ai 里的 organization:manage 权限，这是 owner 或 admin 才有的操作，不是 API key 级别的配置。

三个 rollout 参数值得认真设置。

先跑 shadow 模式。 在真正开始拦截之前开 shadow 模式。你能在 Activity Feed 里看到裁定结果和拒绝率，但用户不会被阻断。至少跑一周，把误杀正常流量的策略规则揪出来。

失败处理。 默认是失败即拦截。如果你的 DLP 供应商有 SLA，这是对的默认值。如果安全服务器还在开发中，或者运行环境不稳定，rollout 阶段改成失败即放行，免得一个配置错误的安全服务器把整个组织的 Claude 访问都打掉。

排除角色。 按比例灰度是组织全局的。先把工程或安全团队的角色排除在执行范围外，他们需要能测试集成本身。

在实现裁定服务器时，即使你会无条件返回 allow，也要先把请求 body 读完再返回。Transcript 可能很大，服务器在读完 body 之前就关闭连接，会在 Anthropic 的失败处理路径里产生看起来像网络故障的错误。

TheRouter 用户需要关注的

Inference hooks 是 provider 平台层的企业公测能力，不和 gateway API key、路由配置或 TheRouter 的路由逻辑直接交互。如果你的组织在 Claude Enterprise 计划下使用 Claude Code 或 claude.ai，需要在推理时做 prompt 检查，又不想把所有 claude.ai 流量都绕进 gateway，inference hooks 就是这个场景的设计目标。

对于用 TheRouter 以编程方式路由 API 流量的团队，gateway 层的过滤仍然是路由决策、system prompt 策略和多 provider 逻辑的正确位置。两个执行层服务于不同的界面。Gateway 看到你路由的 API 请求，inference hooks 看到所有受管的 Claude 界面，包括用户的直接会话。

给自己团队留一个检查问题，gateway 里有没有 DLP 逻辑其实应该挪到 inference hook 里去。只要一条规则是针对用户 prompt 内容的、且需要在用户直接访问 Claude 时也生效，它就是迁移的候选。凡是依赖请求形态、header 或 system prompt 的逻辑，留在路由层。