第七章 搜索运行

一口气走完的路，最容易走错

假设你要做一次数据库迁移，让 AI 写完整的迁移脚本。AI 一口气输出了三百行：建表、迁移、校验、回滚，结构漂亮，注释齐全。

执行到一半，脚本挂了。排查发现，开头的一处假设就错了：它假定旧表的某个字段永远非空，而线上数据里有大量空值。后续步骤全都建立在这个错误假设之上，逻辑自洽，却无法运行。

换一种用法。还是同一个模型，但这次要求：先给出迁移计划，分六步；每执行一步，先在测试库上跑一遍，把结果贴回来，确认无误再生成下一步的脚本。

这次过程慢得多，但每一步的脚本都落在了真实数据的地面上。第一步就暴露了一个字符集问题：如果按上次的方式一口气写完，这个问题会在第几步爆发，谁也说不准。

同样的模型、同样的任务，初始化、目标、空间都可以做得一样充分，差别落在“怎么走”。

为什么走法本身，就能决定搜索的成败？

默认的搜索是开环的

前三层——初始化、目标、空间——塑造的都是搜索开始之前的东西：起跑状态、评判尺子、可及范围。而第四层搜索运行（Search Runtime）处理的是搜索真正展开的过程：一步一步，怎么走。

第二章已经揭示过这个过程的默认形态：每一步只看“下一步是否合理”，沿概率最高的方向向前延伸。用控制系统的语言说，默认的搜索运行是开环的：从起点到终点，中间没有任何环节把“走得对不对”的信号送回来。三百行脚本正是开环的产物：第一步的错误没有被任何环节拦截，后面的每一步都在忠实地放大它。

运行层的各种机制，都在做同一件事：给开环的搜索装上闭环。反馈、反思和验证负责纠偏，遍历和并行负责组织路径，停止条件负责提供出口。

遍历：先走哪条，后走哪条

一个常被忽略的事实是，搜索的顺序会改变搜索的结果。

同一个复杂任务，“一口气做完”和“先做最简单的部分、再逐步升级”（Least-to-Most），得到的不是同一个答案的快慢版本，而是质量不同的两个答案。原因在于第四章的原理：搜索的初始状态决定后续轨迹——而在一次多步骤的搜索里，先完成的部分，会变成后续部分的初始状态。第一步走对了，后续搜索的初始状态就更可靠；第一步埋了错误，错误就进入之后每一步的初始状态。

搜索遍历（Traversal）就是对搜索顺序的主动设计：把复杂任务拆开，并按“让每一步都为下一步铺路”的原则排序。“先制定计划，再执行”（Plan-and-Execute）是最常见的遍历操作——它把“想清楚顺序”本身变成了搜索的第一步。脚本案例里的分六步，就是一次遍历设计。

纠偏的三种机制：环境、自己、标准

开环搜索最缺的是“走得对不对”的信号。这个信号有三个来源，对应三种机制。

反馈：让环境参与搜索

搜索反馈（Feedback）是在搜索过程中接收环境发出的信号：调用工具查最新文档、执行代码看报错、读 API 的真实返回、查数据库的真实内容。ReAct（推理与行动交替）就是这类机制的代表：想一步，做一步，看一步，再想下一步。

反馈的价值在于：它把不依赖 AI 自身判断的环境信号接入搜索。第二章说过，搜索路径上的每一步都在概率空间里自洽——错误也能自洽。但环境不讲自洽：字段里有空值就是有，测试红了就是红了。脚本案例里“每步在测试库上先跑一遍”，就是把环境信号接进了搜索回路。

反思：让搜索回头看自己

搜索反思（Reflection）是让 AI 在途中停下来，重新评价自己已经走出的路径：这段推理有没有漏洞？结论和最初的假设矛盾吗？审查、自我批评都属于这一类。

它针对的正是第二章的那个结构性弱点：搜索的每一步只看局部合理，没有一个环节负责回头审视整条路。反思把这个缺失的环节显式地补成了一次搜索：“检查刚才的推导”本身，就是一次以“找漏洞”为目标的新搜索。

