AI 应用的生意判断
让写代码的 AI 在隔离环境里干活，关键节点停下来等人批准才能继续
01
从用户的一天开始 · 公开事实 + 可观察行为 · 2026-09-23
使用编码 agent 的开发者或团队，在让 agent 自动改代码时，需要把任务放进隔离的 Docker 沙箱运行，并在关键节点暂停等待人工批准后才继续，同时保留可恢复的执行记录。
旧做法是开发者手动在本地或 CI 里跑 agent、自己盯 diff 并手工回滚，或用通用 CI 流水线加人工 review；这些替代不提供 agent 原生的结构化产物交换与关键节点强制批准。
公开材料指向的痛点是：编码 agent 直接在主环境执行会带来不可控的改动与安全风险，而全自动放行又缺少人工把关点；不解决的后果是误改代码或难以回滚。这是从产品能力与工作流结构推出的判断，尚无用户抱怨或事故案例直接佐证。
趋势是 AI 越能自己写代码，人越需要卡点。切入做必须过评审才能合入的研发流程：隔离里干活、批准后才提交，按团队收；定价尚未披露。
推断：相较手工盯 diff 或通用 CI，它把 agent 放进真实 Docker 沙箱执行、在关键节点强制暂停等待人工 Approve，并让 agent 之间交换结构化产物，从而减少事后人工排查与回滚这一步；因此让编码 agent 参与交付、又必须保留人工把关的团队会在需要可审计、可恢复的 agent 工作流时选择它。
① 三个月后 star 是否过 300、有没有企业公开使用案例——这是它从"被围观"到"被信任"的分界; ② 是否推出托管版或团队版定价——商业模式从免费自托管到收费的第一步; ③ 支持的后端数量是否跟随新 agent 工具增长——编排层如果跟不上新 agent 就等于废了
值得拆解。推断：相较手工盯 diff 或通用 CI，它把 agent 放进真实 Docker 沙箱执行、在关键节点强制暂停等待人工 Approve，并让 agent 之间交换结构化产物，从而减少事后人工排查与回滚这一步；因此让编码 agent 参与交付、又必须保留人工把关的团队会在需要可审计、可恢复的 agent 工作流时选择它。
设计人机协作的自动化流程时，先决定"人工审批放在哪一步"， 再决定功能。参考这个顺序：方案审批（便宜）→ 实施 → 结果审查（贵）。 审方案用结构化工件（让批准者有东西可看），审结果用回滚路径兜底。
未披露。 MIT 开源、可自托管，无云服务、无定价页。; 主页展示的产品形态是面向小团队的（parallel-sprint、PM 会话式调度），但都没标价格。 ① 三个月后 star 是否过 300、有没有企业公开使用案例——这是它从"被围观"到"被信任"的分界; ② 是否推出托管版或团队版定价——商业模式从免费自托管到收费的第一步; ③ 支持的后端数量是否跟随新 agent 工具增长——编排层如果跟不上新 agent 就等于废了
让写代码的 AI 在隔离环境里干活，关键节点停下来等人批准才能继续
推断：相较手工盯 diff 或通用 CI，它把 agent 放进真实 Docker 沙箱执行、在关键节点强制暂停等待人工 Approve，并让 agent 之间交换结构化产物，从而减少事后人工排查与回滚这一步；因此让编码 agent 参与交付、又必须保留人工把关的团队会在需要可审计、可恢复的 agent 工作流时选择它。
追踪该仓库的 issue、discussion 与部署文档，确认是否有团队公开报告在真实编码 agent 任务中启用沙箱隔离与人工批准节点的可复现记录。
产品主张帮助用户完成：“让写代码的 AI 在隔离环境里干活，关键节点停下来等人批准才能继续”。具体痛点强度与不采用代价尚未由用户证据核验。
价值闸门未通过，共识闸门未进入。
价值闸门未通过，模式闸门未进入。
价值闸门未通过，求真闸门未进入。
02
市场对照
尚未完成中英文市场对照。待覆盖范围和可核验证据补齐后再给出结论。
03
先给出判断与下一步，再保留完整证据和反例。
开源、可自托管的平台，把编码 agent 变成"可视化编排 + 人机审批 + 可回滚"的交付流程： agent 在真实 Docker 沙箱里跑，按需求换后端（Cursor / Claude Code / CodeBuddy / Trae）， 到关键节点停下来等人批准，产物走结构化工件契约，最后自动提 PR/MR。
作者 cocofhu，单作者主导，MIT 协议，2026-07-24 创建，77 star / 3 fork。 后端 Go（FSM 引擎、API、SQLite、artifact MCP、调度、审计），前端 Vue 3 + Vue Flow （编排画布），沙箱是 Docker + 自研 sandbox-gateway。约 723 个提交，当前 0.2.1-beta。 提交记录里混有 AgentBot 和 Cursor 的提交——作者自己就用 agent 在开发。
判断：一个"让 agent 交付靠谱"的工具，自己就是靠 agent 开发出来的，这条自证链条 虽然不严谨但挺自洽。77 star 说明看过的人认可，但还没到被验证的阶段。
过去让编码 agent 交付代码，默认的卡点是"事后 review"：agent 改完提交 PR， 人来肉眼审查，发现了问题再回滚——而 agent 到底改了哪些文件、为什么这么改， 经常是黑盒，人在 review 时只能重新读懂一遍 diff。
Approving 替代的是这条链的两种形态。一是"PR review 前移"：把审批从"改完全看" 提前到"改之前先批方案"——人批的是 Proposal 和计划，不是事后补救。 二是"回滚从猜变成路径"：失败和回滚在编排图里是显式的边，不用人重新梳理。
它替代的另一种旧行为更基础：以前 agent 工具各自为政（Claude Code 一套、Codex 一套）， 没有一个平台层能把不同 agent 编排进同一个带审批的流程。Approving 想当的是这个编排层。
判断："审批前移到改代码之前"这个设计是对的。人审 PR 是成本最高的审查方式—— agent 已经干完活，推翻意味着重来。审方案是便宜得多的卡点。
未披露。 MIT 开源、可自托管，无云服务、无定价页。 主页展示的产品形态是面向小团队的（parallel-sprint、PM 会话式调度），但都没标价格。
判断：和同类项目一样，这是"开源做分发、未来做云"的经典剧本。 但云服务、企业版、定价全都没有，商业模式还没开始。
| 维度 | 结论 |
|---|---|
| 创始人-产品匹配度 | 未知背景，但自己用 agent 开发这个"管 agent 的平台"，工具和场景高度自洽 |
| 产品洞察力 | 抓住两个真问题：审批应前移到方案阶段，回滚应是显式路径而非事后补救 |
| 技术实现质量 | 架构完整（Go 后端 + 前端画布 + 沙箱网关 + 工件 MCP + 审计），0.2.1-beta 说明在快速迭代 |
| 市场时机 | 好。编码 agent 已跑起来，"让 agent 交付可被审查"正是企业级采用的下一个卡点 |
这是"agent 交付的信任层"，定位踩在正确的时间点上，但还没到验证阶段。
编码 agent 单点跑通之后，企业下一个问题一定是"它改的东西我怎么放心"。 Approving 给的是答案的一部分：让 agent 的工作流可视化、可审批、可回滚， 并且把人审的卡点从"改完全审"前移到"改前先审方案"。
可迁移的规律：审批点在流程里的位置，决定了它的成本。 审方案比审结果便宜一个量级——结果已固化，推翻意味着重来；方案还只是文字，改它只要几分钟。 任何自动化流程设计里，"在哪一步让人说 Yes"是最值得花时间决策的事。
它的短板在编排这一层。 四个后端各选各的（acpBackend），沙箱和凭据平台自己管， 这套东西对想用的人有门槛：得愿意自托管、拉几 GB 镜像、维护自己的沙箱。 这决定了它当前更可能是技术型团队的工具，而不是销售驱动型产品。
和同类竞品的分野：AgentGate、Lelu 那批做的是"权限/策略层"（agent 动作的审批）， Approving 做的是"交付流程层"（把 agent 变成带审批的流水线）。前者更接近安全工具， 后者更接近 CI/CD 的 agent 版。两个方向都成立，Approving 走的是更偏开发交付的那条。
① 三个月后 star 是否过 300、有没有企业公开使用案例——这是它从"被围观"到"被信任"的分界 ② 是否推出托管版或团队版定价——商业模式从免费自托管到收费的第一步 ③ 支持的后端数量是否跟随新 agent 工具增长——编排层如果跟不上新 agent 就等于废了
产品逻辑：设计人机协作的自动化流程时，先决定"人工审批放在哪一步"， 再决定功能。参考这个顺序：方案审批（便宜）→ 实施 → 结果审查（贵）。 审方案用结构化工件（让批准者有东西可看），审结果用回滚路径兜底。
定价结构：无。未披露。
值得关注，但尚在早期。 定位对、设计对（审批前移）、迭代快，这是本批里 "agent 治理"方向最接近可落地形态的一个。但 77 star 和零商业模式说明它还没跨过 从工具到产品的门槛。三个月后拿上面三条验证。
05
产品官网缺失或当前链接只是线索时，从这些检索入口继续核验。