驾驭工程之外：从 "岗位" 到 "组织" 的智能化系统架构

从提示工程、上下文工程到驾驭工程、循环工程，AI 工程范式一路狂飙，“Agent = Model + Harness”几乎成为智能化落地的标准答案。但当智能体真正走进企业，把“让一个智能体可靠地跑起来”当作全部，可能恰是最大的狭隘。未来的智能化系统，是智能体、代码、知识、人、组织乃至物理环境深度耦合的复杂系统；它的架构，需要在神经符号融合之上，补齐组件、接口、质量、异常与自省的系统工程纪律。本文借“经营一家企业”的类比，回答一个问题：驾驭工程之外，智能化系统架构还缺什么。

近一年来，AI 圈几乎成了“工程范式”迭代最快的造词现场。2023 年，大家还在钻研提示工程（Prompt Engineering），琢磨如何把一句指令说得更巧妙；2024 到 2025 年，上下文工程（Context Engineering）登场，注意力转向如何在正确的时刻，把正确的信息放到模型眼前；进入 2026 年，驾驭工程（Harness Engineering）声名鹊起，“Agent = Model + Harness”成为被反复引用的公式，工具、权限、沙箱、状态管理被一股脑装进智能体的“外壳”；紧随其后，循环工程（Loop Engineering）又把执行、评价、反馈、改进连成一个自动运转的闭环。再往后，Graph Engineering、Governance Engineering、Agentic DevOps……新名词仍在不断涌现，仿佛只要再发明一个“XX 工程”，智能体系统的可靠性问题就能迎刃而解。

与这股工程热相伴的，是一种更激进的乐观：“软件正在被吞噬”“中间层被压扁”“未来上头一个智能体、底下一个数据库就够了”。

我并不怀疑这些工程范式的积极意义。恰恰相反，从提示工程到驾驭工程、循环工程，记录的是 AI 从“耍嘴皮子”到“动手做事”、从“信任模型”到“信任系统”的真实进步——人们终于意识到，大模型的能力并不会自动等于可靠的业务结果，必须用工程的脚手架把它框住。今年 2 月，我在《Agent 狂欢与 Palantir 爆红背后：智能化软件正在“凤凰涅槃”》这篇文章中里也曾判断，软件不会消亡，而会在神经符号融合中经历一场“解构再重构”的重生。

大半年过去，Agent 生态继续狂飙，驾驭工程和循环工程几乎成了智能化落地的“标准答案”。但越是如此，我越想提醒一种新的狭隘：如果把这两条工程线，当作智能化技术在企业等严肃场景落地的全部，可能就太狭隘了。 驾驭工程和循环工程的坐标系里，默认的中心始终是智能体；而一家企业、一个复杂系统真正关心的问题，远比“如何让一个智能体可靠地跑起来”要大得多。

那么，驾驭工程、循环工程与未来的智能化软件系统架构之间，究竟是什么关系？这要从一个朴素的类比说起——智能体在系统中扮演的，其实不是“人”，而是“岗位”。

要理解驾驭工程和循环工程的位置，需要先完成一次视角的升维：今天我们谈论的智能化系统，早已不是纯粹的软件。

当大模型智能体大量进入企业，它所做的事情，远不止在屏幕背后生成几段文字、调用几个接口。它会接入真实的业务数据、操作各类软件系统、与不同岗位的人协作，甚至驱动硬件设备、触发现实世界里不可逆的动作。这样一个系统，边界同时覆盖了软件与硬件、人与组织，乃至社会和物理环境。相应地，我们要设计的也不再是传统意义上的“软件架构”，而更接近一种“系统架构”。

有意思的是，“架构”这个词在系统工程的语境里，本来就有比软件丰富得多的含义。一家企业会谈组织架构、业务架构，谈岗位如何设置、权责如何划分、流程如何穿越不同部门。这些看似与代码无关的管理学语言，恰恰是理解智能化系统的一把钥匙。

很多人愿意把智能体想象成企业里的一个“人”，甚至是一个不知疲倦、无所不能的“超级员工”。但在我看来，更准确的类比不是“人”，而是“岗位”。

