你的软件下一位用户将是 AI 智能体。你的架构准备好了吗？

想象一下，一个 AI 智能体正在处理客户的账单争议。它阅读投诉，核查账户历史，并判断应当给予客户一笔抵扣。整个过程只需几秒钟。

很了不起。现在，让它真正把这笔抵扣发放出去。

客户协议存放在另一个系统中。审批规则深藏在应用程序代码里。账单工具则要求由人逐一点击多个界面才能完成操作。

智能体知道该做什么，但现有架构不允许它完成任务。

随着智能体式人工智能投入实际应用，我预计会有越来越多的企业遇到这个问题。然而，奇怪的是，完成任务的障碍与智能体的智能程度几乎毫无关系。

多年来，我们一直在为使用企业软件的人进行现代化改造。现在，我们需要让软件适应那些日益承担操作任务的智能体。

用户界面从来都不是产品的全部

想想当今企业软件的运作方式：人们打开应用程序、浏览仪表板、做出决策，并在不同系统之间推进工作。用户界面是他们与业务互动的方式。

智能体不一定需要这些界面。它可以通过 API、模型上下文协议（MCP）服务器和其他程序化接口获取信息并发起操作。这是向无头架构转变的一部分。

但无头并不意味着应用程序会消失。应用程序中的数据、业务规则、权限和合规要求仍然重要。我认为，它们甚至更加重要。

多年来，软件供应商一直凭借精心设计的用户界面、用户习惯以及员工再培训成本建立竞争优势。当智能体无需打开应用程序界面就能完成更多工作时，这些优势便会减弱。此时，更有价值的是底层的记录系统：可信数据、经过验证的领域逻辑、运营治理以及可审计的交易。

这也会带来商业层面的影响：到 2030 年，企业应用支出中最高可达2340 亿美元的部分，可能受到智能体式 AI 带来的颠覆性影响。这些支出面临被颠覆的风险，但并不意味着它们注定会消失。而当智能体开始承担过去由人们在仪表板中完成的工作时，按席位收费的模式可能会越来越多地转向按使用量、操作次数或结果收费。

对软件供应商而言，这是商业模式上的挑战；对依赖这些应用程序的企业而言，这是架构上的挑战。

我们实现了各部分的现代化，却没有改造工作流程

大多数企业多年来一直在推进现代化改造。一支团队更新旧版应用程序，另一支团队将分散的数据整合到现代化平台上，还有一支团队构建集成方案，或者只是更新用户界面。

每个项目都可能单独取得成功。问题始于智能体需要跨越所有这些系统执行一项工作流程时。

你可以向智能体提供准确的客户信息，但如果负责据此采取行动的应用程序仍将关键规则埋在旧版代码中，接下来会发生什么？或者，你可以开放一个简洁的 API，但其背后的数据仍然不一致。智能体可以采取行动，但你能相信它做出的决定吗？

在这两种情况下，我们都只是让部分技术实现了现代化，却没有改造实际工作。

智能体式 AI 并不在意哪个现代化项目取得了成功，它在意的是整个工作流程能否顺利运行。

实际情况是这样的。一位客户需要加快复杂发动机维修的报价流程，而合同规定了哪些零件可以维修、更换或翻新。每份报价都需要花费数天，有时甚至数周，人工查阅合同和维护手册。客户已经完成了数据平台的现代化改造，但报价速度并未因此提升，因为瓶颈从来不在数据，而在研究。我们围绕一套研究智能体重新构建了这一工作流程，将研究时间缩短了 80%，报价流程也因此提速，效率与以往截然不同。

因此，应用程序现代化和数据现代化不能被规划成两个彼此独立的工作流。架构必须能够支撑完整的业务成果。

有 API 并不意味着系统已为智能体做好准备

人们很容易以为答案很简单：开放端点、连接智能体，就大功告成了。

要是事情真有这么简单就好了。

获取信息是一回事，发放抵扣、更新财务记录或订购替换零件则完全是另一回事。现在我们讨论的是执行，而不只是访问。

这就是我所说的智能体控制面：智能体通过这一边界明确、受到治理的接口，从记录系统读取数据并向其中写入数据。

API 和 MCP 服务器可以向智能体开放工具和数据。但 MCP 并不会自动落实业务规则，也不会判定谁有权采取行动。这些控制仍须在底层系统和工作流中进行设计。

智能体能否获取权威数据？业务规则是否明确，并得到一致执行？它能否提出行动建议，但只执行获准执行的操作？出现问题时，我们能否追踪操作、处理异常，并在可能的情况下予以撤销？

这些问题不是靠更好的模型就能自行解决的。它们涉及工作流、应用设计、数据架构、集成和治理，而且必须一并解决。

从工作本身着手，而非从技术入手

那么，应该从哪里开始？

我不会从让每个应用都采用无头架构，或开放所有可用 API 入手。我会先选定一个有实际意义的业务工作流。

从头到尾梳理这个工作流。哪些系统保存着记录？业务逻辑在哪里？智能体可以信任哪些数据？哪些决策需要人工批准？如果系统在流程进行到一半时发生故障，会怎样？如何持续落实治理？

你会发现那些关键的缺口。这就是你的现代化路线图：围绕业务成果制定一份跨应用、数据、集成和控制措施的协调待办事项清单，而不是推进彼此割裂的技术项目。

衡量成效时也应据此进行。不要看开放了多少 API 或迁移了多少数据，而要看工作流能否可靠地完成、异常如何得到解决，以及业务成果是否有所改善。

我们的目标不是让所有事情都实现自主化，而是实现可靠、可信的执行，并在适当之处发挥人的判断力。

真正的转变远不止无头化

让我感到振奋的，不是淘汰仪表盘，而是人们不再需要在彼此割裂的系统之间手动传递工作，就能完成任务。

但如果只是在从未为智能体设计的架构之上加一层智能体，我们就无法实现这一目标。

下一代企业软件的定义，不会只取决于它能让人们看到什么，还取决于它能让智能体可靠、负责任地做什么。