Agent 学习近况：从工具调用到 Logging 模块化

当前的位置

9 月 17 日的学习记录把当前位置记为第 72 课：Logging 模块化。关注点开始从跑通一次工具调用，转向让程序的职责、失败和运行过程更清楚。

前面的第 53 课阶段档案保留了计算器 Agent 的整合细节。这份近况补充后续学习方向，不把旧版本的代码与新阶段混为一套实现。

工具执行开始有明确契约

笔记已经涉及四类对象：工具注册表、输入模型、输出模型和给模型看的工具说明。它们分别服务于函数查找、参数约束、结果约束与工具选择。

理解这条路径时，可以按顺序看：

1. 模型提出工具名称与参数。
2. 程序检查参数。
3. 工具函数执行。
4. 检查返回内容是否符合约定。
5. 组织结果，再交回模型。

记录中的统一结果结构包括 success、data 与 error。这样，调用者除了看到一段文字，也能识别结果是成功还是失败。具体字段约束仍需要配合实现与测试一起检查。

失败需要被分清

后续记录已经把输入校验失败、输出校验失败、连接问题、超时和业务错误分开讨论。

这些区分的价值在于帮助程序和人采取不同动作。参数不符合约定，首先应检查参数；连接问题需要检查连接；超过时限不能仅凭再等一次就当作解决。

timeout、retry 与 backoff 也进入了学习范围。仅有这些分支，不足以证明系统对所有失败都可靠，仍要用明确输入和预期结果做测试。

日志让一次运行更容易回看

记录中出现了 step、tool_name、success、error_type、duration_ms 与 run_id 等字段。关注点是能够找到某次运行、某轮决策和具体工具调用，而不只看到散落的 print 文本。

conversation_id 对应一段会话，run_id 对应一次 Agent 运行，tool_call_id 对应具体调用。它们解决的问题不同，需要在记录中保持关联。

日志部分已涉及控制台与文件的输出级别、滚动文件和日志配置。当前的模块化目标，是把日志配置从 agent.py 中移到独立模块，减少业务循环承担的职责。

下一步仍然分开记录

根据这份进度摘要，下面几项仍属于后续安排：

• 把运行轨迹组织成结构化 Trace，并考虑数据库持久化。
• 提取独立的工具执行器。
• 将权限和需要人工确认的操作真正接入执行流程。
• 继续学习长期记忆、RAG 与 Streaming。
• 补充用户隔离、测试、并发与部署。

天气相关工具已在学习摘要中出现，但现有摘要没有交代是否连接真实天气服务，因此这里不展示实时天气效果，也不把示例数值当作线上数据。

与阶段项目一起读

可以先看工具调用专题，再看计算器 Agent 阶段项目。前者解释闭环，后者保留具体整合记录，再回到这篇近况理解可靠性相关的新增工作。

围绕摘要中的可靠性主题，网站另补了三篇可运行的配套练习：工具契约、失败处理、结构化日志。这些新增资料不改变本页 9 月 17 日的学习记录，也不把后续计划改记为完成。

来源

整理自个人知识库《Agent 学到哪里了---9.17》。本页为 2026-09-17 学习进度的文字整理；第 72 课是记录中的当前位置，不代表之后的计划已经完成。