第四章：智能体（Agents）全景详解

oh-my-openagent（OmO）内置 11 个智能体。它们不是 11 个独立的 prompt 模板，而是被精心设计成一支”工程团队”——每位有清晰的职责、独特的提示词风格、最佳搭配的模型、明确的工具权限边界。本章逐个介绍它们，并把”在什么时候叫它们出来”讲清楚。

4.1 11 个 Agent 全景图

按”组织职能”分四组：

按”我什么时候会用到它”分三种交互方式：

1. 默认对话 → 默认就是 Sisyphus；
2. Tab 切换 Agent → 进入 Hephaestus / Prometheus 等；
3. @xxx 提及 / task() 调用 → 由当前 Agent 内部委派。

OmO 还为核心 Agent 注入了确定性的 tab 循环顺序（avoid 顺序漂移）：Sisyphus(1) → Hephaestus(2) → Prometheus(3) → Atlas(4) → 其余 Agent。

4.2 Sisyphus：主指挥官（The Default Orchestrator）

名字取自希腊神话：每天推石上山，永不停歇。

4.2.1 角色定位

Sisyphus 是 OmO 的 默认编排者。他不是”最聪明”的那个，而是”最善于沟通和调度”的那个：

• 制定计划、维护 todo 列表；
• 调用 task()、call_omo_agent() 并行下发子任务；
• 处理 IntentGate 分类后的请求；
• 配合 extended thinking（32k budget）做深度规划。

形象地说，Sisyphus 是那种 走遍各处、和每个人都熟、会通过沟通和协调把事情搞定 的项目经理——但纯粹深度技术问题（race condition、内存泄漏）他会让 Hephaestus / Oracle 上。

4.2.2 推荐模型

完整 fallback 链（运行时实测）：

anthropic|github-copilot|opencode/claude-opus-4-7 (max)
  → opencode-go/kimi-k2.5
  → kimi-for-coding/k2p5
  → opencode|moonshotai|moonshotai-cn|firmware|ollama-cloud|aihubmix/kimi-k2.5
  → openai|github-copilot|opencode/gpt-5.4 (medium)
  → zai-coding-plan|opencode/glm-5
  → opencode/big-pickle

4.2.3 关键特性

• 极度激进的并行调度（”积极并行”是 Sisyphus 的核心方法论）；
• 触发关键词 ultrawork / ulw 时自动进入”全力以赴模式”；
• 所有任务在没跑完之前不结束，对应 todo-continuation-enforcer Hook；
• 默认 Extended Thinking 32k tokens；
• 受 no-sisyphus-gpt Hook 保护：在不兼容的老 GPT 模型上会被阻止启动。

4.3 Hephaestus：正牌工匠（The Legitimate Craftsman）

名字取自希腊神话铸造之神。带有故意的讽刺：因为这个项目曾被 Anthropic 屏蔽了 Claude API，OmO 团队就为 GPT 系列单独打造了 Hephaestus。

4.3.1 角色定位

Hephaestus 是 GPT-5.4 原生的自主深度工作者，灵感来自 AmpCode 的 deep mode。给他一个目标，不要给他一个食谱——他自己探索代码、自己研究模式、自己端到端实现，不会让你做保姆。

适用：

• 复杂架构推理（设计新插件系统、单体拆微服务）；
• 跨多文件的复杂调试（race condition、内存泄漏、异常追踪）；
• 跨域知识合成（Rust 内核 ↔ TS 前端、MongoDB → PostgreSQL 零停机迁移）；
• 任何”我特别想用 GPT-5.4 推理风格”的场景。

4.3.2 模型 & 限制

• 模型：GPT-5.4 (medium) only，没有回退；
• 必须有 GPT 提供商；
• 受 no-hephaestus-non-gpt Hook 保护：被强行换非 GPT 模型时会被阻止。

4.3.3 与 Sisyphus + ulw 的对比

结论：90% 任务用 ulw；只有当你特别想用 GPT-5.4 风格或要求”AmpCode 深度探索”体验时才切到 Hephaestus（Tab → 选 Hephaestus）。

4.4 Prometheus：战略规划师（The Planner）

取自希腊神话盗火者，”先思而后行”。

4.4.1 角色定位

Prometheus 是 READ-ONLY 的访谈型规划师：只能在 .sisyphus/ 目录下创建/修改 Markdown 文件，不能写任何代码。

工作流程：

1. 你描述需求（”我要重构 auth 系统”）；
2. Prometheus 启动 explore / librarian 调研代码；
3. 与你做多轮访谈，逐项澄清范围、边界、技术路线、测试策略；
4. 通过”可放行检查”（核心目标 / 范围 / 关键歧义 / 技术路线 / 测试策略全部齐备）后；
5. 强制咨询 Metis 做缺口分析；
6. 把发现写入计划，呈递用户；
7. 如果开启高准确度模式，Momus 严格审查 → 可能 REJECT 让 Prometheus 改 → 重提 → ……
8. 计划落盘到 .sisyphus/plans/{name}.md，引导用户用 /start-work。

