Anthropic on 鬼哥的空间

Claude-Cookbooks 全景导航：被 README 藏起来的另一半

Sat, 18 Apr 2026 00:00:00 +0000

最近 AI 的发展真的是日行千里。

每天打开手机开源社区、翻公众号、过一遍 GitHub Trending——新模型、新工具、新系统、新应用，再加上无数业内高人分享的实践经验，内容浩如烟海，百家争鸣，百家齐放。

说实话，我自己看着都眼花缭乱。有时候晚上躺下想到"今天又没来得及看那几篇论文、那几个新项目"，连睡觉都觉得是在浪费学习时间。

这种状态持续久了，人是会焦虑的。鬼哥每天拼命学习, 拼命实践, 都快忘了自己还是个吉他手, 也得花时间练琴了.

但前阵子我沉下心来，花了一段时间认真翻了一遍 Anthropic 官方的这份 claude-cookbooks——翻完之后我反倒松了一口气。

这份仓库里的内容，积累了 Anthropic 工程师过去三年对 AI 工程化的思考。覆盖面非常全：从 API 最基础的用法，到 Prompt Caching 的成本优化，到 Tool Use 的各种进阶模式，再到 Agent SDK、Managed Agents、Skills 这些最近才成型的产品形态——几乎把"怎么用好 Claude 做一个能上生产的 AI 应用"这件事，从头到尾挨个讲了一遍。

宝藏是真的多，内容也真的多。想用一两篇文章讲清楚根本不现实。

所以我决定先写这一篇——给这份指南做一个大致的梳理，整理出一份索引地图。 后面每个具体话题，再单独开长文展开。

也建议你把这份 cookbook 当作一份可以反复查、反复学的学习地图：不需要一次读完，但值得在接下来几个月里反复回来翻。

你打开 anthropics/claude-cookbooks 的 README，看到的大概是十几条链接——分类、RAG、摘要、几个 tool use 示例、一篇 prompt caching。

如果你只看 README，会以为这就是一份写了两年没人管的老项目。

但你往目录里翻一下就会发现——这份仓库里塞着接近一百篇 notebook，README 里能看到的，大概只占三分之一。

被 README 藏起来的另一半，恰恰是这两年 Anthropic 官方重点推进的东西：Claude Agent SDK 教程、Managed Agents 的 CMA 系列、Skills 技能包、Tool Use 的进阶玩法、Extended Thinking 和 Tool Search 的新模式……这些内容散落在 claude_agent_sdk/、managed_agents/、skills/、patterns/agents/ 这些 README 完全没提的目录下。

这篇文章做的事很简单：把这份 repo 按主题重新整理成一张可以反复查的索引地图。 每个模块一句话定位、列出具体 notebook 文件名、说清楚什么时候该看它——后面想逐篇深入的时候，翻这一页就知道从哪下手。

不做深度拆解，只做导航。真正的"为什么要这么设计"那种长文，留给后面每个主题单开一篇来写。

一、先把这份 repo 的定位搞清楚

在往下看之前，先明确一件事：claude-cookbooks 不是文档的补充，而是可跑的工程示例库。

Anthropic 官方的内容资源现在大致分成三层：

资源	角色	面向
docs.claude.com	权威文档	查 API 参数、模型特性
anthropics/courses	入门课程	第一次接触 API 的开发者
anthropics/claude-cookbooks	工程菜谱	已经会调 API、想把某个具体场景做好的人

Cookbook 是"可执行的最佳实践"：每个 notebook 就是一个最小可跑的场景，装完依赖、填上 API key 就能复现。它的价值不在于"教你 Claude 是什么"，而在于"别人做过这件事，代码给你抄走"。

换句话说，文档告诉你某个 API 参数是什么意思，cookbook 告诉你在真实场景里这个参数应该怎么配、还要和哪几件事配合用。这两者是互补的——文档适合查细节，cookbook 适合找套路。

这也解释了为什么它的更新节奏跟着 Anthropic 的产品线走——每出一个新产品或新能力，这里就会多一个目录。Claude Agent SDK 发布之后有了 claude_agent_sdk/，Managed Agents 发布之后有了 managed_agents/，Skills 功能上线之后有了 skills/。所以它也是观察 Anthropic 官方工程重点转向的一个风向标。

一个小提醒：README 里的链接还是旧的 anthropic-cookbook 仓库路径（目录名对，仓库名已改成 claude-cookbooks）。clone 的时候用新名字，跟着链接点进去会被 GitHub 自动重定向，不影响看内容，但会让你怀疑自己是不是 clone 错了库。

二、一张总览图：20 多个目录怎么归类

仓库里大大小小二十多个目录，我按"使用场景"把它们重新归了一下组：

大类	涉及目录	解决的问题
基础能力	`capabilities/` `multimodal/` `extended_thinking/`	Claude API 开箱即用能做的事
Tool Use	`tool_use/`	让模型调用外部工具
性能与成本	`misc/`（caching/batch 部分） `observability/`	Prompt caching、批处理、用量监控
Agent 三条路径	`patterns/agents/` `claude_agent_sdk/` `managed_agents/`	从模式→SDK→托管运行时的递进
Skills 技能包	`skills/`	打包专业能力给 Claude 调用
第三方集成	`third_party/`	Pinecone / Voyage / Mongo / Wolfram 等八家
评估与微调	`tool_evaluation/` `finetuning/` `misc/building_evals.ipynb`	Prompt eval、工具 eval、Bedrock 微调
工程实践（meta）	整个仓库的组织方式	uv / ruff / registry / slash commands

接下来按这个骨架一层层往里翻。

三、基础能力层：Claude API 开箱即用能做什么

3.1 `capabilities/` — 经典的 NLP 任务

这是整个 cookbook 里最"传统"的一块，也是大部分教程会从这里开始的原因——这些任务不依赖任何高级特性，一个 API key 就能跑：

