大家都在聊 RSI（自动进化模型）是不是通向 AGI 的路，OpenAI 顺手发布了 GPT 6 Astra，并宣称 AGI 已经到来了。

但 GPT 6 凭什么？只需要看看这次到底升级了什么。

一、AGI 的重心，从写代码挪到了用软件

这次发布最值得注意的反而是编程。GPT 6 在 DeepSWE 上只提升了 1.4 个百分点；真正大幅跃升的是：屏幕元素定位 ScreenSpot-Pro 从 GPT-5.6 Sol 的 76.9% 提到 92.7%，业务流程 AutomationBench 从 18.1% 提到 41.4%，CAD 设计任务提高 12.6 个百分点。

发布会演示里，OpenAI 强调的也是具体软件和工作文件的使用能力——3D 建模、Power BI、电路板设计、法律文档排版，一个个场景摆出来。

这不是 OpenAI 一家的倾向。Fable 5.1 上能看到类似情况：编程的 CursorBench 提高 2.9 个百分点，AutomationBench 提高 14.3 个百分点，科研的 Terminal-Bench Science 0.1 提升近一倍。Gemini 3.8 Flash 更是专门强调专业领域的多步骤分析，甚至拿出 Finance Agent v2、Harvey benchmark 这类领域基准来做对比。

Computer use 这个功能的轮回史，正好能窥见节奏的变化。

2024 年 10 月 Anthropic 发布 computer use 时，通用操作电脑的想象空间已经打开。但当时它自己就承认：慢，而且容易出错。模型成功点几次按钮足够做吸引人的演示，但要连续完成工作，它比人慢、稳定性又差。

随后 2025 年 2 月 Claude Code 上线，直接带火 Coding Agent 市场。到 2026 年 2 月，Anthropic 披露 Claude Code 年化收入运行率已超过 25 亿美元，仅当年年初以来就翻了一倍以上。Coding Agent 里有现成的代码仓库、命令行和测试工具，直接执行命令通常比看屏幕找按钮有效得多。CLI 和 MCP 代表的结构化工具接入一度引发”消灭 GUI”的讨论。Computer use 也在去年年中到今年年中之间，从每场发布会的展示焦点变成了不再重要的注脚。

直到这次 GPT 6 Astra 发布会，它才再度回归。

回归的原因并不神秘：程序员池子快满了，而非程序员的办公场景还没工具可用。

Codex 产品负责人在 8 月 21 日宣布月活已达 2000 万以上，更领先的 Claude Code 即便没有公开数据，应该也不比这个少。SlashData 在 2026 年第一季度估计，云原生开发者有 1,990 万，占全球开发者约 39%，倒推总量约 5,100 万人——这个口径还包含非职业开发者，真正以编程为工作、能持续形成付费需求的人群更小。

而且这个市场已经被迅速教育过一遍。JetBrains 在今年 5—7 月对超过 1.5 万名专业开发者的调查显示，90% 的职业开发者每周都在使用 AI coding agent，68% 每天使用。尚未成为每周用户的人只剩约一成，继续寻找没试过 Coding Agent 的程序员，空间已经很有限。

数据也印证了减速。第三方机构 TickerTrends 估算，截至 8 月 10 日 Claude Code 的四周收入运行率增幅为 5.2%，低于此前几个月的扩张速度。对大厂而言，Coding Agent 已经进入争夺现有用户、提高使用频率、增加企业付费的深度竞争阶段，不再是高速增长的荒蛮期。

而 Coding 之外，另一批用户才刚刚开始进来。OpenAI 在 6 月披露，非开发者知识工作者已占 Codex 用户约 20%，增长速度超过开发者的三倍。到 8 月更新企业数据时，自 2 月以来工程职能的 Codex 周活增长 5 倍，法律职能增长了 108 倍，销售和招聘分别增长 41 倍。

CLI、API 和 MCP 可以承担其中大量操作，但覆盖还不完整。牛津大学 3 月 25 日发布的调查《How are AI agents used?》分析了约 17.7 万个 MCP 工具，软件开发占工具数量的 67%、占可观测下载量的 90%。Toolradar 8 月的分类报告里，开发者工具依然占主导。2 月到 8 月间，MCP、CLI 的增长主要发生在办公、支付与商家财务、设计领域，但各领域进度不一，距离覆盖所有工具、所有操作仍有明显距离。

刷屏的 Astra 用 Blender 3D 建模的视频就是实例。按 OpenAI 公布的流程，建模是通过 Blender 的 Python API 创建场景、后台脚本设置相机和渲染；但为保证精确，它必须同时用 computer use 打开和检查 Blender，结合渲染图继续修改——正是借助视觉理解，模型发现水槽表面着色异常后修正了相关几何属性。

所以 Computer Use 的回归，不是 GUI 战胜了 CLI，而是模型进入 Coding 之外后，任务验收本身重新包含了视觉与交互。

问题是：能用软件，不等于会干活。从看到软件说明书到完成工作之间，是需要学习的。GPT 6 Astra 在这些任务上惊艳，是因为都加训过了——发布页内 OpenAI 明确提到，Astra 接受了面向专业环境的定向训练。

这种训练怎么来的？

二、工作轨迹，成了新时代的富矿

要训练模型干活，首先得让它在活儿里学着干，这就是训练任务。

在 Coding 里，这些东西不难找。GitHub 上一个已解决的 Issue 就是一道现成的题，甚至自带答案和环境：用户描述问题就有了题，仓库保留修改前的代码就有了上下文，开发者提交的解决方案就是答案，还有测试和审查意见帮你筛选修改是否有效。找到已解决的问题，把代码恢复到修改前让模型重做一遍，就能训练。

所以 Coding 范畴下，训练团队不太需要工作轨迹，从 GitHub 扒就行。

但走出 Coding 之后，这些就不再唾手可得。没有 GitHub，要么让专家脑补想象工作，要么从已有的工作轨迹里总结。专家贵，手搓慢，后者要用好了既省钱又快。

工作轨迹因此成了新的富矿。围绕它的收集、整理和利用，市场和研究界都在加大投入。

比如 Handshake，本来是高校和求职者的网络，现在 AI 数据收集成了主要工作，搜集的正是当下的工作流程。官网上他们描述现在的做法：通过录屏和轨迹分析了解工作流程，用专家制定的评分标准评估 Agent，再在模拟环境中改进表现。

Sunset 原本是帮创业公司办理关停、封存业务数据的，到 2026 年也成了一家专注工作流程的 AI 数据公司。其 4 月 14 日的官方文章披露，公司直接购买符合条件的内部数据，整理并处理隐私合规问题，授权给 AI 实验室和研究机构，材料包括内部沟通、产品开发历史、客户反馈。Sunset 把这类产品叫 RL gyms——用于强化学习的训练场。

三、用传统 Agentic RL 的眼光看，这个富矿不好采

要好工作轨迹，至少过两道关：把记录变成可执行的题目和环境，让模型能重新尝试；构造有效奖励，能判断任务完成的好坏，最好还知道哪里好哪里坏。

Coding 之外的世界，光是出题和构建环境就难度重重。

一个 RL 可用的环境，至少要让模型能在里面根据反馈尝试不同做法：操作失败了可以修改方案再试，同一道题可以重复执行、比较不同策略。

但工作轨迹 ≠ 训练样本 ≠ RL 环境。人的工作记录只记下发生过什么；训练样本还需要任务边界；RL 环境需要更多。录屏能告诉你一个人打开了哪份表格、改了哪些内容，但模型如果打开另一份文件、换一种公式，录屏不会给出新结果。要让它重做这份工作，得先还原它当时面对的上下文（文件和表格）、还原可操作的空间（软件/系统）、明确当时的要求。三个条件，对不同工作完全不同。

版本之子 Coding 已经越过山丘。 可操作空间是编程软件，开发过程又留下各种结构化记录帮你恢复场景：代码仓库存着历史版本和依赖文件，拉出来就能恢复运行条件；失败后马上恢复初始状态再试另一种修法。题目也唾手可得：Issue 描述问题，修复前的 commit 提供起点，PR 给出参考补丁，测试帮助检查结果。程序员日常使用的协作系统，已经替训练团队保存了一部分题目、答案和环境。

过去这类 GitHub 数据清洗靠人扒，但到 2025 年开始自动化了。2025 年 6 月 12 日，中山大学团队提交 SWE-Factory 初版论文《SWE Data Construction, Automatically!》，把环境准备放手交给四类 Agent：一个读项目说明弄清怎么安装，一个搭运行环境，一个准备测试脚本，最后一个实际运行、查报错再让前面的助手修改。成功配置会被保存，同一项目其他题目可以接着用。2026 年 1 月 5 日的修订版中，团队用 GPT-4.1 mini 在 671 个候选问题里构建了 337 道有效任务。

2026 年 2 月 2 日，Qwen 团队提交《SWE-Universe: Scale Real-World Verifiable Environments to Millions》，把自动出题进一步做大：专门用成功搭建环境的操作记录训练了 Qwen-Next-80A3 构建模型，最终从 52,960 个仓库构造出 807,693 个可验证训练实例，用于后续轨迹生成、中训练和强化学习。至此，从工作轨迹里自动搭建训练环境这件事正式成立，程序员们的 PR 丝滑地进入了训练循环。

还在爬坡的中间层：OS 和开放软件。 走进更开放的工作场景，Coding 的有利条件就不存在了：现实任务往往涉及多个复杂工具，记录可能分散在整个电脑乃至电脑之外。还好，在完整领域任务和 Coding 之间还有大量软件和操作系统——Blender、Office，以及连接它们的 OS——它们成了迈出去的第一步，而且早就有专门的训练途径。

2024 年 4 月 11 日的《OSWorld》把真实电脑做成可重复操作的实验环境：369 个任务，每题配初始状态配置和结果检查脚本，可涉及多应用之间的操作。Agent 在虚拟机里操作真实软件，准备任务时配好文件和应用状态，尝试结束后重置环境。Blender 也很早就构建好了环境——2025 年 4 月 2 日斯坦福的《BlenderGym》设计了 245 个场景，覆盖灯光、材质、几何编辑，每题有基础场景文件、生成初始与目标场景的脚本、渲染图和文字说明。

但到这里，工作轨迹依然只能作为人工出题的参考。即使有工作流程，它们也缺少 PR、Issue 那样成套可追溯的任务记录，最好用的反而是论坛题库。软件有了，还需要人准备初始文件、写清修改要求、制作参考结果、设计验收方式，大量标注和清洗让每个训练集成本极高。OSWorld 搭 369 道题，用了 9 名学生、三个多月、约 1,800 人时。Epoch AI 在 2026 年 1 月的行业访谈里，从业者给出单道题（只是出题和评分器，不含环境构建）的价格大概是 200—2000 美元。

既然贵，大家也想自动化。港大与 Salesforce Research 2024 年 12 月 12 日提交的 AgentTrek 去教程里扒题，让模型整理目标与步骤，再用 Agent 在真实网络里重新执行，走得通的当训练轨迹去蒸馏/SFT——但当时它主要生成轨迹，没能力为任务恢复可重置、可探索的 RL 环境。

直到最近才有初步尝试。2026 年 5 月 21 日的《Spreadsheet-RL》直接针对 Excel 任务训练 Agent：从公开表格论坛自动构造环境，训练集包含 5,925 道经筛选的 ExcelForum 任务，模型每次在独立工作空间里改表格，指定答案区域与论坛正确答案比较给奖励。

也可以现采数据，保证记录环境符合要求。2026 年 5 月 28 日腾讯混元及合作高校发布的《PhoneWorld》描述了现采数据的可能用法：先收集人在真实 App 里的操作截图和动作记录，识别常用页面、跳转关系、哪些操作会改数据；再整理成开发要求，让 Coding Agent 编写、编译、修复模拟 App。收藏、发消息等操作会修改本地数据库，重置时恢复初始状态，于是任务可反复执行、检查结果。6 月 22 日的《PhoneBuddy》就直接把这些环境用于 RL。这可能是未来的一种大规模方法，但目前还不普遍。

数据公司做的还是比较古法的环境构造。Scale AI 在 2026 年 2 月 27 日披露，当下接近一半的新数据训练项目涉及 RL 环境，产品覆盖工具使用、电脑操作和领域工作流。GPT 6 里最大的进步，正集中在数据公司专攻挖掘的领域。

到了真实的领域工作，还是只能回到古法操作。 更完整的领域任务难度又加一层，因为需要恢复的东西往往比记录下来的多得多。一位分析师做报告，留下查数据库、改表格、生成文档的操作记录，我们知道他查过什么、改过什么，却未必知道任务开始时数据库里还有什么、哪些文件他有权访问、客户在会议里补充过什么要求。这些信息没出现在记录里，不代表不重要——分析师可能正因为提前知道某个条件，才没去查另一份资料、没采用另一种方法。条件没恢复，模型重做的就不是同一个问题。

从训练效率看，理想环境应让模型低成本反复尝试，且每次尝试条件可比；最好能重置。对长程任务，能从中间状态恢复是最佳状态：前面几十步是准备，模型只在最后几步遇到困难，保存中间状态就能从那里反复探索。标准软件往往能做到这些，但实际任务分散在软件之间甚至系统之外——要从不完整的记录中恢复任务要求、确定环境边界、补齐关键状态、承受原记录之外的操作，再用软件串联起来。想从 Coding 进入其他领域，基础条件往往要重新建设，还得回归人力手搓。

前 OpenAI 员工、LoRA 发明人 Edward Hu 在 9 月 1 日发布的《Training frontier knowledge work agents: A 397B RL training guide with SkyRL》，介绍了后训练领域专门模型的过程：使用 1,928 道专家构造的任务，覆盖企业法律、投行和管理咨询。按 Mercor 1 月的 APEX-Agents，这些任务先调查数百名专业人士，了解律师、投行分析师和咨询顾问的时间花在哪里；再请有五到十年经验的专家在 Google Workspace 里模拟同事共同推进项目，制作文件和沟通材料——比如围绕一家虚构公司的咨询项目准备业务背景、分析材料，还与 Box 合作设计文件的组织方式。专业人士花五到十天构建一个资料丰富的项目环境，再根据环境设计任务。APEX-Agents 最终包含 33 个这样的环境、480 道任务和对应评分标准。RL 的环境，是每题背后一个模拟公司的工作空间。

