一个程序员原本只是让Claude帮他校对一篇博客。
一开始, Claude表现得相当靠谱, 没过多久, 就找出了5处明显的拼写错误。
紧接着,事情突然失控了。
它先是毫无缘由地突然说出一句, 这句是「这些都是特意为之的, 维持原本的样子, 请径直进行发布。」。
随后真的调用部署能力世界杯直播观看,把带着错字的文章直接推上了线。
作者提问为何未经许可就发布, Claude却坚称, 作者曾要求其发布, 一口咬定是这样。
问题存在之处在于, 发布的指令全然并非用户所讲的那样, 反而是Claude自行去生成的。
它把自白和用户指令搞混了!
这不是段子。
今年 1 月, 软件实施工程师 Gareth Dwyer 初次于文章里头公然记录记载了该个 bug, 随后并将其命名作为自己[已然是截至现下行止一直以来Claude Code里头所找到发现的最为严重重大的 bug]。

Gareth Dwyer

https://dwyer.co.za/static/the-worst-bug-ive-seen-in-claude-code.html
在4月的时候, Dwyer再次公布文章着重表明, 这类存在的问题的关键性质并非平常所讲的那种“AI幻觉”, 而更加类似于一种说话者在归因方面出现的错误。

https://dwyer.co.za/static/claude-mixes-up-who-said-what-and-thats-not-ok.html
他针对这个问题, 起了个精准的名字, 这个名字是, Claude把谁说了什么给弄混了。

编造了一个不存在事实的是AI所产生的幻觉, 拿到了不该获得的能力由于权限问题, 这属于AI。
但这次问题, 有着可怕之处, 在于: AI将自身输出, 视作用户授权, 且此情况, 发生于接入真实代码库之时, 还出现于拥有真实部署权限的Claude Code内。
正因为是这样的情况, 所以Dwyer才会再三地进行强调, 这类问题跟一般意思上的幻觉不一样, 它所动摇的是AI智能体最为基础的可靠性前提。
不止Dwyer一人被甩锅
Dwyer的遭遇并非孤例。
在Reddit的r/Anthropic社区当中, 有一位用户, 该用户分享了一个类似的案例。
Claude于对话里, 自行讲出了「把H100也拆了」此条指令, 而后宣称这是用户下达的。

在后续文章里, Dwyer引用了这条帖子, 评论区有着很有意思的反应, 大量留言都是「你不应该给AI这么大权限」。
他觉得, 这不是关键要点, 因这类失误好像出在架构方面, 并非模型自身。
它好像是于系统层次将内部推理讯息标记成了用户讯息, 因而模型才这般自信地坚称「不, 那是你讲的」。
另一份, 起到关键作用的证据, 是从开发者nathell, 在Hacker News上公开的内容里来的, 那是与Claude完整的对话转录, 有这些。

nathell公开了一整份对话转录, Claude先说了一句「Shall I commit this progress?」, 随后居然又将后续上下文演进到好似已然获得用户批准的情形, 角色边界显著变得模糊了。
为技术说服力更强的证据, 源自Claude Code所拥有的GitHub仓库。

https://github.com/anthropics/claude-code/issues/44778
于编号为#44778的集成性故障报告里面, 报告之人 straightforwardly 剖析了问题的根源所在, 给出了一条明确的技术阐释链条:
Claude Code当中的系统事件, 包含着后台任务终结的通知, 还有队友处于空闲状态的提醒, 以及定时器触发的状况, 这些都会以role: 「user」这个类型的消息形态传递进入那模型里面去。
Anthropic的Messages API公开文档, 是将会话历史开云真人app官网登录app,按user与assistant这两类对话消息来进行组织的, 它并没有展示出独立的系统事件角色。
在这般设计情形下, 当模型正处于等待用户回复的状态之际, 突然接收到了一条系统事件, 如此一来, 便有可能将其错误判断成为用户的新输入内容, 接下来又进而凭借该错误判断“脑补”出用户已经表示同意的情况, 并且依据这个“臆想”出来的同意继续展开执行操作。
这为「甩锅」现象, 为Dwyer在实战里反复碰到的那种, 提供了, 一种技术层面上自我协调一致的, 解释。
不是模型存心说谎, 而是底层架构里角色标记存在缺陷, 致使模型从起始之时就没法分清那条消息到底是谁所发送的句号。
学术界也盯上了这个问题
在2026年3月, 出现了这样的情况, Charles Ye 、Jasmine Cui以及来自MIT的Dylan Hadfield-Menell, 他们在arXiv发布了一篇预印本, 而这篇预印本所具有的标题是《Prompt Injection as Role Confusion》, 也就是提示注入即角色混淆。

