从零搭建 AI Agent 调度中台（前言）：给 AI 一个 prompt 能生成多少代码？
一、我给 Cursor 写了一个 4000 字 prompt，拿到了 200+ Java 文件
2026 年春天的一个周六，我在 Cursor 里写了一份 4000 字的系统设计文档：技术栈、模块划分、接口规范、数据库 10 张表 DDL、编码规范——打包成一个完整的 prompt，丢给了 GPT-4o。
三小时后，AI 吐出了：
- 一个 Maven 父工程 + 8 个子模块 pom.xml（全部正确解析依赖版本）
- 200+ Java 文件（controller/service/impl/mapper/entity/dto/vo/feign/config 完整分层）
- 24 个 Vue 组件（前端 10 个页面 + VueFlow 工作流画布 + SSE 流式封装）
- 26 个 Python 文件（FastAPI 编排层 + A2A 协议层）
- 每个模块的 application.yml 配置、SQL 建表脚本、Docker Compose 中间件启动文件
我当时的反应和你一样：卧槽，这就能跑？
答案是：能跑 60%，剩下 40% 是半成品或者根本不能用。
这个系列要讲的，就是那剩下 40% 的故事——AI 生成的骨架到底哪里不行、怎么硬焊、哪些核心逻辑必须自己逐行写、以及最终怎么拼成一个能对外 demo 的企业级 AI Agent 调度中台。
二、AI 生成的骨架，哪些能用，哪些不能
先给你看一张表，这是我跑通整个项目之后的真实评估：
| 模块 | AI 生成质量 | 我做了什么 |
|---|---|---|
| 父 pom + 8 个子模块骨架 | ★★★★☆ | 版本号微调（Sentinel 从 1.8.6 升到 1.8.8、Milvus SDK 2.4.11） |
| 统一 Result 返回 + 全局异常 + 分页工具 | ★★★★★ | 几乎没改，直接用 |
| MyBatis-Plus 实体 + Mapper + CRUD Service | ★★★★☆ | TenantContext 自动注入逻辑需要自己补（AI 生成的是注释掉的占位） |
| Feign Client + Fallback | ★★★★☆ | Fallback 里返回 Result.fail() 改成抛 BusinessException |
| WorkflowEngine（DAG 执行器） | ★★☆☆☆ | 只有类定义和空方法体，Kahn 算法拓扑排序 + 8 种 NodeExecutor 全部自己写 |
| RagRecallService（RAG 多路融合） | ★★☆☆☆ | AI 只写了"调用向量库搜索"一行注释，归一化公式 + 加权融合 + chunkId 去重全部自己写 |
| Python orchestrator（Function Calling 深循环） | ★★★☆☆ | 主框架有了，但 max_delegate_depth 护栏和消息拼装循环逻辑需要补 |
| VueFlow 工作流画布（design.vue） | ★★★☆☆ | 组件注册和拖拽逻辑有了，执行轮询和状态高亮是我补的 |
| SSE fetch + ReadableStream 封装 | ★★★★☆ | 几乎没改，AI 写的比网上大多数示例都完整 |
| Docker Compose | ★★★☆☆ | Nacos 和 Milvus 的端口映射不对，改了两处 |
| Sentinel Gateway Adapter 配置 | ★☆☆☆☆ | AI 用了 SCA 2022 版本的 starter-gateway 注解，2023 版本已废弃，全部推翻重写 |
三个核心模块——DAG 引擎、RAG 融合、双栈跨语言编排——是 AI 根本写不出来的。 这不是 AI 能力不够，而是这三个模块需要工程化上下文：Kahn 拓扑排序怎么适配 AI Agent 的条件分支、Milvus 和 ES 的分数怎么归一化到同一个值域、Python 怎么回调 Java 的内部端点而不是走公开 API——这些决策需要知道"这个模块在整个系统里的位置"，而 AI 生成的代码是按文档逐条填的，不知道全局。
三、那为什么不直接用 Dify/Coze？
2026 年市面上至少 20 款 AI Agent 低代码平台，社区版免费、SaaS 版月费几十块。拖拖拽拽 5 分钟出效果。
但我在几个真实场景里发现了三个根本问题，这也是自研的唯一合理理由：
问题一：调度引擎是黑盒。 Dify 的 Agent 执行路径是框架内部硬编码的流程，你想在"LLM 回答之前"插一个"强制审核环节"？想在"工具调用失败之后"走"兜底重试+降级"？社区版没有扩展点，要改就得 fork 源码。而我们的自研 DAG 引擎，你看后面的章节会发现——加一个新节点类型，只需要继承 NodeExecutor 接口、在 NodeExecutorRegistry 里注册一行，10 行代码搞定。
问题二：RAG 召回是半成品。 Dify 有 RAG 模块，但只做了"向量召回"单路。生产上的真实问题：用户搜"2025 年房贷利率调整"，向量相似度最高的片段可能来自一篇讲"2023 年房贷"的文章（语义相近但年份错了），而关键词"2025"的 BM25 分数高的片段反而排在后面。单路召回覆盖不了这个场景。我们的自研 RAG 做了 Milvus + ES 双路召回、各自归一化、加权融合、chunkId 去重——这一套在 Dify 社区版里是没有的。
问题三：没有 A2A 协议层。 谷歌 2025 年推出的 Agent2Agent 协议（JSON-RPC 2.0 + SSE 事件流），让 Agent 之间可以互相发现和委派。Dify 支持"多 Agent"，但那是 Dify 内部的多 Agent，和外部平台（比如公司已有的 Python AI 服务）对接的时候，只能走 HTTP 硬编码调用。我们实现了完整的 A2A 协议层——AgentCard 发现、tasks/create/get/cancel、RedisEventQueue 异步状态存储。
选型决策表：
| 对比维度 | Dify/Coze 低代码平台 | 本系列自研平台 |
|---|---|---|
| 调度引擎 | 框架内部硬编码流程 | 自研 Kahn 拓扑排序 DAG 执行器（逐行讲解源码） |
| RAG 召回 | 单路向量 | Milvus 向量 + ES BM25 多路加权融合（有数学推导） |
| Agent 互操作 | 内部多 Agent | 完整 A2A 协议实现（JSON-RPC 2.0 + SSE） |
| 技术栈 | 单栈（Python/Node.js） | Java 业务底座 + Python AI 编排层双栈（跨语言架构设计） |
| 可扩展性 | 插件有限、源码难改 | 8 种 NodeExecutor 策略模式、Feign 远程调用、Sentinel 熔断降级 |
| 适用场景 | 快速 demo、轻量业务 | 企业私有化、合规场景、已有微服务体系 |
一句话总结：如果你的需求是"今天搭个 demo 明天给老板看"，用 Dify；如果你的需求是"私有化部署、全链路可控、和已有系统集成"，就得自研。
四、一条对话的旅程：全系列的骨架
把一次用户提问拆成 10 步，这条链路就是后面十几章的目录：
用户提问
│
▼
┌──────────────┐ ①鉴权+租户隔离 ┌──────────────┐
│ Gateway │ ─────────────── │ Sys-Auth │
│ 统一入口网关 │ │ Token校验 │
└──────┬───────┘ │ Tenant透传 │
│ └──────────────┘
│ ②加载Agent配置
▼
┌──────────────┐ ③Redis会话+滑动窗口 ┌──────────────┐
│ Agent-Core │ ─────────────────── │ Redis │
│ Agent调度器 │ │ 多轮对话历史 │
└──────┬───────┘ └──────────────┘
│ ④RAG前置召回
▼
┌──────────────┐ ┌──────────────┐
│ RAG-Knowledge│ ────────▶│ Milvus │ ← 向量召回
│ 多路融合 │ │ Elasticsearch│ ← BM25召回
└──────┬───────┘ └──────────────┘
│ ⑤拼装Prompt + RAG片段
▼
┌──────────────┐ ⑥SSE流式输出 ┌──────────────┐
│ Model-Gateway│ ─────────────▶│ 前端浏览器 │
│ 多模型路由 │ │ 打字机效果 │
└──────┬───────┘ └──────────────┘
│ ⑦LLM返回Function Calling
▼
┌──────────────┐ ⑧工具执行 ┌──────────────┐
│ Tool-Plugin │ ───────────▶│ HTTP/SQL │
│ 工具插件中心 │ │ 外部接口 │
└──────┬───────┘ └──────────────┘
│ ⑨工具结果回传LLM → 二次总结
▼
⑩最终回答存入会话 → 返回用户
如果用户用的是 DAG 工作流而不是单 Agent 对话，这条链路会被替换成：
前端 VueFlow 拖拽保存 DAG JSON
│
▼
WorkflowEngine（自研 Kahn 拓扑排序执行器）
│
├─ Start 节点 ──→ LLM 推理节点 ──→ RAG 召回节点 ──→ 条件分支节点
│ │
│ true ──┴── false
│ │ │
│ ▼ ▼
│ Tool 节点 Agent 节点
│ │ │
│ ▼ ▼
│ End 节点 ◀────┘
│
└─ 执行中节点状态实时推送前端高亮（轮询 API）
后面每一章，都是这条链路上的一环。 我们不复制 Dify 的实现，而是从"为什么这个环节要这么设计"出发，逐行拆解核心代码——让你不仅能用，还能在面试中对着代码讲出设计取舍。
五、技术栈全景：每一项都选得有理由
自研平台的技术栈比低代码平台重得多，但每一项都不是"选了就选了"。
后端（Java 业务底座 + Python AI 编排层）
| 层 | 组件 | 版本 | 选型理由 |
|---|---|---|---|
| 网关 | Spring Cloud Gateway | 4.x | Nacos 原生发现、Sentinel 熔断、鉴权前置 |
| 注册/配置 | Nacos | 2.3.x | 国内 Java 微服务事实标准、支持 namespace 隔离 |
| 限流/熔断 | Sentinel | 1.8.8 | 比 Resilience4j 对网关更友好、QPS 限流直接配规则 |
| ORM | MyBatis-Plus | 3.5.5 | 多租户拦截器 + 逻辑删除自动注入、比 JPA 灵活 |
| 数据库 | MySQL | 8.0 | 事务型数据（Agent 配置、会话、工作流定义） |
| 缓存 | Redis | 7.x | 会话存储 + Token 滑动窗口 + 分布式锁 |
| 向量库 | Milvus | 2.4 | 生产级向量存储、支持 HNSW/IVF_FLAT 多种索引 |
| 全文检索 | Elasticsearch | 8.x | BM25 关键词召回、和 Milvus 做 RAG 多路融合 |
| 文件存储 | MinIO | latest | 知识库文档（PDF/Word/TXT）私有化对象存储 |
| 异步队列 | RabbitMQ | 3.13 | 文档向量化异步任务、削峰填谷 |
| 定时任务 | XXL-Job | 2.4 | 过期会话清理、用量统计、向量重建 |
| Python 编排层 | FastAPI + LangGraph | 0.115+/0.2+ | Function Calling 深循环、多 Agent 图编排、A2A 协议 |
| 跨语言调用 | Feign + HTTP | — | Java→Python 走 Feign，Python→Java 走 HTTP 回调端点 |
为什么是 8 个微服务 + 1 个 Python 服务，而不是单体？
两个理由：一是部署隔离的需求——Agent-Core 和 RAG-Knowledge 在某些合规场景下需要分别部署在不同机房；二是AI 层用 Python 的灵活性——Function Calling 深循环、LangGraph 图编排这些 AI 原生能力，Python 比 Java 写起来自然得多。Java 做它擅长的（鉴权、CRUD、事务、微服务治理），Python 做它擅长的（LLM 交互、Agent 编排、A2A 协议），两边通过 Feign + HTTP 回调打通。这不是过度设计——你在 ch05 会看到，双栈之间只有 5 个公开端点和 5 个回调端点，边界清晰到一眼就能画出来。
前端
| 组件 | 版本 | 选型理由 |
|---|---|---|
| 框架 | Vue 3 + TypeScript | <script setup> 组合式 API、TS 类型安全 |
| 构建 | Vite 5 | 比 Webpack 快 10 倍、HMR 即时刷新 |
| UI | Element Plus | 政企后台风格、与国内企业用户习惯对齐 |
| 工作流画布 | @vue-flow/core + dagre | 比 AntV G6 更轻、自定义节点组件注册灵活 |
| 状态管理 | Pinia | Vue 3 官方推荐、比 Vuex 简洁 |
| 图表 | ECharts | 大盘统计调用量/Token 消耗趋势 |
| SSE | fetch + ReadableStream | 原生实现、支持携带鉴权头（EventSource 不支持自定义头） |
中间件依赖全景图
┌─────────────┐
│ Nacos 2.3 │ ← 注册中心 + 配置中心
└──────┬──────┘
│服务发现
┌──────────────┼──────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Gateway │ │ Python │ │ XXL-Job │
│ Spring │ │ FastAPI │ │ 定时调度 │
│ Cloud │ │ 编排层 │ └─────────────┘
└──────┬──────┘ └──────┬──────┘
│ │
│Feign/HTTP回调 │
▼ │
┌─────────────────────────────────┐
│ Java 业务底座（7 微服务） │
│ │
│ Sys-Auth Agent-Core Model-GW │
│ RAG-Knowledge Tool-Plugin │
│ Workflow Task-Job │
└────┬──────────┬──────────┬──────┘
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ MySQL 8 │ │ Redis 7 │ │ RabbitMQ │
└─────────┘ └─────────┘ └────┬────┘
│
┌────────┼────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ Milvus│ │ ES 8 │ │ MinIO │
└────────┘ └────────┘ └────────┘
六、全系列路线图（13 章）
| 章 | 标题 | 核心看点 |
|---|---|---|
| 00 | 给 AI 一个 prompt 能生成多少代码？ | （本章）AI 辅助开发的真实评估、自研理由、架构全景、数据流骨架 |
| 01 | 底座搭建：SpringCloud Alibaba + 8 个中间件串联 | Nacos namespace、Sentinel Gateway Adapter（AI 生成的废弃注解怎么改）、Feign 降级、Docker Compose 一键起 |
| 02 | Agent 对话主链路：从用户提问到 LLM 回答 | Redis 会话 + Token 滑动窗口裁剪 + Agent 配置加载 + Function Calling 闭环 |
| 03 | DAG 工作流引擎源码讲解（核心卖点一） | Kahn 算法拓扑排序 + 8 种 NodeExecutor 策略分发 + agent_router 动态路由。AI 只给了空壳，153 行 WorkflowEngine.java 逐行讲解 |
| 04 | RAG 多路召回融合数学推导（核心卖点二） | Milvus 向量 + ES BM25 → 归一化 → 加权融合 → chunkId 去重。AI 只给了注释，173 行 RagRecallService.java 逐行讲解 |
| 05 | Java + Python 双栈架构设计（核心卖点三） | 职责边界表、跨语言 Feign 调用、Python 回调 Java、A2A 协议双端实现。架构图+接口契约 |
| 06 | Function Calling 深循环：Python 编排层的不限轮次实现 | delegate_agent() 递归委派 + max_delegate_depth 护栏 + 消息拼装循环 |
| 07 | A2A 协议实现：JSON-RPC 2.0 + SSE 事件流 | AgentCard 发现、tasks/create/get/cancel、RedisEventQueue 异步状态存储 |
| 08 | 模型网关：多模型路由 + 限流熔断 + Token 统计 | OpenAI 兼容接口封装、Sentinel 熔断兜底、用量日志入库 |
| 09 | 工具插件：Function Calling 的 HTTP/SQL 执行器 | ToolMetaDTO + JSON Schema 入参、租户+Agent 白名单校验 |
| 10 | 前端 VueFlow 画布：拖拽 + 自动布局 + 执行高亮 | 自定义 FlowNode 注册、dagre 拓扑布局、执行轮询、SSE fetch+ReadableStream |
| 11 | 多租户隔离：TenantContext + 拦截器 + MyBatis-Plus 自动注入 | ThreadLocal、全局拦截器、SQL 自动拼接 tenant_id |
| 12 | 部署上线：Docker Compose 10 容器一键启动 | 混合镜像、启动顺序、健康检查、常见故障排查 |
| 13 | 面试总纲 30 题 | DAG 引擎 8 题、RAG 融合 5 题、双栈架构 4 题、Function Calling 3 题、A2A 协议 3 题、微服务治理 4 题、模型网关 3 题 |
七、读者画像与预期收获
这个系列写给谁？
- Java 后端开发者，想进军 AI 应用开发但不知道从哪里开始
- 技术负责人，需要判断"AI 平台自研 vs 采购"的决策依据
- 应届毕业生，想在简历上写一个"不是 2023 年淘汰项目"的简历项目
- 正在用 AI 辅助编程但发现生成代码"能跑但不好用"的开发者——AI 生成 vs 自己硬焊的边界，这个系列会给你一个清晰的答案
学完能带走什么？
- 三个能背三分钟的核心代码：WorkflowEngine.java（DAG 执行器）、RagRecallService.java（RAG 融合）、orchestrator.py（Function Calling 深循环）
- 一套能直接复用的微服务骨架：父 pom、统一 Result 返回、Feign 降级模板、TenantContext 自动注入
- 一篇面试项目描述：100 字版、300 字版、1000 字 deep-dive 版
- 一份技术选型清单：每个中间件的版本、为什么选它、常见坑
- 一个 AI 辅助开发的方法论：哪些模块 AI 能写好、哪些必须自己硬焊、怎么组织 prompt 让 AI 输出更像"人写的"
不能承诺什么？
- 不做 K8s 部署（用 Docker Compose 单机演示）
- 不做 Embedding 本地训练（调用第三方 API）
- 不做计费系统（只做 Token 用量记录）
- 不做前端低代码表单（VueFlow 只做工作流画布）
八、关于"复刻"的诚实说明
你可能已经注意到了——这个项目根目录里有一个文件名很直白的文档：《复刻亚信渊思 AAP 简易智能体调度平台全栈开发交付文档》，内容就是那份给 AI 的 4000 字 prompt。
所以准确的说法是：
这个项目是 AI 辅助生成骨架 + 人工硬焊核心模块的产物。 AI 帮我们跳过了"搭骨架、写 CRUD、配 yml"这些机械劳动（这部分约占总量的 60%），省下来的时间花在了三个 AI 写不出来的核心模块上：DAG 执行器、RAG 融合、双栈跨语言编排（这部分约占总量的 30%），剩下 10% 是各种细节修补（版本号调整、废弃注解替换、端口映射修正）。
市面上有两类技术教程：源码解读类（分析开源项目源码）和从零搭建类（全部自己写）。这个系列是第三类——AI 帮你搭好脚手架，你负责把承重结构焊死。这比"从零写"真实（符合你我今天的开发方式），也比"读源码"实用（你能拿走代码直接改）。
准备好了吗？下一章，我们从底座搭建开始：Nacos、Sentinel、Feign、RabbitMQ、MinIO、Milvus、ES、XXL-Job，8 个中间件 + 7 个微服务，Docker Compose 一键拉起——顺便把 AI 生成的 Sentinel 废弃注解改成 SCA 2023 版本的正确写法。