这篇的底子是掘金上的一篇入门教程，智泊AI 的《AI Agent 保姆级教程 | 从 0~1 构建一个属于你的 AI Agent》。原文信息密度不低，但排得比较散，读完我自己又按理解重排了一遍，顺手把几处我不太同意的地方标出来。所以这篇不算翻译也不算转述，算读后重写：骨架是它的，话是我的。

先说结论，也是我觉得这篇原文最值钱的一句话：

Agent 的核心运行循环，五十行 Python 就能写完。

这话听着像劝退，其实是劝进。它的意思是：你卡住的地方，大概从来不是”框架没学会”。真正难的是工具怎么切、记忆放哪、测试怎么设计、以及什么时候该承认这活儿不需要 Agent。下面这套路线，就是按这个判断重排的。

01 Agent 是怎么转起来的

这一节不能跳。原因很实际：不搞清原理，你没法判断自己到底用不用得上 Agent。而”用不上”的情况比想象中多得多。

所有 Agent，不管挂着什么框架的名字，都在跑同一个循环：

  graph LR
A[用户输入] --> B[LLM 思考]
B --> C{做决定}
C -- 直接回应 --> D[输出结果]
C -- 调用工具 --> E[执行工具]
E --> F[结果回灌上下文]
F --> B
  

拆成三个零件看：

• LLM 是大脑，负责推理和决策；
• 工具是双手，干那些光靠推理干不了的事：算数、查库、读文件、发请求；
• 记忆是记事本，把之前发生过的事留住，让下一轮衔接得上。

LangGraph、CrewAI、Anthropic SDK、OpenAI Agents SDK，这些东西说白了都是把上面这个循环打了个包，加上重试、并发、状态持久化这些配套。循环本身一步没变。

增强型 LLM：循环的最小单位

裸的 LLM 就是文字进、文字出。加三样东西，它才够格进循环：

工作流还是 Agent，先分清

这是全篇最需要提前想明白的一道岔路：

• 工作流（Workflow）：路径是你定的。哪一步调哪个模型、走哪个分支，写在代码里。可预测、可复现、好排查。
• Agent：路径是模型定的。它自己决定调几次工具、按什么顺序、什么时候算完。灵活，但也更贵、更难复现、更难甩锅。

我的取向很明确：能用工作流解决的，别上 Agent。自主性不是免费的，你拿灵活性换走的是可控性，而线上出问题的时候，你要的恰恰是可控性。

02 五种核心工作流模式

这五种是 Anthropic 那篇 Building effective agents 里总结的，现在基本成了行业通用词汇。原文的说法我认同：大多数问题用不着完全自主的 Agent，这五种模式覆盖了日常的绝大部分场景。每一种都建立在上面那个”增强型 LLM”之上。

模式一：提示词链（Prompt Chaining）

把任务拆成固定的几步，顺着做，每次调用只处理上一步的产物。步骤之间还能塞程序化的检查点，验证不通过就不往下走。

• 什么时候用：任务能清清楚楚拆成固定的小步。
• 本质：拿速度换准确率。每次调用都变简单了，结果自然更稳。
• 例子：先写营销文案 → 再翻译成多语言；先列大纲 → 检查要点有没有漏 → 再展开成文。

模式二：路由（Routing）

先给输入分类，再转给对应的专用处理器，每个处理器有自己调优过的提示词。

• 什么时候用：不同类型的输入需要完全不同的处理方式。
• 例子：客服工单分流，最经典的用法。

模式三：并行化（Parallelisation）

同时开几路 LLM。两种玩法：

• 分块（Sectioning）：任务拆成互不影响的几块，同时跑；
• 投票（Voting）：同一个任务跑好几遍，汇总结果提高置信度。

什么时候用：子任务之间没有依赖（用分块）；或者是关键决策、需要多个判断达成共识（用投票）。

模式四：编排者-工作者（Orchestrator-Workers）

一个 LLM 当编排者，运行时动态拆任务，再分给各个工作者 LLM。跟并行化的区别就在”动态”两个字上：子任务不是提前写死的，是它当场决定的。

• 什么时候用：任务结构提前不知道。跨多文件的代码改动、开放式调研、写报告。

