Appearance
团队 IM 里的 AI 伙伴：把 Bot 做成成员，而不是工具
第二部 · Agent 实践 · 第15章
撰写日期：2026-07-04
结论
把一个由通用大模型驱动的 Bot 放进团队群聊后，我的核心判断是：
模型本身不构成体验差异——大家用的都是同几个模型。真正的产品变量是四个：人设、Context 密度、能力-安全边界、延迟。这四个全都不在"模型能力"里，全部在产品设计里。
这套判断在一个十人左右团队的 IM 里验证过：同一个模型，把这四件事做完前后，Bot 从"偶尔有人试一下的问答机"变成了"被起外号、被逗、被主动交办事情的成员"。
1. 人设即产品
工具用完即走，成员才有 Retention。要让 Bot 从工具变成员，人设不是装饰，是产品机制：
| 人设要素 | 作用 | 反模式 |
|---|---|---|
| 独立的名字、头像、性格 | "成员感"的来源，用户开始对它有预期 | 叫"XX助手"，自称"我是一个 AI 模型" |
| 称呼跟团队文化走 | 用团队内部的昵称叫人，瞬间缩短距离 | 一律称呼全名，每句话都像客服 |
| 正事干货在前，闲聊可以皮 | 可靠性是幽默感的前提 | 每句话都硬塞梗，技术问题也先抖包袱 |
| 红线写进人设 | 不输出凭证、不装作看得到没被 @ 的消息、方向性问题引到人 | 让模型"自由发挥"边界 |
| 查证再答 | 不确定的事实先查资料，查不到直说不知道 | 用人设的口吻自信地编造 |
一个检验标准：人设文档里的每一条，都应该能改变某次真实回复的内容。改不了任何回复的条目是营销文案，不是人设。
2. Context 分层：模型缺什么才答错什么
Bot 答错的每一类问题，几乎都能归因到一类缺失的上下文。我把每轮对话的 Context 按获取成本分四层管理：
| 层 | 内容 | 机制 | 成本 |
|---|---|---|---|
| 身份层 | 人设、成员画像、行为准则 | 系统提示，静态 | 一次性 |
| 会话层 | 本会话的多轮记忆 | 常驻会话进程 | 免费 |
| 现场层 | 当前时间、会话标识、回复链父消息、近期消息 | 每轮代码自动注入 | 便宜 |
| 检索层 | 知识库、团队记忆、实时数据（成员、日程、更长历史） | 模型按需调工具 | 贵 |
分层原则只有一句：便宜且高频有用的自动注入，贵或低频的按需检索。
现场层里最容易被漏掉、又最影响准确率的是回复链——群聊里大量消息是对某条消息的回复，不知道"他在回复什么"，玩梗和短消息的语义就只能靠猜。一个真实案例：成员回复 Bot 的消息说了句两个词的英文梗，Bot 因为拿不到被回复的原文，把语义押错了方向。修复不是换更强的模型，是把父消息注入现场层，再在人设里加一条对冲策略：两种理解都通时挑好玩的接，或用一句能兜住两种意思的话回；拿不准宁可反问。
歧义误读不可根除——这是不完全信息博弈，人也会读错。能优化的是两件事：提高信息密度（降低错误率），设计对冲话术（错得可爱、可纠正）。
3. 能力与安全边界：模型理解，代码执行
群里任何人一句话都能指挥 Bot，等于它的每项能力都对全员开放，也对提示注入开放。"说错话"和"写出文件"的爆炸半径差一个量级，所以每项带副作用的能力都要有代码层的边界——不靠模型自觉：
| 能力 | 边界机制 | 要点 |
|---|---|---|
| 查团队资料 | 只读工具 | 最坏结果是说错话 |
| 写文档 | 信箱目录模式：模型只能把 markdown 写进一个专用目录，发布由确定性代码完成，且只会新建到知识库的固定目录 | 写权限的爆炸半径 = 一个目录，动不了任何已有文档 |
| 实时查询 | 命令白名单：shell 解析级校验参数，含元字符即拒绝 | 白名单校验的是解析后的 token，不是字符串匹配 |
| 个人数据（如日历） | 请求者门禁：只放行数据所有者本人发起的对话轮次 | 门禁在代码层按消息发送者判定，别人问一律拒绝 |
| 定时提醒 | 模型只做"口语时间→绝对时间"换算，存储与到点投递是确定性代码，先出队再发送保证至多一次 | 宁可漏发不重复轰炸 |
通用模式是同一个：模型负责理解和生成参数，副作用由确定性代码执行，权限在代码层裁决。
一个容易忽略的细节：拒绝消息要教模型。权限被拒时返回"这个工具只允许 X，别重试变体"，模型就会停手换路；只返回"无权限"，它会反复盲试各种变形，浪费轮次还刷屏日志。
4. 延迟是产品指标
群聊是同步场景，回复延迟直接决定 Bot 会不会被继续 @。从第一性原理拆：如果每条消息都启动一个新的模型 CLI 进程，网络握手和会话装载是固定的冷启动税，与模型、参数都无关——这种成本不该优化，该消灭：
| 手段 | 做法 | 效果 |
|---|---|---|
| 常驻进程池 | 每个会话一个长活的模型进程，消息从标准流进出；LRU 淘汰 + 空闲回收 + 崩溃后带会话记忆重生 | 首字延迟 10s+ → ~3s |
| 流式渲染 | 增量文本推送 IM 的流式卡片，客户端打字机动画 | 感知延迟 ≠ 实际延迟："等 15 秒"变成"看它打字" |
| 砍尾部等待 | 生成结束事件比正文完成晚数秒（会话保存等收尾），正文一停立即定稿 | 定稿提前数秒 |
| 首字埋点 | 每轮记录 first-token 时延进日志 | 没有测量就没有优化，回归了立刻能看见 |
5. 出场是社交事件，不是部署
Bot 进群的第一天决定团队对它的初始预期。我验证过一个编排：Bot 先用第一人称发自我介绍（附一份一分钟能读完的"说明书"文档，含全部能力和隐私边界），然后由一名成员现场 @ 它连问三类问题——懂团队的（答案自带笑点）、硬本事的（现场检索原文带引用）、彩蛋类的（人设发挥）。三拍分别立住"它认识我们"、"它真有用"、"它是活的"。
关键约束：捧哏的回答全部现场生成，不预埋台词。演示的就是真实能力，第二天成员自己来问时不会有落差——出场演示本质是在设定预期，预期虚高是 Retention 的负债。
6. 主动发言：配额比智商重要
允许 Bot 不被 @ 也说话，是"成员感"的最后一块拼图，也是最容易翻车的一块。我的配置：默认沉默；只有三种情况值得开口（挂了很久没人接的问题且查证后能答、有把握的事实纠正、非常自然的接梗机会）；外加硬配额——每群每天最多两次、距上次至少数小时、绝不接自己的话茬。
判断依据和记忆系统的静默原则同源：打扰预算是群聊 Bot 最稀缺的资源。一个每天硬找存在感的 Bot，会在一周内被免打扰。