Ontology本体层进化丨收束：阶段不是越高越好

大家都想知道怎么判断团队本体层阶段，关键其实很简单：规模匹配，而不是追求高阶。什么阶段就做什么阶段的事，这是最务实的策略。下面这张四维度决策图，加上各阶段的具体任务指南，能帮你远离资源错配的坑。

一个系列只说了一件事

这个系列几万字，核心信息其实就一句话：

5人团队用YAML文件，完全正确。15人团队上热加载和集中管理，也是对的。50人团队部署管理平台，这才是正解。这些东西本身没有“好坏”之分——只有“匹配”与“不匹配”的差别。Stage 4的平台再厉害，5人团队非得去搭它，结果就是2个月什么业务都干不了，团队直接崩溃。Stage 1的YAML文件看起来简陋，但它能让5人团队第二天就上线跑起来，对那个团队来说，这就是最好的选择。

一张决策图

下面这张图，就是帮你判断“你现在应该待在哪个阶段”的。从几个最简单的指标开始对照：

第一步：看团队人数
├── 1-5人 → Stage 1（YAML文件）
├── 5-15人 → Stage 2（热加载+集中管理）
├── 15-50人 → Stage 3（管理平台）
└── 50人以上 → 考虑Stage 4

第二步：看别名数量
这个指标比团队人数更客观。
├── < 500条 → Stage 1
├── 500-2000条 → Stage 2
├── 2000-10000条 → Stage 3
└── > 10000条 → Stage 4

第三步：看“改一个别名”的流程
├── 开发者打开YAML → 改 → 重启 → 5分钟 → Stage 1正确
├── CLI工具一行命令 → 立即生效 → 1分钟 → Stage 2正确
├── 打开Web界面 → 搜索 → 编辑 → 保存 → 或许要审批 → Stage 3正确
└── 系统自动发现 → 推给专家确认 → 自动生效 → Stage 4正确

第四步：看痛点
你现在的核心痛点是什么？
├── AI不认识别名？ → Stage 0→1的问题
├── 改别名要重启？ → Stage 1→2的问题
├── 谁改了什么不知道？ → Stage 1→2的问题
├── 改别名没有审批，出过问题？ → Stage 2→3的问题
├── 外部客户需要不同的命名空间？ → Stage 3→4的问题
└── 知识变化太快，人改不过来？ → Stage 3→4的问题

对照这四步，多数情况下，只用第一步（团队人数）就能得出正确结论。

每个阶段的具体任务

确定了当前阶段后，该做什么？不是一股脑全部推倒重来，而是只做当前阶段需要做的事。

如果你在Stage 0（纯Prompt）

要做的事：

1. 把prompt里所有的“如果...那么...”规则，抽出来写成约束规则，放到YAML里
2. 把prompt里所有的“X等于Y”的映射，抽出来写成别名表，放到YAML里
3. 把剩余的部分精简到300字以内——只留角色设定、任务描述、输出格式

不需要做的事：搭Web界面、搞审批流程、建图数据库。你只需要一个YAML文件和一个能读它的加载器。

如果你在Stage 1（YAML文件）

要做的事：

1. 把散落在各智能体目录下的YAML集中到公司级目录
2. 给共享本体和任务本体的划分定一个规范（什么放共享、什么放任务）
3. 如果觉得“改完要重启”麻烦，就加一个热加载机制（watchdog，15行代码）

不需要做的事：上数据库、建Web UI、搭审批流程。你的团队规模还小，YAML够用。

如果你在Stage 2（热加载+集中管理）

要做的事：

1. 加一个变更日志（自动记录每次修改）
2. 如果团队在10人以上，考虑加审批流程
3. 如果CLI工具不够用（行业专家记不住命令），考虑加一个简单的Web UI

不需要做的事：迁移到图数据库、做自动发现、搞数据闭环。除非你的知识变更频率是按“周”算的。

如果你在Stage 3（管理平台）

要做的事：

1. 完善你的API——让所有智能体通过API查询本体，不再直接读文件
2. 建一个“依赖分析”视图——改了某条别名，能看见会影响哪些智能体
3. 考虑数据闭环——如果能做到“数据自动发现新类型→推给人确认→自动更新”，那恭喜你，你在往Stage 4走了

不需要做的事：如果你只是团队大、别名多，但没有“知识需要自动更新”的需求——停在Stage 3就够了。Stage 4不是必经之路。

一个诚实的预测

根据你的团队和业务现状（2个开发、10+智能体、1个行业、内部使用），以下是诚实的预测：

维度	预测
当前阶段	Stage 1向Stage 2过渡中
Stage 2的必要性	中等。文件>10个但还没明显痛点
Stage 3的必要性	低。短期内不会有外部客户、团队短期不会超过15人
Stage 4的必要性	极低。别想这件事

建议：先把Stage 1的基础打好——共享本体和任务本体的分离、命名规范、加载器代码的健壮性。Stage 2的热加载和集中管理，等“改了要重启”这个问题真正让你难受的时候再上。Stage 3和4这两年不用考虑。

再回头看Palantir

系列开头提到了Palantir的Ontology平台——图数据库、实时数据联动、自动发现。它很先进。但现在你应该理解了：它的先进不是因为Palantir比你聪明，而是因为它的规模决定了它必须走到那个阶段。Palantir服务的是全球500强和政府机构，数据量级是百万级、千万级的，团队是上千人的。它如果停在YAML文件阶段，一天都跑不下去。反过来也一样：你的YAML文件方案不是“低级”，是因为你当前的规模不需要更复杂的方案。Palantir如果今天从零做一个新项目，它也会从YAML开始。它不会第一天就搭图数据库。

最后一段话

这个系列从“prompt里放规则为什么不靠谱”讲到了“图数据库驱动的动态本体平台”，跨度很大。但核心信息一直没变：

但组织行业知识不需要一步到位。你可以从YAML开始。随着团队和业务成长，知识的组织方式会自然地需要进化。不要提前进化。

如果你看完这个系列，只记住一件事，我希望是这件：打开一个空白文件，写下你行业里最常见的10个别名映射。花不了1小时。这是你的行业智能体从“裸奔”到“穿鞋”的第一步。做完这一步，你对“本体层”的理解就超过了80%的行业AI团队。剩下的，遇到了再说。

---

本系列至此完结。