2026年

• 1: 2026年的概述
• 2: 加州 AB 316：自主行为的责任归属
• 2.1: 加州 AB 316（材料）
• 2.2: 加州 AB 316 讲解
• 3: OpenClaw 爆红
• 3.1: OpenClaw 爆红（材料）
• 3.2: OpenClaw 爆红 讲解
• 4: Claude Cowork
• 4.1: Claude Cowork（材料）
• 4.2: Claude Cowork 讲解
• 5: Open Responses
• 5.1: Open Responses（材料）
• 5.2: Open Responses 讲解
• 6: Claude Opus 4.6
• 6.1: Claude Opus 4.6（材料）
• 6.2: Claude Opus 4.6 讲解
• 7: Claude Managed Agents
• 7.1: Claude Managed Agents（材料）
• 7.2: Claude Managed Agents 讲解
• 8: OpenAI Agents SDK（2026 更新）
• 8.1: OpenAI Agents SDK 2026（材料）
• 8.2: OpenAI Agents SDK 2026 讲解
• 9: Stripe 面向 Agent 的计量与支付
• 9.1: Stripe Agent 支付（材料）
• 9.2: Stripe Agent 支付 讲解
• 10: Google Agent Executor (AX)
• 10.1: Google AX（材料）
• 10.2: Google AX 讲解
• 11: Claude Fable 5 / Mythos 5
• 11.1: Fable 5 / Mythos 5（材料）
• 11.2: Fable 5 / Mythos 5 讲解
• 12: 美国出口管制暂停 Fable 5 / Mythos 5
• 12.1: 出口管制事件（材料）
• 12.2: 出口管制事件 讲解
• 13: Claude Tag
• 13.1: Claude Tag（材料）
• 13.2: Claude Tag 讲解
• 14: Agent identity
• 14.1: Agent identity（材料）
• 14.2: Agent identity 讲解
• 15: Claude Sonnet 5
• 15.1: Claude Sonnet 5（材料）
• 15.2: Claude Sonnet 5 讲解
• 16: GPT-5.6（Sol / Terra / Luna）
• 16.1: GPT-5.6 家族（材料）
• 16.2: GPT-5.6 家族 讲解
• 17: Claude Opus 5
• 17.1: Claude Opus 5（材料）
• 17.2: Claude Opus 5 讲解
• 18: Aries
• 18.1: Aries（论文）
• 18.2: Aries 讲解
• 19: 欧盟 AI Act 第 50 条：Agent 必须披露身份与委托人
• 19.1: 欧盟 AI Act 第 50 条（材料）
• 19.2: 欧盟 AI Act 第 50 条 讲解
• 20: SpecBox
• 20.1: SpecBox（论文）
• 20.2: SpecBox 讲解
• 21: Snowflake Cortex Agents
• 21.1: Snowflake Cortex Agents（材料）
• 21.2: Snowflake Cortex Agents 讲解
• 22: CrowdStrike 的 Agent 身份与运行时管控
• 22.1: CrowdStrike Agent 身份（材料）
• 22.2: CrowdStrike Agent 身份 讲解
• 23: GPT-6 Astra
• 23.1: GPT-6 Astra（材料）
• 23.2: GPT-6 Astra 讲解
• 24: 开源权重模型达到 Agent 可用
• 24.1: 开源权重线（材料）
• 24.2: 开源权重线 讲解

1 - 2026年的概述

一句话主线： 2026 年，个体编码 Agent 已经是开发者日常；新约束是 团队里那一个 Agent 用谁的权限、在谁的频道里执行、沙箱如何跟得上异步委派。1 月 OpenClaw 把自托管个人 Agent 送上舆论顶点；同月 Cowork 把 Claude Code 的循环做成非开发者桌面 Agent。4–5 月，Anthropic、OpenAI、Google 在同一季度把运行时拆成「控制面 + 执行面」——托管服务、库、自托管三条路同时出现同一个形状。Claude Tag 则把同一套云端沙箱引擎放进 Slack，用组织级 Agent Identity 而不是每人自建 Gateway。Aries / SpecBox 从云基础设施侧证明：执行路径和沙盒调度，已经和模型智力同样限制能做什么。

上一页：2025。深挖：Claude Tag、Aries、SpecBox。今天是 2026-09，这一页写的是上半年到初秋已经发生的事，不是全年闭合的编年。

和 LLM 的关系

模型仍在涨（Tag 默认 Opus 4.8 一类前沿核心），但 Agent 史的主矛盾外移了。决策核心够用之后，稀缺资源换成身份与供给。

• 模型线在 2026 换了问法。 上半年的关键词是长程：compaction 与 agent teams 把「跑得久、开多条线」收进核心；三档划分与中档降价把「能自主跑」下放到更低的价位。年中之后关键词变成验证——Opus 5、GPT-6 Astra 都强调「确认做对了再收工」。核心不再只是选下一步，也开始承担「这一步对不对」。
• 决策核心够用到可以暴露系统问题。 当循环能跑数小时、能开 PR、能查数仓，瓶颈变成：凭证能不能进沙箱、出站要不要白名单、空闲后工作区是否还在、频道里谁有权转向。这些不是更多 CoT 能解决的。
• 模型访问权第一次可被当场关掉。 6 月的出口管制事件证明前沿模型的可用性不只由厂商决定；同年的开源权重线给出另一面——同档能力开始有可自托管的替代。可替换性从优化项变成架构前提。
• 同一引擎，多个表面。 Claude Tag 文档写明：频道里的工作跑在与 Claude Code on the web 相同的短暂沙箱上。模型层没有换一种 Agent 物理，产品层换了「谁在委派、谁看得见」。控制协议没有新发明，生命周期和权限模型有。
• 推理/编码模型继续分化，但不再单独定义品类。 2025 是运行时之年；2026 是运行时被嵌进组织工作流之年。LLM 提供决策，组织提供 scope、bundle、审计。

里程碑

每条一个分类，标签可多个（六类历史角色）。Tag 机制文档与 Slack 切换并进 Claude Tag，不另占行。

刻意不升格的：所有「我们也有 Slack 机器人」的跟风稿；把 Tag 的 Beta 限制（Team/Enterprise、需 Owner、与 ZDR 不兼容）写成已经普及；国内「龙虾套壳 / 安装会」作为热度衍生品；以及任何尚未被第三方复现的 2026 下半年路线图。

能力栈切片

模型层

前沿模型继续当决策核心，编码与长程工具使用足够支撑团队场景。新故事不在又一个基准涨 5 分，而在同一模型被套进不同身份和沙箱策略。频道 session 与私信 session 用不同身份，是产品规则，不是权重文件里的分层。

框架 / 协议层

MCP / Skills 被 Tag 当组织级 connections 和 skills repo 来用：管理员按 scope 配 bundle，而不是每个成员在 claude.ai 上接自己的 connector。A2A 仍偏企业平台叙事，Tag 的「多人转向同一个 session」是产品层的多驾驶员，还不是 A2A 互操作。

身份模型本身接近一层新协议：Agent Identity + Agent Proxy + Access bundle + scope。词见 术语表。主体（principal）第一次从「借用用户 OAuth」里拆出来。

应用层

编码 Agent 从「我的终端」扩展到「我们的频道」。与此同时，三条个人/组织表面并排，不要合成一种产品：

1. OpenClaw：自托管 Gateway，聊天软件指挥本机。
2. Cowork：厂商桌面应用，指定文件夹做知识工作。
3. Claude Tag：组织频道、共享身份、可旁观。

客诉汇总、法务审材料、数仓问答、缺陷复现开 PR——Anthropic 内部案例写在 Tag 资料列表第五阶段。Cowork / Claude Code 仍管个人文件与本地仓库；Tag 管共享、异步、可旁观。最小循环没有换，换的是委派面和可见性。

基础设施层

2026 年第一次把执行基础设施写成主线：

• 控制面与执行面分开——Managed Agents 写成 session / harness / sandbox 三接口，Agents SDK 写成 harness / compute separation，AX 写成从可挂起镜像供给执行环境
• 短暂沙箱生命周期（建、跑、闲、释放、回复再重建）——见 How Claude Tag works
• 凭证不进沙箱——4 月两家各自写进设计（Managed Agents 的工程博客、Agents SDK 的公告），6 月见 Security and data handling
• 云上 Agent 负载的测量——Aries
• 沙箱就绪与调度——SpecBox

评测仍在（SWE-bench 家族），但组织场景缺少等价于 SWE-bench 的「频道任务」谓词。审计日志、花费上限、RBAC 成为产品功能，而不只是安全附录。系统闭环了，治理闭环还没有。

还做不到什么

截至 2026 年 9 月：

• Slack 之外的默认团队表面。 Tag 从 Slack 起步，扩展是目标不是现状。
• JIT 凭证与身份叠加。 博文里的未来项：单次敏感动作当场批，以及「频道 profile ∩ 用户权限」。尚未当成年内已交付的事实。
• 自托管环境里用满 Access bundle。 文档写明自托管 runner 上还不能用 bundle。
• ZDR 组织。 频道记忆和 transcript 需要保留，Zero Data Retention 与 Tag 互斥。
• 把沙箱调度问题做完。 SpecBox / Aries 是问题定义和一条系统路线，不是业界已经换完的新底盘。
• 个人计划与第三方部署。 Tag 只在 Anthropic 第一方的 Team/Enterprise。
• 知识工作 Agent 变成组织员工。 Cowork 把循环接到个人文件夹，身份仍是使用者的账号，不是频道共享的 Agent Identity。
• 模型的可用性掌握在自己手里。 6 月出口管制后，依赖单一前沿模型的产品必须假设它会突然消失。可替换的核心、沙箱、协议都不是可选项。

2 - 加州 AB 316：自主行为的责任归属

加利福尼亚州，2025-10-13 由州长签署（Chapter 672），2026-01-01 生效。新增民法典 § 1714.46：在指控 AI 造成损害的诉讼中，被告不得以「AI 自主造成了损害」作为抗辩。条文对 AI 的定义是泛化的（「一种自主程度可变的、工程化的或基于机器的系统」），通篇没有出现 agent 一词。

1. 材料 — 按法条原文转述：生效日、可援引条款、边界与没规定的事。
2. 讲解 — 它管的是后果归属，不是 Agent 类别；「不是我，是它自己干的」从此不是答案。

法条原文：AB 316, Civil Code § 1714.46。

2.1 - 加州 AB 316（材料）

主要出处：加州立法信息网，AB 316 全文（Chapter 672，2025-10-13 签署）。本页不复制全文。

生效日

法案本身没有写生效日，也没有 urgency 条款。按加州宪法的默认规则（第四条第 8(c)(1) 款），无 urgency 的法案在次年 1 月 1 日生效——即 2026-01-01。注意这个日期不印在法案文本里。

核心条款

§ 1714.46 (b) 的原文意思是：在针对开发、修改或使用了 AI 的被告提起的诉讼中，被告不得提出、也不得主张「是 AI 自主造成了原告的损害」这一抗辩。

定义（(a) 款）用的是泛化表述：「一种自主程度可变的、工程化的或基于机器的系统」。全文没有出现 agent 或 agentic 字样。

(c) 款保留其他积极抗辩，以及关于因果关系、可预见性、比较过失的证据——即这条只堵住「自主」这一条路，不改变其他归责要件。

它没有规定的事

• 不要求审计或留痕。没有日志、记录保留、披露义务。
• 不定义 Agent 类别。它管的是自主行为造成的后果由谁负责，不是「什么算 Agent」。
• 不针对特定技术。任何「自主程度可变」的系统都在范围内。

同期需要分辨的一条

