夜雨聆风FICO 这家公司大多数人没直接打过交道，但几乎所有在美国申请过信贷的人都被它的产品影响过——银行审批房贷、车贷、信用卡时参考的信用分，就是 FICO Score。它的核心业务是用数据分析帮金融机构做风险决策，全球大约 3,500 名员工，做了几十年。
2026 年 5 月，它的 CIO Mike Trkay 说，员工正在每天创建几十个新的 AI agent，"几乎在组织的每一层"都在发生。这些 agent 的范围很广——小到帮个人管理邮件和写 brief，大到跨多个项目管理数据集。Trkay 的态度很典型：他一方面认为这代表了组织拥抱 AI 的活力，另一方面正在紧急建立治理实践——因为他已经看到不同 agent 在对同一个业务问题给出相互矛盾的结果。
肾脏护理公司 DaVita 的 CIO Madhu Narasimhan 说员工已经累计创建了超过 10,000 个 agent，公司为此建了内部平台来管控 token 支出，同时把计算资源集中分配给表现最好的 agent。Lyft 的做法是建了一个 IT 审批机制来管理 agent 之间共享的"skills"，同时在搭一个集中管控平台。Magnum Ice Cream 的美洲区 CIO Michael Friedlander 说了一句很能概括这件事本质的话："Because everybody can do it, we're probably going to end up with a lot of people having the same types of agents."
Friedlander 这句话指向了一个关键事实：agent sprawl 的根源不是某个团队管理松散，而是创建 agent 这件事本身变得太容易了。
两年前，做一个内部自动化工具需要工程团队排期、后端开发、权限设计、部署运维，周期以周或月计。现在一个业务人员用 Copilot Studio 或者 Claude 就能在几小时内搭出一个能读文档、查数据、生成报告的 agent。工程师用 Claude Code 或各种开源编排框架做多步骤 agent workflow，复杂度也不比写一段脚本高多少。
当创建门槛降到这个水平，创新的主体就从工程团队扩展到了整个组织——PM、分析师、运营、甚至行政人员都可以做，而且都在做。
这不是哪一家公司的问题。信用评分、医疗护理、出行平台、消费品….这些行业几乎没有任何业务交集，但它们撞上了同一个结构性现象。
Gartner 在 2026 年 4 月给了一组数据来量化这个趋势的速度：到 2028 年，Fortune 500 企业平均将运行超过 150,000 个 AI agent，而 2025 年这个数字不到 15 个。
同时，只有 13% 的组织认为自己有合适的 agent 治理框架。供给侧的能力在爆炸，治理侧几乎还是空白——这个缺口就是 sprawl 的结构性成因。
这不是哪一家公司的特殊困境。Friedlander 说他知道 Magnum 最终需要把 agent 整合和集中管理，但他也清楚这件事的另一面：agent 消耗 token 有成本，agent 连接内部系统有安全风险，
"how do we manage this to make sure that it's under a financially responsible model?"——这个问题还没有答案。
DaVita 的 Narasimhan 面对 10,000 个 agent 说的是"because we care for our patients, we have to scale with safety"。Lyft 的 Vogrinec 指出对一家有大量监管义务的上市公司来说，agent 失控不是效率问题，是合规问题。
但注意，这些公司没有一家选择禁止员工创建 agent。它们都在试图找一种方式：让创新继续发生，同时把它纳入某种秩序。这件事难就难在这里——你不能把刚刚被释放出来的生产力重新锁回去，但你也不能假装一万个 agent 在组织里不会出事。
Agent泛滥到底带来了什么问题
前面提到的那些公司，它们的焦虑并不都指向同一件事。这些问题看起来各不相同，但如果把它们按深度排列，会发现它们构成一条递进链——每一层问题不解决，就会自然催生下一层。
第一个浮出水面的问题是重复。
当一个组织里多个团队独立创建 agent，最先出现的现象不是某个 agent 出了事故，而是好几个团队在做同一件事。
产品团队做了一个总结 Jira ticket 的 agent，运营团队也做了一个，QA 团队可能还有第三个。每个 agent 有自己的 prompt 写法、模型选择、输出格式、权限范围。它们做的是同一件事，但方式不同、口径不一致、没人知道哪个是"官方版本"。
在三五个 agent 的时候这只是浪费，在几百几千个 agent 的规模上，这就变成了一个系统性的信息混乱源。FICO 的 Trkay 已经观察到了这件事的直接后果：不同 agent 对同一个业务问题给出矛盾的答案。当决策依赖 agent 输出的时候，矛盾的答案不只是不方便——它可能导致错误的业务判断。
重复建设会直接转化成第二个问题：成本堆积。
Agent 的成本结构和传统企业软件有本质区别。传统软件是 seat-based 的——你买 100 个 license，成本在签约时就确定了，之后每多一个用户的边际成本可以忽略不计。企业 IT 的预算体系、审批流程、财务预测模型都是围绕这种固定成本结构建的。但 agent 的运行模式是 token-based 的：每一次调用模型、每一次 tool call、每一次 retry 都在消耗 token，成本随使用量动态增长。当五个团队各自运行一个做类似事情的 agent，成本就是五倍，没有规模经济。
Uber 的故事是这个问题最直接的现实注解。2025 年底 Uber 向大约 5,000 名工程师推出了 Claude Code，并通过内部排行榜激励团队使用 AI 工具。采用速度极快——agentic coding 使用率在一个月内从 32% 跳到 84%，95% 的工程师每月都在使用 AI 工具。然后到了 2026 年 4 月中旬，全年的 AI coding 工具预算已经花完了。
四个月烧光全年预算。每个工程师每月的 API 成本在 500 到 2,000 美元之间。更关键的是很难在上升的 token 消耗和实际交付给用户的功能改进之间画出一条因果线："That link is not there yet." CEO Dara Khosrowshahi 在财报电话会上说大约 10% 的提交代码完全由 autonomous agent 生成，但这个数字本身不能回答"这些代码带来了多少新的有用功能"。
Uber 的情况不完全是 agent sprawl——它更多是 adoption 速度超过了预算模型的预测能力。但它暴露了同一个底层问题：当 AI 使用从固定采购变成动态消耗，企业传统的预算体系会失灵。而 agent sprawl 会让这件事更严重，因为重复建设意味着你不只是在一条线上消耗超出预期，你是在多条平行线上同时消耗，而且很可能直到账单到来才发现其中三条线在做同一件事。
成本可以追踪和分摊，但接下来的问题就没那么容易用财务工具解决了：agent 到底用的是谁的权限？
一个帮你总结 Jira ticket 的 agent，需要读 Jira 的数据。一个帮你查 PR 风险的 agent，需要访问 GitHub repo。一个帮你回答内部知识库问题的 agent，需要连接 Confluence 或 S3。
这些连接在技术上不难实现——MCP、API key、OAuth token 都能做到。但在组织治理上，这些连接意味着一个 agent 正在用某种身份访问企业系统，而传统的 IAM（Identity and Access Management）体系是围绕人类用户设计的：一个人有一个账号，这个账号有明确的权限范围，有入职和离职流程，有定期的 access review。
Agent 打破了这个前提。一个 agent 可能用创建者的个人 token 运行，也可能用一个 service account，也可能用一个从来没人 review 过的 API key。
Okta 的调查显示 88% 的组织报告了与 AI agent 相关的安全事件（疑似或确认），但只有不到 22% 的组织把 agent 当作独立的、需要自己 identity 的实体来管理。大多数 agent 在用共享凭证运行——这意味着出了问题，你没办法把某个行为归因到某个具体的 agent。2026 年的 Verizon 数据泄露调查报告发现，非人类身份管理薄弱已经是安全事件的第二大根源，出现在超过 40% 的事件中。
NHI（non-human identity）在企业环境中和人类身份的比例已经达到 45:1 到 500:1 之间——而 agent 的爆发还在加速这个比例。
当一个 agent 用创建者的个人 OAuth token 持续运行，而这个创建者已经转岗或者离职了，这个 agent 就变成了一个拥有过期身份、未经审查的权限、没有任何人负责的自动化程序。它还在运行，还在访问系统，但组织里没人知道它的存在。
身份和权限是事前的问题——谁能进门、能进哪些门。但还有一个事后的问题：agent 进门之后做了什么，你能还原吗？
传统软件的行为是确定性的——输入 A 产生输出 B，你可以在代码里找到原因。Agent 不是这样。一个用 LLM 驱动的 agent 接收到同样的输入，可能因为 prompt 的微小差异、模型版本的更新、上下文窗口里多了一段数据，就产生不同的输出。当这个输出影响了一个业务决策——比如一个 agent 自动生成的风险评估报告被管理层用来决定是否推进一个项目——事后如果需要复盘，你需要回答：这个 agent 当时读了什么数据？用的是哪个版本的模型？prompt 是什么？它中间调用了哪些工具？每一步的输入输出是什么？谁批准它把结果写入了系统？
micro service的 trace 是确定性的——一个 request 进来，经过哪些 service、调了哪些 API、查了哪些 DB，链路是固定的，提前埋点就能全部捕获。但 agent 的行为链是运行时才确定的：它可能根据上一步的 LLM 输出决定下一步调用哪个 tool，可能 retry 的时候走了完全不同的路径，可能因为 context window 的变化生成了不同的推理过程。也就是说你不能提前定义 trace schema，因为你不知道它会走什么路。
更麻烦的是，很多 agent 是业务人员用低代码平台搭的，根本没有经过工程团队的 observability 规范：没有统一的 logging format，没有接入公司的 tracing infra，甚至可能跑在某个人的个人环境里。就算工程团队建的 agent 有 trace，不同团队的 trace 标准也不统一，没法跨 agent 做关联分析。
前面四层问题——重复、成本、身份、追踪——都是"怎么管"的问题。但管理层最终要回答的是一个更根本的问题：管了之后，这些 agent 到底值不值得留着？
Gartner 在 2025 年 6 月做了一个预测：超过 40% 的 agentic AI 项目会在 2027 年底前被取消。原因是成本上升、业务价值不清晰、风险控制不足。
Gartner 的分析师 Anushree Verma 对此的判断很尖锐：大多数 agentic AI 项目现在还处于早期实验或 PoC 阶段，同时大量 vendor 在做"agent washing"——把现有的 chatbot、RPA、AI assistant 重新包装成"agentic AI"，但没有实质性的 agentic 能力。
Gartner 估计数千个 agentic AI vendor 中只有大约 130 个是真的。
使用量不等于价值。一个 agent 可以每天运行、消耗 token、生成输出，但如果没有人定义过"什么算成功"、没有指标衡量它到底节省了多少时间、避免了多少错误、替代了多少手动工作，那它就会变成一个既没人敢关、也没人能证明值得开着的东西。
而这五层问题的共同根源，是我们之前提到的那个结构性缺口：agent 的创建和部署在组织边缘快速发生，但企业还没有一套机制来发现、登记、管控、追踪和评估这些新的数字行动者。
核心矛盾——如何不扼杀创新地治理 Agent
看完上面这些问题，一个自然的反应是：那就管起来。建 registry、设权限、上 trace、定预算——刚才列出的每一层问题都有对应的治理手段，技术上不存在做不到的障碍。
但实际执行过的人知道，事情没这么简单。
很多组织面对 agent 泛滥的第一反应是封锁或限制 agent 的使用，这不是一个长期可行的策略。如果员工在公司批准的工具里做不了他们想做的事，他们就会绕过组织的管控去用外面的工具。Shadow AI 带来的风险比 agent sprawl 还大——至少 sprawl 的 agent 还在公司的环境里，shadow AI 直接把数据和流程带到了组织视线之外。
这不只是我的理论推演。2026 年 Verizon 数据泄露调查报告发现，员工使用未经批准的 AI 工具的比例已经翻了三倍，影响到 45% 的企业员工。也就是说，"管严一点"的后果不是员工不用 AI 了，而是他们换一个公司看不见的地方继续用——用个人账号、用消费级产品、用不受企业安全策略覆盖的渠道。
但另一面同样真实。前慢提到的那些公司的经历已经说明了放任的代价。
所以真正的难题不是"要不要治理"——这个问题的答案显然是要。难题是在什么时间点、以什么强度介入。
这个矛盾的本质是：创新需要低摩擦，但生产环境需要高纪律。
那具体应该怎么画这条线？公司们已经开始用各自的方式回应这个问题。而在它们之外，一些平台和工具厂商正在从不同角度构建具体的治理能力：有的从成本入手，有的从身份入手，有的从编排入手。下一篇我们看看这些真实的案例，看它们是怎么在实践中处理这个矛盾的。
