AI Agent 智能体开发是当前 AI 应用层增长最快的技能方向之一。大模型本身只是“会思考的接口”而智能体Agent是把思考转化成行动的单位它拆解任务、调用工具、读写外部数据、多轮试错甚至多个 Agent 之间互相协作。本文把一套从零基础到就业的 AI Agent 智能体开发教程整理成系统性技术长文覆盖概念、环境、最小可运行实例、功能测试、API 集成、批量任务、多智能体架构和常见问题。本文主要解决三个问题第一AI Agent 的运行逻辑到底怎么理解它与普通 Prompt、工作流、RAG 的区别是什么第二从零开始如何搭建一个最小可用智能体包含低代码平台和手写代码两种路线第三真实生产中 Agent 如何接工具、跑批量任务、做多智能体协作以及最容易踩的坑。全文不堆概念给可直接复制的命令、代码和验证方法。适合的读者包括后端开发想转 AI 应用开发已经会写 Python 但没系统接触过 Agent 的工程师产品经理或测试想理解智能体落地流程以及准备应聘 agent 智能体开发工程师岗位的学习者。这套内容偏工程实战不是科研方向。1. 核心能力速览AI Agent 开发到底要掌握什么能力项说明学习路线大模型 API → Prompt 工程 → 工具调用 → Agent 框架 → RAG → 多智能体 → 工程化部署主要技术栈Python、LLM API、Function Calling、MCP、Dify、LangGraph、向量数据库、任务队列是否需要显卡纯 API 方案不需要显卡本地部署开源模型才需要显存以具体模型为准部署方式纯云端 API / 本地模型推理 / Docker 平台部署启动方式脚本启动、WebUI 启动、API 服务启动、低代码平台可视化配置是否支持批量任务支持可自行编写批量脚本或接入任务队列是否支持 API 集成支持Agent 后端可封装为 HTTP 接口供业务系统调用适合岗位Agent 应用开发工程师、智能体平台研发、AI 解决方案工程师主要开源生态LangChain / LangGraph、Dify、Coze 扣子、MCP 工具协议等以上每一项都不是孤立知识点而是前后衔接的一条链路。AI Agent 开发与普通接口开发最大的区别在于不再是“用户发请求、程序给固定结果”的线性逻辑而是“用户给目标、Agent 自己规划步骤、调用外部工具、根据中间结果继续推进”的循环逻辑。2026 年社区对 Agent 的讨论重点已经从“能不能跑通”变成“怎么跑得稳、可观测、可维护”所以本文也会花较多篇幅讲测试、排错和批量任务。2. 适用人群、学习路径与使用边界2.1 什么样的开发者适合学 AgentAI Agent 智能体开发并不是一门只属于算法工程师的领域它更像是一种工程能力。在实际招聘中agent 智能体开发工程师岗位往往要求候选人具备三类能力一是能写 Python 并封装接口二是理解大模型 API 的调用逻辑和成本模型三是会处理工具调用、记忆、上下文管理和多轮流程。如果你之前写过 Web 后端那么你只需要补齐大模型 API 调用和 Agent 编排框架两块知识转型速度会比较快。如果你之前只做前端或运维也可以切入但至少要先把 Python、HTTP 请求、JSON 数据处理这些基础补上来。2.2 从零基础到就业的六步路径第一步熟悉大模型 API。至少要用一个真实模型服务完成“文本聊天 结构化输出 Function Calling”三件事。Function Calling 是 Agent 的发动机因为 Agent 之所以能调用工具本质上是模型输出了“应该调用哪个函数、传什么参数”的结构化结果而不是开发者在代码里写死分支。第二步掌握 Prompt 工程基础。这里不是简单学“角色扮演”而是要掌握变量注入、few-shot 示例、输出格式约束、指令优先级和防注入。特别是从 B 站和各大社区流传的教程来看很多 Agent 翻车都发生在提示词阶段比如模型把系统指令和用户输入混在一起或者输出格式不稳定导致下游解析失败。第三步学习工作流与编排概念。需要理解线形流程、条件分支、循环、并行节点、人工审批节点这些概念。这些概念不管是用 Dify 的可视化编排还是用 LangGraph 代码编写都是通用的。值得注意的一个趋势是低代码平台的兴起降低了 Agent 搭建门槛但就业和复杂项目最终仍然需要代码级控制能力。第四步做一两个真实场景项目。推荐优先做带知识库的问答 AgentRAG以及带工具调用查询 Agent天气、订单查询、数据库查询。这类项目能同时覆盖记忆、检索、工具调用和异常处理面试时也容易讲清楚。第五步学习多智能体协作与架构。常见的模式包括主管-工人模式、流水线模式、辩论模式、路由转发模式。这里不需要一开始就追求复杂架构但至少要理解“为什么单个 Agent 做所有事会失控”。第六步工程化落地。包括接口封装、日志追踪、批量任务、限流与重试、权限控制、输出审核。很多教程讲到这步就停了但实际开发中 Agent 能不能上线看的恰恰是这部分工程能力。2.3 使用边界与合规提醒Agent 具有“自动化执行”能力所以使用前必须明确边界。工具调用不能越权访问未授权的系统不能用于绕过登录验证、批量抓取受限数据、撞库、窃取接口权限等操作。涉及人脸、声音、个人隐私、版权素材时必须确认已获得合法授权。建议把 Agent 的工具权限设计为最小权限执行敏感操作前增加人工确认环节。合规不是附加项而是 Agent 上线前必须通过的一环。3. 环境准备与前置条件3.1 开发环境通用清单AI Agent 开发对操作系统要求并不高Windows、macOS、Linux 都可以。如果你使用 Windows建议优先安装 WSL2 或 Docker Desktop这样后续部署基于 Docker 的开源智能体平台时会顺畅很多。相关技术栈中“window 系统部署”是出现频率很高的搜索词大多数开源平台的官方文档都提供了 Linux 优先的支持Windows 下最稳妥的方式就是通过 WSL2 或容器运行。环境层面的通用清单大概包括Python 3.10 或以上版本建议使用 conda 管理虚拟环境。Node.js 18 或以上版本部分平台前端和工具链需要。Docker 和 Docker Compose用于部署 Dify 等开源智能体平台。Git用于拉取仓库。一个可用的模型服务 API Key可以是云厂商的也可以是本地模型的 OpenAI 兼容地址。后续章节的 Python 依赖openai、requests、python-dotenv、pydantic。下面给出一套通用环境创建命令# 创建 Python 虚拟环境Windows 下可用 conda 或 venv conda create -n agent python3.11 -y conda activate agent # 安装基础依赖 pip install openai python-dotenv requests pydantic # 验证 Python 版本 python --version3.2 本地模型还是云端 APIAI Agent 开发的硬件成本差异很大。如果你使用商用模型 API本机几乎不需要 GPU主要开销是 Token 费用开发环境一台普通电脑就够。如果你要在本地部署开源模型实现私有化 Agent则必须准备 GPU显存大小取决于模型参数量和量化方式通常 7B 到 14B 级别的模型在量化后需要 8G 到 20G 不等具体数字必须按实际模型和推理引擎测试。本文不编造固定显存占用因为不同版本差异太大。更务实的建议是学习阶段先全部走云端 API把 Agent 的逻辑、工具调用、记忆编排全部跑通等确认需要本地私有化部署再单独评估模型和显卡。这样开发体验最好也最容易定位问题。3.3 配置 API 地址和密钥几乎所有主流大模型服务平台都提供 OpenAI 兼容接口。项目根目录下创建一个.env文件统一保存密钥和端点信息避免把密钥提交到代码仓库# .env 示例请按实际服务商填写 OPENAI_API_KEYYOUR_API_KEY OPENAI_BASE_URLhttps://your-api-endpoint OPENAI_MODELyour-model-name代码中通过python-dotenv加载配置import os from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(OPENAI_API_KEY) BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL os.getenv(OPENAI_MODEL, gpt-4o-mini)4. 从零搭建第一个智能体4.1 方案一使用 Dify 低代码平台快速验证Dify 是开源 LLM 应用开发平台中社区热度很高的一个它最大的价值是可以让开发者在没有写太多代码的情况下完成 Agent 的编排、知识库接入、工具配置、日志观测和 API 发布。它支持工作流编排、Agent 节点、知识库 RAG、模型接入、外部工具接入并且可以将编排好的应用发布成 API 和网页应用。对于智能体初学者来说Dify 是理解 Agent 概念的最佳入口。启动 Dify 社区版的一般方式是通过 Docker Compose 拉取官方仓库并启动。不同版本路径可能有变化以下命令是通用模板实际目录名和端口请以官方文档为准# 克隆开源平台代码这里以 Dify 社区版示意 git clone https://github.com/langgenius/dify.git cd dify # 使用 Docker Compose 后台启动 docker compose up -d # 查看启动进度 docker compose logs -f启动完成后通过浏览器访问平台 Web 界面。默认端口可能是 80 或 3000 这类常见端口具体以官方文档为准。如果是第一次启动需要先创建管理员账号。接下来可以按以下步骤建立第一个智能体第一步在平台中接入模型供应商填入 API Key 和模型名称。如果使用本地模型需要填写允许的 Base URL、模型名和 API Key并确认模型服务已启动且端口可达。第二步创建一个 Agent 应用。在应用类型中选择“Agent”然后在编排界面里配置系统提示词。提示词要写清楚 Agent 的角色、能力边界、输出格式、默认处理步骤。第三步添加工具。Dify 支持内置工具集也支持自定义 OpenAPI 工具。以天气查询为例你可以创建一个自定义工具传入城市名返回天气信息。工具描述必须写清楚因为模型是根据工具描述来决定是否调用和传参的。第四步发布应用。Dify 会把应用包装成 API通过“访问 API”可以获得调用地址和密钥。4.2 方案二使用 Python 手写带工具调用的 Agent低代码平台适合快速验证但要真正掌握 Agent 原理必须手写一遍代码。核心逻辑是将用户请求发给模型模型判断需要调用哪个工具并输出结构化调用参数程序执行工具后把结果回传给模型模型再生成最终回答或继续调用其他工具。下面是一个最小可运行的例子使用 OpenAI 兼容接口其中模型名称、接口地址都替换为实际占位符import json from openai import OpenAI from dotenv import load_dotenv import os load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) ) MODEL os.getenv(OPENAI_MODEL, gpt-4o-mini) # 定义工具列表模型会按这个描述生成调用请求 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名例如北京、上海} }, required: [city] } } } ] def get_weather(city: str) - str: # 这里替换成真实天气服务当前是演示返回 return f{city} 今天晴气温 22℃适合出行 def run_agent(user_input: str) - str: messages [{role: user, content: user_input}] response client.chat.completions.create( modelMODEL, messagesmessages, toolstools, tool_choiceauto ) msg response.choices[0].message messages.append(msg) # 如果模型决定调用工具则执行工具并将结果回传 if msg.tool_calls: for tool_call in msg.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) if fn_name get_weather: result get_weather(fn_args.get(city)) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) final_response client.chat.completions.create( modelMODEL, messagesmessages, toolstools ) return final_response.choices[0].message.content return msg.content if __name__ __main__: print(run_agent(北京今天天气怎么样))这个例子虽然简单但它已经包含 Agent 的核心循环模型推理 → 工具调用 → 工具结果回填 → 再推理。实际生产环境会复杂得多比如要支持多个工具、处理工具调用异常、限制最大循环轮数、记录每个步骤的 Token 消耗但只要理解了这段最小循环后面扩展方向就清晰了。4.3 判断第一个智能体是否成功成功的标准不应只是“模型返回了一段文字”而是保证以下三点成立第一模型在合适的时候会输出工具调用请求而不是装作自己知道天气。第二程序能正确执行工具并把结果回传给模型。第三最终回答基于工具返回的真实结果而不是模型凭空生成。如果模型没有调用工具常见原因是工具描述写得不清楚、模型能力较弱或者参数 schema 写得太复杂。5. Agent 核心能力测试与效果验证5.1 工具调用测试工具调用是 Agent 最重要的能力。测试时需要覆盖多个场景正常调用、参数缺失、参数格式错误、工具返回异常、多个工具连续调用、工具结果互相依赖。测试目的验证模型能否在对话中理解用户意图并生成正确的工具调用参数。输入示例“帮我查一下上海的天气然后再对比北京是否更适合出行。”操作步骤是启动 Agent 服务按照顺序发送不同难度的工具调用请求观察模型是否调用工具、参数是否完整、返回结果是否合理。判断成功的关键是工具调用参数必须能被 JSON 解析并且工具名正确。失败时优先检查工具描述是否明确、模型是否支持函数调用、参数 schema 是不是存在类型冲突。5.2 多轮对话与记忆测试Agent 与普通接口不同它需要具备多轮记忆能力。这里说的记忆至少分成两层第一层是会话内的短期记忆直接存放在 messages 数组中第二层是跨会话的长期记忆一般依赖向量数据库和用户标识。测试时可以先问“我今天想去上海玩”下一轮再问“那里天气怎么样”看 Agent 是否能关联到“上海”这个上文实体。如果模型忘记了排除思路是先检查 messages 是否完整传递再看上下文是否因为超长被截断最后考虑是否需要引入摘要记忆或向量检索。建议在测试多轮能力时同步记录 Token 消耗。因为随着对话轮数增加输入 Token 会线性增长如果没有压缩摘要成本会很快上升。5.3 路由与任务编排测试Agent 不只是单一问答还可能需要根据任务类型分发到不同的子流程。比如一个客服智能体可以根据用户需求路由到订单查询、售后流程、商品推荐。测试时重点看分支判断是否准确、是否出现来回跳转、超时后是否有兜底回答。判断成功的标准是相似问题能稳定进入同一个分支边界问题不会频繁跳分支链路异常时有统一兜底文案。排查时优先检查系统提示词中的路由规则是否过于模糊以及各分支节点是否都配置了默认回复。5.4 批量任务与稳定性测试Agent 开发完成以后批量任务测试是不可跳过的环节。这里的“批量任务”并不是简单 for 循环调用而是要关注三个问题模型服务限流、单任务失败是否影响整体、结果是否可结构化保存。可以先准备一份 20 条左右的测试输入文件包含正常文本、超长文本、空文本、纯符号文本、带敏感词的文本。用脚本逐条调用 Agent API记录成功数、失败数、平均响应时长、单条 Token 消耗。目标不是追求 100% 成功而是建立“失败可观测、可重试、可定位”的机制。6. 接口 API 与批量任务集成6.1 将 Agent 封装成 API 服务开发完成后Agent 需要作为服务提供给上层业务调用。最简单的方式是使用 FastAPI 封装一个 HTTP 接口。下面的示例是通用结构实际路由和参数可自行扩展from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class AgentRequest(BaseModel): user_input: str session_id: str default class AgentResponse(BaseModel): output: str session_id: str app.post(/agent/invoke, response_modelAgentResponse) def invoke_agent(req: AgentRequest): # 这里调用上一节写好的 run_agent 或平台 API output run_agent(req.user_input) return AgentResponse(outputoutput, session_idreq.session_id) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动服务uvicorn main:app --host 127.0.0.1 --port 8000启动之后可以用 curl 验证接口curl -X POST http://127.0.0.1:8000/agent/invoke \ -H Content-Type: application/json \ -d {user_input: 北京天气怎么样, session_id: test-001}如果接口能返回模型生成的文本说明 Agent 已经可以作为后端服务被其他系统调用。6.2 批量任务脚本设计批量任务脚本至少需要具备以下能力读取输入、输出结构化结果、记录失败原因、支持重试。下面是一个通用示例import json import time import requests API_URL http://127.0.0.1:8000/agent/invoke tasks [ 北京天气怎么样, 推荐一部科幻电影, 把这段文本改写得更正式老板好我不干了, ] results [] for idx, task in enumerate(tasks): payload {user_input: task, session_id: fbatch-{idx}} try: resp requests.post(API_URL, jsonpayload, timeout120) resp.raise_for_status() data resp.json() results.append({task: task, status: success, output: data[output]}) except Exception as exc: results.append({task: task, status: failed, error: str(exc)}) # 注意限流间隔时间需根据实际模型服务调整 time.sleep(1) with open(batch_result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(完成:, len(results))生产级批量任务建议进一步接入任务队列。简单场景可以使用 Python 的队列模块复杂场景建议使用 Celery、MQ 或云厂商的消息队列。批量任务的关键设计原则是每条任务之间不共享状态失败任务可以单独重跑结果写入独立文件或数据库字段所有输入输出都要有 trace_id 关联方便排查。7. 多智能体架构与 2026 趋势7.1 单 Agent 的局限单个 Agent 做所有事情在一两个工具、简单流程上没有问题但一旦任务变多问题就出现了。最典型的是“上下文污染”内部指令、工具描述、历史对话、临时结果全部堆在一个上下文中模型很容易被无关信息干扰。其次是职责不清晰一个 Agent 既要理解用户意图又要调订单接口还要写话术后续维护非常困难。因此社区越来越多地转向多智能体方案。7.2 多智能体协作的常见模式在实际工程中多智能体并不是“多个 Agent 一起聊”而是围绕任务拆分和结果汇总设计固定协作模式。常见的有三种。第一种是主管-工人模式也就是 Supervisor Workers。顶层一个主管 Agent 理解用户目标将任务拆分成子任务下发给多个专门 Agent然后汇总结果。这种模式适合任务类型差异大的场景比如需要同时查订单、查物流、查优惠券的场景。第二种是流水线模式多个 Agent 按顺序执行前一个 Agent 的输出是后一个 Agent 的输入。这种模式适合有固定流程的业务比如内容审核、文章改写、数据清洗。关键在于每个 Agent 都要有明确的输出格式约定否则链路会中断。第三种是路由分发模式主 Agent 只做任务分类将请求直接转发给对应领域的 tool 或子 Agent。这种模式效率高但分类准确性要求高需要做大量边界测试。实现多智能体时LangGraph 和 Dify 工作流是两条主流路线。LangGraph 适合代码层面控制状态流转适合有复杂状态和条件分支的工程Dify 工作流则适合快速搭建和可视化调试。如果目标是就业建议至少掌握一种代码级编排框架它有更强的可扩展性和调试能力。7.3 2026 年值得关注的方向从社区讨论趋势看2026 年 Agent 开发的热点主要集中在MCP 工具协议逐步成为 Agent 与外部工具之间的标准连接方式可观测性成为 Agent 上线必备能力每轮思考、工具调用、Token 消耗都需要可视化追踪轻量级智能体部署方案在个人开发者和 Windows 用户中流行起来比如社区里讨论较多的 Hermes、Microduck 等方案但具体安装和使用请以各项目的官方仓库说明为准不要轻信未验证的一键包多智能体编排逐渐从实验走向工程企业开始关注稳定性、权限隔离和成本控制。8. 资源占用与性能观察8.1 纯 API 模式下的资源占用如果 Agent 调用的是云端模型 API本地资源占用主要集中在 Agent 服务进程和依赖服务上。Python 单进程占用内存通常在几百 MB 以内CPU 消耗主要来自 JSON 解析、请求转发和日志写入对显存没有要求。这种情况下性能瓶颈主要集中在网络延迟和模型服务响应速度上。8.2 本地模型部署的显存观察如果要在本地部署开源模型情况就不同了。先说方法启动模型推理服务后可以通过nvidia-smi观察显卡显存占用。下面命令是通用方式# 每 2 秒刷新一次显存状态 watch -n 2 nvidia-smi显存占用不是固定值它取决于模型参数量、量化位数、上下文长度、并发请求数。更稳妥的判断是第一次启动后先请求一条短文本记录显存基线再请求一条长文本或开启多并发对比显存增长最后通过降低模型上下文长度、减少最大并发数、切换更低比特量化来优化。8.3 延迟与成本优化Agent 的延迟不是模型生成时间决定的而是多轮调用总和。一次工具调用可能产生两到三次模型请求所以延迟和成本会成倍放大。优化手段包括控制工具数量、精简工具描述、限制最大工具调用轮数、使用摘要记忆而不是无限叠加历史、对简单任务使用小模型、对复杂任务使用大模型。这里建议在 Agent 业务代码中记录一个结构化日志至少包含 user_input、model、tool_calls、prompt_tokens、completion_tokens、latency_ms、created_at 这几个字段这是后续定位延迟问题和成本分析的基础。9. 常见问题与排查方法问题现象可能原因排查方式解决方案模型不调用工具直接瞎回复工具描述不清晰或模型不支持 Function Calling检查模型服务能力查看完整请求日志重写工具描述换支持工具调用的模型工具参数解析失败模型返回 JSON 格式不规范打印模型原始输出查看 tool_call.function.arguments 内容增加异常捕获重试一次或要求模型输出纯 JSON多轮对话后模型忘记上文上下文未正确传递或上下文过长被截断检查 messages 是否包含历史记录保留完整 messages引入摘要记忆或向量检索接口调用超时模型推理过慢或网络代理异常查看服务日志和模型服务监控设置更长超时开启流式输出检查网络连接启动服务后页面无法访问端口被占用或容器未就绪查看 docker compose logs检查端口占用更换端口等待容器健康检查通过批量任务中途卡住某条任务请求未结束或触发限流打印当前正在处理的任务索引增加超时时间失败自动重试加入限流等待Token 成本上升很快工具调用轮数过多历史消息无限增长查看日志中的 prompt_tokens 变化限制最大轮数使用摘要压缩历史本地模型显存不足模型过大或上下文过长观察 nvidia-smi查看推理引擎日志切换量化模型减小上下文长度降低并发排查问题有一个基本原则先看日志再看请求数据最后才是改代码。Agent 是链式调用如果最终结果不对问题可能出在任意一环。建议在开发阶段就保留完整的请求和响应日志尤其是模型原始输出因为它能一次性暴露工具调用名、参数字段、截断位置等问题。10. 最佳实践与安全合规Agent 开发越到后期工程化规范越重要。下面几条是从实际开发中总结出来的通用最佳实践。第一工具权限最小化。Agent 能访问的工具越多被误用和注入的风险越大。每一个工具接口都要确认是否有越权风险敏感操作必须增加人工审批节点。比如“发送短信”“删除数据”“修改订单”这类操作不要让模型单轮直接触发。第二提示词注入防护。用户输入可能伪装成系统指令诱导 Agent 输出内部提示词或执行非预期操作。实践中有两类防御措施一类是把用户输入与系统指令做明确分隔始终把用户输入当作不可信数据另一类是在工具调用前增加规则校验比如只允许特定工具在白名单内执行。第三批量任务要有幂等设计。如果批量任务执行到一半失败重新执行时不能重复扣款、重复发送消息或重复写入数据。建议在业务层面增加任务 ID 或 trace_id执行前查询是否已经处理。第四输出内容要合规。Agent 生成的内容不能包含涉政、暴力、色情、诱导违法行为等信息。上线前建议接入内容审核接口而不是只依赖模型自带的安全对齐。第五隐私数据处理要谨慎。如果 Agent 需要处理用户手机号、地址、身份证等隐私信息建议脱敏后再送入模型工具日志中也不能记录明文。涉及声音克隆、人脸生成、数字人等能力时必须确认已获得肖像权和声音授权。第六保留一套最小可运行配置。在项目目录下保存一份已经验证通过的模型配置、环境变量模板和启动命令避免重新部署时到处找参数。建议使用.env.example保存所有占位符配置用 README 记录启动步骤。11. 总结与下一步AI Agent 开发是一个从接口调用到系统工程逐渐深入的过程。如果有人问先验证什么我的建议是先跑通一次“模型 → 工具调用 → 工具结果回填 → 模型回答”的最小循环再逐步增加记忆、路由、批量任务和多智能体协作。这套链路跑通之后你就可以在 Dify、LangGraph、或自定义 Python 服务之间灵活切换也能更快理解社区里各种 Agent 项目的设计思路。本文出现的代码都是通用模板实际使用时要替换成你选择的模型服务商、工具列表和业务字段。文中没有写死显卡显存和端口号的地方也不是遗漏而是因为这些参数必须按实际环境确认。建议你先在 API 模式下跑通流程再评估私有化部署的硬件方案。后续可以扩展的方向很多把 Agent 接入企业知识库做 RAG 智能问答用 MCP 协议把公司内部工具统一接入在 LangGraph 里实现一个带人工审批节点的多智能体系统把批量任务迁移到消息队列并加上完善的失败重试机制。每一步落地都比继续刷概念有价值。建议收藏本文把第一节的学习路线作为自己的检查清单每完成一个阶段就回来对照一次。 AI Agent智能体开发实战：从零基础到多智能体架构与工程落地
AI Agent 智能体开发是当前 AI 应用层增长最快的技能方向之一。大模型本身只是“会思考的接口”而智能体Agent是把思考转化成行动的单位它拆解任务、调用工具、读写外部数据、多轮试错甚至多个 Agent 之间互相协作。本文把一套从零基础到就业的 AI Agent 智能体开发教程整理成系统性技术长文覆盖概念、环境、最小可运行实例、功能测试、API 集成、批量任务、多智能体架构和常见问题。本文主要解决三个问题第一AI Agent 的运行逻辑到底怎么理解它与普通 Prompt、工作流、RAG 的区别是什么第二从零开始如何搭建一个最小可用智能体包含低代码平台和手写代码两种路线第三真实生产中 Agent 如何接工具、跑批量任务、做多智能体协作以及最容易踩的坑。全文不堆概念给可直接复制的命令、代码和验证方法。适合的读者包括后端开发想转 AI 应用开发已经会写 Python 但没系统接触过 Agent 的工程师产品经理或测试想理解智能体落地流程以及准备应聘 agent 智能体开发工程师岗位的学习者。这套内容偏工程实战不是科研方向。1. 核心能力速览AI Agent 开发到底要掌握什么能力项说明学习路线大模型 API → Prompt 工程 → 工具调用 → Agent 框架 → RAG → 多智能体 → 工程化部署主要技术栈Python、LLM API、Function Calling、MCP、Dify、LangGraph、向量数据库、任务队列是否需要显卡纯 API 方案不需要显卡本地部署开源模型才需要显存以具体模型为准部署方式纯云端 API / 本地模型推理 / Docker 平台部署启动方式脚本启动、WebUI 启动、API 服务启动、低代码平台可视化配置是否支持批量任务支持可自行编写批量脚本或接入任务队列是否支持 API 集成支持Agent 后端可封装为 HTTP 接口供业务系统调用适合岗位Agent 应用开发工程师、智能体平台研发、AI 解决方案工程师主要开源生态LangChain / LangGraph、Dify、Coze 扣子、MCP 工具协议等以上每一项都不是孤立知识点而是前后衔接的一条链路。AI Agent 开发与普通接口开发最大的区别在于不再是“用户发请求、程序给固定结果”的线性逻辑而是“用户给目标、Agent 自己规划步骤、调用外部工具、根据中间结果继续推进”的循环逻辑。2026 年社区对 Agent 的讨论重点已经从“能不能跑通”变成“怎么跑得稳、可观测、可维护”所以本文也会花较多篇幅讲测试、排错和批量任务。2. 适用人群、学习路径与使用边界2.1 什么样的开发者适合学 AgentAI Agent 智能体开发并不是一门只属于算法工程师的领域它更像是一种工程能力。在实际招聘中agent 智能体开发工程师岗位往往要求候选人具备三类能力一是能写 Python 并封装接口二是理解大模型 API 的调用逻辑和成本模型三是会处理工具调用、记忆、上下文管理和多轮流程。如果你之前写过 Web 后端那么你只需要补齐大模型 API 调用和 Agent 编排框架两块知识转型速度会比较快。如果你之前只做前端或运维也可以切入但至少要先把 Python、HTTP 请求、JSON 数据处理这些基础补上来。2.2 从零基础到就业的六步路径第一步熟悉大模型 API。至少要用一个真实模型服务完成“文本聊天 结构化输出 Function Calling”三件事。Function Calling 是 Agent 的发动机因为 Agent 之所以能调用工具本质上是模型输出了“应该调用哪个函数、传什么参数”的结构化结果而不是开发者在代码里写死分支。第二步掌握 Prompt 工程基础。这里不是简单学“角色扮演”而是要掌握变量注入、few-shot 示例、输出格式约束、指令优先级和防注入。特别是从 B 站和各大社区流传的教程来看很多 Agent 翻车都发生在提示词阶段比如模型把系统指令和用户输入混在一起或者输出格式不稳定导致下游解析失败。第三步学习工作流与编排概念。需要理解线形流程、条件分支、循环、并行节点、人工审批节点这些概念。这些概念不管是用 Dify 的可视化编排还是用 LangGraph 代码编写都是通用的。值得注意的一个趋势是低代码平台的兴起降低了 Agent 搭建门槛但就业和复杂项目最终仍然需要代码级控制能力。第四步做一两个真实场景项目。推荐优先做带知识库的问答 AgentRAG以及带工具调用查询 Agent天气、订单查询、数据库查询。这类项目能同时覆盖记忆、检索、工具调用和异常处理面试时也容易讲清楚。第五步学习多智能体协作与架构。常见的模式包括主管-工人模式、流水线模式、辩论模式、路由转发模式。这里不需要一开始就追求复杂架构但至少要理解“为什么单个 Agent 做所有事会失控”。第六步工程化落地。包括接口封装、日志追踪、批量任务、限流与重试、权限控制、输出审核。很多教程讲到这步就停了但实际开发中 Agent 能不能上线看的恰恰是这部分工程能力。2.3 使用边界与合规提醒Agent 具有“自动化执行”能力所以使用前必须明确边界。工具调用不能越权访问未授权的系统不能用于绕过登录验证、批量抓取受限数据、撞库、窃取接口权限等操作。涉及人脸、声音、个人隐私、版权素材时必须确认已获得合法授权。建议把 Agent 的工具权限设计为最小权限执行敏感操作前增加人工确认环节。合规不是附加项而是 Agent 上线前必须通过的一环。3. 环境准备与前置条件3.1 开发环境通用清单AI Agent 开发对操作系统要求并不高Windows、macOS、Linux 都可以。如果你使用 Windows建议优先安装 WSL2 或 Docker Desktop这样后续部署基于 Docker 的开源智能体平台时会顺畅很多。相关技术栈中“window 系统部署”是出现频率很高的搜索词大多数开源平台的官方文档都提供了 Linux 优先的支持Windows 下最稳妥的方式就是通过 WSL2 或容器运行。环境层面的通用清单大概包括Python 3.10 或以上版本建议使用 conda 管理虚拟环境。Node.js 18 或以上版本部分平台前端和工具链需要。Docker 和 Docker Compose用于部署 Dify 等开源智能体平台。Git用于拉取仓库。一个可用的模型服务 API Key可以是云厂商的也可以是本地模型的 OpenAI 兼容地址。后续章节的 Python 依赖openai、requests、python-dotenv、pydantic。下面给出一套通用环境创建命令# 创建 Python 虚拟环境Windows 下可用 conda 或 venv conda create -n agent python3.11 -y conda activate agent # 安装基础依赖 pip install openai python-dotenv requests pydantic # 验证 Python 版本 python --version3.2 本地模型还是云端 APIAI Agent 开发的硬件成本差异很大。如果你使用商用模型 API本机几乎不需要 GPU主要开销是 Token 费用开发环境一台普通电脑就够。如果你要在本地部署开源模型实现私有化 Agent则必须准备 GPU显存大小取决于模型参数量和量化方式通常 7B 到 14B 级别的模型在量化后需要 8G 到 20G 不等具体数字必须按实际模型和推理引擎测试。本文不编造固定显存占用因为不同版本差异太大。更务实的建议是学习阶段先全部走云端 API把 Agent 的逻辑、工具调用、记忆编排全部跑通等确认需要本地私有化部署再单独评估模型和显卡。这样开发体验最好也最容易定位问题。3.3 配置 API 地址和密钥几乎所有主流大模型服务平台都提供 OpenAI 兼容接口。项目根目录下创建一个.env文件统一保存密钥和端点信息避免把密钥提交到代码仓库# .env 示例请按实际服务商填写 OPENAI_API_KEYYOUR_API_KEY OPENAI_BASE_URLhttps://your-api-endpoint OPENAI_MODELyour-model-name代码中通过python-dotenv加载配置import os from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(OPENAI_API_KEY) BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL os.getenv(OPENAI_MODEL, gpt-4o-mini)4. 从零搭建第一个智能体4.1 方案一使用 Dify 低代码平台快速验证Dify 是开源 LLM 应用开发平台中社区热度很高的一个它最大的价值是可以让开发者在没有写太多代码的情况下完成 Agent 的编排、知识库接入、工具配置、日志观测和 API 发布。它支持工作流编排、Agent 节点、知识库 RAG、模型接入、外部工具接入并且可以将编排好的应用发布成 API 和网页应用。对于智能体初学者来说Dify 是理解 Agent 概念的最佳入口。启动 Dify 社区版的一般方式是通过 Docker Compose 拉取官方仓库并启动。不同版本路径可能有变化以下命令是通用模板实际目录名和端口请以官方文档为准# 克隆开源平台代码这里以 Dify 社区版示意 git clone https://github.com/langgenius/dify.git cd dify # 使用 Docker Compose 后台启动 docker compose up -d # 查看启动进度 docker compose logs -f启动完成后通过浏览器访问平台 Web 界面。默认端口可能是 80 或 3000 这类常见端口具体以官方文档为准。如果是第一次启动需要先创建管理员账号。接下来可以按以下步骤建立第一个智能体第一步在平台中接入模型供应商填入 API Key 和模型名称。如果使用本地模型需要填写允许的 Base URL、模型名和 API Key并确认模型服务已启动且端口可达。第二步创建一个 Agent 应用。在应用类型中选择“Agent”然后在编排界面里配置系统提示词。提示词要写清楚 Agent 的角色、能力边界、输出格式、默认处理步骤。第三步添加工具。Dify 支持内置工具集也支持自定义 OpenAPI 工具。以天气查询为例你可以创建一个自定义工具传入城市名返回天气信息。工具描述必须写清楚因为模型是根据工具描述来决定是否调用和传参的。第四步发布应用。Dify 会把应用包装成 API通过“访问 API”可以获得调用地址和密钥。4.2 方案二使用 Python 手写带工具调用的 Agent低代码平台适合快速验证但要真正掌握 Agent 原理必须手写一遍代码。核心逻辑是将用户请求发给模型模型判断需要调用哪个工具并输出结构化调用参数程序执行工具后把结果回传给模型模型再生成最终回答或继续调用其他工具。下面是一个最小可运行的例子使用 OpenAI 兼容接口其中模型名称、接口地址都替换为实际占位符import json from openai import OpenAI from dotenv import load_dotenv import os load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) ) MODEL os.getenv(OPENAI_MODEL, gpt-4o-mini) # 定义工具列表模型会按这个描述生成调用请求 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名例如北京、上海} }, required: [city] } } } ] def get_weather(city: str) - str: # 这里替换成真实天气服务当前是演示返回 return f{city} 今天晴气温 22℃适合出行 def run_agent(user_input: str) - str: messages [{role: user, content: user_input}] response client.chat.completions.create( modelMODEL, messagesmessages, toolstools, tool_choiceauto ) msg response.choices[0].message messages.append(msg) # 如果模型决定调用工具则执行工具并将结果回传 if msg.tool_calls: for tool_call in msg.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) if fn_name get_weather: result get_weather(fn_args.get(city)) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) final_response client.chat.completions.create( modelMODEL, messagesmessages, toolstools ) return final_response.choices[0].message.content return msg.content if __name__ __main__: print(run_agent(北京今天天气怎么样))这个例子虽然简单但它已经包含 Agent 的核心循环模型推理 → 工具调用 → 工具结果回填 → 再推理。实际生产环境会复杂得多比如要支持多个工具、处理工具调用异常、限制最大循环轮数、记录每个步骤的 Token 消耗但只要理解了这段最小循环后面扩展方向就清晰了。4.3 判断第一个智能体是否成功成功的标准不应只是“模型返回了一段文字”而是保证以下三点成立第一模型在合适的时候会输出工具调用请求而不是装作自己知道天气。第二程序能正确执行工具并把结果回传给模型。第三最终回答基于工具返回的真实结果而不是模型凭空生成。如果模型没有调用工具常见原因是工具描述写得不清楚、模型能力较弱或者参数 schema 写得太复杂。5. Agent 核心能力测试与效果验证5.1 工具调用测试工具调用是 Agent 最重要的能力。测试时需要覆盖多个场景正常调用、参数缺失、参数格式错误、工具返回异常、多个工具连续调用、工具结果互相依赖。测试目的验证模型能否在对话中理解用户意图并生成正确的工具调用参数。输入示例“帮我查一下上海的天气然后再对比北京是否更适合出行。”操作步骤是启动 Agent 服务按照顺序发送不同难度的工具调用请求观察模型是否调用工具、参数是否完整、返回结果是否合理。判断成功的关键是工具调用参数必须能被 JSON 解析并且工具名正确。失败时优先检查工具描述是否明确、模型是否支持函数调用、参数 schema 是不是存在类型冲突。5.2 多轮对话与记忆测试Agent 与普通接口不同它需要具备多轮记忆能力。这里说的记忆至少分成两层第一层是会话内的短期记忆直接存放在 messages 数组中第二层是跨会话的长期记忆一般依赖向量数据库和用户标识。测试时可以先问“我今天想去上海玩”下一轮再问“那里天气怎么样”看 Agent 是否能关联到“上海”这个上文实体。如果模型忘记了排除思路是先检查 messages 是否完整传递再看上下文是否因为超长被截断最后考虑是否需要引入摘要记忆或向量检索。建议在测试多轮能力时同步记录 Token 消耗。因为随着对话轮数增加输入 Token 会线性增长如果没有压缩摘要成本会很快上升。5.3 路由与任务编排测试Agent 不只是单一问答还可能需要根据任务类型分发到不同的子流程。比如一个客服智能体可以根据用户需求路由到订单查询、售后流程、商品推荐。测试时重点看分支判断是否准确、是否出现来回跳转、超时后是否有兜底回答。判断成功的标准是相似问题能稳定进入同一个分支边界问题不会频繁跳分支链路异常时有统一兜底文案。排查时优先检查系统提示词中的路由规则是否过于模糊以及各分支节点是否都配置了默认回复。5.4 批量任务与稳定性测试Agent 开发完成以后批量任务测试是不可跳过的环节。这里的“批量任务”并不是简单 for 循环调用而是要关注三个问题模型服务限流、单任务失败是否影响整体、结果是否可结构化保存。可以先准备一份 20 条左右的测试输入文件包含正常文本、超长文本、空文本、纯符号文本、带敏感词的文本。用脚本逐条调用 Agent API记录成功数、失败数、平均响应时长、单条 Token 消耗。目标不是追求 100% 成功而是建立“失败可观测、可重试、可定位”的机制。6. 接口 API 与批量任务集成6.1 将 Agent 封装成 API 服务开发完成后Agent 需要作为服务提供给上层业务调用。最简单的方式是使用 FastAPI 封装一个 HTTP 接口。下面的示例是通用结构实际路由和参数可自行扩展from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class AgentRequest(BaseModel): user_input: str session_id: str default class AgentResponse(BaseModel): output: str session_id: str app.post(/agent/invoke, response_modelAgentResponse) def invoke_agent(req: AgentRequest): # 这里调用上一节写好的 run_agent 或平台 API output run_agent(req.user_input) return AgentResponse(outputoutput, session_idreq.session_id) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动服务uvicorn main:app --host 127.0.0.1 --port 8000启动之后可以用 curl 验证接口curl -X POST http://127.0.0.1:8000/agent/invoke \ -H Content-Type: application/json \ -d {user_input: 北京天气怎么样, session_id: test-001}如果接口能返回模型生成的文本说明 Agent 已经可以作为后端服务被其他系统调用。6.2 批量任务脚本设计批量任务脚本至少需要具备以下能力读取输入、输出结构化结果、记录失败原因、支持重试。下面是一个通用示例import json import time import requests API_URL http://127.0.0.1:8000/agent/invoke tasks [ 北京天气怎么样, 推荐一部科幻电影, 把这段文本改写得更正式老板好我不干了, ] results [] for idx, task in enumerate(tasks): payload {user_input: task, session_id: fbatch-{idx}} try: resp requests.post(API_URL, jsonpayload, timeout120) resp.raise_for_status() data resp.json() results.append({task: task, status: success, output: data[output]}) except Exception as exc: results.append({task: task, status: failed, error: str(exc)}) # 注意限流间隔时间需根据实际模型服务调整 time.sleep(1) with open(batch_result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(完成:, len(results))生产级批量任务建议进一步接入任务队列。简单场景可以使用 Python 的队列模块复杂场景建议使用 Celery、MQ 或云厂商的消息队列。批量任务的关键设计原则是每条任务之间不共享状态失败任务可以单独重跑结果写入独立文件或数据库字段所有输入输出都要有 trace_id 关联方便排查。7. 多智能体架构与 2026 趋势7.1 单 Agent 的局限单个 Agent 做所有事情在一两个工具、简单流程上没有问题但一旦任务变多问题就出现了。最典型的是“上下文污染”内部指令、工具描述、历史对话、临时结果全部堆在一个上下文中模型很容易被无关信息干扰。其次是职责不清晰一个 Agent 既要理解用户意图又要调订单接口还要写话术后续维护非常困难。因此社区越来越多地转向多智能体方案。7.2 多智能体协作的常见模式在实际工程中多智能体并不是“多个 Agent 一起聊”而是围绕任务拆分和结果汇总设计固定协作模式。常见的有三种。第一种是主管-工人模式也就是 Supervisor Workers。顶层一个主管 Agent 理解用户目标将任务拆分成子任务下发给多个专门 Agent然后汇总结果。这种模式适合任务类型差异大的场景比如需要同时查订单、查物流、查优惠券的场景。第二种是流水线模式多个 Agent 按顺序执行前一个 Agent 的输出是后一个 Agent 的输入。这种模式适合有固定流程的业务比如内容审核、文章改写、数据清洗。关键在于每个 Agent 都要有明确的输出格式约定否则链路会中断。第三种是路由分发模式主 Agent 只做任务分类将请求直接转发给对应领域的 tool 或子 Agent。这种模式效率高但分类准确性要求高需要做大量边界测试。实现多智能体时LangGraph 和 Dify 工作流是两条主流路线。LangGraph 适合代码层面控制状态流转适合有复杂状态和条件分支的工程Dify 工作流则适合快速搭建和可视化调试。如果目标是就业建议至少掌握一种代码级编排框架它有更强的可扩展性和调试能力。7.3 2026 年值得关注的方向从社区讨论趋势看2026 年 Agent 开发的热点主要集中在MCP 工具协议逐步成为 Agent 与外部工具之间的标准连接方式可观测性成为 Agent 上线必备能力每轮思考、工具调用、Token 消耗都需要可视化追踪轻量级智能体部署方案在个人开发者和 Windows 用户中流行起来比如社区里讨论较多的 Hermes、Microduck 等方案但具体安装和使用请以各项目的官方仓库说明为准不要轻信未验证的一键包多智能体编排逐渐从实验走向工程企业开始关注稳定性、权限隔离和成本控制。8. 资源占用与性能观察8.1 纯 API 模式下的资源占用如果 Agent 调用的是云端模型 API本地资源占用主要集中在 Agent 服务进程和依赖服务上。Python 单进程占用内存通常在几百 MB 以内CPU 消耗主要来自 JSON 解析、请求转发和日志写入对显存没有要求。这种情况下性能瓶颈主要集中在网络延迟和模型服务响应速度上。8.2 本地模型部署的显存观察如果要在本地部署开源模型情况就不同了。先说方法启动模型推理服务后可以通过nvidia-smi观察显卡显存占用。下面命令是通用方式# 每 2 秒刷新一次显存状态 watch -n 2 nvidia-smi显存占用不是固定值它取决于模型参数量、量化位数、上下文长度、并发请求数。更稳妥的判断是第一次启动后先请求一条短文本记录显存基线再请求一条长文本或开启多并发对比显存增长最后通过降低模型上下文长度、减少最大并发数、切换更低比特量化来优化。8.3 延迟与成本优化Agent 的延迟不是模型生成时间决定的而是多轮调用总和。一次工具调用可能产生两到三次模型请求所以延迟和成本会成倍放大。优化手段包括控制工具数量、精简工具描述、限制最大工具调用轮数、使用摘要记忆而不是无限叠加历史、对简单任务使用小模型、对复杂任务使用大模型。这里建议在 Agent 业务代码中记录一个结构化日志至少包含 user_input、model、tool_calls、prompt_tokens、completion_tokens、latency_ms、created_at 这几个字段这是后续定位延迟问题和成本分析的基础。9. 常见问题与排查方法问题现象可能原因排查方式解决方案模型不调用工具直接瞎回复工具描述不清晰或模型不支持 Function Calling检查模型服务能力查看完整请求日志重写工具描述换支持工具调用的模型工具参数解析失败模型返回 JSON 格式不规范打印模型原始输出查看 tool_call.function.arguments 内容增加异常捕获重试一次或要求模型输出纯 JSON多轮对话后模型忘记上文上下文未正确传递或上下文过长被截断检查 messages 是否包含历史记录保留完整 messages引入摘要记忆或向量检索接口调用超时模型推理过慢或网络代理异常查看服务日志和模型服务监控设置更长超时开启流式输出检查网络连接启动服务后页面无法访问端口被占用或容器未就绪查看 docker compose logs检查端口占用更换端口等待容器健康检查通过批量任务中途卡住某条任务请求未结束或触发限流打印当前正在处理的任务索引增加超时时间失败自动重试加入限流等待Token 成本上升很快工具调用轮数过多历史消息无限增长查看日志中的 prompt_tokens 变化限制最大轮数使用摘要压缩历史本地模型显存不足模型过大或上下文过长观察 nvidia-smi查看推理引擎日志切换量化模型减小上下文长度降低并发排查问题有一个基本原则先看日志再看请求数据最后才是改代码。Agent 是链式调用如果最终结果不对问题可能出在任意一环。建议在开发阶段就保留完整的请求和响应日志尤其是模型原始输出因为它能一次性暴露工具调用名、参数字段、截断位置等问题。10. 最佳实践与安全合规Agent 开发越到后期工程化规范越重要。下面几条是从实际开发中总结出来的通用最佳实践。第一工具权限最小化。Agent 能访问的工具越多被误用和注入的风险越大。每一个工具接口都要确认是否有越权风险敏感操作必须增加人工审批节点。比如“发送短信”“删除数据”“修改订单”这类操作不要让模型单轮直接触发。第二提示词注入防护。用户输入可能伪装成系统指令诱导 Agent 输出内部提示词或执行非预期操作。实践中有两类防御措施一类是把用户输入与系统指令做明确分隔始终把用户输入当作不可信数据另一类是在工具调用前增加规则校验比如只允许特定工具在白名单内执行。第三批量任务要有幂等设计。如果批量任务执行到一半失败重新执行时不能重复扣款、重复发送消息或重复写入数据。建议在业务层面增加任务 ID 或 trace_id执行前查询是否已经处理。第四输出内容要合规。Agent 生成的内容不能包含涉政、暴力、色情、诱导违法行为等信息。上线前建议接入内容审核接口而不是只依赖模型自带的安全对齐。第五隐私数据处理要谨慎。如果 Agent 需要处理用户手机号、地址、身份证等隐私信息建议脱敏后再送入模型工具日志中也不能记录明文。涉及声音克隆、人脸生成、数字人等能力时必须确认已获得肖像权和声音授权。第六保留一套最小可运行配置。在项目目录下保存一份已经验证通过的模型配置、环境变量模板和启动命令避免重新部署时到处找参数。建议使用.env.example保存所有占位符配置用 README 记录启动步骤。11. 总结与下一步AI Agent 开发是一个从接口调用到系统工程逐渐深入的过程。如果有人问先验证什么我的建议是先跑通一次“模型 → 工具调用 → 工具结果回填 → 模型回答”的最小循环再逐步增加记忆、路由、批量任务和多智能体协作。这套链路跑通之后你就可以在 Dify、LangGraph、或自定义 Python 服务之间灵活切换也能更快理解社区里各种 Agent 项目的设计思路。本文出现的代码都是通用模板实际使用时要替换成你选择的模型服务商、工具列表和业务字段。文中没有写死显卡显存和端口号的地方也不是遗漏而是因为这些参数必须按实际环境确认。建议你先在 API 模式下跑通流程再评估私有化部署的硬件方案。后续可以扩展的方向很多把 Agent 接入企业知识库做 RAG 智能问答用 MCP 协议把公司内部工具统一接入在 LangGraph 里实现一个带人工审批节点的多智能体系统把批量任务迁移到消息队列并加上完善的失败重试机制。每一步落地都比继续刷概念有价值。建议收藏本文把第一节的学习路线作为自己的检查清单每完成一个阶段就回来对照一次。