前面几篇，我们分别讲了 LLM 应用场景的三项能力拓展：工具调用、思考规划、记忆体系。
这三项能力不是拍脑袋定的，它们对应着 Lilian Weng（OpenAI 前研究与安全副总裁）那篇著名博文《LLM Powered Autonomous Agents》里的经典论断——在一个以大语言模型驱动的自主智能体系统中，LLM 充当系统的大脑，然后辅以三个关键组件：Planning（规划与决策）、Memory（记忆体系）以及 Tool use（工具调用）。
如今 Agent 生态已经非常成熟，这三项能力基本都被各类 Agent 框架封装实现，不需要应用侧从零自研。于是问题就变成了：框架这么多，到底该怎么选？
要回答这个问题，得先有个分类维度。最直观的一个是部署位置——按这个维度，现代 Agent 可以分成两大阵营：
- 服务端 Agent（如 LangGraph、CrewAI）：运行在远程云端服务器或容器中；
- 客户端 Agent（如 WorkBuddy、Claude Code）：运行在用户本地电脑上。
两者在交互模式和安全隔离上差别很大。这一篇先聊服务端 Agent，下一篇再讲客户端 Agent。
01 应用工程内嵌运行模式
假设业务应用的技术栈是 Java，而业务对 Agent 能力的使用又不太复杂，那最省事的做法是：直接在 Spring Boot 项目里引入Spring AI或LangChain4j依赖——这两个框架都兼容 Java 开发风格。
引入之后，Agent 的三大能力是怎么落地的？
工具调用：通过注解的方式，把 Java 项目中的某个方法注册为 Agent 的「工具」。框架会自动把这个方法的参数描述提取出来发给大模型；当大模型判断需要用这个工具时，框架会自动在本地反射执行这个 Java 方法，并把结果送回大模型。
记忆能力：通过拦截器在每次对话前后自动读取和保存历史记录。短期记忆用内存保存，或接入 Redis、JDBC 等实现持久化存储；长期记忆则用框架内置的 RAG 向量存储与检索组件，把用户的长期偏好或企业文档转化为向量，作为 Agent 的长期记忆。
规划决策：本质上依赖两种机制——模型自身的推理能力（如 Chain-of-Thought / ReAct 提示词范式）与框架的循环调度 / 状态机驱动。
依赖大致长这样：
<dependency><groupId>org.springframework.ai</groupId><artifactId>spring-ai-openai-spring-boot-starter</artifactId><version>1.0.0-M5</version></dependency>这种模式的优势很明确：
- 技术栈统一：整个项目都是 Java 开发的，不需要额外兼容 Python 运行环境；
- 上手成本低：内嵌运行模式对开发人员来说更贴近原本的开发风格，熟悉度更高。
02 独立 Agent 服务模式
第二种做法，是把 Agent 框架作为独立的微服务部署在单独的服务器 / 容器中，业务系统（如 Java / Spring 业务后端）通过 HTTP / gRPC / WebSocket 接口来调用它：
[用户端] ▼ [Spring Boot 业务主服务] ▼ [Agent 独立服务] ▼ [API 网关] ▼ [推理引擎服务]这种架构主要用于在后端构建可预测、可控制、高可靠的复杂 Agent 业务流程。落到具体框架，目前比较常见的有四个。
LangChain：把 Agent 能力做成基础组件
最早的是LangChain，目标是标准化大模型应用开发。它采用的是单向流动的链式结构（Chain），非常适合顺序明确的任务，比如输入 → 检索文档 → 总结回答。
但问题也出在这儿：有些 Agent 任务的逻辑是非线性的，需要循环、分支以及断点续跑的能力，单向链就有点力不从心了。
适用场景：简单的 RAG、单次流水线任务。
LangGraph：把流程抽象成有向有环图
后来 LangChain 官方推出了现在最火的LangGraph。它放弃了简单的单向链，把流程抽象为有向有环图（Stateful Graph），并引入三大核心能力：
- 支持循环（Loops）：可以表达「思考 - 行动 - 评估 - 重试」这类迭代逻辑；
- 全局状态（State）：跨节点共享状态对象，用于支撑判断逻辑和分支执行；
- 断点与人工干预（Human-in-the-loop）：可以在图的任意节点暂停，把中间状态持久化到数据库，等待人类审批或补充输入之后再继续运行。
适用场景：企业级复杂 Agent、带人工审批的场景。
CrewAI：把自动化流程包装成一支团队
Crew 原本指的是船务、机务这类有明确角色分工的组织。CrewAI 的设计理念正是模拟人类团队分工：给每个 Agent 固定的角色、目标和背景故事，分配任务，让它们自动协作完成目标——相当于把复杂的自动化流程，包装成一支 AI 岗位分工清晰的团队，各司其职。
适用场景：内容创作团队（研究员 → 撰稿人 → 审稿人）、市场调研、数据分析等有清晰岗位分工和交付文档的业务流程。
AutoGen：更像一个「学术研讨组」
AutoGen 和 CrewAI 一样专注「多智能体（Multi-Agent）」协作，但设计理念完全不同。CrewAI 是岗位明确、流程明确；AutoGen 更像一个学术研讨组——基于 Agent 之间的对话、讨论、辩论，以及在沙箱中写代码跑测试，来共同解决开放性的难题。
适用场景：解决开放式难题，涉及大量编写与真实运行代码 / 数据分析的任务。
03 为什么更多企业选独立部署？
同样是「跑在服务端」，为什么不少企业愿意多花成本，把 Agent 拆成独立服务？主要有五条理由。
1. 技术解耦
独立部署服务通过接口调用的方式暴露能力，不需要考虑与应用服务的技术栈兼容问题。而且现实里，写业务流程的和写 Agent 流程调优的往往是不同的工程师，独立部署能让这两拨人更好地并行开展工作。
2. 生态红利
AI 开源生态以 Python 为主——一些前沿的 AI 能力开源库基本都是 Python 首发、迭代也最快，Java 生态同步过来会存在明显的「时间差」。
3. 资源隔离
Agent 任务经常包含多次 LLM 推理、工具调用以及本地文档解析处理，响应时间长且存在密集型计算开销。内嵌运行的模式很容易影响到 Java 主业务服务的正常运行；独立部署就没有这个风险，而且可以根据业务服务与 Agent 服务各自的特性单独做资源扩容。
4. 安全隔离
如果 Agent 需要具备「执行代码」或「操控浏览器爬取网页」的能力，独立 Agent 服务可以在 Python 侧非常方便地挂载 Docker 沙箱；而在 Java 进程里，很难在 JVM 内部安全地隔离出一个代码执行环境。
5. 系统共享
把 Agent 建设为独立服务之后，不只当前业务应用可以通过接口调用它，公司其他应用也可以复用同一个 Agent 服务接口，避免在各个系统里重复编写相同的 Prompt 和 Agent 流程。
04 Agent 智能体平台模式
第三种形态是平台化。这类框架（如 Dify、Coze）通常自带 Web 前端图形化界面，支持拖拽编排工具与工作流，并能一键暴露 REST API 给业务系统。
它们内置了非常强大的Workflow（工作流）编辑器，把 Prompt、RAG、Agent 节点可视化连接起来，还支持多租户和 Prompt 版本管理。上手门槛极低，更适合提供给非技术人员使用。
∞ 总结
把服务端的三种形态放在一起看，选择逻辑其实很清晰：
- 内嵌运行：技术栈单一、Agent 需求简单时最省事，改动量最小；
- 独立服务：需要资源隔离、安全隔离、跨系统复用时，多付的部署成本是值得的；
- 智能体平台：要让非技术人员也能参与编排时，图形化是最高效的入口。
它们之间不是替代关系，而是随需求复杂度逐级演进的三条路。
下一篇，我们把视角从云端切到本地——聊聊客户端 Agent：当 AI 真正拿到你电脑的文件系统、终端和鼠标键盘，它的架构会变成什么样。
觉得有用的话，点个赞和在看，让更多做安全、做 AI 的朋友看到；也欢迎评论区聊聊你们公司最后选了哪种部署形态。
