今天就来做一个 AI Agent吧-夜雨聆风

今天就来做一个 AI Agent吧

我今天就想做一个 AI Agent

Agent 是如何工作的
五种工作流
构建你的 Agent
使用工具
给 Agent 加上记忆
让 Agent 真正跑起来
多 Agent 协作
最后做个收尾总结

好，直接进入正题……

1. Agent 是如何工作的

这些基础知识很重要。要是不先搞懂，你连自己到底需不需要 Agent 都判断不了。所以……

这是所有 Agent 共用的核心循环：

用户输入 → LLM 思考 → LLM 决策（直接回复，或调用工具）→ 如果调用工具：执行工具并将结果返回给 LLM → 重复以上过程

LLM 是负责推理的“脑子”。工具是负责执行动作的“手”（比如计算器、网页搜索、文件读写）。记忆则是“记事本”，用来记录到目前为止发生了什么。无论你用的是 LangGraph、CrewAI、Anthropic 的 SDK，还是 OpenAI 的 Agents SDK，这些框架本质上都只是把这个循环做了一层抽象封装，并没有改变它的核心逻辑。

增强型 LLM

普通的 LLM 接收文本，输出文本。增强型 LLM 则在此基础上多了三种能力：

工具：模型可以调用的函数，例如计算器、数据库、API、文件操作等。Anthropic 和 OpenAI 都通过 JSON Schema 暴露工具能力；Anthropic 使用 input_schema，而 OpenAI 则把函数封装在带有 parameters 的 function 对象中。
检索：能够从外部来源拉取相关信息，例如搜索引擎、文档、向量数据库。
记忆：能够通过消息历史或其他持久化存储，在多轮交互中保留信息。

工作流 vs. 真正的 Agent

在选择实现方式时，“工作流”和“Agent”的区别非常关键。

工作流是确定性的：执行路径由你的代码控制，相同输入总会走相同流程。它适合步骤固定、边界清晰的任务，而且成本更低（因为需要的 LLM 调用次数更少）。

Agent 则是动态的：下一步做什么由 LLM 自己决定，它还可能反复调用工具。它更适合开放性任务，但成本也更高。判断自己到底需不需要做一个 Agent，最稳妥的起点通常是先从一个简单工作流开始，再看它是否真的有必要进化成自治 Agent。

2. 五种工作流

信不信由你，大多数问题其实根本不需要“完全自治”就能解决。下面这五种模式由 Anthropic 总结提出，也已经被广泛采用，基本覆盖了常见场景。每种模式都依赖增强型 LLM。

模式 1：提示链（Prompt Chaining）

它是什么：把一个任务拆成串行的多个步骤。每一次 LLM 调用都处理上一步的输出，并且可以在步骤之间加入程序化的“闸门”来校验质量。

适合什么时候用：当任务可以自然拆分成固定子任务时。你牺牲一点速度，换来更高准确性，因为每一步的 LLM 任务都更简单。

示例场景：先生成营销文案，再翻译；先写提纲，检查是否覆盖关键主题，再展开成完整文档。

模式 2：路由（Routing）

它是什么：先对输入进行分类，再把它分发给对应的专用处理器。每个处理器都使用为该类问题优化过的提示词。

适合什么时候用：当不同类别的输入需要完全不同的处理方式时。客服工单分诊就是经典案例。

模式 3：并行化（Parallelisation）

它是什么：同时发起多个 LLM 调用。分段式并行会把任务拆成互不依赖的子任务并行处理；投票式并行则是对同一任务执行多次，再聚合结果以提升置信度。

适合什么时候用：当子任务彼此独立时（分段式），或者当你需要对关键决策形成共识时（投票式）。

模式 4：编排者-执行者（Orchestrator-workers）

它是什么：由一个中心 LLM（编排者）动态拆解任务，并把子任务分配给多个执行 LLM。和并行化不同，这里的子任务不是预先定义好的，而是由编排者在运行时决定。

