本文摘要
精读 Anthropic 工程博客三篇：《Building effective agents》《How we built our multi-agent research system》《Effective context engineering for AI agents》。按“演化线”整理——上篇工具与编排模式、中篇多 Agent 系统的工程实现、下篇上下文工程，末尾归纳三次表态。

把这三篇放在一起读，是因为它们隔着大半年，恰好是一次”关注点转移”的完整记录：

  • 2024 年底，Anthropic 在回答”要不要做 agent、agent 由什么积木搭”；
  • 2025 年中，agent 真的跑起来做研究了，问题变成”怎么让一整个系统撑住”；
  • 2025 年秋，焦点进一步下探到最稀缺的资源——上下文本身。

这里先说明一点：下文记录的所有要点，都是这三篇文章各自写作当时的设计与判断。技术迭代很快，今天回看，其中不少具体做法已经是过去式，甚至被作者后续的文章修正。重读它们的价值不在结论本身，而在当时面对的问题、取舍过程和背后的工程理念——这些更经得起时间。而文中夹带的讨论与补充，也只是一家之言，仅供参考。

一句话概括这条线的公式演化：

上篇（2024-12）：agent = LLM + 工具（+ 循环）
中篇（2025-06）：agent = 一整套会跑、会错、会恢复的系统
下篇（2025-09）：系统的核心矛盾是上下文，harness 的主要工作是策展上下文

上篇 · Building effective agents：先把”要不要上 agent”问清楚

原文：https://www.anthropic.com/engineering/building-effective-agents

主旨：跟几十个团队合作做 agent 之后，Anthropic 发现最成功的实现用的是简单、可组合的模式，而不是复杂框架。

定义：workflow 与 agent 是两回事

  • workflow：LLM 和工具按预设的代码路径编排，流程由人写好。
  • agent：LLM 自己动态决定流程和用哪些工具。

这个区分很重要。固定流程的现实场景（比如 coze 上的编排）用 workflow；需要模型在运行时自己拿主意的复杂应用才上 agent。

什么时候用 agent

先用最简单方案，别一上来就上 agent——agent 是用延迟和成本换任务表现。边界清晰、要求可预测的，用 workflow；需要灵活性、模型自主决策、还要规模化的，才上 agent。很多场景其实一次带检索或示例的 LLM 调用就够了。

至于框架（Claude Agent SDK、AWS Strands、Rivet、Vellum 等），上手快，但多一层抽象、难调试、还容易诱导你加复杂度。建议直接从 LLM API 入手。

五种 workflow 编排模式

  1. Prompt chaining 提示链：把任务拆成串行步骤，前一步的输出喂给下一步，中间可加程序化的”闸门”检查。适合能干净拆成固定子任务的场景（比如先写营销文案再翻译）。
  2. Routing 路由：先分类输入，再分派给专门的后续处理。让不同类别各用各的专用 prompt，避免为一种输入优化而伤到另一种（比如把简单问题路由给 Haiku、难的给 Sonnet）。
  3. Parallelization 并行化：分两种。Sectioning——把任务拆成独立子任务并行跑（比如一个模型出结果、另一个做内容审核）；Voting——同一任务跑多次取多个结果（比如多组 prompt 查代码漏洞）。
  4. Orchestrator-workers 编排者-工作者：中心 LLM 动态拆解任务、派给 worker、再汇总。子任务不预设、由编排者按输入决定，适合无法预判步骤的复杂任务（比如改多个文件的编程任务）。
  5. Evaluator-optimizer 评估者-优化者：一个 LLM 生成、另一个评估反馈、循环打磨。适合有明确评估标准、迭代能带来可测提升的场景（比如文学翻译）。

要注意：这五种在原文里全被归在 Workflow 名下，连 orchestrator-workers 也是——因为”编排结构”是代码定的，只有子任务的内容由模型定。它们是可以复用的设计模板，不是框架，也不必整套照搬。真正的 agent 是后面那个独立类别。

