Agent 入门：AI 学习闭环和飞轮

一、学习闭环：让每一个问题都有后续

“这段代码看不懂”可能包含几类不同的问题：语法不熟悉、数据流不清楚，或不了解业务为什么需要这一步。直接要求 AI 从头讲解，容易得到一份覆盖很广、却没有回答疑点的说明

学习闭环从定位疑点开始。输入是当前代码、预期行为和不理解的部分；输出应当是一段能够复述、也能够检查的解释

1. 在疑问出现时，立即捕捉它

遇到疑问时，先留下能够还原问题的上下文：相关代码、输入输出，以及自己原本的判断。无须等到问题表述得很完整，再开始提问

我以为 State 中的字段都会发给模型，但这里似乎只传入了 messages。请沿着这段代码指出模型实际收到的内容，并区分程序状态与模型输入

这里返回了工具调用请求，却没有直接得到查询结果。请说明接下来由谁执行函数，执行结果又怎样回到模型

这类问题给解释划定了范围：需要说明哪一次调用、哪一份数据，以及哪一个判断存在偏差。如果缺少信息，可以先让 AI 指出还需要查看哪些代码

已有基础也值得交代。例如，熟悉 Java、刚接触 Python 时，可以要求先解释对应概念，再回到 Python 的具体写法。类比用于建立联系，语言和框架之间的差异仍要单独确认

2. 用追问缩小理解上的缺口

第一次回答可以提供整体结构，后续追问则需要落到可观察的细节：数据从哪里进入、在哪一步改变，什么条件决定下一步

• 这个概念对应哪一段代码，接收什么、返回什么？
• 给定一个具体输入，程序会按什么顺序执行？
• 去掉这一步，哪些行为会改变？
• 能否先用固定数据演示，再接入模型？

例如，可以用“查询订单，再根据结果回答”理解 LangGraph 的 State、Node 和 Edge：先列出流程需要保存的字段，再看每个节点读取和更新哪些字段，最后沿分支追踪一次成功查询和一次查询失败

这样，术语就有了对应的执行过程。追问中发现的语法或框架知识缺口，可以单独拆出来补充，随后回到原来的流程继续检查

3. 通过复述和实践，确认是否真的理解

读起来顺畅的解释容易带来熟悉感。要判断自己能否使用它，可以先合上回答，用自己的话描述流程，再预测改动后的结果

我的理解是：模型生成工具调用请求，程序校验参数并执行函数，再把结果交回模型。请对照这段代码检查遗漏，指出哪些结论还需要查资料或运行验证

接着换一个相近场景，让 AI 提问、自己作答。例如，把一次成功查询改成“订单不存在”，先判断流程应当如何结束，再运行最小例子观察结果

核对时要区分两类依据：官方资料用于确认接口约定与框架行为，实际运行用于确认当前代码的表现。若结果与解释不一致，就带着输入、日志和差异继续追问

下面的组件把这个过程拆成五步。最后一步出现的新疑问，可以成为下一轮的起点

一次学习闭环结束时，应当留下能复述的解释，以及能支持或修正这段解释的验证结果

二、迭代飞轮：让知识与项目相互推动

解决一个疑问之后，解释可能仍然只存在于聊天记录里。下一次修改项目时，如果还要重新寻找背景、重问同一个问题，这一轮的收获就没有充分保留下来

迭代飞轮关注这些收获如何进入下一轮：项目提供具体问题，学习帮助解释和解决问题，代码、笔记与检查方法再成为后续工作的基础

1. 项目让学习有了具体对象

项目为技术选择提供了约束。同样是学习工具调用，一个只查询订单的小应用，就可以提出一组具体问题：参数如何定义、订单不存在时返回什么、哪些信息允许展示

其他方向也可以从一条可运行的路径开始：

• 知识库问答：选一组资料和几个问题，观察切块、检索与回答之间的关系
• 聊天工作台：完成一轮消息发送与流式展示，再检查取消和超时的行为
• 个人网站：让页面通过域名访问，再理解 Nginx、HTTPS 与文件部署的关系

范围越明确，越容易判断当前需要补什么知识。先完成一条路径、解释清楚关键步骤，再根据实际遇到的问题扩展功能

2. 实时讲解把“能运行”推进到“能理解”

