企业官网建设流程全解析

如果你用过带工具调用的 AI 编程助手，大概率见过这种场面：任务明明只是把某个服务的连接超时参数抽成配置，模型却反复在仓库里搜来搜去，读完这个文件读那个文件，隔三差五跑一遍测试，日志滚了好几屏，diff 却一直没动静。这种状态圈子里现在有个挺形象的说法——工具空转。它跟死机不一样，模型还在运转，工具调用还在产生，token 还在烧，但任务本身没有任何实质推进。MiniMax-Code 这一阵子在社区里被讨论得比较多，其中一个被反复提到的点，就是它在缓解工具空转上的表现。

我自己的日常里，带 Agent 写代码已经不是尝鲜，而是正经的生产工具。但“空转”一直是我最头疼的隐性成本：看起来模型很忙，实际产出为零，你还得盯着它别把仓库搞乱。这篇文章把我对 MiniMax-Code 处理空转问题的理解、我自己做过的对比测试、以及接入后踩过的坑都整理出来，希望给同样被空转折磨的读者一点可复用的经验。

1. 先还原空转现场：一次“忙了20分钟，仓库没有任何改动”的真实会话

1.1 空转不是死锁：它在转，但没往前走

最开始我遇到这类问题时，第一反应是“模型卡住了”。后来把日志拉出来看才发现，它根本不算卡：工具调用一个接一个，每个都有返回值，状态机也在推进。你真要说它死锁了，它还不承认，因为它确实在不停做事。

区别在于：死锁是“什么都没有发生”，空转是“发生了一堆事情，但没有一件在推动任务终点”。为了量化这件事，我给自己定了一个“有效推进”的定义：

• 有效 diff 是否在增长（改动的代码是否越来越接近最终形态）；
• 测试结果是否从红变绿，或者从无关失败变成目标失败；
• 任务计划里的里程碑是否在逐个完成。

如果这三样在 10 个工具调用之后没有任何变化，那基本可以判定为空转。空转最坑的地方在于它不会自己停下来，因为它每一步都觉得自己在“探索”，只是探索永远没有收敛到决策上。

1.2 我见过的三种空转形态

空转不是一种形态，至少我抓到过三种，它们的触发机制不太一样，修复思路也不一样。

搜索型空转。模型反复调 grep、搜索、检索类工具，但搜完之后不读全文，或者读了全文不下判断。典型的会话长这样：

[agent] 任务：给 HttpCli 增加连接超时配置，默认 5 秒 [1] tool_call: search_workspace(query="HttpCli") [2] tool_call: read_file(path="src/http/cli.rs") [3] tool_call: search_workspace(query="HttpCli 调用点") [4] tool_call: read_file(path="src/http/mod.rs") [5] tool_call: search_workspace(query="connect_timeout") [6] tool_call: read_file(path="src/config/loader.rs") [7] tool_call: search_workspace(query="timeout")

从第 5 步开始就已经进入循环：它搜了一个关键词，读了一个文件，发现信息不够，又去搜下一个关键词。每一步单独看都合理，连起来看就是没有目标感的“翻箱倒柜”。正常做法应该是先明确“我需要哪个文件的哪个符号、它的调用链是什么”，然后有目的性地抓取，而不是大海捞针一样把相关词汇全部扫一遍。

验证型空转。这种更常见，也更消耗时间。模型改了一行代码，立刻跑一次测试；测试失败，它不看失败原因，先再改一行，再跑。同样一个 lint 检查，它能因为格式问题来回跑五六次。我见过最夸张的一次，模型为了修复一个未使用变量的 warning，连续跑了 11 次构建，每次构建耗时 40 秒，最后只是删了一行。

确认型空转。这类空转藏得最深——模型前面已经读过某个文件，但因为上下文太长、注意力被稀释，后面忘了，于是重新读一遍，读完发现“哦，这个我之前看过了”，然后又去读另一个已经被读过的文件。整个行为像一个人失忆之后反复确认自己有没有锁门，每次确认都消耗时间，但确认结果并不能改变他已经锁了门的事实。

这三种形态经常叠加出现，尤其是在仓库规模超过两万行、任务又涉及多个模块时。而空转一旦开始，本身还会制造更多空转：模型读了越来越多的工具返回结果，上下文越来越长，注意力越来越散，于是它更倾向于再去调工具“确认一下”。这是一个自增强的恶性循环。

