团队_招_了个不发工资的AI同事：不迟到、不忘事，30 秒把重点播完-平芜编程栈

文章目录

团队"招"了个不发工资的AI同事：不迟到、不忘事，30 秒把重点播完
- 一、为什么是"播报"，而不是再发一条群公告
- 二、搭底座：半天跑通"能说话"的最小闭环
- - 2.1 先说清楚：这底座不是 "ASR → LLM → TTS" 拼出来的
  - 2.2 模型侧：流式输出 \+ 关闭思维链
  - 2.3 表达侧：初始化星云 SDK
  - 2.4 调度层：分段播报、打断与状态机
  - 2.5 可插拔：换掉一个模块，播报不能散架
- 三、补齐认知：简简的"认知层"，不该只写在提示词里
- - 3.1 它知道什么：会议知识的底座不是"把纪要粘进去"
  - 3.2 它是谁、当前要做什么：三个设计决策都落在这一层
  - 3.3 它能不能真正进入业务：从"念待办"到"查系统"
  - 3.4 只靠提示词，她会怎么飘
- 四、设计决策二：四段式播报结构——把"念稿"变成"早会广播"
- 五、设计决策三：1\.05 倍语速 \+ 正装形象——"职场感"是配出来的，也是踩坑踩出来的
- - AI 端渲染
- 六、写在最后：数字同事的门槛，在接入之外

团队"招"了个不发工资的AI同事：不迟到、不忘事，30 秒把重点播完

起因是我们组的一条群公告：上周三，项目群里连发了 14 条消息——会议改期、缺陷认领、周报提醒、评审材料……混在表情包和"收到"里，第二天还是有人没看到截止时间，材料迟交了一整天。
组长在复盘会上说了句气话：“这些事要是有个广播员天天早上播一遍就好了。”
说者无心，听者有意。我刚好最近又在折腾大模型和具身交互智能体，当场接了话茬：我来做一个。于是就有了「简简」——一位穿深色正装、说话干脆利落的职场播报助理，每天把会议纪要、待办和截止提醒整理成 30 秒口播，用职业女声播出来。
这篇文章记录简简从立项到上岗的全过程。做完之后我最大的感受是：把一个 AI 数字同事做得"像个人"，真正的功夫不在接入，而在三个看起来不起眼的设计决策上。

一、为什么是"播报"，而不是再发一条群公告

动手之前先想清楚一个问题：待办提醒的工具已经满天飞了，群机器人、日历推送、Todo 应用，为什么还要做一个会说话、有形象的角色来"念"？

我的观察是：信息推送的失败，往往不是信息没送到，而是信息没被"听见"。

群消息是被动的文字流——14 条消息里，那条"今天 17:00 前提交"和表情包的视觉权重完全一样，大脑会自动把它归为"稍后处理"。而"播报"是一种完全不同的信息压强：一个穿正装的人看着你，用不容分心的节奏把三件事讲出来，还把最要紧的那条原样复读一遍——你很难装作没听见。

再往深一层说，纯文本 Agent 的整理能力其实早就够了——让大模型把 14 条消息归并成三条要点，准确率很高。它缺的是一个出口：一个有形象、有声音、有节奏、能被办公室里的真人自然接收的表达方式。
这正是具身交互智能体补位的地方。星云官方的定义我先抄在这里，因为它基本概括了简简能得到的所有支撑：

具体来说，它把多模态感知 + 专属智脑 + 多模态表达 + AI 端渲 + 数字与物理行动，连同 Real-time Interaction Runtime，连接成一套完整系统，让 AI 可以通过不同的屏幕和机器人身体进入真实世界。

分工一句话讲完：大模型负责"想清楚"，魔珐星云负责"说出来"——语音、口型、表情和动作的实时联动全由星云的表达引擎驱动，前端只管把文本喂进去。

🌐 魔珐星云官网
技术架构图：用户输入 → 大模型整理 → 按句切分调度 → 星云实时驱动 → 3D 数字人播报。呈现的画面如下：

二、搭底座：半天跑通"能说话"的最小闭环

底座部分出乎意料地顺。整体数据流是：

