做一个Agent开发项目时最容易犯的错是把它当成“更聪明的聊天机器人”来做。我最初也是这样在System Prompt里写了一大堆角色设定把模型输出接上了几个工具结果跑起来才发现真正难的不是让模型“知道”该做什么而是让它在一个多轮循环里稳定地“做到”最后——不跑偏、不重复、不烧光Token。这篇文章不是论文复读而是我从一个普通后端开发者角度在折腾大模型Agent开发这半年里沉淀出来的一套入门路线核心概念怎么理解、核心机制怎么掌握、环境怎么搭、一个能跑的小Agent怎么实现以及那些文档里不会写但实际一定会遇到的坑。1. Agent到底是什么——概念不清楚后面全白搭1.1 从Prompt到大模型应用的三层进化如果一直用Prompt调大模型你会很快撞到一个瓶颈模型输出再漂亮也只能“说话”不能“办事”。让它查个天气、读写文件、调数据库、发请求光靠Prompt根本做不到。于是大模型应用的形态逐渐分出了三层。第一层是Prompt工程。本质是把模型当作知识库和文本生成器聚焦在怎么问、怎么规定输出格式上。第二层是带工具的大模型应用。在Prompt里告诉模型有哪些工具可用让它输出一段结构化指令由程序去执行典型形态就是Function Calling。第三层才是Agent。它不仅会调用工具还要自己决定“下一步做什么”把一个较大目标拆成多个小步骤过程中不断观察执行结果、修正计划、补充信息直到任务完成。这三层不是割裂的。Agent是前两层的自然延伸但比它们多了一个至关重要的组件——“循环”。这也是Agent和普通“工具调用应用”最本质的区别普通应用是一问一答一执行Agent是一问多轮多工具过程中模型会反复参与决策。判断一个项目是不是真需要Agent你就看任务是否必须经历多轮“观察-决策-行动”才能完成如果只是一次查询加一次工具调用没必要上Agent。有一个现象我见过很多次刚接触Agent的开发者把“能调工具”直接等同于“做了个Agent”。严格说那只是Agent的雏形。真正的Agent至少要具备四项能力规划、工具使用、记忆、反思。如果目标只是“让模型能算个数学题”你需要的其实是工具调用如果目标是“帮我调研一个行业并输出一份带依据的报告”这才需要Agent因为任务里包含了拆解、收集、整合、自查这些多轮动作。1.2 Agent的四个核心能力规划、工具、记忆、反思把Agent比作一个新入职的员工这四个能力就非常好懂了。规划Planning约等于“做工作计划”。抛给它一个大目标它能拆成可执行的子任务并排出合理的先后顺序。工具使用Tool Use约等于“会用公司系统”。查资料、发邮件、跑报表都要调用外部系统Agent需要知道在什么场景下用什么工具。记忆Memory约等于“记笔记和翻聊天记录”。短期记忆覆盖当前任务里的关键信息长期记忆负责跨会话保留用户偏好和项目背景。反思Reflection约等于“复盘”。执行完一步看一眼结果是不是符合预期不符合就调整下一步而不是闷头继续跑。这四个能力里规划是最难做好的。原因很现实大模型天生有不确定性它拆出来的步骤不一定合理甚至可能自相矛盾。让模型完全自由地去规划一个复杂任务往往会在简单环节多绕好几圈。我实际开发中更常用的做法是把“规划”从模型自由发挥改成“半固定流程”——在提示词里给出一条路径模板例如“第一步搜索背景第二步整理关键数据第三步对比方案第四步生成报告”模型只需要在模板约束下填充具体内容而不是从零开始设计流程。这样做稳定性提升非常明显尤其适合业务链路清晰的场景。1.3 为什么我建议你从手写循环开始而不是先学框架网上关于Agent的资料多到爆炸Arxiv上几乎每天都有新框架和新论文。但我的建议是入门别从论文和框架开始。论文解决的多是单点技术问题比如某个记忆机制、某个规划算法而入门最大的障碍是把这些模块串成一个能跑的系统这个障碍靠读论文解决不了。我更推荐的路线是先手动实现一个最简单的主循环就是“模型加工具加循环”这个铁三角跑通之后再逐步理解记忆、规划、多Agent这些上层概念。有了最基本的运行直觉之后你再去看框架源码和论文会非常轻松因为你清楚某个机制到底在解决哪个环节的问题。这个观点我在带新同事时反复验证过。有位同事第一次用LangChain就跑通了搜索Agent但他根本说不清为什么结果不稳定、Token为什么消耗那么快。后来我让他把框架拆掉用30行代码手写一遍他很快就通了。所以入门的核心不是“会用哪个框架”而是“理解运行机制”。框架只是工具机制才是内功。2. 核心运行机制不搞懂原理会一直踩坑2.1 ReAct模式让模型边想边做ReActReasoning and Acting是当前Agent实现里最经典的模式也是各种框架默认采用的基础方案。它的核心思路是让模型在决策过程中交替输出两种内容思考Thought和行动Action。思考表明模型对当前情况的分析以及下一步计划行动则指定要调用的工具名称和输入参数。程序解析出模型输出的行动指令执行对应工具再把结果作为观察Observation回传给模型模型继续思考。如此循环直到模型输出最终回答Final Answer。这个设计最巧妙的地方在于它把模型的推理过程显式化了。如果不显式输出思考模型可能直接给出一个缺乏依据的答案你还不知道它为什么这么答。显式化之后开发者和用户都能看到Agent“下一步打算做什么”出了问题也能追根溯源比如能找到它是通过哪一步搜索才得出某个结论的。同时思考过程本身也给模型提供了一种“工作记忆”已经完成的分析和下一步计划都写在上下文里后面继续决策时能参考。实现ReAct时提示词里通常要规定输出格式。我用过一个非常实用的模板核心内容是这样Answer the following questions as best you can. You have access to the following tools: search: 在线搜索工具输入为搜索关键词 calculate: 计算器工具输入为数学表达式 Use the following format: Thought: 你对当前情况的分析 Action: 要调用的工具名称 Action Input: 工具的输入参数 Observation: 工具返回的结果由系统填充 Thought: 继续分析 ... Final Answer: 最终答案实际项目中你可以灵活调整模板但核心循环不要变Thought到Action到Observation反复执行直到出现Final Answer。我在正式工程里曾用不到30行代码封装过这个循环效果很稳定后面第四节会给出可以直接跑的完整例子。2.2 Function Calling比文本解析稳定一百倍上面ReAct例子里的Action是文本格式程序需要解析文本才能决定调用哪个工具。这种方式在早期很常见但有一个很头疼的缺点解析极不稳定。模型输出Action时多了一个空格、换行位置不对、工具名写成了相近的另一个词正则匹配就失败整个Agent流程直接卡住。更稳定的方案是Function Calling。它由API直接返回结构化的工具调用结果不再让模型自己拼文本。工作方式大致是这样开发者在API请求里声明工具列表每个工具包含名称、描述、参数的JSON Schema。模型根据用户问题判断是否需要调用工具。如果需要API返回一个结构化的tool_calls字段里面是工具名和参数对象。程序执行工具把结果作为一条role为tool的消息传回给模型。模型基于工具结果继续推理可能再次调用工具也可能直接输出最终答案。用OpenAI的Python SDK写出来大概是这样的from openai import OpenAI client OpenAI() tools [ { type: function, function: { name: search, description: 搜索互联网获取最新信息, parameters: { type: object, properties: { query: {type: string, description: 搜索关键词} }, required: [query] } } } ] messages [{role: user, content: 帮我查一下最近发布的大模型}] resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolstools ) if resp.choices[0].message.tool_calls: tool_call resp.choices[0].message.tool_calls[0] print(tool_call.function.name) print(tool_call.function.arguments)与ReAct文本解析相比Function Calling的稳定性提升是巨大的。我见过不少团队为了让提示词里零碎的Action格式不出错写了大量正则和容错代码最后全部换成了Function Calling。这里提醒一句Function Calling依然依赖模型对工具描述的理解工具描述写得不清楚它照样会调错工具所以工具描述本身也要认真设计。2.3 短期记忆与长期记忆上下文到底怎么管Agent的记忆问题本质上就是上下文管理问题。模型能接收的上下文长度有限且按Token计费不能让Agent把所有过程细节都堆在上下文里。实际开发中我习惯把记忆分成两层分开管理。短期记忆工作记忆负责当前任务里的对话历史和工具调用记录。最简单的做法是按顺序把所有消息放进去但长时间运行后上下文会越来越长。常用的优化手段有三种窗口截断只保留最近N轮完整消息摘要压缩把早期内容用大模型总结成几条要点关键信息抽取只保留工具结果里的重要数据。这三者可以根据任务特点组合使用。长期记忆则负责跨会话保存用户偏好、项目背景、历史结论。实现方式通常是结构化的向量数据库或者普通数据库新任务开始时根据当前问题做检索把相关片段注入上下文。比如做客户支持Agent把客户历史工单存到向量库里新对话时先做相似度检索把命中内容作为背景信息补充给模型。新手最容易踩的坑是把短期记忆和长期记忆混在一起所有聊天记录全部灌进上下文结果Token飞涨模型反而因为信息太杂而越来越“糊涂”。我的经验是短期记忆优先保证最近对话的完整性和关键工具结果的准确性长期记忆负责按需召回两条路径分开处理不要一股脑拼接。2.4 规划策略从模型自由发挥到工程化约束规划是Agent“看起来聪明”的关键也是稳定性最差的部分。目前常见的实现方式有四种一次性规划Plan-and-Execute模型先把任务拆成完整步骤列表然后按步骤推进。优点是一开始思路清晰缺点是如果第一步拆错后面全错。动态规划ReAct式不提前拆任务每走一步看一步根据观察结果决定下一步。优点是灵活缺点是有可能跑偏、绕远。分层规划一个高层Agent负责拆子任务每个子任务由低层Agent或固定工作流执行。适合复杂业务但调试成本高。模板约束开发者在提示词里预先给出一条任务路径模板限制模型的发挥空间。适合流程相对固定的场景。入门阶段我强烈建议先用模板约束加ReAct式动态执行不要一上来就上多Agent。多Agent的调试成本是指数级上升的而且很多场景单Agent配好工具就足够了。我见过一个企业内部知识库问答Bot非要拆成检索Agent、写作Agent、审核Agent三个角色结果三个Agent之间消息传递频繁出错还不如一个Agent三行工具来得稳定。等到真正发现单Agent无法满足需求时再上多Agent才是理性的路径。3. 开发环境与工具链选型第一行代码前的准备3.1 环境配置与模型接入开始写Agent代码之前先把环境准备好。我的标准配置是Python 3.10以上、一个虚拟环境然后安装OpenAI SDK。如果你用的是其他厂商的大模型或本地部署的开源模型只要它们提供OpenAI兼容的API接口就可以复用同一套代码只需要修改base_url和api_key。python -m venv agent_env source agent_env/bin/activate pip install openai python-dotenvKey的管理一定要用环境变量或.env文件不要写死在代码里。Agent项目大概率要提交到Git仓库Key写进代码再传上去的教训我见过太多次。用python-dotenv读.env文件是很标准的做法from dotenv import load_dotenv import os load_dotenv() api_key os.getenv(OPENAI_API_KEY) base_url os.getenv(OPENAI_BASE_URL)接入大模型时有几个参数值得注意。temperature建议设低一点我习惯设在0.2到0.5之间Agent场景要减少随机性否则同样的任务两次结果差异会很大。max_tokens要设足够大避免模型思考到一半被截断。stream参数则看场景做交互式界面时开启流式输出做后台任务时建议关闭省去处理流式帧的复杂度。3.2 框架到底用不用LangChain们的真实定位“用不用LangChain”是我被问到最多的问题。回答是先别用框架手写一遍核心循环之后再决定。不理解运行机制直接上框架出了问题你根本不知道是框架的锅还是模型的锅。当你能手写ReAct循环、理解Function Calling之后再去看框架会快得多。目前主流的Agent框架各有侧重我列一个简单对比框架特点适合场景LangChain / LangGraph生态最全、组件多、抽象多快速集成大量工具和记忆组件LlamaIndex擅长RAG和文档问答知识库类AgentAutoGen多Agent对话调度研究探索、多角色协作OpenAI Assistants API官方托管内置检索、代码解释器快速原型、应用内Agent自研小框架完全可控代码量通常在千行以内生产级业务Agent我个人的选择是原型阶段用官方SDK手写生产阶段大概率是自研小框架加少量现成工具封装。原因在于生产级Agent对稳定性、可观测性和成本控制要求很高直接用大框架会把很多隐式行为带进来出了问题难排查。框架适合快速试错验证不适合直接上生产这句话不是夸大而是很多团队共同的教训。3.3 最小可运行示例40行代码理解Agent循环在引入任何框架之前我建议你先亲手实现下面这个最小Agent循环。它只包含三样东西模型、一个计算工具、ReAct模式。这段代码大约40行能把Agent的核心机制完整呈现出来。这里为了展示原理我故意用文本解析Action而不是Function Calling因为ReAct的思考过程更容易直观看到。真实项目中建议用Function Calling后面案例部分会演示。示例代码如下import re from openai import OpenAI client OpenAI() def calculate(expr): # 只允许数字和运算符号避免执行任意代码 expr re.sub(r[^0-9\-*/(). ], , expr) return str(eval(expr)) tools_desc calculate: 计算数学表达式输入示例: (35)*2 SYSTEM_PROMPT f你是一个AI助手可以用工具回答问题。 工具列表 {tools_desc} 请严格按以下格式输出 Thought: 你的思考 Action: 工具名称 Action Input: 工具输入 Observation: 工具结果系统填充 ... Final Answer: 最终答案 def run_agent(user_input, max_steps10): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ] for _ in range(max_steps): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, temperature0.3 ) content resp.choices[0].message.content print(模型输出:, content) if Final Answer in content: return content.split(Final Answer:)[-1].strip() action_match re.search(rAction: (\w), content) input_match re.search(rAction Input: (.), content) if action_match and input_match: action action_match.group(1) action_input input_match.group(1) if action calculate: observation calculate(action_input) else: observation 未知工具 messages.append({role: assistant, content: content}) messages.append({role: user, content: fObservation: {observation}}) else: messages.append({role: assistant, content: content}) messages.append({role: user, content: 请严格按格式输出包含 Action 和 Action Input。}) return 达到最大步骤数任务结束 print(run_agent(计算 (35)*2 的结果))这段代码虽然简单但Agent的核心骨架全在里面了系统提示词规定了工具和输出格式主循环让模型可以反复调用工具Observation把工具结果回传给模型。你把它跑通之后再回头去理解LangChain的AgentExecutor会觉得豁然开朗因为底层循环机制几乎一模一样。4. 实操案例构建一个“自动搜索摘要”Agent4.1 需求与边界项目从哪里开始理论讲完了我们做一个真实可用的Agent。需求是用户输入一个问题Agent先搜索相关资料再结合搜索结果生成一份带出处的摘要。这个场景非常典型技能充分体现Agent的价值又不会太复杂。功能边界我建议这样划单Agent、两个工具、最多6轮搜索、最终输出摘要。为什么选这个场景当入门案例因为“搜索加摘要”几乎覆盖了Agent开发的所有核心要素工具注册与实现、结构化输出解析、上下文管理、停止条件控制、失败重试。你把这个案例做完按照同样的思路去改造成客服问答、内容生成、数据分析等业务Agent路径是通的。我甚至会把这个案例当作一块“标准实验田”日常验证新模型、新提示词思路时都会拿它先跑一遍。4.2 工具定义与提示词设计这个Agent需要两个工具search用于搜索互联网summarize用于对长文本生成摘要。为了让代码可以直接运行search工具我先用一个可替换的接口你可以接自己的搜索API也可以先用mock函数模拟返回结果。关键在于工具描述要写清楚模型通过描述来判断何时调用它。工具描述的原则是名称要准确、描述要说明什么时候用、参数要说明传什么。比如search的描述可以写成“搜索互联网获取最新信息当用户问题涉及时事、新闻、不了解的事实性信息时使用”模型就能比较准确地判断是否该调用。我踩过的坑是工具描述写得太宽泛比如只写“搜索工具”模型会把什么都当成搜索需求导致大量无效调用。提示词方面除了工具描述还要明确“什么时候停止”。模型很容易在已经有答案的情况下继续搜索白白消耗Token。我在系统提示词里专门加了一句“当搜索结果已经足够回答用户问题时直接基于已有信息生成最终答案不要继续搜索。”这一个小改动能把平均步骤数从5降到3成本控制效果非常明显。核心代码长这样tools [ { type: function, function: { name: search, description: 搜索互联网获取最新信息当用户问题涉及时事、新闻、不了解的事实性信息时使用, parameters: { type: object, properties: { query: {type: string, description: 搜索关键词} }, required: [query] } } } ]4.3 主循环实现代码逐行解析定义好工具后主循环实现如下。这里我选择Function Calling而不是文本解析因为稳定性更好也更贴近真实项目import json from openai import OpenAI client OpenAI() def search_web(query): # 实际使用时替换为真实搜索API # 这里用mock数据模拟搜索结果 mock_results { 大模型 Agent: Agent是大模型驱动的自主智能体通过调用工具完成复杂任务..., AI Agent: AI Agent是能够感知环境、决策并执行动作的智能系统... } return mock_results.get(query, f关于{query}的搜索结果暂未找到详细内容可以尝试更精确的关键词。) def call_model(messages): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolstools, temperature0.3 ) return resp.choices[0].message def run_search_agent(user_question, max_steps6): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_question} ] for step in range(max_steps): message call_model(messages) if message.tool_calls: messages.append({ role: assistant, content: message.content, tool_calls: message.tool_calls }) for tool_call in message.tool_calls: if tool_call.function.name search: args json.loads(tool_call.function.arguments) observation search_web(args.get(query, )) messages.append({ role: tool, tool_call_id: tool_call.id, content: observation }) else: return message.content return 达到最大步骤数本次回答可能不完整。 print(run_search_agent(请帮我调研一下大模型Agent开发的主流框架))这段代码有一个关键细节把assistant的回复消息重新追加回去时必须带上tool_calls字段否则API会报错。这是Function Calling模式下最容易出错的地方之一很多初学者在这里被卡了很久。4.4 运行效果与我的调试心得实际跑这个Agent时我第一次运行就撞上了一个经典问题模型连续搜索了三次同一个关键词完全没有收敛。原因在于mock的搜索结果太笼统模型觉得“信息不够”于是反复搜同一个词。后来我把返回结果写得详细一些同时在系统提示词里增加了“如果搜索结果已经包含足够信息请直接停止搜索并整理答案”的约束情况立刻好转。调Agent的过程本质上就是在调“提示词加工具返回质量”这对组合。模型本身没变变的是它能看到的信息质量。所以遇到Agent效果不好先别急着怀疑模型能力应该先看看工具返回了什么、提示词有没有足够的约束这两项通常才是问题的根源。另外提醒一点Agent的输出一定要先在小范围测试再逐步放开。我用十几条覆盖正常、边界、异常场景的query组成最小测试集每次改动都跑一遍记录Token消耗、步骤数、结果质量。有了这个基线你才能判断一次修改到底是变好了还是变差了否则就是在黑箱里瞎调。5. Token失控、死循环、工具报错怎么排查5.1 Token消耗失控烧钱快怎么控制Token在Agent场景下消耗确实吓人。原因是每一次工具调用之后助理回复、工具结果都要重新传给模型上下文越积越长单次调用的成本也在不断上升。我见过一个简单的调研Agent跑一轮消耗五万Token其中大部分是历史对话的反复重传。控制Token的办法核心就是三个字控上下文。具体手段我总结了几条限制最大迭代轮数例如6步到了就强制终止。工具结果不全量回传先让模型抽取关键信息。比如搜索返回10条结果先提炼出相关的2条。历史消息用窗口截断把中间过程压缩成要点只保留最近N轮完整消息。能用一个工具完成的事绝不拆成两个工具。工具越多模型规划失误的概率越大Token消耗也越大。还有一点容易被忽略系统提示词和工具描述本身也是Token。工具描述写得过长每轮都要浪费。我一般要求工具描述控制在三句话以内能讲清楚用途和参数就行不写一堆场景化废话。5.2 模型陷入死循环怎么办模型在Agent里陷入死循环非常常见。表现是不断调用同一个工具、输出相同或差不多的Action始终没有Final Answer。出现这个现象的原因主要有三个工具结果里没有模型真正需要的信息模型自身规划能力不足绕不出来停止条件没设置到位。排查思路要清晰先打印每一轮的Thought如果模型反复说“我需要更多信息”但搜索关键词一直没变说明它没有从结果里获取到增量信息这时候应该改进工具结果质量而不是盲目加提示词。如果模型Thought一直在推进但行动在绕圈说明任务拆解有问题可以试着在系统提示词里给一条更明确的路径。如果这些都不见效直接加兜底策略最多允许调用N次工具超限后基于已有信息给出答案。兜底策略是生产级Agent必须有的。任何依赖大模型自由决策的系统都要默认“模型可能不会结束”然后在代码层面强制结束。没有这个护栏一个死循环Agent能把你的API账单刷爆。5.3 工具调用失败格式与参数问题工具调用出错是Agent开发中最常见的挫败感来源。最常见的几类错误是模型输出的Action在文本解析时匹配不上。如果还在用正则解析Action建议尽快迁移到Function Calling。模型传参缺字段。比如工具要求query参数模型输出了q或keyword。解决方法是把JSON Schema里的描述写得更清晰并加上示例。工具内部执行报错。这里要重点强调工具内一定要做异常捕获不能把Python异常直接抛给模型。模型看不懂Traceback正确做法是捕获所有异常返回一句“工具执行失败原因是XXX请换一种方式尝试”。我在封装工具时有个习惯任何外部依赖包括HTTP请求、文件读写、数据库查询全部套上try...except并把异常信息转化成对模型友好的短文本返回。这个细节能让Agent的容错能力提升一大截因为它给了模型“换个方法再来一次”的机会。5.4 并发与稳定性从Demo到服务的距离Agent要上线服务首先要解决并发问题。Agent和普通API转发不一样每个任务里包含多次模型调用和多次工具调用整体耗时通常在十秒到分钟级别如果再做流式输出连接占用时间更长。直接同步阻塞会占用大量连接资源所以生产环境要做几件事异步化。用asyncio把IO等待让出来模型调用和工具调用都做成异步。队列限流。对模型API做速率保护和过载保护避免触发429限流。超时控制。整个Agent任务要设置总超时时间不能无限等下去。可观测性。每个任务都要记录运行日志、Token统计、每步耗时出问题才能定位。对入门阶段来说前两点比较紧迫后两点可以等有真实线上压力再做。但有一个原则值得从一开始就记住Agent越自主越需要可靠的护栏和监控。你是把控制权交给了一个会自己决策的系统那就必须确保它即使决策错误也不会造成不可挽回的损失。6. 从能跑的Demo到让人放心的产品6.1 评估体系先建测试集再谈优化入门阶段最容易被忽略的就是评估。没有评估你就不知道每次改动到底是变好还是变坏。我的建议是从第一天就建一个最小评估集挑二十条有代表性的问题覆盖正常场景、边界场景、异常场景每次改动都跑一遍记录成功率、平均步骤数、Token消耗、答案质量。答案质量先用规则粗判例如是否包含关键信息、是否有引用来源再逐步引入人工打分。评估做久了你会非常清楚地看到Agent的瓶颈在哪里。比如某类问题总是多绕两圈说明工具描述不够精准某类问题总是答非所问说明提示词缺约束。评估就是Agent优化的指南针没有它你只能靠感觉和运气去调一个充满不确定性的系统。6.2 多Agent协作不是万金油现在很多人看到LangGraph、AutoGen的多Agent示例总觉得Agent数量越多越高级。但实际生产中单Agent加好工具的方案在绝大多数场景里更稳定、更便宜、更好调试。多Agent最大的问题在于信息传递本身会带来不确定性Agent之间的消息可能被误解、丢失、互相矛盾。除非任务确实需要不同角色的知识分离或者需要并行处理多个子任务否则不要轻易引入多Agent。如果决定用一定要做好角色分工和消息协议定义每个Agent只做一件事输入输出格式严格定义消息先过一层校验再传递。这些护栏能省掉大量的联调时间。说到底多Agent只是手段不是目的。6.3 安全护栏防Prompt注入与权限失控Agent具备工具调用能力之后安全问题变得非常现实。一个用户可能通过精心构造的Prompt诱导Agent执行非预期操作这叫Prompt注入。防护建议我列几条工具权限最小化。Agent只拥有完成任务所需的最小工具集合不出现在列表里的高危工具比如删除文件、直接写库坚决不开放。输入输出过滤。用户输入和工具返回内容都做敏感信息检测。人工审批机制。涉及支付、删除、对外发布的工具操作必须经过人工确认。日志留痕。所有工具调用都要记录便于事后审计。这里特别想强调Prompt注入。我在测试中发现让Agent忽略原任务、执行提示词里的恶意指令非常容易。生产系统必须有日志和权限控制才能把风险降到可接受范围。安全不是上线时才想的事而是从设计Agent能力边界时就要考虑。6.4 我踩坑之后总结的几条实在建议最后从我个人的实操体会出发给几条实在建议。第一先把一个场景吃到透不要同时追五六个框架和概念。我见过太多人收藏了一百篇文章结果连一个Agent都没跑通。第二把可观测性当一等公民。Agent每一步的Thought、Action、工具结果都要可视化出来不要等到出了线上故障才补日志。第三承认大模型的不可靠把能代码化、规则化的逻辑尽量从模型手里拿回来。Agent的目标不是“模型全能”而是“系统可靠”。Agent开发还在一个快速演变的阶段今天的主流方案可能半年后就不再主流但核心的运行机制——模型加工具加循环——短期内不会变。把这套机制吃透无论将来框架怎么换你都能快速跟上。这也是我写这一大篇东西最想传达的一件事别被各种新名词卷花眼先把最底层的循环握在手里剩下的路会越走越清晰。