引言：AI 编程的范式跃迁

过去一年，AI 编程工具从"聊天框里的代码生成器"进化为能够自主执行复杂任务的智能代理。但真正的挑战不在于让 AI 写出代码，而在于如何让 AI 持续、可靠地完成工程任务。

Oh My OpenCode（简称 OmO）正是为了解决这一问题而生。它不是另一个聊天框，而是一套将 AI 从"对话工具"升级为"自动化工程系统"的编排框架。

OmO 封面

OmO 的核心定位：工程化交付而非对话回答

从"会不会答"到"能不能交付"

传统 AI 编程工具的评判标准是"回答质量"，而 OmO 的核心目标是**“工程交付”**。

维度 传统 AI 工具 OmO 的 long-running 编排
人的角色 持续盯盘、补上下文、接管 定义目标、边界、验收标准
状态管理 当前会话上下文为主 plan + boulder + notes + 后台任务
失败处理 人手动改 prompt 倾向自纠偏，再决定是否升级
完成定义 看起来差不多 test/build/LSP 通过 + 验收标准满足
输出物 代码片段 可持续推进的工程结果

OmO 的工作流程遵循"输入 Markdown 描述，输出可运行代码"的心智模型：

1
2
3
4
1. 输入任务 → 2. 判断意图 → 3. 组织执行 → 4. 工程输出
   (任务描述、    (Intent Gate      (并行搜索、         (回到 build/
    repo 上下文、   分清提问/修复/      资料、执行器)       test/LSP，
    工程约束)      实现/调研)                            拿到可验证结果)

[PATTERN] 工程化思维：把 AI 任务从"对话模式"转变为"工作流模式"，每个阶段都有明确的输入、处理和输出标准。

为什么 Vibe Coding 难以支撑复杂工程

OmO 的一个核心立场是：频繁的人类接管，本质上是系统失败的信号。

Vibe Coding 的工程现实

  • 需要人盯着输出，随时接管方向
  • 出错后靠人补上下文、补 prompt
  • 状态主要停留在当前对话窗口
  • 拿到的是片段，不一定是完整交付物

真实工程的要求

  • 变更要过 build/test/LSP/回归
  • 任务可能跨数小时甚至跨多天推进
  • 失败后能继续，不是全部重来
  • 完成必须有清晰的 done 定义和验收标准

Vibe Coding vs 工程现实

[PATTERN] 失败恢复设计：复杂系统必须具备"断点续传"能力——任务中断、失败后能够从上次状态恢复，而非从头开始。

Vibe Coding 的三重工程困境：深度反思

Vibe Coding 并非一无是处——对于制造原型、验证想法、从零搭建新产品，它有独特的价值。但一旦进入存量系统的持续演进，它就会暴露出三个根本性的工程困境。

困境一：上下文窗口与 SDLC 的"无限接力"天然矛盾

LLM 的工作单元是会话（session），而软件开发生命周期（SDLC）的工作单元是项目（project）——两者的时间尺度完全不同。

Anthropic 在其官方工程博客中将这一矛盾描述为长期运行 Agent 的核心挑战：

“The core challenge of long-running agents is that they must work in discrete sessions, and each new session begins with no memory of what came before. Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.”

— Anthropic Engineering: Effective Harnesses for Long-Running Agents

这正是 Vibe Coding 让人焦虑的根源：人类被迫充当"上下文接力员"。每当会话窗口接近上限，就必须手动整理进度、补充背景、重新建立 AI 的工作状态。Thoughtworks 的实验也印证了这一点：

“Contextual awareness is limited. Even with tools like MCP servers, the AI often lacked persistent awareness across sessions. Simulating brownfield development — by starting new chats — often erased prior context, requiring re-explanation.”

没有 harness/checkpoint 机制，跨上下文窗口的工程接力就无从实现。人类不得不随时待命、随时介入，这本质上是把 AI 的架构缺陷转嫁给了人类的注意力。

困境二：单窗口无法支撑多角色并行协作

传统 Vibe Coding 的工作模式是单一对话窗口 + 通用模型，这意味着：

  • 所有任务由同一个"角色"处理，无法针对不同任务激活不同的专业能力
  • 任务只能串行推进，无法并行展开
  • 没有角色分工，就没有关注点分离，也就没有可组合的专业化输出

