客户让 AI Agent 改网站，怎样避免直接碰生产？CommonForge 用隔离工作区串起审核与发布
当代理团队替客户维护网站，客户提出“改一下首页文案”后，开发者常要在需求沟通、代码修改、预览和上线之间来回切换。若再让客户自己的 AI 编码 Agent 直接访问项目，权限边界和变更审查就更难管理。CommonForge 试图把这条协作链放进一个可自托管的工作区：客户提交任务，Agent 在隔离副本中修改，变更经过检查和 staging 审批后才进入生产。
它不是又一个通用代码生成器，而是围绕“多个客户、人员和 Agent 同时改同一项目”组织工作流。仓库说明其运行在 Cloudflare Workers 与 Cloudflare Artifacts 上；工作区支持按项目导入代码、设定访问策略、创建任务、审查候选版本，并在需要时恢复已接受的版本。项目采用 MIT 许可证。CLI cforge 以普通 Git 工作区承载 Agent 修改，避免把 Agent 的编辑动作藏在不可见的专有格式里。
先划权限，再让 Agent 接任务
一个容易忽视的安全点是：提示词并不是权限系统。CommonForge 将文件夹访问策略交给项目所有者配置，选项包括允许修改、只读或不可访问。客户可以提交任务，但任务文本本身不能扩大 Agent 可触及的范围。默认情况下，新客户的项目访问为只读，所有者再按需授权。
工作流大致分为三段：
- 建立项目与策略：导入公开 Git 仓库，配置生产发布目标；需要 staging 时，在项目策略中启用它。首次发布先于 staging。
- 分配任务与工作副本：客户提交任务，开发者或 Agent 获取任务工作区。Agent 使用 CLI 在隔离副本中完成修改，而非直接写生产环境。
- 提交候选、检查并审批：变更进入候选审查流程，先检查、预览，再由有权限的人批准发布；接受的版本可追踪和恢复。
这里的价值不在“Agent 自动上线”，而在把 Agent 输出明确变成一个待审候选。是否自动执行检查、如何定义发布目标、谁能批准，仍须由团队按自己的项目策略配置，不能把工具提供的流程控制误读成对代码正确性的保证。
CLI：把任务工作区还原成普通 Git 操作
官方 npm Registry 当前列出的 CLI 包为 @commonforge-org/cli，版本 0.1.0，许可证 MIT；README 要求 Node.js 22 或更新版本，以及 Git（使用 Git LFS 的目录还需 git-lfs）。安装方式：
npm install -g @commonforge-org/cli cforge --version
CLI 没有默认托管 API 地址。登录时应指定你自己的 CommonForge 部署地址：
cforge login --api-url https://api.example.com --email you@example.com cforge whoami
README 说明，URL 可保存在配置中，也可通过 --api-url 或 CFORGE_API_URL 为命令指定；没有配置时，CLI 使用本机 http://localhost:8787（供本地 wrangler dev 使用），普通 HTTP 仅接受 localhost。不要把示例域名当成真实服务端点。
找到任务后，工作区可以这样取出：
cforge project list cforge project tasks <projectId> cforge checkout <taskId> ./work
在工作目录中像平常一样用 Git 编辑与提交。需要保存可恢复的中间进度，可执行 cforge checkpoint --commit "WIP"；准备提交审查时使用 cforge submit --commit "Update landing page copy"。前者会推送检查点但不冻结，后者推送并冻结为候选，命令会打印候选 ID。若不传 --commit，只有已提交的改动会被推送。完成前可用 cforge status 检查任务与本地工作区状态。
适用场景与落地前检查
CommonForge 面向需要把客户请求、Agent 编码和人工发布审批连起来的代理团队，尤其适合多个项目并行、需要限制目录访问、希望保留候选版本与回滚线索的场景。README 还列出 CLI 的 MCP 模式，可将登录、任务列表、检出、保存进度和提交等操作提供给支持 stdio MCP 的应用；不同客户端的配置步骤各异，实际启用前应以仓库中 CLI README 为准。
它并不意味着无需工程治理：部署需要自己的 Cloudflare 账户和配置，API 地址必须指向实际部署；“检查通过”也不等于业务验收，仍应运行团队自己的测试、审阅差异并验证预览环境。第一次试用时，建议先用非生产项目验证任务授权、隔离目录、staging、审批和恢复流程，再导入真实客户项目。这样才能确认自动化边界符合团队的交付责任，而不是只看 Agent 是否成功生成代码。
相关链接