如何为Google Assistant（Google Home）封装未采用谷歌技术的现有聊天机器人

嘿，刚好做过类似的对接，来给你梳理下两种可行的方案，还有各自的优劣：

虽然你的机器人已经能处理所有意图和实体，但Dialogflow在这里的作用是帮你搞定Google Assistant的“接口适配”——比如语音转文本、Google的对话协议格式、会话上下文的管理框架，不用你自己从零对接Google的底层规范。

具体操作步骤很清晰：

• 在Dialogflow里创建一个Agent，然后启用Fulfillment的Webhook模式
• 当用户在Google Assistant里提问时，Dialogflow会把请求（包含原始问题、会话ID、上下文等）发到你的Webhook服务
• 你从Dialogflow的请求JSON里提取queryResult.queryText（这就是用户的原始问题），然后把它连同会话ID一起发给你的自研机器人API
• 拿到自研机器人的回答后，按照Dialogflow的响应格式返回给它，就能推送给Google Assistant了
• 关于上下文交互：Dialogflow会在请求里带session标识和contexts数组，你可以把自研机器人的会话状态（比如之前的对话历史、用户的交互状态）存在自己的数据库里，用session ID作为唯一键。每次收到请求时，先取出对应状态传给自研机器人，更新状态后再存回去就行；如果你的机器人本身支持会话状态管理，直接把session ID传给它，让它关联状态更省事。

说白了，Dialogflow在这里就是个“翻译官”，把Google Assistant的请求格式转成你机器人能懂的，再把回答转回去，工作量很小，还能快速兼容Google Home的各种设备。

如果你不想用任何中间件，完全自己掌控流程，那可以用Actions on Google SDK直接构建Action：

• 先在Google Actions控制台创建一个项目，选择“自定义”类型
• 用Node.js或Python的actions-on-google库来编写你的Action服务，处理Google Assistant的请求
• 捕获用户的原始文本请求（通过conv.input.raw或者conv.query），直接调用你的自研机器人API
• 上下文管理的话，Google Assistant提供了conv.user.storage（用户级持久化）和conv.storage（会话级持久化），你可以把自研机器人的状态存在这里，每次请求时取出传给机器人，更新后再存回去
• 这种方式的好处是完全摆脱Dialogflow的限制，你想怎么处理对话流程都行，但缺点是要自己搞定Google Assistant的所有交互规范——比如响应的格式（要符合Action的JSON结构）、卡片展示、语音合成的格式，还要处理语音转文本的各种边缘情况，工作量会大很多。

• 如果你的核心需求是快速上线，而且自研机器人已经能处理所有意图、实体和上下文，那方案一绝对是最优解——Dialogflow的适配工作不到一天就能搞定，剩下的就是对接你的API和状态存储
• 如果你的业务需要高度定制对话流程（比如要实现Google Assistant原生功能和自研机器人的深度融合），或者不想依赖Google的中间件，那可以考虑方案二，但要做好啃Google文档的准备

最后补充个小细节：不管用哪种方案，一定要确保你的自研机器人API支持会话ID参数，这样才能准确关联不同用户的对话上下文，不然每次请求都是独立的，没法维持连贯对话。

内容的提问来源于stack exchange，提问作者mpjjonker