classification/ — 文本分类。几个 prompt 模式对比，从 zero-shot 到 few-shot 到带 chain-of-thought 的长 prompt。
summarization/ — 摘要。包括长文分块摘要、多文档合并摘要、以及"按角色视角写摘要"这种进阶玩法。
retrieval_augmented_generation/ — RAG。从最基础的"向量检索 + 拼 prompt"到带 rerank、混合检索的几种设计。
contextual-embeddings/ — 这是比较新的一篇，讲 Anthropic 自己提出的"给每个 chunk 加一段上下文描述再 embed"的做法，在某些场景上能显著提升召回。
text_to_sql/ — 自然语言转 SQL，包括 schema 注入、错误恢复、结果校验。
knowledge_graph/ — 用 Claude 从文本抽取三元组、构建图谱。

如果你是刚开始用 Claude API 做项目，这块是"背景知识"——不是每篇都要精读，但至少扫一遍标题，知道什么场景能在这里找到参考实现。

contextual-embeddings/ 这篇值得单独提一下。传统 RAG 的 embedding 过程是直接把 chunk 扔进 embedding 模型，但很多 chunk 脱离上下文后其实没法检索——比如一段"它在第三季度增长了 12%"，没有"哪家公司 / 哪个产品"的上下文，embedding 向量就很泛。Anthropic 的做法是先用 Claude 给每个 chunk 生成一段上下文描述（“这段来自 XXX 公司 2024 Q3 财报的营收章节”），再和原文拼在一起去 embed。实测在有些场景上能把召回率提升 35% 以上，代价是 embedding 阶段的 prompt caching 必须做好，不然成本会飙。

3.2 `multimodal/` — 视觉能力

Claude 的 vision 能力现在已经是基础配置，这个目录把"怎么用好它"讲了一圈：

getting_started_with_vision.ipynb — 入门。base64 编码、URL 传图、多图一起传的几种姿势。
best_practices_for_vision.ipynb — 最佳实践。图片放在 prompt 的哪个位置、多图之间怎么编号、什么时候该先 OCR 再喂文字。
reading_charts_graphs_powerpoints.ipynb — 图表解读。财报柱状图、流程图、PPT 截图的实战。
how_to_transcribe_text.ipynb — 表单/手写稿 OCR。
crop_tool.ipynb — 让 Claude 自己决定"先裁图再看细节"的分步处理。
using_sub_agents.ipynb — 用 Haiku 做前置视觉处理，Opus 做最终决策的 sub-agent 模式。

3.3 `extended_thinking/` — 让模型"想得更久"

Extended Thinking 是 Claude 4 系列引入的能力，让模型在给出答案前先做一段内部推理：

extended_thinking.ipynb — 基础用法。怎么打开、thinking budget 怎么设、拿到的 thinking block 长什么样。
extended_thinking_with_tool_use.ipynb — 和 tool use 结合。这个组合比较微妙——model 在 tool call 之间保留 thinking context 的方式跟普通对话不一样，这一篇讲清楚了边界。

四、Tool Use 专题：整个 cookbook 最密的一块

tool_use/ 目录是更新最频繁、内容也最厚的一块。里面的 notebook 粗粗可以分成"基础用法"和"进阶玩法"两层：

基础几篇，先过一遍：

calculator_tool.ipynb — 第一次接触 tool use 必看，一个最简单的计算器示例。
tool_choice.ipynb — auto / any / tool（强制某个具体工具）三种模式的区别。
parallel_tools.ipynb — 一次响应里并发调多个工具。
extracting_structured_json.ipynb — 用 tool use 强制返回结构化 JSON，比裸 prompt 稳定得多。
tool_use_with_pydantic.ipynb — 直接用 Pydantic 模型定义 tool schema。
customer_service_agent.ipynb — 经典的客服机器人综合示例。

进阶部分，每篇都是一个独立课题：

memory_cookbook.ipynb + memory_tool.py — Claude 的 memory tool，让模型能读写自己的记忆文件。
programmatic_tool_calling_ptc.ipynb — PTC（Programmatic Tool Calling）。让 Claude 生成一段小代码来决定怎么调用一组工具，而不是一个个手动编排。
automatic-context-compaction.ipynb — 自动上下文压缩。长对话里如何在触发上限前让模型自己"总结前面然后丢掉"。这一篇和我之前写过的 Session 管理文章其实是同一套思路的底层实现。
tool_search_with_embeddings.ipynb + tool_search_alternate_approaches.ipynb — 工具太多塞不进 prompt 的时候怎么办。用 embedding 召回最相关的工具再喂给模型。
vision_with_tools.ipynb — 把 vision 输入和 tool use 混在一起用的注意事项。
threat_intel_enrichment_agent.ipynb — 威胁情报富化 Agent，一个比较完整的垂直场景实战。
context_engineering/ 子目录 — 专门讲上下文工程的一组 notebook，是相对独立的小专题。

这个目录是我个人会反复回来查的。基本上做任何一个需要"让模型调用外部能力"的项目，都能在这里找到至少一个相近的参考实现。

特别想点名 PTC 和 Tool Search 这两篇。 PTC（Programmatic Tool Calling）解决的是"工具编排逻辑比工具本身还复杂"的场景——比如你有 10 个工具需要按特定顺序调用并做中间结果处理，与其让模型一轮一轮 tool call，不如让它一次性生成一段编排代码，由你在沙箱里执行。这种做法在复杂工作流里能把 round-trip 次数从十几轮压到两三轮，延迟和成本都是数量级的改善。

Tool Search 解决的是另一类问题：工具数量多到塞不进 prompt。一个大型 Agent 系统可能挂了几百个 MCP 工具，全部塞进去既超 token 又污染模型判断。用 embedding 预先对工具做语义索引，按用户 query 召回 top-K 工具再喂给模型，是目前比较成熟的解法。这一篇讲清楚了实现细节和几种 trade-off。

五、性能与成本优化

做 Demo 的时候钱和速度都不敏感，但一旦到线上，成本和延迟立刻就会成为第一优先级问题。 这块内容散落在几个目录里，我挑出来单独放一节：

