InfoQ 推荐

ChatGPT 可以帮你理财了，但它也知道你的全部余额！用户：谢谢不用了

李冬梅 — Sat, 16 May 2026 09:00:00 GMT

ChatGPT 可以帮你理财了，但也用你的数据训练模型

昨晚，OpenAI正式面向美国地区的ChatGPT Pro用户推出全新个人理财体验预览版。

该功能允许用户安全连接个人金融账户，通过专属仪表盘查看资金流向，并结合自身财务状况向ChatGPT提出个性化咨询，全程由用户掌控核心信息，目前仅面向小部分用户试点，后续将逐步优化扩展。

OpenAI 表示，与关联金融账户的对话将遵循与常规 ChatGPT 相同的模型训练设置。这意味着，除非用户选择退出，否则 OpenAI 可以将这些对话用作训练数据。

OpenAI表示，金钱深刻影响着人们生活的方方面面，从居住选择、家庭照料到未来规划，都与财务状况紧密相关。但当前理财场景中，用户往往需要整合多个账户、应用程序、信用卡及贷款信息，甚至借助电子表格汇总，才能勉强掌握自身财务全貌，后续的规划决策更是无从下手。

所以新推出的个人理财功能，其核心亮点在于将GPT-5.5的推理能力与用户实际财务状况、个人目标、生活方式及优先级相结合，帮助用户发现财务规律、权衡决策利弊，提供更具个性化和全面性的财务规划建议。用户可通过该功能咨询各类具体财务问题，例如消费变化分析、中长期储蓄计划制定等，但OpenAI明确提示，该功能仅提供信息参考，不能取代专业财务建议。

OpenAI 举了一些具体的例子：

这款个人理财助手可以帮你规划支出，比如想在5年内买套房子，就可以询问它的建议了。

不知道一趟旅行到底花了多少钱？它可以给你出一份清晰的账单。

再比如最近支出太多了，让它帮你看看哪里可以省下来。

还可以帮你在财务上设定某种假设，比如以我现在的经济状况，我能否找一份更低薪水的工作，让我有更多时间和自由陪伴孩子？

甚至连日常生活中的投资风险也会给你做出预警。

也能帮你审查你的哪些订阅服务是花了冤枉钱。

据统计，每月已有超过2亿用户通过ChatGPT进行预算规划、投资咨询、投资路径对比及未来财务目标规划等操作。而GPT-5.5模型的最新进展，进一步提升了ChatGPT处理个人理财领域复杂、上下文相关问题的能力，为此次新功能推出奠定了技术基础。

据悉，该理财功能目前已在ChatGPT网页版和iOS版同步上线，仅对美国Pro用户开放，支持超过12000家金融机构的账户连接。

OpenAI计划根据早期用户的使用反馈持续优化体验，后续将逐步推广至Plus用户，最终实现所有用户均可使用的目标。

这一功能的推出，距离OpenAI今年4月收购个人理财初创公司Hiro的团队仅一个月时间，Hiro团队的金融专业知识为该功能的研发提供了支持。

与同类产品有何不同？

那么，ChatGPT的新功能与目前现有的预算平台（例如 Rocket Money 和 Monarch）有何不同？

一句话概括起来，就是——ChatGPT 会记住用户的重要信息，并在回答问题时牢记这些信息，但不会进行任何操作。

OpenAI 产品经理 Ty Geri 在一次简报会上表示，这些新功能将有助于“将您的个人财务状况与更广泛的个人生活状况联系起来”。

Geri说，如果你让ChatGPT帮你找出不需要的订阅服务，这个助手会利用它已有的关于你的信息来给出建议。

在简报中，OpenAI强调ChatGPT仅拥有读取用户财务信息的权限，它只能分析数据，而不能实际操作用户的资金，例如进行投资或取消订阅。这些操作仍然需要用户自行完成。

那该怎么使用呢？

据 OpenAI 介绍，开启这一理财体验的操作十分便捷。用户可从ChatGPT侧边栏打开“财务”选项并选择“开始使用”，也可在对话任意位置输入“@Finances，连接我的账户”启动流程。ChatGPT会引导用户通过Plaid平台安全关联金融账户，Intuit平台的支持将在后续推出。完成身份验证后，系统将同步并分类用户财务数据，整个过程约需几分钟。

该公司在新闻稿中表示，ChatGPT 将能够“访问用户的余额、交易记录、投资和负债，以帮助用户更直观地了解财务状况或解答您的疑问”。

账户同步完成后，用户可通过专属仪表盘，实时查看投资组合表现、支出明细、订阅服务及即将到期的付款等核心财务信息。

除关联账户外，用户还可主动分享房贷、储蓄目标、计划大额消费等个性化财务信息，这些内容将被保存至“财务记忆”中，为后续对话提供参考，让ChatGPT能够结合账户数据与用户需求，提供更具针对性的指导。

为实现“从解答到行动”的理财服务闭环，OpenAI正与Intuit等生态系统合作伙伴携手。依托Intuit的技术支持，用户可在ChatGPT平台内完成从信用卡推荐、审批概率查询到申请提交，从股票出售税务影响咨询、税务估算到预约当地税务专家实时咨询等一系列操作，实现财务咨询与实际行动的无缝衔接。

针对财务数据的隐私与安全问题，OpenAI作出明确承诺，将用户掌控权放在首位。关联账户后，ChatGPT仅能访问用户的账户余额、交易记录、投资及负债信息，无法查看完整账号，也不能对账户进行任何操作。

为了进一步解释其安全性，OpenAI还表示，用户可随时通过“设置”>“应用”>“财务”或“财务”页面断开账户连接，断开后同步的账户数据将在30天内从OpenAI系统中删除，且不影响对话历史中的财务信息，用户也可单独删除相关对话。

同时，用户可在“财务”页面查看或删除“财务记忆”中的内容；使用临时聊天功能时，ChatGPT不会访问关联的金融账户，且临时聊天记录不会留存。此外，用户可启用多重身份验证（MFA），进一步提升账户安全性。

为确保理财建议的准确性和质量，与关联金融账户相关的对话默认使用GPT-5.5 Thinking模型——OpenAI最新的推理模型。OpenAI还建立了内部评估基准，联合来自领先机构的50多位金融专业人士，对ChatGPT在复杂个人理财任务中的表现进行全面评估。

最后，OpenAI 还强调了这项新功能背后支撑的模型是其最先进的GPT-5.5 Thinking模型。

评估结果显示，GPT-5.5 Thinking在复杂理财任务中的表现优于前代模型，其中适用于ChatGPT Pro用户的GPT-5.5 Pro模型表现最佳。

在针对挑战性财务任务的个人理财基准测试中，GPT-5.5 Thinking得分为79分（满分100分），GPT-5.5 Pro得分为82.5分（满分100分），该得分是专家对回答质量和准确率的加权综合评分。

你会让 ChatGPT 管理你的钱包吗？

ChatGPT 推出个人理财功能后，围绕“让 AI 接管钱包”这件事，互联网很快分裂成了两派。

一派的第一反应几乎是本能的警惕。有人直言：“把银行账户权限交给 AI，这件事在我看来太疯狂了。谢谢，不必。有些数据就应该永远保持私密。”

在他们看来，聊天记录、搜索偏好、日常习惯已经足够让平台勾勒出用户画像，而一旦金融账户被打通，AI 掌握的将不只是兴趣偏好，而是一个人最核心的资产流向、消费结构甚至风险承受能力。对不少人而言，这已经越过了技术便利的边界，进入了隐私不可退让的禁区。

还有用户晒出了他与ChatGPT的对话截图，他询问ChatGPT：即使号称“安全”，把所有的财务数据实时访问权限交给 OpenAI 是个好主意吗？

ChatGPT答道：“从纯粹的风险管理角度来看，任何能够持续访问你完整财务生活的系统，都不应该在绝对意义上被视为‘安全’。”

另一种更现实的担忧则聚焦在责任归属上。

有人评论说，个人理财 AI 技术本身并没有问题，真正的问题在于：如果某天用户醒来，发现自己的 AI 助手在一夜之间擅自开通了六项流媒体订阅服务，甚至自动完成了付款，那么责任该由谁承担？是平台算法的问题，是模型判断失误，还是用户在授权时默认接受了风险？当 AI 不再只是提供建议，而是直接连接银行账户并代替用户执行操作，现有的责任认定机制几乎无法覆盖这种新型场景。

换句话说，技术已经先一步冲进现实，但规则体系还远远没有跟上。

这种担忧甚至让一些人进一步推演出了行业冲击。有人直接断言：“所有 AI 金融科技创业公司都要完蛋了。”

这很好理解，如果像 ChatGPT 这样的平台型产品开始切入个人理财，原本依赖“帮用户管钱”“帮用户做预算”“帮用户做消费规划”作为卖点的 AI FinTech 创业公司，护城河将被迅速稀释。毕竟在大模型时代，用户很可能更倾向于把金融权限交给一个自己已经日常使用的超级入口，而不是再额外下载一个垂直工具。

但支持者的声音同样强烈，而且他们给出的理由非常鲜明：年轻一代根本没有那么在意隐私。

有人指出，许多人并没有真正理解这一代消费互联网用户的变化。

对 Z 世代乃至更年轻的用户来说，数据隐私的重要性正在让位于即时价值。只要产品确实能解决问题，他们愿意交出银行账户权限、通讯录、邮箱访问权，甚至手机相册。隐私在他们那里不是绝对原则，而是一种可以交换的资源——只要交换来的体验足够丝滑、效率足够高。

这种态度甚至被一些年轻用户说得更直接。有人坦言：“也许是因为我骨子里就是 Z 世代，但我真的已经不在乎隐私了。我早就过了纠结隐私的阶段。我把所有财务信息、健康数据，几乎所有东西都给了 OpenAI 访问权限，我无所谓。”

这或许才是这场争议真正值得关注的地方。表面上看，这只是一次关于 ChatGPT 新功能的讨论；更深层次上，它折射出的其实是两种数字时代价值观的碰撞：一代人坚持“数据属于个人，绝不能轻易让渡”；另一代人则认为“隐私本质上是效率的成本，只要收益足够高，交换完全合理”。

而当大语言模型开始从回答问题、生成内容，进一步延伸到管理用户资产、理解消费习惯、甚至替用户直接作出财务决策时，一个更尖锐的问题已经摆在所有人面前：当 AI 开始窥探你的钱包，人类究竟是在获得更聪明的助手，还是正在主动交出你的全部身家？

参考链接：

https://openai.com/index/personal-finance-chatgpt/"

https://www.inc.com/ben-sherry/chatgpt-wants-your-bank-account-info-heres-why-you-may-actually-want-to-share-it/91345488"

https://x.com/ChatGPTapp/status/2055317612687675545"

记忆感知的大模型 KVCache 优化｜AICon上海

AICon 全球人工智能开发与应用大会 — Sat, 16 May 2026 02:00:00 GMT

当前，以 Agent 为核心的新一轮技术浪潮正在席卷产业。那么，世界模型的下一个突破在哪？Agent 从 Demo 到工程化还差什么？研发体系不重构，还能撑多久？

6月26日-6月27日，AICon全球人工智能开发与应用大会"将在上海举办。本次大会将围绕以上问题，邀请来自腾讯、阿里、快手、华为、飞猪等50+头部企业的技术负责人、高校与科研机构的一线专家，分享 Agent 在真实生产环境中的落地经验与前瞻思考。深入探讨 Agent 从原型到量产的工程挑战、数据与记忆的基础设施底座、安全可信的落地保障，以及大模型推理优化、智算架构升级等关键命题。

阿里云高级技术专家马腾已确认出席 “大模型推理优化"” 专题，并发表题为《记忆感知的大模型 KVCache 优化"》的主题分享。本次分享重点介绍以 KVCache 为中心的开源大模型服务框架——Mooncake。将大模型推理引擎中的 KVCache 视作智能体系统最核心的“物理工作记忆”载体。通过打破传统推理中计算与存储的强耦合，Mooncake 实现了 Prefill 与 Decode 的分离式架构，并构建了全局共享的 KVCache 池。这种设计使得多智能体在频繁交互与协同工作时，能够通过跨节点的底层张量零拷贝与高效复用，实现记忆的“一次计算、全局共享”。

马腾，阿里云高级技术专家，在阿里云主要大模型软件栈在新硬件环境下国产化的研究工作，并共同创建了大模型开源项目 Mooncake（5K Star）。目前 Mooncake 已经有阿里云 / 清华 / 月之暗面 / 蚂蚁 / 字节 / 趋境科技等多方参与，并且成功接入 vLLM/SGLang/LMDeploy/LMCache 等社区。同时他也是 SGLang, RBG 等社区的 Committer。他在 SOSP, ASPLOS, ATC, SC, INFOCOM, VLDB, TPDS 等顶级会议和期刊上发表论文二十余篇，相关成果授权美国 / 中国专利 10 项。他曾入选 CCF 系统软件专委会优秀博士论文激励计划，担任 PPoPP, FAST, DASFAA, TPDS, ICME, TC, JSC 等国际会议 / 期刊的程序委员会成员和审稿人。他在本次会议的详细演讲内容如下：

演讲提纲：多智能体时代的记忆挑战从单一对话到多智能体协作的演进趋势Agent Memory 的构成：系统提示词、工具描述、多轮交互历史、智能体间状态传递当前推理架构的瓶颈：重复 Prefill 计算、显存碎片化与端到端延迟核心视角：KVCache 作为智能体的"物理工作记忆"重新定义 KVCache 的角色——从推理缓存到记忆载体"一次计算、全局共享"的设计目标Mooncake：以 KVCache 为中心的开源推理服务框架Prefill 与 Decode 分离式架构（Disaggregated Architecture）全局共享 KVCache 池的构建跨节点张量零拷贝与高效复用机制多智能体落地的底层技术挑战基于记忆感知（Memory-aware）的请求调度与路由策略长短记忆在物理显存中的动态分层与淘汰机制（Eviction）高并发场景下的吞吐极限优化总结与展望Agent Memory 需要下沉至物理推理基础设施通过底层"记忆流转"释放算力与智能潜能听众收益：了解记忆系统和KVCache的无缝结合了解如何通过推理优化，显著提升Agent性能

除此之外，本次大会还策划了端侧 AI、物理与数字空间智能化"、世界模型与多模态智能突破"、Agent 架构与工程化实践"、Agent 安全与可信治理"、企业级研发体系重构"、AI 原生数据工程"、AI 时代的个人提效与组织变革"等14个专题论坛，届时将有来自不同行业、不同领域、不同企业的50+资深专家在现场带来前沿技术洞察和一线实践经验。

更多详情可扫码或联系票务经理 13269078023 进行咨询。

Kubernetes v1.36 发布：安全默认配置强化，AI 工作负载支持日趋成熟

作者：Matt Saunders — Fri, 15 May 2026 12:00:00 GMT

Kubernetes" 发布 1.36 版本"，代号 Haru，这是 2026 年的首个重要版本。该版本包含 70 项增强功能：18 项进入 Stable 阶段，25 项进入 Beta 阶段，以及 25 项新的 Alpha 功能，重点聚焦安全加固、人工智能和机器学习工作负载，以及大规模 API 的可扩展性。由编辑 Chad M. Crowell、Kirti Goyal、Sophia Ugochukwu、Swathi Rao 和 Utkarsh Umre 撰写的发布博客将此次发布描述为“时节更迭、山巅光影流转”之时如约而至，共有 106 家公司和 491 位个人参与了贡献。

本次发布最亮眼的安全功能是用户命名空间（User Namespaces）正式达到 GA，该功能已经历多个版本周期的打磨。该功能可将容器内的 root 用户映射为主机上的非特权用户，即便进程突破容器隔离，也无法获取底层节点的管理权限。同样达到 GA 的还有可变准入策略（Mutating Admission Policies），允许团队借助通用表达式语言（CEL）把变更逻辑定义为原生 Kubernetes 对象，无需再单独维护独立的 Webhook 服务器。发布博客表示，这“为传统 Webhook 提供了原生、高性能的替代方案”，同时降低了“管理自定义准入 Webhook 带来的延迟与运维复杂度”。Kloia 官方博客"也对此做了详细解读并配有原理图示。

细粒度 Kubelet API 授权也在本版本中正式达到 GA。该功能于 v1.32 版本首次以 Alpha 状态引入，支持对 Kubelet HTTPS API 进行更精细的最小权限访问控制，替代了监控与可观测性工具以往所需的过度宽泛的 nodes/proxy 权限。SELinux 卷标签功能进入 Stable 阶段，通过 mount -o context=XYZ 选项替代递归文件重标记，在挂载时为整个卷统一配置正确的 SELinux 标签，以此降低开启 SELinux 强制模式环境下的 Pod 启动延迟。基于 validation-gen 的声明式验证、以及卷组快照（Volume Group Snapshots）——支持同时为多个持久卷声明（PersistentVolumeClaim）创建崩溃一致性快照——也均在本版本中达到 GA。

DRA 管理员访问以及动态资源分配的优先列表功能同样达到 GA，为集群管理员提供了一个固定框架用于全局访问和管理硬件资源，并保障资源选择逻辑在各类集群环境中保持统一。

v1.36 版本在人工智能与机器学习方面的优化主要体现在默认配置适配了日益增长的工作负载需求。ScaleOps 团队在文章"中表示，该版本“与其说是全新的机制，不如说是默认配置补齐了两年间沉淀的 AI 工作负载实践经验”。多项 DRA 增强功能进入测试阶段并默认开启：DRA 可分区设备、DRA 可消耗容量以及 DRA 设备污点与容忍，均无需手动配置特性门控即可启用。这些功能替代了传统的整数 GPU 设备插件模型——该模型不考虑实际资源利用率，直接将整张显卡整体分配——转而提供原生能力，适配现代加速器的分区、共享以及故障恢复机制。VMware Cloud Foundation 博客还提到，以往“申请复杂资源往往需要晦涩且厂商专属的配置模块，调度器也难以做优化调度”，而 v1.36 版本采用的标准化架构大幅降低了多节点 AI 部署的复杂度。

AI 工作负载方面重磅新增的 Alpha 功能是工作负载感知抢占（Workload-Aware Preemption）。在这项功能之前，调度器在为高优先级工作负载腾出空间时会抢占单个 Pod，容易出现分布式训练任务八个进程中七个都在运行，却始终无法正常推进的情况。新的机制将 PodGroup 视为一个整体抢占单元，只有在确认高优先级任务组确实能够容纳资源后才会执行驱逐操作。正如 Palark 团队"在版本解读文章中所说，该功能解决了分布式训练的“部分抢占故障模式”，这也是运行大型 GPU 任务的团队长期面临的痛点。Gang 调度 API 于 v1.35 版本以 Alpha 状态引入，在 v1.36 中正式进入 Beta 阶段。

暂停作业的 Pod 可变资源（Mutable Pod Resources for Suspended Jobs）功能也进入 Beta 状态，并默认启用。该功能允许队列控制器暂停正在运行的作业，调整其 CPU、内存、GPU 及扩展资源请求，适配集群当前可用容量，随后恢复作业运行，无需销毁并重新创建 Pod。Kloia 团队"表示，这省去了依赖自定义控制器或彻底终止、重启作业的操作，让工作负载队列系统能够根据集群实时状态进行灵活调度。

在 API 可扩展性方面，v1.36 版本引入了分片列表与分片监听流作为全新的 Alpha 功能。拥有大量控制器的大型集群常会遇到监听流瓶颈，原因是所有观察者都通过每种资源类型的单一连接接收更新。分片机制可将这类负载分摊到多个流中，Palark 团队"表示，这解决了“超大规模部署里监听流容易成为性能瓶颈的关键痛点”。

通过 cgroup v2 实现的内存服务质量（Memory QoS）在本版本中进入 Beta 阶段，提供了分层内存保护机制，能够更好地将内核控制与 Pod 的资源请求和限制相匹配，减少同一节点上各工作负载之间的资源争用。Pod 级资源原地垂直扩缩容（In-Place Vertical Scaling for Pod-Level Resources）同样进入 Beta 版本并默认启用，支持在不重启容器的前提下调整 Pod 级别的 CPU 和内存配额上限。新版本新增 ResizeDeferred 事件类型，当因节点容量不足无法立即执行扩缩容操作时，Pod 会继续按现有资源规格运行，待节点资源空闲后，Kubelet 将自动重试完成扩缩容。

计划进行版本升级的团队需要留意本版本中若干已移除的功能。gitRepo 卷插件自 v1.11 版本开始被废弃后，现已被彻底移除。该插件存在允许攻击者以 root 权限在节点上执行代码的漏洞，PerfectScale 团队"建议在升级前迁移至初始化容器或外部 git-sync 工具。Kube-proxy 中自 v1.35 版本开始废弃的 IPVS 模式也已正式移除。此外，kubeadm 中的 FlexVolume 支持以及 Portworx 内置驱动也在本版本中被移除，正如 Kloia 团队"在其升级指南中所说明的那样。

有一项早于本版本发布、但仍在 v1.36 官方博客中重点强调的重大运维变更是 Ingress NGINX 的正式退役"。Kubernetes SIG Network 与安全响应委员会已于 2026 年 3 月 24 日正式退役该项目。自当日起，项目不再进行任何版本发布、问题修复以及安全漏洞补丁推送。InfoQ 在 Kubernetes 1.35 版本报道"中梳理了 Kubernetes 网络生态的发展脉络，并指出 Ingress NGINX 只会“尽力维护至 2026 年 3 月”。

VMware Cloud Foundation 博客将本次版本置于更大的行业转变背景下：“Kubernetes 正从一个灵活的框架逐步转向拥有更标准化、更具强制性的默认安全与资源规范。”文章还提到，“跟进 Kubernetes 版本迭代已不再只是简单升级集群”，还涉及“管理生命周期复杂度、判断何时采用新版本、厘清变更对现有工作负载的影响，以及避免平台演进带来的业务中断”。

“通过采用更规范化的实现方式，Kubernetes 让调度器能够更清晰地识别 GPU 及 AI 加速器的专属资源需求，大幅降低了多节点 AI 部署的复杂度。” ——VMware Cloud Foundation 博客，Kubernetes 1.36：企业平台的实际变化"

完整的 Kubernetes 1.36 发布说明" 也已发布。

查看英文原文：https://www.infoq.com/news/2026/05/kubernetes-1-36-released/"

Anthropic 推出 Claude Platform on AWS

作者：Daniel Dominguez — Fri, 15 May 2026 10:12:00 GMT

Anthropic 已宣布 Claude Platform on AWS" 正式全面上线，这是一个全新的部署选项，让 AWS 客户能够使用 AWS 的身份验证、计费和监控服务直接访问 Anthropic 原生的 Claude 平台。该版本允许客户在继续使用 AWS IAM 凭证管理访问权限、并将使用量合并到现有 AWS 账单和承诺中的同时使用 Claude Platform" 的各项功能。

该服务包含对 Claude 完整 API" 功能集的访问权限，包括托管智能体（Managed Agent）、代码执行、网络搜索、提示词缓存、引用、批处理，以及 Skill 和 MCP 连接器等各类集成。Anthropic 表示，新的平台功能和测试版能力在原生 Claude API 发布的同时也会在 AWS 上同步推出。该服务还包括对 Claude Console 的访问，用于提示词测试、评估和开发工作流。

身份验证由 AWS IAM 负责处理，审计日志通过 CloudTrail 来记录，计费则通过标准 AWS 发票结算。Anthropic 自行运营该服务，这意味着客户数据会在 AWS 基础设施边界之外完成处理，这与通过 Amazon Bedrock 访问 Claude 模型的模式有所不同，后者由 AWS 作为数据处理方。Anthropic 的这项服务主要面向那些希望获得完整 Claude Platform 体验、同时继续使用 AWS 身份和采购系统的客户。

该平台目前以测试版形式提供 Claude Managed Agents"，可用于大规模部署智能体，同时还包含代码执行等功能，可直接在 API 调用中执行 Python 工作流和生成可视化图表。此外，它还支持用于可复用任务行为的 Skill、用于文档处理的 Files API，以及用于在执行过程中检索外部信息的网络搜索功能。Anthropic 表示，该平台支持全球和美国推理区域，后续将在大多数 AWS 商业区域陆续开放使用。

此次发布还重点强调了 Claude Platform on AWS 与 Claude on Amazon Bedrock 之间的差异。虽然 Bedrock 将客户数据完全保留在 AWS 托管的基础设施内，并提供 Guardrails 和 Knowledge Bases 等 AWS 原生服务，但 Claude Platform on AWS 优先提供 Anthropic 第一方工具的访问权限，并确保功能与原生 API 首日同步可用。

X" 平台上的社区反馈聚焦于 Claude 与现有 AWS 工作流之间更紧密的集成，特别是在身份验证和计费方面。AI 产品开发者 Sarah Yang" 发帖称：

企业级 AI 的采用将越来越不只是单纯选择哪一款模型，而更像是选择一个自身工作流程可依赖的运营生态系统。

还有多位用户指出了与 Anthropic 原生 API 保持功能一致性的重要性，计算机科学家 Anotida Msiiwa" 评论道：

相关功能在登陆原生 API 的当天便同步上线 AWS，解决了企业云服务普遍存在的功能滞后问题。

与其他云 AI 产品相比，该平台与微软的 Azure OpenAI" 服务和谷歌的 Vertex AI" 集成类似，企业客户可以通过现有的云基础设施和计费系统访问第三方基础模型。然而，Anthropic 的做法有所不同：Claude Platform 本身仍由 Anthropic 运营，仅将 AWS 作为身份验证和采购层，而非完全嵌入云供应商托管的 AI 技术栈中。

