InfoQ 推荐

Next.js 16.3 发布：即时导航、开发内存最高降低 90%，构建速度大幅提升

作者：Daniel Curtis — Mon, 24 Aug 2026 09:15:00 GMT

Vercel 正式发布 Next.js 16.3" 版本，这是该框架自去年 11 月发布 16.0 版本以来最大的一次更新：在为所有现有应用带来性能提升的同时，还提供了一个可选的工具集，叫作 Instant Navigations（即时导航）。

本次更新主要聚焦于开发体验。得益于默认启用的磁盘缓存和全新的内存回收功能，Turbopack 在 next dev 开发模式下的内存占用最高可减少 90%。Vercel 报告称，其自身仪表盘的内存占用从 21.5GB 降至 2GB；The Register" 也提到一位早期使用者的内存使用量从约 4GB 降至 1.5GB，评价称 “内存占用终于回归正常水平”。磁盘缓存机制也加速了 next build，在 CI 环境中重复构建速度最高可提升 5.5 倍。

类型检查速度也更快了。在升级本地依赖后，next build 可以运行 TypeScript 7"，微软官方宣称这个原生移植版本的速度大约提升十倍：

pnpm add -D typescript@^7

服务端渲染基于原生 Node.js 流进行了重构，不再使用 Web 流。Vercel 表示，无需修改任何代码即可在高负载下多处理最高 22% 的请求。Heise" 报道称，随着向 Node 技术栈迁移，边缘运行时已正式废弃。

本次更新新增的核心功能是 Instant Navigations。这是一个可选工具集，能在不放弃服务端架构模式的前提下将客户端单页应用的响应速度带到 Next.js 中。该功能基于去年 11 月推出的 use cache 指令构建，可通过两个配置标志开启：

const nextConfig: NextConfig = { cacheComponents: true, partialPrefetching: true, };

部分预取（Partial Prefetching）会将多个小型预取请求合并，为每条路由生成一份可复用的外壳（Shell）模板。Roboto Studio" 对此做过形象演示：侧边栏的 20 个链接原本会触发 20 次请求，现在只需要一次缓存外壳请求即可完成。全新的开发工具 Instant Insights 会自动找出所有无法实现即时跳转的导航行为；同时新增 Playwright 的 instant() 辅助方法，方便开发团队在上线前提前捕获性能退化问题。

Reddit" 上的开发者已经对内存占用降低 90% 的说法进行了实测，不过这些新增功能开关也存在一些注意事项。GitHub 的反馈讨论帖"列出了几个问题：静态导出与部分预取功能不兼容、全局 styled-jsx 样式可能在路由间泄漏、在 SST 上自托管时启用 cacheComponents 可能导致服务端渲染完全失败。Appwrite" 建议现在就可以升级，以便享受新版本带来的优化，但 Instant Navigations 应当按路由逐步接入。

新项目可以使用 npm install next@latest 直接安装默认版本；现有项目则可以先参考迁移至 Cache Components 的指南"，再启用新行为——该功能预计将在未来的主要版本中成为默认设置。

Next.js 正在回应长期以来的诟病——与单页应用相比，Server Components 的体验略显迟缓。它借鉴了单页应用即时加载外壳的思路，同时保留了服务端驱动的渲染模式。此外，它还进一步面向 AI 智能体驱动开发做了增强，为代码智能体生成版本匹配的 AGENTS.md 配置块，而 Astro" 和 TanStack Start" 等轻量级框架早已在该领域展开竞争。

Next.js 是由 Vercel 开发和维护的开源 React 框架。它在 React 的基础上扩展了基于文件的路由、服务端渲染，以及 App Router 的服务端组件等能力，广泛应用于各类项目，从小型静态网站到大型动态应用均有使用。

查看英文原文：https://www.infoq.com/news/2026/08/vercel-next-js-16-3/"

多个 AI 智能体“同住”一台 EC2：AgentCore 推出持久计算

作者：Matt Saunders — Mon, 24 Aug 2026 07:43:00 GMT

亚马逊云科技在 Bedrock AgentCore 新闻博客"中推出了运行时实例，增加了第二种计算选项。该选项在客户账户内的托管 Amazon EC2 上运行智能体，同时保留现有的 AgentCore API、身份和可观测性模型。该功能面向那些智能体已无法完全适应 AgentCore 最初推出的无服务器 microVM 会话 8 小时运行上限的团队。

首席开发者布道师 Sebastien Stormacq 在公告中解释说，运行时实例为智能体提供由 EC2 支持的持久会话，最长可以运行 14 天，并提供共享文件系统、支持 GPU 加速的实例类型，以及对 Python 和容器镜像的支持。多个智能体可以部署到同一个运行时中，并通过共享会话目录在同一主机上进行协作，而无须在每次交接时相互调用 API。Stormacq 指出，团队可以引入 CrewAI、LangGraph、LlamaIndex 和 Strands 等框架，而无须改变其打包模型，只需使用简单的 @app.entrypoint 装饰器以及 ZIP 文件或容器镜像即可。

运行时实例会替你处理所有这些工作，同时与现有 AgentCore Runtime microVM 中已经使用的相同 AgentCore API、身份控制和可观测性进行集成。- Sebastien Stormacq

这篇博客文章通过一个示例说明了运行时实例旨在支持的多智能体协作模式：多个专业智能体使用一个公共工作目录，处理代码、测试、文档和安全工件。

亚马逊云科技将运行时实例定位为 microVM 的补充，而不是替代品，并鼓励采用混合拓扑，由运行在 microVM 上的编排智能体将长时间运行的工作分派给实例上的工作智能体。InfoQ 此前报道了亚马逊云科技 AgentCore 功能的发展历程，包括最初的 AgentCore 发布"、为可互操作多智能体工作流提供的智能体间协议支持"，以及 Agent Registry" 和面向受治理智能体部署的 Loom 参考平台。

有几项功能应该会让智能体开发者感到高兴：智能体可以在共享会话中将彼此作为工具调用，自主迭代，直到工作完成。Sebastien Stormacq。

Enkompass" 的一篇工程指南深入介绍了支撑运行时实例的新型容量提供程序原语。容量提供程序定义允许使用的实例系列、操作系统、网络和存储，并充当智能体与 EC2 容量之间的契约，AgentCore 会代表团队对这些容量进行预置、修补和扩缩。团队可以设置实例数量下限和上限、目标利用率等边界，然后将一个或多个智能体运行时关联到该提供程序，并将会话生存时间设置为最长 14 天，从而避免直接管理自动扩缩组、启动模板或 AMI 流水线。

Enkompass 还强调，运行时实例最适合需要连续运行 8 小时以上、需要 GPU 或较大内存空间，或者能够受益于多个智能体部署在同一主机上进行紧密协作的工作负载。基于 microVM 的运行时仍然是短时间、突发式、请求—响应型智能体的默认选择，因为它启动迅速，能够隔离会话，并根据实际 CPU 使用量和最高内存用量按秒计费，最长运行 8 小时。该指南预计，大多数组织会同时运行这两种模型，将高流量、短生命周期的任务放在 microVM 上，并将实例保留给数量较少的长时间运行、有状态或大量使用加速器的工作负载。这些工作负载此前会迫使团队维护独立的 EC2 集群。

eCorpIT" 的一项成本分析重点讨论了运行时实例与 microVM 之间的财务权衡。运行时实例按照客户账户中所选实例类型的标准 EC2 费率计费，另加管理费。相比之下，microVM 按 vCPU 小时和 GB 小时计费，不单独收取管理费；对于持续 CPU 利用率较低且长时间处于空闲状态的智能体而言，microVM 可能更加便宜。成本分析表明，在不考虑任何 Savings Plan 折扣的情况下，运行时实例的盈亏平衡点约为 24% 的持续 CPU 利用率。由于运行时实例运行在客户账户中，Savings Plans 和预留实例等 EC2 承诺使用折扣适用于计算费用，但不适用于管理费。该文章认为，在单台主机上共同部署多个智能体，并在工作完成后停止会话，是控制实例成本的主要手段。

社区反应重点关注了这些集成点。Four Signals" 上的一篇简短分析将运行时实例描述为一项重要的基础设施发布，与智能体编排平台的兴起相呼应，并指出了由 microVM 编排智能体向基于实例的工作智能体分派任务的混合模式。daily.dev" 上的一篇摘要强调，14 天的会话上限、共享文件系统以及对流行智能体框架的支持，是该功能为开发团队带来的主要实际优势。工程师 Kosti Vasilakakis" 在 LinkedIn 上指出，运行时实例复用了现有团队已经使用的相同 AgentCore API 和会话固定模型，从而降低了采用这种新计算类型的阻力。

Microsoft 通过 Azure Foundry 托管智能体"采用了类似的方法。这些托管智能体会为每个会话预置虚拟机沙箱，并提供持久化主目录和文件存储；当会话在空闲或重启后恢复时，系统会自动还原状态。相关文档"介绍了该服务如何支持跨 Microsoft Teams 和 Microsoft 365 Copilot、具有托管生命周期的多智能体运行。

亚马逊云科技的相关文档可在 AgentCore 运行时实例页面"查看。

原文链接：https://www.infoq.com/news/2026/08/aws-bedrock-agentcore-runtime/"

“我们破坏了你们所有的应用”：React Router v8 引发争议，有开发者转向 TanStack Router

作者：Daniel Curtis — Mon, 24 Aug 2026 06:00:00 GMT

React Router 是广泛使用的 React 路由库，如今也是 Remix 框架的基础。该项目已发布 React Router v8"，新版本于 2026 年 6 月 17 日推出，刻意将破坏性变更控制在较小范围内，更新了基准版本，并承诺采用可预测的年度发布节奏。

React Router v8 更新了最低版本要求，改为仅提供 ESM 构建，默认启用中间件，并将多项未来标志转为标准行为。该版本还标志着 React Router v6 和 Remix v2 进入生命周期终止阶段，二者都将不再获得安全更新。

开发者关系经理 Brooks Lybrand 在 Remix 博客"上撰文，将该版本描述为有意保持波澜不惊，并解释说，团队过去几个主要版本的目标一直是让发布“尽可能平淡”。他还表示，“如果什么都没破坏，那就不算主要版本”，同时强调，v8 中的每一项破坏性变更，开发者都已经可以在 v7 中通过未来标志提前采用。

新的基准版本要求为 Node 22.22.0+、React 19.2.7+ 和 Vite 7+。为了对该库进行现代化改造，React Router 现在仅以 ESM 模块形式发布，tsconfig 的 target 和 lib 字段也已更新至 ES2022。包括 v8_middleware 和 v8_viteEnvironmentApi 在内的四个未来标志已被移除，其行为成为默认设置；splitRouteModules 则变为一个默认启用的顶层配置选项。

中间件成为基准能力引起了格外关注。在一篇题为《React Router v8 将中间件变为基准能力》的文章中，Roman Fedyskyi 写道"，这项变化推动前端团队“集中管理身份验证、日志和标头”，并认为“许多前端事故其实都是策略事故”。但并非所有报道都令人安心。byteiota 警告称"，对于一个每周 npm 下载量超过 5000 万次的软件包来说，“三项破坏性变更会让团队措手不及”。

Lybrand 在《React Router v8 及未来》"演讲中开玩笑说，他们“破坏了你们所有的应用，而且这样做只是为了惹你们生气”，以此回应 Reddit 上的质疑。一些开发者已经开始寻找其他选择。据 The New Stack 报道，在 Remix 与 React Router 合并后，部分开发者正在转向 TanStack Router"。TanStack Router 仍是主要竞争者，其卖点包括端到端类型安全和内置的 stale-while-revalidate 缓存；与此同时，Next.js 在 React Server Components 的成熟度方面继续领先。

迁移流程被设计得较为简单。官方升级指南"建议开发者在安装之前更新对等依赖项、采用未来标志并移除已弃用的 API。一项关键的弃用变更是移除 react-router-dom 软件包：

- import { Link, useLocation } from "react-router-dom"; + import { Link, useLocation } from "react-router";

DOM 专用 API 现在改为从 react-router/dom 导入。Netlify 和 Sentry SDK 已经支持 React Router v8，自发布以来，该项目还陆续推出了最高至 v8.3.0 的多个次要版本。

React Router 是一个采用开放治理模式进行开发的开源库，由 Shopify 团队维护，升级说明可在 reactrouter.com" 上获取。

原文链接：https://www.infoq.com/news/2026/08/react-route-v8/"

GitHub 公开预览 Stacked Pull Requests 功能

作者：Craig Risi — Mon, 24 Aug 2026 04:19:00 GMT

GitHub 宣布公开预览 Stacked Pull Requests" 。该功能原生支持将大型软件变更拆分为多个比较小的相互依赖的拉取请求，从而可以分别进行审查和合并。该功能旨在解决现代软件开发中一个长期存在的难题：如何在代码生成速度不断提升（尤其是借助 AI 辅助开发的情况下）与人类代码审查人员有限的处理能力之间取得平衡。

现在，开发人员不用再提交包含数百或数千行代码的单个拉取请求，而是可以将工作拆分为一系列比较小的拉取请求，每个请求都基于前一个请求进行构建。审查人员可以单独评估每一个逻辑变更。这不仅减轻了认知负担，还使得开发工作能够持续进行，不用等待整个功能完成后才开始审查。GitHub 的实现还保留了现有的分支保护规则、审查工作流和合并策略，使得分层开发成为现有代码库实践的自然延伸，而不需要单独的工作流。

本次公告的发布时机反映了软件行业正在发生的广泛转变。如今，AI 编码助手能在几分钟内生成大量可直接投入生产的代码，但代码审查仍然主要由人工完成。随着开发速度的加快，审查质量有可能会成为软件交付的主要瓶颈。

Stacked Pull Requests 试图通过缩小审查范围（而非加快审查本身）来解决这一问题。它不再要求审查者同时理解数十项互不相关的更改，而是让每个拉取请求代表一个单一的逻辑步骤，例如引入新的 API、更新数据库架构或实现特定的业务功能。审查范围越小，通常越容易理解、越容易验证，也越不容易因为某些更改疏漏而引入缺陷。

除了改善代码审查外，Stacked Pull Requests 还能优化开发流程。通常，大型功能需要一些基础性工作，而这些工作往往会阻碍后续开发，直到审查完成为止。借助分层变更，开发人员可以在早期工作的基础上继续开发，同时审查人员可以单独评估每一层。

这使得提交者和评审者之间能够进行更连贯的协作，同时减少了对长期存在的大型功能分支的需求——这类分支往往容易出现合并冲突和代码过时的问题。此外，这种做法还鼓励开发者将软件变更视为渐进式的架构改进，而非整体性的功能交付；而这种实践已被证实能降低部署风险并加快反馈速度。

尽管在 GitHub 上尚属新事物，但“分层开发”绝非新概念。Meta 通过其内部开发工具推广了“分层差异比较”（stacked diffs），而 Graphite 和 Sapling 等公司也围绕类似的工作流构建了专用的工具。此前，许多 GitHub 团队一直依赖第三方工具或手动分支管理来实现类似的效果。

通过将该功能直接集成到 GitHub 中，微软消除了此前阻碍其广泛采用的大部分运维负担。现在，团队可以利用熟悉的 GitHub 工作流来创建、审查、更新和合并相互依赖的拉取请求，而且不需要在工程环境中引入额外的工具。

近期研究"进一步印证了这一挑战。一项针对智能编码工具早期采用情况的分析发现，尽管由人工智能生成的拉取请求正变得越来越普遍，但成功的集成仍然高度依赖于人工监督。大多数项目在合并前，仍然需依靠一位经验丰富的审查者来验证智能编码工具生成的代码。另一项针对从业者观点的研究得出结论：代码审查已经成为决定人工智能是提升还是降低软件质量的关键控制点。因此，随着智能编码工具能力的不断提升，结构化的审查流程变得愈发重要。

包括 Graphite" 在内的多家公司已经构建了专门用于分层开发的平台，而为了降低交付风险，现代工程组织越来越重视小粒度拉取请求、主干开发、持续集成和增量部署。

这一趋势也与 GitHub 自身最近推出的创新功能相契合，其中包括：Copilot 编码助手"、CodeQL 增强功能、构建签名认证、基于 MCP 的密钥扫描，以及扩展的 AI 辅助开发工作流。所有这些举措表明，软件工程的未来将不再主要依赖于生成更多代码，而是更多地依赖于创建能够让人类与 AI 进行安全、透明地大规模协作的工作流。

随着 AI 不断加速软件开发的进程，诸如 Stacked Pull Requests 这样的功能可能不再仅仅是一个便利的工具，而是成为一种必要的手段。在代码生成日益自动化的时代，审查、理解并安全地集成这些代码的能力，可能会成为高绩效工程团队的核心竞争力之一。

原文链接：https://www.infoq.com/news/2026/08/github-stacked-pull-requests/"

Netflix 开源了一个用于因果推理的智能代理工作流

作者：Anthony Alford — Mon, 24 Aug 2026 02:44:00 GMT

Netflix" 开源了一个用于观察性因果推断（OCI）的智能代理工作流"。该工作流可以减轻因果分析过程中的繁琐工作。基于观察数据和人类用户的分析计划，该智能代理能够利用行为者-批评者循环来评估因果关系、撰写报告并提出后续步骤的建议。

该智能代理工作流基于 Netflix 现有的 OCI 工具构建。其目标是自动化易出错或重复性任务（如敏感性分析或跟踪多次迭代），将更高层次的任务（如问题构建和结果评估）留给人类用户。OCI 分析被定义为目标试验仿真"，即寻找能够解答该问题的最优 A/B 测试方案。Netflix 团队使用大西洋因果推断会议（ACIC）竞赛数据集"对该工作流进行了评估，发现其与各类基准系统相比非常“具有竞争力”。据 Netflix 说：

在因果推断中使用智能代理面临着一个挑战：在没有真实标注数据的情况下，我们如何评估智能代理在各项任务中的表现？为了应对这一挑战，我们的工作流程将流程审核与人工监督相结合。为了让其他人能够借鉴并评判这一工作流程，我们已经将一个轻量级的独立版本开源。我们希望，这项工作能激发更多在没有真实标注数据的情况下对智能代理进行评估的研究与开发。

人类分析师可以通过创建一个基于模板的 Jupyter 笔记本和一份分析计划来设置该流程。执行代理会根据该计划生成规格说明书，填写笔记本中的参数并执行笔记本。评审员审查笔记本的输出结果；对其进行评级：not_satisfactory、satisfactory_with_caveats 或 fully_satisfactory；并提出规格说明书修改建议。

OCI 智能代理工作流（图片来源： Netflix 博客" ）

为了展示该系统的实际应用，Netflix 发布了一份案例研究，介绍如何利用该工作流来评估新型娱乐内容（如游戏）对用户留存率的影响。分析计划将“干预变量”定义为接触新型娱乐内容的天数，将“结果指标”定义为 2 个月的留存率。作为基准对照，他们将该方案输入到 Claude 大模型中，由它自动执行简单线性回归，输出估算的效果值。

当研究团队使用 oci-agent 工作流时，得出的估算效果值“仅为基准值的 25%”。评审代理指出了几个问题，包括潜在的早期采用者偏差以及安慰剂测试失败。该工作流为智能代理提供了针对这些场景及其他场景的操作指南，并能自动使用调整后的参数进行多次分析。

Owkin 高级产品经理 Fabio Piazza 在 LinkedIn 上写道"：

Netflix 继续悄无声息地在应用人工智能领域树立标杆。他们不仅检查智能代理的输出结果，还让每个步骤都透明化。智能代理会发布计划、规格说明、流程图和手册，供人类检查并重新执行。他们将这些流程审计与人工监督相结合，并将工作分配给两个智能代理：一个负责运行分析，另一个负责评审分析结果并指出不足之处。这提醒我们：技术前沿不仅在于更优秀的模型，更在于围绕这些模型构建更完善的工作流程。

Indeed.com 软件工程总监 Taikai Takeda 在 X 上发文称"：

我对因果推断了解不多，所以如果我只是随口向大语言模型（LLM）抛出这个问题，它可能会做一些半吊子的回归分析，而我最终却会对此感到满意…… [OCI] 的设计初衷并非让智能代理直接输出答案，而是引导其遵循正确的步骤，同时留下可供专家后续进行验证的执行记录。这篇文章通俗易懂，其中包含了在公开数据集上开展的实验以及案例研究。在降低专业任务的入门门槛方面，AI 智能代理确实非常出色，不是吗？

感兴趣的读者可以从 GitHub 上获取 oci-agent 的源代码"。

原文链接：https://www.infoq.com/news/2026/08/netflix-oci-agent/"

完全相信AI代码的Uncle Bob，坦诚这条路还没走通

褚杏娟 — Mon, 24 Aug 2026 02:16:52 GMT

在AI代码极度普遍的当下，一直告诫开发者要严肃对待自己编写的代码的Uncle Bob，如今已经彻底放弃对 AI 代码逐行人工评审，转而在搭建一套依靠指标与约束条件的管控框架，这一做法在工程师群体当中引发激烈争论。

不是所有的软件工程领域的权威领袖都认同这一思路。统一建模语言（UML）联合作者、软件工程领域的奠基人物之一Grady Booch直接公开提出过反对意见。

“信任，但要核验。作为经验丰富的开发者，我可以凭直觉分辨代码好坏。但没有任何智能体，能够拥有同等的实战积累与业务上下文，做到这件事。”Booch说道。

Booch 会完整审核智能体生成的全部代码。在他看来，测试覆盖率和复杂度指标可以让我们对功能正确性抱有信心，却无法发现智能体是否引入安全漏洞、生成无效死代码悄悄侵蚀后续的可维护性，或是漏掉对性能至关重要的逻辑拆分。

那么，自动化指标，到底能不能替代资深工程师在长年职业生涯中练就的问题识别能力？

Uncle Bob为智能体设置了强约束体系：单元测试、Gherkin 验收测试、QA 测试流程、圈复杂度阈值、模块大小限制、依赖结构分析、变异测试（mutation testing）以及测试覆盖率要求。他的核心逻辑是：只要 AI 生成的代码能够全部通过这一道道关卡，即便没人读过一行函数内部实现，我们也有充分理由相信代码的正确性。

这套方案绝非纸上谈兵。单是变异测试这项技术，就会系统性改动源代码，以此检验测试用例是否真的能够捕获缺陷，其严谨程度已经超过绝大多数普通工程团队的人工评审流程。但这种模式需要前期投入巨大成本：想要把测试套件当作唯一质量关卡，需要极强的工程纪律，而绝大多数团队并不具备，也很难快速建立这套能力。

最近在Matt Pocock的播客节目中，Uncle Bob透露了自己的这套方案进度。AI 全权负责代码编写，他自己专注做好后续质量管控，这套模式运行得非常顺利。但在将自己的一整套架构规划流程全自动化时，暂时没有取得理想效果。他承认，现阶段 AI 做架构设计经常产出漏洞方案，架构、模块依赖管控仍然需要人类主导。

播客中，Uncle Bob介绍了自己当前的强约束约束方案和他现在的研发流程，他建议，放弃瀑布式重度前置规划，采用敏捷小迭代，即做完一小轮迭代后，人工复盘重构架构，再进入下一轮。开发者不必维护固定静态需求文档，可运行系统、自动化检测标准才是权威需求。他也不建议开发者不要直接下载使用自己的成品，而是理解工具逻辑后让 AI 复刻适配自己的检测工具。

他还强调了学习底层知识的重要性，认为新人必须亲手写代码，完整经历编码、调试、排错，不能全程只做 AI 提示词工程师。新人可以把自己当作 “人类智能体”，接受自动化检测约束，积累实战，再进阶做战略架构。通过阅读经典软件工程书籍，获取架构与战略思维，弥补 AI 时代架构反馈周期缩短但新人缺少历史踩坑经验的短板。

下面是两人的详细对话，我们进行了翻译和整理，并在不改变原意基础上进行了删减，以飨读者。

太长不看版

Q：如今人工智能和 AI 智能体已经普及，你的工作和编程体验发生了哪些变化？

A：现在，我的核心工作模式是全权交给 AI 智能体执行开发任务、运行各类检测工具，我的终极目标是彻底不用手动查看代码，完全信任 AI 的输出结果。

Q：为什么要耗费大量精力优化代码、搭建管控体系，而不是快速迭代？

A：即便 AI 智能体速度快、智能化程度高，但也和人类一样无法应对极度混乱的代码。只是它们的容错阈值和人类略有不同，但依然存在上限。

Q：有没有一些传统编程理念，在 AI 时代已经不再适用，需要被淘汰？

A：最核心的调整是复杂度阈值。AI 智能体的短期记忆能力远超人类，容量更大、精度更高，能处理更复杂的代码逻辑。第二个需要调整的是人工开发规范的落地方式。我一直是测试驱动开发的忠实拥护者，但这是适配人类开发者的工作准则，完全不适合强行约束 AI 智能体。

Q：在交给需求解析智能体之前，你会做多少人工前置规划？

A：我彻底放弃了重度前置规划，转而拥抱敏捷开发思路。不再一次性规划全部需求，而是让 AI 先完成单个、小型需求迭代，结束后人工复盘架构、优化结构，再推进下一轮迭代，逐步完善整体系统。这套模式无法彻底规避人工收尾、架构调整的工作，我目前也在尝试自动化优化，但暂时没有突破。

Q：很多人会让多个 AI 反复打磨需求文档，拿到完美方案后再落地开发，你如何看待这种模式？

A：如今编程的修改成本已经无限趋近于零，我们完全没有必要耗费大量精力做重度前置规划，快速迭代、持续优化才是最优解。

Q：新人该如何培养这种敏锐度？

A：新人没有这种实战积累，想要培养这种能力，最直接的方式就是研读经典老书。这些书籍虽然部分内容老旧，但核心的架构思维、工程理念、战略逻辑永不过时。新人研读这些内容，就能快速建立顶层认知，再结合 AI 实战体感，慢慢就能培养出战略思维。

Q：AI 可以替代一切，无需学习底层原理，你怎么看？

A：底层基础的价值从未改变。鼓吹基础无用的人，终究会付出代价。

“浴袍”出镜的Uncle Bob

主持人：从我成为开发者至今，甚至在我入行之前，他就深耕软件领域多年，如今更是在智能体Agent领域闯出了自己的一片天地。今天我们有幸连线身着浴袍的 Uncle Bob Martin，欢迎他来到现场。

主持人：真的非常荣幸能请到你。可能很多观众好奇你穿浴袍出镜的缘由，我们正好借此聊聊这个有趣的小细节。这件浴袍为什么成了你的标志性特点呢？

Uncle Bob：这件事大概发生在两年前。某天清晨，我穿着浴袍站在自家门廊上，突然有感而发，忍不住吐槽 SQL 的种种弊端。出于安全层面的考量，将文本语言作为数据库访问语言本身就很不合理，还会引发大量 SQL 注入漏洞之类的问题。

当时我就在浴室里，随手拿起手机即兴吐槽了一番，这段晨间浴袍吐槽视频就这样诞生了。没想到这段视频反响特别好，之后我就陆续多更新了几期晨间浴袍吐槽内容。

主持人：所以你今天也是带着这种随性的晨间状态来做客的吗？是不是还没喝咖啡，保持着清晨不想被打扰的状态？清晨六点就开始琢磨 SQL 问题，也太拼了。

Uncle Bob：其实现在已经上午十点了。（笑）我已经喝完第一杯健怡可乐，状态完全在线，没问题的。

主持人：那就好。看你现在换上了 polo 衫，状态满满。我的观众里大部分是开发者，但也有不少非技术观众，能不能给大家好好介绍一下 Uncle Bob 这个行业传奇人物，让非开发者也能了解你？

Uncle Bob：传奇谈不上，我只是一名普通的程序员，而且已经入行很久了，至今从业时长已经超过五十年。我第一次接触编程是在1964年，那年我十二岁。当时我生日，妈妈给我买了一台小型模型计算机，我通过在插钉上摆放白色小管的方式编写程序。那本质上是一个三位有限状态机，但当时这个小东西彻底勾起了我的好奇心，让我深深迷上了编程。

主持人：十二岁就接触编程，那五十多年后的今天，你是一步步走到如今的行业地位的？

Uncle Bob：从接触编程开始，我就疯狂汲取各类编程知识。父亲给我买了 Fortran、Cobol、PL1 相关的编程书籍，我全部通读了一遍。那时候没有电脑设备可以运行代码，我就把程序写在纸上，在脑海里模拟运行。十六岁的时候，我找到了第一份编写代码的临时工作，十八岁正式入职成为全职程序员，从那以后就一直深耕这个行业。

主持人：你深耕编程一线数十年，还写出了极具影响力的著作。你出版过好几本书，但其中有一本绝对是里程碑式的作品。我没记错的话，就是讲解代码整洁之道的《Clean Code》（代码整洁之道）。在软件工程领域，这本书绝对是被引用最多、影响力最广、认可度最高的经典著作之一。

终极目标：完全信任 AI 的输出结果

主持人：你在人工智能出现之前的时代，就已经深刻影响了整个编程行业，几乎见证了人工智能时代到来前软件工程的全部发展历程。如今人工智能和 AI 智能体已经普及，你的工作和编程体验发生了哪些变化？

Uncle Bob：去年圣诞前后，我第一次真切感受到了这种变革，当时颇感意外。在此之前，我也尝试过 ChatGPT、Grok 等各类 AI 工具，但一直没觉得有多惊艳。

直到后来我慢慢发现，这些 AI 工具的能力远比我想象的更强。我最先试用的是早期版本的 Grok 智能体，我让它帮我写代码，虽然完成质量不算高，但确实能生成可用代码。当时我正在做一个项目，索性就让这个智能体全程辅助我开发。

那段时间我一直要不停地修正它写出的代码，它总会写出各种不规范、冗余的劣质代码。我发现 AI 编码的优势是速度极快，但缺点也很明显，会拖慢我的整体开发节奏，让人十分头疼。

但我很快意识到，凭借极致的速度，AI 智能体能完成很多人类做不到的事。早在21世纪初，有两项技术理念让我印象深刻，但在当时完全不具备落地可行性。

其中一项是 CRAP 代码评估机制，它的核心逻辑是结合代码覆盖率、测试覆盖率与每个函数的圈复杂度，通过一套复杂公式计算出评分，以此判定函数代码的劣质程度。

