调用成功不等于判断正确：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 系列文章：

1. 《软件从现实开始：知识驱动计算（KDC）的 Reality First 主张》

2. 《软件不是文件：KDC 的知识工程主张》

3. 《调用成功不等于判断正确：KDC 的行动治理主张》（本文）

继续说案例。

用户对售后 Agent 说：

帮我看看这笔订单现在能不能退？

Agent 查询了订单状态，检索了当前有效的退款政策，确认商品尚未发货，也没有使用活动权益。随后，它调用 refund_order，退款接口返回成功。

从执行日志看，一切正常：

tool: refund_orderorder_id: 20260710001result: 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）则说明这些对象如何在系统运行过程中被创建、使用和更新。

它至少承担几类职责：识别目标类型，装配来自知识与记忆的上下文，绑定证据，创建推理对象，表达不确定性和风险，提出能力选择建议，并在行动后把反馈重新关联到原判断。

模型可以参与其中，但推理运行时不等于模型本身。目标分类可以由规则和模型共同完成，证据完整性可以由系统校验，风险等级可以由策略决定，用户确认可以来自交互状态，反馈更新也可能发生在模型调用结束很久之后。

推理运行时也不等于 Prompt 编排器。Prompt 可以组织一次模型输入，推理运行时还要管理知识版本、对象身份、风险状态、行动建议和后续反馈。

在早期系统中，这些职责不需要被部署成独立平台。它们可以先由应用模块、结构化记录和策略校验承担。重要的是让判断生命周期有明确责任方，而不是先创造一个名为“推理运行时”的新服务。

推理运行时负责形成和管理判断，但它本身不等于执行系统。它可以提出“建议发起退款”，却还不能说明这项建议应该通过什么入口执行、是否属于一个完整业务目标，以及在什么治理条件下才允许执行。

这也是 Tool、Skill 和 Capability 需要被区分的原因。它们都可能出现在一次 Agent 任务中，但分别位于不同的工程层次：

• Tool 解决一个具体操作如何执行

• Skill 解决多个操作如何围绕业务目标组织

• Capability 解决行动在什么语义、权限和风险边界内可以执行

如果不做这层区分，推理对象提出的“行动建议”就会直接落到某个 Tool 上，业务目标、执行编排和治理责任也会混在一起。

从判断到行动，还需要区分三个执行层次

下面继续使用退款场景，分别说明这三个层次承担的工程责任。

Tool：最小可执行入口

Tool 解决“系统能执行什么”。举个例子：

• get_order_status 查询订单状态

• check_refund_eligibility 检查退款条件

• refund_order 发起退款

• send_notification 发送通知

Tool 通常描述名称、参数和返回结果。它可以由 API、函数、脚本、MCP Tool 或其他执行机制实现。

但 Tool 可被调用，不代表它适合在任何上下文中被模型调用。

Skill：围绕业务目标组织能力

Skill 解决“如何围绕一个目标组织多个步骤”。“处理订单退款”不是一个单独 Tool，而可能包含目标澄清、订单查询、政策检索、资格判断、用户确认、退款执行、状态跟踪和异常转人工。

一个可复用 Skill 应表达：

• 业务目标

• 前置条件

• 所需上下文

• 参与能力

• 编排逻辑

• 风险边界

• 失败和降级策略

• 审计要求

Skill 位于固定工作流和完全自由规划之间。它不要求每一步都写死，也不允许 Agent 每次从零决定全部边界。

Capability：带治理语义的执行抽象

Capability 解决“某项行动在什么条件下可以被理解、选择、调用和治理”。

refund_order 可以是底层 Tool。“发起订单退款能力”则还需要表达：

• 能力身份和业务语义

• 输入输出和影响的现实状态

• 调用主体和权限

• 风险等级

• Owner 和责任域

• 版本和生命周期

• 前置条件与后置不变量

• 人工确认要求

• 审计和可观测策略

