最近这段时间只要打开技术社区满屏都是AI Agent——有人用它处理日常事务有人在项目里用它串联多个业务流程还有人在讨论用Agent做测试、做客服、做数据分析。但真正把AI Agent的工程实现做到能跑进生产、能排查问题、能持续迭代的人其实比想象中少。大多数人卡住的点并不是“大模型会不会说话”而是“Agent怎么组织自己的思考、怎么调用工具、怎么记住关键信息、出了错怎么兜底”。这篇文章想用一套我自己在复盘多个Agent项目后沉淀下来的框架来讲先把一个Agent拆开看看它到底需要哪些部件——我整理成了七要素再聊动手实现时必须想清楚的七个关键决策——也就是标题里的七个决策点。不管你是刚开始学Agent开发还是已经写过一些Function Calling但发现稳定性上不去这套思路应该都能帮你把整个项目串起来。1. 为什么聊工程实现而不是概念1.1 从一个“调用”到一个“系统”先把一个常见误区说清楚调一次大模型API不算Agent让大模型在一个循环里自主决策、调用工具、根据工具返回的结果修正下一步才算是Agent。很多人以为Agent开发就是把模型从单轮问答改成多轮对话但真正动手之后才发现难的不是“让模型说话”而是“让系统兜住模型的每一次输出”。举个例子一个简单的客服机器人如果只是把用户问题丢给模型让它回答那它只是一个ChatBot。但如果你要求这个机器人能查订单、能判断售后政策、能决定要不要转人工那模型就必须自己决定“什么时候调订单接口、什么时候调用售后规则库、什么时候直接回话”。这个过程会把应用从一次调用变成一个循环系统接收任务、拆解规划、调用工具、观察结果、再规划、直到给出最终结论。工程难度也从“怎么调API”变成“怎么控制循环的稳定性”。这就是我为什么一定要从工程实现的角度来拆解Agent。聊概念容易让人兴奋但工程实现才是决定项目能不能落地的那道坎。模型选型错了、工具定义不规范、容错没做、没有评测任何一个环节都会让Agent从“能跑”变成“经常出怪问题”。1.2 一套把“看”和“做”串起来的框架“七要素”和“七个决策点”这两套东西我平时是分开用的但只有把它们放在一起看才真正能指导一个项目从0到1落地。七要素解决的是“看清结构”的问题。任何一个Agent不管它是什么形态底层都跑不开模型、规划、记忆、工具、行动、知识、反馈这七个部件。就像买房子之前要先知道一栋楼需要地基、承重墙、水电管线、门窗一样Agent也需要这些基本件才能撑起来。用这套拆法当你看到一个开源Agent项目或者一篇架构稿的时候能快速知道它强在哪、弱在哪。七个决策点解决的是“动手做”的问题。真正开发Agent的时候你不可能一次把七个部件都设计到满分只能按顺序一个接一个做选择——用哪个模型、Prompt怎么组织、记忆存多少、规划拆多深、工具怎么定义、失败怎么重试、最后怎么验证。七个决策点就是这七次关键选择。它们和七要素一一对应但是视角从“看结构”变成了“做决定”。这套框架不是某个官方标准而是我在项目里反复碰壁碰出来的方法论。Agent这个东西很多人把它讲得很玄但落到工程上就是一连串有顺序的问题。按顺序答好这七个问题你的Agent基本就跑起来了答不好大概率会在后面的某个环节反复返工。2. 从七个要素拆开一个真实Agent2.1 模型层Agent的智商基线模型是Agent的大脑这个说法没毛病但工程上我更愿意把它叫做“智商基线”。模型选定了Agent的推理上限、复杂指令理解能力、工具调用能力就都定死了后面做什么都被这个基线框住。工程上选模型主要看四件事推理能力、上下文窗口、工具调用稳定性、成本。推理能力决定它能不能处理复杂任务比如多轮推理叠加多个工具上下文窗口决定它能同时“记住”多少信息工具调用稳定性决定它能不能老老实实按你定义的JSON结构输出成本则决定这个方案能不能长期跑。很多团队在模型上省成本结果后面花了几倍的开发时间去兜住模型的低级错误这是得不偿失的。模型层还有一个经常被忽略的点模型和工具之间的交互协议。现在主流的方式是Function Calling也就是模型在回答里输出一个结构化指令告诉系统“我要调用哪个工具、传什么参数”。模型对这类指令的生成能力是有差别的指令越复杂、参数嵌套越深出错的概率就越高。所以模型选型一定不能只看指标得拿自己真实的工具定义去试。2.2 规划层把目标拆成可执行的步骤有了大脑还不够一个Agent要完成复杂任务得先把目标拆成步骤。规划这个要素在大模型Agent出来之前就存在经典的做法是任务分解图谱把一个大任务拆成多个子任务再判断哪些子任务能并行、哪些必须串行。大模型时代规划策略主要分两种路线。一种是隐式规划依赖模型自己的推理能力一步步往前走典型代表是ReAct模式让模型交替进行“思考”和“行动”走一步看一步。另一种是显式规划先让模型生成一个完整的行动计划再按计划去执行比如Plan-and-Execute。两种路线没有绝对的好坏工程上更多是混合着用先用一个模型生成计划然后执行计划的过程中再根据反馈动态调整。规划层最容易犯的工程错误是过度设计。把简单任务拆成太多子步骤每一步都要调用一次模型延迟和成本成倍上涨Agent反倒更容易迷失方向。我的经验是能三步走完的任务绝对不要拆成五步规划的意义是让模型少走弯路而不是让模型多走路。2.3 记忆层短期工作台与长期档案柜记忆在Agent里的地位经常被低估。没有记忆的Agent每次对话都是“失忆”状态只能靠上下文里还能放下的那些内容活着。这里需要先说清楚一个基础概念Token它本质上是模型处理文本的最小单位一个Token可以是一个字、一个词、也可能是半个词。每次调用模型输入输出的Token数量直接决定成本和上下文是否溢出。记忆从工程上分两层。短期记忆就是当前会话的上下文窗口模型能直接看到对话历史和工具返回结果。它的特点是读取快、不需要额外存储设施但是窗口天生有限放太多内容既贵又容易让模型“忽略重点”。长期记忆则是把关键信息存到外部系统比如向量数据库、KV存储或者普通数据库需要的时候再检索出来放回上下文。工程上最核心的记忆问题是取舍。不是所有历史都值得记住也不是所有工具返回结果都得塞进上下文。记忆层做的其实是“什么东西放工作台、什么东西归档到档案柜”的决策。这个决策做不好Agent会话一长就崩。2.4 工具层Agent的外挂能力工具是Agent连接外部世界的接口。模型本身只会生成文本不能直接去查数据库、调API、操作浏览器工具的作用就是把模型的结构化输出翻译成真实世界能执行的操作。工具的定义方式有讲究。当前主流做法是用JSON Schema描述工具告诉模型这个工具叫什么、接收什么参数、每个参数的类型和约束条件。模型根据这个描述决定要不要调用工具、传什么值。另一个方案是MCP也就是模型上下文协议把工具发现和调用标准化让Agent可以动态发现可用的工具。MCP更适合工具数量庞大的场景但对于大多数中小项目JSON Schema加上良好的描述已经足够了。工具数量的控制是工程上的一个经典问题。理论上工具越多Agent越强大但实际上工具越多模型的选择难度越大。工具描述写得不清晰、工具之间边界模糊模型就很容易调错工具或者反复在几个工具之间徘徊。我的习惯是工具能合并就合并数量控制在十几个以内每个工具的用途描述尽量突出“什么时候用”而不是“是什么”。2.5 行动层从“决定做”到“真正做”工具和行动在很多人眼里是一回事但在工程实现上必须分开看。工具是“接口描述”是模型知道“可以做什么”行动是“真实执行”是系统真正去调用API、修改数据库、发送消息。模型可以决定要调用工具但真正执行操作的必须是系统代码绝不能是模型直接就改数据。这个分层对安全至关重要。工具层只负责描述能力行动层才掌握执行权限。举个例子一个能操作数据库的Agent模型的职责是判断“该查哪张表、用什么SQL”系统代码的职责是真正执行数据库查询并校验返回结果。如果把SQL执行直接交给模型输出而未经过校验模型的一次错误输出就可能造成严重数据问题。行动层工程上该关注的还有权限边界、超时控制和幂等性。一个Agent能操作的事务越多权限越要收敛能读不要写能限制范围就不要全量开放。超时控制防的是工具调用挂死幂等性防的是重复执行造成同样的副作用。这些都是把Agent从“演示”推向“生产”时必须补的课。2.6 知识层限定Agent的能力边界知识层解决的是“Agent知道什么”。模型从训练数据学到的知识是通用且滞后的它不知道你的业务规则、产品名称、内部数据结构所以需要在运行时把业务知识喂给它。常见的方式有两种一是写进系统Prompt直接把关键规则打包在指令里二是通过RAG检索增强生成从外部知识库检索相关内容注入上下文。知识层的工程难点在于怎么让Agent在“知道得多”和“被约束住”之间取得平衡。知识注入得太多上下文变长、Token成本上升、模型容易被无关信息干扰知识注入得太少Agent又容易一本正经地胡说八道。这里没有标准答案只能按实际情况调。知识层还连着另一个重要命题安全性。Agent的上下文里既要有知识也可能混入用户输入里的恶意内容。如果用户的输入里带了“忽略之前的指令”模型可能就会被带偏。工程上对抗这个问题的手段包括把系统指令写在消息的强约束位置、对用户输入做转义或隔离、对Agent准备执行的高危操作做二次确认。知识层本质上是在划定“Agent可以信任什么”的边界。2.7 反馈层知道自己干得好不好最后一个要素是反馈。没有反馈的Agent就像一个没有考试的学生永远不知道自己学成什么样也没法优化。反馈机制在Agent工程里包括两个层面。第一层是Agent内部的自我纠错。一个Agent在执行任务时工具返回了异常或者结果不符合预期它能根据反馈修正下一步动作而不是硬着头皮继续往下走。这在工程上通常表现为把工具返回的错误信息原样塞回上下文让模型理解“这个方案行不通换个方案”。自我纠错的能力决定了Agent面对不确定性时的韧性。第二层是Agent外部的效果评估。一个Agent跑完之后它到底算不算成功需要一个可量化的评价机制。可以是基于规则的判断比如工具是否调用成功、最终答案是否包含关键字段也可以基于模型的评估让一个更强的模型给Agent的回答打分还可以结合人工抽检。没有评估就没有迭代方向这是反馈层作为七要素最后一环的价值。七要素拆完可以用一张表简单对照要素工程职责常见组件/技术最容易踩的坑模型层提供推理能力GPT系列、Claude、开源模型只看指标不看工具调用稳定性规划层把目标拆成步骤ReAct、Plan-and-Execute过度拆解延迟和成本翻倍记忆层保存和检索信息上下文窗口、向量库所有历史全塞进上下文工具层描述可调用能力JSON Schema、函数调用工具数量失控描述不清晰行动层真实执行并产生副作用API调用、Sandbox模型直接执行未被校验的动作知识层注入业务规则与边界系统Prompt、RAG知识注入过多干扰模型判断反馈层自纠错与效果评估自评、规则校验、人工抽检没有评估永远凭感觉优化3. 七个决策点真正动手前要想清楚的事如果说七要素是“看清一部机器有哪些零件”那这七个决策点就是“按什么顺序把这些零件拧到一起去”。我列出来的七个决策点每一个都对应一个必须在动手前想清楚的问题。顺序也重要因为前面的决策会直接影响后面能怎么选。3.1 决策点一选哪个模型第一个决策永远是模型选型。我见过不少项目先写了一大堆代码最后发现模型推理能力撑不住场景整片返工。正确的顺序是拿最真实的场景样例去测模型再决定用哪家。怎么测不要拿通用题去测要拿“你的任务、你的工具描述、你预期模型输出的结构化结果”去测。重点是看它对工具调用的理解能力给它一个需要查数据的任务看它能不能准确选择工具并传对参数。另一个重点是看它在“收到不完美结果”时的表现工具返回了空数据它会怎么反应是重新换个方式查还是开始瞎编答案。这两点几乎决定了一个模型适不适合做你的Agent基座。成本决策也要放在这一步。闭源模型效果好但按Token计费一个Agent跑一个任务可能要调好几次模型单次成本乘以调用次数就是一个可观的数。开源模型的推理能力也许弱一些但胜在可控。我的建议是初期用闭源模型快速验证场景稳定后再考虑局部替换开源模型降本。3.2 决策点二Prompt架构怎么组织模型选定了接着要决定Prompt——尤其是系统Prompt的结构。这里说的不是“写一段好的提示词”而是系统的指令架构你的Agent有几层指令、任务知识放在哪里、用户输入从哪里进入、工具描述怎么编排。常用的结构是层级化Prompt最外层是系统身份和总规则中间层是业务知识和边界再往下是工具使用说明和任务引导最后才是对话轮次的组织。分层的好处是让模型在每一轮推理时都能快速定位“我现在该遵守哪一层规则”不至于被长上下文稀释掉重点。这个决策点还要考虑多Agent的情况你是用一个Agent承担所有职责还是用“规划Agent工具Agent审查Agent”这样的分工结构单Agent结构简单但职责容易过载多Agent结构清晰但沟通成本高。我的经验是早期不要上多Agent先单Agent跑到极限再拆分。大部分场景单Agent加上工具集合就能解决了。3.3 决策点三记忆怎么存、存多少第三个决策和记忆相关。你需要提前想清楚Agent需要记住多长的历史、要不要长期记忆、记忆存在哪里。短期决策是最常用的方案只保留最近几轮对话和当前任务的工具返回。实现简单、效果可控适合大量任务场景。缺点是会话稍长就会“失忆”用户之前提到的关键信息会被顶出上下文。解决办法是摘要压缩每次对话达到一定长度后把旧对话总结成一个浓缩摘要放在上下文最前面——这是一种非常实用的性价比方案。长期记忆的决策要谨慎。向量库存储适合“用户画像、历史偏好、知识片段”这类需要语义检索的内容但它需要额外的基础设施和检索逻辑也会引入新的错误来源。我的判断标准是如果Agent的业务场景真的需要跨会话记住关键信息才上长期记忆否则短期摘要就够用了。记忆层还有一个被低估的决策点记住工具调用结果。工具返回的大段JSON直接塞回上下文既占Token又干扰后续推理。很多成熟方案会把工具返回结果做压缩只保留关键字段或转成自然语言摘要。这个细节对长任务影响很大。3.4 决策点四任务规划拆到多深第四个决策是规划策略的选择。模型是“一步一个脚印”地边想边做还是先拿出完整计划再执行这个选择要看任务性质。对于步骤不太确定、需要根据中间结果动态调整的任务ReAct式的边想边做更合适。工程实现上的核心是用好“Thought, Action, Observation”三个字段让模型每轮先输出思考再输出要调用的工具然后由系统把工具返回的观测结果继续交给模型。这种模式灵活但缺点是每执行一步都要调一次模型慢且贵。对于步骤明确、顺序稳定的任务Plan-and-Execute更好。让模型先输出完整的步骤列表系统按列表逐个执行执行完一项标记一项遇到失败再回到规划层重新调整。好处是省去大量中间推理的Token消耗坏处是计划容易在执行过程中变得过时。决策的落地方式是设定最大步数上限。不管用哪种规划策略一个任务最多允许模型执行多少轮工具调用这个值必须在代码里写死。我常用的是5到8轮超过就停。防止模型在某个问题上死循环是Agent工程里最基础的护栏。3.5 决策点五工具协议怎么定义第五个决策决定了Agent的执行边界。工具描述写得好不好直接决定模型调用工具的成功率。工具定义的核心是JSON Schema它把工具的名字、参数、类型、约束条件都描述出来。但Schema写清楚了只算及格还要写清“什么时候用这个工具”。我见过太多的工具描述是“查询订单数据”没有告诉模型这个查询返回什么格式、适合回答哪类问题、参数应该从用户话术里的哪个字段提取。结果模型经常为了一个简单问题调错工具。正确的写法是描述用途加边界比如“此工具用于按订单号查询订单状态。订单号通常是10位数字可以从用户消息中提取。如果用户没有提供订单号请先向用户索要”。工具协议的另一个决策点是参数的安全性。任何能从用户输入提取的参数都应该在行动层做二次校验。比如模型提取了一个SQL条件系统在执行前是否做了白名单校验这必须提前设计好。工具协议不只是写给模型看的也是写给系统校验逻辑看的。3.6 决策点六失败之后怎么办第六个决策是容错机制这是Agent工程和普通API调用工程最明显的分水岭。普通接口调用失败一次重试一次就行了但Agent的失败模式多到让人头疼模型输出格式不对、工具调用传参错误、工具返回超时、工具返回的数据和预期完全不一致、连续几轮都没有进展。如果没有容错设计任何一个问题都会让任务卡死。容错的第一层是“把失败信息喂回给模型”。工具调用抛出的异常、返回的报错提示统一格式化成一段Observation返回给模型让模型知道刚才出了问题、问题是什么然后指令它“请根据错误信息调整参数并再次尝试”。这一层处理好了大部分偶发问题会被Agent自己消化掉。容错的第二层是系统侧的护栏。最大循环轮数、单轮超时时间、工具返回结果的大小限制、一定时间内允许的最大Token消耗这些都是系统层面必须写死的。此外重试要有上限连续失败同一工具三次就要终止当前任务转给人工或者直接返回失败一个成熟Agent系统的重要标志是“知道什么时候该放弃”。3.7 决策点七拿什么证明Agent好用最后一个决策也最容易被忽略评测怎么做。没有评测体系Agent的优化就是一个感觉导向的调整过程改了下Prompt感觉好了过两天又感觉坏了但不知道为什么。评测体系分两块。一块是离线评测集提前准备一组真实任务和对应的高质量参考答案每次改动Prompt、工具定义、模型选型之后用同一组测试跑一遍看通过率变化保证优化是正向的。测试集不需要很大二三十个真实任务就能暴露绝大部分问题关键是任务要覆盖典型的成功路径和失败路径。另一块是在线监控。Agent上线后要能记录每一次运行轨迹模型每一步的思考、每一次工具调用、Token消耗、任务是否成功。这类数据不但能帮你及时发现问题经过沉淀还能反哺离线评测集——线上出过的每一类问题都应该变成测试集里的一个用例。这七个决策点按顺序过一遍一个Agent的工程轮廓就出来了。真正动手前把这些答好后面会顺利不少。4. 实操一个最小Agent是怎么落地七要素和七个决策点的4.1 拿一个真实场景跑通全流程理论说多了容易飘直接用一个场景把自己动手的过程完整讲一遍。这个场景我做的是一个内部用的数据问答Agent用户用自然语言提问Agent负责把问题转成数据查询、执行查询、分析结果、给出结论。典型的用户问题包括“上个月销售额前五的产品有哪些”“最近两周退货率最高的品类是什么”。为什么要选这个场景因为它麻雀虽小五脏俱全需要模型推理、需要任务拆解、需要短期记忆、需要调用工具、需要执行、需要知识注入最后还需要验证结果。你不用搭建庞大复杂的架构一个主循环加两个工具就能把这个场景跑起来但每一层设计都值得抠。4.2 七个决策点在这个场景里怎么做模型选型这个场景我直接用Function Calling做得比较成熟的闭源模型。原因也很简单我需要模型稳定地输出结构化的工具调用指令早期不值得在解析格式上花太多时间。Prompt架构我的系统Prompt分成三段第一段定义角色和总目标第二段写了数据库的表结构和字段说明第三段是工具使用规范明确告诉模型“要先用get_schema确认表结构再调query_data执行查询不要在没有确认字段的情况下直接查询”。记忆设计这个场景任务相对独立我用的是只保留最近两轮的短期摘要。不再额外上向量库因为每个查询任务之间没有强依赖关系用户在第二问时提到的“对比上个季度”这种说法通过最近两轮摘要已经足够覆盖。规划策略我选了ReAct式的边想边做。数据查询场景经常要动态调整SQL预先写死计划不现实。模式上就固定成“Thought, Action, Observation”循环系统通过代码控制最多循环五轮。工具定义我设计两个工具get_schema用于查询数据库表结构query_data用于执行SQL并返回结果。Schema写法上把参数约束写到最严query_data的SQL参数必须是字符串类型返回结果限制最大行数。容错机制代码里做了三层保护。第一层query_data返回的错误会被打包成Observation交回给模型第二层循环超过五轮就强制停止第三层SQL执行前有一个简单的只读校验只允许SELECT语句防止模型误输出高危操作。评测体系我准备了一组二十条离线测试问题覆盖正常查询、需要推理才能转换的自然语言、故意缺少必要参数的场景。每次调整之后都用同一组问题回归一遍记录“任务完成率”和“平均工具调用轮数”两个核心指标。4.3 Agent主循环的核心代码结构代码不需要多复杂核心就是一个循环加六个方法。下面是我用的典型结构主要说明实现思路你搬到自己的场景里改一改就能用def run_agent(user_question: str): # messages是传给模型的消息列表 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_question}, ] for step in range(MAX_STEPS): # MAX_STEPS 5 # 1. 让模型推理允许它输出工具调用 response llm.chat(messagesmessages, toolsTOOL_DEFINITIONS) messages.append({role: assistant, content: response.content}) # 2. 如果模型没有要调用工具说明任务已经完成 if not response.tool_calls: return response.content # 3. 逐个执行工具调用 for tool_call in response.tool_calls: result execute_tool(tool_call.name, tool_call.arguments) # 4. 把工具结果塞回消息列表,交给模型继续推理 messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse), }) # 5. 达到最大轮数仍没有结束就强制终止 if step MAX_STEPS - 1: return 任务未能完成已超出最大执行轮数。 return 这段代码里比较关键的是第4步工具结果必须严格按照消息列表的追加方式返回给模型并且要带正确无误的tool_call_id。不少新手在这里漏掉id或者把role写错都会导致模型无法理解“这个结果是哪次调用的”。4.4 跑通一次完整流程观察每一步在做什么拿“上个月销量前五的商品”这个问题举例。第一轮循环模型输出的Thought是“这个问题需要查询上个月的销售数据我需要先确认商品表和销售表的结构”然后调用get_schema。工具返回两个表的结构定义被塞回消息列表。第二轮循环模型看到表结构之后输出了新的Thought“找到销售表包含商品ID和销量字段我需要按商品聚合并且按销量倒序取前五”接着调用query_dataSQL写成SELECT商品名, SUM(销量) AS total_sales FROM 销售表 WHERE 月份 2025-01 GROUP BY 商品名 ORDER BY total_sales DESC LIMIT 5。第三轮循环工具返回了正确数据模型判断“数据已经足够不需要再调用工具”直接Output出最终回答。整个流程三次工具调用轮数合理没有出现反复问同一个工具的情况Agent的工作就完成了。一次成功当然能够做到但评测体系的价值在于把它重复到二十次、五十次、一百次仍然保持稳定的成功率这才是Agent真正可用的前提。5. 常见问题与排查技巧实录做Agent这段时间踩过的坑比写过的代码还多这里挑几个最高频的典型问题和排查思路把这些记成一张速查表也许对您的项目更有用。5.1 模型反复调用同一个工具陷入死循环这是Agent开发最经典的问题。模型第一次调用get_schema获得了表结构但工具返回内容太长被截断或者被挤出了上下文模型下一轮可能忘了已经查询过就又调用一次。另一种情况是模型无论如何都觉得自己需要“再确认一次数据库状态”不停重复同一个动作。排查思路第一件事是翻运行日志看每一轮模型输入的上下文里是否已经包含工具返回结果如果包含了但仍然重复调用基本可以断定是模型忘了。对策是把工具返回结果做减重只保留关键字段在Prompt里加一条强制约束“如果已经查询过表结构禁止再次调用get_schema直接使用已有信息除非表结构发生变化”。5.2 工具参数输出格式错乱JSON解析失败模型输出一个不符合JSON Schema的参数是常见错误比如字符串里含了非法的引号、嵌套参数少了一层、把数组写成了逗号分隔的文本。这类错误在参数越复杂越容易发生处理方案分三个层次。第一层写成严格描述不被当成严格约束而是通过工具调用功能让结构尽量标准第二层在代码里做宽松解析解析失败时把报错作为Observation返回给模型让它把参数修正后重新输出第三层给工具参数做简化比如能用平铺参数就不用嵌套结构。实测下来第三层对降低解析失败率的效果最明显——工具描述越简单模型越不容易犯错。5.3 上下文爆炸Token成本居高不下工具返回的大段JSON是全身上下最占Token的位置。一个查询工具把五百行数据原样返回给模型模型用不了那么多但每轮循环都会带着这段巨量内容一起走可能下一轮还需要再调用一次模型成本就会线性叠加。对策是工具结果压缩。在工具层就设置最大返回行数比如只返回前二十条记录并附注总数更精细的做法是把工具返回结果改写成自然语言摘要例如“查询到152条记录上月销量前三的商品为A、B、C”模型看到这句摘要已经足以继续完成任务完全没有必要看到原始表格。这条优化做完Token消耗通常能降一半以上。5.4 评测结果波动太大无法判断改动好坏Agent的随机性来自两处模型采样温度设置和工具返回的不确定性。如果温度设成正数同一个问题跑五次可能得到五个不同路径就分不清Prompt改动到底起了多大作用。处理方式是在评测时固定温度为0甚至直接关闭采样随机性多次运行测试用同一组输入取通过率而不是单次结果来对比。工具返回不稳定时把评测用的测试数据固定成离线快照不让实时变化的数据干扰对比结论。评测的稳定性是整个Agent迭代的基础这一步不做好后面所有“优化”都是踩在沙子上。5.5 Agent开发要避开的几个坑说道实操过程中的坑有几个我每年都在踩值得单独列出来**热词能堆但冷启动不要堆架构。**看到社区里的“主流架构”就急着上多Agent编排、消息队列、向量库很容易把简单场景做成复杂系统。先用单Agent单循环跑通再按性能瓶颈加复杂度。架构复杂度是结果不是原因。**工具不要超过需求所需的数量。**有人喜欢把一堆能用得上的API都接成工具但工具列表越长模型选择难度越大调用出错率越高。工具是重资产宁可少而精也不多而杂。**测试集是Agent项目最值钱的部分。**不需要一上来就做几百条先从每一次线上失败里收集案例攒到几十条就够用了。这些案例是Agent优化的指南针它不能证明Agent永远正确但能证明Agent有没有在持续变好。6. 最后送上的几句个人经验我在多个Agent项目里摸爬滚打出来一个体会Agent这个方向真正决定项目成败的往往不是那些最花哨的技巧而是一些基础工程习惯。您可能也想先跑通一套Demo出来感受一下效果不过我的经验是先评估自己手里的场景是否值得上Agent也很重要——不是所有流程都需要让模型做规划很多固定流程用传统代码更稳更省成本。核心判断标准是“任务是否需要动态决策”有动态决策的需求才轮到Agent发挥价值。如果您刚开始做Agent我的建议很简单选一个足够小的真实场景能用一个主循环加两个工具解决的就不要搭建复杂的架构先跑通再量化评测再逐步优化。每一步都放到评测体系里去验证比凭感觉调Prompt靠谱得多。Agent不是一个魔术盒子它本质上是一个被精心设计的循环系统——设计的颗粒度越细系统就越稳定。