Hermes Agent Loop：智能体执行循环的架构拆解与工程实践

发布时间：2026/11/2 12:48:24
Hermes Agent Loop：智能体执行循环的架构拆解与工程实践

1. 为什么智能体必须"跑圈"：从一次问答到持续执行的跨越

去年我接手过一个智能体项目，第一版跑得特别"顺利"——用户问一句，模型答一句，demo 演示时全场鼓掌。结果一上真实场景就露馅了：用户说"帮我查一下本周的销售数据，然后给每个大区经理写一封摘要邮件"，模型直接回了一句"我可以帮你，但请提供销售数据"。当场尬住。原因很简单，我没有给 Agent 设计"执行流程"，只是写了个带工具的聊天机器人。工具存在的意义是让模型能做事，但如果缺少一个循环机制，模型永远停留在"建议你去做"而不是"我替你做完了"。

这就是 Agent Loop 存在的理由。所谓 Hermes Agent Loop，本质上是把一个任务从"单次思考"扩展成"感知-规划-行动-观察-修正-再行动"的闭环过程。智能体不是模型，而是"模型+循环+工具+状态"的组合体。模型提供推理能力，Loop 提供持续逼近目标的能力。我后来把所有 Agent 项目都拆成两半：一半是模型推理，一半是循环编排，而真正决定项目生死的是后者。

1.1 "一次调用"和"一个循环"的本质差别

单次调用就像你给一个实习生布置任务，他听完说"明白了"，然后什么也没干。循环调用像你给他开了一个工位、配好电脑、设了日报机制，让他每一步都提交结果、遇到问题自己查资料、卡住了回来找你确认。AI Agent 要落地，必须有"工位+日报+复盘会"这套循环设施。

从技术上看，一次 LLM 调用的输入输出都是纯文本，它不产生副作用。但 Agent 的执行流程需要副作用：发送 HTTP 请求、读写数据库、执行代码、发送邮件。这些副作用只能发生在循环体里，由编排代码来完成。Hermes Agent Loop 做的就是把这个"副作用执行"和"LLM 决策"粘起来，形成一个可控的、可观测的、能终止的循环。

我个人的理解是：懂 LLM 的人很多，懂提示词的人也很多，但真正缺的是"循环设计"能力——怎么定义状态、怎么决定下一轮要不要继续、怎么让模型从失败中拿回有效信息。这正是我看重 Hermes Agent Loop 的原因：它把循环这个隐性的东西显性化了。

1.2 Hermes Agent Loop 的核心抽象

严格说，Hermes Agent Loop 不是一个产品，而是一套设计模式。它由四个核心组件构成：

  • Loop Scheduler：驱动整个循环的引擎，负责维护运行状态、计数器、终止条件。
  • State Store：保存当前任务进度、历史观测结果、上下文摘要。可以是内存、Redis 或数据库。
  • Action Executor：把模型输出的"动作意图"翻译成真实工具调用，并捕获副作用结果。
  • Termination Policy：决定循环何时停止——任务完成、达到最大步数、超出预算、检测到死循环。

很多团队自己写 Agent 框架，用的都是这套四件套，只是名字不一样。Hermes 做得好的一点是，它把"循环"本身抽象成了一个可编排的实体，而不是散落在业务代码里的 while 循环。每个阶段都有钩子（hook），可以注入日志、监控、缓存、人工审批。

伪代码大概长这样：

class HermesAgentLoop: def __init__(self, model, tools, state_store, policy): self.model = model self.tools = tools self.state = state_store self.policy = policy def run(self, task): self.state.init(task) while not self.policy.should_stop(self.state): observation = self.state.latest_observation() plan = self.model.decide(observation) # 决策 result = self.executor.execute(plan.action) # 行动 self.state.append(result) # 累积观测 return self.state.final_answer()

这里的核心不是 while 循环本身，而是decide和execute之间的信息传递质量。用工程的话说，就是"上下文质量决定循环效率"。

1.3 什么时候不该用 Loop：反模式的边界

聊完必要性，也得泼盆冷水：不是所有场景都该上 Loop。如果任务只需要一次检索加一次生成，没必要让 Agent 跑圈。强行引入循环只会增加成本、放大延迟、引入不确定性。

