ylhan
2ef6fe215c
背景：方案文档写"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