21世纪初我就觉得这个理念非常好，当时我在一个大型项目中尝试套用这套机制，确实检测出了大量劣质函数。但问题是，我需要耗费海量时间逐一修改代码、重写测试用例，而项目本身能够正常运行，投入这么多精力优化得不偿失，最后我只能暂时搁置了这套方案。

另一项让我格外关注的技术是变异测试。这项技术的原理很有意思：通过程序遍历源代码，对代码中的正负号、大小于符号、等于符号等逻辑符号进行反转修改，随后运行全套测试用例。

正常情况下，代码逻辑被修改后，测试用例必然会报错；如果测试用例依旧通过，就说明存在“存活变异体”，代表这段代码存在测试漏洞，必须修复。

2000年左右，我在同一个项目中尝试了变异测试。当时单次完整测试需要四分钟，我需要重复运行数百次，只能通宵挂机测试。最后确实检测出了不少漏洞并完成了修复，但这套流程效率极低，根本无法融入常规的构建流程，完全不具备实用性。

去年年底到今年年初，我突然顿悟：AI 智能体运算速度快、不畏惧枯燥重复的工作，还能精准执行指令。我完全可以让 AI 自动运行 CRAP 代码检测工具，自动清理劣质代码；再让它运行变异测试。原本需要通宵完成的工作，现在三十分钟左右就能搞定，还能自动修补所有代码漏洞、完善测试覆盖。

AI 生成的代码往往存在大量冗余、不规范的问题，而这套组合工具刚好可以完美清理这些代码瑕疵。之后我持续迭代，为 AI 智能体搭配了更多自动化工具，不断优化协作流程，如今它们的工作质量已经非常出色。

现在，我的核心工作模式是全权交给 AI 智能体执行开发任务、运行各类检测工具，我的终极目标是彻底不用手动查看代码，完全信任 AI 的输出结果。

目前我只会通过核查 CRAP 评分、不定期抽查代码、运行全套定制测试等方式，验证代码质量是否达标。AI 编码速度远超人类，而我擅长把控整体质量、核查校验，所以我选择让 AI 全权负责代码编写，我专注做好后续的质量管控，目前这套模式运行得非常顺利。

AI 同样受代码腐烂折磨

主持人：也就是说，你的目标是逐步脱离代码编写和人工审核工作，搭建一套完善的代码管控体系，最大限度约束 AI 智能体的行为，规避它的出错风险。

这里我想抛出一个核心疑问：所有人都知道 AI 会写出劣质、混乱的代码，但 AI 开发速度极快，我们为什么要耗费大量精力优化代码、搭建管控体系，而不是快速迭代、等待漏洞自行修复呢？规整代码质量的意义到底是什么？

Uncle Bob：我在去年年底就发现了这个关键问题。我当时让 Grok 智能体持续迭代开发，发现如果不及时清理它产出的劣质代码，一味堆叠新功能，代码冗余和漏洞会持续累积。

随之而来的就是 AI 迭代效率持续下降，还会陷入恶性循环：修改一处代码，无意间破坏了另一处功能，反复修补、反复出错，最后原地打转、越改越乱。我甚至遇到过智能体直接停止工作、无法继续迭代的情况，虽然它没有直白说出这句话，但状态已经完全停滞。

这就说明，即便 AI 智能体速度快、智能化程度高，但也和人类一样无法应对极度混乱的代码。只是它们的容错阈值和人类略有不同，但依然存在上限。一旦代码混乱程度突破阈值，AI 就会迭代卡顿、漏洞激增、问题持续恶化，最终彻底无法推进工作。

主持人：所以你的解决方案是通过工具清理劣质代码。但大多数人的做法和你截然不同，大家遇到 AI 代码出错后，会不断给智能体补充提示词、新增规则指令，通过持续引导的方式修正问题，也就是“人工干预调控”。你为什么放弃这种方式，转而选择自动化检测工具呢？

Uncle Bob：我最开始也尝试过这种方式，在提示词里详细写明测试驱动开发规范、代码整洁准则、代码编写标准，最后整理出了长达数页的代码规范文档，甚至几乎把《Clean Code》的核心内容都录入了提示词。

但我很快发现，AI 模型对待这些明文规则，就像《加勒比海盗》里的准则一样，只是“参考建议”，可遵守可不遵守，不会严格落地。

背后存在一个核心技术现象，叫做“中间信息丢失（lost in the middle）”。

模型的上下文窗口存在注意力机制偏差，开头和结尾的信息权重更高、优先级更强，而中间的内容会被弱化、忽略。如果你的规范提示词过长，大部分规则都会落入上下文窗口的中间区域，直接被模型无视。可能开头几句核心规则还能生效，但几十条之后的规范，模型完全不会读取执行。随着迭代推进，上下文信息不断累积，模型根本无法筛选全部有效规则。

但自动化检测工具不会出现这种问题，规则固定、执行确定性强，不会被上下文窗口的机制影响。使用 AI 智能体的核心技巧，就是精简初始提示词，只保留最核心的规则，让所有关键信息都处于高优先级区域，剩余的规范约束，全部依靠后置自动化工具落地。

主持人：完全赞同。行业里有个很贴切的定义，把上下文窗口分为“智能区”和“迟钝区”，是 Dex Hardy 提出的概念。上下文窗口的前段token，模型注意力集中、判断力强，属于智能区；随着内容增多、token 累积，注意力机制会被稀释，就像嘈杂的人群里每个人都在发声，根本分辨不出有效信息，模型也就变得迟钝了。

所以你彻底摒弃了人工引导调控的模式，回归传统的自动化检测机制。这类检测工具不会占用上下文窗口的动态注意力，可以无限叠加。那是否存在“检测规则过多、过度约束”的情况？自动化检测是不是越多越好？

Uncle Bob：这也是我目前一直在研究的问题。显然自动化检测规则存在上限，一旦约束过多就会拖慢 AI 迭代速度，甚至比人工开发效率更低，那就得不偿失了。只要 AI 的生产效率依然高于人类，这套约束体系就是有效的。

就我目前的实测结果来看，即便叠加了大量检测规则、约束条件，AI 的开发效率依然是人类的2-4倍，优势十分明显。

我们添加的确定性工具，本质上是给 AI 搭建了一套迭代闭环：强制 AI 反复优化代码，直到通过全部检测，包括降低圈复杂度、补充测试用例、修复全部漏洞、规范代码格式等。这套流程会牺牲一部分迭代速度，换取极致的代码质量，我目前还没有摸索到这套平衡机制的上限。

现在，我正在搭建多智能体协作体系，让不同智能体分工协作、接力完成工作：一个负责开发实现，一个负责代码审核，一个负责专项测试，一个负责代码加固。虽然多智能体沟通会产生一定开销，但整体效率依然远超人工开发。

多智能体开发质量高于人工

主持人：我对多智能体系统非常感兴趣，这也是我一直存疑的方向。现在很多人鼓吹搭建多智能体团队，给每个智能体分配独立岗位、独立账号，实现全流程自主协作，但我一直不太认可这种模式。

但我个人更倾向极简分工：只区分开发实现和代码审核两个角色。开发智能体只需要完成基础功能开发、编写基础测试用例，不用追求代码优雅；审核智能体无需梳理业务逻辑，只需要针对开发产出的代码差异做精细化校验，同时可以叠加大量约束规则，因为审核场景的任务边界更清晰。

我想听听你的看法，你如何定义开发、审核、加固等不同智能体的分工价值？

Uncle Bob：多智能体精细化分工有两大核心优势。第一是支持并行工作，我的普通笔记本电脑可以同时运行三个以上的编码智能体，同步推进多项开发任务，大幅提升效率。

第二是精准控制上下文窗口，完美缓解“中间信息丢失”问题。给单个智能体分配单一专项任务，只需少量核心规则就能约束它的行为，规则落地率极高。同时，我会采用“即用即毁”的模式，智能体完成单次任务后直接销毁，下一轮任务启用全新智能体，保证上下文环境干净无冗余。

当然这套模式也存在弊端，智能体启动需要10-15秒的初始化时间，还要重新读取、梳理任务上下文，会产生一定耗时损耗。我目前的完整协作流程非常清晰：

首先由需求解析智能体，将人工撰写的需求文档，转化为 Gherkin 结构化验收测试用例和系统化 QA 测试流程。Gherkin 用例是高阶验收标准，QA 流程则是完整的系统测试方案，模拟用户操作界面、验证系统完整功能。

随后，编码智能体承接需求，根据结构化用例开发业务代码、编写单元测试，确保完全匹配需求、通过基础验收测试；代码开发完成后，交由代码清理智能体，运行 CRAP 代码检测、完成常规代码评审，清理编码智能体产出的冗余、劣质代码。

之后由代码加固智能体执行严苛的变异测试，实现100%代码覆盖率，逐一校验代码逻辑漏洞，修正所有潜在风险，这一步是保障代码稳定性的关键；最后由 QA 测试智能体，将标准化 QA 流程转化为可执行脚本，全自动操作系统、输出确定性测试结果。

整套流程走完，产出的代码质量会非常稳定、可靠。原本单个智能体需要五分钟完成、质量参差不齐的工作，这套多智能体闭环体系大概需要一小时完成，但对比人类半天的开发时长，效率依然提升了4-5倍，且代码质量远高于人工开发水平。

主持人：我发现了你这套模式的核心精髓。你不仅在管控上下文窗口的信息丢失问题，还在把控上下文的迭代轨迹。AI 会话的上下文存在固定轨迹，一旦在单次会话中定下某个基调、开启某项任务，后续所有迭代都会延续这个方向。

比如你让智能体做界面测试，它后续的所有修改都会默认附带界面测试逻辑。只有清空上下文，才能打破这种固有轨迹。所以开发智能体的迭代轨迹是“优先实现功能”，而加固智能体的轨迹是“极致完善测试覆盖”，分层分工刚好规避了轨迹混乱的问题，这个逻辑和你的实践完全契合吧？

Uncle Bob：完全契合。这是大模型普遍存在的特性，即便非编程场景也会出现。比如你和 AI 讨论咖啡冲泡技巧，中途上下文混入了电视剧相关内容，后续所有咖啡相关的回答，都会被电视剧信息干扰，模型无法区分有效信息、过滤冗余内容。

你提出的“迭代轨迹”非常精准。只要保持模型上下文方向统一、信息一致，就能有效规避幻觉、逻辑错位等问题。而多智能体分层校验、层层把关的模式，刚好能彻底规避这些风险。

AI 架构规划流程全自动化，还不行

主持人：我们聊了很多落地实现的细节，接下来想聊聊前置规划。自动化测试、代码检测固然能保障代码质量，但如果API设计不合理、模块结构规划混乱，后续的所有质检工作都会事倍功半。你在前期架构设计、模块规划上有哪些思考？

Uncle Bob：就在一个月前，我还在人工负责架构设计工作。我会让 AI 完成基础开发后，主动向它问询系统结构、模块关联、依赖关系等核心问题。很多时候 AI 给出的架构答案漏洞百出、问题重重，我会基于经验重新规划模块拆分逻辑、定义模块间的通信规则，输出明确的落地方案，再交由 AI 执行开发。

为了提升架构管控效率，我让 AI 开发了架构可视化工具，可以实时生成 UML 结构图，清晰展示系统模块化结构、依赖链路。我可以点击任意模块查看子模块细节、逐层研究，最终直接查看对应源码，实现全层级架构可视化管控。

同时，我搭建了一套确定性检测工具，明确定义模块间的依赖规则：哪些模块可以相互依赖、哪些禁止依赖、依赖链路的流转规范，全部写入固定配置文件，AI 绝对不能违规。最后会有专属检测程序校验架构合规性，一旦 AI 打破依赖规则，就必须通过反转依赖、新增接口、拆分模块等方式整改修复，强制保证架构规范。

目前我正在尝试将这套架构规划流程全自动化，但暂时还没有取得理想效果。

主持人：我和你有一模一样的体会。合理的模块架构能带来巨大的收益，你能具体说说优质模块化结构的核心价值吗？

Uncle Bob：核心逻辑和整洁代码的价值完全一致。边界清晰、接口规范、分工明确的模块，无论是人类开发者还是 AI 智能体，都能轻松理解、精准把控。

人类擅长模块化拆分思考，AI 模型也是同理，只是容错阈值略有差异。只要单个模块职责单一、迭代轨迹清晰，模型就不会被杂乱的业务逻辑干扰，高效完成开发工作。

反之，如果一个模块堆砌各类无关功能、逻辑混乱，AI 根本无法明确工作重心，迭代效率和质量都会大幅下滑，和人类开发遇到的困境一模一样。

主持人：没错，优质架构能最大化发挥测试体系的价值。我一直非常认同 John Ousterhout 的深度模块理论：劣质的浅层模块接口繁杂、内部逻辑单薄，优质的深度模块接口极简、内部封装大量核心逻辑。这套理论似乎完美适配 AI 开发模式，AI 只需读懂极简接口，无需深究底层实现逻辑，就能完成高效开发，这也是你的核心思路吗？

Uncle Bob：完全正确。大模型会重点关注代码结构和接口定义，依托规范的模块接口，它可以无需解析底层源码，直接完成开发迭代。这既是优势也是风险点，只要底层代码逻辑统一规范，就能规避风险、放大优势。

同时 AI 会通过读取测试用例理解系统功能，所以代码结构、模块设计越规范，AI 对业务的理解就越精准，开发质量自然越高。对了，这本书的附录里，我和 John Ousterhout 专门针对这个话题展开了详细辩论，过程非常有趣。

AI开发普及，需要对《Clean Code》做什么调整

主持人：结合当下 AI 开发的时代背景，你会对《Clean Code》的内容做哪些更新和调整？我们之前聊到，传统的代码规范、质检体系在 AI 时代依然适用，只是落地方式变了。但有没有一些传统编程理念，在 AI 时代已经不再适用，需要被淘汰？

Uncle Bob：最核心的调整是复杂度阈值。AI 智能体的短期记忆能力远超人类，容量更大、精度更高，能处理更复杂的代码逻辑。

以往我对人类开发者的要求是，CRAP 评分控制在4以下；现在针对 AI 开发，我把阈值调整到了6，后续可能会放宽到8。这个阈值对应的核心指标是圈复杂度，代表函数的逻辑分支数量。CRAP 评分为6，意味着函数存在6条独立逻辑分支，且全部被测试用例覆盖，这在 AI 开发场景下是完全可控的。我也多次和 AI 验证过这个标准，适配性非常好。

第二个需要调整的是人工开发规范的落地方式。我一直是测试驱动开发的忠实拥护者，但这是适配人类开发者的工作准则，完全不适合强行约束 AI 智能体。

人类适合“写一行测试、写一行业务代码”的迭代节奏，但 AI 不适用这种模式。即便我在提示词中强制要求严格执行测试驱动开发，AI 最终还是会回归“完成函数开发、再补充对应测试用例”的模式，和 John Ousterhout 提倡的节奏一致。

所以，我的核心结论是：人类的编程价值理念依然通用，但人类的开发行为规范、操作阈值，需要针对 AI 全面调整，不能直接照搬套用。

“没有必要耗费大量精力做前置规划”

主持人：这个总结太精辟了。测试驱动开发的本质，是弥补人类短期记忆不足的短板，而 AI 不存在这个问题，所以无需照搬这套流程。

我们聊完了代码实现和规范，再来聊聊前置规划。在交给需求解析智能体之前，你会做多少人工前置规划？如果前期需求规划出错，后续整套智能体迭代闭环都会做无用功，你是如何规避这个问题的？

Uncle Bob：很多人会陷入“极致前置规划”的误区，让人工把需求打磨到完美，再交给 AI 执行，这是几十年前瀑布式开发的老路。

我本周刚好在测试这种模式，结果和以往一样，彻底失败。无论前期规划多么细致，人类都无法穷尽所有场景，AI 也不具备人类的全局思考能力。执行过程中，AI 总会出现规划外的偏差，我们只能反复暂停、重构规划、重新迭代，效率极低。

所以，我彻底放弃了重度前置规划，转而拥抱敏捷开发思路。不再一次性规划全部需求，而是让 AI 先完成单个、小型需求迭代，结束后人工复盘架构、优化结构，再推进下一轮迭代，逐步完善整体系统。

这套模式无法彻底规避人工收尾、架构调整的工作，我目前也在尝试自动化优化，但暂时没有突破。

主持人：我完全认同。当下的开发模式中，代码编写的工作量已经被 AI 极致压缩，但前置需求规划、后置质量复盘的工作量，几乎和以前持平。现在业内流行“需求驱动开发”，很多人会让多个 AI 反复打磨需求文档，拿到完美方案后再落地开发，你如何看待这种模式？

Uncle Bob：AI 非常擅长撰写需求规划文档，还会主动丰富细节、美化方案，看起来无可挑剔，但落地执行时一定会漏洞百出。

我的多次实验证明，纯粹的需求驱动开发模式并不适配 AI 时代，最优解依然是敏捷迭代：小步快跑、快速反馈、迭代优化、实时重构。我之前经常用建房举例，如果修改房屋设计的成本极低，你根本不会提前花高价请设计师做完美图纸，再一次性施工。你会先打地基、再调整格局、逐步优化，边搭建、边修改、边完善。

如今编程的修改成本已经无限趋近于零，我们完全没有必要耗费大量精力做重度前置规划，快速迭代、持续优化才是最优解。

主持人：我非常反感现在泛滥的需求驱动开发标签。很多人把所有前置对齐、需求梳理工作都定义为需求驱动开发，甚至把提示词工程也归为此类，概念太过泛化。你是否会在代码仓库中留存、固化所有需求文档，还是说需求本身是临时、可迭代的？

Uncle Bob：我不会留存固定的需求文档，所有需求都是临时可变的，会根据迭代情况实时调整。

传统开发中，人类编写的源码就是最终的需求落地形态，是唯一的刚性标准。但现在源码由 AI 编写，不再是人类的直接产出，很多人会因此缺失安全感，执着于留存固定的前置需求文档。

但在我看来，最终落地的可运行系统、可通过的检测标准，才是真正的需求。我也不建议大家直接下载使用我开发的 CRAP 检测、变异测试等工具，大家应该让 AI 读取我的工具逻辑，自主复刻、定制适配专属工具，这才是真正掌握核心需求的方式。

新人要把把自己当成“人类智能体”

主持人：这也是 AI 时代很奇妙的一点：AI 会认真读取人类给出的所有参考资料，但人类几乎不会细看 AI 产出的海量代码，信息交互完全单向，非常有意思。

最后我想请教一个核心问题。John Ousterhout 把编程分为战术编程和战略编程，战术是一线落地执行，战略是全局架构规划、方向把控。AI 极其擅长战术编码，但完全不具备战略思维。如今所有基础战术编码工作都被 AI 替代，新手开发者该如何学习战略编程、培养顶层思维？你对新人成长有什么建议？

Uncle Bob：这是当下行业最核心的问题，我也没有完美答案，但我可以分享我的思考。

首先，新手必须亲自手写代码，积累足够的实战经验。不用过长，但一定要亲身经历编码、调试、改错的全过程，才能理解 AI 面对的底层问题，看懂代码背后的逻辑，否则永远无法建立顶层思维。

其次，入行后的新人，应该把自己当成“人类智能体”。在重度使用 AI 的团队中，资深工程师负责战略规划、架构设计，新人承接 AI 级别的基础任务，接受和 AI 一样的自动化检测约束。这个阶段的工作效率会很低，但能快速积累海量实战经验。熬过这个阶段，才有资格把控 AI 工作、做顶层战略设计。

另外，新手必须补齐底层基础。十年前我就建议开发者，即便日常使用高级语言开发，也要抽空学习汇编语言，搞懂底层运行逻辑，跳出上层语法的“虚拟幻境”。这套逻辑现在依然适用。新手必须从二进制、汇编、C 语言等底层知识学起，再到高级语言、AI 工具协作，逐层搭建认知，最终才能具备管控 AI、做战略编程的能力。

主持人：但有一个现实问题，战略编程的反馈周期极长，传统开发模式下，架构设计的失误可能半年后才会暴露，很多新人根本等不到反馈就已经离职转行，永远学不会顶层设计。但 AI 时代加速了整个流程，战略失误会快速暴露。你当初是如何快速发现 AI 的代码存在严重问题的？新人该如何培养这种敏锐度？

Uncle Bob：初期我只是直观看到代码混乱，但真正让我意识到问题严重性的，是 AI 的迭代卡顿、逻辑死循环。我亲身经历过传统开发中代码混乱带来的所有问题，所以能一眼识别 AI 的困境。

新人没有这种实战积累，想要培养这种能力，最直接的方式就是研读经典老书。Tom DeMarco、Ed Yourdon 等人的著作，还有《程序员修炼之道》这类经典书籍，沉淀了几十年的行业经验。这些书籍虽然部分内容老旧，但核心的架构思维、工程理念、战略逻辑永不过时。新人研读这些内容，就能快速建立顶层认知，再结合 AI 实战体感，慢慢就能培养出战略思维。

主持人：所以归根结底，软件工程的底层基础依然至关重要。现在很多人鼓吹“基础无用论”，认为 AI 可以替代一切，无需学习底层原理，你怎么看？

Uncle Bob：底层基础的价值从未改变。Dijkstra 曾说过，软件是人类创造过最复杂的事物，远超其他所有工程体系。软件工程的底层基础，本质是用来拆解、组织、梳理复杂系统的方法论，这套逻辑不仅适配人类，也适配仿生人类的 AI 模型。

鼓吹基础无用的人，终究会付出代价。AI 虽然强大，但依然会撞上复杂度的天花板，而掌握底层基础、架构思维的开发者，才能突破瓶颈、把控全局。只是 AI 延缓了问题暴露的时间，并非彻底消除了问题。

主持人：这是行业迭代的必然规律。从二进制到汇编、再到编译器、如今的大模型，每一次抽象层级升级，都会有人高呼“底层基础无用”，但最终都会被验证是错的。所有被抛弃的底层规则，终有一天会被重新拾起，因为核心逻辑从未改变。

Uncle Bob：没错，亘古不变。

原文链接：

https://www.youtube.com/watch?v=zcLPGC-tvgk"

DeepSeek 再度调价；英伟达AI服务器涨价超 15%；“AI红娘”承诺三年不结婚就退款，前 Kimi搜索负责人创业目标：拉高10%结婚率 | AI周报

傅宇琪,褚杏娟 — Mon, 24 Aug 2026 02:11:16 GMT

DeepSeek API 价格再调；GPT-5.6 Sol 模型价格下调， Codex额度问题引争议；英伟达 AI 服务器涨价超 15%；宇树上市开盘涨超 6 倍后大跌19%，有中签者说幸亏全卖了；“AI红娘”承诺三年不结婚就退款，前 Kimi 负责人立志拉高结婚率 10%；奕境X9发布会送假Labubu？品牌方回应；人均557万元！寒武纪124名员工股票激励“大红包”即将到账；曾主导 AI 眼镜等项目，字节AI穿戴核心产品负责人刘锐离职；钉钉全球商业总裁杨猛将离任，下一站蚂蚁集团；原xAI多模态理解负责人蔺旭东加入混元大模型团队；韦东奕账号时隔一年多更新，上架自编小学数学练习册销量已破万……

行业热点

大模型一周大事

DeepSeek API 价格再调

DeepSeek 将于北京时间 2026 年 8 月 23 日（周日）00:00 起，对峰谷计费规则做出调整，北京时间周末（周六、周日）全天不再区分峰谷时段，统一按照低谷时段价格收取调用费用。

空闲时段价格为高峰时段价格的一半。高峰时段为北京时间 9:00 - 12:00、14:00 - 18:00（其余为空闲时段）。将于北京时间2026年8月23日（周日）00:00起，对峰谷计费规则做出调整，周末（周六、周日）全天不再区分峰谷时段，统一按照低谷时段价格收取调用费用。发送给 deepseek-v4-flash-vision-exp 的图片会按其尺寸换算成 token，与文本 token 一并计费。换算规则详见图像理解：Token 用量。

相比 8 月 17 日上一轮峰谷定价，此次 DeepSeek 主要调整周末计费规则，周六、周日全天统一执行低谷价，工作日峰谷价格不变。

此前，8月17日，DeepSeek API正式涨价。DeepSeek官方公众号8月13日曾发布消息称，对DeepSeek API价格进行更新调整，采用峰谷定价，空闲时段价格为高峰时段价格的一半。高峰时段为北京时间9:00-12:00、14:00-18:00(其余为空闲时段)。

以旗舰模型DeepSeek-v4-pro为例，高峰时间段，V4 Pro每百万tokens输入（缓存未命中）9元，涨幅200%；输出27元，涨幅350%；缓存命中输入0.3元，涨幅1100%。空闲时间段，V4 Pro每百万tokens输入（缓存未命中）4.5元，输出13.5元，缓存命中输入低至0.15元。DeepSeek-V4-Pro正式版于8月13日发布，该版本增强了 Agent 能力。当时，DeepSeek-V4-Pro价格是轻量级模型V4 Flash的大约三倍。以每百万tokens计算，V4 Pro输入是0.025元（缓存命中）和3元（缓存未命中），输出则是6元。相比之下，V4 Flash对应的价格分别为0.02元、1元和2元。

据了解，DeepSeek此次推出峰谷定价的核心初衷，是平衡日间算力拥堵问题。借助市场化价格杠杆，引导企业开发者错峰调度大模型任务，分流高峰算力压力，从而提升整体平台运行稳定性。

GPT-5.6 Sol 模型价格下调， Codex额度问题引争议

OpenAI 宣布未来 3 个月内将 GPT-5.6 Sol 的 API 与 Credit 调用价格下调 20% 以上，其中每 100 万 Tokens 输入从 5 美元降至 4 美元、输出从 30 美元降至 20 美元，缓存及长上下文档位价格也同步下调，该功能已在 API 上线并面向 ChatGPT Work 和 Codex credits 方案推送，Pro、Plus 和 Business 订阅方案的使用规则及权益保持不变。此外，OpenAI 还下调了 GPT-5.6 Luna AI 模型费用。

近期，大量 Codex 用户发现，自己的周额度突然变得特别不经用。社区通过 NerfTrack 等工具追踪发现，有 Plus 用户的周额度从约 160 美元降到 80 美元，直接砍半；还有 Pro 5x 用户从约 674 美元降到 157 美元，缩水约 77%。这和之前的水平差距非常大。

随后，Codex 团队的 Tibo 回应称，OpenAI 并没有偷偷修改额度，部分异常用户其实使用了 Sub2API，将订阅转成 API 再共享或中转，从而触发了风控。但网友显然不买账，因为大量用户表示，自己从没用过 Sub2API，老老实实用官方 Codex，额度照样缩水。

随后，其表示本周 Codex 活跃用户数量已经达到了 2000 万。为庆祝，将为每一位使用 Codex 和 ChatGPT 工作的用户提供一次免费的重置功能，用户可以随时使用这个功能。

针对在使用限制导致资源消耗加快的情况下，Tibo 表示没有观察到任何异常现象。在之后的推文中，Tibo 表示发现了一些用户的缓存命中率要比之前更低，或许这是造成用户资源消耗快的原因。

英伟达 AI 服务器涨价超 15%

8 月 23 日，《彭博社》报道，随着内存芯片成本大幅上涨，英伟达部分最大客户已被告知，搭载其 AI 芯片的服务器价格在将上涨超过 15%。

此次涨价将从明年初出货的系统开始生效，涉及包括旗舰 Vera Rubin 和 Grace Blackwell 芯片在内的系统，具体涨幅将取决于英伟达芯片的代际以及内存配置。为微软、谷歌、甲骨文等大型数据中心运营商代工服务器的企业，近期已经向客户通知即将到来的价格上涨。

即便是行业中占据绝对主导地位的英伟达，也无法维持原有价格或自行消化不断上升的成本，这显示出在 AI 基础设施需求激增之际，三星电子、SK 海力士和美光等内存芯片厂商拥有强大的议价能力。包括苹果、高通在内的多家大型科技公司近期都表示，由于芯片短缺，不得不提高旗下产品的价格。

黄仁勋女儿探访多家中国机器人企业

8 月 21 日 2026 世界机器人大会首日，英伟达物理人工智能平台产品与技术营销高级总监黄敏珊（黄仁勋之女）到场，参观越疆、光轮智能等多家机器人企业展台，体验普勒机器人产品，还到访京东展区了解其机器人相关体系与演示，多次赞叹。

黄敏珊长期主导英伟达 Omniverse 平台及机器人产品线市场工作，是英伟达物理 AI 与机器人生态战略核心推动者，此次到访释放出全球算力巨头与中国具身智能头部企业协同，正从芯片、模型层面向真实物理世界延伸的重要行业信号。

宇树上市开盘涨超 6 倍后大跌19%，有中签者说幸亏全卖了

8月20日，宇树科技低开6.51%，截至收盘，宇树科技大跌近19%，总市值跌破2800亿元。8月19日，该股以1100元/股、629%的涨幅开盘，中一签最高浮盈超47万元，但开盘后股价迅速从高点回落，震荡加剧。面对8月20日行情，多位首日清仓的中签者直言“庆幸”。炒股七八年的李萌（化名）对中新经纬表示：“本来还感觉卖少了亏了，今天再回看，幸亏全卖了！”她回忆，若开盘时挂低点卖出可赚40多万元，最终她在股价回落至899元附近时分两笔卖出，500股净赚超37.32万元。李萌透露，这笔收益将用于配置国债或定期理财，她也会继续坚持打新。另一名福建中签者小枝也在上市首日清仓，获利约38万元。她表示自己一贯坚持“首日即卖”的策略，此前中签的皓元医药曾赚13万多，近期又连续中签长鑫和宇树，“我偏财运挺好的”。不过她明确表示不会再入手宇树科技，“钱取出来直接用，不打算继续买票了。”

开盘当日，公司创始人王兴兴在与领导嘉宾和承销团合影环节，全程表情极为平静，像一个来上班的“打工人”，鲜有企业家敲钟上市的雀跃神态。上市仪式结束后，他与高管们乘坐电梯而下，也始终低头看手机。上市后，宇树科技举办答谢午宴，在敬酒环节中，王兴兴面露笑容举杯回应来宾祝贺，整个人松弛而自然。

