今日项目介绍复盘：老师指出的问题和我需要补上的知识点

今天给老师介绍了自己最近做的机器人和 RAG 相关内容。整体讲下来老师主要不是否定我做的功能而是指出我对一些底层概念理解还不够深项目选型和表达方式也需要再调整。这里把今天老师提到的问题和我自己的理解记录下来方便后面继续补。一、RAG 不能只停留在“能检索”这一层我今天介绍了项目里加的本地 RAG 功能也就是把一些业务文档放到本地知识库里用户提问时先检索文档再让模型结合资料回答。这个思路本身没问题但老师提醒我RAG 不能只理解成“查文档再回答”。如果以后面试或者讲项目只说“我做了一个 RAG”其实还不够。RAG 里面需要继续深入理解这些内容文档怎么切分切分粒度怎么控制怎么生成向量向量数据库怎么检索TopK 怎么选检索结果怎么排序召回不准怎么办如何减少大模型胡说怎么判断回答是否真的引用了资料我之前做的更多是一个简单版本偏演示效果真正要写到简历或者面试里还需要把 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 工作流的重点。六、支付幂等和数据保护需要加强老师还指出支付幂等和保护需要加强。这个问题很重要因为支付相关的业务不能只看前端页面能不能跳转还要考虑后端数据安全。支付幂等的意思是同一笔支付请求即使因为网络问题、用户重复点击、支付回调重复通知等原因执行多次也只能产生一次有效结果。如果没有幂等保护可能会出现用户重复支付司机收益重复增加订单状态被重复修改账单重复生成后台数据对不上支付场景里至少要考虑这些保护每笔订单只能生成一条有效账单同一支付流水号只能处理一次支付成功回调要判断订单当前状态更新订单和增加收益最好放在事务里支付接口要防止重复点击关键操作要记录日志失败时要能回滚或补偿之前我更多关注的是“支付后页面怎么跳转”“司机收益什么时候增加”但老师提醒我真正项目里还要考虑支付安全和数据一致性。七、今天暴露出来的主要问题总结下来今天暴露的问题主要有这几个对 RAG 的理解还不够深只做了简单检索没有深入到向量、召回、排序、评估这些内容。项目里的 AI 能力还偏演示缺少更贴近企业场景的设计。不应该把前端功能强行绑定到飞书机器人要考虑真实用户使用场景。对 Eino 工作流了解还不够需要继续学习 Chain、Graph、Tool、Agent 编排这些内容。支付相关逻辑不能只看页面效果还要考虑幂等、防重复、事务和数据保护。这些问题都挺实际的也说明项目后面还有很多可以优化的地方。八、后面准备怎么改后面我准备从这几个方向继续补1. 深入学习 RAG不只停留在本地 Markdown 检索而是继续了解文档切分Embedding向量数据库TopK 检索相似度计算检索结果重排回答引用资料RAG 效果评估2. 整理 Agent 工程师面试题知识库把 Agent、RAG、MCP、Tool Calling、Eino 工作流这些问题整理成知识库既能用于项目演示也能帮助自己复习。3. 调整项目定位不再把重点放在“飞书机器人”而是改成更通用的企业智能助手比如企业知识库问答业务数据查询内部工具调用工作流编排后台智能助手4. 深入看 Eino 工作流重点补 Eino 里面的ChainGraphWorkflowToolAgentCallbackStreamingError Handling争取后面能讲清楚完整执行链路。5. 加强支付和关键业务保护支付相关功能后续要重点考虑幂等控制事务处理重复回调处理支付流水号唯一性状态流转校验日志记录异常补偿九、这次复盘的收获今天老师指出的问题让我意识到项目不是功能堆得越多越好而是要讲得清楚、设计得合理。AI 项目不能只是“接了一个大模型”而是要说清楚为什么要用 RAGRAG 怎么做得更可靠Agent 怎么调用工具工具调用失败怎么办工作流怎么编排企业场景为什么需要这个东西业务项目也不能只看页面有没有效果还要考虑数据有没有一致支付有没有幂等状态流转有没有校验异常情况有没有处理用户真实场景是否合理这次复盘后我对后面项目优化方向更清楚了。接下来不能只做表面功能要把 RAG、Eino 工作流、企业场景设计和关键业务保护这些内容真正补起来。