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

# 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并同步更新了项目文档方便后续讲解和展示。整体来看今天的工作不算是单纯改页面而是把“入口、数据、回答、文档”都串了一遍。这样明天介绍项目的时候就能比较清楚地讲出我为什么要改、改了什么、遇到了什么问题、最后怎么解决。