misc/prompt_caching.ipynb — Prompt caching 的基础用法。配合我之前那篇 Prompt Caching 深度拆解一起看效果最好：那篇讲"为什么要这么做"和底层 KV cache 原理，这篇告诉你"具体几行代码怎么写"。
misc/speculative_prompt_caching.ipynb — 推测式缓存。不等用户发消息，提前把可能的下一轮 prompt 预热进缓存。在某些低延迟场景下能把首 token 延迟打下去很多。
misc/batch_processing.ipynb — Message Batches API。离线批处理的价格是实时请求的 50%，跑评测、做回填数据时能省很多。
misc/session_memory_compaction.ipynb — 会话记忆压缩。和 tool use 里的 automatic-context-compaction 是配套关系，一个讲工具侧，一个讲消息侧。
observability/usage_cost_api.ipynb — Usage & Cost API。用来做团队用量看板、成本归因报表。
misc/using_citations.ipynb — Citations 功能。让 Claude 在回答里标注"这句话来自文档的哪一段"，做 RAG 产品时非常有用。
misc/sampling_past_max_tokens.ipynb — 当输出被 max_tokens 截断时怎么优雅续写。

这几篇单独看每一个都不长，但组合起来基本就是一个"线上项目优化清单"。上线前对着这张清单过一遍，能省下不少成本和踩坑时间。

有一个非常容易被忽略的组合用法：prompt caching + batch processing。Batch API 本身就打 5 折，再加上 caching 命中的部分又打 1 折左右，叠加下来做离线大规模推理时的成本可以比天真实现低 85% 以上。如果你在做评估、数据标注、回填历史数据这类离线任务，这个组合的经济性优势非常大，但大多数人做 MVP 时根本不会想到要用它。

六、Agent 的三条进阶路径

这是整个 cookbook 里我认为最值得花时间的一块，也是 README 最没讲清楚的一块。

Anthropic 把"怎么构建 Agent"拆成了三个层次递进的目录：

1
2
3


patterns/agents/ ← 模式层：概念和套路（轻量）
claude_agent_sdk/ ← SDK 层：用 Agent SDK 自己组装（中等）
managed_agents/ ← 托管层：用 Managed Agents 托管运行时（重型）

从左到右是"自由度递减、工程量递减"的关系。 哪一层适合你，取决于你要做的系统规模和运行需求。

6.1 模式层 `patterns/agents/` — 先把套路搞清楚

这个目录对应的是 Anthropic 那篇著名博客 Building Effective Agents 里提的几种基础模式的可运行版本：

basic_workflows.ipynb — Prompt chaining / Routing / Parallelization 三种基础工作流模式。
evaluator_optimizer.ipynb — 评估者-优化者模式。一个 Agent 输出、另一个 Agent 打分并反馈，循环到满足条件为止。
orchestrator_workers.ipynb — 编排者-工人模式。主 Agent 拆任务，子 Agent 并发执行。

这三篇是"概念打底"。哪怕你最后不用 Agent SDK，看一遍这三个模式，再去评估任何第三方 Agent 框架的设计，心里都会有一把尺子。

6.2 SDK 层 `claude_agent_sdk/` — 官方的 Agent 教程

这是 Anthropic 最近重点推进的一块，基于 claude-agent-sdk-python，六篇 notebook 是一条渐进式的教学路径：

#	文件	学到什么
00	`00_The_one_liner_research_agent.ipynb`	一行 `query()` 起一个研究 Agent，理解异步迭代和基础概念
01	`01_The_chief_of_staff_agent.ipynb`	CEO 助理 Agent——Memory、Output Styles、Plan Mode、Slash Commands、Hooks、子 Agent 编排全家桶
02	`02_The_observability_agent.ipynb`	可观测性 Agent，需要 GitHub Token + Docker
03	`03_The_site_reliability_agent.ipynb`	SRE Agent，处理告警和事故
04	`04_migrating_from_openai_agents_sdk.ipynb`	从 OpenAI Agents SDK 迁移过来的映射指南——有存量代码的团队重点看这篇
05	`05_Building_a_session_browser.ipynb`	Session 浏览器 demo，可视化 Agent 会话

这一条路径的隐含逻辑是：“你如果已经在用 Claude Code，那 Claude Code 背后的 Agent 内核就是 Agent SDK，你可以用同样的工具链做任何 Agent 应用，而不只是软件开发”。

01 这篇 Chief of Staff 我单独推荐——它是整个教程里最接近"生产级 Agent 到底长什么样"的那篇。里面把持久化记忆（CLAUDE.md 机制）、输出风格切换（给 CEO 发邮件 vs 给团队发内部备忘是两种语气）、Plan Mode（复杂任务先产出方案再执行）、Slash Commands（把高频操作做成可复用快捷方式）、Hooks（每次工具调用都自动写审计日志）、Subagent 编排（法务/财务/战略三个专项 Agent 分工协作）这一整套都串起来了。看完之后你会意识到，“Agent” 这个概念背后其实是一组工程约束的组合，单独拎出任何一个都不够，组合起来才是真正可以上生产的东西。

6.3 托管层 `managed_agents/` — Claude Managed Agents (CMA)

Managed Agents 是 Anthropic 相对较新的一个产品形态：服务端托管的 Agent 运行时，带沙箱、会话持久化、文件状态保留，你只要定义 Agent 和环境，剩下的交给托管服务。

这个目录分成两组：

三个应用型示例（适合先看，建立直觉）：

data_analyst_agent.ipynb — CSV 进、HTML 分析报告出的数据分析 Agent。
slack_data_bot.ipynb — 把上面那个分析 Agent 包成 Slack Bot。
sre_incident_responder.ipynb — 告警→调查→PR→人审→合并的完整 SRE 流程。

六个教程型 notebook（以 CMA_ 开头，建议按顺序读）：

Notebook	主题
`CMA_iterate_fix_failing_tests.ipynb`	入门。引入 agent / environment / session、文件挂载、流式事件循环
`CMA_orchestrate_issue_to_pr.ipynb`	issue → 修复 → PR → CI → 人审 → 合并的完整编排
`CMA_explore_unfamiliar_codebase.ipynb`	在陌生代码库里探索，含"过期文档陷阱"演示
`CMA_gate_human_in_the_loop.ipynb`	人类审批关卡，用自定义工具的 `decide()` / `escalate()` 模式
`CMA_prompt_versioning_and_rollback.ipynb`	提示词版本化与回滚——生产 Agent 的脆弱环节，中文圈讲得很少
`CMA_operate_in_production.ipynb`	生产部署：MCP 工具集、vault 存 per-user 凭证、webhook idle 模式

