项目做到一半，模型开始原地复读。我当时在生成一篇长文，先是同一个词在连续三句话里反复出现，接着整段复读，最后连着章节标题都开始自我循环。那是我第一次认真面对一个事实：在语言模型应用里，最隐蔽的故障不是“答错”，而是“转圈”。后来我花了几周时间专门研究这类问题，发现可以把它系统化为一套方法论。这套方法论在社区里慢慢有了个名字，叫 Loop Engineering，直译过来就是循环工程。Loop Engineering 不是某个官方标准，也不是某个框架自带的模块，它是对“语言模型生成过程中循环现象的识别、检测、打破与设计”的一整套工程实践。它解决的问题很具体：模型为什么复读？如何快速定位是参数问题还是提示词问题？怎么自动检测一段输出是不是陷入循环？在 Agent 任务里怎么防止模型反复调用同一个工具？反过来，迭代自省、多轮修正这类良性循环又该怎么设计？这篇教程就是把我自己的完整经验拆开，从症状分类、根因分析、检测代码、打破手段到实战项目，一步一步讲清楚。适合谁看？如果你在用语言模型写长文本、做 Agent、搭内容生成服务，并且被“输出重复”“跑偏”“原地打转”折磨过，这篇文章可以省下你大量无头绪调参的时间。如果你只是好奇大模型为什么会抽风式复读，前面的章节也能帮你理解背后的概率机制。1. 先给“循环”建档：四种典型循环症状在动手修之前，先把循环分清楚。不同症状看起来都像“重复”，但根因和处理方式完全不一样。我把我实际遇到的案例都归了类，识别方法都写在后面。1.1 词句层面的复读机循环这是最外层、最容易被肉眼发现的循环。典型表现是：模型在某个时刻突然开始高频重复一个词、一个短语或一整句话。我遇到过一个很典型的例子：让它写产品介绍，写到第二段快结束时，连续出现四次“需要注意的是”，“需要注意的细节包括”，“还要注意的是”。单独拎出来看每个句子都通顺，但排在一起就像复读机。更严重的情况是同一句话原封不动重复好几遍，中间不带任何变化。这种循环的识别特征很简单：重复单位短，通常是 3 到 10 个 token；重复节奏密集，基本出现在同段或相邻段；内容没有信息增量和层次推进。1.2 语义层面的原地打转循环比字面重复更隐蔽。字面上句子不重复，看起来也不像复读机，但内容一直在同一个论点上绕圈，信息量不增加。举个实际例子。我要求模型用五个角度论证某个技术方案可行，结果第三个角度之后就开始反复强调“该方案具有显著优势”“性能表现优异”“能够有效解决问题”，措辞一直在换，但论据体系从头到尾只有那两三条。这就是语义层的循环。人类读者会感觉“这段好像讲过了”“怎么又回来了”。识别特征是：用信息密度衡量时，每隔固定长度就会出现与之前某个语义单元高度相似的内容；句子的表层变化掩盖不了论点集合的收敛。1.3 链路层面的 Agent 死循环这个常见于带工具调用的 Agent 场景。模型拿到一个任务后，会进入“思考—行动—观察”的循环，正常情况下每轮行动应该推进任务，但有时候模型会反复调用同一个工具、用同一个查询词，乃至不断生成内容相同或相近的中间思考。我做某个检索类 Agent 时，遇到过一次非常无语的情况：模型反复搜索同一个关键词，连续调了七八次工具，观察结果一样，思考结论也一样，就是没有下一步动作。从服务端日志看，Token 消耗在飙升，但任务的进度条纹丝不动。识别特征是：工具调用序列出现高重复模式；同一个 tool 输入参数高度相似；运行轮数超过预期却拿不到新信息。这类循环的代价是真实的计费数字，不解决会直接烧掉预算。1.4 迭代层面的自我确认循环这个更深一些。发生在模型需要做批判性分析或反复修订任务的场景里。模型先给出了一个结论，然后后面的所有步骤都在找证据强化这个结论，而不是重新审视它。我让模型扮演项目复盘角色，要求它先找到问题根因再给出改进方案。结果它从第一步开始就认定“流程不规范”是唯一原因，后面每一步都在重复“流程不规范导致进度失控”“进度失控源于流程不规范”，推理没有形成闭环，只有自我确认的回路。识别特征是：初始结论和最终结论完全一致，中间没有任何“可能错了”“需要验证”的转折；所有中间步骤都指向同一个方向；推理链本质上是个环而不是一条线。这四种症状在实践中常常叠加出现：语义循环的末端往往伴随字面重复，Agent 死循环里也经常夹杂着语义打转。先建档的意义在于，它能决定你之后往哪个方向排查。2. 循环是怎么被“喂”出来的：生成机制、采样参数与提示词结构知道症状之后，重点来了：这些循环到底从哪来。我把根因分成三层，可能和很多人的直觉不太一样。2.1 概率分布的自我强化：重复内容为什么会“越陷越深”语言模型生成文本，本质上是在每一步从全词表里按概率分布采样一个 token。问题在于，这个概率分布会受到上下文里已有内容的影响。当上下文中出现过一个词，这个词在后续位置的采样概率往往会变得更高。这就是循环的物理基础：一旦模型在某个时刻输出了一个小范围内的重复模式，这个模式就会作为上下文，推高下一次继续输出相似内容的概率。重复的内容越多，上下文中的重复信号越强，模型就越容易继续复制自己。它是一个正反馈过程，越陷越深。我常用一个类比来解释：模型走出了一条浅沟，然后它每一步都更倾向于顺着旧脚印走，沟就越踩越深，最后完全爬不出去。2.2 采样参数是循环的“旋钮”，不是开关很多人一遇到重复就调 temperature，但 temperature 本身是个双刃剑。调低了，输出变得更加保守，更容易走概率最高的那条路径，反而可能强化重复模式；调高了，输出变得混乱，短期看像是“跳出来了”，但长期看可能会陷入另一种随机游走式的循环。真正直接对抗重复的是频次惩罚类参数，它在计算概率时对已经出现过的 token 打一个折扣。还有一个配套的存在惩罚参数，只要 token 出现过就惩罚，不管出现几次。前者压制高频复读，后者压制“出现过还得用”的倾向。我实测的经验是：处理复读机循环，优先动惩罚参数而不是 temperature；temperature 只用于整体风格调节，把它当成循环开关是常见误区。2.3 提示词没有“出口”：开放式任务的结构缺陷很多循环不是生成层面的毛病，是任务本身没给模型一个“什么时候该停下来”的信号。假设你直接让模型“写一篇关于数据可视化的文章”，没有章节数量、没有字数上限、没有结束信号，模型就会一直写下去。写到一定程度，新内容枯竭，但输出现象不能停，于是就开始用已有内容打转，把前面说过的换着法子再说一遍。这就像让一个人在没有出口的迷宫里一直走，他最后一定会绕圈。提示词如果只有起点没有终点，模型就只能在语义空间里画环。2.4 为什么循环总在长文本尾部爆发如果你观察过足够多的失败案例，会发现循环的高发区在两处：长文本的尾部，以及上下文接近窗口上限的位置。这里面有个实际原因：窗口越长，前面内容对当前位置的“注意力”就被稀释得越厉害。模型在长距离依赖丧失后，会倾向于关注最近的内容，而最近的内容往往就是它自己刚刚生成的，于是“看自己—复制自己—再看自己”的环就形成了。另一个长文特有现象是，模型在任务后期已经没有“新计划”可用，但它仍然处于生成模式。尾部爆发循环，本质上是“任务目标已完成但生成信号未终止”的综合表现。所以你会发现，纯粹的“调参解决循环”在短文本里好使，在长文本里效果衰减很快。原因就是长文本循环有结构因素，不是单纯的采样问题。3. 循环检测：从人工肉眼到自动化指标修复循环的前提是能稳定地识别循环。人工肉眼看几千字找重复点，既累又漏。我在实战里把循环检测做成了自动化模块，核心就三招：观察基线、自相似度、熵值监控。3.1 观察基线：先回答四个问题动手写检测代码之前，先人工建立一条观察基线。别嫌麻烦，基线能帮你确定检测参数，避免后面疯狂误报。我每次拿到复现样本，会先回答四个问题：循环单位是什么？是词、句子，还是语义块？单位不同，滑动窗口的 size 就不同。循环周期多长？每隔几句出现一次相似内容？周期决定窗口间隔和比较步长。循环发生在全文哪个位置？开头还是尾部？位置不同，检测启动时机就不同。循环的相似度有多高？是完全雷同还是“神似而形不似”？这决定相似度阈值选多少。这四个问题回答完，检测参数的初值基本就定了。3.2 自相似度检测：滑动窗口与向量化字面重复容易检测，难的是语义循环。我的做法是对文本做滑窗切分，把每个句子或每个固定长度的段落转成向量，然后计算相邻窗口内的平均相似度。相似度连续超过阈值，就判定进入循环区间。向量化不一定要用重型模型。实测下来，用字符级别的 n-gram 特征做 TF-IDF 向量化，对于循环检测已经够用，成本低，跑得快。语义循环有一个特点：即使措辞变了，字符级的共现模式往往还是会留下痕迹，n-gram 能捕捉到大部分情况。3.3 熵值监控：生成质量塌陷的数值征兆第二个信号是熵值。我把生成过程中的 token 对数概率收集出来，逐段计算平均熵。正常情况下，生成内容的熵维持在一定区间；一旦进入循环，模型的概率分布开始高度集中，熵值会明显下降。这个指标的好处是它不依赖语义判断，纯粹看概率分布的形状。适合在服务端流式输出的过程中实时监控，一旦发现连续多个片段的熵低于正常基线，立刻触发预警。熵值监控没法单独作为判据，因为它无法区分“模型在很确定地输出内容”和“模型陷入循环”，需要和自相似度检测配合使用。自相似度负责抓文本结构特征，熵值负责抓概率分布特征，两个信号同时触发才算确认进入循环。3.4 一个可直接复用的循环检测器我把这些手段收敛成一个完整的检测类，核心逻辑是“滑窗自相似度 + 文本熵计算”的二元判断。你可以直接拿去改。import math import numpy as np from typing import List, Tuple from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity class LoopDetector: def __init__( self, window_size: int = 5, similarity_threshold: float = 0.86, entropy_drop_ratio: float = 0.65, min_text_len: int = 200, ): self.window_size = window_size self.similarity_threshold = similarity_threshold self.entropy_drop_ratio = entropy_drop_ratio self.min_text_len = min_text_len self._vectorizer = TfidfVectorizer( analyzer="char_wb", ngram_range=(2, 3), ) def _split_sentences(self, text: str) -> List[str]: parts = [s.strip() for s in text.replace("\n", "。").split("。") if s.strip()] return parts def _window_similarity(self, sentences: List[str]) -> float: if len(sentences) < self.window_size * 2: return 0.0 vectors = self._vectorizer.fit_transform(sentences) max_avg_sim = 0.0 for start in range(0, len(sentences) - self.window_size, self.window_size): window = vectors[start:start + self.window_size] sims = [] for i in range(len(window)): for j in range(i + 1, len(window)): sims.append(cosine_similarity(window[i], window[j])[0][0]) avg_sim = float(np.mean(sims)) if sims else 0.0 max_avg_sim = max(max_avg_sim, avg_sim) return max_avg_sim def _entropy(self, tokens: List[float]) -> float: if not tokens: return 0.0 probs = np.clip(tokens, 1e-12, 1.0) probs = probs / probs.sum() return float(-(probs * np.log(probs)).sum()) def is_looping(self, text: str, token_logprobs: List[float] | None = None) -> Tuple[bool, dict]: if len(text) < self.min_text_len: return False, {"reason": "text_too_short"} sentences = self._split_sentences(text) sim_score = self._window_similarity(sentences) entropy_score = None entropy_flag = False if token_logprobs: # 把一段文字的logprob序列等分成前中后三段，比较稳定段与当前段的熵 third = max(1, len(token_logprobs) // 3) stable_part = token_logprobs[:third] current_part = token_logprobs[-third:] if len(stable_part) >= 2 and len(current_part) >= 2: base_entropy = self._entropy(stable_part) current_entropy = self._entropy(current_part) entropy_score = current_entropy if base_entropy > 0 and current_entropy < base_entropy * self.entropy_drop_ratio: entropy_flag = True sim_flag = sim_score >= self.similarity_threshold # 字面与语义循环以相似度为主，熵值作为辅助强信号 is_loop = sim_flag or (entropy_flag and sim_score >= 0.75) return is_loop, { "similarity": round(sim_score, 4), "entropy": round(entropy_score, 4) if entropy_score else None, "sim_flag": sim_flag, "entropy_flag": entropy_flag, }这个类每次接收一段完整文本和可选的 token 对数概率序列。第一次接入时，建议把相似度阈值从 0.80 开始往上调到 0.90，用你自己的数据校准一遍，避免误报。4. 打破循环的三套打法：参数侧、提示词侧、控制侧检测只是第一步。真正要解决的是“怎么能让模型不再转圈”。我的经验是分三路并行：先动参数快速止血，再改提示词解决结构问题，最后加控制逻辑兜底。4.1 参数侧：先把明显的复读机压下去面对复读机循环，最直接的参数是频次惩罚系数。我通常从 0.3 开始调，复读严重的拉到 0.6 到 1.0。效果非常明显，但我有两条警告：第一，惩罚系数太高会让输出变得呆板。模型为了避免重复，会强行换生僻词，最后通畅度下降。不要在同一个任务上无脑拉满。第二，存在惩罚系数对词句层面的复读帮助相对小，但对“同一个概念反复出现”的语义打转有一定作用。它压制的是“出现即存在感”，能让模型更快放弃旧论点。温度调节要用在正确方向上。复读机循环的处理顺序是：先调频次惩罚，再看是否需要降温度。如果模型在循环时还伴随着逻辑混乱，可以尝试把温度从默认值调低 0.2 到 0.4，让输出更收敛。反过来，如果你在循环里看到的是反复走同一条高概率路径，可以尝试临时加一点温度，让它跳出概率陷阱，但要配合惩罚参数防止跳进新的随机循环。4.2 提示词侧：给生成任务设计“强制出口”参数只能止血，提示词结构才决定循环会不会复发。我的核心心法只有一句话：永远给模型一个明确的“出口信号”。什么叫出口信号？就是提示词里明确写着：什么时候该结束、以什么格式结束、内容边界在哪里、不许重复什么。我在写长文生成提示词时，会明确要求模型按“大纲—分节—总结”的三段结构走，并且强制每节只能写若干个要点，前面章节用过的论点不允许再次出现。实际上，这一步比调参更根本。我把提示词里的格式约束比作“逃逸通道”：模型生成过程中的概率压力再大，都会被这个“必须收尾”的信号及时拽回来。另一个有效技巧是“反驳清单”。在批判性任务里，我要求模型“先列三条支持你结论的证据，再列三条反对你结论的证据，最后再重新给出结论”。这套做法能有效把自我确认循环打断，因为“列出反对证据”这一步，天然就把模型推下了原来的位置。4.3 控制侧：解码约束与后处理兜底参数和提示词都做了，仍然会有漏网之鱼。控制侧就是最后一道防线。我在服务里加了三道闸。第一道是 stop 参数，在生成接口里指定一组终止序列，一旦模型开始输出某些固定的“车轱辘话”，直接截断。第二道是 max_tokens 约束，给每次生成设定合理的上限，避免无界输出。第三道是生成后的循环检测，把第 3 节的 LoopDetector 接在流式输出后面，实时判断输出是否异常，异常就触发重写或降级策略。重写策略我建议这样设计：检测到循环后，不要直接换参数重新生成全文。代价太大，而且可能引入新的偏差。更稳的做法是定位到循环开始的段落，只截取循环之前的内容作为上下文，调整提示词里的补充约束，从循环起点重新生成。实现思路是：保存生成过程中的章节边界，监测到循环后回滚到最后一个有效章节尾，重写该章节。4.4 为什么“只能缓解，不能根除”：概率模型的本质做完了三套打法，我还是要泼一盆冷水：循环问题不存在一劳永逸的解法。因为语言模型本质上是一个概率模型。它的生成过程天然包含自回归的偏差，只要上下文窗口有限，只要 token 的采样概率受历史内容影响，重复路径就永远存在。你不可能“修好”它，只能“管好”它。参数是旋钮，提示词是约束，控制逻辑是护栏，但护栏之内依然可能出现打转的个案。这点认知很重要。很多团队在循环问题上卡壳，不是技术不到位，而是目标定错了：以为要让模型“永不重复”。实际上能做到的是“概率大幅下降 + 异常自动拦截”，只要这两点到位，用户侧基本感知不到，这就已经合格了。5. 项目实战：构建一个带循环守卫的多轮文章生成器讲完方法论，进入实战。我这里分享一个我做过的模拟项目，项目代号叫“带循环守卫的多轮文章生成器”，核心目标是：自动生成一篇 3000 字以上的多章节长文，并且在生成过程中自动检测和修复循环症状。5.1 需求拆解与整体设计先看需求清单。输入是一个主题词和一个大纲列表。输出是包含四个以上章节的完整文章，每个章节至少 600 字。要求是在无人看守的情况下,不出现复读机循环、语义打转和章节间重复。我把它拆成四个模块：大纲规划模块：根据主题生成各章节大纲，并约定每章主题边界。章节生成模块：基于大纲逐章生成内容，每章有独立的出口信号。循环守卫模块：用第 3 节的 LoopDetector 检测每章输出。修复调度模块：检测到循环后，调用重置策略重写对应章节。整体流程是：大纲模块先生成章节列表，然后进入逐章生成循环。每章生成完毕，立即送入循环守卫；守卫判定正常，就把章节内容追加到上下文中，继续下一章；判定异常，就回滚到本章开头，用修复策略重试。重试超过两次仍失败，就把当前章节拆成两个更小的子章节分别生成。5.2 大纲规划模块：先定边界再写正文大纲模块是整个项目的隐性核心。我观察到，循环问题最严重的场景，是模型“不知道本章到底该写什么”。大纲规划模块的作用就是把“模糊的写作主题”转换成“带边界的章节描述”。我给这个模块设计了一个输出格式：每章包含章节标题、核心论点列表、本章禁止出现的论点引用列表。禁止列表是从前面所有章节的论点里抽取出来的，模型在写当前章节时，明确知道自己不该碰哪些内容。这个设计的直接效果就是：从根本上减少了语义层循环的可能。因为循环的本质是“无话可写但必须写”，而禁止列表给了模型一个“不写什么”的明确指引，比“写点什么”更容易约束生成路径。5.3 章节生成模块与循环守卫的联动生成模块本身不复杂，就是按大纲提示词逐章调用模型接口。关键在于它和循环守卫的联动方式。我实现了一个主循环，伪代码如下：def generate_article_resilient(topic: str, outline: dict, detector: LoopDetector, max_retries: int = 2) -> str: context_parts = [] for chapter in outline["chapters"]: chapter_text = None retry_count = 0 while retry_count <= max_retries: prompt = build_chapter_prompt( topic=topic, chapter=chapter, history=context_parts[-3:], # 只带前几章，防止窗口过长 forbidden_points=chapter["forbidden_points"], ) result = call_model_api(prompt) if result.skipped: # 模型判断该章无需展开或内容重复 chapter_text = None break ok, meta = detector.is_looping( result.text, token_logprobs=result.logprobs, ) if not ok: retry_count += 1 # 修复策略：临时提高惩罚系数，并新增一条“不要重复以上论点”的提示 result = retry_with_higher_penalty( prompt=prompt, penalty_increase=0.2 * retry_count, extra_instruction="用全新的例子支撑论点，禁止重复你刚才写过的句子", ) ok, meta = detector.is_looping( result.text, token_logprobs=result.logprobs, ) if ok: break chapter_text = result.text if chapter_text is None: continue # 跳过该章，或降级为纯大纲 context_parts.append(chapter_text) return "\n\n".join(context_parts)这个代码的关键点有三个：第一，上下文只带前几章，不能全量累积。长上下文本身就是尾部循环的诱因，我在实战里会限制 history 不超过三章，再早的内容用大纲模块抽出的论点摘要代表。第二，重试不是无脑重生成，而是“提高惩罚系数 + 追加约束指令”的双重干预。把重试当成一次有导向的微调，成功率比每次都原样重来高很多。第三，模型如果返回“本章内容已被前面覆盖”，我直接接受空章节并跳过。这个设计刚开始我觉得会损失内容，实际测试后发现，它反而是防止章节间语义循环的有效工具。5.4 实测效果对比我跑了一组对比实验。用同一个主题“远程办公工具的发展趋势”，两组配置分别是：普通长文生成，以及带循环守卫的生成。普通配置在生成第三章节时开始重复“远程办公提高了灵活性”，到第五章节出现了连续三段的字面重复，全文最终停在 5000 字左右，实际有效信息大约只有 3000 字。带守卫的配置，第二章节检测到一次语义循环，触发了重试，重试后成功绕开；第四章节再次检测到相似度 0.91 的语义循环，触发二次重试并且采用了“拆章节”降级策略，把原章节拆成两个小章节，最终顺利完成。全文五个章节，整篇没有出现连续重复段落，有效信息密度大幅提升。值得一提的是，守卫启动的两次修复，单次耗时只增加了 15% 到 25%，在可接受范围内。如果完全不做检测，表面上耗时低，但生成结束后还得人工返工，总成本其实高得多。6. 从“打破循环”到“设计循环”：Loop Engineering 的另一半如果只把 Loop Engineering 理解成“除虫”，那就浪费了它另一半的价值。循环不全是坏事，很多有用的能力恰恰要依赖“让模型自己转圈”。6.1 良性循环：迭代自省与多轮修正语言模型单次输出往往有短板，但只要让它“自己检查自己”，结果会有明显改善。我把这个过程看作一个良性循环：生成初稿，对自己打分，找出薄弱点，重新生成，再打分，直到分数达标。关键是要给这个循环一个明确的“进化方向”。我用的方案是让模型输出一组结构化自省意见：逻辑问题、事实风险、冗余内容、表达不足。再把这份意见作为下一轮生成的补充指令。这样每一轮都会真的变好一点点，而不是换个姿势重复。不过要提醒：自省循环有效的前提是初始任务本身有足够的信息可挖掘。如果任务本身信息不足，那自省循环会退化成自我确认循环，越修越偏。解决办法是在循环里加入外部检查点，比如让另一个模型做交叉验证。6.2 带终止条件的循环：哨兵 token 与预算约束设计良性循环时，最容易犯的错是忘记设终止条件。循环没有出口，就是无底洞。我在所有迭代型任务里都会强制加“预算”和“哨兵信号”两道约束。预算很好理解：最大轮数、最大 token 消耗、最大耗时，任何一个超限就强制终止，返回当前最优版本。哨兵信号是指：在提示词里写清楚“当且仅当你认为文本满足以下三个标准时，输出 END”。模型一旦输出 END，整个循环就终止。这两道约束配合使用，等于给循环装了一个自动刹车。我从实践中得到的体会是，良性循环设计里，“如何退出”比“如何进入”更重要。6.3 一个可复用的生成器验收清单最后分享一个我自己整理的多轮生成任务验收清单，拿来即用：[ ] 每轮生成是否都有明确的上下文边界，还是无限累积？[ ] 每轮是否给模型提供了上一轮的客观反馈信号？[ ] 循环内是否有最大轮数、最大 token 消耗的硬性上限？[ ] 是否设置了可识别的终止输出信号（哨兵 token）？[ ] 是否对最终输出做了循环症状检测，而不是只看接口是否成功？[ ] 检测到循环时，是否有预设的修复策略，而不是人工介入？这套清单在新项目上线前过一遍，能拦下大部分隐性循环问题。我做这个项目最大的体会是：和模型打交道，不能幻想它像确定性的代码一样稳定。它更像一个情绪化的写手，写顺了能超常发挥，写僵了会原地转圈。Loop Engineering 的本质就是一套管理“转圈”的机制：承认转圈不可避免，但让转圈变得可见、可控、可终止。把这些机制做扎实之后，模型应用的可信度会有一个质的提升，这也是我在后续所有项目里一直保留循环守卫模块的原因。
项目做到一半，模型开始原地复读。我当时在生成一篇长文，先是同一个词在连续三句话里反复出现，接着整段复读，最后连着章节标题都开始自我循环。那是我第一次认真面对一个事实：在语言模型应用里，最隐蔽的故障不是“答错”，而是“转圈”。后来我花了几周时间专门研究这类问题，发现可以把它系统化为一套方法论。这套方法论在社区里慢慢有了个名字，叫 Loop Engineering，直译过来就是循环工程。Loop Engineering 不是某个官方标准，也不是某个框架自带的模块，它是对“语言模型生成过程中循环现象的识别、检测、打破与设计”的一整套工程实践。它解决的问题很具体：模型为什么复读？如何快速定位是参数问题还是提示词问题？怎么自动检测一段输出是不是陷入循环？在 Agent 任务里怎么防止模型反复调用同一个工具？反过来，迭代自省、多轮修正这类良性循环又该怎么设计？这篇教程就是把我自己的完整经验拆开，从症状分类、根因分析、检测代码、打破手段到实战项目，一步一步讲清楚。适合谁看？如果你在用语言模型写长文本、做 Agent、搭内容生成服务，并且被“输出重复”“跑偏”“原地打转”折磨过，这篇文章可以省下你大量无头绪调参的时间。如果你只是好奇大模型为什么会抽风式复读，前面的章节也能帮你理解背后的概率机制。1. 先给“循环”建档：四种典型循环症状在动手修之前，先把循环分清楚。不同症状看起来都像“重复”，但根因和处理方式完全不一样。我把我实际遇到的案例都归了类，识别方法都写在后面。1.1 词句层面的复读机循环这是最外层、最容易被肉眼发现的循环。典型表现是：模型在某个时刻突然开始高频重复一个词、一个短语或一整句话。我遇到过一个很典型的例子：让它写产品介绍，写到第二段快结束时，连续出现四次“需要注意的是”，“需要注意的细节包括”，“还要注意的是”。单独拎出来看每个句子都通顺，但排在一起就像复读机。更严重的情况是同一句话原封不动重复好几遍，中间不带任何变化。这种循环的识别特征很简单：重复单位短，通常是 3 到 10 个 token；重复节奏密集，基本出现在同段或相邻段；内容没有信息增量和层次推进。1.2 语义层面的原地打转循环比字面重复更隐蔽。字面上句子不重复，看起来也不像复读机，但内容一直在同一个论点上绕圈，信息量不增加。举个实际例子。我要求模型用五个角度论证某个技术方案可行，结果第三个角度之后就开始反复强调“该方案具有显著优势”“性能表现优异”“能够有效解决问题”，措辞一直在换，但论据体系从头到尾只有那两三条。这就是语义层的循环。人类读者会感觉“这段好像讲过了”“怎么又回来了”。识别特征是：用信息密度衡量时，每隔固定长度就会出现与之前某个语义单元高度相似的内容；句子的表层变化掩盖不了论点集合的收敛。1.3 链路层面的 Agent 死循环这个常见于带工具调用的 Agent 场景。模型拿到一个任务后，会进入“思考—行动—观察”的循环，正常情况下每轮行动应该推进任务，但有时候模型会反复调用同一个工具、用同一个查询词，乃至不断生成内容相同或相近的中间思考。我做某个检索类 Agent 时，遇到过一次非常无语的情况：模型反复搜索同一个关键词，连续调了七八次工具，观察结果一样，思考结论也一样，就是没有下一步动作。从服务端日志看，Token 消耗在飙升，但任务的进度条纹丝不动。识别特征是：工具调用序列出现高重复模式；同一个 tool 输入参数高度相似；运行轮数超过预期却拿不到新信息。这类循环的代价是真实的计费数字，不解决会直接烧掉预算。1.4 迭代层面的自我确认循环这个更深一些。发生在模型需要做批判性分析或反复修订任务的场景里。模型先给出了一个结论，然后后面的所有步骤都在找证据强化这个结论，而不是重新审视它。我让模型扮演项目复盘角色，要求它先找到问题根因再给出改进方案。结果它从第一步开始就认定“流程不规范”是唯一原因，后面每一步都在重复“流程不规范导致进度失控”“进度失控源于流程不规范”，推理没有形成闭环，只有自我确认的回路。识别特征是：初始结论和最终结论完全一致，中间没有任何“可能错了”“需要验证”的转折；所有中间步骤都指向同一个方向；推理链本质上是个环而不是一条线。这四种症状在实践中常常叠加出现：语义循环的末端往往伴随字面重复，Agent 死循环里也经常夹杂着语义打转。先建档的意义在于，它能决定你之后往哪个方向排查。2. 循环是怎么被“喂”出来的：生成机制、采样参数与提示词结构知道症状之后，重点来了：这些循环到底从哪来。我把根因分成三层，可能和很多人的直觉不太一样。2.1 概率分布的自我强化：重复内容为什么会“越陷越深”语言模型生成文本，本质上是在每一步从全词表里按概率分布采样一个 token。问题在于，这个概率分布会受到上下文里已有内容的影响。当上下文中出现过一个词，这个词在后续位置的采样概率往往会变得更高。这就是循环的物理基础：一旦模型在某个时刻输出了一个小范围内的重复模式，这个模式就会作为上下文，推高下一次继续输出相似内容的概率。重复的内容越多，上下文中的重复信号越强，模型就越容易继续复制自己。它是一个正反馈过程，越陷越深。我常用一个类比来解释：模型走出了一条浅沟，然后它每一步都更倾向于顺着旧脚印走，沟就越踩越深，最后完全爬不出去。2.2 采样参数是循环的“旋钮”，不是开关很多人一遇到重复就调 temperature，但 temperature 本身是个双刃剑。调低了，输出变得更加保守，更容易走概率最高的那条路径，反而可能强化重复模式；调高了，输出变得混乱，短期看像是“跳出来了”，但长期看可能会陷入另一种随机游走式的循环。真正直接对抗重复的是频次惩罚类参数，它在计算概率时对已经出现过的 token 打一个折扣。还有一个配套的存在惩罚参数，只要 token 出现过就惩罚，不管出现几次。前者压制高频复读，后者压制“出现过还得用”的倾向。我实测的经验是：处理复读机循环，优先动惩罚参数而不是 temperature；temperature 只用于整体风格调节，把它当成循环开关是常见误区。2.3 提示词没有“出口”：开放式任务的结构缺陷很多循环不是生成层面的毛病，是任务本身没给模型一个“什么时候该停下来”的信号。假设你直接让模型“写一篇关于数据可视化的文章”，没有章节数量、没有字数上限、没有结束信号，模型就会一直写下去。写到一定程度，新内容枯竭，但输出现象不能停，于是就开始用已有内容打转，把前面说过的换着法子再说一遍。这就像让一个人在没有出口的迷宫里一直走，他最后一定会绕圈。提示词如果只有起点没有终点，模型就只能在语义空间里画环。2.4 为什么循环总在长文本尾部爆发如果你观察过足够多的失败案例，会发现循环的高发区在两处：长文本的尾部，以及上下文接近窗口上限的位置。这里面有个实际原因：窗口越长，前面内容对当前位置的“注意力”就被稀释得越厉害。模型在长距离依赖丧失后，会倾向于关注最近的内容，而最近的内容往往就是它自己刚刚生成的，于是“看自己—复制自己—再看自己”的环就形成了。另一个长文特有现象是，模型在任务后期已经没有“新计划”可用，但它仍然处于生成模式。尾部爆发循环，本质上是“任务目标已完成但生成信号未终止”的综合表现。所以你会发现，纯粹的“调参解决循环”在短文本里好使，在长文本里效果衰减很快。原因就是长文本循环有结构因素，不是单纯的采样问题。3. 循环检测：从人工肉眼到自动化指标修复循环的前提是能稳定地识别循环。人工肉眼看几千字找重复点，既累又漏。我在实战里把循环检测做成了自动化模块，核心就三招：观察基线、自相似度、熵值监控。3.1 观察基线：先回答四个问题动手写检测代码之前，先人工建立一条观察基线。别嫌麻烦，基线能帮你确定检测参数，避免后面疯狂误报。我每次拿到复现样本，会先回答四个问题：循环单位是什么？是词、句子，还是语义块？单位不同，滑动窗口的 size 就不同。循环周期多长？每隔几句出现一次相似内容？周期决定窗口间隔和比较步长。循环发生在全文哪个位置？开头还是尾部？位置不同，检测启动时机就不同。循环的相似度有多高？是完全雷同还是“神似而形不似”？这决定相似度阈值选多少。这四个问题回答完，检测参数的初值基本就定了。3.2 自相似度检测：滑动窗口与向量化字面重复容易检测，难的是语义循环。我的做法是对文本做滑窗切分，把每个句子或每个固定长度的段落转成向量，然后计算相邻窗口内的平均相似度。相似度连续超过阈值，就判定进入循环区间。向量化不一定要用重型模型。实测下来，用字符级别的 n-gram 特征做 TF-IDF 向量化，对于循环检测已经够用，成本低，跑得快。语义循环有一个特点：即使措辞变了，字符级的共现模式往往还是会留下痕迹，n-gram 能捕捉到大部分情况。3.3 熵值监控：生成质量塌陷的数值征兆第二个信号是熵值。我把生成过程中的 token 对数概率收集出来，逐段计算平均熵。正常情况下，生成内容的熵维持在一定区间；一旦进入循环，模型的概率分布开始高度集中，熵值会明显下降。这个指标的好处是它不依赖语义判断，纯粹看概率分布的形状。适合在服务端流式输出的过程中实时监控，一旦发现连续多个片段的熵低于正常基线，立刻触发预警。熵值监控没法单独作为判据，因为它无法区分“模型在很确定地输出内容”和“模型陷入循环”，需要和自相似度检测配合使用。自相似度负责抓文本结构特征，熵值负责抓概率分布特征，两个信号同时触发才算确认进入循环。3.4 一个可直接复用的循环检测器我把这些手段收敛成一个完整的检测类，核心逻辑是“滑窗自相似度 + 文本熵计算”的二元判断。你可以直接拿去改。import math import numpy as np from typing import List, Tuple from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity class LoopDetector: def __init__( self, window_size: int = 5, similarity_threshold: float = 0.86, entropy_drop_ratio: float = 0.65, min_text_len: int = 200, ): self.window_size = window_size self.similarity_threshold = similarity_threshold self.entropy_drop_ratio = entropy_drop_ratio self.min_text_len = min_text_len self._vectorizer = TfidfVectorizer( analyzer="char_wb", ngram_range=(2, 3), ) def _split_sentences(self, text: str) -> List[str]: parts = [s.strip() for s in text.replace("\n", "。").split("。") if s.strip()] return parts def _window_similarity(self, sentences: List[str]) -> float: if len(sentences) < self.window_size * 2: return 0.0 vectors = self._vectorizer.fit_transform(sentences) max_avg_sim = 0.0 for start in range(0, len(sentences) - self.window_size, self.window_size): window = vectors[start:start + self.window_size] sims = [] for i in range(len(window)): for j in range(i + 1, len(window)): sims.append(cosine_similarity(window[i], window[j])[0][0]) avg_sim = float(np.mean(sims)) if sims else 0.0 max_avg_sim = max(max_avg_sim, avg_sim) return max_avg_sim def _entropy(self, tokens: List[float]) -> float: if not tokens: return 0.0 probs = np.clip(tokens, 1e-12, 1.0) probs = probs / probs.sum() return float(-(probs * np.log(probs)).sum()) def is_looping(self, text: str, token_logprobs: List[float] | None = None) -> Tuple[bool, dict]: if len(text) < self.min_text_len: return False, {"reason": "text_too_short"} sentences = self._split_sentences(text) sim_score = self._window_similarity(sentences) entropy_score = None entropy_flag = False if token_logprobs: # 把一段文字的logprob序列等分成前中后三段，比较稳定段与当前段的熵 third = max(1, len(token_logprobs) // 3) stable_part = token_logprobs[:third] current_part = token_logprobs[-third:] if len(stable_part) >= 2 and len(current_part) >= 2: base_entropy = self._entropy(stable_part) current_entropy = self._entropy(current_part) entropy_score = current_entropy if base_entropy > 0 and current_entropy < base_entropy * self.entropy_drop_ratio: entropy_flag = True sim_flag = sim_score >= self.similarity_threshold # 字面与语义循环以相似度为主，熵值作为辅助强信号 is_loop = sim_flag or (entropy_flag and sim_score >= 0.75) return is_loop, { "similarity": round(sim_score, 4), "entropy": round(entropy_score, 4) if entropy_score else None, "sim_flag": sim_flag, "entropy_flag": entropy_flag, }这个类每次接收一段完整文本和可选的 token 对数概率序列。第一次接入时，建议把相似度阈值从 0.80 开始往上调到 0.90，用你自己的数据校准一遍，避免误报。4. 打破循环的三套打法：参数侧、提示词侧、控制侧检测只是第一步。真正要解决的是“怎么能让模型不再转圈”。我的经验是分三路并行：先动参数快速止血，再改提示词解决结构问题，最后加控制逻辑兜底。4.1 参数侧：先把明显的复读机压下去面对复读机循环，最直接的参数是频次惩罚系数。我通常从 0.3 开始调，复读严重的拉到 0.6 到 1.0。效果非常明显，但我有两条警告：第一，惩罚系数太高会让输出变得呆板。模型为了避免重复，会强行换生僻词，最后通畅度下降。不要在同一个任务上无脑拉满。第二，存在惩罚系数对词句层面的复读帮助相对小，但对“同一个概念反复出现”的语义打转有一定作用。它压制的是“出现即存在感”，能让模型更快放弃旧论点。温度调节要用在正确方向上。复读机循环的处理顺序是：先调频次惩罚，再看是否需要降温度。如果模型在循环时还伴随着逻辑混乱，可以尝试把温度从默认值调低 0.2 到 0.4，让输出更收敛。反过来，如果你在循环里看到的是反复走同一条高概率路径，可以尝试临时加一点温度，让它跳出概率陷阱，但要配合惩罚参数防止跳进新的随机循环。4.2 提示词侧：给生成任务设计“强制出口”参数只能止血，提示词结构才决定循环会不会复发。我的核心心法只有一句话：永远给模型一个明确的“出口信号”。什么叫出口信号？就是提示词里明确写着：什么时候该结束、以什么格式结束、内容边界在哪里、不许重复什么。我在写长文生成提示词时，会明确要求模型按“大纲—分节—总结”的三段结构走，并且强制每节只能写若干个要点，前面章节用过的论点不允许再次出现。实际上，这一步比调参更根本。我把提示词里的格式约束比作“逃逸通道”：模型生成过程中的概率压力再大，都会被这个“必须收尾”的信号及时拽回来。另一个有效技巧是“反驳清单”。在批判性任务里，我要求模型“先列三条支持你结论的证据，再列三条反对你结论的证据，最后再重新给出结论”。这套做法能有效把自我确认循环打断，因为“列出反对证据”这一步，天然就把模型推下了原来的位置。4.3 控制侧：解码约束与后处理兜底参数和提示词都做了，仍然会有漏网之鱼。控制侧就是最后一道防线。我在服务里加了三道闸。第一道是 stop 参数，在生成接口里指定一组终止序列，一旦模型开始输出某些固定的“车轱辘话”，直接截断。第二道是 max_tokens 约束，给每次生成设定合理的上限，避免无界输出。第三道是生成后的循环检测，把第 3 节的 LoopDetector 接在流式输出后面，实时判断输出是否异常，异常就触发重写或降级策略。重写策略我建议这样设计：检测到循环后，不要直接换参数重新生成全文。代价太大，而且可能引入新的偏差。更稳的做法是定位到循环开始的段落，只截取循环之前的内容作为上下文，调整提示词里的补充约束，从循环起点重新生成。实现思路是：保存生成过程中的章节边界，监测到循环后回滚到最后一个有效章节尾，重写该章节。4.4 为什么“只能缓解，不能根除”：概率模型的本质做完了三套打法，我还是要泼一盆冷水：循环问题不存在一劳永逸的解法。因为语言模型本质上是一个概率模型。它的生成过程天然包含自回归的偏差，只要上下文窗口有限，只要 token 的采样概率受历史内容影响，重复路径就永远存在。你不可能“修好”它，只能“管好”它。参数是旋钮，提示词是约束，控制逻辑是护栏，但护栏之内依然可能出现打转的个案。这点认知很重要。很多团队在循环问题上卡壳，不是技术不到位，而是目标定错了：以为要让模型“永不重复”。实际上能做到的是“概率大幅下降 + 异常自动拦截”，只要这两点到位，用户侧基本感知不到，这就已经合格了。5. 项目实战：构建一个带循环守卫的多轮文章生成器讲完方法论，进入实战。我这里分享一个我做过的模拟项目，项目代号叫“带循环守卫的多轮文章生成器”，核心目标是：自动生成一篇 3000 字以上的多章节长文，并且在生成过程中自动检测和修复循环症状。5.1 需求拆解与整体设计先看需求清单。输入是一个主题词和一个大纲列表。输出是包含四个以上章节的完整文章，每个章节至少 600 字。要求是在无人看守的情况下,不出现复读机循环、语义打转和章节间重复。我把它拆成四个模块：大纲规划模块：根据主题生成各章节大纲，并约定每章主题边界。章节生成模块：基于大纲逐章生成内容，每章有独立的出口信号。循环守卫模块：用第 3 节的 LoopDetector 检测每章输出。修复调度模块：检测到循环后，调用重置策略重写对应章节。整体流程是：大纲模块先生成章节列表，然后进入逐章生成循环。每章生成完毕，立即送入循环守卫；守卫判定正常，就把章节内容追加到上下文中，继续下一章；判定异常，就回滚到本章开头，用修复策略重试。重试超过两次仍失败，就把当前章节拆成两个更小的子章节分别生成。5.2 大纲规划模块：先定边界再写正文大纲模块是整个项目的隐性核心。我观察到，循环问题最严重的场景，是模型“不知道本章到底该写什么”。大纲规划模块的作用就是把“模糊的写作主题”转换成“带边界的章节描述”。我给这个模块设计了一个输出格式：每章包含章节标题、核心论点列表、本章禁止出现的论点引用列表。禁止列表是从前面所有章节的论点里抽取出来的，模型在写当前章节时，明确知道自己不该碰哪些内容。这个设计的直接效果就是：从根本上减少了语义层循环的可能。因为循环的本质是“无话可写但必须写”，而禁止列表给了模型一个“不写什么”的明确指引，比“写点什么”更容易约束生成路径。5.3 章节生成模块与循环守卫的联动生成模块本身不复杂，就是按大纲提示词逐章调用模型接口。关键在于它和循环守卫的联动方式。我实现了一个主循环，伪代码如下：def generate_article_resilient(topic: str, outline: dict, detector: LoopDetector, max_retries: int = 2) -> str: context_parts = [] for chapter in outline["chapters"]: chapter_text = None retry_count = 0 while retry_count <= max_retries: prompt = build_chapter_prompt( topic=topic, chapter=chapter, history=context_parts[-3:], # 只带前几章，防止窗口过长 forbidden_points=chapter["forbidden_points"], ) result = call_model_api(prompt) if result.skipped: # 模型判断该章无需展开或内容重复 chapter_text = None break ok, meta = detector.is_looping( result.text, token_logprobs=result.logprobs, ) if not ok: retry_count += 1 # 修复策略：临时提高惩罚系数，并新增一条“不要重复以上论点”的提示 result = retry_with_higher_penalty( prompt=prompt, penalty_increase=0.2 * retry_count, extra_instruction="用全新的例子支撑论点，禁止重复你刚才写过的句子", ) ok, meta = detector.is_looping( result.text, token_logprobs=result.logprobs, ) if ok: break chapter_text = result.text if chapter_text is None: continue # 跳过该章，或降级为纯大纲 context_parts.append(chapter_text) return "\n\n".join(context_parts)这个代码的关键点有三个：第一，上下文只带前几章，不能全量累积。长上下文本身就是尾部循环的诱因，我在实战里会限制 history 不超过三章，再早的内容用大纲模块抽出的论点摘要代表。第二，重试不是无脑重生成，而是“提高惩罚系数 + 追加约束指令”的双重干预。把重试当成一次有导向的微调，成功率比每次都原样重来高很多。第三，模型如果返回“本章内容已被前面覆盖”，我直接接受空章节并跳过。这个设计刚开始我觉得会损失内容，实际测试后发现，它反而是防止章节间语义循环的有效工具。5.4 实测效果对比我跑了一组对比实验。用同一个主题“远程办公工具的发展趋势”，两组配置分别是：普通长文生成，以及带循环守卫的生成。普通配置在生成第三章节时开始重复“远程办公提高了灵活性”，到第五章节出现了连续三段的字面重复，全文最终停在 5000 字左右，实际有效信息大约只有 3000 字。带守卫的配置，第二章节检测到一次语义循环，触发了重试，重试后成功绕开；第四章节再次检测到相似度 0.91 的语义循环，触发二次重试并且采用了“拆章节”降级策略，把原章节拆成两个小章节，最终顺利完成。全文五个章节，整篇没有出现连续重复段落，有效信息密度大幅提升。值得一提的是，守卫启动的两次修复，单次耗时只增加了 15% 到 25%，在可接受范围内。如果完全不做检测，表面上耗时低，但生成结束后还得人工返工，总成本其实高得多。6. 从“打破循环”到“设计循环”：Loop Engineering 的另一半如果只把 Loop Engineering 理解成“除虫”，那就浪费了它另一半的价值。循环不全是坏事，很多有用的能力恰恰要依赖“让模型自己转圈”。6.1 良性循环：迭代自省与多轮修正语言模型单次输出往往有短板，但只要让它“自己检查自己”，结果会有明显改善。我把这个过程看作一个良性循环：生成初稿，对自己打分，找出薄弱点，重新生成，再打分，直到分数达标。关键是要给这个循环一个明确的“进化方向”。我用的方案是让模型输出一组结构化自省意见：逻辑问题、事实风险、冗余内容、表达不足。再把这份意见作为下一轮生成的补充指令。这样每一轮都会真的变好一点点，而不是换个姿势重复。不过要提醒：自省循环有效的前提是初始任务本身有足够的信息可挖掘。如果任务本身信息不足，那自省循环会退化成自我确认循环，越修越偏。解决办法是在循环里加入外部检查点，比如让另一个模型做交叉验证。6.2 带终止条件的循环：哨兵 token 与预算约束设计良性循环时，最容易犯的错是忘记设终止条件。循环没有出口，就是无底洞。我在所有迭代型任务里都会强制加“预算”和“哨兵信号”两道约束。预算很好理解：最大轮数、最大 token 消耗、最大耗时，任何一个超限就强制终止，返回当前最优版本。哨兵信号是指：在提示词里写清楚“当且仅当你认为文本满足以下三个标准时，输出 END”。模型一旦输出 END，整个循环就终止。这两道约束配合使用，等于给循环装了一个自动刹车。我从实践中得到的体会是，良性循环设计里，“如何退出”比“如何进入”更重要。6.3 一个可复用的生成器验收清单最后分享一个我自己整理的多轮生成任务验收清单，拿来即用：[ ] 每轮生成是否都有明确的上下文边界，还是无限累积？[ ] 每轮是否给模型提供了上一轮的客观反馈信号？[ ] 循环内是否有最大轮数、最大 token 消耗的硬性上限？[ ] 是否设置了可识别的终止输出信号（哨兵 token）？[ ] 是否对最终输出做了循环症状检测，而不是只看接口是否成功？[ ] 检测到循环时，是否有预设的修复策略，而不是人工介入？这套清单在新项目上线前过一遍，能拦下大部分隐性循环问题。我做这个项目最大的体会是：和模型打交道，不能幻想它像确定性的代码一样稳定。它更像一个情绪化的写手，写顺了能超常发挥，写僵了会原地转圈。Loop Engineering 的本质就是一套管理“转圈”的机制：承认转圈不可避免，但让转圈变得可见、可控、可终止。把这些机制做扎实之后，模型应用的可信度会有一个质的提升，这也是我在后续所有项目里一直保留循环守卫模块的原因。