作者｜陈鹏，镜舟科技 技术副总裁

过去三十年，OLAP 引擎的发展核心始终围绕结构化数据的处理与分析，当然也取得了显著的进步，比如分布式架构、存算分离及 cloud native、查询性能大幅提升等。然而，随着大模型（LLM）技术的爆发，数据分析的范式正在发生根本性重构。行业预测显示，未来五年内，非结构化数据（文本、图像、音视频等）在企业数据资产中的占比将达到 80%。未来的数据形态将趋于多模态，分析需求将更加复杂，查询方式也将从单一的 SQL 转向自然语言与多模态混合检索。因此，我们需要在现代大数据分析平台基础上，全面拥抱 AI，构建下一代 AI-First Lakehouse。

一、基础设施演进：异构融合的存储与计算层

1. 存储层统一：管理多模态数据

目前大数据体系与 AI 体系存在严重的物理与逻辑割裂。

大数据团队习惯维护基于 Hive、OLAP、Lakehouse 等大数据平台来处理分析结构化数据，也诞生出业界主流的存储格式如 Parquet、ORC 等，能很好的支持结构化数据分析需求。而 AI 团队习惯在单机服务器或配备独立显卡的个人电脑（Laptop）上开发调试，数据以本地文件形式散落。

这种割裂导致数据无法统一存储，治理困难，且跨系统调用的性能极低，需先查数据库再调 AI 模型。但大数据时代的存储格式如 Parquet 的 Row Group 设计专为结构化数据优化，不再适配 AI 场景，AI 场景非结构化数据异构特性明显，同一批数据里，部分字段内容小，部分 embedding 后的字段会很大。

为此，可以考虑引入如 Lance 等专为 AI 设计的存储引擎，支持对文本、图像、视频等多模态数据的高效索引与存取。以实现统一管理分散在各处的非结构化数据，使得 Lakehouse 不仅是数据存储库，更是 AI 资产的统一底座。

2. CPU/GPU 异构计算统一调度

传统 OLAP 依赖 CPU 进行聚合、排序与过滤，而 AI 负载（如 Embedding 生成、非结构化数据解析、模型推理）高度依赖 GPU 资源。

计算引擎需从单一的 CPU 架构向 CPU/GPU 异构架构演进。系统应具备智能调度能力，根据任务类型自动分配计算资源，实现结构化查询与非结构化推理的混合执行。

典型场景：直播电商实时分析

单场直播会上架数十至上百个商品，每个商品展示时长仅 1-2 分钟。系统需同时处理两类数据：

• 结构化计算（CPU）：五维四率数据（曝光进房率、商品曝光率、商品点击率、成交转化率）等实时指标；

• 非结构化计算（GPU）：主播语音讲解分析、主播商品展示视频分析、助播互动表现、用户弹幕评论分析

业务方需要将“点击率”与“主播当时说了什么/做了什么”进行关联分析，以判断推荐是否精准，以及多种因素对成单的影响。这要求计算引擎具备异构资源管理能力，能够灵活调度 CPU 处理统计指标，调度 GPU 处理特征提取与推理，实现多模态数据的实时融合计算。

二、内核能力构建：AI 原生的查询与 In-Database 推理

1. 原生向量检索，从外挂到内核的能力下沉

简单的语义检索已无法满足高精度的业务需求，且外挂式的向量库方案会导致数据冗余与延迟，向量能力已经是多模态处理的必备项（Must-have）。同时引擎内核需要原生支持混合检索，并具备混合召回能力，结合关键词匹配（通过倒排索引实现）与语义检索（通过向量检索实现），通过粗排与精排的组合策略，满足如“搜合同关键条款”、“电商以图搜图”、“在线教育以图搜题”等高精度业务需求。

更进一步，随着越来越多不同类型、不同领域、不同维度的数据摄入 Lakehouse，内嵌知识图谱搜索能力也变得越来越重要，以便高效快捷的挖掘数据之间的关系。

2. In-Database AI ，写入即处理，查询即分析

（1）写入时处理

传统架构中，非结构化数据的 ETL 依赖外部脚本或独立工具链，维护成本高且容易形成数据孤岛。下一代系统应将 AI 能力内置于写入路径，系统自动调用内核级的解析（Parse）、分块（Chunking）、向量化（Embedding），实现从原始非结构化文件到可查询数据资产的自动化转换，无需人工深度介入即可完成打标与关联。

（2）查询时推理

将 LLM 能力内嵌至数据库内核，实现“查询即分析”。用户无需将数据导出至外部模型处理，而是直接在 SQL 中调用 AI 函数。

还是以直播评论分析为例，系统应能直接通过 SQL 调用内置 AI 能力，对海量弹幕进行情感分析，如：

• 自动过滤“扣 1”、“扣 2”等无意义评论；

• 识别具有购买意向的负面/正面反馈，甚至触发内置 Chatbot 进行自动回复。

相比调用外部 API，内置推理可利用本地数据过滤机制，仅对筛选后的高价值数据进行推理，大幅降低延迟与成本，并提升吞吐量。

将 AI 能力贯穿写入和查询全流程，让数据处理成为数据库的内置本能。这种架构下，数据从接入到分析的每个环节都被 AI 增强，消解了传统“先存储、后处理”模式的滞后性，使数据在落盘时即具备智能检索和分析能力。

三、面向 Agent 架构适配：从确定性查询到探索式执行

随着 AI Agent 应用的普及，数据交互模式将从“确定性查询”转向“探索式执行”。Agent 具有多轮推理、自我修正及高并发的特点，这对底层系统提出了新要求：

1. 极致弹性与高并发

Agent 通过多轮推理、自我修正来完成任务，且存在 Multi-Agent 场景，这将导致会产生海量、突发性的查询请求。系统需要具备毫秒级的弹性伸缩能力，支持多路 Agent 并发协作，来实现计算资源的即用即取与成本隔离。

2. 高效智能元数据管理

Agent 会频繁探索数据的 Schema 信息以理解数据结构，系统需提供高性能元数据管理服务，快速响应 Schema 查询。同时在查询元数据时除了常规的库表结构信息外，还应包含丰富的语义数据。