加州的 AI 透明度法（SB 942）不是 2026-01-01 生效——由 AB 853（Chapter 674）修订后的条文写明「本章自 2026 年 8 月 2 日起施行」。网上流传的「1 月 1 日生效」是错的。

2.2 - 加州 AB 316 讲解

当时解决了什么问题

自主系统带来一个归责难题：如果损害由模型自主做出，被告能不能说「这不是我决定的」？AB 316 的回答很干脆——不能。开发、修改、使用 AI 的人，不能拿自主性当挡箭牌。

这条对做 Agent 平台的人有直接含义：「模型自己选的」不是免责事由。工具调用的授权、沙箱的边界、动作的审批，都得由设计者负责——因为它们都是人定的。

要说清的边界

1. 它不管 Agent 定义。条文用的是「自主程度可变的系统」，全文没有 agent 字样。用词上的回避是有意的：立法者不想争论什么算 Agent。
2. 它不管审计。没有任何留痕、日志、披露要求。这意味着「出了事谁负责」有了答案，「怎么查清出了什么事」还没有。
3. 它是州法，不是联邦法。截至 2026 年 9 月，没有任何一个美国州法在 2026 年生效且明确点名「AI agent」或「agentic AI」——碰自主性的都用泛化表述。这个否定结论本身值得记。

对后续 LLM 与 Agent 的影响

把这条和同年 8 月的欧盟 AI Act 第 50 条指南并排看，两个法域走了两条路：欧盟要求「说清楚是谁在行动」，加州要求「别拿自主性推责」。一个管上游披露，一个管下游归责。

对平台设计，两条合起来给出的约束是：动作要能追溯到委托人，行为要能解释。审慎地说，目前法律只要求前者的一半（披露），后者（审计）仍是空白——2027 提纲里值得继续盯的正是这块。

3 - OpenClaw 爆红

2026 年 1 月：商标迫使 Clawdbot → Moltbot → OpenClaw；GitHub 星与实例数在数周内进入现象级。中文互联网称「养龙虾」。

1. 材料 — 按 2026-01 公开事件转述：改名、热度、已出现的安全讨论。
2. 讲解 — 自托管 Agent 的 AutoGPT 时刻；出生与爆红切开；热度 ≠ 敢用。

2025 年仓库起点见 OpenClaw（龙虾）。项目：openclaw.ai、GitHub。

3.1 - OpenClaw 爆红（材料）

本页转述 2026 年 1 月现象级传播当时公开发生了什么。2025-11-24 仓库与产品形态见 2025 材料。

主要出处：项目 lore From Clawd to OpenClaw；报道如 少数派、BBC 中文。星标以 GitHub 当时快照为准，本页只写数量级，不假装精确到个位。

改名（2026-01）

Anthropic 就名称与 Claude 过近发出礼貌但法律上必要的沟通。项目 1 月 27 日前后改为 Moltbot（蜕壳），1 月 30 日再改为 OpenClaw。GitHub、文档、npm、X 账号在短时间内迁移。骗子几乎立刻用旧美术发币——lore 自己写了这一笔。

热度

仓库创建八周后进入主流视野。1 月底报道已写到约 10 万星、单周大量访问；此后数月星标与公开实例继续涨（2026 年春夏进入数十万星量级）。中文侧把安装、配模型、喂上下文叫「养龙虾」；卸载叫「卸龙虾」。腾讯、百度等随后有安装/套壳活动——那是跟风，不是 1 月的源代码本身。

当时已经并排存在的反方

自托管意味着 Gateway 能碰文件、shell、聊天历史。公开讨论很快包括：暴露在公网的实例、密钥泄漏、恶意 skill、误删文件。这不是 2026 年下半年才发明的批评。企业侧后来出现禁用办公网安装的通知，是热度的另一面。

当时不是什么

不是厂商托管的企业 Agent 平台，没有中央 kill switch。也不是「已经安全的个人操作系统」。Foundation / 作者加入 OpenAI 是更晚的治理新闻，不写进 1 月爆红当天。

3.2 - OpenClaw 爆红 讲解

当时解决了什么问题

2025 年官方运行时教会开发者「在终端里委派」。还缺一种人人能传的形态：开源、自己的电脑、自己的聊天软件、一只龙虾表情。2026-01 的改名周把这个形态送上舆论顶点。仓库出生在 2025-11；热度、养虾与暴露面是这一月的事。按定义它 是 Agent，而且往往比 IDE 助手更少人盯着——正因为此，权限面等于机器本身。

对后续 LLM 与 Agent 的影响

记法对齐 2023 年 AutoGPT：引爆记热度，可靠性与安全另记。Aries 把 OpenClaw 写成开源 harness 样本，说明它不是纯 meme，已经成为可测的负载。Claude Tag 走的是组织配身份的反方向：不要把 shell 和密钥交给每人自建的 Gateway。两者会长期并排——个人自托管 vs 企业工作区——不要合成一句「Agent 已经住进每个人的电脑」。国内套壳、安装会、卸虾生意，是热度衍生品，不单独升格。principal 仍是机主，不是 Tag 那套 Agent Identity。

4 - Claude Cowork

Anthropic，2026-01-12。口号是 Claude Code for the rest of your work：同一套 agent 架构，不进终端，对着本机文件夹干活。

1. 材料 — 按 1 月 12 日研究预览当时转述。不把后来的网页/移动端与全付费档回填。
2. 讲解 — 循环未换，principal 是用户划的目录；和龙虾、Tag 不是同一条产品。

当时报道：TechCrunch、The Verge。产品页：claude.com/product/cowork。中文入门：开始使用 Claude Cowork。

4.1 - Claude Cowork（材料）

本页转述 2026-01-12 研究预览当时公开说了什么。现网产品页已演进出网页/移动端、定时任务、内置浏览器和更多套餐，那些不写进「当天」。

主要出处：Anthropic / Claude 当日公告（口号 Introducing Cowork: Claude Code for the rest of your work）；同期报道 TechCrunch、The Verge。中文说明（后出，只作对照）：开始使用 Claude Cowork、什么是 Claude Cowork。

产品主张（当天）

Claude Code 原为终端里的软件工程循环。内部和外部用户很快拿它做几乎所有事，不只写代码。Cowork 被写成同一条能力的简化入口：不必开终端，给 Claude 本机上的一个文件夹，它就可以在该文件夹里读、改、新建文件。任务用日常语言交代；Claude 做计划、逐步执行，重大动作前询问。已有 connectors 可接外部信息；需要浏览时，可与 Claude in Chrome 配对。

公告自己举的例子：整理下载目录、从一堆截图做出费用表、从零散笔记写出初稿。架构上与 Claude Code 共用 agent 循环（报道写 Claude Agent SDK），差别在表面和任务域：知识工作，不是仓库。

范围与警告（当天）

研究预览。当时可立刻用的是 Claude Max + macOS 桌面应用；侧栏点 Cowork。其他套餐走等待名单。公告写明计划扩到 Windows 与跨设备同步，那是路线，不是 1 月 12 日已交付。

风险写进发布说明本身：指令含糊时可能误删文件；提示注入不是新问题，但「第一次用会动文件的工具」会把风险送到非开发者面前。建议权限收在单个文件夹，并自己留备份。

当时不是什么

不是 Slack 里的团队员工（那是半年后的 Claude Tag）。不是自托管 Gateway（同月爆红的是 OpenClaw）。不是网页版 Chat 里新建一个附件按钮——权限模型是指定本地文件夹。当天也不是全套餐、全平台可用。

4.2 - Claude Cowork 讲解

当时解决了什么问题

Claude Code 证明：终端里的多步循环能收工。大量人却拿它整理文件、做表、写稿——任务不是软件工程，工具却是开发者的。Cowork 去掉终端，把同一套「计划 → 动文件 → 看结果」接到桌面文件夹上。循环没有新发明；换的是动作对象（目录树而非 git 工作副本）和操作表面。

按定义这 是 Agent：多步、对环境行动（文件系统与已连接工具）、按回执再决策。人在环路仍在：重大动作要问。权限由用户划文件夹——principal 是使用者账号，不是频道共享的服务身份。

对后续 LLM 与 Agent 的影响

2026-01 同时出现两条「Agent 住进日常」的表面，不要合成一种产品：

• OpenClaw：开源、自托管、从聊天软件指挥你的机器。热度高，暴露面等于主机。
• Cowork：厂商桌面应用、指定文件夹、付费档研究预览。循环同源 Claude Code，治理仍是「你的 Max 账号 + 你划的目录」。

半年后的 Claude Tag 再换一层：共享频道、组织身份。Tag 博文自己拿 Cowork / Claude Code 当熟悉感参照——个人文件与本地仓库仍归这两条，频道协作归 Tag。模型可以共用，权限模型不能混写。

5 - Open Responses

2026-01-15 发布，Apache-2.0。厂商中立的 LLM API 规范（客户端 ↔ 模型提供方），schema 源自 OpenAI 的一方 API。核心维护者来自 OpenAI、Databricks、Amazon、Hugging Face、Ollama、OpenRouter 等；治理条款写明任何单一厂商不得占据多数核心维护者席位，且所有治理角色由个人而非组织担任。

1. 材料 — 按仓库与规范转述：发起方证据、治理条款、规范内容、以及「不是 OpenAI 官方发布」这一区分。
2. 讲解 — 它是模型接口层，不是 Agent 通信层；与 MCP / A2A 不在同一层。

规范与仓库：openresponses.org、openresponses/openresponses。

5.1 - Open Responses（材料）

主要出处：openresponses/openresponses（Apache-2.0，仓库创建于 2026-01-15）、其 CHANGELOG 与 CONTRIBUTING、以及 openresponses.org 的治理页。

发起方：要区分「谁维护」与「谁发布」

• 变更日志写明：2026-01-15 作为开放的多供应商规范发布。
• 首席核心维护者是 OpenAI 的员工，核心维护者名单覆盖 Databricks、Amazon、Hugging Face、Ollama、OpenAI、OpenRouter。
• 规范 schema 的说明写明：schema/ 下的 OpenAPI 源文件复制自 OpenAI 的一方 API。

但要分清：找不到 OpenAI 的官方公告页。OpenAI 官方新闻源里没有这条，站内也只有 Responses API 的功能页。所以正确表述是——由 OpenAI 员工主导维护、schema 源自 OpenAI 一方 API 的开源规范，不是「OpenAI 官方发布的标准」。

治理条款

原文两条值得记：

• 「任何单一厂商不得控制多数核心维护者席位。」
• 「所有治理角色由个人而非组织担任。」

规范内容

• 一个 agentic loop：让模型发出工具调用、接收结果、继续。
• items 作为上下文的原子单位。
• 语义化的流式事件，而不是原始文本增量。
• 默认无状态，可扩展。

后续 2026-04-24 的版本加入 WebSocket 传输、/v1/responses/compact 与 phase 字段。

当时不是什么

它不是 Agent 通信协议。它管的是客户端与模型提供方之间的接口形状，与 MCP（模型↔工具与资源）、A2A（Agent↔Agent）不在同一层。放进时间线时按「模型接口层的标准化尝试」记，不要与工具总线并列。

5.2 - Open Responses 讲解

当时解决了什么问题

2024–2025 年，Agent 的接线分三层：模型↔工具（MCP）、Agent↔Agent（A2A）、以及客户端↔模型提供方。前两层有公开协议，第三层一直是一方 API 的形状——换供应商就要改代码。

Open Responses 处理的是第三层：把「一个能发工具调用、收结果、继续」的循环写成规范，并保留语义化的流式事件（而不是让调用方自己去解析文本增量）。

值得单独记的一点：治理设计

