主题
第八章 OmO 扩展与权限
← 返回目录 | 上一章：OmO 后台任务系统 | 下一章：Claude Code 概述与定位 →
本章合并原报告 §9（工具/MCP/Skill 扩展对比）和 §17（权限系统与安全沙箱），涵盖 OmO 的能力扩展框架和访问控制机制。
8.1 工具扩展：从 19 到 ~40
OmO 在 Opencode 的 19 个工具基础上进行了两类扩展：
- 覆写增强（4 个）：
task（增加异步/category/session_id 等）、grep（增加输出限制）、glob（增加安全限制）、skill（增加多层发现和斜杠命令） - 全新工具（22 个）：LSP 重构套件（6 个）、AST 搜索替换（2 个）、后台任务管理（2 个）、会话历史（4 个）、交互与多模态（2 个）、Skill/MCP 扩展（2 个）、编辑增强（1 个）、任务管理（4 个）、Agent 直接调用（1 个）
每个工具的详细参数、功能说明和使用场景：详见工具系统完整解析。
以下各节聚焦 OmO 在 MCP、Skill、Category 三个维度的扩展——这些是超越工具本身的"能力扩展框架"。
8.2 MCP 服务器对比
Opencode 原生：0 个内置 MCP 服务器（全部用户配置）
OmO 内置：3 个 HTTP 远程 MCP 服务器
| MCP 服务器 | 提供的工具 | 用途 |
|---|---|---|
| websearch (Exa) | web_search_exa | 语义化网络搜索，返回干净的文本内容 |
| context7 | resolve-library-id, query-docs | 查询编程库的最新文档和代码示例 |
| grep_app | searchGitHub | 在百万公开 GitHub 仓库中搜索代码模式 |
三层 MCP 架构：
层级 1: OmO 内置 MCP（3 个 HTTP 远程服务器）
↓ 叠加
层级 2: Claude Code 兼容 MCP（.mcp.json 文件配置，支持环境变量展开）
↓ 叠加
层级 3: Skill 嵌入 MCP（SKILL.md 的 YAML frontmatter 中定义）8.3 Skill 对比
Opencode 原生：基础 Skill 发现机制，无内置 Skill
OmO 内置 Skill：
| Skill | 类型 | 用途 |
|---|---|---|
| git-master | 内置 | Git 操作专家（原子提交、rebase、历史搜索） |
| playwright | 内置 | 浏览器自动化（Playwright MCP） |
| playwright-cli | 内置 | Playwright CLI 工具 |
| agent-browser | 内置 | Agent 浏览器交互 |
| dev-browser | 内置 | 持久页面状态的浏览器自动化 |
| frontend-ui-ux | 内置 | 前端 UI/UX 设计开发指导 |
| work-with-pr | 项目 | PR 工作流 |
| pre-publish-review | 项目 | 发布前审查 |
| github-triage | 项目 | GitHub Issue 分类 |
8.4 Category 系统（OmO 独有）
Category 是 OmO 独有的任务路由机制，将任务类型映射到最优的模型和 Skill 组合：
| Category | 适用场景 | 模型选择策略 |
|---|---|---|
visual-engineering | 前端、UI/UX、样式、动画 | 视觉优化模型 |
ultrabrain | 高难度逻辑、算法 | 最高推理能力模型 |
deep | 自主研究+端到端实现 | 高推理+大上下文 |
artistry | 创造性问题解决 | 创造力优化模型 |
quick | 简单修改、typo 修复 | 最快最便宜的模型 |
unspecified-low | 低工作量杂项 | 中等模型 |
unspecified-high | 高工作量杂项 | 中高模型 |
writing | 文档、文章撰写 | 写作优化模型 |
使用流程：
Sisyphus 委派任务: task(category="visual-engineering", load_skills=["frontend-ui-ux"], ...)
↓
Category 解析器: 查找 visual-engineering 的模型配置
↓
创建 Sisyphus-Junior Agent 实例，绑定该模型
↓
加载 frontend-ui-ux Skill 注入系统提示
↓
Junior 使用视觉优化模型 + 前端专家指令执行任务8.5 权限系统与安全沙箱
多 Agent 系统带来了一个传统单 Agent 不需要面对的问题：不同角色的 Agent 应该有不同的权限边界。 一个只负责查询的 Explore Agent 不应该有能力修改文件；一个只负责规划的 Prometheus Agent 不应该能执行代码。OmO 通过三层权限系统解决了这个问题。
8.5.1 工具级权限（Agent Tool Restrictions）
agent-tool-restrictions.ts 定义了每个 Agent 的工具访问矩阵：
typescript
const AGENT_RESTRICTIONS = {
explore: { // 探索 Agent
write: false, // ❌ 不能写文件
edit: false, // ❌ 不能编辑文件
task: false, // ❌ 不能委派任务
call_omo_agent: false, // ❌ 不能调用其他 Agent
},
librarian: { /* 同 explore */ },
oracle: { // 咨询 Agent（只读）
write: false, edit: false,
task: false, call_omo_agent: false,
},
metis: { // 分析 Agent
write: false, edit: false, task: false,
},
momus: { // 评审 Agent
write: false, edit: false, task: false,
},
"multimodal-looker": { // 图像分析 Agent
read: true, // ✅ 只允许 Read（白名单模式）
},
"sisyphus-junior": { // 子任务执行 Agent
task: false, // ❌ 不能再委派（防止无限递归）
},
}设计哲学：
- Explore/Librarian/Oracle：只读角色，严格禁止任何写操作和任务委派
- Metis/Momus：分析/评审角色，可以读取但不能修改，也不能委派
- Sisyphus-Junior：执行角色，可以读写但不能再委派任务（防止委派链无限递归）
- Multimodal-Looker：白名单模式，只允许 Read 工具，其他一律拒绝
8.5.2 权限格式（Permission System）
permission-compat.ts 定义了统一的权限格式，支持三种权限值：
typescript
type PermissionValue = "ask" | "allow" | "deny"
// 黑名单模式：默认允许，显式拒绝
createAgentToolRestrictions(["write", "edit"])
// → { permission: { write: "deny", edit: "deny" } }
// 白名单模式：默认拒绝，显式允许
createAgentToolAllowlist(["read"])
// → { permission: { "*": "deny", read: "allow" } }ask 值用于需要用户确认的敏感操作（如 Bash 命令执行）。系统还支持从旧格式（布尔值）自动迁移到新的权限格式。
8.5.3 路径沙箱（Prometheus MD-Only）
prometheus-md-only Hook 是路径级别沙箱的典型实现。Prometheus 是 OmO 的规划 Agent——它只应该产出 Markdown 格式的计划文件，而不应该直接修改代码：
prometheus-md-only Hook (tool.execute.before)
├─ 检测当前 Agent 是否为 Prometheus
├─ 检测工具是否为 Write/Edit
└─ 如果目标文件不在 .sisyphus/ 目录或不是 .md 文件 → 拒绝这确保了即使 Prometheus 的 Prompt 中没有明确禁止写代码，Hook 层面也会硬性阻止。
8.5.4 用户可配置
所有权限都可以通过 .opencode/oh-my-opencode.jsonc 覆盖：
jsonc
{
"agents": {
"explore": {
"permission": {
"write": "allow", // 允许 explore 写文件（覆盖默认）
"bash": "ask" // Bash 需要用户确认
}
}
}
}配置加载时，用户设置会通过 migrateAgentConfig 自动迁移旧格式，并与内置默认值合并。