模式五：评估者-优化者（Evaluator-Optimiser）

一个生成，另一个评，评不过就把意见打回去重做，直到达标。

• 什么时候用：有清晰的评判标准，而且反复打磨确实能带来提升。翻译、写代码、写文章都吃这一套。

怎么选，一句话版本：

  graph TD
A[任务能提前拆成固定步骤?] -- 能 --> B[提示词链]
A -- 不能 --> C[输入需要分类分流?]
C -- 是 --> D[路由]
C -- 不是 --> E[子任务互不依赖?]
E -- 是 --> F[并行化]
E -- 不是 --> G[结构运行时才知道?]
G -- 是 --> H[编排者-工作者]
G -- 不是 --> I[有明确评判标准?]
I -- 是 --> J[评估者-优化者]
I -- 不是 --> K[先别急着上 Agent，回去把需求想清楚]
  

03 动手：从”我想要一个 X”到真能跑

到这儿才是大多数人点进教程的真正目的。不绕弯子，最短路径就五步：

1. 把要做的任务写下来；
2. 想清楚需要哪些工具；
3. 明确告诉模型该怎么做事；
4. 拿 5 个真实例子测一遍；
5. 只有测失败了，才加复杂度。

第 5 步是这五步里唯一带纪律性的一条，也是最容易违反的一条。

开工前先答四个问题

• 目标是什么？ 它最后要交出什么东西？
• 它需要哪些信息？ 上网搜、翻文件、查库、看表格、连 CRM，还是用户那句话里就够了？
• 它能做哪些操作？ 只答问题？能搜网？能改文件？能发邮件？能跑代码？
• 它必须守哪些规矩？ 语气、格式、边界、安全红线，拿不准的时候怎么办，以及”什么算好的输出”。

这四个问题答清楚，第一版通常一天之内能出来。答不清楚，你就是在拿模型的自主性替自己想需求，那笔账最后一定会还。

一个够用的设计公式

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

简陋，但它把该写进提示词的东西一个不落地列全了。写不出这五段，说明需求还没想透。

新手选型：先挑一种，别搞集群

• 研究型：收集信息，汇总整理；
• 内容型：写、改、总结、转格式；
• 工作流型：跑那些能重复的业务流程；
• 知识型：基于你自己的文档答问；
• 操作型：在特定环境里执行具体动作。

选型上，两家 SDK 的适用面有明显分工。Anthropic 那套（Claude Code 2025 年 2 月发布，Claude Code SDK 2025 年 9 月改名 Claude Agent SDK）强在读写文件、跑 Shell、搜网、接 MCP 工具，编码和技术类任务、需要一步步操作的场景优先考虑它。OpenAI 的 Agents SDK 2025 年 3 月 11 日发布，同期还有 Responses API 和网络搜索、文件搜索、计算机使用这些内置工具。原文里给了具体版本号，我这儿就不抄了。这类数字过期得比什么都快，用之前自己去仓库看一眼最新的。

让它真按你想的来：一份自查清单

最后一行最重要。真实用户不会用你测试用例里那种规整句式说话，他们会写错别字、会一句话夹三个诉求、会不说清楚前提。你的测试集有多脏，你的 Agent 上线之后就有多稳。

04 工具：少而好，不是多而全

这一步翻车的人最多。常见的错觉是”工具越多，Agent 越聪明”。事实是反过来的：

工具越好，Agent 越聪明；工具越少，Agent 越可靠。

工具的定义可以简单到一句话：AI 靠自己做不到的那些事。算数、搜网、读文件、发邮件、查数据库。

五步走：

1. 先问这事需要工具吗。 答案在提示词里就能推出来的，别给工具。
2. 让 AI 帮你设计工具签名。 这活儿它擅长，你只需要审。
3. 逻辑尽量拆细。 反面教材：manage_files(action, file, destination, overwrite, format, permissions)；正面：read_file(path)、write_file(path, content)、delete_file(path)。一个工具只对应一件具体的事。
4. 把使用场景写进描述里。 「计算器工具」等于没写；「凡涉及数学计算都调此工具，不要自行估算结果」才是描述。
5. 允许它出错，然后针对性修。 报错信息要结构化：模型读得懂的报错，它自己就能纠回来。

