Agent：循环、工具调用与 harness
一句话定位：Agent 是让模型「自己干完一件事」的系统——模型 + 循环 + 工具 + 刹车。背景阅读：提示词工程——会把指令写清楚，才轮得到让模型自己拆任务。
答一句很惊艳，干一件事就露馅
模型能写代码、能答难题，单次问答的表现已经超过很多人。
可你让它「把这个 bug 修了」，它就开始编：看不见你的代码库、跑不了测试、答完这一句就停了。它不是不会修，是没有手、没有眼睛，也没有「接着干」的机制。
怎么让模型从「答一句」变成「干完一件事」？
给它三样东西：一个循环、一组工具、一个收尾判断——这套组合就是 Agent。
三样东西各管一件事。循环管推进：把一件超出单次回答体量的大事，切成模型每一步都够得着的小步。工具管边界：模型的知识停在训练截止日、手够不到你的真实系统，工具把这两层墙拆掉。收尾判断管质量：干没干成不由模型自己说了算，由证据说了算。后面会看到，每一样都有各自的失效方式——Agent 工程的大部分工作，就是在给它们打补丁。
图：Agent 循环——①–④ 转一圈是一步，⑤ 决定退出还是再来一圈；左下角的刹车兜住失控
渐进拆解：给顾问一间办公室
类比
单次调用像打电话问顾问——说清问题、听完答案、挂断；顾问看不到你的现场，只能凭你嘴说的给建议。
Agent 则是把顾问请进办公室：给 TA 文件柜的钥匙（工具），TA 自己翻资料、自己起草、改完自己核一遍（循环），觉得干完了才向你汇报（收尾判断）；当然也给 TA 限定工时——预算烧完就得停（刹车）。你从「问对问题」变成「授权和验收」。
例子
看一遍「修 bug」的循环怎么转（③环境执行夹在②④之间真实发生，走读时并入②的动作叙述）——
- ①思考：先看报错堆栈 → ②行动：调读文件工具，取回报错的那个文件
- ④观察：文件内容回填 → ①思考：定位到第 42 行的空指针 → ②行动：调编辑工具改掉
- ④观察：修改成功 → ①思考：得验证 → ②行动：跑测试命令
- ④观察：3 个用例失败 → ①思考：改动破坏了别处 → ②行动：再改
- ④观察：测试全绿 → ①思考：任务完成 → ⑤收尾：输出修复说明，循环退出
注意第 4 步：循环的价值恰恰在失败之后——单次调用遇到「测试挂了」就结束了，Agent 把失败变成下一步的输入。整场修复 5 圈循环、4 次工具调用，没有任何一步超出单次调用的能力半径——是循环把能力叠出了整个任务。
④观察这一环的纪律是「照实回填」：报错原文、失败用例数、文件不存在，都原样放进消息——粉饰过的观察会让下一步建立在假情报上。
大白话
Agent = 模型 + 手脚 + 刹车。模型负责想，工具负责做，循环负责把「想→做→看结果」串起来，刹车负责让它停得下来。四样缺一不可：没工具是「只会说」，没循环是「只干一步」，没刹车是「停不下来」。
这套包在模型外面的「循环 + 工具 + 刹车」运行时外壳，有一个专门的名字——harness。为什么单次调用撑不起真实任务、这层外壳还要管哪些事（上下文、工具、状态、执行环境、验证），Harness 概览整篇展开。
技术定义
Agent 是模型动态主导自身流程的系统。它与 Workflow 的分界出自业界权威口径（Anthropic《Building Effective Agents》）：Workflow 由预定义代码路径编排模型调用，路径是人写的；Agent 的路径由模型在运行时自己决定。
工程上，一次工具调用的机制是：模型输出结构化的「工具名 + 参数」→ 运行时执行 → 结果作为消息回填 → 模型继续。每轮响应带的结束原因标记（正常结束、要求调工具、达到长度上限等）是循环继续与否的机械依据——各厂商命名不同，OpenAI 叫 finish_reason，Anthropic 叫 stop_reason。
补一层训练视角：「会调工具」不是提示词教的临场发挥，是后训练用几千条调用示例教会的行为——模型发出特殊的调用标记，运行程序看到后暂停采样、执行工具、把结果回填进上下文再继续生成。这条「发标记 → 暂停 → 回填」的链路与联网搜索、代码解释器共用同一套机制（成因与演示见LLM 心理学）。
一轮轮累积下来，模型看到的消息序列长这样：
[系统] 你是运维助手，只读操作。
[用户] 服务响应变慢了，查一下原因。
[助手] → 调用工具 grep("timeout", "logs/app.log")
[工具] 行 42: upstream timeout=30s, retry=3
[助手] → 调用工具 run("tail -100 logs/app.log")
[工具] （最近 100 行日志原文）
[助手] 原因是上游服务超时……（结束原因 = 正常结束，循环退出）每一条「工具」消息都是真实执行的原文回填——模型下一波的判断，完全建立在这份记录的忠实度上。
让模型「决定下一步」的推理组织方式，常见的有四种模式：
| 模式 | 怎么干 | 适合 | 判断依据 |
|---|---|---|---|
| 思维链（CoT） | 单次调用内分步想，不动工具 | 纯推理题（数学、逻辑） | 不需要外部信息 |
| ReAct | 想一步、做一步、看一眼再想 | 开放探索（调试未知 bug、现场调研） | 步骤依赖事先无法预知 |
| 先计划再执行（Plan-and-Execute） | 先出完整计划，再逐项执行 | 可预先列全的长任务（数据迁移、发版流程） | 要全局观、控成本 |
| 反思（Reflection） | 生成后自我批评、再修一版 | 质量优先、延迟不敏感（文章定稿、代码评审） | 有明确的验收标准 |
ReAct 是这一族里最常被拿来当起点的：2022 年的研究显示，让推理与行动交错进行，在 ALFWorld、WebShop 两个交互式任务基准上，绝对成功率分别比最强基线高 34 和 10 个百分点，且推理轨迹让每一步可解释、可检查。四种模式各有代价：ReAct 缺全局观、容易在局部打转；先计划再执行对中途意外脆弱，计划赶不上变化时得配上重新规划的机制。
选型不用背表格，按四个问题依次自问即可：
图：选型决策树——从问一走到问四，答「是」即停；四种模式也能叠加使用
值得强调的是最后一句：模式不是互斥选项。真实的长任务往往「先计划搭骨架、ReAct 跑每一步、反思做收尾」——决策树选的是主导模式，不是唯一模式。
动手：十来行的最小 Agent
伪代码（不可直接运行），重点看三道刹车：
def agent(task, max_steps=25):
messages = [system(ROLE_PROMPT), user(task)] # system=常驻身份设定
for _ in range(max_steps): # 刹车一：步数上限
resp = model.chat(messages, tools=TOOLS)
if resp.stop == "end_turn": # ⑤ 收尾：模型自报完成
ok, report = verify(resp.text) # 刹车二：完成要验证，不听自述
if ok:
return report # 验证过才真收工
messages.append(user(report)) # 不过 → 带着问题继续循环
continue # 回到循环顶部重新思考
result = run_tool(resp.tool_call) # ③ 环境执行 ② 的调用
messages += [resp, tool_msg(result)] # ④ 观察回填，回到 ①
raise DeadLoop("步数耗尽") # 刹车一的兜底出口：转人工十个语句左右，四个要素齐了：循环是 for，工具是 TOOLS 与 run_tool，收尾判断是 stop 检查加验证，刹车是上限、验证与兜底。主流 Agent 框架，剥掉封装后都是这个循环的变体——理解了它，框架对你就不再是黑盒。
边界与取舍：Agent 不是默认选项
路径可预测就不要 Agent
每天定时抓数据、按模板拼报告——步骤固定的活用 Workflow（写死的代码路径）更可靠、更便宜、可测试。业界的建议是把最简单的方案当默认：单次调用加检索够用就别上 Agent，路径可预测用 Workflow，只有需要模型自己拿主意时才升级。形态选择的完整谱系（纯脚本 / Workflow / Agent）在Harness 概览里展开。
死循环防护按三道刹车设计
刹车一是硬上限（步数、时长、token 预算——token 是模型计费与计长度的最小文字单元，一句中文约几十个），到线就停；刹车二是完成验证——模型自述「完成」不采信，用证据说话（测试通过、文件存在、字段齐全）；刹车三是异常检测——连续多步高度相似（同一工具同参数反复调用）、或长时间无实质进展，说明模型卡住了，主动中断转人工。三道刹车的工程化（状态机、Checkpoint、断点续跑）在状态机与 Checkpoint专篇展开。
循环有隐性成本：上下文
每转一圈，消息历史就长一截——工具返回的大段输出原样堆积，几十圈后上下文窗口见顶，模型会「忘了」最初的目标、开始重复劳动。所以循环设计从第一天起就要回答：喂什么、留什么、扔什么。这套方法自成一篇，见Context 工程。
工具给得越多，Agent 越迷糊
工具一多，模型挑花眼的概率明显变大——最小工具集起步，缺了再补。工具治理（注册、权限、懒加载）在工具执行专篇展开。
自测
合上文章先自己答，再展开对照：
ReAct 与 Plan-and-Execute 各适合什么任务？判断依据是什么？
判断依据是「步骤间的依赖是否可预知」。ReAct 边想边做、每一步取决于上一步的观察——适合开放探索类任务：调试一个不知道原因的 bug、调研一个不熟悉的领域，下一步做什么只有看了这步结果才知道，预先列计划没有意义。Plan-and-Execute 先产出完整计划再逐项执行——适合步骤可预先列全的长任务：数据迁移、多环境部署，全局计划带来可控的 token 开销和可审查的路线。代价互换：ReAct 缺全局观、容易在局部打转；Plan-and-Execute 对中途意外脆弱，计划赶不上变化时需要重规划机制。
终止条件和死循环防护一般怎么设计？
三道刹车。其一，硬上限：最大步数、时间预算、token 预算，到线强制停止——这是兜底，防一切意外的意外。其二，完成验证：模型的「正常结束」信号只是自述，要靠证据验收（测试通过、产物存在、字段齐全），防止「假装完成」。其三，异常检测：连续多步高度相似（同工具同参数反复调）、长时间无进展，主动中断转人工。设计原则：上限防失控、验证防自欺、异常检测防卡死，三者叠加而不是三选一。
参考与延伸
- 视频版：动画拆解（约 4 分半）——本篇的交互式演示版，逐节拍推进、可点击回看，支持竖屏模式。
- Anthropic《Building Effective Agents》（2024-12）：Workflow 与 Agent 的权威分界，「从最简方案起步」的模式观 — anthropic.com/engineering/building-effective-agents
- 《ReAct: Synergizing Reasoning and Acting in Language Models》（2022-10，ICLR 2023）：推理与行动交错范式的原始论文 — arxiv.org/abs/2210.03629
- Anthropic《Effective Context Engineering for AI Agents》（2025-09-29）：循环里「喂什么」的系统方法 — anthropic.com/engineering/effective-context-engineering-for-ai-agents
下一站：Context 工程——循环每转一圈都在消耗上下文，喂什么、留什么、扔什么，决定 Agent 能走多远。