← #793

Agent 需要的是控制流，而不是更多 Prompt

文章摘要

作者直击当下 AI agent 设计的一个核心误区：把所有逻辑都塞进 prompt，期待模型”自己想清楚要做什么”。他用一个程序员能秒懂的类比开场——想象你写代码时，每一条语句都只是”建议”，每个函数都可能凭空捏造结果，那你根本没办法做任何推理，复杂度一上来系统就崩了。Prompt 的本质就是这种”建议性、弱规约、难验证”的指令，所以单纯堆 prompt 永远不可能搭出可靠的复杂系统。

文章的核心论点是：可靠软件的根基是递归可组合性——库、模块、函数层层封装，每一层都有确定行为、可测试、可被上层信任。Prompt 完全不具备这些性质。所以正确做法不是”写更聪明的 prompt”，而是把逻辑从散文搬到运行时：用确定性脚手架显式定义状态转换、校验关卡、错误分支，把 LLM 当作系统中的一个组件，而不是整个系统本身。

作者还点出一个被低估的问题：错误检测。如果你完全依赖 prompt，组织面前只剩三条糟糕的路：派一个人盯着 agent 跑、事后做穷举式审查、或者干脆”信仰一下”接受结果。这三条路都不可扩展。真正的 agent 系统应该把验证步骤——比如运行单元测试、跑校验函数、对照 schema——做成确定性的代码节点，强制嵌入流程，让模型即使想偷懒也绕不过去。

简单说，作者主张的”控制流”是把 agent 当成有限状态机或受限工作流：节点之间的跳转由代码控制，每个节点内部允许调用 LLM 做局部决策，但出口必须通过显式校验。这种”夹心结构”——确定性外壳裹着非确定性核——是把 LLM 的概率本质转化为工程可用形式的关键。

HN 评论精华

827a：分享一个真实失败案例——他做的 QA agent 要测试 200 个 markdown 文件，前 30 个都好好的，之后开始幻觉、跳过、乱标。改用确定性 harness 包住循环、由代码控制迭代之后，可靠性”提升了十亿倍”。这是文章观点的最佳教科书例证。
DrewADesign：揭露一个商业动机——大厂之所以鼓吹”全 prompt 工作流”，是因为他们按 token 数赚钱。一旦你引入确定性步骤，反而能用更小、更便宜、更专精的模型把任务做好——这对卖大模型 API 的公司是反向利益。
fny：提出一个具体落地点子——把 orchestration prompt”编译”成代码。也就是说，先用自然语言描述流程，再产出确定性的执行框架嵌入到 agent skill 里，让模型无法漂离预定逻辑。
bob1029：报告自己工程实践的成功率——把 apply_patch 这种 LLM 工具与 check_compilation、run_unit_tests 这种确定性钩子配对，让钩子在每次 patch 后自动执行而不是靠模型记得调用，成功率从 ~80% 提升到几乎 100%。
vishvananda：用一个生动的词描述这种架构——”sandwich”，确定性流外壳夹着非确定性决策内核。他认为这种分层结构不仅更可靠，还更便宜，因为每一层只把模型用在它擅长的事情上。
59nadir：提到 Stripe 内部的 Minions 系统，特点就是在多个 LLM 节点之间策略性地插入确定性 QA 节点，关键校验绝不交给模型自由判断。这是大公司在生产环境验证过的范式。
Neywiny：立场最强硬——从 LLM 中”提取确定性”是个伪命题。Prompt 永远只能”建议”，不能”保证”。任何把可靠性建在 prompt 上的设计本质都是赌博。
评论区共识：未来一两年的 agent 实战分水岭，将是”会不会写控制流”。能写状态机、能搭工具调用栈的工程师将主导 agent 工程，而那些只会拼 prompt 的所谓”prompt engineer”角色会被快速边缘化。