说实话过去这一年我被问得最多的问题就是“大模型聊天我会了但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管道就能解决更高效更便宜。诚实的建议是并不是所有任务都适合AgentAgent适合的任务有几个共性特征。第一任务有明确目标但路径不确定。比如“帮我分析这些日志找出异常原因”目标明确但中间要看哪些日志、跑哪些统计、要不要查历史数据全是动态决定的这时候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线分析Agent3.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_keyyour-api-key, base_urlyour-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: f2025-{(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( modelyour-model-name, messagesmessages, toolsTOOLS, tool_choiceauto, temperature0.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_asciiFalse) }) print(f[Step {step1}] 调用工具: {msg.tool_calls[0].function.name}) continue # 模型认为任务完成输出最终回答 return msg.content return 已达到最大迭代轮数任务可能未完成。 print(run_agent(请分析代码600519最近30日的K线趋势计算5日和20日均线并给出趋势判断。))这段代码我实测过改动一个模型名和一个Key在支持函数调用的模型平台上就能跑通。代码本身没用什么高深的技巧但它就是一个合格的Agent骨架。有几个细节我想单独说明。tool_choiceauto的意思是让模型自己决定要不要调用工具如果你的任务必须强制先调工具也可以设成required或者指定具体工具名。temperature我压低到0.2因为Agent任务需要稳定执行而不是发散创作温度太高模型会给你编出各种奇怪的行动。另外注意工具函数里的异常处理设计get_daily_kline对days做了范围校验calculate_ma检查了数据长度。这些校验不是多此一举它们在真实场景里就是在防止模型“乱来”比如模型突然传了一个days999没有校验的话你的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记忆管理这些更深的模块。
从零手写K线分析Agent：大模型Agent开发核心原理与工程实践
说实话过去这一年我被问得最多的问题就是“大模型聊天我会了但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管道就能解决更高效更便宜。诚实的建议是并不是所有任务都适合AgentAgent适合的任务有几个共性特征。第一任务有明确目标但路径不确定。比如“帮我分析这些日志找出异常原因”目标明确但中间要看哪些日志、跑哪些统计、要不要查历史数据全是动态决定的这时候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线分析Agent3.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_keyyour-api-key, base_urlyour-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: f2025-{(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( modelyour-model-name, messagesmessages, toolsTOOLS, tool_choiceauto, temperature0.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_asciiFalse) }) print(f[Step {step1}] 调用工具: {msg.tool_calls[0].function.name}) continue # 模型认为任务完成输出最终回答 return msg.content return 已达到最大迭代轮数任务可能未完成。 print(run_agent(请分析代码600519最近30日的K线趋势计算5日和20日均线并给出趋势判断。))这段代码我实测过改动一个模型名和一个Key在支持函数调用的模型平台上就能跑通。代码本身没用什么高深的技巧但它就是一个合格的Agent骨架。有几个细节我想单独说明。tool_choiceauto的意思是让模型自己决定要不要调用工具如果你的任务必须强制先调工具也可以设成required或者指定具体工具名。temperature我压低到0.2因为Agent任务需要稳定执行而不是发散创作温度太高模型会给你编出各种奇怪的行动。另外注意工具函数里的异常处理设计get_daily_kline对days做了范围校验calculate_ma检查了数据长度。这些校验不是多此一举它们在真实场景里就是在防止模型“乱来”比如模型突然传了一个days999没有校验的话你的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记忆管理这些更深的模块。