发起方是一家厂商的员工，schema 也来自一家的 API——这本来很像「事实标准的单方面输出」。但治理条款写了两条反向约束：任何单一厂商不得占多数维护者席位、治理角色由个人而非组织担任。

这与 A2A 由 Google 发起、MCP 由 Anthropic 发起的路径不同：这一次从一开始就把「不被一家控制」写进了规则。是否奏效要看后续，但作为设计选择，它是 2026 年协议治理的一个新样本。

对后续 LLM 与 Agent 的影响

对时间线的意义在于分层：不要把这条和 MCP / A2A 混成一类。它们各管一层接线，调研方法 里说的「协议」是这一层的统称。

也需要克制：截至 2026 年 9 月，它的采纳仍集中在模型供应商与推理服务侧，没有出现跨厂商的强制采用。按「标准」标签的门槛（多方默认）看，它还没到。它同样不满足「工程化」的门槛（把某项此前只被演示、未被交付的能力第一次交到他人手上），因此本条不带标签。

6 - Claude Opus 4.6

Anthropic，2026-02-05。厂商称其「规划更谨慎、能维持更长的 agentic 任务」，并在 Opus 级首次提供 1M token 上下文（beta）。同日 Claude Code 增加 agent teams（多智能体组队），API 侧增加 compaction（自主压缩上下文以跑更长任务）、adaptive thinking 与 effort 控制。

1. 材料 — 按官方公告转述：长程与规划、1M 上下文、agent teams、压缩与 effort。
2. 讲解 — 长程与并行第一次从「应用要自己拼」变成核心侧能力。

当时公告：Claude Opus 4.6。

6.1 - Claude Opus 4.6（材料）

主要出处：Anthropic，2026-02-05，Claude Opus 4.6。本页不复制公告全文。

公告说了什么

• 规划与长程：原文写它「plans more carefully」，并且能维持更长的 agentic 任务；可在更大的代码库里可靠运行，具备自我纠错的代码审查与调试能力。
• 上下文：Opus 级首次提供 1M token 上下文（beta）。
• Claude Code 的 agent teams：多智能体组队成为产品内的一等能力，而不是应用层自己搭的拓扑。
• API 侧：新增 compaction（自主压缩上下文以跑更长任务）、adaptive thinking、以及 effort 档位控制。

厂商自报的基准

公告声称在 Terminal-Bench 2.0 上取得最高分，HLE 领先，GDPval-AA 上超出 GPT-5.2 约 144 Elo。这些均为厂商自报，评测口径随公告一并给出，时间线按主张记，不作独立结论。

当时不是什么

不是新世代模型名称的换代，也不是循环语义的变化。它改的是核心能维持多久、能同时开几条线——这两件事此前主要靠应用层的上下文管理与多进程编排来解决。

6.2 - Claude Opus 4.6 讲解

当时解决了什么问题

2025 年解决「跑得久」的办法基本都在核心之外：外部记忆、截断、重启一轮、把任务切碎交给多个进程。GPT-5.2-Codex 第一次把上下文压缩写进模型侧，Opus 4.6 把同一件事做成 API 能力，并且同时给了两个东西：1M 上下文（装得下）和 compaction（装不下时自己压）。

另一半是并行。此前多智能体是应用层的拓扑设计——谁跟谁说话、谁汇总，都要开发者自己写。Building effective agents 当时还专门劝过不要动不动上多 Agent。agent teams 把这件事收进产品：组队成为运行时提供的能力，而不是应用要发明的架构。

对后续 LLM 与 Agent 的影响

这两条决定了 2026 年后半年的运行时形态。当核心能自己压缩、自己组队，运行时要管的就只剩环境——环境活多久、凭证放在哪、谁批准动作。这正是 Managed Agents 与 Agent Tag 那一串事件要处理的问题。

边界要说清：这是核心的能力，不是 Agent。压缩与组队都发生在模型与运行时之间，按定义第四条（反馈后再决策）看，它改善的是循环的续航，不是循环的存在。

7 - Claude Managed Agents

Anthropic，2026-04-08。托管的长时程 Agent 服务，把 Agent 虚拟化成三个接口：session（发生过什么的可追加日志）、harness（调用模型并把工具调用路由到基础设施的循环）、sandbox（跑代码与改文件的执行环境）。三者可各自替换。会话按 session-hour 计费；沙箱可托管也可自托管。

1. 材料 — 按工程博客与官方文档转述：拆哪三个接口、为什么拆、凭证边界、权限与计费。
2. 讲解 — 「进程活着」不再是正确性前提；这是 2026 供给线的骨架。

工程博客：Scaling Managed Agents: Decoupling the brain from the hands。定价：claude.com/pricing。

7.1 - Claude Managed Agents（材料）

主要出处：Anthropic 工程博客，2026-04-08，Scaling Managed Agents: Decoupling the brain from the hands；官方文档（Managed Agents overview 等）与定价页。本页不复制原文。

拆开的是哪三样

工程博客的说法是把 Agent 虚拟化成三个接口：

• session —— 「发生过什么」的可追加日志；
• harness —— 调用 Claude、并把 Claude 的工具调用路由到相应基础设施的那个循环；
• sandbox —— Claude 跑代码、改文件的执行环境。

三者可以各自替换实现而互不干扰。博客写得很直白：对接口的形状有主张，对接口后面跑什么没有主张。

为什么拆：从 pet 到 cattle

最初三样装在一个容器里。好处是「文件编辑就是直接的系统调用，没有服务边界要设计」。但这就养了一只 pet：容器挂了，session 就没了；容器不响应，只能护理它。而排查只有 WebSocket 事件流一个窗口——harness 的 bug、事件流丢包、容器离线，三者长得一模一样，工程师没法定位。

还有一个假设被写死在 harness 里：Claude 要处理的东西就在容器旁边。客户要把 Claude 接到自己的 VPC，就只能对等网络，或者在客户环境里跑 Anthropic 的 harness。

解耦之后：harness 像调任何工具一样调容器，容器死了就当作一次工具调用错误交回给 Claude；Claude 决定重试就重建一个。harness 自己也变成 cattle，可以从最后一条事件续跑。

凭证边界

博客的原话是：结构性的修法是保证 token 永远不可能从跑模型生成代码的沙箱里被够到。Git 场景在沙箱初始化时克隆仓库并把 token 接进本地 remote；自定义工具走 MCP 加 vault。harness 始终不知道任何凭证的存在。

产品形态与计费

官方文档把它定义为「预置的、可配置的 agent harness，跑在托管基础设施上；适合长时程任务与异步工作」，核心概念是 Agent / Environment / Session / Events。当时是 Beta。

定价页写明：标准 token 费率照收，外加 $0.08 per session-hour 的 active runtime；运行时按毫秒计，只在会话状态为 running 时累加——空闲等消息、等工具确认、重排、终止都不计费。文档另说明：session runtime 取代了原来的容器小时计费模型，不再单独收容器费用。

权限策略有三档：always_allow / always_ask / auto；文档写明 agent 自带工具默认 always_allow，MCP 工具默认 always_ask。

当时不是什么

不是新模型，也不是新循环——循环形状没变。它改的是循环住在哪、活多久、以什么身份：可以有自托管沙箱（编排留在 Anthropic 侧，工具执行留在你自己的基础设施里），可以把记忆挂在沙箱的 /mnt/memory/ 下并保留不可变版本，可以按 session 设预算。这些在 2026 年 4 月都还是 Beta。

7.2 - Claude Managed Agents 讲解

当时解决了什么问题

2025 年的运行时——Claude Code、云端 Codex——把循环装进一个「装上即委派」的产品里，但循环与执行环境是长在一起的：容器死了，会话就没了。对单次开发会话够用；对要跑几小时的异步任务就是硬约束。

这一步把 Agent 拆成三个可替换的接口：session（日志）、harness（循环）、sandbox（执行环境）。拆开之后，容器死亡降级成一次工具调用错误，harness 崩溃可以从事件日志续跑。「进程一直活着」从正确性前提变成了实现细节——这是这条线的关键变化。

第二个变化是凭证边界：token 不进沙箱、harness 不知道凭证存在。这让「模型生成代码跑在哪儿」与「密钥放在哪儿」第一次成为两个可以分别回答的问题。

第三个变化容易被忽略：计费单位。$0.08/session-hour 按 running 状态毫秒计费，是「Agent 运行时按会话时长计价」的首个一手定义——前面 阿里云 AgentRun 是产品侧的同类主张，但没有给出这么明确的计价语义。

对后续 LLM 与 Agent 的影响

把它和同期两家放在一起看，2026 年上半年的架构命题是同一个：

三家独立收敛到同一形状，说明这不是某家的产品选择，而是长时程 Agent 对执行层的必然要求。这也解释了为什么 Claude Tag 后来能直接把同一套短寿沙箱引擎搬进 Slack——引擎与委派面已经解耦了。

要注意边界：本条讲的是运行时怎么组织，不涉及沙箱内部怎么隔离。后者属于另一条线。

8 - OpenAI Agents SDK（2026 更新）

OpenAI，2026-04-15（v0.14.0）。2025 年的 Agents SDK 是编排库；这一版把 harness（指令、工具、审批、追踪、交接、续跑记账）与 sandbox（文件、命令、包、产物、隔离）显式拆成两层，并让沙箱供应商可插拔。Python 先行。

1. 材料 — 按 release notes 与官方公告转述：两层怎么分、Manifest、权限、快照续跑、供应商清单。
2. 讲解 — 库开始内置「环境」这个概念；与同期 Anthropic、Google 同向。

Release notes：v0.14.0。

8.1 - OpenAI Agents SDK 2026（材料）

主要出处：OpenAI，2026-04-15，openai-agents-python v0.14.0 release notes；同日 OpenAI 官方论坛的公告帖（标题即「The next evolution of the Agents SDK」）。官方博客页 openai.com/index/the-next-evolution-of-the-agents-sdk/ 对本机不可访问，本页按上述两处转述。

两层怎么分

公告的措辞是：演进后的 SDK 给模型一个强 harness——指令、工具、审批、追踪、交接、续跑记账，以及 Codex 式 agent 使用的那种模型行为；sandbox 提供 compute——文件、命令、包、产物与隔离。两层可以跑在同一台机器上，也可以分开跑，以获得更好的隔离、持久性与安全性。

公告给出的安全理由值得记：这种分离让凭证与编排留在模型生成代码运行的环境之外。

Manifest：把工作区变成可移植描述

新增 Manifest 抽象，用来描述 Agent 的工作区——暂存本地文件、克隆仓库、创建输出目录、挂载对象存储、挂 Git 仓库。官方说它让同一套流程更容易跨供应商与环境迁移。

权限

文档写明：可以定义 sandbox 用户、把文件权限附着到 Manifest 条目上、让面向模型的工具以指定用户运行；底层映射到标准 Unix 文件权限。给出的例子是：模型对 dataroom/ 只读，同时保留对 output/ 的写权限。

续跑

内置快照与再水化（snapshotting and rehydration）：SDK 可以在一个全新的沙箱里恢复会话，从上次保存的状态继续，而不是从头开始。

沙箱供应商

release notes 列出：本地与容器的 UnixLocalSandboxClient、DockerSandboxClient；托管侧为 Blaxel、Cloudflare、Daytona、E2B、Modal、Runloop、Vercel，另有 bring-your-own 选项。

时间线要分清

• 2026-04-15 发布的是 Python 版（v0.14.0）。TypeScript 侧的 sandbox 相关条目最早出现在 5 月的版本里，所以「当时只有 Python」成立，「TypeScript 计划中」这一说法只有二手来源。
• 这是2025 年 3 月那版的演进，不是新框架。2025 年的条目写的是编排与 tracing，这一版写的是执行环境。

8.2 - OpenAI Agents SDK 2026 讲解

