本体层、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团队负责人做的第一个决策：是否使用本体？

客户需求复杂度中等偏上，选择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基础上，我发现了一个新的可选路径"

报告给出了四个客户的数据对比，我觉得这是整份报告最有说服力的部分：

第1个客户节省82%（45→8人天），第4个客户节省89%（38→4人天）。本体从V1.0迭代到V1.3，新增6个实体、12条关系、8个可选扩展点。

到第5-8个客户，规模效应全面显现：

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的标准回答是：

“我们沉淀的是行业通用的业务概念结构，比如’订单可以有审批环节’这类逻辑。您的具体订单数据、客户信息、业务参数全部留在您的环境中，不会带走。这就像会计准则是公共知识，但您的账本是您私有的。”

报告给出了明确的数据隔离边界：

本体是行业的公共业务语言，不属于任何一家企业。客户的数据、参数、配置始终留在客户系统中。带走的是对行业的理解，不是客户的数据。

七、没有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报告给出了一个可操作的判断标准。项目结束后，问自己三个问题：

1. 客户能被培训后自助完成的部分，是否还在长期依赖FDE？ 如果是，说明Skill没有沉淀好。
2. 同类场景的下一个客户，交付成本是否显著下降？ 如果第一个客户需要10人天，第十个客户仍然需要10人天，模式就没有跑通。
3. 产品边界每个季度是否在向产品侧移动？ 如果现场团队的工作量没有随时间下降，说明经验没有回流到产品。

三个都是"否"，你做的是外包。三个都是"是"，你才在做可规模化的FDE。

白皮书说，AI的竞争窗口正在以季度为单位快速收窄。留给企业在"做了一堆项目、说不清留下了什么"的状态里徘徊的时间，不多了。

本文核心案例与框架参考腾讯研究院《FDE模式行业观察与实践》报告第九章"FDE全流程操作手册"。该报告用完整的虚构案例，把Echo-Delta协作机制从冷启动到规模化复用的全过程走了一遍。51CTO数智人才研究院《企业AI力白皮书》的SODTAE 6D评估模型则提供了企业AI成熟度的量化诊断框架。两份报告互为补充，值得对照阅读。