lingyuzeng/collective-memory-repo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
067e38f7e865c0d45eba136df13db8fe449ea777
collective-memory-repo/agents/openclaw-main/maniple-skill-delivery-plan.md
hotwa 9999e3c668 feat(memory): add exec approval config lessons, daily notes, ACP decisions 
- 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 相关记录
2026-03-16 20:08:47 +08:00

6.0 KiB
Raw Blame History

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 初版可交付：

  • skill 已创建
  • claude-kimi 最小调用链跑通
  • skill 文案收敛为面向最终使用，不只是实验说明
  • 配套脚本具备清晰参数和错误输出
  • 完成至少 3 类任务测试：
    • 快速问答/总结
    • 代码分析/总结
    • 目录内任务执行
  • 用户能直接复用命令调用

正式版成功标准

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

增强版成功标准

  • 明确 maniple 是否需要接入
  • 若接入，完成 HTTP streamable 可行性验证
  • 若不接入，明确轻量替代方案

当前已完成

已完成

  • 创建 skill 目录
  • 编写 SKILL.md
  • 编写 scripts/run-agent.sh
  • 用 claude-kimi 完成最小验证（OK_KIMI_TEST）
  • 建立 maniple 研究计划
  • 阅读 maniple 核心实现：server / registry / poller / tmux / spawn / message / logs / wait / poll
  • 增强 skill 文案为交付导向版本
  • 增加脚本中的 alias/zshrc 可用性检查
  • 完成 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 是否进入增强版方案
Reference in New Issue View Git Blame Copy Permalink