课程设计：面向产品运营的智能运营 Agent 工作台

课程定位

这是一套面向 Java 后端开发的 Spring AI Alibaba 深度实战课程。

它不按 API 名字平铺，也不把大模型能力讲成一堆概念。整套课只围绕一个真实业务目标推进：

产品运营输入一句自然语言需求，系统自动理解任务、查数据、查资料、生成方案、检查风险、等待确认、保存结果，并能复盘整个过程。

课程最终要训练的是工程能力：

• 能写出可运行的 JDK 17 + Spring Boot AI 后端工程。
• 能解释模型调用、Tool、MCP、RAG、Memory、Advisor、Skill、Agent、Graph 的职责边界。
• 能把教学 Demo 逐步升级成接近企业项目的工程结构。
• 能判断什么时候该简单写 ChatClient，什么时候必须上 Tool、MCP、Agent Team 或 Graph Core。

为什么现在要学

普通聊天机器人只能回答问题。

产品运营真正需要的是执行一组业务动作：

看数据
→ 找原因
→ 查历史资料
→ 生成活动方案
→ 生成文案
→ 检查风险
→ 等待确认
→ 保存方案
→ 创建执行任务
→ 复盘效果

如果只会接一个模型接口，系统很容易停留在“会聊天但不能办事”的阶段。

这套课程要解决的根问题是：

如何把大模型从文本生成能力，放进一个有权限、有工具、有知识库、有状态、有流程、有观测的后端业务系统里。

学习者当前差距

默认你已经会：

• Java 17。
• Spring Boot。
• Maven。
• REST API。
• MyBatis / MyBatis-Plus。
• MySQL。
• 企业后台系统常见分层。

当前主要差距不在 Spring Boot 基础，而在 AI 工程化：

• 不知道 ChatClient、Agent、Graph 的边界。
• 不知道 Tool Calling 为什么不能直接等于“让模型查库”。
• 不知道什么时候把本地 Tool 升级为 MCP Server。
• 不知道 RAG、Advisor、Memory 如何配合。
• 不知道 Skill 是业务能力包，不是普通 Prompt。
• 不知道多 Agent 协作时如何传递上下文、合并结果和处理失败。
• 不知道 Graph Core 如何做状态、人工确认、重试、恢复和观测。

学完后的能力

学完后，你应该能独立设计和实现一个后端版运营 Agent 工作台：

• 用 Spring AI Alibaba 接入模型对话。
• 把运营自然语言需求解析成结构化任务单。
• 通过安全 Tool 查询运营指标，而不是让模型拼 SQL。
• 把通用工具能力抽成 MCP Server。
• 用 RAG 检索历史活动、运营 SOP、风控规则和文案规范。
• 用 Advisor 做日志、权限、RAG、风控等横切增强。
• 用 Memory 支持运营多轮追问。
• 用 Skill 沉淀可复用运营能力包。
• 用 Agent Framework 组织 ReactAgent、SequentialAgent、ParallelAgent、RoutingAgent、LoopAgent 和 Supervisor Agent。
• 用多智能体团队协作完成复杂运营任务。
• 用 Graph Core 编排企业级可控流程。
• 为模型输出做日志、追踪、成本统计和效果评估。

课程主线

整套课程只围绕一个贯穿需求升级：

帮我分析最近 7 天新用户留存下降的原因，并给我一份下周拉活活动方案。

最开始，我们只判断普通 ChatBot 为什么不够。

然后逐步升级：

V0 普通 ChatBot：只能生成泛泛建议
V1 Spring AI 对话入口：能回答运营问题
V2 结构化任务单：能识别目标、指标、时间范围和输出格式
V3 Tool Calling：能安全查询后端指标
V4 MCP：工具能力可被多个 Agent 和系统复用
V5 RAG：能引用历史活动和运营 SOP
V6 Advisor + Memory：能增强上下文、权限、日志和风控
V7 Skill：沉淀运营分析、活动策划、文案、风控能力包
V8 Agent Framework：让不同执行模式的 Agent 接管任务
V9 Agent Team：多个专业 Agent 协同完成方案
V10 Graph Core：流程可控、可追踪、可恢复、可评估

