重新思考智能体的软件供应链
近期一项MIT研究报告指出，仅有约5%的生成式AI应用正在创造真实、可衡量的商业价值。在我看来，这并非雄心壮志的失败。恰恰相反，大多数团队都在积极进行实验。问题在于，我们用来交付软件的基础系统尚未适应AI的本质。
构建原型或演示已变得异常容易。只需稍作提示词调整，调用一次API，你就能展示出令人印象深刻的东西。但将那个原型转化为你可以在生产环境中信赖的东西，则是另一项挑战。这需要真正的工程：可靠性、一致性、版本控制、监控和防护栏。问题是，我们多年来依赖的工具和工作流从未被设计用来支持行为会随时间变化的系统。
持续集成/持续交付（CI/CD）管道是为测试代码而构建的。它们回答诸如以下问题：
- 这个函数是否返回预期结果？
- 应用程序是否能干净地部署？
但AI系统和代理的行为并不像静态代码。它们的行为可能因上下文、数据和提示词而变化。因此，真正的问题变成了：即使条件发生变化，这个系统能否做出我们信任的决策？
在本文中，我将探讨一些能帮助我们构建成功的软件供应链方案的思路。
重新思考软件供应链
我们需要接受这样一个事实：我们多年来构建和交付软件的方式，已不再适合这个充满智能、代理用例的世界。
如今，CI/CD管道专注于检查代码是否能工作，但对于代理系统，重点在于理解代理如何在复杂环境中行为、适应和做出决策。
为了实现这一点，我们的软件供应链需要超越持续集成，并进化为持续传递关于所构建和交付软件的智能。在新管道中，每一步都需要确保我们正在学习和评估代理，以建立更多信任。
我们需要将软件供应链视为一个活生生的系统，它能不断学习、改进，并随其支持的产品一同演进。
从持续集成演进到持续智能
我们在代理时代对于CI的目标已经改变。
- 从：“这份代码是否足够好到可以合并？”
- 到：“这种智能能否被信任以可靠地行动？”
从持续集成到持续智能的转变，改变了我们构建和信任软件的方式。软件交付管道本是为检查代码是否正确运行而设计，但代理系统要求我们验证系统在现实世界、不可预测条件下的行为。
大型语言模型（LLMs）具有非确定性，其结果不可预测，但当我们在演进软件时，我们需要确保其行为持续改进。因此，挑战在于确保基于非确定性的软件的可靠性和一致性。
作为软件创造社区，我们需要演进我们的持续集成管道，使其能为我们提供可靠性，并帮助我们确认软件随着时间的推移仍保持可靠。
EVAL评估是新的单元测试
在代理系统的世界里，我们需要以看待非代理软件单元测试的方式来思考评估（Evals）。它们超越了检查某物是否工作，转而衡量其在能力、可靠性和安全性方面的表现如何。Evals有助于确定模型是否不仅产生正确的输出，而且行为是否一致，能否在真实场景中被信任。
它们可以离线、在线或持续在线运行，提供关于系统行为的持续反馈。本质上，Evals将自动化测试和运行时可观测性结合在一起，为智能系统创建了一个持续的评估和改进循环。
将EVAL评估集成到交付链中
将Evals集成到交付链中，能确保代理软件在软件生命周期的各个阶段得到持续验证。
在CI阶段，离线Evals在代码向前推进之前验证核心阈值。在CD期间，渐进式交付由指示实时场景中性能和可靠性的Eval分数来指导。
一旦部署，始终在线的Evals在生产环境中运行，以监控模型漂移、偏见、毒性及安全性等问题。通过结合这些层级，团队可以根据汇总的Eval结果做出明智的推广或回滚决策，从而创建一个能够学习、适应并在每次发布中保持信任的交付管道。
将你的供应链视为一个活系统
在代理世界中，软件交付过程必须演变成一个行为如同活系统的持续反馈循环。真实的用户信号直接反馈到在线评估中，触发反思和自动化的改进动作。当检测到漂移或性能退化时，提示词和工作流需要被重新评估，代理需要持续重新部署，以确保系统保持对齐和可靠。
随着时间的推移，系统会在数据、提示词和行为模式上学习，不断适应以持续交付改进的价值。CI/CD不再是从代码到生产的直线路径。它变成了一个治愈循环，每一次互动都有助于持续的学习和完善。
结论
虽然作为一个社区，我们才刚刚起步，但我深信软件交付的未来取决于将我们的关注点从代码正确性转向行为信任。当前的CI/CD管道是为确定性系统设计的，但代理和AI驱动的应用程序需要围绕持续学习和保证构建的新方法。Evals现在充当着新的单元测试，帮助团队在部署的每个阶段衡量可靠性、性能和安全性。
通过将供应链演进为一个反馈系统，组织可以创建不仅交付更快，而且能与它们的代理一同学习和适应的管道，确保每次发布既是智能的，也是值得信赖的。