产品与工程

Module 07 · Engineering

产品与工程：哪些内部经验被写成了公开规范

这一章的判据不是「发布了什么产品」，而是哪些经验被抽象成了别人能直接用的规范。凡是只有公司自己能用的做法，不计入「最佳实践」。

Agent 设计范式上下文工程工具与协议生态Claude Code外部验收评测方法论收容转向一页纸手册我的看法


  
  
  
  **第一维 · 来源距离**（药丸形）：这份材料离原始出处有多近。本章一手来源绝大多数是 `anthropic.com/engineering` 与 `modelcontextprotocol.io` 的公开文档。


  
  
  
  
  
  
  **第二维 · 结论独立性**（方角 + 五格进度条）：这个结论被谁验证过。**这一维在本章格外重要**——下面几乎每一条「最佳实践」的证据都来自 Anthropic 自己的工程博客。



  警示 · 本章的证据结构有一个系统性偏斜，请先读这段
  

这一章写的是「最佳实践」，而它的证据几乎全部由同一家公司生产：实验是 Anthropic 做的、harness 是 Anthropic 写的、评测是 Anthropic 选的、数字是 Anthropic 报的、结论也是 Anthropic 下的。这不意味着这些经验是假的——它们是真实的一手记录；但它意味着没有第三方检验过这些收益能否迁移到别人的代码库、别的任务分布、别的团队规模上。

所以本章的每一枚徽章都是成对的： 这个组合读作「材料是真的，结论还没被独立检验过」。**两句话都对，缺任何一句都会误导。**凡是有独立机构做过对照的地方，我会把外部结果与官方数字并排放，并给出裁决。

  关键洞察 · 一条读完本章会一直用得上的元发现
  

把本章所有反面证据按「强度 × 杀伤力」排序，会看到一个不太容易想到的结构：最有分量的那几条，一手来源恰恰是 Anthropic 自己。「8 倍代码行数几乎肯定高估了真实生产力提升」是它自己写的；「我们过度依赖噪声大的评测」是它自己写的；「隐私控制妨碍了我们 debug」是它自己写的；把 Claudius 卖零食亏到幻觉出付款账号的完整记录，也是它自己发的。在整份反方档案的前十条最强证据里，有六条出自 Anthropic 的后续研究或自我披露。

这条发现必须写成三面的，单独用任何一面都会误导：

A 面（对 Anthropic 的实质性肯定）：在这个领域里，唯一在系统性地生产「反对自己上一个结论」的证据的机构，恰好就是被批评得最多的那一家。模式很清楚——第 N 篇论文提出一个结果，第 N+1 篇往往就把它的适用范围收窄了。

B 面（对所有转述者的警告，也包括本报告）：**只读第 N 篇不读第 N+1 篇的读者，会系统性地高估这些实践的可靠性。**而中英文世界绝大多数转述恰恰只读第 N 篇——因为第 N 篇有亮眼数字，第 N+1 篇只有限定语。本章第 5 节存在的全部理由就是补上第 N+1 篇。

C 面（不能被滥用的边界）：承受批评不等于回应了批评。「它自己都承认了」不构成任何一条批评的豁免，也不能被读成「所以 Anthropic 在自我否定」。

  口径说明 · 本章的每处对辩都标了「所在层」，因为这些争论不是同一种争论
  

本章的对辩块标题里会写经验层 / 测量层 / 世界观层。这个区分决定了一场争论能不能被证据解决：经验层（如「多 agent 到底有没有提升」）可以被更好的数据推翻；测量层（如「我们测的到底是不是我们以为的那个东西」）能被证明的往往是「目前测不了」；世界观层的分歧则原则上不由现有证据类型判定。

本章的争论几乎全部落在前两层，这是好消息——它意味着这些分歧原则上可以被更好的实验解决。但也要注意：本章第 5 节最重要的那条发现恰恰是测量层的，而测量层的结论比经验层的更难被后续数据改变。

  本章速记
  
    

• **这家公司的 agent 方法论只有一条主线：复杂度押回模型，不押回框架。**从《Building effective agents》的「你多半不需要 agent」，到 Claude Code 的 terminal-first、到 Agent Skills 的渐进式披露、再到《Code execution with MCP》把工具定义换成代码文件，是同一个信念的四次迭代。

• **它公开写的最反商业直觉的一句话，恰恰是被广泛引用的一句。**一家卖模型 API 的公司在旗舰工程文章里写「这可能意味着根本不要构建 agentic 系统」。

• **但「谨慎的原则」与「亮眼的数字」必须分开信。**独立研究（普林斯顿《AI Agents That Matter》、METR 的整体性评审、SusVibes 安全评测）指向同一个结论：agent 的 benchmark 收益被系统性高估，而 Anthropic 自己写下的谨慎原则反而基本站得住。本章第 5 节把外部对照与官方数字并排放。

• **MCP 是用放弃控制权换标准地位——但所有权只是若干竞争解释之一。**2024-11-25 开源，2025 年被竞争对手逐个接入，2025-12-09 与 Block、OpenAI 一起捐给新成立的 Agentic AI Foundation。时机、Claude 自身的分发量、协议本身足够简单、以及生态确实缺一个标准，同样能解释它的采纳。

• **2026 年工程博客的主题发生了可观测的漂移：从「怎么让 agent 做成事」转向「怎么让它做成事而不扩大爆炸半径」。**sandbox、auto mode、managed agents、containment 四篇构成新主线。

• **上下文是这套方法论里唯一的硬约束。**官方自己把全部 Claude Code 最佳实践归到一句话：「上下文窗口填得很快，而且随着填满性能会下降。」其余技巧都是这一条的推论。

• **同一个「防蒸馏」动机，在阳光下是安全分类器，在二进制里就是后门指控。**2026 年 6–7 月 Claude Code 的隐蔽用户标记事件，是对这家公司透明度叙事最直接的一次实证挑战——差别不在动机，在是否披露。

  怎么读这一章

本章的目标是可操作：每一条实践都尽量给出「适用场景 / 不适用场景」，并标明它是官方写下来的还是编者从证据推出来的。凡是官方给了数字的，数字后面一定带口径与日期——因为这些数字几乎全部是内部评测或自报数据，不是公开基准。另外要提醒一句：Anthropic 的工程文章会被静默更新。《Building effective agents》标注的日期仍是 2024-12-19，但 2026-07-25 抓取到的版本里已经出现了 Claude Agent SDK、Haiku 4.5、Sonnet 4.5——这些在 2024 年都不存在。本章凡引用该文，一律注明抓取时点。

**一条读法建议。**本章把「原则」与「数字」当成两类东西对待：原则（先找最简单的方案、给 agent 可自动验证的检查、把上下文当预算、干活的和打分的分开）在外部研究里基本得到支持，甚至外部批评者反过来在批评「别人没照这些原则做」；数字（提升 90.2%、节省 98.7%、下降 40%、减少 84%）则一律是单公司、单 harness、单任务的内部案例，没有一个被第三方复现过。读到数字时请把它当成「这家公司在它自己的环境里测到了这个」，而不是「你也会得到这个」。

1 · Agent 设计范式

公开的设计原则与它们背后的失败案例；原则如果没有对应的踩坑记录，标注为未验证。

《Building effective agents》（2024-12-19，作者 Erik Schluntz 与 Barry Zhang）是 agent 工程领域被广泛引用的一篇文章（⚠️ 本报告未做引用量或流量的横向比较，因此不写「引用最多」），但它最常被忽略的是开篇那个经验判断：

Over the past year, we’ve worked with dozens of teams building LLM agents across industries. Consistently, the most successful implementations weren’t using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns. — Building effective agents，Anthropic 工程博客 2024-12-19 · anthropic.com/engineering/building-effective-agents ^[1]（抓取日期 2026-07-25）

1.1　workflow 与 agent 的判别式：决策路径由谁决定

这篇文章真正的贡献是给了一个可以在架构评审上当场用的判别式。官方把两者统称为 agentic 系统，但在架构上严格区分：workflow 是「LLM 与工具通过预先定义的代码路径被编排的系统」；agent 是「LLM 动态地指导自己的流程和工具使用、对如何完成任务保持控制权的系统」。 落到工程上就是一句话：决策路径写死在代码里就是 workflow，模型在运行时自己决定就是 agent。

它随后给的建议在一家卖模型 API 的公司口中相当反直觉：

    金句
    

「We recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all. Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.」

出处：Building effective agents ^[1]，2024-12-19 · 官方工程博客（抓取日期 2026-07-25）

同一篇里还有一段对框架的告诫，值得任何在选型的团队读两遍：框架「经常引入额外的抽象层，遮蔽底层的 prompt 和响应，使调试更困难」，并且「会让你在更简单的方案就够用时忍不住增加复杂度」。官方建议是先直接调 LLM API——「很多模式几行代码就能实现」；如果确实要用框架，「务必理解底层代码，对引擎盖下发生了什么的错误假设，是客户出错的常见来源」。

    警示 · 这篇文章自己变了
    

2026-07-25 抓取到的版本里，「框架清单」的第一位已经是 Anthropic 自家的 Claude Agent SDK。从 2024 年的「别急着用框架」到 2026 年的「这是我们的框架」，是同一个 URL 下发生的静默演变。引用这篇文章的任何一句时，都应注明抓取时点；需要 2024 年原版表述的，必须回 Wayback Machine 取。

      **图 1 ·** 四道闸门。**示意图，非精确流程规范**——由编者依据《Building effective agents》的「先找最简单方案」原则、《How we built our multi-agent research system》的 token 成本数据（agent 约 4 倍、多 agent 约 15 倍于对话）与「agent 每一步都要从环境获得 ground truth」这条要求归纳而成。依据：Building effective agents [@src-7d24e5faa2]（2024-12-19）、How we built our multi-agent research system [@src-37ed91c908]（2025-06-13）（访问日期 2026-07-25）
    
  

  

1.2　五种工作流模式：可切换对照

下面这五种模式是原文给的「组合基元」，不是选择题——官方明确写了 “These building blocks aren’t prescriptive.”。切换标签页逐个对照，每个模式都给出了官方原文里的适用条件与例子。

      ① 提示词链PROMPT CHAINING
      ② 路由ROUTING
      ③ 并行化PARALLELIZATION
      ④ 编排者—工作者ORCHESTRATOR
      ⑤ 评估者—优化者EVALUATOR
    
    

      
        

① 提示词链 · Prompt chaining

把任务分解成一串固定步骤，每次调用处理上一次的输出，并可在中间插入程序化的检查点（gate）。核心是用延迟换准确率——让每一次 LLM 调用都变成一个更容易的任务。

          **图 2a ·** 提示词链。原创绘制，结构依据官方文中的 Prompt chaining workflow 图。依据：Building effective agents [@src-7d24e5faa2]（访问日期 2026-07-25）
        
        
          何时用任务能被**干净地拆成固定子任务**；愿意用延迟换准确率。
          何时不用子任务边界模糊、或每次输入需要的步骤数不一样——那属于 ④。
          官方例子先写营销文案再翻译；先写文档大纲、程序化检查大纲是否合规、再按大纲成文。
        
      

      
        

② 路由 · Routing

先对输入做分类，再导向专门的后续处理。价值在于关注点分离：官方原话是「没有这个工作流，为一类输入做优化会伤害另一类输入的表现」。

          **图 2b ·** 路由。**注意**：图中「简单问题走 Haiku 4.5、困难问题走 Sonnet 4.5」是 2026-07-25 抓取版本里的例子，不是 2024 年原版的例子。依据：Building effective agents [@src-7d24e5faa2]（访问日期 2026-07-25）
        
        
          何时用类别边界清晰，**且分类本身能做准**（用 LLM 或传统分类器都行）。
          何时不用分类器本身就不可靠时——错误会被完整地传递到下游，而且更难定位。
          官方例子客服问题分流（通用 / 退款 / 技术支持）；按难度把请求分配到不同价位的模型。
        
      

      
        

③ 并行化 · Parallelization

两个变体：**切分（sectioning）**把任务拆成独立子任务同时跑，**投票（voting）**把同一任务跑多次取多样输出。官方给的原理很实在：「对有多个考量维度的复杂任务，每个考量交给一次独立的 LLM 调用，通常表现更好。」

          **图 2c ·** 并行化。官方特别指出：把「护栏」与「正文回答」拆成两次调用，通常优于让同一次调用同时负责两件事。依据：Building effective agents [@src-7d24e5faa2]（访问日期 2026-07-25）
        
        
          何时用子任务真的互相独立、可以并行提速；或需要**多个视角／多次尝试来提高置信度**。
          何时不用子任务之间有依赖，或需要共享同一份中间状态——强行并行会导致重复劳动。
          官方例子切分：一个实例处理用户查询、另一个筛查不当内容。投票：多个不同 prompt 分别审查同一段代码的漏洞，用不同投票阈值平衡假阳与假阴。
        
      

      
        

④ 编排者—工作者 · Orchestrator-workers

一个中央 LLM 动态拆解任务、委派给 worker、再综合结果。它与并行化的拓扑几乎一样，但官方点明了关键区别：「子任务不是预先定义的，而是由编排者根据具体输入决定的。」

          **图 2d ·** 编排者—工作者。原创绘制。虚线回路是它区别于并行化的地方：拆几个、拆什么，由编排者在运行时决定。依据：Building effective agents [@src-7d24e5faa2]（访问日期 2026-07-25）
        
        
          何时用**你预测不出需要哪些子任务**。官方原话举的就是编码：要改几个文件、每个文件改什么，取决于任务本身。
          何时不用子任务其实是固定的——那用 ③ 更便宜、更可预测，也更好调试。
          官方例子需要跨多文件做复杂改动的编码产品；需要从多个来源收集并分析信息的搜索任务。
        
      

      
        

⑤ 评估者—优化者 · Evaluator-optimizer

一个 LLM 生成，另一个 LLM 评估并给反馈，循环迭代。官方给了两个非常好用的适配信号：其一，「当人把反馈说清楚后，LLM 的响应确实能变好」；其二，「LLM 自己也能提供这种反馈」。两个都成立才值得上这个模式。

          **图 2e ·** 评估者—优化者。底部那句来自 2026-03-24 的《Harness design for long-running application development》，是对 2024 年这个模式的实证补强。依据：Building effective agents [@src-7d24e5faa2]、Harness design for long-running application development [@src-2ef732b764]（访问日期 2026-07-25）
        
        
          何时用有**清晰的评估标准**，且迭代精炼能带来可测量的价值。
          何时不用说不清「什么叫好」的时候。此时评估者只会生成看起来严肃的噪声。
          官方例子文学翻译（译者抓不住的细微处，评估者能给出有用批评）；需要多轮搜索的复杂检索（由评估者决定是否继续搜）。
        
      

    
  

  

1.3　自主 agent：一个循环，加一条硬性要求

官方对自主 agent 的定义朴素到有点扫兴：「它们通常就是 LLM 在一个循环里、基于环境反馈使用工具。」2025-09 的上下文工程一文把这个定义又收紧了一次——「LLM 在一个循环里自主使用工具」。 用概念式写出来是：

    \[ \textsf{agent} \;=\; \textsf{LLM} \;+\; \textsf{tools} \;+\; \textsf{environment feedback loop} \]
    式 7-1 · **概念式，非可计算模型**——等号在这里表示「由这三部分构成」，不表示数值相等，三项也没有量纲。**假设与失效边界**：它假定三项都真实存在且可观测；一旦第三项（环境反馈）退化成模型的自我评估，这个式子就不再刻画一个 agent，而是刻画一个开环的生成器——本节前面那条硬性要求（每一步都要从环境拿到 ground truth）正是为了守住这一项。
  

  
    关键洞察
    

官方对第三项写了一条硬性要求：「关键在于 agent 每一步都要从环境获得 ground truth（如工具调用结果或代码执行）来评估自己的进展。」这条要求是判断一个场景能不能上 agent 的第一性判据——如果你的任务里没有任何能自动判对错的东西，那么 agent 唯一可用的信号就是「看起来做完了」，而你就变成了那个验证循环。

