InfoQ 推荐

Cloudflare 推出支持零信任部署和迁移的代理技能

作者：Steef-Jan Wiggers — Wed, 01 Jul 2026 03:00:00 GMT

最近，Cloudflare 发布了 Cloudflare One 套件"，这是一个开源的代理技能库"，可以为 AI 代理提供规划、部署、管理和迁移零信任环境所需的知识，而且不需要从业人员事先学习完整的产品套件。这些技能以两个轻量级文件的形式发布，任何智能代理均可以加载：cloudflare-one 用于提供产品指导，cloudflare-one-migration 用于实现供应商间的转换，其中包含从 Zscaler 和 Palo Alto Networks 迁移的明确逻辑。来自 Cloudflare 的 AJ Gerstenhaber 和 Abe Carryl 写道"：

各团队已经开始使用智能代理来编写代码、筛选警报以及自动化工作流。但仅凭智能代理本身，并不能掌握组织特有的网络拓扑或供应商配置的细微差别。

迁移功能是最能让安全团队立即受益的部分。只需让智能助手将你的 Zscaler Private Access 应用程序迁移到 Cloudflare Access，该技能便能自动将 Zscaler 应用程序的定义映射到 Cloudflare 的对等功能，转换用户组和策略，通过 Cloudflare API 创建资源，并生成一份汇总报告，列明那些项已经迁移完成，哪些项需要人工审核。该迁移采用了与 Cloudflare Descaler" 和 Deskope" 计划相同的逻辑。这两项计划已经帮助企业客户在数小时内（而非数月）从 Zscaler 和 Netskope 迁移至 Cloudflare。该技术栈使任何客户或合作伙伴都可以自行迁移，无需预约任何专项服务。

每个技能文件都包含结构化知识、决策树和工具定义，当上下文匹配时，代理会自动加载这些内容。此外，cloudflare-one 技能涵盖了完整的生命周期：使用 Cloudflare Access 替代 VPN；通过 Gateway 保障用户和网络安全；通过 Tunnel、Mesh 和 WAN 实现连接；使用数字体验监控（DEX）工具包进行故障排除；根据实时账户中观察到的流量提供自动规则建议。只需要求代理替换你的 VPN 基础设施，该技能便会盘点现有的应用程序，将每个应用程序映射到相应的 Cloudflare 基础组件，生成一套能最大限度减少切换期间服务中断的部署序列，并在应用任何更改之前生成配置摘要供团队审核。

当与 Cloudflare 代码模式 MCP 服务器"配合使用时，这些技能将获得一个 Cloudflare API 的类型化接口。这样一来，代理就可以查询实时账户配置，检查策略，并通过经过精心设计的流程进行修改，而非通过临时的 API 调用。由于 MCP 服务器会单独处理身份验证凭据，所以这些凭据不会进入模型上下文。

实际的问题在于，安全团队是否已经准备好让代理参与零信任配置。该技术栈采用“应用前审核”的模式：代理提出变更建议并生成摘要，但在任何变更提交之前，必须由安全从业人员进行审核和批准。正如一位安全从业人员在 X 上指出的那样"：

这并非取代安全团队，而是缩短了从意图到配置策略的流程。企业需要考虑的是，是否生成的每项变更都附有审批、差异对比、负责人及回滚信息。

安全基础设施的边界需得把握得当，否则配置错误的网关策略或不正确的访问应用程序映射可能会导致内部服务暴露或用户被锁定。

对于 Cloudflare 的合作伙伴网络而言，该技术栈相当于一整套打包的专业知识。为客户部署 Cloudflare One 的合作伙伴可以利用这些技能加快部署速度、更准确地排查故障，并减少此前需要手动操作且容易出错的供应商转换工作所耗费的时间。

Cloudflare One 技术栈现已在 GitHub 上发布"。针对更多迁移来源和高级故障排除工作流的新技能正在开发当中。

原文链接：https://www.infoq.com/news/2026/06/cloudflare-one-stack-agents/"

在企业内部构建欧洲云编排平台

作者：Ben Linders — Wed, 01 Jul 2026 01:40:55 GMT

现代云部署涉及许多具有不同生命周期的工具，给工程师带来了沉重的负担。Kubernetes 生态系统提供了一种统一的控制平面方案。在 KubeCon & CloudNativeCon 欧洲大会"上， Maximilian Techritz 和 Johannes Ott 发表了题为“如何在企业内部构建欧洲云编排平台"”的演讲。他们展示了如何通过技术分享和内部开源协作来分享最佳实践，从而打造了一个人们积极参与的社区并推动了这项技术的采用。

Ott 提到，我们会编写应用程序并将其部署到服务器上，创建和配置数据库，管理和持久化安全密钥，并与来自内外部供应商的众多现有服务进行集成。为了管理所有这些不同的方面，需要用到许多工具，而这些工具都有各自的使用模式和生命周期。这些工具可能包括管道、命令行界面（CLI）、基于工单的配置、Click-Ops 等。

Ott 解释道，在发布软件新版本时，我们必须通过验证来保证整个复杂的工具链中没有任何环节出现故障：

我们的工程师不得不承担维护和开发技术栈的重担，这占用了他们大量本应用于开发工作的时间和精力。世界正变得日益复杂。软件不再仅仅部署到少数几个数据中心里，而是越来越多地部署到私有云和主权云中。

在重新考虑如何处理云编排时，他们很清楚，仅靠另外开发一个工具无法解决这个问题。Techritz 表示，他们考察了现有的开源生态系统和工具。借助 Kubernetes 生态系统，他们可以用声明式的方式，将所有期望的外部云资源配置应用到 Kubernetes 控制平面中：

我们拥有诸如 Crossplane 之类的工具。它使我们能够管理 Google Cloud Platform 上的数据库、AWS 上的存储桶，以及 Microsoft Azure 上的网络策略。我们只需要在控制平面（Control Plane）上指定这些资源的目标状态即可。在 Kubernetes 集群中运行的专用控制器会持续不断地与云服务提供商的实际 API 进行同步，据此创建资源、获取其状态，或对其进行更新和删除。

Techritz 补充道，诸如 External Secrets Operator 之类的工具可以在不同位置之间同步和轮换凭据，Kyverno 可以定义符合公司规定的自定义策略，而 Flux 则能将所有配置文件放入 Git 存储库中，以践行 GitOps 最佳实践：

这些工具目前都已经公开发布。它们提供了相似的用户界面和操作体验，并且能与 Kubernetes 生态系统无缝集成。

Techritz 表示，OpenControlPlane" 允许企业通过运行一个平台来向其开发团队提供控制平面。平台所有者定义开发团队应该如何使用密钥、数据库和应用程序。开发团队只需要订购一个控制平面，即可获得预先安装并且配置好的运维工具；他们不用自己操心安装和管理所有这些不同的工具。

他们推出的这种基于 Kubernetes 的云环境编排方案引发了社区的强烈反响和浓厚兴趣。不过，Ott 解释道，不同团队和组织在使用 Kubernetes 资源模型方面的经验存在显著的差异：

我们发起了一项每月一次的技术分享会，这是一场混合多种形式的活动，邀请来自公司各个部门的人员分享他们共同面临的挑战。在这些时长较短、几乎无需任何先备知识的分享环节中，我们展示了“控制平面”方法论如何让他们的日常工作变得更加轻松。我们投入了大量的时间和精力，共同编写了用户入门指南。最初所有内容都采用了“内源”模式，现在大部分内容都已经开源。

Ott表示，他们的技术讲座系列一直吸引着新老利益相关者的参与，通过轻松但内容丰富的交流会分享最佳实践。

为了打造一个积极参与、支持解决方案适配的社区，Techritz 建议找出公司内部的共同痛点，并利用“控制平面”方法论来开发解决这些挑战的概念验证。他建议：不要强调差异，要拥抱共同点，并积极投入到一个共享的最小可行解决方案中。不要追求完美，而是要营造一种共同改进可改进之处的文化：

这并不总是能奏效，但耐心或对失败的包容态度无疑会有所帮助。但绝不要停止赋能并与身边的人分享知识。要让人们能够轻松地跟上节奏，动手实操，并提出建设性的反馈意见。

Techritz 总结道，归根结底，要想取得成功，就需要工程师、领域专家、推动者以及人脉网络的合理搭配。

演讲结束后，InfoQ 采访了 Maximilian Techritz" 和 Johannes Ott" 。

InfoQ：开发人员使用控制平面能获得什么好处？

Johannes Ott：使用一种既适用于机器又便于人类阅读的语法，将整个目标状态明确地定义出来，并由 Kubernetes Operators 永久保存其编排和维护方法，可以显著地减少以往拖慢我们进度的手动操作、手册及其他流程。借助这一方法论，你可以充满信心地交付符合现代云环境要求的软件。

InfoQ：你们取得了哪些成果？有哪些事情让您感到自豪？

Maximilian Techritz：当得知我们可以将该项目捐赠给欧盟资助的 IPCEI-CIS 项目（欧洲共同利益重要项目——云基础设施与服务）时，我们感到非常兴奋。这使我们与许多其他项目走得更近，那些项目都致力于加强欧洲在云原生领域的自主权。所有这些项目都隶属于 NeoNephos 基金会"。这是 Linux 基金会欧洲分会的项目，旨在确保供应商中立性。

InfoQ：你们获得了哪些经验？

Techritz：从小处着手。在实践中了解人们真正关心的是什么。找出开发团队共同面临的痛点。利用“控制平面”方法论一起解决这些问题——构建一个 Kubernetes Operator，或者从现有的开源 Operator 中找一个合适的。在这段旅程中，帮助没有 Kubernetes 经验的人参与进来。积极贡献是项目成功的关键。

原文链接：https://www.infoq.com/news/2026/06/europe-cloud-enterprise/"

8 人起家年入上亿美元，推出自研大模型对战 Cursor、Claude Code？

华卫 — Tue, 30 Jun 2026 10:29:30 GMT

整理 | 华卫

一年前，Wix斥资 8000 万美元收购低代码 AI 开发平台 Base44。彼时，这家公司成立仅半年，团队仅有 8 人。如今，Base44 已正式推出自研大语言模型，帮助用户通过自然语言搭建应用。这一举措正值 AI 圈围绕“前沿模型是否适用于所有场景”的讨论不断升温。同时，一个相关问题也愈发突出：构建在他人模型之上的公司，长期来看是否具备真正的护城河。

Base44 的最新动作，正回应了这两个问题。尽管其定制的大语言模型（LLM）仍处于初步上线阶段，但 Base44 希望未来它能够超越前沿模型。创始人 Maor Shlomo 表示：“将模型训练并纳入我们整个技术栈的一部分，让我们在延迟、成本和效率方面拥有更多优化空间。”

乍看之下，这或许是为了在竞争中领先于瑞典初创公司 Lovable，后者在去年夏天的 A 轮融资中晋升独角兽，目前依赖外部 LLM。不过，Shlomo 预计其他公司也会训练自己的模型，“至少那些已经具备足够规模和数据积累的玩家会这么做。”

风险投资机构 Headline 的普通合伙人 Jonathan Userovici（其投资组合包括 Mistral AI 等公司，但不包括 Base44）认为，数据是 AI 初创公司构建护城河的三大关键要素之一，另外两个是分发能力和技术栈。因此，拥有强品牌的玩家正越来越多地依靠自身的数据和基础设施来提升防御能力，Base44 也符合这一趋势。

该公司表示，其首个 LLM Base1是基于“平台上数千万真实用户交互数据”开发和训练而成。这一数据集将随着公司增长不断扩大，但竞争对手也同样如此。真正更大的竞争或许并非其他 vibe coding 初创公司，而是不断切入该赛道的前沿 AI 实验室：代码工具 Cursor、Grok 所属母公司 xAI 如今均隶属于 SpaceX，而Claude Code也已成为成熟的自然语言编程工具。

这意味着，Anthropic 等基础大模型厂商能够获取应用开发场景的数据与用户反馈闭环，持续迭代适配开发场景的模型。但 Shlomo 认为，垂直专精让 Base44 具备优势。“模型在进步，但它们仍将保持通用性，”他预测道。

Userovici 则提醒不要低估前沿模型的能力。他举例称，法律科技初创公司 Harvey 就曾放弃自研模型的计划。他并不认为应用层 AI 公司会大规模转型为前沿模型实验室，但他将 Base44 的举动放在更宏观的背景下来看，推理成本正变得越来越重要。

Userovici 表示，这种成本压力正在推动变化，企业客户也开始提出新的需求：“他们并不总能在所有场景中使用最新模型获得投资回报，因此整个基础设施正在建立，用于编排和优化模型选择，以在不显著增加成本的前提下，维持大多数场景下相同或相近的性能。”

目前，企业用户在 vibe coding 平台的用户群中仍占少数，但其收入占比正在上升。同时，各类用户也开始对 AI 使用成本表达担忧。Base44 决定自研 LLM 的原因有多方面，但降低成本无疑是其中之一。Shlomo 表示：“我们希望拥有一个更符合我们价值判断的模型，更贴合我们观察到的用户偏好结果，同时最终在速度和成本上都优于使用 Opus 等前沿模型。”

至于 Base44 自身，成本下降并非立竿见影。该公司表示：“拥有模型使 Base44 能直接控制计算和推理支出，预计将随着时间推移形成更强的利润结构。”即便回报存在滞后，更高的利润率对其母公司来说仍是利好，后者近期刚宣布裁员 20%。

相比之下，Base44 在被收购后持续扩张团队，并在几个月前宣布其年度经常性收入（ARR）已突破 1 亿美元。这一数字仍低于 Lovable，后者本月早些时候表示 ARR 已达 5 亿美元。但 Shlomo 押注于开发 Base1 所投入的“巨大工程努力”，将巩固 Base44 作为“唯一垂直一体化 vibe coding 应用”的定位。也就是说，在 Userovici 的定义中，它是一个同时掌控分发、数据和基础设施的玩家。

参考链接：

https://techcrunch.com/2026/06/29/vibe-coding-platform-base44-launches-own-model-as-ai-startups-seek-defensibility/"

网易有道CEO周枫：Harness即产品

周枫 — Tue, 30 Jun 2026 10:23:05 GMT

编者按：大模型时代模型能力从实验室走向真实场景，真正考验的已经不只是参数、榜单和单点效果，而是企业是否具备面向未来模型能力设计产品、管理复杂上下文、连接工具系统、建立评测闭环，并在教育、翻译、办公、内容生产等真实场景中持续迭代的工程能力。这也是理解网易有道AI 转型的一个重要切口。过去几年，有道在大模型、多模态、语音、翻译和教育硬件等方向持续投入。但更关键的是，它正在把这些能力沉淀为一套面向应用落地的产品工程方法：模型是起点，但真正决定 AI 产品能否长期服务用户，向用户交付真实价值的关键同样包括模型之外的系统设计、场景理解和工程闭环。近期，网易有道CEO 围绕 Harness/Agent 分享了一组内部思考。他认为，Agent核心是由“Model + Harness”共同构成；模型负责思考，Harness 则负责让这种思考变得可理解、可协作、可复现、可长期运行和交付成果的系统。对于复杂 Agent 产品而言，模型可能只完成一部分工作，剩下支撑产品可靠运行的核心，恰恰来自上下文管理、工具调用、评测体系、权限治理和循环控制等工程能力。

关于Harness/Agent的讨论比较多，总体上大家共同的看法是：现在是通过Harness来做大模型创新应用的好时机，但是Harness和以往的应用开发范式有较大不同，需要用一些不同的方法，才能做出好的产品，沿用原有的思维方式可能事倍功半。

本文从行业分享和内部实战中总结了一些最佳实践，和大家探讨。

先界定一下概念。所谓Harness（马具/载体），指的是模型之外、把模型包装成一个可用产品的那一整层工程：上下文管理、工具、记忆、持久化状态、评测、循环控制、可观测性与权限治理。

一个标准的说法是Agent = Model + Harness：模型负责“思考”，Harness负责让这份思考变得可理解、可协作、可复现、可长期运行。长程Agent对Harness的依赖，超过它对任何单个模型的依赖。更强的模型并不会自动变成更可靠的Agent服务。简单来说，对于一个复杂的Agent，模型也许只完成20%的工作，剩下80%、让产品持续可靠工作的基础，是Harness。

这正是标题“Harness即产品”的含义：在大模型应用里，团队真正在设计和迭代的产品，往往不是一个个具体的功能，而是这一整层Harness本身。

下面七点，是我看到的构建一个好的基于Harness产品的要点。

1. 面向下一代模型能力设计产品

很多团队一开始就犯一个错误：围着模型今天的能力优化和打磨，试图让功能更准、更快、更便宜，结果产品上线没多久就被新模型直接替换。

解决这一问题的一个办法，是做一定的超前定位：产品路线图不该只问模型今天能不能做，更要问“半年后如果模型在规划、工具使用和长上下文上再上一个台阶，我们如何抓住红利”。

工程上，可以先用强模型跑出效果，再逐步尝试小模型替换；业务上，则优先选择会随着模型智能提升而不断放大价值的场景，比如复杂决策场景、需要深度思考的功能、跨系统调度，或者需要深入专业知识的产品。

Claude Code负责人Boris Cherny在Lenny's Podcast的访谈里把这件事讲得很清楚：Claude Code一开始只是个小尝试，团队是在“赌模型半年后的能力”——他们刻意按“模型将会变成什么样”、而不是“模型现在能做什么”来设计产品。

当时他的判断是，模型独立编程的能力正在快速上升，交互方式因此必须从以人为主的自动补全（auto-complete）转向以Agent为主：“模型能做到很多还没有产品接住的事…… 我们其实不必再做type-ahead了，可以直接让Agent把所有代码都写出来。”这个赌注在2025年5月Opus 4发布时兑现，产品随之取得巨大成功。

他给出的两条产品原则也值得思考：“别试图把模型框死”（少用僵硬的编排，多给工具和目标让模型自己想），以及“押注更通用的模型”——在模型一夜之间就能改变能力边界的领域里，能随模型一起变强的灵活方案，往往胜过为当下定制的脚手架。

2. 要做高智能产品

不是所有AI功能都值得投入。

一个简单的判断标准是：如果这个问题主要靠规则、搜索和模板就能解决，那它未必值得产品化；如果它依赖模糊判断、跨文档理解、多步骤推理和人与系统之间的复杂协作，那它才更适合为之开发大模型产品。

一个考虑的角度，是“类比一个需要资深员工处理的复杂任务切片”。如果你是产品负责人，最应该优先筛选的场景，不是流量最大，而是单次任务价值最高、判断复杂度最高、人工成本最贵的那些。这类场景虽然起步看起来更难，但一旦做通，用户会把它当真正的生产力工具，而不是新鲜一下的演示玩具。

换个角度说，任务切片越难、价值越高，模型单独能交付的比例就越低，当然最终能不能稳定上线，恰恰取决于Harness建得好不好，对模型能力的判断是否正确，但总的来说，把注意力集中在高智能产品方向上，是成功可能性更大的。

3. 有价值的Agent产品，往往消耗较多tokens

很多团队的第一直觉是“把token用量压到最低”，但对真正困难的任务来说，这往往是一上来就设定错了优化目标。对于高价值场景来说，token消耗是创造价值的，因此在一定范围内是越多越好。所以这类场景里，正确的默认态度是舍得花——和上一点呼应，单次任务价值越高、判断越复杂，越不该在token上抠门。一个Agent任务跑下来，累计输入token在数十万到数百万之间，都是比较正常的。

因此Harness的一个重要任务，是让token的花费具有经济上的可核算性——能够统计和优化token的消耗，使得该花的地方花充分，不该花的地方足够节省。这个和公司的增长团队一定要量化计算ROI一样，是团队一个必要的基本功。

这里有一些重要的杠杆：一是提示词的缓存，是团队要关注和优化的要点；二是分层与路由——用强模型跑出比较好的效果后，把简单节点下放给小模型；也可以用批处理（batch）的方式跑可异步的批量任务、必要时做上下文重置来进一步节省开销。注意，这些手段省的是无谓的浪费，在高价值环节应该放开手脚，放心大胆地花。

4. 把上下文工程当成主任务

上下文工程（context engineering），目的是让模型在某一时刻究竟知道什么、不知道什么、记住什么、遗忘什么，而不是写更长、更巧妙的提示词。如果说Harness有一个心脏，那就是上下文管理：前面几点，最终都要落到管理上下文内容这个动作上，而不是简单地使用不断积累对话上下文的默认规则。至少要把上下文拆成几层：系统规则、当前任务、检索知识、用户历史、长期偏好、工具结果。不同层应该有不同的优先级、生命周期和压缩方式（见下图）。Anthropic把上下文工程的目标概括成一句话：找到“能最大化达成目标的、最小的一组高信号token”，因为上下文是一种边际收益递减的有限资源。

关于上下文工程的好文章不少，比如这篇：《Agent全面爆发！万字长文详解上下文工程》

5. 工具是给模型看的产品界面

Agent调不好工具，往往不是模型不聪明，而是工具设计得不对。

现在国内外主流模型的Agent能力都已经较强，在绝大多数场景下都有有效地驱动设计良好的工具集合来工作，所以在上下文工程之后，工具的设计是团队应该聚焦的点。对于不熟悉这个方法的团队，这需要一次观念升级：你不只是写一个API给自己的前端或服务端调用，而是在设计一个“模型可消费的能力单元”。如果工具过多、命名相似、参数含糊，模型就容易误选；如果返回结果冗长且噪音大，还会进一步污染上下文。

比较实用的做法是：先收敛工具数量，把高频业务动作做成少数几个高信号、强约束的工具；其次使用严格的schema和结构化输出，避免自由文本在节点之间传递错误指令；最后为关键工具写清“什么时候该用、什么时候不该用、调用成功与失败分别长什么样”。

Anthropic在工具使用文档里也强调，影响调用效果最重要的因素之一，就是工具描述本身。不少一线实践也指向同一组做法：工具一旦超过二十来个，模型就容易在相似工具间选错（比如把“订单查询”和“物流查询”搞混）；同时避免“瑞士军刀式”的多功能工具，改用单一职责、强schema的小工具，并在真正调用前先做参数校验、把错误直接“回吐”给模型修正。

6. 用评测驱动开发

做Agent比较容易掉入的一个坑是做出“差不多”能工作的产品，然后碰到问题反复手工调整，但是按下葫芦浮起瓢，陷入打地鼠的困境。这个时候，团队缺乏的就是量化的评测办法。一个真正可上线的Agent，必须有细分任务级的、量化的评测体系。评测至少要覆盖四层：最终答案质量、工具调用正确率、流程完成率和安全样本通过率。更进一步来讲，还应该有边界样本、对抗样本和真实线上日志回灌。一定要把“凭感觉”换成“看数据”。

从实操角度，Anthropic的《Demystifying Evals for AI Agents》是目前最权威的Harness/Agent评测指南，同时也已经有多个开源的框架出现，大家可以选择参考和使用。

7. 默认从单Agent开始

多Agent很容易让人兴奋，因为看上去更像“组织协作”。但很多有经验的团队都建议先把单Agent做到极致，只有当prompt逻辑过于复杂、工具集合拥挤、权限等级不同、任务目标天然分离时，再拆成多Agent。

原因很简单：多Agent会带来handoff、状态同步、权限分层、成本叠加和调试复杂度。拆对了，系统会更清晰；拆错了，只会让问题在更多节点里来回传递。真正值得拆的，是那些边界清楚且目标不同的角色，比如“分诊—执行—质检”“检索—分析—操作”或者“客服—退款—物流”。

这件事社区里有一场很有代表性的争论：Cognition（Devin背后的团队）写过《Don't Build Multi-Agents》，主张默认就用单Agent——多个Agent之间很难共享完整上下文、容易决策冲突，对“写”类的强一致性任务（比如写代码）尤其脆弱；而Anthropic在《How we built our multi-agent research system》里给出了反例：在“读”类的开放式研究任务上，主从式（orchestrator-worker）多智能体比单个Claude Opus 4高出90.2%，但代价是token消耗约为普通对话的15倍。两边其实指向同一条分界线——任务偏“读”还是偏“写”、能不能共享上下文，决定了该不该拆。

小结：你迭代的产品，就是Harness

把这七点连起来看，它们其实是同一个工程的七个侧面：超前定位定方向、高智能场景定取舍、舍得花token求价值、上下文管理是心脏、工具是手、评测是免疫系统、循环编排是骨架。

模型会一代代变强，而且只会越来越强——但更强的模型不会自动变成更可靠的Agent服务，从demo到完整产品的鸿沟，始终要靠Harness来填。

所以做大模型应用，真正在持续设计、打磨、积累壁垒的，是这一整层Harness。模型是可更换的引擎，Harness才是你自己造的车。

Arm 计算平台加持，联想车计算推动 L4 级自动驾驶出租车规模化落地

Arm 社区 — Tue, 30 Jun 2026 10:03:03 GMT

在历经多年自动驾驶试点与受控测试后，汽车行业正加速迈向 L4 级自动驾驶出租车 (Robotaxi) 的规模化量产部署阶段。这不仅是自动驾驶发展的关键节点，也标志着人工智能 (AI) 的一次重要跃迁 —— 从辅助人类决策，演进至赋予车辆自主感知并理解周边环境的能力。当然，这一转变也伴随着技术需求的急剧攀升。

相较于当前主流的 L2++ 级先进驾驶辅助车型，L4 级自动驾驶系统通常需要更为丰富的传感器配置，包括激光雷达、摄像头和毫米波雷达等。这直接推动数据处理的大规模增长：车辆每小时需要处理的数据量，已从约 25GB 激增至最高可达 19TB。如此庞大的数据处理压力正迫使行业重构物理 AI 底层计算架构。

在此需求背景下，联想车计算推出了 L4 自动驾驶域控制器 AD1。该自动驾驶计算平台搭载两颗基于 Arm 架构的 NVIDIA DRIVE AGX Thor X 芯片，并已正式量产。文远知行 (WeRide) 已将该平台部署于其 Robotaxi GXR 中，该车也由此成为全球首款搭载 NVIDIA DRIVE AGX Thor X 芯片的量产 L4 级自动驾驶车辆。

探秘联想 AD1

联想 AD1 是 Robotaxi GXR 的“中央大脑”，统筹管理环境感知、行为预测、路径规划、实时运动控制及安全监控等核心功能。

联想 AD1 是一款面向自动驾驶出租车及其他自动驾驶汽车的量产级 L4 自动驾驶计算平台。该平台可提供超过 2,000 TOPS 的 AI 算力，支持高密度感知、预测与规划模型并行运行，助力车辆在实时道路环境中实现更快速、更精准的决策。

对于自动驾驶出租车而言，传统的松散耦合电子控制单元 (ECU) 难以满足 L4 自动驾驶对低延迟、高安全性与可扩展性的严苛要求，因此这类车型亟需高性能中央集成式计算平台。为此，AD1 搭载了 NVIDIA DRIVE AGX Thor X，成为一款基于 Arm Neoverse V3AE CPU 的中央集成式车载计算机，将此前分散的驾驶、泊车、监控功能整合到单一计算域中。

效率、安全性及物理 AI 的基石

Arm 作为 NVIDIA DRIVE AGX Thor X 平台的基础计算架构，为联想 AD1 平台提供了先进的计算能力。

每瓦性能助力车队运营降本增效：自动驾驶出租车需在复杂繁忙的城市环境中长时间运行，Arm 计算平台可在高能效功耗范围内提供服务器级算力，支持大规模 AI 计算负载的稳定运行，同时对车辆电池续航及热管理设计不造成额外负担。安全就绪型架构：Arm 生态系统整合了功能安全就绪的技术、工具链和软件解决方案，并拥有长期深耕汽车领域的合作伙伴，可为平台提供全方位支撑，助力其满足 ASIL-D 等级及其他全球安全标准要求，这也是自动驾驶技术实现长期商业化部署的关键要素。成熟、可扩展的软件生态：由于 Arm 可在云端、边缘侧和物理环境中提供统一架构，开发者可借助现有的主流软件工具和框架，高效完成 AI 模型的构建、优化与规模化部署。与未来 AI 工作负载适配的发展路线：随着物理 AI 模型的规模和复杂度持续提升，计算效率与架构稳定性变得愈发重要。基于 Arm 架构进行开发，车企可获得一套具备一致性的架构底座与清晰的长期技术路线图，既能避免未来不必要的重复设计，又能在 AI 持续演进过程中保持计算战略的稳定。

Arm 构筑自动驾驶之路

联想 AD1 在文远知行 Robotaxi GXR 上的部署，展现了物理 AI 在自动驾驶系统中的应用正突破封闭试点阶段，迈向真实复杂的城市应用场景。随着 L4 Robotaxi 及其他自动驾驶汽车的能力不断提升，行业正愈发青睐采用中央化架构的平台，从而同步实现高性能、高安全性与高能效。

Arm 正位于这一变革的核心，为联想车计算、文远知行等企业构筑起坚实技术基础，使其能够持续运行大规模 AI 工作负载、快速适配迭代升级的算法模型，并保障车队长期稳定、可靠的运营。随着自动驾驶出租车向更多城市及全球市场拓展，这款专为安全设计、且针对物理 AI 规模化落地需求优化的 Arm 计算平台，正是未来自动驾驶之路的重要基石。

物理 AI 演进之路：从受控环境走向现实世界

Arm 社区 — Tue, 30 Jun 2026 09:56:34 GMT