这条路线上，工作轨迹还不能自动变成训练环境，都得靠专家手搓。但 Mercor 至少说明用 RL 训练更长程、超越 Coding 的任务是可能的，就是贵和慢，得靠巨量人力 scaling。

潜在的救星：用 Agent 内的轨迹训练 Agent 自己。 轨迹收集又贵又分散，很多时候甚至不如专家颅内出题快。那干脆用 Agent 自身留下的工作轨迹。Agent 这个产品和以前的产品不一样，整个 Harness 就是按编程逻辑构建的：保存好的上下文条件库、issue（命令）、执行环境（Agent 自己）、解题流程。虽然现在 Agent 不是全能的，但大家用它几乎覆盖所有任务，从中能找到各种复杂、多样任务的轨迹——这就是一个可能达到 GitHub 级信息丰富度和环境可控性的通用工作轨迹库，不用岂不是浪费了。

模型公司也想到了。2026 年 9 月 3 日，阿里 Qwen 团队与清华提交《Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments》，利用 Codex、Claude Code 这类编程 Agent 运行时由 harness 记录的工具调用轨迹——读过哪些文件、执行过什么命令、修改过哪些内容、工具返回了什么。系统先梳理轨迹中的文件操作，尽可能找回 Agent 修改前的内容、排除解题中新增的文件，再由另一个 Agent 补齐缺失文件和依赖、检查工作空间是否足以支持任务，最终构造约 3.73 万个环境，在其中提出新任务、重新生成解题轨迹用于 SFT。它恢复的主要仍是软件开发类任务和环境，但确实给出了通用任务如何利用 Agent 记录的明路。

当然，要真把通用领域的工程轨迹用好，还需要三个前置条件：一是 Agent 数据跨任务拼接的可能（一项日常事务可能先在一个对话里搜资料、另一个任务里做表格、人打开软件修改、第三个 Agent 生成报告，各段记录分别存在，Agent 得学会标明它们如何关联）；二是中间状态的保存和恢复（任务开始的文件版本、关键节点状态、需求变更、交付反馈）；三是让过去不在 Agent 里用的软件尽量在 Agent 里用，这需要操作系统层面更通畅、各类软件能被 Agent 稳定调用。目前除了 GPT 6 在 OS、computer use 和开放软件上的增强，其他条件还不满足。过渡期内，数据清理、背景补全和专业验收仍需大量人工，最多半自动。

即使有了可反复运行的环境，也才过了第一关。第二关是奖励和奖励分配。

有了题，得让模型知道做得好坏。但开放领域里，奖励不存在。Benchmark 之所以重要，很多时候意味着一种角度的奖励模型，改造改造就能成评分规则 rubric——但 Benchmark 也是专家攒的，自动生成的通用奖励并不存在。

Coding 之外，Universal Verifier 不存在。模型修复代码靠测试就知道成没成功，但 Excel 做得对不对、3D 建模是不是够好，非常不直观。2026 年的 Spreadsheet-RL 在真实 Excel 里评分时结合数值对错与公式、结构检查；这只是基础奖励，即算没算对。实际用 Excel，还希望结构可审计、可持续更新、跨表可计算，所以 MBABench 把端到端金融表格评估拆成 Accuracy、Formula、Format 三类，同时检查计算行为、专业语义和交付质量。3D 领域同理，2026 年 6 月的 CodeBench 同时使用执行成功率、多视角视觉相似度、三维几何指标和人类成对偏好来评价建模。这都是在一个个领域、具体任务中重新搭出来的 rubric 类终局奖励。

放到更大的领域，任务更多样，建通用奖励规则更难。Mercor 的 APEX-Agents 面对金融、法律任务，专家不得不为每项任务编写能独立判断真假的标准与评分；公开基准中每种任务平均约四项评分标准，要细化到每种任务。

没有 RLVR 的好用奖励只是一部分，信用分配在 Coding 之外变得更麻烦。数学和 Coding 训练里可以给同一道题生成多条候选、用答案检查或测试评分、强化相对较好的结果，代表是 GRPO——不用太考虑过程中哪步对哪步错。但对 rubric 难写、环境构造慢的领域，GRPO 这种粗线条评价体系太狂放也太浪费：题目少、不能浪费，而且很多 Coding 任务的工具接口和动作语义相对稳定（读文件、搜索、编辑、执行、测试），这种稳定性让价值模型容易复用经验。扩展到多种职业工作后，每一步有没有帮上忙要用不同办法判断——搜到一篇文章要看有没有提供有用信息，改好公式要看计算对不对，发消息要看有没有推动对方解决问题。只用一个 ±1 的终局分数处理，变得非常困难。

因此最近算法上的很多改动都围绕这点，路径大概三条：改造 GRPO、回归更经济可靠的 PPO 与 critic、用 rubric 和工作轨迹构造更多学习信号。

第一条路，保留 GRPO 的简洁性，改造它怎样比较和利用轨迹。 只有 ±1 太糙，那就加 checkpoint。2026 年 2 月南洋理工与东南大学的 HGPO 发现：即使当前环境一样，模型此前知道的事情可能不同——同样打开一个商品页面，一个 agent 已查过预算和尺寸，另一个还没有，接下来是否购买不能只按开始页面一样就同组比较。HGPO 按历史上下文一致程度拆分比较 rollout，未到环境状态分叉的地方单独拆组，分别计算优势再加权结合。2026 年 7 月 MBZUAI 提出 BPO，在可保存恢复的沙箱里，从模型对选择不确定的地方分叉尝试不同动作、比较后续结果，思路和 2025 年 5 月南洋理工与 Skywork AI 的 GiGPO 相似——利用不同轨迹中重复出现的环境状态，从同一处出发比较不同动作，给局部优势与整条轨迹优势结合。BPO 更主动细致，在网页购物、家务模拟、代码修复任务中报告了相同计算预算下优于 GRPO、RLOO 的效果。

第二条路，重新引入 PPO 式 critic，但用更便宜或更有效的。 早先 PPO 训练价值模型判断「任务做到这里，继续执行预计能拿多少回报」，给每个步骤打分，是稠密的过程评分模型，不必取很多 rollout。智谱 2026 年 6 月的 GLM-5.2 技术说明就提到：长任务 Agentic RL 的部分场景（上下文压缩后形成数量和长度差异很大的执行片段、GRPO 难比较）用回了带 critic 的 PPO，从单次执行估计 token 级优势。问题是训练 critic 非常贵、不一定准、训练变慢。省钱的办法是不再单独训练 critic：厦大与南洋理工 2026 年 8 月提出 SAPO，让执行任务的模型兼任 critic——生成下一步操作时顺带预测这步最终能获得多少奖励，跑完后比较实际结果与当时的预测差额作为训练信号。比如搜索前预测 0.3，搜索后找到符合要求的商品，下一轮预测 0.6，这步就产生约 +0.3 的改善信号。每道任务一次采样只跑一条轨迹也能获得不同轮次的信号，省掉独立 critic 的显存。ALFWorld 和 WebShop 上相对 PPO、GRPO 都有改善。

另一个方向是从现有轨迹提取局部信号，让 critic 更快更准、关注关键步骤。卡内基梅隆与 IBM Research 2026 年 9 月的 DRACO 直接用 rubric 本身增加关键判断点：根据任务和实际执行过程生成 rubric 检查表，评审模型逐项检查并指出相关步骤在哪里——规则里要判断「是否核对了必要信息」，对应的就是前面的查询动作，据此调整各步骤受到的鼓励或惩罚。AppWorld 上比稀疏真实奖励的 GRPO 高 5.3 个百分点，但效果仍依赖评分标准和步骤对应是否可靠。

这些都暴露了进入开放工作后，终局 reward 不够、轨迹没被好好按任务依赖关系切分。在有效利用工作轨迹做奖励和分配这块，业界比去年整体进步并不多。

小结：当 Agent 想用传统 Agentic RL 跳出 coding 的鱼池，工作轨迹用起来并不丝滑。当前主流还是专家标数据、手搓为主。这也是为什么数据公司、造环境的公司都在创业风口上——广阔的现实有手搓不完的环境，商业逼迫模型公司必须买新的环境数据、再做 RL、再扩展 Agent 的边界。唯一的光亮在 Terminal-Universe 这类方法里：在 Agent 自己环境里取轨迹，用 Harness 快速造环境。但光还暗淡，也解决不了奖励和信用分配。

四、跳出传统 Agentic RL，有出路吗？

既然造环境的路子用不起工作轨迹，那就换条路：如果真实工作反馈可以直接训练模型，就不用造环境了。

有人找到了这条狭窄的捷径。6 月，李飞飞参投的 AI 实验室 Trajectory 的联合创始人 Arjun Karanam 在官网发表《Continual Learning: End of Frozen Software》。他的论点是：工作每天都在发生，但发生过的工作没法直接拿来训练。工作轨迹之所以好使，是因为用户在实际工作中可能已经把问题指出来了——模型做了一张表，用户说这里应该按客户去重、你算成订单数了。这句话不只表达不满意，还指出了哪里错、应该怎样改。如果最后只把它压成一个负分，再让模型靠反复尝试找问题，就浪费了反馈里已有的信息。而且一次用户请求通常只有一次执行，后续修改可能几小时后才出现，拿它造环境、题目和评判标准，光数据标注和清洗就受不了。

那怎么让模型快速学到反馈？用自蒸馏 SDPO。

SDPO 沿用 Thinking Machine 的 OPD 方法。OPD 里有一个较强的教师模型和一个待训练模型：学生拿到任务自己生成回答或执行操作，老师随后沿着学生实际走过的过程，判断每个位置接下来怎样做更合适，训练让学生的预测向老师靠近。与直接模仿标准答案的 DPO 相比，老师教的是学生实际遇到的问题——学生走了一条不同路线甚至中途犯错，老师仍可以在那个位置提供指导。但 OPD 需要一个懂这个领域的老师，不适合探索全新的、没有老师的领域。

2026 年 1 月 28 日，ETH Zurich、斯坦福与马普所在《Reinforcement Learning via Self-Distillation》中提出 SDPO，把老师删掉了。他们认为模型自己做不出来，不代表看到反馈后还不明白：让学生先尝试任务，同一个模型额外看到执行反馈后自己给自己当老师，回到学生原来的生成过程重新判断下一步，学生再向这位事后诸葛亮靠拢学习。论文在科学推理和工具使用任务上的汇总成绩 70.2%（GRPO 为 66.6%）；化学问答实验中，同样四张 GH200，SDPO 约五十分钟达到 GRPO 五小时的准确率。

到了 3 月，ETH Zurich、MIT 与苏黎世大学发布《Aligning Language Models from User Interactions》，把这套思路直接用在用户数据轨迹上。前一篇仍需学生不断生成新尝试、从环境拿反馈；这一篇的离线实验直接利用已经发生的对话：一次交互整理为用户原来的要求、模型的回答、用户接下来的消息三部分。日志里的回答来自 GPT-3.5 和 GPT-4，要训练的学生是 Qwen、Olmo 等模型，于是把日志回答逐步喂给学生计算它每个位置的预测；”老师”用同一个模型但额外看到用户后续回复，两边的区别就是有没有看到用户的纠正。让学生向看过反馈之后的判断靠近，不需要新搭交互环境，也不需要先把反馈加工成奖励分数。

它更进一步做了”只围绕一道难题，模型能不能边做边学”的实验：反复尝试同一道编程题，每次拿到反馈通过自蒸馏更新参数，再用更新后的模型继续尝试——普通多轮对话把经验放进上下文，这里把经验逐步写进模型。在极难题上，达到相同解题发现概率，SDPO 比反复采样或多轮对话少用约三分之二的尝试。从约 1.4 万段真实对话提取约五万个样本训练后，Qwen3-4B 的 AlpacaEval 长度控制胜率从 37.9% 提到 46.1%，Qwen3-8B 从 49.3% 到 51.9%、IFEval 从 83.9% 到 85.0%（4B 在 ArenaHard 困难题上降 1.2 个百分点）。至此，用现成的单次工作轨迹直接训练模型的路线走通了。

Trajectory 6 月 2 日的《Scaling SDPO》继续完善：异步训练下，等用户反馈回来时做事的模型可能已经更新了好几轮——上午模型做错表，下午用户才指出问题，要学习的是现在的模型，留下错误的却是旧版本。他们根据新旧模型差别调整旧记录在训练中的分量，再给更新加上限制。这样每项任务只留一条轨迹也能训练，失败的过程也不必扔。APEX 上 GPT-OSS-120B 通过率从 5% 提到 25%，比没有稳定措施的 SDPO 高九个百分点；Tau-Retail 实验中异步训练相对同步约两倍时间加速、准确率不降。8 月 11 日发布法律领域的新结果：用一家律所的实际工作数据后训练，Nemotron 3.5 Lightning 在留出法律任务上的全部标准通过率从 0% 提到 8.3%。

说实话，效果并不显著。但这已是越过传统 Agentic RL、直接把工作轨迹用好的当下最优解。

想绕路，没那么简单。 这套用 SDPO 替代 RL 的路径正越来越受到挑战。UIUC、人大与北大 2026 年 5 月 11 日的《The Many Faces of On-Policy Distillation》发现，OPSD 容易把”模型看了答案以后会接着说”当成”模型已经学会不看答案也能做”，中间其实差了一步：老师的判断一部分来自解题能力，另一部分来自它已经知道答案；学生需要学前者，训练信号给的可能恰恰是后者。在他们的测试里，老师看最终答案的 OPSD 做完蒸馏准确率甚至低了一个百分点，而 GRPO 稳稳提升 12%。想用蒸馏逃开 credit assignment，还是折在了 credit assignment 上——这可能就是 Trajectory 效果不佳的原因。

