过去这一年，但凡做 AI 应用的，不说自己做了个 Agent 都不好意思跟人打招呼。可真要问一句"你这 Agent 和套了系统提示词的 GPT 聊天框，区别到底在哪"，十个人里有八个答不上来。
一、先给 Agent 一个不啰嗦的定义
Agent 不是某个具体产品，也不是某个算法，它是一种运行范式：让大模型在"感知—思考—行动—观察"的循环里自主推进一个目标，直到完成。
业界最常被引用的拆解来自 Lilian Weng（OpenAI 安全系统团队）2023 年 6 月的综述《LLM Powered Autonomous Agents》，她把 Agent 拆成四块：
- 大模型：负责推理和决策的核心控制器；
- 规划（Planning）：把大目标拆成可执行步骤，必要时反思修正；
- 记忆（Memory）：短期记当前上下文，长期存历史与知识；
- 工具（Tools）：调用搜索、代码执行、数据库、API 来弥补模型自身短板。
这套拆法不是某篇论文的发明，而是社区共识，我自己的项目也基本按这个四元组来搭。
一个常见误区：把"用了大模型的程序"都叫 Agent。不对。单纯做检索增强（RAG）的问答机器人没有自主循环，它只是一次性把检索结果喂给模型生成答案，不算 Agent。Agent 的硬指标是自主闭环——它自己决定下一步做什么，而不是每步都等人点。
二、为什么非要 Agent？大模型的三块短板
把模型单独拎出来，它有三个绕不开的缺陷，正好是 Agent 要补的：
- 知识是冻结的。参数里塞的是训练截止日之前的世界，今天油价多少、你公司内部的订单系统长啥样，它一概不知。
- 它动不了。模型只能"说"，不能"做"。它算得出该发什么邮件，但没法真的把邮件发出去。
- 它没有状态，也不会自我纠错。一问一答，答错了就错了，没有"我刚才那步错了，重来"的机制。
Agent 用三样东西补：用工具连接外部世界（查实时数据、执行动作），用记忆维持跨轮状态，用规划 + 反思把错误在闭环里消化掉。
这里有个演进脉络值得记住：2022 年 Wei 等人提出思维链（Chain-of-Thought，CoT，NeurIPS 2022），让模型"一步步想"再答，推理准确率大涨；但 CoT 只是"想"，不"做"。2023 年 Yao 等人（ReAct，ICLR 2023）把"想"和"做"拧到一起——边推理边调工具，这就是现代 Agent 的雏形。
三、Agent 的核心骨架
感知层负责把环境信息（用户输入、工具返回、系统状态）整理成模型能消化的格式；决策核心是那个大模型；记忆、规划、工具三面围着它转；工具执行完把结果以 Observation 的形式回灌，模型据此决定下一轮。
四、ReAct：看懂这一个范式，就懂了大部分 Agent
ReAct 的精华在三个 token：Thought（想法）、Action（动作）、Observation（观察）。模型先说出自己的想法，再决定调用哪个工具、传什么参数，工具跑完把结果作为 Observation 塞回去，模型看着 Observation 继续想下一步，直到能直接给答案。
一个真实感十足的例子：
❝用户：张三的航班是今天下午，现在北京天气会影响起飞吗？Thought：我得先知道北京现在的天气，再判断是不是恶劣天气。Action：
get_weather(city="北京")Observation：北京当前小到中雨，能见度较低，风速 6 级。Thought：中雨加 6 级风属于可能影响起飞的天气，我再确认下张三的航班状态。Action：query_flight(flight_no="CA1831")Observation：CA1831 状态"延误待定"。Thought：信息够了，可以回答了。Answer：北京当前中雨、6 级风，张三的 CA1831 已显示延误待定，建议他盯紧航司通知。
注意，模型自己决定"先查天气还是先查航班"，自己决定查到第几步收手。这股"自主决定控制流"的劲，就是 Agent 和写死流程的普通程序的根本区别。
ReAct 也不是没毛病：它依赖模型"自觉"输出规范格式，早期纯靠 prompt 约束时经常崩。后来业界普遍转向 Function Calling（下一节）来承担"Action"这一步，比让模型自由写 JSON 稳得多——这点经验很关键，别在 2026 年还教人用正则抠模型输出。
五、规划：让 Agent 不瞎逛
简单任务靠 ReAct 循环够用，复杂任务容易绕晕。规划模块干两件事：任务分解，和自我反思。
- 任务分解：把"写一份竞品分析报告"拆成"列竞品→逐个抓数据→对比→成文"。经典的 Plan-and-Solve（Wang 等人，2023）就是先让模型出一份计划，再按计划逐步执行。
- 树状搜索：ToT（Tree of Thoughts，Yao 等人，NeurIPS 2023）让模型对每一步生成多个候选，评估后选最优分支往下走，适合博弈、规划这类需要"多条路试试"的问题。
- 反思修正：Reflexion（Shinn 等人，NeurIPS 2023）让 Agent 在失败后用自然语言写一段"我哪里错了"的反思，存进记忆，下一轮带着这段反思重来。它不微调权重，纯靠语言反馈做强化，简单却有效。
我做代码生成 Agent 时，反思机制几乎是刚需：第一版代码跑挂了，把报错和"刚才的思路"一起喂回去，第二轮修对的概率明显高。这块省不掉。
六、记忆：别让 Agent 得了健忘症
短期记忆就是上下文窗口里那堆东西：系统提示、历史对话、工具返回。它简单但贵——token 一直涨，超窗口就丢。
长期记忆靠外部存储。最常见的做法是向量数据库做语义检索：把知识切块、向量化存进 FAISS（Meta 开源）、Chroma、Milvus 或 Pinecone，需要时按语义相似度捞相关片段塞进上下文。这套做法叫 RAG（检索增强生成），术语来自 Lewis 等人 2020 年的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。
一个经验之谈：RAG 是 Agent 的"外脑"，但它本身不是 Agent。很多产品把 RAG 问答包装成 Agent 卖，技术上说不过去——它没有自主循环。Agent 可以把 RAG 当成一个工具来用，这是两回事。
七、工具调用与 Function Calling：Agent 的手脚
早期玩法很土：在 prompt 里写"想查天气就输出 {"action":"weather",...}"，然后正则去抠 JSON。脆弱，模型一不按格式来就崩。
2023 年 6 月 OpenAI 推出 Function Calling，把这件事训练进了模型：你用 JSON Schema 描述函数（名字、参数、说明），模型在合适时直接返回结构化调用请求，你执行完把结果贴回去。比正则稳得多，现在主流模型都支持。
再往后，工具越来越多、来源越来越杂，每接一个就要写一遍适配，烦。2024 年 11 月 Anthropic 发布 MCP（Model Context Protocol，模型上下文协议），想当"AI 的 USB-C"：用统一协议把工具、数据源、提示词暴露成 MCP Server，Agent 作为 Client 即插即用。它解决的是"工具接口标准化"这一个问题，不是 Agent 本身。
八、多智能体：一个人干不过一群角色
单个 Agent 上下文容易爆，也容易"既当爹又当妈"顾不过来。多智能体让多个各司其职的 Agent 协作：
几个有代表性的框架：
- AutoGen（微软，Wu 等人，2023）：对话驱动的编排，核心是 UserProxyAgent（执行代码/工具）和 AssistantAgent（推理）来回聊。
- MetaGPT（Hong 等人，2023）：把软件公司的 SOP 塞进多角色，给一句话需求，它模拟产品经理、架构师、工程师协作产出代码。
- CAMEL（Li 等人，2023）：用"角色扮演 + 自动 inception"让两个 Agent 互相驱动，专门解决协作时一方过早退出循环的问题。
- CrewAI（2024 年开源）：偏"角色团队"式编排，上手轻。
多智能体不是银弹。它把"一个超长上下文"切成"多段短上下文"，降低了单 Agent 的复杂度，但引入了通信开销和一致性难题。小任务上单 Agent + 好工具往往更划算。
九、Java 视角：在 JVM 上把 Agent 跑起来
作为写了十几年 Java 的人，我最烦"Agent 只能 Python"的论调。现在两条成熟路线：
- LangChain4j：Java 版的 LangChain，API 直观，工具、记忆、模型抽象齐全。
- Spring AI：Spring 官方 2024 年推出的 AI 应用框架，和 Spring Boot 生态无缝。
一段能跑的 LangChain4j 示例（以 0.33.x 为例，不同小版本 API 可能微调，以官方文档为准）：
// 依赖：dev.langchain4j:langchain4j:0.33.0
// 依赖：dev.langchain4j:langchain4j-open-ai:0.33.0
import dev.langchain4j.agent.tool.Tool;
import dev.langchain4j.model.openai.OpenAiChatModel;
import dev.langchain4j.service.AiServices;
import dev.langchain4j.memory.ChatMemory;
import dev.langchain4j.memory.MessageWindowChatMemory;
public class AgentDemo {
static class WeatherTools {
@Tool("查询指定城市的当前天气")
public String getWeather(String city) {
// 真实项目里这里调天气 API
return city + " 当前 26℃，晴";
}
}
interface Assistant {
String chat(String userMessage);
}
public static void main(String[] args) {
OpenAiChatModel model = OpenAiChatModel.builder()
.apiKey(System.getenv("OPENAI_API_KEY"))
.modelName("gpt-4o-mini")
.build();
Assistant assistant = AiServices.builder(Assistant.class)
.chatLanguageModel(model)
.tools(new WeatherTools())
.chatMemory(MessageWindowChatMemory.withMaxMessages(10))
.build();
System.out.println(assistant.chat("上海现在天气怎么样？适合穿短袖吗？"));
}
}
这段代码背后就是 ReAct：模型看到 @Tool 标注的方法，会自己决定要不要调 getWeather，把结果吃进去再答。你没写任何 if/else 去判断"该不该查天气"，控制权在模型手里——这就是 Agent 的味儿。
Spring AI 走的是 ChatClient + @Tool 标注的路线，概念一致，落地到 Spring Boot 项目里更顺手，适合已经在用 Spring 的团队。
十、框架横评：别被宣传带节奏
| 框架 | 定位 | 适合场景 |
| LangChain | 组件最全的编排库 | 快速拼装原型，但抽象层多 |
| LangGraph | 有状态的图编排（2024） | 需要可控、可断点的复杂流程 |
| LlamaIndex | 数据/RAG 见长 | 知识库问答、文档智能 |
| AutoGen | 多 Agent 对话 | 研究、复杂协作任务 |
| CrewAI | 角色团队编排 | 轻量多 Agent 业务流 |
| Semantic Kernel | 微软企业级 SDK | .NET / Java 企业集成 |
| Spring AI | Spring 生态 AI 框架 | JVM 后端服务 |
| LangChain4j | Java 版 LangChain | JVM 单体 Agent |
提醒一句：LangChain 被吐槽"为了抽象而抽象"不是没道理，简单需求用它反而绕。先想清楚要什么，再选框架，别反着来。
十一、把 Agent 推进生产环境的几道关
原型能跑和能上线是两码事。这几关是我踩出来的：
- 可观测性：每一步 Thought/Action/Observation 都要落日志，否则线上出问题你连它为什么调了那个工具都看不到。LangSmith、Phoenix 这类 trace 工具能回放完整轨迹，上线前就得接。
- 护栏（Guardrails）：两类——输入护栏防提示注入，输出护栏防危险动作。间接提示注入（indirect prompt injection）是 Agent 特有风险：恶意网页被 Agent 当工具结果读进去，可能劫持它的行为，这点在做"浏览器 Agent""文档 Agent"时尤其要防。
- 人在回路（Human-in-the-loop）：发对外邮件、转账、删库这类高风险动作，必须加人工确认闸口，或做成幂等、可回滚。
- 降级与兜底：模型超时、限流、返回空时，要有安全提示和重试/兜底逻辑，别让整个流程卡死。
十二、评估：Agent 难测，但不测就别上线
Agent 非确定，同样输入跑两次轨迹都不一样，传统单测思路行不通。我的做法分三层：
- 关键断言：固定"必须调用了某工具""最终答案包含某关键信息"这类硬条件，作为回归红线。
- 轨迹回放抽检：把历史轨迹存下来，人工或 LLM-as-judge 评估"步骤是否合理、有没有绕路"。
- 端到端任务成功率：拿一批真实任务跑，看最终目标达成率，这是最贴近业务的指标。
LLM-as-a-judge（用模型评模型，Zheng 等人 2023 提出）可以做初筛，但它自己也会犯错，关键节点一定留人工抽检。
十三、我踩过的坑，你最好提前避开
- 上下文溢出。历史对话加工具返回无脑往里堆，几千轮后直接爆窗口、烧钱。解法：滑动窗口 + 关键步骤摘要压缩，别全量保留。
- 循环不收敛。Agent 有时陷入"调工具→不对→再调"死循环。一定设
max_iterations和超时，到点强制终结。 - 工具的副作用。让 Agent 发邮件、下单、删库，一旦它幻觉出错误参数就出大事。写操作必须幂等设计，或直接加人工确认闸口。
- 幻觉混进动作。模型会编出不存在的工具名或参数。用严格 JSON Schema 校验 + 工具白名单，非法调用一律拦下。
- 成本与延迟被低估。每轮一次模型调用，十轮就是十次，token 还逐轮累积。上线前一定压测成本曲线。
十四、写在最后：Agent 是范式，不是万能药
我见过很多团队，明明一个"好 prompt + function calling"就能解决的事，硬上多智能体，结果复杂度翻三倍、效果没提升。Agent 的价值在需要模型自主与环境交互、多步推进的场景：自动运维、研报生成、代码重构、长流程客服。纯问答、单轮生成，别硬套。
落地优先级我建议这样排：先确认有没有"自主循环"的真实需求 → 有，再从单 Agent + 关键工具起步 → 真遇到上下文或角色瓶颈，再上多智能体。工具、记忆、规划这三块，少一块都不叫能打的 Agent。
给想入门的读者一个顺序：读 ReAct 原论文打底 → 翻 Lilian Weng 那篇综述建立全局观 → 自己手搓一个带工具的玩具 Agent → 再去看 LangGraph / LangChain4j 文档。别一上来就背框架 API，那叫调包，不叫懂 Agent。
#AI Agent #大模型 #ReAct #LangChain4j #SpringAI #RAG #多智能体 #Java
