Agent的自旋检测与优雅退场-育师

Agent 的自旋检测与优雅退场：什么时候该坚持，什么时候该停？

报错"连接拒绝"，你的 Agent 第 1 次改了端口，第 2 次换了命令，第 3 次建议你"检查防火墙"，第 4 次……把第 1 次的命令又贴了一遍。
你盯着屏幕想：它到底知不知道自己在原地打转？
反过来也常见：遇到一点困难，它突然说"建议我们下次再继续"——你以为它 responsibly 收尾了，其实是在逃。

“该停的时候不停，不该停的时候乱停”，是长流程 Agent 最容易被忽视的设计盲区。大家都在教 Agent"怎么做任务"，很少有人教它"怎么判断做不下去了"和"怎么体面地结束"。

这篇拆解 tech-stack-architect-coach 会话管理协议里我认为最有工程密度的一部分：主动收尾触发条件 + 自旋检测 + 低投入信号判定。它和跨窗口续接（专栏第 3 篇）是一体两面——会收尾，续接才有意义。

📌TL;DR 速览
讲什么：Agent 的"退场工程"——怎么判断该坚持、该换方式、还是该体面收尾
核心结论："该停"的判据是客观行为（进展/维度/轮次），不是用户喊停；坚持要有 2 轮上限
三个关键数字：5 个主动收尾触发条件｜换方式 2 轮上限｜ 4 条对称禁止条款
适合谁：做排查/客服/教学等长对话 Agent，被"死撑"或"逃避"折磨的人

一、两个对称的失败模式：死撑与逃避
二、五个主动收尾触发条件
三、自旋检测：怎么判定"原地打转"
四、低投入信号：最容易误判的地方
五、自旋/卡死的中间处理：先跳出，再决定收尾
六、收尾五要素：结束是一门手艺
七、对称的禁止条款
八、可复用清单
九、总结

一、两个对称的失败模式：死撑与逃避

协议对这两个模式有精准的画像：

注意设计哲学：“该停"的判据不是"用户喊停”，而是客观条件；而且判停之后不是直接结束，而是"先尝试跳出，跳出无果才收尾"。既不能硬撑，也不能一碰就缩。

二、五个主动收尾触发条件

协议要求教练自己识别"该收尾了"并主动提出，满足任一条件即触发：

#	条件	判定细节
1	上下文过长	轮次达阈值（默认 20，可配置）；或发现自己需要反复回看早期内容才能继续（遗忘征兆）；约 75% 处（~15 轮）先预警"建议本模块结束后收尾"
2	自旋检测	同一问题被问 ≥2 次、同一报错 ≥3 次、或连续 3 轮无实质进展（详见下节）
3	学员低投入信号	分档判定（详见下下节），防止误触
4	阶段完成	模块六步走走完 / 环境搭好——自然的存档点
5	学员卡死	一个报错卡 >3 轮，且教练已给过 ≥2 种排查方向仍未解决

条件 1 里有两个易被忽略的细节：

遗忘征兆（协议叫"异常遗忘"）被列为独立信号：发现 Agent 开始重复解释已讲过的术语、偏离已确认的偏好、把已关闭的选项旧话重提——立即收尾，不要硬撑。等它彻底忘光再存，存的也是错的；
预警线：阈值（20）的 75% 处先打招呼，到线才执行——给学员心理预期，避免突兀。

条件 4 也值得说一句：它让"收尾"不再只是失败/耗尽时的止损动作，而是每个里程碑的自然仪式——完成即存档，存档即续接的保障。

三、自旋检测：怎么判定"原地打转"

自旋（Spinning）的协议定义：

同一问题被问过 ≥2 次、同一报错反复出现 ≥3 次、或连续 3 轮没有实质进展。

真正的工程密度在"实质进展"的判定标准上，协议给了两条铁规：

① 进展以学员侧为准。学员贴出了新的报错文本/日志、任务往前推了一步，才算进展；教练单方面换命令、换角度，但学员没给新反馈，不计为进展。

这一条封死了一个经典的自欺欺人类型：Agent 自己觉得"我在努力"，其实只是换着花样重试同一思路，学员那边没有任何新信息进来。

② "换方式"必须跨维度才算。同一维度内反复换参数不算换方式——连续改docker run的-p/-e选项、连续微调同一条命令，属于"无脑换命令"的变体，判为自旋。跨维度才算：从"要报错文本"换到"看容器实际状态"，再换到"跳过/降级"。

✗ 不算换方式（同维度换参数）：改端口 → 改端口映射写法 → 加 -d 参数 ✓ 算换方式（跨维度）： 要报错文本 → docker ps 看容器状态 → 跳过此步先推进

这个判定标准的普适性远超教学场景：任何"排查-修复"型 Agent（运维、客服、代码调试）都需要它。

四、低投入信号：最容易误判的地方