另外，不同于精确的 SQL，Agent 生成的查询往往很模糊。执行引擎需要支持描述性约束信息（例如，Agent 指令包含“精度要求>80%”或“查询超时<2 秒”），可以根据约束动态调整策略，允许在精度与资源消耗之间做权衡，而非僵硬地执行全量扫描。

四、平台自治：AI 反哺系统的自我进化

在基础层、内核层、以及架构层升级后，还可以思考进一步利用 AI 技术反哺 Lakehouse 自身的鲁棒性与性能。

• 学习最佳实践： 系统应自动学习内部海量日志中的 Best Practice，将其内化为引擎的管理能力。

• 智能故障排查： 利用 AI 自动定位数据库运行中的隐性问题，替代人工排查。

智能物化视图（Auto-MV）加速洞察

目前的物化视图依赖业务方手动创建，门槛较高。未来系统将结合慢查询分析与数据量特征，自动识别性能瓶颈，同时，学习用户的查询行为，自动创建并维护物化视图，从底层透明地加速查询响应，无需用户感知。

流畅开发：避免复杂的 UDF 依赖

对于复杂的业务逻辑与非结构化数据处理，不应强行依赖传统的 UDF，而应通过上述的内核级 AI 能力与开放接口来解决，提供更流畅的开发体验。

结语

下一代 AI-first Lakehouse 的构建是一个系统性工程，需要从数据处理、存储引擎、计算架构、Agent 支持以及平台生态进行全方位升级。核心目标是打破结构化与非结构化数据的壁垒，将 AI 能力从应用层下沉至内核层，构建真正面向 AI 时代的新一代数据平台。

本文分享了扩展云和分布式应用程序的目标与策略，重点介绍了摩根大通（JPMorgan Chase）旗下Chase.com在云迁移过程中汲取的经验教训。

讨论围绕三个核心目标展开，详细阐述了实现这些目标的具体策略，最后说明了这些方法在实践中的落地方式。对于管理大规模系统的从业者而言，这些经验源自我们在摩根大通及其他金融机构多年来的实战积累，具有宝贵的指导意义。

在规划的时候，人们通常只会考虑两到三倍的负载增长。然而，一旦系统部署在互联网上，就无法控制入站流量的规模、时间或使用模式。任何事件（无论是源于合法业务增长，还是恶意攻击者的行为）都可能引发巨大的负载激增。这两种情形各自会带来截然不同的挑战。

安全控制措施可以阻止恶意流量，但当市场波动引发真实客户需求激增时，情况则有所不同。客户恰恰会在这些情况下需要访问金融交易服务。在系统压力下，多个组件可能同时发生故障；网络设备、负载均衡器、应用程序和数据库连接都可能同时中断。

目标

我们的云迁移聚焦于三大核心目标：以成本效益高且高效的方式实现弹性扩展、实现高韧性（这对金融机构尤为重要），以及提供卓越性能，防止因系统迟缓而迫使用户转向其他服务。

高效扩展

实现高效性需要分析客户的使用模式和行为。组织必须在保持弹性扩展能力的同时，发展预测能力。

流量整形（Traffic shaping）提供了一种识别高频率功能的方法论，从而能够有针对性地对关键应用进行扩展。

整体容量管理是另一个关键要素。简单地增加服务器并不能保证成功，还需要仔细权衡成本的因素。

流量模式与容量规划

流量模式是高效扩展的基础。平均流量代表了系统日常处理的基准水平。可预测的模式确实存在，例如，工资入账等周期性事件会促使客户查询账户余额。全年还会出现季节性高峰，这要求提前规划。

突发事件则会带来不同的挑战。DDoS 攻击频繁发生，其流量可能超过正常负载十倍甚至更高。攻击者利用的是与合法用户相同的云资源。组织必须在阻断这些攻击的同时，确保合法客户的真实交易仍能满足服务等级协议（SLA）。

基于已知模式进行合理的容量规划有助于预防运维方面的问题。然而，弹性扩展存在局限性：在扩展过程中，应用程序需要启动并建立与服务及数据库的连接，而建立连接需要时间。从实例启动到完全就绪，可能已经过去数分钟。若大量请求恰好在此期间涌入，系统将面临资源争用的问题。

因此，不能仅依赖弹性扩展，而应该全面考虑完整的运维图景，包括流量模式及相关因素。预留计算容量（Reserved compute capacity）可以应对这些挑战。预留资源能在需要时保证可用性，尤其在多租户共享资源池出现争用时更为关键。此外，预留计算还能带来成本节约。

成本管理需要进行持续关注。应该定期（如每月或每周）应用 FinOps 流程，而非偶尔为之。

超越单纯增加服务器的扩展

扩展不应该局限于简单地增加服务器。当发生扩展时，有一个根本性的问题，那就是，应用程序是否真的因为真实客户的需求而需要扩展，还是因为上游服务排队导致响应变慢？当线程等待响应而无法执行时，CPU 和内存的压力会上升，即使实际需求并未增长，也会触发弹性扩展。

这种场景要求我们在设计中考虑容错，并将其与扩展策略整合。断路器（Circuit breaker）在此过程中会发挥关键作用。当上游服务变慢或失败时，断路器可以防止应用无限期等待响应，而是强制设置超时限制：系统要么在限定窗口内收到成功响应，要么快速失败并继续处理。这种设计可避免线程耗尽、减少不必要的资源消耗，并防止错误地触发扩展。如果没有断路器的话，缓慢的依赖项可能会引发全系统的性能退化，导致弹性扩展，从而添加更多无法解决根本问题的服务器。

高韧性

韧性（Resiliency）要求为不可避免的系统故障做好准备。早期检测和随时执行故障转移程序至关重要。然而，为所有组件实现 100%的可用性既不现实，也无必要。

基础设施可根据关键性分为四个层级。关键（Critical）类的组件必须尽可能接近 100%可用。DNS 就属此类，无论网站架构多么完善，DNS 如果出现故障将会导致所有访问中断。

