一句话看懂：InfoQ 刊发了一篇来自 vivo 工程师的 KDC 理论补篇，探讨 Agent 不能只“会推理”，还必须把判断、授权和行动变成可恢复、可审计的软件事实，否则刷新页面或重启进程就可能丢失现场甚至重复退款。
事件核心：发生了什么
这篇文章是 vivo 肖博主导的“知识驱动计算（KDC）”系列第六篇，由作者与 ChatGPT（GPT-5.5）协作完成。前五篇已建立从 Reality 到 Feedback 的理论闭环，这篇不再增加新概念，而是聚焦一个具体工程缺口：Agent 在执行循环（Thought → Action → Observation）之后，如何让目标、审批、执行和产物在页面刷新、断线重连、进程重启后仍然保持一致。
文章用退款场景举例：Agent 判断订单可退并弹出确认提示，但用户未点击时页面刷新，审批状态丢失；更严重的是，退款请求已提交给支付渠道，后端在写完成状态前重启，恢复后可能重复调用退款接口。作者由此区分了“领域现实”“业务判断事实”和“软件运行事实”三个层次，并提出“业务因果链”与“运行事实链”的双链结构，通过 runId、reasoningObjectId、toolCallId 等稳定身份将两条链连接。文章还借鉴了 Anthropic 的 Managed Agents 实践，主张将 Session（持久化运行记录）、Harness（循环与控制逻辑）和执行环境解耦，并定义了 Resume Contract、Progress Contract、Evaluation Contract 三种交接模板。
为什么重要
当前行业对 Agent 的讨论多停留在“模型会不会调用工具”的层面，但生产环境的真实故障往往来自状态管理。这篇文章把问题从“模型能力”拉回“软件工程”：如果运行事实不能被持久化和恢复，再准确的推理也会在重启后变成不可追责的黑洞。它与 Anthropic Managed Agents、Durable Execution、12-Factor Agents 等公开实践形成互文，说明行业正在从“验证单次执行”转向“构建可恢复的 Agent 运行时”。对 KDC 理论本身，这是从概念框架走向工程落地的关键一步——不新增术语，而是回答“运行现场如何连接到业务判断”。
对用户/开发者/创作者的影响
对开发者而言，这篇文章提供了可操作的工程清单：需要独立持久化运行状态，而不是从聊天文本推断审批是否有效；需要为每次推理、工具调用和审批分配稳定身份；需要明确 Harness 与执行环境的生命周期边界。对使用 AI 客服或自动化流程的企业，这意味着“Agent 说可以做”和“系统真的可靠完成”之间还有一层必须投入的工程成本——否则可能面临重复支付、无法追责等现实风险。对 AI 应用的产品经理，它提示了一个容易被忽视的设计原则：UI 显示“已完成”不等于业务目标已实现，界面状态必须与后端运行事实对齐。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
目前公开信息显示，KDC 仍处于开放研究阶段，尚未发布完整实现或开源代码。值得观察的是：vivo 团队是否会将该框架落地到具体业务场景；Anthropic 等厂商的 Managed Agents 实践是否会进一步统一 Session 与 State 的标准定义；以及 Resume Contract 这类模板能否在社区中形成事实标准，被主流 Agent 框架（如 LangChain、AutoGen）采纳。此外，如何用 Evaluation Contract 验证“恢复后的行动是否仍然符合业务目标”，也会是后续讨论的焦点。
来源：InfoQ CN