岗位与具体的人有什么不同？一个岗位，本质上是一组去人格化的规定：它有明确的职责范围、被授予的权限、与上下游协作的接口、需要达成的考核标准，以及一套沉淀下来的标准作业流程（SOP）。人可以来填充这个岗位，也可能因为离职、调岗而离开，但岗位还在，职责还在。企业可以根据需要设立、合并、拆分乃至撤销一个岗位，而不必关心此刻坐在这个位置上的究竟是谁。

这与智能体的处境高度吻合。我们称之为一个“智能体”的东西，真正稳定的内核，其实是它被赋予的目标、约束、可调用的工具与权限、对外的接口契约，以及完成任务的验收标准；至于背后由哪个模型、哪个版本来“任职”，反而是可以替换的——就像同一个岗位上换了一位新人，职责和流程并不因此改变。这也是为什么今天智能体背后的模型可以不断升级、甚至从一家厂商迁移到另一家，而它所承担的业务职能依然能够延续。

顺着这个类比，会得到一个常常被忽视、却至关重要的推论：智能体的边界，应当由岗位的职责与授权来定义，而不是由模型的能力来定义。

AI圈的惯性思维是“以模型为中心”：模型能力强，就多派给它一些任务；模型做不到，就想办法补提示词、补上下文。但企业设计岗位的逻辑恰好相反——它先想清楚“这个岗位该做什么、不该做什么、能调动什么、出了问题谁负责”，再去找合适的人来胜任。把这套逻辑搬到智能化系统上，工程设问就从“模型能做什么”，翻转成了“这个岗位被要求、被授权做什么”。前者的边界随模型能力漂移，后者的边界由业务和组织锚定。看似只是语序之差，背后却是两种完全不同的设计哲学。

有了“岗位”这个坐标，驾驭工程和循环工程的位置就清楚了：它们本质上都是围绕“岗位”构建的，而且是岗位之内的功夫。

驾驭工程做的是什么？它为一个岗位配齐作业所需的工具箱，划定权限与行为边界，设置好操作规范和质量检查点——这很像一位员工拿到的那套 SOP、工具柜、审批权限和 checklist。循环工程则更进一步，它让这个岗位具备“计划—执行—自检—复盘—沉淀”的闭环：遇到问题能反思重试，做完一件事能复盘总结，把成功的做法和踩过的坑沉淀为下一次可复用的经验——这对应的是一位尽责员工，乃至一个班组在反复实践中积累手艺的过程。

换句话说，驾驭工程和循环工程解决的，是“一个岗位如何把交到手上的活可靠地干好”。它们是智能化系统中扎实而重要的部分，但无论这套功夫做得多纯熟，所覆盖的始终是一个个岗位、一条条作业闭环——是组织意义上的“点”与“线”。

然而，一家成功的企业，从来不是若干优秀岗位的简单相加。在具体岗位的作业流程之上，还有一整套岗位自身无法决定的东西：岗位如何设立、向谁汇报的组织架构，端到端业务如何穿越众多岗位的业务架构，跨岗位统一遵守的制度、内控与审计的治理体系，以及资金、物料、设备、数据这些资源底座。它们共同构成了企业这个“体”。个体的兢兢业业，是在这个“体”之内发挥作用；没有这个“体”，再强的个体也难以稳定地成就整体。

驾驭工程和循环工程之于智能化系统，恰如岗位作业法之于一家企业——它能让一个智能体值得被使用，却还不足以让一个由众多智能体、代码、人和资源组成的整体值得被信任。这，正是我认为它们“重要、但不是全部”的第一层原因。

如果说“岗位”让我们看清了驾驭工程和循环工程的边界，那么接下来要拆解的，是当下最流行、也最具误导性的一种想象——“上头一个智能体、底下一个数据库，中间那一整层都可以不要了”。

这种想象并非毫无来由。以 SaaS 为代表的企业软件，乍看确实像一层“业务翻译器”：前端把业务数据翻译成用户看得懂的界面，后端把业务请求翻译成 SQL 去操作数据库，人则在界面与流程之间来回搬运信息。于是一个顺理成章的推论是：当大模型和智能体成为一个“超级翻译器”，能够直接在自然语言意图与数据库操作之间往返，中间那层软件便失去了存在的理由。“中间层被压扁”“软件被吞噬”的说法，大抵都源于此。