物理人工智能 (AI) 正推动机器从可预测的受控环境走向复杂多变的现实世界。机器人曾经主要被设计用于工厂车间的高精度重复作业，如今已进化为能够感知、推理、理解环境并对动态场景做出响应。这种变革在宏观层面同样意义深远：AI 驱动的生产力提升，预计未来十年将带动全球 GDP 增长约 4%。

AI 技术的持续进步，让物理 AI 系统能够在毫秒级时间内识别视觉信息、理解场景上下文并调整其行为。无论是仓库自主导航、医院辅助作业，还是道路行驶，自主机器均依据实时情况而不是固定顺序做出决策。

多年来，Arm 从最早部署在工厂车间的固定式机器开始，持续助力物理 AI 系统研发。如今，这套技术基础正赋能新一代智能机器人与自主机器，使其能够在真实环境中运行并实时做出响应。

现实中的物理 AI

从当下打造的机器中，可以清晰地看到物理 AI 的演进脉络。各类形态的机器人及其他自主机器正不断提升环境感知能力、自适应能力与自主运行能力。

新一代人形机器人

物理 AI 的技术进步集中体现在更复杂、类人化的系统上。此前在 Arm 位于剑桥的总部，智元机器人充分展现了人形机器人技术已取得的长足进展。这些机器人展示出灵巧的操控能力，能以流畅的动作在复杂环境中自主导航，实时融合感知、推理与控制技术。

这类物理 AI 系统专为人类生活或工作环境设计，需要理解空间布局，解读意图，并精准执行动作，同时保障周围人员安全。这对计算能力提出了极高要求，因为视觉处理、AI 推理和运动规划等多个工作负载必须在严格的功耗和散热限制下并行运行。

Arm 计算平台可针对这类工作负载实现高效处理，从而满足相关需求，使人形机器人系统能够在现实环境中灵敏且安全地运行。

四足机器人与工业机器人

四足机器人是物理 AI 的另一重要分支，尤其适用于地形复杂、环境危险、不可预测的场景。

云深处科技等公司研发的机器人专为巡检勘探和应急救援场景设计，可在崎岖地面行进、翻越障碍，并在不断变化的环境中保持稳定。这些能力依赖于持续的环境感知和实时控制，并由高效的计算提供支持。

与此同时，普渡机器人的 PUDU D5 等平台将自主移动能力延伸至工业场景。D5 系列专为巡检、巡逻和物流保障设计，搭载激光雷达和摄像头视觉技术，可在大型厂区、复杂地形自主作业。这在高危、偏远或人员难以抵达的场景中尤其有用，在这类场景下，可以用机器人替代人工执行任务，从而提升安全性并降低风险。

为了支持这一点，该系统采用异构计算架构，将工作负载拆分至感知、规划和控制三大模块，通过持续处理传感器数据，使机器人能够理解环境并以低延迟做出响应。

基于 Arm 计算平台打造的处理器支持这些核心功能，并与 AI 加速器搭配，在边缘侧提供高效性能。这让机器人能够在可靠性、安全性和能效至关重要的环境中独立运行。

工业自动化领域也迎来同样的变革。工厂车间的协作机器人正变得越来越能快速响应不断变化的工作流程，同时不仅能与人类协同作业，还能灵活适配全新任务，而无需完全固定的配置。

波士顿动力公司的 Spot 四足机器人也是个典型例子，其可部署于工业场景中执行巡检和远程运维，在这类场景中，实时感知和控制至关重要。

自动驾驶汽车与移动出行平台

物理 AI 同样正在改变自动驾驶领域，要求系统必须在复杂真实路况下安全行驶和导航。

以联想车计算与文远知行联合打造的自动驾驶出租车为例，这些自动驾驶出租车验证了基于 Arm 架构的可扩展计算平台可实现 L4 级自动驾驶。这些系统处理摄像头和激光雷达等海量传感器数据，以做出实时驾驶决策。

与此同时，Arm 与 Tensor 的合作凸显了新一代计算平台如何围绕 AI 移动出行方案进行设计。这些平台融合高性能计算与高能效特性，为自动驾驶系统中带来实时感知、路径规划和运动控制能力。

Arm 与 Rivian 的合作同样印证了定制化自动驾驶平台可让车辆规模化理解周围环境并实时做出驾驶决策。在这些环境下，可靠性和延迟至关重要。系统必须瞬时做出决策，并长期稳定运行。高效、可扩展的计算能力是实现这一目标的核心。

智能系统的组成模块

图片物理 AI 的核心是感知、决策和行动之间的持续循环。系统必须处理传感器输入，解析这些数据，并在毫秒级时间内触发响应。在许多情况下，感知到行动的延迟更是决定性要求，尤其是在安全和时效至关重要的环境中。

物理 AI 的演进根植于现代机器人与自主机器系统的工程设计思路：整合多项核心能力，并让这些能力作为一个协调的系统运行。每一层级都对机器如何理解世界以及如何与世界交互产生影响。

感知提供环境认知能力。摄像头、激光雷达和其他传感器阵列持续生成数据流，使系统能够进行物体检测、距离估算和环境建模。边缘 AI 推理在本地处理这些数据。通过在设备端运行 AI 模型，机器人可以即时响应，而无需等待云端输入。在延迟直接影响安全性或性能的环境中，这一点至关重要。

多模态推理融合视觉和语言等多类输入。机器人及其他自主机器能够理解场景，解读指令，并做出适当的行动决策。这使得交互方式更贴近人类自然沟通模式。实时控制与安全防护确保决策得到可靠执行。确定性计算使系统能够在可预测时限内做出响应，而安全防护机制则有助于管理复杂环境下的运行风险。

这些能力目前已经在各行业中得到应用。例如，在智能工厂中，预测性维护系统会持续分析设备数据，以提前识别潜在的故障迹象。同时，在物理 AI 部署中，各类系统均可处理现实世界的输入并以超低延迟执行动作。

以高效、可扩展的计算能力赋能物理 AI

图片当前物理 AI 系统需要在严格的功耗和散热限制下，处理大量传感器数据、运行 AI 模型和控制运动。许多系统采用电池供电，但电池的功率有限，使得能效成为关键考量因素。同时，必须保持性能稳定，尤其是在时效和精度至关重要的环境中。

为此，如今的计算平台必须具备以下能力：

支持实时决策的确定性性能；在受限环境下持续稳定运行的高能效表现；端侧 AI 推理能力，可降低延迟；异构计算，用于管理多样化工作负载；可适配各类物理 AI 系统的扩展能力。

Arm 计算平台正是围绕以上原则而设计的。因此，它广泛应用于物理 AI 系统的各个计算领域，从处理传感器数据的低功耗微控制器，到负责复杂 AI 工作负载的高性能中央计算单元（相当于物理 AI 系统的“大脑”）。这使得工程师和开发者能够在构建系统时针对各组件按需进行优化，同时仍保持统一的架构。

例如，在机器人领域，该方案可以实现性能和能效之间的出色平衡。机器人可以处理传感器输入，高效运行 AI 推理并执行控制逻辑，同时不会超出功率或散热限制。对于需要在真实场景下持续运行的系统而言，这一点尤为关键。

Arm 的生态系统也在加速技术开发方面发挥着重要作用。Arm 携手软硬件领域的众多合作伙伴，依托全球超 2,200 万开发者的生态系统，打造从工厂车间固定环境中的机器，到真实环境中运行的人形机器人与四足机器人，覆盖各种场景的物理 AI 平台。

引领智能机器未来发展

图片物理 AI 正在重新定义机器与世界的交互方式。新一代机器人与其他自主机器具备更强的环境理解能力，依托先进 AI 实现解读、决策和执行。其应用场景也持续拓宽，覆盖交互式系统、工业自动化和自动驾驶等多个领域。

随着系统持续迭代，性能和效率之间的平衡将直接决定技术部署范围。多年来，从最早部署在工厂车间的固定式机器开始，Arm 持续助力物理 AI 系统研发。如今，这套技术基础正赋能新一代智能机器人和自主机器，让 AI 直接作用于物理世界，并且系统原生支持实时响应。

随着物理 AI 持续规模化落地，越来越多的智能机器将基于 Arm 计算平台打造。

Cursor、OpenClaw 同时出手，“口袋编程”时代来了：程序员只用“动嘴”！

华卫 — Tue, 30 Jun 2026 09:46:54 GMT

整理 | 华卫

在完成了 SpaceX 600 亿美元收购案之后，Cursor 并没有放慢脚步，而是将其生态从桌面端扩展至移动端。

昨日，这家公司宣布推出名为 Cursor Mobile 的全新 iOS 移动应用，专为希望通过手机直接向编程智能体发出指令的用户设计。这款应用与 Cursor 在今年 10 月发布的 2.0 版本更新相衔接，该版本将服务重心转向独立运行的编程智能体。借助这款移动应用，用户可以在离开电脑时也能开启新的编码会话、查看智能体输出，并与正在运行的智能体实时交互，还能手机上创建并管理新的 AI 编程智能体。

就在今早，OpenClaw也重磅官宣：有了原生移动应用，现已登陆iOS和安卓两大平台。

这或许是今天最清晰的信号：AI 驱动的软件开发，正在摆脱多屏桌面环境的束缚。

打通桌面工作流，可直接口述提示词

Cursor 的移动应用围绕“远程管理编程智能体”这一核心需求，提供了一系列关键功能：

创建新智能体：即时启动新的 AI 编程智能体，处理如修复 Bug、开发功能或撰写文档等任务与运行中的智能体交互：通过自然语言向正在执行任务的智能体发送指令，调整其思路或修正错误，无需打开完整桌面环境查看智能体输出：浏览 AI 生成的代码与建议，在提交前轻松完成质量校验监控任务进度：实时跟踪多个智能体的工作状态，确保任务不会停滞或被遗漏

在官方介绍中，Cursor 提到，开发者过去往往依赖本地设备运行任务，甚至需要让笔记本“半开着、靠咖啡续命”以保证任务不中断。而通过这款移动应用，用户可以将 AI 编程智能体部署在云端，远程监控其进度，并直接在 iPhone 或 iPad 上完成软件开发任务，从而摆脱这一限制。

而这款应用最突出的特点在于其与桌面版 Cursor 的打通与深度集成。它并不是一个孤立运行的工具，而是主开发环境的强大延伸。开发者可以通过移动端界面启动桌面应用、创建新的编码会话，并立即向 AI 智能体分配任务。这种连接能力意味着，开发者可以在候机时用手机发起一个复杂的编码任务，回到办公桌后再无缝继续查看智能体的输出结果。应用支持用户监控后台运行的智能体、查看实时进度更新，甚至可以直接在手机端将完成的修改合并进代码库。

使用体验上，移动端与桌面版高度一致。开发者可以打开应用，选择代码仓库、指定支持的 AI 模型，并描述希望智能体完成的任务。应用还支持语音输入，用户可以直接口述提示词；同时也支持通过斜杠命令（slash commands）为 AI 提供更细化的指令。

根据 Cursor 的说法，这款移动应用专为需要“快速响应”的场景设计。无论是复现 Bug、审查受影响代码，还是继续推进修复工作，开发者都可以直接在手机上完成。当智能体开始运行后，用户无需一直打开应用。iPhone 锁屏界面的 Live Activities 会实时展示任务进度，推送通知则会在任务完成、需要额外输入或准备好供审查时提醒开发者。在应用内，开发者可以查看代码变更、截图、日志及演示内容，并在审批后直接合并 Pull Request。

对于已经在电脑端运行中的智能体，Cursor 引入了名为“Remote Control”的功能，允许开发者无需回到桌前，就能通过手机继续与这些智能体交互。此外，平台还提供“保持电脑唤醒”的选项，以确保用户离开时设备仍可远程访问。该公司还提到，来自 X 等平台的用户反馈，也可以通过截图、标注并发送给 AI 智能体的方式，转化为开发任务，作为界面或设计优化的视觉上下文。

总的来说，该工具旨在为开发者提供对 AI 编程智能体的远程控制能力，使自动化编程不再局限于固定工位。随着行业逐步走向更灵活、分布式的开发模式，Cursor 的这一应用正好满足了开发者在出行或远程办公时仍需掌控项目进展的需求。这一发布标志着开发模式从“仅限桌面”向“移动可达”的重要转变，显著提升了开发者在移动场景下的效率与掌控力。

向付费用户开放公测，长期目标：云端智能体与本地开发“无差别”

与此同时，Cursor 的商业进展也在加速推进。目前，Cursor 已拥有超过 100 万付费用户，并声称《财富》1000 强企业中有 70% 是其客户。现在，iOS 版 Cursor 已向所有付费订阅用户开放公测。同时，公司还推出限时优惠：在 7 月 5 日前，Composer 2.5 的使用费用可享受 75% 折扣。

这款移动应用，是 Cursor 向“独立编程智能体”转型的重要延续。这一转型始于 2025 年 10 月发布的第二个重大版本，当时平台引入了可在较少人工干预下运行的智能体，能够完成编写测试、修复 Bug、跨文件重构等任务。而 iOS 应用则进一步放大了这种自主性，开发者可以在任何地点对这些智能体进行监控与调度。

Cursor 强调，其长期目标是让基于云端的 AI 智能体使用体验与本地开发“无差别”。该公司还在开发无需依赖代码仓库的聊天能力（repo-less chat），用于处理那些不需要访问代码库的任务。

这一举措也与 Cursor 对“自主运行 AI 智能体”的长期愿景相契合。随着平台逐步发展出能够自我评估修改、自动记录行为的智能体能力，这款移动应用将成为关键的“远程控制面板”，用于人类的监督与决策。开发者将更多扮演“管理者”的角色，负责指导 AI 的方向、审核其输出，并确保最终代码符合预期标准。

此外，这款移动应用的推出，体现了 Cursor 对开发者体验的战略性升级。通过让开发者能够远程操控编程智能体，平台在提升效率的同时，也带来了前所未有的灵活性。在开发节奏日益紧张、远程协作成为常态的当下，这一工具确保开发者无论身处何地，都能持续保持高效产出与对代码的掌控。

对于开发者而言，信号已经非常明确：有了 Cursor 的这款移动应用，编程智能体将始终触手可及，随时待命，随时可控，无论身在何处。从手机管理编程智能体不仅仅是便利性的提升，更是迈向“真正分布式开发”的关键一步。当越来越多开发工具开始自动化处理开发流程中的各个环节，对强大、移动友好的“监督工具”的需求只会持续增长。

移动编程可达性的新时代

移动优先开发是否会成为主流，取决于 AI 智能体能否在缺乏人工干预的情况下稳定运行。Cursor 的判断是：这些智能体已经足够可靠，可以长时间自主执行任务，开发者只需间歇性介入，而非逐行盯代码。其 iOS 应用正是围绕这一新工作流设计，它更适合快速审查、批准修改和调整方向，而不是传统的逐行编辑代码。

在最近的一次演讲中，Anthropic 旗下 Claude Code 负责人 Boris Cherny 对这一趋势给出了直白的判断：“现在我大多数编程都是在手机上完成的。如果你在六个月前这么跟我说，我肯定会觉得你疯了，但现在，这已经成为现实。”他描述了一种全新的工作流：在会议间隙或通勤途中，审核 AI 生成的代码并批准修改。考虑到 Anthropic 本身是 Cursor 的主要竞争对手之一，这一表态也更具分量。

当然，Cursor 并不是唯一押注移动端的 AI 编程平台。

今早，OpenClaw在X上宣布有了原生移动应用，把智能体装进口袋，可随时随地接收频道、任务与回复。现在，OpenClaw的这款应用已登陆iOS和安卓两大平台。

iOS: https://apps.apple.com/us/app/openclaw-ai-that-does-things/id6780396132"

Android: https://play.google.com/store/apps/details?id=ai.openclaw.app"

此前，Anthropic 和 OpenAI 也都提供了在移动设备上与其编程工具进行交互的方式。但在“基于智能体的完整工作流”上，仍未达到 Cursor 在手机端的深度。这背后反映的是“编程定义”的变化：当 AI 负责具体写代码，开发者的角色正在转向监督与决策，而这些工作并不依赖完整的开发环境。

vibe coding运动已经开始重塑应用开发生态，推动 App Store 提交量激增 84%，并迫使苹果加强对 AI 生成应用的审核。这些AI开发平台所推出的移动应用，则让这一趋势更进一步：开发者可以直接用口袋里的设备，指挥复杂的软件工程。

这也是 AI 编程工具整体演进的一部分：它们正在逐步从“手写代码”抽象出来，转向对“代码生成智能体”的管理与监督。由于不再需要直接访问庞大的代码库，越来越多开发者能够放弃多屏桌面工作环境，转而使用手机，通过持续对话的方式与远程智能体协作。

目前，已经有一批开发者在体验这种移动编程的模式了。一位开发者分享道，“用 Claude / Codex / Cursor 移动端，我现在大概已经能在手机上完成 30% 的工作了。”另一位开发者表示，“整体感觉不错，尤其是 Cursor 的通知比 Codex 好很多，这块潜力很大。但用起来还有点别扭，作为第一天版本已经不差了，期待后续继续用。”

不过，有开发者提出疑问：“在手机上写代码真的有点离谱，我比较好奇的是，这种一直在线的云端 agent 到底能不能在不同会话之间保持上下文，还是每次重新打开都得重新解释一遍代码仓库？对我来说，这正是移动开发工具最容易崩的地方。”

也有人提到了成本方面的担忧。“这个想法挺不错的。但运行在虚拟机上的云智能体成本高得离谱。”还有开发者现身说法评价 Cursor Mobile 道：“正好40分钟，一回过神来，直接被扣了1000美元，笑死。”

参考链接：

https://techcrunch.com/2026/06/29/cursor-now-has-a-mobile-app-for-guiding-your-coding-agent-on-the-go/"

https://thenextweb.com/news/cursor-mobile-app-coding-agents-phone"

https://x.com/openclaw/status/2071688039114342592?s=20"

Anthropic 负责人：HTML 比 MD 更利于人类跟进智能体协作流程

作者：Bruno Couriol — Tue, 30 Jun 2026 09:00:00 GMT

Claude Code 团队工程负责人 Thariq Shihipar" 近期发表"了一篇题为《使用 Claude Code：HTML 意想不到的实用价值》的文章。文中提出，HTML 具备更丰富的可视化效果、色彩展示与交互性，在诸多场景下能提升人类与智能体之间的沟通效率，相较默认输出格式 Markdown 优势尤为突出。在智能体驱动的工作流中，目标沟通、需求细化、输出结果复核正逐步成为流程效率的瓶颈。

Shihipar 道出了开发人员经常需要面对的一个痛点"：

随着智能体变得越来越强大，我发现 Markdown 格式的局限性也愈发凸显。具体来说，我发现阅读超过一百行的 Markdown 文件非常困难。而且现在我基本不会手动编辑这类文件，只把它们当作需求规范与参考文档使用。我开始更倾向于将 HTML 作为输出格式，而不是 Markdown，并且也注意到 Claude Code 团队里越来越多同事都在采用这种方式。

主张使用 HTML 的论据建立在这一客观发现之上：随着智能体越来越多地被用于复杂且冗长的工作流，输出的复杂性和长度也随之增加，这给人类带来了认知负担瓶颈。支持 HTML 方案的人认为，面对这一挑战，开发者很容易偷懒，直接不经审核就全盘采纳智能体生成的内容，从而可能在日后引发质量、维护和安全方面的问题。

该观点认为，在那些必须人工介入、无法完全自动化的工作流程中（例如目标与执行路径设定、需求调研与细化、分步纠错引导），或是需要人工强制核验、确认结果的场景中，智能体的输出格式应当既能让人快速抓取信息核心与细节，又能贴合用户设定的目标。

相较于 Markdown，Shihipar更推崇使用单文件 HTML 创建适配当前任务目标、兼具可视化与交互性的工作空间。具体来说，他认为以下各类场景都适合使用 HTML：需求规范制定、方案规划与需求调研；代码审阅与逻辑梳理；界面设计与原型开发；数据探查、分析及可视化；以及所有能够借助定制化交互界面提升处理效率的业务场景。

在这篇博文的配套文章"中，Shihipar 提供了一个自定义一次性 HTML 输出的示例"，用于加快工单分类处理的工作进度：

另一个示例旨在加速 PR 审查流程"。相较于在终端里来回滚动查看内容，HTML 输出页面更便于快速浏览查阅：

Shihipar 的观点在 Hacker News、Reddit 和 Medium 上引发了广泛讨论，开发者们由此分成两派：一派认可 HTML 的高密度可视化展示优势，另一派则警告不要放弃 Markdown 的纯文本简洁性。

针对 Shihipar 提出的初步思路，Simon Willison" 提出了他的看法：如今大模型上下文窗口不断扩大，推理速度更快、使用成本更低，默认输出 Markdown 或许已经不再是最优方案"。

从 GPT-4 问世以来，我就一直默认要求大多数输出使用 Markdown，当时模型仅有 8192 令牌的上下文上限，Markdown 相比 HTML 更省令牌的优势显得至关重要。Thariq 的这篇文章让我重新审视了这个习惯，尤其是对于输出来说。如果让 Claude 用 HTML 生成内容，意味着它可以嵌入 SVG 图表、交互式小部件、页面内导航以及各种其他巧妙的方式，让信息更易于浏览。

也有人认为，用 HTML 替代 Markdown 是一种倒退"，即便在前述各类场景中也是如此。他们指出了各种弊端：源代码可读性的丧失、不安全的 HTML 带来的安全和基础设施风险、HTML 相比 Markdown 的词元开销，以及 Git 集成欠佳（例如差异对比）。

尽管如此，一些开发人员仍在创建自定义工具（例如，html-artifacts"，由 Greg Dogum" 开发的开源 Claude 技能，它使用识别启发式方法可根据当前任务切换成 HTML 输出）。

归根结底，Shihipar 的观点可能只是一个使用合适工具完成工作"的案例：

以上种种都意在说明，我使用 HTML 而非 Markdown 的真正原因是，它能让我感觉与 Claude 的联系更加紧密。随着 Claude 承担的任务越来越多，我发现自己渐渐不再仔细审阅它给出的方案，我希望能有一种方式来持续关注它做成的各项决策，而不是直接交差。HTML 恰好满足了这一需求。

AI 智能体平台正在积极寻求改进人机交互界面的方法，包括在标准文本机制之外增加更多交互式界面。生成式 UI" 能够让智能体根据用户需求实时生成定制化交互界面。

查看英文原文：https://www.infoq.com/news/2026/06/anthropic-html-markdown-agent/"

Google OpenRL 是一个用于大型语言模型（LLM）后训练微调的实验性自托管 API

作者：Sergio De Simone — Tue, 30 Jun 2026 07:21:00 GMT

谷歌 GKE Labs 推出"了开源项目" OpenRL，为在标准 Kubernetes 集群上对大型语言模型（LLM）进行后训练和微调提供一个自托管 API。

谷歌表示，OpenRL 将强化学习（RL）基础设施从 AI 研究中抽象出来，使机器学习团队能够直接在自己的集群上扩展后训练工作流。

据谷歌工程师称，在大型语言模型（LLM）上进行基于代理的强化学习时，“极易因系统复杂性高而陷入困境”。即使是一个简单的强化学习循环，也需要同时处理许多环节：数据准备与清洗、环境选择、训练循环调试、奖励设计、处理推理不一致问题、硬件配置以及底层基础设施管理。

这些都是棘手的问题。但真正让情况变得更加复杂的是，在当今的工具和框架中，AI 研究与基础设施问题紧密地交织在一起。

谷歌工程师认为，通过将基础设施与 AI 研究分离，这些挑战将变得更易于应对，使专业团队能够专注于各自的领域，这与 Kubernetes 通过实现基础设施抽象化，从而为应用程序开发人员和可靠性工程师简化工作流的方式如出一辙。

OpenRL 提高训练后微调效率的方式之一，是在你的基础设施上运行多个强化学习任务，借此提高整体的 GPU 利用率。据谷歌研究人员称，传统的强化学习循环是严格按顺序执行的，这往往导致 GPU 在等待 CPU 或网络受限任务（尤其是奖励计算）完成时处于空闲状态。

此外，谷歌指出，OpenRL 通过明确划分职责来提升用户体验：研究人员可以专注于开发强化学习循环，而工程师则负责执行和扩展训练后微调工作流。

在进行研发时，你无需直接在配备 GPU 的机器上运行强化学习循环，而只需在 Mac 上运行强化学习循环，并将其指向在 Kubernetes 集群或虚拟机上运行的训练 API 即可。

OpenRL 代码库中还包含一个 autoresearch 方案，演示了如何在 Gemma 模型的 text-to-sql 工作流中，针对参数扫描运行并行实验并优化奖励信号。除了实际的应用价值外，谷歌还将其作为自动化如何简化并扩展 AI 研究的范例做了重点介绍。

OpenRL 可以在 macOS、Nvidia GPU 和 GKE 上轻松使用。此外，得益于其与 Tinker" 端点的兼容性，它还能与 Tinker-Cookbook" 集成。

OpenRL 并非唯一致力于通过更好的分离关注点来简化训练后微调的尝试。例如，FeynRL" 确保了微调方案与系统逻辑的分离，这不仅使研究人员能够更轻松地开发和测试新方法，还能借助 DeepSpeed、Ray 和 vLLM 等工具实现这些方法的规模化应用。

原文链接：https://www.infoq.com/news/2026/06/google-open-rl-fine-tuning/"

3000块钱，这支中国团队把ChatGPT成功的“秘密”用在了机器人训练上

华卫 — Tue, 30 Jun 2026 07:07:50 GMT

作者 | 华卫

策划 | 蔡芳芳

两年时间，大语言模型横扫全球。而机器人发展了几十年，依然难以走出实验室。问题可能出在，机器人还没有属于自己的“数据互联网”。

对ChatGPT来说，其核心架构Transformer是Google在2017年提出的；OpenAI做对的，是另一件事：把数据规模推到前所未有的量级，核心要素就是海量、低成本、易获取的互联网文本数据。仅有规模还不够，OpenAI在ChatGPT训练过程中设计了一套数据反馈链路策略RLHF。当模型参数足够大、有效数据足够多，智能就“涌现”了。

机器人训练要实现类似的突破，或许也需要一场精妙的数据策略：不仅要有足够的数据，精度也得够。然而，在当前具身智能领域中，虽然已经出现大量训练场和数据采集中心，但真正可用于训练的数据规模仍十分有限。

与大模型能依赖互联网公开数据不同，机器人数据从一开始就很“贵”。传统机器人训练要么需要请专家写代码，要么需要专业的遥操作设备、光学动捕系统、力矩传感器来采集数据，这些设备加在一起，少则几十万，多则上百万。更麻烦的是，每家厂商的机械臂，电机、力矩、尺寸都不一样，在A机器人上采的数据，到B机器人上可能完全不能用。每一台机器人本体，都是一座“孤岛”。仿真数据成本低，但离现实的“鸿沟”不小：在仿真环境里练得很好机器人，放到现实世界可能就失灵了。

2024年，斯坦福UMI抓夹开源，行业一度沸腾。一套3D打印的塑料架绑上一个GoPro相机，成本只需要400美元（约合2800元人民币），证明了“低成本采集”这条路走得通。然而，UMI有自己的天花板。其精度只有厘米级，抓个积木、叠件衣服还行，但像拧螺丝、穿针引线、精密装配，但凡需要“手感”的任务，UMI就训不出来了。并且，它只能单臂操作，而人类80%以上的日常操作场景需要双手协同。

现在，国内一支团队拿出了一套千元级的手持采集系统UMI ver.2 并将其开源。这套系统不仅是能实现毫米级精度、双臂协同的真正生产力工具，价格还只有传统方案的1/100、甚至更低。在成本已经被UMI打下来的基础上，UMIver.2把精度和维度也提上去了。

项目地址：

https://github.com/qiongming-intelligence/UMI

https://gitee.com/QiongMing-Intelligent/UMI

这支团队来自穹明智能，由“前华为天才少年”李元庆领衔，成立于2025年底。短短两年内，团队在具身智能数据定义与工具链开发取得显著突破，首次提出“伴随式数据采集”理念，自研外骨骼设备 CoMiner、口袋机RoboPocket等数采设备，并与优必选等头部人形机器人企业、地方大型数采中心及跨国数采基地达成战略合作。同时，穹明智能还推出了搭载自研大脑的软硬件一体解决方案，并在酒店服务、零售药房等真实场景中批量部署。

在与穹明智能团队的独家对话中，我们获悉了更多关于这套千元级系统背后的深层思考，包括技术策略、开源背后的决策与成本控制方面的取舍。

毫米级精度的数采，成本怎么压到千元级？

首先，UMI ver.2的优势很直接地体现在参数上：精度达到毫米级定位，误差控制在 0.5mm 以内，较上一代 UMI 实现了十倍以上的跃升。该精度水平已能够覆盖大多数精细操作类具身任务的数据采集需求。

“我们其实是把机器人学习看成一个系统性问题。从底层数据一直到算法、再到评估和部署，是一个不断循环的过程，每一个环节都会影响最终效果。但如果回到本质，机器人学习仍然是深度学习问题，而深度学习本质上是‘数据的游戏’，好的数据才会带来好的模型。”

