一

第十四章的结尾，我留了三个问题：Skill说"要人批准"，执行底座怎么把这道闸装到每次点击之前？Skill说"严格执行"，引擎怎么保证一字不差？那个"干一步看一眼"的思考循环，里面到底装着什么？

回答它们之前，先讲一组数据。我第一次看到时，盯着屏幕坐了很久。

这是航空客服自动化的评测：同一批任务、同一个模型、同一张考卷，任务通过率从72%提到了92%。按常理，这种提升该来自模型升级——更大、更新、更贵。但这一次，模型一个字都没有动。

动的是模型外面。修复工具接口的规范，贡献了十个百分点；调用前把规则注入上下文，四个；把执行规则写清楚，两个；把递给模型的工具清单从五十个收窄到十二个，两个。

第十一章说过那句话：模型只是引擎，引擎不会自己上路。这组数据，是它最有力的注脚——让AI能干活的，大部分不是AI。

那么，"模型外面"到底是什么？这一章，我们走进三台的最后一座：AI中台，Agent的引擎房。Skill中台说"应该怎么办"，数据中台守"事实是什么"——把这两句话变成"真的办成了"，就是引擎房的全部工作。

二

引擎房里的第一件事实，会颠覆大多数人对AI工作方式的想象。

一条消息进入Agent，到结果返回，要走十三步、四个阶段。先组装输入：装配上下文、检查预算、压缩记忆、筛选工具清单、注入执行提醒；然后调用模型：发送、拆解推理；然后执行工具：校验参数、执行、处理结果；最后回写循环：结果写回、判定下一步、收尾。

数一数：十三步里，模型只出现在第六步。其余十二步，全部是代码。

为什么不把消息直接扔给模型就完了？因为每一步都在堵一个具体的坑：不装配上下文，模型不知道它该知道的事；不压缩记忆，长任务会把上下文窗口撑爆；不筛选工具，五十个工具摆在眼前，模型挑花眼——收窄到十二个，通过率反而上升；不校验参数，一次错误的调用就一路狂奔到底；不处理结果，工具明明报了错，模型还蒙在鼓里。

你看到Agent"在工作"的时候，你看到的只是第六步——水面上的一角。水面之下，是十二步工程系统在为模型服务：替它记住目标，替它挑对工具，替它把关动作，替它核实结果。

这不是给模型泼冷水。恰恰相反——模型的价值，正是被这十二步放大的。同一个模型，放进不同的底座，任务通过率可以差几十个百分点。买模型是买引擎；能不能上路、跑得稳不稳，看的是车。

三 

机器讲完了，把镜头对准一次真实的执行。第十一章我们跟着一张报销单走完全程；这一次，我们把镜头塞进引擎房，跟着一份报价单走。

公司《供应商报价审核》Skill，部门级，Owner采购部。一张供应商报价单，进来了。

第一步，触发判定。 这一步根本没经过模型：单据类型、金额区间，规则引擎毫秒级判定，命中审核流程。别小看这个细节——一天几万个流程实例，若每个都惊动大模型，算力账立刻爆炸。什么走引擎、什么走模型，Skill里事先写好（第六节细说）。

第二步，读Skill。 Agent向Skill中台请求v2.1版本，拿到步骤清单：查历史价格、判合理性、超阈值转人审、出报告。

第三步，查历史。 调用数据中台接口，取这家供应商过去二十四个月的价格记录。读什么、能读什么，接口上的权限说了算——第十二、十三章立的规矩。

第四步，判断。 模型上场了。对比历史均价、近期调价、同类物料行情，它给出结论："本单高出历史均价18%，超出该供应商历次调价的正常区间，建议核实涨价理由。"这是裁量执行区——AI来判，但必须附依据，而且判完不算数。

第五步，比较。 又回到代码：高出5%即需人审，这是硬规则。18%对5%，数字对数字，引擎一锤定音——第十四章说过，措辞骗不过算术。

第六步，升级。 审批中心弹出卡片：报价单、历史价格曲线、AI的判断与依据。采购经理扫一眼，批准核实，意见留痕——Skill说"要人批准"，闸就装在这里，每次点击之前。

第七步，写回。 数据中台接口更新状态，动作网关记录这次外部触达。

第八步，交付。 一份结构完整的审核报告：结论、依据、价格对比、审批记录，四样俱全。

