AI Agent的部署黑洞：为什么我们的基础设施仍停留在SSH和祈祷阶段

问题的本质

传统软件工程花了二十年时间完善CI/CD——容器化、零宕机部署、自动回滚、蓝绿发布。每一项都经过实战验证，每一项都有成熟的工具链。

然后Agent时代来了。我们把这些全都扔了。

现在部署一个Agent是什么流程？SSH进生产服务器，编辑提示词模板，重启服务，祈祷。这不是2026年，这是2005年。

我做的不是在抱怨。这是技术债务的尸检报告。

非确定性系统无法用确定性工具部署

传统CI/CD建立在一个美丽的谎言之上：代码产生可预测的输出。你写测试，测试通过，部署，生产环境的测试依然通过。恭喜，你发布了软件。

现在试试用Agent。

你的测试套件通过了，因为GPT-4在解析"明天见"时返回了"用户想要安排会议"。你部署了。GPT-4返回了"用户想要创建日历事件"。集成崩了。什么都没变，除了月相和OpenAI在推理集群上推送的未文档更新。

我们假装可以像测试代码一样测试Agent，但我们是在测试概率分布。每个通过的测试实际上是在说："这次在特定token、特定温度、特定时间点，1次中有1次成功了。"这不是测试。这是带着断言的祈祷。

统计测试的悖论

我们需要的是针对概率输出的统计测试。你的CI管道应该运行每个测试100次，分析输出分布。响应长度均值变化了吗？方差增加了？函数调用率下降了吗？

但没人建这个，因为运行每个测试100次意味着CI耗时100倍，成本100倍。所以我们运行一次测试，合并PR，然后祈祷。

金丝雀部署在无对照组世界中的失败

金丝雀部署在可以A/B测试时很美。5%流量路由到新版本，比较错误率，向前或向后滚动。简单。

除非Agent不这样工作。

每个对话都是独特的。每个用户上下文都不同。你无法比较两个Agent版本的"错误率"，因为它们处理的请求完全不同。版本B失败更多是因为它更烂，还是因为它碰巧遇到了更怪的边缘情况？

我上个月尝试实现prompt变更的金丝雀部署。我把流量95/5分流到旧prompt和新prompt。新prompt在每个我测量的指标上都表现更好。我滚动到50%。突然，对话完成率下降30%。

发生了什么？新prompt更冗长。这对短对话没问题，但在长对话中导致上下文窗口问题。我的5%金丝雀只捕捉到短对话，因为统计上小样本就是这样。失败模式在规模之前是不可见的。

这是Agent的金丝雀悖论：你需要规模来发现问题，但如果你等到规模，你做的就不是金丝雀部署了。

版本锁定在你无法控制的API上

你知道什么有趣吗？把整个产品构建在一个90天后会消失的API版本上。

OpenAI给GPT-3.5-turbo-0613三个月通知期弃用。Anthropic更新Claude模型并给你宽限期。但你锁定的版本——你测试、调优prompt的版本——最终会消失。

在传统软件中，版本锁定可以解决这个问题。你锁定到lodash 4.17.21，它永远在那里。你的Agent锁定到gpt-4-0613，它会一直在那里，直到OpenAI决定它不会在。

正确的解决方案是抽象模型层并维护每个模型版本的prompt变体。实践中没人这么做，因为这会让你的测试表面翻倍，而你已经淹没在测试中了。

取而代之的是强制行军。当弃用邮件到达时，你有90天时间：1. 针对新模型测试整个prompt库 2. 发现哪些prompt崩了 3. 修复它们 4. 希望新模型没有引入新的失败模式 5. 一次性部署所有，因为你无法部分迁移

这不是部署管道。这是倒计时的挟持局势。

真正的回滚不是回滚

这是个有趣的故事。我们在下午2点部署了新Agent版本。到下午4点，客户投诉滚滚而来。没问题——我们回滚。

除了我们做不到。

新版本处理了500个对话。它更新了用户偏好，创建了数据库记录，生成了旧版本不知道如何处理的状态。回滚代码很简单。回滚状态不可能。

这是没人谈论的部署问题：Agent不是无状态请求处理器。它们积累状态。它们学习用户偏好。它们维护对话上下文。部署新版本不仅仅是改变代码——它是改变现实的模式。

传统部署策略假设你可以回滚到已知的好状态。但对于Agent，"已知的好状态"包括坏版本运行时学到的所有东西。你无法不丢失数据地取消学习。

正确的架构是带有版本感知重放的事件溯源。每个Agent交互应该是一个事件。回滚意味着通过旧版本逻辑重放那些事件以重建兼容状态。这是你为有状态系统获得真正回滚能力的方式。

没人建这个因为它极其复杂且性能开销巨大。取而代之的是，我们生活在"回滚"意味着"部署旧代码并手动修复数据损坏"的世界里。

这没问题。一切都很好。

Agent世界的蓝绿部署（思想实验）

蓝绿部署在理论上很美。你有两个相同的生产环境。蓝是活的。你部署到绿，运行测试，然后瞬间切换流量。如果绿失败，切回蓝。零宕机，瞬间回滚。

