Claude Code 的动态工作流：为什么 Agent 不该所有任务都走同一套流程？

目录一、为什么要讨论动态工作流二、固定工作流的问题三、什么是 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 WorkflowsDynamic 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 示例 把按钮文案从“提交”改成“保存” 删除一个未使用 importDirect 模式的流程很短理解任务 - 执行 - 简单检查 - 汇报例子用户把首页按钮文案“开始使用”改成“立即体验”。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 方案 BRAG 权限过滤 方案 CRAG 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 切到 Research4. 设置停止条件无论哪种模式都要有停止条件任务完成 验证通过 需要用户确认 连续失败 缺少权限 缺少关键信息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不是永远深度思考也不是永远快速执行而是知道什么时候该快 什么时候该稳 什么时候该深 什么时候该问人 什么时候该停止这就是动态工作流最重要的意义。