「Agent 需要控制流，不是更多 Prompt」：一篇值得 AI 开发者读的文章

2026 年 5 月 7 日，一篇名为《Agents Need Control Flow, Not More Prompts》的博客文章在 Hacker News 上引发了广泛讨论。作者 Brian（bsuh）提出了一个简洁但深刻的观点：如果你正在开发 AI Agent，与其花时间优化 Prompt，不如把逻辑写成代码。

核心论点

文章从一个常见的痛点切入：如果你曾经在 Prompt 里写过「MANDATORY」「DO NOT SKIP」「你必须」这样的词，你就已经触及了 Prompt 工程的天花板。

作者用了一个精彩的类比：

想象一种编程语言，其中的语句只是「建议」，函数返回「成功」的同时会产生幻觉。推理变得不可能；可靠性随着复杂度增长而崩溃。

这正是用 Prompt 链构建 Agent 的现状——你在用一种「不确定性的语言」来表达「确定性的逻辑」。

软件为什么能 scale

作者指出，软件之所以能构建复杂系统，是因为它具有递归组合性：

系统由库、模块、函数组成
代码暴露可预测的行为
每个组件可以被独立推理和测试
局部推理是可能的——你不需要理解整个系统就能理解一个函数

而 Prompt 链不具备这些特性。每个 Prompt 的输出是不确定的，你无法对它做局部推理，也无法保证它在不同输入下的行为一致性。

可靠性需要确定性脚手架

作者的核心建议是：把 Agent 的逻辑移入运行时（runtime），用确定性的脚手架包裹 LLM。具体来说：

显式状态转换：用状态机定义 Agent 的工作流，而不是让 LLM 自己决定下一步做什么
验证检查点：在每个关键步骤后用程序化的方式验证结果，而不是依赖 LLM 自我检查
LLM 是组件，不是系统：LLM 应该是更大软件系统中的一个组件，而不是系统本身

错误检测是关键

文章特别强调了错误检测的重要性。在一个容易产生「静默失败」的系统中，没有积极错误检测的 Agent 只是「快速到达错误结论的方式」。

作者指出了三种没有程序化验证时的选择：

保姆模式：让人类在循环中检查，防止错误传播
审计模式：在运行结束后做穷尽的端到端验证
祈祷模式：「Vibe 接受」输出（这是对「vibe coding」的幽默引用）

对 Agent 开发者的实用建议

基于这篇文章的观点，以下是给 AI Agent 开发者的具体建议：

1. 用代码表达控制流

# 错误做法：用 Prompt 让 LLM 决定流程
prompt = "如果分析结果是 A，执行 X；如果是 B，执行 Y；如果不确定，再分析一次..."

# 正确做法：用代码控制流程
result = llm.analyze(data)
if result.confidence > 0.8:
    if result.category == 'A':
        execute_x(result)
    elif result.category == 'B':
        execute_y(result)
else:
    result = llm.analyze_with_more_context(data, additional_info)
    verify_and_proceed(result)

2. 为每个 LLM 调用添加验证

不要假设 LLM 的输出是正确的。在关键步骤后添加验证：

output = llm.generate(prompt)
assert output_format_is_valid(output), "LLM 输出格式错误"
assert output_values_in_range(output), "LLM 输出值超出范围"
# 只有验证通过才继续

3. 用状态机管理 Agent 工作流

把 Agent 的工作流定义为一个状态机，每个状态有明确的进入条件和退出条件：

states = {
    'INIT': {'next': 'ANALYZE', 'condition': lambda ctx: ctx.input_valid},
    'ANALYZE': {'next': 'DECIDE', 'condition': lambda ctx: ctx.analysis_done},
    'DECIDE': {'next': 'EXECUTE', 'condition': lambda ctx: ctx.decision_made},
    'EXECUTE': {'next': 'VERIFY', 'condition': lambda ctx: ctx.execution_done},
    'VERIFY': {'next': 'DONE', 'condition': lambda ctx: ctx.verification_passed},
}

4. 限制 LLM 的职责范围

LLM 擅长的是：理解自然语言、生成文本、做判断。LLM 不擅长的是：精确计算、状态管理、流程控制。让 LLM 做它擅长的事，其他的事交给代码。

为什么现在特别重要

2026 年是 AI Agent 大爆发的一年。从 Claude Code 到 Cursor，从 Devin 到各种自动化工具，Agent 正在从实验性产品变成生产力工具。但很多 Agent 的可靠性仍然堪忧——它们在简单任务上表现不错，但在复杂任务上经常「静默失败」。

这篇文章的核心观点——用确定性的软件工程方法构建 Agent 的骨架，让 LLM 做推理和生成——可能是提升 Agent 可靠性的关键。

写在最后

如果你正在开发 AI Agent，或者在使用 Agent 工具时遇到可靠性问题，这篇文章值得一读。它的核心信息很简单：Prompt 不是银弹，好的软件工程实践才是。在 AI 时代，传统的软件设计模式——状态机、验证、错误处理、模块化——比以往任何时候都更重要。

本文参考来源：

Agents Need Control Flow, Not More Prompts

Hacker News 讨论

文章版权声明 1、本网站名称：枫选
2、本站永久网址：https://feng.cx
3、本网站的文章部分内容可能来源于网络，仅供大家学习与参考，如有侵权，请联系站长进行删除处理。
4、本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
5、本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报
6、本站资源大多存储在云盘，如发现链接失效，请联系我们我们会第一时间更新。

THE END