目录

• 一、为什么要讨论动态工作流？
• 二、固定工作流的问题
• 三、什么是 Dynamic Workflows？
• 四、Agent 如何选择最佳路径？
• 五、三种核心工作流：Direct、Plan、Research
• 六、Direct 模式：简单任务直接执行
• 七、Plan 模式：中等复杂任务先规划再执行
• 八、Research 模式：复杂开放任务先研究再行动
• 九、动态工作流和 Agent Loop 的关系
• 十、一个复杂例子：从需求到方案设计
• 十一、一个简单例子：修复错别字
• 十二、动态工作流的真正价值
• 十三、如何在自己的 Agent 中设计动态工作流？
• 十四、容易踩的坑
• 十五、总结

---

最近看 Claude Code、Codex、AI Agent 编程助手时，会发现一个越来越重要的趋势：

Agent 不应该所有任务都走同一套流程。

以前我们设计 Agent，经常会把流程写死。

比如无论用户让它修一个错别字，还是让它设计一个复杂架构，都走同样的流程：

理解任务 -> 制定计划 -> 搜索资料 -> 修改文件 -> 运行测试 -> 总结结果

这个流程看起来很完整，但实际使用时会有问题。

如果任务很简单，它会显得太慢。
如果任务很复杂，它又可能思考得不够深。
如果任务很开放，它甚至可能在没有理解清楚之前就开始动手。

所以，越来越多 Agent 系统开始强调一种能力：

根据任务复杂度，动态选择不同工作流。

这就是 Dynamic Workflows 的核心思想。

---

一、为什么要讨论动态工作流？

先想一个很简单的问题。

你让 AI 做两件事：

任务 A：把 README 里的一个错别字改掉。
任务 B：帮我设计一个支持多租户、多权限、多模型调度的 AI Agent 平台架构。

这两个任务显然不应该走同一套流程。

任务 A 很简单，Agent 最好直接做：

找到错别字 -> 修改 -> 完成

任务 B 很复杂，Agent 如果直接开始写代码，风险会很高。

它应该先做：

理解业务背景
-> 分析约束
-> 调研可选方案
-> 比较架构路线
-> 提出设计
-> 等用户确认
-> 再进入实现

这就是动态工作流的意义。

它不是为了让 Agent 看起来更高级，而是为了让 Agent 在不同任务上使用不同的工作方式。

一句话：

简单任务不要过度思考，复杂任务不要草率执行。

---

二、固定工作流的问题

固定工作流最大的问题是：它假设所有任务都一样。

但真实任务并不一样。

有些任务非常明确：

把 package.json 里的版本号从 1.0.0 改成 1.0.1。

有些任务中等复杂：

给登录页面增加记住密码功能。

有些任务高度开放：

帮我评估这个项目是否适合迁移到微服务架构。

如果所有任务都走同一套流程，就会出现三个问题。

1. 简单任务被复杂化

比如用户只是让 Agent 格式化一段代码。

固定工作流可能会这样做：

先分析需求
再读取项目结构
再制定计划
再搜索相关文件
再检查测试配置
最后才格式化代码

这就有点过了。

用户本来只想要一个快速结果，Agent 却绕了一大圈。

2. 复杂任务被简单化

反过来，如果用户让 Agent 做一个复杂架构设计，但 Agent 直接开写代码，也会出问题。

它可能没有弄清楚：

业务边界是什么
性能要求是什么
部署环境是什么
权限模型是什么
数据隔离要求是什么
后续扩展方向是什么

结果就是代码写得很快，但方向可能错了。

3. 无法适配任务复杂度

固定流程最大的问题是缺少弹性。

它不能根据任务变化调整思考深度。

真正有用的 Agent，不应该只是“执行流程”，而应该先判断：

这个任务简单吗？
是否需要计划？
是否需要调研？
是否需要用户确认？
是否可以直接执行？

这就是动态工作流要解决的问题。

---

三、什么是 Dynamic Workflows？

Dynamic Workflows，可以理解成：

Agent 根据任务的复杂度、模糊度、风险和所需工作量，自动选择合适的执行流程。

