一次 Tool 调用返回 success，业务行动却可能是错的。vivo 肖博在知识驱动计算（KDC）系列第三篇中提出：调用成功≠判断正确，判断正确≠已获行动授权，并给出区分 Tool、Skill、Capability 的三层治理架构，让 Agent 从"万能容器"变为"可治理的协调者"。
传统软件中，一次退款操作被固化在代码路径里：用户点击按钮、二次确认、后端校验、风控判定、事务执行。因果链写在程序中。
Agent 系统改变了这一点。模型在运行时解释目标、组合上下文、选择工具，同一句"帮我看看能不能退"既可能是咨询，也可能是退款意向。选择不再来自预先写死的代码路径。
KDC 认为，一次受治理的 AI 行动不应只留下 Tool 调用记录，而应形成一条完整的因果链：
如何阅读：推理对象位于"知识与证据"和"能力选择"之间，充当上游因果锚点。它让审计系统知道：这次行动不是因为模型"想调用"，而是因为系统识别了目标、引用了知识、评估了风险，并形成了行动建议。
一个诚实的注脚：低风险只读查询未必需要完整链路。但退款、支付、权限变更、不可逆操作——行动影响越大，判断责任越应显式化。
用户对售后 Agent 说："帮我看看这笔订单现在能不能退？"Agent 查询了订单状态，检索了退款政策，确认商品未发货，随后调用 refund_order，接口返回 success。
但用户只是在咨询条件，并没有授权发起退款。
KDC 指出，推理对象至少应区分两个结论：事实判断（订单满足退款条件）与行动授权（用户明确要求发起退款）。二者不能因为语言上相近就被合并。
Agent 常被当作万能主体，同时负责理解目标、选择工具、执行行动、生成审计——一旦出错，结论只能是"Agent 做错了"，真正原因却无法定位。
KDC 主张将执行能力拆分为三个工程层次：
最小可执行入口，描述名称、参数和返回结果。如 get_order_status、refund_order。可被调用，但不代表适合在任何上下文中被模型调用。
围绕业务目标组织多个步骤，包含前置条件、编排逻辑、风险边界、失败降级。介于固定工作流与完全自由规划之间。
带治理语义的执行抽象：表达能力身份、业务语义、权限、风险等级、Owner、前置条件、人工确认要求、审计策略。关键边界不能只靠 Prompt 约束，必须提升为系统机制。
如何阅读：三层架构将"执行"与"治理"解耦。Tool 解决能力有无，Skill 解决效率与复用，Capability 解决安全与合规。三者缺一不可。
推理对象（Reasoning Object）是 KDC 提出的核心工程概念——它不是 Prompt，不是 Trace，也不是完整 Chain-of-Thought，而是外部可审计的判断结构。
它让系统可以检查：判断是否具备行动资格。
对于一次高影响判断，推理对象至少需要表达以下 6 个维度：
如何阅读：推理对象的价值不在于让模型更会解释，而在于让控制平面有机会在行动前检查"前置条件是否满足"。例如，将任务类型标记为"资格咨询"而非"退款执行"，系统即可阻止越权调用。
KDC 建议团队用一条真实的高风险调用记录，对照检查四类缺口。这四类缺口决定了系统能否回答"为什么做、谁允许、依据什么、结果如何"。
如果答案仍然只能从聊天记录、Prompt 和多份日志中人工拼接，说明行动审计链尚未成为稳定工程能力。
如何阅读：四类缺口对应审计链的四个环节——因果（溯源）、语义（理解）、治理（控制）、反馈（验证）。每填补一类缺口，系统就往"可治理的 AI 行动"前进一步。
让模型调用 Tool 已不再困难。真正困难的是把运行时判断、业务风险和执行权限放进同一条可治理链路。企业 AI 的关键不是会调用，而是知道何时不该调用。
选择一条已有高风险 AI 行动记录（退款、权限变更、审批提交），尝试还原完整的因果链：目标→知识→推理→能力选择→策略→执行→反馈。然后对照四类缺口，形成一份最小 AI Action Record。
KDC 理论目前处于开放研究阶段，本文为系列第三篇，前两篇分别讨论领域现实与知识工程。