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

作者：vivo 肖博AI 合作者：ChatGPT（GPT-5.5）创作模式：Human-led, AI-collaborated责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。 研究说明：知识驱动计算（Knowledge-driven Computing, KDC）是我们正在提出和持续打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。它不是业界已有的通用概念，也不是已经成熟的架构标准。这一系列文章将从具体工程问题出发，逐步说明我们为什么提出 KDC、它试图解释什么，以及哪些判断仍有待实践验证。摘要：当 AI 应用开始在运行时解释数据、选择工具并影响业务状态时，数据表示中的遗漏和歧义可能直接转化为行动风险。本文从退款案例出发，提出 Reality First 的观察顺序：先明确系统面对的领域现实，再讨论现实模型、数字表示以及验证反馈如何共同支撑软件的判断与行动。让我们从一个真实案例开始。退款接口返回成功，订单状态已经更新为“已退款”，客服后台也显示流程结束。三天后，用户再次联系客服：钱还没有到账。从系统内部看，这笔退款没有明显异常。退款接口返回了 HTTP 200 状态码，数据库事务已经成功执行，退款单状态符合预期，通知消息也正常发出。检查服务、表结构和调用链，这个流程可以被判断为“执行成功”。但从用户面对的现实看，退款还没有完成，因为钱没有到账。这类问题通常会被归入最终一致性、外部渠道延迟、对账异常或状态同步失败等工程问题。但在这些问题分类之前，还有一个更基础的问题：应用软件中的状态，究竟是不是现实本身？如果不是，那么软件架构的第一层究竟是什么？从传统架构视角看，应用软件经常被描述为数据在程序、数据库、接口和流程之间流动的系统。这个抽象很有解释力，但它通常从数据已经存在之后开始，没有继续追问这些数据在表示什么现实。本文尝试暂时离开数据表、服务和接口这些应用软件架构中常见的组件，从更基础的问题重新审视应用软件。我们研究的初步判断是：应用软件其实不是从数据开始，而是从它试图观察、表示和影响的领域现实开始。数据库、API、事件、对象模型和页面状态，都只是现实进入数字系统后的表达。这个判断看起来朴素，却会改变我们设计 AI 应用软件时提出问题的顺序。我们习惯从数据开始设计软件多数应用软件项目都有一条熟悉的设计路径。需求经过分析后，被翻译成领域对象、数据表、接口和流程：订单需要哪些字段，状态如何枚举，服务之间如何调用，事件如何传递，事务在哪里提交，失败后怎样重试。页面、报表和外部系统再围绕这些数据结构工作。这套方法没有错。过去几十年的软件工业已经证明，清晰的数据模型、稳定的接口契约、可靠的事务和消息机制，是构建复杂系统不可缺少的基础。问题在于，我们很容易在长期工程实践中形成一种错觉：仿佛数据模型就是业务现实，字段变化就是现实变化，接口成功就是业务目标实现。实际上，订单表不是交易本身，库存数字不是仓库中可交付的商品本身，支付状态不是资金流本身，物流轨迹也不是包裹本身。它们都是系统对现实的观察、编码和表达。在固定流程中，这种简化往往足够有效。程序员提前决定了数据从哪里来、每个字段在当前流程中代表什么、什么条件下可以调用接口、失败后如何处理。很多没有写进数据模型的业务含义，实际上被补充在代码分支、规则引擎、页面交互、操作手册和人工审核中。举个例子。数据库里可能只有一个 refund_status = success。但编写售后流程的开发者知道，这个 success 只表示支付渠道已经受理退款，并不表示资金已经进入用户账户。因此，程序可以继续等待到账回执，客服也可能按照操作规范提醒用户关注后续进度。换句话说，传统系统并不是只依靠数据运行。它还依靠程序员在设计阶段把数据的语义、适用条件和例外处理写进确定的执行路径。数据表示即使不完整，代码和人工流程仍可能补上缺失的解释。AI 应用改变的正是这个前提。大模型不再只是被某段固定代码调用，用来完成分类、摘要或文本生成。它开始进入应用软件的运行时，直接读取数据库字段、业务文档、API 响应、历史对话和检索片段，在当前上下文中解释这些表示，再据此形成判断、选择 Tool，甚至触发会改变订单、资金、权限和流程状态的行动。这意味着，过去主要由开发者在设计阶段完成的部分语义解释和行动选择，现在被移动到了运行时：传统程序数据表示 -> 预先编写的解释逻辑 -> 固定条件分支 -> API 调用AI 应用多种表示 -> 模型在当前上下文中解释 -> 运行时判断 -> 动态选择行动复制代码这里真正新增的风险，不是“大模型可能读错一个字段”这么简单，而是表示层中的问题会沿着一条更短、更动态的路径进入现实行动。第一，模型接收到的通常不是完整现实，而是多个系统留下的局部表示。订单状态来自订单系统，支付状态来自支付渠道，用户诉求来自对话，退款政策来自文档检索。每一种表示都有自己的观察范围、更新时间和语义边界。第二，模型需要在运行时自行拼接这些表示。它不仅读取值，还会推断值之间的关系。比如，它可能把 refund_status = success、支付渠道返回 accepted 和“退款流程已结束”的旧版客服话术组合成“用户已经收到退款”。这个结论在语言上很连贯，却超出了任何一个输入实际能够证明的范围。第三，模型形成的解释可能直接影响下一步行动。在传统系统中，一个新结论通常需要开发者把它写进代码后才能改变执行路径。在 Agent 系统中，同一次运行里的解释就可能决定是否关闭工单、是否通知用户、是否再次发起退款，或者是否调用其他业务能力。第四，Tool 调用成功还会制造一种额外的确定感。接口返回成功，只能证明某个数字系统接受或完成了某项操作。如果系统没有定义后续现实反馈，模型和使用者都可能把技术成功误认为业务目标已经实现。于是，一个原本位于表示层的缺口，会被逐级放大：flowchart LR R[“领域现实“] -->|观察与建模| RM[“Reality Model<br/>现实模型“] RM -->|编码：遗漏、压缩、延迟| RP[“Representation<br/>数字表示“] RP -->|解释：歧义、超证据推断| J[“运行时判断“] J -->|行动选择| C[“Tool / Capability“] C -->|执行| A[“现实行动“] A -.->|结果反馈| R复制代码图 1：表示偏差如何沿 AI 判断链进入现实行动需要强调的是，表示偏差并不是 AI 出现后才有的问题，传统系统也会遭遇脏数据、状态延迟和模型失真。AI 带来的变化在于：系统开始动态解释更多异构表示，判断路径不再全部预先写死，而且判断可以更快地转化为行动。原有的数据质量问题，因此进一步变成了语义边界、判断依据和行动治理问题。所以，在 AI 时代继续只从数据开始，已经不只是建模视角上的局限。如果系统没有说明数据对应什么现实、能够支持什么结论、又需要什么反馈才能验证，那么表示层中的遗漏、过期和歧义就可能穿过模型的判断，最终成为现实世界中的行动风险。为什么我们开始研究 KDC我们提出 KDC，并不是因为代码、数据库和 API 已经过时。恰恰相反，这些工程基础仍然承担确定性执行、数据持久化、系统集成和性能保障，是任何生产系统不可缺少的部分。这项研究并不是先有一个“KDC”名称，再去寻找适用问题。Tool-use 已经让 LLM 能够参与下单、查询和任务执行等流程。我们也通过 MCP、Tool、Skill、LLM 与一套能力治理平台完成了电商流程验证。这里的能力治理平台，是承担工具注册、授权、测试、灰度、限流、熔断、审计和观测等职责的工程系统。这个实践不等于完整生产验证，但它让一组新的工程问题变得清晰：模型为什么选择这项操作，依据是否可靠，行动是否越过边界，执行结果是否真的完成了现实目标？KDC 是我们尝试系统回答这些问题后形成的理论研究动机。这项实践还暴露出几类不能只靠工具列表和调用日志解决的责任：系统不仅要知道数据是什么，还要判断哪些内容可以被信任和复用。不仅要记录模型调用了什么，还要解释它依据什么形成判断。不仅要让模型能够调用 Tool，还要治理模型为什么、以什么权限、在什么风险条件下采取行动。行动之后，还要知道现实结果是否支持原来的判断。这些问题分别可以由 RAG、Agent Framework、MCP、API Gateway、IAM、工作流和可观测系统处理其中一部分。但从我们的研究来看，这些机制通常分散在不同架构层和工程团队中，仍需要一个能够把它们放在同一条业务因果链中讨论的软件工程视角：现实如何进入数字系统？ -> 数字表示如何形成可复用知识？ -> 知识如何支持可审计判断？ -> 判断如何转化为受治理的行动？ -> 行动结果如何反馈并修正系统？复制代码我们把围绕这条链路展开的理论研究称为知识驱动计算。这个名称强调的不是“所有软件都应该由知识替代代码”，而是：在 AI 能够理解上下文、形成判断并参与现实行动之后，知识、推理、能力、治理和反馈需要像代码、数据和接口一样，成为可以被明确设计和审阅的工程对象。KDC 并不试图替代 DDD、RAG、MCP、Agent Framework 或既有治理体系。这些方法和机制分别解决领域建模、材料检索、模型连接、任务执行和安全治理等问题。KDC 关注的是：当它们共同进入一个 AI 应用时，如何围绕现实目标形成一条连续、可追溯的工程链路。因此，这项研究选择的第一个起点，不是 Knowledge，也不是 Agent，而是 Realit