腾讯开源的 LoopForge：让 Agent 按流程交付，而不是看它这次发挥

LoopForge 想解决的是”让 Agent 修个 bug，结果全看它这一次的运行”这件事。它把方案、实现、评审、测试、人工验收拆成一条可重复执行的 SOP，Agent 只负责流程里该它干的那一步。

它是什么

LoopForge 是腾讯轻量云团队开源的一个可自主部署的团队工作台（MIT 协议），让你和编程 Agent 一起交付软件。官方给的定位很直白——面向 Agent 交付的 GitHub Actions。

GitHub Actions 是把”跑什么脚本”写成 workflow，LoopForge 把”谁来干活、在哪个沙箱里、按什么顺序、经过哪些检查、由谁签字”写成 SOP。

换个说法：直接给 Claude Code、Codex、CodeBuddy 说”修一下这个 bug”，结果往往赌运气——它可能跳过方案、忘了跑测试、自己评审自己的代码，也可能做到一半停下没人发现。做演示没问题，团队交付不行。LoopForge 就是在这堆 CLI 外面套一层角色、沙箱、检查点和留痕，让每次交付都按同一套流程走。

干活的是编程 Agent CLI，LoopForge 自己不做模型推理。它支持 10 种执行器：CodeBuddy、Codex、Claude Code、OpenCode、Cursor CLI、Antigravity、Kimi Code、Pi、DeepSeek Harness、ZCode。

截至写稿时，仓库数据：star 186，fork 33，创建于 2026-07-28，9 个 release。

它对付的问题

一个能跑的自部署平台，文档里把它要解决的问题讲得比多数同类更具体。核心是四件事。

可重复。 同一条 SOP、同样的阶段、同样的检查，每个需求都一样。内置后端、前端、缺陷修复、产品方案四类 SOP 可以直接起步。

角色分离。 方案、实现、评审、测试各有独立的角色提示词、执行器、模型、规则、Skills 和 MCP 工具。一个角色既能当 SOP 节点，也能在对话里作为子 Agent 被调用。

人在回路。 在关键节点设置人工审批：看完报告再放行，或打回到指定环节返工。

可观测、可续跑。 节点状态、工具轨迹、日志和产物集中呈现；支持暂停、重试失败步骤、从任意节点重跑。

技术上有个细致处理：“不需要 AI 的地方就不用 AI”。SOP 里的”脚本”节点是确定性的 Shell 步骤——构建、测试、Lint、生成报告，这些都交给脚本，不浪费一次模型调用。哪一步该让 Agent 发挥智能、哪一步该走确定性逻辑，流程定义里分得很清。

核心机制：一次运行里，Agent、脚本和人怎么衔接

SOP 是每次交付遵循的工作流。节点有五种：

节点	作用
Agent	一个角色（提示词、执行器、模型、规则、Skills、MCP 工具），负责设计、实现、评审或测试
脚本	确定性 Shell 步骤：构建、测试、Lint、生成报告
人工关口	暂停运行，等人检查产物后放行，或打回到指定环节
子 SOP	把另一条 SOP 作为子流程复用
预览构建	构建静态站点并归档，供评审查看

每个节点声明自己的产物和依赖，依赖完成后引擎自动推进下一步。流程设计器是一个可视化画布，每个步骤选一个角色，检查失败时可以把工作打回到前面的步骤。

README 里记录了团队实际跑过的一次交付，这是全文最实在的一段验证：

四个 CodeBuddy 角色依次完成 Python 修复的规划、实现、独立评审和交付汇总；三个真实测试通过，运行等待人工批准，批准后再次验证代码与验收时一致。

注意细节：“独立评审”是单独一个 Agent 角色做的，不是让实现者自己评自己的代码——这个设计直接对治了”Agent 自评自夸”的通病。而且人批准后还要”再次验证代码与验收时一致”，防止 Agent 交付的代码和验收时不一致。这条链路已沉淀成可复用的 E2E 验收用例。

类似 GitLab 的 CI/CD 但把”跑什么”换成”谁来干”。一条流水线里 Agent 负责动脑的环节，人负责拍板，脚本负责不让人糊弄。

两种工作方式，都挂在同一套需求上

	与 Main Bot 对话	运行 SOP
