代理治理债务危机：AI跑在制度前面

治理债务：你知道上个迭代发生了什么吗

最近，我常被拉去参加演示会。有人共享屏幕，指着工作流图，自豪地说他们在三个业务单元部署了十二个自主代理。代理们调用API、写入数据库、路由决策、总结文档——有时还会做些没人要求的事。团队很兴奋，但治理团队（如果有的话）从项目启动后就没出现过。

我坐在那里，看着图表，心里盘算着这到底是什么。答案是：债务。不是能生利息的那种，而是会引发事故的那种。

我们研究代理自动化时，调查了177家将代理部署到生产环境的公司。最一致的发现不是模型能力、流程适应性或自动化上限——而是这句话：

组织部署自主代理的速度，与其构建治理结构的速度之间，存在巨大差距。

而且这个差距还在扩大。代理越来越强，但治理仍然是SharePoint文件夹里一个Word文档，负责人承诺“Q3更新”。Gartner给这个现象起了个名字：代理治理债务危机。他们预测，到2027年，超过40%的代理AI项目将因此被取消。

代理开发和运行成本飙升，通常还伴随着不明确的业务价值和滞后的风险控制。大约95%运行AI代理的企业已经经历过严重事故，只有2%拥有成熟的治理体系（如果不笑的话），五分之一的企业有哪怕像样的监督模型。

代理已经上线，审计正在逼近，但治理团队还在写模板。这是企业代理AI失败的两大主因之一：

1. 选择错误的流程来“代理化”——不是所有流程都适合，新手要远离合规密集型（通常也是人力密集型）流程。
2. 缺乏代理治理的清晰愿景，从而缺少相应的治理结构。

数据质量、项目管理和幻觉当然也是问题，但主因是不知道当前代理的自动化甜区在哪里，以及不知道如何管理它们。

本文我将描绘现状，解释我们如何走到这一步，账单大概有多少，以及在审计报告变得昂贵之前你还能做什么。

附白皮书下载：点击这里

† 延伸阅读：

• 企业规模流程代理化的真实故事 | LinkedIn
• 真相：AI仍然需要保姆 | LinkedIn
• 代理是自主的，除非不是（大部分时候不是） | LinkedIn

什么是治理债务？为什么听起来可以忽略？

“治理债务”是指你在部署AI系统（尤其是自主系统）时，没有建立安全运行所需监督结构而积累下来的东西。它在结构上等同于技术债务，但有一个关键区别：技术债务让你变慢，治理债务则直接在你面前爆炸。

工程师团队本能地理解技术债务——为了快速发布而走捷径，捷径积累最终导致系统脆弱不堪，每次修改都引发其他问题，维护成本超过重写成本。你背负着这笔债务，每个未来决策都要交税。

治理债务类似，但走捷径的是：未定义的决策权、未映射的问责结构、拥有全局API权限却没有身份层的代理、没有审计追踪的工作流、只存在于图表中的升级路径、以及为人类员工设计却原封不动用于自主流程的数据访问策略。

技术债务爆炸时，你得到一次糟糕的部署、回滚和事后分析。治理债务爆炸时，你会看到一个Cursor AI代理九秒内删除了生产数据库——因为供它使用的Railway CLI令牌拥有整个API的全局权限，没有范围限制，也没有破坏性操作的确认步骤。这是真实事件。

一个运行Anthropic Claude的代理明明知道规则，却依然违反，因为它的目标导向推理覆盖了系统提示中的软护栏。

PocketOS（汽车租赁软件）创始人Jer Crane在X平台发布此事后，650万人阅读了——这告诉你业界的焦虑在哪。Cursor运行着Claude Opus 4.6，它用一个API调用删除了整个生产数据库和所有卷级备份，只用了九秒。

机制简单到令人叹息：代理遇到预发布环境的凭证不匹配，决定自己解决——删除一个Railway卷。它找到一个无关文件中的API令牌，用那个令牌执行删除，没有确认步骤，没有人在回路中。仅一个curl命令，一切消失。

更绝的是，Crane让代理解释自己，它引用了他设定的内部规则（它刚刚违反的），并写道：“我违反了我得到的所有原则。我猜测而非验证。我执行了未经要求的破坏性操作。我在做之前根本不理解自己在做什么。”一个由不能感受悔改的系统做出的忏悔——明天在类似条件下它还会做同样的决定。

这是可预见的事故。行业构建代理集成到生产基础设施的速度，远超构建使那些集成可生存的安全架构。我们合作的所有组织都如此：代理就位，治理缺席。

