Agentic Loop
stop_reason 驱动的控制流与任务分解

Domain 1 是全卷最重的一块，而 agentic loop 是这块的地基。本章只讲两件事：循环该由什么信号驱动（以及三个被官方点名的反模式），以及一个复杂任务该怎么拆。两者共用一个判断轴——让模型的结构化输出驱动控制流，而不是让你的字符串解析驱动控制流。

一、循环的骨架

Agentic loop 的生命周期只有四步，考试反复在这四步的衔接处出题：发请求 → 检查 stop_reason（停止原因）→ 执行被请求的工具 → 把结果放回对话历史，进入下一轮。

messages = [{"role": "user", "content": task}]

while True:
    resp = client.messages.create(model=…, tools=TOOLS, messages=messages)

    # ① 控制流的唯一权威信号
    if resp.stop_reason == "end_turn":
        break                          # 模型认为任务结束，退出循环

    if resp.stop_reason == "tool_use":
        messages.append({"role": "assistant", "content": resp.content})
        results = [run_tool(b) for b in resp.content if b.type == "tool_use"]

        # ② 工具结果必须回灌进对话历史，模型才能据此推理下一步
        messages.append({"role": "user", "content": results})
        continue

两个容易被出题的细节：

• stop_reason 是控制流的唯一权威信号。 "tool_use" 表示模型请求执行工具、循环继续；"end_turn" 表示模型完成回合、循环终止。这是一个结构化字段，不需要也不应该去解析自然语言。
• 工具结果要追加进对话历史。 模型没有隐式记忆，下一轮它能看到什么，完全取决于你往 messages 里放了什么。漏掉这一步的典型症状是：模型反复请求同一个工具——因为在它看来那次调用从未发生过。

二、三个被官方点名的反模式

Exam Guide 在 TS 1.1 的 Skills 部分直接列出了三个要避免的反模式。它们是同一个错误的三种表现：用一个概率性的信号替换了一个确定性的信号（这正是 ch01 的 P3 与 D6 的题眼）。

三条的共同解药是同一句话：循环条件必须绑定在 API 返回的结构化字段上。考场识别信号很直白——只要一个选项里出现「检测到某段文字」「跑满 N 轮」「返回了文本就算完」，它就是错的。

三、模型驱动 vs 预配置决策树

这是 Domain 1 反复出现的另一条轴。两种控制风格的差别，不在于「谁更智能」，而在于决策权放在哪里：

注意这里和 P3（关键规则用确定性强制）的分工：需要 100% 合规时，正确做法是在模型驱动的循环外面加一道程序化闸门（阻断 process_refund 直到 get_customer 返回已验证的 customer ID），而不是把整个 agent 退化成 if/else 流程图。 前者保留了 agent 处理多样请求的能力，后者把它变成了一个昂贵的状态机。详见 ch04。

四、任务分解：固定流水线 vs 动态分解

一个复杂任务进来，第一个设计决策是「拆不拆、怎么拆」。Exam Guide 给了两种模式和一条选择规则：

模式 A：大型 code review 的两类 pass

一次性把十几个文件塞进同一个 review 请求，会出现注意力稀释（attention dilution）的典型症状：有的文件详评、有的敷衍，同一段模式在 A 文件被标为问题、在 B 文件被放行。解法是拆成两类 pass：

• per-file local pass — 每个文件单独一遍，保证深度一致；抓局部问题（空指针、边界、错误处理）。
• cross-file integration pass — 单独一遍看跨文件数据流；抓接口契约、状态共享、调用链问题。

注意这不是「多跑几遍取交集」——那会压掉只被间歇性发现的真 bug（这是 P7 的边界，也是官方样题 Q12 的 D 选项被判错的原因）。两类 pass 的关注点不同，不是同一件事做多次。

模式 B：开放式任务的三步走

「给这个遗留代码库加上全面的测试」这类任务，没法预先拆成固定步骤，因为你还不知道代码库长什么样。官方给的分解顺序是：

1. 先测绘结构（mapping structure）——有哪些模块、入口在哪、依赖怎么走；
2. 定位高影响区（high-impact areas）——哪些代码改动频繁、缺陷密集、被依赖最多；
3. 生成优先级计划，并随依赖发现动态调整——计划不是一次写死的，每完成一块就用新发现修正它。

考场上，这三步的反面就是干扰项：「按字母序逐文件补测试」（没有优先级）、「先写一份完整的测试计划再开工」（假装已经了解代码库）、「一次性读完整个代码库再决定」（context 会先炸，见 ch13）。

本章题组

7 题，全部对标官方样题格式：题干带生产数据，四个选项都「说得通」。做完再看解析。