Agent 普及之后，企业对 LLM 的管控需求会发生什么变化？ 上周和一个做 FinTech 的朋友聊天，他跟我说了一件事，让我想了好几天。
他们团队用 DeepSeek 的 API 搭了个内部代码审查 Agent，挂在 CI 流水线里，每次提交代码自动跑一遍 review。一开始跑得挺好，团队都觉得省事。直到有一天财务找过来，问为什么这个月的模型调用费是上个月的 17 倍。
排查了半天，发现是 Agent 陷入了一个奇怪的循环——它 review 了一段有问题的代码，生成修复建议，然后触发了一次新的 CI 提交，又触发了一次新的 review……就这样在一夜之间跑了 8000 多次调用，把 DeepSeek 账户余额直接打到了负数。
"我们甚至都不知道它什么时候开始失控的。" 他说这句话的时候，表情很复杂。
这可能是 2026 年每一个在业务里用上 Agent 的团队，迟早都会遇到的时刻。
一个正在发生的范式转移 过去两年，我们谈论 LLM 落地的方式经历了一个关键变化。
2024 年，大家问的是"怎么用上大模型"——接入哪个厂商、用什么 Prompt、怎么调参数。那时候的 LLM 调用模式很简单：用户在前端点一个按钮，后端发一次请求，模型返回结果。人是调用链的起点，也是终点。
2025 年下半年开始，情况变了。Agent 从 Demo 走向了生产环境——代码审查 Agent 挂在 CI 里，客服 Agent 接进了企微，数据分析 Agent 每天早上自动跑报表。Dify、Coze、LangChain 这些框架让搭 Agent 的成本降到几乎为零。
但零成本搭建的背面，是失控成本的开始。
IDC 在 2025 年做了一项调研，覆盖了 318 家千人以上企业，结果触目惊心：96% 的企业 GenAI 部署成本"高于或远高于预期"，71% 的决策者承认对 AI 成本来源"几乎或完全失控"。LangChain 团队自己也在博客里写过，他们内部做 AI Coding 的单个开发者，一周就能烧掉几千美元，而团队 HR 到了月底才看到账单。
当 Agent 从"开发者手动点一下、跑一次"变成"挂在后台、24 小时自主运行"时，LLM 调用的本质变了——从一个离散的用户操作，变成了一个持续的后台进程。
这个变化带来的连锁反应，远比大多数人意识到的要深。
三个管控需求的质变 我认为，Agent 普及之后，企业对 LLM 的管控需求会发生三个根本性的质变。这三个变化，都不是在现有 API 网关上加一个"流量统计"功能就能解决的。
第一个质变：从"管 Key"到"管身份" 在非 Agent 时代，LLM 调用的身份模型非常简单：一个 API Key 对应一个应用。Key 漏了，换一个就行。谁在调用？看 Key 就知道。
Agent 时代呢？一个后台 Agent 进程可能服务多个用户、触发多个子任务、调用多个模型的多个接口。一个简单的代码审查 Agent，实际运行时会调用 LLM 做语义分析、调用 embedding 做代码检索、再调用 LLM 生成修复建议——一个 Agent 对应的是 N 次调用链，而不是一次调用。
这时候，"哪个 Key 在调用"这个信息已经不够了。你需要知道的是：哪个 Agent 在调用？在执行什么任务？这是第几轮对话？归属于哪个项目或团队？
这就是为什么我看到主流开源网关（one-api、new-api）的设计时，会觉得它们有一个结构性的盲区——它们把"模型接入"这件事做得很好，一个 Key 转发到多个供应商，格式统一、路由灵活。但它们的基本粒度是 Key，不是 Agent。
Key 只能回答"哪把钥匙开了门"。Agent 时代需要回答的是"谁、在什么时候、以什么角色、做了什么事、花了多少钱"。
第二个质变：从"看账单"到"硬截断" 目前绝大多数团队的成本管控方式，我称之为"事后惊吓模式"——月底收到账单，发现超了，开会讨论，下个月注意。这个模式在 Agent 低速运行的时候勉强能用。但当 Agent 可以在一夜之间跑 8000 次调用的时候，"月底看账单"就意味着"月底才知道已经亏了多少钱"。
Gartner 预测到 2027 年，40% 的 AI Agent 项目会因成本过高而被取消。我觉得这个数字还保守了。
真正需要的不是"提醒你超预算了"，而是在超预算的那一刻直接停下来。不是发一封告警邮件（凌晨 3 点谁会看？），不是把状态标红（Agent 才不在乎你的仪表盘什么颜色），而是直接返回 HTTP 402，让你的 Agent 框架收到一个明确的"钱不够了"的信号，然后优雅降级。
这个逻辑其实和云平台的预算管控一样——AWS 不会在你超预算之后发邮件提醒，它直接限流。但国内的 LLM 网关生态，几乎没有产品做到这一层。大部分是记账，不是管控。
第三个质变：从"能用就行"到"可审计可追溯" 这一点，在金融、医疗、政务等强监管行业是硬需求。
假设你是一家银行的技术负责人，你们用 Agent 处理了一部分信贷审核的辅助判断。有一天监管来问：过去三个月，哪些模型参与了信贷决策？每个模型输入了什么数据？输出了什么结论？有没有数据流向境外模型供应商？
如果这些问题你只能回答"我们的 AI 平台很强，模型效果很好"，那就出大事了。
欧盟 AI 法案（EU AI Act）2026 年 8 月开始强制执行，国内等保合规也在推进。Agent 不是法外之地——每一条调用记录的输入输出、模型选择、供应商流转，都需要是不可篡改、不可删除、可追溯的。 这不仅仅是技术问题，是合规的底线。
但现状是什么呢？大多数团队把供应商的 API Key 散落在 .env 文件、配置中心、甚至硬编码在代码里。别说审计，连"我们现在总共用了多少个模型"都说不清楚。
OneLLM 是怎么想的
聊完三个质变，自然要聊解法。这也是我最近花了很多时间研究 OneLLM 这个项目的原因之一。
OneLLM 是一个开源（MIT 协议）的 LLM 网关产品，基于 Portkey 的开源引擎做了大量定制。简单说，它是一个架在你的应用和所有 LLM 供应商之间的中间层——你用 OpenAI 兼容的 API 格式发请求给它，它帮你路由到 DeepSeek、通义千问、智谱、Claude 或者任何一个你配置的供应商，然后把结果返回给你。
说实话，这个"统一 API 格式"的能力，行业里能做的产品不少，one-api 和 new-api 都是很好的开源选择，各自有几万 Star。OneLLM 让我觉得有意思的，不是它做了统一接入，而是它在统一接入之上，长出了三层"管控基因"。
第一层是虚拟 Key 体系。OneLLM 定义了两种 Key 类型：onellm_sk_ 给普通应用，onellm_ag_ 给 Agent。Ag_ Key 天然携带 agent_id，所有调用自动标记归属。这意味着你可以精确地回答"这个 Agent 花了多少钱"——而不是"这个 Key 花了多少钱"。一个 Key 可以绑定多个供应商，一个 Agent 的所有调用链路——不管经过了多少个模型——都挂在同一个身份下。
第二层是预算熔断。不是发告警，是硬截断。工作区、Key、Agent、供应商绑定——四层独立预算，每一层都可以设日预算和月预算。预算使用到 70% 告警，85% 限流（RPM 减半），100% 直接返回 402。Agent 凌晨跑飞了？没关系，402 一来，它自然会停。
第三层是审计基因。每一条调用日志都不可篡改、不可删除，记录了模型、供应商、Token 消耗、成本、延迟、输入输出全文。还有一个合规报告引擎，能自动检测数据是否流向境外供应商，生成多板块的合规报告。这是为"监管来问"那一刻准备的。
当然，我也要说实话——OneLLM 现在还处于早期阶段。它的 Agent 控制面（死循环检测、分级执行、MCP 网关）还在规划中，产品成熟度远不如那些运营多年的竞品。但它的设计方向是对的：在"管模型"和"管 Agent"之间，有一条清晰的断层线。 谁先把这个断层填上，谁就定义了这个赛道。
写在最后 回到开头那个问题：Agent 普及之后，企业对 LLM 的管控需求会发生什么变化？
我的答案是：管控的粒度会从 Key 下沉到 Agent，管控的时效会从"事后看账单"升级到"实时硬截断"，管控的性质会从"技术便利"升级到"合规底线"。
这并不是危言耸听。看看过去十年云计算的历史——当虚拟机从"开发者手动申请一台玩玩"变成"生产环境自动扩容几百台"的时候，管控需求发生了什么？IAM、VPC、CloudTrail、Budget Alert 这些我们现在觉得理所当然的基础设施，都是那个范式转移之后才长出来的。
LLM 调用正在经历一模一样的转变。
如果你团队里现在只有一两个 Agent 在跑，你可能会觉得这些管控需求离你还远。但我的经验是——Agent 的增速不是线性的。从一个到十个可能用了半年，从十个到一百个可能只需要两周。
能够在 10 个 Agent 时管住成本的企业，才能在 100 个 Agent 时活下来。
你怎么看？欢迎在评论区聊聊你们的 Agent 管控制现状。
OneLLM 开源地址：github.com/EmilyLi2026…
OneLLM 国内体验地址：http://59.110.62.203:18080/
我是一名正在探索 AI 产品方向的产品经理。如果你对 LLM 网关、Agent 管控、企业 AI 治理这些话题感兴趣，欢迎关注交流。
下一篇我们会聊一件事——一行代码不改，怎么给现有的 LLM 应用加上预算熔断和审计追踪。
