用 4 台云服务器，跑通一套“能面试”的多智能体系统
配套课程：《AI Agent 系统设计面试现场》
关键词：多智能体协作 · 分布式部署 · 意图识别 · 规划执行 · 上下文管理 · 智能检索 · 评估反馈
0. 为什么写这篇
学完《AI Agent 系统设计面试现场》你会发现：面试官要的不是“我用了 RAG 和大模型”，而是当真实问题摆在面前时，你能不能从混乱输入里识别意图、从复杂任务里拆出 Plan、从失败执行里定位根因、从上下文爆炸里保住关键信息。
这篇不是概念科普。我把课程里的五大主线（意图识别 / 规划执行 / 上下文管理 / 智能检索 / 评估反馈）落成了一套真能跑、且跨 4 台机器分布协作的多智能体系统，并把一次端到端调用的真实链路、指标、甚至“失败→自愈”的全过程记录下来，作为你面试时可以直接讲的项目。
1. 系统架构：5 类 Agent，4 台机器
课程强调 Agent 不是单体脚本，而是有职责边界、可编排、可观测的协作体。本系统拆成 5 个 Agent + 1 个编排网关：
| 角色 | Agent | 职责（对应课程主线） | 部署机器 |
|---|---|---|---|
| 网关 / 编排 | gateway | 串起整条链路，做失败重试与根因回溯调度 | m1 |
| 意图识别 | intent | 三层意图机制（L1 归一 / L2 分类 / L3 澄清） | m1 |
| 规划 | plan | G4C 计划 + Replan 根因回溯 | m1 |
| 执行 / 工具 | exec | TAO 工具选择 + 工具注册表 | m2 |
| 上下文 / 检索 | memory | f(Context)上下文管理 + 零依赖 RAG | m3 |
| 评估 / 反馈 | eval | 量化指标 + 反馈闭环 + 看板 | m4 |
架构图（跨机内网调用）：
┌──────────────────────── m1 (120.46.194.24) ───────────────────────┐ 用户 ──POST /chat──▶ gateway ──▶ intent(8001) ──┐ │ ├──▶ plan(8002) │ └──▶ memory(8004, m3 内网) ←── exec 也会调 ├──▶ exec(8003, m2 内网) ──┘ └──▶ eval(8005, m4 内网) m2 exec ──▶ memory(8004, m3) m4 eval ──▶ dashboard(8006)每个 Agent 是独立的 HTTP 服务进程（标准库http.server，零三方依赖），通过内网192.168.0.0/24互相寻址。这样做的好处：
- 职责隔离：某个 Agent 挂了不影响其它（配合 systemd
Restart=on-failure）。 - 贴近生产：真实多智能体系统本就是“服务网格”形态，而不是单机
if/else。 - 可观测：每次调用都有全链路
Trace，可直接喂给 Eval 出指标。
2. 部署实战（华为云 FlexusX + Ubuntu 24.04）
4 台8vCPU / 16GiB的 FlexusX，Ubuntu 24.04，全部在同一个 VPC、同一可用区，内网互通（实测延迟 < 0.3ms）。
核心部署脚本（deploy.py）做三件事：
- 逐文件 SFTP 上传代码（
agentkit/包 +service.py+demo_run.py）。这里踩过一个坑：用 tar 包整体上传再解压，会出现文件内容被串号的情况（实测service.py的 md5 居然和__init__.py一致）。改成逐文件上传后稳定。 - 写 systemd unit 并托管。比
nohup &可靠得多——SSH 会话断开后进程不会被回收：
[Unit] Description=AgentKit intent After=network.target [Service] Type=simple WorkingDirectory=/opt/agentkit Environment=AGENT=intent Environment=AGENTKIT_CONFIG=/opt/agentkit/config.json ExecStart=/usr/bin/python3 /opt/agentkit/service.py Restart=on-failure RestartSec=2 [Install] WantedBy=multi-user.target- 从 m1 内部探活各 Agent（注意：健康检查要走内网地址，不能从本地机器直连私网）。
启动后服务状态：
● agentkit-exec.service active (running) ● agentkit-memory.service active (running) ● agentkit-eval.service active (running) ● agentkit-dashboard.service active (running)跨机连通性实测（m1 → m2 私网）：
$ curl -s http://192.168.0.40:8003/health {"status": "ok", "agent": "exec"}3. 端到端实测：一次调用干了什么
以课程里的“面试主线剧情”为场景，发一句话：
用户：那个最划算的帮我订了
系统走完的完整链路（节选自真实Trace）：
| 阶段 | Agent | 关键输出 |
|---|---|---|
| 意图 | intent | 那个→机票（指代消解），意图=book，置信度 0.92 |
| 规划 | plan | G4C 计划：检索→对比→下单 |
| 检索 | memory | RAG 命中《机票产品知识》片段 |
| 对比 | exec | 最划算排序：航司B(650) < 航司C(720) < 航司A(880) |
| 执行 | exec | 下单失败：missing param: destination（缺目的地） |
| 重规划 | plan | 根因回溯：失败点在执行层，但根因在输入层（缺参数） |
| 澄清 | gateway | 从用户画像补全destination=上海 |
| 重试 | exec | 下单成功，订单号ORD_xxx |
最终评估：总分 0.945（良好），自愈=成功，Replan 次数=1。
一次“缺参数”的失败，没有让系统在失败层傻重试，而是回溯到根因、补参数、重跑，这正是课程第二章 Replan 上下讲的核心。
4. 你能从这篇得到什么
- 一套可运行、可部署、可观测的多智能体代码（见仓库
agentkit/）。 - 一个能直接写进简历、经得起追问的项目叙事：不是“调大模型”，而是“意图识别→规划→执行→上下文/检索→评估反馈”全链路工程。
- 一组真实指标和失败自愈证据，面试时能甩数据。
下一篇讲意图识别的三层机制，我会贴出intent_agent.py的真实实现，以及它是怎么把“那个最划算的帮我订了”听懂的。
系列目录
- 总览：4 台 ECS 跑通可运行的多智能体系统
- 意图识别：三层机制（L1 归一 / L2 分类 / L3 澄清）
- 规划执行：G4C 计划与 Replan 根因回溯
- 上下文与检索：f(Context) 与零依赖 RAG
- 执行与评估：TAO 工具选择与评估反馈闭环
- 面试话术与简历：把项目讲专业
)