适合什么时候用：当任务复杂到你无法提前预测结构时。例如跨多个文件的代码生成、研究任务、报告写作。

模式 5：评估者-优化者（Evaluator-optimiser）

它是什么：一个 LLM 负责生成结果，另一个 LLM 负责评估并给出反馈。如果评估不通过，就把反馈送回去继续改，直到满足质量标准为止。

适合什么时候用：当你有清晰的评估标准，而且迭代优化确实能带来可衡量价值时。比如翻译、代码生成和写作任务。

3. 构建你的 Agent

那么，怎样把“我想让一个 Agent 帮我做 XYZ”变成一个真正可运行的东西？

最容易理解的方式是这样：

把这个任务写清楚
确定它需要哪些工具
告诉模型该如何表现
用 5 个真实案例测试它
只有在失败时，才增加复杂度

你不需要先精通五套框架，才能做出自己的第一个 Agent。对我们这种普通人来说，最好的起点是：

如果你想要一个像能干操作员那样工作的 Agent，能使用工具、文件、Shell 命令、网页操作，并且擅长编码工作流，那就选 Anthropic
如果你想要一个干净的开发者 SDK，带托管工具、任务交接（handoffs）、护栏（guardrails），并且能平滑走向生产环境，那就选 OpenAI

这份指南主要聚焦这两个。

最简单的思考模型

在构建 Agent 之前，先回答这四个问题：

最终结果是什么？Agent 到底要产出什么？

示例：

“研究一个主题并写出摘要”
“读取我的笔记并整理成抽认卡”
“查看支持请求并进行正确分流”
“比较多个产品并给出最佳选项”
“审核我的内容，并用我的语气重写”

它需要什么信息？它需要网页搜索、文件、数据库、表格、CRM，还是只需要用户发来的消息？
它被允许执行哪些动作？它只能回答问题吗？还是可以搜索？可以编辑文件？可以发送邮件？可以写代码？可以调用你自己的函数？
它必须遵守哪些规则？包括语气、格式、约束条件、安全规则、不确定时怎么办，以及什么样的结果才算“好”。

如果你能把这四个问题答清楚，通常一天之内就能做出第一版 Agent。

一个很实用的小技巧，后面我们会展开讲：你可以直接把自己的想法丢给 LLM，让它深入思考，替你把上面这些问题都回答出来。

在真正动手构建之前，如何用 AI 先把 Agent 设计出来

一个非常实用的做法是，在写代码之前，先用 Claude 或 ChatGPT 帮你把 Agent 定义清楚。

可以直接贴下面这样的内容：

我想构建一个 AI Agent。我的目标是：[描述你希望它完成什么]用户可能会提出类似这样的问题：[填写 5 个真实、具体的示例]这个 Agent 应该可以访问：[网页搜索 / 文件 / 计算器 / 自定义 API / 不需要其他能力]它必须始终：[列出不可妥协的规则]它绝对不能：[列出边界条件]请帮我把这些内容整理成：1. 一份清晰的 Agent 规格说明2. 一段系统提示词3. 一份工具清单4. 第一版开发路线图5. 10 个测试用例

就这一个提示词，就足够帮一个新手把模糊的想法变成一份可以真正开工的实现计划。

一个适合新手的 Agent 设计公式

每次都套用这个结构：

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

示例：

角色：XX项目研究助理
目标：查找准确信息，并清晰地总结出来
工具：网页搜索、文件检索、计算器
规则：必须标注来源，不要臆测，不确定时要明确说明
输出格式：摘要、风险、机会、最终结论

这就是大多数实用型 Agent 的基础骨架。

先从下面这五类新手 Agent 里挑一种开始

如果你是新手，别一上来就搞什么多 Agent 群体协作。先从下面这些类型里挑一个最实际的：

A-研究型 Agent

适用场景：你希望 Agent 帮你收集信息并做总结。

示例：