可管理（Manageable）层的组件在发生故障时可通过故障转移维持运行，目标为“四个九”的可用性（99.99%，即每年可接受约 52 分钟的停机时间）。

可容忍（Tolerable）层的组件具备内置韧性。例如，缓存长期数据的令牌服务，若服务在缓存有效期内不可用，系统仍可使用已缓存的数据继续运行。

最后，可接受（Acceptable）层的组件允许有限的数据丢失，比如，某些日志系统。韧性目标由影响的严重程度决定。

性能

性能会显著影响用户体验和基础设施成本，但并非所有应用程序的表现完全相同。通过部署接入点（Point of Presence, PoP）可以提升用户体验，因为它对网站延迟（尤其在移动设备上）尤为敏感。

速度至关重要，因为它能建立用户信任，用户期望更快、更好的体验。谷歌等搜索引擎已经认识到这一点，并将速度纳入其排名算法。在网络连接受限的场景下，移动端性能尤为关键。从基础设施角度看，客户完成相同任务所花费的时间越少，运营成本就越低。

我们通过实施全面的性能策略，从初始部署到完整架构落地，系统延迟降低了 71%。这些策略可适配其他业务场景。

五大核心策略

架构方法围绕五个重点领域展开：多区域部署、高性能优化、全面自动化、具备自愈能力的可观测性，以及强大的安全性。

多区域部署

多区域架构通过隔离和分段实现功能化的解耦。这种方法有助于管理区域故障、可用区故障和网络故障，并限制故障的爆炸半径（blast radius）。面对 9400 万客户，可用区级别的故障可被限制为仅影响一小部分用户，而非全部用户。

实现多区域架构需要解决 DNS 管理的问题，因为不同区域拥有独立的负载均衡器，需要协调一致。还需要确定区域间流量的调度策略。在包含多个可用区的区域内，也需选择流量的分配方式。

可用区故障

假设一个负载均衡器将流量分发至同一区域内的两个可用区。两个应用均报告健康状态，可用区看似正常，流量持续流入。然而，如果其中一个可用区的应用与后端系统连接异常，而另一可用区正常，流量仍将流入受损的可用区。若应用虽实现了就绪（readiness）和存活（liveness）探针，却未将依赖系统状态纳入健康检查，那么就有可能出现问题。缺乏适当的反馈机制时，负载均衡器会继续路由流量，导致应用失败。

针对这种情况，解决方案包括将依赖系统的健康状态通过就绪或存活探针反馈给负载均衡器，或采用基于代理的重路由机制将流量导向正常的可用区。这需要有效管理内外部故障，以应对应用停机。

区域性的故障

在多区域部署中，我们依赖统一的区域健康脉搏检查（每 10 秒执行一次），以确保对区域健康状况的一致性和及时可见性。在这里，关键的决策在于，故障是否需要完全切换至备用区域，或者降级服务是否可接受。降级服务的可行性取决于应用的分段情况。若关键服务（如仪表盘首页）失效，则需要故障转移；若非关键组件失效，那么可以继续运行以避免更大的影响。但故障转移会引发“惊群效应”（thundering herd），例如，整个区域失效时，重定向流量突增可能压垮剩余区域，而自动扩展需要时间才能提供额外的容量。健康检查标准（包括失败与成功阈值）决定了对应的响应策略。

多区域的挑战

跨区域的数据复制与确保数据一致性是主要的关注点。当数据中心位置有限而客户遍布全国时，客户分片（customer sharding）是一种可行的方案：将客户按地理位置分片，并由就近的数据中心提供服务，这样可以减少复制的需求，并简化架构。

状态管理需要战略性的决策。为活跃会话维护会话亲和性（session affinity），并在必要时支持故障转移，这有助于高效运行。

高性能

高性能对用户体验至关重要。良好的性能如同可靠的拨号音，用户期望即时响应，不容延迟。边缘计算是实现性能目标的主要手段。现代网站具有复杂的用户界面，内容密集。我们可将静态内容卸载至靠近客户的入网点（Point of Presence，PoP），而源服务器（origin server）仅处理动态操作和关键服务，如登录、账户、支付等。

流量整形（traffic shaping）可以对流量进行分类。关键流量指的是支撑业务运营的核心功能，比如，客户日常的登录、余额查询和支付。分配给关键服务的资源必须始终保持运行。在压力条件下，即便其他流量出现降级也是可以接受的。

内容分发

地理分布会显著影响性能。如果每次资源请求都需要跨越很长的距离，物理网络的屏障将会造成显著的延迟。如果相同的内容已在 PoP 缓存，检索可在 100 毫秒内完成，远优于访问源站所需的较长响应时间（比如，大于 500 毫秒）。性能提升的同时会带来安全方面的收益，因为恶意的流量可以在边缘被拦截。

“最后一公里连接（last-mile connectivity）”的问题值得关注。互联网通信涉及多个网络跳转。边缘计算改变了这一模式，从用户到边缘节点通常只需要一跳，再结合优化的网络传输，这样所带来的效率远高于标准的 ISP-to-ISP 连接。

移动应用也有优化的空间。移动设备具备本地存储，可用于缓存网络解析结果、配置设置和预抓取的内容。

自动化

自动化是关键的战略元素。在整个流水线的各个阶段实施全面自动化可带来巨大收益，这需要涵盖部署、基础设施供应、环境配置、集成自动化操作的健康检查，以及整体的流量管理。

架构不能止步于文档。通过创建“带有倾向性的（opinionated）”架构模板，可以帮助团队构建自动继承架构标准的应用。应用通过基于清单（manifest）定义进行自动化部署，这样能够让团队聚焦业务功能，而非基础设施工具的复杂性。

基础设施“重铺”

基础设施“重铺（repaving）”是一种高效的实践，即在每个迭代周期系统性地重建基础设施。自动化的流程会定期清理运行中的实例。这种方式能够通过消除配置漂移（configuration drift）来增强安全性。当存在漂移或需要应用补丁（包括零日漏洞修复）时，所有更新均可系统性地实现。

长期运行会导致资源陈旧、性能下降和安全漏洞。我们可以定期（如每周或每两周）自动重建环境，步骤大致如下：先优雅地移除流量，再重建环境并重启服务，从而保障运维的稳定性。

