AI 能写代码之后,企业软件真正需要重构的是什么?

重要的不是 AI 完成了什么，而是它知道什么时候停下来

设想这样一笔订单。客户提出需求，一个 Agent 查询了库存、生成了报价，正准备把订单推进下去。这时客户又提了一个额外折扣，超过了 Agent 当前被授予的权限。Agent 没有继续往下走，而是停下来，发起了一道审批；等负责人确认之后，流程才接着进行。

在这个场景里，最值得关注的是，它是否知道这个客户是谁，知道库存该怎么算，知道自己能做什么、不能做什么，以及在什么时候必须把决定重新交回给人。

这几年，我们投入了大量注意力去讨论AI 怎样更快地写出一个系统。

我想提出的问题是，我们是不是因此忽略了另一半：这个系统，究竟怎样才能把企业的业务，安全地交给 AI 去执行？

对话框不是终点，受控执行才是关键

当AI 进入企业软件后，带来的变化不只是用聊天代替了点击。

第一个层次，是人用自然语言向系统提问，系统给出回答，但真正的操作，最后还是由人自己去完成。这当然有用，它降低了查询和理解的门槛。但它没有改变谁在执行。

第二个层次才是关键：Agent 可以在一个明确的授权范围内，直接调用业务动作、推进流程、处理掉一部分常规工作，并在需要的时候，主动请求人来做决策。到了这一层，执行这件事本身，开始部分地从人转移到了 Agent。

顺着这个方向，企业软件要做的，就不只是让人用起来更顺手，还要让 Agent 能够理解它、调用它。换句话说，人和 Agent 可以通过不同的入口，去使用同一套业务能力。

当然了，这并不意味着界面会消失。恰恰相反，界面仍然承担着很重要的职责——复杂的操作、需要协作的环节、异常情况的处理，以及人对结果的检查和确认，很多都更适合在界面上完成。

对企业负责人来说，真正该关心的，也不是我的系统里有没有一个聊天窗口。而是某一项具体的业务，能不能因此减少重复操作、缩短处理过程，同时还保持在可控的范围之内。

交给 Agent 的，不能只有一句任务

我在分享时常用三个词来描述这件事：世界、手、围栏。它们听起来像比喻，但每一个都对应着明确的业务和技术含义。

先说世界，指的是业务上下文。客户是什么，报价和订单之间是什么关系，什么叫作可用库存，一笔订单处在什么状态才允许进入下一步——这些构成了 Agent 需要理解的业务世界。

再说手，指的是它可以调用的业务动作：查询库存、创建报价、申请折扣、提交订单。这里要注意，一个动作不只是一个接口的名字。它还需要有明确的输入、明确的执行条件，以及明确的结果——申请折扣和直接给出折扣，是两件完全不同的事。

最后是围栏，指的是执行的边界。谁能操作哪些数据，什么情况下必须走审批，哪些状态下不允许继续往下，一旦出了问题又该如何追踪。围栏不是用来限制 Agent 干活的，它是让 Agent 能够被放心地用起来的前提。

把这三样放在一起，可以收束成一句话：任务描述告诉 Agent 想做什么，而业务定义和执行规则，决定它究竟能做什么。

模型不会自动获得一家企业的实时数据、内部的业务口径和授权规则。这些东西，需要被明确地提供、持续地维护、并且在执行时真正落实，它不会凭空长在模型脑子里。

那么，我们能不能把这些原本散落在文档、接口和代码里的信息，组织成一套共同的、机器能用的业务定义？

可执行的业务定义，不是另一份需求文档

我们尝试把一家企业管理什么、允许做什么、必须遵守什么，表达成一套结构化的、而且能够参与系统执行的业务定义。为了讨论方便，我把这种定义称为可执行本体。需要说明的是，这是本文采用的一个工程口径，用来指代这类能被运行时使用的业务定义，并不是要去给哲学或学术意义上的本体下一个统一的定义。

它和一份需求文档最大的不同在于，它不只是写清楚有哪些数据，而是要把对象和它们之间的关系、可以执行的业务动作、相关的权限与规则、业务的流程与状态，以及必要的交互视图，都一并描述出来。

我用一个概念上的例子来说明它大致包含什么。请注意，下面只是用来说明机制的示意，并不是任何真实系统的配置语法，其中的具体数字也只是假设值。

