摘要自学 AI Agent 三个月从囤了 40 多篇教程一个都没跑通到用 90 天路径做出第一个能稳定完成任务的 Agent。本文记录我踩过的坑含具体报错和修复方法、走过的五个典型弯路以及最后验证有效的四阶段学习路径和 90 天计划表。结论先行光看教程学不会 Agent能验证你学会的只有跑通的任务。一、我先交个底收藏夹里的 40 多篇教程一篇都没跑通先说结论过去三个月我是那个收藏夹里躺着 40 多篇 Agent 教程、买了两门课、关注了十几个公众号但一行 Agent 代码都没跑通的人。直到第 7 周我才承认收藏夹在变厚能力没在变。后来在技术社区混多了才发现这种焦虑有个高度一致的表达模式「学习 AI Agent 有什么好方法能真正学到位」「怎样才能把 AI Agent 学好」「怎么学出成果」。注意这些问题的共同点问的都不是「学什么」而是「怎么学才能见效」。说明缺的从来不是资料——恰恰相反资料过剩才是问题。另一类声音更值得注意。一些有 CS 背景的实践者开始形成共识学 Agent 不要上来就啃论文堆公式先搞懂「怎么让代码跑通并解决问题」把基础拆解成可落地的模块逐个击破盯着真实场景的痛点找方向而不是死磕教科书案例用快速迭代代替完美主义先跑通一个准确率 60% 的最小版本再逐步优化。这两类声音放在一起指向了同一个结论AI Agent 学习的主要矛盾已经从「信息获取」转移到了「学习路径与验证方法」。┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ 教程过剩 │ -- │ 路径不清 │ -- │ 无法自证学会 │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ v v v 收藏夹越来越满 在论文与框架间 学了三个月 动手次数为零 来回摇摆 不知道自己到哪了二、为什么「看懂了」却「做不出来」要搞明白这个问题得先看看 Agent 到底是个什么东西。一个 AI Agent 的核心是一个闭环感知接收任务与环境信息→ 规划拆解目标、选择工具→ 行动调用工具或模型执行→ 观察获取执行结果→ 迭代。主流的 LLM Agent 通常以「模型 工具调用 循环」的形式实现这一点在 Anthropic 的工程实践总结 Building Effective Agents 中有清晰论述大多数场景下简单的组合模式prompt 检索 工具调用比复杂的多 Agent 编排更有效。┌─────────────────────────────┐ │ │ v │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 感知 │--│ 规划 │--│ 行动 │ └─────────┘ └─────────┘ └─────────┘ │ │ v v ┌─────────┐ ┌─────────┐ │ 观察 │--│ 工具执行 │ └─────────┘ └─────────┘这个结构决定了它的学习特性Agent 是一个行为系统不是知识系统。你无法通过「阅读」掌握一个行为系统——就像没有人能靠读游泳教程学会游泳。认知科学中这被称为「知识的错觉」识别一段解释与会用一组能力之间隔着大量的程序性知识procedural knowledge而程序性知识只能通过练习获得。这带来两个推论推论一教程的价值密度会随阅读量递减。前三篇教程帮你建立概念地图之后的第 N 篇教程大概率是在重复你已知的内容带来的只是「我在学习」的心理安慰。这也是为什么囤积式学习者的实际能力曲线在最初两周后基本走平。推论二学习单元应该是「任务」而不是「知识点」。传统技术学习比如学一门语言可以按知识点组织变量、循环、函数、类。但 Agent 是跨知识点的组合体——一个最小的可用 Agent 同时涉及 prompt 设计、工具定义、函数调用、错误处理。只有以任务为单位组织学习才能倒逼把这些知识点串起来。OpenAI 的 Function Calling 文档 之所以被广泛推荐为入门材料正是因为它围绕「让模型调用一个工具」这个最小任务组织内容而不是围绕概念。这两个推论我当时是不服的直到自己验证了第二遍才认看懂验证的是「知道」做出来验证的是「会做」本来就是两套度量体系。我能在评论区跟人辩论 ReAct 和 Function Calling 的区别但我第一个 Agent 连「查个天气再翻译成英文」都跑不利索——这两件事同时为真毫不矛盾。三、我踩过的五个坑几乎每个自学者都会中招下面五个坑前四个我都亲自踩过第五个最隐蔽是后来做验证时才回过味来的。坑一论文优先啃了两周什么都没留下我第一个月把 ReAct、ToT、Reflection 三篇论文打印出来啃笔记记了 20 多页。结果动手时发现一个尴尬的事论文里的「推理-行动交织」落到代码里就是「把工具执行结果拼回消息列表再调一次模型」这么朴素的一行。我记的 20 页笔记里没有一页能帮我写出这一行。论文的价值在解释「为什么这样设计有效」但这个「为什么」只有踩过坑才能真懂。更合理的顺序是先跑通一个最小 Agent带着「我的 Agent 在哪一步总是失败」的具体问题再回头看论文——那时它才 readable。坑二框架焦虑选型选了两个周末LangChain、LlamaIndex、AutoGen、CrewAI……我在框架选型上花掉两个完整周末看对比帖、画架构图就是没写代码。后来想通了一件事框架封装的正是我需要亲手理解的那个循环。用框架入门等于把学习对象外包了出去。裸 API 写一个 100 行以内的 Agent 循环见第四节代码之后再回头看 LangChain 文档你能一眼看出它替你做了什么、哪些抽象是你不需要的——这个判断力只能从「写过」里来。坑三完美主义起步架构图画了三版代码零行想一口气设计出「正确的架构」再动手先选模型、再选记忆方案、再研究多 Agent 通信协议……我第三版架构图画完的那天代码行数还是零。实践者社区的经验高度一致先搭出能跑的最小版本哪怕准确率只有 60%然后用日志扒执行过程逐段归因修复。Agent 开发的现实是架构问题只有在运行中才会暴露纸上谈兵式的架构设计是伪工程。坑四只做玩具跑通了却什么都没学到跟着教程做了「天气查询 Agent」跑通那一刻成就感满满。但把它换成「查订单、判断能否退换、生成回复文案」这种两步任务立刻翻车模型在第二步忘了第一步查到了什么。玩具任务的单轮特性一次工具调用即完成跳过了 Agent 最核心的挑战多步规划与失败恢复。学习必须在真实场景的痛点上发生——比如「如何降低人工转接率」这类具体问题它天然包含多轮交互、工具选择、异常处理等完整复杂度。坑五轻信自我描述这个最隐蔽这是最致命的坑用「我学过」作为能力证明。我跟人说「会用 LangChain 做 Agent 了」但被追问「你的 Agent 在什么任务上、达到什么成功率、和基线差多少」时答不上来。这个坑在评估 Agent 本身时同样致命——一个 Agent 的自我报告「我已完成任务」与它的真实执行结果之间可能有巨大鸿沟。Lilian Weng 在 LLM Powered Autonomous Agents 里对 Agent 能力边界的系统分析出发点正是这种「声称的能力」与「验证的能力」之间的差距。┌─────────────────────────┐ ┌─────────────────────────┐ │ 自我描述体系 │ │ 验证体系 │ ├─────────────────────────┤ ├─────────────────────────┤ │ 我看完了 X 教程 │ │ 我在任务 T 上达到成功率 S │ │ 我用过 Y 框架 │ │ 失败案例归因于环节 E │ │ 我了解了 Z 概念 │ │ 与基线 B 相比提升 Δ │ ├─────────────────────────┤ ├─────────────────────────┤ │ 不可复现 · 不可比较 │ │ 可复现 · 可比较 · 可迭代 │ └─────────────────────────┘ └─────────────────────────┘四、最后跑通的路径四阶段每步都有验收标准踩完坑后我重建了学习路径设计原则只有一条每一阶段都以上一阶段的可验证产出为输入任何一步都不接受「我懂了」作为完成标志。阶段一裸写最小循环第 1-2 周目标不借助任何框架用模型 API 手写一个工具调用循环。产出物一个能多轮调用工具、并在工具失败时重试或降级的脚本。我第一版代码有三个真实翻车点都是写完才知道的①工具 schema 的 description 写得太省模型死活不调用工具②工具返回了一大段 HTML直接撑爆上下文模型开始胡说③忘了设步数上限一个死循环烧了我一块多 token 费。这三个坑的解法全在下面这段代码的注释里importjsondefrun_agent(model_client,tools,task,max_steps8):最小 Agent 循环规划 - 调用工具 - 观察 - 迭代。 特点无框架依赖每个环节的行为都可以在日志中观察。 messages[{role:user,content:task}]forstepinrange(max_steps):respmodel_client.chat(messagesmessages,tools[t[schema]fortintools],)ifnotresp.tool_calls:# 模型认为任务完成returnresp.contentforcallinresp.tool_calls:tooltools.get(call.name)try:resulttool[fn](**call.arguments)exceptExceptionase:# 失败不终止反馈给模型重试resultjson.dumps({error:str(e)})# 把执行结果作为观察喂回循环 —— 这一步是 Agent 的灵魂messages.append({role:tool,tool_call_id:call.id,content:str(result)})returnMAX_STEPS_EXCEEDED# 显式暴露失败而非静默这个不到 30 行的循环把 Agent 的核心问题全部暴露在你面前工具 schema 怎么写模型才理解得对失败结果怎么反馈模型才能自纠max_steps 怎么定这些问题的答案就是你的第一手程序性知识——也是教程永远不会告诉你的部分。阶段二建立验证 harness第 3-4 周目标为你的 Agent 构造一个固定的任务集和自动化评分脚本。产出物10-20 个带预期输出的任务用例 一键回归脚本。defevaluate(agent,cases):验证 harnessAgent 能力必须经任务集度量而非自我报告。results[]forcincases:actualagent.run(c[task])passedc[check](actual)# 每个用例自带判分函数results.append({task:c[id],passed:passed})ratesum(r[passed]forrinresults)/len(results)print(f任务成功率:{rate:.0%})# 这才是能力的度量returnresults从此「我的 Agent 变好了」这句话有了唯一合法的表达方式harness 成功率从 X% 提升到了 Y%。你改的每一版 prompt、加的每一个工具都会被这个数字客观地奖励或惩罚。阶段三真实痛点项目第 5-10 周目标选一个真实、具体、有度量指标的任务做完整落地。选择标准建议参考社区实践从「如何降低人工转接率」这类能定义基线和目标的问题切入避免「做一个通用助手」这类无边界目标。强化学习方向的学习者可以用 Gymnasium 从「避障」这种单一小目标起步逐步增加任务复杂度——先让 Agent 在简化环境里学会一件小事比在复杂环境里什么都不会强得多。这一阶段的关键动作是把任务拆成可独立验证的模块环境交互模块、决策逻辑模块、评估模块。每个模块有独立的测试坏在哪儿一眼可见。模块化拆分还有一个容易被低估的收益它是归因效率的倍增器。没有模块边界的 Agent 出了问题你只能对着整条对话日志人肉排查有了模块边界你可以先跑一个 30 秒的模块级单测把问题域压缩到三分之一再看日志。随着项目变复杂这个效率差距会指数级放大——很多「Agent 项目做到后期失控」的案例复盘下来都是早期没有建立模块边界和模块级验证。另外一个实践建议为每个模块维护一份「失败样本库」。工具调用失败的真实输入输出、模型规划跑偏的完整对话、判分函数误判的边界用例——这些样本在两周后回看价值远超当时的直觉判断因为它们记录的是你所在的具体环境里最常发生的失败模式而不是教科书里的典型失败。阶段四能力审计与扩展第 11-12 周及以后目标对阶段性成果做一次完整审计——你的 Agent 在哪些任务型别上稳定、哪些上脆弱、失败模式是什么。产出一份「能力清单」它同时是你下一步学习的路线图清单上最脆弱的那一项就是下一个学习周期最值得投入的方向。五、我的 90 天计划表可直接抄把上述路径压缩成一个具体到周的示例以「电商客服 Agent」为例这是社区实践中被反复验证过入行性价比最高的方向之一阶段时间任务验证标准最小循环第 1-2 周裸 API 写客服问答 Agent工具查订单、查库存人工抽测 10 单对话≥6 单正确验证 harness第 3-4 周构造 20 个典型客诉用例 自动判分一键回归跑通得到基线成功率真实项目第 5-10 周接入退换货流程多轮、多工具harness 扩到 50 用例成功率 ≥80%能力审计第 11-12 周失败案例归因输出能力清单每类失败有归因和改进方案这个设计里有四个容易被忽视但决定成败的细节第一基线要早定。第 3 周产出的基线成功率是后续所有改进的参照系。没有基线的优化是玄学。第二日志比指标重要。成功率告诉你「好不好」日志告诉你「为什么」。每个失败用例的完整对话日志都应该被保存——它们就是你的学习教材比任何教程都贴合你的实际水平。第三警惕「成功率的假阳性」。当你发现 Agent 在某类任务上成功率突然提升先检查是不是用例泄露了答案比如判分函数写松了再归功于自己的改进。这个习惯的本质仍然是「验证优先于相信」。第四控制任务复杂度的爬坡速率。一个常见的节奏错误是在成功率刚过 60% 时就急着上多 Agent 协作、长期记忆这类高级特性。更稳健的做法是遵循「成功率 80% 再爬坡」原则单 Agent 在当前任务档位稳定到 80% 以上再引入下一个复杂度层级。这条经验与强化学习里「课程学习curriculum learning」的结论一致——在过难的任务上训练学到的不是能力而是随机性。六、总结三个月教会我的一件事回到开头的那些提问「学习 AI Agent 有什么方法能真正学到位」我的答案可以压缩成三句话以任务为学习单元以可复现的验证为完成标准以真实痛点为方向选择器。围绕这三句话教程从主粮变成了字典框架从拐杖变成了放大器论文从天书变成了答疑老师。而这套学习哲学恰好也是评估 Agent 工具本身的正确姿势。当你逐渐建立起「验证优先」的习惯你自然会用同样的标准审视市面上的 Agent 工具链一个工具说「我能帮你找到最好的 Skill」你要问的是——它在什么任务集上、以什么成功率、和什么基线比这种审视能力恰恰是自学过程中最珍贵的副产品。学习 Agent 的终点不是「我知道 Agent 是什么」而是「我能构建、度量并信任一个 Agent」。前一句是知识的错觉后一句是能力的事实。写在最后如果你也在自学 AI Agent或者正在某个坑里出不来欢迎评论区交流你的卡点我会逐条回复。后续我会把 90 天计划里每周的实测记录整理成系列文章持续更新。
自学 AI Agent 三个月：从收藏夹吃灰到跑通第一个 Agent 的完整复盘
摘要自学 AI Agent 三个月从囤了 40 多篇教程一个都没跑通到用 90 天路径做出第一个能稳定完成任务的 Agent。本文记录我踩过的坑含具体报错和修复方法、走过的五个典型弯路以及最后验证有效的四阶段学习路径和 90 天计划表。结论先行光看教程学不会 Agent能验证你学会的只有跑通的任务。一、我先交个底收藏夹里的 40 多篇教程一篇都没跑通先说结论过去三个月我是那个收藏夹里躺着 40 多篇 Agent 教程、买了两门课、关注了十几个公众号但一行 Agent 代码都没跑通的人。直到第 7 周我才承认收藏夹在变厚能力没在变。后来在技术社区混多了才发现这种焦虑有个高度一致的表达模式「学习 AI Agent 有什么好方法能真正学到位」「怎样才能把 AI Agent 学好」「怎么学出成果」。注意这些问题的共同点问的都不是「学什么」而是「怎么学才能见效」。说明缺的从来不是资料——恰恰相反资料过剩才是问题。另一类声音更值得注意。一些有 CS 背景的实践者开始形成共识学 Agent 不要上来就啃论文堆公式先搞懂「怎么让代码跑通并解决问题」把基础拆解成可落地的模块逐个击破盯着真实场景的痛点找方向而不是死磕教科书案例用快速迭代代替完美主义先跑通一个准确率 60% 的最小版本再逐步优化。这两类声音放在一起指向了同一个结论AI Agent 学习的主要矛盾已经从「信息获取」转移到了「学习路径与验证方法」。┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ 教程过剩 │ -- │ 路径不清 │ -- │ 无法自证学会 │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ v v v 收藏夹越来越满 在论文与框架间 学了三个月 动手次数为零 来回摇摆 不知道自己到哪了二、为什么「看懂了」却「做不出来」要搞明白这个问题得先看看 Agent 到底是个什么东西。一个 AI Agent 的核心是一个闭环感知接收任务与环境信息→ 规划拆解目标、选择工具→ 行动调用工具或模型执行→ 观察获取执行结果→ 迭代。主流的 LLM Agent 通常以「模型 工具调用 循环」的形式实现这一点在 Anthropic 的工程实践总结 Building Effective Agents 中有清晰论述大多数场景下简单的组合模式prompt 检索 工具调用比复杂的多 Agent 编排更有效。┌─────────────────────────────┐ │ │ v │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 感知 │--│ 规划 │--│ 行动 │ └─────────┘ └─────────┘ └─────────┘ │ │ v v ┌─────────┐ ┌─────────┐ │ 观察 │--│ 工具执行 │ └─────────┘ └─────────┘这个结构决定了它的学习特性Agent 是一个行为系统不是知识系统。你无法通过「阅读」掌握一个行为系统——就像没有人能靠读游泳教程学会游泳。认知科学中这被称为「知识的错觉」识别一段解释与会用一组能力之间隔着大量的程序性知识procedural knowledge而程序性知识只能通过练习获得。这带来两个推论推论一教程的价值密度会随阅读量递减。前三篇教程帮你建立概念地图之后的第 N 篇教程大概率是在重复你已知的内容带来的只是「我在学习」的心理安慰。这也是为什么囤积式学习者的实际能力曲线在最初两周后基本走平。推论二学习单元应该是「任务」而不是「知识点」。传统技术学习比如学一门语言可以按知识点组织变量、循环、函数、类。但 Agent 是跨知识点的组合体——一个最小的可用 Agent 同时涉及 prompt 设计、工具定义、函数调用、错误处理。只有以任务为单位组织学习才能倒逼把这些知识点串起来。OpenAI 的 Function Calling 文档 之所以被广泛推荐为入门材料正是因为它围绕「让模型调用一个工具」这个最小任务组织内容而不是围绕概念。这两个推论我当时是不服的直到自己验证了第二遍才认看懂验证的是「知道」做出来验证的是「会做」本来就是两套度量体系。我能在评论区跟人辩论 ReAct 和 Function Calling 的区别但我第一个 Agent 连「查个天气再翻译成英文」都跑不利索——这两件事同时为真毫不矛盾。三、我踩过的五个坑几乎每个自学者都会中招下面五个坑前四个我都亲自踩过第五个最隐蔽是后来做验证时才回过味来的。坑一论文优先啃了两周什么都没留下我第一个月把 ReAct、ToT、Reflection 三篇论文打印出来啃笔记记了 20 多页。结果动手时发现一个尴尬的事论文里的「推理-行动交织」落到代码里就是「把工具执行结果拼回消息列表再调一次模型」这么朴素的一行。我记的 20 页笔记里没有一页能帮我写出这一行。论文的价值在解释「为什么这样设计有效」但这个「为什么」只有踩过坑才能真懂。更合理的顺序是先跑通一个最小 Agent带着「我的 Agent 在哪一步总是失败」的具体问题再回头看论文——那时它才 readable。坑二框架焦虑选型选了两个周末LangChain、LlamaIndex、AutoGen、CrewAI……我在框架选型上花掉两个完整周末看对比帖、画架构图就是没写代码。后来想通了一件事框架封装的正是我需要亲手理解的那个循环。用框架入门等于把学习对象外包了出去。裸 API 写一个 100 行以内的 Agent 循环见第四节代码之后再回头看 LangChain 文档你能一眼看出它替你做了什么、哪些抽象是你不需要的——这个判断力只能从「写过」里来。坑三完美主义起步架构图画了三版代码零行想一口气设计出「正确的架构」再动手先选模型、再选记忆方案、再研究多 Agent 通信协议……我第三版架构图画完的那天代码行数还是零。实践者社区的经验高度一致先搭出能跑的最小版本哪怕准确率只有 60%然后用日志扒执行过程逐段归因修复。Agent 开发的现实是架构问题只有在运行中才会暴露纸上谈兵式的架构设计是伪工程。坑四只做玩具跑通了却什么都没学到跟着教程做了「天气查询 Agent」跑通那一刻成就感满满。但把它换成「查订单、判断能否退换、生成回复文案」这种两步任务立刻翻车模型在第二步忘了第一步查到了什么。玩具任务的单轮特性一次工具调用即完成跳过了 Agent 最核心的挑战多步规划与失败恢复。学习必须在真实场景的痛点上发生——比如「如何降低人工转接率」这类具体问题它天然包含多轮交互、工具选择、异常处理等完整复杂度。坑五轻信自我描述这个最隐蔽这是最致命的坑用「我学过」作为能力证明。我跟人说「会用 LangChain 做 Agent 了」但被追问「你的 Agent 在什么任务上、达到什么成功率、和基线差多少」时答不上来。这个坑在评估 Agent 本身时同样致命——一个 Agent 的自我报告「我已完成任务」与它的真实执行结果之间可能有巨大鸿沟。Lilian Weng 在 LLM Powered Autonomous Agents 里对 Agent 能力边界的系统分析出发点正是这种「声称的能力」与「验证的能力」之间的差距。┌─────────────────────────┐ ┌─────────────────────────┐ │ 自我描述体系 │ │ 验证体系 │ ├─────────────────────────┤ ├─────────────────────────┤ │ 我看完了 X 教程 │ │ 我在任务 T 上达到成功率 S │ │ 我用过 Y 框架 │ │ 失败案例归因于环节 E │ │ 我了解了 Z 概念 │ │ 与基线 B 相比提升 Δ │ ├─────────────────────────┤ ├─────────────────────────┤ │ 不可复现 · 不可比较 │ │ 可复现 · 可比较 · 可迭代 │ └─────────────────────────┘ └─────────────────────────┘四、最后跑通的路径四阶段每步都有验收标准踩完坑后我重建了学习路径设计原则只有一条每一阶段都以上一阶段的可验证产出为输入任何一步都不接受「我懂了」作为完成标志。阶段一裸写最小循环第 1-2 周目标不借助任何框架用模型 API 手写一个工具调用循环。产出物一个能多轮调用工具、并在工具失败时重试或降级的脚本。我第一版代码有三个真实翻车点都是写完才知道的①工具 schema 的 description 写得太省模型死活不调用工具②工具返回了一大段 HTML直接撑爆上下文模型开始胡说③忘了设步数上限一个死循环烧了我一块多 token 费。这三个坑的解法全在下面这段代码的注释里importjsondefrun_agent(model_client,tools,task,max_steps8):最小 Agent 循环规划 - 调用工具 - 观察 - 迭代。 特点无框架依赖每个环节的行为都可以在日志中观察。 messages[{role:user,content:task}]forstepinrange(max_steps):respmodel_client.chat(messagesmessages,tools[t[schema]fortintools],)ifnotresp.tool_calls:# 模型认为任务完成returnresp.contentforcallinresp.tool_calls:tooltools.get(call.name)try:resulttool[fn](**call.arguments)exceptExceptionase:# 失败不终止反馈给模型重试resultjson.dumps({error:str(e)})# 把执行结果作为观察喂回循环 —— 这一步是 Agent 的灵魂messages.append({role:tool,tool_call_id:call.id,content:str(result)})returnMAX_STEPS_EXCEEDED# 显式暴露失败而非静默这个不到 30 行的循环把 Agent 的核心问题全部暴露在你面前工具 schema 怎么写模型才理解得对失败结果怎么反馈模型才能自纠max_steps 怎么定这些问题的答案就是你的第一手程序性知识——也是教程永远不会告诉你的部分。阶段二建立验证 harness第 3-4 周目标为你的 Agent 构造一个固定的任务集和自动化评分脚本。产出物10-20 个带预期输出的任务用例 一键回归脚本。defevaluate(agent,cases):验证 harnessAgent 能力必须经任务集度量而非自我报告。results[]forcincases:actualagent.run(c[task])passedc[check](actual)# 每个用例自带判分函数results.append({task:c[id],passed:passed})ratesum(r[passed]forrinresults)/len(results)print(f任务成功率:{rate:.0%})# 这才是能力的度量returnresults从此「我的 Agent 变好了」这句话有了唯一合法的表达方式harness 成功率从 X% 提升到了 Y%。你改的每一版 prompt、加的每一个工具都会被这个数字客观地奖励或惩罚。阶段三真实痛点项目第 5-10 周目标选一个真实、具体、有度量指标的任务做完整落地。选择标准建议参考社区实践从「如何降低人工转接率」这类能定义基线和目标的问题切入避免「做一个通用助手」这类无边界目标。强化学习方向的学习者可以用 Gymnasium 从「避障」这种单一小目标起步逐步增加任务复杂度——先让 Agent 在简化环境里学会一件小事比在复杂环境里什么都不会强得多。这一阶段的关键动作是把任务拆成可独立验证的模块环境交互模块、决策逻辑模块、评估模块。每个模块有独立的测试坏在哪儿一眼可见。模块化拆分还有一个容易被低估的收益它是归因效率的倍增器。没有模块边界的 Agent 出了问题你只能对着整条对话日志人肉排查有了模块边界你可以先跑一个 30 秒的模块级单测把问题域压缩到三分之一再看日志。随着项目变复杂这个效率差距会指数级放大——很多「Agent 项目做到后期失控」的案例复盘下来都是早期没有建立模块边界和模块级验证。另外一个实践建议为每个模块维护一份「失败样本库」。工具调用失败的真实输入输出、模型规划跑偏的完整对话、判分函数误判的边界用例——这些样本在两周后回看价值远超当时的直觉判断因为它们记录的是你所在的具体环境里最常发生的失败模式而不是教科书里的典型失败。阶段四能力审计与扩展第 11-12 周及以后目标对阶段性成果做一次完整审计——你的 Agent 在哪些任务型别上稳定、哪些上脆弱、失败模式是什么。产出一份「能力清单」它同时是你下一步学习的路线图清单上最脆弱的那一项就是下一个学习周期最值得投入的方向。五、我的 90 天计划表可直接抄把上述路径压缩成一个具体到周的示例以「电商客服 Agent」为例这是社区实践中被反复验证过入行性价比最高的方向之一阶段时间任务验证标准最小循环第 1-2 周裸 API 写客服问答 Agent工具查订单、查库存人工抽测 10 单对话≥6 单正确验证 harness第 3-4 周构造 20 个典型客诉用例 自动判分一键回归跑通得到基线成功率真实项目第 5-10 周接入退换货流程多轮、多工具harness 扩到 50 用例成功率 ≥80%能力审计第 11-12 周失败案例归因输出能力清单每类失败有归因和改进方案这个设计里有四个容易被忽视但决定成败的细节第一基线要早定。第 3 周产出的基线成功率是后续所有改进的参照系。没有基线的优化是玄学。第二日志比指标重要。成功率告诉你「好不好」日志告诉你「为什么」。每个失败用例的完整对话日志都应该被保存——它们就是你的学习教材比任何教程都贴合你的实际水平。第三警惕「成功率的假阳性」。当你发现 Agent 在某类任务上成功率突然提升先检查是不是用例泄露了答案比如判分函数写松了再归功于自己的改进。这个习惯的本质仍然是「验证优先于相信」。第四控制任务复杂度的爬坡速率。一个常见的节奏错误是在成功率刚过 60% 时就急着上多 Agent 协作、长期记忆这类高级特性。更稳健的做法是遵循「成功率 80% 再爬坡」原则单 Agent 在当前任务档位稳定到 80% 以上再引入下一个复杂度层级。这条经验与强化学习里「课程学习curriculum learning」的结论一致——在过难的任务上训练学到的不是能力而是随机性。六、总结三个月教会我的一件事回到开头的那些提问「学习 AI Agent 有什么方法能真正学到位」我的答案可以压缩成三句话以任务为学习单元以可复现的验证为完成标准以真实痛点为方向选择器。围绕这三句话教程从主粮变成了字典框架从拐杖变成了放大器论文从天书变成了答疑老师。而这套学习哲学恰好也是评估 Agent 工具本身的正确姿势。当你逐渐建立起「验证优先」的习惯你自然会用同样的标准审视市面上的 Agent 工具链一个工具说「我能帮你找到最好的 Skill」你要问的是——它在什么任务集上、以什么成功率、和什么基线比这种审视能力恰恰是自学过程中最珍贵的副产品。学习 Agent 的终点不是「我知道 Agent 是什么」而是「我能构建、度量并信任一个 Agent」。前一句是知识的错觉后一句是能力的事实。写在最后如果你也在自学 AI Agent或者正在某个坑里出不来欢迎评论区交流你的卡点我会逐条回复。后续我会把 90 天计划里每周的实测记录整理成系列文章持续更新。
