企业里搞 Agent 真的别只盯着单个模型的能力

我最近在复盘几个公司落地 AI Agent 的案例，发现一个特别诡异的现象：大家都在讨论怎么写好 Prompt，怎么让 Agent 的推理能力更强，但几乎没人关心当 Agent 变成“集群”之后，权限和链路是怎么管理的。

现在的企业级应用根本不是跑一个孤立的 Agent，而是部署一堆 Agent。A Agent 调用 B 的 API，B 又去触发 C 的工作流，最后可能还顺手改了下数据库。这种规模化的复杂度不是线性增加的，而是指数级的。你增加一个 Agent，看似只加了一个节点，但实际上它可能和现有的十几个 Agent 产生无数种调用组合。

我总结了两个特别容易踩坑的实操痛点，大家在部署工作流时一定要留意：

• 权限蔓延（Permissions Creep）： 很多开发者为了图省事，在给 Agent 配置 API Access 时，会直接给一个比较宽泛的权限（比如 Read/Write 权限全开），理由是“反正只是做个摘要，没那么复杂”。结果半年后，这个原本只负责总结工单的 Agent，因为链路跳转，竟然拥有了修改支付系统的权限。这种权限的“隐形漂移”在复杂的 Agentic Workflow 里简直是定时炸弹。
• 责任链断裂（Ownership Thinning）： 当一个业务流经过 5 个 Agent 传递时，如果第 4 步出错了，你会发现根本找不到人负责。现在的组织架构通常只管“谁部署了这个 Agent”，却没人管“谁为这个 Agent 产生的下游连锁反应负责”。

要解决这种“黑盒化”的问题，不能靠那种“一次性审批”的 checklist 模式，那太迟钝了。我个人的实操经验是，必须得建立一套完整的 Agent 治理体系：

1. 身份独立化： 别让 Agent 挂在某个开发者的权限下面“借用”权限。每个 Agent 都必须有自己独立的 Identity，有明确的 Scope，并且必须绑定一个明确的人类 Sponsor（负责人）。
2. 实时拦截而非事后审计： 很多公司做的是 Monitoring（监控），也就是出事了发个报警。但真正的 Governance（治理）应该是 Enforcement（执行）。你得能在 Agent 尝试进行一次越权调用时，直接在 API 网关层面把它掐断，而不是等三个星期后在审计报告里才发现钱丢了。

如果你的 Agent 链路已经开始变得复杂，建议先别急着加新功能，先把 Agent 的身份标识和调用链路的可视化做出来，否则最后只会得到一个谁也解释不清的“数字黑洞”。