LoopForge：编码智能体的自托管交付平台

用流程图描述软件交付

LoopForge 的标准作业流程不是一段带编号的提示词，而是由依赖关系连接的有向图。节点在依赖完成后启动，可以分叉、汇合、失败重试，也可以把任务送回更早的阶段。仓库内置后端交付、前端交付、缺陷修复和产品方案等模板，团队可以在项目中复制并修改，形成自己的工程流程。

节点类型	在交付流程中的作用
Agent	执行可复用角色，包括提示词、执行器、模型、项目规则、技能、工具和预期产物。
Script	执行构建、测试、检查或报告生成等确定性命令，不需要模型参与。
Human gate	暂停流程，由人员检查证据后批准继续、补充上下文，或把工作退回指定步骤。
Sub-SOP	把另一条流程作为子流程执行，并把声明的交付物导入父流程。
Preview build	构建静态站点并归档输出，为人工验收提供可直接查看的结果。

产物并不是流程结束后顺手收集的附件，而是节点契约的一部分。节点可以声明自己将发布哪些产物，后续步骤再消费这些结果。子流程导入逻辑还会区分真正的新交付物与仅用于传递上下文的摘要和记录，避免把继承来的材料误当成子流程的成果。这样，流程完成与否就更多依赖持久化产物和节点状态，而不是模型在最后一段文字里声称自己已经完成。

内置交付模板展示了典型的工程顺序：澄清需求、设计改动、实现、独立审查、运行测试、人工验收、准备交付。检查失败时可以回到更早的节点；人工门禁没有收到决定之前，后续步骤不会继续；最终交付节点还能再次核对已经验收的代码哈希，防止后续步骤悄悄改变被批准的内容。

角色让智能体行为成为项目资产

一个 LoopForge 角色不只包含提示词。它可以固定执行器、模型、项目规则、技能、MCP 工具、权限模式、产物要求，以及参与的审批门禁。规划、实现、审查和测试因此可以使用不同的角色定义，甚至使用不同的编码工具。内置角色默认使用 CodeBuddy，但每个节点都能独立选择执行器。

同一套角色既能被流程节点调用，也能被主智能体在对话工作区中作为子智能体调度。这样一来，临时对话和标准流程就不会各自维护一份相互漂移的工程规范。审查角色可以直接拿到共享工作区和项目规则，不需要每次重新粘贴上下文；项目调整角色后，也能从运行历史中观察它如何参与后续交付。

生产镜像已经包含 CodeBuddy 与 Codex，Claude Code 会在首次使用时从 npm 安装并缓存。原生部署需要操作者自行提供所选命令行工具。当前需求澄清和通知摘要仍使用 CodeBuddy，而主对话和许多流程节点可以在受支持的执行器之间选择。

仓库交付始终回到需求

处理既有代码时，LoopForge 会在隔离工作区中为相关仓库创建工作分支。它可以检出全部仓库或指定子集，支持自动命名、接续已有分支、新建分支和只读检出，并记录工作分支与基线分支。多仓库需求还能为每个仓库配置不同分支策略，同时保留一条需求级交付记录。

正常交付会推送工作分支并创建或更新合并请求。对于预览环境一类共享分支，也可以选择直接合入模式。直接合入前，平台会在临时工作树中检查冲突，并通过租约防止别人刚推入的新提交被旧状态覆盖；成功后，原来的工作区仍停留在工作分支，需求还需要人工确认收尾。合并请求模式则会持续同步状态，并在目标分支发生合入后推动需求完成。

只在对话里完成的修改也不会脱离需求。若对话工作区明确服务于某项需求，平台会创建或复用需求记录，把工作区、仓库和工作分支关联起来，在提交合并请求后进行跟踪。这样，聊天产生的交付与流程产生的交付可以使用同一套状态口径，成本与成员统计也不会只覆盖流程运行。

可观察性覆盖过程，而不只是最后一段回答

每条流程都会记录节点状态、工具调用轨迹、执行日志、产物和检查点。界面把等待人工处理的节点集中到审查收件箱，也允许用户暂停、恢复、重试、取消或退回某一步。对话工作区同样有队列消息、转向当前生成、暂停或接管流程等控制。长任务因此在中断后仍有明确入口，而不是只剩一段无法验证的聊天记录。

工作区恢复被当作工程问题处理。对话在工具调用期间持有租约，在轮次结束或切换工作区前保存检查点；保存失败时，旧工作区不会被过早回收。重新打开同一工作区会恢复原有文件状态，工作分支也不会因为一次会话切换而重新生成。这些机制不如对话界面显眼，却决定了长时间智能体任务能否在断线、超时或异常退出后继续。

运行遥测和模型用量会汇总到项目、成员和需求报告。令牌与成本使用可配置的公开列表价估算，应该被视为运营参考而不是供应商账单。项目还支持业务领域报告以及静态 HTML、SVG 导出，便于团队离开 Web 界面后继续审阅。

安全边界面向可信团队

默认容器部署会把宿主 Docker 套接字挂载到平台容器中，使流程和对话工作区能够直接启动同级沙箱，而不必重新下载镜像或构建环境。Docker 套接字权限实际上接近宿主控制权。LoopForge 把任务放进沙箱容器，限制宿主路径仓库只能由管理员配置，并通过项目权限控制仓库和设置，但只要账号能够运行流程，就能借助 Docker 在该宿主上执行代码。

