先想清楚：为什么是消息通道，而不是又一个 App
做独立 App 最贵的一步从来不是开发，而是让人装它、打开它、记住它。消息通道把这一步直接删掉：用户在 iMessage、WhatsApp、Telegram 或短信里给一个联系人发消息，agent 回消息，交互闭环就成立了。它对使用者的心理成本也低得多——不用学习新界面，只要会打字。
- 省掉的是分发：不需要应用商店审核、不需要引导安装、不需要召回
- 保留的是能力：agent 仍然可以调用工具、查数据库、下单、发通知
- 限制的是界面：没有列表、没有按钮、没有图表，一切都要用文字或图片表达
- 多出来的是状态管理：用户可能隔一天再回一句「那就这个吧」，你得记得上文
能力边界：什么适合放进聊天窗口
判断标准很简单——如果这件事的输入和输出都能用一两句话说完，它就适合；如果需要用户在一屏里对比十几个选项、反复筛选、看图表，聊天窗口就是错的界面。把「浏览与比较」留给网页或 App，把「确认与执行」交给聊天，这条分工目前最稳。
- 适合：查状态、下单、改预约、催进度、订阅提醒、报故障
- 勉强可以：从三五个推荐里选一个（一定要给出选项编号，别让用户自由发挥）
- 不适合：复杂筛选、批量操作、需要看图表做判断的决策
分阶段上线：从只读到会做事
和所有 agent 场景一样，权限要一档一档放。区别在于消息通道的用户更容易产生「它在跟我聊天」的错觉，所以每一步都要明确告诉用户——它现在能做什么、不能做什么。
- 第一阶段：只回答，不改任何数据。目的是验证它能听懂，以及你的知识来源是否准
- 第二阶段：只读你的数据（订单、预约、工单），仍然不改
- 第三阶段：允许它执行低风险动作，比如发送一条通知、生成一份草稿
- 第四阶段：允许它改动数据，但每个动作都要回执，并且可撤销
真正决定体验的是失败路径
消息通道里没有加载条、没有错误页，用户看不到系统状态，只会感受到「它没理我」。所以最该先写的不是能力清单，而是失败路径：听不懂怎么办、超时怎么办、越权请求怎么拒、什么时候转人工。
在聊天窗口里，沉默就是失败；宁可回一句「我没听懂，你可以这样说……」，也不要让对话停在那里。
最后是一条成本提醒：消息通道的「随时可达」是双刃剑。用户会把 agent 当成随叫随到的服务，这意味着你要为消息量付费、要为并发做准备，也要给每条消息的自动回复设上限——否则一次误发就可能变成账单事故。