如何把 Agent 的判断与行动变成可恢复的软件事实 | KDC 工程补篇

作者：vivo 肖博 AI 合作者：ChatGPT（GPT-5.5） 创作模式：Human-led, AI-collaborated 责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。 研究说明：知识驱动计算（Knowledge-driven Computing, KDC）是我们正在提出和持续打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。前五篇建立了从 Reality 到 Feedback 的理论闭环。这篇补篇不增加新的 KDC 核心概念，而是讨论其中一段更具体的工程问题：推理、授权和行动如何变成可恢复、可控制、可审计的软件运行事实。本文摘要：会推理、会调用 Tool，只能说明 Agent 能够完成一次执行循环。要进入真实业务，系统还必须让目标、判断、审批、执行、产物和反馈拥有稳定状态，并在刷新、重连、进程重启和人工介入后继续保持一致。本文区分领域现实、业务判断事实和软件运行事实，提出业务因果链与运行事实链的双链结构；进一步将 Session、Harness 与执行环境解耦，区分 Session、Context、State、Memory 和 Knowledge，并以 Resume Contract、Progress Contract 与 Evaluation Contract 说明一次 Agent 运行如何被恢复、交接、验证和持续演进。KDC系列文章： 《软件从现实开始：知识驱动计算（KDC）的 Reality First 主张》 " 《软件不是文件：KDC 的知识工程主张》 " 《调用成功不等于判断正确：KDC 的行动治理主张》 " 《保存历史不等于形成记忆：KDC 的长期运行主张》 " 《KDC 全景：从现实到反馈的完整工程模型》 "《如何把 Agent 的判断与行动变成可恢复的软件事实 | KDC 工程补篇》（本文） 还是从退款这个具体场景开始。 用户问售后 Agent： 帮我看看这笔订单能不能退。如果可以，就直接帮我处理。 Agent 查询订单，引用当前退款政策，判断订单符合条件，然后准备调用退款能力。由于退款会改变订单和资金状态，系统要求用户确认。页面显示了一条审批提示： 订单符合退款条件。是否确认发起退款？ 用户还没有点击确认，页面突然刷新。 刷新之后，审批提示消失了。聊天记录里还能看到 Agent 说过“准备退款”，但前端不知道审批是否仍然有效，后端不知道用户是否已经做过决定，能力运行时也不知道应该继续、暂停还是取消。 更危险的情况是，退款请求已经提交给支付渠道，但后端在写入本地完成状态之前重启。恢复后，系统只看到“任务尚未完成”，于是再次调用退款接口。 这一次，问题不在知识是否可靠，也不在 Agent 是否理解了用户目标。判断和授权规则可能都是正确的，系统仍然可能因为缺少稳定运行事实而丢失现场、重复执行或无法追责。 这说明，从“Agent 做出了正确判断”到“系统可靠地完成了行动”之间，还有一层不能省略的工程结构。 会执行一次循环，不等于可以运行一个产品 ReAct " 可以把模型行为概括成一个循环： Thought -> Action -> Observation 模型根据当前上下文形成下一步，调用 Tool，读取结果，再继续判断。这个抽象很好地解释了模型如何在一次任务中交替推理和行动。 但产品系统面对的不是一段始终连续的模型调用。页面会刷新，连接会断开，进程会重启，Tool 会长时间运行，审批可能等待几个小时，外部系统可能已经完成操作但响应丢失，子 Agent 也可能在另一个执行环境中继续工作。 生产系统还需要回答： 当前是哪一次 Run、哪一个 Turn 在运行？模型已经提出了什么行动，行动是否得到授权？Tool 是尚未调用、正在执行、已经完成，还是结果未知？用户刷新页面后，原审批是否仍然有效？进程重启后，应该从哪里恢复？Artifact 和子 Agent 属于哪个目标、判断和行动？用户点击 Stop 时，究竟停止哪一次运行？外部行动是否已经发生，重试会不会造成重复影响？ 这些问题不能依靠模型“记住”，也不能让 UI 从聊天文本中猜测。它们必须成为系统可以持久化、引用和恢复的运行事实。 我们把承载这类责任的工程系统称为 Agent Harness，并提出通过共享 State Schema、Runtime Event、View 和 Control，把模型行为转化为可恢复、可控制、可追溯的产品事实。vivo 团队关于 从 ReAct 到 Agent Harness 的工程讨论 "，是本文继续追问状态归属、恢复边界和产品一致性的一个直接起点。 这个视角与 KDC 的对象化、运行时化和治理化高度契合。但在接入 KDC 之前，需要先澄清“事实”并不只有一个层次。 三种事实不能混在一起 在 Agent 系统中，至少存在三种需要分别管理的事实。 领域现实是应用软件的最终参照物。软件只能通过接口、事件、人工确认和其他表示间接观察它。 业务判断事实说明系统基于什么目标、知识和证据形成结论，又为什么建议某项行动。这里的“事实”不是说判断必然正确，而是说系统确实在特定上下文和依据下形成过这项判断。KDC 用推理对象或等价的 AI Action Record 表达这类责任。 软件运行事实则说明某次运行中已经发生了什么：Run 是否开始，审批是否挂起，Tool 是否执行，Artifact 是否创建，Checkpoint 位于哪里。 三者有关联，但不能互相替代： tool.call.completed 不等于 退款已经到账 pendingApproval = null 不等于 用户已经同意退款 页面显示“已完成” 不等于 业务目标已经实现 Runtime 可以权威地声明“这次 Tool Call 已经完成”，却不能仅凭这个运行事实证明用户已经收到资金。UI 可以显示审批条，却不能因为审批条消失就推断用户已经授权。 KDC 与 Agent Harness 在这里形成互补：Harness 让运行事实可信，KDC 继续追问这些运行事实对应什么业务判断和领域现实。 生产级 Agent 需要两条可以连接的链 KDC 的业务因果链关注系统为什么行动，以及行动是否实现现实目标： Reality -> Knowledge / Memory -> Reasoning -> Skill -> Capability -> Policy Decision -> Action -> Feedback -> Reality Agent 产品的运行事实链关注一次执行如何持续存在： Runtime Event -> State -> View -> Checkpoint -> Resume User Control -> Runtime Event 两条链不能各自独立。只保留业务因果链，系统可能解释得清楚却无法恢复。只保留运行事实链，系统可以恢复调用，却不知道行动是否具备业务资格，也不知道最终结果是否实现现实目标。 flowchart LR subgraph B[“业务因果链：为什么行动“] direction TB T[“业务目标“] --> K[“Knowled