适合	探索、快速修复、反复迭代	阶段固定、需要签字确认的可重复交付
怎么跑	Main Bot 按需打开带项目仓库的 Docker 沙箱，把项目角色作为子 Agent 调用	引擎按顺序执行 Agent、脚本、人工关口、子 SOP，每次运行独立沙箱
你怎么把控	回复中途排队或”引导”消息；对话里暂停、恢复或接管正在运行的 SOP	在人工关口审批；打回到指定环节返工；从任意节点重试或重跑
交付物	PR/MR，或直推合入共享分支（mode=direct）	文档、代码或 PR，以及每个节点的产物和日志

两种方式都挂同一套”需求”：无论改动来自对话还是 SOP，都能追溯到原始需求，计入交付与成本统计。

不想部署服务端？还有 LoopForge Local

LoopForge 是个完整平台，要 Docker + Python 3，./start.sh 拉 GHCR 镜像。如果你只想要那套交付工作流，可以直接装进现有的编程助手：

# 在目标项目目录里执行，例如装进 Claude Code
npx -y loopforge-cli@latest install claude

然后在 Claude Code 里运行 /start-devflow "你的需求"。

LoopForge Local 支持 Claude Code、CodeBuddy、Codex、Cursor（Classic 和 Portable 版）、Pi（Portable 版）。它的依赖只有 Node.js 20+、Python 3.8+ 和一个编程助手，不跑平台服务。

落地与限制

能干什么：

• 免 API Key 就能体验——新账号会自动进体验项目，里面有一条只含脚本和人工审批的 SOP，跑通整个”生成报告 → 等人确认 → 继续执行”的流程。
• 修改已有仓库并提 PR：连接 GitHub（内置授权应用，设备码授权，不需要自己申请 PAT），配好执行器凭据即可。
• AI 定时任务：周期性 Agent 任务，共享任务市场提供带版本和参数的任务模板。
• 每个需求全程跟踪，支持 PR/MR 状态跟踪、合入检测、共享分支直推。

要注意的限制：

• 对话和 Agent 步骤需要所选执行器的 API Key。平台不附带模型额度，凭据都得自己配。CodeBuddy、Codex、DeepSeek Harness 内置在 Docker 镜像里；Claude Code、Cursor 等首次使用时从 npm 或厂商安装脚本装。
• Docker socket 赋予了平台控制宿主机 Docker 的权限，所以只适用于可信团队，不能当作不可信多租户的隔离墙。新安装默认监听所有网卡，开放前要读账号与访问控制文档、配置 HTTPS。
• 国内拉 ghcr.io 经常中断。官方方案是设 MIRROR=ghcr.nju.edu.cn ./start.sh（或用其他能替换 ghcr.io 的镜像站），用 digest 校对镜像。注意：Docker 引擎里的 registry-mirrors 只加速 Docker Hub，不能填在这里。
• 需求澄清、AI 汇总、Bot 回复、运行评测目前固定用 CodeBuddy 的模型——如果你想让解释环节也走别的执行器，这四类入口不接受，服务端会拒掉并说明原因。

关于”内部 20+ 业务落地、单月自动完成 200+ 需求与单据交付”，这是腾讯官方公告文章的说法，README 里没有这些数字，属于团队自述而未由外部独立核实——参考时可留意它的口径。

落点

LoopForge 真正想改变的是：把”这次 Agent 发挥得怎么样”变成”这条流程稳不稳定”。它不是又一个能写代码的 CLI，而是把代码 CLI 编排进一条带角色分工、确定性检查、人工签字的交付流水线。GitHub 上现在 186 个 star，还早，但它解决的”Agent 自评自话、做到一半没人发现”恰好是很多团队卡住的地方。

要不要用它，取决于你的团队是不是已经到了”单机 Agent 能写代码、但交付质量全看单次运行”的瓶颈。

仓库地址：https://github.com/Tencent/LoopForge 官方文档与在线预览：https://loopforge.cn

---

事实与来源说明

• 功能、节点类型、SOP 机制、真实交付记录、镜像方案、API Key 要求、Docker socket 权限说明：来自仓库 README.zh-CN.md 及 docs/validation.md 原文。
• star/fork/release 数、创建日期：来自 GitHub 仓库页面公开数据（写稿时快照）。
• “内部 20+ 业务落地、单月 200+ 需求交付”：来自腾讯官方公告文章（腾讯云开发者社区，2026-11-09），为当事方自述，未独立核实。

---

#LoopForge #编码Agent #AI编程 #SOP #开源项目 #研发效能 #腾讯开源 #AI工程化