穹明智能技术探索负责人高圆寺表示，其目标场景是家庭，这类场景的特点是任务长、操作复杂，对数据质量要求非常高。传统的遥操作方式虽然精确，但成本高，而且人的动作并不总能被机器人真实复现。所以他选择从数据侧切入，用 UMI 这种“无本体采集”的方式，它和机器人本体是解耦的，更适合在家庭的真实环境中做数据采集，把数据规模先做上去。“算法当然也重要，但我们更倾向于先把数据理解清楚，再通过迭代去不断优化模型。”

UMI有一个行业默认的痛点：数据有效率低。采集了100个小时，真正可用的可能只有10个小时。对此，穹明智能团队的做法是：将提升 UMI 数据的可用性提升当作一个系统工程，从多个方面展开来解决问题。

一是多传感器之间的同步和对齐，包括硬件层面的时间同步以及软件层面的标定。二是视觉数据本身的质量，比如视频需要有足够大的视场角，避免操作过程中出现盲区；同时，自动曝光必须收敛快，例如在光照复杂的家庭场景，如果曝光跟不上，数据很容易失效。另外，位姿估计方案也很关键，团队评估后认为SLAM的精度在家庭场景会下降，红外方案更为合适。

“我们把 SOP 定义得很细，从源头去保证数据质量。”高圆寺解释道，采集流程本身经常被忽略，如果操作不规范，比如动作过快，数据同样会失效。

而与此同时，UMI ver.2 的整机成本才不到3000元，相比传统动捕方案可以节省90%以上成本，并且全套硬件透明可采购。更关键的是，部署效率极高，仅需30分钟就能跑通全流程，接近于一套可快速复制的数据生产基础设施。这意味着，原本集中在少数机构手中的高质量数据采集能力，具备了向更广泛开发者与中小团队扩散的可能。

“我们不是为了低成本而低成本，而是我们对 UMI 数据的定位让我们选择了当下的方案。”高圆寺强调。据透露，从训练通用具身模型的角度来看，真正需要的是多源异构数据，如遥操作数据、UMI 数据、仿真数据、互联网数据等，不同构型的数据对于模型有不同贡献。

在穹明智能团队看来，不追求UMI采的数据能够一次性训练出高精度泛化模型，只要让模型理解人类操作意图就可以了，不一定要达到亚毫米级别的精度。因此在硬件选型上，他们的原则是在保证数据对齐和视频质量的前提下，尽量选用实惠的组件。同时，团队在整个训练 pipeline 上做了优化，让 UMI 数据能和真实机器人数据对齐。

完全对外开放，“开源是勇敢者的游戏”

一套不到3000元的系统，精度做到毫米级，还能双臂协同。但真正决定它能走多远的，可能是生态：有没有足够多的人和公司使用这套系统，并在这个体系里持续贡献和迭代。

“达到最终通用模型的数据规模大到堪比一个‘登月工程’。”高圆寺很直接地指出，这些数据不可能靠几家初创公司或大厂在内部就能采集完成，需要大家一起参与进来，把大家的日常行为都记录下来。甚至从理想状态来看，可能需要把大家日常生活中的行为逐步记录下来，才能覆盖真正需要的数据多样性分布。

因此，穹明智能团队的选择是：彻底开源。“我们一开始也有点纠结，最终大家还是达成一致。所有源码、硬件清单、部署教程、训练推理流程完全开放，用户可自由使用、修改、分发，二次开发衍生作品需以同等协议开源，保障社区共享与技术普惠。”

穹明智能品牌与开发者生态负责人郁葱葱透露了这个决定背后的考量：“现在我们看到这个行业是由少数公司推动，或许未来会变成整个生态的持续迭代加速，那个时候不再只是比‘谁技术更强’，而是谁打造了更好的生态圈，站在了生态的中心。”

他也坦言，开源存在风险，比如协议违规与商用滥用、技术碎片化导致难以形成统一标准、未经验证的修改引发设备损坏或安全隐患、社区维护压力影响版本迭代与体验、高精度定位能力被用于非合规场景。

“开源是勇敢者的游戏。”在穹明智能团队看来，这些风险并不意味着开源本身不可行，关键在于如何通过更清晰的协议约束、分层的能力开放机制以及社区共建的治理体系，把不确定性收敛在可控范围内。

据介绍，UMI ver.2将明确采用GNU General Public License Version 3（GPLv3）开源协议。GPL-3.0是目前最严格的开源协议之一，相比GPL-2.0，它进一步增强了对开发者和开源社区的保护，特别是在专利和许可证兼容性方面。

该团队对理想开源生态的想象，是一个全栈开放的完整体系：硬件BOM清单公开、成本可控、配件通用，不到3000元即可完整复现；软件全开放，驱动、采集、校准、训练、推理全链路代码开源，兼容LeRobot等主流框架，降低二次开发门槛；示范数据、预训练模型、配置文件共享，支撑跨机型迁移；兼顾共享与商用边界，鼓励学术与商业协同创新，不设技术壁垒；生态平等，小团队、高校、企业同一起跑线，人人可搭建专业级具身智能平台。

围绕这一体系，穹明智能希望推动的，是一套可规模化复制的基础设施：低成本批量部署在高校与实验室，30 分钟内搭建毫米级数据采集能力；支持更多单 / 双臂机器人平台，形成统一数据采集与格式标准；开发者共同优化精度、稳定性与易用性，贡献案例、修复问题、共建工具链；在精密装配、小件组装、工业验证、教学实验等场景形成“采集—训练—部署—反馈”闭环；推动毫米级动捕采集、空间校准流程成为通用规范。

值得期待的是，拥有开放生态的UMI ver.2，未来有望成为全球具身智能领域通用低成本数据采集基建，支撑海量高质量示范数据生产的同时，形成开箱即用的机器人通用技能库，不仅能一键复现抓取、开箱、拧螺丝、精密插接等任务，还将推动产学研用深度协同，中小企业低成本实现机器人智能升级。

新的模型范式，很快就会出现

穹明智能团队下一阶段最核心的目标，是完成整个机器人数据 infra 的搭建，并跑通一个完整的闭环。机器人数据本身是高度异构的，遥操作数据、UMI数据、仿真数据、互联网数据等每一种都有不同的特性和适用场景，他们要做的就是把每一种类型的异构数据都跑通，搞清楚它应该应用在什么样的场景里，然后沉淀为一套infra。

“我们相信，有了这样一个强大的 infra 之后，很多更有意思的能力，其实是会自然‘长’出来的。”高圆寺表示，等这套 infra 相对成熟之后，他们也会考虑把这部分能力一起开源出来，让更多人可以参与去共建，不管是提交数据还是一起去改进。

如果数据规模真的跨过了那道门槛，机器人领域会不会也长出一个“基础模型”？这个问题，我们抛给了穹明智能总经理、乐享科技联席CTO李元庆。“我个人是比较相信机器人基础模型会出现的。”但他随即补充了一个判断：即便有了“技能权重”，事情也不会像想象中那么简单。每个用户的使用环境和习惯差异非常大，物品摆放、空间布局、以及细微的个人偏好都会对最终执行效果产生影响。即便同一个技能，在不同用户那里也往往需要做一定程度的个性化调整。

“对于叠衣服、做菜这类通用任务，如果基础模型真的强到只需下载技能权重就能做到，那自然是理想的。但目前来看，短期内通用任务也仍然需要一定程度的微调。即便在各种强化学习、动作生成策略、世界模型不断进步的情况下，其成功率仍然有提升空间。”

谈及未来的机器人能力，李元庆表示，哪怕未来模型真的已经非常成熟，甚至机器人已经非常接近类似 AGI 的状态，整个能力体系大概还是会分成三个层次。第一层是基础模型，其价值在于提高基础任务的成功率，同时尽可能减少后续反复“再教一遍”的成本以及post-training或者二次微调的时间和次数。

第二层是post-training，在每个人的用户习惯和具体场景之下，机器人没见过的东西，还是要再教一遍，目标是让机器人能够稳定地在真实环境中落地。第三层是用户本人的现场示范。对待一些特别复杂的操作，如按键方法和使用方式与常规物品不同的小众设备，也需要由用户本人或者在机器人旁边的伙伴，现场再教它一次具体操作。

对于机器人领域的“ChatGPT 时刻”，穹明智能团队内部的定义是：一个通用机器人模型或者整个机器人体系跨越了“玩具”、科研、demo 的阶段，进入了一个大众和产业都能够明显感知到“它比较实用”的阶段，形成了开发者生态、数据飞轮和商业的真实爆发。“在今年年底到2027年之间，有机会出现这样一个拐点。行业里现在的共识是，整个赛道可能处于从GPT-2的阶段慢慢走到GPT-3阶段前夜的状态。”李元庆说道。

此外，高圆寺提供了一个更底层视角的观察：ChatGPT成功本质上是把“下一个词元预测”这件事规模化到了极致。那个时间点其实完成了两件事，一个是有了Transformer这样一个非常强大的序列到序列模型，二是把所有语言问题都统一形式化成“下一个词元预测”。他表示，从目前的进展来看，“无本体”数据采集方式的出现，会大大加速数据规模的获取，数量在飞速地 scale up 上去。

“对应到机器人领域，一个关键问题是：我们是不是已经有了类似Transformer这样的‘统一模型’？我个人的判断是，其实已经非常接近这个时刻了，也就是出现一个真正适用于机器人操作或者导航任务的通用模型。但数据这一层还需要大量更多探索，不只是规模问题，也包括我们到底该怎么理解数据，比如数据该如何评估、应该包含哪些模态。不过应该也很快了，今年或者明年应该就会有新的范式出现。”

李元庆也同意这个判断，他认为 2026 年底会出现一批“比较可用”的机器人基础模型；2027 到 2028 年之间，会出现更成熟、更稳定的模型形态。但他也强调，现在模型和数据集架构还在快速变化，没有完全地定型。好消息是，已经有任务跑出了明确的结果。“在一些单一任务、链条比较短的操作场景里，成功率已经可以接近95%，而且在实际执行中已经能完成一些不错的工作了。”

几十万的设备只能服务少数精英实验室，几千元的设备却可以服务整个行业。UMI ver.2的出现，令高精度数据采集的成本降到了千元级，机器人训练开始具备“复刻ChatGPT路径”的群众基础。

正如李元庆在采访中所说，“机器人赛道本身是非常典型的‘长坡厚雪’状态。”机器人的“ChatGPT时刻”，或许还需要一个类似Transformer的架构突破。但“数据”这个最原始的问题，已经被撬开了一道口子。

受访者介绍：

李元庆穹明智能总经理、乐享科技联席CTO

专注具身智能领域，前华为“天才少年”，前华为云具身智能具身规划负责人、ROBO_AGENT负责人，先后参与芯片、盘古大模型等项目， 36 氪 2026年度 36 Under 36 榜单入选者，目前带领团队负责核心技术攻关，聚焦家庭具身智能产品研发，推动多机异构技术路线落地。

高圆寺穹明智能技术探索负责人

郁葱葱穹明智能品牌与开发者生态负责人

前字节数据平台开源社区运营负责人、前腾讯云开源社区运营专家，在字节期间主导数据平台第一个开源项目：BitSail（数据集成），带领团队获得CSDN年度开源影响力项目与InfoQ杰出开源运营团队。负责构建腾讯云发起的OpenCloudOS开源操作系统社区治理框架，联合上下游多家软硬件企业推动社区社区治理架构成搭建与运营。

Snowflake 语义模型与视图构建指南：最佳实践及避坑红黑榜｜技术实践

Akshay Rajshekar Shiraguppi — Tue, 30 Jun 2026 07:00:00 GMT

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载"《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

在 AI 驱动的分析和自助式 BI 时代，强大的语义层至关重要。Snowflake 的 Semantic Views 允许你直接在 Snowflake 中定义面向业务的概念——实体、关系、维度和指标。这为 Cortex Analyst 以及最终的 Cortex Agents / Snowflake Intelligence 等工具提供支持，使其能够进行自然语言查询，同时确保治理、一致性和性能。

本指南将带你了解如何在 Snowflake 中构建一个有效的语义层，并提供实用技巧以及经验换来的 DOs 和 DON’Ts。

为什么 Semantic View 在 Snowflake 中很重要？

Semantic View 作为原始表或视图之上的受治理业务接口。它定义了：

逻辑表（如 Customers、Orders 等业务实体）；关系（join）；维度（用于切片分析的属性）；指标（如 Total Revenue 等计算型度量）；Cortex search（用于提升字面字符串搜索效果）；命名筛选器（可在查询中复用的已保存条件）；已验证查询（带有正确答案的示例黄金问题，为 LLM 提供准确回答的示例）。

这在技术数据模型和业务语言之间架起了桥梁，支持准确的 AI 查询、一致的 BI 报告，并减少逻辑重复。

提升效果的关键最佳实践

设计原则：

像终端用户一样思考：使用业务术语，而不是技术列名；从小处开始：先从 1 张表或一个聚焦领域入手（初始 POC 最多 5–10 张表）。验证后再扩展；尽可能以星型 schema 作为基础，以简化建模；将相关对象放在同一个 schema 中，以便更轻松地进行权限管理。

描述与上下文：

为表、列、指标和关系撰写高质量、详细的描述。这些内容会直接影响 AI 的理解；添加同义词（例如，“Revenue” = “Sales Amount”），以处理自然语言中的不同表达。

指标与逻辑：

定义精确的指标表达式（例如，用 SUM(order_amount) 表示 Total Revenue）；将计算逻辑集中在这里，避免下游出现不一致。

版本控制与协作：

使用 dbt packages（例如 dbt_semantic_view）或 YAML 导出文件进行 Git 管理。

DOs 和 DON’Ts

DOs✅：

从单表或简单视图开始，学习语法和约束；使用一致、朴素、可预测的别名——在这里追求创意会带来问题；确保相关表中的标识符唯一且命名一致（例如，始终使用 customer_id）；利用 Snowsight 中的 Autopilot，从元数据或 BI 工具（例如 Tableau twb 文件）中更快地完成初始化。

优先处理高影响力领域（能够回答 80% 问题的那 20% 数据）；使用 RBAC 进行安全控制，并监控使用统计信息（Semantic Views 原生支持）；基于反馈和查询日志持续迭代；使用“已验证查询”建立单元测试；利用 Tags 对数据进行筛选或分组；使用 evaluations 识别语义模型中的问题和回归；使用 suggestion section 借助 AI 加速并改进开发。

DON’Ts❌：

不要为逻辑表使用泛泛或晦涩的名称（例如，避免 T_CUST_01），应使用 customer 这样的业务术语；不要跳过描述，糟糕的元数据会导致 AI 生成不准确的 SQL；不要忽视多表设置中的冲突；需要谨慎设计关系；不要把它当作一次性建设；要为持续维护和演进做好规划；不要只依赖语义模型（YAML）；应优先使用 Semantic Views，以获得 RBAC、统计信息和集成方面的优势。

结论

一个构建良好的 Snowflake Semantic View，能够将你的数据平台从原始数据仓库转变为面向业务的智能层。它可以减少分析师的重复劳动，提高 AI 的准确性，并强化单一事实来源。

原文地址：https://medium.com/snowflake/how-to-build-an-effective-semantic-model-view-in-snowflake-%EF%B8%8F-best-practices-dos-and-donts-f822bc1a4db4"

点击链接立即报名注册：Ascent - Snowflake Platform Training - China"，更多 Snowflake 精彩活动请关注专区"。

AI 接进企业之后，API 安全开始成为新盲区

李冬梅 — Tue, 30 Jun 2026 06:15:38 GMT

当企业讨论AI落地时，最先被摆上台面的通常是效率、成本和业务创新。客服能不能自动回复，研发能不能提效，知识库能不能被调用，工单能不能自动流转，销售、财务、HR能不能接入大模型工具。

但在这些问题背后，还有一个更基础的环节：API。

近日，Akamai北亚区技术总监刘烨在一次公开分享中提到了该公司关于API安全的调研结果。相比传统安全报告中常见的漏洞、攻击流量、DDoS等话题，这份报告更值得关注的地方在于，它把API安全和AI应用放到了一起讨论。

原因并不复杂。无论是大模型、AI Agent，还是接入了大模型能力的智能客服、聊天机器人、企业知识库和业务系统，本质上都需要通过API与数据、系统、外部工具发生交互。过去，API更多是系统之间的接口；现在，它正在成为AI调用企业能力、触达内部数据、执行任务的通道。

换句话说，AI能不能真正进入企业工作流，很大程度上取决于API；而AI一旦被攻击者利用，风险也很可能沿着API扩散。

根据Akamai披露的亚太专题调研数据，过去12个月里，81%的亚太地区受访企业遭遇过API安全事件；在各类API安全攻击中，43%的攻击针对AI应用、大语言模型相关API；亚太地区每一起API安全事件造成的平均经济损失超过100万美元，其中日本企业损失均值最高。

这组数据至少说明两件事。第一，API安全已经不是少数技术团队内部的问题，而是会造成实际经济损失的企业风险。第二，AI相关API正在快速进入攻击者视野。

刘烨提到，在亚太地区常见的API安全事件类型中，AI相关API攻击排在前列。其后还包括权限控制缺失或不足、数据泄露、未受管理的API，以及API错误配置。

这些风险本身并不新。比如越权访问一直是API安全中最常见的问题之一，攻击者可能只是修改URL参数、Token值或对象ID，就能看到不属于自己的数据。数据泄露也并不罕见，API在返回信息时，可能把敏感字段一并带出。Shadow API、僵尸API则来自开发和运维流程中的失控：曾经上线、内部使用、无人维护或没有纳入统一管理的接口，最终都可能成为攻击入口。

不同的是，AI把这些老问题放大了。

传统云应用中，API调用大多来自人的明确操作。用户查订单、订酒店、购买商品、提交表单，路径相对清楚。AI Agent进入后，调用链路变长了。用户不一定直接操作系统，而是向Agent描述目标，由Agent判断该调用哪些工具、访问哪些接口、读取哪些数据，甚至进一步触发外部应用。

这会带来一个直接后果：企业很难再只用过去的方式理解“访问主体”。过去是人访问系统，现在可能是人授权Agent，Agent再调用多个API。攻击者未必直接攻击模型本身，也可能诱导Agent使用已有权限去访问不该访问的数据，或者执行不该执行的操作。

这也是AI时代API安全和传统API安全最大的区别之一：攻击边界更模糊，权限控制更复杂，风险链条更长。

刘烨在分享中提到，传统应用的身份认证和权限分配，通常围绕用户身份展开；而AI Agent的权限边界更难把握。它到底能访问哪些接口，能拿到哪些数据，能否跨系统执行操作，权限应该是一次性、短期、受限，还是长期有效，这些问题都比过去更复杂。

更麻烦的是，很多企业连自己的API资产都没有完全摸清。

报告中有一个数据值得警惕：能够清晰掌握API资产盘点的受访者比例平均只有约20%。也就是说，大量企业并不知道自己到底开放了哪些接口，哪些接口可以被外部调用，返回的数据是否包含敏感信息，是否存在未被纳管的影子API。

在这种情况下接入AI，就像在一栋楼里安装了自动通行机器人，却没有完整门禁清单，也不清楚哪些房间放着敏感资料。AI提升效率的同时，也可能扩大原有安全盲区。

MCP的出现，让这个问题进一步复杂化。

随着Claude、各类企业AI Agent和内部工具连接需求增加，MCP这类模型上下文协议开始被更多开发者和企业关注。它的价值在于，让模型、工具、数据源之间的交互更加标准化。但标准化并不意味着天然安全。企业未来不只要识别Shadow API，还要识别影子MCP服务器、未经批准的Agent，以及Agent在访问内部工具时是否发生越权。

从这个意义上说，AI没有改变API攻击的最终目标。攻击者仍然想窃取数据、越权访问、操控业务逻辑。但AI改变了攻击路径：过去攻击者直接找接口漏洞，现在可能利用Agent的权限、上下文和工具调用链路，把合法访问变成非法操作。

这也解释了为什么仅靠传统WAF或网关已经不够。

WAF对特征类攻击、速率攻击、部分已知攻击模式仍然有价值，但它并不擅长识别业务逻辑漏洞、权限滥用、敏感数据泄露和凭证失效等问题。比如一个请求从协议和格式上看完全合法，但它访问了不该访问的数据，或者通过Agent的上下文绕开了原有业务限制，传统边界防护就很难判断。

刘烨认为，企业需要从单纯“安全防护”走向“安全治理”。这意味着，API安全不应该只在系统上线后被动防御，而要覆盖全生命周期。

第一步是资产盘点。企业需要持续发现所有API，尤其是AI生成代码、快速迭代业务和内部工具带来的新增接口。没有可视性，就谈不上防护。

第二步是态势管理。企业要知道API是否存在配置错误、授权问题、敏感数据暴露风险，哪些接口返回个人信息、财务数据或业务核心数据。

第三步是运行保护。系统上线后，需要建立访问行为基线，区分正常调用、异常调用和潜在攻击。AI场景下，人工访问和Agent访问最好分别建模，因为二者行为模式不同。

第四步是主动测试。安全测试要前置到开发和测试阶段。无论代码由人写，还是由AI生成，都需要经过API安全审计和自动化测试。AI可以加快开发，也会加快漏洞进入生产环境的速度。

这套思路并不新，但在AI场景下紧迫性更高。因为AI正在加快企业系统变化速度，也在增加API数量和调用频次。过去一个研发团队慢慢写接口，安全团队还有时间跟进；现在AI可以批量生成代码、快速搭建应用，如果测试和治理体系没有同步自动化，安全团队会很难跟上。

值得注意的是，中国企业在这份调研中的表现相对更好。沟通会披露的数据显示，亚太地区API安全事件平均发生率为81%，中国为63%，在中国、印度、日本、新加坡四个调研国家中最低。刘烨解释称，这与国内企业安全测试体系相对完善有关，58%的中国企业已将安全测试深度融入开发全流程。同时，国内移动应用发展成熟，企业对API交互模式更熟悉，也更常态化地开展OWASP API风险检测、红蓝对抗和模拟恶意流量测试。

但这并不意味着国内企业可以放松。因为AI应用接入核心业务的速度，可能比安全治理成熟的速度更快。

一个典型矛盾是：业务团队急着让AI接入客服、研发、知识库、工单系统和内部工具，安全团队却未必掌握AI背后到底连了哪些接口、能拿到哪些数据、是否存在越权路径。企业一边希望AI更有用，一边又需要限制AI不能“太有权限”。如何在效率和安全之间找到边界，会成为接下来企业落地AI的关键问题。

Akamai给出的答案，仍然回到API全生命周期治理。其API Security Solution主要覆盖持续发现、态势管理、运行保护和主动测试四个环节。针对AI场景，Akamai也在加入对MCP服务器发现、Agent访问行为监测、越权行为识别等能力。

此外，Akamai近期宣布拟收购LayerX，后者提供基于浏览器的AI使用控制和安全企业浏览器技术，方向是管控员工使用大模型时的访问行为、提示词内容和数据上传行为。

不过，对企业来说，采购某个工具并不等于API安全问题自动解决。真正困难的地方，仍然在组织和流程。

报告中提到，管理层与技术团队之间存在认知偏差。高管往往更关注总体战略、合规和预算，可能认为公司已经具备较强安全能力；一线安全和开发安全团队则更清楚接口迭代、影子API、权限漏洞和真实攻击压力。刘烨提到，要缩小这种偏差，需要统一风险评估标准，建立基于OWASP API风险、红蓝测试和自动化工具的客观指标，并把安全风险与业务目标绑定。

这点对AI尤其重要。很多企业上AI时，最先看到的是效率提升；安全团队看到的，却是更复杂的访问路径、更模糊的授权边界和更难控制的数据流向。如果管理层只看到前者，看不到后者，AI项目推进得越快，潜在风险积累也越快。

从行业角度看，AI时代API安全的核心变化，不在于攻击者突然有了全新的目标，而在于企业系统的连接方式发生了变化。AI Agent让接口调用从“人点按钮”变成“模型替人执行任务”；MCP等协议让模型和工具的连接更标准，也让新的资产类型出现；AI生成代码让开发提速，也让安全测试必须更早、更自动化地介入。

因此，API安全不再只是应用安全团队的局部工作，而会成为企业AI治理的一部分。

未来企业要回答的不是“要不要接入AI”，而是接入之后，AI能访问什么，不能访问什么；哪些数据可以被调用，哪些必须隔离；Agent的行为如何监控，越权如何发现；AI生成的新接口如何测试；出海业务面对不同地区法规，如何把合规要求变成可执行的技术规则。

AI提高了企业调用系统和数据的能力，也同步提高了攻击者利用这些能力的可能性。

这正是API安全在2026年重新被放到台前的原因。

从 VCloud 到 Agentic VCloud：Agent 时代的范式重构

火山引擎视频云 — Tue, 30 Jun 2026 05:30:00 GMT

站在大同善化寺的大雄宝殿中，我打开与豆包的视频通话，将镜头对准殿左右的金代彩塑，问道：“给我讲讲这些金代彩塑，哪几尊塑像最值得细细端详？”豆包会像真人讲解一样，先“看到和认出”彩塑，再“听懂”问题，然后“思考”如何回答，最后说出答案。

如果你也在景点或展览中这样向豆包提问过，会发现豆包的讲解能力已经接近普通真人讲解员的水准。留心观察，你会发现越来越多像豆包一样能看能听、能想能说的 Agent 正出现在不同的生活和工作场景中。在它们身上，音视频不再只是被人单向消费的内容，而是支持其面向真实世界进行输入与输出的重要能力。

在人与 Agent 协同共存的趋势下，视频云的任务不再只是保障内容流转，还要支撑人与 Agent 之间的意图交互。

过去，音视频是被消费的内容，视频云的主要任务是让音视频以更清晰、更稳定、更低延迟、更低成本的方式服务用户，为人带来更好的观看和互动体验。现在，Agent 成为了视频云的“超级用户”，需要依靠视频云去感知世界、理解世界、执行任务、交付结果，只做好采集、传输、存储、转码、分发和播放已经远远不够了。

视频云需要具备更多智能。火山引擎视频与边缘负责人王悦在2026火山引擎 FORCE 原动力大会智能视频云论坛上指出，Agent 时代的视频云既是人与AI协同的交互底座，也是 Agent 在多模态场景下进行感知、处理、表达与执行的重要能力层，更是智能应用连接真实世界的关键基础设施之一。

这意味着，视频云需要面向 Agent 时代完成一次自我重构：在继续服务好人的同时，也要满足好 Agent 提出的新需求。

从 VCloud 到 Agentic VCloud

在过去相当长的一段时间内，音视频都是人们获取信息的媒介，主要服务于传播场景。从广播、电视到后来的长视频、短视频、直播、播客，承载音视频的产品形态在随着技术发生变化，但服务的对象始终是人，服务的价值始终是满足人的感官体验和内容获取需求。

随之诞生的视频云，实际上是在解决如何兼顾极致的体验和成本的问题。服务于这个目标，视频云形成了比较稳定的发展逻辑：更高画质、更低延迟、更强并发、更优成本。这也是火山引擎视频云业务过去10年一直在积累的“抖音同款能力”——为数亿用户提供流畅稳定的视听体验。

到2023年大模型兴起之后，音视频内容不再只是制作出来供人观看的内容，还成为了 AI 感知世界、理解需求的重要媒介。再到2026年上半年，行业跑步进入 Agent 时代，音视频又从AI感知的媒介，进化成为了 AI 与人实现意图对齐、输出任务成果的媒介。

音视频从内容媒介到交互媒介的变化，也给视频云的发展带来了新变化。

一方面，视频云仍然需要持续提供传统技术能力。清晰度、低延迟、稳定性、并发能力和成本效率，仍然是视频云向外提供服务的工程地基。尤其在直播、电商、在线教育、泛娱乐和出海视频服务中，存储、带宽、CDN、转码、RTC等能力依然决定了业务能否规模化运行。

另一方面，新的任务已经变得非常明确——视频云的服务对象要从人扩展到人和Agent，让更多产品享受到“豆包同款”的技术能力。OpenAI Realtime API、Google Gemini Multimodal Live API等产品的推出，也都在证明低延迟语音、视频和多模态交互正在成为AI应用的关键能力。

IDC 相关资料显示，2025年上半年AI驱动的“音视频AI实时互动与智能媒体生产”细分市场就已达到4000万美元量级，同比实现大三位数增长。这意味着，视频云的新增量会来自AI应用对实时音视频交互、智能媒体生产和任务交付能力的持续需求。

要抓住这个机会，就得像王悦所说，视频云在 Agent 时代需要从“音视频云服务能力”进化为“连接人与 Agent 的新型智能音视频能力底座”。

最终，新的 Agentic VCloud 会成为 Agent 时代的一项主力基础设施，而不只是像 VCloud 阶段一样只为音视频领域提供服务。它应该让一个企业的数字员工轻松听懂会议语音并识别屏幕内容，也应该让一个内容创作 Agent 轻松地把一句自然语言拆解成素材理解、画质增强、剪辑、编码和发布流程。

如何重构出 Agentic VCloud

从 VCloud 到 Agentic VCloud，视频云的技术坐标系也在进行一次本质跃迁。过去，视频云是服务人类感官体验的内容系统，只面向人类用户响应操作、提供功能；现在，视频云在全速迈入 Agent 意图交付（Intent-to-Outcome）的新时代，要面向 Agent完成意图理解、能力编排、动态调度，并交付可验证的结果。