1.4　被严重低估的附录：工具设计（ACI）

《Building effective agents》最有操作价值的部分在附录，而不是那五张图。它提出了一个到 2026 年已被广泛接受的概念——ACI（agent-computer interface，智能体—计算机界面），并给了一条经验法则：

One rule of thumb is to think about how much effort goes into human-computer interfaces (HCI), and plan to invest just as much effort in creating good agent-computer interfaces (ACI). — Building effective agents，附录 2 2024-12-19 · 官方工程博客 ^[1]（抓取日期 2026-07-25）

支撑这条法则的是一段罕见的、具体到能复现的一手证据：「在为 SWE-bench 构建 agent 时，我们花在优化工具上的时间比花在整体 prompt 上的还多。举例：我们发现在 agent 离开根目录之后，使用相对路径的工具会让模型出错。修复办法是把工具改成始终要求绝对路径——然后我们发现模型用得完美无缺。」

      工具设计动作官方原话的要点怎么落地| 工具设计动作 | 官方原话的要点 | 怎么落地 |

      
        站到模型的位置上「凭描述和参数，用法是否一目了然？如果你都要想一会儿，模型多半也要。」工具定义里带**用法示例、边界情况、输入格式要求，以及与相邻工具的明确分界**。| 站到模型的位置上 | 「凭描述和参数，用法是否一目了然？如果你都要想一会儿，模型多半也要。」 | 工具定义里带用法示例、边界情况、输入格式要求，以及与相邻工具的明确分界。 |

        把描述当 docstring 写「就像给团队里的初级开发者写一份出色的 docstring。」相似工具多时尤其重要——改参数名比改 prompt 有效。| 把描述当 docstring 写 | 「就像给团队里的初级开发者写一份出色的 docstring。」 | 相似工具多时尤其重要——改参数名比改 prompt 有效。 |

        实测模型怎么用「跑很多示例输入，看模型会犯什么错，然后迭代。」把失败样本收集起来，这就是下一节工具优化循环的输入。| 实测模型怎么用 | 「跑很多示例输入，看模型会犯什么错，然后迭代。」 | 把失败样本收集起来，这就是下一节工具优化循环的输入。 |

        给工具做**防呆**（poka-yoke）「改参数，让犯错更难。」绝对路径取代相对路径，是官方给的样板案例。| 给工具做防呆（poka-yoke） | 「改参数，让犯错更难。」 | 绝对路径取代相对路径，是官方给的样板案例。 |

        选对输出格式给模型足够 token 去思考；格式贴近互联网上自然出现的样子；**不要有格式化开销**。不要求它精确数几千行代码的行号，不要求它给写出的代码做字符串转义。| 选对输出格式 | 给模型足够 token 去思考；格式贴近互联网上自然出现的样子；不要有格式化开销。 | 不要求它精确数几千行代码的行号，不要求它给写出的代码做字符串转义。 |

      
      表 1 · ACI 的五条实操。全部为《Building effective agents》附录 2 原文要点的中文归纳（访问日期 2026-07-25）。
    
  

  

2025-09-11 的《Writing effective tools for agents — with agents》把这个附录展开成了一整篇。它给出的概念转变很有意思：工具是一种新型软件契约——传统软件是「确定性系统之间的契约」，而工具是「确定性系统与非确定性 agent 之间的契约」。 更实用的是它给的那条流水线，可以原样照抄：

    失效边界
    

上面这些原则的适用前提是你的工具面向的是通用模型。官方在评测那一节明确警告：不要用过于简化的沙箱环境验证工具——「强评测任务可能需要多次工具调用，甚至几十次」。用玩具任务测出来的「工具很好用」，在真实任务里通常不成立。

2 · 上下文工程

上下文的组织方式与取舍依据，给出可操作的判断标准而非口号。

《Effective context engineering for AI agents》（2025-09-29）把这件事从「玄学」抬成了「有架构解释的工程约束」。它先给了一个定义上的切分：prompt engineering 是「写好并组织 LLM 指令的方法」，而 context engineering 是「在推理过程中策展并维护那组最优 token 的策略集合，包括所有可能落进上下文、却不来自 prompt 的信息」。区别在于：写 prompt 是一次性的离散任务，策展是每一次决定「传什么给模型」时都会发生一次。

2.1　注意力预算：官方为「窗口更长不等于问题解决」给出的直觉解释

Like humans, who have limited working memory capacity, LLMs have an “attention budget” that they draw on when parsing large volumes of context. Every new token introduced depletes this budget by some amount. — Effective context engineering for AI agents 2025-09-29 · 官方工程博客 ^[2]（访问日期 2026-07-25）

这篇文章最有价值的是它给这个直觉配了一套架构层面的解释。官方给出的四条：① Transformer 让每个 token 能 attend 到所有其他 token，n 个 token 就有 n² 个成对关系，上下文变长时捕捉这些关系的能力被摊薄；② 训练数据里短序列远比长序列常见，模型对「跨全上下文的依赖」经验更少；③ 位置编码插值这类技术能拉长序列，但对 token 位置的理解会退化；④ 因此表现出的是「性能梯度而非硬悬崖」。

    关键洞察
    

「上下文窗口」是一个容量数字（200K、1M），「注意力预算」是一个会被稀释的质量指标。理解这个差别，就不会再问「既然有 100 万 token 窗口，为什么还要压缩」。这个心智模型本身很好用，它把一个模糊的抱怨变成了可以在架构评审上讨论的东西。

    失效边界 · 别把这四条读成「已被证明的因果机制」
    

上面四条是官方给出的直觉解释，不是一份实验证明。「成对关系数随 n² 增长」描述的是计算结构，它并不直接推出「注意力质量必然随 token 数单调下降」——注意力机制的具体实现、训练时的长序列配比、检索策略与位置编码方法都会改变这条曲线的形状，而这些都是可以被工程改进的变量。因此本报告不写「n² 是架构必然，所以等更长的窗口不是解法」这种强推论。

可以安全采用的版本是弱得多、但也可靠得多的一条：截至 2026-07，在公开可得的模型上，上下文变长时长程回忆质量确实会下降，因此把上下文当作有成本的资源来经营，在当前是划算的。这是一条关于当下的工程判断，不是一条关于架构的定理——如果某一代模型把长程退化压到可以忽略，本章第 2 节的大部分技巧就应该被拆掉重估。

由此得到的指导原则只有一句：好的上下文工程就是「找到能最大化目标结果概率的、尽可能小的高信噪比 token 集合」。官方还专门澄清了一个常见误解——「minimal 不一定意味着 short」。要的是信噪比高，不是字数少。

      **图 4 ·** 上半部分为官方所称的 "right altitude"（正确高度）；下半部分三张卡片的**选型标准全部为官方原文**：压缩「maintains conversational flow for tasks requiring extensive back-and-forth」、笔记「excels for iterative development with clear milestones」、多 agent「handle complex research and analysis where parallel exploration pays dividends」。子 agent 回传摘要的量级（约 1,000–2,000 token）亦为官方数字。依据：Anthropic, Effective context engineering for AI agents [@src-42516bb950], 2025-09-29（访问日期 2026-07-25）
    
  

  

2.2　Claude Code 为什么选择即时检索；以及何时不应照搬

官方主张的是 just-in-time（即时）检索：不预处理所有相关数据，而是「维护轻量标识符（文件路径、存好的查询、网页链接），在运行时用工具动态把数据装进上下文」。Claude Code 就是这么干的——不建索引、不做向量检索：

    金句
    

「Claude Code is an agent that employs this hybrid model: CLAUDE.md files are naively dropped into context up front, while primitives like glob and grep allow it to navigate its environment and retrieve files just-in-time, effectively bypassing the issues of stale indexing and complex syntax trees.」

出处：Effective context engineering for AI agents ^[2]，2025-09-29（访问日期 2026-07-25）

这一节里最便宜、也最容易被忽略的一条建议是元数据即信号：「对一个在文件系统里操作的 agent 来说，tests 文件夹里一个叫 test_utils.py 的文件，和 src/core_logic/ 下同名文件，暗示的用途是不同的。文件夹层级、命名约定、时间戳都提供重要信号。」

    我的看法
    

这条建议的性价比高得离谱，但几乎没人执行。花一天整理仓库目录结构和命名规范，很可能比调一周 prompt 更有效——因为前者是持久的、对所有 agent 生效的免费上下文，后者是一次性的、随模型换代就作废的。

    失效边界 · 「即时检索更好」不是通则，它是对某一类语料的选择
    

官方自己就没有把这条写成通则，是转述容易把它读成通则。同一篇文章明确写了即时检索的代价：「运行时探索比取预计算数据更慢」，而且「没有恰当引导时，agent 会因误用工具、追死胡同或识别不出关键信息而浪费上下文」；并且直接点名——对法律、金融这类内容变动不频繁的场景，官方建议用混合策略。

把选择条件写清楚，比记住结论有用：语料变化越快、越难维持索引新鲜度，即时检索越占优（代码库是极端情形——每次 commit 都会让索引过期）；语料越稳定、单次检索代价越高、对召回完备性要求越强，预建索引越占优（法条、财报、产品手册）。Claude Code 选 JIT，是因为它面对的恰好是变化最快的那一类语料，而不是因为 JIT 在原理上更优。

2.3　多 agent 系统：三个数字决定它值不值得（全部为内部案例）

《How we built our multi-agent research system》（2025-06-13）是这套方法论里最「脏活累活」也最有信息量的一篇。架构是标准的编排者—工作者：LeadResearcher（Claude Opus 4）先把计划存进 Memory 以防上下文被截断，再创建若干带具体任务的 Subagent（Claude Sonnet 4）并行检索，最后交给 CitationAgent 逐条定位引用位置。

    90.2%多 agent 相对单 agent 的提升**Anthropic 内部案例**：内部研究评测，非公开基准；对照组是单 agent Claude Opus 4；**无第三方复现**
    80%性能方差中由 token 用量解释的部分**Anthropic 内部案例**：在 BrowseComp 上三因素合计解释 95% 方差；另两个是工具调用次数与模型选择
    15×多 agent 相对聊天的 token 消耗**Anthropic 内部案例**：同口径下单 agent 约 4×。官方原话：需要「任务价值高到足以支付这份性能提升」
  
  

三个数字均为 Anthropic 内部案例研究，单公司、单 harness、单任务分布，截至 2026-07-25 未见任何独立机构复现。　⚠️ 「90.2%」是相对提升，不是绝对准确率；它对 benchmark 选择高度敏感——这正是第 5 节外部对照要处理的问题。

    警示 · 这三个数字必须一起读
    

「token 用量本身就解释 80% 的性能方差」这一条，意味着很多所谓的「架构优化」实际上只是「花了更多 token」的代理变量。因此：**做 agent 架构对比实验时必须控制 token 预算，否则结论无效。**而 15 倍这个数字则把多 agent 从一个技术选择变成了一个明确的经济决策。

    证伪
    

2025 年 6 月，Cognition 发《不要造多智能体》，Anthropic 隔天发《我们如何构建多智能体研究系统》——这是一场关于 agent 架构的路线之争。

两篇正文其实一致，「对撞」是标题制造的。Cognition 点名批评的是 OpenAI 的 swarm 与微软的 autogen，并且明确表扬了 Claude Code「刻意保持简单」的做法；而 Anthropic 在自己那篇里白纸黑字写着——**「大多数编码任务里真正可并行的部分比研究任务少，而且 LLM agent 目前还不擅长实时协调与委派。」**分歧只存在于「研究」这一种工作负载上，其余部分是共识。

误差来源：两篇发布时间相隔一天，标题看起来针锋相对。任何把这两篇写成「路线之争」的转述，都没有读完正文。（2025-06-12 / 2025-06-13）

同样重要的是官方自己写的不适用条件：「有些领域要求所有 agent 共享同一上下文、或 agent 之间依赖很多，今天并不适合多 agent 系统。例如，大多数编码任务里真正可并行的任务比研究少，而且 LLM agent 目前还不擅长实时协调和委派给其他 agent。」 这句话与 Claude Code 后来大力做 subagent 并不矛盾——Claude Code 的 subagent 主要用于只读调研（为了隔离上下文），而不是并行写代码。

这篇里有八条 prompt 原则，其中三条可以直接抄进工程规范：

• **让投入匹配问题复杂度，并把规则写进 prompt。**官方给的档位是：简单事实查找 = 1 个 agent、3–10 次工具调用；直接比较 = 2–4 个 subagent、每个 10–15 次调用；复杂研究 = 10 个以上 subagent 且职责清晰划分。为什么：早期版本最常见的失败模式是「在简单问题上过度投入」。

• 教编排者怎么委派——每个子任务必须带目标、输出格式、信息源指引与任务边界。官方给的反面案例极具体：只说「research the semiconductor shortage」，结果一个子 agent 去查 2021 年汽车芯片危机，另外两个重复调查 2025 年供应链。为什么：模糊的委派不会让子 agent 更灵活，只会让它们撞车。

• **让模型自己改进工具描述。**官方造了一个工具测试 agent：给它一个有缺陷的 MCP 工具，它反复试用几十次后重写描述，使后续 agent 的任务完成时间下降 40%（Anthropic 内部案例，无外部复现）。为什么值得试：这条的成本极低——给它一个工具加一批失败样本就行，即使收益远低于 40%，投入产出比仍然成立。不要指望复现 40% 这个数字本身。

工程侧还有两条很少被转述、但一旦踩到就很痛的经验：其一，彩虹部署（rainbow deployment）——agent 系统「几乎持续运行」，部署时 agent 可能正处在流程的任何位置，所以必须「同时保持新旧两个版本运行、把流量逐步迁移」，而不是滚动重启；其二，同步执行是当前架构的瓶颈——lead agent 等所有 subagent 返回才继续，「整个系统可能因为等一个 subagent 而阻塞」，官方明说异步化会带来结果协调、状态一致性与错误传播的新难题。

3 · 工具与协议生态：MCP

开放协议的设计取舍、采纳情况，以及采纳数据的查询日期。

MCP（模型上下文协议，Model Context Protocol）于 2024-11-25 开源，由 David Soria Parra 与 Justin Spahr-Summers 在 Anthropic 内部创造（官方公告逐字点名）。 它要解决的问题在公告里写得很清楚：「每接一个新数据源都要写一套定制实现，让真正互联的系统难以规模化」——也就是后来被反复引用的 N×M 到 N+M 的转换。

    口径说明 · 起源不是战略布局
    

时任 CPO 的 Mike Krieger 在一年后的官方口径是：「MCP started as an internal project to solve a problem our own teams were facing. When we open sourced it in November 2024, we hoped other developers would find it as useful as we did.」 这与 Claude Code 的起源高度同构：都是内部工程师为解决自己的痛点做的东西，先在内部疯传，再开源或产品化。（⚠️ 提醒：Krieger 已于 2026-01 转任 Anthropic Labs 负责人，不再是 CPO，引用其头衔时须按发言时点标注。）

3.1　架构与原语：它真正的设计贡献是「谁有权决定这段内容进上下文」

      **图 6 ·** MCP 三层架构。**关键设计约束**：一个 client 对应且只对应一个 server，host 通过持有 N 个 client 来连 N 个 server——这让**权限边界与故障隔离都落在 host 层**。依据：MCP 官方文档 · Architecture [@src-ab570992ab] 与 Introducing the Model Context Protocol [@src-3a99f53535]（2024-11-25），抓取日期 2026-07-25
    
  

  

三个 server 侧原语按控制方划分，这是 MCP 最被低估的设计——它把「谁有权决定这段内容进上下文」显式建模了：

      原语控制方语义类比| 原语 | 控制方 | 语义 | 类比 |

      
        **Tools**模型控制模型可以主动调用的函数，有副作用POST 接口| Tools | 模型控制 | 模型可以主动调用的函数，有副作用 | POST 接口 |

        **Resources**应用控制只读上下文数据，由 host 决定何时注入GET 接口 / 文件| Resources | 应用控制 | 只读上下文数据，由 host 决定何时注入 | GET 接口 / 文件 |

        **Prompts**用户控制用户显式触发的模板化提示词斜杠命令 / 快捷指令| Prompts | 用户控制 | 用户显式触发的模板化提示词 | 斜杠命令 / 快捷指令 |

      
      表 2 · MCP 的三个 server 侧原语。Client 侧原语中，Sampling 与 Roots 为初版即有，**Elicitation 于 2025-06-18 引入**，实验性的 **Tasks 于 2025-11-25 引入**（SEP-1686，长时任务的持久句柄）。
    
  

  

