oh-my-openagent

生活、工作、学习倘使都能自动，则教育之收效定能事半功倍。所以我们特别注意自动力之培养，使它关注于全部的生活工作学习之中。自动是自觉的行动，而不是自发的行动。自觉的行动，需要适当的培养而后可以实现。——陶行知

Oh My OpenAgent：让多模型协作走进开发现场的 Agent Harness

项目地址：https://github.com/code-yeongyu/oh-my-openagent

当开发工作开始由 AI Agent 深度参与，新的问题很快就会出现：模型越来越多，工具越来越杂，配置越来越长，真正能稳定推进任务的工作流却并不总是清晰。

Claude Code、Codex 与开源模型各自拥有能力边界，开发者需要在模型选择、工具集成、规则注入、上下文管理、子任务分发与执行持续性之间来回协调。Oh My OpenAgent 想处理的，正是这片容易变得凌乱的区域。

它将自己定位为一个面向 AI 编程工作流的 Agent Harness。它不要求开发者只押注某一个模型，而是把重点放在编排上：让不同模型、不同 Agent、不同工具和不同任务类型进入同一条可持续推进的开发链路。

README 中给出了非常直接的使用方式：

ultrawork

或者更短一些：

ulw

输入一个关键词，任务便进入更主动的执行状态。这里的核心并不是某个孤立命令，而是一整套围绕多模型协作、任务分解、工具调用、规划执行与持续推进组织起来的能力。

从单个 Agent 到一支可调度的开发队伍

Oh My OpenAgent 的主 Agent 并不只承担回答问题的角色。它被设计为任务编排者，负责规划、委派、调用专门 Agent，并推动工作持续向前。

README 中描述的协作结构包含多个角色：

• 主 Agent 负责整体编排与任务推进
• Ultrawork Planner 负责战略规划与执行前访谈
• Architect Consult 面向架构与调试工作
• Librarian 负责文档与代码搜索
• Explore 用于快速探索代码库
• Multimodal Looker 用于多模态相关任务
• 分类工作者处理不同方向的专门工作

这种结构让复杂任务不再只有一种处理方式。

面对一个大型需求，系统可以先识别范围与歧义，再生成计划，然后将不同部分交给不同类别的 Agent 处理。主 Agent 继续负责统筹与收敛，而不是让所有工作都堆在单一对话里。

任务被拆开，但目标并没有被拆散。

ultrawork：用一个关键词启动持续执行

Oh My OpenAgent 最醒目的入口，是 ultrawork。

README 将它描述为一种能够激活 Agent 协作的工作模式。输入 ultrawork 或 ulw 后，系统会围绕任务展开执行，不让 Agent 在半途轻易停下。

它既存在于 Ultimate Edition，也存在于 Light Edition 中。

在 Ultimate Edition 中，ultrawork 与主 Agent、规划器、后台 Agent、工具链和任务约束共同工作。在 Light Edition 中，它则以适配 Codex CLI 的轻量组件形式继续存在。

这让一个简短的关键词，背后连接起的是规划、委派、搜索、修改、验证与持续执行。

README 里将这种体验概括得很直接：安装后输入 ultrawork，其余工作由系统接手。

三种形态，面向不同的使用路径

Oh My OpenAgent 提供三个版本方向。

Ultimate Edition：面向 OpenCode 的完整形态

Ultimate Edition 是面向 OpenCode 的完整版本。

它包含 11 个 Agent、54 个以上生命周期钩子、4 个内置 MCP，以及全部斜杠命令、Team Mode、/goal 与 ultrawork 等能力。

内置 MCP 覆盖 Web 搜索、文档检索、GitHub 代码搜索与 LSP。主 Agent 可以借助这些工具完成信息搜集、代码理解、导航与诊断。

安装入口如下：

bunx oh-my-openagent install

安装过程会通过 TUI 引导完成插件注册、Agent 与模型配置，以及提供方认证相关步骤。

Light Edition：面向 Codex CLI 的轻量形态

Light Edition 面向 Codex CLI，保留了能够适配其插件系统的组件。

