《AI即软件》第十三章:Skill中台——规则的家

一

读者们可以先思考回答一个问题，我觉得这个问题没有几个人能回答清楚的：

你们公司现在生效的管理规则，一共有多少条？

流程部门说：发文库里三千多份制度文件、流程文档和业务操作指导书。IT说：我们有500个电子流，各系统里的校验规则、状态机，加起来上万处。业务部门说：别看文件了，文件没人看——你问老王，差旅发票怎么审、备件申领走哪条路、什么情况可以破例，老王都知道。

这就是上一代企业里，"规则"真实的生存状态。它们住在三个地方：

发文库里——发了文就沉底，三年没人翻开；系统代码里——改一条审批线要立项排期，等八个星期；老员工脑子里——人一退休，判断跟着走。

三个地方，没有一处是"资产"。文件是死的，代码是藏的，脑子是带不走的。

第十一章那场报销里，我们数过，从头到尾只有两份Skill在场：一份《差旅报销提交》，一份《差旅报销审批》。但读完那一章你大概已经隐约感到不安——差旅标准会调，审批权限会改，财务科目会动，每变一次就多一个版本；报销之外还有请假、采购、授信、合同、备件申领……一家万人规模的企业，把散落各处的规则全部Skill化，是几万份。

几万份活的规则——会被执行，会变更版本，会互相调用，早晚还会打架。这是企业历史上第一次出现的东西。它不是文档，不能往知识库里一扔了之；它不是代码，不能塞进某个系统里自生自灭。

它是资产。而资产，需要一个家。

这个家，就是Skill中台。

二

把家盖起来之前，先说清楚它不是什么——最容易犯的误会，是把Skill中台当成"升级版的文档管理系统"。

不是。区别一句话就能说透：文档管理系统管的是"存"，Skill中台管的是"用"。

文档上传之后就是死的：没人说得清它第3节现在写的是什么、上次改了哪一行、还剩几分可信。而且，文档是用来规范人的行为，而人去不去看，照做不照做，都是不可控的，只能通过事后审计和奖惩机制来约束。但Skill是活的：它只要一发布，定义成Agent必须要执行的规则，那么系统就不会绕过它，每天被成百上千次调用和执行，每次执行都留下轨迹；它有版本，版本之间可回滚；它有Owner，Owner对它的行为负责；它被监控着——哪条规则误判率高、哪条规则半年没被触发过，目录里一目了然。

一个贴近的类比，是手机上的应用商店：应用要注册上架、要过审核、分版本更新、违规下架。Skill中台之于Skill，大抵如此——注册、审核、分发、版本、退役，五个环节一样不少。

但这个类比只对了一半，差的那一半恰恰是要害。应用商店里，App和App基本互不相干；而企业的规则和规则之间，是会组合的——一笔授信评估，要同时调用授信政策、行业风险、账期核查几份Skill加两组数据；也是会打架的——部门的规定和公司的制度冲突时，听谁的？

组合，是本章的主题；打架，留给下一章。

三

进了家门，第一件事是登记。

一份Skill注册进来，要留下四样底账：谁写的——Owner，这一栏不写清，日后就是"没人负责"；什么版本；什么状态——草稿、试用、正式、退役；管什么——权限边界，能读哪些数据、能触发哪些动作。

登记这件事看着平淡，做成了却有一层不平淡的意义：企业第一次能够回答本章开头那个问题了。 打开目录，按状态一筛，生效规则多少条、各归谁管、最近谁改过——清清楚楚。我干这行二十年，这是第一代能做到这件事的架构。光凭这一条，这个家就盖得值。

然后是版本。

第七章那份差旅报销Skill，版本1.2，Owner是财务部流程负责人。为什么企业资产版一定要有版本号？因为规则天然是会变的。差旅标准调整，住宿上限从八百改到一千——Skill跟着升一版，1.2到1.3，变更说明一句话，评审记录留档。改完发现不妥？回滚到1.2，几分钟的事。

听起来平常？对比一下旧世界：规则埋在代码里，改一条要排期八周；埋在制度文件里，改完发个通知，各系统里对应的代码没人记得同步——口径从这一天起悄悄裂开，两年后变成一笔说不清的烂账。版本管理对Skill的意义，不在"管理规范"四个字，而在让规则的变化本身也变得有序、可追溯。

说到版本纪律，我要再请出一位老朋友——第十一章提到的那位汽车零部件工程师Eric。他把十二年工程经验开源成一套Skill体系，里面每一份技能都带着版本和变更记录：改一条诊断规则，旧版本不删，新版本注明改了什么、为什么改。一个人的经验库尚且如此自律，一家企业几万份Skill，没有版本治理，不出一个月就会退回丛林。

四

接下来说"组合"——Skill中台最像魔法、也最容易讲玄的部分。