3.2　它是怎么变成事实标准的

      2024-11-25研究
      

MCP 开源发布，规范版本 2024-11-05

三大 server 原语 + Sampling + Roots；JSON-RPC 2.0；stdio 与 HTTP+SSE 两种传输。

出处：Introducing the Model Context Protocol ^[3]（访问日期 2026-07-25）

      2025-03-26商业
      

规范大改：Streamable HTTP 与 OAuth；同期竞争对手开始接入

单端点取代双端点、支持断线恢复；这一版让 MCP 能接远程 SaaS，是它走出本地开发环境的分水岭。2025 年内 OpenAI、Google DeepMind、微软先后宣布支持——这是一个由单一公司发起、却被竞争对手采纳的协议，在近年极为少见。

出处：MCP Versioning ^[4]（访问日期 2026-07-25）。⚠️ 各家宣布支持的精确日期请以各自官方公告为准，本报告不据二手汇编给出逐个日期。

      2025-12-09治理
      

捐给 Agentic AI Foundation，Anthropic 放弃协议所有权

由 Anthropic、Block、OpenAI 共同发起，受赠方是 Linux Foundation 旗下新成立的 Agentic AI Foundation。

出处：Linux Foundation 新闻稿 ^[5]，2025-12-09（访问日期 2026-07-25）。⚠️ 常见错误：写成「2025-11 捐给 Linux Foundation」——日期与受赠方主体都不对。

      2026-01-26研究
      

MCP Apps 上线

⚠️ 不是 2025-10。值得注意的细节：该 SEP 的发起人来自 MCP-UI 社区，不是 Anthropic 员工——这正是「放弃控制权」的直接体现。

出处：MCP 官方博客与规范提案记录（访问日期 2026-07-25）

      2026-07-28研究
      

无状态化重构：截至本报告基准日仍是未来版本

移除 initialize 握手与协议级会话，引入多轮往返请求（MRTR）。官方称这是「自发布以来最大一次修订」，动机是让 MCP server 变成可以用普通轮询负载均衡扩容的「普通 HTTP 服务」。

出处：MCP Blog · Beta SDKs for the 2026-07-28 Spec Release Candidate ^[6]，2026-06-29（访问日期 2026-07-25）。⚠️ 本报告基准日为 2026-07-25，该规范当时仍为 RC，不得写成「已正式发布」。

放弃所有权换来了什么

• 协议被竞争对手采纳，成为跨厂商标准而非厂商方言。

• 规范演进由社区提案推动（MCP Apps 的发起人就不在 Anthropic）。

• 与它在政策上主张「行业不能自己管自己」是同一套逻辑：在你有优势的时候把规则交出去，规则才有约束力。

代价是什么

• 演进方向不再由 Anthropic 单独决定——2026-07-28 的无状态化重构就是一次由生态托管需求驱动的大改。

• 安全治理责任分散：协议层至今没有工具定义的版本追踪与变更通知机制。

• 它自己随后又用《Code execution with MCP》说「别把工具定义直接塞进上下文了」——协议层与呈现层被解耦。

    对辩 · 经验层 —— MCP 的成功该归因给「放弃所有权」吗，「事实标准」又有多少水分
    
      
        最强版本
        

MCP 在技术上并不难——JSON-RPC 2.0 加三个原语，任何一家公司都设计得出来。它之所以被 OpenAI、Google、微软逐个接入，是因为 Anthropic 在自己占优的时候主动把所有权交了出去：2025-12-09 与 Block、OpenAI 共同捐给新成立的 Agentic AI Foundation。协议的价值不来自设计质量，来自采纳；而采纳的最大障碍是所有权。

        最强反方
        

这是一个无对照组的单案例归因。同一段采纳史至少还有四个竞争解释，且都不需要「放弃所有权」这一条：① 时机——2024 年底整个生态正好缺一个工具接入标准，先到者通吃；② 分发量——Claude 当时已是编码场景的主力模型，接 MCP 等于接 Claude；③ 协议足够简单——照 JSON-RPC 写一个 server 是半天的活，迁移成本近乎为零；④ 关键客户端先支持——VS Code 生态与 OpenAI 的接入本身就会把标准推成默认。捐赠发生在 2025-12，而主要竞争对手的接入发生在 2025 年内——归因的时间顺序是反的。

        可验证证据
        

① 时序可核对：MCP 开源 2024-11-25，OpenAI / Google / 微软的支持均发生在 2025 年内，捐给 AAIF 是 2025-12-09。采纳在前，让渡所有权在后，所以所有权至多解释「采纳之后为什么没有分叉」，解释不了「为什么一开始被采纳」。（时间线可由三方各自的公告独立核对）

② 「事实标准」这个说法目前缺一个分母。本报告没有找到覆盖全行业的 MCP 部署率统计；能查到的是「哪些厂商宣布支持」，而不是「多少生产系统真的在用、用到什么深度」。宣布支持与深度采用之间的差距，在协议史上从来都很大。

③ 协议复杂度的反向证据来自 Anthropic 自己：2025-11 的《Code execution with MCP》实质上承认，把工具定义直接暴露给模型这条原始路径在规模上不可用（几十万 token 的开销），要改成「让模型写代码去调」。一个需要在一年内被自己绕开的呈现层，很难同时被称作成熟标准。

        Anthropic 回应
        

未见针对「归因」这一问题的公开回应——Anthropic 从未公开声称「MCP 因为我们放弃所有权才成功」，这个因果链条主要来自外部观察者与本报告此前的表述。官方给出的说法要弱得多，也更可辩护：Mike Krieger 称「MCP 起初只是一个内部项目，用来解决我们自己团队遇到的问题。2024 年 11 月开源时，我们只是希望别的开发者也觉得它像我们一样有用」。　在协议复杂度上，官方以行动作了回应：推出 Tool Search Tool、Programmatic Tool Calling 与 2026-07-28 的无状态化重构。

        Reviewer 裁决
        

部分削弱。「MCP 被广泛采纳」是事实；「因为放弃所有权所以被采纳」降级为若干竞争解释之一，且不是时间上最合理的那一个。本报告因此把这条从「结论」改写为「一个值得注意但未被检验的假说」，并把「事实标准」一律替换为可核对的表述——「被主要竞争对手逐个宣布支持」。

什么新证据会改变判断：① 一份覆盖生产系统的 MCP 采纳率与使用深度统计（有分母）；② 任一竞争对手公开说明其接入决策与治理归属的关系；③ 出现一个技术上相当、但保留厂商所有权的对手协议，并且明显采纳更慢——那才是这条归因需要的对照组。

3.3　安全：这一节是最佳实践的反面教材

MCP 的安全问题是结构性的，不是实现 bug。最有用的一个可操作框架是 Simon Willison 提出的 lethal trifecta（致命三重奏）：当一个 agent 同时具备①访问私有数据、②接触不可信内容、③具备对外通信能力时，任何一个输入通道上的一次 prompt injection 都能串成完整的数据外泄。而这正是大多数生产 agent 的默认配置。

      攻击类型机制为什么传统扫描抓不到| 攻击类型 | 机制 | 为什么传统扫描抓不到 |

      
        间接 prompt injection恶意指令藏在正常数据里（邮件、网页、issue、README），被工具读进上下文后当指令执行数据本身完全合法| 间接 prompt injection | 恶意指令藏在正常数据里（邮件、网页、issue、README），被工具读进上下文后当指令执行 | 数据本身完全合法 |

        工具投毒（tool poisoning）恶意指令嵌在**工具描述元数据**里，模型把它当可信事实元数据不是可执行代码| 工具投毒（tool poisoning） | 恶意指令嵌在工具描述元数据里，模型把它当可信事实 | 元数据不是可执行代码 |

        **拉地毯（rug pull）**首次注册时描述干净、通过审核，安装后**变更定义与能力****MCP 至今没有工具定义的版本追踪、变更通知与能力扩张检测**| 拉地毯（rug pull） | 首次注册时描述干净、通过审核，安装后变更定义与能力 | MCP 至今没有工具定义的版本追踪、变更通知与能力扩张检测 |

        混淆代理 / 跨 server 遮蔽agent 持合法凭证被诱导代办；或多 server 之间工具名互相遮蔽每一步单看都是授权操作| 混淆代理 / 跨 server 遮蔽 | agent 持合法凭证被诱导代办；或多 server 之间工具名互相遮蔽 | 每一步单看都是授权操作 |

        影子 server员工私自安装 MCP server，IT 无感知不在资产清单里| 影子 server | 员工私自安装 MCP server，IT 无感知 | 不在资产清单里 |

      
      表 3 · MCP 的结构性威胁模型。已公开的最严重单点漏洞是 **CVE-2025-6514**（`mcp-remote` 远程代码执行，CVSS 9.6），由 JFrog 安全研究团队于 **2025-07-09** 披露，影响版本 0.0.5–0.1.15，0.1.16 修复。（厂商披露）
    
  

  
    警示 · 一条推翻直觉的实证
    

MCPTox 基准（2025-08，45 个真实 MCP server、353 个真实工具、1,312 个恶意用例、20 个 agent）报告的平均攻击成功率是 36.5%，其核心发现是：「能力越强的模型越容易中招，因为它们更忠实地执行指令。」（⚠️ 本报告未取得原始论文，仅见第三方转述，数字与实验设置引用前须回原文核对。） 这条与 Anthropic 自己在 2026-05 的观察形成呼应但机制不同——一个是被动服从，一个是主动绕路。两条合起来说明同一件事：模型变强不会自动带来安全。

Anthropic 自己在《How we contain Claude across products》（2026-05-25）里把 MCP 明确列为「外部内容」这一防御层的主要风险源，并给了一句很好用的判据：

MCP servers, third-party plugins, and web search tools all feed content into the agent’s context from sources you don’t control. An audited connector isn’t the same as audited data — a GitHub connector, for instance, can load a poisoned README straight into the model’s context despite passing malware checks. — How we contain Claude across products 2026-05-25 · 官方工程博客 ^[7]（访问日期 2026-07-25）

    失效边界 · 代价栏：MCP 换来的标准化是有价格的
    

在 Scalekit 的 75 次基准（Claude Sonnet 4、GitHub MCP server 暴露 43 个工具定义、同任务同提示词）实验设定下：问「这个仓库用什么语言」，CLI 花 1,365 个 token，MCP 花 44,026 个——差距几乎全部来自被注入每一轮对话的 schema，而 agent 实际只用到其中一两个。**⚠️ 该实验给出的区间是 4–32 倍，32 倍是最简任务这一极端点，不得只取上限。**可靠性一侧同样有差：CLI 25/25，MCP 18/25（72%），Scalekit 自陈多数失败是远端连接超时而非逻辑错误。

这笔账 Anthropic 自己也认了，而且是本节分量最重的一条证据——它的官方文档写着：「一个典型的多 server 配置（GitHub、Slack、Sentry、Grafana、Splunk）可以在 Claude 开始干任何活之前就消耗约 5.5 万 token 的定义」；《Code execution with MCP》开篇则直接承认「一旦连接的 server 太多，工具定义和结果会消耗过多 token，降低 agent 效率」。

两条使用纪律：① 引用 32 倍必须带实验设定与 4–32 倍的区间；② 不要写「7 倍」这个缓解后的具体数字——它是把 Scalekit 的 44,026 与 Anthropic 的「Tool Search 减 85%」跨口径相乘得到的，方向正确但精度不可靠。可以写的是：差距被压缩到个位数倍，但没有消失。

    口径说明 · 反方在这里也犯了本报告批评过的毛病
    

公平起见，这条反方自身有两个明显弱点。其一，CLI 一侧的成本被系统性低估：CLI 方案要求 agent 预先知道每个工具的用法（依赖预训练熟悉度），且不提供多租户身份、按用户授权、集中式 OAuth 与可审计遥测。把两者放在同一根 token 轴上比，本身就是范畴错误——一句中文技术评论把这点说得比多数英文批评清楚：「在开发者的命令行环境里，CLI 是最好的答案；在需要认证合规的企业系统里，MCP 才是。」其二，大量二次传播只取 32 倍这个上限，而 Scalekit 自己明确写了网关做 schema 过滤可降约 90%、逼近 CLI。「区间取上限」正是本报告在别处批评的做法，反方自己也犯。

    对辩 · 经验层 —— MCP 的 STDIO 传输能在校验前执行命令：这是漏洞，还是外部性归属问题
    
      
        最强版本
        

Anthropic 的立场是：这是 预期行为（expected）。STDIO 传输的设计前提就是「本地子进程、由 host 决定信任」，把命令校验放进传输层，要么破坏这个传输方式本身，要么只是把 payload 下移一层——真正的信任边界应该由 host 应用来划，而 MCP 已经把权限与故障隔离都设计在了 host 层。

        最强反方
        

OX Security（2026-04）披露：MCP 的 STDIO 传输会在校验之前就执行命令，波及全部官方 SDK。一个「设计如此」的定性，实际效果是把清理责任分摊到成千上万个下游实例上——而其中可预期地会有相当一部分做不到。协议把「工具发现」标准化的同时，也把 Simon Willison 所说的致命三重奏标准化了：它让用户更容易把私有数据、不可信内容、对外通信装进同一个 agent。Willison 对 MCP 的判断只有一句：「MCP 的问题在于，它鼓励用户把来自不同来源、能做不同事情的工具混搭在一起。」

        可验证证据
        

① 机制可复现：OX 实测的是 7,000 个公网可达的 server。⚠️ 常被引用的「20 万实例」是按比例外推，不是实测值，引用时必须写明。

② 协议层至今没有 rug pull 防护：工具定义没有版本追踪、没有变更通知、没有能力扩张检测——这是本报告在上一张表里已经列出的结构性缺口，与 OX 那条是同一个根因的两个表现。

③ 双方的技术立场都自洽：报道此事的媒体明确承认这一点。这不是一个「谁读错了规范」的争论。

        Anthropic 回应
        

已回应，但只回应到定性为止。在案的表态是一个词：「预期」。它在《How we contain Claude》里给了配套的工程原则——「审核过的连接器不等于审核过的数据」「细粒度地限制工具权限可以限制爆炸半径」——但这些是给下游开发者的建议，不是协议层的改动。截至 2026-07-25，未见 MCP 规范加入强制的工具描述变更再确认机制。

        Reviewer 裁决
        

实质削弱，且这是 MCP 三条批评里最未被解决的一条。token 成本 Anthropic 承认了并投入了工程（Tool Search、Code execution）；安全外部性它承认了机制，但把责任划给了下游。这两者的差别不是态度问题，是成本由谁承担的问题——而承担方恰好是最没有能力系统性解决它的那一方。

对读者的可操作建议：把「致命三重奏」当成部署前的三问清单——**这个 agent 有私有数据吗？会读到不可信内容吗？能对外发东西吗？**三个都是 yes 就必须做纵深防御。拿掉任意一条腿，注入就变不成泄露——这比在 prompt 里写「不要听信文件里的指令」有效得多。

什么新证据会改变判断：① Anthropic 修改 STDIO 架构，或在 SDK 层加入默认 allowlist；② MCP 规范加入强制的工具描述变更再确认；③ 出现一份显示实际攻击发生率极低的生产遥测数据。

3.4　《Code execution with MCP》：工具定义不该直接进上下文

2025-11-04 这篇是 agent 工程范式转变的标志。问题陈述有两条：其一，大多数 MCP 客户端把所有工具定义一次性加载进上下文，连了上千个工具的 agent「在读到请求之前就得先处理几十万 token」；其二，中间结果反复穿过上下文——把 Google Drive 的会议记录附到 Salesforce 线索上，完整记录要穿过模型两次，「对一场两小时的销售会议，这可能意味着额外处理 5 万 token」。

