开局先聊个现象这两年“大模型Agent开发”已经成了AI圈子里一个绕不开的热词从一线大厂的技术分享到独立开发者的周末项目几乎都在往这个方向靠。但真要上手做你会发现网上教程要么停在“调API聊天”的玩具Demo要么一上来就甩完整的多智能体架构中间那段“怎么把一个能对话的模型变成能自己干活、能调用工具、能拆解任务的Agent”的路径反而是最模糊的。这篇文章想做的事很直接带你把大模型Agent开发的底层逻辑捋清楚然后走一遍从模型选型、框架搭建到工具调用、问题排查的完整链路。不管你是刚入门想做个人助理型Agent还是公司里想做个内部知识库问答机器人文里的思路和方法都能直接落地。我会把我实际开发中踩过的坑、试过之后觉得好用的方案、以及一些常规文档里不会写的细节全部填进去尽量让你看完之后能自己动手写一个真正能跑起来的Agent。1. 整体设计思路拆解Agent到底是什么它和普通程序差在哪1.1 从“对话模型”到“Agent”的本质跃迁很多朋友第一次接触大模型Agent时会有个疑惑我已经能调大模型API了给它一段 Prompt 就能回答问题这难道不就是Agent吗严格来说还差得远。经典意义上大模型App是你问一句它答一句主动权在用户手里而Agent是把这个关系倒过来——模型拿到一个目标后自己去规划步骤、调用工具、检查结果、迭代执行直到把任务完成。举个例子让普通大模型“帮我订一杯咖啡”它会回你一段代码或者一个步骤说明但不会真去下单。而Agent会自己去查附近有哪些店、比价、调用下单接口、支付最后告诉你咖啡已经在做了。这个变化的根源是大模型从“语言模型”变成了“推理引擎”。它不再只是预测下一个字而是能基于上下文做规划、分类、决策甚至生成调用外部工具的指令。Agent就是在模型外面套了一层壳这层壳负责把大模型的能力和真实世界的系统连接起来比如搜索、数据库、办公软件、代码执行环境等等。所以学习Agent开发核心要解决的从来不是“怎么让模型说话”而是“怎么让模型正确地动起来”。1.2 一个Agent的基本组成单元我看过很多把Agent架构画得特别复杂的教程其实剥开来看万变不离其宗。一个完整可用的Agent再花哨也逃不出这四块第一是模型底座这是大脑。模型选型决定Agent的上限比如上下文长度不够、工具调用格式支持不好、推理能力弱后面做再多优化都白搭。第二是规划引擎这是小脑。它决定了模型拿到一个任务后是直接给出答案还是拆成思考步骤、边做边看环境反馈。目前用得最多的方案是ReAct模式Reasoning Acting先推理后行动行动后再推理让模型每走一步都输出“我在想什么、我要做什么”然后根据动作结果修正下一步。第三是工具集这是手脚。一个Agent没有工具就像人只有大脑没有手什么都干不了。工具可以是搜索API、SQL查询、计算器、脚本执行器也可以是内部业务接口。开发中最核心的工作之一就是把工具的描述和参数定义清楚让模型知道这些工具是干嘛的、什么时候该用。第四是记忆系统这是短期和长期记忆。短期记忆靠模型自己的上下文窗口管理长期记忆靠外部存储比如向量数据库、Redis等。没有记忆的Agent做完一个任务就“失忆”很多多轮协作场景根本跑不起来。理解了这四块你再去看各种Agent框架会发现它们本质上都是在帮你组装和调度这四样东西只是封装层级和灵活性不同。1.3 为什么今年Agent开发突然“能落地”了Agent这个概念其实很多年前就有但过去喊了好多年都偏实验室化原因是模型能力撑不起“自主规划”。2023年以后情况变了一是大模型的指令跟随能力大幅增强你给它工具描述它能像模像样地决定调用哪个、参数填什么二是推理成本降下来了本地部署的小模型也能跑顺简单Agent三是各家API陆续支持Function Calling模型输出的不再只是自然语言而是带格式的结构化调用指令。这三个条件凑齐Agent才真正具备了商业落地的土壤。现在你去看各大云厂商推出的产品很多都是“大模型工具调用”的Agent壳比如能自动查天气、查库存、写邮件、处理工单的应用。了解了它们背后的原理再动手做自己的Agent心里就会非常有底你不是在“发明”什么玄学而是在组装一套已经成熟的工程组件。2. 工具选型解析模型、框架和部署方案怎么搭最稳2.1 模型选型大模型API、开源模型和本地部署之间的取舍模型选型是Agent开发里第一个要拍板的决定也是后面最不好改的决定。我在实际项目中踩过几次换模型的坑之后总结出这么一套选择逻辑先看你的场景对“模型能力”的敏感度再看“数据隐私”和“成本预算”。如果做的是通用型Agent比如办公助手、个人知识库问答直接用云厂商的大模型API是性价比最高的选择。国内外的头部模型API都支持Function Calling一次请求能同时拿到“自然语言回复”和“结构化工具指令”开箱即用的程度非常高。好处是模型能力天花板高、不用管GPU运维、迭代更新由厂商负责坏处是按token计费高频调用、长上下文的任务成本会涨得很快。如果对数据隐私有硬性要求比如企业内部的合同审查、金融数据分析或者团队里已经有多余的GPU资源那就考虑本地部署开源模型。目前主流的本地部署模型选择像Qwen系列、Llama系列在Agent场景下拉满量化后的7B模型基本可以跑通简单工具调用14B以上模型的规划和指令跟随能力会明显好一截只要显存够用体验接近中等水平的商业API。这里给一个硬指标供参考Agent跑工具调用时模型需要忠实跟着指令输出特定JSON格式。如果模型太小比如3B以下量化参数经常会出现格式混乱、字段丢失、拒绝执行工具调用等情况。实际测试中我建议Agent开发的最低门槛是7B级别安全和稳定要从14B起步。这也是为什么很多企业私有化部署时宁可用中等模型加多次重试也不盲目追“跑得动的小模型”。2.2 框架选型LangChain、LlamaIndex还是自研框架是Agent开发里争议最大的话题。我的观点是初期首选一个成熟框架把链路跑通后期当需求复杂到框架成为障碍时再考虑自研。先聊聊LangChain这是目前生态最深、参考资料最多的框架。它在Agent领域的核心价值是内置了标准化的模型调用封装、工具加载器、记忆管理器、Agent执行器你只需要定义好工具列表框架自动完成“模型生成指令→执行工具→回填上下文→再次调用模型”的循环。缺点是抽象层多很多封装里的细节对开发者不透明排查错误时容易一头雾水。如果你已经有了一定的API调用经验我建议直接用LangChain但有心理准备出问题时一定要下钻到源码里看。如果是知识密集型的Agent比如“基于一堆文档回答复杂问题”LlamaIndex是更顺手的选择。它的核心优势在数据检索侧帮你把文档切块、向量化、召回然后再喂给模型做推理。用它来搭“RAG型Agent”比LangChain省很多功夫但通用工具调用能力相对弱一些。需要特别说的是很多人觉得“框架很重、我要自己写”。我的看法是如果你只是做一两个固定场景的Agent自研反而更清爽把“调模型”和“执行工具”这两个基础函数撸清楚一个循环每轮把历史消息、工具调用、执行结果拼接好发给模型就可以称为一个Agent了。框架的价值在应对多变场景和多Agent协作时才能完全体现出来你的场景越标准越不需要大框架。2.3 部署与执行引擎在线API、Ollama和vLLM怎么选如果把模型部署这块展开又能写一篇长文。这里只给Agent开发者最关心的结论。调用在线API时需要注意三件事一是API的并发限制很多免费额度或低价档会限制每秒请求数Agent内部经常会并行调用多个工具很容易撞上限流二是超时时间设置长任务模型的响应可能处理几十秒API客户端默认的30秒经常不够用三是多轮上下文累积导致token数不断上涨要提前规划好上下文截断策略。本地部署时我用过的方案里Ollama是入门最友好的一条命令就能拉起一个模型服务还自带来OpenAI兼容的接口格式可以直接无缝替换在线API的客户端配置几乎所有Agent框架都原生支持接入。它的缺点是server性能比较一般不适用于高并发生产环境。如果团队里有GPU服务器且Agent要面向生产流量vLLM是更专业的选择吞吐量比Ollama高出一个量级支持连续批处理等高级特性只是配置和维护复杂度明显更高。部署时的经验教训本地模型服务一定要自己做一层请求日志和错误监控Agent的Bug很多时候不是代码问题而是模型服务返回了「奇怪的空内容」或者「非法的JSON输出」。这层监控建好了排查问题的速度会快很多。3. 核心细节解析与实操要点把Agent的“手脚”练扎实3.1 Prompt 设计是Agent开发的第一生产力很多新手觉得Prompt设计就是把任务描述写得详细一点但在Agent开发里Prompt设计是一种结构性工程特别是系统提示词它会直接决定Agent的稳定性和工作效率。给Agent写的系统提示词我总结下来至少需要包含五块内容角色定义告诉模型它是什么“你是自动化流程助手”任务边界什么该做什么不该做“只处理指定的工具调用请求不回答无关问题”输出协议规定每一步输出的格式“必须输出JSON包含think和action两个字段”工具清单列出可用工具、参数说明、使用禁忌兜底策略模型不知道怎么办时的处理原则“如果不确定回复UNKNOWN”。这里有个常见误区把系统提示词写成“一大段散文”结果模型在长上下文中抓不住重点。实际经验是用极简的字段化描述一层一层递进模型遵从度会高很多。我自己习惯用类似这种结构你是订单处理Agent负责根据用户指令查询订单信息。 可用工具: - query_order(order_id): 查询订单状态参数order_id为字符串。 - cancel_order(order_id): 取消订单仅当订单状态为pending时可用。 输出要求: 每一步先输出一个think字段说明你的判断再输出一个action字段表示要调用的工具。 当没有合适工具时用final字段直接回答用户。这种写法会大幅降低模型乱编JSON的概率。别小看这个步骤我在项目里见过太多Agent乱写参数导致工具执行失败最后追根溯源全是Prompt里没说清楚。3.2 Function Calling让模型走进真实世界的钥匙Function Calling是Agent开发中最值得深挖的技术点。它的底层逻辑是你不直接把工具代码发给模型而是把工具的描述、参数名、参数类型、是否必填写成一个JSON Schema列表跟随请求发给模型。模型根据用户问题从工具列表里选中一个并生成符合参数结构的调用指令。整个过程模型本身不执行代码真正执行是在你的服务端。举个例子定义一个“查天气”工具时你提供给模型的Schema长这样{ name: get_weather, description: 查询指定城市当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } }模型收到用户说“北京今天冷吗”后可能会输出这样一个结构化指令{name: get_weather, arguments: {city: 北京}}你的程序解析到这个指令后去真实调用天气API再把天气数据作为一条消息回传给模型模型就能基于真实数据生成最终回复。这个过程就是Agent从“空谈”到“实干”的关键一步。实操里最常翻车的点有两个一是工具定义太多超出模型能力范围时模型经常选错工具或生成不存在的工具名。建议控制一次请求中工具数量在10个以内复杂的工具列表考虑分步加载二是参数值需要做严格校验。模型可能会生成超出枚举范围的参数比如状态字段填了“已完成”但你系统里没有这个值所以工具执行前一定要做二次校验不能盲目把模型生成的参数直接传给生产接口。3.3 记忆管理上下文是Agent最贵的资源Agent开发到后面你会发现限制你的不是模型智力而是上下文窗口和token成本。一个Agent在几轮交互后历史记录里叠满了工具执行结果和大段文档上下文很快要撑爆。这时记忆管理就显得极其重要。记忆管理分为两层。短期记忆就是模型上下文里的对话历史核心策略是“取舍”。哪些内容必须保留最近的用户指令、最近一次工具调用的结果、重要的中间推理结论。哪些内容可以压缩大段原始文档、已经执行过的中间步骤。实现上可以手工截断也可以用模型做“记忆摘要”定期把早期对话压缩成几句话放进上下文。长期记忆则依赖外部存储。每当Agent完成一个重要子任务把结论提取成结构化记录存进向量数据库后续对话中根据当前意图检索相关记忆注入上下文。这套机制就像给Agent配了个笔记本它不再每次从零开始推理。经验之谈记忆管理一定要尽早设计不要等到上下文爆了再临时打补丁。我见过很多Agent项目前期没考虑记忆后期被token账单吓到然后花数周重构。现在主流的框架都带了基础的存储组件但你要想清楚哪些记忆是真正需要的而不是把什么都存下来不然检索噪声会把Agent带偏。3.4 规划与执行循环从ReAct模式到自纠错Agent的执行核心就是规划循环。目前最经典的ReAct模式Reason Act可以简单理解成“边思考边行动”。模型每轮输出都包含推理和动作系统执行动作后把观察结果回传模型根据观察结果再推理直到得出最终答案。整个循环的伪代码大致是while not done: response model.call(history current_task) if response.use_tool: result execute_tool(response.tool_name, response.args) history.append(result) else: done True final_answer response.answer这个循环看着简单真正跑起来会暴露很多问题比如重复执行同一个工具、陷入死循环、对失败结果无脑重试等。我的经验是在循环里必须有明确的“最大步数”限制和“失败处理策略”。比如规定工具调用失败后最多重试两次重试仍失败则要求模型换一个工具或直接放弃规定整个任务的总步数上限为10步超出后强制输出部分结果。没有这些护栏你写的Agent在生产环境里就像一个撒手没的实习生不知道会捅出什么篓子。进阶一点的规划模式是Plan-and-Execute先让模型从头到尾生成一个完整计划再逐条执行并根据执行结果调整剩余计划。这种模式在任务步骤较多、工具之间依赖性强的场景下稳定性更好但对模型的远期规划能力要求更高小模型容易写出“看着合理但执行不了”的计划。如果模型能力一般我反而推荐ReAct边做边改容错率更高。4. 实操过程与核心环节实现一个能跑通的Agent全流程记录4.1 手写一个最小Agent从零搭建不靠大框架先不急着上框架我们用一个最小化实现把Agent的执行循环拆开看一遍。这个例子之后你再回去用框架就能清楚地知道每一行代码在后端到底发生了什么。我用Python加OpenAI兼容接口来演示。假设你的大模型API支持Function Calling本地Ollama部署的Qwen等模型在配置好tools参数后同样可以。先定义一个最简单的工具——获取IP所在地import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) # 如果你用的是云厂商API这里换成对应的base_url和api_key tools [ { type: function, function: { name: get_ip_location, description: 查询给定IP地址所在的城市和运营商, parameters: { type: object, properties: { ip: {type: string, description: IP地址} }, required: [ip] } } } ]接下来写Agent执行循环。关键点是每一轮把历史消息、工具定义、用户问题发给模型模型返回如果是工具调用指令就执行工具并把结果以role: tool的消息追加回去然后再调一次模型如此往复def run_agent(user_input): messages [{role: user, content: user_input}] max_steps 5 for step in range(max_steps): response client.chat.completions.create( modelqwen2.5:7b, messagesmessages, toolstools, tool_choiceauto ) msg response.choices[0].message if msg.tool_calls: messages.append(msg) for tool_call in msg.tool_calls: args json.loads(tool_call.function.arguments) if tool_call.function.name get_ip_location: result f{args[ip]} 位于 北京市朝阳区运营商为电信 else: result 未知工具 messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) else: return msg.content return 达到最大步数任务未完成这段代码已经是一个可以工作的最小Agent。我用Ollama部署的Qwen2.5 7B实测用户输“查询一下8.8.8.8在哪”模型会触发工具调用程序返回结果模型再基于结果生成通顺的最终回答。整个过程你不需要装任何大框架核心就是循环里“发消息→收指令→执行工具→回填→再发消息”的来回。4.2 用LangChain正式搭建让Agent具备搜索和计算能力如果工具数量多了手动管理循环会变得繁琐这时用LangChain会很爽。下面演示一个带“搜索工具”和“计算器工具”的Agent搭建过程代码量很精简效果却非常直观。先安装依赖pip install langchain langchain-openai接着定义两个工具。LangChain里工具的标准写法是用tool装饰器框架会自动根据函数名和docstring生成模型要看的JSON Schema所以写工具时docstring一定要写得清楚它直接决定模型能不能正确理解工具的用途from langchain.tools import tool import random tool def search_web(query: str) - str: 搜索互联网信息返回与query相关的网页摘要query为搜索关键词 # 这里演示用随机数代替真实搜索实际替换为Search API results [{title: 示例结果, snippet: f关于{query}的一段摘要}] return str(results) tool def calculate(expression: str) - str: 计算数学表达式结果expression为合法的数学表达式例如 2*34 return str(eval(expression, {__builtins__: {}}, {}))然后组装Agent。LangChain的create_tool_calling_agent会自动处理Function Calling逻辑再配合AgentExecutor管理执行循环。你需要指定三个东西大模型实例、工具列表、系统提示词from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor llm ChatOpenAI( modelqwen2.5:7b, base_urlhttp://localhost:11434/v1, api_keyollama ) tools [search_web, calculate] prompt ChatPromptTemplate.from_messages([ (system, 你是一个搜索助理必须使用工具来回答用户问题。), (human, {input}), (placeholder, {agent_scratchpad}) ]) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, max_iterations5, verboseTrue) result executor.invoke({input: 计算 23*17 的结果然后搜索‘人工智能’的新闻}) print(result[output])跑起来之后你会发现Agent自动按顺序完成两件事先调用calculate计算出391再调用search_web去“搜新闻”。框架帮你处理好了工具结果回填、历史记录拼接、循环终止这些杂事。但也要留意默认的AgentExecutor对错误处理比较粗暴工具失败时可能直接中断或反复重试。生产环境中我会在外面包一层try-except并在Prompt里明确告诉模型“工具调用失败时根据错误信息调整参数重试一次再失败就明确告知用户”。4.3 接入本地模型Ollama部署与RAG扩展如果你的Agent要处理公司内部文档比如“根据产品手册解答售后问题”纯靠模型自身知识肯定不够需要把RAG检索增强生成接进来。这里演示一个结合本地模型的完整链路先用Ollama部署嵌入模型把文档切片向量化再在Agent的工具列表里加上“文档检索工具”。安装依赖并准备向量库pip install chromadb langchain-community用LangChain内置的加载器读入文档做切片后存入Chromafrom langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_community.embeddings import OllamaEmbeddings loader TextLoader(product_manual.txt) docs loader.load() splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap100) chunks splitter.split_documents(docs) embeddings OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) retriever vectorstore.as_retriever(search_kwargs{k: 4})然后把这个检索器封装成一个工具Agent就能在回答问题时按需“翻手册”from langchain.tools import tool tool def search_manual(query: str) - str: 产品手册检索当用户询问产品使用、参数、故障处理时用该工具检索相关段落 docs retriever.invoke(query) return \n\n.join([d.page_content for d in docs])这个流程跑通的体验是用户问“保修期是多久”Agent判断这属于产品手册问题调用检索工具拿到相关段落再基于段落内容回答。整个链路比直接用裸模型多了一个“手”但这只手恰恰是Agent能解决实际业务问题的关键。很多企业内部的Agent应用本质就是这么一套“本地模型私有文档工具调用”的组合并不需要多高深的架构。4.4 调试与观察Agent运行日志该怎么记Agent开发是个“动态递归”的过程模型每一次输出都影响后续走向所以调试体验和普通代码完全不同。我强烈建议在开发初期就搭好“运行日志”机制把每一次模型输出、工具调用、执行结果、耗时、token数全部记录下来。有两种层次的做法最低成本的做法是在代码里加print或logging把关键信息打到控制台。用LangChain时把verboseTrue打开就能看到完整执行链但那种日志只适合开发态不便于回溯。更规范的做法是落盘到文件或数据库里每条记录包含任务ID、当前消息序列、模型原始输出、工具解析结果、工具执行返回、错误信息、耗时。用这种数据做分析你能很轻易定位到“是模型选错工具”还是“工具参数校验没通过”还是“上下文太长导致模型回复质量劣化”。我在线上Agent项目里就是靠这套日志发现了模型在长上下文中对早期工具结果的记忆会衰减后来针对性做了“关键中间结果摘要”才解决掉。顺便说一句Agent开发不能只看“最终结果对不对”而要看“过程稳不稳”。有时候任务成功是瞎猫撞上死耗子过程一团糟换一个输入就崩。所以记录过程日志是你评估Agent可不可靠的第一手证据。5. 常见问题与排查技巧实录Agent跑偏时的“急救手册”5.1 模型就是不按格式输出JSON怎么办这是Agent开发里出现频率最高的坑。模型输出的arguments是非法JSON或者没有包含必需的字段工具执行直接报错。排查思路按顺序来第一检查模型是否足够大。7B以下量化模型的指令跟随能力很差换14B模型往往立竿见影。第二检查工具Schema是否足够简单。字段太多、描述不清、命名有歧义都会干扰模型尽量把每个参数描述写成“一句话讲清楚格式和含义”。第三检查系统提示词里有没有给出“输出示例”。给模型一个正确的JSON示例比写一大段规则有用十倍。第四代码里要做防御性解析不要直接json.loads。用类似“先尝试解析失败后用正则抽取{...}再解析”的兜底逻辑。这个是实打实的经验我在一个Agent项目里让模型返回“是否确认下单”的布尔值结果它返回了“是”“Yes”“true”三种格式最后不是靠Prompt解决的是统一改成枚举字段confirmed: yes | no问题立刻消失。所以能用枚举就绝不让模型自由发挥。5.2 上下文没过多久就超长该怎么办Agent跑几个来回上下文里就堆了十几万token速度变慢、账单爆炸模型甚至开始遗忘前面的指令。常见原因有三个工具执行结果太啰嗦、历史会话全量保留、中间推理过程占空间。对应解法一是“工具结果精简”。模型调用搜索API返回整篇网页你应该只提取摘要甚至让模型生成“对当前任务的要点提炼”再存回上下文。二是“历史消息裁剪”。设定规则只保留最近的N轮对话和所有工具结果更早的对话做摘要压缩成一段话。三是“子任务隔离”。一个大任务拆成多个独立子Agent执行每个子Agent只看到自己的上下文最后汇总结果。这里要特别提醒上下文长度不是模型越长越好。上下文越长模型对早期内容的注意力就越低。如果你发现Agent在做第10个步骤时“忘了”第1个步骤的信息这不是幻觉问题而是上下文管理没做好。5.3 工具调用反复失败或死循环如何设置护栏Agent陷入死循环的表现很典型反复调用同一个工具、参数永远不对、或者自动把“调用失败”当成“再试一次”。我在这块吃过不少亏总结出三条硬规矩第一必须有最大迭代步数。不管是框架参数还是自研代码设置上限通常5-10步是最低保障。第二对失败做模式识别。同一个工具连续失败两次就不要再重试了转而让模型“换一个工具达成目标或者明确告诉用户需要人工介入”。第三工具设计上减少歧义。比如删除“更新”这样容易和“新建”混淆的工具名合并同类操作。模型的判断一旦有了二义性就会在小问题上打转。5.4 模型输出像个机器人怎么让回答更自然这个问题很主观但确实影响用户体验。很多Agent的回答生硬得像在复述工具结果比如“该IP位于北京市朝阳区运营商为中国电信”这种干巴巴的句子。我通常会在系统提示词里加一条“回答用户时用自然口语表达工具返回结果不要让用户感觉在读结构化数据。”同时让最终回复走一次“话术润色”Agent拿到工具结果后不直接结束而是再调一次模型要求它“根据以下事实以自然口语回答用户”。多加一次模型调用成本不高用户体验提升却非常明显。另外Agent在无法完成需求时很容易陷入“道歉式回答”——“对不起我暂时无法处理这个问题”这会让用户很沮丧。我会在提示词里明确一点**不能完成时要说明原因并给用户一个可行的替代方案。**比如“无法直接查询订单因为缺少订单号你可以提供订单号后重试或者联系客服人工处理”。这个细节对生产环境的可用性影响巨大。5.5 常见问题速查表现象可能原因快速排查方向模型拒绝调用工具工具描述不清或模型能力不足检查工具描述是否具体模型是否小于7B工具参数经常出错Schema字段复杂枚举未约束简化参数改用枚举增加示例Agent反复执行同一工具没有失败重试策略模型陷入循环设置失败次数上限提示词里加“换一种方案”上下文很快超长工具结果未压缩历史全保留精简工具结果历史摘要化子任务隔离回答太生硬像报表缺少话术润色环节增加一次润色模型调用或提示词加“自然口语化”工具结果和问题无关检索召回噪声大调低检索topK增加相关性过滤改写检索关键词任务跑到一半“失忆”关键中间结果没有写入记忆设计摘要节点把已完成步骤结论固化进上下文5.6 独家避坑技巧怎么防止Agent“自作主张”Agent开发中最容易被忽略的安全问题是“模型幻觉后的行动”。模型可能在工具参数里填一个不存在的订单号或把事实描述当成可执行指令。实战中我会加三层防护第一层工具参数必须经过白名单校验不在允许范围内的直接拒绝执行第二层涉及敏感操作删数据、发消息、扣费的工具强制要求模型输出“确认指令”再由程序二次确认第三层最终的执行记录全部落库方便事后审计。这三层加上去基本能把Agent从“敢想敢干”调成“靠谱执行者”。最后再分享几点真实体会做了这么久Agent开发最大的感受是这个领域看起来是“AI魔法”实际上是一门“工程学”。把Prompt写清楚、把工具边界定好、把上下文管理好、把日志记录全这些普通工程手段比任何“神奇技巧”都管用。踩过最深的坑是过早用上复杂框架出了问题不知道该看哪一层后来回归到“先把循环逻辑吃透再叠加框架”的路径整个开发节奏就顺畅了。如果你刚开始接触建议从本文第4节的最小Agent代码开始把它跑通然后逐步加上搜索、计算、文档检索这些工具再慢慢尝试多步规划。等到这套链路熟了你回头看那些铺天盖地的教程和框架文档会感觉格外清晰——因为它们本质上都是在同一个“循环”周围做文章。另外想多说一句大模型的版本迭代非常快选型时不要过度纠结“哪个最强”而是盯准“哪个在你的场景下最稳”稳定可用永远比理论性能重要。希望这篇内容能让你建立起对Agent开发的整体框架少走一些弯路。
