从现实到反馈：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 系列文章：

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

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

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

4. 《保存历史不等于形成记忆：KDC 的长期运行主张》

5. 《KDC 全景：从现实到反馈的完整工程模型》（本文）

6. 《如何把 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<br/>领域现实“] --> RM[“Reality Model<br/>现实模型“]    RM --> RP[“Representation<br/>数字表示“]    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 或服务包装成具备身份、语义、权限、风险、Owner、版本、审计、可观测和生命周期的执行对象。

在 KDC 系统边界内，凡是需要被 AI 理解、选择、调用和治理的重要行动，都应通过能力对象表达。这里不声称世界上的所有变化都由 Capability 造成。用户、外部系统和自然事件同样会改变现实。

Action 作用于现实，Feedback 关闭闭环

能力运行时执行行动，现实结果再通过业务事件、外部状态、人工确认、用户反馈和对账结果进入系统。

反馈不是自动真值，也不应直接升级知识或强化记忆。它需要来源、关联、可信度和错误归因，然后由对应运行时决定更新什么。

Continuous Consistency 是长期方向

闭环的长期目标，是让系统能够观察领域现实与数字表示之间的偏差，并在知识过期、记忆失效、推理错误或行动失败时找到修正路径。

这里所说的“持续一致性”，首先是一种持续发现偏差并寻找修正路径的能力，而不是要求系统与现实始终保持绝对同步，也不是用一个已经固定的总分概括系统状态。偏差可能来自现实覆盖不足、现实映射错误、知识过期、知识漂移或验证缺失。围绕这些问题，Reality Coverage、Reality Mapping、Knowledge Freshness、Knowledge Drift 和 Consistency Verification 目前只是候选的度量方向，具体定义和组合方式仍需要在实践中验证。

KDC 有两张图：业务闭环与工程模型

上面的 Reality-to-Feedback 链路回答“业务因果如何流动”。真正构建系统时，还需要另一张图回答“由什么工程机制承担责任”。

KDC 当前把工程模型概括为三个层次：对象化、运行时化和治理化。

flowchart TB    I[“Reality / Reality Model / Representation“]    A[“Agent<br/>目标解释、上下文组织与协调“]    subgraph O[“对象化：让责任可以被引用“]        direction LR        O1[“Knowledge Object“] --- O2[“Memory Object“] --- O3[“Reasoning Object“] --- O4[“Skill / Capability Object“]    end    subgraph RUN[“运行时化：让对象真正运转“]        direction LR        R1[“知识运行时“] --- R2[“记忆运行时“] --- R3[“推理运行时“] --- R4[“能力运行时“]    end    subgraph G[“治理化：让边界成为系统机制“]        direction LR        G1[“来源、证据与成熟度“] --- G2[“生效、衰减与遗忘“] --- G3[“权限、风险与审计“] --- G4[“反馈可信度与错误归因“]    end    I --> O    O --> RUN    A -.-> RUN    G -.-> RUN    RUN --> X[“Action / Feedback“]    X -.-> I    E[“MCP、Agent Framework、IAM、Policy Engine、Workflow、Observability“] -.-> G    E -.-> RUN

图 6：KDC 对象、运行时与治理的工程责任结构

这三层不是三个必须独立部署的平台，而是三类工程责任。

第一层：对象化，让隐含责任可以被引用

传统 AI 应用常把关键内容放在 Prompt、会话上下文、文档片段、工具描述和日志中。这些内容可以工作，却缺少稳定身份和生命周期，难以跨任务引用和治理。

KDC 当前定义五类核心对象：

对象化的重点不是把所有内容转换成统一 JSON，而是给高价值责任稳定身份。

当退款政策更新时，系统应该知道哪些推理引用了旧版本。当能力发生事故时，系统应该知道哪些 Skill 和行动受影响。当用户纠正偏好时，系统应该找到相关记忆，而不是只能全文搜索聊天记录。

对象化让“依据了什么、记住了什么、如何判断、怎样组织目标、通过什么行动”从临时内容变成可追溯关系。

第二层：运行时化，让对象真正运转

只有对象定义，没有运行时职责，对象会退化成静态 Schema。

KDC 当前提出四类运行时：

知识运行时

负责从表示中解析、抽取、关联、验证和检索知识对象，处理来源、证据、冲突、版本和生命周期。

它可以使用 RAG、搜索、知识图谱和规则系统，但不等于其中任何一个。

记忆运行时

负责记忆形成、检索、强化、冲突、衰减、遗忘、迁移和归档。

它治理的是历史如何影响未来，而不是保存尽可能多的历史。

推理运行时

负责目标识别、上下文装配、证据绑定、推理对象创建、风险评估、能力选择建议和反馈更新。

它不是 Prompt 模板管理器，也不要求暴露模型内部全部思维。

能力运行时