（以下为说明机制的概念示意，非真实配置语法）

业务对象：客户、报价单、订单。

对象关系：订单关联某个客户，并引用一份有效的报价。

业务动作：生成报价、申请折扣、提交订单。

数据权限：销售人员只能处理自己被授权的客户。

审批规则：折扣超过 10%，必须经过审批（10% 只是假设值）。

状态约束：审批没有通过的报价，不允许转成正式订单。

审计要求：记录操作者、审批人、规则的版本，以及执行结果。

有了这样一份定义之后，软件的构成就可以被拆成两部分来看。一部分是业务定义，它描述的是这家企业的差异化——它管理什么、允许做什么、必须遵守什么。另一部分是运行时，它负责把这些定义落实成可执行的系统行为，承接数据操作、接口、校验、权限、流程这些对大多数企业来说都通用、可复用的机制。

所以我的判断是，这件事的本质并不是代码消失了。而是企业差异化的业务定义，和可复用的技术实现，被更清楚地分开了。真正复杂的运行时代码依然存在，只是它不再需要为每一个业务规则重写一遍。

讲到这里，熟悉工程的读者大概会立刻反问一句：这不就是把代码换成配置吗？

只是换一种文件格式，本身没有任何价值。真正值得讨论的是：这份定义是否具有明确的语义，能不能被验证，能不能约束不同的入口（而不是只管住页面、管不住接口），以及能不能被长期、可靠地维护下去。如果这几件事做不到，那它确实就只是另一份更漂亮的配置文件而已。

当然，不是所有业务都能被一份简洁的定义覆盖。复杂的算法、特殊的外部集成、藏在老员工经验里的隐性规则、以及那些确实特殊的流程，仍然可能需要额外的扩展、工程实现和人的判断。

同一套定义，连接 AI 建系统与 Agent 用系统

同一套经过确认的业务定义，其实在两条不同的路径上都被用到了。

第一条是建设路径。人和 AI 一起把需求沟通清楚，形成业务定义，再经过校验、评审和测试，发布给运行时，最终得到一套可以使用的业务系统。在这条路径上，AI 帮助我们更快地把业务建出来。

第二条是运行路径。人或者 Agent 发起一个请求，系统先验证它的身份和授权，再检查相关的业务规则和当前状态，然后要么执行动作，要么进入审批，最后返回结果并记录下审计。在这条路径上，定义帮助系统判断这次请求能不能做、该怎么做。

同一套定义，在建设阶段指导系统成形，在运行阶段为理解和执行提供依据。这就是我说的那个连接点——AI 构建系统和 Agent 使用系统，终于有了一个共同的基础。

但，提出规则修改和获得修改规则的权限，是两回事。

还是用折扣的例子。一个 Agent 不能因为想把这单促成，就自己把折扣超过 10% 必须审批改成超过 20% 才审批。对规则本身的修改，应该走一条独立的评审和发布流程，而不是在一次业务执行里顺手完成。

再往下,有几个真正有分量的技术问题，恰恰是不能靠模型记得遵守来解决的。比如：当 Agent 绕过页面、直接去调用接口时，它能不能改动一张自己无权修改的订单？一份报价在获批之后，如果金额或折扣又发生了变化，原来的审批是否还算数？同一个请求如果被重复发送，会不会就重复生成了两张订单？

这些都是应该被认真验证的问题。当然，我不会说 ObjectStack 已经把它们全部解决了，这类保证需要靠实际的测试去确认，我想强调的只是一个方向：可靠性不能只依赖模型记得遵守规则，业务约束必须在真实的执行路径上被落实。

还要补一句，业务定义并不等于企业的全部知识。Agent 真正办事的时候，仍然需要当前的业务数据、相关的资料和具体的任务上下文。

我之所以会这样去想这些问题，是因为这正是我们围绕 ObjectStack 这条路线在尝试的事情：把关键的业务对象、关系、动作、权限和流程表达成结构化的定义，由运行时去解释和执行，并据此衍生出相应的业务接口、交互界面，以及提供给 Agent 的工具能力。

不只是开发便宜，而是业务更容易改变

如果只把这件事的价值理解成开发更快、更便宜，我觉得是看小了。