贯穿业务案例

项目名称：

面向产品运营的智能运营 Agent 工作台

真实角色：

• 产品运营。
• 增长运营。
• 内容运营。
• 活动运营。
• 用户运营。

系统最终能力：

1. 理解运营意图。
2. 判断任务类型。
3. 查询产品指标。
4. 查询历史活动资料。
5. 查询用户反馈。
6. 检索运营 SOP 和风险规则。
7. 生成问题分析。
8. 生成活动方案。
9. 生成推送、弹窗、短信等文案。
10. 检查夸大宣传、敏感词和规则漏洞。
11. 等待运营人工确认。
12. 保存运营方案。
13. 创建后续执行任务。
14. 输出最终报告。
15. 记录执行过程。
16. 支持追问和复盘。

完整知识地图

必须掌握

• JDK 17 + Spring Boot 工程骨架。
• Spring AI Alibaba ChatClient。
• Prompt / Message / Options。
• Streaming。
• Structured Output。
• Tool Calling。
• Tool 参数、返回值、权限、脱敏和兜底。
• MCP Server / MCP Client。
• RAG、Embedding、VectorStore。
• Advisor 调用链。
• Chat Memory。
• Skill 业务能力包。
• ReactAgent、SequentialAgent、ParallelAgent、RoutingAgent、LoopAgent、Supervisor Agent。
• 多 Agent 上下文传递、结果合并、失败降级。
• Graph Core、StateGraph、Node、Edge、Conditional Edge、OverAllState。
• Human in the Loop。
• 状态持久化、失败重试、流程恢复。
• 可观测、成本统计、效果评估。

理解即可

• 多模型接入的差异。
• 不同向量库的选型口径。
• MCP 工具版本管理策略。
• Prompt 版本发布流程。
• 评估集构建方法。

源码深挖

源码只在能回答工程问题时进入，不逐行念。

计划深挖：

• ChatClient 调用链：请求如何进入模型客户端。
• Tool Calling：工具描述、参数绑定、调用结果如何回到模型。
• Advisor：增强链如何包裹模型调用。
• Memory：会话上下文如何读写。
• Agent Framework：Agent 执行循环、路由、并行和循环优化。
• Graph Core：状态图、节点执行、条件边、持久化和恢复。

暂不展开

• 前端工作台 UI。
• 真实飞书、企微、短信供应商接入。
• 多租户计费系统。
• 大规模在线评测平台。
• 多模型路由的复杂商业化策略。

这些不影响后端课程主线。

章节目录

第 1 章：为什么不是普通聊天机器人

• 本章解决的问题：普通 ChatBot 为什么不能完成复杂运营任务。
• 案例升级：从一句运营需求开始，识别 ChatBot 的能力边界。
• 核心知识：ChatBot 与 Agent 工作台的工程边界。
• 原理深度：只讲业务边界和后端分层，不进入模型源码。
• 学完产出：第 1 章业务认知接口。

第 2 章：运营对话入口，接入 Spring AI Alibaba

• 本章解决的问题：系统如何真正和模型对话。
• 案例升级：把第 1 章的固定判断升级为模型生成运营回复。
• 核心知识：ChatClient、ChatModel、System Prompt、User Prompt。
• 原理深度：看清 Controller → Service → ChatClient → 模型的调用链。
• 学完产出：运营对话接口。

第 3 章：把运营需求解析成任务单

• 本章解决的问题：自然语言太松散，后端无法稳定执行。
• 案例升级：把“分析留存下降并生成方案”解析成目标、指标、时间范围、输出格式。
• 核心知识：Prompt、Message、Options、Structured Output。
• 原理深度：结构化输出为什么比纯文本更适合后端编排。
• 学完产出：运营任务单接口。

第 4 章：为什么不能让模型直接查数据库

• 本章解决的问题：模型拼 SQL 的安全风险和工程风险。
• 案例升级：运营需要查留存率，但模型不能直接碰数据库。
• 核心知识：安全边界、权限、参数白名单、数据脱敏。
• 原理深度：模型输出与后端可信执行之间的边界。
• 学完产出：受控查询设计说明和模拟数据接口。

