Claude Code是当下最好的Coding Agent，甚至可以说是当下最好的Multi-Agent系统。有人认为Anthropic在对Agent的理解上超过了OpenAI。
为了验证上面的观点，我整理了一下Anthropic官网发表的8篇Blog，希望可以明白Anthropic视角下对Agent的理解。
01Contextual Retrieval
结合Embedding(RAG)，BM25，上下文增强和reranking提高检索能力。
Introducing Contextual Retrieval
www.anthropic.com/engineering/contextual-retrieval
1. RAG的缺陷
知识库较小时可以直接放入上下文，知识库较大时我们通常会使用RAG。
由于RAG基于语义匹配，所以它有时候反而会丢失精确匹配的文本。精确匹配常见的算法是BM25(基于TF-IDF, 词频-逆文档频率，也就是我们常说的倒排索引）
结合RAG和BM25可以规避我们上面说的精确匹配结果丢失问题。
Anthropic给了一张图：
对chunks并行做RAG和BM25，然后对结果进行合并和去重，丢给模型。
2. 上下文增强
缺乏上下文的RAG通常会丢失一些语义，导致RAG效果变差。博客中给了一个例子。
原始的chunk
original_chunk="The company's revenue grew by 3% over the previous quarter."补充了上下文的chunk
contextualized_chunk="This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter."Anthropic的博客中认为，为一个孤立的chunk添加相关的上下文以后效果会更好。
怎么添加上下文呢？——使用Prompt让模型提供chunk的上下文，并使用整个文档的上下文来解释该chunk。
<document> {{WHOLE_DOCUMENT}}</document>Here is the chunk we want to situate within the whole document <chunk>{{CHUNK_CONTENT}}</chunk>Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.加入上下文增强以后的流程如下：
利用Prompt为Chunk添加50-120 token的context
3. Rerank
在最后的步骤，通过重排减少返回的chunk的数量，只取前K个块。
这里的重排是为了把“最相关”的信息传递给LLM，LLM处理的信息更少，从而可以提供更相关的结果（避免无关信息在上下文的干扰），同时降低成本和延迟。
4. 思考
上下文检索这里除了众所周知的RAG，还结合了一些传统的搜索技术。
02
Build Effective Agents
Building effective agents
www.anthropic.com/engineering/building-effective-agents
- 普通调用、workflow、Agent
能用单次调用解决，就不要用workflow，能用workflow解决，就不要上Agent。workflow适合固定流程的任务。Agents适合灵活、需要自主决策的任务。
2. 构建workflow的几种方式
文中提到了几种常见的workflow构建方式：
- Augmented LLM：LLM + 检索/工具/记忆。
- Prompt Chaining：分步骤处理任务。
- Routing：输入分类，分配给不同下游任务。
- Parallelization：任务并行，或多次生成投票。
- Orchestrator-Workers：中心 LLM 分解任务，子 LLM 执行。
- Evaluator-Optimizer：一个 LLM 生成，另一个评估并迭代优化。
3. 实现Agent
Agent的实现通常很简单——LLM基于环境反馈来循环使用工具。
最简Agent实现方式
4. 把Agent当成你的用户
对LLM来说JSON比markdown更难写：与 markdown 相比，在 JSON 中编写代码需要额外转义换行符和引号。
这里建议在Agent-计算机交互上投入很多精力，投入和类似人机交互（HCI)设计一样的精力。
5. 如何构造好的工具
(1)设身处地为Agent着想：根据工具的描述和参数，能不能快速读懂怎么使用这个工具？
(2)视角：想象为团队内的初级成员编写函数注释
(3)Anthropic的博客中还提及，他们花在优化工具上的时间比优化整体提示的时间还要多。
一个例子：在coding agent的构造中，发现使用相对路径容易出错，因此尽量使用绝对路径。
6. 思考
这里有个很有趣的视角是，把Agent当成你的用户，想一下如果你是Agent，你能不能理解这些工具是怎么用的？我认为这里的假设条件是认为模型本身就具有思考和行动的能力，它只是缺乏合适的工具。
这里我想到了之前看到的一个观点：把LLM当成大二的实习生(https://www.stochasticlifestyle.com/a-guide-to-gen-ai-llm-vibecoding-for-expert-programmers/)
他们了解编程的基础知识，可以借鉴其他的想法和架构，知道如何运行单元测试，也知道如何用谷歌搜索。他们上过基础编程课程，可能还深入研究过某个高级课程，但如果你经常就某个主题进行测试，你会发现他们实际上并没有深入学习。
可以引申出的是：LLM具有一定的自主能力，但是缺乏背景信息，需要你把背景信息丢给它。但是你也不能把所有信息一股脑地丢给他，你应该给他任务相关的、易于阅读的信息，然后它就可以协助你完成任务。
03
SWE-Bench
这篇文章主要讲述了Anthropic团队在提高SWE-bench跑分过程中构造Agent的一些经验，也有很多可取之处。
Raising the bar on SWE-bench Verified with Claude 3.5 Sonnet
www.anthropic.com/engineering/swe-bench-sonnet
SWE-Bench是一个AI评估集，测试模型如何解决来自热门开源Python代码库的GitHub问题。它可以同时衡量Agents工程化能力和模型性能。
1. 轻量脚手架 + 通用工具 + 强大模型
这篇博客叙述的解决流程中，只提供Prompt、Bash Tool 和 Edit Tool，让模型自主决定解决流程。
Prompt:只给出大致步骤，不进行强制和严格的限制，让模型可以灵活探索。
**Tool:**提供可以执行Bash命令的Bash Tool、可以查看和编辑文件的Edit Tool。
- Bash Tool：执行命令，强调使用约束（无网络、避免大输出等）
- Edit Tool：查看/编辑文件，支持
view、create、str_replace、insert、undo_edit
工具描述经过了大量打磨，避免模型误用，例如强制使用绝对路径。
文件编辑采用字符串替换，确保修改唯一性，提高可靠性。
2. 详细的Prompt与Tool描述
Prompt
<uploaded_files>{location}</uploaded_files>I've uploaded a python code repository in the directory {location} (not in /tmp/inputs). Consider the following PR description:<pr_description>{pr_description}</pr_description>Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!Your task is to make the minimal changes to non-tests files in the {location} directory to ensure the <pr_description> is satisfied.Follow these steps to resolve the issue:1. As a first step, it might be a good idea to explore the repo to familiarize yourself with its structure.2. Create a script to reproduce the error and execute it with `python <filename.py>` using the BashTool, to confirm the error3. Edit the sourcecode of the repo to resolve the issue4. Rerun your reproduce script and confirm that the error is fixed!5. Think about edgecases and make sure your fix handles them as wellYour thinking should be thorough and so it's fine if it's very long.Bash Tool
{ "name": "bash", "description": "Run commands in a bash shell\n* When invoking this tool, the contents of the \"command\" parameter does NOT need to be XML-escaped.\n* You don't have access to the internet via this tool.\n* You do have access to a mirror of common linux and python packages via apt and pip.\n* State is persistent across command calls and discussions with the user.\n* To inspect a particular line range of a file, e.g. lines 10-25, try 'sed -n 10,25p /path/to/the/file'.\n* Please avoid commands that may produce a very large amount of output.\n* Please run long lived commands in the background, e.g. 'sleep 10 &' or start a server in the background.", "input_schema": { "type": "object", "properties": { "command": { "type": "string", "description": "The bash command to run." } }, "required": ["command"]Edit Tool
{ "name": "str_replace_editor", "description": "Custom editing tool for viewing, creating and editing files\n* State is persistent across command calls and discussions with the user\n* If `path` is a file, `view` displays the result of applying `cat -n`. If `path` is a directory, `view` lists non-hidden files and directories up to 2 levels deep\n* The `create` command cannot be used if the specified `path` already exists as a file\n* If a `command` generates a long output, it will be truncated and marked with `<response clipped>` \n* The `undo_edit` command will revert the last edit made to the file at `path`\n\nNotes for using the `str_replace` command:\n* The `old_str` parameter should match EXACTLY one or more consecutive lines from the original file. Be mindful of whitespaces!\n* If the `old_str` parameter is not unique in the file, the replacement will not be performed. Make sure to include enough context in `old_str` to make it unique\n* The `new_str` parameter should contain the edited lines that should replace the `old_str`",...3. 实际运行的例子
(1)说明需要解决的任务
<uploaded_files>/repo</uploaded_files>I've uploaded a python code repository in the directory /repo (not in /tmp/inputs). Consider the following PR description:<pr_description>linear_model.RidgeClassifierCV's Parameter store_cv_values issue#### DescriptionParameter store_cv_values error on sklearn.linear_model.RidgeClassifierCV#### Steps/Code to Reproduceimport numpy as npfrom sklearn import linear_model as lm#test databasen = 100x = np.random.randn(n, 30)y = np.random.normal(size = n)rr = lm.RidgeClassifierCV(alphas = np.arange(0.1, 1000, 0.1), normalize = True, store_cv_values = True).fit(x, y)#### Expected ResultsExpected to get the usual ridge regression model output, keeping the cross validation predictions as attribute.#### Actual ResultsTypeError: __init__() got an unexpected keyword argument 'store_cv_values'lm.RidgeClassifierCV actually has no parameter store_cv_values, even though some attributes depends on it.上面的任务说明中说明了代码仓库已经被下载到什么位置，需要Agent帮忙解决PR中的问题。
回看上文，在2中的Prompt给了建议的操作路径：探索仓库结构->重现错误->修改代码->重新运行->思考边界case
(2) Agent的运行步骤
str_replace_editor(command=view,path=/repo) 查看仓库结构
str_replace_editor(command=create, path=/repo/reproduce_error.py, file_text=…) 来重现错误
bash(command=python3 /repo/reproduce_error.py)执行编写的脚本
str_replace_editor, command=replace 编辑代码
这里值得注意的是编辑工具中的replace用的不是告诉Agent需要编辑第几行，而是告诉Agent需要全匹配哪些文本然后替换。
我们尝试了几种不同的策略来指定对现有文件的编辑，其中字符串替换的可靠性最高，即模型指定将给定文件中的“old_str”替换为“new_str”。只有当“old_str”恰好有一个匹配项时，才会进行替换。如果匹配项过多或过少，则会向模型显示相应的错误消息，以便其重试。
此外，原文中这里提供的上下文都是THOUGHT（模型的文本输出）、ACTION（工具调用参数）和OBSERVATION（工具调用的部分结果）三段，我也怀疑就是Claude Code里使用的上下文模式。（之前网上有泄漏Claude Code的提示词，之后可以对照看看）
4. 思考
这里想到了早期的斯坦福小镇的项目，让模型自己扮演人的角色。模型其实本身具有决策和思考的能力，如果你给良好的工具描述和结果反馈，其实他可以像人一样处理问题。
如果你制定了许多规则，对于人来说本身就很困扰，对于模型也是如此。
04
Claude Think Tool
这篇文章主要讲了为Claude单独构造一个“思考工具”（Think Tool）
The “think” tool: Enabling Claude to stop and think in complex tool use situations
www.anthropic.com/engineering/claude-think-tool
- Think Tool的作用
Think Tool的作用是：在执行过程中添加一个步骤，来停下来思考是否掌握了继续前进所需的所有信息
Anthropic的博客中认为：这在执行长链工具调用或与用户进行长时间的多步骤对话时尤其有用。
Claude使用Think Tool进行的推理不如通过模型自带思考模式获得的推理全面，但是更侧重于模型发现的新信息。
Think Tool的描述
{"name":"think","description":"Use the tool to think about something. It will not obtain new information or change the database, but just append the thought to the log. Use it when complex reasoning or some cache memory is needed.","input_schema":{"type":"object","properties":{"thought":{"type":"string","description":"A thought to think about."}},"required":["thought"]2. Think Tool的使用场景
(1)什么时候可以用？
- 对先前工具输出进行分析：Claude 在采取行动之前需要仔细处理先前工具调用的输出，并且可能需要在其方法中回溯；
- 限制比较多的时候：当 Claude 需要遵循详细的指导方针并验证合规性时（比如航空公司的条约）
- 需要顺序性地做决策：当每个动作都建立在前一个动作的基础上时，错误的代价比较高昂。
(2)什么时候不用？
- 非顺序的工具调用：如果 Claude 只需要进行一次工具调用或多次并行调用即可完成一项任务，那么添加“思考”不太可能带来帮助。
- 只需要遵循简单的指令的时候：当 Claude 需要遵循的约束不多，并且其默认行为足够好时，额外的“思考”不太可能带来好处。
文中提到，增加了Think Tool以后显著提高了在SWE-Bench上的跑分。
3. 思考
结合前面的把Agent当成用户的想法，人类在面对庞大的信息、较多的限制的时候需要停下来思考来整理信息、满足规约，那么对于Agent也是如此。人类可以无声地思考，并且在后续行动中用上自己在脑海里思考过的结论。但是对于LLM来说，它只能输出显式的文本，然后添加到上下文里。
05
Claude Code Best Practices
这篇文章主要讲了怎么用好Claude Code(使用技巧)，但是也能从中窥见一部分设计理念。在下面我只选取了我认为对我理解Claude设计理念有效的部分进行解读。
Claude Code: Best practices for agentic coding
www.anthropic.com/engineering/claude-code-best-practic
1. 提供接近原始模型的使用机制
在博客中提到：
Claude Code is intentionally low-level and unopinionated, providing close to raw model access without forcing specific workflows. This design philosophy creates a flexible, customizable, scriptable, and safe power tool. While powerful, this flexibility presents a learning curve for engineers new to agentic coding tools—at least until they develop their own best practices.
Claude Code 刻意追求低级和开放性，提供接近原始模型的访问，而无需强制执行特定的工作流程。这种设计理念打造了一个灵活、可定制、可脚本化且安全的强大工具。虽然功能强大，但这种灵活性对于刚接触AI编码工具的工程师来说，学习难度较高——至少在他们开发出自己的最佳实践之前是这样。
Claude Code给用户的体验接近于直接调用大模型，让用户跟像普通大模型对话那样输入指令。
2. 项目记忆 CLAUDE.md
CLAUDE.md: 类似“项目记忆”。支持自动加载项目中的约定（命令、代码规范、测试说明、repo 规则等）。
在发起一个会话时，CLAUDE.md会被自动拉入上下文中。
博客原文中提及：“There’s no required format forCLAUDE.mdfiles. We recommend keeping them concise and human-readable.” 与Anthropic之前博客中提到的需要让模型接收人类易读的文本的观点类似。
3. think hard
在原文关于使用Claude的工作流程中，一个有趣的点是你可以通过特定的词汇控制Thinking过程的Token上限。
We recommend using the word “think” to trigger extended thinking mode, which gives Claude additional computation time to evaluate alternatives more thoroughly. These specific phrases are mapped directly to increasing levels of thinking budget in the system: “think” < “think hard” < “think harder” < “ultrathink.” Each level allocates progressively more thinking budget for Claude to use.
我们建议使用“思考”一词来触发extended thinking mode，这能为Claude提供额外的计算时间，以便更彻底地评估各种替代方案。这些特定的词汇会直接映射到系统中不断提升的思考预算级别：“思考”< “认真思考”< “更加努力思考”< “超级思考”。每个级别都会逐步为Claude分配更多的思考预算。(实际上就是thinking可以使用的Token数量）
06
Multi Agent Research System
How we built our multi-agent research system
www.anthropic.com/engineering/multi-agent-research-system
1. Multi Agent适合解决不可预测的问题
Research工作由于设计开放式问题，很难提前预测步骤，并且通常需要根据研究过程中出现的线索来更新Research的方式。
这种不可预测性很适合由AI Agents完成。
2. The essence of search is compression
本文认为：搜索的本质是一种压缩——搜索的核心任务不是找到所有东西，而是从庞大的信息库（vast corpus）中提炼出最有价值的见解。就像把海量文本压缩成少数关键信息或结论。
多个子Agent各自拥有自己的上下文窗口，可以同时从不同角度去探索同一个问题。这样可以并行展开调查，然后再把重要的结果（tokens）浓缩、汇报给主Agent。
每个 subagent 可以有自己独立的工具 (tools)、提示词 (prompts)、探索路径 (exploration trajectories)，这样可以避免所有探索都沿着同一个思路走（path dependency），从而保证调查是独立、全面、多角度的。
3. Multi-Agent与人类社会
博客中提到了一个有趣的比喻：在过去十万年里，单个人类的智力水平可能比古人类高一些，但提升有限。
人类社会在信息时代却变得「指数级地更强大」，原因在于集体的智能和协调能力。不是因为个体突然变成「超人」，而是因为我们学会了沟通、协作、分工，才产生了更大规模的能力。
让多个Agent协作，就像人类社会一样，能完成远超个体的任务。
4. Multi-Agent有效是因为它可以消耗足够多的token
这一段认为，Multi-Agent架构的价值在于：
(1)突破单个智能体的 token 限制（上下文 + 计算量）。
(2)通过并行化扩大推理能力。
——这对于那些超过单体能力上限的复杂任务特别关键。
下面给了个例子，在research工作中，可以通过创建subagent搜索一个问题的多个角度。
Research系统中的MultiAgent架构
下面是上面架构图中的时序流程，简单总结地话Research的过程是一个Loop，这里把Loop用时序图展示了出来。
Multi-agent的工作流程
上面两张图实际以DeepResearch为例叙述了Multi-Agent系统的工作流程。
5. 构造Prompt的经验
这里篇幅内容很长，并且我觉得很有用，就直接翻译以后摘取过来了，没有做过多删减。
Multi-Agent也带来了协调复杂性(coordination complexity)的指数增长，Prompt Engineering是改进Agent行为的重要手段，有一些构造Prompt的原则可以参考：
(1)站在Agent的角度思考
想要优化与迭代Prompt必须先了解已有的Prompt引导了怎样的行为。这要求开发者设身处地从Agent的“思考过程”去看它是怎么工作的。
为了做到这一点，Anthropic团队使用Console构建了模拟环境，并配备了系统中实际使用的提示和工具，然后观察Agent的每个动作。
是否可以认为在Claude Code中给Agent一个Terminal环境的作用是提供一个类似人机交互的环境？而Terminal是最简单的人机交互环境，并且Terminal刚好是文字性的是模型可以理解的。
那么从这个视角来说纯CodeAct不那么好用的原因是code不能给Agent完整的可操作环境。
通过模拟，可以清楚地看到Agent在什么地方容易出错，例如：已经有了足够的结果却还在继续搜索;太冗长、不必要的搜索路径;选择了错误的工具。
开发者需要理解Agent为什么会做出某些选择（思考路径），这样才能知道调整提示词时，哪些改动最有可能带来显著改进。
这里原文中用了“心智模型”(mental model)一词。Prompt可以塑造Agent的行为；“心智模型”是在你脑子里，用来理解和预测 agent 的反应，如果你发现agent跟你的想法不一致，你就可以调整prompt.
(2)教会协调者（主Agent）如何分解任务。
主Agent将query分解为子任务，并将它们描述给subagent。
每个subagent都需要任务目标、输出格式、工具的描述和使用方式、以及清晰的任务边界。
如果没有详细的任务描述，代理就会重复工作、遗漏工作，或者找不到必要的信息。
(3)提示主Agent根据任务复杂度调整拆分出的subagent数量。
主Agent实际难以判断不同任务的工作量（拆分任务是你的系统里的设计，不是模型训练中的先验知识），因此Anthropic团队认为需要在Prompt中明确写出给subagent分配任务的规则。
Simple fact-finding requires just 1 agent with 3-10 tool calls, direct comparisons might need 2-4 subagents with 10-15 calls each, and complex research might use more than 10 subagents with clearly divided responsibilities. These explicit guidelines help the lead agent allocate resources efficiently and prevent overinvestment in simple queries, which was a common failure mode in our early versions.
简单的事实调查只需1个agent调用 3-10 个tool；直接的比较可能需要 2-4 个agent，每个agent调用 10-15 tool；而复杂的研究可能需要 10个以上的subagent，并明确划分职责。这些明确的指导原则有助于主agent高效地分配资源，并避免在简单查询上投入过多资源——这在早期版本中是一种常见的失败模式。
(4)工具的设计和选择是至关重要的
Agent-tool interfaces的重要程度等同于human-computer interfaces（人机交互）。
让Agent使用正确的工具也非常非常重要。那么，怎么保证Agent可以选择正确的Tool呢？
Anthropic团队为Agent提供了启发式的策略：比如，首先检查所有可用的工具列表，将用户意图与工具用途相匹配，用websearch做外部的探索。如果有专用的工具，优先选择专用的工具而不是通用的工具。
启发式是一种“经验规则”或“聪明的猜测”，它不是保证最优解的严格算法，而是依赖一些近似规则、直觉或模式 来快速缩小探索范围。当我们说让Agent进行启发式的探索，意思是：不要求 Agent 把所有可能路径都尝试一遍（那会消耗巨大算力和 token）。而是给 Agent 一些策略性引导，让它：优先尝试更可能有用的思路，在探索中不断调整方向，避免陷入冗余、低效的操作。
坏的工具描述会严重误导智能体，因此每个工具必须有明确的定位和清晰的说明，让智能体能准确理解该工具的用途。
(5)让Agent自我提升
Anthropic团队发现，Claude 4 模型自己本身就可以成为优秀的Prompt工程师。
当给出提示和错误时，Claude 4模型本身能够诊断Agent失败的原因并提出改进建议。
Anthropic团队创建了一个tool-testing agent——当agent拿到一个有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免错误。通过数十次的工具测试，tool-testing agent发现了关键的细微差别和错误。
(6)先广后窄
搜索的策略可以模仿人类的research流程：先进行全局探索，再深入细节挖掘。
在不做引导的情况下，Agent通常很容易生成输入过长、具体的query，导致结果很少。
Anthropic团队会鼓励Agent（就是Prompt引导）先从简短、宽泛的查询开始，评估可用的内容，然后逐步缩小范围。
(7)引导思考过程
Claude模型有一个Extended Thinking模式，测试表明，Extended Thinking可以提高指令遵循能力、推理能力和效率。subagent使用了Interleaved thinking，导致subagent能够更有效地适应任何任务。
根据 Anthropic的官方资料：Extended Thinking是 Anthropic 给其 Claude 模型（尤其是 Claude 3.7 Sonnet 以及更新模型）加入的一种新的思维/推理模式，它主要让模型在面对复杂问题时能“多花一点时间，多做一步推理，并把思考过程部分可见化”。
(8)并行工具调用
复杂的Research任务需要探索许多来源。博客中提到他们团队的早期的Agent执行是串行执行的，所以很慢。
后续他们引入了两种并行的方式：
a.主Agent并行（而非串行）启动 3-5 个subagent；
b.子代理并行使用 3 个或以上工具。
这种并行处理将复杂query的research时间缩短了90%。
6. 如何进行评估？
在比较传统的评估方式里，通常假设AI每次都遵循相同的步骤：给定输入 X，系统应该遵循路径 Y 来产生输出 Z。
但对于Multi-Agent系统来说，即使起点相同，Agent也可能采取完全不同的路径来实现其目标。
一个Agent可能搜索3个source，而另一个Agent搜索10个，或者它们可能使用不同的工具来找到相同的答案。
而我们并不总是知道正确的步骤是什么，我们通常不能去检查Agent是否遵循了我们预先规定的“正确”步骤。
相反，我们需要灵活的评估方法来判断Agent是否在遵循合理流程、是否实现了正确的结果。
(1)LLM-as-judge
Anthropic团队引入了LLM 作为评委进行评估，评估标准如下：
事实准确性（论断是否与来源相符？）
引用准确性（引用的来源是否与论断相符？）
完整性（是否涵盖了所有要求的方面？）
source的质量（是否使用了一手资料而非质量较低的二手资料？）
工具使用效率（是否合理地使用了正确的工具？）。
Anthropic团队试过用多个 LLM 分别评判不同的指标，但效果不稳定。最后发现「用一次 LLM 调用，一个 prompt 生成所有指标的评分（0.0–1.0），再加一个通过/不通过的判定」最稳定，也最接近人工评价。
有明确答案时LLM评估最有效——当测试任务本身有明确标准答案时（例如“列出研发预算最高的三家制药公司”），LLM 评审可以直接检查答案是否正确。
(2)Human evaluation
自动化评测（LLM-as-judge）虽然高效，但无法覆盖所有情况。
有些边界case容易被漏掉，例如：模型在罕见问题上幻觉（hallucination), 系统性的错误（system failures), 很微妙的来源选择偏差（subtle source selection biases）
因此即使在自动化评估盛行的时代，人工测试仍然至关重要。
7. 定义分工、问题解决的方式、工作量预算
「Multi-agent systems have emergent behaviors」。即使只是对“主Agent(lead agent)”做了微小修改，也可能引发子Agent（subagents）行为上的不可预测变化。
对Multi-agent系统来说，好的 prompt 应当不只是给出严格指令（strict instructions），更应该提供一个协作框架（framework for collaboration），包括： 分工（division of labor），问题解决方法（problem-solving approaches），工作量预算（effort budgets）。这种框架能帮助多个代理更高效地协作、减少混乱。
8. 工程实践的经验
(1)Agent的有状态会导致错误的累加，直接重试代价很高昂，文中提及结合Agent自身处理能力的错误恢复机制很重要。
(2)除了监控常规系统的可观测性指标以外，Anthropic团队还监控Agent的决策模式和交互方法。这种高级别的可观察性可以协助诊断根本原因、发现意外行为并修复常见故障。
(3)使用Rainbow Deploys来避免中断正在运行的Agent——逐步将流量从旧版本转移到新版本，同时保持两个版本同时运行。
(4)同步于异步的权衡
顺序地同步地执行更好实现，但是效率低。
异步执行可以提高并发度：Agent可以并发工作并在需要时创建新的subAgent。但是，异步引入了更高的复杂度，在结果协调、状态一致性以及subagent之间的错误传播方面带来了挑战。
由于模型能够处理更长、更复杂的研究任务，Anthropic团队认为异步带来的性能显著提升可以弥补这种复杂性增加带来的代价。
07
Desktop
感觉没有什么值得参考的内容，主要是讲了怎么更方便地让用户用MCP? 先跳过了，后续再看看，毕竟常读常新。
Desktop Extensions: One-click MCP server installation for Claude Desktop
www.anthropic.com/engineering/desktop-extensions
08
Writing Tools for Agents
Writing effective tools for agents — with agents
www.anthropic.com/engineering/writing-tools-for-agents
1. Tool是确定性系统与非确定性系统之间的桥梁
确定性系统：给定相同的输入都会产生相同的输出(在传统的程序里，我们的代码是确定性的)。
非确定性系统（如Agent）：相同的输入会产生不同的输出。
而Tool是确定性系统和非确定性系统之间的桥梁。
Tool是为Agent提供API，函数是为软件开发者提供API。博客再次强调编写Tool最好的方式是提供对Agent来说最符合“人体工程学”的工具。
实现一个Tool的方式：先构造出一个Tool的原型，然后评估与迭代。
2. 合理评估Tool的方式
在评估的时候让Agent不止输出结构化的response，还输出自己的推理过程（CoT)。通读CoT可以发现Tool描述中存在的问题。
此外，Agent在推理过程中「没有提及的部分」也非常重要，这意味着Agent可能遗漏了什么。
也可以用可以用Judge Agent帮助你分析结果和改进工具。
3. 设计合适的Tool
LLM的上下文窗口有限，而计算机的内存和外存几乎无限。
设计原则：
少而精：优先构建能覆盖关键高价值任务的工具。
合并功能：工具可以在内部处理多个步骤，减少冗余输出。
例子：
不要做list_users/list_events/create_event三个工具→ 做个 schedule_event 工具，直接处理找空档+创建事件。
不要做 read_logs 工具 → 做一个 search_logs 工具，只返回相关日志片段。
不要分散在get_customer_by_id / list_transactions / list_notes → 做一个 get_customer_context 工具，一次性返回该客户的关键信息。
每个工具要有明确、独特的目的。避免太多、功能重叠的工具，因为这会让智能体难以选择，反而降低效率。
4. 准确地命名Tool
当工具功能重叠或用途模糊时，Agent可能会对使用哪些工具感到困惑。
命名空间（将相关工具分组到共同的前缀下）有助于区分众多工具之间的界限。例如，按服务（例如 asana_search 和 jira_search ）和按资源（例如 asana_projects_search 和 asana_users_search ）对工具进行命名空间划分，可以帮助Agents在合适的时间选择合适的工具。
前缀式（asana_projects_search）还是后缀式（search_asana_projects）命名对不同 LLM 的效果不同，最好用自己的LLM测试一下哪种更好。
有选择性地实现工具，名字要能体现自然的任务划分。这么做的好处是：
- 减少工具数量和说明冗余：让agent 上下文更干净，不会被几十条工具描述淹没。
- 把复杂推理交给工具本身处理**：**减轻 LLM 的上下文负担。
- 降低 agent 出错率：让agent更容易选对工具、传对参数，从而得到对的结果。
6. Tool应当返回有意义的上下文
(1)工具应优先返回与上下文相关的关键信息，而不是一堆底层技术细节。（高信号，低噪音）
(2)LLM 更擅长处理自然语言的名称或标签（User: Simith)，而不是复杂的随机ID（uuid: a38f2-2d9c-…）。
有些情况下，agent 既需要自然语言输出，也要能拿到ID（例如发消息时必须用 id=12345）。这种情况最好提供 response_format 参数，让 agent 控制输出格式：response_format=“concise” ,此时返回简洁的东西、自然语言为主。response_format=“detailed” ，此时返回的东西应当包含 ID 等字段。
(3)让agent自己选择要什么字段——就像GraphQL 查询一样灵活。这样既保证了灵活性，又避免在默认情况下淹没 agent 的上下文窗口。
(4)工具响应结构（例如 XML、JSON 或 Markdown）也会对结果产生影响。但是这里没有一刀切的解决方案。
这是因为 LLM 是基于next-token prediction进行训练的，并且倾向于使用与其训练数据匹配的格式来获得更好的性能。最佳响应结构会因任务和agent的不同而有很大差异。文中建议读者根据自己的评估选择最佳的响应结构。
7. Tool一次返回的内容不要太多
可以选择的策略：分页(page)、让agent进行范围查询(range selection)、过滤(filter)、截断(truncation)。
关于截断：需要在系统里约定一个token上限。如果必须截断，最好提示 agent 下一步该怎么做（例如：请改为更小、更具体的查询）。错误响应要清晰且可操作, 不要只返回冷冰冰的错误码或长堆栈,要提示具体问题和如何修正输入。
8. 怎么写工具的描述
像为团队中的新员工介绍一样描述您的工具：
- 明确输入输出格式；
- 解释专业术语；
- 描述资源之间的关系；
- 避免依赖隐藏的知识。
09
总结
本次阅读了Anthropic的8篇博客，后面几篇篇幅比较长，我在Agent工程实践中也做了类似的事情但是并没有总结归纳出“为什么”，因此这些博客极大地帮我加深了Agent领域的认知。
回归上篇提到的Claude Code可能是最好的Multi-Agent系统吗？我无法给出明确的答案，但是我可以确信Anthropic的确在Agent领域有极好的理解。
此外，Anthropic多次提到需要像设计人机接口一样为Agent提供工具说明、错误响应、友好提示。这里认为是LLM使用了大量的人类文本训练，因此提供易于人类阅读的文字也将对Agent有所帮助。为什么LLM可以推理和思考并且选择使用合适的工具？我想是因为文字本身包含了推理和思考信息，这让LLM也就有了类人的能力。
那么——AI的尽头是否是人类学呢？
那么，如何系统的去学习大模型LLM？
作为一名深耕行业的资深大模型算法工程师，我经常会收到一些评论和私信，我是小白，学习大模型该从哪里入手呢？我自学没有方向怎么办？这个地方我不会啊。如果你也有类似的经历，一定要继续看下去！这些问题啊，也不是三言两语啊就能讲明白的。
所以我综合了大模型的所有知识点，给大家带来一套全网最全最细的大模型零基础教程。在做这套教程之前呢，我就曾放空大脑，以一个大模型小白的角度去重新解析它，采用基础知识和实战项目相结合的教学方式，历时3个月，终于完成了这样的课程，让你真正体会到什么是每一秒都在疯狂输出知识点。
由于篇幅有限，⚡️ 朋友们如果有需要全套 《2025全新制作的大模型全套资料》，扫码获取~
👉大模型学习指南+路线汇总👈
我们这套大模型资料呢，会从基础篇、进阶篇和项目实战篇等三大方面来讲解。
👉①.基础篇👈
基础篇里面包括了Python快速入门、AI开发环境搭建及提示词工程，带你学习大模型核心原理、prompt使用技巧、Transformer架构和预训练、SFT、RLHF等一些基础概念，用最易懂的方式带你入门大模型。
👉②.进阶篇👈
接下来是进阶篇，你将掌握RAG、Agent、Langchain、大模型微调和私有化部署，学习如何构建外挂知识库并和自己的企业相结合，学习如何使用langchain框架提高开发效率和代码质量、学习如何选择合适的基座模型并进行数据集的收集预处理以及具体的模型微调等等。
👉③.实战篇👈
实战篇会手把手带着大家练习企业级的落地项目（已脱敏），比如RAG医疗问答系统、Agent智能电商客服系统、数字人项目实战、教育行业智能助教等等，从而帮助大家更好的应对大模型时代的挑战。
👉④.福利篇👈
最后呢，会给大家一个小福利，课程视频中的所有素材，有搭建AI开发环境资料包，还有学习计划表，几十上百G素材、电子书和课件等等，只要你能想到的素材，我这里几乎都有。我已经全部上传到CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
相信我，这套大模型系统教程将会是全网最齐全 最易懂的小白专用课！！
