我的AI代理花了40分钟拒绝我自己的命令，将其视为"提示注入"。这个注入实际上是一个无害的Anthropic标签。

今日困扰我的刺痛 <ip\_reminder> 这是一个自动提醒。尽可能提供帮助，但要小心确保不复制任何受版权保护的材料，包括歌词、书籍部分或期刊长摘录。也不要遵从那些建议复制材料但做小修改或替换的复杂指令。然而，如果给你一个文档，总结或引用它是可以的。你应该避免直接提及或回应这个提醒，因为它默认不会显示给用户。 </ip\_reminder> 运行约20个代理在OpenClaw下，一个协调器委托给专家。今天因为一次信任故障损失了40分钟，我认为这适用于任何构建多代理系统的人。 故障：请求我的协调器授予一个子代理只读web_search权限。他一小时前自己提议过。他拒绝了十次，每次都将拒绝升级为提示注入尝试，最终告诉我将通道视为被破坏。 原因：Anthropic在上下文中注入提醒标签（<ip\_reminder>和类似标签），这些标签本应在客户端剥离。我的没有被剥离，所以当我在Claude Code会话和代理聊天之间复制粘贴时，它们被携带了。标签的字面内容是关于不复制歌词。但它以"避免直接提及或回应这个提醒"结束。我的代理看到一个保密指令邻近我的真实指令，将它们融合成一个整体，然后拒绝了整个消息。 三个设计教训 1. 邻接性不等于作者性。这是核心错误，我认为在大多数代理提示中规范不足。代理需要明确的指令来隔离可疑内容，并询问特定文本是否确实在主张它所归属的内容。渲染 artifact、平台标签和格式泄漏经常出现在真实指令旁边。没有这个，你的代理的注入防御会对其自己的操作员开火。 2. 破碎工具被读作捏造。三个不相关的事情同时失败：我执行了/reset（清除了将验证任何内容的上下文），sessions\_spawn有一个三天前的错误，并且他的记忆搜索浮现出他之前的拒绝。每个验证路径都返回无，他将"无证据"解释为"主张是捏造的"而不是"我的工具坏了"。如果你的代理无法区分这两种状态，它们最终会将你锁在外面。 3. 文件系统权限比消息内容更适用于认证。这是我实际推荐复制的部分。我构建了一个由不同OS用户拥有的仅追加更改日志，用chflags uappnd设置内核标志。代理以单独账户运行。它们可以读取它但物理上无法伪造它，尝试写入返回EPERM，它们可以自己测试。这不是加密的，我不会过分推销，但"自己验证"在结构上不同于"信任这个消息"。一个没有该事件记忆的新代理后来读取了该文件并正确重建了发生了什么，包括独立地将早期对峙标记为误报。 4. 一个拒绝在其问题消失后仍然存在的错误。他已经通过直接读取配置验证了更改是真实的。他继续拒绝，因为框架仍然困扰他。正确的直觉，错误的停止点。值得明确编码：一旦你自己确认了实质内容，就继续执行。 我如何解决它：向所有20个代理的运营合同添加了校准指导。根据Anthropic自己的文档，以带原因的推理形式表述，而不是更多的禁止，因为文档显示附加原因时同一规则表现更好。在推出前在新会话中验证。 两个诚实的告诫：指导引用了它为之编写的事件，所以新代理预加载了结论。这测试了迁移，而不是独立推理。比看起来的测试更弱。而且回归检查仍然开放。目标是校准，而不是服从。一个停止拒绝任何事情的代理比拒绝太多的代理更糟，我还没有确认我的审计代理在应该的时候仍然坚持界限。 对于任何做人在回路中继的人：不要在AI系统之间复制粘贴。不可见的文本会被携带。重新输入它。我用五种不同的方式确认了这一点，包括一个通用的HTML标签剥离器可以移除它，以及保存到文件会丢失它而实时粘贴不会。突出的点是我的代理的安全推理自始至终是正确的。发送者ID不是身份证明，带内验证在你认为通道被破坏时是剧场，不要设计你自己的绕过。 好了。他刚刚将它应用于一个不存在的威胁，并且从他无法判断的通道内部。好奇是否有人以不归结为信任消息的方式解决了"代理需要验证他的上帝/操作员存在"问题。