AI Agent 可靠性困局：真正需要的是控制流，而不是更多提示词
Hacker News 热榜 519 分文章引爆争论：当 AI Agent 需要面对复杂任务时，用更多提示词堆叠是不可靠的。真正的破解之道，是把确定性控制流写进代码——让 LLM 成为系统组件，而非系统本身。
2026年5月8日 · 阅读约 4 分钟
核心结论
当 AI Agent 需要处理复杂多步骤务时，用更长的提示词堆叠并不能解决根本问题。5 月 7 日，一篇标题为"Agents need control flow, not more prompts"的文章在 Hacker News 上获得 519 分，引发硅谷工程师对 Agent 架构的深刻反思。
关键要点
- 事件发生时间：2026-05-07
- 核心观点：可靠的 Agent 系统需要确定性控制流（代码），而非非确定性的提示词链
- 影响对象：所有使用 LLM Agent 执行自动化任务的内容团队和开发者
- 衍生框架：LangGraph、BAML、Stripe Minions、SalesForce AgentScript 等控制流方案
背景：当提示词遇到天花板
如果你曾经在提示词里写过 MANDATORY 或 DO NOT SKIP，说明你已经碰到了提示词的天花板。
作者 bsuh 指出一个尖锐的比喻：想象一种编程语言，其中的每条语句都只是"建议"，函数返回"成功"的同时可能还在幻觉。推理变得不可能，随着复杂度增长，可靠性彻底崩溃。
软件工程的根基在于递归可组合性：系统由库、模块和函数一层层搭建。代码暴露出可预测的行为，支持局部推理。但提示词链不具备这个属性——它们是非确定的、弱指定的、难以验证的。
关键影响
| 维度 | 变化 | 对 Agent 开发的影响 | 建议动作 |
|---|---|---|---|
| 架构范式 | 从"提示词工程"转向"控制流工程" | Agent 开发更像传统软件开发 | 将逻辑从提示词移到运行时 |
| 可靠性 | 确定性控制流可验证，提示词链不可靠 | 非确定性 Agent 仅适合窄范围任务 | 引入显式状态转换和验证检查点 |
| 错误处理 | 无程序化验证的 Agent 只会更快到达错误结论 | 需要积极的错误检测 | 设计三元模型：Babysitter / Auditor / Prayer |
| 工具生态 | LangGraph、BAML、AgentScript 等框架涌现 | 已有现成工具可实现控制流 | 选择合适框架替代纯 prompt 编排 |
三种不可靠 Agent 的应对方案
bsuh 在文章中画了一条分界线：确定性编排只是解决了问题的一半。在容易发生静默失败的系统里，没有积极错误检测的 Agent 只是更快地抵达错误结论。没有程序化的验证，开发者只剩下三种选择：
1. Babysitter（保姆模式）
保持人类在循环中，在错误扩散前拦截。适合高可靠性要求场景，但无法规模化。
2. Auditor（审计模式）
运行结束后做彻底的端到端验证。适合批量处理任务，但发现问题时为时已晚。
3. Prayer（祈祷模式）
"Vibe accept the outputs"——接受输出，祈祷没错。这是目前大多数团队的真实状态。
社区声音：控制流方案的实践
HN 社区讨论进一步深化了这个观点：
- apalmer 指出：AI 编码的突破不在于 AI 智能提升，而在于核心流程执行从 LLM 提示词移到了框架层。
- Stripe 的 Minions 团队分享：在非确定性 LLM 工作之间插入确定性节点处理质量保证，留给 LLM 只做它们擅长的事。
- 59nadir 提到 Stripe 的 Minions 系统正是这种理念的实践——在 LLM 工作流中嵌入确定性 QA 节点。
- jerf 总结：提示词靠不住的场景，需要的是"下一代 AI"——不是更强的 LLM，而是更好的架构。
工具词条
正文中出现以下工具/框架：LangGraph、LangSmith、Claude、ChatGPT、Stripe、SalesForce、BAML、n8n
内链引导
- 想深入了解 AI Agent 工具实操？看：AI Agent 工具实操教程：从安装到自动化工作流
- 真实的自动化变现案例：他靠 AI 代码审查+规范驱动开发月入过万：自由开发者的实战复盘