调用成功不等于判断正确：KDC 的行动治理主张

作者：vivo 肖博 AI 合作者：ChatGPT（GPT-5.5） 创作模式：Human-led, AI-collaborated 责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。 研究说明：知识驱动计算（Knowledge-driven Computing, KDC）是我们正在提出和持续打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。前两篇分别讨论了应用软件面对的领域现实，以及什么内容才可以作为知识进入系统。这一篇继续沿着同一个问题向前：当 AI 已经获得可靠知识，它如何把判断转化为现实行动？本文摘要：一次 Tool 调用即使执行成功，也不代表 Agent 做出了正确且获授权的业务行动。本文提出推理对象作为判断与行动之间的可追溯锚点，并区分 Tool、Skill、Capability 和治理基础设施的责任，让 Agent 保持动态协调能力，同时不再成为所有责任的容器。KDC系列文章： 《软件从现实开始：知识驱动计算（KDC）的 Reality First 主张》 " 《软件不是文件：KDC 的知识工程主张》 "《调用成功不等于判断正确：KDC 的行动治理主张》（本文） 继续说案例。 用户对售后 Agent 说： 帮我看看这笔订单现在能不能退？ Agent 查询了订单状态，检索了当前有效的退款政策，确认商品尚未发货，也没有使用活动权益。随后，它调用 refund_order，退款接口返回成功。 从执行日志看，一切正常： tool: refund_order order_id: 20260710001 result: success 但用户原本只是在咨询是否符合退款条件，并没有授权系统真正发起退款。 Tool 调用成功了，业务行动却是错的。 事故复盘时，团队很快能查到模型调用了哪个工具、传入了什么参数、接口返回了什么结果。真正难回答的是另一组问题： Agent 把用户目标理解成了什么？它为什么认为现在应该执行，而不是只回答条件？哪些知识支持“可以退款”？“可以退款”为什么被进一步解释成“已经获得用户授权退款”？这次行动属于什么风险等级？为什么没有要求用户最终确认？哪个系统责任方允许了这次调用？ 调用日志记录了“发生了什么”，却没有完整记录“为什么发生”。 这正是 AI 系统从回答问题走向参与行动后，软件工程需要补上的关键责任。 传统调用链中，很多理由已经写在代码里 在传统应用软件中，一次退款通常位于明确的程序路径中。 用户点击退款按钮，页面要求二次确认，后端校验订单状态和权限，风控规则判断是否需要人工介入，事务服务执行退款，失败后进入重试、回滚或补偿。开发者提前决定了什么时候调用、谁能调用、调用前检查什么、失败后怎么办。 因此，传统调用日志即使只记录接口、参数和结果，也能通过代码版本、工作流和规则配置还原相当一部分调用原因。行动路径的因果关系主要固化在程序中。 Agent 系统改变了这一点。模型会在运行时解释用户目标、组合上下文、选择工具，并根据自然语言判断是否行动。同一句“帮我看看能不能退”，既可能是规则咨询，也可能是退款意向，还可能只是用户在比较方案。选择不再完全来自预先写死的代码路径。 当重要行动的选择发生在运行时，调用原因也需要成为可管理的运行时工程对象。否则，系统拥有越来越丰富的执行能力，却只能用越来越贫乏的日志解释行动。 这不是要求模型把全部内部思维公开出来，而是要求高影响行动留下足够的外部判断依据。 推理对象：把可治理的判断结构外部化 KDC 把这种工程上可引用、可审计的判断结构称为推理对象（Reasoning Object）。 推理对象不是 Prompt。Prompt 是触发模型工作的输入组织形式，它可以包含目标、上下文和指令，却不一定记录最终引用了什么证据、形成了什么结论、评估了什么风险以及建议了什么行动。 推理对象也不是普通 Trace。Trace 擅长记录请求经过哪些组件、耗时多少、在哪里失败。推理对象关注的是这次判断的业务语义和因果依据。 推理对象更不等于要求保存完整 Chain-of-Thought。模型内部可能存在不可得、不稳定、不适合暴露或没有治理价值的细节。KDC 关心的是外部可审计结构，而不是逐字保存模型的内部思维过程。 对于一次高影响判断，推理对象至少需要表达： 目标：这次任务究竟要回答或完成什么上下文：用户、订单、时间、会话和系统状态知识引用：使用了哪些知识对象及其版本记忆引用：哪些历史偏好、经验或先例影响了判断证据：哪些事实、文档、状态或人工确认支持结论关键判断：从目标到结论经历了哪些可外部检查的节点结论：这是事实判断、建议、计划还是行动请求不确定性：证据是否充分，是否需要补充信息风险：结论错误或行动错误会造成什么影响行动建议：是否建议调用某项能力反馈：后续现实结果是否验证或推翻了原判断 回到退款案例，一个合格的外部判断结构至少应该区分两个结论： 事实判断：该订单当前满足退款条件 行动授权：用户是否明确要求立即发起退款 第一项可以由订单事实和退款政策支持。第二项需要来自用户明确确认。二者不能因为语言上相近就被合并。 如果推理对象把当前任务类型标记为“资格咨询”，把结论标记为“可以退款”，同时把“用户最终确认”列为能力前置条件，那么控制机制就有机会阻止 Agent 从咨询直接跨越到执行。 推理对象的价值不在于让模型显得更会解释，而在于让系统可以检查判断是否具备行动资格。 从判断到行动，需要一个可追溯的因果锚点 一次受治理的 AI 行动不应该只留下 Tool 调用记录。它至少需要形成下面这条链路： 业务目标 -> 知识与证据 -> 推理对象 -> 能力选择建议 -> 策略与权限判定 -> 能力调用 -> 执行结果 -> 现实反馈 推理对象位于知识和行动之间，承担上游因果锚点的作用。 它让审计系统知道：这次退款不是因为模型“想调用”某个 Tool，而是因为系统识别了某个目标，引用了指定版本的退款规则，读取了订单事实，评估了风险，并形成了行动建议。 它也让拒绝成为正常结果。如果证据不足、目标含糊、用户没有确认或知识存在冲突，推理对象可以明确表达“当前不能行动”。治理系统不需要等待 Tool 失败，才发现前提并不成立。 高风险能力是否必须绑定推理对象，可以按场景分级。低风险只读查询未必需要完整结构。退款、支付、权限变更、外部通知、审批提交和不可逆操作，则至少应保留等价的目标、依据、风险和授权记录。 KDC 的主张不是把每个模型回答都变成重型审计文档，而是让行动影响越大，判断责任越显式。 推理运行时：管理判断，而不是管理 Prompt 模板 推理对象说明一次判断应留下什么，推理运行时（Reasoning Runtime）则说明这些对象如何在系统运行过程中被创建、使用和更新。 它至少承担几类职责：识别目标类型，装配来自知识与记忆的上下文，绑定证据，创建推理对象，表达不确定性和风险，提出能力选择建议，并在行动后把反馈重新关联到原判断。 模型可以参与其中，但推理运行时不等于模型本身。目标分类可以由规则和模型共同完成，证据完整性可以由系统校验，风险等级可以由策略决定，用户确认可以来自交互状态，反馈更新也可能发