On this page
这两年，随着 AI 成为新的技术热点，经常出现这样的表述：过去企业花大量时间建设的数据库、ERP、CRM、开放平台，已经属于上一代的信息化体系；既然未来越来越多的工作都会交给 AI，那么这些传统系统的重要性自然会下降。
我并不认同这种判断。
技术热点的变化，很容易让人把“新的能力”理解成“旧的基础设施被替代了”。但如果把企业信息化的发展过程拉长来看，AI 并没有跳出过去几十年的数字化进程。相反，当 AI 真正进入业务之后，它仍然需要依赖企业原有的数据、系统、权限和业务规则。
换句话说，AI 并不会完全绕开企业过去的数字化建设。很多时候，它只是把这些原本服务于人的系统和规则，重新变成自己可以理解和调用的能力。
一、AI 化并不是对过去 IT 基建的推倒重来
企业的信息化，本身就是一个不断把现实业务转化成数字系统的过程。
从过往历史看，大致可以理解为几个阶段：
- 信息数字化：把原本存在于纸张、人工记录和个人经验里的信息，逐渐变成结构化数据。
- 业务系统化：通过 ERP、CRM、订单、售后等系统，把原本依赖人工协作的流程固化下来。
- 能力开放化：通过 API、消息、Webhook 等机制，让不同系统之间能够交换数据和调用能力。
- 业务 Agent 化：让 AI 根据当前状态进行判断，并进一步调用已有系统完成任务。
从这个角度看，AI 化并不是突然出现的一条新路线，而是在过去数字化建设之上的进一步演进。
如果企业只是希望 AI 写一段文案、总结一份资料，它确实可以相对独立地工作。
但只要真正进入业务，它就会立刻碰到企业既有的信息系统。
例如：
- 想知道客户是谁，需要客户数据；
- 想知道订单进行到哪一步，需要订单系统；
- 想判断设备是否仍在保修期，需要设备和售后数据；
- 想完成退款、创建工单或修改客户状态，需要相应的业务系统提供执行能力。
而且更进一步，真实业务不只“有数据、有接口”这么简单。
一个员工为什么能做某件事，往往还依赖很多隐性规则：他是什么岗位、拥有怎样的权限、什么情况下可以做决定、哪些情况必须请示、公司过去形成了什么样的处理惯例。
这些规则原本大量存在于人的经验和组织分工里。
所以，当 AI 真正进入业务时，它不仅需要接入数据库和业务系统，还要逐渐掌握这些原本依附在人身上的规则。
这意味着，过去的 IT 基础设施并没有因为 AI 出现而失去价值。相反，它们决定了企业有没有一个足够完整、清晰、可被机器使用的数字世界。
二、讨论“AI”之前，先明确我们到底在说什么？
今天“AI”这个词已经被使用得非常广泛。
在传播层面，我们可以把大模型、智能助手、Agent、自动化系统，甚至带一点模型能力的软件统称为 AI。这没有太大问题。
但一旦进入具体问题，这种模糊就会产生很多误解。
因为我们说“AI 能不能做这件事”时，实际上可能在讨论完全不同的对象。
- 有时，我们说的是大语言模型（LLM）
- 有时，我们说的是 Agent
而这两者的概念和能力边界并不相同。
1. 大语言模型，可以简单理解成一个“大函数”
如果暂时不讨论实现细节，可以把大语言模型简单抽象成：
输入 → 推理 → 输出
我们把一段文字、资料或者上下文交给模型，它进行推理，再返回一段结果。
从这个角度看，模型本身并不会真正去“做”什么。
它不会天然拥有某个企业系统的权限，也不会自动修改数据库，更不会凭空完成退款、创建工单或者操作设备。
它可以输出判断，也可以生成一段看起来像“指令”的内容，但真正去执行动作的，仍然是模型之外的数字系统。
这也是为什么企业最早落地的一批 AI 应用，往往是知识问答。
把 Word、PDF、说明书等资料放进知识库，再通过 RAG 提供给模型，就可以很快获得效果。此时主要解决的是：
如何把已有知识提供给模型。
这一阶段的提升通常很明显，因为资料原本就已经存在，只需要换一种方式交给模型。
2. 一旦说的是 Agent，周边问题就会突然变多
Agent 就不一样了。
当我们说一个 AI Agent 能够替我们处理客服、订单、售后或者其他业务时，它就不再只是一个“输入—输出”的模型。
它往往还涉及一整套周边能力，例如：
- Runtime；
- 工具调用；
- 状态管理；
- 上下文管理；
- 身份和权限；
- 外部系统接口；
- 执行结果；
- 异常处理。
这些东西并不是大语言模型本身。
但在日常传播里，它们往往都被“AI”这一个词盖住了。
所以很多讨论看起来是在问“AI 能不能做”，实际上真正的问题可能是：
- 模型能不能判断？
- 系统有没有提供这个工具？
- Agent 有没有权限使用？
- 当前状态有没有被提供给它？
- 业务的具体规则是什么？
- 什么情况允许自动完成，什么情况必须交给人？
如果不先把这些层次分清楚，就很容易把模型能力和整个 Agent 系统的能力混为一谈。
三、真正进入业务之后，开放能力只是起点，规则才是深水区
假设一个客户问：
“我昨天买的东西为什么还没有到？”
如果只是希望 AI 解释物流周期，那么知识库就够了。
但如果希望 Agent 真正解决问题，它就需要继续完成一系列动作：
- 确认当前用户是谁；
- 找到对应订单；
- 查询订单状态；
- 查询物流信息；
- 判断当前情况是否属于异常；
- 决定是否需要创建售后工单；
- 判断是否允许自动处理，还是需要转交人工。
走到这里，会发现 Agent 真正依赖的不只是数据。
它还依赖业务规则。
例如，同样是一个物流异常：
- 普通用户和重点客户的处理方式是否一样？
- 超过多少天才算异常？
- 哪种情况可以自动补发？
- 哪种情况必须由客服确认？
- 什么金额以下可以直接退款？
- 什么操作需要主管审批？
这些规则过去可能并没有被完整写在系统里。
一部分存在于制度中，一部分存在于员工经验中，还有一部分体现在“谁拥有什么权限”这样的组织关系里。
人在做业务时，可以自然地依赖这些背景知识。
但 Agent 不行。
如果希望它稳定地进入真实业务，就需要逐步把这些原本隐性的约定变成显性的规则。
这也是为什么，企业越往 Agent 化深入，越会重新遇到过去很多系统建设里已经存在的问题：
- 数据是否完整；
- 接口是否稳定；
- 权限是否清晰；
- 业务边界是否明确；
- 操作是否可审计；
- 规则是否能够被机器理解和执行。
因此，真正支撑 Agent 的开放能力，并不是简单地“做几个 API”，而是把企业已有的业务逐步整理成一套机器可以理解、调用和约束的能力体系。
四、很多企业会在“第一阶段成功”之后进入深水区
在实际接触不同企业的 AI 项目时，我反复看到类似的过程。
其中一个很典型的现象是：
企业在第一阶段往往很容易获得正反馈。
把说明书、业务资料、历史文档接入知识库之后，AI 很快就能够回答大量过去需要人工检索的问题。
这种提升非常直观，也很容易让人形成一种预期：
既然第一步这么快，那么接下来顺理成章的 AI 应该也能以同样的速度继续深入业务。
但很多项目真正的困难，恰恰从这里才开始。
案例一：一家工业设备企业
这是一家以工业设备销售和售后为主要业务的企业。公司本身不是软件公司，内部 IT 人员很少，日常业务依赖多个不同厂商提供的 SaaS，以及少量内部维护的工具。企业希望利用 AI 提高售后效率。
最开始，这个项目进展很快。
企业积累了大量设备说明书、维修手册和故障资料。把这些内容整理进知识库之后，AI 很快就可以完成不少原本需要售后人员人工查询的工作，例如解释故障码、查询维修方法，或者根据设备现象给出排查方向。
这种正反馈很容易让人进一步产生预期：
既然 AI 已经能回答这些问题，那么它是不是也能继续替我处理：
- 这是哪个客户；
- 客户买的是哪台设备；
- 设备什么时候出厂；
- 过去是否维修过；
- 当前有没有工单；
- 谁负责这个客户；
- 如果需要售后处理，能不能直接创建工单。
但问题到了这里，性质已经发生了变化。
前面的知识问答，主要依赖已经整理好的文档。
但后面的这些问题，开始依赖客户系统、设备系统、售后系统、订单数据以及不同系统之间的关联关系。
而现实情况是，这些信息可能分别存在于不同 SaaS 中，有些系统缺少完整接口，有些数据甚至没有统一结构。
于是，项目很快从“模型效果怎么样”，进入了另一个阶段：
过去没有完成的数字化基础建设，需要重新补课。
AI 可以快速证明“知识可以被利用起来”，但如果想继续进入业务，它就必须面对企业原本的数据分散、接口缺失、权限不清和规则隐性化等问题。
案例二：一家数字化基础相对完整的企业
另一家企业拥有自己的研发人员，核心业务已经运行在内部建设的系统之上。客户、订单和部分业务状态有相对清晰的数据结构，不同系统之间也已经存在内部接口。
在这种情况下，同样一个 Agent 项目，起点就会明显不同。
需要客户信息，可以调用已有客户接口；需要查询订单，可以使用现有订单服务；需要获取历史记录，也不需要重新从多个 SaaS 页面里想办法提取。
这意味着，项目可以更早进入真正的 Agent 问题：
- 哪些数据应该在一开始注入上下文；
- 哪些信息应该根据当前任务动态查询；
- Agent 可以自动执行哪些动作；
- 哪些操作必须人工确认；
- 原本属于不同岗位的权限，如何映射给 Agent；
- 人过去掌握的业务经验，哪些需要进一步抽象成规则。
此时，企业面对的已经不只是“有没有接口”，而是怎样让 AI 正确地使用这些接口。
这两个项目的差异，很能说明一件事：
企业可以使用同样的模型，也可以使用同样的 Agent 框架，但最终能够做到什么程度，并不会因此相同。
第一阶段的知识库应用很容易缩小这种差距，因为大家都可以快速把文档交给模型。
但一旦继续深入业务，企业过去的数字化建设水平就会迅速显现出来。
结语：Agent 化最终还是会回到业务本身
收回来，我真正想表达的其实有三点。
第一，不要因为 AI 成为新的热点，就全盘否定过去的 IT 基础建设
数据库、ERP、CRM、开放平台这些东西看起来不够“新”，但它们解决的是企业最基础的问题：数据在哪里、业务如何运行、系统之间如何协作。
AI 并没有绕开这些问题。
相反，Agent 越深入真实业务，就越依赖这些基础。
第二，讨论 AI 时，需要越来越明确它到底指代什么
大语言模型、Agent、Runtime、工具调用、权限、状态，并不是同一个概念。
在传播层面，它们都可以被笼统地叫做 AI；但在真正讨论产品和工程问题时，如果仍然只用一个“AI”来描述，就很容易把完全不同的问题混在一起。
很多时候，所谓“AI 能不能做”，其实不是单纯的模型问题，而是整个 Agent 系统是否具备相应能力的问题。
第三，Agent 真正进入业务之后，企业必须重新整理人与业务之间的关系
企业的真实业务，从来不只是系统和数据。
它还包含：
- 谁能够做什么；
- 什么情况下可以做；
- 哪些事情需要审批；
- 哪些异常需要人工介入；
- 员工依靠什么经验进行判断；
- 不同岗位之间如何协作。
过去，这些东西大量存在于人的经验、权限和组织关系里。
如果未来越来越多的业务交给 Agent，那么企业就必须逐步把这些内容从“人脑中的默认规则”，变成机器能够理解和执行的显性规则。
这可能才是 Agent 真正进入企业之后最深的一层变化。
因此，未来企业 AI 化的天花板，并不只取决于模型能力。更重要的是，企业能否重新梳理自己的业务，并把业务整理成边界清晰、职责明确、可以被 Agent 安全调用的能力：即每个能力有明确的输入和输出，有清楚的权限边界，也有对应的业务规则。
过去开放平台做的，是把企业能力提供给其他软件和开发者。
未来，它还可能进一步承担一个新的任务：
把企业的业务能力整理成 Agent 可以安全、准确地使用的工具。
从这个角度看，梳理业务、显性化规则，并把业务抽象成原子的开放能力，并不是 Agent 时代可有可无的工程优化。
它很可能会成为企业真正提高 Agent 能力之前，必须补上的基础建设。