重铺实现涉及多个组件：自动化脚本监控实例的生命周期；基于时间的有效性触发器会移除路由，阻止新请求进入但允许现有请求完成；随后关闭实例、清理节点并创建新实例。创建新实例时，可以使用更新后的镜像，以解决零日（zero-day）漏洞并添加安全补丁，也可以仅简单地重建实例。具体的操作由策略决定。所有流程均自动化完成，在重铺前会移除流量，确保对客户不会产生任何影响。

自动化故障转移

具备优雅降级能力的自动化故障转移需要考虑活跃的会话。对于正在进行处理的客户，会话的处理方式不同于新的会话，需要进行特殊路由。除此之外，必须防止故障转移循环，如果两个区域均不健康，持续切换只会加剧问题。不同场景对延迟容忍度不同；非关键服务故障时，可在受影响区域继续运行。

可观测性与自愈能力

可观测性要求对观测到的事件进行自动化的响应。云环境在各组件中会产生大量事件，比如系统事件、基础设施事件和应用事件。所有的可观测事件都需要自动处理。自动化会通过无服务器函数与可观测性进行集成，也就是在事件触发后，函数自动执行，并且会根据预设的条件切换在哪个区域执行。

数据库问题会触发独立的数据库切换函数；维护活动可以触发函数以屏蔽特定区域或虚拟私有网络（virtual private cloud，VPC）。这些示例场景展示了如何实现自动化行为，同时确保与可观测性的集成。仪表盘监控能够提供辅助价值，但不应该作为主要的响应机制。

健康检查

健康监控需要在多个层级进行。在应用层，健康判断可能涉及复杂的评估，不仅要检查应用本身是否正常运行，还包括与数据库、缓存及其他系统的连接是否通畅。健康检查器内部可以包含复杂的逻辑，但返回状态必须简单，仅用布尔值表示健康或不健康状态即可。

应用内的健康检查要向上传播至可用区这一层级，它要检查所有的实例。然后，这个信息转移至 VPC 层级，以评估整体 VPC 的健康状况，最终输入全局的路由器。每一层级均通过简单的布尔指标实现自动化健康评估，从而支持快速决策。该方法通过系统性健康检查以实现自愈的能力。

决策标准

我们可能会遇到如下的场景，告警指示节点不可用且容量受损，这可能是供应商的问题，流量需要从受影响的 VPC 进行重定向；应用告警显示延迟问题且性能受损，组织需要根据业务需求决定是继续提供降级服务，还是满足服务等级协议（service level agreement，SLA）的要求。在这样的场景中，选择降级服务意味着接受较慢的性能，而非切换至可能存在相同问题的其他可用区。

“灰度故障”（gray failures）指的是故障确定存在但连接仍存在的模糊故障场景。网络相关的故障更难诊断。当某项业务功能受损时，可以考虑将流量重路由至健康的可用区。可以基于可观测性数据执行多种应对措施。

健壮的安全性

安全需要采用零信任模型的分层实现。每一层必须独立运作，假定其他层均可能失效。客户端设备可能会被恶意软件攻陷；边界安全功能需要在边缘实现过滤和 Web 应用防火墙；内部网络需要分段和隔离；容器安全方面，需要进行镜像扫描并采用最小权限原则；应用安全方面，需要确保正确地认证与授权；数据安全方面，要实施加密与隐私控制。各层之间要实现互相强化。

迁移

文化转型是成功迁移的基础，因为云运维与传统的企业自建系统存在根本性的差异。云服务商会持续更新服务，网络策略在不断演进，浏览器也在不断变化，诸多因素都要求我们持续适应。Well-Architected Framework 及相关原则在这方面提供了指导。

“谁构建、谁拥有、谁部署”的所有权模型将责任赋予了应用团队。人为错误与疏忽不可避免，而自动化可以确保一致性。

测试与验证

测试方法各异。Chaos Monkey 等工具通过向运行中的系统注入故障实现反应式测试；失效模式与影响分析（FMEA，Failure Mode and Effects Analysis）则通过系统性组件评估进行预测性分析，识别潜在的故障并制定缓解策略。这两种方法均有它的价值，但 FMEA 更适用于在各应用层进行全面测试，确保能够开发分析与缓解策略。

公司开发了名为 TrueCD 的 CI/CD 方法论，这是一套包含了十二个步骤的自动化流程，相关文档已经在官方博客进行详细阐述。该流程类似于航空业的飞行前安全检查。

抽象层

从企业自建环境向云迁移会影响应用的架构。应用包含了大量的业务逻辑，持续变更可能对业务运维产生连锁影响。抽象层可以最大限度地减少此类影响。该架构方法可在单云、多云、自建环境或混合环境中灵活选用业界最佳组件。Dapr是一个广受认可的开源框架，支持多云架构。

迁移客户流量

大型应用的迁移无法一蹴而就。在初期，可以先在内部用户群体中验证系统，使应用趋于稳定。压缩时间表往往会适得其反，因为某些问题和使用模式需要长期观察才能发现。应用需要充足的运行时间以完成优化。

面对庞大的功能集，在有限时间内完成所有功能可能不现实。将系统拆分为离散应用集可以应对该挑战。在迁移的各个阶段，可逐步将小比例的客户群体进行迁移，最终再实现全面迁移。

结果

这些策略的实施带来了可衡量的成果：显著降低成本，性能指标大幅提升，平台在对比分析中名列前茅。Dynatrace 的公开报告对美国银行网站进行了比较，它指出实现亚秒级（<1 秒）响应的站点代表了最优的性能。

结论

从这些策略中可以提炼出一些关键的考量因素。权衡是不可避免的，我们需要综合考虑成本与性能，同时不损害其他的需求。例如，在多区域架构中，需要评估缓存复制策略：是在单区域还是多区域维护缓存？运维的复杂性随云架构组件的增多而上升。降低复杂性、减少应用监控中的人工干预至关重要，而自动化是实现这一目标的关键机制。

