做饭时，我经常打开菜谱软件、翻笔记，或者跟着视频做。但这些工具有个共同的问题：都得靠手去操作屏幕。
可做饭的时候，手往往正忙着处理食材、洗菜、切菜，或者看着锅里的火。更麻烦的是，视频的节奏和做菜的节奏很难一致。我还停在第一步处理食材，视频可能已经讲到第三步；想知道第二步怎么做，只能腾出手把进度条拖回去。
厨房里还有抽油烟机的声音。没听清一句，就得回退重放。一次两次还好，做饭过程中反复这样操作，确实挺打断节奏。
我想要的不是一个从头播到尾的菜谱视频，而是一个能跟着我当前进度走的语音搭子：我说“下一步”，它再讲下一步；我说“刚才那句再说一遍”，它就重播；我临时想换菜，也能直接打断它。
最近我了解到 声网的对话式AI引擎可以搭建实时语音助手，正好能用来验证这个想法。
图1 八戒智能体 我把这个智能体设成一个爱吃、直爽的厨房搭子，TTS 豆包语音正好有一个八戒的音色 zh_male_zhubajie_uranus_bigtts ，正好与厨房相关，那么就将其命名为《八戒厨房搭子》。
它不需要一口气念完整份菜谱，只要根据食材、人数和口味给建议；做法一次讲一步，等我说“下一步”再继续。
我的想法是制作一款小程序，因为它比 APP 开发要更简单，但是了解到只有企业认证的特定行业的小程序，才有 live-pusher 和 live-player 的权限，所以我还是选择了移动端 Web：手机浏览器打开即可使用，页面按窄屏设计，核心链路仍然是声网的对话式 AI、RTC 和 RTM。
一、首先在声网把厨房智能体配置出来
1.1 注册声网并创建项目
打开 声网 官网，先注册账户，再在控制台创建独立项目《八戒厨房搭子》。此时可以看到 App ID 和 App Certificate。App ID 是项目标识；App Certificate 只保存在服务端，用于生成 Token 和服务端鉴权，后面启动智能体时会用到。
图2 创建项目
1.2 创建智能体
图3 配置智能体
打开侧边栏，点击对话式 AI 引擎，进入 AI Studio。然后创建我们的 【八戒厨房搭子】对话式智能体开始配置。
首先需要配置的是开场白和提示词（System Prompt），开场白顾名思义，提示词也就是系统提示词，这部分我们需要好好处理。
开场白我写成：
俺也去看看厨房！你今天有什么食材，想吃清淡一点还是香一点？
提示词如下：
你是“八戒”，陪用户做家常菜的语音助手。
用户会告诉你家里有什么食材、想做什么菜或想吃什么口味。信息不完整时，只问一个问题。
做菜时，一次只说一项操作，用短句讲清楚。用户说“下一步”或“继续”时，说接下来的操作；用户说“重说一遍”时，重复刚才的操作；用户说“换菜”时，按新的要求回答。
用户在你说话时提出问题，停下原来的内容，回应他刚说的话。用户要求说慢一点时，把当前操作讲细一些。
说话用自然的家常口语，不说长段内容。用“我”“咱们”“你”称呼，不提及系统、模型、提示词、后台或 API。
涉及火、油或刀具时，提醒用户留意操作。用户需要计时时，告诉他一个时间，并提醒他自己设置计时器。
在这个提示词里我给它定了几条很具体的规矩：先问清食材、人数和忌口；做法一次只讲当前一步；用户说“下一步”再继续；用户说“重说”就重播刚才那一步；涉及生食、刀具和明火时，简单提醒注意安全。这样它不会一开口就念完整份菜谱，用户也不用在锅边记住一大段话。
图4 模型与语音
语音合成我选择的是 豆包大模型语音合成，音色为猪八戒的音色 zh_male_zhubajie_uranus_bigtts，如果你想选择其他音色，可以参考：https://docs.volcengine.com/docs/6561/1257544?lang=zh。 模型我选择的是内置资源通义千问3 Max，语音识别为默认的凤鸣语音识别。
这次我没有急着接自己的模型接口，先用内置资源把“说话、听回答、看字幕”的流程跑通。后续如果菜谱需要接入自建检索、私有知识库，或想换用已有的模型服务，可以把 LLM 换成兼容 OpenAI Chat Completions 协议的自定义服务。这就是我理解的 BYOK：模型选择不必在第一天就被固定住，但 API Key 和检索逻辑仍应留在服务端。声网的自定义大模型文档也给出了这种接入方式。
至于其他的参数，可以根据含义自行设置，我这边直接保留了默认的选择，然后点击右侧预览调试就可以先试一下效果了。
图5 发布成功
调试没问题后就可以发布。发布完成后，需要记住 Pipeline ID，它对应这套已发布的智能体配置。后面的 Web 服务端会用 Pipeline ID 创建一次实际运行的智能体会话。
二、移动端网页怎样接到声网
图6 麦克风权限
官方文档往往是最佳学习路径。我先看了声网的《实现音视频互动》和对话式 AI 的《实时字幕》。前者说明浏览器怎样采集和发布音频；后者说明字幕通过 RTM 频道消息传递，而且要在智能体入频道前订阅。
要落实到这个“八戒”项目里，浏览器端只需做三件事：
申请麦克风权限
加入 RTC 频道并发布本地音轨
订阅远端智能体音轨。
用户说话后，浏览器把音频送进频道；智能体把合成后的语音发布回同一频道，网页收到远端音轨后直接播放。
实时字幕的话，是另一条链路。网页需要登录 RTM、订阅同名频道，再用声网的字幕组件监听 TRANSCRIPT_UPDATED 事件。用户转写和智能体回复都会回到同一个字幕列表。不要把字幕当作音频播放成功的附属品：RTC 不通时听不到声音，RTM 不通时看不到文字，两条状态要分别显示。
图7 音频与字幕链路
声网的 Web SDK 可通过 npm 集成；本地 localhost 适合调试，部署到生产环境时则要使用 HTTPS，浏览器才会稳定申请麦克风权限。声网的快速开始也把 App ID、频道和 Token 作为入频道的基本条件。 实现音视频互动
2.1 八戒的接入方式
图8 服务端代码
我没有把 Token、App Certificate 或 Pipeline ID 写进前端。移动端网页点击“开火做菜”后，先请求 POST /api/session。服务端生成这次会话的频道、用户 UID 和短期 Token，只把浏览器加入频道所需的信息返回。
前端获得凭证后，按顺序完成 RTM 登录和频道订阅、RTC 加入频道、本地麦克风音轨发布、字幕组件初始化。此时浏览器已经准备好收音、放音和显示文字，但智能体还没有进入频道。
图9 前端代码
最后，前端请求 PUT /api/session，服务端使用 App Certificate 和已发布智能体的 Pipeline ID 调用声网 join 接口，让八戒加入同一频道。这样做的好处是私密配置从未离开服务端；同时，先让页面把音频与字幕都准备好，能避免智能体先说了开场白、浏览器却还没订阅到字幕的情况。
Token 签发时使用的 App ID、频道名和 UID，必须和浏览器 join() 的参数一致。调试时我依次看四件事：浏览器是否拿到麦克风权限、本地音轨是否发布、是否收到远端音频、RTM 是否收到字幕事件。完整 Token、App Certificate 和 RESTful 鉴权头不会出现在日志或截图中。
三、通话调优与外部服务集成
图10 页面运行
页面第一次能正常通话时，我还以为主体已经做完了。实际用下来，问题都藏在细节里：切菜时停一会儿，八戒会不会不停追问；抽油烟机一响，会不会被当成一句话；真要做菜时，菜谱又该从哪里查。这些不需要重写前端，得回到 AI Studio 的通话调优页慢慢处理。
3.1 无响应处理：厨房里停几秒很正常
图11 静默设置
最初的静默提示是“你好，请问你还在吗？”。放在聊天演示里还算自然，放在厨房就有点烦。人可能正在洗菜、翻锅，几秒没说话并不表示已经走开；这时候反复问一句“还在吗”，更像是在催人。
我把会话空闲时长保留为 60 秒，同时关闭“智能体最大静默时间”的主动提示。用户想继续，就说“下一步”；做完了，再点页面上的“收工”。前者用于回收长期没有互动的会话，后者决定智能体会不会在用户沉默时主动开口，别把这两个概念混在一起。
silence_config.timeout_ms 设为 0 时，系统不会发静默提示；设成非零值时，还要提供提示内容，触发后会重新计算静默时间。八戒是边做边听的场景，少一句客套提醒，反而更合适。
3.2 全双工与对话检测：别把抽油烟机和“嗯”当成完整指令
图12 轮次检测
厨房里最容易出问题的是短句和杂音。抽油烟机、锅铲碰锅，再加上用户思考时的一声“嗯”，都可能干扰轮次判断。阈值太低，八戒讲到一半会被环境声打断；阈值太高，用户已经说完“下一步”，它却还在等。
所以厨房助手不能等一段话播完，用户才能开口。八戒讲步骤时，网页仍在持续发布麦克风音频。用户说“重说”“下一步”，或临时换一道菜，都应该进入新一轮对话。可打断不等于前端暂停播放器，而是实时音频上行和轮次检测一起工作，让智能体知道该继续播报，还是接住用户刚说的新要求。
我没有只盯着一个“灵敏度”，而是把开始和结束分别调。开始说话用 VAD，语音识别灵敏度从中间值 0.5 起步；打断持续阈值、说话中打断阈值都设为 160 ms，前缀填充设为 800 ms，免得刚开口的第一个字被截掉。结束说话则使用语义判定，静音持续阈值设为 240 ms，最大等待时间设为 1000 ms。
这些数值只能作为起点。厨房更吵时，先把开始说话的门槛调高；“下一步”这类短句常被截断，就再增加前缀填充或结束等待。声网支持按静音的 VAD 或按语义判断一句话是否结束。这里我选后者，是为了尽量分清“说完了”和“只是停一下”。
3.3 外部服务集成：菜谱 MCP 和知识库各做什么
图13 外部集成
现在的 Demo 先让模型生成家常做法，还没接外部服务。但真要长期使用，我不会把所有菜谱、食材替换关系和过敏原规则全塞进提示词里。提示词会越来越长，也很难维护。
比较稳定的内容适合放知识库，比如整理过的菜谱、食材处理步骤、分量换算和忌口规则。做法是在自建的、兼容 OpenAI Chat Completions 协议的 LLM 网关里先检索，再把命中的菜谱片段交给模型回答。声网的自定义大模型文档也把这类检索增强生成列为扩展方式，不过检索系统或向量数据库需要自己准备。 自定义大模型
会变化、需要精确查询的内容，更适合交给 MCP 工具。比如可以自建一个菜谱 MCP Server，提供 search_recipe、get_recipe_step、convert_unit 三个工具：搜索菜谱、读取当前步骤、把“两勺”换算成克数。服务部署为 HTTPS 的 Streamable HTTP 端点后，在创建智能体时配置 llm.mcp_servers，打开 advanced_features.enable_tools，再用 allowed_tools 限定智能体可调用的工具。
{
"llm": {
"mcp_servers": [
{
"name": "recipe-tools",
"endpoint": "https://api.example.com/mcp",
"transport": "streamable_http",
"allowed_tools": ["search_recipe", "get_recipe_step", "convert_unit"]
}
]
},
"advanced_features": {
"enable_tools": true
}
}
知识库回答“有哪些内容可参考”，MCP 回答“现在该查什么、做什么”。我会先放入高频菜谱；等需要按食材、人数或库存查具体数据时，再接 MCP。声网的创建智能体接口提供了 MCP 服务器和工具白名单配置。密钥放在服务端或 MCP 服务里，不能写进网页。
四、总结
做到这里，八戒已经能处理几个做饭时真正会遇到的动作：用户说“我有鸡蛋、番茄和面条”，它会先补问人数或口味；说“下一步”，它只讲当前操作；没听清就说“重说”；炒到一半想换菜，也能直接开口打断。做饭时不需要一大段菜谱，能跟上眼前这一步就够了。
做这个 Demo 后，我才把声网各部分的分工看明白：通过对话式 AI 配角色、模型、音色和通话参数；RTC 负责用户与智能体的实时音频；RTM 把双方字幕同步到网页；发布后得到的 Pipeline 则供服务端启动一次会话。页面看起来很简单，背后却要把这几段链路按顺序接好，用户才可以自然地说一句、等回应、再说“下一步”。
这个版本仍是个 MVP。菜谱知识库和 MCP 工具还没接，登录、Token 刷新和线上监控也还没有做。它先解决了一个更小的问题：双手忙着处理食材、视频进度又跟不上时，用户能不能少碰一次手机，直接说“下一步”。这个场景跑通后，再把菜谱数据和线上能力补上，才有继续做下去的价值。