研究已经证明，Role/Persona 对 Agent 行为有显著影响。不同的系统提示词会让同一个模型产生截然不同的推理路径、关注重点和输出风格。Microsoft Azure 的官方架构指南明确指出：

“Multi-agent systems divide responsibilities across multiple specialized agents. This enables modularity, clearer separation of concerns, and improved scalability.”

单窗口 Vibe Coding 的本质是"一人公司"——所有角色由一个人扮演。而真正的工程交付需要的是"分工协作的团队"。

困境三：缺乏工程契约，导致任务不可拆解、不可管理

Vibe Coding 的"done"定义是模糊的——"看起来差不多"就算完成。这带来了一系列连锁问题：

  • 没有契约（contract），就没有明确的交付边界
  • 没有卡点（checkpoint），就无法实现增量验证
  • 没有验收标准（acceptance criteria），就无法判断任务是否真正完成
  • 没有可拆解的任务单元，就无法在多个上下文窗口之间分配工作

Thoughtworks 的对比实验给出了清晰的结论：当引入 TDD、增量提交、模块化等工程纪律后，AI 辅助编程的输出质量在可测试性、可维护性、可扩展性等维度上显著提升。

解法不是"更好的 Vibe Coding"，而是引入 Agent Team 模式：

  • 用契约（接口定义、验收标准）替代模糊目标
  • 用卡点（build/test/LSP 验证）替代"看起来差不多"
  • 用专业化 Agent 团队（而非 Swarm 的无序涌现）替代单窗口通用模型
  • 用harness 机制（进度追踪、状态持久化、断点续传）替代人类手动接力

Agent Team 与 Swarm 的关键区别在于：Swarm 是无结构的多 Agent 并发，Agent Team 是有角色分工、有内部管道、有任务路由的协作体系。每个 Agent 都有明确的职责边界，任务在进入 Agent 之前会经过提示词增强和意图转化，这使得整个系统的行为是可预测、可审计的。

困境四：缺乏历史架构知识库，面向未来编程能力不足

前三重困境聚焦于"当下任务"的执行层面。但还有一个更深层的困境：Vibe Coding 是无记忆的、无历史的、无方向感的——它只能解读当前代码，却无法理解代码背后的演进脉络，更无法从旧代码中导出软件的发展方向。

这对 legacy 项目（存量系统）的伤害尤为致命。Val Town 工程博客一针见血地指出：

“When you vibe code, you are incurring tech debt as fast as the LLM can spit it out.”

— Val Town Blog, 2025-07-30

SonarSource 的行业调查进一步量化了这一问题：88% 的开发者报告 AI 对技术债务产生了至少一项负面影响，其中 53% 的人指出 AI 生成的代码"看起来正确但实际上不可靠"。这正是因为 AI 在没有历史架构知识的情况下，只能基于当前代码的表面结构进行推断，而无法理解：

  • 为什么某个模块被设计成这样（架构决策的历史原因）
  • 哪些地方是不能动的（隐含的业务规则和技术约束）
  • 系统未来应该往哪个方向演进（技术愿景和架构演进路径）

代码能表达"是什么"，但无法表达"为什么"和"往哪里去"。这两个维度的知识，只存在于工程师的脑子里、散落在文档系统里、或者根本没有被记录下来。

解法：SDD + SDLC 驱动的知识沉淀

Martin Fowler（Thoughtworks）在 2025 年 10 月提出了 Spec-Driven Development（SDD） 的系统性定义：

“Spec-driven development means writing a ‘spec’ before writing code with AI (‘documentation first’). The spec becomes the source of truth for the human and the AI.”

— Martin Fowler, Understanding Spec-Driven-Development, 2025-10-15

GitHub 工程博客则进一步将这一理念推向了更高的层次：

“In this new world, maintaining software means evolving specifications. The lingua franca of development moves to a higher level, and code is the last-mile approach.”

— GitHub Blog, Spec-driven development with AI, 2025-09-02