当时解决了什么问题

2025 年的 Agents SDK 是一套编排积木：单/多 Agent、内置工具、tracing，进程是调用方的，跑在哪由开发者自己决定。到 2026 年，长时程任务把「跑在哪」变成了库必须回答的问题——一个跑几小时的 Agent 需要一份能存活的工作区、一套权限、以及容器没了之后能接着来的办法。

这一版的答案是把环境收进库的抽象里：Manifest 描述工作区长什么样，沙箱供应商是可换的实现，快照负责续跑。

三点值得单独记：

1. 沙箱变成可插拔依赖。同一个 Agent 可以今天跑在 Docker 里、明天跑在托管沙箱上——这是 2024-11 MCP 在工具层的思路，被搬到了执行环境层。
2. 权限映射到 Unix 文件权限。听起来朴素，但它是「Agent 能碰什么」第一次用操作系统里已有的语义表达，而不是自定义一套。
3. 凭证与编排不进模型代码的环境。与 Managed Agents 同一天前后的说法几乎一致，两家显然在解同一道题。

对后续 LLM 与 Agent 的影响

这条与 Managed Agents、Google AX 构成 2026 年上半年的同一件事：执行环境从开发者的选型变成运行时的抽象。

区别在于形态：Managed Agents 是托管服务，AX 是自托管运行时，Agents SDK 是库——托管、自托管、库三条路同时存在，且都收敛到「控制面与执行面分开」。这个三分布局本身就是 2026 年供给侧的实况，不该写成某一家的胜利。

9 - Stripe 面向 Agent 的计量与支付

Stripe，2026-04-29（Sessions 2026，一次发布 288 项）。与 Agent 相关的三件：按 token 实时结算的流式支付（用计量引擎精确到每次 token 使用）、Link wallets for agents（每个任务发一张一次性虚拟卡，真实支付信息不暴露给 Agent，每笔支付由人批准）、以及针对 token 盗用的风控。此前 2026-01-14 Stripe 完成对计量引擎 Metronome 的收购。

1. 材料 — 按 Stripe 官方新闻室与文档转述：计量、实时结算、一次性虚拟卡、以及被夸大的那条说法。
2. 讲解 — 改的是经济语义，不是执行语义：Agent 有了自己的支付面，但授权仍握在人手里。

来源：Sessions 2026、Token billing 文档。

9.1 - Stripe Agent 支付（材料）

主要出处：Stripe 新闻室，2026-01-14 Stripe completes Metronome acquisition、2026-04-29 Sessions 2026、2026-08-19 Stripe agrees to acquire OpenRouter；文档 Token billing。本页不复制原文。

三件事，按时间

2026-01-14：完成对 Metronome 的收购。 官方称其计量引擎「已经在为一些最有雄心的 AI 公司提供支持，包括 OpenAI、Anthropic 与 NVIDIA」；公告把「向按用量计费的转变」称为下一个十年的决定性特征。

2026-04-29：Sessions 2026（288 项发布）。 与 Agent 直接相关的两条：

• 面向 AI 商业模式的流式支付。原文的描述是：Agent 以机器速度消耗 token，在企业收到付款之前就产生了真实成本。方案是把精确计量与实时支付接起来，让企业按每一个 token 收款，就在它被使用的那一刻。
• Link wallets for agents。原文：「你的真实支付信息从不暴露给 Agent——每个任务签发一张一次性卡，每一笔支付由你批准。」

2026-08-19：协议收购 OpenRouter（token 路由与优化）。原文提到 Stripe 自去年起已在做 token 成本优化，并推出了 Token Billing 一类产品。

计量能力本身

docs.stripe.com/billing/token-billing（当时为公开预览）按模型与 token 类型（输入、输出、缓存读、缓存写）计量并支持配置加价，会同步 OpenAI / Anthropic / Google 的价格。文档末尾提到可计量的对象包括 token 用量、API 调用、计算时间。

需要更正的一条

流传的「Stripe 于 2026-08-10 推出跟踪 token、tool call 与 agent session 分钟数的计费表」没有一手来源——它只出现在一个已知的 AI 生成 SEO 站点上。Stripe 官方文档里是通用的用量计量，没有「按工具调用」「按 agent 会话分钟」这类专项计量。时间线不采用该说法。

9.2 - Stripe Agent 支付 讲解

当时解决了什么问题

Agent 开始真的花钱：调模型、租沙箱、买数据。此前这笔账落在开发者身上——预充值、配额、事后对账。麻烦出在两头：成本产生的速度和收款的速度不匹配（Agent 以机器速度烧 token），以及授权不可追溯（一次会话里谁批了哪笔）。

Stripe 给的两件东西正对这两头：按 token 实时结算解决速度差，一次性虚拟卡 + 逐笔批准解决授权。

最值得记的不是支付，是那张一次性卡

「真实支付信息不暴露给 Agent，每任务一张一次性卡，每笔支付由人批准」——这是凭证设计，与同期 Managed Agents「凭证不进沙箱」、Agents SDK「凭证与编排不进模型代码环境」是同一个思路的第三种实现：

三条合起来看，2026 年的一个共同答案浮现了：Agent 可以行动，但凭证不由它持有。

对后续 LLM 与 Agent 的影响

按定义，这不是 Agent，也不是执行语义的变化——循环没变，动作接口没变。它改的是经济语义：Agent 成为可以独立计量、独立结算的经济参与者，而授权链仍回到人。

对做平台的人有一条实际含义：成本与权限正在合并成同一个控制面。谁是 principal、它花了多少、哪一步花的，在 2026 年之后是同一套账。

10 - Google Agent Executor (AX)

Google，仓库建于 2026-03-30，首个版本 v0.1.0 于 2026-05-20。定位是分布式 harness 运行时：从可挂起、可恢复的镜像动态供给隔离环境来跑 harness 与 Agent；明确说自己不是托管服务，是自托管运行时，框架无关。配套的 Agent Substrate 负责在 Kubernetes 上大规模调度这些执行环境。

1. 材料 — 按仓库 README 与源码转述：可靠性三机制、与 Substrate 的关系、以及被夸大的协议支持。
2. 讲解 — 同一架构命题的第三种形态：托管、库之外的「自托管运行时」。

仓库：google/ax。配套：agent-substrate/substrate。

10.1 - Google AX（材料）

主要出处：google/ax 仓库（README 与源码，仓库创建于 2026-03-30，v0.1.0 发布于 2026-05-20）；agent-substrate/substrate（仓库创建于 2026-05-13）；项目官站 agentexecutor.io。Google 官方博客对本机不可访问，「2026-05-21 发布」只有二手来源。

自我定位

README 原话：AX 是一个分布式 harness 运行时。它从可挂起、可恢复的镜像动态供给隔离环境来执行 harness 与 Agent；为可靠性设计，即使分布式部署也原生支持恢复与执行续跑。

「AX 不是什么」一节写了两条边界：不是托管服务（AX 是自托管的）；不是 agentic 框架（对用什么框架构建 Agent 不做假设）。

可靠性三机制

• 单写者架构：单一控制器保证状态一致。源码注释写「它作为管理 agentic 循环的单写者系统」。
• 事件日志：持久化的执行状态，自动恢复。
• 高级恢复：在兼容平台上支持 compute 层的 actor 恢复——调度器侧有对应的挂起与恢复操作。

用例上看，客户端发起的交互如果 conversation_id 已存在，就表示恢复一个已有会话而不是新建。

与 Agent Substrate 的关系

AX 在 Kubernetes 上的 Agent Substrate 上有原生支持，这是推荐的生产部署方式。反过来，Substrate 把自己描述为「默认安全的 agent 执行运行时」，用 actor 到 worker 的映射来做高密度调度，支持 microVM 与 gVisor 一类隔离载体，并明说不是 Google 官方支持的产品。

需要更正的说法：协议支持

项目官站声称原生支持 MCP、A2A 等协议。代码里的实际情况不同：主分支源码中检索 a2a / agent-to-agent 为零命中，也没有 AgentService；MCP 则有代码证据。所以按「官站声称支持 A2A，代码未见」记录，不要写成已经支持。LangChain / ADK 的兼容性声明出现在 Substrate 的 README 里，属于 Substrate 的集成面，不是 AX 的能力。

当时不是什么

不是托管产品，不是新协议，也不是新的 Agent 框架。它回答的是运行时那一层的问题：执行环境怎么被供给、怎么被挂起、怎么在崩溃后续跑。

10.2 - Google AX 讲解

当时解决了什么问题

Managed Agents 和 Agents SDK 2026 各自给出了托管服务与库两种答案。AX 补上第三种：自托管运行时——你把它跑在自己的基础设施上，它负责从镜像供给执行环境、维持会话状态、在崩溃后恢复。

它的措辞把这条线的共同点讲得最清楚：从可挂起、可恢复的镜像动态供给隔离环境。注意这里的主体不是沙箱技术，而是执行环境成了一个可以被调度、挂起、恢复的对象——这正是 2026 年供给侧的命题。

对做运行时的人来说还有一处值得记：AX 明确划清「不是托管服务」「不是 agentic 框架」两条边界。它只做运行时那一层，这与 2023 年框架什么都包的做法相反。

对后续 LLM 与 Agent 的影响

三家（Anthropic 托管、OpenAI 库、Google 自托管）在同一季度收敛到「控制面与执行面分开」，说明这是长时程 Agent 的结构性要求，不是产品口味。

要注意可信度分层：AX 当时是早期开发状态（仓库自己标注核心与恢复协议还会大改，并暂停接受外部 PR），官站对 A2A 的支持声称在代码里找不到对应实现。写进时间线时按「自托管运行时的出现」记，不按「又一套生态」记。

配套的 Agent Substrate 自己声明不是 Google 官方支持的产品，这条在引用时不要省略。

11 - Claude Fable 5 / Mythos 5

Anthropic，2026-06-09。Fable 5 与 Mythos 5 是同一个底层模型，唯一区别是安全护栏：Fable 5 公开发布（部分查询会回退到 Opus 4.8），Mythos 5 解除部分护栏、只提供给网络安全防御方与关键基础设施方。厂商称其能力层级高于 Opus，是第一个「Mythos 级」的正式发布。

1. 材料 — 按官方公告转述：Mythos 级定义、两个模型的关系、定价与数据保留要求。
2. 讲解 — 产品分层维度从「能力」换成「护栏」，这是治理结构的变化，不是一次模型升级。

当时公告：Claude Fable 5 and Mythos 5。

11.1 - Fable 5 / Mythos 5（材料）

主要出处：Anthropic，2026-06-09，Claude Fable 5 and Mythos 5。本页不复制公告全文。

「Mythos 级」是什么

公告的脚注给出定义：Mythos 级是能力位于 Opus 级之上的一档 Claude 模型。第一个是 4 月通过 Project Glasswing 发布的 Claude Mythos Preview，接着是本次的 Fable 5 与 Mythos 5。名字取自拉丁语 fabula（被讲述者），与希腊语 mythos 同源。公告明说：区分这两个模型的是安全护栏。

两个模型的关系

同一底层模型，两条分发路径：

• Fable 5：公开发布，部分查询在护栏触发时回退到 Opus 4.8；
• Mythos 5：解除部分护栏，只提供给网络安全防御方与关键基础设施方（Project Glasswing，与美国政府合作）。

定价 $10/$50 per Mtok。要求 30 天数据保留，公告登出后引发客户反弹——这一点在三个月后的 Enterprise Frontier Safeguards 里被正面回应。

厂商自报的能力与安全口径

公告称这两个模型「能比此前任何 Claude 自主工作更久」。护栏触发率厂商自报平均低于 5% 的会话，超过 95% 的会话不触发回退。这些是厂商自报。

