重新思考智能体时代的软件供应链

本文探讨了传统CI/CD管道在AI智能体时代的局限性,提出了从持续集成向持续智能的转变,介绍了评估测试作为新型单元测试的重要性,以及如何构建能够学习和适应的软件供应链系统。

重新思考智能体的软件供应链

最近的MIT研究报告显示,只有约5%的生成式AI应用正在创造真实、可衡量的商业价值。在我看来,这不是雄心的失败。大多数团队都在积极进行实验。问题在于我们用来交付软件的基础系统尚未适应AI的实际特性。

构建原型或演示已经变得异常简单。只需几次提示调整、一个API调用,就能展示出令人印象深刻的东西。但将原型转化为可以在生产环境中信任的系统则是完全不同的挑战。这部分需要真正的工程:可靠性、一致性、版本控制、监控和防护栏。问题在于,我们多年来依赖的工具和工作流程从未设计用于支持随时间改变行为的系统。

传统CI/CD管道的局限性

持续集成/持续交付(CI/CD)管道是为了测试代码而构建的。它们回答以下问题:

  • 这个函数是否返回预期结果?
  • 应用程序是否能够干净部署?

但AI系统和智能体的行为不像静态代码。它们的行为可能因上下文、数据和提示而变化。因此真正的问题变成了:即使条件发生变化,我们能否信任这个系统做出的决策?

重新思考软件供应链

我们需要接受这样一个事实:多年来我们构建和交付软件的方式不再适合智能、智能体用例的世界。

如今,CI/CD管道专注于检查代码是否有效,但对于智能体系统,重点是理解智能体在复杂环境中如何行为、适应和做出决策。

为实现这一目标,我们的软件供应链需要超越持续集成,并朝着提供关于正在构建和交付的软件的持续智能的方向发展。在新管道中,每个步骤都需要确保我们正在学习和评估智能体,以建立更多信任。

我们需要将软件供应链视为一个活生生的系统,它不断学习、改进并随着其支持的产品而进化。

从持续集成到持续智能

我们在智能体时代的CI目标已经改变:

  • 从:“这段代码是否足够好可以合并?”
  • 到:“这种智能是否可靠到可以信任其行为?”

从持续集成到持续智能的转变改变了我们思考构建和信任软件的方式。软件交付管道旨在检查代码是否正确运行,但智能体系统要求我们验证系统在现实世界不可预测条件下的行为方式。

LLMs是非确定性的,结果不可预测,但当我们在进化软件时,我们需要确保其行为持续改进。因此挑战在于确保基于非确定性的软件具有可靠性和一致性。

评估测试是新的单元测试

在智能体系统世界中,我们需要以思考非智能体软件单元测试的方式来思考评估测试。它们超越了检查某物是否工作,而是衡量其在能力、可靠性和安全性方面的表现。评估测试不仅帮助确定模型是否产生正确输出,还判断其行为是否一致,并能在真实场景中被信任。

它们可以离线、在线或持续在线运行,提供关于系统行为的持续反馈。本质上,评估测试将自动化测试和运行时可观察性结合在一起,为智能系统创建一个持续的评估和改进循环。

将评估测试集成到交付链中

将评估测试集成到交付链中可确保智能体软件在整个软件生命周期中得到持续验证。

在CI阶段,离线评估测试在代码前进之前验证核心阈值。在CD期间,渐进式交付由指示真实场景中性能和可靠性的评估分数指导。

一旦部署,始终在线的评估测试在生产中运行,以监控模型漂移、偏见、毒性和安全性等问题。通过结合这些层次,团队可以根据聚合的评估结果做出明智的推广或回滚决策,创建一个学习、适应并在每个版本中保持信任的交付管道。

将供应链视为生命系统

在智能体世界中,软件交付过程必须演变成一个持续反馈循环,其行为类似于生命系统。真实用户信号直接馈入内联评估,触发反思和自动化改进操作。当检测到漂移或性能下降时,需要重新评估提示和工作流程,智能体需要持续重新部署,确保系统保持对齐和可靠。

随着时间的推移,系统会在数据、提示和行为模式中学习,适应以持续提供改进的价值。CI/CD不再是从代码到生产的直线路径。它变成了一个修复循环,其中每个交互都有助于持续学习和改进。

结论

虽然我们作为一个社区才刚刚开始,但我相信软件交付的未来取决于将我们的焦点从代码正确性转向行为信任。当前的CI/CD管道是为确定性系统设计的,但智能体和AI驱动的应用程序需要围绕持续学习和保证构建的新方法。评估测试现在作为新的单元测试,帮助团队在部署的每个阶段衡量可靠性、性能和安全性。

通过将供应链演变为反馈系统,组织可以创建不仅交付更快,而且与其智能体一起学习和适应的管道,确保每个版本既智能又可信任。

参考

https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计