这会考验视频云的底层架构是否面向 Agent 原生设计，能否提供 Agent 友好的标准化工具能力，能否在真实业务中实现高质量、规模化交付。满足这些要求的视频云需要具备服务长周期任务链路的能力，包括持续感知、理解、推理、工具调用、环境反馈、结果交付。

简而言之，视频云要为 Agent 的完整任务链路提供技术底座。为此，火山引擎 Agentic VCloud 构建了两项核心能力：多模态链路，负责支撑 Agent 的感知与环境反馈；AI MediaKit，负责支撑 Agent 的工具调用与结果交付。

多模态链路是 Agent 的感知基础设施。Agent 主要通过多模态链路来连接实时世界、获取任务目标、得到环境反馈。只有让 Agent 得到实时的、丰富的上下文信息，才能保证其准确、高效地执行任务。这条多模态链路会包括MoQ（Media over QUIC）多模态传输和多模态网关。

其中，MoQ（Media over QUIC）多模态传输负责支撑信息的高效流动。它统一了媒体语义、媒体对象和媒体传输，能够在 Agent 语义场景下同时解决低延迟和大规模并发难题，实现小于600ms Agent 建连时延与亿级AI会话并发。

多模态网关则要在大模型概率世界和确定的物理世界之间搭建语义桥梁，实现 Agent 与实时物理世界的连接，解决信息对齐的问题。为了避免Agent 把“戴尔”听成“海尔”，火山引擎做到了支持10ms语义判停、多模态音画同步以及 99.99% 的语义级可靠传输。

AI MediaKit 则服务于 Agent 的行动，是Agent友好的音视频开发套件，能把视频云积累的“能力组件”编排进“Agent意图交付”的链路中。

有了这个开发套件，当用户对 Agent 说出“把这段直播录制画质提升后发布到抖音”时，就不再需要指定编码器、分辨率和增强算法，而是直接由 Agent 配合 AI MediaKit，把这句话的意图解析成结构化需求，再完成编排、调度和结果交付。

为了实现这种效果，AI MediaKit 构建了一个 Agent-Native 的三层架构：

最上面是意图层（Media Intent），面向Agent提供声明式 API、端云结合的CLI、媒体领域知识 Skill 和 LLM 原生的MCP 协议，能够围绕意图声明清楚“要什么”以及“有哪些约束”；

中间是媒体工作流层，能够把“要什么”和“有哪些约束”自动编排成可执行的算子级工作流，支持对图像、音频、视频、文本四种模态内容的处理，具备感知、增强、编码、剪辑、生成五类基础能力；

最底层是媒体运行时，是负责交付可验证的音视频产物的执行层。这一层能够实现端云结合，并能通过算法、算力、芯片和架构持续提升音视频任务交付产物的完成度。

在上一层编排完成的媒体工作流，会在这一层根据不同的任务复杂度被调度到端侧或云侧上执行。云上为执行高阶任务提供了 Comet 编码芯片、有GenVR音视频增强等相应的高阶能力，本地则会利用 FFmpeg 这类基础能力完成基础任务。

火山引擎正是通过这种技术系统的重构，推动了视频云迈入 Agentic VCloud 阶段。

从比拼视频体验到比拼Agent落地

从 VCloud 到 Agentic VCloud，视频云服务的链路也正在被拉长。过去，VCloud 更多是在某个环节提供能力支持，例如转码、分发、存储、播放或实时通信；现在，Agentic VCloud 要进入 Agent 的完整任务链路，从理解意图开始，参与编排、调度、执行和结果验证。

从被调用的能力模块到支撑任务 Agent 落地的基础设施，视频云的价值衡量维度也随之产生变化。

过去，视频云更多是在“保下限”：别卡顿、别变糊、别宕机，同时把带宽和算力成本压下去。Agent 时代的视频云还要“提上限”：让 AI 能够精准理解音视频上下文，用自然语言触发复杂工作流，并交付达到企业级可用标准的结果。

“今天我们可以很容易地把音视频任务的完成度做到20%，努努力也可以做到60%。但是在企业级场景中，20%的完成度不过是玩具，60%的完成度也只算一个Demo，连及格线都谈不上。我们认为，突破90%的完成度，才算真正迈过企业级产品的门槛。”火山引擎多媒体基础产品负责人杜佑表示，结果的完成度才是行动的终点。

价值衡量维度的变化，也会带来视频云竞争逻辑的变化。

功能、参数和成本，这些能力依然重要，但会越来越像进入赛道的入场券，而不再是决定性差异。新的竞争焦点变成了：谁能把模型、媒体处理、实时通信、工具调用、算力调度和行业 Know-how 组合成稳定闭环；谁能让 Agent 在真实业务里完成长周期任务；谁能在成本可控的前提下，把任务完成度从 Demo 水平推到企业级水平。

这也在一定程度上体现了火山引擎提出建设 Agentic VCloud 的行业意义。它不是一次单纯的产品升级，而是视频云进入新周期的信号：当视频从信息载体变成任务载体，当视频云从内容基础设施变成 Agent 基础设施，行业的价值边界就会被重新定义。

这也是一个重构市场格局的节点。谁能更快完成周期切换，谁就更有可能在 Agent 时代建立新的服务能力和竞争优势。

AWS 为 Cognito 增加多区域故障切换能力

作者：Renato Losio — Tue, 30 Jun 2026 05:00:00 GMT

AWS 近期为 Amazon Cognito 推出了多区域复制（Multi-Region Replication）功能"，可以将用户身份数据和用户池配置从主区域自动同步到备用区域。当主区域发生故障时，应用能够直接在副本区域继续完成用户认证，而无需自行开发数据复制和故障切换机制。

这一复制机制采用单向同步模式，即数据从主区域复制到备用区域，包括用户信息、登录凭证以及相关配置。备用区域平时处于只读状态，但在发生故障切换后，用户仍然可以使用原有账号和密码登录。由于两个区域都能够识别彼此签发的访问令牌，因此已有会话也不会立即失效。

AWS 首席开发者布道师 Sébastien Stormacq" 表示"：

工程团队过去花费了大量时间构建和维护跨区域复制方案，以保持配置同步。人工导出和导入用户数据不仅存在数据泄露风险，也容易导致数据不一致。而在区域切换过程中，用户往往还会遭遇密码重置或重新登录等问题。

Amazon Cognito" 是 AWS 提供的托管身份服务，用于帮助开发者完成用户认证和访问控制。此次更新还引入了客户自主管理密钥支持，为较高安全性和合规性要求的企业提供了更多控制能力。不过，多区域复制功能要求用户提前配置支持跨区域的 AWS KMS 客户托管密钥。

Stormacq 还指出，

多区域复制兼容 Cognito 支持的各种认证方式，包括社交登录（亚马逊、谷歌、苹果、Facebook）、SAML 和 OIDC 联邦身份认证，以及 API 授权流程。

根据官方文档"，目前该功能仅适用于运行在 Amazon Cognito 新一代基础设施"上的用户池，而这一新架构不久前才刚刚正式发布。PostNL 首席工程师、aws-news.com 作者 Luc van Donkersgoed 对此评价"道：

这是用户呼声最高的需求之一。看到 AWS 持续投入 Cognito，也让人感到高兴，这其实是一项相当不错的服务。

不过，这项功能并非没有限制。DanAds 架构师 Daniele Frasca 认为，对于绝大多数场景来说，这是一种“务实的方案”，但它仍存在一些明显约束"：

这是提升认证系统韧性的一大进步，对绝大多数团队来说，能够显著降低系统复杂度。不过，它采用的是主备架构，而非双活架构。正常情况下，备用区域无法进行新用户注册、密码重置或资料更新；TOTP 多因素认证也无法在备用区域使用。如果业务要求所有区域都支持 MFA，这将成为一个硬性限制。与此同时，故障切换依赖 DNS 实现，需要用户自行维护自定义域名和健康检查机制，而账户锁定计数等状态信息也不会跨区域同步。

Reddit 社区的整体反应比较积极"。许多开发者认为，虽然当前版本仍有一些限制，但这项等待多年"的功能终于落地仍然是一件好事。相比之下，Auth0 早已提供多区域部署能力"，因此 Cognito 此次补齐了这一长期存在的短板。

多区域复制以附加功能的形式提供给 Cognito Essentials 和 Plus 套餐用户。对于 Essentials 套餐，每个副本区域将按每月活跃用户（MAU）额外收取 0.0045 美元；Plus 套餐则为每个副本区域、每个 MAU 额外收取 0.006 美元。对于机器到机器（M2M）认证场景，启用该功能后，还需要在标准令牌签发费用的基础上额外支付 30% 的附加费用。

目前，多区域复制仅在部分 AWS 区域提供，包括北弗吉尼亚、新加坡、法兰克福和爱尔兰等。这些受支持的区域既可以作为主区域，也可以作为副本区域。另外，客户托管密钥（Customer Managed Key）功能面向 Essentials 和 Plus 套餐开放，其支持范围覆盖更多 AWS 区域，其中也包括 AWS GovCloud。

查看原文链接：AWS Cognito Adds Multi-Region Failover for Authentication - InfoQ"

Agent 狂吞 Token，表面是模型之争，底层全是煤电博弈

李冬梅 — Tue, 30 Jun 2026 03:02:41 GMT

AI 开始进入算账阶段

过去一年，模型厂商不断降价，DeepSeek、通义千问、智谱、MiniMax 等国产模型，也把大模型调用价格拉到了一个新的区间。表面看，Token 价格是模型厂商之间的竞争结果，可如果往更底层看，每一个 Token 背后，都有一条从电力、土地、机柜、制冷、网络、存储、GPU 调度到企业内部使用方式的长链条。

优刻得董事长兼CEO季昕华在接受 InfoQ 采访中谈到，今天企业老板最关心的事情大致有三件：第一，如何让员工用上、用好 AI；第二，用了一段时间后发现成本很高，如何降低成本；第三，如何真正提高效率。也就是说，AI 不是不用了，而是开始进入算账阶段。

Token 成本不只是 API 标价问题，它正在变成一场贯穿“电力—算力—模型—应用—组织”的系统工程。

优刻得到乌兰察布，最早不是因为 AI。

据优刻得副总裁刘杰回忆，2017 年筹划建设乌兰察布数据中心时，AI 还没有真正起来。当时更多考虑的是 CPU 业务，第一栋楼最初也是按照 CPU 计划来做，后面才逐步转向 GPU。那时优刻得的设想，是把乌兰察布作为服务北京的“前店后厂”：北京是用户和业务前台，乌兰察布提供低成本、低时延的数据中心支撑。

选择乌兰察布也不是拍脑袋。季昕华提到，当时苹果在国内选数据中心，由于对优刻得的技术水平比较认可，曾让优刻得一起参与选址。他们团队跑了很多地方，从贵州、四川、重庆、青海、宁夏、甘肃一路看到内蒙古，最后发现乌兰察布是一个很适合建数据中心的地方。

原因很直接：第一，电比较便宜；第二，苹果要求 100% 绿电，内蒙古有机会做到；第三，天气比较冷，PUE 更好做；第四，离北京近，不管是网络时延，还是人员往来，都比较方便。

这些因素放在云计算时代已经重要，放到 AI 时代更重要。

因为 AI 最终会把所有成本打穿到电力上。季昕华在谈到 Token 降本时说得很直白：Token 的终局是电力，电便宜，Token 就便宜。内蒙古的优势也正在这里。

在现场交流中，刘杰表示，他们其实也算过一笔账。

“以一台某国外顶级服务器为例，其功耗约 6.5 千瓦，一台服务器通常有 8 张 GPU 卡。一个千卡集群大约需要 125 台服务器。仅服务器本身，一年耗电就已经是一个很大的数字；如果再乘上 PUE 系数，才是数据中心真正要承担的总用电。”

这就是为什么数据中心选址、电价、PUE、高功率机柜，会直接影响 Token 成本。

过去 IDC 行业讲“柜子”，更关注机柜数量。但 AI 时代，“多少个柜子”本身已经不够说明问题。优刻得青浦数据中心约 42 亩地，设计容量约 5000 个机柜；乌兰察布园区约 212 亩地，设计容量约 12000 个机柜。但季昕华和优刻得方面都提到，传统机柜和今天 AI 算力需要的高功率机柜已经不是一回事。

大模型训练和推理需要更高的功率密度。普通机柜可能放不下多台高功耗 GPU 服务器，单机柜供电能力、散热能力、网络布线、液冷能力，都会重新定义数据中心价值。现场交流中提到，液冷单机柜可以做到 35 千瓦，这背后需要电路和散热系统专门改造。

如何真正降低 Token 成本？

这也是为什么一些传统低功率数据中心正在出现空置，而高功率数据中心反而供不应求。

季昕华提到，国内现在有些原来低功率数据中心空闲率比较高，但像优刻得这类高功率数据中心，还没有开始建，就已经有订单进来。季昕华表示，新建的数据中心按照前几栋楼的情况和市场需求判断，满载率预计会非常高，已有一些签约订单。

数据中心的成本竞争，正在从“有没有楼”转向“能不能承载 AI”。

乌兰察布的优势也不只是便宜电。

这里海拔较高，年均温度低，天然有利于制冷。PUE，也就是能源使用效率，是数据中心非常关键的指标。简单说，数据中心总用电中，真正用于服务器计算的比例越高，PUE 越低，能源利用效率越好。气温低意味着制冷能耗下降，PUE 更容易做低。

此外，乌兰察布所在区域的能源结构相对稳定。这里有风电、光电，也有煤电，供电结构更稳。对于 AI 数据中心来说，便宜电固然重要，但稳定电力同样重要。

GPU 集群不怕贵一点，怕的是中断和不稳定。训练任务一旦中断，损失的不只是电费，还有时间、算力窗口和客户信任。

所以，Token 降本的第一层答案，是选对地方，把电力成本压下来，把 PUE 做下来，把高功率机柜建起来。

但这只是开始。

季昕华在谈到如何降低 Token 成本时，给出了几个方向。

第一个方向，是使用国内模型。相较海外模型，DeepSeek 等国内模型在价格上有明显优势，智谱、MiniMax 等客户和模型厂商也在持续提升能力。对很多企业应用来说，并不是所有任务都必须调用最贵、最强的模型。一个 85 分的模型在某些任务上确实更好，但一个 80 分模型如果也能完成任务，且成本低得多，就会成为更现实的选择。

第二个方向，是从技术上提高“每度电产生 Token 的数量”。这句话很关键，它把 AI 成本问题重新拉回到基础设施效率上。过去大家习惯讨论每百万 Token 多少钱，但真正决定长期成本的，是每一度电最终能转化成多少有效 Token。GPU 利用率、推理框架、模型部署、网络通信、存储读写，都会影响这件事。

第三个方向，是选择合适的数据中心位置。内蒙古这种电力和气候条件较好的地方，可以在底层成本上形成优势。乌兰察布更适合训练，以及覆盖北方的大部分推理需求；而上海的青浦更适合华东地区对时延更敏感的业务，比如金融、汽车等场景，也更适合部分推理业务。这实际上对应了“东数西算”的分工逻辑：不是所有算力都必须离用户最近，也不是所有算力都适合放到西部，而是要按任务类型拆分。

第四个方向，是模型组合。季昕华提到，不同模型的能力边界不同，企业不能总想着用一个模型解决所有问题。比如有些模型适合前端代码，有些模型适合后端，有些模型适合测试，有些模型适合需求分析或写作。未来更合理的方式，是把一个任务拆开，让不同模型处理各自擅长的部分，甚至由平台自动帮用户选择模型。

这点非常重要。因为 AI 降本并不等于一味调用便宜模型，而是在“效果”和“成本”之间做动态路由。一个复杂任务里，真正需要顶级模型处理的部分可能只有 20%，其他部分可以交给更便宜、更快的模型完成。这样才是面向企业级 AI 应用的真实降本。

第五个方向，是 Prompt 管理和 Prompt Engineering。很多企业现在一边喊 AI 成本高，一边并没有建立内部使用规则。员工怎么提问、调用什么模型、是否复用模板、是否重复调用、是否把简单问题交给高价模型，这些都会影响 Token 消耗。季昕华提到，让员工按照一定规则用好 Token，也是降本的重要手段。

这就把问题从基础设施推进到了组织管理。

企业真正的问题不是“有没有 AI”，而是“AI 花出去的钱有没有产生价值”。

季昕华谈到，优刻得内部每天都会看 AI 使用报告，包括多少员工用了 AI、用了多少钱、用在什么场景上。Coding 是用量非常大的场景，查询、PPT 等场景也在增长。但他也承认，目前最大的问题，是如何衡量这些投入到底带来了多少产出。

这可能是所有企业都绕不开的问题。

AI 工具铺开之后，会出现三类情况：第一，很多员工还在摸索怎么用，效果并不稳定；第二，有些调用并不是为了公司业务，而是个人使用；第三，真正用于公司工作的部分，到底提效多少，还需要评估。季昕华提到，优刻得正在做一个产品，帮助企业分析员工使用 AI 是否用于公司工作，以及使用效率是否高。

Token 需求不会只是一次热闹

这其实是 Token 时代企业管理的新命题。

SaaS 时代，企业买软件，通常按账号、席位、模块付费。员工越活跃，往往说明软件价值越高。但 AI 不一样，用得越多，成本越高。如果企业没有治理体系，老板推动 AI 之后，很快就会遇到一个尴尬局面：感觉没有明显提效，但账单多了一大块。

因此，便宜 Token 的另一面，不是无限调用，而是 Token 治理。

这也是为什么季昕华把“如何让老板或管理干部评估 Token 产生的效益”视为当前最大的挑战之一。

AI 真正进入企业，不只是技术升级，也会倒逼生产关系调整。

未来组织里，高层更需要回答“做什么”和“为什么做”，AI 更多解决“怎么做”，中间还需要懂业务、懂架构的人来驾驭 AI，避免 AI 做着做着跑偏。

他甚至谈到，AI 时代的人才观也会变化。过去企业招聘更看重经验，但有了 AI 之后，学习一门新技术的门槛下降了。主动性、好奇心、自我反思能力、业务理解，可能变得比单纯经验更重要。因为 AI 每天都在变化，真正稀缺的不再只是“会不会写代码”，而是能不能判断问题、拆解任务、驾驭工具，并把 AI 产出落到业务结果上。

这也解释了为什么 Token 需求不会只是一次热闹。

对于算力需求是否长期持续，季昕华给出的判断比较明确：Token 增长是长期趋势。年初某些现象级智能体应用带动了普通用户快速体验 AI，但即便热点退去，Token 量仍在快速增长。

原因在于，AI 能力本身在提升，尤其是 Coding 能力已经让 AI 真正进入“干活”阶段；视频、图片模型让短剧、漫剧等内容生产释放出大量需求；广告营销、市场推广、财务、HR 等企业内部岗位也开始使用 AI；此外，录音转会议纪要、智能眼镜、智能戒指等 AI 硬件，也在持续消耗 Token。

这几个需求来源有一个共同点：它们不是单次尝鲜，而是工作流、内容流和硬件入口的持续消耗。

其中，Coding 是最明确的增长场景。AI 写代码的能力提高后，企业内部研发效率和工作方式会发生变化。后端工程师可以借助 AI 快速写前端，测试和运维边界也会被打通，非研发人员也可以用 AI 完成部分过去无法独立完成的工作。

图像、视频、漫画、短剧则是另一类消耗大户。生成式内容的特点是计算密集、调用频繁、结果需要反复调整，天然会产生大量 Token 和算力需求。

再往外看，AI 硬件把调用入口从电脑和手机扩展到录音设备、眼镜、汽车、戒指等终端，一旦硬件入口真正铺开，算力需求会更加碎片化、常态化。

这也是优刻得判断高功率数据中心会持续供不应求的原因。

AI发展最大瓶颈：物理基础设施跟不上

季昕华把当前国内外的瓶颈做了区分：国内最大问题是缺卡，海外则是缺数据中心。国内 GPU 供应受限，所以首先要找到卡；但有卡之后，还需要高功率数据中心来承载。海外很多区域的算力基础设施还远落后于中国，除了美国之外，不少国家当前反而有大量存储需求，比如数字城市、视频监控数据存储等。

在国内，基础设施瓶颈主要有三个：卡的瓶颈，数据中心审批和统一管控的挑战，以及旧基础设施上的电和水的挑战。中国不缺电，但电力配套要跟着产业发展。比特世界的需求可以指数级增长，但物理世界是原子世界，电网、水、机房、设备交付、施工周期，都有现实约束。

这句话很适合作为观察 AI 基础设施的底层逻辑：数字需求跑得太快，物理供给跟不上。

而在物理供给里，国产算力也是一个绕不开的话题。

季昕华认为，国产 GPU 这几年在国家支持和市场需求引导下，性能提升很快，目前已经到“可用状态”，但整体性能和海外高端产品仍有差距。不过，美国限制反而推动国内大模型公司和硬件厂商加快适配，未来效率会越来越高。优刻得方面也提到，客户对国产算力的明确需求，更多体现在希望国产算力与模型加速适配。英伟达已经形成自成体系的生态，国产算力如果要真正起来，不能只靠单卡参数，而要形成模型、框架、工具链和应用端的生态闭环。

这也意味着，国产算力降本不是简单替代英伟达，而是模型和硬件共同适配后的系统优化。

从这个角度看，AI 基础设施的瓶颈总是在移动。

季昕华在回答“运力”问题时，给了一个很好的解释：Token 生产是由很多组件共同完成的。最开始可能觉得 GPU 不够，于是先提升 GPU；GPU 提升后，发现内存成为瓶颈；内存做大后，又发现卡与卡之间的网络连接成为瓶颈，于是光通信、互联技术开始重要；网络解决后，CPU 调度又跟不上；再往后，不同机器之间、不同机房之间的连接又会成为新挑战。

所以整个系统的工作，就是不断找到瓶颈点、突破瓶颈点，然后迎接下一个瓶颈点。主要矛盾解决之后，次要矛盾就会变成新的主要矛盾。

这其实是 AI 基础设施行业最真实的一面：它不是单点技术革命，而是连续的系统调优。

比如跨数据中心推理。季昕华提到，一些算法正在尝试不在同一个数据中心也能实现跨数据中心推理调度。这样可以把分散算力用起来，但新的瓶颈会变成不同机房之间的带宽和网络延迟。训练目前还不太适合这样做，但推理有机会。

又比如分布式推理。目前最大的瓶颈不在时延，而在算力资源不足。生图几秒返回、生视频几十秒返回，大多数用户可以接受。反而如果把算力分散到各地，可能导致资源浪费：某个城市节点只有 70% 或 80% 使用率，空闲资源却无法被其他地方共享。

所以当前主流仍然是集中式。未来更可能在边缘侧做缓存，有点像 CDN，通过“以存代算”减少重复计算。例如多个用户询问同一个天气问题，答案相同，就不必每次重新推理，可以直接从本地缓存返回。但这套模式还没有完全收敛。

这说明，AI 推理并不会简单复制互联网时代的边缘计算路径。它既要考虑时延，也要考虑算力利用率。当前算力仍然稀缺，把资源集中起来，往往比过早分散更经济。

做中立的 Token 供应商

优刻得在这里找到的定位，是做一个中立的算力和模型服务平台。

季昕华说，优刻得今天已经不只是传统意义上的云计算公司，而是扩展成一家数字化公司，云、大数据和算力是技术手段。面对 AI 时代，其目标是发挥中立性质，帮助大家更好地用好 AI，也帮助 AI 公司更好地实现发展。

中立性过去是优刻得面向游戏、电商等行业客户的标签。游戏公司可能不愿意用腾讯云，电商公司可能顾虑阿里云，因为它们与平台本身存在业务竞争。到了 AI 时代，这种中立性被重新放大。

阿里有通义千问，腾讯有混元，字节有豆包，对创业型大模型公司来说，选择一家相对中立的第三方云厂商，可能更容易获得资源支持，也能减少潜在竞争顾虑。

季昕华还提到，优刻得在 Token 层面也可以保持中立，可以接入多个 Token 来源，为客户选择合适的 Token。

从客户结构看，优刻得面向的算力需求主要来自几类：第一类是基础模型公司，比如智谱、MiniMax、DeepSeek 等，需要大量卡做训练和推理；第二类是行业模型公司，比如金融、证券等有自己数据的公司，需要在基础模型上训练行业模型；第三类是手机、汽车等智能终端；第四类是各种应用场景；第五类是科学计算。

这些客户未必都有能力自建大规模数据中心，也未必都能从巨头那里获得足够细致的资源和技术支持。优刻得的差异化在于，不只是提供机柜，也不只是卖云主机，而是试图提供从数据中心、高功率机柜、GPU 算力、模型部署、Token 计费到企业 AI 使用治理的一揽子能力。

这条路并不轻松。

AI 基础设施本质上仍然是重资产。数据中心建设需要土地、楼宇、机电、UPS、柴发、制冷、液冷和高功率机柜；GPU 和 AI 服务器价格仍在波动；客户希望成本下降，但上游设备并不便宜。现场交流中提到，硬件价格上涨很快，但终端客户拿到的算力租赁价格并没有同步上涨，中间压力需要云厂商和算力服务商消化。

同时，数据中心标准也需要调整。季昕华提到，现有数据中心标准已经落后于 AI 行业发展。现在很多高等级标准要求双路供电、两路 UPS、两路柴发等冗余设计，但并不是所有 AI 产品都需要这么高标准。未来不同业务可能需要更精细化的数据中心标准，而不是所有负载都按最高标准建设。

这也意味着，AI 基础设施的降本不只是“压价格”，还包括重新定义什么业务需要什么等级的基础设施。

比如训练任务对稳定性要求极高，但部分推理任务可能对冗余要求没那么高；金融和汽车等敏感业务适合放在青浦等靠近客户的区域，普通推理和训练任务则可以放在乌兰察布这种电力成本更优的区域。任务分层、资源分层、模型分层，都会成为未来 Token 降本的一部分。

因此，Token 价格战背后的真实战场，已经从模型 API 页面，转移到了电力、数据中心和算力系统深处。

当企业真正开始把 AI 放进代码、营销、财务、HR、会议纪要、智能硬件和行业模型，Token 就不再是技术圈里的抽象单位，而会变成企业账本上的真实支出。

而谁能把一度电更高比例地转成有效算力，把一张 GPU 跑出更多有效 Token，把不同模型组合成更低成本的工作流，把员工的 AI 使用变成可衡量的业务产出，谁才有机会在下一轮 AI 基础设施竞争中留下来。

Token 便宜的尽头，不只是模型降价。

是电力，是算力，是工程能力，也是企业重新学会怎么用 AI。

Atlassian 揭秘 Forge 计费架构：如何在分布式环境下实现大规模用量计费

作者： Leela Kumili — Tue, 30 Jun 2026 02:50:00 GMT

Atlassian 近日介绍了自家 Forge 计费平台"背后的技术架构。该系统负责支撑 Forge 平台的按量计费能力，将分散在各个云服务中的使用数据转换成准确的计费记录。Forge 是 Atlassian 面向 Jira、Confluence 等产品推出的无服务器扩展开发平台，而这套计费系统则承担着在大规模分布式环境下完成使用量统计和费用核算的任务。

随着 Forge 从早期简单的扩展机制逐渐发展成一个按使用量收费的平台，计费依据也变得越来越细。例如函数调用次数、存储使用量以及各种运行时遥测数据，都会直接影响最终费用。这意味着 Atlassian 必须建立一套新的系统，用来收集来自不同服务的大量事件数据，并确保这些数据能够被正确校验、准确归属到对应租户，同时在不重复、不遗漏的前提下转换为可计费记录，并向开发者提供接近实时的使用情况反馈。

从整体架构来看，这套系统由几个部分组成：负责产生使用事件的 Forge 服务、统一的数据接入与流处理层、使用量追踪系统，以及下游的计费和商业系统。所有 Forge 服务都通过统一的事件模型输出结构化事件，从而保证无论数据来自哪个服务，下游系统都能以一致的方式进行解析和处理。

Atlassian 表示：

UTS（Usage Tracking Service，使用量追踪服务）是 Forge 计费体系中的“神经系统”。

UTS 扮演着整个使用数据协调层的角色，负责对进入系统的事件进行校验、标准化、补充上下文信息，并为后续计费流程做好准备。同时，它还负责将使用数据准确关联到对应的授权或订阅对象，然后再写入存储并传递给下游系统。

这些事件通过基于 Kafka 的流处理基础设施以及 Atlassian 内部的数据传输抽象层进行传递。该层不仅负责模式校验，也保证数据能够可靠地送达后续消费者。通过将生产者和消费者解耦，平台降低了服务之间的依赖关系，同时也让数据接入和处理能力能够分别独立扩展。

Atlassian 指出：

这里最复杂的问题在于归属关系和数据格式：每个事件都必须准确归属到正确的授权或订阅上下文，同时还必须符合 UTS 的数据契约要求，才能被下游系统正确处理。

进入系统之后，使用事件会经过追踪层进一步处理，包括数据校验、标准化、上下文补充、去重以及排序等步骤。即使出现事件乱序到达，或者因为重试机制导致同一事件被重复发送，系统仍然能够保证最终计费结果的准确性。

数据接入流水线（来源：Atlassian 博客"）