SDD 的核心洞见是：代码不再是真相的来源，意图才是。当我们用规格说明（spec）来驱动开发时，工程师被强制扮演"项目负责人"的角色——不只是写代码，而是要思考：

  • 过去：这个系统是怎么演进到今天的？有哪些架构决策记录（ADR）需要保留？
  • 现在：当前需求的边界在哪里？验收标准是什么？
  • 未来：这次变更会如何影响系统的演进方向？哪些约束不能打破？

这种思维方式的转变，让 Agent 在工作时不再是"盲人摸象"——它有了历史地图（spec + ADR），有了当前坐标（验收标准），也有了方向感（技术愿景）。

OmO 的 AGENTS.md 正是这一理念的具体实践：它不只是告诉 Agent"代码在哪里"，更告诉 Agent"为什么这样组织"、“哪些是反模式”、“未来的演进方向是什么”。这使得每一次 Agent 工作都能站在整个项目的历史和未来视角上，而不是只看当前窗口里的代码片段。

困境五：缺乏自动纠偏机制与工程级 Rules 体系

前四重困境都指向"如何让 AI 做得更好"，而第五重困境则指向一个更底层的问题：当 AI 做错了，谁来发现？谁来纠正？

Vibe Coding 的纠偏机制是人类——人盯着输出，发现问题就接管，靠人的注意力来兜底。这在原型阶段尚可接受，但在持续演进的工程系统中，这种模式有一个致命缺陷：模型的偏差会被悄悄放大，直到积累到人类无法忽视的程度才被发现。

这不是模型能力的问题，而是系统设计的问题。任何复杂系统——无论是分布式计算、金融交易还是航空控制——都不会依赖单点的人工监督来保证正确性。它们依赖的是内建的自动纠偏机制：

  • 多重校验（cross-validation）
  • 异常检测（anomaly detection）
  • 约束传播（constraint propagation）
  • 角色互相审查（peer review）

Agentic Engineering 把这一工程原则引入了 AI 协作体系。它需要两个层面的纠偏机制同时运作：

第一层：专门调教过的 Agent 互相监督

在 OmO 的架构中，不同 Agent 承担不同的角色，这种角色分工本身就是一种纠偏机制：

  • Sisyphus 作为编排器，不直接写代码，而是验证其他 Agent 的输出是否满足验收标准
  • 验证 Checkpoint 在每个阶段结束时强制运行 lsp_diagnostics、build、测试套件——这是机器对机器的纠偏，不依赖人的注意力
  • Intent Gate 在任务入口就对意图进行分析和校正，防止 AI 按字面意思执行错误任务

这种"Agent 互相监督"的设计，让错误在传播之前就被拦截，而不是等到人类发现时已经积累了大量技术债。

第二层：强力的团队大工程 Rules 体系

单靠 Agent 互相监督还不够。真正让系统行为收敛、稳定的，是工程级的 Rules 体系——一套被明确写下来、被所有 Agent 强制遵守的约束规则。

在 Vibe Coding 的实践里，这些规则往往是隐含的、模糊的，甚至根本不存在。工程师凭直觉和经验判断什么能做、什么不能做，但这些判断无法传递给 AI。

Agentic Engineering 把这些隐含规则显式化、结构化：

  • AGENTS.md / CLAUDE.md：项目级知识库，记录架构约束、反模式、演进方向
  • 系统提示词中的 Rules：每个 Agent 的行为边界，明确"必须做什么"和"绝对不能做什么"
  • 验收标准（Acceptance Criteria）：每个任务的完成定义，机器可判断、可复现
  • 工程纪律约束：如"不得修改 public/ 目录"、“不得删除 .deploy_git/”——这些约束被写入 Rules，Agent 无法绕过

这套 Rules 体系的价值在于：它把工程师的集体智慧固化成了系统约束，让每一个 Agent 在工作时都站在整个团队的肩膀上，而不是从零开始摸索。

当 Rules 体系足够完善时，模型的偏差会被多重约束拦截，输出会趋向稳定和收敛。这不是因为模型变得更聪明了，而是因为系统设计让错误更难发生、更容易被发现。