比如"翻译一句话""给一段文字做摘要"这类任务，单次调用就够了。再比如"对固定格式的文件做字段提取"，用规则引擎或结构化输出比 Agent Loop 更稳。Loop 的适用场景应该是"目标明确但路径不明确"的任务：多步操作、需要外部信息、可能需要纠错的场景。判断标准很简单：如果一条 SQL 能解决的问题，就别搭一个 Agent。

这类经验我踩了不少坑才知道。一开始我把所有需求都"Agent 化"，结果系统变得又慢又贵。后来定了条规矩：先用规则和脚本解决 80% 的确定性问题，剩下的路径不确定性高的才交给 Loop。

2. 六段式执行循环逐层拆解：从意图识别到结果验收

把 Hermes Agent Loop 打开看，一个完整的执行流程可以拆成六个阶段：意图归一化 → 计划编排 → 工具路由 → 动作执行与观测捕获 → 经验反馈与策略修正 → 退出策略。这六个阶段不是每次都要完整跑一遍，而是一个逻辑上的解剖框架，实际执行时可能跳步、回退、并行，但每一轮循环一定涵盖了其中某几个阶段。

2.1 阶段一：意图归一化——把用户的一堆话压成结构化任务

用户输入往往是口语化、模糊、隐含条件的。比如"这个月的报表怎么还没出来？"单看这句话，根本不知道"这个月"是指哪个月份、"报表"是哪张报表、"还没出来"是期望我去催促还是期望我解释延迟原因。意图归一化的目标不是做语义理解，而是把用户输入转成一个结构化任务描述：{task_type: "query_report", parameters: {month: "current", report_name: null}}。

在 Hermes 的设计里，这一步通常由一个低成本的分类器或一个小模型完成，而不是让主模型做。原因是意图归一化属于"确定性较高"的任务，用大模型是浪费。我在实践中会用 few-shot 示例，让模型输出 JSON，然后做 schema 校验。如果校验失败，就进入澄清循环——不是继续跑主循环，而是回退到"追问用户"的微循环。

这里有个容易忽略的细节：意图归一化的结果要写入 State Store，作为后续所有阶段的基础。我见过很多项目在这一步没做状态持久化，导致循环跑了几轮后，早期意图信息被上下文冲掉，Agent 开始"自由发挥"。

2.2 阶段二：计划编排——生成步骤清单而不是直接动手

很多 Agent 框架让模型"想一步做一步"，这在简单任务里没问题，但任务稍微复杂就容易迷失。Hermes Agent Loop 更推荐的做法是：在进入执行前，先生成一个步骤清单，也就是计划。计划不是最终答案，只是一个导航图。

比如用户要求"把销售数据按区域汇总，生成图表，邮件发给管理层"，计划可能是：

  1. 从数据库读取销售明细
  2. 按区域分组聚合
  3. 用图表库生成柱状图
  4. 调邮件服务发送给管理层

这个计划生成的最大好处是：它可以被用户预览和修改。我实际项目中，在计划阶段会做一个"人工确认"钩子，如果用户看到了不合理的计划，可以直接打断。这是很重要的产品逻辑——把 Agent 的"自作主张"风险前置到行动之前。

计划的好坏直接影响后面的步骤数。计划生成得越细，后续循环越短。但也要注意粒度：颗粒度太细会导致计划本身占用的上下文太多；太粗又会失去指导意义。经验值是控制在 3-7 步，超过 7 步应该考虑把任务分解成子任务，而不是硬撑一个长计划。

{ "plan": [ {"step_id": 1, "action": "execute_sql", "args": {"query": "SELECT region, SUM(amount) FROM sales WHERE month = CURRENT_MONTH GROUP BY region"}}, {"step_id": 2, "action": "generate_chart", "args": {"type": "bar", "data": "step_1.result"}}, {"step_id": 3, "action": "send_email", "args": {"attachment": "step_2.result", "to": "managers"}} ] }

2.3 阶段三：工具路由——把动作映射到可执行API

计划里的动作是抽象的，比如"execute_sql"并不等于真的能执行 SQL。工具路由要做的是：从注册表里面找到最匹配的工具，并做参数映射。这个阶段很多时候被模型一步完成了，但 Hermes 推荐显式处理——原因在于工具的数量一旦超过 20 个，模型直接选工具的发生错误率会显著上升。

工具路由常用两种策略：一种是向量检索，用工具名和描述做 embedding，从工具库里召回 Top-K，然后交给模型选；另一种是分类器，把工具归类到有限的几个域里，模型先选域，再选具体工具。后者在工具数量极大（上百个）时更稳定。

