本文深入解析了 Agent 的编排机制涵盖 ReAct 动态决策循环、Plan-and-Execute 计划执行机制以及 Workflow Graph 流转规则。通过实例详解了不同编排方式的选择依据及实际应用场景帮助读者理解 Agent 如何在状态保存的基础上自主决策。内容实用适合想要学习大模型编程的小白程序员收藏学习。状态、编排与行动的关系假设一个 Agent 正在执行代码发布任务当前状态记录了这些信息当前目标发布到测试环境 当前阶段运行测试 构建结果成功 测试结果失败 最近错误数据库连接超时这份状态可以告诉系统任务停在测试阶段构建已经完成但测试还没有通过。至于下一步是重试测试、进入问题诊断、终止发布还是请求人工处理需要系统结合当前状态、执行结果和状态转移规则进行判断。测试失败 ↓ 判断失败原因 ├─ 可重试 → 重新测试 ├─ 需要排查 → 进入问题诊断 ├─ 无法继续 → 终止发布 └─ 需要决策 → 请求人工处理负责组织这些执行路径的就是 Agent 的编排逻辑。编排会读取当前状态再根据任务规则选择下一条合法路径。如果需要调用工具它会把任务交给对应的执行节点如果遇到高风险操作它会暂停任务并等待用户确认如果任务已经达到结束条件它会终止执行循环。可以把三者的关系简单理解为状态记录任务现在在哪里编排判断接下来允许往哪里走工具把判断变成真实行动。图 1. 从状态到行动。状态保存任务位置和执行结果编排读取状态并应用规则行动层调用工具、进入节点或请求人工确认。前五期提到的上下文、Prompt、工具和状态也会在这套编排过程中重新组合起来。每次行动前系统根据当前状态组织上下文和动态 Prompt模型读取信息后提出工具调用Harness 校验并执行工具工具结果写回状态编排逻辑再根据新的状态决定任务如何继续。ReAct 的动态决策循环其实在第一期内容中我们聊过 ReAct。它把判断、行动和观察放进一个循环模型先根据已有信息选择行动再根据环境返回的新结果决定下一步。模型选择下一步行动 ↓ Harness 校验并执行工具 ↓ 环境返回新的结果 ↓ 模型再次判断以测试失败为例Agent 一开始可能只知道数据库连接超时。它还不知道问题出在数据库服务、网络配置、环境变量还是测试代码本身。这时候很难提前写出一条完整的排查路径。Agent 可以先读取测试日志再根据日志选择下一项检查。它可能先调用 Shell 工具查看数据库容器docker ps如果发现容器没有启动它会继续读取 docker-compose.yml如果容器已经正常运行它可能转去检查端口、数据库地址或者测试环境变量。前一次工具调用产生的结果会直接改变下一次行动。代码排错、开放式资料搜索、陌生代码库探索和复杂环境诊断都有类似特点问题路径无法提前确定需要持续读取外部信息中间结果还会不断改变后续方向。这类任务就适合使用 ReAct。不过ReAct 循环不代表模型想做什么就做什么。Harness 仍然要负责工具权限、参数校验、最大执行轮次、超时和停止条件。模型负责提出行动系统负责判断这个行动是否允许执行。ReAct 擅长处理的是“不知道下一步会遇到什么”的任务。Agent 自主决策的工程边界一次完整的版本发布不只有未知问题需要探索还包含很多已经明确、不能跳过的流程。假设我们把整条发布流程都交给 Agent 临场决定。Agent 构建完项目后可能认为这次修改范围很小只运行了部分测试测试失败以后它一边修改代码一边重试逐渐把发布任务做成了代码重构它也可能记得运行测试却忘记执行安全扫描。更危险的情况是Agent 看到测试通过直接调用部署工具没有等待人工确认。部署结束后它生成了一份完整的发布报告却没有真正检查服务是否正常启动。模型可能知道测试、安全扫描和人工确认都很重要但“模型知道应该执行”与“系统保证一定执行”之间仍然隔着一道工程边界。如果每一步都由模型临场决定执行路径可能偏离原始目标关键步骤也可能被遗漏。同样的任务每次走不同路径还会增加测试、复现和审计的难度。因此需要探索的步骤可以交给 Agent但必须执行的步骤要写进系统规则。Plan-and-Execute 的计划执行机制如果一个任务的目标已经明确也能拆成若干子任务但在执行过程中还可能遇到变化可以采用 Plan-and-Execute。它会先生成一份计划再按照子任务之间的依赖关系逐步执行。生成计划 ↓ 按依赖顺序执行 ↓ 更新任务状态 ↓ 遇到异常时修改计划对于发布任务Agent 会先列出1. **检查当前分支和代码变更** 2. **构建项目** 3. **运行单元测试和集成测试** 4. **执行安全扫描** 5. **生成发布说明** 6. **请求用户确认** 7. **部署到测试环境** 8. **验证服务状态**真正交给系统执行的计划通常会比自然语言列表更结构化。每个步骤可以带上任务 ID、依赖项、完成条件和当前状态{ id: run_tests, task: 运行测试套件, dependencies: [ build_project ], success_criteria: 所有必要测试通过, status: pending }有了这些字段Harness 可以知道 run_tests 必须等待 build_project 完成也能根据测试结果判断这个步骤是否真正结束。规划阶段负责拆分任务和建立依赖关系。执行阶段负责调用工具并将结果写回状态。如果某个步骤失败系统再根据最新状态修改后续计划。原计划可能是测试 → 安全扫描 → 生成发布说明测试失败后计划被修改成测试失败 → 诊断数据库连接 → 修复配置 → 重新构建 → 重新测试 → 安全扫描这份计划要跟着任务状态一起更新。如果 Agent 已经确认问题来自测试数据库配置后续就不用重新检查所有依赖如果修复过程中修改了代码和配置原来的构建结果也要标记为失效。Plan-and-Execute 适合目标明确、可以拆成多个子任务、子任务之间存在依赖同时允许执行路径根据结果适度调整的任务。研究报告、复杂代码修改、跨多个系统的数据整理等任务都可以先列计划再执行。不过初始计划可能建立在错误假设上。环境变化越频繁计划过期得越快。如果系统每走一步都重新生成完整计划模型调用成本也会继续增加。计划中出现“部署”或“删除文件”这样的步骤也不代表 Agent 自动获得了对应权限。Harness 仍然要在执行前检查工具权限和人工审批条件。Plan-and-Execute 提供的是一份可以调整的任务结构它让 Agent 少一点走一步看一步多一点先想清楚再行动。Workflow Graph 的流转规则还有一类任务执行路径已经比较稳定。以一个简化的发布流程为例构建成功后才能运行测试测试通过后才能执行安全扫描获得人工确认后才能部署。部署完成以后还要运行健康检查检查失败则进入回滚或人工处理。实际节点和顺序取决于团队的发布策略。安全扫描可以和测试并行低风险测试环境也不一定需要人工审批。这里使用简化流程说明编排关系。这类流程可以固化成 Workflow Graph构建 ↓ 测试 ├─ 失败 → 终止当前发布 → 进入诊断流程 └─ 通过 ↓ 安全扫描 ↓ 人工审批 ↓ 部署 ↓ 健康检查 ├─ 通过 → 完成 └─ 失败 → 回滚在 Workflow Graph 中节点代表一个执行阶段边也就是连接节点的有向箭头代表节点之间允许发生的流转条件决定任务可以进入哪条分支。节点不一定都由模型执行“构建项目”可以是 Shell 命令节点“运行测试”可以是 CI 服务节点“安全扫描”可以调用固定扫描工具“人工审批”需要等待用户输入“失败诊断”则可以交给 Agent。Workflow Graph 不一定是 DAG——有向无环图指节点之间存在明确的流转方向但不会形成可以回到原节点的循环。如果任务只需按照依赖关系单向推进不需要返回之前的节点就可以使用 DAG。当发布任务中存在“测试失败—修复—重新构建—重新测试”的回路这种结构就已不是 DAG更接近带循环的 Workflow Graph 或显式状态机。状态机可以把任务划分成BUILDING TESTING DIAGNOSING WAITING_FOR_HUMAN DEPLOYING VERIFYING DONE FAILED每个状态都有明确的进入条件和退出条件。测试没有通过就不能从 TESTING 进入 DEPLOYING用户没有确认任务就只能停在 WAITING_FOR_HUMAN。模型在某个节点内部依然可以自主行动但它只能沿系统允许的路径交还控制权。Workflow Graph 把测试、审批以及失败后的回滚路径从模型判断变成了系统规则。这些规则不能只画在图中Harness 还要执行工具白名单、权限检查、状态转移校验和审批条件。如果诊断 Agent 没有获得部署工具它就无法在排查过程中绕过发布主干当前状态不满足进入条件路由器也不能把任务直接送进部署节点。因此路径稳定、规则明确、存在必经步骤、需要测试与审计的任务更适合固化成 Workflow Graph。三种编排方式的选择依据ReAct、Plan-and-Execute 和 Workflow Graph 不是三种能力等级。区别在于执行路径由谁产生又在什么时候确定。图 2. 三种编排模式对比。ReAct 的路径在运行过程中逐步生成Plan-and-Execute 在任务开始时生成计划并允许根据执行结果修订Workflow Graph 由开发者预先定义合法节点和流转范围。选择时可以先看任务路径的确定程度路径无法提前判断需要持续读取环境反馈使用 ReAct目标明确、任务可以拆解但具体步骤会随结果调整使用 Plan-and-Execute路径稳定、规则明确还有不能跳过的节点使用 Workflow Graph。风险和结果验证方式也会影响自主度。删除数据、发送消息、支付、部署等操作需要权限限制或人工确认测试退出码、JSON Schema、安全扫描结果和服务健康状态可以由程序判断更适合写进固定流程。开放式分析、故障归因和方案选择则可以给模型保留更多决策空间。实际系统也可以把模型生成的计划转换成临时任务图或者在 Workflow Graph 的某个节点中动态生成子计划。Plan-and-Execute 负责规划Workflow Graph 负责控制流两者可以组合使用。固定主干与局部自主实际系统很少只使用一种编排模式。代码发布可以用 Workflow Graph 控制主干把失败后的修复交给 Plan-and-Execute再让 ReAct 处理无法提前确定的诊断步骤。Workflow Graph 控制发布主干 构建 → 测试 → 安全扫描 → 人工审批 → 部署 → 健康检查 → 完成或回滚测试通过任务沿固定路径继续测试失败当前发布停止。系统保存失败日志和任务状态再创建诊断与修复子任务。Plan-and-Execute 可以把修复任务拆成1. **分析失败日志** 2. **定位相关代码和配置** 3. **验证失败原因** 4. **修改代码或配置** 5. **检查修改范围并进行代码审查或变更确认** 6. **重新运行相关测试** 7. **输出修改结果**其中“定位相关代码和配置”很难提前写死。Agent 可以在这个子任务中使用 ReAct读取日志、搜索代码、运行命令再根据返回结果调整排查方向。Agent 修改代码以后发布对象已经变化修改前的构建、测试和扫描结果不能继续沿用。系统需要检查修改范围按团队策略完成代码审查或变更确认再重新构建并进入发布主干。图 3. 混合编排的代码发布流程。Workflow Graph 控制构建、测试、安全扫描、人工审批、部署、健康检查和回滚测试失败后进入 Plan-and-Execute 修复子流程具体故障诊断节点内部运行 ReAct代码发生修改后先进行代码审查或变更确认再重新构建并从测试阶段重新进入发布主干。整套系统可以分成三层Workflow Graph 控制任务主干和安全边界 ↓ Plan-and-Execute 组织复杂的诊断修复子任务 ↓ ReAct 处理子任务内部无法预先确定的步骤Workflow Graph 守住确定性Agent 处理不确定性。任务可以根据现场情况调整也不会因为一次临场判断跳过关键环节。自主节点的控制权交还Agent 完成自主任务后Workflow Graph 还要判断任务能否继续。比较稳妥的方式是给自主节点定义明确的输入输出契约。调用诊断 Agent 时系统传入任务目标、可用工具、行为约束和完成条件{ goal: 定位并修复测试失败, allowed_tools: [read_file, search_code, write_file, run_tests], constraints: [不得提交代码, 不得部署], success_criteria: 必要测试通过 }allowed_tools 需要由 Harness 真正执行不能只写进 Prompt。Agent 可以生成任务总结和修改结果测试记录、退出码和工作区快照等验证证据则由 Harness 或工具运行层附加{ status: resolved, changed_files: [config/test-db.js], test_run_id: test-run-204, exit_code: 0, workspace_snapshot_id: snapshot-018, suggested_route: rerun_tests }Harness 检查输出 Schema、测试记录、工作区快照和文件修改范围再由 Workflow Graph 选择合法节点。即使 Agent 建议 rerun_tests系统发现代码已经修改也可以先把任务送回构建节点。Agent 可以建议往哪里走系统负责判断这条路是否合法。如果 Agent 执行超时、达到最大轮次或者返回结果无法验证Workflow Graph 可以进入失败节点或人工处理节点。任务状态和中间产物继续保留后续可以重试或从检查点恢复。这样自主节点保留完成局部任务所需的灵活性也不会打散整个系统的控制边界。结语综上Agent 能自主决定下一步不代表整条任务链都要交给模型。路径未知时使用 ReAct任务可拆解但步骤会变化时使用 Plan-and-Execute流程稳定且存在必经节点时使用 Workflow Graph。真实系统通常由 Workflow Graph 控制主干Plan-and-Execute 组织复杂子任务ReAct 处理局部未知问题。需要探索的地方交给 Agent必须保证的地方交给系统。最后当下AI大模型是当下实打实的优质风口岗位缺口大、发展前景广、薪资待遇突出对比内卷严重、涨薪晋升困难的传统技术岗是普通人转行逆袭的绝佳选择。但很多想要入局大模型领域的朋友都面临无系统学习路径、无实战资源、求职无方向的难题一个人硬啃最容易走弯路、浪费大量时间精力。这里我结合多年一线实战与教学经验整理出一套零基础大模型专属资料包含系统化学习路线图零基础到精通大模型学习书籍 文档电子版2026 最新行业报告项目实战 配套源码大厂面试真题需要的朋友微信扫描下方 CSDN 官方认证二维码免费领取保证 100% 免费。扫码免费领取全部内容下面简单介绍一下资料包含的内容1、大模型系统化学习路线图专属定制从零基础入门到企业级实战的全阶段学习体系划分清晰的四大学习阶段规避碎片化学习弊端适配新手2、0基础到进阶视频教程配套完整高清实操教程覆盖Prompt提示工程、RAG知识库搭建、Agent智能体开发、模型微调、部署落地等核心知识点所有课程搭配实操演示零基础也能轻松看懂、上手实操。3、大模型学习书籍 文档汇总30本行业经典AI、大模型、深度学习精选书籍涵盖理论原理、开发实战、算法基础、AI产品思维等各类内容4、AI大模型最新行业报告整理2024-2026年最新大模型行业白皮书、市场分析报告清晰展现行业发展趋势、技术迭代方向、岗位需求变化帮助学习者精准把握行业风口找准学习和就业方向5、大厂面试真题汇总了常见的AI大模型面试问题、知识点梳理和面经参考方便求职时针对性准备。6、大模型项目实战 配套源码包含GPT应用开发、RAG私有知识库、智能问答系统等多个企业级实战项目配套完整可运行源码从简易Demo到完整商业应用全覆盖帮助学习者将理论转化为落地实战能力积累项目经验。7、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。8、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料