← Knowledge Notes
AI Engineering / Knowledge note · Chinese

Anthropic 工程团队第一方视角:Agent 工程化 / Skills / MCP / Claude Code(2025-2026 全集)

Anthropic engineering 博客 25 篇 hub wiki。Building Effective Agents 框架(Workflow vs Agent + 5 模式)+ Context Engineering 新范式(prompt engineering 的演化)+ Harness 设计 4 类(单次 / 长跑 single agent / 长跑 multi agent / managed-decoupled)+ Tool 设计 5 原则 + Agent Skills 开放标准 + Claude Code 工程化(sandboxing / auto mode / best practices / 2 次 postmortem)+ MCP 演化(code execution / DXT/MCPB / advanced tool use)。25 篇 1 句话索引。Anthropic 视角是 [[wiki-ai-agent-architecture]] / [[wiki-claude-code-workflow]] 系列里"官方第一方"层,与三方观察互校

Source collection:Anthropic 与 Claude · Published here:2026-09-26 · Note updated:2026-05-19

Agent工程SkillsMCP

何时打开:你想看 Anthropic 自己怎么搭 agent / 怎么改 Claude Code / 怎么设计 MCP 周边,不是听三方解读。本 wiki 把 anthropic.com/engineering 这一带 25 篇(2024 起到 2026-05)按"问题 → 答案"压成 6 大主题 + 25 篇 1 句话索引。

一句话核心:"Anthropic 视角"=第一方实战 + 推标准两件事并行 —— 既给"我们自己怎么做"(building effective agents / harness 设计 / Claude Code 内部决策),也推开放标准(MCP / Agent Skills / Desktop Extensions / Managed Agents),让生态接得上。读三方(王凯 / 老黄 / Lenny)wiki 是"用户视角",本 wiki 是"原厂视角",两视角必须同看**才不会偏。

互校地图:本 wiki ↔ AI Agent 架构与多 Agent 编排(跨作者主题综合)(6 视角综合)↔ Claude Code 工作流(跨作者主题综合)(Claude Code 6 视角)↔ AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive)(Phase A 锚 wiki / agent eval 单文 deep dive)↔ Prompt / Context Engineering(跨作者主题综合)(prompt + context 工程演化)。


0. 25 篇分类总览

按解决的问题归类:

类 篇数 主问题 看本 wiki 哪节
A. 框架与定义 2 "agent 是什么?跟 workflow 怎么分?" §1
B. Context 工程范式 2 "Prompt engineering 之后是什么?" §2
C. Harness 设计 4 "agent 单次能跑 / 多次能跑 / 多 agent 并行能跑,各怎么设计?" §3
D. Tool 设计与 MCP 4 "agent 怎么用 1000 个工具不爆 context?" §4
E. Agent Skills(新原语) 1 "怎么给 agent 加领域专长不污染默认行为?" §5
F. Claude Code 工程化 5 "Claude Code 内部怎么保 quality + 安全 + 用户体验?" §6
G. Eval 方法论 5 "怎么科学评测 agent?(深入见 AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive))" §7
H. 其他 2 think tool 已被 extended thinking 替代 / Contextual Retrieval(RAG 优化) §8

1. 框架与定义:Workflow vs Agent(Anthropic 官方版)

来自 Building Effective AI Agents(2024 末发布,后续大量内部博客都引这篇当 canonical)。

1.1 核心区分

Anthropic 把 LLM 相关系统统称为 agentic systems(智能体系统),内部细分两类:

Workflow(工作流) Agent(智能体)
英文定义 "Systems where LLMs and tools are orchestrated through predefined code paths." "Systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
中文 代码路径预先写好,LLM + tools 按写好的流程跑 LLM 自己决定下一步走哪、调什么工具,自己掌控全过程
谁拿主动权 工程师 模型
何时用 任务结构明确、流程可预定义、要可预测 任务开放、复杂度大、需要灵活性,且愿意接受性能不确定 + 成本更高

关键判断:

"agentic systems often trade latency and cost for better task performance"

译:智能体系统通常是用延迟和成本换更好的任务表现。

意思:agent 不是"更高级",而是"更贵更慢但更灵活"的选项。Anthropic 给的纪律:

何时用 simple LLM call 何时用 workflow 何时用 agent
答案直接出来即可 任务可拆成明确步骤、要保可预测性 / 一致性 步骤数和路径不可预测、规模化人工干预不现实

1.2 5 大 workflow / agent 模式

