章节导航 第 16 章 / 共 16 章
第 16 章 第五部分：前沿与展望

Agent、工具使用与未来展望

从 Chat 到 Agent——LLM 如何从对话工具走向自主行动者

Agent 工具使用 RAG MCP 推理模型 未来

从对话到行动

传统的 LLM 交互模式是一问一答——用户提问，模型回答。但一个真正有用的 AI 助手需要的不仅是”说”，还要能”做”：

用户: "帮我查一下北京明天的天气，如果下雨就取消我的户外日程"

传统 LLM: "我无法访问实时天气数据，也无法操作您的日历..."

Agent LLM:
  1. [调用天气 API] → 北京明天：小雨，14°C
  2. [调用日历 API] → 发现"公园跑步"日程
  3. [调用日历 API] → 取消"公园跑步"
  4. 回复: "北京明天有小雨，已帮您取消公园跑步。"

LLM Agent 是以 LLM 为”大脑”，配备工具、记忆和规划能力的自主系统。

Agent 架构

核心组件

一个完整的 Agent 系统通常包含四个核心组件：

┌─────────────────────────────────────┐
│            Agent 系统                │
│                                     │
│  ┌──────────┐  ┌──────────────┐    │
│  │  规划器   │  │    记忆系统   │    │
│  │ (Planner) │  │   (Memory)   │    │
│  └────┬─────┘  └──────┬───────┘    │
│       │               │            │
│  ┌────▼───────────────▼────────┐   │
│  │         LLM（大脑）          │   │
│  └────────────┬────────────────┘   │
│               │                    │
│  ┌────────────▼────────────────┐   │
│  │       工具集 (Tools)          │   │
│  │  搜索 │ 代码 │ API │ 文件    │   │
│  └─────────────────────────────┘   │
└─────────────────────────────────────┘

规划（Planning）

Agent 需要将复杂任务分解为可执行的步骤。常见的规划策略：

ReAct（Yao et al., 2023）——交替进行推理（Reasoning）和行动（Acting）：

Thought: 我需要查找北京明天的天气
Action: weather_api(city="北京", date="明天")
Observation: 小雨, 14°C, 东风3级
Thought: 天气是下雨，需要检查用户的户外日程
Action: calendar_search(type="outdoor", date="明天")
Observation: 找到: "公园跑步" 9:00-10:00
Thought: 需要取消这个户外日程
Action: calendar_cancel(event_id="xxx")
Observation: 已取消
Thought: 任务完成，汇报结果
Answer: 北京明天有小雨，已帮您取消公园跑步。

Plan-and-Execute——先制定完整计划，再逐步执行：

Plan:
  1. 查询北京明天天气
  2. 判断是否下雨
  3. 如果下雨，搜索户外日程
  4. 取消找到的户外日程
  5. 汇报结果

Execute: [逐步执行上述计划]

Tree-of-Thought——探索多条推理路径，选择最佳：

        [问题]
       /   |   \
    [路径A] [路径B] [路径C]
     ↓       ↓       ↓
   评估     评估     评估
     ↓
  [选择最优路径继续]

程序化工具调用（Programmatic Tool Calling / Code Mode）——生成代码一次性执行多步操作：

ReAct 逐工具调用的模式在复杂任务中效率低下——每一步都需要一轮 LLM 推理 + 工具执行 + 结果观察。程序化工具调用提供了一种替代范式：给模型一个执行环境（sandbox），让它生成代码一次性编排多个工具调用，配合结构化输出减少多轮交互。

# ReAct 模式：4 轮交互
Thought → Action(search) → Observation → Thought → Action(filter) → Observation → ...

# Code Mode 模式：1 轮交互
Code: results = search(query); filtered = filter(results, criteria); return filtered

Anthropic 的 Programmatic Tool Calling（2026.01）率先将这一模式工业化。Cloudflare CodeMode 进一步验证：2 个核心工具（search + execute）+ ~1000 token 即可覆盖 2500+ API 端点。与 Plan-and-Execute 的关系：Code Mode 可视为”执行阶段”的优化——规划仍然可以由 LLM 完成，但执行从逐工具调用升级为代码批量执行。这代表了 Agent 执行模式从”对话式”到”程序式”的重要演进。

记忆系统

类型实现用途
短期记忆上下文窗口内的对话历史当前任务的上下文
工作记忆结构化的 scratchpad中间推理结果
长期记忆向量数据库 + 检索跨会话的知识
外部知识RAG / 搜索引擎实时信息获取

工具使用（Tool Use / Function Calling）

工具调用机制

现代 LLM 通过 function calling 机制调用外部工具：

// 工具定义
{
  "name": "search_web",
  "description": "搜索互联网获取实时信息",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {"type": "string", "description": "搜索关键词"},
      "max_results": {"type": "integer", "default": 5}
    },
    "required": ["query"]
  }
}

// 模型输出（决定调用工具）
{
  "tool_calls": [{
    "function": {
      "name": "search_web",
      "arguments": "{\"query\": \"北京明天天气\"}"
    }
  }]
}

MCP（Model Context Protocol）

MCP（Anthropic, 2024）是一个标准化的 Agent-工具通信协议：

┌─────────┐     MCP      ┌─────────────┐
│  LLM    │◄────────────►│  MCP Server  │
│  Agent  │   标准协议     │  (工具提供者) │
└─────────┘              └─────────────┘
                              │
                         ┌────┴────┐
                    [GitHub] [Slack] [DB] ...

MCP 的价值：

  • 标准化：一套协议连接所有工具，不用为每个工具写适配器
  • 安全：权限控制、审计日志
  • 可发现：工具可以自描述其能力
  • 互操作：不同的 LLM/Agent 框架都能使用同一套工具

2026 年，MCP 从 Anthropic 发起扩展为 Agent 基础设施标准的一部分。OpenAI、Google、Microsoft 等主要厂商均已采纳。生态数据（2026-07-28 官方公告）：MCP 月度 SDK 下载量突破 4 亿（4 倍年增长），TypeScript 与 Python SDK 累计下载量均已突破 10 亿次；Claude 应用商店收录 950+ MCP Server，全生态可用 MCP Server 超 10,000+；Google ADK 原生支持 MCP，意味着 MCP 已成为 Agent-工具通信的事实标准。MCP 现由 Linux Foundation 旗下 Agentic AI Foundation 治理，Anthropic 与 OpenAI 共同参与。官方 registry 收录数另已达 25,000+（2026-08-26 核实）——⚠️ 两个数字口径不同（Anthropic 公告的”全生态可用” vs registry 收录计数），不可互相替换，引用时须标明口径与快照日期。