但这套“翻译”叙事，只看到了软件最表层的形态，却没有看到中间层真正承载的职责。

把一家企业的系统摊开来看，智能体负责“想”、数据库负责“存”，而把“想”与“存”可靠地连接起来、并对业务结果负责的，正是中间层。它承担着六类无法被上下两端吸收的职责。

一是业务逻辑与不变量。 企业运转有大量必须被严格遵守的规则：账务上的守恒关系、业务对象之间的级联约束、指标的计算口径、行业的合规要求。这些规则，既不是数据库 schema 所能完整表达的——数据库能管参照完整性，却管不了跨越众多表和业务语义的复杂规律；也不能交给一个概率性智能体去临场发挥——它可以参考规则，却不应成为规则的最终裁决者。

二是跨资源的事务与一致性。 一个业务动作往往要同时改动多个资源、多个系统：下单要同时扣减库存、锁定额度、生成单据。这中间涉及事务边界、并发控制、幂等处理，以及失败时的补偿。数据库能保证单库之内的 ACID，而一旦动作跨越服务和系统边界，一致性就必须由应用层的事务编排与补偿机制来维系。

三是状态机与流程编排。 订单、工单、审批、合同，每一类业务对象都有自己的生命周期：在什么状态下能做什么动作、状态之间如何迁移，都有明确规定。这些状态机与流程，是业务稳定推进的骨架。

四是权限与安全的执行点。 企业权限远不止“某人能看哪些数据行”，更关键的是功能权限与操作授权：谁能发起一笔付款、谁能批准一次变更、哪些动作必须经过复核。这些策略需要在系统中有明确的执行点，并留下不可篡改的审计记录，而不能仅仅依赖智能体“自觉”。

五是系统集成与防腐适配。 企业真实 IT 环境，是众多年代各异的遗留系统、SaaS、数据源和设备的集合，中间层负责对接系统、转换协议、隔离差异，形成“防腐层”。今天 MCP 这类协议确实让系统“接得上来”，但连接标准化只是第一步——接入之后语义是否一致、结果是否可靠、异常如何处理，仍要靠中间层保证。

六是可靠性工程。 熔断、限流、重试、降级、故障隔离、看门狗与超时控制——这套分布式系统几十年沉淀下来的机制，决定了系统在局部出错时，能否把问题限制在局部，而不引发连锁崩溃。

把这六类职责归拢起来，结论其实很朴素：数据库回答“数据如何被正确地存储”，智能体回答“开放情境下该怎么做”，而中间层回答“业务如何被一致、可靠、可审计地做成”。 最后这一项，正是企业需要一套复杂系统，而不是“一个聪明人加一屋子档案”的根本原因。

讲到这里，有必要做一个关键区分：软件的“形态”与软件的“职责”，并不是一回事。

会被压扁、会被重构的，是软件的形态——那些以表单、CRUD、固定流程为中心，需要人一步步点击、来回搬运信息的 SaaS 外壳，这部分确实会被智能体的自然语言交互和自主执行大幅替代。但不会随之消亡的，是软件的职责——对一致性、可靠性、可审计性的保障，对资源、状态和不变量的管理。智能体改变的，只是这些职责由谁触发、如何组合，并没有取消它们；恰恰相反，当系统里多了一个会“自信地犯错”（fail-confident，而非传统程序那样在出错时快速抛出异常）、其错误还会沿长链路级联放大的组件时，这些职责不是变轻，而是变得空前沉重。

也正因如此，代码并没有消失，而是从“台前”退到了“幕后”：它不再以“人直接操作的界面逻辑”出现，而是化身为智能体脚下的确定性底座、身边的护栏，以及与智能体协作的共生体。这里我想再强调一次那个判断——智能体能够取代的，是“人操作软件”这件事；它取代不了的，是“软件约束业务”这件事。

这其实并不是什么全新的智慧。那些在高风险环境中持续保持可靠的组织，早就在用同样的逻辑行事，而且从不把成功寄托在“个体足够优秀、永远不犯错”上。

最典型的是航空业。今天民航的安全记录，并不来自“只招天才飞行员”，而是来自一份份标准操作清单、机组之间的交叉检查，以及自动化告警与标准程序。飞行员当然优秀，但托底的，是一套把人、流程、自动化和复核编织在一起的系统。

