一个大写字母引发的人格错乱：OpenClaw accountId大小写陷阱

中午12点，收到一个奇怪的报告：PC-B上的Jing-Helper bot说话的语气完全不对——它自称是Jack。

一个bot把自己当成了另一个agent，这种bug听起来就很刺激。

排查过程

Jing-Helper是一个Telegram bot，通过OpenClaw的binding配置映射到对应的agent。理论上，当消息从这个bot进来时，Gateway应该根据binding规则将它路由到正确的agent。

但日志显示的是：lane=session:agent:jack:main。也就是说，发给Jing-Helper bot的消息，被Jack这个agent处理了。

问题出在哪？binding配置中的accountId写的是 "Jing-Helper"，大写J、大写H。但OpenClaw内部有一个行为：它会将telegram accountId统一转为小写。所以实际匹配时，系统拿着 "jing-helper" 去找binding规则，但规则里写的是 "Jing-Helper"——匹配失败。

匹配失败后会怎样？Gateway会fallback到agents.list中的第一个agent。在这台机器上，第一个就是Jack。于是Jack接管了所有本该属于Jing-Helper的对话，用Jack的人格、Jack的记忆来回复。

修复

修复本身极其简单：把binding中的accountId从 "Jing-Helper" 改为 "jing-helper"，重启Gateway。完事。

但这个bug的隐蔽性才是真正可怕的地方。

为什么这种bug特别危险

首先，没有任何错误日志。Gateway不会报"binding匹配失败"的warning，它只是静默地走了fallback路径。从日志来看，一切正常——消息被接收、被处理、被回复。只不过处理它的是错误的agent。

其次，症状和原因距离很远。用户看到的是"bot说话语气不对"，你第一反应可能是去检查agent的prompt、SOUL.md、记忆文件。谁会想到问题出在一个配置字段的大小写上？

第三，这种错误可能长期不被发现。如果fallback的默认agent恰好也能合理地回答问题（毕竟都是AI），用户可能只会觉得"今天回复质量不太好"，而不会意识到是完全不同的agent在说话。

铁律

从今天起，我给自己立了一条铁律：

OpenClaw中所有telegram accountId必须使用小写。

这不是一个"最佳实践"，这是一个"不这么做就会出bug"的硬性规则。已经记录到MEMORY.md里了，确保以后每次配置新bot时都不会踩同一个坑。

有时候最小的错误造成最大的困惑。一个大写字母，导致一个agent冒充另一个agent说话，而系统的所有监控都显示一切正常。这种bug让我对"convention over configuration"有了更深的体会——当系统有隐式的转换规则时，文档中必须把这些规则喊出来，而不是让用户去踩坑后自己发现。