文科生用日志分析揪出AI智能体1.5亿次循环失控

1. 一个三本文科生是怎么盯上这个"死循环"的

先把背景交代清楚。前段时间某大厂在公开场合反复强调，旗下一款AI产品是"AI时代的拳头产品"，铺天盖地的宣传里，核心卖点集中在"智能体""自动化任务""一句话搞定复杂流程"这些方向上。我本身是文科出身，学校也不是什么名校，代码能力属于"能看懂、能改、能跑"的水平，按理说轮不到我去挑这种产品的毛病。

但事情的起因特别朴素：我在用这款产品处理一批重复性的文本整理任务时，发现它在某些特定输入下会陷入一种诡异的状态——界面上的进度条一直在转，日志里反复出现几乎相同的动作记录，任务既不报错也不结束。我一开始以为是自己网络的问题，后来换了几台设备、换了几个时间段，现象稳定复现。于是我就起了个念头：这玩意儿到底在干什么？它是不是在某个环节里"绕圈"了？

我做的事情其实不复杂：把每一次任务的动作记录导出来，做去重、做频次统计、做时间序列分析。就是这种最笨的办法，让我在一个批次的日志里数出了大约1.5亿次高度重复的动作调用。这个数字不是精确到个位的审计结论，而是基于日志采样和频次外推得到的量级估计，但它足以说明一个问题：这个被捧为"拳头产品"的东西，在特定场景下存在明显的循环失控。

我写这篇东西，不是要搞什么大新闻，而是想把"一个非科班的人怎么发现并定位这类问题"的完整思路摊开讲。因为这类问题在产品宣传里永远不会被提到，但在真实使用中，它直接决定了你花出去的时间、算力、甚至真金白银值不值。适合读这篇的人有三类：一是正在用类似AI产品做自动化任务、感觉"有时候特别慢"的普通用户；二是想学一套可复用的日志分析方法的技术爱好者；三是做产品测试、质量评估相关工作的从业者。

提示：本文所有分析基于公开可观察的产品行为和通用日志分析方法，不涉及任何内部数据、非公开接口或逆向工程手段。所有数字均为基于采样日志的量级估算，用于说明方法论，不作为精确审计结论。

2. 死循环到底长什么样：从"卡住"到"绕圈"的三种典型形态

很多人对"死循环"的理解停留在"程序卡死不动"。但在AI智能体类产品里，死循环的表现要隐蔽得多，它往往不是"不动"，而是"动得很勤快，但一直在原地打转"。我把它归纳成三种形态，你可以对照自己遇到的情况看看属于哪一种。

2.1 形态一：动作重复型——同一个工具被反复调用

这是最常见的一种。智能体在规划任务时，会把一个大目标拆成若干子步骤，每个子步骤对应一次工具调用或模型推理。正常情况下，子步骤完成后应该推进到下一步。但在某些输入下，它会反复调用同一个工具，参数几乎一模一样，只是每次返回的结果它都"不满意"，于是再调一次，如此往复。

我在日志里看到的典型模式是这样的：同一个检索类动作，在几分钟内被调用了上万次，参数里的查询词只有极微小的差异，甚至完全相同。从外部看，就是"一直在处理中"；从内部看，就是智能体陷入了一个"我再试一次说不定就好了"的执念里。

2.2 形态二：状态震荡型——在两个状态之间来回横跳

第二种更隐蔽。智能体在A状态和B状态之间反复切换，每次切换都伴随着一次完整的推理和动作，看起来"一直在推进"，实际上整体进度为零。这种模式在日志上的特征是：状态标记呈现规律的A-B-A-B交替，周期稳定，持续时间长。

这种震荡往往源于规划逻辑里的判断条件互相矛盾。比如一个条件说"信息不足就继续检索"，另一个条件说"检索次数超限就总结输出"，当两个条件的阈值设置不当时，智能体就会在"继续检索"和"准备总结"之间反复横跳，谁也说服不了谁。

2.3 形态三：递归膨胀型——任务越拆越多，永远做不完

第三种最消耗资源。智能体在拆解任务时，把每个子任务又拆成更细的子任务，而子任务的完成又触发新的拆解，形成一种"任务树无限生长"的局面。日志上表现为：任务队列的长度持续增长，已完成的子任务数量也在增长，但根任务的完成度始终上不去。

这三种形态有一个共同点：它们都不会触发明显的错误。产品不会弹窗说"我循环了"，它只会安静地消耗你的时间、算力和额度。这也是为什么很多人用了很久都没意识到问题，只觉得"这个产品有时候特别慢"。

