本体层、Skill、连接器：AI Agent时代的可复用资产怎么建？

做完一个项目你留下了什么如果答案是一套代码那你做的不是AI落地是外包。一个让人后背发凉的问题腾讯研究院在《FDE模式行业观察与实践》报告里提出了一个判断标准。我觉得这个标准可以用来审视每一个做AI落地的团队只留给客户一个系统 → 外包带回一些经验但无法复用 → 项目制交付沉淀为Skill / 模板 / 产品能力 → FDE沉淀后显著降低下个客户成本 → 可规模化FDE把团队换成自己重新读一遍只留下一套代码 → 代码工人带回一些经验但无法复用 → 项目制工程师沉淀为可复用的方法论、工具、模板 → 在成长沉淀后显著降低下一次同类工作成本 → 在规模化成长这个标准比任何绩效考核都狠。我回想自己过去做过的项目。每个都拼尽全力交付结果也不差。但如果问项目结束后留下了什么可复用的资产——说实话不多。代码留在客户那里经验留在脑子里没有变成模板、没有变成工具、没有变成可复用的方法论。下一个项目来了又是从零开始。报告把这种状态叫本体层缺失的恶性循环项目多、人手紧优先交付客户沉淀永远排在后面没有沉淀下一个项目又从零开始效率低、人更累于是更没有时间沉淀。这篇文章不讲道理讲方法。用FDE报告第九章里那个完整的ERP虚构案例做主线把可复用资产怎么从零建起来这件事走一遍。一、什么是本体层为什么它是一切的起点先说清楚概念。FDE报告里的本体层Ontology听起来很学术但本质不复杂——它就是结构化的行业业务知识。打个比方你公司系统里有个字段叫cust_id另一套系统里叫user_no第三套系统里叫主体编码。它们在业务语义上都是客户。本体层要做的就是把这些系统差异翻译成统一业务语言这是客户这是订单这是审批这是风险事件它们之间有什么关系能触发什么动作在哪些条件下需要人工介入。没有这层语义抽象AI只能停留在问答和摘要——它不知道订单是什么不知道审批涉及哪些角色不知道发货需要什么前置条件。有了这层语义抽象AI才有可能进入流程执行。本体层解决业务对象如何被理解Skill解决能力如何被复用连接器解决系统如何被操作。三者分别对应知识沉淀、能力沉淀和系统连接沉淀。三者组合在一起才构成一个可复用的行业解决方案。二、冷启动本体V1.0怎么从零到一FDE报告虚构了这样一个场景某AI平台公司决定深耕ERP行业目标客户是中型制造企业行业内潜在客户约80家。公司内部有一个5人的Echo团队负责本体与平台能力建设以及多支Delta团队负责客户前线交付。冷启动阶段Echo团队要做的事情第一步召集2-3位有ERP交付经验的领域专家用2周时间完成核心实体梳理。产出一份结构化文档内容包括核心实体清单客户、供应商、产品、订单、仓库、物流单、发票、收款单、退货单实体关系图客户→下单→订单→关联产品→触发发货→生成物流单状态流转规则订单的生命周期创建→确认→备货→发货→签收→完结/退货行为定义每个状态切换需要什么前置条件、谁有权限操作、异常处理路径第二步用AI辅助抽取。把已有的3套ERP项目的设计文档、数据库表结构喂给大模型让它自动抽取实体和关系草稿。Echo团队在此基础上补充、修正和确认。第三步最终产出。本体V1.0以结构化YAML/JSON Schema形式存储在内部知识库配套一份人可读的业务语言说明文档。关键原则有三条不追求完美覆盖70%主流通用场景即可明确标注已知缺口清单——哪些环节尚未建模等待前线验证AI生成的初稿必须由Echo专家逐条确认不能跳过人工审核报告特别强调了一点我觉得非常重要即使有AI辅助本体抽取——从代码逆向工程、从设计文档自动生成——人工确认成本依然很高。AI生成的结果可能98%是正确的但要找出那2%的错误人必须读完100%。不能给管理者形成AI来了本体建模成本很低了的错觉。冷启动阶段不产生直接客户收入必须作为基础设施投资获得独立预算。管理层需要设定明确预期前3个客户成本会更高预计第5-6个客户开始成本下降。这个阶段的核心产出物ERP行业本体V1.0结构化文件业务语言说明文档面向Delta团队的使用指南已知缺口清单面向Delta团队的观察指引三、第一个客户使用本体 发现缺口冷启动完成后Delta团队进入第一个客户现场。客户背景某中型制造企业年收入8亿元需要升级ERP系统中的订单管理和仓储模块希望引入AI Agent自动处理常规订单流转。Delta团队负责人做的第一个决策是否使用本体方案预估工时内部成本说明A从零定制约45人天0内部结算完全自己搭不依赖本体B使用本体适配约8人天本体使用费5万5万内部费复用本体70%内容只做30%适配客户需求复杂度中等偏上选择B更经济。Delta团队向Echo团队下单使用本体V1.0。然后是客户现场交付。Delta团队基于本体V1.0中的订单实体和状态流转快速搭建适合客户的本体模型。在对接过程中发现了两个本体里没有的差异点该客户的订单金额超过50万时需要总经理审批才能发货——这个大额审批环节在本体V1.0中不存在该客户的仓库分为成品仓和原材料仓发货规则不同——本体V1.0只有一种仓库类型Delta团队为客户定制这两个差异点确保项目符合预期。交付完成后Delta团队填写一份标准化的本体反馈单本体反馈单 #001【发现1】大额订单审批现象订单金额超阈值时需审批才能进入发货状态当前本体状态无审批环节建议增加审批者角色在确认→备货之间插入可选审批节点通用性判断中大型制造企业普遍存在预估60%以上客户有类似需求【发现2】多仓库类型现象成品仓vs原材料仓发货逻辑不同当前本体状态仓库为单一实体建议仓库增加类型属性不同类型关联不同发货规则通用性判断有一定通用性预估40%客户有多仓需求这份反馈单提交给Echo团队。如果反馈被采纳进入本体基线可以抵扣本体使用费——采纳1个高价值实体/关系抵扣1.5万采纳1个中等价值属性/规则抵扣0.5万。这就是内部结算机制的核心逻辑让Delta有动力把信息传递给Echo反馈可抵扣成本让Echo有动力保持本体质量质量不好就没人用内部收入归零。Echo团队在1-2天内完成评审。评审标准三条行业通用性30%潜在客户会遇到、纳入后维护成本是否可控、是否与已有实体冲突或冗余。评审结论两个发现都被采纳。本体从V1.0升级到V1.1新增审批节点为可选扩展点仓库实体增加类型枚举属性。四、飞轮转动从第2到第4个客户到第3-4个客户时Delta团队的操作模式发生了质变项目启动时不再需要评估是否用本体——本体已是默认起点项目执行中大部分时间花在客户特定配置和数据接入而非业务建模项目收尾时反馈单变成半标准化——很多时候只是在本体V1.2基础上我发现了一个新的可选路径报告给出了四个客户的数据对比我觉得这是整份报告最有说服力的部分客户行业本体版本Delta使用本体工时从零定制对比工时新增反馈客户A制造V1.0→V1.18人天45人天审批节点、多仓库类型客户B制造/电子V1.16人天42人天多级审批、序列号追踪客户C制造/物流V1.25人天40人天物流单拆分、多承运商路由客户D制造/快消V1.34人天38人天批次管理、保质期规则第1个客户节省82%45→8人天第4个客户节省89%38→4人天。本体从V1.0迭代到V1.3新增6个实体、12条关系、8个可选扩展点。到第5-8个客户规模效应全面显现指标第1个客户第5个客户第8个客户Delta交付工时8人天3人天2人天本体反馈频率每项目2-3条每项目0-1条几乎没有新增客户上线周期6周2周1周项目毛利率25%含本体投入分摊55%70%Bob McGrew在YC访谈中提出的核心度量原则可以作为补充衡量两件正确的事——交付的成果价值即使还无法完全捕获以及产品杠杆单位价值对应的现场投入应该下降。如果第一个客户需要10个人-月第十个同类客户仍然需要10个人-月模式就没有跑通。五、本体成熟从做项目到做产品到第23个月以后ERP行业本体进入成熟期。标志是Delta团队在ERP行业的平均项目工时10人天60%以上的客户需求可以通过配置少量定制完成不需要FDE全程驻场ISV伙伴基于本体独立服务客户不再需要平台方派Delta团队本体V2.x的最终形态18个核心实体42条标准关系15个可选扩展点8个预置Skill自动订单路由、异常告警、库存预测、审批流配置……5个系统连接器对接主流ERP、WMS、TMS等系统注意这个结构本体层解决业务对象如何被理解Skill解决能力如何被复用连接器解决系统如何被操作。三者叠加才构成一个完整的可复用行业解决方案。ROI也清晰了本体冷启动投入约150万6个月×5人到第8个客户已累计节省交付成本约300万正式回本。六、数据隐私客户最担心的问题“你们会不会把我们的东西拿给别人用”——这是客户最常问的问题。Delta的标准回答是“我们沉淀的是行业通用的业务概念结构比如’订单可以有审批环节’这类逻辑。您的具体订单数据、客户信息、业务参数全部留在您的环境中不会带走。这就像会计准则是公共知识但您的账本是您私有的。”报告给出了明确的数据隔离边界层级包含内容不包含内容归属本体层实体、关系、行为规则的抽象定义任何客户的真实数据平台所有通用Skill基于本体重新开发的通用能力模块客户数据访问平台所有客户Skill访问客户数据的具体Skill代码和配置—客户所有客户特定上下文客户数据—客户所有本体是行业的公共业务语言不属于任何一家企业。客户的数据、参数、配置始终留在客户系统中。带走的是对行业的理解不是客户的数据。七、没有API接口的老旧系统怎么办讲到这里有一个现实问题必须面对。本体层定义了订单“仓库”“审批这些业务概念Skill定义了怎么做”连接器负责接入哪些系统。但很多企业的现实是核心业务系统根本没有API接口。制造业的MES系统可能是十年前本地定制的版本没有开放接口能源行业的SCADA系统协议封闭政务系统的老OA更是连文档都没有。这些系统里跑着企业最核心的数据但AI就是接不进去。FDE报告的建议是用更轻量的方式Skill连接器行业知识库逐步逼近本体层的效果。但轻量的前提是你得有办法操作这些系统。这也是为什么在连接器这一层实在Agent的ISSUT工业执行引擎值得关注。它的核心能力是无接口执行——通过智能屏幕语义理解直接操作没有API接口的老旧系统。不需要对方开放接口不需要改老系统代码Agent像人一样看屏幕、点按钮、填表单但速度和准确率远超人工。对于制造业的MES无接口操作、能源行业的SCADA数据采集、政务系统的老OA审批流这种能力是连接器层的关键拼图。传统RPA也能做无接口操作但靠的是固定坐标和硬编码规则系统界面一变就崩。实在Agent的智能屏幕语义理解是基于AI的——它能理解屏幕上元素的语义界面布局变化也能自适应。八、什么样的产品能帮你建可复用资产回到那个核心问题有没有支持私有化部署的企业级Agent解决方案能帮企业把可复用资产真正建起来大部分Agent产品给你的是一个模型接口和一个对话界面。但FDE报告讲得很清楚可复用资产不是模型是模型知识系统连接编排能力的组合。从这个框架看实在Agent这类产品在三个层面都有对应能力本体层/知识库层面实在Agent内置RAG知识库能力可以把企业的SOP、产品手册、规章制度导入进去形成本地数据闭环。这对应FDE报告里行业知识库的角色——提供专业内容和业务上下文。更重要的是它支持私有化部署数据不出域——这对央国企和涉密领域是刚性需求。白皮书也特别提到央国企AI建设面临信创全栈是刚性约束从芯片到大模型必须自主可控。实在Agent背后有自研TARS行业大模型不是简单套用通用API在信创适配上有天然优势。Skill层面实在Agent提供智能体Skill插件、行业Skill模板和自定义技能导入能力。这对应FDE报告里Skill解决能力如何被复用的角色——把任务经验固化为可执行能力。报告还提醒单个Skill不构成护城河较可行的保护方式是把Skill与连接器和专属知识库封装成完整应用。实在Agent的Agent技能市场正是这个思路——Skill不是零散插件而是组织成行业模板的可复用方案。连接器层面实在Agent支持对接企业微信、文档系统、CRM等常用业务系统加上前面提到的ISSUT工业执行引擎处理无接口老旧系统。这对应FDE报告里连接器解决系统如何被操作的角色。两者叠加才能让AI真正进入企业核心业务流程而不是只在外围做问答。此外实在Agent还具备企业级防幻觉引擎、安全审计智能体和权限精细管控能力。白皮书在治理维度E里说得很清楚护栏必须进入拦截模式而非仅记录合规审查必须前置而非事后补审安全台账和法务台账必须是同一本账。这些不是加分项是准入门槛。九、一个判断标准最后回到开头那个问题做完一个项目你留下了什么FDE报告给出了一个可操作的判断标准。项目结束后问自己三个问题客户能被培训后自助完成的部分是否还在长期依赖FDE如果是说明Skill没有沉淀好。同类场景的下一个客户交付成本是否显著下降如果第一个客户需要10人天第十个客户仍然需要10人天模式就没有跑通。产品边界每个季度是否在向产品侧移动如果现场团队的工作量没有随时间下降说明经验没有回流到产品。三个都是否你做的是外包。三个都是是你才在做可规模化的FDE。白皮书说AI的竞争窗口正在以季度为单位快速收窄。留给企业在做了一堆项目、说不清留下了什么的状态里徘徊的时间不多了。本文核心案例与框架参考腾讯研究院《FDE模式行业观察与实践》报告第九章FDE全流程操作手册。该报告用完整的虚构案例把Echo-Delta协作机制从冷启动到规模化复用的全过程走了一遍。51CTO数智人才研究院《企业AI力白皮书》的SODTAE 6D评估模型则提供了企业AI成熟度的量化诊断框架。两份报告互为补充值得对照阅读。