loop-swarm 多智能体共识沙箱：以顺序运行与字节级补丁共识守护 loop-engineering 的 L3 自动化循环

人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载本指南以 loop-engineering 仓库中loop-swarm功能为绝对主体展开先讲清它为何要解决单个 AI 智能体运行结果不确定这一 L3 高层级问题再给出可直接复制的 CLI 命令与完整参数说明最后深入到tools/loop-swarm的源码与测试还原其顺序多智能体运行 字节级一致多数共识的底层实现。读完你既能立刻跑通npx cobusgreyling/loop-swarm run --count 3 -- agent-cmd也能理解共识阈值、退出码、失败淘汰与安全边界的设计取舍。为什么需要多智能体共识沙箱不确定输出的安全网在 loop-engineering 的成熟度模型里循环loop会从 L1只报告逐级升到 L2在 worktree 中隔离修复再到 L3无人值守自动执行。层级越高一个错误判断被自动写入仓库的代价越大。而 AI 编码智能体agent有一个天然短板即使给它完全相同的任务两次运行也可能产出不同的结果——非确定性可能来自模型采样、工具调用顺序、环境噪声甚至只是注释排版。loop-swarm针对的正是这个缺口。按 tools/loop-swarm/README.md 的定位它是面向极高置信度循环操作的多智能体共识沙箱loop-swarm在一个隔离的loop-sandboxworktree 中按顺序多次运行同一个智能体命令然后提取每次运行产生的.patch文件、对其哈希并自动判断是否达成了多数共识。如果智能体产生了不确定的结果loop-swarm就充当L3 安全网只有被多次独立顺序运行一致验证过的变更才会被提出。换句话说它把一次运行的结果升级为多次运行互相印证的结果用多数投票消化单次运行的不确定性。需要强调的安全前提README 中[!IMPORTANT]标注loop-swarm实现的是临时 git worktree 隔离这一安全边界不是 OS 级沙箱或容器。完整威胁模型请阅读 docs/safety.md 中 Worktree Isolation Consensus Sandboxing 一节。快速上手一条命令跑起共识验证在任意 git 仓库根目录无需克隆本仓库直接通过 npx 运行npx cobusgreyling/loop-swarm run --count 3 -- npx my-agent run --task Refactor utils.ts这是 docs/QUICKSTART.md Multi-agent consensus sandboxing (loop-swarm) 一节给出的标准形态也是本功能在快速入门文档中要求保留的可复制示例# 在 3 个顺序沙箱中运行多智能体共识 npx cobusgreyling/loop-swarm run --count 3 -- agent-cmdCLI 参数与语法从 tools/loop-swarm/src/cli.ts 的参数解析可以看出完整的命令行约定参数简写默认值说明run—必填唯一的子命令缺省或写错会报错退出Missing or invalid subcommand. Must use run.--count, -n-n3顺序启动的智能体数量必须为正整数NaN或小于 1 会报错退出--shell—false是否在 shell 中执行命令如bash -c场景--help, -h-h—打印帮助信息并退出两个容易被忽略的语法点来自 cli.ts 的实现必须显式使用--分隔符loop-swarm run --count 3 -- echo hello。如果没有--、或--后面没有命令CLI 会报Missing command. Use -- to separate options from the command.并以退出码 1 结束——这是为了把智能体命令原样透传避免parseArgs吞掉 agent 自己的参数。--count校验在启动前完成parseInt(values.count, 10)后若isNaN(count) || count 1直接输出--count must be a positive integer.并退出防止 0 或负数引发无意义的空跑。依赖与运行环境见 tools/loop-swarm/package.jsonNode.js 18包为 ESM 模块bin入口为loop-swarm核心运行时依赖cobusgreyling/loop-sandbox以 file: 相对路径引用本仓库的tools/loop-sandbox。共识判定的工作流程五步还原按 tools/loop-swarm/README.md 的 How it works以及 tools/loop-swarm/src/swarm.ts 中runSwarm的实际实现一次完整的 swarm 运行是这样的顺序启动N个loop-sandbox实例默认N3。串行而非并行是为了防止 git worktree 和信号处理器竞争serialized to prevent worktree races。从源码看runSwarm用一个for循环逐个await runInSandbox(...)每个 agent 打印▶️ Agent i/N进度。等待所有沙箱执行完智能体命令并提取 diff。任一智能体失败非零退出码会被取消投票资格——源码先按exitCode 0过滤出successfulRuns统计failedRuns并打印⚠️ N agent(s) failed with non-zero exit codes. They are excluded from consensus voting.。对每个.patch文件的原始字节做 SHA-256 哈希。源码用createHash(sha256).update(buffer).digest(hex)以哈希为 key 统计hashCounts。判定严格多数阈值是Math.floor(N / 2) 1针对启动的总数N不是成功数。若达到阈值把胜出补丁复制为.loop-sandbox/patches/consensus.patch。清理所有临时 worktree由每个loop-sandbox的finally清理路径完成。一个重要的特例无变更共识源码中成功运行但!r.hasChanges || !r.patchFile的智能体被计为noChangeCount。如果noChangeCount threshold则判定达成共识——共识内容是无需任何变更✅ Consensus reached! 2/3 agents produced NO changes (success).此时不生成consensus.patchconsensusPatchFile: null但整体成功。这一点非常实用对于检查后确认无需修改这类任务多数智能体一致地什么都没改本身就是高置信度的安全结论而不是失败。多数补丁落盘与分歧补丁当存在多数补丁时源码 swarm.ts 的if (maxCount threshold majorityHash)分支✅ Consensus reached! 2/3 agents produced the exact same patch. Consensus patch saved to: root/.loop-sandbox/patches/consensus.patch胜出补丁取自多数哈希中的第一个代表文件hashCounts[majorityHash].files[0]复制到同一patches目录下的consensus.patch。其余哈希对应的补丁作为divergentPatches返回供审计参考。若maxCount未达阈值则打印❌ Swarm failed to reach consensus. (Highest agreement: X/N)并判定失败。退出码与行为约定tools/loop-swarm/README.md 明确规定了两个退出码与整个工具链loop-context、loop-gate的约定风格一致退出码含义0达成共识——要么在某个补丁上达成要么在多数智能体成功且未产生补丁即无需变更上达成1未达成共识或工具内部失败含 CLI 参数错误、命令缺失、异常抛出实现上cli.ts 依据runSwarm返回的result.reached决定process.exit(0)还是process.exit(1)。因此loop-swarm可以干净地嵌入 CI / 调度脚本0放行非0即中止并交人工处理——这正是 L3 自动化所需的机械判定。底层隔离机制依赖loop-sandbox的临时 worktreeloop-swarm本身不重复实现隔离而是逐次调用cobusgreyling/loop-sandbox的runInSandbox见 tools/loop-sandbox/src/sandbox.ts。每个沙箱执行校验当前目录是 git 仓库isGitRepo生成运行 idsandbox-8位hex。用loop-worktree的createWorktree从当前 HEAD 创建临时分支与 worktree进程cwd指向该隔离树。以stdio: inheritspawn 用户命令Windows 下若npx/tsc等.cmdshim 抛ENOENT会自动通过 shell 重试一次源码中的supersededByRetry机制避免抢占真实结果。命令结束后git add -A并git diff --cached --binary提取补丁含未跟踪文件、支持二进制写入.loop-sandbox/patches/runId.patch。finally中统一清理kill 残留子进程、释放可选 advisory lock、git worktree remove --force、删除loop/runId分支并 gc——保证主仓库保持干净。这解释了loop-swarm的产物为什么是patch文件而非直接改代码共识只决定哪个补丁被选中应用与否仍由你或后续 gate决定。人工审查补丁的方式与单沙箱一致npx cobusgreyling/loop-sandbox review git apply .loop-sandbox/patches/consensus.patch安全边界与已知限制务必先读tools/loop-swarm/README.md 与 docs/QUICKSTART.md 同时强调以下限制这也是设计文档要求Notes limitations ... with a link to safety docs的原因字节级一致共识共识依赖补丁字节的精确 SHA-256 哈希。两个智能体产出语义相同但空白或注释顺序不同的代码会被判定为分歧。这是当前实现最需要意识到的假阴性来源——安全优先于召回。共享标准 IO顺序执行的智能体共享父进程的标准输入输出不适合需要独立交互式终端的命令。时间代价执行被串行化以维持 manifest 上的安全保证--count 3大约耗时单次运行的 3 倍README 原话roughly 3x as long。SIGINT 处理因为loop-sandbox是进程内运行其信号处理器会在收到SIGINT时退出整个进程运行中收到信号会让整个 swarm 退出而非交给 swarm 自己的清理流程。README 明确这是 v1 限制留待后续子进程化实现。不是 OS 沙箱loop-swarm提供的是 git worktree 隔离进程仍保有 OS 级别的文件系统与网络访问能力补丁也不会捕获 worktree 之外或.gitignore的改动见 tools/loop-sandbox/README.md 的[!WARNING]。完整威胁模型与防线请阅读 docs/safety.mdPath Denylist、Auto-Merge Policy、Human Gates 等章节以及其中 Worktree Isolation Consensus Sandboxing 一节对loop-swarm的定位。测试如何验证共识逻辑tools/loop-swarm/test/swarm.test.mjs 用真实的 git 仓库 临时目录跑通五条端到端用例是理解共识语义最直接的样例确定性命令--count 2下两个 agent 写出相同内容 →Consensus reached! 2/2并断言.loop-sandbox/patches/consensus.patch存在且非空。分歧补丁agent 写入Math.random()产生的非确定内容 → CLI 非零退出输出Swarm failed to reach consensus。全部失败agentprocess.exit(1)→ 非零退出输出3 agent(s) failed with non-zero exit codes与失败提示。2/3 多数第三个 agent 写入分歧内容 → 仍判定成功输出Consensus reached! 2/3且生成 consensus.patch。这正是严格多数而非全票一致的体现。无变更多数多数 agent 成功但什么都没写 → 输出Consensus reached! 2/3 agents produced NO changes并成功退出。这五条用例与 swarm.ts 的分支一一对应可作为你理解或复刻共识语义的最小参考集。在工具链与文档体系中的位置快速入门入口loop-swarm是 docs/QUICKSTART.md 中 L2/L3 安全工具链的一节紧随loop-worktree与loop-sandbox的 Ephemeral worktree isolation 之后并在文末的 Copy-paste cheat sheet 中保留一行快捷命令npx cobusgreyling/loop-swarm run --count 3 -- agent-cmd。安全文档docs/safety.md 的 Worktree Isolation Consensus Sandboxing 将loop-sandbox单 agent 临时 worktree 隔离与loop-swarm跨顺序运行要求字节一致共识并列构成 L2→L3 的递进防线。与统一前端的关系设计上loop-swarm不重写统一的cobusgreyling/loop前端入口而是与loop-init、loop-audit、loop-sandbox等专用包一样保持独立、可单独调用。统一 CLI 的分层约定见 docs/cli-front-door.md。实践建议什么时候用、怎么用用在 L3 无人值守改动之前凡是智能体要自动产生代码变更、而错误代价高比如涉及docs/safety.md中 denylist 之外的业务代码的操作先套一层loop-swarm把一次猜变成多数印证。--count权衡默认3是严格多数 时间开销的平衡点任务越关键可上调但要接受近线性的时间增长串行执行。--count 1在语义上退化为单次loop-sandbox运行不构成共识。善用无变更共识对于检查、triage 类任务多数 agent 一致认为无需改动也是有效的高置信度结果退出码 0无需因此误报失败。应用前必查consensus.patch共识只保证多次运行一致不保证改动正确。在git apply .loop-sandbox/patches/consensus.patch前仍应按 docs/safety.md 的 Pre-Flight Safety Check 核对 denylist、auto-merge 策略与人工 gate。一句话总结loop-swarm用顺序多跑几次 严格多数字节一致把智能体的单次不确定输出收敛为可机械判定、可审计、可放心进入下一步的高置信度补丁——它是 loop-engineering 从 L2 迈向 L3 无人值守时最直接的一道共识防线。赞分享人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载相关推荐WebLLM 函数调用Function Calling实战指南手动解析与 OpenAI 协议两种实现方案WebLLM 函数调用Function Calling实战指南手动解析与 OpenAI 协议两种实现方案 本指南以 examples/function c人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务loop-engineering Dependency Sweeper Starter用 L2 补丁级自动化与强验证门禁守护依赖面loop engineering Dependency Sweeper Starter用 L2 补丁级自动化与强验证门禁守护依赖面 Dependency Sw人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务loop-engineering CI/CD部署指南用GitHub Actions与loop-action实现Agent循环无人值守运行loop engineering CI/CD部署指南用GitHub Actions与loop action实现Agent循环无人值守运行 loop engin人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考