Spring AI 2.0实战：从零打造代码生成Agent完整指南

从聊天机器人到自主Agent：Spring AI 2.0的关键跃迁

Spring AI 2.0发布已有一段时间，围绕它的讨论也逐渐升温。据B站UP主徐树来的系列课程分享，2.0版本最核心的更新并非底层API的重构，而是完成了Agent基座的构建。

在1.0时代，Spring AI本质上只能扮演一个「增强版聊天机器人」的角色——它可以调用大模型、接入Tools工具、维护对话记忆，最终生成一个能对话的应用。但这距离真正意义上的Agent（智能体）还有明显差距。

所谓Agent，在AI领域特指具备自主决策能力的智能系统，区别于简单的问答机器人。一个完整的Agent需要具备四个核心能力：感知（接收环境信息）、规划（分解任务制定策略）、行动（调用工具执行操作）和反思（评估结果并调整策略）。这一概念最早可追溯到人工智能研究中的BDI（Belief-Desire-Intention）架构。BDI架构由澳大利亚人工智能研究者Michael Bratman在1987年提出，将智能体的心智状态建模为三个核心组件：信念（Belief，对世界状态的认知）、愿望（Desire，期望达成的目标集合）和意图（Intention，已承诺执行的计划）。这一架构在上世纪90年代被广泛应用于多智能体系统和仿真领域，但由于当时的知识表示和推理能力有限，BDI Agent只能在预定义的规则空间内运作。近年来，大语言模型的涌现带来了根本性的变革——LLM本身充当了Agent的「大脑」，其强大的自然语言理解和推理能力使得Agent不再依赖手工编写的规则库，而是具备了处理开放域、非结构化任务的泛化能力。这正是Agent在2023年之后重新成为工程实践热点的根本原因。

要在1.0时代实现自主规划、自主思考的Agent，开发者必须依赖阿里巴巴推出的开源框架 Spring AI Alibaba Agent Framework，它在Spring AI的基础上做了大量扩展，支持React Agent（推理-行动循环）以及基于Workflow的自主编排能力。React（Reasoning and Acting）是由普林斯顿大学和Google在2022年提出的Agent范式，其核心思想是让大模型在每一步都先进行推理（Thought），然后决定采取什么行动（Action），接着观察行动结果（Observation），再进入下一轮推理。这种交替循环的方式模拟了人类解决问题时的思考过程，比起一次性生成答案，React能显著提升复杂任务的完成质量和准确率。

值得一提的是，React并非唯一的Agent范式。与之对应的还有几种主流方案：Plan-then-Execute模式让模型先生成完整的任务计划再逐步执行，适合目标明确的结构化任务，但缺乏中途调整的灵活性；Reflexion模式在React基础上增加了自我反思环节，Agent在每轮循环后会评估自己的推理质量并生成改进建议，在编程和数学推理等需要高准确率的场景中表现更优；**LATS（Language Agent Tree Search）**则将蒙特卡洛树搜索引入Agent推理过程，通过探索多条推理路径来寻找最优解。React之所以成为最广泛采用的范式，在于它在实现复杂度和效果之间取得了较好的平衡。不过React在工程实践中也面临挑战：循环次数不可预知可能导致API调用成本失控，需要设置最大迭代次数限制；同时每轮循环都会增加上下文长度，可能触及模型的context window上限，需要引入上下文压缩或摘要机制。

而Spring AI 2.0的意义在于，官方原生框架本身就补齐了这块能力。如今它已经能够支持「自主思考 → 调用Tools → 执行行动 → 循环迭代」的完整闭环，直到任务完成。这标志着Spring AI从「大模型调用工具包」正式进化为「Agent开发框架」。

Agent Utils工具库：逆向Claude Code的低成本捷径

2.0真正的价值增量集中在Agent生态这一层。据课程介绍，Spring AI社区提供了一套 Agent Utils工具库，而这套工具库的一个突出特点是——它直接逆向了Claude Code（Anthropic官方的命令行代码助手）的设计思路。

Claude Code是Anthropic于2025年初推出的命令行AI编程助手，运行在终端环境中，能够直接读写本地文件系统、执行shell命令、搜索代码库并进行多步骤的代码修改。它的核心设计理念是让AI具备完整的开发环境操作能力，而非仅仅生成代码片段。Claude Code采用了工具调用+循环推理的架构，每一步都可以调用文件操作、搜索、执行命令等工具，并根据结果决定下一步动作，直到完成用户的编程任务。