控制故障的爆炸半径始终至关重要。站点必然会遇到各种问题，组件难免失效。关键在于故障发生时的影响范围，是波及所有客户，还是仅限一小部分？这一关注点至关重要。我们必须建立面向行动的可观测性，并与自动化操作紧密关联起来。

所有决策必须以客户为中心。业务运营服务于客户。请思考“拨号音体验”：拿起电话，用户期望立即听到拨号音。应用亦应如此，用户打开移动应用，理应立即看到结果。

核心原则：智能扩展，保持可靠性。当下一次流量激增不可避免地到来时，系统弱点必将暴露出来。这些策略的直接目标在于，当流量激增时，关键组件必须能够保持运行，核心系统必须维持响应能力，客户必须像往常一样获得即时响应。

原文链接：

Scaling Cloud and Distributed Applications: Lessons and Strategies

引言：悖论

数据能够反映出很有意思的现实。麦肯锡的“人工智能现状（State of AI）”报告显示，72%的组织已经在至少一项业务职能中采用了 AI。投资速度令人震惊，数百亿美元正在被投入 AI 研究，企业为 AI 项目划拨了前所未有的预算。然而，在现实中，大多数组织并没有从中获得实质性的价值。

一个鲜明的例子是优步的Michelangelo平台（来自Wang Kai等人）。该平台经过多年建设，已经成为其机器学习的基础设施，能够使开发团队快速掌控自身的领域，并部署从路径优化到需求预测等各类解决方案。随着 AI 技术演进，优步进一步利用生成式 AI（GenAI）加速了开发进程。正是由于早已建立了坚实的组织与技术基础，优步才能在 AI 浪潮中占据先机。

与此同时，过去几年采纳 AI 的大多数大型企业却难以突破试点阶段。这些企业拥有相同的技术和知识资源，却缺乏必要的组织结构与平台来释放 AI 的真正价值。Gartner 2025年的研究显示，在 AI 成熟度较高的组织中，仅有 45%能将项目维持三年以上，此外，57%的高成熟度组织已准备好采用新的 AI 解决方案，而低成熟度组织中这一比例仅为 14%。

我们谈论的 vs 真正重要的

正如麦肯锡的AI状态报告所示，AI 的采纳速度在不同行业及组织内部不同类型工作中呈现出显著的差异。在软件平台与工程领域，AI 的应用已明显加速。

随着开发与 DevOps 社区拥抱 AI，其放大效应显而易见。谷歌的“DORA：AI辅助软件开发现状”报告指出，采用 AI 带来了可观的收益，包括：

• 个体效能的提升

• 工作重心转向更高价值任务

• 产品性能改善

• 代码质量提高

• 组织整体绩效增强

然而，尽管技术在不断进步，但是组织层面的影响仍参差不齐。JetBrains 的“开发者生态系统现状”调查显示，超过 50%的开发者每天有 20%至 60%的时间花在会议、工作聊天和邮件上。沟通与状态对齐仍是核心挑战。矛盾点在于，更快地交付成果，并不必然意味着更快地创造商业价值。

将更多精力投入到理解价值流与业务上下文，才是交付更高价值的可行路径。架构师在此过程中扮演关键角色，也就是弥合组织目标与开发速度之间的鸿沟。他们帮助团队设计具备韧性、可扩展的系统，将业务意图转化为稳健的技术实现。

归根结底，真正重要的并非我们编码或部署的速度有多快，而是我们能否有效地将持续改进融入业务运营与组织体系之中。

迈向 AI 驱动的持续变革流

显然，人工智能（尤其是生成式 AI 和 AI Agent）正在促使组织重新思考如何适应持续发生的变化。但这并不意味着传统的架构定义方法已经过时。相反，这条路径在于利用 AI 增强既有的架构实践，从而在业务上下文、设计与交付之间建立持续的流动。

Anthropic 的“经济指数报告”基于数百万条匿名的 Claude 对话数据，将用户与 Claude 的交互模式分为两类：自动化（AI 在无需显著用户输入的情况下完成任务）和增强（用户与 AI 协作完成任务）。不到两年间，自动化交互占比从 41%上升至 49%，而增强型交互则从 55%下降至 47%。

这为软件相关工作中 AI 的应用提供了一个有趣的代理指标：尽管 AI 工具和 Agentic AI 发展迅速，但用户正越来越多地依赖 AI 处理更复杂的组织任务。在技术驱动型组织中可以推断，虽然 AI 已经能够显著提升个体在离散任务上的生产力（自动化），但在组织流程层面的更大效率增益（与增强相关）仍面临障碍，主要是数据就绪度和业务领域上下文信息的缺失。在 CGI 的架构实践中，当组织试图将 AI 从孤立试点扩展到规模化应用时，这些挑战反复出现，凸显了领域清晰度与上下文工程（context engineering）的重要性。

架构师支持组织从个体生产力提升迈向整体运营效率的提升。这需要架构层面的努力来保障组织资产，即确保数据可用性、明确业务上下文边界，并重新对齐流程。如前所述，这些需求本质上是人力、组织或信息层面的，而非单纯的技术栈现代化。新兴的业务需求将要求更高的一致性与清晰度，以便 AI Agent 或 AI 辅助开发团队能在组织层面实现改进。在此背景下，架构的意义愈发聚焦于赋能人类与 AI 智能体协同演进的流动机制。

为何“快速流动”优先？

如前所述，AI 如同水流，会沿着组织现有的渠道渗透。渠道清晰直接，流动便会加速，渠道曲折狭窄或存在死胡同，则引发洪涝与瓶颈。在组织的语境中，“快速流动”指快速响应变化并基于早期反馈及时调整航向的能力。它关注系统级的敏捷性，即快速收集、理解并将业务需求转化为可交付解决方案的能力。这种流动必须与真实用户需求和业务战略对齐，而不仅仅是追求技术效率。实现快速流动的组织通常具备四大特征：

1. 业务对齐（Business alignment）

2. 清晰的领域边界（Clear domain boundaries）

3. 可控的认知负荷（Managed cognitive load）

4. 优化的交互模式（Optimized interaction patterns）

