ClawStage 想把 AI 从“答题机器”变成家庭里的常驻角色不卖家电逻辑卖的是“居住感”。从工程侧看这件事真正的难点不是接一个大模型 API而是把语音唤醒、对话调度、长期记忆和情绪状态串成一条始终在线的链路。这篇文章会拆解 ClawStage 背后的技术画像并给出一套最小可复现的“AI 在场设备”验证流程包括语音链路选型、Agent 状态管理、接口调用思路和资源占用观察方法。如果你准备做 AI 陪伴硬件、多模态语音助手或家庭 Agent 方向可以直接收藏这篇。1. 核心能力速览需要提前说明ClawStage 目前在公开渠道的产品细节还不算多下面这张表更多是基于“AI 在场设备 / 情感陪伴硬件”这条产品定位倒推的技术画像。如果你手头有官方 SDK 或开发者文档应以实际接口为准。能力项说明产品定位AI 陪伴硬件强调“人在场”的情感连接而非单纯智能家居控制核心技术链路语音唤醒 - 前端信号处理 - ASR - 大模型对话 - Agent 任务调度 - TTS - 音响反馈关键差异化长期记忆、持续在场、角色一致性、多轮情感响应目标用户独居用户、老人陪护、儿童陪伴、情绪支持场景硬件门槛尚不确定需等官方公布从同类产品看需要麦克风阵列、扬声器、低功耗主控或上位机联网启动方式官方未公布概念验证阶段可自行搭建语音网关服务是否支持 API不确定建议关注官方开发者计划是否支持批量任务不确定从家庭场景看多设备管理需要会话隔离与队列机制主要风险隐私边界、常开麦克风、声音角色授权、情感依赖伦理从这张表能看出ClawStage 真正值得技术人关注的不是“它用了哪家的大模型”而是“它怎么让 AI 在一个物理空间里保持在场”。在场意味着 AI 不能每次对话都从零开始它得记得上次聊到哪、知道用户当下的情绪状态、能在不打扰的情况下主动提供存在感。这三件事单拆开都不难合在一起就是典型的 AI Agent 工程问题。2. 适用场景与使用边界2.1 适合谁最典型的落地场景有三类。第一类是独居年轻人下班回家后能有一个非任务型的对话对象不用张嘴就是“打开灯”而是可以聊今天的状态。第二类是老人陪护语音交互门槛低设备如果能记住老人的用药习惯、日常作息、家人的称呼关系价值会比普通智能音箱高很多。第三类是儿童陪伴但这一场景对内容审核和角色边界的要求最高。从开发者角度看ClawStage 这类产品还适合作为“多模态 Agent 的载体”来研究。你不需要真的购买硬件只要把你的大模型服务包装成一个带记忆、带状态、带主动触发能力的后端再通过任何语音前端接入就能复刻九成以上的核心交互体验。2.2 不适合什么它不适合被当作任务型智能家居中控来买至少目前的叙事重点不在“控制”上。如果你需要的是连续执行确定性指令、跨设备自动化那成熟的智能音箱或 Home Assistant 方案更合适。ClawStage 的价值在高频情感对话和长期关系建立上这要求用户愿意投入时间养一个“AI 角色”不是所有用户都有这个耐心。2.3 使用边界与合规约束必须把隐私问题放在第一位。这类产品要持续检测唤醒词意味着麦克风长时间处于待命状态。在设计上一定要做本地语音活动检测VAD和本地唤醒只有唤醒成功后才把音频送到 ASR 或大模型服务。音频传输链路要加密敏感信息要脱敏历史记录要支持用户手动删除。如果涉及儿童声音、真人声音克隆、特定角色音色必须先确认授权链条完整。没有授权的声音和形象无论是训练还是合成都存在版权和肖像权风险。情感陪伴还有一个伦理边界AI 可以承接情绪但不能伪装成真人、不能诱导用户过度依赖、不能替代专业心理干预。这些约束最好在设计阶段就写进产品规范而不是等舆情出来再补救。3. 关于“AI 在场”的技术拆解ClawStage 想卖的“陪你说话的家”从技术角度可以拆成五个模块。3.1 持续在线的感知层设备不能只在用户喊唤醒词时才工作。它需要随时检测环境声判断是否有人说话、说话对象是不是自己、当前是不是适合搭话的时间。更准确的表述是设备需要一个感知状态机状态包括“待机”“聆听”“思考”“说话”“静默等待”。每个状态之间的跃迁条件要设计得很清晰否则会出现设备突然插话、应答延迟、或者说完话后仍然监听导致的误触发。3.2 记忆层对话大模型本身没有长期记忆ClawStage 这类产品要想让用户感觉“它懂我”必须自己搭建记忆层。最基础的做法是会话级记忆保存最近 20 轮对话进阶做法是用户画像记忆记录用户提到过的家人、宠物、工作事件、情绪偏好更进阶的做法是事件记忆把重要事件按时间线存储支持跨天引用。记忆层建议独立成服务不要塞进模型上下文里否则成本会随着对话轮数线性上涨。3.3 角色一致性层情感陪伴设备上一个关键问题是用户不喜欢“每次换一个陌生人”的聊天体验。角色一致性层负责把 AI 的角色设定固定下来包括说话风格、回应尺度、是否主动共情、对哪些话题保持克制。具体实现上可以使用一条系统提示词做“角色基线”再叠加少量示例对话做风格约束但不要把整套人设全部堆进提示词应该把用户长期记忆、角色设定、当前会话意图分层管理。3.4 响应生成和 TTS 层对话文本生成之后还要过一遍语音合成。陪伴设备对 TTS 的要求比普通助手高很多因为用户会长时间听。停顿节奏、语气词、语速变化、句尾上扬都会影响“像不像真人”。这一层建议做成可替换的音频输出服务方便在本地引擎和云端引擎之间切换。3.5 主动发起能力这是“在场感”和普通问答机器人的最大区别。设备不能只是被动响应它需要在用户回家时主动问一句“今天回来得比平时晚要不要先喝点水”也能在用户连续沉默一段时间后选择不打扰。主动发起能力实际上是一套定时任务加情绪判断规则风险在于容易演变成烦人推送所以需要做打扰等级控制。4. ClawStage 最小复刻环境准备与前置条件如果你不想等 ClawStage 的官方硬件想先验证“一个会陪你说话的 AI 设备”在技术上到底跑不跑得通可以按下面这套思路搭一个 demo。这套架构不是 ClawStage 的官方部署方案而是通用的技术验证模板。4.1 硬件与环境清单部件最低要求备注主控设备树莓派 4B / 旧笔记本 / 小主机都可以需要能联网能跑 Python 服务麦克风USB 麦克风即可有麦克风阵列更好可以增强定向拾音扬声器任意 3.5mm 音箱输出质量会直接影响陪伴感操作系统Ubuntu 22.04 或 Windows 10/11涉及音频驱动Linux 相对方便大模型后端云端 API 或本地 Ollama / vLLM本地模型需要按实际显存测试ASR 引擎Whisper / FunASR / 云厂商 ASR需要支持流式或分片识别TTS 引擎Edge-TTS / CosyVoice / 云厂商 TTS优先选能保存音色参数的引擎这里不写死任何具体显存数字因为不同模型版本差别太大。稳妥的验证方式是先用云端 API 打通逻辑再把某个模块替换成本地模型逐个观察延迟变化。4.2 Python 环境建议使用 Python 3.10 以上版本单独建虚拟环境mkdir ai-presence-demo cd ai-presence-demo python3 -m venv venv source venv/bin/activate # 基础依赖 pip install pyaudio numpy soundfile requests # 如果你打算接入 OpenAI 兼容接口 pip install openai如果你的电脑没有安装 PortAudio在 Ubuntu 上先执行sudo apt update sudo apt install portaudio19-dev python3-pyaudio4.3 服务化架构不要把语音识别、大模型对话、语音合成全部写在一个 main.py 里。建议用 Docker Compose 起三个独立服务方便单独重启和替换。下面是通用模板需要按你自己的模型地址和端口调整version: 3.9 services: asr: image: your-asr-image:latest ports: - 9001:9001 environment: - ASR_LANGUAGEzh - DEVICEcpu llm: image: your-llm-gateway:latest ports: - 9002:9002 environment: - MODEL_NAMEqwen2.5-7b-instruct - OPENAI_BASE_URLhttp://host.docker.internal:11434/v1 tts: image: your-tts-service:latest ports: - 9003:9003 environment: - VOICE_IDdefault实际运行时你需要 yml 里出现的是自己打包好的镜像名而不是这几个示例名。5. 启动一个最简“陪伴会话”这一节把整个链路跑通。我们不做复杂唤醒词先实现一个最简版本按键录音 - 语音识别 - 大模型生成回复 - TTS 播放。这样能最快验证链路有没有问题。5.1 会话循环代码示例import requests import sounddevice as sd import numpy as np import queue import io import wave SAMPLE_RATE 16000 DURATION 5 q queue.Queue() ASR_URL http://127.0.0.1:9001/transcribe LLM_URL http://127.0.0.1:9002/v1/chat/completions TTS_URL http://127.0.0.1:9003/synthesize def record_once(durationDURATION): print(开始录音请说话...) audio sd.rec(int(duration * SAMPLE_RATE), samplerateSAMPLE_RATE, channels1, dtypeint16) sd.wait() return audio.flatten() def asr_transcribe(audio): buffer io.BytesIO() with wave.open(buffer, wb) as wf: wf.setnchannels(1) wf.setsampwidth(2) wf.setframerate(SAMPLE_RATE) wf.writeframes(audio.tobytes()) response requests.post(ASR_URL, files{file: buffer.getvalue()}, timeout30) return response.json().get(text, ) def llm_chat(user_text, history): history.append({role: user, content: user_text}) payload { model: your-chat-model, messages: history, temperature: 0.8 } response requests.post(LLM_URL, jsonpayload, timeout60) reply response.json()[choices][0][message][content] history.append({role: assistant, content: reply}) return reply def tts_speak(text): requests.post(TTS_URL, json{text: text, voice: friendly}, timeout30) if __name__ __main__: history [{role: system, content: 你是一个住在用户家里的AI伙伴语气自然、简短会主动记住用户提到的小事。}] while True: try: audio record_once() text asr_transcribe(audio) if not text: continue print(f你说: {text}) reply llm_chat(text, history) print(fAI说: {reply}) tts_speak(reply) except KeyboardInterrupt: break注意ASR、TTS 接口路径是我根据通用架构占位的实际要以你启动的服务文档为准。第一次跑通的关键是先把每个服务单独用 curl 验证再跑组合链路。5.2 一个稳定的“在场”会话需要什么上面的循环只是基础对话还谈不上陪伴。要让用户感觉 AI 在场会话服务还要多做三件事一是持久化历史。把 history 存储到本地 SQLite 或 Redis重启后还能恢复。二是加入时间感知。系统每次调用大模型前可以自动追加当天日期、星期、用户上次活跃时间让回答有真实世界的时间坐标。三是加入“用户画像变量”。比如在 system prompt 里动态填充用户姓名、常用称呼、宠物名字等字段。# 动态构造 system prompt 示例 system_prompt f 你是一个住在用户家里的AI伙伴。 当前时间{current_time} 用户姓名{user_profile.get(name, 朋友)} 用户家里提到过的人{user_profile.get(family, [])} 你要记住这些信息但不要一次全部说出来自然地在对话中回应。 5.3 判断链路是否跑通的三个标准从手机录音到 AI 回复播放端到端延迟不能超过 3 秒否则对话节奏会变得很不自然。TTS 播放的时候麦克风不要继续采集这段音频否则会把 AI 自己说的话当作用户输入形成回声循环。连续对话 10 轮以上模型不会忘记用户在第 3 轮提到的关键信息。如果忘记说明记忆层还没有生效。6. 记忆层与 Agent 状态管理的接口设计ClawStage 这类产品如果把所有历史都塞进大模型上下文成本会失控响应时间也会越来越长。更合理的做法是让记忆层成为一个独立服务对外提供几个接口。6.1 记忆服务接口接口作用建议请求方式/memory/save保存一条用户事实或事件POST/memory/search按关键词或时间范围检索记忆GET/memory/delete删除某条记忆满足用户删除权DELETE/session/list查看当前所有活跃会话GET“AI 在场”本质上是多个会话状态的持续管理。用户和设备的交互过程可以按“短对话 - 会话 - 长期记忆”三层去存储。短对话只保存在内存会话结束就存入时序数据库只有经过信息抽取的稳定事实才进入长期记忆。# 检索用户上次提到的“加班”相关记忆 curl -X GET http://127.0.0.1:9100/memory/search?query加班limit5 \ -H Authorization: Bearer YOUR_TOKEN返回内容一般是一段 JSON里面包含记忆 ID、记忆内容、时间戳和来源会话 ID。如果返回空说明前面几轮对话还没有被抽取成记忆要检查记忆抽取任务有没有执行。6.2 主动触发与批量会话调度一个家庭里可能同时存在多个用户需要支持多会话隔离。不能只用一个全局 history否则家庭成员之间会互相串记忆。建议用user_id作为会话隔离维度。当设备检测到陌生声音时先不调用大模型而是先做一次语音特征标记询问对方身份再把对话挂到对应 user_id 下。批量任务在陪伴设备上的体现是“定时主动关心”。比如每天上午询问天气晚上睡前聊一天状态。把这些任务做成 cron 表达式放到调度队列里由 Agent 服务统一触发而不是在对话循环里写死。# 主动关心任务的伪代码 scheduled_jobs [ {job_id: morning-check, cron: 0 9 * * *, user_id: u_001}, {job_id: evening-check, cron: 0 22 * * *, user_id: u_001}, ] def run_scheduler(): for job in scheduled_jobs: if crontab_match(job[cron], now()): context memory_service.summarize_daily(user_idjob[user_id]) reply llm_chat_with_active_trigger(job[user_id], context) tts_speak_with_volume_control(reply)主动触发不是越高频越好。每个用户每天接收主动消息的上限最好设置为 3 到 5 次之间留足间隔。否则用户会觉得家里多了一个“催命 AI”。7. 接口 API 与外部工具接入完整的 AI 在场设备不能只靠语音对话生活它可能还要和日历、天气、健康数据、IoT 设备联动。这意味着后端需要一个统一的工具调用协议。OpenAI 的 function calling 是当前通用性较高的协议ClawStage 如果最终开放开发者平台大概率也会兼容类似机制。7.1 用 Function Calling 控制外部工具以查天气为例{ role: assistant, content: null, tool_calls: [ { id: call_001, type: function, function: { name: get_weather, arguments: {\city\: \北京\} } } ] }执行流程是把用户语音转成文本后交给大模型模型判断需要查询天气返回对应 tool_call后端代码执行真实天气接口再把结果回填给模型模型生成自然语言回答最后交给 TTS 播放。网络请求示例用 Python 写import requests API_BASE http://127.0.0.1:9002/v1/chat/completions payload { model: your-chat-model, messages: [ {role: user, content: 今天出门要不要带伞} ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市的实时天气, parameters: { type: object, properties: { city: {type: string} }, required: [city] } } } ] } resp requests.post(API_BASE, jsonpayload, timeout30) print(resp.json())7.2 调用失败重试建议外部工具接口不是永远稳定。对天气、日历这类查询失败的兜底方案是告诉用户“稍等一下我再试”但不要陷入重复请求的死循环。建议每次外部调用最多重试两次两次失败后直接给用户一个降级回答。工具调用日志要完整记录输入参数和返回状态方便事后排查。8. 资源占用与性能观察硬件产品的资源占用需要实测才能下结论但我们可以聊几个需要重点观察的维度和通用的优化方向。8.1 延迟预算情感陪伴对话与普通问答的延迟要求不完全一样。普通问答快一点慢一点都能接受但语音对话一旦超过 2 到 3 秒用户会下意识重复说话。建议按模块记录时间消耗唤醒词检测应控制在 0.2 秒内常驻内存占用尽量低于 200 MB。ASR 识别5 秒音频流式识别目标在 1 秒内返回。LLM 首 token 延迟使用流式输出更好可以先让 TTS 播放“嗯嗯”的反馈声音再逐渐输出正文。TTS 合成需要能边生成边播放而不是等整段文本合成完才播。8.2 显存与内存观察方法如果你使用本地大模型建议用nvidia-smi观察模型加载前后的显存占用用free -h观察内存用htop观察 CPU。根据模型参数量不同显存占用会有很大差异不要直接照搬网上任何人的数字。一个正确的观察方式是# 启动本地模型服务前记录 GPU 显存 nvidia-smi --query-gpumemory.used --formatcsv # 启动后再次记录 nvidia-smi --query-gpumemory.used --formatcsv只要两次记录的差值稳定就说明模型加载完成。后面每多跑一轮对话如果显存占用还会持续上涨说明存在缓存没释放的泄漏问题。8.3 降低资源占用的思路如果你打算在低功耗设备上常驻运行优先做这些优化ASR 使用小模型做预识别只有置信度低时才调用更大模型。实际上更合理的顺序是本地 VAD 先判断有没有人说话。TTS 缓存高频短语例如“嗯”“我在听”“然后呢”不需要每次合成。LLM 设置最大 token 数和上下文窗口上限防止长对话后服务内存膨胀。把记忆检索结果按相关性截断不要一股脑塞进 prompt。9. 常见问题与排查方法问题现象可能原因排查方式解决方案设备录音后没有识别出文字麦克风音量低或采样率不匹配先录制 wav 文件检查波形调整增益统一采样率为 16000 HzAI 回复延迟过高大模型服务占用过高或网络延迟大分别测试 ASR、LLM、TTS 单独响应时间换更小模型、打开流式输出、或迁到更低延迟的 APIAI 说话时把自己当成用户没有做回声消除或播放抑制观察识别日志是否出现 AI 自己的话增加播放状态锁播放时暂停录音长期对话后回复质量下降历史过多导致上下文混乱或 token 超限查看实际发送的 token 数启用记忆抽取压缩历史到固定条数设备无缘无故搭话误唤醒或主动触发设计不合理查看唤醒词日志和定时任务日志提高唤醒阈值减少主动触发频率TTS 声音机械感严重音色参数或模型版本限制对比不同语音合成结果换成带情感控制的 TTS 引擎或调慢语速用户记忆串到另一个家庭成员缺少 session 隔离检查会话服务按 user_id 分组是否生效统一以 user_id 维度管理历史、记忆和主动任务排查时建议先忽略界面问题从日志入手。所有模块都要输出带时间戳的结构化日志尤其是唤醒状态变化和每次外部 HTTP 请求的耗时。否则问题一旦发生你会很难定位是哪一层拖慢了体验。10. 最佳实践与使用建议如果想把 ClawStage 这类思路做成一个可靠工程而不是停留在 demo请遵守下面这些实践。先说技术层面。第一次测试用小参数跑通链路再逐步增加复杂度。先关掉主动触发跑通“按键录音 - ASR - LLM - TTS”的闭环然后把按键改成离线唤醒词最后再引入任务调度和记忆持久化。每一步都保留一份可回滚的配置避免改坏后找不到可运行版本。建议把“最小可运行配置”单独写进 README方便过几个月再回来查阅。数据目录一定要分层管理原始录音、ASR 转写文本、模型回复、用户记忆、操作日志分散存储。原始录音不要长期保留转写完成后即可删除避免隐私文件堆积。模型参数和 prompt 模板要纳入版本管理你不能在改了一句系统提示词后才发现线上角色性格变了。输出内容在合成语音前建议先跑一遍敏感词过滤和隐私信息脱敏防止模型在对话中复述出用户不想重复的内容。然后是产品与合规层面。所有涉及用户音频的数据处理流程需要明确说明支持用户一键导出和删除个人数据。涉及声音复制或角色扮演时需要确保相关声音和形象获得了明确授权。情感陪伴产品还应该在对话中加入边界设定当用户表达严重的情绪困扰时设备应当鼓励用户寻求专业帮助而不是提供无边界的情感替代。这个规则可以通过系统提示词实现但仅靠提示词通常不够稳定更稳妥的做法是在服务端针对敏感信号执行独立的规则拦截。从商业化角度看ClawStage 这类产品的真正护城河不是硬件卖多少钱而是持续积累的真实用户关系数据和处理这些数据的合规工程能力。设备买到家只是开始后续的会话服务、记忆更新、角色进化才是用户愿意长期付费的原因。11. 总结与下一步ClawStage 这次想讲的“ AI 真正在场”本质上是在挑战 AI 产品的一个短板它能不能从按需问答变成一段持续关系。这个概念并不虚落到工程上就是感知层、记忆层、角色层、主动触发层和语音交互层的组合。对普通技术人来说在官方硬件和 SDK 还没公开前你完全可以先用自己的电脑、麦克风和开源模型把核心链路复刻出来。开头先验证的第一件事不是音色好不好听而是“闭环能不能在 3 秒内跑通”。这是所有陪伴体验的地基。最容易踩的坑是长期对话后历史无限膨胀和回声反馈只要提前做记忆压缩和播放抑制大部分体验问题都能解决。后续你可以顺着三个方向继续深入一是把开源的 ASR、LLM、TTS 换成更适合低功耗设备的模型组合二是给设备搭建真正的向量记忆库让 AI 能跨周、跨月记住用户的重要事件三是设计一套完整的用户授权与数据删除流程这决定了产品能不能规模化。等 ClawStage 公布更多官方技术细节后再拿你的这套方法论去对照会比直接看宣传稿理解得更深。