“研究一下脚踝扭伤后最好的康复训练动作”
“查一下某个加密协议的最新进展”
“对比三台笔记本电脑”

所需能力：

网页搜索
如果你希望它使用你自己的文档，还需要文件检索
清晰的输出格式

B-内容型 Agent

适用场景：你希望 Agent 帮你撰写、改写、总结，或转换内容形式。

示例：

“把我的笔记整理成一篇 newsletter”
“用我的品牌语气改写这段内容”
“总结这份会议纪要”

所需能力：

通常只需要一个足够强的系统提示词
可选的文件访问能力
你偏好风格的示例

C-工作流型 Agent

适用场景：你希望 Agent 按照一个可重复的业务流程来执行任务。

示例：

“给客服工单分类”
“把销售线索分发到正确类别”
“检查表单提交内容，并生成一版回复草稿”

所需能力：

清晰的分类体系
明确的规则
有时还需要自定义工具或 API 调用

D-个人知识型 Agent

适用场景：你希望 Agent 基于你自己的文档来回答问题。

示例：

“只使用我的 PDF 来回答”
“搜索我的笔记并解释这个主题”
“找出所有提到这个客户的地方”

所需能力：

文件检索或 RAG
明确要求它必须以所提供材料为依据，不能脱离材料乱答

E-操作型 Agent

适用场景：你希望 Agent 在某个环境中实际执行操作。

示例：

“读取这些文件并修改它们”
“搜索网页、整理结果，并保存成报告”
“执行 Shell 命令并帮我调试代码”

所需能力：

工具
权限
明确而严格的安全边界

Anthropic：理解如何构建你的第一个 Agent，最容易上手的方式

如果你希望模型能使用工具，并且能在某个环境里实际操作，那么 Anthropic 的 Agent 工具体系会特别有帮助。Claude Code 于 2025 年 2 月发布，之后 Claude Code SDK 又在 2025 年 9 月更名为 Claude Agent SDK。截至 2026 年 3 月，GitHub 上列出的当前版本是 v0.1.50。

什么情况下 Anthropic 是个好选择

如果你希望 Agent 具备以下能力，优先考虑 Anthropic：

读取、写入和编辑文件
使用 Shell 命令
搜索网页
使用 MCP 工具
擅长编码和技术类任务
像一个可靠的助手一样，按步骤推进工作

使用 Anthropic 时，你本质上在做什么

从新手视角看，其实你只是在做三件事：

给 Claude 一个明确的任务
给 Claude 一组可用工具
让 Claude 一直循环，直到任务完成

就这么简单。

新手示例：一个“研究并总结”的 Agent

假设你想要的是：

“一个能帮我研究某个主题，并写出一份清晰报告的 Agent。”

那么你的构建方案会是：

角色：高级研究助理
目标：查找准确信息，并清晰总结
工具：网页搜索，必要时加上文件访问
规则：标注来源；不确定时要明确说明；保持简洁
输出：要点总结 + 关键风险 + 结论

这些内容就能变成你的系统提示词：

SYSTEM_PROMPT = '''你是一个细心的研究助理。你的工作是帮助用户准确研究主题。在需要时使用工具。不要猜测。如果信息不确定或不完整，请清楚说明。始终产生：1. 总结2. 关键发现3. 风险或不确定性4. 最终结论'''

现在，用户就可以提这样的问题：

“研究一下最新的 AI agent SDK”
“对比 Anthropic 和 OpenAI，看看哪个更适合新手构建 Agent”
“找出三个高质量来源，并做总结”

到这里，它其实已经是一个真正可用的 Agent 了。

新手示例：一个基于文件的写作 Agent

也许你想要的是：

“读取我的笔记，再用我的语气把它们改写成一篇清晰的文章。”

那你的设计就会变成：

角色：写作助理
目标：把粗糙笔记整理成打磨过的成稿
工具：文件读取，必要时加文件写入
规则：保留原意、提升清晰度、匹配语气
输出：最终文章 + 可选的标题建议

