使用一群并行编程智能体构建 SQLite
简而言之。任务：作者编排了六个并行编程智能体（Claude、Codex 和 Gemini 各两个）来构建一个约 1.9 万行代码的类 SQLite Rust 引擎。工作流程包括生成脚手架的引导阶段，随后是工作循环，智能体在此循环中认领范围明确的任务、实现功能并以 sqlite3 作为标准参照进行测试。源文本未详细说明人在智能体循环期间的持续参与，主要限于初始设置和监控。；工具：custom-built or unnamed agent。人工角色：原始帖子没有说明人如何参与。；局限：该项目是 SQLite 架构的“仿制品”，而非生产级数据库，缺乏并发支持和完整的 SQL 功能。高协调开销和文档膨胀（PROGRESS.md 达到 490 行）阻碍了效率。使用 CLI 智能体难以跟踪令牌使用情况，且整合智能体在运行期间未能完成去重任务。。
工具
custom-built or unnamed agent
Agent Work Atlas 发布日期:
概述
简而言之
工作流程
作者编排了六个并行编程智能体（Claude、Codex 和 Gemini 各两个）来构建一个约 1.9 万行代码的类 SQLite Rust 引擎。工作流程包括生成脚手架的引导阶段，随后是工作循环，智能体在此循环中认领范围明确的任务、实现功能并以 sqlite3 作为标准参照进行测试。源文本未详细说明人在智能体循环期间的持续参与，主要限于初始设置和监控。
原文报告的结果
该引擎通过了 64 条 SQLLogicTest 查询，但由于不支持子查询等语法，大多数其他查询失败。观察到显著的协调成本：54.5% 的提交用于锁管理而非功能开发。作者在实验期间用完了 Codex Pro 每周额度的 100%，并使用了 Claude Pro 每周额度的 70%。
人工角色
原始帖子没有说明人如何参与。
局限
该项目是 SQLite 架构的“仿制品”，而非生产级数据库，缺乏并发支持和完整的 SQL 功能。高协调开销和文档膨胀（PROGRESS.md 达到 490 行）阻碍了效率。使用 CLI 智能体难以跟踪令牌使用情况，且整合智能体在运行期间未能完成去重任务。
试一试
我想在一个小型 Rust 项目中复现并行智能体编程实验。首先，设置一个基于锁文件任务认领系统的 git 仓库。安装 Claude、Codex 和 Gemini 的 CLI。创建一个引导脚本，生成 Cargo.toml、DESIGN.md 和 PROGRESS.md。然后，使用循环脚本在单独的终端窗格中启动每个智能体的两个实例，该脚本拉取最新的 main 分支，从 'current_tasks' 目录认领任务，实现代码，运行 'cargo test' 并推送。监控 git 日志以区分协调提交和功能提交。在运行完整智能体群之前，使用一个智能体执行一个简单任务的试运行，以验证锁机制是否正常工作。在花费 API 额度或推送到共享远程仓库之前，请向我寻求确认。在 10 次迭代后，报告协调提交与总提交的比例。
来源报告未经独立核验。发布日期为本站案例发布日期，并非原始文章日期。