【提示词写满 “务必”、“绝对不要”？你已碰到提示词工程天花板】

快速阅读：当你在 Prompt 里写下“务必”、“绝对不要”时，说明你已经撞到了提示词工程的天花板。真正的 Agent 稳定性不来自更长的咒语，而来自在非确定性的模型外层，构建一套确定性的软件控制流。

如果你发现自己不得不写下“务必”或“绝对不要”来约束模型，那说明你已经触碰到了提示词的极限。

现在的 Agent 开发逻辑很怪。大家总觉得只要模型能力够强，或者 Prompt 写得够长，就能搞定一切。但实际情况是，当你试图让模型去管理高层级的控制流——比如让它自己决定按顺序处理 200 个文件——它很快就会崩溃。它会漏掉文件，或者在没理由的情况下重复测试已经做过的内容。这不像是在用工具，倒像是在祈祷。

把 LLM 当成整个系统的核心是危险的。如果一个编程语言的语句只是“建议”，函数返回的“成功”可能只是幻觉，那这个系统根本无法扩展。

解决办法不是去堆砌更高级的模型，而是把逻辑从自然语言挪回运行时。

有网友提到，与其让 Agent 在 Prompt 里反复横跳，不如写一段 Python 脚本作为“脚手架”。让模型去执行这些确定性的脚本，把复杂的循环、状态管理和文件读写交给代码，而只把模型当作处理模糊逻辑的“插件”。这种做法让系统可靠性提升了几个量级。

这其实是在构建一种“混合架构”：用确定性的代码逻辑来包裹非确定性的模型调用。

有观点认为，这种模式本质上是把 LLM 从“执行者”降级为“翻译层”或“决策点”。当遇到需要逻辑判断的边界情况时，再调用模型；其余时间，交给高效、廉价且绝对可靠的代码。

这种做法虽然让 Agent 看起来没那么“全能”了，但它真正能干活。

与其做一个随时可能在生产环境由于幻觉而“自毁”的超级智能，不如做一个能精准调用工具、并能通过代码自动校验结果的可靠系统。

你是在构建一个智能体，还是在构建一个昂贵的、不可控的随机数生成器？

bsuh.bearblog.dev/agents-need-control-flow/