• 失败后的回滚或补偿方式

因此可以把三者简化为：

Tool：如何执行Skill：如何围绕目标组织执行Capability：如何在治理边界内执行

复制代码

一个 Tool 可以成为 Capability 的执行入口，一个 Skill 也可以被作为较高层能力暴露，但前提是它们被放入明确的语义、权限、风险和审计边界中。

为什么 Capability 不能只靠 Prompt 约束

团队常在系统 Prompt 中写下这样的规则：

执行退款前必须获得用户确认。

这是一条有价值的模型指令，却不应该是高风险行动的唯一防线。

Prompt 会被上下文影响，模型可能误解自然语言，指令也可能在复杂任务中被遗漏。如果底层 refund_order 对模型完全开放，那么治理责任实际上被压在一次概率性判断上。

能力治理需要把关键边界提升为系统机制：

• 权限：当前主体是否有权发起退款

• 风险等级：金额、订单状态和场景是否需要更严格控制

• 策略判定：知识、证据和前置条件是否完整

• HITL：是否需要用户确认或人工审批

• 限流与熔断：异常调用是否应被抑制或中止

• 事务与补偿：失败时如何避免半完成状态

• 审计：谁基于什么判断发起了行动

• 可观测：执行成功率、策略拒绝、人工介入和现实结果如何

• 生命周期：能力是否处于实验、灰度、稳定或退役状态

在退款案例中，控制平面可以把“存在明确用户确认”设置为事务型退款能力的必要条件。即使 Agent 推理错误、Skill 编排遗漏，能力也不应进入执行。

这里的治理不是为了让所有调用变慢，而是按现实影响分级。查询退款规则与真正发起退款不应承担同样的控制成本。只读、可逆、低影响的能力可以轻量治理。写操作、资金、权限和不可逆行动需要更严格的证据与确认。

Agent 的正确位置：协调者，而不是所有责任的容器

如果把 Agent 当作万能主体，它会同时负责理解目标、保存全部上下文、形成判断、选择 Tool、执行行动、处理失败和生成审计。系统看似简单，责任却无法拆分。

一旦出错，团队只能得到“Agent 做错了”这样的结论。目标解释、知识版本、记忆使用、推理路径、技能选择、能力实现、治理策略和外部系统中的任何一层，都可能是真正原因。

KDC 因此不把 Agent 作为理论起点，而把它放在对象、运行时和治理机制之上。Agent 可以承担：

• 解释用户目标

• 请求和组织上下文

• 协调推理过程

• 选择可复用 Skill

• 提出能力调用建议

• 处理执行反馈

但高影响判断应形成推理对象或等价审计依据，高风险行动应进入能力治理。Agent 可以建议行动，却不能因为自己完成了推理，就自动获得执行权限。

这也避免另一个极端：把 Agent 退化成固定脚本。目标解释和路径选择仍然可以动态发生，只是关键责任不再全部隐藏在 Agent 的临时上下文里。

sequenceDiagram    participant U as 用户 / 业务目标    participant A as Agent    participant R as 推理运行时    participant P as 能力控制平面    participant X as 能力运行时    participant W as 领域现实    U->>A: 提出目标    A->>R: 组织上下文、选择 Skill    R-->>A: 推理对象与行动建议    A->>P: 申请调用 Capability    P->>P: 检查权限、风险、前置条件    alt 允许执行        P->>X: 授权请求        X->>W: 通过 Tool 执行        W-->>X: 现实结果与反馈        X-->>R: 执行结果与反馈    else 需要确认或拒绝        P-->>A: 请求人工确认或拒绝    end

复制代码

图 3：从业务目标到受治理行动的责任链

把 Agent 放在对象、运行时和治理机制之上，并不意味着 KDC 要另起炉灶。恰恰相反，Agent 的责任被拆开之后，必须继续回答一个工程问题：这些责任分别由哪些已有机制承载，它们之间又如何通过同一条业务因果链连接起来？下一节因此不再讨论 Agent 应该采用什么单一形态，而是把它与现有的协议、编排框架和治理基础设施逐一对照。