第十一章介绍过Eric的"总控路由"：任何问题进来先分类，"电机异响"要同时加载电机知识和振动诊断知识，再按需加载细分子技能。企业请求的真实形态正是如此——从来不是一份Skill对一个问题，而是一组Skill对一类问题。

把镜头对准一个具体场景：客户授信评估。销售想给一家合作三年的老客户提高赊销额度，请求进来，编排引擎做三件事。

第一件，加载。按Skill目录里的声明，这个请求需要：公司级《授信政策》Skill——额度和账期的硬规则；销售部级《行业风险评估》Skill——这家客户所在行业的近况判断；再从数据中台取两组数据——客户主档、过去二十四个月的交易记录。

第二件，路由与并行。政策合规是确定性检查，走规则引擎，毫秒出结果；行业风险评估是模糊判断，交给Agent在Skill框架内裁量，但要附判断依据。两条线并行跑，互不等待。第十一章报销案例里那张金额路由——五百元以下直入、3860元走部门主管——就是这里最常见的一种形态：条件路由。

第三件，也是最要紧的一件：收场。

这是我要重点讲的，因为它来自一个特别容易被回避的问题——并行跑两个子任务，一个成功、一个超时，这笔授信评估算成还是算败？

旧软件时代，这个问题几乎不存在：程序要么跑完、要么抛异常，路径是写死的。可现在干活的换成概率性的Agent，子任务超时、部分失败，是常态而不是异常。编排引擎如果不预先定义"怎么算完成"，Agent就会自己看着办——把超时的当通过的报上来。这不是危言耸听，这是工程界用真实事故换来的教训。

所以新一代Skill中台把收敛判据做成编排的必填项，白纸黑字写进Skill：这组任务，算完成的标准是哪一种——

• 全成功
  ：一个都不能少。适用于"错一个就是事故"的组合，比如合规检查加付款指令；
• 关键子任务成功
  ：关键项必须过，次要项失败走降级——行业风险评估超时，这笔授信自动转人工复核，既不卡死，也不放行；
• 多数成功
  ：批量场景——十张发票识别成功八张，两张转人工补录，整批算通过。

与判据配套的是失败处置三件套：重试、降级、整批放弃。而所有处置之上有一条铁律："没跑完、结果未知"是一个合法的终态——它必须被如实上报，绝不允许被包装成成功。 工具所报告的结果"成功"只是一面之词，作数的永远是对结果的独立核验。

这组判据的系统化梳理，我要归功于第十一章提过的那位作者——LJM（Jinming Li）。他那部四百多页的开源著作《Harness Study：智能体的工程实践》，卷三专门讨论了多任务协作的契约与失败处置。本章的收敛判据设计，受益于他的梳理。

我知道这几段是全书技术浓度最高的地方。业务读者不必记全三种判据的名字，记一句话就够了：编排引擎的本质，是提前替Agent回答"事情只办成了一半，怎么办"——你不提前回答，Agent就会替你乱回答。

五

"没有轨迹，就没有企业级Agent。"——这句话第十章第一次出现，第十一章报销的结尾又见了一次。现在可以交代它的归宿了：在架构上，执行轨迹是Skill中台的一等公民，是每份Skill的必填字段，不是可选配置。

回看第七章那份企业资产版Skill，最后一个字段就是"执行轨迹"。一次执行要留下十样东西：输入上下文、Skill版本、模型版本、工具调用、读取了哪些数据、判断依据、触发了谁的审批、输出结果、时间戳、责任主体。

这十样东西，支撑四件事：

审计——这笔账谁放的行，链路拉出来就是；复盘——那天为什么判错，判断依据白纸黑字；回滚——错到哪一步，退回哪一步；优化——哪个判断点反复出问题，说明这条Skill该改版了。

第十五章会讲轨迹的工程实现——它长在执行底座里。本章要说的是它的治理地位，一句话：轨迹不是日志，是证据。 日志是给工程师排错用的，可以滚动覆盖；证据是给审计和争议用的，只许追加、不许涂改。这和第十二章审计账本"只许追加"一脉相承——数据如此，行为亦然。

六

注册、版本、编排、轨迹，这些都是资产管理的"硬件"。让这个家真正活起来的，是一条通道——晋升通道。本章的分量，一半压在这里。

我们来讲一个故事。

销售部有一位做了十几年报价支持的老员工，按部门习惯，我们叫她老周。她每天要人工初审几十张报价单：配置全不全、折扣超没超红线、付款条款符不符合公司政策。查的东西不难，但项项要人眼过，一天下来眼睛发直。

去年，她把这些检查写成了一份Skill——《报价预审》，装在自己的个人空间里，自己用。

第一周，她初审一张报价单的时间，从十几分钟降到两分钟。