完成常规致谢后，王兴兴没有就此结束，而是突然把话题转向技术，开始讲述宇树上市后真正准备投入的一套系统。他认为AI 不只会成为机器人的大脑，还会进入机器人的研发过程，帮助人类设计、训练和迭代机器人。搭建这样一套系统的循环将是具身智能企业最重要的竞争力。今天，要让机器人学会一项新技能，工程师仍然需要手工推动多个环节。王兴兴认为，这套开发方式仍然非常原始。AI 已经具备编程、信息检索、视频生成和结果分析能力，完全可能把这些环节逐步连接起来。

按照他描述的路径，AI 首先自动查询最新论文和开源代码，选择可能适用的方案，生成机器人的训练程序。代码随后进入仿真环境，也可以借助视频生成模型构造训练环境和素材。完成仿真后，训练结果被部署到实体机器人上。机器人能否保持平衡、动作是否准确、任务成功率有多高，都需要在真实世界中重新验证。在王兴兴看来，这套系统可以持续借用全球基础模型的进步。即使宇树自身的编程能力没有同步提升，只要底层模型变强，自动搜索、编程、训练和评价的能力也会一起提高。

“AI红娘”承诺三年不结婚就退款，前 Kimi 负责人立志拉高结婚率 10%

近日，AI婚恋创业品牌良配科技引发行业关注，公司提出“用户三年未结婚全额退款”的颠覆性机制，并定下推动国内结婚率提升10%的长期目标。目前良配科技正推进第二轮融资，估值达3000万美元，已对接腾讯、阿里、美团等多家大厂战投部门。

良配科技创始人曾歆勋为94后创业者、南方科技大学2019届毕业生，曾在微信、TikTok负责搜索推荐业务，曾任Kimi AI搜索负责人。2025年5月，其放弃千万期权全职创业，All in AI婚恋赛道。创立之初，曾歆勋与今日资本徐新仅沟通3小时，便敲定1500万元天使轮融资，获顶级机构重仓加持。

针对传统婚恋平台痛点，曾歆勋指出，行业长期存在核心逻辑悖论：传统订阅模式依靠用户长期单身、持续付费盈利，导致平台与用户利益完全对立，普遍存在无效社交、匹配效率低等问题。为此，良配科技打造全新反向产品机制，将平台收益与用户脱单成果深度绑定。

产品采用多项反互联网常规设计：注册用户需与AI红娘完成20分钟深度沟通，精准筛选诚意用户；同一时间仅支持一对一匹配，主动舍弃行业常规的留存、活跃数据；推出三年未婚全额退款政策，以机制倒逼平台专注真实脱单转化。

据了解，良配团队共 18 人，9 人负责研发，其余 9 人覆盖产品、设计、运营、增长；产品上线仅 40 天，累计注册用户约 10000 人，主要分布在北上广深、成都、杭州 6 座城市。

奕境X9发布会送假Labubu？品牌方回应

8月19日下午消息，近日有车主反映称，参加南昌当地奕境X9预售发布会，签到礼品可以选择领取Labubu盲盒一个，拆开后却发现是假Labubu。网传图片显示，车主输入领取的Labubu盲盒防伪码，在泡泡玛特官网查询时显示防伪码错误，盲盒背面也将“搪胶”错写成了“塘胶”。

针对此事，南昌奕境汽车用户中心工作人员向媒体表示，现场发的Labubu盲盒确实是假的。据其介绍，有多位顾客前来询问Labubu是否为正品，门店会真实告知Labubu不是正品。被问及为何不发放正品Labubu，工作人员表示该盲盒仅作为给顾客的小纪念品，没有考虑得那么周全，相关问题会与门店进行反馈。

8月18日，奕境X9开启预售，预售价29.98万元起。预售当晚，奕境汽车App一度崩溃无法下单。当日晚间，奕境汽车品牌总经理曾清林在微博上回应称，没有发订单战报，因为不到10点系统就崩了，到现在一直都下不了单。“向支持奕境的客户和朋友道一声抱歉！我现在正在盯着连夜排查。”19日凌晨，他再度发文称，从发布会现场回来，刚盯着把App崩的问题解决掉。他还调侃称，“我经常在内部自嘲我们是个草台班子，一方面是自嘲，另一方面也是鞭策自己不要变成真草台班子。”

人均557万元！寒武纪124名员工股票激励“大红包”即将到账

8月17日晚，寒武纪发布公告，公司2023年限制性股票激励计划预留授予部分第一个归属期的股份登记工作已完成，124名员工即将迎来人均价值约557万元的股权激励“红包”，相关股票将于8月20日上市流通。根据公告，本次归属的激励对象共124人，合计分享59.76万股股票，其中56.1万股为定向发行股份，3.66万股来源于公司回购的A股普通股。以8月17日寒武纪收盘价1156元/股估算，该部分股票总价值约6.9亿元，对应人均股票价值达到557.15万元。回顾2023年底推出该激励计划时，寒武纪的股票均价仅为139元/股。不到三年时间，股价飙升逾7倍，早早参与股权激励的员工因此收获丰厚回报。

曾主导 AI 眼镜等项目，字节AI穿戴核心产品负责人刘锐离职

8月18日消息，据媒体报道，字节跳动旗下豆包Ocean AI硬件产品负责人之一刘锐（内部花名沐然），已正式离职。至于离职去向，有消息称刘锐或将开启在新领域创业，创业方向目前尚不清楚。在字节期间，刘锐负责视觉多模态方向的多条AI硬件产品线，包括一直备受业内关注的AI眼镜产品。据接近该团队的人士透露，他较早参与了穿戴产品从0到1的场景定义，并推动了模型能力从评测到产品落地。在加入字节之前，刘锐曾任职于华为，参与了华为HarmonyOS NEXT（纯血鸿蒙）AI原生智能方向的产品规划，全程经历了首代大模型与OS融合的定义期。

钉钉全球商业总裁杨猛将离任，下一站蚂蚁集团

8月17日消息，据媒体报道，钉钉全球商业总裁、客户发展部负责人杨猛已完成离职相关内部流程，计划加入蚂蚁集团。阿里钉钉悟空副总裁任卿（花名“易统”）将接手杨猛负责的商业化工作。知情人士称，此次离任由杨猛主动提出，相关人事变动最快将于近期公布。杨猛加入蚂蚁集团后的具体职务，以及任卿是否继续沿用“全球商业总裁”职务，目前尚不清楚。前述知情人士还称，在阿里加速AI商业化的背景下，集团对企业服务业务的收入增长和商业转化提出了更高预期，这被认为是杨猛离任的原因之一。媒体就上述人事变动向钉钉、蚂蚁集团求证，截至发稿，双方均未作出回应。

原xAI多模态理解负责人蔺旭东加入混元大模型团队

8月18日消息，据媒体报道，前xAI多模态理解负责人蔺旭东加盟腾讯，传闻其将会接管该公司多模态基础模型。蔺旭东的简历，几乎就是一部全球顶级AI实验室巡游史：2014年陕西省渭南市高考理科状元，2018年清华大学数理基础科学专业毕业，2023年哥伦比亚大学计算机博士，2024年1月加入谷歌DeepMind，担任Gemini多模态预训练与后训练的核心贡献者；2025年11月加入马斯克xAI，担任Member of Technical Staff / 多模态理解Lead。他的主要研究领域是多模态内容理解、表征学习、视频分析和生成模型，同时也是VX2TEXT的第一作者。从DeepMind到xAI，蔺旭东参与了全球最先进的多模态大模型的预训练与后训练全流程。

韦东奕账号时隔一年多更新，上架自编小学数学练习册销量已破万

北京大学教师韦东奕时隔一年在 B 站更新动态，内容为一道有趣的题及数道数学题解法，其 B 站账号小店上新他主编的小学、初中数学解题能力训练练习册，其中小学数学练习册销量已破 10000 件，北京大学确认该账号为韦东奕本人账号。

京东快递员转型机器人维修：首批培训后已上岗，未来 5 年创造 10 万个就业岗位

8 月 20 日消息，据京东物流黑板报，近期，京东物流组织了首批一线员工转型机器人维修工程师培训，来自全国各地的数十名快递员、仓管员、质检员等一线员工在京东服务涿州技术认证培训中心参加学习。据了解，首批完成学习培训和岗位认证的一线员工，已正式在机器人维修工程师的新岗位上岗。此外，京东还对外公布最新就业规划：未来五年将面向全行业创造超过10万个机器人维修工程师就业岗位，为自动化运维赛道输送大量成熟技术人才。

Meta 成微软最大 AI 客户之一：年采购额达数亿美元，每周消耗数万亿token

8 月 20 日消息，据外媒报道，Meta 正通过微软 Azure 云服务采购 AI 服务，年支出高达数亿美元，已成为微软规模最大的 AI 客户之一。知情人士称，Meta 每周通过 Azure 消耗的模型调用量达到了数万亿token。目前，微软 Azure 正通过 Foundry 平台提供来自多家供应商的 AI 模型，包括 OpenAI、Anthropic、DeepSeek、Mistral AI、xAI、Meta 等，总数达 11604 个。截至今年 7 月，该平台已有 10 万名客户。

对于 Meta 而言，该公司采购的 AI 算力主要用于软件开发等工作。据知情人士透露，Meta 会根据模型的可用性和成本，通过不同平台采购模型。Meta 开发人员还曾通过 Foundry 使用 OpenAI 的技术，以评估自研模型的输出效果。此外，Meta 自身也在开发面向外部客户的 AI 模型 API 服务，允许用户通过 API 使用不同模型。该业务未来可能与微软 Foundry 等平台形成竞争，并有助于 Meta 减少对外部 AI 服务的依赖。

Stripe超70亿美元收购OpenRouter

8月17日消息，据外媒最新报道，支付基础设施企业 Stripe 已完成对 AI 模型平台 OpenRouter 的收购交易。OpenRouter 主要为开发者提供统一的 AI 模型接入和路由服务。OpenRouter 于5月宣布完成B轮融资，融资额达1.13亿美元，估值达13亿美元。投资者包括红杉资本、安德森·霍洛维茨基金、门洛风投和Alphabet旗下的Capital G。外媒上月报道称，Stripe和OpenRouter正在进行收购谈判。如今，报道称，谈判已达成协议，交易价格超过70亿美元。Stripe 的一位发言人表示，该公司不对谣言或猜测发表评论。

Anthropic业绩反超OpenAI，正全速推进 IPO 进程

8月19日，据华尔街日报援引知情人士报道，OpenAI二季度收入为67亿美元，较一季度的57亿美元增长18%，与此同时运营亏损进一步扩大，令公司在备受期待的IPO前景上蒙上阴影。相比之下，Anthropic同期收入超过115亿美元，不仅环比增幅逾140%，更是首次在季度收入上超越这家成立更早的竞争对手，并实现小幅运营盈利。此外，另有消息称Anthropic正准备最快在本月底公开提交上市申请文件。若监管审核顺利，Anthropic预计最快将于今年第四季度正式在美股市场挂牌交易。

围棋八冠王柯洁分享必赢AI方式：“装弱智”

8 月 20 日消息，近日，围棋世界冠军柯洁在直播中提到的“人类靠装弱智打赢最高水平AI”的话题迅速出圈，相关片段在社交平台和围棋社群广泛传播，登上多个平台热搜，引发网友对围棋AI能力边界的热烈讨论。

直播里柯洁介绍，这套非常规对局思路最早由日本棋手芝野龙之介摸索出来。对局时人类棋手不遵循职业棋理走常规布局，开局故意下出很多不符合常理、看似水平低劣的落子，主动制造出“对手实力很弱”的假象。由于围棋AI的训练数据大多来自正规棋谱，面对这种严重脱离训练样本的怪异局面，很容易出现局势误判，错误高估自身优势而放松防守。

人类棋手则在看似杂乱的落子中悄悄布局，等到后半盘抓住机会吃掉AI整块大龙，就能实现翻盘取胜。柯洁还笑着调侃，如果当年和阿尔法狗对战时知道这个方法，说不定对局结果会不一样。

话题传开后，不少网友第一反应是“人类棋力反超AI了”，也有很多围棋爱好者留言澄清，这本质是利用了AI算法的评估漏洞，属于取巧的奇袭战术，并不是正常对弈中的实力碾压。

重磅发布

DeepSeek Harness 首发新版本：多模态能力升级

DeepSeek Harness v0.1.0-rc.8 版本上线，带来 14 项调整，重点补齐多模态能力，支持原生图片请求和图文混合输入，/goal、/plan 等命令可接收图片，@菜单新增文件和会话引用。子代理体系扩充，可按需安装 Claude Code 和 Codex。优化 Windows 终端体验，修复图片请求、流式生成、自定义网关等问题。

此外，该版本为纯文本模型搭建工具层视觉，通过调用 OCR、颜色统计、像素扫描等工具将图片转为结构化信息供文本模型推理。同时，此次更新还强化了插件化思路，加入 web_search 并发查询等优化，提升了相关性能。

另外，DeepSeek-V4-Flash-Vision-Exp 在 DeepSeek API 平台也已上线，文本能力与 DeepSeek-V4-Flash 持平，涵盖 agent、推理和世界知识等领域，在多模态智能体基准测试中性能较 V4-Flash 大幅提升，接近 Opus-4.8。

GLM-5.3 上线：60 分跻身全球前沿，与 Kimi K3 并列开源模型第一

8 月 19 日上午消息，智谱凌晨上线新一代基座模型 GLM-5.3 API。该模型擅长复杂编码、防御性网络安全与长程任务，在 Artificial Analysis Intelligence Index 中取得 60 分，进入全球前沿模型能力区间，与 Claude Fable 5、GPT-5.6 Sol 等闭源旗舰处于同一水平，并与 Kimi K3 并列开源模型第一。

当前，前沿模型正从比拼更大参数规模，转向比拼单位成本下的有效智能。据悉，GLM-5.3 以更小的参数规模、更高的参数效率和更低的调用成本达到前沿模型水平，实现前沿旗舰模型中最低的单任务成本，并将“智能—成本”的帕累托前沿显著推进，利好 AI 应用加速落地与规模化普及。

GLM-5.3 并非依靠单纯扩大参数规模实现跃升，其与上一代 GLM-5.2 沿用同一基础模型，性能提升主要来自后训练。这表明前沿能力向前推进不必依赖更大的参数规模和更高的算力投入。

目前，该模型已接入 ZCode、GLM Coding Plan 等官方产品，API 定价与 GLM-5.2 保持一致，模型权重将于下周五开源。同日，国家超算互联网上线GLM-5.3 API调用服务，企业和开发者无需繁琐环境配置，登录超算互联网即可一键调用该旗舰模型。

阿里推出 AI 音乐模型快乐虾米

8 月 17 日，阿里巴巴微信公众号发文表示，推出 AI 音乐模型快乐虾米“Happy Shrimp 1.0”。据介绍，该模型能精准理解自然语言，可以将情绪、故事或记忆变成一首完整的音乐。据悉，Happy Shrimp 从研发初期就选择降低创作门槛，在乐理、编曲等专业术语外，可精准理解自然语言，让人人都能享受创作音乐等乐趣。用户提出语言描述、歌词、曲风、情绪、年代及人声等要求，模型可以整体规划、同步创作、兼顾长程结构，一体成型，生成完整歌曲。Happy Shrimp 已在国内及海外同步上线电脑端，新用户可享受大额免费积分。

阿里虎鲸文娱自研“虎鲸AI大模型”，内测AI视频创作工具

8月20日消息，据媒体获悉，阿里旗下的虎鲸文娱集团已自研完成“虎鲸AI大模型”，并且正在内测一款全新的AI视频内容创作工具“虎鲸AI”。据了解，虎鲸AI部分功能需要充值才能使用，整个项目的研发测试或至少有半年。目前该工具无法直接登录使用，仅供受邀用户使用。消息还称，结合虎鲸文娱此前对外介绍的其在 AI 影视大模型中的技术进展来看，这款工具可能是面向影视、短剧、动画创作者的工业化AIGC工作台。

豆包上线“工作任务”新功能，手机可远程操作电脑

8 月 17 日，字节跳动旗下 AI 助手豆包推出“工作任务”新功能，用户可通过手机端远程操作电脑。该功能支持手机向电脑端豆包下达指令，完成文件处理、网页操作、应用控制等任务，实现跨设备协同。这意味着用户即便不在电脑前，也能通过手机让 AI 助手在电脑上执行具体操作，进一步拓展了 AI 助手的实用场景。

支付宝发布国内首个Agent商业底座

8 月 18 日，支付宝发布首个全栈 Agent 商业底座及多 Agent 跨端互联AHA协议体系，联合千问、华为、OPPO、比亚迪、吉利等20余家企业共建 Agent 互联生态。据了解，支付宝旗下超级服务 Agent “阿宝”目前完成了超过一万项服务的AI化接入，服务跨端支持5大手机品牌、16家主流车企。

百度文心助手推出任务引擎2.0，日活用户同比增长83%

8月20日，百度App发布多项产品升级。文心助手升级任务引擎2.0，覆盖用户群的高频场景，且完全免费。该任务引擎可根据用户目标自主规划与执行，全程无须人工干预。据悉，今年6月文心助手日活跃用户同比增长83%，日均对话轮次增长超过两倍。

稀宇科技推出MiniMax Design

8 月 20 日，据稀宇科技消息，公司推出MiniMax Design。MiniMax Design是一款把多模态模型能力变成真实可用的生产力的Harness。用户提出创作需求后，它能够理解目标、拆解任务、调用相应的模型与Skills，完成从素材处理、生成和编辑到最终交付的完整过程。

9.9 万起！蔡明同款仿生机器人亮相：五官自然精致主打情感陪伴

8 月 19 日消息，2026 世界机器人大会在北京亦创国际会展中心拉开帷幕，多款前沿机器人集中亮相。其中，松延动力展台展出的一款仿生机器人因与春晚蔡明同款而备受关注。

这款机器人仿真程度颇高，皮肤质感接近真人，五官自然贴合，妆造精致，不少现场观众表示其逼真度超出预期。据展台工作人员介绍，该款与春晚舞台上和蔡明同框表演的机器人属同一系列，仅在妆容等细节上有所区别。功能方面，机器人除了基础的语音对话外，还能接收语音指令，做出卖萌、亲吻等表情动作。其妆容和造型支持定制，可根据需求与游戏 IP 等做联名设计。在应用场景上，该产品主打情感交互，可用于医院导诊、博物馆讲解、语音陪伴等多个领域。工作人员举例称，将程序设定为导诊模式后，仿生形态能让交互过程比传统导诊机器人更具温度，减少冷冰冰的机械感。价格方面，这款仿生机器人基础款售价约 9.9 万元，高配版本则超过 13 万元。据现场销售人员介绍，价位差异主要体现在面部表情的灵活度和细腻程度上，价格越高，表情表现越丰富。

宇树科技发布“超人”机器人

8 月 17 日，宇树科技发布了一款人形机器人新品“超人”，原地跳高 2m，极限速度 12.66m/s（0.85m 腿长），超越全人类原地跳高和奔跑速度纪录。宇树科技表示，全新整机刚用 3 个多月研发出来，未来几个月还有很大的完善空间。

企业应用

8 月 19 日，据火山引擎消息，特斯拉上线豆包大模型，目前特斯拉车机现已陆续推送。8 月 18 日，阿里旗下Agent产品“千问办公”正式接入企业微信，此前，该产品已接入钉钉和飞书。此外，千问办公于近日开源了全新的上下文基础设施“MyContext”。它可以把海量异构的个人工作数据加工成Agent易理解的专属工作档案，让Agent读懂用户和真实业务工作流，并最终在决策和执行等环节实现人机协同，提升Agent在工作场景下的表现。8 月 18 日，企业微信全面升级CLI与MCP能力，WorkBuddy、DeepSeek Harness、MiniMax Code等AI Agent均可直接接入企业微信调用企微能力完成任务，企业也可基于开放接口接入自建Agent。此次开放升级，面向所有规模的企业全面开放，不再受企业人数、资质等门槛限制，覆盖文档、表格、邮件、会议、日程、通讯录等十个能力模块。本次CLI的全面开放也意味着企业微信进一步向AI生态敞开底层办公能力。8 月 17 日，华为小艺、vivo蓝心小V、荣耀YOYO正推进接入支付宝阿宝，现已开始测试，落地后手机系统AI将可调用支付宝办事 Agent 能力。此外，支付宝方面还在与更多手机品牌洽谈相关合作，目标推动主流手机终端实现对阿宝的接入。公开资料显示，目前市面上OPPO、阶跃两家已经落地调用阿宝。

从现实到反馈：KDC 完整工程模型全景

vivo 肖博 — Mon, 24 Aug 2026 02:00:00 GMT

作者：vivo 肖博

AI 合作者：ChatGPT（GPT-5.5）

创作模式：Human-led, AI-collaborated

责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。

研究说明：知识驱动计算（Knowledge-driven Computing, KDC）是我们正在提出和持续打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。前四篇分别从 Reality、Knowledge、Reasoning、Skill、Capability、Memory 和 Feedback 展开。这一篇不再逐个解释概念，而是回答最后一个问题：它们如何组成一套完整、可审计、可治理、可渐进采用的软件工程模型？摘要：KDC 试图把领域现实、数字表示、知识、记忆、推理、技能、能力、行动和反馈组织成一条连续的业务因果链。本文给出 Reality-to-Feedback 闭环以及对象化、运行时化、治理化三层工程模型，同时区分已验证实践、理论推导和开放问题，说明企业如何从一个高影响业务闭环开始渐进采用。KDC系列文章：《软件从现实开始：知识驱动计算（KDC）的 Reality First 主张》"《软件不是文件：KDC 的知识工程主张》"《调用成功不等于判断正确：KDC 的行动治理主张》"《保存历史不等于形成记忆：KDC 的长期运行主张》"《KDC 全景：从现实到反馈的完整工程模型》"（本文）《如何把 Agent 的判断与行动变成可恢复的软件事实 | KDC 工程补篇》"

在前四篇贯穿的退款案例中，我们已经得到四份产物：

一张 Reality Map，说明系统面对哪些现实对象、状态、关系和反馈一张 Knowledge Card，说明当前退款规则来自哪里、为什么可信、适用于什么边界一份 AI Action Record，说明 Agent 为什么建议退款、策略如何判定、用户是否确认一份 Feedback Contract，说明接口成功之后，什么现实结果才算退款真正完成

每份产物都解决了一个问题，却没有任何一份能够单独解释完整业务。

Reality Map 不会自动告诉 Agent 应引用哪条政策。Knowledge Card 不会自动形成退款判断。AI Action Record 不能替代实际执行。Feedback Contract 也只有在能够追溯到原目标和行动时才有意义。

当它们被放到同一条因果链上时，KDC 的完整轮廓才出现：

系统面对什么现实 -> 如何表示和理解现实 -> 依据什么形成判断 -> 如何围绕目标组织行动 -> 怎样在治理约束下影响现实 -> 如何用现实反馈修正系统

KDC 的价值不在于提出几个孤立名词，而在于尝试把这条链路变成可以被设计、运行、审计和演化的软件工程闭环。

KDC 要解决的不是所有软件问题

在组装完整模型之前，需要先说明它的适用范围。

KDC 不是操作系统、数据库、编译器、网络协议或模型训练理论。它依赖这些数字基础设施，却不试图重新定义它们。

KDC 也不是所有应用软件的强制架构。如果一个程序只执行确定转换、固定规则和低风险 API 调用，不需要模型理解动态上下文，不涉及知识演化，也不会影响重要现实状态，那么传统代码、数据模型、接口契约、测试和监控已经可以很好地解决问题。

KDC 更关注这样一类系统：

业务语义密集，简单字段不足以表达全部条件上下文会随用户、时间、项目和现实状态变化模型会在运行时解释材料并形成判断系统需要根据目标选择 Skill 或 Capability行动可能影响订单、资金、权限、审批、通知或其他重要现实状态团队需要知道判断依据、行动原因和责任边界行动结果必须反馈并影响未来知识、记忆或治理

企业知识助手如果只做低风险文档问答，可能只需要来源和引用增强。当它开始生成审批建议、创建任务、发送通知或修改业务状态时，KDC 关注的完整链路才逐步变得必要。

因此，采用 KDC 不是二元选择。团队可以只补齐当前风险最高的一段，而不是一次性建设全部对象和运行时。

一条从 Reality 到 Feedback 的完整闭环

KDC 当前用下面这条链路组织核心概念：

flowchart LR R[“Reality 领域现实“] --> RM[“Reality Model 现实模型“] RM --> RP[“Representation 数字表示“] RP --> K[“Knowledge“] RP --> M[“Memory“] K --> Q[“Reasoning“] M --> Q Q --> S[“Skill“] S --> C[“Capability“] C --> A[“Action“] A --> F[“Feedback“] F -.->|持续校验与修正| R

图 5：KDC Reality-to-Feedback 业务闭环

这不是一条只能从左到右执行一次的流水线，而是一张因果地图。

Reality 是最终参照物

领域现实定义系统在职责范围内试图观察、建模、预测或影响的对象、状态、关系和动态规律。

退款系统面对的现实包括用户诉求、订单承诺、原支付、资金退回和到账结果。数据库状态很重要，但它不是最终参照物。接口成功也不能单独证明用户已经收到资金。

Reality Model 决定系统看见什么

现实模型选择哪些现实进入系统，如何划分对象和状态，怎样表达关系，又用什么反馈判断变化已经发生。

同一个退款过程可以被建模成“处理中、成功、失败”，也可以区分“渠道受理、清算中、银行处理中、用户到账”。模型粒度应与系统职责和现实承诺匹配。

Representation 是现实的数字编码

数据、文档、API、事件、日志、图谱、Embedding、Prompt 和模型上下文都是表示。它们让现实能够进入数字系统，却不自动等于现实或知识。

Knowledge 提供可复用依据

表示经过解释、验证并形成可复用认知成果后，才能在 KDC 意义上成为知识。

知识需要来源、证据、适用边界、版本和成熟度。当前退款政策与订单事实可以支撑判断。一份相似度更高但已经过期的旧政策不能以相同资格进入推理。

Memory 让历史在受治理条件下影响未来

记忆保存知识、经验、决策、反馈和演化轨迹。它不是把所有历史对话放入向量库，而是决定哪段历史在什么条件下仍可影响当前判断。

上次用户选择退款可以解释过去，却不能自动成为“用户永远偏好直接退款”的稳定画像。

Reasoning 连接依据与结论

推理对象记录目标、上下文、知识和记忆引用、证据、关键判断、风险、结论和行动建议。

它不要求暴露完整 Chain-of-Thought，而是提供足以审计高影响判断的外部结构。比如，“满足退款条件”和“用户已经授权退款”必须成为两个可区分判断。

Skill 组织目标级复用

Skill 把业务目标、前置条件、参与能力、编排逻辑、风险边界和失败策略组织起来。

“处理退款”不是一个 Tool，而是一项可能包含目标澄清、规则判断、用户确认、执行、跟踪和异常处理的目标级能力组合。

Capability 是受治理的行动入口

Capability 把底层 Tool 或服务包装成具备身份、语义、权限、风险、Owner、版本、审计、可观测和生命周期的执行对象。

在 KDC 系统边界内，凡是需要被 AI 理解、选择、调用和治理的重要行动，都应通过能力对象表达。这里不声称世界上的所有变化都由 Capability 造成。用户、外部系统和自然事件同样会改变现实。

Action 作用于现实，Feedback 关闭闭环

能力运行时执行行动，现实结果再通过业务事件、外部状态、人工确认、用户反馈和对账结果进入系统。

反馈不是自动真值，也不应直接升级知识或强化记忆。它需要来源、关联、可信度和错误归因，然后由对应运行时决定更新什么。

Continuous Consistency 是长期方向

闭环的长期目标，是让系统能够观察领域现实与数字表示之间的偏差，并在知识过期、记忆失效、推理错误或行动失败时找到修正路径。

这里所说的“持续一致性”，首先是一种持续发现偏差并寻找修正路径的能力，而不是要求系统与现实始终保持绝对同步，也不是用一个已经固定的总分概括系统状态。偏差可能来自现实覆盖不足、现实映射错误、知识过期、知识漂移或验证缺失。围绕这些问题，Reality Coverage、Reality Mapping、Knowledge Freshness、Knowledge Drift 和 Consistency Verification 目前只是候选的度量方向，具体定义和组合方式仍需要在实践中验证。

KDC 有两张图：业务闭环与工程模型

上面的 Reality-to-Feedback 链路回答“业务因果如何流动”。真正构建系统时，还需要另一张图回答“由什么工程机制承担责任”。

KDC 当前把工程模型概括为三个层次：对象化、运行时化和治理化。

flowchart TB I[“Reality / Reality Model / Representation“] A[“Agent 目标解释、上下文组织与协调“] subgraph O[“对象化：让责任可以被引用“] direction LR O1[“Knowledge Object“] --- O2[“Memory Object“] --- O3[“Reasoning Object“] --- O4[“Skill / Capability Object“] end subgraph RUN[“运行时化：让对象真正运转“] direction LR R1[“知识运行时“] --- R2[“记忆运行时“] --- R3[“推理运行时“] --- R4[“能力运行时“] end subgraph G[“治理化：让边界成为系统机制“] direction LR G1[“来源、证据与成熟度“] --- G2[“生效、衰减与遗忘“] --- G3[“权限、风险与审计“] --- G4[“反馈可信度与错误归因“] end I --> O O --> RUN A -.-> RUN G -.-> RUN RUN --> X[“Action / Feedback“] X -.-> I E[“MCP、Agent Framework、IAM、Policy Engine、Workflow、Observability“] -.-> G E -.-> RUN

图 6：KDC 对象、运行时与治理的工程责任结构

这三层不是三个必须独立部署的平台，而是三类工程责任。

第一层：对象化，让隐含责任可以被引用

传统 AI 应用常把关键内容放在 Prompt、会话上下文、文档片段、工具描述和日志中。这些内容可以工作，却缺少稳定身份和生命周期，难以跨任务引用和治理。

KDC 当前定义五类核心对象：

对象化的重点不是把所有内容转换成统一 JSON，而是给高价值责任稳定身份。

当退款政策更新时，系统应该知道哪些推理引用了旧版本。当能力发生事故时，系统应该知道哪些 Skill 和行动受影响。当用户纠正偏好时，系统应该找到相关记忆，而不是只能全文搜索聊天记录。

对象化让“依据了什么、记住了什么、如何判断、怎样组织目标、通过什么行动”从临时内容变成可追溯关系。

第二层：运行时化，让对象真正运转