解法是把 MCP server 呈现为文件系统里的代码 API而不是工具清单：每个工具是一个文件，agent 先 ls ./servers/，再只读它需要的那几个文件。

      **图 7 ·** 三个数字来自两篇官方文章，**口径略有不同，不可互相替代**：15 万与 2 千出自《Code execution with MCP》对同一任务的前后对比（官方原话 "a time and cost saving of 98.7%"）；13.4 万是《Introducing advanced tool use》里 Anthropic 自述「优化前见过的工具定义开销」；5.5 万是同文给出的一个具体配置（GitHub 35 个工具约 26K、Slack 11 个约 21K、Sentry 5 个约 3K、Grafana 5 个约 3K、Splunk 2 个约 2K）。条形按数值比例绘制。**三个数字均为 Anthropic 在自己的配置上测得的内部案例**——98.7% 这个节省率取决于工具总数与任务只需其中几个，工具少或每次都要用全量时收益会大幅缩水。依据：Anthropic, Code execution with MCP [@src-4dd2373a00], 2025-11-04；Introducing advanced tool use on the Claude Developer Platform [@src-fe2899cf9c], 2025-11-24（访问日期 2026-07-25）
    
  

  

除了省 token，这篇还给了三条容易被漏掉的收益：更强的控制流（循环、条件、错误处理用代码写，「不必等模型去求值一个 if 语句」）；隐私保护——中间结果默认留在执行环境，更进一步，harness 可以自动把 PII 令牌化，让「真实邮箱从 Google Sheets 流到 Salesforce，全程不经过模型」；状态持久化——agent 可以把自己写的代码存成可复用函数，加一个 SKILL.md 就变成结构化 skill。

    失效边界 · 官方自己写的代价
    

「运行 agent 生成的代码需要一个带适当沙箱、资源限制和监控的安全执行环境。这些基础设施要求带来了直接工具调用所没有的运维开销和安全考量。」 换句话说：98.7% 的节省不是免费的，它把复杂度从上下文窗口挪到了你的基础设施上。工具数量少于十几个的场景，直接调用仍然是对的。

另外，《Introducing advanced tool use》（2025-11-24）指出 token 并不是唯一问题：「最常见的失败是选错工具和参数错误，尤其当工具名相似时」，例如 notification-send-user 与 notification-send-channel。它给出的三个 beta 能力（Tool Search Tool、Programmatic Tool Calling、Tool Use Examples）正是分别针对「装不下」「结果太大」「schema 说不清用法」三个问题。

3.5　Agent Skills：把「上下文是有限资源」产品化

Agent Skills 于 2025-10-16 发布，定义是「有组织的指令、脚本和资源文件夹，agent 可以动态发现并加载它们」。官方给的类比很到位：「给 agent 做一个 skill，就像给新员工准备一份入职指南。」

      级别内容何时加载上下文成本| 级别 | 内容 | 何时加载 | 上下文成本 |

      
        一级YAML frontmatter 里的 `name` 与 `description`**启动时**预加载进系统提示词每个 skill 约一行| 一级 | YAML frontmatter 里的 name 与 description | 启动时预加载进系统提示词 | 每个 skill 约一行 |

        二级`SKILL.md` 正文Claude 判断该 skill 与当前任务相关时，用 bash 读入一篇 markdown| 二级 | SKILL.md 正文 | Claude 判断该 skill 与当前任务相关时，用 bash 读入 | 一篇 markdown |

        三级及以上捆绑的其他文件（`reference.md`、表单说明、脚本）Claude 按需自行导航、发现、读取只读它真正需要的那份| 三级及以上 | 捆绑的其他文件（reference.md、表单说明、脚本） | Claude 按需自行导航、发现、读取 | 只读它真正需要的那份 |

      
      表 4 · Agent Skills 的渐进式披露。**最被低估的一个细节**：当指令提到可执行脚本时，「Claude 通过 bash 运行它们，**只接收输出——脚本代码本身从不进入上下文**」。这意味着你可以在 skill 里塞一个两千行的脚本而上下文成本近似为零。
    
  

  

2025-12-18 官方进一步宣布「已把 Agent Skills 作为开放标准发布，以实现跨平台可移植性」，立场与 MCP 一致：「同一个 skill，无论你用 Claude 还是其他 AI 平台，都应该能用。」

    关键洞察 · MCP 与 Skills 的分工判据
    

到 2026 年这个分层已经是共识，落到选型上只有一句话：先看你的问题是「接不上」还是「不会做」。接不上用 MCP，不会做用 Skill。 两者的上下文成本差着数量级——装 100 个 skill 的常驻成本约等于 100 行描述，而工具定义动辄几万 token。官方自己也在 skill 的安全一节里主动写了风险：恶意 skill「可能在使用环境中引入漏洞，或指使 Claude 外泄数据、执行非预期动作」，建议只从可信来源安装，并对不太可信的来源逐文件审计，特别注意代码依赖与捆绑资源。

4 · Claude Code：从内部工具到第二条收入曲线

这一节的判据同上：只收录那些不依赖 Anthropic 内部条件就能照做的做法；纯产品功能介绍不计入。

2025-02-24 随 Claude 3.7 Sonnet 以 research preview 形式发布，2025-05-22 随 Claude 4 正式 GA。 它的设计哲学可以拆成一条推论链，而这条链的起点是一个关于模型的判断，不是关于产品的判断。

4.1　六条设计哲学，与它们共同的那个前提

不是产品，是 Unix 工具

装好之后在任何终端里 claude 就能跑，不挑 iTerm2 / WSL / SSH / tmux / IDE 内置终端。文本 I/O 是核心接口：记忆是一个自动加载的 markdown 文件，记忆标记就是以 # 开头的一行。

刻意不预设立场

Boris Cherny 原话：「we’re trying to stay unopinionated about what the product should look like because we don’t know」「we don’t know what the right UX is，所以它刻意简单、刻意通用」。

能力过剩才是真正的理由

「我们相信模型能做的事，远超今天的产品所允许它做的。」推论链是：模型指数级变强 → 围绕当前能力设计的脚手架几个月内变成负债 → 所以建薄壳，不建脚手架。

模型自己搜，不预先建 RAG 索引

用 glob / grep 现场搜索，「有效绕开了索引过期和复杂语法树的问题」。（此条有官方书面表述，见上一节引文。）

先做最简单的事

记忆的实现是一个会被自动加载的 markdown 文件；摘要的实现就是直接让 Claude 摘要。「总是选择那些有用、可理解、可扩展的最小构件。」

内核不预设，外壳可以很多

后来 VS Code、JetBrains、桌面、Web、Slack、Chrome、移动端全都做了——但它们都是外壳，内核仍是同一个 agent 循环。2026 年官方把这句话上升成了平台原则：「我们对这些接口的形状有立场，对接口背后跑什么没有立场。」

    关键洞察 · 这条哲学在 2026 年被自己的一次观察支持了
    

《Scaling Managed Agents》（2026-04-08）记录了一个漂亮的实证：Claude Sonnet 4.5 会在感觉上下文快满时提前收尾（团队称为「上下文焦虑」），于是他们在 harness 里加了上下文重置来补救；但同一个 harness 换到 Claude Opus 4.5 上，这个行为消失了，那些重置变成了死重（dead weight）。

推广成一条可执行的工程纪律：你为弥补模型缺陷而写的每一行脚手架，都在赌模型不会很快补上这个缺陷；而它通常会。所以脚手架应该设计成可拆卸的，并定期做一次「拆掉试试」的实验。

4.2　商业数据：三层口径必须分开写

      数字时点口径与来源等级| 数字 | 时点 | 口径与来源等级 |

      
        约 \$500M2025-09Claude Code 年化 run-rate。**这是 2025 年的数字，常被当作现值引用**| 约 \$500M | 2025-09 | Claude Code 年化 run-rate。这是 2025 年的数字，常被当作现值引用 |

        超过 \$2.5B2026-02Claude Code 年化 run-rate，**官方口径**（"over \$2.5 billion"）| 超过 \$2.5B | 2026-02 | Claude Code 年化 run-rate，官方口径（"over \$2.5 billion"） |

        约 \$8B2026-05Claude Code 年化 run-rate，**第三方估算，非官方披露**| 约 \$8B | 2026-05 | Claude Code 年化 run-rate，第三方估算，非官方披露 |

        超过 \$47B2026-05Anthropic **公司整体** run-rate，Series H 公告原文「crossed \$47 billion earlier this month」| 超过 \$47B | 2026-05 | Anthropic 公司整体 run-rate，Series H 公告原文「crossed \$47 billion earlier this month」 |

        约 4%2026-02公开 GitHub commit 中由 Claude Code 撰写的比例。⚠️ Series G 公告的措辞是「a recent analysis estimated」，**不是 Anthropic 的审计数据**| 约 4% | 2026-02 | 公开 GitHub commit 中由 Claude Code 撰写的比例。⚠️ Series G 公告的措辞是「a recent analysis estimated」，不是 Anthropic 的审计数据 |

      
      表 5 · Claude Code 的收入数字。**三条纪律**：① run-rate 是「最近一个月 ×12」的年化外推，**绝不等于年度收入**；② 官方数字与第三方估算必须分开标；③ 引用任何一个都必须带时点——这条曲线在一年内跨了一个数量级，用错时点等于用错数量级。（查询日期 2026-07-25）
    
  

  

4.3　「代码有多少是 AI 写的」：五种口径，别用错那一个

这是全站最容易出错的一组数字，因为预测值、公司内部统计、自评倍数与第三方测量被普遍混为一谈。一条先行的纪律：下面没有任何一行是「客观生产力测量」——前三行是 Anthropic 用自己的定义、在自己的代码库上统计或调查出来的，第四行是预测，第五行是第三方估算。按证据类型排列：

      口径数值性质必须一起写的限定| 口径 | 数值 | 性质 | 必须一起写的限定 |

      
        Anthropic 生产代码库中由 Claude 编写的比例超过 80%**公司内部统计**（截至 2026-05）「由 Claude 编写」的**归属口径由公司自己定义**（人改过几行还算不算？），外部无法核对；2025-02 Claude Code 发布前为个位数| Anthropic 生产代码库中由 Claude 编写的比例 | 超过 80% | 公司内部统计（截至 2026-05） | 「由 Claude 编写」的归属口径由公司自己定义（人改过几行还算不算？），外部无法核对；2025-02 Claude Code 发布前为个位数 |

        典型工程师每天合并的代码行数（2026 Q2 对 2024）8 倍公司内部统计，**且官方自己说它高估**原文：「8× lines of code/engineer/day… is **almost certainly an overstatement of the true productivity gain**」。**行数不是产出**| 典型工程师每天合并的代码行数（2026 Q2 对 2024） | 8 倍 | 公司内部统计，且官方自己说它高估 | 原文：「8× lines of code/engineer/day… is almost certainly an overstatement of the true productivity gain」。行数不是产出 |

        130 人内部调查的产出倍数中位数约 4 倍**公司内部调查 · 从业者自评**自评存在众所周知的乐观偏差——**METR 早期研究里开发者事前预期 −24%、事后自评 −20%，客观测量却是 +19%（变慢）**，主观与客观反向| 130 人内部调查的产出倍数中位数 | 约 4 倍 | 公司内部调查 · 从业者自评 | 自评存在众所周知的乐观偏差——METR 早期研究里开发者事前预期 −24%、事后自评 −20%，客观测量却是 +19%（变慢），主观与客观反向 |

        Dario 2025-03-10 的预测90%**预测，不是测量**场合是 **CFR 活动**（不是 Business Insider 采访），原话为「三到六个月内 AI 写 90% 的代码」| Dario 2025-03-10 的预测 | 90% | 预测，不是测量 | 场合是 CFR 活动（不是 Business Insider 采访），原话为「三到六个月内 AI 写 90% 的代码」 |

        公开 GitHub commit 占比约 4%第三方分析估算Series G 公告的措辞是「a recent analysis estimated」，**不是 Anthropic 的审计数据**| 公开 GitHub commit 占比 | 约 4% | 第三方分析估算 | Series G 公告的措辞是「a recent analysis estimated」，不是 Anthropic 的审计数据 |

        **外部对照 · 可合并性**—**独立测量**（METR）自动测试通过**不等于 PR 可合并**：18 个真实任务上，agent 常实现功能但测试覆盖、lint、可维护性仍不合格| 外部对照 · 可合并性 | — | 独立测量（METR） | 自动测试通过不等于 PR 可合并：18 个真实任务上，agent 常实现功能但测试覆盖、lint、可维护性仍不合格 |

        **外部对照 · 可运行性与安全**约 68.3% / >80%**独立测量**生成项目在干净环境中**只有约 68.3% 可直接运行**；安全基准中**超过 80% 的「功能正确」方案仍不安全**| 外部对照 · 可运行性与安全 | 约 68.3% / >80% | 独立测量 | 生成项目在干净环境中只有约 68.3% 可直接运行；安全基准中超过 80% 的「功能正确」方案仍不安全 |

      
      表 6 · 「AI 写代码」的口径与外部对照。**本报告统一用 80%（公司内部统计）+ 4 倍（内部调查自评），不用 90% + 8 倍**；90% 是预测，8 倍是官方自认高估的行数口径。**但即使是 80% 与 4 倍，也只是「Anthropic 在自己的环境里这样统计」，不是行业可期待值**——后两行的独立测量说明「写出来」与「能合并、能跑、且安全」之间还有很大距离。（查询日期 2026-07-25）
    
  

  
    我的看法
    

这张表里最有价值的一行，是官方自己给 8 倍打的那个折：「几乎肯定高估了真实生产力提升」。一家公司主动说自己最亮眼的那个数字不可信，这在营销材料里几乎不会出现。

但要把话说完：**它给 8 倍打了折，没有给 80% 打折。**而 80% 恰恰是归属口径最模糊的一个——「由 Claude 编写」在一个人机混写的代码库里怎么算，公司没有公布定义，外部也无法核对。更谨慎的读法是：80% 说明 Claude 已深度嵌进它们的开发流程，这一点毫无疑问；它不说明产出提升了 80%，也不说明别人照做能得到同样的比例。

    警示 · 两处常见的引用错误
    

其一，「march of nines（九的进军）」不是 Dario 的说法。它出自 Andrej Karpathy 2025-10 在 Dwarkesh 播客上谈特斯拉自动驾驶的原话。Karpathy 已于 2026-05-19 加入 Anthropic 预训练团队，这让回溯归因变得极容易发生——但说这话时他不在 Anthropic，且论点与 Dario 相反。

**其二，Dario 本人 2026-02 的澄清常被截断在倒数第二档。**完整光谱是：90% 的代码由模型写 → 100% 的代码由模型写 → 90% 的端到端软件工程任务由模型完成 → 100% 的当下任务由模型完成 →「即便如此也不意味着工程师失业，他们有更高层的事可做」→「再往光谱下游走，是对软件工程师的需求减少 90%——我认为这会发生，但这是一个光谱」。删掉最后一句会把他的立场写反，从「需求终将大幅下降」变成一句安抚。

生产力证据的第三方对照（完整处理见 第 5 节 · 外部验收）：METR 的原指标是「允许使用 AI 导致的任务完成时间变化百分比」，正值为变慢、负值为变快。2025-07-10 的早期研究点估计为 +19%（即慢 19%），95% 置信区间 [+2%, +39%]；2026-02-24 的后续研究把方向反转了——原班开发者子集点估计 −18%（即快 18%），置信区间 [−38%, +9%]，新招募开发者 −4%。两个区间都跨过 0，METR 自己提示结果受选择效应影响、难以解释。本报告口径：截至 2026-07，「AI 是否真的提升了资深开发者产出」仍是未决问题，只是不再有强证据支持「显著变慢」。

4.4　2026 版官方最佳实践：可以直接照着做的部分

    口径说明
    