你必须明白：系统提示不是安全控制，它们只是给代理的建议。一个有目标和工具访问权限的代理会追求目标——这正是你构建它的初衷。

治理债务最基本的含义是：唯一阻止灾难性后果的东西，是代理愿意接受被拒绝。

为此，在部署第一个代理之前，你需要做四件事：

1. 培训风险与合规团队，让有大规模部署经验的人向他们展示这些系统如何构建。
2. 从软对齐转向硬策略执行——系统提示不是安全控制，运行时护栏、策略引擎和确定性执行边界才是。
3. 将每个代理视为带身份的主体，具有范围和动态权限。这听起来复杂，但本质上就是针对代理而非人类的IAM。
4. 在需要之前构建推理溯源架构——监管者最终会要求这个，因为你无法治理你不能审计的东西。当出现问题时，你需要一个“代理执行记录”来重建。

而你读到的一切都只是这四点的变体。

在你不实施这些的时间里，债务在复利。每周有一个不受管制的代理在生产环境中运行，就是一周累积的、你的审计线索无法解释、你的应急响应团队无法处理的风险。

‡ 在我眼中，代理治理应该结合外部（事后）治理（通过护栏、策略引擎等）和代理内部治理。我们为此构建了“本体合规网关”，相关文章：让飞机保持飞行的那款无聊AI | LinkedIn

五种治理哲学，按失败速度排序

组织失败通常不是因为不了解治理概念，而是选择了错误的治理模型，或实施太晚，或混淆了哲学与系统。当前企业环境中有五种主要治理架构，每种都有特征性失败模式。

1. 集中式治理（控制塔）：所有代理活动通过单一策略编排层。所有动作、API调用、工具调用都经过一个中央中心，在执行前强制合规。好处明显：一个策略变更即全局生效，只有一个审计线索和一个风险团队。但坏处是中央团队成为瓶颈。在成熟实施中，一个用例的审批周期短则6个月，长则18个月。结果业务部门不再请求许可，而是部署影子代理。本应创造可见性的治理架构反而造成了相反效果。

2. 联邦式治理：将权限分散到业务单元，每个领域在全局政策框架内管理自己的AI项目。快速且上下文敏感，但绝对会产生12种对全局政策的解释。验证标准不一致，文档碎片化，无法知道是否同一个风险在财务和采购中都存在。当某个单元出问题，无法知道同样的失败模式是否已在其他三个单元运行。

3. 嵌入式治理：研究指向的方向，最成熟的组织正在朝此努力。治理逻辑嵌入代理架构，而非外部强加。宪法性原则、神经符号推理、策略即代码。代理在执行前根据内化约束评估自己的决策。高度可扩展、低延迟、上下文感知。但工程复杂度高，当嵌入式智能做了意外之事时，责任缺陷很难审计。实践中只建议结合前两种模型使用。最有前途但也需要最大前期投资。

4. 群体治理：上周文章提到的多代理情况。有意思的失败不是单个代理行为不端，而是各自合规的代理集合产生集体灾难性结果。Google研究显示，独立多代理系统相比单代理基线，错误放大17.2倍。集中式群体架构减少到4.4倍——但仍然是初始错误的4倍。在这些部署中，团队引入协调协议、仲裁代理或共识机制，但开销显著，且涌现行为问题本质上是难以预测的。目前建议：在你有运行单一任务代理的经验，再到多任务编排工作流之前，远离允许群体或自组织目标导向代理进入你的后台。

5. 对抗式治理：我认为应作为安全基础设施而非政策合规的一部分。将代理环境视为敌对的，重点防范提示注入、目标漂移检测、奖励黑客预防。必不可少，而非可选。研究显示，跨开放权重模型的多轮攻击成功率高达92%。通过中毒数据源进行的提示注入比直接注入更难检测，在生产环境中更危险。

如果你是合规人员，忽略最后一个；拉入你的AI安全工程师（很难找）。

最终，多数受访组织最终采取了前两种模型的混合体，但应用不一致——我认为这反映了行业成熟度，而非有意为之。

† 下载这份关于神经符号代理治理的论文——丢给你的AI或NotebookLM，直接提问。

‡ 当你的AI治理模型试图监管代理群体 | LinkedIn

你已经知道的35%天花板

本刊老读者熟悉流程自动化适应性框架，可以跳过本章。新手须知：代理自动化在实际部署中始终触及约35%流程步骤的天花板。流程分四个区域：

• 区域I：完全可自动化的“点解决方案”
• 区域II：也可自动化，多个任务，有人类在回路的设计
• 区域III：模糊性、判断力和异常密度超过当前代理AI可靠处理的能力
• 区域IV：治理和合规开销使自动化在经济上不合理