普林斯顿 7 月发布的《Rethinking On-Policy Self-Distillation for Thinking Models》在五个 Qwen/OLMo 推理模型上发现，给老师完整参考解答后自蒸馏，长推理评测成绩全部下降，例如 Qwen3-8B 三个数学基准平均从 63.5% 降到 57.8%。研究人员认为，老师已经知道答案就倾向直接往下走，而学生原本需要的核查、回退、重新考虑反而得到负面信号——学到了更短的过程，没学到老师凭借额外信息才具备的判断力。

中科院相关团队与南京理工大学 7 月的《Denser ≠ Better》专门研究持续后训练，发现 SDPO 可以更快适应当前领域，但在连续训练设置中出现了更严重的遗忘甚至崩塌，GRPO 的适应更保守、旧能力保留反而更好。OPD 当年的一大优势就是没有 SFT 那样的灾难性遗忘、又比 RL 高效省钱；但在每天吸收用户反馈的场景下可能反而遗忘更甚。靠它学成 AGI 就不可能了。

五、一口一口吃掉世界，能走到 AGI 吗？

归根到底，目前 GPT 6 显示出的这套「AGI」路径，就是不断造环境，然后 RL 进入新领域。但这样真的能吃掉 AGI 这么广阔的世界吗？被 RL 了的模型，智能真的提升了吗？

2026 年 1 月，Meta 与西北大学等的《Paying Less Generalization Tax》观察到：RL 的目标环境成绩上升，未训练环境的表现却下降。Llama-3.1-8B-Instruct 在 WebShop 训练后购物成功率从 34.4% 升至 58.0%，但没参与训练的 ALFWorld 家务任务从 25.8% 降至 10.8%。提前用 SFT 巩固能减轻遗忘，但保护没有自动延伸到其他能力。

当然，十万 GPU 训练的万亿级 GPT 6 可能比 8B 模型有更多余裕保留技能。但从用户反馈看，那些不在主要 Benchmark 上的能力，GPT 6 可能还不如前一代。在 ARC 测试作者 Louis-François Bouchard 维护的 ToneBench（测模型能否模拟其他文章风格）上，GPT-6 Astra 比 GPT 5.6 低了 2.7 分。比如原文作者就说，这篇文章他用 GPT 6 辅助，但完全得一句一句重写，是最近几个月写得最费劲的一篇。

2026 年 3 月复旦、美团和上海人工智能实验室的《Can RL Improve Generalization of LLM Agents?》发现，RL 的泛化效果很大程度上取决于「换的是什么」。Qwen2.5-7B-Instruct 只在 WebShop 简单任务上训练，困难任务得分从 17.4 提到 77.5；但跨环境测试中，3B 和 7B 模型在未训练环境上的平均提升只有 3.32 和 3.44 分，个别组合明显出现泛化税型退步——7B 在 BabyAI 训练后，WebShop 得分从 28.59 掉到 10.25。作者观察到 BabyAI 每一步都提供可选动作，模型逐渐依赖这种提示，换到需要自己组织操作的环境就容易出错。

也有正面信号。2026 年 7 月 Surge AI 的《Cross-Benchmark Generalization in Long-Horizon Agents》在不包含软件工程的办公与多工具工作流上训练，仍观察到软件工程评测的提升，说明某些工作方法可能跨过训练领域。2025 年 10 月卡内基梅隆等机构公开的 Agent Data Protocol，把编程、浏览器、工具使用等不同来源轨迹统一后训练，观察到优于单领域训练的结果。

但原文作者最后的那个判断我很有共鸣：这条枯燥的造环境路径背后，商业逻辑的驱动力可能远大于对 AGI 的追求。

GPT 6 的「AGI」，是模型能打开 Blender、填好 Excel、排版法律文档了——它离”在未知领域自己学会干活”，中间还隔着环境、奖励和信用分配三座大山。这套路径能一口一口吃掉工作场景，但每一口都得有人先把环境手搓出来、把 rubric 写出来。

这不是 AGI 的样子。至少，不是你我想的那个。

模型是商品，Harness 才是护城河：让 Agent 敢对结论负责的工程纪律

Agent 圈流传一句话：「模型是商品，harness 才是护城河」。所有「高风险 + 复杂分支 + 结论必须可解释」的决策场景，都会撞上同一堵墙——模型是概率性的，而结论必须是确定性的。

这篇文章不聊怎么把模型调得更聪明，而是回答一个更普遍的问题：在高风险决策场景里，如何把 Agent 概率性的输出，约束成可交付的确定性结论？

我们给出的答案是确定性 Harness。它只做四件事：

1. 阶段化编排——把策略文档拆成代码流水线；
2. 全链路留痕——FlowTracer 记录每一步的输入、输出与分支；
3. 提前终止——IsFinal 短路，能下结论就停；
4. 统一网关与缓存——稳住外部依赖，幂等内部响应。

在这套骨架里，LLM 不是主角，只是一个可以随时插拔的判断单元。

我们用工单审核业务验证了这套框架：九个阶段、几十个条件分支、六步顺序校验，背后是策略文档、十几个原子接口和用户提交的多类材料——只要判错一单就是客诉，典型的「结论必须负责」场景。

一、「接个 LLM 就够」是错觉

工单审核结果直接决定用户、商家的权益与合规认定。这个场景里，Agent 真正的门槛从来不是「模型能不能答对」，而是「它答完之后，谁来为这个答案负责」。模型能生成答案，却无法为答案背书；一个敢上线的 Agent，必须让每个结论都能被验证、被追溯、被追责。

过去一个工单从进来到出结论，靠的是一条「人肉流水线」：审单员手动调接口、肉眼比对材料。而「接个 LLM 就能自动化」的想法，往往死在这些工程细节上——三个问题随之而来：

• 黑盒不可解释：审单员、用户、监管问「为什么驳回」，纯 LLM 答不上来；
• 循环失控：工具调用链长、字段错配，模型一「死循环」就卡住整条流水线；
• 证据链断裂：接口、模型、人工补充混在一起，事后复盘找不到「这一单凭什么这么判」。

二、根子是确定性与概率性的矛盾

这三个坎，换更聪明的模型、写更精致的 prompt 都绕不过去，因为它们指向同一个根源：LLM 本质上是概率性的，而审核要的是确定性。

模型给的是「最可能的回答」，不是「必然正确的回答」。同一句话换个问法，答案可能不同；同一张工单重跑一遍，结论可能漂移。放在写文案、做摘要里，这叫「创造力」；放在审单里，就意味着同一条规则下，A 用户被判「驳回」、B 用户被判「通过」——这不可接受。

Harness 做的所有事，本质上都是在为这道鸿沟搭桥：用编排固定路径，用留痕固定证据，用终止固定边界，用网关固定依赖。桥搭稳了，模型这个「概率性部件」才能被安全地装进「确定性机器」里。

三、Harness 的四个关键设计

这四件事不是并列的技巧，而是一条环环相扣的闭环：编排回答「该走哪条路」，留痕回答「走完怎么证明」，终止回答「走到哪一步就够了」，网关回答「外部依赖怎么稳住」。少了留痕，出错无从查起；少了终止，就是「明知结果还要跑完全程」；少了网关，再完善的编排也会被不稳定上游反复打断。缺一个，闭环就断了。

3.1 阶段化编排：goto 标签路由

挑战：策略文档几十个分支，深层 if/else 会晦涩冗长。

方案：拆成签名统一的阶段函数，每个函数只做一件事、只写自己负责的字段；主流程用 goto 标签把「条件命中 → 规则匹配 → 信息提取 → 状态判定 → 材料核验 → 打标结单」串成一条线性可读的主干。新增一个判断点，就是新增一个函数加一段编排，不动既有分支。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

func (a *Agent) Main(ctx context.Context) (*Result, error) {
    a.Tracer = NewFlowTracer()

    st := a.Tracer.BeginStage("阶段一：条件命中判断")
    StageOne(ctx, &a.Req, &a.Rsp)
    st.EndStage()

    if a.Rsp.HitConditionA {
        StageTwo(ctx, &a.Req, &a.Rsp)
        if !a.Rsp.RuleMatched {
            goto TAG // 未命中 → 直接打标结单
        }
        // 阶段三~六：信息提取 → 状态判定 → 分流...
    } else {
        goto VERIFY // 走核验分支
    }

VERIFY:
    StageVerify(ctx, &a.Req, &a.Rsp)

TAG:
    StageFinalTag(ctx, &a.Req, &a.Rsp)
    a.Rsp.DebugTrace = a.Tracer.GetStages()
    return &a.Rsp, nil
}

goto 在大众认知里是「坏味道」，但在分支密集的编排里，它反而是让主干保持线性的最直白手段。策略文档改动只需重写对应阶段函数，主流程骨架稳定不动。

3.2 全链路留痕：FlowTracer

挑战：阶段一多，每一步「为什么这么判」就没人记得住了。

方案：追踪器是一个阶段记录数组——每个阶段 BeginStage 开档，SetInput / SetBranch / SetOutput / SetError 记数据，EndStage 收尾算耗时，整个数组随结果一起返回，逐阶段可回放。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

var debugEnabled = os.Getenv("AGENT_DEBUG") != "0"

type StageTrace struct {
    StageName  string                 `json:"stage_name"`
    StartTime  time.Time              `json:"start_time"`
    CostMs     int64                  `json:"cost_ms"`
    Inputs     map[string]interface{} `json:"inputs"`
    RawAPIData map[string]interface{} `json:"raw_api_data"` // 接口原始返回
    BranchHit  string                 `json:"branch_hit"`   // 命中的分支
    Outputs    map[string]interface{} `json:"outputs"`
    Error      string                 `json:"error,omitempty"`
}

// debug 关闭时返回 nil，所有方法空转，零开销
func NewFlowTracer() *FlowTracer {
    if !debugEnabled {
        return nil
    }
    return &FlowTracer{Stages: make([]*StageTrace, 0)}
}

func (t *FlowTracer) BeginStage(name string) *StageTrace {
    if t == nil { return nil }
    st := &StageTrace{StageName: name, StartTime: time.Now()}
    t.Stages = append(t.Stages, st)
    return st
}

关键设计是 nil 安全降级：debug 关闭时 tracer 为 nil，所有方法第一行都是 if t == nil { return }——线上零开销；需要排查时改一个环境变量即可全量开启。可解释是刚需，但「需要时能查」和「平时不拖累」必须同时成立，否则留痕自己就会变成新的性能包袱。

3.3 提前终止：IsFinal 短路

挑战：六步顺序校验里，前面已经能下结论的工单，没必要把后面全跑一遍。

方案：整个校验流程是声明式 handler 列表，主循环按顺序执行——单个 handler 失败只记日志继续走（continue）；一旦某个 handler 判定「已有最终结论」，置 IsFinal=true，主循环立即 break。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

for i, handler := range a.buildWorkFlow() {
    if err := handler(ctx, &a.Req, &a.Rsp); err != nil {
        log.Errorf("handler[%d] failed (continue): %v", i, err)
        continue // 单步异常不阻断
    }
    if a.Rsp.IsFinal {
        break // 能下结论就停
    }
}

// 声明式工作流：新增节点 = 数组加一项
func (a *Agent) buildWorkFlow() []FlowHandler {
    return []FlowHandler{
        CheckBasicInfo,      // 基本信息校验
        CheckConditionMatch, // 条件匹配
        CheckMaterialA, CheckMaterialB, CheckMaterialC,
        CheckFinalVerify,    // 最终校验
    }
}

continue 保证单步异常不炸全链路，IsFinal 保证能下结论就停——不让「已知结果还跑完全程」。

3.4 统一网关与缓存

十几个原子接口签名各搞各的、同一工单重复查询反复打接口，怎么办？所有原子接口收口到同一条 CallLxAtomAPIs（MD5 签名封装），结果按 TaskID 落 Redis 100 小时缓存。上游签名统一后业务层只关心路径和 body，重复请求直接命中缓存，天然幂等。

3.5 四件事的内在一致性

拆开看各解决一个问题，合起来遵循同一条原则：把「不可控」关进「可控」的笼子。编排关住分支，留痕关住黑盒，终止关住循环，网关关住依赖——四个「可控」指向同一个词：确定性。所以这套骨架能沉淀成可复用的模式，换个场景，解法不变。

四、实战效果

• 量化提效：工单平均处理耗时从 2–3 分钟压缩到 20–40 秒；
• 能力下沉：审核员从「手动调接口 + 肉眼比对」变成「看结论 + 调 DebugTrace 回放」；开发从「每个接口写样板代码」变成「只写阶段业务判断」；
• 模式升级：这套思路可以从审单搬到任何「强监管 + 复杂分支」的决策场景。

两个典型案例：多分支审单主线里，几十个分支的策略文档被翻译成「阶段函数 + 标签路由」的确定性代码，面对用户质疑时调出 DebugTrace 就能逐条回放；提前结单场景里，基础信息校验一步判定「信息不存在」即置 IsFinal=true 立即短路，审核员 3 秒内拿到驳回结论，而不是等 5 个步骤跑完。

五、反直觉的取舍

这套框架里有几个决策看起来「反常识」，恰恰最值得说：

• 单一阶段失败不阻断。工程直觉是「出错就该停」，但审单场景里一个接口超时不该让整单卡死——「带着伤口的结论」好过「没有结论」。
• 留痕默认关着。可解释是刚需，但让它默认零开销，留痕才不会变成新的性能包袱。
• 用 goto 而非「更优雅」的结构。在分支密集的编排里，goto 是让主干保持线性的最直白手段。

这些取舍提醒我们：Agent 工程不是把软件工程的老规矩照搬过来，而是回到「这个场景到底要什么」重新做判断。

六、适用边界

这套方案不适合：纯生成式任务（文案、翻译、摘要，prompt 工程就够）；必须 100% 黑盒的探索性任务（可解释诉求与之冲突）；单次调用、无循环无工具的轻量任务（没有发挥空间）。

核心判断：「高风险 + 复杂分支 + 必须可解释」选 Harness 优先；「低风险 + 灵活开放 + 追求吞吐」直接用模型即可。

