AI Agent开发实战，最近在我身边被讨论的频率高得吓人。但讨论归讨论，真到动手环节，我见过太多人挂在同一个地方：收藏夹里躺着几十篇教程，模型调用的demo也跑通了好几个，结果一到要做“会自己规划、会自己调用工具的Agent”，就不知道该往哪走了。原因不复杂——Agent开发本质上是一门编排艺术，知识点是环环相扣的：先懂模型怎么输出，再懂工具怎么接进来，然后才谈得上规划、记忆和多角色协作。这些东西一口气吃不成，需要一份足够宽、又有明确产出的时间节奏，把每个环节都变成能运行的东西。
这篇文章就是我给自己和身边朋友反复迭代出来的14周进阶学习计划，从理论到落地，每一周做什么、做到什么程度、容易在哪里卡住，都会写清楚。它适合已经有Python基础、想系统进入Agent开发方向的开发者，也适合那些已经在做Chatbot或RAG应用、想把系统做得更“自主”的人。先说明，这不是一个零基础编程课，如果你连函数、JSON、HTTP请求都还没写过，建议先补两周基础再来。下面进入正题。
1. 先想明白：Agent开发到底在学什么
1.1 Agent不是一个“模型”，而是一套系统
我刚接触Agent开发时犯过一个认知错误：以为换一个更强的模型，应用就能自动变得“智能”。后来发现完全不是这么回事。普通大模型应用是一锤子买卖：用户提问，模型回答，流程结束。Agent应用则是目标驱动的循环：用户给一个目标，系统自己判断需要调用哪个工具、读取什么数据、如何调整下一步动作，然后反复执行，直到得出结果。
用生活里的例子类比：普通聊天机器人像前台接线员，你问什么它答什么，答不上来就结束；Agent更像一个贴身助理，你告诉它“帮我安排周五去某城市的出差”，它会自己查航班、看会议时间、预定酒店、把最终行程单发给你，甚至中途发现某个航班取消还会主动换方案。这个“感知、决策、行动、反馈”的闭环，才是Agent开发的核心。
所以学习Agent开发，学的不是某个模型API的新玩法，而是怎么把模型、工具、数据、流程粘合成一个可靠系统。这也是为什么14周计划里，前几周一直在打基础，因为很多人在“工具调用”还没理解透的时候就去折腾多Agent协作，等于没学会走就想跑跨栏。
1.2 14周为什么拆成四个阶段
这份计划的时间分配不是拍脑袋定的，而是按学习曲线设计的。Agent开发有很强的“前置依赖”：你不知道模型怎么输出结构化内容，就没法定义工具协议；没见过工具循环，就理解不了记忆管理为什么重要；没做过单Agent项目，就没资格谈多Agent协作。所以我把14周切成了四个阶段。
| 阶段 | 周次 | 核心命题 | 阶段结束时的可见产出 |
|---|---|---|---|
| 基础打底 | 1-4 | 模型怎么输出，工具怎么接入 | 一个徒手写的“工具调用”迷你循环 |
| 核心机制 | 5-8 | 规划、记忆、工具的闭环 | 一个可对话、可调多工具的Agent项目 |
| 复杂协作 | 9-10 | 多Agent角色拆分与通信 | 一个含多角色任务协作的Demo |
| 工程化落地 | 11-14 | 可观测、可评估、可部署 | 一个能演示、有测试、有说明的作品 |
每个阶段结束，都必须有“能跑起来给别人看”的东西。在我看来，这是整个计划最重要的设计原则：知识可以忘，但亲手跑通的系统不会忘。很多人学Agent失败，不是因为笨，而是因为连续几周只有输入没有输出，动力很快就没了。阶段产出就是用来对抗这种“学习疲劳”的。
1.3 这个计划适合谁，又会筛掉谁
如果你的背景是后端开发、Python脚本熟练、平时会处理JSON接口，那这个计划几乎是为你定制的。你缺的不是编程能力，而是Agent特有的编排思维。如果你是大模型应用的产品经理或测试开发，也可以跟着做，只是代码部分需要多找人请教。
反过来，如果你连虚拟环境都还没配过，或者只是对Agent好奇、暂时没有明确应用场景，我建议先不要启动这个计划。Agent开发有个特点：没有具体问题牵引，很容易变成“为了用框架而用框架”。你必须手里握着一个真实到让你头疼的任务，才能熬过中间那些排错的夜晚。这也是我认为14周计划最该有的心态——它是给“要解决问题的人”用的路线图，不是给“收藏党”的收藏夹。
2. 前四周：先把地基打结实
2.1 第一周：掌握“和模型对话”的底层规则
第一周的目标只有一个：把模型当成一个“概率性文本生成器”来理解，而不是当成数据库。很多人以为模型内部存了知识，所以反复追问它“你记得我之前说过什么吗”，然后发现上下文一长就忘。真相是，模型每次回答都只基于你塞给它的那一段上下文重新推断，它没有“记忆”，只有“窗口”。
所以第一周建议做三件事。第一，理解token和上下文窗口：一个汉字可能对应一到多个token，窗口满了就要裁掉旧消息，这不是bug而是机制。第二，理解system、user、assistant三种角色的分工：system是长期指令、user是当次请求、assistant是模型历史回复，三者不能混。第三，理解temperature这类参数：做Agent任务时我习惯把temperature设在0到0.3之间，降低随机性，让工具选择更稳定。
调用模型的代码长什么样？各家API细节不同，但核心形态是稳定的。类似这样：
response = model_api.chat( messages=[ {"role": "system", "content": "你是一个任务规划助手，只能使用可用工具完成任务。"}, {"role": "user", "content": "帮我查一下某产品库存，并预约一个演示。"}, ], temperature=0.2, )第一周的练习不用复杂，每天做一个角色扮演型小应用，比如“会追问需求的简历顾问”“只会用反问句的健身教练”。重点不是功能，而是让你形成一种感觉：模型给出的内容取决于你如何设计指令和约束。
2.2 第二周：提示工程，重点放在“结构化输出”
第二周开始，我们要从聊天场景切到Agent场景。Agent最大的不同在于：模型的输出不能只是“说得好听”，必须能被程序稳定解析。普通聊天里模型说“好的，我会帮你查一下”没问题，但Agent系统需要的是模型直接给出“我要调用query_inventory函数，参数sku是A100”这类结构化意图。
结构化输出的标准做法是让模型返回JSON，并在system指令里写清楚格式。一个我会反复用的例子：
{ "intent": "query_inventory", "arguments": { "sku": "A100", "warehouse": "east" } }你需要同时提供schema和少量示例，两者缺一不可。只写“请返回JSON”是不够的，模型会在字段命名上自由发挥，导致你写解析代码时痛不欲生。我见过有人用正则硬解析模型输出，那是在给自己挖坑；正确的做法是从源头用schema和示例约束。
这周可以做一个发票信息提取Demo：输入一段发票照片的文字描述，让模型输出金额、发票号、开票日期三个字段。看似简单，但如果你第一次做就会发现，模型会经常把字段名写成大写开头或中文，你要不断调整提示词。这个“调模型”的过程，就是Agent开发真正需要的基本功。
2.3 第三周：理解函数调用，这是Agent的分水岭
第三周是整个计划的第一个分水岭。函数调用（Function Calling）解决的事情是：模型本身不擅长算数、查库、发请求，但它擅长“决定该做什么”。你可以给模型一份工具清单，每个工具都有一段描述和参数定义，然后让模型在回答用户前，先输出“我想调用哪个工具”的意图。
工具定义本质上是一份给模型看的接口文档。比如：
{ "name": "query_inventory", "description": "查询指定商品的实时库存，只接受SKU编号参数", "parameters": { "type": "object", "properties": { "sku": { "type": "string", "description": "商品SKU编号，例如A100" } }, "required": ["sku"] } }这段定义里有三个细节容易被忽略：name要稳定，不能频繁改名；description要写清楚“什么时候用、参数是什么格式”，不然模型会乱选工具；required字段要明确，否则模型可能省略关键参数。你定义的工具集合就是Agent的能力边界——模型永远无法主动使用你没定义过的东西。
第三周的练习是定义5个工具，比如查询天气、读取日历、创建待办、发送邮件、计算运费，然后给模型各种用户请求，看它能不能选中正确的工具、填出正确的参数。这一步能让大多数人第一次直观感受到Agent的“决策感”，也是后面所有内容的基础。
2.4 第四周：徒手写一个迷你Agent循环
第四周把前三周学到的东西串起来，写一个真正的最小Agent循环。我强烈建议不要在第一周就引入框架，因为框架会把你和底层机制隔开。你至少要亲手写过一遍循环，才知道报错时该查哪里。
核心逻辑是：把消息发给模型，带上工具列表；如果模型返回的是“工具调用意图”，就执行对应工具，把结果以tool消息回填给模型，继续下一轮；直到模型返回普通文本，才把答案交给用户。
messages = [ {"role": "system", "content": "你是库存查询助手，只能使用提供的工具。"} ] max_steps = 5 step = 0 while step < max_steps: response = model_api.chat(messages=messages, tools=tool_definitions) if response.finish_reason == "tool": messages.append(response.message) tool_result = run_tool(response.tool_call) messages.append({"role": "tool", "content": tool_result}) step += 1 continue answer = response.content print(answer) break代码里的max_steps是很多人会忽略的保命符。如果没有最大轮数限制，模型可能因为工具返回的数据不合预期而无限循环，你的账号会被token费用轰炸。第四周结束时，你应该有一个能查库存、能查天气、能处理简单对话的迷你程序。不要急着加花活，先把这个循环跑稳。
3. 第五周到第十周：把“推理循环”真正建起来
3.1 第5-6周：规划、记忆、工具，Agent三大件的正确理解
到了第五周，你已经有一个最简循环了。这时候需要把视野拉高，理解Agent系统的三大件：规划、记忆、工具。很多人一听到“规划”就想到让模型自己天马行空地拆解任务，其实工程上最稳妥的做法是先“显式规划”，再慢慢过渡到“隐式规划”。
显式规划就是你在代码里写死步骤：第一步查库存，第二步算运费，第三步生成订单。这听起来不“智能”，但它可靠、可控、容易调试。隐式规划则是把目标直接丢给模型，让它自己决定调用顺序。新手最大的误区是一上来就追求隐式规划，结果模型在复杂任务中反复横跳，系统完全不可预测。我建议至少在上面练习一周显式工作流，再尝试让模型自由发挥。
这周还要理解ReAct这种思考循环套路。简单说，就是让模型交替输出思考（Thought）、动作（Action）和观察（Observation），就像解题时先把思路说出来，再动手，再根据结果调整。很多框架默认就是这种模式。你不需要背定义，但要能在自己的日志里认出这种三段结构。
关于记忆，先用一个简单结论拖着：短期记忆就是会话窗口，长期记忆后面第九周专门说。第六周不需要做太复杂的事，把第四周的迷你循环扩展成三个工具的完整工作流，比如“查库存+算运费+生成报价单”，就已经很扎实了。
3.2 第7周：选择编排框架，但不要被框架绑架
第七周可以开始用框架了。框架解决的核心问题，是把你自己写的循环、工具注册、记忆管理这些重复劳动封装成通用组件。你不需要再自己处理消息回填的细节，也不必每次新建项目都重写一遍工具解析逻辑。
选择框架时别陷入“全都要对比一遍”的泥潭。我的建议很简单：选一个社区活跃、文档完整、能快速跑通官方示例的，用起来就行。要知道，几乎所有成熟框架都逃不过几个核心抽象：模型封装、工具注册、记忆接口、循环执行器。你只要理解了自己第四周写的那个循环，看任何框架的文档都会很顺，因为它们万变不离其宗。
用框架练手时，我特别建议做一件事：花一个晚上读框架关于“工具调用”部分的源码。不用全看懂，只看一个函数就行——看看框架是怎么解析模型返回的tool_call、又是怎么把工具结果放回上下文的。读完你会恍然大悟：这不就是我第四周写的那个while循环吗。框架没有魔法，只有工程封装。
3.3 第8周：做一个“工具齐全”的单Agent项目
第八周是核心机制的收官周。你要做一个真正有实用价值的单Agent项目。我比较推荐“企业内部信息查询助手”这个类型，因为它的工具边界清晰，又足够接近真实需求。工具集至少包含：用户信息查询、订单查询、文档检索、审批状态查询。四个工具能覆盖大部分常见问题，又不会让交互流程失控。
这周的重点不是写更多工具，而是解决“任务路由”和“参数注入”两个问题。任务路由指模型能从用户一句话里判断该走哪个工具，比如“张总上周的报销批了没”应该走审批查询而不是订单查询。参数注入指模型要从自然语言里提取出关键参数，比如把“张总”映射成员工编号。没有干净的参数注入，后面一切自动化都是空中楼阁。
调试时我建议大家养成一个习惯：把每一轮模型返回的tool_call和参数都打印出来。不要只看最终答案，因为很多错误发生在中间某个参数的小偏差上，比如sku里多了一个空格。我见过有人花了整整两天找Bug，结果只是模型把“A100”输出成了“A 100”。先看轨迹，再找问题，这是Agent开发调试的铁律。
3.4 第9周：记忆管理的取舍
第九周处理Agent开发里最容易被误解的话题：记忆。很多人一开始会把所有对话历史都塞给模型，认为信息越多越准。实际上，上下文一长，token费用上涨、响应变慢，而且模型注意力会被无关内容稀释，效果反而变差。
记忆管理的本质是取舍。我按实现成本由低到高列出三种常见策略：
| 策略 | 做法 | 适用场景 | 成本 |
|---|---|---|---|
| 滑动窗口 | 只保留最近N轮消息 | 短任务、工具调用密集场景 | 低 |
| 摘要记忆 | 每次对话结束后用模型生成摘要，下次只带摘要 | 跨会话、长期任务 | 中 |
| 向量检索记忆 | 把历史对话或文档做向量化，按相似度召回相关片段 | 知识库问答、个性化偏好 | 高 |
对多数单Agent项目，滑动窗口加摘要记忆就够用了。向量检索适合做RAG式记忆，但前提是你有足够多需要检索的历史内容。这周练习可以是给Agent添加“用户偏好”记忆：比如用户说过自己偏好靠窗座位，以后推荐时就带上这个信息。实现方式不复杂，但能让你感受到记忆设计对体验的提升有多大。
3.5 第10周：多Agent协作的轻量入门
多Agent协作是看起来最炫、实际最容易翻车的话题。第十周只做轻量入门，目的是让你理解模式，不是让你把所有系统都改成多Agent。多Agent真正解决的问题是角色隔离和复杂度隔离：一个负责理解需求、一个负责查数据、一个负责生成报告，各司其职，互不干扰。如果任务简单到单Agent和几个工具就能搞定，完全没必要拆。
常见的协作模式有三种。主从模式：一个主Agent负责统筹，其余按指令行动，适合任务路径明确。流水线模式：前一个Agent的输出是后一个Agent的输入，适合有明确先后顺序的处理。协商模式：多个Agent对同一目标投票或讨论，适合需要多角度判断的场景。工程上主从和流水线足够覆盖绝大多数需求，协商模式尽量少用，因为它不可控、消耗大。
多Agent之间的通信协议需要提前设计好。我吃过亏的地方是没有约定消息格式，结果一个Agent输出的Markdown表格被另一个Agent当成JSON解析，直接报错。你需要定义类似“任务ID、发送者、接收者、内容类型、载荷”这样的固定结构，这比多Agent算法本身更重要。第九周结束时，做一个“需求拆解+查询+汇总”的三人小组Demo就好，别贪多。
4. 最后四周：从“能跑”到“扛得住”
4.1 第11周：给Agent装上仪表盘
进入第11周，视角要从“功能开发”切换到“工程化”。Agent系统最大的特点是不可控性强，同样的输入可能今天成功明天失败，中间多了一轮少了一轮都难查。所以第一件事是建立可观测性，不看到中间轨迹就等于盲调。
我习惯把每次Agent运行都记录成JSON Lines格式，一行一个事件。每条事件至少包含：事件类型（是哪一步）、序号、触发的Agent、调用的工具、传入参数、返回结果、耗时和token数。比如：
{"event": "tool_call", "seq": 3, "agent": "assistant", "tool": "query_inventory", "arguments": {"sku": "A100"}, "latency_ms": 120, "tokens": 42}有了这份日志，你就可以回放一次Agent行为，看到它第几步选错了工具、第几步参数抽错了，也能统计平均耗了多少轮。很多框架自带trace功能，就算不用框架，也一定要自己打日志。可观测性还包含成本追踪：每次运行花了多少token，在哪个工具上花了最多，这些数据直接决定后面做优化时往哪里使劲。
4.2 第12周：评估Agent，才能放心迭代
没有评估就没有迭代，这句话在Agent开发里尤其成立。普通功能你测试几遍就放心了，Agent应用会因为模型版本、提示词微调、工具返回变化产生各种漂移。你需要建立一个回归测试集，把典型用户问题和期望行为固化下来。
评估不是只看最终答案对不对，至少要看三件事：最终答案是否正确或可用、工具调用序列是否合规、有没有冗余循环或危险操作。比如一个查询库存的任务，正确答案可能没错，但Agent偷偷多调用了一次无关工具，这种也要算失败。
自动化评估有两种常用手段。一是规则检查，比较期望工具序列和实际工具序列是否一致，这个精确但不灵活。二是模型打分，让另一个模型作为裁判，按“相关性、完整性、安全性”打分，这个灵活但需要设计打分标准。两类结合比较稳。我建议第12周给项目准备20到30个测试用例，定一个“关键场景必须全部通过、边界场景允许部分失败但不致命”的验收线。
4.3 第13周：部署、并发和成本控制
部署Agent和部署普通Web服务有很多相似点，但有一个关键差异：Agent单次运行可能持续几十秒，涉及多次模型调用和外部请求，不能像普通接口那样直接同步等待。你需要引入异步任务队列，用户提交任务后拿到一个状态接口，Agent在后台跑完后通知结果。这也是为什么很多人把Agent包装成“任务系统”而不是“请求响应系统”。
并发控制同样要提前设计。多个用户同时使用Agent时，需要限制对模型API的并发请求数，做简单的漏桶或信号量限流。流式输出能显著改善体验，让用户看到Agent“正在思考”的过程，而不是干等。成本控制层面，最有效的三板斧是：缓存高频工具结果、优先使用便宜模型处理简单意图、给所有循环加最大步数。比如“查询公司班车时刻”这种固定信息，完全可以直接缓存，不用每次都触发一次完整Agent。
部署架构不一定要上很重的微服务。单进程加任务队列加一份日志存储，就能覆盖很多场景。重点是你要把Agent当“有外部依赖的长任务”来设计，而不是当成普通函数来部署。
4.4 第14周：把项目打磨成作品
第14周不写新功能，只做打磨。我强烈建议你完成一个“作品级”的交付，而不是让项目停留在“我自己知道怎么跑”的状态。原因很简单：作品是你对14周学习的沉淀，也是你以后给任何合作方展示时最有力的证明。
作品清单至少包括四样东西。一份清晰的README，写清楚项目定位、架构图、工具列表、环境变量、已知边界，让人十分钟就能看懂项目；一个一键启动的演示脚本，保证任何机器上跑起来都能复现核心流程；一份评估报告，把你第12周建的测试集和结果放进去，证明这个系统不是碰巧能跑；再加一个失败案例集，主动记录几次典型的错误轨迹和修复方式，这比成功率更显专业。
最后找两三个朋友当“小白用户”来测试，观察他们在没有你指挥时会不会用、哪里用崩。这一轮暴露出的小问题，通常就是作品最后需要修的那些毛刺。第14周结束，你手上不再是一个Demo，而是一个可以长期维护和对外展示的作品。
5. 走过几轮计划之后，我最想替你避开的几个坑
5.1 别从“万能助手”开始，从一个窄问题开始
我见过太多人启动项目时野心很大：要做一个能管日程、写周报、订外卖、回答公司制度查询的超级助手。这种系统在两周内必然失控，因为工具越多，模型选择的复杂度成倍上升，一个工具定义写得含糊，整个链路都会乱掉。正确的做法是像剥洋葱一样，先选定一个窄而具体的问题。比如“只做公司制度问答+请假审批查询”，把这两个工具做到极致的稳定，再考虑下一个月扩展。窄问题里做出的质量，远比宽问题里的半成品有价值。
5.2 多Agent不是万金油，别为了架构好看而拆角色
第十周做完多Agent之后会有一种冲动：什么项目都想上多Agent。我劝你忍住。多Agent意味着更高的token成本、更长的响应时间、更多的通信失败点。很多“多Agent”真正需要的其实只是把流程写清楚，用一个主循环加几个函数调用就完成了。我自己用过一个判断标准：如果两个角色的思维逻辑完全一样，只是为了概念上好看，就不要拆。什么时候该拆？一个要读文件做总结，一个要调API做查询，工具域完全不重叠，这才有拆的必要。
5.3 调试不留痕，等于盲人摸象
从第八周开始，我给自己的项目强制加了一个“复盘模式”：允许用户或开发者回看某次完整轨迹，包括每一轮思考、工具调用、参数和耗时。就是这个习惯，至少帮我排查了三十多个原本会让人抓狂的问题。没有轨迹，你可能还在猜是不是模型不够聪明，有了轨迹，你就会发现只是某个工具的参数文档里少写了一句描述。建议你把日志当作Agent项目的原生组成部分，而不是事后补丁。
5.4 计划是活的，允许自己卡一周
最后说点心态层面的经验。14周只是一个参考节奏，不是军令状。真实的Agent开发会遇到各种意外：平台接口升级、框架版本不兼容、工具返回的数据格式和预期不一致，这些都可能让你的进度停滞。我见过有人因为第三周的工具定义一直不收敛，果断把那周拉长到两周，后面反而追了回来；也有人死赶进度，结果核心机制没吃透，后面越学越虚。判断计划要不要调整，唯一的标准就是看“阶段产出是否真的达标”，而不是看日历。
走到这里，我想把最后一点体会留给你：Agent开发真正迷人的地方，不在于模型本身变聪明了，而在于你亲手把模型、工具和数据编排成了一个能自主决策的系统。这份14周计划教不了你所有细节，但它能保证你在结束时有作品、有手感、有一套属于自己的排错方法。只要你在某个周末让那个最早的迷你循环跑起来，后面的一切都会顺很多。祝你每一周都有看得见的进展。
