ONTAO 理论体系 · 第三篇：决策链理论
📍 所属层：企业运行本体层——建在哪——决策链是操作本体的落脚点
落脚点选在哪——为什么是决策链，怎么选，怎么跑通。
这一篇决定 ONTAO 的价值边界：建模哪里，不建模哪里。
一、为什么落脚点是"决策链"而不是"对象"或"流程"
回顾第二篇的结论：本体论的价值单位是决策，不是对象。
三个论证：
- 价值论证：AI 在真实业务中产生价值的时刻，是它参与决策的时刻——不是它"知道"某个对象的时刻。查得到库存 ≠ 值钱；能判断"这个单能不能插"才值钱。
- 复杂性论证：从对象出发建模，会滑向"数字孪生"——几百个对象、几千条关系、越建越多、越来越没人看。复杂到没人看 = 等于没有。
- 可验证论证：决策链是可跑通、可验收的单位。"供应商异常时 AI 能给出处置建议并推动低风险动作"——这是可以检验的真/假命题。而"关系图画得对不对"无法检验。
决策链的定义（重申并精确化）：
一条决策链 = 从触发条件到动作落地的完整通路，包含：触发 → 对象集合 → 数据 → 规则 → 动作 → 审批 → 执行 → 回填。
"决策"的精确定义（来自 Palantir 操作本体的判据）：
任何"选择业务结果的写入"都是决策——无论它叫什么名字（改状态、批申请、调参数、发通知），只要落笔改变了业务结果，就是决策；决策必须走动作（Actions），不允许直写。
推论：
- "查一下数据"不是决策（无写入）
- "改个备注"是否决策？——若备注影响后续判断（业务结果），是；否则不是
- 决策链上每一环只要发生"选择业务结果的写入"，就必须有对应的动作定义 + 权限——这正是动作是唯一写通道（第二篇）的由来
二、三条标准的深层逻辑
选决策链的标准：高频、昂贵、依赖多人判断。缺一不可。为什么是这三条？
| 标准 | 深层逻辑 | 缺了会怎样 |
|---|---|---|
| 高频 | 频率决定复利——同样的建模投入，跑的次数越多回报越大 | 一年一次的事，建模成本收不回来 |
| 昂贵 | 代价决定容错价值——决策错了损失越大，AI 参与的价值越大 | 小事错了也无所谓，AI 没价值 |
| 依赖多人判断 | 复杂度决定痛点强度——信息分散在多人/多系统/多经验里，才需要"拼接地图" | 一人拍板的事，AI 只是加速器，不是拼图者 |
三者的关系：高频保证收益，昂贵保证价值，多人判断保证AI 不可替代性——这正是 Palantir 选客户/选场景的底层逻辑，也是我们选落脚点的底层逻辑。
反直觉推论：最好的落脚点往往不是"最赚钱的流程"，而是"最痛的、最常发生的、最需要多方对齐的"判断。因为它最需要本体论，也最容易让本体论见效。
三、反对"数字孪生"：为什么全量建模是陷阱
数字孪生的诱惑
"既然要做本体，那就把整家公司建模出来——所有对象、所有关系、所有规则。" 听起来完备，实际上：
数字孪生的四个死因
- 没人看：几百个对象几千条关系的图，复杂到所有人看不过来 → 沦为壁纸
- 维护成本爆炸：业务每变一次，图就要改一遍 → 很快过时 → 过时的图比没有图更危险（AI 依据过时本体行动，后果自负）
- 验证无从下手：全量图无法验收——没人能说清"这张图对不对"
- 收益不集中：资源撒在百里，不如砸在一处——决策链跑通有闭环，全量建模没有闭环
正确姿势
不是：先把全公司建模，再让 AI 干活
而是：找一条决策链，沿链建模（够用就停），跑通闭环，再扩展
本体不是一步画完的地图，是从一条条决策链长出来的活体。
四、最小闭环原则
定义
最小闭环 = 一条决策链上，AI 从"理解状态"到"权限内推动动作"的完整通路，用最小成本跑通。
最小闭环的四步
① 触发 定义什么情况进入这条链（可判定的触发条件）
② 理解 AI 读取相关对象的状态与属性（地图）
③ 建议 AI 依据规则给出处置建议（分析）
④ 动作 AI 在权限内推动下一步（低风险自动/高风险报人审批）
为什么必须"闭环"而不是"半截"
- 只做到②（AI 能理解）→ 还是聊天助手，员工仍要复制答案去群里确认 → 失败
- 只有做到④（AI 能推动动作）→ 才是"地图+按钮" → 成功
验收标准（固定不变）：
| 状态 | 判定 |
|---|---|
| AI 给答案后，还要复制到群里找人确认、开会审批、手动操作 | ❌ 只是聊天助手 |
| AI 理解当前真实状态，识别受影响对象，在权限内推动下一步动作 | ✅ 接近真正本体论 |
五、如何识别一条好的决策链（实操方法）
识别入口（从哪找候选）
- 高频事务：每天/每周都会发生、需要反复判断的事
- 痛点访谈：哪些事"最怕出错的""最需要找很多人确认的""最依赖老师傅经验的"
- 事故回溯：过去出过事、赔过钱的判断点
- 多系统交界：信息分散在 CRM/ERP/Excel/微信群/人脑里的判断——多系统交界处就是本体论的主战场
筛选问题清单（对每条候选链逐个提问）
- [ ] 多久发生一次？（高频？）
- [ ] 判断错了，代价多大？（昂贵？）
- [ ] 需要几个人/几个系统/多少经验才能判断？（多人判断？）
- [ ] 现在判断依据是"文件+数据+人"还是"只有人"？（后者痛点更强）
- [ ] 跑通后 AI 能否产生真实动作？（还是只能给建议？）
反向筛选（什么不值得建模）
- 一年一次：不值得
- 错了无代价：不值得
- 一个人拍脑袋就能定：不值得
- AI 只能给建议、永远无法推动动作：暂缓
六、含糊问题清单：本体论真正困难的地方
文档的警告（本体论.txt）
本体论真正困难的地方，从来不是画图、不是写代码，而是逼着企业去回答过去经营中一直含糊的问题。
含糊问题 ≠ 复杂问题——含糊问题是"从来没被逼问过"的问题，答案藏在各部门的默认假设里：
"重要客户"到底谁说了算？ （销售/财务/老板各有一本账）
"已成交"是不是同一个意思？ （销售看签约，财务看回款，交付看上线）
出现异常谁有权判断？谁负责处理？ （以为有流程，实际靠人吼）
处理结果应该回到哪里？ （结论散在群里/邮件里/脑子里）
谁最终认为这件事"结束了"？ （没有人——所以永远在打补丁）
为什么这比画图难得多
- 答案不在任何系统里——数据、文件里找不到，必须逼人去回答
- 答案往往是政治性的——"谁说了算"牵动部门博弈，有人不想说清
- 说清意味着责任明确——含糊是有好处的（可以随时解释），显性化=失去模糊空间
操作化：含糊问题清单
每条决策链建模时，第一步不是画对象，而是列出这条链上所有"过去靠人模糊处理"的问题，逐条逼出可判定的答案：
问题：什么算"重要客户"？
逼问 → 回款评级 ≥ B 且年交易额 ≥ X？ → 是规则，入库
逼问 → "看情况吧"？ → 不算答案，继续逼
问题：什么算"异常"？
逼问 → 连续 3 次同步失败 或 单日收入骤降 > 50%？ → 是规则，入库
逼问 → "感觉不对"？ → 不算答案，继续逼
验收标准：一条决策链的建模完成，不是"图画完了"，而是"清单上的含糊问题全部有了可判定答案"。每一条答不出的问题，就是本体的缺口，也是业务的隐性风险。
七、决策链的解剖：链上每一环都要能回答
以"供应商异常处置"为例（拾光传媒）：
触发 数据异常：连续N次同步失败 / 收入骤降超阈值 / 上游API报错
└→ 触发条件必须可判定（具体数值/次数），不能是"感觉不对"
对象 供应商、上游服务、链接、站点、下游客户
└→ 每个对象的当前状态可查（地图）
数据 今日收入、同步日志、历史基线、上次处置记录
└→ 数据来源明确，单一事实源
规则 什么算异常？什么程度该暂停？哪些情况要通知谁？
└→ 规则必须可判定（见第二篇）
动作 低风险：标记异常、生成处置建议、通知相关方
高风险：暂停同步、停用链接 ← 必须人审批
审批 谁拍板高风险动作？审批点在哪一环？
└→ 权限四层（理解/建议/自动/必批）
执行 动作落地 → 状态更新
回填 这次处置暴露了什么新规则？写回本体
└→ 本体是活的
解剖的意义：链上任何一环回答不了，就是本体缺口——要么补规则，要么补数据，要么补权限定义。
标准案例：插单决策（来自本体论.txt）
制造企业接到急单，老板问 AI"能不能插进来赶紧做"。聊天机器人只会翻出《紧急订单处理制度》复制给你——但真实业务里答案分散在七个地方：
客户是谁？过去回款怎么样？ → CRM + 老销售的记忆
这张订单毛利多少？ → ERP
仓库有没有能插单的原料？ → 库存系统
哪条产线有空档？ → 生产系统
插单会不会影响哪些订单？ → 排期逻辑
其他订单延期要赔多少钱？ → 合同条款
谁有权批准插单？ → 老板/管理层的默认权力
这正是本体论要拼接的：把分散在 CRM/ERP/生产系统/Excel/微信群/老员工脑子的东西拼成一张图，AI 才能"不是在猜答案，而是理解此刻真实发生的业务状态"。
这条例子的启示：插单决策 = 高频（工厂常有急单）+ 昂贵（排期/赔偿/客户关系）+ 高度依赖多人判断（销售/生产/财务/老板）——完美命中三标准。
八、决策链的运行时剖面：五层交互架构
前文回答了两个问题：最小闭环回答"决策链分几个阶段"（纵向时间流），链解剖回答"链上有什么环节"（横向要素）。这一节回答第三个问题——AI 与本体交互时，每一层的责任边界在哪：哪些靠系统确定性执行，哪些给 LLM 自主，哪些是红线。
这一层视角来自 Palantir 在松下能源北美（PENA）AI 维修平台的工业实践。技术人员与 AI 的每次交互严格沿五层展开：
技术人员提问 ──> [L1 上下文层] 系统自动注入对象当前状态（确定性触发，不靠 LLM 自觉）
│
▼
[L2 查询层] LLM 沿知识图谱导航，链接遍历关联对象（LLM 自主）
│
▼
[L3 逻辑层] 调用封装函数/模型，LLM 严禁自己计算规则（函数负责）
│
▼
[L4 行动层] 生成推荐方案，确认后回写源系统（LLM 提案 + 人确认）
│
▼
[L5 治理层] 权限动态拦截 + 决策血缘留痕（端到端贯穿）
五层与决策链的对应
| 五层 | 对应最小闭环环节 | 谁负责 | 关键纪律 |
|---|---|---|---|
| L1 上下文层 | 触发 + 理解 | 系统（确定性） | 对象当前状态自动注入，杜绝 AI "睁眼瞎" |
| L2 查询层 | 理解 | LLM（自主） | 沿链接遍历对象，不自由写 SQL |
| L3 逻辑层 | 建议 | 函数/模型（封装） | 计算封装在函数里，LLM 只调用不计算 |
| L4 行动层 | 动作 | LLM 提案 + 人/系统执行 | 动作合规、状态回写一致 |
| L5 治理层 | 全程 | 系统（拦截 + 审计） | 权限分级动态拦截、决策留痕 |
每层一条纪律（可直接做验收检查项）
- 上下文自动注入——对话开始前，系统已把对象当前状态（设备ID/最新告警/近期日志）塞进上下文。AI 不需要用户手动描述现状。对应 ONTAO 的"AI 强制加载机制"：不是靠 LLM 自觉去查，是系统确定性地给。
- 查询走对象工具——AI 通过对象查询工具过滤、聚合、沿链接遍历拿数据（
机器 → hasTickets → 维护工单），而不是自由写 SQL。防幻觉、防越权。 - 逻辑走函数——复杂计算和专业模型封装为函数（如
findSimilarSolutions(machineId, alarmCode)），LLM 只负责调用和解释结果，严禁 LLM 自己算。对应拾光传媒的扣量公式红线：规则在函数里，LLM 碰不到。 - 行动回写——AI 推动的动作真实改变对象状态，并回写（Writeback）到物理源系统，实现闭环操作。不是"嘴上给个建议"。
- 治理贯穿——权限不是事后补救，是 L1–L4 运行期实时拦截（T1 初级工让 AI 下高额采购单 → 第四层直接拦截）。决策血缘（Decision Lineage）：AI 推荐 + 人类反馈（点赞/点踩/文字修正）全程不可篡改留痕，驱动系统自我迭代——比"版本化+回填"更细：不仅记结果，记"推荐→反馈"过程（详见第五篇演化与沉淀理论）。
为什么决策链必须讲五层
- 只讲环节（解剖）不知道责任边界——"逻辑"到底谁算？答：函数算，LLM 不算。不立这条，LLM 就会绕过规则自己"拍脑袋"。
- 只讲闭环（四步）不知道确定性锚点——"理解"靠什么保证不漏？答：上下文层系统注入，不靠 LLM 想起来。不立这条，AI 永远是"问一句查一句"的被动工具。
- 治理层单独成层，是因为权限与审计不是某个环节，是贯穿所有环节的剖面——与决策链"审批"环节的区别：审批是链上一个点，治理是整条链的底色。
一句话：决策链"通不通"的终极判据 = 五层全通——上下文自动注入、查询走对象、逻辑走函数、行动回写、治理拦截。任何一层缺失，AI 就退回聊天助手。
九、多决策链的扩展逻辑
一条链跑通后，怎么扩展？
原则：从"最痛"到"相邻"，不跳跃
- 优先扩展共享对象的链（供应商异常处置跑通了 → 供应商生命周期里的其他链顺带补上）
- 优先扩展共享数据的链（同一批对象/数据源，边际成本低）
- 避免扩展全新领域的链（除非它符合三标准且有人力）
扩展的本质：本体像树一样生长——从第一条链的根，沿着共享的对象/数据长出相邻的枝，而不是从零开始铺一片森林。
十、链间规则冲突与仲裁
链越建越多，树越长越密——共享对象是扩展的捷径（第九节），也是冲突的温床：两条链在交叉处给出矛盾的答案时，冲突不裁，多链就从"树"退化成"补丁堆"。
冲突的四个形态（长大的必然，不是事故）
| 形态 | 表现 | 例子（拾光传媒观察） |
|---|---|---|
| 判定冲突（读） | 两条链对同一状态给出相反结论 | 风控链判"暂停该供应商"，结算推送链仍按它正常结算 |
| 写冲突（写） | 两条链同时写同一状态 | 同步管线链回写收入的同时，手动修复链也在改同一行 |
| 时序冲突（依赖） | A 链正在改的状态是 B 链判定的输入 | 处置链刚停用链接，健康检查链还基于停用前快照判"异常" |
| 价值冲突（目标） | 链的目标本身相反 | 收益链想调低扣量率，风控链想调高——没有技术错，是目标在打架 |
为什么冲突必须显性仲裁
冲突不裁不会消失，只会从规则层下沉到实现层——代码里写死"谁先跑、谁覆盖谁"，回到本体论没建成的老样子。四个退化：
- 行为随机：今天 A 赢明天 B 赢，规则变成掷骰子，AI 建议不可预期
- 规则失灵：实际被绕开的规则不是规则——"暂停"了还在结算，规则就失去了可信度
- 越界：拿 A 链的权限做 B 链的判定（裁决权没声明，谁都能顺手裁）
- 补丁堆叠：每次冲突现场改一条，越改越乱——第七篇的"冗余"腐烂症状在链间重演
仲裁的四个机制（按冲突形态对症）
| 冲突 | 仲裁机制 | 依赖的既有机制 |
|---|---|---|
| 判定冲突 | 管辖域声明 + 规则优先级：建链时声明"我读哪些对象、写哪些状态"，管辖域重叠处显式标为冲突点；冲突时更高优先/更具体的规则胜出——优先级本身是规则，改它走规则提案 PR，人拍板 | 含糊问题清单（第六节）、规则提案=PR（第五篇）、权限四层必批（第四篇） |
| 写冲突 | 唯一写通道 + 写回所有权裁决：同一状态有两个 source-backed 源 = 架构错，本体层禁止；必须合并时显式定义策略（取权威源 / 时间戳胜出 / 累加），不许隐含 | 动作是唯一写通道 + 六步流水线（第二篇）、写回所有权三态（第五篇） |
| 时序冲突 | 版本化快照 + 前置条件校验：读状态必须带"基于哪个版本"；动作的前置条件（guard）校验版本，版本变了 → 拒绝执行、重读重判（乐观锁语义） | 状态层（第十篇）、动作前置/后置条件与事务（第二篇） |
| 价值冲突 | 默认升级人：价值冲突没有技术解，只有业务解——触发时 AI 把冲突显性抛给负责人，逼问清单 + 人拍板 → 沉淀为新规则 → 回到"判定冲突"的优先级机制 | 人永远不让渡的决策（第四篇）、实战回填（第五篇） |
三条总纪律
- 冲突显性化是前提：不声明管辖域的链不许建——"我可能碰到谁"是建链时的必答问题，答不出 = 链还没想清楚
- AI 不自己挑赢家：冲突触发时 AI 的职责是把冲突抛出来（双方规则 + 各自依据），不是选一条执行——裁决权默认在人，除非该冲突类型已被显式授权自动仲裁
- 每次仲裁都是一次决策：必须走动作 + 审计留痕（决策血缘）——冲突是决策血缘最肥的矿：被逼出来的新规则，正是回填池里最值钱的条目
一句话：第九节教树怎么长，第十节教交叉处怎么裁——管辖域声明防患，优先级/所有权/版本校验/升级人四种机制对症，仲裁结果一律落成规则入库。
本篇结论（立论）
- 本体论的价值单位是决策，落脚点是决策链，不是对象、不是全量建模
- 选链三标准：高频 / 昂贵 / 依赖多人判断——缺一不可，三者共同保证复利、价值、不可替代
- 数字孪生是陷阱：没人看、维护爆炸、无法验证、收益不集中——全量建模必然失败
- 最小闭环是方法：触发→理解→建议→动作，跑通闭环才算成功，半截就是聊天助手
- 验收标准固定：AI 能理解状态、识别影响对象、权限内推动动作 = 成功；答案还要人复制到群里确认 = 失败
- 含糊问题清单是建模起点：建模完成 ≠ 图画完了，而是"过去含糊的问题全部有了可判定答案"——每一条答不出的问题就是业务隐性风险
- 五层全通才算通：上下文自动注入 / 查询走对象 / 逻辑走函数 / 行动回写 / 治理拦截——决策链的运行时剖面，缺一层 AI 就退回聊天助手
- 扩展像树生长：从最痛到相邻，共享对象/数据优先，不铺森林
- 多链要会裁冲突：判定冲突 = 管辖域声明 + 规则优先级（改优先级走 PR、人拍板）；写冲突 = 唯一写通道 + 写回所有权裁决；时序冲突 = 版本快照 + 前置条件校验；价值冲突 = 默认升级人。冲突不裁就下沉到代码，本体白建
一句话立论：决策链理论回答"本体论建在哪"——建在最高频、最昂贵、最依赖多人判断的那条链上，先把含糊问题逼成可判定规则，跑通闭环，再沿共享对象生长；链多了还要会裁链间冲突——冲突显性化、仲裁落规则，多链才不会退化成补丁堆。
下一篇预告：人机协作理论——ONTAO 的灵魂（AI 能力光谱与权限四层）