Agent

整体架构

下图即是项目的整体架构

可以分为

1. 接入层
2. 业务层
3. 服务层
4. 存储层

知识库Agent

本质上是RAG的过程，在对话Agent和运维Agent里，基本都会使用到RAG

核心流程

RAG的整体流程分为两部分：
提问前(数据准备)：分片->embedding ->存储
提问后(回答生成）：召回->重排->生成

提问前链路（数据准备）

1. 分片：将原始文档（如业务告警处理手册）切割为多个语义完整的片段。
2. 索引：
   。用Embedding模型将每个片段转为向量。
   。将片段文本和向量存入向量数据库。
3. 完成后，知识库即构建完毕，等待用户提问。

提问后链路（回答生成）

1. 召回：用户问题->Embedding模型->向量->向量数据库->Top10相关片段。

2. 重排: Top10片段->Cross Encoder模型->Top3最相关片段。

3. 生成：Top3片段+用户问题->大模型->最终答案。

项目细节

读取文件
我们直接传入文件路径path，调用Files.readString读取文件内容到内存

文件分块

其他的文件可以考虑使用minerU将pdf文件这些提取信息

1.第一层按照Markdown的标题#切分，将文档按照标题分割成多个章节Section
2.第二层对每个章节进行分配，如果章节小于MaxSize，则直接将这个章节作为一个分配。
3.如果章节大于MaxSize，则对段落边界进行切分
4.对于对段落边界进行切分的地方，还会根据Overlap，实现段落间内容重叠，来保持段落之间的上下文语义连贯

文件索引（向量化和存储到数据库）

1. 首先对所有分片进行向量化，获取向量数组

2. 构造符合milvus表记录的结构体。id、content、vector、metadata

3. 构造完记录后，插入到数据库中

召回
我们之前是将文档存储到了Milvus向量数据库里面，所以召回的时候也是从这个数据库去查询。

1. 将查询文本向量化
2. 相似度查询(余弦相似度)

对话Agent

使用ReAct模式，ReAct=Reasoning(推理)+ Acting(行动)，核心是让 AI 像人一样边想边做、边做边调整，通过思考->行动->观察->再思考来解决问题。

流程梳理
对话Agent的核心目标是结合外部知识(RAG召回）与工具调用能力(ReAct模式），解决复杂问题。
整体流程可概括为：

1. 用户输入->embedding->向量数据库召回
2. 构建带上下文(召回的内容)的prompt
3. ReAct模式多轮交互
4. 最终输出答案

不足的地方

记忆存储，当前只是使用ConcurrentHashMap进行存储的，没有长期进行存储，可以升级为长期记忆存储（向量书库）

运维Agent

运维Agent的核心目标是将运维人员的告警处理经验转化为自动化流程。使用Plan-Execute-Replan的设计模式，即先规划-再执行，再重新规划

与ReAct的核心区别：先规划vs边想边做

对比维度	Plan-Execute-Replan	ReAct
核心思路	结构化计划（先拆步骤，按计划执行）	实时决策(边想边做，无固定步骤）
适用场景	复杂流程类任务(如报告生成、项目管理)	灵活探索类任务(如问答、解谜)
步骤特点	提前规划步骤序列（可动态调整）	动态生成下一步（无预设顺序）
优势	任务进度可控、步骤清晰有序	灵活应对未知情况

运维Agent的自动化能力源于三方面协同：
结构化规划：Planner将模糊的运维经验转化为可执行步骤，降低复杂告警的处理门槛
工具化执行：Executor集成监控/日志系统，替代人工重复操作，提升响应速度
动态的调整：Replanner根据实时结果修正计划，适配下游发版/临时抖动等不确定性场景

使用框架的SupervisorAgent能力，可以自动的帮助我们管理PlanAgent和ExecutorAgent之间的执行扭转，其核心就是流程控制，与Plan对象在整个流程中的传递而已。

面试相关

使用场景

简单介绍一下你设计的几个Agent
在项目里一共实现了3个Agent，分别是知识库Agent、对话Agent和运维Agent。

• 知识库Agent的核心目标是作为团队文档管理和AI应用的基础设施，通过自动化流程，将我们日常积累的文档
  （告警处理手册、技术方案、错误码文档），转化为可被AI高效检索的向量，为后续的RAG提供了高质量的向量数据支撑。举个最常见的例子，当我们想根据一个模糊的回忆找文档的时候，可以根据模糊的提问快速检索到对应文档，不再需要再嵌套目录里面一个一个翻了。
• 对话Agent本质上是一个基于大模型+知识库构造的ReAct模式智能交互系统。你可以把它看作是一个能够像真人一样理解问题、调用知识库检索并给出精准回答的小助手。它最重要的使命就是帮助团队挡掉高频的重复咨询，加速问题解决，从而提高整体的工作效率。
• 运维Agent是为了解决值班排查问题的痛点而做的。运维Agent主要是使用了Plan-Execute-Replan设计模式，自动规划排查步骤，通过调用各平台的API，实现跨系统联动，一站式完成排查。这些告警从服务错误、性能波动，到中间件异常、下游依赖故障，告警太多了。传统的处理方式往往依赖于人工排查：看告警、查日志、查监控，最终才能判断问题的根源。整个过程重复、耗时，特别是在晚上或节假日，响应效率和准确性更是难以保障，值班的时候告警一多就很痛苦。运维Agent可以通过调用各平台的API，实现跨系统联动，一站式完成排查。例如，它可以自动从告警中提取接口名和时间范围，查询日志、查询监控、查询告警处理手册，将所有信息汇总成一份结构化的故障排查报告。

ReAct和Plan-Execute-Replan有什么区别？

• ReAct适合边想边做，没有固定步骤

• Plan-Execute-Replan适合处理复杂任务，先拆解步骤，再执行，根据执行结果判断要不要修改计划

• 所以在我的项目中，对话场景用ReAct，因为用户问题灵活，需实时决策。它的职责是处理开放式的，多轮的业务咨询，比如回答某个API怎么用，特点是灵活，能根据对话历史动态决定下一步做什么，但执行链条不会预设得特别长。

• 运维场景用Plan-Execute-Replan，比如专门处理告警。它的职责是接受一个明确目标，然后制定一个可能包含多步骤的排查计划，并严格按计划调用各工具执行。

• 它们底层共享同一套工具集和知识库，但工作模式和目标不同。

你的工具集有哪些Tool，分别有什么功能？

• 其实设计tool就是要思考Agent需要哪些功能
• 首先想到的是知识库召回工具，从向量数据库中召回最相关的3份片段
• 然后是日志查询工具，日志查询是通过腾讯云日志平台的MCP实现的，他们的MCP支持用自然语言查询日志
• 还有告警查询工具，对接监控系统的/alerts接口，直接获取当前活跃告警信息
• 其实在测试过程中，我还发现大模型不能精准知道当前时刻的时间，所以还编写了一个时间查询工具，为Agent提供实时时间信息
• 最后还有一个联网查询工具，集成外部搜索引擎，让大模型也有搜谷歌的能力

你的项目用的是什么模型？

• 向量模型我使用的是阿里的text-embedding-v4
• 语言模型我使用的是qwen3-max

召回与重排的区别是什么？

• 召回：快速捞出相关片段
  • 将用户问题通过Embedding模型转化为向量。
  • 用向量相似度算法计算问题向量与数据库中所有片段向量的相似度，挑出TopN（如10个）最相关的片段。
  • 特点：速度快、成本低，但准确率有限，适合初步筛选-
• 重排：给片段排优先级
  • 使用专门计算文本对相似度的模型，逐对计算用户问题与每个召回片段的语义相关性。
  • 从10个片段中选出TopK(如3个)最相关的片段。
  • 为什么不直接召回3个？召回用向量相似度(快但准度低)，重排用CrossEncoder模型（慢但准度高），二者结合实现先广撒网再精挑细选，效果优于一步到位。

你做这个项目遇到过什么困难/挑战？
其实最大的困难是在于写文档，之前的告警处理手册其实是很多人都会往里面加东西，很多步骤可能表述的不是很清晰，最蛋疼的是有些超链接，链接到其他文档，写的不完整

• 那对于我们做RAG来说，第一步就是要把文档写完整完善，否则会影响召回的质量，以及大模型的判断
• 另外我觉得印象比较深刻的点在于，这个项目是我实习到时候偷摸做的，因为实习的时候安排我也值班。
• 值班我就发现了这些痛点，太浪费时间了值班。老是要翻日志看监控，回复很多相同的问题。说白了就是比较打杂，维护老项目。让我打杂但是我不能真打杂浪费时间啊，所以我偷偷做这个项目，好在最后做出来了，不论是对其他人值班，还是对自己值班，真有帮助。我还觉得挺有成就感的。

改进方向

• 增加多模态能力
• 支持多租户，多租户隔离，知识库隔离，权限隔离，资源隔离