新增 Pipecat Flows 兼容性 spike 结论

交接文档规定"未经 spike 结论，不进入 Phase 3"。本次完成 Phase 1 spike，
7 项验证全部通过，并给出可进入 Phase 2 的结论。

新增 P1-Flows兼容性Spike结论.md

核心结论：
- **不装 pipecat-ai-flows**。Pipecat 1.10 内置 Flows（pipecat.flows），
  装独立包会报错提示卸载；独立包 1.4.0 会把 pipecat 降到 1.4.0
- **复用 DeepSeekLLMService**，不写 FallbackProvider 适配器。它自带
  DeepSeekLLMAdapter 处理 reasoning_content 回传（P0 踩过的坑），
  thinking 默认 disabled。代价是失去本地 vLLM 降级
- 实测：中文流式 14–22 块/回复、工具参数无重复拼接、回灌后出最终回答、
  worker.cancel() 立即终止、role_message 生效

定位了 5 个坑（4 个 Flows 相关 + 1 个环境）：
1. FlowManager.initialize 是协程但签名显示 -> None，漏 await 静默失效，
   role_message/task_messages/工具全部不生效而 LLM 照样回复，极易误判
2. 必须用 PipelineRunner 跑 worker；直接 run() 会让工具执行失败，
   异常被转成通用错误串，handler 从不执行，默认日志看不到
3. respond_immediately 默认 True，initialize 会立刻触发一轮回复，
   做归因测试时不清空观察窗口会归因错
4. role_message 与 task_messages 各产生一条 system 消息，
   两者不要同时用（切回本地 vLLM 时会 400）
5. NLTK punkt_tab 本地也需预装，否则 setup 超时卡住

对现有功能的影响：分句 TTS、RTVI、记忆身份不受影响；
SearXNG 工具需迁移；本地 vLLM fallback 会失去。
第四节给出 Phase 3 的最小生产集成 diff 要点。

有趣的项目/AI桌面陪伴助手/AI桌面陪伴助手方案.md

@@ -396,13 +396,15 @@ P5通过Home Assistant统一调用。按实际设备比较官方Xiaomi Home和Xi
 
 ## 10. 运行维护与当前下一步
 
-### 已完成（截至 2026-09-15）
+### 已完成（截至 2026-09-16）
 
 - Ubuntu 24.04 已确认，USB 接口已盘点；依赖版本固定在代码仓库的 `requirements.txt`
 - 助手本体在服务器上实现并跑通，端到端测试 16/16（**用文件音频，非实时链路**）
 - STT/TTS/LLM 三方基准实测；DeepSeek 四条路径验证
 - 记忆与身份的数据层实现并测试（88 项断言）
 - 代码剥离为独立仓库 `~/workspace/ai-companion/`
+- 网页文字与语音对话、助手文字显示、DeepSeek Function Calling + 私有 SearXNG 已部署
+- 姓名档案跨连接恢复已修复；内部 user_id 与用户称呼隔离
 
 ### 下一步顺序（按风险从高到低）
 
@@ -417,6 +419,7 @@ Pipecat Playground 做了真人浏览器对话，麦克风 → STT → LLM → T
 | 0 | **音频边界定稿** | ✅ 2026-09-15 完成（见 §5） | 决定了客户端接口形态 |
 | 1 | **服务端 WebRTC 入口 + 客户端骨架** | ✅ **实时链路已闭环**（见 `P0-Pipecat传输层实验报告.md`） | 已验证：信令、ICE、data channel、帧路由、STT→LLM→TTS、文件与浏览器真人非静音回复 |
 | 1b | **查清帧路由根因 → 定 A/B 方案** | ✅ **根因已定位，采用 A 方案** | NLTK 运行时下载导致 setup timeout；不是模型不兼容。网页 RTVI 保留 |
+| 1c | **Agent 与通用记忆工具化** | 🟡 **已选 Pipecat Flows，待兼容性 spike** | 保留现有实时链路与 MemoryStore；先文字、后语音，legacy 可回滚。见 `P1-Pipecat Flows Agent化与记忆改造交接.md` |
 | 2 | **N5095 客户端骨架** | 🔶 雏形已有（`client/test_client.py`） | 非 trickle ICE、data channel 心跳、文件音频实时发送、回复录音都已实现。**不做 AEC/播客参考/打断**——那些要真实声卡 |
 | 3 | **接入真实麦克风与音箱** | 阻塞：硬件未购；网页仅验证普通麦克风对话 | 唯一能完整验证阵列 AEC、打断、本地唤醒的一步，也是 P2 的全部内容 |
 | 4 | **STT 中文识别正确率** | 阻塞：需录音 | 见下"最大功能风险" |
@@ -444,6 +447,24 @@ ICE 候选、Playground 需要 `/start`、`run()` 要 WorkerParams、后台异
 **理由**：语音链路是全局瓶颈。它若走不通，后面的表情、转头做得再好也没用；
 而它若走通，其余部分都是可分解的独立工作。
 
+### Agent、记忆与打断决策（2026-09-16）
+
+当前系统是固定实时对话流水线加一个最多两轮的 `web_search` 工具循环，不是通用
+Agent。框架对比后决定渐进引入 **Pipecat Flows**，不整体迁移 OpenClaw、Agno、
+LangGraph、LiveKit Agents 或 smolagents。原因是现有 Pipecat/WebRTC 链路已经闭环，
+Flows 能提供状态、函数注册和对话节点，而身份、隐私、记忆与低延迟策略仍保留在
+项目内。
+
+必须先验证接口差异：Flows 期待 Pipecat `LLMService + context aggregator`，当前
+DeepSeek fallback、历史、STT/TTS 和工具循环都在自有 `ConversationEngine` 中。
+因此先做独立 spike，再以 `legacy|flows` feature flag 渐进迁移，禁止直接替换线上
+路径。完整实施范围、测试和回滚要求见 [[P1-Pipecat Flows Agent化与记忆改造交接]]。
+
+当前通用长期记忆尚未闭环：姓名是同步 confirmed 档案；“记住/我喜欢/我习惯”等
+规则仍统一写 candidate，默认检索排除，也没有确认晋升入口。当前打断也只是能量 VAD
+切分话段加任务取消能力；助手说话时检测到用户声音只记日志，尚未同时取消生成并清空
+客户端播放缓冲。这两项是 Flows 改造后的核心验收，不得写成“已完成”。
+
 ### 最大功能风险：STT 中文识别率
 
 Zipformer 的速度没问题（服务器 RTF 0.03），但**中文真人识别率至今没有可信数据**——