一次多 Agent 群聊中，主持人同时点名两个机器人并说“早上好”。其中一个机器人回复时，却自称成了另一个机器人。
最先想到的解释通常是 profile 串了、人格文件加载错了，或者会话被污染。但只读核查显示：服务指向正确的 Agent，归档中的 system prompt 也是正确 profile，并没有加载同伴的人格文件。
真正值得注意的变化发生在消息进入模型之前。
🧹 消息清洗改变了句子的主语
群聊框架会移除消息中对当前机器人的 @mention，避免模型把自己的用户名当成正文。这个设计单独看很合理。
但原始消息是同时点名两个机器人：
@AgentA @AgentB 早上好当这条消息交给 AgentB 时，框架移除了 @AgentB，留下：
@AgentA 早上好从模型视角看，这不再是一条“你们两位早上好”，而更像是在对 AgentA 说话。若 AgentB 的 system prompt 只写了职责，没有明确写出自己的姓名、用户名，以及“AgentA 是另一位伙伴”，模型就可能顺着当前输入中的唯一身份锚点回答。
这里的关键不是“模型为什么犯傻”，而是：预处理后的文本已经不是人类发送的那句话。
🔍 排查身份错乱，要看模型实际收到什么
只检查原始 Telegram 消息不够，只检查人格文件也不够。至少要对齐三层证据：
- 原始输入：人类在群里实际发送了什么。
- 框架变换：mention、引用、用户名等内容如何被删除或改写。
- 最终 prompt：模型最后看到了什么身份信息。
如果只看第一层，会觉得“两个人都被清楚地点名了”；只看第三层的 system prompt，又会觉得“profile 没串，不该认错”。真正的误导来自两层之间的文本变换。
这类问题也不能仅凭一次错误回复就断言根因。更稳妥的说法是：服务和 profile 串用已被现有证据排除；清洗后残留的他人用户名，加上自身身份声明不足，是当前最有证据支持的解释，仍需通过对照测试验证。
🪪 职责不是身份
很多 Agent 的人格文件会详细写：
- 负责什么业务；
- 用什么语气；
- 有哪些权限；
- 如何与团队协作。
却没有写最基础的几件事：
我的姓名：AgentB
我的用户名：@AgentB
AgentA 是另一位团队成员，不是我在人机单聊中，这个缺口可能长期不暴露；进入多 Agent 群聊后，别人的名字会频繁出现在上下文里，职责描述无法稳定回答“我是谁”。
因此，多 Agent 的身份声明至少要包含：
- 自己的固定名称和账号标识；
- 主要同伴是谁；
- 不得冒充、代答或继承同伴身份；
- 被多人同时点名时，仍以自己的身份回应。
这不是给 prompt 堆更多设定，而是补齐最小身份主键。
🧪 最小修复之后要做对照验收
比清空历史、重写人格或修改共享框架更稳妥的路径是：
- 只补齐发生误认 Agent 的明确身份；
- 单独点名它问候，验证基本身份；
- 同时点名两个 Agent，复现原场景；
- 分别检查每个 Agent 实际收到的清洗后文本；
- 连续多轮确认没有被错误历史再次带偏。
主持逻辑也可以避免把多个机器人塞进同一句邀请，而是逐个点名分别发送。这样既减少输入歧义，也让每一条回复的验收对象清晰。
✅ 结论
多 Agent 群聊中的身份错乱，不一定是 profile 串用。当框架删除当前 Agent 的 mention，却保留其他 Agent 的 mention 时，预处理本身可能制造一个错误的身份锚点。
排查时不要只看用户原文，要看模型最终收到的文本；设计人格时不要只写职责，要写清楚不可混淆的身份；修复后不要靠一次自报成功，要用单独点名与多人点名做对照验收。
马启航Marvis