八步走完，回头数一数：模型只出场了两次——第四步判断价格，第八步起草报告。触发是引擎，查数是接口，比较是算术，审批是人，写回是管道。工程界有一句话精确概括了这种分工："规则能表达的判断，用代码；模型只承担规则表达不了的判断。" 这不是权宜之计，这是混合执行模型的本意——用模型的昂贵与灵动，只换代码换不来的那两次判断。

四

那份审核报告，现在要请它担任一个新角色了。

传统流程里，报告是给人看的附赠品。在这里，它是Agent的记忆。 第四章说过"文档即记忆"，现在可以给出它的完整工程含义：Skill的交付件定义，就是Agent的记忆写入规则——报告写什么、存到哪、什么格式，Skill里写明，Agent照着写。下一个Agent接手这家供应商的下一笔报价时，第一件事就是读上一份报告：历史价格、上次争议、当时的判断，一翻即得，不用重新摸索。

干过项目的人都懂这句话的分量。没有交付件定义的Skill，就像没有文档的项目——每次交接，接手的人从头再摸一遍。文档缺失的亏，我做了二十年项目，吃够了。

Agent的记忆一共三层：会话上下文——正在处理的这件事，短期；项目文档——这件事的来龙去脉，中期，就住在那一份份交付件里；业务对象数据与Skill资产——这家企业的家底，长期，住在数据中台和Skill中台里。第十一章机制表里"记忆管理"那一行，展开来就是这三格。

短期的会话记忆还有一道难题：装不下。一个长任务跑下来，上下文很快见底，必须压缩。压什么、留什么？工程界用真实教训换来的纪律是：按价值压缩，按时间压缩是错的。 任务目标、用户约束，价值最高，原文完整保留；早期的工具返回，可以替换成一段摘要。而且压缩完必须做一件事：把任务目标原文重新注入。 缺了这一步的压缩，等于变相删除任务——Agent会勤勤恳恳地忘掉自己为什么出发。

这个道理，老员工带新人时天天在用：先交代"这个客户最在意交期，价格可以谈"——这就是目标重注入；然后才是过程的流水账。区别只在于，人靠经验悟出这一点，Agent靠写进底座的规则保证这一点。

记忆还需要格式。第十一章提到的那位汽车工程师Eric，把十二年经验整理成四类：项目案例——什么项目、什么问题、根因是什么、怎么解的、教科书上没有的那一句是什么；工艺窍门——什么条件下、怎么做、为什么；决策准则——如果怎样、就怎样、因为什么；踩坑记录——在哪个项目踩的、如果重来、教训凝成了什么原则。个人尚且需要格式才能把经验存成可用的形状，企业的记忆写入规则更应从中取形。没有格式的记忆是日记，有格式的记忆才是资产。

五

Agent说"我做完了"——然后呢？

第十三章说过，轨迹不是日志，是证据。但证据从哪来？这一节讲引擎房里管验收的部分，第十一章机制表里的"验证器"。它分三层，一层比一层软。

第一层，机器判。 结构完成了吗——报告该有的部分都齐了吗？数据填充完成了吗——金额、日期都非空吗？格式验证通过了吗？顺便说，"完成"这个词必须分级：结构完成、数据填充完成、格式验证通过、可交付——四级清清楚楚。缺了分级，"完成"在不同人嘴里根本不是一个意思，这是多少项目扯皮的根源。这一层判定不需要智能，代码说了算——硬闸门。

第二层，语义判。 "这份审核报告覆盖了关键风险点吗？"——这没法用代码判，用模型判。但注意：判的依据是Skill里写好的验收标准，不是模型自由发挥。它像考官——考官可以聪明，考卷必须是Skill出的。

第三层，过程判。 跑几百步的长任务，等终点才验收就晚了。中间每隔一段设检查点：方向对不对，有没有在原地打转——防的是"一路狂奔地跑错"。三层验收，从硬到软，第十章那句"AI的自由度取决于它的输出可不可验收"，在这里长出了牙齿。

验收之外，是证据的纪律。Agent打的每一个外部动作——发邮件、调接口、写数据——记四笔账：意图，它想干什么；尝试，它实际做了什么动作；报告，工具说结果如何；实况，外部世界实际如何。为什么分四笔？因为工具的"成功"只是它的一面之词：邮件接口说"发送成功"，作数的是对方服务器收没收。四笔记全，"说完成了"和"真完成了"从此是两笔账。