战略对齐确保 AI 解决的是真正的问题。在考虑技术之前，快速流动型的组织始终紧密耦合业务战略、用户需求与技术领域。团队清楚自己的工作对用户的意义及其如何驱动商业价值。当这类组织采纳 AI 时，目标明确指向特定用户的痛点与战略业务目标。而许多组织则为了“现代化”而部署 AI，未与用户成果建立清晰的联系，这可能会取得技术成功，却遭遇商业方面的失败。

清晰的领域边界使 AI 能在业务上下文中安全自治。当团队所负责的领域明确对应业务能力与用户需求时，AI 就可以在这些边界内有效地运作。这种对齐意味着 AI 决策天然反映业务规则与用户诉求。如果缺乏这种清晰性，技术边界与业务边界脱节，将放大系统的模糊性与复杂性。从领域驱动设计（DDD）视角看，要实现 AI 支持的组织效率提升，架构师可能需要更新限界上下文（bounded contexts）的交互模式，审视核心子域的关键流程，或优化支撑性子域的流程。

优化交互模式确保跨边界协作始终以用户为中心。在快速流动型的组织中，团队互动是有意设计且定期复盘的。缺乏这种纪律，会经常导致多个团队重复解决相同的问题、构建相同的方案。为了应对混乱，有些组织又走向了另一个极端，即强制所有人频繁沟通，这反而会引发了混乱。快速流动型组织采用 Team Topologies 框架，在必要时促成团队高效协作与沟通。

激活流动性

为了说明 AI 在架构中的流动应用，我们描述一个组织在生成新解决方案规范（specification）时如何借助 AI 的历程。他们并非一开始就得出了结论，而是经历了启动、激活流动性，并在推进过程中不断演进架构方法的过程。

以下案例研究展示了“架构流动性”在实践中的具体体现。在 CGI 的一项倡议中，目标是将 AI 用例转化为跨多个业务解决方案的规模化 AI 实现。

团队首先通过战略指导，超越传统的研讨会，加速将业务 AI 的用例推进至概念验证（Proof of Concept，PoC）实现阶段。为此，团队推出了一种队列式（cohort-based）的计划，与各团队合作细化业务价值、用户旅程及潜在的 AI 用例。通过快速迭代，我们将 UI 原型迅速转化为 PoC 实现。

业务负责人通过 UI 原型直观感受到 AI 的潜在影响与收益，同时也能看到其他团队的思路。除了宝贵的协作体验外，开发者也首次拥有了明确的视觉目标来指导实现。持续的积极反馈证明该计划深受参与者认可。下图展示了该队列式流程的迭代循环及其输入/输出：定义用户旅程、原型设计、演进 AI 辅助的规范。

在启动阶段，团队通过调研业务负责人，使用统一的 MadLib 格式确认优先的主题与用户故事（基于“Next Best Action/Recommendation”框架）：

根据每期队列的战略主题，邀请团队成员。在首次研讨会中，队列成员深入探讨所选用户故事并定义用户旅程。随着时间推移，队列逐渐转向通过自然对话描述上下文，而非提交结构化输入，用户故事演变为由业务负责人讲述简短故事后自动生成。贯穿队列过程的一项关键考量是，在有限时间内平衡交付引人注目的成果与保持专注性。

因此，首次研讨会聚焦于使用简洁布局定义用户旅程图（如下图），以价值流图为背景（触发事件 → 步骤 1 → 步骤 2 … → 步骤 6 → 结束事件/结果），并按故事板划分泳道（角色、行动、情绪、痛点、机会、交付价值）。

在明确 PoC 范围的上下文与边界后，UX 设计师与队列快速协作，设计 UI 线框图与可点击的原型。设计师在“过渡仪式（cross-over ceremony）”中向队列展示成果，随后由一支精简的跨职能小队（全栈开发、数据科学家、提示工程师、AI 解决方案架构师）接手，使用不同模型、算法与方法推进 PoC。最终仪式展示了每个 PoC 的可行选项。该小队的核心目标是直接用 AI 解决业务挑战，并因聚焦队列优先级，与业务价值建立更直接的联系。

团队采取滚动交付模式，每月产出 2–3 个 UI 原型或 AI PoC 实现。他们运行了多个队列，获得宝贵反馈并持续优化策略。然而，下一个挑战随之而来：如何将这些早期解决方案推进至生产级实现？

不出所料，实现团队提出的第一个问题就是：“规范文档在哪里？”尽管 PoC 有记录，但它们不能被视为可供其他团队进行实现的设计规范。这一挑战在 CGI 的转型项目中十分常见：PoC 能带来清晰的认知，却往往缺乏下游交付团队所需的结构化规范。

不过，在过去 6 个月中，团队已积累了超过 50 小时的设计会议、UI 原型演示和 PoC 实现记录。为避免回溯成本（比如，重新召集分析师和设计师细化方案），团队转而采用上下文工程（context engineering），利用基础模型（Gemini 与 GPT 表现相当）进行处理。

假设：给定一个精心策划的设计模式知识库和标准输出格式，团队可以从对话记录或研讨会白板内容中生成一致的用户故事与用例规范。业务负责人认为生成结果的方向是正确的。

生成的规范包含典型的正常流与异常流，并涵盖系统组件、依赖关系等设计元素，附带初步的结构图与交互图。经过迭代，甚至纳入了旅程图，并根据故事叙述中的关键词自动分配情绪分值。团队进一步扩展规范，加入了验收标准、初始测试用例，以及安全、数据隐私等方面的检查清单问题，供实现阶段回答。

生成这些规范的基础是一个围绕实现设计模式（implementation design pattern）构建的知识库。团队扩展了传统的设计模式格式，加入检查清单问题，使生成的规范涵盖了以下的关键维度：

• 采纳与商业价值：确保方案能够交付可衡量的业务成果，并通过清晰的价值对齐与用户采纳策略获得认可；

• 用户体验：强调实现中的考量因素，确保用户交互直观、透明、可信，提升全程的信心、参与度与满意度；

• 运维因素：通过健壮的监控、性能与生命周期管理，维持可靠、可扩展、可解释的 AI 系统；

