当Agent开始读DSL,软件就不再是流程了

当入口从功能变成意图，软件的形状开始改变。

你有没有遇到过这种情况：系统提示"支付接口调用完成"，但账单并没有结清；流程走到了最后一步，业务目标却还没达成。

过去我们习惯把软件理解成一条条流程：用户点开功能，按顺序填表，系统按预定路径执行。流程走完，事情就算办完——严格说，传统系统也有对账、复核和异常补偿来兜底结果，只是完成标准常常隐式地散落在流程之外，要等出了问题才被检查。现在，一种新的软件形态正在出现：用户不再需要知道系统有哪些功能、先点哪里，而是直接说出要什么："把本月已到期、没有争议的账单处理完，超过一万元的先让我确认。"

软件正在从"人操作功能、按流程完成任务"，转向"人表达目标、系统组织能力完成任务"。两种模式会长期共存，变化最大的是编排和交互层。这是一个个人判断，不是已经确定的行业结论。

01 软件正在换一种方式工作

这个转变不是某个按钮的变化，而是五个层面一起动。

第一，入口从功能变成意图。今天用户需要知道系统有什么功能、先点哪里、再填什么；目标驱动软件接受的是目标本身，同时需要理解范围、约束、授权和完成标准。页面仍然存在，但更多用于查看证据、处理例外和作出决定。

第二，完整流程拆成稳定能力与动态决策。"查账""付款""撤销"这些能力仍要可靠实现，Agent 负责选择和协调，能力本身负责兑现合同。标准流程不会消失，它成为成本更低、经过验证的优先执行方案，遇到例外再交给 Agent。

第三，业务状态从"当前走到哪一步"，扩展为"知道什么、缺什么、已经证明什么"。传统流程用节点位置代表进度，目标执行需要的是：已确认的事实与来源、已执行动作及其结果、尚未解决的冲突和依赖、达成目标所需的证据。

第四，开发工作重心改变。从编写大量操作路径、设计页面表单，转向设计意图表达、确认和例外处理、验证业务结果是否成立、管理策略与证据版本。权限、事务、幂等、状态和可观测性会更重要，因为调用方不再总是一个行为固定的程序。

第五，确定性集中在承诺和责任边界。探索信息、比较方案可以允许多种路径；扣款、签约、记账、权限变更，需要明确授权和严格执行。

这些变化看起来分散，其实指向同一个问题：软件要表达的东西变了。过去我们表达"怎么做"——页面、流程、按钮；现在要表达"要什么、凭什么算完成"——意图、能力、状态、证据。任何需要被机器理解和校验的表达，都需要一种语言。DSL 不是什么好玩的建模工具，而是软件把这几样新东西写下来的方式。所以接下来要讲的，不是 DSL 语法怎么演进，而是它正在从"描述流程的语言"变成"描述目标与证据的语言"。

02 关于 DSL，两种常见理解都不够

谈到 DSL（领域特定语言），一种常见说法是：它只是更高级的流程描述，把业务规则写成一段段可执行的文本，本质上还是在描述"怎么做"。另一种说法正好相反：Agent 时代来了，模型什么都能理解，DSL 会消失，让模型自由发挥就行。

第一种理解解释了 DSL 的过去，第二种理解赌的是 DSL 的消失。但它们都漏掉了最关键的变量——DSL 的消费方正在改变。

过去，一份 DSL 的读者是编译器：你写好步骤，编译器照做，一步错，全盘错。后来，DSL 的读者是控制器：你描述期望状态，控制器负责收敛到那个状态，SQL、Terraform、Kubernetes 都是这样。而现在，DSL 的读者里加入了 Agent——一个会理解、会犹豫、会判断的消费方。

一旦 Agent 成为读者，DSL 就不再只是"被执行"，而是"被理解、被校验"。理解靠模型，校验靠确定性引擎——两者共享同一套语义合同，只是各读各的投影：引擎读取完整规则，模型读取受控切片。这正是 DSL 发展的分水岭。

03 DSL 的三代演进

从描述步骤，到定义完成——DSL 走过的不只是语法演进。

先说明一点：这不是严格的技术世代。命令式和声明式今天仍然大量存在，也不会消失。把它看成三种并存的分析框架更准确——只是当执行路径变得更灵活时，完成标准必须走到台前，变得显式、可检查。

第一代，命令式：描述"怎么做"。每一步都写清楚，被编译器解释执行。它的特点是确定、可预期，但也脆弱——一步错，全盘错，改一次流程要动一整条链路。

第二代，声明式：描述"期望状态"。你不用写步骤，只需要声明目标状态，控制器负责收敛：SQL 声明结果集，Terraform 声明基础设施，Kubernetes 声明部署状态。代价是新问题——状态漂移：现实和声明之间，总是悄悄偏离。

第三代，意图与证据式：描述"目标、约束和完成标准"。它的核心不再是"要什么状态"，而是"什么算完成、拿什么证明完成"。

