第七章 搜索运行

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

一个团队要做数据库迁移，让 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（工作流）是把一套被验证有效的运行结构固化下来：先规划、再执行、再验证、失败回退——也就是搜索编排。脚本案例里"分六步、每步先测"的流程一旦被固定，就成了一个 Workflow 的雏形。

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

Workflow 和 Agent 都值得用整章展开，本书第四篇会回来专门处理。本章只需要记住它们在四层模型里的位置：它们是运行层的机制，解决的是"搜索怎么走"的问题。

运行层的全貌

如果说前三层决定了一次搜索"能产出什么"，运行层决定的是"实际产出什么"。它也是最"工程化"的一层：初始化、目标、空间的操作大多发生在提问的那一刻，而运行层的机制发生在搜索展开的全过程——这正是 AI 应用从"问答"走向"干活"时，投入最集中的一层。

Prompt 映射

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

注意这张表和前面各章的一个差别：空间层的操作是"提问技巧"，一个人一句话就能完成；运行层的操作很多是"流程设计"——跑测试、读报错、多角色交叉——需要环境和工具的配合。这就是为什么运行层的实践，最终都长成了 Workflow 和 Agent 的形态。

项目案例

回到开头的数据库迁移团队。第二次尝试成功后，他们没有就此打住，而是把这次的经验固化成了一套标准的迁移协作流程，并且明确了每个环节的归属：

遍历：任何迁移先出计划，步骤按"风险从低到高"排序，低风险步骤先验证环境假设。反馈：每一步脚本先在测试库执行，真实输出贴回对话，确认后再继续。验证：迁移完成不等于结束，必须跑完行数比对、抽样校验和业务侧冒烟三个检查项。反思：计划执行前，让 AI 以"找出这个计划最可能失败的两处"为目标做一次预审。停止条件：任何步骤验证失败两次，停止执行，回滚已做步骤，重新评估方案，禁止第三次硬试。

三个月后，这套流程执行了十一次迁移，零事故。更有意思的是团队的用法悄悄变了：规划、预审、执行、验证，渐渐由不同的会话来承担——同一个模型，不同的职责分工。他们没有读过任何 Agent 的教程，但一个多角色的搜索系统已经自发成形了。

这个案例是运行层最好的注脚：模型从头到尾没有换，前三层的设定也没有大变，变化的只是搜索的走法——以及走法被固化之后，自然生长出的分工。

容易混淆

"反馈不就是验证吗"

发生的位置不同。反馈在过程中——边走边接收环境信号，修正的是轨迹；验证在节点上——对一段产出做判定，决定它能不能过关。导航仪和安检门的区别。

"并行就是为了更快"

并行的首要价值是独立性。几条互不污染的轨迹同时搜索，交汇处往往最接近稳固的答案；如果几条轨迹共享同一套偏置，再快也只是把同一个错误复制了几份。

本章总结

本章从一个典型的失败开始：一口气写完的三百行脚本，第十七行的错误假设被后面每一行忠实放大——默认的搜索运行是开环的，没有任何环节把"走得对不对"送回来。

运行层的机制都在给开环装上闭环：遍历设计搜索的顺序，让每一步为下一步铺路；反馈接入环境的信号，反思让搜索回头看整条路，验证把结果交给外部标准，三者可靠性递增；停止条件守住闭环的出口，达标则停，止损也停；并行及其固化形态——Workflow 与 Agent——让多条轨迹分工推进。

现在，回答每章都要回答的那个问题：

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

答案是：四层模型的第四层——搜索运行。至此，一次认知搜索的四层全部走完：从什么状态起跑（初始化），为了什么而搜（目标），能去哪些地方（空间），怎样走完全程（运行）。

但真实的项目从来不只是一次搜索，而是成百上千次搜索的连续。为什么项目做得越久，AI 的表现越依赖那些被长期维护的东西？多次搜索之间到底发生了什么？这是第三篇的主题，我们从下一章的问题开始：为什么长期项目越来越依赖上下文？

官网连载说明：全书共五篇十八章，本站当前开放前两篇。第三至五篇——长期认知搜索、统一 AI 工程、实践——将在本站陆续更新。本书也在公众号"咏歌与凯旋"同步连载，欢迎关注、留言交流。

章节信息

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