说实话，过去这一年我被问得最多的问题就是：“大模型聊天我会了，但Agent到底怎么开发？”每次看到“Agent开发”这四个字被各种包装成玄学，我都有点坐不住。实际上，大模型Agent的本质就是让模型在循环里做事，它不神秘，但它确实有一整套和普通接口调用完全不同的工程细节。
这篇内容完全是面向“想真正动手的人”的：你可以是刚入门的大模型应用开发者，也可以是从传统后端开发转过来的工程师，甚至可以是没有写过一行代码但想搞清楚Agent机制的产品经理。我会从概念讲起，把Agent的架构拆开，然后带你把一个完整的Agent跑起来——这个示例不是Hello World，而是一个能真正干活的“K线分析助手”。整个过程我会把我自己踩过的坑、试过错、最后证明可行的方案全部写出来。
1. 大模型Agent到底是什么：先把它从概念神坛上拉下来
1.1 从ChatGPT到Agent：能力边界到底差在哪
先聊一个最基础的问题：ChatGPT你已经用得很熟了，它和Agent有什么区别？
如果你只用ChatGPT问问题，你会得到一个回答，仅此而已。无论你问“今天北京的天气怎么样”还是“帮我查一下某支股票的近30日K线”，它给出的都只是一段文本，而且大概率是它根据训练数据编出来的话。它不会真的去查天气，也不会真的去拉行情数据。
Agent不一样。Agent的核心不再是“生成一段回答”，而是“完成一个任务”。它把大模型当作一个大脑，这个大脑可以决定“下一步要做什么”，可以调用外部工具（比如查天气的API、拉K线的API、执行代码解释器），然后根据工具返回的结果决定“下一步再做什么”，直到任务完成为止。
这个过程有一个专业术语叫“ReAct循环”：Reasoning（推理）加 Acting（行动）。模型先想，然后动，观察结果，然后再想再动。吴恩达在他的Agent教程里反复强调过一个观点：Agent并不是一个新的模型架构，而是一个把“模型+工具+循环”组合起来的应用范式。我觉得这个表述非常准确。
1.2 Agent核心模块拆解：感知、规划、行动、反思
如果要给Agent画一个大脑结构图，我个人习惯把它拆成四个模块。
感知层（Perception）负责接收外部输入。用户提出的自然语言只是最原始的感知，更完整的Agent还会接入实时数据源、环境状态、甚至其他Agent的输出作为感知输入。在你的代码里，感知层基本就是你的系统提示词（System Prompt）、用户消息和工具执行后的结果拼接。
规划层（Planning）是大模型发挥核心价值的地方。LLM在这里把一个大任务拆成若干子任务，决定先调用哪个工具、后调用哪个工具，并为每一步写出思考和理由。这一层的能力取决于模型本身的推理能力和你的提示词设计，和模型参数量的关系很大。
行动层（Acting）负责真正执行决策。模型输出一个带有工具调用意图的指令，代码解析这个指令，去调用API、执行函数、读写文件，然后把结果以“Observation（观察结果）”的形式交回给模型。行动层是你的工程主战场：函数怎么写、参数校验怎么做、返回值怎么处理，全在这层。
反思层（Reflection）容易被新手忽略，但它是Agent质量稳定与否的分水岭。模型在拿到工具返回的结果后，需要判断“结果是否符合预期”“是否需要换个方式再试”“是否任务已经完成”。这对应的就是循环体中模型的一次次重新推理。
我用一个生活类比帮朋友理解这四个模块：你叫外卖，看菜单是感知，决定这家就点个黄焖鸡是规划，下单付款是行动，吃到嘴发现太辣，打开小程序补点一杯冰饮料，这就是反思后的再次行动。没有反思机制的Agent，就像完全不看结果，点完外卖就不管了的自动程序。
1.3 Agent走向工程化的三个关键背景
为什么2024年之后Agent开发被频繁提及，因为三个条件在这个时间点同时到位了。
第一，模型本身的函数调用（Function Calling）能力成熟了。无论是OpenAI的模型还是国产开源模型，现在都能稳定输出结构化的工具调用指令，而不再需要你靠正则表达式去解析一段自由文本里夹带的“行动意图”。这个基础能力直接决定了Agent的工程可行性。
第二，框架生态形成了。从鼻祖级的LangChain，到后来的LangGraph、AutoGen、CrewAI、Dify，再到国内社区的一些开源编排方案，Agent的开发工具链已经相当完备。很多人说“框架本身就是Agent开发的门槛”，实际上恰恰相反，框架把门槛降低了。
第三，应用需求倒逼范式转型。光是聊天已经满足不了企业了，大家真正想要的是“让系统替人把流程跑完”：自动运维、自动数据分析、自动生成报表、自动处理工单，这些都需要Agent这种能一次次调工具、能纠错、能自主推进的形态。
不过也要泼一盆冷水：Agent开发目前最大的挑战在于稳定性。模型存在幻觉，工具调用可能不按预期返回，流程可能走偏，成本还可能失控。这些不是算法问题，而是工程问题，也就是这篇文章后面要重点展开的内容。
2. 动手之前先把这几件事想清楚：任务、模型、框架
2.1 什么任务适合用Agent来解
我见过很多人一上来就问“怎么用Agent做个电商客服”，但聊两句发现他们的需求其实是“把常见的50个问题用知识库自动回答”，这根本用不着Agent，一个RAG管道就能解决，更高效更便宜。
诚实的建议是：并不是所有任务都适合Agent，Agent适合的任务有几个共性特征。
第一，任务有明确目标但路径不确定。比如“帮我分析这些日志，找出异常原因”，目标明确，但中间要看哪些日志、跑哪些统计、要不要查历史数据，全是动态决定的，这时候Agent的优势就出来了。
第二，任务需要借助外部信息或工具。模型的知识有截止日期，内部数据它一概不知，只有通过工具调用把外面的数据、业务系统的数据拿进来，任务才能往下走。如果纯粹是“把我传给你的文字润色一下”，那其实是单轮优化任务，不适合Agent。
第三，任务允许试错和迭代。Agent的循环本质就是一个“尝试—观察—再尝试”的过程，你不能要求它一次性成功、零成本失败。像支付、手术规划这类一次定生死且没有容错空间的场景，现在让Agent全自动接管是不负责任的，更合适的方式是“人类审批+Agent建议”。
2.2 模型怎么选：别光看跑分，看你的任务需求
选模型这件事，我建议你只看三个维度。
第一个维度是函数调用能力，这是Agent的命门。有些模型聊天能力很好，但输出工具调用时格式不稳定，经常把JSON字段名写错，或者明明要求输出固定Schema却混入描述性文本。我会在第三部分的实操里告诉你如何检验一个模型的函数调用到底稳不稳。
第二个维度是上下文长度。Agent一次任务往往要往返很多轮，每轮都要携带工具返回结果，上下文消耗比普通问答高一个量级。32K的上下文听起来不小，实际跑起来几轮对话就满了，所以要么选长上下文模型，要么你后面必须做上下文管理——我强烈建议你两条腿走路。
第三个维度是成本与部署方式。API模型的优势是质量稳定、省心；本地部署的好处是数据私有化、无单次调用费用，但并发量和显存限制往往让人头疼。国内可用的开源方案里，Qwen系列和DeepSeek系列在工具调用上的表现都值得一试，跑在消费级显卡上也能干活。
另外提醒一句，不要只看宣传的跑分。真实Agent任务里，模型表现受提示词影响极大，同一模型在差提示词和好提示词下的工具调用成功率能差出20个百分点。我的习惯是先把候选模型和我的任务提示词绑在一起做一次小规模评测，再决定要不要买量。
2.3 框架选型：新手到底该不该直接上框架
这是个很现实的问题。市面上的主流方案我大体分三类。
第一类，直接用模型厂商的SDK手写Agent循环。代码量不大：一个while循环，一次次的chat completion，判断输出内容是普通消息还是工具调用指令。好处是你能把整个机制吃透，任何一个环节出问题你都知道去哪看；坏处是很多工程化的事（记忆管理、状态维护、多Agent协作、可观测性）要自己造轮子。
第二类，通用编排框架LangGraph。它的核心思路是把Agent流程定义成一张状态图，节点是各种操作（调用模型、执行工具、外部条件判断），边是状态转移。它适合流程相对固定、状态复杂的任务，比如客服工单处理、审批流转。学习曲线确实陡，得理解图、状态、节点、边那套概念。
第三类，多Agent协作框架，AutoGen和CrewAI是代表。核心思路是多个角色化Agent互相配合：一个研究Agent、一个写代码Agent、一个审查Agent，互相发消息完成任务。这种强交互模式适合头脑风暴、多视角分析类的任务，但调试起来是真的麻烦，一个Agent理解偏了会把整个团队带跑偏。
我给新手的建议非常明确：别一上来就套框架，先手写一个最小Agent循环。框架的价值在工程化，不在魔法。你直接用SDK写一个循环调工具，跑通一次，你就能理解所有框架的设计初衷，之后再看LangGraph、AutoGen都不会懵，而是会想“这个框架把我的哪些痛点解决掉了”。
2.4 环境与工程基建：没有日志就别做Agent开发
写Agent和写普通API服务有一点很不一样：普通API是确定性输入输出，出问题直接看参数看返回值就能定位；Agent是模型驱动的非确定性程序，你根本不知道它下一步会调什么工具。这种情况下，日志和追踪不是可选项，是必需品。
我自己的最小工程化配置有三样。一样是Python环境管理，用虚拟环境把依赖隔离干净，避免不同项目的包互相冲突，这个基础但又重要。另外这样是API密钥管理，永远放在环境变量里，永远不要提交到代码仓库，这是最基本的安全红线。第三样是请求日志，所有发给模型的请求、模型返回的结果、工具执行结果都要落日志，最好带trace_id把一次Agent任务的完整链路串起来。
现在主流框架也都集成了可观测性，比如LangSmith、Phoenix，有预算的话建议直接用，它能把每一步的token消耗、延迟、模型输出都可视化出来。我最开始没用这套，结果线上Agent出了幻觉，我对着几百行裸日志排查了一整天才定位到是某一次工具返回里的一个坏数据把模型带偏了。有了追踪工具，这种问题五分钟就能看到。
3. 从零开始搭建一个真正能干活的K线分析Agent
3.1 场景定义：让Agent做什么、边界在哪
教技术最好用真实场景。这个示例我选择“股票K线分析助手”，也是因为这类任务特别适合展示Agent的特性：它需要实时数据（模型不知道今天的行情）、需要多步处理（拉数据、算指标、写结论）、需要调用外部工具（行情API和计算函数）。但我要声明一句，这个示例只做技术演示，不构成任何投资建议。
需求我定义得尽量窄：用户给一支股票代码，Agent负责完成三件事。第一，用行情API拉取该股票最近30个交易日的日K线数据。第二，根据K线数据计算5日和20日均线，判断当前趋势。第三，输出一份结构化的分析摘要，包括最新收盘价、近30日涨跌幅、均线状态和一句趋势判断。
边界也很重要：这个Agent不预测未来、不生成买卖建议、不处理除A股股票代码以外的标的。把边界写清楚有两个好处，一是避免模型越界胡扯，二是方便你在系统提示词里给模型立规矩。
3.2 工具层设计：函数定义与安全校验
Agent的“手脚”就是工具函数。我不会让模型直接调用交易所API，而是给它包一个简单的数据服务接口。这里有个关键心得：工具函数的输入输出格式要做到极简，不要让一次工具调用返回一大堆无关字段。模型很吃这个，冗余信息越多，它提取关键信息的出错率越高。
我设计了两个工具。
第一个是get_daily_kline(stock_code, days)，传入股票代码和天数，返回标准的K线数据列表，每个元素包含日期、开盘价、收盘价、最高价、最低价。代码在示例里我会用模拟数据替代真实API，方便你直接跑通。
第二个工具是calculate_ma(kline_data, window_size)，传入K线数据和均线周期，返回最近一日的均线值以及近几日的趋势。把计算函数独立出来而不是让模型自己做算术，理由很简单：模型做算术是弱项，这种确定性的运算交给代码最靠谱。
工具层还有一个安全细节：对输入参数做白名单校验。函数调用是模型直接触发的，如果模型被人诱导输出了一个恶意股票代码，或者传入了超大days参数，你的工具层应该能拦下来。我在代码里加了简单的参数范围检查，实际生产环境里你还应该加鉴权、限流和敏感信息过滤。
3.3 Agent核心循环：手写一个最小可运行的Agent
现在到整篇文章最关键的部分了。我用最少的代码实现Agent循环，不用任何框架，仅依赖模型SDK。伪代码写出来极其直观：
第一步，把系统提示词、用户消息和工具定义（Schema）一起发给模型。第二步，模型返回两种可能：如果是普通文本回复，说明它认为任务完成了，结束；如果返回的是工具调用指令，解析出工具名和参数。第三步，在本地执行对应工具函数，拿到结果，拼装成一条“工具返回消息”。第四步，把这条工具返回消息追加到对话历史中，回到第一步重新问模型。第五步，设置最大迭代轮数（我习惯设10轮），防止Agent陷入死循环。
下面是一个可运行的极简版本代码。
import json from openai import OpenAI client = OpenAI(api_key="your-api-key", base_url="your-base-url") TOOLS = [ { "type": "function", "function": { "name": "get_daily_kline", "description": "获取某只股票最近指定交易日数的日K线数据", "parameters": { "type": "object", "properties": { "stock_code": {"type": "string", "description": "股票代码，如600519"}, "days": {"type": "integer", "description": "交易日数量，1-60之间"} }, "required": ["stock_code", "days"] } } }, { "type": "function", "function": { "name": "calculate_ma", "description": "计算K线数据中最近一日指定周期的均线值", "parameters": { "type": "object", "properties": { "kline_data": {"type": "array", "description": "日K线数据列表，每个元素需包含日期和收盘价"}, "window_size": {"type": "integer", "description": "均线周期，如5或20"} }, "required": ["kline_data", "window_size"] } } } ] def get_daily_kline(stock_code: str, days: int) -> list: # 模拟数据，真实场景替换为行情API import random random.seed(hash(stock_code) % 1000) if not (0 < days <= 60): raise ValueError("days必须在1到60之间") result = [] price = 50.0 for i in range(days): price = round(price * (1 + random.uniform(-0.04, 0.04)), 2) result.append({ "date": f"2025-{(i // 28) + 1:02d}-{(i % 28) + 1:02d}", "close": price, "high": round(price * 1.02, 2), "low": round(price * 0.98, 2), "open": round(price * 0.99, 2) }) return result def calculate_ma(kline_data: list, window_size: int) -> dict: closes = [item["close"] for item in kline_data] if len(closes) < window_size: raise ValueError("K线数据长度不足，无法计算均线") ma = sum(closes[-window_size:]) / window_size return {"window_size": window_size, "ma_value": round(ma, 2), "period": "recent"} def run_agent(user_query: str, max_steps: int = 10): messages = [ {"role": "system", "content": "你是K线分析助手。你有两个工具：get_daily_kline和calculate_ma。当用户提出分析需求时，你应该先获取K线数据，再根据需要计算均线，最后给出结构化摘要。如果工具返回错误，请尝试调整参数重试。"}, {"role": "user", "content": user_query} ] for step in range(max_steps): response = client.chat.completions.create( model="your-model-name", messages=messages, tools=TOOLS, tool_choice="auto", temperature=0.2 ) msg = response.choices[0].message if msg.tool_calls: messages.append({ "role": "assistant", "content": msg.content if msg.content else "", "tool_calls": [ {"id": tc.id, "type": "function", "function": {"name": tc.function.name, "arguments": tc.function.arguments}} for tc in msg.tool_calls ] }) for tc in msg.tool_calls: args = json.loads(tc.function.arguments) if tc.function.name == "get_daily_kline": result = get_daily_kline(args["stock_code"], args["days"]) elif tc.function.name == "calculate_ma": result = calculate_ma(args["kline_data"], args["window_size"]) else: result = {"error": "unknown tool"} messages.append({ "role": "tool", "tool_call_id": tc.id, "content": json.dumps(result, ensure_ascii=False) }) print(f"[Step {step+1}] 调用工具: {msg.tool_calls[0].function.name}") continue # 模型认为任务完成，输出最终回答 return msg.content return "已达到最大迭代轮数，任务可能未完成。" print(run_agent("请分析代码600519最近30日的K线趋势，计算5日和20日均线，并给出趋势判断。"))这段代码我实测过，改动一个模型名和一个Key，在支持函数调用的模型平台上就能跑通。代码本身没用什么高深的技巧，但它就是一个合格的Agent骨架。
有几个细节我想单独说明。tool_choice="auto"的意思是让模型自己决定要不要调用工具，如果你的任务必须强制先调工具，也可以设成required或者指定具体工具名。temperature我压低到0.2，因为Agent任务需要稳定执行而不是发散创作，温度太高模型会给你编出各种奇怪的行动。
另外注意工具函数里的异常处理设计：get_daily_kline对days做了范围校验，calculate_ma检查了数据长度。这些校验不是多此一举，它们在真实场景里就是在防止模型“乱来”，比如模型突然传了一个days=999，没有校验的话你的Agent就会飞出去打爆外部接口。我实际开发的Agent项目里，工具层的输入校验往往比业务逻辑本身还要多，这是必要的防御性编程。
3.4 系统提示词才是Agent的灵魂
代码写完很多人以为就结束了，其实还有一个花费功夫不亚于代码的部分：系统提示词。
同一个Agent，系统提示词写得好不好，任务成功率能差出一大截。我总结了一套适合Agent开发的提示词模板，五个要素一个不能少。
第一，角色定位。告诉模型它是什么，比如“你是K线分析助手”。定位会直接影响模型的语言风格和决策偏好。第二，工具说明和调用策略。不要只列出工具名，要教模型“先做什么、再做什么”，比如“应该先获取K线数据，再根据需求计算均线，最后给出分析摘要”。这就是给Agent植入工作流的根基。第三，输出格式要求。要求结构化输出，比如“必须给出最新收盘价、近30日涨跌幅、均线状态、趋势判断四部分”，不要让它自由发挥。第四，错误处理策略。告诉模型“如果工具返回错误，尝试调整参数重试”，没有这句，模型一旦遇到工具报错就会直接放弃或者胡编结果。第五，安全与边界约束。明确“不预测未来”“不提供买卖建议”“只处理指定市场股票”，防止越界。
这里还要提一个最近圈子里讨论很多的概念：记忆安全。Agent的记忆模块保存着用户偏好和任务上下文，如果这部分内容被构造性输入污染，Agent就可能在后续步骤中被诱导做出错误决策。像a-memguard这类针对LLM Agent记忆的防御框架，核心思路就是给Agent的短期记忆和长期记忆加一层过滤和校验。我在工程实践中的做法是：凡是外部输入的信息，默认不可信，写入记忆前必须经过格式化校验；凡是工具返回的数据，使用前要做字段白名单校验。这个习惯值得每个Agent开发者尽早养成。
3.5 并发、成本与稳定性：从跑通Demo到扛住访问
代码跑通了，接下来要考虑“AI Agent怎么扛并发”这个问题。我注意到热词搜索里很多人搜这个，足以说明这是从Demo走到上线之间的拦路虎。
首先明确Agent和普通接口在并发上的本质区别：普通接口处理一个请求可能只需要几百毫秒，而Agent一个任务可能要循环调用5到10次模型API，耗时几十秒，单请求成本高一个数量级。你的后端不能像处理普通接口那样有多少请求就开多少处理线程，不然模型API的限流会瞬间把你打爆。
我常用的手段有这么几样。一是异步化改造，用asyncio把工具调用和LLM调用变成协程而不是线程，避免线程上下文切换开销，同时可以控制并发度。二是请求级限流，用一个信号量控制同时进行的Agent任务数量，比如全局限5个并发，再配合一个按用户的速率限制（比如单用户每分钟最多启动2个任务）。三是缓存工具结果，同一个工具函数、同样的参数在短时间内的调用结果基本一样，尤其是行情数据这种高频重复查询，缓存可以砍掉大量外部API调用。四是超时与重试，对所有模型调用和工具调用设置超时，失败时按指数退避重试，重试次数上限我习惯设3次，不能再多，否则雪崩风险太高。
成本控制方面，我建议你在Agent入口就设两道闸。第一道是任务级token上限：在循环里统计每次对话的token消耗，一旦超过阈值就强制终止并让Agent输出“任务超限，需要简化需求”。第二道是轮数上限，就是我代码里的max_steps，这是最基础也最有效的成本护城河。
还有一个实操技巧：尽量把工具返回的内容截短再塞给模型。行情接口返回30天K线可能几千个字节，模型不关心中间那几天，你直接把最后几天的数据和高低点摘要传过去就够了。上下文短了，成本低了，模型的注意力也更集中。
4. 常见问题与排查技巧实录：我踩过的最多的坑
4.1 模型输出工具调用格式错乱怎么办
这是Agent新手最容易遇到的问题，没有之一。你的代码明明没错，但模型返回的tool_calls参数里经常出现字段名拼写错误、参数值类型不对、JSON解析失败这些情况。
我的排查路径是这样的。第一步，检查模型本身是否真的支持函数调用。很多模型走的是兼容层，函数调用能力很弱，你喂的Tools Schema它根本不理解，这时候换一个原生支持Function Calling的模型效果立竿见影。第二步，检查工具的Schema是不是太复杂。如果一个工具需要七八个嵌套参数，模型很容易出错，处理方法是把工具拆小，一个工具只干一件简单的事。第三步，降低温度，把temperature从0.7调到0.1甚至0，模型的输出稳定性会显著提升。第四步，给模型提供少样本示例，在系统提示词里写清楚“当你想获取数据时，应该这样调用工具”，给一个标准调用示例。
如果以上都试了还是不行，最土但最有效的办法是用一层代码兜底：在解析tool_calls失败时，把模型的原始输出重新喂回模型，告诉它“你刚才的输出格式不对，请只输出JSON”，这个方法能救回很大一部分失败请求。
4.2 Agent跑到第三步方向就偏了
我最早做多步Agent的时候，经常看到模型在第一步、第二步还正常，到了第三步突然开始自由发挥，分析的内容跟工具返回的数据之间没有关系，甚至是凭空生成的。
这类问题我现在的解法是：把大步骤拆小，并且在关键节点强制校验中间结果。举个例子，K线分析任务至少拆成两个Agent阶段：第一阶段只负责“拉数据”，输出统一格式为“已获取数据，准备用于计算”，并把数据存到Agent状态里；第二阶段才负责“算指标并总结”。每阶段单独调用，阶段之间用代码做状态字段的校验，不满足就报错重试。
还有一个很重要的设计思路叫“人类监督节点”（Human-in-the-loop）。不是所有环节都要人盯着，而是要在风险最高、最容易偏离的那一步加一个人工确认。比如Agent要执行一个带有不可逆后果的工具（删除文件、对外发请求、转账），中间插一个“等待用户确认”的分支。对K线分析这种只读任务来说，这个分支可加可不加，但对于运维类Agent，这一步是必须的。
4.3 上下文越跑越长，幻觉越跑越严重
Agent是多轮循环，每轮都把历史翻出来重发，上下文长度肉眼可见地涨。上下文一长会带来两个问题：一是成本直线上升，二是模型注意力涣散，容易忽略系统提示词里的规则，开始胡言乱语，也就是“上下文越涂越脏”。
最直接的解决方法是上下文裁剪。我在实际项目里的做法是：消息历史只保留最近3轮对话摘要，更早期的对话改用一段自然语言摘要代替：大模型技术在上下文工程里主流的做法需要用户积极介入。具体怎么实现，可以把关键信息提取成一个总结，然后作为一条system消息放回对话里，取代那几条冗长的历史。当然，真的用到这步说明你的Agent任务已经足够复杂了，前两步还不足以支撑它跑完步骤，需要在这种框架下，一方面采用关键信息摘要，另一方面可以给重要的固定知识单独开一个“静态上下文区”，不随每轮对话重复携带。
另外要提醒一点，工具返回的大K线列表在每一轮都会被重复发送给模型，这个开销很大。我的习惯是“工具结果瘦身”：只返回最近几条数据和统计摘要，历史数据内部存在本地状态里，模型需要时再引。这个技巧能让你的token消耗直接砍半。
4.4 并发一上来，API疯狂报429错误
本地写好了，放到测试环境模拟真实流量一打，好家伙，模型API提供商直接给了你一堆429限流响应，伴随的还有连接超时、偶发的5xx。
这是正常的，你的Agent任务消耗的是多个模型API调用，所以并发压测的时候，限流阀值比普通API更高也更真实。应对策略我在3.5节说了四个手段，这里再展开说一下重试的具体参数。我发现指数退避配合随机抖动是最稳的：第一次失败等1秒，第二次等2秒，第三次等4秒，然后加上0到1秒随机抖动防止所有请求同时重试造成“惊群”。重试上限设3次，再多已经没有意义，反而会把你自己的出口带宽和数据库打满。
同时我强烈建议你做请求队列+限流阀。用一个Semaphore控制最大并行数，比如5到10，剩下的请求排队。表面上看这是降低了吞吐量，实际上因为API限流的存在，无序盲目发请求的最终有效吞吐量反而更低。
4.5 评估与测试：别把“调通一次”当成“项目完成”
最后说一个最容易被忽略的事：Agent项目的测试和评估。
传统的单元测试对Agent这种非确定性系统作用有限，你不能断言一个模型在给定输入下“一定调用哪个工具”。正确的评估思路是搭一套“黄金样本集”，准备10到20条典型用户问题，每条都配上理想的工具调用序列和最终回答要点，然后每次改动提示词或模型后，把整个样本集跑一遍，统计任务成功率。
还有两个关键指标建议关注：一个是工具调用有效率，即所有模型发出的工具调用中，确实对完成任务有贡献的比例；另一个是无效轮次率，即Agent多少次循环是在重复同一类动作而无实效。这两个指标比单次成功与否更敏感，能帮你尽早发现Agent在“假性工作”。
评估方式上，除了人工看输出，还可以用“LLM as Judge”的做法：让另一个更强的模型给Agent的输出打分，做出结构化评估。我自己跑下来，这种方式能省非常多人工时间，但要注意法官模型本身也会有偏好，关键指标还是要定期人工抽检对齐。
末尾再聊几句实在的
写到这里，我觉得最值得强调的经验就一条：做Agent开发，别一上来就追求大而全。把自己的第一个Agent“缩小”不是示弱，恰恰是聪明。先把一个任务做到闭环跑通，把工具调用、上下文管理、成本控制、异常处理这些基本功练扎实，再慢慢叠加多步骤、多Agent协作、记忆机制这些进阶能力。我见过太多人一上来就搞多Agent架构，最后连日志都看不懂。
每次我在实际项目中踩坑，最后复盘时都会发现同一个规律：Agent的问题，绝大多数不是模型不够聪明，而是工程不够扎实。提示词边界不清晰就怪模型幻觉，工具参数不校验就怪函数调用不稳定，并发没限流就怪API不抗压。把工程做扎实，你的Agent自然会变得靠谱起来。
如果这篇内容能帮你把第一个Agent顺利跑起来，让你对“大模型Agent开发”这个概念的体感从“玄”变成“具体”，我觉得就值了。后面有机会的话，我再写写多Agent协作和Agent记忆管理这些更深的模块。
