大多数关于智能体 AI 治理的建议都围绕流程展开。你会拿到需要采用的框架、需要追踪的成熟度模型，以及需要执行的项目周期。这些基础工作有帮助，但它无法控制智能体在发起请求那一刻的实际行为。一个典型事件让问题变得具体。某个智能体重试失败的调用，切换到更昂贵的模型，一晚上花掉 200 美元。框架可以说这越界了，但它无法阻止这次请求，除非规则在请求实际发生的地方得到执行。API 密钥允许了这笔开销，因为请求路径上没有任何控制措施。API 路由层正是可以部署这类执行机制的地方。每个智能体请求都经过它，这使其成为设置预算上限、限制模型和记录活动的实际场所。现在大家谈智能体治理，基本上都在讲流程。拿框架，跑成熟度模型，走项目周期。这些事不是没有用，但它们解决不了一个非常具体的、卡在喉咙眼的问题。当你的智能体深夜发出一个请求、要切到一个更贵的模型、要多花你200美元的时候，谁在那一刻拦住它？框架可以说「你这样不对」。真的，框架可以把你这个行为标记为越界。但框架拦不住这次请求。因为规则不是在请求发生的地方执行的。我问你个问题。你看完上一句话，能不能立刻在脑子里指出来，你现在的智能体到底在哪里执行规则？大多数人指不出来。因为根本没设。OpenRouter提出了一个很直接、而且你马上就能动手做的解法。API路由层。每一个智能体发出的每一个请求，不管用的是什么框架，LangChain、CrewAI、AutoGen、Semantic Kernel，不管，最终都要经过路由层。密钥、模型名、成本、token消耗、延迟，全部路过这里。所以路由层是你最能抓到它们的地方。打个比方，网络流量。你可以在每个应用里设控制，但你终究还是在网关层设共享策略，因为那是流量汇聚的地方。AI智能体也一样。局部的控制放智能体里面，通用的控制放路由层。这个模式在很多领域已经被验证过了，不是拍脑袋想出来的。
什么是智能体 AI 治理？
智能体 AI 治理是一套策略和强制执行机制，用于约束自主 AI 智能体在运行时能做什么。它在两个层面运作。策略时治理定义了应该成立的条件：哪些模型被批准、智能体可以访问哪些数据、需要哪些人工监督机制。运行时治理在 API 请求发出的那一刻强制执行实际情况：模型访问、支出限制、供应商访问、请求日志记录，以及无论是否有人类监控都会激活的持续监控。这两个层面之间的差距正是组织暴露风险的地方。为什么仅有治理框架无法强制执行任何东西治理框架帮助你定义规则。当智能体发出模型请求时，它们并不强制执行这些规则。行业框架描述了治理应该实现什么目标，但没有说明它在何处运行。它们告诉你哪些模型被批准、谁拥有智能体、以及何时需要人类签字批准。这些指导帮助高管决定智能体如何被批准、拥有、监控和升级。智能体通过委派运作。你给它一个任务、一个模型、工具、数据以及一定程度的自主权，而治理必须定义这种委派允许什么、阻止什么。框架可以说智能体需要访问控制，但除非该控制存在于执行路径中，否则它无法拒绝未经批准的模型请求。策略可以说智能体需要预算限制。除非预算上限在请求发生的地方得到执行，否则它无法阻止重试循环一夜之间花费 200 美元。API 路由层为你提供了一个将治理意图转化为运行时行为的地方。构建 AI 智能体的开发者在运行时控制方面往往会趋同：工具访问权限、API 密钥、执行策略强制、终止开关、身份信息、日志记录以及实时策略。这些属于执行路径层面的关注点，而非委员会式设计。将 API 路由层作为治理的管控节点API 路由层是合适的执行强制点，因为它位于你的 AI 智能体与其所调用的模型之间。无论你使用的是 LangChain、CrewAI、AutoGen、Microsoft Semantic Kernel、Amazon Bedrock Agents，还是自定义框架，你的 AI 智能体仍然会发出模型请求。这些请求携带着治理所需的信息：API 密钥、模型、提供商、成本、模型 token 用量、延迟、路由行为以及响应状态。这使得路由层成为强制实施共享规则的自然位置。
你可以通过为每个工作流控制 API 密钥、预算、允许使用的模型、提供商访问权限以及请求追踪记录，来强制实施 AI 智能体治理的第一层。步骤 1：为每个 AI 智能体工作流分配专用 API 密钥为每个 AI 智能体工作流创建一个单独的 API 密钥。销售资格审核智能体与代码审查智能体具有不同的风险概况和不同的预算。独立的密钥可以让你获得独立的控制措施和独立的审计追踪记录。如果你在多个智能体之间共享单个密钥，你将无法归因支出、识别哪个智能体导致预算超支，也无法按工作流限制模型访问。单个配置错误的智能体的影响范围会扩大到使用该密钥的所有工作流。步骤 2：针对每个密钥设置信用额度根据智能体预期的每日支出，为每个密钥设定信用额度。销售智能体每天 50 美元。分类智能体每天 10 美元。内容管道每天 200 美元。当智能体达到预算上限时，API 会返回一个速率限制错误。你的智能体不应在没有硬性停止的情况下无限花费资金。如果省略这一步，重试风暴或模型升级循环将一直运行，直到有人检查账单。步骤 3：模型允许列表限制每个 API 密钥可以调用的模型。如果你的分类智能体只需要 Claude Haiku 4.5 和 GPT-5 Mini，就把该密钥锁定到这些模型。如果该智能体尝试调用 Claude Opus 4.8、DeepSeek V4 或 GLM 5.2，请求会在到达模型之前被拒绝。没有这一步，一个在失败时重试的智能体可能在未经人工批准的情况下自行升级到更昂贵的模型。夜间产生 200 美元支出的情况之所以会发生，就是因为模型允许列表是开放状态。第四步：通过 Broadcast 进行请求日志记录将请求追踪路由到你的可观测性平台。OpenRouter 的 Broadcast 功能可以将请求数据发送到 Langfuse、Datadog、W&B Weave 等可观测性平台，以及自定义 webhook，无需对应用程序代码进行检测。审计追踪会捕获调用的模型、消耗的 token、延迟和每次请求的成本。
夜雨聆风