作者：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，而是 Reality。因为在讨论系统知道什么、如何判断和怎样行动之前，需要先回答：这个应用软件究竟在面对什么？
应用软件真正面对的是领域现实
KDC 研究中所说的 Reality，不是一个没有边界的哲学概念，也不是要求软件描述整个物理世界。我们暂时把它作为一个工程概念使用：
在确定的系统边界和系统职责内，系统希望观察、建模、预测或影响的客观存在及其运行规律。
这里有两个必要限定。
第一是系统边界。比如电商系统不需要描述世界上的所有事物，它只需要关注与商品、用户、交易、库存、支付、履约和售后有关的现实。
第二是系统职责。比如同一个订单，在交易系统、财务系统、仓储系统和客服系统中对应不同的责任范围。交易系统关注订单是否成立，财务系统关注资金是否完成结算，仓储系统关注商品能否履约，客服系统关注用户问题是否真正解决。它们面对的是同一现实的不同切面。
在这个边界内，领域现实至少可以从四个维度理解：
Reality = Object + State + Relationship + Dynamics对象（Object）：系统关注的存在，比如用户、商品、订单、库存、支付和物流。
状态（State）：对象在现实中的阶段和条件，比如订单待支付、已支付、已发货、已退款。
关系（Relationship）：对象之间客观存在的关联，比如用户创建订单、订单包含商品、退款对应原支付。
动态规律（Dynamics）：状态和关系如何变化，以及哪些约束不能被破坏，比如未支付订单不能进入履约，退款金额不能超过实际支付金额。
这四个维度的意义，不是提供另一套画图术语，而是迫使架构设计回答一个经常被跳过的问题：我们准备编码的数据，到底在表示什么？
以退款为例，真正的领域现实并不只有一个 refund_status 字段。它至少涉及：
用户提出退款诉求
订单与原支付记录之间存在有效关系
退款申请经过业务规则和风险判断
支付渠道接受退款请求
资金进入清算或原路退回过程
用户账户最终收到资金
订单、售后、财务和用户通知状态得到相应更新
这里的每一步都可能由不同系统观察，也可能处于不同时间尺度。一个内部字段从 processing 变成 success，只说明某个系统对现实作出了某种判断，并不天然代表用户已经收到资金。
数据库保存的是表示，不是现实
现实进入软件系统，需要经过建模和编码。KDC 把这些数字编码统称为表示（Representation）。
表示可以是：
数据库中的一行记录
API 的请求和响应
消息队列中的事件
文档中的一段文字
日志和审计记录
对象模型或状态机
搜索索引、Embedding 或知识图谱中的节点和关系
提供给大模型的 Prompt 和上下文
因此，更完整的链路不是“现实直接变成数据”，而是：
Domain Reality -> Reality Model -> Representation - Domain Model - Data Model - API / Message / Event - Document / Log / Context现实模型（Reality Model）位于现实和数字表示之间。它决定系统选择观察什么、忽略什么，如何划分对象，如何定义状态，如何表达关系，又如何判断一次变化真的发生了。
任何模型都必然是有选择的。退款系统可以把状态简化为“申请中、成功、失败”，也可以进一步区分“渠道已受理、清算中、银行处理中、用户已到账”。两种模型都可能合理，关键取决于系统职责。
如果系统只负责把退款请求提交给支付渠道，那么“渠道已受理”也许就是它的职责终点。如果系统向用户承诺“退款已到账”，那么它就需要能够观察更后面的现实状态。问题不在于状态多或少，而在于数字表达是否与系统作出的现实承诺相匹配。
可以用下面的方式理解现实与表示之间的差异：
这并不意味着数字表示不可信，而是说每一种表示都有来源、观察范围、时间延迟和适用边界。架构需要知道一个字段“声称了什么”，也需要知道它“没有证明什么”。
从这个角度看，许多所谓的数据问题，其实首先是现实映射问题：
我们是否遗漏了重要现实对象？
一个状态是实际发生、外部声明，还是系统推断？
多个系统对同一现实是否使用了不同定义？
某个字段在多长时间内仍可作为有效判断依据？
系统采取行动后，哪个反馈可以证明现实目标已经实现？
如果这些问题没有在建模阶段得到回答，再完整的数据血缘和接口文档，也只能解释数字如何流动，不能完整解释数字与现实之间的关系。
状态正确，不等于现实正确
传统软件工程非常重视内部一致性。数据库事务保证一组写入同时成功或失败，消息机制保证事件可靠传递，缓存策略减少不同副本之间的偏差，监控系统观察服务是否健康。
这些能力仍然重要。但它们主要解决数字系统内部的一致性。
应用软件还面对另一种一致性：数字系统对现实的描述是否仍然成立。
退款事务提交成功，可以证明数据库内部的退款单和订单状态按照规则发生了变化。它不能单独证明支付渠道已经处理，更不能证明用户已经到账。接口返回成功，可以证明调用被对方系统接受。它不能单独证明最终业务结果已经发生。
于是，应用软件的“正确”至少包含两个层次：
数字内部正确 +数字表示与领域现实足够一致前者关注事务、类型、接口、流程和技术状态。后者关注现实对象、业务承诺、外部变化和结果反馈。
KDC 的核心判断之一是：应用软件的最终参照物不是内部状态，而是现实。系统当然无法直接获得完整现实，只能通过传感器、人工确认、外部接口、业务事件和其他表示去观察它。但正因为只能间接观察，架构才更需要显式记录观察来源、适用范围和反馈条件，而不是默认数据库中的最新值就是现实本身。
一个表示偏差如何被放大为行动错误
前面的机制可以在退款案例中具体展开。LLM 和 Agent 系统会读取退款状态、客服记录和支付渠道响应，然后形成结论：“退款已经完成。”它还可能据此发送通知、关闭工单，或者选择后续行动。
模型擅长把分散表示组织成连贯解释，但连贯并不等于真实。如果上下文遗漏关键状态，或者不同系统对同一字段使用了不同语义，模型就可能得出超出证据范围的结论。
回到开头的退款案例。假设 Agent 看到了以下内容：
refund_status = successgateway_response = acceptedticket_status = processing如果系统没有告诉它 success 只代表退款请求被渠道受理，也没有提供到账反馈，它很可能把“渠道接受请求”解释为“用户已经收到退款”，继而自动关闭工单。
问题不一定出在模型，也不一定出在接口。更根本的问题是，系统没有把现实承诺、表示语义和验证反馈之间的关系表达清楚。
AI 系统一旦能够根据表示自主形成判断并参与行动，软件工程就必须多问三步：
1. 模型看到的表示对应哪一部分现实？
2. 这些表示足以支持什么结论，又不足以支持什么结论？
3. 行动发生后，系统通过什么现实反馈确认目标已经实现？
这也是 KDC 从 Reality 开始，而不是从 Prompt、数据或 Tool 开始的原因。只有先明确系统面对的现实，后续才能讨论哪些表示可以形成知识、哪些判断需要被审计，以及哪些行动可以安全执行。
KDC 与 DDD：不是替代，而是继续向运行时追问
领域驱动设计（Domain-driven Design, DDD）已经长期强调：复杂软件不能只围绕数据库表组织，而应围绕领域语言、限界上下文、实体、值对象、聚合和领域服务建模。
KDC 认可并继承这个方向。DDD 提供了理解领域语义的重要方法，也提醒团队不要让技术模型取代业务模型。
KDC 的关注点进一步延伸到 AI 运行时：
一个领域对象被模型理解时，引用了哪些知识？
模型形成判断时，依据来自哪里，是否仍然有效？
系统选择行动时，是否理解其对现实状态的影响？
行动完成后，什么反馈能够校正数字表示和后续判断？
DDD 可以帮助我们说明“订单是什么”、“退款属于哪个限界上下文”、“哪些状态迁移合法”。KDC 继续追问“AI 为什么相信这笔退款已经完成”、“这个判断能否被追溯”、“现实结果是否反过来修正了系统”。
因此，KDC 不替代 DDD，也不要求团队放弃既有领域模型。它把 DDD 提供的领域语义作为重要来源，并在其上增加知识引用、运行时判断、行动治理和现实反馈的连续链路。
实践：尝试为一个业务流程画出 Reality Map
理解 Reality 最有效的方法，不是给现有架构增加一层抽象名词，而是选择一个边界明确的业务流程，检查数字系统究竟在映射什么。
可以从退款、下单、审批、发货、合同审查或项目风险跟踪中任选一个。第一次练习不需要覆盖整个企业，也不需要立即修改系统。
第一步，写清系统边界和职责
先用一句话说明系统负责什么、不负责什么。
举个例子：
售后系统负责接收退款诉求、验证业务条件、发起退款并向用户反馈进度。实际资金清算由外部支付渠道和银行完成。
这句话会直接决定系统应该建模哪些现实，以及哪些现实只能通过外部反馈观察。
第二步，列出对象、状态、关系和动态规律
不要先打开表结构。先从业务现实写起：
第三步，把现实元素映射到数字表示
为每个重要现实元素找到当前系统中的表示：数据库字段、API、事件、文档规则、人工确认或外部回执。
同时记录三个信息：表示来自哪里、多久更新一次、它能够证明什么。
第四步，定义现实反馈
对每个重要行动追问：什么信号能够证明它在现实中产生了预期结果？
“接口成功”通常只是执行反馈，不一定是最终现实反馈。退款场景中的现实反馈可能包括支付渠道状态、银行回执、对账结果、用户确认或超时后的人工核验。
第五步，形成映射缺口清单
重点寻找以下缺口：
现实中存在，但系统没有表示的对象或状态
多个系统使用同一字段名，却表达不同含义
一个中间状态被错误命名为最终结果
表示已经过期，但下游仍把它当作当前事实
行动只有技术返回，没有现实结果反馈
系统作出的承诺超出了它实际能够观察和验证的范围
最终产物可以是一张单页 Reality Map：
这张图的目的不是取代领域模型、数据模型或系统架构图，而是把它们重新连接到现实。团队完成第一次盘点后，只需要选择一个影响最大的缺口进入后续设计，不必一次性重构所有表示。
对于低语义、低风险、固定流程的简单自动化，也不必引入完整 KDC 模型。如果一个脚本只在受控环境中转换文件格式，输入输出确定，也不影响重要现实状态，那么传统接口和测试已经足够。Reality Map 更适合那些涉及复杂业务语义、跨系统状态、外部行动或高影响判断的流程。
Reality Map 改变的，是架构提问的顺序
完成一张 Reality Map 后，团队得到的并不只是另一张业务分析图。
它真正改变的是架构讨论的起点。过去，我们可能直接讨论退款状态应该如何定义、接口如何调用、消息如何传递。现在需要先确认：系统负责观察哪一段退款现实，对用户作出了什么业务承诺，又能够通过什么反馈验证这个承诺已经兑现。
这里所说的“承诺”，不是一个新的理论对象，而是应用软件通过页面、接口、流程和服务向用户或其他系统表达的业务结果。比如，“退款申请已提交”、“支付渠道已受理”和“退款已经到账”，是三个不同强度的承诺。系统能够表达哪一种承诺，取决于它实际观察到了哪一段现实。
如果系统只能观察支付渠道是否受理退款，就不应该把这个中间结果表达为“退款已经到账”。如果系统向用户承诺订单已经完成退款，就需要继续观察资金退回、对账或用户确认等后续反馈。
这也解释了“软件从现实开始”的工程含义。它不是要求团队放弃数据模型、API 或流程，而是要求这些数字对象能够追溯到系统所承担的现实职责：
这个字段在表示哪个现实对象或状态？
这个接口成功能够证明什么，又不能证明什么？
这次状态变化对应现实中的哪个过程？
系统对外表达“完成”时，依据的是内部执行结果，还是已经获得了现实反馈？
如果数字表示与现实不一致，哪个机制负责发现和修正？
当这些问题先被回答，数据模型才不只是内部存储结构，而成为领域现实的数字表达。接口也不只是调用入口，而成为系统观察或影响现实的通道。状态机也不只是字段迁移规则，而开始对应现实过程及其约束。
因此，Reality First 并不是用 Reality 取代 Data，而是重新确定推导顺序：
Domain Reality -> Reality Model -> Representation - Data / API / Event / Document我们仍然需要继续讨论字段如何定义、数据怎样流动、服务如何调用。区别在于，这些设计不再凭空从数字系统内部开始，而是能够向前追溯：它们为什么存在，表示什么现实，服务什么职责，又依靠什么反馈维持有效。
KDC 对应用软件的第一性判断可以压缩为一句话：
应用软件不会创造现实，它在数字基座之上表示现实、理解现实，并最终作用于现实。
所以，“软件不是从数据开始，而是从现实开始”并不否定数据。它要表达的是：数据来源于对领域现实的建模，软件架构则是领域现实的数字化表达与持续演化。
但这会带来下一个问题：如果数据库、文档、API、事件和向量都只是现实的表示，那么这些表示在什么条件下，才能真正成为系统可以信任和复用的知识？
这将是下一篇讨论的主题。
理论边界与开放问题
本文关于 Reality、Reality Model 和现实驱动计算的表述，属于 KDC 当前阶段的理论推导，尚未经过充分的跨场景实践验证。现实模型如何形式化、现实覆盖范围如何度量，以及持续一致性如何验证，仍是后续研究问题。
版权声明： 本文采用 CC BY-NC-ND 4.0（署名-非商业性使用-禁止演绎） 许可协议。转载请注明出处。