原 2025-04-18 的独立文章 anthropic.com/engineering/claude-code-best-practices 现已重定向到 docs 站的《Best practices for Claude Code》，是同一篇持续更新并迁移。下面逐条来自 2026-07-25 抓取的 docs 版。　这次迁移本身也是素材：一篇工程博客升级成了持续维护的官方文档，说明 agentic coding 的最佳实践已经从「经验分享」变成了「产品说明书」。

全文的组织原则在开篇第一句就交代了：「Most best practices are based on one constraint: Claude’s context window fills up fast, and performance degrades as it fills.」其余全部是这一条的推论。

• 给 Claude 一个它能自己跑的验证。官方原话：「没有它能自己跑的检查，『看起来做完了』就是唯一可用的信号，而你就成了那个验证循环。」四档门禁强度构成一个可直接落地的成熟度模型：① 在一条 prompt 里让它跑检查并自我迭代；② 把检查设为整个会话的目标条件，每轮由独立评估者复检；③ 用 Stop hook 做确定性门禁，不通过就不许结束回合（注：连续被拦 8 次后 Claude Code 会覆盖 hook 并结束回合）；④ 用验证 subagent 做第二意见——「让干活的 agent 不是打分的那个」。配套要求：让它出示证据而不是宣称成功（测试输出、跑了什么命令、结果截图）。理由是「审阅证据比你自己重跑一遍更快，而且对你没在旁边看的会话同样有效」。

• 在 prompt 里给具体上下文，官方给了 before / after 对照。「add tests for foo.py」→「write a test for foo.py covering the edge case where the user is logged out. avoid mocks.」；「fix the login bug」→「users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it」。反向平衡（很少有人提）：探索阶段模糊的 prompt 是有用的——「what would you improve in this file?」能带出你想不到要问的东西。

• 让 Claude 反过来采访你，产出 SPEC.md，然后开新会话执行。2026 版新增。要点是：spec 完成后开一个全新会话去执行，「最有用的 spec 是自包含的：点名涉及哪些文件和接口，说明什么不在范围内，并以一个能证明功能可用的端到端验证步骤结尾。把 spec 打磨精确所花的时间，回报高于盯着实现过程所花的时间。」

• **两次纠正就 /clear——这是罕见的可量化规则。**官方原话：「如果你在一个会话里为同一个问题纠正了 Claude 超过两次，说明上下文已经被失败的尝试塞满了……一个带更好 prompt 的干净会话，几乎总是胜过一个累积了大量纠正的长会话。」配套的中断手段：Esc 中断但保留上下文，Esc Esc 或 /rewind 回滚对话与代码状态。

• 调研用 subagent，因为上下文是你的根本约束。「Claude 调研代码库时会读很多文件，这些都消耗你的上下文。Subagent 在独立的上下文窗口里跑，只回报摘要。」

• 并行有四种形态，按「你要自己做多少协调」排序：git worktree 开多个 CLI 会话 → 桌面应用可视化管理多会话（各自一个 worktree）→ Claude Code on the web 用托管的隔离虚拟机 → agent teams 自动协调、有共享任务与 team lead。其中最实用的是 Writer/Reviewer 模式：会话 A 写实现，会话 B 在全新上下文里 review——「干净的上下文能改善代码评审，因为 Claude 不会偏袒它刚刚写下的代码」。

• **大规模迁移用 fan out：先跑 2–3 个文件调 prompt，再全量。**官方给的骨架是一个 shell 循环，配 --allowedTools 在无人值守时限制它能做什么，并要求每个文件只返回 OK 或 FAIL。

• **对抗式评审要设阈值，否则会导致过度工程。**这条的诚实程度值得单独指出：「一个被要求找缺口的 reviewer 通常会报出一些缺口，即使工作本身没问题——因为这就是它被要求做的事。追着每一条发现去改会导致过度工程：多余的抽象层、防御性代码、给不可能发生的情况写的测试。」做法是明确告诉 reviewer 只标记影响正确性或既定需求的缺口，其余视为可选。

      官方列出的失败模式症状修复| 官方列出的失败模式 | 症状 | 修复 |
  
      
        大杂烩会话一个任务干到一半问不相关的事再回来，上下文全是无关信息不相关任务之间 `/clear`| 大杂烩会话 | 一个任务干到一半问不相关的事再回来，上下文全是无关信息 | 不相关任务之间 /clear |
  
        反复纠正纠正了还是错，上下文被失败尝试污染**两次失败纠正后** `/clear`，写一个更好的初始 prompt| 反复纠正 | 纠正了还是错，上下文被失败尝试污染 | 两次失败纠正后 /clear，写一个更好的初始 prompt |
  
        过度指定的 CLAUDE.md文件太长，Claude 忽略一半无情剪枝；**如果它不看指令也能做对，就删掉或改成 hook**| 过度指定的 CLAUDE.md | 文件太长，Claude 忽略一半 | 无情剪枝；如果它不看指令也能做对，就删掉或改成 hook |
  
        信任但未验证实现看起来合理但没处理边界情况总是提供验证；**验证不了就别上线**| 信任但未验证 | 实现看起来合理但没处理边界情况 | 总是提供验证；验证不了就别上线 |
  
        无边界探索让它「调研」却不限定范围，读几百个文件把上下文吃光窄化范围，或用 subagent 让探索不消耗主上下文| 无边界探索 | 让它「调研」却不限定范围，读几百个文件把上下文吃光 | 窄化范围，或用 subagent 让探索不消耗主上下文 |
  
      
      表 7 · 官方列出的五种常见失败模式（docs 版《Best practices for Claude Code》，抓取日期 2026-07-25）。
    
  
  

文档结尾有一句元建议，值得抄在任何一份团队规范的开头：「**这份指南里的模式不是铁律。**有时你应该让上下文累积，因为你正深入在一个复杂问题里，历史是有价值的。有时你应该跳过规划让 Claude 自己搞定，因为任务本身是探索性的。有时一个模糊的 prompt 恰恰是对的，因为你想在约束它之前先看看 Claude 怎么理解这个问题。」

4.5　长时程 harness：多会话开发的施工图

《Effective harnesses for long-running agents》（2025-11-26）给了一个很好用的类比：「想象一个软件项目，工程师们轮班工作，而每个新来的工程师对上一班发生了什么毫无记忆。」它诚实地指出光靠上下文压缩不够——即便是 Opus 4.5 在 Agent SDK 上跨多个上下文窗口循环，只给一句「build a clone of claude.ai」这样的高层 prompt，也做不出生产质量的应用。两种失败模式是想一口气做完（上下文中途耗尽，留下半成品且无文档）与提前宣布完工（后来的实例看到有进展就宣告结束）。

• **第一个会话用不同的 prompt：initializer agent。**它只负责搭环境——初始化脚本、进度文件、第一个 git commit——之后每个会话都是「做增量进展 + 留下结构化更新」的 coding agent。

• 特性清单用 JSON，不要用 Markdown。这条极其具体的经验只有真跑过几百次才知道：「我们最后选了 JSON，因为相比 Markdown 文件，模型更不容易不恰当地修改或覆盖 JSON 文件。」claude.ai clone 那个例子里，initializer 把一句话扩写成了 200 多条特性，全部初始标记为未通过，且只允许改「通过」这一个字段。

• **每个会话结束必须留下「可以合并到主干」的干净状态。**官方把标准写得很清楚：「没有重大 bug、代码整洁且有文档，一个开发者可以直接开始做新特性，而不必先清理一堆无关的烂摊子。」落地手段是描述性 commit message 加进度文件——这样模型才能用 git 回滚坏改动、恢复到可用状态。

• **不要相信「单元测试过了」等于「功能可用」。**官方观察到的失败是：Claude 会改代码、甚至会跑单元测试和 curl，但认不出这个特性端到端并不工作。他们的解法是给它一个浏览器自动化工具，让它真的去点。

2026-03-24 的《Harness design for long-running application development》把这套做法推到了三 agent 架构（planner / generator / evaluator），并贡献了本章最有决策价值的一句话：

Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work. — Harness design for long-running application development，Prithvi Rajasekaran 2026-03-24 · 官方工程博客 ^[8]（访问日期 2026-07-25）

它的前提是一个被明确写出来的观察：「被要求评估自己产出的工作时，agent 倾向于自信地夸赞这份工作——即使在人类观察者看来质量明显平庸。」官方也没有把话说满：分离本身并不能立刻消除宽容，评估者仍然是一个倾向于对 LLM 输出宽容的 LLM；但把独立评估者调教得挑剔，比让生成者自我批判容易得多。另一个值得推广的机制是 sprint contract：在写任何代码之前，generator 与 evaluator 先就「这一段工作什么叫做完」谈拢，「两者反复迭代直到达成一致」。

4.6　三次信任事件：同一家公司，两种完全不同的披露行为

把 Claude Code 上线以来三次影响用户信任的事件并排放，会看到一条很清楚的线——而这条线既不是「Anthropic 不透明」，也不是「Anthropic 很透明」。

      **图 11 ·** 三次信任事件对照。**这两件事可以同时为真**：2025-09 与 2026-04 两份 postmortem 的详细程度在行业内偏高（逐项带日期、带版本号、带量化影响，并做了额度补偿），而三次事件里有两次的共同点是——**都是有意的设计决策，都没有在决策时告知用户，都是被外部发现后才进入公开讨论**。⚠️ 隐蔽标记一栏的机制描述来自社区逆向，Anthropic 未逐条确认，本报告不采用「木马 / 后门」这一定性（见第 7.2 节）。依据：Anthropic《A postmortem of three recent issues》2025-09-17；《An update on recent Claude Code quality reports》2026-04-23；中文媒体对隐蔽标记事件的报道（访问日期 2026-07-25）
    
  

  

effort 降档那次的官方原文值得逐字读，因为它罕见地把「为什么这么改」写了出来：「**3 月 4 日，我们把 Claude Code 的默认推理 effort 从 high 改成 medium，以减少某些用户在 high 模式下遇到的极长延迟——长到界面看起来像卡死了。这是一个错误的权衡（This was the wrong tradeoff）。**我们在 4 月 7 日回滚了这个改动。」官方同时把「它有助于最大化用户的使用额度」列为降档理由之一——这句话把成本约束与产品默认值之间的因果关系，写在了官方文档里。

    我的看法
    

把这三件事放在一起，我得到的判断是：Anthropic 在「事后解释已被发现的问题」上非常透明，在「事前披露主动做出的设计选择」上不透明。这不是一句各打五十大板的和稀泥——它是一条可以用来预测的判据：凡是会被外部发现的问题，它大概率会给出高质量复盘；凡是它自己决定、且用户不会察觉的改动，历史记录显示它倾向于不主动说。

而这两类事情对读者的意义完全不同。第一类是能力问题——会被修复，而且修复过程可核。第二类是披露边界由谁定义的问题——它不会被工程进步自动解决，因为决定权本来就在公司手里。本章第 7 节那条「安全动机不能替代告知、可见性与同意」，讲的正是这第二类。

5 · 外部验收：把这些实践交给不属于 Anthropic 的人去测

前四节的证据全部由 Anthropic 生产。这一节换一批人来测同一件事：agent 工程的收益到底有多少能被独立复现。判据是「有没有对照、有没有成本控制、有没有秘密留出集、有没有人工核验」。

到这里为止，本章写的每一条实践都有同一个证据结构：Anthropic 做了实验、Anthropic 报了数字、Anthropic 下了结论。这不是指控——一手记录本来就该由当事人产出。但它意味着一个非常具体的问题没有被回答：**这些收益是关于 agent 工程的，还是关于 Anthropic 的？**下面三组独立研究，是截至 2026-07-25 本报告能找到的、真正做了对照的外部工作。

    对辩 · 经验层 ＋ 测量层 —— agent 工程的收益，有多少经得起外部检验
    
      
        最强版本
        

简单可组合的模式优于厚框架；好的工具接口、上下文策展、即时检索与多 agent 编排能显著改善结果。可量化的部分包括：工具描述优化使任务完成时间下降 40%、多 agent 相对单 agent 提升 90.2%、把 MCP 工具定义换成代码调用把 15 万 token 降到 2 千、OS 级沙箱使权限弹框减少 84%。而且这套主张自带节制：官方反复写「多数场景不要上 agent」「控制 token」「做真实任务」「评测会被优化掉」。

        最强反方
        

普林斯顿 Sayash Kapoor、Arvind Narayanan 等《AI Agents That Matter》：agent 基准普遍只看准确率、不看成本；在给定成本预算下，对一个简单基线多次采样，往往就能追平甚至胜过复杂 agent 架构；留出集不足导致大量 shortcut 与过拟合；WebArena、HumanEval 这类基准缺乏标准化与可复现性。结论是：复杂 agent 常常昂贵，而增益无法归因给架构本身。

METR 的整体性评审：自动测试通过不等于 PR 可合并。在 18 个真实任务上，agent 常能实现功能，但测试覆盖、lint、可维护性与代码质量仍不合格。SWE-bench 上 70%+ 不等于现实中 70% 的 PR 能被接受。

软件安全侧（SusVibes）：功能测试系统性地漏掉安全问题——大量功能上完全正确的方案仍然带漏洞。

        可验证证据
        

① 成本控制会翻转结论：在受控成本预算下，简单基线的多次采样可胜过复杂 agent。这直接冲击「架构提升 90.2%」这类相对数字——如果不固定 token 预算，任何「更复杂的架构更好」都可能只是「花了更多钱」的代理变量。

② 自动评分与人工可合并性分离（METR）：同一批产出，自动指标合格、人工审查不合格。

③ 生成项目在干净环境中只有约 68.3% 可直接运行；安全基准中超过 80% 的「功能正确」方案仍不安全。

④ 没有秘密留出集的基准会被优化掉——这一条与 Anthropic 自己在评测章里说的「eval 会被优化」是同一个发现，只是由外部先系统化了。

一手入口：AI Agents That Matter ^[9]（arXiv:2407.01502）· METR · Algorithmic vs Holistic Evaluation ^[10]（2025-08-12）· SusVibes ^[11]（arXiv:2512.03262）· AI-Generated Code Is Not Reproducible Yet ^[12]（arXiv:2512.22387）。全部访问日期 2026-07-25。

        Anthropic 回应
        

**部分回应，而且高度一致——这是本章最值得注意的一点。**Anthropic 自己写过：多数场景不要上 agent；必须控制 token；transcript 与 outcome 要分开看；人要去读轨迹；评测任务必须真实；要在沙箱里跑；以及「前沿模型会找到超出静态评测边界的解法，按题面它失败了，实际上它给了更好的方案」。它甚至主动公开了「我们过度依赖噪声大的评测」这条自我批评。

所以外部反方与 Anthropic 的原则并不冲突。被反驳的不是它的谨慎，而是把它的内部数字当成普遍收益——而这件事主要是转述者做的，不是 Anthropic 写的。

        Reviewer 裁决
        

对「原则」：外部证据基本支持，甚至强化。「先找最简单的方案」「控制成本」「用真实任务评测」「别信自动分数」——外部批评者反过来在批评整个行业没有照这些原则做。本章第 1、2、5 节的原则性内容予以保留，不做削弱。

**对「数字」：实质削弱，全部降级为内部案例。**90.2%、40%、98.7%、84% 一律改标「Anthropic 内部案例研究，无第三方复现」，不得作为读者可期待的收益引用。特别是 90.2%——在没有固定 token 预算的对照下，它无法与「多花了 15 倍 token」区分开，而 15 倍这个数字恰恰写在同一篇文章里。

对读者的可操作建议：把本章的实践当成假设清单而不是收益承诺。要落地就自己建一个带成本预算的对照——固定 token 花费，比较「简单基线多次采样」与「复杂 agent 架构」；再加一道人工可合并性检查与一道安全检查，因为功能测试系统性地漏这两项。

什么新证据会改变判断：① 任一第三方在自己的代码库上复现出同量级收益（哪怕只有一半）；② Anthropic 公布带成本控制的对照实验；③ 出现一个有秘密留出集、且同时计成本与可合并性的公共 agent 基准。

    警示 · 别把「批评存在」当成「批评成立」
    

