vivo 肖博提出知识驱动计算（Knowledge-driven Computing, KDC）完整工程模型，将 AI 应用软件从"模型调用"组织为一条从领域现实到现实反馈的连续工程闭环，并给出对象化、运行时化、治理化三层工程架构。
当一个 AI 应用不仅能生成文本，还能退款、下单、变更权限、发送通知——错误会直接进入现实。传统软件工程有代码、数据库、API、工作流和治理体系，但当模型参与判断和行动后，知识、记忆、推理、技能、能力和反馈这些过去隐含的责任，必须显式化。
KDC 不试图替代操作系统、数据库、编译器或模型训练理论。它依赖这些基础设施，但关注的是另一类问题。
模型调用 + Prompt + 工具调用 + 日志。关键内容放在会话上下文和文档片段中，缺少稳定身份和生命周期，难以跨任务引用和治理。
从领域现实出发，经过知识、记忆、推理、技能、能力、行动，到现实反馈——形成一条可设计、可运行、可审计、可演化的连续工程闭环。
KDC 更关注这样的系统：业务语义密集、上下文随用户和时间变化、模型在运行时解释材料并形成判断、行动可能影响重要现实状态、团队需要知道判断依据和责任边界。
采用 KDC 不是二元选择。团队可以只补齐当前风险最高的一段，而不是一次性建设全部对象和运行时。
KDC Reality-to-Feedback 业务闭环：这不是一条只能从左到右执行一次的流水线，而是一张因果地图。最终参照物始终是领域现实本身。
KDC 把工程责任概括为三个层次。它们不是三个独立部署的平台，而是三类必须承担的工程责任。
对象化让关键责任可被引用；运行时化让对象持续工作；治理化让行动边界不依赖模型自律。三者共同服务于同一个目标：让 AI 应用从一次性演示走向长期生产系统。
第一层：对象化 —— 让隐含责任可以被引用
传统 AI 应用把关键内容放在 Prompt、会话上下文和日志中。KDC 定义五类核心对象：Knowledge Object（可复用依据）、Memory Object（受治理的历史）、Reasoning Object（可审计的判断）、Skill Object（目标级复用）、Capability Object（受治理的行动入口）。对象化让"依据了什么、记住了什么、如何判断"从临时内容变成可追溯关系。
第二层：运行时化 —— 让对象真正运转
知识运行时负责解析、关联、验证和检索知识对象；记忆运行时治理历史如何影响未来，而非保存尽可能多的历史；推理运行时记录目标、证据、风险与结论，不要求暴露模型内部全部思维；能力运行时负责能力发现、调用、组合与反馈处理。运行时是逻辑责任，不必一开始对应四个独立服务。
第三层：治理化 —— 让行动边界成为系统机制
当 AI 可以退款、下单、变更权限时，治理需要从 Prompt 约定提升为系统机制：能力注册与版本、权限与策略、风险分级与 HITL、事务边界与补偿、可观测与审计链、现实反馈与错误归因。治理不只发生在能力入口——知识权限、记忆访问、推理证据同样需要边界。
以下是一个用户说"帮我看看这笔订单现在能不能退"的完整流程，展示 KDC 各层如何协同工作。
识别现实目标 —— 系统区分"资格咨询"和"行动授权"。当前目标是判断是否符合条件，不是立即退款。Reality Map 告诉系统："接口成功"不是最终现实结果。
装配知识与记忆 —— 知识运行时提供当前有效的退款政策（v4.0），保留版本、证据和适用边界。记忆运行时返回上次退款经历，但标明：这是特定订单下的结果，不足以证明用户当前偏好。
形成推理对象 —— 记录：目标是资格判断，政策版本 v4.0，订单未发货且权益未核销，结论是符合条件，风险在于把咨询误解为授权。
选择 Skill —— Agent 选择"订单退款处理"Skill。该 Skill 规定：先判断资格，再解释影响，用户确认后才进入事务型能力。高金额或异常订单转人工。
提出能力调用建议 —— 用户确认后，系统建议调用"发起订单退款能力"。能力对象声明其风险、权限、Owner、事务边界、审计策略和反馈要求。
控制平面判定 —— 检查调用主体、用户确认、推理对象、订单状态、知识版本、风险策略。条件满足时授权执行；缺少确认时拒绝并返回可解释原因。
能力运行时执行 —— 调用底层 Tool，处理事务、异常、重试或补偿。Tool 返回成功只表示请求被受理，不直接标记退款为现实完成。
现实反馈进入系统 —— 支付渠道状态、对账结果和用户确认进入 Feedback Contract。反馈关联到原目标、推理对象、能力对象和策略判定。如果旧政策导致错误判断，让知识降级或过期。
Agent 的价值不是自己承担所有责任，而是协调对象、运行时和治理机制完成一个可追溯任务。每一步都有明确的工程责任归属。
KDC 最容易失败的采用方式，是先建设一个名义完整的"知识平台、记忆平台、推理平台和能力平台"，再去寻找业务场景。更现实的路径是从一个高价值或高风险闭环开始。
建立 Reality Map —— 明确系统边界、现实对象、状态、关系、动态规律和成功反馈。优先识别内部状态与现实承诺之间的缺口。
识别关键 Representation 和 Knowledge —— 找出当前判断依赖的文档、数据、规则和事件。只对象化高价值、可复用或高风险知识。
外部化高影响判断 —— 为高影响决策建立推理对象或等价审计依据。至少记录目标、知识引用、证据、结论、风险和行动建议。
治理重要能力 —— 把影响现实状态的 Tool 纳入 Capability，补齐语义、Owner、权限、风险、版本、审计和失败策略。优先治理资金、权限、审批和不可逆行动。
建立现实反馈和错误归因 —— 定义执行结果与现实成功的区别，把反馈关联到目标、推理、能力和策略，区分知识、记忆、推理、治理、执行和外部系统错误。
按真实瓶颈引入运行时能力 —— 主要问题是旧政策和冲突？优先补知识运行时。历史误用频繁？补记忆生命周期。Tool 失控？补能力治理和控制平面。
先闭合责任 → 再抽象机制 → 最后平台化
平台应该从反复出现且边界稳定的运行时责任中长出来，而不是从术语清单中长出来。
KDC 的原创性不在于发明了 Knowledge、Agent、API 或治理，而在于把它们组织成一个面向 AI 应用软件的连续工程闭环。但完整并不意味着成熟，连贯也不意味着正确。它需要更多真实系统验证，也需要允许反例推翻或修正当前抽象。真正值得保留的，不是每一个术语，而是这组工程问题：系统面对什么现实，依据什么知识，记住了什么，如何形成判断，怎样围绕目标组织技能，通过什么能力行动，谁来治理，以及如何从反馈中修正自己？
KDC Architecture Canvas 已开放，选择一个现有或拟建设的 AI 业务流程，邀请业务 Owner、架构、AI、数据、安全和运维相关人员完成一次架构评审。从"当前流程真的需要完整 KDC，还是只补一两个高风险缺口即可"开始。
搜索"KDC 系列"获取完整五篇原文与工程模板。