当时不是什么

不是新架构，也不是新的 Agent 能力类别。它第一次把安全护栏等级而不是权重规模当作产品分层的维度——同一个模型，公开版与受限版的差别不在能力，在允许做什么。

11.2 - Fable 5 / Mythos 5 讲解

当时解决了什么问题

前沿模型此前只有两条分发路径：全量发布，或者不发布。但 2026 年的能力分布不再是一根轴——最强的模型既能被用来找漏洞，也能被用来补漏洞。把它们一起锁起来，防御方也拿不到；一起放出去，攻击方也拿得到。

Fable 5 / Mythos 5 给出的是第三条路：同一个底层模型，按护栏分层，按受众分发。公开版在某些查询上回退到次一级模型，受限版解禁后只给受信任的机构。

这条选择有代价，而且公告自己承认了：要让护栏可判定，就得能查出绕过——于是有了 30 天数据保留要求。企业客户对此反弹，三个月后 Enterprise Frontier Safeguards 用客户自控云基础设施 + 零保留的方式给了另一个答案。

对后续 LLM 与 Agent 的影响

这是治理结构的变化，不是模型升级。它把「模型能不能用」从二元问题变成能力等级 × 受众 × 护栏的三维问题。三天后发生的事证明了这不是纸上设计——美国出口管制 直接按这条分层关掉了两个模型的访问权。

对做平台的人的意义：模型的可获得性不再只由厂商决定。这是 2026 年之后设计 Agent 系统时必须假设的前提。

12 - 美国出口管制暂停 Fable 5 / Mythos 5

Anthropic，2026-06-12 与 06-30 两篇官方声明。美国政府援引国家安全权限发出出口管制指令，禁止任何外国国民访问 Fable 5 与 Mythos 5——包括境外的、以及美国境内具外国国籍的 Anthropic 员工。指令于当日 17:21 ET 收到，Anthropic 于当天对全部客户停用这两个模型。6 月 26 日 Mythos 5 先恢复对美国机构的访问；6 月 30 日管制解除，7 月 1 日 Fable 5 全球恢复。

1. 材料 — 按两篇官方声明转述：暂停范围、恢复时间线、厂商的反驳与后续框架。
2. 讲解 — 美国第一次用出口管制召回已商用的模型；访问权成为可开关项。

暂停声明：Statement on the US government directive。恢复声明：Redeploying Fable 5。

12.1 - 出口管制事件（材料）

主要出处：Anthropic，2026-06-12，Statement on the US government directive to suspend access to Fable 5 and Mythos 5；2026-06-30，Redeploying Fable 5。本页不复制原文全文。

暂停（2026-06-12）

美国政府援引国家安全权限发出出口管制指令，禁止任何外国国民访问 Fable 5 与 Mythos 5——范围包括境外的用户，以及在美国境内、具外国国籍的 Anthropic 员工。

声明的原话是：「这道指令的实际效果是，我们必须对全部客户立即停用 Fable 5 与 Mythos 5。」指令于当日 17:21 ET 收到。其他模型不受影响。

厂商同时给出反驳：政府方面认为已掌握绕过 Fable 5 护栏的方法；Anthropic 称该手法对应的只是少量已知的次要漏洞，并且其他公开模型同样能发现。

恢复（06-26 → 07-01）

• 2026-06-26：美国方面批准恢复 Mythos 5 对美国机构的访问；
• 2026-06-30：管制解除，公告标题即《Redeploying Fable 5》；
• 2026-07-01（周三）起，Fable 5 全球恢复。

后续

Anthropic 与 Project Glasswing 的伙伴（含 Amazon、Microsoft、Google）开始制定跨行业的 jailbreak 严重性评估框架，并加强与美国政府的发布前测试协作。同期公告说明的安全方向见 Enterprise Frontier Safeguards。

时间线要分清

暂停与恢复两端都有官方专文，是一手。但触发它的政府指令本身不是公开文件——没有可引用的政府原始文本。二手报道中的官员引语不要采信为事实。

12.2 - 出口管制事件 讲解

当时发生了什么

前沿模型的访问权此前由厂商单方面决定：上线、下线、限流、涨价。2026-06-12 出现了第三种情况——政府要求厂商关掉一个已经在售的模型，而且管辖口径是按人（外国国民）而不是按地区或用途。

注意指令的实际效果：因为无法逐用户判定国籍、也无法隔离境内持外国国籍的员工，厂商只能对全部客户停用。这是「按国籍管辖」在一家全球服务上的直接后果。

三天前刚发布的 Fable 5 / Mythos 5 正是这次的对象——把能力分层发布，反而让「关掉最高一档」变成一个可执行的选项。

对后续 LLM 与 Agent 的影响

这是 2026 年最重要的事件之一，原因是它确立了一个先例：模型访问权是可被政府当场开关的。

对做 Agent 平台的人，它改写的是假设而不是能力：

1. 模型可获得性不再只由厂商决定。依赖单一前沿模型的产品，需要假设它会突然消失。
2. 可替换性从「省钱」变成「韧性」。同一批事件里，开源权重模型在 2026 年集体达到 agent 可用水平（见 开源权重线），这两条线合起来才完整。
3. 合规成为部署前提，而不是上线后的附录。

你的 2027 观察提纲 里写「监管与合规若开始决定能不能部署，那是主线，不是附录」——这件事在 2026 年 6 月就发生了，写 2027 时应当把它从「待观察」改成「已发生」。

时间线记法上要克制：触发指令的政府文件不公开，只有厂商两端声明是一手。事件成立，细节不可考。

13 - Claude Tag

Anthropic，2026-06-23。Claude Tag 先在 Slack 上线：Claude 以团队成员加入频道。8 月 3 日旧 Claude in Slack 切到 Tag。

1. 材料 — 按发布博文转述：多人、记忆、ambient、Beta 范围。
2. 讲解 — 组织身份与短寿沙箱；不要把 Beta 写成已经普及。

当时公告：Introducing Claude Tag。本站资料：Claude Tag。

13.1 - Claude Tag（材料）

本页转述 2026-06-23 发布博文当时公开说了什么。身份模型细节见次日 Agent identity；机制深挖见本站 Claude Tag 资料，本页不整页复制。

主要出处：Anthropic，2026-06-23，Introducing Claude Tag。中英对照：发布博文。

产品主张

Claude Tag 是团队与 Claude 协作的新方式。先从 Slack 开始：Claude 可以像团队成员一样加入。向选定频道授权，并连接到所选工具、数据乃至代码库。频道里任何人可 @Claude 委派任务，自己去忙别的。Claude 记住频道里的相关信息，并能规划将来要做的任务。

Anthropic 把它写成 Claude Code 演化的开端：更主动，也更适合整个团队。内部叙事：@Claude 已成为推进工作的主要方式之一；产品团队约 65% 的代码由内部版 Tag 产出（厂商自报，不是独立审计）。同一模式超出工程：追指标、处理支持工单、帮定位缺陷。

即日起 Claude Enterprise 与 Team 可以 beta 使用。目标是扩展到团队工作的其他表面，当时交付的是 Slack。

使用方式（博文自己列的）

用过 Claude Code 或 Cowork 会有熟悉感：用简单的话提出请求，它拆成阶段，用已有工具推进，完成后在 Slack 线程里回复产物。相对个人聊天，博文强调三点：

• 多人： 一个频道里只有一个与所有人互动的 Claude；谁都能看见它在做什么，也能从上一任停下的地方接续。
• 随时间学习： 跟进频道积累上下文；若授权，还可从其他频道和数据源学习（不从私有频道向外汇报）。
• 主动： 若开启 ambient，会主动更新它认为你该知道的事，跟进沉寂未决的线程或任务。

管理员侧：配对 Slack、给工具、设组织月度花费上限、先在私有频道测试。Tag 取代现有 Claude in Slack 应用；管理员可在 30 天内选择迁移。旧应用退役时间在帮助文档里写成 2026-08-03。符合条件的 Enterprise / Team 有上线积分（仅限 Tag 在 Slack 中的用量等限制，以当时说明为准）。

当时不是什么

Beta，不是所有套餐、不是 Slack 之外的默认表面。65% 是内部产品团队自报。ZDR 等限制写在后续文档，不在这篇发布博文的中心，但产品当时明确不是「已经普及的虚拟员工」。

13.2 - Claude Tag 讲解

当时解决了什么问题

2025 年的 Claude Code 很强，但是「一个开发者的终端」。团队协作发生在 Slack：任务从对话里冒出来，上下文在频道里，责任不在某一次私人聊天。Tag 把与 Claude Code on the web 相同的短暂沙箱引擎放到频道线程上：委派可见、可旁观、可交接。控制协议没有新发明；生命周期和权限模型有。ambient 把循环从「被叫才动」扩到「跟进未决事项」——主动度上升，误报与越权风险也上升，所以要管理员划频道和工具。

按定义这 是 Agent：决策、在沙箱与已连接工具里行动、按线程反馈再决策。人在环路变成多人在环路。MCP / Skills 在这里变成管理员按 scope 配的 bundle，而不是每人自己的 connector。

对后续 LLM 与 Agent 的影响

主矛盾从「会不会写代码」外移到：用谁的权限、记忆跟谁走、沙箱闲了怎么办。次日的 Agent identity 把「不要 act as the user」写成公开设计。8 月 3 日旧 Slack 应用切走，是治理事件：身份从每人自己的账号变成组织配的那一个。不要把 Team/Enterprise Beta 写成已经普及；个人计划与第三方部署当时不在范围内。ZDR 与频道记忆互斥，文档已写。A2A 仍偏企业平台叙事；Tag 的多驾驶员是产品层，不是跨厂商互操作。

14 - Agent identity

Noah Zweben（Claude Code 团队），2026-06-24。概念博文：频道共享工作区身份；私信仍走个人账号。

1. 材料 — 按博文转述：为何借用用户身份会垮、按频道划界。
2. 讲解 — act-as-user 失败模式；JIT 凭证当时是未来项。

当时原文：Agent identity: a new access model。对照：身份模型博文、How agent identity works。

14.1 - Agent identity（材料）

本页转述 2026-06-24 概念博文当时写了什么，不把文中的未来项（JIT 凭证、身份叠加）写成已经交付。

主要出处：Noah Zweben，2026-06-24，Agent identity: a new access model for autonomous, team-wide AI。中英对照：身份模型博文。机制文档：How agent identity works。

主张

单人 AI（一个人对一个助手）可以连自己的 Google Drive / GitHub，让模型代表你行事。多人体验如 Claude Tag：Claude 同时坐在共享频道里，调用的是工作区的工具与上下文，而不是某一个人的。因此 Claude 需要由管理员配置、绑到工作区的自己的账号。这套访问模型叫 agent identity。

博文解释：为何「act as the user」在异步、多驾驶员场景会垮——任务可能在用户已经离开后还在跑；频道里下一条指令可能来自另一个人；权限跟「最后说话的那个人」走会错乱、不可审计。公开频道应共享工作区身份；范围按频道划，而不是按人。例如为法务配的 Claude 不应把记忆种进工程频道。

文档补充（与博文同一产品）：频道里 Claude 用自己的服务账号（Slack 应用、GitHub App、其他已连接工具里的服务账号）；动作记在这些账号上。用户与 @Claude 的 DM 不适用这套身份，改跑在该个人的 claude.ai 与个人 connectors 上（GitHub PR 署名仍可能是 Claude GitHub App）。Owner 可禁用 DM。

当时不是什么

JIT（单次敏感动作当场批）、以及「频道 profile ∩ 用户权限」的身份叠加，博文当作未来方向。不要读成 6 月 24 日已经上线。自托管 runner 上 Access bundle 的限度见机制文档，不是这篇博文的中心声明。

