Multi-Agentic Software Development Is a Distributed Systems Problem | 海外技术热榜
原文链接
🔗 Multi-Agentic Software Development Is a Distributed Systems Problem
翻译说明
本文翻译自Hacker News最新热门技术文章，内容仅供学习参考，版权归原作者所有。
完整翻译内容
[] 证明维护及其他！ 1. 主页 2. 帖子 多代理软件开发是一个分布式系统问题（AGI 无法将你从这个问题中拯救出来） 最近，我一直在思考用于管理相互协调的法学硕士系统的脚手架和语言——新的编程语言可能是该领域的理想解决方案。 我们有一篇相当有趣的论文正在开发一种有趣的编排语言来描述多代理工作流程——事实证明，编排虽然对于任何实际的分布式协议来说都太弱了，但实际上是一种相当简洁和优雅的形式主义，用于描述代理之间出现的定制交互，特别是如果我们结合博弈论。请留意，我们很快就会分享！ 现在，我不断听到的一个令人讨厌的反馈，甚至是来自其他应该更了解的验证研究人员的反馈，是对事态的一种冷漠，以及对开发管理代理的形式主义和语言的目标的冷漠。最常见的一句话可以概括为：“代理协调的最佳解决方案就是等待几个月。” 这个论点大致总结如下： 1. 当前的多代理 LLM 系统无法自主构建大型软件（同意 ✅）。 2. 这归结为协调问题（同意✅）。 3.下一代模型将更加智能（同意✅）。 4.下一代模型不会出现协调问题(⁇HUH⁇)。 主要含义是构建语言和工具来描述和管理这些系统是一项西西弗斯式的任务；新的模型将不可避免地使它们过时，而整个努力将是徒劳的。 作为一名验证研究人员，我发现这种投降有点不成熟和误导：有大量的分布式系统文献，字面上是关于这个问题的，但人们却忽略了，并且许多不可能性的结果是不变的为能力建模。即使下一个模型是 AGI（笑），协调问题也是一个根本问题，仅靠更聪明的智能体是无法逃脱这个问题的。 在这篇博文中，我想充实这个想法，并将多代理软件开发问题分解为一个正式的模型，并与一些标准分布式系统不可能性结果建立一些联系。无论参与者的 AGI 有多高，分布式共识都是困难的。 软件开发的正式模型 Claude。为我制作一个跟踪食谱的应用程序。不要犯任何错误。 我们可以将多智能体综合问题形式化地建模如下：给定一个提示 (P :=)“(\textit{一个跟踪食谱的应用})”，我们可以将公式 (\Phi(P)) 定义为与提示一致的软件集： [ \Phi(P) := { \phi | \phi ~ \text{程序} ∧ \phi ~\text{与提示一致}~P } ] 关键这里的要点是，自然语言提示就其本质而言是未指定的——即可能有多个与提示一致的程序。当我们使用法学硕士构建和编写软件系统时，我们实际上是要求法学硕士从这组元素中选择一个元素。 相反，当我们进行多代理软件开发时，即我们启动多个代理 (A_1, ⋯, A_n)，并要求它们构建一个软件，我们实际上是要求它们每个生成软件组件 (\phi_1, ⋯, \phi_n) ，以便它们都细化对提示的一个一致的解释： [ C(\phi_1, \cdots, \phi_n) := \exists \phi \in \Phi(P), \forall i, \phi_i \text{refines} \phi ] 换句话说，这只不过是一个大的分布式共识问题。 [] 换句话说，用户的提示 (P) 首先通过计划分割发送到多个代理的任务 (a_1, \cdots, a_n)。然后，这些代理并行工作以实现各自的编码任务 (\phi_1, \cdots, \phi_n)，到最后，如果合成成功，我们希望最终生成的软件系统(\phi)由每个单独的结构(\phi := \phi_1 || \cdots || \phi_n)组成，满足用户的要求。 这本质上是一个共识问题，因为代理 (a_1,\cdots,a_n) 必须同时工作以生成其软件工件 (\phi_1,\cdots,\phi_n)，但要充分沟通并达成共识，确保最终的软件 (\phi_1 || \cdots || \phi_n) 格式良好并满足请求。一个(\phi_i)中的设计决策或选择将导致影响和影响(\phi_j)其他代理的可能选择的约束。例如，如果负责实现网络连接的代理 (a_{\text{network}}) 选择一个具有用于请求的回调式异步 API 的库，那么负责整体集成的代理 (a_{\text{integration}}) 必须围绕该选择组织基础设施，依此类推。其他模块中的类似选择将影响其他代理的设计空间，并且整个过程作为联合综合问题进行。 这真的是分布式共识问题吗？ 当我们完成代理软件开发的正式模型时，在这一点上，我还想花一点时间来驳斥一些明显的反驳。 1. 为什么 (P) 未指定（即不能 (|\Phi(P)| = 1)）？自然语言的本质就是模棱两可的。事实证明，我们确实有办法为软件提供精确且明确的规范。它被称为编程语言。其他任何事情都为代理做出设计决策留下了空间。另一种看待这一问题的方式是，我们可以花一些时间来完善我们的初始提示，以使其不那么不明确，但除非我们一直进行编码（此时，您不会使用多个代理，而只是一个），否则我们的提示将会有一定程度的模糊性。 2. 问题本质上是并发的吗？在软件中投入多个代理的动机系统在某种程度上超出了本文的范围，但是一旦我们做出了决定并且我们有多个代理在处理我们的任务，那么问题本质上就是并发的（无论它们是并行工作还是在单个线程上交错工作），我们必须解决协调问题。 3. 我们不能有一个主管来决定选择吗？为什么不让代理并行提出提案，然后让某种主管来管理将 PR 合并到共享代码库中？不错的尝试！ git repo 是一种尝试协调并行软件开发的相当标准的方法，但是您还没有解决基本的并发问题，充其量您已经将自己硬编码为单一并发选择，而不是一个特别好的并发选择：当选择一个设计决策并将其合并到代码库中时，会发生什么必须重新设置基础的工作？如果有冲突怎么办？有些工作必须丢失。 我在这里想表达的关键点不是你有时不能在忽略并发问题的情况下进行多代理软件开发——显然人们在不退出 Paxos 的情况下使用代理进行软件开发已经取得了一些成功——而是这种观点有助于我们有先见之明地了解如何通过协调工作流程解决这些基本的并发问题。现在，如果你带我出去喝几杯，也许我会更进一步说，如果我们希望多代理软件开发真正实现规模化，那么就必须仔细考虑和回答这些问题。 多代理软件开发的不可能结果 现在我们有了代理软件开发的正式模型，是时候让这篇博文得到回报了！让我们画出一些与分布式系统的联系，并尝试勾勒出一些不可能的结果。 用于多代理系统的 FLP（安全性、活跃性、容错性，选择两个） 当然，除了 FLP 之外我们还能从哪里开始，哦我亲爱的 FLP。费舍尔、林奇和帕特森的开创性论文“通过一个错误过程实现分布式共识的不可能性”建立了一个基本不可能的结果，在任何异步分布式系统（是的！包括我们在内）中规定了共识。 FLP 定理（Fischer et al., 1985）：在任何具有任意消息延迟和至少 1 个节点崩溃故障的可能性的分布式系统中，没有确定性协议可以确保所有非故障节点在有限时间内达成共识。 在我们分解这个定理的含义之前，我想先说明一下 FLP（异步消息、崩溃故障）的假设确实适用于我们的协议： 1. 异步消息 - 向 LLM 传递消息通常是异步的。法学硕士通常负责确定何时读取消息，并且他们可以将其推迟任意长的时间。然而，一个 LLM 代理尝试向另一个 LLM 代理发送消息，无论是通过共享文件系统、通过某些消息传递队列还是任何其他支架，另一个 LLM 看到此消息的时间点通常由另一个 LLM 确定 - 当它完成其推理跟踪时，或者当它正在调用的程序或工具完成时。总的来说，我们无法对消息传递设置限制。 2. 崩溃失败——这需要较少的理由，但特工们非常渴望搬起石头砸自己的脚。在这种情况下，崩溃失败不仅仅意味着进程本身死亡，还可能意味着代理运行一个永远不会终止的工具（即带有意外循环的 bash 脚本等）。其他时候他们可能会自杀。总体而言，特工可能会在未经通知的情况下崩溃。 现在，这对我们意味着什么？特别是，这意味着在任何多代理系统中，无论代理有多聪明，他们都永远无法保证能够同时完成这两件事： - 安全 - 即生成满足用户规范的结构良好的软件。 - 是实时 - 即始终就最终软件模块达成共识。 您可能会对其中的活跃性感到惊讶，因为代理似乎总是在大多数工作流程中取得进展并终止，但这并不意味着他们达成共识 - 事实上，我看到的一种非常常见的模式是一种循环，在设计决策上来回移动，其中一个代理选择一个设计决策，另一个代理恢复更改，选择另一个决策，然后他们循环。 从这个角度来看，另一个有趣的见解是，当我们在共享计算机上运行代理时，我们可能能够比纯粹的崩溃故障模型做得更好一点——特别是运行像 ps | 这样的命令。 grep claude 等可以对应于类似于故障检测器的东西，从中我们可以获得更强的共识范围。特别是，Chandra 和 Toueg 的论文《Reliable Distributed Systems 的 Unreliable Failure Detectors for Reliable Distributed Systems》建立在 FLP 之上，并证明了在 FLP 设置中达成共识是可能的，前提是允许代理访问故障检测器小工具（可能不可靠），该小工具报告其他代理是否仍然存在。如果代理对应于进程，并且进程处于活动状态相当于进度（情况不一定总是如此），那么 ps 可能会给我们类似的东西。因此，从中得出的一个结论可能是为法学硕士提供一种工具来检查其他代理的活跃度。 多代理软件开发的拜占庭将军问题 我想勾勒出第二个不可能性结果的联系，它有点微妙，但仍然值得思考：兰波特的“拜占庭将军问题”。 在分布式系统中，拜占庭节点是一种建模概念，对应于参与者失败的最坏情况假设；而像 FLP 这样的定理假设，当服务器发生故障时，它会崩溃并停止参与协议，拜占庭节点可能会这样做，或者它们可能会做任何事情，即它们可能会偏离协议以任意方式偏离协议，例如伪造来自其他用户的消息、向无意的参与者发送消息，或者重复之前的消息（仅举几个例子）。 拜占庭故障模式真的与多代理软件开发相关吗？虽然这个失败模型有点保守——我们的代理肯定不会主动尝试破坏我们的系统——我认为这个模型在我们的环境中仍然有用，因为拜占庭失败似乎是捕捉“误解”输入提示想法的好方法。出于所有意图和目的，误解提示的代理可以被视为协议中的拜占庭代理，积极对抗试图生成正确软件系统的其他参与者。在这样的代理人面前，我们还能达成共识吗？ 拜占庭将军定理（Lamport-Shostak-Pease，1982）：在任何具有可能任意偏离协议的 (f) 拜占庭代理的同步消息传递系统中，只有当进程总数 (n \gt 3f + 1) 时，诚实进程之间才能达成一致。 具体来说，根据这种解释，如果我们启动 (n) 个代理来实现我们的软件系统，如果超过 (\frac{n - 1}{3}) 个代理误解了提示，那么就不可能达成共识。 Lamport 在论文中提出了一种针对此设置的算法，该算法在较高层面上涉及收集所有参与者的选票并获得多数票。在我们的环境中，集成投票更多的是一种理论构建，也是我们的类比开始有点不成立的地方——软件实现的空间足够大，投票不太可能取得太大进展——但我们仍然可以从这个不可能的结果中获得一些有用的见解。 这里的关键观察是，兰波特的结果对我们可以容忍的软件开发实际上可能的最大误解数量进行了严格限制。这不是什么东西更聪明的代理人或更好的法学硕士将解决这个问题。我们的合成问题本质上是不明确的，因此代理人可能总是会产生误解。从这一分析中得出的一个可行的结论是，虽然我们无法提高我们可以容忍的误解数量，但我们可以通过采用减少误解数量的技术来增加成功的可能性，特别是测试、静态分析和验证等外部验证机制，有效地将误解转化为崩溃失败，而不是继续对自然语言描述的误解，代理可以崩溃，或改进其解释以匹配测试，从中我们可以重用较弱的 FLP结果。 进一步阅读除了 FLP 和拜占庭将军之外，还有一些其他关键的分布式系统结果可能值得在多代理软件开发的背景下考虑，但已为读者留下了精确的链接作为练习:) : - 常识 (Halpern & Moses, 1990) - 本文定义了一个正式模型，用于推理分布式系统内认知知识的流动，并为此类系统中存在常识知识建立了不可能性结果。 - 部分同步（Dwork、Lynch 和 Stockmeyer，1988） — Dwork 等人的部分同步模型是标准的逃生舱口，尽管存在 FLP，仍可提供共识。这项工作的关键技巧是设置消息延迟的上限——在真实的分布式系统中，设备不会无限期地等待消息到达，而是会超时并请求重新发送。通过这种简化，共识可以以增加消息复杂性为代价来解决。 - CAP 定理（Gilbert & Lynch，2002）——当然，如果不参考广受好评的 CAP 定理，任何有关“流行”分布式系统的文章都是不完整的！ CAP 与 FLP 一样，提供了一个不可能的结果，表明任何分布式系统都必须选择e 最多介于一致性（代理对其内部视图达成共识）、可用性（代理最终能够为请求提供服务）和分区容错性（即使网络的某些部分无法访问，代理仍然可以取得进展）中的两个之间。 ² 结论 那么，这给我们带来了什么呢？我通过这篇文章构建的论点是，多代理软件开发从根本上来说是一个分布式系统问题，因此，它继承了文献中的不可能性结果。 FLP定理告诉我们分布式系统不可能同时具备安全性、活跃性和容错性。兰波特的《拜占庭将军》告诉我们，在不可能达成共识之前，拜占庭进程的精确界限。请注意，这些结果都不依赖于代理智能。 重点并不是说多代理软件开发是不可能的——人们今天肯定会通过代理来运送真正的软件，并且明天他们可能会运送更多的垃圾。我的论点更多的是，这些人目前正在通过隐式解决这些协调问题来做到这一点，通常是通过没有经过深思熟虑的保证或故障模式的临时机制。分布式系统文献对所有这些机制都有精确的形式主义，四十年来关于它们可以和不能为您解决什么问题的定理，以及何时何地应应用不同技术的明确规则。 这让我们很好地回到了引言中的引言：“代理协调的最佳解决方案就是等待几个月。”或许。我承认，但即便如此，上面的不可能性结果并不是当前模型能力的暂时产物；它们不会随着智能体变得更加聪明而消失；它们是域的固有属性。更聪明的代理可能会缩小我们算法中的常数，但它们不会、也不可能消除界限。如果我们希望多代理软件开发能够真正扩展，那么迟早有人必须这样做实际上，我们将设计协议、语言和工具作为首要问题来解决潜在的协调问题，而不是希望它会消失。 脚注 1 这并不能完全捕获代理是否确实存在并正在取得进展，因为粗粒度的流程视图无法捕获故障模式，例如代理挂在无限的工具调用中，或者代理已脱轨并完全停止在代码库上工作。 ² 我没有花太多时间考虑与我们的设置的桥梁，但在较高的层面上，我想说，对于代理软件开发，分区容错可能不是必需的。 [] 所有内容均可根据知识共享零许可证 v1.0 获得，除非另有说明 废除版权 ©
翻译声明：本文由AI自动翻译，如有不准确之处欢迎指正
🙏 如果本文对你有帮助，欢迎打赏支持，你的鼓励是我持续输出优质内容的最大动力！ 💴 打赏通道：点击文章末尾「赞赏」按钮即可，每一分支持都是我前进的动力～