负责能力发现、选择、调用、组合、结果反馈和失败处理，并在控制平面的策略约束下执行。

它不是一个裸 Tool Executor。授权、风险、版本、失败策略和现实反馈都属于执行边界的一部分。

运行时是逻辑责任，不必一开始对应四个独立服务。一个现有应用可以通过模块、事件、策略和数据结构承担其中部分职责，再根据规模和边界逐步拆分。

第三层：治理化，让行动边界成为系统机制

当 AI 只能生成文本时，错误主要影响回答质量。当 AI 可以退款、下单、变更权限和发送通知时，错误会进入现实。

治理层需要把以下责任从 Prompt 约定提升为系统机制：

• 能力注册、发现和版本

• 主体身份、权限和策略

• 风险分级和 HITL

• 前置条件、后置不变量和事务边界

• 限流、熔断、灰度、回滚和补偿

• Owner、生命周期和退役

• 运行时可观测和对象化审计链

• 现实反馈和错误归因

能力控制平面承载能力注册、授权、策略、审计、观测和生命周期控制。能力注册表保存能力身份、语义、Owner、风险、依赖和状态。能力治理决定什么条件下允许、拒绝、降级或转人工。

治理也不只发生在能力入口。知识权限、记忆访问、推理证据和反馈可信度同样需要边界。一个控制平面无法替代所有运行时治理，它只是行动治理中最集中的基础设施节点。

用一次退款任务组装完整模型

现在我们把前四篇的退款任务完整走一遍。

1. 识别现实目标

用户说：“帮我看看这笔订单现在能不能退？”

系统首先区分资格咨询和行动授权。当前目标是判断是否符合条件，不是立即退款。

Reality Map 告诉系统，退款涉及订单、原支付、活动权益、资金退回和到账反馈。“接口成功”不是最终现实结果。

2. 装配知识与记忆

知识运行时提供当前有效的退款政策、订单事实和活动权益规则，并保留版本、证据和适用边界。

记忆运行时可能返回上次退款经历，但同时标明：这是特定订单下的情景和行动结果，不足以证明用户当前仍偏好直接退款。

3. 形成推理对象

推理运行时记录：

• 目标是资格判断

• 当前政策版本为 v4.0

• 订单未发货且权益未核销

• 结论是符合退款条件

• 风险在于把咨询误解为授权

• 行动建议是向用户说明条件并请求明确确认

4. 选择 Skill

Agent 选择“订单退款处理”Skill。该 Skill 规定：先判断资格，再解释影响，用户确认后才进入事务型退款能力。高金额或异常订单转人工。

5. 提出能力调用建议

用户确认后，系统建议调用“发起订单退款能力”。能力对象声明其风险、权限、Owner、事务边界、审计策略和反馈要求。

6. 控制平面判定

控制平面检查调用主体、用户确认、推理对象、订单状态、知识版本、风险策略和能力生命周期。

条件满足时授权执行。缺少确认时拒绝并返回可解释原因。命中高风险规则时进入 HITL。

7. 能力运行时执行

能力运行时调用底层 Tool，处理事务、异常、重试或补偿，记录执行结果。Tool 返回成功只表示请求被受理，不直接把退款标记为现实完成。

8. 现实反馈进入系统

支付渠道状态、对账结果和用户确认进入 Feedback Contract。系统将反馈关联到原目标、推理对象、能力对象和策略判定。

如果退款到账，行动结果可以形成候选记忆。如果延迟来自渠道故障，更新能力质量和行动-结果记忆。如果旧政策导致错误判断，让知识降级或过期。如果 Agent 误解目标，修正推理策略。

这一过程说明，Agent 的价值不是自己承担所有责任，而是协调对象、运行时和治理机制完成一个可追溯任务。

KDC 如何与现有体系协同

KDC 不以替代现有理论和基础设施来证明自己。它更像一张组合地图：

KDC 的补充，是把这些局部机制连接到一条从现实、知识和判断到行动、治理和反馈的因果链。

这也是 KDC 当前最主要的原创主张：新颖性不在于发明 Knowledge、Agent、API 或治理，而在于把它们组织成一个面向 AI 应用软件的连续工程闭环。

这个原创性主张仍需要更多实践、外部审阅和反例检验。它不能因为概念链条连贯，就自动被视为已经成立的行业理论。

渐进采用：从一个业务闭环开始

KDC 最容易失败的采用方式，是先建设一个名义完整的“知识平台、记忆平台、推理平台和能力平台”，再去寻找业务场景。

更现实的路径是从一个高价值或高风险闭环开始。

第一步，建立 Reality Map

明确系统边界、现实对象、状态、关系、动态规律和成功反馈。优先识别内部状态与现实承诺之间的缺口。

第二步，识别关键 Representation 和 Knowledge

找出当前判断依赖的文档、数据、规则和事件。只对象化高价值、可复用或高风险知识，保留来源、证据、版本和成熟度。

