你的销售智能体上周一晚上烧了200美元。它先是调用失败，Agent没有停下来等人工确认，而是自己重试——重试也失败——然后它做了一个更聪明的决定：换个模型试试。它从 GPT-4o 切到了 GPT-5.5，那个凌晨两点，账单开始飞涨。第二天早上没人知道发生了什么，因为没有人设过预算上限，也没有人给它划定过可以使用哪些模型。这不是假设，这是本周三被披露的真实事故，发生在一家部署了三个智能体工作流的中型 SaaS 公司里。
问题不在模型，问题在中间那一层。绝大多数团队把智能体直接接到 OpenAI 或 Anthropic 的 API 上，密钥一把走天下，结果就是：一旦某个工作流在某个奇怪的边界条件下开始失控，它能调用的算力、消耗的预算、切换的模型，全部不受约束。IBM上周发布的报告里有一个刺眼的数字——97%遭遇AI安全事件的组织，事后复盘发现根因都指向AI访问控制的缺失。换句话说，模型没坏，流程没坏，密钥管理坏了。更尴尬的是，调研显示只有不到五分之一的企业拥有真正成熟的AI治理框架，剩下的大多数都在裸奔。
解法其实简单到不像解法：在API路由层为每一个智能体工作流分配独立的API密钥。每个密钥绑定三件事——月度预算上限、允许调用的模型白名单、提供方准入名单，外加完整的请求日志。这套机制不需要重新设计系统架构，OpenRouter、Portkey、Cloudflare AI Gateway 都能五分钟内配完。预算触顶自动熔断，模型白名单之外直接拒绝，日志全留痕——出事了知道哪个智能体、哪个工作流、哪一次调用出的问题。最小可行治理，从来不是写一份几十页的框架文档，而是把今天那把共享密钥，按工作流拆成五把。
