Agent loop 范式

阶段: B3 · agent loop + 评测统计（Day 21-30） 标签: #agent-loop #workflow-vs-agent #context-engineering #anthropic

今日导引（由浅入深）

• 能力曲线位置：B1-B2 我们打通了「会跑模型 + 会评测模型」的底座（tokenizer/cost、attention/decoder/KV 机理、judge 校准与 bootstrap CI）。从今天起 B3 把这套度量能力对准一个真正的研究对象——agent loop。
• 为什么紧接昨天：昨天（Day 20）用 bootstrap CI 给 judge 收口，确立「无 CI 不下结论」的纪律；今天承接的是「无判定边界不上 agent」的同一种克制——先判定该不该用循环，而不是上来就写循环。
• 通向明天：明天（Day 22）开始定义 agent 调用工具的契约，Day 24 真正动手写回路。今天是这条线的「前置判据」一环。
• 最小可判定产出：一张 agentEval.ts 的回路缺口图（Mermaid）+ 3 处待补点清单，不需要 API key。

1. 机理精读

定义边界：workflow 是预编排的链，agent 是自定步数的回路。

• workflow（工作流）是把任务拆成一条预先编排好的固定步骤链，每一步 LLM 只负责「填空」——抽取、改写、分类、生成。
• 步骤的数量、顺序、分支都由开发者在代码里写死，模型不决定走向。
• agent（智能体）则相反：LLM 自己站在「观测（observe）→ 决策（decide）→ 调用工具（act）→ 拿到反馈（feed back）」的回路里，自己决定下一步做什么、何时停下。
• 两者的根本区别不在「用没用 LLM」，而在「控制流由谁决定」：workflow 的控制流写在代码里，agent 的控制流写在模型的每一步推理里。

为什么这样设计：把不确定性留给真正不确定的任务。

• Anthropic《Building Effective Agents》(2024-12) 给出的核心判据是——只有当任务的步数或路径无法预先确定时，才该用 agent loop。
• 典型反例：「把这封邮件分类到 5 个标签之一」步数恒为 1，写成 agent 是纯浪费——多了不可控性、没多任何能力。
• 典型正例：AML 调查——调查员要先看到一批证据，才能决定下一步去查哪个账户、要不要调银行流水、够不够写 SAR，路径依赖于中途观测，无法事前编排。
• 这条判据把「该不该上 agent」从风格偏好变成了可判定的工程决策：先问「步数/路径是否事前可定」，可定就用链。

关键权衡：可控/便宜 vs 灵活/失控。 workflow 链可控、可测、便宜（步数确定 → token 预算确定 → 成本可预测），但表达力受限于开发者预想的分支。agent loop 灵活、能处理开放式任务，但代价有三：

1. 成本不可预测——模型可能多绕几步，token 花费上不封顶（这正是 B1 的 cost 度量在 agent 场景的延伸）。
2. 可观测性差——每一步是模型自己决定的，调试要看完整 transcript，没有 OTel/trace 几乎无法复盘。
3. 会失控——没有硬上限就可能死循环或步数膨胀。

Anthropic 的原话是「先用 workflow，能不上 agent 就不上」，本质是把灵活性的成本只花在确实需要的地方。

与相邻概念的边界：context engineering 已取代 RAG-centric 叙事。

• 2026 年的一个重要修正是：不要再把 agent 设计的核心理解成「检索 + 拼接上下文」（RAG-centric）。
• 当前主流叙事是 context engineering——agent 真正的工程难点是「在每一步给模型喂什么上下文、怎么管理工具结果在 transcript 里的累积、何时压缩/丢弃历史」。
• 检索只是其中一个数据来源而非中心；把 RAG 当 agent 设计核心，会错配整个架构的重心。

workflow vs agent 速查表：

2. 推导 / 手算 / 代码走读

今天是代码分析日。Read src/agent/eval/agentEval.ts，画出它当前的调用图并标出缺失的真正回路。关键发现（基于真实文件）：

• 核心函数是 runTaskEval(tasks, opts)（agentEval.ts:77）：它对每个 task 顺序执行三步——opts.generate(task) 拿模型输出 → task.codeCheck?.(output) 跑确定性 grader → opts.judge({task, output}) 拿 LLM-judge 裁决，然后聚合。
• 这是单轮 in/out，没有回路。 看 runTaskEval 的循环体（agentEval.ts:79-92）：generate 只接收 task，返回一段 output 字符串就结束；没有「模型请求调用工具 → 执行工具 → 把观测回填给模型 → 模型再决策」的闭环。它是「问一次、答一次、判一次」，本质是 workflow 里的「单步填空 + 评分」，不是 agent。
• judge 路径同样是单轮：makeLlmJudge（agentEval.ts:173）只把 {task, output} 拼成 prompt 让 judge 模型打一次分（pass/fail/unknown + partial score），不涉及多步。
• 三处待补点（写入缺口清单）：
  1. 无工具执行回填——GenerateFn 签名 (task) => Promise<GenerateResult>（agentEval.ts:42）只吐文本，没有 tool 调用与观测回填的位置。
  2. 无 step 状态机——没有 transcript 累积、没有「第 N 步」的概念，无法表达「先 observe 再 act」。
  3. 无终止/上限条件——既然没有多步，也就没有「最多 8 步、超了就停」的失控保护。
