Anthropic 官方 Orchestrator-Worker 多智能体研究系统设计模式（工程博客四篇 + claude-cookbooks 参考实现）

Anthropic — Multi-Agent / Orchestrator-Worker 设计（博客）

一句话定位

这不是一个可下载运行的产品级 harness，而是 Anthropic 用 4 篇官方工程博客公开披露的设计模式——真实生产系统是内部的 “Claude Research” 功能（LeadResearcher → 并行 Subagents → CitationAgent 三级流水线），其后端代码从未开源；唯一可读的代码级证据是官方参考仓库 claude-cookbooks 里的教学向 notebook 与三份逐字系统提示词，用来”展示模式的形状”而非生产实现本身。

核心架构总览（目录结构关键路径 + 引用的 commit）

• 一手源不是代码仓库，是博客集群：4 篇 anthropic.com/engineering/* 文章，已全文抓取存档于 blog/*.md。
• 辅助代码仓库：github.com/anthropics/claude-cookbooks（原名 anthropic-cookbook，旧 URL 301 跳转到新名），commit 3393bdaedde4fb26b4944a14710471f07c204fc1（作者日期 2026-07-02，提交信息 “fix(rag,classification): update rate-limit tier references to usage-tier naming (#752)”），git clone --depth 1 浅克隆于 2026-07-07。
• 关键路径：
  • patterns/agents/README.md — 明确自称是 Building Effective Agents（Erik Schluntz & Barry Zhang）一文的参考实现。
  • patterns/agents/orchestrator_workers.ipynb — 最小可跑的 orchestrator-workers 模式（FlexibleOrchestrator 类、XML 任务解析、市场文案变体玩具示例），是教学示例，不是真实 Research 系统：worker 顺序执行（非并行），orchestrator 单次调用产出 2-3 个 XML 子任务。
  • patterns/agents/async_multi_agent_orchestration.ipynb — 目录中最接近生产的代码artifact，其 notebook 头部原文声明本 cookbook 展示的是 “the shape of the two multi-agent orchestration patterns behind the multi-agent results in the Claude Opus 4.8 system card”：固定 N-agent 团队 + 动态异步子代理生成两种拓扑。
  • patterns/agents/prompts/research_lead_agent.md（155 行）、research_subagent.md（47 行）、citations_agent.md（22 行）— LeadResearcher / Subagent / CitationAgent 三个角色的逐字系统提示词，均含 Go 模板占位符 {{.CurrentDate}}（research_lead_agent.md:2、research_subagent.md:1，本次已直接读取确认存在），证明这些提示词在生产环境是模板渲染而非静态字符串。
• 重要说明：这三份提示词是 Anthropic 在博客 #1 中主动指向的”开源示例提示词”（“See the open-source prompts in our Cookbook for example prompts from our system”），角色命名与博客架构图完全吻合，但应视为官方发布、用来说明真实系统设计的参考提示词，不是生产提示词的逐字泄露；提示词内提到的工具名 run_blocking_subagent、complete_task 是内部风格命名，语义合理但未被其他独立来源交叉确认。
• 全部结论均来自本地存档文件，未凭空补充。

Agent Loop（主循环 / 何时继续何时停）

• 顶层循环（博客 #1 架构图，blog/multi-agent-research-system.md 第 59-61 行叙述）：LeadResearcher 思考 → 将计划存入 Memory → 生成 Subagents → 各 Subagent 独立循环（检索 → 通过 interleaved thinking 评估 → 决定继续检索或返回）→ LeadResearcher 汇总 → 判断”是否需要更多研究”（回到生成子代理，或退出）→ 交给 CitationAgent → 结束。
• 停止条件的具体文字见 cookbook-code/research_lead_agent.md <important_guidelines> 第 4 条（约第 150 行）：“when you have reached the point where further research has diminishing returns… STOP FURTHER RESEARCH and do not create any new subagents. Just write your final report.”
• Subagent 层是显式的 OODA 循环，见 research_subagent.md <research_process> 第 3 步，并带硬性工具调用上限（<maximum_tool_call_limit> 段落）：“Execute a MINIMUM of five distinct tool calls, up to ten for complex queries… under a limit of 20 tool calls and under about 100 sources”。
• 通用（非 Research 产品）agent loop 的定义见博客 #2 与 #3：“LLMs autonomously using tools in a loop”（博客 #3 引用 Simon Willison），终止条件包括任务完成或显式的 max-iterations/人工检查点。
• 代码级循环见 async_multi_agent_orchestration.ipynb cell 9 的 run_agent 函数：字面上的 for _ in range(max_turns) 有界工具循环，stop_reason == "end_turn" 时退出，遇到未预期的 stop_reason 则抛异常。
• 同步执行是官方承认的生产限制（博客 #1 “Production reliability” 一节）：“Currently, our lead agents execute subagents synchronously, waiting for each set of subagents to complete before proceeding.”——异步执行被列为未来工作，async_multi_agent_orchestration.ipynb 正是朝这个方向的原型探索，并明确关联到 “Claude Opus 4.8 system card”。

记忆与上下文管理（压缩、长期记忆、会话持久化）

博客 #3（Effective context engineering for AI agents）是这一维度最权威的来源，给出三种长程一致性技术：

1. Compaction（压缩）：在上下文窗口接近用尽时摘要重建。Claude Code 的实现细节（博客 #3）：保留”architectural decisions, unresolved bugs, and implementation details”，丢弃”redundant tool outputs”，并额外保留”the five most recently accessed files”。更轻量的变体是”tool result clearing”，已作为 Claude Developer Platform 的一项功能上线。
2. 结构化笔记 / agentic memory：agent 把笔记写到外部持久存储（如 NOTES.md 风格文件，或 Claude Code 的 to-do 列表），在上下文重置后读回。博客举 “Claude Plays Pokémon”（外部演示，非本系列博客本身）为例，证明无需显式记忆结构提示也能跨数千步跟踪进度。已上线功能：Claude Developer Platform 公开测试版的 memory tool（基于文件的存储）。
3. 子代理架构本身被明确当作上下文管理策略，而不只是并行策略：“specialized sub-agents can handle focused tasks with clean context windows… returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)”。

博客 #1 的具体记忆细节（架构图配文，blog/multi-agent-research-system.md 第 61 行）：“The LeadResearcher begins by thinking through the approach and saving its plan to Memory to persist the context, since if the context window exceeds 200,000 tokens it will be truncated.”——这是全部材料中唯一给出的具体上下文长度数字（200K token，与当时 Claude 公开上下文窗口一致）。

博客 #1 附录”Long-horizon conversation management”补充：agent “summarize completed work phases and store essential information in external memory before proceeding”，并可”retrieve stored context like the research plan from their memory rather than losing previous work when reaching the context limit”。

博客 #1 附录”Subagent output to a filesystem to minimize the ‘game of telephone’“：subagent 可将大型结构化输出（代码、报告、可视化）直接写入外部 artifact 存储，只回传一个轻量引用，绕过 lead agent 作为全内容中转的角色——这是一个明确的上下文/token 经济性设计。

未发现跨会话的长期用户记忆（如用户画像存储）的证据——这里讨论的记忆全部是任务内/会话内的（压缩、笔记、子代理隔离），不是跨对话持久记忆。

工具体系（定义/调用协议/注册/权限）

• 基础机制是标准 Anthropic Messages API 的 tool-use block（JSON-schema input_schema、响应中的 tool_use content block），这部分是通用 API 机制，未在这四篇博客中重新展开。
• MCP（Model Context Protocol）是扩展层：博客 #1 明确把 MCP 列为工具选择困难的来源之一（“agents encounter unseen tools with descriptions of wildly varying quality”，prompt-engineering lesson #4）；博客 #4 整篇就是围绕 MCP 工具设计的强化：原型 → eval → 迭代的闭环。
• research_subagent.md 给出的具体工具分类：google_drive_search、gmail 系列工具、gcal 系列工具、repl（仅限 JS 的沙盒计算器，明确禁止访问 DOM/API）、web_search、web_fetch，以及可能存在的任意”内部工具”（Slack、Asana、GitHub）。文中明确优先级规则：“internal tools strictly take priority” 高于 web search（当两者都可用且相关时）。
• research_lead_agent.md 给出的编排层工具：run_blocking_subagent（生成并阻塞等待单个子代理，通过 prompt 参数传递任务）与 complete_task（提交最终报告）。注意：这是一个阻塞的、单子代理粒度的工具接口，却被要求”并行调用”——即所谓”parallel tool calls”是通过在同一轮内发起多次 run_blocking_subagent 调用实现的，提示词层面并没有一个批量/异步原语。
• async_multi_agent_orchestration.ipynb 给出更进化的异步工具 schema：send_message（recipient_ids + content，通过追加到下一次工具结果来投递——“This is the ONLY way to reach other agents”）、wait_for_message（阻塞等待）、create_subagents（立即返回，生成 N 个 helper，共享 base_instruction，可选 per_subagent_instructions[i]，上限 10 个）、get_status（轮询 active/idling/done/crashed）、kill_subagents。
• 工具设计原则（博客 #4 “Principles for writing effective tools”）：偏好少量高层”合并型”工具而非对每个 API 端点做薄封装（例如用 schedule_event 代替 list_users+list_events+create_event）；按服务/资源前缀给工具命名空间以在 MCP 工具泛滥时消歧；返回”高信号”字段而非裸 UUID；支持 response_format 枚举（"concise" vs "detailed"）以在完整性和 token 成本间权衡（举例的实测数字：同一条 Slack 线程 detailed 模式 206 token vs concise 模式 72 token）；默认截断示例——Claude Code 对单次工具响应的上限是 25,000 token。
• 工具自我改进闭环：博客 #1 item 5（“Let agents improve themselves”）——一个专门的”工具测试 agent”被给一个有缺陷的 MCP 工具，实证探测后重写其描述；实测效果是下游任务完成时间降低 40%。

Prompt 设计（系统提示结构、动态组装）

• 博客 #3 给出结构化指导：把系统提示组织成命名分区（<background_information>、<instructions>、## Tool guidance、## Output description），用 XML 标签或 Markdown 标题；目标是”合适的高度”（right altitude）——既不是脆弱的硬编码 if/else，也不是空泛的高层指导。
• 三份 cookbook 提示词是这套结构在实践中的具体证据：research_lead_agent.md 用的顶层 XML 分区为 <research_process>、<subagent_count_guidelines>、<delegation_instructions>、<answer_formatting>、<use_available_internal_tools>、<use_parallel_tool_calls>、<important_guidelines>；research_subagent.md 用 <research_process>、<research_guidelines>、<think_about_source_quality>、<use_parallel_tool_calls>、<maximum_tool_call_limit>。
• 动态组装证据：两份提示词都含模板占位符 {{.CurrentDate}}（Go 风格模板语法），本次核实见 research_lead_agent.md:2（“The current date is {{.CurrentDate}}.“）与 research_subagent.md:1（“The current date is {{.CurrentDate}}.“）——证明这些提示词在生产环境由模板引擎渲染而非静态字符串。
• 博客 #1 的 8 条 prompt-engineering 经验本身也是一种元层面的 prompt 设计指导：“teach the orchestrator how to delegate”（给子代理明确的目标/输出格式/工具指导/边界，而非模糊的一句话）；“scale effort to query complexity”（子代理数量 vs 查询类型的显式对照表——这在 cookbook 提示词里字面对应 <subagent_count_guidelines> 分区）；“start wide, then narrow down” 的检索启发式被直接写进提示词文本。
• Extended/interleaved thinking 被当作提示词可控的推理层面之一，而非独立模块：“The lead agent uses thinking to plan its approach… Subagents also plan, then use interleaved thinking after tool results”（博客 #1 item 7）。

Router / 编排（任务分解、多 agent、子 agent）

这是该 harness 的命名维度，也是全部 12 个维度里证据最丰富的一项。

• 规范拓扑（博客 #1 架构章节 + 配图）：用户查询 → LeadResearcher（编排者）→ 分析、规划、并行生成 N 个 Subagents（worker），各自拥有独立上下文窗口与独立工具循环 → subagent 把浓缩后的发现回传给 LeadResearcher → LeadResearcher 汇总，决定是否生成更多 subagent 或停止 → 最终结果 → CitationAgent（第三个独立专职角色，不是 subagent，专门负责事后引用标注）→ 返回用户。
• 模式命名与通用定义：博客 #2 “Orchestrator-workers workflow”——“a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results”，并明确与”Parallelization”模式区分：orchestrator-workers 的子任务不是预先定义的，而是运行时按输入动态决定；parallelization 的子任务是预先固定的。
• 任务分解分类法（research_lead_agent.md 第 2 步”Query type determination”）：三个正式类别——Depth-first（同一问题的多个视角，3-5 个子代理各取不同方法论角度）、Breadth-first（查询拆分为相互独立的子问题，子代理按子话题分配且明确不重叠边界）、Straightforward（单个子代理，有时作为”平等协作者”与 lead 各分担一半工作）。
• 子代理数量规模化规则（博客 #1 item 3 与 cookbook <subagent_count_guidelines> 均有，后者更细）：简单查询 → 最少 1 个子代理（从不为零，“always create at least 1 subagent to ensure proper source gathering”）；标准 → 2-3 个；中等 → 3-5 个；高复杂度 → 5-10 个，硬上限”never more than 20… Prefer fewer, more capable subagents over many overly narrow ones.”
• 实测性能：多智能体系统（Opus 4 作 lead + Sonnet 4 作 subagent）在 Anthropic 内部研究类 eval 上比单一 Opus 4 高出 90.2%；BrowseComp 方差的 95% 由 3 个因素解释——单独 token 用量占 80%，剩余 20% 由工具调用次数和模型选择分摊。
• 并行性是两层的：(1) lead 并发生成 3-5 个子代理而非串行；(2) 每个子代理自身并行发起 3+ 个工具调用。综合效果：“cut research time by up to 90% for complex queries”（博客 #1 item 8）。
• 成本权衡（量化）：agent 用量约为 chat 的 4 倍；多智能体系统用量约为 chat 的 15 倍（博客 #1）。明确指出的不适用领域：大多数编码任务（共享上下文/依赖过多，真正可并行的部分不够）——这也是博客 #2 把”编码”和”检索/多源信息收集”同列为 orchestrator-workers 两个示例用例的原因，但博客 #1 特别指出编码在”多智能体”（而非单智能体）处理上经济性边际。
• 早期迭代中的具体失败模式（博客 #1）：为简单查询生成 50 个子代理；子代理重复做同一个子检索（“2021 汽车芯片危机” vs “2025 供应链”的例子）；agent 之间”用过多更新互相干扰”。
• 汇总/聚合职责明确保留给 lead agent，绝不下放：research_lead_agent.md <important_guidelines> 第 5 条：“NEVER create a subagent to generate the final report - YOU write and craft this final research report yourself.”
• 异步 cookbook notebook 在工具 schema 层面展示了两种不同的编排拓扑：(a) 固定 N-agent 团队——所有 agent 一开始就并发启动，通过 send_message 点对点通信；(b) 动态异步子代理——只有 lead 拥有生成/查询状态/终止的工具权限，子代理汇报后 wait_for_message 等待进一步指令而不是终止，即子代理可以被保活并重新派任务，而非一次性执行。

Skill / 插件体系

• 这四篇博客中没有描述任何专门的”skills”或插件体系。最接近的类比是作为可插拔能力单元的 MCP server 集成，已归入”工具体系”一节讨论。
• 备注：Anthropic 另一个独立的”Agent Skills”产品功能（claude.com/skills，仅在四篇文章的页脚导航中出现）是一个不同的、更晚期的产品层面，不属于这四篇设计模式文章正文的覆盖范围——这里的结论是”这批源材料未覆盖”，不是”Anthropic 不存在这个东西”。
• 结论：未实现 / 这批源材料未涉及。

自进化能力（自我改进 / 学习型记忆 / eval 驱动纠错）

• 博客 #1 item 5”Let agents improve themselves”：用 Claude 4 模型充当 prompt 工程师——给定一个提示词加一种失败模式，模型诊断并给出修复建议。具体实例：一个专门的工具测试 agent 迭代式地对一个有缺陷的 MCP 工具进行”数十次”测试调用，重写该工具描述；实测效果是后续 agent 使用改进后描述的下游任务完成时间降低 40%。
• 博客 #4 把这套流程正式化为可复用工作流：搭建工具原型 → 基于真实使用场景生成 eval 任务 → 运行 eval → 让一个 agent（Claude Code）分析原始 transcript 并重构工具 → 在留出测试集上重跑以避免过拟合。文中以图表形式展示了内部 Slack 和 Asana MCP 工具集的前后准确率对比（图表描述为”有提升”，但抓取到的正文没有给出具体百分比，图片本身未做 OCR）。
• 本质是离线的、人类监督的、eval 驱动的工具/提示词改进闭环——不是在线/自主的自我修改型 agent，也不是会改变未来模型权重的持久化学习记忆。这四篇源材料中没有描述任何”从轨迹做 RL”或”用自身输出做微调”的机制。
• 结论：部分实现——“通过 agent 辅助分析 + eval 闭环改进工具/提示词”，明确是人类把关，不是自主在线学习。

可观测性（日志 / trace 格式）

• 博客 #1 “Debugging benefits from new approaches”一节：专门加入完整的生产级 tracing，目的是诊断为什么agent 会选择不好的检索词、劣质来源，或遇到工具失败——这一需求源于用户反馈 agent”没找到明显信息”却完全无法定位原因。
• 明确的隐私设计约束：可观测性停留在”agent 决策模式与交互结构”层面，“without monitoring the contents of individual conversations”。没有披露任何具体的 trace schema（字段名、日志格式、存储后端）——这是定性/愿景性的表述，不是规格说明。
• 四篇源材料中都没有给出具体的 trace/log JSON schema、span 格式，或具名的可观测性工具/厂商。提到的模拟/开发期观测工具是 Anthropic Console——用来”build simulations… with the exact prompts and tools from our system, then watched agents work step-by-step”（博客 #1 item 1”Think like your agents”）。
• 结论：仅有定性描述；这批源材料中未找到具体的 trace 格式。

安全与权限（审批门、密钥管理）

• 这四篇源材料在这一维度覆盖非常薄——博客聚焦于研究类 agent 的设计，不是安全架构。
• 唯一具体的权限相关规则来自 research_lead_agent.md <use_available_internal_tools> 一节：“DO NOT use write, create, or update tools”——子代理/lead 在研究过程中对内部集成（Slack、Asana、Google Drive 等）被限制为只读使用；明确允许读动词（_search、_user_info）白名单，硬性禁止改写类调用。
• research_lead_agent.md <important_guidelines> 第 6 条：明确的内容安全门——“you must not create subagents to research anything that would promote hate speech, racism, violence, discrimination, or catastrophic harm.”
• 四篇源材料均未描述 API key/密钥管理设计、审批门/人在回路 UI 机制，或任何 auth 模型。
• 结论：最低限度——只有只读工具限制 + 内容安全指令；没有披露密钥/凭据管理设计。

沙箱与执行隔离

• research_subagent.md 给出一个具体的隔离细节：repl 工具被明确限定为仅 JS、无 DOM 访问、无 API 调用、无外部依赖——即刻意收窄为仅供计算使用的沙盒执行面（“the repl tool does not have access to a DOM or other features, and should only be used for JavaScript calculations without any dependencies, API calls, or unnecessary complexity”）。
• 博客 #2（附录 1”Coding agents”）另外提到通用 agent 测试实践：“We recommend extensive testing in sandboxed environments, along with the appropriate guardrails”——这是通用性指导，不是针对本 harness 的具体沙箱实现。
• 没有描述容器/VM 隔离架构，也没有为 Research subagent 本身规定文件系统/网络沙箱规格——subagent 的主要”工具”是 web_search/web_fetch/内部 SaaS API，不是任意代码执行，所以经典的沙箱逃逸问题在这个具体 harness 的设计里基本不在讨论范围内。
• 结论：最低限度——只有 repl 的 JS-only 限制是具体的；未披露更广泛的沙箱架构。

与模型的协同设计

• 博客 #1 的核心实证发现本身就是一个模型协同设计的结果：token 用量解释了 BrowseComp 性能方差的 80%，且”upgrading to Claude Sonnet 4 is a larger performance gain than doubling the token budget on Claude Sonnet 3.7”——即模型质量提升被视为同一架构上的乘数效应，这也是选择异构模型分层（Opus 4 作 lead + Sonnet 4 作 subagent）而非统一模型的动机。
• Interleaved thinking（Anthropic API 特性，docs.anthropic.com/en/docs/build-with-claude/extended-thinking#interleaved-thinking）被用作让子代理”评估工具结果”并在循环中途精炼下一步查询的核心机制——这是 harness 设计明确依赖的模型能力，而不是 harness 自己搭建的东西。
• 博客 #4 关于工具响应格式的指导（“optimal response structure will vary widely by task and agent… LLMs are trained on next-token prediction and tend to perform better with formats that match their training data”）明确说明工具/harness 设计必须按模型协同调优，不是模型无关的。
• 博客 #3 的核心论点（context rot、n² attention 成本、位置编码插值导致长上下文精度下降）本身就是一种基于模型架构认知的 harness 设计推理——上下文工程策略直接源自 transformer 注意力机制，而不是把模型当黑盒处理。
• 四篇源材料均未描述针对本 harness 的自定义模型训练、微调或 RLHF——协同设计完全停留在”围绕已知模型行为塑造 prompt/工具/上下文”层面，不涉及权重层面。

轨迹利用（session/trajectory 是否反哺训练/评测）

• 博客 #1 的 eval 方法论（LLM-as-judge 打分标准：事实准确性、引用准确性、完整性、来源质量、工具效率，0.0-1.0 打分 + pass/fail）明确是轨迹的评测用途——最初在约 20 个人工挑选的查询上运行，再用 LLM-judge 扩展到”数百个输出”——但这是用于迭代提示词/工具的离线 eval，不是一个明确声明的训练数据管道。
• 四篇源材料中没有任何地方说明用户会话轨迹被用来微调或 RL 训练底层 Claude 模型。文中描述的”轨迹复用”只有两种：(a) 人类测试员阅读 transcript 捕捉边缘情况（SEO 内容农场偏差的例子）；(b) 工程师阅读 agent trace 来调试/改进提示词和工具（博客 #4 整篇的评测-transcript-分析工作流）。
• 结论：轨迹被用于评测和人在回路的提示词/工具迭代，没有披露作为训练/RL 数据。应报告为”未确认”而非”未实现”——Anthropic 在这几篇源材料里根本没有对此做出明确表态。

与同类 harness 的关键差异（1-3 条，可以先留一句概述，后续 synthesis 阶段会做跨 harness 对比）

• 与多数”产品即 harness”（有具体开源代码库、可运行、可 clone 的项目）不同，这是 Anthropic 唯一一个以设计模式/博客形式公开、生产代码完全未开源的重量级 harness 样本；其”源码”只有教学向 cookbook，量化数据（90.2% eval 提升、80% 方差来自 token、15x token 成本）却异常丰富、具体，这种”文字证据扎实但代码证据单薄”的组合在同类调研对象里较为特殊。
• 明确的经济性边界披露（编码任务不适合多智能体、15x token 成本）在同类 harness 的公开材料中较少见——大多数厂商倾向只展示正面收益数字，Anthropic 这四篇博客罕见地正面写出多智能体系统”何时不该用”。
• 跨 harness 的横向对比（与 Warp、其他 orchestrator 型 harness 的 agent-loop/工具协议/沙箱设计对照）留待后续 synthesis 阶段统一处理，此处不展开。

原始源码定位

• repo: https://github.com/anthropics/claude-cookbooks（原 anthropic-cookbook，旧链接 301 跳转）
• commit/version analyzed: 3393bdaedde4fb26b4944a14710471f07c204fc1（作者日期 2026-07-02，浅克隆于 2026-07-07）
• 关键文件列表（相对 repo 根目录）：
  • patterns/agents/README.md
  • patterns/agents/orchestrator_workers.ipynb
  • patterns/agents/async_multi_agent_orchestration.ipynb
  • patterns/agents/basic_workflows.ipynb（仅通过渲染页面部分阅读，未落盘）
  • patterns/agents/prompts/research_lead_agent.md
  • patterns/agents/prompts/research_subagent.md
  • patterns/agents/prompts/citations_agent.md

一手源存档（sources/）

目录 /Users/zhao/projects/self-wiki/ai-research/sources/harness/anthropic-multi-agent-orchestration/ 下：

• NOTES.md — stage-1 调研笔记（全部维度详细发现、逐一引用行号）
• blog/multi-agent-research-system.md — 博客 #1《How we built our multi-agent research system》全文（2025-06-13）
• blog/building-effective-agents.md — 博客 #2《Building effective agents》全文（2024-12-19）
• blog/effective-context-engineering.md — 博客 #3《Effective context engineering for AI agents》全文（2025-09-29）
• blog/writing-tools-for-agents.md — 博客 #4《Writing effective tools for AI agents — with agents》全文（2025-09-11）
• cookbook-code/research_lead_agent.md — LeadResearcher 系统提示词逐字稿（155 行）
• cookbook-code/research_subagent.md — Subagent 系统提示词逐字稿（47 行）
• cookbook-code/citations_agent.md — CitationAgent 系统提示词逐字稿（22 行）
• cookbook-code/orchestrator_workers.ipynb — 参考 orchestrator-workers 模式代码
• cookbook-code/async_multi_agent_orchestration.ipynb — 异步子代理生成/消息中枢模式代码
• cookbook-code/agents-README.md — patterns/agents/ 目录索引（原文件名 README.md，改名避免与本目录 NOTES.md 冲突）