但反思有一个天生的局限：检查者和被检查者是同一套认知。带着同一个偏置走岔的路，很可能带着同一个偏置通过复查。所以反思适合拦截粗心的错误，拦不住系统性的盲区。

验证：把结果交给外部标准

搜索验证（Verification）通常是更可靠的纠偏机制：不只接受搜索自己的判断，而是把结果交给一个相对独立的外部标准——单元测试、事实核对、基准评测、数据比对。

反思和验证的差别值得停顿一下。反思问的是“我觉得我对吗”，验证问的是“客观标准认为我对吗”。前者仍在认知空间内部，后者把锚点抛到了空间之外。这就是为什么 AI Coding 的质变发生在“能跑测试”之后：从那一刻起，代码的对错不再由生成它的搜索说了算。

三种机制的配合原则是优先接入可检查的外部信号；反馈和验证不足时，再用反思补位。不同机制的可靠性取决于具体环境，不能只靠其中一种。

停止条件：闭环的出口

闭环还需要一个出口：什么时候结束搜索。

停止条件（Stopping Criteria）回答的就是这个问题。它和第五章的成功标准是一对容易混淆的概念：成功标准定义“什么算完成”，属于目标层；停止条件管“什么时候终止”，属于运行层。两者的差别在止损时才看得最清楚：成功标准告诉你终点长什么样，停止条件告诉你走不到终点时怎么办。

没有停止条件的闭环会变成死循环：验证失败，修正，再验证，再失败，无限重试。一条设计良好的停止条件应该是双向的：达标则停，止损也停。“连续两次验证失败，就放弃当前路径，退回起点换一条根本不同的路线”——这句话里没有新技巧，但它防止了搜索在一条死路上耗尽所有预算。

多车道：并行搜索与角色分工

至此讨论的都是一条轨迹的走法。运行层还有另一类机制：同时铺开多条轨迹。

并行搜索（Parallel Search）让多个方向同时推进：几个执行单元各自独立搜索，再交叉比对。第二章的自洽性方法就是最朴素的并行——它的价值不在速度，而在独立性：互不污染的轨迹可以暴露分歧，也更容易发现共同成立的部分。辩论（Debate）则是另一种并行：让两条轨迹故意走向对立，用对抗把双方盲区逼出来。

当并行的各条轨迹不再是同一条搜索的复制，而是各自承担不同职责时，Workflow 和 Agent 这两个工程概念就出现了。

Workflow（工作流）是把一套被验证有效的运行结构固化下来：先规划、再执行、再验证、失败回退——也就是搜索编排。脚本案例里“分六步、每步先测”的流程一旦被固定，就成了一个 Workflow 的雏形。

Agent（智能体）是承担特定搜索职责的执行单元：一个负责规划，一个负责编码，一个负责验证，一个负责反思。注意这个定义的关键：Agent 的本质是职责，不是能力。规划 Agent 和验证 Agent 背后可以是同一个模型，区分它们的不是“谁更聪明”，而是各自在搜索系统里负责的位置不同。

Workflow 和 Agent 的具体形式放到本书第四篇展开。本章只需记住它们在四层模型里的位置：它们是运行层的机制，解决的是“搜索怎么走”的问题。

运行层的全貌

如果说前三层决定了一次搜索“能产出什么”，运行层决定的是“实际产出什么”。它最直接体现工程设计：初始化、目标、空间的操作大多发生在提问的那一刻，而运行层的机制贯穿搜索展开的全过程。AI 应用从“问答”走向“干活”时，很多复杂性也由此出现。

运行层还需要一个监督视角。搜索运行回答“搜索怎样推进”，包括如何遍历、接收反馈、验证、纠偏和停止；搜索运行治理则判断当前过程是否仍应这样继续，必要时要求验证、回退、分叉、重新初始化、独立审查或停止。它不构成第五层，而是对第四层运行状态的观察与干预。