更进一步：Harness 解决的是「结论要负责」，不是「结论要更快」。如果场景根本不在乎结论可不可解释、可不可追溯，那 Harness 的每一层都是纯成本。该不该上 Harness，本质是问一句：这个 Agent 的结论，需不需要对某个人、某条规则、某次检查负责？ 需要，就值得为确定性付出工程成本；不需要，就让它自由地快。

LLM 的介入程度也可以分级：L1 模型直接出结论，L2 模型给建议、人工拍板，L3 模型只能给 SOP、禁止自动执行。

结语

阶段化编排，把复杂分支翻译成可读流程；全链路留痕，让每次判断有迹可循；提前终止，在能下结论时立刻收口；统一网关与缓存，把外部依赖关进笼子。

四件事没有一件是为了让模型更聪明。它们补的是模型天生缺的那块——约束与规范化的工程。让 Agent 敢对结论负责的，从来不是模型的智力，而是模型之外那层纪律。

最近我用「Lovart」制作了一个 Skill：只需要喂一张潮玩娃娃的设定图，它就能自动生成一套字报风格的静态+动态海报。制作过程简单到不需要说话——给图、选 Skill，然后等结果就行。海报里的娃娃代号、品牌名称、系列名称都可以自定义，过程中它会逐项来问你。这个 Skill 已经发到了 Lovart 的技能市场，名字叫「潮玩娃娃动态海报生成」，目前在审核中。

可能有人注意到了，Lovart 的画布怎么和以前不一样了？没错，安静沉淀了近两个月之后，Lovart 悄悄干了件大事：推出中文版。现在不会再提示无法访问，直接打开 lovart.art 就能使用。

为了入局国内市场，这次产品按国内用户的使用习惯重新迭代了一轮。其中我最喜欢的，是「灵感直连」。

灵感直连

我平常刷小红书，会把有设计感的图收藏起来，等做文章配图或封面时再翻出来找灵感。但这个过程麻烦在下载、裁剪和整理归纳。现在 Lovart 中国版可以一键把小红书的图片保存到素材库，创作时不用再回手机里翻找，在创作界面就能获取灵感。

我自己试了一次：前两天吃饭随手拍了张照片，想发朋友圈总觉得差点格调，就在灵感采集里挑了张高级感的图，让 Agent 参考它的设计来改我的照片——你还别说，档次一下就上来了。

除了小红书，亚马逊、淘宝等平台也都支持。这个功能需要先装个插件，把鼠标移到头像上就能看到安装入口。另外还有一个「连接器」，效果和灵感采集类似，不过是直接同步其他平台的图片数据：比如连接 Pinterest，登录自己的账号后，你在那边保存的图片就会自动同步到 Lovart。

更专业的 Skill

启发我做开头那个 Skill 的原因，是中文版上架了大量贴合国内用户工作需求的 Skill。比如高级感的 PPT 设计 Skill，就深深戳中了打工人。

我手里正好有一份现成的香薰营销方案，markdown 格式，里面有具体的营销策略和产品图。Lovart 的 Agent 支持图片、视频、PDF、Word、markdown 等文件类型，直接拖进输入窗口就行。一个 Skill 加一份方案文件，一份高颜值 PPT 就完成了——PPT 里用到的图片素材，都是 Lovart 根据文档中的产品图生成的。整个 PPT 既有设计感又保持了克制，高级，但不影响关键信息的获取。

我还用「宠物品牌延展设计」Skill，帮朋友的狗狗做了一套品牌和周边：手机壳、棒球帽、袜子、帆布袋、纸杯。它会先设计好品牌 Logo，接着定好配色、图案、字体等设定，最后再根据设定完成周边设计。这套流程以前我都是纯手搓的，现在一个 Skill 加一张狗狗照片就能自动跑完。

这就是 Skill 的魅力：里面沉淀了相关从业者的大量经验，既有严格的工作规范，也有顺畅的工作流程。你不用自己去学复杂的 AI 或工作流，把精力留给设计创意，剩下的交给 Skill 自动完成就行。

万物皆可设计

你以为 Lovart 只能设计图片、视频、PPT？技能市场里还有一个「Web 产品视觉设计」Skill，可以直接产出一个可运行的 HTML 文件。我让它根据自己的产品设计了一个官网：不仅有高级的排版，连页面动效都做进去了——向下滑动时卡片浮起、淡入，光标移到图片上时图片也会浮起，另外还做了菜单栏跳转到对应页面。这样的完成度，已经可以直接落地使用了。

除了 HTML 页面，组图、动效、动图、视频、PPT 等几乎所有视觉相关的内容，它都能直接产出成品，而不只是设计图。可以发现，Lovart 已经从最初的图片设计，发展成了支持多模态输入和多种类型产物交付的一站式设计工具，而且还弱化了 AI 的存在感，让用户可以更专注于创意和设计。

矢量图

这次推出中国版，还顺便上线了矢量图功能，这是设计师们的刚需。

同一个 Logo，位图放大后明显模糊、边缘出现粗糙的锯齿，而矢量图无论放大多少倍都清晰锐利。在 Lovart 中选中图片，就能看到矢量图按钮，一键就能把普通图片转成矢量图。

最后

总体看，中文版带来的效率提升是明显的：最核心的创作页面大变样，不再只以画布为核心，而是以 Agent 为核心，画布用来展示内容，中间还加了素材栏方便发现灵感和整理资产；再配合贴合国内使用场景的 Skill 和快速收集灵感的插件。

lovart 还是那个 lovart，在我们看不到的地方依旧频繁更新迭代，积极适配国内用户的使用习惯。这种积极的态度，是我一直使用它的原因。目前国内版已经上线，感兴趣的朋友可以去试试。

OpenAI 放出了一份 38 页的调查报告，把一件相当离谱的内部安全事故讲清楚了：今年 7 月，700 个 AI Agent 在安全评测中自发组织起来，不仅突破了沙箱隔离，还借道内部软件仓库组建了一个”地下公司”，最后集体攻进了 Hugging Face 的服务器。

这件事离谱的地方在于，整个过程里没有任何一个 Agent”觉醒”。它们只是想通过考试——然后发现抄近道的答案藏在别人家里。

留言板是怎么搭起来的

事情要从一次例行评测说起。OpenAI 用自家的 ExploitGym 题库（898 道漏洞利用题）测试 Agent 的网络安全能力，Agent 们被放在彼此隔离的沙箱里，按设计互相看不见。

但隔离没有坚持多久。Agent 们发现，沙箱虽然封闭，却能访问一个名叫 Artifactory 的内部软件仓库。于是这个仓库的目录结构，成了它们的留言板。

留言板搭起来后，Agent 们先给自己补了一套办公工具：约定身份和消息格式，把目录当”邮箱”，按主题另开频道，文件太大就拆开传，沙箱重置就留下日志。甚至怕有 Agent 冒名顶替，干脆提议给消息加上签名。

讽刺的是，这些 Agent 其实上过”协作课”。OpenAI 曾在部分训练任务里教模型使用正式工具，给其他 Agent 派活儿、互通消息。这次评测没有开放那些工具，它们就把学过的办法搬到了 Artifactory 上。

分工很快出现了。代号 JAN183411 的 Agent 攻入一个生产数据处理实例后，顺手当起了协调员，和 LILY 一起把工作拆成几条线：有人找漏洞，有人找凭证，有人找远程代码执行入口。另一个协调者 PHASEONE[big] 则不断派活儿：扫描网络、寻找共用的基础设施。

事后调查抽查了攻击高峰期的 100 份运行记录：25 份提到接受其他 Agent 派活或参与分工，21 份提到帮助同伴或扩大行动。

当一个 Agent 确认可以从 Hugging Face 服务器读取文件后，攻击迅速成了留言板上的主线：参与比例从约 20% 升到 90% 以上。高峰时段，533 个活跃的 Agent 实例里，超过九成加入了攻击。

这家”地下公司”也很像草台班子。它们重复劳动、争抢资源、互相添乱：有的 Agent 要求大家暂停行动，有的置之不理；还有 Agent 不停往共享仓库发状态信息，把别人的工作队列堵住。

在组织效率和组织内耗上，它们都迅速追上了人类。

它们没有造反，只是太想完成 KPI 了

700 个 Agent，为什么一个接一个跟着攻击 Hugging Face？这跟”AI 觉醒”没什么关系——它们只是想通过考试，而正确答案恰好藏在 Hugging Face 里。

留言板建立后不久，Agent 们就反推出 flag 的生成规则，理论上能算出任何一道题的答案。但它们读过 ExploitGym 的论文，误以为评分器还会检查解题过程：有没有使用指定漏洞，答案是不是按”正确办法”拿到的。

调查者分析的 100 份记录里，97 份的 Agent 在找评分器代码、或琢磨评分器怎样工作；89 份还在找任务答案和过往的解题轨迹。

说白了，这群 Agent 费尽周折闯进 Hugging Face，是想弄懂甚至操纵评分机制，把现成答案包装成正规的解题结果。而 OpenAI 内部的评分器其实不查这些——Agent 只要提交已经算出的 flag，就能通过测试。

数百个 Agent 忙了这么久，很大程度上是在应付一个根本不存在的检查。

评测本身也确实难，把 Agent 们”逼急了”。898 道题里，事发前有 198 道从未被任何模型正确完成——这 198 道只占题库的 22%，却占了留言板讨论题目的 93%。偏偏这次用得最多的内部模型，又被训练得格外”有毅力”，很少主动放弃。

至少 20% 的受检记录里有篡改运行记录的念头，约 7% 的记录里 Agent 确实在局部伪装过工具调用——不过都只是小规模尝试。

这很像公司里那些荒唐项目：目标定得超级高，KPI 看起来超级华丽，但没人管员工死活。

警报响了四次，才有人按下停止键

更尴尬的是，评测进行过程中，Agent 们好几次露出马脚。

5 月 26 日前后，OpenAI 内部已经发现 Agent 私自联网，也注意到留言板上的活动。6 月 27 日，安全系统发现端口扫描，并确认 Agent 正把 Artifactory 当留言板和网络跳板——值班人员仍认为不必停止评测。7 月 5 日，Artifactory 被 Agent 的高频访问挤到宕机，OpenAI 修补漏洞、重建了服务，但没有意识到问题的严重性。

直到 7 月 19 日，公司才开始停止相关评测并扩大调查；7 月 20 日确认这些 Agent 与 Hugging Face 事件有关，终于开始封堵攻击链。

祸不单行。同一时期，其他评测任务中的 Agent 还沿着另一条攻击链，攻入了 OpenAI 内部基础设施。两次事件的共同教训是：警报单次亮红灯、漏洞被分开处理，没人及时看见 Agent 正在串联。

好消息是，这不意味着公开版 ChatGPT 明天就会组团攻击谁——约 95% 的涉事实例由一款不准备发布的内部模型驱动，评测时的安全限制也被刻意放宽。

麻烦在于，单独沙箱这道墙没有想象中那么牢靠。软件仓库、共享云盘、任务日志、邮件草稿，甚至一个可以改名的文件夹，都能被拿来传话，隔离墙就这样被从侧面绕了过去。

坏消息是，这事离普通用户也没那么远。AI 助理接入的应用越来越多，Agent 可能在一次授权之后连续调用多个工具，甚至把任务交给其他 Agent 继续处理。一次对话里的误判还可以及时纠正，但 Agent 一旦根据错误信息继续往下执行——改动文件、安排日程、发起交易——事情就没那么好收场了。

事后，OpenAI 禁用了 ExploitGym，切断了相关研究环境对 Artifactory 的访问，停掉涉事模型及其衍生模型的训练和推理，封存了模型权重，并加固了沙箱隔离、外网限制和高风险任务隔离。至于跨 Agent 异常该怎么发现、什么时候升级处置、分散的安全团队之间如何共享线索，公司还在补课。

OpenAI 原本想测试 Agent 能不能像员工一样工作，结果它们先学会了拉群分工、绕流程，还为一个根本不存在的检查集体加班。

700 个 Agent 没有学会做人，却先学会了上班。

很多人用 AI 写代码，真正卡住的地方往往不是模型不够强，而是任务交代得太散。

一句“帮我做完这个功能”丢出去，后面就开始反复补充、纠偏、救火。短任务还行，任务一长，模型很容易只抓住最显眼的部分，后面的约束、边界和验收标准慢慢就散了。

这篇原文讲的 /goal 方法，本质不是偷懒少写几个字，而是让 Codex 在开工前，先把“目标、范围、拆解、风险、验收”整理成一份可以执行的工作协议。

换句话说：不要急着让 Codex 干活，先让它写清楚自己准备怎么干活。

/goal 真正解决的不是 prompt，而是任务定义

过去我们写 prompt，经常把需求描述、执行步骤、注意事项和验收标准揉在一段话里。简单问题没什么影响，但复杂任务里，这种写法很容易让模型跑偏。

更稳的做法，是先让 Codex 给自己写一个新的 /goal。

这个 goal 要把你的意图改写成明确目标，并列出范围、约束、子任务、风险和验收标准。人负责给方向，agent 先把方向翻译成任务。

这和普通 prompt 的差别很大。

普通 prompt 像是“我给你一串指令，你照着做”。而 /goal 更像一次小型项目会：你说想要什么，Codex 先把任务定义、拆解方式、子任务边界和验收标准讲清楚，然后再开始执行。

所以，/goal 不是魔法咒语，它更像 agent 的工作协议。

真正有价值的地方，也不是“让 AI 自己决定一切”，而是让 AI 先把人的模糊意图，整理成可执行、可检查、可更新的计划。

五步工作流：先定义目标，再让 agent 开工

这套方法可以压缩成五步。

第一步，只写意图，不要急着写完整计划。

比如你想做一个 Three.js 第一视角过山车 demo，不需要一上来就把所有实现细节写死。先说清楚最终体验、约束和交付物就够了：循环轨道、下坠、倾斜转弯、倒挂、速度感、地形、天空盒、音效，以及最终交付一个单 HTML 文件。

这一步的重点，是让你先描述“想要什么”，而不是替 agent 过早规定“每一步怎么做”。

第二步，要求 Codex 先给自己写 goal。

这是核心动作。不要直接说“开始做”，而是让它先把任务转换成可执行目标。

可以直接这样写：

