企业AI真正缺失的一层：从文档到可执行流程，Agent只是暂时填补了这个 Gap
现在谈 Enterprise AI，几乎绕不开 Agent。
查数据做一个 Agent，操作业务系统做一个 Agent，处理订单做一个 Agent，运维系统再做一个 Agent。
这种方式当然有效。
但在最近将企业知识进一步转换为自动化流程的实践中，我越来越意识到一个问题：
今天我们大量使用 Agent，其实是在人工填补“企业知识”与“可执行流程”之间缺失的一层。
它可以解决当前的问题，但从 Enterprise AI 的长期架构来看，更像是一种过渡方案。
真正需要解决的问题可能并不是：
企业需要多少 Agent？
而是：
企业已经拥有的大量知识，如何被 AI 理解为可计算、可验证，并最终可以执行的业务过程？
一、今天的 Agent，其实隐藏了大量人工工作
我们现在实现一个企业 Agent，通常是这样的过程：
业务文档 ↓ 业务专家理解 ↓ 开发人员理解 ↓ 人工定义 Workflow ↓ 开发 Tool / MCP / API ↓ 编写 Agent ↓ LLM 调用最终用户看到的是：
User ↓ AI Agent ↓ Business System看起来好像 AI 已经理解了企业业务。
但实际上，真正困难的部分往往发生在 Agent 开发之前。
是人完成了：
Document ↓ Understanding ↓ Business Process ↓ Business Rule ↓ Executable Workflow然后把这个结果写进 Agent。
换句话说：
Agent 看起来理解业务，是因为开发 Agent 的人先理解了业务。
因此今天很多 Enterprise Agent，本质上仍然是：
Human Knowledge Engineering + LLM Interface + Tools。
这没有问题，而且是目前非常实用的落地方式。
问题在于：它是否能够规模化？
二、企业不可能永远靠人工编写成千上万个 Agent
一个简单系统也许只有几十个业务流程。
但是大型企业系统完全不同。
以金融交易系统为例，一个 Trade 就可能涉及：
Trade Entry Validation Confirmation Settlement Amendment Partial Termination Full Termination Accounting Risk Exception Handling ...不同产品又有不同规则：
Trade ├── Bond ├── Swap ├── FX ├── Repo └── ...不同产品下面继续细分。
不同版本之间规则还可能发生变化。
不同客户又可能存在自己的配置和业务规则。
如果每一种业务组合都依靠开发人员：
读文档 → 理解业务 → 设计 Workflow → 写 Agent那么所谓 Agent 化，实际上变成了：
把整个企业业务重新人工实现一次。
只是以前写在应用程序中，现在又写进 Agent。
这显然很难成为 Enterprise AI 的最终形态。
三、真正缺失的是 Documents → Process 这一层
现在常见的 Enterprise AI 架构是：
Documents ↓ RAG ↓ LLM ↓ Agent ↓ ToolsRAG 解决了一个非常重要的问题：
AI 如何找到企业知识？
但是找到知识，并不意味着可以执行知识。
例如文档写：
When a position row is selected on the Viewer, the Security ID is prefilled on the Bond Trade entry.
RAG 可以很好地回答：
Security ID 是如何产生的？
但如果我们希望 AI 自动形成一个业务流程，它必须进一步理解：
Event: PositionSelected Action: PrefillSecurityID Source: Position.securityId Target: BondTrade.securityId Operation: Bond Trade Entry Context: Position Viewer Data Lineage: Position.securityId ↓ BondTrade.securityId这已经不再是普通的文档检索。
它开始变成：
Computable Knowledge。
也就是说，从“AI 能找到答案”到“AI 能够执行企业业务”，中间实际上还隔着很长的一段距离。
四、更困难的是：企业流程通常根本没有完整写在一个地方
这是实践中非常现实的问题。
最开始很容易产生一个想法：
让 LLM 阅读文档，然后生成完整 Workflow。
但真正进入企业文档以后就会发现，这个假设通常不成立。
一个流程的信息可能分散在很多地方。
例如：
文档 A：
选择 Position 后， Security ID 自动填入 Trade Entry。文档 B：
Validation 之前允许修改 Security ID。文档 C：
如果 Security ID 无效， Trade Validation 失败。文档 D：
Validation 成功后可以进行 Confirmation。Exception Guide：
Confirmation 失败后， Trade 保持 Validated 状态。Settlement 文档又写：
Confirmation 成功后生成 Settlement Instruction。没有任何一个文档真正告诉 AI：
这是完整的 Trade Process。完整流程实际上隐藏在这些知识之间。
而对于一个原本就不了解这个业务领域的 AI 来说，还有一个更加困难的问题：
它怎么知道自己缺了什么？
如果我们事先已经知道完整流程，那么让 AI 去寻找对应知识并不困难。
真正困难的是未知领域。
AI 看到 A、B、C、D 四段知识以后，凭什么知道还有 E？
如果依靠模型自己的常识补 E，我们又重新回到了 Enterprise AI 最不希望出现的问题——一个逻辑上很合理、实际上却不存在于企业规则中的流程。
因此，“从企业文档自动走向执行”真正困难的地方，并不是调用 API，也不是 Agent 会不会使用工具，而是：
如何从分散、不完整、具有条件、版本和业务上下文的知识中，重建一个有证据支撑的业务过程。
这可能才是 Documents 和 Agents 之间真正缺失的那一层。
五、我们是在用 Agent 解决问题，还是在用 Agent 重新实现一遍企业？
这让我想到一个值得继续讨论的问题。
过去十多年，企业软件经历了从单体应用向 SOA、微服务演进的过程。
我们把一个大型系统拆成很多服务：
Service A Service B Service C Service D ...然后再通过 API、消息和编排把它们组合起来。
现在进入 Agent 时代，我们似乎正在做一件非常相似的事情：
Agent A Agent B Agent C Agent D ...一个 Agent 负责订单，一个 Agent 负责 Settlement，一个 Agent 负责运维，一个 Agent 负责数据查询，再通过 MCP、Tool、API 或 Multi-Agent Orchestration 把它们连接起来。
区别只是：
Service 封装的是程序逻辑，Agent 还可以封装自然语言理解、知识和推理能力。
这当然让 Agent 比传统 Service 灵活得多。
但问题也随之而来：
如果一个业务出现一种变化，我们增加一个 Agent；
一个产品有特殊规则，我们增加一个 Agent；
一个版本有不同流程，我们再增加一个 Agent；
一个客户有特殊配置，我们继续增加 Agent。
那么几年以后，我们会不会从过去的：
Service Sprawl
走向新的：
Agent Sprawl？
更值得思考的是，如果每一个 Agent 背后的业务流程和规则，仍然需要开发人员先阅读企业文档、理解业务，再人工编码进去，那么我们真正改变了什么？
过去是：
Business Knowledge ↓ Developer ↓ Service现在变成：
Business Knowledge ↓ Developer ↓ Agent我们只是把 Service 换成了一个更加智能的 Service。
这当然是进步。
但它可能还不是 Enterprise AI 最终要解决的问题。
真正值得期待的也许是：
Business Knowledge ↓ AI Understanding ↓ Computable Business Knowledge ↓ Business Process ↓ Execution到了那个阶段，Agent 才不需要成为企业知识和业务流程的另一个“人工编码容器”。
它更像一个执行者：根据当前任务、当前上下文和企业已有知识，动态获得自己需要执行的能力。
所以最后留下一个问题：
用大量类似“微服务”的 Agent 去替代过去的 Service，真的是 AI 时代企业软件的解决之道吗？
还是说，这只是当前从传统软件向 AI-Native Enterprise 过渡阶段的一种权宜之计？
如果我们最终仍然需要人工理解企业的每一个流程，然后把它重新写成一个又一个 Agent，那么我们可能只是完成了：
Service → Agent
而真正尚未完成的变化是：
Knowledge → Computable Knowledge → Action。
也许，后者才是 Enterprise AI 真正需要跨过去的那道门槛。