第三步，外部化高影响判断

为高影响决策建立推理对象或等价审计依据。至少记录目标、知识引用、证据、结论、风险和行动建议。

第四步，治理重要能力

把影响现实状态的 Tool 纳入 Capability，补齐语义、Owner、权限、风险、版本、审计和失败策略。优先治理资金、权限、审批、外部通知和不可逆行动。

第五步，建立现实反馈和错误归因

定义执行结果与现实成功的区别，把反馈关联到目标、推理、能力和策略，并能够区分知识、记忆、推理、治理、执行和外部系统错误。

第六步，按真实瓶颈引入运行时能力

如果主要问题是旧政策和冲突，优先补知识运行时。如果历史误用频繁，补记忆生命周期。如果高影响判断不可审计，补推理对象和运行时。如果 Tool 失控，补能力治理和控制平面。

这条路径的原则是：

先闭合责任再抽象机制最后平台化

平台应该从反复出现且边界稳定的运行时责任中长出来，而不是从术语清单中长出来。

成熟度：哪些已经验证，哪些仍是理论提案

完整模型必须把证据强度写清楚，否则读者会误以为每一层都已经经过同等验证。

开放问题不是附录里的免责条款，而是理论演进的一部分。Reality Model 如何形式化，知识可信度如何计算、运行时最小接口如何冻结、记忆如何遗忘、多 Agent 如何分责、反馈如何成为验证证据，都需要继续通过 RFC 和参考实践收敛。

实践：用 KDC Architecture Canvas 做一次架构评审

选择一个现有或拟建设的 AI 业务流程，邀请业务 Owner、架构、AI、数据、安全和运维相关人员共同完成一次评审。

Canvas 不需要先画成复杂图，可以从下面八个区域开始：

评审时依次检查：

1. 是否把数据库状态误当作现实结果？

2. 是否把文件、向量或 RAG 片段直接当作已验证知识？

3. 是否存在无法说明依据的高影响判断？

4. Skill 是否明确目标、边界和失败路径？

5. 重要 Tool 是否缺少 Capability 语义、Owner 和风险等级？

6. 关键治理是否只存在于 Prompt 或人工默契中？

7. 接口成功后是否缺少现实反馈？

8. 日志能否支持知识、记忆、推理、能力和治理之间的错误归因？

9. 当前流程真的需要完整 KDC，还是只补一两个高风险缺口即可？

最终不要产出一份宏大平台路线图，而是选择一个最重要、最可验证的缺口。

比如：先让退款能力必须绑定用户确认和推理对象。先让当前政策拥有稳定版本与有效期。先让到账反馈能够关联到原能力调用。完成一个闭环后，再决定是否需要抽象为共享运行时能力。

KDC Architecture Canvas 的目标不是证明系统“符合 KDC”，而是帮助团队发现：哪些过去隐含的责任，已经因为 AI 参与判断和行动而必须显式化。

KDC 试图建立的是一条可以被质疑的工程闭环

AI 时代的软件工程不会抛弃代码、数据库、API、工作流和既有治理体系。KDC 的判断是：当模型能够理解上下文、形成判断并参与现实行动后，软件工程还需要显式管理知识、记忆、推理、技能、能力、治理和反馈。

完整链路可以再次压缩为：

面对现实  -> 形成可靠认知  -> 产生可审计判断  -> 组织目标级技能  -> 通过受治理能力行动  -> 用现实反馈持续校正

对象化让关键责任可以被引用，运行时化让对象能够持续工作，治理化让行动边界不依赖模型自律。三者共同服务同一个目标：让 AI 应用软件从一次性演示走向长期生产系统。

KDC 当前仍是一套开放理论提案。它需要更多真实系统验证，需要与既有理论进行严格比较，也需要允许反例推翻或修正当前抽象。完整并不意味着成熟，连贯也不意味着正确。

我们真正希望保留的，不是每一个当前术语，而是这组工程问题：

系统面对什么现实，依据什么知识，记住了什么，如何形成判断，怎样围绕目标组织技能，通过什么能力行动，谁来治理，以及如何从反馈中修正自己？

当一个 AI 系统能够稳定回答这些问题，它才开始具备理解现实、参与行动并承担长期工程责任的基础。

理论边界与开放问题

本文是 KDC 完整模型的公开叙事版本，不是已冻结的架构规范。当前已验证证据主要集中在现有能力治理平台支持的 MCP + Tool + Skill + LLM 电商流程，以及能力控制平面的部分工程职责。Reality、知识定义、对象模型主要属于 Derived。完整运行时、企业知识库、自主 Agent、记忆体系和持续一致性度量仍包含 Hypothesis 或 Open Research。KDC 不替代 DDD、RAG、MCP、Agent Framework、API Gateway、IAM、Policy Engine 或 OpenTelemetry。

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