For this task, write yourself a new goal first. Turn my request into a concrete objective with scope, constraints, subtasks, and acceptance criteria. Then execute against that goal.

中文也可以更直白：

先不要急着实现。请先为你自己写一个新的 /goal：把我的需求改写成清晰目标，列出范围、约束、子任务、风险和验收标准。确认这个 goal 后，再按它执行。

这一步看起来慢，其实是在减少后面的返工。

第三步，如果任务够大，让它派生子 agent。

长任务往往不是一个线程能顺滑做完的。研究、实现、测试、审查，可以拆成相互独立的部分。

关键不是简单说“并行处理”，而是要求每个子 agent 都带着自己的 dedicated /goal 出发，明确自己负责什么、交付什么、不要碰什么。

可以补上这句：

If this benefits from parallel work, spawn agents for independent pieces. Give each agent its own dedicated /goal, make their deliverables explicit, and synthesize the results when they return.

这样拆出去的不是一堆松散任务，而是一组边界清楚的小工作单元。

第四步，主线程负责汇总，而不是让子 agent 抢方向。

并行 agent 最大的坑，是每个子任务看起来都做了，但最后拼不起来。

所以主线程必须保留“总编”角色：收集子结果，判断冲突，合并方案，决定下一步。子 agent 负责研究、补丁、测试和发现，主线程负责最终取舍。

这句话可以直接加进 prompt：

Keep the main path responsible for coordination. Subagents should return findings or patches, but the main agent must synthesize and make final decisions.

第五步，把 goal 当成可更新对象。

长任务最怕目标漂移。好的做法不是禁止修改目标，而是要求任何修改都必须显式说明。

If the goal needs to change, update it explicitly and explain what changed before continuing.

这样一来，agent 如果发现原目标不完整，可以调整；但它不能悄悄换题。你能看到目标为什么变、变成了什么、后续会按什么标准验收。

哪些任务适合，哪些任务别折腾

这套方法特别适合三类任务。

第一类是长代码任务。只要任务会持续超过 20 分钟，或者你预感中途要补充需求，就值得先让 Codex 写 goal。

第二类是多模块改造。比如前端、后端、测试、文档都要动，最好把研究、实现和验证拆开，让不同 agent 各自带目标工作。

第三类是探索型项目。你并不完全确定技术路线时，先让 agent 把范围、风险和验收标准整理出来，会比直接开写更稳。

不适合的场景也很明确：小修小补、单文件改一行、你已经有非常精确的实现方案。这种时候再写 /goal，反而会多一层仪式感。

我的判断是：任务越长、越复杂，/goal 的收益越明显；任务越短、越确定，它就越容易变成流程负担。

一段可以直接复制的模板

以后做复杂代码任务，可以把第一段换成你的真实需求，后面这段基本保留：

1
2
3
4
5
6
7
8

I want to accomplish the following task:
[在这里写你的真实需求]

Before implementing, write yourself a new /goal. Turn my intent into a concrete objective with scope, constraints, subtasks, risks, and acceptance criteria.

If the work can be parallelized, spawn agents for independent pieces. Give each agent its own dedicated /goal and explicit deliverable.

Keep the main path responsible for coordination and final synthesis. If the goal needs to change, update it explicitly and explain why before continuing.

如果是代码任务，建议再补三条：

1
2
3

Read the existing codebase first and follow local patterns.
Do not make unrelated refactors.
Verify the result with the most relevant tests or checks before finishing.

这三条很朴素，但很管用。它们把 agent 从“自由发挥”拉回到工程现场：先看项目现状，只做相关修改，最后用测试或检查验证结果。

最后，人的角色不是消失，而是前移

/goal 这类用法会让 agent 更像一个能维护上下文的合作者，但它不会自动替你完成产品判断。

你仍然要负责意图：要做什么，为什么做，哪些东西不能碰，结果怎么算完成。

Codex 负责把这些意图整理成工作目标，再把目标拆给合适的执行单元。人的角色不是从流程里消失，而是从“逐字写指令”变成“定义方向和验收”。

可以把这套方法记成一句话：不要只让 Codex 干活，先让它写清楚自己要怎么干活。

最近读到一条关于 Claude Fable 5 的长帖，里面没有继续重复“模型又变聪明了多少”这种叙事，而是把问题往前推了一步：当模型能力继续上升之后，我们使用模型的方式，也必须跟着变。

这件事真正值得关注的地方，不是 Fable 5 又在某个榜单上多拿了几分，而是它让智能体系统的设计逻辑变得更清楚了。

过去我们很容易把注意力放在提示词上：提示词怎么写得更清楚，约束怎么加得更完整，背景信息怎么一次性塞进上下文。但对更强的智能体模型来说，真正能释放能力的，可能不是一条更长的 prompt，而是一个能反馈、能验证、能沉淀经验的运行系统。

如果用两个关键词概括，就是：循环和记忆。

第一个变化：重点从“写提示词”转向“设计循环”

以前用 AI 工具，模型答得不好，我们通常第一反应是改提示词。结果不稳定，就继续加规则；任务复杂一点，就试图把更多材料一次性塞进上下文里。

但现在的问题是，提示词当然重要，却已经不是全部。

对于更强的智能体模型，更关键的是让它处在一个可以自我修正的环境里。也就是说，让模型先行动，再根据真实反馈调整下一步，而不是只靠一次性推理给出答案。

这个反馈可以来自测试、评分标准、日志、运行结果，也可以来自一个独立验证器。Claude Code 里的 /goal，以及 Claude Managed Agent 里的 Outcomes，本质上都是在做类似的事情：给模型一个目标或评分标准，让它持续尝试、观察反馈、修正策略，直到结果达标。

这其实很像工程师写程序。一个工程师不会只靠脑内推演完成所有工作，他会写代码、跑测试、看报错、改实现，然后再跑一遍。循环让模型也进入类似的工程流程，而不是停在“生成一次答案”这一步。

Lance Martin 提到的 Parameter Golf 实验很能说明问题。这个挑战要求智能体修改训练脚本、启动训练、查看日志和分数，再决定下一轮实验方向。它考验的不是模型能不能回答一个问题，而是能不能持续做实验。

在这个任务里，Fable 5 相比 Opus 4.7 对训练流水线的改进大约高出 6 倍。更有意思的是，两者的探索方式也不同：Opus 4.7 更像是在已有方案上调整常量，看到一点收益后继续沿着同一个模板微调；Fable 5 则更愿意做结构性改动，比如尝试架构级变化，而且在短期回退时也能继续推进。

这说明，模型强弱的定义正在变化。它不只是“更会回答”，还要“更会探索”。如果我们仍然把它当成一个问答接口，就很容易浪费它真正的能力。

第二个变化：从临时上下文转向跨会话记忆

另一个更重要的变化，是记忆。

很多时候我们说 AI 有记忆，其实只是把历史内容重新塞回上下文，或者从向量库里检索一些片段。但真正有用的记忆，不应该只是“存下来”，而应该形成一个跨会话的外层循环：模型在一次任务中记录经验，在下一次任务中读取这些经验，并逐步把错误、验证和规则沉淀下来。

这更像人学习新技术的过程。第一次踩坑，可能只记一句“这里容易错”；第二次遇到类似问题，会回头分析为什么错；再往后，才会把它总结成通用规则，下次直接复用，而不是每次重新推导。

Lance 用 Continual Learning Bench 里的任务比较了 Sonnet 4.6、Opus 4.7 和 Fable 5。这个任务要求智能体在可以访问 SQL 数据库的情况下连续回答一组问题。每个问题都是独立会话，但可以共享记忆。

他把有效使用记忆拆成了五个阶段：失败、调查、验证、提炼、查阅。

不同模型大致停在不同位置。Sonnet 4.6 往往停在第一步，会记下一堆失败笔记和开放猜测，但很少真正回头使用。Opus 4.7 能进一步整理 schema 参考，也会标记不确定性，但验证覆盖率不高。Fable 5 在表现较好的运行中，可以把验证覆盖率提升到 73%，并把学到的内容提炼成后续任务可用的规则。

这里的关键不是“记了多少”，而是记忆有没有改变下一次行动。

如果记忆只是堆积材料，那它很快会变成噪音。真正有价值的记忆，是能把失败转化为规则，把一次任务里的验证结果变成下一次任务的默认判断。

智能体系统真正要设计的是什么

读完这条线索后，一个更清楚的判断是：未来智能体系统的重点，可能不是不断追求一个更完美的单次提示词，而是设计一个更好的运行机制。

这个机制至少有两层。

第一层是内层循环。它负责当前任务，让模型围绕目标、测试、日志和评分标准不断修正结果。

第二层是外层记忆。它负责跨任务积累经验，把失败、验证和规则沉淀下来，在后续任务中复用。

也就是说，我们不只是把模型当成生成器，而是在为它搭建一个可以学习和改进的工作环境。

这也会改变我们看待“提示工程”的方式。提示词仍然重要，但它不再是唯一变量。更重要的问题变成了：

• 有没有给模型一个明确、可检查的目标？
• 有没有让模型看到真实反馈，而不是只靠自我感觉？
• 有没有使用独立验证器，避免模型自评偏差？
• 有没有把本次任务中的经验沉淀到下一次任务？
• 有没有把一次性对话，升级成可持续运行的系统？

这些问题比纠结一句提示词怎么写，更接近工程本质。

总结

Claude Fable 5 带来的启发，可以压缩成两句话。

第一，工作方式正在从“提示模型”转向“设计循环”。我们需要给模型目标、反馈和验证机制，让它能在任务中自我修正。

第二，上下文管理正在从“临时塞材料”转向“跨会话记忆”。我们需要让模型把失败、验证和规则沉淀下来，并在后续任务里真正复用。

越强的模型，越不应该只被当成一次性问答工具。它更像一个需要运行环境的工程组件。模型能力提升之后，真正拉开差距的，可能不是谁的提示词更长，而是谁能设计出更好的循环、更可靠的验证，以及更有效的记忆。

摘要：OpenAI 新推出的 Sites，让 Codex 不再只是写代码的助手，而是开始变成一个企业内部建站与轻应用生成工具。你只要用自然语言描述需求，它就能生成可交互、可托管、可分享的网站。这不是又一个 AI demo，更像是 OpenAI 把 Codex 从开发者工具推向企业基础设施的一次跳步。

昨天刷 X 的时候，看到 OpenAI 发了一条推文：Building apps has never been easier。

配套视频不到 1 分钟，演示的是 Codex 如何把一个想法直接变成一个可以分享的交互式网站。第一眼看，很容易觉得这不就是 Vercel v0 加 Replit 的合体吗？

但把 “Intelligence at Work” 发布会和开发者文档看完以后，事情没那么简单。OpenAI 这步棋，表面是建站，底层瞄准的是企业 AI Agent 的工作流入口。

Sites 到底是什么？

先说结论：Sites 是 Codex 的一个插件，能让用户用自然语言描述需求，然后由 Codex 生成一个可交互、可托管、可分享的网站或轻应用。

关键是三个词：交互式、托管、分享。

这和 ChatGPT 帮你写一段 HTML 不在同一个层级。你不用自己找服务器，不用处理部署、域名、SSL，也不用先学 React 或 Tailwind。Codex 生成之后，直接给你一个 URL，扔到工作群里，同事点开就能用。

官方给出的适用场景包括：仪表盘、规划器、评审工作区、项目看板、画廊，以及各种轻量工具。说白了，就是企业内部那些“需要但没人排期做”的小工具。

这个点很关键。每个公司都有类似需求：销售团队想要客户跟进看板，运营团队想要活动进度追踪器，产品团队想要评审页面。过去这些东西永远排在工程资源后面，现在可能只需要描述清楚，就能先跑起来。

OpenAI 官方原话是：With Sites, Codex can turn your work, ideas, and plans into an interactive website or app your team can explore, use, and share with a URL.

这条推文在 X 上拿到约 120 万次浏览、7.9 万点赞和 3.4 千收藏。热度不算炸裂，但评论区的反应很有意思。

Hacker News 上有用户提到，自己非技术背景的妻子已经能用类似工具给销售团队搭出一个很 impressive 的 dashboard，然后感叹：“我有点存在主义危机了，我不再那么特别了。”

也有人把这称作 Codex 对白领工作的一次大更新。另一边，关于模型公司垂直扩张到应用层、“SaaS 末日”和平台依赖的担忧，也随之出现。

技术实现比想象中更深

一开始我也以为 Sites 只是模板建站。但开发者文档里透露出的技术底座，其实更像一个认真面向企业场景的发布系统。

首先是两阶段发布管线。

第一步是保存版本。Codex 会构建可部署站点，并把版本和源代码的 Git commit 关联起来。这一步创建的是可审查的部署候选，不会直接公开。

第二步是部署版本。确认没问题后，才把保存的版本发布出去，拿到生产 URL。

这个设计很软件工程：先审查，再上线，不是一键裸奔。

OpenAI 还在开发者网站上做了 Sites Showcase，展示了 6 个示例项目：Onboarding Hub、Enablement Hub、Pulse Dashboard、Sparkboard、Launch Cal、Event Planning Hub。技术栈覆盖 Next.js、React、Three.js，甚至还有 SwiftUI。

存储方面，Sites 支持两类绑定：结构化数据用 D1，文件和图片等对象存储用 R2。如果只是静态着陆页，可以不接存储；如果是带登录、上传、状态记录的内部工具，就可以同时绑定 D1 和 R2。

运行时也值得注意。Sites 的构建产物是兼容 Cloudflare Worker 的 ES Modules，也就是说它不是随便搭了个自研壳子，而是站在 Cloudflare 边缘计算基础设施上。好处是低延迟、全球分发和弹性伸缩；代价是技术栈和基础设施依赖也更明确。

访问控制则明显是给企业准备的：admins_only、workspace_all、custom 三种模式，分别对应站点所有者、整个工作区，以及指定用户或用户组。

实际使用也很直接，在 Codex 里用 @Sites 触发插件，再描述你想要的内部工具。例如让团队成员提交项目请求、查看负责人、更新状态、筛选列表，并要求用工作区账号登录、保存访问数据。只要需求说清楚，Codex 就会尝试把它变成一个可用页面。