参数映射是个硬功夫。模型可能输出"查询上个月的销售数据"，工具期望的参数是start_date和end_date，这中间需要一层转换逻辑。Hermes 的做法是让每个工具声明一个 JSON Schema，然后用一个转换器把模型的自然语言输出映射到 Schema 要求的结构。映射失败时不要静默，要返回明确的错误信息给模型，让模型在下一轮中修正。

2.4 阶段四：动作执行与观测捕获——副作用是核心信息源

动作执行是循环里唯一产生真实世界影响的阶段。这个阶段看起来简单——HTTP 请求发出去、SQL 执行完、结果返回——但实际上最容易翻车。原因很简单：真实世界的响应不会像教科书一样干净。

我在项目里吃过亏：工具返回了 HTTP 200，业务处理失败；数据库查询超时；第三方 API 的响应结构与文档不一致；文件生成了但编码是乱的。这些情况如果执行器不加以处理，会把噪声直接放进下一轮的上下文中，模型就会开始胡说八道。

Hermes 的观测捕获模块有三个要点：一是要捕获"原始观测"，保留工具的原始输出，不能只存摘要；二是要捕获"状态变更"，比如写入了哪个文件、改了哪个表——这类信息后续排查时特别有用；三是要带上"元数据"，如耗时、是否有异常、返回大小。这些元数据应该单独存储，而不是混入模型上下文。混入上下文会把 token 烧光，这个问题后面我会单说。

2.5 阶段五：经验反馈与策略修正——把失败变成下一步的判断依据

循环的精华就在这个阶段。模型看到上一步的观测结果，判断"我离目标近了还是远了"，然后决定下一步怎么做。这一步不同于计划编排：计划是基于初始信息的预判，反馈是基于实际观测的调整。

举一个具体例子：Agent 计划用 SQL 查销售数据，结果 SQL 报错"table not found"。反馈阶段要决定的是——换个表名？还是换个数据库？还是问用户要正确表名？没有反馈机制的话，模型会一次次用同样的错误 SQL 去执行，直到最大步数耗尽。有反馈机制的话，模型会把错误信息当证据进行推理："table not found 可能是表名变化，我先查看有哪些表"。于是下一轮计划就变成SHOW TABLES。

这个阶段设计的好坏，直接决定了 Agent 是否"聪明"。关键要素是为模型提供必要的上下文切换能力，也就是"反思提示"：你把上一步的目标、观测、失败原因简明扼要地喂给模型，而不是把整段历史都倒给它。用大白话说，就是"让模型看简报，而不是看会议纪要全文"。

从工程实现角度，我倾向于把反思做成一个独立的小模型调用，而不是让主循环模型一口气干完。主模型的任务是"决策下一步动作"，反思模型的任务是"从反馈里提炼要点"。两者分工，成本更低，也更稳定。

2.6 阶段六：退出策略——什么时候才算"真的完成"？

循环必须有一个明确的退出条件，否则就是失控。Hermes Agent Loop 里至少有四层退出策略：

  • 目标完成判定：模型输出一个TaskComplete信号，并附上最终答案或产物引用。
  • 最大步数限制：这是安全网，防止模型陷入无限修正。
  • Token 预算限制：如果上下文累计超过预算，强制停止或进入汇总模式。
  • 用户中断：用户点击"停止"，循环立刻终止并保存现场。

其中，"目标完成判定"是最tricky的。模型经常会过早地宣布完成——比如查到了一个中间结果，就把它当成最终答案输出。我在实践中用了一个"完成检查器"：当模型输出 TaskComplete 时，不直接信任，会用一个校验器去检查最终答案是否真的回答了用户的初始任务。校验不通过就打回重做。这一步相当于给 Agent 套上了"质检员"，效果立竿见影。

另外，退出不等于丢弃状态。我习惯在退出前把 State Store 里的重要信息落盘，甚至生成一份"执行摘要"。这样如果用户后续追问，可以直接基于摘要恢复上下文，而不需要重新跑一遍循环。

3. 循环设计里最容易被忽略的三个决策点

前两章讲的是流程，这一章讲的是真正的设计取舍。很多团队照猫画虎搭了一个 Loop，跑起来也能用，但一上生产就崩。原因大多不是流程问题，而是三个隐性的决策点没想清楚。

