终端里问一次，回答正常。把机器人拉进群，问题一下变多了：不艾特它就不说话，艾特一次却回两遍；用户补了个链接，它当成新问题；卡片明明点过了，换个人又提交了一次。
这些现象看上去都像“AI 不太聪明”，其实要先拆开检查。消息有没有进来、入口规则有没有放行、分给了哪个角色、工具有没有返回、最后有没有发出去，是五件不同的事。
这一篇接着第三篇的只读查询 Skill，做一张消息行为表和一份群聊接入单。我们借用原交付包的角色隔离、事件去重和反馈约定来解释，但下面的群、人物和消息编号都是教学示例，不是一次已经完成的线上验收。
不回话，先别改提示词
假设同事说：“我没艾特，它怎么不接？”此时不应该立即给提示词加“积极主动”。如果消息在前面的艾特过滤层就被丢掉，后面的模型根本没看见。
按下面的顺序查，每一步只找本次消息对应的记录，不用相近时间的其他运行凑证据。
| 检查位置 | 要拿到的证据 | 这一层有问题时先做什么 |
|---|---|---|
| 平台事件入口 | 目标群的事件是否到达 | 查事件订阅、应用身份、群范围 |
| 入站过滤 | 是否因艾特、发送者类型或白名单被过滤 | 对照配置，不急着放大所有群权限 |
| 角色路由 | 交给哪个角色，是否已经消费 | 核对群与角色映射，阻止通用聊天重复接管 |
| 业务执行 | 使用哪个 Skill、工具结果或停止原因 | 查第三篇的入口和工具约定 |
| 发出与回读 | 平台回执、消息 ID、内容是否可读回 | 区分执行完成和实际送达 |
原交付包特别要求角色处理过的事件不要再落进通用聊天。否则一条消息被两条路径接住，两边都觉得自己该回，结果就是用户收到两份回答。
反过来，如果你只允许艾特触发，就应明确告诉群成员。入口策略不是默认越积极越好，它要匹配这个群的工作方式。
先写一张“什么时候开口”的表
普通群和话题群的消息关系可能不一样。接入前，先请技术同事给你各拿一个真实事件样本，确认怎样识别根消息、后续回复和艾特。不要靠“去掉艾特后文本为空”推断它是一个新问题。
下面是一份客服型群聊的建议行为表。它不是所有群通用的默认值，你需要和业务负责人一起填。
| 情况 | 接收与记录 | 群内动作 |
|---|---|---|
| 允许范围内的新业务话题 | 先保存根消息，再做分类 | 必要时补问或查工具 |
| 同一话题补充链接 | 归到已有记录 | 继续原问题，不重复建单 |
| 只有艾特、没有可定位问题 | 不能凭空生成业务对象 | 根据已有话题判断，缺信息才问 |
| 公告、闲聊、感谢 | 保留必要上下文 | 不机械抢答，不自行确认业务解决 |
| 相同事件再次送达 | 命中处理记录 | 不重复执行同一外部动作 |
| 明确“仅记录，不用回复” | 若授权和规则允许，后台留痕 | 不发确认话术，不额外发卡片 |
这里最容易忽略的是最后一行。回复“收到，不再回复”，本身已经回复了。静默不是一种语气，是需要明确控制的输出行为。
如果后台动作失败又必须告知负责人，应在事先约定的管理渠道报告，不把“用户让静默”理解成可以把失败藏起来。没有这种渠道时，先把运维规则补齐。
四个编号，别都叫“会话 ID”
为了让技术同事能真正落地，我们至少要区分下面四种东西。字段名可以不同，含义不能混。
| 标识 | 回答什么问题 | 常见误用 |
|---|---|---|
| 事件 ID | 这次平台投递是否已经处理过 | 把不同事件都按文本去重 |
| 根消息 / 话题 ID | 这条补充属于哪个业务上下文 | 把时间接近的两条消息拼在一起 |
| 回复消息 ID | 用户反馈的是机器人哪条回答 | 只按“最后一条回复”猜 |
| Trace ID | 哪次 Agent 执行产生了这条回复 | 用相近时间的另一条运行记录解释 |
举个模拟例子：话题 topic-A 中有事件 event-1，机器人回复 reply-1，对应运行 trace-1。用户点这张回复的反馈卡，就要沿着这条已保存的映射找回 trace-1。不能因为 trace-2 更新，就把评分写到后者。
去重记录也不能只放在模型记忆里。服务重启后仍要知道哪些事件已经接收、哪些动作已经发出、哪些处于结果未知。持久化状态和并发条件更新是控制程序的工作，不是让提示词写一句“注意不要重复”。
服务端还应验证回调人是否有权操作、卡片是否属于这个话题、消息是否属于当前应用。回调带来的编号是输入，不是凭证。
同一个机器人，可以有不同的岗位纪律
原方案里有客服、专业助手和 PMO 三类角色。公开讲这三类角色，是为了说明规则不能一锅端，不是要求读者一次做齐。
客服侧，重点是问题有没有被收齐、当前谁接手、状态有没有依据。普通转人工不顺手附送持续催办，也不因为对方说“谢谢”就关单。一个话题里有多个子问题时，需要区分它们，不能用一条“已解决”把全部问题盖住。
专业助手侧，重点是回答质量以及用户对这次回答的反馈。原包的反馈规则是：“已解决”一键提交；“部分解决”“未解决”可以补充原因和说明，原因是选填。首次成功提交后锁定，防止多人点击覆盖。这里不要套用另一套客服终态规则，把可选反馈突然变成强制表单。
用户反馈和模型评价也要分开保存。用户点“没解决”是用户意见；模型说“引用不充分”是模型判断。两者可以一起帮助改进，但不能混成一个不知道谁打的分。
PMO 侧，重点又变了。它要解释交付推进到哪、验收或发布卡在哪里、需要谁处理。任务数量多，不等于工作量大；今天显示“开发中”，不等于今天刚进入开发；没有工作日、请假和剩余工时数据，就不要硬算容量风险。
如果你是第一次做，先选一个角色、一个测试群、一种只读场景。三种角色可以共享基础能力，但发送范围和行为规则分别验收。
这份接入单，交给技术比一句“接飞书”有用
【群聊接入单】
业务角色与负责人：
目标环境 / 应用 / Profile，不填密钥：
允许的测试群和发送者范围：
接收哪些事件类型：
是否必须艾特；新话题如何识别：
根消息与后续回复的关联方式：
允许调用的 Skill 与只读工具：
事件消费后，怎样阻止其他处理器重复响应：
去重键 / 保存位置 / 保留周期：
回复消息与 Trace 的映射如何保存：
静默指令怎样控制所有对外输出：
回调权限、卡片归属和首次提交锁定方式：
发出成功、失败、未知分别怎样记录：
测试群通过后，谁批准扩大范围：
故障开关与回退负责人：
应用、Profile 和机器人身份要一起核对。配置看着相似，不代表是同一个应用；同一个应用也不要随意再起一套并行事件消费者。否则测试代码和现有服务可能同时抢消息或重复处理。
接入单里有一项填不出来，不用为了完整写“已完成”。比如暂时没有真实回复到 Trace 的映射，就写待接入，先停止这条自动评分链路。
在测试群里，故意把它弄乱一次
单人按顺序发三条消息，几乎测不出边界问题。真正要练的是下面这些情况。先用脱敏、合成数据桌面推演，再由获授权的同事在限定测试群执行。
| 演练 | 通过标准 |
|---|---|
| 两个话题同时补链接 | 各归各，不借用另一个话题的对象 |
| 同一事件重复投递 | 不多建单、不多发同一条通知 |
| 两个人同时点反馈 | 只有一次成功提交，其余得到一致状态 |
| 旧卡片或跨话题回调 | 服务端拒绝错误归属，不污染记录 |
| 工具超时后用户追问 | 明确本次没查到，不假装已有结果 |
| 明确要求静默 | 后台留痕与群内无新增输出同时满足 |
| 发送后进程中断 | 标记未知并核对，不直接再发一条 |
把实际收到的事件、处理记录、工具轨迹和发出回执放在同一份测试记录里。只截一张群里“回复看起来没问题”的图，不足以证明没有重复副作用。
走到这里，这个员工才有了基本的群聊纪律：知道该接谁、接哪件事、什么时候不说话、失败后找谁。下一篇把这些东西装进交付包，检查换个人、换环境之后还能不能说清楚。