丰田生产方式则提供了另两件著名的武器。一是“安灯绳”（andon）：流水线上任何一名工人发现异常，都可以立刻拉绳叫停产线，不让带缺陷的产品继续流向下游。二是“防错”（poka-yoke）：通过简单的装置和设计，让错误在物理上根本无法发生——装反了就放不进去，漏了一步就无法进入下一环节。医疗领域同样如此，一份看似简单的手术安全清单，要求团队在关键节点逐项确认，就能显著降低术后并发症。

这些做法表面各异，内核却高度一致：它们都默认“人会疲劳、会疏忽、会犯错”，并把这一假设作为设计起点；然后用一道道防线，把错误限制在局部、及时发现、阻止它向下游传递。 系统追求的从来不是“个体永不失误”，而是“个体的失误不演变为系统事故”。

这套逻辑完全可以平移到智能化系统：智能体的一次错误输出，就像流水线上的一个缺陷，它要穿过类型校验、业务规则、事务一致性、权限沙箱、测试验证、熔断隔离、人工审批这一道道防线，才可能最终演变为一次业务事故。每道防线都可能有自己的漏洞，但只要防线足够多、漏洞彼此错开，错误就很难贯穿到底。

这正是为“中间层”正名的意义：它不是要被浪潮冲刷掉的多余之物，而是系统可信的主体；它的价值，恰恰体现在“当智能体不可避免地犯错时，系统依然能够稳稳站住”。

为中间层正名之后，如果再追问一步——在未来的智能化系统里，智能体、代码、知识究竟各居什么位置？我们就触到了这套架构最核心的设计问题。

在驾驭工程和循环工程的默认图景里，三者其实并不平等。站在舞台中央的，永远是智能体；代码和知识是围绕它、供它差遣的配件。代码的典型身份是“工具”——智能体在需要时调用一个函数、一段脚本；或是通过 hook 挂载的局部检查规则，在动作前后做一次拦截与校验。知识的典型身份则是“上下文”——在智能体需要时被检索出来、塞进提示词的片段。它们当然有用，但都是下位的、依附的：工具等待被调用，规则等待被触发，知识等待被检索，而决定何时调用、触发、检索的，是智能体。

这正是我认为驾驭工程和循环工程“不够”的深层原因：它们在起点上，就把代码和知识放在了从属位置，而没有把二者当作与智能体平等的、架构级的组成部分。

而在我所设想的智能化系统架构里，智能体、代码、知识应当被一同“升格”为三个并列的一阶实体（first-class entity）。所谓一阶实体，是说它们都拥有独立的结构、独立的生命周期和独立的设计价值，彼此之间不是主从，而是协作。

借用前面的企业类比，可以给三者各一个角色，也看清各自不可替代的质地。

智能体，是“任职者”。 它承担系统中需要感知、理解、规划、判断、协商乃至临场创造的部分，尤其擅长处理开放、模糊、没有预设答案的情境与例外。它的行为天然带有概率性和情境依赖性——这既是它灵活、能应对意外的来源，也是它不确定的来源。

代码，是“制度机器”。 它承担确定性的执行：事务的提交与回滚、不变量的强制、资源的调度、状态的流转、权限的落实。它不随情境摇摆，同样的输入给出同样的结果，可重复、可验证。企业里那些“无论谁来做都必须如此”的部分，由这台机器保证。

知识，是“规章与本体”。 它承载系统共享的意义：业务对象是什么、彼此关系如何、口径如何定义、机理如何约束、经验沉淀为何。它回答“是什么、为什么、以什么口径”，既为智能体提供理解世界的框架，也为代码提供规则的来源。

读过《Agent 狂欢与 Palantir 爆红背后：智能化软件正在“凤凰涅槃”》这篇文章的朋友会发现，那篇文章里我讲的是神经与符号的融合；这里的三元，正是对那个二元框架的细化。

为什么要把“知识”从“符号”里单独拎出来？因为代码和知识虽同属符号一侧，承担的东西却不同：代码是规则的“可执行形态”，回答“怎么做、必须怎样”；知识是规则的“可理解形态”，回答“是什么、为什么、口径是什么”。 同一条业务规则，写进本体是知识，编译成校验逻辑是代码——前者可以被人讨论、推理、修订，后者负责在运行时把它稳稳执行。把二者混为一谈，就会忽视“知识本身需要被建模、治理和演化”这一独立工作。

