文章总结： 本文通过PB&J三明治制作案例，揭示AIAgent在无攻击情况下仍可能因字面执行模糊指令引发事故的风险。核心指出Agent安全需从系统层面构建约束机制，而非仅依赖提示词工程。关键建议包括实施最小自治原则、状态化授权检查及人机协同决策，以降低意图偏差导致的意外后果。 综合评分： 78 文章分类： AI安全,安全建设,解决方案,安全运营,安全开发

[译苑雅集Vol. 9] 没人攻击，AI Agent 也可能把事情办砸

四楼南侧东 四楼南侧东

表图

2026年5月27日 21:07 北京

在小说阅读器读本章

去阅读

作者：Henry Farrell

时间：2026 年 05 月 26 日

原文：https://blog.sondera.ai/p/agent-pbj-problem

你大概做过这个练习。也许是在小学课堂上，也许是父母拿它逗过你，也许你后来也用它逗过自己的孩子。练习很简单：你写下制作花生酱果酱三明治，也就是 PB&J (Peanut Butter & Jelly sandwich exercise) 的步骤，然后让另一个人严格按字面意思执行。你写“把花生酱放到面包上”，对方就真的把整罐花生酱放在一袋还没打开的面包上。这个老爸式笑话背后有个道理：我们说出口的话，和我们真正想表达的意思，中间可能隔着很大一段距离，而且多数时候，我们根本没意识到这段距离存在。

人和人之间，会用常识、清单和互相确认来填补这段空白。到了 Agent 这里，这段空白始终敞开着。

PB&J 这个“精确指令”练习，正好抓住了 Agent 面临的核心难题：你怎么知道它理解的是你的真实意图，而不会只抓住字面去做？

Agent 能遵守规则，但未必理解意图

PB&J 练习能一代代流传下来，是因为它讲了一个没法再压缩的问题：人类沟通依赖大量共享语境和常识，而我们平时很少意识到这一点。我们知道要先打开面包袋，也知道要拧开罐子。即使从没做过三明治，也不会把这些步骤当成额外知识。它们不在菜谱里，却在我们的脑子里。如果所有人都只按字面规则行动，沟通和协作都会变得非常困难。

Agent 不一样。它们没有人类那种常识和伦理直觉。它们可能会奖励黑客 reward hacking ，也天然倾向于把收到的指令执行下去。Agent 安全讨论里，这一点一直没有得到足够重视。

现在，公开讨论大多集中在提示词注入上。有人把恶意指令塞进文档、邮件或网页，Agent 读到以后，开始做用户并没有要求它做的事。Simon Willison 提出的“致命三元组”很好地解释了提示词注入为什么危险：当一个 Agent 同时接触不可信输入、能访问私有数据，并且具备对外行动能力时，数据外泄或破坏的风险就会出现。编程 Agent 往往正好同时具备这三点。

这个风险当然真实。有人诱骗 Agent 做错事，确实值得警惕。可 PB&J 问题把我们带到另一个更麻烦的场景：没人攻击它，它也可能把事情办砸。

用户要一个三明治。Agent 有权限进入厨房，有权限拿罐子，也有权限使用刀具。它按字面执行指令，于是没有拧开盖子，而是把花生酱罐子砸开。没有攻击者，没有恶意载荷，Agent 也确实在执行任务。但最后留下的，仍然是一个乱糟糟的厨房。

事故面也是攻击面

“删除测试数据”“核对总账”“把报告发给团队”，这些话在人看来都很普通，但每一句都有一个 Agent 可能照字面执行的版本，而且有些版本会带来灾难性后果。删除测试数据，可能删掉生产库，因为 Agent 不知道用户说的是哪个数据库。核对总账，可能记到错误账户。把报告发给团队，可能发进一个有客户在场的 Slack 频道。

这些失败都不是提示词注入，它们是 PB&J 问题：一个被授权的 Agent，使用被授权的工具，面对模糊指令，然后照字面执行。攻击面 attack surface 和事故面 accident surface 在这里重叠了。

致命三元组有三条腿。现在的讨论之所以集中在不可信内容和提示词注入上，是因为大家很自然会想从提示词层面控制 Agent。但到今天，我们已经必须把提示词注入视为一个默认会发生的条件。真正造成损害的是第三条腿，也就是外部动作。后果发生在动作那里。

