企业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。文档 BValidation 之前允许修改 Security ID。文档 C如果 Security ID 无效 Trade Validation 失败。文档 DValidation 成功后可以进行 Confirmation。Exception GuideConfirmation 失败后 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 真正需要跨过去的那道门槛。
企业AI真正缺失的一层：从文档到可执行流程，Agent只是暂时填补了这个 Gap
企业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。文档 BValidation 之前允许修改 Security ID。文档 C如果 Security ID 无效 Trade Validation 失败。文档 DValidation 成功后可以进行 Confirmation。Exception GuideConfirmation 失败后 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 真正需要跨过去的那道门槛。
