AI Agent 入门：Anthropic 官方指南笔记

花时间翻了 Anthropic 那篇《Building Effective Agents》，顺手整理成学习笔记。

核心观点其实就一句：大多数成功的 Agent 实现，用的都是简单可组合的模式，而不是复杂的框架。

1. Agent 是什么：一句话 + 一个公式

先区分两个概念：

Workflows：通过预定义代码路径来编排 LLM 和工具，步骤是固定的
Agents：LLM 动态决定执行流程，自己选择下一步用什么工具

Agent 的核心循环就这一件事：

1	用户输入 → LLM 思考 → 决定（回复 or 调用工具）→ 执行 → 把结果喂回去 → 重复

LLM 是大脑，工具是双手，记忆是笔记本。

构建 Agent 的万能公式（套上去就能用）：

1	Agent = 角色 + 目标 + 工具 + 规则 + 输出格式

举个例子：

要素	内容
角色	加密项目研究助手
目标	找到准确信息并清晰总结
工具	网页搜索、文件搜索、计算器
规则	标注来源、不猜测、标注不确定的地方
输出格式	摘要 + 风险 + 机会 + 最终判断

2. 构建之前：先问自己四个问题

在写任何代码之前，先回答这四个问题。答清楚，第一版 Agent 一天就能出来。

目标是什么？ Agent 最终要产出什么？
需要什么信息？ 需要搜索网页？读文件？查数据库？
允许做什么操作？ 只能回答？能搜索？能写文件？能发邮件？
必须遵守什么规则？ 语气、格式、安全限制、不确定时怎么办？

3. 五种工作流模式

Anthropic 总结了五种常见模式，按复杂度从低到高：

Prompt Chaining（链式调用）

把任务拆成顺序步骤，每步的输出是下一步的输入。适合”先做A，再用A的结果做B”这种场景。

比如：写文案大纲 → 检查大纲是否达标 → 写正文。

Routing（路由）

先分类输入，再分发给专门的处理流程。核心价值是隔离不同类型的问题，避免互相干扰。

比如：客服问题分类 → 退款请求 / 技术支持 / 常规咨询走不同流程。

Parallelization（并行化）

两种形式：

Sectioning：拆成独立子任务同时跑，再合并结果
Voting：同一个任务跑多遍，用投票决定最终输出

适合需要多视角判断、或子任务相互独立的场景。比如代码安全审查，多个 prompt 各自挑刺，比一个 prompt 全面检查效果好得多。

Orchestrator-Workers（编排器-工人）

中心 LLM 动态拆解任务，分发给多个 Worker，再汇总结果。关键区别是子任务不是预定义的，而是由编排器根据输入决定的。

适合代码修改这类场景——每次要改哪些文件、改什么内容，输入不同结果就不同。

Evaluator-Optimizer（评估-优化）

一个 LLM 生成，另一个 LLM 评估，形成循环。适合有明确评估标准、迭代能带来可见提升的场景。

典型用法：翻译 + 评审 → 再翻译 → 再评审，直到达标。

4. 五种适合新手的 Agent 类型

不知道从哪开始？从这五种里选一个：

类型	用途	需要的工具
研究 Agent	收集信息并总结	网页搜索、文件搜索
内容 Agent	写作、改写、转化内容	文件访问、强系统提示词
工作流 Agent	执行可重复的业务流程	API 调用、分类规则
知识库 Agent	基于你的文档回答问题	文件搜索 / RAG
操作 Agent	在环境中执行操作	工具 + 权限 + 安全边界

新手建议：先从研究 Agent 或内容 Agent 开始，最容易出成果。

5. 工具使用的原则

Anthropic 提了一个有意思的概念：ACI（Agent-Computer Interface），对标传统的 HCI。工具设计比模型选择更重要。

什么时候需要工具？

LLM 能靠推理回答的 → 不需要工具（改写邮件、总结文本、解释概念）
需要外部数据或执行动作的 → 需要工具（查天气、搜新闻、算利息、读文件）

工具设计三原则

原则一：一个工具只做一件事

# ❌ 坏的设计
manage_files(action, file, destination, overwrite, format, permissions)

# ✅ 好的设计
read_file(path)
write_file(path, content)
delete_file(path)

原则二：告诉 Agent 什么时候用它

# ❌ 坏的描述
"计算器工具"

# ✅ 好的描述
"当需要进行数学计算时使用此工具。永远不要猜测计算结果。"

原则三：用真实场景测试，然后修

Agent 不调用工具 → 修工具描述
调用方式不对 → 修输入格式
瞎编结果 → 加更严格的规则

Anthropic 在开发 SWE-bench 编码 Agent 时，花在优化工具上的时间比优化整体 prompt 还多。

6. 记忆：大部分人想多了

这可能是最容易过度工程化的部分。

两种记忆，什么时候需要：

类型	什么时候需要
短期记忆	当前对话的上下文，SDK 默认支持，不用管
长期记忆	需要跨对话查信息时

决策流程：

Agent 不加记忆能正常工作吗？
    ├── 能 → 不加
    └── 不能 → 需要跨消息记住东西？ → 短期记忆
              需要查外部文档？ → 文件搜索（简单 RAG）

绝对不要过早上的东西：

向量数据库
Embedding
复杂的 RAG 管线

70% 的场景，不需要任何记忆就能工作。

7. 测试驱动：让 Agent 真正能用的关键

Agent 最终不好用，不是因为架构不对，而是因为提示词写得烂、没测试、期望不切实际。

测试方法

第一，用 AI 生成测试用例：

我构建了一个目标为 [xxx] 的 AI Agent。
请生成 15 个真实的用户输入：
- 混乱的
- 模糊的
- 真实世界风格的
包括边界情况和错误输入。

第二，像真实用户一样测试，别用理想输入：

# ❌ 别用理想输入测试
"请帮我分类这个账单请求"

# ✅ 用混乱真实的输入测试
"我又被扣钱了 怎么回事啊"

第三，失败了一次只修一个地方：

提示词不清楚？ → 改提示词
输出格式模糊？ → 加格式要求
缺工具？ → 加工具
缺规则？ → 加规则

8. 多 Agent 何时需要

99% 的人不需要多 Agent。 一个好 Agent + 好工具足够用。

只有这三种情况才需要多 Agent：

技能完全不同：一个负责研究，一个负责写作
有明确流水线：输入 → 分析 → 写作 → 输出
权限不同：一个只能读数据，一个能执行操作

如果真的需要，用最简单的模式：

1	用户 → 主 Agent → 按需调用其他 Agent

不要一上来就搞蜂群架构（Swarm）或全自主多 Agent 系统，很容易崩。

9. 构建路径（按这个顺序来）

一句话描述你的 Agent
用 AI 生成规格说明 + 系统提示词 + 测试用例（直接套公式）
构建最小可用版本（不要多 Agent、不要复杂记忆）
用 10 个真实场景测试
一次只改进一个方面：提示词 → 输出结构 → 示例 → 工具 → 记忆

这个顺序很重要，别跳步。

10. 核心结论

Anthropic 的三个核心原则：

保持简单 —— 设计复杂不等于效果好
透明可见 —— 明确展示 Agent 的推理步骤
ACI 优先 —— 像重视人机交互一样重视 Agent 与工具的接口

最后一句话值得记住：

构建正确的系统，而不是最复杂的系统。

参考来源