第 5 章：第一个运营数据 Tool

• 本章解决的问题：Agent 如何安全调用 Java 后端能力。
• 案例升级：用 Tool 查询最近 7 天留存、激活率和渠道数据。
• 核心知识：Tool Calling、Tool 参数、Tool 返回值。
• 原理深度：模型如何选择工具，工具结果如何回到模型上下文。
• 学完产出：运营指标查询 Tool。

第 6 章：Tool 参数、返回值、权限与兜底

• 本章解决的问题：Tool 能跑不等于能进真实项目。
• 案例升级：增加时间范围、渠道、用户分群、权限校验和失败兜底。
• 核心知识：参数校验、返回 DTO、脱敏、错误处理。
• 原理深度：工具契约如何影响模型稳定性。
• 学完产出：工程可用版运营数据 Tool。

第 7 章：从 Tool 升级到 MCP

• 本章解决的问题：本地 Tool 只能服务一个应用，复用能力不足。
• 案例升级：运营数据查询能力要给多个 Agent 和系统复用。
• 核心知识：MCP 与 Tool 的区别、MCP Server 边界。
• 原理深度：工具服务化与协议化的价值。
• 学完产出：MCP 设计方案。

第 8 章：运营数据 MCP Server

• 本章解决的问题：如何让 Spring AI Alibaba 调用远程工具服务。
• 案例升级：把留存、转化、活动数据查询封装为 MCP 工具。
• 核心知识：MCP Server、MCP Client、鉴权、超时、错误处理。
• 原理深度：远程工具调用的失败路径和版本管理。
• 学完产出：operation-data-mcp-server。

第 9 章：为什么运营 Agent 需要 RAG

• 本章解决的问题：模型不知道公司历史活动和内部 SOP。
• 案例升级：活动方案必须参考历史活动和运营规范。
• 核心知识：文档解析、分片、Embedding、VectorStore、RAG。
• 原理深度：检索增强与模型生成的边界。
• 学完产出：运营知识库设计。

第 10 章：历史活动知识库最小闭环

• 本章解决的问题：如何让 Agent 查到真实资料再回答。
• 案例升级：检索历史拉活活动，辅助生成新方案。
• 核心知识：上传、解析、入库、检索、引用。
• 原理深度：相似度检索为什么可能查错，如何控制。
• 学完产出：历史活动参考助手。

第 11 章：RAG 引用与幻觉控制

• 本章解决的问题：运营报告必须知道依据来自哪里。
• 案例升级：报告中标出历史活动和 SOP 引用。
• 核心知识：引用片段、来源追踪、置信度、拒答策略。
• 原理深度：哪些结论来自资料，哪些是模型推断。
• 学完产出：带引用的运营分析报告。

第 12 章：Advisor 把日志、权限、RAG 串起来

• 本章解决的问题：把增强逻辑都写在 Service 会越来越乱。
• 案例升级：给模型调用统一加日志、权限、RAG 上下文和风控检查。
• 核心知识：Advisor 调用链。
• 原理深度：横切增强如何包裹模型调用。
• 学完产出：运营 Agent Advisor 链。

第 13 章：Memory 让运营能连续追问

• 本章解决的问题：运营会追问“那按渠道拆一下呢”。
• 案例升级：保留同一会话的指标、原因和方案上下文。
• 核心知识：Chat Memory、多轮上下文、会话 ID。
• 原理深度：记忆不是无限追加，需要压缩和边界。
• 学完产出：可追问运营分析助手。

第 14 章：Prompt 版本化与上下文压缩

• 本章解决的问题：Prompt 改动不可追踪，上下文越来越长。
• 案例升级：运营分析 Prompt、活动策划 Prompt、风控 Prompt 分版本管理。
• 核心知识：Prompt 模板、版本号、灰度、上下文压缩。
• 原理深度：上下文长度、成本和稳定性的权衡。
• 学完产出：Prompt 版本管理方案。

第 15 章：为什么需要 Skill

• 本章解决的问题：Prompt、Tool、RAG 分散，难以复用成业务能力。
• 案例升级：把“运营数据分析”沉淀成能力包。
• 核心知识：Skill 与 Prompt、Tool、MCP、Agent 的区别。
• 原理深度：Skill 是业务能力组合，不是单个函数。
• 学完产出：Skill 目录规范。