agent 本体与三条原则

agent 就是 LLM 在循环里根据环境反馈使用工具：每一步拿到 ground truth 判断进度，可以在检查点或受阻时暂停等人类反馈，通常还设停止条件（比如最大迭代数）。

三条核心原则：设计简单、过程透明（显式展示规划步骤）、精心打磨 ACI（agent-computer interface，认真写工具文档并测试）。

附录里那段工具 prompt engineering 值得单独拎出来：工具格式要贴近模型熟悉的自然文本，别制造格式负担（比如要求精确行号的 diff、在 JSON 里转义代码）；写工具描述要像给初级工程师写 docstring；多跑例子迭代；做防呆（poka-yoke）。Anthropic 说做 SWE-bench 时，花在优化工具上的时间比优化总 prompt 还多——一个实例就是强制用绝对路径，解决了相对路径出错的顽疾。

讨论与补充

  • 2024 年 agent 应用已初见端倪，最被看好的是客服和 coding agent 两个方向。它们都具备”清晰成功标准 + 反馈闭环 + 人类监督”。这个组合可以当成一个筛选器：成功标准清晰（可自动验证）才有反馈闭环，有闭环模型才能自迭代，再加人类监督兜底。反过来，标准模糊、闭环难量的任务（创意写作、开放式咨询）塞 agent，很容易变成烧 token 的自嗨。
  • 这一年的公式是 agent = LLM + 工具，harness 这个词还没出现，tool/ACI 是核心的设计对象。往后读中篇、下篇 能看到它怎么被一层层包起来：harness 把工具包在更外一层，负责循环控制、上下文管理、记忆、权限沙箱、错误恢复；工具只是 harness 里的一个部件，并没有被取代。

中篇 · 多 agent 研究系统：从单个 agent 到生产系统

原文：https://www.anthropic.com/engineering/multi-agent-research-system

背景：Claude 的 Research 功能用多个 agent 做开放式研究，架构是 orchestrator-worker（lead agent + 并行 subagent）。

为什么用多 agent

研究步骤无法预判。搜索的本质是”压缩”——从海量语料里提炼洞见。让 subagent 各带独立窗口并行探索、各自压缩后交回 lead，等于分离了关注点、降低了路径依赖。

效果：Opus 4 当 lead + Sonnet 4 当 subagent，相比单 Opus 4，在内部研究评测上高 90.2%。

为什么有效？主要是能花更多 token。在 BrowseComp 上，token 用量单独就解释了 80% 的性能差异，另两个因素是工具调用次数和模型选择。

代价也直白：agent 约比普通对话多用 4× token，多 agent 约 15×。所以它只适合任务价值够高、高度可并行、信息超出单窗口、还要对接多种复杂工具的场景。编码任务真正可并行的部分没有研究多，其实不太适合多 agent。

架构与 prompt 原则

LeadResearcher 先把计划存进 Memory（上下文超 20 万 token 会截断），再建 subagent 并行搜索，最后交给 CitationAgent 定位引用。

给 agent 写 prompt 的原则：

  • 像你的 agent 那样思考（用 Console 模拟，看它一步步怎么跑）；
  • 教编排者怎么委派——说清目标、输出格式、工具来源、边界；
  • 按查询复杂度分配投入力度；
  • 工具设计与选择是关键；
  • 让 agent 自我改进；
  • 先宽后窄；
  • 引导思考过程（extended thinking 当草稿纸）；
  • 并行工具调用（复杂查询的研究时间最多缩短 90%）。

评测

不能只看是否走完预设步骤，要判”结果对不对 + 过程合不合理”。小样本就立即开评（约 20 条查询）；LLM-as-judge 用单次调用打 0.0–1.0 加通过/不通过最稳；人工评测补漏（比如早期 agent 偏好 SEO 内容农场，只有人看得出来）。

生产可靠性四难点