这一代的失败表现也变得不同：动作执行完了，但业务目标没有达成。一个接口调用成功，不等于一笔账结清；一个流程走完，不等于客户问题解决。传统系统不是没有结果校验——恰恰相反，对账、复核、异常补偿都长在流程之外，靠人来补。意图驱动做的，是把"完成标准"写进语言本身，让它每一步都可检查。

最根本的转折只有一个：消费方加入了 Agent。DSL 从"被执行"变成"被理解和被校验"——理解交给模型，校验交给确定性引擎。两者共享同一套语义合同：引擎读取完整规则，模型读取受控投影，既保持一致，也避免把整套规则反复塞进上下文。

04 第三代之后：DSL 开始分层，证据成为新物种

当 DSL 进入意图与证据的形态，一份 DSL 不再是一整块流程描述，而会自然长成一个五层家族，每一层变更频率不同，消费方也不同：

契约层，定义能力接口、参数、幂等和事务边界。它最慢，变化最少，由编译器和 Agent 共同消费。

对象层，定义业务对象、状态断言和对象间关系。它变化慢，承载"业务状态"。

规则层，承载策略、授权、路由。它中速变化，支持热更新。

编排层，表达意图、目标、约束和组合方式。它动态变化，主要由 Agent 消费，决定"这次怎么组织能力"。

证据层，定义完成标准、证明链和重放方式。它随目标变化，回答"凭什么算完成"。

五层各司其职，版本需要成套保存：契约层最慢、证据层最快，一套版本固定下来，历史重放才成为可能。

其中最值得注意的新物种是证据 DSL。传统软件里，完成是一个布尔值：接口返回成功，任务就结束了。第三代软件里，完成是一组可验证的断言——"账单已结清"不是调用一次支付接口，而是需要收款回执、账本记录、对账结果三者构成一条证据链。

证据是有时效的：尽调结论会因为规则更新而失效，财务数据会因为财报重述而作废。所以证据层还要回答两个问题：这份证据的有效期是什么？它失效之后，需要重新验证什么？

证据还有一个边界：模型的判断不能自行充当证明。Agent 说"我认为已完成"，不算完成，完成必须落到可核查的记录上。历史重放也不是把旧结论直接搬回来——它要重新验证已有记录，确认当时的事实、规则和判定仍然成立，避免把"曾经验证过"误当成"现在仍然有效"，更不能因此再次提交、付款或发送通知。记录版本是这一切的基础：一次判定发生时，当时的事实、规则和判定结果要成套保存，重放才讲得清"凭什么"。

同时，确定性会集中在承诺和责任边界：扣款、签约、记账、权限变更需要强约束；探索、比较、整理可以宽松。路径稳定、高频、责任重的事，确定性程序仍然更好；Agent 应该用在变化和判断真实存在的地方。

05 这不是说流程会消失

需要说清楚边界：目标驱动有成本，推理耗时、行为波动、排障困难。如果一件事路径稳定、频繁执行，固定流程依然是更便宜、更可靠的选择。

所以更准确的说法是：软件要能判断什么时候按既定方案执行，什么时候需要重新规划。标准流程降级为"成本更低、经过验证的优先方案"，遇到例外再交给 Agent。完整的流程不会消失，它只是从唯一路径，变成了众多可选项里默认的那一个。

这也是为什么真正值得追问的问题不是"怎样把更多业务放进 DSL"，而是：哪些东西必须提前编排，哪些东西只需定义能力和约束、允许运行时选择？

06 对做软件的人，这意味着什么

如果接受这个判断，落地不用从大系统开始。挑一个边界清楚的例子，做最小四件套：用"把本月已到期、没有争议的账单处理完，超过一万元的先确认"这类意图作为入口；用一个业务对象保存状态，不是用页面位置；用两个可信能力执行动作——查账、付款；再用一组证据判断完成——收款回执、账本记录、对账结果。

然后做一件朴素但重要的事：对比固定流程，看人工处理量减少了多少。证据层最值得先做，因为它直接改变"完成"的定义。

举一个开户场景的最小例子。系统查询企业信息，已经拿到法人姓名，但识别到还缺联系电话，于是只追问电话这一项。客户补充并确认后，业务服务保存并读回，证明这位人员的联系方式已经满足要求，才进入下一项。客户选择"稍后补充"，系统就保留这个缺口，继续推进其他可办理事项；到了最终提交，仍然会检查这项义务是否已满足。Agent 可以灵活决定先问什么、怎么问，但系统必须清楚知道：什么已经成立、什么还缺、凭什么进入下一步——这正是这篇文章想说的核心。

我越来越倾向于一个更完整的表述：以目标组织工作，以业务对象保存状态，以可信能力执行动作，以证据判断完成。页面、流程、代码和 Agent 都服务于这套结构，各自承担适合的职责。

软件从"按流程走完"，走向"对目标负责"。而 DSL 作为这套结构的书写方式，也终于从描述步骤的语言，变成了定义完成的语言。

真正值得思考的问题是：当"完成"需要被证明，我们的系统准备好回答"凭什么"了吗？