也就是说，Agent 不再固定走一条路，而是先判断任务类型，再选择路径。

一个简单抽象是：

用户任务
-> 判断任务复杂度
-> 选择工作流
-> 按工作流执行
-> 根据结果动态调整
-> 交付结果

如果任务简单：

Direct：直接执行

如果任务中等复杂：

Plan：先计划，再执行

如果任务复杂、开放、不确定：

Research：先研究，再设计，再执行

这三个模式可以看作动态工作流的基本骨架。

---

四、Agent 如何选择最佳路径？

Agent 选择工作流时，通常需要判断几个维度。

1. 任务是否明确

明确任务：

把这个函数名从 getUser 改成 getCurrentUser。

模糊任务：

帮我优化一下用户系统。

任务越模糊，越需要计划或研究。

2. 改动范围是否大

小范围任务：

改一个按钮文案。

大范围任务：

重构整个登录鉴权流程。

范围越大，越不能直接执行。

3. 风险是否高

低风险任务：

补充注释
格式化文档
修复错别字

高风险任务：

修改支付逻辑
修改权限系统
修改数据库迁移
删除历史代码

风险越高，越需要计划、验证和确认。

4. 是否需要外部信息

不需要调研：

把现有接口返回值改成驼峰命名。

需要调研：

比较 LangGraph、AutoGen 和 OpenAI Agents SDK，选一个适合当前项目的方案。

需要外部资料、方案比较、技术判断时，就更适合 Research 模式。

5. 是否存在多种可行方案

如果只有一种明显做法，可以直接做。

如果存在多种路线，就应该先分析。

比如：

我要给系统加缓存。

这可能有很多方案：

本地缓存
Redis 缓存
CDN 缓存
数据库查询缓存
应用层 memoization

这时 Agent 不应该直接选一个，而应该先比较。

---

五、三种核心工作流：Direct、Plan、Research

动态工作流可以先从三个基础模式理解：

1. Direct：直接执行
2. Plan：计划驱动
3. Research：研究驱动

它们适合不同任务。

Direct 适合简单、明确、低风险任务
Plan 适合中等复杂、有多步骤的任务
Research 适合复杂、开放、不确定的任务

可以这样记：

Direct：快
Plan：稳
Research：深

这三个模式不是互相割裂的。

复杂任务可能先走 Research，然后进入 Plan，最后局部任务用 Direct 完成。

例如：

先 Research：研究技术方案
再 Plan：制定实施步骤
再 Direct：修改具体文件

这才是真正的动态。

---

六、Direct 模式：简单任务直接执行

Direct 模式适合简单、明确、低风险的任务。

比如：

修复一个错别字
格式化一个文件
补充一个 README 示例
把按钮文案从“提交”改成“保存”
删除一个未使用 import

Direct 模式的流程很短：

理解任务 -> 执行 -> 简单检查 -> 汇报

例子：

用户：把首页按钮文案“开始使用”改成“立即体验”。

Agent 可以直接：

1. 搜索“开始使用”
2. 找到对应文件
3. 修改文案
4. 简单确认没有其他同名误改
5. 汇报完成

这种任务如果还要长篇计划，就会降低效率。

Direct 模式的原则是：

能直接做的事，不要过度设计。

但 Direct 也有边界。

如果任务看起来简单，但涉及高风险区域，比如支付、权限、生产配置，就不应该直接做。

---

七、Plan 模式：中等复杂任务先规划再执行

Plan 模式适合中等复杂度任务。

比如：

新增一个功能
修复一个跨文件 Bug
重构一个模块
为接口增加权限校验
给页面增加一个筛选条件

这类任务通常不是一步完成，需要拆解。

Plan 模式的流程大概是：

理解目标
-> 查看相关文件
-> 制定计划
-> 分步骤执行
-> 每一步验证
-> 汇报结果

例子：

用户：给用户列表页增加按角色筛选的功能。

Agent 不应该立刻乱改，而应该先计划：

1. 找到用户列表页组件
2. 查看当前筛选逻辑
3. 查看后端接口是否支持 role 参数
4. 如果支持，接入前端筛选
5. 如果不支持，补充接口参数
6. 更新测试
7. 运行验证

