新增 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 要点。
This commit is contained in:
@@ -396,13 +396,15 @@ P5通过Home Assistant统一调用。按实际设备比较官方Xiaomi Home和Xi
|
|||||||
|
|
||||||
## 10. 运行维护与当前下一步
|
## 10. 运行维护与当前下一步
|
||||||
|
|
||||||
### 已完成(截至 2026-09-15)
|
### 已完成(截至 2026-09-16)
|
||||||
|
|
||||||
- Ubuntu 24.04 已确认,USB 接口已盘点;依赖版本固定在代码仓库的 `requirements.txt`
|
- Ubuntu 24.04 已确认,USB 接口已盘点;依赖版本固定在代码仓库的 `requirements.txt`
|
||||||
- 助手本体在服务器上实现并跑通,端到端测试 16/16(**用文件音频,非实时链路**)
|
- 助手本体在服务器上实现并跑通,端到端测试 16/16(**用文件音频,非实时链路**)
|
||||||
- STT/TTS/LLM 三方基准实测;DeepSeek 四条路径验证
|
- STT/TTS/LLM 三方基准实测;DeepSeek 四条路径验证
|
||||||
- 记忆与身份的数据层实现并测试(88 项断言)
|
- 记忆与身份的数据层实现并测试(88 项断言)
|
||||||
- 代码剥离为独立仓库 `~/workspace/ai-companion/`
|
- 代码剥离为独立仓库 `~/workspace/ai-companion/`
|
||||||
|
- 网页文字与语音对话、助手文字显示、DeepSeek Function Calling + 私有 SearXNG 已部署
|
||||||
|
- 姓名档案跨连接恢复已修复;内部 user_id 与用户称呼隔离
|
||||||
|
|
||||||
### 下一步顺序(按风险从高到低)
|
### 下一步顺序(按风险从高到低)
|
||||||
|
|
||||||
@@ -417,6 +419,7 @@ Pipecat Playground 做了真人浏览器对话,麦克风 → STT → LLM → T
|
|||||||
| 0 | **音频边界定稿** | ✅ 2026-09-15 完成(见 §5) | 决定了客户端接口形态 |
|
| 0 | **音频边界定稿** | ✅ 2026-09-15 完成(见 §5) | 决定了客户端接口形态 |
|
||||||
| 1 | **服务端 WebRTC 入口 + 客户端骨架** | ✅ **实时链路已闭环**(见 `P0-Pipecat传输层实验报告.md`) | 已验证:信令、ICE、data channel、帧路由、STT→LLM→TTS、文件与浏览器真人非静音回复 |
|
| 1 | **服务端 WebRTC 入口 + 客户端骨架** | ✅ **实时链路已闭环**(见 `P0-Pipecat传输层实验报告.md`) | 已验证:信令、ICE、data channel、帧路由、STT→LLM→TTS、文件与浏览器真人非静音回复 |
|
||||||
| 1b | **查清帧路由根因 → 定 A/B 方案** | ✅ **根因已定位,采用 A 方案** | NLTK 运行时下载导致 setup timeout;不是模型不兼容。网页 RTVI 保留 |
|
| 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/播客参考/打断**——那些要真实声卡 |
|
| 2 | **N5095 客户端骨架** | 🔶 雏形已有(`client/test_client.py`) | 非 trickle ICE、data channel 心跳、文件音频实时发送、回复录音都已实现。**不做 AEC/播客参考/打断**——那些要真实声卡 |
|
||||||
| 3 | **接入真实麦克风与音箱** | 阻塞:硬件未购;网页仅验证普通麦克风对话 | 唯一能完整验证阵列 AEC、打断、本地唤醒的一步,也是 P2 的全部内容 |
|
| 3 | **接入真实麦克风与音箱** | 阻塞:硬件未购;网页仅验证普通麦克风对话 | 唯一能完整验证阵列 AEC、打断、本地唤醒的一步,也是 P2 的全部内容 |
|
||||||
| 4 | **STT 中文识别正确率** | 阻塞:需录音 | 见下"最大功能风险" |
|
| 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 中文识别率
|
### 最大功能风险:STT 中文识别率
|
||||||
|
|
||||||
Zipformer 的速度没问题(服务器 RTF 0.03),但**中文真人识别率至今没有可信数据**——
|
Zipformer 的速度没问题(服务器 RTF 0.03),但**中文真人识别率至今没有可信数据**——
|
||||||
|
|||||||
@@ -122,6 +122,21 @@ metrics 与 interruption,不重写已有的记忆、身份、LLM/TTS 适配。
|
|||||||
- **不做 AEC、不做播放参考、不做打断**——那些要真实声卡和硬件
|
- **不做 AEC、不做播放参考、不做打断**——那些要真实声卡和硬件
|
||||||
- 它是 N5095 客户端的雏形,不是产品代码
|
- 它是 N5095 客户端的雏形,不是产品代码
|
||||||
|
|
||||||
|
## 八点五、2026-09-16 后续架构补充
|
||||||
|
|
||||||
|
媒体传输闭环不等于 Agent、长期记忆和实时打断已经闭环。真人网页测试后确认:
|
||||||
|
|
||||||
|
- 姓名档案已经能跨连接恢复,但通用“记住/偏好”仍写 candidate,默认不会召回;
|
||||||
|
- 当前 `SimpleVAD` 能判断 700ms 尾静音,助手说话时检测到用户声音却只记日志;
|
||||||
|
- `InterruptionFrame` 和异步任务取消能力存在,但没有由 user-started-speaking
|
||||||
|
可靠触发,也没有保证清空浏览器已经缓冲的音频;
|
||||||
|
- 当前只有 `web_search` 的手写工具循环。
|
||||||
|
|
||||||
|
后续 Agent 层选择 **Pipecat Flows 渐进集成**,继续坚持 A 方案,不重写已经验证的
|
||||||
|
传输层。因为 Flows 使用 Pipecat `LLMService` 与 context aggregator,而项目当前
|
||||||
|
使用自有 `ConversationEngine`,必须先做独立兼容性 spike,并保留 legacy feature
|
||||||
|
flag。详细交接见 [[P1-Pipecat Flows Agent化与记忆改造交接]]。
|
||||||
|
|
||||||
## 八、复现
|
## 八、复现
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
|
|||||||
@@ -0,0 +1,256 @@
|
|||||||
|
# P1 · Pipecat Flows 兼容性 Spike 结论
|
||||||
|
|
||||||
|
> 日期:2026-09-16
|
||||||
|
> 状态:**spike 完成,7 项验证全部通过**
|
||||||
|
> 代码:`p1/flows_spike.py`(探索脚本)、`app/tests/test_flows_spike.py`(断言版)
|
||||||
|
> 前置:[P1-Pipecat Flows Agent化与记忆改造交接](P1-Pipecat%20Flows%20Agent化与记忆改造交接.md)
|
||||||
|
|
||||||
|
交接文档规定:**未经 spike 结论,不进入 Phase 3**。本文即该结论。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、结论摘要
|
||||||
|
|
||||||
|
| 问题 | 结论 |
|
||||||
|
|---|---|
|
||||||
|
| 兼容的 flows 版本 | **不装独立包**。Pipecat 1.10.0 **内置** Flows(`pipecat.flows`) |
|
||||||
|
| LLMService 选择 | 复用 Pipecat 的 `DeepSeekLLMService`;**代价是失去本地 vLLM 降级** |
|
||||||
|
| token 级文本 | ✅ 实测 14–22 块/回复,满足网页显示与分句 TTS |
|
||||||
|
| 工具调用 | ✅ 参数聚合完整,无重复拼接;工具结果回灌后能出最终回答 |
|
||||||
|
| 取消 | ✅ `worker.cancel()` 能立即终止 LLM 流 |
|
||||||
|
| context | ⚠️ **会产生两条 system 消息**(见 §五) |
|
||||||
|
| 是否破坏现有功能 | 见 §六——**有两处需要处理** |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、版本:不需要独立包,而且装了有害
|
||||||
|
|
||||||
|
**这是最重要的一条发现。**
|
||||||
|
|
||||||
|
`pipecat-ai 1.10.0` **已经内置了 Pipecat Flows**,模块路径 `pipecat.flows`。
|
||||||
|
装独立的 `pipecat-ai-flows` 包时,Pipecat 会直接报错提示:
|
||||||
|
|
||||||
|
```
|
||||||
|
ERROR | pipecat:_warn_if_standalone_flows_installed:45 -
|
||||||
|
The separate `pipecat-ai-flows` package is installed alongside a version of
|
||||||
|
Pipecat that already includes Pipecat Flows as `pipecat.flows`.
|
||||||
|
You do not need both — uninstall `pipecat-ai-flows` and import Flows from `pipecat.flows`.
|
||||||
|
```
|
||||||
|
|
||||||
|
而且独立包的版本区间有陷阱:
|
||||||
|
|
||||||
|
| 独立包版本 | 要求的 pipecat-ai | 后果 |
|
||||||
|
|---|---|---|
|
||||||
|
| 1.4.0 | `>=1.4.0,<1.5.0` | **会把 pipecat 从 1.10.0 降到 1.4.0** |
|
||||||
|
| 1.3.0 | `>=1.4.0,<2` | 可安装,pytest dry-run 只新增自己 |
|
||||||
|
|
||||||
|
(1.4.0 是"更新"的版本,却钉死在更老的 pipecat 区间——如果按"装最新版"的直觉操作,
|
||||||
|
会静默把整个框架降级。)
|
||||||
|
|
||||||
|
**决定**:
|
||||||
|
|
||||||
|
- `requirements.txt` **不添加** `pipecat-ai-flows`
|
||||||
|
- 代码 `from pipecat.flows import FlowManager, NodeConfig, FlowsFunctionSchema`
|
||||||
|
- 内置版与独立包 **API 一致**(FlowManager / NodeConfig / FlowsFunctionSchema 签名相同),
|
||||||
|
所以这个切换不影响任何写法
|
||||||
|
|
||||||
|
内置版的导出比独立包更多(多出 `Flow`、`FlowConfig`、`FlowProblem`、`FlowReferenceError`),
|
||||||
|
像是更演进的 API,但 spike 只用到了两者共有的部分。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、LLMService 选择
|
||||||
|
|
||||||
|
**结论:复用 Pipecat 的 `DeepSeekLLMService`,不写 `FallbackProvider → LLMService` 适配器。**
|
||||||
|
|
||||||
|
理由:
|
||||||
|
|
||||||
|
1. **它自带 `DeepSeekLLMAdapter`**,源码注释明写 "Supplies the `reasoning_content`
|
||||||
|
DeepSeek requires on assistant messages in thinking mode"——**这正是我们在 P0
|
||||||
|
阶段踩过的坑**(见 `P0-DeepSeek验证报告.md`:开思考时多轮/工具回灌一律 400)。
|
||||||
|
框架已经处理了。
|
||||||
|
2. `thinking` 默认就是 `disabled`,与 P0 的结论一致。
|
||||||
|
3. 支持自定义 `base_url`,将来要接本地 vLLM 也能用。
|
||||||
|
4. **无法适配 `FallbackProvider`**:Flows 要求的是 `LLMService` 实例
|
||||||
|
(`LLMService | LLMSwitcher`),而 `pipecat_flows` 里那个 `LLMAdapter`
|
||||||
|
**只管摘要生成**,不是 provider 适配器。要保留 fallback 必须自己写
|
||||||
|
`LLMService` 子类,成本中等。
|
||||||
|
|
||||||
|
**必须覆盖模型名**:默认是 `deepseek-v4-flash`,**该模型不存在**,用默认值会 400。
|
||||||
|
必须显式设 `DeepSeekLLMService.Settings(model="deepseek-flash")`。
|
||||||
|
|
||||||
|
**失去本地 vLLM 降级的代价**:目前本机 27B 的 vLLM 已停用,fallback 实际上没有可用的
|
||||||
|
后备目标。所以 Phase 3 先只用 DeepSeek 是合理的。将来若要恢复双后端,
|
||||||
|
Pipecat 有 `LLMSwitcher` 可用,不必自写。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、实测结果(7 项,9 个断言全通过)
|
||||||
|
|
||||||
|
```
|
||||||
|
=== 2. DeepSeek 在 Flows 中流式输出中文 ===
|
||||||
|
回复: '我是你的桌面陪伴小助手,平时就待在这儿陪你聊聊天、说说话。'
|
||||||
|
分块数: 18
|
||||||
|
[PASS] 有中文回复
|
||||||
|
[PASS] 回复不含 Markdown
|
||||||
|
[PASS] 7. token 级文本事件(>1 块) — 18 块
|
||||||
|
|
||||||
|
=== 3+4. 流式工具参数聚合 / 工具结果回灌 ===
|
||||||
|
工具调用参数: [{'city': '北京'}]
|
||||||
|
最终回复: '北京现在是下午三点半。'
|
||||||
|
[PASS] 3. 工具被调用 — 1 次
|
||||||
|
[PASS] 3. 参数聚合完整(无重复拼接) — {"city": "北京"}
|
||||||
|
[PASS] 4. 工具结果回灌后有最终回答
|
||||||
|
|
||||||
|
=== 5. 取消 ===
|
||||||
|
取消前 13 块 → 取消后 1.5s 内 13 块(又收到 0 块)
|
||||||
|
[PASS] 5. 取消后停止输出
|
||||||
|
|
||||||
|
=== 6. system message ===
|
||||||
|
context 消息角色序列: ['system', 'user', 'assistant']
|
||||||
|
[PASS] 6. system 消息不超过 1 条
|
||||||
|
[PASS] 6. 有 user 与 assistant 轮次
|
||||||
|
```
|
||||||
|
|
||||||
|
补充观察:
|
||||||
|
- **role_message 生效**:设"你是桌面陪伴助手"后,模型自称"桌面陪伴小助手",
|
||||||
|
不再是通用的"DeepSeek AI 助手"
|
||||||
|
- **工具调用只有 1 次**(修好 runner 之前会失败重试 2 次,见 §五)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、暴露的问题(4 个坑,都已定位)
|
||||||
|
|
||||||
|
### 坑 1:`FlowManager.initialize` 是协程,漏 `await` 会静默失效
|
||||||
|
|
||||||
|
```python
|
||||||
|
inspect.signature(FlowManager.initialize) # (self, initial_node=None) -> None
|
||||||
|
inspect.iscoroutinefunction(...) # True ← 签名上看不出来
|
||||||
|
```
|
||||||
|
|
||||||
|
漏 `await` 时**不报错**,只是整个 flow 从不初始化:role_message、task_messages、
|
||||||
|
工具注册**全部没生效**,而 LLM 照样会回复(因为 `run_llm=True` 直接触发推理)。
|
||||||
|
|
||||||
|
现象极具误导性:会让人误判成"Flows 不支持这些特性"。实测中我一度得出
|
||||||
|
"role_message 不生效"的结论,就是这个原因。
|
||||||
|
|
||||||
|
### 坑 2:必须用 `PipelineRunner` 跑 worker,不能直接 `worker.run()`
|
||||||
|
|
||||||
|
直接 `worker.run(...)` 时 runner 没挂上,**工具执行会失败**:
|
||||||
|
|
||||||
|
```
|
||||||
|
Error executing function call [get_time]:
|
||||||
|
Worker 'PipelineWorker#0': runner is not set; call attach() first.
|
||||||
|
```
|
||||||
|
|
||||||
|
这个异常被 Pipecat 转成给 LLM 的通用错误串
|
||||||
|
`"The function X failed and returned no result."`,**handler 从不执行**,
|
||||||
|
日志里默认看不到真实原因。要开 DEBUG 才看得到。
|
||||||
|
|
||||||
|
正确写法:`await PipelineRunner().run(worker)`
|
||||||
|
|
||||||
|
### 坑 3:`respond_immediately` 默认 `True`,initialize 会立刻触发一轮回复
|
||||||
|
|
||||||
|
`FlowManager.initialize()` 会 queue 一个 `LLMRunFrame`,**在用户说话之前**
|
||||||
|
就产生一轮 LLM 回复。
|
||||||
|
|
||||||
|
做测试/归因时如果不清空观察窗口,会把"节点初始化的自动回复"当成
|
||||||
|
"对用户问题的回复"——我第一版 spike 就误判了第 2 项。
|
||||||
|
|
||||||
|
生产上这通常是想要的行为(节点进入即主动开口),但**必须知道它存在**。
|
||||||
|
|
||||||
|
### 坑 4:会产生两条 system 消息
|
||||||
|
|
||||||
|
实际发给 DeepSeek 的请求里:
|
||||||
|
|
||||||
|
```
|
||||||
|
[system] '你是桌面陪伴助手……' ← role_message(走 system_instruction)
|
||||||
|
[system] '当前任务:普通陪伴对话。' ← task_messages
|
||||||
|
[user] '……'
|
||||||
|
```
|
||||||
|
|
||||||
|
`role_message` 通过 `LLMUpdateSettingsFrame(system_instruction=...)` 下发,
|
||||||
|
而 `task_messages` 里的 system 消息留在 context 里,**两者都进请求**。
|
||||||
|
|
||||||
|
交接文档 §九 Phase 1 第 6 项要求"context aggregator 不产生第二条 system message"——
|
||||||
|
严格说,**context 里确实只有一条**(`task_messages` 那条),
|
||||||
|
`role_message` 走的是 LLM settings 而非 context。但**发出去的请求有两条 system**。
|
||||||
|
|
||||||
|
风险:
|
||||||
|
- 多数模型能处理多条 system,但**优先级不保证**(谁覆盖谁取决于实现)
|
||||||
|
- 我们之前在**本机 vLLM** 上就吃过"多条 system 直接 400"的亏
|
||||||
|
(见 `P0-本地LLM验证报告.md`)——如果将来把 LLM 切回本地 vLLM,这条会立刻炸
|
||||||
|
|
||||||
|
**建议**:Phase 3 集成时**只用一种**。要么把节点任务说明也写进 `role_message`,
|
||||||
|
要么不用 `role_message`、全部走 `task_messages`。不要两个都用。
|
||||||
|
|
||||||
|
### 坑 5(环境):NLTK `punkt_tab` 本地也要装
|
||||||
|
|
||||||
|
Pipecat 启动会预热 NLTK 分句器,缺 `punkt_tab` 会尝试联网下载并被安全策略拦
|
||||||
|
(`SSRF attempt to restricted IP`),setup 超时后管线卡住。
|
||||||
|
|
||||||
|
服务器上已装(`~/.local/share/ai-companion/nltk_data`),**本地开发机也要装**,
|
||||||
|
否则 spike 跑不起来。`p1/flows_spike.py` 已加 fail-fast 检查与拷贝命令提示。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、对现有功能的影响
|
||||||
|
|
||||||
|
| 现有功能 | 是否受影响 | 说明 |
|
||||||
|
|---|---|---|
|
||||||
|
| 分句 TTS | **不受影响** | Flows 输出 token 级 `TextFrame`(实测 18 块),自有分句逻辑照用 |
|
||||||
|
| RTVI 网页显示 | **不受影响** | token 增量与完整文本都能拿到 |
|
||||||
|
| 记忆 / 身份 / SQLite | 不受影响 | Flows 的 state 只存会话控制状态,长期数据仍走 `MemoryStore` |
|
||||||
|
| SearXNG 搜索 | 需迁移 | 现在的 `web_search` 手写循环要改成 Flows 工具 |
|
||||||
|
| **本地 vLLM fallback** | **会失去** | `FallbackProvider` 不能被 Flows 直接使用(见 §三) |
|
||||||
|
| 两条 system 消息 | **需要注意** | 见坑 4;切回本地 vLLM 时会 400 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 七、建议的最小生产集成 diff(Phase 3 用)
|
||||||
|
|
||||||
|
不改动现有 `EngineProcessor` 的音频路径,只在**文字路径**上分流:
|
||||||
|
|
||||||
|
1. `app/config.py` 加 `AI_AGENT_RUNTIME=legacy|flows`,**默认 legacy**
|
||||||
|
2. `app/agent/` 新增 `tools.py`(工具定义)、`memory_policy.py`(记忆策略)、
|
||||||
|
`flows_runtime.py`(FlowManager 装配)
|
||||||
|
3. `services/bot_server.py` 里,RTVI `send-text` 按 `AI_AGENT_RUNTIME` 分流:
|
||||||
|
`legacy` → 现有 `EngineProcessor`;`flows` → 新建的 Flows 路径
|
||||||
|
4. 语音路径**暂不动**,留到 Phase 5
|
||||||
|
5. `requirements.txt` **不加** `pipecat-ai-flows`
|
||||||
|
|
||||||
|
关键注意点:
|
||||||
|
- 用 `PipelineRunner().run(worker)`,不要直接 `worker.run()`
|
||||||
|
- `await flow.initialize(node)`
|
||||||
|
- `role_message` 与 `task_messages` 的 system 消息**二选一**
|
||||||
|
- `DeepSeekLLMService.Settings(model="deepseek-flash")` 必须显式覆盖
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 八、下一步
|
||||||
|
|
||||||
|
spike 已给出结论,**可以进入 Phase 2**(抽出工具与策略层):
|
||||||
|
|
||||||
|
- 把现有 `web_search` 执行从 `ConversationEngine` 抽成可复用函数
|
||||||
|
- 实现记忆工具,先用 fake store 单测
|
||||||
|
- legacy 路径继续工作,Flows 不是唯一调用者
|
||||||
|
|
||||||
|
Phase 3(接网页文字路径)等 Phase 2 完成标准达成后再开始。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 九、复现
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd ~/workspace/ai-companion
|
||||||
|
|
||||||
|
# 探索脚本(带请求体抓取与逐项诊断)
|
||||||
|
~/venvs/ai_assistant/bin/python p1/flows_spike.py
|
||||||
|
~/venvs/ai_assistant/bin/python p1/flows_spike.py --only 3
|
||||||
|
|
||||||
|
# 断言版(接 CI 用)
|
||||||
|
~/venvs/ai_assistant/bin/python app/tests/test_flows_spike.py
|
||||||
|
|
||||||
|
# 需要 DEBUG 日志排查时
|
||||||
|
SPIKE_DEBUG=1 ~/venvs/ai_assistant/bin/python p1/flows_spike.py --only 3
|
||||||
|
```
|
||||||
@@ -0,0 +1,501 @@
|
|||||||
|
# P1 · Pipecat Flows Agent 化与记忆改造交接
|
||||||
|
|
||||||
|
> 日期:2026-09-16
|
||||||
|
> 状态:方案已选定,等待实现
|
||||||
|
> 实现仓库:`~/workspace/ai-companion`
|
||||||
|
> 部署目录:`yonglin@cadadmin-server.taild0f91d.ts.net:~/ai-companion`
|
||||||
|
|
||||||
|
## 一、给 Claude Code 的任务摘要
|
||||||
|
|
||||||
|
在**不推翻现有实时语音链路**的前提下,渐进引入 Pipecat Flows,把当前手写的
|
||||||
|
单工具循环升级为受策略约束的 Agent 工具层,并补齐通用长期记忆的确认、读取、
|
||||||
|
修改和忘记流程。
|
||||||
|
|
||||||
|
必须遵守以下边界:
|
||||||
|
|
||||||
|
1. 保留现有 `MemoryStore`、SQLite 数据、身份隔离、DeepSeek fallback、SearXNG、
|
||||||
|
RTVI 网页显示和流式 TTS。
|
||||||
|
2. 先做 Pipecat Flows 与当前 `ConversationEngine` 的兼容性 spike;验证通过前,
|
||||||
|
不得替换线上默认路径。
|
||||||
|
3. 使用 `AI_AGENT_RUNTIME=legacy|flows` 保留可立即回滚的 legacy 路径。
|
||||||
|
4. 模型不得决定或传入 `owner_user_id`;用户身份必须由服务端会话上下文注入。
|
||||||
|
5. 用户明确要求记忆与模型推测必须分开。模型推测不得直接成为 confirmed。
|
||||||
|
6. 不把 Pipecat Flow state 当成长期记忆;长期数据仍通过 `MemoryStore` 持久化。
|
||||||
|
7. 不顺手实现唤醒词、硬件 AEC、人脸自动切换、向量数据库或 systemd。
|
||||||
|
|
||||||
|
## 二、开始前必须知道的仓库状态
|
||||||
|
|
||||||
|
### 代码和部署
|
||||||
|
|
||||||
|
- Git 已提交基线包含:
|
||||||
|
- `c3d2c7f`:修复 Pipecat 实时链路并补齐网页测试
|
||||||
|
- `719fc13`:修复网页对话并接入 SearXNG 搜索
|
||||||
|
- 2026-09-16 的姓名档案修复、疑问句防误写和测试目前仍是**未提交改动**。
|
||||||
|
- 线上服务已运行这些未提交改动,不等于服务器代码与 Git HEAD 相同。
|
||||||
|
- 开始工作前必须运行 `git status --short` 和 `git diff`;不得 reset、checkout
|
||||||
|
或覆盖现有改动。
|
||||||
|
- 线上健康接口:`http://127.0.0.1:7860/health`。
|
||||||
|
- 网页调试入口通过 SSH 隧道访问:`http://localhost:7860/client/`。
|
||||||
|
|
||||||
|
### 当前已验证能力
|
||||||
|
|
||||||
|
- SmallWebRTC 信令、ICE、data channel、音频输入输出已闭环。
|
||||||
|
- 浏览器真人麦克风 → STT → DeepSeek → Qwen3-TTS → 浏览器播放正常。
|
||||||
|
- 网页文字输入、用户文本、助手文本和语音回复正常。
|
||||||
|
- DeepSeek 能自主调用 `web_search`,SearXNG 工具结果能回灌后继续回答。
|
||||||
|
- 用户自报“我叫林”会同步写入 confirmed 姓名档案,disconnect/reconnect 后恢复。
|
||||||
|
- 姓名疑问句不会再把“谁吗”之类内容覆盖为姓名。
|
||||||
|
- 当前专项回归:
|
||||||
|
- 姓名档案 22/22
|
||||||
|
- 记忆存储 30/30
|
||||||
|
- 身份 19/19
|
||||||
|
- 搜索 12/12
|
||||||
|
- 传输 4/4
|
||||||
|
|
||||||
|
### 线上姓名数据库备份
|
||||||
|
|
||||||
|
- 首次档案迁移前:
|
||||||
|
`/home/yonglin/.local/share/ai_assistant/memory.db.before-name-profile-20260916`
|
||||||
|
- 疑问句误写修复前:
|
||||||
|
`/home/yonglin/.local/share/ai_assistant/memory.db.before-name-question-20260916-1140`
|
||||||
|
|
||||||
|
不要删除这些备份。后续若改 schema,必须另建带时间戳的备份。
|
||||||
|
|
||||||
|
## 三、当前系统到底是什么
|
||||||
|
|
||||||
|
当前不是完整通用 Agent,而是:
|
||||||
|
|
||||||
|
```text
|
||||||
|
SmallWebRTC / RTVI
|
||||||
|
↓
|
||||||
|
EngineProcessor
|
||||||
|
↓
|
||||||
|
SimpleVAD → StreamingSTT
|
||||||
|
↓
|
||||||
|
ConversationEngine
|
||||||
|
身份 → 自动记忆检索 → DeepSeek/搜索工具循环 → 分句 TTS
|
||||||
|
↓
|
||||||
|
WebRTC 音频与 RTVI 文本
|
||||||
|
```
|
||||||
|
|
||||||
|
`ConversationEngine._stream_and_speak()` 手写了最多两轮的 `web_search` Function
|
||||||
|
Calling 循环。模型能自主决定是否搜索,但还不能自主调用记忆工具。
|
||||||
|
|
||||||
|
Pipecat 当前主要负责传输、Frame、PipelineWorker 和 RTVI;STT、LLM、TTS 语义链路
|
||||||
|
仍由自有引擎调度。
|
||||||
|
|
||||||
|
## 四、当前记忆决策与真实缺口
|
||||||
|
|
||||||
|
### 写入
|
||||||
|
|
||||||
|
| 输入 | 当前行为 | 实际是否可复用 |
|
||||||
|
|---|---|---|
|
||||||
|
| “我叫林” | 同步更新 `users.display_name`,写 confirmed 姓名 | 是 |
|
||||||
|
| “记住我不吃香菜” | 回复后规则抽取,写 candidate | 否,默认检索排除 |
|
||||||
|
| “我喜欢咖啡” | 回复后规则抽取,写 candidate | 否,默认检索排除 |
|
||||||
|
| 普通聊天 | 只保留当前内存历史和 user turn | 重连后不可用 |
|
||||||
|
|
||||||
|
当前没有 candidate 的确认、晋升或管理入口。因此除姓名外,“写进数据库”和“助手会在
|
||||||
|
以后使用”不是一回事。
|
||||||
|
|
||||||
|
### 读取
|
||||||
|
|
||||||
|
- 每条已确认身份的用户消息都会尝试检索,不是模型按需决定。
|
||||||
|
- 默认只读取 confirmed、private/shared、未过期记忆。
|
||||||
|
- 最多 5 条,超时 300ms 后无记忆继续回答。
|
||||||
|
- 当前是中文字符/二元组字面相似度;记忆总量很小时,无命中会退回最近记忆。
|
||||||
|
- 用户姓名作为档案固定注入,不依赖语义检索。
|
||||||
|
|
||||||
|
### 必须达到的目标语义
|
||||||
|
|
||||||
|
1. **稳定档案**:姓名、称呼、语言和明确的稳定偏好;连接开始时加载。
|
||||||
|
2. **显式长期记忆**:用户明确说“记住/以后/别忘了”,经策略校验后 confirmed。
|
||||||
|
3. **候选观察**:普通聊天中推断出的可能信息只能 candidate,不直接影响回答。
|
||||||
|
4. **事件/摘要**:会话事件与逐字稿不冒充永久事实,可过期、可删除。
|
||||||
|
5. **矛盾更新**:同 owner + kind + key 的 confirmed 新值覆盖或 supersede 旧值。
|
||||||
|
6. **透明控制**:支持查看、确认、修改、忘记;模糊删除必须追问。
|
||||||
|
|
||||||
|
## 五、为什么选择 Pipecat Flows
|
||||||
|
|
||||||
|
### 候选比较
|
||||||
|
|
||||||
|
| 框架 | 优点 | 与本项目的主要问题 | 结论 |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Pipecat Flows | 已在 Pipecat 生态;状态、节点、函数注册和校验;支持 DeepSeek 等 OpenAI-compatible 服务 | 期待 Pipecat `LLMService + context aggregator`,与当前自有引擎有接口差异 | **选择,渐进集成** |
|
||||||
|
| Agno | 内置 user/session/memory,最接近轻量版 OpenClaw | 会与现有会话、历史和记忆层重叠 | 暂不采用 |
|
||||||
|
| PydanticAI | 类型安全、依赖注入、流式工具事件、较轻 | 长期记忆策略仍要自建;与现有工具循环收益有限 | 备选 |
|
||||||
|
| LangGraph | 持久状态、checkpoint、长任务和人工审批成熟 | 对当前实时陪伴链路过重 | 暂不采用 |
|
||||||
|
| LiveKit Agents | 完整实时语音 Agent、工具、handoff | 相当于替换已跑通的 Pipecat/WebRTC;长期记忆仍需外接 | 不迁移 |
|
||||||
|
| smolagents | 代码少、多步工具 Agent | 偏任务型,多步延迟高,API仍偏实验 | 不用于主链路 |
|
||||||
|
| OpenClaw | 通用 Agent runtime、分层记忆和后台整理完整 | 运行时过重、默认个人 Agent 假设、实时语音和身份边界仍需定制 | 不整体迁移 |
|
||||||
|
|
||||||
|
官方资料:
|
||||||
|
|
||||||
|
- [Pipecat Flows Overview](https://docs.pipecat.ai/api-reference/pipecat-flows/overview)
|
||||||
|
- [Pipecat Function Calling](https://docs.pipecat.ai/pipecat/learn/function-calling)
|
||||||
|
- [Agno Memory](https://docs.agno.com/examples/memory/overview)
|
||||||
|
- [PydanticAI Agents](https://ai.pydantic.dev/agents/)
|
||||||
|
- [LangGraph Memory](https://docs.langchain.com/oss/python/langgraph/add-memory)
|
||||||
|
- [LiveKit Chat Context](https://docs.livekit.io/agents/logic/chat-context/)
|
||||||
|
- [OpenClaw Memory](https://docs.openclaw.ai/concepts/memory)
|
||||||
|
|
||||||
|
### 选型原则
|
||||||
|
|
||||||
|
选择 Pipecat Flows,不是为了追求“框架化”,而是为了:
|
||||||
|
|
||||||
|
- 复用现有实时媒体栈;
|
||||||
|
- 把工具 schema、执行、结果回灌和状态切换从手写循环中抽离;
|
||||||
|
- 给记忆确认/删除等多轮流程提供显式状态;
|
||||||
|
- 保留产品特有的身份、隐私和低延迟策略。
|
||||||
|
|
||||||
|
## 六、最重要的集成风险
|
||||||
|
|
||||||
|
Pipecat Flows 的正常构造需要:
|
||||||
|
|
||||||
|
- `PipelineTask`
|
||||||
|
- Pipecat `LLMService`
|
||||||
|
- context aggregator
|
||||||
|
- 由 Pipeline Frame 驱动的函数调用和消息更新
|
||||||
|
|
||||||
|
当前项目则是:
|
||||||
|
|
||||||
|
- `PipelineWorker` + 自定义 `EngineProcessor`
|
||||||
|
- 自有 `FallbackProvider`,不是 Pipecat `LLMService`
|
||||||
|
- 自有消息历史与 prompt 构造
|
||||||
|
- 自有 STT/TTS 调用,不是标准 Pipecat service processor
|
||||||
|
- RTVI 事件由 `EngineProcessor` 手工补发
|
||||||
|
|
||||||
|
因此不能直接“安装 Flows,然后包住 ConversationEngine”。如果忽略这一点,很容易出现:
|
||||||
|
|
||||||
|
- 两套消息历史同时增长;
|
||||||
|
- 工具调用重复执行;
|
||||||
|
- token 既被自有引擎又被 Pipecat aggregator 消费;
|
||||||
|
- RTVI 文本重复或消失;
|
||||||
|
- TTS 重复播报;
|
||||||
|
- 取消只停止其中一套任务;
|
||||||
|
- 身份切换后旧 context 泄漏。
|
||||||
|
|
||||||
|
## 七、目标架构
|
||||||
|
|
||||||
|
```text
|
||||||
|
┌─────────────────────────────┐
|
||||||
|
WebRTC / RTVI ─────▶│ Pipecat Pipeline │
|
||||||
|
│ transport + turn + metrics │
|
||||||
|
└──────────────┬──────────────┘
|
||||||
|
│
|
||||||
|
┌──────────────▼──────────────┐
|
||||||
|
│ Flows Runtime(可切换) │
|
||||||
|
│ node / state / tools │
|
||||||
|
└──────────────┬──────────────┘
|
||||||
|
│
|
||||||
|
┌────────────────────────┼────────────────────────┐
|
||||||
|
▼ ▼ ▼
|
||||||
|
LLMService 适配器 Memory Policy Web Search
|
||||||
|
DeepSeek/Fallback + MemoryStore SearXNG
|
||||||
|
│ │
|
||||||
|
▼ ▼
|
||||||
|
流式文本与 TTS SQLite(继续使用)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Flow state 只保存会话控制状态
|
||||||
|
|
||||||
|
建议字段:
|
||||||
|
|
||||||
|
- `session_id`
|
||||||
|
- 服务端绑定的 `user_id`(内部使用,不展示给模型)
|
||||||
|
- `display_name`
|
||||||
|
- `identity_version`
|
||||||
|
- `pending_memory_action`
|
||||||
|
- `pending_confirmation`
|
||||||
|
- 当前 node
|
||||||
|
|
||||||
|
不要把全部记忆内容复制进 Flow state,也不要把 state 当数据库。
|
||||||
|
|
||||||
|
### 初始节点
|
||||||
|
|
||||||
|
第一版只需要两个节点,不要设计庞大状态图:
|
||||||
|
|
||||||
|
1. `conversation`
|
||||||
|
- 普通陪伴对话;
|
||||||
|
- 可用只读搜索和受限记忆工具;
|
||||||
|
- 默认节点。
|
||||||
|
2. `confirm_memory_change`
|
||||||
|
- 只在修改、删除目标不明确或敏感写入时进入;
|
||||||
|
- 用户确认/取消后返回 `conversation`。
|
||||||
|
|
||||||
|
## 八、工具设计
|
||||||
|
|
||||||
|
### 全局工具
|
||||||
|
|
||||||
|
#### `web_search(query)`
|
||||||
|
|
||||||
|
- 复用 `app/search.py` 与 SearXNG。
|
||||||
|
- 保留最多两次连续搜索限制。
|
||||||
|
- 搜索失败返回工具错误结果,不让整轮异常退出。
|
||||||
|
- 来源 URL 保留给网页,TTS 继续不朗读来源段。
|
||||||
|
|
||||||
|
#### `memory_search(query)`
|
||||||
|
|
||||||
|
- `owner_user_id` 从会话注入,禁止模型传入。
|
||||||
|
- 只返回 confirmed、未过期、授权 scope。
|
||||||
|
- 不确认身份时返回不可用,不搜索任何私人记忆。
|
||||||
|
- 结果条数和超时沿用配置上限。
|
||||||
|
|
||||||
|
#### `memory_remember(kind, key, value)`
|
||||||
|
|
||||||
|
- 仅确认身份可用。
|
||||||
|
- 只有当前用户明确表达“记住/以后/别忘了/我的偏好是”等意图时,才能 confirmed。
|
||||||
|
- 模型推断或总结只能写 candidate。
|
||||||
|
- `owner_user_id`、source session/turn、scope 由服务端填充。
|
||||||
|
- 默认 private;模型不得扩大成 shared。
|
||||||
|
- 同 key confirmed 写入保持幂等并更新旧值。
|
||||||
|
- 姓名确定性快路径暂时保留,不立即交给模型。
|
||||||
|
|
||||||
|
#### `memory_forget(selector)`
|
||||||
|
|
||||||
|
- 仅确认身份可用。
|
||||||
|
- 精确匹配一条时可返回待删除摘要;删除前应有明确用户意图。
|
||||||
|
- 多条或模糊匹配进入 `confirm_memory_change`,不得猜测删除目标。
|
||||||
|
- 删除必须同时匹配 owner;不得只凭 memory_id。
|
||||||
|
- 返回“已删除/没有找到/需要确认”,不能把“请求已接收”说成“已经删除”。
|
||||||
|
|
||||||
|
#### `memory_update(key, value)`
|
||||||
|
|
||||||
|
- 用于用户明确纠正已有事实或偏好。
|
||||||
|
- 更新必须保留来源和更新时间。
|
||||||
|
- 若未来增加 superseded 状态,先做向后兼容 migration,不删旧 schema。
|
||||||
|
|
||||||
|
#### `profile_update(display_name)`
|
||||||
|
|
||||||
|
- 第一阶段可继续使用现有确定性姓名提取,不必立即暴露给模型。
|
||||||
|
- 如果以后工具化,也必须经过同一疑问句和角色描述过滤。
|
||||||
|
|
||||||
|
### 记忆执行策略必须独立于 prompt
|
||||||
|
|
||||||
|
不要仅依赖“请不要误记”的 system prompt。新增类似:
|
||||||
|
|
||||||
|
```text
|
||||||
|
app/agent/memory_policy.py
|
||||||
|
```
|
||||||
|
|
||||||
|
策略层输入至少包含:
|
||||||
|
|
||||||
|
- 当前原始 user text
|
||||||
|
- 工具请求
|
||||||
|
- 已确认身份
|
||||||
|
- 当前 session/turn
|
||||||
|
- 已有同 key 记忆
|
||||||
|
|
||||||
|
策略层输出:
|
||||||
|
|
||||||
|
- allow_confirmed
|
||||||
|
- allow_candidate
|
||||||
|
- needs_confirmation
|
||||||
|
- reject
|
||||||
|
|
||||||
|
模型可以提出动作,策略层拥有最终决定权。
|
||||||
|
|
||||||
|
## 九、分阶段实施
|
||||||
|
|
||||||
|
### Phase 0:保护基线
|
||||||
|
|
||||||
|
1. 运行 `git status --short`、保存 `git diff`。
|
||||||
|
2. 运行当前相关测试。
|
||||||
|
3. 记录网页文字、网页语音、搜索、姓名重连的基线延迟与行为。
|
||||||
|
4. 不修改线上数据库 schema。
|
||||||
|
|
||||||
|
完成标准:现有未提交修复没有丢失,基线测试结果有记录。
|
||||||
|
|
||||||
|
### Phase 1:独立兼容性 spike
|
||||||
|
|
||||||
|
新增独立实验,不先改生产入口,例如:
|
||||||
|
|
||||||
|
```text
|
||||||
|
p1/flows_spike.py
|
||||||
|
app/tests/test_flows_spike.py
|
||||||
|
```
|
||||||
|
|
||||||
|
需要验证:
|
||||||
|
|
||||||
|
1. 找到与 `pipecat-ai==1.10.0` 兼容的 `pipecat-ai-flows` 版本并精确 pin。
|
||||||
|
2. DeepSeek OpenAI-compatible 接口能在 Flows 中流式输出中文内容。
|
||||||
|
3. 流式 function-call arguments 能被正确聚合一次,不重复拼接。
|
||||||
|
4. 工具结果回灌后能生成最终回答。
|
||||||
|
5. 任务取消能终止 LLM 请求和后续工具执行。
|
||||||
|
6. context aggregator 不产生第二条 system message。
|
||||||
|
7. 能获得 token 级文本事件,满足网页显示和分句 TTS。
|
||||||
|
|
||||||
|
若任何一项不成立,停止生产集成,先记录结论;不得为了使用框架而绕过现有正确行为。
|
||||||
|
|
||||||
|
### Phase 2:抽出工具和策略层
|
||||||
|
|
||||||
|
建议新增:
|
||||||
|
|
||||||
|
```text
|
||||||
|
app/agent/
|
||||||
|
├── __init__.py
|
||||||
|
├── tools.py
|
||||||
|
├── memory_policy.py
|
||||||
|
├── flows_runtime.py
|
||||||
|
└── llm_service.py
|
||||||
|
```
|
||||||
|
|
||||||
|
- 先把现有 `web_search` 执行从 `ConversationEngine` 抽成可复用函数。
|
||||||
|
- 实现记忆工具,但先用 fake store 单测。
|
||||||
|
- legacy 路径继续工作;不要让 Flows 成为唯一调用者。
|
||||||
|
|
||||||
|
完成标准:工具层可被 legacy 和 flows 两条路径复用,策略测试不依赖真实 LLM。
|
||||||
|
|
||||||
|
### Phase 3:先接网页文字路径
|
||||||
|
|
||||||
|
- 新增 `AI_AGENT_RUNTIME`,默认仍为 `legacy`。
|
||||||
|
- 只让 RTVI `send-text` 在显式 `flows` 配置下走新路径。
|
||||||
|
- 保持网页用户文本、token 增量、完整 assistant 文本和可选 TTS。
|
||||||
|
- 语音路径暂时保持 legacy。
|
||||||
|
|
||||||
|
完成标准:同一服务可切换两条 runtime;legacy 回归无变化;flows 文字路径通过工具、
|
||||||
|
姓名、记忆和搜索验收。
|
||||||
|
|
||||||
|
### Phase 4:补齐通用记忆闭环
|
||||||
|
|
||||||
|
至少覆盖:
|
||||||
|
|
||||||
|
1. “记住我不吃香菜” → confirmed。
|
||||||
|
2. disconnect/reconnect → “我不吃什么”能召回香菜。
|
||||||
|
3. “我今天吃了香菜”不得自动变成稳定偏好。
|
||||||
|
4. “其实我现在吃香菜了”能明确更新旧偏好,而不是保留冲突 active 值。
|
||||||
|
5. “忘掉我的饮食偏好”能删除;目标模糊时先确认。
|
||||||
|
6. 访客无法读取或写入私人记忆。
|
||||||
|
7. 用户 A 的记忆绝不出现在用户 B 的 prompt、工具结果或日志中。
|
||||||
|
|
||||||
|
### Phase 5:迁移语音路径
|
||||||
|
|
||||||
|
只有 Phase 3、4 稳定后才迁移语音:
|
||||||
|
|
||||||
|
- 保持 STT transcript 和原始 user text 一致;
|
||||||
|
- 保持首句尽快进入 TTS;
|
||||||
|
- 工具调用期间不得把工具 JSON 念出来;
|
||||||
|
- 来源段不进入 TTS;
|
||||||
|
- 用户打断时取消 Flows、LLM、工具和 TTS 的同一轮 execution;
|
||||||
|
- `ConversationEngine` 中已经稳定的身份与记忆接口可以拆分复用,不要求一次删除旧类。
|
||||||
|
|
||||||
|
### Phase 6:打断控制链
|
||||||
|
|
||||||
|
当前 `SimpleVAD` 只做 RMS 话段切分。下一步先实现控制闭环,不在本阶段承诺真实硬件
|
||||||
|
声学效果:
|
||||||
|
|
||||||
|
```text
|
||||||
|
user-started-speaking
|
||||||
|
├─ 发出 InterruptionFrame / 客户端停播信号
|
||||||
|
├─ 取消当前 Flows/LLM/TTS execution
|
||||||
|
├─ 清空未发送和客户端已缓冲音频
|
||||||
|
└─ 保留新用户话语的 pre-roll 并继续收集
|
||||||
|
```
|
||||||
|
|
||||||
|
要求:
|
||||||
|
|
||||||
|
- 不等待 700ms 尾静音才停止助手;
|
||||||
|
- 使用开始阈值、连续帧或正式 VAD,避免单个噪声帧误触发;
|
||||||
|
- `_bot_speaking` 不能只代表服务端推帧结束,要考虑客户端仍在播放;
|
||||||
|
- 文字请求期间的麦克风回采不得错误抢占;
|
||||||
|
- 先做合成 Frame 回归;真实 AEC、扬声器回声和远场误触发留到硬件 P2。
|
||||||
|
|
||||||
|
### Phase 7:部署与清理
|
||||||
|
|
||||||
|
- flows 默认值只有在线上验收后才能从 legacy 改为 flows。
|
||||||
|
- 更新 README、部署说明和本交接文档。
|
||||||
|
- 在修改数据库前创建新备份。
|
||||||
|
- 确认 `/health`、网页文字、网页语音、搜索和重连记忆。
|
||||||
|
- 确认日志没有 API key、私人全文记忆或内部 ID 泄漏。
|
||||||
|
|
||||||
|
## 十、测试与验收矩阵
|
||||||
|
|
||||||
|
### 必须新增的单元测试
|
||||||
|
|
||||||
|
- 工具参数 schema 与非法参数。
|
||||||
|
- 模型不能传 owner_user_id/scope 越权。
|
||||||
|
- 未确认身份拒绝 private memory。
|
||||||
|
- 明确“记住”写 confirmed。
|
||||||
|
- 推断信息只写 candidate。
|
||||||
|
- 同 key 更新幂等。
|
||||||
|
- 模糊忘记返回 needs_confirmation。
|
||||||
|
- 精确忘记只删除当前 owner。
|
||||||
|
- Flows node 切换后不会重复执行工具。
|
||||||
|
- 取消后不再写记忆或发送音频。
|
||||||
|
|
||||||
|
### 必须保留的现有测试
|
||||||
|
|
||||||
|
```bash
|
||||||
|
.venv/bin/python app/tests/test_profile_memory.py
|
||||||
|
.venv/bin/python app/tests/test_memory.py
|
||||||
|
.venv/bin/python app/tests/test_identity.py
|
||||||
|
.venv/bin/python app/tests/test_search.py
|
||||||
|
.venv/bin/python app/tests/test_transport.py
|
||||||
|
.venv/bin/python app/tests/test_engine_e2e.py
|
||||||
|
```
|
||||||
|
|
||||||
|
### 真人网页验收
|
||||||
|
|
||||||
|
1. 文字:“记住我不吃香菜。”
|
||||||
|
2. disconnect/reconnect。
|
||||||
|
3. 文字:“我不吃什么?”
|
||||||
|
4. 语音重复 1–3。
|
||||||
|
5. 问实时问题,确认会搜索且显示来源。
|
||||||
|
6. 助手播长回答时插话,确认音频停止、插话未丢失。
|
||||||
|
7. 问“我是谁”,只能回答用户称呼,不能回答内部 ID。
|
||||||
|
|
||||||
|
### 性能验收
|
||||||
|
|
||||||
|
- 无工具普通对话不能因为 Flows 固定增加一次额外 LLM 调用。
|
||||||
|
- 记忆检索仍有超时和失败降级。
|
||||||
|
- 分别记录 VAD、STT、记忆检索、LLM 首 token、工具、TTS 首段和首音。
|
||||||
|
- 对比 legacy/flows 的 P50/P95;无工具首音出现明显回退时不得切默认。
|
||||||
|
|
||||||
|
## 十一、明确非目标
|
||||||
|
|
||||||
|
本次不要做:
|
||||||
|
|
||||||
|
- 唤醒词和 20 秒连续对话窗口;
|
||||||
|
- N5095 产品客户端、声卡 AEC 或阵列波束形成;
|
||||||
|
- 人脸自动确认说话者;
|
||||||
|
- Mem0、Chroma、Graphiti、LanceDB 等新存储;
|
||||||
|
- OpenClaw、Agno、LangGraph 或 LiveKit 迁移;
|
||||||
|
- 多 Agent、子 Agent 或复杂任务规划;
|
||||||
|
- 米家/Home Assistant 工具;
|
||||||
|
- systemd、自启动和公网暴露;
|
||||||
|
- 清理或重写所有 legacy 代码。
|
||||||
|
|
||||||
|
## 十二、回滚要求
|
||||||
|
|
||||||
|
1. `AI_AGENT_RUNTIME=legacy` 必须能绕过全部 Flows 代码。
|
||||||
|
2. 新数据库字段必须向后兼容,禁止 drop/rename 现有表或列。
|
||||||
|
3. 工具执行要有幂等键或 source turn,避免重试重复写入。
|
||||||
|
4. 新路径异常时,本轮可以无记忆继续,但不能自动切换后重复执行有副作用工具。
|
||||||
|
5. 部署前保留数据库与上一版本代码;回滚不能依赖重新生成用户数据。
|
||||||
|
|
||||||
|
## 十三、建议 Claude Code 的第一轮动作
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd ~/workspace/ai-companion
|
||||||
|
git status --short
|
||||||
|
git diff --check
|
||||||
|
|
||||||
|
# 先读这些文件,不要先改
|
||||||
|
sed -n '1,240p' services/bot_server.py
|
||||||
|
sed -n '240,560p' services/bot_server.py
|
||||||
|
sed -n '180,500p' app/engine.py
|
||||||
|
sed -n '1,220p' app/memory/base.py
|
||||||
|
sed -n '220,380p' app/memory/sqlite_store.py
|
||||||
|
```
|
||||||
|
|
||||||
|
然后只完成 Phase 1 spike,提交一份结论:
|
||||||
|
|
||||||
|
- 兼容的 flows 版本;
|
||||||
|
- 选择复用 Pipecat OpenAI-compatible `LLMService`,还是实现
|
||||||
|
`FallbackProvider → LLMService` 适配器;
|
||||||
|
- token、tool-call、取消和 context 的实测结果;
|
||||||
|
- 建议的最小生产集成 diff;
|
||||||
|
- 是否会破坏现有分句 TTS、RTVI 和 fallback。
|
||||||
|
|
||||||
|
未经 spike 结论,不进入 Phase 3。
|
||||||
|
|
||||||
Reference in New Issue
Block a user