Rivet：在S3上扩展与编排AI代理的新范式

为什么AI代理需要新的基础设施

当前AI代理（Agent）的部署面临一个根本矛盾：代理需要持久化状态、高并发处理和灵活编排，而传统云基础设施并非为此设计。Rivet（YC W23）在Hacker News上发布的Launch HN项目，提出了一种激进但合理的思路——将代理的扩展与编排直接构建在S3之上。

S3作为对象存储，天然具备高持久性和近乎无限的扩展能力，但通常不被视为运行有状态代理的首选。Rivet的切入点在于：代理的核心需求不是低延迟计算，而是可靠的状态管理和事件驱动的工作流。通过将代理的运行时状态、消息队列和任务编排层映射到S3对象上，Rivet试图绕开复杂的基础设施管理，让开发者专注于代理逻辑本身。

这一思路的吸引力在于极简的运维模型。开发者无需预置数据库或消息中间件，代理的每次状态变更都作为对象写入S3，编排则通过轮询或事件通知触发。对于初创团队和原型验证场景，这种“无服务器式”的代理托管显著降低了启动成本。

S3（Simple Storage Service） 是AWS于2006年推出的对象存储服务，将数据以“对象”形式存放在扁平命名空间中，每个对象包含数据本体、元数据和唯一键。其核心特性包括：11个9的数据持久性、按请求量自动扩展的吞吐能力、以及最终一致性（2020年后对新建对象和覆盖写升级为强一致性）。与块存储或文件系统不同，S3不支持原地修改或部分追加，每次更新都是完整对象替换，并以版本ID保留历史。S3的API模型简单（PUT/GET/LIST），按存储量和请求次数计费。这些特性使其成为备份、数据湖和静态资源托管的默认选择，但其高延迟（通常数十毫秒）和LIST操作的扩展瓶颈，也让它鲜少被用于低延迟事务场景。

代理编排的S3原生设计

Rivet的核心设计围绕三个抽象：代理定义、状态存储和调度器。代理定义以代码或配置形式描述工作流步骤；状态存储利用S3对象保存每个代理实例的上下文和中间结果；调度器则负责检测状态变化并触发下一步骤。

这种设计的一个直接好处是弹性。S3的写入和读取能力随请求量自动扩展，代理数量的增长不会引入新的运维负担。另一个好处是可审计性——每个代理的完整状态历史都是S3上的对象版本，天然支持回放和调试。

然而，S3的延迟特性也带来挑战。对于需要毫秒级响应的交互式代理，轮询S3可能引入不可接受的延迟。Rivet的应对策略是将高频操作缓冲在内存中，仅定期持久化到S3，但这又部分牺牲了状态一致性。Hacker News评论中有开发者质疑这一权衡是否适合生产环境，尤其是多代理协作场景下的竞态条件。

竞态条件（Race Condition） 指多个执行单元并发读写共享状态时，最终结果依赖于不可控的执行时序，从而导致非预期的行为。在代理编排中，典型场景是：两个代理实例几乎同时读取同一份S3对象作为上下文，各自更新后写回，后写入者会静默覆盖先写入者的变更。由于S3的对象写入是“整对象替换”而非原子字段更新，也没有内建的乐观锁（如版本号比较并交换）机制，仅靠S3原生API无法直接防止这类丢失更新。常见缓解手段包括：在对象元数据或独立锁对象上实现compare-and-swap、引入外部协调服务（如DynamoDB条件写）、或让单个调度器串行化同一代理实例的所有状态变更。这也是Hacker News评论中质疑多代理协作场景可靠性的技术根源。

多源视角下的争议与共识

据Hacker News的Launch帖和评论区讨论，Rivet获得了早期关注者的认可，但也面临尖锐质疑。共识在于：S3作为代理状态后端在成本和大规模扩展上有明显优势，尤其适合批处理型和长时运行的代理任务。

分歧则集中在延迟和一致性上。部分评论者认为，将S3用于编排层是“用错了工具”，因为S3的强一致性模型在跨区域场景下表现复杂，且对象存储的列表操作在大规模下可能成为瓶颈。另一方则反驳，对于许多代理工作流而言，秒级延迟已足够，而S3的简单性带来的开发效率提升远超延迟损失。

一个独特的洞察来自单一来源评论：Rivet的真正价值可能不在S3本身，而在于它提供了一套代理状态管理的标准接口，未来可以替换底层存储而不影响上层逻辑。如果这一抽象成立，Rivet的长期定位将是代理基础设施的“控制平面”，而非S3的封装。

强一致性（Strong Consistency）与跨区域复制 是理解评论分歧的关键背景。AWS在2020年12月宣布S3对新建对象的PUT和LIST操作提供强一致性，意味着写入成功后任何后续读取都能看到最新版本。但这一保证仅在单个区域内部成立；S3的跨区域复制（Cross-Region Replication）本质上是异步的，副本区域可能存在秒级到分钟级的滞后，且不保证顺序。对于跨区域部署的代理编排，如果在A区域写入状态后由B区域的调度器读取，就可能观察到陈旧数据，从而破坏“状态即真相”的假设。此外，S3的LIST操作在存储桶对象数量极大时，单次请求返回上限为1000个键并需分页，高频轮询会显著增加请求成本与延迟，这正是“对象存储列表操作可能成为瓶颈”这一质疑的具体来源。

对开发者的实际意义

对于正在构建AI代理的团队，Rivet提出了一条值得评估的路径：如果你的代理工作流以异步任务为主，对状态持久性要求高而对延迟不敏感，那么基于S3的编排可以大幅简化架构。反之，实时对话型代理仍需考虑传统数据库或内存队列方案。

Rivet的Launch也反映了一个更广泛的趋势——AI代理的基础设施正在从通用云计算向领域特定方案分化。S3只是一个起点，未来可能出现更多针对代理生命周期优化的存储与编排原语。开发者应关注这类项目背后的抽象设计，而非仅仅比较底层存储的优劣。