从零搭建AI Agent平台：让LLM变成能干活的企业数字同事

上个月帮一家创业公司搭AI Agent平台对方CTO第一句话就是“我手底下有几十个会用ChatGPT的员工但还没有一个能自己干活的数字同事。”这句话我记到现在。很多人把AI Agent当成聊天机器人的升级版但真正的Agent平台本质上是给企业造“数字同事”的流水线工厂。我刚接触这个概念时也被绕晕过LLM、AI模型、DeepSeek、Agent、Agent平台这几个词一会儿一个说法网上教程东一榔头西一棒子。所以这次我把自己从0到1搭建AI Agent平台的完整过程整理成文从概念拆解、架构设计、代码实现到部署落地和避坑经验一次讲完。文章适合谁看一类是在学Agent开发的工程师想搞明白这套东西到底怎么落地另一类是刚搞清楚DeepSeek和LLM是什么、想再往前迈一步的同学。看完你至少能把一个最小可用的Agent平台跑起来并且知道企业级落地要补哪些东西。1. 先把概念捋清楚模型、LLM、Agent和平台的关系1.1 它们到底谁是谁这四个词的关系我用一个交通工具的类比来解释比任何教科书定义都好使。AI模型是“发动机”的最底层概念泛指所有通过数据训练出来的算法实体比如图像识别模型、语音合成模型、大语言模型都是AI模型。LLM是“已经装上变速箱的汽油发动机”本质上是一种专门处理语言任务的AI模型特点是不只会背答案还能根据上下文生成新内容。你现在听到的DeepSeek、GPT系列、Claude都属于LLM这一层。Agent则是“整台车”。它包含LLM这个发动机还多了方向盘任务规划、轮子工具调用、油箱记忆能自己决定开去哪、怎么避开堵车、什么时候进加油站。DeepSeek只是Agent脑子里那块“算命的料”Agent则是一个能自己动手干活的完整系统。Agent平台又是什么是“整条汽车生产线”。单台车再好一天也就造几辆平台负责把设计图纸Agent定义、零件供应链工具注册、质检线评测反馈、售后体系日志审计全部标准化。所以“当Agent有了工厂人人都能造同事”这句话说的就是用平台的思路批量生产Agent每个Agent都像一个有分工、有技能、有记忆的虚拟员工。我整理了一张表方便你速记概念类比典型例子核心能力AI模型发动机各种神经网络模型感知、识别、生成LLM装好的发动机DeepSeek、GPT系列语言理解与生成Agent整车AutoGPT、自研Agent自主决策、调用工具、记忆Agent平台汽车流水线Dify、自研平台批量管理、编排、治理Agent1.2 单个Agent和Agent平台的本质区别早期很多人搭Agent就是一个Python脚本调LLM的API给一段PromptLLM返回答案完事。这种“单个Agent”更像一个会聊天的接口玩具距离“同事”差了十万八千里。真正的分水岭出现在两个场景。第一个场景是Agent需要协作。比如一个售前客服Agent接到客户问题后要先去订单系统查历史记录再调库存系统看发货时间最后把结果整理成回复。这还只是单个Agent串多个工具。如果任务再复杂一点比如“生成一份竞品分析报告”需要一个Agent去爬数据一个Agent做数据分析一个Agent写初稿一个Agent校对格式四个Agent分头干活再汇总单个Agent模式完全管不过来。第二个场景是Agent需要治理。企业里Agent数量一多谁调的什么模型、花了多少Token、调用了哪些敏感接口全都要有记录和权限管控。没有平台层的统一网关任何一个Agent里硬编码的API Key泄露都够你喝一壶。所以我的建议很直接如果你只是学习而搭一个Agent脚本就够了但凡是想让Agent在业务里真正干活的从第一天就要按平台的思路来设计哪怕第一版只写两百行代码也要把工具注册、记忆接口、日志这些底座打上。后面扩功能时你会发现这一步省了多少返工的力气。2. 设计Agent平台先画好“工厂流水线”的蓝图2.1 Agent内部长什么样五层结构在你开始写代码前先要理解一个Agent内部的组成结构。我习惯把它拆成五层这是从多个开源Agent项目里总结出来的通用骨架。感知层接收用户输入可能是聊天消息、HTTP请求、工单事件这层负责把各种来源的输入统一成标准格式。规划层是Agent的“大脑”由LLM驱动负责理解任务、拆解步骤、决定下一步调哪个工具。行动层是Agent的“手”实际执行工具调用比如查数据库、发HTTP请求、操作文件。记忆层是Agent的“记事本”短期记忆保存当前对话上下文长期记忆存在向量数据库里供随时检索。反馈层是Agent的“复盘机制”执行完一个工具后判断结果是否合理不合理就换一条路重试。你想想一个优秀的同事是怎么干活的接到任务先确认需求感知心里列个计划规划遇到不懂的查资料、问人行动工具想起之前做过类似的事能参考记忆干完了复盘哪里能改进反馈。Agent的设计逻辑和这完全一样。2.2 技术选型框架对比与选择逻辑画完蓝图就要选工具。市面上的Agent开发框架五花八门我实测过的几个主流方案按场景分个类LangChain和LangGraph是目前Python生态最主流的Agent框架。LangChain起步早、组件全适合快速验证LangGraph在编排复杂多Agent流程上更灵活适合状态机和循环逻辑。缺点是学习曲线陡峭封装层次多出了问题不好排查。Dify和FastGPT属于“Agent低代码平台”路线自带界面、工作流编排、知识库管理后端只要接入模型API和数据库就行。适合非技术团队搭内部工具或者想快速出原型的中后台产品。缺点是深度定制受限特殊场景跑不动。Spring AI是Java生态的后起之秀。如果你的团队是Spring Cloud背景想在企业级Java应用里集成AgentSpring AI比硬套LangChain舒服得多后面我会专门讲。自研框架适合什么情况我见过一些大厂的大规模场景通用框架的抽象挡不住性能优化和特殊控制需求最后都会走向自研。但你要从0到1起步我强烈不建议第一版就自研先用成熟框架把业务逻辑跑通等瓶颈出现再动手不迟。我的选型逻辑就三条团队技术栈熟什么用什么业务越标准越用低代码平台、越特殊越用框架第一版目标永远是“跑通最小闭环”不是为了炫技。2.3 平台的五个核心模块缺一个都别上线平台层和单个Agent最大的区别在于它要管的东西从“一个Agent的逻辑”变成了“一群Agent的生态”。我归纳下来至少有五个核心模块是平台必备的。模型接入网关统一封装各种LLM的API调用支持多模型切换、密钥管理、限流和成本统计。工具注册中心类比微服务里的注册中心每个Agent能调用的函数在这里登记包含工具ID、入参Schema、鉴权方式、调用权限。没有这一层Agent的工具调用会变成一团乱麻。任务编排引擎决定多个Agent之间怎么协作是串行链路、并行分发还是主从式的规划-执行模式都在这一层配置。记忆与知识库短期会话缓存用Redis这类内存数据库长期的企业文档知识库用向量数据库比如Chroma、Milvus、Weaviate。观测与审计记录每个Agent的每次决策、工具调用、Token消耗、耗时和错误信息方便排查和做成本控制。我有一个心得如果你只打算自己搭个练手项目至少也要把模型接入和工具注册两个模块做出来。只调API聊天不调用工具的Agent练不了什么真本事。3. 动手实操搭一个最小可用的Agent平台这一章我会带你从零写一个不依赖LangChain等重型框架的最小Agent平台。自己写一遍核心的“感知-规划-行动”循环比直接上框架更能理解原理。等你理解了再换框架就得心应手了。3.1 环境准备我用的环境是Python 3.11一个DeepSeek的API KeyRedis用Docker起一个。DeepSeek是我目前测下来性价比很高的LLM选择接口兼容OpenAI格式代码写起来几乎是无缝的。装依赖只需要两个库pip install openai redis chromadbopenai官方SDK可以直接调DeepSeek的API因为它的接口兼容OpenAI格式。Chroma用来做长期记忆的向量存储先用它起步数据量大了再换Milvus。3.2 核心代码造一个会调用工具的Agent我先定义工具注册中心。工具的本质就是一个函数加上一段描述描述告诉LLM这个工具是干什么的、参数是什么。TOOL_REGISTRY { calculate: { description: 计算数学表达式的结果参数为字符串表达式例如 (3 5) * 2, func: lambda expr: str(eval(expr, {__builtins__: {}}, {})) }, get_weather: { description: 查询某个城市的天气情况参数为城市名称, func: lambda city: f{city} 今天晴气温 24-30 摄氏度东南风 3 级 } }看清楚没有工具注册中心做的事情就是登记“这个Agent会什么技能”。每加一个新技能就是往这个表里加一项。这和你给新员工办工位、开通系统权限是一个道理。接下来是Agent的主循环。核心思路就是让LLM看“当前有哪些工具可用”和“用户的问题是什么”然后决定是调用工具还是给出最终答案。一次完整的Agent运行流程是这样的把系统提示词、用户的请求、历史对话一起发给LLMLLM返回一段JSON结果包含下一步动作如果是调用工具执行工具函数把结果追加到对话里回到第1步如果是最终答案返回给用户流程结束用代码实现就是这样import json from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com/v1 ) SYSTEM_PROMPT 你是一个数字同事名叫小智。 当你需要查询数据或执行操作时必须使用工具。 工具调用结果请严格按如下JSON格式输出 {action: 工具名, args: 参数} 当你已经拿到结果、可以回答用户时输出 {action: finish, result: 最终回答} def run_agent(user_input, historyNone): history history or [] messages [{role: system, content: SYSTEM_PROMPT}] messages.extend(history) messages.append({role: user, content: user_input}) max_steps 5 for _ in range(max_steps): response client.chat.completions.create( modeldeepseek-chat, messagesmessages, response_format{type: json_object}, temperature0.3 ) content response.choices[0].message.content parsed json.loads(content) if parsed.get(action) finish: return parsed[result] tool_name parsed[action] tool_args parsed.get(args, ) if tool_name not in TOOL_REGISTRY: messages.append({ role: user, content: f工具 {tool_name} 不存在请从可用工具中选择 }) continue tool_result TOOL_REGISTRY[tool_name][func](tool_args) messages.append({ role: user, content: f工具返回结果: {tool_result} }) return 抱歉我尝试了多次仍未完成这个任务。这就是一个最简Agent核心。试试调用“帮我算一下(12 3) * 5等于多少”它会走一遍“规划-调用工具-整理结果”的完整循环。这里有一个安全坑要提醒上面代码里的eval只是演示用。生产环境一定要自己写一个安全的四则运算解析器或者用sympy这类库做表达式解析直接eval用户输入等于把服务器门钥匙交给黑客。3.3 给Agent装上长期记忆接入RAG只会调用工具的Agent像个记性不好的新员工——聊完就忘。要让Agent能“记得”之前聊过的内容并在回答时参考企业文档就需要把记忆层和知识库加上。我用Chroma实现一个最简单的记忆工具。先把企业文档切块、向量化、存进向量库再把这个“查文档”的能力注册为Agent的一个工具。import chromadb from openai import OpenAI # 假设已经有一批文档切片这里用两个示例片段演示 documents [ 公司年假政策入职满一年可休5天满三年可休10天, 报销流程先在OA系统提交申请附发票照片财务会在3个工作日内审批, 远程办公规定每周三和周五可申请居家办公需提前一天报备 ] client OpenAI(api_keysk-你的key, base_urlhttps://api.deepseek.com/v1) chroma_client chromadb.Client() collection chroma_client.get_or_create_collection(company_knowledge) def embed_text(text): resp client.embeddings.create( modeldeepseek-embedding, input[text] ) return resp.data[0].embedding for idx, doc in enumerate(documents): collection.add( ids[str(idx)], embeddings[embed_text(doc)], documents[doc] )然后注册一个search_docs工具def search_docs(query): results collection.query( query_embeddings[embed_text(query)], n_results2 ) return .join(results[documents][0]) TOOL_REGISTRY[search_docs] { description: 在公司的知识库中搜索与问题相关的文档片段参数为搜索关键词, func: search_docs }现在问Agent“公司年假怎么休”它就会先调用search_docs查到年假政策再基于工具返回的结果回答你。这个模式就是现在各大企业广泛使用的RAG检索增强生成本质上是把私域知识注入Agent的工具调用链路绕开了LLM训练数据里没有企业私有信息的问题。3.4 部署成平台服务核心Agent跑通后我用FastAPI把Agent包成一个HTTP服务用Docker Compose一键起一套最小平台一个Agent API服务、一个Redis缓存短期会话、一个Chroma做知识库。先写FastAPI接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): user_input: str session_id: str default app.post(/agent/chat) def chat(req: ChatRequest): # 实际项目里这里会从Redis读历史传入run_agent的history参数 result run_agent(req.user_input) return {session_id: req.session_id, reply: result}Docker Compose编排version: 3.8 services: agent-api: build: . ports: - 8000:8000 environment: - REDIS_URLredis://redis:6379/0 depends_on: - redis redis: image: redis:7-alpine ports: - 6379:6379到这里“能跑的Agent平台”就算从0到1搭起来了。但这个平台距离“能用的Agent平台”还有一段路下一章专门讲企业级落地要补的硬功夫。4. 企业级落地从“能跑”到“能用”的关键升级4.1 给Java团队的建议Spring AI与Spring Cloud集成如果你所在团队的技术栈是Java和Spring Cloud那更适合用Spring AI来开发Agent而不是绕道Python服务。Spring AI借鉴了LangChain的分层设计但深度整合了Spring生态依赖注入、配置管理、熔断限流这些能力都是现成的。一段最简的Spring AI工具定义大致长这样Component public class WeatherTool implements ToolCallback { Override public String getName() { return getWeather; } Override public String getDescription() { return 查询指定城市的天气; } Override public JsonElement getJsonSchema() { return JsonParser.parseString( {type:object,properties:{city:{type:string}}} ); } Override public String call(JsonElement jsonElement) { String city jsonElement.getAsJsonObject().get(city).getAsString(); return weatherService.query(city); } }配合Spring Cloud的OpenFeign、网关、配置中心你可以把Agent作为一个微服务注册进去让其他服务通过Feign调用Agent能力。我们团队用这个方案把Agent嵌进了已有的权限体系Token计量和审计接的是公司统一日志平台扩展性比单独挂一个Python服务好很多。4.2 多Agent协作与任务编排单Agent能干活但没法处理复杂业务。我遇到过一个需求自动生成项目周报。这活至少分三步拉取本周代码提交记录、总结重点变更、按照指定模板生成周报。如果拆成多个Agent协作分工就很清晰。一个常见模式是“规划器-执行器”模式。规划Agent负责把用户的大任务拆成多个子任务分发给多个执行Agent最后汇总结果。这个模式的代码实现核心思路是一个编排循环先让规划Agent给出子任务清单然后依次或并行调用子Agent最后把各Agent的结果合并交给汇总Agent。在LangGraph里做这种编排比手写状态机轻松得多它天然支持有环路的图结构还能设置节点之间的状态传递和条件分支。我个人经验是两种以上Agent协作、且存在条件跳转时就别手写了直接用LangGraph这类编排框架别在状态管理上重新发明轮子。4.3 打通现有系统Jenkins、数据库与工业场景Agent的价值很大程度来自它和公司已有系统的集成程度。我实测过最顺手的是把Jenkins封装成一个Agent工具让Agent能帮你触发构建、查看流水线状态。比如注册一个jenkins_trigger工具内部调用Jenkins API触发指定Job构建。这样你问Agent“帮我跑一下测试环境的构建”Agent就能理解你的意图、调用工具、返回构建链接。这比固化的聊天机器人灵活太多。还有热搜词里提到的Agent与PLC编程。在工业自动化场景Agent目前最稳妥的落地点是做PLC代码的辅助生成和审查而不是直接下发控制指令。实际项目里Agent生成梯形图或结构化文本代码必须先经过资深工程师的人工审批再进入仿真验证环节这是绝对的安全红线。自动化程度再高也要保留人工兜底。4.4 企业平台必备的治理能力我在多个企业项目里踩出来的经验是平台能跑起来只算第一步真正决定能不能长期用的是治理能力。至少四件套必须有。权限管理管的是“哪个角色能用哪些Agent、能调哪些工具”。成本管控管的是模型调用预算、Token消耗实时统计和超限熔断。版本治理管的是Prompt和工具函数的版本管理Agent行为变化要可追溯、可回滚。审计日志管的是每个Agent的完整决策轨迹出问题时能一步步回溯是哪次工具调用导致的结果异常。这四件套在开源社区方案里往往需要自己补。如果团队资源有限我建议先用日志系统简单记全量Trace成本管控用网关层做总Token上限权限管好工具层就行版本治理可以放在下一期再做。5. 常见问题排查与避坑实录5.1 高频问题速查表我把实际搭建和运维过程中遇到的高频问题整理成了一张速查表每个问题后面都附了排查思路问题现象常见原因解决思路Agent陷入循环不返回结果缺少最大迭代限制加max_steps参数超时强制返回兜底话术工具调用参数老是格式错误Prompt里的工具描述不够明确每个工具补充参数示例最好加Few-shot样例回答内容张冠李戴知识库检索到了无关片段调整向量检索的top_k和相似度阈值加rerankAgent不听系统提示词约束提示词在长对话中被稀释每次请求都重新注入系统提示词压缩历史消息Token消耗涨得飞快历史消息无限制累积对旧消息做摘要或裁剪只保留最近N轮多个Agent互相等待编排流程存在循环依赖加超时熔断规划Agent负责兜底调度这张表是运维排障的第一张地图。遇到问题先定位到具体环节再对症下药。5.2 死循环的规避这是新手最容易踩的坑。Agent在调用工具后如果工具返回的结果不理想它会反复尝试同一个方向直到达到我设置的max_steps才停下来。不加这个限制的后果是一个简单的推理题能让你的Token账单在几分钟内爆炸。我踩过的真实案例是Agent在算一笔复杂的报销金额时调用计算器工具返回的结果总是不符合预期它一遍遍重试同一公式执行了47次工具调用。从那以后我定了一个规矩所有Agent默认最大步数5宁可让它提前认怂说“我搞不定”也不能让它无脑烧钱。规避死循环还有一个技巧在工具返回结果不佳时给LLM追加一条提示“如果上述结果不合理尝试换个思路或换个工具”。这能引导Agent自我纠偏而不是原地打转。5.3 Agent面试和学习中的高频疑问因为Agent热度高最近不少朋友问我面试怎么准备。这里把自己辅导别人总结的三个高频问题思路分享一下。“Agent和LLM的区别是什么”别背定义用生产视角说LLM是完成单一语言任务的模型Agent是围绕LLM构建的、具备任务规划、工具调用和记忆能力的完整应用系统。比如DeepSeek本身是LLM基于它做的自动客服机器人是Agent。“如果让你从零搭一个Agent平台你怎么设计”这个题考的是架构能力。按上面提到的模型接入、工具注册、任务编排、记忆检索、观测审计五模块回答重点讲清楚为什么需要工具注册中心和各模块职责划分。“遇到过Agent效果不稳定的问题吗怎么排查的”这题考实战经验。可以举例Prompt调优、工具Schema优化、最大步数限制以及如何通过日志追踪定位到具体环节。有真实踩坑案例会非常加分。6. 适合新手练手的三个小项目6.1 个人知识库问答Agent把你自己的笔记、收藏的文章、读书笔记倒进Chroma用我上面给的RAG方案做一个个人知识库问答Agent。这个项目练的是数据清洗、切块策略、向量检索参数调优。做完你会明白为什么RAG效果时好时坏——切块大小、重叠长度、检索top_k甚至embedding模型的选择都会影响最终效果。6.2 自动写周报的Agent做一个能对接Git提交记录和待办事项的周报Agent。核心练的是多工具协同拉数据工具、总结工具、模板渲染工具。我建议往里面加一个人工确认的步骤Agent生成周报初稿后由你确认再发送这也符合Agent落地的产品安全观。6.3 多Agent客服工单Agent搭两个Agent一个负责理解用户问题并判断问题类型另一个负责从知识库检索方案并生成回复。中间用一个编排节点串联。这个项目练的是多Agent协作和任务编排能让你直观体会到单Agent和多Agent在业务场景中的差别。这三个项目难度递增做完基本上就有了Agent平台开发的核心手感。不要贪多一个项目跑通再进下一个。我在实际操作中最大的体会是别一开始就追求复杂框架。把第一个Agent当成一个刚入职的新同事来带先给它讲清楚工作边界System Prompt、能用的工具Tool Registry、该记的事Memory再让它从小任务开始上手。平台能不能跑起来往往取决于这类基础细节做没做好而不是用了多牛的框架和模型。后面有机会我再展开讲讲LangGraph的多Agent编排细节和Spring AI的企业集成方案。如果你也在搭Agent平台欢迎交流你的踩坑经验。