Plan 模式的价值是降低混乱。

它让 Agent 在执行前先建立路线图。

这对于多文件、多步骤任务尤其重要。

---

八、Research 模式：复杂开放任务先研究再行动

Research 模式适合复杂、开放、不确定的任务。

比如：

帮我设计一个 Agent 评测系统
评估当前项目是否要上微服务
比较三种向量数据库方案
设计一个多模型路由架构
调研 Claude Code 和 Codex 的工程差异

这类任务最大特点是：

没有唯一答案
需要比较方案
需要理解背景
需要权衡利弊

Research 模式一般会这样做：

理解问题
-> 收集上下文
-> 调研资料
-> 比较方案
-> 给出建议
-> 等确认
-> 再进入实现

例子：

用户：帮我设计一个 Agent Eval 系统。

Agent 应该先问或自行整理：

评测对象是什么？
是代码 Agent、客服 Agent，还是数据分析 Agent？
任务是否可自动验证？
是否需要人工评审？
有没有历史失败案例？
评测结果要用于模型选择，还是用于上线门禁？

然后再给出架构：

任务集
轨迹采集
自动评分器
LLM 评分器
人工抽检
回归测试
报告系统
持续改进流程

Research 模式的关键词是“先弄清楚”。

它不是慢，而是避免在错误方向上快速前进。

---

九、动态工作流和 Agent Loop 的关系

如果你已经了解 Agent Loop，可以这样理解：

Agent Loop 是底层循环
Dynamic Workflows 是循环策略

Agent Loop 负责：

目标 -> 计划 -> 行动 -> 观察 -> 更新 -> 验证

Dynamic Workflows 决定：

这个任务应该用多深的循环？
要不要先计划？
要不要先研究？
要不要快速执行？
要不要中途问用户？

比如 Direct 模式下，Agent Loop 很短：

目标 -> 行动 -> 观察 -> 完成

Plan 模式下，Loop 更完整：

目标 -> 计划 -> 行动 -> 观察 -> 修正 -> 验证 -> 完成

Research 模式下，Loop 更深：

目标 -> 调研 -> 分析 -> 比较 -> 方案 -> 确认 -> 执行 -> 验证

所以，动态工作流不是替代 Agent Loop，而是在 Agent Loop 之上增加了一层“任务路由”。

---

十、一个复杂例子：从需求到方案设计

假设用户说：

我想给公司内部知识库加一个 AI 问答 Agent。
要求能引用资料来源，能控制权限，回答不确定时不要胡说。
请你帮我设计方案。

这个任务显然不适合 Direct。

它也不只是普通 Plan。

它更适合 Research 模式。

第一步：理解任务

Agent 先拆解需求：

目标：设计内部知识库 AI 问答 Agent
要求：
1. 能基于内部资料回答
2. 能引用来源
3. 能控制权限
4. 不确定时要拒答或提示不确定

第二步：识别关键问题

Agent 会发现这里至少有几个核心问题：

知识库如何接入？
权限如何过滤？
检索如何做？
回答如何引用来源？
如何避免幻觉？
如何评测效果？
如何部署？

第三步：进入 Research 模式

Agent 不应该直接写代码，而应该先调研和比较：

方案 A：传统 RAG
方案 B：RAG + 权限过滤
方案 C：RAG + Agent 工具调用
方案 D：多阶段检索 + LLM rerank + 引用校验

第四步：输出方案

Agent 可以给出推荐架构：

用户问题
-> 权限识别
-> 文档检索
-> 权限过滤
-> 片段重排
-> LLM 生成答案
-> 引用来源校验
-> 不确定性判断
-> 输出答案

第五步：再进入 Plan

当用户确认方案后，Agent 再进入 Plan 模式：

1. 先实现文档索引
2. 再实现检索接口
3. 再实现权限过滤
4. 再实现问答生成
5. 最后加入引用校验和评测

第六步：局部 Direct

在具体实现时，一些小任务可以用 Direct：

新增一个配置项
改一个函数名
补一个单元测试

