天润聚粮全自动数智化企业的最新进展

天润聚粮 enterprise-management-system-1.0

业务侧智能体全员报到：天润聚粮全自动数智化企业的最新进展

业务侧智能体完工、1 月 1 日至 5 月 26 日连续运行、5 月 17 日总纲包系统封闭、pair1000 应用测试收尾

这是一篇面向读者的系统进展说明：重点不是介绍某个页面，也不是解释 AI 编程方法，而是说明天润聚粮如何从企业管理系统推进为基于 AI 和语义图的全自动运行数智化企业。

30万+ 后端 TypeScript 代码行

8万+ 前端 Vue / JS / TS 代码行

48 现役智能体

12+2 业务侧智能体与外部交易对手

22aa32cf 当前 full/full/full 图真值

119/119 source oracle 通过

70/70 pair1000 shards 收尾

144/144 + 244/244 飞书协同与 task/v2 账本

图1｜系统整体架构：业务底座、智能体框架、图真值、外部协同和证据账本

图1｜系统整体架构：业务底座、智能体框架、图真值、外部协同和证据账本

01

这不只是一篇“续集”，而是一次系统进展说明

前两篇文章介绍过天润聚粮从业务系统走向语义图、从单点 AI 能力走向企业级智能体的基本方向。本文只保留这个背景，不继续写成前文续篇，也不把重点放在“我们怎么看 AI”。

本文要介绍的是项目自身的最新进展：天润聚粮 enterprise-management-system-1.0 已经从传统企业管理系统，推进为一个基于 AI 和本体论语义图的全自动运行数智化企业。

这里的“全自动运行”不是指脱离治理、脱离边界的盲目自动化，而是指采购、销售、库存、财务、客户、供应商、智能体、任务、协同、证据、测试和发布门禁被组织到同一套系统里，能够按业务日期连续推进、产生任务、执行动作、留下回执，并接受语义图和应用测试的校验。

截至 2026 年 5 月底，几个进展已经形成系统级信号：业务侧智能体全部完工；模拟运行已经从 2026 年 1 月 1 日追到 5 月 25 日，当前推进到 5 月 26 日；5 月 17 日总纲包完成史诗级系统封闭；pair1000 应用测试与数据验证进入系统收尾；22aa32cf 图真值、source oracle、mapping audit 和外部协同账本共同构成了最新的运行证据。

02

系统当前画像：从企业管理软件到全自动数智化企业

图2｜统一智能体框架：业务、需求、执行、测试和空间治理共用运行契约

图2｜统一智能体框架：业务、需求、执行、测试和空间治理共用运行契约

天润聚粮最早不是从一个聊天框开始，而是从企业经营对象开始：采购、销售、库存、财务、客户、供应商、产品、用户权限、审批、任务和协同。这些对象先在传统业务系统里稳定下来，再被语义图、智能体和证据系统接管。

目前系统已经具备相当明确的工程规模：后端 TypeScript 代码超过 30 万行，前端 Vue/JS/TS 代码超过 8 万行，后端 .ts 文件超过 1000 个，前端页面和脚本超过 100 个。当前图真值版本为 22aa32cf-a071-4775-85f8-d288b9a2edf9，图构建口径是 storageMode=full、sliceMode=full、buildMode=full，versionSeq=365。

更关键的是，系统不是只有业务表和页面，而是形成了六层协同结构。

第一层是传统业务底座：采购、销售、库存、财务、客户、供应商、产品、权限等核心域。

第二层是应用入口和企业管家：前端页面、Agent Console、ObjectSet 工作台、架构治理、链式查询和 Ask 指令入口。

第三层是罗汉堂统一智能体框架：message_bus、agent registry、execution contract、timer/runtime、evidence + receipts。

第四层是业务侧智能体：12 个 business agent、2 个 external counterparty，以及围绕早会、经营决策、客户、供应商和业务动作的协同机制。

第五层是语义图与图真值：graph_node、graph_edge、graph_source_ref、graph_version、business registry projection、source oracle、mapping audit。

第六层是质量与发布门禁：pair1000、same-version mismatch audit、release audit、ActionLog、delivery log、task/v2 ledger。

这六层接起来，才是“全自动数智化企业”的基础形态：业务不是被 AI 问答解释，而是被系统对象、语义关系、智能体动作和证据账本共同运行。

03

业务侧智能体全部完工：企业角色进入系统运行目录