"用户好像不想聊了"是 Agent 最难判断的信号之一——判重了显得驱赶用户，判轻了纠缠骚扰。协议的做法是分档 + 三条件 + 豁免清单：

A 档·想停短语——即时触发。“先这样吧”“有点累”“下次再说”"今天到这"等明确表达想停的语义，命中即收尾。

B 档·裸应答词——须三条件同时满足才计入。“嗯”“哦”"好的"这类应答词，只有当：

教练已明确要求学员执行某动作（跑命令/贴输出/动手改）之后；
连续 ≥2 轮只回此类词、没实际执行、没新信息、没推进；
学员并非正在专注执行任务（正在跑压测/敲命令/贴日志期间的短应答一律不计）；

——三条件同满，才算低投入信号。

豁免清单（明确不计入的两种"假低投入"）：

step_confirm节奏下学员每步的"嗯/好的/收到"——那是正常教学节奏；
诊断期的简短回答（“面试冲刺”“每天 2 小时”“都按默认”）——那是短问换短答的正常形态。

协议的防误判总原则写得很到位：

单个应答词永远不足以触发收尾；判定必须基于实际回复内容 + 是否在推进，而非字面词表。

这条原则其实是全篇的题眼：所有触发条件判定的都是"行为和进展"，不是"话语的表面客气"。

五、自旋/卡死的中间处理：先跳出，再决定收尾

命中自旋（条件 2）或卡死（条件 5）时，协议禁止两个极端——“无脑继续原路径换命令试"和"直接甩一句我们下次继续”。正确流程是先跳出，跳出无果再收尾：

明确点破：一句话告诉用户"我们在这个点上已经绕了 N 轮，先停一下换个方式"——点破本身就是在建立共识；
换一种方法（四选一或组合）：
- 换提问角度——换种方式让用户描述现象（“把完整报错和docker ps、服务日志一起贴出来”）；
- 换工具/命令——换一个排查方向（仍守红线：一次一条、四要素解释）；
- 先跳过这一小步——把卡点记入遗留疑问，推进能推进的部分；
- 降级目标——“彻底解决"降级为"记录现象 + 已试排查方向，留待重开”；
给换方式设 2 轮上限：换方式后再给 2 轮，仍无实质进展必须收尾——不允许第 3 轮继续硬撑。

设计的精妙在"2 轮上限"：它给了"坚持"一个有界的额度，既不一碰就缩，也不无限续杯。目的协议里写得直白：既避免反复烧 token，也避免用收尾躲避问题——判据是"换方式是否有效"，不是"用户喊没喊停"。

六、收尾五要素：结束是一门手艺

收尾不是说一句"下次继续"，而是顺序固定的五个要素，且关键顺序是：先征询确认，再落盘（延续"不猜测、不代劳"的原则）：

要素	内容	要点
1. 一句话说清原因	点明触发的是哪条条件	“我们这轮聊得比较多了” / “这个报错换了两种方式还没通，先落盘别空转” / “模块 N 走完，正好存档”
2. 总结进度 3–5 条	学到了什么 / 卡在哪 / 下一步	先贴给用户看，先不落盘
3. 征询学员确认	“有要补充或纠正的吗？”	学员确认后才落盘；有出入先改总结
4. 落盘	体系笔记 + CONTEXT.md 全文覆盖 + TRACE.md 追加	卡死型收尾必须写清"当前卡点 + 已试排查方向"
5. 给出下次入口	续接话术 + 交接文件说明	“下次直接说’继续学 Redis’，我会自己读交接文档”

要素 3 还有个例外条款，设计得很成熟：自旋/卡死且上下文接近溢出时，允许边落盘边征询——先存一版再请用户复核，但必须明确告知"我已先存了一版，有出入随时让我改"，不得静默落盘后假装问过。

要素 4 里"卡死型收尾"的落盘要求是整套设计的闭环关键：已试过的排查方向必须落盘——否则下次冷启动（专栏第 3 篇的五检查）会从零再试一遍，自旋就白检测了。

七、对称的禁止条款

有了触发条件和流程，还必须封死四种钻空行为（协议原文为硬约束）：

禁止假装收尾：不能嘴上"我们下次继续"但不落盘——提出收尾就必须走完五要素全流程；
禁止学员没同意就强行收尾：学员明确说"我还想继续"且未命中自旋/卡死，就继续教——主动收尾权不等于专制权；
禁止把收尾当逃避：触发条件必须真实满足，尤其低投入信号必须按分档判定——单个"嗯"、step_confirm 的"好的"、诊断期的短回答都不能拿来当收尾借口；
禁止自旋时硬撑：已命中自旋时即使用户没喊停也必须介入——不得装作没检测到继续原路径。

这套"权力 + 约束"的对称设计很值得玩味：前两条给收尾权上锁（不能逃、不能滥用），后两条给不作为上锁（不能装看不见）。Agent 的每一权权力都有对应的禁止条款，这才是完整的设计。