这一组是目前 cookbook 里最贴近"企业级 Agent 运营"的内容。如果你在做 B 端 Agent 产品，哪怕不用 Managed Agents，也强烈建议看一遍 prompt versioning 和 operate in production 这两篇——它们把"Agent 上线之后你还要做哪些事"讲得最清楚。

稍微展开一下 CMA_prompt_versioning_and_rollback.ipynb 为什么特别值得看：传统软件工程里代码改动有 Git、有 CI、有灰度发布，但 prompt 的改动目前很多团队还靠 Excel 或 Notion 维护。Prompt 不是代码但比代码更脆弱——同一个字改一下，模型行为可能完全变样。这篇 notebook 给出的答案是把 prompt 也纳入版本化体系：服务端存版本、每个 session 可以绑定到特定版本、用标注过的测试集做版本对比、发现回归可以按 session ID 批量回滚。这套工作流不依赖 Managed Agents 本身也能借鉴——核心思路是把 prompt 当成一等公民的配置来治理。

七、Skills 技能包

skills/ 目录对应的是 Claude 的 Skills 功能——打包好的"专业能力"，Claude 在需要的时候自动发现并加载。

核心理念是 Progressive Disclosure：技能定义不在每轮对话里都加载，只在模型判断"这个任务需要 Excel 能力"时才把 Excel skill 拉进来，从而节省 token。

这个目录下有三篇 notebook：

notebooks/01_skills_introduction.ipynb — 基础：加 beta header、创建第一个 Excel/PPT/PDF。
notebooks/02_skills_financial_applications.ipynb — 金融场景：投资组合报告、多格式工作流（CSV → Excel → PPT → PDF）。
notebooks/03_skills_custom_development.ipynb — 自定义 skill 开发：金融比率计算器、品牌指南 skill。

Skills 这个功能对应的是你在 Claude.ai 里看到的"Claude 帮你直接生成 Excel/PPT"那个能力。如果你想做类似的"让 Claude 产出真正可用的办公文档"的产品，这是唯一的官方路径。

Progressive Disclosure 这个机制值得单独理解一下。传统做法里，你要给模型扩展能力，通常是把所有工具定义、system prompt、知识都塞进每一轮对话——结果是你挂的能力越多，token 成本越高，而且大部分 token 根本用不上。Skills 的思路是把能力拆成有元数据的"技能包"，只在模型判断当前任务需要时才动态加载对应的代码和指令，本质上是一种 lazy loading + capability routing。这个设计思路在做大型 Agent 平台时非常关键，哪怕你不用 Skills 产品本身，理解它的机制对你设计自己的能力注入系统也有参考价值。

八、第三方集成一览

third_party/ 下有八家集成，都是最小可跑的对接示例：

目录	角色	典型场景
`Pinecone/`	向量数据库	RAG 召回
`VoyageAI/`	Embedding 模型	RAG、语义搜索
`MongoDB/`	文档数据库 + 向量搜索	一体化 RAG 后端
`LlamaIndex/`	RAG 框架	和 Claude 一起用的完整 pipeline
`Wikipedia/`	知识源	实时查询百科做事实补充
`WolframAlpha/`	计算/数学	精确数值计算、公式求解
`Deepgram/`	语音转文字	音频输入场景
`ElevenLabs/`	文字转语音	语音输出场景

这块适合按需查阅——你项目里用到哪家就去看哪篇，不需要通读。

九、评估与微调

这两块相对偏"工程化"，但一旦你开始做严肃点的 AI 产品就绕不过去：

misc/building_evals.ipynb — 自动化评估。用 Claude 当 judge 给自己的 prompt 打分。
misc/generate_test_cases.ipynb — 用 Claude 生成测试用例来做对抗性评估。
tool_evaluation/tool_evaluation.ipynb — 工具级评估。Agent 系统里每个 tool 调用是否正确、参数是否合理的专项评估。
misc/metaprompt.ipynb — Metaprompt：让 Claude 帮你写/优化 prompt。
misc/building_moderation_filter.ipynb — 用 Claude 搭内容审核过滤器。
finetuning/finetuning_on_bedrock.ipynb — 在 AWS Bedrock 上微调 Claude，附 datasets/ 示例数据。

微调这块目前官方只出了 Bedrock 路径的教程，直接从 Anthropic API 做 fine-tuning 目前还不是公开能力。

十、仓库工程实践：这本身就是一份"怎么管理 Notebook 项目"的样板

这一节是给另一类读者的——那些在自己团队里也要维护大量 notebook / 示例代码的工程师。

claude-cookbooks 这个 repo 本身的组织方式，其实是一份挺成熟的范本：

用 uv 做包管理。有 uv.lock 和 uv.toml，uv sync --all-extras 一键把所有依赖装齐。相比 pip install -r requirements.txt，速度快一个数量级，也更容易复现。
ruff 做 lint 和 format。行长 100、双引号。Notebook 里放宽了 E402（中间 import）、F811（重定义）、N803/N806（变量命名），这几条放宽对 notebook 写作很实用——Jupyter 里本来就会有大量这种"不优雅但可读"的写法。
pre-commit + Makefile + tox。make check / make fix / make test 三条命令覆盖日常。
registry.yaml + authors.yaml。每篇 notebook 在 registry.yaml 里登记标题、路径、作者、分类，方便后续站点化检索。这是一个很聪明的做法——内容和元数据分离，让 notebook 集合可以被当成一个可查询的数据库来对待。
.claude/ 目录 + 自定义 slash commands。/notebook-review（检查 notebook 质量）、/model-check（校验模型 ID 是不是用了非推荐的日期版本）、/link-review（检查死链）。这几个 slash command 既给人用，也给 CI 用。
lychee.toml。专门的死链检查配置，比自己手写正则靠谱。
CLAUDE.md 里写死模型 ID 规范。明确规定永远用非日期别名（如 claude-sonnet-4-6）而不是 claude-sonnet-4-6-20250514。这种小约定写在 CLAUDE.md 里，让 Claude Code 或其他 Agent 在写示例代码时不会跑偏。

这些细节如果你自己维护过一个 notebook 集合，应该能立刻 get 到它们的价值。我之前维护过几套内部示例代码，最大的痛点就是时间一长没人管，示例里的 API 调用方式和模型名全都过时了。claude-cookbooks 用 CI + slash command + 自动化校验把这件事从"靠人自觉"变成"靠流程保证"，是很值得抄的做法。