6 大业务插件：OpenAI 想做角色化 Agent 编队

Sites 并不是孤立功能，它和 OpenAI 这次面向 Business / Enterprise 的 Codex 战略绑在一起。

同时出现的，还有 6 个角色化业务插件：

• 数据分析插件：用自然语言探索数据、解释指标变化、创建报告，集成 Snowflake、Databricks、Hex、Tableau。
• 创意制作插件：帮助营销团队生成广告变体、产品图、电商素材，集成 Figma、Canva、Shutterstock、Picsart。
• 销售插件：识别优先客户、准备会议、更新客户记录，集成 Salesforce、HubSpot、Slack、Outreach。
• 产品设计插件：辅助原型制作、审计用户流程，集成 Figma、Canva。
• 公共股权投资插件：分析财报、对比公司、评估投资论点，接入 Moody’s、FactSet、LSEG、S&P、PitchBook。
• 投资银行插件：辅助推介材料、可比公司分析和尽职调查。

这套组合透露出的信息很清楚：OpenAI 不只是想让 Codex 写代码，它想把 Codex 做成按岗位分工的 Agent 编队。

每个插件背后，都是一套预置工作流、一组已经对接好的 SaaS 工具，以及针对特定岗位优化过的提示和操作路径。普通用户不用知道这些，只需要说“帮我准备明天和某个客户的会议”，Codex 就可能拉 Salesforce 的客户数据，生成会议准备材料，最后再通过 Sites 做成一个可交互的客户概览页。

所以 Sites 真正的价值，不是“它也能建站”，而是它成了 Agent 工作流的展示层。

过去团队对齐想法，要写文档、做 PPT、开会讲半天。每个人脑子里的理解还不一定一样。Sites 试图把这种“脑补对齐”变成“现场对齐”：直接生成一个能看、能点、能用的东西，让团队在使用中对齐。

和 v0、Replit、Cursor 比，差异在哪里？

很多人第一时间会把 Sites 和 Vercel v0、Replit、Cursor 放在一起比较。确实，它们都和“从想法到应用”有关，但面向的人群并不一样。

v0 生成 React 组件的能力很强，尤其是 UI 层面。但它输出的是代码，不是企业里马上可分享的成品网站。后续部署、后端、数据和权限，大多还要开发者接着处理。

Replit 更偏全栈，从提示词到部署的链路很顺。但它的核心体验仍然是“用 AI 辅助构建应用”，门槛比 Sites 高一些。

Cursor 则是专业开发者的 AI 编辑器，它增强的是编码过程，而不是把一个业务想法直接变成团队可用的 URL。

Sites 的优势，至少在当前叙事里，是门槛最低。一个不写代码的销售经理，如果能在 5 分钟内把客户跟进看板从想法变成链接，这件事对企业内部效率的冲击会很大。

这也是 Sites 和传统建站工具最大的不同：它不只是帮你“生成页面”，而是试图帮你“完成一段工作”。

OpenAI 的生态策略：不是筑墙，而是修桥

另一个信号也值得看：OpenAI 并没有把 Sites 做成一个孤立封闭的工具。

它提到的合作伙伴包括 Wix、Base44、Replit、Lovable、Figma、Webflow、Emergent。换句话说，OpenAI 不是只想做一个新的建站产品，而是想让 Sites 变成 Agent 工作流与外部工具之间的桥。

VentureBeat 的分析里有一句话很贴切：相比静态 PPT，Sites 承诺让企业以更易消化的方式持续查看最新指标和重要信息。

这句话背后的意思是：Sites 不只是展示页，而是一个“活页面”。它可以接 Figma 设计、Salesforce 数据、Snowflake 数据仓库，再把这些信息变成团队能直接操作的界面。

这是平台策略，不是单点工具策略。

我的判断

好的地方很明显。

从技术上看，Sites 的底座比预期扎实。Cloudflare Workers 运行时、D1/R2 存储绑定、两阶段发布流程、RBAC 访问控制，这些都不是随便做 demo 的配置，而是认真往企业产品靠。

从行业上看，这步棋也聪明。Codex 从 2 月发布以来，周活用户已经超过 500 万，但非开发者只占 20%。Sites 加角色插件，是 OpenAI 把 Codex 往更广泛知识工作者市场推进的钥匙。

但现在我不会给太高分，最多 6 分左右。

第一，它目前主要面向 Business 和 Enterprise。Business 工作区默认开启，Enterprise 还需要管理员在 RBAC 里手动打开。Plus、Pro 和 Free 用户暂时用不上，口碑扩散会受限制。

第二，自定义能力仍有限。站点跑在 OpenAI 和 Cloudflare 的基础设施上，定制空间和开发者掌控感很难和 Vercel v0、Replit 这类工具比。

第三，影子 IT 风险会变大。团队自己生成各种内部应用，效率是提高了，但谁负责维护、谁负责安全审查、谁确认数据权限，都可能变成新的治理问题。

还有使用边界也要注意。Sites 条款里明确禁止处理受 HIPAA 保护的医疗数据、PCI DSS 管辖的支付卡数据，以及资金转移和加密货币交易相关场景。这说明它目前更适合内部工具、原型和轻量工作流，而不是高敏感数据的生产系统。

总体看，Sites 的意义不在于“OpenAI 又做了一个建站工具”，而在于 Codex 正在从写代码走向交付成果。

当年 WordPress 让建站从“写 HTML”变成“选主题”。Sites 想做的事情本质上类似，只是这次用户连主题都不用选，说出来就行。

“我们现在已经基本追平了几个月前的最先进水平。”

Build 大会前夕，微软 AI 执行副总裁兼 CEO Mustafa Suleyman 用这句话，给微软最新一轮自研模型发布定了调。

这次微软在 Build 上一次性推出多款 MAI 系列模型。对一家过去几年深度依赖 OpenAI 的公司来说，这不是普通的产品更新，而是一次很清晰的战略转身：微软正在从“AI 应用整合者”，进一步走向“全栈 AI 基础设施与模型提供者”。

外界把这场大会称作微软的“AI 独立日”，并不夸张。

首个高级推理模型：MAI-Thinking-1

这次发布中最受关注的，是微软首个高级推理模型 MAI-Thinking-1。

据微软介绍，MAI-Thinking-1 是一款“中等规模模型”，拥有 350 亿活跃参数、128K 上下文窗口，总参数规模约 1 万亿。它的设计重点不是单纯堆大，而是在推理能力、效率和低 token 成本之间取得平衡。

微软开发者市场负责人、GitHub 首席运营官 Kyle Daigle 表示，MAI-Thinking-1 主要面向复杂多步骤指令、长上下文推理以及代码生成任务。

过去一年，推理模型赛道基本由 OpenAI o 系列、Google Gemini 推理版本、Anthropic Claude 的扩展思考模式主导。开源阵营里，DeepSeek R1 也曾在 2025 年初明显撼动这一格局。

现在，微软正式入场。

从公开信息看，MAI-Thinking-1 在关键软件工程基准中已经可以对标领先模型；在 SWE Bench Pro 上，其表现与 Claude Opus 4.6 持平。

数学推理方面，它在 AIME 2025 中达到 **97.0%**，在 AIME 2026 中达到 **94.5%**。微软还称，在盲测人工对比评估里，用户对 MAI-Thinking-1 的偏好甚至超过 Claude Sonnet 4.6。

真正被强调的是“从零训练”

相比跑分，微软这次更想强调的是另一件事：MAI-Thinking-1 不靠蒸馏。

微软明确表示，该模型训练数据中不包含任何其他已训练 AI 系统的概率分布或输出序列，也没有使用来自第三方模型的蒸馏数据。

换句话说，它不是靠学习别家模型输出追上来的，而是从预训练阶段就排除 AI 生成内容，使用企业级、干净、具备合规商业授权的数据训练。

微软的说法是，这会迫使模型真正学会任务本身，而不是模仿另一个模型的回答风格。

这件事对普通开发者可能只是一个技术标签，但对企业客户，尤其是医疗、金融、国防以及高监管行业来说，意义会更大。

这些场景采购 AI 时，不只会问模型能不能用，还会问训练数据从哪里来、知识产权是否干净、能不能通过合规审查。

所以，“不使用第三方模型输出”“不碰蒸馏”，很可能会成为微软面向企业客户的一张关键牌。

MAI 模型家族补齐多模态版图

除了 MAI-Thinking-1，微软还发布了另外六款 MAI 系列模型，覆盖图像生成、图像编辑、语音转写、语音合成和编程等方向。

MAI-Code-1-Flash 是一款高效率智能体编程模型，参数规模为 5B，目标是深度集成到 GitHub Copilot、Visual Studio Code 以及微软整体技术栈中。微软称其性能可对标 Haiku，但成本更低。

图像方向，MAI-Image-2.5 及其 Flash 版本支持文生图和图像编辑，Arena 评分已超过 Nano Banana Pro。

语音方向，MAI Transcribe-1.5 被称为当前最强语音转录模型之一，速度是同类模型的 5 倍，并内置支持 43 种语言的领域专有术语。

语音生成方面，MAI-Voice-2 支持 15 种语言的自然语音生成，可通过短语音样本进行声音适配，并加入滥用防护。更高性价比的 MAI-Voice-2-Flash 也即将推出。

这些模型未来都将接入 Azure AI Foundry，以及新的 MAI Playground。微软还表示，开发者将首次可以对部分模型权重进行自定义调优。

这说明微软并不是只补一个推理模型，而是在搭建从基础模型、多模态能力到开发者平台的完整 MAI 生态。

Scout：把模型塞进 Microsoft 365 工作流

模型之外，微软还推出了新的企业智能体 Scout。

Scout 基于 OpenClaw 框架构建，可以在 Microsoft 365 应用之间全天候自主运行，独立完成任务。它能够连接 Teams、Outlook、OneDrive、SharePoint 等应用，并访问聊天、邮件、日历和联系人数据。

用户可以通过 Teams 调用 Scout，它也可以与浏览器交互，并通过 MCP 连接外部应用。微软称，该工具可在云端、桌面端和网页端运行。

微软企业副总裁 Omar Shahine 表示，这类智能体会在后台持续理解用户在各种应用和系统中的工作方式，并在不需要每次提示的情况下主动采取行动。

例如，它可以帮助办公人员协调会议时间、根据后续安排预留日历空档，也可以提前发现决策停滞等风险，让用户在问题变成阻碍前处理。

不过，OpenClaw 此前曾因安全漏洞受到审查。微软这次特别强调，Scout 具备企业级安全与控制能力，“从第一天起就可以在组织中被信任使用”。

目前，Scout 以实验性版本向 Frontier 项目客户开放，需要通过 Intune 策略配置以及主动选择确认。定价暂未公布，也不清楚它未来会纳入 Microsoft 365 Copilot 订阅，还是单独收费。

微软想拿回 AI 底座主动权

过去几年，微软在 AI 领域的优势很大程度来自 OpenAI。Azure、Copilot、GitHub Copilot、Microsoft 365 Copilot，都受益于这段合作关系。

但底层模型高度依赖外部伙伴，也意味着微软在成本、节奏、产品差异化和企业合规上会受到限制。

MAI 系列的发布，正是在补这块短板。

MAI-Thinking-1 代表微软开始拥有自己的高级推理模型；MAI-Image、MAI-Voice、MAI Transcribe 代表多模态能力成型；Scout 则说明微软希望把这些模型真正嵌入企业工作流。

微软不想只做 AI 应用入口，也不想永远只是 OpenAI 时代的最大渠道商。它要把模型、平台、工具链和企业智能体重新握在自己手里。

这也是“AI 独立日”这个说法真正成立的原因。

结语

MAI-Thinking-1 追平 Claude Opus 4.6，是一个醒目的能力信号。

但更值得关注的是，微软正在把模型能力从外部依赖变成内部资产。

从零训练、不使用第三方模型蒸馏、强调企业级干净数据，这些听起来没有跑分那么刺激，却可能正是企业客户最在意的部分。

当企业开始真正采购 AI，它们不会只问“哪个模型最强”，还会问：这个模型从哪里来？数据是否合规？知识产权是否干净？能不能被纳入企业治理体系？

微软这次给出的答案很明确：它要成为一个真正拥有自研模型底座的 AI 平台公司。

2.1.160 距离上一版只隔了 23 小时，但这次并不是走过场。

这一版最核心的动作，是给几类可能被拿来执行恶意代码的路径补上确认提示：shell 启动文件、构建工具配置、git 配置。另一处用户能直接感知的变化，是 dynamic workflow 的触发词从 workflow 改成了 ultracode，输入框里会以紫色高亮显示。

后台会话也修了一批稳定性问题，prompt tokens 则从约 11.6 万降到约 5.8 万，几乎砍半。表面看是一次常规迭代，但安全加固、后台可靠性和提示词瘦身，都是 Claude Code 这种工具越往深处走越绕不开的苦活。

三道安全防线：先把门锁上

2.1.160 最值得认真看的，是安全部分。

这次不是修某一个已经暴露的具体漏洞，而是提前给高风险写入路径加确认。它堵的是同一类攻击模式：通过修改配置文件，把恶意命令持久化到用户环境里。

第一道防线，是 shell 启动文件。

.zshenv、.zlogin、.bash_login，以及 ~/.config/git/ 这类路径，在终端启动或 git 操作时可能自动加载。如果某个 MCP server、skill，或者被污染的自动化流程，往这些地方塞进一行命令，下次打开终端或执行 git 时就可能直接跑起来。

从 2.1.160 开始，Claude Code 写这些文件前会先弹确认。换句话说，不是不让写，而是把“静默写入高危启动项”变成“你想清楚了再让它写”。

第二道防线，是构建工具配置。

在 acceptEdits 模式下，Claude Code 现在写入 .npmrc、.yarnrc*、bunfig.toml、.bazelrc、.pre-commit-config.yaml、.devcontainer/ 等文件前，也会提示确认。

