超越提示词：为什么 AI Agent 需要确定性控制流

关于 AI agent 的主流叙事长期以来一直围绕着“提示词工程”（prompt engineering）——即寻找魔法词汇来让模型表现出特定行为的艺术。然而，随着开发者从简单的原型转向复杂的、生产就绪的系统，他们正面临一道墙。当你发现自己不得不使用全大写的 MANDATORY 或 DO NOT SKIP 来强迫模型遵循某个序列时，你就已经触及了“提示词的上限”。

软件的可靠性一直是通过确定性控制流来实现的：显式的状态转换、验证检查点以及递归的可组合性。为了让 AI agent 不再仅仅是“随机鹦鹉”，而是成为可靠的工具，逻辑必须从散文式的描述中转移到运行时（runtime）中。

提示词逻辑的失效

提示词链（prompt chains）本质上是非确定性的且规范定义薄弱。将 LLM 视为整个系统而非系统中的单个组件，会导致随着复杂度的增加，可靠性发生崩溃。

想象一种编程语言，其中的语句仅仅是建议，而函数在返回“成功”的同时可能还在幻觉出结果。在这种环境下，推理变得不再可能。这就是许多 agentic workflows 的现状，即 LLM 被要求管理其自身的高层编排。正如一位用户在 Hacker News 的讨论中所指出的，让模型管理控制流往往会导致它遗漏文件、对 bundle 进行三重测试，或者陷入循环——即使是像 GPT-4 或 Claude 3.5 这样最先进的模型，这些失败依然存在。

将逻辑转移到运行时

为了构建可靠的 agent，开发者必须实现确定性的脚手架。这意味着将 LLM 视为执行特定、受限任务的工具，而周围的软件负责处理“如何做”和“何时做”。

1. 确定性编排

与其要求一个 agent “研究一个主题然后写一份报告”，确定性系统会将此分解为 DAG（有向无环图）或状态机：

• 第 1 步： LLM 生成搜索查询。
• 第 2 步： 程序化搜索执行（确定性的）。
• 第 3 步： LLM 综合结果。
• 第 4 步： 程序化验证输出格式。

通过将记账和路由工作移至符号层（symbolic layer），开发者可以降低 token 成本，提高速度，并消除 agent “忘记”某个步骤的风险。

2. 激进的错误检测与质量门禁

没有程序化验证的 agent 仅仅是快速得出错误结论的一种方式。社区提出了三种常见的（且通常是有缺陷的）错误处理方法：

• 监护人模式： 让一个人类参与其中（human in the loop），以便在错误传播之前将其拦截。
• 审计员模式： 在运行结束后进行详尽的端到端验证。
• 祈祷模式： 对输出进行“感觉验收”（vibe-accepting），并寄希望于最好结果。

为了超越这些模式，开发者正在实现“质量门禁”（quality gates）——即处理质量保证的确定性节点。例如，Stripe 的 "Minions" 系统在非确定性的 LLM 工作之间利用确定性节点来确保质量，而不必将验证工作留给 LLM 本身。

行业观点

向确定性控制流的转变引发了各种技术反驳意见和补充策略：

LLM 在软件创建中的角色

一些人认为，最终目标并不是在运行时使用 LLM 来完成任务，而是使用 LLM 来 编写能够完成任务的软件。在这种观点下，LLM 的角色缩小为帮助用户向体现了硬性业务规则的系统提供合规的输入。

“操作反射”方法

为了在确保一致性的同时保持一定的灵活性，一些开发者使用“锁文件”（lockfiles）来处理常见任务。这些定义了哪些特定的技能或知识片段与任务相关，充当一个协调器，根据预定义的蓝图而非开放式的提示词来分配任务。

混合模型

关于我们是否只是在重新发明编程，目前存在争议。正如一位评论者所言：

"Can't wait for ya'll to come full circle and invent programming from first principles."

然而，其他人建议采用混合方法——类似于游戏引擎使用高级脚本语言（如 Lua）来调用高性能的 C++ 库。在这种类比中，LLM 提供灵活的“脚本”层，而确定性脚手架则提供稳健的“工程”层。

结论：Agent 工程的未来

设计控制流——而不是编写提示词——正在成为 agent engineering 的新前沿。通过将 agent 循环与展示层和控制层分离，开发者可以构建出可观测、容错且真正可扩展的系统。目标不是消除 LLM 的创造力，而是将其约束在一个能够保证结果符合用户意图的框架内。