3.1 状态是"全量重算"还是"增量累积"？—— Memory 的组织方式

每次循环，模型看到的上下文应该是什么？两种做法：一种是把所有历史观测全部塞进去，让模型自行提取信息；另一种是维护一个经过提炼的"状态快照"，只放当前任务的关键信息。

全量重算的优势是实现简单、信息无损耗；劣势是 token 成本线性增长，而且信息量大了之后，模型容易在无关细节上"走神"。增量累积的优势是上下文精炼、每次循环的推理负担小；劣势是需要额外设计和测试，否则可能丢失关键信息。

Hermes 的做法是混合式：保存全量观测用于审计，但每次循环喂给模型的是一份"结构化状态摘要"，包含当前计划进度、最近一次动作的结果、待解决的关键疑问、已经排除的方案。这个摘要由第二阶段或第五阶段生成，长度控制在 500 token 以内。

我强烈建议读者在搭 Loop 时不要偷懒直接拼接历史消息。否则跑到第 10 轮的时候，你会看到模型开始复读历史里的某句话，基本就是上下文过载的信号。

3.2 上下文窗口如何不爆——摘要、裁剪、遗忘策略

哪怕你采用增量累积，经过十几轮工具调用后，上下文依然会膨胀。尤其是工具返回的长文本，比如一个 API 返回了 2000 行 JSON，即便只放一次，也够烧掉一堆 token。更别说循环 20 次。

解决思路有三：

  • 裁剪：设定每个工具结果最多进入上下文 N 个 token，超出部分截断，完整内容存 State Store。模型需要完整数据时可以通过读取文件或者查看状态获取。
  • 摘要：对较长的工具输出先跑一次摘要，把摘要放进上下文。代价是可能丢失细节，所以要在摘要中保留"关键数值"和"错误码"这类容易出问题的地方。
  • 遗忘：明确把某些历史对话和观测标记为"已归档"，不再进入后续上下文。这适用于已经被解决的问题的分支。

我自己的偏好是：优先摘要，其次裁剪，最后才遗忘。遗忘操作要极其谨慎，因为很可能导致模型在下一轮又重新提出一个已经被否决的方案。

这里给一个上下文管理的示例配置：

context_policy: max_tokens_per_observation: 800 summary_model: "fast-small" summarize_if_exceeds: 500 archive_prefix: "[ARCHIVED]" history_window: 8 # 保留最近8轮完整消息

实践下来，这个配置能把整个 Loop 的 token 消耗降低大约 40%，同时保持任务完成率基本不变。当然，数字仅供参考，具体要看你的任务复杂度。

3.3 循环的"刹车"设计——最大步数、token预算、超时熔断

Step limit 是最基础的刹车，但只设 step limit 还不够。很多 Agent 项目的问题是——步数看起来没超，但每步都消耗大量 token，最终费用飙升。所以必须同时设 token 预算和 wall-clock 超时。

三个刹车参数配合起来：

  • max_steps：默认 10，复杂任务可以提到 15，再高就该反思是不是计划分解有问题。
  • max_tokens_per_run：整个 Loop 总 token 消耗上限，比如 50k。达到后触发"强制汇总"模式——不再执行工具，只让模型基于已有信息输出最佳答案或声明失败原因。
  • max_wall_time_seconds：比如 120 秒。这个刹车常用于有用户等待的场景。超时后返回"任务仍在进行中"的中断提示，保存现场，允许后台继续。

刹车触发后的行为也很重要。不要简单粗暴地抛异常，而是把触发原因写入执行日志，并给用户一个"部分结果"——如果拿到了中间数据，也一并展示。这种设计能极大提升产品的容错感。

4. 实测跑 Loop 时踩过的坑与排查链路

理论讲得再漂亮，不如坑来得深刻。下面几个坑是我在多个 Agent 项目里真实踩过的，每一个都花了不少时间排查。我尽量把完整的排查链路写出来，你可以直接照做。

4.1 坑一：Agent 陷入了"假性循环"——工具成功但目标未推进

现象：日志显示 Agent 一直在执行工具，且每次都"成功"。比如它反复查询同一条数据，或者反复调用同一个计算函数。步数在涨，但最终答案迟迟不出来。表面看是模型"卡住了"，实际上是循环的反馈信号不足以让模型判断"当前已经完成"。

