第 10 章 DDD、业务本体和 Agent 的关系

如果要给 Agent 的业务层找一个最接近的软件思想来源，那么最接近的其实是 DDD。

DDD 之所以重要，不是因为它提供了一堆术语，而是因为它提醒我们：

软件系统真正难的地方，不是代码本身，而是业务模型。

这一点放到 Agent 身上，会显得更加明显。

因为 Agent 表面上看是一个“会自然语言”的系统，容易让人误以为它可以直接跨越业务建模。 但现实恰恰相反。

语言能力越强，越需要边界。 否则系统很容易在不同业务上下文里发生语义漂移。

DDD 里最关键的几个思想，和 Agent 高度契合：

第一，统一语言。

Agent 不是自己发明业务词汇，而是应该和业务团队、系统设计者、数据结构使用同一套语言。

第二，边界上下文。

同一个词在不同业务域里可能不是同一个意思。 如果没有边界，Agent 很容易把相近词汇混成一套模糊语义。

第三，领域模型承载规则。

业务规则不应该只存在于人的脑子里，也不应该只散落在 prompt 里，而应该进入模型外部的系统结构。

第四，显式状态流转。

业务不是一堆静态事实，而是可推进、可中断、可回退的过程。 Agent 恰恰最依赖这种过程结构。

因此，如果用一句话总结 DDD 和 Agent 的关系，可以写成：

DDD 解决的是业务如何被严肃建模，
Agent 解决的是模型如何在被建模的业务世界里进行受控自治。

这个关系很重要。

它意味着，真正成熟的 Agent 架构，并不是“绕开业务建模”，而是“比传统系统更依赖业务建模”。

但这一章想再往前走一步。

仅仅说“DDD 对 Agent 很重要”还不够。 更关键的问题是：

DDD 到底解决了什么，
业务本体又补上了什么，
Agent 为什么会比传统软件更依赖这两层结构。

如果把这件事拆开看，可以得到一个很清晰的关系链：

• DDD 负责把业务世界建成团队可用、代码可落地的领域模型
• 业务本体负责把这套业务语义进一步形式化、共享化、可验证化
• Agent 则运行在这套模型之上，对对象、状态、事件、动作和约束进行动态决策

这三层不是替代关系，而是递进关系。

先看第一层，DDD 到底给了什么。

DDD 真正重要的，不是术语表，而是四件事：

• 统一语言
• 边界上下文
• 领域模型
• 一致性边界

Eric Evans 的 DDD 参考文档、Fowler 对 Ubiquitous Language 和 Bounded Context 的说明，以及 Microsoft 的一系列 DDD 工程文档，都在强调同一件事：

复杂业务不是先写系统，再补充业务解释；
而是先定义业务世界中的对象、规则、事件和边界，再让系统对齐它。

这对 Agent 的意义非常直接。

因为 Agent 天生倾向于跨语言、跨上下文、跨工具地自由联想。 这使它很强，但也意味着它更容易把不同上下文里的相近概念混成一团。

例如：

• customer 在客服上下文里是服务对象
• 在结算上下文里可能是应收责任主体
• 在营销上下文里又可能是潜客画像单元

如果没有 bounded context，Agent 看到的不是一个清晰对象，而是一堆共享词形但并不共享语义的词。

所以，DDD 给 Agent 的第一份礼物，不是“业务知识更多了”，而是：

业务语言终于被放进了有边界的世界里。

第二份礼物，是领域模型本身。

DDD 反复强调，真正的业务知识不应主要停留在 controller、application service、UI 或 prompt 里，而应进入 domain model。 Microsoft 的战术 DDD 文档、领域模型文档和领域验证文档都在说明：

• 实体不是纯数据容器
• 聚合要守住不变量
• 领域服务只处理不自然属于单个实体的行为
• 领域验证本质上是不变量维护
• 领域事件让状态变化显式可见

这对 Agent 来说非常关键。

因为一旦没有领域模型，团队就会天然把很多“本应属于业务内核的知识”塞到这些地方：

• prompt
• orchestration glue
• tool wrapper
• if/else 流程
• 人工经验

短期看，这样开发很快。 长期看，这会让 Agent 的每一次升级都变成语义漂移风险。

换句话说，DDD 给 Agent 的第二份礼物是：

把业务规则从语言层和流程胶水层，重新拉回到稳定的领域内核。

这时会出现一个更进一步的问题：

如果 DDD 已经这么重要，为什么还需要“业务本体”？

答案是，DDD 很强，但它主要解决的是“团队如何建模”和“代码如何对齐业务”。 而业务本体解决的是另一层问题：

• 如何把业务概念从具体实现中抽离出来
• 如何让不同系统、不同团队、不同代理共享同一套语义
• 如何把业务词汇与业务规则变成机器可处理、可验证、可交换的结构

这就是 Gruber、Noy & McGuinness、Enterprise Ontology、SBVR、OWL、OWL-S 这一整条脉络的意义。

它们共同说明：