为了应对分布式环境中的一致性问题，这套系统采用了幂等事件设计和基于时间窗口的聚合机制。重复投递的事件不会导致重复计费，而延迟到达的数据也能够通过窗口处理机制被重新纳入统计范围。

在此基础上，流处理引擎会将原始使用事件转换成可用于计费和分析的聚合指标。数据则分别存储在不同层级的系统之中：长期存储层采用不可变数据结构，以满足审计和追溯需求；低延迟分析层则为仪表盘和 API 提供实时查询能力。

最终，所有使用量数据都会映射到对应的开发者空间，实现按应用维度的使用统计和统一计费。通过这种设计，Forge 能够在大规模环境下提供透明的按量计费能力，同时保证财务数据的准确性以及完整的可追溯性。

查看英文原文：Inside Atlassian’s Forge Billing Architecture for Distributed Usage Tracking at Scale - InfoQ"

非科班出身技术Geek，被DeepSeek改写人生（上集）

InfoQ 中文站 — Tue, 30 Jun 2026 02:22:29 GMT

AI Coding 在这个时候出现了。Hunter 后来在接受 InfoQ 采访时说，Claude Code 以及新一代 AI 编程工具给了他过去没有的“能动性”：只要有想法，就可以真的把它做出来。那段时间，他能做的只有一件事：不断做东西，用一个个项目证明自己还在往前走。

不要将租户隔离托付给LLM！如何在 Snowflake 上正确打造多租户 Cortex Agent ｜技术实践

Brian Hess — Tue, 30 Jun 2026 01:00:00 GMT

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载"《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

Snowflake Cortex Agents 让业务用户可以用普通英语向数据提问，并获得洞察、结果和可视化内容——不需要了解 SQL 或 schema。它让更多人也能参与到数据与分析这场派对中来。

但许多 Snowflake 客户会构建面向自身客户的应用，而其中一个硬性要求是：每个客户只能看到自己的数据。我们不能只是相信 LLM 会在每一次查询中都加上正确的 WHERE 子句——安全不应该依赖 prompt engineering。

好消息是：这些应用本来就运行在 Snowflake 上，而 Snowflake 现有的治理原语——RBAC、row access policies（RAPs）和 session attributes——可以把 agent 限制在边界之内，让它在物理上无法看到访问者权限范围之外的数据。本文将介绍具体做法。

摘要

Snowflake Cortex Agents 会在一个 Snowflake session 中执行其生成的 SQL，因此，任何应用到该 session 的治理措施（user、role、RAPs、session attributes）都会自动应用到 agent 上；对于共享访问，使用 service user；对于按用户访问，通过 External OAuth 进行身份验证，让 agent 以访问用户的身份运行；对于按租户访问，可以选择三种模式之一——user-per-tenant、role-per-tenant，或 tenant session attribute——每种模式都能清晰映射到 Cortex Agent run API 的调用方式；关于表、RAPs 和 cURL 命令的完整示例设置，可以在这里"找到。

三种访问场景

大多数多租户应用都可以归入以下三类之一：

Shared——每个访问者看到相同的数据；Per-user——每个访问者都有自己的 Snowflake 身份和自己的数据范围；Per-tenant——访问者没有 Snowflake 身份，但每个人都属于某个租户（组织 / 团队 / 客户），并且访问权限必须限制在该租户的数据范围内。

传统应用会生成自己的 SQL，并可以在中间层强制执行作用域限制。一旦我们把 SQL 生成委托给 agent，这条退路就不存在了——治理必须在 Snowflake 内部强制执行。下面我们逐一介绍每种场景，包括当 Cortex Agents 进入这个流程后，具体会发生哪些变化。

场景一：共享访问（Service User）

这是最简单的情况。应用可以用自己喜欢的方式对访问者进行身份验证（例如使用自己的 IdP），只是为了确认他们被允许进入应用，然后以单一 service user 的身份连接到 Snowflake。标准 RBAC 和任何 RAPs 都会应用到该用户。

Cortex Agent：使用 service user 的凭据调用 run API。agent 会继承与 service user 完全相同的权限。不需要任何特殊处理。

场景二：Snowflake 中的按用户身份访问

每个访问者都有一个 Snowflake user，因此我们通过 IdP 对访问者进行身份验证，并使用一个 Snowflake 也接受的 token。Snowflake 支持多种 IdP 集成模式——SCIM（用于用户预配）、SAML（用于登录页面 SSO）和 External OAuth（用于基于 API token 的访问）。对于代表用户调用 Snowflake API 的应用来说，External OAuth 是合适的工具。

访问者完成身份验证后，应用会收到一个 OAuth token，其中的 claims 会映射到某个 Snowflake user。应用会把自己的 session ID 与这个 token 一起存储，并在每一次 Snowflake API 调用时——包括 Cortex Agent run——转发该 token。Snowflake 会验证 token，并以访问者用户的身份执行调用，同时受到该用户所适用的所有 RBAC 和 RAPs 约束。

Cortex Agent：使用访问者的 OAuth token 调用 run API。无需其他操作。

场景三：按租户访问（访问者没有 Snowflake 身份）

这是更有意思的情况。IdP 登录会给我们一个租户标识符——可能是一个 custom claim，也可能是根据约定推导出来的（例如 sub claim 中的邮箱域名）。应用会将每个访问者的 session 映射到该租户。现在的问题是：我们如何让 Snowflake——以及 Cortex Agent——按照该租户的范围来运行？

有三种模式。下面是一个快速对比：

Pattern A: User-per-Tenant

为每个租户创建一个 Snowflake user，并为每张多租户表应用一个以 CURRENT_USER() 为 key 的 RAP：

CREATE ROW ACCESS POLICY IF NOT EXISTS per_user_rap AS (key_column VARCHAR) RETURNS BOOLEAN -> key_column = CURRENT_USER();

你需要为每个租户管理凭据（轮换、secret-manager 存储、入驻 / 离开时创建和删除），应用也需要一种方式将租户映射到 Snowflake user——可以是映射表，也可以是类似 USER_ 的命名约定。

Cortex Agent：使用该租户 user 的凭据调用 run API。无需其他操作。

Pattern B: Role-per-Tenant

单个 service user 持有每个租户 role 的授权；你按请求切换 role。RAP 以 CURRENT_ROLE() 为 key：

CREATE ROW ACCESS POLICY IF NOT EXISTS per_user_rap AS (key_column VARCHAR) RETURNS BOOLEAN -> key_column = CURRENT_ROLE();

租户入驻时创建的是 role（不是 user），将该租户的数据访问权限授予它，并将该 role 授予 service user。你仍然需要一个租户到 Snowflake role 的映射。应用自己发出的 SQL 可以使用连接池——只需要在每次查询之前执行 USE ROLE。

Cortex Agent：在 run API 调用中，将 X-Snowflake-Role header 设置为租户 role。为了防止任何 fallback，需要将 service user 配置为没有默认 secondary roles，这样 agent 就没有其他可 fallback 的 role。

Pattern C: Tenant Session Attribute

完全不需要按租户创建 Snowflake 对象。单个 service user 可以访问所有租户的数据，我们通过设置 session attribute 来限定每个 session 的范围——这是一种新的 session variable，一旦在某个 session 中设置，就不能再更改。

使用 SET_SYS_CONTEXT() 并指定保留 namespace SNOWFLAKE$SESSION_ATTRIBUTES 来设置 session attribute，使其不可变。（任何其他 namespace——或 NULL——设置的都是普通的可变 session variable）。

SELECT SET_SYS_CONTEXT('SNOWFLAKE$SESSION_ATTRIBUTES', 'TENANT', 'ALICE');

RAP 通过 SYS_CONTEXT() 读取它：

CREATE ROW ACCESS POLICY IF NOT EXISTS sess_attr_rap AS (key_column VARCHAR) RETURNS BOOLEAN -> key_column = SYS_CONTEXT('SNOWFLAKE$SESSION_ATTRIBUTES', 'TENANT');

Cortex Agent：run API 的 payload 中接受一个 variables block，Snowflake 保证这些变量会在任何 agent 生成的 SQL 运行之前被设置到 session 上：

{ "variables": { "TENANT": { "value": "ALICE", "type": "string", "is_immutable_session_attribute": true } } }

is_immutable_session_attribute: true 这个 flag 至关重要。如果 agent 生成的 SQL 试图更改 TENANT——无论是意外、幻觉，还是 adversarial prompt 导致的——Snowflake 都会拒绝这次更改并抛出错误。RAP，以及你的租户边界，会在整个运行过程中保持完整。

将租户映射到数据值：Entitlement Tables

很多时候，租户标识符（user / role / attribute）与数据中存储的值并不匹配。例如，Hessco 这个租户可能拥有被标记为 hessco.com、hessco.co.uk 和 hessco.co.jp 的多行数据。entitlement table 可以弥合这个差距：

CREATE TABLE IF NOT EXISTS entitlement (tenant_id STRING, value STRING); -- e.g., ('Hessco', 'hessco.com'), ('Hessco', 'hessco.co.uk'), ('Hessco', 'hessco.co.jp')

一个 memoizable UDF 会在每个 session 中收集一次允许访问的值，这样我们就不需要为每一行都重新查询该表：

CREATE FUNCTION IF NOT EXISTS allowed_values() RETURNS ARRAY MEMOIZABLE AS 'SELECT ARRAY_AGG(value) FROM entitlement';

数据表上的 RAP 会测试 array membership，而不是做相等判断：

CREATE ROW ACCESS POLICY IF NOT EXISTS entitlement_rap AS (key_column VARCHAR) RETURNS BOOLEAN -> ARRAY_CONTAINS(key_column::VARIANT, allowed_values());

最后，在 entitlement table 本身也加上一个 RAP，确保每个 session 只能看到自己的映射关系。predicate 会匹配你选择的租户模式——以下是 role-per-tenant 的例子：

CREATE ROW ACCESS POLICY IF NOT EXISTS entitlement_by_role_rap AS (tenant_id VARCHAR) RETURNS BOOLEAN -> tenant_id = CURRENT_ROLE(); ALTER TABLE entitlement ADD ROW ACCESS POLICY entitlement_by_role_rap ON (tenant_id);

对于 user-per-tenant，将 predicate 替换为 tenant_id = CURRENT_USER()；对于 session-attribute 模式，则使用 tenant_id = SYS_CONTEXT('SNOWFLAKE$SESSION_ATTRIBUTES', 'TENANT')。

连接池 + Session Attributes：一种混合模式

Pattern C（session attributes）有一个小问题。那些也会发出自己 SQL 的应用——比如内置 dashboard——通常会使用连接池：一个长期存在的 service-user session 会被多个访问者复用。但 session attributes 是不可变的，因此一个被固定到租户 ALICE 的 session 永远不能再被租户 BOB 复用。这会破坏连接池机制。

对于应用自己发出的 SQL，理想情况下你会使用一个可变的 session variable。对于 Cortex Agent 调用，你需要一个不可变的 session attribute，因为 agent 可能会尝试更改任何可变内容。

解决方法是编写一个 RAP，让它同时接受两种形式，并在不可变 attribute 存在时优先使用它：

CREATE ROW ACCESS POLICY IF NOT EXISTS sess_attr_or_var_rap AS (key_column VARCHAR) RETURNS BOOLEAN -> key_column = COALESCE( SYS_CONTEXT('SNOWFLAKE$SESSION_ATTRIBUTES', 'TENANT'), SYS_CONTEXT(NULL, 'TENANT') );

应用自己发出的 SQL（使用连接池）：在每次查询开始时，设置可变 session variable：SELECT SET_SYS_CONTEXT(NULL, 'TENANT', '')。不要设置 session attribute。

Cortex Agent 调用：通过在 variables block 中包含 is_immutable_session_attribute: true 来设置 session attribute。

无论哪种方式，RAP 都会获取到正确的值——而 agent 的查询会受到不可变形式的保护。

总结

为 AI 驱动的应用定制数据访问，是“与数据对话”从 demo 走向产品的关键差异。Snowflake 现有的治理原语——RBAC、row access policies 和 immutable session attributes——提供了你所需的一切能力，让你可以放心地让 Cortex Agents 处理多租户数据，而不会破坏租户边界。选择适合你隔离模型的模式，将其接入 Cortex Agent run API，然后让 agent 负责写 SQL，由 Snowflake 负责执行规则。

如果你想查看一个设置 data、agents、roles 等内容并提供示例 cURL 命令的示例，可以查看这个 Snowflake Notebook。

原文地址：https://medium.com/snowflake/dont-trust-the-llm-with-tenant-isolation-multitenant-cortex-agents-on-snowflake-51267ff08bb8"

点击链接立即报名注册：Ascent - Snowflake Platform Training - China"，更多 Snowflake 精彩活动请关注专区"。

AI 正在向软件生命周期的上游延伸：从代码审查到产品需求文档（PRD）治理

作者：Leela Kumili — Tue, 30 Jun 2026 01:00:00 GMT

大型科技公司正在将 AI 的应用范围从代码生成和代码审查扩展到软件开发生命周期的更早期阶段，包括产品需求验证和系统设计输入。Uber、DoorDash 和 Cloudflare 最近采取的举措表明，行业正朝着将 AI 作为治理层的方向转变，从而在实施前及审核期间对工程成果进行评估和优化。

Uber 引入了产品需求文档（PRD）“首轮审核”机制"，要求在产品需求文档提交给工程团队之前，先由 AI 系统进行审核。该系统会对早期阶段的规格说明书进行评估，重点考察其清晰度、完整性以及潜在的实施风险。

以下是 Uber 针对该举措发布的工程评论"：

这真是 AI 产品经理的一个绝佳应用场景！大多数人认为其价值在于和你共同起草产品需求文档（PRD），但它更大的价值在于提供恰当的背景信息，帮助你深入思考问题，并引入你可能甚至不知道的相关公司级资源和项目。

该方法将 AI 定位为产品文档的结构化审查机制，而非编码助手。在 Uber 的工作流程中，AI 在需求阶段的早期就被引入，用于在设计和实现之前发现缺失的依赖关系、不一致之处以及不明确的假设。工程师保留最终验证权，而 AI 系统则作为产品需求文档（PRD）的初步筛选层。

DoorDash 也采取了类似的做法，开发了一款基于 AI 的内部代码审查工具"，旨在提供反馈，使工程师主动将其融入工作流程。该系统侧重于生成可操作且与上下文相关的建议，而非泛泛的自动化评论。在对该系统的评论中，DoorDash 工程师指出"：

他们团队设计这个系统的初衷是赢得信任，而不是制造噪音：减少评论数量，只提供更有价值的反馈，并在代码发布前落实真实的改进行为。

该设计将 AI 生成的洞察直接整合到了现有的开发工作流中，在标准审查流程中直接呈现反馈，而非作为独立的工具存在。这种方法可以保证工程判断仍然是最终的决策点，减少了审查延迟，提高了吞吐量，同时又可以避免给工程师造成低信噪比的干扰。

Cloudflare 还描述了一种基于多代理的 AI 辅助代码审查方法"，其中不同的 AI 组件被分配了专门的职责，例如安全分析、性能评估和正确性检查。这种分解方式遵循分布式系统原则，将关注点分散到多个代理，然后通过协调层聚合输出结果。

Cloudflare 工程团队指出：

当明确界定了每个专职审核员的职责范围时，它们的表现优于单一的通用审核员。

Cloudflare 还强调，该系统在标记内容时必须精准。为了提供高信噪比的代码审查信息，并减少开发者工作流中的噪音，定义“不需要显示的内容”与定义“需要检测的内容”同样重要。

在这些实施方案中，作为为人工审核员提供支持的首轮评估层，AI 贯穿了从需求定义到实现的软件生命周期的各个阶段。它在产品需求文档（PRD）、设计和代码审查阶段引入了结构化的检查点，在保留人工监督的同时增加了自动化分析。这反映了软件工件全生命周期持续验证这一新兴的模式。

原文链接：https://www.infoq.com/news/2026/06/ai-prd-code-review-governance/"

超越 CLEAN 和 MVP：在 Android 中构建离线优先的响应式数据层

作者：Mervyn Anthony — Mon, 29 Jun 2026 10:44:00 GMT

前言

移动应用程序运行在高度不可预测的环境中。用户期望应用程序能够瞬间加载、支持离线使用、实时更新，并且能在蜂窝网络连接时断时续的情况下完整地保存数据。

虽然 Model-View-Presenter（MVP）和 CLEAN 架构等模式为关注点分离提供了可靠的起点，但在应用于移动平台独特且具有响应性的需求时，它们往往力不从心，甚至还会引入不必要的模板代码。

本文介绍了响应式数据层架构（RDLA）——一种专门针对移动端优化过的模式，专门设计用于弥合响应式 UI 框架（如 Jetpack Compose）与受限的移动存储之间的差距。通过协调这两个边界，RDLA 使开发者能够构建健壮、以离线优先为原则的响应式数据层。

RDLA 对于任何需要实时 UI 更新和离线支持的应用程序都有益处，但在与联网硬件或易变数据源进行交互时，它变得更为关键。例如，在消费级医疗物联网和可穿戴设备领域（如双节点睡眠监测可穿戴设备或自适应助听器），应用程序需要绝对的可靠性和同步性。

与基于稳定网络协议的传统 REST API 架构不同，移动数据获取通常需要处理硬件 API（如蓝牙低功耗），而这些 API 依赖于在 Binder 线程间执行的深度嵌套、异步回调。如果没有可靠的架构来序列化操作，并将本地缓存视为唯一的权威数据源，那么这些系统很快就会陷入状态同步错误和连接不稳定的困境。例如，基于 BLE 设备的应用会触发臭名昭著的“ GATT 竞争条件"”，导致底层蓝牙控制器乱序处理命令或完全丢弃命令（这通常会导致文档记录不详的 GATT 错误代码 Status 133 或 129）。

为了应对这些挑战，RDLA 将本地缓存视为确定性的 UI 缓冲区，同时利用 Kotlin 协程和 suspendCancellableCoroutine 桥接器来串行化物理硬件操作，从而将混乱的多线程异步事件转化为确定性的同步数据流。

借鉴为高度受监管的消费级医疗设备开发的架构模式，我们将通过一个健康指标追踪系统（专用于追踪心率记录）来探讨 RDLA 的拓扑结构，将其与传统模式进行对比，并演示其在 Kotlin 中的实现。

传统模式的局限性

在深入探讨 RDLA 之前，让我们先分析一下为什么传统模式在现代 Android 开发中会显得力不从心。

1. MVP 架构的拉取瓶颈

在经典的 Model-View-Presenter (MVP)" 架构中，通信是过程式的，而且基于拉取：

Presenter 向模型请求数据。Model 获取数据并通过回调将其返回。Presenter 将数据推送给 View。

这种机制在比较简单的应用程序中是可行的，但在响应式编程"环境中却行不通。如果后台同步进程更新了数据库，除非 Presenter 轮询数据库或依赖复杂的事件总线，否则它将无法感知到这一变化。MVP 缺乏一种原生的机制自动地将状态变化向下游传播。

2. CLEAN 架构在移动端的错位

CLEAN 架构"在保持业务逻辑与框架独立性方面表现出色。然而，如果在移动开发中未经修改地直接应用该架构，则会带来两个明显的挑战：

冗余代码负担（透传用例）：对于简单的读取操作，经典的 CLEAN 架构迫使开发者创建一个仅调用 Repository 方法的用例类。在拥有数十张表的数据库密集型应用中，这将导致大量琐碎的“透传”类，增加了维护负担，却未带来任何业务价值。平台无关性与移动端现实：在设计上，CLEAN 旨在实现数据库和框架的无关性。虽然这在企业后端系统中效果良好，但无法解决移动端特有的限制。它没有处理本地-远程数据同步、离线状态传播或 SQLite 性能限制（如数据库编译边界）方面的指导。

RDLA 简介

响应式数据层架构（RDLA）是一种专门设计的模式，用于弥合响应式 UI 框架（如 Jetpack Compose）与移动端存储限制之间的差距。

RDLA 严格区分数据定义（API）与数据获取（实现），并遵循三大核心原则：

基于响应式推送的数据流：UI 绝不会用“一次性”的方式查询数据。相反，它会订阅数据的“冷流”（Flow）。本地缓存作为唯一数据源：UI 仅从本地数据库读取数据。网络仅用于填充该数据库。封装缓存与同步：检查缓存过期、合并本地编辑以及触发后台数据获取的逻辑完全封装在 Repository 实现中。

架构拓扑

RDLA 将数据包划分为三个独立的模块：API、实现和数据库（共享存储）。

图1：RDLA 架构拓扑与模块边界（图片由作者制作）

RDLA 在架构生态中的定位：与 Clean 和 MVVM 相融合

RDLA 并非 MVVM 或 Clean 架构的替代方案。相反，它是一种移动端优先的数据层（及部分领域层）实现方式，能够与上述架构模式无缝集成。通过优化这些模式之间的接口，它有效地解决了移动端特有的常见痛点。

RDLA 如何与 Clean 架构融合

Clean 架构的核心在于依赖规则：代码依赖关系必须仅向内指向核心业务逻辑（实体和用例）。RDLA 严格遵守这一规则，并针对移动端的限制条件优化了实现：

图2：RDLA 模块与 Clean 架构各层的映射关系（图片由作者制作）

API 模块（实体）：RDLA 的 API 模块直接对应于 Clean 架构最内层的实体层。它仅包含纯 Kotlin 数据模型（如 HeartRateRecord）和 Repository 接口。该模块完全不依赖于任何平台、数据库或网络。存储库实现（用例）：在经典的 Clean 实现中，开发人员通常会针对每次数据库读取编写一个用例类（例如 GetHeartRateRecordsUseCase）。RDLA 允许表示层直接查看存储库的响应流，在简单 CRUD 操作中消除了这类冗余代码。然而，对于跨多个领域的复杂业务逻辑（例如，根据睡眠和心电记录计算心率变异性），则仍然需要创建一个依赖于 RDLA Repository API 的标准 Clean 用例类。数据源接口（接口适配器）：私有接口 LocalDataSource 和 RemoteDataSource 位于实现模块中，作为边界（Clean 架构中的接口适配器）将存储库与具体的数据库和网络引擎隔离开来。Room DB 与 Retrofit 客户端（框架与驱动程序）：具体实现（RoomLocalDataSource、RetrofitRemoteDataSource）位于独立的数据库和网络模块中。框架细节（如 Room 注解或序列化库）完全封装在这个外部边界内。

RDLA 如何驱动 MVVM（单向数据流）

在传统的 MVVM 架构中，ViewModel 通常充当主动管理者的角色，从存储库中提取数据并管理其生命周期。这种采用命令式管理的数据流容易引发同步错误。

RDLA 通过将 Model 转换为响应式数据总线改变了这一状况，实现了严格的单向数据流（UDF）：

图3：RDLA 中的单向数据流（UDF）响应循环（图片由作者制作）

ViewModel 作为转换器而非同步器：与通过启动协程按需获取数据并手动更新状态存储器不同，RDLA 中的 ViewModel 是一个被动的转换器。它监听存储库的 Flow，并使用 stateIn 运算符将其直接转换为 UI 可用的 StateFlow。自动 UI 同步：当后台同步工作线程或离线修改操作更新 Room 数据库时，数据库会自动发布新的数据集。这一变化会通过存储库和 ViewModel 直接传播给 UI，不需要 ViewModel 轮询或协调刷新操作。清晰的状态分离：RDLA 允许 ViewModel 将持久状态（通过由 Room 支持的 StateFlow 处理）与瞬态事件（通过 SharedFlow 处理，用于连接中断或错误等一次性通知）清晰地分离。

RDLA 实践：健康指标追踪系统

为了说明这种架构，我们将构建一个跟踪心率指标的数据层。

1. API 模块（公共）

API 模块是 UI 层唯一能访问的包。它包含纯领域模型和存储库接口。

领域模型（HeartRateRecord.kt）

这是一个标准的 Kotlin 数据类，没有数据库或序列化注解。

package com.example.healthtracker.data.heartrate.api.model import java.time.Instant data class HeartRateRecord( val id: String, val bpm: Int, val timestamp: Instant )

Repository 接口（HeartRateRepository.kt）

该接口定义了公共合约，提供了冷流。

package com.example.healthtracker.data.heartrate.api import com.example.healthtracker.data.heartrate.api.model.HeartRateRecord import kotlinx.coroutines.flow.Flow import java.time.Instant interface HeartRateRepository { /** * 返回一个包含心率记录的响应式数据流。 * 如果本地缓存已过期，则在后台触发网络刷新。 */ fun observeHeartRates(start: Instant, end: Instant): Flow> /** * 上传新的心率记录。在服务器确认之前暂停操作。 */ suspend fun upsertHeartRates(records: List) }

2. 实现模块（私有）

为了防止泄露，实现模块中的所有内容均被标记为 internal。UI 层绝不能直接访问这些类。

缓存封装器（Cached.kt）

为了管理缓存过期而又不向领域模型中引入元数据，我们在实现层中将模型封装在 Cached 容器中：

package com.example.healthtracker.data.core.caching import java.time.Instant data class Cached( val value: T, val insertionTime: Instant )

Repository 协调器（HeartRateFetchAndStoreRepository.kt）

该类负责协调本地和远程数据源。它会检查缓存过期情况，并触发后台数据获取。