同事输入杂乱纪要/待办 │ ▼ 大模型（流式输出）：边整理边吐字 │ 每攒够一句话立刻回调 ▼ 调度层：按句切分 → 送具身交互智能体分句播报 │ ▼ 星云 SDK：3D 形象 + 语音合成 + 口型表情同步

2.1 先说清楚：这底座不是 “ASR → LLM → TTS” 拼出来的

跑通之后我回去看了下自己最初的技术方案，发现和"标准做法"完全不是一回事，这里值得先花一段说清楚，否则后面三节的设计决策会显得没来由。

我最初的思路是经典的三段式管线：ASR → LLM → TTS → 屏幕。语音识别负责听懂，大模型负责想，语音合成负责念。每个模块单独都能工作，拼在一起也能跑 Demo——但一到持续的人机交互里就开始出问题：状态不同步、响应链路变长、表达与用户当前状态脱节。

这里我要说清楚一件事：问题不在于这些单项技术不好。ASR、LLM、TTS 这些能力本身都很重要，也都在快速进步，我完全没有否定它们的意思——真正进入持续的人机交互，需要的是把它们围绕一次完整的用户交互连接起来。

星云不是简单把几个模块连起来，而是围绕一次完整的人机交互设计整个系统，形成：

持续感知 → 持续理解 → 持续决策 → 持续表达与行动 → 持续反馈

也就是Continuous Interaction Loop（持续交互循环）。

一句大白话：不是"你问一句，它答一句"，而是 AI 一边和你交流，一边继续听、继续看、继续判断接下来应该怎么回应和行动。

落到简简身上，这个区别是很具体的：她在播第三项待办的时候，"新指令进来"这一路并没有停——新内容判断、优先级比较、要不要打断、原口播的队列怎么接回去，全都在同一个循环里跑。这就是端到端具身交互智能与"三件套拼接"最本质的差别：后者是几个独立的回合，前者是一段连着的、可以被随时改写的对话。

2.2 模型侧：流式输出 + 关闭思维链

模型侧用 OpenAI 兼容接口做流式输出，并且关掉思维链——qwen3.8-max 是思考模型，不关的话它会先"想"几秒才吐第一个字，播报场景等不起：