4.4.2 不同意图的访谈策略

4.4.3 推荐模型

4.4.4 怎么唤出 Prometheus？

• 方式 1：Tab → 选 Prometheus，然后开始描述工作；
• 方式 2：在 Sisyphus 里 @plan "我要重构 auth"。

两者效果一样，前者适合”我现在就是要规划”，后者适合”刚干一半想插一个计划”。

4.5 Metis：缺口分析师（The Gap Analyzer）

4.5.1 角色定位

Metis 在 Prometheus 写计划落盘之前强制介入，作用：

• 找出用户请求里隐藏的意图；
• 找出可能让实现偏的歧义；
• 揪出 AI slop 模式（过度工程、scope creep）；
• 找缺失的验收标准；
• 找未被处理的边界情况。

4.5.2 为什么需要 Metis？

计划作者（Prometheus）有”ADHD 工作记忆”——它在脑子里建立了很多关联，但从没写到纸上。Metis 强迫这些隐含知识被外显化。

模型：默认 Claude Opus 4.7，回退 GPT-5.4 (high) → GLM 5 → Kimi K2.5。

4.6 Momus：严苛审查官（The Ruthless Reviewer）

4.6.1 角色定位

Momus 在用户开启”高准确度模式”后才会出场。它按 4 条标准评审计划：

1. Clarity（清晰度）：每个任务是否说清楚”在哪里能找到实现细节”？
2. Verification（可验证性）：验收标准是否具体可测？
3. Context（上下文充分度）：是否提供了 ≥ 90% 充分的上下文，让执行人不必猜超过 10% 的内容？
4. Big Picture（大局观）：目的、背景、工作流是否清楚？

4.6.2 Momus 只在以下情况说 OKAY

• 100% 文件引用都能验证；
• ≥80% 任务有明确的参考来源；
• ≥90% 任务有具体的验收标准；
• 0 个任务需要对业务逻辑做假设；
• 0 个关键红旗。

REJECTED 时 Prometheus 修补后重提，没有最大重试次数。模型默认 GPT-5.4（xhigh），GPT 派系最严苛的一位。

4.7 Atlas：执行指挥棒（The Conductor）

4.7.1 角色定位

Atlas 像乐队指挥：自己不演奏乐器，只负责让大家配合得完美。

Atlas 能做的：

• 读文件理解上下文；
• 跑命令验证结果；
• 用 lsp_diagnostics 检查错误；
• grep / glob / ast-grep 搜索。

Atlas 必须委派给子 Agent 的：

• 写文件 / 改代码；
• 修 Bug；
• 写测试；
• Git 提交。

4.7.2 智慧累积（Wisdom Accumulation）

每完成一个任务，Atlas 都会：

1. 从子 Agent 的回应中抽取”学到了什么”；
2. 分类成 Conventions / Successes / Failures / Gotchas / Commands；
3. 把这份”经验”传递给后续所有子 Agent。

笔记本（notepad）目录结构：

.sisyphus/notepads/{plan-name}/
├── learnings.md       # 模式、约定、成功做法
├── decisions.md       # 架构选择和理由
├── issues.md          # 遇到的问题、阻塞、坑
├── verification.md    # 测试结果、验证产物
└── problems.md        # 未解决问题、技术债

4.7.3 触发方式

/start-work 命令。Atlas 会自动激活，不需要手动 Tab 切。start-work Hook 会做：

• 如果 .sisyphus/boulder.json 存在 → RESUME 模式，从断点续作；
• 如果不存在 → 找 .sisyphus/plans/ 中最新计划，新建 boulder.json，从第一项开始。

模型：默认 Claude Sonnet 4.6，回退 Kimi K2.5 → GPT-5.4 (medium) → MiniMax M2.7。

4.8 Sisyphus-Junior：执行小弟（The Task Executor）

4.8.1 角色定位

Sisyphus-Junior 是被 Sisyphus 或 Atlas 调用 task() 时召唤出来的”专属执行 Agent”，特点：

• focused：不能再委派任务（task / call_omo_agent 被禁用）；
• disciplined：极度强迫地维护 todo；
• verified：完成前必须通过 lsp_diagnostics；
• constrained：READ-ONLY 计划文件，不能改 .sisyphus/plans/。

4.8.2 模型按 Category 决定

Junior 没有固定模型，而是按调用时 category 字段动态选：

• visual-engineering → Gemini 3.1 Pro；
• ultrabrain → GPT-5.4 (xhigh)；
• deep → GPT-5.4 (medium)；
• quick → GPT-5.4 Mini；
• ……