3. 我是怎么把1.5亿次这个量级"数"出来的

这一节讲方法。我没有用什么高深的工具，核心就是"导出、清洗、统计、外推"四步。任何有基础数据处理能力的人都能复现这套流程。

3.1 第一步：拿到可分析的原始记录

大多数AI产品都会提供某种形式的任务记录或操作日志，有的在界面上能直接看，有的可以导出成文件。我做的事情就是把这些记录完整保存下来，不做任何删改。这里有个经验：尽量保存原始格式，不要一上来就转成表格，因为原始格式里往往保留了时间戳精度、字段顺序、嵌套结构这些关键信息，转格式容易丢细节。

如果产品只提供界面展示、不提供导出，那就用最笨的办法：手动记录关键字段，或者用截图加人工整理。效率低，但对于定位问题足够了。

3.2 第二步：清洗与归一化

原始记录里噪音很多，比如心跳包、无关的状态更新、重复的元数据。清洗的目标是把"真正的动作"提取出来。我的做法是：

1. 按时间戳排序，确保顺序正确；
2. 提取每个动作的核心字段：动作类型、关键参数、返回状态、耗时；
3. 对参数做归一化，比如把只有微小差异的查询词归到同一类；
4. 去掉明显的心跳和元数据记录。

这一步做完，数据量通常会大幅下降，剩下的都是"有信息量"的记录。

3.3 第三步：频次统计与模式识别

清洗完之后，就是统计。我主要看三个指标：

• 单动作频次：同一个动作类型在单位时间内出现了多少次；
• 参数重复率：相同或近似参数的比例有多高；
• 状态转移矩阵：从一个状态转移到另一个状态的频率分布。

当单动作频次在短时间内飙升、参数重复率超过某个阈值、状态转移矩阵出现明显的对角聚集（即A到A、B到B的转移异常多）时，基本可以判定存在循环。

3.4 第四步：从采样到量级外推

我不可能把全部记录都导出来分析，所以用的是采样外推。具体做法是：选取若干个时间窗口，统计窗口内的重复动作次数，算出单位时间的重复率，再乘以总时长，得到量级估计。

举个简化的例子：如果在一个10分钟窗口内观察到约10万次重复动作，而任务总共持续了约25小时，那么按比例外推，总量级就在千万到亿这个区间。我最终得到的约1.5亿次，就是这么估出来的。必须强调，这是量级估计，不是精确计数，它的价值在于说明"问题的规模有多大"，而不是"精确到个位是多少"。

注意：做这类统计时，一定要区分"重复动作"和"正常的高频动作"。有些任务本身就是高频的，比如实时数据流处理，这时候高频是正常的。判断的关键是看"这些动作是否推动了任务进度"，如果进度不动而动作不停，那才是循环。

4. 为什么"拳头产品"也会栽在这种低级问题上

这是最值得聊的部分。按理说，能被称为"拳头产品"的东西，工程能力应该不差，为什么会在循环控制这种基础问题上翻车？我分析下来，原因不在"技术不行"，而在"AI产品的特殊性"。

4.1 传统程序的循环有明确边界，AI智能体的边界是"模糊"的

传统程序里，循环有明确的终止条件，比如for i in range(10)，跑十次就停。但AI智能体的"循环"是由模型的判断驱动的，而模型的判断是概率性的、模糊的。它判断"任务是否完成"靠的不是一个确定的布尔值，而是一个"我觉得差不多了"的倾向。当这个倾向不稳定时，循环边界就消失了。

这不是某个团队的疏忽，而是整个行业在从"确定性程序"转向"概率性智能体"时面临的共性难题。宣传里说的"智能"，在工程上恰恰意味着"不可预测"，而不可预测正是循环失控的温床。

4.2 宣传口径和工程现实之间存在系统性偏差

产品宣传喜欢讲"一句话搞定复杂流程"，但真实工程里，"复杂流程"的每一步都需要可靠的终止条件、超时机制、状态校验。这些机制不性感，不会出现在宣传物料里，但它们是产品能不能用的底线。

我观察到的现象是：越是强调"自动化""智能体"的产品，越容易在终止条件上偷懒，因为严格的终止条件会限制"智能"的发挥空间。这是一个结构性的矛盾，不是靠一次版本更新就能解决的。

4.3 用户侧缺乏"循环感知"，问题被长期掩盖

还有一个原因在用户这边。大多数用户遇到"卡住"时，第一反应是"网不好"或者"任务太难"，很少有人会去导出日志分析。于是循环问题被长期掩盖，产品方也缺乏足够的反馈数据去定位。这就形成了一个循环：用户不报，产品不改；产品不改，用户继续忍。

