逻辑与搜索分离：AI智能体规模化新路径

将逻辑与推理分离，通过解耦核心工作流与执行策略，能显著提升AI智能体的可扩展性。

从生成式AI原型转向生产级智能体的过程中，可靠性成为关键工程挑战。大语言模型（LLM）本质上是随机的，一个提示词可能首次成功，第二次却失败。为解决这一问题，开发团队通常会将核心业务逻辑包裹在复杂的错误处理循环、重试机制和分支路径中。

这种做法带来了维护难题。定义智能体应做什么的代码，与处理模型不可预测性的代码紧密耦合，难以分离。来自Asari AI、MIT CSAIL和Caltech的研究人员提出，企业要规模化智能体工作流，需要不同的架构标准。

这项研究引入了一种名为概率天使非确定性（PAN）的编程模型，以及名为ENCOMPASS的Python实现。该方法允许开发者编写智能体工作流的“理想路径”，同时将推理时策略（如束搜索或回溯）委托给独立的运行时引擎。这种关注点分离为减少技术债务、提升自动化任务性能提供了潜在路径。

当前的智能体编程方法常混淆两个不同的设计方面。一是核心工作流逻辑，即完成业务任务所需的步骤序列；二是推理时策略，它指导系统如何应对不确定性，例如生成多个草稿或根据标准验证输出。

当这两者结合时，代码库会变得脆弱。实现如“最佳N采样”这样的策略，需要将整个智能体函数包裹在循环中。转向更复杂的策略，如树搜索或精炼，通常需要对智能体代码进行彻底的结构重写。

研究人员认为，这种纠缠限制了实验。如果开发团队想从简单采样切换到束搜索策略以提高准确性，往往必须重新设计应用程序的控制流。这种高实验成本意味着团队常选择次优的可靠性策略，以避免工程开销。

ENCOMPASS框架通过允许程序员使用名为_branchpoint()_的原语在代码中标记“不可靠位置”，来解决这一问题。

这些标记指示LLM调用的位置以及执行可能分叉的地方。开发者编写代码时，假设操作会成功。在运行时，框架解释这些分支点，构建可能执行路径的搜索树。

这种架构实现了作者所称的“程序控制”智能体。与“LLM控制”系统（模型决定整个操作序列）不同，程序控制智能体在代码定义的工作流中运行。LLM仅被调用来执行特定子任务。在企业环境中，这种结构通常更受青睐，因为它比完全自主的智能体具有更高的可预测性和可审计性。

通过将推理策略视为对执行路径的搜索，该框架允许开发者应用不同算法——如深度优先搜索、束搜索或蒙特卡洛树搜索——而无需改变底层业务逻辑。

这种方法的实用性在复杂工作流（如遗留代码迁移）中显而易见。研究人员将该框架应用于Java到Python的翻译智能体。工作流涉及逐文件翻译仓库、生成输入并通过执行验证输出。

在标准Python实现中，为此工作流添加搜索逻辑需要定义状态机。这一过程模糊了业务逻辑，使代码难以阅读或检查。实现束搜索要求程序员将工作流分解为独立步骤，并显式管理变量字典中的状态。

使用提出的框架来提升AI智能体可扩展性，团队通过在LLM调用前插入_branchpoint()_语句实现了相同的搜索策略。核心逻辑保持线性和可读性。研究发现，在文件和方法级别应用束搜索优于更简单的采样策略。

数据表明，分离这些关注点允许更好的扩展规律。性能随推理成本的对数线性提升。最有效的策略——细粒度束搜索——也是使用传统编码方法实现最复杂的策略。

控制推理成本是管理AI项目盈亏的数据官的主要关注点。研究表明，与简单增加反馈循环数量相比，复杂的搜索算法能以更低成本获得更好结果。

在涉及“Reflexion”智能体模式（LLM批评自身输出）的案例研究中，研究人员比较了增加精炼循环数量与使用最佳优先搜索算法的效果。基于搜索的方法实现了与标准精炼方法相当的性能，但每任务成本更低。

这一发现表明，推理策略的选择是成本优化的一个因素。通过外部化这一策略，团队可以调整计算预算与所需准确性之间的平衡，而无需重写应用程序。低风险的内部工具可能使用廉价且贪婪的搜索策略，而面向客户的应用程序可能使用更昂贵且详尽的搜索，所有这些都在同一代码库上运行。

采用这种架构需要开发团队改变对智能体构建的看法。该框架旨在与现有库（如LangChain）协同工作，而非替代它们。它位于堆栈的不同层，管理控制流而非提示工程或工具接口。

然而，这种方法并非没有工程挑战。该框架减少了实现搜索所需的代码，但并未自动化智能体本身的设计。工程师仍需识别分支点的正确位置，并定义可验证的成功指标。

任何搜索能力的有效性依赖于系统对特定路径评分的能力。在代码翻译示例中，系统可以运行单元测试来验证正确性。在更主观的领域，如摘要或创意生成，定义可靠的评分函数仍是瓶颈。

此外，该模型依赖于在分支点复制程序状态的能力。虽然框架处理变量作用域和内存管理，但开发者必须确保外部副作用——如数据库写入或API调用——得到正确管理，以防止搜索过程中的重复操作。

PAN和ENCOMPASS所代表的变化与模块化的更广泛软件工程原则一致。随着智能体工作流成为运营核心，维护它们需要与传统软件相同的严谨性。

将概率逻辑硬编码到业务应用程序中会产生技术债务。它使系统难以测试、审计和升级。将推理策略与工作流逻辑解耦允许两者独立优化。

这种分离也促进了更好的治理。如果特定搜索策略产生幻觉或错误，可以全局调整而无需评估每个智能体的代码库。它简化了AI行为的版本控制，这是受监管行业的要求，其中决策的“方式”与结果同样重要。

研究表明，随着推理时计算规模的扩大，管理执行路径的复杂性将增加。隔离这种复杂性的企业架构可能比允许其渗透到应用层的架构更持久。