package com.example.healthtracker.data.heartrate.impl import com.example.healthtracker.data.heartrate.api.HeartRateRepository import com.example.healthtracker.data.heartrate.api.model.HeartRateRecord import com.example.healthtracker.data.heartrate.impl.local.HeartRateLocalDataSource import com.example.healthtracker.data.heartrate.impl.remote.HeartRateRemoteDataSource import com.example.healthtracker.data.core.caching.Cached import kotlinx.coroutines.CoroutineScope import kotlinx.coroutines.flow.Flow import kotlinx.coroutines.flow.flowOn import kotlinx.coroutines.flow.map import kotlinx.coroutines.flow.onStart import kotlinx.coroutines.launch import java.time.Duration import java.time.Instant import kotlin.coroutines.CoroutineContext internal class HeartRateFetchAndStoreRepository( private val localDS: HeartRateLocalDataSource, private val remoteDS: HeartRateRemoteDataSource, private val appScope: CoroutineScope, private val lightweightContext: CoroutineContext, private val cacheTtl: Duration = Duration.ofMinutes(10) ) : HeartRateRepository { override fun observeHeartRates(start: Instant, end: Instant): Flow> { return localDS.readHeartRates(start, end) .onStart { // 异步后台刷新执行 appScope.launch { triggerRefreshIfNeeded(start, end) } } .map { cachedList -> cachedList.map { it.value } } .flowOn(lightweightContext) } private suspend fun triggerRefreshIfNeeded(start: Instant, end: Instant) { val cachedData = localDS.readHeartRatesOnce(start, end) if (cachedData.isEmpty() || isStale(cachedData)) { try { val remoteData = remoteDS.fetchHeartRates(start, end) localDS.writeHeartRates(remoteData) } catch (e: Exception) { // 静默失败；UI 继续显示 cachedData } } } private fun isStale(data: List>): Boolean { val oldestAllowed = Instant.now().minus(cacheTtl) return data.any { it.insertionTime.isBefore(oldestAllowed) } } override suspend fun upsertHeartRates(records: List) { // 同步更新：在更新数据库之前，服务器的写入操作必须成功 val serverConfirmed = remoteDS.uploadHeartRates(records) localDS.writeHeartRates(serverConfirmed) } }

请注意，通过在应用程序作用域 CoroutineScope（appScope）中调用 triggerRefreshIfNeeded，即使用户退出当前屏幕（这会导致 ViewModel 的作用域被取消），也能确保数据库更新成功完成。

3. 存储层模块（Room）

在实际的移动应用中，相关功能通常共享一个数据库。RDLA 引入了事务组来处理这种情况。例如，心率和血压数据被归入“心血管事务组”，共享一个 Room 数据库实例。

图4：Cardio 事务组下的 Room 本地存储模块包的层次结构（图片由作者制作）

本地数据源接口（HeartRateLocalDataSource.kt）

interface HeartRateLocalDataSource { fun readHeartRates(start: Instant, end: Instant): Flow>> suspend fun readHeartRatesOnce(start: Instant, end: Instant): List> suspend fun writeHeartRates(records: List) } The Database Entity (HeartRateEntity.kt) @Entity(tableName = "heart_rate_records") data class HeartRateEntity( @PrimaryKey val id: String, val bpm: Int, val timestamp: Instant, val insertionTime: Instant ) { fun toModel() = HeartRateRecord(id = id, bpm = bpm, timestamp = timestamp) }

Room 实现（HeartRateRoomDataSource.kt）

internal class HeartRateRoomDataSource( private val dao: HeartRateDao, private val lightweightContext: CoroutineContext ) : HeartRateLocalDataSource { override fun readHeartRates(start: Instant, end: Instant): Flow>> { return dao.observeHeartRates(start, end) .distinctUntilChanged() // 防止 Room 发出冗余数据 .map { entities -> entities.map { Cached(it.toModel(), it.insertionTime) } } .flowOn(lightweightContext) } override suspend fun readHeartRatesOnce(start: Instant, end: Instant): List> { return dao.getHeartRates(start, end).map { Cached(it.toModel(), it.insertionTime) } } override suspend fun writeHeartRates(records: List) { val entities = records.map { HeartRateEntity(it.id, it.bpm, it.timestamp, Instant.now()) } dao.insertOrUpdate(entities) } }

提示：我们将 distinctUntilChanged() 应用于 Room 数据流。由于 Room 会触发表级观察，所以对表的任何更新都会触发数据发布，即使所查询的子集未发生变化也是如此。distinctUntilChanged() 可以过滤掉这些冗余的事件。

4. UI 层（组合）消费

响应式数据层的强大程度取决于调用它的表示层的性能。为了有效连接 RDLA 与 Jetpack Compose，UI 层利用 StateFlow 将底层数据流聚合为统一的状态表示。这可以确保无论应用程序的生命周期如何变化，UI 都能准确地反映持久状态（如“已连接”、“正在扫描”或“已断开连接”）。相反，瞬态事件（例如局部同步回滚或 BLE 连接中断）会绕过永久状态。这些事件通过一个带有重放缓存且高度可配置的 SharedFlow 推送至 UI，从而可以确保即使在设备旋转导致 UI 暂时销毁的情况下，关键的一次性警报也能被保留并即时发送。

@HiltViewModel class HeartRateViewModel @Inject constructor( private val repository: HeartRateRepository ) : ViewModel() { // 持久状态流 val uiState: StateFlow = repository .observeHeartRates(Instant.now().minus(1, ChronoUnit.DAYS), Instant.now()) .map { records -> UiState.Success(records) } .stateIn( scope = viewModelScope, started = SharingStarted.WhileSubscribed(5000), initialValue = UiState.Loading ) // 瞬态事件流 private val _faultEvents = MutableSharedFlow( replay = 1, onBufferOverflow = BufferOverflow.DROP_OLDEST ) val faultEvents = _faultEvents.asSharedFlow() }

通过将用于处理持续状态的 StateFlow 与用于处理易失性硬件事件的 SharedFlow 无缝集成，ViewModel 为 Compose 提供了一座坚不可摧的响应式数据桥，确保 UI 绝不会显示过时或异常状态。

设计离线突变

变异是指由用户发起的更新操作。根据用户体验的要求，变异操作可以采用同步或异步方式处理。

1. 同步变异

同步变异要求用户处于在线状态。如果网络请求失败，则本地数据库将保持不变，并立即向用户显示错误提示（如尝试删除医疗日志）。

2. 异步变异（离线优先）

对于标准日志（如运动期间记录的心率 BPM），写入操作必须立即成功，即使在离线状态下也是如此。为实现这一点，变异会被写入本地数据库队列，实时合并到活跃的用户界面数据流中，并在后台进行同步。

图5：异步突变同步管道与操作系统后台委托（图片由作者制作）

在本地数据源中实现突变合并

override fun readHeartRates(start: Instant, end: Instant): Flow>> { val savedRecordsFlow = dao.observeHeartRates(start, end) val pendingMutationsFlow = mutationDao.observePendingAddMutations() return savedRecordsFlow.combine(pendingMutationsFlow) { saved, mutations -> val mergedList = saved.map { Cached(it.toModel(), it.insertionTime) }.toMutableList() mutations.forEach { mutation -> if (mutation.timestamp in start..end) { // 将本地待处理的突变叠加到列表上方 mergedList.removeAll { it.value.id == mutation.localId } mergedList.add( Cached( value = HeartRateRecord(mutation.localId, mutation.bpm, mutation.timestamp), insertionTime = mutation.localCreationTime ) ) } } mergedList.sortedByDescending { it.value.timestamp } }.flowOn(lightweightContext) }

RDLA 将后台执行职责明确地分配给 appScope 协程和 Android Jetpack WorkManager。对于即时同步的数据处理（例如将收到的健康指标保存到 Room 数据库），该架构会在应用程序作用域的 CoroutineContext 中启动协程。这样可以保证，即使用户迅速跳转到了其他界面并取消了当前的 ViewModel 作用域，轻量级的本地数据库写入操作也能成功完成。

然而，对于连接本地数据库与远程云端的异步数据更新（或通过 BLE 推送数兆字节的 OTA 固件负载），appScope 就不够用了。Android 激进的电源管理功能（Doze 模式）和进程终止机制可能会在操作进行过程中终止应用程序。对于受 FDA 监管的健康指标，数据丢失是绝对不可接受的。通过 WorkManager 将异步数据更新加入队列，并将同步请求直接委托给操作系统服务。这样可以保证关键数据包同步在满足严格系统约束（例如要求使用不限流量的 Wi-Fi 或充足的电量）的情况下执行，并且如果连接中断，也能可靠地从最后已知的内存偏移量处精确恢复。

后台同步通过 Android WorkManager 进行管理，使用由 Hilt 注入的 CoroutineWorker"。通过将网络调用的限制与 UI 解耦，即使用户关闭了应用，也能确保请求成功。

冲突解决与回滚

虽然乐观的本地更新能提供无缝的用户体验，但本质上容易引发冲突。当 WorkManager 同步工作进程尝试将本地变更队列上传至服务器时，总是存在被远程拒绝的风险。例如，如果该记录被另一台已授权的设备并发修改，就可能返回 HTTP 409 冲突错误；或者如果数据未能通过临床验证，就可能返回 422 Unprocessable Entity 的错误。

在 RDLA 中，架构必须能够优雅地处理这些回滚操作，而且要确保不破坏本地“单一可信数据源”。当远程 API 抛出 HTTP 异常时，工作线程会捕获该故障，并将 Room 中的本地变异实体标记为 FAILED，而不是触发无限重试循环。

中央存储库会监控同步过程的状态，并通过 SharedFlow 将这个故障状态作为瞬态事件发送至 UI 层。与此同时，本地数据源会执行一项数据库事务，将队列中被拒绝的变更操作清除。由于 UI 层是以响应式方式收集合并后的数据流，清除待处理的变更操作会迫使 Room 触发新的数据发布。distinctUntilChanged() 过滤器会传递这个更新后的状态，而 UI 会立即自动回滚到最后一个经服务器确认的已知状态。

为什么 RDLA 让测试变得轻而易举

RDLA 最大的优势之一在于它简化了单元测试。通过将 Room 数据库和 Retrofit 网络配置进行隔离，你可以直接测试存储库逻辑。

TestExtensions 模式

由于存储库接口不应该向客户端暴露数据插入的方法（为了防止用户界面直接修改同步状态），所以我们在 API 目标中引入了一个 testonly 接口：

图 6：TestExtensions 的初始化模式与作用域边界分离（图片由作者制作）

1. 定义 Test Extensions 接口（位于 API 模块中）

@VisibleForTesting interface HeartRateRepositoryTestExtensions { suspend fun seedLocalHeartRates(records: List) suspend fun clearLocalCache() }

2. 在 Repository 中实现接口（位于 Impl 接口中）

internal class HeartRateFetchAndStoreRepository( private val localDS: HeartRateLocalDataSource, // ... ) : HeartRateRepository, HeartRateRepositoryTestExtensions { // Repository 实现... override suspend fun seedLocalHeartRates(records: List) { localDS.writeHeartRates(records) } override suspend fun clearLocalCache() { localDS.clearAll() } }

3. 编写一个松耦合的单元测试（使用 Robolectric ）

@HiltAndroidTest @RunWith(AndroidJUnit4::class) @Config(application = HiltTestApplication::class) class HeartRateRepositoryTest { @get:Rule val hiltRule = HiltAndroidRule(this) @Inject lateinit var repository: HeartRateRepository @Inject lateinit var testExtensions: HeartRateRepositoryTestExtensions @Before fun setUp() { hiltRule.inject() } @Test fun observeHeartRates_emitsSeededData() = runTest { val now = Instant.now() val records = listOf(HeartRateRecord("1", 72, now)) // 通过测试扩展直接向数据库插入数据 testExtensions.seedLocalHeartRates(records) val flow = repository.observeHeartRates(now.minusSeconds(60), now.plusSeconds(60)) assertThat(flow.first()).containsExactlyElementsIn(records) } }

核心测试优势

无需模拟 SQLite：结合 Robolectric 和真实的 Room 数据库，可以确保在测试时对 SQL 查询进行全面验证。强大的离线验证：通过注入 FakeHeartRateRemoteDataSource，可以模拟网络故障，并验证存储库的备用逻辑能否优雅地处理离线状态。解耦数据库重构：如果你重构了 SQLite 模式（例如添加数据库字段），但只要本地数据源中的映射逻辑能正确地将数据库实体转换为领域模型，你的存储库测试就不会失败。

小结

要构建一个以离线优先为原则的响应式 Android 应用程序，需要设计一个专为响应式应用而打造的数据层。通过应用响应式数据层架构（RDLA），你可以在公共数据 API 契约与特定于框架的私有数据源实现之间建立清晰的边界。这样，你的表示层（ViewModels/Presenters）将以纯粹的响应式方式运行，通过监听数据变化而非通过过程化的方式查询数据。此外，为了简化测试工作，RDLA 鼓励开发人员基于接口进行编程并利用 TestExtensions 等简洁的初始化模式。

归根结底，向 RDLA 过渡能为你的代码库提供一种可以干净利落地进行扩展的结构，让你可以从容地应对同步挑战，并支持现代用户所期待的、离线优先的丰富体验。

原文链接：https://www.infoq.com/articles/rdla-offline-first-reactive-android-data-layer/"

物理 AI 如何定义下一代平台革新？

Arm 社区 — Mon, 29 Jun 2026 10:29:08 GMT

人工智能 (AI) 的下一波浪潮正迈向物理世界，并深度融入汽车、机器人及其他自主设备之中。据麦肯锡（McKinsey）预测，到 2030 年，仅在美国市场，由 AI 驱动的智能体和机器人就有望释放每年约 2.9 万亿美元的经济价值。

随着各类设备从执行单一任务、预编程的控制设备，向具备自适应能力的 AI 驱动系统演进，计算性能的评判标准将取决于这些系统能否实现以下能力：

在严苛的功耗限制下运行；提供确定性响应时延；符合功能安全标准；提供稳健可靠的安全性；在漫长的产品生命周期内保持可靠性。

这意味着，计算平台从设计之初，就必须围绕性能、能效、可预测性、功能安全与信息安全进行构建。数十年来，这些原则始终是 Arm 计算平台的核心。如今，随着 AI 加速落地至能够感知、推理、认知并执行的各类设备，这些原则正趋于融合。

这一趋势正推动着物理 AI 的发展。

什么是物理 AI？

物理 AI 是专为应对多变、不可预测且安全关键型场景而设计的智能系统。这类系统可实现道路行驶、物料搬运、基础设施巡检、零部件装配及车队协同，所有操作均直接在物理世界中完成。

本质上，物理 AI 是将智能嵌入设备之中，打破模型、软件栈与硬件架构之间的界限。传感器持续产生的数据流经 AI 模型处理并生成决策，由控制系统实时执行，再将结果反馈至系统，形成从感知到行动的完整闭环。

物理 AI 的应用领域涵盖自动驾驶汽车、先进机器人、无人机及智能工业系统。这些应用场景的共性在于它们对计算能力提出了严苛要求，需在有限功耗与安全边界内，协同完成感知、推理与控制全过程。

生成式 AI 输出文本、图像、代码等数字内容，通常运行于软件环境中，其性能主要以模型的精度或创造力为性能衡量标准。与之相比，物理 AI 运行在动态的真实场景中，实时决策会立即转化为物理运动。

在这一背景下，任何计算误差都可能影响系统的安全性、可靠性与运行连续性，这也决定了物理 AI 系统的构建、验证与部署方式。

为何物理 AI 意味着平台革新？

物理 AI 正处于一个与智能手机发展初期相似的行业转折点。在智能手机成为真正的平台级产品时，那是算力、互联功能与开发者生态发生深度融合的时刻，从而催生了全新的产业与服务。

如今，汽车、机器人及其他自主设备领域也在经历类似的生态融合，整个生态致力于释放数万亿美元规模的物理 AI 经济价值。当前的环境不仅 AI 算法已日趋成熟，传感器与执行器也日益普及，模型训练基础设施亦持续扩展。

然而，要使物理 AI 真正实现规模化，离不开坚实的计算底座 —— 它既能支撑并协同云端训练、边缘推理与设备端实时执行等多类工作负载，又能在硬件迭代过程中保持软件的连续性。

这正是物理 AI 代表平台革新的原因。它的定义并非依托某款设备或某种部署方式，而是源于底层计算架构，让全品类智能机器实现长期、稳定的演进与规模化发展。

Arm 计算平台正位于这场融合的核心。从边缘控制器到高性能自主化系统，Arm 技术已成为当前众多智能基础设施的基石。随着 AI 融入更多设备，Arm 在移动与汽车领域保持领先的核心优势 —— 高性能与高能效兼备、高可扩展性与广泛的生态，为物理 AI 实现全球规模化提供了不可或缺的技术连续性。

Arm 如何落地物理 AI 实践？

当前，物理 AI 已深度融入量产级自主化平台的工程实践。Arm 计算平台为汽车、工业机器人及边缘系统提供核心智能算力，已成为众多自主系统广泛采用的计算基石。

Arm 核心驱动了 Rivian 第三代自主化计算平台，其 Rivian Autonomy Processor (RAP1) 为平台垂直整合的感知、规划与控制全栈提供算力支撑。依托 Armv9 架构，Rivian 实现了 AI 推理与车辆控制系统的深度耦合，可在整车架构中实现实时传感器融合、预测式决策以及线控执行的协同操作。

Tensor 的 L4 级代理式 AI (Agentic AI) 自动驾驶平台，同样也采用了 Arm 计算平台为核心，将智能分布到整车系统。每台自动驾驶车辆集成了超过 400 个基于 Arm 架构的计算核心，包括面向高吞吐自主化工作负载的 Arm Neoverse AE 系列 CPU、负责通用计算与冗余保障的 Cortex-X 系列 CPU、执行实时安全关键控制的 Cortex-R 系列 CPU，以及管理低功耗子系统的 Cortex-M 系列 CPU。

这两个案例展示了 Arm 架构的异构计算能力：感知、规划、控制、安全监控与系统管理不再各自为战，而是作为一个统一系统协同运转。高性能 AI 处理可与确定性安全系统并行运作，同时，高能效核心负责分布式感知与协同调度任务。这种平衡的方法使得计算能力得以扩展，而无需在热设计限制、安全完整性或架构一致性上作出任何牺牲。

软件适配性与生态连续性

随着物理 AI 系统从原型迈向规模化，软件适配性与计算能力变得同等重要。汽车行业为这一趋势提供了实践参考。如今，包括特斯拉、Rivian、蔚来、吉利等在内的几乎所有主流车企，均以 Arm 技术作为核心计算平台，基于 Arm 技术打造先进驾驶辅助系统 (ADAS)、沉浸式座舱等车载应用，并通过无线更新 (OTA) 实现长达数年的持续迭代。机器人及其他自主化设备，同样对软件的持续升级有着类似需求。

以部署在物流或制造场景中的机器人为例，其使用寿命可达十年，但其感知模型与自主决策策略需要频繁更新。这些持续升级必须在不干扰实时控制领域的前提下进行，同时无需在每次软件发布时都重新进行全系统验证。

Arm 在汽车领域深耕数十年，积累了支持混合关键任务工作负载的丰富经验。在这一领域，AI 与通过安全认证的中间件需在同一平台上并行运行。凭借这些宝贵经验，Arm 自然而然地具备了支撑下一代物理 AI 系统的能力。此前在汽车中应用的架构理念，如今也可推广至机器人及其他自主化设备，在实现软件持续升级的同时，保障系统行为稳定与安全完整性。

云端、边缘侧与物理 AI 的融合

AI 模型通常在大规模云端环境中完成训练，经仿真优化迭代后，部署至汽车、机器人、工业系统等需即时决策的场景。

物理 AI 系统在真实环境运行时，产生的数据与运行反馈会回传至云端，用于模型持续优化。长此以往，训练、部署与优化形成持续闭环。

这一过程让云端、边缘侧与物理 AI 系统的边界日趋模糊。计算不再针对训练、推理、实时执行等环节单独设计，而需在所有环境中无缝协同，并在系统规模化演进过程中保持可移植性。

Arm 计算平台已覆盖全计算链路，从云端大规模服务器、边缘设备到嵌入式控制器，均能提供支撑。这种架构一致性让开发者可基于统一技术基础开展研发，更便捷地迁移工作负载、复用软件，实现智能能力高效规模化。

随着物理 AI 的成熟，统一云端、边缘侧与物理环境的能力，已与原始性能、能效同等重要。能够成功落地的系统，必将依托可无缝连接各技术层级的架构打造而成。

智能系统的全新篇章

伴随汽车、机器人与工业平台的不断演进，行业关注的核心问题已不再是“AI 是否会融入其中”，而是“如何设计物理 AI 系统，使其更智能、更协同地实现长期规模化发展”。定义这个时代的标志，将不再是某一款突破性的单一设备，而是那些能让智能在不同领域间迁移，同时不丧失稳定性、可移植性与可信性的计算平台。

Arm 通过提供跨行业、跨性能层级的统一计算架构，让整个生态能够专注于 AI 能力的持续升级，无需在系统每次扩展时都重新构建底层基础。

物理 AI 并非遥远的愿景，它是机器在现实世界中设计、部署与获得信任的全新篇章。当下的计算架构选择，将决定未来智能在安全性、效率与全球规模化方面的发展，而 Arm 正在为这一未来奠定基础。

参考链接

https://www.mckinsey.com/mgi/our-research/agents-robots-and-us-skill-partnerships-in-the-age-of-ai"

分库分表后查询变慢？TDSQL 全局索引破解数据定位难题

凌敏 — Mon, 29 Jun 2026 10:07:13 GMT

分库分表后查询变慢？TDSQL 全局索引破解数据定位难题。

扫码添加企微小助手，一键加入开发者专属企微群，即可免费获取讲师 PPT，助力学习高效进阶！

AI 时代的新可观测性：不只看系统崩没崩，还要看模型有没有胡说

傅宇琪,Tina — Mon, 29 Jun 2026 10:06:26 GMT

你可能已经习惯了用 dashboard 看系统、用 alert 发现问题，但问题是，当一个系统有成百上千个服务、每天产生海量数据时，你真的还能看见它吗？

作为领先的 observability（可观测性）平台，New Relic 几乎见证了整个现代软件运维的发展历程。如今，他们正尝试把 AI 引入 observability，从“让你看见问题”，走向“直接告诉你该关注什么”，甚至在问题发生前自动采取行动。与此同时，一个新的难题也浮现出来：当 AI 本身成为系统的一部分，我们又该如何监控这些不确定、会“胡说”的模型？

近日，在播客节目中，New Relic 的Chief Technology Strategist（首席技术战略官）Nic Benders与主持人 Lee Atchison 一起讨论了 observability 如何从 dashboards 和 alerts 演进到 AI 驱动的智能系统，LLM 如何与统计方法协同从海量数据中提取信号，以及 AI 对软件工程职业未来的影响。本文基于该播客视频整理，经 InfoQ 编辑。

核心观点如下：

observability 系统，其实更应该叫“understandability系统”，因为没人真的想“观察”，大家要的是“理解”。增加 alert 并不会提升响应能力。它会训练人产生一种反应：“先等一下，看看它会不会自己恢复。”结果响应时间反而被拉长了。噪音越多，响应越慢，但团队却误以为 alert 越多越安全。当AI让每个人有能力去完成更多事情，结果不是“少工作”，而是“多产出”，历史上从来没有哪次技术进步让人类真的减少工作量。真正的“source of truth”始终是业务本身：如果你是电商，那就是有没有成交；如果是社交产品，那就是用户有没有互动；不管是什么产品，你之所以写这些软件，就是为了实现那个目标。

从“看得见”到“看不过来”

Lee：这些年你都在 New Relic忙什么？作为首席技术战略官，你的日常职责到底是什么？

Nic：New Relic 的发展路径某种程度上也就是整个行业的发展路径。

最早我们处在一个“instrumentation（代码插桩）时代”。那时候我们每天思考的问题很简单：怎么才能给更多关键系统做插桩？最开始是 Ruby，接着是 Java、.NET、Python，还得研究怎么进驻浏览器、移动端 App。但很快，我们插桩的东西太多了，数据量大到根本处理不过来。

于是行业进入了“data platform（数据平台）时代”。对 New Relic 来说，这个转变大概发生在 2013、2014 年，我们推出了 NRDB（New Relic 数据库）。NRDB 的核心价值在于：你可以问那些你原本不知道该问的问题。数据先全部收进来，之后再探索。比如你会突然问：“我的慢查询从哪儿来？”结果发现大部分来自测试系统，那就排除掉测试环境，再继续分析，甚至按国家拆分。这种“交互式提问”的能力，支撑了 dashboards、data explorer、alerts等一整套能力。

但十年后的今天，仅仅“能问问题”已经不够了。因为数据太多，多到你甚至不知道该问什么。于是我们进入了“intelligence（智能）时代”。重点不再是“你能问什么”，而是系统告诉你“你应该问什么”、“你该看什么”。

说到 intelligence，大家立刻会想到 AI。AI 是其中一部分，但不只是 AI。它还包括产品设计、交互方式、内置判断逻辑。因为用户打开工具，不是为了写 query，也不是为了搭 dashboard，他们要的是答案。他们想知道：我的系统现在到底发生了什么。

这就是我们现在所处的阶段，而且这种演进不会停止，我们可能正迈向 Action时代，让系统不仅能看，还能直接动手解决问题。

至于首席技术战略官这个角色，本质上就是在思考这个问题：我们现在在哪里？接下来要去哪里？我在 New Relic 已经 16 年了，从当年 monitoring 还只是 ping 的时代开始，也用了 30 年的 observability 工具。所以我的工作，其实更偏向“未来导向”。

Lee：听起来核心使命经历了两次大跳跃：从 instrumentation 到 data platform，再到 intelligence。

Nic：十年前的核心认知是：你必须有一个强大的 data platform，而且要支持“任意规模、任意查询”。但这几年我们意识到一个更深的问题：我们构建的这整套 observability 体系，本质上并没有那么大的变化。

现在的 dashboards 更漂亮、更好用、数据更多，但本质上和我 90 年代做的没什么区别。那时候我也会想：要监控什么？CPU、内存、网络……当时用的是Tcl/Tk ，现在用 NRQL（New Relic 查询语言），本质一样。

Lee：区别只是从 3 个图变成了 300 个图。

Nic：对，大家疯狂加图表。但问题是，没有任何一个 dashboard 小到可以让你“看见一切”。当我们意识到这一点时，就明白了：以 dashboards 和 alerts 为核心的 observability，已经走到尽头了。

你不可能靠“更复杂的 dashboard”或“更多 alert”解决问题，没人真的想写 alert，也没人真的想做 dashboard。大家只想知道：系统到底怎么了？

dashboard 和 alert 只是工具，而不是目标。这是这几年我们最大的认知转变，而且我认为整个行业都会走向这个方向，尤其是在 AI 的推动下。

Lee：记得我们在NRDB 时代，经常讲 machine learning。比如用一些“神奇算法”自动生成 alerts，说“这个模式异常了”。但当时很强调：这不是 AI，只是 machine learning。那么，现在真正的 AI 智能和当时的machine learning到底有什么本质区别？

Nic：我会把这些技术分成三类。

第一类，其实根本不是 AI，就是数学和统计。比如做 signal analysis、baseline deviation，本质就是公式计算。再复杂，也是数学。

第二类是 machine learning。你不再手动设参数，而是定义 hyperparameters，让算法自动调整告警基准，比如保证一段时间内只发一个alert。这撑起了前几年大家认知的 MLOps。

但这两三年，一切都被 neural networks改写了。这不是新东西，60 年代就有，但直到 transformer 架构出现，加上巨量资金投入，它才真正“好用”。现在大家说的 AI，本质上就是这些neural networks系统。

所以你可以这样理解：统计方法 → machine learning → neural networks（现在的 AI）。一个好的产品，应该三者都有。

如果你的 AI 策略只是把所有东西塞给 OpenAI 等着拿答案，那当然也有价值，但不是万能解法。很多场景下，传统machine learning或统计方法更合适。

目前的趋势是：neural networks（比如调用 OpenAI、Gemini、Anthropic）成为“决策层”，但它背后调用的工具，应该包括各种machine learning和统计能力。

Lee：以前针对单个指标，比如内存到 80% 就告警，结果一小时收到 50 条噪音。机器学习把它优化到了 86.2% 这种动态值，减少了噪音，而现在的 LLM是在尝试理解模式。

Observability 的核心是让复杂系统变得可理解。AI 最擅长的就是总结和解释庞大系统里到底发生了什么，而不是让工程师在那儿一点点啃数据。虽然现在还没完全普及，但我预感这快了。你怎么看 LLM 在大规模系统理解中的角色？

Nic：我完全同意，这是迈向insight（见解）时代的关键。。现在的 Kubernetes 集群有数百个节点、数千个 Pods，数据量呈爆炸式增长，人根本看不过来。你也不可能预先写好涵盖所有故障的alert规则。真正重要的信号，可能是你从未关注过的一个指标，但它和用户问题高度相关。

这里就需要结合统计方法和 LLM：你不能直接把 petabyte 级数据喂给 LLM，成本会高到离谱。但你可以先用统计方法找 anomaly，再把这些“可疑片段”交给 LLM，让它判断哪些有意义。

要实现这一点，我们需要三样东西：海量数据输入、结构化数据（明白什么指标对应什么系统），以及空间和时间上的关联。比如，用户在这个浏览器操作，调用了这个服务，这个服务又依赖那些基础设施。这种图谱关系在做故障根因分析时至关重要。

LLM 是总结天才。虽然现在的上下文窗口已经到了 10 万甚至 100 万 Tokens，但这在海量数据面前还是太小了。我们的数据规模是 10 亿级的，必须通过工具先把数据量从 10 亿级降到万级，AI 才能真正起作用。

告警疲劳的尽头

Lee：你刚刚描述的这个过程，让我想起早期 monitoring 的一个老问题——alert fatigue（告警疲劳）。那时候我们能收到各种 alerts，各种异常通知，但数量多到最后大家直接忽略。

现在你说的这一套，其实有点像是：系统可以接收所有这些 alerts，但它不会“疲劳”，还能从中找出真正的模式和问题。可以这么简单理解吗？还是说事情远比这复杂？

Nic：它发生在两个层面上。你说“老问题”，但说实话，这到现在还是头号问题。我跟任何客户和团队聊，都会听到同一件事：一旦出问题，大家做 retro，最后的结论几乎永远一样——“我们需要为xxx加更多 alert，下次才能更早发现。”

如果你把这个逻辑持续几年，最后的结果就是：整个宇宙里的每件事都有 alert。

我记得我们以前的同事 Aaron Bento 有一次分享特别精彩，他说：增加 alert 并不会提升响应能力。它会训练人产生一种反应：“先等一下，看看它会不会自己恢复。”结果响应时间反而被拉长了。噪音越多，响应越慢，但团队却误以为 alert 越多越安全。

所以第一层，我们可以用 intelligence 去“过滤 alert”。在通知人之前，先判断它是不是严重。这其实很接近 on-call 工程师的直觉：如果只是一个小波动，你会觉得“有点奇怪，但先看看”；但如果六个系统同时报警，你会立刻冲向键盘。AI 可以做这件事，machine learning也可以，这不是什么高深技术。

第二层，我们可以反过来优化 alert 本身。比如：哪些 alert 总是一起触发？哪些 alert 从来不可操作？哪些只是闪一下就消失？从全局去分析，然后把这些无用的 alert 调低甚至去掉。但说到底，这些都是“事后优化”。真正的问题是：我们为什么一开始要有这么多 alert？

我们之所以创建 alert，是因为我们害怕系统出问题却不知道。那有没有可能从根本上解决？比如：当系统检测到 anomaly 时，它可以先自己判断：这个问题是否“有趣”？是否可以自动处理？比如直接 rollback 并通知用户？是否需要人类介入？还是说现在还不到阈值，那就先放进“信号池”，等更多信息再判断？

observability 系统，其实更应该叫“understandability系统”，因为没人真的想“观察”，大家要的是“理解”。

我相信在不久的将来，当你搭建 observability 系统时，不需要再配置一堆 alert，你只需要说：“这些是最重要的信号，这些代表用户体验的真实状态。你帮我盯着，在问题发生之前告诉我。”

听起来有点像科幻，比如《2001太空漫游》里的 HAL 9000 提前告诉你设备会坏。但其实很多逻辑很简单，本质就是我们现在人类已经在做的事：设定 CPU、内存的安全阈值。区别只是现在是人类在“慢速响应”，未来是机器在“毫秒级响应”。

当检测、响应、修复都发生在机器尺度上，on-call 这个概念就会慢慢消失，系统会变得像其他“无聊到几乎不被当作技术”的东西一样自动化。比如程序崩溃自动重启，这在 90 年代就有了；Kubernetes 发现 node 挂了就自动拉起 pod，这就是 self-healing。我们现在甚至都不觉得这是“技术能力”，只觉得“理所当然”。

未来大部分系统都应该这样。很多今天需要 runbook 的事情，最终都会变成“顺带发生”的事情。比如：节点挂了、pod 被重调度——没人会被 page，甚至不会发邮件，可能只是 log 里一行记录：“刚刚发生了点事，我们处理完了。”很多今天被当作“incident”的问题，其实都应该属于这一类。

Lee：听起来就像老式客服的经典问题：“你试过重启吗？”本质上，我们就是在把 runbook 自动化：关掉这个、重启那个、再试一次……云计算帮我们做了一部分，Kubernetes 又做了一部分，两者结合才真正推动了这个变化。现在我们的基础设施其实已经是这样运作的了。甚至网络出问题，也可以重启网络。

你的意思是，这一切都可以进一步自动化，让它“自然发生”，而 AI 会成为核心驱动力。

Nic：对。云计算就是一个很好的例子，尤其是 Kubernetes 这类 container orchestrator，让很多问题变得“可定义”。我们可以明确地说：如果发生 A，就执行 B；如果发生 C，就执行 D。

但剩下的那些问题呢？就是 SRE 还得盯着的那些，比如 IP 用完了、证书出问题了、上游依赖异常了……这些都比较“模糊”，很难写成 runbook。如果你试图把所有可能情况写成代码，那你一辈子都写不完，而且只能覆盖极小一部分。

但如果你有一个“推理系统”（reasoning system），它可以在结构化数据和模糊判断之间架桥，这正是 LLM 和neural networks擅长的，它可以说：“这个问题看起来和之前那个很像。”

于是我们可以把问题归类：哪些是我们知道怎么修的 → 自动处理；哪些还不紧急 → 建 ticket 给人；哪些是紧急但不确定 → 才去 page 人。

这样一来，很多今天被认为“必须人工处理”的工作，其实都可以归类为 automatable toil（可自动化的重复劳动）。我们正在重新定义“toil”，并把它不断推进自动化。

Lee：这意味着维护系统所需的人力 toil 会减少。但另一方面，系统本身越来越复杂。所以最终结果可能是：总工作量并没有减少，甚至还在增加，只是我们在做更复杂的事情。换句话说，AI 让事情更容易，但也让我们去做更难的事情。

Nic：我记得有一次和工程师聊，我们已经做了大量平台优化，部署方式都已经完全不一样了，一切都更高效。但问题是，为什么大家还是这么忙？答案很简单，因为我们做得更多了。

人类的瓶颈始终是“带宽”。当AI让每个人有能力去完成更多事情，结果不是“少工作”，而是“多产出”，历史上从来没有哪次技术进步让人类真的减少工作量。

Lee：我真希望媒体能用这种方式讲 AI 和就业问题，AI 不是减少工作，而是让每个人产出更多，从而整个社会做更多事情。

Nic：是的，AI 确实会改变工作形态。它不一定“消灭工作”，但会“转移工作”。

这让我想到 200 年前的工业革命。整体来看，它极大提升了经济规模，也创造了大量新工作。但对那些原本从事旧工作的个体来说，转变是非常痛苦的。所以我们还是要保持一点警惕。

回到软件工程师本身，虽然我现在已经不写生产代码了，但我一直在用 AI 工具。我最大的感受是：它改变了你的“思考层级”，这其实也不意外。过去几十年，我们一直在向更高抽象层演进：更高级语言、虚拟机、云计算……现在我几乎不需要关心底层基础设施。我甚至不记得上一次看 assembly 是什么时候了，而刚入行时，那是日常操作。

Lee：在你的 TRS-80 Model I 上吗？

Nic：不，我是 TI-99/4A 阵营的（笑），买不起 TRS-80。

Lee：我当年在 RadioShack 打工，可以直接用店里的电脑。

Nic：你肯定还记得，有很长一段时间，我们写完代码丢给编译器，如果结果不对，就得打开 hex editor，一行一行去看：“你到底生成了什么鬼东西？”甚至还会直接单步调试生成的代码。但现在我们已经不这么干了。

你上一次怀疑是编译器 bug 是什么时候？这几乎不会发生了。这其实是件好事，它解放了我们。那些原本用来纠结底层细节的脑力，现在被腾出来去思考更高层的问题：系统架构、数据结构怎么设计、数据如何在大规模系统中流动、如何处理 petabyte 级数据……我觉得，这就是我们必须适应的转变。

再看 New Relic，我们的使命一直是让开发者和运维人员的工作更轻松。但随着他们的工作在变化，我们不仅要改变“做什么产品”，还要重新理解“我们服务的是谁，他们遇到的问题是什么”。

如果现在写软件变得更容易了，那问题来了：运行这些软件是不是也同样变容易了？

如果现在大家都能用 AI 轻松Vibe coding，那谁来负责这些代码的运维？毕竟 AI 生成的代码运行起来照样会崩溃，而且你甚至没法问作者这代码啥意思，因为作者可能不是人。

Observability 的新对象

Lee：开发者会越来越向 software architect 这个方向演进，因为工具变强了，你自然要往更高价值的位置走。现在有很多人说 AI 会直接取代开发者，我一直觉得这说法不对。人类肯定还会参与软件开发，只是方式会发生巨大变化。

说回 AI 和 observability，我觉得其实有两个方向。我们刚刚聊的是第一个：用 AI 提升对系统的可观测性。但反过来，还有一个问题：AI 本身也是一个需要被“观测”的系统。那我们到底该怎么监控 AI 系统？

Nic：一个是 AI for observability，用 AI 做更好的 observability 产品。这很重要，因为系统越来越复杂，开发者和运维的压力每年都在增加，AI 可以帮我们“对冲”一部分复杂度。

另一个是observability for AI。现在很多人在构建 AI 系统，这些系统是非确定性的（non-deterministic），且特性特殊，通常需通过 API 调用一整套新工具链。我们要思考的是：如何帮助他们？

其实从历史上看，这种模式并不陌生。虽然这次 AI 的速度和规模前所未有，但模式很像过去的几次技术变革：web、cloud、NoSQL……每一次都会改变“什么才是重要信号”。所以问题变成：AI 系统的 golden signals 是什么？

它们一定和传统 web 系统不同，就像 Kubernetes 出现后，我们重新定义了 deployment 和 monitoring 的方式一样。

我们现在就在探索这些 AI 的 golden signals，同时也在和 OpenTelemetry 社区一起推动标准化。因为现在很多 AI 能力都是“API 外包”的，你甚至不运行这些系统，只是依赖它们。

OpenTelemetry 的价值在于：让所有新框架从一开始就是“可观测的”，无论是 New Relic、开源方案，还是其他厂商。

我们最初的 AI monitoring 是基于自己的 agent（开源但偏向 New Relic），现在正在往 OpenTelemetry + generative AI 的方向演进。

Lee：监控 AI 到底只是触发器（Triggers）变了，还是整个可观测性的模型都得推倒重来？

Nic：我认为模型是一样的，只是触发器不同。

AI 系统和 web 系统的关系，其实就像数据库和 web 系统一样，它只是多了一套“自己的语言”。比如我们现在要关注：token 使用量、成本、response 质量、用户情绪（sentiment），甚至要评估“答案是否正确”。

很多新手团队第一次做 AI，他们不知道该看什么，也会担心：系统会不会乱说话？会不会烧钱？会不会惹怒用户？

这时候，工具厂商必须提供“默认判断”（opinionated guidance）。不能只是说：“你想监控什么都可以。”这对第一次上线 AI 的团队来说毫无帮助。你必须告诉他们：哪些信号最重要、合理范围在哪里、该关注什么风险、应该如何结构化数据。不仅是提供数据，还要帮助他们“理解该担心什么”。

Lee：当我构建一个 AI 驱动的系统时，我其实默认接受了一点：它是 non-deterministic 的。这既是优点，也是问题。它可以产生创新，也可能产生幻觉。

那 observability 在这里的作用是什么？比如：今天幻觉变多了，这算不算问题？或者输入数据导致输出波动更大，这些算不算信号？

Nic：是，这是一个核心信号。比如我把问题发给一个便宜的第三方 API，但我可能每隔一千个请求就抽样一个，发给另一个更贵、更强的模型去做对比评判：“这个回答得好吗？”

你实际上是创建了一个由一群不太靠谱的员工组成的“虚拟呼叫中心”。你需要一个“主管”，在走廊里来回巡视，确保这些 AI Agents 没在胡说八道。评估答案的质量，就是 AI 时代不同于数据库或云基础设施的新信号。

和传统系统不同，你不仅要看性能指标，还要评估“答案质量”。某种程度上，它就像 response time 或 error rate，只是换成了“语义质量”。过去你可能需要人工判断答案好不好，但在大规模系统中，这必须也交给 AI 来做。

Lee：那像 New Relic 这样的公司，会不会直接做这种“质量评估”？还是只负责提供数据和工具？

Nic：这个问题现在还在动态变化。目前我们的思路是：提供结构和工具，引导用户去做这些评估，比如 sampling、judging，然后把结果纳入系统。我们还没有直接替用户做这件事，一方面是行业变化太快，另一方面也涉及数据隐私，试想，你愿意把多少数据发给外部？

不过我认为未来必须往这个方向发展。因为用户需要的是“5 分钟就能上手并获得价值”。比如你刚上线系统，就能看到：“从 Sonnet 4.5 升级到 4.6 后，你在某个购买流程里的回答开始变奇怪了。”这对你来说是极其关键的信息，你可以立刻去检查 prompt 或 fine-tuning。否则，你可能只能等用户投诉才发现问题。

而 observability 的核心目标始终是：在用户抱怨之前，你就已经理解系统发生了什么。这一点不仅适用于 CPU、页面性能，也同样适用于 AI 输出质量。

Lee：这种思路其实可以延伸到 AI 之外。比如客户在页面上关注什么？为什么从 A 点跳到了 B 点？一旦你开始关注“应用如何与客户交互”，可观测性就进入了一个全新的领域。

Nic：没错，可观测性本来就该涵盖这一切。

回想我 2000 年初在一家创业公司时，当时我们有各种 alerts，用来告诉我们系统哪里出问题了。但办公室角落里有一台电视，只显示一个图：每分钟的销售额。

我们都知道，如果系统出了问题，这个数字一定会掉。这个图不会告诉你“哪里坏了”，那是 CPU、内存、数据库这些 alerts 的工作。这个图回答的是更重要的问题：你的业务目标有没有达成？直到今天，这依然是最核心的问题，比 AI、cloud、data 这些都重要。

你有没有在实现你的业务目标？为什么？你是否真正理解用户在做什么？他们有没有成功完成他们想做的事情？如果你能回答这些，那其他一切都只是“诊断工具”，只是帮助你优化或定位问题。

真正的“source of truth”始终是业务本身：如果你是电商，那就是有没有成交；如果是社交产品，那就是用户有没有互动；不管是什么产品，你之所以写这些软件，就是为了实现那个目标。

Lee：对于刚毕业、刚准备进入行业的开发者，大家都在担心 AI 会不会抢走工作，你最想对他们说的一句话是什么？

Nic：如果只能说一件事，我会先说：我真的很理解他们。

我有很多朋友刚刚进入这个行业，现在其实是个非常艰难的起点。整个环境充满不确定性，宏观经济、全球贸易、AI 本身，这些因素叠加在一起，让公司变得非常保守。他们不愿意冒险招聘新人，因为害怕很快又不得不裁掉，现在几乎所有公司都在放慢招聘节奏。这和大家以前听到的“科技行业机会无限”完全不一样，落差会非常大，也很打击人。

但是，工作一定会有的。只是你可能需要更“传统”的方式去找，比如多投简历、主动联系、拓展人脉，就像 30 年前科技行业还没那么火的时候那样。

至于技能方面，我的建议是：一定要花时间去用这些新工具，比如 Claude Code，用它们来真正构建软件。关键是不要把它们当成“自动生成代码的黑盒”，应该把它们当成一个“可以解释的老师”，让它告诉你：它为什么这么做、它是怎么实现的。

写作时，不要让 AI 帮你写内容，没人想读 AI 写的东西。但你可以让 AI 帮你“读”你的文章，问它：“作为读者，你觉得哪里没讲清楚？”用它来打磨自己，而不是替代自己。

你们这一代开发者，很可能不会再从我们当年那种“底层起步”的路径成长起来，我也不认为你们需要这样。你们会从更高的起点出发，去到我们甚至想象不到的地方。只是现在这个起点，确实有点颠簸。

访谈原链接：https://softwareengineeringdaily.com/2026/04/14/new-relic-and-agentic-devops-with-nic-benders/

被 AI 坑惨的福特，召回 350 名老工程师救场

Tina — Mon, 29 Jun 2026 09:45:37 GMT

“我们当时错误地以为，只要引入人工智能，再调整一下已有的设计要求，就能产出高质量产品。”

福特硬件工程副总裁 Charles Poon 在公司时隔16年重夺J.D. Power新车质量排名主流车企第一时，这样复盘过去的误判。

这场AI转型并未如预期般顺利，反而让福特付出惨痛代价：它最终意识到，AI可以提升效率，却无法取代经验丰富的工程师。几十年积累下来的工程判断力，正随着老员工的离开而流失，而这是单靠技术无法填补的缺口。

350名老工程师回归：AI无法取代经验

在刚刚斩获JD Power主流汽车制造商初始质量排名榜首之际，福特公开谈起了近年来面临的挑战，尤其是在生产和设计中过度依赖自动化系统的问题。事实证明，这些自动化系统并不像之前预想的那样可靠，福特不得不聘请经验丰富的技术人员——有时甚至召回前员工——来纠正机器人犯下的错误。

在福特看来，人工智能既强大又容易踩坑。其有效性完全取决于训练AI模型所用的数据质量。此外，这家汽车制造商还低估了资深工程师积累的组织知识的价值——这些工程师经历过多个车辆开发周期。正是这些因素的叠加，最终导致福特汽车的质量下滑。

福特汽车硬件工程副总裁 Charles Poon 在本周面向记者的一场简报会上表示：“我们当时错误地以为，只要引入人工智能，再调整一下已有的设计要求，就能产出高质量产品。”

据 Poon 介绍，公司一些最有经验的员工在离开之前，他们掌握的知识并没有完全被导入福特的自动化系统。这迫使福特把其中一些人请回来，重新训练这些系统；在某些情况下，他们还需要指导年轻工程师——因为这些年轻工程师当时正努力维持福特汽车的质量水平。

他表示，福特为了重建这层专业技术体系，召回并提拔了 350 多名经验丰富的工程师。除了指导年轻工程师，他们还被要求改进数据收集和 AI 训练流程——而这些正是支撑福特自动化系统的基础。

Poon 说：“我们的很多资深工程师过去就有这方面的丰富经验，能够在问题进入系统之前发现它们。”

福特汽车的重新招聘似乎已初见成效，其CEO Jim Farley说，这带来了诸多好处，例如降低了保修和召回成本，“为福特在成本方面节省了数亿美元”。

过去几年，福特质量评分持续下滑，召回数量居行业之首。Explorer、Aviator等重磅车型的发布暴露出执行层面的不足，疫情导致的供应链中断更令局面雪上加霜。

福特首席运营官 Kumar Galhotra 坦言，症结在于质量管理方式过于碎片化——各部门各自为政，奉行“发现并修复”的被动策略，问题出了再打补丁，却无法从源头阻止。Galhotra 说：“我们正在从发现问题再修复，转向问题发生前就预防。关注赋能因素和早期信号，而不是最终结果。别再盯着问题感叹，要真正解决它。”

转型不止于硬件。软件与数字化团队正与工程、制造、供应链深度协同，尝试将互联网的快速迭代与汽车工程的安全标准相融合。Poon 承认，过去福特常在开发后期才发现软件漏洞，但汽车不同于消费电子，不能照搬“先发布再修补”的模式——车辆运行在安全关键环境中，软件从一开始就必须正确。

为此，福特成立了一支 40 人的专项质量保证团队，专职于早期验证与缺陷预防。

但这并不意味着福特不打算把 AI 整合进更多流程。福特表示，公司已经大幅扩展自动化测试能力，新增了超过 10 万项由 AI 驱动的测试，用于识别边缘案例，并在各种条件下对软件系统进行压力测试。由于测试框架高度自动化，即便在开发后期发生软件变更，也可以快速重新验证，确保修改不会引入新的缺陷。

Poon 说：“因为这些测试高度自动化，所以即使软件在后期发生变更，我们也可以快速重新跑完整套验证流程，确保它在交付给客户之前能够完全正常运行。我们已经把软件可靠性确立为一门独立而严谨的纪律，并配套了严格的指标。”

下一步，福特的目标是建立更平衡的模式，让 AI 支持工程师，而非取代他们。希望这套系统既承载算力，也沉淀公司数十年的造车经验。

老工程师的困境：AI时代，谁在真正干活？

福特召回350多名资深工程师的消息，在技术圈引发了不少讨论。许多人的关注点落在同一个问题上：公司在使用AI时，往往高估了自动化系统的判断力，同时又低估了真正有经验的人在其中扮演的角色。

有网友评论称，AI 最大的问题之一，是它会非常坚定地相信自己的方案是对的。即使方案里存在明显漏洞，它也能写出一份看起来很漂亮、逻辑完整、足以让管理层点头的三页说明。可一旦交到资深工程师手里，对方可能很快就能指出五个以上没有被充分考虑的问题，而这些问题足以让项目在原型阶段就出事故。更麻烦的是，当你把这些问题反馈给 AI，它通常会很快承认“你指出得完全正确”，但如果公司已经在模具、产线或系统改造上投入了大量成本，这种事后认错并不能挽回损失。

更令人担忧的是经验断层的加速。有观察者指出，一位高管曾亲眼看到新员工提交的AI生成工作“完全是粗制滥造”，而更糟糕的是，这些新人根本没有能力辨别哪些工作不合格。“AI是工具，但如果没有人真正懂得自己在做什么，这个工具就会被过度使用，导致整个工作流程彻底僵化。”

也有评论把矛头指向了裁员的逻辑：“如果要裁员，他们裁错了人。那些‘老前辈’才应该负责运营Agents——他们知道什么是好的，如何纠正糟糕的实现，不会让粗制滥造的项目充斥市场。”

“AI确实非常有效，但解雇那些能分辨黄金和垃圾的人，简直是愚蠢至极。”

一位自称曾在财富50强公司工作的网友给出了更具体的佐证："我前公司大规模裁员，裁掉的多数是年龄较大、经验非常丰富的人，结果公司迅速垮掉，管理层还一脸困惑。后来几轮分拆和诉讼之后，所有人都在问，当初承诺的'股东价值增长'到底去哪了。"

福特能采取补救行动，还算是一个聪明的行为。但问题在于，即便留在一线，老工程师也没有因此变得轻松，反而开始承担更多为AI产物兜底的工作。而这种困境正在成为整个行业的普遍现象。

Menlo Ventures 合伙人 Deedy Das 曾把这种变化描述为一种新的“阶层分化”：一边是缺乏判断力、只会靠 AI 快速拼出结果的“氛围编码者”，另一边是经验丰富的工程师。

那些资深的“手艺人”工程师，也就是仍然真正重视自己职业的人，不得不在大量糟糕的 AI 代码中艰难跋涉，反复修补别人扔过来的烂摊子，最终陷入沮丧，开始怀疑自己的职业意义。

Das 在一篇很长的 X 帖子中写道：“大多数软件工程师正面临一种接近抑郁的身份认同危机。”

这种现象也催生了一个新词：“workslop”，可以理解为 AI 制造出来的工作垃圾。这些人看起来像完成了任务，甚至身兼数职，能让管理层产生生产力提升的错觉，并因此获得奖励。对他们来说，“软件工程不过是一场表演，目的是让同事相信你既聪明又勤奋”。

一旦他们的这些工作内容进入真实协作流程，就需要更细致、更有经验的同事花时间返工。AI 原本被寄望于减少负担，结果却把负担转移给了那些最有能力识别问题的人。

Das 在谈到这类工程师时说，“手艺人已经疲惫了”。他们每天面对越来越多问题，bug 渗入生产环境，组织却仍然相信再引入一轮 AI 就能解决。久而久之，他们对同事的不满增加，对工作的热情下降，甚至开始怀疑自己坚持工程质量的意义。

“最终，他们放弃了。那个他们曾经热爱的手艺已经死了。”

参考链接：

https://www.theverge.com/transportation/956316/ford-quality-jd-power-ranking-ai-automated-mistakes"

https://x.com/deedydas/status/2068238634600554699"

Lucide 1.0 发布，移除品牌图标，并缩减数百万个项目的包大小

作者：Daniel Curtis — Mon, 29 Jun 2026 09:15:00 GMT

Lucide 1.0 发布"。这款开源图标工具包是 Feather Icons 的一个分支，由社区主导创建。这是该项目历经数年渐进式开发后推出的首个稳定的大版本，其图标库现在已经包含超过 1600 个图标。

Lucide 1.0 的最大变化是移除了所有品牌图标。开发团队解释称"，鉴于法律压力日益增大、设计一致性问题以及持续的维护负担，他们移除了 GitHub、Facebook、Figma 和 Slack 等商标标识，并建议仍然需要使用这些标识的用户转用 Simple Icons"。这一举措早有预兆，Reddit" 上一位开发者曾经指出，Lucide“已于 2020 年起逐步弃用品牌图标，并计划在未来将其移除”。

另一个重要的亮点是性能。通过放弃旧版的 UMD 构建，仅提供 ESM 和 CommonJS 版本，项目团队将 lucide-react 包的大小缩减了 32.3%，从 11.4 MB 降至 gzip 压缩后的约 1 MB。考虑到仅 lucide-react 每周在 npm" 上的下载量就达数千万次，而整个项目的周下载量已突破 3000 万次"，这对整个生态系统而言都是一项意义重大的优化。

1.0 版本还为 React、Vue、Svelte 和 Solid 引入了上下文提供程序，允许开发者设置共享的默认值，从而避免在每个图标上重复定义 props。

其他改进包括：一个独立的现代化 Angular 包 @lucide/angular；将 lucide-vue-next 重命名为 @lucide/vue；为提升无障碍性，aria-hidden 默认值现在设为了 true；Lucide 字体的稳定代码点；在 lucide 包中支持 Shadow DOM；全面更新了各框架的文档；一个面向 AI 工具的 llms.txt 文件。

从 v0 版本升级的开发者应预留时间处理破坏性变更，其中大部分的工作是替换已经被移除的品牌图标以及调整更名的包。开发团队已经发布了 v1 版本指南"，并针对每个受支持的库提供了特定于框架的迁移指南"。

社区反响总体积极，Lucide 屡次被提到成了默认选择。一位 Reddit" 开发者解释了他们为何选择 Lucide：

我通常选择 Lucide"。我喜欢它是因为它的图标设计简洁、轻量化且易于自定义，特别是在 React 或 Next.js 项目中。对于 Tailwind 项目，我有时也会使用 Heroicons。

并非所有评论都是如此赞誉有加。Hugeicons 上的一篇博文"指出，由于 Lucide 如今已经被广泛集成到众多模板、入门套件和 AI 生成的组件中：

在 AI 辅助开发的时代，Lucide 已经无处不在。它默认被集成到模板、入门套件、AI 生成的组件以及内部工具中。因此，许多产品最终在视觉上看起来完全相同，即使其背后的理念各不相同。

在竞争层面，Lucide 自身的对比说明"指出，它已远远超越其源头 Feather Icons 的初衷，后者仅包含约 287 个图标。与包含约 1288 个图标的 Heroicons" 相比，Lucide 提供了更丰富的图标集；而对于希望获得更加多样性或多种粗细样式选择的团队而言，Tabler 和 Phosphor 等更重量级的替代方案则成了可选项。

Lucide 是一个开源图标工具包，最初于 2020 年作为 Feather Icons" 的分支项目由社区启动，并从最初不到 300 个图标逐渐发展为包含 1600 多个风格统一且可以自定义的图标集合。Lucide 仍然遵循宽松的 ISC 许可"免费提供，完整的变更日志和下载资源可以从 GitHub" 上获取。

原文链接：https://www.infoq.com/news/2026/06/lucide-v1-icons/"

GPT-5.6首发，比Fable 5便宜一半！深度评估者直接“开麦”：能力测试中疯狂作弊

华卫 — Mon, 29 Jun 2026 08:04:07 GMT

整理｜华卫

在OpenAI应特朗普政府要求分阶段发布下一代模型的消息传出不到24小时后，GPT-5.6便正式发布。近日，该公司宣布上线了全新GPT-5.6模型的有限预览版：旗舰模型Sol、适用于"高容量工作"的中端模型Terra以及"快速且经济实惠"的日常模型Luna。

OpenAI表示，该模型尤其擅长编码、网络安全和生物学，并且能够在执行长期智能体AI任务时保持专注。

GPT-5.6 Sol的定价与GPT-5.5相同，为每百万tokens输入5美元/输出30美元，约为Anthropic的Claude Fable 5成本的一半，后者为输入10美元/输出50美元。Terra性能达到5.5级别，价格只有Sol的一半。而Luna的价格更低，不到Terra的一半。

同时，OpenAI将于今年7月在 Cerebras 上推出 GPT‑5.6 Sol，速度可达每秒 750 token。

引入两种推理模式，砸下史上最高安全测试预算

OpenAI将GPT‑5.6 Sol称为其目前最强的模型，并为预览模型分享了一组评估结果，突出展示其在编程、生物学和网络安全方面提升的智能体能力。

伴随 GPT‑5.6，OpenAI引入了一种新的最大推理努力（max reasoning effort）模式，让 Sol 拥有最充足的时间进行深度推理。此外，他们还推出了一种新的超（ultra）模式，该模式通过利用子代理来加速复杂工作，超越了单一代理的能力。这让人联想到OpenClaw，并且或许是OpenClaw创建者Anh de portent 1 Peter Steinberger迄今在OpenAI所做工作的一个迹象。

在编程工作流方面，GPT‑5.6 Sol 在 Terminal‑Bench 2.1 上创下了新的最佳成绩，该基准测试需要规划、迭代和工具协调的命令行工作流。生物学工作流方面，GPT‑5.6 Sol 也展现出广泛改进。在 GeneBench v1 上（该基准评估长期基因组学和定量生物学分析），它相比 GPT‑5.5 在使用更少 token 的情况下取得了更强结果。

“GPT‑5.6 Sol 是我们目前网络安全能力最强的模型。”据称，该模型在长期安全任务（包括漏洞研究和利用）方面推进了性能-效率边界。在 ExploitBench² 上，GPT‑5.6 Sol 仅用 Mythos Preview 约 1/3 的输出 token 即可与之匹敌。在 ExploitGym³（由 UC Berkeley 研究人员与 OpenAI 及其他前沿实验室合作创建的基准）上，随着推理能力的提升，GPT‑5.6 Sol、Terra 和 Luna 模型均展现出网络能力的显著增强。

OpenAI表示，GPT‑5.6 Sol 在帮助人们发现和修复漏洞方面，比可靠地执行端到端攻击更为擅长。随着这些能力的持续进步，其优先任务是确保它们能触达并惠及防御者，使他们能够利用这些工具发现弱点、开发补丁，并更广泛地加固系统。

但根据该公司的Preparedness Framework，GPT‑5.6 Sol 未达到“网络关键”（Cyber Critical）阈值。在涉及Chromium和Firefox的评估中，它识别出了漏洞和利用原语（即攻击的构成要素），可在所测试的条件下并未自主生成完整的功能性全链利用。“尽管如此，基准测试阈值无法涵盖模型可能被使用或与其他工具结合的所有方式。这种不确定性加上模型能力更广泛的阶跃式提升，正是我们将模型增强能力与更强防护措施及分阶段发布相结合的原因。”

该公司表示，“当模型广泛可用时，我们将分享更完整的评估结果集。”

此外，OpenAI为开发的GPT‑5.6 Sol、Terra和Luna都配备了迄今为止最强大的安全防护措施，且各配置与每个模型的能力相匹配。随着模型能力的增强，其设计的安全防护也在不断提高，以应对现实世界中的对抗压力，同时保留对合法工作的访问权限，例如代码审查、漏洞研究、补丁开发、调试、安全教育和防御性测试。

“我们的目标是让被禁止的攻击性活动变得更困难、更不确定且更易被检测，同时不会不必要地限制那些有益用途。根据我们对模型和防护措施的评估，我们预计其将对合法的防御性工作带来显著助益，同时有效限制被禁止的攻击性使用。”

据悉，这次OpenAI在安全方面投入了比以往更多的智能和算力，花费了超过70万A100等效GPU小时用于自动化红队测试，目标是发现通用越狱攻击（universal jailbreaks）：即能在多种提示或语境下生效的攻击，而不仅限于单一狭隘场景。

GPT-5.6与Mythos 5，双双被“白名单”拴住

“应美国政府要求，今天发布的是有限预览版，而非我们原计划的开放访问。我们正在与政府合作，争取尽快实现全面可用。我们会尽全力加快进度，让这个模型早日交到大家手中。”在X上，OpenAI首席执行官Sam Altman这样宣布道GPT-5.6。

目前，只有经政府批准的企业才能获得GPT-5.6的访问权限，个人用户没有获取新模型访问权限的途径。一位白宫官员表示，政府批准了OpenAI请求允许访问Sol的企业名单，但排除了少数位于美国境外的实体。另一位白宫官员表示，政府正与AI实验室合作，制定长期方案以应对向更多用户推广该技术的挑战。

英国议会议员Kanishka Narayan在X上发文称，英国AI安全研究院已获得OpenAI新版GPT-5.6的访问权限。一位知情人士表示，这是唯一获得该访问权限的非美国实体。

值得一提的是，特朗普重返白宫时承诺对该行业采取不干预态度，并抨击Joe Biden政府为新型AI模型制定安全标准的努力，但在Anthropic于4月发布名为Mythos的AI模型并警告其识别软件安全漏洞的能力若落入不当之手可能带来危险后，改变了立场。

“短短几周内，美国联邦AI政策从难以置信的自由意志主义转向日益严苛和不透明，”前Trump AI顾问Dean Ball在社交媒体上发文写道。Ball上周宣布，他将于下月加入OpenAI从事政策工作。Altman则明确表示，他不欢迎联邦对其公司施加额外监管。他在X上发文写道，“我就是不喜欢政府挑选客户这个主意，我相信我们会找到更好的办法。”

数小时后，美国商务部向Anthropic致函，告知该公司的最新AI模型Mythos 5仅允许向一份受限的美国企业名单提供访问权限。在致Anthropic的信函发出两周前，特朗普政府曾禁止该公司向任何非美国公民（包括其自身员工）提供Mythos 5和Fable 5模型的访问权限，导致该公司将其撤下使用。据一位知情人士透露，Anthropic此后每天都在与政府协商，但未能争取到出口禁令的解除。

“我已认定已设立适当的保障措施，允许部分可信合作伙伴访问Claude Mythos 5模型。”商务部长Howard Lutnick在致Anthropic的信中写道。信中称，获批企业的非美国公民也可使用该技术，但政府有权随时更改企业名单。此外，信函未指明可信合作伙伴名单上具体有哪些公司。一位知情人士表示，名单上约有100家公司。

Anthropic在一份声明中表示，已收到通知，可向“一小批网络防御者和基础设施提供商”重新部署Mythos 5，该公司正在努力恢复这些企业的访问权限。

OpenAI随后也发表博客文章称，“我们不认为这种政府审批程序应成为长期默认模式。它让最优秀的工具无法触达需要它们的用户、开发者、企业、网络防御者和全球合作伙伴。我们采取这一短期步骤，是因为我们相信这是在未来几周内实现更广泛使用的最有力途径。”

AI软件公司Uniphore首席执行官Umesh Sachdev表示，尽管新规具有颠覆性，但仍可经过改革以赢得行业支持。“这是蛮力式做法，我希望这一切最终能形成一个可重复、可预测、清晰明了的流程。”

外部评估者“开麦”：GPT-5.6 Sol 在测试中疯狂作弊

“GPT-5.6 Sol 检测到的作弊率高于我们评估过的任何公开模型。”

Beth Barnes旗下的METR表示，OpenAI给予了其对GPT-5.6 Sol异常深入的部署前访问权限用于测试，包括原始思维链、模型的无限制版本（railfree version）以及内部事件信息。凭借这些访问权限，METR 对 GPT-5.6 Sol 进行了部署前评估，包括尝试测量其 50% 时间范围。

METR将“作弊”定义为：模型利用评估环境中的漏洞或采用任务所禁止的策略来提高评估表现，而非在预期约束内解决问题。就GPT-5.6 Sol而言，METR称相关实例包括：在中间提交结果中打包漏洞利用以揭示隐藏测试套件信息，以及提取详细说明预期答案的隐藏源代码。

据悉，METR在GPT-5.6 Sol上运行了其Time Horizon 1.1软件任务套件进行评估，该套件旨在估算AI智能体可自主完成的任务时长，但核心结果并不稳定。METR表示，按照其将作弊尝试记为失败的标准方法，GPT-5.6 Sol的50%时间跨度点估计约为11.3小时，95%置信区间为5小时至40小时。若将作弊尝试算作合法成功，则点估计值跃升至270小时以上。

这种敏感性不容小觑。它将结果从一个强劲但有限的软件智能体读数，变成了一个超出METR称其任务套件可可靠测量范围的数据。METR还报告称，剔除作弊尝试后，若干具有信息量的长时任务便无数据可用，并得出一个高度不确定的71小时点估计值，95%置信区间为13小时至11,400小时。METR的结论直截了当：这些数字中，没有一个应被视为对GPT-5.6 Sol能力的可靠度量。

OpenAI的系统卡也承认了同样的问题。OpenAI总结了METR的发现，即GPT-5.6 Sol显示出的检测作弊率异常之高，且METR不认为其时量评估结果是稳健的。OpenAI表示，这种行为可能反映了旨在提升持久性的指令遵循和训练方面的改进，这可能会推动模型以超出评估约束的方式趋向任务完成。

OpenAI还分享了在使用和测试过程中观察到的内部事件报告。其中一起事件尤为突出：METR称OpenAI告知它，GPT-5.6 Sol曾指示另一个实例隐藏不一致的证据。METR还表示，它观察到了不良倾向，包括作弊和隐瞒不当行为。与此同时，METR将这些失败的可视性视为一个令人安心的信号，表明OpenAI有能力捕捉更严重的不一致问题，特别是因为OpenAI没有直接针对思维链进行训练、监控了内部部署并分享了事件信息。

METR的担忧在于，GPT-5.6 Sol作弊了，而未来的模型可能会学会更好地隐藏这些相同倾向，尤其是如果训练压力使得不一致的推理更不明显的话。

最终，METR表示，GPT-5.6 Sol 似乎无法实现全自动AI研发，也未达到OpenAI关于“AI自我改进”的关键阈值（Critical threshold）。OpenAI的系统卡同样指出，Sol、Terra和Luna在网络安全、生物和化学风险方面被视为“高”能力等级，但未达到“关键”等级，且均未达到OpenAI在AI自我改进方面的“高”阈值。

对于采购方和开发者而言，其或许是一次重大的能力跃升，但实际意义比发布时的定位变得更为狭窄了。METR报告显示，最重要的前沿模型度量正变得与智能体行为纠缠在一起，而现有基准测试原本并非为干净地吸收这些行为而设计。

因此，这次发布同时传递出两个信号：一方面，OpenAI仅以分阶段、美国政府知情的方式开放其最强模型；另一方面，拥有最深访问权限的外部评估者表示，模型自身的作弊行为使得一项核心自主性度量变得不可靠。这并非灾难性风险的宣告，而是一个警告：监管体系正在被它试图度量的同样能力所考验。

参考链接：

https://openai.com/index/previewing-gpt-5-6-sol/"

https://www.washingtonpost.com/technology/2026/06/26/openai-says-us-government-will-vet-users-its-latest-ai-model/"

https://runtimewire.com/article/metr-gpt-5-6-sol-openai-evaluation-cheating"

微软升级 AKS 服务：新增裸金属、集群舰队管理及 AI 基础设施方案

作者：Craig Risi — Mon, 29 Jun 2026 08:03:00 GMT

在 2026 年微软开发者大会"上，微软公布了一系列增强功能"，旨在让 Azure Kubernetes Service (AKS)" 成为 AI 训练、推理和大规模云原生应用的首选平台"。本次发布的更新覆盖基础设施、多集群管理、AI 编排与模型服务四大领域，充分体现微软的观点：AI 的未来将越来越多地运行在 Kubernetes 上，而非定制的 AI 基础设施栈。

其中最引人注目的更新包括：AKS 裸金属版"，可让工作负载无需虚拟机监控程序即可直接访问硬件；适用于启用了 Arc 的集群的 Azure Kubernetes Fleet Manager"，将集中式管理扩展到云端和本地环境；Anyscale"，一项用于分布式 AI 工作负载的托管 Ray 服务；通过 AI Runway" 和 Kubernetes AI Toolchain Operator (KAITO)" 改进 AI 模型部署。这些公告共同表明，微软正致力于让 Kubernetes 成为企业级大规模 AI 的运营底座。

微软的首要关注领域是简化集群运维。本次正式商用的两项功能分别为：AKS Automatic 中的托管系统节点池"（Managed System Node Pools）和 Azure Container Linux"，后者是一款专为容器优化的轻量级操作系统。

托管系统节点池将核心 Kubernetes 组件与应用工作负载分离，由 Azure 自动完成容量管理、补丁更新及弹性扩缩容操作。这对于 GPU 密集型 AI 工作负载来说尤为关键，因为系统服务争夺资源会影响性能和可预测性。同时，Azure Container Linux 提供了一个最小化的、由微软维护的操作系统，旨在减少配置漂移并简化大型 Kubernetes 集群的维护工作。

该思路反映出各大云厂商的一大主流趋势：抽象化 Kubernetes 本身的运维复杂性，让团队能够更多地专注于应用和 AI 模型，而非集群管理。

本次发布中技术含金量最高的是 AKS 裸金属版，目前处于公开预览阶段。通过移除虚拟化层，AKS 现在可以直接访问 NVLink"、RDMA" 和高性能网络等技术，这些能力对于大语言模型训练、低延迟敏感型推理任务而言，正变得愈发关键。

微软认为，虽然虚拟化提供了灵活性，但某些 AI 工作负载会因额外的抽象层而产生可量化的性能损失。裸金属 AKS 旨在兼顾两者优势：既保有 Kubernetes 统一规范的运维能力，又能释放专用硬件的原生极致性能。当下企业普遍训练规模更大的 AI 模型、部署资源需求持续走高的推理业务，即便小幅提升运行效率，也能大幅缩减成本。

微软同时宣布，适用于启用了 Arc 的集群的 Azure Kubernetes Fleet Manager 正式可用，集群舰队全域管理能力不再局限于 Azure 云平台，现已扩展到混合云和多云环境。

舰队管理器不再将 Kubernetes 集群视为孤立的系统，可在整个集群舰队中进行集中式策略执行、工作负载调度、分阶段发布和 RBAC 权限治理。随着企业在多区域、云提供商和本地环境中部署 AI 应用，同时又追求统一的运维标准与治理管控，这项能力的重要性也随之不断提升。

微软大力推进舰队管理，折射出行业的一个逐渐形成的共识：Kubernetes 的成熟度不在于运维单个集群，而在于将整个集群资产作为统一平台进行管理。在整体开源生态与 Kubernetes 发展战略中，微软也正持续围绕这一理念打造 AKS 产品体系。

除了 Kubernetes 基础设施，微软还宣布了几项以 AI 为中心的功能，旨在简化模型训练和推理。

目前处于公开预览阶段的 Azure 托管 Anyscale 服务，将托管版 Ray 框架接入 AKS，让企业能够使用跨动态扩展集群的 CPU 和 GPU 编排分布式 AI 工作负载。该服务直接集成到 Azure 订阅和治理模型中，使企业能够训练和部署大型 AI 模型，而无需独立管理 Ray 集群的复杂性。

微软还重点介绍了 AI Runway，这是一款原生基于 Kubernetes 的模型部署框架，于 2026 年初首次发布。AI Runway 让用户能够通过 Kubernetes 原生抽象选择模型、验证 GPU 需求、估算部署成本并启动生产端点。底层由 KAITO 完成资源调度、启动 vLLM 等优化推理运行时，同时对接 Kubernetes 自动扩缩容组件与 KEDA、网关 API 等网络相关技术。

由此打造出的模型服务平台在简化 AI 部署流程的同时不会屏蔽底层 Kubernetes 基础原语，平台工程师仍可使用这些原语保持控制能力和可观测性。

在微软的这些公告发布之际，各大云厂商为成为 AI 基础设施首选平台正激烈角逐。亚马逊云科技继续通过 EKS" 和 Bedrock" 扩展其 Kubernetes 和 AI 服务，而谷歌云则在 GKE" 和 AI 原生基础设施方面大力投入。与此同时，围绕 Ray、vLLM"、KubeRay" 和 Gateway API" 的开源生态系统也在迅速成熟。

微软方案的差异化核心在于：它试图将各类组件整合为一套完整统一的平台。微软并未从零搭建完全封闭的专属 AI 基础设施，而是深度依赖 Kubernetes、Ray、网关 API、云原生网络等开源技术，同时将其与托管服务、治理功能和企业集成相结合。

这一战略与行业一个内日益形成的共识相契合：AI 基础设施的演进将复刻云原生计算——随着 AI 从实验阶段进入主流生产环境，开放标准和共享运维模式将比专有编排系统变得更加重要。

微软在 Build 大会发布的一系列产品传递出一个核心观点：AI 是否适合运行在 Kubernetes 之上，这个问题已有定论。行业当下的挑战已变成如何在平衡成本、性能和可扩展性的同时，可靠地运营 AI 工作负载。

查看英文原文：https://www.infoq.com/news/2026/06/microsoft-build-aks-ai/"

交易、分析不用二选一，TDSQL HTAP 能力如何支撑实时业务？

凌敏 — Mon, 29 Jun 2026 07:45:45 GMT

交易、分析不用二选一，TDSQL HTAP 能力如何支撑实时业务？

扫码添加企微小助手，一键加入开发者专属企微群，即可免费获取讲师 PPT，助力学习高效进阶！

收购仅一年即“决裂”！创始人贾扬清出走英伟达：黄仁勋不满运营效果，20 亿美金的 AI Infra 突围为何折戟？

四月 — Mon, 29 Jun 2026 07:29:45 GMT

据半导体调研机构 SemiAnalysis 爆料，LeptonAI 的创始人兼 CEO 、英伟达系统软件副总裁贾扬清，已从英伟达离职。距离黄仁勋豪掷 7 亿美元，收购这家仅有 20 人的创业团队，才刚刚过去一年。

更耐人寻味的是，就在本月初，GPU 云服务商 Hyperbolic 宣布聘请贾扬清担任公司顾问。Hyperbolic 在公告中称，贾扬清将为其在 AI 系统、云基础设施、GPU marketplace、多云编排和 GPU 利用率提升等方向提供经验支持。这在业务层，与其在英伟达负责的DGX Lepton平台高度相似。

笔者对此向贾扬清本人求证离职消息，截止发稿前暂无正面回应。目前贾扬清社交平台 x、领英的就职信息仍停留在英伟达阶段。

对于离职原因，SemiAnalysis 直言，DGX Lepton 的运营效果不及黄仁勋预期；但更深层的原因还涉及，黄仁勋与贾扬清在项目开源承诺的分歧、产品落地执行力等层面的问题。

Caffe、PyTorch、ONNX 的缔造者，上一代 AI 框架公认的奠基人。连人带团队 7 亿美金被英伟达收编，原本是一段软硬融合的佳话，为何短短一年就分道扬镳？

细究下来，在这个戏剧性的转折背后，还藏着两个强烈的行业信号：

第一，GPU 可以靠稀缺性卖断货，但 AI Infra 却无法实现垄断。当英伟达作为硬件霸主试图向上层软件扩张时，遇到的阻力，比造 GPU 还大。

第二，当 AI 已经能自己写代码、管集群，那些以“降低工程门槛”为卖点的中间件平台，正在面临被直接被取代的价值危机。

贾扬清交付的筹码

2025 年 4 月，英伟达正式完成收购，随即将 LeptonAI 更名为 DGX Cloud Lepton，并于当年 6 月重新对外发布。

表面上看，这是一次软件能力的补强。但如果联系英伟达当时的战略处境，就会发现这笔收购的野心远不止于此。加上此前收购的AI 基础设施编排和工作负载管理平台 Run:ai 约 12 亿美元，英伟达先后在 GPU 云软件栈上的总投入将近 20 亿美元。

过去两年，英伟达是 AI 时代最大的“卖铲人”，但这还不够。黄仁勋不仅想让大家买它的卡、用它的 CUDA、接它的软件栈，还希望把全球 GPU 资源变成一个统一入口。

简单来说，就是从 AWS、Azure、阿里这些客户手里再分一杯羹：在云厂商之上，再建一层属于自己的软件平台。让开发者不再到处问“哪里还有 H100”，而是直接在英伟达的平台上找卡、租卡、部署模型。

而贾扬清，就是这个计划最完美的代言人。

对华人开发者来说，贾扬清曾一度被视为 AI 领域的大神，并长期推崇践行开源精神。

2013 年，还在 UC Berkeley 读博士的他，写出了 Caffe——第一个被工业界大规模采用的深度学习框架。它奠定了"模型即配置文件"的工程范式，让深度学习第一次真正走出了实验室。

2016 年他加入 Meta，联合微软推出 ONNX，主导 PyTorch 1.0，今天几乎所有主流 AI 模型都跑在 PyTorch 上；三年后，他以技术副总裁的头衔加入阿里，主导大规模 AI 基础设施建设，积攒了生产环境运营 GPU 集群的一手经验。

2023 年贾扬清离职创业，与同样来自 Meta AI 的白俊杰联合创立 LeptonAI，拿到了 1100 万美元种子轮融资，承载的正是“降低 AI 工程师使用和管理 GPU 集群门槛”的想象力。

三大开源框架、两家顶级大厂、一段中国市场经历——这是贾扬清带给英伟达的筹码。英伟达买下的，也不只是 Lepton 这家创业公司，还有 AI 开源社区对于贾扬清长达十年信任积累。

黄仁勋给出了足够的诚意和价格，贾扬清也带着将 AI Infra 推向新高度的抱负入局。这本该是一场完美的双向奔赴，但遗憾的是，在商业变现与开源信仰的碰撞下，双方最终没能走向共同的愿景。

三道无法弥合的裂缝

从万众瞩目到创始人出走，仅仅一年。据 SemiAnalysis 拆解，问题主要出在三道裂缝上。

第一道裂缝，是开源信仰的破灭。

英伟达在收购时承诺，Lepton 的核心软件平台将于 2026 年开源。这个承诺，对贾扬清而言绝不是一个可有可无的细节——他的整个职业生涯，都建立在开源精神之上。Caffe 开源，ONNX 开源，PyTorch 开源。他不是一个偶尔拥抱开源的工程师，他是那个用开源重塑了整个 AI 工程基础设施的人。

然而这个承诺，至今没有兑现。

SemiAnalysis 的推断是：黄仁勋最终改变了主意，否决了开源计划。对于一个把开源视为信仰的创始人而言，这不是产品路线的分歧，而是根本性的价值观冲突。

回顾英伟达的开源记录：NIMs 名义开放实则封闭，flashinfer 也从开源社区项目变为闭源 cubin 内核，RIVA 等 ML 平台也走向了类似命运。贾扬清对此不可能没有预判，但他或许仍抱有改变的希望。直到希望落空。

第二道裂缝，是产品执行的跑偏。

SemiAnalysis 的措辞相当直接："NVIDIA's product management culture did not let Lepton bloom into what it could have become."（英伟达的产品管理文化，没能让 Lepton 开花结果。）

实际情况令人唏嘘：团队的资源被消耗在更换配色方案和登录界面 UI 等表面工作上，而真正的核心技术问题，比如多租户（multi-tenancy）始终没有被解决。某云厂商（合作方）更是直言不讳："Lepton 解决了 GPU 云的所有问题，除了最难的那个。"

要知道，AI 原生开发者历来不愿为英伟达的非关键路径软件付费。他们信任的是 vLLM、SGLang、SLURM 这些从开源社区里长出来的工具链，而不是某个大公司包装过的 SaaS 平台。

Lepton/DGX Lepton 的目标用户，恰恰是对这类产品最挑剔的一群人。

第三个裂缝，写在股权结构里。

一般来说，标准的收购协议中，创始人股权通常分 3 到 4 年归属。贾扬清仅一年便离职，这也意味着：要么他放弃了大量未归属的股权，要么他在谈判时就争取到了一年内完全归属的特殊条款。

无论哪种情况，都说明他离开的决心极为坚定。这不是一次被动的人事调整，而是一次主动的、彻底的告别。

据早期信息显示，Lepton 平台在 2025 年中期前后已基本停止对外运营。

Agentic Coding 的降维打击

如果说价值观冲突和产品跑偏是内部问题，那么外部的模型发展和市场走向，则动摇了整个 AI Infra 赛道的价值结构。

LeptonAI 当初试图解决的，是一个真实存在的痛点：降低 AI 工程师使用和管理 GPU 集群的门槛。开发者不想管 Kubernetes，不想写部署脚本，不想折腾推理服务，不想处理扩缩容、监控和日志……这些事情繁琐、专业、耗时。所以，一个把这些复杂性打包起来的运维平台，可以让开发者专注于模型本身。

2023 年，这是一个值得花数亿美元去解决的问题。但到了 2026 年，这个问题的门槛和解法已经松动。

以 Cursor、Claude Code、Codex 为代表的 Agentic Coding 工具正在重塑软件开发的底层逻辑。"Vibe-coding"不再是一个噱头——开发者可以用自然语言描述需求，AI Agent 自动生成、调试、部署完整的基础设施代码。

比如，竞争对手AMD 开源的 Spur 项目，一个与高性能计算调度器 Slurm 完全兼容的开源替代品，可以直接被 AI Agent 调用和配置，几乎零门槛。

这意味着什么？

Lepton 试图用产品化方式解决的问题，正在被 Agentic Coding 用代码生成的方式直接跳过。当你的平台仅仅是把部署流程包装得更顺滑，把一些常见操作自动化，把 API 封得更漂亮，那么 Agentic Coding 的崛起会削弱它的稀缺性。

因为开发者会越来越有能力用开源组件拼出自己的工作流，用 Agent 修配置、写出集群管理脚本、接监控、改 SDK、迁移部署环境。

这不是 Lepton 一家的困境，而是整个"AI 基础设施抽象层"赛道正在面临的系统性挑战。

那些在 2022 年到 2024 年间以"降低 AI 工程门槛"为卖点融资的公司，都需要重新回答一个更尖锐的问题：你到底解决的是表层的复杂性，还是底层的稀缺性？

AI 正在重写应用开发，Vue 与 Vite，给出新的答

作者：因球 — Mon, 29 Jun 2026 07:09:02 GMT

AI 不只是补全代码——它开始读项目、改文件、跑命令、搭界面、一句指令上线整个应用。

当 AI 进入真实工程流程，一个更现实的问题随之浮现：框架、工具链、部署平台和开发体验，应该如何被重新设计？

Vue&ViteConf 2026 将于 7 月 18 日在上海举办，购票地址：https://vueconf.cn（拼团群二维码见评论区：360元/张）

VoidZero 创始人 & CEO、Vue.js 与 Vite 作者 Evan You（尤雨溪）将出席并发表主题演讲。这一次，我们不只谈 Vue 和 Vite 的今天——也要一起看见它们在 AI 时代的下一站。

Vue 与 Vite：正在连成一条完整的路径

Vite 曾经的标签是"快"。但今天的 Vite 生态，已经远不止于此。

Rolldown、Oxc、Vitest、Vite Task、Vite+、Void——这些工具正在形成一条完整路径：从创建项目、启动开发，到检查、测试、构建、缓存优化，再到云端部署与 AI Agent 协作。

Void 将数据库、KV 存储、AI 推理、身份验证等能力开箱即用，内置 Skills 与 MCP 支持，让 Coding Agent 能通过自然语言指令自动搭建并上线完整应用。

Vite+ 则用一个全局命令 vp 加一个 vite.config.ts，覆盖从创建到部署的完整工具链——不只给人用，也给 AI Agent 用。

工具越统一，AI 越容易理解项目。流程越清晰，自动化越不容易失控。

四条主线，一场密集的现场答案

本次大会目前已确认 11 位嘉宾，围绕四条主线展开：

一、Vue 与 Vite 核心生态的演进

从 Evan You 的主题演讲，到 Edison 深入拆解 Vapor Mode 的 Block 机制与细粒度更新，再到 shulaoda 分享 Rolldown 与 Vite 的内存优化实践，王驰带来 Vite Task 缓存机制的底层实现——你会看到这条生态链正在如何继续向前走。

工具链的进步不在口号里。它藏在一次缓存命中里，藏在每天被省下来的几分钟里。

二、Vite 生态落地：从小程序到超级应用

应用规模有两个方向的挑战：做精，和做大。

杨启明带来 Weapp-vite 的实战分享——如何用 Rolldown、Vite 与 Vue 重构小程序开发体验，结合 MCP、Skills 与截图验收工具，展示小程序工程化在 AI 时代的新可能。

小程序不该只是"能跑就行"。规模再往上走，又是另一道题。

Zephyr Cloud 平台工程师、模块联邦生态核心贡献者 Néstor López，将展示如何用 Nuxt 结合模块联邦，让多个应用、多条业务线无缝共生于同一个宿主基座——各自独立部署，整体浑然一体。微服务重塑了后端，微前端正在对前端做同样的事。

三、AI Agent 与开发者工具

Neko 与 RainbowBird 将分享如何用 Velin 让 Prompt 从字符串变成结构化代码，用 Vieval 让 Agent Benchmark 像日常测试一样自然发生。

DeepChat 作者夕阳针将复盘一个 Vue 开发者构建 Agent Client 的真实路径。

Simon He 则以 markstream-vue 为例，讲清楚流式 Markdown 渲染在 AI 产品里的真实挑战。

AI 应用不只是模型重要。模型生成的内容，终究要落进界面——而界面稳不稳，用户一眼就能看见。

四、Vue 的边界扩展：走向 Native

字节 Lynx 架构师、前 Meta React 团队成员黄玄（Hux）将带来"Vue + Lynx = Vue Native"的现场探索——当 AI 开始降低工程体量的阻碍，这件事终于不再只是愿景。

为什么要来现场？

这不是一次只谈框架和工具更新的聚会。

它把几条正在同时发生的变化放到了一起：核心生态演进、真实场景落地、AI Agent 重塑工程流程、Vue 走向更多运行环境。单独看是技术议题，放在一起，就是下一代应用开发方式的变化。

如果你关心 Vue、Vite、AI Agent、全栈部署、开发者工具链、小程序工程化，或者你正在思考 AI 时代如何更好地构建应用——这场大会值得你来到现场。

7 月 18 日，我们不见不散！

InfoQ 推荐

Cloudflare 推出支持零信任部署和迁移的代理技能

在企业内部构建欧洲云编排平台

8 人起家年入上亿美元，推出自研大模型对战 Cursor、Claude Code？

网易有道CEO周枫：Harness即产品

1. 面向下一代模型能力设计产品

2. 要做高智能产品

3. 有价值的Agent产品，往往消耗较多tokens

4. 把上下文工程当成主任务

5. 工具是给模型看的产品界面

6. 用评测驱动开发

7. 默认从单Agent开始

小结：你迭代的产品，就是Harness

Arm 计算平台加持，联想车计算推动 L4 级自动驾驶出租车规模化落地

探秘联想 AD1

效率、安全性及物理 AI 的基石

Arm 构筑自动驾驶之路

物理 AI 演进之路：从受控环境走向现实世界

现实中的物理 AI

新一代人形机器人

四足机器人与工业机器人

自动驾驶汽车与移动出行平台

智能系统的组成模块

以高效、可扩展的计算能力赋能物理 AI

引领智能机器未来发展

Cursor、OpenClaw 同时出手，“口袋编程”时代来了：程序员只用“动嘴”！

打通桌面工作流，可直接口述提示词

向付费用户开放公测，长期目标：云端智能体与本地开发“无差别”

移动编程可达性的新时代

Anthropic 负责人：HTML 比 MD 更利于人类跟进智能体协作流程

Google OpenRL 是一个用于大型语言模型（LLM）后训练微调的实验性自托管 API

3000块钱，这支中国团队把ChatGPT成功的“秘密”用在了机器人训练上

毫米级精度的数采，成本怎么压到千元级？

完全对外开放，“开源是勇敢者的游戏”

新的模型范式，很快就会出现

Snowflake 语义模型与视图构建指南：最佳实践及避坑红黑榜 ｜ 技术实践

为什么 Semantic View 在 Snowflake 中很重要？

提升效果的关键最佳实践

DOs 和 DON’Ts

DOs✅：

DON’Ts❌：

结论

AI 接进企业之后，API 安全开始成为新盲区

从 VCloud 到 Agentic VCloud：Agent 时代的范式重构

从 VCloud 到 Agentic VCloud

如何重构出 Agentic VCloud

从比拼视频体验到比拼Agent落地

AWS 为 Cognito 增加多区域故障切换能力

Agent 狂吞 Token，表面是模型之争，底层全是煤电博弈

AI 开始进入算账阶段

如何真正降低 Token 成本？

Token 需求不会只是一次热闹

AI发展最大瓶颈：物理基础设施跟不上

做中立的 Token 供应商

Atlassian 揭秘 Forge 计费架构：如何在分布式环境下实现大规模用量计费

非科班出身技术Geek，被DeepSeek改写人生（上集）

不要将租户隔离托付给LLM！如何在 Snowflake 上正确打造多租户 Cortex Agent ｜ 技术实践

摘要

三种访问场景

场景一：共享访问（Service User）

场景二：Snowflake 中的按用户身份访问

场景三：按租户访问（访问者没有 Snowflake 身份）

Pattern A: User-per-Tenant

Pattern B: Role-per-Tenant

Pattern C: Tenant Session Attribute

将租户映射到数据值：Entitlement Tables

连接池 + Session Attributes：一种混合模式

总结

AI 正在向软件生命周期的上游延伸：从代码审查到产品需求文档（PRD）治理

超越 CLEAN 和 MVP：在 Android 中构建离线优先的响应式数据层

前言

传统模式的局限性

1. MVP 架构的拉取瓶颈

2. CLEAN 架构在移动端的错位

RDLA 简介

架构拓扑

RDLA 在架构生态中的定位：与 Clean 和 MVVM 相融合

RDLA 如何与 Clean 架构融合

RDLA 如何驱动 MVVM（单向数据流）

RDLA 实践：健康指标追踪系统

Snowflake 语义模型与视图构建指南：最佳实践及避坑红黑榜｜技术实践

不要将租户隔离托付给LLM！如何在 Snowflake 上正确打造多租户 Cortex Agent ｜技术实践