我为什么在组建AI军团之后，开始建设领域知识体

我刚刚给AI军团补上了一套统一通讯标准。任务终于能够在Muse、专业Agent和审核Agent之间流转。但这次改造也让我意识到一个更大的问题：如果不同Agent对“客户是谁”“商机走到哪一步”“什么才算完成”的理解并不一致，那么协同越顺畅，错误传播得反而越快。这也是我对企业AI建设形成的新判断：

AI越多，企业越需要的不是更多工具，而是一套能够统一业务认知、组织任务协同并控制知识回写的运行系统。

过去，我先建设第二大脑，让AI记得住资料、规则和判断；再组建AI军团、统一通讯标准，让不同Agent分得清职责、接得住任务。

接下来要补上的，是领域知识体。它要让所有Agent站在同一张业务地图上，理解相同的客户、商机、报价、合同和订单，遵守相同的规则，并用相同的证据判断任务是否真正完成。只有完成这一步，AI才可能从一组会回答问题的工具，逐步变成能够参与业务、接受验收并沉淀组织能力的数字员工。

01 这次升级，改变了我对AI协同的判断

Muse加入AI军团，原本只是为了拓展CRM研究中的云端洞察、外部反证和规划能力。但新成员一进来，原有协作方式就出了问题：大家使用的通讯方式、任务状态和上下文版本并不一致。于是，我开始统一任务身份、业务场景、状态定义和结果入口。这解决了一个很现实的问题：一项任务由谁发起、谁接手、做到哪一步、最后回到哪里，终于可以被持续追踪。可当通讯链路真正连起来以后，另一个更深的问题出现了。同样是“报价完成”，一个Agent可能理解为报价文件已经生成，另一个Agent理解为成本和权限已经审核，还有一个Agent认为只有客户正式确认才算完成。它们都没有偷懒，也都可能严格执行了自己的任务。但因为业务定义不同，越高效的协同越可能产生越大的偏差。这让我意识到：

统一通讯解决的是任务能不能接力；统一认知解决的是大家做的是不是同一件事。

前者需要AI军团和运行底座，后者需要领域知识体。

02 AI能够穿过系统孤岛，也能让错误穿过所有孤岛

传统企业系统按照职能保存数据，真实业务却沿着价值流不断向前推进。客户需求会进入商机，商机形成方案和报价，报价进入合同，合同再进入订单、制造、交付和回款。 AI最有吸引力的地方，是它有机会跨过原来的系统边界，把散落在CRM、ERP、MES、WMS、文档和专家经验中的信息重新连接起来。但连接本身并不等于理解。如果最初匹配错了客户身份，AI可能读取错误的历史价格，形成错误的报价建议；建议进入报告和任务以后，又可能被写回知识库，成为下一轮AI继续工作的依据。一个局部错误由此获得了自动生成、自动传播和自我强化的能力。过去，错误可能停留在一张表、一个文件或者一个部门。现在，它可以在几分钟内穿过报告、任务、系统和知识库，并逐渐获得“企业知识”的外观。

过去的孤岛让错误难以流动；未经治理的AI，可能让错误高速穿过所有孤岛。

所以，我并不认为企业接入更多大模型、Copilot和Agent，就自然完成了AI转型。如果目标、责任、业务定义、验收证据和知识回写没有统一，企业只是把原来的系统孤岛升级成了新的能力孤岛。

03 回头看，我的建设路线其实只有两步

第二大脑、Agent、Skill、SQLite、任务机制和通讯链路，看起来像许多分散的工具项目。但它们最终都服务于两步建设。

第一步：先把AI组织成一支能够协同的队伍这一步解决三个问题：

记得住：资料、案例、规则和判断有统一出处，新任务不必每次从头介绍背景；
分得清：谁负责洞察，谁负责协调，谁负责执行，谁负责审核；
接得上：任务有人接手，过程可以追踪，结果带着证据返回原入口。

第二大脑解决“记得住”，AI军团解决“分得清”，通讯机制和运行底座解决“接得上”。Muse带来的这次组织升级，补上的正是第三部分。第二步：再让这支队伍理解并参与真实业务队伍能够协同，不代表它已经理解企业怎样运转。它还需要知道：

