跳转到内容
AI Agent 教程 AI Agent 教程

CLI 命令与 In-Session 技能的双面设计

学习目标

  • 理解 CLI 与 In-Session 技能双入口架构的设计动机
  • 掌握 omc team 与 /team 不同 runtime 的选择策略
  • 设计自己的双入口系统
  • 识别 CLI 与 skill 行为不一致和用户混淆的陷阱

项目实践

双入口架构

OMC 为同一功能提供了两种不同的用户入口：

入口命令格式运行环境典型场景
Terminal CLIomc ...Shell（独立进程）终端自动化、脚本集成
In-Session Skill/... 或魔关键词Claude Code 会话内交互式编排

对比表：同一功能的不同 runtime

功能Terminal CLIIn-Session Skill差异
Setupomc setup/setup 或 /omc-setup两种都是真实入口点
Ask Provideromc ask codex "..."/ask codex "..."路由到同一个 advisor flow
Team 编队omc team N:codex "..."/team N:executor "..."不同 runtime：CLI 启动 tmux workers，in-session 使用 Claude 原生 Team
CCG—/ccgCCG 仅在 in-session 可用
Autopilot—/autopilot仅在 in-session 可用
Ralph—/ralph仅在 in-session 可用

为什么 Team 有两种不同的 runtime？

维度omc team（CLI）/team（In-Session）
Worker 类型Codex CLI、Gemini CLI、Claude CLIClaude 原生 Team Agent
执行环境tmux 分屏中的独立进程Claude Code 会话内的子 Agent
适用场景需要 Codex/Gemini 的跨 Provider 工作纯 Claude Agent 编队
状态管理.omc/state/team/ 互操作 APIClaude Code 原生 ~/.claude/teams/
可见性tmux panes 可查看实时输出通过 Task 工具的状态

关键设计决策：CLI 和 in-session 的 Team 是不同的 runtime，而非同一代码的不同入口。CLI Team 支持 Codex 和 Gemini 外部 Provider，in-session Team 使用 Claude 原生 Agent Teams。

CLI 命令实现模式

OMC 的 CLI 使用 Commander.js 构建：

// src/cli/commands/team.ts（伪代码）
const teamCommand = new Command('team')
  .argument('[task]', '任务描述')
  .option('--new-window', '在新窗口中启动')
  .option('--auto-merge', '启用自动合并')
  .action(async (task, options) => {
    // 解析 N:agent-type 参数
    // 创建 tmux session
    // 启动 Worker panes
    // 进入监控循环
  });

In-Session Skill 实现模式

OMC 的 Skill 是 skills/<name>/SKILL.md 文件：

---
name: team
description: N coordinated agents on shared task list
---


# Team Skill


## Usage
/oh-my-claudecode:team N:agent-type "task description"


## Architecture
...

Claude Code 在触发时读取 SKILL.md，将其指令注入系统提示。

双面设计的优势

  1. 满足不同用户习惯：偏好终端的用户使用 CLI，偏好交互式的用户使用 Skill
  2. 支持自动化：CLI 可以被脚本调用，Skill 必须在会话内运行
  3. 能力互补：CLI 支持外部 Provider（Codex/Gemini），Skill 支持原生 Agent Teams

问题与规避

问题 1：CLI 和 skill 行为不一致

同一功能在 CLI 和 Skill 中可能有不同的实现逻辑。

规避策略：OMC 对某些功能（如 omc ask 和 /ask）共享同一个底层逻辑。对于 Team 这种本质不同的 runtime，OMC 在文档中明确说明差异。

问题 2：用户混淆两种入口

用户可能不知道什么时候用 omc team，什么时候用 /team。

规避策略：OMC 在 README 中提供了对比表，明确说明每个功能的两种入口及其差异。

问题 3：部分功能只有单入口

某些功能（如 Autopilot、Ralph）只在 in-session 可用，没有 CLI 对应。

规避策略：这些功能依赖 Claude Code 会话内的子 Agent 能力，无法在独立 CLI 进程中实现。OMC 在文档中标注了 — 表示不可用。

设计取舍

为什么不统一到单一入口？

维度单一入口双入口
用户认知低——只需学一个命令中——需要理解两种入口
实现复杂度高——需要统一两种运行环境中——每种入口有独立的实现
能力覆盖低——必须选择一种运行环境高——两种环境互补
自动化支持取决于选择的环境高——CLI 可脚本化

OMC 的选择：双入口——两种运行环境的能力互补（CLI 支持外部 Provider，Skill 支持原生 Agent Teams），比单一入口的能力覆盖更广。

参考来源

版本信息

📅 2026-05-31 🏷️ v4.14.4 🔀 ed7800d

标签

dual-surfacecliskillsruntime-separationuser-experience