我当时排查的第一步是拉出每一步的 Plan 和 Observation 对照。结果发现模型每轮生成的 Plan 几乎一样，都是同一种操作。第二步是检查工具返回的结果，发现每次都返回完全相同的数据。问题出在工具调用被语义缓存命中了，模型以为执行了新的动作，实际拿的是缓存的旧结果。这就导致"观测不到新信息"，修正无从谈起。

修复方案分两层：一是工具执行层，对写操作禁用缓存，读操作缓存要带上时间戳标记；二是循环决策层，在上下文中显式提示模型"你刚才已经获得过该数据，不要重复获取，应该基于数据进行推理"。后者靠提示词能缓解，但根治还是要让 Loop 检测"连续 N 步动作相似且无新增信息量"，触发一次"重定向提示"。

4.2 坑二：模型幻觉出根本不存在的工具参数

这是 Agent 落地最经典的翻车现场。工具 Schema 里明明只有user_id和date_range两个参数，模型却输出了一个user_name字段。结果工具执行时报参数校验错误。正常情况下，模型应该读取错误并修正参数。但很多模型在下一轮会继续幻觉，甚至换一个同样不存在的参数。

排查链路是这样的：先看工具执行器日志，确认异常是 schema 校验失败；再看模型输入的上下文里是否有工具定义被截断或丢失。我遇到的情况是，工具定义太长，被上下文策略裁剪掉了。模型根本看不到工具 Schema，只能靠"记忆"猜测参数，于是开始幻觉。

修复办法：工具定义无论多长，都不要完整截断。如果工具描述超长，就拆成"短描述"和"参数明细"，模型首轮只接收短描述，当它决定调用该工具时，再动态注入完整的参数 Schema。Hermes 管这个叫"按需加载工具定义"。

4.3 坑三：上下文里塞满了没用的日志——观测噪声挤掉关键信息

有一次排查一个 Agent 跑偏的问题：模型开始评论无关数据、引用日志中某个错误码大谈特谈，而用户真正要的答案早就在第 3 步就获得了。看日志发现，前面的工具返回了非常详细的操作日志，里面包含大量的状态码、时间戳、审计信息。这些信息全被塞进了模型上下文，把真正重要的观测结果淹没在噪声里。

排查链路：先对比最终回答与初始任务，确定存在"走偏"；再检查每一步的 Observation 进入上下文前有没有做清洗；最后发现清洗模块遗漏了"日志类输出"的处理。

修复办法：在观测捕获阶段加一个"观测清洗器"，对不同类型的工具输出做差异化处理。SQL 查询结果只保留表头和行数；日志类只保留 ERROR/WARNING 行；搜索引擎结果只要标题和摘要。这个清洗器可以由规则驱动，不需要用模型，成本低且可预期。

4.4 完整排查链路：从日志到回溯再到加断言

给你一个通用的排查流程，适合任何 Loop 异常：

  1. 先确认终止原因：查 Termination Policy 的日志，看是正常完成还是超步数还是超预算。这一步能快速区分"模型问题"和"配置问题"。
  2. 导出运行轨迹：每一轮记录 Plan、Action、Observation、Reflection 四件套。轨迹文件是排查的第一现场。
  3. 定位首个异常点：从后往前看，结果不对找倒数第二步；步数超限找第一步"无效动作"；token 超限找第一个返回超大的工具。
  4. 复现最小案例：把异常点之前的历史截断成最短的"能复现问题"的对话记录，然后用这个 session 单独重跑。这样能排除后续噪声干扰。
  5. 加断言和回归测试：修完后，把这个 case 固化成一个回归测试用例。每次改 Loop 配置都要跑一遍回归集。

这套流程在我团队里已经成了标准操作。效果就是：排查一个 Loop 问题的时间从三天缩短到半天，而且修完的问题基本不会复发。

5. 让 Loop 跑得更稳更省：工程优化经验

最后讲一讲我在生产环境里沉淀下来的优化手段。目标很朴素：稳定性和成本不能只靠"模型更强"，要从架构层面抠。

5.1 用"廉价模型"做路由和反思，用"昂贵模型"做最终决策