另一个细节是 registry.yaml 里每篇 notebook 都登记了分类标签和作者。这看起来只是一个 meta 索引文件，但它背后其实是一个内容运营思路：让示例集合既能被人读，也能被机器查询。未来如果要做一个"按类目筛选的交互式站点"或者"根据用户目标推荐 notebook 的 Agent"，registry.yaml 就是现成的数据源。把内容和元数据分开，永远比把元数据硬编码进 README 要更灵活。

十一、我接下来会按什么顺序往里钻

最后给自己留一份阅读路线图，也供参考：

如果你是第一次用 Claude API：

misc/prompt_caching.ipynb — 先把成本大头的底子打好
tool_use/calculator_tool.ipynb + tool_choice.ipynb — Tool use 基础
capabilities/retrieval_augmented_generation/ — 如果你要做 RAG
multimodal/getting_started_with_vision.ipynb — 如果涉及图像

如果你已经在用 Claude Code，想扩展到自定义 Agent：

patterns/agents/ 三篇 — 先把概念过一遍
claude_agent_sdk/00 → 01 → 04 — 沿着教程走
tool_use/memory_cookbook.ipynb + automatic-context-compaction.ipynb — 长会话 Agent 必备
managed_agents/CMA_operate_in_production.ipynb — 想上线再看这篇

如果你在做 B 端 Agent 产品：

managed_agents/ 全套六篇 CMA 教程
tool_evaluation/tool_evaluation.ipynb + misc/building_evals.ipynb — 评估不能缺
observability/usage_cost_api.ipynb — 成本监控
managed_agents/CMA_prompt_versioning_and_rollback.ipynb — 运营侧

结尾：这只是起点

写到这里回头看，这份 cookbook 里随便挑一个模块展开，都够单独写一篇长文：

Agent SDK 的六篇 notebook 值得一篇一篇拆，特别是 Chief of Staff 那篇里塞了一整套生产级 Agent 该有的能力
Managed Agents 这个新产品形态本身就值得一篇"它和 Agent SDK 到底什么区别"的分析
Tool Use 里的 PTC、Tool Search with Embeddings、Memory Tool 每一个单拿出来都能写一篇技术拆解
Skills 的 Progressive Disclosure 机制和它对 token 经济的影响，是个完整的专题
patterns/agents/ 对应的那三种设计模式，配合实际项目经验聊一聊会很有意思

这些我都打算一篇一篇写。这份导航文章就当是书签——以后每完成一篇深度拆解，就回来把对应的链接加上，让这里慢慢长成一张真正可用的学习路线图。

如果你也在看这份 cookbook，欢迎告诉我你最关心哪个模块，我排序的时候可以参考一下。

参考资料

anthropics/claude-cookbooks — 本文索引的主体
anthropics/claude-agent-sdk-python — Agent SDK 本体
anthropics/courses — 如果你还在更早的阶段，先看这个
Building Effective Agents — Anthropic 官方 Agent 设计方法论
Equipping agents for the real world with Skills — Skills 的设计理念

Claude Managed Agents：从聊天机器人到自主 Agent 的一步之遥

Thu, 09 Apr 2026 00:00:00 +0000

150 行代码就能造一个"数字分身"，但它只会聊天，不会做事。

如果它能帮你写代码、搜资料、跑脚本呢？

两个月前，我给博客做了一个 AI 数字分身——guige_avatar。访客点击右下角的聊天按钮，就能和"鬼哥"的 AI 分身聊技术、聊 AI、聊生活。

整个后端只有 150 行 JavaScript，部署在 Vercel 上，用的是 OpenAI 的 GPT-4.1-nano。它很轻量，也确实能用——但说实话，它只是一个穿了马甲的 Chat Completion API。

2026 年 4 月，Anthropic 推出了 Claude Managed Agents——一个托管式的 Agent 运行时平台。看完文档后我意识到：如果用 Managed Agents 重构鬼哥分身，它能从一个只会聊天的机器人，进化成一个真正能做事的自主 Agent。

本文就以这个真实案例为主线，带你理解 Managed Agents 到底是什么、能做什么、以及什么时候该用它。

一、手搓版：guige_avatar 架构剖析

先看看现在的数字分身长什么样。注意截图右下角那个小对话气泡——那就是访客与鬼哥 AI 分身聊天的入口。

1.1 整体架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


访客浏览器 Vercel Serverless
┌─────────────┐ POST ┌──────────────────┐ ┌─────────┐
│ 博客首页 │ ─────────→ │ api/chat.js │ ───→ │ OpenAI │
│ 聊天面板(JS) │ ←───────── │ (~150 行) │ ←─── │ API │
└─────────────┘ JSON │ │ └─────────┘
 │ ↓ fire-and-forget│
 │ Telegram 通知 │
 └──────────────────┘
 ↑
 data/persona.yaml
 (人设 YAML ~200行)

1.2 核心代码：就这么简单

后端的核心逻辑可以浓缩成这几步：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// 1. 加载人设 YAML → 构建 system prompt
const persona = yaml.load(fs.readFileSync('data/persona.yaml'));
const systemPrompt = buildSystemPrompt(persona);

// 2. 拼接历史（最多 10 轮）+ 当前消息
const messages = [
 { role: 'system', content: systemPrompt },
 ...history.slice(-10),
 { role: 'user', content: userMessage }
];

// 3. 一次 API 调用，返回结果
const response = await openai.chat.completions.create({
 model: 'gpt-4.1-nano',
 messages
});

没有 agent loop，没有工具调用，没有自主决策。每次请求就是一次单轮 LLM 推理。

1.3 人设工程：它的真正价值

guige_avatar 最精巧的部分不是代码，而是 persona.yaml——一个约 200 行的人设定义文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


personality:
 traits: ["技术极客", "偶尔幽默", "喜欢深度思考"]
 speaking_style: "口语化但有技术深度"
 
knowledge:
 expertise: ["大数据", "AI/LLM", "分布式系统"]
 current_projects: ["Claude Code 源码分析", "博客写作"]
 
