Perplexity 用 AI 代理造数据库

背景：AI 代理参与基础设施开发

Perplexity 最近完成了一项引人注目的实验：仅用两名工程师，配合数百个 AI 编码代理，构建了一个名为 CobbleDB 的自定义数据库。这个数据库用 Rust 编写，目标是替代其搜索栈中 DynamoDB 的读取操作。

这一案例展示了 AI 代理在复杂系统开发中的潜力，同时也划出了一条清晰的边界：AI 代理可以参与构建，但绝不允许运行数据库。

CobbleDB 是什么？

CobbleDB 是一个用 Rust 实现的自定义数据库，专门用于处理 Perplexity 搜索栈中的读取负载。原本这部分工作由 AWS 的 DynamoDB 承担，但 Perplexity 选择自研替代方案，以优化性能和成本。

• 语言：Rust，兼顾性能与内存安全
• 定位：替代 DynamoDB 的读取路径
• 开发模式：两名人类工程师 + 数百个 AI 编码代理

AI 代理如何参与开发？

根据公开信息，AI 代理在项目中承担了大量编码任务。人类工程师负责架构设计、任务拆分和代码审查，而 AI 代理则并行生成代码、编写测试、修复简单缺陷。这种模式大幅提升了开发速度，使得小团队也能推进原本需要更大规模人力的基础设施项目。

关键做法：

1. 任务拆解：将数据库开发拆分为细粒度、可验证的模块
2. 代理分工：不同代理负责不同模块的代码生成与测试
3. 人工把关：工程师审查关键逻辑，确保正确性与安全性
4. 禁止运行：AI 代理不参与数据库的实际运行和运维

为什么禁止 AI 代理运行数据库？

这是整个案例中最值得关注的约束。数据库是搜索栈的核心组件，任何运行时的错误都可能导致服务中断或数据损坏。Perplexity 选择让 AI 代理停留在“构建阶段”，而不进入“运行阶段”，原因可能包括：

• 可靠性要求：数据库运行需要严格的稳定性和故障恢复能力
• 责任归属：生产环境操作需要明确的人类责任链
• 安全风险：AI 代理可能执行不可预测的操作
• 可观测性：人类工程师更擅长处理运行时突发问题

这一边界设定为其他团队提供了参考：AI 代理适合加速开发，但不适合直接接管关键生产系统。

对开发者和 AI 使用者的实用解读

谁可以借鉴？

• 小团队：希望用有限人力推进基础设施项目
• AI 工具使用者：探索 AI 代理在复杂工程中的协作模式
• 平台工程师：需要平衡开发效率与生产安全

怎么做？

1. 从非关键路径开始：先让 AI 代理参与工具链、测试、文档等低风险任务
2. 建立审查机制：所有 AI 生成的代码必须经过人工审查
3. 明确禁止清单：列出 AI 代理不得触碰的生产操作，如部署、数据库运行、密钥管理
4. 拆解任务：将大项目分解为 AI 可理解、可验证的小任务
5. 度量效果：跟踪开发速度、缺陷率、审查成本，评估 AI 代理的实际价值

有什么用？

• 加速开发：数百个代理并行工作，缩短交付周期
• 降低人力门槛：两名工程师即可推进数据库级项目
• 积累经验：为未来 AI 参与更复杂系统开发提供范本

总结

Perplexity 的 CobbleDB 案例证明，AI 编码代理可以显著提升基础设施开发的效率，但前提是设定清晰的边界。让 AI 构建，但不让 AI 运行，可能是当前阶段最务实的协作策略。对于开发者和 AI 使用者来说，关键不是追求完全自动化，而是找到人机协作的最佳平衡点。