它包含规则注入、评论检查、Git Bash、LSP、ultrawork、ulw-loop 与持续执行相关能力。

安装方式如下：

npx lazycodex-ai install

也可以通过非交互方式启用推荐配置：

npx lazycodex-ai install --no-tui --codex-autonomous

Light Edition 不要求 Bun，可以直接在 Node 与 npm 环境中使用安装命令。

OmO Native：独立运行的 Beta 形态

OmO Native 是独立运行的 Beta 版本。

它以 omo 命令的形式提供，并内置 OMO 扩展。它不加载到 OpenCode 或 Codex 中，而是作为独立命令使用。

安装方式如下：

bun add -g omo-ai@beta

安装完成后，可以使用：

omo

README 将其描述为包含固定 senpi 引擎与 OMO 扩展的独立形态。

Team Mode：让并行协作变得可见

单个 Agent 可以处理任务，而 Team Mode 试图把协作进一步推向多 Agent 并行。

在 Team Mode 中，主 Agent 担任负责人，最多可以调度 8 名并行成员。不同成员围绕不同类别展开工作，主 Agent 则负责协调它们的结果。

Team Mode 还支持通过 tmux 进行实时可视化。执行过程不再完全隐藏在单一输出流中，而可以呈现为多成员同时推进的工作现场。

配置示例如下：

{
  "team_mode": {
    "enabled": true,
    "max_parallel_members": 4,
    "tmux_visualization": true
  }
}

启用后，系统会提供 team_* 工具族。

README 中提到，hyperplan 可以在真正开始写代码前，从多个角度审视计划。与此同时，ultraqa 可以由多名 Agent 并行处理验证任务。

Team Mode 默认关闭。它更像是一套在需要时打开的并行执行能力，而不是每一次任务都必须进入的模式。

用任务类别代替手动挑选模型

多模型环境里，一个常见难题是：到底该为当前任务选哪个模型。

Oh My OpenAgent 的处理方式不是让主 Agent 每次直接挑选具体模型，而是先选择工作类别。类别再自动映射到合适的模型。

README 中列出了若干类别：

类别	面向的工作
visual-engineering	视觉设计、UI、UX、前端
deep	横跨视觉与技术领域的深度工作
quick	单文件修改、拼写修复等快速任务
ultrabrain	高难逻辑与架构决策

这种机制把“模型选择”转化为“任务分类”。

Agent 先识别当前工作属于视觉工程、深度处理、快速修改还是高难推理，再由 Harness 根据映射关系选择模型。开发者不需要在每次委派子任务时手工调整模型策略。

不同模型的能力被看作可调度资源，而不是需要反复手动切换的独立工具。

规划先行：/ulw-plan 与 /ulw-execute

复杂任务最容易出问题的时刻，常常不是编码阶段，而是尚未明确范围就急着开始修改的时候。

Oh My OpenAgent 提供 Ultrawork Planner，用于在执行前展开规划。

通过 /ulw-plan，系统会以访谈模式了解任务，识别范围与歧义，并在真正修改代码前写出计划。计划会写入 .omo/plans/。

随后可以通过 /ulw-execute 执行已经形成的计划。

这条路径将复杂任务划分为更清晰的两个阶段：

1. 先理解需求、确认边界、形成规划
2. 再依据计划进入执行

规划器不只是把需求重新叙述一遍，而是试图将任务推进到可以执行的状态。

对于需要多步骤修改、涉及多目录、需要协调设计与实现的工作，这种先规划后执行的节奏提供了更明确的工作秩序。

持久目标与任务推进机制

Oh My OpenAgent 中的 /goal 用于设置一个持续存在的线程目标。

当目标启用后，系统可以在空闲时继续推进任务。README 说明，空闲续跑只会在 goal.enabled 启用时发生，默认情况下并不会自动开启。

与目标机制配套的还有 Todo Enforcer。

它负责避免 Agent 在任务还没有完成时进入空闲状态。任务清单不只是摆在上下文里的文字，而会成为推动执行继续向前的约束。

此外，Think Mode、评论检查器与规则注入机制也共同服务于任务质量与执行稳定性。

