Agent 教程看了不少，我决定拿三个旧例子补基础

最近整理自己的 Agent 学习文章，我发现一个有点尴尬的问题：代码跟得下来，工具也能接起来，真要讲清楚"为什么这样设计"，还是会卡住。

我的博客里已经有 ReAct、Reflection 和几个 Agent 框架的笔记。但文章数量增加，并不代表这些知识在脑子里连起来了。于是我准备把学习节奏放慢一点，拿已有的串口网关、Reflection 和 LangGraph 例子，重新检查执行、反馈和状态。

先拆一次工具调用：究竟是谁在执行？

之前做串口测试时，我用 Python 的 pyserial 搭了一个网关，把模组指令收发封装成 HTTP API，让 AI 通过接口参与测试。当时最关心的是流程能否跑起来，现在我想沿一次调用往下追。

在这个项目里，模型提出工具名称与参数，执行程序向 HTTP 网关发请求，网关通过 pyserial 下发指令并读取回包，再把执行结果送回后续模型请求。

这条线看起来简单，却能把排查位置分开：

我的第一份复习作业，是找一次已有测试记录，把任务输入、工具参数、网关响应和最终报告放在一起。只看到"测试通过"还不够，我想找到支撑这句话的原始结果。

这里不需要先重写整个项目。能解释一次调用由谁完成、结果经过哪里，就比笼统地说"AI 帮我测了"更进一步。串口网关原记录

我以前写过一个生成素数函数的 Reflection 学习例子。回看运行记录，评审出现了"无需从算法层面改进"，后面却仍然进入了代码优化。

这不能直接当成程序错误。反馈还提到了工程优化，任务本身也可能允许继续调整。但它让我意识到，读懂模型的评价和读懂程序的控制逻辑，是两件需要分别完成的事。

接下来我准备检查四个位置：停止条件、评审输出格式、解析方式、最大迭代次数。

先用固定反馈检查控制分支：输入"通过""需要修改"和无法识别的内容，分别预测程序会继续还是结束，再运行核对。这样可以先把程序逻辑看清楚，随后再观察真实模型的输出。

生成出来的函数也要单独验证。以"返回不大于 n 的素数列表"为约定，最初可以从这些输入开始：

这只是测试起点，还需要更多边界和范围检查。评审措辞变好了，并不能替代函数在测试中的表现。我想比较的是：修改前后，究竟哪一项结果变了。Reflection 原笔记

博客里的 LangGraph 例子是一个三步问答助手：理解问题、搜索、生成回答。状态里有 search_query、search_results 和 step 等字段。

过去我容易把这些字段当成实现细节。现在想想，它们正好能告诉我：搜索节点拿到了什么，返回结果存在哪里，回答节点实际读取了什么。

那个例子里，搜索失败后还可以使用模型已有知识继续回答。所以，只看最终答案是否流畅，无法判断本次搜索有没有成功。

我准备固定一个需要外部资料的问题，给后续节点分别提供三种情况：

如果问题需要最新信息，失败后是否还适合继续回答，也得单独考虑。框架提供了组织流程的方式，具体任务仍需要合理的失败处理。LangGraph 原笔记

接下来，我想尽量复用同一批脱敏日志和样例，按下面的顺序复习：

这些是我接下来准备做的练习。每一步都留一个具体产出，比继续收藏一份讲得很顺的解释，更方便日后回看和检查。

用 AI 帮忙时，我也想改变问法。先写自己的判断，再让它找反例：

我理解这段程序会在评审通过后停止。请帮我找到实际退出条件，并给一个可能让我的理解不成立的输入。我先预测，再运行检查。

一轮结束，记下四行：原先怎么想，实际看到什么，为什么有差别，下次先查哪里。

我还是会继续写实践文章。只是希望下次讲一个 Agent 项目时，能更清楚地说出：我做了什么，它为什么这样工作，我又怎样知道结果可信。

我是 Aiclaw，做车联网软件，也持续学习和实践 AI、Agent。完整学习笔记和工程记录放在我的博客。