这条我想多说一句，因为它是整篇里性价比最高的一段：改工具描述的收益，通常比换个更贵的模型大。参数名起对、描述写清、报错给全，这三件事加起来的提升，比你从中杯换大杯明显得多，而且不花钱。

05 记忆：三档就够，别一上来就 RAG

记忆这块最容易过度设计。抓住核心就两类：

• 短期记忆 = 对话记忆。 整场对话产生的内容。主流 SDK 自带，你只要别手动清就行。
• 长期记忆 = 外部知识库。 它能随时去查的资料：笔记、PDF、文档、数据库。

对应三档配置，按需往上走：

06 打磨：这一步才是分水岭

成品能不能用，基本由这一步决定。市面上体验差的 Agent，问题几乎都出在这三处：提示词写得糙、测试没做全、预期设得不现实。

1. 用 AI 批量造测试用例。 手写十条要半天，让它生成二十条只要一分钟，你负责挑和改。
2. 按真实用户的说法去测。 「账单分类」是你的说法；「为什么我账户老是被扣钱」才是用户的说法。
3. 一次只修一处。 出问题了逐项排查：提示词有歧义？输出格式没约束？缺工具？规则不全？一次改一个变量，不然你根本不知道是哪一下起了作用。
4. 让 AI 帮你查它自己的故障。 把失败的那轮完整对话喂回去，让它分析哪一步偏了。
5. 克制。 别急着叠功能。现有的还没稳，加进来的每个新功能都只是多一个坏点。

原文说准备二十组测试用例能挖出大量手测发现不了的问题，这个数量级我认。二十条脏数据的信息量，远大于两百条干净数据。

07 多 Agent：绝大多数时候，你还不需要

这块的错觉是”Agent 越多越强”。不是。多 Agent 会把 Token 成本、延迟、调试难度一起乘上去，而收益只在特定条件下才出现。

先把单 Agent 版本做扎实。要升级到多 Agent，得同时满足三条：任务能清晰拆分、单个 Agent 确实完不成、各角色职能差别明显。

真正值得上多 Agent 的场景，我只见过三类：

• 技能不同：调研的和写文案的，需要的提示词和工具根本不是一套；
• 固定流水线：输入 → 分析 → 撰写 → 输出，环节稳定且各环节评判标准不同；
• 权限分级：一部分只读，一部分能写能执行。这条其实是安全设计，不是性能设计。

架构上最稳的是分层：用户只对主 Agent 说话，主 Agent 按需调辅助 Agent，产出回到主 Agent 手上审过才算数。子 Agent 是帮手，不是决策人。

08 收束

把上面这些压成几句：

• Agent 的底层逻辑不复杂，核心循环五十行 Python 能写完；难的全在细节里。
• 决定体验上限的是：工具设计、异常处理、评估体系、选型判断。四样里没有一样叫”用了哪个框架”。
• 很多场景下，提示词链、路由这种简单模式比自主 Agent 更合适：更快、更便宜、更好排查。

三条可以今天就动手的建议

一、先手搓一个，别从框架开始。
把那个循环自己写一遍，你就看穿了所有框架在干什么，之后排查问题会快很多，选工具时也不容易被话术带走。

二、用最简的方案解决问题。
多步骤的活，提示词链基本够；要先分类再动手的，路由能完美适配。只有当”下一步该干什么”必须由模型自己判断时，才升级成自主 Agent。

三、把预算花在工具设计和测试上。
工具名起准、描述写清、报错结构化，这三件事的收益比换模型、换框架都实在。再准备二十组够脏的测试用例，你会挖出一堆手测根本碰不到的问题。

这套东西的好处是它不太挑技术代际。模型换、SDK 改名、框架起落，循环还是那个循环，工具设计还是那件难事。把这层吃透，后面无论怎么迭代，你都接得上。

原文：智泊AI，《AI Agent 保姆级教程 | 从 0~1 构建一个属于你的 AI Agent》。文中五种工作流模式源自 Anthropic 的 Building effective agents。本文为提炼重写，结构与观点取舍已按我自己的理解调整，出入之处以原文为准。