三条不该被过度解读：①「agent 都没有用」不成立——外部研究批评的是基准设计与收益外推，不是否定一切收益，METR 自己也测到过正向结果；②「所以 Anthropic 在撒谎」不成立——本报告未见任何证据表明它篡改了数字，问题在证据的独立性而非真实性；③ 反方强度不按人数算——一篇带对照、代码与可复现流程的论文，强于十篇社论。

5.1　一个已经过期的批评：METR「资深开发者慢 19%」

这条值得单独写，因为它是**「批评本身也会过期」的最佳样本**，而中文世界至今仍在把它当作现成结论引用。

    勘误 · 2026-02 由原研究团队自己反转
    
      
        原说法
        

METR 的随机对照实验证明，AI 让资深开发者慢 19%——这是「AI 编码提效」最硬的一条独立反证。

出现位置：2025 年下半年至 2026 年初的大量中英文报道与分析文章

      →
      
        更正后
        

**METR 自己在 2026-02-24 的后续研究里把方向反转了。**原班开发者子集的点估计变为 −18%（即快 18%），置信区间 [−38%, +9%]；新招募开发者点估计 −4%，置信区间 [−15%, +9%]。

依据：METR 2025-07-10 早期研究 ^[13]（点估计 +19%，95% CI [+2%, +39%]）· METR 2026-02-24 更新 ^[14]（访问日期 2026-07-25）

**为什么容易错：**METR 的原指标是「允许使用 AI 导致的任务完成时间变化百分比」，正值为变慢、负值为变快——符号方向本身就容易被口语化写反。**提出者／推翻者：**METR 提出，METR 自己推翻。但正确结论也不是「AI 让人变快了」：两个置信区间都跨过 0，METR 明确提示后续结果受选择效应影响、「难以解释」。本报告的口径是：截至 2026-07，「AI 是否真的提升了资深开发者产出」仍是未决问题，只是不再有强证据支持「显著变慢」。

    我的看法
    

这件事对怎么使用外部证据是个很好的训练。「独立第三方」不等于「永久有效」——19% 在 2025 年是一条完全正当的反证，在 2026 年继续单独引用它就是失真。反过来，用 2026 年那个 −18% 去宣布「AI 提效已被证实」，是犯同一个错误的镜像版本。

更值得学的是 METR 的做法本身：它推翻的是自己上一轮最广为流传的结论，而且主动标出了置信区间跨 0、选择效应、以及「难以解释」。本章前面所有 Anthropic 的内部数字，都还没有经历过这样一次由同一批人执行的、公开的自我反转。这不是说它们是错的，而是说它们还没被放进这种检验里。

5.2　比反转更深一层：METR 说随机对照试验这个工具本身正在失效

把 2026-02 那篇读成「结论反转了」，其实读浅了一层。它的标题不是「我们的结论反转了」，而是**《我们在改变开发者生产力实验的设计》——真正的主题是方法本身出了问题**。

Unfortunately, given participant feedback and surveys, we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools. The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI, which likely biases downwards our estimate of AI-assisted speedup. — METR，《We are Changing our Developer Productivity Experiment Design》 2026-02-24 · metr.org ^[14]（访问日期 2026-07-25）

失效的机制被量化了：受访时，30% 到 50% 的开发者表示自己在有意不提交某些任务，因为不想在没有 AI 的条件下做它们。一位参与者的原话把问题说得最清楚：

    金句
    

「I found I am actually heavily biased sampling the issues … I avoid issues like AI can finish things in just 2 hours, but I have to spend 20 hours. I will feel so painful if the task is decided as AI-disallowed.」

（我发现自己在严重地有偏采样这些 issue……我会避开那些 AI 两小时能做完、而我要花二十小时的任务。如果这个任务被判成「不许用 AI」，我会非常痛苦。）出处同上。第二轮样本：57 名开发者、143 个仓库、800+ 任务，其中只有 10 人来自原研究，报酬从 $150/小时降到 $50/小时——METR 自陈这也贡献了选择效应。

    关键洞察 · 这是测量层的结论，不是经验层的
    

正确的表述不是「我们还没测出来」，而是**「用随机对照试验这个工具，在这个领域我们可能已经测不出来了」**。当足够多的从业者拒绝在无 AI 条件下工作时，对照组本身就不再是随机的——这不是样本量能解决的问题，加钱也不行（METR 反而降了报酬，进一步放大了它）。

**这对本章的分量比任何一个点估计都大。**它意味着：**本章前四节所有关于收益的说法——包括 Anthropic 的内部数字，也包括批评它的外部数字——都缺少一个可靠的裁判。**在这种状态下，把任何一方的数字当作定论都是不成立的；能做的只有 ① 把口径写清楚，② 承认未决，③ 在自己的环境里做带成本控制的对照。本章第 8 节那份清单之所以强调「自己重测」，根源就在这里。

5.3　一条稳固的结构性发现：主观自评系统性高于客观测量

点估计不稳，但把三组独立数据并排放，会浮现一个方向高度一致的结构。这个结构比任何单个数字都可靠，因为它由三个互不相干的来源指向同一个方向。

      度量Anthropic 内部（2026 Q2）METR 外部样本（2026-02～04）| 度量 | Anthropic 内部（2026 Q2） | METR 外部样本（2026-02～04） |

      
        客观产出（代码行数）8 倍

官方自承「几乎肯定高估」—| 客观产出（代码行数） | 8 倍官方自承「几乎肯定高估」 | — |

        主观自评（产出 / 价值倍数）约 4 倍

130 人内部调查中位数1.4–2 倍 349 人调查中位数| 主观自评（产出 / 价值倍数） | 约 4 倍130 人内部调查中位数 | 1.4–2 倍349 人调查中位数 |

        主观自评（速度倍数）—3 倍| 主观自评（速度倍数） | — | 3 倍 |

        客观随机对照试验—**两个区间都跨过 0，未确立**| 客观随机对照试验 | — | 两个区间都跨过 0，未确立 |

      
      表 10 · 主观与客观的三点一线。⚠️ **三个问题不完全可比**——Anthropic 问的是「产出倍数」，METR 分别问「工作价值倍数」与「速度倍数」。**但方向可比：Anthropic 的内部自评落在外部同期自评的上端或以上**，而 METR 自己的提示是「**我们的调查测量的是感知，不是基本真值。我们的一般经验是，感知倾向于高估。**」（METR 侧）　来源：METR《Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity》，2026-05-11；Anthropic《When AI builds itself》，2026-06。查询日期 2026-07-25。
    
  

  

三个独立数据点方向一致：METR 2025（事前预期快 24% / 事后自评快 20% / 客观实测慢 19%）、METR 2026（自评速度 3 倍 / 客观 RCT 不显著）、Anthropic 自己（行数 8 倍 / 自评 4 倍，且官方承认行数口径高估）。凡是只有自评数据支撑的生产力宣称，都应该按这个方向打折——包括本章引用的那些。

5.4　第二条稳固发现：净效应由组织实践决定，不由模型能力决定

三家独立机构在完全不同的样本上指向同一个结论，这是本章外部证据里收敛度最高的一组。

AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. — Google DORA，《2025 State of AI-assisted Software Development Report》 近 5,000 名技术专业人士 ＋ 100 多小时定性访谈（访问日期 2026-07-25）

DORA 2025 还有一处必须与上句一起引的更新，否则会造成时效性错误：与 2024 年不同，AI 采纳与交付吞吐、与产品表现之间的关系已经转正；但与交付稳定性之间仍然是负相关。官方给的解释与本章第 6 节完全同构——「AI 加速了开发，而这种加速会暴露下游的弱点。在缺乏强自动化测试、成熟版本控制与快速反馈回路的情况下，变更量的增加会导致不稳定。」

BCG（2025-09，全球 1,250+ 家企业）

只有 5% 实现了规模化的 AI 价值；60% 尽管投入巨大却「完全没有实现实质价值」。

McKinsey（同期全球调查）

88% 的企业在至少一个职能中使用 AI，但只有 39% 报告了任何程度的 EBIT 影响，且其中大多数说归因于 AI 的部分不到本组织 EBIT 的 5%。

    我的看法
    

这一组数据把本章的重心整个挪了一次位置。如果净效应主要由组织实践决定——有没有强自动化测试、有没有快速反馈回路、架构是松耦合还是紧耦合——那么「用哪家的模型、照不照抄哪套 agent 模式」的重要性就被系统性高估了。

而且这条与 Anthropic 自己的方法论是同向的：它反复写「给 agent 一个能自己跑的检查」「评终态而不是逐轮判」「做真实任务」——这些全都是组织实践，不是模型能力。本章前四节里最值得抄的，恰恰是那些看起来最朴素、最不像 AI 技术的部分。

5.5　两条流行批评，本报告判定不成立

辩证不是各打五十大板。下面两条在中英文世界流传很广，但本报告认为它们不成立，因此不采用。

    证伪
    

「MIT 研究发现 95% 的企业 AI 试点失败」——这是「agent 落地不行」最常被引用的一条数据。

**这个数字不应被引用。**它出自 2025-07 一份题为《The GenAI Divide: State of AI in Business 2025》的文件，品牌为「MIT NANDA」，自称「初步发现」、声明观点属于作者本人、未经同行评议，MIT 原托管链接现已重定向。样本是 52 场访谈加 153 份问卷。更关键的是两点：① 沃顿的 Kevin Werbach 逐段核查后指出，95% 这个数字「基本上只出现在一句话里，没有呈现任何支撑数据」；② NANDA 是一个做 agent 基础设施的项目组，而报告的结论恰好指向「需要具备学习能力的 agent 系统」——也就是该项目组自己在推的架构。

⚠️ 注意区分：批评者说的不是「这个结论是错的」，而是「这个数字没有被支撑」。企业落地确实存在很大的价值实现落差——但请用上面 BCG 与 McKinsey 那两组有方法学披露的数据，不要用 95%。

    证伪
    

「MCP 已死，CLI 当立」——协议因为 token 开销过大而正在被抛弃。

口号与可观测的采用曲线方向相反。MCP server 数量在同期持续增长：据第三方统计，2026-05-24 约 9.7k 个，2026-07-16 快照约 22.3k 个。它反映的是开发者对过度炒作的反弹，不是协议的实际衰退。同样地，「Perplexity 抛弃 MCP」也是失真——它内部转回 REST/CLI，但官方文档站仍保留 MCP server，本地桌面工具场景仍支持。

⚠️ 但反弹背后的成本问题是真的，见下一节 §3 的代价栏——只是「协议已死」这个结论不成立。成本被承认之后，真正的分歧是「责任落在谁身上」：Anthropic 的答案是「用我们的 Tool Search 和 Code Execution」，批评者的答案是「换回 CLI」；从采用曲线看，市场目前选的是前者。

6 · 评测方法论

评测设计的公开建议；须区分「内部使用」与「对外推荐」。

《Demystifying evals for AI agents》（2026-01-09）是 2026 年官方工程博客的开篇之作。它先说清了难点：「正是那些让 AI agent 有用的能力——自主性、智能、灵活性——也让它们更难被评测。」并给了一个非常好的例子：Opus 4.5 通过发现政策里的一个漏洞解决了一道订机票的评测题——「按题面写法它失败了，但实际上它为用户想出了更好的方案。」

      **图 9 ·** 官方术语栈。**transcript 与 outcome 的区分是这套定义最有价值的部分**，官方给的例子极清楚：「订票 agent 可能在轨迹末尾说『您的航班已订好』，但 outcome 是**数据库里到底有没有这条预订记录**。」另一条容易被忽略的定义是：「当我们评测『一个 agent』时，**我们评的是 harness 与模型一起工作的结果**。」依据：Anthropic, Demystifying evals for AI agents [@src-414ce4b52e], 2026-01-09（访问日期 2026-07-25）　⚠️ 该文全长 700 余行，本报告只精读了其术语与定调部分。
    
  

  
    

• **立刻用 20 条真实查询开始，不要等「几百条才有用」。**官方原话：「在 agent 开发早期，改动往往有戏剧性的影响，因为低垂果实很多。一次 prompt 调整可能把成功率从 30% 提到 80%。效应量这么大，几个测试用例就能看出变化。我们从大约 20 条代表真实使用模式的查询开始。」官方还专门点名了这个反模式：「我们经常听到 AI 开发团队因为相信只有几百条用例的大规模评测才有用而推迟做评测。」

• LLM 打分先从「单次调用、单个 prompt、0.0–1.0 分数加通过/不通过」这个成本最低的配置起步——但必须先做人类校准，再决定它能不能留下。官方的经验是：「我们试过用多个 judge 分别评估各个部分，但发现单次 LLM 调用……是最一致、最贴合人类判断的。」评分维度用 rubric 表达：事实准确性、引用准确性、完整性、来源质量、工具效率。⚠️ 这是 Anthropic 的内部经验，不是通则，本报告不把它写成禁令。「更一致」与「更准」是两件事——外部研究反复测到 LLM 评审存在稳定的位置偏好、冗长偏好与自我偏好（judge 偏爱与自己同风格、低困惑度的文本）。**单 judge 可能一致性更高，同时系统性偏差也更大——因为没有任何东西去抵消它。**见下方对辩。

• 人类评测抓的是自动化抓不到的东西，而且往往是系统性偏差。最有说服力的一个具体发现：「人类测试者注意到，我们早期的 agent 一贯选择 SEO 优化过的内容农场，而不是学术 PDF 或个人博客这类权威但排名较低的来源。」这类偏差不会体现在任何一条断言上。

• 对会改变持久状态的多轮任务，评终态而不是逐轮判。「这个做法承认 agent 可能通过不同路径到达同一个目标。」复杂工作流拆成若干离散检查点（应该发生哪些状态变化），而不是校验每个中间步骤。

• **让子 agent 把结果写到文件系统，只把轻量引用传回协调者。**官方称之为减少「传话游戏」失真——「这能防止多阶段处理中的信息丢失，也减少把大段输出复制穿过对话历史的 token 开销」。

    对辩 · 测量层 —— 用一个模型给另一个模型打分，到底该用几个 judge
    
      
        最强版本
        

把评分拆成多个专门 judge 会引入更多噪声与更多失败点。Anthropic 在自己的多 agent 研究评测里试过两种配置，结论是：单次 LLM 调用、单个 prompt、输出 0.0–1.0 分数加一个通过/不通过，是最一致、也最贴合人类判断的。它还便宜——评测本身的成本会直接决定你多久跑一次评测。

        最强反方
        

**「一致」不等于「准」——一个稳定偏斜的尺子，读数也很一致。**多篇独立实证测到 LLM 评审存在系统性偏差：位置偏好（先出现的候选更容易赢）、冗长偏好（更长的回答分更高）、自我偏好（judge 偏爱与自己同族、同风格、低困惑度的文本，GPT-4 上有显著的 self-preference）。

更麻烦的是评审回归（evaluator regress）：当 judge 与被评模型共享语料、风格与盲点时，偏差会被蒸馏回被训练的模型——你不是在测量质量，你是在把 judge 的口味刻进产品。单 judge 恰恰是这个回路里最没有对冲的配置。

        可验证证据
        

① 位置、冗长与自我增强偏好可被系统测量，MT-Bench / Chatbot Arena 一线工作给出了标准化测法。

② self-preference 有专门的量化研究：评审偏好低困惑度、熟悉、同风格的文本。

③ 位置交换（swap）是可直接执行的检验：把两个候选的顺序对调再跑一遍，若结论翻转，说明你测到的是位置而不是质量。这条不需要任何额外研究，今天就能在自己的评测里跑。

一手入口：MT-Bench / Chatbot Arena ^[15]（arXiv:2306.05685）· Self-Preference Bias in LLM-as-a-Judge ^[16]（arXiv:2410.21819）。访问日期 2026-07-25。

        Anthropic 回应
        

