AI驱动的Agent系统正在重塑软件的基本结构，领域建模不再局限于设计阶段，而是必须融入运行时——这不仅仅是技术层面的升级，更是软件工程范式的根本性转变。

先划重点：今天想探讨三个核心问题——第一，传统的分工模式为何不再适用？第二，Agent系统究竟带来了哪些新变化？第三，领域建模如何迁移到运行时，具体该如何操作？

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

读完Stone与学生的合著文章（链接同上），感触颇深，故写下这篇随笔进行分享。

长久以来，软件工程默认了一个几乎无人质疑的假设：领域建模（DDD）用于描述系统，而系统则用于运行模型。换句话说，人们先通过抽象，将业务世界压缩成一套稳定的概念——实体、值对象、聚合——然后把这些结构交给程序去执行。模型的生命周期停留在设计阶段，其价值在于“足够准确”，而非“持续有效”。一旦进入运行时，真正发挥作用的是代码，而模型本身则退居一旁。

过去，这种分工之所以可行，是因为系统的变化频率是可控的。模型可以滞后一步，甚至可以只是一个近似值。只要工程体系足够稳定，模型与现实之间的偏差不会立即引发问题，而是通过测试、流程和人力被逐步消化。

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

这个假设正在被打破。

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

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

有人可能会想通过打补丁来解决：更频繁地更新模型，更精细地划分领域，用更强的类型系统死磕。但这些手段都会撞上同一个天花板——它们依然假设模型是“运行之外”的东西。只要这个前提不变，领域建模就永远在追着系统跑，而不是参与系统本身。

当追赶的成本超过系统自身变化的速度时，原有的结构就不只是低效，而是彻底失效。

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

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

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

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

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

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

于是，在“建模”旁边，出现了一个新层次——治理。

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

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

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

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

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

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

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

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

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

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