2026-09-27 复核：数字推进了，而且多出第三个口径。 registry 收录（去重后 server）已升至约 30,000–32,000（第三方对官方 registry API 的几次独立全量统计：30,375 / 31,309 / 31,793，快照 2026-09-10 ~ 09-14）。⚠️ 该数字无官方公告口径，彼此相差约 3%，属中置信度，引用时请连同快照日期一起写。

⚠️ 更要紧的是第三个口径：收录条目 vs 去重 server。 registry 保留每个 server 的每一个历史版本，条目数天然是 server 数的 3.2 倍左右（99,114 ~ 101,219 条目 → 30,375 ~ 31,309 server）。本人对官方 API 的分页抽样也印证了这层差异：按名字字典序前段 22,967 条条目只对应 8,820 个不同 name。所以看到”MCP 生态有 N 万个 server”时，先问一句：数的是全生态、收录 server，还是收录条目——三者能差出一个数量级。

2026-10-16 复核：出现第四档，而且这份分歧暴露了引用规则还缺一项。 2026-10-13 的一份统计给出 42,753，而 2026-10-09 的另一份给出 40,965——两者相差约 1,788（≈4.4%），相隔仅 4 天。同一来源还称 2026 年 9 月单月新增 11,902 个 server，超过此前九个月的总和。

这条把本章的结论推进了一格：此前我们说”三个口径不能互相替换”，现在要补上——即便锁定到”registry 收录的去重 server”这一个口径，不同统计者在同一周内仍会差出 3–4%。所以完整规则是三项，缺一不可：

引用任何会自己增长的数字，必须标 ① 口径（全生态 / 收录 server / 收录条目）② 快照日期（精确到日）③ 统计者（谁数的）。

这与本章末尾”引用 benchmark 数字必须标注四项（来源 / 快照日期 / effort 档位 / harness）“是同一套规则——增长型数字与评测分数一样，都不是一个数，而是一条带坐标的读数。

本人实测（2026-10-16，官方 API 一手，但为下界）： 用 registry.modelcontextprotocol.io/v0/servers?limit=100 按 name 首字母分桶并行分页全量抓取，得到 68,190 条条目、20,300 个不同 name（条目/去重 name ≈ 3.36，与本章此前记录的”条目 ≈ server 数 3.2 倍”一致）。

⚠️ 三点必须同时说明，否则这个数会被误用：

  1. 这是下界，不是全量：并发抓取遭遇速率限制，部分分桶提前中断，实际条目数应更高。
  2. 它不足以判定 42,753 与 40,965 孰对——两者都远高于本次实测到的去重 name 数，说明第三方统计的”server”很可能不是”去重 name”这一口径（可能含非 active 状态、或按版本/仓库计数）。这正是”口径”这件事的现场演示：连官方 API 都能给出与媒体统计差一倍的数。
  3. 方法可复用：这条实测的价值不在那个数，而在它证明官方 registry API 可以自己跑全量统计（limit 上限为 100，limit=500/1000 会返 422；cursor 为 name:version，且任意前缀都可作起始 cursor，因此可分片并行）。凡需要”registry 到底有多少”的场合，应自己跑一遍，而不是引任何二手统计。

⚠️ 同时给本章的构成数据加一条时点警告：下面那批组成比例（62% 只发过一版等）是 2026-09 的快照。总数在一个月内涨了约 35%，这些比例很可能已经漂移。正确做法是加时点警告，而不是用新总数去反推新构成——构成比例的漂移通常比总数更快（新涌进来的一批 server 会把”只发过一版”的比例整体推高）。

但任何一个总数都不说明生态健康度。 ⚠️ 以下比例是 2026-09 快照，与上文的 2026-10 总数不是同一时点，请勿当作同一次快照读。 同一批统计给出的构成数据，对”生态规模”这个叙事是重要修正：

  • 62% 的 server 只发过一版（发布一次从未修订），约 36% 已三个月以上未更新
  • 22.6%（约 7,090 个）没有源码仓库链接，其中 remote-only 的 6,484 个（20.7%）根本无代码可读——“先审后接”的策略对五分之一的 registry 天然不可执行
  • 极度头部集中：最大单一发布者有 1,505 个单一功能微工具；top 10 发布者占 17.7%；89.7% 的发布者只有一个 server
  • 反直觉的一条：com.anthropic 在 registry 里 0 个条目——发起方自己几乎没往 registry 放东西，所以”registry 数量”天然低估头部高质量 server

（以上构成数据为第三方统计，中置信度，趋势一致但非官方公告。）

MCP 2026-07-28：史上最大协议更新。自 2024 年 11 月开源以来，MCP 于 2026 年 7 月 28 日发布了第五版规范，完成了从”有状态双向协议”到”无状态请求/响应模型”的架构级转变：

  1. 无状态核心：移除 initialize 握手和 Mcp-Session-Id 头——每个请求自描述（通过 _meta 字段传递协议版本和能力）。MCP Server 可部署在 AWS Lambda、Vercel、Cloudflare Workers 等 Serverless 平台，通过普通轮询负载均衡器水平扩展。这完全改变了 MCP 的部署范式——从”需要长连接的有状态服务”变为”无状态微服务”，基础设施门槛大幅降低。
  2. 治理层面：规范已移交 Linux Foundation 旗下 Agentic AI Foundation 治理，进入开放治理阶段。向后兼容：新客户端访问旧服务器时自动回退到 initialize 握手。
  3. MCP Apps（官方扩展）：Server 可在 Claude 聊天界面的沙盒 iframe 中直接渲染交互式 UI，无需切换标签页。这标志着 MCP 从纯 API 协议升级为应用分发平台——Server 不仅可以执行操作，还能自带用户界面。
  4. Tasks 扩展：基于轮询的异步任务机制，替代阻塞式 tasks/result，支持”分析 100GB 日志”等长耗时操作。
  5. MRTR（Multi Round-Trip Requests）：工具调用中支持 InputRequiredResult 向用户征询中间输入，无需长连接。
  6. 企业级安全：OAuth 2.0/OIDC 完整对齐（含 RFC 9207 issuer 验证、scope 累积 step-up）。企业可通过 Entra/Okta 集中管控 MCP 权限——管理员授权一次，用户通过 IdP 组继承、首次登录零配置。
  7. 分布式追踪：W3C Trace Context 强制要求。路由头（Mcp-Method 和 Mcp-Name）标准化为必填 HTTP 头。

对比旧协议：MCP 1.0（2026 初）的技术升级——弃用 SSE 传输、Streamable HTTP 成为推荐——在当时是一次重要跃迁，但到 2026-07-28，连”Streamable HTTP 的有状态模式”也被弃用。整个协议从”需要 Session 的远程调用”质变为”无状态的标准化 API 协议”。