因此，文档没有把默认部署描述成多租户隔离边界。任一已登录账号可以列出实例中的项目、需求和运行记录。第一个浏览器账号会成为平台管理员。自助注册默认开启，可以通过 AGENTFLOW_ALLOW_SIGNUP=false 关闭。项目所有者和管理员可以修改项目设置与仓库，个人凭据只由对应账号管理。若要暴露到公网，合理顺序是先限制网络访问并创建管理员，配置 HTTPS，再根据组织策略关闭自助注册，只向可信同事发放账号。

无法接受宿主守护进程暴露的团队，可以移除套接字挂载和本地 Docker 沙箱配置，连接独立的工作节点或执行机器。纯脚本流程仍可留在平台容器内运行。这个方案确实改变了隔离边界，但并没有消除隔离设计本身，操作者仍需管理执行节点、凭据和网络权限。

GitHub 设备授权申请的是仓库级权限，范围大于在 LoopForge 中选中某个仓库。模型密钥保存在个人设置中，而不是宿主全局命令行配置里；平台生成的 Git 提交使用不可投递的平台身份。即便如此，模型密钥、仓库令牌、运行日志和工作区数据都应按生产秘密管理。

验证记录详细，但不是独立基准

仓库提供了相当完整的验证记录，包括 Go 测试、HTTP 接口测试、浏览器路径、干净容器安装、权限检查、真实 Docker 执行，以及一次真实 GitHub 导入、提交合并请求和合入实验。内置七阶段交付流程在使用 CodeBuddy、经过人工澄清与验收后，用 47 分钟完成并推送了功能分支。目标仓库是一个 Python 测试项目，因此这项结果证明的是平台编排和仓库交付链路，而不是对所有框架的兼容性，也不等于完全自主交付。

真实模型运行使用的是 CodeBuddy 与 deepseek-v4.1-flash。Codex 和 Claude Code 有命令、协议及凭据边界测试，但没有用独立付费账号执行真实模型服务。外部知识服务、企业通知、真实多机器云执行池以及所有操作系统也不在完整实测范围内。维护者明确说明验证结果属于历史记录，不代表后续提交自动获得同等结论。

这种证据链比单纯的功能清单更强，因为它写明了哪些项目真实运行、哪些项目跳过，以及修复了哪些可复现缺陷。不过，它不是与其他智能体平台的独立对比，也不能直接证明所有采用者都会获得生产效率提升。采购或部署前，应在准备使用的具体提交、模型服务、仓库和网络环境中重新执行相关验收用例。

平台版与本地版服务不同工作方式

LoopForge 还提供独立的本地命令行包。本地版把内置的经典或便携工作流安装到已有编码助手中，支持 Claude Code、CodeBuddy、Codex、Cursor、Pi、DeepSeek Harness 和 Hermes Agent 等宿主。安装器会把工作流资产写入目标项目，并在 .devflow/install-state.json 中记录受管文件摘要。开发者无需运行 Web 平台、MySQL 或共享容器服务，也能使用内置交付流程。

形态	主要使用者	工作流能力	证据与审批
平台版	共享需求、角色、运行记录和交付历史的工程团队	对话工作区，以及通过可视化设计器维护的自定义流程	共享运行页、人工门禁收件箱、产物、指标和仓库合入状态
本地版	在已有编辑器或终端宿主中工作的单个开发者	安装到项目中的内置经典或便携工作流	artifacts/ 下的文件、持久化流程状态和可选本地看板

两种版本有意保持分离。同一宿主在同一个项目中只能启用一种本地版本，避免状态和产物互相覆盖。当前本地版只运行内置工作流，把任意平台流程导出为独立本地执行仍在计划中。因此，当团队需要集中编辑、发布和治理流程版本时，应使用平台版，而不是把本地版理解成同一引擎的无界面副本。

实际采用时应该看什么

最明确的适用场景，是团队已经愿意使用命令行编码智能体，却无法让它们稳定遵守工程规范。LoopForge 可以固定规划、实现、审查和测试角色，在角色之间插入确定性检查，在关键边界要求人工批准，并把证据挂回需求。它还适合需要多仓库、自托管执行、GitHub 交付和运行可解释性的团队。

采用时应从一个受信任项目、一个范围明确的工作流开始。先运行不需要模型密钥的脚本与审批示例，确认安装、容器和人工门禁；再连接一个可丢弃仓库，用团队已有模型执行小范围修复。扩大范围前，应验证分支权限、Docker 隔离、凭据处理、注册暴露面、成本统计和目标交付分支。内部评估应比较旧流程与 LoopForge 在相同任务集上的结果，而不是直接引用仓库里的历史验证数字。

限制同样需要正视。平台不适合隔离敌意租户；对话工作台当前以中文为主，管理页支持中英文；默认流程角色使用 CodeBuddy，需求澄清和通知路径也依赖它；本地版还不能导出任意平台流程；模型成本、延迟和服务故障仍属于外部运营风险；人工门禁必须由真正理解上下文的人值守，否则审批只会变成机械点击。

这些边界没有削弱项目的核心价值。LoopForge 把编码智能体当作交付系统中的一个组件，并显式管理角色、仓库、沙箱、流程版本、产物、检查点、审批和合入结果。对于希望从演示效果走向可追责工程交付的团队，这种架构比继续把风险藏在一段更长的提示词里更有实际意义。