2. 空转的根因：工具调用被当成了“外挂大脑”，而题面没有进模型

2.1 没有题面，就只能反复“翻厨房”

要理解空转为什么发生，得先理解模型内部发生的决策过程。一个合格的编码 Agent 拿到任务后，应该在内部先建立一个“题面”：要改什么、约束是什么、验收标准是什么、需要哪些外部证据。题面越清晰，工具调用的目的性越强。

但很多情况下，模型并没有在内部把题面建起来。它只是知道“用户让我改超时配置”，至于超时配置在哪、默认值怎么定义、有没有现成的配置入口，它一概不知道。于是它只能靠工具去环境里试探，搜一下、读一下、再搜一下。这与一个没有菜谱的人进了厨房很像：他不知道要做什么菜，只能不停开冰箱、开柜子、翻调料，每一步都在获取信息，但永远凑不齐做菜需要的那组信息，因为他一开始就没定义“什么才算信息够了”。

工具在这里成了“外挂大脑”——模型不先在内部做推理，而是直接把推理外包给工具。结果就是工具的每一次调用都在采集信息，但信息没有进入决策闭环。这本质上不是工具的问题，是任务分解和目标定义的问题：模型没有把“未知清单”列出来，自然也就不知道搜到什么程度可以停。

2.2 触发阈值太低：证据还没攒够就出手

我长时间观察 Agent 日志后得出一个结论：空转最直接的技术原因是工具调用的触发阈值设得太低。模型对“我是否真的需要调用工具”这件事的判断，在大多数场景下过于宽松。只要上下文里出现了一点点不确定性，模型就倾向于调工具去查。

打个比方，你问一个人“你家的门锁了吗”，正常人会先回忆自己出门时有没有锁门的动作——这个回忆过程是内部推理，不需要外部证据。只有当你完全想不起来时，才会折回去看门。但很多 Agent 的行为是：一被问到锁门，立刻跑回去看，看完回来，过五分钟再问，又跑回去看。它把“内部推理可以解决的不确定性”和“必须外部验证的不确定性”混为一谈，全部交给了工具。

正确的做法是在调用工具之前先做一次内部推理。MiniMax-Code 这一代模型给我的感觉是，它在训练和 Agent 框架层面都强化了这个习惯：先问“当前上下文里有没有我需要的答案”，如果答案在上下文里，就禁止自己调工具；只有当上下文确实缺失关键证据时，才允许发起工具调用，而且最好是“一次调用把需要的证据取齐”，而不是查一点推一点。

2.3 上下文膨胀：越查越乱，越乱越查

这是空转最容易被忽视的放大器。工具调用会产生大量返回结果：读文件返回整个文件内容，跑测试返回几百行日志，搜索返回一串文件路径。这些东西全部塞进上下文之后，模型的有效注意力会被严重稀释。

有一个很直观的体验：同一个文件，如果它是在 20 个工具调用之前读的，当模型需要引用它里面的某个符号时，它可能已经记不清了。于是它会再调一次 read_file。每次重新读取，上下文变得更长，注意力被稀释得更厉害，下一次就更记不住。这个循环一旦启动，就在 token 消耗和空转次数两个维度上同时爆炸。

这也是为什么单纯给 Agent 更大的上下文窗口并不能解决空转。窗口越大，模型越容易把已经读过的内容“遗忘”在窗口深处，然后靠重复读取来补偿。真正有效的方案是控制进入上下文的工具结果质量——该压缩的压缩，该摘要的摘要，别让原始日志和整文件内容无差别地堆积。

3. MiniMax-Code 的解题思路：把工具调用从“自由行动”改成“预算审批”

我对 MiniMax-Code 处理空转的理解，核心可以概括成一句话：它把工具调用从“模型的自由行动”变成了“经过审批的支出”。就像企业内部采购要过预算审批一样，工具调用不再由模型拍脑袋决定，而是由任务计划、置信度、收敛信号三方面共同把关。这是我在社区讨论和公开演示里看到的做法，也是这一代编码 Agent 的通用设计方向。

3.1 规划先行：工具调用被挂到任务里程碑上

