今天给老师介绍了自己最近做的机器人和 RAG 相关内容。整体讲下来，老师主要不是否定我做的功能，而是指出我对一些底层概念理解还不够深，项目选型和表达方式也需要再调整。这里把今天老师提到的问题和我自己的理解记录下来，方便后面继续补。

一、RAG 不能只停留在“能检索”这一层

我今天介绍了项目里加的本地 RAG 功能，也就是把一些业务文档放到本地知识库里，用户提问时先检索文档，再让模型结合资料回答。

这个思路本身没问题，但老师提醒我，RAG 不能只理解成“查文档再回答”。如果以后面试或者讲项目，只说“我做了一个 RAG”，其实还不够。

RAG 里面需要继续深入理解这些内容：

1. 文档怎么切分
2. 切分粒度怎么控制
3. 怎么生成向量
4. 向量数据库怎么检索
5. TopK 怎么选
6. 检索结果怎么排序
7. 召回不准怎么办
8. 如何减少大模型胡说
9. 怎么判断回答是否真的引用了资料

我之前做的更多是一个简单版本，偏演示效果，真正要写到简历或者面试里，还需要把 RAG 的流程、原理和常见问题讲清楚。

二、RAG 里面可以准备一些 Agent 工程师面试题

老师还提到，可以在 RAG 知识库里放一些 Agent 工程师相关的面试题。

这个建议挺有用。因为如果只是放业务文档，RAG 的展示效果可能比较普通。如果知识库里加入一些 Agent、RAG、MCP、Tool Calling、Eino 工作流相关的问题，后面不仅能演示机器人问答，还能顺便复习面试知识。

比如可以整理这些问题：

• 什么是 Agent？和普通聊天机器人有什么区别？
• RAG 的完整流程是什么？
• 为什么 RAG 需要向量数据库？
• Embedding 是什么？
• TopK 检索是什么意思？
• MCP 是什么？解决了什么问题？
• Tool Calling 和普通 API 调用有什么区别？
• 多 Agent 协作有哪些常见问题？
• Eino 里面 Workflow、Chain、Graph 有什么区别？
• Agent 如何避免一直循环调用工具？

这样做的好处是，项目不只是一个功能演示，也能变成自己的学习资料库。

三、不要把前端项目强行做成飞书机器人

老师指出的另一个问题是：前端不能强行做成飞书机器人。

我之前的思路是把机器人能力接到飞书里，想让乘客、司机或者用户通过飞书机器人提问。但老师提醒我，这个方向不一定适合前端项目，因为不能保证每个用户、司机或者业务人员都有飞书，也不能确定他们会在飞书里使用这个功能。

这句话让我意识到：项目设计不能只为了“看起来有 AI”，还要符合真实使用场景。

如果是企业内部系统，飞书机器人可能比较合适，因为员工本来就在飞书里办公。但如果是面向普通用户的项目，比如打车、外卖、医疗、租房这种生活类系统，直接把核心功能放到飞书里就不太自然。

所以后面如果继续做 AI 功能，更合理的方式应该是：

• 在 Web 页面里做一个聊天入口
• 在后台管理系统里做一个智能助手
• 在移动端页面里做一个问答窗口
• 飞书机器人只作为企业内部通知或辅助入口，而不是主要入口

四、项目应该面向企业搭建 Eino，而不是强行绑定某个平台

老师还说，要对标企业去搭建 Eino，而不是只围绕某个具体平台做功能。

我的理解是：Eino 更适合做一个 AI 应用的编排框架。它可以把模型、工具、知识库、工作流、Agent 等能力组合起来。重点不是“我接了一个飞书机器人”，而是“我能不能用 Eino 搭建一套企业可用的 AI 应用流程”。

企业里更关心的是：

• 能不能接企业自己的数据库
• 能不能接企业自己的知识库
• 能不能调用内部业务接口
• 能不能控制权限
• 能不能记录日志
• 能不能配置工作流
• 能不能保证回答稳定
• 出错后能不能追踪

也就是说，Eino 项目不应该只写成一个“聊天机器人”，而应该表达成一个“企业智能助手搭建方案”。

比如可以做成：

基于 Eino 的企业知识库问答与业务工具调用助手

或者：

基于 Eino 的企业内部智能问答工作流系统

这样会比单纯说“飞书机器人”更适合写项目。

五、需要深入理解 Eino 的工作流

老师也提醒我，Eino 的工作流需要深入了解。

