一、前言以前我只看“技术点”今天开始看“项目整体”以前学习 Agent、RAG、MCP、Docker 这些内容的时候我经常是一个点一个点地看。比如RAG 是用来检索知识库的Multi-Agent 是多个 Agent 协作Skill 是封装某种能力Docker Compose 是用来启动服务的Makefile 是用来封装命令的。但是今天聊下来我发现这些东西其实不是孤立的。它们真正放到项目里之后会变成一个完整链路用户提出问题 → Agent 理解任务 → Planner 拆解任务 → Executor 调用工具 → RAG/Skill 提供知识支持 → Supervisor 判断结果 → 必要时 Replan → 最后输出答案。而项目要真正跑起来还需要 Docker、Compose、Makefile 这些工程化工具。所以今天最大的收获是AI Agent 项目不是简单调一个大模型接口而是一个包含任务规划、工具调用、状态管理、异常处理、知识增强和工程部署的完整系统。二、Multi-Agent 不是“多个聊天机器人”而是分工协作今天重点讨论了 Multi-Agent 项目中几个 Agent 的职责划分。在面试表达里不能简单说我用了多个 Agent。这样太空了。更好的说法是我把系统拆成了多个角色型 Agent不同 Agent 负责不同阶段的任务比如任务规划、工具执行、结果校验和重新规划从而提升复杂问题处理能力。比如在智能运维 Agent 项目中可以这样设计Agent 角色主要职责Planner Agent分析用户问题拆解排障步骤Executor Agent根据计划调用日志、监控、知识库等工具Supervisor Agent判断执行结果是否满足目标Replanner Agent如果结果不足重新调整执行计划这样一说面试官就能听出来你不是为了堆概念才用 Multi-Agent而是为了解决复杂排障任务中的流程控制问题。三、共享状态不是神秘东西本质是 Agent 协作时的“公共记录本”今天我们还重点聊了一个很容易让人迷糊的概念共享状态 / OverallState / Global Context。一开始我容易把它理解成某个神秘组件好像所有 Agent 都能直接“看见”一个公共大脑。但后来理解之后发现它其实可以简单理解成多个 Agent 协作过程中的公共记录本。这个状态里可能会保存用户原始问题当前任务计划每一步执行结果工具调用返回内容当前是否完成是否需要重新规划最终答案。比如用户问为什么我的服务接口响应变慢了Planner Agent 先生成计划1. 查询接口最近 30 分钟响应时间 2. 查询服务日志是否有异常 3. 查询数据库慢 SQL 4. 综合判断可能原因Executor Agent 执行完每一步后会把结果写回状态中。Supervisor Agent 再根据这些结果判断是否已经定位问题 是否还需要继续查询 是否需要 Replan所以共享状态不是单纯的 prompt也不是聊天窗口而是Agent 编排框架在执行流程中维护的一份结构化上下文。四、Agent 为什么需要 Replan今天还聊到一个关键问题怎么判断结果好不好什么时候需要重新规划这个问题特别适合面试因为它能体现项目不是简单调用模型而是有流程控制能力。在智能运维场景里Replan 通常发生在这些情况1. 工具调用失败比如日志查询工具超时或者监控系统没有返回数据。这时不能直接回答用户没查到。而应该让 Replanner 换一种方式原计划查询最近 30 分钟日志 失败原因日志服务超时 新计划缩小时间范围查询最近 5 分钟日志并补充查询监控指标2. 返回结果不足比如工具查到了 CPU 正常、内存正常但是用户的问题还没解释清楚。这时 Supervisor 可以判断当前证据不足不能下结论。然后触发 Replan继续查询数据库、网络、下游服务。3. 结果之间存在冲突比如监控显示服务正常但是日志里大量报错。这时候不能直接输出结论而是应该进一步分析可能是部分实例异常整体监控均值掩盖了问题。然后继续查询实例级别日志。五、项目中如何避免大模型幻觉今天另一个重点是Agent 项目怎么避免大模型胡说在面试里这个问题一定要回答得工程化不能只说“加强 prompt”。比较好的回答是我主要从提示词约束、工具结果校验、RAG 证据引用、结构化输出和 Replan 机制几个方面降低幻觉。可以这样展开1. Prompt 约束在系统提示词中明确要求严禁编造不存在的日志、指标和故障原因。 所有结论必须基于工具返回结果。 如果证据不足需要明确说明无法判断。2. 工具结果作为主要依据Agent 不能凭感觉回答而是要先调用工具。比如查日志查监控查告警查知识库查数据库状态。最终回答必须基于这些工具返回的信息。3. RAG 提供知识依据对于排障经验、故障手册、接口文档等内容可以放入知识库。用户提问时系统先检索相关文档再让大模型基于文档回答。这样可以减少模型凭空编造。4. Supervisor 校验结果Supervisor Agent 可以判断当前答案是否有依据 是否回答了用户问题 是否存在明显缺失 是否需要重新规划这就是 Multi-Agent 在可靠性上的价值。六、Skill 和 RAG 不是互斥关系今天也聊到一个很重要的点有了 Skill是不是就不需要 RAG 了这个理解其实不对。Skill 和 RAG 解决的问题不一样。对比项SkillRAG主要作用封装处理某类任务的方法检索外部知识更像什么能力说明书 / 操作流程知识库 / 资料库内容特点偏流程、步骤、规范偏文档、事实、经验是否可能同时使用可以可以举个例子如果我要做一个“Java 异常排查 Skill”里面可以写当用户询问 Java 服务异常时 1. 先分析异常类型 2. 再判断是否和配置、依赖、网络、数据库有关 3. 如果涉及历史故障经验需要查询知识库 4. 最后按原因、证据、解决方案输出这里 Skill 负责告诉 Agent遇到这类问题应该怎么处理。而 RAG 负责提供具体的故障文档、历史案例、解决方案。所以更准确的理解是Skill 是能力流程RAG 是知识来源。Skill 里完全可以要求 Agent 在某一步调用 RAG。七、Agent 挂了怎么办这才是工程化问题今天还聊到一个非常项目化的问题如果其中一个 Agent 挂了怎么办这个问题很有价值因为真实项目里不能只考虑正常流程还要考虑异常流程。常见处理方式有几种1. 重试机制如果某个 Agent 调用失败可以自动重试。比如第一次调用失败 → 等待 1 秒 → 再试一次 → 仍失败则降级适合处理网络波动、模型接口偶发失败等问题。2. 超时控制不能让一个 Agent 无限等待。比如 Executor Agent 调用日志工具如果超过 10 秒没有返回就应该认为失败。然后把失败原因写入共享状态。3. 降级处理如果某个 Agent 无法工作可以走简化流程。比如 Replanner Agent 挂了系统可以不重新规划而是直接基于已有结果输出目前已查询到部分信息但由于进一步分析模块异常无法继续定位。这比直接系统崩溃要好。4. Supervisor 兜底Supervisor 可以作为流程控制者判断某个节点失败后是否继续执行、重新规划或者终止任务。这也是 Multi-Agent 编排中很重要的一环。八、传统 NLP 和大模型的区别今天还简单分析了传统 NLP。传统 NLP 更依赖人工设计流程比如分词词性标注命名实体识别关键词提取情感分析文本分类。它通常是针对某个具体任务训练一个模型。比如输入一句话 → 判断情感是正面还是负面而大模型更像是一个通用语言能力底座。它可以同时完成问答总结翻译推理代码生成工具调用多轮对话。所以可以简单理解为传统 NLP 更像“专用工具”大模型更像“通用语言智能底座”。但是传统 NLP 也不是完全没用了。在实际项目中传统 NLP 的一些思想仍然很重要比如文本切分关键词匹配BM25 检索意图识别实体抽取。这些能力在 RAG、Agent、搜索系统中依然会出现。九、Docker Compose 和 Makefile 是项目落地的工程化补充虽然 Docker Compose 和 Makefile 不是今天的主线但它们是项目真正运行起来的关键。今天理解到docker-compose.yml不是业务代码而是用来描述多个服务如何一起启动。比如 Milvus 不只是一个容器它可能还需要etcdMinIOvolumenetwork。而 Makefile 的作用是把复杂命令封装成简单指令。比如原来要执行很多命令docker compose up -d docker compose logs -f docker compose down可以封装成make up make logs make down这在企业中也很常见。不过企业里不一定只用 Makefile还可能用Shell 脚本Docker ComposeJenkinsGitLab CIKubernetes YAMLHelm ChartAnsibleTerraform。这些本质上都是为了一个目标把复杂、重复、容易出错的操作自动化。十、今天的整体学习脉络今天的内容比较散但其实可以串成一条线Agent 项目设计 ↓ Multi-Agent 协作 ↓ 共享状态传递 ↓ Planner / Executor / Supervisor / Replanner 分工 ↓ 异常处理与 Replan ↓ 幻觉控制与工具校验 ↓ Skill 和 RAG 的关系 ↓ 传统 NLP 与大模型的区别 ↓ Docker Compose / Makefile 工程化部署也就是说今天不是只学了某一个技术点而是在补齐一个 AI Agent 项目的完整认知。从“会调接口”到“能设计系统”中间差的就是这些东西。十一、总结今天的学习让我对 AI Agent 项目有了更完整的理解。以前我可能会觉得 Agent 项目就是大模型 工具调用 RAG。但现在更准确的理解应该是Agent 项目是一个由大模型驱动的任务执行系统它需要规划、执行、状态传递、工具调用、知识增强、异常处理和工程化部署共同支撑。其中Multi-Agent 解决复杂任务分工问题共享状态解决 Agent 之间的信息传递问题Replan 解决执行过程中的不确定性问题Supervisor 解决结果校验问题Skill 解决能力复用问题RAG 解决外部知识补充问题Docker Compose / Makefile 解决项目部署和运行问题。今天最大的收获不是记住了某个概念而是开始把这些技术点放到一个真实项目里理解。这对后面准备实习面试很重要。因为面试官真正想听的不是我学过 Agent。而是我知道 Agent 在项目里怎么设计、怎么协作、怎么避免幻觉、怎么处理异常以及怎么真正跑起来。
从 Multi-Agent 到项目部署：我今天终于把 Agent 项目“从概念到落地”串起来了
发布时间：2026/5/29 6:45:01
一、前言以前我只看“技术点”今天开始看“项目整体”以前学习 Agent、RAG、MCP、Docker 这些内容的时候我经常是一个点一个点地看。比如RAG 是用来检索知识库的Multi-Agent 是多个 Agent 协作Skill 是封装某种能力Docker Compose 是用来启动服务的Makefile 是用来封装命令的。但是今天聊下来我发现这些东西其实不是孤立的。它们真正放到项目里之后会变成一个完整链路用户提出问题 → Agent 理解任务 → Planner 拆解任务 → Executor 调用工具 → RAG/Skill 提供知识支持 → Supervisor 判断结果 → 必要时 Replan → 最后输出答案。而项目要真正跑起来还需要 Docker、Compose、Makefile 这些工程化工具。所以今天最大的收获是AI Agent 项目不是简单调一个大模型接口而是一个包含任务规划、工具调用、状态管理、异常处理、知识增强和工程部署的完整系统。二、Multi-Agent 不是“多个聊天机器人”而是分工协作今天重点讨论了 Multi-Agent 项目中几个 Agent 的职责划分。在面试表达里不能简单说我用了多个 Agent。这样太空了。更好的说法是我把系统拆成了多个角色型 Agent不同 Agent 负责不同阶段的任务比如任务规划、工具执行、结果校验和重新规划从而提升复杂问题处理能力。比如在智能运维 Agent 项目中可以这样设计Agent 角色主要职责Planner Agent分析用户问题拆解排障步骤Executor Agent根据计划调用日志、监控、知识库等工具Supervisor Agent判断执行结果是否满足目标Replanner Agent如果结果不足重新调整执行计划这样一说面试官就能听出来你不是为了堆概念才用 Multi-Agent而是为了解决复杂排障任务中的流程控制问题。三、共享状态不是神秘东西本质是 Agent 协作时的“公共记录本”今天我们还重点聊了一个很容易让人迷糊的概念共享状态 / OverallState / Global Context。一开始我容易把它理解成某个神秘组件好像所有 Agent 都能直接“看见”一个公共大脑。但后来理解之后发现它其实可以简单理解成多个 Agent 协作过程中的公共记录本。这个状态里可能会保存用户原始问题当前任务计划每一步执行结果工具调用返回内容当前是否完成是否需要重新规划最终答案。比如用户问为什么我的服务接口响应变慢了Planner Agent 先生成计划1. 查询接口最近 30 分钟响应时间 2. 查询服务日志是否有异常 3. 查询数据库慢 SQL 4. 综合判断可能原因Executor Agent 执行完每一步后会把结果写回状态中。Supervisor Agent 再根据这些结果判断是否已经定位问题 是否还需要继续查询 是否需要 Replan所以共享状态不是单纯的 prompt也不是聊天窗口而是Agent 编排框架在执行流程中维护的一份结构化上下文。四、Agent 为什么需要 Replan今天还聊到一个关键问题怎么判断结果好不好什么时候需要重新规划这个问题特别适合面试因为它能体现项目不是简单调用模型而是有流程控制能力。在智能运维场景里Replan 通常发生在这些情况1. 工具调用失败比如日志查询工具超时或者监控系统没有返回数据。这时不能直接回答用户没查到。而应该让 Replanner 换一种方式原计划查询最近 30 分钟日志 失败原因日志服务超时 新计划缩小时间范围查询最近 5 分钟日志并补充查询监控指标2. 返回结果不足比如工具查到了 CPU 正常、内存正常但是用户的问题还没解释清楚。这时 Supervisor 可以判断当前证据不足不能下结论。然后触发 Replan继续查询数据库、网络、下游服务。3. 结果之间存在冲突比如监控显示服务正常但是日志里大量报错。这时候不能直接输出结论而是应该进一步分析可能是部分实例异常整体监控均值掩盖了问题。然后继续查询实例级别日志。五、项目中如何避免大模型幻觉今天另一个重点是Agent 项目怎么避免大模型胡说在面试里这个问题一定要回答得工程化不能只说“加强 prompt”。比较好的回答是我主要从提示词约束、工具结果校验、RAG 证据引用、结构化输出和 Replan 机制几个方面降低幻觉。可以这样展开1. Prompt 约束在系统提示词中明确要求严禁编造不存在的日志、指标和故障原因。 所有结论必须基于工具返回结果。 如果证据不足需要明确说明无法判断。2. 工具结果作为主要依据Agent 不能凭感觉回答而是要先调用工具。比如查日志查监控查告警查知识库查数据库状态。最终回答必须基于这些工具返回的信息。3. RAG 提供知识依据对于排障经验、故障手册、接口文档等内容可以放入知识库。用户提问时系统先检索相关文档再让大模型基于文档回答。这样可以减少模型凭空编造。4. Supervisor 校验结果Supervisor Agent 可以判断当前答案是否有依据 是否回答了用户问题 是否存在明显缺失 是否需要重新规划这就是 Multi-Agent 在可靠性上的价值。六、Skill 和 RAG 不是互斥关系今天也聊到一个很重要的点有了 Skill是不是就不需要 RAG 了这个理解其实不对。Skill 和 RAG 解决的问题不一样。对比项SkillRAG主要作用封装处理某类任务的方法检索外部知识更像什么能力说明书 / 操作流程知识库 / 资料库内容特点偏流程、步骤、规范偏文档、事实、经验是否可能同时使用可以可以举个例子如果我要做一个“Java 异常排查 Skill”里面可以写当用户询问 Java 服务异常时 1. 先分析异常类型 2. 再判断是否和配置、依赖、网络、数据库有关 3. 如果涉及历史故障经验需要查询知识库 4. 最后按原因、证据、解决方案输出这里 Skill 负责告诉 Agent遇到这类问题应该怎么处理。而 RAG 负责提供具体的故障文档、历史案例、解决方案。所以更准确的理解是Skill 是能力流程RAG 是知识来源。Skill 里完全可以要求 Agent 在某一步调用 RAG。七、Agent 挂了怎么办这才是工程化问题今天还聊到一个非常项目化的问题如果其中一个 Agent 挂了怎么办这个问题很有价值因为真实项目里不能只考虑正常流程还要考虑异常流程。常见处理方式有几种1. 重试机制如果某个 Agent 调用失败可以自动重试。比如第一次调用失败 → 等待 1 秒 → 再试一次 → 仍失败则降级适合处理网络波动、模型接口偶发失败等问题。2. 超时控制不能让一个 Agent 无限等待。比如 Executor Agent 调用日志工具如果超过 10 秒没有返回就应该认为失败。然后把失败原因写入共享状态。3. 降级处理如果某个 Agent 无法工作可以走简化流程。比如 Replanner Agent 挂了系统可以不重新规划而是直接基于已有结果输出目前已查询到部分信息但由于进一步分析模块异常无法继续定位。这比直接系统崩溃要好。4. Supervisor 兜底Supervisor 可以作为流程控制者判断某个节点失败后是否继续执行、重新规划或者终止任务。这也是 Multi-Agent 编排中很重要的一环。八、传统 NLP 和大模型的区别今天还简单分析了传统 NLP。传统 NLP 更依赖人工设计流程比如分词词性标注命名实体识别关键词提取情感分析文本分类。它通常是针对某个具体任务训练一个模型。比如输入一句话 → 判断情感是正面还是负面而大模型更像是一个通用语言能力底座。它可以同时完成问答总结翻译推理代码生成工具调用多轮对话。所以可以简单理解为传统 NLP 更像“专用工具”大模型更像“通用语言智能底座”。但是传统 NLP 也不是完全没用了。在实际项目中传统 NLP 的一些思想仍然很重要比如文本切分关键词匹配BM25 检索意图识别实体抽取。这些能力在 RAG、Agent、搜索系统中依然会出现。九、Docker Compose 和 Makefile 是项目落地的工程化补充虽然 Docker Compose 和 Makefile 不是今天的主线但它们是项目真正运行起来的关键。今天理解到docker-compose.yml不是业务代码而是用来描述多个服务如何一起启动。比如 Milvus 不只是一个容器它可能还需要etcdMinIOvolumenetwork。而 Makefile 的作用是把复杂命令封装成简单指令。比如原来要执行很多命令docker compose up -d docker compose logs -f docker compose down可以封装成make up make logs make down这在企业中也很常见。不过企业里不一定只用 Makefile还可能用Shell 脚本Docker ComposeJenkinsGitLab CIKubernetes YAMLHelm ChartAnsibleTerraform。这些本质上都是为了一个目标把复杂、重复、容易出错的操作自动化。十、今天的整体学习脉络今天的内容比较散但其实可以串成一条线Agent 项目设计 ↓ Multi-Agent 协作 ↓ 共享状态传递 ↓ Planner / Executor / Supervisor / Replanner 分工 ↓ 异常处理与 Replan ↓ 幻觉控制与工具校验 ↓ Skill 和 RAG 的关系 ↓ 传统 NLP 与大模型的区别 ↓ Docker Compose / Makefile 工程化部署也就是说今天不是只学了某一个技术点而是在补齐一个 AI Agent 项目的完整认知。从“会调接口”到“能设计系统”中间差的就是这些东西。十一、总结今天的学习让我对 AI Agent 项目有了更完整的理解。以前我可能会觉得 Agent 项目就是大模型 工具调用 RAG。但现在更准确的理解应该是Agent 项目是一个由大模型驱动的任务执行系统它需要规划、执行、状态传递、工具调用、知识增强、异常处理和工程化部署共同支撑。其中Multi-Agent 解决复杂任务分工问题共享状态解决 Agent 之间的信息传递问题Replan 解决执行过程中的不确定性问题Supervisor 解决结果校验问题Skill 解决能力复用问题RAG 解决外部知识补充问题Docker Compose / Makefile 解决项目部署和运行问题。今天最大的收获不是记住了某个概念而是开始把这些技术点放到一个真实项目里理解。这对后面准备实习面试很重要。因为面试官真正想听的不是我学过 Agent。而是我知道 Agent 在项目里怎么设计、怎么协作、怎么避免幻觉、怎么处理异常以及怎么真正跑起来。