这是中篇 最有价值的部分——把”agent 跑起来”之后的系统级麻烦摊开了：

  1. agent 有状态、错误会累积：要能从中断处恢复（不是从头重启），配重试 + 定期检查点；也让 agent 自己知道工具坏了去适配，再配确定性兜底。
  2. 非确定性难调：加 full production tracing；且监控的是决策模式/交互结构，不看对话内容（保隐私）。
  3. 部署要协调：agent 是高度有状态的网、几乎一直在跑，更新时它们可能停在流程的任意位置。用 rainbow deployment——新旧版本同时跑，流量渐进从旧切到新，不打断正在跑的 agent。
  4. 同步执行瓶颈：lead 同步等每一批 subagent 跑完，实现简单但堵信息流（lead 无法中途指挥 subagent，subagent 之间无法协调，一个卡住全系统等）。异步能加并行，但结果协调、状态一致、错误传播都更难。作者预期未来的收益会盖过复杂度。

附录还有两点值得记：对会改状态的 agent 做”终态评测”；长程对话管理——总结已完成阶段、要点存外部记忆、接近上限时用干净上下文 spawn 新 subagent 做交接、从记忆取回研究计划；subagent 的输出落文件系统，只回传轻量引用，少走”传话游戏”。

讨论：trace 可以不止是给人看的黑盒

我想在这里比原文多走一步（下面是我自己的一点见解，仅供参考）：

  • 原文的 full production tracing 只做到”给人诊断失败”，而且刻意不看对话内容；rainbow deployment 只做到新旧并存、渐进切流量。两者都没有节点级的”变化记录”，也没让 agent 自己用。
  • 我的想法是：trace 应记录关键节点处的变化，让 agent 自己也能回答”当时为什么这样做”——不只是人看的黑盒。

真要落地，一种可行的拆法是：事实层（可自动采、可信：节点/触发/候选/选中/结果）+ 解释层（agent 当时的自述，只当假设不当结论）。节点粒度卡在”有选择的地方”——选了 A 没选 B，才算一个节点。这层正好对应中篇 的两个难点：调试追踪，以及长任务跑一半 agent 被更新、行为漂移后的归因。

下篇 · Context Engineering：焦点回到最稀缺的资源

原文：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

主旨：把 harness 里”上下文管理”这个部件正式命名，并从第一原理解释为什么需要它。

从 prompt engineering 到 context engineering

prompt engineering 关心怎么把话说对，偏一次性，主要针对 system prompt；context engineering 关心在整个推理过程中策展并维持那组”最优 token”——系统指令、工具、MCP、外部数据、消息历史，所有落进窗口的东西都算。

区别的关键在”迭代”：prompt 是一次写好，而上下文是每决定一次”给模型什么”，就重新策展一次。

为什么：注意力是有预算的

窗口不是越大越好。needle-in-a-haystack 一类测试发现了 context rot——窗口里 token 越多，模型准确召回信息的能力越弱。各模型退化速度不同，但都存在。

原因在架构：transformer 里每个 token 都要注意其他所有 token，n 个 token 就是 n² 对关系，上下文越长注意力摊得越薄；再加上训练语料里短序列远多于长序列，模型对长程依赖本就经验少。所以表现出来是一条渐变的性能曲线而非断崖——长上下文里模型仍能干活，但精度和长程推理会打折。

结论：上下文是有限的”注意力预算”，每加一个 token 都在花它。好的上下文工程，就是找到”能最大化目标概率的最小高信号 token 集”。

有效上下文的解剖

  1. system prompt：清晰、直接、在”正确高度”。太低=把脆弱逻辑硬编码进提示词，越维护越烂；太高=含糊到假设共享上下文，给不出具体信号。要分节写（background / instructions / tool guidance / output）。目标是”最小但完整”——minimal 不等于 short。做法是先用最强模型测最小版本，再按失败模式加。
  2. tools：工具是 agent 与信息/行动空间的契约，必须 token 高效、功能不重叠、自包含、抗错、用途清晰。最常见的坑是工具集臃肿、选择歧义——人都说不清该用哪个，别指望 agent 不迷糊。
  3. examples：few-shot 依然强烈推荐，但要精选少量、多样、典型的例子，而不是堆一串边缘 case。对模型来说，例子是”一张顶一千字的图”。

