AI Agent的Prompt陷阱：为什么你不能全靠提示词管理状态
2026年5月，开源AI编程Agent领域出了一个"里程碑"：droid 架构用 65KB 的Prompt定义了整个任务编排系统。这个数字震住了不少人——原来用Prompt可以替代传统状态机。
但仔细看架构细节，我发现一个被忽视的问题：Prompt能帮你"描述"状态机，但它不能帮你"运行"状态机。
01 Prompt是描述，不是执行
droid 0.1220的架构确实精巧。它用Prompt定义了：
| 维度 | Prompt定义 |
|---|---|
| 任务定义 | JSON Schema |
| 编排逻辑 | "If error, retry with..." |
| 质量门控 | "Verify output..." |
| 执行记录 | 上下文自带 |
| 暂停恢复 | 状态存进内存 |
看起来五脏俱全。但核心问题是：这些都是Prompt告诉模型的"规则"，不是模型必须遵守的"法律"。
模型可以"理解"状态机，但它不"执行"状态机。
- Prompt说"检查结果再继续"，模型可能跳过硬查
- Prompt说"三次重试失败就停止"，模型可能第六次还在试
- Prompt说"记住上一步的状态"，上下文丢失时模型当场失忆
这不是droid的bug，这是所有Prompt-driven架构的 structural flaw。
02 对比：程序化状态机的确定性强在哪
传统状态机是这样的：
state = IDLE
if input == "start":
state = RUNNING
elif input == "stop" and state == RUNNING:
state = STOPPING
确定性强在哪：
- 状态转移是原子操作，不存在"模型理解错了"
- 状态持久化是显式的，不存在上下文丢失
- 边界条件是强制执行的，不存在"应该停止但还在跑"
Prompt驱动做不到这些。Prompt是指导性的，不是强制性的。
03 现实中的断裂：大厂已经意识到这个问题
看几个信号：
- Anthropic 在 Agent Marketplace 实验中加了 human-in-the-loop 审批节点，不是全靠Prompt自驱
- OpenAI 的 Agents 模式加了"tool use guardrails"，用程序化约束补充Prompt
- Google Gemini 2.0 的 agentic 模式，状态管理用的是显式 checkpoint，不是纯上下文
大厂不傻。他们知道Prompt的边界在哪。
04 正确的架构思路：Prompt + 程序化双轨
droid 架构的真正贡献不是"用Prompt替代状态机"，而是用Prompt降低状态机的设计成本。
正确的双轨模式：
| 层 | 职责 | 实现方式 |
|---|---|---|
| 业务逻辑层 | 定义"做什么" | Prompt (可读、可改) |
| 执行控制层 | 强制"怎么做" | 程序化 (原子操作) |
| 状态持久层 | 记住"做到了哪" | 数据库/文件 |
| 质量门控层 | 判断"做对了没" | 程序化断言 |
Prompt处理不了的部分，强行用代码实现。
这才是 2026 年 AI Agent 架构的现实解法。
05 我的判断
65KB Prompt 确实精巧，但别被数字迷惑。
- 65KB 可以描述状态机
- 但它不能代替状态机
- 描述 ≠ 执行
Prompt是很好的需求定义语言，但它不是好的运行时语言。
2026年还在玩纯Prompt驱动的架构，本质上是把表达能力当执行能力用。区别就像：
菜谱写得好 ≠ 菜做得好
分析基于 droid 0.1220 公开架构文档，数据来源：GitHub / HN 讨论