Hello 以后将定时更新Ai Agent脚手架项目的搭建

1.1 项目背景

随着大语言模型（LLM）的快速发展，以 AI Agent（智能体）为核心的应用架构正在成为新一代软件系统的主流形态。

相比传统“请求-响应”式系统，Agent具备以下能力：

• 自主决策（Autonomous Decision Making）

• 工具调用（Tool Usage）

• 多轮对话（Multi-turn Interaction）

• 持久记忆（Memory Persistence）

从工程视角来看，一个典型的 Agent 架构可以抽象为：

Agent = LLM + Tools + Memory + Planning

其中：

• LLM（大模型）：负责理解与生成

• Tools（工具）：扩展能力边界（如调用API、数据库、外部系统）

• Memory（记忆）：提供上下文与长期信息存储

• Planning（规划）：实现复杂任务的拆解与执行

---

然而，在实际企业级开发中，AI Agent 项目往往面临以下问题：

• ❌ 业务逻辑与模型调用强耦合

• ❌ Prompt、工具、记忆散落在各处

• ❌ 难以扩展多Agent协作

• ❌ 难以测试与维护

因此，我们需要一个工程化、可扩展、可维护的 Agent 架构体系。

👉 本项目的目标正是：

构建一个基于 DDD分层架构 的企业级 AI Agent 脚手架，帮助开发者快速搭建稳定、可演进的智能体系统。

项目整合了以下主流技术生态：

• Google Agent Development Kit（Google ADK）

• Spring AI

• Model Context Protocol

---

1.2 为什么选择DDD架构？

传统三层架构（Controller-Service-DAO）在早期项目中足够简单高效，但在 AI Agent 这类复杂业务 + 多模型协作系统中，会逐渐暴露出问题：

🚨 传统架构的问题

• 业务逻辑分散

  • Prompt 写在 Service

  • 工具调用写在 Controller

  • 状态管理写在 Redis / DB

• 模型耦合严重

  • 一旦更换 LLM（如 GPT → Claude），改动范围大

• 缺乏领域抽象

  • Agent 行为无法沉淀为“领域能力”

• 测试困难

  • 无法对 Agent 行为进行单元测试（只能跑全链路）

✅ DDD（领域驱动设计）的优势

引入 Domain-Driven Design 后，系统会发生本质变化：

1️⃣ 领域层成为核心

• Agent 被抽象为领域对象（Entity / Aggregate）

• Tool、Memory、Plan 变成领域能力

• Prompt 也可以建模为领域对象

👉 不再是“调用模型”，而是“驱动一个智能体完成任务”

---

2️⃣ 技术与业务解耦

• LLM / MCP / 向量数据库 → 都属于基础设施层

• Domain 层完全不依赖具体实现

👉 你可以随时：

• 换模型（OpenAI → Google → 本地模型）

• 换工具协议（MCP → 自定义工具）

• 换存储（Redis → 向量数据库）

---

3️⃣ 清晰边界，天然支持扩展

• 单 Agent → 多 Agent 协作

• 简单问答 → 复杂任务规划（Plan & Execute）

👉 架构本身就是为“复杂系统”设计的

---

4️⃣ 更强的可测试性

• Domain 层可纯单测（不依赖模型）

• Infrastructure 可 Mock

• Agent 行为可以被验证

---

1.3 技术选型

本项目围绕“Agent工程化”进行技术选型，重点关注 扩展性 + 标准化 + 生态成熟度。

技术	选型理由
Google Agent Development Kit	Google 官方 Agent 开发框架，支持复杂 Agent 编排
Spring AI	无缝集成 Spring Boot，统一 LLM 调用接口
Model Context Protocol	AI 工具调用标准协议，支持跨工具生态

---

👉 技术选型背后的核心思想

构建一个“可替换的AI基础设施层”

也就是说：

• LLM 可替换

• Tool 可插拔

• Memory 可扩展

• Agent 可组合

1.4 项目架构概览

本项目采用 DDD + 六层架构设计，整体结构如下：

┌───────────────┐
│   trigger     │  ← Controller / MQ / 定时任务
├───────────────┤
│      api      │  ← 接口定义（DTO / Facade）
├───────────────┤
│      app      │  ← 应用服务（编排用例）
├───────────────┤
│    domain     │  ← 核心领域（Agent / Tool / Memory）
├───────────────┤
│ infrastructure│  ← 技术实现（LLM / MCP / DB）
├───────────────┤
│     types     │  ← 通用类型（枚举 / VO / 常量）
└───────────────┘

🔹 各层职责详解

1️⃣ trigger（触发层）

• HTTP 请求（Controller）

• 消息队列（MQ）

• 定时任务（Scheduler）

👉 系统入口

2️⃣ api（接口层）

• DTO 定义

• Facade 接口

• 对外暴露能力

👉 隔离外部调用与内部实现

---

3️⃣ app（应用层）

• 编排业务流程（Use Case）

• 调用 Domain 层能力

• 不包含复杂业务逻辑

👉 “指挥官”，不干活

---

4️⃣ domain（领域层）⭐核心

• Agent 实体（Agent）

• 工具抽象（Tool）

• 记忆模型（Memory）

• 任务规划（Planner）

👉 系统的大脑

---

5️⃣ infrastructure（基础设施层）

• LLM 实现（OpenAI / Google）

• MCP 工具适配

• 数据存储（MySQL / Redis / 向量库）

👉 技术细节全部放这里

---

6️⃣ types（公共类型层）

• 枚举（Enum）

• 值对象（VO）

• 常量定义

👉 跨层共享，避免重复定义

---

🔚 小结

本项目的核心价值在于：

用 DDD 思想，重新组织 AI Agent 的工程结构

实现从：

• ❌ “调用模型写功能”

  到

• ✅ “构建可进化的智能体系统”