在 Agent 系统中，Harness 是搜索运行治理的一种工程实现。它根据可记录的信号工作，例如工具调用、验证结果、重试次数、已排除方向和成本。动作重复本身不等于搜索失控；只有重复同时伴随没有新信息、没有重新评估路径或风险上升时，才需要干预。

可以这样记住三者的关系：搜索运行决定“搜索怎样走”，搜索运行治理判断“这条路还该不该这样走”，Harness 把这种判断落实为运行时的门禁和动作。

Prompt 映射

常见做法	所属机制	作用
先制定计划，再分步执行	遍历	让每一步为下一步铺路
先做最简单的部分，逐步升级	遍历	用简单部分校准后续搜索的初始状态
边写代码边运行测试，根据报错修正	反馈	把环境信号接入搜索回路
调用工具查询最新资料后再作答	反馈	用环境事实修正先验中过时的知识
完成后自我审查，找出漏洞	反思	补上“回头看整条路”的环节
逐条核对事实、运行单元测试	验证	用外部标准判定结果
多个执行单元独立作答，再交叉比对	并行	用独立轨迹的交汇处定位答案
连续两次失败就放弃当前路径	停止条件	防止在死路上耗尽预算

空间层的操作多是“提问技巧”，一句话就能完成；运行层的操作则更接近“流程设计”，需要跑测试、读报错和多角色交叉，也需要环境与工具配合。因此，运行层的实践常会落到 Workflow 和 Agent 上。

项目案例

回到这个迁移场景。第二种走法跑通之后，可以把它固化成标准流程，并明确每个环节的归属：迁移先出计划，步骤按“风险从低到高”排序；每一步先在测试库执行，把真实输出贴回对话；完成后进行行数比对、抽样校验和业务侧冒烟检查；计划执行前，再让 AI 预审最可能失败的环节。任一步骤连续验证失败，就停止执行并回滚，重新评估方案。

这套流程沿用下来，同类事故会明显减少。用法也随之变化：规划、预审、执行、验证，渐渐可以由不同的会话来承担——同一个模型，不同的职责分工。不需要读过 Agent 的教程，也会逐渐形成多角色的搜索分工。

这个案例说明，模型没有更换，前三层的设定也没有明显变化，改变的是搜索的走法，以及走法固化后形成的职责分工。

容易混淆

“反馈不就是验证吗”

发生的位置不同。反馈在过程中接收环境信号，修正搜索轨迹；验证在节点上对一段产出做判定，决定它能否继续。

“并行就是为了更快”

并行的首要价值是独立性。几条互不污染的轨迹同时搜索，有助于暴露分歧并相互校验；如果几条轨迹共享同一套偏置，再快也只是把同一个错误复制几份。

本章总结

本章从一个开环搜索的失败开始：早期的错误假设没有被及时发现，后续步骤便不断放大它。默认的搜索运行缺少把“走得对不对”送回来的环节。

运行层的机制都在给开环装上闭环：遍历安排搜索顺序，反馈接入环境信号，反思检查已经走过的路径，验证引入外部标准，停止条件规定达标或止损时退出，并行以及由此固化的 Workflow 与 Agent 则让多条轨迹分工推进。

回到本章最后一个问题：

本章讨论的，是搜索系统的哪一部分？

答案是：四层模型的第四层，搜索运行。一次认知搜索的四层至此完整：从什么状态起跑（初始化），为了什么而搜（目标），能去哪些地方（空间），以及怎样推进、校正和停止（运行）。

真实项目也不只进行一次搜索，而是持续发生大量搜索。项目做得越久，AI 的表现为什么越依赖那些被长期维护的东西？多次搜索之间到底发生了什么？这是第三篇的主题，我们从下一章的问题开始：为什么长期项目会“失忆”？

章节信息

• 所属篇目：第二篇 · 一次认知搜索
• 本章回答的核心问题：它改变了搜索系统哪一部分？——四层模型的第四层：搜索运行，核心主线是把开环搜索改造成闭环（遍历定顺序，反馈/反思/验证三级纠偏，停止条件守出口，并行与分工扩展车道）