只有对象定义，没有运行时职责，对象会退化成静态 Schema。

KDC 当前提出四类运行时：

知识运行时

负责从表示中解析、抽取、关联、验证和检索知识对象，处理来源、证据、冲突、版本和生命周期。

它可以使用 RAG、搜索、知识图谱和规则系统，但不等于其中任何一个。

记忆运行时

负责记忆形成、检索、强化、冲突、衰减、遗忘、迁移和归档。

它治理的是历史如何影响未来，而不是保存尽可能多的历史。

推理运行时

负责目标识别、上下文装配、证据绑定、推理对象创建、风险评估、能力选择建议和反馈更新。

它不是 Prompt 模板管理器，也不要求暴露模型内部全部思维。

能力运行时

负责能力发现、选择、调用、组合、结果反馈和失败处理，并在控制平面的策略约束下执行。

它不是一个裸 Tool Executor。授权、风险、版本、失败策略和现实反馈都属于执行边界的一部分。

运行时是逻辑责任，不必一开始对应四个独立服务。一个现有应用可以通过模块、事件、策略和数据结构承担其中部分职责，再根据规模和边界逐步拆分。

第三层：治理化，让行动边界成为系统机制

当 AI 只能生成文本时，错误主要影响回答质量。当 AI 可以退款、下单、变更权限和发送通知时，错误会进入现实。

治理层需要把以下责任从 Prompt 约定提升为系统机制：

能力注册、发现和版本主体身份、权限和策略风险分级和 HITL前置条件、后置不变量和事务边界限流、熔断、灰度、回滚和补偿Owner、生命周期和退役运行时可观测和对象化审计链现实反馈和错误归因

能力控制平面承载能力注册、授权、策略、审计、观测和生命周期控制。能力注册表保存能力身份、语义、Owner、风险、依赖和状态。能力治理决定什么条件下允许、拒绝、降级或转人工。

治理也不只发生在能力入口。知识权限、记忆访问、推理证据和反馈可信度同样需要边界。一个控制平面无法替代所有运行时治理，它只是行动治理中最集中的基础设施节点。

用一次退款任务组装完整模型

现在我们把前四篇的退款任务完整走一遍。

1. 识别现实目标

用户说：“帮我看看这笔订单现在能不能退？”

系统首先区分资格咨询和行动授权。当前目标是判断是否符合条件，不是立即退款。

Reality Map 告诉系统，退款涉及订单、原支付、活动权益、资金退回和到账反馈。“接口成功”不是最终现实结果。

2. 装配知识与记忆

知识运行时提供当前有效的退款政策、订单事实和活动权益规则，并保留版本、证据和适用边界。

记忆运行时可能返回上次退款经历，但同时标明：这是特定订单下的情景和行动结果，不足以证明用户当前仍偏好直接退款。

3. 形成推理对象

推理运行时记录：

目标是资格判断当前政策版本为 v4.0订单未发货且权益未核销结论是符合退款条件风险在于把咨询误解为授权行动建议是向用户说明条件并请求明确确认

4. 选择 Skill

Agent 选择“订单退款处理”Skill。该 Skill 规定：先判断资格，再解释影响，用户确认后才进入事务型退款能力。高金额或异常订单转人工。

5. 提出能力调用建议

用户确认后，系统建议调用“发起订单退款能力”。能力对象声明其风险、权限、Owner、事务边界、审计策略和反馈要求。

6. 控制平面判定

控制平面检查调用主体、用户确认、推理对象、订单状态、知识版本、风险策略和能力生命周期。

条件满足时授权执行。缺少确认时拒绝并返回可解释原因。命中高风险规则时进入 HITL。

7. 能力运行时执行

能力运行时调用底层 Tool，处理事务、异常、重试或补偿，记录执行结果。Tool 返回成功只表示请求被受理，不直接把退款标记为现实完成。

8. 现实反馈进入系统

支付渠道状态、对账结果和用户确认进入 Feedback Contract。系统将反馈关联到原目标、推理对象、能力对象和策略判定。

如果退款到账，行动结果可以形成候选记忆。如果延迟来自渠道故障，更新能力质量和行动-结果记忆。如果旧政策导致错误判断，让知识降级或过期。如果 Agent 误解目标，修正推理策略。

这一过程说明，Agent 的价值不是自己承担所有责任，而是协调对象、运行时和治理机制完成一个可追溯任务。

KDC 如何与现有体系协同

KDC 不以替代现有理论和基础设施来证明自己。它更像一张组合地图：

KDC 的补充，是把这些局部机制连接到一条从现实、知识和判断到行动、治理和反馈的因果链。

这也是 KDC 当前最主要的原创主张：新颖性不在于发明 Knowledge、Agent、API 或治理，而在于把它们组织成一个面向 AI 应用软件的连续工程闭环。

这个原创性主张仍需要更多实践、外部审阅和反例检验。它不能因为概念链条连贯，就自动被视为已经成立的行业理论。

渐进采用：从一个业务闭环开始

KDC 最容易失败的采用方式，是先建设一个名义完整的“知识平台、记忆平台、推理平台和能力平台”，再去寻找业务场景。

更现实的路径是从一个高价值或高风险闭环开始。

第一步，建立 Reality Map

明确系统边界、现实对象、状态、关系、动态规律和成功反馈。优先识别内部状态与现实承诺之间的缺口。

第二步，识别关键 Representation 和 Knowledge

找出当前判断依赖的文档、数据、规则和事件。只对象化高价值、可复用或高风险知识，保留来源、证据、版本和成熟度。

第三步，外部化高影响判断

为高影响决策建立推理对象或等价审计依据。至少记录目标、知识引用、证据、结论、风险和行动建议。

第四步，治理重要能力

把影响现实状态的 Tool 纳入 Capability，补齐语义、Owner、权限、风险、版本、审计和失败策略。优先治理资金、权限、审批、外部通知和不可逆行动。

第五步，建立现实反馈和错误归因

定义执行结果与现实成功的区别，把反馈关联到目标、推理、能力和策略，并能够区分知识、记忆、推理、治理、执行和外部系统错误。

第六步，按真实瓶颈引入运行时能力

如果主要问题是旧政策和冲突，优先补知识运行时。如果历史误用频繁，补记忆生命周期。如果高影响判断不可审计，补推理对象和运行时。如果 Tool 失控，补能力治理和控制平面。

这条路径的原则是：

先闭合责任再抽象机制最后平台化

平台应该从反复出现且边界稳定的运行时责任中长出来，而不是从术语清单中长出来。

成熟度：哪些已经验证，哪些仍是理论提案

完整模型必须把证据强度写清楚，否则读者会误以为每一层都已经经过同等验证。

开放问题不是附录里的免责条款，而是理论演进的一部分。Reality Model 如何形式化，知识可信度如何计算、运行时最小接口如何冻结、记忆如何遗忘、多 Agent 如何分责、反馈如何成为验证证据，都需要继续通过 RFC 和参考实践收敛。

实践：用 KDC Architecture Canvas 做一次架构评审

选择一个现有或拟建设的 AI 业务流程，邀请业务 Owner、架构、AI、数据、安全和运维相关人员共同完成一次评审。

Canvas 不需要先画成复杂图，可以从下面八个区域开始：

评审时依次检查：

1. 是否把数据库状态误当作现实结果？

2. 是否把文件、向量或 RAG 片段直接当作已验证知识？

3. 是否存在无法说明依据的高影响判断？

4. Skill 是否明确目标、边界和失败路径？

5. 重要 Tool 是否缺少 Capability 语义、Owner 和风险等级？

6. 关键治理是否只存在于 Prompt 或人工默契中？

7. 接口成功后是否缺少现实反馈？

8. 日志能否支持知识、记忆、推理、能力和治理之间的错误归因？

9. 当前流程真的需要完整 KDC，还是只补一两个高风险缺口即可？

最终不要产出一份宏大平台路线图，而是选择一个最重要、最可验证的缺口。

比如：先让退款能力必须绑定用户确认和推理对象。先让当前政策拥有稳定版本与有效期。先让到账反馈能够关联到原能力调用。完成一个闭环后，再决定是否需要抽象为共享运行时能力。

KDC Architecture Canvas 的目标不是证明系统“符合 KDC”，而是帮助团队发现：哪些过去隐含的责任，已经因为 AI 参与判断和行动而必须显式化。

KDC 试图建立的是一条可以被质疑的工程闭环

AI 时代的软件工程不会抛弃代码、数据库、API、工作流和既有治理体系。KDC 的判断是：当模型能够理解上下文、形成判断并参与现实行动后，软件工程还需要显式管理知识、记忆、推理、技能、能力、治理和反馈。

完整链路可以再次压缩为：

面对现实 -> 形成可靠认知 -> 产生可审计判断 -> 组织目标级技能 -> 通过受治理能力行动 -> 用现实反馈持续校正

对象化让关键责任可以被引用，运行时化让对象能够持续工作，治理化让行动边界不依赖模型自律。三者共同服务同一个目标：让 AI 应用软件从一次性演示走向长期生产系统。

KDC 当前仍是一套开放理论提案。它需要更多真实系统验证，需要与既有理论进行严格比较，也需要允许反例推翻或修正当前抽象。完整并不意味着成熟，连贯也不意味着正确。

我们真正希望保留的，不是每一个当前术语，而是这组工程问题：

系统面对什么现实，依据什么知识，记住了什么，如何形成判断，怎样围绕目标组织技能，通过什么能力行动，谁来治理，以及如何从反馈中修正自己？

当一个 AI 系统能够稳定回答这些问题，它才开始具备理解现实、参与行动并承担长期工程责任的基础。

理论边界与开放问题

本文是 KDC 完整模型的公开叙事版本，不是已冻结的架构规范。当前已验证证据主要集中在现有能力治理平台支持的 MCP + Tool + Skill + LLM 电商流程，以及能力控制平面的部分工程职责。Reality、知识定义、对象模型主要属于 Derived。完整运行时、企业知识库、自主 Agent、记忆体系和持续一致性度量仍包含 Hypothesis 或 Open Research。KDC 不替代 DDD、RAG、MCP、Agent Framework、API Gateway、IAM、Policy Engine 或 OpenTelemetry。

Cloudflare WriteGuard 为 MCP 服务器提供了精细化的安全控制

作者：Sergio De Simone — Mon, 24 Aug 2026 01:03:00 GMT

Cloudflare 推出"了 WriteGuard（目前处于私有测试阶段），旨在为 MCP（模型上下文协议）服务器提供精细化的安全控制。对于能够修改数据或执行操作的工具，该功能可以控制 AI 代理的访问权限（而非仅限于读取信息），从而提升 AI 代理的安全性。

WriteGuard 是一个集策略、归因和审计于一体的共享层，旨在应对 AI 代理使用 MCP 访问具有写入权限的外部服务（包括数据库、GitHub、SaaS 应用程序、内部 API 等）时产生的风险。

只读模式是一个不错的起点。随着模型的不断改进，团队在人工智能领域积累了更多的经验，来自工程、产品、设计、销售和客户成功等部门的人开始寻求能够执行操作的工具。[……] 我们希望能够集中控制智能代理可以执行的写入操作，确保智能代理标签能在下游应用程序中显示，并建立审计日志，方便调查智能代理的活动。

WriteGuard 部署在 Cloudflare 的 MCP 服务器门户之后，拦截所有传入的 MCP 请求。它会加载与目标工具关联的策略，并评估请求上下文，以确定是允许该请求原样通过，还是应该阻止。如果获得允许的请求随后失败，那么它将与所有最初被拒绝的请求一起被路由到审计服务。

据 Cloudflare 工程师 Scott Roe-Meschke 和 Kenny Johnson 介绍，WriteGuard 的优势在于能够针对特定的工具定义策略，而不需要更改 MCP 服务器本身。它还充当所有通过 Cloudflare 门户连接 MCP 服务器的公共安全层。

仅就 GitLab 而言，我们本可以直接将这些控制措施集成到服务器中。但我们还需要为 Jira、内部维基、Google Workspace 以及新增的每台 MCP 服务器提供相同的功能。如果在每台服务器上重新实现这些功能，不仅工作量更大，还会导致行为不一致。

每项工具都被分配了一个风险等级，从完全没有风险的 read-only 到 critical 。例如，完成合并请求、触发生产环境部署或批量删除记录均被归类为关键操作。创建合并请求或更新问题字段属于 contained write 级别，而将通知标记为已读、订阅问题或添加评论等影响较小的操作则属于 minimal impact。

Roe-Meschke 和 Johnson 指出，WriteGuard 不需要创建独立的智能代理账户，否则将“产生第二套需要管理的权限”。相反，MCP 服务器使用现有的 OAuth 凭据来识别用户。为了确保在集中式审计日志中仍然能识别出由智能代理驱动的操作，WriteGuard 会将 MCP 客户端和会话上下文添加到用户身份信息中。

WriteGuard 将每次调用分类为“成功”、“失败”或“被阻止”，并在随后异步向内部审计 Worker 发送一条经过脱敏处理的事件。该事件会省略被视为机密或敏感信息的键值，并包含服务器、工具、风险等级、结果、用户、客户端和持续时间等信息。

WriteGuard 目前处于私有测试阶段"，这使 Cloudflare 能够在正式发布前验证其行为并优化产品功能。

原文链接：https://www.infoq.com/news/2026/08/cloudflare-writeguard-mcp-safety/"

亚马逊云科技开源 Dogwood：给 AI 智能体的工具调用立规矩

作者：Steef-Jan Wiggers — Sun, 23 Aug 2026 09:00:00 GMT

亚马逊云科技最近开源了 Dogwood"，这是一门用于智能体工具调用的策略语言。它与 Cedar" 的不同之处在于，其规则可以回溯查看智能体已经执行过的操作。Dogwood 采用 Apache 2.0 许可证发布，目前 AgentCore Policy 已支持该语言。

AgentCore Policy 于去年 re:Invent 大会上推出。它位于模型之外，作为一个确定性的控制层运行。模型提出工具调用，策略引擎接受或拒绝调用，而模型永远不会接触执行机制。Cedar 是用于编写这些决策的语言。亚马逊云科技于 2025 年末将其贡献给 CNCF，成为一个沙箱项目。

Cedar 每次只查看一个请求。将同一个请求输入两次，无论之前发生了什么，也无论策略以什么顺序运行，得到的答案都相同。审计和自动推理都依赖这一特性。代价是 Cedar 只能限制单个操作，无法描述操作序列。

智能体会将多个操作组合成工作流，而团队需要的约束通常存在于操作序列之中：在采取行动前获得批准、确保累计总额不超过限制，以及在接触机密数据后停止联系外部人员。

Dogwood 增加了第二种子句类型。Cedar 条件写在 when 中，而时序条件则写在 when temporal 中，并且可以读取智能体的事件历史。事件对应工具调用请求及其结果，携带输入参数和发起请求的主体。操作模式来自智能体的 MCP 工具清单，每个工具对应一个操作，由 Dogwood 直接生成。在底层，时序条件会被转换为 Cedar 上下文字段，解释器会在 Cedar 作出决策之前，根据事件历史填充该字段。

四种操作符涵盖了常见模式，它们全都基于核心度量一阶时序逻辑"子集，以标准库宏的形式定义，而不是作为语言原语：formerly 用于判断某个时间窗口内是否发生过某件事，count_within 用于计算发生次数，count_distinct_within 用于计算不同值的数量，sum_within 用于计算累计总额。bind 操作符可以为聚合结果命名，以便将当前请求与其进行比较。

这项公告中最具启发性的部分，是平台团队会很熟悉的一个正确性陷阱。针对响应事件而不是请求事件编写的速率限制，可能会被并发操作绕过。亚马逊云科技展示了这一过程：三笔并发的 2000 美元转账在任何一笔完成之前到达，因此，对响应求和的策略看不到任何正在处理的金额，于是允许三笔转账全部越过 5000 美元的上限；而对请求求和的相同策略则会拒绝第三笔转账。两个策略之间仅相差一个词。

这种异步性并非无关紧要。智能体会并行发起工具调用，而在多智能体环境中，操作交错会让情况更加复杂。一个按顺序理解时看似正确的策略，可能在并发环境中失效；这是一个出现在新领域中的典型分布式系统问题。

亚马逊云科技坦率说明了相应代价。时序求值需要有状态地追踪事件，而且求值时间可能取决于事件日志的长度。更重要的是，时序条件不支持 Cedar 提供的自动推理分析工具，因此使用这些条件的策略集将失去接受形式化分析的能力。团队表示，这正是他们选择构建一门独立语言，而不是扩展 Cedar 的原因。

现有 Cedar 策略仍然可以继续使用。任何有效的 Cedar 策略也都是有效的 Dogwood 策略，因此无须重写任何内容。默认拒绝机制保持不变，forbid 仍然优先于 permit。

Apache 2.0 许可证并不意味着可以直接部署。亚马逊云科技表示，参考解释器"用于探索和测试该语言，而不是在生产环境中执行授权。该仓库对其他要求的说明也非常直白。时间戳必须可信，事件必须经过身份验证。字段名和操作名必须保持一致。轨迹需要持久化存储，决策需要记录日志，并且绝不能让一个租户的历史记录流入另一个租户。保留策略也很重要，因为工具调用历史中包含敏感数据。这相当于需要构建一个值得信任的事件日志。如果做不到这一点，策略便毫无意义。

Dogwood 发布的同一周，MCP 2026-07-28 规范通过强制要求方法和工具名称标头，让 HTTP 基础设施能够识别智能体流量。两者分别解决了同一个问题中彼此相邻的两个部分。标头让网关能够看到智能体正在调用哪个工具；Dogwood 则用于表达一系列此类调用累计起来可以执行哪些操作。

路线图中的项目包括：支持以现实时间边界为基准的规则所需的绝对时间窗口；用于断言最终必须发生什么、而不是禁止什么发生的活性属性；以及面向多智能体系统、涵盖任务交接和锁的编排策略。

此次发布由亚马逊云科技副总裁兼杰出工程师 Marc Brooker、自动推理团队的 Joseph Tassarotti，以及亚马逊云科技 Agentic AI 的 Jean-Baptiste Tristan 共同撰写，其中 Marc Brooker 曾主导 Aurora DSQL 的发布。亚马逊云科技目前尚不接受贡献，并表示计划先收集反馈，待语言趋于稳定后再开放贡献。

原文链接：https://www.infoq.com/news/2026/08/aws-dogwood-agent-policy/"

向量数据库要被取代？DynamoDB 开始原生支持 AI 搜索

作者：Renato Losio — Sun, 23 Aug 2026 06:09:00 GMT

Amazon DynamoDB 最近推出了原生向量搜索"，允许开发者将嵌入向量与应用数据存储在一起，并直接在 DynamoDB 中运行近似最近邻查询，无需使用单独的向量数据库。该功能支持带过滤条件的相似度搜索，以及面向语义搜索工作负载的可配置向量索引。

向量搜索"使用一种新的 DynamoDB 索引类型，该索引基于存储在表属性中的向量嵌入。开发者可以选择任意嵌入模型，例如 Amazon Bedrock Titan Text Embeddings、Cohere Embed 或 OpenAI 文本嵌入模型，创建具有所需维度和距离函数的向量索引，然后使用新的 SearchVectors API 进行查询。亚马逊云科技首席解决方案架构师 Esra Kayabali" 写道"：

向量索引没有存储限制，并会随着数据增长进行横向扩展。现在，你可以利用 DynamoDB 及其原生向量搜索功能，构建需要对智能体记忆进行语义检索、检索增强生成、推荐引擎、个性化体验和异常检测等功能的应用。

此前，使用这款托管式 NoSQL 数据库的应用如果要支持向量搜索，就必须将数据复制到单独的向量数据库，并让两个系统保持同步，这增加了架构复杂性和数据传输量。原生向量搜索允许在同一张 DynamoDB 表中存储和查询向量嵌入与应用数据，从而移除了这条额外的数据流水线。Kayabali 补充道：

DynamoDB 完全采用无服务器模式，因此向量搜索可以自动扩展，无需管理基础设施。它最多支持 4096 个维度，支持欧几里得距离、余弦距离和点积距离函数，以及内联过滤。

在《使用 Amazon DynamoDB 原生向量支持构建语义搜索"》一文中，亚马逊云科技首席 NoSQL 专家解决方案架构师 Leonid Koren" 和亚马逊云科技DynamoDB 高级解决方案架构师 Mo Kamioner" 展示了如何构建一个 Python 语义搜索应用。该应用使用 Bedrock 嵌入和 DynamoDB，按照语义而不是精确关键词查找相关研究论文。他们解释了这项新功能对成本的影响：

除了承载项目的底层表所产生的标准 DynamoDB 费用外，向量索引还会按三个维度计费。你需要为写入索引的数据、搜索时处理的数据以及存储的数据付费。这三项均按字节计量，并按 GB 计费。

作者表示，使用更低的维度、尽可能减少索引投影、不在结果中返回嵌入向量，以及进行选择性分区，是能够显著降低向量搜索成本的主要方法。亚马逊云科技副总裁兼首席布道师 Jeff Barr 在 LinkedIn 上强调"：

它可以扩展到你需要的任意规模（想想数万亿个向量），同时保持个位数毫秒级延迟。

鉴于许多数据库在过去几年中已经推出了向量支持，一些从业者认为亚马逊云科技 “入场太晚"”。不过，Humayun Khan 评论：

这是一项非常令人兴奋的新功能。DynamoDB 原生向量搜索可以将向量搜索和应用数据保存在同一个位置，从而大幅简化 AI 应用的构建。

一些开发者想知道 DynamoDB 是在向量搜索之前还是之后应用属性过滤器"，但这项功能获得了社区大体积极的反馈"，许多人强调了它相对于 S3 向量存储桶"的优势。用户 coinclick 警告称"：

S3 具有近乎无限的扩展能力，并且能够提供稳定的延迟，即使这种延迟表现并不出色。我认为 DynamoDB 通常也能很好地横向扩展，并提供非常低的延迟，但其成本可能会比 S3 高很多。

该团队计划通过兼容 DynamoDB 的适配器 ExtendDB，为本地开发和自托管部署提供向量搜索。向量索引现已在 DynamoDB 当前提供服务的所有区域开放，并支持使用 Standard 或 Standard-IA 表类别的表。

原文链接：https://www.infoq.com/news/2026/08/aws-dynamodb-vector-search/"

PostgreSQL 太难懂？有人把它做成了城市模拟器

作者：Olimpiu Pop — Sun, 23 Aug 2026 03:25:00 GMT

Nikolay Samokhvalov" 发布了 PGSimCity"。这是一款开源教育可视化工具，可以将 PostgreSQL 集群的运行机制转换成交互式 3D 空间模拟。该项目完全在浏览器中运行，无需安装本地依赖，可以通过 PGSimCity 在线可视化"沙箱访问。它为后端开发者、站点可靠性工程师和数据库架构师弥合了高层 SQL 查询与底层内核执行之间的概念鸿沟。

其核心抽象将 PostgreSQL 18 的内部机制转换为 src/world/layout.ts" 中定义的具体市政区域。客户端连接从北部天空进入 Postmaster 管理进程，后者沿着后端大道派生工作进程。shared_buffers 池是位于城市中央的一个 1024 帧网格，旁边分布着 wal_buffers、ProcArray、锁表和提交日志（CLOG）。城市结构下方的存储挖掘区以 8 KB 页面区域、B 树、空闲空间映射（FSM）和可见性映射（VM）的形式组织堆数据。预写日志被传送至东部的 WAL 区域，walwriter 和 walsender 线程从这里广播复制流；西部维护场则容纳 checkpointer、bgwriter 和 autovacuum 工作进程。

为了忠实呈现系统架构，展示层将 three.js" 渲染与核心状态转换严格解耦。模拟状态变更由 src/sim/state.ts" 中采用 SimState 的独立 TypeScript 状态机计算，确保帧率波动不会导致内部状态失去同步。

后端开发者可以跟踪语句在解析、重写、规划和执行各阶段的生命周期，而首席数据库工程师和 SRE 则可以主动触发异常运行场景，检查引擎的故障模式。将 shared_buffers 设置为 16 MB 会强制触发 clock-sweep 淘汰竞争，后端需要先写入作为淘汰对象的脏页，然后才能读取新数据。模拟受限的 work_mem 会导致 Sort 和 HashAggregate 执行节点将临时文件溢写到 base/pgsql_tmp。

长时间运行的事务会压低 xmin 水平线，使 autovacuum 无法获得足够的清理空间并导致表膨胀；大量突发写入则会引发检查点风暴，在超过 max_wal_size / (1 + checkpoint_completion_target) 阈值时，以全页写入（FPW）淹没 pg_wal。

在 Hacker News" 上，该项目引发了关于 AI 辅助软件架构可视化和认知负担的广泛讨论。

Samokhvalov 表示，最初的原型通过消耗数十亿 token 的大语言模型提示构建，随后又对照 PostgreSQL REL_18_STABLE 源代码进行了大量人工校准。社区反馈推动了降低 UI 弹窗密度的工作，也催生了面向 ClickHouse 的 CHSimCity" 等衍生项目。

PGSimCity 还集成了 PGlite"，可以直接在浏览器的客户端线程中运行编译为 WebAssembly 的真实内存版 PostgreSQL。展望未来，该项目的 ROADMAP.md" 列出了多项核心技术里程碑：引入语句池化可视化模式；使缓冲帧环大小模型与 PostgreSQL 18 的动态 io_combine_limit" 和 effective_io_concurrency" 规则保持一致；扩展交互式查询计划路径；实施每夜运行的变异测试门禁，以针对上游 REL_18_STABLE 分支强化确定性验证引擎。完整代码库、文档和运维测试套件均可在 PGSimCity GitHub 仓库"中获取，并采用 Apache-2.0 许可证"，鼓励开发者提供反馈、创建分支并参与贡献。

原文链接：https://www.infoq.com/news/2026/08/pgsimcity/"

事故频发并不意味着可靠性下降

作者：Craig Risi — Sun, 23 Aug 2026 01:10:00 GMT

IT 工程项目领导者最常见的假设之一，是报告的事故数量不断增加就意味着系统可靠性正在下降。然而，Great Circle 最近的一篇文章"提出，实际情况往往恰恰相反：事故数量增加，反而可能意味着组织的事故管理文化正在改善。随着团队不断投入资源完善流程、工具、培训和运维规范，他们会更愿意正式地将那些过去大概只会被悄悄处理、甚至被隐瞒的事故报告上去。这样带来的结果就是组织对运营问题的可见性提高了，但却不一定意味着系统的健康状况恶化。

这篇文章对业内广泛采用事故数量作为关键绩效指标（KPI）的做法提出了质疑。文章认为，事故数量衡量的其实是组织发现并处理运营问题的意愿，而不是系统本身的可靠性。成熟的事故管理文化会鼓励工程师尽早报告事故，让适当的利益相关者参与进来，并开展结构化的事故复盘。虽然这通常会导致提交上去的事故数量在初期有所增加，但同时也创造了更多学习、改进流程以及预防未来更大规模中断的机会。

这一现象在其他工程领域也十分常见。加强漏洞管理后，组织往往会发现更多安全问题，但这并不意味着系统突然变得更不安全，而是因为组织检测安全弱点的能力提高了。同样，引入更好的可观测性通常会带来更多告警消息，而更完善的测试则会在软件进入生产环境之前发现更多缺陷。在这些情况下，更好的度量体系暴露的是原本不可见的既有问题，而不是制造了新的问题。

事故管理遵循着同样的规律。过去，工程师可能会默默解决那些难搞的 Bug，或悄悄处理服务降级问题；如今，他们可能会选择将事故正式报告，从而触发协同响应流程、文档记录和事后复盘。虽然仪表盘上的事故数量有所上涨，但组织实际上是通过让运营知识变得可见且可复用，从而提高了自身的韧性。

这一观点也与可靠性工程领域更广泛的发展方向一致。现代 SRE 实践正在逐步摆脱简单的运营指标，转而关注能够反映用户影响、恢复效率和组织学习能力的指标。与其问“发生了多少起事故”，不如进一步追问：“用户在事故发生多久后受到影响？”“服务的恢复有多快？”“是否找到了根因？”以及“类似故障发生的频率是否正在下降？”

Sygnia" 近期发布的相关指导也提出，许多传统事故指标，包括原始事故数量、工单数量，甚至单独观察时的平均响应时间（MTTR），都可能营造出虚假的信心，因为这些指标衡量的是运营活动，而不是组织的应对准备程度。相较之下，该指导建议关注遏制措施的有效性、升级处理的质量、事故后的改进，以及事故响应流程的成熟度等指标。

同样，围绕 Service Level Objectives" (SLOs) 构建的现代可靠性实践，也越来越强调以用户为中心的指标，例如错误预算消耗（error budget burn）、SLI 降级程度和用户影响，而不是以基础设施为中心的统计数据。可靠性平台认为，理解用户如何感知故障，比单纯统计事故数量或只衡量基础设施正常运行时间，更能准确反映服务健康状况。

Great Circle 最重要的观点或许并非技术层面的，而是文化层面的。组织不应该为了让看板上的指标更好看，就打压上报事故的行为。如果工程师认为自己会因为事故数量过高而受到批评，那他们可能会推迟事故的上报、试图独自解决问题，或者直到当前的问题严重恶化后才进一步上报。这些行为会降低组织的可见性，而恰恰是在这种最需要快速协作的时候，组织最不应该失去这种可见性。

相反，健康的 IT 工程组织会对提升透明度的行为予以奖励。这样的组织能认识到，事故的上报并不是承认失败，而是结构化学习过程的开始。通过鼓励尽早报告、无责协作和持续改进，组织可以让运营知识随着时间积累，而不是将这些知识局限在个别事故处理人员手中。

更为广泛的寓意是指标应该反映组织真正关心的结果。事故数量下降可能意味着可靠性提高，但同样可能意味着事故漏报、分类标准不一致，或者事故管理文化正在被削弱。反过来，事故报告数量暂时的增加，也可能代表运营实践更加健康，组织对自身问题的认知更加充分。

查看英文原文：More Incidents Don't Necessarily Mean Less Reliability"

Cloudflare 推出 Cache Response Rules，在源站响应后进一步控制缓存

作者：Renato Losio — Sat, 22 Aug 2026 09:17:00 GMT

