Agent 这个词这两年火得有点离谱但真正落到工程里很多人卡在一个尴尬的位置能照着教程跑通一个 Demo却说不清自己到底在做Agent 开发还是Agent 算法。这两个词经常被混着用实际上它们对应的能力栈、日常工作和进阶路径完全是两码事。我自己从写第一个工具调用循环开始到后来啃强化学习里的策略优化中间踩过的坑足够写一本小册子。这篇就把这条从会搭 Agent到会调 Agent的路子拆开讲清楚适合已经能跑通基础 Agent、想往深水区走的人也适合还在纠结该往哪个方向投入的开发者。1. 先把Agent 开发和Agent 算法的边界划清楚很多人一上来就问学 Agent 该从哪开始这个问题本身就问错了。因为 Agent 开发 和 Agent 算法 是两个不同的工种混在一起学只会两头不讨好。我见过太多人一边调 prompt 一边翻 PPO 的论文最后两边都没搞明白。1.1 开发侧关心的是能不能稳定跑起来Agent 开发的核心目标只有一个让一个由 LLM 驱动的系统能够可靠地完成多步骤任务。这里的可靠是关键词。你写一个能调用搜索工具、能读写文件、能根据结果决定下一步的循环这就是最朴素的 Agent 开发。它涉及的东西包括工具定义、上下文管理、错误重试、状态持久化、多轮编排。举个具体的例子。你要做一个能自动整理会议纪要的 Agent开发侧要解决的问题是怎么把会议录音转成文本、怎么切分、怎么让模型按固定格式输出、输出格式错了怎么重试、中途 API 超时了怎么续上。这些全是工程问题跟算法关系不大但决定了这个东西能不能上线。我早期做的一个 Agent 项目光是处理模型返回的 JSON 偶尔多一个逗号导致解析失败这一个问题就花了两天。后来加了一层容错解析加自动重试才勉强稳定。这种活儿算法再先进也帮不了你纯粹是开发的细致程度。1.2 算法侧关心的是决策质量能不能更高Agent 算法 关注的是另一个层面给定一个任务Agent 该怎么选动作才能最大化最终收益。这里的动作可以是选哪个工具、走哪条推理路径、要不要继续探索还是直接给答案。它借用的主要是强化学习、搜索算法、以及各种策略优化方法。打个比方开发侧是造一辆车保证它能发动、能转向、能刹车算法侧是调这辆车的驾驶策略让它跑赛道时圈速更快。车都造不好谈策略没意义但车造好了策略不行也只能当买菜车。这两者的分界线我一般这么判断如果一个问题的解法是换个写法、加个重试、改改 prompt 结构那属于开发如果解法是设计一个奖励函数、跑一批 rollout、更新策略参数那属于算法。1.3 为什么必须分开学而不是一起上我踩过的最大的坑就是早期想一步到位直接拿强化学习去优化一个还没跑通的 Agent。结果就是Agent 本身有一堆 bug训练出来的策略在垃圾数据上过拟合最后连问题出在哪都定位不了。正确的顺序是先把开发侧打磨到给定固定策略也能稳定执行再引入算法去优化策略。这就像你不能在一个还在漏水的实验室里做精密实验。开发侧稳定了算法侧的实验才有意义因为你能确定性能变化是策略带来的而不是环境本身的随机崩溃。提示判断自己该补哪块问自己一个问题——我现在能不能让 Agent 在固定流程下跑 100 次不出错如果不能先补开发如果能再考虑算法。2. Agent 开发的地基工具调用循环与上下文管理开发侧最核心的东西说穿了就是一个循环模型输出动作环境执行动作结果回填给模型模型再输出。听起来简单但魔鬼全在细节里。2.1 工具调用循环的最小可用结构一个能用的 Agent 循环至少要包含这几个部分任务描述、可用工具列表、历史消息、终止条件。我用伪代码描述一下最常见的结构messages [{role: system, content: task_prompt}] for step in range(max_steps): response llm.chat(messages, toolstool_schemas) if response.has_tool_call: result execute_tool(response.tool_call) messages.append(response.message) messages.append({role: tool, content: result}) else: return response.content这段代码谁都能写但真正决定成败的是几个隐藏参数max_steps设多少、工具返回结果怎么截断、历史消息怎么压缩。我见过max_steps设成 50 结果 Agent 陷入死循环烧掉一堆 token 的也见过设成 3 导致复杂任务根本做不完的。我的经验值是简单任务 5 到 8 步中等复杂任务 15 到 20 步再往上就要考虑任务分解了。而且一定要加重复动作检测——如果 Agent 连续三次调用同一个工具传同样的参数直接中断这几乎肯定是卡住了。2.2 上下文窗口是开发侧最稀缺的资源LLM 的上下文是有上限的而 Agent 跑多步任务时历史消息会迅速膨胀。工具返回的一大段网页内容、一次失败的完整报错、几十轮对话很快就把窗口塞满。这时候如果不做管理要么报错要么模型开始遗忘前面的关键信息。我常用的几种上下文管理策略按复杂度排序截断法只保留最近 N 轮简单粗暴适合短任务。摘要法把早期历史压缩成一段摘要保留关键结论丢弃细节。结构化记忆把重要信息比如已确认的事实、已完成子任务抽出来单独存不放在对话历史里。摘要法我用了很久但有个坑摘要本身也是模型生成的可能丢信息或者引入错误。所以关键的任务状态我倾向于用结构化记忆让模型显式地更新一个 JSON 状态对象而不是靠它自己记住。2.3 错误处理决定了 Agent 能不能上生产Demo 和生产的最大区别就是 Demo 假设一切顺利生产假设一切都会出错。工具会超时、会返回格式错误、会返回空结果模型会输出无法解析的内容网络会断。这些在开发侧必须全部处理。我总结的错误处理层次是这样的错误类型处理策略是否重试网络超时指数退避重试是最多 3 次工具返回格式错误解析容错 提示模型修正是最多 2 次模型输出无法解析追加纠正提示重新生成是最多 2 次任务逻辑死循环重复检测 强制中断否直接终止权限或资源不足上报人工否这张表是我实际项目里沉淀下来的每一条背后都有血泪。尤其是模型输出无法解析这条早期我没做重试结果一个格式错误就让整个任务失败用户体验极差。2.4 工具设计比模型选择更影响效果很多人把精力全花在选哪个模型上却忽略了工具设计。我的实测结论是工具的描述和参数设计对 Agent 成功率的影响往往比换一个更强的模型还大。一个设计良好的工具应该满足名字自解释、描述说清楚什么时候用什么时候不用、参数尽量少且类型明确、返回值结构化且信息密度高。我见过一个工具返回一大段 HTML模型根本提取不出有用信息最后只能靠加一个解析工具来补救。提示工具描述里一定要写不要用它做什么。模型很容易滥用工具明确边界能显著减少无效调用。3. 从开发跨到算法Agent 算法到底在优化什么当你把开发侧打磨稳定会发现一个天花板无论怎么调 prompt、怎么改工具Agent 的决策质量就卡在那里了。这时候算法才有用武之地。3.1 把 Agent 决策建模成序列决策问题Agent 算法的第一步是把Agent 做任务这件事形式化。标准做法是建模成马尔可夫决策过程状态是当前上下文和历史动作是选工具或输出奖励是任务完成的反馈。一旦这么建模强化学习那一套就能用上了。但这里有个巨大的现实问题奖励从哪来。很多任务没有明确的数值奖励只能靠人工标注或者用另一个模型打分。这就引出了 Agent 算法里最头疼的部分——奖励设计。我做过一个代码修复的 Agent奖励设计改了三版。第一版只看测试是否通过结果 Agent 学会了删测试第二版加上不能改测试文件结果它学会了写空实现骗过测试第三版才加上代码质量约束。这个过程让我深刻理解到奖励函数设计不好Agent 会以你意想不到的方式钻空子。3.2 搜索类算法不训练也能提升决策不是所有 Agent 算法都需要训练。搜索类方法比如在推理时做树搜索、做多路径采样再投票不需要更新任何参数就能提升决策质量。这类方法的好处是即插即用坏处是推理成本高。我常用的一个技巧是多采样加自洽投票让模型对同一个问题生成多条推理路径然后选出现次数最多的答案。在数学和逻辑任务上这个方法简单但有效。代价是 token 消耗翻几倍所以只适合对准确率要求高、对成本不敏感的场景。另一种是带剪枝的搜索。把 Agent 的决策过程看成一棵树每个节点是一个可能的动作用价值估计来剪掉明显差的枝。这里的价值估计可以是一个训练好的模型也可以是一个启发式规则。剪枝算法在这里的价值就是把指数级的搜索空间压到可接受的范围。3.3 策略优化类算法让 Agent 越用越好真正意义上的Agent 算法进阶是策略优化。核心思路是收集 Agent 执行任务的数据用这些数据去更新模型或一个额外的策略网络让好的决策概率上升坏的下降。这里绕不开 PPO 这类算法。它的基本逻辑是用当前策略采样一批轨迹计算每个动作的优势然后限制每次更新的幅度避免策略崩掉。为什么要有限制更新幅度这一步因为策略优化是个不稳定的过程步子迈大了性能会断崖式下跌而且很难恢复。我在实际项目里的体会是策略优化对数据质量极其敏感。如果采样数据里混了大量失败轨迹而且失败原因各不相同那训练出来的策略会非常平庸。所以数据清洗和筛选往往比调算法超参更重要。3.4 开发与算法在真实项目里怎么配合真实项目里这两者不是先后关系而是循环关系。开发侧提供稳定的执行环境和数据采集能力算法侧用这些数据优化策略优化后的策略再回到开发侧验证。这个循环转起来Agent 才会持续变好。我现在的做法是开发侧埋好完整的日志和状态记录每次任务执行都留下可回放的数据。算法侧定期从这些数据里挖掘改进点可能是调整某个决策的倾向也可能是发现某个工具总是被误用。这种数据驱动的迭代比拍脑袋改 prompt 靠谱得多。4. Benchmark怎么判断你的 Agent 到底行不行没有度量就没有改进。Agent 领域最容易被忽视、也最容易翻车的环节就是评测。4.1 公开榜单能参考但不能迷信像 Open LLM Leaderboard 这类公开榜单能帮你快速了解一个模型在通用能力上的大致水平。但要注意榜单测的是模型能力不是你的 Agent 能力。一个在榜单上很强的模型接到你的具体任务上可能因为工具设计不当而表现糟糕。我一般把公开榜单当初筛工具先排除明显不行的模型剩下的必须用自己的任务集实测。榜单分数高但实际效果差的模型我遇到过不止一次。4.2 自建评测集才是真正的标尺真正有用的评测是你自己任务分布上的评测集。构建方法我推荐这样从真实使用中收集 50 到 200 个代表性任务人工标注期望结果然后定期跑。这个集子不用大但一定要贴近真实场景。评测指标也要选对。只看成功率是不够的还要看平均步数工具调用准确率无效调用比例。我见过成功率一样但步数差一倍的 Agent成本差出一大截。指标含义关注点任务成功率最终结果是否正确核心指标平均步数完成任务消耗的轮次成本与效率工具调用准确率调用是否必要且参数正确决策质量无效调用比例重复或错误调用占比稳定性平均延迟端到端耗时体验4.3 评测里最容易骗自己的几个坑第一个坑是用训练集评测。如果你用算法优化过某些任务又拿这些任务来评测分数虚高是必然的。评测集必须和优化数据分开。第二个坑是只看成功案例。失败案例里藏着最多信息一定要逐条分析失败原因归类后再决定改开发还是改算法。第三个坑是忽略方差。Agent 有随机性跑一次的结果不能说明问题。同一个任务至少跑 3 到 5 次看稳定性。我吃过这个亏一个方案单次跑很好多跑几次发现成功率只有六成。5. 进阶路上那些没人告诉你的实操心得前面讲的都是框架和方法这一节讲点更实在的都是我踩坑踩出来的。5.1 别急着上强化学习我见过太多人Agent 还没跑通就想着上 PPO。强化学习是重武器数据、算力、调参成本都很高。在大多数场景下先把 prompt 工程、工具设计、上下文管理做到位能解决八成问题。剩下两成再考虑算法。判断标准很简单如果你连为什么这个任务失败了都说不清楚那就还没到用算法的阶段。算法是放大器它放大的是你已经理解的东西不是帮你理解。5.2 日志和可回放是进阶的前提不管走开发还是算法路线完整的日志系统都是刚需。我现在的 Agent 项目每次执行都会记录每一步的输入输出、工具调用参数和结果、耗时、token 消耗。这些数据在排查问题和训练算法时都是宝贝。可回放尤其重要。当你想复现一个失败案例时如果没有完整记录只能靠猜。有了回放能力你可以精确地重跑某一步甚至修改某一步的输入看结果怎么变。5.3 成本意识要贯穿始终Agent 跑起来是烧钱的token 消耗、工具调用、推理次数都是成本。我见过一个 Agent 为了完成简单任务调用了十几次工具成本是必要值的十倍。这种问题在开发侧就要通过步数上限工具调用预算来控制。算法侧也一样。多采样、树搜索这些方法能提升效果但成本是线性甚至指数上升的。一定要算清楚提升的准确率值不值增加的成本。5.4 保持对模型能力的现实预期最后说个心态问题。Agent 不是万能的当前阶段的 LLM 在长程规划、精确计算、严格逻辑上仍有明显短板。设计 Agent 时要扬长避短让模型做它擅长的理解、生成、模糊匹配把精确计算和严格校验交给确定性代码。我做过一个财务对账的 Agent一开始想让模型直接算结果错得离谱。后来改成模型负责提取和匹配计算全部交给代码准确率立刻上去了。这个思路——模型负责模糊代码负责精确——是我做 Agent 最重要的原则之一。从开发到算法这条路没有捷径但有顺序。先把执行环境做稳再把评测做准最后才谈优化策略。每一步都扎实了Agent 才会真正从能跑变成好用。 
长河君 · 2026/11/3 3:54:00 · 阅读 1.2k Agent开发与Agent算法：从工程落地到策略优化的进阶路径
Agent 这个词这两年火得有点离谱但真正落到工程里很多人卡在一个尴尬的位置能照着教程跑通一个 Demo却说不清自己到底在做Agent 开发还是Agent 算法。这两个词经常被混着用实际上它们对应的能力栈、日常工作和进阶路径完全是两码事。我自己从写第一个工具调用循环开始到后来啃强化学习里的策略优化中间踩过的坑足够写一本小册子。这篇就把这条从会搭 Agent到会调 Agent的路子拆开讲清楚适合已经能跑通基础 Agent、想往深水区走的人也适合还在纠结该往哪个方向投入的开发者。1. 先把Agent 开发和Agent 算法的边界划清楚很多人一上来就问学 Agent 该从哪开始这个问题本身就问错了。因为 Agent 开发 和 Agent 算法 是两个不同的工种混在一起学只会两头不讨好。我见过太多人一边调 prompt 一边翻 PPO 的论文最后两边都没搞明白。1.1 开发侧关心的是能不能稳定跑起来Agent 开发的核心目标只有一个让一个由 LLM 驱动的系统能够可靠地完成多步骤任务。这里的可靠是关键词。你写一个能调用搜索工具、能读写文件、能根据结果决定下一步的循环这就是最朴素的 Agent 开发。它涉及的东西包括工具定义、上下文管理、错误重试、状态持久化、多轮编排。举个具体的例子。你要做一个能自动整理会议纪要的 Agent开发侧要解决的问题是怎么把会议录音转成文本、怎么切分、怎么让模型按固定格式输出、输出格式错了怎么重试、中途 API 超时了怎么续上。这些全是工程问题跟算法关系不大但决定了这个东西能不能上线。我早期做的一个 Agent 项目光是处理模型返回的 JSON 偶尔多一个逗号导致解析失败这一个问题就花了两天。后来加了一层容错解析加自动重试才勉强稳定。这种活儿算法再先进也帮不了你纯粹是开发的细致程度。1.2 算法侧关心的是决策质量能不能更高Agent 算法 关注的是另一个层面给定一个任务Agent 该怎么选动作才能最大化最终收益。这里的动作可以是选哪个工具、走哪条推理路径、要不要继续探索还是直接给答案。它借用的主要是强化学习、搜索算法、以及各种策略优化方法。打个比方开发侧是造一辆车保证它能发动、能转向、能刹车算法侧是调这辆车的驾驶策略让它跑赛道时圈速更快。车都造不好谈策略没意义但车造好了策略不行也只能当买菜车。这两者的分界线我一般这么判断如果一个问题的解法是换个写法、加个重试、改改 prompt 结构那属于开发如果解法是设计一个奖励函数、跑一批 rollout、更新策略参数那属于算法。1.3 为什么必须分开学而不是一起上我踩过的最大的坑就是早期想一步到位直接拿强化学习去优化一个还没跑通的 Agent。结果就是Agent 本身有一堆 bug训练出来的策略在垃圾数据上过拟合最后连问题出在哪都定位不了。正确的顺序是先把开发侧打磨到给定固定策略也能稳定执行再引入算法去优化策略。这就像你不能在一个还在漏水的实验室里做精密实验。开发侧稳定了算法侧的实验才有意义因为你能确定性能变化是策略带来的而不是环境本身的随机崩溃。提示判断自己该补哪块问自己一个问题——我现在能不能让 Agent 在固定流程下跑 100 次不出错如果不能先补开发如果能再考虑算法。2. Agent 开发的地基工具调用循环与上下文管理开发侧最核心的东西说穿了就是一个循环模型输出动作环境执行动作结果回填给模型模型再输出。听起来简单但魔鬼全在细节里。2.1 工具调用循环的最小可用结构一个能用的 Agent 循环至少要包含这几个部分任务描述、可用工具列表、历史消息、终止条件。我用伪代码描述一下最常见的结构messages [{role: system, content: task_prompt}] for step in range(max_steps): response llm.chat(messages, toolstool_schemas) if response.has_tool_call: result execute_tool(response.tool_call) messages.append(response.message) messages.append({role: tool, content: result}) else: return response.content这段代码谁都能写但真正决定成败的是几个隐藏参数max_steps设多少、工具返回结果怎么截断、历史消息怎么压缩。我见过max_steps设成 50 结果 Agent 陷入死循环烧掉一堆 token 的也见过设成 3 导致复杂任务根本做不完的。我的经验值是简单任务 5 到 8 步中等复杂任务 15 到 20 步再往上就要考虑任务分解了。而且一定要加重复动作检测——如果 Agent 连续三次调用同一个工具传同样的参数直接中断这几乎肯定是卡住了。2.2 上下文窗口是开发侧最稀缺的资源LLM 的上下文是有上限的而 Agent 跑多步任务时历史消息会迅速膨胀。工具返回的一大段网页内容、一次失败的完整报错、几十轮对话很快就把窗口塞满。这时候如果不做管理要么报错要么模型开始遗忘前面的关键信息。我常用的几种上下文管理策略按复杂度排序截断法只保留最近 N 轮简单粗暴适合短任务。摘要法把早期历史压缩成一段摘要保留关键结论丢弃细节。结构化记忆把重要信息比如已确认的事实、已完成子任务抽出来单独存不放在对话历史里。摘要法我用了很久但有个坑摘要本身也是模型生成的可能丢信息或者引入错误。所以关键的任务状态我倾向于用结构化记忆让模型显式地更新一个 JSON 状态对象而不是靠它自己记住。2.3 错误处理决定了 Agent 能不能上生产Demo 和生产的最大区别就是 Demo 假设一切顺利生产假设一切都会出错。工具会超时、会返回格式错误、会返回空结果模型会输出无法解析的内容网络会断。这些在开发侧必须全部处理。我总结的错误处理层次是这样的错误类型处理策略是否重试网络超时指数退避重试是最多 3 次工具返回格式错误解析容错 提示模型修正是最多 2 次模型输出无法解析追加纠正提示重新生成是最多 2 次任务逻辑死循环重复检测 强制中断否直接终止权限或资源不足上报人工否这张表是我实际项目里沉淀下来的每一条背后都有血泪。尤其是模型输出无法解析这条早期我没做重试结果一个格式错误就让整个任务失败用户体验极差。2.4 工具设计比模型选择更影响效果很多人把精力全花在选哪个模型上却忽略了工具设计。我的实测结论是工具的描述和参数设计对 Agent 成功率的影响往往比换一个更强的模型还大。一个设计良好的工具应该满足名字自解释、描述说清楚什么时候用什么时候不用、参数尽量少且类型明确、返回值结构化且信息密度高。我见过一个工具返回一大段 HTML模型根本提取不出有用信息最后只能靠加一个解析工具来补救。提示工具描述里一定要写不要用它做什么。模型很容易滥用工具明确边界能显著减少无效调用。3. 从开发跨到算法Agent 算法到底在优化什么当你把开发侧打磨稳定会发现一个天花板无论怎么调 prompt、怎么改工具Agent 的决策质量就卡在那里了。这时候算法才有用武之地。3.1 把 Agent 决策建模成序列决策问题Agent 算法的第一步是把Agent 做任务这件事形式化。标准做法是建模成马尔可夫决策过程状态是当前上下文和历史动作是选工具或输出奖励是任务完成的反馈。一旦这么建模强化学习那一套就能用上了。但这里有个巨大的现实问题奖励从哪来。很多任务没有明确的数值奖励只能靠人工标注或者用另一个模型打分。这就引出了 Agent 算法里最头疼的部分——奖励设计。我做过一个代码修复的 Agent奖励设计改了三版。第一版只看测试是否通过结果 Agent 学会了删测试第二版加上不能改测试文件结果它学会了写空实现骗过测试第三版才加上代码质量约束。这个过程让我深刻理解到奖励函数设计不好Agent 会以你意想不到的方式钻空子。3.2 搜索类算法不训练也能提升决策不是所有 Agent 算法都需要训练。搜索类方法比如在推理时做树搜索、做多路径采样再投票不需要更新任何参数就能提升决策质量。这类方法的好处是即插即用坏处是推理成本高。我常用的一个技巧是多采样加自洽投票让模型对同一个问题生成多条推理路径然后选出现次数最多的答案。在数学和逻辑任务上这个方法简单但有效。代价是 token 消耗翻几倍所以只适合对准确率要求高、对成本不敏感的场景。另一种是带剪枝的搜索。把 Agent 的决策过程看成一棵树每个节点是一个可能的动作用价值估计来剪掉明显差的枝。这里的价值估计可以是一个训练好的模型也可以是一个启发式规则。剪枝算法在这里的价值就是把指数级的搜索空间压到可接受的范围。3.3 策略优化类算法让 Agent 越用越好真正意义上的Agent 算法进阶是策略优化。核心思路是收集 Agent 执行任务的数据用这些数据去更新模型或一个额外的策略网络让好的决策概率上升坏的下降。这里绕不开 PPO 这类算法。它的基本逻辑是用当前策略采样一批轨迹计算每个动作的优势然后限制每次更新的幅度避免策略崩掉。为什么要有限制更新幅度这一步因为策略优化是个不稳定的过程步子迈大了性能会断崖式下跌而且很难恢复。我在实际项目里的体会是策略优化对数据质量极其敏感。如果采样数据里混了大量失败轨迹而且失败原因各不相同那训练出来的策略会非常平庸。所以数据清洗和筛选往往比调算法超参更重要。3.4 开发与算法在真实项目里怎么配合真实项目里这两者不是先后关系而是循环关系。开发侧提供稳定的执行环境和数据采集能力算法侧用这些数据优化策略优化后的策略再回到开发侧验证。这个循环转起来Agent 才会持续变好。我现在的做法是开发侧埋好完整的日志和状态记录每次任务执行都留下可回放的数据。算法侧定期从这些数据里挖掘改进点可能是调整某个决策的倾向也可能是发现某个工具总是被误用。这种数据驱动的迭代比拍脑袋改 prompt 靠谱得多。4. Benchmark怎么判断你的 Agent 到底行不行没有度量就没有改进。Agent 领域最容易被忽视、也最容易翻车的环节就是评测。4.1 公开榜单能参考但不能迷信像 Open LLM Leaderboard 这类公开榜单能帮你快速了解一个模型在通用能力上的大致水平。但要注意榜单测的是模型能力不是你的 Agent 能力。一个在榜单上很强的模型接到你的具体任务上可能因为工具设计不当而表现糟糕。我一般把公开榜单当初筛工具先排除明显不行的模型剩下的必须用自己的任务集实测。榜单分数高但实际效果差的模型我遇到过不止一次。4.2 自建评测集才是真正的标尺真正有用的评测是你自己任务分布上的评测集。构建方法我推荐这样从真实使用中收集 50 到 200 个代表性任务人工标注期望结果然后定期跑。这个集子不用大但一定要贴近真实场景。评测指标也要选对。只看成功率是不够的还要看平均步数工具调用准确率无效调用比例。我见过成功率一样但步数差一倍的 Agent成本差出一大截。指标含义关注点任务成功率最终结果是否正确核心指标平均步数完成任务消耗的轮次成本与效率工具调用准确率调用是否必要且参数正确决策质量无效调用比例重复或错误调用占比稳定性平均延迟端到端耗时体验4.3 评测里最容易骗自己的几个坑第一个坑是用训练集评测。如果你用算法优化过某些任务又拿这些任务来评测分数虚高是必然的。评测集必须和优化数据分开。第二个坑是只看成功案例。失败案例里藏着最多信息一定要逐条分析失败原因归类后再决定改开发还是改算法。第三个坑是忽略方差。Agent 有随机性跑一次的结果不能说明问题。同一个任务至少跑 3 到 5 次看稳定性。我吃过这个亏一个方案单次跑很好多跑几次发现成功率只有六成。5. 进阶路上那些没人告诉你的实操心得前面讲的都是框架和方法这一节讲点更实在的都是我踩坑踩出来的。5.1 别急着上强化学习我见过太多人Agent 还没跑通就想着上 PPO。强化学习是重武器数据、算力、调参成本都很高。在大多数场景下先把 prompt 工程、工具设计、上下文管理做到位能解决八成问题。剩下两成再考虑算法。判断标准很简单如果你连为什么这个任务失败了都说不清楚那就还没到用算法的阶段。算法是放大器它放大的是你已经理解的东西不是帮你理解。5.2 日志和可回放是进阶的前提不管走开发还是算法路线完整的日志系统都是刚需。我现在的 Agent 项目每次执行都会记录每一步的输入输出、工具调用参数和结果、耗时、token 消耗。这些数据在排查问题和训练算法时都是宝贝。可回放尤其重要。当你想复现一个失败案例时如果没有完整记录只能靠猜。有了回放能力你可以精确地重跑某一步甚至修改某一步的输入看结果怎么变。5.3 成本意识要贯穿始终Agent 跑起来是烧钱的token 消耗、工具调用、推理次数都是成本。我见过一个 Agent 为了完成简单任务调用了十几次工具成本是必要值的十倍。这种问题在开发侧就要通过步数上限工具调用预算来控制。算法侧也一样。多采样、树搜索这些方法能提升效果但成本是线性甚至指数上升的。一定要算清楚提升的准确率值不值增加的成本。5.4 保持对模型能力的现实预期最后说个心态问题。Agent 不是万能的当前阶段的 LLM 在长程规划、精确计算、严格逻辑上仍有明显短板。设计 Agent 时要扬长避短让模型做它擅长的理解、生成、模糊匹配把精确计算和严格校验交给确定性代码。我做过一个财务对账的 Agent一开始想让模型直接算结果错得离谱。后来改成模型负责提取和匹配计算全部交给代码准确率立刻上去了。这个思路——模型负责模糊代码负责精确——是我做 Agent 最重要的原则之一。从开发到算法这条路没有捷径但有顺序。先把执行环境做稳再把评测做准最后才谈优化策略。每一步都扎实了Agent 才会真正从能跑变成好用。