这就比一个模糊的“内容型 Agent”要容易落地得多。

在真正构建 Anthropic Agent 之前，你应该先让 AI 帮你回答这些问题

你可以直接用 LLM 帮你把方案定义清楚：

帮我设计一个基于 Anthropic 的 Agent。我的目标是：[goal]我希望这个 Agent 能够：[list actions]我希望这个 Agent 使用这些工具：[list tools]我希望最终输出长这样：[format]请帮我生成：1. 一段强有力的系统提示词2. 一份最小可用工具清单3. 一个第一版 Python 示例4. 10 个测试提示词5. 提升可靠性的建议

这个提示词通常能帮你把 80% 的工作先铺好。

OpenAI：理解如何构建你的第一个 Agent，最容易上手的方式

OpenAI 于 2025 年 3 月 11 日发布了 Agents SDK，同时推出了 Responses API，以及内置的网页搜索、文件检索和计算机使用工具。到了 2026 年 3 月，Python 包 openai-agents 的版本是 0.13.1。

什么情况下 OpenAI 是个好选择

如果你想要下面这些特性，优先选 OpenAI：

一个非常干净的 Agent API
易于接入自定义函数工具
内置的托管工具
专家型 Agent 之间的任务交接（handoff）
护栏（guardrails）与链路追踪（tracing）
从原型走向生产环境的平滑路径

使用 OpenAI 时，你本质上在做什么

从新手角度看，整个构建过程就是：

创建一个 Agent
给它写清楚指令
需要的话，再加上工具
用真实用户请求跑起来

就这些。

新手示例：一个支持请求分流 Agent

假设你的目标是：

“读取传入的支持请求，并判断它属于计费、技术，还是销售问题。”

那它就会变成：

角色：支持请求分流助理
目标：正确给请求分类
工具：先不用，后面可以再加 CRM 工具
规则：只能选一个类别，并简要说明原因
输出：类别 + 原因

代码大概会长这样：

from agents import Agent, Runneragent = Agent(
name="Support Triage Agent",
instructions="""You classify customer requests.Choose exactly one category:- billing- technical- salesReply with:1. Category2. One sentence explaining why""",)result = Runner.run_sync(agent, "这个月我的订阅被收费了两次。")print(result.final_output)

到这里，它已经是一个有实际用途的 Agent 了。

新手示例：添加一个自定义工具

现在假设你想要的是：

“在需要的时候，帮用户完成计算。”

from agents import Agent, Runner, function_tool@function_tooldef calculate(expression: str) -> str:
import math
allowed = {k: v for k, v in math.__dict__.items() if not k.startswith("__")}
return str(eval(expression, {"__builtins__": {}}, allowed))agent = Agent(
name="Math Helper",
instructions="帮助用户解决数学问题。需要时使用计算器工具。",
tools=[calculate],)result = Runner.run_sync(agent, "10000 以 5% 的复合增长在 8 年后是多少？")print(result.final_output)

这时候，这个 Agent 就不只是陪你聊天了，它已经能够通过工具去执行实际动作。

新手示例：使用托管工具

OpenAI Agents SDK 还支持托管工具，例如网页搜索、文件检索和代码解释器。这些能力在 SDK 文档里都提供了辅助函数。对新手来说，你可以把它们理解成“预制能力”模块，直接挂到 Agent 身上，而不是每样都自己从零手写。

这意味着你可以构建出这样的 Agent：

“从网上研究这个主题并做总结”
“搜索我的文件，并基于文件内容回答问题”
“运行代码来分析这份数据”

在真正构建 OpenAI Agent 之前，你应该先让 LLM 帮你回答这些问题：

帮我设计一个 OpenAI Agent。我的目标：[goal]我希望它处理的任务有：[list tasks]我觉得它需要这些工具：[list tools]输出应该长这样：[format]请给我：1. 一段清晰的 Agent 指令块2. 一个最简单的第一版实现3. 一个在需要时带工具的版本4. 10 个测试提示词5. 常见失败模式，以及对应修复方法