Cloudflare 近日推出缓存响应规则（Cache Response Rules"），这是一套新的规则引擎，运行在源站返回响应之后、内容写入 Cloudflare 缓存之前。此前，缓存规则（Cache Rules）只能根据请求属性进行判断；缓存响应规则则新增了一个响应处理阶段，可以在响应进入缓存之前检查源站返回的内容。

根据官方文档，缓存响应规则"允许用户修改 Cache-Control 指令、管理 Cache Tag，以及移除 Set-Cookie、ETag 和 Last-Modified 等 Header，而无需修改源站应用本身。

这为缓存行为提供了更细粒度的控制，有助于提高缓存命中率，也能简化 CDN 迁移。

Cloudflare 高级产品经理 Alex Krivit" 和前系统工程师 Anthony Turcios" 写道：

如果你曾经因为一些本来应该轻松留在缓存中的内容，被一个多余的 Set-Cookie 或错误的 Cache-Control Header 强行拉回源站而感到恼火，那么缓存响应规则正是为解决这个问题而生，而且它恰好在正确的时机发挥作用。

来源：Cloudflare 博客

目前，缓存响应规则支持三类操作：移除影响缓存的 Header、管理 Cache Tag，以及修改 Cache-Control 指令。

缓存决策实际上分为两个阶段。在请求阶段，规则会决定是否查询缓存，以及应该如何查询，然后才会联系源站；新的缓存响应规则在源站返回响应之后运行，让用户可以在内容写入缓存之前，根据响应 Header 调整缓存行为。例如，当访问者请求 /static/app.js 时，Cloudflare 首先检查缓存。如果没有找到该文件，请求就会被转发到源站，由源站返回响应。假设响应 Header 中包含一个 Set-Cookie。Krivit 和 Turcios 解释了其中的问题：

原本应该缓存在每个 Cloudflare 数据中心的静态资源，现在却无法缓存了。如果每个网站的每位访问者都遇到同样一个意外的 Header，最终结果就是缓存命中率不断下降，源站带宽被大量消耗，性能受到影响，基础设施成本也随之上升。

缓存响应规则会在 Cloudflare 收到源站响应之后、将响应写入缓存之前执行。这样，用户无需修改源站应用，就可以调整与缓存相关的 Header、管理 Cache Tag，并移除指定 Header。

此前，Cloudflare 已经提供缓存规则"，用于控制 Cloudflare 如何处理进入的请求，以及是否从缓存中读取内容或将内容写入缓存。新的缓存响应规则是在源站返回响应之后执行，可以在响应真正写入缓存之前修改与缓存相关的 Header。Cloudflare 团队强调，两者并不是替代关系，而是互为补充：

缓存响应规则并不会取代缓存规则。缓存规则在请求阶段决定是否缓存、缓存什么，以及如何缓存。缓存响应规则则会在 Cloudflare 看到源站响应之后，在此前不存在的这个处理阶段，对缓存方式和是否缓存做出最终决定。

来源：Cloudflare 博客

Cloudflare 的这一变化也引发了一些讨论。领英用户 Marcella dePunzio 表示"：

提升缓存性能往往取决于优化响应行为，而不是增加更多基础设施。让团队能够在边缘侧更灵活地控制缓存策略，可以提高效率、降低源站负载，并简化应用管理，而且无需修改代码。

也有一些从业者对此持保留态度"，担心如果工程师错误地将动态内容判断为可缓存内容，强制缓存可能会带来问题。Mission FinOps 创始人 Yuvdeep Singh 则表示"：

无需等待应用完成修改，直接在边缘侧修正源站的错误，这是一个很大的优势。

缓存相应规则目前已向所有 Cloudflare 套餐开放。

查看英文原文：Cloudflare Introduces Cache Response Rules for Post-Origin Cache Control"

Cloudflare 推出 Agent Tracing：支持截断限制，不同框架的 Payload 默认记录策略存在差异

作者：Steef-Jan Wiggers — Sat, 22 Aug 2026 07:15:00 GMT

Cloudflare 推出了 Cloudflare Agents 的首个组件，Agent Tracing"（Agent 追踪），可提供用于集中查看已经部署的 Agent 会话的统一 Dashboard。此次发布在现有 Workers Tracing 的基础上增加了 Agent 级别的 Span，同时也伴随着明确的收费时间表：Beta 期间免费，2026 年 10 月 1 日起将纳入 Workers Observability 的计费体系。

这一功能真正要解决的问题值得关注。一个 Agent 即使返回 HTTP 200，也不意味着它运行正常。它可能选择了错误的工具，将过时的上下文交给 Subagent，或者在重试循环中不断消耗 Token。而应用层遥测通常只能告诉你发生了一次 API 请求或数据库查询，却无法解释究竟是什么 Agent 行为导致了这些问题。

此前，Workers Tracing" 已经能够对基础设施层进行追踪，包括 Fetch 调用、KV 读取和 D1 查询等。但直到现在，在 Workers 上运行的 Agent，其 Trace 中只有这些基础设施 Span，缺少 Agent 自身行为的信息。Agent Tracing 新增了 Agent 调用、模型调用、工具执行和审批等 Span，并将模型信息和 Token 使用量作为元数据附加到其中。每一轮交互都会生成一条 Trace：

invoke_agent {agent class} ├── chat {model} └── execute_tool {tool} └── tool_approval {tool}

Subagent 的工作会嵌套在调用它的操作之下。因此，如果一个父 Agent 将任务交给 Subagent，而 Subagent 又调用模型、执行工具、查询 D1 并写入 KV，那么整个过程就会以一条完整的瀑布流呈现出来，覆盖两个层级。有三个字段用于将 Span 与 Dashboard 中的 Agent 对应起来：Agent name 用于标识逻辑实现，Agent ID 用于标识具体实例，Conversation ID 则用于标识会话。Cloudflare 特别提醒，不要根据请求或用户标识符动态生成 Agent name，否则 Dashboard 中会出现大量不同的 Agent。

这种关联方式正是开发者对这一功能感兴趣的地方。在 Cloudflare 的 X 平台公告"下，Mykyta Pavlenko 留言称：

我想在 Hermes 上试试这个功能，就为了看 Trace 瀑布流——能够直接看到模型调用下面紧接着出现一个错误的工具参数，这正是我想要的调试视图。

不过，Approval Span 本身存在一个值得注意的限制。文档"指出，这类 Span 表示 Worker invocation 内部的生命周期事件，并不会记录用户跨多个 invocation 进行响应时所等待的时间。换句话说，Human-in-the-loop 延迟（或许是审批流程中最值得关注的指标）并不是这个 Span 所记录的内容。

除了 Trace 视图之外，Session Replay 还可以跨多个交互轮次重新组合已经记录的会话，包括消息、推理过程、带参数和结果的工具调用，以及 Subagent 活动。Cloudflare 明确指出，这一功能只是重放已经记录的数据，并不会重新执行 Agent。

真正需要团队特别关注的是 Payload 记录，因为不同开发框架的默认行为并不一致。Think 默认不会保存消息或工具 Payload，除非在 Agent class 中设置 storeMessages 和 storeTools；wrapAISDK() 的行为也相同。而 Flue 默认会保存消息、系统指令、工具定义、参数和结果，需要设置 content: false 才能停止记录。也就是说，同一平台提供的这一功能，根据团队所使用的 Harness 不同，默认隐私策略可能完全相反。而消息 Payload 中又经常包含个人数据或 Secret。

文档列出的限制同样值得关注。Cloudflare 明确表示，Trace 并不是完整且无损的会话记录；Payload 数据受到 Span 大小限制，因此较长的消息、推理过程、工具参数和工具结果都可能被截断。此外，Session Replay 不会显示图片。如果团队把 Replay 当作审计记录，而不仅仅是调试工具，那么这些限制意味着它可能无法完全胜任。

具体配置方式取决于使用的技术栈。Think 和 Flue v2 及更高版本会自动对每轮交互进行埋点。直接调用 AI SDK 时，则需要使用 wrapAISDK() 进行封装。它支持 v6 和 v7，并要求在每次调用中提供身份字段，因为此时不存在可以自动提供这些信息的 Agent 实例。

自定义 Harness 则需要使用 Workers Custom Spans API，并遵循 OpenTelemetry 的 GenAI 参考实现，因为 Workers 目前还不直接支持 OpenTelemetry API。Cloudflare 表示，他们正在开发这项支持。完成后，能够生成标准 Span 的框架就可以直接接入，而无需手动埋点。

Span 属性遵循 OpenTelemetry 的生成式 AI 语义约定"，Trace 则可以导出到任意 OTLP Endpoint。

计费细节也值得仔细阅读，因为实际计费单位与 Agents 视图中显示的内容并不完全相同。每个 Span 都会计为一次 Observability Event，包括 SDK 内部产生的 Span，以及其他 Worker 层面的操作，即使这些内容并不会显示在 Agents 视图中。从 2026 年 10 月 1 日开始，Workers Free 每天包含 20 万次 Event，保留期为 3 天；Workers Paid 每月包含 2000 万次 Event，保留期为 7 天，超出部分按每 100 万次 0.60 美元计费。因此，一个产生大量 Span 的复杂 Harness，其实际成本可能高于 Dashboard 给人的直观印象。而对于需要追踪长期趋势、而不仅仅是排查单次事故的团队来说，3 到 7 天的保留期也相对有限。

这一发布与本季度多个厂商呈现出的趋势一致。微软的 Agent Framework Harness" 默认启用了 OpenTelemetry；Azure API Management 的 AI Gateway 层也可以将 Token 指标导出到 Application Insights、Datadog 和 Grafana。虽然各家厂商采取的路径不同，但最终得出的结论基本一致：Agent Runtime 需要自己的遥测层，仅靠基础设施 Span 无法解释 Agent 究竟做了什么。

Cloudflare 将 Tracing 描述为构建能够持续自我改进的 Agent 的一步，未来可以将结构化 Trace 数据用于评估以及 Agent 开发生命周期。这仍然只是 Cloudflare 当前提出的发展方向。目前已经实现的能力，则是让开发者能够看到每轮交互调用了哪个模型、消耗了多少 Token、选择了哪个工具，以及时间究竟花在了哪里。

查看英文原文：Cloudflare Adds Agent Tracing, with Truncation Limits and Uneven Payload Defaults"

npm 终于动手了：默认封杀 postinstall 脚本

作者：Daniel Curtis — Sat, 22 Aug 2026 03:05:00 GMT

由 GitHub 维护并随 Node.js 一同提供的软件包管理器 npm 发布了 npm 12"。该版本更改了 npm install 的一系列安全相关默认行为，同时弃用可以绕过双因素认证的细粒度访问令牌。

npm 12 将此前自动执行的三种安装行为改为需要开发者明确选择启用。这些更改于今年 6 月首次公布"，并从 npm 11.16.0 开始通过警告形式提供，以便团队在升级前做好准备。

最重要的变化是 allowScripts 现在默认为关闭。依赖项的 preinstall、install 和 postinstall 脚本不再运行，除非项目明确允许它们运行。这也包括任何包含 binding.gyp 文件的软件包隐式执行的 node-gyp 构建，即使该软件包并未声明安装脚本。来自 Git、文件和链接依赖项的 prepare 脚本也会以相同方式被阻止。开发者可以审查等待运行的脚本，批准自己信任的脚本，然后将生成的允许列表提交到 package.json 中。

另外两项默认设置针对非注册表来源。--allow-git 现在默认为 none，关闭了一条代码执行路径：在这条路径中，即使设置了 --ignore-scripts，Git 依赖项自己的 .npmrc 仍可以覆盖 Git 可执行文件。--allow-remote 也默认为 none，用于阻止 HTTPS tarball 依赖项。相关的 --allow-file 和 --allow-directory 标志保持不变。

GitHub 的迁移讨论"建议首先允许依赖树中已经存在的内容，然后再逐步收紧限制，并提供了针对原生模块、Cypress、Playwright、Puppeteer、Electron 和 Husky 的配置方法。全局安装和 npx 无法使用 approve-scripts，需要改用配置，例如 npm config set allow-scripts=canvas,sharp --location=user。完整细节可参阅 npm approve-scripts"、npm deny-scripts" 和 allow-scripts 配置"文档。讨论中的评论者指出，现有的 ignore-scripts=true 设置具有更高优先级，会在没有提示的情况下使允许列表失效；新安装的软件包还会造成一个先有鸡还是先有蛋的问题，因为 npm approve-scripts 会从 node_modules 中读取信息，如果软件包尚未安装，就会报告 ENOMATCH 错误。

社区的整体反应较为支持。Hacker News 上的讨论"获得了 484 分和 200 多条评论，atraac 写道：

postinstall 脚本早就应该被移除了，它就是 NPM 软件包的毒瘤。依赖深处存在大量不受控制的 postinstall，只要拉取一些东西，它们就会随机运行，简直荒谬。我不知道当初怎么会有人认为这是一个好主意。

其他人则没有那么信服。gear54rus 指出了 patch-package" 等合理使用场景，cookiengineer 则认为允许列表“没有作用域”，导致“你的依赖项所依赖的任何软件包是否需要脚本都变得不可预测”。

安全研究人员认为，更大的风险在于审批疲劳。OpenSourceMalware 的一位分析师在文章"中指出，esbuild、sharp、core-js、puppeteer 和 bcrypt 都依赖生命周期脚本，并警告反复出现的构建失败会让默认拒绝机制变成“一个直接点过去的提示框”，同时把攻击者的活动推向可见性更低的攻击面。JFrog" 报告称，在过去一年观察到的恶意 npm 攻击中，这三种攻击途径涉及的事件约占 53%。

npm 也是最后一个采用这些控制措施的主流软件包管理器。pnpm 多年来一直提供安装脚本允许列表。在冷却期机制方面，pnpm 10.16 引入了 minimumReleaseAge，Yarn 4.10.0 增加了 npmMinimalAgeGate，Bun 随后在 1.3 版本中跟进，这些都早于 npm 自己在 11.10.0 中推出的 min-release-age。

npm 是 Node.js 的默认软件包管理器，由 GitHub 维护。它托管着全球最大的软件注册表，为开发者提供命令行客户端和注册表，用于安装、共享和发布可复用的 JavaScript 与 TypeScript 软件包。作为更广泛的 Node.js 生态系统的基础组成部分，npm 被广泛用于前端和后端项目，以管理依赖项、运行脚本，并大规模分发开源代码。

原文链接：https://www.infoq.com/news/2026/08/npm-12-released/"

JetBrains详细阐述了控制AI支出快速增长的首批举措

作者：Matt Foster — Sat, 22 Aug 2026 01:05:00 GMT

JetBrains在一篇博客文章中介绍"，在开发相关支出在六个月内大约增长十倍后，公司如何开始集中管理AI的使用。公司没有限制工程师只能使用少数已批准的工具，而是构建了一个共享的访问与记账层，其目标是在保留工具选择的同时，为团队提供更高的可见性与控制能力。

随着AI的使用在公司内部加速增长，变化逐步显现了出来。JetBrains表示，大多数开发者每月会使用3到5个AI工具，而自2026年1月起，随着更强模型的出现（包括Claude Opus 4.5和4.6），token消耗开始急剧上升。

工具多样性使得账单变得越来越难以理解。JetBrains最初花了四天时间将AI的使用与费用数据手动汇总到电子表格中，以生成各供应商与工具开销的快照。随后公司通过供应商API与内部仪表盘实现了自动化，为团队提供持续更新的当前与预测支出视图。

然而，可视化并不能方便地进行干预。仪表盘可以显示支出发生的位置，但请求仍然直接从各个工具发往相应的供应商。

随后的进展来源于一个由单个开发者最初构建的内部工具。JetBrains将该wrapper扩展为Central CLI，提供了一种统一的方式来调用自研与第三方AI工具。通过CLI发起的请求会经由公司现有的AI平台路由，从而在开发者与底层模型供应商之间建立一个共享的控制点。

这使得平台的角色从事后观察AI支出，转变为参与产生这些流量的组成部分。JetBrains可以将现有的AI-credit体系应用到第三方工具，同时管理者可以查看支出并为单个开发者、团队或更大组织单元配置限制。

公司刻意避免通过大幅减少可用工具的数量来解决问题。JetBrains表示，他们曾经见过其他组织标准化为一两个AI产品，但该公司认为市场变化速度很快，几个月后某一工具可能就不再是最佳选择。

集中化访问层可以将这两个问题分离开来。开发者可以继续在支持的工具中选择，而记账、访问管理与支出控制则位于其下层。

据JetBrains称，在数周内已有超过1000名开发者采用Central CLI，但该系统尚未覆盖所有的AI支出源。一些基于终端智能体与个人订阅仍在受控路径之外，公司也在制定在不同用户与团队间公平分配AI预算的策略。

更广泛的成本管理问题正变得越来越常见。FinOps Foundation已将生成式AI视为FinOps职责范围日益增长的一部分"，并建议采用集中化的方法来跟踪AI使用与成本。其他组织对不断上升的消耗也有直接反应：据ITPro报道"，埃森哲要求员工减少不必要的AI使用，而优步在四个月内耗尽年度AI预算后引入了月度限制。

JetBrains选择了不同的路径。公司不是从限制开发者可用工具入手，而是尝试集中管理那些用于衡量与治理这些工具的基础设施。

查看英文原文：JetBrains Details Its First Steps to Bring Rapidly Growing AI Spend Under Control"

神秘“Ox Alpha”突袭 OpenRouter，性能超过 Fable 5？全网盲猜智谱 or 小米

李冬梅 — Fri, 21 Aug 2026 11:41:49 GMT

电影圈的“牛来”刚刚火遍全网，大模型圈也来了一头身份不明的“牛”。

今天上午，OpenRouter 没有举行发布会，也没有公布技术报告，只用一个忍者表情放出了一款代号为“Ox Alpha”的神秘模型。“Ox”在英文中正有“牛”的意思，于是，一场属于 AI 行业的“牛来”也开始了。

OpenRouter 对这款神秘模型的介绍很短，基本就一句话概括了：这是一款面向高效编程、长时间 Agent 任务和真实生产环境的前沿模型，拥有100万Token上下文窗口，同时支持文本、图像和视频输入。

除此之外，模型参数、训练数据、架构、基准成绩以及开发团队全部处于保密状态。

神秘模型 Ox Alpha 引发热议

目前能够确定的是，Ox Alpha 并不是 OpenRouter 自己开发的模型。OpenRouter 只负责将用户请求路由给背后的第三方供应商，而后者选择在预览期间保持匿名。

这让 Ox Alpha 在上线几小时后迅速变成一场大型“猜模型”游戏。

从 Google Gemini、小米 MiMo V3 到腾讯混元新模型，不同猜测陆续出现。

更重要的是，在人们试图识别它到底是谁之前，OpenRouter 表示它目前是免费的。

根据 OpenRouter 公布的信息，Ox Alpha的完整模型标识为：

stealth/ox-alpha

它是一款以推理和编程为主要方向的模型，重点面向三类任务：长周期软件工程、复杂推理，同时结合文本与视觉信息的Agent工作流。

据介绍，Ox Alpha 拥有超 100 万 Token 上下文窗口，最大输出长度达到 13 万 Token。

这意味着，它理论上可以一次读取规模较大的代码仓库、长时间积累的Agent执行记录，或者由文本、图片和视频共同组成的复杂任务。

模型支持文本、图片和视频输入，但输出形式仍然只有文本。

值得一提的是，在 Ox Alpha 介绍页面的 FAQ 部分，有一个问题是问 Ox Alpha 是否支持工具调用和结构化输出？

显示的回答是：它能够支持工具调用、tool_choice以及 JSON 格式的结构化输出，不过暂不支持严格的 JSON Schema 约束。

这些特征说明，Ox Alpha 并不只是面向聊天或单次代码补全，还可能是为了 Coding Agent 准备的执行模型。

长时间Agent任务对模型的要求，与普通编程问答并不相同。

它不仅要生成一段正确代码，还需要持续读取文件、调用工具、跟踪修改状态、运行测试，并在失败后重新规划。如果上下文稍长就忘记目标，或者连续调用几次工具后开始偏离任务，即便模型在代码基准上得分很高，也很难真正进入生产环境。

OpenRouter 因此没有把 Ox Alpha 描述为单纯的“代码模型”，而是反复强调“sustained agentic work”，即能够持续进行的Agent工作。

截至目前，OpenRouter页面显示，Ox Alpha 的中位首 Token 延迟约为 1.95 秒，输出速度约为每秒 49 Token，最近三天的可用率接近100%。

不过模型刚刚上线，这些数据的采样周期和调用规模都非常有限，后续很可能继续变化。

更值得注意的是，OpenRouter 没有公布任何 SWE-bench、Terminal-Bench或其他编程与Agent 基准成绩。

换句话说，OpenRouter 使用了“frontier model” 这一定位，但目前还没有公开证据证明 Ox Alpha 在性能上已经进入GPT、Claude 或 Gemini 旗舰模型所在的第一梯队。

它究竟是新的旗舰模型，还是针对速度、成本和 Agent 任务优化的中型模型，根据已知信息，还暂时无法判断。

不过，这款模型目前虽然还不知道出自谁手，但最大的好处是，它现在免费呀！

Ox Alpha 目前在OpenRouter上的输入和输出价格均为零。

对于一款拥有100万Token上下文、支持视频输入和工具调用的模型而言，完全免费的API并不常见。

作为对比，同样拥有百万级上下文的 Gemini 3.7 Flash，在 OpenRouter 上的价格为每百万Token 输入 0.375 美元、输出 1.875 美元；GPT-5.6 Sol Pro则为每百万 Token 输入2.5美元、输出15美元。

不过，Ox Alpha的免费并不是永久定价。

OpenCode 随后宣布，Ox Alpha 将在其平台上免费开放一周，提供较宽松的速率限制和接近无限的使用额度。

OpenCode 发文称他们为这次测试准备了每天 100T Token（Trillion，表示万亿）的容量，其联合创始人 Dax 在X上向开发者喊话：“快来猜猜是啥模型吧！”

有一说一，100 万亿 Token 确实是一个很有诚意的公开测试邀请了。

这意味着，隐藏在 Ox Alpha 背后的模型厂商可能不只是想收集几百条聊天反馈，而是希望观察模型在真实Agent Harness、代码仓库和长周期任务中的表现：它会在哪些工具调用中失败，面对多长上下文开始遗忘，连续修改几十个文件后是否仍能维持目标，以及开发者最终是否愿意继续使用。

测试效果如何？

模型放出后，在国外技术社区引发了一波集中测试。

在 X 平台，有用户测试过后，表示用起来很不错。

还有用户拿出了最难的 AI 测试题——鹈鹕骑自行车SVG任务。

该用户对 Ox Alpha 的不同推理档位进行了 15 次对照测试：在相同提示词、相同温度下，分别以 low、high 和 max 三档推理强度各生成 5 次。

从结果看，模型基本都理解了任务，能够稳定画出鹈鹕、自行车、车轮和骑行动作，说明其代码生成与空间关系表达具备一定稳定性。

但仔细观察仍能发现，部分样本中鹈鹕的腿没有踩在踏板上，车架结构不完整，翅膀、身体与车把之间也偶尔出现不合理连接。

更值得注意的是，推理强度提高后，质量提升并没有与计算开销保持同步。

low 档通常只需约 13 至 21 秒，推理字段几乎为空或只有十几个字符。

high 档耗时仍维持在 19 至 23 秒左右，画面细节和结构一致性有所改善。

最后到了max档，模型的推理字段骤增至约1.7万至6.2万个字符，单次生成耗时也拉长至124至355秒，Token消耗最高超过2.6万。

最终图像确实增加了云朵、太阳、头盔、速度线和更复杂的车轮结构，但核心构图并没有出现同等幅度的提升，个别样本甚至仍存在脚与踏板错位、车架比例失衡等问题。

这组测试其实很能说明问题：一是它能够比较稳定地完成需要生成可视化代码的任务；二是其最高推理档位存在明显的“过度思考”倾向——模型花费数十倍的推理字符和十几倍的时间，换来的主要是装饰细节，而不是结构准确性的根本改善。

另一部分用户更关注它是否适合Agent任务。

有人表示，Ox Alpha能够在经过两次需求澄清后，完成自己预期的功能；也有人尚未开始测试，就已经因为免费额度和百万上下文把它接入OpenCode。

还有用户把注意力放在“100万亿Token”上，认为这更像一场公开压力测试，而不是常规产品发布。

社区中目前比较一致的态度是：免费、上下文足够长，可以尝试；但在身份、稳定性和真实能力得到确认之前，不适合仅凭“frontier”标签替代成熟的生产模型。

这种谨慎并非多余。OpenRouter此前已经上线过多款Alpha匿名模型。社区往往会在发布初期把它们猜成下一代GPT、Gemini或Grok，但模型身份揭晓后的实际定位，未必与最初的想象一致。

免费开放还带来了另一个现实作用：为模型进行极大规模的真人压力测试。

相比模型厂商自己设计的Benchmark，开发者会把模型接入OpenCode、Claude Code类Harness，放进真实项目，要求它修复依赖冲突、阅读混乱代码、操作终端、浏览网页，甚至连续工作几个小时。这些失败案例对准备正式发布的模型厂商可能比排行榜分数更有价值。

免费并不是没有代价，只是测试费用由模型公司承担，开发者则贡献真实任务和反馈。

此外，在x 上，有用户对该模型与其他模型进行了更详细的对比测试，该用户让 Ox Alpha 在 10个具体的任务中跑一遍。

从结果看出，Ox Alpha最终通过8个、失败2个，因此是80%。

其他模型每个任务测试了4次，有的模型在 4 次任务中全部成功，有的任务某个模型成功2次；

还有的全部失败了。

最后一行是这10项任务的平均通过率：

Fable 5：65%GLM-5.3：62%GPT-5.6 Sol：52%Grok-4.6：62%Ox Alpha：80%

从表面结果看，Ox Alpha 在这10项任务里排名第一，比第二名Fable 5高15个百分点。

综合结果来看，Ox Alpha 表现出了接近甚至超过前沿模型的潜力，但样本太少，测试口径也不完全一致，也不能直接判断它已经击败GPT、GLM 或 Fable。

在这条测评贴下面，一些用户看到结果后评论，“感觉把Fable 5都干掉了”。

因此有人猜测，这是智谱的能力水平。

关于模型归属的猜测

匿名模型上线后，社区最关心的问题不是怎么用，而是“它到底是谁”。目前主要出现了四类猜测。

第一种猜测：小米MiMo V3

在Reddit、x 等平台上，MiMo V3是目前出现频率较高的答案。

这种猜测主要建立在三条线索上。

第一，时间点接近。8月18日，小米集团 CFO 林世伟在财报电话会上透露，新一代MiMo模型正在训练，有望很快发布。但小米并未公布具体型号，因此“MiMo 3.0”只是网友暂时使用的称呼，并非官方名称。

第二，小米此前有过在 OpenRouter 匿名测试模型的先例。

今年3月，代号Hunter Alpha的神秘模型在OpenRouter免费上线，一度被外界猜测为DeepSeek V4，随后小米确认，它实际上是MiMo-V2-Pro的早期内部测试版本。

Hunter Alpha同样拥有100万Token上下文，且面向Agent任务，上线后很快突破1万亿Token调用量。

第三，两者的产品定位存在重合。Ox Alpha 被描述为面向高效编程、持续 Agent 任务和生产环境；目前的 MiMo 系列同样把代码、工具调用和长周期 Agent 执行作为重点方向。

Ox Alpha 的 100万Token 上下文，也与 MiMo-V2.5 和 MiMo-V2.5-Pro 的百万级上下文接近。

所以在 Reddit 上，有一位用户猜测，这款模型就是 MiMo V3，后面有用户继续提问，他的猜测理由是什么。

有另一位用户回答了这个问题，他写道：“Mimo 确实经常以 100 万亿 Token 为单位进行预算。例如，Mimo 100 万亿 Token 计划。

更有一名用户直接判断：“这很可能就是MiMo V3，趁它还开放的时候用吧。”

这类猜测目前主要来自发布时间、免费测试策略和模型定位，并没有确凿技术证据。

第二种猜测：腾讯混元HY 4

另一部分网友认为，Ox Alpha 可能来自腾讯混元。

一篇 Reddit 帖子直接将模型指向“HY 4”，理由是能够支撑如此大规模免费调用的厂商并不多，腾讯在算力和推理基础设施上具备相应条件，同时也可能需要在正式发布前收集真实Agent任务数据。

下面有用户附和说，由于最近在和Hy 3合作，这就说得通了。

跟上面一样，这些都只是网友们的猜测。目前没有 OpenRouter、腾讯或第三方评测机构给出能够把 Ox Alpha 和混元模型联系起来的证据。

第三种猜测：Google Gemini系模型

Ox Alpha 拥有100万 Token 上下文，并原生支持图片和视频输入，这两个特征很容易让人联想到 Gemini。

有 x 用户发帖猜测，这是披着神秘外衣的 Gemini 模型。

有用户向模型询问身份后发现，Ox Alpha 自称 Gemini，于是把截图发到X上。

但让模型“自报家门”并不是可靠的鉴别方法。模型可能从训练数据、系统提示或上下文中生成一个看起来合理的答案，也可能在不同询问方式下给出完全不同的身份。

尤其对于Stealth Model而言，提供方通常会主动隐藏模型信息，模型回答“我是Gemini”“我是Claude”或者“我是某个OpenAI模型”，都不能作为归属证据。

如果仅从百万上下文和视频输入判断，Gemini确实是候选之一，但同样的能力正在越来越多的新模型上出现。它更像是一条缩小范围的线索，而不是答案。

第四种猜测：智谱 GLM-5.3

除此之外，还有网友怀疑它是智谱尚未发布的新模型。

有用户通过分析结果得出猜测，认为这是GLM-5.3 的变体，在25个不同的提示中，原生token 数量和 GLM-5.3 完全匹配，ox 也接受图像输入。

还有用户表示，它在50/50的对抗字符串测试中与 GLM-5.3 的分词器匹配度最高，而 Gemini、DeepSeek 和Kimi 的匹配度仅为18-22%，同时 OXAlpha 还拥有其罕见的API指纹。

在国内知乎平台，有用户猜测，这种风格很智谱，他们之前出过一个名为 Pony Alpha 的模型，现在又出了Ox 模型，正好对上了。

Stealth Model正在成为一种新的发布机制

除了上述种种猜测外，还有网友表示，这几乎形成了一个有些荒诞的局面：几乎每一家正在准备新模型的公司，都可以被套进 Ox Alpha 的身份猜测中。