我现在对 Eino 的理解还停留在工具接入、机器人回答这些表层功能上。后面需要继续看它的核心机制，比如：

• Chain 是什么
• Graph 是什么
• Workflow 怎么组织节点
• Tool 怎么注册和调用
• Agent 怎么决定调用哪个工具
• 节点之间的数据怎么传递
• 出错后怎么处理
• 怎么做流式输出
• 怎么做日志追踪
• 怎么控制工具调用次数

如果这些不了解清楚，项目讲起来就会显得只是“调了一个模型 API”。

真正有价值的是能讲清楚：

用户提出问题后，系统如何经过意图识别、知识检索、工具调用、结果整理，最后生成回答。

这才是 Eino 工作流的重点。

六、支付幂等和数据保护需要加强

老师还指出支付幂等和保护需要加强。

这个问题很重要，因为支付相关的业务不能只看前端页面能不能跳转，还要考虑后端数据安全。

支付幂等的意思是：同一笔支付请求，即使因为网络问题、用户重复点击、支付回调重复通知等原因执行多次，也只能产生一次有效结果。

如果没有幂等保护，可能会出现：

• 用户重复支付
• 司机收益重复增加
• 订单状态被重复修改
• 账单重复生成
• 后台数据对不上

支付场景里至少要考虑这些保护：

1. 每笔订单只能生成一条有效账单
2. 同一支付流水号只能处理一次
3. 支付成功回调要判断订单当前状态
4. 更新订单和增加收益最好放在事务里
5. 支付接口要防止重复点击
6. 关键操作要记录日志
7. 失败时要能回滚或补偿

之前我更多关注的是“支付后页面怎么跳转”“司机收益什么时候增加”，但老师提醒我，真正项目里还要考虑支付安全和数据一致性。

七、今天暴露出来的主要问题

总结下来，今天暴露的问题主要有这几个：

1. 对 RAG 的理解还不够深，只做了简单检索，没有深入到向量、召回、排序、评估这些内容。
2. 项目里的 AI 能力还偏演示，缺少更贴近企业场景的设计。
3. 不应该把前端功能强行绑定到飞书机器人，要考虑真实用户使用场景。
4. 对 Eino 工作流了解还不够，需要继续学习 Chain、Graph、Tool、Agent 编排这些内容。
5. 支付相关逻辑不能只看页面效果，还要考虑幂等、防重复、事务和数据保护。

这些问题都挺实际的，也说明项目后面还有很多可以优化的地方。

八、后面准备怎么改

后面我准备从这几个方向继续补：

1. 深入学习 RAG

不只停留在本地 Markdown 检索，而是继续了解：

• 文档切分
• Embedding
• 向量数据库
• TopK 检索
• 相似度计算
• 检索结果重排
• 回答引用资料
• RAG 效果评估

2. 整理 Agent 工程师面试题知识库

把 Agent、RAG、MCP、Tool Calling、Eino 工作流这些问题整理成知识库，既能用于项目演示，也能帮助自己复习。

3. 调整项目定位

不再把重点放在“飞书机器人”，而是改成更通用的企业智能助手，比如：

• 企业知识库问答
• 业务数据查询
• 内部工具调用
• 工作流编排
• 后台智能助手

4. 深入看 Eino 工作流

重点补 Eino 里面的：

• Chain
• Graph
• Workflow
• Tool
• Agent
• Callback
• Streaming
• Error Handling

争取后面能讲清楚完整执行链路。

5. 加强支付和关键业务保护

支付相关功能后续要重点考虑：

• 幂等控制
• 事务处理
• 重复回调处理
• 支付流水号唯一性
• 状态流转校验
• 日志记录
• 异常补偿

九、这次复盘的收获

今天老师指出的问题让我意识到，项目不是功能堆得越多越好，而是要讲得清楚、设计得合理。

AI 项目不能只是“接了一个大模型”，而是要说清楚：

• 为什么要用 RAG
• RAG 怎么做得更可靠
• Agent 怎么调用工具
• 工具调用失败怎么办
• 工作流怎么编排
• 企业场景为什么需要这个东西

业务项目也不能只看页面有没有效果，还要考虑：

• 数据有没有一致
• 支付有没有幂等
• 状态流转有没有校验
• 异常情况有没有处理
• 用户真实场景是否合理

这次复盘后，我对后面项目优化方向更清楚了。接下来不能只做表面功能，要把 RAG、Eino 工作流、企业场景设计和关键业务保护这些内容真正补起来。