如何通过分离逻辑和搜索来扩展人工智能代理的性能

将逻辑推理与逻辑推理分离可以提高性能。 AI代理可扩展性 通过将核心工作流程与执行策略解耦。

从生成式人工智能原型到生产级智能体的过渡引入了一个特殊的工程难题： 可靠性逻辑逻辑模块（LLM）本质上是随机的。一次有效的提示可能在第二次尝试时失败。为了缓解这个问题，开发团队通常会将核心业务逻辑封装在复杂的错误处理循环、重试机制和分支路径中。

这种方法会造成维护问题。定义代理应该做什么的代码与定义如何处理模型不可预测性的代码密不可分地混杂在一起。研究人员提出了一种新的框架。 阿萨里人工智能， 麻省理工学院计算机科学与人工智能实验室， 和 加州理工学院 这表明需要采用不同的架构标准才能实现规模化。 代理工作流程 在企业中。

该研究引入了一种名为 概率天使非决定论（PAN） 以及一个名为 安康帕斯这种方法允许开发者编写智能体工作流程的“正常路径”，同时将推理时策略（例如束搜索或回溯）交给单独的运行时引擎处理。这种关注点分离为减少技术债务、同时提升自动化任务的性能提供了一种潜在途径。

智能体设计中的纠缠问题

当前智能体编程方法常常将两个截然不同的设计方面混为一谈。第一个方面是…… 核心工作流逻辑或者说，完成一项业务任务所需的步骤顺序。第二个是…… 推理时间策略这决定了系统如何应对不确定性，例如生成多个草稿或根据评分标准验证输出。

当这些方法结合起来时，最终的代码库会变得脆弱。实现诸如“N 选一”采样之类的策略需要将整个智能体函数封装在一个循环中。而采用更复杂的策略，例如树搜索或优化，通常需要对智能体的代码进行彻底的结构重写。

研究人员认为，这种纠缠限制了实验的开展。如果开发团队想要从简单的采样策略切换到波束搜索策略以提高精度，他们通常必须重新设计应用程序的控制流程。

实验成本高昂，导致团队为了避免工程开销，常常选择次优的可靠性策略。

将逻辑与搜索解耦以提升 AI 代理的可扩展性

ENCOMPASS 框架通过允许程序员标记来解决这个问题。 “不可靠地点” 在他们的代码中使用了一个名为“primitive”的原始方法 分支点()。

这些标记指示 LLM 调用发生的位置以及执行可能出现分歧的地方。开发者编写代码时假定操作一定会成功。运行时，框架会解释这些分支点，以构建一个包含所有可能执行路径的搜索树。

这种架构能够实现作者们所说的 “程序控制”代理与“LLM-in-control”系统（其中模型决定整个操作顺序）不同，程序控制代理在代码定义的流程中运行。LLM 仅在执行特定子任务时才会被调用。与完全自主的代理相比，这种结构具有更高的可预测性和可审计性，因此在企业环境中通常更受欢迎。

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

对遗留系统迁移和代码转换的影响

这种方法的实用性在复杂的流程中显而易见，例如遗留代码迁移。研究人员将该框架应用于…… Java 到 Python 翻译代理工作流程包括逐个文​​件翻译存储库，生成输入，并通过执行验证输出。

在标准的 Python 实现中，向此工作流程添加搜索逻辑需要定义一个状态机。这个过程会掩盖业务逻辑，并使代码难以阅读和检查。实现束搜索则要求程序员将工作流程分解为各个步骤，并通过变量字典显式地管理状态。

利用所提出的框架来提高人工智能代理的可扩展性，该团队通过插入以下元素实现了相同的搜索策略： 分支点() 在 LLM 调用之前添加语句。核心逻辑保持线性且易于阅读。研究发现，在文件和方法级别应用束搜索优于更简单的采样策略。

数据表明，将这些问题分开考虑可以实现更好的扩展规律。性能随推理成本的对数呈线性提升。

已发现的最有效策略—— 精细波束搜索 ——这也是使用传统编码方法实现起来最复杂的功能。

成本效益和性能扩展

控制推理成本是负责人工智能项目损益的数据管理人员的首要关注点。研究表明，复杂的搜索算法可能会产生 以更低的成本获得更好的结果 与简单地增加反馈回路的数量相比。

在一项涉及“反思”代理模式（其中 LLM 对其自身输出进行批判）的案例研究中，研究人员比较了增加优化循环次数与使用最佳优先搜索算法的效果。基于搜索的方法在性能上与标准优化方法相当，但成本更高。 降低每项任务的成本。

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

采用这种架构需要开发团队改变对代理构建的看法。该框架旨在与现有库协同工作，例如： 朗链它并非取代现有功能，而是位于堆栈的不同层级，负责管理控制流，而不是提示工程或工具接口。

工程挑战与考量

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

任何搜索功能的有效性都取决于系统的能力。 为特定路径得分在代码翻译示例中，系统可以运行单元测试来验证其正确性。但在诸如摘要或创意生成等更为主观的领域，定义可靠的评分函数仍然是一个瓶颈。

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

对人工智能代理可扩展性的影响

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

将概率逻辑硬编码到业务应用程序中会造成以下问题： 技术债务这使得系统难以测试、审计和升级。将推理策略与工作流逻辑解耦，可以对两者进行独立优化。

这种分离也有助于更好地进行治理。如果某种特定的搜索策略产生幻觉或错误，可以全局调整该策略，而无需评估每个代理的代码库。这简化了人工智能行为的版本控制，这对于受监管的行业至关重要，因为在这些行业中，决策的“方式”与结果同样重要。

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