这就是动态工作流的真实形态：

大任务用 Research
中任务用 Plan
小任务用 Direct

它不是三选一，而是可以组合。

---

十一、一个简单例子：修复错别字

再看一个非常简单的例子。

用户说：

把文档里的 agnet 改成 agent。

这时 Agent 不需要 Research，也不需要复杂 Plan。

Direct 就够了：

1. 搜索 agnet
2. 替换为 agent
3. 确认没有遗漏
4. 汇报完成

这就是动态工作流的另一面：

简单任务就应该简单完成。

如果 Agent 对这种任务还要做大量分析，就会显得笨重。

---

十二、动态工作流的真正价值

动态工作流的价值，可以总结成五点。

1. 更智能

Agent 不再机械执行固定流程，而是会先判断任务类型。

2. 更高效

简单任务快速完成，复杂任务才投入更多思考。

3. 更可靠

复杂任务先研究和计划，减少方向性错误。

4. 更少干预

Agent 能自己判断什么时候该直接做，什么时候该深入想，什么时候该问用户。

5. 更好的用户体验

用户不会感觉 Agent 总是在“过度流程化”，也不会感觉它“太莽”。

好的 Agent 应该像一个成熟的协作者：

小事快速处理
中事先排步骤
大事先问清楚、想明白

---

十三、如何在自己的 Agent 中设计动态工作流？

如果你要自己设计一个 Agent，可以从一个简单规则开始。

1. 先判断任务类型

可以让 Agent 在执行前判断：

任务是否明确？
任务是否低风险？
是否需要多文件修改？
是否需要外部信息？
是否存在多个方案？
是否需要用户确认？

2. 设计三种模式

可以先定义：

Direct：最多 1-3 步，直接执行
Plan：先列计划，再分步执行
Research：先调研分析，再给方案

3. 设置切换条件

比如：

如果任务简单明确 -> Direct
如果任务涉及多步骤 -> Plan
如果任务开放模糊 -> Research
如果中途发现复杂度升高 -> 从 Direct 切到 Plan
如果发现缺少背景 -> 从 Plan 切到 Research

4. 设置停止条件

无论哪种模式，都要有停止条件：

任务完成
验证通过
需要用户确认
连续失败
缺少权限
缺少关键信息

5. 记录每次选择

Agent 最好能说明：

我选择 Direct，因为这是一个低风险单文件修改。
我选择 Plan，因为这个任务涉及多个文件和测试。
我选择 Research，因为这个任务有多个可行方案，需要先比较。

这样用户更容易信任它。

---

十四、容易踩的坑

1. 所有任务都 Research

这会导致 Agent 很慢。

用户只是让你改一个字，你却开始做长篇调研，这很影响体验。

2. 所有任务都 Direct

这会导致复杂任务风险很高。

架构设计、权限系统、数据迁移这类任务不能直接莽。

3. Plan 写得很漂亮，但不执行

有些 Agent 会列一个很长的计划，但真正执行时没有跟随计划。

计划必须服务执行。

4. 不会中途切换模式

一开始以为是简单任务，但执行中发现牵涉很多模块，这时就应该从 Direct 切换到 Plan。

一开始以为是普通功能，但发现有多个技术路线，这时就应该切到 Research。

5. 缺少验证

动态工作流不是只选择流程，还要验证结果。

无论 Direct、Plan 还是 Research，最后都要回答：

结果怎么证明是对的？

---

十五、总结

Dynamic Workflows 的核心思想很简单：

不同任务应该走不同流程。

简单任务：

Direct：直接执行，快速完成

中等任务：

Plan：先计划，再分步执行

复杂开放任务：

Research：先研究，再设计方案

它解决的是 Agent 的“路径选择”问题。

如果说 Agent Loop 让 AI 从“会回答”变成“会做事”，那么 Dynamic Workflows 让 AI 从“会做事”进一步变成“会选择正确方式做事”。

真正好的 Agent，不是永远深度思考，也不是永远快速执行，而是知道：

什么时候该快
什么时候该稳
什么时候该深
什么时候该问人
什么时候该停止

这就是动态工作流最重要的意义。