如何定制你的 Agent，才能让它真按你的预期做事

新手最容易翻车的地方就在这儿：他们做出来的是一个“泛用助手”，而不是一个“具体 Agent”。

拿下面这份检查清单对照就行。

1、把任务范围收窄

不好的写法：

“帮我处理一些业务相关的事”

更好的写法：

“把销售电话整理成行动项摘要”
“把销售线索分类成高意向、中意向、低意向”
“研究加密项目，并输出风险、催化因素和最终判断”

2、定义输出格式

不好的写法：

“给我一个答案”

更好的写法：

“请返回：摘要、证据、风险、下一步建议”
“请返回 JSON，字段包括 category、confidence、explanation”
“请按 5 个标题输出项目符号列表”

3、提供示例(few-shot)

如果你在意语气、结构，或者分类质量，那示例会非常有帮助。

你可以直接告诉模型：

“下面是 3 个优秀输出示例”
“下面是 5 个请求分类示例”
“请严格按照这种风格来写”

4、只在必要时添加工具

如果任务只是改写笔记，就不要加网页搜索。如果答案应该完全来自提示词本身，就不要加文件访问。每多一个工具，复杂度就会上一个台阶。

5、用真实提示词测试，而不是只用理想化输入

要用真实用户会打出来的那种乱糟糟提示词去测。

不要只测这种：

“Please classify this technical issue”

还要测这种：

“my account is broken and i keep getting charged what do i do”

这才是真正能看出你的 Agent 到底在干嘛的时候。

你的构建路径可以这样走：

第 1 步：用一句话写清楚这个 Agent 是干什么的
示例：“我想做一个 Agent，把我零散的笔记整理成一份干净的每周 newsletter。”

第 2 步：让 Claude 或 ChatGPT 把这句话展开成：

一份 Agent 规格说明
一段系统提示词
一份工具清单
10 个测试提示词

第 3 步：先做出最小可用版本
先别搞多 Agent。先别上复杂记忆。除非真的需要，否则也别急着上 RAG。

第 4 步：拿 10 个真实案例去测试

第 5 步：一次只改一个东西

提示词
输出结构
示例
工具
记忆
检索

这个顺序很重要。别一股脑全扑上去，把自己绕晕了。

避免犯这个错

最大的错误，就是一上来就想做一个“全能超级 Agent”。

不要从这些东西开始：

网页搜索
文件检索
数据库访问
记忆
多 Agent 交接
复杂护栏
自定义仪表盘
20 个工具

你应该从这些开始：

一个明确任务
一个 Agent
一段清晰提示词
最多一到两个工具
五到十个真实测试用例

你真正更容易做成这件事的方式，就是别把自己先绕死，别一上来就过度复杂化。

实用总结：

现在你已经到第 3 部分的结尾了。这一部分讲的就是如何构建你的第一个 Agent。读到这里，你应该能明确说出：

我知道我的 Agent 是干什么的
我知道它需要哪些工具
我知道它该遵守哪些规则
我知道输出应该长什么样
我知道该从 Anthropic 还是 OpenAI 起步
我知道如何反过来利用 AI 帮我设计第一版

4. 使用工具

大多数人都会在这里搞错。

“工具越多 = Agent 越聪明” ->错。

更好的工具，才会让 Agent 更聪明。更少的工具，反而会让 Agent 更可靠。

理解工具最简单的方式

工具本质上就是：

“AI 靠自己做不到的东西”

例如：

计算数字
搜索网页
读取你的文件
发送邮件
查询数据库

第 1 步：先问自己一句，“这事真的需要工具吗？”

在你添加任何工具之前，先问：

模型能不能只靠推理就回答这个问题？
还是说，它确实需要真实世界的数据或执行动作？

示例：

不需要工具：

“改写这封邮件”
“总结这段文字”
“解释这个概念”

需要工具：