我更愿意从三个具体的变化来谈。

第一个变化，是业务调整的成本。还是那条折扣审批规则，假设有一天公司决定调整它。真正的问题不是几分钟能不能改完代码，而是：改完之后需要动哪些地方，怎么检查影响的范围，页面、接口和 Agent 调用是不是仍然遵守同一条规则，又该怎么测试和发布。当业务定义是统一的一份时，这种调整要减少的，是大量的人工交接、重复实现，以及这里改了那里忘了的遗漏风险。对一家需要不断调整策略的企业来说，这种业务更容易改的能力，往往比第一次开发更便宜更重要。

第二个变化，是企业能够积累下来的资产。除了业务数据之外，企业还可以慢慢积累一套由自己掌握、可以审查、可以版本化、可以持续演进的业务定义。当然，我不会说业务定义就是企业唯一的资产——客户、品牌、经验和真实的经营能力，一样重要甚至更重要。我也不会把定义是开放的等同于迁移是没有成本的：运行时的兼容性、扩展代码、数据迁移，仍然需要逐一验证。

第三个变化，关系到交付人员的工作重心。这是我在自己团队里尝试的一件事：让那些更理解客户需求的交付人员，借助 AI 和平台的能力，更直接地参与到业务系统的构建和验收中来。我想说清楚，这里的重点绝不是程序员不值钱了。恰恰相反，需求的澄清、规则的建模、系统工程、异常的处理，以及对交付结果负责这件事，正在需要一次重新分工。

重复性的实现工作可能会减少，但企业仍然需要有人，为系统的可靠性和最终的业务结果负责。

也正因为如此，在算这笔账的时候，不能只盯着写代码或者调用模型的那点费用。集成、数据治理、测试、复核、运维和风险，这些同样是实打实的交付成本，而且往往是更大的那一部分。

先验证一个业务模块，而不是宣布重做整个 ERP

讲了这么多判断，落到实践上，我自己的做法反而是保守的。我们是在一些任务执行和工作计划相关的项目里去尝试的，涉及年度计划、季度计划、月度计划、任务执行和考核这几类业务。

我之所以觉得这类业务适合用来讨论，是因为它天然地在问一个问题：怎么把一段文字里的安排，转化成系统里的对象、关系、责任、状态和动作。一句“这个季度每人要完成三个重点任务，逾期要上报”，背后其实就藏着对象、规则和状态。

具体怎么定义，我用“例如可以这样”来说明，而不把它写成已经完成的事实。例如，可以把计划、任务、责任人、考核结果分别定义成对象，把任务逾期要上报写成一条明确的规则，把考核未完成不能关闭计划写成一个状态约束。这些都只是示意，真正的定义要结合具体业务去打磨。

更重要的是，怎么判断它真的可用，而不只是界面已经生成出来了。我倾向于把验证标准落在具体的行为上，去看几件事：任务能不能按照规则被推进，越权的操作能不能被真正阻止，需求变化之后有没有经过测试，以及执行的记录能不能被事后追溯。

对已经有成熟系统的企业，我的建议是审慎的：优先挑一个边界清晰的模块，和现有系统做集成或者协同，一步步验证，完全不必先去推翻那些已经跑得好好的系统。而对于全新的应用，确实可以从一开始就把业务定义组织起来，但真正上生产，仍然要经过测试、数据准备、权限配置和验收，一个都少不了。

说到底，一个可信的、小范围的业务闭环，比一天就能重构完整个 ERP这样的口号，要有说服力得多。

一个人、一万个 Agent，是分工问题，不是人数预测

我在之前的分享里提过一个设想：一个人，一万个 Agent。我想澄清，这既不是一个精确的预测，也不意味着所有企业从此都不再需要员工。

我真正想表达的是，当越来越多的执行工作可以被自动化地完成，人的职责，到底应该放在哪里？我自己的答案是，放在那些机器暂时接不住的地方——定义目标，确认规则，设置权限，处理例外，验收结果，以及，为这一切承担责任。

所以企业其实不必急着把员工都换成 Agent。但我觉得，现在是一个值得开始思考的时间点：在你的业务里，哪些部分已经被定义得足够清楚，清楚到可以被机器理解、执行，并且被检查？从那一部分开始，就够了。