在运维、IT、安全等多领域交织的部门，团队每天面对大量业务需求和重复性咨询。伴随大模型的发展，如何用AI优化这些场景是我主要研究方向？这篇文章分享了我从RAG到Agent的技术探索，试图为企业问答场景带来更高效的解决方案。
公司项目文档残缺，相关项目背景、知识细节无法沉淀成文档 我们的部门咨询任务多，问题重复率高，面向的用户也对计算机知识水平不一致。
大模型兴起后，我看到了RAG（检索增强生成）的潜力，在dmeo阶段先解决咨询场景，公司级别的rag通过组织架构实施。
在咨询场景中通过结合知识库检索与生成能力，AI可以接管IM软件的对话，自动回答问题。过程中我为公司IM工具开发了一个HTTP接口，初步实现了AI问答接管。然而，由于文档未经整理，回答质量不稳定——要么冗长，要么过于简洁，甚至偶尔偏离事实。
为了提升效果，我设计了一个知识库迭代搜索功能，类似“DeepSearch”。它的核心在于通过生成新查询多轮检索逐步逼近答案，避免一次性返回不精准的结果。这让我意识到，RAG的关键在于知识库的质量与检索效率。
在RAG的实践中，我尝试了多种技术方案：
v1. 向量数据库
将文档向量化，提升检索速度，但语义匹配仍需优化。
v2. 语料生成
通过LLM自动生成补充语料，补充知识库的多样性。也可以用于微调。
v3. LoRA微调
通过小规模调整模型参数，适配企业特定场景。
v4. 分类分库模式
将知识库视为一本结构化书籍，每本书配有目录（通过metadata.json管理），按主题分类存储。结合更高的分类准确度和检索效率，回答质量显著改善。
RAG解决了基础问答，但面对复杂需求时，AI仍显得被动。于是，我开始探索Agent——一个由大模型驱动的智能系统，能感知环境、规划任务、执行步骤并动态调整。LangChain的“Plan-and-Execute”框架给了我启发：Agent能根据用户问题拆解任务，迭代执行，并在结果反馈中优化路径。
我的实现逻辑包含四个核心环节：
分类
快速定位问题所属知识领域。
检索
从分库中提取相关文档,评估。
Plan
高相关度会生成分步解决方案。
执行
按计划逐步完成并输出结果。
例如，用户提问后，Agent检索文档，规划步骤，执行后返回答案，整个过程可观测、可调整。虽然目前执行逻辑偏“步进式”（走一步看一步），但已初步展现出从“被动问答”到“主动解决”的潜力。
为支持这一方案，我开发了一个UI客户端，集成：
知识库管理：维护文档结构与内容。
LLM与嵌入模型管理：自动发现Ollama模型。
MCP管理：未来计划支持SSE，提升实时性。
效果图已能展示Agent的执行流程，MCP模块还有更多扩展空间，比如集成多模态能力或更复杂的任务调度。
cli版本执行效果图：
RAG有效缓解了重复性咨询的效率瓶颈，而Agent则为复杂任务的自动化打开了新局面。在技术选型上，我主要依赖Grok-2作为核心模型，Grok-2它的推理能力和上下文理解让我快速验证了想法我并未系统评估成本，这成为后续优化的重点。单一大模型的“一刀切”方式虽然便捷，但在性能与资源平衡上仍有改进空间。
未来计划调整技术栈，构建更精细的分工协作体系：
分类器微调
通过微调一个轻量模型，提升问题分类的精度和速度，减轻主模型负担。
Rerank
利用Ollama部署小模型，在本地实现检索结果的重排序，进一步优化答案相关性。
多模型Plan
引入Grok-3、DeepSeek-R1、Gemini-Thinking等模型，针对规划（Plan）环节进行多模型推理比较，挖掘各自在逻辑推演上的优势。
任务执行分离
将执行模块拆分为独立的Single Agent，支持并行处理，提升复杂任务的吞吐量。
还有其他很多功能比如权限管控、Endpoint API、用户交互、可观测性、鲁棒性上还待实施。在工具整合层面，我期望基于MCP（Model Context Protocol）协议。客户端采用stdio模型，确保本地交互的低延迟；远端则通过SSE（Server-Sent Events）实现实时调用。