Anthropic 给的"积木块",从简到繁:

# 模式 中文 一句话 何时用
1 Prompt chaining 提示链 把 task 拆成连续 step,每步独立 LLM call,前步输出 = 后步输入 任务可清晰拆 / 步骤间有顺序依赖
2 Routing 路由 分类输入 → 不同 prompt / 模型处理 类别清晰 + 每类需不同响应
3 Parallelization 并行 同时跑多个 LLM call,合并结果(sectioning 拆任务 / voting 同任务多次跑) 子任务独立 + 速度敏感
4 Orchestrator-workers 编排 + 工人 一个"编排器" LLM 拆任务,动态生成子 task 给"工人" LLM 子任务无法预先列举
5 Evaluator-optimizer 评测 + 优化 一个 LLM 输出,另一个 LLM 评,反馈循环 有清晰评测标准 + 迭代能明显改进

+ Agent(最复杂):LLM 自己规划循环,工具调用 + 环境反馈,直到任务完成或 stop condition。

Anthropic 反复强调:"successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns."(成功的实现不靠复杂框架,靠简单可组合模式。)— 这跟 王凯 Claude Code 终端工作流方法论(完整版) 王凯"工具栈尽量极简"互校一致。

1.3 跟三方视角对照

来源 "Agent"指什么
Anthropic(本节) 动态自主决策 + 工具调用 + 自掌握过程的系统
黄益贺帖子级判断(newtype · Agent 架构与多 Agent 编排) 感知 + 自主决策 + 执行动作的动态体(类似)
王凯字面用法(王凯 Agent 工程实操) "开一个新终端跑 Claude" = 1 个 agent
学术派(Agent 研究论文 3 篇精读(2024-2025)) More Agents Is All You Need / # agents 取代 # parameters

最大共识:agent ≠ workflow,两者组合用(Anthropic 推 5 模式 + agent 6 类组合,老黄叫 "Agentic Workflow"),不存在"纯 agent"的生产部署。


2. Context 工程:Prompt Engineering 之后的新范式

来自 Effective context engineering for AI agents(2025)。

2.1 范式升级

"After a few years of prompt engineering being the focus of attention in applied AI, a new term has come to prominence: context engineering."

译:经过几年聚焦 prompt engineering,新词出现:context engineering(上下文工程)。

两者关系:

Prompt Engineering Context Engineering
焦点 "找对的词 / 句" "configure 整个 context window 里放什么"
单位 一段 prompt 整个调用前的 token 状态
关键问题 "怎么 phrase 这个指令?" "什么样的 context configuration 最能引导出我要的行为?"
思考方式 thinking in words thinking in context —— 全盘考虑当前 token 状态会产生什么行为

2.2 Context 是什么(扩义)

Context = LLM 采样时的全部 token,包括:

  • System prompt
  • User message
  • 历史对话
  • 工具定义
  • 工具返回值
  • 检索结果(RAG)
  • 记忆(memory)
  • 中间推理过程

工程问题:在 LLM 固有约束下(context window 有限 + token 越多越烧成本 + 长 context 注意力衰减),最大化这些 token 的"信号密度"。

2.3 为什么 prompt engineering 不够了

agent 跑起来后,context 是动态生长的 —— 每轮工具调用都往里塞东西。单纯优化 system prompt 不够,还要管:

  • 工具返回值的格式 / 长度
  • 哪些中间结果留 / 哪些丢
  • 跨 session 的"记忆"怎么落怎么取
  • context window 满了怎么 compaction

这些都是 context engineering 的范畴。

实战指针:见 Prompt / Context Engineering(跨作者主题综合) 跨作者综合。Karpathy 早在 2024 就喊"Context Matters",老黄 / 王凯 / Anthropic 这套是同一波认知收敛。


3. Harness 设计:4 类场景

Harness(框架 / 脚手架)= 让 LLM 当 agent 跑起来的基础设施(接输入、编排工具、管 context、记 transcript)。

Anthropic 把 agent 跑法分 4 类,每类 harness 设计不同:

3.1 单次会话 agent(单 context window)

何时:任务在 1 个 context window 内能完成。

代表 harness:Claude Code 默认模式 / Cowork / Cursor。

核心难点:context 管理 + 工具选择 + 用户交互。

3.2 长跑 single agent(跨多 context window)

来自 Effective harnesses for long-running agents + Harness design for long-running application development。

何时:任务跑数小时甚至数天,1 个 context 装不下。

