# Claude-Switch Multi-Agent Skill 交付计划

时间：2026-03-10 23:08 Asia/Shanghai

## 最终目标

交付一个 **可在 OpenClaw / mac-5 上稳定使用的 skill**，使主会话能够把复杂任务委托给本机 `claude-switch` 的不同 alias（优先 `claude-kimi`），并在必要时借鉴或接入 `maniple` 的 MCP HTTP streamable 能力。

> 最终交付不是单纯研究报告，而是：**一个能被调用、能测试、能逐步扩展的 skill**。

---

## 最终交付物定义

### 交付物 A：主 skill（必须）
建议名称：`claude-switch-orchestrator`

必须具备：
1. 明确触发条件
2. 支持 alias 路由
3. 定义默认 provider 策略（优先 `claude-kimi`）
4. 定义调用规范：`zsh -lc` + `source ~/.zshrc`
5. 定义默认权限模式：`--permission-mode bypassPermissions`
6. 定义输出格式：alias / cwd / exit code / summary / fallback
7. 定义失败处理策略

### 交付物 B：配套脚本（必须）
当前已有：
- `scripts/run-agent.sh`

后续至少补齐：
1. `scripts/run-agent.sh` 稳定化
2. 可选：`scripts/run-agent-router.sh`
3. 可选：`scripts/check-agent-env.sh`
4. 可选：`scripts/test-kimi.sh`

### 交付物 C：验证文档（必须）
至少包含：
1. `maniple-mcp-http-validation-plan.md`
2. 本交付计划
3. 最终测试结果摘要

### 交付物 D：MCP/Maniple bridge（可选增强项）
仅在验证通过后纳入：
1. 基于 `maniple` 的适配说明
2. 或者自研轻量 MCP bridge 原型

---

## 成功标准

### MVP 成功标准
满足以下条件即可认为 skill 初版可交付：
- [x] skill 已创建
- [x] `claude-kimi` 最小调用链跑通
- [x] skill 文案收敛为面向最终使用，不只是实验说明
- [x] 配套脚本具备清晰参数和错误输出
- [x] 完成至少 3 类任务测试：
  - [x] 快速问答/总结
  - [x] 代码分析/总结
  - [x] 目录内任务执行
- [x] 用户能直接复用命令调用

### 正式版成功标准
- [ ] 支持 `claude-kimi` 稳定运行
- [ ] 至少验证一个额外 alias 的兼容性
- [ ] 完成失败场景测试（auth / invalid url / timeout）
- [ ] 输出 contract 稳定
- [ ] 在 OpenClaw 任务委托语境中可复用

### 增强版成功标准
- [ ] 明确 `maniple` 是否需要接入
- [ ] 若接入，完成 HTTP streamable 可行性验证
- [ ] 若不接入，明确轻量替代方案

---

## 当前已完成

### 已完成
- [x] 创建 skill 目录
- [x] 编写 `SKILL.md`
- [x] 编写 `scripts/run-agent.sh`
- [x] 用 `claude-kimi` 完成最小验证（OK_KIMI_TEST）
- [x] 建立 `maniple` 研究计划
- [x] 阅读 `maniple` 核心实现：server / registry / poller / tmux / spawn / message / logs / wait / poll
- [x] 增强 skill 文案为交付导向版本
- [x] 增加脚本中的 alias/zshrc 可用性检查
- [x] 完成 3 组 `claude-kimi` 真实任务测试（目录总结 / maniple 仓库总结 / claude-switch 项目总结）

### 未完成
- [ ] skill 文案从“实验型”升级为“交付型”
- [ ] 增加更完整的脚本测试矩阵
- [ ] 明确 alias 路由策略
- [ ] 补齐 `maniple` 剩余关键接口映射
- [ ] 决定是否需要 `maniple` 作为增强层

---

## 核心决策

### 决策 1：最终必须以 skill 为主交付
无论后面是否使用 `maniple`，最终都要回收到 skill 里。不能只留一个外部仓库研究成果。

### 决策 2：优先保证 `claude-kimi` 跑通
先把单 provider 做稳，再扩展其他 alias。不要一开始追求全 provider 同时可用。

### 决策 3：`maniple` 是增强参考，不是当前必须依赖
只有在它明显提高：
- 持久 worker 管理
- HTTP streamable 调用
- 日志/事件/恢复
时，才纳入正式方案。

---

## 执行阶段

## Phase 1：Skill 稳定化（当前最优先）
目标：让 `claude-switch-orchestrator` 从“能跑”变成“可交付”。

任务：
- [ ] 收紧 SKILL.md，增加明确使用模式
- [ ] 增加脚本帮助信息与错误分类
- [ ] 增加 `claude-kimi` 实际任务测试
- [ ] 记录标准命令样例
- [ ] 明确 fallback 行为

产出：
- 可直接复用的 skill + script

## Phase 2：Alias 路由策略
目标：让 skill 不只是调用一个 alias，而是有可扩展的 provider 策略。

任务：
- [ ] 定义 alias → 场景映射
- [ ] 定义默认 alias
- [ ] 定义失败 fallback 到 `claude-kimi`
- [ ] 为未来 `claude-glm` / `claude-minimax` 预留接口

产出：
- 稳定 routing 规则

## Phase 3：Maniple 接口映射
目标：搞清楚 `maniple` 哪些能力值得并入 skill 的增强版。

任务：
- [ ] 完整梳理 tools / resources 映射
- [ ] 识别可复用的 worker 生命周期能力
- [ ] 明确 marker / JSONL / idle 检测兼容点
- [ ] 验证 tmux 为主的部署路径

产出：
- 接口地图
- 是否接入的结论

## Phase 4：MCP/HTTP 增强验证（条件阶段）
目标：只有在前面 stable 之后，才验证 streamable-http 是否值得纳入最终 skill 方案。

任务：
- [ ] 本地启动 `maniple` HTTP 模式
- [ ] 验证基础连接
- [ ] 验证 worker 生命周期工具
- [ ] 评估 `claude-switch` alias 适配成本

产出：
- go / no-go 结论

## Phase 5：最终收口
目标：形成可交付版本。

任务：
- [ ] 更新 skill 内容
- [ ] 保证示例命令正确
- [ ] 完成测试摘要
- [ ] 给出使用建议和边界

产出：
- 最终 skill
- 使用说明（嵌入 skill / references，而不是散文件）

---

## 当前建议的最终路线

### 当前最稳路线
1. 先把 `claude-switch-orchestrator` 做稳
2. 先以 `claude-kimi` 为主
3. 再决定是否把 `maniple` 作为增强层纳入

### 不建议的路线
- 现在就把全部精力放在把 `maniple` 装成正式常驻服务
- 现在就追求所有 provider 一起打通
- 让最终交付变成“只有一堆研究笔记，没有可用 skill”

---

## 下一步立即执行项

1. 继续完善当前 skill，使其更像正式交付物
2. 增加实际任务测试（不只是 OK 测试）
3. 在此基础上继续推进 `maniple` 接口验证
4. 最终判断 `maniple` 是否进入增强版方案