1. 从大模型到智能体AI agent 到底在解决什么问题这两年但凡跟技术沾点边的场合几乎都绕不开 AI agent 这个词。但很多人第一次听到它的时候脑子里冒出来的第一个问题往往是这跟 ChatGPT、DeepSeek 这些大模型到底有什么区别我直接跟大模型对话不就行了吗为什么还要搞一个 agent 出来我刚开始接触这个概念的时候也有同样的困惑。后来在实际项目里踩了不少坑才慢慢把这件事想明白。简单说大模型是一个“博学但只会动嘴”的顾问而 AI agent 是一个“能自己动手把事办成”的执行者。你问大模型“帮我订一张明天去北京的机票”它会告诉你订票的一般流程、注意事项甚至帮你列出几个航空公司的官网。但 AI agent 会直接打开订票页面填好你的身份信息选好航班走到支付那一步再问你确认。这个差别听起来好像只是“多做了几步”但背后的技术架构和工程复杂度完全不是一个量级。大模型的核心能力是理解和生成语言它的输出是文本。而 agent 的核心能力是“感知—决策—行动”的闭环它的输出是真实世界里发生的状态变化。1.1 大模型、LLM 和 AI agent 的三角关系先把几个容易混淆的概念理清楚。LLM 是 Large Language Model 的缩写中文叫大语言模型它是 AI 模型这个大家族里目前最主流的一个分支。你可以把 AI 模型理解成一个总称就像“汽车”一样下面有轿车、SUV、卡车。LLM 就是其中一种专门处理语言任务的模型。DeepSeek、GPT、Claude、通义千问这些本质上都是 LLM。那 AI agent 呢它不是模型而是一套系统。这套系统里可以包含一个或多个 LLM 作为“大脑”再加上记忆模块、工具调用模块、规划模块、执行模块等等。打个比方LLM 是发动机AI agent 是整辆车。发动机很重要但光有发动机你哪儿也去不了你还得有方向盘、油箱、传动系统才能让车真正跑起来。所以如果有人问你“DeepSeek 属于哪个”准确的说法是DeepSeek 是一个 LLM它可以被用作 AI agent 的推理核心。但 DeepSeek 本身不是一个 agent它没有记忆、没有工具调用能力、没有自主规划的能力。你得在它外面套一层 agent 框架它才能变成一个能干活的东西。1.2 为什么现在 AI agent 突然火了其实 agent 这个概念不是新东西学术界十几年前就在研究多智能体系统了。但为什么这两年才真正进入大众视野核心原因有三个。第一LLM 的推理能力跨过了某个临界点。早期的语言模型只能做简单的模式匹配你让它规划一个多步骤的任务它经常逻辑断裂。但现在的大模型在复杂推理上的表现已经相当可靠这就让“让模型自己决定下一步做什么”这件事变得可行了。第二工具调用协议标准化了。以前你想让模型去调用一个外部 API得自己写一堆解析逻辑模型输出的格式稍微变一下你的代码就崩了。现在主流的 LLM 都支持结构化的函数调用模型会按照你定义的 schema 输出参数解析起来稳定得多。第三工程生态成熟了。LangChain、LlamaIndex、AutoGen 这些框架把 agent 开发的门槛拉低了很多。你不需要从零实现记忆管理、工具路由、多轮规划这些模块框架已经帮你封装好了。当然框架也带来了新的学习成本和抽象泄漏问题这个后面会细说。1.3 一个 agent 的最小组成结构不管用什么框架一个能跑起来的 agent 至少包含四个核心模块。推理核心通常是一个 LLM负责理解用户意图、做决策、生成行动计划。这是 agent 的“大脑”。记忆系统分短期记忆和长期记忆。短期记忆就是当前对话的上下文长期记忆通常用向量数据库存储让 agent 能记住之前发生过的事情。没有记忆的 agent 每次对话都是失忆状态体验很差。工具集agent 能调用的外部能力比如搜索、计算、读写文件、调用 API、操作数据库等等。工具的定义要清晰参数 schema 要严格否则模型很容易传错参数。执行循环agent 的核心工作流。一般是“观察—思考—行动—观察”的循环直到任务完成或者达到最大步数限制。这个循环的设计直接决定了 agent 的稳定性和效率。注意很多新手一上来就想做一个“全能 agent”什么工具都往里塞。实际经验告诉我工具越多模型选错的概率越大。一个 agent 配 5 到 8 个工具是比较舒服的范围超过 15 个工具之后准确率会明显下降。2. 动手搭建第一个 AI agent从零到跑通理论说再多不如动手跑一遍。这一章我带你从零搭一个能用的 agent不依赖任何高级框架先用最原始的方式把核心逻辑跑通这样你才能真正理解框架帮你做了什么。2.1 环境准备与模型选型先确定你要用哪个 LLM 作为推理核心。如果是学习目的建议从 API 调用开始不要一上来就搞本地部署。本地部署模型虽然省钱但环境配置的坑很多容易在第一步就劝退。目前主流的选择有几个方向。OpenAI 系列的模型在函数调用上最成熟文档也最全。国内的话DeepSeek 的 API 性价比很高推理能力也够用。如果你在企业环境里可能还要考虑数据合规的问题那就得用私有化部署的方案。我个人的建议是学习阶段用 API生产环境再根据成本和合规要求决定是继续用 API 还是私有化部署。不要为了“技术先进”而选择本地部署除非你确实有数据不能出内网的需求。# 一个最简化的 agent 循环示例不依赖任何框架 import json class SimpleAgent: def __init__(self, llm_client, tools): self.llm llm_client self.tools {t.name: t for t in tools} self.memory [] self.max_steps 10 def run(self, user_input): self.memory.append({role: user, content: user_input}) for step in range(self.max_steps): response self.llm.chat( messagesself.memory, tools[t.schema for t in self.tools.values()] ) if response.tool_calls: for call in response.tool_calls: result self.tools[call.name].execute(call.arguments) self.memory.append({ role: tool, name: call.name, content: str(result) }) else: return response.content return 达到最大步数限制任务未完成这段代码虽然简陋但它包含了 agent 最核心的逻辑把用户输入和工具定义一起发给模型模型决定是直接回答还是调用工具如果调用了工具就把结果塞回上下文继续循环。所有框架本质上都是在这个骨架上做增强。2.2 工具定义的关键细节工具定义是 agent 开发里最容易被低估的环节。很多人觉得工具就是写个函数把功能实现就行了。但实际上工具的描述文本和参数 schema 直接决定了模型能不能正确使用它。我踩过的一个典型坑是工具描述写得太简略。比如我定义了一个“查询订单”的工具描述只写了“查询订单信息”。结果模型经常在用户问“我的快递到哪了”的时候去调用这个工具但实际上快递查询和订单查询是两个不同的接口。后来我把描述改成“根据订单号查询订单的详细状态包括支付状态、发货状态、物流单号。不适用于查询物流轨迹查询物流轨迹请使用 track_logistics 工具”准确率立刻就上来了。参数 schema 也要尽量严格。能用枚举的地方就用枚举能加格式约束就加格式约束。比如日期参数不要只写“string”要写清楚格式是“YYYY-MM-DD”。模型在格式明确的情况下传参错误率会低很多。还有一个经验工具的执行结果要尽量结构化。如果你返回的是一大段自然语言模型还得从里面提取信息容易出错。返回 JSON 格式的数据模型解析起来更稳定。2.3 记忆管理的实操方案记忆管理是区分“玩具 agent”和“可用 agent”的关键。最简单的记忆就是维护一个消息列表每次把完整历史发给模型。但这样做有两个问题一是 token 消耗会随着对话轮次线性增长二是当上下文太长时模型对早期信息的注意力会下降。我的做法是分层管理。最近 5 到 10 轮对话保留完整内容更早的对话做摘要压缩。摘要不是简单截断而是让模型自己总结“之前发生了什么、达成了什么结论、还有什么待办事项”。这个摘要会作为系统提示的一部分注入到后续对话中。长期记忆用向量数据库来做。当用户提到某个之前讨论过的话题时先用向量检索找到相关的历史片段再注入到当前上下文里。这样 agent 就能“记住”几个月前的事情而不需要把所有历史都塞进 prompt。实操心得摘要压缩的 prompt 要专门调优。我一开始用通用的“请总结以下对话”效果很一般。后来改成“请提取以下对话中的关键决策、待办事项和用户偏好用简洁的要点列出”摘要质量明显提升后续对话的连贯性也好了很多。2.4 执行循环的稳定性设计agent 的执行循环最容易出的问题是“死循环”和“跑偏”。死循环就是模型反复调用同一个工具或者在一个步骤上卡住出不来。跑偏就是模型理解错了任务目标做了一堆无关的操作。防死循环最直接的办法是设置最大步数限制。但光限制步数不够还要检测重复调用。如果模型连续三次调用同一个工具且参数相同就应该强制中断把当前状态返回给用户。防跑偏的办法是在系统提示里明确任务边界。我通常会在 prompt 里写清楚“你只能完成以下范围内的任务超出范围请告知用户无法处理”。另外每执行完一个工具调用可以让模型先“反思”一下当前进展确认没有偏离目标再继续。还有一个实用技巧给 agent 加一个“确认机制”。对于有副作用的操作比如发送邮件、修改数据库、提交表单在执行前先让 agent 输出一个确认请求等用户确认后再执行。这样即使模型判断错了也不会造成不可逆的后果。3. 多智能体协作与工程化落地单个 agent 跑通之后下一步自然会想能不能让多个 agent 协作完成更复杂的任务这就是多智能体系统的方向。但我要先泼一盆冷水多智能体不是银弹很多场景下单 agent 加更多工具反而更稳定。3.1 什么时候需要多智能体判断标准其实很简单任务能不能清晰地拆分成多个独立的子角色。比如一个软件开发任务可以拆成“需求分析 agent”“编码 agent”“测试 agent”“代码审查 agent”。每个角色的职责边界清晰输入输出格式明确这种场景就适合多智能体。但如果任务本身是模糊的、需要大量来回沟通的多智能体反而会增加协调成本。我见过一个团队把简单的客服问答拆成了五个 agent结果光是 agent 之间的消息传递就消耗了大量 token响应时间翻了三倍效果还不如一个单 agent。多智能体的核心挑战是通信协议的设计。agent 之间怎么传递信息、怎么表示任务状态、怎么处理冲突这些都需要提前定义好。我的经验是能用结构化数据传递就不要用自然语言。自然语言在 agent 之间传递时信息损耗比人跟人交流还大。3.2 企业级 Java 技术栈的 agent 开发如果你的团队是 Java 技术栈那 Spring AI 是目前比较成熟的选择。它把 LLM 调用、工具定义、记忆管理这些能力都封装成了 Spring 风格的 Bean 和注解跟现有的 Spring Cloud 微服务体系整合起来比较自然。一个典型的架构是这样的Spring Cloud 负责服务治理和配置管理Spring AI 负责 agent 的核心逻辑工具层通过 Feign Client 调用现有的微服务接口。这样 agent 就能复用企业已有的业务能力不需要重新造轮子。// Spring AI 工具定义示例 Component public class OrderTools { Tool(description 根据订单号查询订单状态返回支付状态和物流信息) public OrderStatus queryOrder(ToolParam(description 订单号格式为 ORD 开头的 12 位字符串) String orderId) { return orderService.getStatus(orderId); } }这种声明式的工具定义方式比手写 schema 省事很多但要注意注解里的描述文本同样要写清楚不能因为用了框架就偷懒。3.3 部署与运维的注意事项agent 的部署跟传统服务有几个不一样的地方。首先是延迟波动大因为 LLM 的响应时间本身就不稳定再加上多轮工具调用一个请求可能跑几秒也可能跑几十秒。所以超时设置要放宽异步处理要做好。其次是成本监控。agent 的 token 消耗比普通对话高得多尤其是多智能体场景。一定要做好 token 用量统计和告警不然月底账单出来会吓一跳。我的做法是给每个 agent 设置每日 token 预算超过预算就降级到更便宜的模型或者直接拒绝服务。还有可观测性。agent 的执行链路很长出了问题很难排查。建议把每一步的输入输出都记录下来包括模型的思考过程、工具调用的参数和结果。这些日志在调试和优化时非常有用。注意日志里可能包含用户敏感信息存储和访问权限要做好控制。如果是企业环境还要考虑数据脱敏和审计合规的问题。3.4 与现有系统的集成策略agent 落地最大的阻力往往不是技术而是跟现有系统的集成。我见过太多项目卡在“agent 跑得挺好但没法接入业务系统”这一步。我的建议是不要试图让 agent 直接操作核心业务系统。更稳妥的做法是在 agent 和业务系统之间加一层“适配层”把 agent 的工具调用转换成业务系统能理解的 API 请求。这层适配层可以做权限校验、参数校验、限流、审计相当于一个安全网关。另外agent 的权限要单独管理不要复用现有用户的权限。给 agent 分配最小必要权限只开放它真正需要的接口。这样即使 agent 被恶意诱导能造成的破坏也有限。4. 常见问题排查与避坑指南这一章整理我在实际项目中遇到的高频问题和解决方法都是踩过坑之后总结出来的希望能帮你少走弯路。4.1 模型不调用工具怎么办这是新手最常遇到的问题。你明明定义好了工具但模型就是不用直接用自己的知识回答。原因通常有三个工具描述不够清晰、系统提示没有强调工具的使用场景、或者模型本身对函数调用的支持不好。排查顺序是这样的先检查工具描述确保每个工具的功能、适用场景、不适用场景都写清楚了。然后在系统提示里加一句“当用户的问题涉及实时数据或需要执行操作时必须调用相应工具不要依赖你的内部知识”。如果还不行就换一个函数调用能力更强的模型试试。4.2 工具调用参数传错参数传错的表现形式很多格式不对、字段缺失、值超出范围、类型错误。根本原因通常是 schema 定义不够严格。我的做法是给每个参数都加上详细的描述和示例。比如一个“日期”参数描述里写“格式为 YYYY-MM-DD例如 2024-01-15”。一个“数量”参数描述里写“正整数范围 1 到 100”。这些细节看起来啰嗦但能大幅降低传参错误率。另外在工具执行前加一层参数校验。如果参数不合法不要直接抛异常而是返回一个友好的错误信息给模型让模型自己修正。这样 agent 就有了自我纠错的能力。4.3 上下文超长导致性能下降对话轮次多了之后上下文会越来越长模型的响应速度变慢而且对早期信息的注意力会下降。这个问题在多轮工具调用的场景下尤其明显。解决方案前面提过分层记忆这里补充一个细节工具调用的结果如果很长不要原样塞回上下文。比如一个搜索工具返回了 20 条结果你只需要把最相关的 3 到 5 条塞回去就行。剩下的可以存到外部存储需要时再检索。还有一个技巧是定期“重置”上下文。当对话轮次超过一定数量后让模型生成一个当前状态的摘要然后用这个摘要开启一个新的上下文窗口。这样既能保留关键信息又能控制上下文长度。4.4 常见问题速查表问题现象可能原因排查方向解决方案模型不调用工具工具描述不清、系统提示未强调检查工具描述和系统提示补充适用场景说明强调必须调用工具参数传错schema 不严格、缺少示例检查参数定义加格式约束和示例执行前校验响应越来越慢上下文过长检查 token 用量分层记忆、结果截断、定期重置死循环缺少步数限制、重复调用检测检查执行循环逻辑设最大步数检测重复调用任务跑偏任务边界不清检查系统提示明确任务范围加反思步骤成本超预期token 消耗大统计各环节用量设预算告警降级策略4.5 面试中常被问到的几个问题如果你在准备 AI agent 方向的面试有几个问题几乎必问。第一个是“agent 和 LLM 的区别是什么”这个前面已经讲清楚了核心是 agent 有自主决策和行动能力LLM 只有语言生成能力。第二个是“怎么保证 agent 的稳定性”。回答要从多个层面展开工具定义的规范性、执行循环的边界控制、错误处理和重试机制、可观测性建设。不要只答一个点。第三个是“多智能体系统的通信怎么设计”。重点讲清楚通信协议的选择、消息格式的定义、冲突解决机制。如果能结合具体项目经验来讲会更有说服力。第四个是“怎么评估 agent 的效果”。这个问题的难点在于 agent 的输出不是确定性的很难用传统的准确率指标来衡量。我的做法是定义一组任务完成度的指标比如任务成功率、平均步数、工具调用准确率、用户满意度。然后建一个测试集定期跑回归测试。实操心得面试时如果被问到不会的问题不要硬编。可以说“这个场景我还没实际遇到过但根据我的理解我会从某某角度去分析和解决”。面试官更看重你的思考方式而不是标准答案。4.6 学习路径建议如果你是刚入门建议按这个顺序来先理解 LLM 的基本原理和 API 调用方式然后动手写一个最简单的 agent 循环接着学习工具定义和记忆管理最后再研究多智能体和工程化部署。不要一上来就看框架文档框架的抽象会掩盖很多底层细节。先用原生 API 把核心逻辑跑通再去用框架你会理解得更透彻。遇到问题也更容易定位因为你知道框架底层在做什么。至于学习资料官方文档永远是最好的起点。OpenAI 的函数调用文档、LangChain 的 agent 教程、Spring AI 的参考指南这些都值得反复看。书的话目前市面上专门讲 agent 的书还不多可以关注一些技术博客和开源项目的源码实战性更强。我在实际项目里最大的体会是agent 开发是一个不断调优的过程没有一劳永逸的方案。今天跑得好的 prompt明天换个模型可能就不行了。保持迭代的心态做好监控和测试比追求一次性的完美方案更重要。