来自 Viv（@Vtrivedy10）的推文线程

通过开放式问题构建智能体驾驭心智模型 简而言之： - 代理的简化视图，它是一个具有特定任务框架和模型选择的系统 - 线束内的模型不可互换。它们的智能特性不稳定，因此“升级”到新模型需要更多的工作。 我们所谓的“通用”代理/工具实际上是“我愿意花在定制上的时间”和任务性能之间的一种权衡。 - 线束工程中一个令人兴奋的领域是自主优化（元提示、模板化、dspy 等）。 先决条件： 我们来考虑一个智能体“有用的工作单元”，并将其称为任务。 问题： 问题 1：是否存在“通用”的代理框架？我指的是那种能够帮助解决足够广泛的任务，而无需进行大量额外工程开发的框架。可以想象一下“我们直接使用 Claude Code 的基础框架”这种框架。 问题 2：什么是“存在”？例如，如果我没有针对我的任务对工具进行超优化，我会损失多少性能？ 问题 3：一个“即时生成任务框架”的世界会是什么样子？我们希望解决“我想要极佳的任务性能”和“我希望花合理的时间来优化我的任务框架”这两个问题。 随想： 这和什么类似？ 工具框架不等同于提示，但其理念与 @DSPyOSS（Miprov2、GEPA 等）类似。我们希望针对我们的任务（提示、工具设计、子代理定义、有用上下文）同时且理想情况下自主地优化工具框架的各个组件。 模型不可互换： 模型不应该与其框架分离，它们是相互依赖的！我们真正关心的是任务性能，所以我们需要为该任务设计一个模型+框架组合。例如：如果你在做软件工程，你其实并不关心OCR的提示、工具和模型基准测试。 我们今天要做的事情： 实际公司中的任务通常具有相似的“模式”：类似的输入、类似的预期输出、类似的中间步骤。因此，我们要么将该任务转化为工作流，要么编写一个非常具体的工具和代理来完成该任务。 梦想： 但现实世界中真实用户的需求变化极大。因此，理想的情况是，当任务到来时，能够立即生成一个代理，配备针对该任务的超特定工具、指令、成功标准和智能分析。目前，要做到这一点可能还需要人工干预，但我们可能会看到越来越多的代理能够引导其他代理使用。这正是“代理构建器”公司应该投入所有资源的方向，最终的赢家将在这方面做到极致。 其中一些内容或许更适合写在博客里，但还是有必要分享出来。现在安全带很流行，大家都在努力让它们易于制造，并且……对各自的领域都非常有用。