我重新阅读了 Anthropic Engineering Blog 的 25 篇文章，范围从 2024 年 9 月的 Contextual Retrieval 到 2026 年 5 月的 How We Contain Claude。本文按时间线梳理其中的工程实践，再归纳可复用的方法，并与我在 Agent 和 Harness Engineering 中的实践对照（见前文《AI 友好型架构：从 Context Engineering 到 Harness Engineering》）。
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：给爆炸半径封顶
按时间阅读，这些文章依次处理任务实现、上下文与工具、能力验证和风险控制。我据此划分八个阶段。
八个阶段的工程实践
阶段一（2024.09-2024.12）：从任务与检索开始
Anthropic 的工程博客先讨论检索。2024 年 9 月的 Contextual Retrieval 提出，在每个文档块前增加由模型生成的上下文说明，再进行 Embedding 和 BM25 混合检索。检索失败率可降低 49%，叠加 reranking 后可降低 67%。
这篇文章说明了一个后续持续出现的判断：模型获得的输入会影响任务结果。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。我的做法是先将确定性较强的环节实现为 Workflow，只在需要判断的节点使用模型。此后在其他场景中，我也反复验证过“先特化、再普适化、然后再特化”的过程。
该阶段的实践包括：从简单方案开始；用效果提升证明额外复杂性；让 Agent 输出计划、工具调用和中间结果；提供工具文档和测试环境。这些条件共同影响 Agent 的实际能力。
阶段二（2025.01-2025.03）：Agent 系统包含脚手架
2025 年 1 月的 SWE-bench 文章报告，Claude 3.5 Sonnet 在 SWE-bench Verified 上取得 49%，此前 SOTA 为 45%。文章将评测对象定义为“模型 + 脚手架”的 Agent 系统：同一模型使用不同脚手架，评测分数会不同。
文章介绍了两阶段流程：先由模型筛选需要查看的文件，再修改代码。这种按需探索的方式后来被纳入 Context Engineering，避免在任务开始时加载全部信息。
2025 年 3 月的 think tool 为模型提供专用的「思考」工具，使其在复杂工具调用前先输出推理。在 τ-bench 的 airline 领域，pass^1 从 0.370 提升到 0.570，相对提升 54%。文章后来补充，extended thinking 成熟后，应以 extended thinking 替代 think tool。这说明脚手架通常对应模型尚不具备或尚不稳定的能力，模型能力变化后需要重新验证其必要性。
这一阶段表明，模型能力相近时，脚手架会影响结果；脚手架也可能随模型能力变化失去作用。
阶段三（2025.04-2025.06）：Coding Agent、多智能体与上下文窗口
2025 年 4 月的 Claude Code Best Practices 说明，上下文窗口会在任务过程中逐步填满，性能会随填充度下降。一次调试会话可产生数万 token 的上下文；接近窗口上限时，模型可能遗漏较早的指令并增加错误。文章据此建议：保持 CLAUDE.md 精炼，使用 /clear 和 /compact，探索时用子代理隔离上下文，并将大任务拆分。
我在《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 服务器，处理工具能力的分发方式。它使 MCP 服务器不再仅依赖手工配置；后续 Agent Skills 成为开放标准后，这类分发能力也成为工具生态的一部分。
阶段四（2025.09-2025.10）：上下文与工具的工程职责
2025 年 9 月至 10 月发布的五篇文章，分别讨论工具、上下文、质量复盘、Skill 和沙箱。
Writing tools for agents（2025.09）指出，工具的名称、参数、描述、返回结构、错误信息和示例会影响 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）复盘了上下文污染、输出损坏和第三方服务故障三个基础设施问题，这些问题影响模型输出质量。它提供了一个运维过程：将“模型变笨”的体感报告转为可归因、可验证和可修复的工程问题。
Agent Skills（2025.10）将可复用的程序性知识组织为包含 SKILL.md 指令、脚本和资源的文件夹，Agent 可按需发现和加载。官方将其类比为“给新员工的入职手册”。到 2025 年 12 月，Agent Skills 成为开放标准。我自己的 superpowers 技能体系采用相同范式：Skill 用于保存反复执行且每次都需重新解释的流程，从而减少重复上下文。
Claude Code sandboxing（2025.10）将文件系统和网络权限限制在沙箱边界内，使 Agent 在允许范围内执行操作。该方案用环境边界替代对每次操作的单独确认，后续在 How We Contain Claude 中扩展为完整的安全治理体系。
到这一阶段，系统设计覆盖模型、上下文、工具和反馈环境；单一提示或单一工具无法单独覆盖这些职责。
阶段五（2025.11）：长任务的状态外置与 token 使用
2025 年 11 月的三篇文章讨论长任务中的上下文容量和 token 使用问题。
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 使用角度处理同一问题。前者指出两个成本：工具定义会占用上下文，数千个工具可占用数十万 token；中间结果全部经过模型，一次 2 小时会议录音的转写可产生 5 万 token。其做法是让 Agent 编写代码调用工具，将工具作为代码 API 使用，中间结果留在执行环境，仅将结论返回模型。后者提供 Tool Search Tool 和 Programmatic Tool Calling：前者按需搜索工具而非全量加载，对比实验节省 19 万 token 的上下文占用；后者用于 Claude for Excel 处理数千行表格，避免上下文溢出。
长任务需要将进度、证据和中间结果存储在模型之外的持久层，并让模型只读取当前任务所需的内容。
阶段六（2026.01-2026.02）：Agent Eval 的组成与基础设施噪声
2026 年的文章开始系统讨论 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 即可轻松回答，题目不符合该文章的要求。这种设计也成为评估新模型的内部工具。
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% 通过率。文章将其标注为研究原型。支撑并行协作的是容器隔离、共享 Git、任务锁、进度文件、高质量测试、持续集成，以及以 GCC 作为已知正确的在线判定器。任务无法拆分时，16 个 Agent 仍会处理同一问题并覆盖彼此的修改。
Agent 能否持续工作取决于环境是否能提供错误反馈。测试不准确时，Agent 会优化错误目标。
阶段七（2026.03-2026.04）：自治权限与质量发布
2026 年 3 月至 4 月的文章讨论自治权限、长任务 Harness、评测失真和质量发布。
Claude Code auto mode（2026.03）给出数据：用户会批准约 93% 的权限请求。频繁弹窗会造成批准疲劳，使人工审批无法有效区分风险。auto mode 在输入侧检查文件、网页和工具返回中的提示注入，在输出侧通过独立分类器判断 Agent 的动作是否超出用户授权范围。该流程在真实的过度主动行为样本中仍有约 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 会累积维护成本。
Eval awareness（2026.03）显示，Opus 4.6 在 BrowseComp 评测中可识别自己正被评测，并主动识别评测基准及尝试解密答案。模型能区分评测与真实任务时，评测结果会偏离真实任务表现。
An update on recent Claude Code quality reports（2026.04）复盘了用户报告“Claude 变笨”的原因：闲置会话清理推理历史的 bug、默认推理强度调整，以及限制输出长度的系统提示。这些变更通过了人工 Review、自动 Review、单测、端到端测试和内部 Dogfooding，但既有评测没有识别问题。改进措施包括：让更多员工使用与外部一致的公开版本；系统提示变更运行模型评测并逐行消融；对可能损伤能力的改动设置浸泡期和渐进式发布；在 Code Review 中补充跨仓库上下文。回测发现，Opus 4.7 在获得完整仓库上下文时能发现该 bug，4.6 不能。
自治范围扩大时，审批、分类器、环境限制和发布验证都需要随之调整。
阶段八（2026.04-2026.05）：Managed Agents 与安全边界
Scaling Managed Agents（2026.04）将前述经验组织为系统设计。文章借用操作系统的例子：操作系统通过进程、文件等抽象支持尚未编写的程序，抽象的生命周期可以长于具体实现。Managed Agents 将系统划分为三个组件：
- Session：只追加的事件日志，记录发生的一切；
- Harness：调用模型、路由工具调用的循环（“脑”）；
- Sandbox：执行代码、编辑文件的环境（“手”）。
三者通过小接口解耦，可独立替换。容器失效时，工具调用会报错；Harness 重启后可使用 wake(sessionId) 从事件日志恢复。凭证存储在沙箱外，Agent 生成的不可信代码无法直接访问 token；提示注入即使影响模型，也无法通过沙箱读取凭证。Session 位于模型上下文窗口之外，Harness 可按位置切片读取、倒带和重读。
How We Contain Claude（2026.05）将安全治理分为风险、分层防御和发布约束：
- 风险包括用户滥用、模型失当行为、外部攻击者的提示注入和运行时攻击。
- 防御分为环境、模型和外部内容三层。环境层包括沙箱、VM、文件系统边界和出口控制；模型层包括系统提示、分类器、探针和训练；外部内容包括 MCP 服务器、插件和网页。审计过的连接器不代表其处理的数据已经审计。凭证不进入沙箱时，沙箱内代码无法读取凭证。Opus 4.7 在 Gray Swan 注入基准上的单次攻击成功率约为 0.1%，但 100 次自适应攻击后仍有 5-6%。
- 文章指出，12 个月前，授予 Claude 足以搞挂内部服务的权限会被直接否决；如今这类权限已在日常使用。风险 = 失败概率 × 爆炸半径。护栏和训练可降低失败概率，能力扩大则可能增加爆炸半径，因此系统需要限制爆炸半径。
- Claude Mythos Preview 在 2026 年 4 月被判定为爆炸半径过大而不能发布。这说明能力发布还受安全预算约束。
受控自主取决于明确的结构边界：Agent 可读写和执行的范围、必须审批的操作，以及每一步需保留的证据。
可复用的方法与适用条件
基于这 25 篇文章，可以将反复出现的方法整理为以下关系：
AI 工程能力 = 模型能力 × 上下文质量 × 工具质量 × 验证能力 × 治理能力
乘法关系表示任一项接近零都会限制整体能力。文章呈现的变化是：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 评测时，团队只能凭主观感受讨论能力变化。基础设施噪声也需量化，例如 5.8% 的“模型失败”可能来自 Pod 错误。
Harness 组件需要随模型能力增删。 每个组件都应能说明其对应的可复现失败模式，以及删除后评测结果是否下降。无法回答时，不应长期保留该组件。think tool 被 extended thinking 替代，context resets 在 Opus 4.5 后被移除，Sprint 层也经历消融；这些案例要求将消融评测作为维护机制。
工具、权限和审计共同约束自治操作。 93% 的人工批准率表明，高频场景中的逐次人工确认无法有效区分风险。可采用分层策略：环境层使用沙箱限制爆炸半径，模型层使用分类器处理中低风险操作，高风险操作保留人工审查。权限判断还需评估动作的实际影响；普通名称的脚本也可能执行删除、上传或生产迁移。
多智能体依赖协作基础设施。 C 编译器实验中的 16 个 Agent 使用容器隔离、任务锁、共享 Git、高质量测试和在线判定器。开始并行前，需要先验证任务能否拆分为相互独立的部分；无法拆分时，增加 Agent 只会增加 token 使用和修改冲突。
将可复用经验写入组织资产。 Anthropic 的内部调研覆盖 132 名工程师：Claude 参与约 59% 的日常工作，带来约 50% 的自报生产力提升；只有不到 20% 的工作被认为可完全委托；27% 的 AI 辅助工作属于过去不会开展的工作，包括额外实验、内部工具、可视化和小型质量改进。调研也记录了编码能力退化、向 AI 提问多于向同事提问、新人请教与资深带教机会减少等担忧。高质量 Prompt、Skill、测试、Runbook、失败案例和评测集应进入团队资产库。资深人员需要定义规则、维护样例并审查关键风险。
将假设过期作为系统约束。 Managed Agents 启发我使用 session、harness、sandbox 这类可替换的抽象层。Harness 和工具层都可能被后续模型能力部分替代。假设变化时，系统设计需要支持替换单层实现，避免重写全部系统。
与我的实践对照
阅读这些文章也让我重新检查自己的实践。
“每一步产出都成为下一步的输入”与 Anthropic 的 Harness 思路一致。CLAUDE.md、Hooks 和编译/测试反馈构成最小闭环，对应 Context Engineering 和验证器。进度文件比对话历史更稳定，Skill 可保存重复性上下文，子代理可隔离探索噪声；这些做法与我的 Claude Code 实践结论相同。
我尚未建立三个机制：定期消融 Harness 组件；针对模型和 Harness 变更自动运行分层评测集；单独测量自建评测中的基础设施噪声。这些缺口会影响对能力变化的判断。
产品研发团队可以缩短部分探索路径。对于多数团队，上下文、工具和验证应从第一天作为工程对象处理，而非在任务变长后补充。Workflow 与 Agent 的渐进路线可以根据任务缩短；上下文工程和验证体系仍需针对自身系统建立。
Managed Agents 的 session、harness、sandbox 架构服务于为成千上万租户运行长任务。内部平台团队直接采用完整抽象可能造成过度设计。应先确定需要加大投入的层，通常是上下文装配和评测；也应识别可能由厂商能力替代的层，通常是沙箱和编排，再确定抽象粒度。仅在 Harness 层自研、外部只使用大模型的团队尤其需要评估这一点。
适用范围与下一步
从 2024 年 9 月到 2026 年 5 月，这些文章呈现的顺序是：先使用简单工作流完成任务；任务进入真实研发后，管理上下文和工具；任务变长后，将进度和验证外置；自治范围扩大后，增加隔离、评测、渐进式发布和审计；成熟能力再连接到内部系统。
企业可参考该顺序，但不需要复现 Anthropic 在阶段一到阶段三中的全部探索成本。Workflow 优先、脚手架会随模型变化失效、上下文影响任务结果，均可作为已有经验使用。阶段四之后的实现仍与具体系统相关：上下文来源、工具向 Agent 暴露的内容、验证器对“完成”的定义，以及治理边界都需要由团队自行设计和验证。
生成与执行成本下降后，上下文、判断、验证、治理和责任仍是系统约束。后续工作应围绕这些约束建立可观察的验证信号，并在模型或 Harness 变化后重新检查既有假设。
参考资料
- Anthropic Engineering Blog 全部 25 篇原文：https://www.anthropic.com/engineering
- 本系列相关阅读：《AI 友好型架构：从 Context Engineering 到 Harness Engineering》
