很多 Agent 原型跑得很顺，一进真实业务长链路就开始失控。它能查一个订单，也能调用一个工具，但一旦任务变成“先判断客户等级，再查合同，再核对 SLA，再生成补偿方案，再发起审批”，简单的边想边做就会暴露短板。
ReAct 的价值，是把推理和行动接成一个循环。模型先想一步，再调用工具，再根据观察结果继续下一步。这种结构适合短任务和探索型问答，但复杂任务需要更早看到全局依赖、候选路径、失败回退和人工检查点。
Plan-and-Solve、Tree of Thoughts 和 Graph of Thoughts 真正带来的变化，是让 Agent 从局部反应式执行，升级成带规划层、搜索层和状态机的执行系统。
复杂 Agent 的核心升级，是把“下一步做什么”提前拆成“任务依赖图怎么建、候选路径怎么选、执行状态怎么收口”。
一、ReAct 的边界出现在长链路任务里
ReAct 指的是 reasoning and acting，也就是让模型在每轮里先推理，再行动，再读取工具返回的观察结果。它把大模型从纯文本回答拉进了外部世界，搜索、查库、调用 API、读文件都可以进入同一个循环。
这个循环很适合局部不确定的任务。比如查一条知识、补一段代码、读取一个页面、对一个订单做单点判断，模型可以边看边改，直到拿到答案。
长链路任务的压力来自另一类问题。任务之间有前后依赖，有些分支可以并行，有些动作必须等人工审批，有些路径失败后需要补偿。此时只让模型在当前观察结果上决定下一步，很容易把全局问题压成局部贪心。
ReAct 在复杂任务中的 4 个常见失效信号
任务越做越散，模型不断补新步骤，但看不到完整依赖关系。
工具调用顺序受最近一次观察影响，容易错过更优路径或并行机会。
中途失败后只能继续试探，很难知道应当重试、回滚、换路，还是升级给人工。
过程记录像一串对话日志，无法稳定恢复成可审计的业务状态。
因此，复杂任务的第一步，是先把任务从“一串动作”提升成“一张图”。这就是 Plan-and-Solve 可以落地的地方。
二、Plan-and-Solve 先把任务拆成依赖图
Plan-and-Solve 的核心思路，是先规划，再求解。模型不急着执行第一步，而是先把问题拆成若干子问题，明确每个子问题要产出什么，再按计划逐步完成。
落到工程里，这个计划不应该只是自然语言清单。它更适合被整理成任务依赖图。每个节点都有任务编号、输入、预期输出、依赖节点、可用工具、验收标准和失败处理。这样后面的执行器才知道哪些节点可以并行，哪些节点必须等待上游结果。
一个投诉处理 Agent 的任务依赖图
先规划成依赖图，再进入执行接收投诉与识别目标查询客户等级CRM / 会员系统核对合同 SLA合同库 / 条款抽取拉取故障证据工单 / 日志 / 监控生成补偿方案候选依赖客户等级、SLA 与故障证据提交审批或升级人工
这张图表达的重点，是计划层先决定哪些信息必须拿到，哪些任务可以并行，哪些输出会共同约束最终方案。
图建出来之后，执行器拿到的是一组可调度、可恢复、可验收的节点，而不是一句无法直接落地的“处理投诉”。
Plan-and-Solve 解决的是结构问题。它让 Agent 先拥有任务地图。但地图只有一张时，系统仍然可能走进次优路线。复杂场景还需要比较多条路径，这就进入 ToT 和 GoT 的位置。
三、ToT 和 GoT 把计划变成可搜索的候选空间
Tree of Thoughts，也就是思维树，把中间推理结果当成可展开、可评分、可回溯的状态。模型不再只生成一条推理链，而是在关键节点生成多个候选想法，再用评分器挑出更值得继续展开的分支。
Graph of Thoughts 进一步放宽结构。候选想法可以合并、改写、聚合和循环改进。对于企业任务，这一点很重要。合同条款、故障证据和客户价值会反复互相修正，很多场景天然更接近图结构。
工程落地时，ToT 和 GoT 可以被理解为三件事：候选路径生成、路径评分、预算内剪枝。系统允许模型提出多种处理方案，但每一种方案都必须带着成本、风险、证据完整度和可执行性进入评分。
| 模式 | 适合解决的问题 | 工程形态 |
|---|---|---|
| ReAct | 短链路、强交互、工具结果会快速改变下一步 | 思考、行动、观察循环 |
| Plan-and-Solve | 多步骤任务、依赖清晰、需要先看全局 | 任务依赖图、节点验收、并行调度 |
| ToT / GoT | 存在多条候选路径，需要比较、剪枝和回溯 | 候选路径搜索、评分器、预算控制、状态合并 |
这一层最容易写得很玄。真正能落地的关键，是把“想法”降成结构化候选项。每个候选项都要说明它依赖哪些证据、会调用哪些工具、预计成本是多少、失败后如何退出。
四、状态机是规划和搜索的落地点
规划层生成的是任务图，搜索层生成的是候选路径，真正承接执行的是状态机。没有状态机，计划只会停留在模型上下文里。一旦进程重启、工具超时、审批暂停，系统就很难恢复到正确位置。
复杂 Agent 的状态机至少要记录三类状态。第一类是任务节点状态，例如已计划、待运行、运行中、被阻塞、待审批、已完成、已失败。第二类是证据状态，例如数据已读取、证据不足、证据冲突、需要补充检索。第三类是治理状态，例如需要人工确认、已授权、已拒绝、已补偿。
复杂任务状态机的最小字段
node_id：当前子任务节点，便于恢复、重试和审计。
dependencies：上游依赖和可并行节点，决定调度顺序。
evidence：已获得证据和证据来源，决定下一步是否可信。
candidate_paths：ToT 或 GoT 生成的候选路径及评分。
approval_state：人工中断、批准、拒绝和修改意见。
checkpoint：可恢复快照，支撑长任务断点续跑。
LangGraph 这类状态图框架的价值，就在于把节点、边、检查点和人工中断变成运行时能力。AutoGen 的 GraphFlow 也在强调用图来表达多智能体流程。它们共同指向一个工程事实：复杂 Agent 需要被状态图管理，对话历史只适合保留上下文，不适合承担生产调度职责。
五、评分器决定搜索会不会变成烧钱试错
ToT 和 GoT 一旦进入生产系统，第一道边界就是成本。每个候选分支都可能触发模型调用、工具调用、数据库查询、沙箱执行和人工审批。搜索空间如果不收口，很快会把质量提升变成延迟和费用问题。
评分器要回答的问题，比“哪个答案看起来更好”更具体。它应该同时评估证据完整度、业务风险、工具成本、可回滚性、用户体验和成功概率。低风险读操作可以多探索几步，高风险写操作必须更早进入审批或停止。
生产可用评分器的 5 个维度
证据分：关键输入是否来自可信系统，是否存在冲突证据。
风险分：是否涉及金额、权限、合同、客户通知和不可逆副作用。
成本分：模型调用次数、工具调用次数、预计耗时和人工等待成本。
可恢复分：失败后能否重试、补偿、回滚或保留草稿。
完成分：方案是否满足用户目标和业务验收标准。
评分器的输出应当进入状态机，而不是只停在模型回复里。系统需要知道为什么保留 A 路径、剪掉 B 路径、升级 C 路径。这样后续审计、调参和复盘才有证据。
六、综合图：复杂任务 Agent 的四层执行架构
把前面的层次合在一起，复杂任务 Agent 可以拆成四层：规划层先生成依赖图，搜索层比较候选路径，状态机层承接执行与恢复，治理层控制风险与审计。
点击图片可放大查看高清架构。
复杂任务 Agent 的四层执行架构用户目标与业务约束目标、权限、时间、成本、风险等级规划层Plan-and-Solve 生成子任务依赖图节点、输入、输出、依赖、验收标准搜索层ToT / GoT 生成、评分、剪枝候选路径保留最值得继续执行的方案状态机层ready / running / blockedreviewing / done / failedcheckpoint 支撑断点续跑治理层审批、预算、权限、补偿trace_id、审计日志、人工接管控制自动化边界工具层与业务系统：搜索、数据库、CRM、ERP、工单、审批流
这张图里的关键关系，是规划层和搜索层都不直接落到业务系统。它们先把决策压成可执行状态，再由状态机决定何时调工具、何时暂停、何时恢复、何时让人接管。
治理层也不是最后补上的日志。它从一开始就参与预算、权限和风险控制。低风险节点可以自动跑，高风险节点必须等待审批，搜索分支超过预算就要剪掉。这样复杂 Agent 才能既聪明，又可控。
七、落地顺序从一条可恢复链路开始
团队不需要一开始就实现完整 GoT。更稳的路径，是先选一条真实业务链路，把 ReAct 执行过程改造成可恢复的状态机；再把任务前置拆成依赖图；最后只在关键决策节点引入候选搜索。
这条顺序能避免过早复杂化。很多任务只需要 Plan-and-Solve，不需要 ToT。很多 ToT 只需要在两个关键分支上做候选比较，不需要展开几十个节点。工程系统追求的是可验证的完成率，不是把所有论文结构都搬进运行时。
给技术负责人的 4 个落地动作
选一条 5 步以上、经常失败、需要人工确认的业务链路，例如退款审批、故障补偿、合同审查或数据分析报告。
把现有 ReAct 日志拆成节点状态，明确每一步的输入、输出、依赖和失败处理。
在计划层加入依赖图生成，让系统先判断哪些节点可以并行，哪些节点必须等待。
只在高价值决策点引入 ToT 或 GoT，用评分器控制候选数量、成本和风险。
复杂 Agent 的上限不只取决于模型会不会推理，更取决于系统能不能把推理组织成计划、搜索和可恢复的执行状态。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