下一步：MCP 2026-08-22 路线图五大优先方向：

  1. Agentic messaging primitives——用 webhooks / channels 实现服务端主动通知，让客户端停止轮询；把 Tasks 扩展（SEP-2663）成熟后并入规范核心。
  2. HTTP-native transport 统一与硬化——把无状态 HTTP 模型推广到更多部署形态，包括本地 server 在 stdio 上跑 Streamable HTTP。
  3. Agent identity 与企业级安全——MCP 授权当前假设”人类在浏览器里点同意”，但生产中的调用方越来越多是以自身身份运行的云端 Agent、用户不在场、或父 Agent 向子 Agent 委派更窄权限。方案基于 DPoP（RFC 9449）+ Workload Identity Federation + ID-JAG grant 的 token exchange，替代手工配置的 API key 与长生命周期 refresh token；并继续参与 IETF OAuth 与 WIMSE 工作组。
  4. Improved primitives——tools/call 结果的统一契约 + 大工具目录的渐进式发现（progressive discovery）。
  5. SDK 开发体验。

对齐五优先方向的 SEP 走加速审阅，范围外的提案不自动拒绝但排在其后。⚠️ 注意第 4 条：上文把”渐进式发现”写成 Anthropic 工程师（2026-04 公开演讲）的工程建议，现在它已上升为 MCP 官方路线图的第 4 优先方向——“一次性把所有工具塞进上下文”不再只是不经济，而是即将被协议层淘汰。

⚠️ 兼容性边界需要说清楚（2026-09-08 核实）：上文第 2 条写”新客户端访问旧服务器时自动回退到 initialize 握手”，这是一个乐观表述。官方兼容性矩阵把”现代客户端 + 旧服务端”标记为 failing；旧服务端之所以仍能工作，是因为官方 SDK 对两个时代的协议都提供支持，而非协议本身保证兼容。此外 2026-07-28 版本引入了最短 12 个月的弃用周期并首次使用（SEP-2577）：

已弃用能力迁移路径最早移除
Roots通过工具参数、resource URI 或 server 配置传递目录与文件2027-07-28 及之后发布的第一个修订版
Sampling直接对接 LLM 提供商 API同上
Loggingstdio 传输写 stderr；可观测性用 OpenTelemetry同上
Dynamic Client RegistrationClient ID Metadata Documents（CIMD）同上

五个 Tier-1 SDK（TypeScript / Python / Go / C# / Rust）在 2026-07-28 发布当日即提供稳定支持，v2 为默认安装、v1 冻结为仅安全修复。基于 v1 SDK 或 Roots/Sampling/Logging 的实现需要排期迁移。

MCP 的上下文膨胀挑战与解决方案

MCP 的大规模落地暴露了一个关键工程问题：上下文膨胀。当工具描述全部塞入上下文窗口时，token 消耗急剧增长——例如 Chrome DevTools MCP 的 26 个工具需要 17,500 tokens，3-4 个 MCP 服务器即可占用 50k+ tokens，远超许多模型的上下文预算。

Anthropic 官方（2026-04，David 工程师公开演讲）提出了三大解决方案：

  1. 渐进式发现（Progressive Discovery）：不再一次性加载所有工具，改为按需搜索和加载。“工具加载工具”模式——模型判断需要某类工具时才查找并加载对应 schema。
  2. 程序化工具调用（Programmatic Tool Calling / Code Mode）：给模型一个执行环境，生成代码一次性完成多步操作，配合结构化输出减少多轮调用。这与下文讨论的”程序化工具调用”架构范式直接对应。
  3. 服务器端面向 Agent 设计：停止将 REST API 一比一映射到 MCP，从 Agent 视角设计接口，提供执行环境让模型自己组合能力。

工程实践已验证这些方案的有效性：

  • Cloudflare CodeMode（2026-02）：search + execute 双工具模式，仅 ~1000 token 固定上下文覆盖 2500+ API 端点，99.9% token 降幅
  • PMCP（渐进式 MCP 开源实现）：16 个 stable 元工具覆盖 90+ 下游工具，能力卡片优先展示 → 按需加载详细 schema
  • mcp-code-wrapper：96% 上下文节省

更重要的是，MCP 的定位正在从”Agent↔工具”的连接协议升级为应用分发层——Agent 可自带 UI 独立运行，不再寄生在宿主应用内。这标志着 MCP 从通信协议到生态平台的演进。2026-07-28 的 MCP Apps（沙盒 iframe 渲染）和 Tasks 扩展（异步轮询）进一步强化了这一趋势——MCP Server 现在可以是一个完整的微型应用，而非单纯的 API 端点。企业级管理认证（EMA）的引入也为 Agent 工具调用的权限管控和审计日志提供了生产级答案。

Skills over MCP（SEP-2640，已定稿）：同一方向的第二次推进。 2026-09-13 合并并标记 Final 的 SEP-2640 给 MCP 增加了 io.modelcontextprotocol/skills 扩展：Server 声明该扩展后须实现 skills/list（枚举技能）与 skills/get（按 URI 取单个技能），技能文件通过已有的 resources/read 原语提供（约定 skill:// URI）。

从 MCP Apps 到 Skills，Server 能分发的东西从 UI 进一步扩展到了可执行的领域方法论，而且带了一套 digest 绑定的审批模型：

  • 每个技能条目包含完整 YAML frontmatter + 每个文件的 URI + SHA-256 digest + 字节数清单
  • 宿主必须把读取限制在已保留的清单内，用前校验 digest 与大小；任一文件变更须重新取得用户批准
  • 规范建议单技能 ≤ 512 文件 / 16 MiB；清单也可以是字符串 "dynamic"（技能文件按需生成、没有稳定 digest 时）
  • digest 是逐文件的，不是逐技能的——早期草案只对 SKILL.md 做 digest，意味着 Server 可以先让一个无害技能通过审批、再换掉模型同样会照读的引用文件

这与上面的”渐进式发现""服务器端面向 Agent 设计”构成一条完整的线：MCP 正在把”上下文里该放什么”这个问题从客户端搬到协议层，而且这次连”放进去的东西有没有被偷偷改”也一并管了。

⚠️ Final ≠ 落地：截至 2026-09-22，第三方对 1,432 个托管 MCP 端点做匿名 initialize 探测，572 个完成握手，其中只有 2 个声明了该扩展（Hugging Face 与 RenooLab）。规范定稿到生态采用之间还有一段路——这条提醒与本章”协议标准化 ≠ 互操作已解决”是同一个判断（该探测为第三方实测，中置信度）。

Agent 协议栈：从工具到协作

MCP 解决了 Agent 与工具之间的通信，但 Agent 之间如何协作？2026 年 Agent 协议栈分化为清晰的三层架构：

