AI系统真正的可靠性，往往不取决于模型：重读《Designing Data-Intensive Applications》第二版
周读：《Designing Data-Intensive Applications, 2nd Edition: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems》
作者：Martin Kleppmann、Chris Riccomini
周读日期：2026年10月30日
出版机构：O’Reilly Media
一家企业准备上线AI知识助手。它可以回答产品参数、技术资料、合同问题、库存信息和客户历史记录。
演示阶段，效果很好。员工输入问题，AI很快给出答案，还能引用相关文档。于是企业决定扩大使用范围，将知识助手接入CRM、产品数据库、文档系统以及内部业务流程。
但不久后，问题开始出现。销售人员已经更新了客户状态，AI却仍然引用旧数据；产品参数已经修改，知识库中的向量索引却没有及时更新；某个客户记录已经删除，搜索结果中仍然保留历史片段；两个员工几乎同时修改一份配置，系统产生了互相冲突的版本；一次网络超时后，Agent重新执行操作，结果意外创建了两条相同的业务记录。
这些问题乍看都像AI出了错。但仔细分析就会发现：真正发生故障的，可能根本不是模型。而是数据在存储、复制、同步、更新和跨系统传递过程中，失去了预期的一致性与可靠性。
这正是《Designing Data-Intensive Applications》要帮助读者理解的问题。上一期《Designing Machine Learning Systems》，我们讨论为什么模型训练成功不等于生产系统可靠。这一期继续向下深入：如果AI所依赖的数据系统本身不可靠，再好的模型也无法保证业务结果正确。
从这个角度看，《Designing Data-Intensive Applications》并不是一本与AI无关的数据库技术书。它解释的是：现代数字系统如何在不断变化、持续扩张和局部故障不可避免的现实中，仍然尽可能正确地运行。
一、为什么2026年的第二版值得重新阅读
《Designing Data-Intensive Applications》第一版出版于2017年，由Martin Kleppmann独立撰写。它后来成为分布式系统、数据库和数据工程领域具有代表性的技术著作。
2026年，Martin Kleppmann与Chris Riccomini合作推出第二版。新版并没有推翻第一版的核心思想。它进一步讨论了近十年来发生明显变化的技术环境。包括云服务和云原生系统、多种数据库架构、Local-First软件、现代数据处理、向量嵌入，以及分布式系统的最新实践。
其中一个很值得注意的变化，是新版在第一章就讨论了Cloud与Self-Hosting之间的架构选择，并在最后一章专门讨论：Doing the Right Thing。也就是数据系统的伦理、隐私、责任与社会影响。
这说明数据系统设计早已不只是选择数据库。它同时涉及：
- 技术权衡。
- 组织能力。
- 可靠性。
- 数据治理。
- 使用者权益。
这本书最重要的价值，并不是告诉我们应该选择PostgreSQL、Redis、Kafka还是某一种云数据库。而是提供一套可以长期使用的判断方法：理解每一种技术选择背后的Trade-Off。技术会持续变化。但权衡不会消失。
二、数据系统设计的第一原则：不存在没有代价的架构
今天的软件架构讨论中，充满了各种流行建议。使用微服务、采用Serverless、迁移到云端、引入消息队列、建立实时数据湖、部署向量数据库、将系统改造成Event-Driven Architecture。这些方案都可能有价值。
但本书反复提醒读者：技术选择必须服务于实际需求。
例如，一家企业每天只有几千条业务记录，数据量不大，系统同时在线用户很少，业务逻辑也不复杂。如果直接引入多个微服务、分布式消息队列、复杂数据库集群、实时计算平台、独立搜索集群，那么系统可能确实获得了更高的理论扩展能力。但同时也增加了部署成本、运维成本、网络故障风险、数据同步问题、权限配置复杂度、排错难度以及系统之间的依赖关系。企业最终可能只是把一个原本简单的问题，变成一个复杂的工程问题。
所以真正成熟的架构设计不是尽可能采用最先进的技术，而是以能够满足需求的最低必要复杂度，建立可靠且可持续演进的系统。复杂性本身就是成本。
三、Reliability、Scalability、Maintainability：系统真正的三个核心目标
本书副标题包含三个关键词：Reliable、Scalable、Maintainable。它们分别对应不同问题。
Reliability：出现局部故障时，系统能否继续正确工作？
服务器可能宕机，磁盘可能损坏，网络可能中断，程序可能存在缺陷，操作人员也可能犯错。可靠性并不意味着永远不发生故障。而是系统能够在预期故障范围内，通过容错、检测、恢复和必要的降级措施，继续提供可接受的服务。
Scalability：当负载增加时，系统能否合理扩展？
今天每秒100次请求，未来可能达到每秒1000次。真正需要评估的是吞吐量、延迟、资源占用、扩展成本以及负载变化后系统的行为。这里需要强调：Scalability不是系统现在有多大，而是系统应对负载增长的能力。
Maintainability：系统能否长期修改、理解和维护？
一个系统可能今天运行很好。但如果三个月后没人敢修改代码，六个月后没人知道数据从哪里来，一年后每次升级都会引发事故，那么它很难称得上成功。可维护性包括可运维性、简单性和可演进性。这也是为什么系统架构不应该只追求当前性能。一个能够持续被理解和修改的系统，往往比一个极度复杂但缺乏可维护性的系统更有长期价值。
四、不要先讨论数据库，先讨论数据究竟用来做什么
新版第一章特别强调Operational Systems与Analytical Systems的区别。这是理解整个现代数据架构的重要起点。
Operational Systems主要服务日常业务操作，例如创建订单、修改客户资料、更新库存、记录支付状态、处理业务事务。这些工作通常被称为OLTP，即Online Transaction Processing。
Analytical Systems则更关注从大量历史数据中进行统计、聚合和分析，例如统计过去一年的销售额、比较不同国家的客户转化、分析产品销量趋势、预测未来需求。这些属于更接近OLAP，即Online Analytical Processing的工作。
两者的技术要求不同。OLTP强调较低的单次事务延迟、事务完整性、并发操作和及时更新；OLAP强调大量数据扫描、复杂聚合、历史分析和较高的数据处理吞吐量。因此，企业不应该要求一个系统毫无代价地同时满足所有需求。
这也是为什么现代企业经常同时存在业务数据库、数据仓库、搜索索引、缓存、对象存储和消息队列。这些并不一定是重复建设，它们可能正在解决不同类型的问题。但问题随之出现：同一条业务事实存在于多个系统时，谁才是权威来源？
五、System of Record与Derived Data：AI时代必须分清“事实”和“副本”
这可能是全书对AI系统最有直接价值的概念之一。假设企业产品数据库中有一条记录：某型号工业设备的额定功率是75kW。这是经过审核的产品主数据。网站为了提高访问速度，将参数复制到缓存；搜索系统为了实现查询，将相关内容建立索引；AI知识库又把文档切块并生成向量嵌入。于是同一个参数可能同时存在于多个位置：Product Database、Website Cache、Search Index、Vector Store。
但它们的地位并不相同。产品主数据库可能是System of Record，也就是该业务事实的权威记录来源。而缓存、搜索索引和向量数据库通常是Derived Data，即为了特定用途，从权威数据派生出来的结果。
如果产品参数从75kW调整为80kW，所有下游系统都应该按照预定机制更新。否则AI可能引用一个已经过时、但在向量搜索中仍然高度相关的旧数据片段。这个问题不能简单通过优化Prompt解决。因为：模型获得的数据，本身就不是当前有效事实。
因此AI知识系统建设首先要问：每类事实的System of Record在哪里？哪些系统只是Derived View？更新如何传播？传播失败如何处理？如何验证下游数据与权威来源保持一致？这些问题直接决定企业AI系统能否长期可靠运行。
六、为什么索引能够提高速度，却也可能增加系统复杂度
数据库内部如何存储和检索数据，是本书第四章的重要主题。书中讨论了B-Tree、LSM-Tree、列式存储、物化视图、全文搜索索引和向量嵌入。这些技术不需要所有业务管理者都掌握实现细节，但至少应该理解：索引是一种用额外存储与维护成本换取查询效率的机制。
例如：B-Tree适合许多数据库中的点查询、范围查询和更新场景；LSM-Tree采用日志结构与分层合并策略，在某些写入密集型工作负载下具有优势，但也涉及Compaction、读写放大和空间放大等权衡；列式存储更适合许多分析查询，因为它能够高效读取需要的列，而不必总是处理完整行记录；全文搜索索引则服务关键词与文本查询；向量索引面向嵌入表示的近邻检索需求。
但这里有一个需要特别强调的事实：向量索引不等于业务数据库。它擅长寻找语义上可能相近的内容，却不天然保证事务一致性、当前数据版本、权限正确性、记录的唯一性以及删除后的完整同步。
所以建立RAG知识库不能只问“用哪一种Embedding模型？”，还应该问：向量索引与真实业务数据之间，怎样保持可验证的关系？
七、Replication：增加副本以后，系统并不会自动更可靠
为了提高可用性、读取能力或跨地区访问性能，数据系统经常采用Replication——复制。例如主数据库保存数据，另一个节点保留副本，某个副本用于读取，另一个副本用于灾难恢复。听起来很合理。但复制会引出一个关键问题：多个节点在同一时刻看到的数据，一定相同吗？
答案是不一定。如果采用异步复制，主节点已经完成一次写入，副本可能需要稍后才能看到更新。这时用户可能出现一种很奇怪的体验：刚刚修改了信息，刷新页面以后，却又看到了旧值。这种现象可能来自Replication Lag，即复制延迟。
所以分布式数据系统必须明确：哪些场景允许读取旧数据？哪些场景必须读到自己的最新写入？哪些业务需要更强一致性？例如文章阅读次数允许短暂延迟，通常影响不大；但支付结果、库存扣减或重要授权状态如果读取了错误版本，可能导致严重后果。一致性需求必须由业务正确性决定，而不是由数据库默认配置替企业决定。
八、Sharding解决容量问题，却创造了新的协调问题
Replication主要解决数据副本与容错、读取等问题。Sharding则主要解决如何将数据划分到多个节点。例如一家平台用户数量持续增长，单个数据库节点的容量和吞吐能力开始接近瓶颈。系统可以按照用户ID、客户租户、地理区域或哈希键将数据分布到多个分片。
但分片并不是单纯把数据库切成几块。它会带来新的问题：如何选择分片键？如何避免Hot Spot？怎样重新平衡数据？跨分片查询怎样执行？跨分片事务怎么办？不同租户之间怎样隔离？例如某个大型客户产生了全平台40%的数据请求。如果系统简单按照租户ID分片，这个客户所在分片可能长期成为热点。增加更多普通分片，并不能自动解决这个热点。
所以数据系统扩展之前，必须先理解：负载究竟集中在哪里。这与上一期《High Output Management》中寻找系统瓶颈的思想非常相近。不是盲目增加资源，而是找到限制整体表现的结构。
九、Transactions：没有事务，很多“偶发错误”会变成业务事故
现代数据系统有一个非常重要的能力：Transaction。事务帮助系统把多个相关操作放在具有一定原子性和隔离保证的执行边界内。例如客户付款以后，需要创建支付记录、更新订单状态、扣减相应库存。如果这些操作没有正确的事务及跨系统协调机制，就可能出现订单显示已付款但支付记录不存在、库存已经扣减却没有对应订单、同一笔支付被重复处理、不同操作之间出现不可接受的不一致。
本书详细讨论ACID、Read Committed、Snapshot Isolation、Serializable Isolation、分布式事务和Two-Phase Commit。这些概念说明了一个重要事实：数据库能够正常返回结果，并不代表并发业务一定正确。
尤其需要注意：不同数据库的事务隔离级别可能允许不同并发异常，例如Lost Update或Write Skew。业务设计不能只假设“使用了数据库事务，所以一切都安全。”还需要确认：哪些不变量必须被维护？哪些并发行为是允许的？是否需要更强隔离、唯一性约束或额外协调？
十、分布式系统最麻烦的地方：你无法总是知道对方究竟发生了什么
这是本书第九章非常重要的思想。假设一个AI Agent向业务系统发送请求：创建一条客户跟进任务。系统等待响应。但网络超时了。这时会发生什么？Agent并不知道：请求根本没有到达服务器，还是请求已经到达但服务器尚未处理，还是服务器已经处理成功只是响应在网络中丢失。这几种情况对客户端可能表现完全一样：Timeout。
如果Agent立即重新发送同样请求，就可能重复创建任务。这说明：网络超时不等于操作失败。分布式系统中一个很困难的问题，就是局部故障和通信不确定性。服务器宕机、网络中断、处理缓慢，有时很难仅凭超时准确区分。
所以真实生产系统需要明确的重试策略，例如Idempotency Key、唯一请求ID、幂等写入、去重机制、操作结果查询和超时后的状态核对。这些机制能够帮助降低重复执行风险。但不能简单认为添加自动重试就解决了可靠性问题。恰恰相反，没有正确幂等设计的自动重试，可能让一次故障变成多次错误操作。
十一、Exactly Once为什么不能只靠一句技术承诺
现代消息系统经常讨论At-Most-Once、At-Least-Once和Exactly-Once。这些概念看起来像三种非常清晰的技术保证。但在真实业务中，“恰好执行一次”必须明确适用边界。
例如：消息处理系统可能能够保证某个内部状态更新在特定条件下具有Exactly-Once Processing语义。但如果工作流还涉及发送邮件、向第三方付款、调用外部API或创建CRM记录，那么外部系统是否支持幂等、事务或结果核对，就会影响整个业务操作能否避免重复。
因此：消息被处理一次，与业务副作用恰好发生一次，不是自动等价的。这也是为什么生产系统设计中，常常需要结合稳定事件ID、事务日志、去重表、业务唯一性约束、Outbox Pattern、幂等接口和结果确认机制。
对于AI Agent而言，这一点尤其重要。因为Agent可能会自行判断刚才工具调用失败了，应该再试一次。如果它没有能力识别请求状态，或系统没有提供幂等保障，就可能重复执行真实业务动作。这已经不是模型回答质量问题，而是分布式操作语义问题。
十二、Consistency与Consensus：系统必须知道何时可以相信某个结果
在单机程序里，我们容易假设同一个变量在同一时刻具有明确状态。但分布式系统中，多个节点可能拥有不同版本，网络可能延迟，节点可能发生故障。因此，“当前值是什么”本身就可能成为需要协调的问题。
本书第十章讨论Linearizability、Logical Clocks、Consensus和Coordination Services。这些机制并不是用来让系统听起来更复杂。它们在解决多个节点如何在一定故障模型下，对重要状态形成可依赖的一致判断。
例如一个系统必须保证同一时间只有一个节点能够执行某项关键任务。这可能涉及领导者选举、Lease、Fencing Token、状态版本和协调服务。需要特别区分：Linearizability不等于Serializability。前者主要讨论并发操作在外部看来是否符合某种实时顺序的一致性要求；后者是事务隔离领域的概念，关注多个事务的执行效果是否等价于某种串行顺序。二者处理的是不同维度的正确性问题。这也是为什么架构讨论不能把“强一致性”当作一个没有进一步定义的营销词。真正应该问：系统究竟需要保证什么行为？
十三、CAP不是“在一致性、可用性、分区容错中任意选两个”
分布式系统讨论中，CAP经常被过度简化。例如CP数据库、AP数据库、三选二。这种说法作为入门记忆方式容易传播，但用于生产架构决策可能过于粗糙。
网络分区并不是工程师可以随意选择是否存在的现象。真实分布式系统必须面对网络故障。当通信确实发生分区时，一些特定的一致性和可用性目标之间会出现无法同时完全满足的限制。但现实系统的权衡远不止一个二选一标签。不同操作可以采用不同保证。有些业务可以短暂返回旧数据；有些业务宁可暂时不可用，也不能接受错误写入；有些系统通过本地优先体验、冲突合并或异步同步改善使用体验。
所以真正成熟的问题不是“我们是CP还是AP？”，而是：在什么故障条件下，对哪类操作，系统允许什么结果？这种思考方式比简单技术标签更接近实际架构设计。
十四、Batch Processing与Stream Processing：数据为什么需要不同的处理时间模型
数据处理系统还需要解决什么时候处理数据？传统Batch Processing通常是在一定范围内，对已有数据执行批量计算，例如每天汇总销售、定期清洗CRM、生成月度分析、重新计算客户分层。Stream Processing则面向持续产生的事件，例如订单创建、库存更新、支付成功、客户资料修改、系统异常。这些事件发生后，系统可以按一定延迟目标持续处理。
本书第二版分别讨论Batch Processing、Stream Processing，并增加了更完整的数据流系统设计视角。但实时并不天然优于批量。实时系统通常需要处理乱序事件、重复事件、事件时间与处理时间差异、状态恢复、Checkpoint、失败后的重放以及成本和运维复杂度。如果一项业务每天更新一次已经足够，那么为了追求“实时”部署复杂流处理系统，未必产生真正价值。
所以选择Batch还是Stream，首先应该回答：业务究竟需要多新鲜的数据？是秒级、分钟级、小时级，还是每天一次？这个问题应该先于具体技术选择。
十五、Change Data Capture：让数据库变化成为可治理的事件
对于企业AI系统，Change Data Capture，简称CDC，是一个值得理解的重要概念。它可以把数据库中的变化持续传递到下游系统。例如一条产品记录被修改，主数据库完成更新，变更信息经过CDC机制进入数据管道，下游系统再更新搜索索引、分析表、缓存和AI知识库。这种设计能够减少人工维护多个副本的成本。
但CDC也不是自动保证所有系统永远一致。仍然需要设计事件顺序、消费位置、重复处理、失败重试、删除事件、Schema变化、回放、重建和最终一致性延迟。例如产品信息已经在主数据库被删除，但向量索引没有收到删除事件，那么AI仍可能检索到不应该继续存在的内容。这不仅是数据新鲜度问题。当删除与权限、隐私或合规相关时，它还可能成为治理问题。因此：知识库更新机制，必须包含新增、修改和删除的完整生命周期。
十六、第二版为什么把Local-First与Durable Execution纳入讨论
新版有两个特别值得AI时代读者注意的方向。
第一个是：Local-First Software。它关注软件如何在保留本地控制、离线能力和用户数据自主性的同时，实现跨设备协作与同步。这与过去完全依赖中心化云服务的思路存在不同取舍。本地优先不意味着没有冲突。恰恰相反，它需要认真处理离线修改、多设备同步、并发编辑、冲突合并和数据所有权。
第二个是：Durable Execution。也就是让跨越较长时间、包含多个步骤的工作流，能够在故障或重启后恢复执行。这一概念对Agent非常重要。假设一个企业Agent执行：读取新询盘、查询产品数据库、生成技术建议、等待人工审批、创建报价草稿、更新CRM。整个流程可能持续几十分钟，甚至跨越数天。如果中途某个服务重启，系统不应该简单从第一步重新执行所有动作。否则可能出现重复发送、重复创建或状态冲突。
持久化工作流需要能够可靠记录：执行到哪一步、哪些动作已经完成、哪些结果需要恢复、哪些步骤可以安全重试、哪些动作必须重新获得批准。但Durable Execution不自动等于外部副作用Exactly-Once。跨系统业务正确性依然需要幂等、事务边界和补偿机制。这也是本书第二版与现代Agent工程之间非常重要的联系。
十七、AI系统的真正问题，可能是“多个正确的系统组合出了错误的结果”
这是我认为这本书最值得延伸的一层。假设企业拥有五个系统：CRM、产品数据库、文档管理、向量搜索、AI Agent。单独看，每个系统都可能正常。CRM能够查询，产品数据库能够返回记录，文档系统能够下载文件，向量搜索能够返回相关片段，Agent能够调用工具。但组合起来，仍然可能产生错误。
原因在于：CRM中的客户资料是今天的数据，产品参数是昨天的缓存，文档系统中有上周的技术版本，向量索引还没有更新。Agent则把这些来源组合成一份看起来完整的业务建议。于是：组件全部正常，整体结论却不正确。
这就是为什么生产AI系统必须关注End-to-End Correctness。不能只验证每个API是否返回200、每个数据库是否在线、每个工具能否调用。还要验证多个组件组合以后，是否仍满足关键业务不变量。例如引用的产品参数必须来自有效版本、用户不得访问无权限的客户数据、已经撤销的技术文件不能继续作为当前依据、一次批准不能被重复消费、同一订单不能被重复创建。这些约束必须在系统层面落实，不能全部交给语言模型自行判断。
十八、一个完整案例：怎样为企业AI知识助手设计可靠的数据基础设施
假设一家工业设备企业拥有以下系统：ERP负责产品与库存，CRM负责客户和商机，文档系统负责技术资料，网站负责公开产品信息。AI知识助手需要综合这些内容，回答员工和客户问题。
如果按照本书的原则设计，首先不是选择向量数据库。而是明确：每类数据的权威来源。例如产品参数以经过审核的产品主数据为准，客户信息以CRM相应记录为准，库存以ERP中定义的有效库存视图为准，技术资料必须具有版本和适用状态。
随后划定数据访问边界。员工可以查询内部报价信息，客户只能查询被授权公开的信息，不同客户之间的数据不能交叉暴露。
再建立数据流。业务系统发生变更后，通过可靠的数据管道更新下游搜索和AI检索系统。每条派生记录至少应能关联：来源系统、来源记录ID、版本或更新时间、有效状态和访问范围。对于无法及时同步或无法确认来源有效性的内容，AI应该采取更保守的行为，例如显示资料更新时间、请求重新查询权威系统、提示当前无法确认或暂停使用过期记录。对于实时库存、报价和订单状态等信息，通常应优先查询具有明确权限和一致性保证的业务接口，而不是仅依赖可能滞后的向量知识库。
最后还要建立监控，包括数据同步延迟、事件积压、同步失败次数、索引版本、无效引用比例、权限测试结果、异常重试和业务操作去重。这样建设的才是由可靠数据基础设施支撑的AI应用，而不只是一个接入了很多文档的聊天机器人。
十九、第二版最后一章提醒我们：能处理数据，不等于应该处理数据
《Designing Data-Intensive Applications》第二版最后一章的标题是：Doing the Right Thing。它讨论预测分析中的偏差与歧视、责任和问责、反馈回路、隐私、追踪与监控、用户同意、数据权力、法律与自律。这部分内容非常值得企业AI实践者认真阅读。
因为技术团队很容易把数据理解成Storage、Records、Events、Features、Embeddings。但数据往往描述的是真实的人和他们的活动，例如客户行为、员工绩效、用户位置、沟通记录、购买偏好、浏览历史。这些信息即使能够被技术系统采集，也不代表企业在任何场景下都有充分理由使用。
因此数据系统设计除了可靠性，还必须回答：为什么收集这些数据？处理目的是什么？谁有权访问？保存多久？用户是否具有必要的知情与控制权？是否存在不合理监控？系统错误可能伤害谁？这也是为什么AI数据基础设施不能只追求More Data，更需要Legitimate Data Use。真正成熟的企业系统，应该同时具备技术正确性与使用正当性。
二十、本周实践：用一张Data System Architecture Canvas重新审视一个AI项目
这一期不需要建立分布式数据库集群。更加值得实践的是选择一个真实网站、CRM流程或AI知识系统，为它建立一份简化的数据架构说明。只回答九个问题。
1. Business Invariants
哪些事情绝对不能出错？例如订单不可重复、权限不可越界、有效技术版本不可混淆。
2. System of Record
每一类关键事实的权威来源是什么？
3. Derived Data
哪些缓存、索引、统计表和向量库只是派生结果？
4. Freshness
不同业务允许多大的数据延迟？哪些字段必须实时查询？
5. Consistency
哪些操作必须具有更强一致性或事务保证？哪些允许最终一致？
6. Failure Handling
网络超时、数据源不可用、消息重复时怎样处理？
7. Recovery
能否重放事件、重建索引、恢复状态，并避免重复业务副作用？
8. Observability
发生错误以后，能否追溯来源、版本、时间及处理过程？
9. Ownership
谁负责数据定义、同步、访问权限、故障处理和最终业务正确性？
如果这九个问题都无法回答，那么系统即使已经成功上线，也可能存在大量尚未被发现的结构性风险。这份Canvas真正的价值是：把隐含的架构假设转化成可以检查和验证的设计决定。
二十一、如何开始，而不是直接建设一套复杂的数据平台
《Designing Data-Intensive Applications》讨论了大量深入的分布式系统技术。但普通企业不应该因为读了这本书，就立即引入所有架构模式。更合理的第一阶段，可以只做三件事。
第一，建立权威数据清单。明确哪些系统对哪些事实负责。
第二，找出最危险的数据同步链路。例如产品主数据到网站与AI知识库、CRM到销售自动化、订单系统到库存系统。
第三，为关键链路增加验证和恢复能力。例如版本检查、失败告警、事件去重、数据一致性抽样验证及回滚方案。
完成这三件事以后，再根据真实业务需求考虑是否需要CDC、独立搜索系统、消息队列、跨区域复制或更复杂的事务协调。不要把复杂架构当成工程成熟的证明。真正成熟的架构应该能够清楚解释：为什么需要这个组件，以及它解决了什么不能用更简单方式解决的问题。
二十二、把最近几期连接起来：可靠AI系统其实是一条完整的能力链
回顾前面的周读，会发现几本看似不同的书正在逐渐形成一套完整的系统观。
《Good Strategy/Bad Strategy》讨论：组织应该把资源集中到什么真正重要的问题上。
《High Output Management》讨论：怎样设计组织与流程，获得更高质量的产出。
《Designing Machine Learning Systems》讨论：怎样让模型从实验进入生产，并持续接受评估与改进。
《Designing Data-Intensive Applications》则进一步向下追问：这些模型、Agent和业务流程，依赖的数据基础设施究竟能否可靠工作？
它们之间存在清楚的关系：Strategy决定方向，Management配置资源，ML Engineering构建智能能力，Data Engineering保障信息流动，Distributed Systems维护关键一致性与故障边界，Governance约束权力、权限和责任。AI并不是独立于这一切之上的新系统。它越来越深地嵌入整套企业生产体系。所以真正建设企业AI能力，不能只购买模型服务。还需要让数据、软件、流程、组织与治理共同具备生产能力。
结语：真正可靠的数据系统，不是永远不出错，而是知道什么必须正确，以及出错以后怎样恢复
《Designing Data-Intensive Applications》第二版最重要的价值，并不是帮助我们记住更多数据库术语。而是改变我们理解技术系统的方式。
过去，我们容易问：数据库选哪一个？服务器买多大？用不用Kafka？是否部署向量数据库？是否需要微服务？但当真正理解数据系统设计以后，这些问题都会向后移动。更重要的问题变成：业务最不能接受什么错误？哪些数据必须保持一致？哪些结果允许短暂延迟？发生局部故障时，系统应该如何表现？网络请求超时以后，怎样避免重复执行？数据更新以后，搜索与AI系统怎样同步？某条记录被删除以后，哪些副本必须随之处理？系统扩大十倍以后，哪里会出现瓶颈？三年后，是否仍然有人能够理解和维护它？
这些问题没有简单、统一的答案。不同业务需要不同权衡。真正优秀的系统架构，并不是消除所有风险。而是：明确风险，设置边界，建立验证和恢复能力。
这一点在AI时代尤其重要。今天，我们越来越容易把复杂业务流程交给模型与Agent。它们能够读取信息、调用工具、生成结果，甚至自动执行工作。但一旦进入真实生产环境，可靠性就不再只是模型回答得是否聪明，而是整个系统能否持续维护正确的事实、正确的状态、正确的权限与正确的行为。
一个模型可能非常强大，但如果它读取的是旧数据，结果仍然会错。一个Agent可能规划得非常合理，但如果系统没有幂等机制，执行仍然可能重复。一个知识库可能检索得非常准确，但如果权限和删除同步失败，它仍然可能造成严重风险。
所以我认为，这本书在2026年最值得保留的一条认识是：AI系统的能力上限，越来越受模型能力影响；而AI系统的可信下限，仍然取决于整个数据与软件基础设施。前者决定系统能做什么，后者决定系统能否被放心使用。企业真正需要建设的，不只是越来越强的AI能力，更是让这些能力在真实世界中持续、正确、可控地运行的工程基础。
本期互动
选择一个正在运行的AI应用，假设明天发生三件事：上游数据更新失败、一次外部API请求超时、一条本应删除的客户记录仍存在于搜索索引。你能否准确说出系统会怎样表现？
如果不能，这可能比继续升级模型更值得优先研究。因为：真正的生产可靠性，首先来自对系统失败方式的理解。
本期参考资料
本期以第二版官方目录与作者维护的资料为主要依据，并将AI应用案例作为延伸分析。
- O’Reilly：《Designing Data-Intensive Applications, 2nd Edition》官方书籍与14章目录
- O’Reilly：第二版Preface
- Martin Kleppmann、Chris Riccomini：第二版官方文献参考仓库
- ScyllaDB：与两位作者关于第二版重构的访谈与讨论
- Martin Kleppmann：Please Stop Calling Databases CP or AP
说明：本期关于分布式系统、数据模型、复制、分片、事务、一致性与批流处理的技术讨论基于原书主题；关于2026年RAG、AI Agent、CRM自动化与企业知识系统的部分，是结合这些原理提出的实践性延伸，不应理解为作者对具体AI产品的直接评价。
下期预告
周读：《OpenAI Responses API》·OpenAI Official Documentation
下一期，我们从数据系统基础设施重新回到AI应用开发。如果《Designing Data-Intensive Applications》讨论的是可靠的数据怎样被存储、复制、协调和处理？那么接下来要面对的是：AI模型怎样安全、可靠地接入真实业务系统？
我们将围绕Responses API与生产环境AI工作流，重点研究模型调用与状态管理、工具调用及执行边界、结构化输出、文件搜索与外部数据、多步骤交互、错误恢复与评估、权限与安全，以及怎样避免把一段简单的模型调用代码，误认为一个已经成熟的AI生产系统。从数据可靠性走向AI应用可靠性，继续构建完整的AI工程知识体系。
标签
Designing Data-Intensive Applications,Martin Kleppmann,Chris Riccomini,DDIA,分布式系统,数据系统架构,数据库,Data Engineering,Reliability,Scalability,Maintainability,Replication,Sharding,Transactions,Consistency,Consensus,CDC,Stream Processing,Vector Database,RAG,AI Agent,AI基础设施,数据治理,系统设计,终身学习,周读