查看英文原文：https://www.infoq.com/news/2026/05/anthropic-claude-aws/"

百度想明白了：旧供给到达极限了

王一鹏 — Fri, 15 May 2026 09:45:28 GMT

今天大部分企业看待 Token 经济的心情十分复杂——一方面，Token 的价格已经打到了地板；另一方面，Agent 燃烧积分 /Token ，生产账单的速度仍然很快。尤其是当这些企业把 AI 从"偶尔试用"转向"业务系统集成"时，ROI 完全无法取得平衡，有的只是足够茂盛的焦虑。

参与 SWE-bench 编程评测基准的主流 Agent 系统技术报告显示（2025 年），完成一个标准编程任务，最先进的 Agent 系统平均需要调用 API 30 到 60 次，一次任务的成本在 0.07 到 0.75 美元之间。切换到实际开销，以当前最流行的 Agent 框架 Claude Code 为例，来自 Artificial Analysis 的数据显示，如果使用 GLM-5.1 模型，单次任务的 Token 成本高达 2 美元以上。

这还没有计算企业场景中的长期记忆、Skill，以及庞大上下文。

层层叠加，导致 Token 单价虽然降了 99%，但消耗量涨了 30 到 100 倍。诚如李彦宏在 2026 年 5 月 13 日举办的百度 Create 大会上所说：Token 只是代表成本，并不代表收益；它衡量的是投入，而不是产出。关注有多少 Agent 在给人类干活，并交付结果。这比无谓的 Token 消耗，更接近价值，也更接近本质。

除价格外的另一个问题是推理效率。2026 年 4 月，InfoQ 开展了一系列类龙虾产品的直播测试工作，我们惊讶的发现国产龙虾在用同一个模型，处理同一个任务时，推理耗时相差 10-20 倍，产出的结果却并无明显差异。

不得不怀疑，在 Agent 全面进入生产环境前，Agent Infra 已经迎来了结构性问题。

我仔细听完百度创始人李彦宏、百度集团执行副总裁沈抖在 5 月 13 日上午的全部发言，最终总结出一个信号：旧供给快要到达极限了，已经成为新物种的 AI 全栈云们，正在继续求变。

2025 年的 AI 云供给模式，正在改变

仔细数数，所谓的“旧供给”，其实也只有 1-2 年的“服役历史”。

沙利文在 2025 年曾发布中国全栈 AI 云服务市场报告，但核心主语是 AI。今天百度的升级可以总结为“新需求，新全栈，新供给”，核心主语是 Agent。

主语的变化，背后意味着背后的技术工作，最具代表性的领域即是 KV Cache（键值缓存）的命中率提升。

大模型推理过程中，每处理一个 token，都需要对整个上下文历史进行大量矩阵运算。KV Cache 把这些中间运算结果保存下来，避免每次都重新计算。在 Agent 时代，这个机制变成了系统性能的命脉——Agent 的多轮调用之间上下文高度重叠，如果 KV Cache 命中，就不需要重新推理整个上下文，速度和成本都会大幅改善。反之，对于一个调用 30-60 次的 Agent 任务，就是巨大的算力浪费。

大模型的定价机制从侧面印证了 KV Cache 的真实价值：Anthropic 对命中缓存的 token 提供 90% 折扣，OpenAI 提供 50% 折扣，Google 提供 90% 折扣。平台愿意对"已在缓存里的 token"让出如此高的折扣，本质上是在承认：缓存命中的 token，边际算力成本接近于零。命中率越高，平台成本越低，用户越有动力把更多调用留在同一个平台——这是 KV Cache 优化背后真正的商业逻辑，也是为什么各方都把 KV Cache 命中率当作核心竞争力指标来对待。

2023 年，加州大学伯克利分校在 arXiv 发表的论文率先解决了 KV Cache 的内存管理问题，将 GPU 显存浪费从 60-80% 降至不足 4%。这是当前几乎所有主流推理引擎的基础架构层。

2024 年 7 月，月之暗面（Kimi）在 arXiv 发表论文，系统描述了其以 KV Cache 为核心的生产架构。这是当时中国公开可查的、具代表性的系统性 KV Cache 生产架构技术论文之一。Mooncake 的核心数据显示，在相同硬件条件下，KV Cache 中心化架构实现了 525% 的吞吐量提升。

这些是正确方向上的真实进展。但为什么还不够？

一个可能的原因是，现有的 AI 供给体系——从推理引擎、调度框架到 GPU 集群的组织方式——都是按照"单次请求 - 单次响应"设计的。这套设计从根本上就没有为 Agent 的运行方式准备过。

KV Cache 命中率提升了，推理效率改善了。但 Agent 的运行不只是推理的问题，它还涉及：长上下文的跨请求持久化、子 Agent 的调度与协同、记忆系统的索引与管理、多模型协作的任务分发——现有的 AI 供给体系里，没有一套统一的架构来处理。

新的 AI 使用范式，新的全栈供给体系，是百度智能云在这次大会上真正要回应的真问题。

百度的全栈回答

"全栈"，很容易被当成营销语言，但在此处，它有具体的技术含义：在 Agent 时代，推理效率、调度框架、内存管理、硬件配置这几个层面是相互耦合的——单独优化任何一层，都无法释放其他层的潜力——要作为一个整体来设计和优化，而不是各自独立打补丁，它们的目标是为了服务大规模智能体应用。这正好对应李彦宏提到的 DAA 概念。

在李彦宏看来，Token 不一定代表终局，它只代表成本并不代表收益，衡量的是投入而非产出，但未来衡量一个平台和生态的繁荣，更应该看的有多少 Agent 在为人类干活，并交付结果。

百度智能云的发布新全栈 AI 云，正由此而生。它的架构更新包含两个主要层次：Agent Infra（Agent 基础设施层）和 AI Infra（AI 算力基础设施层）。在 Agent Infra 上，追求把单位 Token 的智能水平做到最好，并在真实业务中稳定运行、持续进化、可管可控。在 AI Infra 上，追求提供每瓦性能更强、性价比更高的 AI 算力，把 Token 效能做到极致。

二者互为支撑，是百度智能云围绕新需求，给出新供给的核心解决思路。

Agent Infra：为 Agent 而生的调度层

百度官方表示，原有的“MaaS 模型服务”已升级为"Token Factory 词元工厂"。以 Agent-first 理念重构产品架构，尽可能减少 token 重复计算，推理生成速度较市场水平提升约 25%。支持文心、DeepSeek、GLM、MiniMax 等国产主流模型的调用，提供更具性价比的 token 服务。

传统大模型 API 是无状态的：每次调用都是独立的，不持有任何状态。对单次问答，这已足够；但对一个需要运行数十次调用的 Agent 任务，无状态 API 是系统性瓶颈。

百度在 Agent Infra 层引入了三个关键升级：Agent Harness 、模型服务、Agent Runtime。

现阶段用户对 Agent 平台的选用几乎处于两难局面：架构精简的开源平台，工程方面的工作不够，需要等待社区更新。但是此类平台消耗的是 Token，相对性价比更高；架构完善的闭源商业产品，工程能力强大，但消耗的通常是积分，调用最优模型，复杂任务的成本可能高达 10 美元以上（按积分折算），性价比不够。

百度的 Agent Infra 提供长上下文管理、记忆、Sub-agent 调度和评估能力，内置足够丰富的 skills。相当于再以上两个选择中提出第三条路：享受完善的产品能力，成本按 Token 计算。

在模型服务侧，百度更侧重推理成本的降低和推理速度的增加，核心技术手段是前文提到的 KV Cache 命中率提升。

长链推理可能会消耗百万级的 token，但真正新增计算的 token 占比不多，因此需要更高的缓存命中率。官方数据显示，在百度智能云上调用 SOTA 模型，速度比行业平均水平快 25%。

就 InfoQ 对 DuMate 的直播测试结果来看，DuMate 处理 8 份左右非结构化脏数据，并输出“投资人一页纸”汇报材料的时间是 1min 左右，同类产品使用能力接近的模型，耗时在 10min 以上，差距确实非常明显。

Agent Runtime 则是解决了企业最关心的稳定、安全、可观测问题，时至今日，也变成了 AI 走进企业的必备能力。

AI Infra：全链路能力重建

AI Infra 层的核心是 KV Cache 的系统性处理。百度采用了三级存储池化设计：HBM（显卡高速内存）→ 内存（CPU Memory）→ SSD（固态硬盘）。这三级介质速度依次递减，成本也依次递减。

这意味着，热 KV Cache 可以考虑存在 HBM，温 KV Cache 则能下沉到内存，冷 KV Cache 可以进一步落盘到 SSD——理论上，系统可以根据访问频率动态管理数据位置，在成本和速度之间自动寻优。

百度公开称，这套方案在生产环境中实现了超过 90% 的 KV Cache 命中率，是业界最高水平。

此外，百度还宣布在 Agentic 强化学习场景下的训练效率和强化学习效率提升达到 100% 以上。

Agentic 强化学习是大模型从“会说”走向“会做”的关键路线，但传统强化学习在工程上很难规模化：训练不稳定、环境慢、采样贵。百度将其变成了一个工程能力，无论是搜索问答 Agent、自动编辑 Agent、视频理解 Agent，还是编程 Agent，都可以在这一套底座上持续优化。

在基础设施层面，百度智能云也公布了吉瓦级 AIDC 升级，通过"网络向心布局"设计理念，让计算与网络距离最短，最大限度提升计算效率，规模化落地风液兼容架构，让数据中心的整体建设周期缩短约 30%。

数据中心这个话题，在 AI 时代其实变得有点微妙。

一个典型的大模型训练任务是这样运作的：启动时，数千张 GPU 同时拉满，几天到几个月高强度运行；训练结束，这批算力从最高负荷骤降为接近空置，等待下一个训练任务被调度进来。这种"全有或全无"的需求节奏，和传统数据中心"平稳负载、充分利用"的设计假设完全相悖。

过去几年服务器交货周期波动剧烈，放大了这个问题。机房规划时就必须把服务器型号和冷却系统绑死，灵活调整几乎不可能。

百度一定程度上解决了供应链弹性的问题，通过已规模落地的"风液兼容架构"，实现前端同源、末端按需微调——同一套数据中心既能适配风冷服务器，也能适配液冷服务器。这意味着机房不必因为冷却系统而被锁死在特定硬件上，当某类服务器受供应链影响时，可以灵活替换。

需要注意的是，百度这次提出的全栈架构，并非全新亮相——多数能力已经在生产环境中跑了相当时间。所以严格来说，这套架构的重点不是发明创造，而是进化升级，以及彼此协同。从 2025 到 2026，对于 AI 新供给体系的梳理，已经越过临界点，变成了某种再出发的信号。

比如首次公开亮相的企业级智能营销解决方案 Hogee，以及专为企业打造专属视觉智能体"一见 Claw"，正帮助义乌的商家迭代为"AI 工厂"和"AI 店长"。

义乌的模式是“前店后厂”的模式——前端对接全球买家，后端组织供应链生产。这个模式的效率，长期被信息不对称所制约：哪个款在卖、库存够不够、促销时机对不对，仓库和门店之间永远在对账。

通过"一见 Claw"视觉智能体，可以将海量规则自动配置到每个摄像头上，通过自然语言，一句话识别规则、完成流程处置；而 Hogee 则通过内置的营销 Skill，帮助商家完成从销售导购、销售数据，到库存调货、促销建议等营销全链路工作。

这套组合，本质上是把原来依赖人工经验和线下对接的"前后端协同"，交给了 Agent 来跑。

类似的逻辑，在离义乌很远的几个场景里同样跑通了。

招商银行已上线 800 余个 AI 应用，活跃在风控、营销、研发和日常办公等核心场景，其中超过 50% 跑在百度昆仑芯 P800 国产算力上——在合规要求最高的金融行业做到这个规模，说明系统稳定性和安全性已经经过了严格验证。用招行内部的说法，这不是试点，是"全行级部署"。

汽车行业里，百度与长安共建的智算中心算力规模达到每秒 142 亿亿次（2023 年竣工时为行业纪录），持续支撑自动驾驶模型的训练和迭代，长安也因此成为工信部批准 L3 自动驾驶量产产品的两家车企之一。

能源侧，国家电网通过百度智能云已覆盖 800 余座变电站，AI 开始进入过去最依赖人工巡检的基础设施场景。

2025 年财报中，百度 AI 业务的占比大幅增加，来到了 400 亿的量级，跟以上进展脱不开关系。

一个更长周期的判断

有一个在产业史上反复出现的规律是：在范式转型期，第一个建好新供给体系的，获得的往往不只是市场份额，而是代际的架构优势。

iPhone 发布后，App Store 在 2008 年 7 月上线。首周末下载 1000 万次，上线两个月内从 500 款应用增至 3000 款、累计下载突破 1 亿次。到 2023 年，苹果累计向开发者支付超过 3200 亿美元。这不是因为苹果的手机最便宜，而是因为苹果第一个建立了一套对开发者和用户都有确定性的供给体系——开发者知道在哪里发布、如何变现；用户知道在哪里找应用、支付是否安全。

AI Agent 时代，类似的逻辑正在展开。

对企业用户而言，新全栈供给体系的直接意义是：把 AI 落地失败的可能性从技术层面降低了。

此前，在中国主要 AI 服务商中，在 KV Cache 生产架构和 PD 分离量产部署这两个具体维度上，只有月之暗面（Kimi）通过 Mooncake 论文建立了技术上的共识。可惜的是， Kimi 以模型服务为主，没有完整的 Agent Infra 层。

这虽然不构成对厂商整体技术能力的评价，但确实能帮助我们百度 Create 这次发布会的产业意义——亮出架构演进方向和实践效果，对 AI 基础设施买家来说，本身就是一种信任凭证。

同时，AI 基础设施也正从模型竞争阶段进入架构竞争阶段。前几年的核心命题是"谁的模型能力更强、Benchmark 更高"；接下来的核心命题是"谁的系统能在真实企业场景里稳定跑起来、成本可控、性能可期"。

这个判断是不是成立，要看接下来一两年，谁的企业客户真正用 AI 把生意做出了不一样的结果。

“一人公司”正在重做AI创业？极客部落首场16个OPC项目路演：AI 创业已从“卷模型”转向“卷闭环”

木子 — Fri, 15 May 2026 09:42:45 GMT

AI创业的风向，正悄然且迅速地改变：

现在的OPC们都不怎么聊“大模型”、“参数”、“BenchMark”这些东西了，反而更关心的是谁能最快把 AI 塞进真实场景里，然后把闭环跑通。

以上，是我们的极客部落在望京极客部落 OPC 路演现场，看完16个项目后最明显的感受。

这里面，有人做 AI 恋爱辅助，有人做AI青年社区，有人做数字生命，有人帮工厂改流程，还有人在重新改造儿童教育和内容生产......但比起“炫技”，现场出现更多的词是：获客、交付、闭环、复购。

说白了，大家都开始认真讨论一件事：AI 到底能不能真正干活；以及，它能不能撑起一门真实的生意。

这场路演，大家到底在比什么？

5月8日，极客部落举办首场OPC入驻路演评审，一群AI创业者、“一人公司”团队，共计16支队伍在北京望京联络大厦轮番登台。

整个过程有点像 AI 创业版“限时答辩”：每个团队只有5分钟，3分钟讲项目，1分钟演示 Demo，最后1分钟讲未来计划；在这5分钟内，需要快速讲清楚自己做什么、AI 如何真正参与业务，以及产品能不能跑通闭环。

这场路演最有意思的一点是，它看的并不是传统创业比赛那套“大市场、大融资故事”，相比“故事讲得好不好”，评委们更在意的是：AI到底有没有真正进入业务流程。

为保障评审的专业性与公平性，本次活动采用多维度评分机制。根据《极客部落 OPC 筛选评审规则》，现场关注的重点是：AI 原生驱动、个体或极小团队结构、AI 深度协同、产品化与规模化能力、商业闭环与自我造血能力、高效产出与成本优势、快速迭代能力、场景价值、增长潜力、数据与经营意识、开放协同与长期发展意愿等 12 项能力。

比如：

一个团队是不是已经在用 AI 覆盖研发、运营、营销、客服等多个环节？一个极小团队，能不能靠 AI 把原本需要几个人甚至十几个人完成的事情真正跑起来？产品有没有真实用户、真实场景、真实收入？项目到底是不是一个“能活”的生意？......

现场出现频率最高的问题，大都犀利且现实，比如：“你的用户从哪来？”、“现在收入怎么样？”、 “如果不用 AI，这件事原本需要多少人？”、“为什么用户愿意持续付费？”等等。

整个评审机制也很“结果导向”。除了 AI 原生能力，现场还会重点看产品成熟度、商业模式、增长潜力等，以及项目是不是停留在Demo 阶段。

所以有些项目虽然技术不算最强，但由于已经有用户、有收入、有明确场景，反而会得到更高评价；相反，如果只是“套个 AI 壳子”、缺少真实需求，即使概念再热，也很难拿高分。

某种程度上，这套评审逻辑，其实反映的是 AI 创业正在进入一个新阶段。

过去两年，行业里最容易获得关注的，往往还是“模型能力”“参数规模”或者“技术概念”；但随着大模型逐渐基础设施化，真正拉开差距的东西已经开始变化。

现在很多 AI 产品，模型本身并不稀缺，API、Agent 框架、AI Coding 工具也越来越成熟，真正难的，反而变成了：谁能最快把 AI 塞进真实业务里，并且让它稳定、持续、低成本地运转下去。

这也是为什么，本场路演的评委已不太关心“你的模型如何”，而更关心：“AI 到底替你干了什么活”。因为现在很多项目的问题，并不出在“模型不够强”，而出在业务根本没跑通——没有真实用户、没有使用频率、没有收入，甚至 AI 只是一个展示层。

而 OPC（One Person Company）这件事，本质上也不是“一人创业”这么简单，它真正测试的是：AI 能不能开始承担过去一个团队的职责。比如研发、运营、内容生成、客服、营销、数据分析，甚至部分销售动作，能不能被 AI 接管或协同完成。

如果这些环节真的能被压缩，那么创业的组织结构、成本结构，甚至公司的增长方式，都会发生变化。

这批项目，透露了哪些 AI 创业趋势？

我们发现，这16个OPC路演项目里，已经很少有人在单纯做“通用AI助手”了。

大家做的方向变得更加垂直、具体：有人在重做 To B 产业协同，有人做情绪陪伴和数字生命，有人切进教育、制造、医疗、音乐、舞蹈等垂直场景，还有人开始把 AI 接进真实商业流程、硬件和线下服务里......

在此，我们从中选出了几个有代表性的项目，开具体展开说说。

首先，其中一个很值得关注的方向，是有人开始尝试用AI重做To B产业协同。

他们想解决的，其实是一个很现实的问题：大量 AI 初创公司有技术、有产品，但根本进不了真正的大客户体系。

团队本身有很强的To B背景，他们观察到，现在 AI 行业其实有一个很大的断层：一边是大量 AI 初创公司，技术和产品不少，但不会做 To B、找不到客户；另一边则是很多大型企业，明明有真实需求，却根本不知道应该找谁、怎么选、怎么落地。

所以他们想做的，本质上是一个 AI 版“产业连接平台”：

把需求、供给、人才、案例、算法模型全部沉淀下来，再通过 Agent、Skill 和 AI 工作流去完成需求解析、精准匹配、验证、推进履约甚至结算。

举个例子，过去一个大型项目，可能需要百万年薪级别的解决方案专家长期跟进；但现在，他们认为很多需求分析、方案匹配和履约流程，其实都可以被拆成大量 Skill，再逐渐 Agent 化。

某种程度上，这个项目卷的已经不是“模型能力”，而是“产业协同效率”。

它想做的也不只是“卖 AI”，而是把原本高度依赖人脉和人工推进的 To B 连接流程，慢慢变成一个可在线化、标准化、Agent 化运转的系统。

此外，有人发现了另一种高频需求：年轻人的情绪，于是他们做起了“AI+情绪经济”的产品。

他们发现，很多大城市年轻人其实一直在反复焦虑同一类问题：

工作值不值得做、失业后能撑多久、人生下一步到底该怎么选，于是开始尝试用 AI 把这些原本很抽象的情绪和状态“量化”出来。

于是他们先做了一个“心酸计算器”，把工作时薪、时间成本这些东西量化出来，结果在小范围传播里很快就有人共鸣。

后面，他们开始把“量化人生变量”这件事做成产品：一边是时间、资产、防御能力等量化工具；另一边则是 MBTI、SBTI 这类心理测评和人格内容。

团队的核心思路其实挺像“AI 驱动的热点内容工厂”：什么情绪在流行、什么社会议题正在爆，他们就快速做对应产品，再通过 AI 批量生成内容、插画、文案和传播素材。

这个项目有意思的地方，不只是“测评”本身，而是它把 AI 的速度优势用到了极致。

团队提到，他们现在已经能做到 24 小时上线一款产品，简单测评甚至 6 小时内就能完成。包括热点捕捉、内容生产、分发和转化，基本都在 AI 驱动下快速完成。

另外一个很现实的点是，他们其实已经在反向验证商业化：和小红书商家合作授权码分发、提前布局毕业季流量节点、提前储备视频和话题素材，甚至已经跑通了部分支付和运营闭环。

某种程度上，这已经不只是一个“AI 测评工具”，而更像一个高度 AI 化的情绪内容生产系统。

还有一个“跨界”做AI 出海营销+AI硬件医疗的团队，也挺有意思。

他们原本长期服务字节跳动等大厂的海外增长业务，本质上是在用 AI 重做广告营销流程。过去很多广告素材、投放测试、达人合作，可能需要团队按周推进；现在他们已经能把大量内容生成、测试和投放流程压缩到分钟级。包括 TK 达人启动、素材生成、数据验证等环节，都已经高度 AI 化。

但更有意思的是，他们把营销业务赚到的钱，拿去“养”另一个更硬核的方向：AI 医疗硬件。

团队现在在做的，是一种面向 C 端用户的柔性健康监测设备，核心问题不是“算法准不准”，而是现有硬件太笨重、不舒服，很难让普通人长期佩戴。

所以他们现在重点，是找更轻、更软、更适合长时间贴附的新材料，比如柔性电子和纳米水凝胶，并结合 AI 算法去做连续健康监测。

他们提到，现在很多硬件的问题其实已经不只是 AI，而是材料科学。因为 AI 模型和算法已经越来越成熟，真正限制产品体验的，反而是传感器、材料和真实数据采集能力。

从某种程度上来看，这16个OPC项目，很像一份“AI 落地样本”。

如果放在一两年前，很多AI创业团队还在卷“谁的模型更强”、“谁能替代 ChatGPT”；但这次路演里，一个很明显的变化是：大部分创业团队，已经不再把“自研底层模型”当成自己的核心竞争力了。

这并不意味着 Benchmark、模型能力或者底层 Infra 不重要。只是对于大量创业团队来说，训练、优化和持续迭代模型的成本太高了：无论是算力、数据、人才还是时间投入，都不是普通小团队能长期承受的。

另外一点，是模型正在迅速基础设施化。无论是 OpenAI、Claude、Qwen 还是各种 Agent 框架、AI Coding 工具，获取能力的门槛都在快速下降。

于是，对于现在的AI行业OPC团队而言，真正拉不开差距的往往已不是“能不能生成”，而是谁更适合放在应用层、工作流、行业 Know-how 和真实场景里。

也就是说，AI 创业的竞争，正在从“模型能力”，慢慢转向“系统能力”。

比如做 To B 产业协同的团队，本质上已经不是在做聊天机器人，而是在尝试把原本高度依赖人力、关系和经验推进的解决方案流程，拆成大量可复用的 Skill 和 Agent。它想重构的，其实是企业服务里的“连接成本”。

而做“AI+情绪经济”的团队，则明显是另一种思路：他们不卷技术深度，而是卷“情绪捕捉速度”。什么情绪正在流行、什么社会议题正在爆，他们就快速生成产品、内容和传播素材。他们把 AI 当成一个高速内容生产系统，而不是单纯工具。

还有一个很有意思的变化是：这批项目几乎都在默认“AI 会进入组织结构”。

以前大家说 AI，更像“工具升级”；但现在很多团队已经开始默认：

AI 会参与研发、运营、营销、客服、数据分析，甚至部分销售动作。

所以这次评审里高频出现的词，也不再只是“参数”和“Benchmark”，而变成了：闭环、履约、增长、交付、复购。

因为很多创业者已经意识到，AI 真正改变的，可能不只是单点效率，而是整个业务流程和组织方式。

关于极客部落

极客部落，本质上是一个面向 AI 创业者、独立开发者和“一人公司（OPC）”的轻量化创业社区，目前落地在北京望京联络大厦，由极客邦科技旗下模力工场负责运营。

它并不只是传统意义上的联合办公空间，而更像一个围绕 AI 应用创业搭建的小型生态：会提供工位、活动交流、部分算力和政策对接支持；但比起“创业空间”，它更像一个 AI 创业观察现场。

极客部落比较特别的一点是，核心关注的不是“大团队创业”，而是 AI 时代正在出现的一类新组织形态：极小团队、甚至“单人成军”的创业者。

很多过去需要一个完整团队才能完成的研发、运营、内容和营销工作，现在正在被 AI 工具、Agent 和工作流重新压缩。所以极客部落关注的，也不是单纯“有没有好想法”，而是：AI 是否真正进入业务流程、项目能不能快速迭代、一个小团队能不能把产品和商业闭环真正跑起来。

