Ref2Graph：把企业 SOP 编译成可以调度的技能图谱

企业里做 AI 知识库，常见的起手式是把制度、手册和产品资料上传，做解析、切片和索引，再接上大模型。

员工问一句，系统从资料里找出相关段落，组织成答案，还能附上出处。这条路线叫 RAG，检索增强生成，也是目前企业文档知识库接入大模型的一条主流路径。微软的 RAG 文档介绍了这种架构及其工程问题。

查资料当然有用。但做企业软件的人，很难只停在这里。

拿报销来说，回答“差旅补助是多少”和把一笔报销处理完，隔着好几步：材料是否齐全，票据是否重复，审批走到哪里，金额怎么核算，异常退给谁。问答框里写出一段流畅的说明，这笔单子还在那里。

我想试试另一种组织企业知识的办法：Skill + Reference。把怎么办事写进 Skill，把办事时需要查的依据放进 Reference，再用图谱连接技能、资料和脚本，以及业务状态。这就是 Ref2Graph 的出发点。

我把它做成了两份可以打开体验的网页：

当前是使用演示数据的产品原型。页面中的编译、门禁和监控用于演示设计；真实解析服务、图数据库和业务系统接入，需要后续实现与测试。

01. RAG 的难处，到了流程里会更明显

RAG 的基本做法，是先检索，再把找到的资料交给模型作答。关键词、向量都能用在这个过程中，混合检索和重排也可以。

问题出在“找到相关内容”之后。

一份制度被拆成小段，金额标准可能在这里，适用对象在前两页，例外条款又在后面。单看每一段都没错，凑到具体业务里就可能用错。Anthropic 在 Contextual Retrieval 中讨论过这类上下文丢失；补充上下文、调整切分和重排，都是改善办法。

还有一层更麻烦：检索结果按相关性排列，业务步骤却有先后。有些检查即便和用户这句话不太相似，也必须执行。票据核验、权限检查，还有状态锁定，漏掉其中一步，答案写得再漂亮也交不了差。

把更多资料塞进上下文，并不能自动补齐这些控制。资料一多，模型还要辨认规则版本、适用条件和彼此冲突的说明；金额计算、字段验证这样的工作，也需要可检查的程序逻辑。

RAG 仍然适合查资料，检索技术也一直在改进。Ref2Graph 想补的是流程这一层：让操作步骤、规则引用和执行条件有各自明确的位置。Reference 内容较多时，照样可以用 RAG 检索。

02. Skill 管做法，Reference 管依据

在这套设计里，一份文档要先拆清楚：哪些内容指导动作，哪些内容提供依据，哪些工作应交给程序。

制度修订了，可以更新对应的 Reference，再检查引用它的技能。计算口径变了，改脚本并重新测试。审批条件调整，则要回到 Skill 和相关业务状态，检查整个过程。

这种组织方式有现成的参考。Anthropic 的 Agent Skills 工程文章用文件夹打包操作说明、参考资料和脚本，按任务需要逐层读取。我希望把这条思路用到企业已有的制度和 SOP 上，并把依赖、状态与冲突关系单独管理。

写成 SKILL.md 不会自动让流程可靠。权限、版本、重试、并发，还有回退，仍要落实到执行系统；脚本也得接受测试。文件结构把职责摆清楚，后面的工程才知道该检查哪里。

03. Ref2Graph

Ref 是 Reference，Graph 是图谱。 起点是企业已经积累的参考文档：制度、手册，以及字段说明和规则表。先把它们整理成能维护、能引用的知识库，再把其中的对象和关系组织成图谱。

这里的“整理”，也包括从文档中拆出程序性的做法，形成 Skill。剩下的规则、定义和例子，作为 Reference 被按需引用。

文档目录能告诉人文件放在哪里。图谱还应该回答：哪几个技能依赖这份规则，哪个步骤要调用脚本，执行前需要什么状态，完成后会产生什么结果。

假设一份规则表被替换，沿着引用关系，就应当能找到需要复核的技能。“账户注销”和“资金划转”涉及同一个账户，也该把冲突关系摆出来，让调度器有明确依据决定是否阻断或排队。

所以我给这套设计取了 Ref2Graph 这个名字。图谱负责呈现这些关系，也为校验和调度提供关系索引。至于能否真正阻止一次并发误操作，要看执行层的实现和测试，不能只看画布上的连线。

04. 一份 SOP 进来之后，要经过什么

PRD 把这段处理过程拆成五步。

1. 解析文档。 留住标题层级、表格、条件和例外。
2. 编译规约。 分出操作步骤、参考资料和脚本职责，形成技能包草稿。
3. 做静态校验。 检查字段、引用、上下文预算、前置条件和失败处理。
4. 抽取关系。 建立技能、资料、脚本与状态对象之间的连接。
5. 登记版本。 把检查过的资产记录下来，供调用、追踪和修订。

这条流水线最容易被一句“一键生成”带过去。我更想把失败的地方交代清楚：原文有一张跨页表格，解析时丢了半行，后面的技能写得再规整，依据也已经错了。编译出的步骤漏了一个例外条件，也得有人能对照原文发现它。

原型中的“SOP 编译”页可以体验队列、阶段进度和产出物预览。目前选择文件仅读取文件名，没有真正解析或编译用户的业务文件。

05. 不妨拿一个技能走一遍

打开完整交互原型，可以先到技能库里搜索 invoice-audit。看完技能内容，再切到拓扑图谱，找它引用的资料、调用的脚本，以及消耗和产出的状态。

接着打开“门禁与本体”，对照节点、关系和校验项。这里能看出这张图允许表达什么，也能看出哪些信息不能只写在一段自然语言说明里。

想看编译过程，就回到“SOP 编译”；想看运行记录怎样呈现，去“SkillOps 监控”。这些页面使用示例数据，目的是让人可以沿着流程讨论：哪个环节少了信息，哪里出了错却找不到返回入口。

关心技术方案，可以直接读配套 PRD。里面的性能指标和实施周期是设计目标，尚未经过生产测量。

06. Token 账，也放进沙盒里算

Skill 和 Reference 分开后，可以按需读取：开始只看简短的技能名称与描述，命中技能后读操作规约，执行到具体分支再读相应资料或运行脚本。

原型里的 Token 沙盒把这件事变成了可调整的参数。默认设定是 100 个技能，每个技能的元数据按 80 tokens、SOP 按 2,500 tokens、参考资料按 1,500 tokens 估算，单次激活 2 个技能。

第二项的算式是 100 × 80 + 2 × (2,500 + 1,500)。改变技能数量或资料长度，页面会重新计算。

这是一笔假设账。页面把第一项标成“全量 RAG”，实际比较的是全部技能资料一次性注入的情景。检索、重排和缓存，再加按需加载，本来就可以出现在 RAG 系统里，不能把这两个数字当成对所有 RAG 产品的评测。

上线后要算的账还包括召回遗漏和任务成功率，重试次数、工具调用和总延迟也得算进去。上下文省了，单子办错了，省下的那点 Token 大概不够补人工返工。

07. 下一步

我想用一份脱敏 SOP 跑完整个过程：解析后逐条对照原文，复核拆出的 Skill 和 Reference，再准备成功、失败和冲突几组用例，检查执行结果。把这份文档处理明白，再进一步完善。

两个页面都可以直接打开：

• Ref2Graph 完整交互原型
• Ref2Graph 产品需求文档（PRD）

如果你的业务里有一份特别难讲清楚的 SOP，欢迎通过作者联系渠道交流。说清场景就好，内部文件不用发来。