它们并不只是增加更多开关，而是在 Agent 执行过程中形成一层层约束：知道目标、知道规则、知道待办，并在需要时继续推进。

LSP、AST-Grep、Tmux 与 MCP 的协同

AI Agent 的能力不只取决于模型，也取决于它如何接触代码库。

Oh My OpenAgent 集成了 LSP、AST-Grep、Tmux 与 MCP 等工具能力。

LSP：为 Agent 提供接近 IDE 的精度

LSP 集成提供诊断、导航、符号检索、工作区重命名等能力。

Agent 可以使用：

• lsp_rename
• lsp_goto_definition
• lsp_find_references
• lsp_diagnostics

这些工具让 Agent 不必只依赖文本匹配去理解项目结构。它可以更接近 IDE 的方式定位定义、追踪引用、检查诊断信息并进行工作区级修改。

AST-Grep：面向代码结构的搜索与改写

AST-Grep 支持跨 25 种语言的模式感知代码搜索与改写。

与单纯的文本搜索不同，AST-Grep 面向的是代码结构。对于需要寻找特定语法模式、识别相似实现或进行结构化修改的场景，它为 Agent 提供了另一种理解代码的视角。

Tmux：让交互式终端工具进入工作流

Tmux 集成使 Agent 能够处理完整的交互式终端环境。

REPL、调试器与 TUI 都可以被纳入这一能力范围。对于不适合以一次性命令完成的工具，这种终端协作方式扩展了 Agent 的操作空间。

MCP：按需接入工具与上下文

Ultimate Edition 包含内置 MCP，用于 Web 搜索、文档检索、GitHub 代码搜索与 LSP。

README 还强调了 Skill-Embedded MCPs 的思路：MCP 服务可以跟随技能按需启动，在任务需要时出现，任务完成后结束。

这样做的目的，是避免 MCP 服务长期占据上下文预算。工具不必一直堆在会话里，而是在合适的任务边界内工作。

Hashline：为编辑建立可验证的定位方式

Agent 修改代码时，最棘手的问题之一是文件内容变化。

如果 Agent 读取文件后，文件已经被其他操作修改，后续编辑就可能建立在过时的行号或旧内容上。Oh My OpenAgent 的 Hashline 试图为每一行内容提供稳定、可验证的标识。

启用 hashline_edit 后，Agent 读取到的内容会带有哈希标签：

11#VK| function hello() {
22#XJ|   return "world";
33#MB| }

编辑时，Agent 通过这些标签引用对应的内容行。

如果文件在读取后发生变化，哈希不再匹配，编辑会在造成错误前被拒绝。这样，Agent 不需要依赖重新复现一整段文本或猜测旧行号，而是通过内容哈希来确认它正在修改的对象仍然有效。

可以在配置文件中启用这一能力：

{
  "hashline_edit": true
}

Hashline 的设计围绕一个很具体的问题展开：让编辑动作能够建立在可验证的上下文上。

/init-deep：为代码库生成分层上下文

大型项目中，上下文很少只存在于根目录。

不同目录有不同职责，不同模块也有不同约束。Oh My OpenAgent 的 /init-deep 用于生成分层的 AGENTS.md 文件，让项目知识随着目录结构自然展开。

生成后的结构可以类似这样：

project/
├── AGENTS.md
├── src/
│   ├── AGENTS.md
│   └── components/
│       └── AGENTS.md

根目录的 AGENTS.md 承载项目范围的上下文，src 下的文件承载源代码相关信息，组件目录下的文件则可以进一步表达局部规则。

Agent 会自动读取与当前任务相关的上下文。

这使项目规范不必全部挤在一个巨大文件中，也不必由开发者每次手动复制到提示词里。规则可以贴近代码存在的位置，并随着任务进入不同目录而自然生效。

规则注入与 Claude Code 兼容能力

Oh My OpenAgent 可以自动将 AGENTS.md、README 与条件规则注入 Agent 上下文。

规则文件可以放在：

AGENTS.md

或者：

.omo/rules/

这种机制让项目规范、局部约束与开发约定可以持续参与 Agent 的每一次执行，而不必依赖人工反复提醒。