目前，极客部落也在尝试把政府资源、产业需求、技术社区和 AI 创业者连接起来，比如提供免费工位、算力补贴、场景对接和创业交流等支持。

某种程度上，它也像是一个观察 AI 创业变化的小型样本：很多 AI 原生创业方式，都会先在此出现。

当AI助手进化为自主智能体：英伟达如何携手 SAP 重构企业级“信任逻辑”？

李冬梅 — Fri, 15 May 2026 09:15:43 GMT

从财务和采购到供应链和制造，专业AI智能体正在深入企业系统，并在其中进行业务决策、访问数据和大规模运行工作流。

在SAP Sapphire 2026大会上—— NVIDIA创始人兼首席执行官黄仁勋通过视频与SAP首席执行官Christian Klein共同发表主题演讲——宣布SAP与NVIDIA将扩大合作，以帮助企业在具备安全性和治理控制的条件下运行专业智能体。

SAP将NVIDIA OpenShell" ——一种用于安全开发和部署自主AI智能体的开源运行时——嵌入到SAP商业AI平台(SAP Business AI Platform)中。此外，SAP工程师正在与NVIDIA协同设计OpenShell，并将成果回馈给该开源项目。

OpenShell提供隔离的执行环境、文件系统和网络层的策略执行，以及基础设施级的遏制机制，可在智能体逻辑发生故障时防止受损。

在SAP商业AI平台中，OpenShell是所有SAP AI智能体的运行时安全层，这其中也包括在Joule Studio中构建的自定义智能体—— Joule Studio是SAP用于构建和管理端到端企业智能体的环境。

对于企业而言，从AI助手到自主智能体的转变改变了“信任逻辑”。当一个智能体能够触及记录系统、跨越应用边界，并且无需审核的情况下运行时，在投入生产之前，需要具备边界、策略执行和审计追踪能力。这正是SAP和NVIDIA共同致力解决的问题。

那么，应用层到底有多重要？

黄仁勋曾将AI比作是一个五层蛋糕"：能源、芯片、基础设施、模型和应用。

应用层位于顶层，意味着AI可创造经济价值并提高知识工作者的生产力。作为企业应用和商业AI领域的全球领导者，SAP是应用层的重要催化剂。它支撑着财务、采购、供应链和制造等工作流的运行，智能体必须在策略、身份和流程控制下运行。

SAP在企业运营中的这一核心地位成为企业采用代理式AI的关键驱动力。

企业级智能体需要理解角色、流程、权限和数据边界。它们还需要一个执行环境，能够限制智能体可访问的范围、操作权限以及其推理运行的位置。

作为SAP的长期客户，NVIDIA提供了自身的视角——其财务、供应链和物流均运行在SAP上，这为双方在实践中理解企业级治理的需求提供了共同的语境。

SAP工程师正在与NVIDIA工程师协作，进一步开发OpenShell的开源代码库，重点关注企业在生产环境中运行代理式AI所需的能力：包括运行时加固、策略建模、企业身份集成，以及审计和治理接口。

SAP和NVIDIA的技术实现了无缝协同，共同满足企业部署可信智能体的重要要求。

NVIDIA OpenShell负责问：该智能体的操作能否安全执行？Joule Studio运行时（SAP商业AI平台中的企业控制层）负责问：这一操作是否应该发生？

它们共同填补了仅凭应用层安全性无法覆盖的空白。

构建自定义智能体的SAP客户将获得更快的生产路径。NVIDIA NemoClaw" ——一个用于开发和部署自主智能体的参考蓝图——将直接在Joule Studio中使用。这意味着开发团队可以获得一条从初始构建到可信生产部署的结构化路径，而无需从头开始搭建安全框架。

只有当企业可以放心地将数据托付给AI智能体时，它们才能创造价值。

对于许多组织而言，这些数据存储在SAP中——其中包含了支撑其业务运营的财务、采购和供应链的记录系统。SAP和NVIDIA携手让智能体具备执行能力，同时确保其始终处于企业要求的边界内运行。

JEP 533 加强 JDK 27 中 Java 结构化并发的异常处理

作者：A N M Bazlur Rahman — Fri, 15 May 2026 08:12:00 GMT

JEP 533（结构化并发第七个预览版"）已经升级为 JDK 27 的正式功能。以 JDK 19 首次孵化以及 JDK 21 开始的多轮预览为基础，本轮迭代继续对该 API 进行优化。本轮更新的重点主要集中在如何将异常从作用域中传播出来。

结构化并发通过 java.util.concurrent.StructuredTaskScope" 类提供，结合 Joiner" 抽象，可以将一组相关的子任务视为单个工作单元。它解决了临时线程管理无法解决的三个问题：将子任务的生命周期限制在父作用域内、可靠地传播取消操作，以及在可观测性工具中呈现线程层次结构。预览版 6"（JDK 26）新增了 onTimeout()" 回调，并将 allSuccessfulOrThrow()" 调整为返回 List。预览版 7 延续了这一方向，并重点关注异常处理的易用性和类型安全性。JEP 533 将本轮迭代定义为一次重点优化：StructuredTaskScope 和 Joiner 接口新增了第三个类型参数“用于指定 StructuredTaskScope 类中 join() 方法可能抛出的异常类型”，并新增了一个静态 open 方法，用于“实现默认的 join 策略，并使用给定的 UnaryOperator 生成 StructuredTaskScope 配置”。

最显著的变化是三个标准连接器（joiner）的 join() 方法所抛出的新异常类型。在最近的预览版中，当子任务失败时，Joiner.allSuccessfulOrThrow()"、anySuccessfulOrThrow()" 和 awaitAllSuccessfulOrThrow()" 会抛出预览版特有的 FailedException" 异常。现在，在预览版 7 中，这些连接器会抛出 ExecutionException"，这与 Future.get()" 中长期用于指示子任务失败的封装器相同。异常原因信息会保留在 getCause() 中，因此可以直接沿用熟悉的 catch-then-switch 模式：

try (var scope = StructuredTaskScope.open()) { Subtask user = scope.fork(() -> findUser(userId)); Subtask> o = scope.fork(() -> fetchOrders(userId)); scope.join(); return new Response(user.get(), o.get()); } catch (ExecutionException e) { switch (e.getCause()) { case IOException ioe -> handleIo(ioe); case TimeoutException te -> handleTimeout(te); default -> throw e; } }

这次变更缩小了经典并发代码与结构化作用域之间的概念差异。已经在早期预览版中捕获 FailedException 异常的团队，在迁移至 JDK 27 时，只需要将这些捕获语句更新为捕获 ExecutionException 异常。

第二个改动是结构上的。现在，StructuredTaskScope 和 Joiner 接口新增了第三个类型参数 R_X，用于表示 join() 可能抛出的异常类型。之前的签名是 Joiner，现在变成了 Joiner。名称 R_X 遵循该 JEP 的约定，用于在文档中将异常类型与结果类型及 join() 返回类型区分开来；编译器会像对待任何其他类型参数一样对待它。如果应用程序代码通过 open()" 使用了所提供的 joiner ，编译器就会推导出所有内容，源代码看起来与之前相同。对于编写自定义连接器的库作者而言，throws 子句已经成为类型的一部分，而非由实现单独声明的内容。这样一来，签名就变得更加真实可信了，并且为调用者提供了一个关于 join() 方法的精确的异常检查契约。

第三项更改是新增了一个 open 重载，它将默认的合并策略（即无参数 open() 的行为，它会等待所有子任务成功或任一子任务失败）与一个配置操作符（使用 UnaryOperator" 设置作用域的 Configuration" ）配对：

try (var scope = StructuredTaskScope.open( cfg -> cfg.withTimeout(Duration.ofSeconds(2)).withName("checkout"))) { scope.fork(() -> fetchCart(userId)); scope.fork(() -> fetchProfile(userId)); scope.join(); }

之前，如果要在默认的快速失败策略中应用超时、名称或自定义线程工厂，就必须在操作符中同时传入一个 Joiner。新的工厂方法消除了这一繁琐步骤。该重载接受一个UnaryOperator 参数，这与预览版 6 中引入的更严格的类型检查一致。

结构性保障保持不变：子任务会继承 ScopedValue" 绑定（JEP 506"），JSON 线程转储格式仍然会向工具暴露作用域层次结构，而且，当作用域在 try-with-resources 之外使用，或从非所有者线程分叉时，仍然会抛出 StructureViolationException" 异常。

预览版 7 并非重新设计。预览版 5 中确定的 API 框架保持不变，本轮更改仅限于易用性和类型方面，而非结构。对于关注该 API 的团队而言，每次预览范围的缩小，都表明设计正在趋于稳定。结构化并发已经经历了两个孵化期和数个预览版。尽管 JEP 533 并未明确最终时间表，但该 API 似乎正在趋于稳定。

要对该提案进行测试，开发人员可以在 JDK 27 早期访问版本中使用 --enable-preview 启用该预览功能。在 API 最终确定之前，通过 OpenJDK 邮件列表收集的反馈意见将继续被用于完善该 API。

原文链接：https://www.infoq.com/news/2026/05/jep-533-jdk-27/"

兼顾效率、成本与能力，百灵开源旗舰推理模型 Ring-2.6-1T

李冬梅 — Fri, 15 May 2026 07:08:25 GMT

5 月 15 日，蚂蚁百灵宣布其旗舰级思考模型 Ring-2.6-1T 正式开源，权重文件同步上线 Hugging Face、ModelScope 平台。此前，该模型上线 OpenRouter，并开放限时免费 API 体验。

Ring-2.6-1T 是一款拥有万亿个参数的旗舰级推理模型，专为现实世界的复杂任务场景而设计，可供开发人员、研究人员和企业环境进行验证、调整和进一步开发。其核心设计逻辑是“按需思考”，模型引入了可调节的Reasoning Effort 机制，支持 high 与 xhigh 两种推理强度，开发者可以根据任务特性动态分配推理资源。

项目地址：https://huggingface.co/inclusionAI/Ring-2.6-1T

Ring-2.6-1T 的目标并非仅仅追求更大的参数规模，而是为了应对大型模型正在进入的实际生产环境：代理工作流、工程开发、科学研究分析、复杂的业务系统以及企业自动化流程。在这些场景中，模型不仅需要“回答问题”，还需要理解上下文、规划步骤、调用工具、持续执行，并在长期任务中保持稳定性。

Ring-2.6-1T 在三个方面实现了关键升级：

全面增强代理执行能力：从“能够回答”到“能够执行”，在多步骤任务、工具协作、上下文规划和推进复杂工作流程方面表现更稳定。Reasoning Effort 机制：支持两种推理强度级别，high 和 xhigh，允许开发人员根据任务复杂性灵活调整思考深度，从而在效率、速度和成本之间取得更好的平衡。异步强化学习训练范式：在训练层面，Ring-2.6-1T 采用异步（Async）强化学习训练架构，将策略采样与参数更新解耦为独立流水线，解决了传统同步训练中GPU 资源等待、训练吞吐不足的问题，并支持更长周期的持续训练。在此基础上，百灵将此前在Ring-1T 中验证过的“棒冰算法”引入异步RL 训练，解决训练不稳定问题。

百灵表示，相关技术细节将在后续技术报告中公开。

根据权威评测，Ring-2.6-1T 的两档模式各有所长。high 模式下，PinchBench 得分 87.60，高于 GPT-5.4 xHigh和Gemini-3.1-Pro high，Tau2-Bench Telecom 达到 95.32，Agent 场景执行能力显著。xhigh 模式下，AIME 26 得分 95.83，接近多家头部模型水平；GPQA Diamond 达到 88.27，体现出稳健的科学知识理解与复杂推理能力。

Grafana Pyroscope 2.0：实现持续性能分析规模化落地

作者：Matt Saunders — Fri, 15 May 2026 06:00:00 GMT

Grafana Labs 发布 Pyroscope 2.0"，这是对这款开源持续性能分析数据库的一次全面重构。该版本于 2026 年 4 月 21 日发布，解决了原始设计中累积的存储成本、查询性能和运维复杂性问题。

持续分析与指标、日志和追踪是可观测性堆栈的四大支柱。指标可以报告高 CPU 使用率等问题，追踪可以显示哪个服务是瓶颈，而分析则更进一步，可以精确定位到具体是哪个函数的哪一行代码在消耗 CPU 资源。Grafana Labs 资深工程师 Christian Simon 在公告中写道"，随着系统日益复杂，这种区分变得至关重要，因为只有在函数级别才能进行有针对性的优化，而不是简单地增加硬件资源。

“持续分析能够实时捕获这类运行瞬间，让你不必依靠调试器碰运气。” ——Christian Simon，Grafana Labs

原始 Pyroscope 基于 Cortex 构建，Mimir 和 Loki 早期版本也采用了相同的底层架构，但这三个项目后续都逐步脱离了该架构。Simon 指出，Mimir 近期完成了架构重构，去除了写入路径中的副本复制操作，实现了读写解耦，并将对象存储作为唯一的真实数据来源。Pyroscope 2.0 采用了相同的架构设计原则，并根据分析数据的特性进行了适配：大负载、大量的符号信息，以及突发的查询模式。

最显著的成本下降来自取消了写入路径中的副本复制。在 v1 版本中，每份分析数据都会被写入三次。单份分析数据大小可达数十兆字节，因此三倍的放大效应会对存储开销造成明显影响。Pyroscope 2.0 将每份分析数据只写入对象存储一次。第二个成本下降来自数据共置：把同一服务产生的分析数据集中存储，让函数名、源码位置、堆栈跟踪等符号信息能够进行去重处理。Simon 透露，在 Grafana 自己的生产环境中，这一优化最多可将符号存储占用降低 95%。

读取路径也经过了重新设计。在 v1 版本中，查询是在有状态的组件内部进行处理，而这类组件无法弹性扩容，这就意味着即便业务处于空闲时段，也必须按照峰值负载预留容量。Pyroscope 2.0 将整条读取路径改造为无状态模式：任意的查询器都能处理任意的查询，查询器数量可根据业务需求灵活调整。Simon 指出，分析数据的访问模式具备突发性，不存在稳定的基础流量，但故障发生期间会出现大量并发访问。他还发现，由大模型驱动的智能体正越来越多地调取分析数据，用于自动化问题排查，这种新型流量也从弹性扩展中受益。

“借助无状态查询器，系统能够从容应对各类流量峰值，无需在非峰值时段为闲置资源容量额外付费。” ——Christian Simon，Grafana Labs

从运维角度来看，更少的有状态组件意味着故障类型更少、部署速度更快。Simon 表示，v1 版本中需要耗时 8 至 12 小时的部署工作如今只需要几分钟就能完成。分段写入器改为无磁盘模式，存储网关组件也已被彻底移除。

新架构还启用了在 v1 版本中无法实现的新功能。这些功能包括从分析数据中衍生生成指标——可将分析数据聚合为跨服务、跨部署的集群级对比，无需逐一查询单条分析数据；支持查看单个分析数据实例，而不局限于聚合数据；以及用于可视化分析数据时间分布的热力图查询能力。Simon 表示，这些功能并非单独额外开发，而是更简洁的数据模型与无状态读取路径带来的自然成果。

此次发布恰逢持续分析作为标准可观测性信号逐步获得行业认可。OpenTelemetry 在 2024 年 8 月宣布"已将持续分析纳入核心遥测信号，Elastic 将其持续分析代理捐赠给了该项目。OpenTelemetry 最近宣布其 Profiles 信号进入了 Alpha 阶段。Pyroscope 2.0 原生支持 OpenTelemetry 协议（OTLP），允许团队通过标准的 OpenTelemetry 流水线摄取分析数据。

可观测性社区早已注意到性能分析与降低成本之间的关联。InfoQ 2024 年 2 月一篇关于年度可观测性预测"的文章指出，FinOps 与 OpenTelemetry 的发展、AI 技术集成一道，是塑造该领域格局的核心力量之一。这些趋势在 Pyroscope 2.0 的发布中均有所体现：架构调整大幅降低了大规模运行性能分析的成本，OTLP 协议适配紧跟 OpenTelemetry 的普及步伐，同时 Simon 也明确提到，已有 AI 智能体在生产环境中调取使用性能分析数据。

Pyroscope 并非唯一的开源持续分析项目。Polar Signals 开发了 Parca"，一个用于收集持续分析数据的开源系统，使用 eBPF 实现低开销的数据采集。Polar Signals 联合创始人 Frederic Branczyk 在 InfoQ 的访谈中"介绍他们使用 eBPF 和一个叫作 FrostDB 的自定义时序数据库同样解决了 Pyroscope 2.0 通过架构重构解决的存储与查询难题。

在商业替代方案方面，Datadog"、New Relic"、Dynatrace" 和 Sentry" 都为偏好托管解决方案的团队提供了替代选择。CubeAPM" 也提供了持续分析功能，作为全栈可观测性平台的一部分，面向希望简化部署、降低运维开销的企业组织。Pyroscope 采用开源代码结合 Grafana Cloud Profiles 托管服务的模式，使其与这些厂商形成差异化定位，尤其适合已经在使用其他 Grafana 生态组件的团队。

Pyroscope 的实际应用案例有充分的文档记录。在 2026 年伦敦 QCon 大会上，Monzo 的工程师分享他们使用 Pyroscope 进行持续分析，以便在部署时检测性能回归，同时他们还维护了一个叫作“Graph Trending Downwards”的 Slack 频道，用于记录性能改进的情况。InfoQ 在 2026 年 3 月报道了这次演讲"。Uber 也发布了在 Go 语言中运用配置文件引导优化（Profile-Guided Optimisation）的详细实践，这一工作流程在 2025 年 3 月的 InfoQ 文章"中有详细记录，Grafana Labs 也提到自己在同样的流程中使用了 Pyroscope。

Grafana Cloud Profiles" 是由 Pyroscope 驱动的托管版本，自 2025 年 4 月起已在生产环境中运行 2.0 架构。Grafana 在 2025 年 9 月将其推广到所有区域，此后累积已处理 19.5PB 的分析数据。对于现有的 Grafana Cloud Profiles 用户，迁移工作已全部完成。对于自行运行 Pyroscope 的团队，从 v1 版本升级的关键变化是分布式部署需要依赖对象存储，因为它现在是所有分析数据的唯一真实数据来源。迁移指南"和发布说明可在项目文档"中获取。

查看英文原文：https://www.infoq.com/news/2026/05/pyroscope-2-profiling/"

AdonisJS v7 推出端到端类型安全、经过重构的项目模板以及零配置 OpenTelemetry

作者：Daniel Curtis — Fri, 15 May 2026 04:00:00 GMT

由 Harminder Virk 维护的 AdonisJS"（一款“开箱即用的 Node.js 框架）发布 7.0 版本"，其核心亮点是端到端类型安全，此外还包含经过重构的项目模板、零配置可观测性，以及全新改版的文档网站。

该版本更新了超过 45 个包，并新引入了三个包：用于 OpenTelemetry 集成的 @adonisjs/otel、用于类型化内容集合的 @adonisjs/content，以及用于在 Edge 模板中使用组件语法渲染 Markdown 的 edge-markdown。

v7 的核心是一套通过代码生成贯穿整个应用技术栈的类型系统。路由定义会生成 TypeScript 类型，供新的 urlFor 辅助函数使用，从而取代了 v6 中未声明类型的 router.makeUrl 方法。Transformer 提供了一个专用的序列化层，可以在构建时生成 .d.ts 文件，使前端代码能够通过类型安全的方式访问 API 响应结构，而且无需手动复制代码。对于 Inertia 应用程序，框架会扫描页面组件，确保 inertia.render 在编译时传递了正确的 props。由 Tuyau 驱动的类型安全 API 客户端将同样的保障扩展至使用 TanStack Query 或plain fetch 的独立前端项目。

v7 依赖 Node.js 24 及以上版本，这使得团队能够用原生平台 API 替代第三方依赖。dotenv 包已经被 Node 内置的 util.parseEnv 所取代。同时，一个新引入的内部 JIT TypeScript 编译器 ts-exec（以基于 Rust 的 SWC 编译器为基础构建，大小约为 15 KB）取代了用于开发的 ts-node。

项目模板经过全面重构。与以往通过一系列配置问题引导开发人员不同，v7 提供了四个预设方案（Hypermedia、API、React 和 Vue）。这些模板都是开箱即用的，其中已经包含身份验证流程、会话管理以及前端工具链。该框架还引入了针对控制器、事件和策略的批量文件生成功能，消除了此前在路由文件顶部堆积如山的懒加载导入语句。

社区反响非常积极。在 LinkedIn" 上，一位开发人员这样评价 v7：

当前 TypeScript 优先后端开发的“最佳平衡点（Sweet Spot）”

他还补充说：

如果你来自 Laravel 阵营，或者只是厌倦了在 Express/NestJS 中拼凑 20 多个包，AdonisJS 将为你带来“开箱即用的魔法”。

Reddit" 上的一位新用户分享了使用该框架启动一个项目有多快，并补充说他们对迁移到 v7 版本有些担心。

我也意识到，我启动这个项目的时间可能正好在 v7 发布之前，所以如果我想要进行迁移的话，希望过程不会太麻烦。

库作者 Harminder Virk 直接做了回复：

很高兴听到你喜欢 AdonisJS。从 v6 升级到 v7 会非常顺利，因为几乎没有任何破坏性变更。可能只需要 15 到 20 分钟。

AdonisJS 与 NestJS 和 Laravel 等框架所处的领域相似，其不同之处在于特点鲜明的开发理念（遵循“约定优于配置”原则），以及对 TypeScript 的原生支持。NestJS 倾向于采用 Angular 风格的依赖注入和装饰器，而 AdonisJS 则更多地借鉴了 Laravel 的传统，提供了一个涵盖路由、ORM、身份验证、数据验证和邮件处理的完整工具包，并将这些功能整合在一个统一的框架之下。

对于从 v6 版本升级的团队，这些破坏性变更主要属于技术层面的调整，包括重新命名的导入项、经过更新的配置文件以及一个新的加密模块。AdonisJS 团队预计，大多数应用程序可以在 30 分钟至 1 小时内完成迁移。他们提供了详细的升级指南"以及专门的 GitHub 讨论帖"供用户报告问题。

AdonisJS 是一个由 Harminder Virk 创建并维护的、功能完备的开源 Node.js Web 框架。它深受 Laravel 传统的影响，提供了一个遵循“约定优于配置”原则的统一工具集，涵盖路由、ORM（Lucid）、身份验证、数据验证、邮件处理和模板引擎等功能，并全程支持 TypeScript。

原文链接：https://www.infoq.com/news/2026/05/adonis-v7-opentelemetry/"

鼠标每动一下都在训练AI，Meta员工“造反”了：厕所、会议室都贴满抗议传单

华卫 — Fri, 15 May 2026 02:43:44 GMT

整理 | 华卫

近日，Meta 员工周二在美国多个办公室分发了传单，抗议公司最近在他们电脑上安装鼠标追踪软件。路透社看到的传单照片显示了这一情况。这些传单出现在会议室、自动售货机上方以及这家 Facebook 母公司办公室的卫生纸架上，呼吁员工签署一份反对此举的在线请愿书。

根据路透社看到的照片，传单上写道：“不想在‘员工数据提取工厂’工作吗？”

此次传单分发发生在 Meta 计划裁员 10% 员工（即78865名员工中的约8000人）的约一周前，计划在2026年下半年进一步裁员。根据 Trueup 数据，2026 年科技行业已在 247 起裁员事件中裁减超过 9.5 万个岗位，平均每天减少 882 个职位。在这样的背景下，Meta 在员工电脑上安装了能够记录鼠标移动、点击和操作路径的软件。

这是迄今为止最明显的信号之一，表明这家硅谷巨头内部，一场劳工运动正在逐渐成形：一些员工开始将对公司计划围绕 AI 重塑劳动力结构的愤怒，转化为组织劳工行动的努力。而推动这一运动的压力，并非 Meta 独有。

这场抗议，有组织且合法？

这场抗议并非一时兴起，而是具备一定组织性的行动。据了解，他们发放的传单和相关在线请愿书引用了美国《国家劳资关系法》（National Labor Relations Act），提醒签署者：当员工选择通过组织行动改善工作条件时，“在法律上是受到保护的”。

值得一提的是，抗议传单中引用美国《国家劳资关系法》并非修辞装饰，而是一个明确的法律信号，人力资源管理者需要认真对待。美国国家劳资关系委员会（NLRB）明确指出，使用 AI 干预员工的组织权利是违法的，尤其是在涉及数据收集或员工监控时。这一表述使得“用于训练 AI 模型的数据收集型鼠标追踪软件”处于一个法律敏感区域，尤其是在公司同时进行 10% 裁员的情况下。

据外媒报道，NLRB 之前已裁定 Meta 的保密协议违法，认为其中禁止被裁员工讨论工作条件的条款侵犯了员工的组织权利。而当前员工公开传播公司监控信息的抗议行为正是 NLRA 所要保护的典型活动。

传单引导员工参与请愿的同时，在英国，一部分 Meta 员工也已与 United Tech and Allied Workers（UTAW，隶属于 Communication Workers Union）合作发起正式的工会化行动，这些员工还搭建了一个网站，通过特定网址招募成员，该网址致敬了前首席运营官 Sheryl Sandberg 的畅销书《Lean In》，这本书鼓励女性在职场中争取平等地位。