“现在天气怎么样？”
“搜索最新新闻”
“计算复利”
“从我的表格里拉取数据”

规则：

如果任务需要外部数据或实际动作，就用工具；如果不需要，就别加。

第 2 步：用 AI 帮你设计工具

我正在构建一个 AI Agent。我的目标是：[describe goal]我认为这个 Agent 需要完成这些事情：[list actions]这些任务里，哪些需要工具？我应该创建哪些工具？请尽量保持简单、最小化。请返回：1. 工具清单2. 每个工具的说明3. 每个工具所需的输入参数

这会帮你省下不少时间。

第 3 步：保持简单，别整花活

不好的工具设计：

manage_files(action, file, destination, overwrite, format, permissions)

更好的工具设计：

read_file(path)write_file(path, content)delete_file(path)

规则：

一个工具，只做一件清晰的事。

第 4 步：明确告诉 Agent 什么时候该用工具

大多数人就是死在这一步。

不好的写法：

“计算器工具”

更好的写法：

“当任务涉及数学计算时，必须使用这个工具。不要臆测计算结果。”

第 5 步：让 Agent 先失败，再修它

拿真实问题去测，例如：

“2^16是多少”、“计算10年7%的增长率”

如果它：

不用工具 → 修改工具描述
工具用错了 → 修改输入参数设计
出现幻觉 → 把规则收紧

现在你已经到第 4 部分结尾了，你应该知道：

你不需要很多工具
你可以用 AI 帮你设计工具
工具越简单，Agent 往往越好
工具说明往往比工具本身还重要

好，继续……

5. 给 Agent 加上记忆

很多人把“记忆”这件事复杂化得离谱。

你其实只需要理解一件事：

记忆只有两种

短期记忆（对话记忆）

它其实就是：

“到目前为止，对话里说过什么”

这个能力你默认就已经有了。

长期记忆（外部知识）

它指的是：

“Agent 之后还能查到的东西”

例如：

你的笔记
PDF
文档
数据库

你到底什么时候才真的需要记忆？

问自己：

Agent 是否需要跨多轮消息记住内容？→ 是 → 需要短期记忆
它是否需要使用外部文档？→ 是 → 需要长期记忆
否则 → 你大概率根本不需要记忆

第 1 步：让 AI 帮你判断自己需不需要记忆

我正在构建一个 AI Agent。我的目标是：[goal]这个 Agent 是否需要：1. 对话记忆？2. 外部知识（RAG）？如果需要，请解释为什么。如果不需要，也请解释为什么。请保持简单。

第 2 步：你有三个选择……

方案 A：不要记忆（从这里开始）

对大多数新手来说，这是最好的起点
适用于 70% 的场景

方案 B：对话记忆

大多数 SDK 已经内置处理了
你只需要别重置消息历史

方案 C：基于文件的记忆（轻量 RAG）

上传文档
使用文件检索工具

第 3 步：别一上来就玩过头

常见大坑：

加向量数据库
加 embeddings
加复杂流水线

而这时候你甚至都还没搞清楚自己到底需不需要它们。

规则：

如果你的 Agent 在没有记忆的情况下也能正常工作，那就不要加记忆。

好，现在你已经到第 5 部分结尾了，你应该知道：

大多数 Agent 并不需要复杂记忆
先从简单开始
只有出问题时，再补记忆

6. 让 Agent 真正跑起来

这里往往就是 Agent 要么做成了，要么做成一坨的分水岭。而很多 Agent 之所以很烂，通常都是因为：

提示词太差
没有测试
预期不切实际

所以……

第 1 步：用 AI 生成测试用例

我构建了一个 AI Agent，它的目标是：[goal]请创建 15 条真实感强的用户输入，要求：- 杂乱- 模糊- 符合真实世界表达方式另外还请包含：- 边界情况- 容易混淆的输入- 糟糕输入

第 2 步：像真实用户一样去测试

不要测试这种：

请对这个计费请求进行分类

