企业开始用 Agent 之后，真正麻烦的事才刚刚开始

最近看了一个产品，叫 川序 Chuanxu。

我觉得做企业 AI、数字化，尤其是正在推进 Agent 落地的人，可以花点时间看看。

不是因为它又做出了一个多聪明的 Agent。

恰恰相反。

它没有继续卷 Agent，而是在想：企业以后怎么管 Agent。

这个问题，我觉得比再做一个 Agent 平台更值得关注。

Agent 少的时候，很多问题都不是问题

现在不少企业的 AI 还处在早期。

研发部门几个 Agent，客服部门几个 Agent，财务自己做一个，HR 再做一个。

总共也没多少。

这个阶段，大家关心的通常是：

模型效果怎么样？

能不能调用系统？

能不能自动完成任务？

准确率高不高？

能不能真正替代一部分人工？

这些当然重要。

但只要 Agent 真正开始进入业务，下一个问题很快就会冒出来。

公司到底有多少个 Agent？

这些 Agent 分别是谁创建的？

属于哪个部门？

谁是负责人？

它能看哪些数据？

能调用哪些系统？

谁批准了它的权限？

昨天晚上它到底做了什么？

如果员工离职，他创建的 Agent 怎么办？

如果一个 Agent 出现异常，能不能马上停掉？

如果服务器挂了，它正在执行的任务还能不能恢复？

这些问题，现在 Agent 少的时候感觉不到。

等 Agent 多起来，全是问题。

就像二十年前企业刚开始信息化的时候，大家觉得账号密码能登录就行。

后来才慢慢有了组织架构、角色、权限、SSO、日志、审计、堡垒机、CMDB。

Agent 也会经历同样的过程。

川序做的，恰恰就是这一层

图片

我看完川序之后，对它的理解很简单：

它想成为企业 Agent 的管理控制面。

不管下面跑的是哪种 Agent，企业最终都需要统一管理它的身份、组织归属、负责人、权限、任务、协作、运行状态和审计记录。

换句话说，它关注的不是：

“这个 Agent 能不能干活？”

而是：

“这个 Agent 能不能作为企业正式的一部分，长期、安全、稳定地干活？”

这两个问题完全不是一回事。

一个 Agent 能完成一次任务，不代表它能进入生产环境。

企业真正需要的是：

这个 Agent 是一个受管理的生产要素。

它必须有身份。

必须有负责人。

必须知道属于哪个组织。

必须有明确的数据边界。

必须知道什么事情可以自己做，什么事情必须审批。

出了问题，还必须能追溯、暂停和恢复。

这时候 Agent 才真正从 Demo 进入企业。

我特别认同一句话：提示词不能代替权限

今天很多 Agent 项目的安全设计，某种程度上还是靠自觉。

比如在 Prompt 里告诉它：

不要访问某些数据。

不要执行危险操作。

没有批准不能干什么。

但这和真正的企业权限不是一回事。

一个财务 Agent 如果不应该看到某些数据，正确的方式不是告诉它：

“请不要看。”

而应该是：

它根本就没有权限看。

这其实是 Agent 从玩具变成生产系统的一个分水岭。

以后 Agent 可以查数据、写代码、改配置、发消息、审批流程、生成合同，甚至进一步操作 ERP、采购和财务系统。

那个时候最大的风险，可能已经不是它偶尔回答错一个问题。

而是：

一个不该有权限的 Agent，拥有了执行权。

所以未来企业 AI 很重要的一块基础设施，我认为一定不是 Prompt Engineering。

而是：

Agent IAM。

图片

谁是谁。

谁属于谁。

谁能干什么。

谁批准了。

什么时候失效。

最后谁负责。

这些东西听起来一点都不性感。

但真正做过企业系统的人都知道，到了生产环境，最后决定系统能不能大规模使用的，往往就是这些东西。

还有一点，我觉得它想得比较远

川序还有一个思路，我很感兴趣：

数据库不只是存 Agent 的数据，也成为 Agent 的控制面。

现在很多 Agent 的状态散落在 Markdown、JSON、本地 Memory、向量库、框架运行时里。

做 Demo 很快。

但是企业真正跑一年以后就会发现：

到底哪个状态是真的？

两个 Agent 同时修改怎么办？

任务跑到一半机器挂了怎么办？

换一个 Agent 实例还能不能接着干？

谁修改过这个状态？

怎么回溯？

所以川序选择把 Agent 的核心身份、任务、状态、协作、运行过程和审计证据，尽可能放回数据库体系里。

这个思路非常传统。

但企业系统最后往往需要的，就是这些传统能力。

AI 可以很新。

生产系统不能每天靠运气运行。

真正值得思考的是：公司有 500 个 Agent 以后怎么办？

现在我们正在疯狂讨论：

怎么做 Agent。

怎么训练 Agent。

怎么让 Agent 干更多的活。

怎么让 Agent 替代更多重复工作。

但很少有人认真讨论：

当 Agent 真正开始干活以后，我们准备怎么管理它？

假设两三年以后，一家公司有 500 个 Agent。

有些属于财务。

有些属于 HR。

有些属于采购。

有些负责研发。

有些负责客服。

还有几十个 Agent 之间自动协作。

这时候一定不可能再靠一个 Excel 表登记：

Agent 名称、负责人、API Key。

甚至每个部门自己管自己的 Agent都未必行得通。

因为 Agent 最终会跨系统、跨部门、跨数据域运行。

企业一定会需要一套新的管理基础设施。

今天企业 IT 管的是：

人、账号、设备、服务器、应用、数据库。

以后很可能还会多一个一级管理对象：

Agent。

我为什么推荐大家关注川序

不是因为我认为所有企业现在都应该马上上一套 Agent 管理平台。

很多公司的 Agent 数量还远没有到必须治理的阶段。

我更推荐大家看的，是它提出的问题。

因为这些问题，今天可能看起来有点早。

但只要企业真的开始大规模使用 Agent，就一定绕不过去。

我一直觉得，企业 AI 落地不能只盯着“能不能做出来”。

真正的难点往往在后面：

做出来以后，敢不敢让它进生产？

进生产以后，敢不敢让它持续运行？

持续运行以后，出了问题能不能找到责任链？

如果 FDE 解决的是：

怎么把 Agent 真正做进业务。

那么川序这一类产品解决的是另一个问题：

Agent 进了业务以后，企业到底怎么管。

前一个问题决定 Agent 能不能产生价值。

后一个问题决定企业敢不敢把越来越多的权力交给 Agent。

我越来越觉得，企业 AI 真正进入深水区之后，后一个问题可能比我们今天想象得更重要。

所以川序这个产品，我推荐做企业 AI、FDE、数字化、架构和安全的人都去看看。

未必现在就需要用。

但它提出的问题，我们迟早都会遇到。