第 16 章：运营数据分析 Skill

• 本章解决的问题：多个 Agent 都需要稳定的数据分析套路。
• 案例升级：沉淀指标解释、异常归因、建议输出模板。
• 核心知识：Skill 绑定 Tool / MCP / RAG。
• 原理深度：Skill 如何控制输入、步骤和输出质量。
• 学完产出：运营数据分析 Skill。

第 17 章：活动策划与文案 Skill

• 本章解决的问题：活动方案和文案需要可复用规范。
• 案例升级：生成活动方案、推送文案、弹窗文案并做风险提示。
• 核心知识：活动策划 Skill、文案 Skill、风险规则。
• 原理深度：生成类任务如何约束风格、边界和合规。
• 学完产出：活动策划与文案能力包。

第 18 章：从 ChatClient 升级到 ReactAgent

• 本章解决的问题：单次模型调用无法持续观察、思考、行动。
• 案例升级：让 Agent 自己决定是否查数据、查资料、生成方案。
• 核心知识：ReactAgent、工具选择、执行循环。
• 原理深度：Agent 执行循环与普通 ChatClient 的差异。
• 学完产出：活动策划 ReactAgent。

第 19 章：SequentialAgent 与 ParallelAgent

• 本章解决的问题：有些任务必须串行，有些可以并行。
• 案例升级：先查数据再生成方案，同时并行查反馈和竞品。
• 核心知识：SequentialAgent、ParallelAgent。
• 原理深度：并行不等于一定更快，要看依赖和资源。
• 学完产出：串并行运营分析流程。

第 20 章：RoutingAgent 与 LoopAgent

• 本章解决的问题：不同运营需求要走不同路径，文案还要反复优化。
• 案例升级：数据分析、活动策划、文案生成、复盘报告自动分派。
• 核心知识：RoutingAgent、LoopAgent。
• 原理深度：路由判断和循环退出条件。
• 学完产出：运营任务路由和文案优化 Agent。

第 21 章：SupervisorAgent 调度子 Agent

• 本章解决的问题：复杂任务需要一个主管统一拆解和汇总。
• 案例升级：主管 Agent 调度数据、反馈、策划、文案、风控子 Agent。
• 核心知识：Supervisor Agent。
• 原理深度：任务拆解、上下文裁剪、结果聚合。
• 学完产出：运营 Supervisor Agent。

第 22 章：设计产品运营 Agent Team

• 本章解决的问题：一个 Agent 做所有事情会失控。
• 案例升级：明确需求理解、数据分析、用户反馈、竞品、策划、文案、风控、复盘 Agent。
• 核心知识：多 Agent 角色边界。
• 原理深度：角色划分如何影响输出质量和排错。
• 学完产出：运营 Agent Team 设计。

第 23 章：Agent as Tool 与 Agent Handoff

• 本章解决的问题：Agent 之间如何调用和交接任务。
• 案例升级：策划 Agent 调用文案 Agent，风控 Agent 接手审核。
• 核心知识：Agent as Tool、Agent Handoff。
• 原理深度：调用关系、交接上下文、责任边界。
• 学完产出：Agent 协作接口。

第 24 章：多 Agent 输出合并与失败降级

• 本章解决的问题：多个 Agent 结果可能冲突，也可能失败。
• 案例升级：合并数据分析、反馈分析、竞品分析，生成统一方案。
• 核心知识：结果合并、冲突处理、失败降级。
• 原理深度：部分失败时如何保证主流程可用。
• 学完产出：端到端运营活动方案生成团队。

第 25 章：为什么复杂 Agent 必须上 Graph Core

• 本章解决的问题：Agent Team 能跑，但流程不可控、不可恢复。
• 案例升级：运营方案生成需要节点、边、条件、人工确认、状态。
• 核心知识：Graph Core 的工程价值。
• 原理深度：Graph 与普通 Agent 编排的边界。
• 学完产出：Graph Core 改造设计。

第 26 章：StateGraph、Node、Edge、OverAllState