层次协议发起方解决的问题
Agent↔工具/数据源MCPAnthropic（2024）Agent 如何调用外部工具和访问数据
Agent↔AgentA2AGoogle（2025）→ Agentic AI Foundation / Linux Foundation（2026-08 起）不同 Agent 如何发现和协作（含原 ACP 边缘协同能力）
边缘协同ACP（已并入 A2A, 2026）——
浏览器侧（观察中）WebMCP站点向 agent 暴露可调用工具⚠️ 尚未进入标准轨道：2026-06-09 起随 Chrome 149 开放 origin trial；2026-10-08 W3C WebML CG 发布新 draft report，但仍不在 W3C Standards Track

⚠️ 第四行的身份是”候选 / 观察中”，不能与 MCP、A2A 并列为”已成立的支柱”。 本章历史上已经出过两次同类错误——“把 RC 当 GA”（第 10 章 MCP）、“把已消失产品当趋势标志物”（Cowork，已更正）。判断标准是：有没有进入 W3C Standards Track。目前没有。 WebMCP 与 ARD 一样都处在”规范已发布、地位未定”这一档，读者应当按”可能变”来用，而不是按”已经有”来用。

A2A（Agent-to-Agent Protocol） 是 Agent 互操作的关键突破。2026 年 4 月，A2A 被 Linux Foundation 正式收录，150+ 组织支持，成为首个生产就绪的 Agent 互操作开放标准。核心机制包括：

  • Agent Card：Agent 的能力自描述文件，类似 API 的 OpenAPI Spec
  • 任务委派：一个 Agent 可以发现并委派任务给能力匹配的另一个 Agent
  • 多轮异步协商：支持复杂的跨 Agent 多步骤协作

MCP 和 A2A 的关系是互补而非竞争——MCP 定义 Agent 怎么用工具，A2A 定义 Agent 怎么跟 Agent 协作。两者共同构成 Agent 互操作基础设施。📌 2026 年 8 月起两者归入同一基金会（Agentic AI Foundation）治理——互补关系从”两家厂商的标准并行”升级为”同一中立治理架构下的分工”。

⚠️ 但”同一治理架构下”不等于”同一成熟度档”。 截至 2026-10 的两侧落差已经相当明显：

侧registry / 规范状态规模刻度
MCPregistry 已在规模化运转（收录数已达第四档量级，见 §MCP 生态数据）SDK 周下载量与 A2A 差一个数量级（见本节末尾表）
A2AAgent 发现与能力宣告这一层尚无定稿的正式规范：A2A Registry 规范长期停留在 open RFC；发现层的工作重心转向 AI Catalog / ARD小一个量级

⚠️ 两个”待回源”，本轮未能用官方源坐实，故按来源性质标注，不写成断言：

  1. 「A2A Registry 规范自 2026-08 起停滞、工作被重定向到 AI Catalog 与 ARD」——来自单一媒体（forkast）。本轮回源时发现一个与它不完全吻合的事实：ARD 的公布时间是 2026-06-17（Google Developers Blog），规范 v0.9 draft 标注 2026-05-28，即早于 2026-08。因此更稳妥的写法是”发现层的重心在 2026 年中转向 AI Catalog / ARD”，而不是”8 月起被重定向”。回 Linux Foundation / AAIF 官方公告后再定稿。
  2. ARD 本身的规格（多来源一致，中-高置信度）：Apache-2.0，由 Linux Foundation 的 AI Catalog 工作组孵化，作者含 Google / Microsoft / Hugging Face，核心是在 /.well-known/ai-catalog.json 发布一份能力清单（条目用 IANA media type 标注，可指向 application/mcp-server+json 或 application/a2a-agent-card+json），由 registry 抓取并建立索引。

给”双支柱”这个比喻加一个量化刻度（本轮改用一手源：npm / PyPI 下载量 API，实测窗口 2026-10-06 ~ 10-12）：

协议SDK 包周下载量（一手）
MCP@modelcontextprotocol/sdk（npm）64,994,424
MCPmcp（PyPI）63,432,248
A2A@a2a-js/sdk（npm）4,179,585

⚠️ 必须附带一条口径订正：第三方 adoption census 给的是”MCP 92.2M vs A2A 4.5M（约 21:1）“，这个数字组合用一手 API 无法复现——npm 单包是 65.0M（不是 92.2M），npm + PyPI 合计是 128.4M。所以结论要按”量级”而非”倍数”来写：

  • MCP 与 A2A 的 SDK 周下载量差约一个数量级（单包对照 15.6:1，两包合计对照 30.7:1），这个量级结论是稳健的；
  • 具体倍数（21:1）与两个绝对值均不可复现，引用时请给区间与口径（数的是哪个包、哪个窗口），不要把 21:1 当成精确值。

这不推翻”互补”，但修正了”支柱”这个比喻的对称性——两者不是对等的两根柱子，是一根已经规模化、一根刚起步。同一批来源的判断可以直接引用：“大多数团队现在需要 MCP；A2A 只在你的 agent 必须把工作交给一个不由你运行的 agent 时才需要。”

📌 ARD 的定位值得单独说清，因为它容易被误读成”MCP 的竞品”：ARD 不是替换 MCP，也不是替换 A2A，它是两者之上的”调用前发现层”——解决的是”agent 怎么知道有这个工具/这个 agent 存在”，选完之后仍然交回 MCP / A2A 各自的原生协议。MCP 教会了 agent 怎么用工具，但没有解决”去哪儿找到这个工具”，ARD 补的就是这一格。同时它明确覆盖 MCP 与 A2A 两类条目，因此不宜写成”只有 A2A 侧在做”。

AAIF 的来历已可回源到官方（2026-09-27 核实）：Linux Foundation 于 2025-12-09 宣布成立 Agentic AI Foundation，首批三个捐赠项目是 Anthropic 的 MCP、Block 的 goose、OpenAI 的 AGENTS.md；铂金成员包括 AWS、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft、OpenAI。三个创始项目里有两个是”指令 / 配置格式”，这解释了本书另一处（Claude Code v2.1.277 原生支持 AGENTS.md）的来历——Anthropic 接受了一个由竞争对手发起、且已被 60,000+ 开源项目采用的事实标准。

⚠️ 仍有两处需保留不确定性：A2A 被接收为 AAIF Growth Stage project 的日期在不同来源间存在 2026-08-17 / 2026-08-20 / 2026-08-27 三种说法（第三个来自一份持续跟踪的 adoption census），本书只写”2026 年 8 月”——三个来源给出三个日期这件事本身，恰恰佐证了”不写具体日”的处理是对的：当分歧不是两种而是三种时，最可靠的写法就是写月份；A2A v1.0（2026-03）引入的签名 agent card（AgentCardSignature，基于 RFC 7515 的 JWS）来自二手转述，未找到官方公告原文。

签名 agent card 值得写清它的边界：签名能证明这张卡由密钥持有者发布、且未被篡改（认证），但不能证明”你是否应该把任务委派给它”（授权）。协议可以提供可验证的身份，替不了你做授权决策——这是本章”协议标准化 ≠ 互操作已解决”最贴切的一条注脚。

