跳到主要内容

Agent 与工具工程

Agent 会围绕目标反复读取环境、提出行动、获得观察并调整下一步。它适合路径无法完全预先写定的任务,例如排查未知故障、跨多份资料研究,或在仓库中根据测试结果持续修改代码。

实践质量主要取决于五件事:行动能否被校验,观察能否被追溯,状态是否由外部系统维护,权限是否足够窄,完成是否由测试或业务规则证明。模型和工具只是其中一部分。

先判断是否需要 Agent​

任务步骤固定、分支已知时,优先使用普通程序或 Workflow。它们更容易预测、测试和审计。例如每天把同一份 CSV 转成固定报表,不需要模型决定下一步。

当任务同时具备以下特征时,Agent 才开始有价值:

  • 根因、资料位置或解决路径尚不明确。
  • 下一步依赖刚刚获得的测试、搜索或工具结果。
  • 需要在多个文件或系统之间保持任务状态。
  • 结果可以通过测试、规则、来源或人工审批验证。

如果结果无法验证、行动代价很高,又缺少可靠的撤销方式,应先缩小任务范围。Agent 的自主程度不能超过系统的验证和恢复能力。

五篇分别解决什么问题​

Agent 实践不是五套互斥框架,而是五个不同层次的问题:

单步怎么决定? → ReAct
多步怎么组织? → Plan-and-Execute
一次任务怎么收敛? → Loop 工程
真实环境怎么受控运行?→ Harness 工程
跨任务怎么越做越好? → Agent 优化
↓
成熟方法再沉淀为 Skill
文章核心对象主要回答不负责
ReAct单步决策新观察出现后,下一步做什么?长期状态、权限与恢复
Plan-and-Execute任务计划多步骤、依赖和 Replan 怎么组织?执行环境的安全边界
Loop 工程单次 Run怎样反复执行、更新假设并在预算内收敛?具体沙箱和权限实现
Harness 工程模型外控制面谁能做什么,什么是权威状态,怎样验证、恢复和审计?模型应该如何推理
Agent 优化多次 Run如何根据 Eval、失败和人工反馈更新 Skill / Harness / Tool?当前任务的逐步执行

Skill 不属于另一种 Agent 架构。 它是经过多次验证后沉淀出来的可复用方法,可以被 ReAct、Plan、Loop 或 Harness 中的 Agent 按需加载。

推荐阅读路径​

第一次学习不需要五篇全部读完。按任务复杂度逐步增加:

ReAct → Plan-and-Execute → Loop → Harness → Agent 优化

这是一条学习顺序,不是强制运行时流水线。简单只读排障可能只有 ReAct;步骤明确但较长的任务可以直接使用 Plan;真实仓库执行通常需要 Harness;只有任务需要根据中间结果反复调整时才需要完整 Loop;同类任务已经有足够运行样本后,再进入 Agent 优化。

以登录回跳 Bug 为例:

  • ReAct:运行失败测试、搜索相关代码、读取回调,根据观察缩小根因。
  • Plan-and-Execute:把复现、补测试、修复、验证写成有依赖和 done_when 的计划,并允许证据变化后 Replan。
  • Loop:维护 Hypothesis、预算、停止条件和下一轮策略,直到完成或明确阻塞。
  • Harness:限制可写路径和命令,维护 Work Object、权威状态、Gate、日志和 Checkpoint。
  • Agent 优化:汇总多次真实任务的失败模式和 Eval,决定应该修改 Prompt、Skill、Tool、Harness 还是评测集。
  • Skill:当“复现 → 最小修改 → 回归测试 → 检查 Diff”已经跨多个 Bug 验证有效,再封装成可复用能力。

几篇文章沿用同一故障以减少理解成本,但教学起点不同,示例代码不应被理解为同一个仓库快照可以直接拼接。

统一五个工程概念​

本系列使用同一组术语,避免模型输出、工具结果和系统事实混在一起:

  • 行动请求:模型希望执行的工具与参数,请求本身没有授权效力。
  • 未验证观察:工具返回的原始内容,仍需校验来源、结构和时效。
  • 权威状态:宿主程序确认后的任务事实、预算、阶段和检查点。
  • 外部验证:测试、退出码、Schema、业务不变量或人工审批提供的证据。
  • 完成标准:任务开始前确定的验收条件,全部满足后才能成功。

一次运行可以生成很多合理文字,仍然可能没有完成任务。系统只根据权威状态和外部验证改变成功状态。

按问题选择入口​

第一次实践时,选择一个范围小、可回退、有现成验证方式的任务。先写目标、允许操作的资源、禁止动作和完成标准,再决定模型可以使用哪些工具。这样得到的 Agent 系统即使能力有限,也能解释自己做过什么,并在证据不足时停下来。