• 本章解决的问题：如何把复杂流程显式建模。
• 案例升级：把需求理解、数据分析、RAG、策划、文案、风控拆成节点。
• 核心知识：StateGraph、Node、Edge、OverAllState。
• 原理深度：状态如何在节点之间流动。
• 学完产出：运营活动生成 StateGraph。

第 27 章：Conditional Edge、并行节点与人工确认

• 本章解决的问题：流程不是一条直线。
• 案例升级：不同任务走不同分支，数据、反馈、竞品并行，保存前人工确认。
• 核心知识：Conditional Edge、并行、聚合、Human in the Loop。
• 原理深度：条件分支和并行结果聚合。
• 学完产出：可分支、可并行、可确认的工作流。

第 28 章：状态持久化、失败重试与流程恢复

• 本章解决的问题：长流程不能因为一次失败全部重来。
• 案例升级：节点失败后重试，中断后从状态恢复。
• 核心知识：状态持久化、重试、恢复、幂等。
• 原理深度：哪些状态必须保存，哪些动作必须幂等。
• 学完产出：可恢复运营工作流。

第 29 章：可观测、成本统计与效果评估

• 本章解决的问题：真实项目必须知道花了多少钱、哪里慢、效果好不好。
• 案例升级：记录模型调用、Tool 调用、MCP 调用、节点耗时和输出评分。
• 核心知识：日志、指标、链路追踪、成本统计、评估集。
• 原理深度：评估模型输出不能只靠主观感觉。
• 学完产出：运营 Agent 可观测与评估模块。

第 30 章：最终项目复盘与企业落地清单

• 本章解决的问题：如何从课程工程迁移到公司项目。
• 案例升级：整理部署、权限、安全、版本、监控、评估和迭代机制。
• 核心知识：工程边界、上线清单、后续演进。
• 原理深度：教学 Demo、工程可用版、生产级版本的差距。
• 学完产出：企业落地检查清单。

重点与取舍

重点：

• 业务问题如何驱动技术引入。
• 每章只引入一个核心能力。
• 每个可运行章节都有真实命令、请求和预期输出。
• 每次升级都说明旧方案为什么不够。
• 所有 AI 能力都回到 Java 后端工程边界。

非重点：

• 不做前端 UI。
• 不做大量模型横评。
• 不做复杂云部署。
• 不把所有向量库和所有模型供应商都讲一遍。

代码演进策略

代码统一放在仓库根目录 example：

example/
  stage-01-operation-agent-workbench/
  stage-02-spring-ai-basic/
  stage-03-tool-calling/
  stage-04-mcp/
  stage-05-rag/
  stage-06-memory-advisor/
  stage-07-skill/
  stage-08-agent-framework/
  stage-09-agent-team/
  stage-10-graph-core/

原则：

• 当前阶段只实现当前章节需要的能力。
• 不提前写后续章节代码。
• 每个阶段都要能 mvn.cmd test。
• 涉及 HTTP 接口时给出真实请求。
• 涉及模型、数据库、向量库、MCP 时，先给可运行模拟版，再升级为真实依赖。

学习与验收方式

每章至少回答：

• 这章解决了什么运营问题？
• 上一版方案哪里撑不住？
• 本章引入哪个新能力？
• 代码怎么运行？
• 运行现象证明了什么？
• 真实项目还差哪些工程边界？
• 下一章为什么自然出现？

验收标准：

• 能运行本章 example。
• 能说清楚调用链。
• 能指出至少 3 个常见坑。
• 能解释教学 Demo 和生产方案的差距。
• 能完成本章练习。

第一章设计

第一章定位为课程开篇，不接模型。

它只回答一个问题：

为什么产品运营需要 Agent 工作台，而不是普通 ChatBot？

第一章已经具备最小代码：

POST /api/chapter-01/evaluate

它不会调用模型，而是用固定结构化响应展示：

• 普通 ChatBot 的限制。
• Agent 工作台需要补齐的能力。
• 下一章为什么要接入 Spring AI Alibaba。

这样设计是为了先建立边界：

• 模型不是业务系统。
• 文本生成不是任务执行。
• Agent 工作台需要后端能力、状态、流程和治理。