UTAW 的一位代表证实了这一行动。UTAW 组织者 Eleanor Payne 表示，“Meta 的员工正在为管理层鲁莽且昂贵的押注付出代价。当高管们追逐具有投机性的 AI 战略时，员工却面临毁灭性的裁员、严苛的监控，以及被迫训练那些低效、最终可能取代他们的系统这一残酷现实。”

相较于 Meta 的整体员工规模，这一行动仍然较小，但却触及了公司过去很少遇到的“内部凝聚力”问题。公司上一次较为显著的员工抗议，是 2018 年围绕性骚扰政策的集体罢工，最终以政策调整收场，而非对员工的打压。

Meta出声辩护：模型就需要真实案例

在今年 1 月的一次财报电话会上，Meta 首席执行官 Mark Zuckerberg 表示，2026 年将是“AI 开始从根本上改变我们工作方式的一年”。上个月，Meta向员工发布通知，推出“模型能力倡议”（Model Capability Initiative，简称MCI），捕捉员工鼠标点击信息、键盘输入信息和屏幕内容的上下文等，然后把收集到的数据用于训练AI智能体。

根据路透社看到的一份内部备忘录，“模型能力计划”（Model Capability Initiative）运行在公司配发的设备上。Meta 将其描述为“精神上自愿”，但对使用指定应用的员工而言，实际上是“事实上的强制”。在员工隐私保护更严格的司法辖区，这种做法能否经受审查仍不明确；相比之下，欧盟现行的职场监控规则，在“比例原则”和“员工同意”方面设定了比美国联邦法律更高的门槛。

从纯技术角度看，MCI旨在生成的数据集对某些AI训练范式确实有价值。机器学习模型通常受益于真实的人机交互数据，以实现细致入微的表现。其理念是创造能够从观察到的人类行为中学习的人工智能，类似于初级员工通过观察前辈学习。然而，伦理和实际问题的根源在于数据收集机制。关键是，Meta 尚未公开 MCI 的公开 API、配置密钥或版本号。这种缺乏透明度使得独立审计软件的具体功能和局限性变得困难，加剧了员工的怀疑。

现在，在其公司内部，Zuckerberg的那句话被一些员工解读为了：哪些岗位正在被“纳入数据集”。“这让我感到非常不舒服，”一位工程经理在内部留言板上写道。还有人担心，自己正在帮助训练未来取代自己的系统。“我们怎么选择退出？”一名员工问道。据外媒报道，Meta首席技术官 Andrew Bosworth 曾确认，他们实际上无法退出。

数月以来，Meta 员工一直在内部平台和在线论坛上表达不满，针对公司今年大规模裁员的计划（该计划在首次报道一个多月后才向员工确认），以及引入鼠标追踪软件，该追踪程序记录了指定工作应用列表中的鼠标移动、点击、按键和截图。许多员工认为，这无异于在帮助设计取代自己的机器人。

在被问及此事时，Meta 发言人 Andy Stone给出了一个相对直接的商业解释：“如果我们要构建能够帮助人们使用电脑完成日常任务的AI智能体，我们的模型就需要真实的使用案例，例如鼠标移动、点击按钮以及浏览下拉菜单等操作。”Meta还在一份声明中表示，这些数据用于教授AI智能体如何操作软件，并且它仅运行在指定的应用和网站上，而非覆盖所有计算机活动。并且，他们已采取“安全措施”保护公司敏感信息。

至于还会有多少员工失去工作，Meta 目前仍在评估中。Meta 首席财务官 Susan Li 在 4 月对投资者表示，“我们其实还不确定公司未来的最佳规模是多少。我认为目前变化非常多，尤其是在 AI 能力快速发展的背景下。”

参考链接：

https://www.reuters.com/sustainability/society-equity/meta-us-employees-organize-protest-against-mouse-tracking-tech-2026-05-12/"

https://www.engadget.com/2172212/meta-employees-are-protesting-the-companys-mouse-tracking-program/"

GitHub 推出 MCP 服务器集成，全面扩展机密扫描功能

作者：Craig Risi — Fri, 15 May 2026 02:12:00 GMT

GitHub 宣布"，其 MCP Server" 现在已经全面支持机密扫描"功能，将自动凭证检测和修复能力扩展至 AI 辅助和代理驱动的开发工作流。此次更新旨在帮助组织在软件生命周期的早期阶段识别暴露的机密（如 API 密钥、令牌和凭证），同时使 AI 工具和外部系统能够以更加结构化、更加自动化的方式与 GitHub 的安全发现进行交互。

这次发布表明，业界对保障 AI 增强型软件交付管道的安全性越来越重视。在这些管道中，自主代理和 AI 编码助手大规模生成、修改源代码并与之交互的情况越来越多。通过将机密扫描功能与 MCP 服务器集成，GitHub 使外部工具和 AI 驱动的工作流能够通过编程方式访问安全洞察、自动化修复流程，并将凭证保护直接融入开发自动化流程。

机密泄露仍然是现代软件开发中最常见且最危险的安全风险之一。如果凭证被意外地提交到代码库，则攻击者便可能直接访问生产系统、云环境及敏感服务。GitHub 的机密扫描技术已经能检测代码库中泄露的凭证，而与 MCP Server 的集成则将这一功能扩展至机器可读的工作流，使 AI 代理和自动化平台能够实时响应检测结果。

随着企业纷纷采用能够快速生成大量代码和配置的 AI 编码工具，这一点显得尤为重要。虽然这些工具能加快开发速度，但也增加了无意中将机密信息引入代码库或管道的风险。在 GitHub 的最新更新中，机密扫描不仅是面向开发人员的功能，更是支持 AI DevSecOps 实践的基础组成部分。

MCP Server 集成功能允许外部系统通过编程方式与机密扫描警报进行交互，从而支持自动化警报分诊"、修复建议和策略执行等工作流。现在，企业不再完全依赖开发人员手动审查检测结果，而是可以将安全响应直接集成到 CI/CD 管道、编排系统和 AI 代理中。

这反映了应用安全领域中一个广泛的演变趋势：工具正从被动检测转向持续自动化治理。人们越来越期待，安全系统不仅要能识别风险，还要能提供背景信息、协调响应，并在自动化工程环境中无缝运行。

在 GitHub 发布这一公告之际，人们对公共和私有存储库中凭证泄露的担忧日益加剧。随着 AI 生成的代码日益普及，安全研究人员和平台提供商警告称，机密管理正变得日益复杂，尤其是在 AI 系统自主与基础设施、API 和部署管道交互时。

其他主要平台也做出了类似的回应。GitLab 已经在其 CI/CD 管道中扩展了自身的机密检测能力，而 Snyk" 和 TruffleHog" 等工具则专注于持续扫描代码库和开发工作流，从而查找暴露的凭据。与此同时，为了减少机密意外泄露的风险，包括亚马逊云科技"和谷歌云"在内的云服务提供商，正在持续地投入资源，推动机密管理系统与开发工具之间的深度集成。整个行业的大趋势已经非常明确：机密管理正从一项独立的安全职能，演变为自动化软件交付过程中不可或缺的组成部分。

这次发布的更深远意义在于，它支持向以代理为中心的 AI 原生开发环境转型。随着 AI 系统逐渐成为编码、部署和运维工作流中的积极参与者，各平台必须确保安全控制措施同样具备自动化、可观察性和机器可读性。

通过在 MCP 服务器上提供机密扫描功能，GitHub 正在为未来打基础。届时，AI 代理不仅能够编写和修改代码，还能在日常运行中识别并应对安全风险。这一举措凸显了业界日益形成的共识：在高度自动化的开发生态系统中，安全工具必须演变为软件生命周期中的自主参与者，而不仅仅是事后检查点。

原文链接：https://www.infoq.com/news/2026/05/github-mcp-secret-scanning/"

蚂蚁灵波开源LingBot-VLA真机后训练全流程代码，150条示教数据即可适配新机器人

华卫 — Fri, 15 May 2026 02:08:15 GMT

整理 | 华卫

近日，蚂蚁集团旗下具身智能公司灵波科技今日宣布，全面开源其具身基座模型LingBot-VLA 的真机后训练工具链。开发团队可基于这套工具链，使用自有数据将 LingBot-VLA 快速迁移到自有机器人和具体任务中。

当前，具身智能领域开源模型持续增多，但把模型真正部署到自己的机器人上，仍需要完成一系列适配工作。由于不同机器人在机械臂构型、末端执行器、传感器配置和控制接口等方面存在差异，开发团队通常需要围绕真机部署开展大量工程工作。这套工程链路往往是各团队的核心 know-how，过去鲜有完整开放。

此次开源针对真机适配过程中的核心需求，覆盖四个关键环节：支持多LeRobot 数据合并、关节维度映射标准化的数据处理工具，面向真机场景优化的训练配置，离线评测工具，以及支持编译加速的真机部署模块。模型同时提供含深度和不含深度两个版本，方便开发团队根据自身需求进行选择。

作为蚂蚁灵波开源的具身基座模型，LingBot-VLA 基于 2 万小时真实机器人数据预训练，覆盖 9 种主流双臂机器人构型，具备跨本体、跨任务泛化能力。在真机和仿真评测中，LingBot-VLA均优于行业基准π0.5，并已与乐聚、松灵、星海图等厂商完成多机型验证。

据悉，LingBot-VLA 仅需150 条演示数据即可实现高质量的任务迁移。得益于底层代码库的深度优化，其训练效率达到StarVLA、OpenPI 等主流框架的 1.5~2.8 倍，进一步降低模型适配所需的数据和算力成本。

目前，LingBot-VLA 代码库已在 GitHub 开源（github.com/Robbyant/lingbot-vla），模型权重同步发布于 Hugging Face 和 ModelScope。

科大讯飞面向超大规模教育场景的 Agent 系统架构演进与工程实践｜AICon上海

AICon 全球人工智能开发与应用大会 — Fri, 15 May 2026 02:00:00 GMT

科大讯飞高级系统架构师王搂已确认出席 “Agent 系统架构与工程化实践"” 专题，并发表题为《面向超大规模教育场景的 Agent 系统架构演进与工程实践"》的主题分享。本次演讲将重点分享如何用图灵完备的编排平台承接复杂 DAG、如何用节点状态机和消息驱动调度支撑混合交互、如何在工程上平衡“稳定流水线”与“局部闭环纠偏”、如何借助 CRDT、Distro 和 P2P 镜像分发解决分布式授权、水平扩展与大模型快速部署问题。同时也会讨论一个核心判断：在 Agent 系统里，决定上限的不只是模型能力，调度、工具、权限、记忆与监控这些 harness 设计同样关键。

王搂，科大讯飞高级系统架构师，从事复杂系统架构和设计 10 年以上，AI 开发 5 年以上，经历过引擎开发，工作流编排系统，引擎托管系统，Agent 开发运行平台等相关工作经历。重点参与了 BG 统一 Agent 运行底座 Wish 平台的开发，在引擎推理加速，工作流编排调度，Agent 运行底座与系统架构等方面具备丰富经验。他在本次会议的详细演讲内容如下：

演讲提纲：为什么 AI 平台必须从”能力串联”升级为”自闭环系统”AI 应用从”单能力、短链路、短会话”演变为”多能力、复杂 DAG、长会话”大模型并没有消灭系统工程，反而把 Observe / Orient / Act 的工程问题全部暴露出来在复杂业务里，决定系统表现的往往不只是模型，而是整个运行时如何让系统更快感知、更快纠偏、更快恢复WISH平台的核心定位：不是一个画布，而是 Agent 时代的运行时底座对标编程语言与 IDE 的设计思路：变量、分支、循环、子工作流、异常处理为什么“harness 和模型同等重要”：调度、工具、权限、记忆、监控共同决定系统上限不是所有问题都应该交给自由 Agent：教育场景更需要“稳定流水线 + 局部闭环纠偏”的混合架构编排与调度：如何支撑复杂 DAG 的高效执行与调试调度器内核：节点状态机设计（未调度→预备→就绪→执行→已执行）基于消息驱动的数据传递：统一处理流式与非流式混合场景FaaS 落地：代码执行与调度解耦、命名空间隔离、字节码缓存、依赖管理一个关键经验：循环速度比单次“完美决策”更重要，系统必须优先保证可观测、可调试、可回退服务托管与治理：如何把数百个引擎纳入统一框架统一托管框架：一次编写、无限次托管，启动自检 + 崩溃现场自动收集结构化 action space 的工程价值：节点、工具、工作流比“代码即动作”更适合权限控制、审计和治理负载均衡基础假设失效时的应对：基于授权限流的最大空闲调度策略分布式授权精准控制：基于 CRDT PN-Counter 的无冲突并发解决方案基于 Distro 协议的自组织集群：让水平扩展真正具备工程可行性高并发下再小概率的事件也一定会发生：记一次高并发复杂场景下的踩坑经历——内存复用导致的请求串乱高性能基础上的又一次性能飞跃：如何让服务发现性能翻倍混合云弹性与线上稳定性：Agent 系统不能只会做题，还要能活在生产环境里多云自动化构建、发布与扩缩容系统设计基于 P2P 的高速镜像分发（提速 20 倍以上）精准监控与应急三板斧：重启、迁移、扩容从“人工盯系统”到“系统自我感知和自我恢复”的演进未来规划：从运行时走向更严格的 Agent 基础设施以整个AI链路为单位的整体弹性伸缩工作流描述语言WDL的形式化与严格化验证“拉”模式大展身手，跳出复杂分布式授权的天花板听众收益：对于教育超复杂场景下，Agent运行与调度的清晰认知对于Agent的能力边界认知对于Agent时代下，对于底层AI基础设施超高要求的复杂度认知

更多详情可扫码或联系票务经理 13269078023 进行咨询。

复制失败与脏碎片：Linux 页面缓存漏洞影响所有主流发行版

作者：Matt Saunders — Fri, 15 May 2026 01:37:08 GMT

在一周内，两处 Linux 内核本地权限提升漏洞相继被公开披露。其中，由安全公司 Theori" 于 2026 年 4 月 29 日披露的“复制失败"（Copy Fail）”（CVE-2026-31431"），以及由研究员 Hyunwoo Kim" 于 2026 年 5 月 7 日披露的“脏碎片（Dirty Frag）”（ CVE-2026-43284" 和 CVE-2026-43500" ），均可以使无特权的本地用户在受影响的发行版上获得 root 权限。这两个漏洞都会影响页面缓存，而且与 2022 年的“脏管道（Dirty Pipe）”漏洞属于同一漏洞大类。

复制失败漏洞是由 Theori 团队利用其基于 AI 的安全工具 Xint Code" 发现的。该团队表示，该漏洞是对 Linux 的 crypto/ 子系统进行扫描约一小时后发现的，整个过程仅需要一个操作符提示，而且不需要自定义测试框架。该漏洞本身源于内核模块 algif_aead 的逻辑缺陷，这个模块是在 2017 年的一次就地优化中引入的。一个没有任何特权的进程可以将数据插入 AF_ALG 套接字，并对不属于它的文件页面缓存执行小规模地写入操作。由于页面缓存在主机上共享，相同的写入操作可能影响属于 setuid 二进制文件的文件。Theori 发布了一个独立的 Python 概念验证程序（ 732 字节）。它只需要 Python 标准库，即可在未经修改的情况下攻破 Ubuntu 24.04 LTS、Amazon Linux 2023 、RHEL 10.1 和 SUSE 16 系统的 root 权限。

“复制失败仅需一个无特权的本地用户账户——无需网络访问权限、内核调试功能或预装的加密组件。内核加密 API（AF_ALG）在几乎所有主流发行版的默认配置中均处于启用状态，因此，从 2017 年起至补丁发布前的整个时间段内，该漏洞都处于可利用状态。”——Theori，copy.fail"

披露时间线"显示，Theori 于 2026 年 3 月 23 日向 Linux 内核安全团队报告了该问题。该团队次日便进行了初步确认，并于 3 月 25 日前提出了补丁并完成审核，4 月 1 日完成主线提交，4 月 22 日分配了 CVE-2026-31431 编号。该漏洞于 2026 年 4 月 29 日向公众披露。此后数日，各大发行版陆续发布了修复补丁。Bugcrowd 安全研究员 Casey Ellis 在 Bugcrowd 博客中写道"，Theori“并非为了追逐潮流而转向 AI 漏洞利用开发。他们之所以转型，是因为当前的数学模型更倾向于这一方向。”

在复制失败漏洞披露一周后，Hyunwoo Kim 发布了脏碎片"漏洞，并将其描述为同一类漏洞的延伸。脏碎片串联了两个独立的漏洞：CVE-2026-43284（影响 esp4 和 esp6 模块的 xfrm-ESP 页面缓存写入漏洞）以及 CVE-2026-43500（影响 rxrpc 的 RxRPC 页面缓存写入漏洞）。这两者结合所覆盖的配置范围比单独任何一个漏洞都要广泛，这源于它们能在不同发行版的默认配置下相互弥补彼此的不足。

“xfrm-ESP Page-Cache Write 提供了一种强大的任意 4 字节 STORE 原语（类似于复制失败），并且包含在大多数发行版中，但它需要创建命名空间的权限。Ubuntu 有时会通过 AppArmor 策略阻止没有特权的用户创建命名空间。在这种环境下， xfrm-ESP Page-Cache Write 无法被触发。虽然 RxRPC Page-Cache Write 不需创建命名空间的权限，但 rxrpc.ko 模块本身并未包含在大多数发行版中。不过，在 Ubuntu 上，rxrpc.ko 模块默认会被加载。"—— Hyunwoo Kim，dirtyfrag GitHub 存储库"

Kim 指出，这种链式攻击使这两个变体能够相互弥补对方的盲点，从而在所有经过测试的主要发行版上都能获取 root 权限。与许多内核漏洞利用不同，脏碎片并不依赖于竞争条件。Kim 将其描述为一个确定性的逻辑漏洞：内核在尝试失败时不会发生恐慌，而且成功率很高。CVE-2026-43284 影响了 2017 年 1 月至 2026 年 5 月补丁发布前的内核版本。CVE-2026-43500 覆盖的范围则比较狭窄，从 2023 年 6 月（受影响的 RxRPC 代码路径引入之时）起，至 2026 年 5 月 10 日止。

脏碎片漏洞的披露过程颇为特殊。Kim 在 README" 文件中指出，在 2026 年 5 月 7 日首次发布时，由于外部因素导致信息保密被打破，而且当时尚未发布补丁或分配 CVE 编号。当时，linux-distros 邮件列表的维护者们便建议 Kim 立即发布该文档，而非继续等待。发布后几天内，相关补丁和 CVE 标识符相继发布。AlmaLinux 在漏洞披露当天就发布了详细说明"，并很快发布了包含补丁的测试内核，生产库的更新则于 2026 年 5 月 8 日上线。

自 Trusty Tahr（14.04 LTS）以来的所有 Ubuntu 版本均受到了影响。Canonical 发布了一份缓解指南"，涵盖了这两个脏碎片漏洞（CVE）。根据 kernel.org 的 CNA 评估，该指南将 CVE-2026-43284 的 CVSS 3.1 评分定为 8.8 （高危），并根据 Canonical 自身的评估将 CVE-2026-43500 的 CVSS 3.1 评分定为 7.8（高危）。同时，该指南还指出， CVE List 尚未为其分配评分。Canonical 的指南详细说明了如何通过 /etc/modprobe.d 阻止三个受影响的模块（esp4、esp6、rxrpc），包括重新生成 initramfs、卸载模块以及确认它们已经不再出现在 /proc/modules 中。使用 IPsec（StrongSwan）或 AFS（RxRPC）的组织在应用此缓解措施前，应评估回归风险，因为该措施会禁用相关内核模块。

这两个漏洞都与脏管道（CVE-2022-0847）属于同一个领域，后者是 2022 年的一个 Linux LPE 漏洞，当时相关的安全报道曾对此进行过讨论"。脏管道允许无特权用户将数据插入只读文件的页面缓存中。虽然复制失败和脏碎片使用相同的页面缓存写入原语，但是通过不同的内核子系统进入该原语：复制失败通过加密 API 进入，而脏碎片则通过 IPsec 和 RxRPC 进入。这些漏洞能在经过严格审查的代码中存活多年，很可能是因为在审查 crypto/ 子系统、ESP 快速路径以及 RxRPC 接收路径时，主要关注的是加密正确性属性，例如 IND-CPA 安全性和抗侧信道攻击能力。而内存来源以及内核是否应通过该内存进行写入则属于另一类问题，标准审查流程并未针对此类问题进行检测。

Sysdig 威胁研究团队在 LinkedIn 上发文"称，“脏碎片漏洞表明，页面缓存写入漏洞正成为一种反复出现的攻击类型”，并且指出，鉴于已经有公开利用该漏洞的代码，防御方应假设，在未打补丁的 Linux 系统上，任何本地立足点都可能迅速演变为 root 权限。Sysdig 安全研究员 Crystal Morin 于 5 月 7 日（即漏洞披露当天）发布了一条针对脏碎片的 Falco 检测规则。

对于这两项漏洞来说，容器隔离机制是一个复杂的因素。来自 Bugcrowd 的 Ellis 指出了复制失败漏洞暴露的三个攻击面：运行在共享内核上的多租户 Kubernetes 集群、执行不可信拉取请求代码的自托管 CI/CD 运行器，以及在容器内运行模型生成 shell 命令的 AI 代理代码执行沙箱。由于页面缓存是在整个主机上共享的，所以一个容器的写入操作会影响其他所有租户。那些不提供独立内核的隔离机制（如 Linux 命名空间）无法阻止这两种漏洞利用方式。Ellis 指出，“共享内核的多租户架构正是复制失败所反映出的结构性风险”，并且建议，对于执行不可信代码的工作负载，应采用 Firecracker 等微虚拟机（microVM）运行时，或 gVisor 等用户空间内核。

复制失败漏洞的发现之所以引人注目，不仅在于漏洞本身，还因为其中涉及的 AI 技术。InfoQ 在 2026 年 4 月的一篇报道中曾经提到，Anthropic 研究员 Nicholas Carlini 利用 Claude Code 发现了五个 Linux 内核漏洞"，其中包括 NFS 驱动程序中一个存在达 23 年之久、可被远程利用的堆缓冲区溢出漏洞。Carlini 仅使用了一个简单的 bash 循环遍历内核树中的每个源文件，并没有借助任何定制工具。Linux 内核维护者告诉 Carlini ，AI 生成的漏洞报告已经从“噪音”转变为“有效发现”，安全邮件列表如今每天会收到 5 到 10 份有效的报告。Theori 在发现复制失败漏洞的工作中采用了类似的方法，但更为精准，他们将扫描范围限定在 crypto/ 子系统内。Ellis 的文章将 Xint Code 的成果描述为一个数据点，这表明发现内核级逻辑缺陷的成本可能已经大幅降低。他还指出，组织应预见新报告的数量将会增加。

对于目前正在采取应对措施的组织而言，针对复制失败的主要措施是更新至包含主线提交 a664bf3d603d 的内核包。该提交撤销了 2017 年的 algif_aead 就地优化。在该补丁发布之前，Theori 提出的缓解方案是将 algif_aead 模块加入黑名单，并结合 seccomp 配置文件，阻止不受信任的进程创建 AF_ALG 套接字。针对脏碎片漏洞，缓解措施是将 esp4、esp6 和 rxrpc 加入黑名单并清空页面缓存，并随后在发行版发布更新时应用内核补丁。Kim 的 README 文件指出，复制失败公布的将 algif_aead 加入黑名单的缓解措施无法防范脏碎片，因为 xfrm-ESP 原语与复制失败共享相同的接收端，但并不依赖于 algif_aead 的存在。

原文链接：https://www.infoq.com/news/2026/05/copy-fail-dirty-frag-linux/"

当 Agent 开始接管工作流，企业最在意的三件事：安全运行、稳定交付、持续进化

陈姚戈 — Thu, 14 May 2026 11:45:22 GMT

Agentic AI 的开发和大量落地，正在把一批过去不够显眼的基础设施问题推到台前。

过去两年，市场谈 AI 算力有一种简化认知：AI 算力，几乎等同于 GPU。

类似的简化也发生在云上。在很多人眼中，云计算等同于“租算力”。云像是一座远程大机房，负责把算力供给出去，至于应用如何运行、协作、演进，往往被放在次要位置。

这套认知已经脱离产业事实了。

AI 产业逐步从单纯聚焦模型训练，转向同时重视模型部署、推理效率与真实应用落地。在 Agent 爆发的背景下，AI 工作负载正变得更碎片化、更动态，也更依赖高频任务调度、内存管理、工具调用与系统编排。

随着 AI 负载类型和规模的变化，云计算和 CPU 都被委以重要使命和新的期待。

首先，CPU 正在重新获得更高的关注度。

Agent 负载的特点，正在催高市场对高核心数 CPU 的需求，尤其是在云端多租户、沙箱执行、会话并发和多 Agent 协作等场景里，CPU 承担着任务编排、执行铺开与资源调度的关键职责。

这种变化已经传导到业务侧。AMD 全球副总裁、中国区互联网事业部总经理刘宏兵也提到，过去几个月，公司一直在尽最大可能保障客户需求及AI 基础设施。

与此同时，云计算的角色在发生变化。阿里云智能集团研究员、容器服务负责人易立表示，过去云计算主要提供的是算力，而现在，云还要提供一整套能够让智能体安全运行、稳定交付、持续进化的平台能力。