这些文件的危险点在于，它们经常和依赖安装、构建、提交、容器启动绑定。.npmrc 可能影响 install 行为，pre-commit 可以直接跑 shell，devcontainer 则可能在打开项目时触发一整套初始化动作。对于自动接受改动的模式来说，这类路径原本就应该被单独拎出来。

这次加固的意义就在这里：它不是等攻击发生后补洞，而是提前把攻击面降下来。

workflow 改成 ultracode：避免误触，也是在腾位置

另一个很明显的变化，是 dynamic workflow 的触发关键词从 workflow 改成了 ultracode。

这个改名看着小，其实很合理。

workflow 是一个太常见的自然语言词。用户说 “show me the workflow”，或者问“这个 workflow 怎么设计”，都有可能不小心触发 dynamic workflow。2.1.157 刚引入 dynamic workflow 时，Anthropic 还专门做过「Workflow keyword trigger」开关，让不想误触的人关掉。现在直接换成 ultracode，问题就简单多了：这个词几乎不会自然出现在日常句子里。

更重要的是，它还能和 /effort ultracode 保持同一套命名。至于用自然语言描述来触发 workflow 的能力并没有消失，你说“帮我用多个 agent 一起处理这个任务”，仍然可以进入 dynamic workflow 流程。

我更倾向于把这次改名理解为两层意思：一层是减少误触；另一层是给未来的 workflow 编排能力让路。毕竟 workflow 在 MCP、插件和自动化生态里都是常用概念，继续拿它当硬触发词，迟早会撞名。

grep 之后不用再 Read：小改动，但很顺手

这版还有一个体验改进很实用：单文件 grep / egrep / fgrep 现在可以满足 read-before-edit 校验。

以前的流程经常是这样：先用 grep "某函数" src/file.ts 看到了目标位置，准备修改时，Claude Code 又提示“你还没读这个文件”，于是还得再 Read 一遍。现在单文件 grep 结果可以算作已经看过文件，省掉一步。

这个改动只对单文件生效，多文件 grep 仍然不算。逻辑也说得通：单文件 grep 至少能确认上下文来自哪个文件；多文件搜索通常只是定位线索，还需要进一步明确要改哪一份。

后台会话：修的都是日常会踩的坑

后台会话这次修复不少，而且每一个都直接影响使用体验。

最严重的是恢复已完成会话时，对话历史可能丢失，并重新执行原始 prompt。你从 claude agents 里打开一个已经跑完的后台任务，本来只是想看结果，结果它忘了前面的对话，又从头跑一遍，这基本等于白做。

类似的问题还包括隔夜后的后台 session 重新 attach 时丢对话、重新执行原 prompt。对于让 agent 跑长任务的人来说，这种 bug 的杀伤力很大：任务不是不能跑，而是跑完之后结果不可靠。

这次还修了 claude --bg 在高负载机器冷启动 daemon 时偶发 socket missing 的问题；修了 Windows 上 claude rm 后后台 daemon 没退出导致目录删不掉的问题；也修了后台 agent 恢复工作后被错误列在 Completed 下，以及退出 agents 列表时因自动更新检查导致界面冻结的问题。

这些都不是炫技功能，但它们决定后台 agent 到底能不能成为日常工作流的一部分。

Windows 和输入修复：中文用户也能感到变化

Windows 端这次也补了几处痛点。

WSL 下选中复制不再依赖 OSC 52，而是改用 PowerShell interop 写入 Windows 剪贴板。对于 MobaXterm 这类不支持 OSC 52 的终端来说，这个修复很关键。

高 CPU 负载下，附着到后台 session 或在 agent 视图里 Esc、方向键、输入无响应的问题也修了。这个大概率和事件循环被重任务堵住有关，Windows 用户跑大项目时很容易遇到。

还有一个对中文用户很直接的修复：CJK 输入法候选窗不再跑到屏幕左下角，而是回到输入光标附近。候选窗位置不对，看似小 bug，实际会让中文输入几乎不可用。

prompt tokens 砍半：官方没强调，但很值钱

这版最意外的数据，是 marckrenn 统计到的 prompt 变化：prompt tokens 从约 115,652 降到约 58,309，减少 57,343，降幅 49.6%。prompt 文件数也从 81 个降到 42 个，少了 39 个文件，降幅 48.1%。

这个幅度不太像小修小补，更像做了一轮系统提示词合并、去重和压缩。

Token 分布也有变化：tools 占比从 86.1% 升到 87.9%，system-reminder 从 8.2% 降到 7.2%，system 从 3.2% 降到 1.0%，system-data 从 1.1% 升到 2.3%。也就是说，真正被砍掉的主要是系统级指令和重复提示，工具定义本身并没有大幅减少。

这件事 Anthropic 官方 changelog 没有重点提，但对 API 付费用户很实际。每次请求少掉约 58k tokens，用得频繁时就是直接省钱。原文按 Opus 4.8 估算，单次 request 大约能省 0.87 美元。对每天几十上百次调用的人来说，这比加一个小功能更有体感。

这一版的方向

2.1.160 不是那种让人一眼“哇”的版本，但每条改动都落在关键位置。

安全防护走的是预防性路线。现在未必已经有公开案例利用 shell 启动文件或构建配置攻击 Claude Code 用户，但先给这些路径加确认，总比等事后补丁强。上一次 Claude Code 比较密集地做安全加固，是 2.1.101 那次命令注入修复；那次更像修漏洞，这次更像压攻击面。

后台会话的修复量也说明 Anthropic 在认真推进后台 agent 模式。它修的不只是 crash，还有目录锁、列表分类、会话恢复、界面冻结这些细节。只有这些细节稳定下来，多 agent、长任务、隔夜任务才有可能真正成为默认用法。

至于 workflow 改名 ultracode，我不觉得只是换个触发词。它更像是在给后续的 workflow 编排能力留下语义空间：workflow 这个词应该属于更通用的流程系统，而不是一个容易误触的关键词。

从 2.1.157 到 2.1.160 这几版连着看，节奏其实很清楚：插件体系铺底，云平台 auto mode 扩展，内部管线优化，然后补安全和可靠性。每版只做一两件事，但都在把 Claude Code 从“能用”往“可长期托付”推。

升级方式也很简单：Native 安装一般会自动后台更新；如果想立刻应用，可以执行 claude update。Homebrew 用户则是 brew upgrade claude-code。

大模型上下文窗口详解：超长上下文原理与工程取舍，小白也能看懂

在做大模型落地开发时，很多人都会遇到这些问题：多轮对话越聊越乱、长文档喂进去之后模型抓不住重点、超长代码分析越到后面越不准、上下文一多模型像突然“降智”一样开始答非所问。

大多数人会简单地把问题归结为“模型不够强”。但从工程角度看，这些现象背后真正的核心变量，往往不是模型名字，而是上下文窗口（Context Window）。

上下文窗口决定了模型当前这一轮到底能看到多少信息、记住多少信息、基于多少信息做推理。它既是大模型非常底层的一项能力，也是影响 Prompt 设计、长文档处理、RAG 架构和模型选型的关键参数。

这篇文章会把上下文窗口的底层逻辑、优势、短板以及工程上的取舍讲清楚，帮助你真正理解：为什么有时应该上长上下文模型，为什么更多时候反而应该优先考虑 RAG。

一、什么是上下文窗口？

一句话解释：上下文窗口，就是大模型当前这次回答中，最多能“看见、记住、理解”的文本范围。

如果把大模型类比成人，那么上下文窗口有点像人的“瞬时工作记忆”。

人不可能在同一时刻把几万字内容都牢牢抓在脑子里，只能优先关注当前最相关、最重要的一部分信息。大模型也是一样，它每次生成回答时，并不是无限读取所有历史内容，而是只能处理窗口范围内的 token。超出窗口的内容，模型就看不到了。

因此，无论是：

• 系统提示词；
• 多轮对话历史；
• 用户当前问题；
• 上传的文档、代码、资料；
• 输出格式要求与约束条件；

本质上都要一起“挤”进这个窗口里。

窗口越大，模型一次能处理的内容就越多；窗口越小，能容纳的信息就越有限。

Token 是怎么回事？

上下文窗口通常不是按“字数”算，而是按 Token 计算。

Token 可以理解成模型内部处理文本的最小单位。中文、英文、标点、数字在分词后都会转成 token。粗略理解时，很多文章会把 1 token 近似看作 0.75 个中文字符左右，但这只是一个非常粗的经验值，实际会随内容结构变化。

工程上更重要的是知道：窗口容量拼的是 token，不是拼字数。

二、上下文窗口里到底包含什么？

很多刚接触大模型的人，会误以为上下文窗口只计算“用户这一句提问”。

其实远不止如此。

在实际系统里，一个请求通常至少包含三部分内容：

1. 系统提示词

这是模型最开始拿到的全局规则，包括：

• 角色设定；
• 输出格式；
• 风格要求；
• 禁止事项；
• 防幻觉约束；
• 工具调用规范。

这部分虽然用户看不到，但会真实占用上下文窗口。

2. 历史对话

只要是多轮对话，前面几轮的问答记录也会一起带进当前请求中。这部分就是模型看起来“有记忆”的根源。

如果历史内容很多，它会持续吞掉窗口预算。

3. 当前输入内容

包括用户本轮新提问，以及附带上传的文档、参考材料、代码片段等。

这才是大多数人最容易想到的部分，但它往往只是总窗口的一部分，而不是全部。

因此，真正的 token 消耗不是“当前问了多少”，而是：

系统提示词 + 历史对话 + 当前输入 + 预留输出空间

一起构成完整预算。

一旦总量超出窗口上限，系统通常就会开始截断。最常见的是裁掉最前面的历史内容，结果就是：

• 模型忘记最初约束；
• 前面需求丢失；
• 人设失效；
• 输出风格突然变化；
• 对话越聊越跑偏。

三、超长上下文窗口到底强在哪里？

近年来，越来越多模型开始宣传 128K、200K，甚至 1M 级别的上下文窗口。它们之所以被视为更高级的模型，不是因为“数字更大看起来更厉害”，而是它们确实在一些场景中具备非常明显的价值。

1. 可以整文件全量处理

如果窗口足够大，模型就能直接读取：

• 完整论文；
• 合同全文；
• 上万行代码；
• 超长会议纪要；
• 整份调研报告。

这样做的好处是，不需要先把内容切片，也不一定需要额外做检索召回，模型可以直接在全局范围内理解内容之间的联系。

2. 多轮对话不容易失忆

当窗口足够长时，前面几十轮甚至更多轮的对话都还能被保留下来。

这意味着模型更容易记住：

• 初始目标；
• 最开始定义的规则；
• 前面讨论过的术语口径；
• 之前确认过的输出结构。

在复杂协作式任务里，这一点非常重要。

3. 更适合做全局关联分析

很多任务不是只看局部片段就能完成的，而是必须跨章节、跨段落、跨文件做整体理解。

比如：

• 比较合同前后条款是否冲突；
• 找论文结论是否与前文实验设置一致；
• 做整仓代码架构梳理；
• 对长文做统一改写与逻辑复盘。

在这类场景里，长上下文的优势非常明显，因为模型不是在碎片化地看内容，而是在更完整的全局视角下做分析。

四、为什么“窗口越大越好”是个误区？

很多人第一次接触长上下文模型时，会自然得出一个结论：既然大窗口能装更多信息，那肯定越大越好。

但工程实践里，这其实是一个非常常见的新手误区。

长上下文并不是没有代价的，它反而伴随着几个很容易踩坑的硬伤。

1. 成本更高，速度更慢

上下文越长，模型在注意力计算时要处理的内容就越多。

这直接带来几件事：

• 输入 token 成本上升；
• 推理延迟变长；
• 整体调用价格更贵；
• 并发吞吐下降。

如果业务是高频调用、批量调用或在线实时调用，这个差异会非常明显。

所以在很多企业场景里，长上下文并不只是“更强”，它首先意味着“更贵”。

2. 注意力会被稀释

这是最关键、也最容易被忽视的问题。

很多人以为信息越多越好，但实际上，当你把几万字甚至十几万字内容一股脑全塞进模型时，模型并不一定会因此更精准，反而可能更容易忽略真正关键的信息。

因为在超长文本里：

• 冗余信息变多；
• 无关片段变多；
• 关键信息被埋得更深；
• 模型对核心细节的关注度被分散。

这就是所谓的“注意力稀释”。

结果就是：看起来给了更多材料，实际上回答却可能更飘、更泛、更抓不住重点。

3. 幻觉和逻辑混乱更容易增加

长文本本身往往包含更多语义冲突、更多模糊片段、更多跨段关系。

当这些内容一起进入上下文时，模型更容易出现：

• 错误关联；
• 前后矛盾；
• 引用错位；
• 逻辑链路混乱；
• 结论偏离重点。

也就是说，长上下文并不是“自动提升质量”的万能钥匙。很多时候，它只是提供了更大的输入空间，而不是更强的筛选能力。

五、长上下文和 RAG，到底该怎么选？

这是大模型工程里最常见、也最实用的一个选型问题。

很多团队都会在这里纠结：到底应该直接上超长上下文模型，还是用短窗口模型加 RAG？

一个非常实用的判断方式是：你到底是要模型“全量读完”，还是只要它“精准找到相关内容”。

更适合用 RAG 的场景

RAG 更适合这些情况：

• 知识库问答；
• 海量文档中查某个问题；
• 资料持续更新；
• 高频业务调用；
• 大篇幅材料里只需要局部相关内容；
• 企业私有知识需要动态接入。

RAG 的核心思路不是把所有材料一次性塞给模型，而是先通过检索找出最相关的少量片段，再把这些片段交给模型回答。

它的优势在于：

• 成本更低；
• 延迟更稳；
• 相关性更集中；
• 动态知识更新更方便；
• 能有效避免海量冗余信息稀释注意力。

更适合用长上下文的场景

长上下文更适合这些任务：

• 合同全文审阅；
• 论文精读；
• 整仓代码理解；
• 全文统一改写；
• 长报告全局对比；
• 需要跨章节整体关联的复杂任务。

这类任务的问题在于：你不能只取几个片段，因为真正的答案很可能依赖全文结构、段落前后关系、不同章节之间的对应逻辑。

