Mr pretty开头想从自己的一段真实经历说起。去年年底我接了一个内部的智能客服升级项目，团队全是Java背景，领导给的需求就一句话："把大模型接进来，让它自己会干活。"一开始大家都觉得简单，无非是调API、拼Prompt。结果真正做下去才发现，从"调用大模型"到"构建一个有记忆、会调工具、能自主决策的Agent"，中间隔着一条很深的沟。网上现成的资料大多围绕LangChain和Python，Java生态里能看的实战内容少得可怜。后来我们选型落到了Spring AI Alibaba上，一路踩坑一路填坑，总算把系统跑稳了。这篇就把我自己的选型思考、核心概念拆解、代码落地过程和线上踩过的坑完整写出来，给同样在Java技术栈里做Agent开发的同学一条相对顺畅的路。这篇文章适合两类人看：一类是即将在Spring Boot项目里接入大模型能力的Java工程师，另一类是已经了解Agent概念、但想要一套可落地的工程化参考的架构师。不会堆砌概念，每一步都对应真实项目中会遇到的问题。
1. 为什么最终选了Spring AI Alibaba：选型背后的预算、团队与生态账
先聊一个最实际的问题，Java团队做Agent开发，摆在面前的路大概有四条：直接用HTTP调各家大模型API自研封装；用LangChain4j；用Spring官方社区孵化的Spring AI；用Spring AI Alibaba。我每个都试过，简单说说真实感受。
直接用HTTP调API最灵活，但代价是你要自己维护对话上下文、工具调用协议、流式输出解析、多轮记忆这些底层逻辑。这些工作量大不说，而且跟业务没半点关系，属于典型的重复造轮子。做两个Agent可能还行，做十个八个，光接口解析就得把人写吐。
LangChain4j是把LangChain的设计思路搬到了Java，功能挺全，但问题在于它跟Spring生态的整合是"后补"的。你在Spring Boot项目里用它，会感觉它是外来户——虽然也有Spring Boot Starter，但自动配置、配置项管理、跟Spring Cloud体系的协同总觉得隔了一层。我们团队当时还有上游系统要用Spring Cloud Alibaba，两套体系的组件放在一起，想想就头疼。
Spring AI官方项目胜在正统，是Spring官方把LLM能力纳入Spring生态的大动作。它定义了统一的ChatClient、ChatModel这些高层抽象，Future-proof做得好。但早期版本它主推OpenAI，国内模型接入要自己写Adapter，DashScope的适配也是后来社区贡献的，总有点水土不服。
最后说Spring AI Alibaba，这是阿里巴巴在Spring AI基础上做的增强实现。它对我来说最大的价值有三个：第一，原生支持阿里云百炼上面的通义系列模型，这是国内最容易拿到的合规模型渠道，发票、审计、私有化部署都好谈；第二，它延续了Spring Boot的"自动配置+Starter"哲学，加依赖、填Key、注入Bean三步走，几乎没有学习成本；第三，它不只是适配了模型，还把整个Agent开发需要的周边能力，比如Prompt模板管理、对话记忆、工具调用、多Agent编排这些，在Spring AI的标准架构里做了具体落地。团队本来就熟Spring那一套，上手的心理负担小很多。
从成本角度算一笔账更好理解。假设团队有5个Java工程师，用LangChain4j或者自研方案，光熟悉框架和补概念就得花一周，之后写业务的时候还要时不时处理框架本身的坑。用Spring AI Alibaba，对Spring老手来说，第一天就能把对话跑通，第二周就能上工具调用。这个时间差在项目排期上很要命。我的建议是，Java团队做Agent，除非你的场景极度特殊需要完全掌控协议层，否则直接从Spring AI Alibaba起步基本不会错。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Agent不是"调一次大模型"：LLM、Agent、Skill、Harness这几个概念必须拎清
做完选型再来扣概念。网上关于Agent的讨论很热闹，但"Agent是什么"在不同人嘴里完全是不同的东西。我面试候选人的时候经常问一个问题：你说你在做大模型开发，那调用一次聊天接口算不算Agent？很多人的回答是模糊的。这里我把自己用的判断标准写清楚。
2.1 LLM是大脑，Agent是长了手脚的大脑
大语言模型本身只做一件事：根据输入的文本预测下一个Token。它没有手，不能帮你查数据库；它没有脚，不能替你去调用外部系统；它甚至没有真正的记忆，每次对话对它来说都是全新的。LLM就像一个知识渊博但被关在房间里的专家，你说什么他都能聊，但他什么都做不了。
Agent则是在LLM外面套了一层"行动力"。一个标准的Agent系统，至少包含这么几个部分：模型作为决策核心，能力是指知道该做什么、该用什么顺序做；工具集作为手脚，能力是执行具体动作；记忆作为工作台账，能力是记住讲过的话和做过的决定；规划器作为任务拆解中枢，能力是把一个复杂目标拆成多步可执行的子任务。所以判断标准很简单：你的系统如果只是"提问-回答"的闭环，那是聊天机器人；如果系统能在某个目标驱动下，自主决定调用哪些工具、以什么顺序执行、根据中间结果调整策略，那才是Agent。这个概念差异是所有后续开发的地基。
2.2 Skill和Agent的关系：不是谁包含谁，而是能力与角色的区别
很多新手上来就问："Skill和Agent到底有什么区别？"我用一句话解释：Skill是"会做什么事"，Agent是"在什么角色下决定做哪些事"。
Skill本质上是把工具调用、Prompt模板、执行逻辑打包成一个可复用的能力单元。比如"日历管理Skill"包含了创建日程、查询空闲时间、删除日程这几个工具以及一套怎么调用它们的指令。Agent则是持有这些Skill的执行主体。一个"行政助手Agent"可以同时挂载日历Skill、邮件Skill、报销Skill，它根据用户意图判断当前该激活哪个Skill。
两者最本质的区别在于：Skill是被动的、静态的，它定义能力边界；Agent是主动的、动态的，它决定能力的使用时机。做工程的时候这个区分很重要——Skill要做到高内聚，可以被不同Agent复用；Agent则聚焦于角色定义和决策逻辑，不跟具体实现纠缠。一个Skill被多个Agent共用，是很正常的架构，这在后面的多Agent编排章节还会展开。
2.3 Harness这个词，其实是理解Agent架构的一把钥匙
热搜词里"harness和agent区别"被频繁检索，说明很多人也卡在这里。Harness本意是"马具"或者"背带"，在Agent开发语境里，我倾向于把它理解为"Agent运行的框架与外壳"。它是一个偏底层的概念，指的是承载Agent运行的那套基础设施——模型调用的封装、工具执行的安全沙箱、上下文管理的管线、观测与日志的埋点。你可以这么理解：Agent是你看到的"人"，Harness是这个人身上穿的"外骨骼"，决定了这个人能跑多快、能扛多重、在什么环境下能干活。
实际开发中，"自己写Agent逻辑"和"用Harness跑Agent"的边界，是很多人踩坑的地方。如果你的Agent要处理动态工具调用、多轮规划、错误恢复，那几乎肯定需要一个Harness层面的设计。Spring AI Alibaba提供的Ag