给 AI Agent 加状态机，踩了个 instruction 注入的坑

Fri, 10 Apr 2026 00:00:00 +0000

做 Agent 做到一定复杂度，一定会遇到这个问题：多步骤流程怎么编排。

我们的场景是 UGC 视频制作——用户说"帮我做一条唇釉的带货视频"，Agent 需要走完意图分析、搜索对标、制定策略、仿写脚本、达人选角、生成素材这一整套流程。每一步都有不同的指令，需要调不同的工具，用户还可能在任何一步说"不满意，重来"。

靠 system prompt 里写一大段流程说明让 LLM 自己记住做到哪了？试过，对话一长就乱。跳步、重复、忘记之前收集的信息，各种问题。

所以我们给 Agent 装了一个状态机。

为什么是状态机

状态机的核心价值是把"Agent 应该做什么"从 LLM 的记忆里抽出来，变成一个确定性的外部数据结构。

不用状态机的时候，Agent 的行为完全依赖 LLM 对上下文的理解。LLM 需要从几十轮对话历史里推断出"我现在在第几步、下一步该做什么、之前收集了哪些信息"。这在 3-5 轮对话里还行，到了 10+ 轮就不可靠了。

用了状态机之后，每一轮对话开始时，系统从外部状态里读出"当前在哪一步"，把这一步的 instruction 注入到 LLM 的上下文里。LLM 不需要记忆，它只需要执行当前步骤的指令。

这个思路不是我们发明的。研究了 30 多个开源 Agent 框架后发现，所有做多步骤编排的框架本质上都是这个模式：

                    ┌─────────────────────┐
                    │    状态机 / 工作流    │
                    │  （确定性，外部维护）  │
                    │                     │
                    │  当前步骤 → instruction
                    │  转移条件 → 下一步    │
                    │  共享数据 → state.data │
                    └──────────┬──────────┘
                               │ 注入 instruction
                               ▼
                    ┌─────────────────────┐
                    │     LLM Agent       │
                    │  （概率性，执行层）   │
                    │                     │
                    │  看到 instruction    │
                    │  → 调用工具          │
                    │  → 回复用户          │
                    │  → 推进状态机        │
                    └─────────────────────┘

确定性的编排层告诉 Agent “该做什么”，概率性的 Agent 层决定"怎么做"。两层各管各的。

Prompt Engineering on niuzj

给 AI Agent 加状态机，踩了个 instruction 注入的坑

为什么是状态机