又为什么不直接用“神经”来指代智能体？因为一个真正投入运行的智能体，早已不是纯粹的神经网络，而是“model + harness”的复合体，内部就包含代码。把它作为一个实体，是从“职责”而非“实现”的视角看问题——我们关心的是“谁在承担这个岗位”，而不是它的每一块由神经还是符号构成。

需要说明的是，“一阶实体”并不是停留在纸面的概念划分。在真实运行的系统里，三者都由具体组件承载，有明确的位置和接口。把它们逐层展开，便得到下面这样一张运行时架构。

这张图里，智能体主要落在第二层的岗位智能体、协作总线与模型路由上；知识主要落在第五层的本体、规则机理、知识图谱与数据谱系上。代码则贯穿全部七层、分布最广：不仅第三层的流程引擎与策略执行、第四层的工具与微服务、第六层的数据与消息、以及横切各层的可观测治理平台由代码构建——第一层的交互界面本身也常由代码实现，用以限定和收窄人机交互的通道、降低认知负担、减少误操作；第二层智能体的内部实现（规划、记忆、循环及其驾驭外壳）同样离不开代码。图中各层标注的〈智能体〉〈代码〉〈知识〉，表示该层占主导的一阶实体，并不意味着其他实体在该层缺席。三个“一阶实体”因此不是三个抽象标签，而是三组看得见、可替换、可独立演化的组件。

尤其值得强调第三层——编排与控制层，它正是“驾驭”在系统级的落点：流程引擎、策略决策点（PDP）与执行点（PEP）、护栏、熔断与人工审批，共同构成一张驾驭平面。驾驭工程常被理解为“给一个智能体配上工具和约束”；而在系统视角下，它是一张横贯众多智能体、工具和资源的控制网络。

当三个一阶实体真正并列，架构设计的重心就从“如何让一个智能体更能干”，转向“如何组织三者的协作”。从大量案例中，可初步归纳出五类反复出现的模式。

1. 智能体主导、代码裁决（Agent proposes, code disposes）。 智能体提出方案，由类型系统、规则引擎、求解器等确定性代码做校验与裁决，通过后才交由受控工具执行——把概率性的灵活，收敛进确定性的闸门。

2. 代码主导、智能体补位。 常规、可预期的部分由代码自动流转，只有在遇到例外、异常或需要判断的节点，才把任务交给智能体。一句话概括，就是“惯例自动化、例外智能体化”。

3. 知识居中、双向约束。 知识不是被动等待检索的文档，而处于智能体与代码之间：它既为智能体提供理解与规划的框架，也通过“Ontology as Code”被编译为代码可执行的约束，同时约束两端。

4. 证据携带、闭环回写。 智能体每次执行，不只提交结果，还一并提交数据来源、校验记录、推理依据等证据，并把新的事实与经验回写到知识与数据谱系中，让系统的每一步都可追溯、可复盘。

5. 岗位协作。当系统中有多个智能体，它们之间也会形成类似组织的协作：按专长路由、上下游交接、会签复核、管理者—执行者（manager-worker）分工——这是把“岗位”的逻辑，扩展到智能体群体。

这五类模式的共同点在于：智能与可信，不再被寄托在某一个“足够聪明”或“绝对正确”的组件上，而是由三者的组合方式——也就是架构——共同保证。 智能体提供智能，代码提供确定性，知识提供共享的意义与约束；组织得当，系统就能在灵活与可靠之间立住。

第三章把智能体、代码、知识并列为三个一阶实体。这一章，我想在为代码“正名”之后再为它“升格”——因为在智能化系统里，代码的地位，远比“被智能体调用的工具”要高。

先从一个方向性问题说起。今天谈论智能体，多数人脑海中的拓扑是单向的：智能体位于中心，理解任务、做出规划，然后在需要时调用工具、操作数据库、驱动其他软件——仿佛一位员工在熟练地使用一台台机器。驾驭工程配置的工具链、MCP 标准化的工具接口，基本都服务于这个方向：让智能体更顺手地调用代码。

