详细内容或原文请订阅后点击阅览
代理线束工程
本文最初发表于 Addy Osmani 的博客上。经作者许可，将其转发至此处。粗略地说：每当您发现代理犯了错误时，您都会花时间设计解决方案，以便代理不再犯同样的错误。过去两年我们一直在争论模型。哪一个是 [...]
来源:O'Reilly Media _AI & ML本文最初发表于 Addy Osmani 的博客上。经作者许可，将其转发至此处。
粗略地说：每当您发现代理犯了错误时，您都会花时间设计解决方案，以便代理不再犯同样的错误。
过去两年我们一直在争论模型。哪一位最聪明，哪一位写的 React 最干净，哪一位产生的幻觉更少。就目前而言，该对话还不错，但它缺少系统的另一半。该模型是运行代理的输入之一。剩下的就是工具：提示、工具、上下文策略、挂钩、沙箱、子代理、反馈循环和围绕模型的恢复路径，以便它实际上可以完成某些事情。
一个好的模型加上一个好的安全带会打败一个好的模型但一个坏的安全带。我在自己的作品中一遍又一遍地看到这种情况的发生。越来越有趣的工程不在于选择模型，而在于选择模型。这是在设计围绕它的脚手架。
该学科现在有了一个名字。 Viv Trivedy 创造了“线束工程”这个术语，他的“代理线束剖析”文章是对线束实际是什么以及每个部分存在的原因的最清晰的推导。Dex Horthy 一直在跟踪这种模式的出现。HumanLayer 将大多数代理故障归结为“技能问题”，归结为配置而不是模型权重。Anthropic 的工程团队发布了我认为是关于如何为长期运行的工作设计线束的最佳公开细分。 Birgitta Böckeler 从用户角度很好地概述了这是什么样的。
这篇文章是我尝试将这些线索整合在一起的尝试。
安全带到底是什么？
Viv 的一句台词完成了大部分工作：
特工 = 模型 + 挽具。如果你不是模特，那么你就是安全带。
线束是除模型本身之外的每一段代码、配置和执行逻辑。原始模型不是代理。一旦线束赋予它状态、工具执行、反馈循环和可执行约束，它就变成了一个。