9999e3c668
- shared/long-term/lessons: OpenClaw exec 批准授权系统完整配置经验 - daily/2026-03-16: CLI安装、exec配置、待办记录 - daily/2026-03-15: 之前未提交的日志 - shared/long-term/decisions/acp-agents-integration.md - agents/openclaw-main: claude-switch/mcp 相关记录
204 lines
6.0 KiB
Markdown
204 lines
6.0 KiB
Markdown
# 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` 是否进入增强版方案
|