1. 先说结论token从来不是Agent最难管的东西接手Agent类项目这几年最常被问到的就是“token扛不扛得住”。往往是需求还没聊完就有人掏出估算表跟我说一次任务要烧掉多少token、换算成成本又是多少。我理解这种焦虑但实话说token在所有变量里恰恰是最可控的一个。你可以算、可以设上限、可以拦超限它顶多让你多花钱不至于让系统突然变得不可收拾。真正让我在凌晨三点爬起来查日志的从来不是token账单而是另一类事情。比如Agent跑着跑着把前两步的结论给忘了照着旧数据往下做比如某个工具调用失败之后它不停重试烧掉的token只是表象真正的问题是没人拦住它再比如用户在对话里改了一个关键字段Agent却仍然按之前误解的信息执行。这些故障的共同点是没有人能回答出“它为什么这么做”。所以“Agent真正难管的可能不是token”这句话不是故作姿态而是实操中反复验证过的感受。真正难管的是上下文一致性、状态管理、行为可控性、可观测性。这四件事里任何一件没做好都会让你在调试和上线阶段付出比token成本高得多的代价。token只是症状指标不是病根。这篇内容我会把这四个难管的地方拆开讲再把我在内部项目里用过的方案和踩过的坑一并放出来希望能给你一份可以直接“抄作业”的清单。1.1 为什么我对token焦虑没那么紧张先给一个判断的基准token消耗是有限度的。每次任务调用多少个模型、每个模型接收多少文本、工具返回有多大都能在代码层面统计和封顶。只要设了任务级上限最坏结果就是成本超标被拦下来不会出现“不可控”的系统级事故。相比之下状态错乱和行为偏移才是真的不可控。模型一旦拿着错误状态继续执行它可能把订单下错、把数据删掉、把通知发给不该发的人。这类事故的代价远超token账单恢复起来也更麻烦。所以我做Agent项目时会把成本放在可靠性的后面先把行为逻辑钉住再谈省钱。1.2 真正让我睡不着的四件事展开之前先把四个关键词放这上下文一致性、状态管理与恢复、行为可控性、可观测性。它们分别对应四种事故形态关键信息被淹没、执行到一半崩溃无法续跑、不按流程走甚至死循环、出事后根本查不到原因。后面每一节都会对应一个真实场景和一套解决方案。2. 真正难管的第一个点上下文一致性2.1 你以为它记住了其实它只是在“猜”做完几个Agent项目之后我对“记忆”这个词的态度变得很谨慎。现在的上下文窗口确实越开越大但“信息在上下文里”和“信息真正被模型关注到”是两件截然不同的事。长对话中越早的信息权重会越弱中间某一步如果塞进来一大段工具返回的JSON用户的原始意图很可能会被挤到注意力边缘。我印象很深的一次是一个内部流程Agent。用户第一句话说“我要红色的A商品”Agent中间查了三轮库存和价格最后用户补充一句“还是不要蓝色那款套装了换回之前那个”。结果它下单选了一个蓝色套装——因为最近的对话里蓝色套装的优先级盖过了最开头的红色设定。你说它没有上下文窗口吗窗口肯定放得下。问题在于当大量历史信息堆在同一个窗口里模型能依靠的外部线索就是“最近出现、频率最高”的信息而不是“最关键”的信息。你把它当有记忆的助手它其实是在残缺材料上做高概率猜测。2.2 上下文污染比token超限更隐蔽和“遗忘”同样常见的是“污染”。每一次工具调用、每一条报错信息、每一段冗长的查询结果都会留在上下文里。从token角度看它们只是成本从推理质量角度看它们是噪音。我习惯拿桌面来打比方桌面堆满了垃圾文件你真正要找的那张合同就在最底下模型得翻很久才能翻到翻的过程中还很容易拿错。更麻烦的是矛盾信息。多轮对话里同一个对象会有多种不同描述工具返回值里某个字段的数值和用户刚说的不一致。模型要同时消化这些相互冲突的信息再生成下一步动作出错几乎是必然的。很多团队只盯着token超限的警报却没意识到真正腐蚀Agent能力的是“超限前就已经存在的污染”。2.3 实操手法结构化记忆与显式状态针对上下文问题我现在的做法是尽量别让对话历史承担记忆职责。核心原则一条让持久化的状态成为唯一事实源而不是让模型从对话里“回忆”。具体分四步。第一步关键信息抽取。每一轮结束时把用户偏好、任务进度、当前结论这些内容抽出来写进提前定义好的结构化字段里。比如“目标商品”“颜色”“数量”“确认状态”各占一个字段而不是散落在一堆对话里。第二步按需组装。每次生成下一步动作时只把当前这一步真正需要的字段拼接进提示词其他不相关的历史不带。第三步历史摘要。更早的对话压缩成几条“阶段结论”放进上下文而不是把原始记录全部堆着。第四步显式状态校验。每个关键步骤过后用一段确定性规则校验当前状态有没有互相矛盾——比如“用户选择的商品”和“工具落单的商品”是否一致。这个校验可以用普通代码写不要交给模型判断。这样做之后至少我自己的项目里那些“明明说过却当作不知道”的诡异问题少了一大半。代价是多写一点胶水代码但换来的是Agent每一步都踩着显式状态前进而不是靠词频猜答案。3. 真正难管的第二个点状态管理与失败恢复3.1 Agent是有状态系统被你当成无状态函数用了很多团队一开始把Agent想成“输入提示词输出结果”的函数调用。用户说一句话模型决定调哪个工具最后返回答案结束。但真实业务任务几乎都是多步的查库存、比价、下单、确认、发送通知。每一步都有副作用有些副作用还会落到外部系统里。这时候Agent就不再是一个无状态函数而是一个有状态的、带有外部影响的任务系统。只要这个认知没建立失败恢复就一定会出问题。最常见的一幕是Agent执行到一半报错你还没法回答“现在到底进行到哪一步了”。哪些副作用已经生效哪些还没做哪些决策已经落定没有任何记录。这种情况下做任何补救都只能靠猜。3.2 “重跑一遍”是最贵也最容易出错的恢复方式我最早期犯过的错就是失败之后“重新跑一遍”。听起来很简单但后果往往很严重。举个例子。某个内部项目里Agent要在确认会议后发送通知邮件。第一次执行时会议预约建好了邮件也发出去了但在最后一步状态更新时报错。于是我们重跑结果第二封邮件发出去了会议室也被重复预约。原因很简单重新执行不是从断点继续而是把整套操作再做一遍。这个场景对Agent尤其危险因为每一次重新规划生成的计划和上一次未必一样你根本不知道它会重复哪些操作、跳过哪些操作。哪怕模型自己说“好的我会重新来”它也没有能力自动判断哪些副作用已经存在。3.3 落地做法状态落盘、幂等设计、检查点要解决这类问题我的做法是把它当分布式系统的状态管理来设计而不是靠提示词。第一状态落盘。每一个任务在数据库里都有一个任务对象记录当前阶段、已完成步骤、待办步骤、关键决策依据。每完成一步就更新一次做到“任何时刻都能回答当前位置”。第二幂等设计。所有会产生副作用的工具都必须接收一个唯一请求号。工具内部记录这个请求号重复的请求号直接返回之前的结果不再重复执行。这样即使Agent因为超时重试也不会产生重复订单、重复邮件、重复扣款。第三检查点。在不可逆操作之前设一个门槛比如支付、删除、发送正式通知必须经过显式确认。这个确认可以是人工审批也可以是用户对话里的一次明确授权但不能让模型自己“觉得没问题就直接执行”。第四失败恢复从检查点续跑。发生故障后读出任务对象定位到最后成功的步骤从那里继续而不是从头重启整个Agent。提示判断一个Agent恢复流程是否合格就看它能否回答“执行到哪一步了、哪些副作用已生效、重放会怎样”这三个问题。3.4 一个印象深刻的故障现场我踩过一个很有代表性的坑。某个订单处理Agent第一次跑到一半崩了状态没落盘。我们重跑之后它创建了两张订单——前一次创建的那张还躺在系统里后一次又建了一张新的。用户看到重复扣款直接炸锅。后来我们把订单创建工具的请求号机制补上又把“创建订单”设为需要人工确认的检查点这类问题基本绝迹。那次之后我有个习惯凡是Agent要对外部系统做写操作第一件事先问“这个操作重放一体会怎样”。4. 真正难管的第三个点行为可控性4.1 计划写得好不代表执行不出格我见过不少Agent在规划阶段表现很好步骤清晰、顺序合理、风险点也识别了。但真正跑起来完全不是那么回事。原因在于执行过程中模型会不断面对新的局部情况它会“灵活地”调整计划而“灵活”和“出格”之间的边界非常模糊。举个最常见的例子。你给Agent定的流程是“先查库存再比价最后下单”。前面两步都正常用户催了一句“能不能快点”模型就直接拿两小时前查过的库存数据下单了。库存早就变了但它认为“用户着急所以要优先满足速度”。你说它恶意吗不是。但它的行为已经从流程边界里滑出去了而标准的prompt很难约束住这种滑出。4.2 死循环和空转本质是行为问题行为失控最典型的表现是死循环。某个工具连续返回错误Agent不换思路而是用同样的参数再调一次再调一次。从token账单上看确实是越烧越多但这笔账要算在“没有行为约束”上不是算在“token太贵”上。我在系统里会加这么几个硬限制最大步数、同一工具的连续调用上限、单次任务超时时间。并且规定当同一个动作重复超过固定次数时Agent必须切换策略或者向用户说明当前卡点。另外如果Agent观察到工具连续失败它必须先把失败原因记录下来再决定是否换一种工具或换一种参数而不是无脑重试。4.3 让Agent“听话”的三层约束要让Agent行为可控不能只靠“提示词多写几句”。我自己的做法是分三层去拦。第一层是工具契约。每个工具都定义严格的入参校验和返回值结构。参数缺失、类型不对、取值非法工具直接拒绝而不是让模型自己“猜一个合理的值”往里填。比如订房工具必须显式接收入住日期缺失就报错不给模型留默认推断的空间。第二层是权限阶梯。默认情况下Agent只拥有只读权限。写操作需要更高级别授权删除、支付、发送通知这类不可逆操作必须经过人工确认。权限不是写死在prompt里的“你最好别做”而是由系统在工具调用层面强制拦截。第三层是监督与审计。每轮执行后有一个独立的轻量校验器检查“实际做了什么”是否和“计划说要做什么”一致。发现偏差就强制重新规划而不是让Agent带着错误继续往下跑。这个校验器可以用规则代码实现也可以用一个小模型做分类不建议让执行Agent自己评价自己。注意权限拦截必须在工具调用层做不能只写在提示词里。提示词里的“你最好不要”仅是建议工具层的拒绝才是强制。4.4 一个订票Agent的教训我手头有个住宿预订Agent出过一次很典型的事故。用户在对话里没有明确说入住日期只说“帮我订一家离会场近的酒店”。结果是Agent直接拿当天的日期去下单了。事后查原因订房工具的接口里入住日期是可选的模型填了一个“当前日期”作为“合理推断”。这个错误本质上不是模型不聪明而是工具契约给了它模棱两可的空间。修复方式也简单日期字段改成必填并在调用前用代码校验“日期不能早于今天”同时增加一条规则如果用户没有明确日期Agent必须反问确认不能默认。这类问题靠提示词优化很难彻底解决因为模型太容易产生“合理但错误”的补全。凡是能用代码验证的就永远不要让模型自己判断。5. 真正难管的第四个点可观测性与调试5.1 没有“为什么”你就不敢上线Agent只要一失控第一个问题肯定是“它当时为什么要这么做”。如果项目里没有记录决策过程这个问题的答案永远是“不知道”。普通日志只记token数量和调用时间对Agent来说几乎没用。你需要的是完整决策轨迹每一轮的系统提示词、用户输入、模型输出、工具请求参数、工具返回结果、状态更新内容全部串在一个追踪标识下。按这个标准去做之后排查效率会高很多。线上出了怪事把对应任务的轨迹拉到本地在隔离环境里重放一遍基本能定位到是哪一个环节的上下文或工具返回把Agent带偏了。很多团队觉得Agent项目没法调试其实不是没法调试而是没有把决策轨迹当作一等公民来记录。5.2 用回归集把Agent“钉”住Agent的外部表现不稳定所以很多团队干脆放弃测试这是更大的坑。我现在的做法是沉淀一个回归集把每一次线上故障和典型用户路径整理成测试场景固定输入记录预期行为。改prompt、改工具、改模型都在这个回归集上先跑一遍。回归集不需要一开始就很大。二三十条覆盖主流程和已知坑位的用例已经能挡掉大部分回归问题。每修一个Bug就对应补一条用例防止同类问题第二次出现。跑回归的方式也不复杂离线重放已记录的输入检查Agent的输出和动作序列是否符合预期。对不稳定的环节还可以人工评估门槛之后再加自动判断。这个习惯坚持下来Agent的“不可控感”会明显下降因为它至少被你用历史故障“钉”住了一部分。5.3 一个原则能用代码解决的就别让模型决定这条原则是从无数次调试里提炼出来的。凡是被证明会稳定出错的地方都存在一个确定性解法。日期校验、权限拦截、幂等键、状态一致性检查、步数上限……这些都是代码能处理的事情处理结果百分之百确定。把这类逻辑交给模型等于把确定的问题变成概率问题。相反真正需要模型决策的场景是那些没有标准答案的判断理解用户意图、生成方案、判断语气、决定信息优先级。这一层才值得把token花上去。把确定性控制点全部回收成代码之后你会发现不仅Agent稳定了token消耗也会跟着降下来。这不是省钱的额外收益而是架构合理的自然结果。6. 实操速查把管理重心从token挪到状态与行为6.1 立项前先回答五个问题我在启动任何一个Agent项目之前都要先过五个问题。第一这个任务有几个稳定状态每一步之间的迁移条件是什么第二哪些操作会对外部系统产生副作用其中哪些不可逆第三每个工具允许做什么、禁止做什么边界定义清楚了吗第四模型决策的边界在哪里哪些环节必须由规则代码接管第五如果任务半路失败从哪里恢复重试会不会重复执行这五个问题任何一个答不上来都说明方案还没到动手写提示词的阶段。先把这些想清楚后面能省很多返工。很多项目的管理复杂度在立项那一刻就决定了而不是在写代码之后才出现的。6.2 三个可以直接用的架构模式第一个模式是状态机模式。把整个任务的阶段定清楚比如“待选品”“待确认”“执行中”“已完成”Agent只能在允许的状态之间迁移跳状态就拦截。状态机能在设计层面消灭大量越权行为。第二个模式是双层控制模式。上面一层是模型负责理解和决策下面一层是规则控制层负责校验工具调用、权限、步数、超时和预算。模型永远不能直接触碰外部系统所有操作都要经过控制层。这个模式和“权限阶梯”配合起来行为可控性会强很多。第三个模式是人工确认回环。凡是有副作用的不可逆操作流程都必须停在一个“等待确认”的节点上。这个节点可以由用户在对话里确认也可以在系统里走人工审批但必须存在。加了这条之后即使模型误判也有一个兜底刹车能避免最严重的后果。6.3 token还是要管但优先级往后放我说token不是最难管的不等于完全不管。成本控制还是要做只是放对位置。我的习惯是按任务设定token上限而不是按单次请求。任务一旦超限终止执行并标记异常而不是默默烧下去。其次能用小模型解决的问题就不要大模型上。意图分类、实体抽取、结果校验这类简单任务小模型完全够用把它和复杂的推理拆开处理成本能降一大截。再次做好提示词缓存稳定的系统提示和工具描述不要在每轮都重复计费。但所有这些优化都应该在行为稳定之后再做。过早的激进压缩上下文很可能省了token却破坏了状态一致性和决策质量最后得不偿失。7. 常见问题与排查速查表7.1 一张表对应四种最典型的故障把前面几类坑汇总成一张速查表方便在现场快速定位现象大概率原因排查入口处理建议Agent重复执行同一操作工具缺少幂等处理失败恢复用整体重跑在决策轨迹里查同一请求号是否重复给写操作加唯一请求号恢复时从检查点续跑Agent同一工具反复失败并重试没有行为约束和步数上限统计连续调用同一工具的频次设置最大步数、连续失败上限、强制换策略Agent漏掉早期用户意图上下文污染或历史信息稀释回放该轮提示词看关键字段是否被淹没结构化记忆只组装当前步骤所需事实Agent不按流程执行跳过必要步骤工具契约过松权限限制不足对比计划和实际工具调用序列严格入参校验权限阶梯计划执行后校验7.2 现场快速定位的一些土办法每次线上出问题我建议按“四步法”来查。第一步把任务的完整决策轨迹拉出来看模型在关键节点到底看到了什么第二步看工具调用序列和计划差在哪里差多大第三步检查是否触发了已知的确定性控制点比如权限拦截、参数校验、幂等重复第四步用离线重放把同样输入跑一遍看问题是不是可复现。可复现的问题通常都能在控制层面修不可复现的问题则往往和上下文里的随机性有关优先考虑收敛上下文和增加约束。这里面还有一个容易被忽略的细节记录模型输出的原始文本别只记录解析后的结构。特别在输出格式不稳定的早期阶段原始输出是判断“是模型理解错了还是你的解析错了”的关键证据。7.3 踩坑后的经验沉淀每次处理完一个线上问题我都会在项目文档里补一条“这类问题下次怎么预防”。例如“所有涉及日期的操作必须显式校验”“所有用户修改过的字段必须在下一次工具调用前重新注入当前状态”“所有不可逆操作前必须有人工确认点”。规则越具体越好一条不落。时间长了这个清单本身就是团队最宝贵的资产。8. 最后分享几个我自己常用的土办法8.1 上线前的“半路杀掉”测试每个Agent上线前我都会做一次“半路杀掉”的测试。把它放到测试环境里在任务跑到某一步时手动中断然后执行恢复流程看它能不能从检查点续跑、会不会重复执行。这一步能暴露大多数状态管理问题。8.2 回归集永远走在修改前面每次改prompt或改模型都要过一遍回归集。哪怕只是调整几个字的措辞也不能直接上生产。Agent行为有随机性不要相信“这次改得很小应该没事”。只有历史用例一致通过我才敢把改动合入。8.3 给工具返回打上数据时间戳给每个工具的返回结果打上数据时间戳。这个看起来很小但能让模型知道“哪条数据是新的哪条已经过期”能避免很多用旧数据下决策的问题。实现成本极低收益却很直接。8.4 把token超限当设计警报把token超限当成设计警报。如果同一个环节反复触发token限制通常说明这里的设计有问题——比如把不该塞进上下文的内容塞进去了或者该用结构化记忆的地方还在靠堆对话。这些土办法不复杂但它们解决的恰好就是标题里说的那件事。Token是可以精打细算的但上下文一致性、状态管理、行为可控性、可观测性才是Agent真正难管的地方。把注意力放在这些地方比天天盯着账单数字更有可能把一个Agent项目从“能跑”推进到“敢上线”。