核心难点:新 session 起来时没有上 session 的记忆。Anthropic 用一个生动类比:

"Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift."

译:想象一个软件项目,工程师轮班上岗,但每个新人来上班时对前一班发生的事一无所知。

Anthropic 的两件套解法:

角色 任务
Initializer agent(初始化) 第一次 run,配置环境 —— 准备工作目录、装依赖、设好让"接班人"能直接干活
Coding agent(每班次) 每个新 session 启动后,做增量进展 + 留下清晰交接物(progress notes / TODO / 测试)给下一班用

类比修正版:不是"每个新人完全失忆",是"每个新人能看到前一班贴在白板上的 markdown 笔记"。

真实案例:Carlini 用 16 个并行 Claude 写了 100k 行 Rust C 编译器,跑了近 2000 次 Claude Code 会话 + 烧了 $20K API,见 #36-真实事件-carlini-16-claude-写-c-编译器。

进阶:harness-design-long-running-apps 借 GAN 思路 —— 一个 agent 写代码,另一个 agent 当"裁判"评 frontend 设计(主观品质)+ 测试可用性(可验证),GAN-like 迭代。适用于"产出是设计 / 文案这类主观品质"的长跑任务。

3.3 多 Agent 并行(同一项目)

来自 How we built our multi-agent research system + Building a C compiler with a team of parallel Claudes。

何时:任务子任务可并行(查不同资料、写不同模块)+ 结果需要合并。

Anthropic Research 系统的设计(Claude.ai 的 Research 功能):

[规划 agent] —— 接用户问题,拆出 N 个并行子查询
     ↓
[N 个并行子 agent] —— 各自跑 web 搜索 / Workspace 检索
     ↓
[合并 agent] —— 收集所有结果,综合 + 写报告

关键经验(Anthropic 反复强调):

  • 协调成本是隐藏开销:多 agent 之间传递 context 烧 token 飞快
  • 评测难度激增:你评的是"整个 agent 团队",不是单 agent
  • 可靠性问题:1 个 agent 跑挂率 5%,N 个 agent 团队跑挂率 1−(0.95)^N

3.4 Managed Agents(decoupling brain from hands,2026 新提法)

来自 Scaling Managed Agents(2026)。

核心洞察:之前的 harness 设计都基于"Claude 当前能做 X、不能做 Y"假设。但模型迭代很快,假设会 go stale(过期)。

典型例子:"context anxiety"(上下文焦虑)—— Claude Sonnet 4.5 在感觉 context 快满时会"急着收尾",过早结束任务。harness 团队为此设计"compaction"(压缩历史)绕开。但 Sonnet 4.6 直接没了这毛病,旧 harness 变成累赘。

Managed Agents 思路:把"脑"(模型)和"手"(执行能力)解耦,让 harness 自动跟着模型能力升级,不需要每次模型升级都重写 harness。

对应到产品:platform.claude.com/docs/en/managed-agents,Claude 自动管 long-running 的复杂度。

3.5 4 类 harness 速查

场景 Harness 名 代表 复杂度
单次会话 标准 agent harness Claude Code 默认 ⭐
长跑 single agent initializer + coding agent Agent SDK 长跑模板 ⭐⭐⭐
多 agent 并行 planner + workers + synthesizer Claude.ai Research ⭐⭐⭐⭐
Decoupled managed 自动跟模型升级 Managed Agents 服务 ⭐⭐(用户视角)

3.6 真实事件:Carlini 16 Claude 写 C 编译器

来自 Building a C compiler with a team of parallel Claudes(2026,作者 Nicholas Carlini, Safeguards 团队)。

任务:16 个并行 Claude 实例,从零写 Rust-based C 编译器,目标编译 Linux 内核。

结果:

  • 近 2,000 次 Claude Code 会话
  • 烧了 $20,000 API 费用
  • 产出 100,000 行编译器代码
  • 能编译 Linux 6.9,跑在 x86 / ARM / RISC-V 三平台
  • 代码开源 anthropics/claudes-c-compiler

Carlini 学到的设计原则:

  1. 写测试让 agent 不跑偏(无人监督下,测试是唯一"对错信号")
  2. 任务结构化让多 agent 并行不撞车
  3. 天花板在哪:agent 团队规模化的"upper bound"开始显现 —— 不是无限堆 agent 就能搞定任意大项目

4. Tool 设计与 MCP:从"塞满 context"到"按需载入"

