从 Multi-Agent 到项目部署：我今天终于把 Agent 项目“从概念到落地”串起来了

Stick_ZYZ

218人浏览 · 2026-05-28 21:42:36

Stick_ZYZ · 2026-05-28 21:42:36 发布

一、前言：以前我只看“技术点”，今天开始看“项目整体”

以前学习 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 解决的问题不一样。

对比项	Skill	RAG
主要作用	封装处理某类任务的方法	检索外部知识
更像什么	能力说明书 / 操作流程	知识库 / 资料库
内容特点	偏流程、步骤、规范	偏文档、事实、经验
是否可能同时使用	可以	可以

举个例子：

如果我要做一个“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 不只是一个容器，它可能还需要：

etcd；
MinIO；
volume；
network。

而 Makefile 的作用是：

把复杂命令封装成简单指令。

比如原来要执行很多命令：

docker compose up -d
docker compose logs -f
docker compose down

可以封装成：

make up
make logs
make down

这在企业中也很常见。

不过企业里不一定只用 Makefile，还可能用：

Shell 脚本；
Docker Compose；
Jenkins；
GitLab CI；
Kubernetes YAML；
Helm Chart；
Ansible；
Terraform。

这些本质上都是为了一个目标：

把复杂、重复、容易出错的操作自动化。

十、今天的整体学习脉络

今天的内容比较散，但其实可以串成一条线：

Agent 项目设计
   ↓
Multi-Agent 协作
   ↓
共享状态传递
   ↓
Planner / Executor / Supervisor / Replanner 分工
   ↓
异常处理与 Replan
   ↓
幻觉控制与工具校验
   ↓
Skill 和 RAG 的关系
   ↓
传统 NLP 与大模型的区别
   ↓
Docker Compose / Makefile 工程化部署

也就是说，今天不是只学了某一个技术点，而是在补齐一个 AI Agent 项目的完整认知。

从“会调接口”到“能设计系统”，中间差的就是这些东西。