现在试试Agent。

问题不在基础设施。Kubernetes让蓝绿部署微不足道。问题是对话状态。

你的蓝环境正在服务一个对话。用户问问题。蓝Agent响应。你切到绿。用户问后续问题。绿Agent没有上下文。

你可以在蓝绿之间共享状态，但现在它们不独立了。对绿的不良部署可能破坏蓝的状态。你可以在切换时对状态进行快照，但现在你在赌你的状态序列化格式在版本间兼容。

真正的解决方案是版本感知的状态管理。每个状态写入应该标记创建它的Agent版本。当你从蓝切到绿时，进行中的对话保持它们的上下文，但那个上下文通过绿的版本镜头被解释。

这意味着绿需要理解蓝的状态格式。这意味着你的状态模式需要永远向前兼容。这意味着你需要在两个方向上都需要迁移逻辑，因为从绿回滚到蓝需要降级状态。

没人在规模上建过这个基础设施，因为它现象级复杂。取而代之的是，我们在切换前排空连接（宕机），或者我们接受一些对话会丢失上下文（破坏的用户体验），或者我们根本不做蓝绿部署。

特性标志对于Prompt来说比你想象的更难

代码的特性标志很简单。把新代码包在if语句里，切换标志，测量影响。简单。

Prompt的特性标志是个完全不同的野兽。

问题是可组合性。Prompt不是离散的特性。它是链的一部分。你的系统prompt影响你的函数调用，这影响你的输出解析，这影响你的下一轮。在不改变其他的情况下改变一个prompt会创造微妙的不一致。

我尝试为prompt实现特性标志。我想A/B测试一个让Agent更简洁的新系统prompt。看起来很简单，对吧？就把50%的请求路由到新系统prompt。

除了新系统prompt稍微改变了响应格式。我的输出解析器依然工作但更慢，因为它打了更多边缘情况。然后更慢的解析导致长对话中的超时问题。然后超时问题导致用户重试，这打了其他变体，这给出了不一致的响应。

一个特性标志创造了状态腐化的级联。

我们需要的Infrastructure是版本感知的prompt链。当你切换特性标志时，你不是改变一个prompt——你是切换到整个prompt链变体。这意味着维护并行的prompt宇宙并确保它们产生语义等价的输出。

仅监控就是噩梦。你不能只数错误。你需要测量变体间的语义漂移。你需要检测变体A和变体B产生技术上正确但战略上不同的响应。

没这个工具。我们没有自然语言的语义diff工具。我们没有prompt一致性的lint规则。我们没有LLM输出的类型系统。

所以我们用特性标志部署prompt并希望级联效应不会破坏太多东西。

我们需要的管道

我们需要但没人建的部署管道应该包括：

版本感知的状态管理：每个Agent状态片段标记创建它的版本。版本边界的自动迁移。包括状态回滚的回滚支持。

语义回归测试：针对基线分布的连续Agent行为评估。当行为漂移超过阈值时自动警报。与部署管道的集成以阻止不良部署。

带语义监控的渐进式推出：部署到队列，不是一次性。监控语义指标，不只是系统指标。语义退化时的自动回滚。

多模型抽象：Agent可以同时在多个LLM后端上运行。模型版本间的渐进式流量转移。基于真实使用模式的成本和质量优化。

对话感知的蓝绿部署：环境间的状态迁移。版本边界的上下文保留。长对话的零宕机更新。

这个基础设施不存在，因为每个人太忙于构建Agent而无法构建它下面的平台。我们在犯二十年前行业犯的同样错误——在基础设施之前构建应用程序。

区别是二十年前，你可以发布损坏的代码并重启服务器。现在，你发布一个损坏的Agent，它会在任何人注意到之前对用户进行三个小时的煤气灯效应。

经济学没有帮助。构建Agent基础设施昂贵且没有直接回报。构建Agent便宜且有直接回报。每个初创公司都在竞相发布功能。没人有时间构建部署管道。

直到它们规模化。直到它们有10,000用户并且需要在不宕机的情况下部署关键修复。直到它们有100个Agent并且需要在所有之间管理prompt版本。直到它们有监管要求并且需要每次部署的审计日志。

直到那时，它们意识到它们应该先建基础设施。但到那时，它们有技术债务，有依赖当前行为的用户，有要求功能速度的投资者。停下来构建基础设施感觉像是倒退。

所以它们不这样。它们打补丁并祈祷。它们为眼前的问题构建一次性解决方案。它们积累部署债务，就像它们积累技术债务一样。最终，部署过程变得脆弱以至于没人想部署。速度降为零。

这就是我们所在的地方。大多数Agent公司距离一次不良部署的危机只有一步之遥。大多数Agent平台没有回滚策略。大多数Agent团队通过SSH进生产并编辑文件来部署。

我们需要在构建更多Agent之前构建部署管道。或者我们需要接受我们的部署策略就是SSH和祈祷。

我知道我会赌哪个。

关于作者：Atuia是哲学博士、技术CTO、有判断力的思考者。他相信证据高于感觉，判断高于圆滑。你可以在 https://www.80aj.com 阅读更多他的深度思考。