周六下午两点我打开电脑打算花两个小时把AI Agent从概念变成能跑的东西。不是看帖子是真的装一个。两个小时后我面前多了一个本地部署的Agent应用它连上了DeepSeek的接口挂着几个外部工具能自己拆任务、调工具、整理结果。整个过程听起来顺实际上一半时间都耗在配置和排错上。如果你也在AI Agent这个词门口徘徊不知道它跟大模型、LLM、DeepSeek到底是什么关系也不知道从哪下手这篇就用我这两小时的经历把概念、选型、安装步骤和踩坑过程一次讲清楚。1. 先给你看看两小时折腾出来的成果先展示结果后面讲步骤你才知道自己到底在装什么。我的最终状态是这样机器上用Docker跑着一个开源的Agent应用平台我用的是Dify做演示。平台里配置了一个模型供应商填的是DeepSeek的API Key。然后在里面建了一个叫信息小助手的Agent应用启用了三个工具网页搜索、日期时间、本地文档检索。实际测试时我问它帮我想想怎么做Python性能优化搜索两篇相关文章并整理出三个可执行建议它的输出轨迹是拆解问题、选定网页搜索工具、执行搜索、读取结果、归纳总结、给出建议。这个轨迹就是Agent和普通聊天机器人最大的区别——它不只是生成文本它会在思考之后去碰外部世界再把结果带回来继续思考。很多人都误会了一件事以为装个AI Agent是把DeepSeek这类大模型下载到本地。不是的。DeepSeek是云端API我装的是Agent应用平台平台通过API去调用DeepSeek的模型能力。这个平台给我的东西是模型接入、工具挂载、Agent编排、日志观察全都有界面可操作。相当于我搭好了一个工位DeepSeek是坐在工位上的高材生工具是它手边的设备和资料。为什么这件事值得花两小时因为跑通之后你拥有的不是一个聊天框而是一个框架。你可以不断给它加手、加工具、加记忆让它去处理具体的业务任务。这跟拿网页版ChatGPT聊两句的体验完全不是一回事。2. 开始之前必须掰扯清楚LLM、大模型、Agent到底谁是谁2.1 一个能记住的类比LLM是大脑Agent是完整的打工人三个词天天见但很多人分不清。大模型是个总称泛指用海量数据训练出来的模型。LLM是大语言模型是大模型里最主流的一支特点是主要处理文本。DeepSeek就属于LLM跟GPT系列、Llama这些是同类物种。LLM本身只能说话不能做事。你问它问题它给你一段看起来合理的文字但它不会去查数据库、不会发请求、不会操作文件。Agent就不一样了。Agent是以LLM为推理核心外面包了一圈工程能力——规划任务、调用工具、读写记忆、根据反馈调整行动。你可以简单理解成LLM是大脑Agent是大脑加手、加电话、加会议纪要、加项目任务清单是一个完整的打工人。2.2 Agent的四件套推理、规划、工具、记忆核心推理由LLM承担。所有的理解、判断、生成都靠这一层。任务规划把大目标拆成小步骤。比如写一份周报会被拆成收集本周工作记录、整理重点、按模板输出。工具调用让Agent能真正影响外部世界。搜索网页、查数据库、发邮件、操作表格都靠工具。工具用得顺不顺手直接决定Agent的价值。记忆短期记忆是当前对话上下文长期记忆是跨会话存下来的知识技能记忆则是把你调教好的流程沉淀下来下次一键复用。2.3 DeepSeek到底是哪个一句话回答DeepSeek是LLM是模型不是Agent。DeepSeek Agent框架 工具 AI Agent应用。你去问任何一个做Agent开发的人他嘴里的用DeepSeek都是在说用DeepSeek的模型API作为Agent的推理核心而不是说DeepSeek本身就带Agent能力。用一个比喻收尾DeepSeek像新招的高材生脑子好Agent框架像工位、电脑、系统权限、项目管理流程组合起来才是一个能干活的人。2.4 会话和记忆为什么两个Agent会话之间互不相识有个挺有意思的问题Codex可以直接读取其他AI Agent会话内容吗答案是分层的。像Codex这类编程Agent它能读取当前工作目录、相关代码文件和当前会话上下文所以看起来好像记得之前的操作。但大多数Agent实例之间默认不共享记忆两个不同的Agent应用甚至同一个应用的两个会话默认也是互相隔离的。跨会话的长期记忆是要靠外部存储做的比如向量数据库、记忆服务这是架构设计问题不是模型自带的。搞清楚这个你后面设计Agent时就不会想当然。名词是什么会不会用工具举例大模型(AI Model)海量数据训练出的模型总称不会各种开源/闭源基座模型LLM(大语言模型)以文本为主的大模型不会只会生成文本DeepSeek、GPT系列、LlamaAI Agent以LLM为核心具备规划、工具、记忆的完整执行系统会Dify里建的Agent、Codex编程Agent3. 我选的安装路径Docker起一个本地Agent平台接DeepSeek API3.1 为什么这么选型先说选型逻辑免得你照着做完了不知道自己在干嘛。我没选纯代码库路线比如直接用LangChain或LangGraph从零搭。原因很现实作为入门代码路线的学习曲线太陡我两小时内根本跑不通。而Dify这类开源Agent平台把模型接入、工具挂载、Agent编排全做成界面操作新手可以先看到全貌再决定要不要深入代码。它同时支持本地部署数据在自己手里出问题能看日志生产团队以后也可以基于它的后端做二开。模型我选了DeepSeek理由更简单API价格便宜接口兼容OpenAI格式中文任务表现稳。对于装个Agent体验一下这个目标它是性价比最高的选择。如果你预算充裕换成别家的模型也不影响整体流程因为Dify这类平台已经把主流模型都做成可配置的了。3.2 几个方案的横向对比方案形态适合谁上手难度Coze云平台快速体验Agent产品能力低Dify开源可自托管想自己部署、控制数据、定制细节中LangChain/LangGraphPython框架开发者深度编排复杂逻辑高Codex等CLI编程Agent终端工具主力做代码生成和重构中Spring AIJava生态框架企业Java团队想把Agent接进现有系统中高我的建议是如果只想看看Agent能干嘛先玩云平台就行半小时就能体验如果想理解原理或者后面要做成内部工具走自托管路线更合适。这篇讲的是自托管路线。3.3 环境准备一台4核8G以上的Linux服务器或macOS电脑。Windows也能跑但坑多一些不推荐第一次就踩。装好Docker和Docker Compose。磁盘预留10G以上因为要拉好几个镜像。网络状况直接影响镜像下载时间这点要有心理准备预留10到20分钟下载时间很正常。如果你只是临时体验也可以直接用Dify的云版本省掉环境环节。但自托管能看到的东西多得多尤其是日志和容器状态排错时全靠它们。3.4 实操步骤全记录以下是我当时的时间线照着走一遍你也能复现时间动作说明16:05确认Docker环境docker version能正常输出即可16:10拉取Dify项目并启动git clone后进入目录docker compose up -d16:35打开网页端完成初始化浏览器访问http://localhost按提示设管理员账号16:40配置模型供应商进DeepSeek开放平台创建API Key回应用里填入并测试16:50创建Agent应用新建应用时选择Agent类型打开工具调用能力17:00挂载工具启用网页搜索、日期时间等工具17:15第一轮实测触发模型401报错进入排错17:30修复配置把模型名和API地址改对17:45第二轮实测跑通搜索总结完整链路17:55完善系统提示词给Agent写清角色、边界、输出格式整个安装命令本身不复杂但有两件事没人提醒的话你会卡很久一是DeepSeek的API Key要先在开放平台创建并确保账户有余额二是模型供应商配置里模型名、API地址这些字段填错了页面只会给你一个模糊的报错。这部分我单列一个章节详细讲。4. 两个小时内真正吃掉时间的是这三个坑4.1 坑一模型调用一直报401或404现象很直接应用建好了模型也选了DeepSeek但一发消息就报错。我的排查链路打开Dify的后台日志看到错误是Invalid API Key和Model Not Exist两类。不急着改平台配置先在命令行用curl直接调DeepSeek的接口同一个Key、同一个模型名试一遍。curl通了说明API Key本身没问题问题出在平台侧的填法。回到模型供应商配置发现API地址的格式不对——DeepSeek的接口地址默认是https://api.deepseek.com不需要额外加/v1而模型名我一开始填成了不带版本符号的别名实际要用deepseek-chat。改完之后重新测试通了。这条经验可以省你很多时间兼容OpenAI格式不等于所有字段都跟OpenAI一模一样。先curl验证API本身再验证平台配置能把排查范围缩小一半。以后再遇到任何模型调用失败我先做这步。4.2 坑二Agent根本不会调用工具有个更隐蔽的问题Agent建好了模型也通了但它表现得像个普通聊天框。我问现在几点它直接凭印象编了一个时间而不是去调用日期时间工具。排查链路是这样的确认应用类型。我一开始建的是聊天助手不是Agent。聊天助手默认不做工具调用只有Agent类型才会进入思考是否用工具的循环。确认模型支持Function Calling。DeepSeek的deepseek-chat模型支持但如果你用的是专门的推理模型工具调用的行为会有差异实测要验证。检查工具是否在Agent的可用范围里。平台里工具是分应用启用的光在后台配置了工具当前应用里没打开照样不生效。把工具单独测一遍。网页搜索工具本身能不能返回结果不在Agent里测直接在工具页测试。最后开日志确认一次完整请求里到底有没有tool call记录。有记录但没执行是工具问题根本没有任何tool call记录是Agent配置问题。解决起来不复杂把应用类型改成Agent重新启用工具给工具描述写清楚触发条件。但排查顺序如果反了你会把模型、平台、工具三个环节来回试很多遍。4.3 坑三Agent陷入死循环反复调用同一个失败工具这个坑最烧钱。现象是日志里同一个工具调用连续出现了6次每一次都是同样的报错Agent还是在原地打转token消耗肉眼可见地涨。根因有三个工具失败时返回的是纯文本错误模型没看懂以为网络波动就重试了。我没有设置最大迭代轮数Agent默认会一直在循环里打转。工具描述写得太模糊模型不知道该在什么条件下用、什么条件下不该用。我做了三个调整给应用设置了最大迭代次数我设的是5轮超了就主动结束并告诉用户目前无法完成工具的返回错误改成固定JSON格式类似{success: false, error: timeout}模型看到结构化错误能更快止损工具描述里加上什么时候不要用的说明比如仅在需要实时信息时使用日常闲聊不要调用。这里有一个通用的认知Agent的自由度是配置出来的默认越宽越容易失控。你以为给它挂20个工具它能干更多事实际上它光选工具、试错就可能把预算烧光。4.4 复盘两小时的时间到底去哪了环节理想耗时实际耗时说明拉取镜像和启动环境10分钟20分钟主要看网络平台初始化和建应用10分钟15分钟界面不熟悉到处看模型认证配置5分钟30分钟卡在401和模型名工具挂载与单独测试10分钟25分钟每个工具都要验一遍第一轮Agent实测5分钟20分钟发现聊天助手和Agent的区别系统提示词调优10分钟20分钟一开始写太短如果让我重新来一遍我有把握缩到40分钟先curl验证API再用平台自带的Agent模板起步只挂两个必要工具最后再调系统提示词。但第一次装这些坑基本避不开掉了才知道为什么。5. 跑通只是开始我接着做的三件事才让Agent真正能干活5.1 第一件事给Agent写一份岗位说明书跑通之后我干的第一个事是重写系统提示词。模板里自带的提示词太简单就一句你是AI助手这种Agent用起来跟裸奔差不多。我给它写了一份岗位说明书角色信息研究助手 职责根据用户问题搜索资料并整理成结论 边界不编造数据找不到就明确说找不到不确定的内容标注存疑 工具使用原则 - 先拆解问题再选择工具 - 搜索工具只用于获取外部信息 - 引用来源必须一并给出 输出格式 - 先给结论 - 再列依据 - 附上来源链接 - 最后给可选下一步为什么写这么多因为LLM面对模糊指令的默认行为是尽量把回答编得像样。你给它明确的约束等于给它设置了一个护栏幻觉率会明显下降。你在提示词里说不编造数据找不到就明说它就更倾向于告诉你查不到而不是硬编一个答案。5.2 第二件事做工具最小集不是工具越多越好挂完一个搜索工具、一个日期时间工具之后我又试着挂了五六个工具结果Agent的行为反而变差了。它会在多个工具之间犹豫甚至选错工具。后来我砍到只剩三个核心工具成功率明显回升。原则很简单每增加一个工具Agent误调用的概率就会增加一点。工具列表是给模型看的不是给人看的所以每个工具的描述要写清楚两件事什么时候用它什么时候别用它。工具名一句话描述触发条件风险级别日期时间获取当前日期与时间用户问时间、日程、时效性内容时只读低网页搜索搜索互联网公开信息用户需要外部资料、最新信息时只读低本地文档检索检索指定目录下的文档内容用户要求基于内部资料回答问题只读低我的经验是Agent起步阶段可用工具控制在3到5个以内。后面你熟悉了它的脾气再逐步加。每加一个工具都专门测一轮看它会不会在无关问题里乱调用。5.3 第三件事给高风险操作加一道人审闸门如果Agent未来要执行更重的操作比如发邮件、删除数据、调用付费API我会在架构上强制加一道人审环节。现在的Agent完全可以做到自主执行但它太自信了又太愿意动手没有审批闸门的话一个错误的工具调用可能造成不可逆的后果。具体做法不复杂在Agent的执行流程里加一个确认节点Agent生成操作计划后先停下来把计划发给用户用户点击确认后才真正执行。权限设计上遵循最小权限原则——Agent只有完成当前任务所需的最小权限而不是给它一个管理员账号随便造。这一点在Dify里可以做成对话式确认在纯代码方案里就是加一个审批函数。真要做生产级Agent这步省不掉。做完这三件事我把同一个测试任务跑了十次做小样本对比调整前大概一半次数需要我中途纠正调整后大部分任务能一次性完成token消耗也降了一些。我的体感是AI Agent这玩意儿工程化调教带来的提升往往比换一个更强的模型来得更明显。6. 用了几天之后给新入坑的人一句实在话6.1 入门顺序比天赋重要如果照着这条路线走我建议你们后面的学习顺序是先把提示词玩明白再学Function Calling的原理接着上手Agent框架然后去研究MCP和工具开发最后再碰多智能体。热搜里那些AI Agent面试题翻来覆去问的无非就是概念区别、工具调用原理、记忆设计、错误处理这些。自己装一遍再去看那些题你会有一种这题我会的踏实感因为坑你都踩过了。如果是团队做技术选型Java后端团队可以关注Spring AI它跟现有Spring生态结合得比较顺如果本身是做自动化、工业控制的可以把Agent和PLC编程结合起来研究这个方向很垂直但需求真实存在如果想快速验证产品想法先上云平台别急着自建。6.2 别追求全自动先把一件事练到稳定用几天之后我最大的体会是别一上来就追求全自动多智能体协作。那种看起来很酷的架构背后需要处理的边界条件和错误恢复非常多。新人最容易掉进去的坑是想让Agent一口气完成十个步骤结果中间任何一步出错整个链条就断掉。我的做法是反过来先让Agent稳定完成一件小事——比如搜索资料并整理成固定格式的摘要。这一件事调稳了再逐步加工具、加步骤、加长期记忆。你可以把每次成功的多步骤流程沉淀成技能或模板下次一键调用这就是为什么技能和记忆会成为Agent开发里的高频词。最后分享一个实在的小技巧给Agent的提示词里加上一句如果你无法完成任务请明确说出来。这句话看着简单实际能帮你省掉大量token和大量无意义的死循环——因为它给了模型一个体面的退出出口。两小时装好Agent只是入场券真正的门槛在怎么约束它、调教它、让它稳定地做事。先把一匹野马驯成干活的马再去想怎么组一支马队这个顺序错不了。