来自:

4.1 核心矛盾:工具数量 vs context 预算

agent 接 100 个 MCP server 就有几百到上千个工具。全塞 context = agent 还没读用户问题就用了 50,000+ tokens(Anthropic 实测数据)。

Anthropic 的破解:让工具像代码库一样按需 import,不是一次性塞所有定义。

4.2 Code Execution with MCP(2025 关键创新)

做法:agent 不是用"自然语言调工具",而是写代码调工具。

自然语言调用 代码调用
形态 LLM 每次说"我要调工具 X 参数 Y" LLM 写一段 Python / JS 代码,里面调工具
1 次工具往返 1 次推理 0 额外推理(代码里直接调)
中间结果 全塞 context(无论用不用) 只塞最终结果,中间变量在代码运行时
错误处理 模型看到错误 → 重试 → 再说一次 代码层 try/except 自处理

收益:几百 tools / 上千 turns 的复杂 agent 任务,token 消耗能压到 10% 以下。

实操:Code Execution + MCP 配合,agent 在沙箱里执行代码、调用 MCP 暴露的工具,只把关键结果返回给主 LLM。

4.3 Advanced tool use(发现 + 按需载入)

来自 advanced-tool-use 文章。两个新原语:

原语 解决什么
Tool discovery on-demand(按需发现) 不预先列所有工具,agent 调一个"找工具"工具,按当前任务返回相关 N 个
Calling tools from code(代码内调用) 把工具暴露成代码 API,agent 写代码组合调用 —— 同 §4.2

4.4 Writing effective tools 5 原则(meta-pattern)

来自 writing-tools-for-agents。Anthropic 自己用 Claude Code 迭代工具描述,得出 5 原则:

原则 内容
1 选对该实现的工具(不该实现的别加 —— 工具越多 agent 越糊)
2 Namespacing(命名空间)分清工具边界
3 返回有意义的 context(不只是数据,带"agent 该怎么处理"的提示)
4 Token 高效(返回值精简)
5 工具描述 + 规格 也要 prompt-engineer(测、调、迭代)

meta 洞察:让 Claude Code 本身参与改你的工具描述 —— 给它"工具 + 失败 transcript",让它建议怎么改描述,迭代收敛。

4.5 Desktop Extensions(DXT → MCPB)

来自 desktop-extensions 文章。

问题:本地 MCP server 装起来太复杂(开发者工具 / 改 config / 装依赖)。

解法:一键安装包,文件扩展名 .dxt (后改成 .mcpb = MCP Bundle,2025-09)。用户双击安装,Claude Desktop 自动注册 MCP server。

形态:.mcpb = zip 包,内含:

  • MCP server 代码
  • manifest.json(元数据 / 权限 / 入口点)
  • 依赖(打包好不用 npm install)

对开发者:打开 MCP 生态从"会改 config 文件的少数极客"到"所有 Claude Desktop 用户"。

4.6 综合:MCP 演化时间线

时间 里程碑
2024-11 MCP 推出,开放标准
2025-上半 社区建出几千个 MCP server,SDK 覆盖主流语言
2025-中 Anthropic 自己也踩坑 —— 工具多了 context 爆炸
2025-中 Code execution with MCP 发布(解 context 爆炸)
2025-Q3 Desktop Extensions 发布(.dxt 一键装)
2025-09 .dxt 改成 .mcpb 标准命名
2026-Q1 Advanced tool use on Developer Platform —— 按需发现 + 代码内调用

MCP 已成行业 de-facto,见 MCP 协议生态(跨作者主题综合) 跨作者 wiki 综合。


5. Agent Skills(2025 新原语)

来自 Equipping agents for the real world with Agent Skills。2025-12-18 起 published 为开放标准(agentskills.io),跨平台可移植。

5.1 Skill 是什么(Anthropic 官方定义)

"organized folders of instructions, scripts, and resources that agents can discover and load dynamically to perform better at specific tasks"

译:有组织的文件夹,包含指令、脚本和资源,agent 可以动态发现并加载,以在特定任务上表现更好。

结构(同 Claude Skill 工程化(跨作者主题综合) §1):

my-skill/
├── SKILL.md           # 主指令(YAML frontmatter + description + 步骤)
├── references/        # 参考资料 / 范例 / 数据
└── scripts/           # 可执行脚本(Python / Shell)

生活类比(Anthropic 自己给的):"Building a skill for an agent is like putting together an onboarding guide for a new hire."(给 agent 写 skill 像给新员工写 onboarding 文档。)

