最近在做 DunCrew （一个本地运行的 AI Agent 系统）的时候，积攒了 347 条真实的任务执行记录。本来想看看 Token 成本怎么优化，结果挖出来一些有意思的东西，顺手写了篇论文发了 arXiv 。核心思路： 类比 DNA 测序。把 Agent 每一步操作编码成四种"碱基"——X （探索：读文件、搜索）、E （执行：写文件、跑命令）、P （规划：思考、反思）、V （验证：检查结果）。一个任务就变成一条碱基序列，比如 X-X-P-E-E-V-E ，然后用 n-gram 、马尔可夫转移矩阵这些经典方法去分析。几个硬数据：
P-X-P 振荡是唯一显著的高危三元组：规划→探索→又规划，命中这个模式的任务成功率下降 10.4%。Agent 在"想做什么"和"去看看情况"之间反复横跳，就是不动手。
E→V 转移概率只有 2.1%：Agent 执行完操作后几乎不验证结果。写完文件不检查、跑完命令不看输出，这是系统性缺陷。
P-ratio 是最强的失败预测因子（ r=-0.256, p<0.0001 ）：一条序列里"规划"占比越高，任务越可能失败。Agent 过度思考约等于原地踏步。
然后我们做了个东西叫 Governor：基于上面的发现做了一个序列级的"熔断器"，不调用 LLM 、零额外成本，纯粹看碱基模式来干预。比如检测到连续探索就强制刹车，检测到执行后没验证就注入提示。部署前后对比（ 101 条 vs 246 条）：
成功率：88.1% → 94.3%（+6.2%）
平均 Token 消耗：275K → 154K （-44%）
触发了规则的任务成功率反而最高（ 96.4%），说明干预是正向的
跨系统验证：为了排除"只在自己系统上有效"的疑虑，我们拿了 2000 条 SWE-agent 在 SWE-bench 上的公开轨迹，用同样的 XEPV 编码分析。结果：探索螺旋和 E→V 验证缺失这两个核心模式在 SWE-agent 上也复现了。
论文和分析工具都会开源：
论文：arXiv （链接待补充）
工具包：github.com/FatBy/base-sequence-toolkit
官网：duncrew.com
做 Agent 的兄弟们有没有遇到过类似的问题？特别是 Agent 在死循环里烧 Token 的情况，有什么好的处理策略？
P-X-P 振荡是唯一显著的高危三元组：规划→探索→又规划，命中这个模式的任务成功率下降 10.4%。Agent 在"想做什么"和"去看看情况"之间反复横跳，就是不动手。
E→V 转移概率只有 2.1%：Agent 执行完操作后几乎不验证结果。写完文件不检查、跑完命令不看输出，这是系统性缺陷。
P-ratio 是最强的失败预测因子（ r=-0.256, p<0.0001 ）：一条序列里"规划"占比越高，任务越可能失败。Agent 过度思考约等于原地踏步。
然后我们做了个东西叫 Governor：基于上面的发现做了一个序列级的"熔断器"，不调用 LLM 、零额外成本，纯粹看碱基模式来干预。比如检测到连续探索就强制刹车，检测到执行后没验证就注入提示。部署前后对比（ 101 条 vs 246 条）：
成功率：88.1% → 94.3%（+6.2%）
平均 Token 消耗：275K → 154K （-44%）
触发了规则的任务成功率反而最高（ 96.4%），说明干预是正向的
跨系统验证：为了排除"只在自己系统上有效"的疑虑，我们拿了 2000 条 SWE-agent 在 SWE-bench 上的公开轨迹，用同样的 XEPV 编码分析。结果：探索螺旋和 E→V 验证缺失这两个核心模式在 SWE-agent 上也复现了。
论文和分析工具都会开源：
论文：arXiv （链接待补充）
工具包：github.com/FatBy/base-sequence-toolkit
官网：duncrew.com
做 Agent 的兄弟们有没有遇到过类似的问题？特别是 Agent 在死循环里烧 Token 的情况，有什么好的处理策略？
目前尚无回复
Select Language