从现实到反馈：KDC 完整工程模型全景

作者：vivo 肖博 AI 合作者：ChatGPT（GPT-5.5） 创作模式：Human-led, AI-collaborated 责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。 研究说明：知识驱动计算（Knowledge-driven Computing, KDC）是我们正在提出和持续打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。前四篇分别从 Reality、Knowledge、Reasoning、Skill、Capability、Memory 和 Feedback 展开。这一篇不再逐个解释概念，而是回答最后一个问题：它们如何组成一套完整、可审计、可治理、可渐进采用的软件工程模型？摘要：KDC 试图把领域现实、数字表示、知识、记忆、推理、技能、能力、行动和反馈组织成一条连续的业务因果链。本文给出 Reality-to-Feedback 闭环以及对象化、运行时化、治理化三层工程模型，同时区分已验证实践、理论推导和开放问题，说明企业如何从一个高影响业务闭环开始渐进采用。KDC系列文章： 《软件从现实开始：知识驱动计算（KDC）的 Reality First 主张》 " 《软件不是文件：KDC 的知识工程主张》 " 《调用成功不等于判断正确：KDC 的行动治理主张》 " 《保存历史不等于形成记忆：KDC 的长期运行主张》 " 《KDC 全景：从现实到反馈的完整工程模型》 "（本文） 《如何把 Agent 的判断与行动变成可恢复的软件事实 | KDC 工程补篇》 " 在前四篇贯穿的退款案例中，我们已经得到四份产物： 一张 Reality Map，说明系统面对哪些现实对象、状态、关系和反馈一张 Knowledge Card，说明当前退款规则来自哪里、为什么可信、适用于什么边界一份 AI Action Record，说明 Agent 为什么建议退款、策略如何判定、用户是否确认一份 Feedback Contract，说明接口成功之后，什么现实结果才算退款真正完成 每份产物都解决了一个问题，却没有任何一份能够单独解释完整业务。 Reality Map 不会自动告诉 Agent 应引用哪条政策。Knowledge Card 不会自动形成退款判断。AI Action Record 不能替代实际执行。Feedback Contract 也只有在能够追溯到原目标和行动时才有意义。 当它们被放到同一条因果链上时，KDC 的完整轮廓才出现： 系统面对什么现实 -> 如何表示和理解现实 -> 依据什么形成判断 -> 如何围绕目标组织行动 -> 怎样在治理约束下影响现实 -> 如何用现实反馈修正系统 KDC 的价值不在于提出几个孤立名词，而在于尝试把这条链路变成可以被设计、运行、审计和演化的软件工程闭环。 KDC 要解决的不是所有软件问题 在组装完整模型之前，需要先说明它的适用范围。 KDC 不是操作系统、数据库、编译器、网络协议或模型训练理论。它依赖这些数字基础设施，却不试图重新定义它们。 KDC 也不是所有应用软件的强制架构。如果一个程序只执行确定转换、固定规则和低风险 API 调用，不需要模型理解动态上下文，不涉及知识演化，也不会影响重要现实状态，那么传统代码、数据模型、接口契约、测试和监控已经可以很好地解决问题。 KDC 更关注这样一类系统： 业务语义密集，简单字段不足以表达全部条件上下文会随用户、时间、项目和现实状态变化模型会在运行时解释材料并形成判断系统需要根据目标选择 Skill 或 Capability行动可能影响订单、资金、权限、审批、通知或其他重要现实状态团队需要知道判断依据、行动原因和责任边界行动结果必须反馈并影响未来知识、记忆或治理 企业知识助手如果只做低风险文档问答，可能只需要来源和引用增强。当它开始生成审批建议、创建任务、发送通知或修改业务状态时，KDC 关注的完整链路才逐步变得必要。 因此，采用 KDC 不是二元选择。团队可以只补齐当前风险最高的一段，而不是一次性建设全部对象和运行时。 一条从 Reality 到 Feedback 的完整闭环 KDC 当前用下面这条链路组织核心概念： flowchart LR R[“Reality 领域现实“] --> RM[“Reality Model 现实模型“] RM --> RP[“Representation 数字表示“] RP --> K[“Knowledge“] RP --> M[“Memory“] K --> Q[“Reasoning“] M --> Q Q --> S[“Skill“] S --> C[“Capability“] C --> A[“Action“] A --> F[“Feedback“] F -.->|持续校验与修正| R 图 5：KDC Reality-to-Feedback 业务闭环 这不是一条只能从左到右执行一次的流水线，而是一张因果地图。 Reality 是最终参照物 领域现实定义系统在职责范围内试图观察、建模、预测或影响的对象、状态、关系和动态规律。 退款系统面对的现实包括用户诉求、订单承诺、原支付、资金退回和到账结果。数据库状态很重要，但它不是最终参照物。接口成功也不能单独证明用户已经收到资金。 Reality Model 决定系统看见什么 现实模型选择哪些现实进入系统，如何划分对象和状态，怎样表达关系，又用什么反馈判断变化已经发生。 同一个退款过程可以被建模成“处理中、成功、失败”，也可以区分“渠道受理、清算中、银行处理中、用户到账”。模型粒度应与系统职责和现实承诺匹配。 Representation 是现实的数字编码 数据、文档、API、事件、日志、图谱、Embedding、Prompt 和模型上下文都是表示。它们让现实能够进入数字系统，却不自动等于现实或知识。 Knowledge 提供可复用依据 表示经过解释、验证并形成可复用认知成果后，才能在 KDC 意义上成为知识。 知识需要来源、证据、适用边界、版本和成熟度。当前退款政策与订单事实可以支撑判断。一份相似度更高但已经过期的旧政策不能以相同资格进入推理。 Memory 让历史在受治理条件下影响未来 记忆保存知识、经验、决策、反馈和演化轨迹。它不是把所有历史对话放入向量库，而是决定哪段历史在什么条件下仍可影响当前判断。 上次用户选择退款可以解释过去，却不能自动成为“用户永远偏好直接退款”的稳定画像。 Reasoning 连接依据与结论 推理对象记录目标、上下文、知识和记忆引用、证据、关键判断、风险、结论和行动建议。 它不要求暴露完整 Chain-of-Thought，而是提供足以审计高影响判断的外部结构。比如，“满足退款条件”和“用户已经授权退款”必须成为两个可区分判断。 Skill 组织目标级复用 Skill 把业务目标、前置条件、参与能力、编排逻辑、风险边界和失败策略组织起来。 “处理退款”不是一个 Tool，而是一项可能包含目标澄清、规则判断、用户确认、执行、跟踪和异常处理的目标级能力组合。 Capability 是受治理的行动入口 Capability 把底层 Tool 或服务包