作为云原生的操作系统，容器的重要性因此再次凸显。它是 Agent 在云端部署的主流承载方式，提供标准化、轻量隔离的运行环境，并协同编排系统实现任务调度、弹性扩容，为上层的持续治理与监控奠定基础。根据 Docker 发布的《State of Agentic AI》报告，94% 的受访者在 Agent 的开发或生产环境中使用容器，其中 98% 延续了传统软件时代的云原生工作流。这表明，当 Agent 从实验走向生产，行业并没有舍弃已有的基础设施体系，反而更加依赖这些经过验证的交付和治理能力。

这背后对应的，其实正是 Agent 开发和使用者最在意的几件事：安全、稳定和可持续迭代。

最近爆火的 Agent 项目，包括 Kimi 的深度研究、通用 Agent 模式“OK Computer”、MiniMax 的 MaxClaw、MaxHermes等产品，背后都有阿里云支撑。而 AMD 也为阿里云提供了底层算力支撑。

为了支撑这一轮变化，云计算和芯片厂商分别做了哪些调整，又如何共同应对 Agent 负载带来的新压力？

在本期《C 位面对面》中，极客邦科技创始人、CEO 霍太稳邀请阿里云智能集团研究员、容器服务负责人易立，以及 AMD 全球副总裁、中国区互联网事业部总经理刘宏兵，一起讨论 Agent 时代基础设施正在发生的变化，以及这些变化把云计算和芯片引向什么方向。

技术和商业的早熟，推动龙虾爆发

OpenClaw 的爆火，让行业第一次更直观地看到 Agent 接管工作的可能。随后，越来越多厂商开始推出“国产龙虾”，把部署门槛、使用成本和上手难度一起拉低。结果是，Agent 不再只是少数人的玩具，而是在更大范围内快速扩散。

阿里云智能集团研究员、容器服务负责人易立，已经把龙虾真正嵌入了自己的工作流。他在不同环境里部署了不同角色的 Agent。云上 Agent，会在他上班路上提前整理好关注的新闻、热点和技术论文；作为容器服务团队负责人，他还需要 24 小时值守的 SRE Agent，帮助分析线上集群问题、处理异常；而桌面端的 Agent，则负责日程整理、技术规划、会议安排和纪要输出。

InfoQ 也关注到了更加“激进”的应用。霍太稳表示，TGO 鲲鹏会硅谷分会长黄东旭与超过 2500 个智能体协作，已经重写了过去一个团队花 10 年才完成的 TiDB 体系，他每天消耗的 Token 量，已经超过 10 亿。

与此同时，一些平台开始让 Agent 与 Agent 之间直接通信与协作，智能体逐渐形成网络结构，不再只是围绕人展开。

在观察到这种规模跃迁后，AMD 全球副总裁、中国区互联网事业部总经理刘宏兵打趣说，也许未来会出现一个“龙虾社会”。当越来越多人同时拥有、调用、依赖多个 Agent，而这些 Agent 又彼此协作时，这个略带玩笑意味的说法，正在变成一种现实。

这轮增长不只是技术能力带来的，也与商业闭环比过去来得更快有关。

AMD 全球副总裁、中国区互联网事业部总经理刘宏兵提到，互联网客户过去一直有时间焦虑，即前期的大规模投入，究竟什么时候才能真正变现。无论是早年的云计算，还是后来的 AI，产业都曾经历过很长的投入期，商业闭环来得很慢。

这一轮 Agent 热潮的特别之处在于，从模型、平台到应用，整个链条的变现速度都明显加快了。提供 Token 和云资源的大厂可以更快获得收入；个人用户和中小企业，也能更直接地把 Agent 转化为效率提升，甚至业务收益。

AI 负载的新需求

随着 Agent 应用的规模化落地，AI 工作负载正经历结构性分化。

与传统软件处理确定性、边界清晰的任务不同，Agent 需面向开放式目标进行自主决策、持续环境交互与长链路任务执行。这种范式转变，使得 Agent 在应用、推理与训练三个层面呈现出与传统 AI 负载截然不同的技术特征。

在应用层面，Agent 不再仅是简单的文本生成，它可以调用工具、连接系统，甚至执行代码。安全、隔离和可控性成为首要前提。每个 Agent 都需要运行在沙箱环境中，依托计算、存储和网络的协同控制，才能既安全又高效地完成任务。与此同时，Agent 常将复杂任务拆解成多步并行操作，例如新闻检索、数据分析或子 Agent 协作，这就对冷启动延迟、并发吞吐能力提出了高要求。再加上任务跨越多轮对话和多阶段执行，状态保存与休眠唤醒能力，成为保障连续性和降低成本的关键。

推理层的负载特征也发生显著变化。Agent 的上下文窗口不仅包含用户指令，还需动态嵌入规则定义、工具返回数据及历史交互轨迹，导致内存占用与计算开销呈非线性增长。这要求底层架构打破单一 GPU 加速的传统思路，转向 CPU、GPU、内存与高速网络的协同优化，以在保障长窗口推理稳定性的同时实现成本控制。

易立还指出，Agent 模型训练与传统的预训练也很不一样。传统预训练更关注 GPU 性能，但 Agent 模型必须在真实场景中模拟、学习复杂任务决策，其能力很大程度上取决于对工具调用的掌控，这意味着 CPU 计算吞吐、内存带宽以及分布式调度架构的协同效率，反而成为影响训练迭代速度的关键瓶颈。

整体而言，Agent Infra 的核心命题早已不再是高效运行模型，而是实现智能体的安全隔离、状态管理与规模化运行。

Agent Infra 的四个关键问题

AI 负载的变化，也在改变行业真正关心的指标。刘宏兵说，过去大家更关注模型刷分，看榜单、看参数、看单点能力；但到了生产环境里，客户最终关心的，是能不能稳定交付业务结果，以及端到端体验和 ROI。

在这种前提下，Agent Infra 至少要解决四个问题：强隔离、高并发和低时延、状态和记忆管理，以及长链路执行。

首先是强隔离。

Agent 不只是生成文本，它还会调用工具、连接企业系统，甚至执行代码。到了这个阶段，安全已经不是一个额外补丁，而必须成为默认前提。基础设施需要提供安全沙箱、细粒度权限控制，以及计算、存储、网络的一体化隔离能力。只有先把边界划清楚，Agent 才能从“跑得起来”走向“跑得可控”。

第二个问题是高并发和低时延。

Agent 往往会把一项复杂任务拆成多个步骤并行推进，比如工具调用、子 Agent 协作、搜索和分析。这意味着，系统面对的不是少量持续运行的大任务，而是大量同时涌入的小任务。沙箱系统的冷启动时延和并发吞吐能力，会直接影响 Agent 的执行效率，也直接影响用户体验。

第三个问题是状态和记忆管理。

Agent 任务往往跨越多轮对话，不是一次调用就结束。它需要保留上下文、记忆用户意图，还要在任务中断后继续接上此前的状态。因此，Agent 沙箱基础设施必须具备高效的“休眠—唤醒”能力，让任务可以像人一样，随时暂停，随时恢复，保持记忆连续。

最后，是长链路带来的系统复杂度。

Agent 并不是一次性的模型响应，而是一个持续多轮交互、持续规划、调用工具、观察结果、修正决策的长链路过程。这样的执行方式能够提升复杂任务的完成质量，但也会显著放大系统复杂度、Token 消耗、故障排查难度。因此，Agent Infra 不只是“把Agent跑起来”的运行环境，而是支撑 Agent 在生产环境中稳定、可控、可观测、可持续优化的系统。

更进⼀步看，未来的智能形态将从单智能体向动态⽣成的集群进化。Kimi 的 Agent Swarm，OpenClaw 对 Agent Client Protocol (ACP)⽀持都指向同⼀个⽅向：Agent 从单体应⽤，演进成分布式、⾃规划、⾃组织的软件系统。这要求 Agent Infra 的职责从单一智能体的生命周期管理，升级为对动态协作集群的编排、治理与资源统筹。

这一架构演进同时带来效率范式的重构。在企业侧，竞争逻辑从固定流程优化转向智能驱动的价值创新，通过多智能体协同实现数据到决策的自动化闭环；在个人侧，开发者可借助“一人多 Agent”模式完成团队级产出。

面对集群化协作与长链路执行带来的工程复杂性，易立指出，Agent 的开发范式正从早期的提示词工程转向上下文工程与 Agent Harness；Agent Infra 需将安全沙箱、全链路可观测性、自动化评测体系、与安全护栏等沉淀为标准化平台能力。

云计算与芯片的新任务

在新的负载形态和 Agent Infra 的要求下，云和 CPU 的任务都在发生变化。

阿里云看到，云的角色不再只是提供算力，还要提供一整套让智能体安全运行、稳定交付、持续进化的平台能力。换句话说，云正从“资源池”进一步变成“Agent 工厂”，要负责智能体如何启动、如何隔离、如何调度、如何恢复、如何监控，以及如何在生产环境中被持续运营。

正在推进 Agent 创新的新锐 AI 厂商，已经着手联合云与芯片厂商解决这个问题。无论是 Kimi 的深度研究和通用 Agent 模式“OK Computer”，还是 MiniMax 的 MaxClaw 及其他全栈 Agent 产品，背后都离不开阿里云的支撑，而 AMD 则为这套云基础设施提供了更底层的算力底座。

这种变化，首先体现在运行时设计上。为了应对 Agent 的强隔离和突发式并发的需求，云基础设施需要更快地创建执行环境，也需要更强的弹性调度能力。

为此，阿里云 ACS Agent Sandbox 可以做到百毫秒级的沙箱创建、按需供给的弹性资源池，并且围绕MicroVM、NetworkPolicy、安全挂载、身份授权和审计能力，建立起了端到端隔离。

ACS Agent Sandbox 通过自定义模板预热，将镜像、依赖和配置提前加载到缓存中，再结合 MicroVM 的轻量化特性，把 Agent 实例的拉起时间压缩到 20 到 40 毫秒。同时，它还能支持最高每分钟 15000 个沙箱的弹性伸缩，任务触发时按需创建，结束后自动释放。

Agent 的另一项关键要求，是云必须更擅长处理“有状态”的任务。传统云服务更擅长处理无状态、短生命周期的请求，但 Agent 的很多任务需要跨越多轮对话，甚至在暂停一段时间后再继续执行。因此，基础设施要能保留上下文、保存运行现场，并在任务恢复时以接近实时的速度把它重新拉起。对用户而言，这是“记忆连续”；对底层系统而言，则是更复杂的状态管理能力。

为了解决这个问题，阿里云把运行环境与状态解耦，并通过持久化存储保障任务续接。状态实时保存在 ESSD 和 NAS 中，即便遭遇节点故障、实例迁移或弹性调度，Agent 也能基于历史状态快速恢复上下文。ACS Agent Sandbox 同时提供运行时 Checkpoint 能力，使实例在迁移或网络波动期间仍能保持执行链路不断。再加上阿里云容器服务 ACK 作为统一控制面，负责集中处理任务编排和状态管理，原本分散在单机上的逻辑被提升成了平台级能力。对于长链路任务来说，这意味着系统既能快速拉起，也能在中断之后接着跑下去。

由于 Agent 的状态被持久化存储，任务可以随时暂停或迁移而不中断执行，这让计算资源可以按需释放而非持续占用；同时，每个 Agent 实例的恢复和调度需要秒级响应、高并发支持和灵活扩缩容。正是在这种情况下，Serverless 的事件驱动、动态编排和细粒度调度的特性，天然契合 Agent 的状态管理和弹性需求。

过去，Serverless 更多被理解为一种简化开发和节约资源的云服务模式；但在 Agent Infra 场景里，它的重要性已经不只是“省资源”，而是其事件驱动、动态编排、细粒度调度的机制，天然更贴近 Agent 的工作方式。函数计算沙箱和 ACS Agent Sandbox 的运行机制，和 Agent 的并发执行、动态触发、会话亲和、快速弹性有高度一致性。这意味着，Serverless 在 Agent 时代不再只是一个可选项，可能会成为很多智能体应用的默认底座。

另一边，AMD 看到的第一个变化是，CPU 在 Agent 时代被提到了更加重要的位置。

AMD 的判断是，Agent 业务会把算力需求从集中式的大任务，拉向高并发的海量小任务。在这种变化下，CPU 的角色被重新抬高了。因为任务编排、工具调用、数据处理、安全隔离、状态管理，这些支撑 Agent 正常运转的环节，更多依赖的是通算能力，而不只是 GPU 的矩阵计算能力。

Agent Infra 对芯片提出的要求，至少包括三个层面：一是更高的多核并发能力，用来承接大量同时涌入的小任务和沙箱线程；二是更强的单核和指令集效率，用来加速检索、解析、压缩、加解密、向量计算等工具调用背后的通用计算；三是更高的内存带宽和 I/O 能力，用来支撑上下文保留、状态维护和快速恢复。

以第五代 AMD EPYC Turin 为例，192 核、全链路 AVX-512、12 通道 DDR5 这些指标，在 Agent 场景中，能够满足高峰期并发承载需求，优化单任务完成时间与执行环境恢复速度。

在安全上，云计算与芯片也需要联合解决新的问题。

易立提到，Agent 从一个聊天伙伴，变成真正的工作同事之后，会调用工具、执行命令，但它并不承担责任，这给用户和基础设施构建者都带来了新的挑战。易立认为，不能默认 Agent 不会犯错，必须给它一个受约束的执行环境，让它在可控边界内行动。

所以，安全必须成为平台默认能力。ACS Agent Sandbox 在计算层面用 MicroVM 为每个 Agent 实例提供独立内核，安全边界接近完整虚拟机；也允许开发者进一步控制它是否能访问互联网、是否能访问公司核心应用，同时配合细粒度授权和安全审计。

随着 Agent 权限扩大，只靠过去最小权限、纵深防御这些思路，也开始显得不够。易立提到，在下一代 Agent Infra 里，数据可用不可见会成为一个越来越核心的要求。比如涉及支付、账户、隐私数据的场景，企业当然希望 Agent 可以完成任务，但不会希望它直接暴露用户的银行密码、账号或其他敏感信息。也因此，机密计算开始从一个偏底层、偏专业的能力，走向 Agent 基础设施的中心位置。以 AMD 的 SEV 为代表的机密计算能力，可以让数据在执行过程中依然处于受保护状态，只能被受控的 Agent 使用，而不能被平台方或其他恶意 Agent 直接调用。

安全始终伴随代价。

刘宏兵指出，若加密导致 CPU 算力损失达 30%~50%，多数企业将难以承受；而 AMD 凭借将 CPU 内部硬件加密性能损耗控制在 3%~5% 以内的成绩，显著提升了客户接受度。

如果说上一轮 AI 基础设施竞争，核心是把模型训得更大、把 GPU 堆得更多，那么 Agent 时代真正考验的，则是谁能把一整套系统组织起来。

也正因如此，云计算和芯片的角色都在被重新定义。云不再只是资源池，而要变成运行和治理智能体的平台；CPU 也不再只是 GPU 的配角，更需重新成为并发、状态、安全和成本的关键支点。

今天外界看到的，是 Kimi、MiniMax 等厂商旗下 Agent 产品在台前快速推进；但真正决定它们能走多远的，往往是背后那套更重、更复杂，也更少被看见的基础设施。

当 Agent 开始接管工作流，企业最在意的三件事：安全运行、稳定交付、持续进化

陈姚戈 — Thu, 14 May 2026 11:33:56 GMT

这轮Agent热潮正在把很多企业推到一个不太舒服的位置。大家都知道不能错过，但到底该从什么场景切入、需要怎样的基础设施，很多人其实并不清楚。
Agent正在把AI负载从单纯的模型推理，推向更复杂的任务编排、工具调用、状态管理、安全隔离和多Agent协作。这时候，企业如果还用 “AI算力=GPU” ，“上云=租机器”的旧理解来做技术选型，在真正落地时一定会踩坑。
在本期《C位面对面》中，极客邦科技创始人、CEO霍太稳，深度对话：
💬 阿里云智能集团研究员、容器服务负责人易立
💬 AMD全球副总裁、中国区互联网事业部总经理刘宏兵
为你解答Agent 基础设施的关键问题。

龙虾犯错，员工背锅？Agent 需要安全、稳定与持续进化的底座

陈姚戈 — Thu, 14 May 2026 11:07:56 GMT

要让Agent真正成为员工，只部署“龙虾”是不够的，一套安全、稳定、可支撑应用持续迭代的基础设施至关重要。
InfoQ与阿里云、AMD一起，系统梳理了Agent潮带来的负载变化、基础设施面临的新要求，以及云计算与芯片的最新发展趋势。
本片为预热和精彩回顾，请到正片和文章欣赏更多精彩内容！

拒掉字节、谷歌橄榄枝，Meta 离职大佬田渊栋官宣自立门户！苏妈老黄追着投

李冬梅 — Thu, 14 May 2026 10:30:41 GMT

Meta 离职大佬田渊栋官宣创业，估值超300亿

过去一年，如果要评选硅谷 AI 圈最魔幻的公司，Meta大概率能稳坐前排。

小扎一边拿出数百亿美元继续豪赌 AI，另一边又对内部组织架构频繁调整、研究团队被不断重组，甚至连那些真正能决定未来技术方向的核心科学家，也在这场“战略摇摆”中被推向门外。

田渊栋就是这场魔幻布局里的典型例子。

昨晚，这位半年前被Meta裁掉的华人 AI 科学家田渊栋，带着一家新公司高调归来，首轮融资直接拿下 6.5 亿美元，估值冲到 46.5 亿美元。领投方是GV和Greycroft，AMD 和英伟达都跟投了。

公司名字叫Recursive Superintelligence。

半年前，这位在 Meta 待了近十年的华人 AI 科学家被裁时，评论区几乎变成了硅谷顶级 AI 公司的“抢人现场”。在他这条离职推文下方的评论区，字节跳动、谷歌DeepMind 等公司纷纷抛出橄榄枝，但都被他婉拒了。

有趣的是，当时还有人调侃，提议田应该召集所有以前在 Meta 的人，自己开一家公司，然后狠狠地报复 Meta。

或许看到这条评论后，他心动了。

田渊栋是谁？

他出生于上海，毕业于上海交大，随后在Carnegie Mellon University机器人研究所拿下博士学位。博士毕业后，他进入FAIR，在 Meta 一待接近十年。他长期担任NeurIPS、ICML等顶会领域主席，是学界和工业界都认可的核心研究者。

他的研究方向，几乎踩在了当代 AI 最核心的交叉点上：强化学习、多智能体系统、大模型推理规划、深度学习理论分析、AI 可解释性。他长期担任NeurIPS、ICML等顶会领域主席，是业内公认的“偏理论、偏底层、偏难题”的那类研究者。

这种人，在大厂体系里通常有点尴尬。他们不一定能快速交付 flashy demo，也未必适合冲 KPI，但往往决定了一家公司未来三到五年的技术天花板。

偏偏这几年，Meta 对这种长期主义的耐心越来越少。田渊栋的离职，就是这种缺少长期主义耐心带来的公司动荡的缩影。

2025 年初，距离Llama 4发布只剩不到两个月，Meta 内部突然调整资源配置，将 FAIR 的部分基础研究团队直接抽调到生成式 AI 产品线。包括田渊栋团队在内，大量研究人员被要求承担后训练、调参、问题修复等工程支持任务。

这场调整背后，是 Meta AI 内部越来越明显的路线转向：从长期基础研究，转向短周期产品交付。

随着 Meta AI 权力结构调整，以及Alexandr Wang主导的新组织扩张，FAIR 的独立性被进一步压缩。最终，在一次大规模组织收缩中，田渊栋及其团队被裁撤。

他当时在社交平台写下的那句：“真正该解决问题的人，并不是被裁掉的人。”

带着失望离开半年后，田渊栋带着新公司又重新“杀回”了AI圈。

大厂“出走”的 AI 老兵，组了个豪华牌局

Recursive 创始团队几乎像是一整个“硅谷 AI 梦之队”，这8位创始人把当前 AI 产业链上最核心的研究机构凑了个遍：OpenAI、Google DeepMind、Meta AI、Salesforce AI、Uber AI。

站在台前的是 CEO Richard Socher。AI 圈对这个名字并不陌生。Socher 曾担任 Salesforce 首席科学家，负责Salesforce AI整体研究业务，后来创办搜索公司You.com。他属于那种典型的硅谷“学术派创业者”——既有论文履历，也有商业化经验。

另一位关键人物是Caiming Xiong，他曾在 Salesforce 主导多模态预训练研究。此外，还有多位从 OpenAI 出走的研究员，包括Josh Tobin、Jeff Clune、Tim Shi。

甚至连 AI 教科书《Artificial Intelligence: A Modern Approach》作者、Google 前研究总监Peter Norvig也加入了顾问阵容。

团队规模目前只有 25 人，这和许多硅谷的典型叙事一样：用最少的人，押注最远的未来。

他们到底在做什么？

那这么多技术大佬凑在一起，他们打算做什么？

今天的大模型竞争，本质上仍然停留在一个简单粗暴的逻辑上：更大的模型、更多的数据、更强的算力，业内把这套方法叫 Scaling Law。

它确实带来了过去几年的爆炸式突破。但问题也越来越明显：边际收益正在下降，训练成本却在指数级上升。Recursive 想做的，恰恰是跳出这条老路。

其实他们想做的事已经把答案写在了公司名字里：Recursive。“递归”，是 Recursive 想解决的核心问题。他们押注的方向叫 Recursive Self-Improvement（递归自我改进）。

简单说，就是让 AI 自己发现问题、优化模型、生成新训练路径，再反过来提升自身能力。这不是做一个更聪明的聊天机器人，也不是继续沿着“大模型参数翻倍”的老路堆算力。他们想做的是——让 AI 具备某种“自我进化能力”。

Socher 对外的解释非常直接：“AI 本身是代码，而 AI 已经能写代码。条件已经成熟。”

这句话背后的逻辑其实很清楚：如果一个系统能理解自己的结构、识别瓶颈、生成优化方案，并验证结果，那它理论上就具备了持续提升自己的可能。

那它和其他 AGI 创业公司有什么不同？

最近一年，硅谷冒出了不少瞄准 AGI 的新实验室。例如Safe Superintelligence押注“安全优先”的超级智能；一些新兴实验室则在探索世界模型与强化学习路线。

但 Recursive 的打法更彻底。它跳过了很多公司正在专注研究的如何让模型更聪明这一方向，直接去研究如何让整个 AI 开发流程自动化。

Recursive 目前在San Francisco和伦敦设有办公室，接下来，这笔融资将主要用于建设大规模算力基础设施，并启动首个“L1 级自主训练系统”。

按照计划，这套系统将在 2026 年中期亮相。它的目标不止是提升 AI 模型能力。更长远看，它希望把这套递归优化机制扩展到药物发现、科学研究等更广泛领域。

如果它真的成功，影响将远超又一个聊天机器人。而届时，Meta 也许会再一次面对那个熟悉的问题：

为什么自己总能在最关键的时候，把真正值得下注的人送出去？

参考链接：

https://x.com/Recursive_SI/status/2054490801972166898"

https://techfundingnews.com/uk-ai-startup-recursive-hits-4-65b-valuation-with-650m-raise-from-nvidia-and-gv/"

https://x.com/tydsh/status/1981167436859920861"

把 UI 生成接进流水线：基于半监督评测体系的 UI 自动化生产实践

作者：黄兆嵩 — Thu, 14 May 2026 10:09:27 GMT

本文来自 QCon 全球软件开发大会·2026（北京站）明星讲师、蚂蚁集团支付宝体验技术部前端工程师黄兆嵩带来的演讲分享《把 UI 生成接进流水线：基于半监督评测体系的 UI 自动化生产实践》。

引子

当界面迭代速度超过 UI 产能，当需求变化快于设计节奏，当用户体验需要千人千面。

传统的“预先设计→开发→上线”的生产流程已难以为继，基于 AI 的生成式 UI 技术正在重塑生产方式。

我们提出了一系列基于 AI 的生成式 UI 工程实践——从生成工具、自动化调试到生产投放，配合可量化的质量监控，让整条链路可观测、可迭代。

最终达成：“让前端生产自动运转，让用户体验随需而变”。

序章

2025 年 11 月，Google 发布 Generative UI——根据用户需求，动态生成完整交互界面。

生成式 UI 这个方向，被推倒聚光灯下。

行业已经跑了几年的 UI 生成，模型能力一路飙升。但问题来了：你敢让模型直接改你们的生产界面吗？

"能生成"到"敢上线"，中间还差什么？

今天分三部分来谈谈一些我们的思考和实践：

高质量 UI 生成——品牌约束复杂、业务逻辑深，怎么让生成结果真正可用，而不是"看起来像那么回事"LUI 场景下的应用——用户等待耐心以秒计，UI 生成这个重任务怎么接进去质量可观测与可迭代——生成结果怎么评价？怎么提升？

我希望通过这些工作，让 UI 生成从技术能力，变成能接进生产流水线的工程能力。部分效果：

AI 从代码生成领域崛起的同时，我们观察到两件事。

需求变了。从"一套界面服务所有人"，到越来越多产品追求千人千面——给每个用户生成专属 UI。体验还没跟上。大多数 AI 产品还停留在纯文本甚至 CLI 的初级交互阶段。程序员能适应，但普通非技术用户面对命令行，那是门槛，不是工具。AI 带来的效率提升，他们根本还没享受到。

与此同时，先进模型的 UI 生成质量，已经能超越人类前端程序员。

需求有了，生产力也到位了。

