状态、编排与行动的关系

假设一个 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 或显式状态机。状态机可以把任务划分成：

BUILDINGTESTINGDIAGNOSINGWAITING_FOR_HUMANDEPLOYINGVERIFYINGDONEFAILED

每个状态都有明确的进入条件和退出条件。测试没有通过，就不能从 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 可以进入失败节点或人工处理节点。任务状态和中间产物继续保留，后续可以重试或从检查点恢复。

这样，自主节点保留完成局部任务所需的灵活性，也不会打散整个系统的控制边界。

最后

对于正在迷茫择业、想转行提升，或是刚入门的程序员、编程小白来说，有一个问题几乎人人都在问：未来10年，什么领域的职业发展潜力最大？

答案只有一个：人工智能（尤其是大模型方向）

当下，人工智能行业正处于爆发式增长期，其中大模型相关岗位更是供不应求，薪资待遇直接拉满——字节跳动作为AI领域的头部玩家，给硕士毕业的优质AI人才（含大模型相关方向）开出的月基础工资高达5万—6万元；即便是非“人才计划”的普通应聘者，月基础工资也能稳定在4万元左右。

再看阿里、腾讯两大互联网大厂，非“人才计划”的AI相关岗位应聘者，月基础工资也约有3万元，远超其他行业同资历岗位的薪资水平，对于程序员、小白来说，无疑是绝佳的转型和提升赛道。

如果你还不知道从何开始，我自己整理一套全网最全最细的大模型零基础教程，我也是一路自学走过来的，很清楚小白前期学习的痛楚，你要是没有方向还没有好的资源，根本学不到东西！

下面是我整理的大模型学习资源，希望能帮到你。

👇👇扫码免费领取全部内容👇👇

最后

1、大模型学习路线

2、从0到进阶大模型学习视频教程

从入门到进阶这里都有，跟着老师学习事半功倍。

3、 入门必看大模型学习书籍&文档.pdf（书面上的技术书籍确实太多了，这些是我精选出来的，还有很多不在图里）

4、 AI大模型最新行业报告

2026最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

5、面试试题/经验

【大厂 AI 岗位面经分享（107 道）】

【AI 大模型面试真题（102 道）】

【LLMs 面试真题（97 道）】

6、大模型项目实战&配套源码

适用人群

四阶段学习规划（共90天，可落地执行）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型

• 带你了解全球大模型

• 使用国产大模型服务

• 搭建 OpenAI 代理

• 热身：基于阿里云 PAI 部署 Stable Diffusion

• 在本地计算机运行大模型

• 大模型的私有化部署

• 基于 vLLM 部署大模型

• 案例：如何优雅地在阿里云私有部署开源大模型

• 部署一套开源 LLM 项目

• 内容安全

• 互联网信息服务算法备案

• …

  👇👇扫码免费领取全部内容👇👇

  

3、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】