通用 fallback：claude-sonnet-4-6 → kimi-k2.5 → gpt-5.4 (medium) → minimax-m2.7 → big-pickle。

4.8.3 为什么”普通模型”也够用？

因为 Junior 拿到的是：

1. 来自 Atlas 的详细任务说明（50–200 行）；
2. 累积下来的 wisdom；
3. 明确的 MUST DO / MUST NOT DO 约束；
4. 强制验证要求。

智能在系统里，不在单个 worker 上。

4.8.4 系统提醒：拒绝半途而废

如果 Junior 想”我做完了”但 todo 还有未勾选项，会被 Hook 强行注入：

[SYSTEM REMINDER - TODO CONTINUATION]

You have incomplete todos! Complete ALL before responding:
- [ ] Implement user service ← IN PROGRESS
- [ ] Add validation
- [ ] Write tests

DO NOT respond until all todos are marked completed.

这就是”推石头”机制的代码体现。

4.9 Oracle：架构顾问（The Consultant）

4.9.1 角色定位

Oracle 是 READ-ONLY 高 IQ 顾问：只能读，不能写、不能编辑、不能委派（write / edit / task / call_omo_agent 全部被禁）。

适用：

• 架构决策（”这个模块该不该拆？”）；
• 代码评审；
• 复杂调试咨询；
• 不熟悉模式的解读；
• 安全/多系统权衡。

模型：GPT-5.4 (high) 默认；回退 Gemini 3.1 Pro (high) → Claude Opus 4.7 (max) → GLM 5。灵感来自 AmpCode 的 oracle agent。

4.9.2 调用方式

Ask @oracle to review this design and propose an architecture

或在 Sisyphus 计划里通过 call_omo_agent(subagent_type="oracle", prompt=...)。

4.10 Librarian：图书管理员（Docs / OSS）

4.10.1 角色定位

Librarian 做”基于证据的多仓库分析、文档查询、开源实现示例”。READ-ONLY：禁 write / edit / task / call_omo_agent。

适用：

• 不确定的库 API 用法；
• 跨仓库比对实现；
• 找最佳实践（”主流 React hooks 怎么处理 race”）；
• 找标准（OAuth 2.1 PKCE / RFC 9728 等）。

模型：默认 GPT-5.4-mini-fast / MiniMax M2.7-highspeed → MiniMax M2.7 → Claude Haiku 4.5 → GPT-5.4-nano。

调用：

Ask @librarian how this is implemented - why does the behavior keep changing?

4.11 Explore：代码勘探者（Codebase Grep）

4.11.1 角色定位

Explore 做”快速代码库勘探 + 上下文 grep”，是 OmO 的检索主力。READ-ONLY：禁 write / edit / task / call_omo_agent。

模型：默认 Grok Code Fast 1（快得离谱）→ MiniMax M2.7-highspeed → MiniMax M2.7 → Claude Haiku 4.5 → GPT-5.4-nano。

调用：

Ask @explore for the policy on this feature

或在 Sisyphus 内部 call_omo_agent(subagent_type="explore", run_in_background=true)。

4.12 Multimodal-Looker：视觉小组

4.12.1 角色定位

视觉/截图/PDF/图表内容分析专家。白名单：read only。

模型：默认 GPT-5.4 (medium) → Kimi K2.5 → GLM-4.6V → GPT-5-Nano。

调用方式独特：通过 look_at(path=...) 工具自动启动，不需要手动 @。

4.13 工具权限速查表

OmO 通过 Hook 严格控制每个 Agent 能调用的工具，下面是关键限制：

这套限制把”读”和”写”在物理层面分开，让评审/检索/规划三类只读 Agent 的产出绝对不会污染代码库。

4.14 调用对照速查

下面这张表是日常工作中最常用的”我现在该叫谁”：

4.15 一句话记忆每个 Agent

• Sisyphus：项目经理，把石头推上山。
• Hephaestus：独行匠人，硬骨头交给我。
• Prometheus：访谈式规划师，先想清楚再动手。
• Metis：缺口分析师，把你脑子里的隐含信息抠出来。
• Momus：严苛审稿人，不达标就驳回。
• Atlas：指挥棒，不演奏只协调。
• Sisyphus-Junior：执行小弟，按 Category 上场，绝不偷懒。
• Oracle：架构军师，只读高智商。
• Librarian：图书管理员，文档/OSS 检索。
• Explore：代码勘探者，grep 风暴。
• Multimodal-Looker：视觉之眼，看图像/PDF/图表。

下一章我们要把它们串起来，看 OmO 的三种主线工作流：Ultrawork、Prometheus、Atlas——这才是日常生产里最常用的部分。