大模型把“会理解、会推理、会生成”的能力补齐了不少，但很多 AI 产品仍停在聊天窗口里。真正进入屏幕、人形机器人、AR/VR、数字人导览、车载座舱这类终端时，问题会变得更具体：它不只要回答问题，还要看起来像在场、能听能说、能做动作，并且能被开发者轻量接入和二次开发。
6 月 27 日，OSCHINA AI 创新沙龙上海站围绕 AI 创新产品展开交流。魔珐星云以具身交互智能平台代表身份参与分享，这个方向值得开发者关注：AI 产品的竞争点，正在从“模型能不能答”扩展到“终端能不能自然交互”。
只有大模型还不够：终端需要一条交互链路
对话框里的 AI 交互很短：用户输入文本，模型返回文本。但终端里的 AI 交互通常是一条链路：
- 语音输入：麦克风采集、降噪、ASR 转写。
- 意图理解：大模型或业务模型判断用户要什么。
- 状态管理：设备当前在哪个场景、上一轮说过什么、能不能打断。
- 表达输出：TTS、口型、表情、动作、屏幕 UI 或 AR 内容。
- 设备控制：调用机器人、摄像头、传感器、业务系统或本地应用。
这就是“具身交互底座”的价值所在。它不是替代大模型，而是把模型能力包进一个可运行、可感知、可表达的终端系统里。对开发者来说，关键不只是模型 API，而是如何把感知、推理、动作、渲染、设备协议串起来。
为什么开源和轻量化很关键
AI 终端形态差异很大。一个商场导览屏、一个陪伴机器人、一个 VR 训练应用，对延迟、算力、摄像头、麦克风、网络稳定性和隐私边界的要求都不同。如果底座过重，开发者会被集成成本拖住；如果完全封闭，业务团队又很难改出自己的交互体验。
因此，面向终端的具身交互平台至少要关注几件事：
- 轻量运行：边缘设备、浏览器、移动端或机器人控制板不一定有充足算力。
- 模块可替换：ASR、LLM、TTS、动作系统、数字人渲染最好能按需替换。
- 协议清晰：终端动作不应只藏在 SDK 内部，最好能用事件、HTTP、WebSocket 或消息队列描述。
- 二次开发友好：开发者能接入自己的知识库、业务 API、设备控制逻辑。
源摘要提到“轻量化、可开源二次开发的具身交互底座”，这其实切中了 AI 应用落地的一个硬问题：产品不是在模型 Demo 里交付，而是在真实终端、真实网络、真实用户打断中交付。
可以这样实践：用 WebSocket 串起一个最小具身交互原型
下面是一个可运行的最小示例，用 Python 模拟“终端事件 -> 智能体处理 -> 动作输出”的链路。它不代表魔珐星云平台的真实接口，只是一个便于开发者理解具身交互架构的伪项目骨架。
运行前需要 Python 3.10+。
mkdir embodied-agent-demo
cd embodied-agent-demo
python -m venv .venv
source .venv/bin/activate
pip install fastapi uvicorn websockets
创建 server.py：
from fastapi import FastAPI, WebSocket
import uvicorn
app = FastAPI()
def decide_action(text: str) -> dict:
"""Replace this with your LLM, RAG, or business rules."""
if "你好" in text or "hello" in text.lower():
return {
"speech": "你好，我在。需要我介绍今天的活动吗？",
"emotion": "friendly",
"motion": "wave_hand"
}
if "带我去" in text:
return {
"speech": "好的，我会打开导航，并用箭头标出路线。",
"emotion": "focused",
"motion": "point_forward"
}
return {
"speech": "我理解了。这个问题我会先查询业务系统再回答。",
"emotion": "thinking",
"motion": "idle"
}
@app.websocket("/agent")
async def agent_socket(ws: WebSocket):
await ws.accept()
while True:
event = await ws.receive_json()
user_text = event.get("text", "")
action = decide_action(user_text)
await ws.send_json({
"type": "embodied_action",
"input": user_text,
"output": action
})
if __name__ == "__main__":
uvicorn.run(app, host="127.0.0.1", port=8000)
创建 client.py：
import asyncio
import json
import websockets
async def main():
async with websockets.connect("ws://127.0.0.1:8000/agent") as ws:
for text in ["你好", "带我去主会场", "帮我查一下议程"]:
await ws.send(json.dumps({
"device_id": "demo-screen-001",
"modality": "speech_text",
"text": text
}, ensure_ascii=False))
reply = await ws.recv()
print(reply)
asyncio.run(main())
启动服务并测试：
python server.py
另开一个终端运行：
source .venv/bin/activate
python client.py
你会看到类似输出：
{"type":"embodied_action","input":"你好","output":{"speech":"你好，我在。需要我介绍今天的活动吗？","emotion":"friendly","motion":"wave_hand"}}
这个小例子里，speech 可以接 TTS，emotion 可以驱动数字人表情，motion 可以映射到机器人动作或屏幕动画。真正上线时，你可以把 decide_action() 替换成大模型调用、知识库检索、设备控制策略或企业业务 API。
落地时别忽略工程边界
具身交互听起来很“拟人”，但工程上要克制。终端系统比聊天机器人更容易暴露延迟、误识别和动作不一致的问题。
开发者评估这类平台或自研底座时，可以用下面的清单做第一轮判断：
- 端到端延迟是否可控，尤其是语音输入到语音输出的耗时。
- 网络断开时是否有降级策略，例如本地 FAQ、固定动作、离线唤醒。
- 动作、表情、语音是否能被统一编排，避免“嘴在说 A、手在做 B”。
- 是否支持接入自己的模型、知识库、账号体系和设备协议。
- 终端采集的音视频数据如何存储、脱敏和授权。
- 开源或可二次开发部分的边界是否清楚，避免后期被封闭接口卡住。
AI 终端时代不是把聊天框搬到屏幕上，而是让模型进入一个有身体、有场景、有反馈的系统。魔珐星云在源创会分享的具身交互方向，提醒开发者把注意力从“单次回答质量”扩展到“完整交互体验”。真正能落地的 AI 产品，往往赢在这些看似琐碎但决定体验的链路上。