Day 15｜智能体的“状态机与工作流”——让 Agent 能“按流程办事”，而不是“自由发挥” ，状态机 = 不让 L

——让 Agent 能“按流程办事”，而不是“自由发挥”

到目前为止，你已经知道：

Day 13：记忆工程
Day 14：Tooling（工具库 = 行动能力）

但你会发现：

有了工具并不代表 Agent 就能“按计划执行”。 大模型 很容易忘流程、跳步骤、乱执行。

所以，AI 工程实践里必须补上一块：

State Machine（状态机） + Workflow Engine（ 工作流 引擎） = 让智能体像“程序”一样严格执行流程。

它能给你的 Agent 带来 3 大能力：

可控（流程明确）
可恢复（中断不崩）
可扩展（流程可配置）

今天这一篇，你会彻底理解：

为什么智能体一定需要状态机？
工作流和 Prompt 有什么本质区别？
如何设计一个“可回溯、可恢复”的 Agent 执行系统？
状态机与工具库如何结合？
如何把大模型从“自由聊天”变成“流程机器人”？
实战例子（内容生成 / 流程自动化 / 抓取任务）
最终给你一个“通用 Agent Workflow 模板（伪代码可直接用）”

这一篇非常关键，是智能体工程的底座。

01｜为什么智能体必须用“状态机 + 工作流”？

你有没有遇到这些问题：

LLM 执行任务时突然跳过步骤
工具调用顺序不稳定
多轮任务中断后无法恢复
两个工具之间依赖关系乱
重试会导致重复执行
智能体生成内容时突然换主题
系统复杂后，LLM 行为不可控

这些问题本质都是：

语言模型是 “概率机器”，不是“确定性程序”。而状态机提供确定性。

就像人类大脑自由联想很强，但做手术时必须遵守严格的步骤。

大模型也一样：

自由生成 → 强
严格执行流程 → 弱

所以你必须加上 状态机。

02｜状态机（State Machine）是智能体的“流程导航”

一个典型状态机包含：

State（状态）
Transition（状态转移规则）
Action（动作）

例如内容生产的流程：

Draft → Outline → Expand → Review → Polishing → Done

你必须严格告诉模型：

当前在哪个状态（state）
能转移到哪个状态（transition）
在这个状态下要执行什么工具（action）

这是把 AI 从“自然语言模型”变成“流程机器人”的关键步骤。

03｜工作流（Workflow）是“可配置的执行流程”

工作流解决的是：

任务执行顺序 + 依赖关系 + 条件流转

和 Prompt 最大不同：

Prompt 是“软指令”，模型可以不听
Workflow 是“硬约束”，模型必须遵守

工作流通常会包含：

顺序执行（Sequence）
分支（If/Else）
循环（Loop）
等待（Wait）
并行（Parallel）
错误恢复（Retry / Rollback）

这正是你后面做：

内容生成智能体
自动抓取 / 自动写报告智能体
视频脚本生成智能体
多文件产出的 AI

所必须具备的能力。

04｜状态机 + 工作流 = 强可控智能体架构

完整结构图：

User → Supervisor Agent → Workflow Engine → State Machine → Tools → Execution

流程分解：

用户提出任务
主管 Agent（LLM）制定初步计划
Workflow Engine 创建任务流程
State Machine 控制当前执行步骤
每个步骤让 LLM 决定细节并调用工具
执行工具
Flow 更新状态，继续下一步
最终返回结果

也就是说：

工作流决定“做什么”
状态机决定“现在做哪一步”
工具决定“怎么做”
模型决定“如何填内容 / 工具参数”

这是今天行业最稳的智能体架构。

05｜如何设计智能体的状态机？（可直接用）

最推荐的结构：

{
    state: "OUTLINE",
    next: ["EXPAND"],
    action: "generate_outline"
}

常用 6 类状态：

① INIT（初始化）

准备任务：

解析用户需求
设置目标
拆分子任务

② PLAN（规划阶段）