在AI编程助手赛道中，Claude Code的定位与Cursor、GitHub Copilot有着本质区别。GitHub Copilot主要作为IDE内的代码补全工具，聚焦于行级和函数级的代码生成，交互模式是「补全」而非「对话」；Cursor则将AI深度集成到编辑器体验中，支持多文件编辑和对话式编程，但仍然以IDE为中心。Claude Code选择了一条更为激进的路线——完全运行在终端中，不依赖任何IDE，直接操作文件系统和命令行。这意味着它更接近一个真正的「AI开发者」而非「AI编辑器插件」。其工具集设计（文件读写、grep搜索、bash执行、git操作等）构成了一套完整的开发环境抽象层，这种设计思路的价值在于它定义了「AI编程Agent需要哪些原子能力」的范式标准。逆向这套工具集，本质上就是在复用Anthropic团队通过大量实验验证过的能力边界定义。

这意味着开发者不需要从零摸索Agent的工程范式，而是可以站在成熟产品的肩膀上，快速复用一套经过验证的代码生成助手架构。徐树来在课程中正是借助这套工具库来搭建一个类Claude Code的代码生成助手项目。

这种「逆向 + 封装」的思路对企业级开发很有启发：与其自己重新设计任务编排与工具调用的协议，不如借鉴业界标杆产品的交互模式，再用Spring生态的工程能力做二次封装。

从成本角度看，这样的开发路径极为高效——既能快速上手Spring AI 2.0，又能顺带掌握Agent Utils这套工具库的用法，一举两得。

项目实战的技术路线：由浅入深的完整链路

课程采用了循序渐进的教学结构，从大模型最基础的能力一路延伸到Agent的高级特性。整体技术路线可以拆解为以下几个层次：

基础对话层：ChatClient与模型接入

最底层依然是Spring AI 1.0就已成熟的能力，包括 ChatClient、ChatModel、各大模型接入、流式输出（Streaming） 等。流式输出是指大模型生成内容时不等全部生成完毕再返回，而是逐token（词元）实时推送给客户端。技术上通常基于Server-Sent Events（SSE）或WebSocket实现。SSE是一种基于HTTP的单向推送协议，服务端可以持续向客户端发送数据流，特别适合大模型的文本生成场景——因为生成过程天然是单向的（模型到用户），不需要WebSocket那样的双向通信能力。在Spring生态中，SSE可以通过Spring WebFlux的Flux<String>响应类型优雅地实现，与响应式编程模型天然契合。对于用户体验而言，流式输出可以将首字响应时间从数秒降至毫秒级；对于开发者而言，它还能实现更精细的中断控制和进度展示。在Agent场景中，流式输出尤为重要，因为Agent的推理过程往往较长，实时展示思考步骤能够显著提升用户信任感。

有意思的是，Spring AI 2.0中90%以上的内容与1.0并无本质变化，因此想深挖底层源码细节的开发者，完全可以参考此前1.0版本的系列课程。

记忆与工具层：从对话走向Agent的过渡

在对话基础之上，逐步加入 记忆（Memory）、Tools工具调用、MCP（Model Context Protocol） 等能力。

MCP是Anthropic于2024年底开源的一种标准化协议，旨在解决大模型与外部工具、数据源之间的连接问题。在MCP出现之前，每个AI应用都需要为每个外部服务编写独立的集成代码，导致大量重复工作。MCP采用客户端-服务器架构，定义了统一的通信格式，使得任何符合MCP协议的工具服务器都可以被任何MCP客户端（如AI应用）直接调用。这类似于USB协议之于硬件设备——一旦标准化，即可即插即用。

从技术实现层面来看，MCP基于JSON-RPC 2.0协议进行通信，支持两种传输方式：本地的stdio（标准输入输出）和远程的HTTP+SSE。MCP与大模型原生的Function Calling机制有着本质区别：Function Calling是模型厂商各自定义的工具调用接口，不同模型（OpenAI、Claude、Gemini）的Function Calling格式互不兼容，工具定义绑定在模型调用层；而MCP将工具定义和工具执行从模型层抽离出来，形成独立的服务层。这意味着同一个MCP工具服务器可以被任何模型调用，同一个AI应用也可以在不修改工具集成代码的情况下切换底层模型。在安全性方面，MCP引入了权限控制和沙箱执行的概念，工具服务器可以声明自己需要的权限范围，客户端可以在执行敏感操作（如文件删除、数据库写入）前要求用户确认。Spring AI 2.0对MCP的支持意味着开发者可以轻松接入社区已有的大量MCP工具服务器，包括文件系统访问、数据库查询、Web搜索、代码执行等各类能力，而无需为每个工具编写定制化的集成代码。截至2025年中，MCP社区已经涌现出数百个开源工具服务器，覆盖了从GitHub操作、Slack消息到PostgreSQL查询等常见开发场景。

