FDE Ontology 本体层：应该怎么沉淀？

很多 FDE 团队都知道：项目不能永远靠人力定制，做完要把经验留下来。

但“留下来”经常被简单理解成：写几个 Skill。

Skill 当然重要，可它只是沉淀的一层。如果任务是什么、对象之间怎么关联、谁有权推进、什么情况需要审计，这些都没说清，换到下一个客户，团队还是会从头理解一遍。

我更倾向于把 FDE 的沉淀放在两条线上看：一条看业务经验有多通用，一条看它已经被沉淀成什么形态。

第一条线：先分清，它是通用能力、行业能力，还是企业特性

以汽车配件生产制造行业的任务跟进管理系统为例。

最底层，是不分行业都存在的通用能力：任务有 Owner、有状态、有进度，也会开启、推进、结束。

再往上一层，才是汽车行业的特殊性。比如这个行业的任务跟进，会碰到哪些典型角色、节点和协作关系。这一层可以逐步沉淀成汽车行业的模板。

最上面一层，是某家企业自己的特殊做法。它的组织结构、系统字段、审批习惯、客户数据和业务参数，不应该因为做过一次就被当成行业标准。

这里最容易犯的错，是把客户特例直接封进通用 Skill，结果下一家客户一用就不对。

我会用一个简单标准来判断：先看普适性。

假设一家车企有一条特殊规则，先不要急着下沉。只有当三家同类车企都出现这条规则时，才把它当成行业通用能力，进入行业层。只在一家企业出现的，仍然属于这家企业的实例。

这不是说“三家”是适用于所有行业的固定数字，而是提醒团队：行业模板必须来自同类客户的重复验证，而不是来自一次交付时的主观感觉。

第二条线：再分清，它已经沉淀到了哪一层

同一条业务经验，不只可以按通用性区分，也可以按沉淀形态逐步往下走。

第一层，是概念和知识表达。比如什么叫任务、什么叫进度、什么叫状态。这些内容可以先是文档、说明或半结构化表格，目的是让团队先讲同一种业务语言。

第二层，是结构化表达。任务有哪些实体，实体之间是什么关系，状态如何变化，谁能修改什么。这时，经验开始从“描述”变成可以被系统理解的业务结构。

第三层，是原子能力。比如读取任务、更新任务状态、查询 Owner、校验某个节点是否能推进。这些能力可以先封装为传统 API，也可以包装成给 AI 系统调用的 MCP。它们解决的是单点操作能不能稳定执行。

第四层，是 Skill。一个任务开启或结束后，需要检查哪些信息、识别谁是 Owner、确认谁有权限推进节点，这些重复出现的 SOP，才适合沉淀成一个 Skill。

再往上，多个 Skill 可以组合成一个 Agent。它不只是完成一个单点动作，而是围绕一个更完整的目标，编排多个步骤完成任务。

权限、审计这类能力则要横向配套。无论是 API、MCP、Skill 还是 Agent，只要开始碰真实业务动作，就要说清谁可以调用、调用后留下什么记录、出了问题怎么追溯。

两条线要一起用，而不是只做一张能力清单

如果只按“文档、API、Skill、Agent”来沉淀，团队可能会把一条客户专属审批规则包装得很漂亮，却没有发现它根本不值得跨客户复用。

反过来，如果只知道某个规则在行业里常见，却没有把它继续沉淀成结构、原子能力和流程，团队下次仍然只能从头开发。

所以，每做完一个项目，真正该留下的不是一句“把经验复用起来”，而是两组判断：

1. 这条经验属于跨行业通用、行业通用，还是企业特有？
2. 它现在只是知识表达，还是已经值得沉淀成结构、API 或 MCP、Skill，甚至 Agent？

这样看，完整本体层并不是所有 FDE 团队一开始就该建设的大工程。

更现实的路径是：先从真实项目里把概念、规则和场景说清，再把重复出现的部分做成结构和能力；等同类客户越来越多、复用不断被验证，行业模板才会慢慢长出来。

本体层不是先画出来的，它是被一个个真实项目磨出来的。

JOTO 企业落地观察

• 企业若在未经历多轮交付验证前就投入资源构建全量本体，易导致模型脱离实际业务流，维护成本陡增；应优先支持轻量级概念对齐与渐进式结构收敛。
• FDE 团队常将 Skill 视为沉淀终点，但本文指出 Skill 仅是第四层——这意味着企业若跳过结构化建模与原子能力封装，其 Skill 将缺乏可组合性与可观测性，难以支撑复杂 Agent 编排。
• 权限与审计被明确列为横向能力，说明企业在构建 RAG 知识工程或智能体工作流时，不能仅关注语义检索与动作执行，必须同步设计访问控制策略与操作留痕机制，否则无法满足金融、制造等强合规行业要求。
• 文中“三家同类车企”的验证阈值提示：行业模板的形成依赖于跨客户共性识别，这对企业级 RAG 知识库的构建提出新要求——需支持多源客户语料的差异过滤与共识提取，而非简单合并。