LLM 制定整体执行步骤，例如：

1. 生成大纲  
2. 扩写  
3. 校对  
4. 最终格式化

这一步输出的是：

状态机结构
工作流节点

③ EXEC（执行阶段：多个子状态）

典型内容生产智能体的执行状态：

OUTLINE → SECTION_EXPAND → MERGE → REVIEW → POLISH

④ FEEDBACK（循环状态）

Review Agent 做如下事情：

检查语义
检查格式
检查逻辑
发现错误 → 回到某个状态

例如：

POLISH → FEEDBACK → EXPAND

⑤ ERROR（异常状态）

触发条件：

工具错误
LLM 输出不符合 schema
中间文件损坏
检查不通过

错误处理策略：

ERROR → RETRY（最多 3 次）
ERROR → ROLLBACK（回到上一状态）

⑥ DONE（完成）

最终输出：

全文内容
文件生成
工作流结束

06｜如何设计一个“内容生成智能体”的工作流？

内容生产智能体 Workflow（可直接使用）

START
  ↓
ANALYZE_REQUIREMENT（解析任务）
  ↓
GENERATE_OUTLINE（生成文章结构）
  ↓
CONFIRM_OUTLINE（自检大纲）
  ↓
EXPAND_SECTIONS（逐节扩写）
  ↓
MERGE（拼接成全文）
  ↓
REVIEW（逻辑 / 结构 / 风格检查）
  ↓
POLISH（润色 & 格式）
  ↓
OUTPUT（导出 markdown）
  ↓
DONE

这和你现在写内容的流程完全吻合。

07｜把上面转成可执行的状态机（伪代码）

这是一个可以直接贴进工程框架里的状态机示例：

state_machine = {"INIT": {"action": "parse_requirement","next": "OUTLINE"
  },"OUTLINE": {"action": "generate_outline","next": "OUTLINE_REVIEW"
  },"OUTLINE_REVIEW": {"action": "review_outline","next": {"ok": "EXPAND","fail": "OUTLINE"
    }
  },"EXPAND": {"action": "expand_sections","next": "MERGE"
  },"MERGE": {"action": "merge_sections","next": "REVIEW"
  },"REVIEW": {"action": "final_review","next": {"ok": "POLISH","fail": "EXPAND"
    }
  },"POLISH": {"action": "polish_text","next": "DONE"
  },"DONE": {"action": "export_markdown","next": None
  }
}

这是一个真正工程级的、可落地的状态机。

08｜状态机如何和工具库结合？

Day 14 的工具库负责：

生成内容
分析文本
写文件
调用 API
检查质量

状态机负责：

调度工具
控制执行顺序
处理异常

模型负责：

决定内容
填写工具参数
自检工具结果

三者结合后，Agent 才能做到：

可控、可恢复、可扩展。

09｜让 Agent 可恢复（Recovery）的关键：持久化状态

任何生产级智能体都要做：

每次状态转移前写入数据库
工具执行前后都记录日志
状态机在异常中断后能恢复到最近的状态

示例记录：

task_id = 18374
current_state = "EXPAND"
progress = 4 / 7
last_output = "section_4.md"

中断后：

重新加载状态 → 回到 EXPAND → 继续写 section 5

这是 Devin、AutoGPT 级别系统的标准。

10｜最终给你的成品：智能体 Workflow Prompt

这是 AI 工程师最常用的通用模板：

你是负责状态机执行的智能体。
规则：
1. 必须严格按照当前状态执行对应 action
2. 禁止跳过状态
3. 执行完 action 后，根据结果决定下一状态
4. 若发生错误，必须触发 error handler
5. 每一步都必须输出：
   - 当前状态
   - 执行的工具
   - 工具参数
   - 工具返回结果
   - 下一状态
不要自行更改流程。

这就是控制大模型的“缰绳”。

总结：

状态机 = 不让 LLM 乱来 工作流 = 不让 LLM 忘步骤 工具库 = 让 LLM 能真正行动 三者一起 = 工程级智能体