当模型进入运行时：领域建模的位置转移与软件结构的重写

软件工程长期建立在一个稳定分工之上：领域建模用于描述，代码用于执行。但当系统行为开始由持续演化的 Agent 决策驱动时，这种分工正在失效。领域建模被迫进入运行时，并由此引入新的约束层——治理，软件的基本结构也随之发生重写。

软件被 Agent 重写：CLI 化的 SaaS，正在变成 AI 的“操作系统语言”

读完Stone与我的学生合写的那篇文章(链接如上)，感慨颇多，遂写下这篇随笔。

在相当长的一段时间里，软件工程默认了一件几乎不被质疑的事情：领域建模(DDD)是用来描述系统的，而系统是用来运行模型的。

这正是传统领域驱动设计的隐含前提。人通过抽象，将业务世界压缩为一组稳定的概念结构——实体、值对象、聚合——然后把这些结构交给程序执行。模型存在于设计阶段，它的价值在于“足够准确”，而不是“持续有效”。一旦进入运行时，真正发生作用的是代码，而不是模型本身。

这个分工在过去是有效的。因为系统的变化频率是可控的，模型可以滞后于现实，甚至可以是近似的。只要工程体系足够稳定，模型与真实世界之间的偏差，不会立即变成系统性问题，而是被测试、流程、以及人力逐步吸收。

问题并不出在建模能力上，而出在一个更底层的假设：世界变化的速度，低于领域建模被重写的成本。

这个假设正在失效。

当代码不再完全由人编写，而是由 Agent 持续生成与修改时，系统行为开始呈现出一种新的特征：它不再是一个固定程序的执行结果，而是一组动态决策过程的叠加。逻辑路径变得不稳定，状态边界开始模糊，系统不再“执行一次定义”，而是在运行中不断重构自身。

在这种结构下，“先建模，再执行”的顺序开始出现断裂。领域建模如果仍然停留在设计阶段，它就无法覆盖运行时的变化；而一旦无法覆盖，它就不再是系统的抽象，而只是对过去状态的一种记录。换句话说，模型开始失去约束力。

可以尝试用补丁修复这个问题：更频繁地更新模型、更精细的领域划分、更强的类型系统。但这些手段都会遇到同一个瓶颈——它们仍然假设模型是“在运行之外”的。只要这一点不变，领域建模就永远在追赶系统，而不是参与系统。

当这种追赶的成本高于系统自身的变化速度时，原有结构就不再是低效，而是失效。

于是，一个新的要求开始变得不可回避：领域建模必须进入运行时。

这不是一个渐进优化，而是位置的改变。一旦模型进入运行时，它就不再只是描述系统的语言，而成为系统本身的一部分。系统不再是“代码执行领域建模”，而是“LLM驱动代码生成与执行”。领域建模的状态，直接影响系统的行为；领域建模的变化，本身就是系统演化。

这也是为什么类似 Palantir 的 Ontology 看起来更像一层基础设施，而不是一个建模工具。它所做的事情，并不是帮助人更好地表达领域，而是维持一个持续存在的结构：现实世界的映射、系统当前的状态、以及对这些状态的操作能力，被放在同一个可计算的空间中。

在这个空间里，建模不再是一次性的行为，而是一种持续发生的过程。人可以修改模型，Agent 也可以修改模型；系统运行依赖模型，而模型又在运行中被重塑。模型从“定义”变成“介质”。

一旦模型成为运行时介质，另一个问题立刻浮现出来：谁来约束它的变化？

在传统结构中，这个问题并不突出。领域建模是由人设计的，变化是离散的、受控的。但当领域建模可以被多方持续修改时，它会迅速变成一个高度耦合的共享结构。不同 Agent 的行为、不同任务的需求，都会试图在模型上留下痕迹。如果没有约束，这种演化会在很短时间内走向混乱。

于是，“建模”之外，出现了一个新的层——治理。

这里的治理，并不是权限控制或流程审批，而是对模型演化路径的约束机制。它决定哪些修改是合法的，哪些状态是可接受的，哪些关系是必须保持一致的。换句话说，它定义了领域建模可以如何变化，而不仅仅是领域建模当前是什么。

当这一层出现时，领域建模的性质再次发生变化：它不再只是知识的表达，而成为系统行为的边界条件。系统可以生成代码、执行任务、改变状态，但所有这些行为，都必须在模型及其治理规则之内展开。

这时再回头看执行层，会发现它的地位正在发生转移。无论是代码生成框架、任务编排系统，还是各种形式的 Harness，本质上都在回答同一个问题：如何把一个意图转化为可执行过程。这一层当然仍然重要，但它开始呈现出明显的通用化趋势——不同系统之间的差异，越来越少体现在“怎么执行”，而越来越多体现在“执行什么，以及在什么约束下执行”。

当执行变成通用能力，差异就会向上移动。

真正难以替代的部分，开始集中在两个东西上：领域建模本身，以及对它的治理。

因为只有这一层，能够决定系统的连续性。原型阶段形成的结构，不再需要被翻译成另一套“生产代码”；它可以直接进入运行，被修改、被强化、被约束，最终演化为系统本身。开发与运行之间的断层被抹平，取而代之的是一个持续演化的过程。

这种连续性不是简单的效率提升，而是一种结构优势。它意味着系统不再需要通过“重写”来完成阶段切换，而是通过“演化”来积累能力。每一次修改，都发生在同一个模型空间中；每一次执行，都会反过来影响这个空间。

如果沿着这个方向继续推导，一个相当直接的结果会出现：软件的核心将不再是代码，也不是执行框架，而是一个持续运行的世界模型，以及对它的治理结构。代码成为实现细节，执行框架成为可替换组件，而领域建模及其演化路径，成为系统真正的边界与护城河。

在这样的结构里，“谁更会写代码”不再是决定性问题；真正关键的是，谁控制了那个领域建模，以及它如何被改变。

这不是工具层的演进，而是软件如何被定义的一次转移。