这一层让应用具备了上下文感知和外部能力扩展的条件，是从对话走向Agent的过渡阶段。

Agent能力层：核心特性详解

这是整个课程的核心，围绕Spring AI Agent Utils展开，涵盖几个关键特性：

• Ask User Question：当提示词信息不足时，由大模型主动向用户提问以补全上下文。这是解决「用户指令模糊」痛点的关键机制。在传统的AI应用中，面对模糊指令，模型往往会基于猜测给出可能不准确的回答；而Ask User Question机制让Agent具备了「追问」能力，类似于一个有经验的开发者在接到需求时会先确认细节，而非盲目动手。这一机制的工程实现需要在Agent的推理循环中增加一种特殊的动作类型——暂停执行并向用户发起提问，收到回答后将新信息注入上下文继续推理。在具体实现上，这通常表现为一个特殊的Tool：当Agent判断信息不足时，调用ask_user工具，该工具的执行会阻塞Agent的推理循环，将问题呈现给用户，等待用户输入后将回答作为工具执行结果返回，Agent随即带着新信息继续后续推理。这种设计的精妙之处在于它将人机交互统一到了工具调用的框架中，不需要为交互式场景额外设计控制流。

• Skills技能模块化：让Agent具备可组合、可复用的能力单元，提升代码复用率。每个Skill可以理解为一个封装好的能力模块，包含特定的提示词模板、工具集合和执行逻辑，Agent在规划阶段可以根据任务需要动态组合不同的Skills。这种设计借鉴了软件工程中的单一职责原则和组合模式，使得Agent的能力可以像乐高积木一样灵活拼装，也便于团队分工开发和独立测试。举例来说，一个代码助手Agent可能包含「代码审查Skill」、「单元测试生成Skill」、「文档编写Skill」、「性能优化Skill」等多个能力单元，每个Skill内部封装了专属的系统提示词和工具集。当用户提出「帮我优化这个API的性能并补充文档」时，Agent的规划模块会自动选择并串联「性能优化Skill」和「文档编写Skill」。这种模块化设计也为Agent的能力市场奠定了基础——团队或社区可以发布和共享标准化的Skill包，类似于npm包之于JavaScript生态。

• 任务规划（Task Planning）：Agent自主拆解复杂任务，形成执行路径，实现多步骤自动化。例如用户说「帮我重构这个模块并写好单元测试」，Agent会自动拆解为：分析现有代码结构 → 识别重构点 → 执行重构 → 编写测试用例 → 运行测试验证，每一步的结果会影响下一步的决策。任务规划的质量直接决定了Agent处理复杂任务的上限，目前业界主流的实现方式包括让大模型一次性生成完整计划（Plan-then-Execute）和边执行边调整计划（Adaptive Planning）两种策略，各有优劣。Plan-then-Execute的优点是全局视野好、步骤间依赖关系清晰，但缺点是计划一旦生成就难以根据执行中的意外情况灵活调整；Adaptive Planning更具弹性，但可能导致局部最优而非全局最优的执行路径。在实际工程中，一种折中方案逐渐流行：先生成粗粒度的整体计划，然后在每一步执行时再做细粒度的微调，兼顾全局性和灵活性。Spring AI Agent Utils的任务规划模块正是采用了这种混合策略。

• 长期记忆（Long-term Memory）：跨会话保留信息，让助手真正「记住」项目上下文。长期记忆在工程实现上面临多重挑战：首先是信息筛选问题——不是所有对话内容都值得记住，需要模型或规则判断哪些是值得持久化的关键信息；其次是检索效率问题——当记忆量积累到一定规模后，如何在毫秒级时间内找到与当前任务相关的记忆片段，通常需要借助向量数据库和语义检索技术；第三是记忆更新问题——旧信息可能过时甚至矛盾，需要机制来处理记忆的覆盖和失效。

在向量数据库的具体应用中，每条记忆首先通过embedding模型（如OpenAI的text-embedding-3-small或开源的BGE系列模型）转化为高维向量表示，然后存储到向量数据库中。当Agent需要检索相关记忆时，将当前对话上下文同样转化为向量，通过近似最近邻（ANN）算法快速找到语义最相似的记忆片段。主流的ANN算法包括HNSW（Hierarchical Navigable Small World）和IVF（Inverted File Index），其中HNSW因为检索精度和速度的良好平衡而被广泛采用。在向量数据库选型上，Milvus适合大规模部署场景，支持分布式架构和亿级向量；Chroma以轻量级和易用性著称，适合原型开发；Pinecone则提供全托管的云服务，免去运维负担。Spring AI本身提供了对多种向量数据库的统一抽象接口（VectorStore），开发者可以在不修改业务代码的情况下切换底层存储引擎。

