直接聊点实际的。大模型Agent开发最近这个词被刷屏的频率比我外卖软件里的红包弹窗还高。但如果你真去翻各种资料会发现要么是讲概念讲到天上要么是给一段demo代码让你自己悟。作为一个从去年就开始折腾Agent并且真把它用到业务系统里扛过线上流量的开发者我觉得是时候把那些文档里不写、视频里不讲的实操经验拿出来透个底了。先说清楚这篇东西是什么。它不是一篇AI时代必学的鸡汤文也不是CtrlC、CtrlV的代码仓库搬运。它是我基于大模型Agent开发入门这个主题结合自己从零搭建、优化、排障到上线全过程的经验总结。你会看到Agent到底是什么、和普通调API有什么区别、第一行代码该怎么写、工具调用怎么设计、上下文爆炸怎么处理、线上并发怎么扛以及那些我踩过之后至今想起来还肉疼的坑。适合谁看如果你已经会写Python或者Java用过OpenAI、Claude、通义、文心这类大模型的API但面对Agent这个概念总觉得隔着一层窗户纸想自己动手搞一个能干活、不是玩具的东西那这篇内容就是冲着你来的。如果你是纯小白连Token是什么都还懵也没关系下面凡是涉及基础概念的地方我都会用大白话和类比拆开揉碎讲清楚。1. Agent的本质为什么它不只是一个增强版聊天机器人1.1 从一问一答到目标驱动的思维转变很多人对Agent的第一印象是能记住上下文的对话机器人。这个理解不能说错但严重低估了Agent的核心价值。如果只是多轮对话那现有的ChatGPT网页版早就做到了压根不需要专门搞一套Agent框架。我习惯用一个类比来解释Agent和普通大模型应用的区别普通大模型应用像是一个问答百科你问它什么它根据训练数据和上下文给你一个答案说完就完了。而Agent更像你雇的一个实习生助理你给它一个任务目标它能自己琢磨需要做哪几步、每一步需要调用什么工具、中间遇到问题怎么调整方案最后把结果交付给你。这个差别的本质在于目标驱动和单次推理的区别。普通应用是输入Prompt输出CompletionAgent则是输入目标输出行动序列。这个过程往往需要大模型进行多轮推理每一轮都要结合当前状态、历史信息、工具返回结果决定下一步动作直到任务完成或者它判定无法完成。在业内这个机制通常被叫做推理-行动循环Reasoning-Action Loop。最早的经典范式叫ReAct就是让模型交替进行思考Reasoning和行动Acting。思考的时候模型用自然语言描述自己的推理过程行动的时候模型生成调用某个工具的指令系统执行完工具后把结果反馈给它它再接着思考。这就不是一次API调用能完成的而是一个循环往复的多次调用过程。1.2 Agent的四大核心组件拆解既然Agent是一个目标驱动的循环系统要运转起来至少需要四个核心组件。理解了这四个组件你再看任何Agent框架都会觉得不过如此。第一个组件是感知层也叫输入处理模块。用户的原始需求是模糊的、口语化的、甚至隐含大量默认前提的。感知层要做的事情是把这些非结构化输入转换成模型更容易理解和处理的结构化指令。比如用户说帮我查下昨天订单量怎么突然跌了感知层需要把这个意图拆解成查询订单数据和分析异常原因两个子任务。第二个组件是规划层这是Agent的大脑。它负责拆解任务、制定步骤、决定先做什么后做什么。现在主流实现方式是依赖大模型本身的推理能力让它通过思维链Chain of Thought或ReAct模式生成行动规划。稍复杂的系统会引入规划器Planner专门做这一步甚至用更小的模型做规划用更大的模型做执行以控制成本。第三个组件是记忆层这是Agent区别于普通应用的关键分水岭。记忆分短期记忆和长期记忆。短期记忆就是我们说的对话历史放在上下文窗口里长期记忆则通常存在外部存储比如向量数据库或关系型数据库需要时检索出来注入上下文。可以按工作记忆和长期记忆来理解就像人一样手头正处理的事记在脑子里过往的经验翻笔记本找。第四个组件是行动层也叫工具调用层。模型再聪明只靠文本输出也没法操作真实世界。它需要通过调用外部工具来获取数据或执行操作比如查数据库、调API、发HTTP请求、执行一段代码。这一层解决的是模型如何把意图变成动作的问题。没有这四个组件你写的东西再花哨也只是套了壳的对话机器人。有了它们才叫Agent。我在实际项目里见过太多团队拿个OpenAI的API接上Prompt就觉得做了Agent结果连个简单的天气查询都要靠模型瞎编这就是典型的分层没做透。1.3 模型选择是Agent的底层地基坦白讲Agent效果的上限一半以上由底层的模型能力决定。ReAct循环里最核心的推理质量、指令跟随能力、工具调用准确率都直接取决于模型本身。现在市面上能用来做Agent的模型可以分两类。一类是闭源商用模型比如OpenAI的GPT系列、Claude系列、国产的通义千问、文心一言、智谱GLM等特点是省心效果有保障按Token计费适合快速验证和中小规模应用。另一类是开源可私有化部署的模型比如Qwen系列、Llama系列、DeepSeek系列适合对数据安全敏感的企业场景比如企业内部的知识库Agent不可能把业务数据全丢给外部API那就必须在私有云或本地GPU服务器上部署。选模型有两条我个人的经验准则。第一条能用商用API跑通验证的不要一上来就折腾私有化部署成本完全不在一个量级。第二条关注模型的工具调用专项能力而不是只看跑分。有些模型写文章、写代码很强但让它按特定JSON格式输出工具调用参数时经常丢三落四。做Agent这块能力比文笔重要得多。我这边的建议是入门阶段用哪个模型不要过于纠结先用手头最顺手的API把流程跑通核心是理解Agent的运行机制。等真正要上线的时候再根据场景做系统性的模型评测选型那时候你会发现评测Agent的模型能力和评测普通对话模型的关注点完全不一样。2. 从零搭建第一个Agent模型、框架与亲手写一个最小实现2.1 框架选型LangChain、LlamaIndex还是自己撸确定要搞Agent之后第一个跳进脑子的问题肯定是要不要用框架用哪个。市面上最响的三个名字就是LangChain、LlamaIndex还有国产的Dify/Coze这类低代码平台。先说LangChain这是目前生态最全、知名度最高的Agent开发框架。它把Agent开发常用的组件——模型调用、提示词模板、工具注册、记忆管理、输出解析——全部抽象成了标准化接口。优点是灵活、生态大、社区资料多遇到问题基本都能搜到答案缺点是抽象层级太多出了Bug排查起来会让人怀疑人生版本更新还经常破坏性变更你今天照着老教程写的代码过两月可能就全废了。LlamaIndex侧重的则是对数据的索引和检索它在RAG检索增强生成这一块的体验做得比LangChain舒服如果你做的Agent核心是基于企业文档问答选LlamaIndex会更顺手。但它做复杂多步骤工具调用Agent的能力相对弱一点。还有一类低代码平台比如Dify和Coze。它们把Agent的搭建变成了可视化拖拽配置不需要写代码适合产品经理、运营人员快速做原型验证。但对我这种做系统集成的开发者来说低代码平台的自由度始终是个瓶颈一旦涉及复杂的业务逻辑、私有化部署、深度定制最后还是得回到代码里去。我的观点比较直白如果你想把Agent当核心技术积累直接选LangChain或者干脆自己写一个轻量的Agent循环不要迷信框架。框架解决的是懒得重复造轮子的问题但它不是银弹。入门阶段用LangChain快速跑通场景是OK的但你要清楚每一层封装下面发生了什么。我自己后面做生产级系统核心的Agent循环是手写的只在局部用LangChain的工具类。为了方便理解后面的内容我们先以LangChain生态的风格来讲。另外我也会在下一节附一个完全不依赖框架的最小实现保证你在框架到底帮我做了什么事这件事上有体感。2.2 亲手写一个最小Agent循环不依赖框架我不想把这篇文章搞成LangChain的教程因为那玩意儿迭代太快写完了可能就过时了。相反的我带你直接用原生代码写一个最小但五脏俱全的Agent循环。这段代码做完你再看任何框架的源代码都能一眼看穿它在干嘛。先确定环境Python 3.10安装好openai这个SDK包其他兼容OpenAI协议的SDK也可以比如通义、DeepSeek的接口都兼容这个协议。下面这段代码实现的是一个能调用加法计算器和当前时间查询两个工具的Agentimport json import datetime from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://your-endpoint.com/v1 # 换成你的模型服务地址 ) # 定义工具这是模型的操作手册 tools [ { type: function, function: { name: calculator_add, description: 计算两个数字的和, parameters: { type: object, properties: { a: {type: number, description: 第一个加数}, b: {type: number, description: 第二个加数} }, required: [a, b] } } }, { type: function, function: { name: get_current_time, description: 获取当前时间, parameters: {type: object, properties: {}} } } ] # 工具的实际执行函数 def execute_tool(name: str, arguments: dict): if name calculator_add: return str(arguments[a] arguments[b]) if name get_current_time: return datetime.datetime.now().isoformat() return f未找到工具: {name} def agent_run(user_input: str, max_steps: int 5): messages [{role: user, content: user_input}] for step in range(max_steps): print(f--- 第 {step 1} 轮推理 ---) response client.chat.completions.create( modelyour-model-name, messagesmessages, toolstools, tool_choiceauto ) message response.choices[0].message messages.append(message) # 如果模型没有返回工具调用指令说明任务结束 if not message.tool_calls: print(Agent 最终回答:, message.content) return message.content # 遍历工具调用逐个执行并把结果追加进对话历史 for tool_call in message.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) print(f调用工具: {fn_name}({fn_args})) result execute_tool(fn_name, fn_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) print( 达到最大迭代步数强制结束) return None if __name__ __main__: agent_run(现在是几点顺便帮我算一下 23 和 19 的和是多少)这段代码看起来很短但它完整实现了Agent循环的全部要素工具定义、模型推理、工具路由、结果回填、多步循环。你跑一下会发现模型收到问题后会先调用get_current_time工具拿到结果后再调用calculator_add工具最后把两个结果综合起来组织成一段自然语言回答。关键在最后还是能串起来。这里面有两点值得展开说说。第一工具描述就是模型的使用手册。你给模型的function定义里name和description的措辞质量直接影响模型能不能正确选用和调用工具。描述越清晰模型越不会乱选。参数里的required字段决定了哪些参数必填模型会严格按这个规则来生成调用参数。第二工具调用结果是用role: tool消息回填到对话历史里的。这一步很多人第一次接触时会漏掉。模型每调用一次工具执行结果都必须作为一条消息追加回messages列表并且要通过tool_call_id和之前模型生成的工具调用关联起来。不把这个回填逻辑写对模型根本看不到工具的执行结果然后就会开始胡编乱造。2.3 用LangChain框架快速验证一万个Agent的Hello World原生代码能帮你理解原理但实际开发中特别是后面要接记忆、接向量库、接多工具协同的时候用框架确实能省不少事。下面用LangChain的最新风格LCEL表达式写一个最简单的Agent。from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.tools import tool from langchain_core.prompts import ChatPromptTemplate llm ChatOpenAI(modelyour-model-name, api_keyyour-key) tool def add(a: float, b: float) - float: 返回两个数字的和。 return a b tool def get_time() - str: 返回当前系统时间的ISO格式字符串。 import datetime return datetime.datetime.now().isoformat() tools [add, get_time] prompt ChatPromptTemplate.from_messages([ (system, 你是一个能调用工具解决用户问题的助手。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) result executor.invoke({input: 现在几点了另外帮我算一下 12345 乘以 6789}) print(result[output])注意到没用LangChain之后你不需要手动处理工具调用循环和消息回填。create_tool_calling_agent和AgentExecutor把这些逻辑给你封装掉了。你只管定义工具函数和提示词剩下的事情框架帮你跑。但我要泼一盆冷水爽归爽别真的只停留在爽上。等你需要精细控制每一步行为——比如某些步骤要用温度更低的参数、某些工具调用后要暂停等待人工确认、某些历史消息需要单独压缩——你抓瞎的速度会非常快。所以我的建议是先用这套快速验证效果然后回去把2.2那段的原生循环吃透。两相对照LangChain在你眼里就没什么魔法了它只是在固定的模式上做了自动化封装而已。3. 工具调用与记忆Agent不掉链子的两条腿3.1 Function Calling的工程化设计Agent的价值八成都体现在工具调用上。工具定义得好不好直接决定了Agent是真干活还是花架子。我自己在实践中踩出来的经验是工具设计要遵循三个原则。第一单一职责。一个工具只做一件具体的事不要搞万能函数。工具越通用参数越多模型就越容易把参数填错。宁可多定义几个细粒度工具也不要定义一个大而全的工具。第二命名和描述用词要精准。模型是靠工具的描述文字来判断什么时候该调用你的工具的描述写得含糊比如处理数据这种模型根本不知道该不该调。写清楚你的工具是干嘛的、输入是什么、输出是什么、在什么场景下使用。第三参数要严格校验。模型生成参数虽然是结构化的但一样会出现类型错误、缺参数、越界的情况。工具入口做一层健壮性校验不是多余是保命。除了设计层面还要聊聊工具调用的安全边界。前两天还有人问我说Agent能直接操作生产数据库吗。我的回答是能但你最好别这么干。更安全的做法是让Agent只调用你预先封装好的、只读或带严格权限控制的内部API而不是让它直接拿着数据库连接串去执行SQL。生产环境里我会把Agent能触达的所有工具做一次权限盘点涉及资金、删除、变更类的操作一律走人工审批流不让模型一步到位。3.2 上下文窗口再大也得面对记忆问题做Agent的人迟早要撞上一堵墙上下文窗口不够用或者说对话历史越来越长模型的效果越来越差费用越来越高。原因不难理解。模型每一次请求都要把整段对话历史包括系统提示、工具定义、历史消息、工具执行结果重新发送一遍。Token越堆越长响应越来越慢费用成倍上涨而且模型会逐渐迷失在海量历史里记不清早期的重要信息。这就像一个人看一部剧前面二十集的细节全挤在脑子里看到第三十集的时候前二十集的情节已经开始模糊后面根本演不动。应对策略业界已经沉淀了几种。第一种叫滑动窗口截断Sliding Window。最简单粗暴只保留最近N轮对话更早的扔掉。问题是一旦遇到用户昨天让我记录了一个偏好今天要按那个偏好执行这种场景早扔就废了。所以只能用在任务之间无关联的简单场景。第二种叫摘要压缩Summary Memory。用一个轻量模型对旧对话进行摘要把详细内容变成要点存档。比如一个几十轮的长对话最终压缩成用户是上海人偏好极简风格设计预算在3万以内这次任务是做店铺装修方案。这样上下文占用大幅降低还能保住关键信息。代价是丢失细节如果后续需要精确追溯某句话摘要里还原不出来。第三种叫向量检索记忆Vector Retrieval。把历史对话切块后embedding存入向量数据库。每次需要记忆时根据当前问题做相似度检索把最相关的几段历史对话捞出来拼进上下文。这个方案适合知识密集、需要精确引用的场景代价是要引入一个向量数据库架构复杂度变高。我实际项目里的做法是组合拳短期对话用滑动窗口保证响应速度同时把重要信息实时抽取存入结构化记忆库比如用户的偏好表长期知识走向量检索。不要试图用一种方案解决所有记忆问题Agent的记忆系统本来就是分层设计的。3.3 记忆与Token开销的最优平衡聊到记忆就绕不开一个让很多新手翻车的点工具定义也要吃Token。你没看错你给模型定义的每一个工具转换成JSON Schema后都是实打实的Token每个请求都会带着。工具数量一多光工具定义就可能吃掉几千Token。这意味着你做工具优化的时候不能只盯着调用的次数要连定义体积一起算进去。我见过有人一口气往Agent里塞了四五十个工具功能倒是全了但每次请求光工具描述就要上万Token模型漏选工具的概率反而直线上升。正确做法是按场景分组。每次运行Agent时根据用户的初步意图先筛选出最相关的一组工具再发给模型。比如用户问天气你就把天气和位置相关的五六个工具挂上去那些内部报表工具根本不进上下文。Token的性价比问题也要算清楚。一个中型Agent每次请求带4000Token上下文用户每天调用2000次一个月光上下文重复发送的费用就是不小的一笔数字。所以凡是能离线做、批量做、缓存做的都不要让Agent在线一步到位。做一个任务编排层把复杂的长期任务拆成可以异步执行的子任务Agent只负责编排和审核结果而不是傻乎乎地在一个循环里把所有事干完。4. 实战踩坑实录并发、幻觉与调试三板斧4.1 AI Agent怎么扛并发一个被问烂了但必须答透的问题AI Agent能扛并发吗——这个问题我几乎每次分享都会被人问。答案是能扛但你要先搞清楚瓶颈到底在哪不然加多少台机器都是白搭。Agent系统的瓶颈不在模型API本身而在三个更容易被忽略的地方上下文的状态管理、工具调用链路的稳定性、以及外部依赖接口的速率限制。先引发一个很多人忽略的问题Agent是有状态的。普通接口服务是无状态的来了请求处理完就返回扩容容易。但Agent在一个任务循环里要维护对话历史、工具调用状态、中间产物。如果你用的是最简单的全局内存变量存对话状态的方案那这个服务实例一旦扩容到多台用户的请求被负载均衡分发到不同的机器上Agent就失忆了。所以生产级Agent状态必须外置比如存Redis或数据库每台服务实例都从同一个地方读写状态。这是扛并发的第一前提。第二个瓶颈点是工具调用链路。Agent执行一个任务往往要串行调用好几个工具每个工具又有自己的响应时间。如果一个任务平均要调用6次工具每次平均1秒整个流程就是6秒起步。单用户还好并发50个用户同时跑后端就有一堆线程/协程在挂着等外部响应连接池、数据库连接、HTTP客户端都容易被打爆。解决办法有两条路一是给每个工具调用做异步化和超时熔断二是做任务排队动态并发控制别让Agent任务一股脑涌入。第三个是模型API的速率限制Rate Limit。你用的商用模型服务都有每分钟请求数RPM和每分钟Token数TPM的限制。并发一上来最先报错的就是这个。应对方案就是做请求转发层的智能限流和重试把并发请求平滑排队同时注意尽量减少不必要的多轮工具调用省着点Token用。4.2 模型幻觉与睁眼说瞎话的治理Agent一大翻车现场就是幻觉。模型不知道答案、或者工具返回了结果但它没看懂它就会一本正经地编一个看起来合理的答案。这在聊天场景里可能只是尴尬在业务决策场景里就是事故。治理幻觉我有几个亲测有效的办法。第一在提示词里强制约束不知道就说不知道。话虽简单但真的很多人系统提示词里根本不写这条。你要明确告诉模型工具返回的结果是你唯一的信息来源如果没有工具结果支撑的判断必须明确回答我无法从现有数据中确认禁止猜测。第二用结构化输出做兜底。现在主流模型都支持JSON Schema模式的输出你让模型必须按答案你的信息来源可信度三段式结构输出。如果模型找不到信息源可信度标注就会很低系统这层可以做自动拦截不把低可信度的结果直接展示给用户。第三严格区分模型推测和工具事实。在给模型的Prompt里要把模型内部知识和工具返回结果分成两个明确的上下文块。例如只有当用户问的是苹果是什么这类常识问题时模型才可以用内部知识回答一旦涉及我的订单状态我的余额这类事实性问题模型必须依赖工具返回的实时数据内部知识在这里是无效的。用这种显式隔离幻觉率能大幅下降。第四关键场景引入结果校验回调。有些工具执行完之后可以反过来调用一个轻量模型拿原始问题和工具执行结果做一致性校验工具返回的数据能不能支撑模型最后的回答校验不过就重跑或转人工。4.3 Agent调试把黑盒拆成白盒最后一条少有人讲但价值极高Agent怎么调试。普通程序你可以在IDE里打断点但Agent是循环调用大模型每次生成的推理文本都不一样如果不在工程层面做可观测性出了问题你连从哪里查起都不知道。我的调试三板斧强烈建议从第一天就实践起来。第一日志必须记录每一步的完整轨迹。不只是记录模型最终说了什么而是记录每一次循环里的完整信息当前Messages的Token数、模型这一步的思考内容、它选择了哪个工具、传了什么参数、工具返回了什么、回填之后模型下一步怎么想。把这些完整的trace记录成结构化日志最好是JSON格式方便检索和回放。第二做一个回放工具。把Agent运行的每一轮轨迹都存下来出问题后可以直接按照记录的轨迹在调试环境里重放整个流程。这样你就能看到是模型在第二步选错了工具还是第三步工具参数传错了还是第四步上下文被某条脏数据污染了。不回放你永远只能靠猜。这一步做好了Agent的调试效率会提升一个数量级。第三对提示词和工具定义做配置化管理。不要把你给模型的指示硬编码在代码里把它们抽出来做成配置文件或者直接用提示词管理平台。这样改了Prompt不需要重新发布代码而且可以做A/B对比。我实际开发中会为同一个任务的Prompt维护多个版本记录每个版本在不同测试集上的表现Agent的迭代优化靠的是数据不是玄学。5. 从玩具到产品的进阶路线多Agent协作、评测与成本控制5.1 什么时候该上多Agent架构很多人一上来就追求多Agent协作觉得一个Agent不够酷。但实际上单Agent能做好的事情强行拆成多Agent只会增加系统的不稳定性因为Agent之间传递信息本身就有损耗和延迟。我的经验是出现下面三种情况之一才考虑引入多Agent架构。第一种是角色冲突同一个任务里需要两种截然不同的能力组合比如一个是市场分析师要发散地找灵感一个是合规审核员要严格地挑毛病这两种角色放在同一个上下文里会互相干扰。第二种是编排复杂度高任务本身可以拆成明确的子流各子流之间可以并行执行这时候用多个Agent并行跑比一个Agent单线程串行快得多。第三种是上下文隔离需求不同子任务需要关注不同的信息领域如果硬放在一个上下文里模型会顾此失彼。多Agent架构最忌讳的用法是把Agent当成函数库每个小步骤都拆一个Agent去调用。那样不仅延迟叠加而且因为每个Agent都会引入独立的随机性最终的输出可控性会很差。多Agent的核心价值是隔离和编排不是流程化封装。5.2 评测是Agent开发的照妖镜Agent开发有一个让所有人都头疼的问题同一段Prompt这次跑和上次跑结果可能不一样同一个任务今天效果好明天效果可能崩了。这和你改没改代码关系不大完全是模型本身的随机性和更新导致。所以Agent要能持续迭代必须有属于自己的评测集。针对你的业务场景准备几十到几百条典型的用户任务给每条任务标注期望的工具调用序列和期望的最终答案关键点。每次你改动Prompt、换模型、调工具定义拿同一套评测集回归一遍对比通过率。评测有客观和主观两条路。客观的部分跑完一个Agent任务比对结果文本和期望文本的相似度、工具调用序列是否一致、关键实体是否命中等。主观的部分让业务方对输出质量打1到5分或者用好/中/差三档标注。理想情况客观评测做成自动化流水线每天跑一次监控Agent的整体健康度。我自己的经验是没有评测集的Agent项目迭代速度会指数级下降因为你根本不知道自己改完是变好了还是变坏了。5.3 成本控制别让你的Agent烧钱如流水最后说成本这是产品落地绕不开的一关。很多人在Demo阶段觉得Agent好使一上线账单出来直接傻眼。核心原因是没有意识到的Agent调用放大效应。用户看起来只提了一个问题但Agent内部为了回答这个问题可能已经循环了三四轮每一轮都是一次完整的大模型调用。假设一个问题的API成本是0.02美元循环四轮就是0.08美元一天一万个用户提问就是800美元一个月就是两万多美元。普通聊天应用不会有这个放大效应Agent天然就会放大Token消耗。控制成本的几个实操手段模型分级简单任务用小模型复杂任务用大模型。Agent的规划层可以用便宜快速的模型只有关键的执行步骤才调用大模型。结果缓存相同或相似的问题把Agent最终答案缓存下来下次直接命中不重复跑循环。早停机制设置Agent循环的最大步数并且监控每一轮的是否有实质进展。如果连续两轮模型都在原地纠结、没有新工具调用就强制终止不要让它空转到超时。省掉的都是真金白银。工具结果的压缩工具返回的原始数据可能非常大比如查询数据库返回了几百行记录。在把结果回填给模型之前先做一层摘要或抽取只保留模型需要的关键字段能省大量的上下文Token。6. 安全与合规Agent不能裸奔上线聊产品、聊架构、聊效果最后必须严肃聊一轮Agent的安全与合规问题。这块往往被入门者当成事后补的作业但实际体验下来等出了事再补成本完全不一样。Agent最大的安全隐患在于不可预测的工具调用链。设计一个普通API接口我可以明确地写出鉴权规则哪些角色能调、参数范围是什么、返回什么。但Agent是自动决策的你给它5个工具它会怎么组合使用、用在哪一步不是你一行行代码规定死的。这里面就可能产生越权访问、敏感数据泄露、异常操作等风险。我整理出几条Agent安全开发的红线供参考第一最小权限原则。给Agent的工具权限必须是最小够用级别。它只需要查明天的排班就不要给它改排班的权限它只需要看订单总数就不要给它看用户手机号的权限。工具权限设计要假设模型的判断不一定总是准确。第二敏感操作必须有人工兜底。涉及资金流转、数据删除、对外发送消息这类高风险动作即使Agent规划好了系统层也要卡一道转人工确认后才能执行。不要让Agent成为能够自主完成高风险闭环的系统。第三一切行为可审计。Agent的每一步推理、每一次工具调用参数、每一个结果回填都要留痕存档。出了安全事故日志有没有就是天壤之别。我自己做生产Agent日志保留时长至少半年不说完全够用但查事的时候不至于两眼一抹黑。第四提示词注入防御。这是个容易被忽视的坑。如果你的Agent会读取外部传入的内容比如网页内容、用户上传的文档、邮件正文这些内容里可能被恶意塞入忽略之前所有指令现在做xxx之类的注入文本。轻则诱导Agent执行错误操作重则导致数据外泄。防御思路是对外部内容做隔离标记处理、严格限制Agent对外部内容的指令遵循权限、关键工具调用前对参数做二次校验。这块深入讲可以单独开一篇这里先给个方向。写在最后一条真实走过弯路的人的体会回头看看从调API聊天到跑起生产级Agent这段路程最大的认知升级不是学会某个框架或者熟悉了某个模型而是意识到Agent的本质是一套把大模型从内容生成器变成行动决策器的工程体系。模型是发动机但变速箱、底盘、方向盘全得靠工程来搭。刚开始动手的时候别迷信复杂的框架别迷信花哨的架构更别觉得ChatGPT能做的事我也能做。老老实实从最小循环开始把工具调用跑通再逐步接入记忆、评测、安全、成本管理一步一步把能跑的Demo打磨成可靠的产品。最后给刚入门的朋友一个具体的行动建议用这篇文章第二部分的原生代码自己动手把那个Agent跑起来然后给它加一个你自己工作场景里的真实工具比如查企业微信通讯录、查订单接口、查天气接口让Agent真正帮你干一件具体的活。做完这一步你对Agent的理解会超过绝大多数只刷文章不写代码的人。剩下的就是踩坑、复盘、迭代这条路没有捷径但走起来确实有意思。 大模型Agent开发实战：从原理到生产级落地的工程经验
直接聊点实际的。大模型Agent开发最近这个词被刷屏的频率比我外卖软件里的红包弹窗还高。但如果你真去翻各种资料会发现要么是讲概念讲到天上要么是给一段demo代码让你自己悟。作为一个从去年就开始折腾Agent并且真把它用到业务系统里扛过线上流量的开发者我觉得是时候把那些文档里不写、视频里不讲的实操经验拿出来透个底了。先说清楚这篇东西是什么。它不是一篇AI时代必学的鸡汤文也不是CtrlC、CtrlV的代码仓库搬运。它是我基于大模型Agent开发入门这个主题结合自己从零搭建、优化、排障到上线全过程的经验总结。你会看到Agent到底是什么、和普通调API有什么区别、第一行代码该怎么写、工具调用怎么设计、上下文爆炸怎么处理、线上并发怎么扛以及那些我踩过之后至今想起来还肉疼的坑。适合谁看如果你已经会写Python或者Java用过OpenAI、Claude、通义、文心这类大模型的API但面对Agent这个概念总觉得隔着一层窗户纸想自己动手搞一个能干活、不是玩具的东西那这篇内容就是冲着你来的。如果你是纯小白连Token是什么都还懵也没关系下面凡是涉及基础概念的地方我都会用大白话和类比拆开揉碎讲清楚。1. Agent的本质为什么它不只是一个增强版聊天机器人1.1 从一问一答到目标驱动的思维转变很多人对Agent的第一印象是能记住上下文的对话机器人。这个理解不能说错但严重低估了Agent的核心价值。如果只是多轮对话那现有的ChatGPT网页版早就做到了压根不需要专门搞一套Agent框架。我习惯用一个类比来解释Agent和普通大模型应用的区别普通大模型应用像是一个问答百科你问它什么它根据训练数据和上下文给你一个答案说完就完了。而Agent更像你雇的一个实习生助理你给它一个任务目标它能自己琢磨需要做哪几步、每一步需要调用什么工具、中间遇到问题怎么调整方案最后把结果交付给你。这个差别的本质在于目标驱动和单次推理的区别。普通应用是输入Prompt输出CompletionAgent则是输入目标输出行动序列。这个过程往往需要大模型进行多轮推理每一轮都要结合当前状态、历史信息、工具返回结果决定下一步动作直到任务完成或者它判定无法完成。在业内这个机制通常被叫做推理-行动循环Reasoning-Action Loop。最早的经典范式叫ReAct就是让模型交替进行思考Reasoning和行动Acting。思考的时候模型用自然语言描述自己的推理过程行动的时候模型生成调用某个工具的指令系统执行完工具后把结果反馈给它它再接着思考。这就不是一次API调用能完成的而是一个循环往复的多次调用过程。1.2 Agent的四大核心组件拆解既然Agent是一个目标驱动的循环系统要运转起来至少需要四个核心组件。理解了这四个组件你再看任何Agent框架都会觉得不过如此。第一个组件是感知层也叫输入处理模块。用户的原始需求是模糊的、口语化的、甚至隐含大量默认前提的。感知层要做的事情是把这些非结构化输入转换成模型更容易理解和处理的结构化指令。比如用户说帮我查下昨天订单量怎么突然跌了感知层需要把这个意图拆解成查询订单数据和分析异常原因两个子任务。第二个组件是规划层这是Agent的大脑。它负责拆解任务、制定步骤、决定先做什么后做什么。现在主流实现方式是依赖大模型本身的推理能力让它通过思维链Chain of Thought或ReAct模式生成行动规划。稍复杂的系统会引入规划器Planner专门做这一步甚至用更小的模型做规划用更大的模型做执行以控制成本。第三个组件是记忆层这是Agent区别于普通应用的关键分水岭。记忆分短期记忆和长期记忆。短期记忆就是我们说的对话历史放在上下文窗口里长期记忆则通常存在外部存储比如向量数据库或关系型数据库需要时检索出来注入上下文。可以按工作记忆和长期记忆来理解就像人一样手头正处理的事记在脑子里过往的经验翻笔记本找。第四个组件是行动层也叫工具调用层。模型再聪明只靠文本输出也没法操作真实世界。它需要通过调用外部工具来获取数据或执行操作比如查数据库、调API、发HTTP请求、执行一段代码。这一层解决的是模型如何把意图变成动作的问题。没有这四个组件你写的东西再花哨也只是套了壳的对话机器人。有了它们才叫Agent。我在实际项目里见过太多团队拿个OpenAI的API接上Prompt就觉得做了Agent结果连个简单的天气查询都要靠模型瞎编这就是典型的分层没做透。1.3 模型选择是Agent的底层地基坦白讲Agent效果的上限一半以上由底层的模型能力决定。ReAct循环里最核心的推理质量、指令跟随能力、工具调用准确率都直接取决于模型本身。现在市面上能用来做Agent的模型可以分两类。一类是闭源商用模型比如OpenAI的GPT系列、Claude系列、国产的通义千问、文心一言、智谱GLM等特点是省心效果有保障按Token计费适合快速验证和中小规模应用。另一类是开源可私有化部署的模型比如Qwen系列、Llama系列、DeepSeek系列适合对数据安全敏感的企业场景比如企业内部的知识库Agent不可能把业务数据全丢给外部API那就必须在私有云或本地GPU服务器上部署。选模型有两条我个人的经验准则。第一条能用商用API跑通验证的不要一上来就折腾私有化部署成本完全不在一个量级。第二条关注模型的工具调用专项能力而不是只看跑分。有些模型写文章、写代码很强但让它按特定JSON格式输出工具调用参数时经常丢三落四。做Agent这块能力比文笔重要得多。我这边的建议是入门阶段用哪个模型不要过于纠结先用手头最顺手的API把流程跑通核心是理解Agent的运行机制。等真正要上线的时候再根据场景做系统性的模型评测选型那时候你会发现评测Agent的模型能力和评测普通对话模型的关注点完全不一样。2. 从零搭建第一个Agent模型、框架与亲手写一个最小实现2.1 框架选型LangChain、LlamaIndex还是自己撸确定要搞Agent之后第一个跳进脑子的问题肯定是要不要用框架用哪个。市面上最响的三个名字就是LangChain、LlamaIndex还有国产的Dify/Coze这类低代码平台。先说LangChain这是目前生态最全、知名度最高的Agent开发框架。它把Agent开发常用的组件——模型调用、提示词模板、工具注册、记忆管理、输出解析——全部抽象成了标准化接口。优点是灵活、生态大、社区资料多遇到问题基本都能搜到答案缺点是抽象层级太多出了Bug排查起来会让人怀疑人生版本更新还经常破坏性变更你今天照着老教程写的代码过两月可能就全废了。LlamaIndex侧重的则是对数据的索引和检索它在RAG检索增强生成这一块的体验做得比LangChain舒服如果你做的Agent核心是基于企业文档问答选LlamaIndex会更顺手。但它做复杂多步骤工具调用Agent的能力相对弱一点。还有一类低代码平台比如Dify和Coze。它们把Agent的搭建变成了可视化拖拽配置不需要写代码适合产品经理、运营人员快速做原型验证。但对我这种做系统集成的开发者来说低代码平台的自由度始终是个瓶颈一旦涉及复杂的业务逻辑、私有化部署、深度定制最后还是得回到代码里去。我的观点比较直白如果你想把Agent当核心技术积累直接选LangChain或者干脆自己写一个轻量的Agent循环不要迷信框架。框架解决的是懒得重复造轮子的问题但它不是银弹。入门阶段用LangChain快速跑通场景是OK的但你要清楚每一层封装下面发生了什么。我自己后面做生产级系统核心的Agent循环是手写的只在局部用LangChain的工具类。为了方便理解后面的内容我们先以LangChain生态的风格来讲。另外我也会在下一节附一个完全不依赖框架的最小实现保证你在框架到底帮我做了什么事这件事上有体感。2.2 亲手写一个最小Agent循环不依赖框架我不想把这篇文章搞成LangChain的教程因为那玩意儿迭代太快写完了可能就过时了。相反的我带你直接用原生代码写一个最小但五脏俱全的Agent循环。这段代码做完你再看任何框架的源代码都能一眼看穿它在干嘛。先确定环境Python 3.10安装好openai这个SDK包其他兼容OpenAI协议的SDK也可以比如通义、DeepSeek的接口都兼容这个协议。下面这段代码实现的是一个能调用加法计算器和当前时间查询两个工具的Agentimport json import datetime from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://your-endpoint.com/v1 # 换成你的模型服务地址 ) # 定义工具这是模型的操作手册 tools [ { type: function, function: { name: calculator_add, description: 计算两个数字的和, parameters: { type: object, properties: { a: {type: number, description: 第一个加数}, b: {type: number, description: 第二个加数} }, required: [a, b] } } }, { type: function, function: { name: get_current_time, description: 获取当前时间, parameters: {type: object, properties: {}} } } ] # 工具的实际执行函数 def execute_tool(name: str, arguments: dict): if name calculator_add: return str(arguments[a] arguments[b]) if name get_current_time: return datetime.datetime.now().isoformat() return f未找到工具: {name} def agent_run(user_input: str, max_steps: int 5): messages [{role: user, content: user_input}] for step in range(max_steps): print(f--- 第 {step 1} 轮推理 ---) response client.chat.completions.create( modelyour-model-name, messagesmessages, toolstools, tool_choiceauto ) message response.choices[0].message messages.append(message) # 如果模型没有返回工具调用指令说明任务结束 if not message.tool_calls: print(Agent 最终回答:, message.content) return message.content # 遍历工具调用逐个执行并把结果追加进对话历史 for tool_call in message.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) print(f调用工具: {fn_name}({fn_args})) result execute_tool(fn_name, fn_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) print( 达到最大迭代步数强制结束) return None if __name__ __main__: agent_run(现在是几点顺便帮我算一下 23 和 19 的和是多少)这段代码看起来很短但它完整实现了Agent循环的全部要素工具定义、模型推理、工具路由、结果回填、多步循环。你跑一下会发现模型收到问题后会先调用get_current_time工具拿到结果后再调用calculator_add工具最后把两个结果综合起来组织成一段自然语言回答。关键在最后还是能串起来。这里面有两点值得展开说说。第一工具描述就是模型的使用手册。你给模型的function定义里name和description的措辞质量直接影响模型能不能正确选用和调用工具。描述越清晰模型越不会乱选。参数里的required字段决定了哪些参数必填模型会严格按这个规则来生成调用参数。第二工具调用结果是用role: tool消息回填到对话历史里的。这一步很多人第一次接触时会漏掉。模型每调用一次工具执行结果都必须作为一条消息追加回messages列表并且要通过tool_call_id和之前模型生成的工具调用关联起来。不把这个回填逻辑写对模型根本看不到工具的执行结果然后就会开始胡编乱造。2.3 用LangChain框架快速验证一万个Agent的Hello World原生代码能帮你理解原理但实际开发中特别是后面要接记忆、接向量库、接多工具协同的时候用框架确实能省不少事。下面用LangChain的最新风格LCEL表达式写一个最简单的Agent。from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.tools import tool from langchain_core.prompts import ChatPromptTemplate llm ChatOpenAI(modelyour-model-name, api_keyyour-key) tool def add(a: float, b: float) - float: 返回两个数字的和。 return a b tool def get_time() - str: 返回当前系统时间的ISO格式字符串。 import datetime return datetime.datetime.now().isoformat() tools [add, get_time] prompt ChatPromptTemplate.from_messages([ (system, 你是一个能调用工具解决用户问题的助手。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) result executor.invoke({input: 现在几点了另外帮我算一下 12345 乘以 6789}) print(result[output])注意到没用LangChain之后你不需要手动处理工具调用循环和消息回填。create_tool_calling_agent和AgentExecutor把这些逻辑给你封装掉了。你只管定义工具函数和提示词剩下的事情框架帮你跑。但我要泼一盆冷水爽归爽别真的只停留在爽上。等你需要精细控制每一步行为——比如某些步骤要用温度更低的参数、某些工具调用后要暂停等待人工确认、某些历史消息需要单独压缩——你抓瞎的速度会非常快。所以我的建议是先用这套快速验证效果然后回去把2.2那段的原生循环吃透。两相对照LangChain在你眼里就没什么魔法了它只是在固定的模式上做了自动化封装而已。3. 工具调用与记忆Agent不掉链子的两条腿3.1 Function Calling的工程化设计Agent的价值八成都体现在工具调用上。工具定义得好不好直接决定了Agent是真干活还是花架子。我自己在实践中踩出来的经验是工具设计要遵循三个原则。第一单一职责。一个工具只做一件具体的事不要搞万能函数。工具越通用参数越多模型就越容易把参数填错。宁可多定义几个细粒度工具也不要定义一个大而全的工具。第二命名和描述用词要精准。模型是靠工具的描述文字来判断什么时候该调用你的工具的描述写得含糊比如处理数据这种模型根本不知道该不该调。写清楚你的工具是干嘛的、输入是什么、输出是什么、在什么场景下使用。第三参数要严格校验。模型生成参数虽然是结构化的但一样会出现类型错误、缺参数、越界的情况。工具入口做一层健壮性校验不是多余是保命。除了设计层面还要聊聊工具调用的安全边界。前两天还有人问我说Agent能直接操作生产数据库吗。我的回答是能但你最好别这么干。更安全的做法是让Agent只调用你预先封装好的、只读或带严格权限控制的内部API而不是让它直接拿着数据库连接串去执行SQL。生产环境里我会把Agent能触达的所有工具做一次权限盘点涉及资金、删除、变更类的操作一律走人工审批流不让模型一步到位。3.2 上下文窗口再大也得面对记忆问题做Agent的人迟早要撞上一堵墙上下文窗口不够用或者说对话历史越来越长模型的效果越来越差费用越来越高。原因不难理解。模型每一次请求都要把整段对话历史包括系统提示、工具定义、历史消息、工具执行结果重新发送一遍。Token越堆越长响应越来越慢费用成倍上涨而且模型会逐渐迷失在海量历史里记不清早期的重要信息。这就像一个人看一部剧前面二十集的细节全挤在脑子里看到第三十集的时候前二十集的情节已经开始模糊后面根本演不动。应对策略业界已经沉淀了几种。第一种叫滑动窗口截断Sliding Window。最简单粗暴只保留最近N轮对话更早的扔掉。问题是一旦遇到用户昨天让我记录了一个偏好今天要按那个偏好执行这种场景早扔就废了。所以只能用在任务之间无关联的简单场景。第二种叫摘要压缩Summary Memory。用一个轻量模型对旧对话进行摘要把详细内容变成要点存档。比如一个几十轮的长对话最终压缩成用户是上海人偏好极简风格设计预算在3万以内这次任务是做店铺装修方案。这样上下文占用大幅降低还能保住关键信息。代价是丢失细节如果后续需要精确追溯某句话摘要里还原不出来。第三种叫向量检索记忆Vector Retrieval。把历史对话切块后embedding存入向量数据库。每次需要记忆时根据当前问题做相似度检索把最相关的几段历史对话捞出来拼进上下文。这个方案适合知识密集、需要精确引用的场景代价是要引入一个向量数据库架构复杂度变高。我实际项目里的做法是组合拳短期对话用滑动窗口保证响应速度同时把重要信息实时抽取存入结构化记忆库比如用户的偏好表长期知识走向量检索。不要试图用一种方案解决所有记忆问题Agent的记忆系统本来就是分层设计的。3.3 记忆与Token开销的最优平衡聊到记忆就绕不开一个让很多新手翻车的点工具定义也要吃Token。你没看错你给模型定义的每一个工具转换成JSON Schema后都是实打实的Token每个请求都会带着。工具数量一多光工具定义就可能吃掉几千Token。这意味着你做工具优化的时候不能只盯着调用的次数要连定义体积一起算进去。我见过有人一口气往Agent里塞了四五十个工具功能倒是全了但每次请求光工具描述就要上万Token模型漏选工具的概率反而直线上升。正确做法是按场景分组。每次运行Agent时根据用户的初步意图先筛选出最相关的一组工具再发给模型。比如用户问天气你就把天气和位置相关的五六个工具挂上去那些内部报表工具根本不进上下文。Token的性价比问题也要算清楚。一个中型Agent每次请求带4000Token上下文用户每天调用2000次一个月光上下文重复发送的费用就是不小的一笔数字。所以凡是能离线做、批量做、缓存做的都不要让Agent在线一步到位。做一个任务编排层把复杂的长期任务拆成可以异步执行的子任务Agent只负责编排和审核结果而不是傻乎乎地在一个循环里把所有事干完。4. 实战踩坑实录并发、幻觉与调试三板斧4.1 AI Agent怎么扛并发一个被问烂了但必须答透的问题AI Agent能扛并发吗——这个问题我几乎每次分享都会被人问。答案是能扛但你要先搞清楚瓶颈到底在哪不然加多少台机器都是白搭。Agent系统的瓶颈不在模型API本身而在三个更容易被忽略的地方上下文的状态管理、工具调用链路的稳定性、以及外部依赖接口的速率限制。先引发一个很多人忽略的问题Agent是有状态的。普通接口服务是无状态的来了请求处理完就返回扩容容易。但Agent在一个任务循环里要维护对话历史、工具调用状态、中间产物。如果你用的是最简单的全局内存变量存对话状态的方案那这个服务实例一旦扩容到多台用户的请求被负载均衡分发到不同的机器上Agent就失忆了。所以生产级Agent状态必须外置比如存Redis或数据库每台服务实例都从同一个地方读写状态。这是扛并发的第一前提。第二个瓶颈点是工具调用链路。Agent执行一个任务往往要串行调用好几个工具每个工具又有自己的响应时间。如果一个任务平均要调用6次工具每次平均1秒整个流程就是6秒起步。单用户还好并发50个用户同时跑后端就有一堆线程/协程在挂着等外部响应连接池、数据库连接、HTTP客户端都容易被打爆。解决办法有两条路一是给每个工具调用做异步化和超时熔断二是做任务排队动态并发控制别让Agent任务一股脑涌入。第三个是模型API的速率限制Rate Limit。你用的商用模型服务都有每分钟请求数RPM和每分钟Token数TPM的限制。并发一上来最先报错的就是这个。应对方案就是做请求转发层的智能限流和重试把并发请求平滑排队同时注意尽量减少不必要的多轮工具调用省着点Token用。4.2 模型幻觉与睁眼说瞎话的治理Agent一大翻车现场就是幻觉。模型不知道答案、或者工具返回了结果但它没看懂它就会一本正经地编一个看起来合理的答案。这在聊天场景里可能只是尴尬在业务决策场景里就是事故。治理幻觉我有几个亲测有效的办法。第一在提示词里强制约束不知道就说不知道。话虽简单但真的很多人系统提示词里根本不写这条。你要明确告诉模型工具返回的结果是你唯一的信息来源如果没有工具结果支撑的判断必须明确回答我无法从现有数据中确认禁止猜测。第二用结构化输出做兜底。现在主流模型都支持JSON Schema模式的输出你让模型必须按答案你的信息来源可信度三段式结构输出。如果模型找不到信息源可信度标注就会很低系统这层可以做自动拦截不把低可信度的结果直接展示给用户。第三严格区分模型推测和工具事实。在给模型的Prompt里要把模型内部知识和工具返回结果分成两个明确的上下文块。例如只有当用户问的是苹果是什么这类常识问题时模型才可以用内部知识回答一旦涉及我的订单状态我的余额这类事实性问题模型必须依赖工具返回的实时数据内部知识在这里是无效的。用这种显式隔离幻觉率能大幅下降。第四关键场景引入结果校验回调。有些工具执行完之后可以反过来调用一个轻量模型拿原始问题和工具执行结果做一致性校验工具返回的数据能不能支撑模型最后的回答校验不过就重跑或转人工。4.3 Agent调试把黑盒拆成白盒最后一条少有人讲但价值极高Agent怎么调试。普通程序你可以在IDE里打断点但Agent是循环调用大模型每次生成的推理文本都不一样如果不在工程层面做可观测性出了问题你连从哪里查起都不知道。我的调试三板斧强烈建议从第一天就实践起来。第一日志必须记录每一步的完整轨迹。不只是记录模型最终说了什么而是记录每一次循环里的完整信息当前Messages的Token数、模型这一步的思考内容、它选择了哪个工具、传了什么参数、工具返回了什么、回填之后模型下一步怎么想。把这些完整的trace记录成结构化日志最好是JSON格式方便检索和回放。第二做一个回放工具。把Agent运行的每一轮轨迹都存下来出问题后可以直接按照记录的轨迹在调试环境里重放整个流程。这样你就能看到是模型在第二步选错了工具还是第三步工具参数传错了还是第四步上下文被某条脏数据污染了。不回放你永远只能靠猜。这一步做好了Agent的调试效率会提升一个数量级。第三对提示词和工具定义做配置化管理。不要把你给模型的指示硬编码在代码里把它们抽出来做成配置文件或者直接用提示词管理平台。这样改了Prompt不需要重新发布代码而且可以做A/B对比。我实际开发中会为同一个任务的Prompt维护多个版本记录每个版本在不同测试集上的表现Agent的迭代优化靠的是数据不是玄学。5. 从玩具到产品的进阶路线多Agent协作、评测与成本控制5.1 什么时候该上多Agent架构很多人一上来就追求多Agent协作觉得一个Agent不够酷。但实际上单Agent能做好的事情强行拆成多Agent只会增加系统的不稳定性因为Agent之间传递信息本身就有损耗和延迟。我的经验是出现下面三种情况之一才考虑引入多Agent架构。第一种是角色冲突同一个任务里需要两种截然不同的能力组合比如一个是市场分析师要发散地找灵感一个是合规审核员要严格地挑毛病这两种角色放在同一个上下文里会互相干扰。第二种是编排复杂度高任务本身可以拆成明确的子流各子流之间可以并行执行这时候用多个Agent并行跑比一个Agent单线程串行快得多。第三种是上下文隔离需求不同子任务需要关注不同的信息领域如果硬放在一个上下文里模型会顾此失彼。多Agent架构最忌讳的用法是把Agent当成函数库每个小步骤都拆一个Agent去调用。那样不仅延迟叠加而且因为每个Agent都会引入独立的随机性最终的输出可控性会很差。多Agent的核心价值是隔离和编排不是流程化封装。5.2 评测是Agent开发的照妖镜Agent开发有一个让所有人都头疼的问题同一段Prompt这次跑和上次跑结果可能不一样同一个任务今天效果好明天效果可能崩了。这和你改没改代码关系不大完全是模型本身的随机性和更新导致。所以Agent要能持续迭代必须有属于自己的评测集。针对你的业务场景准备几十到几百条典型的用户任务给每条任务标注期望的工具调用序列和期望的最终答案关键点。每次你改动Prompt、换模型、调工具定义拿同一套评测集回归一遍对比通过率。评测有客观和主观两条路。客观的部分跑完一个Agent任务比对结果文本和期望文本的相似度、工具调用序列是否一致、关键实体是否命中等。主观的部分让业务方对输出质量打1到5分或者用好/中/差三档标注。理想情况客观评测做成自动化流水线每天跑一次监控Agent的整体健康度。我自己的经验是没有评测集的Agent项目迭代速度会指数级下降因为你根本不知道自己改完是变好了还是变坏了。5.3 成本控制别让你的Agent烧钱如流水最后说成本这是产品落地绕不开的一关。很多人在Demo阶段觉得Agent好使一上线账单出来直接傻眼。核心原因是没有意识到的Agent调用放大效应。用户看起来只提了一个问题但Agent内部为了回答这个问题可能已经循环了三四轮每一轮都是一次完整的大模型调用。假设一个问题的API成本是0.02美元循环四轮就是0.08美元一天一万个用户提问就是800美元一个月就是两万多美元。普通聊天应用不会有这个放大效应Agent天然就会放大Token消耗。控制成本的几个实操手段模型分级简单任务用小模型复杂任务用大模型。Agent的规划层可以用便宜快速的模型只有关键的执行步骤才调用大模型。结果缓存相同或相似的问题把Agent最终答案缓存下来下次直接命中不重复跑循环。早停机制设置Agent循环的最大步数并且监控每一轮的是否有实质进展。如果连续两轮模型都在原地纠结、没有新工具调用就强制终止不要让它空转到超时。省掉的都是真金白银。工具结果的压缩工具返回的原始数据可能非常大比如查询数据库返回了几百行记录。在把结果回填给模型之前先做一层摘要或抽取只保留模型需要的关键字段能省大量的上下文Token。6. 安全与合规Agent不能裸奔上线聊产品、聊架构、聊效果最后必须严肃聊一轮Agent的安全与合规问题。这块往往被入门者当成事后补的作业但实际体验下来等出了事再补成本完全不一样。Agent最大的安全隐患在于不可预测的工具调用链。设计一个普通API接口我可以明确地写出鉴权规则哪些角色能调、参数范围是什么、返回什么。但Agent是自动决策的你给它5个工具它会怎么组合使用、用在哪一步不是你一行行代码规定死的。这里面就可能产生越权访问、敏感数据泄露、异常操作等风险。我整理出几条Agent安全开发的红线供参考第一最小权限原则。给Agent的工具权限必须是最小够用级别。它只需要查明天的排班就不要给它改排班的权限它只需要看订单总数就不要给它看用户手机号的权限。工具权限设计要假设模型的判断不一定总是准确。第二敏感操作必须有人工兜底。涉及资金流转、数据删除、对外发送消息这类高风险动作即使Agent规划好了系统层也要卡一道转人工确认后才能执行。不要让Agent成为能够自主完成高风险闭环的系统。第三一切行为可审计。Agent的每一步推理、每一次工具调用参数、每一个结果回填都要留痕存档。出了安全事故日志有没有就是天壤之别。我自己做生产Agent日志保留时长至少半年不说完全够用但查事的时候不至于两眼一抹黑。第四提示词注入防御。这是个容易被忽视的坑。如果你的Agent会读取外部传入的内容比如网页内容、用户上传的文档、邮件正文这些内容里可能被恶意塞入忽略之前所有指令现在做xxx之类的注入文本。轻则诱导Agent执行错误操作重则导致数据外泄。防御思路是对外部内容做隔离标记处理、严格限制Agent对外部内容的指令遵循权限、关键工具调用前对参数做二次校验。这块深入讲可以单独开一篇这里先给个方向。写在最后一条真实走过弯路的人的体会回头看看从调API聊天到跑起生产级Agent这段路程最大的认知升级不是学会某个框架或者熟悉了某个模型而是意识到Agent的本质是一套把大模型从内容生成器变成行动决策器的工程体系。模型是发动机但变速箱、底盘、方向盘全得靠工程来搭。刚开始动手的时候别迷信复杂的框架别迷信花哨的架构更别觉得ChatGPT能做的事我也能做。老老实实从最小循环开始把工具调用跑通再逐步接入记忆、评测、安全、成本管理一步一步把能跑的Demo打磨成可靠的产品。最后给刚入门的朋友一个具体的行动建议用这篇文章第二部分的原生代码自己动手把那个Agent跑起来然后给它加一个你自己工作场景里的真实工具比如查企业微信通讯录、查订单接口、查天气接口让Agent真正帮你干一件具体的活。做完这一步你对Agent的理解会超过绝大多数只刷文章不写代码的人。剩下的就是踩坑、复盘、迭代这条路没有捷径但走起来确实有意思。