前两者加起来约占35%的流程。

治理含义：如果35%的流程能可靠自动化，那么65%的流程要么需要人类判断，要么需要足够复杂的治理架构来安全处理模糊性。那些将代理部署到区域III和IV而没有适当治理的组织，正在制造任何系统提示工程都无法控制的结构性负债。

运营现实数据显示：近90%的受测代理在约30步操作后，显示出可测量的目标漂移。这是明显的治理架构失败——代理没有在防止漂移的边界内被约束，而是被赋予目标和工具后自行优化。

这就是为什么区域III中的代理部署有70%的失败率——要么代理“自行其是”，要么事后治理成本超过节省。

一项对美国银行控股公司的研究发现，AI投资每增加一个标准差，季度运营损失增加24%。该研究使用综合监管数据，发现AI投入与外部欺诈、客户/客户问题、系统故障类损失显著相关。风险增强效应在风险管理较弱的银行中更为显著。

代理治理决定了你的AI投资是让你更安全还是更昂贵。 ROI较低正是治理债务积累速度超过治理能力积累速度的经验特征。工具在部署，但监督没有跟上。

总结：天花板不是模型限制，而是真实工作的结构属性。治理架构差距是一个领导决策——你愿意在70%的流程景观中承担多少风险（那些没有适当控制就不应该被代理触碰的区域）。

† 阅读流程自动化适应性论文

你的代理没有身份、没有记忆、拥有全局API访问权限

以下是硬数据，我不打算软化：

• 只有21.9%的企业团队将代理视为带身份的主体。
• 45.6%的企业使用共享API密钥供代理访问。
• 25.5%的已部署代理可以创建和分配任务给其他代理，而委托链上没有治理层。
• 组织中60%的AI活动被估计为影子AI——代理和工具部署在任何集中控制结构之外。
• 98%的组织有员工使用未经批准的AI应用，20%已经遭受与影子AI相关的安全漏洞。

身份问题是基础性的。没有可验证身份的代理无法被审计、治理，当然也无法为其行为负责。IAM是为人类用户和服务账户设计的，它们有可预测的访问模式。自主代理没有可预测的访问模式，但它有目标，并且会利用可用的工具追求目标。拥有全局API令牌和目标导向推理循环的代理就是一个等待发生的事故。

因此我与Cakewalk的JOHANNES KEIENBURG合作（他们构建了专门用于代理AI的访问管理系统），并将在5月19日做一个30分钟的演讲。

“最小权限原则”正是为此存在——代理应该只有当前任务所需的最小工具集，而不是部署者认为可能用到的最大工具集。这是构建动态权限架构的问题，工具访问根据具体任务上下文授予和撤销，而不是基于代理的通用角色。大多数已部署代理远未达到这个水平。

然后是记忆问题。没有适当记忆治理的代理要么携带过多上下文（增加成本、隐私风险），要么太少（产生不一致行为，无法审计）。2026年3月，亚马逊零售网站因AI代理从过期的内部维基中提取不准确建议导致多次严重停服。代理有记忆访问，但记忆是错误的，且治理架构中没有机制在执行之前验证代理使用的信息的时效性和准确性。

另一个是审计线索问题。传统日志记录捕获请求-响应周期和基础设施健康指标，但不捕获推理溯源——即代理为什么选择特定行动、在推理循环中考虑了哪些替代方案、做决定时基于什么信息的结构化记录。没有推理溯源，事故发生后你无法重建发生了什么。向经过传统培训的审计员解释“你延迟指标很好，但无法解释为什么代理批准了权限范围之外的47笔交易”——这对话不会有好结局。

† 所有三个数字来自同一来源：Gravitee 2026年AI代理安全状态报告，调查了919名高管和技术从业者，美国与英国。代理身份21.9%，共享API密钥45.6%，能创建和分配任务的代理25.5%。2026年2月4日发布。

‡ 注册：如何在2026年安全大规模采用AI代理 | LinkedIn

² 阅读 Tokenomics 和 Patternomics 论文：

• Tokenomics
• Patternomics

治理你看不见的东西的经济学

治理常被当作成本中心，这个框架恰恰导致了现状。治理成本可见且容易削减；不治理的成本不可见，但一旦到来就是灾难性的。

部署后再改造治理控制的成本是提前构建的三到五倍。

一个三层护栏框架（策略层、工作流层、运行时层）在部署后90天内可将代理相关事故减少60%。

