基础篇

F22｜Agent不是另一个神经网络：用一次读文件讲清循环

基础篇约 2.6 千字1 组分步图解

从具体对象与小例子开始，理解计算过程与适用条件。

本节会用到

F01 · 先分清 F03 · 文字为什么要先变成Token编号 F15 · 从最后一排数到一个Token，再到一句回答

本章目录

动态图解 · F22

把一个Agent任务拆成真正发生的几轮

同一句用户任务，为什么可能调用模型不止一次？

LLM生成下一步提议，宿主执行获准的动作，把结果再交给LLM。这是外层任务循环；每次模型调用内部还要经历逐Token生成。外层的一轮工具行动不等于内部生成一个Token，两种“循环”不能混用。

调用标识把某次工具请求与其结果连接的ID。

工具结果程序实际执行后返回的内容。

上下文本轮明确交给模型的信息，而非整个电脑状态。

输入与适用条件：构造的只读教学任务：文件config.txt含timeout=30。泳道展示职责边界，不声称调用了真实商业API；数据和动作顺序固定。

1 / 8 · 1. 用户任务：读config.txt中的timeout

停留时间

步骤第1步，共8步

窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。

模型尚未看到磁盘文件。先区分用户给的任务与环境真实内容。

未读取

默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。

为什么需要

模型可以借助工具获得新证据，而不把一切都塞入参数。

怎样实现

按请求、校验、执行、结果回填、继续决策组织循环。

可能的代价与误解

忘记回填工具结果会让模型重复请求；把输出文本当执行证明会误报完成。

如何判断是否做对

对照每轮模型输入和工具日志，确认结果与call_id匹配。

先还原成普通程序

把Agent理解为一个围绕模型组织任务执行的系统：程序准备输入，调用模型，检查模型输出；如果输出要求用工具，就执行并把结果回填；如果已满足完成条件，就结束。

Harness或宿主是这套执行环境和控制逻辑的常用名称。模型负责生成候选动作或回答，宿主负责真正运行、保存状态和控制边界。不是模型内部突然长出了文件系统访问权限。

一个三次模型调用的完整例子

用户问：“文件里函数返回什么？”下面用教学消息，不对应某厂商全部API字段。

第一轮输入包括用户问题、可用工具说明：“read_file接受一个path，返回文件文本。”模型输出的是工具请求，例如read_file(path='demo.py')。此时文件尚未因此被读完。

宿主执行：检查路径允许访问，调用真实文件读取操作，得到def answer(): return 42，把结果与这次调用身份绑定。

第二轮输入包括原任务、前一轮工具请求及真实工具结果。模型现在可以根据源码答“返回42”，也可以提出进一步验证请求。假设它要求运行测试，宿主执行后返回测试输出。

第三轮输入含这份验证结果，模型组织最终回答。宿主仍应按照任务类型判断是否完成，不能只因为最后一句语气肯定就证明所有需求满足。

一轮、一回合和一个任务为什么要区分

本书把一次模型请求及其输出叫模型调用。用户发一个问题到收到本次答复可称一轮用户交互；其中可能包含很多模型调用和工具执行。产品中的Turn、Step、Thread具体定义可能不同，阅读源码要看该项目的类型和生命周期。

Thread或会话通常保存相关交互的组织关系；任务task是要实现的用户目标。一个长任务可能跨多次会话，一个会话也可能包含多个任务。

工作流与自由Agent的区别

工作流workflow可由程序预设步骤，例如“先查缓存，再查数据库，再生成回答”；更自主的Agent把更多下一步选择交给模型。两者可以混合，不是只有完全自由行动才叫先进。

固定流程有可预测性，自由选择有适应性；多加一个自主环节也增加错误和成本。简单需求已有明确路径时，没必要强制先规划、再多Agent研究、再反复审查。

什么叫工具，什么叫副作用

工具tool是宿主向模型提供的可调用能力。读文件、搜索、查数据库、运行测试都是工具形式。副作用是调用改变了外部世界，例如修改文件、发送邮件、提交代码。

模型生成一个工具名称不代表已完成副作用；副作用发生后响应丢失，也不代表它未发生。这就是F33要讲的unknown和幂等问题。

为什么Agent需要循环

在不知道文件内容时，模型无法可靠决定最终补丁；读完文件后才有新的信息。循环让“行动获得观察，观察改变下一步决策”成为可能。它不是为了让模型机械地多说几遍分析。

循环同时必须有结束条件、预算和无进展处理。比如相同搜索连续没有新证据时，就应该改变策略或报告缺口，而不是无限重复。

本书教学脚本的边界

离线演示可以让一个固定脚本依次返回预设工具请求，以展示消息怎样移动；这叫协议或控制流模拟，不是商业模型真实自主能力。只有接入真实模型并记录实测，才能讨论该模型在任务上的成功率。

运行示例 · F22

读取—发现缺口—再读取：让一次工具结果决定下一步

输入与条件。用户问“为什么超时？”教学仓库中config写 timeout=3，日志写 request elapsed=5，单位均在文件头声明为秒。

步骤与对象	内部动作	中间结果 / 新状态
1第1轮模型输入	任务＋read_file工具说明	提议读取config。
2第1个工具结果	拿到timeout=3秒	只能确认配置，还不能知道真实请求是否超时。
3第2轮模型输入	追加config结果	提议读取日志，而不是直接猜网络坏了。
4第2个工具结果	日志耗时5秒	有了配置与运行记录两个证据。
5第3轮回答	对齐同一请求和同一版本	5大于3，可说明本次请求超过配置时限；仍不能仅据此确定为何耗时5秒。

把过程连起来。Agent循环的价值是根据已取得证据确定缺什么，而不是机械地多问模型几次。

边界与反例。动作序列是教学构造，不是实测模型自动选择；这里证据只支持“超过时限”，不支持猜测更深根因。

依据与适用范围：[TOOLS]。示例输入和场景由本书明确设定。

课后自检

自检 1

工具调用JSON已生成，文件就已修改了吗？

查看参考答案收起参考答案

没有。还要宿主解析、授权、执行并核验外部状态。

自检 2

一次用户提问里可有多次模型调用吗？