boundaries:
 forbidden_topics: ["政治敏感", "个人隐私"]
 fallback: "这个话题我不太方便聊，换个有趣的话题吧？"

这种"人设工程"确实让对话体验很自然。但问题是——人设再好，它也只能聊天，不能做事。

1.4 手搓版的天花板

能力	状态
闲聊	✅ 流畅自然
回答技术问题	✅ 基于人设知识
搜索最新信息	❌ 无网络访问
查看博客文章	❌ 无文件读取
帮访客写代码	❌ 无代码执行
记住上次对话	❌ 刷新即丢失
自主完成任务	❌ 无 agent loop

这就是一个典型的聊天机器人——能对话，但不能行动。

二、Managed Agents：它到底是什么？

2.1 一句话定义

Managed Agents = Anthropic 托管的 Agent 运行时。

你不需要自己搭 agent loop、沙箱、工具执行层。Anthropic 提供一个完整的云端容器环境，Claude 在里面自主运行 bash、读写文件、搜索网页、执行代码。

如果 Messages API 是"你调用模型，模型返回文本"，那 Managed Agents 就是"你定义 Agent，Agent 自主完成任务"。

2.2 与 Messages API 的定位差异

	Messages API	Managed Agents
本质	直接模型调用	预构建的 Agent 运行时
适合	自定义 agent loop、精细控制	长时间异步任务、最小化基础设施
工具执行	你的代码负责执行	Anthropic 云端容器执行
类比	买 CPU 自己组电脑	买整机开箱即用

2.3 核心概念四件套

Managed Agents 的整个模型围绕四个概念：

概念	说明	类比
Agent	模型 + system prompt + 工具 + MCP servers	一个人的"能力定义"
Environment	云端容器模板：预装包、网络规则	这个人的"工作环境"
Session	运行中的 Agent 实例，绑定 Agent + Environment	一次具体的"工作会话"
Events	应用与 Agent 之间的消息流（SSE）	你和这个人之间的"对话"

工作流程：

1
2
3
4
5
6
7
8
9


创建 Agent（一次性） → 创建 Environment（一次性）
 ↘ ↙
 创建 Session（每次任务）
 ↓
 发送 Event（用户消息）
 ↓
 流式接收 Agent 响应（SSE）
 ↓
 可中途引导或中断

三、Case Study：数字分身 v1（手搓）vs v2（Managed Agents）

这是本文最核心的部分。我们来看，如果用 Managed Agents 重构鬼哥分身，会发生什么变化。

3.1 对话 → 能动手：工具能力

v1（手搓版）：只能基于 system prompt 中的静态知识回答。

1
2
3


访客：你最近写了什么文章？
鬼哥分身：我最近在写 Agent Skills 和 Gemma 4 的分析文章...
（这是 persona.yaml 里预写的，不是实时查的）

v2（Managed Agents 版）：有完整的工具链。

1
2
3
4
5
6
7
8


访客：你最近写了什么文章？
鬼哥分身：[使用 bash] ls content/post/ | tail -5
 [使用 read] 读取最近 5 篇文章的 frontmatter
 我最近写了这些文章：
 1. Agent Skills 深度解析（4月7日）
 2. Gemma 4 深度分析（4月5日）
 3. Karpathy 的 LLM Wiki（4月2日）
 ...每篇都有链接，要看哪篇？

Managed Agents 的内置工具：

工具	能力	数字分身的用途
Bash	执行 shell 命令	列出文章、统计数据
Read / Write / Edit	文件读写	查看博客内容、生成草稿
Glob / Grep	文件搜索	搜索特定话题的文章
Web Search / Fetch	网络搜索	查最新技术动态

3.2 内存级历史 → 持久化会话

v1：对话历史存在前端 JavaScript 内存中，刷新页面就没了。

1
2


// v1：前端维护历史，刷新即丢失
let history = []; // 🔥 页面刷新 = 失忆

v2：Session 天然持久化，Event 历史服务端保存。

1
2
3
4
5
6
7
8


# v2：Session 持久化，随时可恢复
session = client.beta.sessions.create(
 agent=avatar_agent.id,
 environment_id=env.id,
 title="访客 A 的对话"
)
# 下次访问，用同一个 session_id 继续
# 完整的对话历史都在服务端

更关键的是，Managed Agents 有 Memory（研究预览阶段）——跨会话的长期记忆。这意味着鬼哥分身可以记住：“上次这个访客问过 Spark 调优，他应该是做大数据的。”

3.3 单轮推理 → 多步 Agent Loop

这是最本质的差异。

v1：一问一答，没有中间推理步骤。

1

用户消息 → LLM 生成回复 → 返回

v2：Agent 可以自主规划多步执行。

1
2


用户消息 → Claude 思考 → 调用工具 A → 分析结果 
 → 调用工具 B → 综合判断 → 生成回复 → 返回

比如访客问"帮我分析一下你这个博客的技术栈"：

v1：只能背 persona.yaml 里预写的答案
v2：grep -r "hugo" config/ → cat themes/hugo-theme-stack/... → ls layouts/ → 基于实际代码给出准确分析

3.4 无沙盒 → 云端容器

v1：代码在 Vercel Serverless Function 里跑，只有 150ms 的冷启动预算，不能装额外的包。

v2：完整的云端容器。

1
2
3
4
5
6
7
8
9


environment = client.beta.environments.create(
 name="guige-avatar-env",
 config={
 "type": "cloud",
 "networking": {"type": "unrestricted"},
 # 可以预装任何包
 # Python, Node.js, Go, Hugo...
 },
)

容器意味着：

可以预装 Hugo 来本地构建预览
可以跑 Python 脚本分析数据
可以 git clone 仓库来读取最新代码
网络不受限，可以访问外部 API

3.5 单 Agent → 多 Agent 编排

v1：一个 function 处理所有事情。

v2：可以按职责拆分为多个专精 Agent。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# 主 Agent：鬼哥分身（对话协调者）
avatar = client.beta.agents.create(
 name="鬼哥分身",
 model="claude-sonnet-4-6",
 system="你是鬼哥的数字分身...",
 tools=[{"type": "agent_toolset_20260401"}],
 callable_agents=[
 {"type": "agent", "id": blog_agent.id, ...},
 {"type": "agent", "id": code_agent.id, ...},
 ]
)

