准备：按 README 启动 Loop，使用自带的 workspace/，打开网页。实验 1、2 分别点击左侧“新任务”；实验 3 的两条消息必须在同一段对话里发送。
每次先写预测，再运行。只根据实际轨迹判断：模型未按实验要求提出调用时，记录“未触发目标分支”，不要把预期写成事实，也不要为了得到漂亮结果反复重跑。真实模型请求会消耗服务额度；查看已经保存的记录不会再次请求模型。
复制 记录表，填写自己的预测、Run ID 和事件证据。每题用“待验证／需要提示／能独立解释”记录理解程度，不用模型回答是否流畅代替学习验收。
先预测。 本轮模型请求上限为 1，第一次响应同时提出两个合法工具调用。两个工具能否都执行？之后能否再次请求模型？最终会是什么运行状态？
在左侧“新任务”中，将“本轮请求上限”改为 1，发送：
请在第一次模型响应中同时提出两个工具调用：list_files，path 为 .；read_file，path 为 agent-loop.md。拿到两个结果后再总结笔记主题。只读。
检查轨迹。
- 展开“模型轮次 1”的原始记录，确认实际输出的
message.tool_calls是否有两个元素。没有两个时，本次不能证明“同批两个工具”的分支。 - 若确有两个合法调用，检查两条 TOOL 记录及各自的 RESULT。工具调用 ID 应分别配对，不能拿另一条回执代替。
- 查看 STOP 记录，以及本轮模型请求次数。正常情况下应是一次模型请求、两次工具调用，随后
budget_exhausted；没有第二次模型请求，也没有最终回答。
完成标准。 你能指出两条工具事件，以及终止循环的证据；能解释“本轮请求上限”为什么不等于“最多执行一个工具”。
连接代码。 在源码页找到 src/agent.ts 的 RunLoop：外层循环限制模型请求次数，内层循环处理本批所有工具调用。不要把一个 TOOL 事件当作下一次模型请求。
写完预测后再看自查说明
工具调用请求属于第一次模型响应。执行这批调用不会消耗第二次模型请求额度。收齐结果后，外层请求额度已经用完，所以不会再次调用模型生成总结。
同批只有一个调用、模型直接回答、响应被截断或工具被拒绝，都是不同的实际分支，要按本次记录解释。本题的预期只适用于前述两个合法调用的条件。
先预测。 请求读取一个不存在的文件，是否一定让整个 Agent 立即停止？下一次模型请求应携带什么证据？
点击“新任务”，将上限改为 6，发送：
先列出工作区文件。为了观察错误回执，请原样读取 agent-looop.md，不要预先纠正拼写。等错误返回后，再根据目录结果选择正确文件读取。不要把错误读取和纠正后的读取放在同一批调用中。最后说明错误如何被纠正，并引用一处实际读到的原文。只读。
检查轨迹。
- 找到失败的
read_file。记录真实参数、错误结果和tool_call_id。 - 在该事件的“说明”中点击“进入第 N 次请求的消息”，核对实际输入中的
role: "tool"、调用 ID 和错误内容。 - 查看后续模型实际提出的动作，及纠正后的工具结果。模型可能纠正，也可能说明证据不足；不要用本题的故意拼写错误概括它在所有任务上的恢复能力。
- 核对回答中的引文是否来自成功读取的内容。循环结束不自动等于任务验收通过。
完成标准。 你能从“错误工具结果”追到“下一次模型实际输入”，再指出模型做了什么；能解释错误回执与程序崩溃的区别。
连接代码。 src/tools.ts 的 ExecuteReadonly 返回可交给模型的错误对象；src/trace.ts 记录实际结果，src/agent.ts 将它作为配对的工具消息追加。
写完证据后再看自查说明
可处理的工具错误会变成回执，下一次模型请求才能据此决定怎么做。模型自行在回答里说“已经修正”不算证据，要有纠正后的实际工具请求和结果。
如果本次模型提前纠正了文件名，没有触发错误，则不能把这条轨迹记为错误恢复通过。如果出现模型接口、存储或其他非预期错误，保留记录并先讨论，不自动重试。
先预测。 同一对话发送两条消息，每条都只需要一次模型请求。页面应显示几个 Turn、几次模型请求？第二次请求如何知道第一条消息？
点击“新任务”，上限设为 2，发送：
请记住本段对话的代号是“青叶-42”，只回答“已记录”，不要调用工具。
结束后在同一个输入框追问：
刚才的代号是什么？只回答代号，不要调用工具。
检查轨迹。
- 顶部显示两个对话 Turn。若各自只请求模型一次，总模型请求数为 2；每个 Turn 内都从“模型轮次 1”开始。
- 比较两轮模型事件的实际输入。第一轮通常是
system → user；第二轮应保留这两条及第一轮的assistant回复，再追加新的user消息。 - 检查第二轮 CONTEXT 中的
history_messages和parent_run_id，并打开本地记录核对。继承的是消息，不是凭空多出一次后台模型思考。 - 刷新页面后，两轮对话及原始轨迹仍可回看。刷新本身不应新增模型请求。
完成标准。 你能指出第二轮输入中保存代号的那条消息；能解释为什么“Turn 2”和“模型轮次 1”可以同时出现。
连接代码。 src/conversation.ts 读取并校验上一轮消息；src/context.ts 更新本轮系统上下文并追加新的用户输入，src/trace.ts 保存实际发送的消息。原始事件的 turn 仍是模型请求计数，conversation_turn 才是用户对话轮次。
写完证据后再看自查说明
模型从请求携带的消息中读取前文。只看到它回答了代号，还不能单独证明上下文实现正确；实际发送的 messages 才能证明程序带上了哪些信息。
同一对话中的第一轮也可能调用工具、请求模型多次。因此两个用户 Turn 不保证只产生两次模型请求。更换代号可以重做练习，但不要把已有演示答案当作自己的观察结果。
请关闭自查说明，用自己的话回答，并给出一处本次运行证据：
- 模型提出工具请求后，谁负责执行？工具结果靠什么和原调用配对？
- 为什么本轮只有一次模型请求，却可能执行两个工具？
- 工具读取失败时，下一次模型请求在哪里看到错误？
- 两次用户提问为什么不等于两次模型请求？
- 页面显示“循环已结束”，还需要检查什么才能认定任务完成？
只有能找到证据并独立解释时，才将对应项记为“能独立解释”。不知道时记录卡点，回看那一条事件；不需要一次补学所有 Agent 术语。