但只要回到真实企业，就会发现还有另一个方向，而且往往更常见。企业里大量工作，并不是“一个人自主决定做什么、再调用各种工具”，而是反过来：流程本身是预先定义、自动流转的，人只在其中某些固定节点上，完成相对确定的动作——录入一项数据、做一次判断、签一个字；流程的其余环节以及环节衔接，都由系统自动执行。智能体进入这样的环境，同样会被流程在固定节点“调用”：到了需要判断的环节，流程把上下文交给它，它给出结论，流程再继续向下。

如果说前者是“人用机器”，后者就是“机器用人”。未来的智能化系统，控制流一定是双向的：既有智能体调用代码，也有代码编排的流程在调用智能体。只承认前一个方向，本质上还是“智能体中心”的思维。

仅有静态组件图还不够。驾驭工程和循环工程之所以好懂，是因为它们紧紧咬住智能体的一个长程任务，一步步看得见。系统级架构同样可以用一个任务的完整旅程来检验——而且这个旅程更长，因为它把流程、知识、代码和人都织了进去。不妨以企业里最常见的“处理一笔异常订单（退款）”为例。

这条旅程里有几个关键节点：第 3 步是“机器用人”——不是智能体主动发起，而是确定性流程在判断节点调用它；第 6 步是“代码裁决”——智能体可以提议，但放行与否由策略和护栏决定；第7步把人留在回路里，作为高风险与不确定的最终锚点；第 8、9 步完成回写与沉淀，让一次成功不止解决一件事，而成为系统可复用的资产。

换言之，单个智能体的循环（计划—执行—自检—反思）并没有消失，而是被嵌入了一个更大的、跨组件、跨人机的循环。驾驭工程让人看见一个智能体如何思考；系统架构让人看见，这个思考如何被组织、约束、记录，并最终沉淀为组织能力。

沿着这条旅程，智能体与确定性流程之间，就形成了两条持续运转的通道。

一条向上，可称为“升级”（escalation）：当自动化流程遇到无法处理的例外、超出预设的情境，或需要价值判断时，它把问题向上交给智能体，由智能体临场理解、推理、决断——这是把“不确定”，路由给“会思考的一方”。另一条向下，可称为“沉淀”（sedimentation）：当智能体对某类问题的临场处理被反复验证为有效，这种做法就应被固化下来——提炼为规则、沉淀为技能、改写进流程，重新成为确定性代码的一部分；下次再遇到同类情况，系统自动处理即可，不必再劳烦智能体。

两条通道合在一起，构成系统持续成熟的机制：例外不断向上汇聚为智能，成功的智能不断向下沉淀为秩序。一个系统成熟到什么程度，很大程度上就看它有多少原本需要临场发挥的判断，已经被沉淀为稳定、确定、可重复的流程。

沿着这两条通道再看代码，会发现它在系统中有三重身份，一层比一层更基础。最表层，代码是“工具”：智能体调用的函数、脚本和服务，替它完成计算与操作，这重身份里，代码是智能体手中的器具。再往里，代码是“护栏”：类型校验、规则约束、权限检查、事务边界，在智能体动作前后拦截风险，这重身份里，代码是约束智能体的边界。而最基础、也最容易被忽视的一重，是代码构成了智能体栖居其间的“环境”本身。

这一点，游戏和自动驾驶领域早已给出了范本。一款游戏、一套自动驾驶仿真系统之所以“可信”，是因为背后有一个用代码构建的物理引擎：重力如何作用、物体如何碰撞、动量如何守恒、车辆如何响应操控，都由代码预先编码；智能的角色（游戏中的 AI、仿真里的规划算法）就在这个引擎划定的世界里行动——它可以灵活决策，却无法违背引擎所规定的规律。

企业和科学场景同样需要这样一个“世界引擎”。现实中的企业，需要一个数字化的孪生：业务对象有哪些、彼此如何作用、业务规则与科学机理是什么，都要用代码复刻出来。这个引擎既要支撑上层应用的开发与运行，也要让智能体在一个“规律真实有效”的世界里感知和行动。

这里恰好回应了知识与代码的分工：本体和知识，是对规律的“陈述”——它说清楚世界是怎么回事；代码，是规律的“可执行引擎”——它让规律在系统中真正生效。 所谓“机理—软件编译映射”，做的正是把陈述出来的规律，编译成引擎可执行的规则。顺带一提，支撑这一切开发与运行的底层平台环境，本身也无一不是用代码构建的。

