从功能集合到能力系统:本体驱动的软件生成与对话式交互

未来软件的组织方式，正在从“功能集合”转向“能力系统”。软件不再是若干固定功能的集合，而是可生成、可编排、可验证的能力系统。但能被生成，不等于能接着演化：生成是一次性的，演化是长期的，后一道坎更难。要过这道坎，软件的组织方式就得变——不是把功能堆得更全，而是把层次分得更清楚。下文按五层展开：本体层、业务层、编排层、对话层、界面层，每层管一件事；FDE 与可验证，是演化能力的组织支撑。

一、总体形态：从功能集合到能力系统

功能不再提前穷举，而是在本体约束下按需生成，再交给智能体在运行时编排调用。变的不是界面，是软件的组织方式。

组织方式的改变，落在结构上就是五层分工。本体层定义边界，业务层把能力生成出来、固化成企业的物理模型，编排层在运行时组合调用，对话层承接人的意图，界面层保留传统操作，直接调用业务层。

这五层里，本体层和业务层偏稳，编排层偏活，对话层和界面层偏入口。稳和活不是对立的：业务层固化得越清楚，编排层越敢在边界内灵活调度。

二、本体层：企业运行逻辑的语义描述，需要持续完善

本体层是整套系统的核心——业务层生成得对不对，编排层调度得顺不顺，最后都要回到本体上对账。它把企业运行中的概念、关系、规则形式化：有哪些实体，实体之间怎么关联，哪些规则必须成立，哪些边界不能越过。落在工程上，实例化出来就是“本体模型”，给人和机器一套一致的、能校验的语义框架。

本体层描述的是后台业务逻辑，让大模型理解业务。界面逻辑属于操作层面，不在本体范围内。它不只服务数据治理，更是企业级数据建模和系统架构的逻辑基石。程序可以按需生成，数据仍是底层实体。

本体层不是一次成型，需要不断完善。需求变化推动本体演化，本体演化反过来暴露需求里没言明的约束。“需求定死了本体也就定了”并不成立——性能、安全、合规、成本这类非功能需求很难被本体完全吸收，得在生成约束里单独表达。落地时也不追求全域严密的一张网，跑得通的是划了边界的核心本体：圈内概念、关系、规则明确，圈外允许弱结构化接入，用一部分推理能力换本体跟着业务迭代的能力。

拿模型驱动架构作个参照：它早就试过从模型生成代码，失在工具链形式化严谨性不够、转换脚本很难验证；本体驱动把生成定义为从领域本体经平台特定本体到源代码的多阶段确定性变换，并对结构保持给出可验证条件——生成本身成为能被约束、被检查的事。

落到开发流程上，本体层就是大模型编程中的那套规范。先把本体建起来，再让模型照着它生成代码——先建本体，再编程，规范先行，系统的稳定才有根。

本体层是语义的单一来源，但不是生成约束的唯一来源。生成约束不是本体一家说了算：本体管语义，架构规范管结构，非功能需求管性能、安全、合规与成本，运行时约束管并发、权限、审计。本体层说清语义，业务层把它落成企业实际运转的物理模型——前者是描述，后者是执行。

三、业务层：企业的物理模型，执行本体层

业务层是企业的物理模型，也是本体层的执行模型，不是另一套语义。它管的是企业实际怎么运转：哪些能力必须存在，哪些流程按什么顺序走，哪些规则在什么条件下生效。

这层的关键是固化。搞清楚的规律固化成程序，承载可验证的业务行为。业务逻辑不再全部由人提前穷举，而是在本体约束下按需生成。代码生成的输入至少包括四类。本体模型来自本体层，是语义的单一来源与语义约束，载体是领域本体与平台特定本体；架构约束来自架构治理与系统设计，管依赖方向、分层边界和结构不变量，载体是宪章式架构规范、接口契约与架构决策记录；非功能需求来自业务、合规与运行要求，管性能、安全、合规与成本，载体是需求文档、SLA、合规条款与成本预算；运行时约束来自运行环境与交付要求，管运行边界与交付条件，载体是调度并发配置、权限模型、审计要求与状态持久化。

界面是派生视图，不是代码的源头。业务层生成的产物，既供编排层调用，也供界面层派生展示。

本体在生成中占多大分量，可分三档：规范在前、代码仍由人维护，是当下主流；规范与代码共同演进，两边都算权威，是过渡形态；规范为唯一来源、代码完全交给生成，是方向，不是今天的标准动作。

业务层和大模型怎么分工，不是一次定死的：固化逻辑撞上本体没覆盖的新场景，暂时退回给大模型试探。哪些逻辑已经足够稳定，由本体中的规则、约束与阈值，结合回归测试和架构不变量共同判定——本体给语义依据，测试给经验证据。

业务层的可维护性：不变量与两道闸门

业务层求固化，但固化不等于僵化。它要能被验证、被维护。依赖方向、分层边界写成机器可执行的不变量；每轮改动先做确定性扫描；命中问题就生成一次小规模重构；行为测试与结构测试两道闸门验收；阈值逐步收紧。

阈值收紧不是自动发生的。谁定阈值、多久收紧一次、收紧后生成失败率上升怎么办，仍是治理决策，需要人拍板。但一旦定下来，检查就是机器能反复执行的，不靠谁的经验足。

本体提供那套不变量，检查才知道该查哪儿。业务层架构跟不上，生成得越多越难收场。

四、编排层：灵活易变，但要在权限边界内