过去，模型发布通常由厂商主导：先公布名称和技术报告，再展示基准成绩，最后向开发者开放API。用户知道自己正在测试谁，但也很容易受到品牌和宣传信息影响。

Stealth Model反过来操作。

模型先匿名进入平台，开发者在不知道品牌、参数和排行榜的情况下直接使用。提供方可以获得更接近真实环境的评价，也可以避免一次不成熟的预览影响正式品牌。如果模型表现出色，最终揭晓身份还能再制造一轮传播；如果效果不理想，则可以低调结束测试。

对 OpenRouter 而言，这种机制也强化了它在模型产业链中的位置。

OpenRouter 不再只是汇总不同模型API的“路由中间层”，还可以成为模型公司的公开试验场：统一接口、真实开发者、大量Agent流量和相对完整的使用数据，为尚未正式发布的模型提供灰度环境。

Ox Alpha的匿名身份暂时遮住了模型公司的名字，却把行业正在变化的发布逻辑暴露了出来：下一代模型可能不再先开发布会，而是先悄悄进入开发者的终端，工作一周，消耗数万亿Token，再带着真实反馈正式亮相。

至于忍者面具后面究竟是小米、腾讯、Google，还是一家尚未进入公众视野的模型公司，目前没有任何一种猜测获得证实。

等面具揭开的那一天，人们也许才会知道，它究竟是一款真正的前沿模型，还是一次包装得很成功的匿名灰度。

参考链接：

https://openrouter.ai/stealth/ox-alpha"

https://x.com/himustafatokmak/status/2090601134767439976/photo/1"

https://x.com/search?q=opencode%20Dax&src=typed_query"

https://www.reddit.com/r/opencode/comments/1vtxp6t/identity_of_the_ox_alpha_model_hy4/"

https://www.reddit.com/r/opencode/comments/1vtw0aq/guess_what_another_one_free_model_ox_alpha_in/"

DeepSeek 发布多模态模型，“小鲸鱼”长出了眼睛

李冬梅 — Fri, 21 Aug 2026 11:34:36 GMT

刚刚，DeepSeek在 API 平台上线实验模型deepseek-v4-flash-vision-exp，开始提供图像理解服务。

根据 DeepSeek 官方文档，用户可以通过设置来访问 V4-Flash-Vision-Exp 模型的 API。在 API 服务中，图片会转换成 token 后按 token 计费，一张图片最多占 384 tokens，计费价格与 V4-Flash 模型一致。

多模态 API 支持 Chat Completions、Messages、Responses 三种格式调用，可以方便接入各类 Agent 工具中使用，支持图文混合输入，支持 base64 内联、外部 URL、Files API 三种图片传入方式。

这是 DeepSeek V4 系列首次通过官方 API 明确开放视觉输入，也补上了其在多模态开发场景中的一块能力拼图。

在此之前，DeepSeek V4 系列主要以文本推理、代码生成和Agent能力见长。

4 月发布的 V4-Flash 采用混合专家架构，总参数量2840亿、每个 Token 激活约 130 亿参数，并将 100 万 Token 上下文作为默认配置。

7 月底上线的 V4-Flash-0731 又通过新一轮后训练，重点强化工具调用和长周期 Agent 任务。

但相比之下，Vision-Exp 模型多数指标高于V4-Flash-0731。

在七项测试中的六项发生变化，其中五项提升、一项小幅下降：

Terminal Bench 2.1：82.7→83.9NL2Repo：54.2→57.7DeepSWE：54.4→59.3Toolathlon-Verified：70.3→75.9DSBench-Hard：59.6→63.6AutomationBench：25.1→25.7Cybergym：76.7→75.3，下降1.4分

提升最明显的是Toolathlon，新模型增加5.6分；其次是DeepSWE，增加4.9分。

这两项都与工具调用、真实代码库修改和长周期Agent执行有关。

这意味着，Vision-Exp可能并非简单地在V4-Flash外面接入一个视觉编码器，而是在后训练或多模态Agent训练中，同时改善了模型理解环境、规划任务和调用工具的能力。

与 Opus 4.8 相比，Vision-Exp在大多数文本Agent测试中仍然稍弱。例如NL2Repo低12分，DSBench-Hard低8.1分。

但它在DeepSWE上达到59.3，超过Opus 4.8的58.0；Toolathlon上为75.9，也只比Opus低0.3分。

所以更准确的结论是：Vision-Exp的文本Agent能力整体接近Opus 4.8，在个别代码Agent测试上实现反超，但尚未全面超过。

这款模型在正式上线前已经短暂留下过痕迹。

8月20日，有开发者在DeepSeek Harness源码中发现deepseek-v4-flash-vision-exp名称，以及与图片附件、本地文件和代码模式相关的配置。

但当时官方API端点尚未开放，调用图片请求会返回错误。

不过，V4-Flash-Vision-Exp目前仍带有“Exp”后缀，官方也明确将其定义为实验性模型。

材科源图三个月完成两轮融资，AI全链路闭环加速材料产业化

李冬梅 — Fri, 21 Aug 2026 11:31:11 GMT

近日，苏州材科源图科技有限公司（MatSource）宣布，近三个月内连续完成两轮超亿元天使轮系列融资。

其中，前一轮投资方包括苏高新、硅港资本、合肥原初陆号和上海远鼓，老股东亿合资本、清新资本追投；新一轮由经纬创投领投，苏创投及老股东中科创星、硅港资本继续跟投。

本轮资金将主要用于完善“数据—物理模型—智能体—自动化实验”研发链条，加速智能高通量实验平台的搭建与迭代；推动能源、催化等方向的材料进入中试和产业化阶段；同时引进AI与材料科学交叉领域人才。

公开信息显示，材科源图于2025年11月完成数千万元天使轮融资，由中科创星领投，元禾控股与亿合资本参与。

半年左右先后获得多轮融资，也反映出资本市场对AI for Materials的关注，正在从算法和科研平台转向实验闭环与产业交付。

AI预测之后，还要完成实验验证

AI进入材料研发并不是新概念。过去几年，机器学习已经被用于材料性质预测、候选配方筛选和分子结构设计。但材料研发与文本、图像生成存在明显区别：模型给出的结果只是一组候选方案，最终能否成立，还要经过合成、测试和反复验证。

这使AI材料研发面临一个现实问题：计算端可以快速筛选大量候选材料，实验端的合成、表征和验证速度却未必能够同步提升。如果两者没有形成闭环，模型预测就很难直接转化为可以使用的配方和工艺。

材科源图试图连接这两部分。其技术体系包括材料数据库、物理预测模型、材料智能体和高通量实验平台。公司披露，目前已积累百万级真实材料数据库，自研材料预测物理模型超过200个，并计划在年内将数据库扩充至千万级、物理模型增加至250个以上。

与主要依赖统计相关性的通用大模型不同，材科源图的专用AI 智能体基于真实实验数据与物理模型训练，属于垂直领域专家系统。其智能体目前覆盖固态电解质、氢能电催化、离子液体、光刻胶、热催化、分子筛、有机电合成和费托合成等方向。

从“筛选材料”走向“筛选—验证—迭代”

在高通量自动化实验层面，材科源图推出了全球首台AI Agent驱动的无机固相/固液相合成高通量自动化实验平台。该平台单日样品处理能力达150个，实现了“规划—设计—工艺—执行—反馈”全流程闭环。

这一闭环的意义在于，模型不再只输出预测结果，还能通过真实实验不断校正。材料研发中大量依靠研究人员经验完成的配方调整、参数组合和重复实验，也有机会转化为可以记录和复用的数据。

这套“数据—物理模型—智能体—自动化实验”的闭环研发体系，已经在产业项目中得到验证。以公司服务某世界500强企业的案例来看，这家企业的一个热催化反应催化剂转化效率低下，困扰了他们多年，期间曾外包给多个高校和头部材料研发公司均未解决。材科源图承接项目后，合同约定一年交付，实际不到两个月就找到了一系列性能更优的催化剂，其中最优者比企业原有材料性能高出30%，目前已通过小试、正在走中试和量产阶段。

探索三种商业化路径

在商业化方面，材科源图目前规划了技术服务、材料银行和自研材料生产三条路径。

技术服务主要面向企业的定制研发需求，通过项目开发、专利买断和 Token 计费等方式收费；“材料银行”则将研发过程中积累的材料配方、工艺和知识产权作为可持续复用的数字资产，通过授权及收益分成实现变现；自研材料生产进一步向下游延伸，通过自建或合资工厂推动材料量产。

公司当前重点布局绿色有机电合成和固态电解质等方向，部分项目已经进入中试阶段。与单纯销售软件或算法服务相比，这种模式试图覆盖从材料预测、实验验证到配方授权和产品生产的更长链条，但也意味着公司需要承担更重的实验设施、工程放大和产业运营投入。

AI for Materials 正在从技术验证向实际研发流程渗透。

对这一赛道而言，模型能筛选出多少候选材料只是起点，真正决定商业价值的，是候选方案能否通过实验验证，能否形成稳定工艺，并最终转化为客户可以采购的材料产品。

本地运行、支持视觉与工具调用：Meta 开源智能体模型

作者：Olimpiu Pop — Fri, 21 Aug 2026 09:00:00 GMT

Meta AI Research 宣布推出 Muse Glimmer"，这是一款拥有 300 亿参数的开放权重模型，采用 Apache 2.0 许可证发布。Muse Glimmer 专为始终在线的本地工作流而设计，使开发者无需依赖云 API，即可直接在消费级 GPU 和工作站上运行自主智能体、复杂工具调用、本地编码以及以 LLM 作为评判者的评估。

Muse Glimmer 30B 模型架构和智能体基准测试

为了在严格的内存预算下实现智能体执行能力，Meta 采用了源自其更大型旗舰模型 Muse Spark 的多阶段训练策略：

Logit 蒸馏（预训练）：该模型使用相匹配的预训练数据集组合，从 Muse Spark 迁移基础推理能力。中期训练：使用包含复杂推理轨迹、交错文本与图像数据以及多步工具调用轨迹的长上下文序列扩大训练规模。后训练对齐：结合监督微调（SFT）、同策略蒸馏和强化学习（RL），优化代码生成、工具使用和结构化规划等多个领域的性能。

一个专用的 18 亿参数感知编码器使 Muse Glimmer 能够原生处理交错的多模态输入，让本地智能体可以在执行代码或自动化工作流期间直接理解截图、图表和文档。

未经压缩的 300 亿参数模型通常需要超过 55 GB 的显存，因而无法在标准消费级硬件上使用。Muse Glimmer 通过两项主要的运行时优化解决了这一问题：

动态量化：利用 4 位动态压缩（K-Quant），模型占用空间降至约 17 GB 至 20 GB。这在标准的 24 GB 至 32 GB GPU/NPU 内存范围内留下了足够的内存余量，可供键值（KV）缓存、感知嵌入和推测解码开销使用。

DFlash 推测解码：Muse Glimmer 不再一次预测一个 token，而是与一个基于 DFlash 架构的轻量级配套“草稿”模型协同工作。草稿模型提出包含多个 token 的块，再由基础模型并行验证。在 Apple Silicon（M4/M5 Max）和 NVIDIA RTX 5090 显卡等硬件上，这种方式可将生成吞吐量提升至多 3.1 倍。Muse Glimmer 经过训练，能够执行长期规划并处理意外故障状态。当 API 调用或终端命令返回错误时，该模型会诊断故障并尝试其他路径，而不是终止执行。它支持 OpenClaw 等智能体框架，并提供可调节的推理强度，使开发者能够在执行速度和决策质量之间取得平衡。

在标准化基准评估（SWE-Bench、DeepSearch QA、τ-Bench 和 MCP-Atlas）中，与 300 亿参数级别的领先开放模型相比，Muse Glimmer 取得了较高的成功率。与 Gemma 4 31B 和 Qwen 3.6 27B 等同类模型相比，Muse Glimmer 展现出更出色的多步工具调用可靠性和故障恢复能力，同时在通用编码和推理能力方面保持了竞争力。

该模型的权重已在 Hugging Face 上提供。Meta 与开源社区合作，为 llama.cpp、ExecuTorch、Apple MLX、Ollama、LM Studio 和 vLLM 等流行的本地框架提供原生运行支持。它还通过 PyTorch 的 TorchTitan 框架支持微调工作流。

Muse Glimmer 标志着本地 AI 智能体朝着兼具可行性和高性能的方向迈出了重要一步，既能保护数据隐私，又能维持低延迟运行。若要在自己的机器上高效运行该模型，建议使用配备 24 GB 至 32 GB 统一内存或显存的系统，例如搭载 M4/M5 Max 芯片的 Mac，或配备 RTX 5090、RTX 4090 等现代 GPU 的 PC。这一硬件配置范围可以确保在加载量化后的 4 位权重之外，还能为长时间智能体会话所需的视觉编码器、DFlash 草稿模型和 KV 上下文缓存提供充足内存。

原文链接：https://www.infoq.com/news/2026/08/meta-muse-glimmer/"

视频生成迎来“Claude Code时刻”，MiniMax Design “杀入” Adobe、Canva 腹地

冬梅 — Fri, 21 Aug 2026 08:55:09 GMT

一笔 AI 视频生成的隐性账单

周一上午，一家消费品牌临时决定，为即将开始的促销活动追加一轮短视频投放。

需求听起来并不复杂：围绕同一款新品，面向不同年龄、消费场景和平台，制作一批风格接近真实用户分享的短视频。内容大致包括：有人在办公室使用产品，有人在家体验；有的突出价格，有的强调功能。整体要求语气不能太像硬广，画面还需适配多平台规格。

真正让内容团队头疼的是最后一句：“先做100条，下午看第一轮效果。”

按照过去的工作方式，要在当天完成这项工作几乎不可能。

团队需要先把一句商业需求拆成若干脚本，再逐条设计分镜，准备人物、商品和场景素材，随后进入拍摄或生成、剪辑、配音、字幕和包装环节。

即使已经使用了AI工具，创作者仍要在多个工具之间来回切换：一个工具生成图片，一个工具让图片动起来，再用其他软件处理配音、字幕和剪辑。每多做一个版本，都意味着重新组合一遍素材和流程。

问题在于，这种“做100条视频，下午就要”的需求，正在从临时任务变成商业内容团队的日常。

这不是个别团队的焦虑，2025年，Adobe 调研显示，超过 60% 的营销人员认为内容需求已经增长至原来的 5 倍或以上，且预计这种压力还会继续增加。

图片来源：Adobe 官网

WPP Media发布的《2026年年中全球广告预测》显示，预计2026年全球广告收入达到 1.3 万亿美元，同比增长8.9%，高于2025年12月预测的7.1%。

数字广告占比越高，意味着品牌对短、快、多版本素材的需求也越强。

视频需求增长与 AI 生成能力的普及，正在同时把内容团队推向一个新的瓶颈。

这个瓶颈就是：生成10个、100个版本的视频越来越容易，但判断哪个能用、保持哪些元素一致、修改哪一版，以及如何送审和交付，并不会自动变得简单。

同一款产品需要覆盖抖音、快手、小红书、电商平台和海外社交媒体，还要适配不同人群、场景、语言、尺寸和传播语境。广告投放还要不断测试不同的开场、人物、卖点和表达方式，根据点击率、完播率和转化效果快速更换素材。

当生成成本下降之后，人的时间开始消耗在筛选、校对、修改和版本管理上。这笔隐性账单，成为全行业必须正视的“后生成时代”核心命题。

那么，这笔隐性账单应该怎么消化？

其实现在市场上并不缺生成工具。图像、视频、配音、数字人、字幕、翻译、剪辑和尺寸适配等环节，都已经出现大量 AI 产品或功能。

但问题是，单纯地把这些 AI 生成工具叠加起来，只会让团队拥有更多彼此割裂的能力。

一个工具写脚本，一个工具生成图片，一个工具制作视频，再由人把素材导入剪辑软件，补充口播、字幕和包装。

生成环节越来越快，需求拆解、分镜制作、资产整理、版本筛选和最终交付仍然需要人工完成，一套能承接完整商业任务的视频生产工具平台，才是付费的企业级用户真正需要的。

商业视频生成的“最终一公里”

那么，能够直接承接商业视频生成任务的平台，都有哪些玩家？

市场上已经出现了一些相对成熟的解决方案。

Adobe正从专业创作软件向AI工作流延伸，Canva则从模板化设计进一步走向Agent。两者都在尝试把生成能力嵌入现有设计和内容生产体系。

但 MiniMax design 走出了一条差异化的路线：MiniMax Design 从原生多模态模型出发，重新组织商业视频的生产流程。

这一区别直接影响产品的工作方式。

传统创作软件通常以画布、时间线和素材为起点，用户需要明确自己要调用哪些功能。MiniMax Design 以需求为起点，用户只需要描述产品、受众、平台、卖点和内容风格，系统便可继续完成创意拆解、脚本、分镜、素材生成、配音、字幕和成片。

既然大家都开始做视频生成 Agent，谁的 Agent 更接近商业视频生产本身，谁就能掌握更多主动权。

然而，当越来越多产品开始提供视频生成 Agent，竞争关键也随之变化：谁更理解商业需求，谁能减少人工拆解和跨工具拼接，谁能稳定批量交付可用素材，谁就更接近真正的商业视频生产。

MiniMax Design凭什么认为自己更接近这一目标？答案最终还要落到真实的生成结果上。

产品上线后，很快在国内外创作者社区引发一轮集中体验，海外用户的创作热情尤其明显，不少创作者开始尝试用它制作动画、影视预告和视觉包装，并在社交平台上分享生成过程与使用感受。

在x 平台，一位 ID 名为 Ai Bella 的用户使用 MiniMax Design 完成了一支僵尸题材的悬疑预告片。

他表示，自己想测试 AI 能在多大程度上展开一个完整的电影概念，于是将一则僵尸电影创意交给 MiniMax Design 处理。从故事梗概、电影场景和整体氛围，到视觉特效、字体设计及结尾转折，整支预告片都在Agent驱动的工作流中逐步完成。

在他看来，这次体验与过去生成一组彼此割裂的视频片段有所不同。不同镜头和视觉元素开始围绕同一个故事目标被组织起来，整个过程“更像是在真正执导一部短片”。

以前可能制作一条这样的内容，要先确定人物、场景和脚本，再准备参考素材和文案，随后完成拍摄或生成、剪辑等工作。而使用 MiniMax Design，用户可以直接口述需求，甚至一句话的提示词就能得到下列类似的视频。

同样在 x 平台，一位日本视频创作者 SEIIIRU 在体验 MiniMax H3 和 MiniMax Design 后，将其形容为一个可能让从业者产生职业危机感的案例。

他用 Design 制作了一条汽水广告视频，随后写道：“这就是那种让人觉得AI真的要来抢我们工作了的情况吧。”

但他紧接着给出了另一个判断：站在视频行业从业者的角度，面对这类工具，也已经很难选择完全不用。

另一名创作者则尝试用 MiniMax Design 中的 H3 探索不同动画风格。

他表示，自己只需要给出大致方向，Agent 便会进一步把想法拆解成可以实际执行的工作流，再逐步生成相应的视频。这种创作方式让 AI 视频变得更有趣：创作者无需一开始就确定所有制作细节，可以在生成过程中不断尝试不同风格，并根据结果继续调整方向。

还有位 x ID 名为Bhavy 的用户，用 Design 进行了对象替换，该用户表示，自己给 Design 一个参考视频和 3 张图片，让它交换舞者。结果它在不到 1 分钟的时间内生成了这段视频，并且始终保持每张脸和光照的一致性。

他不禁感慨，“这简直太疯狂了 ”。

还有用户表示，自己试过后完全迷上了 MiniMax Design，只需要一个提示，然后等待一会儿，就能获得完整的复古日式旅行海报风格视频。

从这些用户分享的视频中可见，MiniMax Design 整体对电影类型、视觉风格和氛围的理解较好。在提示词足够具体、故事和镜头规划清晰的情况下，可以生成电影感较强、画面质量较高的片头或预告片样片。

值得一提的是，这些案例之外，MiniMax H3 也开始进入更成熟的创作平台。

剪映国际版 CapCut 平台已经接入 MiniMax H3，用户可以直接在 CapCut App、Web 和桌面端试用。

差异性怎么体现？

从以上实测案例可以看到，MiniMax Design 的优势不只体现在单条视频的生成效果上。它在需求理解、专业效果调用、复杂任务执行和商业成片交付等环节，都呈现出与其他视频 Agent 不同的产品逻辑。

而要做到这些，背后离不开 MiniMax Design 的几个差异化特征：

第一，不是给旧软件加一个Agent，是围绕Agent重新设计生产界面。

Adobe 的优势来自 Photoshop、Premiere、Illustrator、AEM 和 Workfront 等成熟软件体系，Canva 的基础则是模板、画布与协作生态。

两家公司正在把 Agent 逐步嵌入原有产品：Adobe 将 Creative Agent 带入 Firefly、Photoshop 和 Premiere，Canva AI 也开始通过对话生成和修改设计。

MiniMax Design 与他们最大的不同，是直接以 Agent 作为创作入口。用户描述想法或上传brief 后，主 Agent 理解目标、拆解任务并匹配模型，文案、图像、视频和音频等 Agent 随后协同完成任务。

其工作流程可以概括为：

理解创作目标 → 智能拆解任务 → 多Agent协同处理 → 合并、编辑和导出

Adobe 把 Agent 带进了软件，MiniMax Design 则以 Agent 为入口，将软件能力纳入从需求到交付的完整链条中。

第二、它更集中地面向“视频原生”的多模态生产。

MiniMax Design 将脚本、分镜、图像、视频、配音、音乐和编辑放在同一张 Canvas 上，不同节点自动连接，从前期调研、脚本策划一直走到最终剪辑，减少在多个工具之间反复上传素材和重建上下文。

这些能力最终围绕视频成片组织。用户只需描述产品、受众、渠道、卖点和内容风格，系统继续完成脚本、分镜、画面、声音与剪辑。适配的重点场景包括短剧、电商内容、品牌TVC和广告素材，产品重心比通用设计平台更集中于商业短视频生产。

第三、把“成功的方法”封装成Skill，比每次重写Prompt更适合批量生产。

MiniMax Design 另一个值得重点关注的能力，是自定义 Skill 和插件。

用户可以通过对话创建自己的 Skill，也可以直接调用 Skill Plaza 中已经沉淀的工作流。适配范围覆盖短剧、分镜、商业广告、电商、音频和音乐等内容，并可以借助专业插件处理电影特效和其他复杂制作任务。

为什么这很重要？

这样从Skill 与普通 Prompt 的差别说起。

Skill 与普通 Prompt 的差别，在于它保存的内容不只是一段自然语言指令。一项完整的生产方法，往往还包括任务拆解顺序、节点关系、模型选择、参考素材、参数约束和质量检查。

例如，制作一条KOC种草视频，需要确定目标人群和使用场景，提炼产品卖点，生成口语化脚本，再依次处理人物、口播、产品露出、字幕和包装。一次效果较好的成片背后，真正有价值的是这套流程，而非某一个偶然生成成功的镜头。

批量生产真正需要复制的，不是上一条视频，是生产上一条视频的方法。这也是 Skill 机制最擅长做的事。

Skill 可以把一次成功的提示词、节点组合和检查流程沉淀下来，成为下一项任务可以直接调用的生产能力。面对新的商品或课程，用户只需要替换产品信息、受众和交付要求，就能沿用已经验证过的结构。

比如生产100条视频时，团队不必从头编写100次Prompt，也不必依靠某位操作人员记住全部制作步骤。

此外，商业客户还需要在多人协作、跨项目复用和人员变化的情况下保持结果一致。Skill 把个人经验转化为可保存、可调用的流程资产，使内容团队有机会建立自己的广告 Skill、电商 Skill、动态讲题 Skill 或影视包装 Skill。AI 由此从一次性的灵感工具，进一步接近日常生产系统。

第四、开放适配，免迁移。

创作团队已经积累了大量本地素材、专业软件工程文件和内部工作流，采用AI并不意味着这些资产可以全部推倒重来。

MiniMax Design 设置了本地资产中心，Canvas 素材可以保存在本地，Agent 能够调用本地文件，并将生成结果导向专业工具，这样团队就不必放弃已有素材和生产流程。

底层的 MiniMax H3 进一步提供了开放权重、API 和 ComfyUI 接入方式。

MiniMax H3 项目地址：https://github.com/MiniMax-AI/MiniMax-H3"

图片来源：MiniMax 官网

H3 能够统一理解文本、图像、视频和音频输入，生成带同步立体声音频的视频；API 支持 768P 和 2K 输出，时长为 4 至 15 秒。

这种开放适配带来两个直接好处。

首先，模型与产品之间的反馈链路更短。商业生产中暴露的人物一致性、商品还原、声音同步和参考素材理解等问题，可以更快进入底层模型的迭代。

其次，企业可以根据自身需求选择接入方式。普通创作者可以直接使用 MiniMax Design，专业团队可以连接本地素材和外部工具，拥有开发能力的企业则可以通过H3 API、开放权重和ComfyUI，将模型接入原有生产流程，无需彻底迁移既有资产和工作流。

模型公司开始吞噬软件层

把前面四点放在一起看，MiniMax Design的产品逻辑会更清楚：以Agent作为创作入口，用Canvas组织视频生产，通过Skill复用成功流程，再以开放模型和工具适配原有工作流。

这几项能力共同指向一件事：MiniMax 想做不仅是一款视频生成工具，而是一套围绕模型重新建立的创作软件。

在其他同类产品上，模型作为一项能力被放进软件。例如 Photoshop 增加生成式填充，剪辑软件加入自动字幕，设计平台接入文生图。模型负责生成某段内容，软件继续承担任务拆解、素材管理、编辑修改和流程组织。

但用户依然要打开不同工具，在菜单、时间线和文件夹之间完成剩余工作。

而 Agent 和 Harnes 出现后，打破了这种分工。

模型获得工具调用、文件读写、任务规划和结果检查能力后，开始接手软件原本负责组织的工作。用户不再需要逐项指定使用哪个功能，而是直接说明想要的结果，Agent 再决定如何拆解任务、调用工具，并根据执行结果继续修改。

Claude Code 已经在软件开发领域证明了这条路线。

Claude 过去也会写代码，但真正让它进入开发流程的，是读取项目、修改文件、运行命令和检查结果的能力。模型由此从回答编程问题的助手，变成开发环境里的执行者。

Anthropic 分析了50万次 Claude Code 和 Claude.ai 交互，发现 Claude Code 中 79% 的对话包含某种形式的自动化，高于 Claude.ai 的49%。改变开发方式的关键，是它能否借助Harness把任务持续做完。

图片来源：Anthropic 官网

Harness正在成为AI时代的新软件层。过去软件通过固定界面规定用户怎么工作，Harness则根据用户目标，临时组织模型、工具和流程。

MiniMax Design 正在把类似的逻辑带进视频生产。

当然，这不是传统软件单方面被模型公司“进攻”，倒可以说是一场双向迁移。

MiniMax Design 和 Adobe、Canva正在从相反方向抵达同一个战场。

Adobe 已经推出Firefly AI Assistant，用户可以用自然语言描述目标，由 Agent 跨 Firefly、Photoshop、Premiere、Illustrator等应用执行多步骤工作流，Canva AI 2.0同样强调意图理解、Agent 编排、品牌记忆和跨渠道内容生成，并可以定时批量生产社交内容。

如果 Agent 只是一项边缘功能，Adobe 和 Canva 不必同时向 Agent 转型。传统软件公司把模型装进软件，模型公司则开始从模型中长出软件，把这种双向渗透放在一起来看，释放了一个信号——双方最终抵达的是同一个战场。

那么下一步竞争的重点，是谁能理解 brief、拆解脚本和分镜，组织人物、商品与品牌资产，调度图像、视频、声音和剪辑能力，并完成修改、检查与交付。

MiniMax Design 正是在这一层向上生长，所以它的想象空间也不只属于视频Agent市场。

它想重新定义的，是 Adobe、Canva 背后整套商业内容生产逻辑。

视频生成只是入口，真正可能被改写的，是商业内容的生产方式。

参考链接：

https://platform.minimax.io/docs/guides/video-generation"https://business.adobe.com/resources/reports/content-management-digital-trends.html"https://www.anthropic.com/research/impact-software-development"

不跟风、不堆模型，百度靠什么突围AI办公赛道？

褚杏娟 — Fri, 21 Aug 2026 08:47:55 GMT

近期，百度文库网盘官宣旗下通用智能体GenFlow正式启用中文品牌名“库库AI”，同时「库库AI」上线独立客户端、小程序、Web三端产品。这意味着此前内嵌于百度文库、网盘体系的AI办公能力，还将上线独立产品，入局当下竞争日趋激烈的AI办公赛道。

相较于多数后发入局的办公AI产品，百度文库、网盘早在三年前便布局通用AI办公领域。库库AI前身GenFlow于去年4月推出1.0版本，经过一年持续迭代，已更新至4.0版本，逐步完成产品能力的打磨与升级。此次定名“库库AI”，也是长期用户使用习惯的沉淀。

官方表示，独立三端产品的落地，是产品能力、团队产能与行业环境多重条件成熟后的择机布局，并非跟风市场热度。

早期阶段，产品智能体调度、多场景协同等核心能力还在迭代，因此并未急于推出独立端口。直至2025年，多重条件齐备，才迎来独立上线的合适节点。

产品层面，GenFlow4.0完成通用智能体整体重构升级，整合优化Office全链路办公、多媒体素材处理、资料解析、智能体调度等核心能力，可独立支撑全流程办公任务闭环；团队层面，依托AI原生研发模式，仅20余人的研发团队，在一个月内完成Web、小程序、客户端三端同步开发，实现高效迭代；行业层面，AI办公已从概念普及阶段走向规模化落地阶段，个人与企业用户对场景化、任务式AI办公工具的实际需求持续释放，落地型AI产品的市场接受度大幅提升。

如今，库库AI的独立亮相，便成为百度深耕AI生产力办公赛道多年后，顺势完成的一次产品形态升级。

底层架构优化解决通用体验痛点

当前市面多数AI办公产品普遍存在体验短板，集中体现为设备切换任务中断、长期对话上下文冗余卡顿、记忆内容混乱、跨智能体能力无法复用等问题。库库AI的产品差异化，主要来源于底层架构设计带来的针对性体验优化。

