多代理代码调度坞

并行运行本地编码代理时,为每个代理隔离环境、预约冲突文件,并按测试结果排队交付补丁。

开发者一次开多个本地编码代理时,麻烦很快从“谁来写”变成“谁在改同一个文件”。用户把 Linear 或 GitHub issue 拖进调度台,标注依赖关系、测试命令和允许代理碰触的目录。每个代理启动前都会拿到独立 worktree、环境变量和可回收的测试容器,主分支始终保持干净。

代理准备修改高冲突文件时,先申请短期文件租约。若支付模块、配置文件等关键区域已被占用,调度台会把它改派到可并行的测试、文档或低冲突任务,或让它等待前一项补丁的结果。代理完成后,系统在各自容器中运行指定测试,记录代码差异、测试输出和它引用过的任务上下文。

通过测试的补丁按依赖顺序进入合并队列。后续补丁若依赖前一个改动,系统会先在更新后的基线重新验证;失败的任务则带着终端现场退回给开发者。最初版本只支持本机 Git 仓库、容器测试和文件租约,先解决多代理互相覆盖这件事,不代替团队的代码审查与发布权限。

为什么是现在

截至2026年9月8日观察时,Airuncode位于Product Hunt新品流第3位,并直接主打在本机运行多个编码代理。S1 当用户开始并行启动代理,文件争用、测试环境互扰和补丁合并顺序就会成为紧邻的操作问题。

目标用户

目标用户是同时开两到五个本地编码代理的独立开发者或小团队负责人。他们通常在拆完一组相关issue后,希望并行推进实现、测试和文档。此时多个任务会触碰配置、类型定义或公共接口。手动维护worktree、终端和合并顺序开始占用注意力,才会需要一个调度台。

最小切入点

核心状态可先放在本地SQLite中,记录任务、依赖、租约和运行结果。每项任务用Git worktree创建独立分支和目录,这一隔离方式已有同类工具验证。S3S4 用Docker Engine启动一次性测试容器,并为端口、缓存和环境变量生成任务级命名空间。代理通过包装后的文件写入工具申请租约,而不是直接限制整个worktree。第一版只接GitHub Issues与Linear中的一种,避免同时维护两套同步逻辑。合并队列先做拓扑排序、变基和指定测试,不尝试自动判断代码质量。

以小博大

最有效的演示是一段可复现的冲突现场:两个代理同时修改配置文件,调度台把其中一个改派去补测试。把该示例仓库、运行日志和CLI做成开源模板,能直接触达正在使用Claude Code、Codex和其他本地代理的开发者。发布内容应聚焦少返工多少,而非代理数量。用户导入自己的仓库后,可免费查看文件重叠报告,再决定是否启用自动调度。

竞品与缝隙

AiruncodeGoogle
Airuncode已提供本地优先的多代理运行环境。用户自带模型密钥,代码与提示词保留在本机。它还强调共享记忆、自动补测试和失败后修复。S2 这已经覆盖“同时跑多个代理”的主要入口。公开页面更关注代理能力和测试闭环。页面没有展示修改前的文件租约流程。也没有说明会按占用情况改派任务。这张卡的缝隙在代理动手前。它把目录权限、依赖关系和租约放入调度决策。若Airuncode补上冲突预判,这个缝隙会迅速缩小。
Open OrchestratorGoogle
Open Orchestrator已经为代理创建独立worktree。它支持多种编码代理和统一控制台。Conflict Guard会实时发现文件重叠。合并队列还能提示顺序并逐项交付。S3 这与本卡的后半段高度接近。差异在于它主要监测已经发生的编辑重叠。本卡要求代理写入前取得短期租约。占用发生时,任务还能转去测试或文档。Linear或GitHub issue的依赖也参与排程。这个差异必须明显减少等待和返工。否则它更像现有工具的一项调度功能,而非独立产品。

怎么赚钱

本地单仓库和基础租约免费。专业版按开发者席位月付,提供多仓库调度、任务系统同步、容器模板和历史审计。团队版再增加共享策略、权限控制与集中运行节点。

反方视角

文件租约可能把正常并行误判为冲突,导致代理空等。代理也可能通过脚本、生成器或重命名绕过路径规则。worktree只隔离文件,数据库、端口、缓存和外部服务仍会互相影响。每项任务启动容器会增加磁盘占用与等待时间。依赖图若由用户手填,很快会失真;若让模型推断,又会出现漏项。更现实的威胁是相邻工具已具备隔离、冲突检测和合并队列。S3 若主动租约不能显著减少返工,它只适合作为插件功能。

依据与来源

共引用 4 条可核验来源
发布快照· Product Hunt
Airuncode
Feed 日期
快照时间
截至 抓取
在 Product Hunt 查看 "Airuncode"
来源核对
Telegram 频道