图3｜全自动数智化企业按业务日期连续运行的闭环

图3｜全自动数智化企业按业务日期连续运行的闭环

最新进展里，业务侧智能体全部完工是一个关键分水岭。

这件事的意义不在于“多了几个 bot”，而在于企业经营角色被系统化了。业务侧智能体被纳入统一 registry、execution contract、message_bus、timer/runtime 和 evidence receipts，不再是散落脚本，也不是临时提示词角色。

现在的业务侧运行范围包括 12 个 business agent 和 2 个 external counterparty。它们对应的不是抽象能力，而是企业运行里的角色：早会编排、采购判断、销售判断、库存判断、财务判断、客户协同、供应商协同、业务动作包装、外部交易对手模拟等。

这意味着系统已经可以把“今天企业应该发生什么”拆成一组可调度、可执行、可回执、可审计的角色动作。例如：早会智能体按业务日期触发；采购侧根据库存和供应商条件形成建议；销售侧根据客户、产品和库存形成动作；外部客户和供应商进入协同模拟；动作通过 wrapper 限定边界；结果进入 ActionLog、delivery log 或 task/v2 账本。

业务侧智能体完工以后，项目的核心问题也随之变化。此前的问题是：这些企业角色能不能被定义出来、接入统一框架、形成闭环？现在的问题是：这些角色每天运行时，能不能持续稳定地产生业务事实、协同任务和可复盘证据？

这正是 1 月 1 日到 5 月 26 日连续模拟运行的价值所在。

04

从 1 月 1 日跑到 5 月 26 日：系统开始按业务日期自动运转

天润聚粮现在不是在补几条测试数据，而是在按业务日期运行一个企业。

当前模拟运行已经从 2026 年 1 月 1 日追到 5 月 25 日，并进入 5 月 26 日。已完成的协同补发包括飞书 144/144 sent、task/v2 244/244 created。更重要的是，这些数字背后不是孤立消息，而是连续业务日期下的运行账本。

对一个全自动数智化企业来说，时间非常重要。一个企业不是静态对象集合，而是每天都在发生采购、销售、库存变化、客户触达、供应商协同、任务派发、异常处理和财务影响。

因此，连续模拟运行至少验证了四类能力。

第一，业务日期能不能驱动系统状态向前滚动。系统不是只回答“库存是多少”，而是要知道 1 月 1 日、5 月 25 日、5 月 26 日分别处在什么业务上下文里。

第二，业务侧智能体能不能在连续日期中触发。早会、决策、协同、动作、回执，都要跟随业务日期推进，而不是临时问答触发。

第三，外部协同能不能进入账本。飞书消息、task/v2 任务、delivery_id、IM uuid、client_token 幂等，不只是通知渠道，而是运行事实的一部分。

第四，运行结果能不能反哺图真值和测试。业务动作产生的数据、证据和异常，最终要进入 source oracle、pair1000、release audit 或总纲包复盘。

所以，5 月 26 日模拟不是“又跑了一天”，而是系统从历史补齐走向连续运行的标志。企业的自动化不在单次调用里，而在每天都能向前推进的运行链条里。

05

5 月 17 日总纲包：一次史诗级系统封闭

图4｜图真值与质量门禁闭环：source oracle、pair1000、release audit 分层校验

图4｜图真值与质量门禁：source oracle、pair1000、release audit 分层校验

5 月 17 日总纲包是这轮工程里最重要的阶段性成果之一。它不是一个“写计划”的文档，也不是为了管理 AI 编程流程而存在的辅助材料，而是把天润聚粮这套系统的关键工程面收成了一个可执行、可验证、可追踪的总包。

它完成的核心工作，是把业务侧智能体、图真值、外部协同、pair1000、空间治理、发布门禁、证据产物和运行账本统一到同一套系统进度里。

在业务侧，它确认业务智能体不再只是愿景，而是进入 registry、contract、message_bus、timer/runtime 和 action wrapper 管理。

在语义图侧，它要求 graphVersionId 不能手写冒充，必须由真实重建、pin、projection 和 source oracle 证据支撑。

在外部协同侧，它把飞书、task/v2、delivery_id、IM uuid、client_token 幂等和 DB audit 纳入同一个运行账本。

在测试侧，它把 pair1000、same-version mismatch audit、mapping audit、source oracle release-grade 放到发布前质量门禁里。

