1. 从一堆热搜词里我看到了 AI agent 的真实全貌最近后台收到不少私信问的都是同一类问题“AI agent 到底是个啥和 DeepSeek 这种大模型是什么关系”“我想学 AI agent 开发该从哪下手”“企业里用 Java 能不能搞 agent 平台”这些问题凑在一起其实指向了一个很明确的信号AI agent 已经从概念炒作期进入了工程落地期大量开发者、产品经理、企业技术负责人都在找一条能走得通的路。我自己从 2023 年下半年开始系统性地做 agent 相关的项目从最早的“套壳对话机器人”到后来的多智能体协作系统再到给传统企业做 PLC 编程辅助的 agent 工具链踩过的坑比写过的代码还多。这篇文章不打算给你讲什么“AI agent 是未来”这种正确的废话而是把我在实际项目里验证过的架构思路、开发流程、工具选型、避坑经验全部摊开来讲。无论你是刚听说 AI agent 的新手还是已经在做企业级 agent 平台的老手应该都能从里面找到对自己有用的东西。先给一个最直白的定义AI agent 是一个能自主感知环境、做出决策、调用工具、执行动作并最终完成目标的软件系统。注意这里的几个关键词——自主、决策、工具、执行。这四样东西缺一个它就不算真正的 agent只能算一个“会聊天的模型接口”。很多人把 DeepSeek、GPT 这类大语言模型直接叫做 agent这是不准确的。大模型是 agent 的“大脑”但光有大脑没有手脚、没有记忆、没有工具它什么都干不了。下面我会把这个关系彻底讲清楚。2. AI agent、LLM、AI 模型到底谁是谁2.1 用一家公司来类比这三者的关系我习惯用一家公司来打比方这样最好理解。AI 模型是公司里那个知识渊博但只会动嘴的顾问你问他什么他都能答但他不会自己去查资料、不会发邮件、不会操作 Excel。LLM大语言模型是 AI 模型里专门处理语言文字的那一类比如 DeepSeek、通义千问、文心一言这些它们的核心能力是理解和生成自然语言。而AI agent是给这位顾问配了一个完整的执行团队——有秘书帮他记事情记忆模块、有助理帮他查资料工具调用、有项目经理帮他拆任务规划模块、有质检员帮他检查结果反思模块。顾问只负责出主意真正把事办成的是整个团队。所以当有人问“DeepSeek 属于哪个”的时候答案很明确DeepSeek 是一个 LLM是 AI 模型的一种它可以作为 AI agent 的核心推理引擎但它本身不是 agent。你可以把 DeepSeek 装进一个 agent 系统里让它当大脑但你还得给它配上记忆、工具、规划这些组件它才能变成一个真正的 agent。2.2 一张表把概念彻底理清概念本质核心能力典型代表能否独立完成任务AI 模型数学函数的集合模式识别、预测图像分类模型、推荐模型否LLM基于 Transformer 的大规模语言模型语言理解与生成DeepSeek、GPT、Claude否只能生成文本AI agent以 LLM 为推理核心的完整系统感知、规划、工具调用、执行AutoGPT、LangChain Agent、企业自研平台是这张表建议你存下来面试的时候被问到“agent 和 LLM 有什么区别”直接按这个逻辑答基本不会出错。我在面试别人的时候最怕听到“agent 就是更聪明的 LLM”这种回答说明他根本没做过实际项目。2.3 为什么这个区分如此重要因为混淆概念会直接导致技术选型错误。我见过一个团队老板说“我们要做一个 AI agent 来自动处理客服工单”结果技术负责人直接调了一个大模型的 API写了个 prompt 让模型输出处理方案然后就没有然后了。这个系统上线后模型只能“建议”怎么处理但没法真正去查订单、改状态、发通知。这就是把 LLM 当成了 agent少了工具调用和执行环节。正确的做法是LLM 负责理解工单内容并决定调用哪个工具agent 框架负责实际调用工单系统的 API 完成操作最后再把结果反馈给 LLM 生成回复。整个链路走通才叫 agent。3. 一个 AI agent 的骨架里到底装了什么3.1 四大核心模块缺一不可不管你是用 LangChain、Spring AI 还是自己从零手写一个完整的 AI agent 系统一定包含这四个模块推理核心Brain通常就是一个 LLM负责理解输入、做出决策、生成输出。选型时重点看它的函数调用Function Calling能力这是 agent 能否调用工具的关键。记忆系统Memory分短期记忆和长期记忆。短期记忆就是当前对话的上下文长期记忆通常用向量数据库存储历史经验和知识需要的时候检索出来。工具集Toolsagent 能调用的外部能力比如搜索引擎、数据库查询、API 调用、代码执行器、文件读写等。工具的设计质量直接决定 agent 的能力边界。规划与反思Planning Reflectionagent 把大任务拆成小步骤的能力以及在执行过程中发现错误后自我纠正的能力。这是区分“初级 agent”和“高级 agent”的分水岭。3.2 记忆模块的设计细节记忆这块我想多说几句因为很多新手做的 agent 是“金鱼记忆”——聊完就忘。短期记忆的实现相对简单就是把对话历史按 token 数截断后塞进 prompt。但长期记忆就复杂了你需要决定什么信息值得存存成什么格式什么时候检索检索多少条我的经验是长期记忆不要什么都存。我试过把所有对话都存进向量库结果检索出来的内容噪音极大反而干扰了 agent 的判断。后来改成只存三类信息用户的明确偏好比如“我喜欢简洁的回答”、任务执行的成功经验比如“处理这类工单要先查订单状态”、以及重要的实体信息比如“客户 A 的账号是 XXX”。这样检索精度大幅提升。3.3 工具调用的实现原理工具调用的底层机制其实不复杂。你在定义工具的时候实际上是在告诉 LLM“我这里有几个函数它们的名字、参数、功能描述如下。”当 LLM 判断需要调用某个工具时它会输出一个结构化的调用请求通常是 JSONagent 框架解析这个 JSON执行对应的函数再把结果返回给 LLM。整个过程就像你给一个外包同事发了一份“可调用服务清单”他需要什么就按格式申请你帮他执行完再把结果给他。注意工具的描述文字非常关键。我踩过的坑是工具描述写得太简略LLM 经常选错工具或者传错参数。后来我把每个工具的描述都写成“什么场景下用、参数格式是什么、返回什么结果”三段式调用准确率从 60% 提升到了 90% 以上。4. 从零搭建一个 AI agent 的完整实操流程4.1 环境准备与技术栈选型如果你是 Python 技术栈推荐 LangChain 或 LlamaIndex 作为基础框架向量数据库用 Chroma 或 MilvusLLM 可以用 DeepSeek 的 API性价比高或者本地部署开源模型。如果你是 Java 技术栈Spring AI 是目前最成熟的选择配合 Spring Cloud 可以做微服务化的 agent 平台。前端展示可以用 Gradio 快速搭原型生产环境建议用 React 或 Vue 自己写。我个人的建议是新手先用 Python LangChain 跑通一个最小可用 agent理解每个模块的作用之后再根据实际需求决定是否换技术栈。不要一上来就追求企业级架构那样很容易在配置环境阶段就放弃。4.2 最小可用 agent 的代码实现下面是一个用 Python 实现的极简 agent 示例包含工具调用和记忆功能。这段代码你可以直接复制运行只需要把 API Key 换成你自己的。import json from openai import OpenAI client OpenAI(api_keyyour-api-key, base_urlyour-base-url) # 定义工具 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气。当用户询问天气时使用此工具。参数 city 为城市名称。, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ] # 模拟工具执行 def execute_tool(name, args): if name get_weather: return f{args[city]}今天晴气温 25 度 return 未知工具 # 对话记忆 messages [ {role: system, content: 你是一个智能助手可以调用工具帮助用户解决问题。} ] def chat(user_input): messages.append({role: user, content: user_input}) response client.chat.completions.create( modeldeepseek-chat, messagesmessages, toolstools ) msg response.choices[0].message if msg.tool_calls: for tool_call in msg.tool_calls: result execute_tool(tool_call.function.name, json.loads(tool_call.function.arguments)) messages.append(msg) messages.append({role: tool, content: result, tool_call_id: tool_call.id}) response client.chat.completions.create(modeldeepseek-chat, messagesmessages) msg response.choices[0].message messages.append(msg) return msg.content print(chat(北京今天天气怎么样))这段代码虽然简单但已经包含了 agent 的核心循环接收输入、LLM 决策、工具调用、结果反馈、生成回复。你可以在这个基础上逐步添加更多工具、加入向量记忆、增加规划模块。4.3 工具设计的五个原则工具设计是 agent 开发中最容易被低估的环节。我总结了五条原则都是实际项目中验证过的单一职责一个工具只做一件事。不要设计一个“万能工具”什么都能干那样 LLM 根本不知道怎么选。描述详尽前面说过了描述要包含使用场景、参数说明、返回格式。错误友好工具执行失败时返回的错误信息要能让 LLM 理解并决定下一步而不是直接抛异常。幂等优先尽量设计成重复调用不会产生副作用的工具这样 agent 重试时不会出问题。数量克制一次给 LLM 的工具不要超过 10 个太多了它会选择困难。如果确实需要很多工具用分组或路由的方式解决。4.4 规划模块的实现思路规划模块让 agent 能把“帮我策划一场团建活动”这种模糊任务拆解成“确定人数→选择场地→安排交通→预订餐饮→发送通知”这样的步骤序列。实现方式主要有两种一种是ReAct 模式让 LLM 在每一步都输出“思考→行动→观察”的循环另一种是Plan-and-Execute 模式先让 LLM 生成完整的计划再逐步执行。我实测下来ReAct 更适合步骤少、需要灵活调整的任务Plan-and-Execute 更适合步骤多、依赖关系明确的任务。你也可以把两者结合先用 Plan-and-Execute 生成大框架每个步骤内部用 ReAct 执行。5. 企业级 AI agent 平台的架构与落地5.1 为什么企业需要自己的 agent 平台直接用开源框架搭一个 agent 不难但企业场景下你会遇到一堆开源方案解决不了的问题多个部门要用同一个 agent 但权限不同怎么办agent 调用的内部 API 需要统一鉴权怎么办调用量大了怎么限流和计费出了事故怎么追溯和审计这些问题决定了企业必须有一个统一的 agent 平台而不是让每个团队各自为战。5.2 基于 Spring Cloud Spring AI 的平台架构如果你在 Java 技术栈的企业里我推荐这套架构方案网关层用 Spring Cloud Gateway 做统一入口负责鉴权、限流、路由。Agent 编排层用 Spring AI 的 ChatClient 和 Function Calling 能力构建 agent 核心每个 agent 作为一个独立的微服务注册到 Nacos。工具服务层把企业内部的各种能力数据库查询、工单系统、CRM、ERP封装成标准的工具服务通过 Feign 或 Dubbo 暴露接口。记忆存储层短期记忆用 Redis长期记忆用 Milvus 或 PgVector。可观测层用 Micrometer Prometheus Grafana 监控 agent 的调用量、响应时间、工具调用成功率等指标。这套架构的好处是每个 agent 可以独立部署、独立扩缩容工具服务可以复用权限控制集中在网关层。我们给一家制造企业落地这套方案的时候从立项到第一个 agent 上线用了大概六周时间。5.3 Agent 与 PLC 编程的结合案例这个场景可能很多人没想过但确实是我做过的一个很有意思的项目。传统 PLC 编程需要工程师手动写梯形图或结构化文本门槛高、效率低。我们做了一个 agent工程师用自然语言描述控制逻辑比如“当传送带上有物料且光电传感器触发时机械臂抓取并放到指定位置”agent 自动生成对应的 PLC 代码框架工程师只需要审核和微调。这个 agent 的核心难点在于PLC 编程有严格的语法和安全规范LLM 生成的代码不能直接下发到设备必须经过仿真验证。我们的做法是让 agent 生成代码后自动调用仿真工具跑一遍测试用例通过后才输出给工程师。这个“生成→验证→修正”的循环就是典型的 agent 反思机制。5.4 多智能体协作的开发规范当一个任务复杂到单个 agent 搞不定的时候就需要多个 agent 协作。比如软件开发场景可以拆成产品经理 agent、架构师 agent、程序员 agent、测试 agent。但多 agent 系统有个大坑通信开销会指数级增长。我见过一个项目五个 agent 互相聊天聊了 200 轮还没开始干活。我的经验是多 agent 协作一定要有明确的角色边界和通信协议。每个 agent 只负责自己领域内的事输出格式必须结构化由一个“协调者 agent”负责调度和汇总。另外agent 之间的通信内容要精简不要传递完整的对话历史只传关键结论和必要上下文。6. 新手学习 AI agent 的路线与资源6.1 分阶段学习路线我带过几个新人总结出一条比较靠谱的学习路线第一阶段1-2 周理解 LLM 的基本原理和 API 调用方式能写 prompt 让模型完成简单任务。这个阶段不需要碰 agent 框架。第二阶段2-3 周学习 Function Calling 机制手动实现一个带工具调用的对话机器人。推荐用 OpenAI 或 DeepSeek 的 API 练手。第三阶段3-4 周引入 LangChain 或 Spring AI实现带记忆和规划的完整 agent。同时学习向量数据库的基本用法。第四阶段持续研究多 agent 协作、agent 评估、agent 安全等进阶话题参与开源项目或自己做一个完整的产品。6.2 关于“AI agent book 下载”这件事很多人搜这个关键词我理解大家想找系统性的学习资料。我的建议是优先看官方文档和开源项目的源码书的更新速度跟不上这个领域的变化。LangChain 的官方文档、Spring AI 的参考指南、OpenAI 的 Function Calling 文档这三个加起来比市面上大多数书都管用。如果你确实需要书找 2024 年之后出版的之前的基本可以忽略了。6.3 面试中常被问到的 agent 问题我作为面试官问过也听过不少 agent 相关的面试题。高频问题包括agent 和 LLM 的区别是什么考察基础概念你怎么设计 agent 的记忆系统考察架构能力工具调用失败时 agent 应该怎么处理考察异常处理思路多 agent 系统中如何避免死循环考察实战经验你怎么评估一个 agent 的好坏考察评估体系认知最后一个问题最难因为 agent 的评估不像传统模型有明确的准确率指标。我的回答思路是从任务完成率、工具调用准确率、平均执行步数、用户满意度四个维度综合评估并且要针对具体场景设计测试用例集。7. 实际开发中踩过的坑与排查技巧7.1 常见问题速查表问题现象可能原因排查方法解决方案agent 不调用工具直接回答工具描述不清晰或 prompt 未引导检查工具描述和 system prompt优化工具描述在 prompt 中明确要求先查工具工具调用参数错误参数 schema 定义不严谨打印 LLM 返回的调用 JSON补充参数示例和格式说明agent 陷入循环规划模块没有终止条件查看执行日志中的步骤序列设置最大步数限制增加反思判断记忆检索不相关向量化质量差或检索策略不当检查 embedding 模型和检索结果换更好的 embedding 模型调整检索条数响应速度慢工具串行调用或 LLM 推理慢分析各环节耗时并行化独立工具调用换更快的模型7.2 三个血泪教训第一个教训不要迷信框架。我早期用 LangChain 的时候遇到问题就去翻源码结果发现很多问题出在我自己的设计上框架只是背了锅。后来我养成了一个习惯任何框架先花半天时间把它最核心的 200 行源码读一遍理解它的抽象逻辑再开始用。第二个教训日志要打全。agent 的执行链路很长LLM 的输入输出、工具的调用参数和返回结果、每一步的耗时这些都必须记录。我现在的项目里每个 agent 执行都会生成一个 trace ID所有环节的日志都关联这个 ID排查问题时一查到底。第三个教训安全边界要提前划。agent 能调用工具就意味着它能产生真实影响。我见过一个 agent 因为工具权限没控制好把测试环境的数据库给清了。所以任何有副作用的工具都必须加确认机制和权限校验不能让 agent 自主决定执行。7.3 性能优化的几个实用技巧缓存 LLM 响应对于相同或相似的输入缓存 LLM 的输出能省不少钱和时间。工具并行调用如果 agent 需要同时查天气和查航班这两个工具调用可以并行执行。流式输出对于长文本生成用流式输出提升用户体验。模型分级简单任务用小模型复杂任务用大模型成本能降一半以上。8. 这个方向接下来还能怎么玩AI agent 这个方向变化太快了我每个月都能看到新的框架、新的产品、新的玩法。但有些底层的东西是不变的对业务的理解、对工具的封装能力、对异常的处理经验这些才是真正拉开差距的地方。工具会过时框架会迭代但一个能把复杂业务拆解成 agent 可执行流程的人永远稀缺。如果你现在刚开始学我的建议是别贪多先把手头的一个小场景做透。比如帮自己自动整理会议纪要、自动回复常见邮件、自动生成周报这些场景足够简单但能让你把 agent 的核心循环跑通。跑通之后再逐步加记忆、加工具、加规划一步步来。我见过太多人一上来就想做“通用 agent”结果三个月过去了还在调 prompt。最后分享一个我最近在用的调试技巧给 agent 加一个“思考日志”模式让它每一步决策都输出一段解释文字说明为什么选这个工具、为什么这么拆任务。这个日志不展示给最终用户只在开发调试时打开。我靠这个功能定位了好几个隐藏的逻辑 bug比单纯看输入输出有效得多。 AI Agent 开发实战：从 LLM 到企业级 Agent 平台架构与落地
1. 从一堆热搜词里我看到了 AI agent 的真实全貌最近后台收到不少私信问的都是同一类问题“AI agent 到底是个啥和 DeepSeek 这种大模型是什么关系”“我想学 AI agent 开发该从哪下手”“企业里用 Java 能不能搞 agent 平台”这些问题凑在一起其实指向了一个很明确的信号AI agent 已经从概念炒作期进入了工程落地期大量开发者、产品经理、企业技术负责人都在找一条能走得通的路。我自己从 2023 年下半年开始系统性地做 agent 相关的项目从最早的“套壳对话机器人”到后来的多智能体协作系统再到给传统企业做 PLC 编程辅助的 agent 工具链踩过的坑比写过的代码还多。这篇文章不打算给你讲什么“AI agent 是未来”这种正确的废话而是把我在实际项目里验证过的架构思路、开发流程、工具选型、避坑经验全部摊开来讲。无论你是刚听说 AI agent 的新手还是已经在做企业级 agent 平台的老手应该都能从里面找到对自己有用的东西。先给一个最直白的定义AI agent 是一个能自主感知环境、做出决策、调用工具、执行动作并最终完成目标的软件系统。注意这里的几个关键词——自主、决策、工具、执行。这四样东西缺一个它就不算真正的 agent只能算一个“会聊天的模型接口”。很多人把 DeepSeek、GPT 这类大语言模型直接叫做 agent这是不准确的。大模型是 agent 的“大脑”但光有大脑没有手脚、没有记忆、没有工具它什么都干不了。下面我会把这个关系彻底讲清楚。2. AI agent、LLM、AI 模型到底谁是谁2.1 用一家公司来类比这三者的关系我习惯用一家公司来打比方这样最好理解。AI 模型是公司里那个知识渊博但只会动嘴的顾问你问他什么他都能答但他不会自己去查资料、不会发邮件、不会操作 Excel。LLM大语言模型是 AI 模型里专门处理语言文字的那一类比如 DeepSeek、通义千问、文心一言这些它们的核心能力是理解和生成自然语言。而AI agent是给这位顾问配了一个完整的执行团队——有秘书帮他记事情记忆模块、有助理帮他查资料工具调用、有项目经理帮他拆任务规划模块、有质检员帮他检查结果反思模块。顾问只负责出主意真正把事办成的是整个团队。所以当有人问“DeepSeek 属于哪个”的时候答案很明确DeepSeek 是一个 LLM是 AI 模型的一种它可以作为 AI agent 的核心推理引擎但它本身不是 agent。你可以把 DeepSeek 装进一个 agent 系统里让它当大脑但你还得给它配上记忆、工具、规划这些组件它才能变成一个真正的 agent。2.2 一张表把概念彻底理清概念本质核心能力典型代表能否独立完成任务AI 模型数学函数的集合模式识别、预测图像分类模型、推荐模型否LLM基于 Transformer 的大规模语言模型语言理解与生成DeepSeek、GPT、Claude否只能生成文本AI agent以 LLM 为推理核心的完整系统感知、规划、工具调用、执行AutoGPT、LangChain Agent、企业自研平台是这张表建议你存下来面试的时候被问到“agent 和 LLM 有什么区别”直接按这个逻辑答基本不会出错。我在面试别人的时候最怕听到“agent 就是更聪明的 LLM”这种回答说明他根本没做过实际项目。2.3 为什么这个区分如此重要因为混淆概念会直接导致技术选型错误。我见过一个团队老板说“我们要做一个 AI agent 来自动处理客服工单”结果技术负责人直接调了一个大模型的 API写了个 prompt 让模型输出处理方案然后就没有然后了。这个系统上线后模型只能“建议”怎么处理但没法真正去查订单、改状态、发通知。这就是把 LLM 当成了 agent少了工具调用和执行环节。正确的做法是LLM 负责理解工单内容并决定调用哪个工具agent 框架负责实际调用工单系统的 API 完成操作最后再把结果反馈给 LLM 生成回复。整个链路走通才叫 agent。3. 一个 AI agent 的骨架里到底装了什么3.1 四大核心模块缺一不可不管你是用 LangChain、Spring AI 还是自己从零手写一个完整的 AI agent 系统一定包含这四个模块推理核心Brain通常就是一个 LLM负责理解输入、做出决策、生成输出。选型时重点看它的函数调用Function Calling能力这是 agent 能否调用工具的关键。记忆系统Memory分短期记忆和长期记忆。短期记忆就是当前对话的上下文长期记忆通常用向量数据库存储历史经验和知识需要的时候检索出来。工具集Toolsagent 能调用的外部能力比如搜索引擎、数据库查询、API 调用、代码执行器、文件读写等。工具的设计质量直接决定 agent 的能力边界。规划与反思Planning Reflectionagent 把大任务拆成小步骤的能力以及在执行过程中发现错误后自我纠正的能力。这是区分“初级 agent”和“高级 agent”的分水岭。3.2 记忆模块的设计细节记忆这块我想多说几句因为很多新手做的 agent 是“金鱼记忆”——聊完就忘。短期记忆的实现相对简单就是把对话历史按 token 数截断后塞进 prompt。但长期记忆就复杂了你需要决定什么信息值得存存成什么格式什么时候检索检索多少条我的经验是长期记忆不要什么都存。我试过把所有对话都存进向量库结果检索出来的内容噪音极大反而干扰了 agent 的判断。后来改成只存三类信息用户的明确偏好比如“我喜欢简洁的回答”、任务执行的成功经验比如“处理这类工单要先查订单状态”、以及重要的实体信息比如“客户 A 的账号是 XXX”。这样检索精度大幅提升。3.3 工具调用的实现原理工具调用的底层机制其实不复杂。你在定义工具的时候实际上是在告诉 LLM“我这里有几个函数它们的名字、参数、功能描述如下。”当 LLM 判断需要调用某个工具时它会输出一个结构化的调用请求通常是 JSONagent 框架解析这个 JSON执行对应的函数再把结果返回给 LLM。整个过程就像你给一个外包同事发了一份“可调用服务清单”他需要什么就按格式申请你帮他执行完再把结果给他。注意工具的描述文字非常关键。我踩过的坑是工具描述写得太简略LLM 经常选错工具或者传错参数。后来我把每个工具的描述都写成“什么场景下用、参数格式是什么、返回什么结果”三段式调用准确率从 60% 提升到了 90% 以上。4. 从零搭建一个 AI agent 的完整实操流程4.1 环境准备与技术栈选型如果你是 Python 技术栈推荐 LangChain 或 LlamaIndex 作为基础框架向量数据库用 Chroma 或 MilvusLLM 可以用 DeepSeek 的 API性价比高或者本地部署开源模型。如果你是 Java 技术栈Spring AI 是目前最成熟的选择配合 Spring Cloud 可以做微服务化的 agent 平台。前端展示可以用 Gradio 快速搭原型生产环境建议用 React 或 Vue 自己写。我个人的建议是新手先用 Python LangChain 跑通一个最小可用 agent理解每个模块的作用之后再根据实际需求决定是否换技术栈。不要一上来就追求企业级架构那样很容易在配置环境阶段就放弃。4.2 最小可用 agent 的代码实现下面是一个用 Python 实现的极简 agent 示例包含工具调用和记忆功能。这段代码你可以直接复制运行只需要把 API Key 换成你自己的。import json from openai import OpenAI client OpenAI(api_keyyour-api-key, base_urlyour-base-url) # 定义工具 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气。当用户询问天气时使用此工具。参数 city 为城市名称。, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ] # 模拟工具执行 def execute_tool(name, args): if name get_weather: return f{args[city]}今天晴气温 25 度 return 未知工具 # 对话记忆 messages [ {role: system, content: 你是一个智能助手可以调用工具帮助用户解决问题。} ] def chat(user_input): messages.append({role: user, content: user_input}) response client.chat.completions.create( modeldeepseek-chat, messagesmessages, toolstools ) msg response.choices[0].message if msg.tool_calls: for tool_call in msg.tool_calls: result execute_tool(tool_call.function.name, json.loads(tool_call.function.arguments)) messages.append(msg) messages.append({role: tool, content: result, tool_call_id: tool_call.id}) response client.chat.completions.create(modeldeepseek-chat, messagesmessages) msg response.choices[0].message messages.append(msg) return msg.content print(chat(北京今天天气怎么样))这段代码虽然简单但已经包含了 agent 的核心循环接收输入、LLM 决策、工具调用、结果反馈、生成回复。你可以在这个基础上逐步添加更多工具、加入向量记忆、增加规划模块。4.3 工具设计的五个原则工具设计是 agent 开发中最容易被低估的环节。我总结了五条原则都是实际项目中验证过的单一职责一个工具只做一件事。不要设计一个“万能工具”什么都能干那样 LLM 根本不知道怎么选。描述详尽前面说过了描述要包含使用场景、参数说明、返回格式。错误友好工具执行失败时返回的错误信息要能让 LLM 理解并决定下一步而不是直接抛异常。幂等优先尽量设计成重复调用不会产生副作用的工具这样 agent 重试时不会出问题。数量克制一次给 LLM 的工具不要超过 10 个太多了它会选择困难。如果确实需要很多工具用分组或路由的方式解决。4.4 规划模块的实现思路规划模块让 agent 能把“帮我策划一场团建活动”这种模糊任务拆解成“确定人数→选择场地→安排交通→预订餐饮→发送通知”这样的步骤序列。实现方式主要有两种一种是ReAct 模式让 LLM 在每一步都输出“思考→行动→观察”的循环另一种是Plan-and-Execute 模式先让 LLM 生成完整的计划再逐步执行。我实测下来ReAct 更适合步骤少、需要灵活调整的任务Plan-and-Execute 更适合步骤多、依赖关系明确的任务。你也可以把两者结合先用 Plan-and-Execute 生成大框架每个步骤内部用 ReAct 执行。5. 企业级 AI agent 平台的架构与落地5.1 为什么企业需要自己的 agent 平台直接用开源框架搭一个 agent 不难但企业场景下你会遇到一堆开源方案解决不了的问题多个部门要用同一个 agent 但权限不同怎么办agent 调用的内部 API 需要统一鉴权怎么办调用量大了怎么限流和计费出了事故怎么追溯和审计这些问题决定了企业必须有一个统一的 agent 平台而不是让每个团队各自为战。5.2 基于 Spring Cloud Spring AI 的平台架构如果你在 Java 技术栈的企业里我推荐这套架构方案网关层用 Spring Cloud Gateway 做统一入口负责鉴权、限流、路由。Agent 编排层用 Spring AI 的 ChatClient 和 Function Calling 能力构建 agent 核心每个 agent 作为一个独立的微服务注册到 Nacos。工具服务层把企业内部的各种能力数据库查询、工单系统、CRM、ERP封装成标准的工具服务通过 Feign 或 Dubbo 暴露接口。记忆存储层短期记忆用 Redis长期记忆用 Milvus 或 PgVector。可观测层用 Micrometer Prometheus Grafana 监控 agent 的调用量、响应时间、工具调用成功率等指标。这套架构的好处是每个 agent 可以独立部署、独立扩缩容工具服务可以复用权限控制集中在网关层。我们给一家制造企业落地这套方案的时候从立项到第一个 agent 上线用了大概六周时间。5.3 Agent 与 PLC 编程的结合案例这个场景可能很多人没想过但确实是我做过的一个很有意思的项目。传统 PLC 编程需要工程师手动写梯形图或结构化文本门槛高、效率低。我们做了一个 agent工程师用自然语言描述控制逻辑比如“当传送带上有物料且光电传感器触发时机械臂抓取并放到指定位置”agent 自动生成对应的 PLC 代码框架工程师只需要审核和微调。这个 agent 的核心难点在于PLC 编程有严格的语法和安全规范LLM 生成的代码不能直接下发到设备必须经过仿真验证。我们的做法是让 agent 生成代码后自动调用仿真工具跑一遍测试用例通过后才输出给工程师。这个“生成→验证→修正”的循环就是典型的 agent 反思机制。5.4 多智能体协作的开发规范当一个任务复杂到单个 agent 搞不定的时候就需要多个 agent 协作。比如软件开发场景可以拆成产品经理 agent、架构师 agent、程序员 agent、测试 agent。但多 agent 系统有个大坑通信开销会指数级增长。我见过一个项目五个 agent 互相聊天聊了 200 轮还没开始干活。我的经验是多 agent 协作一定要有明确的角色边界和通信协议。每个 agent 只负责自己领域内的事输出格式必须结构化由一个“协调者 agent”负责调度和汇总。另外agent 之间的通信内容要精简不要传递完整的对话历史只传关键结论和必要上下文。6. 新手学习 AI agent 的路线与资源6.1 分阶段学习路线我带过几个新人总结出一条比较靠谱的学习路线第一阶段1-2 周理解 LLM 的基本原理和 API 调用方式能写 prompt 让模型完成简单任务。这个阶段不需要碰 agent 框架。第二阶段2-3 周学习 Function Calling 机制手动实现一个带工具调用的对话机器人。推荐用 OpenAI 或 DeepSeek 的 API 练手。第三阶段3-4 周引入 LangChain 或 Spring AI实现带记忆和规划的完整 agent。同时学习向量数据库的基本用法。第四阶段持续研究多 agent 协作、agent 评估、agent 安全等进阶话题参与开源项目或自己做一个完整的产品。6.2 关于“AI agent book 下载”这件事很多人搜这个关键词我理解大家想找系统性的学习资料。我的建议是优先看官方文档和开源项目的源码书的更新速度跟不上这个领域的变化。LangChain 的官方文档、Spring AI 的参考指南、OpenAI 的 Function Calling 文档这三个加起来比市面上大多数书都管用。如果你确实需要书找 2024 年之后出版的之前的基本可以忽略了。6.3 面试中常被问到的 agent 问题我作为面试官问过也听过不少 agent 相关的面试题。高频问题包括agent 和 LLM 的区别是什么考察基础概念你怎么设计 agent 的记忆系统考察架构能力工具调用失败时 agent 应该怎么处理考察异常处理思路多 agent 系统中如何避免死循环考察实战经验你怎么评估一个 agent 的好坏考察评估体系认知最后一个问题最难因为 agent 的评估不像传统模型有明确的准确率指标。我的回答思路是从任务完成率、工具调用准确率、平均执行步数、用户满意度四个维度综合评估并且要针对具体场景设计测试用例集。7. 实际开发中踩过的坑与排查技巧7.1 常见问题速查表问题现象可能原因排查方法解决方案agent 不调用工具直接回答工具描述不清晰或 prompt 未引导检查工具描述和 system prompt优化工具描述在 prompt 中明确要求先查工具工具调用参数错误参数 schema 定义不严谨打印 LLM 返回的调用 JSON补充参数示例和格式说明agent 陷入循环规划模块没有终止条件查看执行日志中的步骤序列设置最大步数限制增加反思判断记忆检索不相关向量化质量差或检索策略不当检查 embedding 模型和检索结果换更好的 embedding 模型调整检索条数响应速度慢工具串行调用或 LLM 推理慢分析各环节耗时并行化独立工具调用换更快的模型7.2 三个血泪教训第一个教训不要迷信框架。我早期用 LangChain 的时候遇到问题就去翻源码结果发现很多问题出在我自己的设计上框架只是背了锅。后来我养成了一个习惯任何框架先花半天时间把它最核心的 200 行源码读一遍理解它的抽象逻辑再开始用。第二个教训日志要打全。agent 的执行链路很长LLM 的输入输出、工具的调用参数和返回结果、每一步的耗时这些都必须记录。我现在的项目里每个 agent 执行都会生成一个 trace ID所有环节的日志都关联这个 ID排查问题时一查到底。第三个教训安全边界要提前划。agent 能调用工具就意味着它能产生真实影响。我见过一个 agent 因为工具权限没控制好把测试环境的数据库给清了。所以任何有副作用的工具都必须加确认机制和权限校验不能让 agent 自主决定执行。7.3 性能优化的几个实用技巧缓存 LLM 响应对于相同或相似的输入缓存 LLM 的输出能省不少钱和时间。工具并行调用如果 agent 需要同时查天气和查航班这两个工具调用可以并行执行。流式输出对于长文本生成用流式输出提升用户体验。模型分级简单任务用小模型复杂任务用大模型成本能降一半以上。8. 这个方向接下来还能怎么玩AI agent 这个方向变化太快了我每个月都能看到新的框架、新的产品、新的玩法。但有些底层的东西是不变的对业务的理解、对工具的封装能力、对异常的处理经验这些才是真正拉开差距的地方。工具会过时框架会迭代但一个能把复杂业务拆解成 agent 可执行流程的人永远稀缺。如果你现在刚开始学我的建议是别贪多先把手头的一个小场景做透。比如帮自己自动整理会议纪要、自动回复常见邮件、自动生成周报这些场景足够简单但能让你把 agent 的核心循环跑通。跑通之后再逐步加记忆、加工具、加规划一步步来。我见过太多人一上来就想做“通用 agent”结果三个月过去了还在调 prompt。最后分享一个我最近在用的调试技巧给 agent 加一个“思考日志”模式让它每一步决策都输出一段解释文字说明为什么选这个工具、为什么这么拆任务。这个日志不展示给最终用户只在开发调试时打开。我靠这个功能定位了好几个隐藏的逻辑 bug比单纯看输入输出有效得多。