当世界引擎真正建立起来，我们就抵达了可信的最高形态：不是靠一道道外挂的检查去拦截错误，而是让违规动作，在这个世界的结构里根本无法发生。

就像在一个物理规律真实有效的世界里，人无法穿过一堵墙、无法凭空创造质量——不是有人在旁边反复检查“你有没有穿墙”，而是穿墙这个动作在结构上就不成立。业务世界里同样如此：守恒的量只能移动、不能凭空赋值，越权的操作在权限结构里无法发起，不满足前置条件的动作无法进入下一步。也就是说，最高级的护栏，是让这个世界本身就没有给错误留门。 相比“等智能体犯错后再去发现、回滚”，让错误“无从发生”，无疑是更彻底的可信。

前面四章，从“岗位”讲到“中间层”，又从“三个一阶实体”讲到“世界引擎”，骨架已经立起。但要让这套系统真正具备工程说服力，还得回答一个更“硬核”的问题：传统软件架构里那些明确的组件接口、非功能性保障、分层异常处理、事件追溯，以及自适应软件强调的架构级自省，在智能化系统里还成立吗？又有哪些不一样？

我的总体判断是：这些架构纪律不仅没有过时，反而更加不可或缺；只不过它们要从“管理确定组件”，扩展为“驾驭确定组件与概率组件的耦合”。

这五要素里，最能统摄全局、也最能体现“系统架构”本质的，是最后一项——架构级自省。

研究自适应软件的同行都熟悉反射（reflection）的思想：系统在实际运行的“基级”（base-level）之上，维护一个与它因果相连（causally connected）的“元级”（meta-level）架构表示；先在元级模型上感知、分析、推演，再把调整决策反射、映射回基级落实。经典的 MAPE-K 闭环（监控—分析—决策—执行 + 知识）讲的就是这件事。这套机制在智能化系统里不仅保留，而且被大模型前所未有地增强了。

对照这张图，可以看清三件事。

其一，“可观测”与“可控制”，是反射通道的两个方向。 基级把状态、事件、轨迹、证据持续上报到元级（向上的感知），元级把诊断后的调整、修复与演化，经版本、灰度、审批受控下发回基级（向下的落实）。元级架构表示必须与基级实时、因果地一致，否则在元级上的一切推演都是空中楼阁。这也解释了为什么我们把可观测性看得如此之重——它是自省得以发生的前提。

其二，元级的“推演者”，今天可以是一个治理智能体。 它能读懂架构、理解谱系，并生成与验证改进方案。前面讲的 RSI、AIP Evolve，本质上都坐落在元级：在架构自表示上提出候选（注：这里的“自表示”——英文是“self-representation”，是反射理论里的核心概念，指系统在内部维护一份 “关于它自己” 的显式描述）、在仿真与评测中验证，再请求映射到基级。这正是“架构级自省”在 AI 时代的新形态——自省不再只靠人预写的规则，而有了能够推理架构本身的智能。

其三，也是最需要警惕的：元级一旦部分交给概率性智能体，元级本身也必须有护栏。 目标、验收标准和不可突破的约束由人外生锁定、不能被治理智能体改写；改进要经独立验证与人工审核，否则就陷入“谁来监督监督者”的困境，自省沦为自我授权。工程上，反射层数也必须有界——智能体可以治理智能体，却不能无限地元上加元。

说到这里，可以正面回应那个贯穿始终的问题：智能体与代码的关系，同传统软件组件之间的关系，究竟差在哪里？

传统软件组件是“同质”的：它们都确定地行为，通过固定接口交互，调用即是确定的控制转移，组件如何组合可以被静态分析，系统整体性质也能从组件性质可靠推导。而智能体与代码是“异质”的：一个是概率性的认知，一个是确定性的执行；控制流双向流动，大量路径在运行时才展开，因而无法完全靠静态分析把握，必须借助运行时观测与约束。代码为智能体的概率性“收敛”出确定性，智能体为代码的刚性“注入”灵活性。 二者既非主从、也非对等，而是在知识与契约的衔接下，形成一种动态共生。

