AI代理可靠性是系统工程难题，传统测试不足。需放弃“提示即祈祷”，通过瞬时沙盒进行高保真集成测试，确保生产级稳定性。
译自：Your CI/CD Pipeline Is Not Ready To Ship AI Agents
作者：Arjun Iyer
让我们坦诚面对一分钟。如果你撇开炒作周期、病毒式传播的推特演示以及基础模型公司天文数字般的估值，你会注意到人工智能领域存在一个明显的空白。
我们仍处于早期阶段，我们的基础设施正在失效。
虽然每家SaaS公司都在其UI上添加了一个Copilot侧边栏，但真正的自主代理在实际应用中却很少见。我指的是那种无需人工干预即可可靠执行复杂多步骤任务的软件。如今，大多数代理都是由热情的工程师将内部工具拼凑起来，用于总结Slack帖子或查询SQL数据库。它们存在于内部使用的安全港湾，在那里20%的故障率只是一种奇怪的烦恼，而不是一个流失事件。
为什么这些代理还没有面向客户？不是因为模型缺乏智能，而是因为我们的交付流程缺乏严谨性。将代理从酷炫的演示带到生产级可靠性是一个工程噩梦，很少有人解决，因为传统的CI/CD管道根本不是为非确定性软件设计的。
我们正以艰难的方式认识到，交付代理不是一个AI问题。它是一个系统工程问题。具体来说，它是一个测试基础设施问题。
“提示即祈祷”的终结
在过去一年里，业界一直痴迷于那些承诺奇迹的框架。你给框架一个目标，它就会搞定其余的一切。这就是“提示即祈祷”时代。
但正如工程社区最近的讨论所强调的，特别是围绕12-Factor Agent的深刻对话，生产现实是乏味的确定性。实际交付可靠代理的开发者正在放弃完全自主的理念。相反，他们正在构建健壮且确定性的工作流，其中大型语言模型（LLM）被视为在特定杠杆点注入的模糊函数调用。
当你剥去LLM的黑盒魔法时，一个生产级代理开始看起来很像传统的微服务。它具有控制流、状态和依赖关系。它需要与世界交互才能发挥作用。
12-Factor理念正确地指出，你必须拥有自己的控制流。你不能将你的逻辑循环外包给一个概率模型。如果你这样做，你最终会得到一个80%的时间工作正常，而另外20%的时间会自行产生幻觉陷入困境的系统。
因此，我们将代理构建为工作流。我们将LLM视为一个组件，而不是架构师。但一旦我们确定了这种架构，我们就会一头撞上传统软件工程十年前就已经解决，但AI又重新打开的一堵墙。这堵墙就是集成测试。
评估的陷阱
当团队开始测试代理时，他们几乎总是从评估（evals）开始。
评估至关重要。你需要框架来评估你的LLM输出的相关性、毒性和幻觉。你需要知道你的提示更改是否导致推理能力的退化。
然而，在交付产品的背景下，评估本质上是单元测试。它们测试节点的逻辑，但它们不测试图的完整性。
在生产环境中，你的代理不是在虚空中聊天。它在行动。它在调用工具。它正在从CRM获取数据，更新Jira中的票据，或者通过MCP（模型上下文协议）服务器触发部署。
你的代理的可靠性不仅取决于它编写文本或代码的能力，还取决于它处理这些外部依赖项返回的混乱和结构化数据的一致性。
集成噩梦
这就是平台工程头疼的开始。
想象一下，你有一个旨在排除Kubernetes Pod故障的代理。要测试这个代理，你不能只给它一个文本提示。你需要将它置于一个可以做几件事的环境中。它必须调用Kubernetes API或封装它的MCP服务器。它必须接收描述CrashLoopBackOff的JSON负载。它必须解析该负载。它必须决定检查日志。最后，它必须调用日志服务。
来源：Signadot
如果该JSON负载的结构发生变化，或者日志服务的延迟突然增加，或者MCP服务器返回略有不同的错误模式，你的代理可能会崩溃。它可能会因为输入上下文与训练示例不匹配而臆想出解决方案。
为了可靠地测试这一点，你需要集成测试。但是，对代理进行集成测试比对标准Web应用程序进行集成测试要困难得多。
为什么传统测试不起作用
在传统的软件开发中，我们模拟依赖项。我们对数据库和第三方API进行存根。
但对于LLM代理，数据就是控制流。如果你模拟MCP服务器的响应，你就是在给LLM提供一个完美且经过清理的场景。你正在测试“顺利路径”。但LLM在“不顺利路径”上最危险。
你需要知道当MCP服务器返回500错误、空列表或缺少字段的模式时，代理会如何反应。如果你模拟这些交互，你就是在编写一个让测试通过而不是发现错误的测试。你不是在测试代理的推理能力，而是在测试你自己编写模拟的能力。
模拟的替代方案通常是一个完整的预发布环境，你在其中启动代理、MCP服务器、数据库和消息队列。
但在现代微服务架构中，为每个拉取请求启动一个重复的堆栈是极其昂贵和缓慢的。你不能等待45分钟来完成一个完整的环境配置，只为了测试对系统提示的微调是否正确处理了数据库错误。
对瞬时沙盒的需求
要交付生产级代理，我们需要重新思考我们的CI/CD管道。我们需要能够让我们在软件开发生命周期的早期执行高保真集成测试的基础设施。
我们需要瞬时沙盒。
平台工程师需要为AI开发者提供一种方法，来启动一个轻量级、隔离的环境，其中包含：
- 正在测试的代理版本。
- 它所依赖的特定MCP服务器和微服务。
- 访问真实（或逼真）的数据存储。
至关重要的是，我们不需要复制整个平台。我们需要一个系统，允许我们启动已更改的组件，同时将流量智能地路由到堆栈其余部分的共享稳定基线。
来源：Signadot
这种方法解决了数据保真度问题。代理与运行真实逻辑的真实MCP服务器交互。如果MCP服务器返回一个复杂的JSON对象，代理必须将其摄入。如果代理发出一个改变状态的调用（例如重启Pod），它实际上会命中该服务或其沙盒版本。这确保了循环的闭合。
这是验证工作流是否可靠的唯一方法。
将代理可靠性左移
AI代理的未来不仅仅是更好的模型，更是更好的DevOps。
如果我们接受生产级代理只是带有模糊逻辑的软件，那么我们必须接受它们在集成测试中需要与支付网关或飞行控制系统相同的严谨性。
我们正在走向一个代理只是Kubernetes集群中一个微服务的世界。它通过MCP与其他服务通信。平台工程师面临的挑战是让开发者有信心合并代码。
这种信心并非来自提示评估上的绿色对勾。它来自于看到代理在一个真实环境中运行，查询一个真实的MCP服务器并成功执行工作流。
结论
构建代理是容易的部分。构建可靠测试代理的堆栈才是成败的关键。
随着我们从内部玩具和受控演示转向面向客户的产品，获胜的团队将是那些能够快速迭代而不破坏现有事物的团队。他们将是那些放弃“提示即祈祷”理念，转而将生产保真度带入其拉取请求（PR）审查的团队。这需要一种专注于请求级隔离和在Kubernetes中原生工作的瞬时测试环境的特定基础设施。
解决这种基础设施差距是Signadot的核心使命。我们允许平台团队创建轻量级沙盒来测试代理，以对抗真实依赖项，而无需完整环境的复杂性。如果您正在完善您的AI工作流架构，您可以在signadot.com了解更多关于这种测试模式的信息。