谁是同一个客户；
商机在哪个条件下才能进入下一阶段；
报价需要经过哪些成本、权限和交期审核；
合同承诺怎样进入订单和交付；
谁能够改变业务状态；
什么证据才代表任务真正完成。

这一层要解决的是“看得懂、守规则、做得完”。它对应的就是领域知识体，以及未来建立在知识体之上的数字员工。

先让AI能够一起工作，再让它们把同一项业务工作做好。

04 知识体，不是再建一个更大的知识库

我已经有Obsidian，也有轻量级SQLite，还有由不同Agent和Skill组成的AI军团。但这三者承担的责任并不相同。 Obsidian保存文档、案例、判断和来源；SQLite保存任务、状态和运行记录；企业业务系统保存客户、订单、库存、成本等真实数据。它们都是重要载体，却不会自动形成一套共同业务认知。领域知识体要做的，是把这些分散内容组织成一张可以共同使用的业务地图：

企业有哪些核心业务对象；
这些对象之间存在什么关系；
每个对象会经历哪些状态；
哪些规则决定状态能否变化；
哪些角色拥有读取、判断和修改权限；
哪些证据代表业务真正完成。

以客户为例，知识体不能只保存一份客户资料。它还要说明集团客户、签约主体、付款主体和最终使用者之间是什么关系；不同区域和法人怎样共享客户信息；一项商机、报价和合同分别由谁负责；哪些事实来自权威系统，哪些只是尚未验证的判断。当Muse、专业Agent和审核Agent再次处理同一客户时，它们读取的不只是几篇相关文档，而是同一套对象、关系、规则和证据。专业上，这类结构叫作Ontology，也就是领域本体。在我的建设路线里，我更愿意把它理解为一个可以持续生长的领域知识体：它不仅保存过去，还会在任务执行、事实核验和结果反馈中不断修正。

知识库帮助AI找到材料；领域知识体帮助AI理解材料之间的业务关系，并据此行动。

05 对制造企业数字化负责人，这解决的不是一个技术问题

我现在定义的产品方向，是一套面向制造企业CIO和数字化转型负责人的AI业务运行系统。它不以Agent数量作为结果，也不把生成一份文件视为任务完成。它要减少的，是企业对“人肉接口”的长期依赖。

过去，数字化负责人需要不断向不同系统、部门和AI解释背景；以后，Agent应该从共同业务上下文继续工作。最终要形成的，不是一个更复杂的个人知识库，也不是一群彼此独立的AI助手。而是一套能够把数据转化为知识、把知识带入任务、把任务结果重新沉淀为组织能力的运行系统。这也是我个人定位中“让转型沉淀为能力”的具体含义。

06 我现在走到哪里，下一步准备验证什么

目前，第二大脑、AI军团、职责分工和统一通讯机制已经形成初步雏形。 Muse与Codex之间完成了正常任务、重复事件和反向活跃会话的部分双向技术验证，能够区分消息送达、任务认领和最终结果返回。但这还不等于形成了稳定运行的数字组织。 Windows闲置状态下的自动检测和安全唤醒仍未完成稳定验收，长期无人干预、企业采用和业务收益也尚未得到证明。领域知识体同样还处在建设阶段。下一步，我不会一开始就试图描述整个企业，而会选择CRM、LTC或跨境业务中的具体场景，验证一条最小闭环：

Agent能否识别相同的业务对象；
能否依据共同规则完成任务；
能否把结果和证据返回原任务；
经过确认的新事实能否修正知识体；
下一次任务能否直接复用这些能力。

只有这条闭环真正跑通，领域知识体才不是一张新的架构图，数字员工也不只是一个新的概念。我关注的始终不是AI能不能写得更快、回答得更像专家。我更关心的是：制造企业在数字化转型和跨境出海过程中，怎样让AI真正理解业务、参与执行、接受验证，并把每一次实践转化为下一次可以复用的组织能力。这就是我接下来要继续完成的建设：让AI理解业务，让转型沉淀为能力。

Peter Tang｜制造业AI数字化转型 · 业务架构 · LTC · 跨境出海

———笔者邀请大家共同探索———

笔者这一次的Muse 5个亿token已经耗尽，请大家一起来使用Muse云端助理，探索生态共赢未来。

AI越多，企业越需要一套运行系统