README 还描述了对 Claude Code 生态的兼容能力。

Claude Code 的 hooks、commands、skills、MCPs 与 plugins 可以在 Oh My OpenAgent 中继续使用。对于已经积累了一套 Claude Code 配置的开发者而言，这意味着已有的工作习惯和扩展资产可以延续到新的 Harness 中。

兼容并不只是为了减少迁移阻力，也让不同工具体系中的配置能够继续发挥作用。

Skills：不只是提示词文件

在 Oh My OpenAgent 中，Skills 不只是简单的提示词集合。

一个 Skill 可以携带面向特定领域调校过的系统指令、按需启动的嵌入式 MCP 服务，以及限定 Agent 行为边界的权限范围。

内置 Skill 包含：

• playwright
• git-master
• frontend

其中，playwright 面向浏览器自动化，git-master 涉及原子提交与变基处理，frontend 面向设计优先的前端工作。

自定义 Skill 可以放在项目目录：

.opencode/skills/*/SKILL.md

也可以放在用户级配置目录：

~/.config/opencode/skills/*/SKILL.md

这种组织方式使 Skills 成为可以随项目沉淀的工作单元。它们不仅告诉 Agent 应该怎样思考，还可以带上完成工作所需的工具能力。

配置文件与优先级

Oh My OpenAgent 使用 JSONC 配置。

用户级配置文件位于：

~/.omo/omo.jsonc

项目级配置文件位于：

.omo/omo.jsonc

系统会从当前项目向上查找配置文件，直到用户目录。距离当前项目更近的配置拥有更高优先级。

这种层级让全局偏好与项目特定要求可以同时存在。

全局配置可以保存通用的 Agent、模型、工具和行为偏好；项目配置则可以覆盖某个仓库中的具体需求。对于不同技术栈、不同协作规则、不同任务敏感度的项目，这样的配置结构提供了更细的控制空间。

匿名遥测与退出方式

README 中说明，匿名遥测默认启用，用于跟踪活跃安装情况。

对于每个产品、每台机器，每天最多发送一次事件。机器标识以 SHA256 哈希方式处理。

主插件可以通过配置关闭遥测：

{
  "telemetry": false
}

也可以通过环境变量关闭：

export OMO_DISABLE_POSTHOG=1

或者：

export OMO_SEND_ANONYMOUS_TELEMETRY=0

Light Edition 则拥有对应的独立关闭方式。

卸载路径同样清晰

如果需要移除 OpenCode 中的插件，可以从配置文件的插件数组中删除 oh-my-openagent 或兼容名称 oh-my-opencode。

README 中提供了使用 jq 的处理方式：

jq '.plugin = [.plugin[] | select(. != "oh-my-openagent" and . != "oh-my-opencode")]' \
    ~/.config/opencode/opencode.json > /tmp/oc.json && \
    mv /tmp/oc.json ~/.config/opencode/opencode.json

运行时配置文件也可以按需删除：

rm -f ~/.omo/omo.jsonc ~/.omo/omo.json
rm -f .omo/omo.jsonc .omo/omo.json

对于 Codex CLI Light Edition，可以执行：

npx lazycodex-ai uninstall

也可以使用兼容别名：

npx lazycodex-ai cleanup

或者：

omo-agent-toolkit uninstall --platform=codex

这些命令会处理由工具管理的 Codex 缓存、市场状态、插件配置与钩子状态。

一个围绕编排展开的开发环境

Oh My OpenAgent 的重点并不只是把更多模型放进终端。

它尝试建立的是一套围绕编排展开的工作环境：主 Agent 负责推进，规划器负责澄清任务，专业 Agent 负责处理分工，LSP 与 AST-Grep 帮助理解代码，MCP 提供搜索与文档能力，Hashline 守护编辑的有效性，规则与 AGENTS.md 让项目上下文持续存在，Team Mode 则将并行协作带入同一个执行现场。

在这里，模型并不是彼此割裂的选择题。

它们可以被视为不同类别任务的执行资源，被放入统一的 Harness 中，围绕目标、规则、计划、工具与验证共同工作。