AI Agent 开发在 2026 年已经不是“要不要学”的问题，而是“从哪里开始搭体系”的问题。如果你翻过招聘网站，会发现大量岗位描述里同时出现“LLM”“Agent”“RAG”“工具调用”这些词，但真到面试和实战时，很多人卡在同一个地方：能跑通 ChatBot，却不知道如何让模型自主决定调用哪个工具，也不知道怎么把多个 Agent 串成一个能落地的业务流程。这篇文章的价值，就是把一条从零搭建自定义智能体的完整学习路线拆开：从 LLM 的基础原理，到 Agent 的运行循环，再到工具调用、RAG 增强、接口封装、批量任务和问题排查，每一层都有可操作的内容，而不是只抛概念。
先给结论：学 Agent 开发不需要你先成为算法专家，真正需要的是“工程思维 + 对 LLM 行为模式的准确理解”。整条路线学下来，你应该能做三件事：第一，写一个能自主规划步骤、调用外部工具的 Agent；第二，把它封装成 HTTP 接口，接到自己的业务系统里；第三，在真实场景里测试、调优、排查问题，而不是停留在 Demo 阶段。这篇文章不会只讲某个单一框架，而是把从零搭建自定义智能体所涉及的公共知识讲通，再用具体代码演示最小可运行的 Agent 闭环，最后补充框架选型、接口服务化和工程化建议。
如果你符合以下任一情况，这篇文章可以完整读完：零基础想转大模型应用开发；已经在用 LLM 做 ChatBot，想升级成 Agent；后端工程师想接 Agent 能力到现有系统；或者你只是想搞清楚市面上那些 Agent 产品到底是怎么实现的。下面直接进入正题。
1. AI Agent 开发学习路线核心能力速览
先给一张总览表，方便你对照自己的进度。这套表中每一项，后续章节都会展开。
| 学习主题 | 核心技能点 | 可落地产出 | 建议投入 |
|---|---|---|---|
| LLM 基础原理 | 模型调用、Token、上下文窗口、提示词设计 | 理解并跑通任意大模型 API | 2 天 |
| Agent 运行机制 | ReAct 循环、Function Calling / Tool Calling | 完成一次“模型决定调用工具”的最小闭环 | 3 天 |
| 记忆与多轮对话 | 上下文管理、短期记忆、长期记忆、向量检索 | 支持长时间会话的 Agent | 3 天 |
| RAG 增强 | 文档加载、文本切分、向量化、检索召回、重排 | 基于私有知识库的问答 Agent | 4 天 |
| 工具与工作流 | 工具注册、参数校验、多工具编排、条件分支 | 能处理复合任务的 Agent 流程 | 4 天 |
| 框架与低代码平台 | LangChain / Dify / Coze 等选型 | 用平台快速搭建 MVP，用代码做深度定制 | 3 天 |
| 接口服务化与批量任务 | FastAPI 封装、任务队列、日志、重试 | 可对外提供服务、可批量执行的 Agent 系统 | 4 天 |
| 评测与排查 | 效果指标、链路追踪、故障恢复 | 一套可持续迭代的 Agent 测试用例 | 3 天 |
从这张表能看出，Agent 开发不是“一个工具学到底”，而是多条技术线交叉。实际工作中，最常见的任务组合是“LLM + RAG + 工具调用”。例如做一个内部知识库助手，用户问“帮我查一下上季度项目总结”，Agent 需要先判断是不是要知道文档内容，决定是否触发 RAG 检索，检索完再判断是否需要调用某个内部系统接口，最后组织语言回复。理解这条链路，比背住某个框架的 API 更重要。
2. 适用场景与使用边界
Agent 开发适合解决四类问题：一是信息聚合类，比如从多个系统取数后汇总；二是流程自动化类，比如根据用户输入自动创建工单并分配负责人；三是内容生产类，比如按照固定模板生成周报；四是知识问答类，比如企业内部文档检索。这四类场景都有一个共同点：任务流程存在“分支决策”环节，不是简单的输入输出映射，而是需要模型根据上下文决定下一步做什么。
也有不适合用 Agent 硬套的场景。比如对延迟要求高到 200ms 以内的实时接口，不要用 Agent 串链路；对结果精确率要求 100% 的数值计算，不要直接依赖 LLM 输出，要加规则校验；涉及数据权限强隔离的场景，不要把所有数据都塞进上下文，先用权限系统做过滤。简单说，Agent 适合做“有边界的智能任务”，不适合做“不可控的开放生成”。
这里必须强调使用边界。开发过程中你会接触大量数据，可能是用户聊天记录、文档、业务数据库内容，这些数据在使用前要明确授权范围。调用第三方程大模型 API 时，注意不要上传包含敏感个人信息或商业秘密的内容，除非对方明确允许且链路满足合规要求。如果你打算做语音、图像或数字人相关的 Agent，还要格外注意肖像和声音授权。另外，Agent 调用外部工具时，必须限制权限，比如数据库只读、文件路径白名单、网络请求域名白名单，避免因为模型误触发工具导致破坏性操作。任何自动化能力都应该在测试环境充分验证后再考虑上线。
3. 学习前置条件与环境准备
不建议完全零编程基础直接学 Agent。最少要有这些底子：能读懂 Python 代码并写简单脚本；知道 HTTP 请求的基本概念，会用 curl 或 Postman；了解命令行基本操作，比如切换目录、创建虚拟环境；具备初步的 API 调用经验，用过任意一个 REST API。满足这些条件，后续学习会顺畅很多。
环境方面，准备一台能联网的开发机即可，Windows、macOS、Linux 都行。推荐安装的内容和版本建议如下，实际以你的系统为准：
# 建议使用 Python 3.10 以上的版本 python --version # 创建独立虚拟环境，避免依赖冲突 python -m venv agent_env # 激活虚拟环境 # Windows agent_env\Scripts\activate # macOS / Linux source agent_env/bin/activate # 基础依赖 pip install openai python-dotenv requests fastapi uvicorn大模型本身有两种接入方式。第一种是云端 API，推荐新手直接从这种模式开始，优点是零显存门槛，只需一个可用的 API Key；第二种是本地模型，比如通过 Ollama 或 vLLM 启动本地模型服务，适合数据敏感场景，但需要一台配置合适的 GPU 机器，显存占用和推理速度都与模型参数量、量化方式有关，需要以你本机实际测试为准。更稳妥的建议是：本地模型用来学习和调试，生产环境按业务需求选择 API 或内网私有化部署。
另外准备一个 Dify 或 Coze 这类低代码/开源平台账号不是必须的，但建议在后面学习框架选型时注册一个，这样的平台适合快速搭 MVP，能帮你先验证业务想法，再决定要不要用代码深度定制。不需要一开始就把所有工具都装齐，每到一个阶段再引入对应工具，效率更高。
4. 核心概念拆解：LLM、Agent、工具调用、记忆、RAG
很多人学 Agent 学不下去，是因为概念都认识，但不知道它们之间的关系。下面用一条主线把概念串起来。
- LLM 是“大脑”但不是“身体”。大模型擅长理解自然语言、生成内容、做一定程度的推理，但模型本身不能主动发起 HTTP 请求、查询数据库、执行代码或访问本地文件。
- Agent 是“大脑 + 身体”的组合。一个最小 Agent 至少要包含：一个 LLM 作为决策核心，一组可以调用的工具（Tool），以及一个运行循环（Loop），让模型在“观察现状 -> 决策行动 -> 执行工具 -> 观察结果”之间反复迭代，直到完成任务。
- 工具调用是 Agent 的“手”。实现机制是 Function Calling / Tool Calling：把每个工具的描述和参数结构以 JSON Schema 形式传给模型，模型根据用户需求选择调用哪个工具，并输出结构化的调用参数，然后由程序执行真正的函数。
- 记忆是 Agent 的“长期状态”。短期记忆就是当前会话的上下文，靠拼接历史消息实现；长期记忆依赖外部存储，比如把重要事实向量化后存入向量数据库，按需检索。
- RAG 是 Agent 的“知识补充包”。把外部文档切分成片段、向量化、建好索引；接收问题时先检索相关片段，再把检索结果作为额外上下文交给 LLM。RAG 解决的是“模型不知道你私有数据”的问题。
把这个链路放到一个真实例子里：用户说“帮我统计这周销量最高的三个城市”。Agent 的运行循环是这样的：LLM 判断需要查数据库，于是输出一个调用 get_sales_data 的请求，参数是“本周”；程序执行这个函数拿到原始数据；数据回填给 LLM，由 LLM 生成最终回答“上海、广州、杭州”。整个过程里，LLM 负责“判断和表达”，代码负责“执行和获取”，缺一不可。
5. 从零搭建最小可用 Agent：Python 实操
5.1 设计目标与项目结构
理解原理后，最有效的验证方式是自己写一个几十行的 Agent。目标定小一点：做一个命令行工具，支持三个工具——获取当前时间、计算器、模拟查询今日天气。用户输入自然语言，Agent 自主决定调用哪个工具并输出结果。项目结构如下：
agent_demo/ ├── main.py # Agent 主循环 ├── tools.py # 工具定义与执行函数 ├── llm_client.py # LLM 调用封装 ├── config.py # 配置项：API Key、模型名、base_url ├── .env # 存放环境变量 └── requirements.txt # 依赖列表5.2 LLM 客户端封装
无论你使用哪个大模型平台，只要能提供 OpenAI 兼容接口，下面的封装方式基本通用。实际请求地址、模型名称、密钥获取方式以你的平台文档为准，建议把这些配置放到环境变量里：
# llm_client.py import os from openai import OpenAI client = OpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL", "https://api.openai.com/v1"), ) MODEL_NAME = os.getenv("LLM_MODEL_NAME", "gpt-4o-mini") def chat(messages, tools=None, temperature=0.2): response = client.chat.completions.create( model=MODEL_NAME, messages=messages, tools=tools, # None 表示不使用工具调用 temperature=temperature, ) return response.choices[0].message5.3 工具定义与执行
工具定义的核心是一份“给模型看的说明书”和一份“给程序执行的函数”。说明书要写清楚工具什么时候用、参数含义，模型会靠这些信息做选择：
# tools.py from datetime import datetime import json # 1. 工具说明书：符合 Function Calling 的 JSON Schema TOOLS = [ { "type": "function", "function": { "name": "get_current_time", "description": "获取当前日期和时间", "parameters": { "type": "object", "properties": {}, "required": [] } } }, { "type": "function", "function": { "name": "calculator", "description": "执行基础数学计算，接收一个数学表达式字符串", "parameters": { "type": "object", "properties": { "expression": { "type": "string", "description": "例如 (12 + 34) * 5" } }, "required": ["expression"] } } }, { "type": "function", "function": { "name": "query_weather", "description": "查询指定城市今日天气", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，例如 上海" } }, "required": ["city"] } } } ] # 2. 工具执行函数：真正干活的代码 TOOL_FUNCTIONS = { "get_current_time": lambda **kwargs: datetime.now().strftime("%Y-%m-%d %H:%M:%S"), "calculator": lambda expression: str(eval(expression, {"__builtins__": {}}, {})), "query_weather": lambda city: f"{city}今日天气：多云，24~31℃，东南风3级", }注意：这里的eval仅为教学演示，生产系统必须用安全表达式解析库或沙箱执行，否则有代码注入风险。
5.4 Agent 主循环
接下来是核心的 ReAct 循环。流程是：把用户输入加入消息列表 -> 带工具列表调用 LLM -> 如果返回的是工具调用请求，就执行对应的函数，把结果作为新的消息追加进去 -> 再次调用 LLM，直到模型输出最终回答：
# main.py import json from llm_client import chat from tools import TOOLS, TOOL_FUNCTIONS def run_agent(user_input: str, max_iterations: int = 5): messages = [{"role": "user", "content": user_input}] for _ in range(max_iterations): response_message = chat(messages, tools=TOOLS) # 情况一：模型没有请求调用工具，说明可以直接给出最终回答 if not response_message.tool_calls: return response_message.content # 情况二：模型请求调用工具 messages.append(response_message) for tool_call in response_message.tool_calls: name = tool_call.function.name arguments = json.loads(tool_call.function.arguments) result = TOOL_FUNCTIONS[name](**arguments) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result, }) return "达到最大迭代轮数，任务未能完成。" if __name__ == "__main__": while True: user_input = input("你：") if user_input.lower() in ("exit", "quit"): break print("Agent：", run_agent(user_input))5.5 运行与判断标准
启动前确认.env文件已配置好 API Key、模型名和 base_url，然后执行：
python main.py建议依次测试这样的输入：
你：现在几点了？ 你：帮我算一下 (12 + 34) * 5 你：上海今天天气怎么样？ 你：先用计算器算 123*456，再告诉我上海天气判断成功的标准有三个：模型能根据语义选择正确的工具；多轮工具调用能被正确回填给模型，最后生成自然语言答案；单次任务能在一个循环内完成，不出现死循环。如果模型一直不输出工具调用，先检查工具描述是否写清楚了触发条件；如果工具结果回填后报错，检查tool_call_id和角色是否为tool。
6. 框架选型与低代码平台实战
自己写一遍最小 Agent 之后，你就具备了判断框架的能力。市面上的工具大致分成三类。
第一类是代码框架，代表包括 LangChain、LangGraph、LlamaIndex、AutoGen、CrewAI。LangChain 生态成熟但抽象层级多，适合快速集成各种模型和工具，但调试时容易绕；LangGraph 强调有向图式的流程控制，适合复杂任务编排、条件分支和循环，如果你要控制 Agent 的行为走向，可以优先考虑；LlamaIndex 更适合做文档检索和 RAG 深度集成的场景；AutoGen 和 CrewAI 则偏多智能体协作，适合研究“多个角色聊天协作”的玩法。选框架不要贪多，建议先主攻一个，跑通一个完整业务闭环。
第二类是低代码/开源平台，典型代表是 Dify 和 Coze。如果你业务链路涉及表单填写、用户指令分派、知识库问答、定时任务，这类平台能帮你把 MVP 在几小时内搭出来。Dify 比较适合国内开发者和有私有化需求的人，可以本地部署，支持 Workflow 编排，也提供了内置的知识库、变量、会话管理。低代码平台的学习重点不是记住每个节点，而是理解“输入变量 -> 模型节点 -> 搜索工具 -> 条件判断 -> 输出变量”的数据流。先用这类平台验证“业务到底需不需要 Agent”，再回到代码做深度定制，学习效率更高。
第三类是大模型服务商的 Agent 开发套件，比如各家云厂商提供的智能体工作室。这类平台一般把模型能力、插件生态、知识库和渠道发布都做好了，适合快速上线内容型应用，但自定义能力受平台限制。实际选型建议很简单：验证想法用低代码平台，生产环境要深度定制用代码框架，追求快速上线且不用深度控制用云厂商套件。
7. 功能测试与效果验证
Agent 的测试要比传统软件多一层“不确定性”维度，因为同一个输入，模型可能给出不同结果。你会需要一套“固定输入 + 运行多次 + 统计结果”的验证思路。
功能测试建议覆盖六类：单轮工具调用是否精准；多轮多工具调用链路是否顺畅；自然语言边界情况是否兜得住，比如错别字、口语化表达、上下文指代；长上下文会话是否遗忘前文；工具参数不完整时模型是否会追问；非任务意图是否会被拒答。用表格记录更直观：
| 测试用例 | 输入示例 | 预期行为 | 通过标准 | | --- | --- | --- | --- | | 单工具调用 | “今天上海热吗” | 调用 query_weather | 返回天气信息且参数正确 | | 歧义处理 | “帮我算一下” | 追问具体表达式 | 不抛出异常，能引导用户补全 | | 多工具链路 | “明天上海会下雨吗” | 先取时间，再查天气，再回答 | 两次工具调用结果都正确 | | 非任务意图 | “帮我骂一下老板” | 拒绝 | 输出安全合规的拒绝话术 |效果验证三板斧：第一看任务完成率，也就是所有步骤走完并给出有效回答的比例；第二看工具调用准确率，分开统计“该调工具时调了”和“不该调时没调”；第三看 Token 消耗，同一个任务调优前后对比，目标是用更少的 token 完成同等效果。如果某次测试输出质量不稳定，优先检查是否提示词指令不够明确、工具描述是否含糊、上下文是否塞入了无关信息。
8. 接口 API 与批量任务
Agent 做出来之后，不可能永远只停留在命令行，迟早要对外提供服务。推荐用 FastAPI 封装一层。思想是：把上一节写好的run_agent作为核心处理函数，HTTP 接口负责接收请求、调用 Agent、返回结果：
# api.py from fastapi import FastAPI from pydantic import BaseModel from main import run_agent app = FastAPI() class AgentRequest(BaseModel): message: str user_id: str = "default" class AgentResponse(BaseModel): reply: str @app.post("/agent/chat", response_model=AgentResponse) def chat_with_agent(req: AgentRequest): reply = run_agent(req.message) return AgentResponse(reply=reply)启动服务：
uvicorn api:app --host 127.0.0.1 --port 8000用 curl 测试接口：
curl -X POST http://127.0.0.1:8000/agent/chat \ -H "Content-Type: application/json" \ -d '{"message": "上海今天天气怎么样？", "user_id": "test001"}'接口服务化之后，批量任务也随之而来。比如要给一批输入文本逐个生成结构化分析，常见做法是维护一个任务队列，每次取出一个任务执行，把状态和结果写入日志：
import json import logging from main import run_agent logging.basicConfig(level=logging.INFO) def process_batch(input_file: str, output_file: str, max_workers: int = 4): with open(input_file, "r", encoding="utf-8") as f: tasks = json.load(f) results = [] for task in tasks: try: logging.info("处理任务开始: %s", task["id"]) reply = run_agent(task["message"]) results.append({"id": task["id"], "status": "success", "reply": reply}) logging.info("处理任务成功: %s", task["id"]) except Exception as e: logging.error("处理任务失败: %s，错误：%s", task["id"], e, exc_info=True) results.append({"id": task["id"], "status": "failed", "error": str(e)}) with open(output_file, "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2)批量任务三个原则：每个任务独立记录日志；失败任务要单独落盘而不是直接丢弃；任务处理前先做小批量测试，比如先跑 5 条再跑全部，避免大量调用消耗 token 后才暴露问题。接口服务的访问范围也要注意，生产环境建议加鉴权，至少限制在可信内网。
9. 资源占用与性能观察
很多人误以为 Agent 开发只有模型推理成本，实际上资源占用要看两段：模型调用侧和应用服务侧。
如果你用的是云端大模型 API，这部分成本主要体现为 token 消耗，而不是本地显存。观察指标包括单次任务平均输入 token、输出 token、调用次数。性能调优的核心是减少无效调用，比如 Agent 在不需要调用工具时就不要传 tools 参数，避免模型纠结要不要调工具；多轮对话只保留最近几轮关键信息，而不是把所有历史都塞进上下文；尽量用结构化输出，减少生成内容长度。
如果你选择本地部署模型，则要关注推理延迟、显存占用和吞吐量。显存占用与模型参数量、量化精度、上下文长度有直接关系，例如参数量越大的模型需要越多显存，加载后模型常驻显存是常见现象。这部分不要相信网上任何固定的“几张显卡够用”结论，必须按实际模型、量化方式和并发模拟结果来判断。观察方法很简单：启动服务后，在 Linux 上用nvidia-smi持续查看显存变化，或者用带指标面板的服务框架观察推理期间显存峰值。
还有一类资源经常被忽略，就是 RAG 链路里的向量化服务和外部依赖。如果知识库大，向量化会消耗大量 CPU/内存；如果 Agent 在运行中频繁调用外部 API，网络延迟会直接变成用户可感知的等待时间。性能优化顺序建议是：先看工具调用链路，再看上下文长度，再看模型并发设置，最后才考虑换更大的模型。
10. 常见问题与排查方法
Agent 开发过程中，下面这些问题是出现频率最高的，整理成排查表方便对照：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 请求报错：llm request timed out | 网络连接不稳定或模型响应过慢 | 检查网络，缩短输入长度，查看服务端日志 | 增加客户端超时时间；重试；改为流式输出 |
| 报错：provider rejected the request schema or tool payload | 工具 JSON Schema 格式不符合要求 | 打印 tools 参数，逐个字段校验 | 按平台文档调整 Schema；去掉不支持的字段 |
| 模型输出经常包含“思考过程”，干扰结果解析 | 使用了带推理链的模型，且未关闭思考输出 | 查看模型平台设置 | 在平台关闭思考模式，或在提示词中要求只输出最终结果 |
| 上下文超长报错 | 多轮对话累积历史过长，或 RAG 片段过多 | 打印消息数组中每个角色消息的长度 | 做消息裁剪、摘要压缩；限制检索片段数量 |
| Agent 不调用工具，直接乱答 | 工具描述不清晰，或模型型号不支持 Function Calling | 测试换个支持工具调用的模型；检查 tools 是否真正传入 | 优化工具描述，明确触发条件；更换模型 |
| 工具参数总是解析失败 | 模型返回的 JSON 格式不合法 | 打印原始返回内容 | 用参数容错解析；给模型提供 example 参数示例 |
| 批量任务跑到一半卡住 | 单任务异常导致主流程中断 | 查看日志，找到卡住的任务 | 增加任务级 try/except 和轮次超时控制 |
| 同一个任务多次结果不一致 | 模型本身随机性，或提示词不够明确 | 固定 temperature 参数，多次运行对比 | 关键任务加规则校验；温度调低；使用结构化输出 |
| API Key 无效或配额不足 | 密钥配置错误或余额用完 | 检查环境变量、控制台用量 | 重新配置密钥；绑定付款方式或更换账号 |
| 本地模型推理极慢 | 显存不足引发换页，或并发数过高 | 观察 nvidia-smi 显存、CPU 占用 | 降低并发；换更小的模型；减少上下文长度 |
排查 Agent 问题时有一个通用技巧：在关键节点都打日志，把“模型原始输出”“工具执行结果”“回填给模型的工具消息”分别打印出来。问题往往一眼就能定位，到底是模型决策错了、工具执行错了，还是参数传错了。
11. 最佳实践与工程化建议
把 Agent 从 Demo 变成可用系统，有一些工程化经验值得尽早内化。
第一，第一次调试先小参数测试。无论模型 API 还是本地模型，先用最短输入跑通链路，再逐步增加上下文长度和工具数量，避免一上来就排错混乱。每次只改一个变量，记录前后效果变化。
第二，保留一套最小可运行配置。把第 5 节那个最小 Agent 单独存成一个目录，不要和复杂的 RAG 链路混在一起。出问题时回退到最小配置做对比，往往是定位问题最快的方式。
第三，目录和配置管理要规范化。模型 API Key 放环境变量或密钥管理服务，不要写进代码库。输入素材、中间日志、最终输出按日期和任务 ID 分目录存放。提示词模板本身也是代码，要纳入版本管理。
第四，批量任务必须加日志和失败重试。每个任务记录开始时间、结束时间、状态、错误信息、token 用量。失败任务先落盘，再设计重试策略，比如区分“临时网络错误重试 2 次”和“参数错误不重试直接告警”。
第五，接口服务要限制访问范围。线上环境加鉴权，限制请求频率，设置单次请求超时，否则大量外部调用可能产生不可控成本。如果 Agent 会调用内部系统，建议把工具本身的权限收敛到最小，比如查询接口只读、写操作必须二次确认。
第六，涉及数据、人脸、声音、版权素材时必须确认授权。无论是做知识库文档、RAG 数据源，还是接入语音合成、图像生成、数字人能力，都要只使用有合法来源和明确授权的素材。测试环境使用真实用户数据前，要做脱敏处理。任何生成内容的发布或商用，都要做效果复核，不能直接由模型输出流转到公开渠道。
12. 总结与下一步
这套学习路线里，最值得先掌握的内容是第 4 节和第 5 节，也就是 Agent 运行机制和最小代码实现。把这部分吃透，后面无论换什么框架、什么平台，你都能快速上手，因为你理解的是本质，而不是某个框架的专属写法。最容易踩的坑是：跳过了原理，直接抱着 LangChain 或 Dify 操作，结果出现问题后完全不知道是模型决策问题还是工具执行问题。只要你能自己写出那个最小运行循环，这类问题就会变得很好排查。
接下来你可以按这个顺序继续扩展：先把手动编写的三个工具替换成真实业务接口，比如查数据库、调用内部 API；再引入一个向量数据库，把静态知识库变成 RAG 链路；然后尝试 LangGraph 或 Dify 把流程可视化；最后给你的 Agent 加一套评测用例，让每次改动都有量化结果。每一步做完都用固定输入验证一次，整条链路就会越来越稳定。Agent 开发方向的技术栈迭代很快，但核心的“模型决策 + 工具执行 + 上下文管理”这套骨架不会变，把它练熟，比追逐每一个新框架都更值。
