打开几乎任何AI产品，你都会发现角落里的同一个下拉菜单。在你能够完成任何工作之前，你有一个任务：选择一个模型。或许还要决定它应该思考多少。选择很重要。一个模型可能在追踪困难的错误方面表现出色，但在设计上却表现得异常糟糕。另一个模型可以制作出漂亮的界面，但在长时间的构建中可能会失去重点。然后，一个新模型上线，排名再次变化，或者价格发生变化。称某个模型为“最佳”假设前沿有一个王冠。但实际上并没有。如果选择模型会影响你的应用程序是否有效，那么在工作开始之前，你就不应该凭空猜测会选对。对于Lovable而言，这就是模型独立性的意义。我们不会将模型视为可互换的。我们是模型独立的，因为我们对它们有深刻的看法。模型独立，而非模型无差别。模型无差别意味着将每个模型放在同一个接口后面，给予它相同的指令，并用另一个名称替换。真正的模型独立意味着了解每个模型的最佳工作方式。我们在Lovable有一个专门负责这项工作的团队。对于每个模型，他们围绕其最佳工作方式来调整指令、工具和项目环境。他们研究模型在哪些地方会卡住，无论是在长时间的调试循环中、在配置后端时、在打磨界面时，还是在完全不同的地方。然后他们跨完整构建测试整个设置。例如，在其中一次评估中，一个前沿模型的任务完成速度比其前身快15%，所需回合少40%，得分高出2-3%。这些是有意义的提升，使新模型在当时成为更强的选择。我们可以在让一个模型在Lovable内表现良好上下重金投入，并在有更好的选择出现时继续前进。可移植性给予我们这种自由，而不必扔掉我们对模型表现差异的理解。控制平面是产品“向我的应用添加支付”听起来像是一个指令。在Lovable内部，该请求会启动一个应用构建代理。该代理将构建从您的请求携带到一个工作更改，并对沿途发现的任何事物做出反应。它必须理解您的意思，找到项目的相关部分，规划更改，编写代码，运行应用，并查看它是否有效。如果有什么问题，正确的恢复路径并不总是显而易见的。系统应该重试、更改计划、使用另一工具、引入一种不同推理的模型，还是问您一个问题？答案取决于构建沿途的发现。一个简单的请求可能会揭示一个架构问题。或者第一次尝试可能表明模型理解了目标，但在某个工具上遇到困难。这就是为什么控制平面会观察工作的展开：你尝试做什么，任务变得多么困难，以及代理是否在取得进展还是开始兜圈。控制平面随后可以将构建的不同部分分配给不同的模型，而不是要求一个模型负责整个事情。控制平面还会围绕模型调整系统。在一次评估中，一个模型不断重新读取已经在上下文中的文件，并在成功编辑后再次检查它们。我们给它不同的指令：信任上下文，信任编辑结果，并跳过冗余的工具调用。我们还可能更改工具、如何解释它们、模型看到的项目上下文量，以及在下一轮之前如何总结一个长时间的构建。这不是模型轮盘赌。我们不会将相同的提示通过五个模型并选择我们最喜欢的回应。我们会给予每个模型适合它的指令、工具和上下文，然后判断应用是否变得更好。独立并不意味着不断切换。在构建过程中更换模型可能会使情况变得更糟，因为一个长期运行的项目会积累历史。代理已经探索了文件，尝试了方法，遇到了错误，并了解了重要的是什么。模型只是那个代理的一部分。当模型改变时，我们可能不得不压缩该历史并重建其缓存上下文。某些对话的细节可能仅作为总结存留。这意味着一个模型在孤立状态下可能更好，但仍可能不是当前构建的正确选择。我们的控制平面必须权衡可能的收益与我们可能失去的上下文和可能重复的工作。目标不是尽可能频繁地切换模型。一次有用的切换必须值得其成本。否则，我们只是在制造模型的波动。决定是否切换始于了解系统失败的原因。有时，应用构建代理通过通风工具直接告诉我们，浮现出本来难以看到的问题。如果模型提供者超负荷，Lovable可以通过另一个提供者将下一个调用发送给相同的模型。这可以解决可用性问题，但解决的不是糟糕的方法。如果上下文错误，工具令人困惑，或者模型误解了任务，切换提供者则放弃了缓存而不解决故障。使用 u 进行重试...