• 结论与去向：这三处缺口正是 Day 24 由 src/agent/loop.ts 补齐的内容（该文件已建、测试绿）。今天的产出是分析文档，把 agentEval 的「评测骨架」与 loop 的「执行回路」在概念上分开。

当前 agentEval 数据流（Mermaid 草图）：

flowchart LR
  T[task] --> G[generate task]
  G -->|output| C[codeCheck output]
  G -->|output| J[LLM-judge task,output]
  C --> A[聚合 completion/codePass/cost]
  J --> A
  A --> R[TaskEvalReport]

注意图里没有任何从 J/工具回到 G 的反向边——没有「观测 → 再决策」的自环，这就是回路缺口的可视化证据。真正的 agent 回路应在 generate 内部出现「模型 → 工具 → 观测 → 模型」的循环，而当前 generate 是一锤子买卖。

3. 今日实战

1. Read src/agent/eval/agentEval.ts，沿 runTaskEval → generate / codeCheck / judge 画出当前数据流（grader + LLM-judge 两条评分线汇入聚合）。
2. 标出回路缺口：在「generate 返回 output」与「judge 打分」之间，没有任何工具执行 / 观测回填 / 多步状态。
3. 把调用图（Mermaid）+ 3 处待补点（无工具回填 / 无 step 状态机 / 无终止上限）写入 docs/aipa/day21-agent-loop.md（交叉引用文档，非本仓代码）。
4. 在文档里明确：回路本体由 Day 24 的 src/agent/loop.ts 补齐，本日只做缺口分析，不需要 key。
5. 做一次「该不该上 agent」判定演练：对手上 3 个候选任务（如「邮件分类」「AML 调查」「固定模板报告生成」）逐一回答「步数/路径是否事前可定」，只有 AML 调查应判为 agent。
6. 记录判定理由，作为后续 B4「何时不用 agent」的对照素材。

4. 今日实测 / 产出

• 产出：提交 docs/aipa/day21-agent-loop.md + 1 张回路缺口图（Mermaid）。
• 状态：回路在 Day 24 由 src/agent/loop.ts 补齐（已建，测试绿）；本日产出为分析文档，无需 key。
• 现有 agentEval.ts 的事实：单轮 in/out（generate → codeCheck → judge → 聚合），确无工具执行回填 / step 状态机 / 终止上限——这三点即缺口清单。

5. 常见误区 / 陷阱

• 把 workflow 当 agent 卖。 步数恒定的任务（分类/抽取/单次生成）套上「agent」标签不增加能力，只增加成本与不可控性。先问「步数/路径是否事前可定」。
• 没有硬上限就放 agent 上线。 缺终止条件的回路会死循环或步数膨胀，token 成本上不封顶——这正是 Day 24 要补的 maxSteps。
• 把 RAG 当 agent 设计核心。 2026 主线是 context engineering，检索只是上下文来源之一；以「检索拼接」为中心会错配架构重心。
• 把评测骨架和执行回路搅在一起。 agentEval.ts 负责「度量」，loop.ts 负责「执行」；混在一个函数里既难测也难复用。
• 以为「上了 agent 就更智能」。 agent 只是给了模型自定控制流的权力，并不提升单步推理质量；用错地方反而放大错误（每一步的错都会传导到后续观测）。

一句话决策树：任务步数固定 → 用 workflow 链；步数/路径依赖中途观测 → 用 agent loop（且必带硬上限 + 完整 trace）。

6. 学习资源（每条带 YYYY-MM）

• Anthropic, Building Effective Agents — 2024-12（agent-vs-workflow 权威基线，本日机理主线）
• Anthropic, Effective context engineering for AI agents — 2025-09（context engineering 取代 RAG-centric 叙事）
• 本仓代码：src/agent/eval/agentEval.ts（runTaskEval / GenerateFn / makeLlmJudge）— 2026-06（当前评测骨架，回路缺口分析对象）
• 交叉引用：docs/aipa/day21-agent-loop.md（回路缺口图 + 待补点，本日产出）

SOTA检查 (2026-06 更新)

• 当前主流方案：Anthropic《Building Effective Agents》(2024-12) 仍是 agent-vs-workflow 取舍的权威基线，2026 年内未被取代，是「先 workflow、能不上 agent 就不上」的标准引用。
• 是否仍 SOTA：是。判据（步数/路径是否事前可定）在 2026 仍然成立。
• 补充主线：Anthropic《Effective context engineering for AI agents》(2025-09) 是当前对「agent 上下文管理」的主流叙事，与本判据互补——选了 agent 之后，下一个核心问题就是每步喂什么上下文。
• 需复核 / 过时告警：context engineering 已替代 RAG-centric 叙事——勿把「检索拼接」当 agent 设计核心。agent 领域半衰期 ~6 个月，平台/框架的 GA 状态须执行当周重验。
• 下次复查点：周一 WebSearch「effective agents 2026」「context engineering agent 2026」；7-28 MCP 最终规范定稿后复核工具/上下文契约措辞。

衔接

• 昨天：Day 20 — Bootstrap CI + 收口（judge 误差棒，无 CI 不下结论）
• 今天：判定「该不该上 agent」——只有步数/路径不可预先确定才用回路；分析 agentEval.ts 的回路缺口
• 明天：Day 22 — Tool 设计契约（给 agent 的「API 表面」补 JSON-Schema 与结构化错误）