本体不是知识库: 而是 AI 时代的内存系统

把动态本体看作AI时代的内存系统，是解决智能体落地难题的关键一步。它定义了智能体运行的世界，让记忆、规则和行动都有章可循。
核心内容：
1. **当前智能体框架的核心困境**：Harness等工具面临规则、记忆、多Agent协作等系统性问题。
2. **动态本体的核心定位**：从“知识库”转向“内存系统”，类比为定义对象、连接与生命周期的文件系统。
3. **系统的构成与动力**：由ObjectType、LinkType构成基础，Action、Function、Rule提供执行动力。

Harness 越多，越说明缺了一层

这两年，围绕让智能体在企业落地的项目越来越多。

有的叫 Harness，有的叫 Loop，有的叫 Agent 运行时，有的强调 Workflow、Memory 或 Multi-Agent。名字不同，工程问题很接近：让模型不要只回答问题，而是能规划、执行、观察、验证、重试。

但它们最后都会撞到同一个边界：

智能体到底运行在一个什么样的世界里

如果这个世界只是提示词、聊天历史、向量库、工具 schema 和临时 JSON 的拼接，系统很快会出现几个熟悉的问题：规则没有强制性，记忆没有生命周期，写回没有血缘，多 Agent 之间没有共享语义，企业业务逻辑散落在提示词和工具代码里。

所以我越来越倾向于把动态本体看成 AI 系统里的运行内存，而不是知识库。 具体而言，Harness 框架是一套脚手架，它用来控制大模型怎么跑。本体相当于一个业务世界的数字孪生，它决定了大模型跑在哪个世界里。

动态本体首先是一个面向内存的文件系统

工程师或者架构师在理解本体的时候，容易被“知识图谱”、“语义模型”这些词带偏。

这些词没有错，但不够准确。对一个要支撑 Agent 执行的系统来说，本体首先要回答的是：什么对象可以存在，怎么命名，怎么连接，怎么被读取，怎么被写入，怎么过期，怎么追溯。

这更像文件系统。

在这个类比里，ObjectType 类似文件类型和 inode schema。它定义系统里允许存在什么东西：约束、模式、决策记录、业务流程、反模式。这些不是 markdown 标签。它们决定一条记忆的字段、生命周期、可检索方式和治理规则。

LinkType 则类似文件系统里的链接关系，但语义更强。它不是“参见某某”的文本提示，而是可遍历、可审计、可治理的关系。

例如 derived_from 表示决策血缘，about_concepts 表示概念索引，cites_files 表示代码锚定，contradicts 表示矛盾，supersedes 表示替代，impacts 表示影响传播。 在上一篇文章里我专门处理过 derived_from：它不是一个好看的字段，而是一条检索边。DecisionRecord 进入 Manifest 后，系统可以沿这条边扩一跳，把支撑这个决策的约束和模式补回来。

这就是文件系统思维和知识库或者知识图谱思维的区别。

文件系统关心“这个对象是什么类型，和谁连接，谁能读，谁能写，何时失效，出了问题怎么修”。

Action、Function、Rule 构成动力层

如果只有 ObjectType 和 LinkType，本体仍然只是一个结构化存储系统。真正让它运行起来的，是 Action、Function 和 Rule。

Action 是受治理的写操作。它不是普通 tool calling。

普通工具调用只描述函数签名，比如“更新供应商状态”。它没有说明这个操作在业务世界里是否合法、是否需要审计、会影响哪些对象、失败时如何解释。本体里的 Action 不只是函数入口，而是带前置条件、规则、写回和血缘的受控操作。这里的关键不是格式，而是语义：Action 改变的是一个受约束的企业世界。

Function 则负责可计算的读路径。它可以基于对象和链接做聚合、推导、影响分析、风险计算。它不一定改变状态，但它定义了“系统如何理解当前世界”。

Rule 是边界。它决定什么操作能执行，什么写回能晋升，什么记忆必须保护，什么节点应该降级。