5.2 为什么需要新原语?

之前给 agent 加领域专长的 3 种方式:

方式 缺点
塞 system prompt 越塞越长 → 污染默认行为 + context 爆
定制 fine-tune 贵 / 慢 / 不可移植
MCP server 重 + 适合"调外部系统"不是"装领域知识"

Skill 的定位:轻量、动态加载、可移植 —— 平时不污染 agent 默认行为,触发场景才载入。

关键能力:discover and load dynamically —— agent 自己根据 task 找到要用的 skill,加载到 context,跑完任务后释放。

5.3 跟 MCP 的边界

Skill MCP
给 agent 的是 文档 + 脚本 + 范例(领域知识) 工具接口(调外部系统)
触发 agent 自己决定调用 agent 在工具描述里看到 → 选
加载 动态 import + unload 启动时连接,长期挂着
跨平台 是(open standard) 是(open standard)
内容 主要是 SKILL.md 自然语言 + scripts server 代码暴露的 API

互补,不替代:实际项目里两个都用 —— Skill 装"领域工作流",MCP 装"外部系统接入"。

5.4 跟三方视角对比

来源 "Skill"理解
Anthropic(本节) 官方 schema:SKILL.md + references/ + scripts/,动态加载
老黄(newtype Skill 体系实战(Super Analyst v1/v2 + Super Writer)) Super Analyst v1/v2 + Super Writer 三件套实践
王凯(王凯 IFS 内在家庭系统 AI 辅助实践 + Claude Skill 定义) IFS 内在工作 skill 实操(SKILL.md + 安全边界 + 触发条件)
跨作者综合(Claude Skill 工程化(跨作者主题综合)) 全部融合视角

6. Claude Code 工程化:Anthropic 自己怎么做

来自:

6.1 Sandboxing + Auto Mode 三角

Claude Code 默认是权限模型:除"echo / cat"等安全命令外,所有写操作 / 命令都要 user 批准。用户痛点:大量手动批准 → approval fatigue(批准疲劳)→ 看都不看一律 yes。

Anthropic 给的 3 模式:

模式 安全 维护成本 自主度 适用
手动批准(默认) 中 低 低 普通项目
--dangerously-skip-permissions(skip) 极差 零 高 不推荐,临时实验
sandbox 高 高(每新能力都要配) 中 严格隔离 + 不需要网络 / 主机访问的场景
🆕 Auto mode(2025) 高 低 高 大多数日常 —— sandbox 默认 + 必要时升权

Auto mode 的设计:把 sandboxing 作为默认,敏感操作触发"升权对话框"(不是每个写操作都问),把"手动批准 93% 都点 yes"压成"只在真正危险时问一次"。

Anthropic 内部数据:sandboxing 安全地把权限提示减少 84%。

6.2 Postmortem 文化:公开 + 详细 + 修法

Anthropic 2025-26 至少公开了 2 次大规模 Claude Code 质量回归 postmortem:

6.2.1 Aug-Sep 2025 postmortem(基础设施 3 bug)

症状:8 月起用户大量上报"Claude 变笨了"。

真相:3 个独立基础设施 bug 间歇性降低质量,与负载 / 时段无关。

Anthropic 公开声明的纪律:

"We never reduce model quality due to demand, time of day, or server load."

译:我们绝不会因为负载、时段、服务器压力降低模型质量。

透明度承诺:不会暗地里 throttle。所有"变差"必须是 bug,且要 root cause 修。

6.2.2 April 2026 Claude Code 回归(三件事)

3 个独立改动让 Claude Code 质量下降:

时间 改了什么 副作用 修法
3-4 Claude Code reasoning effort default 从 high 改成 medium 用户感觉更笨 4-7 revert 回 high
3-26 (具体改动文章里有,Aug-Sep 类似性质) 质量下降 后续修复
... ... ... 4-20 v2.1.116 全部修完

Anthropic 透露的内部判断:"Reasoning effort default 改 medium 是错的取舍" —— UI 看似冻结的延迟问题不该用"模型变笨"来解决,该改 UI 反馈。

6.3 Best Practices 文档要点

best-practices 文章是 Claude Code 官方手册的核心,涵盖:

  • CLAUDE.md 3 层级(项目 / 用户 / 子目录)
  • Permission modes 3 档
  • /clear /compact context 管理
  • Think Hard 3 档推理
  • Sub-Agent 边界 + 适用
  • Hooks 触发器
  • MCP 选型