趋势正在成形：未来的应用形态，从 “先设计，再开发”，转向 “按需生成”。

当前主要有三个方向（需求转 UI、设计稿转 UI、数据转 UI）在推进：

但不管哪个方向，卡住大家的往往是同样的问题：

生产侧——不会用、完不成、过不了审。生成出来要么不符合业务规范，要么审核打回，最后还是人工填坑。迭代侧——模型或链路升级后，效果有没有提升？提升了多少？完全说不清。导致业务的信任度大打折扣。

想要落地，必须要解决这些问题。

第一章：如何生成高质量 UI

能生成，不等于能用。

给张设计稿、写段需求，现在的模型基本都能产出 UI。但真实业务的复杂度，远不是 demo 能比的。

怎么一步步把生成质量，拉到真正可用的标准？

困境一：Prompt 成了无人维护的代码仓库

我们给业务提供了通用的 UI 生成 prompt。几周后，反馈来了——

"我服了，每次改 prompt 像在写短篇小说。"

去看了一眼他们魔改后的提示词：洋洋洒洒几百上千行，品牌规范、组件约束、交互逻辑全塞一起。有的团队甚至搞了一份十几页的文档来管 prompt，每次改动要在群里 @ 一圈人确认。

问题还不止于此：多人协作怎么分工？版本怎么管？改了一处，别的地方崩没崩？上周好好的，这周生成结果全变了，不知道谁动了哪一行。

prompt 变成了一个没有 IDE、没有版本控制的代码仓库。

解法：给 prompt 一个 IDE

我们搭了一个 prompt 工作台。核心做了两件事：

把整块 prompt 拆成独立模块，产品、设计、研发各自维护各自的部分，互不污染。谁改了什么、什么时候改的，一目了然。此外，我们将生产环境所用的数据、模型和上下文都接到平台上——不管是谁，改完直接试运行，看真实生成结果。不用再跑复杂的代码上线部署测试流程，大大缩短试错成本。

调试跑通后，进入生产，我们还提供：

批量生产——同一套配置，一次跑出多个页面单个精修——局部有问题，对话修改，不用整个界面重来

从调试到上线，给用户提供一个平台走完。

困境二：大多数需求只有一句话

工作台解决了提示词"写好了怎么管"，但 “写不好” 这个问题还没解决。

现实是：大部分需求都是一句话，没有产品文档，没有交互说明。

拿这样的输入去生成，模型能出东西，但布局凌乱、功能不全——也就是及格分，远达不到上线水平。

解法：生成前加一层需求改写

在生成之前，系统自动判断需求是否完备，把一句话扩写成完整的业务描述：

主要是补充：页面结构、补交互流程、补功能边界。

改写前后的效果对比——布局从凌乱到清晰，功能覆盖也更完整。

困境三：设计稿还原"差一口气"

把设计稿扔给模型，模型还原出的 UI 经常——布局偏了、元素位置不准、视觉细节漏了…

这种样式问题, 设计师一眼就能看出来。

“你这个智能，还不够智能。”

根源在于：模型对图片中 UI 元素的位置、大小等视觉信息感知不够精准。

它能大致知道"这是个列表、那是个按钮"，但按钮在和旁边文字间距多少、圆角多少像素、颜色什么色值？这些靠视觉模型去推理，精度不够。

解法：给模型配一副"尺子"

我们用两万多条人工精确标注 UI 标注数据，训练了一个专门的组件检测模块。

秒级识别图片中每个元素的大小、位置、层级关系，输出结构化 (JSON 格式) 的布局描述，然后作为生成模型的输入，让还原的布局精度，大幅提升。

这个能力不只用在生成环节——还能做设计稿与还原稿的自动比对：哪里偏了、哪里漏了，一目了然。此外质量走查、异常检测也能用上。

困境四：生成结果"不像自己的产品"

功能对了，布局对了，但一眼看上去就不像你们的产品——老模型经常出 AI 味（Mac 表情包、莫名的蓝紫渐变），新模型产出不符合品牌设计语言。

根本原因是：模型不认识你的设计规范。

解法：风格管理仓库 + RAG 召回

我们建了一套风格管理仓库。用户可以把产品的设计规范录进去——色彩体系、字体、圆角、间距、图标风格，越详细越好。

每次生成时，用户可以自己选择想要应用的设计规范，也可以由系统根据需求自动召回对应规范，注入生成上下文。

这是风格化生成的效果。

没有专业设计师，没有设计规范怎么办？两条路：

自动提取——上传一张产品截图，系统自动提取设计风格文档模板库——我们提供了内置上千张优质 UI 的风格模版库和风格狂暴能力。用户可以直接使用。

第二章：如何在 LUI 中应用 AI 生成

有了高质量 UI 生成，可以直接用在 LUI 界面里吗？

落地的时候，我们几乎同时收到了两个声音：

用户："点了半天，界面还没出来。"内部：“老板，显卡快撑不住了。”

一个是体验问题，一个是成本问题。根源是同一件事——UI 生成太重。用户每轮对话都可能触发一次时间很长的完整 UI 生成。

问题出在哪：四步串行

传统链路：用户发请求 → 业务智能体取数据 → 生成模型产出 UI 代码 → 渲染到屏幕。

四步全串行，每步等上一步。哪怕每步只需几秒，加在一起就是十几秒甚至更长。在对话场景，十几秒的等待是致命的。

一、流式渲染，砍掉独立生成环节

传统链路里，业务智能体取完数据，还要再调一次生成模型来产出 UI 代码。我们的思路：砍掉这一步。

直接让智能体输出 UI 渲染所需的全部信息。

我们首先在端环境对 Markdown 协议进行了拓展，设计了 markdown-XML 的渲染协议。让模型在 Markdown 里直接嵌入组件描述——需要什么组件、属性是什么、渲染哪些数据。渲染引擎拿到即自动补全 Dom 结构，解析渲染，不再需要额外的模型调用。

可以让 UI 元素 (Tab 页、按钮、列表), 边输出边出现在屏幕上。用户的感知从"等完再看"变成"边聊边看"。

这套 markdown 拓展方案同样适用于 HTML、React、小程序等技术栈——把 JS 资源、DOM 树、script 按顺序输出，渲染引擎同样可以达到流式渲染的效果：

二、生成式 UI 召回方案，让显卡不用硬扛

再看成本，千人千面，相似的数据，生成出来的界面高度雷同。每次重新生成，是在浪费资源。

我们的思路很直接：数据相似的用户，看到相同的一组界面。

具体实现：

用存量用户数据做冷启动，提前生成一批 UI 存入仓库线上请求进来，走三级缓存匹配：数据结构和特征完全一致 → 直接返回数据特征相似 → 稍微修改或绑定数据后返回都匹配不上 → 返回兜底界面返回兜底界面的数据，触发离线生成入库

从而实现：生产侧和消费侧完全解耦。线上请求永远从仓库取，延迟稳定、体验可控。仓库随调用量自动丰富，越用越好。

第三章：如何实现有效的监督 & 迭代优化

能生成了，能上线了。但怎么知道生成得好不好？

困境：人工质检成了瓶颈

“生成完了，让产品经理把把关吧。”

一开始我们也这么做。但生成速度上去之后，一天几百个页面，审核还是那几个人——积压越来越大。人工质检，反而成了流水线上最慢的环节。

更麻烦的是：人审标准不一致。同一个界面，A 觉得可以，B 觉得不行。标准在每个人脑子里，没法沉淀、没法复用。

要让 UI 生成真正上流水线，质量监督必须自动化。

解法：自动机审 & 人机协同审核

UI 生成后，系统自动打分、输出评审意见——哪里有问题、严重程度如何。

背后是一套规则驱动的 Agent 评审流程：

通用规则（内置）——文字是否溢出、图片是否变形、交互元素是否可点击、布局是否合理业务规则（用户录入）——品牌色是否合规、字号是否达标、特定场景必须包含哪些元素

评审结果分三档：

每条问题附带具体说明和定位，帮助 AI 进一步给各个维度打分和撰写详情。

同时，机审之外，我们提供了包含机审结果的标注界面，协助人工审核。

设计师和产品经理可以直接在 UI 截图上圈选区域、标注问题。审核通过的才进上线流程。

我们用人工精标数据验证了机审的准确性。两个关键发现：

人审与机审通过率吻合度约七成人拒绝的，机器全部拒绝了。没有一例漏网。

这意味着：机审比人审更严，不会放水。可以做一道真实有效的质量门禁——先过机审，再给人看。人只需处理机审通过但有争议的部分，审核量大幅下降。

自动迭代 Prompt

有了人审和机审的标注数据，我们又往前走了一步。

每次审核后，系统自动汇总标注信息，分析这一批 UI 的共性问题根因——色彩不合规？布局规则没覆盖？某类组件描述不够清晰？分析完成后，生成针对性的 prompt 优化建议，直接更新到生成链路。

产品和设计只需指出"这里不好"，不用自己想怎么改 prompt。链路自己会学。

审核做得越多，生成质量越高。正向循环。

总结与展望

最后聊几个思考：

一、动机的演变 – 从辅助工具，到个性化引擎，再到前端生产范式的革命

最早 21 年做生成式 UI，看中的是 AI 的自然语言理解能力——用自然语言完成低代码操作，改个颜色、调个属性、换个布局。

后来 AI 能力增强，目标变了——不同的用户数据，驱动出不同的 UI，实现千人千面。

再到现在，超低的生产成本 + 超高的生产质量，正在推动前端生产方式的整体升级。

二、生成的边界在扩展

去年聊这个话题时，AI 还很难生成复杂业务逻辑，只能做展示和拼接层，运用写好的业务组件。

现在，预言"未来大部分 UI 组件可能都是生成的"——已经成真了，几乎所有界面内容都可以通过 AI 直接生成。接口调用、服务对接，也能通过 MCP、Skill 等协议实现。

生成式 UI 的能力边界，从"画个界面"扩展到了"跑通业务"。

与此同时，产品、前端、后端的界线越来越模糊。未来可能不再区分前端后端，大家都是懂产品的全栈。

三、交互形态的终局

Claude Code 这类工具让 AI 能力进一步释放，很多产品开始沿着"让 AI 权限无限扩大"的逻辑做重构。

CLI 现在很火。但大部分普通用户最终期待的，不是一个命令行，而是更直观、更优雅的界面。

CLI 不是终局形态，而是技术快速革命下，体验技术还没来得及适应的中间态产物。

LUI 与 GUI 的融合，会把越来越强的 AI，在各行各业真正让不同用户用起来。

当 AI 越来越强、能做的事越来越多，用户需要的不只是能力，还有体验。

我们接下来的方向，正是面向 LUI 与 GUI 的融合，让强大的 AI，有信、雅、达的表达。

作者介绍

黄兆嵩博士，蚂蚁集团前端工程师，2021 年开始深耕基于大语言模型的前端应用生成与研发领域多年。先后就职于华为、蚂蚁集团，负责 “基于 AI 生成的低代码 / 无代码前端应用研发平台”、“生成式 UI & UI 生成中心”、“生成式黑科技 Tools ”等项目。主要研究方向为 AI to UI、UI 评测。博士研究方向为多源异构数据的可视分析与检索等。

AWS 改进 Aurora Serverless：扩容速度提升 45%，吞吐量提高 30%

作者：Renato Losio — Thu, 14 May 2026 10:00:00 GMT

AWS 近期为 Amazon Aurora Serverless 发布了新的平台版本"，重点改进了扩缩容行为与运行时效率。根据 AWS 的介绍，在流量激增场景下，数据库容量扩展速度现在可提升约 45%；同时，通过更优的资源调度与基于工作负载的扩容决策，数据库性能最高可提升 30%。

平台的第四版本引入了更高效的运行时机制以及更智能的扩容算法，不仅让 Aurora Serverless 集群能够更快完成容量扩展，还使其拥有更高的数据库性能。

Amazon Aurora Serverless 已正式可用四年"，它是一种按需、自动扩缩容的 Aurora 配置，可根据应用负载动态调整数据库容量。Aurora Serverless 支持 MySQL 与 PostgreSQL，在空闲时能够缩容至零容量"，并以 0.5 ACU（Aurora Capacity Unit）为单位细粒度调整资源"，以适配工作负载变化。

AWS 使用 HammerDB TPROC-C" 基准测试，对三个 Aurora Serverless 平台版本在 1,024 个虚拟用户下的性能进行了对比。测试结果使用每分钟新订单数（NOPM）衡量各版本性能，并统计相对于上一平台版本的变化幅度。AWS 高级软件开发工程师 Jiaming Yan"、L3 软件开发工程师 Ashok Kurakula"，以及高级软件工程师 Nashad Safa" 表示"：

对于 Aurora Serverless 支持的两种数据库引擎——Aurora MySQL 与 Aurora PostgreSQL——平台第四版本相比第三版本，NOPM 提升了 27% 到 34%。

来源：AWS 博客

另一项 Sysbench 基准测试则对运行平台第二、三和四版本的三个 Aurora Serverless 集群进行了比较。测试中，各集群采用相同的容量配置，范围从 0.5 到 256 ACU，并启用了快速扩容。系统加载了总计 16 GB 的 250 张数据表后，在 512 个线程下执行了 5,000 万次以读操作为主的查询。

研究人员通过 CloudWatch 的 ServerlessDatabaseCapacity 指标比较不同版本的容量表现。Yan、Kurakula 与 Safa 总结称：

平台第四版本相比第三版本，任务完成速度提高了 27%，成本降低了 28%；相比平台第二版本，完成速度提高了 41%，成本降低了 42%。

The Duckbill Group 首席云经济学家 Corey Quinn 在其新闻通讯"中写道：

Aurora Serverless 的扩容速度提升了 45%，并且可以缩容到零——巧的是，这也正好是我对那些按 ACU 小数计费的‘Serverless 数据库’热情所剩无几的位置。不过，能在不额外收费的情况下获得真实性能提升，倒也说明要么市场竞争开始起作用了，要么西雅图那边有人不小心批准了错误的 PRFAQ。

根据 AWS 的公告，新的扩容算法特别适合多个任务竞争资源的工作负载，例如高并发 Web 应用与 API 服务。AWS 首席数据库解决方案架构师 Pini Dibask 在领英上评论称"：

特别值得关注的一点是，re:Invent 2025 上发布的 Database Savings Plans 为 Aurora Serverless 提供了 AWS 数据库服务中最高的折扣力度（35% 折扣）。再结合平台第四版本带来的性能提升（理论上意味着更低的 ACU 消耗），Aurora Serverless 的成本模型已经发生了根本性变化。

AWS 表示，新建集群将默认使用最新平台版本；现有集群则可以通过 ServerlessV2PlatformVersion 参数升级到该版本。

原文链接：

https://www.infoq.com/news/2026/05/aurora-serverless-v4/"

从服务器 OS 到 Agent 沙箱：腾讯云如何打通 AI Infra 的生态底座

四月 — Thu, 14 May 2026 09:50:56 GMT

Agent 弹出授权请求，询问你能否访问目录，或执行脚本。你瞥了一眼，直接点下 Allow，继续手头的工作。

这个场景是不是似曾相识？

Anthropic 统计，类似的请求最终有 93% 都会被用户盲目批准。所谓的安全拦截，早已在频繁的授权弹窗里形同虚设。无人细究那段被放行的代码究竟做了什么。与此同时，CodeRabbit 对 470 个开源 GitHub PR 的分析显示，AI 生成代码里的安全漏洞，最高可达人工代码的 2.74 倍。

它们都指向了 Vibe Coding 时代同一个悬而未决的问题：代码生成的速度远超人工审查的极限，但代码执行的边界，却缺乏足够可靠的基础设施来支撑。

想划定这道边界并不容易。过去，行业长期在“隔离要够硬、启动要够快、成本要够低”之间反复妥协。容器、传统虚拟机（VM，Virtual Machine）、托管云沙箱各有答案，也各有死角。

近期，腾讯云开源 Cube Sandbox，一个面向 AI Agent 的沙箱项目。4 天后，GitHub Star 突破 4000。（https://github.com/TencentCloud/CubeSandbox）

在 Agent Infra 这个从不靠话题出圈的赛道，这条增长曲线说明的不只是关注度，它更像是一次集体表态：开发者已经不愿再在"安全"与"性能"之间将就，也不愿将执行环境长期绑定在海外托管云服务里。

一个可以自己部署、自己掌控的沙箱，正在从可选项变成刚需。

沙箱为什么难做？

沙箱不是新概念。

在线 IDE、代码评测、安全测试、Serverless、浏览器自动化，都早就需要隔离环境。但 Agent 带来的变化在于，过去大多是人写代码、人审代码、人运行代码；现在，Agent 会动态生成代码，调用 Shell，读写文件，安装依赖，访问网页，并在多轮执行中根据反馈继续调整动作。

这让沙箱要承受的工程压力完全变了。

它不只是要隔离一段预期明确的代码，而是要承接模型生成的、不确定的、可能连续执行的任务链条。执行环境既要足够安全，又不能慢到破坏交互体验；既要支撑高并发，又不能把成本推到企业难以接受的程度。

这就是 Agent 执行环境长期绕不开的三座大山。

Docker 容器最轻，启动快、成本低，也最容易被开发者接受。但容器本质上仍共享宿主机内核。NIST 在容器安全指南中也指出，容器虽然提供隔离，但并不像虚拟机那样具备清晰、具体的安全边界。对普通业务应用来说，这未必不可接受；但对执行模型生成代码、用户输入脚本和不可信任务的场景来说，这道边界显然不够可靠。

传统虚拟机把隔离做得更彻底。每个实例都有独立操作系统内核，攻击面收敛，安全边界更清楚。但代价也明显：启动慢、资源重、密度低。Agent 的任务往往是高频、短生命周期的，一次代码片段执行、一次浏览器操作、一次工具调用，都可能需要快速拉起一个干净环境。传统 VM 很难成为默认答案。

以 E2B 为代表的海外托管云沙箱则绕开了自建复杂度。它开箱即用，接口友好，也已经在不少 Agent 项目中形成使用习惯。但对国内企业来说，执行环境不在自己手里，代码和数据要进入外部云端，成本、延迟、合规和供应商锁定都会随规模放大。

这也是为什么，一个可自部署、可审计、可掌控的开源沙箱，会在 Agent Infra 里变得越来越重要。

这正是 Cube Sandbox 切入的位置。

在不可能三角里找到第四条路

Cube Sandbox （以下简称 Cube）选择的是 MicroVM 路线。

它基于 RustVMM 与 KVM 构建，官方基准测试显示，可以在 60ms 内创建具备完整服务能力的硬件隔离沙箱，同时把单实例内存开销控制在 5MB 以下。在腾讯云提供的 50 并发基准测试中，平均冷启动为 67ms，P95 约 90ms，整体保持在百毫秒级。

Cube Sandbox 测试数据

这套特性背后，突破的正是 Agent 执行环境里的几道硬门槛。

首先是隔离。Cube 的每个沙箱拥有独立 Guest OS 内核，不再依赖 Docker 式的共享内核边界。对 Agent 来说，这一点很关键。因为它执行的不是一段完全确定的业务代码，而是模型在上下文中生成的命令、脚本和操作链条。一旦没有硬边界，错误就不只是一次输出失误，而可能变成对系统状态的污染。

其次是速度。传统 VM 的问题在于隔离够硬，但太重。Cube 通过资源池预置、快照克隆等方式，把冷启动压到 60ms 以内。对 Agent 交互来说，这不是锦上添花。沙箱一旦变慢，工具调用、代码执行、调试反馈都会被拖慢，整个 Agent 体验会迅速失去连续性。

再次是密度。Agent 一旦进入规模化场景，沙箱不会一个、十个地跑，而是成百上千地并发。Cube 通过 CoW 内存复用等机制，把单实例开销压到 5MB 以下，目标是在单机上承载更高密度的沙箱实例。

对基础设施来说，指标只是第一层。更关键的问题是：这些能力有没有在真实业务里经受过足够复杂的压力？

Cube 值得讨论的地方正在这里。它不是一个只在实验室里跑通的 Demo。它来自腾讯云 Serverless、虚拟化和大规模弹性调度场景的长期积累，并在元宝 AI 编程、MiniMax Agentic RL 训练等真实场景中验证过高并发沙箱调度能力。

对元宝这类 AI 编程场景来说，沙箱不是一个外围组件，而是代码生成之后能否安全执行、低成本执行的基础设施。

最后是迁移门槛。原生兼容 E2B SDK，仓库中也提供了 OpenAI Agents 相关接入示例。已有应用理论上只需替换 URL 环境变量，就能把执行后端迁移到 Cube 上。

可以看到，Cube 并不是在容器和虚拟机之间简单二选一，而是在尝试把 VM 的硬隔离、容器的轻量化和云沙箱的易用性，压进一套可自部署、可掌控的 Agent Runtime 里。

跨过硬件部署的最后一道门槛

如果说，Cube 开源初期回答的是：这个沙箱能不能足够安全、足够快、足够轻。

那么本月上线的 v0.2.0 版本要回答的则是更深层次的问题：它能不能被更多开发者和企业更低门槛地部署和管理。（https://github.com/TencentCloud/CubeSandbox/releases/tag/v0.2.0）

关键来自于 PVM （Pagetable-based Virtual Machine，基于页表的虚拟化部署模式）。

它让普通云服务器无需裸金属或嵌套虚拟化，也能运行 CubeSandbox。这意味着 Cube 的部署边界被明显拓宽：它不再只面向具备底层环境条件的团队，而是开始进入普通 CVM 场景。

这件事看起来很底层，但对 Agent Infra 很关键。

基础设施要进入生态，第一步不能太难。如果一个沙箱项目要求开发者先解决裸金属、内核包、虚拟化配置和一堆复杂依赖，它就很难成为主流开发者的默认选择。

此外，v0.2.0 还带来了三项更新：

Web 控制台上线：集群、沙箱、模板的可视化管理能力首次整合进来，开发者不再需要纯靠命令行管理沙箱实例，操作链路大幅收短，运维可观测性同步提升。

兼容范围扩大：DEB 系（Ubuntu / Debian）与 RPM 系（CentOS / Rocky）均已支持，一键部署脚本与预编译内核包同步提供，主流 Linux 发行版的安装路径全面打通。

OC9 深度集成：Cube 的 PVM 内核模块已开源合入 OpenCloudOS 9 主线内核，使 OC9 成为目前对 PVM 支持最顺滑的发行版之一，内核直接集成了 Cube 的 PVM 宿主内核支持，而其它发行版则需要额外安装预编译内核包。

目前，OpenCloudOS 社区已发布 Cube 的 RPM 包，OC9 用户可通过 yum 直接安装部署（4 天斩获 4K Star 的 Agent 沙箱，5 步在 OC 上跑通"）

随着部署链路进一步标准化，Cube 也开始收到国内外开发者的早期实践反馈，这种社区验证正是基础设施项目走向成熟的重要信号。

从 OS 到沙箱：下探 AI Infra 底座

Cube 解决了 Agent 执行层的隔离与调度问题，但一套完整可落地的 AI Infra 方案，还需要底层操作系统的支撑。这正是 OpenCloudOS 9（OC9）的位置。

OC9 是腾讯云主导、多家厂商联合发起的国产开源服务器操作系统，从内核到软件包全面自主维护，不再依赖第三方发行版（包括 CentOS），发布于 2023 年。目前已支撑超过 2000 万节点级生产环境，覆盖金融、互联网、政务等行业，是国内三大服务器操作系统根社区之一。

与其它发行版对 Cube 的支持方式不同，OC9 对 PVM 的支持不是通过外挂补丁包实现，而是将 Cube 的 PVM 内核模块直接合入主线内核。这意味着：

OC9 用户无需额外操作，内核已原生具备运行 Cube PVM 模式所需的全部支持；后续通过 yum 安装 Cube 的整个部署流程，在 OC9 上的复杂度将降至最低；随着 Cube 版本迭代，内核级集成意味着更稳定的底层适配，而非依赖外部包的滞后更新。

从操作系统到执行环境，OC9 与 Cube 的组合，提供了当前少有的 “全链路开源与可控” 路径。OC9 负责底层 OS 的内核级维护与长期支持，Cube 负责上层 Agent 的安全隔离与弹性调度，两者的内核级集成，让从 OS 到沙箱的部署不再有断层。

对金融、政企及内部研发平台等对数据主权高度敏感的场景而言，这套组合的价值不局限于单一技术指标的提升，而在于它给出了一条完整、可审计、且无需依赖海外托管服务的落地路径。

而在 Cube 与 OC9 之外，腾讯云也在推进 TACO AI 加速引擎与 FlexKV 多级缓存系统，在缓存复用与推理效率上补齐关键拼图。

整体来看，腾讯云正围绕“安全沙箱 + 推理加速 + 缓存优化”构建技术闭环，逐步深化 Agent 基础设施的全栈能力，致力于突破智能体在大规模生产级应用中的运维与性能瓶颈。

AWS WorkSpaces 支持 AI 智能体直接操作遗留桌面应用程序

作者：Steef-Jan Wiggers — Thu, 14 May 2026 06:29:00 GMT

亚马逊云科技宣布 Amazon WorkSpaces" 现已可作为 AI 智能体的托管虚拟桌面，支持智能体通过计算机视觉与输入模拟来操作传统桌面应用，无需对应用程序进行现代化改造或 API 集成。