const stream = await this.openai.chat.completions.create({ model: LLM_MODEL, messages, stream: true, temperature: 0.6, max_tokens: 400, enable_thinking: false, // 智能体要第一时间开口，不能先"想"几秒 }); let fullResponse = ''; // 核心：增量一到达就回调，组件按句切分后立刻送智能体开口 for await (const chunk of stream) { const content = chunk.choices[0]?.delta?.content || ''; if (content) { fullResponse += content; if (onDelta) onDelta(content, fullResponse); } }

2.3 表达侧：初始化星云 SDK

页面引入 SDK 脚本后（一行<script>，也可以像我一样做成动态加载），核心是构造XmovAvatar实例。凭证在星云控制台创建驱动应用后获取（此处已脱敏）：

this.sdkInstance = new window.XmovAvatar({ containerId: '#avatar-container', appId: config.appId, // 星云控制台创建驱动应用后获取 appSecret: config.appSecret, gatewayServer: 'https://nebula-agent.xingyun3d.com/user/v1/ttsa/session', useWebGL2: true, // 局部接管Widget：页面用自己的文案区展示口播内容，关闭SDK默认字幕 proxyWidget: { subtitle_on: () => false, subtitle_off: () => false }, // 语音状态回调：简简的"开口/说完/空闲"全靠它驱动状态机 onVoiceStateChange: (status) => { this.voiceState = status if (config.onVoiceStateChange) config.onVoiceStateChange(status) }, onMessage: (message) => { // SDK级错误（连接、会话）统一从这里冒出来 console.log('SDK消息:', message) }, enableLogger: process.env.NODE_ENV === 'development' }) await this.sdkInstance.init({ onDownloadProgress: (progress) => { console.log('资源加载进度:', progress + '%') }, })

两个初始化细节值得单独说：

容器要有明确宽高。容器还没完成布局就被 SDK 初始化，会在 0 尺寸容器里渲染异常，我的做法是检测到offsetWidth === 0时先等 300ms 再继续；
初始化必须防重入。开发时热更新（HMR）会让组件反复挂载，不做锁的话旧实例不释放，会触发"账号驱动并发数已满"的 10005 错误。我用一个initPromise把初始化流程锁成单例，重入前先destroy()旧会话。

顺带说清楚一件事，因为它是我在对比方案时才发现的关键差别：这一层做的不是"TTS 播放"。

真实的人际交流从来不只有一句话。语言之外，还有声音、语气、情绪、节奏、停顿、眼神、表情、头部动作、手势和身体动作。所以简简的表达不是简单的TTS + Lip Sync——系统会依据当前的语言、用户状态、智能体角色、情绪、场景以及当前交互状态，实时生成并驱动语音、口型、情绪表情、眼神、头部动作、手势和身体动作。

这里有两个区别我在实际看效果时才真正体会到：

**第一，不是预制播放，是根据上下文实时生成。**简简的播报内容每天都不一样，靠预制动画不可能对上。她的"专业感"是实时长出来的，不是从几个固定动画里挑的。

**第二，表达和感知不是前后两个独立阶段。**她在播报的时候，“新指令进来"这一路还开着。新内容一到，她停下来答完，再回到刚才没播完的那条——不是"动画被打断、切回来”，而是表达中断之后立刻进入了新的表达。

这一层的核心优势：统一、连续、同步，而不是语音、表情、动作各自播放。

2.4 调度层：分段播报、打断与状态机

这一层是把"能说话"变成"说得像个真人"的关键，一共三块。

分段播报——利用星云的speak(content, is_start, is_end)三段式接口：每句一个 SSML 段，第一句is_start=true，最后一句is_end=true，中间句子两个都是 false。简简因此可以"边整理边播"，听者感知到的只是正常的接话停顿，而不是沉默的生成等待：

speakSegment(text, { isStart = true, isEnd = false } = {}) { if (!this.isInitialized || !this.sdkInstance || !text) return // 每段都下发完整合法的SSML（纯文本，语速在控制台侧配置） const ssml = `<speak>${text}</speak>` this._lastSegIsEnd = isEnd this.sdkInstance.speak(ssml, isStart, isEnd) }

打断——播报进行中来了新指令，先调interactiveidle()让简简停下，等回到空闲态再下发新内容，天然支持插话：

interrupt() { this._pendingInterrupt = true this.sdkInstance.interactiveidle() } // 等智能体回到空闲态，超时3秒兜底放行，避免状态回调丢失导致死等 _waitVoiceIdle(timeout = 3000) { if (this.voiceState === 'idle' || this.voiceState === 'end') { return Promise.resolve() } return new Promise((resolve) => { const finish = () => resolve() this._idleWaiters.push(finish) setTimeout(finish, timeout) }) }

段间间隙判定——流式分段播报有个隐蔽的边界情况：句与句之间会有一瞬的idle回调。不处理的话，“她还在播"和"她播完了"会混淆。我用一个_lastSegIsEnd标记区分"段间间隙"和"整段说完”，配合_pendingInterrupt区分"主动打断触发的 idle"——三个标记合起来，状态机才算闭环。

简简目前是"文本进、语音出"，打断这件事在文本侧还比较简单。但如果把同一套调度层搬到语音场景，往下一层就是持续感知的问题：系统得在她自己正在说话的时候，依然听得见别人。星云的语音感知包括算法降噪、AEC / 抗回声、本体声音抑制、VAD、ASR、远场语音，以及 Double Talk / Barge-in 智能打断——这几个词摆在一起才看得懂难点在哪：

**系统既不能把她自己的扬声器声音误识别成用户，也不能因为 AI 正在表达就听不到真正的用户输入。**它需要连续地做一串判断：判断真实用户声音 → 去除本体回声 → 区分噪声、咳嗽、Backchannel 与真实插话 → 检测有效打断 → 停止当前表达 → 持续接收用户完整输入 → 进入新一轮交互。

其中"区分 Backchannel 和真实插话"这一条我认为特别值钱——“嗯嗯”"然后呢"在真实交流里太频繁了，如果都算打断，播报永远播不完。

视觉侧同样在"持续感知"的范畴里：如果哪天把这套东西搬到办公室门口的屏上，有人走近时，AI 能通过摄像头感知到有人进入交互范围，并由此触发主动交互——不用等谁先开口，她自己就会说一句"今天有三件事要提醒你"。核心优势是持续感知，而不是一次输入。

2.5 可插拔：换掉一个模块，播报不能散架

星云支持模块可插拔，但这句话我第一遍读得很快，后来才意识到它说的是件挺硬的事。

**可插拔并非简单的 API 拼接。**感知、认知、表达与执行之间存在紧密的时序依赖与状态关联——比如换掉 LLM，流式分句的到达节奏就变了，如果调度层还在按老节奏等文本，播报就会错拍。

星云的做法是通过标准化的接口契约与统一的状态管理机制，确保模块替换之后，事件流转、会话状态、时间同步与异常处理仍然保持一致，端到端交互体验不受影响。当前支持的组件大致是：

对简简这个项目来说，最实际的价值是**“不被单一供应商绑死”**：Brain 那一格我正好是在自研智脑和第三方 LLM 之间做选择。而放到公司环境里更有意义——有些部门要求数据不出内网（对应"客户自建大脑"），有些团队早就把工作流搭在 Dify 上了（对应"第三方 LLMOps 平台"），可插拔意味着这些都用不着推翻重来。

星云的接入本身很轻：表达全在云端生成参数流、浏览器端侧渲染，前端只管喂文本和管状态。半天时间，最小闭环就通了——但这只是"能说话"，离"像个职场播报员"还差一整套认知。

三、补齐认知：简简的"认知层"，不该只写在提示词里

底座通了之后，我犯了一个挺典型的错误：我以为接下来要做的事，就是"把提示词写好"。

结果第一次试播就出了问题——她把一份已经取消的评审会当成"今日待办"播了出去。那份纪要确实在系统里，但它已经被新版纪要作废了。

还有一次更微妙：那天有三条待办，她的播报结构是对的，但把"需要在评审会前确认接口"这条排到了最后——因为模型不知道"接口没确认，评审会开不了"这层依赖关系。

这两件事让我意识到，简简缺的不是"更好的提示词"，而是一整层东西：知道自己是谁、掌握哪些知识、当前任务是什么、下一步该调什么。这一层在星云里叫专属智脑。文档里有个说法我看完立刻就懂了：

大模型更像解决"我能不能回答这个问题"，专属智脑还要解决"我是谁、我代表谁、我掌握哪些知识、当前任务是什么，以及下一步该调用哪个系统"。

它的目标是把通用模型进一步变成真正属于企业、品牌、岗位或个人的智能体。落到简简身上，是三件事。

3.1 它知道什么：会议知识的底座不是"把纪要粘进去"

我最初的实现非常粗暴：把会议纪要原文复制成文本，丢进向量库。播报确实能用，但一直是"及格线"水平。看完文档我才明白自己漏掉了什么：全模态数据解析不只是支持 PDF、Word、PPT、图片、音频、表格这些格式，更重要的是解析过程中会同时保留资料里的层级关系、图文关系、表格关系、说话人信息和上下文。

不是"转成文字"和"转得更好"的区别，是有没有信息的问题。这四类关系在职场素材里全都会踩到：

表格关系：周报是一张表，转成文字就是"张伟 80% 李娜 60%“——没有主语、没有表头。保留了表格关系，简简才知道这是"周报提交完成度”，才不会把 80% 读成"绩效 80 分"；
说话人信息：会议录音转写如果丢了说话人，讨论过程就会被当成决议。我经历过一次，简简播报"方案 A 已被否决"——实际上那是会议里某个人的反对意见，最后通过的恰恰是方案 A；
层级关系：一份纪要里有"决议"和"讨论过程"两层。层级丢了，两件事会糊在一起，简简就会把没定的事播报成"已确认"；
图文关系：需求文档里常插设计稿截图。图文关系丢了，截图上的示意数字就会被当成真实指标播出去——这在职场里是事故级的。

第二项是知识图谱 + RAG 深度融合。这个差别我是被一个具体问题点醒的。

那天的原始输入是一句：“缺陷认领今天下午六点前完成。”

普通 RAG 会去检索"缺陷认领"最像的段落，很可能捞回一段流程说明，然后组织成"请尽快完成缺陷认领"。意思没错，但没用。

而带上关系组织之后就不一样了。知识图谱 + RAG 会把文档里的实体、概念和关系组织起来，底层结合向量语义、关键词和知识图谱进行召回，让智能体面对跨资料、跨知识点的问题时，不只是命中某个片段，而是能把多个相关知识连接起来。简简顺着"人 → 负责模块 → 缺陷单 → 截止时间 → 依赖的评审会"这条链，播出来的是：

“第二，新版本缺陷清单已同步，请各自认领。请重点注意，第二项，缺陷认领今天下午六点前完成；其中接口模块还等李娜确认，会影响周三评审会。”

多出来的那半句不在任何一条原始消息里，它是从"缺陷 → 模块 → 人 → 会议依赖"这几条关系里长出来的。这就是"找到一段话"和"基于关系组织答案"的差距——在职场播报场景里，这个差距就是"念稿"和"有用"的差距。

第三项是高效知识治理，也就是我开头那次翻车的直接原因。

项目是活的：需求改版、人员变动、排期调整、会议取消。**企业知识不是一次建完就不变，真正重要的是在资料持续新增、修改和废止之后仍然保持准确。**这需要在知识块、标签、实体、关系、向量索引和来源信息这整条链上持续维护。

我后来专门做了个验证：把一份纪要标记为作废，别的不动，再让简简播报——她照旧把那条取消的会议念了出来。做完治理之后才跟上。

这件事让我彻底接受了"治理"这个词，而且它还带来一个我没想到的好处：**来源信息追溯。**现在每条知识都能追到是哪份纪要、哪个版本来的。当两份材料互相矛盾时（这在赶进度的项目里太常见了），系统能判断哪份更新，而不是随机挑一份播出去。

3.2 它是谁、当前要做什么：三个设计决策都落在这一层

专属智脑不只是"知道内容"，还要知道自己代表谁、服务谁、遵循什么规则、当前要完成什么任务。可配置的内容包括：身份、人设、角色、任务、规则、音频、Agent、Workflow、对话流程和工具调用。

我按这几项把简简重新配了一遍：

配完之后，简简的行为变化不是"回答得更好"，而是开始具备岗位化、场景化、流程化的工作能力——知道自己现在是个播报助理，知道这一轮该把话说完而不是闲聊，知道被新指令打断之后要接回哪一条。

文档里还有一句对开发者很友好的话：**用户可以根据自己的需求配置习惯使用的大模型，如果没有常用的大模型，可以直接用星云自研智脑。**我这次正好是这么分工的——内容生成继续跑 qwen3.8-max，而身份、知识、规则、任务、流程、工具这些"智脑该管的事"交给平台，两者不冲突。

**需要说明的是：接下来第四、五、六节讲的三个设计决策——温度、口播结构、语速与形象——本质上都是在这一层里做选择。**我一开始把它们当成"调参"，现在更愿意把它们理解成"给这个岗位定规矩"。

3.3 它能不能真正进入业务：从"念待办"到"查系统"

第三层是我这次真正用上了、也觉得最有想象力的部分：专属智脑最终不是停留在对话层，而是要能进入企业真实业务流程，可连接CRM、ERP、OA、HIS、BI、商品系统、订单系统、客户系统、门店系统、IoT 以及第三方 Agent。

简简这个场景其实天生就在内网里，因为它播报的每一件事背后都有系统：

播报"今日待办" → 该问OA / 项目管理系统的真实状态，而不是从纪要里猜（纪要写完的那一刻就已经开始过期了）；
播报"谁还没交周报" → 该查OA / HR；
播报"这个版本发布有风险" → 该查BI / 缺陷系统的实时数据；
播报完顺手"提醒对应同事准备评审材料" → 这是流程推进，不是回答问题。

这就是"一个会念稿的程序"和"一个进得了流程的同事"的区别：前者生成答案，后者结合业务系统完成查询、协同、触发和流程推进。

这一层的核心优势，一句话概括：从通用回答能力，升级为面向具体身份、岗位和业务的智能体能力。

3.4 只靠提示词，她会怎么飘

讲完三层，说一个必须写出来的踩坑。

第二节我夸过底座好搭，第三节开头我也承认了"以为写提示词就完事"的错误。这里把症状列清楚，因为我觉得它比结论有用：

知识会过期。取消的评审会被播出来，提示词治不了——它根本不知道哪份纪要作废了；
结构会漂。播到后面几天，简简开始把"重点复读"那一段省掉，直接念条目。提示词里的结构没变，是长上下文把规则稀释了；
规则会打架。我同时写了"每条不超过 20 字"和"重要事项原样重复"。当一条重点本身超过 20 字时，模型会随机选一条遵守，表现就是时好时坏。

后来我按专属智脑的配置项把职责拆开：**提示词里只留"语气和风格"，身份、知识、规则、任务、流程、工具全部挪到配置层。**三个现象基本都收敛了。

我的理解是："怎么说"是风格问题，放在提示词里灵活调整没问题；"我是谁、做什么、先做哪一步"是认知和流程问题，放在提示词里，就会随着上下文变长被稀释掉。

这也是这一节最核心的一句：专属智脑不是"更长的提示词"，而是另一层东西。

四、设计决策二：四段式播报结构——把"念稿"变成"早会广播"

第一个决策是模型温度，这是我来回调得最久的一个参数。

简简播报的是会议纪要、待办、截止时间。这类内容有个特点：**播错一个时间点、编造一个事项，信任感直接归零。**所以第一版我直接把温度压到了 0.3，求稳。

结果翻车了。0.3 温度下的播报干巴巴的，像短信念稿：“明日会议。十点。产品评审。“句子短促、没有起伏，听两分钟就烦。职场播报需要的是"专业”，不是"机械”。

另一头，0.8 的温度确实生动，但代价是不能接受：它会自作主张地"润色"——把"周三评审会"扩写成"热闹的周三评审会即将到来"，甚至脑补出不存在的事项。这在娱乐场景无所谓，在办公室是事故。

最后落在 0.6：

temperature: 0.6, // 播报稳定优先，但不能失去自然的语感

这个值的分寸感在于：句子有自然的抑扬和衔接，但内容严格贴着输入走。配合规则里的一条硬约束——信息不足时用一句话简短追问，不要编造真实的会议、人名或数据——幻觉问题基本被摁死了。

我的总结是：播报类智能体的温度，不取决于模型，取决于"这条信息错了谁背锅"。娱乐场景错了是笑料，职场场景错了是事故。

第二个决策花的时间最多，也是简简能不能立住的关键。

最初的提示词我只写了"你是职场播报助理，播报会议纪要和待办"。结果简简给出的内容逻辑是对的，但形态是错的——一整段平铺直叙，重点埋在中间，听完记不住任何一条。

我去研究了电台新闻和班组早会的口播稿，发现职业化的口头播报都有一个共性结构：**先给全貌，再给条目，重点复读，收尾给方向。**于是我把这套结构直接焊进了系统提示词：

三个细节是针对"听"这个动作专门设计的：

“每条不超过 20 字”：播报是听的，不是读的。一条超过 20 字，听的人就得回放才能记住；
"请重点注意"复读机制：关键信息在语音流里只出现一次必被漏掉——这是从应急广播学来的。实测我把"今日 17:00 前提交周报"放进待办，复读机制上线后，"没听到截止时间"的反馈直接归零；
收尾给"下一步建议"：播报不是终点，要给行动指引。哪怕一句"建议先处理第一条"，都比戛然而止强。

另外格式约束（禁 Markdown、禁序号、禁换行）不是为了好看——这段文字要直接喂给 TTS，任何格式符号都会被念出来或导致断句诡异。

五、设计决策三：1.05 倍语速 + 正装形象——"职场感"是配出来的，也是踩坑踩出来的

第三个决策关于"气质"。文字内容立住了，还差声音和形象这一层。

形象侧没有什么悬念：在星云控制台给简简配置了 30 岁左右职业女性形象、深色正装、现代办公室背景、商务专业女声。让我意外的是这整套"人设资产"全在控制台完成，前端代码一行不用动——形象、音色、场景和代码是解耦的。

语速侧就踩坑了。我想要的语速是 1.05：比常速略快一点，体现"明快、节奏干脆"，又不能快到像催命。第一反应是在 SSML 里包<prosody rate="1.05">，结果——播报整段静默消失，不报错、不播，简简就站在那儿看着你。

排查下来确认：当前 TTS 引擎不接受<prosody>标签，带标签的文本会被服务端整段拒绝。这是一个"静默失败"——没有任何错误码指路，只能靠对比"带标签"和"不带标签"的下发结果定位。

最终方案：语速在星云控制台的音色设置里配置（1.05 倍速），前端一律下发纯文本 ****<speak>：

代码里我保留了语速参数位并写清注释"待引擎支持后开启"——这类"引擎当前不支持"的能力边界，不写下来下个人一定再踩一遍。

简简播报页面全景：正装形象 + 播报文案区 + 输入区。

一段真实输出（输入是上周那条 14 条消息的杂乱记录）：

“今天例会共确认三项事项。第一，周三上午十点产品评审会，全体参会。第二，新版本缺陷清单已同步，请各自认领。请重点注意，第二项，缺陷认领今天下午六点前完成。第三，团建地点下周投票。建议先完成缺陷认领，再安排评审会材料。”

几个实测数据：

最小闭环耗时：半天跑通"能说话"（模型侧 + 表达侧 + 调度层）；
单次播报时长：30 秒以内（约 140 字），正好是一段不让人分心的时间；
漏听反馈：重点复读机制上线后，"没听到截止时间"的反馈归零；
形态定稿：温度 0.6 + 四段式结构 + 1.05 倍速 + 正装形象；
稳定性：连续运行一周，除了语速标签那次静默失败，没有出现过播报中断。

AI 端渲染

上面这些数字背后有个容易被忽略的工程选择，值得单独说：简简走的是端侧实时渲染——3D 画面在用同事的浏览器本地渲染，云端只传参数流（驱动参数，而不是视频流）。

它解决的不是"画面好不好看"，而是一个更底层的问题：**实时交互能力能不能真正低成本、低延迟、稳定地部署到大量终端。**带来的直接价值有好几项：

降低云 GPU 成本：减少对云端算力的持续依赖；
降低带宽占用：不再依赖视频流长距离传输；
降低延迟：就近渲染，交互链路更短；
提升稳定性：弱网环境下依然可以运行；
支持大规模并发：并发不再直接受云端渲染资源限制；
支持低成本 AI 终端：对终端芯片要求更可控，更适合规模化部署。

对"给全公司每个组配一个播报助理"这种设想来说，这几条不是技术指标，是能不能推广的前提：一台云端 GPU 撑不住几百个并发会话，但几百个浏览器各自渲染是没问题的。

还有一点必须提：AI 端渲和 Runtime 在星云体系里不是孤立能力，而是关键技术和工程基础设施——它们支撑的是感知、智脑、表达和行动这四件事能在终端上真的跑起来。

顺带说，这也是它跟大模型怎么接完全解耦的原因：今天我用 qwen3.8-max，明天换别的模型，简简的"身体"不用动。

六、写在最后：数字同事的门槛，在接入之外

做完简简，对"具身 Agent 落地"这件事有了个很具体的判断。

技术上的接入其实不难——大模型加一个表达引擎，几天就能让一个 3D 具身交互智能体开口说话。真正决定"她像不像一个可以共事的同事"的，是那些藏在提示词和参数里的决策：温度压到多少才既稳又活、信息结构怎么设计才"进得了耳朵"、语速和形象怎么配才贴合场景。

回到开头的判断：具身智能体补的就是纯文本 Agent 缺的那层"表达与交互"——大模型让 AI 想清楚了，但信息要真正"抵达"人，还需要一个有形象、有声音、有节奏的出口。魔珐星云补的就是这一层，而且把表达和代码解耦得足够开，让人设的迭代不需要动代码。

补一件这次才想明白的事：身体是可以换的。简简现在有屏幕这一个身体，那同一个智能体，可以拥有不同的身体；智能体持续存在，身体不断升级。同一份智脑配置，今天挂在这个页面上，明天可以挂到办公室门口的大屏、会议室的一体机——身份、知识、记忆、任务持续复用。而如果她哪天有了机器人的身体，行动还会进一步延伸到物理世界：转向用户、靠近用户、移动、导航带路、跟随指示、上肢动作、Robot Skill。屏幕这一半我这次用到了（把整理好的信息说出来、演出来），物理那一半还在路上。

给想做类似东西的开发者一个可复用的路径：