模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第10章 — Oh-My-OpenCode的创新
Token用量: 约 3,900 input + 1,000 output
10.3 Ultrawork模式
在 OMO 的诸多功能里，Ultrawork 模式可能是最鲜明、也最“有态度”的一个。它由关键词触发，常见触发词就是 ultrawork 或 ulw，实现位于 hooks/keyword-detector/ultrawork/。一旦触发，系统不再把自己当成普通聊天助手，而是切换到一种更激进、更自主、更强调完工率的工作姿态。
理解 Ultrawork，不能把它看成只是“多插了一段 prompt”。它背后是一套明确的运行哲学：Human intervention = failure signal。也就是“人类频繁介入，本身就是系统失败的信号”。如果用户必须不断提醒 agent：“你先去看代码”“别急着改”“别半成品就停”“你还没验证”，那就说明这个系统离真正自主还很远。Ultrawork 试图把这种不满变成可以执行的工作协议。
它的注入消息极其强硬。系统会要求 agent 在写任何代码之前，先充分理解需求、勘探代码库、解决歧义、形成清晰计划；会强制它优先调用 Explore、Librarian、Oracle、Plan agent 等专业角色；会明确把“简化版本”“以后你可以再扩展”“我做了一些假设”之类的输出视为不可接受。换句话说，Ultrawork 的重点不是“更快”，而是不允许以礼貌措辞掩盖未完成工作。
所以关键词触发的意义很大。它等于给用户一个显式开关：当用户输入 ultrawork 时，双方默认进入一种更高自主度的契约。这个契约大致包含五个阶段。
第一，先探索再动手。不要看到第一个疑似相关文件就直接改，而要先摸清架构、约定、边界条件和相邻实现。第二，需要外部知识时先研究最佳实践。第三，端到端实现，而不是只给骨架。第四，验证，包括构建、测试、行为证据。第五，若失败则持续迭代，而不是输出一段看似体面的总结。
这五个环节——探索、研究、实现、验证、继续——构成了 Ultrawork 的真实工作回路。
它之所以重要，是因为它击中了许多 coding agent 的一个隐性弱点：太“会说话”，但不够“会干活”。很多 agent 在对话层面表现得很友好，会解释、会总结、会道歉，但一到执行层面就容易停在 70% 到 80% 的位置。Ultrawork 模式就是在逆着这个倾向设计。用更标准的系统术语说，它在强化一种**活性（liveness）**期望。所谓活性，指的是系统应该持续朝完成状态推进，而不是长时间停在未完成但口头上像完成的状态。
OMO 的做法不是单靠一句“请继续直到完成”。它把 Ultrawork 与 planner、delegate-task、continuation hooks 结合起来。也就是说，Ultrawork 并不是单点功能，而是整个编排系统中的高自主姿态入口。关键词只是触发器，真正让它站得住的，是下游的 Plan agent、Atlas、Ralph Loop、Todo Continuation 等机制。
另外值得注意的是，Ultrawork 不是“一刀切”地对所有 agent 注入同样内容。不同模型、不同 agent 身份可能会走不同版本的 ultrawork message；planner 家族甚至可能被特殊处理。这说明 OMO 知道一件事：自主性不是均匀撒到整个系统里的，它应当按角色做适配。规划者需要的是更严谨的思考约束，执行者需要的是更强的落地压力，搜索者则需要的是并行调研优先。
它还改变了上下文使用方式。传统做法是让主 agent 把所有探索、检索、实现都塞进主对话里，结果就是主上下文越来越脏。Ultrawork 则鼓励通过 Explore 和 Librarian 等后台子 agent 并行收集信息，再让主线程基于结构化结果继续工作。这等于把高自主度变成“编排能力”，而不是“主线程无限啰嗦”。
从用户体验上说，Ultrawork 代表一种相当鲜明的立场：减少不必要的人类确认，降低打断频率，把更多执行负担留给系统。保守系统往往频繁要求确认，因为那样更安全；OMO 则认为，在很多工程任务里，这种高频确认并不是真正好的体验，因为它把工作又推回给了用户。
当然，这种模式也有成本。更高自主度通常意味着更高 token 消耗、更长运行时间，以及在需求理解错误时更大的偏航风险。OMO 的回应不是否认这些代价，而是通过规划、批评、验证和 continuation 机制去托底。
因此，Ultrawork 的价值不在于它有一个酷炫名字，而在于它把一句口号变成了可运行的模式：编码 agent 不应该像聊天机器人那样在“看起来有帮助”时停下，而应该像真正的执行者那样，以完成任务为目标持续推进。这一点，正是 OMO 相比普通 agent 最鲜明的态度差异之一。