从去年开始带团队做企业级 AI Agent 落地前前后后踩了无数坑也沉淀了一套从架构设计到部署运维的完整打法。这个系列终于完结了趁热把这一年多的实战经验整理出来。这篇文章不聊虚的概念直接讲清楚 Agent 到底是什么、和普通 AI 模型的区别在哪、企业落地应该选什么技术栈、架构怎么拆、以及那些真正会让你熬夜的坑。1. 先搞清楚Agent、LLM 和 AI 模型到底是什么关系很多刚接触这领域的朋友第一反应就是问Agent 是不是就是 GPT DeepSeek 是不是 Agent 这是个特别典型的概念混淆。1.1 三层关系模型是大脑LLM 是大脑的高级形态Agent 是会用大脑干活的完整人我习惯用一个类比来解释把 AI 模型想象成一个刚毕业的高材生。AI 模型是这位高材生的知识储备和思维方式本身他读过很多书有很强的推理能力但他只是坐在那里你不问他他不会主动干活。LLM大语言模型是 AI 模型里特指以自然语言为核心能力的那一类比如 DeepSeek、GPT、Claude它们擅长理解文本、生成文本、写代码、做总结。DeepSeek 就属于这一层它是一个 LLM 底座本身不是 Agent。Agent智能体是给这位高材生配上了眼睛感知环境、手脚调用工具、记事本记忆系统、工作计划表任务规划甚至还可以给他配上团队多 Agent 协作。这时候他才真正能独立完成一项完整的工作。所以 DeepSeek 是 Agent 的大脑但不等于 Agent。Agent 是拿着 LLM 当核心外面套了一层又一层能力的完整系统。1.2 企业场景为什么不能只用 LLM必须上 Agent我见过很多企业一开始的玩法很简单把内部知识库整理一下接一个 LLM 做问答。但用三个月就会发现纯 LLM 问答根本解决不了实际问题。举个例子财务部门想要一个助手来对账。纯 LLM 能做什么它只能告诉你根据财报文本这个月应收是多少但真实场景是要它自己去连数据库查明细、比对 Excel 里的流水、发现异常主动调用风控模型、最后生成一份带图表的分析报告甚至推送给相关负责人。这一连串动作纯 LLM 干不了因为它没有执行能力不知道去哪拿数据不知道怎么操作你的业务系统。Agent 的出现就是来解决这个问题的。它不是聊天机器人而是能拆解任务、能调用系统、能操作工具、能记住上下文、能自主完成任务闭环的数字员工。企业用它省的是人力提的是流程效率这才是它的核心价值。2. 企业级 Agent 的架构拆解不只是套一个 API那么简单我在网上看到很多 Agent 入门教程教你用 LangChain 写个 ReAct 循环调 OpenAI 就完事了。但企业级应用完全不是这个量级它对可控性、安全性、可观测性的要求极高。2.1 Agent 的五个核心组成结构以我们落地的经验一个生产级别的 Agent 必须包含以下五个部分缺一不可。第一大模型核心LLM Core这是 Agent 的推理引擎负责理解意图、生成计划、产出答复。企业选型时不能盲目追最新最强的模型要考虑数据合规、部署成本、响应速度。实测下来很多内部业务场景用开源模型微调比直接调云端 API 更稳尤其涉及敏感数据时私有化部署是硬需求。第二感知层PerceptionAgent 要能看到外部世界。这个感知包括三类一是接收用户输入的自然语言指令二是通过 API 读取企业系统的数据三是通过连接器对接数据库、文档库、消息中间件等基础设施。没有感知Agent 就是个瞎子。第三规划层Planning这是 Agent 的大脑皮层。拿到任务后Agent 要把大目标拆解成可执行的小步骤。业界常用的策略有 ReAct推理行动、Plan-and-Execute先规划后执行以及思维链等。我强烈建议企业场景用 Plan-and-Execute先让 Agent 把完整计划列出来给用户确认再执行。为什么因为可控性用户可以中途纠偏Agent 不用一条路走到黑。第四记忆层Memory记忆分为短期记忆和长期记忆。短期记忆就是对话上下文这个好理解长期记忆包括两类一类是业务知识库用向量数据库存储通过检索增强生成的方式来调用另一类是实体记忆比如记录用户的偏好、历史操作习惯、项目的状态。记忆系统设计得好不好直接决定 Agent 好不好用。第五行动层Action/ToolsAgent 调用外部工具就靠行动层。这里就涉及现在特别火的 MCPModel Context Protocol模型上下文协议它本质上是定义了一套标准化的工具调用协议让 Agent 能像插 USB 一样即插即用地接入各种工具。比如让它调用企业内部的工单系统 API、发邮件、操作数据库、执行运维脚本。2.2 Skill、Memory、MCP、Harness四个让你面试加分的概念这几个词在热词里反复出现说明关注度非常高我一个个讲清楚。Skill技能Skill 是 Agent 对外提供的一组能力封装。比如数据分析技能下面是写 Python 代码、调 SQL、画图表、代码审查技能下面是读 diff、跑静态检查、生成评审意见。Skill 的本质是把复杂的业务流程固化成 Agent 可以调用的能力模块这样可以做到高内聚、低耦合不同的 Agent 复用同一套 Skill。Memory记忆Memory 我上面提到了但企业落地还有一个关键点就是记忆的权限管理。比如一个客服 Agent它可以记住用户的收货地址但不能把 A 用户的订单信息泄露给 B 用户。所以记忆层一定要做隔离和权限校验。MCP模型上下文协议MCP 是 2024 年后端开发圈特别火的词。它解决了 Agent 和工具之间通信标准化的痛点。以前你接一个内部系统就要写一套自定义的 function calling 对接逻辑现在只要工具方实现了 MCP ServerAgent 端直接通过 MCP Client 连接即可。Spring AI 3.0 已经内置了 MCP 支持企业级 Java 技术栈的用户可以直接走 Spring AI 的 MCP 客户端实现实测接入数据库、文件系统、第三方 API 都非常顺滑。Harness运行框架Harness 是承载 Agent 运行的大框架它管的是 Agent 的生命周期包括运行环境、执行上下文、状态管理、异常处理、安全审计这些技术底座。你可以把它理解成 Agent 的操作系统像 LangChain、Semantic Kernel、Spring AI 扮演的就是这个角色。企业里自研 Harness 的情况也很多因为要集成公司自己的权限、审计、监控体系框架直接套用往往不够灵活。2.3 单 Agent 还是多 Agent企业落地怎么选多智能体Multi-Agent这两年是个热词但我对企业的建议是能单就不要多除非业务天然有分工。单 Agent 适合任务链路清晰、上下文共享需求高的场景比如做智能客服、智能文档分析一个 Agent 从头做到尾状态好管理排错也容易。多 Agent 则适合横向分工明确的场景比如一个项目交付 Agent拆成需求分析 Agent开发 Agent测试 Agent各自独立运行、通过消息队列协作。多 Agent 的难点在于任务编排与通信机制设计控制不好容易上下文混乱、重复执行。我们在实际项目里会用 BPMN 工作流引擎结合 Agent 节点来做编排既有工作流的确定性又有 Agent 的智能性这是一个比较成熟的企业级解法。3. 企业级技术选型Java 技术栈怎么做 Agent先交代下我们的团队背景主力是 Java所以技术选型从一开始就是围绕 JVM 生态来的。相关热搜里也有很多人问Spring AI 开发 AgentSpring Cloud Spring AI 开发自己的 Agent这块我可以好好讲讲。3.1 为什么选 Spring AI 而不是 LangChain选型这件事我们内部吵过好几轮最终统一选了 Spring AI 为主框架理由有三个。一是团队技术栈匹配度高。我们团队对 Spring Boot 太熟了Spring AI 完全基于 Spring 生态设计学习成本极低不用为了 Agent 去学一套全新的 Python 技术栈。二是企业级集成能力强。Spring AI 对数据库连接、事务管理、消息队列、安全认证这些企业能力的整合好到离谱这正好是 LangChain 的短板。三是 MCP 支持完善。Spring AI 3.0 对 MCP 的原生支持已经很成熟对接外部工具链路很顺。当然我不是否定 LangChain它生态丰富、上手快适合快速原型验证。但如果要搞企业级生产系统尤其是 Java 为主的团队Spring AI 真的更合适。3.2 基于 Spring AI 搭建企业 Agent 平台的四个关键技术点第一个是模型接入层的抽象。Spring AI 支持 OpenAI、Ollama、通义千问、DeepSeek 等主流模型通过统一的 ChatModel 接口来封装业务代码不用绑定具体厂商后续换模型或者做多模型路由都非常方便。第二个是 Prompt 模板管理。企业应用对输出质量要求高Prompt 需要反复调优。Spring AI 提供了类似 Thymeleaf 的模板引擎把 Prompt 做成模板配合变量注入这样产品经理也能参与调优不用每次改代码。第三个是 OutputParser输出解析。这个特别重要Agent 的输出如果不做结构化解析下游系统根本没法用。Spring AI 支持将 LLM 输出解析为 Java POJO 对象我们用它统一对接业务系统实测解析准确率明显高于直接塞 JSON 给下游。第四个就是 MCP 工具接入。以给 Agent 加一个数据库查询工具为例直接用 Spring AI 的 MCP 客户端能力引入依赖在配置里声明工具端点声明一个 ToolCallback BeanAgent 就能开始调用这个工具了。整个流程不到一小时就能跑通。3.3 多 Agent 编排用 Spring Cloud 思路做分布式 Agent我们做多 Agent 时直接借用了 Spring Cloud 那套微服务思想。每个 Agent 是一个独立 Spring Boot 服务注册到 Nacos 上Agent 之间的协作通过 Feign 调用加消息队列实现这样天然拿到了服务发现、负载均衡、熔断降级的能力。举一个实际案例我们做过一个智能运维 Agent拆成了三个子 Agent感知 Agent负责对接监控系统持续收集服务器指标、日志异常。诊断 Agent接收感知 Agent 上报的异常调用知识库和日志分析工具定位根因。处置 Agent根据诊断结果调用自动化脚本执行修复操作涉及高风险变更时停车等待人工审批。这三个 Agent 之间完全通过内部 API 协作每一个都有独立的资源配额和权限范围。这样做的好处是故障隔离感知 Agent 挂了不会影响处置 Agent运维可以单独扩容非常贴合生产环境的要求。4. 实操全流程从 0 到 1 完成一个企业级 Agent光讲理论没有说服力我完整跑一遍一个典型的企业智能助理开发流程让大家看看每一步是怎么落地的。4.1 需求拆解与方案设计阶段我们接到一个需求给某制造企业做安全生产巡检助手。他们过去靠安全员每天手动翻巡检记录、查隐患照片、填写整改报告工作量巨大而且经验全在老安全员脑子里新人很难上手。我们把这个需求拆成三个核心能力智能问答安全员可以用自然语言查询历史巡检记录、这个车间过去一个月有哪些隐患未整改。隐患识别上传现场照片Agent 自动识别安全隐患未戴安全帽、消防通道堵塞等。报告生成自动汇总巡检数据、隐患情况、整改建议生成日报周报。这三个能力对应三个 Skill文档检索问答 Skill、图像识别 Skill、数据聚合报告 Skill。这里要注意不是所有能力都让 Agent 自己生成图像识别这块我们直接调了一个独立的视觉模型服务Agent 只负责把图片传给该服务并接收识别结果这样模型职责单一效果更稳。4.2 核心开发与关键代码实现技术栈是 Spring Boot 3 Spring AI PostgreSQL Milvus 向量库。第一步搭建工程引入 Spring AI 依赖配置好模型端点。dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId version3.0.0/version /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-mcp-client/artifactId version3.0.0/version /dependency这里注意Spring AI 的版本迭代很快API 变动比较大对照官方文档用对应版本极其重要不然跑起来一堆坑。第二步定义 Agent 的核心 Service绑定 ChatModel 和工具调用。用 ChatClient 来构建对话链路以 Fluent API 的方式编写代码非常简洁Service public class SafetyInspectAgent { private final ChatClient chatClient; public SafetyInspectAgent(ChatClient.Builder builder) { this.chatClient builder .defaultSystem(你是一名安全生产巡检专家负责协助安全员完成巡检任务回答必须严谨 涉及隐患整改时给出可操作的建议不确定的信息必须明确说明。) .defaultTools(new QueryInspectionTool(), new ImageRecognitionTool()) .build(); } public String chat(String userMessage) { return chatClient.prompt() .user(userMessage) .call() .content(); } }这段代码看起来简单但有几个细节很关键。defaultSystem 里我写了很明确的角色定义和行为约束这是企业级 Agent 输出的第一道质量防线。defaultTools 声明了该 Agent 可以调用的工具有哪些这是权限控制的第一道闸门Agent 只能用它被赋予的工具。第三步实现工具方法。Spring AI 3.0 里用 Tool 注解来声明一个可调用工具方法参数会被自动注入给 LLM 做函数调用决策。Component public class QueryInspectionTool { private final JdbcTemplate jdbcTemplate; public QueryInspectionTool(JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } Tool(description 根据日期范围查询车间隐患整改记录) public ListMapString, Object queryHazards( String startDate, String endDate, String workshopId) { return jdbcTemplate.queryForList( SELECT * FROM hazard_records WHERE create_time BETWEEN ? AND ? AND workshop_id ? AND is_rectified false , startDate, endDate, workshopId); } }这个 Tool 注解我很喜欢它把复杂的方法调用直接暴露成 Agent 技能连 SQL 权限都天然通过数据库账号做了隔离。工具返回结构要尽量扁平字段名要直白因为 LLM 看得懂你的列名你写 meterId 它知道是设备编号吗不一定你直接写 meter_code 反而更清晰。第四步配置 MCP 服务器来接入外部系统。以对接企业微信通知为例我们实现了 MCP Server让 Agent 能够自动推送巡检异常给安全员spring: ai: mcp: client: enabled: true connections: - name: wecom-notify url: http://mcp-server-wecom.internal:8080/sse配置了 MCP 连接之后Agent 通过工具调用推送消息就非常简单方法的写法和上面的 Tool 一致底层通信交由 MCP 协议处理。4.3 部署与上线从开发环境到生产环境的差异开发环境你只需要一台能跑大模型的机器加一份配置就够了可生产环境完全是另一码事。我们生产环境的部署架构是K8s 集群上跑 Agent 业务服务GPU 节点部署推理服务Milvus 单独集群存储向量数据Redis 做短期记忆缓存Nacos 做配置中心和服务发现。这里有个特别注意的点是超时控制。LLM 推理时间不可控你不能让用户在前端一直转圈所以我们在网关层统一设置请求超时使用 SSE 流式响应用户这样体验更好也绕开了 HTTP 网关的请求超时限制。还有一个点是模型网关的负载均衡和多模型切换。生产环境不能把 LLM 的地址写死我们用自研模型网关封了一层支持按业务线路由到不同的模型。比如内部知识问答走内部私有化小模型复杂推理任务走云端大模型这样成本控制非常好比全用顶级模型省了大约 60% 的 token 费用。另外一个重要环节是服务隔离与权限管控。Agent 要访问数据库、发消息、操作运维脚本每次工具调用都有可能造成实际影响所以在生产环境我们给每个 Agent 申请专属的数据库账号和最小权限的 API Key所有工具调用记录都会落审计日志这个点在国内企业落地时尤其重要安全部门会重点审查。4.4 企业级多 Agent 的 Spring Cloud 编排配置刚才提到多 Agent 编排这里补充下实际配置示例。我们使用 Spring Cloud OpenFeign 让子 Agent 之间互相调用以上面的智能运维 Agent为例处置 Agent 要调用诊断 Agent 的接口。FeignClient(name diagnosis-agent, path /api/agent/diagnosis) public interface DiagnosisAgentClient { PostMapping(/analyze) DiagnosisResult analyze(RequestBody DiagnosisRequest request); }通过 Nacos 服务发现诊断 Agent 的实际地址会被自动解析不需要手动维护 IP。配合 Sentinel 做熔断降级当某个 Agent 服务异常时上游 Agent 不再死等它快速降级返回兜底方案。这里有一个重要的设计经验Agent 之间的调用一定要设定明确的输入输出协议也就是定义好 DTO字段含义写清楚别用 Map 传参。因为 Agent 之间通信本来就多一层不确定性协议再模糊排查问题的时候你真的会疯掉。5. 企业级 Agent 一年实战的避坑指南这部分是花钱买来的教训每一句话都值得多看一遍。5.1 提示词并没有你想的那么万能很多人觉得 Agent 效果不好就是提示词没写好疯狂调 Prompt结果调了一个月还是不稳定。我要泼一盆冷水提示词工程的边际收益是有上限的真正的效果瓶颈往往在数据质量和工具设计上。如果你让 Agent 访问的数据库表字段含义不明、工具返回的数据残缺不全再好的 Prompt 都会被误导。我们后期把主要精力放在了数据清洗、建立统一的字段字典、优化工具返回结果的简洁性上效果提升非常显著。记住一个原则给 Agent 提供的工具要像给新员工发操作手册一样描述务必精确清晰说明输入输出、适用场景同时要控制工具数量不是越多越好工具多了模型的选择会出问题。5.2 监控和可观测性比算法还重要Agent 是概率系统它今天输出正常不代表明天不抽风。生产环境一定要建立完善的可观测体系否则出了问题连怎么排查都不知道。我们做了三层监控第一层是基础指标包括请求量、延迟、token 消耗、工具调用成功率第二层是运行轨迹追踪也就是每次 Agent 会话里的每一步操作如思考链、中间结果、工具调用参数、返回结果全程记录第三层是结果质量评估用另一个模型定期对 Agent 的输出打分比如是否合规、是否跑题、是否有明显幻觉。我强烈建议从第一天就把这三层监控建起来不要等出了问题再补否则你会发现自己根本没法判断 Agent 的行为是否正确。5.3 安全与合规必须前置最后一条也是最重要的一条。企业级 Agent 涉及的数据往往很敏感权限管理一定要做到最小可用。我们在一个试点项目里出现过一次 Agent 因权限配置过宽读取了非授权部门的经营数据虽然只是测试阶段但把整个部门都吓出一身冷汗。现在我们的规范是三条硬性要求第一Agent 的每个工具调用都走独立的权限校验不能复用人的账号权限第二所有涉及敏感数据查询的指令必须记录完整审计日志第三高风险操作如删除数据、发起支付、修改配置必须加入人工审批节点Agent 只负责发起和准备不能直接执行。6. 学习路径与面试经验想进这个领域的可以参考这是个更新的领域很多人关心怎么入行以及面试会问什么。结合我带人的经验给出一条比较高效的学习路径。6.1 零基础入门的三个月自修路径第一个月先把基础补扎实。搞清楚 LLM 的基本原理至少动手调用过一次主流模型的 API亲手跑通一个 RAG 检索增强生成的例子。不需要把 Transformer 数学推导搞透但一定要理解 Token、Embedding、上下文窗口、向量检索这些核心概念。第二个月进入 Agent 框架实操。选择 Spring AI 或者 LangChain 其中一个把官方文档里的 Agent 示例跑一遍理解 ReAct 循环和工具调用的机制然后自己动手做一个个人助理级的 Agent能调用搜索、计算器、日历这类简单工具就可以。第三个月做企业级项目。可以从AI 客服助手或企业知识库问答入手把多轮对话、长期记忆、权限控制、日志审计这些企业级要求都加上走完一遍从需求到上线的完整流程。到这里你已经具备在企业里独立交付一个中小型 Agent 项目的能力了。6.2 面试高频题与答题思路请解释 Agent 和 LLM 的区别建议用我开头的高材生类比先谈 LLM 是大脑再谈 Agent 是给大脑加上了感知、规划、记忆、行动能力的完整系统。Agent 如何调用外部工具讲清楚 function calling 的机制模型输出结构化工具调用指令框架负责实际执行并把结果回传给模型再结合 MCP 的发展讲一下标准化的意义。如何保证 Agent 输出结果的准确性有几个层面数据层面保证检索质量模型层面做结果校验和幻觉检测流程层面引入人工审批节点工程层面建立评估集做回归测试。在生产环境你如何设计一个 Agent 平台考察的是架构能力。从模型接入层、能力层Memory、MCP、Skill、编排层、应用层、监控治理层五个维度去回答再结合团队实际选型展开比如 Java 团队用 Spring AI Nacos K8s。说了这么多最后分享一个我自己最大的体会企业级 AI Agent 真正的难点不是模型选得有多强而是工程化能力有多扎实。一个能稳定上线的 Agent背后是数据治理的细致、工具设计的严谨、监控体系的完备共同支撑的。这个领域日新月异但把基本功打牢、把工程意识建立起来无论技术怎么变你都能从容应对。