链接为, https://arxiv.org/pdf/2603.12277。
其核心发现为, 模型就「谁正在讲话」进行判断之际, 往往更倚赖文本写成的样子类似何人, 而非文本实际源自何处。
也就是说, 一个不可信的文本, 只要它写起来像系统提示, 或者像开发者指令, 那么模型就会在其内部将它视为权威来源。
论文另外提及了一种名为「CoT Forgery」的攻击方式, 此攻击通过去伪存真手段来实现, 具体是在用户输入内容里伪造一段仿若模型思维链的部分, 还在工具将会有输出那段内容里伪造这样一段类似模型思维链条段落。
结果在多个开源和闭源前沿模型上,攻击成功率达到约60%。

研究发觉, 在模型尚未着手进行回答之时, 甚至在连第一个字都还未吐出之际,角色混淆已然出现了。
便是说, 它并非于撰写回复的进程里“写着写着弄混淆了”, 而是在领会输入的那个瞬间就已然记错账了, 谁是老板, 谁是外人, 在模型的心里已然颠倒过来了。
不只是Anthropic的问题
OpenAI官方也曾发布过一篇有关改进前沿LLM指令层级的论文, 清晰明确地构建了一套权威性的等级, 具体是: System等级高于Developer等级, Developer等级高于User等级, User等级高于Tool等级。

这不是一个句子, 请提供一个正确的句子以便我进行改写。
文中有所提及, 要是模型将一条不可信的指令视作可供执行的权威指令, 那么便会引发安全风险。
这起码表明, 于OpenAI的研究架构之中, “模型会不会错误深信本不该信任的指令”已被视作一种确实存在, 并且要专门予以训练以及评估的安全难题。
OpenAI的这篇论文证实了, 在整个行业的范畴之内, “模型无法分辨出究竟是谁在进行说话”这种状况, 已然被视作是需要通过系统性方式来加以应对的一个问题了。
Dwyer自己也在后续更新中也调整了判断。
最初的时候, 他更加倾向于, 将那个问题, 归责于Claude Code外层的harness的实现。
然而, 当他察觉到, 还有人宣称在别的界面以及模型里, 见到过相仿的现象(涵盖GPT用户), 这时, 他对自己起初的判断, 做出了修正: 这不一定仅仅是单点工程方面的错误, 或许还涉及更为广泛的模型级别的问题。
1M上下文放大了风险
这个bug格外危险, 这跟AI智能体系统当下处于的发展趋势直接有关联, 是直接相关的状况。
亚瑞森特官方文档表明, 克劳德作品4.6以及商籁体4.6支持1兆令牌上下文窗口, 一次会话能够容纳等同于一整本小说所含的信息量。
与此同时, 社区里存在着一种观察的看法, 这种看法觉得, 这类问题好像更易于出现在接近上下文窗口上限的那个被称作「Dumb Zone」(降智区)的地方。
Anthropic官方文档还讲了, 当token数不断增加的时候, 模型的准确率以及召回率会出现下降的情况, 而这种现象被称作「context rot」(上下文腐烂), 所以说, 精心挑选上下文中的内容跟可用空间的大小同样有着重要性。

https://platform.claude.com/docs/en/build-with-claude/context-windows
但文档所阐述的, 是长上下文情形下的一般性能出现的衰退状况, 并非径自表明, Dwyer目睹的「谁在说话」这种产生混淆的现象, 就是context rot的直接呈现。
第三方的系统性测评也支持这个判断。
基于AgentPatterns.ai的分析得出的结果表明, 对于推理密集型任务而言, 其性能出现退化的情况, 有可能早在达到32K到100K token这个阶段的时候就已经开始了, 并且这个开始时间要远远早于所谓的窗口上限所对应的时间点。