14.2 - Agent identity 讲解

当时解决了什么问题

2025 年运行时默认「用你的 GitHub、你的浏览器、你的 OAuth」。这对个人副驾驶成立：委派者、凭证持有者、审计对象是同一个人。频道里一旦多人转向同一个正在跑的任务，借用某人的 token 会变成：走了的人仍在担责，后来的人越权，回放对不上当时权限。act-as-user 在同步、单驾驶员、短会话里勉强可过；在异步多驾驶员下，授权、审计、回放三条都不闭合。

博文把规则写成产品：共享工作区用服务账号；私信仍是个人助手。身份与「怎么表现」（指令、plugins、记忆）分开配置。按定义身份模型 不是 Agent。它是循环能在组织里转的前提。没有它，Tag 只能是又一个 Slack 机器人。

对后续 LLM 与 Agent 的影响

词接近一层新协议：Agent Identity、Agent Proxy、Access bundle、scope。MCP / Skills 在 Tag 里变成管理员按 scope 配的 bundle。Cowork 的文件夹 principal 仍是用户，不要回填成已经切换到这套模型。A2A 仍偏企业平台；Tag 的多驾驶员是产品层，还不是跨厂商 agent 互操作。JIT 与权限交集（频道 profile ∩ 用户权限）在 2026-09 仍不要当已交付事实。

15 - Claude Sonnet 5

Anthropic，2026-06-30。官方定位是「最 agentic 的 Sonnet 模型」：能制定计划、使用浏览器与终端一类工具、以几个月前还需要更大更贵模型才能达到的水平自主运行。定价 $2/$10（介绍价转为常态价）。

1. 材料 — 按官方公告转述：agentic 定位、成本曲线、与 Opus 档的关系。
2. 讲解 — 改的是单位成本，不是能力上限；「能自主跑」下沉到中档是 2026 年的关键经济性变化。

当时公告：Claude Sonnet 5。

15.1 - Claude Sonnet 5（材料）

主要出处：Anthropic，2026-06-30，Claude Sonnet 5。本页不复制公告全文。

公告说了什么

• 定位：官方原话称它是「built to be the most agentic Sonnet model yet」——能制定计划、使用浏览器与终端一类工具、自主运行，「达到几个月前还需要更大更贵模型才能达到的水平」。
• 价格：$2/$10 per Mtok，介绍期价格随后转为常态价（即相对前代降价约三分之一）。
• 成本曲线：公告用 effort 维度展示成本-性能曲线，覆盖了 Opus 档的大部分区间；即在同等成本点上，Sonnet 5 追上了此前要上 Opus 才有的表现。
• 安全口径：厂商自报其网络安全能力显著低于当时的 Opus 级。

当时不是什么

不是能力上限的推进——上限属于同期的 Opus 4.8 与 Mythos 级。它推的是自主运行的单位成本：把「会规划、会用浏览器和终端、能自己跑」从高档位下放到中档位。

厂商自报数字（降价幅度、曲线覆盖）按主张记，不作独立结论。

15.2 - Claude Sonnet 5 讲解

当时解决了什么问题

2025 年能自主跑长程任务的模型都在最高档：价格决定了「敢于让 Agent 跑多久」。编码 Agent 的成本模型很直接——一次委派烧的 token 乘单价。单价不降，长任务就只能留给少数场景。

Sonnet 5 的公告没有讲新的能力类别，讲的是同一类能力换到了中档价位：会规划、会用浏览器与终端、能自主运行。配合 effort 维度的成本曲线，同等成本点上能覆盖此前 Opus 档的区间。

对做平台的人，这条的意义是单位经济性：同一笔预算能开的并发数、能容忍的重试次数、能放的沙箱存活时长，都由这个价格决定。

对后续 LLM 与 Agent 的影响

把它与 Opus 5（一个月后，同一条线的高档位）连起来读：2026 年年中，Anthropic 在高低两端同时推进自主能力——一端推上限，一端推价格。GPT-5.6 家族的 Sol / Terra / Luna 三档（见下）是同一思路的另一家版本。

决策核心的价格曲线开始决定 Agent 的产品形态，这件事在 2026 年才变得明显。在此之前的叙事里，成本只是运维指标，不是能力边界。

16 - GPT-5.6（Sol / Terra / Luna）

OpenAI，2026-07-09（公开可用）。家族分三档：Sol（最高推理上限，面向大型代码库推理与长时程 agentic 工作）、Terra（均衡默认）、Luna（最低成本轻量）。平台侧能力表显示三个模型全部支持推理、Responses API、多 Agent 编排（预览）、并行工具调用与 computer use，上下文窗口约 105 万 token。

1. 材料 — 按 GitHub 与平台模型文档转述：三档定位、共同能力表、上下文与分发时间线。
2. 讲解 — 多 Agent 编排与 computer use 从「某一款有」变成「全档标配」。

第三方一手： GitHub Changelog。

16.1 - GPT-5.6 家族（材料）

主要出处：GitHub Changelog，2026-07-09，OpenAI’s GPT-5.6 Sol, Terra and Luna are now available in GitHub Copilot；平台模型文档（Azure AI Foundry）标注 gpt-5.6-sol / terra / luna (2026-07-09)。OpenAI 官网对本机不可访问，本页按上述两处一手替代来源转述。

三档怎么分

• Sol —— 家族最高推理上限。GitHub 的表述是「best for complex reasoning over large codebases and demanding, long-running agentic work」。
• Terra —— 均衡默认档。
• Luna —— 最低成本的轻量档。另有 -pro 变体。

全家族共同具备的能力

平台模型文档的能力表显示，三个档位全部支持：推理、Responses API、多 Agent 编排（预览）、函数与并行工具调用、computer use，以及推理强度与详细度控制。上下文窗口 1,050,000（输入 922,000 / 输出 128,000）。

需要更正一条二手流传：多个来源称上下文约 150 万 token，平台文档与第三方模型索引均为 1,050,000。

发布节奏

公开可用日是 2026-07-09。另有二手报道称该模型在 2026-06-26 先做了受政府限制的限量预览，但这一条没有一手来源，写时间线时须标注为「据媒体报道」。二手还提到 Sol 有协调内部子 Agent 的模式，同样未能核实。

当时不是什么

不是单一模型发布，而是一次档位划分：把「多 Agent 编排 + computer use + 百万级上下文」从旗舰专属变成家族标配。这是能力下放，不是能力上限的推进——上限由两周后的 GPT-6 Astra 接续。

16.2 - GPT-5.6 家族 讲解

当时解决了什么问题

2025 年的能力分布是「旗舰有、低档没有」：computer use 只有在最贵的模型上才可用，多 Agent 编排要靠框架自己搭。产品因此要在「能力」和「成本」之间做取舍——想要 computer use，整个产品线的单价就被顶上去。

GPT-5.6 把这两项拉平到全家族：最低成本的 Luna 也支持多 Agent 编排与 computer use，且三档共享约 105 万 token 的上下文。取舍点从有没有变成用哪一档。

对做平台的意义很直接：Agent 的默认能力集合被重画了。如果 computer use 与编排在各档都有，那么运行时要解决的就不是「能不能做」，而是「做得对不对、花了多少、谁批准的」。

对后续 LLM 与 Agent 的影响

两周后的 GPT-6 Astra 把重点转向「怎么确认自己做完了」，再往后一个月的 Opus 5 也强调自我验证。2026 年年中之后，前沿模型的竞争点从「能做什么」转向「做完了怎么知道」——这正是定义第四条（完成判据）在核心侧的对应物。

边界：这是核心能力的下放，不是 Agent 形态的变化。编排是核心提供的原语，循环仍由运行时驱动。

17 - Claude Opus 5

Anthropic，2026-07-24。官方表述是「Opus 档的台阶式改进，驱动长时程 Agent」，接近 Fable 5 的前沿水平但价格约一半。公告强调它更善于验证自己的工作、并持续迭代到成功；在 computer use 的 OSWorld 2.0 上于各成本点均优于其他模型。

1. 材料 — 按官方公告转述：台阶式改进、自我验证、computer use 与端到端任务分数。
2. 讲解 — 竞争点从「能做什么」转向「做完了怎么知道」。

当时公告：Claude Opus 5。

17.1 - Claude Opus 5（材料）

主要出处：Anthropic，2026-07-24，Claude Opus 5。本页不复制公告全文。

公告说了什么

• 定位：官方原文称它是「a step change improvement for the Opus tier powering long-running agents」——驱动长时程 Agent 的 Opus 档的台阶式改进；接近 Fable 5 的前沿智能，价格约一半。
• 自我验证：公告写明它「much stronger at verifying its work and iterating carefully until it succeeds」——更强的自查与迭代到成功。
• computer use：在 OSWorld 2.0 上于所有成本点都优于其他模型，并超过 Fable 5 的最好成绩，成本约为其三分之一。
• 其他分数：ARC-AGI 3 上为次优模型的三倍；Zapier 的端到端业务任务基准 AutomationBench 通过率约为次优模型的 1.5 倍。

口径说明

上述分数均为厂商自报，且 OSWorld 2.0 是 2026 年的新版电脑操作基准，与 2024 年的 OSWorld 原版分数不可横比。写时间线时不把两者连成曲线。

当时不是什么

不是能力类别的扩张，也不是 Agent 架构的变化。它的重点是验证：做完了要能自己确认做对了——这是长时程自主里最难的一块，此前主要靠外部的测试与人工检查。

17.2 - Claude Opus 5 讲解

当时解决了什么问题

长时程 Agent 一直卡在同一个地方：做得久不等于做得对，而判断对不对在 2024–2025 年一直外包给执行环境——跑测试、看 CI、人审 diff。决策核心自己不做这个判断。

Opus 5 的公告把「更善于验证自己的工作、持续迭代到成功」写成了主要能力，并配了 computer use 与端到端业务任务的分数。方向很清楚：把验证从外部谓词部分收进核心。

这与定义第四条是同一件事的两侧。外部完成判据（SWE-bench 一族）回答「整段轨迹交付了没有」；核心侧自我验证回答「我在中途怎么知道这一步是对的」。后者不能替代前者——自查失败而宣布成功的失败模式，正是外部谓词存在的理由。

对后续 LLM 与 Agent 的影响

Sonnet 5 推价格、Opus 5 推验证、GPT-6 Astra 在同一时期强调「独立确认结果后才宣布完成」——三家在 2026 年年中同时转向完成判据的核心侧内化。

对做运行时的人，这意味着外部谓词不能被省掉：核心越自信，越需要独立于核心的检查。第二层不是被替代，而是被需要得更清楚。

18 - Aries

Rethinking AI Cloud Infrastructure for Agentic Serving Systems。Aries：把智能体轨迹当一等观测单元的实验框架。

1. 论文 — 按原文转述：轨迹、测量鸿沟、三项发现。
2. 讲解 — 一次委派是轨迹；请求级 LLM 指标会看错关键路径。

原文与本站译本：Aries 资料栏。

18.1 - Aries（论文）

Rethinking AI Cloud Infrastructure for Agentic Serving Systems（Aries）。约 2026-07-31 公开。本站中文译本：中文。HTML/PDF 以 资料介绍 为准。

摘要

自主 agent 把重复推理与持久上下文、沙箱化工具执行结合在一起，对传统 LLM 服务构成新挑战。论文提出 Aries：全栈实验框架——把任务语义与执行配置分离；用关联的系统遥测重建跨组件智能体轨迹；在异构沙箱基底上用一致接口暴露有状态工具执行。实验用开源平台与基准，并补上商业平台的生产轨迹（匿名）。主要发现写成：