在前面几篇里，这些概念已经以不同名字出现过：VerifyGate 是规则执行，Promotion Gate 是写回晋升，Memory Prompt Builder 是读侧函数，GC dry-run 是生命周期规则，AgentMemoryScope 是读权限与预算规则。

所以，动态本体不是静态图。

ObjectType / LinkType 让世界有结构；Action / Function / Rule 让世界会运动。

我把这一层称为动力层。它回答的不是“世界是什么”，而是“世界如何合法地变化”。

Harness 和 Loop 是运行层，不是世界层

现在很多 Harness 、 Loop engineering 项目做得很扎实。

它们解决 plan、act、observe、verify、retry、tool routing、checkpoint、多 Agent 协作。这些能力是必要的。没有 Harness，Agent 就是一段会调用工具的自由文本生成器。但 Harness 不应该承载世界模型。

Harness 应该负责控制流：谁先跑，谁后跑，失败回哪一步，重试几次，什么时候中止，什么时候升级。

动态本体管世界：有哪些对象，哪些规则算数，哪些记忆能读，哪些结果能写回，什么经验能跨任务复用。

这个边界很重要。

规则放在 prompt 里，失败只能得到“模型觉得不对”。规则存在 ConstraintMemory 里，并且 VerifyGate 要求失败带 rule_id，系统才知道是哪条约束被违反。成功经验只在 chat log 里，下轮很难稳定复用；通过 Promotion Gate 晋升为 DecisionRecord 和 PatternMemory，下一轮才能通过 Manifest 读到。retry 细节混进共享记忆，长期内存会被噪声污染；Session Flush 清掉 EP 内临时态，只保留结构化结论，记忆层才不会越跑越脏。

一个复杂 Agent 系统出了问题，你必须能判断：是 Harness 路由错了，是本体规则错了，是 Manifest 拼错了，还是 Agent 输出错了。层次混在一起，排查成本会指数级上升，导致多智能体系统无法落地。

多智能体系统是应用层

多智能体经常被放在架构中心，我现在更愿意把它放在应用层。

企业里的多智能体可以有很多角色：采购、风控、财务、销售、运维、代码、测试。分工很重要，但它们不应该各自维护一套私有的世界模型。

稳定的多智能体协作，不来自“大家聊得更好”，而来自共享的对象、共享的规则、共享的动作。

采购 Agent 读取 Supplier、Contract、BusinessFlow。风控 Agent 读取 ConstraintMemory、AntiPattern、DecisionRecord。运维 Agent 读取 Incident、Runbook、PatternMemory。它们可以有不同 Manifest、权限和 token 预算，但底层世界应该是一套。

这也是为什么我不把 Memory 简化成“给每个 Agent 配一段长期记忆”。

长期记忆如果只属于某个 Agent，就会变成角色私有笔记。企业系统需要的是共享内存：对象一致、血缘一致、规则一致、写回一致。

多智能体之间当然需要协议，但协议不是根，根是共享本体。

本体自己也需要一套多智能体

我们说“多智能体运行在本体之上”，指的是业务多智能体。例如采购、风控、运维、编码这些 Agent，依托本体提供的内存层和动力层工作。

但本体本身的建设，也需要一套高度定制化的多智能体。

这类 Agent 不是普通业务 Agent。它们的任务不是处理某张订单或修某个 bug，而是生产和维护本体本身。

可以有 Object Modeling Agent 设计 ObjectType，Link Modeling Agent 设计 LinkType，Action Designer Agent 定义 Action，Function Engineer Agent 实现可计算读路径，Rule Engineer Agent 编写约束，Memory Curator Agent 清理记忆，Migration Agent 处理 schema 演进，Verifier Agent 检查本体变更是否破坏已有流程。

这些 Agent 的产物不只是代码，还包括 schema、link spec、action spec、function implementation、rule set、migration plan、demo EP 和 verification report。

换句话说，本体支撑多智能体，多智能体也反过来生产本体。

这件事在工程上很现实。企业本体不会一次建完。对象类型会拆分，链接类型会增加，Action 会调整，规则会迁移，旧记忆会失效。靠人手工维护全部变化，不现实；靠通用聊天 Agent 自动乱改，也不可靠。