这条判断有一个产业级版本。 Salesforce Winter ‘27（2026-10-12 GA）把 Agentforce 的 Third-Party Orchestration 扩展到”任何 A2A-compliant 生态”。关键不在 Salesforce，而在“compliant”由谁定义：实际出货的是”一份协议实现 + 一张自发布的 agent card”。这与上面签名 agent card 的判断结构完全相同：

签名 agent card 是技术层面的”能认证、不能授权”；“A2A-compliant” 是商业层面的同一件事。

同一批来源给出的判据可以直接用：“compliant”这个标签”提供了连接的共同语言，但不提供安全性或身份的保证”。 风险的表述也一致——行业正在从 de jure（法定）标准滑向 de facto（事实）标准：当”合规”由产品实现而非行业共识来定义，“互操作”就容易退化成”接入某个主导平台的实现”。

一条更硬的密码学边界，值得和上一段并置。 ARD 的 trustManifest 支持用 HTTPS 身份做签名，但有分析指出一个结构性弱点：如果 JWK Set 与清单文件同在一个源站上，那么能改写 ai-catalog.json 的攻击者，也能在同一次入侵里改写 jwks.json 并换掉密钥，产出的清单照样能通过验证——因为被签文档与为之作证的密钥共享同一份命运。同样的限制还有：trustManifest 的签名只覆盖清单本身，不覆盖 entries，因此把某条目的 url 改指向恶意 MCP 端点，签名依然有效。

📌 合起来的判据：签名解决的是”这份文档没被中途改过”，不解决”签发者可信”，也不解决”条目内容可信”。凡看到”已签名 / 已验证”就当成”已授权”的读法，在这三层上都会出错。 签名只有在验证密钥可独立于被签文档解析（DNSSEC 记录、带外 pin 的密钥、源站沦陷也够不着的 JWK 设施）时才值它的重量。

⚠️ 来源性质：Salesforce Winter ‘27 的 GA 日期与 A2A 覆盖范围为单一媒体转述，须回 Salesforce 官方 release notes 确认；上段密码学边界来自对 ARD 规范的第三方分析，已与多个独立来源的规范描述一致，但未逐条回规范原文。

工具使用训练

教模型正确使用工具需要专门的训练：

方法思路代表
SFT on tool data在工具调用数据上微调Gorilla
Self-play模型自己生成工具使用轨迹Toolformer
RL with tool feedback工具执行结果作为奖励信号ToolRL

Toolformer（Schick et al., 2023, Meta）的方法特别优雅——让模型自己决定在文本中”何时”、“何处”插入工具调用，用工具返回结果是否降低 PPL 作为选择标准。

RAG（检索增强生成）

基本架构

RAG（Lewis et al., 2020）将检索系统与生成模型结合，解决 LLM 的知识过时和幻觉问题：

用户查询 → [Embedding 模型] → 查询向量
                                ↓
                    [向量数据库检索] → Top-K 相关文档
                                ↓
        [用户查询 + 检索到的文档] → LLM → 回答

RAG 系统组件

组件选项说明
Embedding 模型BGE, E5, GTE将文本转为向量
向量数据库Milvus, Pinecone, Chroma高效相似度搜索
文档处理切分、清洗、元数据提取预处理管线
重排序Cohere Reranker, BGE-Reranker精排提高质量

高级 RAG 技术

Chunk 策略对 RAG 质量影响巨大：

固定长度切分:  [512 tokens] [512 tokens] ...  → 简单但可能切断语义
语义切分:     [段落A] [段落B] [段落C] ...       → 保持语义完整
层次切分:     [文档摘要] → [章节摘要] → [段落]   → 多粒度检索

Self-RAG（Asai et al., 2023）让模型自己决定是否需要检索：

生成过程中:
  Token Token Token [NEED_RETRIEVE] → 触发检索
  → 检索结果注入
  → [IS_RELEVANT] Token Token Token [CITE] → 带引用继续生成

代码 Agent

Coding Agent：从辅助到自主

2026 年，编程 Agent 从”IDE 内代码补全”演化为两个层级：

IDE 集成 Agent——实时辅助，嵌入在编辑器工作流中：

系统特点
CursorIDE 内代码生成/编辑/重构，工业应用最广
GitHub CopilotVS Code/JetBrains 集成，Agent 模式支持多文件编辑

CLI/云端自主 Agent——异步执行完整开发任务（理解 issue → 探索代码库 → 修改代码 → 运行测试 → 提交 PR）：

系统特点自主程度
Claude Code终端原生 Agent（2026 年扩展为通用 Claude Agent SDK），MCP 生态集成，从 npm 迁移到原生安装；Agent SDK 与 claude -p 自 2026-06-15 起从订阅信用独立计费高——可自主完成完整任务
Codex CLIOpenAI 云端异步 Coding Agent高——异步执行，结果可审查
Devin端到端软件工程 Agent高——全自主开发
SWE-Agent自动修复 GitHub issue中——专注 issue 修复
OpenHands开源 Coding Agent 平台中——社区活跃

读 2026 H2 编码榜单前必须知道的一件事：

上表按”系统”列举并给出”自主程度”，隐含的假设是能力归属于系统本身。2026 H2 的榜单现实推翻了这个假设：Terminal-Bench 4.0 起，榜单条目是”模型(effort 档位) + 通用 agent harness”三元组（harness 为 Claude Code / Codex / Grok Build / mini-SWE-agent），不再是 2.0 时代 topping 榜单的专用 scaffold；换用更难的任务集后，最佳解决率从 2.0 版的 84.7%（据第三方榜单记录，本轮未回源核实）降到 58.2%。

榜首两名值得连着读：GPT-6 Astra(max) + Codex，58.2% ± 2.8%（2026-09-03）；Fable 5.1(max) + Claude Code，57.9% ± 3.8%（2026-09-01）。差 0.3 个百分点，而两者置信区间几乎完全重叠——榜单的名次在这里没有统计意义，只有”这两个组合处在同一档”是可读的信息。

脱离 harness 与 effort 档位谈模型的编码能力已不可比——同一模型在 Claude Code 与在 Codex 下的分数是两个不同的数，“模型 vs 模型”和”harness vs harness”是两条独立的轴。（这也解释了为什么 DeepSeek 会在模型卡里注明”以 DeepSeek Harness 的 minimal 模式、max effort 测得”——见第 15 章。）

📌 另记一个现实案例，供”不要盲目相信 benchmark 数字”一节引用：据第三方榜单记录，GPT-6 Astra 在 OpenAI 官方发布页出现了 57.7%（表格）与 57.9%（图注）两个 Terminal-Bench 4.0 数字，次日抓取时表格已静默改为 57.9%，OpenAI 未作说明。来源单一，引用时须标注”据第三方记录”。⚠️ 更值得注意的是：这两个自报数字与 tbench.ai 官方榜单登记的 58.2% 都不一致——厂商发布页的自报分数与基准官方榜单是两套口径，不可混用。