1. 以 Token 为中心的指标会遗漏非推理瓶颈（harness 与工具可占端到端延迟很大一块，文中举例可高达约 48%）。
2. 多留上下文的精度收益递减，同时降低服务容量。
3. 工具沙箱在长时间空闲与短时资源突发之间交替；想靠激进挂起省资源，会被恢复成本吃掉。

安全分析强调缩小沙箱攻击面。愿景：轨迹级指标、自适应上下文管理、弹性沙箱、攻击面最小化。

问题重构

传统 LLM 服务优化单次模型调用（TTFT、每 token 时间）。Agent 服务里，一次用户请求跨许多相互依赖的模型步与工具步。论文把 智能体轨迹 定义为：服务该请求过程中 LLM 调用、工具调用、工具结果、harness 决策的有序序列。测量必须把任务进度和跨层运行时行为连起来；既有能力基准与系统基准都只覆盖一半。

Aries 用任务规格 vs 执行规格分离、跨层事件 ID、与基底无关的工具接口，来做受控对比和失败归因。

当时不是什么

这是测量框架与问题定义，不是已经换完的新云底盘。生产数字来自匿名轨迹与受控复现，不要读成某一家公开 SLA。

18.2 - Aries 讲解

论文解决了什么问题

2025 年运行时把循环做成产品，公开讨论仍停在 SWE-bench 和演示。Aries 指出：GPU 解码变快，任务仍可能卡在 harness、工具和闲置沙箱。用请求级 LLM 指标管 Agent 服务，会看错关键路径——一次委派跨多次推理、工具调用、沙箱生命周期和 KV 状态，观测单元必须是轨迹，不是 QPS。把轨迹当一等公民，才能问「这一步为什么没推进」。

按定义论文研究的是 已经在转的 Agent 如何被云基础设施拖住或放大，不是新的决策算法。编排库解决不了存储、隔离和上下文税。

对后续 LLM 与 Agent 的影响

Tag 文档里的短暂沙箱（建、干、闲、释放）与这篇的「空闲但突发」互相印证：产品已经撞上论文写的负载。SpecBox 走调度优化；Aries 走测量与问题重构。两者都说明 2026 年主矛盾外移：不是再涨 5 分基准，而是执行路径是否跟得上异步委派。文中用 SWE-Bench Pro、OpenClaw 一类 harness 当负载，不是偶然。愿景项（弹性沙箱、最小攻击面）不要当成业界已经换完的底盘。

19 - 欧盟 AI Act 第 50 条：Agent 必须披露身份与委托人

欧盟委员会，2026-07-20 发布第 50 条透明度指南（C(2026) 5054 final，51 页），透明度义务自 2026-08-02 起适用。指南第 31 段明文点名 AI agent 与复杂多 Agent 架构：具备与人交互能力的 Agent 被第 50(1) 条覆盖，且设计上就必须披露其人工性质与所代表的人——理由写明是「代理与授权的透明度，以及对行动后果的问责」。同日生效的还有加州 AI 透明度法。

1. 材料 — 按官方指南与 FAQ 转述：点名原文、披露要求、不必标注的部分、以及被推迟的条款。
2. 讲解 — 第一个在生效规则里点名 Agent 的法域；它要求的是「说清楚谁在行动」，不是「审计做了什么」。

指南：Transparency obligations guidelines。

19.1 - 欧盟 AI Act 第 50 条（材料）

主要出处：欧盟委员会，2026-07-20，Article 50 透明度指南（C(2026) 5054 final，51 页）；AI Act Service Desk FAQ；以及 Digital Omnibus on AI（Regulation (EU) 2026/1744）。

点名 Agent 的原文（第 31 段）

指南写：AI agent 属第 50(1) 条覆盖范围，只要它在执行任务过程中具备与指令它的人或其他自然人交互的能力（例子包括预订、处理通信、谈判或订立合同、执行购买等）。

要求是：AI agent 的设计与开发方式，必须让它同时披露自己的人工性质、以及它代表谁行动——理由是「代理与授权的透明度，以及对行动后果的问责」。指南还提到复杂多 Agent 架构，并要求在授权、报告、验证等关键节点向指令方披露。

不必标注的部分（第 63 段）

第 50(2) 条要求标注可感知的合成内容，但指南明确不包括中间处理步骤，例如推理与思维链，也不包括一次网页请求或浏览器动作。

时间表与配套法规

• 2026-08-02：第 50 条透明度义务开始适用。同一天，加州的 AI 透明度法（SB 942，经 AB 853 修订）也开始施行——两个法域选了同一天。
• 同一批立法里，高风险系统的义务被推迟：Digital Omnibus on AI（Regulation (EU) 2026/1744）把原定 2026-08-02 的高风险义务推到 2027-12-02 / 2028-08-02。所以 2026 年真正生效的只有透明度这一档。
• 该法规的附件还把 Agentic AI 列入了公告机构的类别代码。

官方 FAQ 的两条补充

• 「AI agent」不是法律定义。官方 FAQ 写明：该术语没有法律定义，第 3(1) 条的「AI 系统」与第 3(63) 条的「通用模型」定义足以覆盖 Agent。
• 自主程度与工具使用可以是风险认定的决定因素：FAQ 提到模型的自主水平或工具使用能力，可能在把模型认定为「具系统性风险的模型」时起决定作用。

需要区分的一条

委员会的《AI 生成内容透明度行为准则》全文没有出现 agent——规则覆盖了 Agent，但行业合规路径还没跟上。

19.2 - 欧盟 AI Act 第 50 条 讲解

当时解决了什么问题

Agent 在对外交互时的核心身份问题是：对面那个人知不知道自己在跟机器说话，以及这台机器代表谁。此前的产品实践全是自选动作——有的在 UI 上标注，有的靠用户自己推断。

第 50 条把它变成义务，而且明确写进了 Agent 与多 Agent 架构：设计上就要披露人工性质与委托人。指南的措辞值得注意——它把这条的理由写成「代理与授权的透明度，以及对行动后果的问责」，关注点是授权链，不是内容真假。

三个要注意的口径

1. 中间步骤不算要标注的合成内容。推理与思维链、网页请求与浏览器动作都被明确排除。这避免了把 Agent 的内部过程当作「生成给公众的内容」。
2. 「AI agent」不是法律定义。官方 FAQ 说得很清楚：术语没有法律定义，靠「AI 系统」与「通用模型」两个既有定义覆盖。这是立法技术上的回避——和加州 AB 316 用「自主程度可变的系统」是同一手法。
3. 真正生效的只有这一档。同一批立法把高风险义务推迟到了 2027 年底与 2028 年。不要把 2026-08-02 写成「AI Act 全面生效」。

对后续 LLM 与 Agent 的影响

把两个法域并排看，路径差异很清楚：

两条合起来给平台设计的约束是：动作要能追溯到委托人。但两条都没有要求审计留痕——「查得清出了什么事」这件事，截至 2026 年 9 月仍是法律空白。这是 2027 提纲最值得继续盯的点之一。

20 - SpecBox

SpecBox: Speculative Sandbox Scheduling for Efficient LLM Agent Serving。主张沙箱准备时间可以从关键路径上拿掉；机制不在此展开。

1. 论文 — 论文主张，以及它证明了什么。
2. 讲解 — 沙箱在关键路径；这是执行层，不是再训一遍模型。

原文与本站译本：SpecBox 资料栏。

20.1 - SpecBox（论文）

SpecBox: Speculative Sandbox Scheduling for Efficient LLM Agent Serving。约 2026-08 公开（资料栏介绍写 8 月 5 日）。本站中文译本：中文。HTML/PDF 以 资料介绍 为准。

论文的主张

LLM agent 越来越多经 MCP 调用隔离沙盒。长生命周期预留内存太贵，按需实例化又带来冷启动——在多租户、多轮场景下，这段准备时间落在尾延迟上。论文的主张是：这段等待属于调度问题，可以不等模型变得更聪明就能缓解。

沙盒内部的隔离与调度机制不在本页展开，见资料栏。

它证明了什么

沙箱准备时间是可测量的 Agent 服务成本，不是实现细节。 作者给出原型与相对基线的对比，把「环境还没就绪」从工程抱怨变成可以放进容量与延迟模型的一项。

对 Agent 史的意义在这一条：2026 年，执行供给第一次被当作系统问题来量。

当时不是什么

这是一条系统路线与原型数字，不是业界默认调度器。预热猜错会浪费 CPU/内存——论文把阈值当成设计张力，没有宣布已经免费。

20.2 - SpecBox 讲解

论文解决了什么问题

Aries 测量到工具与沙箱不是边角。SpecBox 选其中一个可优化点：反应式「先说完再启动」把秒级冷启动串进每一步。MCP 把工具变成远程沙盒之后，这个问题更硬——协议标准化了调用，没有标准化「环境已经热着」。论文的方向是把这段等待从关键路径上拿掉，而不是靠核心再聪明一点。具体机制不在本条展开，见资料栏。

按定义 SpecBox 不是 Agent，是给 Agent 服务的运行时调度。环境未就绪，Action 只能阻塞——这是执行层，不是模型层。

对后续 LLM 与 Agent 的影响

产品上的短暂沙箱（用完释放）正好撞上冷启动。Tag 一类异步委派对尾延迟敏感：人 @ 完去开会，回来还在等环境。论文自报的改善幅度是它自己设置下的报告，不是可以写进所有 SLA 的常数。和 Aries 一起读：2026 年把执行基础设施写成主线，但「把沙箱调度问题做完」仍是研究与工程，不是已经换完的新底盘。

21 - Snowflake Cortex Agents

Snowflake，2026 年 8 月连续三次一般可用：08-07 原生应用中的 Cortex Agents 与 MCP server 可用（跨应用 agent→agent 编排，各应用数据与逻辑保持私有，只能通过提供方暴露、消费方批准的工具互相调用）；08-26 编码 Agent 可用（工具执行由 Snowflake 承担，使用方不再自己搭 agent loop）；08-30 异步 API 可用（后台长任务在客户端断开后继续，上限 6 小时）。

1. 材料 — 按官方发布说明转述：三次 GA 各自改了什么、权限模型、异步语义。
2. 讲解 — 数据平台把「可以自己跑、自己调、自己停」的循环收进服务端；与同期 Managed Agents 是同一种收法。

发布说明：2026-08-07、2026-08-26、2026-08-30。

21.1 - Snowflake Cortex Agents（材料）

主要出处：Snowflake 官方文档发布说明，2026-08-07 / 08-26 / 08-30 三条。本页不复制原文。

2026-08-07：跨应用编排

Cortex Agents 与 MCP server 在 Snowflake 原生应用中一般可用。要点是一个应用里的 agent 可以调用另一个应用里的 agent 或 MCP server，而每个应用保持自己的数据与逻辑私有——「agent 只能通过提供方暴露、消费方批准的工具跨应用访问」。权限模型包含调用方授权、功能策略与角色委派。

2026-08-26：服务端执行 agent loop

编码 Agent 一般可用。官方原文写：「Snowflake 执行工具并把结果流回你的应用，因此你不必自己构建或托管一个 agent loop。」

2026-08-30：异步长任务

异步 API 一般可用。把请求的 background 字段设为真即可：长任务在客户端断开后继续运行，超时上限 6 小时。

三条合起来是什么

跨应用编排 + 服务端托管的循环 + 断连可续的长任务——这三样此前都是开发者自己拼的：自己写编排、自己托管循环、自己做断线重连。这一轮把它们收进了平台。

需要更正的一条

流传的「Cortex Agents 于 2026-08-09 GA（跨库工具访问）」是编造的日期。Snowflake 官方 8 月的新闻稿只有另外两条，本条日期以官方发布说明为准。