要测这种：

“为什么他tm我又被收费了”

第 3 步：一次只修一个问题

当它失败时，问自己：

是提示词不清楚吗？
是输出格式太模糊吗？
是少了某个工具吗？
是少了某条规则吗？

第 4 步：用 AI 帮你调试 Agent

这是我的 Agent：这是我的输入：[input]这是它的输出：[output]问题出在哪？我该怎么修？请具体一点。

第 5 步：别太早发疯式加复杂度

先不要加：

多个 Agent
复杂工作流
自动化流水线

除非：

你的简单版本已经能稳定工作

现在你已经到第 6 部分结尾了，你应该知道：

测试就是一切
AI 可以帮你调试它自己
先修清晰度，再谈复杂度

下一部分……

7. 多 Agent 协作

这里特别容易一路跑偏。

很多人会觉得：

“Agent 越多 = 能力越强”

错。

永远先从一个 Agent 开始。

永远。

只有在这些情况下，才考虑增加：

任务边界已经明显可以拆开
一个 Agent 明显扛不住
不同角色之间差异非常大

只有 3 种情况，你才真的需要多个 Agent

技能不同

示例：

研究 Agent
写作 Agent

流程明确分段

示例：

输入 → 分析 → 写作 → 输出

权限不同

示例：

一个 Agent 只能读取数据
一个 Agent 可以执行动作

第 1 步：用 AI 帮你判断是否需要多个 Agent

我已经构建了一个 AI Agent。它的任务是：[describe]这个场景应该用：1. 单个 Agent2. 多个 Agent如果是多个 Agent：- 分别承担什么角色？- 为什么？请保持简单。

最稳妥的模式是 Supervisor 模式：

用户 → 主 Agent →（有需要时再调用其他 Agent）

不要一上来就做：

swarm
完全自治的多 Agent 系统

这玩意很容易碎一地。

第 2 步：角色命名保持简单

不好的写法：

“具备动态认知分层能力的 AI 战略 Agent”

更好的写法：

“研究 Agent”
“写作 Agent”

第 3 步：慢慢增加 Agent

起步：

1 个 Agent

然后：

最多先加到 2 个

只有在下面这种情况下再继续扩展：

你确实看到了真实收益

第 7 部分的结论是什么？

大多数人其实根本不需要多个 Agent
单 Agent + 好工具，通常已经够用
只有被现实逼到那一步时，再增加复杂度

8. 收尾总结

这份指南里最重要的洞见是：Agent 在概念上其实很简单，但在落地执行上要求很高。核心循环无非就是 LLM 思考、调用工具、重复推进，这些逻辑 50 行 Python 可能就能写完。真正的工作量，藏在工具设计、错误处理、评估机制，以及判断什么时候应该用更简单模式（比如提示链、路由）而不是自治 Agent 里。

给刚开始上手的人，三个可执行建议：

先亲手做一个从零开始的 Agent。理解最原始的循环，会让所有框架都变得“透明”而不是“玄学”。这样你排查问题会更快，选工具也会更准。
从能跑通的最简单模式开始。提示链足以处理大多数多步骤任务；路由模式足以处理大多数“先分类再执行”的流程。只有当你真的需要让 LLM 动态决定执行路径时，再升级到自治 Agent。
尽早把精力投入在工具设计和评估上。一个命名清晰、描述准确、错误信息结构化的工具，对 Agent 表现的提升，往往比你换模型、换框架更大。而 20 个高质量测试用例，通常也比一大堆手动乱测更能抓出真实问题。

这个领域变化很快。MCP 在不到一年里就成了通用标准，两家头部厂商都推出了 Agent SDK，新框架几乎月月冒头。但这份指南讲的基本功并没有变：Agentic Loop、五种工作流模式、好的工具设计原则，以及“先从简单开始”的纪律。把这些学扎实，后面不管世界怎么变，你都能跟得上。

你现在已经能自己构建一个 Agent 了。