它要解决的问题十分普遍。2024 年甘特报告"显示，75% 的企业仍在运行缺少现代 API 的遗留系统，71% 的财富 500 强企业在大型机系统上运行核心业务流程，且缺乏完善的程序化访问能力。对于这类企业来说，部署 AI 智能体意味着要在耗资巨大的应用现代化改造和彻底暂缓 AI 落地之间二选一。

WorkSpaces 采用了一种截然不同的方式：为智能体提供与人类员工完全相同的桌面环境。智能体通过 IAM 完成身份验证，通过唯一的预签名 URL 接入 WorkSpaces 实例，再通过截图识别（计算机视觉）、点击、输入、滚动等操作（模拟人机输入）与应用程序发生交互。应用程序无法感知是智能体在操作，软件本身也无需做任何修改。

（来源：亚马逊云科技新闻博客文章"）

Nuvens Consulting 总监 Chris Noon 在公告"中阐述了这项方案对受监管行业的价值：

WorkSpaces 让我们的客户能够为 AI 智能体提供与其员工所使用的相同的安全、受管控的桌面环境。无需自定义 API 集成，具有完整的审计追踪和开箱即用的企业级隔离。对于受监管的行业来说，这不是锦上添花，而是基本底线。

MCP 集成使其具备框架无关性。WorkSpaces 对外开放了托管 MCP 端点，这意味着任何支持 MCP 的智能体框架，包括 LangChain、CrewAI 和 Strands Agents，都可以直接接入。AWS 使用基于 Amazon Bedrock 构建的 Strands 智能体演示了该项能力，该智能体可在示例药房系统中处理处方续配工作流程：查找患者记录、检索药品信息、提交订单并确认续配，全程无需依赖 API。

安全模型继承了企业为人类 WorkSpaces 环境所做的所有设置。智能体在隔离的 WorkSpaces 实例中运行，而不是在本地机器或内部网络上。CloudTrail 会捕获所有操作行为用于审计，CloudWatch 则提供完整的可观测性。亚马逊云科技建议为每个智能体分配唯一的 IAM 身份，用以区分智能体操作与人类操作。桌面屏幕分辨率、图像格式和智能体能力（计算机输入、计算机视觉、屏幕截图存储）均可按资源栈进行配置。

成本是一个显而易见的质疑点。AI 编程公司 Reflex 最近发布的基准研究"显示，视觉智能体完成一项任务大约消耗 50 万输入词元，而 API 智能体仅用了 1.2 万词元，成本差异达 45 倍。Reflex 增长负责人 Palash Awasthi 认为：

更好的视觉模型可以降低每张屏幕截图的错误率，但并不能减少获取相关数据所需的屏幕截图数量。

视觉智能体耗时17分钟，而调用 API 仅需 20 秒。Awasthi 承认，更先进的模型最终会降低成本，但他坚持认为，基于视觉的智能体所需步骤始终会多于基于 API 的替代方案。

这正是亚马逊云科技想要表达的核心权衡：计算机使用智能体和 API 解决的是完全不同的问题。有可用 API 时，智能体理应优先使用。但绝大多数企业软件、遗留 ERP 系统、胖客户端应用和专用工具本身就没有提供 API 访问能力。

对于这些应用程序而言，一个成本高出 45 倍的智能体仍有可能比耗时数年的现代化改造项目更加经济。每个企业都需要弄清楚的是，工作流自动化的价值是否足以证明特定规模下的词元成本是合理的。云桌面的临时部署特性有助于成本管控：组织可以为特定任务启动 WorkSpaces 实例，并在智能体完成后将其关闭，无需维护持续运行的基础设施。

微软也正通过 Windows 365 for AI agents" 推行类似思路，打造了一个平行的云桌面服务品类，让 AI 系统通过用户界面而非 API 来操作软件。

WorkSpaces 智能体访问功能目前在美国东部（弗吉尼亚北部、俄亥俄）、美国西部（俄勒冈）、加拿大（中部）、欧洲（法兰克福、爱尔兰、巴黎、伦敦）和亚太地区（东京、孟买、悉尼、首尔、新加坡）提供预览版。包含示例代码的 GitHub 仓库" 现已可用。

查看英文原文：https://www.infoq.com/news/2026/05/aws-workspaces-ai-agents/"

Gemini 进手机，Android 翻身；Gemini进电脑，全网开喷！

褚杏娟 — Thu, 14 May 2026 06:04:30 GMT

谷歌正在端侧AI上，大力尝试。Android 争了口气，但 AI 笔记本依然让人摸不着头脑。

相比过去把 AI 作为一个应用、聊天窗口或语音助手入口，这次 Google 在 Android 上的思路明显更激进：它试图让 AI 直接进入系统交互、网页自动化、小组件生成、语音输入、车载导航，甚至电脑光标等基础体验之中。

在 Android Show I/O Edition 上，谷歌集中发布了一组围绕 Gemini Intelligence 展开的新产品与新功能。简单来说，核心是让 Gemini 变成 Android 生态的执行层：用户不再只是打开 App去做任务，而是直接把目标交给系统，由系统调动应用、网页、文件和设备能力来完成。

最有争议的则是 Googlebook。发布后，开发者社区几乎都在质疑：有人认为它只是“手机系统加键盘”，有人担心它重蹈 Pixelbook 被放弃的覆辙，也有人质疑谷歌又推出了一个定位不清的 AI 硬件概念。

最具产品感的功能，是 AI 生成小组件

这次发布会中，手机端最有产品感的功能之一，是 Create My Widget。

有用户评价称：“作为一名 iPhone 用户，我实在看不出 Apple 的 iOS 要如何对标这种原生级深度个性化能力。”这指的正是 Create My Widget，它的核心是让用户通过自然语言生成自己的专属小组件。

过去，KWGT、Widgetopia 这类第三方应用已经给 Android 用户提供了丰富的小组件定制选项。但这些工具大多依赖天气、电量、股市行情等预设数据源，普通用户很难真正自定义逻辑，除非愿意自己写代码。

Google 这次的做法，是让 Gemini 直接参与小组件生成过程。用户只需要用自然语言描述需求，系统就能自动生成一个专属小组件。关键的是，这个组件可以在保护隐私的前提下，调取用户的日历、邮箱、短信等应用数据，真正贴合个人生活习惯。

例如，用户输入：“每周为我推荐三份高蛋白减脂备餐食谱。”系统就会生成一个对应的小组件，并允许用户直接添加到手机桌面。用户还可以自由调整尺寸，让组件展示更多内容。

这也是谷歌所说的“生成式 UI”的第一步。

Create My Widget 更像是把桌面变成一个可以被 AI 动态生成的个人工作台。用户不再只是从固定模板里选择，而是可以根据自己习惯，生成真正属于自己的界面。

同时，这也是 Android 17 最值得苹果警惕的地方。有网友评论称：“在 2025 年 WWDC 上，面对外界对其 AI 进展滞后的批评，Apple 靠 iOS 视觉界面大改版稳住了 iPhone 用户，但这套打法只能用一次。今年 6 月的 WWDC 2026 上，Apple 必须兑现 Siri 2.0 的承诺，推出真正可用的智能体 AI 功能。否则等到 iOS 27 面世时，在 Android 17 面前只会显得落伍陈旧。”

总体来看，下一阶段 Android 生态的核心能力，是 Gemini Intelligence。

这个名字显然很容易让人联想到 Apple Intelligence。Google 将其描述为一套结合硬件、系统软件和 AI 模型的新智能系统。它的目标不是简单回答问题，而是把过去需要用户在多个应用之间切换、搜索、筛选、填写表单的任务，整合成一个连续流程。

这次升级的关键在于 Gemini 的多模态能力。例如，用户可以拍下一张哥斯达黎加咖啡品鉴旅行的宣传手册，然后要求 Gemini 在 Expedia 上筛选适合六人同行的类似旅行项目。Gemini 会自动理解图片内容，进入网页或应用执行检索，并通过通知栏向用户展示任务进度。

除了原生应用，Gemini Intelligence 还将进入 Android 版 Chrome。Google 表示，很多现实任务并不一定发生在 App 里，用户也经常遇到手机没有安装对应专属应用的情况。因此，Google 将此前桌面端 Chrome 中的自动化能力迁移到 Android 设备上，让 Gemini 能够在网页端完成操作。

这意味着，Gemini 可以跨应用、跨网页执行任务。对 Android 来说，这已经是系统级智能体能力的雏形。

Google 还发布了新的语音精修工具 Rambler。语音输入经常出现停顿、重复、改口，Rambler 的作用，就是自动识别用户最终想表达的内容，整理成一段通顺、可直接发送的文本。它还支持二次编辑、多语言混合输入等场景。

此外，Google 还将在 Android 17 中引入操作系统验证功能。公司表示，推出该功能是为了应对一些恶意行为者发布经过修改的 Android 版本。这些系统看起来像官方版本，但实际上可能暗中破坏设备完整性，此外还有自动拦截伪造的银行来电、实时检测恶意应用程序威胁以及全局默认开启的防盗锁等。

这些能力虽然不如 Gemini Intelligence 那样吸睛，但反映出 Google 在推进系统智能化的同时，也试图增强 Android 设备的可信度和安全透明度。

苹果还在重做 Siri

“巧合”的是，就在 Google 展示 Android 17 AI 能力的同一天，苹果的 iOS 27 也传出了新消息。

外媒报道称，苹果计划在 iOS 27 中重新设计 Siri，将其从传统语音助手改造成更接近 ChatGPT、Claude、Gemini 的聊天式 AI 助手。新版 Siri 不仅会拥有新的界面形态，还将支持多轮对话、历史记录、图片和文档上传，以及系统级搜索入口。

如果这些信息最终落地，这将是 Siri 诞生以来最重要的产品重构之一。它也意味着，Apple 正在尝试把 Apple Intelligence 从一组分散的 AI 功能，进一步整合成 iOS 的系统级智能入口。

按照目前披露的信息，新版 Siri 的交互形态会发生明显变化。在 iOS 27 中，Siri 可能会以新的胶囊形动画出现在灵动岛中。当用户唤起 Siri 后，系统会先显示一张透明的结果卡片。用户可以将卡片向下滑动，展开成类似短信对话串的聊天视图。

此外，苹果还计划推出一个独立的 Siri 应用，用于保存用户与 Siri 的历史对话。相关记录可能会以会话摘要网格的形式呈现，用户可以从中继续此前的聊天，也可以通过“+”按钮发起新的对话。

新版 Siri 的另一项重要变化，也是对多模态能力的支持。

报道称，用户将能够在 Siri 中上传图片和文档，让 Siri 基于这些内容完成理解、总结、编辑或回答问题。这会让 Siri 从单纯的语音命令入口，进一步变成一个可以处理文本、图片和文件的综合 AI 助手。

与此同时，苹果也在更新 Image Playground，包括简化控制项，并新增“描述你想做的修改”这一编辑方式。这意味着，Apple 可能正在把自然语言编辑能力进一步整合进图像生成和图像处理工具中。

除了聊天界面，iOS 27 还可能引入一个新的系统级手势。用户可以在系统任意位置从屏幕顶部中央向下滑动，启动新的系统搜索入口。这个入口会在灵动岛中显示 “Search or Ask” 搜索栏，让 Siri 与系统搜索更深度结合。

苹果还计划在新的搜索和助手流程中整合第三方 AI 选项。用户可能可以在搜索栏中选择 ChatGPT、Gemini 等聊天机器人，作为 Siri 或 Apple Intelligence 的替代选项。

看起来，苹果并非没有动作，但问题在于，其目前看起来仍然处在“重做 AI 助手”的阶段，而谷歌已经开始尝试让 AI 成为系统里的执行层。

如果说苹果的关键词还是 Siri，那谷歌的关键词已经变成了 OS agent。当然，谷歌的这些功能目前也并不完整，很多体验还很零散，真正落地到不同设备、不同厂商、不同地区后也会面临一致性问题。但从方向上看，Android 17 的确更像是在探索下一代操作系统，而 iOS 27 更像是在补上上一代语音助手的短板。

对苹果来说，压力仍然很大。

主打“智能光标”的Googlebook，到底给谁用？

相比手机端的 Gemini Intelligence，Google 这次发布的全新品类笔记本 Googlebook，争议明显更大。

“Googlebook 让我产生了强烈的 Pixelbook 既视感。我很确定，除非它的价格和配置组合夸张到离谱，否则大概率会惨败。”一位网友这样评价。这几乎代表了不少开发者和科技用户的第一反应。

Google 将 Googlebook 定义为全球首款从零开始适配、原生搭载 Gemini Intelligence 的笔记本电脑。它不是传统 Chromebook 的简单延续，而是 Google 面向“智能系统时代”推出的新型笔记本设备。

Googlebook 的核心功能是 Magic Pointer，也就是“智能光标”。传统笔记本光标多年来主要承担点击、选择、右键菜单等基础操作。Googlebook 则试图让光标成为 Gemini 的入口。用户轻轻晃动光标，就能激活智能交互功能；点击页面、邮件、图片或文档中的任意内容，系统会根据上下文弹出快捷操作建议。

例如，用户看到一张儿童房照片，觉得墙面单调，可以同时选中儿童房实景图、心仪壁纸和软装素材，让系统自动生成装修效果预览。传统笔记本完成类似操作，通常需要保存图片、上传 AI 工具、输入提示词、等待生成。Googlebook 则试图把这些步骤压缩成系统层面的一次交互。

有意思的是，DeepMind 也同步展示了一个与之呼应的实验方向：用 AI 重新想象一个已经存在 50 年的界面——鼠标指针。相关演示展示了用户如何通过动作、语音和自然的简短指令，在屏幕上直观地指挥 Gemini 完成任务。

Googlebook 还强调手机与电脑之间的打通能力。用户可以在 Googlebook 上直接运行手机应用，不需要拿起手机，也不需要安装额外插件或使用虚拟触控界面。同时，Googlebook 提供 Quick Access 功能。手机与笔记本联动后，用户可以直接在 Googlebook 的文件浏览器中访问手机文件。

Google 还展示了 Gemini 生成电脑桌面小组件的能力。比如，用户要筹备柏林家庭聚会，可以让 Gemini 生成一个统筹小组件，自动整合航班信息、酒店订单、餐厅预约记录和倒计时。

目前，HP、Dell、Lenovo、ASUS 等厂商已经加入 Googlebook 合作生态。Google 表示，Googlebook 将于今年年内上线。

发布后，开发者社区对 Googlebook 的态度明显分化。

少部分人认为，Googlebook 代表 Google 正在尝试把 Gemini 深度嵌入操作系统，是一条值得关注的 AI 设备路线。但更多人持质疑态度，其中最大的一个就是：Googlebook 到底是给谁用的？

相比 Apple 发布硬件时通常能清楚说明产品适合哪类人，Googlebook 给人的感觉更像是一台“手机系统加键盘”的设备，而不是一台真正意义上的笔记本电脑。有用户追问，它到底是在对标 Android 版 MacBook，还是一台带键盘的平板设备？

这种质疑背后，是开发者对“AI 笔记本”概念本身的不信任。对他们来说，笔记本和台式机的使用场景正在越来越集中在重度用户和专业用户身上，而轻量用户可能更适合平板加键盘，或者类似 Samsung DeX 的手机桌面模式。

如果 Googlebook 只是把 Android、Gemini 和键盘组合起来，那它很难证明自己比现有电脑、平板或手机组合更值得购买。

谷歌的硬件信誉岌岌可危

更何况，Pixelbook 的阴影仍在。

Googlebook 被频繁拿来与 Pixelbook 对比。有人认为，Googlebook 很可能会“走上 Pixelbook 的老路”。部分用户对 Pixelbook 的评价其实并不差，甚至有人至今仍在使用。但问题在于，Google 没有持续迭代这条产品线，而是在几年后换一个品牌重新试一次。

这让很多用户对再次购买 Google 硬件保持谨慎。

从 Chromebook、Pixelbook 到 Googlebook，Google 一直在“重新发明差不多的东西”，但品牌和路线始终不够稳定。有用户直接问：“Googlebook 会被支持多久？什么时候会进入 Google 坟场？”

这句话背后，是 Google 硬件和服务长期积累下来的信任问题。

“Googlebook”这个名字也不太受待见。

有人认为，Google 可能是想避开 Chromebook 的包袱，让用户把 Google 与 AI 绑定起来，就像过去 Chrome 与互联网绑定一样。但这种命名也带来了新的困惑：如果 Googlebook 并不是 Google 自研硬件，而是由多家 OEM 厂商生产，那么这个名字听起来就像是一台由 Google 亲自制造的设备。

也有用户认为，Googlebook 可能位于 Chromebook 之上，因为其 AI 功能对硬件有更高要求，而设备本身仍由第三方厂商制造。该用户推测，Google 可能会把 Pixelbook 品牌保留给第一方硬件。

除了硬件定位，Googlebook 的 AI 宣传方式也引发反感。

有网友认为，很多企业并不知道该如何营销 AI。它们展示的 AI 场景往往像是在服务公司想象中的用户，而不是现实中的用户。尤其是 Googlebook 广告中使用 AI 帮用户买衣服的场景，被认为并不能代表大众真实需求。

不过，质疑之外，也有人看到了 Googlebook 的战略意义。

有用户认为，Googlebook 是一个重要动作，因为操作系统正是 AI agent 最适合落地的位置。未来智能体需要理解用户在多个界面和设备上的活动，才能真正替用户完成任务，而 OS 层面拥有最完整的上下文。

还有用户认为，Googlebook 最有意思的部分并不是硬件本身，而是 “Create your own widget” 这类能力。用户可以直接告诉 Gemini 自己想要什么数据、什么样的展示方式，然后生成一个专属界面。这种“按需生成的小型 UI”，可能会成为未来操作系统的重要方向。

目前来看，Googlebook 在开发者社区得到的第一反应并不算乐观。它激起的不是单纯期待，而是围绕 Google 硬件信誉、AI 营销疲劳、操作系统路线混乱和产品定位不清的集中质疑。

但这也恰恰说明，AI 设备竞争已经进入了一个新阶段。厂商不能只说一台设备“为 AI 设计”，还必须证明：AI 真的能让这台设备比现有电脑、平板和手机组合更值得购买，否则可能也是“白折腾”。

本地优先 AI 推理：高性价比文档处理云架构模式

作者：Obinna Iheanachor — Thu, 14 May 2026 04:00:00 GMT

一种三层混合架构可将 Azure OpenAI 的成本降低 75%，并在 4700 份文档的生产级工作负载中把处理耗时缩短 55%。2026 年云文档处理的默认架构是将每份文档都推送给托管 AI 端点，然后接收返回的结构化数据。这种方式虽然可行，但效率低下。在工程图纸、发票、监管文件这类具有固定结构化版式的文档语料中，有 60% 至 70% 的输入内容都可以通过确定性本地算法在毫秒级完成处理，且无需产生任何 API 调用成本。

本文介绍了一种我称之为本地优先 AI 推理（Local-First AI Inference）的可复用模式：这是一种三层架构，由确定性本地处理器处理大部分输入内容，云端 AI 服务仅用于应对边缘情况，人工审核层则用来限制错误率。云 AI 系统中最重要的架构选择不在于选用哪款模型，而在于何时调用模型。本地优先模式打破了固有的默认做法，提出了一个核心问题：“这份文档是否真的需要调用云端模型？”而不是不加区分地将所有内容都发送给端点。

我在 Azure 上部署了这种模式，用于从 4700 多份工程图纸 PDF 文件中提取元数据。采用纯云端方案需要花费 47 美元的 Azure OpenAI API 调用费用，耗时 100 分钟，且每份文档都会存在幻觉风险。采用混合架构方案后，API 成本降至 10 至 15 美元，处理时长缩短至 45 分钟，同时人工审核层有效控制了错误率。

手动替代方案需要工程师逐份打开 PDF、查找标题栏，并把修订信息录入电子表格，每份文档大约耗时 2 分钟，4700 份文件合计约 160 个工时。按照工程人力费率计算，每次迁移流程的成本超过 8000 英镑。这个系统已在四个站点投入使用。这种模式可推广至所有输入结构可预测的云 AI 工作负载场景：发票处理、合同信息提取、医疗记录解析等。

三层架构

层级数量由失败模式的数量决定。双层系统（本地加云端）要么默认采信存在幻觉的云端结果，要么直接拒绝这类结果并丢失覆盖率。四层系统会增加复杂度，但可靠性不会获得相应的提升。三层架构是覆盖全部三类失败场景所需的最少层级：可通过规则直接处理的文档（第1层）、需要通过视觉解析的文档（第2层），以及以上两种方式都不足以可靠处理、必须依靠人工介入审核的文档（第3层）。

第 1 层：本地确定性提取

每份文档都经过 PyMuPDF 本地提取环节进入处理流水线。第一层能以零 API 成本、单文档约 3 秒的耗时处理 70% 至 80% 的文档。这个层级采用高精准度、低召回率的设计原则：当无法确定结果时，会直接返回空值而不是猜测。它几乎不会产生误报，但会漏掉版式特殊的文档，而这类文档恰好可以交由第二层处理。

第 2 层：云 AI 推理

未能通过第一层处理的文档会被渲染成图像并发送给 Azure OpenAI 的 GPT-4 Vision 端点。这一层以每次调用约 1 美分、每份文档约 10 秒的耗时处理 20% 至 30% 的文档。它的失败模式与第一层恰好相反：有可能给出看似笃定实则错误的结果。

第 3 层：人工审核

第一层与第二层产出结果存在冲突的文档或是第二层返回低置信度输出的文档都会被标记为人工审核，这类文档约占总量的 5%。

图 1. 本地优先 AI 推理架构——三层混合流水线

注意图 1 中各层之间的差异：

第 1 层（本地 PyMuPDF 提取，占比 70% 至 80%，耗时约 3 秒，零成本），有置信度门控。第 2 层（Azure OpenAI Vision 兜底处理，占比 20% 至 30%，耗时约 10 秒，单次花费 1 美分）。第 3 层（人工审核，占比约 5%）。

置信度评分：该模式的核心架构

从第一层升级至第二层的决策由置信度评分函数驱动。候选内容先经过黑名单过滤，再根据四项加权标准进行打分。

预过滤：黑名单

在进行评分之前，显式黑名单会剔除已知的误报模式：截面标记（“SECTION C-C”）、网格参考字母、页码标识（“OF”）以及修订历史列标题。凡是匹配黑名单的候选项都会被直接剔除，不再参与后续评分。

空间位置

提取器将搜索限制在预期目标字段所在的文档区域内（工程图纸标题栏位于页面底部 30%、右侧 40% 的范围）。该区域以外的候选项都会被舍弃。同样的原则也适用于其他场景：发票号码通常在右上角，合同日期则出现在序言部分。

图 2：带注释的工程图纸

图 2 是一份代表性图纸，包含标题栏（右下角）及 REV 值“E”、修订历史表（右上角，常见误报来源），还有网格参考字母（边框位置，极易被误判为单字母修订值）。

锚点邻近度

靠近已知标签（“REV:”、“DWG NO”、“SHEET”）的候选项会获得更高分。与标签精确相邻（例如 “REV: E”）的得分最高；在同一区域内共同出现的得分则相对更低。

格式合规性

候选项会按照合规格式进行校验：带连字符的数字编号（1-0、2-0）、单个英文字母（A-Z）、双字母组合（AA、AB）以及特殊值（EMPTY、NO_REV）。凡是不符合格式的候选项都会被做降分处理。

上下文信号

证实候选项有效性的次要指标包括：邻近佐证标签（SHEET、SCALE、DWG NO 在附近出现）、与其他已提取元数据的一致性，以及同一区域内不存在相互冲突的候选项。

综合得分计算如下：

score = (40 * spatial) + (30 * anchor) + (20 * format) + (10 * context),

其中空间维度为二元判定（在边界区域内/不在边界区域内），锚点权重随着与最近标签的像素距离衰减，格式维度同样为二元判定（格式有效/格式无效）；上下文则用来捕获次要信号：邻近佐证标签（SHEET、SCALE、DWG NO 在附近出现）、与其他已提取元数据的一致性，以及同一区域内不存在冲突候选项。

具体示例

参考图 2，PyMuPDF 从图纸中提取文本，并在三个不同位置识别出字符“E”：位于右下角标题栏的 REV 字段内（紧邻图纸编号）、右上角修订历史表的最新条目处（附带备注“New Release”），以及右侧边框上的网格参考字母。三处字符完全一致，这也正是空间评分机制至关重要的原因。

网格参考字符“E”会因为无法通过空间过滤（处在标题栏边界区域之外，空间得分为 0.0）立即被舍弃。修订历史处的“E”通过了空间过滤（位于页面右侧区域，空间得分为 1.0）与格式校验（为合法单字母，格式得分为 1.0），但锚点得分仅为 0.2，原因是它处在 DESCRIPTION 列标题旁，而非 REV 标签旁；上下文得分为 0.0，因其周边标签（LTR、REVISION、DPT）与佐证标签集合（SHEET、SCALE、DWG NO）并不匹配，综合得分为 66。标题栏处的“E”空间得分为 1.0（处于边界区域内），锚点得分为 1.0（与“REV”标签直接相邻），格式得分为 1.0（合规单字母），上下文得分为 0.8（SHEET、SCALE、DWG NO 均在周边区域），综合得分为 98。系统以高置信度选定标题栏的“E”，直接输出结果，无需调用云端 API。倘若它的得分为 72（例如 REV 标签破损或缺失，仅能依靠位置做推断），则会被送入第二层进行云端核验。

路由阈值设置如下：90 分及以上直接输出结果（高置信度），50 至 89 分触发第二层校验，低于 50 分则启动完整云端提取。

