📌 项目地址：Tencent/LoopForge | ⭐ 796 颗星 | 🔧 Go
问题很具体：一次性的 agent 跑不了团队交付
你让 Claude Code 或 Codex “修这个 bug”，结果全看那一次的运气：它可能跳过规划，可能忘了写测试，可能自己审自己的代码，也可能跑到一半就停了，没人发现。个人玩玩没问题，团队用这种方式交付需求不行。
腾讯开源的 LoopForge（Go 写的，MIT 协议，star 数接近 800，截至发稿）解决的正是这个。它的思路不是再造一个更强的 agent，而是在现有的编码智能体外面包一层流程壳：角色分工、Docker 沙箱、检查点、历史记录。底层执行者你自己挑，支持 CodeBuddy、Codex、Claude Code、OpenCode、Cursor CLI、Antigravity、Kimi Code、Pi、DeepSeek Harness 和 ZCode 共十种 CLI。
核心概念叫 SOP（标准作业流程）：把一套被验证过的工作方式固化成流水线，节点类型有四种，Agent、Script、Human-gate、子 SOP。下次同类需求进来，走同样的流程、跑同样的检查，审批环节直接内建在流程里。
两种用法，对应两种场景
README 里用一张表讲得很清楚，我直接拆开说。
聊天模式：适合探索、快速修复、和 agent 来回迭代。你在聊天里向 Main Bot 描述需求，它会按需开一个会话工作区（一个 Docker 沙箱，里面已经 checkout 好你的仓库），把任务委派给各项目角色作为子智能体去执行，最后开 PR。回复跑到一半你也能插话排队或纠偏，正在跑的 SOP 也可以随时暂停、恢复或手动接管。
SOP 模式：适合正式交付。引擎按顺序执行各个节点，每个节点跑在各自的沙箱里。到 Human-gate 节点时流程停下，你读报告、批准，或者打回到指定步骤重做，也可以从任意节点重试或重跑。
两条路径背后是同一套需求追踪。不管改动来自聊天还是 SOP，都能关联回原始需求，并计入交付和成本报表。产出的形式可以开 PR/MR，也可以直接合并进共享分支（mode=direct）。
我觉得最值钱的两个设计
角色是真拆开的。规划、实现、评审、测试，每个角色有自己独立的 prompt、执行器、模型、规则、Skills 和 MCP 工具。这意味着评审角色可以换个更强的模型，或者干脆换个不同的 CLI 执行器。同一个 SOP 里不同角色用不同组合，这个自由度很少有同类工具给到。
人工审批是流程节点，不是外挂。审批关卡就长在流水线里，到点自动停，你处理完再往下走。打回、重试、从任意节点重跑都是原生操作。
另外它自带四类 SOP 模板（backend、frontend、bug-fix、product），起步不用从零画流程图。聊天首页支持 @ 角色、技能、需求、SOP 或仓库，每个会话可以单独选执行器、模型和权限模式。
上手前要想清楚的
README 正文没有给完整的安装命令，部署细节要看仓库的 Docs 部分（比如 conversation-workspaces.md 这类文档），所以上手成本得自己掂量。
几个现实问题：
- 依赖 Docker 沙箱，有运维门槛，不是开箱即用的 SaaS。
- 项目还早期，流程定义和接口可能有变动，建议先内网小范围试。
- 最关键的一点：SOP 固化的是你已有的工作方式。如果团队本身没有清晰的交付流程，固化下来的也只是混乱。这个工具放大的是流程纪律，不是流程本身。
一句话总结：agent 编排工具不少，LoopForge 的差异在于多执行器可插拔、审批内置进流水线、加上自托管和 MIT 协议。对代码不能出内网的团队，最后一条可能就够了。