• 合规性与治理：嵌入伦理、法律和审计框架，以确保 AI 的运维能够负责任、透明且符合法规要求。

• 数据源与集成：定义数据质量、可访问性及连接性等考量因素，确保方案有效运行与可持续性；

• 安全与数据隐私：尽量左移（shift left），从源头将安全与隐私纳入考量。

这些实现设计模式从一开始就按业务负责人排序的 AI 用例优先级进行分类归档，形成以下原型：

• 原型 1：对话式 Agent

• 原型 2：AI 驱动的异常检测

• 原型 3：超个性化与下一步最佳行动/推荐

• 原型 4：智能工作流自动化

• 原型 5：多模态与全渠道 AI

• 原型 6：预测性维护与安全监控

• ……（随着流动持续，将涌现更多原型）

• 默认模式实现的考量因素

下图展示了这些原型按架构关注点（UX 与交互、监控与感知、业务流程与规则）的分类，为默认模式实现提供了有用的参考。

随着知识库不断扩充，团队现在能从一次研讨会讨论中自动生成包含验收标准和“左移”要素（比如，安全、隐私甚至法律视角）的完整规范初稿。但是，需要注意，团队的核心目标是构建扎实的架构知识上下文，而非开发工具。

AI 与 AI Agent 持续演进。尽管团队正在探索如何根据规范反向生成 UI 原型，但从架构的视角来看，其信心源于精心策划的知识库。随着规范驱动开发（Specification-Driven Development, SDD，参见“理解SDD”）理念的兴起（比如，Spec Kit，一款基于AI的SDD工具包），团队更加确信自己走在正确道路上。这一旅程远未结束，AI 在架构中的应用方式将持续演变，并会改变架构师的工作范式。

上述案例特别适用于“绿地”（greenfield）场景，也就是架构师与团队有足够的空间在启动新方案或向现有系统引入创新时，主导对 AI 的应用。然而，大多数组织还维系着支撑核心业务能力的成熟系统体系。这些系统构成一幅马赛克式的实现图景，各自处于不同生命周期阶段。对于那些专门构建的系统，其最新架构视图很可能已“铭刻于代码之中”。

毫无疑问，编码助手、Copilot 和编码 Agent 已经引起开发者的广泛关注，他们日益将其用于日常的开发活动，从代码补全、文档生成，到覆盖整个软件开发生命周期（SDLC）的更高级能力，SDLC 中的变革之流从未停歇。

在这样的“棕地”（brownfield）环境中，将 AI 应用于架构的机会广阔而多元化。AI 可在多个阶段帮助架构师弥合组织业务能力与技术实现之间的鸿沟。例如：

• 使用 AI 来支持架构评估：评估架构决策的各个方面非常适合结合上下文工程与先进的基础模型（比如，Gemini、GPT、Claude 等）。更稳健的权衡结果（例如，扫描技术选项以填补架构能力缺口）需要以关键架构原则和其他架构需求为依据。此外，采用少样本提示（few-shot prompting）技术，通过提供“好/中/差”示例，可引导权衡分析。此类策略可用于多种架构权衡的场景（例如，给定某种实现方案，更适合单体还是微服务？事件驱动还是 API 驱动？）

• 使用 AI 来生成规范性架构：在大型组织中，常见的棕地环境挑战在于，随着时间的推移，架构发生了漂移但并未文档化，甚至缺乏架构图与文档。这些应用多为大规模单体系统，而掌握其知识的人员往往已调岗或离职。手动逆向工程风险高、耗时长。此时，AI 可评估应用并自动生成操作手册、架构图、数据模型与依赖关系等必要的文档。

• AI Agent 提出架构与设计方面的更新：在 DevSecOps 中，AI Agent 正被用于持续摄取运行时事件流。它们可能监控已部署方案的安全漏洞，或分析运行日志以减少事件噪音与冗余工单。通过识别重复漏洞或运行模式，Agent 可在适当时机提出设计改进建议。

结论：前行之路

人工智能本身无法凭空创造组织能力。人类必须先以组织知识为其基础，AI 才能强化已有的基石。成功与停滞的分野，不仅在于模型、工具或基础设施的选择，更取决于组织是否具备支撑 AI 快速演进的架构基础。清晰的领域边界、可控的认知负荷、对齐的价值流，才能让 AI 增强交付，而不是仅仅添加复杂性。在此意义上来讲，架构师与架构本身成为 AI 的赋能者，而非旁观者。

正如案例所示，当架构师从控制结果转向框定上下文（定义语义、边界与护栏，使 AI 及未来的 AI Agent 自治变得安全可靠），AI 的承诺才能真正兑现。

真正的问题并非“如何采纳 AI”，而是“如何演进我们的架构，以支持 AI 增强的持续变革流”。

原文链接：

Architecture in a Flow of AI-Augmented Change

微软正式发布SharePoint Framework (SPFx) 1.22版本，该版本专注于现代化 SPFx 开发者的构建和工具使用体验。这一转变标志着 SPFx 解决方案构建方式的基础性更新，旨在解决技术债务、提升可扩展性，并与更广泛的微软工具链标准保持一致。

在此之前，SPFx 项目依赖基于Gulp的构建工具链来协调编译、打包等任务。尽管这种方式被大家所熟知，但相对于现代化的 JavaScript 和 TypeScript 工作流来说，这种模式早已被认为是过时的。同时，旧版 SPFx 的模板和生成器输出触发了npm audit漏洞，并落后于当前的依赖预期。1.2 版本通过过渡到新的工具链并清理脚手架解决方案中的漏洞解决了这些问题。

SPFx 1.22 更新的核心是从基于 Gulp 的工具链转向基于Heft的工具链。Heft（来自 Rush Stack 生态系统的配置驱动的构建编排器）现在为新的 SPFx 项目管理构建任务，而底层的打包继续使用 Webpack。这一转变使 SPFx 的开发与当代构建生态系统保持一致，使得构建更加透明、可维护，并便于未来的工具增强。如果需要的话，现有项目升级到 1.22 后可以继续使用传统的 Gulp 工作流，但使用 Yeoman 新建的项目默认采用 Heft。

