Capabilities › Quant v1.1 › 工程协作框架
我们如何用 AI 开发 AI 系统，而不让 AI 失控
多个 Agent 可以建议、起草、实现，但最终方向和高风险授权永远在人手上。这不是口号——这是我们在自己的工程实践里强制执行的纪律。
2026 年了，“用 LLM 写代码”已经不是难题。难题是当这些代码、配置、运行时变更要进入真正的生产环境时——谁负责？谁批准？怎么追溯？什么时候必须停下来等人？这一层工程框架就是为回答这些问题而存在的。
AI 可以加速研发，但最终方向、高风险授权、生产部署永远在人手上。
为什么这一页对应能力 03
“人主导的多 Agent 开发”作为 yunforce 的核心能力之一，需要在真实压力下被验证——不是在一两个 demo 任务里，而是在一个跨越多个月、涉及高风险变更、需要长期工程纪律的项目里。Quant v1.1 是我们实施这套方法的场地。
这一页讲的是这套方法的完整机制：它如何分配角色、设定边界、强制暂停、保留证据，让多个 AI Agent 协同工作而不失控。
关于“AI 开发 AI”，客户最常问的三个问题
我们直接回应。
你们用 AI 开发，会不会失控？
不会。最终方向、高风险授权、生产部署都由人类审批。Agent 可以建议和起草，但不能自己决定推进。三个关键节点（规格、计划、实现）上，系统强制暂停等待人工批准。
多个 Agent 一起工作，会不会互相乱改？
不会。每个 Agent 有明确的角色边界：产品 Agent 只能审查、不能实现；开发 Agent 只能改代码、不能部署；运维 Agent 只能在已批准的范围内执行；研究 Agent 只读，不写入正式系统。跨边界的动作需要明确委派。
AI 做的事情出了问题，谁负责？谁来回溯？
最终责任人始终是人类审批者——因为是他们批准了变更。回溯靠的是证据：每一次 Agent 的建议、计划、实现、部署，都通过 GitHub 议题、commit、审查文档、关闭评论留下完整可审计的轨迹。
真正的问题，不是 AI 能不能产出
我们使用多个 Agent，但目标不是最大化自主性。
目标是一个许多贡献者都能帮忙的系统，而不侵蚀问责、执行纪律或可审计性——一旦工作变得真正运营化。
许多 Agent 可以贡献。只有人类能批准最终方向。
组织不能比软件更不守纪律
Quant v1.1 在运行时已经分离了建议、审批、执行和证据。这个项目的团队运营方法刻意采用了相同的形状——这样组织就不会比软件更不守纪律。
产品运行时
- -顾问 / 研究对象 → 治理对象可以建议，但不执行
- -人类审批 → 决定是否授予权限
- -执行系统 → 仍是唯一执行权威
- -证据与验证 → 每一个有意义的动作都以证据闭合
团队运营系统
- -Agent 建议和构建 → 在定义的角色边界内贡献
- -人类批准 → 直接授权保持在人手上
- -开发 / 运维执行 → 实现和变更只通过被分配的执行角色发生
- -证据闭合 → GitHub 评论、审查文档、测试结果闭合循环
关键设计选择：审批门、执行边界、证据轨迹不只是产品特性。它们也是团队运营规则。
运营模型被分成四个独立的控制层
角色框架
产品框定和审查，开发实现，运维执行运行时跟进，副驾驶路由，研究保持只读，人类最终决策人保留最终权威。
授权框架
高影响变更需要直接授权：生产系统重启、外部接口写入、配置切换、治理覆盖、凭证、生产状态声明。
执行框架
工作通过一条可重复路径流动：议题、规格确认、实现计划、产品审查、实现、实现后审查、授权门、验证、证据闭合。
恢复框架
恢复是系统设计的一部分。在压力下应用相同纪律：保留证据、陈述失败、定义回滚路径、保持权威边界可见。
上面已经展示了核心机制（四层框架、三个暂停点、最终权威、三个客户问题）。下面进入完整角色拆解和执行路径——属于深度内容，不必读完。
不同的 Agent 服务于不同的任务，而不是可互换的声音
人类最终决策人
方向、委派、授权边界的最终决策拥有生产 go / no-go 决策
不把最终批准权委派出去
产品 Agent
塑造议题、规格、验收逻辑、推广边界对照风险和范围审查实现
不应成为默认实现者
开发 Agent
起草实现计划和测试计划修改代码、测试和技术文档
不为了通过绿色检查而削弱测试，也不部署
运维 Agent
拥有运行时连续性、服务器支持、监控、证据收集在运行手册和授权边界内执行
不把转达的批准当作变更许可
副驾驶 Agent
协调和转达；它是路由层，不是内容层保留项目方法和明确的交接
不成为隐藏的第二审批者
研究 Agent
只读研究和分析为产品审查产出发现
不实现代码，不触碰正式系统路径
仓库边界：本地 Agent 默认只在自己的主仓库内编辑和提交。跨仓库编辑需要明确的人类委派。
工作路径刻意比“问一下 Agent”更重
工作流系统和审查流程为工作强制了一个共享形状。这让计划、实现、审查、运行时授权保持分离，而不是塌缩进单一对话。
议题与范围
工作从一个明确的议题开始，带有问题、动作、验收、测试契约。
产品确认规格
在开发计划任何东西之前，产品检查这个切片是真的、有边界、可实现的。
开发起草计划和测试
实现计划和验证计划一起起草，包括授权期望和回滚条件。
产品审查计划
产品批准、拒绝，或带发现循环直到计划可接受。
开发实现
代码、测试、技术文档在批准范围内变更，并带 Agent 归属推送。
产品实现后审查
对照批准的计划、真实文件、实际测试 / 证据界面审查实现。
授权与发布
如果需要运行时变更，产品和开发就验证计划对齐，然后由人类最终决策人授权动作。
证据闭合
审查文档、议题评论、日志、测试输出、关闭评论保存了什么改变了、为什么完成了。
三个强制暂停点
规格缺口 — 切片还没准备好；产品必须澄清或缩小它才能让开发计划
计划批准 — 计划可接受、实现可以开始，但批准本身是明确的
实现批准 — 代码可接受；如果需要部署，下一步是授权，而不是静默执行
工作流由边界定义，而不是由某个模型厂商定义
LLM 厂商会变，模型 API 会变，账户会被限制。一个真正的工程框架不应该绑死在任何特定供应商身上。这是我们专门为“压力情景”做的三个设计。
角色名高于模型名
仓库标签是角色名优先，供应商名其次。这让运营层比当前模型分配更稳定。
工作流逻辑外部化
中继协议、暂停点、工作流系统活在文档和脚本里，而不是在某一个模型的记忆里。这让路径可复现。
模型失败变成换装问题
如果一个角色能在保持相同范围、证据、权威契约的前提下被重新映射，系统在供应商或账户压力下会更优雅地降级。
两个方法论，两个层面，各自独立
yunforce 对外有一个 PROOF 方法论，讲我们如何为客户交付 AI 项目。本页讲的工程协作框架不是同一回事——它是这个特定自研项目内部使用的工程协作机制。
PROOF 方法论 → 对外，跨项目，关于“我们如何与客户共同推进一个 AI 落地”
工程协作框架 → 内部，单项目，关于“一个多 Agent 团队如何在不失控的前提下推进高风险工程变更”
两者解决不同的问题，互相不替代。把它们都展示出来，是因为我们认为客户值得看到——一家声称“懂 AI”的公司，是怎么在自己的工程实践里管住 AI 的。