OpenClaw 的实现逻辑
之前了解到OpenClaw其实是AI Agent（智能体）框架,而非聊天ai机器人,更像一个虚拟员工，能够接管的电脑工作流。
OpenClaw核心架构
OpenClaw本身并不生产智力，它是一个连接器和指挥官。
- 大脑（外部 LLM）： OpenClaw 并不自带大模型，而是通过 API 接入外部LLM模型。它将用户的模糊指令发送给大模型，获取逻辑拆解后的执行计划。
- 躯干（本地/云端部署）： 它采用本地优先设计，OpenClaw部署在你自己的电脑、私有服务器上，直接访问的本地文件系统。
- 感官（即时通讯集成）： 也就是它的交互入口，一般为常用的聊天软件。通过这些App给它发指令。
- 执行器（工具调用）： 它拥有丰富的插件/工具集。当大模型决定"需要搜索网页"或"需要修改 Excel"时，OpenClaw 会调用相应的本地脚本或 API 去执行具体操作。
OpenClaw是如何使用ai模型
OpenClaw 对 AI 的利用主要体现在以下三个维度：
- 意图解析与任务拆解：AI负责理解你的自然语言并将其转化为一系列可执行的代码指令。
- 持久记忆：本地存储交互历史和配置。
- 自动化工作流的"闭环"。
OpenClaw的本质是把大模型的推理能力与本地系统的操作权限结合在了一起，给与ai更多的权限与操作空间，而不是仅仅局限于写代码文件边界和聊天对话。
流式传输形态
由于会议记录的asr需要做流式传输，所以先分清流式传输形态以权衡最佳选择
HTTP前端分片上传（HTTP streaming / chunked） 和 WebSocket 都可以做“流式传输”，但它们的设计目标和通信模式其实差别很大，简单理解：
- HTTP前端分片：客户端分片发请求 → 服务端一段一段返回
- WebSocket：客户端和服务器 随时互发消息
通信模型区别
-
HTTP前端分片
特点：客户端发请求，服务器持续返回数据块。 -
WebSocket
特点：全双工，双向实时，一次连接长期存在。
👉 我做的主要是会议记录，稳定性和准确性要比延迟更加重要，即使用前端切段音频，后端维护session状态。
http前端分片可以使模型看到更长的上下文，能够提升一些稳定性和准确性，http前端分片依然有个很严峻的挑战，说话人分离。
会议记录流式传输最终方案
最终方案流程为以下两步：
- http分片传输session期间：仅仅做asr，给前端暂时返回。
- session接收is_final的后处理：说话人分离diarization+说话人身份校验，一次性全部返回给前端。