一个收到坏指令但没有工具的 Agent，最多生成一段文本。文本当然也会带来问题，但比行为更容易控制。坏指令可能来自 PDF 里的恶意载荷，也可能来自一个忘了说明数据库名称的用户。来源不同，Agent 的行动方式却可能一样，影响范围也一样。

换句话说，致命三元组讲的不只是攻击者。它讲的是：授权能力遇到模糊意图，就可能失败。攻击者是模糊意图的一个来源，用户也是，LLM 自身也是，系统提示词也是。Agent 未必能分清哪条指令来自哪里，它只是执行。

写更好的提示词够吗

提示词工程能解决这个问题吗？写一个更好的系统提示词。做一个 30000 行的 CLAUDE.md。把缺失的上下文补进去。把边界情况都列出来。写一份详尽的指令文件当然很累，但并非做不到；写完以后，Agent 确实会拥有更多上下文，更有可能做出一个像样的 PB&J。

更好的提示词、更强的模型，都会有帮助，也能缩小一部分差距。问题是，这套办法在企业里很难规模化。

企业里的每个团队都会运行自己的 Agent，配自己的工具，服务自己的工作流。每条工作流都有很多没说出口的默认假设：哪个数据库是生产库，哪个频道算内部频道，哪个账本正在使用，哪个病人已经完成身份确认。每个写提示词的员工，都要知道这些假设，还要记得在每次、面对每个 Agent 时都写清楚。然后模型变了，供应商更新了系统提示词，Agent 工具箱里又多了一个工具。上个季度还能用的提示词，突然覆盖不了新行为带来的失败模式。那份指令文件要重写。谁来写？谁来审？多少团队要一起改？

提示词工程的答案，有点像要求每个员工都变成厨房台边那个孩子，为一个三明治写 1500 个步骤。可就算写到第 1500 步，孩子也不能确定家长会按他的意思执行。家长读到第 847 步，觉得这次不用照做；读到第 1203 步，又做出一个孩子没想到的解释。一个字面执行者拿着 1500 个步骤，就有 1500 个可能误读的地方。更详细的指令有价值，但不是完整答案。

归根到底，提示词仍然只是建议，我们只能写好提示词，然后祈祷它能照做。无论指令写得多长、多细，都不能保证模型一定遵守你的规则和意图。

制作三明治还讲究顺序

PB&J 练习还告诉我们，很多错误发生在顺序上。先打开袋子，再取出面包；先打开花生酱罐子，再用刀取花生酱；最后把花生酱抹到面包上。顺序很重要。

除了数据泄露和数据破坏，Agent 的失败也可能发生在顺序上。没确认病人身份，就提交用药申请；没检查依赖关系，就移动文件；没重新阅读邮件线程，就直接发邮件；没核验收款人，就执行转账。每个动作本身在正确顺序下都可以成立，放到错误顺序里就会造成伤害。Agent 有权限提交申请，有权限移动文件，也有权限发送邮件。权限本身不是问题，问题在操作顺序。

你可以在提示词里反复强调：“永远先做第 4 步，再做第 35 步！”但 Agent 仍然可能换个顺序，或者直接漏掉某一步。

形式化方法领域很早就在思考顺序问题。“线性时序逻辑”这个术语，说的就是如何推理一组动作序列中的属性。比如，“只有这些前置条件已经发生，这个动作才被允许”；又比如，“这个状态绝不能再次出现”。

无状态授权检查回答的是另一个问题：这个主体现在有没有权限做这个动作？它表达不了上面那两类属性。当前大多数 Agent 护栏，本质上仍是无状态授权检查，所以抓不住这类失败模式。

把顺序编码进护栏，仍然是一个未解决的问题。我们最近花了不少时间研究 Cedar，这个策略语言的核心是无状态的，但它支持实体存储，可以在多轮交互之间携带轨迹状态。也就是说，系统可以随着 Agent 行动不断更新实体属性，让后续调用理解当前状态，从而近似实现状态化授权。这个方法在很多场景下有用，但还不能提供原生的序列推理。大多数授权语言之所以无状态，是因为传统软件里的授权天然是请求-响应模式。Web 应用不需要判断前一次请求是否发生在当前请求之前，Agent 需要。