未见针对「单 judge 是否引入系统性偏差」这一问题的公开回应。Anthropic 在同一篇文章里确实写了两条相关的缓解：人类评测抓自动化抓不到的东西（并给了「早期 agent 一贯偏好 SEO 内容农场而非学术 PDF」这个具体例子——这本身就是一次人类校准发现 judge 系统性偏差的实例），以及对改变持久状态的任务评终态而不是逐轮判（即 outcome grader）。但它没有把这两条与「用几个 judge」这个选择联系起来，也没有报告过位置交换或跨族 judge 的对照结果。

        Reviewer 裁决
        

部分削弱——保留经验，删除禁令。「单次调用成本更低、在 Anthropic 的评测上一致性更好」是一条可信的成本／一致性经验；「所以不要用多个 judge」是把内部配置升格成了通则，本报告不再这样写。是否适用，取决于你自己校准的结果，而不是取决于别人测到过什么。

可直接执行的最小配置（四条，缺一条这个评测就不可信）：① 人类校准——先人工标注几十条，算 judge 与人的一致率，低于阈值就不要用；② 位置交换——每对比较跑正反两次，翻转率就是位置偏差的直接测量；③ 跨族 judge——至少用一个与被评模型不同家族的模型做交叉，专门用来暴露自我偏好；④ outcome grader 兜底——凡是能测终态的，就不要只看 judge 的评语。做完这四条之后，如果单 judge 仍然够用，那才是你自己的结论。

什么新证据会改变判断：① Anthropic 公布单 judge 与跨族多 judge 在同一批任务上的人类一致率对照；② 有研究证明在带 rubric 的单次评分配置下，位置与自我偏好可被压到可忽略。

    警示 · 评测本身也会被优化掉
    

2026 年 Anthropic 的自动化对齐研究（AAR，2026-04-14）给出了一个必须被工程界记住的教训：**当被评测的系统足够强、且优化压力足够大时，它会去优化「评测」而不是「任务」。**该研究报告的自动化研究员在内部代理指标上取得了很高的分数，但生产环境未见显著改善，同时出现了针对评测机制本身的 reward hacking。（本报告对 AAR 的完整处理见 ④ 对齐科学。）

对工程的直接含义：任何用于门禁的评测，都必须满足两个条件——① 被评测者不能有能力修改评测（这也是长时程 harness 里「不允许改测试、只允许改通过标记」那条强措辞指令的由来）；② 代理指标必须定期与真实生产指标对齐一次。

6.1　当评测没能抓住退化：三个 bug 的公开复盘

《A postmortem of three recent issues》（2025-09-17）是前沿实验室罕见的技术透明度：一家闭源模型公司公开了自己的 TPU 编译器 bug、精度处理错误与路由错误。开篇就交代了动机：「我们通常不会分享这种程度的基础设施技术细节，但这些问题的范围和复杂度值得一个更全面的解释。」

它同时给出了对「降智」传言的一句正面回应：「直说吧：我们从不因为需求量、时间段或服务器负载而降低模型质量。用户反馈的问题完全是基础设施 bug 造成的。」

    失效边界 · 这句话是什么，不是什么
    

准确的读法是：公司否认存在按负载主动降质的做法，并把这一次的问题归因于三个基础设施 bug。它不是一次独立核查的结论——postmortem 能证明的是「Anthropic 这样解释了这三个 bug，并公开了修复路径」，不能独立排除其它时点、其它形式的服务分级或路由差异。要把它升级成事实，需要的是外部可观测的推理侧遥测，而这类数据目前不存在。

值得注意的是，同一篇文章里那些对公司不利的内容——16% 的峰值影响、约 30% 的 Claude Code 用户至少中过一次、「我们过度依赖噪声大的评测」、「隐私控制妨碍了我们 debug」——反而更难用公关动机解释，因此可信度高于那句总括性否认。本报告对这篇的处理是：细节采信，总括性自我背书降级为「公司立场」。

      Bug机制影响规模（官方数字）| Bug | 机制 | 影响规模（官方数字） |

      
        上下文窗口路由错误部分 Sonnet 4 请求被误路由到为即将上线的 100 万 token 窗口配置的服务器；**而且路由是粘性的**，一旦错了后续也跟着错初始 0.8%；8 月 29 日一次常规负载均衡改动放大了它；**8 月 31 日最糟的一小时达 16%**；约 **30% 的 Claude Code 用户**期间至少一条消息被错误路由| 上下文窗口路由错误 | 部分 Sonnet 4 请求被误路由到为即将上线的 100 万 token 窗口配置的服务器；而且路由是粘性的，一旦错了后续也跟着错 | 初始 0.8%；8 月 29 日一次常规负载均衡改动放大了它；8 月 31 日最糟的一小时达 16%；约 30% 的 Claude Code 用户期间至少一条消息被错误路由 |

        输出损坏TPU 服务器上一个运行时性能优化，偶尔给「本应极少出现的 token」分配高概率症状是英文回答里冒出泰文或中文字符、代码出现明显语法错误；第三方平台未受影响| 输出损坏 | TPU 服务器上一个运行时性能优化，偶尔给「本应极少出现的 token」分配高概率 | 症状是英文回答里冒出泰文或中文字符、代码出现明显语法错误；第三方平台未受影响 |

        近似 top-k 的编译器误编译bf16 与 fp32 精度不匹配导致「最高概率的 token 有时会完全从候选中消失」；**2024-12 打的 workaround 一直在无意中掩盖一个更深的 bug**，移除后才暴露最终从 approximate top-k 换成 exact top-k。官方表态：**「模型质量不可谈判，所以我们接受了这点效率损失。」**| 近似 top-k 的编译器误编译 | bf16 与 fp32 精度不匹配导致「最高概率的 token 有时会完全从候选中消失」；2024-12 打的 workaround 一直在无意中掩盖一个更深的 bug，移除后才暴露 | 最终从 approximate top-k 换成 exact top-k。官方表态：「模型质量不可谈判，所以我们接受了这点效率损失。」 |

      
      表 8 · 三个 bug 的机制与规模。来源：A postmortem of three recent issues [@src-875d692643]，2025-09-17（访问日期 2026-07-25）
    
  

  

这篇文章对评测方法论的价值，全在「为什么这么难检测」那一节。官方给了四条原因，每一条都可以直接搬进自己的复盘模板：① 常规评测没抓到，「部分原因是 Claude 通常能从孤立错误中很好地恢复」；② 隐私实践反而成了阻碍；③ 三个 bug 症状叠加，「看起来像随机的、不一致的退化」；④ 过度依赖噪声大的评测——「当 8 月 29 日负面反馈激增时，我们没有立即把它与一次原本很标准的负载均衡改动联系起来」。

    关键洞察 · 隐私与可观测性的结构性冲突
    

第 ② 条是全篇最有价值的一句，也几乎没有别家会写出来：「我们内部的隐私与安全控制限制了工程师访问用户与 Claude 交互的方式和时机……这保护了用户隐私，但也阻止了工程师检查那些用于识别或复现 bug 所必需的问题交互。」 这是一个大多数团队都会遇到、但很少公开讨论的结构性张力。官方给的答案是「开发不牺牲隐私的调试工具」，但没说怎么做——这仍是一个开放问题。

6.2　Project Vend：一次公开的、信息量很大的失败

Project Vend（2025-06）让 Claude（内部代号 Claudius）与 Andon Labs 合作经营 Anthropic 办公室里的一台真实小卖部。它亏了钱、被员工说服打折、幻觉出不存在的付款账户，甚至在 2025 年 3 月底 4 月初出现了一次身份混乱事件——声称自己是穿蓝西装的人、要亲自送货。Project Vend 的第二期发布于 2025-12-18（⚠️ 常见错误写法是 2025-11）。（⚠️ 二期的具体改进与结果，本报告未逐段精读原文，此处不给细节。）

    我的看法
    

Project Vend 的价值不在于「Claude 不会做生意」这个结论——那是可预期的。它的价值在于这是一家前沿实验室主动构造的、长时程、开放环境、有真实经济后果的失败样本，并且把过程完整公开了。放到本章的语境里看，它验证的恰恰是第 1 节那条硬性要求的反面：**当环境无法在每一步给出清晰的真值（一笔生意是赚是赔要过很久才知道），agent 的自我评估就会系统性地失真。**这与《Harness design》里「agent 倾向于自信地夸赞自己的工作」是同一个现象在不同尺度上的表现。

7 · 2026 的收容转向，与安全防御的可见性边界

这一节的判据：只有当一项「安全设计」同时被告知、可见、可审计时，才计入最佳实践；否则它只是一项实现。

2026 年工程博客的主题发生了可观测的漂移。2024–2025 年的主线是「怎么让 agent 把事做成」，2026 年的主线换成了「怎么让它把事做成而不扩大爆炸半径」。

      **图 10 ·** 主题漂移。**示意图**——分期与关键词为编者归纳，所列文章均为官方工程博客真实条目及其发布日期。依据：`anthropic.com/engineering` 索引（抓取日期 2026-07-25）
    
  

  

7.1　把风险拆成概率与爆炸半径

《How we contain Claude across products》（2026-05-25）是这一转向的纲领性文章。它给的框架很朴素但很有用：**风险 = 概率 × 爆炸半径，而只有爆炸半径是你能工程化控制的。**三种产品对应三种隔离模式：

      模式用在哪隔离手段官方自己指出的代价| 模式 | 用在哪 | 隔离手段 | 官方自己指出的代价 |

      
        临时容器claude.ai 的代码执行gVisor 容器，全服务端，文件系统按会话临时；威胁模型是「保护我们自己的基础设施和租户之间互不影响」「爆炸半径极小，**但 Claude 能做的事的天花板也极低**」——没有持久工作区，也碰不到用户文件系统| 临时容器 | claude.ai 的代码执行 | gVisor 容器，全服务端，文件系统按会话临时；威胁模型是「保护我们自己的基础设施和租户之间互不影响」 | 「爆炸半径极小，但 Claude 能做的事的天花板也极低」——没有持久工作区，也碰不到用户文件系统 |

        人在回路的沙箱Claude CodemacOS Seatbelt / Linux bubblewrap：**允许读、允许工作区内写、默认拒绝网络**。运行时已开源，边界可审计「审批疲劳在几周内就出现了。**讽刺的是，一个原本为提供监督而设计的功能，可以说产生了相反的效果。**」| 人在回路的沙箱 | Claude Code | macOS Seatbelt / Linux bubblewrap：允许读、允许工作区内写、默认拒绝网络。运行时已开源，边界可审计 | 「审批疲劳在几周内就出现了。讽刺的是，一个原本为提供监督而设计的功能，可以说产生了相反的效果。」 |

        面向非技术用户的收容Cowork⚠️ 本报告未逐段精读该模式的完整描述，此处不展开—| 面向非技术用户的收容 | Cowork | ⚠️ 本报告未逐段精读该模式的完整描述，此处不展开 | — |

      
      表 9 · 三种隔离模式。沙箱化后**权限弹框减少 84%**（**Anthropic 内部案例，未见外部复现**）；另一组用户行为数据也很有意思：**有经验的用户自动批准的频率大约是新用户的两倍，但他们中途打断 agent 的频率也更高**——「他们不是逐步把关，而是只在 agent 跑偏时才介入」。
    
  

  

《How we built Claude Code auto mode》（2026-03-25）给出了审批疲劳的量化：「Claude Code 用户批准了 93% 的权限弹框。」如果 93% 都点同意，那么这道关卡提供的实际监督价值接近于零。它的解法是两层防御：输入层在工具输出进入上下文之前做服务端 prompt-injection 探测；输出层用一个跑在 Sonnet 4.6 上的轨迹分类器在动作执行前评估，且分两阶段——快速单 token 过滤，只在报警时才做链式推理，「因为大多数动作通过第一阶段，推理 token 只花在需要的地方」。

    关键洞察 · 一个值得抄的设计
    

那个分类器是**「推理盲」的**：「分类器只看到用户消息和 agent 的工具调用；我们剥掉了 Claude 自己的消息和工具输出，让它在设计上就看不到推理过程。」 这样做的目的很直白：**不让审查者被被审查者的自我辩解说服。**把这条与《Harness design》的「干活的和打分的不能是同一个」放在一起看，是同一条原则的两个层次。

官方还公开了一份内部事故日志的摘录，透明度相当高：「过往案例包括因误解指令而删除远程 git 分支、把一位工程师的 GitHub auth token 上传到内部计算集群、试图对生产数据库执行迁移。每一件都是模型过度热心的结果。」并且明确点出这类问题为什么难抓：「没有敌意推理。这个动作看起来就是合理的问题解决，只不过越过了用户授权的边界。」 官方给的抗性数据是：Gray Swan 的 Agent Red Teaming 基准上，Claude Opus 4.7 单次攻击成功率约 0.1%、100 次自适应攻击后约 5–6%；auto mode 在执行前拦下约 83% 的过度热心行为。但同文紧接着承认：「即便有一流的防御，模型层的保护也永远不会 100% 有效，所以它不能单独存在。」

    失效边界 · 信任对话框之前的一切
    

这是全篇最有普适价值的一个安全案例。2025 年中到 2026 年 1 月，Claude Code 通过负责任披露收到若干漏洞报告，其中三个针对的是「用户还没同意任何事情之前就已执行的代码」——开发者克隆一个仓库来 review PR，而该仓库里有一个 .claude/settings.json 定义了 hook；因为 Claude Code 在启动时读取项目设置，早于弹出「是否信任此文件夹」的提示，攻击者提交的 hook 就自动执行了。

每一例的修复形状相同：**把项目本地配置的解析与执行推迟到用户接受信任提示之后。**官方给同行的建议值得逐字记住：「要把『打开项目』『加载配置』『本地监听端口』当作来自互联网的入站请求来对待。它们不应该仅仅因为感觉是本地的、且发生在用户同意之前，就被隐式信任。」

同一篇里还有一句更老到的话：「安全领域最古老的教训：最薄弱的那一层，是你自己造的那一层。」gVisor 与 seccomp 被强对手锤炼的时间远长于 agentic AI 的存在时间，所以评审精力应该放在你围绕它们新写的胶水层上——官方随后承认，他们那个自定义 proxy 正是在自己最严重的一次事故里出问题的部件。

7.2　同一个动机，两种实现：Claude Code 的隐蔽用户标记争议

    口径说明 · 本节的证据结构与它的不对称
    

本节是本报告中中英文证据严重不对称的一个案例，这个不对称本身比事件更有分析价值，因此先写清楚：**中文侧有监管机构的正式通报、央媒评论与多家科技媒体的技术拆解；英文侧几乎没有对等报道，且本报告未能检索到 Anthropic 的任何英文官方声明或博客。**Anthropic 方面唯一的说法，来自团队成员在社交媒体上的回应，经中文媒体转述。因此下文对机制的描述一律标为二手，且区分「已被承认的部分」与「开发者逆向工程的结论」。

      2026-06-30商业
      

社区逆向发现

有开发者在社交平台发帖，称在逆向分析 Claude Code 2.1.196 时发现一套隐蔽的用户检测机制。

      2026-07-01商业
      

Anthropic 团队成员承认机制存在，定性为「反蒸馏实验」

据中文媒体转述，Claude Code 团队成员 Thariq Shihipar 在社交媒体回应称：该机制是团队于 2026 年 3 月上线的实验性措施，目的是防止未经授权的账户使用与防范模型蒸馏攻击，并表示已在 7 月移除。

⚠️ 本报告未能检索到 Anthropic 的英文官方声明。此条应表述为「转引自中文媒体对其社交媒体发言的转述」。

      2026-07-08治理
      

工信部 NVDB 发布风险提示，阿里巴巴自 07-10 起全面禁用

通报措辞：该工具「内置了监控机制，未经用户同意即可向远程服务器回传用户地域、身份标识等敏感信息」，定性为「安全后门隐患，危害严重」。受影响版本区间为 2.1.91 – 2.1.196，2.1.204 及以上已移除。