证据账本还有三条铁律。只追加——能改的证据等于没有；记错了，追加一条更正记录，不许回去涂原文——第十二章数据的账、第十三章行为的轨迹，同一条宪法。热路径写事实、离线做解释——运行中只记无可争议的事实；解释与归因是易错的判断，放到事后慢慢做，做错了可以重跑，事实没有被动过。防两种沉默——该响的没响：声明过的事件没发生，要靠定期对账揪出来；报警器自己坏了：检测器也要被检测，定期喂几个已知坏样本，验证它真的会响。

这三条不玄，但每一条，都是真实世界塌过桥的地方。

六

还剩最后两笔账：成本，与克制。

先算成本。 这笔账从模型的选择开始：不同任务用不同的模型——分类、抽取这类粗活，便宜模型足够；复杂裁量这种难活，才请贵模型出场。第十一章机制表里"模型适配"一行，展开来是一项调度策略。然后是执行方式：企业流程里大部分操作是高频且确定的——查余额、对账、走标准审批链。这类操作，Skill可以"编译"成确定性的执行流——不经过模型，引擎直接跑，百分之百确定，成本趋近于零。这就是预编译路径。于是三种执行模式各就各位：实时推理——复杂判断、头一次遇到的场景，贵但值得；预编译——高频确定性操作，快而便宜；异步批处理——夜间报表、批量对账，不抢白天的道。哪些操作走哪条道，是Skill里的声明，是架构决策——不由Agent临场自作主张。

再谈克制。 这两年，"多Agent"是最热的词——遇到复杂任务就拆成一群Agent，各干各的，听着就先进。但研究界的一组数据泼了盆冷水：对一千六百多条多Agent执行轨迹的分析发现，76%的失效出在接口与边界上——任务怎么切、结果怎么传、权限怎么交；单个Agent能力的强弱，反而是次要因素。一群Agent，就是一堆交接界面，每个界面都是一道可能出错的缝。

所以工程界的克制原则是：能一个Agent干完的，不拆成一群。 确要拆，两条纪律：层级最多两层——层再多，故障定位先失效；父子权限取交集而不是并集——分身不继承全权，分身交回的结果默认不可信，须独立校验后才采信。

业界有一句话，把这种克制说到了底："控制流在代码里，判断力在模型里。" 它和第十章的裁量度模型、本章第三节的混合执行，是同一句话的三种说法——本书选的路线，业界已经用脚投了票。

七

到这里，架构设计的四层，讲完了三层半——数据的家、规则的家、规则的法律、引擎房。还剩最后半层：四层里最上面那一层，交互层。第十一章说它"反而最简单"，只给了几段话；下一章，我们把这一层单独拆开。

回望第十一章挂出的那张全景图：四层，从数据到交互；两面，控制与验证。随后的四章，我们逐层拆开：第十二章盖了数据的家——金库与防盗门；第十三章盖了规则的家——注册、编排与晋升；第十四章立了规则的法律——层级、三轨与终裁；这一章，走进了引擎房——十三步、三层记忆、三层验收、三条执行道。

六条原则，此刻可以逐一验收。双唯一通道——读写过数据中台，做行动作网关；Skill是唯一的业务逻辑载体；Agent是执行者不是决策者——本章八步审核里，模型只出场两次，每一次都在Skill划定的框里；治理内置于架构——层级、三轨、终裁，长在必经之路上；没有轨迹就没有企业级Agent——证据账本，只追加；三台总线，业务插拔。六条全部落了地，没有一条悬空。

还有第十一章那个总公式：可靠的企业级AI执行 = 明确目标 + 硬约束 + 授权裁量空间 + 工具与数据接口 + 验收标准 + 审计轨迹 + 人机审批。 写下它的那一章我说过，架构没有发明任何新东西。现在，七个词每一个都有了住址：明确目标住在Skill里，硬约束住在数据中台和动作网关里，授权裁量住在裁量度模型里，工具与接口住在引擎房里，验收住在三层验证器里，轨迹住在证据账本里，审批住在审批中心和治理委员会里。

做了二十年IT，我画过数不清的架构图。这一套，是我第一套敢说"每一层都站在论证过的道理上"的架构——没有一块砖是拍脑袋的。

但图纸终究是图纸。画架构图的人都知道，真正的考验从破土动工才开始：谁来写Skill？IT部门转身去干什么？业务部门怎么接住这份自由？旧系统里那几十万行代码，怎么办？

在那之前，先把最后半层补齐：第十六章：对话即界面——从点击到对话的人机交互。