前面拆过 Agent 为什么会被判“撒谎”：答复里说做了某个写操作，工具轨迹里却找不到对应调用，话和证据对不上。
这一篇讲另一面——话和证据都能对上，每一步工具调用都返回 ok，任务却一步都没往前走。
我搭了一个四步最小实验。第 1 步和第 2 步确实在推进：证据从 0 条变成 1 条，待补证据从 2 项减到 1 项。可到第 3 步，工具依然返回 ok，证据集合再没增加，待解决问题也没减少。
控制器在第 4 步就标了 no_progress，没有等到 max_steps=8。
很多系统只设最大轮数。它能阻止 Agent 无限运行，却分不清第 8 步是正常收尾，还是从第 3 步起就在原地打转。等轮数跑满再停，中间那 5 步的钱和延迟已经花掉了。
这篇文章不照参数清单念文档。先把这条四步轨迹完整展开，看清“进展”该拿什么衡量，再讲控制器应该在哪一步做出判断。
四个 ok 组成了一条失败轨迹
先把轨迹展开。任务需要找到两项独立证据，步数预算是 8。
第 1 步调用 search_docs("Agent memory update")，得到结果集 A，待补证据从 2 项变成 1 项。第 2 步打开 A1，抽出事实 F1，已核验证据从 0 条变成 1 条。前两步都在推进任务。
第 3 步再次搜索同一个问题，工具仍返回 A。第 4 步把查询改成 agent memory update，接口照样成功，结果仍是 A。字符串看起来变了，业务状态却没变：证据还是 1 条，缺口还是 1 项。
如果监控面板只看 HTTP 200、ok=true 和工具成功率，这四步全是绿色。可从任务角度看，后两步没有产出新证据，没有排除假设，也没有缩小缺口。继续调用只会消耗 token、时间和外部 API 配额。
所以每个 action 之后，都要问一个更严格的问题：它改变了什么？
对研究型 Agent，进展可能是新增一条独立来源、补齐一个证据缺口、排除一个候选答案。对客服 Agent，进展可能是订单状态从“待确认”变成“已核验”，或者成功拿到用户缺失的信息。对编码 Agent，进展可能是失败测试数量下降、目标文件被正确修改，而不是又执行了一遍同样的命令。
这意味着任务启动时就要定义“进展契约”。至少明确目标状态、未完成项、哪些字段只能由权威工具改变，以及什么证据才能关闭一个缺口。没有这份契约，控制器只能数调用次数，无法知道 Agent 离完成更近还是更远。
状态也不能只存一段自然语言摘要。摘要可能写着“已经找到相关资料”，但结构化 evidence_count 仍是 0；模型读起来像有进展，控制器却拿不到可验证变化。关键状态要有可比较字段，自然语言只负责补充解释。
进展必须绑定任务状态，不能只绑定工具返回值。
四步工具调用都成功，但后两步没有增加证据或减少任务缺口
字符串变了，为什么状态没变
最常见的循环检测是记录 (tool, input)，发现完全重复就中断。它能抓住一部分问题，但很容易漏掉语义相同、写法不同的调用。
开头第 3、4 步就是例子。大小写和空格不同，原始字符串不相等，归一化后却都是 query=agent memory update，返回结果也相同。如果只比原文，控制器会把第 4 步误判成一次新探索。
反过来，工具和参数完全相同也不一定是坏循环。第一次请求超时，第二次使用相同幂等键重试；第一次搜索索引尚未刷新，业务允许等待后再查一次。这些重试可能合理。看到重复就立刻停止，同样会误伤正常恢复。
更稳的判断要同时看三类信号。
第一类是动作指纹。对参数做大小写、空白、排序和默认值归一化，再记录工具名与关键参数。第二类是观察指纹，对结果集、错误类别或关键字段做稳定摘要，判断“返回了一大段新文本”是否其实还是同一批内容。第三类是状态差，比较 action 前后的 evidence_count、open_gaps、task_state、test_failures 或业务状态版本。
指纹还要避开噪声字段。搜索结果里的抓取时间、请求 ID 和排序抖动每次都可能不同，如果直接对完整 JSON 哈希，控制器会误以为结果一直在变。应先抽取与任务相关的文档 ID、事实键或业务状态，再计算稳定摘要。反过来，不能为了命中重复而删除金额、币种、对象 ID 等真正影响任务的字段。
状态差也要验证来源。模型自己在 scratchpad 里把“待核验”改成“已完成”，不应算业务进展；只有验证器、权威工具或满足证据规则的状态转移才能关闭缺口。否则 Agent 可以通过改写自己的计划制造虚假进度。
这段脚本把工具名、归一化参数和结果摘要算成指纹。第 1、3、4 步得到相同指纹 47abf3e4；第 3、4 步的 evidence 与 gap 均无变化，于是无进展连续计数从 1 变成 2，控制器在第 4 步停止。
这里把连续两次无进展设为最小实验的停止条件，不是通用阈值。搜索调研、数据库轮询和高风险写操作，对等待时间、重试次数和证据要求都不同。应该用回放数据校准，而不是把一个数字复制到所有 Agent。
停止条件的边界：软判断与硬预算
max_steps 仍然需要，但它只是一道硬预算。和超时时间、token 上限、工具调用上限、重试次数、费用上限一样，它回答的是“最多允许花多少”，不回答“任务是否已经完成”。
软停止条件负责业务判断，至少应区分几种结果：目标已经完成；连续没有进展；信息不足，需要用户补充；下一步涉及高风险操作，需要审批；当前能力无法完成，需要降级或转人工。
这些状态不能都压成一个 failed。如果是 completed，系统可以进入答案生成；如果是 needs_input，应该提出最小澄清问题；如果是 risk_gate，应该暂停并展示将执行的动作；如果是 no_progress，应该输出已经确认的事实、尚缺的证据和停止原因，而不是假装任务完成。
停止也不等于立刻丢弃现场。控制器可以先保存最后一个一致状态、已验证证据和未完成清单，再生成受限结果。研究任务可以回答“目前只核验到一项”；编码任务可以保留补丁但不提交；客服任务可以转人工并附上已查到的订单信息。这是带证据降级，不是把半成品包装成成功。
如果多个子任务并行，还要按分支判断进展。一条分支停滞，不代表整个任务必须终止；但同一缺口被三个子 Agent 重复搜索，也不能因为调用来自不同 worker 就算三次探索。控制器需要在共享任务状态上去重，再决定终止单个分支、重新规划或结束全局任务。
控制顺序也很重要。每轮先执行 action，再验证观察结果，再计算状态差，随后判断业务完成、风险与无进展，最后才检查剩余预算。否则只在循环开头看轮数，很容易多跑一步高风险工具，或在刚好完成时仍被粗暴标成超限。
写操作还要单独处理。发消息、退款、建单等动作不能因为结果暂时未知就直接重试。控制器应先用幂等键查询前一次执行状态，区分“请求失败”“响应丢失”和“业务未发生”，再决定是否重发。循环检测负责识别停滞，幂等与确认机制负责避免重复副作用，两者缺一不可。
Agent 控制器同时使用业务停止条件和步数、时间等硬预算
Trace 记录协议要解释每次停止
没有 Trace，循环问题只能看到最终的“超时了”。有了结构化轨迹，才知道 Agent 在哪一步失去进展。
更实际的做法是把“有进展”写成可核验字段，而不是只背一个停止阈值。
每一步至少记录 trace_id、step、目标摘要、归一化 action、工具状态、结果指纹、关键状态版本、状态差、剩余预算、控制器决策和 stop_reason。高风险参数可以脱敏或摘要，但不能只留一句“调用成功”。
除了记录“发生了什么”，还要记录“依据哪条策略”。同一条 trace 在 policy_v1 下可能允许继续，在 policy_v2 下可能提前停止。日志里若没有 controller_version、threshold_source 和命中的规则 ID，策略升级后就无法解释判断变化，也难以做新旧版本回放对比。
复盘时先找最后一次有效状态变化，再看后续 action 为什么仍被允许。是 Planner 没看到已有证据，工具每次返回同一页，状态更新失败，还是停止策略只配置了最大步数？不同原因对应不同修复，不能都归咎于模型“不会思考”。
离线评测也不该只看最终答案。至少加入四类轨迹：动作不同但语义重复；动作相同但允许重试；结果变化却没有业务进展；任务已完成但模型还想继续。对同一条 trace 回放控制器，检查 stop_reason 是否稳定，才能知道改规则后有没有制造新的误停。
评测时要同时统计两类代价：漏停让 Agent 空转或重复副作用，误停让本可恢复的任务过早结束。只追求更高的循环拦截率，会把网络抖动后的正常重试也挡掉；只追求任务完成率，又可能容忍大量无效步骤。阈值应按任务风险和回放样本校准。
开头那条轨迹的正确结果不是“第 4 步报错”。工具没有错，控制器只是确认连续两步没有新增证据，于是保留已验证的 F1，标明还缺一项独立来源，并以 no_progress 结束。
Agent 真正的停止能力，体现在每一步都能拿出证据说明：任务发生了什么变化，为什么还值得继续。跑到上限时被拔掉电源，只是最后一道保险。
Agent Trace 需要记录动作指纹、结果指纹、状态差、预算和停止原因
把这些判断落实到可运行、可复盘的大模型项目里，关注点不是堆概念，而是把每个关键设计变成能验证的工程动作。
发表于 4 天前
|
查看: 2|
回复: 0