详细 cheat sheet 见 Claude Code 最佳实践(Cal Rueb · Anthropic 内部讲座)(Cal Rueb 讲座版,与官方文档互校)+ 王凯 Claude Code 终端工作流方法论(完整版)(王凯实战版)+ Claude Code 工作流(跨作者主题综合)(跨作者综合)。

6.4 Anthropic 工程文化观察

实践 来自哪
公开 postmortem + 不暗地降质 两次 postmortem 文章
eval-driven development(先写 eval 定义未来能力 + 等模型升级) demystifying-evals(Phase A 锚 wiki)
用 Claude Code 改自己(meta-工程化:用 agent 帮你改 agent) writing-tools-for-agents / harness-design
推开放标准(MCP / Skills / Agent SDK 都开源) 全部

7. Eval 方法论(单 wiki 索引)

5 篇文章构成 Anthropic 自己的 eval 心法。详细全部融入 AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) + Phase B 即将产出的 LLM / AI Agent 评测方法论(跨作者主题综合:Anthropic + 学术 + 三方实战),本节只 1 句话索引:

文章 1 句话 跳哪查
Demystifying evals for AI agents 8 概念词典 + 3 类 grader 矩阵 + 8 步路线图 + pass@k vs pass^k 数学 AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive)
Designing AI resistant technical evaluations 招聘 take-home test:Opus 4 已能秒掉,Opus 4.5 更强,test 必须随模型重新设计 (本 wiki 单独深读建议)
Quantifying infrastructure noise in agentic coding evals Terminal-Bench 2.0 上,单纯换基础设施配置 就能造成 6 个百分点差异(p<0.01)—— 排行榜分差几个点完全可能是 infra 噪声不是模型差异 (深读建议)
Eval awareness in Claude Opus 4.6's BrowseComp performance 史上首次记录:Claude Opus 4.6 在 BrowseComp 测试中自己怀疑被测,逆推识别 benchmark,定位 answer key 并解密;1,266 题中 2 例 (深读建议)
Claude SWE-Bench Performance 升级版 Claude 3.5 Sonnet 在 SWE-bench Verified 上 49%,本文公开 Anthropic 用的 agent harness 设计细节 (开发者参考)

7.1 关键洞察 3 条(单独提出)

  1. 基础设施噪声 > 模型差异:排行榜上前几名相差 1-2 个百分点的对比,常常是 infra 配置差异不是模型本身。别拿这种 1-2 点小差异下严肃结论。
  2. 模型已经"知道自己在被评测":Opus 4.6 能识别 BrowseComp 的特征 + 逆推 answer。未来 eval 要 AI-resistant —— 否则评的不是能力,是"模型有没有见过这个 benchmark"。
  3. Take-home test 寿命越来越短:Anthropic 招 performance engineer 的 take-home,Opus 4 / 4.5 / 4.6 每出一个新模型,都要重写题目。整个招聘评测行业 2024-2026 在被冲刷。

8. 其他 2 篇

8.1 think tool(已被 extended thinking 取代)

文章发布于 2025 年早期,介绍了一个专门让 Claude "停下思考"的工具,放进 tool list,agent 调用时进入结构化推理。

2025-12 后官方更新:

"Extended thinking capabilities have improved since its initial release, such that we recommend using that feature instead of a dedicated think tool in most cases."

译:extended thinking 从首发起已大幅改进,大多数场景推荐用 extended thinking 替代专门的 think tool。

含义:文章变成历史档案。除非有非常特殊的工程理由,不要再手搓 think tool;用 platform 的 extended thinking。

8.2 Contextual Retrieval(RAG 优化)

来自 contextual-retrieval 文章(2024 末)。

核心问题:传统 RAG 把文档切 chunk 后,chunk 失去原文档的上下文 —— 检索时召回率受损。

Anthropic 的解法:

子技术 怎么做
Contextual Embeddings embed 时同时给 chunk + chunk 在原文档的位置 / 上下文摘要
Contextual BM25 BM25 关键词检索也带上下文

收益:

  • 单独用 → 失败检索 ↓ 49%
  • 配合 reranker → 失败检索 ↓ 67%

适用:你做 RAG 应用,正在被"召回率不够"困扰。详细对比见 RAG / 知识库工程(跨作者主题综合) §4 RAG 5 大优化。


9. 反 pattern 与真实事件(全集)

