Agent 常用的三种开发思想

这篇笔记记录一下我对 Agent 开发方式的理解。

刚开始接触 Agent 时，我很容易把它想成一个很神奇的东西：

给大模型一堆工具，然后让它自己完成任务。

但真正做项目时会发现，如果只是把工具全塞给模型，然后说一句“你自己看着办”，效果经常不稳定。

后来我慢慢把 Agent 开发里的常见思路分成三类：

工作流式
计划执行式
反思迭代式

它们不是互相排斥的流派，更像三种组织智能行为的方式。

第一种：工作流式

工作流式最容易理解。

它不是让模型完全自由发挥，而是提前把步骤固定好。

例如写一篇文章：

生成大纲
  -> 搜集资料
  -> 写初稿
  -> 检查事实
  -> 润色

每一步可以调用模型，也可以调用工具。

代码上可能长这样：

outline = await generate_outline(topic)
materials = await search_materials(outline)
draft = await write_draft(outline, materials)
checked = await fact_check(draft)
final = await polish(checked)

这类方式的特点是：

• 流程清楚。
• 容易调试。
• 结果更稳定。
• 适合业务规则明确的任务。

它不像电影里的自主 Agent，更像一个由模型参与的自动化流水线。

但在实际工作里，这反而经常是最靠谱的。

工作流式适合什么场景

工作流式适合步骤比较明确的任务：

• 生成报告。
• 处理工单。
• 批量改写文案。
• 根据模板生成代码。
• 从文档中抽取结构化信息。
• 审核内容并给出分类。

例如客服工单处理：

读取工单
  -> 判断问题类型
  -> 提取关键信息
  -> 查询知识库
  -> 生成回复
  -> 交给人工确认

这里不需要模型自己发明流程。

我们真正需要的是让模型在每个明确步骤里完成语言理解和生成。

第二种：计划执行式

计划执行式更接近大家想象中的 Agent。

它先让模型根据目标制定计划，再逐步执行。

例如用户说：

帮我分析这个项目为什么启动失败，并尝试修复。

Agent 可能先生成计划：

1. 查看项目结构。
2. 查看启动脚本。
3. 安装依赖或检查依赖状态。
4. 运行启动命令。
5. 根据报错定位代码。
6. 修改并重新验证。

然后每一步根据观察结果继续调整。

这类模式常见结构是：

目标
  -> 计划
  -> 执行一步
  -> 观察结果
  -> 更新计划
  -> 继续执行

计划执行式的价值

计划执行式适合目标明确但路径不固定的任务。

例如：

• 修复 bug。
• 调研一个陌生代码库。
• 分析线上问题。
• 规划一次迁移。
• 根据用户目标操作多个系统。

这些任务不能完全写死流程。

因为下一步要做什么，往往取决于上一步看到什么。

例如运行测试后发现：

不是业务逻辑错，而是环境变量缺失。

那计划就应该调整为：

检查配置加载逻辑，而不是继续改业务代码。

计划执行式的问题

计划执行式听起来很强，但它也有风险。

模型可能：

• 制定过大的计划。
• 忘记已经做过什么。
• 执行时偏离目标。
• 工具调用太多。
• 在没有验证的情况下自信总结。

所以实际项目里，计划执行式通常需要约束：

• 每次只执行一个小步骤。
• 工具结果必须进入上下文。
• 关键操作前要做权限控制。
• 修改后要验证。
• 超出范围时要停下来。

Agent 不是越自由越好。

好的 Agent 往往是：

目标足够清楚，行动足够受控。

第三种：反思迭代式

反思迭代式关注的是质量提升。

它不是一次生成就结束，而是让模型检查自己的输出，再改进。

例如写代码：

生成实现
  -> 自查潜在问题
  -> 运行测试
  -> 根据失败修改
  -> 再次验证

或者写文章：

写初稿
  -> 检查结构是否清楚
  -> 检查有没有跳步
  -> 补充例子
  -> 润色表达

这类思想的核心是：

不要指望第一次输出就是最终答案。

反思迭代式的常见做法

常见做法有几种。

自我检查

让模型根据标准检查自己的输出。

例如：

请检查上面的实现是否有遗漏的异常处理、边界情况和测试缺口。

这种方式成本低，但模型可能看不出自己真正的问题。

外部验证

让工具给出客观反馈。

例如：

运行测试
运行 lint
编译项目
请求接口
截图检查页面

这比单纯让模型自我感觉更可靠。

多轮改进

每次根据反馈修改一点。

生成
  -> 验证
  -> 修改
  -> 再验证

这很像人类开发者的工作方式。

三种思想怎么组合

实际项目里，这三种方式经常混在一起。

例如做一个代码修复 Agent：

计划执行式：先决定排查步骤
工作流式：每次修改后固定运行测试
反思迭代式：根据测试失败继续修复

再比如做一个文档生成 Agent：

工作流式：大纲 -> 初稿 -> 润色
计划执行式：资料不足时决定继续搜索什么
反思迭代式：检查逻辑断点和表达问题

所以我现在不会把它们看成三个互斥框架。

它们更像三种积木。

怎么选择

可以按任务不确定性来判断。

如果步骤固定，优先工作流式。

如果目标明确但路径不固定，加入计划执行式。

如果输出质量需要打磨，加入反思迭代式。

简单表格：

我最后想通的地方

Agent 开发不是简单地让大模型“自主”。

更关键的是设计一套行为结构：

什么时候让模型判断
什么时候让工具验证
什么时候固定流程
什么时候允许调整计划
什么时候停下来交给人

工作流式提供稳定性。

计划执行式提供适应性。

反思迭代式提供质量提升。

真正好用的 Agent，通常不是最自由的，而是能在合适的位置自由、在关键的位置受控。