不是所有环节都需要顶级模型。我现在的分层是：

  • 意图归一化、工具路由、上下文摘要：用 fast 小模型。这些任务结构清晰、误差容忍度高，小模型完全够用。
  • 计划编排、策略修正：用中档模型。这两部分需要一定推理能力，但不需要最强模型。
  • 最终答案生成、复杂多步推理：用旗舰模型。只有到达这一步才值得付出高成本。

这个分层的收益非常直观：一个 20 步的 Loop 中，可能只有 2-3 步用到旗舰模型，其余都由小模型完成。整体成本能降 60%-70%，而完成率只下降几个百分点。关键在于不要让小模型做它做不了的判断——如果小模型对某个工具路由的置信度低，就把这个 case 升级给大模型。

5.2 工具结果缓存与结果指纹：避免重复执行

工具调用是有副作用的，重复执行既浪费钱还可能产生重复副作用。我做了两层防护：

  • 结果指纹：每次执行工具前，把工具名+参数+当前状态摘要hash成一个指纹，如果指纹和之前的某次执行一致，直接返回缓存结果并标记"cached"。同时要注意缓存的有效期，尤其是数据类工具。
  • 幂等设计：写操作（发邮件、改数据库）尽量设计成幂等，或者至少带上 request_id，避免网络重试造成重复执行。

在 Loop 内部，这个机制能显著减少无效步数。比如模型反复查询相同的数据时，第二次直接命中缓存，观测依然是有效的新信息，但成本已经省下来了。

5.3 并行子任务的扇出与收敛

复杂计划往往包含多个相互独立的步骤。比如"分别查询销售、库存、客户数据，然后汇总分析"。如果一条路走到底，串行执行会非常慢。Hermes Agent Loop 支持"扇出-收敛"模式：把计划中的独立步骤分成多个子任务，并行执行，等所有子任务返回后再聚合成新的上下文。

扇出时需要注意三个问题：

  • 上下文隔离：每个子任务只看到它需要的观测，不要互相污染。
  • 结果收敛：子任务返回后，需要有一个收敛器把多份结果整合成一份摘要，再喂给主模型。收敛器可以由小模型完成。
  • 失败传播：某个子任务失败不一定要终止整个 Loop，可以标记为"部分失败"，在主任务里决定是重试还是忽略还是降级处理。

我实际用的聚合逻辑是：并发度控制在 3-5，超过 5 会导致工具 API 被限流；每个子任务带独立 step 限制，防止某个子任务把整体步数耗尽。

5.4 让 Loop 可观测：结构化日志、追踪 ID、断点续跑

最后一个建议可能不性但非常实用——Agent Loop 必须面向调试设计。LLM 的不确定性意味着你永远不会知道下一秒会发生什么，所以你要确保"发生了什么"能被完整记录。

我的做法是：

  • 为每次运行分配一个 trace_id，所有日志、工具调用、token 消耗都绑上这个 ID。这样用户反馈一个坏 case 后，你可以一条命令拉出完整的运行轨迹。
  • 记录每一步的 token 消耗。不只是总 token，明细到"模型输入 token 用了多少，工具输出 token 用了多少"。这样你能发现哪个环节是吞 token 大户，针对性优化。
  • 支持断点续跑。当循环被预算中断或用户中断后，把 State Store 序列化保存。用户说"继续"时，从断点恢复，而不是从零重跑。这个体验对长任务非常关键。

一个可观测的 Loop 和一个不可观测的 Loop，维护成本差距是十倍。我见过太多项目线上出问题后只能"盲猜"，因为日志只有 final answer 没有中间过程。所以我的原则：宁可多花一点时间在日志设计上，也不要在出问题时抓瞎。

说到底，Hermes Agent Loop 不是什么高深的技术，它就是把"让 AI 做成一件事"这件事工程化。你不需要一开始就实现所有优化，但至少要理解执行流程的每个环节为什么存在。先让循环跑起来，再逐步加刹车、加缓存、加可观测性。等你在真实业务里跑过几十个任务之后，你对"Agent 该如何被编排"的理解，会比读任何框架源码都深。

最后分享一个我自己的小技巧：在 Loop 的每个阶段末尾都加上一个phase_comment字段，让模型用不超过 50 个字总结"这一步干了什么、发现了什么"。这个技巧一开始只是为了日志，后来我发现它还能强制模型整理思路——相当于给循环里的每一轮都做了一次 mini 总结，跑偏概率显著下降。难受的地方在于要稍微多花一点 token，但对比踩坑成本，这绝对值得。