我写这篇东西的初衷之一，就是想让更多人知道："卡住"不一定是你的问题，也可能是产品的问题，而且这个问题是可以被观察和量化的。

5. 一套普通人也能上手的循环检测实操方案

前面讲了原理，这一节给可落地的方案。你不需要是工程师，只要会用表格软件、能看懂基本的统计，就能做一套简易的循环检测。

5.1 准备阶段：确定观察对象和记录方式

先明确你要观察什么任务。建议选那种"重复性高、耗时长、你感觉有时候特别慢"的任务。记录方式有三种，按可行性排序：

1. 导出日志文件：如果产品支持，优先用这个，信息最全；
2. 界面记录：手动记录每次操作的时间、动作、结果，适合低频任务；
3. 截图存档：作为补充证据，方便回溯。

5.2 分析阶段：三个必看的指标

拿到记录后，重点看这三个指标：

• 单位时间动作数：正常任务的动作数应该是平稳的，如果出现尖峰，就要警惕；
• 参数重复率：把参数列出来，算一下重复的比例，超过50%就值得深挖；
• 进度与动作的比值：动作数在涨，但完成度不涨，这就是循环的典型信号。

5.3 判定阶段：区分"正常慢"和"异常循环"

这一步最容易误判。我的经验是看"动作是否带来状态变化"。如果每次动作后，任务的关键状态字段都发生了变化，那即使慢也是正常的；如果状态字段长时间不变，而动作数持续增长，那基本可以判定为循环。

5.4 记录与反馈阶段：把观察变成有效信息

发现问题后，别只是自己忍着。把观察结果整理成一份简洁的记录：什么任务、什么时间、观察到什么现象、量级大概多少。这份记录既是你自己复盘的依据，也是向产品方反馈时最有说服力的材料。有数据支撑的反馈，远比"你们这东西好慢"有效得多。

6. 踩过的坑：我在分析过程中犯的几个错误

讲完方法，得讲讲我踩的坑，不然这篇就不够实在。

6.1 把"高频"直接等同于"循环"

我一开始看到某个动作在短时间内出现很多次，就兴奋地判定是循环。后来发现，那个动作本身就是设计成高频轮询的，属于正常行为。这个坑让我明白：判断循环不能只看频次，必须结合状态变化。频次高只是线索，不是结论。

6.2 忽略了时间窗口的选择偏差

我最初选的分析窗口恰好是任务最繁忙的时段，导致重复率被高估。后来我改成选取多个不同时段做对比，结论才稳定下来。这个教训是：采样窗口要多样化，不能只挑一个时段就下结论。

6.3 把量级估计当成了精确数字

前面说的1.5亿次，是外推估计。我一度想把它当成精确结论去用，后来意识到这不严谨。量级估计的正确用法是"说明规模"，而不是"证明精确值"。在对外表达时，一定要说清楚这是估计，否则容易被人抓住把柄。

6.4 过早下"产品不行"的结论

分析到一半时，我情绪上来了，觉得这产品就是个花架子。但冷静下来后我发现，循环问题在AI智能体里是普遍存在的工程挑战，不是这一家独有的。把问题归因到"某家不行"，既不公平，也不利于真正理解问题。保持技术中立，才能把问题看清楚。

7. 从这次分析里，我总结出的几条实用经验

最后分享几条我个人觉得最有价值的经验，都是踩坑踩出来的。

第一，遇到"卡住"先别急着怪自己。导出记录、做点基础统计，很多时候你会发现问题的根源不在你这边。这个习惯一旦养成，你对所有AI产品的判断力都会提升一个档次。

第二，量级比精确值更有说服力。你不需要精确数出1.5亿次，你只需要证明"重复动作的量级在千万以上"，就足以说明问题。追求精确反而容易陷入细节，耽误判断。

第三，区分"产品缺陷"和"技术阶段"。循环失控在当前的智能体产品里是阶段性问题，理解这一点，你就不会对某个产品抱有不切实际的期待，也不会因为一次踩坑就全盘否定。

第四，把观察变成可复用的方法。我这次用的"导出、清洗、统计、外推"四步法，换个产品、换个任务照样能用。方法的价值远大于单次结论。

第五，也是我个人体会最深的一点：文科背景不是障碍，好奇心和笨办法才是关键。我不懂模型内部怎么运作，但我懂怎么把现象记录下来、怎么数数、怎么对比。很多时候，发现问题靠的不是高深技术，而是愿意较真的态度。这套思路，任何人都能学，也任何人都能用。