[PATTERN] 工程化破局：Vibe Coding 的五重困境（上下文断裂、单角色串行、目标模糊、历史知识缺失、纠偏机制缺失）对应五个工程解法——harness 机制、Agent Team 分工、ATDD 验收标准、SDD 知识沉淀、Rules 体系 + Agent 互相监督。这五者共同构成了从"对话式 AI 编程"到"工程化 AI 交付"的跃迁路径。

三种协作模式：选择合适的"代理团队"

OmO 提供三种不同的协作姿态，分别适合不同类型的任务：

OmO 的 Agent 团队架构

OmO（现已更名为 omo; the best agent harness，仓库：code-yeongyu/oh-my-openagent）的核心设计理念是：用专业化 Agent 团队替代单一通用对话窗口。每个 Agent 都有明确的角色定位、专属的推理预算和职责边界，任务通过内部管道路由到最合适的 Agent，而非由一个"全能选手"串行处理所有事情。

1
2
3
4
5
6
7
8
9
10
用户请求
  ↓
Intent Gate（Phase 0：意图分析与任务分类）
  ↓
Sisyphus（主编排器）
  ├─→ Hephaestus（深度工作）
  ├─→ Prometheus（战略规划）
  ├─→ Oracle（架构咨询）
  ├─→ Librarian（文档研究）
  └─→ Explore（代码搜索）

Intent Gate 是整个系统的入口守卫（Phase 0）：它分析用户的真实意图，而非字面请求，避免 AI 按照字面意思执行错误任务，并决定后续的任务路由策略。

1. Hephaestus —— 深度自治的"正牌工匠"

定位：Deep Agent，擅长 hard problem / 架构 / 深度 debug

架构特性：

  • 给目标，不给 recipe：接收的是"north star"级别的目标描述，而非分步骤的操作指令
  • 自主探索：自行搜索代码库、研究模式、端到端执行，不需要人工干预
  • 深度推理：适合需要跨多个文件、多个系统边界进行推理的复杂任务

适用场景：

  • 复杂架构推理
  • 链路很长的 debug
  • 跨技术域迁移

注意事项：问题空间越大，目标不清就会努力错方向。越自主，越要提前写清可量化的验收标准。

2. Sisyphus —— 默认主力模式

定位：主编排器（Orchestrator），大多数复杂任务的默认入口

架构特性：

  • 32k thinking budget：拥有深度思考预算，用于复杂任务的规划和协调
  • 责任分离：Sisyphus 本身不直接写代码，而是理解需求、分配任务、验证结果
  • 并行委托：可同时启动多个后台任务，让 Explore、Librarian、Oracle 并发工作
  • 强制完成：内置 TODO 追踪机制，必须完成所有任务项才能停止（源自希腊神话中西西弗斯推石头的隐喻——永不放弃）

入口：ulw / ultrawork

工作流程：

1
Intent Gate → 并行证据收集 → category 执行 → 工程验证（build/test/LSP）

关键价值：帮你组织一支团队把任务做完——Explore、Librarian、Oracle 可以同时工作，把代码证据、文档证据和策略建议带回来。

Sisyphus 工作模式

3. Prometheus + Atlas —— 规划与执行的分离