据百度文库网盘介绍，库库AI自2023年启动底层重构后，采用可插拔MoE混合架构，实现模型调用、数据处理、交互服务的分层解耦。基于该架构，产品的任务进度、用户记忆、办公资产不会绑定单一设备，可在电脑、手机、小程序多端实时同步流转，实现连续化办公体验，有效解决多数AI产品脱机任务中断、设备切换进度丢失的行业痛点。

针对长期对话卡顿、记忆混乱的核心问题，库库AI搭载独立分层记忆系统，实现记忆体系与聊天对话记录完全解耦。行业多数产品会将全部对话内容灌入上下文窗口，长期使用后冗余信息不断堆积，进而引发卡顿、调用效率下降等问题。而库库AI会对原始对话数据进行二次筛选处理，区分短期临时交互信息与长期有效办公记忆，精准留存用户办公习惯、专业经验、使用偏好，自动清理无效冗余内容。

经过分层筛选沉淀的长期记忆，可跨Skill、跨智能体、跨使用场景全域复用，持续积累对用户的认知，同时规避上下文臃肿带来的各类体验问题，实现产品长期使用体验的稳步优化。

另外，AI办公产品的上下文数据处理，长期存在核心技术矛盾：既要保障全量数据完整留存、信息高度保真，又要兼顾数据处理精准度与运行效率，两项指标往往相互制衡。

库库AI深度依托百度网盘、文库长期沉淀的底层技术基建，承接了前AI时代打磨成熟的技术体系，整合网盘知识架构与文库知识图谱核心能力，为产品数据处理提供扎实的技术支撑。

百度网盘承载千亿GB级海量数据，长期处理海量用户的资料检索、预览、读写调取等高频操作，积累了成熟的高并发、大规模、复杂化数据处理经验。基于多年实战打磨，平台已形成完善的数据优化体系，涵盖数据库调用优化、上下文压缩策略、场景化精准数据召回、数据精度动态调控等多项核心能力。

相较于全新研发的AI办公系统，库库AI依托成熟的存量技术基建，在海量数据并发处理、效率与精度平衡上具备天然优势，核心数据处理能力经过长期实战验证，整体稳定性和实用性更为突出。

C端模式成熟，B端依托存量资源稳步渗透

近期AI行业价格波动频繁，各类模型、AI应用涨价、降价交替出现，

库库AI背后的成本控制逻辑是：一方面，产品不会对所有任务统一调用高规格大模型，而是根据任务复杂程度拆解需求，匹配适配的模型能力，避免算力资源浪费；另一方面，依托自研编辑器、Office专属智能体，通过人机协同的办公模式优化推理逻辑，有效降低大模型推理消耗，以此实现长期成本可控、定价稳定。

库库AI自功能上线之初，便配套完善的商业模式，始终遵循“价值落地优先、流量变现后置”的稳健思路，实现C端、B端双线有序推进。

C端层面，依托百度文库、网盘多年沉淀的成熟付费体系，库库AI的智能化办公能力实现无缝衔接升级，已形成完整的付费层级、权益体系与用户复购闭环，属于成熟存量业务的智能化延伸，商业模式已完全跑通。

B端商业化布局始于2024年，团队将GenFlow通用智能体底座迁移至企业网盘体系，完成传统企业存储产品的智能化升级。

中小企业是库库AI重点覆盖群体。行业传统认知中，大客户客单价更高，中小企业普遍存在经营不稳定、定制服务成本高的问题。但在AI原生产品模式下，这一现状发生改变。

百度文库网盘分析，传统SaaS模式服务中小企业，需要针对不同行业做大量定制化开发，人力成本居高不下。而库库AI依托AI原生架构，仅通过调整Skill配置、优化前端交互范式，即可适配多数行业需求，大幅降低定制服务成本。同时，网盘存储属性带来极强的数据用户黏性，只要中小企业经营状态稳定，产品付费率、续费率均能保持稳定，具备长期复利价值，部分大客户项目反而存在服务成本高、毛利承压的问题。后续产品将配套FDE服务模式，进一步深入行业场景，打通产品能力与企业真实业务的衔接壁垒。

库库AI首个重点落地的垂直场景为金融投研。团队选择该场景的核心原因，是金融行业具备时效性强、数据维度繁杂、决策严谨度高、内容精准度要求严苛的特点，能够精准检验AI办公产品的专业化落地能力。

据百度文库网盘相关负责人透露，其个人已依托库库AI搭建轻量化投研体系，可实现全天候盯盘、自动复盘、个股动态跟踪，将碎片化的投资研究工作，转化为标准化、系统化的复盘流程，提升投研效率。

在国内产品持续迭代的同时，百度办公AI全球化布局同步推进，海外对应产品OREATE AI已覆盖全球220多个国家和地区。海内外产品共享统一底层技术架构，能力迭代基本同步，不存在明显技术时差。

海内外用户需求明显不同。国内办公场景更侧重团队协同与本土生态适配，而海外市场中，自由职业者、个人创作者、小型单人公司的用户增速更快、需求更旺盛。海外用户的核心诉求：一是深度本地化交付，不止基础语言翻译，还需适配当地审美风格、内容表达逻辑与行业办公习惯；二是高度重视内容专业度与可信度，对交付内容的时效性、准确度要求更高；三是对数据隐私保护、合规安全的标准更为严苛。

百度文库网盘自2025年GenFlow迭代初期，便同步启动海外业务布局。海内外产品共用存储底层、自研编辑器、通用智能体核心框架，海外业务仅需基于统一架构做本地化适配。同时，全球各地区用户的真实办公需求与使用反馈，会反向回流至产品迭代体系，持续优化产品通用能力与本地化适配能力。

AI办公的长期竞争：沉淀与协同能力成核心壁垒

百度文库网盘团队分析认为，本轮AI办公赛道的集中爆发，核心驱动力来自大模型Coding能力的大幅提升。

早期大模型仅擅长简短问答对话，面对完整、复杂的办公交付任务，需要配套大量工程化开发，落地难度高、投入成本大，属于行业“苦活累活”，早期入局玩家较少。随着模型Coding能力迭代升级，AI办公产品研发门槛大幅下降，模型基础输出质量可满足大部分常规办公需求，叠加大众AI使用习惯普及、企业数字化降本需求释放，AI办公赛道正式进入爆发期。

整体来看，当前行业仍处于发展早期，但未来整体市场空间广阔。

库库AI团队判断，未来，通用型办公AI平台与垂直行业办公产品将长期共存，不存在单一品类通吃市场的情况。赛道整体体量充足，无论是横向覆盖全场景的通用办公能力，还是纵向深耕细分行业的垂直能力，只要能切实解决用户真实办公痛点，均可形成稳定市场价值。同时，垂直场景拓展虽会产生一定适配成本，但行业场景沉淀的高质量专属数据，可反向训练优化模型能力，场景深耕与模型迭代形成正向循环，并非单向成本消耗。

针对当前AI办公赛道内卷加剧的情况，百度团队的判断是：赛道短期竞争比拼底层模型能力，长期竞争的核心则是数据沉淀与人机协同进化能力。预计2027年前后，全网公开的通用存量知识将基本完成模型训练，行业各家基础大模型的通用能力将逐步趋于同质化，单纯依靠模型参数带来的竞争优势将持续弱化。未来AI办公产品的核心竞争力，将集中在三大维度：通用智能体调度能力、垂直专业知识库积累、全域记忆与数据存储沉淀能力。

当模型完成通用存量知识的学习后，后续能力迭代将高度依赖用户持续产出的新知识、新经验、新工作方法。能否持续沉淀用户个性化数据、办公习惯与专业经验，能否为用户提供持续、定制化、连续性的智能办公服务，将成为产品核心差异化优势，同时直接决定用户的产品迁移成本。

针对行业“强模型将吞噬工具、Skill生态将失效”的争议，团队表示二者为协同赋能关系，不存在相互替代的可能。模型能力升级能够优化工具、行业Skill的落地效果，而持续迭代的行业Skill、场景化工具，能够为模型提供全新的场景训练样本，推动模型持续进化。

对于后续发展，库库AI的产品迭代方向清晰，主要围绕场景扩容、生态开放、技术优化三大维度稳步推进。

场景层面，在现有金融投研垂类场景的基础上，2026年9月将批量上线多行业专属Skill工具与专业知识库，从单一垂直场景逐步延伸至多行业专业办公领域，覆盖更多细分岗位、细分行业的办公需求。

生态层面，库库AI或将采取渐进式开放策略，后续将逐步开放API、CLI等接入能力，支持用户自定义接入第三方工具、外部模型与专属数据源，满足个性化、定制化的办公需求。同时产品会基于海量用户使用数据，持续优化智能体调用逻辑与响应速度，迭代提升整体使用体验。

技术层面，团队将持续攻坚长上下文处理、数据精准度优化、企业级权限隔离三大核心技术方向。依托百度多年积累的海量数据处理、知识图谱搭建、高并发调度工程化能力，在多人协同办公、超长对话交互、复杂任务处理等场景中，平衡信息完整性、处理效率与数据安全性，在合规可控的前提下，持续释放AI办公生产力。

Vercel Zero 引发争议：AI 时代真的需要一门新语言吗？

作者：Daniel Dominguez — Fri, 21 Aug 2026 06:25:00 GMT

Vercel 已正式推出 v0 API"，让开发者能够以编程方式访问其 AI 应用构建智能体。开发者可以通过 API 发送提示词，让 v0 生成和修改应用程序文件，在 Vercel Sandbox" 中运行生成的应用程序，并获得一个可以嵌入自有界面的预览 URL。

该 API 以聊天为单位组织每个应用程序，聊天会维护应用程序的当前状态。开发者可以使用同一个聊天 ID 发送后续消息，让 v0" 继续编辑现有应用程序。该 API 支持同步、异步和流式请求，流式响应会公开智能体的各项操作，例如读取文件、编辑、搜索、执行 Bash 命令和调用工具。

开发者还可以基于现有 GitHub 仓库、ZIP 压缩包或文件集合创建应用程序。应用程序准备就绪后，开发者可以关联一个 Vercel 项目，并通过 API 进行部署。预览环境使用短期令牌，并且可以通过服务器端代理访问，从而避免在浏览器中暴露 v0 API" 密钥。

该 API 还支持外部工具和设计系统。开发者可以连接 MCP 服务器"，或者从团队或用户记忆、skills.sh"或已连接的仓库中加载技能。每个请求最多可以传入三项技能。Vercel 还提供了相关集成，可以通过 MCP、AI SDK" 或 Vercel 的 eve 框架，将 v0 作为工具用于其他 AI 智能体。

这使 v0 与 Lovable" 和 Bolt" 等应用构建工具形成了不同的定位，后两者主要提供用于生成应用程序的交互式环境。相比之下，v0 API" 将应用构建智能体作为基础设施开放，开发者可以从自己的产品、脚本、CI 流水线或其他智能体中调用它。Vercel 的方案还将生成的应用程序直接与其 Sandbox 和部署 API 集成。

社区的讨论主要集中在该 API 对全程可编程应用开发的支持潜力上。AI 领域影响力人士 ZenithAI" 如此评价此次发布：

这是迈向全程可编程应用开发工作流的重要一步。

Vercel 开发者 @EstebanSuarez" 强调了预期的智能体工作流。他解释说，智能体可以将提示词和设计系统发送给 v0 API，获得 Vercel Sandbox 中的实时预览，对应用程序进行迭代，并在准备就绪后进行部署。他写道：

你的智能体需要一个应用程序。它将提示词连同你的设计系统一起发送给 v0 API，随后会收到一个预览 URL：应用程序已在 Vercel Sandbox 中实时运行。你的智能体会对它进行迭代。准备就绪后，它会进行部署。这就是新的 v0 API。

新的 API 可以通过 v0 SDK 使用，其中 v2 API 的地址为 https://api.v0.dev/v2。开发者可以创建" API 密钥、安装 SDK，并构建能够发送提示词、流式传输智能体活动、渲染预览和部署生成应用程序的界面。

原文链接：https://www.infoq.com/news/2026/08/vercel-v0-api/"

初级岗位消失、高级人才断层：下一代高级工程师从哪里来？

作者：Ben Linders — Fri, 21 Aug 2026 04:00:00 GMT

Alasdair Allan 在 QCon London" 的演讲《当 AI 吞噬中间层：缺失台阶的工程师成长路径》"中解释说，AI 正在消除职业阶梯每一级上的学习机会，从而扰乱职业发展，同时又让人们能够完成超出自身经验水平的工作。进入行业的初级开发者越来越少，AI 也减缓了入门级岗位的招聘。

Allan 表示，AI 正在编写大量代码，开发者这一职业的内涵已经发生了巨大变化。但他补充说，编写代码从来都不是这个职业的核心目的。

使用 AI 需要监督，而监督需要编程技能。Allan 对此提出疑问：如果 AI 接手了过去用于培养工程师的工作，那么下一代工程师将从何而来？他表示，如果初级工程师的技能发展因使用 AI 而受到阻碍，那么 AI 带来的生产力收益可能会以损害验证 AI 所写代码所需的技能为代价。

Allan 表示，资深程序员所具备的模式识别能力，包括系统应该如何构建、复杂性隐藏在哪里，以及系统在规模扩大后会在哪里出问题，如今已经无法再通过传统方式获得。初级工程师没有建立起判断眼前代码正确与否所需的直觉：

初级工程师不会再花费数年时间阅读遗留代码库，或在凌晨 3 点调试生产事故。他们只会让 AI 智能体处理这些内容，并要求它进行总结。

Allan 表示，大多数工程工作都属于人们所说的“黑地（blackfield）”：处于高负载下的遗留系统，所有人都同意应该逐步弃用，却没有人有时间真正执行。规范可能从未编写过，也可能曾经编写过，却因为数十年没有记录的决策而失去意义。业务规则被编码在各种条件中，而理解这些规则的人早已离开。

Allan 表示，AI 智能体可以阅读代码、测试文档，但它们无法读取生产环境。它们无法查看多年的请求模式，并理解哪些代码路径以代码本身无法揭示的方式承担着关键负载。

Allan 提到，在受 AI 影响较大的职业中，年轻员工的招聘速度已经放缓。25 岁以上员工的工作量并未减少。他解释说，这意味着进入行业的初级开发者越来越少：

人们并不是遭到解雇；他们从一开始就没有被雇用。AI 阻碍技能形成，AI 将工作转变为监督，而现在，AI 又减缓了入门级岗位的招聘。

Allan 认为，各组织在争相采用 AI 编程工具的同时，也在削弱培养能够监督这些工具的人才通道。能够为 AI 构建良好上下文的人，是那些通过多年实践在头脑中积累了上下文的人。曾经培养出这些人才的通道正在断裂。

Allan 表示，就像住院医师培训一样，人们之所以要做那些枯燥的杂活，是因为这些工作能够让人学习，而不是因为这样做效率更高。他最后总结说，坚持这样做的公司，才会在十年后仍然拥有高级开发者，因为到那时，我们其余的人都已经退休了。

演讲结束后，InfoQ 采访了 Alasdair Allan"。

InfoQ：关于 AI 对开发时间和生成代码质量的影响，相关研究得出了哪些结论？

Alasdair Allan：研究结果的矛盾程度，比任何一方愿意承认的都要高。METR 的随机对照试验发现，经验丰富的开发者在使用 AI 后速度降低了 19%，但他们却认为自己的速度提高了 20%。Anthropic 发现，使用 AI 的初级工程师在知识掌握方面的得分降低了 17%，完成任务的速度却没有任何提高。他们牺牲了学习，却什么也没换来。AI 对于简短、定义明确的任务确实有用，但随着复杂性增加，收益会迅速消失，瓶颈也会向上游转移至代码审查环节，而这恰恰是高级工程师判断力发挥作用的地方。在真实的开源项目中，AI 生成的 15 个 PR 没有一个可以合并，尽管它们都通过了自动化测试。AI 可以实现功能，却无法胜任工程技艺。

InfoQ：程序员使用 AI 工具后，其工作会发生怎样的变化？

Allan：编程正在转变为监督工作。Anthropic 的工程师在 59% 的日常工作中使用 Claude，但只能完全委托约 20% 的工作。两者之间的差距，也就是生成与判断之间的空间，将是未来工作岗位存在的地方。AI 编写代码；人类判断它是否是正确的代码。令我担忧的是，现在 80% 到 90% 的工程问题都会被提交给 AI，而不是同事。当 AI 直接给出答案，却省略整个探索过程时，与导师一起艰难解决问题所带来的偶发学习机会就被绕过了。过去的职业发展通道是为编写代码的人建立的。我们尚未为监督系统的人重新构建这条通道。

InfoQ：对于在 AI 时代培养工程师，你有哪些建议？

Allan：我没有完整的答案。我们目前处于诊断阶段，而不是解决方案阶段。但我们现在就可以采取行动：建立结构化的学习路径，有意识地安排基础工作轮岗，就像住院医师培训一样，因为这些枯燥的杂活能够培养判断力。我们需要衡量理解程度，而不是速度。观察人们如何思考，而不是他们产出了什么。将上下文视为基础设施，编写这样的文档：它应该像是为一名懂得编程、却不了解该代码库的高级工程师准备的入职材料。我们需要设定诚实的预期。AI 是工具，不是老师。利用它跳过理解过程，就是在透支自己的未来。

原文链接：https://www.infoq.com/news/2026/08/AI-disrupts-engineering-progress/"

“Anthropic不再是AI圈的信仰”

褚杏娟 — Fri, 21 Aug 2026 03:04:26 GMT

“Anthropic 堪称AI界的‘苹果’，尽管价格最高，却攫取了最多的收入。”有人这么评价Anthropic 。但另一方面，用户的体感是：“做Anthropic的用户，就像身处一段有毒的关系中。体验时好时坏，但日子久了，攒下来的只有满心怨气。”

今年4月份时，开发者的使用需求和注意力已经开始向Codex重新分配。当时，受到Claude Code使用限制影响的开发者，遇到了功能出现跃升式提升的Codex。同时，Codex还通过扩大免费使用范围和提高速率上限，降低了使用门槛。

如今，“Codex 与 ClaudeCode 之间的差距正越来越大。”有开发者现身说法：

我的业务工作配有Codex订阅，日常本职工作则使用Claude账号，所以我一直高频使用两者，使用时间大致各占一半。Codex基本上会直接按照我的要求执行。它有时有点太容易被引导，不会像我期待的那样提出足够多的质疑。不过，它能够理解问题、展开调查、制定计划并解决问题。Claude Code却越来越差。它身上的“AI腔”已经到了近乎语无伦次的程度，我经常很难理解它生成的句子。它还会说类似“你提出质疑是对的，我刚才完全没有抓住重点”这样的话。这种典型的AI式表达，大多数模型早在一年前就已经很少出现了。很长一段时间里，两者一直互有胜负，领先者来回更替，而且差距通常很小。但目前，两者之间的差距已经相当明显。

个人开发者的用脚投票，直接体现在了两个公司的的营收变化上。

增长明显向Codex倾斜

据市场研究机构 TickerTrends 最新追踪估算，截至8月10日，Anthropic旗下Claude Code的年化经常性收入（ARR）达到151.2亿美元，继续领先于OpenAI Codex的88.3亿美元。两者相差63亿美元，Claude Code约为Codex的1.71倍。

尽管Claude Code仍占据规模优势，但近期增长动能明显向Codex倾斜。7月6日至8月10日期间，Claude Code追踪ARR由142.6亿美元增至151.2亿美元，增幅约6%；同期，Codex则从58.8亿美元增至88.3亿美元，增幅超过50%。

以四周前的数据为基准，Codex最新月环比增长率为20.8%，显著高于Claude Code的5.2%。受此影响，两款产品之间的ARR差距从7月6日的83.8亿美元缩小至8月10日的63亿美元，降幅约24.8%。

从较长趋势看，以Anthropic 2月12日披露的Claude Code 25亿美元ARR为基准，此后3月底增至约63亿美元，4月底达到103亿美元，并于6月突破140亿美元。Codex的追踪ARR则从2月初的约10亿美元，增长至4月的30亿美元、6月的56亿美元和8月的88.3亿美元。从起始基数计算，Codex增长约8.8倍，快于Claude Code同期约6倍的增幅。

TickerTrends估计，Claude Code目前约占Anthropic总追踪ARR的21.9%；在其基准分配情景下，Codex约占OpenAI企业业务ARR的45%。

这次报告的收入变化，引起了很多人的关注。

“我始终认为，受中国大模型冲击、行业价格战，以及靠堆 token 拉高营收的模式走到尽头等因素影响，Anthropic营收增速会逐步趋平。从数据来看（当然这只是初步结论，样本量确实有限），我的判断大概率是对的，营收增长放缓的拐点或许已经出现。当然，长期来看，利润才是真正的核心指标。”Gary Marcus 评价道。

高ARR，但营收可能并不那么健康

据Sacra数据显示，企业端使用占 Claude Code 总营收的一半以上，客户包括 Netflix、Spotify、KPMG、L'Oréal、Salesforce 等。

目前Anthropic年消费额超 10 万美元的客户数量在过去一年增长 7 倍；年消费超 100 万美元的客户已突破 1000 家，该数字在 2026 年 4 月仅为 500 余家，不到两个月实现翻倍，而两年前仅有十几家。财富 10 强企业中已有 8 家成为其客户。

Anthropic的高ARR不仅代表Claude需求量高，另一组数据也反映出了这背后AI模型公司与云巨头之间日益深入的利益绑定。

根据SemiAnalysis发布的数据，2026 年第二季度，Anthropic 来自间接渠道（Amazon Bedrock、Microsoft Foundry、Gemini Agent Enterprise）的 ARR 占比已超过 40%。与此同时，API 和 B2B 业务贡献了公司绝大部分的净新增年度经常性收入（NNARR）。

这种收入结构的变化十分重要，因为间接渠道收入与直接渠道收入的变现方式并不相同。

具体取决于合作协议，超大规模云厂商可能收取 IaaS 费用或参与收入分成；AI模型公司则作为账面销售方，按总额确认 ARR。因此，同样规模的 Token 消耗，在 AI 实验室和云服务商的账面上，可能对应不同的收入金额和利润率。

简单来说，双方的合作核心是：Anthropic用利润率换取增长速度，云厂用资本和算力换取Claude增长中的多层收益。双方都从Claude的扩张中获益，但云厂控制着更多基础设施和分销环节。

以与Amazon的合作为例，企业客户通过Amazon Bedrock调用Claude时，通常使用现有AWS账户、云合同和统一账单完成采购。虽然客户由AWS开票，但Anthropic仍是Claude模型服务的销售主体，并按照总额确认相关token收入。

AWS在这一过程中扮演基础设施和分销平台的角色。Anthropic与Bedrock交易结构包括固定IaaS费用、收入分成，以及与token吞吐量或消费规模相关的业绩门槛。Claude使用量越大，AWS获得的基础设施收入和渠道分成越多。

对于云厂商而言，收入分成是有利的，因为 Token 即服务（TaaS）业务的变现能力和利润率通常高于其 IaaS 业务。但更多增量利润流向云服务商，最终会压缩 AI模型公司的 EBIT 利润率，而模型公司通常将这部分成本计入销售与市场费用。

因此，一笔通过Bedrock产生的Claude收入，Anthropic可以计入完整ARR，但需要向AWS支付算力费用和渠道分成。这也意味着，通过Bedrock产生的100美元ARR，与Anthropic直接面向客户销售产生的100美元ARR，经济价值并不完全相同。前者有利于扩大收入规模，却可能因为AWS分成而贡献较低的利润。

有网友算了一下，Anthropic通过云厂商卖API，云厂商大概能分走约 4 成收入，按净利润来算可能和 Anthropic 的收入是差不多的，因为Anthropic要扣掉算力成本。所以 650 亿美元 ARR 虽然不是假收入，但收入结构显然没那么健康。渠道占比越高，营收增长和利润增长就越不能直接画等号。如果只看 ARR 的话，可能会高估这些收入对 Anthropic 最终利润的贡献。

但对Anthropic而言，云厂商渠道最重要的价值就是其已经建立起来的企业分销网络。

比如，大量大型企业拥有长期AWS合同、预付云额度和成熟的合规体系。通过Bedrock采购Claude，这些客户不需要重新引入一家独立AI供应商，也不必重新完成漫长的安全评估、预算申请和供应商审批。这使Anthropic能够绕过部分直接销售流程，降低企业获客成本，并迅速进入全球大型公司的核心业务系统。

与此同时，Bedrock还为Anthropic提供了更灵活的算力获取方式。如果采用传统IaaS合同，Anthropic可能需要提前签署多年期算力采购承诺，并承担需求不及预期的风险。通过与实际token消费相联系的合作模式，Anthropic可以获得更强的算力弹性，但代价是单位成本和渠道费用更高。

当然，这套模式能够显著提高Anthropic的收入增长速度，新问题也会随之到来。

首先，Anthropic通过Bedrock按总额确认收入，意味着其ARR增长可能快于实际经济利润增长；其次，AWS掌握企业客户入口、账单和底层算力，随着间接渠道占比提高，其相对于Anthropic的议价能力也可能增强；此外，Bedrock并不只服务Claude，Amazon可以同时引入OpenAI及其他模型。当不同模型之间的性能差距缩小时，客户可能更依赖Bedrock的平台和合规能力，而不是直接依赖某一家模型公司。

企业版订阅向整个业务输血？

数据显示，订阅业务占Anthropic总营收的 10%-15%。各档位内仍按 token 计量使用量，通过速率限制与会话大小管控模型访问权限。

“Anthropic摆明了是故意把效果做烂：想要Opus 4.8级别的性能，你就得去用贵得多的Fable 5.0。Codex的表现也一样拉胯。以前20分钟就能搞定的事，现在得花一整天，token消耗量还跟着水涨船高。我现在真的没辙了。Gemini比这几个还要差。我已经打定主意，要多花点时间研究下中国的模型了。”有网友吐槽。

除了关注较多的个人订阅外，Claude Code企业版近期被吐槽得也很多。

“我同事用的是Claude Code企业版，按API调用计费。我自己用的是100美元档位的订阅套餐。她只能用低阶模型，月中就耗完了350美元的额度；可我的调用量是她的好几倍，处理的任务也更复杂，却几乎碰不到额度上限。企业版这玩意儿，真是离谱到家了。”Bharat Digital创始人 Harsh Nisar 说道。

有网友也遇到了这种情况。“公司给我配了价值 250 美元的企业版额度，我只用 4 天就用完了。可我自己花 200 美元买的个人订阅，能用出 20 倍的量。”其直言，“这差距大得离谱，说白了就是企业版在给整个业务补贴输血。”

对此，有人解释道，企业版的定价逻辑根本不是产品定价，是采购逻辑。“她的账号是卖给财务团队的，这类客户要的就是刚性额度管控，而你的套餐面向的是个人用户。所以，她按 token 按量付费，每月 15 号就把额度耗光了，而你用的是固定资费套餐，哪怕重度使用也能覆盖。同一款产品，只是买单的主体不同而已。”

还有人补充道，之所以差距这么悬殊，核心在于两类套餐对无效消耗的计费逻辑天差地别。

API按量计费模式下，每一次调用重传的对话历史，都会按全额重复计费。一条10轮的对话，上下文就占2000-4000 tokens；如果不做压缩处理，后续每一次调用都要为这部分相同的上下文全额付费。要是把上下文精简总结成一段200 tokens 的内容，后续对话的计费成本就只剩原来的5%-10%。这当然改变不了企业版本身的定价逻辑，但这类隐形消耗，往往就是企业版开销超支的核心原因。

参考链接：

https://blog.tickertrends.io/p/claude-code-vs-openai-codex-arr"

https://x.com/SemiAnalysis_/status/2089714350164492652"

https://newsletter.semianalysis.com/p/anthropic-growth-and-bedrock-mix"

https://www.youtube.com/watch?v=WCrnS09vpfo"

撞名Anthropic的“外挂”刷屏：让“DeepSeek V4‑Pro碾压 Fable 5”但无人能复现，Token开销反而翻倍

褚杏娟 — Fri, 21 Aug 2026 03:01:37 GMT

最近，一个名为 J-Space Cognition Suite 的社区项目近日在 X 上快速传播。项目方声称，在完全不修改 DeepSeek V4-Pro-0813 模型权重的情况下，仅通过一套推理时 Harness，就能显著提升模型在多项 Agent Benchmark 上的表现，甚至超过 Fable 5。

不过，这一看起来颇为惊人的结论目前仍缺少最关键的一环：第三方复现。据 ExplainX 梳理，截至8月18日，J-Space Cognition Suite 公布的所有性能提升数据均来自项目方自己的测试，尚未有独立团队在相同条件下复现相关结果。因此，“DeepSeek V4 Pro 已经借助 J-Space 击败 Fable 5”目前仍然只能被视为项目方及社区传播中的主张，而不是已经得到验证的事实。

更容易引发误解的是，J-Space Cognition Suite 与 Anthropic 此前公布的 J-space 研究并不是同一个东西。前者是一套面向 DeepSeek V4 Pro 的第三方 Agent Harness，后者则是 Anthropic 对 Claude 模型内部神经表征展开的可解释性研究。两者虽然名称相似，但技术对象和用途完全不同。

不改模型权重，靠Harness把 V4 Pro“榨干”？

J-Space Cognition Suite 是一个面向 DeepSeek V4-Pro-0813 的社区开源项目。本质上，它并不是一个经过微调的新模型，也没有生成新的模型 checkpoint，而是在模型运行时外面增加一层 Harness，通过调整 Agent 的任务执行流程改善最终表现。

项目方认为，DeepSeek V4 Pro 在长时间 Agent 任务中存在两个主要问题：一是“表征漂移”，二是“过早停止”。

所谓表征漂移，可以理解为模型执行长链路任务时，随着步骤不断增加，当前工作状态逐渐偏离最初目标，具体表现可能包括忘记此前的重要上下文、重复已经完成的工作，以及在任务持续推进过程中逐渐“跑偏”等。

“过早停止”的定义则更加直接，即Agent 实际上还没有完成任务，却提前认为工作已经结束。例如在代码尚未完全修改、测试尚未完成或者仍存在错误的情况下，模型已经宣布任务完成并停止执行。