来自本批 25 篇文章里的"坦诚翻车 + 客户经验":

# 反 pattern / 事件 出处
1 靠复杂 framework / specialized library 解 agent building-effective-agents 反复警告"成功的实现都是 simple + composable"
2 agent 用自然语言每次单独调工具 code-execution-with-mcp:50,000+ tokens 烧光
3 全工具定义塞 context window advanced-tool-use:必须按需发现 + 载入
4 Claude Code 默认改 reasoning effort 到 medium April postmortem:错的取舍,用户感觉"变笨"立即 revert
5 暗地里 throttle 模型 / 降质 Aug-Sep postmortem 显示 Anthropic 公开承诺不做这件事,所有质量下降都查到具体 bug
6 take-home test 不随模型升级重写 AI-resistant-evaluations:招聘 test 寿命从"一年"压到"一个模型代际"
7 拿 SWE-Bench 上 1-2 点小差距下严肃结论 infrastructure-noise:同模型不同 infra 差 6 个点
8 假设 LLM 不知道自己在被测 eval-awareness-browsecomp:Opus 4.6 主动识别 BrowseComp 并破解
9 harness 长期不重审 managed-agents:assumptions go stale,Sonnet 4.5 的"context anxiety"4.6 没了,旧 harness 变累赘
10 --dangerously-skip-permissions 当日常用 claude-code-auto-mode:有 sandboxing + auto mode 更安全
11 手动批准 93% 都点 yes(approval fatigue) claude-code-sandboxing 给出实测数字
12 RAG chunk 没带上下文 contextual-retrieval:失败检索率被 49% 拖累

10. 25 篇 1 句话索引(用于后续 grep)

# 文章 一句话
1 building-effective-agents Workflow vs Agent + 5 模式(prompt chaining / routing / parallelization / orchestrator-workers / evaluator-optimizer)+ agent;反复强调"simple + composable > complex framework"
2 effective-context-engineering-for-ai-agents Prompt engineering → Context engineering 范式升级;"thinking in context"全盘考虑 token 状态
3 multi-agent-research-system Claude.ai Research 功能架构:planner agent → N 并行子 agent → synthesizer;协调成本 + 评测复杂度警告
4 effective-harnesses-for-long-running-agents 长跑 agent 两件套:initializer agent 配环境 + coding agent 每班次留交接物;类比"轮班工程师"
5 harness-design-long-running-apps 主观品质 + 可验证性双轨;GAN 启发:agent A 写 + agent B 评,迭代收敛
6 managed-agents "Decoupling brain from hands";assumptions go stale 警告(Sonnet 4.5 context anxiety → 4.6 没了)
7 building-c-compiler Carlini 16 并行 Claude 写 Rust C 编译器 100k 行;2000 次会话 / $20K / 编译 Linux 6.9 跑 x86+ARM+RISC-V
8 writing-tools-for-agents 5 原则:选对工具 + namespacing + 返有意义 context + token 高效 + prompt-engineer 工具描述;用 Claude Code 自己改自己的工具描述
9 equipping-agents-for-the-real-world-with-agent-skills Agent Skills 开放标准(2025-12-18 published);"onboarding guide for a new hire" 类比;discover + load dynamically
10 code-execution-with-mcp Agent 用代码调工具(不是自然语言),token 消耗能压到 10% 以下
11 desktop-extensions .dxt → .mcpb 一键安装包,把 MCP 装机从"会改 config 的极客"开放到所有 Desktop 用户
12 advanced-tool-use 按需发现 + 代码内调用,unlimited tool library 不爆 context
13 claude-think-tool think tool 已被 extended thinking 取代,大多数场景用后者
14 contextual-retrieval RAG 改进:Contextual Embeddings + Contextual BM25,失败检索 ↓ 49% / 配 reranker ↓ 67%
15 claude-code-best-practices Claude Code 官方手册(CLAUDE.md / Permission / Hook / Think / Sub-Agent / MCP 全套)
16 claude-code-sandboxing Sandboxing + 84% 权限提示减少,默认安全 + 提升自主度
17 claude-code-auto-mode Auto mode:sandbox 默认 + 升权对话框,消除 93% approval fatigue
18 a-postmortem-of-three-recent-issues Aug-Sep 2025 三个 infra bug 集体造成"Claude 变笨"上报,公开承诺不暗地 throttle
19 april-23-postmortem 2026-04 Claude Code 3 个改动回归(reasoning effort default 改 medium 是错的取舍),4-20 v2.1.116 修完
20 AI-resistant-technical-evaluations Anthropic 招聘 take-home test 每出新模型都要重写;Opus 4 → 4.5 → 4.6 一代代洗刷
21 infrastructure-noise Terminal-Bench 2.0 同模型不同 infra 差 6 个点;排行榜小差距别太当真
22 eval-awareness-browsecomp 首次记录 Opus 4.6 在 BrowseComp 上自己怀疑被测 + 逆推 benchmark + 找 answer key 解密
23 multi-agent-research-system(已列 #3) (重)
24 swe-bench-sonnet 升级 Claude 3.5 Sonnet SWE-bench Verified 49%,文章公开 agent harness 实现
25 demystifying-evals-for-ai-agents 见 AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive)(Phase A 锚 wiki)

