ylhan
2ef6fe215c
新增 Pipecat 传输层实验报告；方案 §10 记录当前卡点
背景：方案文档写"Pipecat 作为唯一会话管线框架"，但核实后发现
代码里它只在 requirements.txt 里（零引用）。于是做实验验证架构问题：
Pipecat 该用多深——只做传输（A），还是按框架 service 模型重构（B）。
新增 P0-Pipecat传输层实验报告.md
- 传输层跑通：信令（47–280ms）、ICE 连通、data channel、双向媒体轨
- 帧路由未通：自定义处理器的 process_frame 调用次数为 0，
连自己注入的 StartFrame 都没进去；引擎从未运行
- 现象：连接全对、音轨协商成功、助手永远不说话，日志里一条错误都没有
- 记下 8 个集成坑，每个都表现为"什么都没发生"
- 结论：实验未能支持 A 方案，反而间接给了 B 更多理由；
但根因未定位，两种可能必须区分（接线错误 vs 模型不兼容）
方案 §10 更新
- 第 1 步改为"服务端 WebRTC 入口 + 客户端骨架"，状态标注为
"传输层跑通、帧路由未通"
- 新增 1b 步：查清帧路由根因 → 定 A/B 方案，标为当前卡点
- header 加注实验状态与 A/B 待定
- 架构图补传输层，标注"实验，帧路由未通"
顺带修正
- 局域网于当日重新编址（192.168.0.x → 172.16.1.x），
架构图里的服务器地址更新
- 报告数量 4 → 5
2026-09-15 17:55:53 +08:00
..
2026-09-15 17:55:53 +08:00
2026-09-14 17:02:12 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 17:55:53 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00