上下文工程还不够 - 循环内没有法学硕士的循环工程实验

每个人都在谈论循环工程,但大多数讨论都假设法学硕士位于循环的中心。我想隔离架构本身。因此,我构建了一个确定性的、零依赖的 Python 基准测试,用简单的规则替换模型,使我能够直接衡量一个问题:目标导向控制器能否比传统线性管道更好地隔离故障?在验证了 300 个随机种子的基准测试并修复了一个最初使我自己的结果无效的微妙错误之后,我发现控制器始终完成了线性执行器从未达到的独立分支。本文介绍了架构、基准测试设计、调试过程以及一个狭隘但实用的主张背后的证据:故障隔离是控制流的一个可测量属性,与 LLM 推理无关。后语境工程还不够——循环内没有 LLM 的循环工程实验首先出现在《走向数据科学》上。

来源:走向数据科学

范围:这不是代理框架相互竞争的基准,也不声称该控制器“更智能”。它声称一些更狭隘、更站得住脚的东西:故障隔离是一个真实的、可测量的架构属性。

它是一种模式,而不是产品:循环工程是一种控制流模式,而不是特定的框架。它的概念是用一个观察状态并朝着目标行动的迭代系统取代单个巨大的提示。

为验证而构建:为了证明这种机制而不是相信它,我构建了一个目标导向控制器的小型确定性实现。它需要零个 LLM 调用,并且具有零外部依赖性。

可测量的故障隔离:虽然线性一次性管道在第一个未解决的障碍上完全停止,但该控制器将故障隔离到包含故障的特定分支。在 300 个随机种子中,控制器平均完成 10.3 个独立分支中的 3.3 个,而线性基线仅完成 0.4 个。

彻底的透明度:在相信这些数字之前,我实际上发现并修复了自己的基准测试逻辑中的一个真正的错误,并且我正在详细地解决该错误,而不是隐藏它。

无缘无故停止的管道

几个月前,我看到任务处理管道在四十步中的第三步崩溃了。

第三步需要一个我尚未设置的配置值。由于这个单一的缺失值,下游的所有东西都死了。其中包括三十多个与丢失的配置完全无关的步骤。

这项工作本身并非不可能。该系统崩溃只是因为管道没有概念能力跳过损坏的分支并继续移动其他分支。

我写这篇文章是为了解决完全位于提示之上的层。这是代理系统的一部分,用于管理状态并在步骤成功、失败或卡住后确定下一步行动。在人工智能工程界,人们称之为循环工程。

资源