编排层由智能体负责，特点是灵活易变。业务层回答“有哪些能力、规则是什么”，编排层回答“这一次先做什么、后做什么、调用哪个能力、遇到例外怎么办”——它承载的是人的判断和调度，不是把确定性逻辑再写一遍。但这种判断不是自由发挥，要在权限边界内、按可审计的轨道走。

智能体沿对话入口、编程生成、工作执行、个人代理几个方向并行发展，逐步形成分层协同的体系，彼此叠加、嵌套、互相调用，不是线性替代。比较成型的做法是两类：一类由编排者管任务分解与分配、整合上下文，避免智能体之间行为冲突，业界常称 orchestrator–worker；另一类先做整体规划再分步执行，规划、协调、执行分开承担，常称 plan-and-execute。这种层级解决的是单智能体可靠性随步骤衰减的问题。编排层的关键不在有几个智能体，而在谁在什么权限边界内做什么决策。

编排层只管判断，不管执行。它决定下一步做什么，但不替代业务层的确定性执行，也不替代运行时对过程的承载。运行时负责进程调度、并发、等待、故障恢复、状态持久化、权限控制和审计留存，它不在五层分工里，是承载这几层的执行底座。对话是主入口，但对话本身不执行操作；真正干活的是运行时，真正决定怎么干的是编排层。

编排层和业务层的边界要清楚。能在业务层固化的，不要留在编排层反复试探；编排层试出来的稳定路径，下沉回业务层固化。仍属判断调度的，留在编排层，做成可复用的编排模式；语义层面的，回写本体层。这个下沉和回写的过程，正是 FDE 和可验证机制发挥作用的地方。

五、对话层与界面层：主入口和传统通道

对话层是主入口。人的意图先到编排层，由编排层判断怎么拆、调用哪些业务能力，再向业务层发令执行。对话不绕过编排层，也不绕过权限和审计。交互方式从“以应用为中心”转向“以用户意图为中心”：系统不再要求人逐个 App 切换操作，而是识别意图后自主拆解并完成多步骤任务。

界面层不会消失。传统的界面和人机交互保留下来。GUI、API、多模态都还在，界面从唯一入口退为并列通道之一。但和对话层不同，界面层不走编排层，直接到业务层：传统界面的操作是确定的，用户知道自己要点哪个按钮、调哪个能力，意图不需要拆解，直接调用业务层的能力即可。

界面即便还要生成，也是由“本体+角色+任务+场景+设计约束”共同派生出来的视图；已经存在的传统界面，继续承担熟悉、可控、可审计的操作通道。退位的是“界面作为操作主体”的位置，上来的是意图理解、确认与兜底的责任——机器自动得越多，人的确认越省不掉。

所以是双入口：对话承接模糊、多步骤的意图，先交编排层拆解，再到业务层执行；界面承接明确、高频的操作，直接调用业务层。两者不是替代关系，而是分工关系——走哪条路，取决于意图需不需要拆。界面层的存在，也让确认与兜底有了落地位置。

双入口之外，还有更轻的一档：有些简易、易变的需求，将会由用户直接用大模型生成，用不着这套五层结构，软件的使用范围进一步扩大。

六、FDE 与可验证：演化能力的组织支撑

FDE（Forward Deployed Engineer，现场交付工程师）驻扎客户现场，填上标准产品与真实需求之间的差距，对业务成果负责。在这套五层结构里，FDE 的作用不是“驻场支持”，而是支撑演化。每交付一次，都要留下沉淀：现场规则、例外和约束回写本体层；现场验证有效的稳定路径，下沉到业务层固化成确定性逻辑，此后不轻易改变；仍属判断调度的，留在编排层，形成可复用的编排模式。否则只是挂着产品名头的驻场外包。

为什么下沉这件事，偏偏由 FDE 来做？因为编排层最灵活，最容易在真实场景里长出标准产品没有的路径。这些路径如果只留在某个项目、某个人手里，系统就演化不动。FDE 的职责，是把它们识别出来、沉淀下去：该固化的固化，该回写的回写，该保留为编排模式的保留。本体层需要不断完善，业务层需要不断固化，编排层需要不断沉淀，FDE 是这三件事在组织上的抓手。

FDE 管的是人的沉淀；可验证管的是机器的检查，贯穿始终。它管两件事：功能对不对，结构还长不长。功能验证靠行为测试，结构验证靠架构不变量扫描与结构测试。功能测试通过、结构性检查却没通过，是生成式编码里一类典型失败：功能对了，系统却已经改不动。所以可验证不只是交付前的验收动作，而是每一轮生成、每一次编排调整、每一条 FDE 沉淀都要过的闸门。

结论：该盯的不是生成能力，是演化能力

前一道坎靠模型能力，后一道坎靠系统结构。生成是一次性的：模型跑完，代码落地，这件事就结束了。持续演化是另一回事。它要求每一轮产出都被理解、被检查，还得能被下一轮改动接上。落到具体，就是四件事：每一轮产出有共同语义依据，结构不变量可扫描，行为与结构两道测试可验收，改动影响可分析。

这条路走得通走不通，不取决于模型能不能把代码写出来，而取决于写出来的东西能不能持续被理解和修改。五层结构的分工，本质上就是为演化服务的：本体层提供共同语义依据，业务层提供可验证的物理模型和固化实现，编排层吸收不确定性，对话层与界面层承接人的意图与确认，FDE 把现场经验沉淀回来，可验证守住每一道闸门。

本体的用处也因此是两层的：先约束第一次生成，再给后续每次改动一套共同的语义依据，改哪儿、影响什么，说得清楚。