先说一类很常见的翻车现场。一个数字员工被问「把这份报销单转给张三的直属主管审批」，它很自信地查了通讯录，拿到一个名字，发过去了。结果那个人三个月前就调岗了，张三现在的主管是另一个人。报销单卡在一个已经不管这摊事的人那里，没人报错，日志全绿——只是这件事从此没人推进。
问题不在模型笨。模型很聪明，它把「查主管」这个动作完成得干净利落。问题在于，它查的那个「通讯录」，根本不是一份能被 Agent 可靠依赖的事实——它是一张随时会过期、没有版本、说不清哪个字段是权威的人员列表。
几个月前我在 Palantir 从本体长到 Agent，我们从 Agent 长回本体 里下过一个判断，下得很痛快：
Ontology 最难建的那个稳定核心——身份、关系、权限边界、审计证据——组织平台手里本来就是现成的：工号是身份，组织图谱是关系，审批链是权限边界的活体实现，审计日志是决策证据。
那篇讲的是路线：为什么组织平台可以反着走，先让 Agent 以数字员工的身份上岗，再从它的日常工作里长回本体。但路线讲完，有个工程问题被我一笔滑过去了——从钥匙串到本体，中间那道编译，具体怎么做？
「通讯录是现成的」这句话，和「通讯录能被 Agent 可靠地查询、推理、追责」之间，隔着的不是一个断言，是一堆很土的活：同一个人在 HR 系统和钉钉里可能是两个 ID；一个部门上个季度还在、这个月被合并了，那份历史审批该挂在谁名下；一个 Agent 问「这个人的直属主管是谁」，它凭什么相信拿回来的那个名字。开头那张卡住的报销单，就死在这堆活里。
这篇就把这道编译拆开写。核心判断只有一句：企业知识不是检索出来的，是编译出来的；而且要从最土的那一层开始编译——可验证的事实。