MiniMax-Code 在拿到任务后，第一步不是急着调用工具，而是先做任务分解，产出一个带里程碑的计划。每个里程碑都明确了“需要什么输入、产出什么结果、如何验收”。工具调用被严格挂在某个里程碑的“输入证据”需求上——只有某个里程碑确实缺少外部证据时，对应的工具才会被批准调用。

这与我前面说的“题面”是同一个思路，但更结构化。举个例子，同样是“给 HTTP 客户端加超时配置”的任务，一个合理的里程碑规划可能是：

1. 定位 HTTP 客户端的构造入口（需要证据：调用链）；
2. 确认现有配置体系（需要证据：配置加载代码）；
3. 设计超时参数的默认值来源（不需要工具，内部推理即可）；
4. 实现修改（需要证据：目标文件当前内容）；
5. 补充测试并验证（需要证据：测试运行结果）。

注意第 3 步。很多空转发生在这一步：模型本来可以直接在内部推理“默认值应该来自配置文件，还是代码常量”，却非要再去搜一圈别的项目里的超时参数写法。规划先行之后，这类无目的探索会被直接拦掉，因为这一步的里程碑里没有定义任何外部证据需求。

3.2 置信度门控：不确定才查，查完立刻回到主线

第二个关键设计是置信度门控。模型在决定是否调用工具之前，先做一次“证据检查”：当前上下文里是否已经存在我需要的答案？如果存在，直接使用；如果不存在，明确列出缺什么，然后发起一次有目标性的工具调用。

这个机制直接针对我前文说的“触发阈值过低”问题。你可以把它理解成一道闸门：只有在“上下文确实没有该信息”的情况下，闸门才打开。更重要的是，它要求模型“查完立刻回到主线”——工具返回结果后，模型必须先把它压缩、合并进当前的任务上下文，然后继续执行里程碑，而不是让这次工具调用的结果引发新的一轮探索。

我在日志里观察到，传统 Agent 经常在工具返回后“跑题”：读了一个文件，发现里面提到了另一个模块，于是顺手去读那个模块，再读那个模块的依赖，最后彻底忘了主线。置信度门控的意义就是切断这条“探索链”，确保每次工具调用都服务于当前里程碑，而不是服务于模型的好奇心。

3.3 收敛信号与早停：给“试探”设上限

空转最容易发生在“试错”阶段：模型改了一个方案，测试失败，换成另一个方案，又失败，再换回去。MiniMax-Code 的做法是给试探设上限。当一个方案连续失败达到一定次数时，它不再继续换方案，而是主动回退到最近一个稳定状态，重新审视计划。

这个“早停”机制非常关键。很多空转的本质是模型在“撞南墙不回头”——它已经用了三次不同的改法，测试失败原因都一样，说明问题根本不在它改的那几行代码，而是它的假设本身错了。此时正确的动作不是继续改，而是停下来重新读错误，或者干脆人工介入。

早停的另一个触发点是“验收信号”。当任务计划里的所有验收项都满足时，模型主动终止，不再去做额外的验证、额外的搜索、额外的“保险性检查”。这一点上很多 Agent 做得很差——任务已经完成了，diff 也对了，测试也过了，它还要再跑两遍测试，再读一遍变更文件确认。MiniMax-Code 给我的感觉是它对“完成”的判定更果断，验收过了就收工。

3.4 工具结果压缩：别让日志撑爆上下文

光有门控还不够，因为工具返回的结果本身就可能成为下一轮空转的诱因。MiniMax-Code 在工具结果回填上下文之前做了压缩和摘要处理：读文件返回的不是整个文件的原始内容，而是按任务相关性抽取的符号定义、关键结构；跑测试返回的不是完整日志，而是“失败用例 + 关键报错行”。这样一来，上下文里留下的都是高密度信息，模型的注意力不会被一堆无关日志稀释。

这一步是整个解决方案里最不起眼但最决定成败的一环。我前文提到过，上下文膨胀会反过来加重空转，而工具结果压缩就是直接在源头切断这个放大器。它的效果我可以用一个很朴素的体验来说明：用同一个模型跑同一个任务，开压缩时它的工具调用数量大概是关闭压缩时的三分之一，而且中途几乎不会出现“重新读取已读文件”的情况。