# Sub-Agent 1：博客助手（搜索和推荐文章）
blog_agent = client.beta.agents.create(
 name="博客助手",
 model="claude-haiku-4-5", # 用小模型节省成本
 system="你负责搜索和推荐鬼哥的博客文章...",
 tools=[{"type": "agent_toolset_20260401"}],
)

# Sub-Agent 2：代码助手（分析代码、写 demo）
code_agent = client.beta.agents.create(
 name="代码助手",
 model="claude-sonnet-4-6",
 system="你负责帮访客分析代码和写 demo...",
 tools=[{"type": "agent_toolset_20260401"}],
)

当访客问文章相关的问题时，主 Agent 委托给博客助手；问代码问题时，委托给代码助手。各司其职，成本可控。

四、完整对比：手搓 vs 托管

维度	v1 手搓版	v2 Managed Agents
本质	Chat Completion 包装器	自主 Agent 平台
Agent Loop	无，单轮 request-response	有，多步推理 + 工具调用循环
工具能力	无	Bash、文件操作、Web 搜索、MCP
代码执行	不可能	云端容器沙盒
对话记忆	前端内存，刷新丢失	服务端持久化 Session
长期记忆	无	Memory（研究预览）
多 Agent	不可能	Coordinator + Sub-agents
后端代码	~150 行 JS	~50 行 Python（SDK 调用）
基础设施	Vercel function（自己维护）	Anthropic 全托管
模型	GPT-4.1-nano（OpenAI）	Claude Sonnet/Haiku（Anthropic）
成本	API 调用费 + Vercel 免费层	API 调用费 + Session 运行费
开发周期	1 天	1 天（SDK 很简洁）
适合场景	轻量级人设聊天	需要工具和自主性的场景

五、SDK 实战：5 分钟跑通 Managed Agents

5.1 安装

1
2


pip install anthropic
export ANTHROPIC_API_KEY="your-key"

5.2 创建 Agent + Environment + Session

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


from anthropic import Anthropic

client = Anthropic()

# 1. 创建 Agent
agent = client.beta.agents.create(
 name="鬼哥分身 v2",
 model="claude-sonnet-4-6",
 system="""你是鬼哥（luoli523）的数字分身。
 
性格：技术极客，偶尔幽默，喜欢深度思考。
擅长：大数据、AI/LLM、分布式系统、Claude Code。
说话风格：口语化但有技术深度，喜欢用类比解释复杂概念。

你可以使用工具来查看博客文章、搜索信息、执行代码。
当访客问到你不确定的事情时，先搜索再回答，不要编造。""",
 tools=[
 {"type": "agent_toolset_20260401"},
 ],
)

# 2. 创建 Environment
environment = client.beta.environments.create(
 name="avatar-env",
 config={
 "type": "cloud",
 "networking": {"type": "unrestricted"},
 },
)

# 3. 创建 Session
session = client.beta.sessions.create(
 agent=agent.id,
 environment_id=environment.id,
 title="访客对话",
)

print(f"Agent: {agent.id}")
print(f"Environment: {environment.id}")
print(f"Session: {session.id}")

5.3 发消息 + 流式接收

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


with client.beta.sessions.events.stream(session.id) as stream:
 # 发送用户消息
 client.beta.sessions.events.send(
 session.id,
 events=[{
 "type": "user.message",
 "content": [{
 "type": "text",
 "text": "帮我看看你博客最近写了什么文章"
 }],
 }],
 )

 # 流式处理响应
 for event in stream:
 match event.type:
 case "agent.message":
 for block in event.content:
 print(block.text, end="")
 case "agent.tool_use":
 print(f"\n[🔧 使用工具: {event.name}]")
 case "session.status_idle":
 print("\n\n✅ 完成")
 break

输出可能长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


让我看看最近的文章...
[🔧 使用工具: bash]
[🔧 使用工具: read]

最近写了这几篇：
1. **Agent Skills 深度解析**（4月7日）— 拆解 Addy Osmani 的 19 个 AI Agent skill
2. **Gemma 4 深度分析**（4月5日）— Google 开源模型的架构和应用
3. **Karpathy 的 LLM Wiki**（4月2日）— 从零理解 LLM 的百科全书

要看哪篇的详细内容？

✅ 完成

5.4 TypeScript 版本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

// 创建 Agent
const agent = await client.beta.agents.create({
 name: "鬼哥分身 v2",
 model: "claude-sonnet-4-6",
 system: "你是鬼哥的数字分身...",
 tools: [{ type: "agent_toolset_20260401" }],
});

// 创建 Environment
const env = await client.beta.environments.create({
 name: "avatar-env",
 config: { type: "cloud", networking: { type: "unrestricted" } },
});

// 创建 Session
const session = await client.beta.sessions.create({
 agent: agent.id,
 environment_id: env.id,
});

// 发消息 + 流式响应
const stream = await client.beta.sessions.events.stream(session.id);

await client.beta.sessions.events.send(session.id, {
 events: [{
 type: "user.message",
 content: [{ type: "text", text: "你最近在研究什么？" }],
 }],
});

for await (const event of stream) {
 if (event.type === "agent.message") {
 for (const block of event.content) {
 process.stdout.write(block.text);
 }
 } else if (event.type === "agent.tool_use") {
 console.log(`\n[🔧 ${event.name}]`);
 } else if (event.type === "session.status_idle") {
 console.log("\n\n✅ Done");
 break;
 }
}

六、工具配置：精细控制

默认的 agent_toolset_20260401 启用全部工具。但你也可以按需开关：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 只开 bash 和文件操作，关掉网络
agent = client.beta.agents.create(
 name="安全受限的分身",
 model="claude-sonnet-4-6",
 tools=[{
 "type": "agent_toolset_20260401",
 "default_config": {"enabled": False},
 "configs": [
 {"name": "bash", "enabled": True},
 {"name": "read", "enabled": True},
 {"name": "glob", "enabled": True},
 {"name": "grep", "enabled": True},
 # web_fetch 和 web_search 保持关闭
 ]
 }],
)

还支持自定义工具——你定义接口，Claude 决定何时调用，你的代码执行后把结果返回：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