2026-09-27 复核：这套口径差出现了第二个、也更极端的实例。 Anthropic 在 2026-09-22 的 Opus 5.5 发布页自报 Terminal-Bench 4.0 = 66.4%（xhigh effort，±2.6），但 Opus 5.5 截至 2026-09-27 尚未出现在 tbench 官方榜单上——自报值比官方榜首（58.2%）高出 8.2 个百分点。这是本章”自报 vs 榜单”警示的第二个实例，且比 Astra 那一例更极端：Astra 是三个数字彼此差 0.5pp 以内，这里是”自报直接突破榜首且不在榜上”。

而且同一模型名下会同时挂着多个分数，容易被误读成”数字变了”。 Anthropic 09-22 的发布页脚注称公开榜上 Opus 5 为 51.8%，而 tbench 页 09-27 在榜首区域显示的是 53.9%。⚠️ 这不是快照漂移：解析 tbench 官方榜单 payload（rank 字段）后确认，两条是同时挂在榜上的活跃行，只是 effort 档不同——Opus 5 的 max 档 51.8% ±3.4（官方榜第 10 名）与 xhigh 档 53.9% ±3.2（第 8 名），同属 2026-07-24 那次提交，至今都在榜上；Anthropic 脚注取的是前者作为对照。真正的教训是同一模型名下的多个 effort 条目会被不同来源各取一个，所以本章的引用规则要从”两套口径”升级为四项：引用 benchmark 数字必须一并标注①来源（厂商自报 / 基准官方榜）、②快照日期、③effort 档位、④harness。（同一判定在第 1 章 Terminal-Bench 段落有展开叙述。）

榜单前列（tbench.ai 官方页，2026-09-27 抓取）：

序（按模型去重）官方榜实际名次模型（effort）harness解决率成本
1第 1 名GPT-6 Astra (max)Codex58.2% ± 2.8$3.3k
2第 2 名（并列四项）Fable 5.1 (max)Claude Code57.9% ± 3.8$6.2k
3第 8 名Opus 5 (xhigh)Claude Code53.9% ± 3.2$6.1k
4第 14 名Fable 5 (max)Claude Code44.5% ± 3.8$7.3k
5第 16 名GLM-5.3 (max)Claude Code41.8% ± 3.2$2.7k
6第 17 名Grok 4.7 (xhigh)Grok Build37.6% ± 3.5$3.7k

⚠️ 两列名次为什么不一样：官方榜把所有 effort 档都算作独立行（同一模型最多挂五档），且并列同分共享名次，所以”去重后第 3 行”在官方全量榜上是第 8 名。引用名次时必须说明用的是哪一种口径。

两点值得单说。其一，第 5 名的 GLM-5.3 用的是 Claude Code harness——一个非 Anthropic 模型借 Claude Code 上榜，是”harness 是独立变量”最干净的证据；榜单的”模型”列里混着各家模型，而 harness 列只有四种取值，真正的可比单位是三元组，这一点本章写对了，现在有了更直观的证据。其二，成本列是本段此前完全没用上的维度：Astra 58.2% 花 3.3k，Fable5.157.93.3k，Fable 5.1 57.9% 花 6.2k——分数差 0.3pp，成本差近一倍；Sonnet 5(max) + Claude Code 只有 12.4% ± 3.1，却烧掉 21.6B tokens / $9.6k。所以本段的结论要补上下半句：名次在这里没有统计意义，但成本列有。

代码 Agent 的工作流

1. 理解问题 → 阅读 issue / 用户描述
2. 探索代码库 → 搜索相关文件、理解架构
3. 定位问题 → 找到需要修改的文件和位置
4. 编写代码 → 生成 patch / 新代码
5. 测试验证 → 运行测试、检查结果
6. 迭代修复 → 如果测试失败，分析原因并重试

推理模型（Reasoning Models）

o1/o3 与 DeepSeek R1

推理模型（Reasoning Models）代表了 LLM 的一个新范式——在推理时通过延长思考来提升能力：

OpenAI o1（2024）和 DeepSeek R1（2025）是这一方向的标志性工作。

核心思想是 Test-Time Compute Scaling：

传统模型: 输入 → [固定计算量] → 输出
推理模型: 输入 → [可变计算量: 思考链可以很长] → 输出

简单问题: 短 CoT → 快速回答
困难问题: 长 CoT (数千 token 的推理) → 仔细推导

推理模型的训练

DeepSeek R1 的训练流程揭示了推理能力是如何涌现的：

阶段 1: Cold Start（少量推理示例 SFT）
  → 模型学会基本的 CoT 格式

阶段 2: RL (GRPO)
  → 用数学/代码的正确性作为奖励
  → 模型自发学会更长、更深入的推理
  → "Aha moment"：模型学会自我纠错

阶段 3: Rejection Sampling + SFT
  → 用 RL 模型采样高质量推理数据
  → SFT 训练更稳定的推理模型

阶段 4: 再次 RL
  → 进一步精炼

关键发现：推理能力可以通过 RL 自发涌现——不需要人类编写详细的推理步骤，只需要给正确答案的奖励，模型就会自己学会推理。

推理模型蒸馏

DeepSeek 发现 R1 的推理能力可以有效蒸馏到小模型：

蒸馏模型基座AIME 2024MATH-500
R1-1.5BQwen2.5-1.5B28.9%83.9%
R1-7BQwen2.5-7B55.5%92.8%
R1-14BQwen2.5-14B69.7%93.9%
R1-32BQwen2.5-32B72.6%94.3%
R1-70BLLaMA-3.3-70B79.8%94.5%

小模型通过蒸馏获得的推理能力，甚至超过了直接 RL 训练的效果。

Multi-Agent 系统

多 Agent 协作

复杂任务可以由多个专门化的 Agent 协作完成：

┌──────────┐
│ Planner  │ → 分解任务、分配给专家
└─────┬────┘
      │
  ┌───┴───┬───────┬──────┐
  ▼       ▼       ▼      ▼
[Coder] [Writer] [Researcher] [Reviewer]
  │       │       │            │
  └───────┴───────┴────────────┘
                  │
            ┌─────▼─────┐
            │ Integrator │ → 整合结果
            └───────────┘

代表框架——2026 年分为两个层次：

官方 Agent SDK（三大厂商的第一方 Agent 开发工具）：

