AI Agent 到底是什么？剥开营销外衣，看清它的骨架与血肉

一叶飘零_sweet_

281人浏览 · 2026-07-31 12:41:55

一叶飘零_sweet_ · 2026-07-31 12:41:55 发布

过去这一年，但凡做 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）：发对外邮件、转账、删库这类高风险动作，必须加人工确认闸口，或做成幂等、可回滚。
降级与兜底：模型超时、限流、返回空时，要有安全提示和重试/兜底逻辑，别让整个流程卡死。