DDD 把业务语言变成领域模型，
业务本体再把领域模型中的关键语义推进为可交换、可推理、可验证的语义层。

这不是纯学术补充，而是 Agent 时代非常现实的需求。

为什么？

因为传统软件很多时候只需要“同一团队内部理解一致”就足够了。 但 Agent 系统经常要求：

• 多个 agent 协同
• 多个系统接入
• 多个工具语义映射
• 多个团队共享业务概念
• 多种评测与治理系统读取同一业务定义

一旦进入这个层面，单靠代码里的领域对象名和团队口头共识就不够了。 你需要一层更显式的业务语义基础设施。

这也是为什么 SBVR 这类标准特别有价值。 它把 business vocabulary 和 business rules 往“可交换、可工具处理、可发现不一致”的方向推进。 OWL 则把这种业务语义推进成可被 reasoner 处理的逻辑对象。 OWL-S 又更进一步，展示了 agent 如何基于语义描述自动发现、调用、组合服务。

这几层合在一起，就能把第 10 章最核心的命题说清楚：

DDD 负责“把业务说清楚”，
业务本体负责“把业务语义形式化”，
Agent 负责“在这套被说清楚且被形式化的业务世界里行动”。

再往下看，为什么 Agent 比传统软件更依赖这种显式世界模型？

经典规划理论其实早就给出了答案。 STRIPS、PDDL、planning and acting 这些工作都在说明：

• 规划必须有世界状态表示
• 必须有动作模型
• 必须有目标表示
• 必须有约束和反馈

否则，系统无法稳定规划和重规划。

LLM Agent 时代的 ReAct、LLM+P、Generative Agents，本质上并没有推翻这一点。 它们只是把“显式世界模型”的需求，从传统规划重新带回到了语言模型系统里。

这会形成一个很重要的反差：

• 传统软件常把流程写死在显式代码分支里
• Agent 则需要在运行时根据目标、状态、工具反馈和环境变化决定下一步

也正因为如此，Agent 比传统软件更依赖：

• 对象模型
• 状态模型
• 动作语义
• 事件语义
• 不变量
• 边界

如果没有这些东西，Agent 的“自主性”就会迅速退化成“自由发挥”。

这一点和 artifact-centric BPM 的脉络也能很好地对上。

IBM 的 business artifact、GSM 生命周期、object-aware process management 以及 artifact-centric multi-agent systems 这条线，其实提供了一个特别好的桥：

• DDD 强调领域对象、聚合、事件和不变量
• artifact-centric 方法强调业务工件、生命周期、里程碑和条件推进
• Agent 系统则可以作为作用于这些业务工件生命周期的观察者、执行者和协作者

这非常重要。 因为它说明 Agent 最稳的落点，不是取代业务对象，而是围绕业务对象工作。

也就是说，Agent 不应该成为“业务本体本身”。 它更像是：

• 读业务对象
• 解释业务状态
• 触发领域命令
• 消费领域事件
• 在边界内协调流程

而不应越俎代庖，把业务规则直接塞进一层难以验证的 prompt 决策里。

Microsoft 的 DDD 文档里其实已经有非常明确的分层暗示：

• 应用层负责协调
• 领域层负责业务规则
• 领域模型负责不变量
• 领域事件负责表达业务变化

把这个分层翻译成 Agent 语言，几乎就会得到：

Agent orchestration 更像应用层，
领域模型和业务本体才是业务层。

这句话特别值得记住。 因为很多团队最容易犯的错误，就是把 Agent 当成“新的业务内核”。 结果是：

• 规则漂进 prompt
• 状态漂进 session memory
• 约束漂进工具描述
• 一致性边界漂进人工习惯

这样短期能跑，长期不可维护。

更成熟的方式应该是：

1. 先用 DDD 定义 bounded context、对象、聚合、不变量、事件
2. 在需要跨系统共享和推理的地方，用业务本体/语义层把关键概念形式化
3. 让 Agent 站在这套模型之上做协调、分析、补查、生成和局部自治
4. 把真正改变业务真相的动作，约束到领域命令、领域事件和聚合边界内

只有这样，Agent 才是在业务世界里受控自治，而不是在业务世界外面“聪明地猜”。

所以，本章最终想留下的结论，可以浓缩成三句话。

第一句：

DDD 不是 Agent 时代之前的旧工程方法，
而是 Agent 时代业务层最重要的稳态结构之一。

第二句：

业务本体不是替代 DDD，
而是把 DDD 的业务语义推进成跨系统、跨代理、可推理的共享语义层。

第三句：

Agent 不是业务模型的替身，
而是运行在业务模型和业务本体之上的自治执行者与协调者。

如果把这三句真正落实到系统里，那么 Agent 的业务层就不会再是“提示词里的一段行业介绍”，而会变成：

• 有边界的
• 有语言的
• 有对象的
• 有事件的
• 有约束的
• 可被治理的

这时，Agent 才真正进入工程意义上的业务世界。