也正因如此，我们信任的对象，从“每一个组件都正确”，转变为“组件被组织的方式——也就是架构——能够在组件不确定时，依然托住整体”。这，才是智能化系统真正的架构纪律。

回到开头那个问题：驾驭工程、循环工程，与未来的智能化软件系统架构，究竟是什么关系？

经过这一路辨析，答案已经清晰：它们是这套架构中扎实而重要的组成部分，却不是全部。驾驭工程和循环工程解决的，是“一个岗位如何可靠地干活”；而企业级落地所要回答的，是“如何把众多岗位、代码、知识、人、组织乃至物理环境，组织成一个值得信任的整体”。前者是智能体视角的工程，后者是系统视角的工程。从前者走向后者，正是智能化技术真正进入严肃场景所必须跨过的一道坎。

这是否意味着，要在“智能”与“可信”之间做一次非此即彼的取舍？并非如此。

一家成熟企业的高明之处，从来不是把所有工作都固化成不许变通的死流程，也不是放任每个员工自由发挥，而是清楚地知道：哪些环节应当确定、哪些环节可以自主，并让这条分界随经验积累不断移动——常规的、被反复验证的，沉淀为确定性的秩序；意外的、需要判断的，保留给个体的智能。智能化系统同样如此。智能与可信之间，不是一次静态的折中，而是一种高效的动态平衡：确定性与自主性的分界，应当在运行中可观测、可评估、可移动，并通过“升级”与“沉淀”持续调整。系统越成熟，越多智能沉淀为可信的秩序；同时又在秩序之上，为新的智能留出空间。

在这样的系统里，软件工程师的角色正在被重塑，而不是被取代。

当越来越多的“实现”可以由智能体生成，工程师真正稀缺的价值，会转向更高处：把模糊的业务目标，凝练为清晰的契约与约束；把散落的知识与经验，组织成机器可理解、可推理的本体与谱系；设计出能够验证对错、约束行为的护栏与验收机制；并在系统运行中持续观测、评估与治理。简言之，工程师的工作重心，正从“编写实现”，转向“定义契约、组织知识、设计验证、治理运行”。代码依然重要，甚至更为关键——只是它更多地以底座、护栏和世界引擎的方式存在。这要求工程师既懂智能体之所能与所不能，也懂系统工程之厚重。

今年 2 月，我在《Agent 狂欢与 Palantir 爆红背后：智能化软件正在“凤凰涅槃”》这篇文章中写下：软件不会在这场智能化浪潮中消亡，而会在神经符号融合中解构再重构、浴火重生。如果说那篇文章回答的是软件如何“重生”，那么这一篇想回答的，便是重生之后的智能化系统，应当如何被组织、被经营。

智能体让我们第一次拥有了可以承担“岗位”的智能，这是这个时代最激动人心的变化。但越是激动人心，我们越需要一份冷静：不要把未来寄托在一个个“优秀员工”的兢兢业业上，而要把它建立在一套值得信任的系统之上。 智能来自个体，可信来自系统——这，或许正是我们在驾驭工程与循环工程之外，最需要补上的那一课。

注：本文在AI辅助下完成，其中主要观点和逻辑来自本人。

彭鑫，复旦大学计算与智能创新学院副院长、教授，国家级高层次人才计划入选者。中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，中国汽车工程学会汽车基础软件分会副主任，《Journal of Software: Evolution and Process》联合主编（Co-Editor），《ACM Transactions on Software Engineering and Methodology》、《Empirical Software Engineering》、《Automated Software Engineering》、《软件学报》等期刊编委。2016年获得“NASAC青年软件创新奖”，2023年入选上海市东方英才拔尖项目，2024年获得“中创软件人才奖”。主要研究方向包括软件智能化开发与测试、智能化软件系统构造与运行支撑、具身智能与自主无人系统软件等。研究工作多次获得《IEEE Transactions on Software Engineering》年度最佳论文奖、ICSM最佳论文奖、ACM SIGSOFT杰出论文奖、IEEE TCSE杰出论文奖等国际期刊及会议优秀论文奖。担任2022年与2023年CCF中国软件大会（CCF ChinaSoft）组织委员会主席与程序委员会共同主席，以及ICSE、FSE、ASE、ISSTA、ICSME、SANER等会议程序委员会委员。