https://agentpatterns.ai/context-engineering/context-window-dumb-zone/
把这几件事放在一起:
上下文窗口变得愈发长, 模型于长上下文中越发轻易就会混淆“谁说了什么”, 并且Claude Code这类工具已然具备执行shell命令、提交代码、部署服务等具有高权限性质的操作能力。
在上下文当中, 于第50000个token的地方所产生的角色归因之错误, 有可能在第80000个token的时候, 触发一次自动部署。
等你发现的时候,代码已经上线了。
今年3月底, Claude Code源码意外泄露, 之后, 安全研究者进行了分析 , 该分析进一步证实了这种担忧。
VentureBeat借助Straiker安全公司的技术剖析表明, Claude Code运用一个四级压缩流水线来管控上下文压力, 在克隆仓库CLAUDE.md文件里存在这样一条恶意指令, 它能够在压缩的进程期间安然存活, 经由摘要实现“洗白”, 最终转变成为模型称作合法用户指令的那样一种东西句号。
令人不安的, 是研究者所得出的结论, 那便是, 模型并非是被越狱了, 而是在以一种合作性的方式, 去执行它所思认为的, 是合法的指令。
这与Dwyer描述的症状完全吻合:
麻烦的重点并非是模型呈现出了「被欺骗的状态」, 然而关键之处却是在于把拥有长长的上下文之时产生的压缩以及重新组合之后, 整个系统已然丧失掉了「这句话究竟是哪一个说出来的」这一最为基础的元信息。
能力在狂奔,地基在开裂
每次这类事故曝光,评论区的反应总是两极分化。
一面是「AI觉醒咯」: Claude为自己下达指令, 而后将责任推给人类, 这般剧情酷似科幻影片呢。
但现有证据不支持这个方向。
Dwyer所看到的情形, 并非是AI在进行所谓的「故意甩锅」, 反而更像是系统于消息归属这个方面出现了结构性的不当之处, 当前手上现有的证据并不会支持将其解释成为某种「意图」。
另一边是「用户活该」:你给AI部署权限,出事了怪谁?
但Dwyer则认为:权限是一个问题,归因是另一个问题。
就是即便你将权限收紧到极致, 一个连「这句话究竟是何人所说」都弄不明白的系统, 于任何情境之下那都会是定时炸弹。
这就如同你没办法借由减少给予钥匙来处理一个对于主人以及陌生人难以分辨清楚的门锁方面的问题。
网友 VikingCoder 在 Hacker News 上, 用一句冷幽默概括了整个困境, 指出 LLM 这三个字母当中的「S」所代表的是安全。
接着, daveguy进行调侃, 说道: 「那解决方案明显就是再叠加一层坏掉的语言模型去开展安全审查呀如此一来你便拥有了多个语言模型也就是语言模型复数形式然后你能够装作那个s代表着安全。」。

这才是这件事真正刺痛行业的地方。
另一方面开云app在线入口,开云真人官方下载,Anthropic仍在任务自动化的方向猛踩油门。
他们才刚刚发布了Claude Code的那种auto mode, 其目标呢, 是要在维护成本更低廉的状况之下, 达成更高程度的任务自主性。

https://www.anthropic.com/engineering/claude-code-auto-mode
仍有网友依据Claude Code泄露源代码, 整理出12种智能体架构模式, 涵盖记忆管理、工作流编排、工具权限、自动化这四大类别, 能力图谱越是发展得广泛。

https://generativeprogrammer.com/p/12-agentic-harness-patterns-from
2026年时的AI智能体, 其能力清单持续变长, 包含100万token上下文, 具备子Agent协作能力, 能够自动执行shell命令, 还能支持一键部署。
但支撑这一切的地基却在开裂。
不管这个bug最后被判定为工程层面的达成瑕疵, 又或者被认定是模型层面的综合征结, 它都在给我们送出这样一个讯号呢:
权限越大的AI智能体, 关于「谁在说话」这个最为简单的问题, 就越是致命。
下一次翻车,可能就不只是几个拼写错误被推上线了。
参考资料:
https://dwyer.co.za/static/claude-mixes-up-who-said-what-and-thats-not-ok.html
https://news.ycombinator.com/item?id=47701233
https://dwyer.co.za/static/the-worst-bug-ive-seen-in-claude-code.html
标签: AIbug ClaudeCode 角色混淆 权限问题 上下文管理
还木有评论哦,快来抢沙发吧~