大家好，我们是 StackChan + M5 CoreS3 的深度用户。最近几个月把 StackChan 改造成了「AI 工作秘书」，过程中解决了社区几个长期 open 的问题（#11 #103 #54 #108 ），想把这些成果回馈上游，也想听听维护者希望以什么形式收这类贡献。
我们做了什么
1. xiaozhi-esp32 基线升级：v2.2.4 → v2.5.0（关联 #11 ）
按 #11 的建议把 vendored 的 xiaozhi-esp32 升到 v2.5.0（单 AFE 重构 + 原生 notify 支持），适配了 7 类破坏性变更（NetworkResult/expected 迁移、esp-sr 预编译库 wrap、枚举删除等），已在 CoreS3 真机稳定运行多天（含 8.5h+ 连续运行零重启的远程遥测验证）。这是目前我们验证过最顺畅的版本 ：待机拍照、连续对话、插播播报全部正常。
2. 拍照掐断语音（关联 #103 ）
#103 的「speech 期间 camera.take_photo 后 TTS 静默/音序错乱」我们也踩了，根因在资源冲突而非音频管线本身：
JPEG 编码器需要 ~8KB 内部 RAM，与音频管线相撞；改为 PSRAM 固定 96KB 缓冲 做 JPEG 输出；
拍照前真正拆卸唤醒词引擎 （对话态小智会关唤醒词所以没事，待机态它开着才冲突），拍完无条件恢复；
内存守卫语义改为「宁漏拍不重启」。
3. AI Agent TTS 卡顿（关联 #54 ）
我们的路径：TTS 改走 notify 流式播报 （上游 xiaozhi-esp32 PR #2191 的引擎，v2.5.0 原生含），音频时长与内存解耦；另修了一个移植期引入的事件位撞车 （PLAYBACK_DRAINED 与 START_LISTENING 同为 1<<10，一个 bit 解释了"插播被掐断/每轮要重喊唤醒词"全部玄学）。现在是真·流式边下边播，长度不再受限。
4. ESP-IDF 5.5 全新 clone 编译失败（关联 #108 ）
我们也撞了，主因是 esp-sr 预编译库的符号缺失 （源码里搜不到的引用）：补一个 esp_log_wrap.c + 两个链接选项（wrap 标志）即可通过；另有一个易踩点：本地覆盖组件目录必须 fullclean 才会进构建。可以整理成文档或直接提 PR。
5. 附带：给 78/esp-ml307 提了一个修复（PR 78/esp-ml307#61 ）
排查「间歇性 PANIC 重启（每天 2-4 次）」时定位到 EspTcp 在被动断开后析构的 use-after-free 竞态 （等待接收任务退出的逻辑被 fd != -1 短路）。已向组件上游提 PR：78/esp-ml307#61 ，修复后 8.5h+ 零重启。该组件是 xiaozhi-esp32 的依赖，合并后大家都能受益。
AI 工作秘书改造（简述）
在上述基线上，我们把 StackChan 改造成了「工作秘书 + 桌面陪伴」终端，核心思路是把机器人当作整个 AI Agent 的语音入口 ：
语音派活 ：对机器人说话 → 局域网桥接服务派发给本机 AI Agent（Hermes）执行 → 结果推送到飞书（真机 79 秒端到端）Agent 能干的活 = 机器人能指挥的活 ：Hermes 通过**飞书 CLI（lark-cli）**接入飞书——凡是 CLI 授权范围内的能力（日历、任务、消息、文档、审批、多维表格…）都可以被机器人语音调用，且随 CLI 授权扩展自动增长，无需逐个功能适配。对着机器人说"帮我看看明天日程"、"把这个整理成文档发飞书"，效果等同于直接指挥 Agent——机器人只是把语音换成文字指令的入口，能力上限取决于 Agent 侧而不是机器人侧亲测跑通的闭环场景 ：语音下达 → Hermes 执行（联网搜索、知识/学习资料检索、制定学习计划、日程安排、设置提醒、会议纪要整理等）→ 结果推送飞书 → 机器人开口播报完成情况，整条链路日常在用主动开口 ：不只是被动应答——飞书日程到点、久坐/喝水（摄像头视觉判定）、任务完成回执，都会主动插播说话（插播完自动恢复被中断的对话）健康监测（桥接侧，固件零改动） ：机器人定时拍照 → 桥接做图像分析（在座/坐姿/水杯水位，视觉模型走 OpenAI 兼容协议可热切换，免费的 GLM-4V-Flash 即够用）→ 规则引擎防骚扰（连续多轮确认 + 冷却时间 + 每日上限）→ 触发时机器人开口提醒 + 飞书留痕配套本地 Dashboard ：桥接自带一套 Web 后台——照片按场景分类与灯箱预览、在座/坐姿/水位多泳道时间轴、日志检索、设备稳定性遥测（复位原因 + 内存水位）、以及上述所有配置的远程管理热配置通道 ：拍摄位角度、空闲休眠等全部免烧录远程可调
架构上遵守「机器人只做耳/眼/手」：长内容完整推飞书存档，同时自动提取 120 字以内的语音结论让机器人开口反馈（兼顾信息完整性与播报体验）；桥接只监听局域网。
想请教的
以上代码量约 14 commits / +4700 行（外层 fork 分支 + xiaozhi 补丁 + 组件修复），直接整分支提 PR 太重，我们猜测维护者可能更希望拆分。想请教 @m5stack 维护者：
基线升级 + 上述修复，希望整分支 PR、按主题拆多个小 PR，还是先出文档/补丁包？
[bug] TTS audio goes silent after camera.take_photo during speech (audio stream sequence desync), v1.4.4 #103 [bug] voice (tts) of ai agent is very choppy #54 Current firmware does not build from a clean clone using ESP-IDF 5.5.5 #108 工作秘书类改造（依赖外部 Agent/飞书）如果不适合进主线，我们也可以只出技术文档供社区参考。
所有改动都在真机上日常使用验证过，欢迎交流。
代码公开仓库https://github.com/artrobin-cn/StackChan/tree/public/work-secretary-v2.5
大家好，我们是 StackChan + M5 CoreS3 的深度用户。最近几个月把 StackChan 改造成了「AI 工作秘书」，过程中解决了社区几个长期 open 的问题（#11 #103 #54 #108），想把这些成果回馈上游，也想听听维护者希望以什么形式收这类贡献。
我们做了什么
1. xiaozhi-esp32 基线升级：v2.2.4 → v2.5.0（关联 #11）
按 #11 的建议把 vendored 的 xiaozhi-esp32 升到 v2.5.0（单 AFE 重构 + 原生 notify 支持），适配了 7 类破坏性变更（NetworkResult/expected 迁移、esp-sr 预编译库 wrap、枚举删除等），已在 CoreS3 真机稳定运行多天（含 8.5h+ 连续运行零重启的远程遥测验证）。这是目前我们验证过最顺畅的版本：待机拍照、连续对话、插播播报全部正常。
2. 拍照掐断语音（关联 #103）
#103 的「speech 期间 camera.take_photo 后 TTS 静默/音序错乱」我们也踩了，根因在资源冲突而非音频管线本身：
修完连续验证多轮 SEATED/水杯拍照 + 语音共存，无复现。
3. AI Agent TTS 卡顿（关联 #54）
我们的路径：TTS 改走 notify 流式播报（上游 xiaozhi-esp32 PR #2191 的引擎，v2.5.0 原生含），音频时长与内存解耦；另修了一个移植期引入的事件位撞车（PLAYBACK_DRAINED 与 START_LISTENING 同为 1<<10，一个 bit 解释了"插播被掐断/每轮要重喊唤醒词"全部玄学）。现在是真·流式边下边播，长度不再受限。
4. ESP-IDF 5.5 全新 clone 编译失败（关联 #108）
我们也撞了，主因是 esp-sr 预编译库的符号缺失（源码里搜不到的引用）：补一个
esp_log_wrap.c+ 两个链接选项（wrap 标志）即可通过；另有一个易踩点：本地覆盖组件目录必须 fullclean 才会进构建。可以整理成文档或直接提 PR。5. 附带：给 78/esp-ml307 提了一个修复（PR 78/esp-ml307#61）
排查「间歇性 PANIC 重启（每天 2-4 次）」时定位到 EspTcp 在被动断开后析构的 use-after-free 竞态（等待接收任务退出的逻辑被
fd != -1短路）。已向组件上游提 PR：78/esp-ml307#61，修复后 8.5h+ 零重启。该组件是 xiaozhi-esp32 的依赖，合并后大家都能受益。AI 工作秘书改造（简述）
在上述基线上，我们把 StackChan 改造成了「工作秘书 + 桌面陪伴」终端，核心思路是把机器人当作整个 AI Agent 的语音入口：
架构上遵守「机器人只做耳/眼/手」：长内容完整推飞书存档，同时自动提取 120 字以内的语音结论让机器人开口反馈（兼顾信息完整性与播报体验）；桥接只监听局域网。
想请教的
以上代码量约 14 commits / +4700 行（外层 fork 分支 + xiaozhi 补丁 + 组件修复），直接整分支提 PR 太重，我们猜测维护者可能更希望拆分。想请教 @m5stack 维护者：
所有改动都在真机上日常使用验证过，欢迎交流。
代码公开仓库
全部改动已公开在本人 Fork（已按 v2.5.0 基线整理，可直接构建）：
https://github.com/artrobin-cn/StackChan/tree/public/work-secretary-v2.5