SDK厂商特色工具发现策略MCP 集成
Claude Agent SDKAnthropicHarness 工程最佳实践渐进式发现（Progressive Discovery）原生深度集成
OpenAI Agents SDKOpenAISwarm 生产版，handoff + guardrails + trace预加载 + 按需筛选支持 MCP
Google ADKGoogleA2A + MCP 双协议原生支持混合模式（预加载基础 + 按需发现）原生深度集成
Microsoft Agent Framework（python 1.19.0 / dotnet 1.22.0）MicrosoftAutoGen + Semantic Kernel 统一，原生 MCP+A2A，DurableTask 持久化工作流原生支持原生深度集成

Microsoft Agent Framework（1.0 GA 于 2026-04-03，截至 2026-09-27 已推进到 python 1.19.0 与 dotnet 1.22.0，两者均发布于 2026-09-18）是当前最活跃的厂商级 Agent 框架——融合了原 AutoGen（多 Agent 对话）和 Semantic Kernel（提示编排），原生支持 MCP + A2A 双协议，并集成 DurableTask 提供持久化工作流能力。

五个月从 1.0 走到 1.19，本身就是一个观察样本。1.19.0 的破坏性变更尤其说明问题——框架正在把多租户与供应链边界钉死，这与本章”Agent 基础设施成熟化”是同一条线：

  1. HTTP cookie 持久化改为显式 opt-in：框架自建的 MCP / A2A / AG-UI HTTP 客户端默认不再保留响应 cookie——依赖隐式 cookie 会话的集成会断
  2. MCP 技能归档仅限 ZIP（TAR / TAR.GZ 被检测出来后跳过，不再解包）+ MCP sampling callback 弃用
  3. provider 支撑的 MCP 会话按每次调用（per invocation）隔离——多租户场景的安全边界变化
  4. Redis 历史存储键按 provider 与会话身份隔离

第 1 条与第 3 条是同一类动作：把”默认共享”改成”默认隔离”。这与本书反复出现的 fail-closed 取向一致，只是发生在框架层而非模型层。（版本与破坏性变更清单回源 GitHub release 页，高置信度。）

Claude Agent SDK 生产化变更（2026-06-15）：Anthropic 将 Agent SDK 与 claude -p 非交互式调用从订阅计划中独立抽取 Agent SDK 信用：

订阅计划Agent SDK 信用
Pro$20/月
Max 5x$100/月
Max 20x$200/月

用尽后切换到标准 API 费率（若启用）或停止请求。这一变更显著影响 CI/CD 与定时 Agent 任务的成本核算——使用前应做工作量评估。

开源 Agent 框架：

框架特点适用场景
LangGraph图结构工作流复杂状态管理
CrewAI角色化 Agent 团队业务流程
AutoGen多 Agent 对话通用协作

Harness Engineering：Agent 工程的新维度

2026 年 4 月 Claude Code 源码泄露后，一个新概念进入行业视野——Harness Engineering。它指的是包裹在模型外面的整套工程系统：

┌─────────────────────────────────────────┐
│              Harness（外壳工程）           │
│                                         │
│   提示词构建 │ 工具调度 │ 权限控制        │
│   上下文管理 │ 错误恢复 │ Feature Flags  │
│                                         │
│         ┌─────────────────┐             │
│         │   LLM（模型）    │             │
│         └─────────────────┘             │
│                                         │
└─────────────────────────────────────────┘

Claude Code 的泄露代码揭示了 Harness 的真实复杂度：51 万行代码、42 个工具、6 种 Agent 模式、44 个 Feature Flag。Sebastian Raschka 的判断——“Harness 比 Model 更重要”——正在被行业验证。多个独立分析项目（claude-harness.dev 交互式源码分析、ClaudeCode-Leak 技术调查）围绕泄露代码形成了完整的学习生态。

这标志着 Agent 领域的认知升级：从”怎么让模型更聪明”到”怎么把工程做对”。

Agent 安全

Agent 能”做事”也意味着能”搞破坏”。安全考量：

  1. 权限最小化：Agent 只应获得完成任务所需的最小权限
  2. 人类确认：关键操作（删除、支付、发送）前需人类确认
  3. 沙箱执行：代码执行在隔离环境中进行
  4. 审计日志：所有工具调用都需要记录
  5. 输入验证：防止注入攻击（prompt injection 通过工具输出注入恶意指令）

未来展望

1. 更长的上下文窗口

从 4K → 32K → 128K → 1M+ tokens，更长的上下文意味着：

  • 更完整的文档理解
  • 更长的对话记忆
  • 减少 RAG 的依赖（直接把文档放进上下文）

但长上下文不是万能药——Lost in the Middle 研究表明模型在长上下文中间部分的信息检索能力显著下降。

2. 更高效的训练

  • 数据效率：用更少的数据达到同样的能力（合成数据、课程学习）
  • 计算效率：新的架构（如 Mamba 等 SSM）减少训练 FLOPs
  • 通信效率：更好的并行策略减少 GPU 间通信开销

3. 个性化与定制

让每个用户拥有”自己的” AI：

  • 长期记忆：记住用户的偏好、习惯、历史
  • 风格适应：根据用户沟通风格调整输出
  • 领域专精：通过少量数据快速适应特定领域

4. 端侧模型

趋势代表意义
手机端 LLMApple Intelligence, Gemini Nano隐私保护、离线可用
PC 端 LLMCopilot+ PC, 本地 Ollama低延迟、无 API 成本
嵌入式 LLMPhi-4-mini, Qwen 3-0.6BIoT、机器人

5. Agent 基础设施成熟化