21.2 - Snowflake Cortex Agents 讲解

当时解决了什么问题

企业数据平台上的 Agent 一直有个尴尬：数据在平台里，循环却跑在外面。开发者要自己接鉴权、自己写编排、自己处理长任务的断线——而这些恰恰是平台已经解决过的问题（权限、调度、事务）。

三条 GA 各补一块：跨应用编排解决「别人的数据怎么合规地用」，服务端 loop 解决「谁托管循环」，异步 API 解决「任务比连接活得久」。

权限那条值得单独看：跨应用调用需要提供方暴露工具 + 消费方批准，配合角色委派。这是数据侧的最小权限模型，与 CrowdStrike 在安全侧的短时令牌、Managed Agents 在运行时侧的 scope bundle 是同一个方向的三种实现。

对后续 LLM 与 Agent 的影响

这条的意义不在于 Snowflake 做了什么新东西，而在于做这件事的是数据平台：

• 2023–2025 年，Agent 运行时由模型厂商与专做运行时的公司提供；
• 2026 年，掌握数据与权限的企业平台也开始提供——因为「Agent 能碰什么数据」本来就在它们手里。

对做 Agent 平台的人，这是竞争面的变化：对手不只是其他运行时，还包括已经持有凭证与数据的既有平台。它们的优势不在沙箱，而在它已经知道谁有权访问什么。

22 - CrowdStrike 的 Agent 身份与运行时管控

CrowdStrike，Fal.Con 2026。三件与 Agent 直接相关：Falcon Guardian（在 Windows / macOS 终端发现已知与影子 Agent，给出实时清单，阻止未授权 Agent，把治理策略变成可执行的运行时控制）；Agentic Identity Provider（每个 Agent 签发可加密验证、不可冒用或共享的身份；Agent 从不持有常设凭证，访问由令牌代理，按每个任务所需的最小权限与最短时间签发；每个动作都绑定到它代表的人或工作负载）；以及 agentic SOC（跨 Agent 的持久记忆、按工作流配置自治等级）。

1. 材料 — 按官方新闻稿转述：三件事各自说了什么、身份模型的三条规则、以及未发布服务的免责声明。
2. 讲解 — 目前最完整的 Agent 身份模型；与运行时侧、数据侧的同类做法对照。

来源：Falcon Guardian、Agentic Identity Provider。

22.1 - CrowdStrike Agent 身份（材料）

主要出处：CrowdStrike 官方新闻稿（Fal.Con 2026），2026-08-31 至 09-02 四条。本页不复制原文。

三件事

2026-08-31 — Falcon IQ / Project Quiltworks：官方称用超过 50 个 Agent 自动化最耗时的安全工作流。

2026-09-01 — Falcon Guardian（AI Agent 安全）：官方原文写，传感器在 Windows 与 macOS 上发现已知与影子 AI Agent，给出每个运行中与休眠 Agent 的实时清单；定义哪些 Agent 允许在受管终端上运行，阻止未授权的，并「把治理策略翻译成可执行的运行时控制」。

2026-09-02 — Agentic Identity Provider：这是本批里最值得记的一条，官方给了三条规则：

1. 「每个 Agent 被签发一个可加密验证的身份，不可冒用、不可共享。」
2. 「Agent 从不被授予它自己的常设凭证。 Agentic IdP 通过令牌代理访问，令牌按每个任务所需的最小权限、最短时间签发。」
3. 「Agent 所做的每一个动作，都绑定到它所代表的那个人或那个工作负载。」

2026-09-02 — agentic SOC：跨每个 Agent、每次调查、每个租户的持久记忆（「一个 Agent 学到的，它们都知道」）；客户可以为每个工作流设置自治等级，从人在环路批准到完全自主执行；支持双向 MCP。

口径提醒

官方文本自带「未发布服务」免责声明，部分能力仍写作「将提供」。写时间线时按「已公布的能力设计」记，不要写成已经全面可用。

与同类的关系

这套模型与运行时侧的 scope bundle、数据侧的跨应用授权是同一个方向的三种落地：身份从「借用用户凭证」里拆出来，动作绑定到委托人，凭证短时且最小。

22.2 - CrowdStrike Agent 身份 讲解

当时解决了什么问题

2026 年之前，Agent 的身份基本是借用的：用你的 OAuth、用你团队的服务账号、或者一把长期 API key。这带来三个问题——审计追不到人、权限只能一次给足、凭证一旦泄露影响面等于整个账号。

CrowdStrike 给的三条规则逐一对应：

注意这是安全厂商给出的答案，不是模型厂商——这本身是信号：Agent 身份问题先被当作终端与凭证安全问题来处理。

与另外两条线的关系

• Managed Agents 处理的是沙箱里的凭证（token 不进沙箱）；
• Snowflake 处理的是数据侧的授权（提供方暴露、消费方批准）；
• 这一条处理的是身份本身（谁是谁、代表谁、能做什么）。

三条合起来才是完整的 2026 答案：主体独立于用户，凭证不落执行环境，动作可归因。

对后续 LLM 与 Agent 的影响

最有价值的一处是 Falcon Guardian 的「影子 Agent」概念：终端上会出现没人批准过的 Agent。这在 2026 年是真实问题——OpenClaw 一类自托管 Agent 让每个人都能在自己机器上跑一个，企业需要先发现再谈治理。

对做平台的人：发现与清点是治理的前提。在能管住之前，先得知道有多少在跑。这条和 2026 年 Tag 的组织级身份是同一命题的两端——一个从组织往终端看，一个从终端往频道看。

23 - GPT-6 Astra

OpenAI，2026-09-03（版本日）／09-04（GitHub Copilot 一般可用）。平台能力表显示其支持推理、Responses API、多 Agent 编排（预览）、并行工具调用与 computer use，上下文约 105 万 token，训练数据截至 2026 年 4 月。

1. 材料 — 按 GitHub Changelog 与平台模型文档转述：机制评价、能力表、加强的安全控制。
2. 讲解 — 「做完了怎么知道」被写进模型行为描述；这代人机接口的另一处新意是推理时安全指令注入。

第三方一手： GitHub Changelog。

23.1 - GPT-6 Astra（材料）

主要出处：GitHub Changelog，2026-09-04，GPT-6 Astra is generally available in GitHub Copilot；平台模型文档（Azure AI Foundry）标注 gpt-6-astra (2026-09-03)。OpenAI 官网对本机不可访问。

一段罕见的机制评价

GitHub 的公告没有只列分数，而是写了它怎么工作——原文：

「GPT-6 Astra stood out for how it works, not just what it produces: it plans and validates as it goes, batches diagnosis with verification, and independently confirms its results before declaring a task done.」

并称在长时程编码任务上比此前 OpenAI 模型用更少步骤取得更好表现。这段出自第三方（GitHub），比厂商自报更有分量，但仍属合作方口径。

能力表

平台文档显示支持：推理、Responses API、多 Agent 编排（预览）、函数与并行工具调用、computer use、推理强度与详细度控制。上下文 1,050,000，训练数据截至 2026 年 4 月。

一处值得单独记的机制

平台文档写明，当安全系统判定风险升高时，该模型可能施加加强的安全控制：在推理时修改分类器阈值，并用系统生成的安全指令补充客户提示。

这不是模型能力，也不在循环里——是服务端在推理时改写输入。对做平台的人，这类机制会影响可复现性与调试路径，值得单独跟踪。

当时不是什么

不是 Agent 产品，也不是协议事件。它的可核对意义集中在两条：验证行为被写进官方能力描述，以及推理时安全指令注入这一服务端机制的公开化。

23.2 - GPT-6 Astra 讲解

当时解决了什么问题

长时程 Agent 的失败模式里，最贵的不是「做错」，是做错了还宣布成功——人已经走了，错误在收工之后才暴露。前面几代模型的应对方式是把检查留给外部：测试、CI、人审。

GPT-6 Astra 的官方描述第一次把顺序写反过来了：先独立确认结果，再宣布完成。配合 Opus 5 一个月前的「更强的自我验证」，这条线在 2026 年年中已经稳定：核心开始承担一部分完成判据。

对后续 LLM 与 Agent 的影响

两点值得记。

一是验证变成默认叙事。 从 2024 年的 o1「把想藏进内部计算」，到 2026 年的「边做边验、确认后收工」，核心被要求承担的部分从推理扩展到正确性判断。

二是推理时安全注入。 平台文档写明服务端会在风险升高时修改分类器阈值、并用系统指令补充客户提示。这意味着同一段提示在不同风险判定下可能得到不同行为——对调试、评测复现、以及「Agent 为什么这么做」的归因，都是一个新变量。

边界：核心侧自我确认不能替代外部谓词。判断做完了和判断交付了是两件事，前者越强，后者越重要。

24 - 开源权重模型达到 Agent 可用

2026 年，多家实验室把「面向 agent」的能力打成开源权重标配：Qwen3.5 → 3.8（2 月 → 8 月）、GLM-5.1 → 5.3（4 → 8 月）、MiniMax M2.5 / M3（2 月 / 6 月）、DeepSeek V4（4 月开源预览，8 月 Pro GA）、Kimi K3（7 月）、Thinking Machines 的 Inkling（7 月）。共同点是百万级上下文、原生多模态、computer use 与 agent harness 兼容。

1. 材料 — 按各家官方公告与仓库转述：逐条日期、能力、以及各自的自我定位。
2. 讲解 — 自托管从「能力打折的选择」变成「同档可选项」；与 6 月的出口管制是同一件事的两面。

代表来源：DeepSeek V4、GLM-5.2 发布说明、Kimi K3、Inkling。

24.1 - 开源权重线（材料）

主要出处：各家官方公告与仓库（QwenLM、docs.z.ai、minimax.io、deepseek.com、moonshot.ai、thinkingmachines.ai），以及 ModelScope / GitHub API 的仓库元数据。本页只做汇总，不复制原文。

逐条

需要区分的一处

Kimi 的 K2.7-code（06-12）可在第三方模型索引中看到，但没有找到对应的开源权重仓库——「K2.7 开源」未能核实，本页不列为开源权重。

一句话总结这一年的变化

1M 上下文、原生多模态、computer use、与主流 agent harness 兼容——这四项在 2026 年从「旗舰闭源专属」变成「开源权重标配」。厂商自我定位也从「追平上一代」改成「面向 agent 工作负载设计」。

24.2 - 开源权重线 讲解

当时解决了什么问题

2023–2025 年，「用开源权重跑 Agent」意味着接受明显的能力折扣：上下文更短、工具调用更脆、多模态缺失。自托管是数据主权与成本的选择，代价是能力。

2026 年这个等式变了。百万级上下文、原生多模态、computer use、以及与主流 harness 的兼容性，在中国实验室的开源权重里成了标配，且迭代节奏以月计。自托管从「打折的选择」变成「同档可选项」。

DeepSeek 那条尤其直白：官方文档点名与 Claude Code、OpenClaw、OpenCode 集成，并放出自己的 harness——开源方开始主动适配闭源运行时，方向与两年前相反。

对后续 LLM 与 Agent 的影响

把这条和 6 月的出口管制事件放在一起读，才是完整的：

• 出口管制证明了已商用前沿模型的访问权可以被当场关掉；
• 开源权重线证明了同等能力有可自托管的替代。

两件事发生在同一年，不是巧合——它们共同改写了「依赖单一模型」这件事的风险定价。对做 Agent 平台的人，可替换性（模型、沙箱、协议）从优化项变成架构前提。

口径要克制：本页是汇总条目，各家的能力主张多为厂商自报，第三方实测尚未成体系。写结论时按「可用替代已经存在」记，不按「已追平」记——这两句话在工程上的含义差别很大。