一、一轮工作的七个站位

• 接收消息——会话层。
• 组装请求——历史＋工具表＋提示段。
• 调用模型——llm。
• 解析回复——agent-loop。
• 要动手？——走统一管线（4.4 六道关）。
• 结果回炉——再次组装、再次调模型。
• 无需再动手——输出最终回复。

每个站位都有名字、有归属——黑盒从打开的这一刻起就不黑了。

二、实测：循环本身也是插件

配置里有 agent-loop 和 agent 两个包。

连【怎么循环】都是可替换的能力——这在一套【皆插件】的系统里是理所当然，在别的框架里往往是写死的。

顺带一提：界面侧还有 client-ui-settings-agent-loop——循环行为甚至有设置面板。

三、打开盒子改不改变行为

不改变。拆解的价值不在【知道有哪些步骤】，在于：

• 排查有落点：卡在哪一站，就去查哪一站的账。
• 优化有对象：慢在组装还是模型，数字会说话。
• 理解有结构：后面每节都是把某一个站位放大看。

四、这一章的地图

• 6.2 拆【循环了几次】——Turn 与 Step。
• 6.3 拆【动手那一步】——统一管线。
• 6.4~6.7 拆【看见了什么】——Session 与可追溯。
• 6.8 拆【怎么复盘】——重建、回放、调试。

站位清楚了，地图才好走。

五、动手 Demo：一轮工作从进站到出站

七个站位一张表：

stops = ["接收消息", "组装请求", "调用模型", "解析回复",
         "要动手?", "结果回炉", "输出回复"]
for i, s in enumerate(stops, 1):
    print("  站位 %d: %s" % (i, s))
print()
print("  实测: agent-loop 本身也是插件, 不是写死的内核")

实跑输出：

--------------------------------------------------------------------
一轮工作从进站到出站
--------------------------------------------------------------------
  把【一条消息进来】到【一条回复出去】中间的站位摆出来：

  站位           谁在干活
  --------------------------------------------------
  接收消息       会话层
  组装请求       上下文装配（历史＋工具表＋提示段）
  调用模型       llm
  解析回复       agent-loop
  要动手？       走统一管线（4.4 的六道关）
  结果回炉       再次组装、再次调模型
  无需再动手     输出最终回复
  --------------------------------------------------

  实测：配置里有 `agent-loop` 和 `agent` 两个包——
  **连【循环本身】都是一个插件**，不是写死在内核里的。

每个站位都有归属——排查时按站查账，不猜。 agent-loop 是插件这件事，再次印证 3.7 的【连管理器都是插件】。 后面每节就是把某一个站位放大看——地图先立起来。

30 秒实验

1. 把七个站位默写一遍，标出哪几站会调模型。
2. 在配置树里找到 agent-loop 包，确认它是个插件。
3. 想想你最熟悉的框架里，循环是写死的还是可替换的？

常见误区

1. 错误：Agent 就是一次 API 调用。——纠正：一次 API 调用是一个 Step；一轮工作通常有多个 Step。
2. 错误：循环逻辑写死在框架内核里。——纠正：实测 agent-loop 是插件——可替换、可配置。
3. 错误：拆站位是理论活，没用。——纠正：排查按站查账——这是后面 6.8.3 调试三步的地基。

• ☐ 下一节（6.2 Turn 与 Step：一轮工作可以包含多次模型推进）

相关笔记

• Tool Execution Pipeline：一次工具调用究竟要经历哪些阶段 —— 站位【要动手】的细节
• 本章小结 —— 那时候的实物数据，这里派上用场
• Agent 的核心能力 —— 【能推进】正是核心能力之一
• 🐳 DeepSeek Harness · 索引