无人参与全链路编码agent
本文整合三条线索，梳理如何构建一个真正 无人参与的全链路编码 Agent 系统：
- Stripe Minions — 企业级无人值守编码 Agent 的架构蓝本
- Claude Code
/goal— 条件驱动的自主评估循环 - OpenCode
/ulw（Ultrawork） — 最大强度的多 Agent 编排循环
一、三条线索的核心贡献
┌─────────────────────────────────────────────────────────────┐
│ 无人全链路编码 Agent │
│ │
│ ┌─────────────────────┐ │
│ │ ⚙️ Minions │ ← 结构层：做什么、按什么顺序 │
│ │ Blueprints (状态机) │ 确定性节点 + LLM 节点混合编排 │
│ └────────┬────────────┘ │
│ │ 调度 │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ 🔁 /ulw (Ultrawork) │ ← 编排层：怎么做、派谁做 │
│ │ 多 Agent 并行 + │ 平行探索 → 深度研究 → 代理执行 │
│ │ Ralph-Loop 兜底 │ │
│ └────────┬────────────┘ │
│ │ 执行 │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ ✅ /goal │ ← 评估层：做完了吗？ │
│ │ 轻量模型每轮评估 │ 条件满足 → 停；不满足 → 继续 │
│ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
| 层 | 代表 | 核心解决 | 类比 |
|---|---|---|---|
| 结构层 | Minions Blueprints | 确定性与自由度的平衡 — 什么步骤用脚本，什么步骤用 LLM | 代码结构（if/else/for） |
| 编排层 | /ulw Ultrawork | 多 Agent 并行调度的强度 — 同时探索、研究、执行 | 多线程并发 |
| 评估层 | /goal | 何时才算做完 — 用独立轻量模型客观评估条件 | 单元测试断言 |
三条线索 不冲突，是互补关系。一个完整的无人值守系统需要三层全部覆盖。
二、Stripe Minions 架构回顾
核心目标： 构建完全独立执行任务、编写代码并提交 PR 的 AI Agent 系统。每周成功合并超过 1300 个 PR。
定位： 不是"结对编程助手"，而是"独立打工人"——接收任务，在隔离环境自主编码、跑测试、修 bug，最终提交不包含任何人写代码的 PR。
五大核心挑战与解法
| # | 挑战 | 解法 | 对应架构层 |
|---|---|---|---|
| 1 | 环境隔离与互相干扰 | 标准化 Devbox，热启动 10s，随用随毁 | 基础设施 |
| 2 | 缺乏人类确认的失控风险 | 沙箱化 QA 环境，爆炸半径受限，跳过确认提示 | 安全策略 |
| 3 | 确定性与自由度平衡 | Blueprints 状态机：脚本节点 + LLM 节点混合编排 | 结构层 |
| 4 | 上下文过载 | 静态：局部规则文件；动态：MCP Toolshed 网关（~500 工具） | 信息架构 |
| 5 | 试错成本失控 | 反馈左移：本地 lint 自修 → 一次 CI 修复机会 | 成本控制 |
Blueprints 状态机（核心创新）
┌──────────────┐
│ 任务解析节点 │ ← 确定任务范围
└──────┬───────┘
▼
┌──────────────┐
│ 环境准备节点 │ ← Shell: git clone, install
└──────┬───────┘
▼
┌──────────────┐
┌───────►│ LLM 编码节点 │ ← Agent 自由写代码
│ └──────┬───────┘
│ ▼
│ ┌──────────────┐
│ │ 本地 Lint 节点 │ ← Shell: eslint, tsc
│ └──────┬───────┘
│ ▼
│ ┌─────────────────────┐
│ │ Lint 通过？ │
│ │ (确定性判断节点) │
│ └──┬──────────┬───────┘
│ 失败 │ │ 通过
│ ▼ ▼
│ ┌──────────┐ ┌──────────────┐
│ │ LLM 修复 │ │ CI 提交节点 │
│ └────┬─────┘ └──────┬───────┘
│ │ ▼
└───────┘ ┌──────────────┐
│ CI 结果判断 │
└──┬──────┬────┘
失败 │ │ 通过
┌────▼┐ ▼
│ 一次│ PR 自动提交
│ 修复│
└─────┘
关键设计原则：
- 能用脚本解决的问题坚决不用 LLM（Lint、Git Push、环境准备）
- LLM 只做需要"理解"的工作（写代码、分析错误日志）
- 每个节点都有确定的输入/输出契约
- CI 修复只给 一次 机会，防止无限烧钱
三、Claude Code /goal — 条件评估循环
/goal 是 Claude Code 在 2026 年 5 月 v2.1.139 中引入的命令。它不是让 agent 更快，而是让 agent 知道什么时候该停。
架构
用户: /goal "重构 auth 模块直到所有测试通过"
│
▼
┌──────────────────────────────────────────┐
│ Agent 主模型 (Opus/Sonnet) 执行一个 turn │
│ 读代码 → 改文件 → 跑测试 → 产出结果 │
└──────────────────┬───────────────────────┘
│ turn 结束
▼
┌──────────────────────────────────────────┐
│ 评估模型 (Haiku，无工具权限) │
│ 读取当前对话 + 原始条件 │
│ 判断："条件满足了吗？" │
└──────────────────┬───────────────────────┘
┌──────┴──────┐
▼ ▼
未满足 已满足
→ 返回评估理由 → 记录 achieved
→ 开始下一轮 → 退出循环
关键设计
| 特性 | 说明 |
|---|---|
| 评估者 = 工作者的分离 | 主模型（Opus/Sonnet）干活，评估模型（Haiku）检查。防止「自己说自己做完了」的偏差 |
| 评估者无工具权限 | Haiku 只看对话，不跑命令、不读文件。防止评估过程副作用的产生 |
| 条件即 prompt | "所有测试通过"— 条件直接作为下一轮的指令上下文 |
| 持久化 | 状态保存在线程存储中，claude --resume 可跨会话恢复 |
| 预算控制 | 条件可加 or stop after 20 turns 兜底 |
评估层的核心价值
Minions 缺少的就是这一层。Minions 靠 Blueprints 的结构确定性来防止跑偏，但 Blueprints 无法回答"这个 LLM 节点到底干完了没"。/goal 填补了这个空白：用独立评估模型替代人工判断"是否完成"。
对比：
| 决定"何时完成"的方式 | 例子 | 问题 |
|---|---|---|
| Agent 自己决定 | Claude Code 普通模式 | Agent 有「做完了」偏见，可能跳过边界情况 |
| Blueprints 固定节点 | Minions 原版 | 只能检查确定性条件(lint 过)，无法评估"代码质量够不够" |
| 独立评估模型 | /goal | 轻量模型客观判断，不受主模型乐观偏差影响，可评估软条件 |
四、OpenCode /ulw（Ultrawork）— 最大强度编排循环
/ulw 是 OpenCode 的 ultrawork 模式激活关键字，搭配 /ulw-loop 命令实现自引用循环。
架构
用户: "ulw 实现支付模块"
│
▼
┌──────────────────────────────────────────┐
│ 1. 关键字检测: "ulw" → 注入 ultrawork │
│ 系统提示，激活最大强度模式 │
└──────────────────┬───────────────────────┘
▼
┌──────────────────────────────────────────┐
│ 2. 并行探索阶段 │
│ ┌────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Explore│ │ Librarian│ │ 直接工具 │ │
│ │ 找模式 │ │ 查文档 │ │ grep 搜索 │ │
│ └────────┘ └──────────┘ └───────────┘ │
│ 5-10 个背景 agent 同时运行 │
└──────────────────┬───────────────────────┘
▼
┌──────────────────────────────────────────┐
│ 3. 执行阶段（Sisyphus 编排） │
│ 研究结果到达 → 指导实现 │
│ 复杂问题 → 派 Oracle/Artistry │
│ UI 工作 → 派 visual-engineering │
└──────────────────┬───────────────────────┘
▼
┌──────────────────────────────────────────┐
│ 4. Ralph-Loop 兜底 │
│ 本轮做完 → 检查 completion-promise │
│ 没做完 → 自动注入 continuation 继续 │
│ 默认最多 100 轮 │
└──────────────────────────────────────────┘
核心差异：/ulw vs /goal
| 维度 | /ulw | /goal |
|---|---|---|
| 循环触发 | Agent 判定"做完了" → 检查 sentinel | 每轮结束 → 评估模型检查条件 |
| 评估方式 | 字符串匹配（completion promise） | 独立模型语义判断 |
| 并行度 | 极高 — 同时 5-10 个 background agent | 单 agent，线性执行 |
| 编排模式 | Sisyphus 多 Agent 编排 | 单 Agent 自循环 |
| 适用场景 | 复杂、多步骤、需要深度研究 | 目标明确、可客观判断完成条件 |
| 避免跑偏方式 | 编排层约束（Agent 类型、category） | 评估层约束（Haiku 检查） |
五、三层融合：完整的无人参与编码 Agent 系统
将三条线索融合，得到完整架构：
┌──────────────────────┐
│ 系统总入口 │
│ /goal "实现 X 功能 │
│ 直到所有验收条件通过" │
└──────────┬───────────┘
│ 激活 /goal 评估循环
▼
┌────────────────────────────────────────────────────────────┐
│ /goal 评估层 │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ 每轮结束 → Haiku 评估：条件满足？ │ │
│ │ 不满足 → 返回评估理由，指导下一轮方向 │ │
│ │ 满足 → 记录 achieved，输出最终结果 │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────┬─────────────────────────────────┘
│ 启动一轮执行
▼
┌────────────────────────────────────────────────────────────┐
│ Minions Blueprints 结构层 — 本轮执行计划 │
│ │
│ 1. 环境准备 (Shell) ← 确定性节点，秒级完成 │
│ 2. 代码编写 (LLM) ← Agent 自由决策，但限制在范围内 │
│ 3. 本地 Lint (Shell) ← 确定性节点，不通过 → 跳修复 │
│ 4. 本地测试 (Shell) ← 确定性节点，不通过 → 跳修复 │
│ 5. CI 提交 (Shell) ← 确定性节点，一次修复机会 │
│ 6. 结果汇总 (LLM) ← 输出本轮执行摘要供 /goal 评估 │
│ │
└──────────────────────────┬─────────────────────────────────┘
│ 蓝图执行过程中
▼
┌────────────────────────────────────────────────────────────┐
│ /ulw 编排层 — 蓝图内的 Agent 节点如何执行 │
│ │
│ 遇到 LLM 节点时： │
│ ┌──────────────────────────────────────────────┐ │
│ │ Sisyphus 编排器 │ │
│ │ ├─ 派 Explore 寻找相关代码模式 │ │
│ │ ├─ 派 Librarian 查最新 API 文档 │ │
│ │ ├─ 复杂逻辑 → Oracle 架构评审 │ │
│ │ ├─ UI 变更 → visual-engineering │ │
│ │ └─ 全部并行执行，谁先到用谁的结果 │ │
│ └──────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────┘
执行流程示例
/goal "将用户模块从 REST 迁移到 GraphQL，直到所有集成测试通过"
Iteration 1:
Blueprint: [环境准备] → [LLM: 分析现有 REST 代码] → [LLM: 编写 GraphQL schema]
→ [Shell: 生成 types] → [Shell: lint] → [汇总]
/ulw 编排: 派 explore 找所有 REST 路由 + 派 librarian 查 GraphQL 最佳实践
/goal 评估: "集成测试通过了吗？" → 没通过，代码还没写完 → 继续
Iteration 2:
Blueprint: [LLM: 编写 resolver] → [LLM: 修改调用方] → [Shell: lint] → [Shell: 跑测试]
→ [lint 失败] → [LLM: 修复 lint] → [Shell: lint] → [汇总]
/goal 评估: "集成测试通过了吗？" → 部分测试失败 → 评估理由: "auth 相关 3 个测试失败"
→ 下一轮重点修复 auth 测试
Iteration 3:
Blueprint: [LLM: 修复 auth 测试] → [Shell: 跑测试] → [Shell: lint] → [汇总]
/goal 评估: "集成测试通过了吗？" → 全部通过! → achieved → 输出 PR
三种失败兜底
| 失败类型 | 兜底机制 | 所属层 |
|---|---|---|
| Agent 跑偏写无关代码 | /goal 评估不通过 + 评估理由重定向 | 评估层 |
| LLM 节点无限循环 | Blueprints 确定性节点（lint/测试）卡住流程 | 结构层 |
| Agent 进程挂掉 | Ralph-Loop / /background 持久化 + 恢复 | 编排层 |
六、基建模块清单（三层视角）
如果要从零搭建这样的系统，需要以下模块：
评估层基建
| 模块 | 说明 |
|---|---|
| 条件解析器 | 将自然语言条件转为可评估的结构化形式 → 评估模型的 prompt |
| 评估模型服务 | 轻量模型（如 Haiku）池，无工具权限，只读对话历史 |
| 状态持久化 | SQLite / 文件存储，保存 goal 状态（pursuing/paused/achieved），支持跨会话恢复 |
| 预算控制器 | 监控 token 消耗、轮数，/goal clear 手动中断 |
结构层基建
| 模块 | 说明 |
|---|---|
| Blueprints 定义语言 | YAML/JSON 格式的状态机描述，支持 type: shell 和 type: llm 节点 |
| 工作流引擎 | DAG 执行器，支持节点级重试、超时、条件分支 |
| 节点契约系统 | 每个节点定义明确输入/输出 Schema（Shell 节点 = exit code + stdout，LLM 节点 = 文件变更集） |
| 隔离执行环境 | Devboxes / Docker / 临时 VM，热启动 < 10s，用完即毁 |
编排层基建
| 模块 | 说明 |
|---|---|
| 多 Agent 调度器 | 按任务类型路由到 specialist（explore/librarian/oracle/visual-engineering） |
| MCP Toolshed 网关 | 统一工具 API 层，按任务可见范围动态暴露工具集 |
| Shift-Left 反馈管道 | 本地 lint → 类型检查 → 单元测试，在蓝图中作为确定性节点嵌入 |
| 背景并行执行器 | 支持 5-10 个 background agent 同时运行，结果按需合并 |
七、对比总结
┌─────────────────────────┐
│ Minions (Stripe) │
│ 🏢 企业级 │
│ Blueprints 状态机 │
│ Devbox 沙箱 │
│ Toolshed MCP 网关 │
│ 一次 CI 修复机会 │
└──────────┬──────────────┘
│ 缺评估层
▼
┌────────────────────────────────────────────────────────────┐
│ 融合系统 = Minions 结构 + /ulw 编排 + /goal 评估 │
│ │
│ 优势： │
│ ✅ 结构层的确定性 → 不烧钱在脚本能解决的问题上 │
│ ✅ 编排层的强度 → 复杂任务多 Agent 并行，不线性等待 │
│ ✅ 评估层的客观 → 独立模型判断完成，不受主模型偏差影响 │
│ ✅ 三层各自兜底 → Agent 跑偏、进程挂掉、无限循环都不能致死 │
└────────────────────────────────────────────────────────────┘
▲
┌────────┴──────────┐
│ │
┌────────────┴──────┐ ┌───────┴───────────┐
│ /goal (Claude) │ │ /ulw (OpenCode) │
│ 🧪 评估层 │ │ 🔁 编排层 │
│ Haiku 条件检查 │ │ Ralph-Loop 兜底 │
│ 跨会话持久化 │ │ 多 Agent 并行 │
│ 预算控制 │ │ 深度研究模式 │
└───────────────────┘ └──────────────────┘
核心结论：
Minions 证明了一件事：企业级无人编码 Agent 可行。
/goal提供了它缺少的"客观完成判定"，/ulw提供了它缺少的"高强度多 Agent 编排"。三者融合，才是完整的无人参与全链路编码 Agent 系统。