目前业界主流方案包括基于embedding的向量检索、基于知识图谱的结构化存储，以及两者的混合架构。在实际的代码助手场景中，长期记忆可以记住项目的技术栈偏好、代码风格规范、历史决策原因等信息，使得Agent的输出越来越贴合团队的实际需求。

对企业级AI开发的启示

这套实战课程的价值，不仅在于教会大家如何写一个代码生成助手，更在于它勾勒出了Java生态下企业级Agent开发的完整方法论。

对于长期深耕Spring技术栈的Java团队而言，Spring AI 2.0意味着无需切换到Python生态即可构建生产级Agent应用。在此之前，LangChain、LlamaIndex等主流AI应用开发框架几乎都以Python为主要语言，Java开发者要么被迫学习新语言栈，要么只能使用功能有限的早期Java封装。Spring AI 2.0的成熟让Java团队可以在熟悉的依赖注入、面向接口编程、声明式配置等Spring范式下构建AI应用，大幅降低了团队的技术切换成本。

从更深层的技术对比来看，Python生态在AI领域的优势主要体现在模型训练和研究原型阶段——PyTorch、TensorFlow等框架以Python为第一语言，数据科学社区的工具链（Jupyter、Pandas、NumPy）也以Python为核心。但在AI应用的生产部署阶段，Java的优势开始显现：强类型系统带来更好的代码可维护性和重构安全性；JVM的成熟垃圾回收机制和高并发处理能力使其更适合处理生产环境中的高负载场景；Java生态在编译期检查、依赖管理（Maven/Gradle）和API版本控制方面也更为严谨。对于拥有大量Java存量系统的企业（金融、电信、制造等行业），Spring AI 2.0让AI能力可以直接以微服务的形式集成到现有系统架构中，无需引入跨语言调用的复杂性（如gRPC桥接、REST API封装等中间层）。

更重要的是，Spring生态本身在企业级应用中积累了丰富的基础设施——安全认证（Spring Security）、微服务治理（Spring Cloud）、数据访问（Spring Data）、监控观测（Micrometer）等，这些能力可以与AI Agent无缝集成，构建出符合企业安全合规要求的生产级系统。例如，Agent的工具调用可以通过Spring Security的权限体系进行细粒度的访问控制，确保Agent只能调用其被授权的工具和数据源，防止越权操作带来的安全风险；Agent的推理日志可以通过Micrometer接入Prometheus/Grafana进行可观测性监控，实时追踪每次推理的token消耗、响应延迟、工具调用成功率等关键指标，为成本控制和性能优化提供数据支撑；Agent的记忆存储可以通过Spring Data接入企业已有的数据库基础设施，无论是关系型数据库（MySQL、PostgreSQL）还是NoSQL数据库（MongoDB、Redis），都可以通过Spring Data的Repository抽象统一接入。此外，Spring Cloud的服务发现和负载均衡能力使得Agent服务可以水平扩展，应对高并发场景下的弹性需求；配置中心（如Spring Cloud Config或Nacos）则可以动态管理Agent的模型参数、提示词模板和工具配置，实现不重启服务即可调整Agent行为的运维灵活性。

Ask User Question、任务规划、长期记忆这些特性，恰恰是企业实际落地时最容易踩坑的地方——如何处理用户输入不完整、如何编排多步骤任务、如何维护跨会话状态，都在这套框架中有了标准化的解决方案。

更重要的是「逆向Claude Code」这一思路本身。它提醒我们：AI应用开发正在从「造轮子」转向「复用最佳实践」。当业界已经存在Claude Code这样验证过的产品形态时，借鉴其架构、结合本地技术栈快速封装，往往是性价比最高的落地路径。这种方法论在软件工程中并不新鲜——早年的Web框架大量借鉴了Rails的设计理念，移动端框架也参考了iOS的交互范式——但在AI Agent领域，由于产品形态尚未完全固化，能够快速识别并复用标杆产品的架构模式，将成为工程团队的核心竞争力之一。

小结

Spring AI 2.0的核心跃迁在于原生支持了Agent能力，而Agent Utils工具库则通过逆向Claude Code提供了低成本的实战入口。对Java开发者来说，这是一个进入AI Agent开发领域的绝佳时机——既能复用熟悉的Spring工程范式，又能掌握任务规划、长期记忆等前沿Agent能力。随着框架生态的持续完善，Java在企业级AI应用中的话语权也有望进一步增强。