agent = client.beta.agents.create(
 name="带自定义工具的分身",
 model="claude-sonnet-4-6",
 tools=[
 {"type": "agent_toolset_20260401"},
 {
 "type": "custom",
 "name": "get_blog_stats",
 "description": "获取博客的访问统计数据",
 "input_schema": {
 "type": "object",
 "properties": {
 "period": {
 "type": "string",
 "description": "统计周期：today, week, month"
 }
 },
 "required": ["period"]
 }
 }
 ],
)

七、手搓 vs 托管：什么时候用哪个？

这两种方案不是非此即彼的关系，而是不同复杂度和需求下的最优选择。

用手搓版（Messages API / 自建）

需求简单：纯聊天，不需要工具调用
成本敏感：Vercel 免费层 + 便宜的小模型就够了
完全控制：你需要自定义每一个细节
已有基础设施：你的团队已经有成熟的 agent 框架
离线场景：需要本地部署

用 Managed Agents

需要工具能力：Agent 需要执行代码、搜索网页、读写文件
长时间任务：任务可能运行几分钟甚至几小时
零基础设施：不想自己维护沙盒和 agent loop
多 Agent 编排：任务需要多个专精 Agent 协作
持久化会话：需要跨请求保持上下文和文件状态

混合方案：最佳实践

实际上，鬼哥分身最可能的进化路径是混合方案：

1
2
3
4
5
6
7


访客消息
 ↓
前端（博客首页）
 ↓
轻量网关（Vercel / Cloudflare Worker）
 ├── 简单闲聊 → 直接 Messages API（省钱）
 └── 复杂任务 → 转发到 Managed Agents Session

简单问答（“你是谁？““你喜欢什么？"）走便宜的 Messages API；需要搜索、执行代码、多步推理的任务走 Managed Agents。按需升级，不浪费。

八、Beta 注意事项

Managed Agents 目前是 Beta 状态（managed-agents-2026-04-01），几个关键信息：

所有 API 账户默认可用，无需单独申请
SDK 自动设置 beta header，直接用就行
Research Preview 功能（Outcomes、Multi-agent、Memory）需要单独申请
Rate Limit：创建操作 60 req/min，读取操作 600 req/min
支持 7 种 SDK：Python、TypeScript、Go、Java、C#、Ruby、PHP
还有 CLI 工具 ant（Homebrew 安装）

品牌规范提醒：如果你在产品中集成 Managed Agents，可以用 “Claude Agent” 命名，但不能用 “Claude Code” 或 “Claude Cowork” 的名称和视觉元素。

总结

从 guige_avatar 到 Managed Agents，本质上是从 “调用模型生成文本” 到 “委托 Agent 完成任务” 的范式转移。

从	到
Chat Completion	Agent Session
单轮推理	多步 Agent Loop
无工具	Bash + 文件 + Web + 自定义
前端内存	服务端持久化
单一 Agent	多 Agent 编排
自建一切	托管运行时

Managed Agents 本质上是 “Claude Code as a Service”——把 Claude Code 的核心能力（bash、文件操作、web 搜索、agent loop）包装成云端 API，让开发者在自己的产品中嵌入 Claude 级别的 Agent 能力。

对于鬼哥分身来说，150 行手搓版已经够用了。但当某天访客说"帮我写一个 Spark 调优的 demo"时，Managed Agents 版本会回答：

1
2
3
4


好的，让我帮你写一个...
[🔧 使用工具: write] 创建 spark_tuning_demo.py
[🔧 使用工具: bash] python spark_tuning_demo.py
脚本已经写好并测试通过了，关键的调优点是...

从"我告诉你"到"我帮你做”——这就是一步之遥。

Anthropic on 鬼哥的空间

Claude-Cookbooks 全景导航：被 README 藏起来的另一半

一、先把这份 repo 的定位搞清楚

二、一张总览图：20 多个目录怎么归类

三、基础能力层：Claude API 开箱即用能做什么

3.1 capabilities/ — 经典的 NLP 任务

3.2 multimodal/ — 视觉能力

3.3 extended_thinking/ — 让模型"想得更久"

四、Tool Use 专题：整个 cookbook 最密的一块

五、性能与成本优化

六、Agent 的三条进阶路径

6.1 模式层 patterns/agents/ — 先把套路搞清楚

6.2 SDK 层 claude_agent_sdk/ — 官方的 Agent 教程

6.3 托管层 managed_agents/ — Claude Managed Agents (CMA)

七、Skills 技能包

八、第三方集成一览

九、评估与微调

十、仓库工程实践：这本身就是一份"怎么管理 Notebook 项目"的样板

十一、我接下来会按什么顺序往里钻

结尾：这只是起点

参考资料

Claude Managed Agents：从聊天机器人到自主 Agent 的一步之遥

一、手搓版：guige_avatar 架构剖析

1.1 整体架构

1.2 核心代码：就这么简单

1.3 人设工程：它的真正价值

1.4 手搓版的天花板

二、Managed Agents：它到底是什么？

2.1 一句话定义

2.2 与 Messages API 的定位差异

2.3 核心概念四件套

三、Case Study：数字分身 v1（手搓）vs v2（Managed Agents）

3.1 对话 → 能动手：工具能力

3.2 内存级历史 → 持久化会话

3.3 单轮推理 → 多步 Agent Loop

3.4 无沙盒 → 云端容器

3.5 单 Agent → 多 Agent 编排

四、完整对比：手搓 vs 托管

五、SDK 实战：5 分钟跑通 Managed Agents

5.1 安装

5.2 创建 Agent + Environment + Session

5.3 发消息 + 流式接收

5.4 TypeScript 版本

六、工具配置：精细控制

七、手搓 vs 托管：什么时候用哪个？

用手搓版（Messages API / 自建）

用 Managed Agents

混合方案：最佳实践

八、Beta 注意事项

总结

参考资料

3.1 `capabilities/` — 经典的 NLP 任务

3.2 `multimodal/` — 视觉能力

3.3 `extended_thinking/` — 让模型"想得更久"

6.1 模式层 `patterns/agents/` — 先把套路搞清楚

6.2 SDK 层 `claude_agent_sdk/` — 官方的 Agent 教程

6.3 托管层 `managed_agents/` — Claude Managed Agents (CMA)