在执行侧，它把 Captain、IntegrationManager、ImplementationEngineer、TestEngineer、resident、space-governor 等角色的边界收清，避免局部完成冒充系统完成。

因此，5 月 17 日总纲包的价值不是“防止 AI 漂移”这么泛，而是它把天润聚粮从多条工程线推进为一个系统级闭环：业务能跑、图能锚、协同能记账、测试能收口、发布能裁决、证据能复盘。

这也是为什么它可以被称为史诗级完成。它完成的不是某个页面、某个接口、某个 agent，而是把一个全自动数智化企业需要的关键系统面同时合拢。

06

pair1000：用应用测试案例确认系统能不能承受规模化验证

图5｜本体论语义图如何把企业对象变成可执行网络

图5｜本体论语义图如何把企业对象变成可执行网络

pair1000 不是一个抽象质量口号，而是一组面向应用场景、图真值和发布门禁的数据化测试。

当前 pair1000 的关键结果是 70/70 shards quality complete。结合 source oracle 119/119、mapping audit violations=0、avgConfidence=0.825，可以确认系统至少通过了三类验证。

第一，来源证据可以覆盖。source oracle 119/119 表明 release-grade 来源引用已经完整通过，系统不是靠口头解释图真值，而是能把节点、边、对象和判断追到证据来源。

第二，对象映射没有明显违规。mapping audit violations=0 说明业务对象、图节点、projection 和 registry 之间的映射没有暴露出当前门禁可识别的违规项。

第三，分片质量已经收尾。70/70 shards quality complete 表明 pair1000 所覆盖的应用测试分片全部完成质量检查，系统不是只通过少量样例，而是在更大规模、更分片化的测试集中完成收口。

pair1000 能确认的东西非常具体：同一图版本下的对象关系是否稳定；业务 registry projection 是否能支撑应用查询；source_ref 是否能把回答追到来源；图真值是否能承接业务侧智能体需要的对象上下文；发布前是否存在 same-version mismatch 风险。

这对天润聚粮很关键。因为全自动运行系统最危险的不是“完全不能跑”，而是“局部看起来能跑”。一个采购建议能生成，不代表采购、库存、供应商和任务账本都一致；一个智能体动作能执行，不代表它引用的对象、证据和权限都正确；一个图查询能返回，不代表同版本分片都稳定。

pair1000 的作用，就是把这种局部可用拉到系统级应用测试里验证。

07

本体论语义图：让企业对象可以被机器执行

图6｜外部协同闭环：飞书、task/v2、delivery_id 与业务侧智能体

图6｜外部协同闭环：飞书、task/v2、delivery_id 与业务侧智能体

本体论语义图在天润聚粮里的价值，不是“把系统画成图”，也不是写几段关于图谱作用的说明，而是把企业对象变成机器可以理解、查询、执行和审计的结构。

举一个采购场景。系统里不是只有一张采购订单表，而是采购订单、供应商、产品、库存批次、入库记录、付款条件、业务日期、执行动作、任务回执和证据来源共同构成一个对象网络。采购智能体要做判断时，不能只读一段自然语言说明，而要沿着语义图确认：当前库存是否低于阈值、供应商是否可用、产品是否匹配、订单是否已经创建、动作是否允许、证据是否属于当前 graphVersionId。

再看销售场景。销售动作不是“给客户发一条消息”这么简单。它涉及客户、产品、库存、价格、应收、交付、外部协同和任务账本。语义图把这些对象连起来，销售智能体才能知道：哪个客户可以触达，哪个产品可以销售，库存是否支撑，是否需要创建 task/v2，飞书消息是否已经发送，delivery_id 是否会重复。

库存场景也类似。库存不是一个数字，而是采购入库、销售出库、产品批次、仓库位置、业务日期和异常事件共同作用的结果。语义图让库存变化可以被追溯到业务动作，也让业务动作反过来受库存约束。

财务场景则体现证据价值。应收、应付、付款、回款、订单和客户供应商关系必须能回到 source_ref、evidencePaths 和 graphVersionId。否则，智能体即使能生成财务解释，也无法进入系统级审计。

因此，本体论语义图在项目里的作用可以概括为四个可执行层面：统一对象、统一关系、统一证据、统一边界。

统一对象，是让采购订单、销售订单、库存、客户、供应商、产品、Agent、Contract、Receipt、Task 都有稳定身份。

统一关系，是让采购影响库存、库存约束销售、销售形成应收、智能体动作连接任务和回执。