4. 我拉出来的几组实测：工具调用次数、耗时与返工率的变化

光讲原理不够，我自己在本地拉了两组测试。因为没有官方基准那么严谨，我把它当作“参考数据”来看，但趋势是足够说明问题的。

4.1 两个测试任务的设置

我选了两种有代表性的任务跑在同一套工具集上，工具集包含搜索、读文件、编辑、跑测试四项，接入方式保持一致，不修改任何工具的原始定义。

• 任务 A：给一个约 2 万行的 Python 服务加上 HTTP 客户端的连接超时配置，默认值 5 秒，要求从环境变量读取，并补一个单元测试。
• 任务 B：定位并修复一个偶发空指针异常。异常只在并发请求下出现，仓库里没有直接的复现用例，需要先读并发调度代码再判断。

任务 A 偏“增量修改”，任务 B 偏“定位排查”。这两种任务恰好是空转的重灾区。

4.2 数据对比与空转率计算

我把会话日志里的工具调用全部导出来，按类型统计。对比对象是同系列基础模型（未启用完整 Agent 调度优化）和 MiniMax-Code 的 Agent 模式，下表是我统计到的中位数数据：

我还算了一个“空转率”指标，定义是(工具调用总次数 - 有效推进次数) / 工具调用总次数。有效推进指该次调用直接产出了里程碑产物（比如定位到了关键符号、完成了代码修改、让测试从红变绿）。任务 A 里基础 Agent 的空转率大约 63%，MiniMax-Code 是 36%；任务 B 更夸张，基础 Agent 空转率接近 71%，MiniMax-Code 是 42%。

4.3 数据背后的几个观察

有几个数字值得展开说。第一是“首次产出有效 diff 的时间”。这个指标比总耗时更能反映空转：基础 Agent 在任务 A 里花了 6 分钟才产出第一版修改，而这 6 分钟里它已经调了 20 多次工具，全在搜索和读文件。MiniMax-Code 只花了 2 分钟，因为它在规划阶段就把不需要的证据需求砍掉了。

第二是“跑测试次数”。基础 Agent 在任务 B 里跑了 9 次测试，但真正有效的只有最后 2 次——前面 7 次都是在同一个错误上反复试探不同改法。MiniMax-Code 跑 4 次测试就定位到了并发调度的根因，区别在于它每次跑测试之前都会先读测试失败日志，并且把“失败原因是否与当前改动相关”纳入判断——不相关就不继续折腾。

第三是“人工返工次数”。这个指标最能体现空转的隐性代价。基础 Agent 提交的代码经常只解决了表面症状，没有触及根因，导致我review 的时候要再改一遍。MiniMax-Code 的提交里，任务 A 直接可用，任务 B 有一处边界条件没处理好需要补一下，但整体完成度明显高一个档次。我的体感是，空转率降下来之后，产出质量和完成度也跟着上来了，因为模型的注意力没有被浪费在无意义的探索上。

5. 接入之后容易踩的坑：工具定义、超时参数和人工接管时机

MiniMax-Code 不是万能的。如果你自己的 Agent 框架、工具配置、提示词写得离谱，再好的模型也会给你演出空转。这几个月我自己就在这些地方栽过跟头，整理出来给各位排雷。

5.1 工具 description 写得太“宽”，门控就失效了

置信度门控的前提是模型能准确判断“哪个工具能提供我缺的证据”。如果你的工具 description 写得过于宽泛，模型就会把大量不相干的需求都路由到这个工具上，门控直接失效。

举个我改过的例子。最初的搜索工具描述长这样：

作用：在代码库中搜索文本，返回匹配的文件和行号。

问题在于“搜索文本”这个表述太宽了。模型遇到“我想知道这个函数在哪里被调用”也会用它，遇到“我想知道超时配置在哪个文件”也会用它，遇到“我想确认这个变量是不是空的”还会用它。其中只有第一种是该用搜索的，后两种应该靠读文件或内部推理。我把描述改成：

作用：精确查找符号定义或引用位置。仅当你知道目标标识符（函数名、类名、变量名）且只需要知道它出现的位置时使用。 不要在需要理解语义、比较多个文件、查找配置来源时使用。需要理解代码含义时，使用 read_file 并指定行号范围。

