微服务治理走过的坑，Agent治理可能还会再踩一遍

AI Agent 本身很容易被看见，但Agent之间依赖关系却非常隐蔽，因为复杂性通常在水面之下悄悄堆积。

这就像以前的一个非常严重的问题，影子IT（Shadow IT）一样。

业务部门绕开 IT 部门自行采购应用，电子表格逐渐演变成数据库，部门级工具悄悄升级为任务关键型系统。最终，组织靠治理、标准和架构护栏把这些问题收拢。

目前Agentic AI 势头正劲所以一个新问题就出现了，而且比影子 IT 更难察觉——它不会表现为未经授权的应用程序，而是表现为一堆看不见的依赖关系。

影子集成（Shadow Integrations）。

为什么影子集成有所不同

传统集成是可见的，需要：

• 项目立项
• 架构评审
• 支持模型
• 文档记录
• 资金审批

Agentic 工作流不一样：一个 Agent 连上 CRM 系统，另一个连接器接入 ERP，第三个打通协作工具，第四个暴露出货运可见性。过去要数月才能落地的东西，现在几个小时就能搭起来，创新速度陡增，治理却没跟上节奏。

于是一种危险的错觉出现了：集成越容易创建，看起来就越容易管理。

问题不在于智能，而在于可见性

大多数组织盯着的问题是这样的：

• 该用哪个模型？
• 回答的准确度如何？
• 能释放多少生产力？
• 能自动化多少任务？

这些问题虽然很重要，但还有一批同样关键、却很少有人追问的问题：谁拥有这个 Agent？谁批准新的连接？谁监控依赖关系？谁负责故障支持？谁负责淘汰不再使用的 Agent？谁审计 Agent 执行的操作？

当组织从十个 Agent 扩展到数百个，这些问题会从架构层面的讨论，变成实实在在的运营挑战。

无人问津的五个问题

负责任地扩展 AI Agent，靠的不只是智能，还要有明确的所有权、治理和问责机制。

1、谁拥有这个 Agent？

所有权应归属于应用团队、集成团队、AI 平台团队、企业架构团队，还是运维团队？所有权不清，问责很快就会跟着模糊——而问责不清的系统，很难撑得住规模化。

2、谁批准新的连接？

是不是谁都能把 Agent 接到 ERP 系统、客户数据、供应商门户或财务应用上？治理不是要拖慢创新，而是要让访问保持安全、有意图、可追溯。

3、出问题时该找谁？

假设某个 Agent 出故障，原因可能是：

• 连接器发生变化
• API 达到速率限制
• 供应商平台不可用
• 数据定义发生变化

比如凌晨两点出问题了，那么谁应该去处理？应用团队？集成团队？平台工程团队？答案常常含糊不清，而运营层面的模糊地带撑不了多久。

4、能不能解释 Agent 做了什么？

人得为自己的决定给出解释，Agent 也会渐渐被推到同样的位置上。组织需要能回答这样的问题：

• 为什么创建了这份采购订单？
• 为什么重新分配了库存？
• 为什么更改了客户承诺？
• 哪些系统影响了这个决策？

没有可观测性，自主系统很快会变成一个黑箱。

5、谁来淘汰 Agent？

企业已经在跟这些东西较劲：

• 僵尸应用程序
• 未使用的 API
• 遗留集成

废弃的 Agent 会不会变成下一轮数字垃圾？很可能。每一波技术浪潮，都会留下一批活得比自己用途更久的资产，AI Agent 大概率也不会例外。

Agent 泛滥可能成为新一代的微服务泛滥

每多一层抽象，就多一层复杂性——最终也得靠一门新学科来管住它。

十年前，企业遇到过类似的问题：微服务泛滥。团队快速搭建各类服务最终发现自己离不开：

• API 网关
• 服务目录
• 可观测性平台
• 治理标准
• 平台工程团队

Agentic AI 大概率会走上相似的轨迹。

也许在 DevOps、MLOps 和平台工程之后，下一门学科将是：AgentOps。

是否需要一个 Agent 治理办公室？

这话听起来是夸张了点，但当初 API Centers of Excellence刚提出的时候，也是这般模样；数据治理委员会是这样，平台工程团队也是这样。

Agent 数量一多，企业大概率需要具备这些能力：

• Agent 注册中心
• 身份与访问管理
• 版本控制
• 可审计性
• 生命周期管理
• 策略执行
• 可观测性
• 性能监控

这并非因为 Agent 本身有多危险，而是因为放任不管的复杂性，早晚要付出代价。

这些很多都能在 NIST AI 风险管理框架（AI RMF 1.0）里找到对应——该框架强调治理、风险管理、可追溯性和可信 AI。框架本身并非针对 Agent 而设计，但组织正从孤立的 AI 解决方案转向大规模运行的自主 Agent，问责制和生命周期管理的分量也随之加重。

架构护栏助力规模化扩展

护栏常被当作创新的绊脚石，但治理框架划出清晰的边界、明确问责、沉淀出可复用的运营模式，组织反而能放心大胆地往前走。业界近期关于 AI 治理的讨论，也越来越倾向于把合规和治理看作加速器，而不是阻碍。

成功的组织可能会确立这样一些原则：

• 身份先于自主（Identity Before Autonomy）：每个 Agent 都得有明确的所有权和问责机制。
• 可观测性先于优化（Observability Before Optimization）：先弄清楚 Agent 是怎么运作的，再谈提升生产力。
• 治理先于规模化（Governance Before Scale）：不受管理的系统，扩展起来很少有好下场。
• 生命周期先于泛滥（Lifecycle Before Proliferation）：Agent 该被当成产品对待，走完创建、运行、退役的完整流程。
• 复用先于重复建设（Reuse Before Duplication）：企业能力该拿来共享，而不是让每个新 Agent 都重新造一遍轮子。

管理 AI Agent，可能很快就会变得跟管理数字员工差不多——治理、问责、生命周期管理，会成为最基础的几项能力。

总结

每一轮技术浪潮，都会带来一种新的抽象；而每一种抽象，都在藏东西。

• 云计算隐藏了基础设施。
• 微服务隐藏了分布式系统。
• 生成式 AI（Generative AI）隐藏了机器学习。
• Agentic AI 可能正在隐藏运营层面的依赖关系。

挑战不在于创造出智能的 Agent。挑战在于治理它们。

部署最多 Agent 的组织未必能笑到最后；真正撑得住的，是那些能负责任地把 Agent 管起来、经得住规模考验的组织。

过去十年，人们学会了如何管理 API 和微服务。未来十年可能需要学会如何管理数字同事。

作者：Vivekanand Emani