把 GPT-4 关在一个没有输入输出的房间里它能写诗、能解方程、能编代码——但它什么也做不了。没有眼睛看屏幕没有手去点鼠标没有记忆记住昨天用户说了什么没有工具可以调用。这就是当前大语言模型的处境拥有一颗超强的大脑却没有一个身体。Agent 要解决的正是这个问题。本文是 Agent 基础系列的开篇先把Agent 到底是什么、为什么需要它这件事讲清楚建立起整体认知框架。一、LLM 的困局能想但不能动打开任何一个大模型的对话界面输入一段 prompt几秒后拿到回复——这就是绝大多数人与 LLM 交互的全部。看起来已经很厉害了但仔细想一下这个过程的本质输入一段文本 → 输出一段文本。仅此而已。模型不会主动去查数据库不会帮你打开浏览器下单不会记住你上周说过的偏好更不会在任务出错时自己调整方案。它是一个极其强大的推理引擎但推理的起点和终点都是文本——它被锁在一个纯符号的世界里。这种有脑无身的状态在工程上带来三个根本性问题1. 无法感知环境模型不知道当前几点了、不知道用户的文件在哪里、不知道上游系统返回了什么状态码。它只能处理你塞进 prompt 的信息其余一概不知。2. 无法采取行动模型可以告诉你建议执行 SQL 查询但它自己不会执行。它给出的永远是一个建议而不是一个结果。从建议到结果之间还需要人去做最后一步。3. 没有持续记忆每次 API 调用都是独立的模型不记得上一轮对话。所谓对话上下文是应用层把历史消息重新拼好再传一遍——这不是记忆这是每次考试都把草稿纸重抄一遍。这三个问题的本质是一样的LLM 缺少与外部世界的闭环交互能力。Agent 就是为了补上这块拼图。二、Agent 的本质LLM 感知 行动 记忆Agent这个概念不是 LLM 时代才出现的。早在 1997 年Franklin 和 Graesser 就给出了自主 Agent 的经典定义 [1]一个身处环境中、能感知环境、能作用于环境、随时间推进自身目标的系统。到了 LLM 时代OpenAI 研究员 Lilian Weng 在 2023 年发表了一篇被广泛引用的博文 [2]给出了一个更具体的架构分解Agent LLM大脑 Planning规划 Memory记忆 Tool Use工具使用LLM 负责推理和决策其余三个模块分别解决怎么拆解任务、怎么记住经验和怎么扩展能力的问题。如果用人体来类比整个架构就很直观了Agent 组件人体对应功能LLM大脑前额叶推理、规划、决策——理解目标、拆解步骤、做出判断感知Perception眼睛、耳朵读取屏幕、解析文件、接收用户指令、获取系统状态行动Action / Tools手、嘴调用 API、操作浏览器、执行代码、写入数据库——对世界产生副作用记忆Memory工作记忆 长期记忆工作记忆 当前对话上下文长期记忆 用户偏好、历史经验环境Environment外部世界操作系统、文件系统、Web 应用、第三方服务——Agent 行动的对象没有 LLM系统只是一个自动化脚本没有感知、行动、记忆LLM 只是一个放在培养皿里的大脑。Agent 的本质就是给大脑装上身体让它从能想变成能干。三、Agent 运行时架构一张图看懂核心组件在深入代码之前先用一张架构图建立全局视角。一个典型的 Agent 运行时由以下组件组成┌─────────────────────────────────────────────────────────────────┐ │ Agent Runtime │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Execution Loop执行循环 │ │ │ │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ │ │ Thought │───►│ Action │───►│ Observation │ │ │ │ │ │ (LLM推理) │ │(工具调用) │ │ (结果解析) │ │ │ │ │ └──────────┘ └──────────┘ └──────────────┘ │ │ │ │ ▲ │ │ │ │ │ │ Loop until done │ │ │ │ │ └─────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────────┐ ┌──────────────┐ ┌────────────────┐ │ │ │ LLM │ │ Tool Registry│ │ Memory │ │ │ │ (推理引擎) │ │ (工具注册表) │ │ (记忆系统) │ │ │ │ │ │ │ │ │ │ │ │ - Chat API │ │ - 工具描述 │ │ - 短期上下文 │ │ │ │ - Tool Call │ │ - 参数Schema │ │ - 长期向量库 │ │ │ │ - Streaming │ │ - 调用适配器 │ │ - 摘要压缩缓存│ │ │ └─────────────┘ └──────────────┘ └────────────────┘ │ │ │ │ │ │ └─────────┼──────────────────┼──────────────────┼─────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌────────────┐ ┌──────────┐ │模型服务 │ │ 外部工具 │ │ 存储后端 │ │OpenAI │ │ - REST API │ │ - Redis │ │Claude │ │ - DB Query │ │ - PgVec │ │通义千问 │ │ - Browser │ │ - 文件系统│ └─────────┘ └────────────┘ └──────────┘四个核心组件的职责Execution LoopAgent 的心跳驱动 Thought → Action → Observation 循环直到任务完成或触发终止条件LLM推理引擎接收当前上下文用户输入 工具结果 历史输出下一步决策继续调用工具 or 返回最终答案Tool Registry工具注册表管理所有可用工具的名称、描述、参数 Schema 和执行逻辑。LLM 通过 Function Calling 机制与它交互Memory记忆系统短期记忆维护当前对话上下文直接塞进 prompt长期记忆通过向量检索增强本系列的 RAG 和 Memory 专题会深入展开关键设计决策Execution Loop 不在 LLM 内部而是在应用层。LLM 只负责单次推理要不要继续循环、什么时候停是应用层的逻辑。这个解耦是理解 Agent 架构的关键——LLM 是引擎Loop 是方向盘。四、Chatbot vs Agent不是程度差异是范式差异很多人会把 Agent 理解为更高级的聊天机器人。但从架构层面看两者是完全不同的范式维度ChatbotAI Agent核心功能回应消息完成目标交互模式反应式输入 → 输出自主式感知 → 规划 → 行动 → 观察工具使用极少或无核心能力多步执行否单次推理是循环调用工具直到完成错误恢复需要人重新提示任务内自我修正副作用默认无可产生真实世界行动发邮件、改数据库一句话总结Chatbot 回应问题Agent 完成目标。一个是你问它答一个是你说目标它干活。但 Agent 也不是非黑即白的概念它是一个光谱——最左边是纯规则聊天机器人关键词匹配 → 预设回复中间是带插件的 Chatbot能调用一两个工具但不自主循环最右边是完全自主的 Agent可以连续运行数小时、执行数十次工具调用、无需人在环。当前绝大多数生产级产品处于中间偏右的位置。五、ReAct让推理接地的核心循环Agent 和 Chatbot 最大的架构差异在于Agent 不是想完再说而是边想边做边看。这个循环有一个正式的名字——ReActReasoning Acting [3]。ReAct 的核心循环只有三步Thought思考→ Action行动→ Observation观察→ 重复看起来很简单但它的核心洞察是推理帮助行动行动也帮助推理。推理让模型制定计划、处理异常行动让模型与外部世界交互获取新信息来支撑下一步推理。两者互为补充形成闭环。为什么这个循环如此重要因为纯推理Chain-of-Thought有一个致命缺陷它是静态的。模型完全依赖内部知识不与外部世界交互一旦内部知识有误错误就会一路传播下去。ReAct 论文Yao et al., ICLR 2023的实验数据很说明问题方法事实核查准确率幻觉率纯推理CoT56.3%14%ReAct推理行动60.9%6%ReAct 多路采样64.6%—数据来源ReAct 论文 Table 3 [3]ReAct 的幻觉率仅为纯推理的不到一半。原因很直观每一步推理之后Agent 可以通过行动比如搜索、查数据库来验证自己的判断而不是蒙着头往下推。回到人类的做事方式其实也是这样——你不会把一道菜的全部步骤在脑子里过一遍才动手而是切一刀看看厚度、炒两步尝尝咸淡、随时调整。这种边想边做边看的模式就是 ReAct 在 Agent 中的实现。5.1 ReAct 循环的伪代码在进入真实框架代码之前先用伪代码看清 ReAct 循环的本质。无论用什么框架、什么语言Agent 的核心循环都可以归结为function agentRun(userQuery): messages [systemPrompt, userQuery] loop: response llm.chat(messages, toolsregisteredTools) if response.hasToolCalls(): for each toolCall in response.toolCalls: // 执行工具 result toolRegistry.execute( toolCall.name, toolCall.arguments ) // 把工具结果追加到消息列表 messages.append(toolResult(toolCall.id, result)) continue // 继续循环让 LLM 看到结果后决定下一步 else: // LLM 直接返回文本没有工具调用 → 任务完成 return response.text就这么简单。整个 Agent 的核心就是一个while循环LLM 决定调用工具就执行工具、把结果喂回去继续跑LLM 决定直接回答就结束循环。复杂的是工具和记忆不是循环本身。5.2 用 Java Spring AI 实现最小 ReAct AgentSpring AI 是 Spring 生态的 AI 集成框架。以下代码展示的是手动实现 ReAct 循环的方式目的是让你看清循环内部的每一步。Spring AI 2.0 已经通过ToolCallingAdvisor内置了这个循环——实际项目中你不需要手写但理解内部机制对调试和定制至关重要。/** * 最小 ReAct Agent 实现Spring AI * 演示 Thought → Action → Observation 循环在 Java 中怎么跑 */ Service public class ReActAgent { private final ChatClient chatClient; private final ToolRegistry toolRegistry; private final int maxIterations 10; // 防止死循环 public ReActAgent(ChatModel chatModel, ToolRegistry toolRegistry) { this.toolRegistry toolRegistry; // 构建 ChatClient注册所有可用工具 this.chatClient ChatClient.builder(chatModel) .defaultSystem( 你是一个智能助手。请按照以下步骤处理用户请求 1. 先分析问题思考需要什么信息 2. 如果需要外部数据调用合适的工具 3. 根据工具返回结果继续分析或直接回答 4. 重复直到收集够信息给出最终答案 ) .defaultTools(toolRegistry.getAllToolCallbacks()) .build(); } /** * Agent 执行入口 * 核心让 LLM 自主决定调用工具还是直接回答 */ public String run(String userQuery) { // 消息历史 短期记忆 ListMessage messages new ArrayList(); messages.add(new UserMessage(userQuery)); for (int i 0; i maxIterations; i) { // 调用 LLM带工具定义 ChatResponse response chatClient.prompt() .messages(messages) .call() .chatResponse(); AssistantMessage assistantMsg response.getResult().getOutput(); // 判断LLM 是要调用工具还是直接回答 if (hasToolCalls(assistantMsg)) { // --- Action 阶段执行工具调用 --- messages.add(assistantMsg); // 记录 LLM 的决策 for (ToolCall toolCall : assistantMsg.getToolCalls()) { // Observation 阶段获取工具执行结果 String result executeTool(toolCall); // 将工具结果追加到消息列表供下一轮推理使用 messages.add(new ToolResponseMessage( toolCall.id(), toolCall.name(), result )); log.info([ReAct 循环 #{}] 工具: {} → {}, i, toolCall.name(), truncate(result, 200)); } // continue → 回到循环顶部让 LLM 看到工具结果 } else { // --- 最终回答LLM 认为任务完成 --- log.info([ReAct 循环 #{}] 任务完成共 {} 轮迭代, i, i 1); return assistantMsg.getText(); } } throw new AgentTimeoutException( Agent 在 maxIterations 轮内未能完成任务); } private String executeTool(ToolCall toolCall) { try { return toolRegistry.execute( toolCall.name(), toolCall.arguments() ); } catch (Exception e) { // 工具执行失败时把错误信息返回给 LLM // 让 LLM 决定是重试、换个工具、还是放弃 return 工具执行失败: e.getMessage() 。请考虑其他方案。; } } }代码关键点解读循环是核心整个 Agent 就是一个for循环 条件判断。LLM 返回 tool_calls → 执行工具 → 结果塞回 messages → 继续循环。LLM 返回纯文本 → 结束。LLM 是决策者每次循环LLM 看到完整的消息历史包括之前的工具结果自主决定下一步是调用工具还是给出最终答案。Agent 代码不做任何硬编码的流程控制。maxIterations 是安全阀生产环境中必须设置最大迭代次数防止 LLM 陷入死循环反复调用同一个工具、或者在两个工具之间来回切换。工具错误不回退交给 LLM 处理工具执行失败时把错误信息作为 Observation 返回给 LLM让 LLM 决定下一步。这比硬编码的重试逻辑灵活得多。5.3 用 Python LangChain 实现同一件事对比一下 Python 生态的实现感受不同框架的风格差异from langchain.agents import create_react_agent, AgentExecutor from langchain_openai import ChatOpenAI from langchain.tools import tool # 定义工具用装饰器非常简洁 tool def search_github_trending(language: str, period: str) - str: 搜索 GitHub Trending 项目返回项目名称、Star 数和描述 # 实际实现调用 GitHub API return f找到 25 个 {language} 项目本周最热: spring-ai (Star 1200)... tool def filter_ai_projects(project_list: str) - str: 从项目列表中筛选 AI 相关项目 return 筛选出 8 个 AI 相关项目: spring-ai, langchain4j, ... # 定义 Agent一行代码 llm ChatOpenAI(modelgpt-4o, temperature0) agent create_react_agent( modelllm, tools[search_github_trending, filter_ai_projects], promptreact_prompt_template # ReAct 格式的 prompt ) # 执行AgentExecutor 负责循环 executor AgentExecutor(agentagent, toolstools, max_iterations10) result executor.invoke({input: 查最近一周 GitHub 上 Star 增长最快的 Java AI 项目})对比两个版本核心逻辑完全一样LLM → 工具调用 → 结果喂回 → 循环但风格差异很大Spring AI显式控制循环类型安全适合需要精细控制的场景LangChain高度封装几行代码搞定但调试时需要理解框架内部的抽象层六、主流 Agent 框架横评LangChain vs LangGraph vs Spring AI vs AgentScope不同框架对 Agent 的抽象方式差异很大。以下从开发者最关心的几个维度做横向对比6.1 Agent 定义方式维度LangChainLangGraphSpring AIAgentScope语言PythonPythonJavaPython / Java / TypeScriptAgent 定义create_agent()函数式图Graph 节点NodeChatClientTool注解ReActAgent/HarnessAgentJava/DialogAgentPython控制流框架内置循环开发者自定义图结构框架内置工具循环ToolCallingAdvisor框架内置循环工具定义tool装饰器tool装饰器Tool注解 /ToolCallbackToolkit注册Python/Tool注解Java多 Agent需要手动编排原生支持多节点 多 Agent需要自行实现内置 Pipeline / MsgHub / A2A6.2 工具调用编排LangChain工具调用对开发者几乎透明。AgentExecutor自动处理LLM 要调用工具 → 执行 → 结果返回 LLM的循环。好处是简单坏处是调试困难——出问题时不知道循环内部发生了什么。# LangChain: 工具调用对开发者透明一行 invoke 搞定 result executor.invoke({input: 今天北京天气怎么样}) # 中间发生了什么你不知道除非开 verboseTrueLangGraph把循环拆成显式的图节点每个节点是一个处理步骤边定义了控制流。开发者完全控制 Agent 的执行路径。from langgraph.graph import StateGraph, END # LangGraph: 显式定义执行图 graph StateGraph(AgentState) graph.add_node(agent, call_model) # 节点1LLM 推理 graph.add_node(tools, call_tools) # 节点2执行工具 graph.add_edge(tools, agent) # 工具结果 → 回到 LLM graph.add_conditional_edges(agent, # LLM 决策分支 should_continue, {continue: tools, end: END} ) app graph.compile() result app.invoke({messages: [HumanMessage(content...)]})Spring AI工具定义用 Java 注解强类型IDE 友好。Spring AI 2.0 引入了ToolCallingAdvisor递归 Advisor框架自动驱动工具调用循环——开发者只需定义工具并注册到ChatClient循环逻辑不再需要手写。// Spring AI: 用 Bean 注册工具类型安全 Bean Description(搜索 GitHub Trending 项目) // 工具描述传给 LLM public FunctionGithubRequest, String searchGithub() { return request - githubService.getTrending( request.language(), request.period()); }AgentScope面向多 Agent 场景设计通过MsgHub实现多 Agent 之间的消息广播和协调。from agentscope.agents import DialogAgent from agentscope.service import ServiceToolkit # AgentScope: 面向多 Agent 的对话编排 toolkit ServiceToolkit() toolkit.add(search_github) agent1 DialogAgent(planner, model_config_namegpt-4, service_toolkittoolkit) agent2 DialogAgent(executor, model_config_namegpt-4, service_toolkittoolkit) # Pipeline 串行执行MsgHub 广播通信 pipeline SequentialPipeline([agent1, agent2])6.3 记忆管理对比框架短期记忆长期记忆记忆管理方式LangChainConversationBufferMemory全量保留需自行集成向量库提供 Memory 抽象类但实现需要开发者接入LangGraphState对象中的messages列表通过 Checkpoint 持久化 State显式状态管理每个节点读写 StateSpring AIMessageWindowChatMemory滑动窗口VectorStore接口支持 PgVector / Milvus接口抽象好但自动摘要等高级功能需自行实现AgentScopeAgent 内部memory队列需自行集成提供 Memory 基类支持自定义序列化选型建议如果你的项目是 Java 技术栈、需要强类型和 IDE 支持 → Spring AI。如果是 Python 技术栈、需要快速原型 → LangChain。如果需要精细控制执行流比如复杂的多 Agent 编排、条件分支、人机交互节点 → LangGraph。如果核心需求是多 Agent 协作 → AgentScope 值得尝试。七、从能推理到能行动Agent 能力的三次跃迁回顾 Agent 的发展脉络能力的跃迁可以分成三个阶段7.1 第一阶段函数调用20232023 年OpenAI 在 GPT-3.5/4 中引入 Function Calling让模型能够输出结构化的函数调用请求。这是 Agent 从纯文本生成走向工具调用的第一步。LangChain 等框架迅速跟进Agent 开发者可以通过预定义的 API 来扩展模型能力。这个阶段的核心模式是为模型造工具——每个能力都需要专门定义接口、写好描述、注册到模型中。7.2 第二阶段操作电脑2024-20252024 年 10 月Anthropic 发布 Computer Use [5]让 Claude 直接看屏幕截图、计算鼠标坐标、点击按钮和输入文字。这意味着 Agent 不再需要为每个软件写专门 API——它可以直接像人一样操作任何有图形界面的软件。OpenAI 在 2025 年初跟进发布了 Operator [8]搭载 CUA 模型进一步验证了这条路线。这个阶段的范式转变是从为模型造工具到让模型学会用人的工具。Agent 可以操作人类已经用了几十年的软件而不需要等每个软件开放 API。7.3 第三阶段套件化场景落地20262026 年Agent 赛道进入场景深耕阶段。国内以百度搭子为代表一个月内连推自媒体、设计、金融三个垂直套件 [7]把通用 Agent 能力封装为一个套件解决一类问题的产品形态。国外 OpenAI 把 Operator 整合进 ChatGPT AgentAnthropic 通过 API 让开发者广泛接入 Computer Use。IDC 在 WAIC 2026 上首发的《DAA研究报告》[9] 预测全球活跃 Agent 数量将从 2025 年的 2860 万增长到 2030 年的 22.16 亿。Agent 正在从极客玩具变成生产力基础设施。八、一个真实例子ReAct 循环怎么跑起来的抽象概念说完了用一个具体例子来看 Agent 是怎么工作的。假设用户说帮我查一下最近一周 GitHub 上 Star 增长最快的 Java AI 项目整理成表格。Chatbot 的做法输出一段文字建议——你可以去 GitHub Trending 页面查看或者用 GitHub API 自己写个脚本……然后结束。用户还得自己去做。Agent 的做法则完全不同Thought 1用户要查 GitHub 上 Java AI 项目近一周的 Star 增长。我需要先获取 GitHub Trending 数据。Action 1调用浏览器工具打开 GitHub Trending 页面筛选 Java 语言、时间范围选 This Week。Observation 1页面加载完成获取到前 25 个项目的名称、描述、Star 数。Thought 2拿到了项目列表但用户要的是增长最快需要筛选出 AI 相关的项目。我来逐个分析描述。Action 2对每个项目的描述做关键词匹配 语义判断筛选出 AI/LLM/RAG/Agent 相关项目。Observation 2筛选出 8 个 AI 相关项目。Thought 3数据收集完成现在生成 Markdown 表格。Action 3生成表格并返回给用户。整个过程经历了 3 轮 Thought → Action → Observation 循环调用了浏览器、语义分析、文件生成等多个工具。这就是 ReAct 循环在实际 Agent 中的运作方式——不是一次性想好再输出而是想一步做一步看一步。8.1 从开发者视角看同一件事作为开发者你在日志中看到的 ReAct 循环执行过程是这样的[Agent] 收到用户请求: 查最近一周 GitHub 上 Star 增长最快的 Java AI 项目 [ReAct #1] LLM 决策: 调用 search_github_trending(languagejava, periodweekly) [ReAct #1] 工具返回: 找到 25 个项目: spring-ai(1200⭐), langchain4j(890⭐)... [ReAct #1] Token 消耗: prompt1,200 completion350 1,550 [ReAct #2] LLM 决策: 调用 filter_ai_projects(projectsspring-ai,langchain4j,...) [ReAct #2] 工具返回: AI 相关 8 个: spring-ai, langchain4j, deeplearning4j... [ReAct #2] Token 消耗: prompt2,100 completion280 2,380 [ReAct #3] LLM 决策: 直接回答不调用工具 [ReAct #3] 生成最终 Markdown 表格 [Agent] 任务完成共 3 轮迭代总 Token 消耗: 5,480每一轮循环的 Token 消耗是累加的——因为每一轮都需要把之前的所有消息历史重新传给 LLM。这就是为什么 Agent 的 Token 消耗远大于单次 Chatbot 调用也是为什么成本控制是生产级 Agent 必须面对的工程问题。九、生产级 Agent 的工程挑战把 Agent 从 Demo 带到生产会碰到一系列 Demo 中不会遇到的问题。以下是最关键的四个。9.1 错误恢复工具调用失败怎么办在 Demo 中工具调用总是成功的。在生产中工具会超时、会返回错误、会返回不符合预期的数据。核心原则把错误信息返回给 LLM让它自己决定怎么处理。回到第五节的 Java 代码executeTool方法中的错误处理已经体现了这个思路private String executeTool(ToolCall toolCall) { try { return toolRegistry.execute(toolCall.name(), toolCall.arguments()); } catch (TimeoutException e) { return 工具 toolCall.name() 执行超时30s 建议1) 缩小查询范围重试 2) 换用其他数据源; } catch (Exception e) { return 工具执行失败: e.getMessage() 。请考虑其他方案。; } }关键设计不让工具异常中断 Agent 循环。异常被捕获转化为Observation返回给 LLM给 LLM 提供恢复建议。不是简单地说失败了而是告诉它可以尝试什么LLM 通常能做出合理的恢复决策——换一个工具、调整参数重试、或者告诉用户我做不到但也要注意LLM 可能在恢复时陷入死循环反复用相同参数重试同一个失败的工具。所以 maxIterations 限制和重复工具调用检测是必须的。// 检测重复调用如果连续 2 次调用同一工具且参数相同强制终止 private SetString recentCalls new HashSet(); private String executeToolWithDedup(ToolCall toolCall) { String callSignature toolCall.name() : toolCall.arguments(); if (recentCalls.contains(callSignature)) { return 检测到重复调用。该工具已用相同参数调用过一次且 未成功。请更换策略或告知用户当前限制。; } recentCalls.add(callSignature); // ... 执行逻辑 }9.2 成本控制Token 消耗的优化Agent 的 Token 消耗是乘法效应的每一轮循环都要把完整的历史消息传给 LLM。3 轮循环的 Token 消耗不是 3 倍而是 1236 倍因为每轮的消息数在增长。实际优化手段策略原理效果滑动窗口只保留最近 N 轮消息丢弃更早的减少 30-50% Token工具结果压缩工具返回的原始数据太大时先做摘要再塞入上下文减少 50-80% Token选择更便宜的模型简单步骤用小模型如 GPT-4o-mini关键决策用大模型减少 60-90% 费用缓存重复查询相同工具相同参数 → 返回缓存结果减少重复调用的 TokenSpring AI 中的滑动窗口记忆实现// 只保留最近 20 条消息防止上下文无限膨胀 ChatMemory memory MessageWindowChatMemory.builder() .chatMemoryRepository(new InMemoryChatMemoryRepository()) .maxMessages(20) .build();工具结果压缩的示例——不要把整个网页塞进去Tool(description 搜索网页内容) public String searchWeb(String query) { String rawHtml httpClient.get(url); // 不要直接返回 rawHtml可能有 50KB // 提取关键信息压缩到 2KB 以内 return extractAndSummarize(rawHtml, query); }9.3 超时处理Agent 不能无限跑下去生产环境中一个 Agent 任务可能需要 10 秒到 5 分钟不等。必须设置多层超时public class AgentConfig { // 第一层单次 LLM 调用超时 private Duration llmCallTimeout Duration.ofSeconds(30); // 第二层单次工具调用超时 private Duration toolCallTimeout Duration.ofSeconds(60); // 第三层整个 Agent 任务超时 private Duration agentTimeout Duration.ofMinutes(5); // 第四层最大迭代次数 private int maxIterations 10; }每一层超时触发后的处理方式LLM 调用超时重试一次仍然超时则终止任务返回已有的中间结果工具调用超时把超时信息返回给 LLM让它决定是否换方案Agent 总超时强制终止返回当前最佳结果 说明哪些步骤未完成9.4 幂等性设计重复执行不能出事故Agent 会调用工具产生副作用发邮件、写数据库、创建订单。如果因为重试或异常恢复导致工具被重复调用必须保证幂等性。Tool(description 发送邮件给指定收件人) public String sendEmail(String to, String subject, String body) { // 幂等性设计用请求 ID 去重 String requestId generateRequestId(to, subject, body); if (processedRequests.contains(requestId)) { return 邮件已发送检测到重复调用跳过; } emailService.send(to, subject, body); processedRequests.add(requestId); return 邮件发送成功; }生产环境中的幂等性方案写操作用唯一请求 ID 去重或者用数据库唯一约束查询操作天然幂等但要注意缓存一致性不可逆操作如删除增加确认步骤或在 Agent 循环中设置人工审批节点十、这个框架在系列中的位置本文建立了 Agent 的整体认知框架。这个框架不是孤立的——此前已发布的每个专题系列都在这个框架上深入了一个具体模块系列对应 Agent 组件解决什么问题RAG 系列Memory长期记忆Agent 怎么从海量文档中精准找到需要的知识怎么做检索增强MCP 系列Tool Use工具使用Agent 怎么用统一协议连接外部工具和数据源MCP 解决了什么问题Memory 系列Memory多层记忆Agent 怎么跨会话记住用户偏好怎么从经验中学习记忆的工程分层怎么做而 Agent 基础篇本身接下来还会继续拆解两个关键话题本篇内容AGENT-02四大核心机制全景图——Planning、Tool Use、Memory、Reflection 各自怎么工作怎么协作AGENT-03从单 Agent 到多 Agent——为什么需要多 Agent怎么编排和单 Agent 的本质区别是什么理解了今天的整体框架再去看每个系列的具体实现就会清楚它们各自在 Agent 架构中扮演什么角色。结语LLM 给了 AI 一颗强大的大脑但大脑不能独立存在——它需要感知来理解世界需要行动来改变世界需要记忆来积累经验需要一个完整的闭环来持续运转。这就是 Agent 的本质不是一个新的模型而是一种新的架构范式——让 LLM 从能说进化为能做。从代码层面看Agent 的核心就是一个while循环——但这个循环让 LLM 从被动回答问题变成了主动完成目标。真正的工程挑战不在循环本身而在循环周围的一切工具的可靠性、记忆的管理、成本的控制、错误的恢复、副作用的安全。下一篇我们进入 Agent 基础篇第二篇拆解 Planning、Tool Use、Memory、Reflection 四大核心机制——看看这个身体的每个器官具体怎么工作。有问题评论区见欢迎交流~参考资料[1] Franklin, S. Graesser, A. (1997). Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents. Proceedings of the Third International Workshop on Agent Theories, Architectures, and Languages (ATAL 96), Springer LNAI Vol.1388. https://cs.memphis.edu/~franklin/atal96/atal96.htm[2] Lilian Weng, LLM Powered Autonomous Agents. LLM Powered Autonomous Agents | LilLog[3] Yao et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. https://arxiv.org/pdf/2210.03629[4] Lei Wang et al. (2024). A survey on large language model based autonomous agents. Frontiers of Computer Science 2024. https://www.researchgate.net/publication/379217962_A_survey_on_large_language_model_based_autonomous_agents[5] Anthropic, Developing a computer use model. Developing a computer use model \ Anthropic[6] Catio, Agentic AI Reference Architecture. Agentic AI Reference Architecture: Components Layers | Catio[7] 央广网百度搭子 WAIC 2026 报道. 2030年全球DAA将超22亿个 百度AI三大发布亮相WAIC_央广网[8] Presenc AI, OpenAI Operator Update Tracker. OpenAI Operator Update Tracker: From Operator to ChatGPT Agent (2026) | Presenc AI[9] IDC《DAA研究报告》, WAIC 2026 首发. https://36kr.com/newsflashes/3899647452677769