Prometheus：战略规划者，采用面试式规划

  • 先采访、再落计划：在执行前主动提问、识别范围、消除歧义
  • 把隐含需求和关键约束固化到 .sisyphus/plans/*.md，让后续执行不再依赖人脑临场补上下文
  • 适合需要前期规划的复杂功能开发

Atlas：执行型子代理，按波次推进

  • /start-work 之后按 wave 推进
  • 每个 wave 执行、验证、记录 learnings
  • 支持断点续传：任务中断后能从上次状态恢复，而非从头开始

适用场景：跨天、高风险、要可审计的长任务

三种模式对比

OmO 的 Harness 机制：解决上下文断裂问题

OmO 自称"the best agent harness"，其 harness 机制直接针对 Vibe Coding 的第一重困境——上下文断裂：

  • TODO 追踪系统：Sisyphus 必须创建 TODO 列表，每个任务完成后标记，所有 TODO 完成才允许停止
  • 验证 Checkpoint：每个阶段结束时强制运行 lsp_diagnostics、build、测试套件，没有通过就不算完成
  • 后台任务状态管理：每个后台任务有唯一 ID，支持状态查询和结果聚合
  • Ultrawork 模式：在提示中包含 ultrawork 或 ulw 关键词，自动激活并行任务、强制验证、专业 Agent 路由等全套能力

[PATTERN] 模式匹配：根据任务复杂度、时间跨度、风险等级选择合适的协作模式——简单任务用 Sisyphus，深度问题用 Hephaestus，长周期高风险任务用 Prometheus+Atlas。OmO 的本质是把"单窗口对话"升级为"有角色分工、有内部管道、有验证卡点的 Agent 工程团队"。

核心差异：OmO 与 Vibe Coding 的本质区别

对比维度 Human-in-the-loop Vibe Coding OmO 的 long-running 编排
人的角色 持续盯盘 / 补上下文 / 接管 定义目标 / 边界 / 验收
状态管理 当前会话上下文为主 plan + boulder + notes + 后台任务
失败处理 人手动改 prompt 倾向先自纠偏，再决定是否升级
完成定义 看起来差不多 test/build/LSP 通过 + 验收标准满足
输出物 代码片段 可持续推进的工程结果

Manifesto 的关键词：minimum intervention, not constant supervision

关键建议：用 ATDD 的方式使用 OmO

ATDD（Acceptance Test-Driven Development）= 用可执行验收标准驱动计划、实现和完成判断。

四步实践法

1. 先写验收标准（AC）
把行为、边界、指标、回归范围写清。验收标准越具体，代理越不容易努力错方向。

2. 让 Prometheus 把模糊点问清
把隐含需求和关键约束固化进 plan，让后续执行不再依赖人脑临场补上下文。

3. 先准备可执行的判断依据
能写测试就写测试；不能写测试，也至少写出 LSP / build / perf / 业务断言等判断条件。

4. 再选模式推进实现

  • Hard problem → Hephaestus
  • 大多数复杂任务 → Sisyphus + ulw
  • 关键长任务 → @plan + /start-work

ATDD 实践

[PATTERN] 验收标准先行：在放权给 AI 自主执行之前，必须先明确"什么叫 done"——可量化、可验证、可复现的验收标准是自主代理的"护栏"。

常见误区：没有验收标准，代理就会推错石头

这是使用 OmO 最容易犯的错误：

坏输入（模糊目标） 好输入（可验证目标）
“把登录流程优化一下” “保留现有 SSO 行为；新增邮箱登录；登录关键路径 E2E 通过；LSP 0 error；关键 API p95 < 200ms”
“重构这个模块” 明确边界、回归范围、性能约束、不能动的部分
“把体验做好” 定义 test / build / LSP / 性能 / 业务指标

核心原则：把 done 写成机器能判断的条件——tests / build / lsp / perf / 业务断言 / 回归范围，都尽量写成能执行、能判定、能复现的标准。

快速开始：今天就能用的三条命令

1
2
3
4
5
6
7
8
# 大多数任务：用 ulw 修掉 failing tests，并补上回归验证
ulw

# 先规划：把复杂任务写成可讨论的计划
@plan "重构认证链路，但保持现有行为"

# 执行/恢复：按波次推进，支持断点续传
/start-work

不要再教 AI 怎么做每一步；先让它知道什么叫 done。

总结：如果今天只记住三件事

  1. OmO 的差异不只是"会不会写"，而是"会不会持续推进到完成"

  2. 越 autonomous，越需要清晰边界和可量化验收标准

  3. 模式选择：

    • Hephaestus → 解 hard problem
    • Sisyphus → 覆盖大多数复杂任务
    • Prometheus + Atlas → 管高风险长任务

参考资料

模式速查表

模式 适用场景 核心命令 关键成功因素
Hephaestus Hard problem / 架构 / 深度 debug 直接对话 清晰的 north star 和边界
Sisyphus 大多数复杂任务 ulw / ultrawork Intent Gate + 并行证据
Prometheus+Atlas 跨天/高风险/可审计任务 @plan + /start-work 先固化 plan，再按 wave 执行
ATDD 实践 所有模式通用 — 先写验收标准，再放权执行