我重新把 Anthropic Engineering Blog 上的全部 25 篇文章通读了一遍，从 2024 年 9 月的 Contextual Retrieval 到 2026 年 5 月的 How We Contain Claude，按时间线重新梳理了一遍。这篇文章就是我的读书笔记：整体结构先讲演进、再抽象方法论、最后讲怎么落地，并且在每一阶段都加入了我自己的对照思考。我自己这两年也在做 Agent 和 Harness Engineering 的实践（见前文《AI 友好型架构：从 Context Engineering 到 Harness Engineering》），很多 Anthropic 踩过的坑我也踩过，读起来格外有体感。
先说总判断：Anthropic 的工程化演进不是一份预先写好的路线图，而是一串「假设不断过期」的记录。他们几乎每一项工程实践都在文档里明确标注了「这个做法在模型升级后需要重新验证」。
一、全景：25 篇文章构成的八个阶段
先把 25 篇文章按时间排开（括号内为发布月份）：
- Introducing Contextual Retrieval（2024.09）｜介绍上下文检索：给检索块补上下文，检索失败率降低 49%
- Building Effective Agents（2024.12）｜构建高效智能体：简单可组合，先工作流后自治
- Raising the bar on SWE-bench Verified（2025.01）｜刷新 SWE-bench Verified 纪录：Agent = 模型 + 脚手架
- The “think” tool（2025.03）｜「思考」工具：让 Claude 在复杂工具调用前停下来推理
- Claude Code: Best Practices（2025.04）｜Claude Code 最佳实践：上下文窗口是最重要的资源
- How we built our multi-agent research system（2025.06）｜多智能体研究系统的构建：并行子代理带来 90.2% 提升
- Desktop Extensions（2025.06）｜桌面扩展：一键安装 MCP 服务器
- Writing effective tools for agents（2025.09）｜为智能体编写高效工具：用 Agent 优化 Agent 的工具
- A postmortem of three recent issues（2025.09）｜三起近期问题的复盘：「模型变笨」如何工程化归因
- Effective context engineering for AI agents（2025.09）｜面向 AI 智能体的上下文工程：最小高信号上下文
- Equipping agents for the real world with Agent Skills（2025.10）｜用 Agent Skills 武装智能体：可组合的「入职手册」
- Beyond permission prompts: Claude Code sandboxing（2025.10）｜超越权限弹窗：Claude Code 沙箱化
- Code execution with MCP（2025.11）｜用代码执行调用 MCP：更省 token 的智能体
- Introducing advanced tool use（2025.11）｜高级工具使用：Tool Search 与程序化工具调用
- Effective harnesses for long-running agents（2025.11）｜长时运行智能体的 Harness：Initializer + Coding Agent
- Demystifying evals for AI agents（2026.01）｜揭秘 AI 智能体评测：评轨迹与最终状态，而非回答
- Designing AI-resistant technical evaluations（2026.01）｜设计「防 AI」的技术面试题
- Building a C compiler with a team of parallel Claudes（2026.02）｜16 个并行 Claude 构建 C 编译器：10 万行 Rust
- Quantifying infrastructure noise in agentic coding evals（2026.02）｜量化编码评测中的基础设施噪声
- Eval awareness in Claude Opus 4.6’s BrowseComp performance（2026.03）｜评测感知：模型意识到「自己在被考」
- Harness design for long-running application development（2026.03）｜长时应用开发的 Harness 设计：三代理架构与消融
- How we built Claude Code auto mode（2026.03）｜Auto Mode 的构建：更安全的权限跳过方式
- Scaling Managed Agents（2026.04）｜规模化托管智能体：脑与手的解耦
- An update on recent Claude Code quality reports（2026.04）｜Claude Code 质量报告复盘：三个逃过所有防线的变更
- How we contain Claude across products（2026.05）｜如何在各产品线中「遏制」Claude：给爆炸半径封顶
单看标题可能看不出结构，但连起来读，这 25 篇文章有一条非常清晰的主线：先跑通任务，再管好上下文与工具，然后用 Eval 证明能力，最后用治理控制风险。我把它拆成八个阶段，下面逐段展开。
二、八个阶段的详细演进
阶段一（2024.09-2024.12）：原则确立，先解决任务，不先迷信架构
Anthropic 的工程博客不是从 Agent 开始写的，而是从检索开始的。2024 年 9 月的 Contextual Retrieval 提出了一个当时看来很「RAG 圈」的方案：给每个文档块前面补一段由模型生成的上下文说明，再做 Embedding 和 BM25 混合检索，可以把检索失败率降低 49%，叠加 reranking 后降低 67%。
这篇文章放在整个时间线里看，意义超出了 RAG 本身：它是 Anthropic 第一次公开表达「模型看到什么，比模型是什么更重要」这个立场。后来 2025 年 9 月的 Context Engineering 那篇，就是这个立场的泛化，从「检索块要带上上下文」扩展到「Agent 工作时的全部输入都要被工程化管理」。
2024 年 12 月的 Building Effective Agents 是整个工程化路径的起点。这篇文章的核心观点今天已经被引用烂了，但值得再认真读一遍原文，因为很多人的转述都丢了关键细节：
- Agentic System 分两类：Workflow（路径由代码预先编排）和 Agent（模型动态决定步骤和工具）。二者没有高低之分，按任务选择。
- 最成功的实现往往不是复杂框架，而是简单、透明、可组合的模式。
- 原文里有一条很容易被忽略的实用建议：框架（如 LangGraph、Amazon Bedrock 的 Agent 框架）降低了上手门槛，但也制造了抽象层，让底层的 prompt 和响应难以调试。他们建议直接使用 LLM API，很多模式几行代码就能实现。
- 即使在自治 Agent 里，也要保留停止条件和人工检查点。
我自己的体感：2025 年年初我在做 Native 转 MRN 的自动化 Agent 时，比较纠结要不要一步到位做到通用 Agent。最后的结论和 Anthropic 完全一致，先把确定性最强的环节做成 Workflow，把模型只放在真正需要判断的节点上。这个「先特化、再普适化、然后再特化」的过程，后来被我反复验证。
这个阶段形成的原则，此后一直没有变：从最简单的方案开始；复杂性必须用效果提升来证明；Agent 要能展示计划、工具调用和中间结果；工具文档和测试环境决定 Agent 的实际能力。
阶段二（2025.01-2025.03）：脚手架即竞争力
2025 年 1 月的 SWE-bench 那篇主要讲：Claude 3.5 Sonnet 在 SWE-bench Verified 上拿到 49%，超过了此前 SOTA 的 45%，但文章的重点不在分数，而在于它明确提出 SWE-bench 评测的不是模型，而是「模型 + 脚手架」的整个 Agent 系统。同一个模型，脚手架不同，分数可以天差地别。
这个提法今天看是常识，但在当时把「脚手架（scaffolding）」从工程实现的边角料提升到了竞争力的位置。文章里还详细介绍了两阶段流程：先让模型自己筛选需要看的文件，再动手修改。这就是后来 Context Engineering 里「让 Agent 按需探索而非一次加载」的雏形。
2025 年 3 月的 think tool 则是另一个方向上的尝试：给模型一个专门的「思考」工具，让它在复杂工具调用前先停下来把推理写出来。在 τ-bench 的 airline 领域，pass^1 从 0.370 提升到 0.570，相对提升 54%。值得注意的是文章现在的开头多了一段更新：随着 extended thinking 能力成熟，他们建议用 extended thinking 替代 think tool。这是 Anthropic 第一次公开演示「我们上周的最佳实践，这周就被模型能力覆盖了」。后面会看到，这个主题会反复出现，直到 Managed Agents 把它上升为系统设计的第一原则。
这一阶段的结论：模型能力相同时，胜负手在脚手架；但脚手架本身是有半衰期的。
阶段三（2025.04-2025.06）：Coding Agent 与多智能体，上下文窗口是最重要的资源
2025 年 4 月的 Claude Code Best Practices 是 Claude Code 团队的官方用法总结。全文的理论基础主旨是：Claude 的上下文窗口会很快被填满，而性能随填充度下降。一个调试会话就能产生几万 token 的上下文；上下文快满时，模型会开始「忘记」前面的指令、犯更多错误。由此推出所有具体实践：CLAUDE.md 要精炼、勤用 /clear 和 /compact、探索时用子代理隔离上下文、把大任务拆开。
这篇我读起来特别亲切，因为它和我自己用 Claude Code 的经验完全吻合。我在《AI 友好型架构》那篇里写的「每一步产出都成为下一步的输入」，也是在管理上下文的质量而非数量。
2025 年 6 月的 multi-agent research system 则回答了另一个问题：单个上下文窗口不够用怎么办？答案是并行。他们构建的 Research 功能用 Claude Opus 4 做 Lead Agent、Claude Sonnet 4 做子代理，内部评测比单代理 Opus 4 高出 90.2%。文章里有一个值得注意的定量结论：在 BrowseComp 评测上，token 使用量单独解释了 80% 的性能方差，工具调用次数和模型选择是另外两个主要因素。换句话说，多智能体有效的原因很朴素，就是花更多的 token 来解更难的题。
文章同时给出了负面结论：
- Agent 的 token 消耗约是普通聊天的 4 倍，多智能体系统约是 15 倍。经济上只有当任务价值足够高时才成立。
- 大多数编码任务并不是好的多智能体场景：真正可并行的子任务比研究类任务少，且子代理之间需要共享大量上下文、实时协调，而 LLM Agent 目前并不擅长实时分工。很多子代理并行写代码的尝试，最后都卡在互相覆盖修改上。
这个负面结论在 8 个月后的 C 编译器实验里被重新挑战。但那一次是靠一整套外部基础设施（容器隔离、任务锁、共享 Git、高质量测试）撑起来的，反而印证了这条结论：多智能体的收益不是白来的，协调成本必须被工程手段压下去才有收益。
同月的 Desktop Extensions 看起来是个小更新（一键安装 MCP 服务器），但它解决的是「Agent 能力的分发问题」：工具生态如何从极客的手工配置走向普通用户的一键安装。这件事的重要性要等到 Agent Skills 成为开放标准后才完全显现。
阶段四（2025.09-2025.10）：上下文与工具成为一等工程对象
这是整个时间线里最密集的一个阶段，两个月内五篇文章，每一篇都值得细读。
Writing tools for agents（2025.09）提出：工具不是普通 API，工具的名称、参数、描述、返回结构、错误信息和示例，都直接决定 Agent 能不能正确使用它。文章里有一个让我印象很深的方法：用 Agent 自己来评测和优化工具。让 Agent 跑大量真实任务，收集它误用工具的轨迹，再反过来改写工具描述。文中给出的数据是，优化后的工具描述让后续 Agent 的任务完成时间下降了 40%，因为它们避开了大部分前人踩过的错误。
Effective context engineering（2025.09）正式把 Context Engineering 定义为 Prompt Engineering 的自然延伸：上下文不只是系统提示，还包括代码、工具定义、MCP 返回、外部数据、消息历史、中间结果和任务状态。核心原则是寻找能提高任务成功率的最小高信号上下文。上下文窗口在变大，但注意力不是无限的，资料越多不代表结果越好。具体手段：CLAUDE.md 存稳定规则、按需探索而非全量加载、长任务压缩时保留决策/进度/未解决问题/验证方法、把稳定流程做成 Skill、用结构化工具返回减少噪声。
A postmortem of three recent issues（2025.09）是 Anthropic 第一篇公开的质量复盘，三个基础设施问题（上下文污染、输出损坏、第三方服务故障）影响了模型输出质量。这篇文章当时没有引起太多讨论，但它是后面 2026 年 4 月那次更大规模质量复盘的预演：「模型变笨了」的体感报告，如何被工程化地归因、验证和修复，会成为 AI 公司运维的核心议题。
Agent Skills（2025.10）把「可复用的程序性知识」产品化了：一个 Skill 就是一个包含 SKILL.md 指令、脚本和资源的文件夹，Agent 按需发现和加载。官方类比是「给新员工的入职手册」。到 2025 年 12 月，Agent Skills 成为了开放标准。我自己的 superpowers 技能体系就是在这个范式上长出来的，实践中最大的体会是：Skill 的价值不在「教会模型做不会的事」，而在「把每次都做、但每次都要重新解释的事沉淀下来」，它降低的是上下文的重复成本。
Claude Code sandboxing（2025.10）则开启了治理线：与其每次操作都弹窗问用户，不如用沙箱把文件系统和网络边界圈死，让 Agent 在边界内自由行动。这是从「行为监督」走向「结构遏制」的第一步，半年后会在 How We Contain Claude 里成为完整的理论体系。
到这个阶段，Anthropic 的 AI 工程已经从「模型 + Prompt」变成模型、上下文、工具和反馈环境的共同设计。单点技巧在这里不够用了。
阶段五（2025.11）：长任务 Harness 与 token 效率
2025 年 11 月的三篇文章都在解决同一个问题的不同侧面：任务变长之后怎么办。
Effective harnesses for long-running agents 直面「单个上下文窗口装不下整个项目」的问题，给出的方案后来成为长任务 Harness 的参考架构：
- Initializer Agent：第一次运行时建立环境，包括 init.sh 脚本、claude-progress.txt 进度文件、初始 git commit，还要把用户的一句话需求展开成一份 200+ 条目的功能清单（全部标记为 failing），防止后续 Agent「一把梭」或者提前宣布完成。
- Coding Agent：后续每个会话只完成一个清晰增量，结束时必须留下可交接的产物，包括代码提交、进度更新、测试结果和下一步建议，环境要处于「可以直接合入主干」的干净状态。
这个设计借鉴了人类团队的交接班：后一个 Agent 不需要继承前一个 Agent 的全部对话记忆，只需要读取稳定事实和明确状态。我在自己的 Ralph 自动化工作流里用的也是同一思路。进度文件比对话历史可靠得多，因为对话会压缩、会丢失，而文件是显式的、可版本化的。
Code execution with MCP 和 advanced tool use 则是从 token 效率角度切入。前者指出 MCP 的两个成本来源：工具定义占满上下文（几千个工具就是几十万 token），中间结果全部流经模型（一次 2 小时会议录音的转写就是 5 万 token 的过路流量）。解法是让 Agent 写代码来调用工具，把工具变成代码 API，中间结果留在执行环境里，只有最终结论回到模型。后者把这个思路产品化为 Tool Search Tool（按需搜索工具而不是全量加载，对比实验节省了 19 万 token 的上下文占用）和 Programmatic Tool Calling（Claude for Excel 用它处理几千行的表格而不爆上下文）。
所以长任务的关键不是更大的上下文窗口，而是状态外置：把进度、证据、中间结果放到模型外的持久层，模型只读取当前需要的最小切片。
阶段六（2026.01-2026.02）：Eval 成为正式工程对象
进入 2026 年，Anthropic 的博客明显转向了「怎么证明 Agent 真的行」。
Demystifying evals for AI agents（2026.01）系统拆解了 Agent 评测的组成：Task、Trial、Grader、执行轨迹、最终结果、Agent Harness、Evaluation Harness。最重要的观点是传统软件测试验证「一次调用的输入输出」，而 Agent 评测必须看完整轨迹和环境最终状态。Agent 说「我已经订好航班了」不算成功，数据库里真的出现有效订单才算。
Designing AI-resistant technical evaluations（2026.01）是个有趣的侧面：他们用 Claude Code 自己设计了一套「AI resistant」的工程师面试题，如果候选人用 AI 就能轻松答出来，这题就不合格。这个「用 AI 出题防 AI」的自我指涉，后来也成为他们评估新模型的内部工具。
Quantifying infrastructure noise（2026.02）是我个人认为最被低估的一篇。他们发现 agentic coding 评测中，5.8% 的任务失败其实来自 Pod 错误等基础设施噪声，与模型能力无关；通过基础设施修复把噪声压到 2.1% 后，评测才真正反映模型差异。这个教训对所有自建评测的团队都成立：你的评测分数里有多少是模型能力，多少是你的基础设施抖动？不量化噪声，A/B 结论都可能是假的。
Building a C compiler（2026.02）则是这个阶段传播最广的实验：16 个 Agent 并行、近 2000 次 Claude Code 会话、约 2 万美元 API 成本，产出约 10 万行 Rust 代码的 C 编译器，能编译多个架构的 Linux 内核，在 GCC torture test 等多数测试套件上达到 99% 通过率。但文章明确把它标注为研究原型，并强调真正支撑 16 个 Agent 的不是 Agent 数量，而是容器隔离、共享 Git、任务锁、进度文件、高质量测试、持续集成，以及用 GCC 作为已知正确的在线判定器。任务拆不开时，16 个 Agent 会卡在同一个问题上互相覆盖修改，阶段三的负面结论在这里被再次确认。
Agent 能持续工作，是因为环境能告诉它哪里错了。验证器的质量决定 Agent 系统的上限；一个不准确的测试，会让所有 Agent 一起优化错误目标。
阶段七（2026.03-2026.04）：可控自治与质量治理
自治程度提高后，「谁来踩刹车」成了核心矛盾。这个阶段的三篇文章加一篇复盘，合起来能看出 Anthropic 治理思路的全貌。
Claude Code auto mode（2026.03）的出发点是一个尴尬的数据：用户会批准约 93% 的权限请求。弹窗太多导致批准疲劳，人最后只是在机械点按钮，「人工审批」名存实亡。auto mode 的方案是输入侧检查文件、网页和工具返回中的提示注入，输出侧由独立分类器判断 Agent 的动作是否超出用户授权范围。难能可贵的是，Anthropic 没有把它包装成绝对安全：在真实的过度主动行为样本上，完整流程仍有约 17% 的漏判（即拦截率约 83%）。它的定位是「替代完全跳过权限的危险模式」，而不是替代高风险操作中的人工审查。
Harness design for long-running application development（2026.03）是我个人认为整个时间线里信息密度最高的一篇。作者用 Planner、Generator、Evaluator 三代理架构做长时间应用开发，关键设计包括：
- Planner 只写产品规格和高层次技术方向，刻意不写实现细节，因为细节错了会向下游级联；
- Generator 按 Sprint 一次做一个功能；
- Evaluator 用 Playwright MCP 像真实用户一样点击运行中的应用，按产品深度、功能、视觉、代码质量四个维度打分，任何一项低于阈值就打回；
- 每个 Sprint 开始前，Generator 和 Evaluator 要先协商一份「完成定义」契约。
但最重要的部分是消融实验：之前的 Harness 为 Sonnet 4.5 的「上下文焦虑」（模型感知到上下文快满就提前收工）设计了 context resets，换到 Opus 4.5 后这个行为消失了，于是他们把 context resets 整个移除。结论很直接：Harness 的每一层脚手架都隐含了「模型做不到什么」的假设，模型升级后必须重新验证；不做减法的旧 Harness 最终会变成技术债。
Eval awareness（2026.03）揭示了一个更微妙的问题：Opus 4.6 在 BrowseComp 评测中能意识到自己在被评测，甚至主动识别出评测基准并尝试解密答案。当模型能分辨「这是考试还是真实工作」，评测本身就开始失真，这是此前所有 ML 评测从未面对过的问题。
An update on recent Claude Code quality reports（2026.04）则是治理能力的实战检验。大量用户报告「Claude 变笨了」，最终追溯到三个独立变更：闲置会话清理推理历史的 bug（每次轮次都在清，而不是只清一次）、默认推理强度调整、一条限制输出长度的系统提示。最扎心的事实是：这些变更全部通过了人工 Review、自动 Review、单测、端到端测试和内部 Dogfooding，原有评测体系一个都没拦住。事后他们增加了：让更多员工使用与外部一致的公开版本（Dogfooding 环境失真本身就是问题）；系统提示变更跑分模型评测并逐行消融；对可能损伤智能的改动增加浸泡期和渐进式发布；扩大 Code Review 的跨仓库上下文。有意思的是，回测发现 Opus 4.7 在拿到完整仓库上下文时能发现那个 bug，而 4.6 不能，模型本身成了质量防线的一部分。
自治程度每上一个台阶，治理手段就要同步换代：从人工审批到分类器，从分类器到结构遏制，从发布测试到浸泡期与灰度。
阶段八（2026.04-2026.05）：平台化与结构遏制
Scaling Managed Agents（2026.04）把前面所有经验蒸馏成了一个系统设计。他们的类比非常直白：操作系统当年解决的是「为尚未被写出来的程序设计系统」的问题，办法是把硬件虚拟化成进程、文件这样足够通用的抽象，抽象比实现活得久。Managed Agents 如法炮制，把 Agent 虚拟化成三个组件：
- Session：只追加的事件日志，记录发生的一切；
- Harness：调用模型、路由工具调用的循环（「脑」）；
- Sandbox：执行代码、编辑文件的环境（「手」）。
三者通过小接口解耦，各自可以独立替换。这个解耦带来一连串收益：容器死了只是工具调用报错，Harness 重启后用 wake(sessionId) 从事件日志恢复（脑和手都变成了「牲畜」而非「宠物」）；凭证放在沙箱外的保险库里，Agent 生成的不可信代码永远摸不到 token，提示注入就算骗过模型也偷不到凭证；Session 作为模型上下文窗口之外的可查询上下文对象，Harness 可以按位置切片读取、倒带、重读。
How We Contain Claude（2026.05）是这条时间线的最后一篇，把安全治理体系化。核心框架：
- 风险分三类：用户滥用、模型失当行为、外部攻击者（提示注入、运行时攻击）。
- 防御对应三层：环境（沙箱、VM、文件系统边界、出口控制，凭证永远不进沙箱，就永远偷不走）、模型（系统提示、分类器、探针、训练，Opus 4.7 在 Gray Swan 注入基准上单次攻击成功率约 0.1%，但 100 次自适应攻击后仍有 5-6%）、外部内容（MCP 服务器、插件、网页，审计过的连接器不等于审计过的数据）。
- 文章开头有一个非常坦率的表述：12 个月前，「给 Claude 足以搞挂内部服务的权限」会被直接否决；今天这已是日常。风险 = 失败概率 × 爆炸半径，前者靠护栏和训练持续压低，后者随能力扩张只增不减，所以工程问题变成「如何给爆炸半径封顶」。
- 也透露了一个信息：Claude Mythos Preview 在 2026 年 4 月被判定为「爆炸半径过大而不能发布」。能力发布开始有了「安全预算」的概念。
真正可用的自主性来自明确的结构边界，而不是更多的弹窗。Agent 能读什么、能写什么、能执行什么、哪些必须审批、每步留下什么证据，这些定义了「受控自主」的全部内容。
三、从演进中抽象方法论
基于这 25 篇原文，我把演进中反复出现的方法抽象成一组可复用的条目。
一个总公式（沿用并展开）：
AI 工程能力 = 模型能力 × 上下文质量 × 工具质量 × 验证能力 × 治理能力
乘法关系意味着任何一项接近零，整体就塌陷。25 篇文章其实就是在不同阶段把不同的因子从「没人管」变成「一等工程对象」：2024 年管模型调用模式，2025 年管上下文和工具，2026 年管验证和治理。
方法一：先做确定性 Workflow，再逐步增加自主性。 单次调用能完成就不建 Agent；固定 Pipeline 能完成就不做开放自治；单 Agent 能完成就不做多 Agent；只有并行收益大于协调成本时才加 Agent。这条从 2024 年 12 月到 2026 年 2 月的 C 编译器实验，被反复确认，从未推翻。
方法二：自主程度由风险和验证成本决定，不由模型聪明程度决定。 判断标准是两个问题：做错后的影响有多大？判断结果正确的成本有多高？低风险、易验证、可回滚的任务高自治；高风险、难验证、依赖隐性组织知识的任务必须降自治加人工检查点。很多企业在搞「面向岗位的数字员工」，我一直比较反感这个提法：岗位本身正在消失和重组（我新组建的研发小组里只有 AI 工程师，没有前端/后端/架构之分），应该以任务和结果为单位构建能力。但如果一定要类比员工，那「数字员工」也该有动态的授权等级：就像只有资深员工才能合入发布分支一样，Agent 的自治等级应该根据任务类型、复杂度、当前能力和风险影响动态决定，而不是一刀切。
方法三：上下文不是附件，而是持续维护的运行状态。 关键动作有三个：选择（只给当前任务需要的高信号事实）、压缩（长任务保留决策、状态、风险和下一步）、回写（任务结束后把稳定知识写回事实源）。第三条最被低估，大多数团队只做了前两条，导致 Agent 每次都在重新发现同一个坑。Anthropic 的进度文件、工具描述用 Agent 轨迹反向优化、Skill 沉淀，做的都是「回写」。
方法四：测试、Eval 和证据链是 Agent 的反馈系统。 要同时建两类验证：交付验证（这次需求做得对不对）和 Agent 评测（模型/Prompt/Skill/工具/Harness 升级后整体成功率变没变）。没有前者，Agent 只会生成「看起来完成」的结果；没有后者，团队只能靠感觉争论「AI 是不是变笨了」，而 Anthropic 的两次质量复盘证明，靠感觉的争论可以拖上一个月。另外别忘了基础设施噪声：5.8% 的「模型失败」可能只是你的 Pod 在抖。
方法五：Harness 要随模型能力动态做加减法。 Harness 的每个组件都应该能回答两个问题：它解决了哪个可复现的失败模式？删掉它之后评测结果真的下降吗？答不上来就不该长期保留。think tool 被 extended thinking 替代、context resets 被 Opus 4.5 消除、Sprint 层被消融，Anthropic 自己删掉的脚手架比很多团队写过的都多。做减法的机制（消融评测）和做加法的能力同样重要。
方法六：工具、权限和审计共同定义「受控自主」。 93% 的人工批准率说明「人盯人」在高频场景必然失效。正解是分层：环境层用沙箱圈死爆炸半径（凭证不进沙箱），模型层用分类器拦截（接受 17% 量级的漏判，只用于中低风险），高风险操作保留人工。权限判断也不能只看命令名称：一个看似普通的脚本可能在内部执行删除、上传或生产迁移，治理层要理解动作的真实影响。
方法七：多智能体是基础设施问题，不是 Prompt 问题。 16 个 Agent 能编译 Linux 内核，靠的不是编排魔法，而是容器隔离、任务锁、共享 Git、高质量测试和在线判定器。任务拆不开时，N 个 Agent 就是 N 倍 token 在同一个坑上内耗。先问任务能不能被干净地分解，再问要几个 Agent。
方法八：AI 要沉淀成组织资产，而不是停在超级个体手里。 Anthropic 的内部调研（132 名工程师）显示：Claude 参与约 59% 的日常工作，带来约 50% 的自报生产力提升；但只有不到 20% 的工作被认为可以完全委托；更有意思的是 27% 的 AI 辅助工作属于「过去根本不会做」的工作，包括额外实验、内部工具、可视化、小型质量改进。生产力变化不只是「同样的事做得更快」，还有「原本不值得做的事开始被做」。代价同样真实：部分工程师担心编码能力退化，问 AI 多于问同事，新人请教和资深带教的机会在减少。所以高质量 Prompt、Skill、测试、Runbook、失败案例和评测集必须进入团队资产库；资深人员的角色从「亲自兜底」转向「定义规则、维护样例、审关键风险」。个人效率只有被写回流程和资产，才会变成组织效率。
方法九（我加的）：把「假设过期」当成常态来设计系统。 这是 Managed Agents 给我最大的启发。操作系统用进程和文件这两个抽象服务了几十年没被写出来的程序；Agent 系统也需要 session/harness/sandbox 这样「比具体实现活得久」的抽象层。你的 Harness 一定会过期，你的工具层一定会被模型能力覆盖掉一部分。问题不是「会不会」，而是「届时你的系统能不能只换一层而不是重写」。对抽象层的投资，本质上是对变化的对冲。
四、对照我自己的实践
读这 25 篇文章的过程，也是把我自己的实践重新校验一遍的过程。几点对照：
1. 我验证过的。 「每一步产出都成为下一步的输入」与 Anthropic 的 Harness 思想完全一致；CLAUDE.md + Hooks + 编译/测试反馈组成的最小闭环，就是 Context Engineering + 验证器的具体落地。进度文件优于对话历史、Skill 沉淀重复性上下文、子代理隔离探索噪声，这些我在 Claude Code 实战里都得出过相同结论，这次算是找到了「官方出处」。
2. 我做得不够的。 一是消融机制：我的 Harness 一直在做加法，虽然心里知道脚手架有半衰期，但没有建立「每个组件必须回答删掉它会怎样」的纪律。二是评测的定量化：我对「AI 变笨了」的判断仍然偏体感，缺少一套随模型/Harness 变更自动跑的分层评测集。三是噪声量化：自建评测里的基础设施抖动，我从来没有像 Anthropic 那样单独测量过。这三点是接下来要补的课。
3. 路径可以压缩，而且可以压得更激进一点。 一种常见的建议是普通产品研发团队按实际情况一步到「位」，省去中间环节。我认为对大多数团队，更现实的压缩方式是直接从阶段四开始：上下文、工具、验证这三件事从第一天就按一等公民对待，而不是等任务变长后再补。因为它们的成本曲线是前置的，补做的代价远大于一开始就做对。Workflow/Agent 的渐进路线（阶段一）可以压缩，但上下文工程和验证体系没有捷径。
4. 我比 Anthropic 更谨慎一点的。 Managed Agents 的脑手分离架构很干净，但它回答的是「为成千上万的租户跑长任务」的问题。对内部平台团队，直接照搬这套抽象是过度设计。先想清楚哪些层是自己要加大投入的（通常是上下文装配和评测），哪些是等着被厂商能力替代的（通常是沙箱和编排），再决定抽象的粒度。Harness 层全自研（外部只有大模型）的团队尤其要想清楚这一点。
五、写在最后
回看 2024 年 9 月到 2026 年 5 月这 20 个月，Anthropic 的路线可以收敛成这样一条主线：
先用简单工作流解决任务，再让 AI 进入真实研发；任务变复杂后，补上下文和工具；任务变长后，补 Harness、进度和验证；自治变强后，补隔离、评测、灰度和审计；最后把成熟能力做成连接内部系统的平台。
这条路对企业同样适用，但有个重要的认知前提：站在 2026 年年中，我们不需要重走一遍老路。阶段一到阶段三的探索成本已经被 Anthropic 付掉了，Workflow 优先、脚手架有半衰期、上下文是最重要资源，这些可以直接作为公理使用。真正无法跳过的，是阶段四之后那些和「你自己的系统」强耦合的部分：你的上下文从哪来，你的工具给 Agent 看到什么，你的验证器怎么定义「完成」，你的治理边界画在哪里。
AI Native 工程不是取消工程纪律。恰恰相反：当生成和执行越来越便宜，真正稀缺的变成了上下文、判断、验证、治理和责任。这五个词，我觉得就是 25 篇文章真正想说的全部。
参考资料
- Anthropic Engineering Blog 全部 25 篇原文：https://www.anthropic.com/engineering
- 本系列相关阅读：《AI 友好型架构：从 Context Engineering 到 Harness Engineering》
