最近在技术社群里聊 Agent 落地成本绕不开的话题几乎都是 token。上下文窗口不够用、推理账单一路上涨、日志里每一轮都躺着好长一段 usage 字段……多数人觉得能把 token 管住Agent 项目就成功了一半。可真正把 Agent 放进业务链路里跑过几轮之后我的体感完全变了Agent 真正难管的可能不是 token。同样的输入两次输出不一样一个工具调完关键字段丢了上一个节点的决策把后面十几步全带偏出问题后你还说不清到底是哪一步开始错的。这些才是每天都在消耗心智的地方。这篇文章不打算讨论怎么“省 token”而是想分享我在这类项目里踩过的坑以及最后总结出的一套“管 Agent”的实际思路。适合正在做 Agent 落地的开发者、对大模型应用选型犹豫的技术负责人也适合那些已经被上下文长度折腾得怀疑人生、想换个角度思考问题的人。1. 为什么 token 问题先被盯上但它只是个表象1.1 计费透明所以天然容易背锅现在的 AI 服务大多按 token 计费账单上白纸黑字写着每次调用的消耗量。技术负责人一看成本报表第一反应就是把 token 数字压下来。这个逻辑没有错但问题在于token 是一个“显性指标”而 Agent 真正的问题往往藏在一连串隐性指标下面。我见过一个项目为了让 Agent 一次处理完半年的合同文本团队拼命调大上下文窗口最后账单涨了三倍准确率反而下降了。后来排查发现模型在长上下文中迷失了重点把几份不相关的历史条款当成了当前合同的依据。这里 token 确实变多了但根因不是“上下文不够长”而是“该关注的字段没有在合适的位置被强调”。1.2 上下文窗口是个显性边界容易让人误判上下文窗口就像电脑内存条不够用的时候问题很明确直接报错、截断、或者丢信息。这种故障是“可见的”很自然会被归为第一优先级。可一旦你把窗口加大模型不报错了新的隐性故障反而开始出现——它开始“选择性遗忘”早期信息或者面对大量噪声输出模棱两可的答案。这时候你不会再把问题归到“上下文不够长”上因为窗口明明是足够的。你会开始怀疑模型能力不行、Prompt 写得不行、工具定义有问题。实际上问题出在你把一个“资源约束”误当成了“管理问题”。资源约束可以靠加钱解决管理问题只能靠架构和流程解决。1.3 token 解决的是“装得下”不是“用得对”我把一个很长的业务说明全部塞进上下文里模型确实能“看到”所有信息但这不代表它会在合适的时机“调用”正确信息。大语言模型的注意力机制本身就是有偏的内容越长关键信息被稀释得越厉害。你可以把 token 当成仓库容量但仓库满了不代表货物的编号清楚、取货路径最优。在 Agent 场景里这个问题会加倍放大。因为 Agent 往往要跑很多步每一步都会把之前的中间结果拼回上下文。如果你只是无脑扩大窗口最终上下文里堆满了旧步骤的噪声模型做下一步决策时被噪声带偏的概率远大于借助长上下文做出更优判断的概率。后来我养成一个习惯先看每一步模型“实际参考了哪些信息”而不是先看整个 Agent 用了多少 token。2. 真正难管的行为漂移、状态失控和工具契约2.1 同一套输入Agent 的“可复现性”差得离谱传统软件开发里代码确定性是默认的同一份输入跑一百次结果也是一样的。Agent 完全不是这样。模型采样有随机性同样 Prompt 的温度设成 0也可能因为内部并行、远端版本更新等原因输出不同。如果在 Agent 里每一步都叠加这种随机性最终输出的偏差会指数级放大。我在一个信息抽取任务里做过测试拿同样 20 份测试文本跑 5 轮最终结果的字段完全一致的只有 12 份剩下的要么漏了字段要么提取了错误值。最麻烦的是每次漏的字段还不一样。这种情况你没法用“改一个 Bug”来修复因为根因是随机的、分散的。后来我只能把“字段缺失”当作预期情况在后续流程里重新校验和补全。2.2 多步 Agent 的状态管理比你想的更容易“串线”单次 Prompt 调用不存在状态管理问题模型看到什么就是什么。但 Agent 是要多步决策的每一步都需要基于前几步的结果。很多人把历史的对话记录直接拼回上下文事情就开始失控了。最经典的场景是Agent 第一步提取了“甲方是 A 公司”第二步在处理条款时模型又从其他上下文里推断“甲方是 B 公司”然后后面所有校验都基于 B 公司进行。你翻日志会发现每一步单独看都挺合理但连起来就是错的。这就是典型的“隐式状态扰动”——模型从长上下文中找信息时没有稳定的状态访问机制。这里的难点不是“上下文不够”而是“状态没有显式化”。对话历史是隐式状态模型对它的记忆是概率性的你要真正管住 Agent就必须把它变成显式状态对象每一步都明确写入和读取并且对关键字段加“锁”防止被后续步骤改写。2.3 工具调用的“参数幻觉”比输出格式错误更隐蔽Agent 和普通聊天最大的区别是它能调用工具。工具调用要严格按照接口 schema 来但模型天生爱“自由发挥”。我见过模型把日期格式从YYYY-MM-DD传成2024年5月1日也见过它给一个只需要经纬度的工具传了城市名称。你用严格 schema 校验错误是能被拦住的但更隐蔽的是它会在参数里“编造”一个看起来合理、实际不存在的信息。举个例子模型要调用一个“查询客户等级”的工具接口只需要一个customer_id。模型没有在上下文里找到这个 ID但它没有报“找不到”而是自己生成了一个类似格式的 ID 传进去。工具查不到数据返回空结果模型就当“该客户无记录”继续往下写。这种错误不会触发任何异常但它直接污染了业务结论。要管住这个问题不能只靠提示词。我后来在工具层加了一道“参数合法性预检”对枚举值、格式、存在性做校验校验不通过就返回给模型一个明确错误要求它重新从上下文中提取。同时把“找不到必要参数”设计成一种合法的 Agent 行为它是“信息不足”而不是“空结果”。2.4 规划与执行经常“两张皮”计划越漂亮越容易翻车很多 Agent 框架喜欢让模型先写一个 Plan然后按 Plan 一步步执行。听起来很合理但实际跑起来“计划”和“执行”经常是脱节的。模型写计划时参考的是初始信息执行到第四步时它掌握的信息已经变了可它又不会主动去更新最初的计划。结果就是Agent 还在执行一个过时的方案中间步骤的决策和计划里的目标已经对不上了。我把它叫作“规划漂移”。最常出现在长任务里比如一个需要 8 步才能完成的调研任务跑到第 5 步时模型发现了一个新的方向然后它“擅自”在原来的计划里插入新步骤但又不清理旧步骤。最后你看到的轨迹既不是最初计划也不是一个新计划而是一团互相矛盾的中间产物。这种问题靠调 Prompt 很难根治。我最后的选择是把计划本身也当成一个显式对象在执行每一步之前先校验“当前步骤是否和计划一致、计划是否需要更新”并且对计划的修改必须经过一个独立步骤不能由模型在执行节点里顺手改了。本质上就是把“决策”和“执行”分开管理。3. 实操我是怎么定位“隐藏难点”而不是纠结 token 的3.1 构造一个最小 Agent 压测任务为了讲清这个过程我用一个模拟场景来说某跨平台系统要做一个“合同关键信息抽取 条款冲突检查”的 Agent。输入是几份合同文本输出是一个结构化报告包含签约主体、金额、期限、违约责任以及冲突条款清单。我先没有急着写完整流程而是搭了一个最小闭环模型先抽取字段再调用一个“校验工具”去检查两份合同是否冲突。整个链路只有 5 个节点。为了让问题暴露我故意把不同合同的文本格式打乱有的带标题有的纯正文有的金额用大写。然后我写了一个简单的压测脚本每条输入跑 10 次记录每一步的原始输出、工具调用参数、最终结果。这里有一条很重要的经验不要只看最终结果一定要给每个节点打点否则你根本不知道问题来自哪一步。3.2 用错误分类表统计数据而不是靠感觉跑完 50 条测试数据后我把所有失败情况手工归类列了这样一张表失败现象出现次数根因类型字段遗漏主体或金额没抽出来14信息提取不稳定工具调用参数错误12参数幻觉前后两步的关键信息不一致9状态串线输出格式无法被下游解析6格式漂移上下文超限被截断2token 资源问题有意思的是真正和 token 相关的失败只占 2 次。大部分错误分布在信息提取的不稳定、工具参数幻觉、状态串线上。这让我更确信Agent 的瓶颈不在“容量”而在“行为质量”。错误分类表最大的价值是让我不再凭直觉优化。以前遇到问题我会第一时间调 Prompt然后跑一遍觉得“看起来好了”其实根本没统计过失败率。现在我会把每个失败案例固化成一个回归用例每次改动后跑一遍看分布有没有变化。3.3 一个典型的“状态覆盖”Bug 实录压测中有一个案例印象特别深。任务是抽取 A 合同和 B 合同的甲方然后提醒是否同一主体。Agent 第一轮正确抽出了 A 合同的甲方是“某技术有限公司”第二轮却把“某技术有限公司”写成了“某科技有限公司”错了一个字。校验工具拿这个错误名字去查查不到记录返回空值Agent 就输出“无法判断是否同一主体”。表面上是“模型把公司名记错了”但继续深挖发现第一轮输出的结果被放回了上下文第二轮模型从对话历史里“重新解码”这个名字时受到了上下文中其他信息的干扰。这就是典型的状态串线。排查方法很笨但有效我在每个节点后面加了一个state_snapshot字段把当前所有关键变量打印出来。对比两轮快照一眼就看到了差异。修复方案也不是改 Prompt而是把“公司名称”这个字段变成了一个显式状态对象用户在第几轮都只从状态对象里读不重新从上下文中推断。相当于给关键字段加了一把锁。这个案例给我最大的启发是Agent 的 bug 不一定在模型能力而在你的状态管理设计。你把状态管住了模型的随机性才不至于演变成系统性错误。3.4 从“省 token”转向“省心智”的配置调整做完这轮压测后我没有去优化 token 用量而是重新设计了一套上下文配置。核心原则是只把当前步骤真正需要的信息放进上下文把已经完成的结果固化成结构化状态而不是把历史原始记录一直堆着。具体做法是每一轮执行前先构造一个“状态摘要”只包含上一步的关键字段和必要的工具返回结果。不把整段历史对话塞回去而是用一个紧凑的结构化对象替代。给每个工具调用加上 schema 校验出错时返回错误码而不是让模型自己瞎猜。定义好任务终止条件当 Agent 拿到核心字段后不再继续尝试“锦上添花”。这个调整下来token 消耗反而下降了 40%。更关键的是最终结果的一致性从原来的 60% 左右提升到了 92%。所以你看盯着 token 优化不一定能提升质量但优化行为质量token 天然就省下来了。4. 把 Agent 管理思维切到“控行为”上而不是“控成本”上4.1 原则一给 Agent 定一份“任务契约”Agent 跑业务不能让它像聊天一样自由发挥。我给每个 Agent 都定义了一份“任务契约”里面写清楚输入是什么能接收哪些字段哪些是必填。输出是什么必须返回什么结构字段枚举和格式。能调用哪些工具每个工具的用途、参数、成功和失败语义。边界是什么遇到缺失信息时应该停止还是继续追问。终止条件是什么达到什么状态就可以结束不允许无限修正。这个契约不是写给人看的而是要落到代码里。输出必须通过结构化校验工具调用必须经过参数预检。模型就像流水线上的工人可以有自己的操作手法但不能脱离工序卡。有了任务契约Agent 的行为就有了“边界感”。你管它的时候不是看它每一步说了什么而是看它有没有违反契约。违反契约的节点会被自动拦截问题也能在最早的地方暴露。4.2 原则二可观测性不是可选项而是基础设施传统程序出错有堆栈、有日志、有调试器。Agent 出错你面对的可能只是一段“看起来合理但结果不对”的推理过程。所以 Agent 项目里的可观测层不能是事后补的。我每个 Agent 节点都会记录四类信息输入摘要这一步模型到底看到了什么。输出结果这一步模型生成了什么。状态快照这一步之后关键变量变成了什么。决策理由如果可能记录模型当时的思考片段。记录这些信息不只是为了排查更是为了“回放”。出了一个问题我可以用同一份输入重新跑一遍对比两次状态快照的差异。没有这些信息我只能靠猜。有了这些信息我至少能定位到是在第几轮、哪个工具调用上开始偏的。4.3 原则三把评估集当代码库一样维护很多人做大模型应用评估集只有零星几个示例每次改动都靠“肉眼看一下”。一旦 Agent 复杂起来这种评估方式根本撑不住。我自己维护了一套大约 200 条的评估集按业务场景分类每一条都包含输入、期望输出、关键校验点。每次改 Prompt、换模型、调工具逻辑都要跑一遍回归。指标不只是“最终准确率”还包括“工具调用成功率”、“状态一致性率”、“重试次数”这些过程指标。只有这些指标一起看才能知道这次改动到底是变好了还是变坏了。有一次我把某个 Prompt 改得更严格最终准确率确实提升了一点但工具调用失败率翻了一倍。如果只看准确率我会以为改动是成功的但看过程指标我发现模型开始频繁“拒答”和“绕弯”。这就是评估集过程指标的价值。4.4 原则四能不用模型的地方就不要用模型Agent 不是环节越智能越好。很多“确定性决策”根本不需要大模型比如字段格式转换、枚举匹配、规则校验用普通代码就够了。模型应该只负责需要语义理解的部分比如判断信息是否完整、归类文本、生成自然语言总结。我在某个项目中把工具调用的前置判断从模型换成了规则引擎原来模型经常在“要不要调用这个工具”上犹豫导致重复重试换成规则后这一块的失败率几乎降到了零。Agent 管理做得好的人都有很强的“克制力”知道哪些环节应该让模型介入哪些环节应该用代码兜底。5. 常见问题与排查技巧实录我在多个 Agent 项目里反复遇到下面这些问题整理成一张速查表便于你在排查时“按图索骥”。现象根因排查思路避坑建议上下文越堆越长输出质量反而下降把过多无关历史塞进上下文模型注意力分散检查每个节点真正需要的信息是什么减少冗余用状态摘要代替原始历史记录同一任务跑多次结果差异很大模型采样随机性 状态未显式固定多次运行对比每一步的状态快照关键字段做“只写一次”处理降低自由度工具调用解析失败模型输出参数不符合 schema打印工具调用原始输出加工具参数预检失败时返回明确错误码计划步骤与实际执行不一致规划与执行分离模型中途“自作主张”在每一步执行前校验计划一致性把计划当显式对象管理改动必须走独立步骤关键实体被替换或遗忘隐式状态受上下文干扰对比各轮状态快照 diff用显式状态对象存储关键实体避免模型重新推断Agent 陷入重复重试循环终止条件不明确或工具错误被当成可恢复问题看日志中同一节点的重复次数设置重试次数上限区分“临时错误”和“确定性错误”总说“没有记录”但业务里明明有工具参数传递错误导致查不到数据检查调用参数是否与接口要求一致参数预检里校验存在性不让模型生成不存在的 ID还有两条经验值得单独说。第一不要让 Agent 自己判断“是否已经完成任务”。模型倾向于在不确定时继续挖掘然后在信息足够时又容易过早收尾。我会在任务契约里写清楚“哪些字段齐了就可以停”甚至用一个独立的规则检查器来控制收尾。第二每一条失败案例都要留档。不要今天发现一个问题修完就忘掉。我在本地维护了一个 failure zoo按场景和根因类别归档定期重新跑一遍检查有没有“复发”。特别是当你更换底层模型版本或者调整 Prompt 模板后老问题复发的概率比想象中要高。这也就是为什么我说Agent 真正难管的不是 token。token 是显性的、可量化的、花钱就能解决的资源问题。真正吃时间、吃精力、吃团队耐心的是上面这些行为层面的事情——状态怎么不漂移、工具怎么不掉链子、计划怎么不跑偏、错误怎么可回放。我自己的体会是把这些问题先解决掉token 成本往往是顺手降下来的。反过来只盯着 token省下的钱还不够填排查行为问题的时间坑。这个思路后续还可以往前再走一步把评估集做成自动化的 CI 门禁每次改动都触发回归跑批把常用的失败模式沉淀成校验规则在 Agent 运行时就实时拦截。这些做扎实之后Agent 才会从一个“看起来会做事但有点随机”的 Demo变成真正敢放进业务链路里的工具。