Heft 的引入解决了长期以来开发者对 SPFx 工具链类似“黑箱”的担忧。据微软介绍，Heft 具备带有明确的倾向性和基于插件功能的设计，允许实现更透明、更易于维护的构建，并有助于未来工具的改进。它支持共享配置(rig.json)，简化了 TypeScript 的设置，并提供了原生 Webpack 配置选项。然而，从自定义gulpfile.js进行迁移可能需要一些重要的调整，尤其是对于那些使用定制构建步骤的团队。

此次发布的另一个重要现代化措施是解决了 SPFx Yeoman 生成器和脚手架项目输出中由npm audit报告的所有已知的安全漏洞。在使用最新的生成器生成一个新脚手架项目时，开发者将不会再看到npm audit报告的高严重性问题，从而提高了开箱即用的安全基线信心。微软还重置了脚手架模板中默认的 TypeScript 版本至 5.8，让开发者能够使用最新的语言特性及改进的工具支持。

此次发布没有对先前支持的 API 引入任何功能弃用（deprecations）。然而，微软明确指出，未来将仅对旧版 Gulp 构建系统提供关键性修复。在即将发布的 SPFx 1.23 版本中，新建项目将仅使用 Heft（前提是 CLI 工具已准备就绪）。到 SPFx 1.24，基于 Gulp 的构建管道将被正式标记为不支持（officially unsupported）。这意味着开发者应尽早规划迁移路径，尤其是依赖自定义 Gulp 任务的团队，以确保与未来 SPFx 版本的兼容性。

社区在社交媒体上的反应既表现出兴奋也带有一定的谨慎。在 LinkedIn 上，微软 365 开发者社区的成员强调了构建系统变更的重要性，指出“这不是一个简单的更新”，尤其是考虑到从 Gulp 到 Heft 的转换。一些开发者已经开始分享教程和资源以帮助他人适应新的 Heft 工作流。其他人则提到，迁移现有的项目是一项不小的挑战，尤其是对于拥有自定义 Gulp 任务或扩展的团队，并正在讨论逐步迁移的具体策略。

展望未来，SPFx 的路线图包括进一步解耦 CLI、开源模板以及与 Rush Stack 工具更深入的集成。鼓励开发者现在就开始探索 Heft，以熟悉未来的迁移路径并符合微软的发展方向。

关于完整的发布说明和 Heft 迁移指南，请参阅 SPFx 1.22发布说明和工具链文档。

原文链接：

SharePoint Framework 1.22 Ships with Heft-Based Build Toolchain and Refreshed Project Baseline

Agoda的“2025年AI开发者报告”显示，AI 在东南亚和印度已成为开发者的主流工具，在带来切实生产力提升的同时，也引发了关于可靠性、技能发展和组织准备度的新问题。

报告显示，AI 的采用已经基本达到普及的水平，95%的东南亚和印度开发者每周都会使用 AI 工具，超过一半的人在工作时会始终保持一个 AI 助手处于开启状态。开发者普遍感受到了效率的提升，但他们将这种影响描述为稳定而渐进的增益，而非对其工作的彻底自动化。

尽管使用率很高，但是开发者对 AI 的依赖却十分务实。提升生产力是主要驱动力，80%的受访者将“加快编码速度”和“协助处理常规编码任务”列为关键收益。然而，大多数人仍将 AI 视为需要监督的助手，而非可自主行动的代理。Agoda 将此总结为：“AI 已成主流，但尚未成熟”，当前的工作流程与保障机制仍在追赶工具本身的发展速度。

报告揭示了一个显著差距，即开发者行为与组织治理之间存在脱节。工具选择已经趋于集中化，约 87%的受访者使用 ChatGPT，许多人认为自己的集成开发环境（IDE）已具备 AI 就绪的能力，但正式的政策却明显滞后，仅有约四分之一的团队表示其工作遵循官方的 AI 使用指南，约 60%的开发者称所在组织尚未制定任何正式的 AI 政策。

在实践中，开发者正通过自下而上的方式填补这一空白。近 80%的受访者将“可靠性不足”和“输出不一致”列为阻碍更广泛使用 AI 的首要障碍。然而，67%的人表示他们会在合并前持续审查 AI 生成的代码，约 70%的人会常规性地重写或修正 AI 输出以确保正确性。报告指出，这种“默认审查”（review-by-default）的文化，正在将高采纳率转化为负责任的使用实践，不过自上而下的治理框架尚未完全建立。

研究还强调了强烈的自主学习的趋势，约 87%的开发者表示他们正在通过在线资料、实验和同行交流等方式自我培训 AI 技能，而非依赖公司提供的正式培训项目。与此同时，期待值也在上升，超过一半的开发者认为，AI 熟练度应该成为招聘的基本要求，许多人视 AI 能力为职业发展的关键要素。

Agoda 指出，该地区的开发者普遍将 AI 视为增强工作而非取代其工作的手段。但这种自下而上的势头也可能暴露出资源获取与支持体系的不均衡。报告呼吁企业需要迎头赶上，通过提供结构化培训、更清晰的政策以及将实验与安全、合规性及长期能力建设相协调的框架，来支持一线开发者。

 报告总结指出了三个现实情况：AI 已经成为主流，但分布不均；AI 正通过问责机制逐步演进；不同市场和企业间，AI 使用经验差异显著。大多数开发者每周节省的时间在 1 至 6 小时之间，最大收益体现在编码、调试以及学习新 API 或框架等环节，并非整项任务的完全自动化。

Agoda 首席技术官 Idan Zalzberg 将此视为软件构建方式的转变，而非构建者本身的更替：AI 正嵌入日常开发流程（从代码审查到团队协作），但人类的判断与监督仍居核心地位。报告最后指出，该地区真正的机遇在于，将这种自下而上的实验精神，与更强大的信任机制、问责体系和共享实践相结合，从而将近乎全民的 AI 应用，转化为一种可持续、区域级的工程能力。

原文链接：

How Developers in Southeast Asia and India Are Really Using AI in 2025