改完之后，同一任务里搜索类工具的调用次数立刻降了一半。这个改造背后的逻辑很简单：工具描述其实是在替模型做“工具选择预判”，描述越精确，模型的预判越准，门控才有意义。

5.2 超时和重试：不是越大越小越好

工具空转还有一个隐蔽来源是超时参数配错。我见过两种情况：

• 超时设太短：某个工具实际需要 3 秒返回，你设了 1 秒超时。结果工具被中断，Agent 认为调用失败，触发重试，重试又超时，连续三四次。不仅空转，还白白浪费了工具的执行成本。
• 超时设太长：一个卡死的工具调用会阻塞整个 Agent 循环十五分钟，这期间模型既不能继续也不能放弃，本质上也是一种空转。

我现在的做法是先做一次基线测量：把每个工具单独跑 20 次，记录 P50 和 P95 的响应时间。超时时间设在 P95 的 2 倍左右，而不是拍脑袋定一个值。重试策略也做了区分：只读类工具可以重试，写操作类工具（编辑文件、跑构建）禁止自动重试，必须回到计划层面重新评估，否则极易出现“同一个 edit 提交两次”的混乱。

5.3 什么时候该打断它：空转的三个早期信号

即使 MiniMax-Code 已经把空转率降了一半，你还是得学会识别空转的早期信号，在它演变成灾难之前人工打断。我自己的判断标准是三条，命中任意一条就立刻停止执行：

• 同一个工具在连续 5 个调用里出现 3 次以上，且中间没有产出任何有效 diff；
• 测试失败原因与前一次完全一样，但模型改了不同的代码；
• 当前 diff 内容回到过某个历史状态，说明模型在“改来改去”而不是“往前推进”。

打断时不要只说“停下来”，那样模型会懵。我常用的指令是：“你现在在重复调用 search 工具，先停一下。回头读你前 10 条消息里 read_file 的返回内容，基于这些内容直接告诉我你需要什么信息，我来确认。”把模型拉回内部推理轨道，而不是让它继续用工具试探。

5.4 我在 prompt 里加的“验收标准”，意外地管用

最后分享一个我自己的小技巧，它不花任何成本，但效果显著。我在每个任务的开头显式加一段“验收标准”，三行左右：

任务完成的标准： 1. HTTP 客户端构造处已接入连接超时参数，默认 5 秒； 2. 参数可从环境变量 HTTP_CONNECT_TIMEOUT 读取； 3. 新增测试覆盖“未设置环境变量时使用默认值”的场景，且测试通过。

起初我加这段只是为了让输出更可控，没想到它对空转的抑制效果出奇地好。原因也不难理解：模型在内部建“题面”的时候，如果没有验收标准，它自己也不知道“做到什么程度算完成”，于是只能无限探索；给了三条明确标准之后，它的每个里程碑都有了截止线，搜索、读文件、跑测试都围绕这三条标准展开，自然就不容易跑偏。这其实就是 MiniMax-Code “收敛信号与早停”理念的提示词版本，可以跟它的内置机制形成互补。

6. 个人体会：省下的不是 token，是“等待时的焦虑”

用了这一段时间之后，我最大的体会是：工具空转真正可怕的地方不在于多烧了多少 token，而在于它消耗的是你对 Agent 的信任。当模型第一次在你面前滚了十五分钟工具调用却没有产出时，你就再也不敢放手让它干活了，最后又退化回自己手写代码。那才是最大的损失。

MiniMax-Code 让我重新愿意把任务交出去，核心原因就是它的空转率肉眼可见地低，我盯屏幕的压力小了很多。我不太关心它内部到底是哪种机制的组合起了决定性作用——是规划先行、置信度门控还是早停，说实在的我也没法把这几个变量的贡献精确拆开。但从工程视角看，只要“有效推进占比”上去了，可预测性就上来了，我就可以更放心地在它跑任务时去干别的事，而不是在终端前面干等。

如果你也想做同样的优化，我建议不要只换模型。先把上面第五部分说的工具描述、超时基线、验收标准这三件事做掉，你会发现空转率本来就会降一截，再换上规划更严格的 Agent 框架，效果会叠加。工具空转是个系统问题，不是一个模型能单枪匹马解决的，但好的模型可以把这个问题从“每天都在发生”变成“偶尔发生”，这就够了。