代码运行成功，只说明当前输入下得到了一次结果。实时讲解更适合围绕一次具体执行展开，把涉及的文件、数据和分支串起来

请沿着一次请求讲解：入口在哪里，哪些函数会被调用，状态在哪里更新，结果怎样返回。说明这次修改影响了哪一步，以及可以怎样检查

理解正常路径之后，再选择一个边界条件：工具报错时是否还会生成回答，服务重启后哪些数据能够恢复，取消请求后后台是否继续执行

这些问题需要对照实现逐项确认。可以先预测行为，再查看日志或调整输入；若要修改代码，先说明预期改变，运行后比较结果。讲解、改动与观察围绕同一个问题进行，才容易发现理解中的缺口

3. 把一次解决问题，变成下一次的起点

一次问题处理结束后，可以检查是否留下了三类可复用的内容：

• 代码：保留已经验证的修改，并说明它解决了哪个问题
• 笔记：记录原因、选择依据和适用条件，便于找回当时的判断
• 验证方法：留下输入、预期结果与检查步骤，供下一次改动时复查

例如，排查模型请求超时时，需要记录等待发生在哪一层、日志能看到什么，以及界面怎样结束等待。调长超时参数是否有效，要结合实际原因判断；保留下来的记录则能帮助下一次排查从已有线索开始

这里的积累可以很小：一段关键代码、一条排查记录、一个可重现的例子。下面的飞轮展示了这些内容如何回到下一轮学习与实践中

飞轮能否持续，取决于每轮留下了什么：代码保存解决办法，笔记保存判断依据，验证方法帮助后续改动保持可检查

三、我的经验：先定方向，再让 AI 参与学习和项目

AI 可以沿着一个问题不断展开，学习时间却需要分配。对 Agent 入门，我更认同先了解技术路线、确定个人方向，再围绕项目组织学习顺序

1. 先看技术地图，再决定学习顺序

技术地图用于了解领域的组成：模型调用、Prompt、工具调用、RAG、流程编排、评测和部署分别解决什么问题，又在哪些地方相互依赖

有了大致位置，再结合目标安排顺序。例如，以工具调用为起点时，可以先跑通一次模型请求，再接入一个参数明确的本地函数，随后检查失败路径；检索和复杂编排可以等项目出现相应需求后再引入

每个阶段都应当有一个能够展示或解释的结果。看到新框架时，先判断它与当前问题的关系，再决定是否调整路线

2. 用公开资料建立依据，让 AI 帮助整合

整理学习资料时，我会优先选择来源明确、能够查看原文或代码的内容，并按用途交叉使用：

• 官方文档：确认接口、参数和框架约定，留意适用版本
• 公开项目：观察一项能力如何组织成可运行的实现，核对依赖与配置
• 技术博客：理解作者面对的问题、选择依据，以及方案成立的条件

AI 适合帮助解释术语、串联材料和整理待验证的问题。涉及关键行为时，可以要求它标明依据，再回到原文、源码或最小例子核对

资料之间出现差异，也是一条有用线索：先检查版本、运行环境和讨论范围是否一致，再判断结论能否用于当前项目

3. 做项目可以 “grill me”，学习可以 “grill it”

我用这两个说法区分追问的对象。做项目时，让 AI 追问自己的计划；学习时，围绕概念的机制、边界和例子继续追问

“grill me”：把实现前的判断说清楚

请先追问这个项目的目标用户、使用场景、最小功能、异常情况和验收标准。一次聚焦一个尚未明确的判断，等我回答后再继续

以客服 Agent 为例，需要先确认允许处理哪些请求、是否具有退款权限、权限由哪一层校验，以及何时转人工。回答这些问题，才能为实现和验收提供共同依据

“grill it”：把概念放到具体条件下检查

请解释这个机制解决的问题，给出一个最小例子，再说明一个不适用或容易误用的场景。标出需要查阅资料确认的部分

理解之后，可以让 AI 换一个输入提问，先由自己预测结果，再说明原因并运行检查。若无法解释预测与结果的差异，就回到对应步骤继续补充

这两种方式都需要保留自己的判断：需求是否合理由具体目标决定，技术解释是否成立由资料与执行结果支持

先用技术地图确定方向，再围绕项目提出问题；让每个问题经过解释与验证，并把有用的结果保留下来，供下一轮继续使用