统一证据，是让 source_ref、evidencePaths、graphVersionId、delivery_id 把结论绑定到来源。

统一边界，是让 RBAC、action wrapper、pair1000、release audit 决定哪些动作可以执行，哪些结果可以发布。

这才是本体论语义图对全自动数智化企业的价值：智能体不是凭提示词“猜企业”，而是在同一张对象、关系、证据和权限图里运行企业。

08

外部协同闭环：飞书和 task/v2 成为企业运行事实

图7｜数据库 ER 图：传统业务对象与运行证据共同落表

图7｜数据库 ER 图：传统业务对象与运行证据共同落表

全自动数智化企业不能只在数据库里自转。真实企业每天都会发生外部协同：客户沟通、供应商确认、内部任务派发、异常提醒、审批推动、交付回执。

天润聚粮把飞书和 task/v2 放进运行账本，而不是把它们当成外围通知。飞书 144/144 sent、task/v2 244/244 created、delivery_id 幂等、IM uuid 稳定派生、client_token 控制重复创建，这些机制共同保证外部协同能够作为系统事实被追踪。

这意味着：一个业务日期上的协同消息，不只是“发出去一条消息”，而是会产生可查询的 delivery_id；一个任务不是临时文本，而是 task/v2 ledger 中的对象；一次外部交易对手模拟，不只是对话，而是和客户、供应商、业务动作、证据链发生连接。

因此，外部协同闭环的价值在于把企业运行从“系统内部状态”扩展到“系统—人—外部交易对手—任务平台”的连续事实链。

09

从系统图看全自动运行闭环

系统图中最重要的不是图本身，而是它呈现出的运行闭环。

前端、企业管家、Agent Console 和 ObjectSet 工作台负责把人、业务对象和智能体入口连接起来。

NestJS 后端、PostgreSQL、Redis 和业务域服务承接采购、销售、库存、财务、客户、供应商等传统业务事实。

罗汉堂统一智能体框架负责把经营、需求、执行、测试、空间治理和外部协同纳入同一套 agent registry 和 execution contract。

图真值和本体论语义图负责把业务对象、智能体角色、证据来源和质量门禁锚定到同一版本。

pair1000、source oracle、mapping audit 和 release audit 负责决定系统结果能否进入发布和长期使用。

这套闭环表达的是：企业每天产生业务事件，业务事件触发智能体，智能体创建任务和协同，协同产生回执，回执进入证据账本，证据再回到语义图和测试门禁。

这才是全自动数智化企业的基本运行方式。

10

当前阶段的定位：正在运行的全自动数智化企业

“运训”可以描述系统建设过程中的测试和验证，但它不能作为天润聚粮的最终定位。更准确的定位是：基于 AI 和语义图的全自动运行数智化企业。

这套系统的核心不是训练 AI，也不是展示 AI，而是让企业运行本身自动化、结构化、证据化、可审计化。

它要解决的问题不是“AI 能不能回答一个问题”，而是“企业能不能在系统里每天自动推进”：业务日期向前走，采购销售库存财务跟着变化，客户和供应商进入协同，任务和回执进入账本，语义图持续校验对象关系，测试和发布门禁持续约束系统结果。

因此，天润聚粮现在的价值不在单个功能点，而在整体运行形态：它已经具备业务系统、语义图、业务侧智能体、外部协同、应用测试和证据治理共同组成的全自动数智化企业骨架。

11

结语：企业 AI 的边界在系统运行能力里

企业 AI 的关键不在聊天框里，也不只在模型参数里，而在企业能不能把自身对象、关系、流程、证据、权限、测试和协同组织成一个可运行系统。

天润聚粮这一轮进展，正把这个问题推到工程层面：业务侧智能体全部完工，连续模拟推进到 5 月 26 日，5 月 17 日总纲包完成系统级封闭，pair1000 应用测试收尾，22aa32cf 图真值和 source oracle 把对象与证据锚住，飞书和 task/v2 把外部协同纳入运行账本。

这不是在证明 AI 会替人聊天。

它在证明：一个企业可以把自己改造成由 AI 和语义图共同驱动、能够自动运行、自动协同、自动留痕、自动验证的数智化企业。

一句话收束：天润聚粮正在证明，企业可以被改造成由 AI 和语义图共同驱动、能够自动运行、自动协同、自动留痕、自动验证的数智化企业。