更合理的方式，是让一组本体工程 Agent 在 Harness 约束下工作：提出变更，生成迁移，跑验证，经过 Promotion Gate 后再晋升。

这和业务 Agent 使用本体，是两条不同的线。

一条是应用线：Agent 使用本体。
一条是生产线：Agent 建设本体。

三层系统：记忆层、动力层、智能体层

把前面的内容收束一下，我更愿意把这套系统分成三层。

第一层是记忆层。

它由 ObjectType、LinkType 和对象实例构成。它负责保存企业世界的结构化状态，记录决策血缘，支持检索和注入，管理记忆生命周期。

第二层是动力层。

它由 Action、Function、Rule 构成。它负责受控写入、规则验证、状态迁移、影响传播、Promotion、GC 和 Health。

第三层是智能体应用层。

它由 Harness、Loop、多智能体和具体业务 Agent 构成。它负责任务拆解、角色协作、工具调用、计划执行、失败重试和人工升级。

三层分别回答三个问题：记忆层回答世界是什么；动力层回答世界如何合法变化；智能体层回答谁来执行任务。

这个划分并不新奇。传统软件也有类似分层：数据库、业务服务、应用层。区别在于，AI 系统里“世界状态”不能只是数据库表；它还需要能被 Agent 读取、压缩、注入、写回、追溯和治理。所以动态本体不是取代数据库，也不是取代 Harness。它是夹在企业状态和 Agent 执行之间的运行内存。

为什么企业 AI 更需要这一层

个人助理可以靠 chat history 活很久。企业系统不行。

企业系统的难点不是“模型不会说”，而是业务对象复杂、规则变化快、权限边界严格、决策必须可追溯、经验需要跨团队复用。这些要求用 prompt 很难长期维持。

ObjectType 处理对象复杂性，LinkType 处理关系复杂性，Rule 处理约束，Action 处理受控写入，Function 处理计算和推导。DecisionRecord 处理审计，PatternMemory 处理经验复用，GC / Health 处理过期和腐化，Manifest 处理多智能体读侧一致性。

这就是动态本体和普通 RAG 的差别。 RAG 只能解决“从资料里找相关片段”。动态本体解决的是“在受治理的企业世界里读、写、验证和演进”。

二者可以结合，但不能互相替代。

如果只做 RAG，Agent 可能知道很多材料，却不知道什么能改、什么不能改、改完要写回哪里、失败对应哪条规则。

如果只有 Harness，没有本体，Agent 可以跑得很勤奋，但每次都像在临时搭建的世界里工作。

企业 AI 的核心是稳定，可复现，可诊断等这些特性，必须让 Agent 运行在同一个可治理世界上。

回到本体自身

“本体”这个词容易被讲得很玄。从工程角度看，我更愿意拆开理解：先有“本”，再有“体”。

“本”是系统的稳定根基：对象、关系、规则、血统、动作、函数、状态。它决定企业世界如何被表达，如何被读取，如何被改变。

“体”是这些根基组织出来的运行形态：记忆层、动力层、Agent 应用层。

所以，基于“本”的内存管理系统，不是把更多内容塞给模型，而是为模型提供一个可读、可写、可验证、可演进的世界。

多智能体系统也不是凭空协作。它们要么运行在这个世界上，要么帮助建设这个世界。

这可能是很多 Harness / Loop 项目最终会走向的地方：执行循环越来越清楚之后，大家都会发现，真正难的是循环背后的世界状态层。

在下一个阶段，我可能会把重点转向代码锚定：当应用代码文件变化时，哪些规律应该标记？当测试结构重构时，哪个决策的血缘还可信？那会让本体内存进一步贴近真实工程仓库，从而去探索如何利用本体去动态生成软件。

不过在进入下一个阶段之前，我还是想把边界讲清楚：Harness 管循环，动态本体管世界，动力层管合法变化，多智能体管应用和本体生产。

如果不把他们各自的边界搞清楚，可能做出来的智能体系统还是个玩具，把架构和边界理清楚了，才有机会让系统长期发展。

登录查看剩余 70% 内容