下午刷到一条技术热帖标题挺直接“花两小时装了 ai agent。。。”。底下评论齐刷刷在问两小时真的够用哪个模型Agent 和普通的 AI 对话到底差在哪我本来也只是想看个热闹结果越看越手痒索性把周六下午拿出来做了个极限测试从零开始不买课不看长篇文档目标只是把一个能自己调工具、有记忆、能接外部服务的 Agent 跑起来。最后我不仅跑通了还顺手把里面许多模糊的概念都理清了。这里我把完整过程记下来包括踩过的坑。这篇东西不是那种“半小时做出AI应用”的夸张教程它更像是一个真正操作过的人把两小时里冒出来的问题都摊开讲清楚DeepSeek 到底算什么、Agent 和 LLM 怎么分工、MCP 和 memory 要接在哪一层、放到企业级 Java 或 PLC 编程场景里又该注意什么。为了让不同基础的读者都能看懂我会先把几个最容易混淆的概念拆开再进入实操记录最后给出一份排查清单。如果你正打算入门 AI Agent这篇应该能帮你省掉不少试错时间。1. 安装前先想清楚Agent、LLM、AI模型的边界在哪里很多人在搭 Agent 之前根本没搞清楚自己手里拿的是哪块积木。看到社区里有人说“我用了 DeepSeek 搭 Agent”就以为 DeepSeek 本身就是 Agent看到别人说“接个 MCP 就有记忆了”又把工具协议和记忆混为一谈。两小时能跑通是一回事跑通之后能不能改、能不能维护是另一回事。所以拿到代码之前先把这块地基打牢。1.1 三层结构模型、LLM 接口和 Agent 壳我用一个生活里的类比来拆AI 模型是所有智能的源头类似一个受过大量训练的行业顾问LLM 是这种模型的对外服务形态相当于顾问通过电话或邮件接活的方式Agent 则是围绕这个顾问搭起来的完整工作台包含问题拆解、调用计算器、查资料、做记录这些配套流程。严格说AI 模型是一个上层概念包含计算机视觉、语音、强化学习等很多分支。LLM 是其中以自然语言为主要输入输出的那一类模型大语言模型的缩写就是 LLM。到了 2025 年绝大多数主流模型比如 GPT 系列、Claude 系列、DeepSeek 的 deepseek-chat 和 deepseek-reasoner都属于 LLM 这一类。但你给 DeepSeek 发一句话它只能给一个回答这叫“对话”你让它自己决定先查天气、再查日历、最后订会议室并且中间每一步都调用对应工具这才叫“Agent”。Agent 不是某种新模型而是一个软件壳。这个壳里至少要包含几个部件模型入口、工具注册表、记忆存储、任务循环。模型负责生成决策工具负责执行动作记忆负责保存上下文任务循环负责把“下一步该干什么”的过程跑起来。DeepSeek 在整套架构里只是“大脑”它要挂上工具和记忆才能真正变成 Agent。理解这一点之后你会发现网上很多所谓 Agent 产品其实只是套了一层 system prompt 的聊天机器人。1.2 DeepSeek 属于哪一类它能当 Agent 的大脑吗DeepSeek 是模型不是 Agent也不自带工具调用框架。但它提供 OpenAI 兼容的 API可以用 Requests 或 OpenAI SDK 直接调用这给搭建 Agent 提供了很大便利。在我周六的实际测试里DeepSeek 的 deepseek-chat 模型在工具调用、JSON 输出和上下文理解上表现都不错。用它搭 Agent 的好处很明显API 价格便宜、中文支持好、无需本地显卡、注册即用。缺点则是它不具备 GPT-4 那类超大模型的复杂推理稳定性在工具参数很多、任务链路很长的时候需要你在提示词和上下文管理上多花心思。如果你不想用国内 API也可以换成本地部署的开源模型比如 Qwen 系列或 Llama 系列。问题是本地跑模型会占用大量 CPU/GPU 资源两小时想要跑出一个体验流畅的 Agent云 API 是更稳健的选择。所以我现在所有示例代码都以 OpenAI 兼容接口为基准你只需要改掉 base_url 和模型名称就能在不同供应商之间切换。1.3 为什么“加个 system prompt”不等于做 Agent有读者可能不理解我把“请扮演一个助手会调用工具”写进 system prompt是不是就是 Agent 了严格说不是。System prompt 只是给模型一个行为约束模型并没有真正具备执行外部动作的能力。真正区分 Agent 的是“行动闭环”模型输出一个工具调用意图代码去执行这个工具然后把结果返回给模型模型继续决策。如果只有对话没有执行整个闭环长得再像 Agent也只是聊天机器人。这个闭环也叫 Agent Loop。我在搭建时就是用一个大循环来对抗简单 API 请求不断问模型下一步调什么工具、执行、拿结果、再问。两小时内最花时间的部分不是写这个循环而是把工具参数格式整对让模型输出能被代码解析成功。2. 两小时实操从空目录到可对话可调用工具的 Agent先说明一下我的搭建目标不追求多智能体编排不搞复杂页面只要一个能在终端里对话、能调用外部工具、能记住前后文的 Agent。最终我用的是 Python 3.10 OpenAI SDK DeepSeek API外加一个简单的内存列表和两个自定义工具函数。整个流程分为四步每一步都有明确的验证点。2.1 环境准备Python 虚拟环境和 API 配置我的电脑是 Windows 11平时在本地开发用 PyCharm。周五晚上其实已经装好了 Python 3.10并用 venv 建了一个干净的环境。两小时后能跑通和环境干净有很大关系。如果你机器上还跑着别的 Python 项目强烈建议新建虚拟环境不然依赖冲突会让你在第一步就崩溃。创建环境和安装依赖的命令非常简单python -m venv .venv .\.venv\Scripts\activate # Windows source .venv/bin/activate # macOS / Linux pip install openai python-dotenv这里安装的是官方 openai 库因为 DeepSeek 提供 OpenAI 兼容接口直接用它就能访问。接下来在项目根目录创建.env文件存放 API KeyDEEPSEEK_API_KEYsk-你的key DEEPSEEK_BASE_URLhttps://api.deepseek.com/v1 DEEPSEEK_MODELdeepseek-chat用 .env 而不是直接把密钥写在代码里是为了防止不小心把密钥提交到 Git 仓库。我见过太多新手把 key 写死在脚本里结果上传 GitHub 后几分钟就被爬虫扫走。这点不是可有可无是底线。2.2 第一步用一个函数完成 LLM 对话Agent 不管多复杂最终都要回到“和模型对话”这件事上。所以第一步先用最简单的方式验证 API 通不通。以下代码可以放在llm.py里import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL), ) def chat(messages, toolsNone, tool_choiceauto): resp client.chat.completions.create( modelos.getenv(DEEPSEEK_MODEL), messagesmessages, toolstools, tool_choicetool_choice, temperature0.7, ) return resp.choices[0].message if __name__ __main__: msg chat([{role: user, content: 你好}]) print(msg.content)跑一下如果能正常输出“你好”说明网络和密钥都没问题。这里先不管 tools只想让链路通起来。需要注意的是temperature0.7对大多数任务是一个比较均衡的值如果你想让它更严谨地做工具调用可以降到 0.2 左右减少随机性。2.3 第二步把工具调用接进去这才是 Agent 和聊天机器人的分水岭要让模型能够调用工具第一步是给模型提供工具描述。工具描述不是给人类看的而是用 JSON Schema 告诉模型“这个函数叫什么、有哪些参数、各参数类型是什么”。模型会基于这些信息生成一个结构化的调用意图然后由我们代码真正执行。我这次做了两个自定义工具一个是获取当前时间一个是做四则运算。虽然看起来很简单但它们已经能证明一件事模型不再只是“说话”而是可以“动手”。工具定义写入一个tools.pydef get_current_time(): from datetime import datetime return datetime.now().strftime(%Y-%m-%d %H:%M:%S) def calculator(expression: str): return str(eval(expression)) TOOLS [ { type: function, function: { name: get_current_time, description: 获取当前系统时间返回年月日和时分秒, parameters: {type: object, properties: {}} } }, { type: function, function: { name: calculator, description: 计算数学表达式例如(1 2) * 3, parameters: { type: object, properties: { expression: {type: string, description: 数学表达式} }, required: [expression] } } } ]主循环写在agent.py里。它的逻辑只有五步拼消息、发给模型、看返回结果、如果返回想要调用工具就执行工具、然后把执行结果拼回去继续对话。我强烈建议你把这个循环挂在脑海里因为市面上再花哨的 Agent 框架底层都脱离不了这个模式import json from llm import chat from tools import TOOLS, get_current_time, calculator tool_map { get_current_time: get_current_time, calculator: lambda expression: str(eval(expression)), } def run_agent(user_input): messages [{role: user, content: user_input}] while True: msg chat(messages, toolsTOOLS) if msg.tool_calls: for tc in msg.tool_calls: fn tc.function.name args json.loads(tc.function.arguments) if fn get_current_time: result get_current_time() elif fn calculator: result calculator(args[expression]) else: result 未知工具 messages.append({ role: tool, tool_call_id: tc.id, content: str(result) }) else: print(Agent:, msg.content) break if __name__ __main__: run_agent(现在几点顺便算一下(1234)*2等于多少)这里最容易踩坑的地方是消息格式。OpenAI 兼容接口要求当模型返回 tool_calls 时代码必须回传role: tool的消息而且tool_call_id必须等于模型返回的 id。如果漏掉这个 id接口会直接报 400 错误。另一个坑是eval虽然写起来方便但真实项目里很不安全建议换成ast.literal_eval或专门的表达式解析库。2.4 第三步加记忆、加 MCP从单轮对话变成多轮协作两小时里我还做了一件事把简单的记忆加上。说到“记忆”很多人会想到向量数据库以为要接 Chroma 或 Milvus。但记忆也分短期和长期。最基础的短期记忆其实就是把历史消息放回 messages 列表里让模型能看到上下文。我在上面代码里加了一个memory列表每次用户提问先往列表里追加 user 消息模型回答后再追加 assistant 消息。这样连续对话时模型能记住你是做数学题还是查时间。对大多数轻量 Agent 来说这个程度已经够用只有当你希望 Agent 跨会话记住用户偏好或者从大量文档中检索信息时才需要引入向量库和 RAG。至于 MCP它是模型上下文协议解决的是“工具接入方式统一”的问题。在传统方式里每接一个服务就要写一套自定义调用代码而 MCP 提供标准化的 server 和 client 接口让 Agent 可以像插 USB 一样接入文件系统、数据库、浏览器等能力。我这次没有真去开发 MCP server只花 20 分钟用官方 SDK 接了一个本地文件读取服务发现它本质上就是在上面的工具循环外面再套一层协议封装。MCP、skill、memory 这三个词在热门搜索里经常一起出现很多新手误以为它们是并列的三个组件其实不是。skill 是“动作能力”比如会写代码、会算术memory 是“数据保存”比如记住上下文和偏好MCP 是“通信标准”让 skill 的接入更规范。这三者正好对应 Agent 的“四肢”“笔记本”和“插槽”。表格总结一下我这次用到的关键配置方便你照着抄配置项值说明Python 版本3.10兼容性和生态都更稳妥OpenAI SDK1.x官方库支持工具调用模型deepseek-chat性价比高工具调用稳定温度0.2 ~ 0.7工具任务建议低温度短期记忆list 存储轻量场景足够MCP 接入可选复杂工具场景建议上3. 装完之后它能干点啥真实场景拆解Agent 跑通只是开始真正让人兴奋的是它接到业务里的样子。网上流行的产品很多有个人知识库、自动写代码、企业流程审批、甚至 PLC 编程辅助。我把几个我实际见过或测试过的场景展开说顺便聊聊哪些适合用 Agent哪些现在还不太成熟。3.1 个人知识库问答最容易上手的落地方案我第一天测完 Agent 后第二个周末就把它接到了个人知识库上。思路很简单把 Markdown 笔记、PDF、网页另存为文本用 embedding 模型切块向量化存到向量数据库用户提问时先检索最相关的几个片段再把这些片段塞进 Agent 的上下文让模型基于片段回答。这个方案有几个坑。切块大小直接决定回答质量切太大容易塞入无关信息切太小又会丢失上下文。我试过 500 字、800 字、1200 字三种最后还是觉得 800 字带 200 字重叠比较稳。另外不要指望全库向量化之后就不管了知识库更新后需要重新生成 embedding 并覆盖旧数据否则 Agent 会一本正经地讲过期信息。3.2 辅助编程与研发自动化Jenkins、CI/CD 和 Agent 的搭配程序员可能是最爱折腾 Agent 的群体。我见过有人用它自动生成单元测试、自动修 Bug、自动提交 PR也有人直接把它接进 Jenkins 流水线在构建失败时让 Agent 拉取日志、定位错误、给出修复建议甚至自动把补丁推到测试分支。这里最让人担心的问题是权限边界。我测试的时候发现Agent 可以生成一个看似合理的分支名但它不知道团队实际的命名规范它能改代码但不知道哪些模块有历史包袱。所以我的习惯是Agent 只负责“建议”不负责“推送”。让它生成补丁、生成 commit message、生成测试代码最终合入由人来做。至于“Codex 能直接读取其他 AI Agent 的会话内容吗”我实测下来答案是不能。Codex 只能访问它自己工作区里的文件、终端输出和对话历史无法跨 Agent 读取另一个会话。企业里如果想做多智能体协作需要在框架层面把对话记录共享出来比如统一写到同一个数据库或用消息队列广播否则每个 Agent 都是信息孤岛。3.3 企业级 Java 场景Spring AI 和 Agent 平台化如果你们公司是 Java 技术栈那 Spring AI 是一个绕不开的名字。Spring AI 不是一个成品 Agent而是类似 Spring 生态里的一个 AI 集成层负责屏蔽不同模型 API 的差异提供 ChatClient、EmbeddingClient、VectorStore 等抽象。它和 Spring Cloud 配合起来可以很自然地嵌入到微服务体系里一个服务负责调模型另一个服务负责工具执行再有一个服务管会话状态。我见过一个企业级方案是这样设计的Java 后端把用户请求包装成统一的 Agent Task 对象投递给 Kafka由 Worker 节点消费并调用 LLM工具调用走内部 OpenAPI比如查询订单、创建工单、审批流转所有会话记录写到 ES方便审计。这个设计的好处是Agent 的决策和业务动作彻底解耦出了问题可以回放日志追责。代价是工程复杂度明显上升。企业级 Java Agent 平台不是“两小时能搭完”的水平你需要考虑模型限流、降级、权限、敏感词、多租户隔离等一系列问题。个人项目里那些“一把梭”的写法到这里基本都要推翻重来。3.4 PLC 编程等工业场景Agent 的下一个蓝海标题里有人提到“Agent 与 PLC 编程”这个方向我去年就关注过。PLC 是工业控制里最常见的控制器传统编程语言以梯形图、结构化文本为主工程师写起来非常依赖厂家的 IDE。Agent 的优势在于它能读取 IO 表、设备手册、历史程序然后生成结构化文本代码甚至自动补齐注释和报警处理逻辑。但这里有一条红线不能让 Agent 直接连接生产线做实时控制。工业现场的安全要求极高任何推理模型都可能在极端情况下给出不稳定输出。我比较看好的落地模式是Agent 先离线生成代码由电气工程师人工审核再通过仿真器验证最后才部署到 PLC。这一步把 Agent 从“执行者”降级为“辅助设计工具”既发挥了它快速生成和检索的能力又守住了安全底线。4. 避坑清单与排查技巧实录两小时里我踩了不少坑有些坑一旦踩中会浪费半小时以上。我把它们按频率和影响程度整理成清单并在每一条后面写上排查思路。新手照着这个表排查能省下大量试错时间。4.1 Agent 不调用工具先检查这三处最常见的问题是模型不调用工具反而像普通对话一样直接回答。这时先别怀疑模型智商按顺序检查三点工具 schema 是否合法消息历史中是否遗漏了tool_call_id系统提示词是否明确要求使用工具。我测试时发现如果把两个工具的 description 写得含糊比如只是“获取时间”四个字模型可能觉得不需要调用也能答于是直接编一个时间。把 description 改成“获取当前系统时间返回年月日和时分秒适合回答现在几点、今天几号等问题”之后调用准确率立刻上升。模型是需要把工具和用户意图匹配起来的描述越具体匹配越高。另外如果你用了本地开源模型它可能不支持原生的tool_calls字段只在输出文本里写“我会调用计算器……”。这时候只能靠解析文本触发工具或者换一个更懂工具调用的模型。无脑堆功能只会让代码变得脆弱。4.2 上下文爆炸和 token 费用失控两小时测试阶段用的 token 不多问题不明显可一旦跑真实业务上下文会迅速膨胀。用户多聊几轮每轮都带着所有历史记录再加上文档片段模型输入 token 轻松破万。如果你用的是按 token 计费的外部模型月底账单会非常感人。解决方法有几种一是给对话设置最大轮数超过就开启新一轮二是用滑动窗口只保留最近 N 条消息三是把长文档做成摘要或向量检索不整段塞进上下文。我自己的习惯是对每轮对话设置历史消息不超过 20 条同时对超过 3000 字的文档一律走 RAG而不是直接拼进上下文。这样既保证模型的“短期记忆”清晰也控制了成本。4.3 模型选型DeepSeek、GPT 系、开源小模型怎么挑模型选型直接决定 Agent 的上限。我整理了一个小型对比表不代表所有场景都适用但可以给你一个初始决策思路模型优点缺点适合场景DeepSeek deepseek-chat价格低、中文好、OpenAI兼容复杂推理弱于顶级闭源个人项目、中文场景DeepSeek deepseek-reasoner推理过程强响应慢、推理token成本高逻辑题、代码分析GPT-4o / GPT-4.1工具调用稳、生态好价格高、需要国际支付企业产品、复杂AgentClaude 系列长上下文强、写代码强价格高、国内访问不便文档摘要、代码生成Qwen 72B 本地部署可离线、隐私好需要多卡、维护成本高内网数据敏感场景如果你是新手我建议先无脑用 deepseek-chat 把流程跑通等确认 Agent 真的能在业务里带来价值再考虑换成更贵或更复杂的模型。一个常见的误区是一开始就追求最强模型结果钱花了不少还没学会怎么设计好的工具和提示词。4.4 部署层面的常见问题API Key、并发、日志审计个人项目部署相对随意但如果是团队或企业使用有几件事必须提前想好。API Key 不应该写在配置文件里要放到密钥管理服务或环境变量中Agent 服务需要限流防止某个用户把整月预算刷爆所有工具调用日志都要留存包括模型返回的原始内容和工具执行结果否则出了问题根本没法复盘。我在测试 Jenkins 场景时就吃过亏Agent 调用一个查看日志的工具因为文件名带空格拼接命令时出了错工具返回“File Not Found”。如果不看日志只看最终输出会以为是 Agent 幻觉实际上只是工具调用参数没转义。这个问题暴露了“可观测性”的重要性——每个工具调用的入参和出参都必须被记录下来这是 Agent 应用中比“智能”更重要的工程指标。5. 两小时后的真实感受我在两小时里装出的 Agent和市面上那些成熟产品比还差得很远。它没有漂亮界面没有多智能体编排也没有复杂记忆管理但它确确实实让我第一次感受到“模型从回答问题变成了执行任务”。当我说“现在几点顺便算一下表达式”它真的去调了时间函数又调了计算器最后把结果拼成一句自然回复那种感觉跟单纯问一个聊天机器人是完全不同的。如果你也想动手试我给你三个建议。第一不要一开始就追“多智能体”“复杂记忆”这些热词先把单 Agent 的工具调用跑通比什么都管用第二所有配置和代码都用最小可行方案起步只有当你明确遇到性能瓶颈时再引入向量库、消息队列这类重武器第三始终把日志和权限当第一优先级Agent 越智能失控的破坏力就越大。我在实验结束后把 Agent 接到了自己每天都要做的定时巡检任务上让它每天早上读日志、检查异常状态、写一份摘要发给群机器人。这个改动不大但已经帮我省了每天十分钟的重复劳动。也许再过一阵我会继续加一个数据分析工具让它能从数据库里拉数据生成周报。到那时候再写一篇持续迭代的踩坑记录。