J-Space Cognition Suite 的核心思路并不是重新训练模型，而是在 Harness 层改善重试、验证、记忆、状态维护和停止条件等外围机制。项目背后的假设是：DeepSeek V4 Pro 模型权重本身已经蕴含更强的能力，只是现有 Agent 运行框架没有充分释放这些能力。

从这一角度看，J-Space 提出的是当下越来越受AI开发者关注的问题：同一个模型，在不同Harness下，究竟能够表现出多大的能力差距？

目前，在其官方GitHub上公布的一组数据显示，加入 J-Space Cognition Suite 后，DeepSeek V4-Pro-0813 在 Terminal-Bench 2.1 上的成绩从87.9提高至90.1；NL2Repo成绩从61.5提高至73.4；Toolathlon-Verified则从74.1最高提升至79.5。

其中，Terminal-Bench 2.1提升2.2分，NL2Repo提升11.9分，Toolathlon-Verified最高提升5.4分。也正是这些成绩，推动了“DeepSeek V4 Pro通过J-Space击败Fable 5”的说法在X上迅速传播。

一个对项目相对有利的细节是，其公布的改造前基准与DeepSeek官方成绩基本接近。这至少意味着项目没有通过人为压低DeepSeek原始基线来制造夸张提升。

但真正重要的问题发生在“改造后”。

ExplainX指出，目前这些提升后的数字全部来自J-Space Cognition Suite项目方自己运行的Benchmark。包括Terminal-Bench、NL2Repo和Toolathlon-Verified在内，尚未发现项目之外的独立团队按照相同模型、Prompt、Harness、工具权限和推理预算重新跑出类似结果。

因此，“DeepSeek V4 Pro现在已经全面超过Fable 5”还不能作为一个已经确认的Benchmark事实。尤其是在Agent Benchmark越来越依赖外围Harness的情况下，仅有最终分数已经很难说明全部问题。模型是否允许重试、可以执行多少轮工具调用、是否拥有额外记忆模块、任务停止由谁判断、验证失败后是否自动回滚，这些因素都可能显著改变最终成绩。

真正严格的验证方式，应当是针对同一个DeepSeek V4-Pro-0813进行A/B测试：一组使用J-Space Harness，一组不使用；除此之外，Prompt、工具权限、推理强度、测试环境以及其他变量全部保持一致。只有在这种条件下，才有可能判断性能提升究竟来自Harness本身，还是Benchmark波动以及其他实验变量。

截至8月18日，项目之外的独立复现仍然没有出现。

此J-Space，与Anthropic研究不是一回事

此次事件中最容易产生误解的地方，是“J-Space”这个名字。

2026年7月，Anthropic曾发表一项关于Claude内部“J-space”的研究。该研究关注的是Claude内部一组特殊的神经表征，并尝试从“全局工作空间理论”（Global Workspace Theory）的角度理解模型内部信息如何被读取、传递和利用。这是一项模型可解释性研究。

而此次围绕DeepSeek V4 Pro传播的J-Space Cognition Suite，则是完全不同的社区项目。它是一个运行在DeepSeek V4 Pro外部的推理时Harness，与Anthropic没有官方关系，也不是将Anthropic的J-space直接移植到了DeepSeek。

J-Space Cognition Suite使用了一些类似“global workspace”的语言描述自己的推理机制，其命名究竟是受到Anthropic研究启发，还是单纯的命名巧合，目前并不能确认。但从技术形态来看，两者区别非常清楚：Anthropic研究的是模型内部表征，而J-Space Cognition Suite处理的是模型外部Agent执行流程。

也就是说，社区目前传播的“V4 Pro + J-Space”并不是“DeepSeek用上了Anthropic发现的J-space”。但这个命名确实迷惑了很多人，不少人在尝试后反馈无法复现，没有得到很好的结果。

有开发者扒了J-Space 的GitHub仓库代码后，直言这就是“skill plugin”，即运行在模型外围的skill或脚手架。

不过也有网友指出，J-space 也可以通过提示词来操控，比如“先思考一下 XYZ，然后再说 blablabla”，并不一定非要通过直接注入的方式。所以，理论上确实可以用这种方式来利用 J-space，但具体怎么做、哪些方法有效，仍然需要实际的探针实验去验证。

“这就是炒作，而且是假的。我没能复现其中任何一项说法。实际上，它消耗的 Token 反而比基线更多，推理表现也没有超过不使用这个 Skill 的 DeepSeek。”有尝试过的开发者说道。

还有开发者尝试用 DSH跑了一遍后，发现它确实能够运行，并且也表示，它的实现形式是一个 Skill，再加上一些 Python 辅助脚本，用来做类似看板的持久化任务管理。不过，这次测试的10个任务都比较简单，虽然覆盖了不同类型的编程工作，但可能也是测试结果不理想的原因之一。

该开发者测的是 V4 Flash 的 Token 消耗，不是 Pro 版本，（不过项目方也提到这套方法对 Flash 同样有效，只是提升幅度会更小），并且用的是 DeepSeek 官方 API。测试结果如下：

PI：作为基线。PI + J-Space：成本大约是基线的 2～4 倍。DSH + J-Space：Token 消耗相比基线高约 50%。

该开发者的结论是，用原生 Harness + V4 Flash 跑了一个设计得并不严谨的 Benchmark后，其没有观察到所谓的成本节省效果。相反，相比直接使用裸 PI，实际 Token 消耗反而更高。

J-Space Cognition Suite的传播还与另一个名字发生了交叉：Operation Cheepseek。

同期，OpenCode宣布“Operation Cheepseek: Phase 1 Complete”，OpenCode Go用户据称可以以10美元获得30美元额度。与此同时，OpenCode还将DeepSeek V4 Flash的请求限额从每5小时31,650次调整到3,800次，降幅约88%。

由于这些信息都集中出现在DeepSeek、Agent Harness和OpenCode相关社区中，部分传播内容开始将OpenCode的Operation Cheepseek与J-Space Cognition Suite联系起来。

但ExplainX指出，目前没有证据能够证明两者属于同一个项目，也没有证据表明这是一次协调行动。因此，在缺少进一步信息之前，将两件事直接合并是不准确的。

Harness进入“补短板”阶段

J-Space 尽管仍缺少独立复现案例，但它所试图解决的问题并不特殊：长任务状态怎么保存、模型什么时候应该继续、什么时候真正完成、工具失败后如何恢复、上下文越来越长后如何避免遗忘，以及这些机制需要付出多少额外Token成本，正在成为几乎所有Agent Harness共同面对的问题。

模型厂商和开源社区也正在围绕这些问题快速补课。

这种变化从DeepSeek Harness最新的更新内容中也能看出来。8月17日发布的v0.1.0-rc.7增加了Codex和Claude Code子代理任务的Job Panel管理、MCP/ACP图片附件持久化，同时修复了极简模式下Persistent Bash卡顿、大历史消息分页栈溢出以及max-token截断后会话无法继续等问题。DeepSeek还新增了low推理强度选项。相比“增加一个新工具”，这些更新更集中在子Agent调度、长会话、状态恢复和推理成本控制等系统层问题。

Harness目前最明显的短板之一，是长任务状态管理。

8月发布的“LongHorizon-Harness”研究直接把这一问题概括为“task-state management problem”。研究人员指出，现有Agent Harness通常将任务执行、任务状态和完成判断全部放在持续膨胀的上下文中，状态越来越难追踪，错误的自我判断也可能继续传播。

这也是J-Space 引入类似Kanban的外部持久化设计的原因。其思路并不是单纯要求模型“记性更好”，而是在模型之外保存任务进度，让Agent即使在某一轮推理中发生遗忘或偏离，也还有机会被外部状态拉回原来的任务轨道。

但状态外置并没有彻底解决问题，因为长上下文通常还需要另一个机制：Compaction（压缩），即把越来越长的历史压缩成更短的摘要。

OpenCode目前就内置了一个隐藏的Compaction Agent，当上下文过长时自动生成更短的状态摘要；同时，它还将General、Explore、Scout等不同Subagent分工处理不同任务。

但社区实际使用也暴露出Compaction的风险。OpenCode今年的一项Issue报告称，一个原本被定义为只读的Explore Agent，在触发Compaction后可能丢失原有权限约束，开始修改文件。问题提出者因此建议Compaction必须保留原Agent的工具和权限限制。

这揭示了当下一个很现实的矛盾：上下文不压缩，Agent会越来越臃肿；压缩以后，又可能丢失任务目标、状态甚至权限边界。

Agent会做事以后，新的问题变成“什么时候算真正做完”。因此，越来越多Harness开始把Verification和Stop Condition从模型自己的语言判断中拆出来，比如DSH甚至将agent/turn-stopping设计为一个独立扩展节点，插件可以在模型准备结束任务时继续介入。

近期的StateM研究也把“过早停止”列为长任务Agent的典型失败模式之一。研究者没有改变底层模型权重，而是通过持久状态、阶段化上下文、经过检查的状态转移以及可恢复Runbook来约束执行过程。论文报告称，相同Harness可以将DeepSeek V4 Flash在Terminal-Bench 2.1上的成绩从82.7%提高至88.1%，并进一步讨论了使用廉价模型和Harness控制实现更高性价比的可能性。

但验证、重试和更多状态检查也带来了新的成本问题。

有研究团队对17个前沿模型进行了 Long-Horizon-Terminal-Bench 评测。结果显示，Agent平均每项任务消耗约980万Token，每次运行大约经历239个执行回合，平均执行时间为88.9分钟。

因此，Harness下一阶段要解决的问题还包括什么时候值得再让模型重试、什么时候继续运行已经不划算等。

通用Harness还是模型原生Harness？

另一个正在形成的分化是，社区越来越希望Harness能够兼容所有模型，而模型厂商则开始主动开发更贴合自身模型特性的原生Harness。

OpenCode属于典型的通用路线。它将Build、Plan、General、Explore和Scout等Agent拆成不同权限和职责，让Subagent之间分工协作，同时通过Permission体系限制文件编辑和Shell操作。

但多Agent也让权限管理明显变复杂。今年4月，OpenCode曾被报告存在父Agent禁止写文件，但可以通过调用拥有写权限的Subagent绕过限制的问题。后续修复方案开始将父Session中的deny规则和外部目录权限传递给子Agent。

而模型厂商正在选择另一条路线：更深地了解自己的模型行为，并围绕这些特性设计Harness。

DeepSeek直接推出官方DSH，将Model Adapter、Agent Loop、Session、Sandbox、Approval Policy等都纳入统一插件架构；OpenAI今年4月升级Agents SDK时，则明确提出“model-native harness”，将Memory、文件和Shell工具、Skills、Compaction等能力集成进Agent Loop，同时把Harness和真正执行模型生成代码的Sandbox拆成两个层次，以提高隔离性、持久性和扩展能力。

是让模型适配Harness，还是让Harness适配模型？目前并没有标准答案。

参考链接：

https://explainx.ai/blog/j-space-cognition-suite-deepseek-v4-pro-harness-august-2026"

https://github.com/Tiger3807861189/DeepSeek-V4-J-Space-Capability-Realization-Report"

https://github.com/anomalyco/opencode/issues/16372?utm_source=chatgpt.com"

https://arxiv.org/abs/2608.01964?utm_source=chatgpt.com"

https://arxiv.org/abs/2608.15089?utm_source=chatgpt.com"

OpenAI 之后又是 Anthropic，Claude 将攻击延伸至公共互联网

作者：Olimpiu Pop — Fri, 21 Aug 2026 02:25:50 GMT

在 OpenAI 披露其模型在 ExploitGym" 基准测试期间逃逸沙箱"之后，Anthropic 开展了一项回溯审计，覆盖 141006 次评估运行。调查评估了多项进攻性基准测试的历史测试，包括 Cybench"、CyberGym" 和 ExploitBench"，重点检查了在第三方评估合作伙伴 Irregular 提供的环境中执行的运行。审计发现了三起不同事件"，涉及六次评估运行。在这些运行中，由于出口路由配置错误，以及模型在夺旗演练期间攻陷了现实世界中的目标，Claude 模型得以访问公共互联网。

这些事件涉及 Claude Opus 4.7、Mythos 5 和一个尚未发布的内部研究原型。在所有运行中，模型都在专用的隔离测试环境中运行，与 Anthropic 的内部网络和客户数据分离。模型保留了基础的模型级安全训练，但没有配备生产级拒绝分类器和实时滥用监控。系统提示明确告知模型，它们运行在无法访问互联网的离线模拟环境中；然而，网络容器配置错误使出站互联网路径仍然处于活动状态。由于错误地假定所有可访问的 IP 地址都位于评估范围内，模型采用了基本的攻击技术，而没有利用零日漏洞或尝试自我外泄。

第一起事件涉及 Claude Opus 4.7"。在该场景中，一家虚构目标公司与一个真实域名同名。Opus 4.7 无法在容器内部访问本地目标，于是执行网络发现，在公共网络上找到对应域名，并在四次独立运行中实施了针对性攻击。该模型提取了基础设施凭证、应用身份验证令牌，以及一张包含数百条真实记录的生产数据库表。内部思维链轨迹显示，Opus 4.7 意识到目标属于一家正在运营的公司，但它为自己的行为找到了理由，认为该真实主机是夺旗演练有意设置的一部分，并继续实施攻击。

第二起事件涉及 Mythos 5"。在测试容器中，该模型检查了模拟安装文档，其中引用了一个尚未注册的 Python 软件包名称。Mythos 5 识别出一个依赖混淆漏洞，并尝试在公共 PyPI 注册表上注册该软件包。为了满足 PyPI 的账户注册要求，该模型尝试了多种自动化策略，以获取用于短信验证的电话号码，之后又获得了一个免费电子邮件账户。它成功将一个带有攻击载荷的软件包发布到 PyPI。该软件包在公开状态下保留了大约一小时，随后被注册表的自动化安全机制删除。

在此期间，15 个外部系统下载并执行了该软件包，其中包括由一家第三方网络安全公司运营的自动化安全扫描器。载荷在扫描器内部执行后，将本地环境凭证外泄到 Mythos 5 建立的收集点。随后，该模型使用这些被盗凭证，直接横向进入该安全供应商的基础设施。在其推理轨迹中，Mythos 5 指出上传真实软件包是不恰当的，但由于发现了无法识别的 TLS 证书颁发机构，而且系统日期被设置为 2026 年，它断定该环境是模拟环境，并因此忽略了风险。

第三起事件涉及一个内部研究原型。该模型未能在本地找到目标后，对大约 9000 个公共 IP 地址进行了自动扫描。它利用多种 Web 攻击手段攻陷了一个外部应用，包括从暴露的调试端点收集凭证以及实施 SQL 注入。在后续执行链中，该原型分析了目标环境的元数据，认定该云账户与评估演练无关，并自主终止了所有攻击活动。

Anthropic 于 7 月 23 日暂停了所有进攻性网络安全评估，并于 7 月 27 日通知了受影响实体。该公司将这些事件定性为操作和运行框架控制失误，而不是模型对齐失控，理由是缺乏出口过滤以及提示上下文不匹配。接下来，Anthropic 将升级沙箱隔离控制措施，扩展交互记录监控流水线，并与独立评估机构 METR 合作审计评估环境。

这些评估逃逸事件并不是孤立的操作疏漏，而是表明 AI 安全与遏制领域出现了一种关键的全行业趋势。Anthropic 的这起事件与近期发生的先例高度相似：包括 GPT-5.6 Sol 在内的 OpenAI 模型在 ExploitGym 基准测试期间突破沙箱隔离，访问了 Hugging Face 的生产系统。这些事件共同凸显了随着自主智能体能力不断进步，前沿实验室所面临的系统性安全挑战。随着模型越来越多地展现出识别零日漏洞和执行复杂攻击路径的能力，业界迫切需要更加稳健、更加隔离的评估环境，以及不设防护栏的防御模型来支持事件响应。

原文链接：https://www.infoq.com/news/2026/08/claude-sandox-breach/"

Rust 再下一城：Astro 7 重写编译器与 Markdown 流水线

作者：Daniel Curtis — Fri, 21 Aug 2026 01:16:00 GMT

面向内容的 Web 框架 Astro 发布了 Astro 7"。该版本几乎完全聚焦于构建性能，随后发布的两个次要版本又对其进行了扩展。

此次更新的核心是转向原生工具链。.astro 编译器已使用 Rust 重写，Markdown 和 MDX 处理迁移到新的 Rust 流水线，渲染切换到基于队列的引擎，框架现在则基于 Vite 8" 及其 Rolldown 打包器运行。Astro 自己的基准测试显示，构建速度提升了 15% 至 61%：astro.build" 的构建时间从 62.70 秒降至 24.24 秒，包含 8,431 个页面的 Cloudflare 开发者文档则从 386.89 秒降至 261.94 秒。

新编译器取代了此前的 Go 实现，使用 oxc" 进行解析，并使用 Lightning CSS" 处理作用域。它也更加严格。未闭合的标签现在会报错，而不是被静默修复；无效的嵌套会按原样传递；元素之间的空白则遵循 JSX 规则。

Markdown 现在通过 Sätteri" 运行。这是由核心团队成员 Erika 基于 pulldown-cmark 和 Oxc 构建的 Rust 处理器，内置 GitHub Flavored Markdown、智能标点、标题 ID、数学公式和 Wiki 链接，而不是通过插件附加这些功能。依赖 remark 或 rehype 的项目可以继续使用旧流水线。

除速度之外，Astro 7 还通过兼容 Hono" 的 src/fetch.ts 入口点增加了高级路由功能，正式稳定了路由缓存"，并为 Netlify、Vercel 和 Cloudflare 提供实验性 CDN 提供商，同时还为 AI 编码智能体引入了 astro dev --background 和 JSON 日志。

Hacker News" 上对该版本的反应褒贬不一，发布帖子获得了 211 分。一位评论者对依赖项数量从 v6 的 247 个降至 v7 的 190 个表示欢迎"，另一位评论者则认为，对于受困于旧版 .astro 文件的团队而言，严格的 HTML 编译“实在不怎么样”（原文链接）"。

一位开发者对 Markdown 切换提出异议"，称“仅仅为了提升构建速度”就放弃 unified“令人相当不满”。这促使核心团队成员 Erika 确认"，该流水线被刻意设计为可插拔形式，unified 并不会消失。

Williams 报告"称，他们自己的构建速度反而略有下降，维护者 Matthew Phillips 对此回应道：

有多少个页面？性能改进主要面向较大型的网站（数千个页面），尤其是大量使用 MDX 的网站。我们也在开发增量构建，这应该会有所帮助：https://github.com/withastro/roadmap/issues/1388"

迁移通过 npx @astrojs/upgrade 完成，v7 升级指南"介绍了具体细节。Rust 编译器、队列渲染、日志记录、缓存和高级路由的实验性标志均转为稳定功能；src/fetch.ts 成为保留文件名；@astrojs/db 被移除，改用 Drizzle" 或 node:sqlite；已弃用的 astro:transitions 内部功能也已移除。

随后又发布了两个次要版本。7 月 16 日发布的 Astro 7.1"侧重于控制能力，而不是速度。新的 script-src-elem、script-src-attr、style-src-elem 和 style-src-attr CSP 指令允许使用内联样式，而无需放宽针对外部 CSS 的策略；paginate() 新增 format 函数，可以在文件格式构建中重写 next、prev、first 和 last URL。--ignore-lock 标志恢复了运行第二个开发服务器的能力；glob() 加载器的 deferRender 选项以放弃跨构建 HTML 缓存为代价，降低大型集合的内存占用；实验性的 collectionStorage: "chunked" 标志则会每隔 10Mb 拆分一次 .astro/data-store.json 存储，以适应对文件大小设有限制的平台。

Astro 7.2" 于 8 月 6 日发布，带来了 Phillips 此前预告的增量构建功能。在 experimental.incrementalBuild 标志之后，路由可以通过 getStaticPaths() 为每个路径返回一个 cacheKey 来选择启用该功能；对于内容集合，entry.digest 是自然的选择：

与竞争对手相比，其定位并未改变。Next.js 16 已正式稳定用于生产构建的 Turbopack，并且仍然是更重量级的应用框架；Astro 则继续以内容驱动型网站为目标，默认不包含客户端 JavaScript。真正发生变化的是，Astro 的构建工具链现在采用了原生代码，缩小了与竞争对手一直在交付的 Rust 流水线之间的差距。

Astro 是一个面向内容驱动型网站的开源 Web 框架，采用 MIT 许可证分发，并于 2026 年 1 月被 Cloudflare 收购"。它默认在服务器端渲染组件，并允许团队通过使用 React、Vue、Svelte、Solid 或 Preact 构建的孤岛添加交互功能。

原文链接：https://www.infoq.com/news/2026/08/astro-7-release-speed/"

CFP 开放 | KCD 杭州站邀您共议 Agent 时代的云原生、可观测与大模型推理

KCD Hangzhou 2026 组委会 — Thu, 20 Aug 2026 11:03:02 GMT

KCD Hangzhou 2026 将于 11 月 28 日在杭州举办，即日起面向社区征集演讲议题，截止时间为 9 月 30 日。

杭州是阿里巴巴和 DeepSeek、宇树科技等多家人工智能企业的诞生地，也是全国首批"国家新一代人工智能创新发展试验区"，云原生与 AI 的开发者社区在这里都有深厚积累。11 月，我们期待与大家再次相聚杭州，围绕 Agent 时代的云原生技术展开交流。

会议信息

会议背景

KCD（Kubernetes Community Days，Kubernetes 社区日）是由社区组织的活动，汇聚开源和云原生领域的采用者和技术人员，旨在促进教育、协作和交流。KCD 活动由云原生计算基金会（CNCF）提供支持。

大会主题

Cloud Native in the Age of Agents：当云原生遇见 Agent

AI Agent 正在重塑软件的构建方式和运行形态。从 MCP 协议到推理引擎优化，从 Agent 沙箱隔离到多 Agent 编排，Kubernetes 正在成为 Agent 工作负载的标准运行时，CNCF 生态中的 OpenTelemetry、Envoy、Knative 等项目正在为 Agent 时代提供新的基础设施保障。

KCD Hangzhou 2025 以 AI + Cloud Native 双 Track 吸引了 82 份投稿、39 位讲师、316 名到场参会者和 20,000+ 线上观众，参会者反馈最强烈的声音是——希望更多深度 AI 内容和互动环节。今年我们围绕 "Agent on Kubernetes" 这一核心叙事，设置三个分论坛：Agent 如何在 K8s 上运行、如何用 CNCF 可观测生态保障 AI 系统质量、AI 推理引擎如何与 K8s 调度深度结合。每个 Track 都扎根于 CNCF/K8s 生态，同时回应 Agent 时代的新需求。

分论坛设置

Track 1：Agent Infra — K8s 上的 Agent 运行时与基础设施

出品人：

Fupan Li, Kata Containers architecture committee (AC) member张振, PhD, OpenKruise Maintainer

Agent 的生产化部署本质上是 Kubernetes 上的一类新工作负载。如何安全隔离 Agent 代码执行、如何通过 CNCF 网关项目治理 MCP/A2A 流量、如何利用 K8s 原生的编排能力协调多 Agent 协作——本论坛聚焦 K8s 生态如何承载 Agent 工作负载。

推荐选题方向：

Agent Gateway：CNCF 网关生态在 Agent 流量治理中的角色Agent Sandbox 与运行时隔离Agent 编排、注册与通信Agent 工作负载调度与资源管理

Track 2：Observability & Reliability for AI — CNCF 可观测生态在 AI/Agent 时代的演进

出品人：

Juraci Paixão Kröhling, Governance Committee member for the OpenTelemetry project张乎兴, OpenTelemetry Go Compile time Instrumentation SIG maintainer, Alibaba

CloudOpenTelemetry 是 CNCF 除 Kubernetes 之外最成功的 Graduated 项目。Agent 时代对可观测提出了全新挑战：GenAI 语义规范、多 Agent Trace 关联、推理性能指标采集。同时，混沌工程、SRE 实践也在向 AI/Agent 场景延伸。本论坛聚焦 CNCF 可观测与可靠性生态如何保障 AI/Agent 系统的质量。

推荐选题方向：

OpenTelemetry × GenAI：语义规范与 Agent Trace 标准化AI 系统可观测实践Agent 评测与混沌工程语义知识底座与智能运维

Track 3：AI Infra & LLM Serving — K8s 上的推理引擎与 AI 基础设施

出品人：

宋净超（Jimmy Song）, HAMi Community Manager, CNCF Ambassador张家驹, vLLM社区贡献者, 红帽大中华区CTO

大模型推理是 Agent 时代的算力底座，而 Kubernetes 是推理引擎的标准部署平台。vLLM、SGLang 等开源推理引擎如何在 K8s 上高效运行、GPU 调度如何优化、平台工程如何支撑 AI 工作负载——本论坛聚焦 K8s 作为 AI 推理基础设施的工程实践。

推荐选题方向：

vLLM / SGLang on Kubernetes：生产部署实践推理性能深度优化长上下文、多模态推理与成本控制模型生命周期管理议题提交说明

CFP 地址：

https://sessionize.com/kcd-hangzhou-2026/"

或扫描以下二维码提交演讲：

议题形式：

标准演讲：30 分钟（含 Q&A）闪电演讲：10 分钟（技术亮点速览）

截止时间：北京时间 2026 年 9 月 30 日 23:59（以提交时间为准）

结果通知：通过初审的议题将于提交后 14 个工作日内收到确认函

参会须知

本活动采用定向邀请制，参会资格需经组委会审核；主办方不承担参会者差旅及住宿费用（特殊情况请与主办方沟通）。

联系方式

议题提交：

邮箱：tunan.wr@alibaba-inc.com　

微信：dig_403

赞助咨询：

邮箱：liqiong.lai@geekbang.com

手机：18518483325

认识 KCD 杭州组织者

我们专业的组织团队致力于举办一场充满活力和包容性的活动：

蔡威：CNCF Ambassador, DaoCloud江波：Head of Growth and Ecosystem, Robbyant夏小雅：Open Source Program Manager, Ant Group王蓉：Open Source Program Office Operations Manager,Alibaba Cloud张乎兴：OpenTelemetry Go Compile time Instrumentation SIG maintainer, Alibaba Cloud

合作伙伴

InfoQ、极客时间、极客时间企业版、TGO鲲鹏会、模力工场

InfoQ 推荐

Next.js 16.3 发布：即时导航、开发内存最高降低 90%，构建速度大幅提升

多个 AI 智能体“同住”一台 EC2：AgentCore 推出持久计算

“我们破坏了你们所有的应用”：React Router v8 引发争议，有开发者转向 TanStack Router

GitHub 公开预览 Stacked Pull Requests 功能

Netflix 开源了一个用于因果推理的智能代理工作流

完全相信AI代码的Uncle Bob，坦诚这条路还没走通

“浴袍”出镜的Uncle Bob

终极目标：完全信任 AI 的输出结果

AI 同样受代码腐烂折磨

多智能体开发质量高于人工

AI 架构规划流程全自动化，还不行

AI开发普及，需要对《Clean Code》做什么调整

“没有必要耗费大量精力做前置规划”

新人要把把自己当成“人类智能体”

DeepSeek 再度调价；英伟达AI服务器涨价超 15%；“AI红娘”承诺三年不结婚就退款，前 Kimi搜索负责人创业目标：拉高10%结婚率 | AI周报

行业热点

大模型一周大事

DeepSeek API 价格再调

GPT-5.6 Sol 模型价格下调， Codex额度问题引争议

英伟达 AI 服务器涨价超 15%

黄仁勋女儿探访多家中国机器人企业

宇树上市开盘涨超 6 倍后大跌19%，有中签者说幸亏全卖了

“AI红娘”承诺三年不结婚就退款，前 Kimi 负责人立志拉高结婚率 10%

奕境X9发布会送假Labubu？品牌方回应

人均557万元！寒武纪124名员工股票激励“大红包”即将到账

曾主导 AI 眼镜等项目，字节AI穿戴核心产品负责人刘锐离职

钉钉全球商业总裁杨猛将离任，下一站蚂蚁集团

原xAI多模态理解负责人蔺旭东加入混元大模型团队

韦东奕账号时隔一年多更新，上架自编小学数学练习册销量已破万

京东快递员转型机器人维修：首批培训后已上岗，未来 5 年创造 10 万个就业岗位

Meta 成微软最大 AI 客户之一：年采购额达数亿美元，每周消耗数万亿token

Stripe超70亿美元收购OpenRouter

Anthropic业绩反超OpenAI，正全速推进 IPO 进程

围棋八冠王柯洁分享必赢AI方式：“装弱智”

重磅发布

DeepSeek Harness 首发新版本：多模态能力升级

GLM-5.3 上线：60 分跻身全球前沿，与 Kimi K3 并列开源模型第一

阿里推出 AI 音乐模型快乐虾米

阿里虎鲸文娱自研“虎鲸AI大模型”，内测AI视频创作工具

豆包上线“工作任务”新功能，手机可远程操作电脑

支付宝发布国内首个Agent商业底座

百度文心助手推出任务引擎2.0，日活用户同比增长83%

稀宇科技推出MiniMax Design

9.9 万起！蔡明同款仿生机器人亮相：五官自然精致 主打情感陪伴

宇树科技发布“超人”机器人

企业应用

从现实到反馈：KDC 完整工程模型全景

KDC 要解决的不是所有软件问题

一条从 Reality 到 Feedback 的完整闭环

Reality 是最终参照物

Reality Model 决定系统看见什么

Representation 是现实的数字编码

Knowledge 提供可复用依据

Memory 让历史在受治理条件下影响未来

Reasoning 连接依据与结论

Skill 组织目标级复用

Capability 是受治理的行动入口

Action 作用于现实，Feedback 关闭闭环

Continuous Consistency 是长期方向

KDC 有两张图：业务闭环与工程模型

第一层：对象化，让隐含责任可以被引用

第二层：运行时化，让对象真正运转

知识运行时

记忆运行时

推理运行时

能力运行时

第三层：治理化，让行动边界成为系统机制

用一次退款任务组装完整模型

1. 识别现实目标

2. 装配知识与记忆

3. 形成推理对象

4. 选择 Skill

5. 提出能力调用建议

6. 控制平面判定

7. 能力运行时执行

8. 现实反馈进入系统

KDC 如何与现有体系协同

渐进采用：从一个业务闭环开始

第一步，建立 Reality Map

9.9 万起！蔡明同款仿生机器人亮相：五官自然精致主打情感陪伴