第二个月，组里同事发现了，来借用。这时候出现了第一道闸门：个人级Skill和企业级Skill是硬隔离的——老周的Skill住在她的个人命名空间里，同事可以看、可以借鉴思路，但它的输出进不了公司流程，它也拿不到公司数据接口的权限。这不是官僚。这是防"影子IT"：个人创作的自由，和企业流程的严肃，必须两全——个人的可以野蛮生长，但一旦碰企业数据、进企业流程，就必须走治理管道。

第三个月，销售部总经理发话：这么好的东西，不该老周一个人用，升部门级。流程启动。先过Skill设计师评审——这个融合了业务骨干和产品经理职责的新角色，审的不是代码，是Skill文本本身：规则写得清不清？边界划得对不对，哪些能自动、哪些必须人看？然后跑测试集：三十张历史报价单，当初人工判过的结论和Skill判的结论，对得上吗？再试用一个季度，执行轨迹随时可查。

部门级转正那天起，《报价预审》（部门版v1.0）正式接单，所有输出走数据中台接口、经动作网关留痕——它从"老周的帮手"变成了"部门的员工"。

又过了半年，财务部找上门来。他们发现，全公司的报价预审已经有七成先经过这份Skill，它的折扣判断口径，事实上影响了后面的授信和合同。影响已经跨了部门，那就必须升公司级：财务、法务坐进评审会，把授信政策的硬约束并进去，v2.0发布为公司标准。

老周的十几分钟，最后变成了全公司的两分钟。

但这个故事里，藏着一件比效率重要得多的事。

我把它想明白的那天，在笔记本上写了六个字：变异、选择、遗传。

生物的进化靠这三步——个体变异，环境选择，优势遗传。组织能力的进化，一模一样：老周在裁量空间里琢磨出的每一点改进，是变异；部门评审、测试集、试用期的数据，是选择；从1.0到2.0的一次次版本固化，是遗传。而个人级、部门级、公司级的三级晋升通道，就是把"选择与遗传"做成了组织制度——每一级晋升，都是一次环境的选择；每一次版本固化，都是一次优势的遗传。

换句话说：Skill中台不只是规则的家，它是企业能力的进化机制。 企业不再指望某位领导慧眼识珠地"总结推广先进经验"，而是让好做法自己长出来、被数据选出来、固化进版本里。

我干这行二十年，见过太多"老周"。他们的判断比任何系统都准——发票该不该放行、这个折扣能不能给，文件写不出那个手感。可人一走，经验跟着走，接手的人从头再错一遍。文件留得住字句，留不住判断。Skill第一次把"判断"本身写成了文字，而晋升通道让这份判断有机会离开某个人的脑子，长成组织的器官。

人会退休，但老周写的Skill不会。

七

资产管理的最后一环，是退出。

一份Skill退役之前，中台必须先回答一个问题：谁在用它？

这就是依赖追踪。Skill A的执行要调用Skill B，这层依赖就记在账上；B要变更或者退役，中台把所有依赖它的A列出来，连着近九十天的调用记录，逐个通知Owner确认——确认完才能动。

旧世界的读者，对这个问题的分量应该有切肤之感。第二章那个"0→1→0"的神秘代码，本质就是一次没有依赖账本的删除——没人知道那段代码被生产调度依赖着，删下去，三天后整个计划调度瘫痪。新架构里重演一遍：一份《物料状态变更》Skill要下线，中台一查依赖图，列出三份在用的上游Skill和调用记录——下线动作自动变成一次有清单、有确认、有回滚预案的变更，而不是一次赌博。

至此，一份Skill的一生走全了：

设计→评审→发布→执行→监控→优化→退役。

生有登记，活有轨迹，变有版本，终有交代。这就是"逻辑资产"四个字的完整含义——企业第一次像管理资金一样管理自己的规则。

八

最后，把三台的关系说透，本章就可以收尾了。

数据中台回答"什么东西是真的"，Skill中台回答"事情应该怎么办"，AI中台回答"怎么把事情真正办成"。三台各司其职，总线之上，业务插拔——第十一章立的六条原则，到这里全部有了着落。

数据的家，上一章盖好了；规则的家，这一章盖好了。

但在收尾之前，我必须把一个问题诚实地留在门口——它是这一章所有安宁的背面。

几万份Skill住进了同一个家：个人的、部门的、公司的。多数时候相安无事，但总有一天——而且很快——会有人发现：销售部《行业风险评估》里默许的账期宽限，和公司《授信政策》的硬规则对不上；某个团队自己攒的《合同初审》Skill，悄悄跳过了法务规定的那一步。

规则多了，就会打架。家里几万份规则，听谁的？

下一章，我们给Skill的世界立一部宪法。

第十四章：Skill的法律层级——治理模型与冲突裁决。