与 MCP、Agent Framework 和治理基础设施的关系

KDC 不需要重新发明模型连接协议、Agent 编排框架、身份系统或网关。

MCP 和 Tool-use 解决模型如何发现并调用资源、Prompt 和工具。Agent Framework 解决目标、任务、执行循环和多 Agent 协作如何组织。API Gateway 处理认证、路由、限流和流量治理。IAM 与 Policy Engine 处理主体、资源、动作和策略判定。工作流与审批系统承载稳定流程和人工节点。

这些能力都是 KDC 可以复用的工程基础。

KDC 补充的问题是如何把它们连接到同一条业务因果链：MCP Tool 对应什么业务能力，Agent 为什么建议调用，推理引用了哪些知识，当前风险是什么，Policy Engine 基于哪些上下文判定，执行结果又如何回到现实反馈。

能力控制平面是对这组治理职责的理论抽象，不是某个具体产品名称。它可以复用 API Gateway、IAM、Policy Engine、风控、审批和可观测系统实现。

实践：还原一条高风险 AI 行动审计链

选择一个已经存在的高影响动作，例如退款、支付确认、权限变更、审批提交、创建订单或对外发送通知。

不要先设计新平台。先拿一条真实调用记录，尝试还原：

业务目标  -> 知识与记忆依据  -> 可审计判断与风险  -> Skill 和能力选择  -> 权限与策略判定  -> 用户确认或 HITL  -> 执行结果  -> 现实反馈

复制代码

然后形成一份最小 AI Action Record：

完成记录后，重点寻找四类缺口：

1. 因果缺口：只能看到 Tool 调用，无法追溯目标和依据

2. 语义缺口：Tool 有参数，却没有业务语义、风险和 Owner

3. 治理缺口：关键边界只写在 Prompt，没有系统策略

4. 反馈缺口：接口成功后，没有验证现实结果

这份记录不要求所有系统使用相同字段，也不要求每次只读查询都保存完整结构。它的作用是验证：对于重要行动，系统是否能够回答“为什么做、谁允许、依据什么、结果如何”。

如果答案仍然只能从聊天记录、Prompt 和多份日志中人工拼接，说明行动审计链尚未成为稳定工程能力。

企业 AI 的关键不是会调用，而是知道何时不该调用

让模型调用 Tool，已经不再是最困难的问题。真正困难的是把运行时判断、业务风险和执行权限放进同一条可治理链路。

推理对象让系统能够表达“为什么这样判断”。Skill 让目标级流程可以复用又保留动态空间。Capability 让行动拥有语义、权限、风险、Owner 和生命周期。控制平面让关键边界不只依赖模型自律。

因此：

调用成功 ≠ 判断正确判断正确 ≠ 已获行动授权接口返回成功 ≠ 现实目标已经实现

复制代码

企业级 AI 的价值不是让 Agent 尽可能多地完成动作，而是让它在该行动时能够行动，在不确定、越权或证据不足时能够停下来，并且让每一次重要行动都可以被解释、审计和追责。

但即使一次推理和一次行动都正确，系统仍然不能算长期可靠。现实会变化，知识会过期，用户会纠正系统，能力也会失败。下一篇将继续讨论：历史与反馈如何进入记忆，系统又如何避免把错误经验不断放大。

理论边界与开放问题

本文对推理对象、能力对象、能力运行时和能力控制平面的描述来自 KDC 阶段的理论推导。推理对象、完整运行时责任边界和自主 Agent 参考架构仍主要是 Derived 或 Derived + Hypothesis。

版权声明： 本文采用 CC BY-NC-ND 4.0（署名-非商业性使用-禁止演绎） 许可协议。转载请注明出处。