1. 为什么AI突然长出了"手脚"：从聊天框到Agent的进化逻辑
过去两年我一直在折腾大模型应用，踩过最大的坑就是——把ChatGPT当搜索引擎用，把"能聊天"当成"能干活"。很多项目Demo做得花里胡哨，一问"能落地吗"，卡死在最基础的一环：模型只会说，不会做。
直到我开始系统性地接触AI Agent这个概念，才意识到自己之前对"AI能做什么"的认知，至少落后了一年。
先说一个反直觉的事实：单纯调用GPT-4、Claude这样的模型接口，你得到的只是一个"超级大脑"，而不是一个"能干活的员工"。大脑再聪明，没有手、没有脚、没有任务拆解能力，它也只能坐在那里回答你抛过来的问题。你问它"帮我查一下这个月的销售数据并生成报表"，它要么给你一段实现思路，要么编造一份数据，总之无法真正完成闭环。
AI Agent解决的就是这个问题。
它本质上是给大模型装上了一套完整的"行动系统"。如果把大模型比作一个刚刚入职的高智商新人，那Agent就是那个教会他怎么用公司系统、怎么查资料、怎么调用工具、怎么分步骤完成任务的老员工。这个新人体力好、脑子快，但只有有了Agent这层封装，他才知道遇到问题该先干什么、后干什么、什么时候该停下来确认。
那Agent到底是什么？引用行业内比较被认可的定义：Agent是一个由大模型驱动的、能感知环境、做出决策、执行动作并观察结果的智能体系统。拆开讲，它至少要具备四个核心能力：
- 规划（Planning）：把一个大目标拆解成若干可执行的子任务，并能根据中间结果动态调整计划。
- 记忆（Memory）：短期记忆负责当前任务的上下文，长期记忆负责跨对话、跨会话的知识沉淀。
- 工具调用（Tool Use）：能主动调用外部API、数据库、代码解释器、浏览器等，真正对现实世界产生影响。
- 反思与迭代（Reflection）：执行完每一步之后，能观察结果、判断是否正确、必要时自我纠错重试。
这四个能力，才是Agent和"套了Prompt的聊天机器人"之间最本质的分水岭。
这篇文章是这个AI Agent系列教程的起点。我接下来要做的，是把"认识Agent"这件事拆成几个看得见摸得着的维度，包括它的原理拆解、主流技术框架、能落地的应用场景和边界、以及一个最简单但完整可跑的入门Demo，带你从0到1建立起对Agent的判断力。不管你是刚入门的开发者、做技术选型的产品经理，还是想用Agent提效的运营同学，这个系列都按"能直接用"的标准来写，不讲玄学，只讲实操。
2. 一句话讲透Agent的底层逻辑：大模型当"脑子"，其它都是"手脚"
2.1 三个关键组件的关系
很多人一开始接触Agent时会觉得概念很虚，总是说"Agent就是一个AI助手啊"。但你真的去拆解一个成熟的Agent系统，会发现它的骨架其实是清晰的三角关系：模型（Model）、工具（Tools）、编排层（Orchestration），外加一个贯穿始终的上下文（Context）。
可以用开餐厅来类比。
- 模型是主厨：他负责判断"这道菜应该怎么做"，根据菜单（用户指令）决定烹饪步骤。天赋决定了菜的上限。
- 工具是厨房设备：烤箱、蒸锅、料理机。主厨再厉害，没有烤箱也做不出烤鸭，只能给你描述烤鸭该怎么做。对Agent来说，这些工具就是搜索引擎API、代码执行器、数据库查询接口、业务系统接口。
- 编排层是厨房的动线设计：决定什么菜先备料、什么菜先下锅、出锅之后传给谁。编排层管理的是整个任务的流程状态，保证每一步的输入输出能正确衔接，不会把给A桌的菜端给B桌。
当用户说"帮我研究一下竞品最近的动态，并输出一份简报"，在主厨视角下，这可能被拆解成：搜索竞品新闻 -> 阅读核心文章 -> 提炼要点 -> 对比我方产品 -> 整理成简报。每一步都在调用不同的工具，每一步的结果都会被重新喂回模型作为下一步判断的依据。这个"拆解-执行-反馈-再执行"的循环，就是Agent比传统聊天机器人强大的根本原因。
2.2 不要把Agent和"Prompt工程"混为一谈
我在网上看到大量文章把两者混为一谈，这里必须掰扯清楚。
Prompt工程的核心是：优化输入给模型的指令，让模型输出更符合预期。它是一个"单轮优化"问题，本质还是模型自己完成整套推理，只是在输入端做文章。比如你用一段精心编排的prompt让GPT直接输出一份周报，这仍然是一次性推理，模型并没有"去查数据->验证->修改"的过程。
Agent的核心则是"多轮任务编排"问题。它的关注点从"怎么让模型答得好"转移到了"怎么让模型在真实环境中把事办成"。这个转移带来的差异非常明显：
| 对比维度 | 传统Prompt应用 | AI Agent |
|---|---|---|
| 核心问题 | 如何优化输入，获得更好的输出 | 如何拆分任务，联动工具，达成目标 |
| 信息的流动 | 用户 -> 模型 -> 用户 | 用户 -> Agent -> 工具 -> 模型 -> 工具 -> 用户 |
| 是否自主决策 | 否，一次生成定稿 | 是，根据中间结果动态决策下一步 |
| 是否能操作外物 | 通常不能 | 能（查库、调用API、写文件、发请求） |
| 失败后的处理 | 用户自己改prompt重试 | Agent自我检查、重试、调整策略 |
用大白话说：Prompt工程是在改造"一个人"的脑子，让他更会回答问题；Agent是在组建"一个团队"，里面有分工、有工具、有流程。大模型只是这个团队里的核心成员之一，而不是全部。
2.3 循环闭环：Agent循环（Agent Loop）
真实运行中的Agent，是一个闭环系统，业界通常称为Agent Loop。拆开看，每一步是这样的：
- 接收任务目标。
- 大模型分析当前状态，制定或调整下一步行动（可能是调用某个工具，也可能是直接给出答案）。
- 执行行动（如调用搜索API），获得结果。
- 把新的结果放回上下文，供模型判断："这个结果够了吗？需要修正吗？下一步该做什么？"
- 重复2-4，直到任务完成或达到停止条件。
你可能会问：这不就是普通的循环吗？有什么稀罕的？
关键在于第4步里"把结果放回上下文"这个动作。大模型本身没有记忆持久化，如果每次执行完工具调用后不把结果写回上下文，模型就会"失忆"，不知道刚才发生了什么。所以Agent框架的核心工作之一，就是管理好这个上下文回路：既不让模型遗忘关键信息，又不能让上下文无限堆叠导致超长、混乱、成本爆炸。这个我会在后面编排层的章节里详细展开。
3. 主流Agent技术架构盘点：从AutoGPT到LangChain再到现在的"有状态"范式
3.1 第一阶段：单线程自动循环（AutoGPT模式）
2023年AutoGPT横空出世时，大家是真的兴奋，因为它是第一个让很多人直观感受到"AI能自主完成任务"的项目。用户给出一个目标，AutoGPT会自己拆解目标、生成步骤、调用工具、执行操作、检查结果，然后继续下一步。
但它的问题也很明显，拆解出来的步骤经常是错的，而且没有兜底校验机制。我在实际跑的时候观察过它的日志，它会一本正经地"觉得"自己该去查某个网站，结果URL是编的，然后失败，再编一个新的，再失败。看起来特别努力，实际上在空转。你问它"到底完成没有"，它会告诉你"完成了"，实际上产出根本没法用。
AutoGPT暴露的核心问题，也是第一代Agent的共同天花板：没有可靠的工具调用机制，模型"幻觉"出来的行动会被当成真实行动执行。
3.2 第二阶段：简化+收敛（LangChain / LlamaIndex工具调用范式）
在AutoGPT带来的混乱之后，LangChain这一类的框架出来做了一件事：把"让模型自由发挥"收敛为"让模型从已有工具列表里选一个"。这就是现在大家熟知的Function Calling机制。
运行逻辑从"模型自己创造行动"升级成了"模型在预设工具集里做选择"。框架预先定义好一批工具（搜索、计算器、代码解释器），模型根据当前任务判断"现在应该调用哪一个"，然后填充参数执行。参数有明确schema，执行完有明确返回值，返回值会回到上下文里。
这套模式带来的直接好处是可靠性大幅提升：模型不再自由发明工具，它只能在我们允许的范围内行动。坏处是系统开始变复杂。你用LangChain搭一个稍复杂的Agent应用时，会出现很多工程层面的烦恼：上下文管理、循环终止条件、工具报错后的递归重试逻辑、成本控制。很多人项目跑得通Demo，但是一上生产就发现各种边界问题多得要命。
3.3 第三阶段：有状态、多智能体、面向生产（Claude Agent SDK / OpenAI Assistants / 通用编排框架）
我观察到一个很明显的趋势：Agent的技术架构正在从"玩具级Demo"走向"生产级稳定性"，行业的重心也逐渐转移到了三个方向：
方向一：有状态会话与存储。不再把上下文稀里糊涂地每次全塞进模型，而是引入会话ID、快照恢复、记忆持久化机制。用户离开一段对话再回来，Agent能记住之前的中间状态。这在To B业务里极其重要——客服、销售、运营场景里，用户不会一次给全信息，必须跨轮次积累。
方向二：多智能体协作模式。不再是一个Agent包揽所有事，而是让多个Agent分工，各管一个环节，有Manager Agent负责分配和汇总。比如写一篇行业研究报告，可以并行开三个子Agent分别做"数据采集"、"案例分析"、"观点提炼"，主Agent最后合并。这种方式在长链条任务里效果非常显著，但对任务拆解策略和上下文共享机制的要求也更高。
方向三：SDK化的Agent工具链。以业界最新的Agent SDK为代表的一批工具，正在把"工具注册、会话管理、Agent间协作、可观测性"做成开箱即用的基础设施。
这个过程里还有个不可忽视的底层推动力：模型本身的能力在升级。以前模型的工具选择判断经常出错，而现在的新模型在Function Calling上的准确率已经高了很多，这让Agent架构里的"模型选工具"变得更加可信，也让Agent从"炫技"逐步迈入"实用"。
3.4 给新人的技术选型建议
在做技术选型时，我见过太多人一上来就研究最新框架，结果被坑得晕头转向。我的建议分三种情况：
- 学习理解Agent原理：先自己手写一个最简单的ReAct循环（Reason + Act），不要上任何框架。用几十行代码实现"模型选工具->执行->回填"这个循环，你会对一切框架豁然开朗。
- 做To B业务系统：优先考虑有状态、带完整工具生态的官方SDK或企业级框架，稳定性和可观测性比花哨的功能更重要。
- 做探索性研究或快速原型：可以先直接构建在模型能力之上，配合灵活的社区框架，但要预留足够的容错和人工审查环节。
4. 一个跑通即懂的极简Agent：手写50行代码感受Agent Loop
光讲理论不过瘾，我带大家手写一个最简Agent。用Python + OpenAI兼容接口就可以跑通，不需要任何Agent框架，但你会真正理解Agent内部在发生什么。
4.1 准备工作
- Python 3.10+
- 一个支持Function Calling的LLM接口（国外的OpenAI、Claude，或国内的大模型服务都行，只要兼容OpenAI的chat/completions格式即可）
- 安装OpenAI Python库：
pip install openai
4.2 完整代码
import json from openai import OpenAI client = OpenAI( api_key="YOUR_API_KEY", base_url="YOUR_API_BASE_URL" # 默认 https://api.openai.com/v1 ) # ---------- 1. 定义可用工具 ---------- def get_weather(city: str) -> str: """查询城市天气的模拟函数。生产环境替换为真实API。""" data = { "北京": "晴，21°C，微风", "上海": "小雨，24°C，东南风2级", "深圳": "多云，28°C，湿度较大", } return data.get(city, f"暂时没有{city}的天气数据") def calculator(expression: str) -> str: """执行数学表达式计算，注意不能执行任意代码。""" allowed = set("0123456789+-*/.() ") if not set(expression).issubset(allowed): return "表达式包含非法字符" try: return str(eval(expression, {"__builtins__": {}}, {})) except Exception as e: return f"计算错误: {e}" TOOLS = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的当前天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"} }, "required": ["city"] } } }, { "type": "function", "function": { "name": "calculator", "description": "执行四则运算表达式", "parameters": { "type": "object", "properties": { "expression": {"type": "string", "description": "数学表达式，如(3+5)*2"} }, "required": ["expression"] } } } ] FUNCTIONS_MAP = { "get_weather": get_weather, "calculator": calculator, } # ---------- 2. Agent循环 ---------- def run_agent(user_query: str, max_steps: int = 5): messages = [{"role": "user", "content": user_query}] print(f"用户输入: {user_query}\n") for step in range(max_steps): # 模型决策：直接回答 or 调用工具 response = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=TOOLS, tool_choice="auto", ) msg = response.choices[0].message # 如果没有工具调用，说明模型认为可以直接给答案了 if not msg.tool_calls: print(f"第{step+1}步：模型直接回答") print(f"最终答案: {msg.content}") break # 有工具调用：解析并执行 print(f"第{step+1}步：模型请求调用工具") messages.append(msg) # 先把模型的工具调用请求加入对话 for tool_call in msg.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) fn = FUNCTIONS_MAP[fn_name] result = fn(**fn_args) print(f" -> 工具 {fn_name}({fn_args}) = {result}") # 把工具结果作为function角色消息回填 messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": str(result), }) else: # 超过最大步数仍未结束，强制终止 print("已达最大步数限制，强制停止") print(f"当前消息序列长度: {len(messages)}") if __name__ == "__main__": run_agent("北京今天天气怎么样？另外帮我算一下 1200*1.13 是多少")4.3 你会看到什么
把上面代码跑起来，你会看到类似这样的流程输出：
用户输入: 北京今天天气怎么样？另外帮我算一下 1200*1.13 是多少 第1步：模型请求调用工具 -> 工具 get_weather({"city": "北京"}) = 晴，21°C，微风 -> 工具 calculator({"expression": "1200*1.13"}) = 1356.0 第2步：模型直接回答 最终答案: 北京今天天气为晴，21°C，微风；1200乘以1.13的结果是1356.0。请注意，模型在第一步里"同时"调用了两个工具（Tool Call并行执行），执行结果回填后，模型在第二步综合所有信息给出了最终回答。这背后就是我前文说的Agent Loop：
模型判断->请求调用工具->系统执行->结果回填->模型再判断。
4.4 这段代码里藏着的三个关键工程点
第一，工具定义必须清晰。模型并不知道你的函数怎么调，它只是根据你给的JSON Schema猜测参数。如果你描述写得不清楚，模型就会传错参数。我见过很多生产事故都是因为"工具描述太简略"，模型把"city"传成了"北京市"或者把"expression"传成了"1200 X 1.13"。所以工具的description字段值得认真写，它直接决定了模型的调用准确率。
第二，工具结果一定要回填。看代码里的messages.append({"role": "tool", ...})，这一步是Agent循环的命脉。很多初学者在这儿偷懒，把工具执行结果直接用print打印，而没有喂回模型对话上下文，结果模型永远不知道刚才查到了什么。
第三，循环必须设上限。max_steps=5这个参数看起来微不足道，但生产环境里如果没有这个上限，一个失控的路由（比如模型反复调用一个失败的工具）会让你的API账单在几分钟内爆炸。真实项目里我还会加上单轮工具超时、全局任务时间上限、以及异常工具结果的分支处理。
注意：上面main代码里的
tool_choice="auto"意思是让模型自己决定是否调用工具。你也可以改成tool_choice={"type":"function","function":{"name":"get_weather"}}强制指定某个工具，这在某些必须走特定工具的流程里非常有用。
5. 当Agent动手"做事"：ReAct、工具调用和工作流的真实配合方式
5.1 从"一步工具调用"到"多步问题解决"
上面的极简Demo演示的是单轮甚至双轮的工具调用，而真实业务中，Agent经常要连续走六步、八步、甚至十几个工具调用。比如我问Agent："对比一下我们和竞品A在过去一个月的新品发布情况，并给出差异分析"，合理的执行链可能长这样：
- 调用搜索API，搜"竞品A 新品发布 这一个月"
- 打开搜索结果中排名靠前的新闻页面，抓取正文
- 提取每个发布产品的名称、时间、核心卖点
- 搜索"我们公司 新品发布 这一个月"，同样抓取信息
- 用代码工具把两边的发布时间线拉出来对比
- 汇总成结构化分析报告
这个链条之所以被称为"Agentic"，是因为模型每一步看到前一步的结果后，都在重新决定下一步做什么。它不是预先编排好的死流程。
5.2 ReAct模式：给模型一张"思考草稿纸"
ReAct模式是当前Agent架构里最经典也最实用的推理框架，核心就八个字：推理、行动、观察、循环。
ReAct的关键在于，除了用户的输入和工具返回的结果，它还会把模型自己的"思考过程"也放回到上下文中。这样一来，模型不再是生硬地被逼着猜下一步，而是像我们人一样，在草稿纸上先写几句"现在是什么情况、下一步应该干嘛、理由是啥"，然后再动手。
实际效果是什么呢？模型在上下文里多写这几次思考，决策准确率会有肉眼可见的提升，尤其是在对话链比较长、信息比较琐碎的任务上。这就好比你让一个实习生干活，只给指令他容易跑偏；但如果你让他每做完一步就先用一两句话说一下"我看到了什么、我打算怎么做"，你可以及时发现问题，他也会更少犯低级错误。
5.3 工作流（Workflow）和Agent是两种互补思路
很多人会把Agent和工作流对立起来，好像"用Agent就是高级，用工作流就是老土"，实际上这两种思路是互补的。
- 工作流（Workflow）：流程是预先写死的。输入A之后一定是走B再到C，适合规则明确、步骤固定的任务。比如"客户的订单进来 -> 校验库存 -> 自动扣款 -> 推送物流单号"，这条路每一步都固定，用工作流跑又稳又便宜。
- Agent：路径是动态的。每一步根据模型判断决定，适合开放性强、没有标准答案的任务。比如"写一份竞品分析报告"，输入一样，但具体行为完全取决于输出内容。
我的建议是：能用工作流搞定的，就不要上Agent。Agent不是银弹，它是带着"自由度"的成本来的——自由度越高，出错的可能性越大，调试和审计的难度也会水涨船高。最合理的形态是两者的组合：外层用工作流定义好主线骨架，内层遇到不确定性环节再交给Agent动态处理。
6. 工具的历史性跃迁与Agent的实用边界：什么场景能上，什么场景别硬上
6.1 从联网搜索到"操作API"再到"控制浏览器"
聊完原理，再聊聊Agent能碰触现实世界的三种主要工具形态。理解了这个，你就知道为什么Agent催生了那么多"AI取代XX岗位"的讨论。
第一类：信息获取工具。最典型的就是搜索工具、RAG（检索增强生成）里的向量数据库、网页爬虫。Agent用它们来"看世界"。这个是一个颠覆性的能力跃迁——大模型不再依赖训练数据的那一页知识，它可以去实时检索它没见过的东西。我印象非常深的是第一次把搜索工具挂到Agent上，问它"搜一下昨天发布的行业白皮书讲了什么"，它居然真的自己打开了多个网页并给出了答案。那一刻我真的觉得，原来的GPT是关在小房间里的天才，现在房间门打开了。
第二类：操作工具。包括代码解释器、数据库、API接口、内部系统。这类工具让Agent能"做事情"。比如数据分析Agent连上数据库之后，可以自己写SQL取数、写Python做清洗、再生成可视化图表，一口气拉通整条数据流水线。
第三类：自动化工具。浏览器自动化和RPA。这类工具让Agent像人一样"点击网页"。但它们也是目前事故率最高的一类——自动化操作走的边界很模糊，很容易破坏生产环境或踩到业务合规红线。如果你让Agent自动操作一个生产系统的界面，只要它点错一个按钮，后果可能就是脏数据或真实资金损失。
6.2 什么场景别硬上Agent
我踩过不少坑，也复盘过很多失败的Agent项目。总结下来，有三类场景我劝你不要急着上Agent：
场景一：任务本身模糊且无法验收。如果连你自己都不知道"成功"长什么样，那Agent只会给你整一堆花活。比如"帮我想个好的营销策略"，这种任务开了Agent等于开盲盒。先定义清晰的验收标准再上Agent，否则一场空。
场景二：高频、实时、需要审批的关键交易。自动下单、自动转账这类涉及资金的操作，Agent一旦出错，代价是不可逆的。可以让它算方案、给建议、生成指令，但最后一步请务必保留人工确认。说白了，容错成本决定自动化边界，这个道理在哪都成立。
场景三：模型能力明显不够的任务。如果你的任务本身逻辑深度极高，连最强模型自己都搞不明白，那加再多的Agent框架也救不回来。就像驾校教练再专业，让一个游泳教练去教开车，换再好的汽车品牌也没用。先用小规模实验验证模型本身的基础能力，再决定要不要上全套Agent架构。
6.3 高性价比的Agent落地方向
反过来，有哪些方向是投入产出比很高的？根据我自己的观察和实践，这几类是最容易见到真金白银的：
- 数据分析和报表生成。模型写SQL、做数据透视、生成图表的能力已经比较成熟，配上数据库工具，能把初级分析师几天的工作压缩到几十分钟。
- 客户支持和工单分诊。除了常见的FAQ问答，Agent真正强的地方在于边问边查：问客户要单号、查订单系统、判断物流异常原因，然后解决。全链路能缩短到原来的1/10。
- 内容生产流水线。从选题、搜索资料、生成初稿、配图建议到SEO优化，整套流程编排好，一个Agent并发可以顶上一个小型内容团队的产能，虽然质量上限取决于模型水平，但效率提升是实打实的。
- 私人知识助理。把文档、知识库、过往决策沉淀进长期记忆，让它随时能被检索。这个不是传统RAG，而是真的利用长期记忆机制让Agent越用越懂你。
7. 跑通第一个Agent前后，我踩过的五个具体坑
前面讲了原理、框架、落地场景，最后分享一些实操中的具体教训。这些不是我编出来的，是真实踩过坑之后总结的经验，我把它整理成一个checklist，按顺序帮你避坑。
7.1 不要跳过"人工审查"就上生产
AI Agent的输出天然具有概率性，加上工具调用链条长，错误会被层层放大。我在做数据分析Agent时遇到过：模型在写SQL时少了一个WHERE条件，导致取数范围错了，结果后续的所有分析都是基于错误数据做的，而Agent完全察觉不到，还一本正经输出了结论。要不是人工复核发现，这就要闹出事故了。
所以任何Agent系统上线初期，"人在回路"（Human-in-the-Loop）是一定要保留的。尤其是关键数据的产出环节，至少加一道人工抽查。
7.2 工具越多，模型越容易"精神分裂"
工具数量超过50个之后，模型的选择准确率会下滑得非常快。解决方案有两个：一是做工具分组，让Agent先选组再选工具；二是利用模型自带的工具推荐/路由模块做预筛选。千万别一股脑把所有工具塞进上下文，那只会让模型无所适从。
7.3 上下文管理是成本的大头，不是token本身
Agent跑的轮次越多，历史上下文就越长。用户每次对话的完整历史都被重复塞进去，最后你会发现API账单上的token消耗远超你预估的1.5倍甚至2倍。我的建议是：对历史做窗口截断，核心信息抽成摘要放进记忆区，不要无脑全量携带。
7.4 重试机制要设上限，否则会吞掉预算
Agent调用工具失败时很自然会重试，但如果不设上限，一个坏工具能触发十几次无用重试。我见过最夸张的一次，一个夹取网页的Agent因为目标站点屏蔽了爬虫，连续重试了17次才停止。给每次工具重试设定2-3次上限，并加上超时熔断，这是血泪教训。
7.5 日志可观测性，做在功能之前
调试Agent和调试普通程序完全不同。普通程序有明确的函数调用栈，而Agent的决策是模型在prompt里"自由发挥"出来的。如果上线前没有把每一次模型判断、工具调用、返回结果、token消耗全部打点存档，出了事你连复盘都无从下手。所以Agent项目的可观测性绝对要排在功能之前。
8. 给新手的下一步行动路径
写到这里，"认识AI Agent"的核心骨架算是搭完了。最后给刚开始接触这个领域的朋友一份具体的行动清单：
- 先把第4节的极简Agent代码亲手跑通，跑通之后再加点新工具进去，感受一下模型是怎么从工具列表里做选择的。
- 阅读一篇高质量的Agent综述文，建立全局视野。重点理解ReAct、工具调用规范、多Agent协作三大块。
- 选定一个真实的小场景，比如"定时抓取行业新闻并生成摘要邮件"，用你选择的框架去落地，过程中的工程坑会逼你快速成长。
- 关注模型本身的工具调用能力迭代。Agent的上限很大程度上取决于模型的基础能力，你做的工程优化只是把模型的能力稳定释放出来，千万不要本末倒置。
我个人在实际项目中最深的体会是：Agent这个领域变化速度极快，但核心思想反而朴素——给聪明的模型装上可靠的行动闭环，并且每一步都让它能观察自己的行为结果。弄懂这一点，后面任何花哨的框架和概念都能顺着这条主线去理解。下一篇教程，我计划手把手带你搭建一个能连外部API、有记忆、能跑完整任务的实战Agent项目，到时见。