验证方法与提示词迭代

通过分层抽样构建了包含 400 份文件的验证集，涵盖 PDF 格式（含文本型与扫描型，贴合语料库 7:3 的比例）、版本格式（五个类别均有样本覆盖）以及文档年份（1995 至 2024年，包含扫描质量与标题栏布局的各类变化）。真实标签由工程师手动标定，工程师逐份打开文档并记录版本 REV 值。对于模糊样本（扫描破损、版式特殊的文档），由第二位工程师独立复核数值。存在分歧的样本（约占整体的 3%），通过查阅实体图纸档案最终裁定。

系统提示词经过了五轮迭代，每一轮迭代均由一类特定错误触发：

每轮迭代都会在部署前对完整的 400 份文件数据集进行测试。仅优化某一类格式但会导致其他类别性能下降的更改会作为性能回归予以驳回。整体准确率从 89% 提升至 98%，历时三周、历经五个迭代周期，每个周期都专门针对当前占比最高的单一错误类型，而非盲目进行大范围泛化优化。

权衡分析

纯云方案与混合方案之间 2% 的准确率差距在脱离上下文的情况下具有误导性。纯云方案 98% 的准确率意味着仍有 2% 的文档会默认接收错误结果，且没有任何机制能够识别这类疏漏。对于工程图纸而言，错误的版本修订号可能会导致按照过时规格生产零部件，这类静默错误远比已知遗漏风险更高。混合方案的预审核准确率略低，仅有 96%，但由人工审核的 5% 文档可捕获剩余的错误，最终审核后的实际准确率可超 99%。核心问题不在于预审核数值谁更高，而在于产生的错误是静默隐藏还是被主动暴露。

云部署与运维

云推理应该被视为异常处理路径，而非默认的路径。本节中的每一项架构设计决策均遵循这一原则。

Azure OpenAI 治理

我使用 Azure OpenAI 服务（而非直接调用 OpenAI API），确保可以将文档内容保留在组织的 Azure 租户环境内。系统主动管理速率限制（严格控制在配额上限内，而不是等到触发 429 错误后重试）。图像以 150 DPI 分辨率渲染，因为针对 400 份文件验证集的测试表明，72 DPI 会降低扫描件的识别准确率，而 300 DPI 使会负载体积翻倍，却不会带来效果提升。预调用验证（旋转校正、空白页检测）防止了约 5% 的 API 调用被浪费。

可观测性

结构化日志会记录每层路由去向、置信度得分、处理耗时，以及每份文档的 Azure OpenAI 词元消耗量。漂移检测用于监控运行过程中第一层的成功率：若数值持续下降，说明语料库中的文档格式已发生变化。第二层调用失败时，采用指数退避策略进行重试（最多重试三次），之后再路由至第三层。对于产生幻觉的结果，绝不使用相同提示词进行重试。

模型升级即基础设施迁移

在 GPT-4.1 上运行稳定后，我使用相同的生产提示词在 GPT-5+ 上进行基准测试，针对相同的 400 份文件验证集且未对新模型做任何修改。整体准确率表现持平，两者均达到 98%。我按照文档类别对结果做了细分：文本清晰且标题栏规整的 PDF、打印质量欠佳的扫描件，以及过往易产生误报的特殊布局图纸。三类文档的表现均相差无几。GPT-5+ 既没有识别出 GPT-4.1 遗漏的文档，也未出现新的失败类型。提取任务本质是在限定文档区域内进行受空间约束的模式匹配，性能上限取决于系统能否锁定正确识别区域并设置合理判定规则，而非大模型自身的推理能力。

Azure 上的模型迁移工作（包含新部署、提示词重新验证、API 版本更新、速率限制测试以及完整验证套件测试）只在新模型能够为实际业务负载带来可量化的提升时才有价值。本次场景中新模型并无实质提升，因此我继续使用 GPT-4.1，规避了不必要的迁移成本与工作量。

多站点架构

该系统已从单站点命令行工具扩展为部署在四个工程站点上的内部 Web 应用。

身份验证与治理

用户通过 Azure AD 安全组进行身份验证。Azure OpenAI 服务主体采用权限受限的独立应用注册，与用户会话解耦。API 密钥存储在 Azure Key Vault 中，运行时通过托管身份进行读取，任何站点均无法直接访问凭证信息。

图 3. 多站点部署架构

图 3 展示了进行本地第一层提取的各站点节点，这些节点通过 Azure AD、密钥保管库及托管身份接入共享的 Azure OpenAI 环境。系统同时配备了站点本地文档存储，并支持元数据统一输出。

计算、存储与作业编排

本地提取任务（第 1 层）在每个站点自己的计算资源上运行。Azure OpenAI 端点是共享的，并在各站点之间分配速率限制配额，防止某一个站点的大批量作业挤占其他站点资源。每次提取任务均以批处理作业形式提交；Web 应用程序先验证上传的文件，将其写入暂存区域并加入作业排队。作业在每个站点内按顺序执行，但在各站点之间是独立并行运行的。上传的文档保留在站点本地存储中，只有结构化元数据（CSV 输出）传给下游资产管理系统所用的共享网络路径。因此，原始文档永远不会离开它们所在的站点。新站点上线需要部署 Web 应用程序、添加 Azure AD 安全组并分配速率限制配额，无需修改提取逻辑或 Azure OpenAI 部署配置。

该模式的局限性

当三个条件同时满足时，本地优先 AI 推理模式就会奏效：目标字段具备可预测的空间位置、语料库包含大量文本类文件，且任务仅涉及单一且定义明确的数值。若无法满足以上条件，则采用替代架构会更为合适。

无空间约定

对于自由格式文档（会议记录、普通信函），第 1 层不存在相关锚点，所有文档都会进入第 2 层。此时运行的是有额外开销的纯云架构。在这些情况下，可以直接跳过本地层，并投入精力设计结构化提示词，对输出结果进行模式验证。

以扫描为主的语料库

如果 80% 或更多的文档是扫描图像，本地提取几乎无法处理。此时应转向纯云架构，同时采用高效批处理、请求并行化，以及重复文档模板的缓存层方案。

多字段依赖

提取相互依赖的字段（发票行项目，其中数量、价格和总额必须一致）会让置信度阈值更难校准。采用结构化输出验证的云优先方案，由模型将所有字段以 JSON 格式返回，再通过后处理步骤校验内部一致性，这种方式远比依靠脆弱的跨字段规则做本地提取更为可靠。

快速变化的文档格式

黑名单与空间启发式规则均针对已知语料库做了适配调整。若文档格式频繁变动（如新供应商、新标题栏布局），第一层的识别成功率会下降，维护成本也随之增加。对于高度异构的文档来源，结合少样本提示词、并以格式检测分类器作为路由层的云优先处理方案，相比人工调校的空间规则，能够更平稳、顺畅地自适应适配。

查看英文原文：https://www.infoq.com/articles/local-first-ai-inference-cloud/"

前阿里Qwen负责人林俊旸再创业，新AI Lab估值136亿元

四月 — Thu, 14 May 2026 03:40:13 GMT

两个月前，林俊旸在 X 上用一句“bye my beloved qwen”告别千问，让 AI 圈为之震动。

震动的原因，不只是他顶着 “阿里最年轻 P10” 的头衔，更重要的是，他是把 Qwen 从阿里内部项目，一路推到全球开源大模型顶流的关键人物。

消息出来当天，投资圈和大厂就已经坐不住了。有人不停在圈里打听：“你认识林俊旸吗？求对接。”

今天，投资人等待的答案浮出水面。

据 The Information 最新报道，林俊旸正在为其新成立的 AI 实验室（AI Lab）寻求数亿美元融资。知情人士透露，如果本轮融资完成，该项目预计将达到约 20 亿美元，约合人民币 136 亿元。

消息称，高榕资本与红杉中国已就投资事宜展开接洽。随后，红杉中国通过投诉不实报道的形式，否认了已经投资。

目前，相关谈判仍在进行中，最终估值仍有变化可能。这家实验室的名称，也尚未正式对外公布。

林俊旸是谁？

林俊旸的履历放在 AI 圈里并不常见。没有海归博士光环，也不是硅谷大厂归来，而是在国内研究和工程环境里一路长起来的技术人。

他 1993 年出生，北大语言学硕士，2019 年以应届生身份加入阿里达摩院。

2022 年底，阿里重组 AI 团队，29 岁的林俊旸被任命为千问系列大模型技术负责人。

此后三年，他带着一支百余人的团队，把千问做成了全球开源模型的标杆：Hugging Face 上的衍生模型超过 20 万个，全球下载量突破 10 亿次，日均 110 万次，衍生模型数量甚至超过了 Meta Llama。

2025 年，他成为阿里最年轻的 P10，时年 32 岁。

在这个过程中，Qwen 团队规模长期只有百余人，而字节的 Seed 团队仅负责基础模型训练的就接近千人。资源不对等的条件下做到这个结果，也是林俊旸个人技术信用的来源。

20 亿美元，投的是什么？

对一家刚刚成立，更谈不上产品和成果的 AI Lab 来说，20 亿美元不是普通意义上的公司估值，更像是对创始人过往技术积累、模型经验和团队号召力的提前定价。

这条逻辑在硅谷的AI 圈已经被反复验证。

前 OpenAI 首席科学家 Ilya 创立 Safe Superintelligence，成立仅三个月完成 10 亿美元融资，投后估值 50 亿美元。前 OpenAI CTO 穆拉蒂创办 Thinking Machines Lab，首轮就拿到 20 亿美元，投后估值 100 亿美元。

两笔融资的底层逻辑是一样的：投资人买的不是现有产品，是这个人的技术判断力、以及他能吸引谁加入。

林俊旸走的是同一条路，只是折扣系数不同。国内同类初创的估值水平通常远低于美国同行，但 20 亿美元放在国内已是罕见的起点。

有风投分析指出，美国 AI 初创能拿高估值，部分原因是市场预期最终被科技巨头收购；然而，这套退出逻辑在中国能否同样成立，目前仍是变数。

另一个更真实的挑战，是算力。

林俊旸在今年 1 月的清华 AI 峰会上曾坦言，中国在算力上与美国存在一到两个数量级的差距，但他同时提出了应对思路：算法与硬件协同设计。

这是他接下来需要正面回答的结构性问题。

他要去哪个方向

新实验室的研究方向尚未对外披露，但有几个公开的线索可以参考。

去年 10 月，他曾在千问内部组建机器人与具身智能团队，并公开表达了对基础智能体方向的判断：“多模态基础模型正在借助强化学习演变为能使用工具和记忆、执行长程推理的基础智能体。”

离职前夕，他还在朋友圈分享了 Qwen Coding Agent 的招聘信息。这也说明具身智能和 Coding Agent 是他持续投入的方向，不是一时兴起。

但最能说明问题的，是 5 月 5 日他在 X 上转发的一条研究推文，来自于一名伯克利的计算机专业在读博士 Parth Asawa。

被转发的内容是一个名为“Continual Learning Bench 1.0”的新基准测试发布，用来衡量 AI 系统在在线环境中持续自我改进的能力。

当前的大模型框架有一个根本性的局限：训练完成即冻结，部署之后不会从真实交互中持续进化。主流的 Agent 框架也绕不开这个问题，工具调用、记忆检索只是在弥补，没有触及本质。

林俊旸转发的这个方向，瞄准的正是这个空白——让 AI 系统在使用过程中真正学习，而不只是调用。

把三个线索放在一起：具身智能、coding agent、持续学习，交汇点或许能够更清晰一些：能在真实世界中持续进化的智能体基础架构。

5 月 7 日，林俊旸清空小红书内容，更改昵称、头像和简介。

这个动作通常也意味着：新的叙事要开始了。

一条既有路径

林俊旸的故事，可以看作是中国 AI 人才迁徙潮里的一个切面。

从大厂出走再创业的 AI 技术领袖，在资本市场上已经形成了一套相对稳定的逻辑：在大厂担任过关键技术角色，积累技术声望和团队号召力，出走后投资人的响应速度往往比当事人自己还快。

阿里系出来的贾扬清，创立 Lepton AI 后被英伟达以数亿美元收购；百度系出来的景鲲，创办 Genspark 一年半融资三轮跻身独角兽。字节系的案例更多，不再赘述。

但对比看来，林俊旸的处境，似乎还有一点微妙的不同。

他不是功成身退后主动出走，而是在千问正高速上行的节点，因为组织战略与自身判断之间的矛盾，才被推着离开了自己一手建起来的项目。彼时，千问 App 月活刚跃居全球第三，马斯克才点赞他们的模型。

这种背景下出来创业，往往带着双重驱动：不只是要做出新的东西，更要证明原来那个判断是对的。

20 亿美元，就是资本市场对这种驱动力的报价。

参考链接：

https://www.theinformation.com/articles/former-alibaba-star-researcher-starts-new-ai-lab-seeks-2-billion-valuation

黄仁勋最后一刻登上访华飞机，英伟达中国市场再添变量

四月 — Thu, 14 May 2026 02:50:47 GMT

特朗普访华的随行名单里，直到出发前一天晚上都没有黄仁勋。

但反转来的就是这么突然。

根据Bloomberg最新报道，老黄在最后一刻登上了飞机（Last-minute addition），属于临时加入。随后也得到了白宫发言人 Steven Cheung 的确认，黄仁勋“行程有所变动”，然后“正好赶上了”。

这可能是特朗普此次访华随行企业家名单中，最值得科技产业关注的一个变化。某种程度上也意味着，英伟达的AI 芯片又重新回到了谈判桌，有了值得观察的新变量。

受该消息影响，英伟达美股夜盘直线拉升，涨幅超1%。

专机从华盛顿起飞，在阿拉斯加中途停靠，黄仁勋在这里“临时”登上飞机。黑色皮夹克，黑色双肩包，整装待发，和他每次登上发布会的造型一样。只是这次登上的是Air Force One。

随行的企业家里还有马斯克、库克、贝莱德的拉里·芬克、高盛的苏德巍等近 20 家美国大企业创始人或领导者。但黄仁勋是这个名单里唯一一位“最后一刻才加进来”的人。

此前，黄仁勋曾表示，如果获得邀请，他很乐意随行访华。和黄仁勋很乐意访华一样，英伟达当然也想回到中国市场。

从 95% 到 0

就在访华前不到两周，黄仁勋在接受采访时谈到：“In China, we have now dropped to zero。”我们在中国的业务，现在已经完全停滞了。

这个“零”的来路，是一段越退越后的三年。

2022年秋，A100和H100直接列入对华禁售清单，英伟达连夜推出削减互联带宽的A800和H800，塞进合规的口子。不到一年，A800和H800同样被禁。

然后是2024年推出的H20——算力只有H100的六分之一，有用户直接叫它“鸡肋”，但就是这颗鸡肋芯片，2024年仍然给英伟达带来了120亿到150亿美元的中国市场收入。

到2025年4月，H20出口也被叫停，且“无限期”生效。英伟达被迫计提约45亿美元损失，这是芯片行业史上单次最大规模的资产减值。黄仁勋的定性是：弄巧成拙，largely backfired。

H200本来还可以作为一道夹缝求生的细缝。

2025年12月特朗普放话允许出口，2026年1月13日BIS正式批准，条件是每笔销售收入的25%上交美国政府。《金融时报》指出，此前从没有任何美国企业同意过这种收入分成安排。中国商务部随即宣布暂停采购，称此举实质是“把芯片出口变成了技术租赁”。

据财新报道，目前已有中国云厂商拿到H200，但只能在海外部署算力，国内市场仍然悬而未决。黄仁勋在3月的GTC大会上说公司已重启H200生产，但谈判桌上的事，显然还没谈完。

这也是老黄要赶上这趟飞机的原因。

断供的三年培育了国产 AI 芯片

但英伟达最想回来的那个时间窗口，已经过去了。

三年出口管制，客观上促成了一件英伟达和美国商务部都没预料到的事：强迫中国AI产业完成了一次被动的全栈迁移。

字节、腾讯、阿里这些原本重度依赖CUDA生态的大厂，在无卡可用的压力下，不得不把训练和推理集群逐步迁向华为昇腾。迁移过程很痛，但一旦跑通，惯性就会反向积累。

昇腾的真正护城河从来不是单卡性能，而是它现在能提供的那套从芯片到MindSpore框架再到CANN软件栈的一体化交付——这在政企、金融、运营商这些对国产化要求最高的场景，是英伟达进来也很难打破的壁垒。

更有象征意义的节点发生在今年4月：DeepSeek V4发布，首个在昇腾950PR上跑通的第一梯队大模型，推理成本据称只有英伟达特供版的四分之一。

华为在去年全联接大会上公布的路线图，950、960、970一年一代排到2028年，传递的信号已经很清楚：这不再是应急替代，这是一个有自己节奏的独立体系。

IDC数据显示，2025年中国AI加速卡市场本土厂商出货量约165万张，市场份额首次突破四成，华为昇腾以81.2万张稳居第一。

护城河在收缩

当然，差距还在，而且在某些场景里相当实质。

超大规模基础模型的训练集群，国产芯片在多卡通信延迟和集群稳定性上仍和英伟达有代差。主流国产GPU还在7nm到14nm的制程区间里，英伟达已经进了4nm时代。软件生态的积累更不是靠两三年的追赶能抹平的。

所以目前头部大厂的状态，基本是训练侧能用英伟达尽量用，国产主打推理和集采场景。

但这个格局说明了英伟达的处境：它回来之后，拿到的不会再是三年前那种全场景的主导地位，而是几个特定场景里的补充选项。

中国AI产业第一次在自己的市场上，真正有了选择权。这是三年管制打出来最意想不到的结果，对英伟达来说也是最难受的地方——不是营收的问题，而是那道护城河窄了。

再回看“最后一刻登机”这个细节。

来，意味着要在牌桌上亮明立场，且谈判桌的条件未必比之前好；不来，中国市场的僵局又无法突破。

黄仁勋在阿拉斯加上了飞机，与其说是“正好赶上了”，不如说是：等到最后一刻，才确认这一趟无论如何也值得奔赴。

Netflix 推出“模型生命周期图”，扩展企业级机器学习

作者：Matt Foster — Thu, 14 May 2026 02:19:00 GMT

Netflix 概述"了一种用于管理企业级机器学习系统的、基于图的架构，并阐述了其内部的“模型生命周期图”如何映射数据集、模型、特征、评估、工作流和生产系统之间的关系。随着机器学习系统互联程度的日益提高，这种方法符合行业的广泛发展趋势——转向以元数据为中心的机器学习平台，可以提升可发现性、治理能力和复用性。

在最近的一篇工程博文中，Netflix 的工程师们描述了当组织在多个团队中积累了大量数据集、特征、管道、实验和已经部署的模型后，传统的机器学习工具将变得越来越难以管理。该公司认为，在规模化运行时，了解模型的来源、其所依赖的上游数据集，以及变更在下游系统中的传播方式，已经成为一项重大的运维挑战。Netflix 提出的解决方案是一个面向图的系统，它将机器学习资产及其关系视为首要的基础设施关注点。

图片来源：Netflix

模型生命周期图将机器学习实体表示为相互连接的节点和关系，而不是孤立的管道阶段。据 Netflix 介绍，这些图模型能够建模数据集、特征、模型、评估、工作流和生产服务之间的依赖关系，使工程师能够追溯血统关系，更好地理解变更对运营的影响。该系统还旨在提高可发现性，使团队能够定位可重用的机器学习资产，检查模型在整个组织中的构建和使用情况。

图片来源：Netflix

Netflix 工程师认为，图结构特别适合机器学习系统建模，因为机器学习资产很少是孤立存在的。一个模型可能依赖于多个数据集、衍生特征、评估工作流以及下游生产服务，而这些要素都会随着时间的推移独立演变。与传统上面向管道的机器学习基础设施视图相比，将这些关系表示为可遍历的图连接，能让团队更有效地进行影响分析、血统链检查和可复用组件的识别。

在内部， Netflix 将该架构视推动机器学习“普惠化”这一更广泛举措的一部分。该公司表示，与其将机器学习知识集中在专业平台团队手中，该图结构能够实现一种更自主的服务模式，让工程师和数据科学家能够独立发现数据集、理解依赖关系并复用现有组件。该博文指出，此举既能减少重复工作，又能提高所有权、治理及运营背景的透明度。

该架构反映了业界向以元数据为中心的机器学习和数据平台发展的趋势。类似的概念已经出现在诸如 LinkedIn DataHub" 这样的系统中——该系统将数据集、数据管道和所有权元数据之间的关系建模为图结构——以及聚焦数据血统的项目中，例如 OpenLineage"。随着机器学习部署在整个组织内的扩展，Uber 的 Michelangelo ML 平台"也强调了集中式生命周期管理、特征复用和可重现性。

这种方法也与 Spotify Backstage" 等内部开发门户体现出来的发展趋势相类似。在这些平台上，工程团队越来越多地采用基于图的表示方法来建模服务、基础设施、所有权以及运维元数据之间的关系。

尽管许多近期的 AI 工作流强调快速实验、自主工具和轻量级协调，但 Netflix 的“模型生命周期图”却将重点放在了可追溯性、依赖关系映射和组织级可视化上。这种设计表明，随着机器学习系统日益深入地嵌入到企业软件栈的各个层面，组织可能会越来越多地将元数据、血统追踪和生命周期治理视为核心的架构要求，而非次要的运营关注点。

原文链接：https://www.infoq.com/news/2026/05/netflix-ml-graph/"

AI Agent 沙箱的网络安全：从流量隔离到智能治理｜AICon上海

AICon 全球人工智能开发与应用大会 — Thu, 14 May 2026 02:00:00 GMT

阿里云高级技术专家王炳燊、技术专家李博康已确认出席 “Agent 系统架构与工程化实践"” 专题，并发表题为《AI Agent 沙箱的网络安全：从流量隔离到智能治理"》的主题分享。本演讲以阿里云 ACK 在生产环境的实践为主线，分三个层次展开：首先分析 Agent 沙箱场景独特的网络安全威胁模型；其次介绍他们自研的 TrafficPolicy CRD，如何通过 FQDN 域名白名单、优先级策略叠加和多链路规模化下发，解决当前生产中的隔离问题；最后介绍的计划上线的 L7 策略层——SandboxSecurityProfile，从流量隔离走向 Token 替换、内容审计、LLM 流量治理的完整安全管道。

王炳燊，阿里云容器服务 ACK 网络团队技术负责人，长期专注于云原生容器网络领域的研发与实践。主要工作涵盖大规模 Kubernetes 集群的 CNI 插件、网络策略引擎、eBPF数据面、RDMA 高性能网络及网络可观测性体系建设。

李博康，阿里云技术专家，负责阿里云容器服务 ACK 网络整体解决方案设计与落地，主导网络策略、大规模容器沙箱网络等核心能力建设，深度参与 Cilium 及阿里云开源社区贡献，持续构建高性能、高安全的云原生容器网络体系。他们在本次会议的详细演讲内容如下：

演讲提纲：Agent 沙箱为什么是个网络安全难题沙箱工作负载的特殊性：执行不可信代码、工具调用目标运行时才确定、每个租户独立隔离三类核心威胁：横向渗透（沙箱访问集群内其他服务）数据外泄（带着平台凭证访问任意外部 API）凭证滥用（Agent 直接使用 AK/Token 调用云 API，无法审计）为什么 NetworkPolicy 不够用：只有 IP/Port、无法做域名白名单、策略数量随沙箱规模线性爆炸为什么 Envoy sidecar 又太重：数千沙箱并发时资源开销不可接受TrafficPolicy：今天在生产中如何做API 设计理念：声明式、优先级叠加、Namespace 级与集群级双模型GlobalTrafficPolicy 设置平台安全基线，TrafficPolicy 让租户叠加工具白名单三类访问目标：CIDR / Service（含 Endpoint 展开）/ FQDNFQDN 的挑战：DNS TTL 竞态、IP 动态变化、多租户 DNS 归属难以区分解法：DNS 拦截 + IP 集合动态追踪 + TTL 陈旧缓存兜底规模化挑战与下发链路设计：数千沙箱并发 → nftables 规则集线性膨胀，编译和写入耗时直接影响启动时间三种部署形态并存（普通节点 / Kata 安全沙箱 / ECI 无节点），无法用同一条链路覆盖三条差异化路径：gRPC server-streaming 推增量、Shim 在进程启动前预置数据面保证首包前策略就绪、unix socket 旁路 API 处理 ECI 场景SandboxSecurityProfile：L7 治理的下一步为什么需要 L7：光有"能不能访问"不够，还需要"访问时做什么"展示 API 设计，逐段解释每个 action 的动机：CloudSecurityCheck：接入云安全中心，实时检测恶意域名IdentityInjection：每个沙箱注入身份标识，流量全程可溯源TokenTransformation：AK/Token 不下发给 Agent，由平台在流量层透明替换LLMAudit：LLM 请求/响应内容审计，满足合规要求Forwarding：强制走内部 LLM 网关，防止绕过管控直接访问外部模型 API技术实现路径：TLS 拦截（MITM CA）+ Envoy ext_proc 作为可插拔执行引擎与 TrafficPolicy 的关系：L4 是门，L7 是门里的检查站，两层叠加互补总结听众收益：建立 AI Agent/沙箱场景网络安全的完整威胁模型认知了解大规模沙箱场景下网络策略的工程挑战与解法看到一个面向 AI Agent 的 L7 安全策略的完整实现方案

更多详情可扫码或联系票务经理 13269078023 进行咨询。