2025-2026 年 Agent 领域最大的变化是基础设施的标准化和工程化：

  • 协议标准化：MCP（Agent↔工具）和 A2A（Agent↔Agent）构成了 Agent 互操作的双支柱。三大厂商的官方 Agent SDK 均已支持这些协议

  • Harness Engineering：从 Claude Code 泄露事件中获得的行业共识——Agent 的竞争力不在模型本身，而在包裹模型的工程系统。提示词构建、工具调度、上下文管理、错误恢复的工程复杂度远超预期

  • 自主开发 Agent：Claude Code、Codex CLI 等工具展示了 LLM 作为编程 Agent 的巨大潜力——不是”代码补全”，而是”自主完成从 issue 理解到 PR 提交的全流程”

  • 多 Agent 协作：从单一 Agent 走向多 Agent 团队协作（planner + coder + reviewer），A2A 协议为跨厂商 Agent 协作提供了标准化基础

  • 治理的执行点下沉到协议层（）：上面四条讲的都是”协议怎么定""工程怎么做""在哪里跑”，但“谁在运行时真正拦住一次越权调用”这一格本章此前是空的——§Agent 安全 给的五条原则（权限最小化、人类确认、沙箱执行、审计日志、输入验证）全在应用侧，没有基础设施侧的执行点。

    Google 在 Cloud Next ‘26 发布 Agent Gateway，被称为首个来自主要云厂商的 protocol-native agent gateway：基于 Envoy 与 Kubernetes、用标准 K8s Gateway API 保持开放可扩展；与传统 API 网关只看 HTTP 头与 IP 不同，它原生解析 MCP 与 A2A 消息，从中提取工具名、模型标识、Agent 身份做细粒度 RBAC。执行模型很具体：mTLS 握手时用 SPIFFE 校验 Agent 身份 → deframing filter 解析 MCP 消息得到 method 与 tool name → 按策略只放行该身份获批的调用。配套 Model Armor（prompt injection / tool poisoning / 敏感数据泄露）、Agent Identity（非人类行为体的加密 ID）、Security Command Center 自动发现 Cloud Run / GKE 上未纳管的 agent 与 MCP server。

    📌 一句话落点：网络层只能看到流量去哪，协议层能看到流量想干什么。

    与本章已有的 MCP 企业级安全（OAuth 2.0/OIDC 对齐、可通过 Entra/Okta 集中管控）并置读：那是身份与授权的下发点（IdP），这是运行时的执行点（gateway）——同一条链的两端，本章此前只有前半段。

    ⚠️ 两条限定（必须保留）：① 发布状态存在来源冲突——forkast 报道为 preview，另一来源称已 GA、仅 Cloud Trace 集成等仍为 preview。本书不判定，以 Google Cloud 官方文档的 release notes 为准。 ② 本条主体来自对 Cloud Next ‘26 技术披露的媒体报道，非官方一手。

  • 云端异步 Agent 执行：Agent 任务正从本地桌面迁移到远程云端——Agent 会话在云端远程运行，关掉设备后工作继续，定时任务无需设备在线，跨设备同步（桌面开始→手机查看→任意设备拿结果），需要人工验证时通过推送通知唤醒用户。这标志着 Agent 基础设施从”开发者本地工具”向”消费者云服务”的关键转型。

⚠️ 2026-09-27 更正标志物：本条原以”Claude Cowork 2026 年 7 月扩展至 Web 和移动端”为标志。Cowork 作为独立入口已于 2026-09-16 被取消——Anthropic 官方博客《Claude Cowork and chat are now one Claude》宣布 Cowork 与 chat 合并为”一个 Claude”，官方给的理由是”用户抱怨要自己决定任务该放哪儿”（同日推出 Claude Docs 与 Claude Slides 两个 beta，Claude Design 也并入对话内）。被引用为标志物的产品已经不存在了，但论点本身没被推翻——需要换一个标志物。

更好的新标志物是 2026-09-17 的 Claude Code Projects 重构（官方博客《Projects redesigned: from folder to conversation》，一手，Claude Code 类目下）：一个项目 = 一个协调者对话 + 多个并行云端线程。它比 Cowork 更贴合本条论点，因为官方在这一篇里给出了三个可引用的工程事实：

  1. 每个线程是一个完整的 Claude Code 云会话，跑在自己的分支与自己的仓库副本上，可开 PR、跑测试；线程之间若改动同一处代码，冲突按普通 merge conflict 处理——官方明说没有发明特殊的冲突解决模型。
  2. 关掉电脑后继续跑，可从手机查看与转向；线程之间共享项目记忆与 Library（收集你加入的文件与 Claude 产出的产物）。
  3. 每个线程都算一个完整会话，所以 projects 会比单会话更快达到用量上限（官方原话：projects can reach usage limits faster）。这是”云端异步执行”在计费层的直接后果。

⚠️ 两处边界：① 本次重构是 beta，首发给”使用 Claude Code 云会话、且没有既有 web/桌面 projects”的 Pro / Max 订阅者，逐步扩大；② 线程目前只在云端跑——官方说”在你本机、本地工具与内网之中运行”是 coming very soon，即当前还不含本地终端线程。

另需澄清一个容易误读的点：Cowork 的合并对象是 chat 与 Design，不是 Claude Code。Claude Code 不仅未被合并，反而在次日（09-17）拿到了上面这套云端并行线程能力。消费者侧的”入口合并”与开发者侧的”云端化”是两件事，方向甚至相反。

6. 科学发现

LLM 正在从”工具”走向”科学家”：

  • AlphaFold（蛋白质结构预测）
  • FunSearch（数学发现）
  • 药物发现、材料科学、气候建模

7. 安全与对齐的长期挑战

随着模型能力增强，安全问题也在升级：

  • Scalable Oversight：如何监督比人类更强的 AI？
  • Deceptive Alignment：模型是否可能”假装”对齐？
  • Value Lock-in：如何确保 AI 的价值观随社会演化？
  • Catastrophic Risk：如何防止高能力 AI 系统的灾难性失败？

写在最后

大模型正处于一个技术爆炸的时代。从 GPT-3 到 GPT-5，从 Chat 到 Agent，从纯文本到多模态——每半年都有让人惊叹的进展。

但在兴奋之余，有几个原则值得铭记：

  1. 基础比前沿重要：理解 Transformer 的数学、Scaling Laws 的物理、数据工程的细节，比追赶最新论文更有价值
  2. 工程和科学同样重要：一个好的分布式训练系统、一套可靠的评估基础设施、一条高效的数据管线——这些”不性感”的工作，往往决定了项目的成败
  3. 保持批判性思维：不要盲目相信 benchmark 数字，不要轻信模型的输出，不要低估安全问题的复杂性。
    • 厂商自己也会拆自己的数字，而且比第三方批评更有教学价值。Anthropic 在 2026-09-22 的 Opus 5.5 发布页主动披露了两件事：① 评测时开着生产安全护栏，护栏介入时网络安全任务改由 Opus 4.8 完成、生物与前沿 LLM 开发任务改由 Opus 5 完成，官方承认这很可能拉低了自家分数；② 官方原话——在这些能力水平上，benchmark 分差已不再是现实差异的可靠指南。
    • 连”分数被自己的安全策略压低了”都要写出来，这不是谦逊，是一个信号：当分差小到无法区分时，厂商自己也知道排行榜已经失去了分辨力。上文”榜首两名差 0.3pp、置信区间几乎重叠”是第三方视角的同一个结论，而这是厂商视角。
    • 实践建议：引用任何 benchmark 数字时，一并记下来源（厂商自报 / 基准官方榜）、快照日期、effort 档位、harness 四项。本章的 Astra 三数字、Opus 5 的 51.8% vs 53.9%、Opus 5.5 的 66.4% 不在榜，都是缺了其中某一项造成的。
  4. 动手实践：读一百篇论文不如训一个小模型。从 NanoGPT 开始，亲手体验训练的每一个环节

这本书的目标不是让你”知道”大模型，而是让你有能力动手做。希望它能成为你在这个激动人心的领域中的可靠参考。

“The best way to predict the future is to invent it.” — Alan Kay

持续更新中。有问题、建议或勘误，欢迎联系作者。