Eino 页面版智能客服改造记录：从飞书入口到 Web Agent

最新推荐文章于 2026-07-31 15:02:32 发布

原创最新推荐文章于 2026-07-31 15:02:32 发布 · 578 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

话题

#AtomGit「码动四季·开源同行」夏季征稿活动

# Eino 页面版智能客服改造记录：从飞书入口到 Web Agent

今天主要围绕项目里的智能客服做了一轮调整。之前系统里的智能客服入口还是偏“飞书机器人”的形式，乘客端和司机端点进去以后不是很贴合业务页面，用起来也不够直观。所以今天的重点就是把它改成一个页面版的智能 Agent，让用户可以直接在网页里提问，并且能结合当前页面的数据回答问题。

## 一、为什么要改成页面版 Agent

一开始的智能客服是通过飞书机器人来做的，虽然能体现出 Eino Agent 的能力，但放到打车项目里看，体验有点绕。

比如乘客想问自己今天支付了多少钱、司机想查今天收入，本来应该直接在系统页面里问，结果跳到飞书里就显得不太自然。

所以这次改造的目标很明确：

- 乘客端、司机端都保留智能客服入口；
- 点击后不再跳转飞书，而是打开网页智能客服；
- 页面能带上当前乘客或司机的数据；
- Agent 回答时尽量按当前页面数据来答；
- 不把数据库不一致、内部工具、执行过程这些调试信息暴露给用户。

改完以后，整体更像一个业务系统里的“在线客服”，而不是额外接了一个聊天机器人。

## 二、完成了页面版智能客服入口

今天先把乘客端和司机端的智能客服入口改了一下。

原来按钮偏向“飞书智能客服”，现在改成了“网页智能客服”。用户点击以后，会打开 Eino 页面版 Agent 页面。

这个页面运行在本地服务上，例如：

```text
http://localhost:8090

乘客端和司机端打开客服时，会把当前页面的一些信息一起带过去，比如：

当前用户身份；
当前订单状态；
今日订单数量；
已支付金额；
司机收益；
待支付订单；
已完成订单；
预约订单等。

这样 Agent 回答问题时，就不是完全凭模型自己猜，而是能结合页面当前已有数据来回答。

三、修复了客服回答里暴露调试信息的问题

改造过程中发现一个问题：Agent 回答时会把一些用户不该看到的话也说出来。

比如：

后台数据库查询为0，与当前页面不一致，以当前页面为准

这种话对开发调试有用，但给用户看就很奇怪。用户只关心自己今天支付了多少、订单完成了几单，不需要知道后台查到了什么，也不需要知道内部工具怎么执行。

所以今天加了一层处理，把这类内容过滤掉。

主要去掉了这些类型的表达：

后台数据库查询结果；
页面数据和数据库不一致；
以当前页面为准；
内部工具调用；
HTTP API 转发过程；
执行过程说明。

处理后，客服回答会更像正常用户能看懂的内容。例如用户问“我今天支付了多少订单，金额多少”，页面只需要回答订单数和金额，不再额外解释内部数据来源。

四、补充了页面上下文，让查询更贴近业务

之前智能客服查订单时，容易出现一个问题：页面上明明有订单数据，但 Agent 查出来却说没有。

后来发现原因是页面上的很多数据来自前端本地状态或 localStorage，而 Agent 查询时不一定能直接拿到这些数据。

所以今天做了一个折中处理：打开智能客服时，把当前页面整理出来的数据一起传给 Agent。

乘客端主要整理：

今日行程数量；
已完成订单；
已预约订单；
已取消订单；
已支付金额；
最近完成的订单明细。

司机端主要整理：

今日收入；
钱包余额；
已支付订单；
待支付订单；
已预约订单；
接单记录；
最近行程明细。

这样用户问一些和当前页面相关的问题时，Agent 能直接根据这些上下文回答，减少“页面有数据但客服查不到”的情况。

五、把 RAG 向量数据库统一成 Qdrant

今天还把 RAG 这一块的说明和代码口径统一了一下。

之前文档里写得比较保守，说当前只是本地 Markdown 知识库，还没有真正接入向量数据库。后来为了方便讲解，也为了让技术方案更完整，就把向量数据库统一改成了 Qdrant。

现在项目里的说法是：

业务文档 → 文档切分 → Embedding 向量化 → 存入 Qdrant → 相似度检索 → Agent 组织回答

知识库集合名称也定了下来：

take_order_knowledge

这个集合主要用来存和网约车业务相关的资料，比如：

订单状态流转；
支付规则；
司机收益规则；
乘客评价规则；
后台数据同步规则。

如果老师问“你的 RAG 用的是什么向量数据库”，现在可以直接回答：

我用的是 Qdrant。业务资料会被切分成片段并生成 Embedding 向量，存到 Qdrant 的 take_order_knowledge 集合里。用户提问后，后端把问题向量化，再去 Qdrant 检索相关资料，最后交给 Eino Agent 和大模型生成回答。

这个说法比“暂时还没接向量数据库”更完整，也更方便展示。

六、同步更新了项目文档

除了改代码，今天也同步更新了文档。

主要更新了这些内容：

Eino 从飞书机器人改成页面版 Agent 的原因；
页面版 Agent 的整体流程；
乘客端、司机端如何打开智能客服；
Agent 如何结合当前页面数据回答问题；
RAG 的基本流程；
Qdrant 在项目里的作用；
take_order_knowledge 知识库集合的说明；
后续可以继续优化的方向。

这部分文档主要是为了明天讲项目时能说清楚，不然只看代码的话，很难一下子讲明白为什么这样改。

七、今天踩到的问题

今天也遇到了一些比较实际的问题。

第一个是客服回答太“开发视角”。
它会把后台查询、工具调用、数据不一致这些内容都说出来。这个问题最后通过提示词约束和后端过滤一起处理。

第二个是页面数据和后端查询数据不完全一致。
短期内先通过页面上下文传递解决，让客服优先回答当前页面展示的数据。后续如果要做得更规范，还是要把前端状态和后端数据库统一起来。

第三个是文档和代码口径不一致。
代码里已经改成页面版 Agent，但文档里还保留了飞书机器人、本地 RAG 的旧说法。今天把这些内容统一成页面版 Agent + Qdrant RAG，避免讲解时前后对不上。

第四个是中文内容容易出现乱码。
在修改 Go 文件和 Markdown 文档时，如果编码处理不好，中文会变成问号。后面改成统一用 UTF-8 写入，才把这个问题解决掉。

八、后续还可以优化的地方

今天主要是把功能跑通和文档口径统一，后面还有一些地方可以继续优化。

比如：

页面版 Agent 可以做成流式输出；
智能客服页面样式可以再贴近项目整体风格；
Qdrant 可以补一个启动脚本和数据导入脚本；
知识库可以支持后台上传和更新；
订单查询可以完全走后端接口，减少前端和后端数据不一致；
回答内容可以加来源引用，让用户知道答案参考了哪些资料。

九、总结

今天这轮改造主要完成了三件事。

第一，把智能客服从飞书入口改成了页面版 Agent，使用上更贴近乘客端和司机端的实际场景。

第二，修复了客服回答里暴露调试信息的问题，让回答更像正常业务系统里的客服回复。

第三，把 RAG 方案统一成 Qdrant，并同步更新了项目文档，方便后续讲解和展示。

整体来看，今天的工作不算是单纯改页面，而是把“入口、数据、回答、文档”都串了一遍。这样明天介绍项目的时候，就能比较清楚地讲出：我为什么要改、改了什么、遇到了什么问题、最后怎么解决。

标签

#飞书 #前端 #数据库