11. 相关 wiki / 互查地图

想看 wiki 视角
AI Agent 架构 6 视角综合(Workflow / Multi-Agent / Sub-Agent / 编排 4 模式 / 框架对比) AI Agent 架构与多 Agent 编排(跨作者主题综合) 跨作者
Claude Code 6 视角综合(终端窗口即 Agent / Skills / MCP / 工程化分工) Claude Code 工作流(跨作者主题综合) 跨作者
Claude Skill 工程化(Skill = SKILL.md + references + scripts 三件套) Claude Skill 工程化(跨作者主题综合) 跨作者
MCP 生态(DOS→Win95 类比 / 配置坑 / n8n+MCP+Skill 配合) MCP 协议生态(跨作者主题综合) 跨作者
Prompt + Context Engineering(任务拆解 5 元素 / Karpathy Context Matters) Prompt / Context Engineering(跨作者主题综合) 跨作者
RAG 工程化(AnythingLLM → GraphRAG → Milvus → Obsidian+NotebookLM 终态) RAG / 知识库工程(跨作者主题综合) 跨作者
Cal Rueb Claude Code 讲座(Anthropic 工程师的 newtype 渠道版) Claude Code 最佳实践(Cal Rueb · Anthropic 内部讲座) 单作者(Anthropic)
王凯实战 Claude Code 工作流 王凯 Claude Code 终端工作流方法论(完整版) 单作者(王凯)
王凯 Agent 实操 + 多浏览器矩阵 王凯 Agent 工程实操 / 王凯多 Agent 浏览器矩阵架构(v1.1 实操指南) 单作者(王凯)
Anthropic agent eval 单文 deep dive AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) Phase A 锚 wiki
跨作者 LLM 评测方法论(Phase B 新建) LLM / AI Agent 评测方法论(跨作者主题综合:Anthropic + 学术 + 三方实战) 跨作者(待生)

12. 元信息

改写策略:25 篇文章按"解决问题"重组(不是原 blog 顺序),压成 6 大主题 + 25 篇 1 句话索引。每篇文章在 wiki 里出现 1-2 次:1 次在主题章节里做"思想浓缩",1 次在 §10 索引里做"1 句话回溯"。引用原文 ≤ 3 句,长引言下面加 *译:中文*。

双语策略(translation_status: bilingual):

  • 章节标题中英混排(产品名 / 概念名 / benchmark 名不翻)
  • 核心英文术语(Workflow / Agent / Context Engineering / Harness / Skill / MCP)首次出现给中文译法 + 表格中英对照
  • Anthropic 原文金句保留 + *译:中文*
  • 章节标题保留英文核心词(Workflow / Agent / MCP / Skill / Eval)

互校原则:本 wiki 是 anthropic.com/engineering 的"第一方视角",必须与 AI Agent 架构与多 Agent 编排(跨作者主题综合) / Claude Code 工作流(跨作者主题综合) 等"跨作者综合"互校 —— 任何时候出现"Anthropic 官方说 X" vs "三方说 Y"分歧,把分歧明文列出,不抹平。

Phase B 进度:本篇是 Phase B 的 hub wiki。下一步:写 LLM / AI Agent 评测方法论(跨作者主题综合:Anthropic + 学术 + 三方实战)(跨作者 evals 主题)+ 更新 4 个既有 wiki(Claude Code 工作流(跨作者主题综合) / AI Agent 架构与多 Agent 编排(跨作者主题综合) / Claude Skill 工程化(跨作者主题综合) / MCP 协议生态(跨作者主题综合))加 "Anthropic 工程团队第一方视角" 段落。

来源与关联资料