一个研究方向，是 Xiang 等人在论文《架构安全 AI Agent：关于间接提示词注入攻击系统级防御的观点》中提到的系统级防御：Agent 在调用任何工具之前，先提交一份拟执行动作计划；外部策略引擎先评估整个序列，再允许任何动作真正执行。这样，可被推理的对象就变成了完整计划，而不是一个个孤立动作。

序列问题在生产环境里还没有完全解决，但这类研究会让答案慢慢清晰起来。

修厨房，别只盯着厨师

那么，怎样才能管住这些 Agent，让我们更有把握相信它会遵循我们的意图？

一种办法，是把“常识”继续往模型里塞。用更多数据训练，用更多样例微调，做对齐，把模型包进更复杂的 Agent 执行框架，更仔细地写提示词，然后期待下一代模型足够聪明，能补上这一代模型漏掉的空白。

这条路有必要，但不够。PB&J 练习解释了为什么“写提示词然后祈祷”路线会失败。哪怕你写下 1500 个制作三明治的步骤，家长仍然能跳过其中一步、把顺序弄错，或者误解你的意图。只要控制还停留在自然语言指令层面，就不可能彻底填平这段空白，因为 Agent 会把指令当成建议。

另一半办法，是先假设 Agent 可能理解错、执行错，然后把控制放进它运行的环境里。不要只盯着厨师，要修厨房。

安全工程师都知道最小权限原则：一个进程只应拥有完成工作所需的权限，不多给。Agent 也需要一个对应原则，我称为“最小自治原则”。

即便 Agent 得出结论，认为破坏某个东西是个好主意，它也不应该被允许真的破坏掉。不管 Agent 多么相信自己的推理，它都不应该总能把推理变成行动。最小权限原则说，你只能访问完成任务所需的最低限度资源。最小自治原则说，只要此时此刻、在这个上下文中、针对这些对象、按照这个顺序，你没有得到授权，就不能做。哪怕你再确信这件事有帮助，也不能做。

回到三明治例子。厨房知道，罐子必须先打开，刀才能伸进去。厨房会用机械方式拒绝刀接触未打开的罐子。厨师可以很字面，可以很有创造力，也可以非常确信“砸开罐子更快”。但环境不允许这条路径发生，最后得到的仍然是一个三明治。

对 Agent 来说，这种行为层面的思路意味着，工具必须知道一些 Agent 不知道的东西。提交用药申请的工具必须知道，病人身份必须先确认。移动文件的工具必须知道，它会破坏哪些引用关系。发送邮件的工具必须知道，邮件线程是否已经读过。重点在于让工具更懂 Agent 的行为风险，而不是单纯期待 Agent 变得更聪明。负责执行操作顺序的策略层，应当放在模型之外、上下文窗口之外，具备确定性，并且默认拒绝。

默认拒绝并不等于静默失败。当厨房拒绝某个动作时，更合理的做法通常是把决定交给人：“我正准备删除测试数据库，但无法确认它是否存在生产依赖。是否继续？”Agent 不能自己决定，人来决定。上面提到的那篇《架构安全 Agent》论文也直接表达了这一点：人机交互应当是核心设计考虑，而不是备用方案。

PB&J 指令问题，是我们用来理解非确定性的一个很有人味的例子。既然我们已经开始用自然语言和机器说话，就该认真吸取这个教训。Agent 仍然会像过去一样照字面听话；我们要做的，是确保一句随口说出的“做一个 PB&J 三明治”，不会变成一堂关于语言和意图之间差距的惨痛课程。

写在最后

我对这篇文章核心观点的理解是：在 AGI/ASI 真正到来以前，AI 对提示词的理解，始终可能和人的真实意图存在偏差。偏差不一定来自攻击，也不一定只是模型能力不足，很多时候只是语言、上下文和行动边界没有被系统明确约束。只要 Agent 能调用工具、访问数据、改变外部状态，这种偏差就可能变成未曾预期的后果。

这也是 harness 工程重要的原因。面对由智能驱动的系统，我们不能只把希望押在“让模型更懂人”上，还要在系统层补上约束、验证、权限、顺序和回滚机制。换句话说，目标不只是纠正智能本身，更要把智能放进一个不容易把事情办砸的系统里。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：表图 四楼南侧东 四楼南侧东《[译苑雅集Vol. 9] 没人攻击，AI Agent 也可能把事情办砸》