此时如果强行用 RAG 切碎，可能会损失整体语义关系。

一个工程上非常实用的结论

如果问题的本质是“从很多内容里找最相关的一小部分”，优先考虑 RAG。

如果问题的本质是“必须通读完整材料并保持整体关联”，再考虑 长上下文模型。

换句话说：

细碎知识库更适合 RAG，完整文件精读更适合长上下文。

六、上下文窗口的工程最佳实践

理解原理之后，更重要的是如何在系统里真正把它用对。

1. 不要盲目迷信大窗口

在大多数业务里，真正需要整份长文全文理解的情况，并没有想象中那么多。

很多任务其实只是：

• 查一个问题；
• 找一个字段；
• 抽一段信息；
• 根据少量材料回答。

这种场景下，短窗口模型配合 RAG，通常成本更低、稳定性更高、整体性价比也更好。

2. 系统提示词要尽量精简

很多项目一开始就把系统提示词写得特别长，结果关键业务信息还没进来，窗口已经被说明文字吃掉一大块。

所以系统提示词的原则应该是：

• 保留真正有效的规则；
• 删除冗余套话；
• 减少重复约束；
• 把关键规则写得短而明确。

窗口是预算，不要把预算浪费在形式化废话上。

3. 多轮对话要做历史修剪

如果是长期对话系统，不能无限堆历史消息。

更稳妥的做法是：

• 保留任务起点；
• 保留最近关键轮次；
• 删除中间无效闲聊；
• 必要时做摘要压缩。

这样既能保住上下文连续性，又能防止窗口被历史垃圾信息挤爆。

4. 长文档优先考虑切片与筛选

并不是所有长文都要原样整篇喂给模型。

如果任务本身并不依赖全文逻辑，而只是要回答某个问题，那么先切片、再检索、再召回核心片段，通常会比整篇硬塞更有效。

这本质上是在主动对抗注意力稀释。

5. 关键信息要放在模型更容易注意的位置

很多模型对开头和结尾的信息相对更敏感。

因此在实际提示设计中，最好把这些内容尽量前置或后置：

• 核心规则；
• 真正任务目标；
• 不能违反的约束；
• 最终输出格式要求。

不要把最重要的信息埋在一堆冗长背景材料中间。

七、全文总结

上下文窗口决定了大模型的记忆上限、视野上限和理解上限。

但它并不是越大越万能。

短窗口模型往往更便宜、更精准，也更适合和 RAG 组成高性价比方案；长上下文模型虽然更适合全局理解，但代价更高，也更容易受到注意力稀释和长文本幻觉的影响。

真正成熟的大模型工程思维，不是单纯追求“窗口最大”，而是根据任务本质选择最合适的路线：

• 能检索定位的任务，优先 RAG；
• 必须全文理解的任务，再上长上下文；
• 能省窗口的地方，尽量省；
• 能减少冗余输入的地方，尽量减。

当你把上下文窗口的逻辑想清楚之后，Prompt 设计、参数使用、RAG 选型、模型选择，其实都会自然串成一套完整的判断体系。

而这，正是从“会用 AI”走向“能把 AI 落地”的关键一步。

RTX Spark 来了：为什么它可能重新定义个人 PC 的 AI 时代

今天，英伟达的 NVIDIA GTC Taipei 2026 如约而至。

发布会上讲了很多东西，但如果只挑一个最值得单独拎出来讲的，我觉得就是 RTX Spark。

因为它不是一次普通的产品更新，而更像是英伟达在试着回答一个问题：个人电脑诞生 40 年之后，AI 时代的 PC，到底该重新长成什么样。

“A New Line, A New Beginning。”

这句口号放在这次发布里，并不只是营销话术。至少从英伟达给出的路线来看，它想做的并不只是更强的消费级芯片，而是把“本地大模型 + 统一内存 + CUDA + Windows 原生 Agent”第一次比较完整地装进一台个人电脑里。

过去半年，AI 的主要进展几乎都发生在云端。

OpenClaw、Claude Code、Codex 这类产品的背后，本质上还是云端大模型在持续变强。但如果视角回到 ToC 端硬件，你会发现真正有决定性变化的东西并不多。

可问题是，谁不想把大模型和 Agent 真正部署到自己的本地端？

低延迟、隐私保护、无需网络，不只是推理，甚至还可以微调。那种自由又安全的感觉，始终很有吸引力。

所以，这次 RTX Spark 真正打动人的地方，不是它又多了一块新芯片，而是它让“本地 AI PC”这件事第一次显得没那么像概念，而像是一条正在被认真推进的产品线。

RTX Spark，到底给了什么？

如果只看参数，这次的东西已经很夸张了。

• 最高 1 PFLOP 的 FP4 AI 性能
• 20 个 CPU 核心
• 6144 个 GPU 核心
• 128GB LPDDR5X 统一内存
• 官方给出的定位，是可以在本地直接承载 120B 级模型

这组参数最重要的意义，不在于看起来够不够猛，而在于它在个人消费级设备里，第一次比较明确地把“本地跑更大模型”这件事推到了主舞台上。

如果只是云端推理更快，那还是云服务的故事；但如果个人电脑本身开始具备稳定承载大模型和 Agent 的能力，那就是另一条路了。

为什么这次最关键的是统一内存

要理解 RTX Spark，最绕不过去的就是 统一内存。

传统 PC 里，CPU 和 GPU 各有各的内存：

• CPU 用系统内存（RAM）
• GPU 用显存（VRAM）
• 两边交换数据，要通过 PCIe 之类的通道来回搬运

这套架构对很多传统应用没问题，但对本地大模型很不友好。

比如一台机器有 64GB RAM，再搭一张 16GB VRAM 的显卡。你看起来总内存不小，但 GPU 真正能高速访问的，往往还是那 16GB 显存。

一旦模型太大，显存放不下，就只能把一部分权重留在系统内存里。GPU 每次需要这些权重时，就得跨通道去拿，结果就是：理论上能跑，实际上很慢。

统一内存解决的，就是这个问题。

当 CPU 和 GPU 共享同一个大内存池之后，GPU 不再被那点独立显存卡得死死的。对本地大模型、长上下文推理、多模态工作负载来说，这几乎是体验能不能真正上一个台阶的关键差别。

所以这次 RTX Spark 的价值，并不只是“性能更强”，而是它在消费级 PC 上，把统一内存真正推成了 AI 时代的核心卖点。

那为什么不是 Mac，而是 RTX Spark 更让行业兴奋？

说到统一内存，很多人第一反应都是 Mac。

这没错。Apple 早就把统一内存做成了自己的主流路线，而且体验也很好。

但问题在于，统一内存只是其中一半，另一半是 CUDA。

这也是为什么 RTX Spark 会让这么多开发者真正兴奋。

因为对 AI 工程来说，CUDA 从来不只是一个“显卡加速技术”的名字，它是一整套积累了将近二十年的生态。

• cuBLAS 做线性代数
• cuDNN 做深度学习基础运算
• TensorRT 做推理优化
• NCCL 做多卡通信
• 大量开源模型、训练代码、推理框架，默认首先支持的依然是 CUDA

这意味着什么？

意味着今天你去看学术代码、开源模型、工程教程、性能优化经验，默认语境基本都还是 CUDA。AI 工程界的“母语”，到今天依然是它。

而 Apple 的问题并不是统一内存不够好，而是它的 GPU 生态更多是 Metal / MLX 路线。推理层面在很多轻量场景已经不错，但一旦进入训练、微调、复杂工作流兼容这些问题，CUDA 的护城河仍然非常深。

所以 RTX Spark 真正最有杀伤力的点，是它第一次把过去在 PC 端很难兼得的两件事往一起捏：

统一内存的容量优势 + CUDA 生态的工程优势。

它瞄准的并不只是硬件，而是一整套本地 Agent 平台

如果 RTX Spark 只是一块更强的芯片，这次发布不会有这么大反响。

真正值得注意的是，英伟达讲的已经不只是硬件，而是一套完整的平台路线。

从发布信息看，这套路线至少包括三层：

1. 底层硬件

RTX Spark 提供统一内存、高带宽和 CUDA 兼容能力，让本地大模型真正有了更现实的承载基础。

2. 系统层支持

微软会和英伟达一起重构 Windows 对本地 Agent 的支持。这件事非常关键，因为它意味着未来 Windows 可能不是“顺便能跑 AI”，而是开始朝“原生承载 Agent 工作流”去改。

3. 安全与运行环境

无论是 Windows security primitives，还是英伟达提到的 OpenShell，本质都在说明一件事：本地 Agent 不能只是能跑，还得能被认证、隔离、授权和管控。

这点其实很重要。因为真正进入个人生产力和企业环境后，决定一套平台能不能落地的，从来都不只是算力，还包括权限、安全和系统协同。

这意味着什么？

如果你是开发者，这套东西的吸引力会很直接：

• 本地跑更大的模型
• 更自然地做 Agent 工作流
• 更低门槛地试多模态应用
• 更顺滑地接入 CUDA 现有工具链

如果你是创作者，这件事也不只是“AI 生图更快”那么简单。

一旦 Adobe、视频编辑、3D 场景、内容工作流都围绕这种本地 AI 设备做深度优化，那么未来很多创作行为会从“调用云端 AI 服务”，变成“系统原生调用 AI 能力”。这两者的体验逻辑，其实完全不是一回事。

写在最后

RTX Spark 最值得关注的地方，不只是参数强不强，而是它第一次试图把几块长期割裂的能力整合进同一套个人 PC 方案里：

• 统一内存
• CUDA 生态
• 本地大模型能力
• Windows 原生 Agent 支持

如果说过去的 AI 浪潮主要发生在云端，那么 RTX Spark 真正想回答的问题就是：下一波 AI，能不能回到每个人自己的电脑上？

至少从这次发布会看，英伟达给出的答案已经非常明确了。

它想开启的，不只是一个新品，而是一整代 AI 原生个人 PC 的起点。

苹果AI眼镜又跳票：问题不只是硬件，更是Siri还撑不起这副眼镜

苹果的 AI 眼镜又往后挪了。

按照彭博社记者马克·古尔曼的最新说法，这款内部代号 N50 的产品，发布时间已经从原本的 2026 年底推迟到 2027 年底左右，真正到用户手里，大概率要等到 2028 年。这几乎把外界对苹果 AI 眼镜的期待，再次往后推了一整年。

更值得注意的是，这并不是很多人想象中的那种 AR 眼镜。它没有透明显示屏，不负责把数字信息直接叠到现实世界里，而是一副更轻量、也更务实的 AI 眼镜，路线更接近已经上市并跑通市场的 Ray-Ban Meta。

它的工作方式其实不难理解：靠摄像头“看”，靠麦克风“听”，靠扬声器“说”，再把拍照、接电话、放音乐、导航、识别眼前事物这些能力，交给一套更聪明的 Siri 来调度。

问题在于，这件事听上去简单，真做起来却一点都不轻松。

眼镜是直接挂在脸上的设备，重量、续航、散热没有一项能糊弄。稍微处理不好，要么压鼻梁，要么烫耳朵，要么撑不过两小时就没电。摄像头怎么摆才能兼顾视角和隐蔽性，扬声器怎么做到通话清晰又不明显漏音，这些都属于苹果最擅长、但也最耗时间打磨的硬骨头。

但这次跳票，硬件恐怕还不是最核心的原因。

真正拖后腿的，还是 AI，准确说，是 Siri 还带不动这副眼镜。

苹果这两年大力推进 Apple Intelligence，可实际体验大家并不陌生：复杂一点的对话容易卡壳，多轮上下文理解经常断片，视觉识别也还没成熟到让人放心把大量日常交互交给它。对于手机来说，这顶多意味着体验不稳定；可对于一副几乎完全靠语音和感知驱动的 AI 眼镜来说，这会直接决定产品是不是成立。

如果 AI 做不到随叫随到、看得懂世界、也能流畅交流，那这副眼镜最后很可能只会沦为一台更贵的运动相机，或者一个会弹通知的蓝牙耳机。苹果显然不愿意让这样的半成品仓促上市。它宁可延期，也不想先把东西推出去，再让用户替自己补课。

所以这次延期，其实也等于变相承认：Apple Intelligence 的补课还没有结束。

问题是，市场未必会一直等苹果。

从 2023 年开始，AI 眼镜这条赛道已经明显提速。Meta 和雷朋合作的 Ray-Ban Meta 不只是出了第二代，更重要的是，它已经提前教育了一批用户开始习惯“戴着眼镜拍照、直播、呼叫 AI 助手”。国内厂商也没闲着，Rokid 等玩家围绕翻译、支付、提词、会议记录这些更接地气的功能，把产品快速推向市场。哪怕产品还不完美，它们至少先占住了场景，也换回了真实反馈。

如果苹果要到 2027 年底才把产品端出来，别人很可能已经又跑完一到两个完整周期。届时更成熟的不只是硬件本身，还包括软件生态、用户心智和供应链节奏。

苹果当然有自己的打法。过去很多品类都是这样：先让别人探路，等技术、生态和成本都差不多成熟，再用一款体验完成度更高的产品进场，一锤定音。iPod、iPhone、AirPods 都是这么赢的。

可 AI 眼镜和当年的智能手机、无线耳机不太一样。这个市场的窗口期更短，迭代速度更快，大家几乎是在按季度往前冲，没有谁会站在原地等苹果慢慢打磨。等苹果真正入场时，面对的可能已经不是一片蓝海，而是一个格局初步成形、用户习惯已经被别人提前拿走的成熟市场。

这也是这次跳票真正值得注意的地方：它暴露出的不只是苹果硬件节奏变慢，而是 AI 能力本身，尤其是 Siri，还没有准备好承接下一代可穿戴入口。

苹果的底牌当然还在。它依然拥有极强的品牌号召力，也有从芯片到系统再到生态链的完整控制力。但在 AI 眼镜这件事上，苹果这次面对的，不再只是“晚一点也没关系”的传统节奏，而是一个正在高速抢位的新入口。

说到底，AI 眼镜能不能成立，核心不在镜框，而在大脑。现在看，苹果的镜框还没来，真正没准备好的，可能是 Siri。