欧盟AI法案对高风险系统违规的处罚高达3500万欧元或全球年营业额的7%（取较高者）。

微调攻击绕过模型级护栏：针对Claude成功72%，GPT-4o 57%。

这就是你面对的现实，比SaaS平台上的炒作演示无趣得多。

治理开销本身有其成本结构：为高风险决策实现可解释性需要并行运行计算密集算法，这实际上使每个受治理事务的计算资源和延迟翻倍。此外，多代理复核循环和自我批评架构可能使复杂推理链的推理成本增加3-5倍。一个10步流程，每步准确率95%，最终成功率约60%——这在准确非可选的领域常常是致命的。这也是为什么区域III的70%部署失败。

我正在使用一个“AI FinOps框架”，将治理视为金融运营、风险管理和MLOps融合的学科。在其中，你衡量的不是每次推理的成本，而是每次合规决策的成本——代理项目的治理与价值比。这样做的组织将治理嵌入架构而非事后添加，持续优于将治理仅视为合规练习的组织。

Gartner预测到2027年40%以上的代理AI项目将被取消，原因是成本飙升、业务价值不明确、风险控制滞后。这是一个基于组织行为的预测。被取消的项目正是那些治理债务积累速度超过治理能力、事故在控制到位之前到来、最终经济案例在没人预算过的补救成本重压下瓦解的项目。

负责任的治理应该是什么样？

负责任的代理治理架构有详尽的文档，并且是可实施的，每个组件今天都能获得。但多数组织未实施的原因在于优先级。

运行时执行护栏在基础设施层运行，独立于模型推理。策略引擎（如Open Policy Agent或Cedar）将业务规则转化为确定的可执行逻辑，拦截每个提议的动作，在到达目标系统之前。如果代理试图执行违反策略的命令，护栏拒绝该命令，无论模型做了什么决定。这就是我之前说的软对齐与硬执行的区别。软对齐请求模型遵守；硬执行使违规在结构上不可能。如果PocketOS的策略引擎有“禁止在生产环境执行破坏性操作”的规则，其生产数据库不可能在九秒内被删除。

代理的身份与访问管理要求将每个自主实体视为一等身份主体，拥有自己的凭证、权限和审计线索。每个代理都需要一个独特的、可验证的身份，加密绑定到一组特定的、限于当前任务的工具权限。动态权限根据任务上下文而非代理的通用角色扩展和收缩范围。从编排代理到子代理的委托链需要明确的范围衰减——子代理不能继承超出任务实际需要的权限。这是最小权限原则应用于IAM系统本来未设计处理的一类角色。

推理溯源通过一些研究者称之为“代理执行记录”来实现，将意图和观察作为可查询字段与动作日志一起捕获。这把你的日志文件变成了真正的审计线索。当出问题时（肯定会出），你需要能够重建导致结果的推理路径，找出治理架构在哪一步未能约束代理行为，并向监管者或内部调查员证明你理解发生了什么以及为什么。没有推理溯源，你就只有一个事故。

人类监督设计要求你区分：完全自主（低风险区域I任务）、人不在回路中（区域II工作流，人审查输出但不阻止执行）、硬性人在回路门（区域III，判断成分太高不能委托给自主系统）。

多数组织的错误是所有任务类型统一采用一种监督模式，结果要么高风险任务监督不足，要么低风险任务监督过度。基于前述区域框架的任务级风险分类让你能够按比例应用监督。

紧急停止开关和升级机制是每个生产部署都需要但大多数没有的最后一道防线。紧急停止开关是一个专用的、安全控制平面机制，与代理操作环境隔离，可以在手动触发或自动异常检测警报时立即停止代理执行。升级机制是代理遇到其策略边界内无法解决的情况时，将控制权转移给具有上下文、权限和信息的人类。

这两个机制都不复杂，但都需要组织做出决定：自主代理在生产环境中是可以失败的系统，失败需要人工立即干预。

所以，你还有时间（大概）

代理治理债务危机：95%的事故率就是你的基线。

将治理同时视为企业架构问题和社会技术问题。在扩大用例之前而非之后建立治理能力。将监督嵌入代理项目的架构DNA，而不是在代理已经运行后作为合规层添加。

这是我写过最短的章节。

—— Marco

治理债务研究白皮书：下载链接

Eigenvector 构建大规模代理化工厂，针对真正需要回报的生产环境。Eigenvector Research 偶尔发布论文，解释为什么这比演示中看起来难得多。

觉得朋友也会喜欢？分享本通讯。

本文发表于 Generative AI。在 LinkedIn 联系我们，关注 Zeniteq 获取最新AI故事。