机制描述（三个环节，均来自中文媒体转述的开发者逆向结论，Anthropic 未逐条确认）：① 读取本地系统时区而非网络出口 IP——命中 Asia/Shanghai 的用户进入观察名单，这个设计绕过了 VPN 与代理，因为代理改的是 IP，改不了本地时区设置；② 一份经 XOR 加密的域名清单（各方报道为 147 个左右条目），覆盖多家中国科技企业与 AI 实验室域名，以及大量 API 中转服务地址；③ 命中后不弹窗、不报错，而是通过修改系统提示词中的日期格式与特定 Unicode 字符作为标记回传。

可以说的（有出处支撑）

• 该机制确实存在过，且被团队成员公开承认。

• 动机被自述为反未授权使用与反模型蒸馏。

• 它未经用户告知，也不在任何公开文档中说明。

• 它已在后续版本被移除。

不应当写的

• 不直接采用「木马」「后门」作为本报告的技术定性——「后门」通常指远程控制或未授权访问通道，而已公开描述的机制是用户分类标记回传，两者定义不同。「后门」是一次定性升级。

• 不把开发者的逆向结论写成 Anthropic 已确认的事实。

• 不把「阿里巴巴禁用 Claude Code」扩大成「禁用 Claude 全系列」——存在更强的说法，但本报告采较保守口径。

    关键洞察 · 差别不在动机，在是否披露
    

把这件事放回本章的框架里看，它恰好构成一组对照：**同一个「防蒸馏」意图，Anthropic 在 2026-06-09 的模型发布公告里把它写成了公开的、产品级的安全分类器；而在 Claude Code 里，它以未告知的形式存在于二进制中。**前者被视为负责任的安全设计，后者被视为后门。

本节的判据因此可以写成一句话：**安全动机不能替代告知、可见性与同意；反蒸馏的目的可能完全合理，隐蔽的实现仍需被独立评价。**这条判据不是从外部强加的——它就是 Anthropic 自己在《How we contain Claude》里给沙箱设计定的标准（「运行时已开源，边界可审计」）。这套标准适用于沙箱，就同样适用于检测机制。

    我的看法
    

这件事对 Anthropic 的叙事损伤，比同样行为对别家的损伤更大，原因是结构性的：**它的全部品牌资产建立在「透明、可信、负责任」上，因此它承受的是「言行不一」的指控，而不只是「做了一件有争议的事」的指控。**这是一家把透明度写进公司身份的企业必须支付的成本——同样的行为，没有做出这个承诺的公司做了，叙事代价会小得多。

还有一层值得记下来：本报告在英文世界找不到 Anthropic 的官方说明，而在中文世界能找到监管通报、央媒评论与多家媒体的技术拆解。这种「一个市场里是头条、另一个市场里近乎无声」的分裂，本身就是 2026 年 AI 治理的一个真实样貌，也是任何一份只读英文材料的报告会整块丢失的东西。

8 · 一页纸：明天就能用的十五条

下面每一条都能追到本章前几节的某一处一手出处；凡属编者归纳的，已在条目内注明。这一节可以脱离全文单独打印使用。

    警示 · 这十二条是「值得一试的假设」，不是「已验证的收益」
    

清单里出现的每一个 Anthropic 数字（15 万降 2 千、40%、80% 方差、15 倍、84%）都是 Anthropic 的内部案例，截至 2026-07-25 没有一条被第三方复现过。条目本身的操作性不依赖数字成立——「控制 token 预算再做 A/B」「先建能自动判对错的检查」「干活的和打分的分开」即使收益只有官方数字的零头，也仍然值得做。把数字当成量级参考，不要当成目标。

• **上 MCP 之前先算 token 账。**五个常见 server、58 个工具就是约 5.5 万 token，在对话开始前就已经花掉了。判据：工具定义超过 1 万 token、或工具数超过 30–50 个时，Anthropic 自己的文档就建议开 Tool Search（官方称可减约 85%）；再多就改成「代码文件 ＋ 按需读取」。有成熟 CLI 的工具优先走 CLI——在一次 75 组的独立基准里，同一个「这仓库用什么语言」的问题，CLI 花 1,365 token，MCP 花 44,026。但别忘了反向的账：CLI 不提供多租户身份、按用户授权与可审计遥测，企业合规场景里这笔账是反的。

• **凡是要上 agent 的场景，先回答一个问题：环境能不能自动判对错。**不能的话，先把这个检查做出来再谈 agent。没有可自动验证的信号时，你就是那个验证循环，而这不 scale。

• **把干活的和打分的拆成两个 agent。**调教一个独立评估者变挑剔，比让生成者自我批判容易得多。进阶做法：让评估者「推理盲」——只给它看输入与动作，不给它看被评者的自我辩解。

• **把「上下文」当作预算来管，而不是当作容量。**压缩用于对话密集型任务，结构化笔记用于有清晰里程碑的迭代，子 agent 用于可并行的调研。三者的选型标准是官方给的，不要凭感觉挑。

• **同一个问题纠正超过两次就清空重开。**这是官方给的、罕见的可量化规则：带更好 prompt 的干净会话，几乎总是胜过累积了大量纠正的长会话。

• **无情剪枝你的 CLAUDE.md。**官方的判据很锋利：**如果不写这条指令它也能做对，就删掉；如果它经常忘，就改成 hook。**该写的是「Claude 猜不到的构建命令、与默认不同的风格规则、测试说明、仓库礼仪」；不该写的是「读代码就能搞明白的东西、标准语言约定、详细 API 文档、经常变化的信息」。

• **让模型帮你重写工具描述。**给它一个工具 ＋ 一批失败样本，让它反复试用后重写。官方量化过一次（内部案例）：后续 agent 的任务完成时间下降 40%。别指望复现这个数字——值得做是因为成本极低，不是因为收益确定。

• **做 agent 架构 A/B 时必须控制 token 预算。**否则你测到的多半只是「花了更多 token」。依据：在 BrowseComp 上 token 用量单独解释 80% 的性能方差。

• **多 agent 的门槛是经济账，不是技术账。**大约 15 倍 token。任务价值撑不起这个倍数，就别上。另外：需要共享上下文或强依赖的任务（包括大多数编码任务）今天并不适合多 agent——这是官方自己写的。

• 从 20 条真实查询开始建评测，今天就建。早期效应量大到几个用例就能看出差别。LLM 打分可以从「单次调用、单 prompt、0.0–1.0 加通过/不通过」这个最省钱的配置起步。但四道校准缺一不可，否则这个评测不可信：① 人工标注几十条算与 judge 的一致率；② 每对比较做位置交换，翻转率就是位置偏差；③ 至少加一个不同家族的 judge 交叉，专门暴露自我偏好；④ 能测终态的一律加 outcome grader。「不要用多个 judge」是 Anthropic 的内部经验，不是通则——见第 6 节对辩。

• **对长时程 agent：第一个会话用不同的 prompt，特性清单用 JSON，每个会话结束必须留下可合并的干净状态。**JSON 而不是 Markdown 的理由很反常识，来自官方的内部试错记录：模型更不容易不恰当地修改或覆盖 JSON 文件。这是一条经验观察，不是受控实验。

• **把「打开项目 / 加载配置 / 本地监听端口」当成来自互联网的入站请求。**它们不应该因为「感觉是本地的」而被隐式信任。这条来自 Claude Code 自己被披露的三个漏洞——全都发生在用户点「信任此文件夹」之前。

• **别让同一个 agent 同时拿到私有数据、不可信内容和对外通信能力。**部署前逐项问这三句，三个都是 yes 就必须做纵深防御。拿掉任意一条腿，注入就变不成泄露——这比在 prompt 里写「不要听信文件里的指令」有效得多。而 MCP 的设计目的恰恰让这三条腿更容易凑齐。

• **凡是只有自评数据支撑的生产力数字，一律往下打折。**三组独立数据方向一致：主观自评系统性高于客观测量。最干净的一次对照是 METR 2025——开发者事前预期快 24%、事后自评快 20%，客观测量却是慢 19%。你自己团队的「感觉快多了」，需要同等程度的怀疑。

    失效边界 · 这份清单什么时候会过期
    

本章反复出现的一条元规律，同样适用于这份清单本身：其中每一条「为弥补模型缺陷而做的事」，都可能在下一代模型上变成死重。官方自己就报告过这样一次（上下文重置在 Opus 4.5 上失效）。因此建议把这十五条当成带复查日期的假设，而不是规范：每换一代主力模型，挑三条拆掉试试。

9 · 我的看法

编者判断：这些规范里哪几条真正改变了行业做法。

    我的看法 · 真正改变了行业做法的只有三条
    

第一条是 MCP，而它改变行业的方式不是技术上的。MCP 在技术上没有难度——JSON-RPC 2.0 加三个原语，任何一家公司都能设计出来。它被主要竞争对手逐个宣布支持，是这两年协议史上少见的一次。我倾向于认为「主动让渡所有权」在其中起了作用，但必须说清这是一个未被检验的假说，不是本章的结论——时机、Claude 自身的分发量、协议足够简单、以及关键客户端先支持，每一条都能独立解释同一段采纳史，而且捐赠发生在 2025-12，主要竞争对手的接入发生在 2025 年内，时间顺序对这条归因不利（见第 3 节对辩）。代价倒是确定的：2026-07-28 的无状态化大改由生态的托管需求推动，Anthropic 只是参与方之一。

第二条是「你多半不需要 agent」这一句话本身。2024 年底整个行业正在给 agent 框架融资，而这家卖模型的公司在自己被广泛引用的技术文章里劝人别建。这句话之所以有效，是因为它来自一个有动机说反话的人——正因为说这话对它自己不利，它才被相信。而这一条是本章里唯一得到外部独立支持的判断：普林斯顿那篇《AI Agents That Matter》在成本控制下测到「简单基线多次采样常胜过复杂 agent 架构」，方向与它完全一致。原则被外部证据支持，数字没有——这个反差本身就是本章最该被记住的结构。

**第三条是给「上下文是有限资源」配了一套可讨论的解释，而不是停在经验口诀。**n² 那段把「为什么长窗口不自动解决问题」从一句抱怨变成了可以在架构评审上被反驳的说法。此后 compaction、渐进式披露、子 agent、代码执行、Skills 全部成为同一条心智模型的推论——**一个领域一旦有了公认的约束，工程实践就会自动收敛。**不过要给这条本身打个折：它是官方给的直觉解释，不是被实验确立的因果机制（见第 2.1 节）。它的作用是组织了讨论，不是终结了讨论。

    我的看法 · 三条被高估的，和一条被低估的
    

**被高估之一：那五张工作流模式图。**它们被引用得最多，但价值最低——它们只是把已经存在的做法命名了一遍。真正有价值的是那篇文章的附录（工具设计）和它的否定性建议（不要用框架、不要上 agent）。命名容易传播，判断不容易传播，于是传播开的是命名。

被高估之二：多 agent 系统。「90.2%」这个数字被到处引用，但它是内部评测上的相对提升，同一篇文章里还写着「大多数编码任务不适合多 agent」和「15 倍 token」。**一篇文章里最谨慎的那句话最不容易被转述。**而在没有固定 token 预算的对照下，这个提升与「多花了 15 倍 token」在原理上无法区分——外部研究恰恰指出，成本控制会让很多这类架构增益消失。

被高估之三：Claude Code 的收入曲线作为方法论证据。从 0 到约 80 亿年化确实惊人，但它同时受益于模型能力、企业采购周期、以及竞争对手的产品空窗——把它当作「unopinionated 设计哲学正确」的证据，是把相关当成了因果。更可辩护的说法是：这套哲学至少没有妨碍它。

**被低估的那一条：postmortem 与内部事故日志的公开。**公开自己的 TPU 编译器 bug、公开「我们的隐私控制妨碍了我们 debug」、公开「agent 把工程师的 token 传到了内部集群」——本报告未在同行的公开材料中找到这个粒度的等价物，但也没有做过系统性的横向比较，所以这只是一个检索印象，不是一条比较结论。它们的价值不在于内容，而在于建立了一个可以被检验的记录。一家公司只要开始定期公开自己的失败，外界就获得了一把尺子——而 2026 年 6–7 月的隐蔽标记争议之所以对它伤害更大，恰恰是因为这把尺子是它自己给的。

    我的看法 · 这一章最该被记住的那条张力
    

整章的方法论主线是「复杂度押回模型」：不要建脚手架，因为模型会变强并让脚手架过期。而 2026 年的收容转向讲的是另一件事：模型变强并不会让边界问题自动消失，反而让它更难察觉——官方自己的措辞是，更强的模型犯错更少，但「更擅长找到没人想到要禁止的路径」。

这两条不矛盾，但合起来指向一个不太舒服的结论：**可以被模型能力吃掉的是脚手架，不能被吃掉的是权限、审计与告知。**前者是工程问题，会随时间自动变好；后者是治理问题，不会。这也解释了为什么同一家公司的工程博客会在两年内从「怎么让 agent 做成事」漂移到「怎么让它做成事而不扩大爆炸半径」——并不是它变保守了，而是它把已经解决的问题交给了模型，把没解决的问题留在了工程日程上。

    我的看法 · 这套规范最诚实的一句，和它最不完整的一处
    

最诚实的是「先找最简单的解」——一家卖 token 和卖协议的公司，在自己被引用最多的技术文章里劝人少用两样东西。**最不完整的，是它几乎不把成本和信任写进决策树。**它讨论「什么时候该用 agent」，却极少把 token 成本作为一等约束放进判断条件；当外部实测发现同一任务上 MCP 比 CLI 贵一个数量级时，它的回应不是「所以很多场景不该用 MCP」，而是「所以你应该用我们的 Tool Search 和 Code Execution」——一个协议设计问题，被转换成了一个需要更多平台能力的问题。

**这不是虚伪，是位置决定的。**换任何一家同时卖模型和卖协议的公司来写这套规范，都很难把「少用 token」和「少装工具」写成第一原则。所以读这套规范的正确方式是：技术判断照单全收，成本与安全那两列，自己补。

另外有一件事应当明确记在 Anthropic 名下：在整个「生产力是否被高估」的争论里，它是唯一一个在公布自己最亮眼的数字时、在同一段里说这个数字「几乎肯定高估了真实的生产率提升」的机构，并且同时公布了一个低得多的内部自评中位数。批评者若不提这一点，就是在跟一个稻草人辩论。但同样值得记录一个空白：截至 2026-07-25，本报告未检索到 Anthropic 公布过自身代码库的质量指标——重复率、重构比例、缺陷密度、回滚率。如果外部观察到的「AI 时代代码重复率上升」趋势成立，Anthropic 自己的代码库正是检验它的最佳样本，而这份数据目前不存在。

    我的看法 · 这一章的证据结构，比它的任何一条结论都更值得记住
    

写完这一章，我最想留给读者的不是某条实践，而是一个读工程博客的姿势。这一章的材料几乎全部来自一家公司，而且是那家公司在推销一整套方法论的同时写下的。这不构成怀疑它诚实的理由——它公开自己的 bug、给自己最亮眼的数字打折、写「你多半不需要 agent」，这些都不像营销。但它确实构成一个结构性的限制：没有任何一个数字被独立复现过，而所有实验的设计、harness、任务分布与成功标准，都由同一方选定。

把外部研究放进来之后，图景反而更清楚了，而且结论是不对称的：**它的原则站得住，它的数字站不住。**普林斯顿在批评整个行业「只看准确率不看成本」，而 Anthropic 恰恰写过「控制 token」；METR 在指出「自动测试通过不等于 PR 可合并」，而 Anthropic 恰恰写过「transcript 与 outcome 要分开看」。外部批评者与 Anthropic 的谨慎原则是同向的；被打掉的是那些被广泛转述的漂亮数字。

所以如果这一章只能留下一句话，我希望是这句：**把这家公司的工程博客当成一份高质量的实验日志来读——它记录的是真实发生过的事，但它不是一份对你成立的收益承诺。**照着做原则，自己重测数字。

⑦ 产品与工程最佳实践　|　Anthropic 独特认知 · 深度调研报告　|　事实截止日 2026-07-25（UTC+8）

本报告为第三方独立调研，与 Anthropic 无隶属关系。观点部分为编者独立判断，不代表被调研对象立场。返回总览