用SQLite协调本机多个AI编程助手
agent-collab-kit用约230行Python及SQLite处理本机多个编程Agent之间的协作问题,仅依赖标准库并采用MIT许可。消息持久保存至接收方确认,文章同时指出并行编辑同一文件的覆盖风险。
原文暂未完整获取,基于公开信息的快读
多个 AI 编程 Agent 在同一台机器上干活,容易碰到两个问题:完成通知留在各自终端里,交接被遗漏;同时修改一个文件,后一次写入覆盖前一次。作者团队在开发内部工具时遇到了这两种情况,于是做了 agent-collab-kit:用约 230 行 Python、标准库和 SQLite 协调协作,采用 MIT 许可。
目前能确认什么
工具提供持久消息和显式确认。消息保存在本地 SQLite 数据库中,等待接收方确认。同一个幂等键用于重试时,可以返回已有消息,避免重复发送;拿它发送不同内容则会报错。但 ack 只表示消息已收到,不能证明代码已交付或测试通过。
编辑文件前,Agent 可以申请对应资源名称的租约(lease),也就是有有效期的占用声明。租约有效时,其他 Agent 申请同名资源会失败。每次申请都有新的 generation UUID,续租和释放需要匹配所有者及这一标识,避免旧任务误操作后来接手者的租约。
租约依赖 Agent 主动遵守,不能阻止文件写入。
暂停的 Agent 可能在租约过期、资源被接管后恢复运行,因此必须检查所有权,失去租约就停止工作。工具仅支持可信的单机和本地磁盘,不负责启动 Agent、调用模型或运行 Git。
我的判断
它适合给多个本机编程会话补上明确的交接规则。持久消息能减少通知遗漏,租约能表达文件归属,但仍需要一个集成者负责审查和合并;作者团队也采用了这种分工。
数据库里的占用状态,不等于文件已经受到保护。
真正需要核实的是接入方式:Agent 是否会在写入前检查所有权,失去租约后能否及时停止。节选没有给出完整执行流程。若这些行为只靠提示词约定,并行编辑的覆盖风险仍然存在,不能把申请租约成功当成安全写入的保证。