一、怎么设计 Agent，答案要从业务里找

ERP、OA、CRM、PLM、MES……一家企业可能已经部署了不少系统，但员工仍然需要做表、问人、拉群、核对，再凭经验判断下一步该做什么。

今天，这些工作中的一部分开始被表达为 Agent 需求：自动跟踪订单、判断物料齐套、分析变更影响、协调跨部门任务。于是，讨论很快进入“怎么设计 Agent”：需要哪些工具，如何拆分任务，怎样组织多个 Agent 协作。

暂且排除为了花掉 AI 预算而寻找场景的项目，“怎么设计 Agent”的答案，需要先从这些需求的业务来源里找。 业务究竟需要什么？现有系统已经承载了什么？剩下的部分，为什么还在靠人完成？把这些问题拆清楚，才有依据判断 Agent 应该承担哪些工作，以及哪些需求可以用其他方式解决。

二、业务本身包含什么？

一家制造企业，要把客户要求转化为能够交付的产品。销售、技术、采购、生产、交付等环节承担不同功能，人员、资金、设备和管理机制支撑它们运行。订单进度、物料齐套、变更影响，都产生于这些环节及其相互依赖。

以一次技术变更为例。客户要求将一批产品中的元件从 A 型换成 B 型。旧元件可能已经采购，部分产品可能已经装配；新元件的采购周期和返工所需的产能，又会影响原来的交付安排。

要处理这件事，企业需要掌握多方面的内容。

首先是对象、关系和状态：哪些合同和产品受到影响，采用哪个版本的技术方案，物料已经采购多少、分配给谁，产品生产到了哪一步。只知道“仓库里有多少”，还不能判断“这个项目能用多少”。客户经营同样需要关联客户、商机、合同和服务记录，才能判断一次投诉是否影响正在推进的续约；零售则需要区分商品在不同门店的库存、在途和预留数量，才能判断哪里真正缺货。业务判断依赖具体对象之间的关系，以及它们当前的状态。

其次是目标、职责与能力：客户要求必须满足到什么程度，交期是否可以协商，新增成本由谁承担；技术、采购、生产和销售分别负责什么，谁对整个变更闭环负责，现有资源是否具备返工能力。

还需要明确活动、规则和决策：哪些评估可以并行，哪些工作必须等待确认，旧版本何时停止使用；哪些技术条件不能突破，谁有权批准额外支出；各个方案分别增加多少成本、影响哪些交付，最终如何选择。

这些内容共同决定业务怎样运行。同样的描述方式既适用于整个企业，也适用于其中的部门、团队和业务环节。它们各自有目标与责任，又通过共享对象、资源和工作交接联系起来。

三、现有系统覆盖了什么，哪些还在靠人？

ERP 可以管理采购、库存和财务，PLM 可以管理产品结构与技术版本，MES 可以记录生产执行，OA 可以承载审批流转。它们也可能提供规则校验、计划计算和分析能力。企业并不是从零开始数字化。

问题出在：各部分已经进入系统，不代表它们之间的业务逻辑也得到了完整承载。

技术系统里更新了 BOM，采购订单是否需要调整？库存中的旧元件对应哪些项目？生产现场哪些任务必须停下来？OA 中的变更审批通过之后，谁负责确认各系统和现场都已经采用新版本？

接口传递了数据，也未必回答了这些问题。“可以使用”“已经完成”“需要变更”分别是什么意思，需要结合对象关系、业务规则和责任才能确定。

这些没有被系统承载的部分，今天往往由人补上。

有人用 Excel 维护跨系统的对应关系；有人在群里询问最新进展；有人记得某种材料在什么条件下可以替代；有人知道出了问题该找谁；还有人综合成本、交期和客户关系，决定怎样处理。

人既在补录事实、连接信息、执行既定规则，也在处理冲突、不确定性和真正需要取舍的决策。 它们在日常工作中混在一起，看起来都是“系统之外的人工工作”，性质却并不相同。

这也解释了为什么系统已经很多，需求依然不断出现。数字世界对业务的承载仍有缺口，业务本身又在持续变化：产品调整、职责重分、规则更新、客户提出新要求，都可能让原来的覆盖再次变得不完整。

四、这些人工工作，都需要交给 Agent 吗？

当大模型能够阅读文档、理解消息、调用工具之后，人们自然会想到：能不能加一个 Agent，把这些人工工作接过去？

可以探索。但在此之前，值得把这包工作拆开。

例如，销售团队希望“让 Agent 自动跟进客户”，拆开后可能发现：客户当前处于什么阶段、由谁负责、什么条件下应该跟进，都没有被明确记录。这部分定义补齐后，提醒和任务派发就可以通过普通工作流完成；如何理解客户的异议、采取什么沟通策略，则是进一步的判断问题。

零售企业希望“让 Agent 自动补货”，背后需要的是商品、门店、库存、在途、促销计划之间的完整关联。有了这些基础，常规补货可以通过规则和预测模型计算；突发缺货时如何在门店之间分配有限库存，则涉及经营目标和约束下的选择。

制造企业面对物料延期，需要决定是加价采购、采用替代料，还是调整交期。这涉及方案生成、约束检查和价值取舍。部分判断可以用明确规则或优化算法完成，部分需要 Agent 协助分析，也可能需要人作出最终决定。

决策同样需要继续拆解：必要的事实是否齐全，约束是否明确，评价标准是否存在？这些基础缺失时，所谓“需要智能判断”，可能还混着大量信息补全和业务定义工作。

因此，被表达为 Agent 需求的工作，并不必然需要以 Agent 的方式实现。 应先识别其中哪些是对象、状态、关系和规则没有进入系统，哪些是计算能力不足，哪些确实涉及复杂决策，再选择相应的实现方法。

五、把需求放回业务与数字孪生之间

这也回到了我在《企业数字化的终局，是业务的数字孪生》中讨论的方向：数字世界应当逐步承载业务如何运行，让人、Agent 和传统系统围绕同一套对象、事实与规则接续工作。

数字孪生需要包含什么，依据就在业务本身。它既要承载日常记录与流转，也要为计算、决策、行动和反馈提供共同环境。建设可以从有限范围开始，逐步补齐其中缺失的内容与联系。

无论最后形成的是数字化、报表、工作流还是 Agent 需求，它们都可以放回同一个问题中理解：业务所需要的能力，与现有数字孪生的承载之间，还差什么？

下一篇继续展开：如何把这些 gap 识别出来，转化为有明确业务依据的产品需求。