Agent系统中基础设施强制vs提示引导的边界选择

这道题类型在考试大纲中属于一类题，会把考生分成两派，而大多数备考资料（包括我们的）给出的建议只涵盖了其中一种情况。

题干给出一个系统，该系统绝对不能做某件事。比如一个分类器只能返回固定列表中的类别，一个 Agent 绝对不能执行破坏性 SQL，一个步骤绝对不能在前置步骤完成之前启动。然后题目会问，哪种方案可以满足这个要求。

其中一个选项会添加一条清晰、措辞得当的指令。另一个选项则添加一个钩子、一个门控、一个作用域限制或一个验证步骤。

标准建议是：基础设施负责执行，prompt 只能起引导作用，所以选基础设施。我们自己在反模式那篇文章里也是这么写的，而且这个说法有一半的时候是对的。

这些题目实际分布在哪里

大多数人会把这道题归到 Prompt Engineering 和 Structured Output 下。确实，schema 讨论属于那里，验证相关的术语也是在那里教的。

在我们银行，涉及代码级答案而避开 prompt 级干扰项的题目集中在 Agentic Architecture and Orchestration：那里有十二道，而 Prompt Engineering 只有五道。钩子、前置条件门控、子 Agent 隔离、工具作用域。

但反过来就不一样了。在 prompt 级答案正确、代码级选项被标记为错误的题目中，有三分之二落在 Prompt Engineering 里。

所以如果你通过阅读结构化输出来复习这个专题，你会遇到那些措辞正确的案例，却会错过大多数措辞不正确的案例。反过来，如果你靠背"永远在代码里强制执行"，你会做相反的事。

指南本身的措辞是有条件的

这是值得直接从官方指南里提取的部分。

每次指南将确定性机制与 prompt 指令对置时，条件就摆在旁边。钩子和门控出现在"需要确定性合规时"和"业务规则要求保证合规时"。即便是关于结构化输出最有力的表述——说它是保证 schema 合规输出最可靠的方法——也把"保证"这个词包在里面。

指南从未说过执行类方案通常更好。它说的是当你需要的是保证时，才应该选用它。

除此之外，同一份指南在其他地方也点名了 prompt 级的答案。规范化规则应该和 schema 一起放在 prompt 里。Few-shot 示例被指名为格式一致性最有效的技术。工具描述被指名为工具选择的主要机制，而不是路由层。

需求是需要保证，还是需要准确性？

如果某事绝对不能发生或必须始终成立，而违规是业务或安全失败而非质量问题，那这个需求就需要在模型之外进行强制执行。

如果某事需要做得好、做得很一致、或以特定格式来做，那这是一个 prompt 问题，添加基础设施是错误的答案。

区分它们的可靠方法不是看需求的措辞。而是问失败的后果是否落在对话之外。后续代码根据类别做分支判断。一次删除触碰了生产环境。一个步骤提交了不可逆的操作。当失败逃出对话落到别的地方，你就需要保证。

当它没有逃出时，当坏输出的代价只是输出本身不好时，你需要的是准确性。

为什么明显的捷径会失败

这道题一个诱人的做法是扫描题干里有没有"never"、"always"或"must"。

这不管用，而且在你依赖它之前值得知道为什么。在我们银行，"保证"类词汇最多只出现在一半代码级正确答案的题干中。其余的只是陈述需求而没有用这些词。与此同时，至少有一道 prompt 级正确答案的题目在引用系统 prompt 行里包含了"always"，这恰恰就是陷阱所在：这个词出现在场景里是因为有人把它写进了指令里，而指令本身才是被审视的对象。

读后果，别读形容词。

识别错误选项的三种形态

从我们银行这类题目中手动分类干扰项得出：

把 prompt 措辞当作保证来提供。这是迄今为止最常见的一种。一条指令清楚地、强调地命名了约束条件，却放在本该放机制的地方。

一个真实机制但作用域错误。选项提名了一个真实能执行约束的东西，却用在它覆盖不到失败的地方。钩子挂在一个在损害发生之后才触发的事件上。工具从实际需要它的子 Agent 那里被撤走了。强制的工具选择却无法排序第二次调用。

对真实机制行为的虚假描述。更难发现，因为机制本身是对的但描述的行为不对。会自动重试的钩子。配置在不存在的位置的钩子。一个严格的 schema 却从源文档填补缺失字段。

还有一小类值得单独命名，因为它会坑到有经验的人：把 temperature 设为零，或更换模型，作为保证的替代品。这两者都不能把概率转化成确定性。temperature 零确实是某些一致性问题的正确答案，这正是它能在其他地方充当你干扰项的原因。

复习时怎么用这个

找这类题目中你已经答过的，在看选项之前，先写下失败的后果落在哪里。落在对话之内，还是之外。

如果你能正确分类，通常正确答案就变得很明显了。如果你做不到，无论你复习多少遍，错误答案都会继续看起来合理。

然后检查你的错误偏向哪个方向。把基础设施当作准确性问题的答案，和把措辞当作保证问题的答案，是两种不同的错误，修复方法也不同。前者意味着你矫枉过正了，大概是因为受了类似我们文章的建议。后者意味着你还没有内化"指令是一个请求"这件事。

一个完整解释的工作实例在这类题目的免费题库里

一句话版本

指令改变的是模型可能做什么。钩子、门控或验证步骤改变的是系统能够做什么。读失败落在哪里，决定需求需要哪一个，然后那个把两者混为一谈的选项就会凸显出来。

关于这方面的结构化输出侧，包括 schema 何时不再有帮助，见 prompt engineering and structured output guide。对于这些题目所在的编排模式，agentic architecture guide 涵盖了更广的领域。