运行时检索：Just in Time

过去主流是”预检索”：先算好相关数据再喂模型。agent 时代出现另一条路——Just in Time：不预加载全部，只留轻量标识（文件路径、查询、链接），运行时用工具按需取。

Claude Code 就是这么干的：分析大数据库时不把整块数据塞进窗口，而是写针对性查询、用 head/tail 之类命令去看，全程不把完整数据对象载入上下文。

这很像人的认知：我们不背下所有资料，而是靠文件系统、收件箱、书签，需要时再取。而且文件本身携带信号——名字、目录、时间戳都在提示用途和相关性。

由此引出渐进披露（progressive disclosure）：agent 一层层探索，每一步的结果为下一步提供线索，只把当下必要的留在工作记忆里。代价是运行时探索更慢、更依赖好的工具和启发式规则；所以也不排斥混合策略——一部分预取（比如 CLAUDE.md 直接进上下文），其余交给 glob/grep 即时导航。

长时程任务的三条路

当任务长到超过一个窗口（几十分钟到几小时的代码迁移、深度研究），就需要专门手段：

  1. compaction（压缩）：窗口快满时总结内容、开一个新窗口。Claude Code 的实现里，模型保留架构决策、未解决的 bug、实现细节，丢掉冗余的工具输出，再带上最近访问的 5 个文件继续。诀窍在”留什么”——先追求 recall（别漏），再提 precision（去冗余）。最安全的轻量形式是清掉早已用完的工具结果。
  2. structured note-taking（结构化笔记 / agentic memory）：agent 定期把笔记写到窗口外的记忆里（NOTES.md、to-do），之后再拉回来。这是低开销的持久记忆。
  3. sub-agent 架构：与其让一个 agent 扛整个项目，不如让专门 subagent 用干净窗口做聚焦任务，主 agent 持高层计划做协调；subagent 可能烧几万 token 探索，只回一份 1–2k token 的摘要。关注点分离，详细上下文隔离在 subagent 内部。

怎么选：compaction 适合大量来回对话；笔记适合有清晰里程碑的迭代开发；多 agent 适合并行探索有收益的复杂研究。

Pokémon 与 memory tool

文章用 Claude 玩宝可梦举例，展示记忆如何改变 agent 能力。这是个非编程、长时程的任务：模型没被教任何记忆结构，却自己长出了进度账本、探索地图、成就清单、战斗策略，在窗口被压缩后靠着笔记继续玩下去——几乎就是 structured note-taking 的自发形态。

Sonnet 4.5 发布时，Anthropic 把这一模式产品化：公开 beta 的 memory tool，基于文件系统，让 agent 把信息存到窗口外，跨 session 建知识库、保项目状态。

所以这是一条连续谱：context（工作记忆）→ 任务内笔记文件 → 跨会话的长期记忆。压缩也好、落文件也好，本质是同一件事——把”不可靠、占预算”的长上下文，换成”可控、可检索”的外部存储。

串起来：一年里的三次表态

三篇文章不是并列的三块知识，而是一次重心转移：

  • 上篇关心”要不要”：给出积木和判断标准，公式是 agent = LLM + 工具。此时核心设计对象是工具/ACI。
  • 中篇关心”撑不撑得住”：agent 真的上线跑长任务后，麻烦全在系统层——状态、追踪、部署、同步瓶颈。工具退成一个部件。
  • 下篇关心”资源怎么花”：把最稀缺的资源（上下文/注意力）单独拎出来，给出策展方法。到这里，“多 agent”也被重新解释成”绕开上下文限制的手段之一”，与中篇的”多 agent 主要是能烧更多 token”是同一件事的两面。