每个事件流系统最终都会将同一条消息投递两次。网络抖动、Broker 重启、偏移量提交失败——至少一次投递不是 Bug，而是契约。传统消费者能够优雅地处理这种情况，因为它们是确定性的：处理同一事件两次，得到相同的结果，写入相同的记录。第二次写入是一个空操作（no-op）。
LLM 不是确定性处理器。相同的提示词加上相同的输入，每次运行都会产生不同的输出。即使设置了 temperature=0，浮点运算、批次组合效应以及硬件调度的差异也会引入方差。针对"确定性" LLM 设置的研究发现，在自然发生的多次运行中，准确率差异高达 15%，最优与最差性能之间的差距甚至达到 70%。至少一次投递加上非确定性处理器，并不会给你带来至多一次的行为，只会带来不可预测的行为——这是一场蓄势待发的生产环境危机。
AI Agent 的标准心智模型通常假设采用 HTTP：客户端发送请求，Agent 进行处理，最后返回响应。这种模式清晰、同步、且易于推理。当一个基于 LLM 的函数执行失败时，你会收到一个错误代码；当它成功时，你就可以继续下一步。
一旦你将 HTTP 接口换成 Kafka 主题或 SQS 队列，上述每一个假设都会开始动摇。队列保证的是“至少一次交付”（at-least-once delivery），而你的 Agent 具有随机性。这种组合产生了一些在确定性系统中并不存在的故障模式——而且修复方法也与传统微服务所采用的方法不同。
本文将探讨当 AI Agent 消费消息队列时实际发生的变化：幂等性、顺序性、背压、死信处理，以及一种特定的故障模式——即重播的消息在第二次触发时会导致 Agent 产生不同的行为。
几乎所有关于构建 AI Agent 的教程都以同样的方式开场：用户输入消息，Agent 进行推理，Agent 返回响应。这个模型对聊天机器人和副驾驶（Copilot）来说运行良好，却无法描述各组织正在大规模部署的大多数生产 AI 工作。
在企业环境中默默发挥最大价值的 Agent，并不等待消息。它们在数据库行发生变更时唤醒，在队列深度超过阈值时唤醒，在凌晨 3 点的定时任务触发时唤醒，或在监控检测到指标漂移超出范围时唤醒。它们在没有用户在场的情况下行动。一旦失败，没有人会察觉，直到损失已经累积到难以挽回。
构建这类主动型 Agent 需要一套与构建被动式助手截然不同的设计语汇。适用于对话型 AI 的会话（Session）思维模型，在 Agent 循环运行、在后台重试、没有人类兜底的场景下会彻底失效。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
