背景
OpenClaw、Feishu、memory、hook 和交付链路同时在跑时，用户感知到的是一个整体服务，而不是底层很多独立组件。
服务恢复案例
OpenClaw / Feishu 服务恢复地图
把一句“它不靠谱”拆成 memory、路由、上下文、交付和回执五层工程问题，让复杂 agent 服务能按层修复。
问题
当 memory 读不回、群消息没路由到正确 agent、引用上下文不完整、交付链接还是旧内容、/done 写入后又没有回执时，用户只会得到一个结论：系统不可靠。
证据
- 问题地图明确收敛出至少五类故障：空 memory index、错误路由、quoted body 缺失、假完成交付、auth 或 ack 状态漂移。
- 文档把“没回复”继续拆成没写入、写入了但没 ack、以及 ack 发送失败三种不同状态。
- 修复顺序被重新排成 P0 / P1 / P2，而不是继续靠聊天记录回忆问题。
设计动作
- 按用户可感知的症状，把问题拆成 memory、routing、context、delivery、permissions 五层，并分别定义证据与验收。
- 把关键入口如 /done、/task 从多代理试探链路里前置短路到正确 intake，减少被 prefix 规则吞掉的情况。
- 为交付型结果补上 domain、内容新鲜度、回执与恢复路径的验收条件，不再把“能打开一个链接”当成完成。
结果
服务恢复从“模糊不可信”变成可诊断、可验收、可分层修复的工程问题，也更适合作为 agent 服务设计案例公开说明。
公开边界
公开的是故障分类、恢复方法和验收思路，不公开私有日志全文、账号配置、token 或用户敏感对话。