agent-orchestrator-mcp

Prompt

# 提示词：发给 ChatGPT（GPT-5.6-sol / o3 等）的设计评审指令 > 下面的内容直接复制粘贴到 ChatGPT 对话窗口即可。它包含了完整上下文，不需要额外补充。 --- ## 复制从这里开始 ↓ ``` 你是一位资深 AI Agent 基础设施架构师，精通 MCP（Model Context Protocol）规范、多 agent 编排、以及 LLM Coding Agent 生态（OpenAI Codex CLI、Claude Code、WorkBuddy/CodeBuddy、Cursor）。请对以下「三合一统一 MCP Server」方案做架构评审，给出你的设计建议。 # 背景 我目前有三个独立的能力模块，分别解决不同问题： ## 模块 A：repo-harness（规划→执行→状态恢复） - 来源：Ancienttwo/repo-harness（GitHub 开源，Bun 实现） - 已安装：v0.11.3，全局 Bun，已跑 `init --target codex`（写了 ~/.codex/hooks.json） - 核心机制：Chat 规划 → 写 PRD/Sprint/Goal 文件到仓库 `.ai/harness/` → 执行端读 handoff 文件续跑 → 状态落盘不依赖聊天记忆 - 官方定位："ChatGPT Pro 在本地规划，Claude 或 Codex 执行" - 带一个只读 MCP 边车：`repo-harness mcp serve --transport http --profile planner` - 关键哲学："聊天会遗忘，仓库会记住"——状态恢复而非记忆恢复 ## 模块 B：recall（历史会话接手） - 来源：我自己写的 skill（SKILL.md），非开源 - 能力：跨三个平台检索历史对话： 1. Claude Code：~/.claude/projects/-/*.jsonl（JSONL 会话文件） 2. WorkBuddy：~/.workbuddy/workbuddy.db（SQLite 任务索引）+ projects/**/*.jsonl（会话流水，含已归档） 3. Codex 桌面版：~/.codex/sessions/ 和 ~/.codex/archived_sessions/（rollout JSONL） - 独有能力：过滤 Codex 日志里的系统注入噪声（<recommended_plugins>、环境上下文等标签），只提取真实用户指令 - 本质：记忆恢复（向后看）——和 repo-harness 的状态恢复（向前走）互补 ## 模块 C：parallel（多 agent 并行安全协作） - 来源：我自己写的 skill（SKILL.md），纯 playbook/知识文档 - 核心：git worktree 隔离 + 依赖追踪 + 冲突检测 + 并发临界点控制 - 适用场景：多个 AI agent 同时改同一套代码/系统时的安全纪律 - 关键规则： - 主线(main)+支线(branch)拓扑，支线在主线收尾前只读预研 - worktree 解决编辑阶段零冲突，合并阶段需串行化 - 共享资源（端口/DB/服务）需要额外隔离 - 人审瓶颈：实测约 3-5 个并发 agent 是舒适上限 # 目标 把这三个模块整合成 **一个统一的 MCP Server**（类似 Playwright MCP 那样暴露 ~22 个工具集），使得： 1. **任何 MCP 客户端都能用**：WorkBuddy、Codex CLI、Claude Code、Cursor、ChatGPT——只要支持 MCP 协议就能接 2. **Skill 只能 WB 用，MCP 全通用**——这是选 MCP 而非 Skill 作为交付形式的核心原因 3. **保留原有模块不动**：repo-harness 的 Codex hooks / CodeGraph 底层设施保留；recall/parallel skill 保留作为 fallback 和知识文档 # 我已有的设计方案（请你评审） ## 技术选型 - 语言：TypeScript (Node.js)，用 `@modelcontextprotocol/sdk` - 传输：stdio（默认，最通用）+ 可选 SSE（HTTP，远程场景） - 配置：启动参数 `--repo <target-repo-path>` 绑定目标仓库 - 依赖：零外部 API，全部基于本地文件系统 + git CLI + sqlite3 - 安装：`npx agent-orchestrator-mcp` 或全局 npm install ## 四大域、22 个工具 ### 域 1：HARNESS（来自 repo-harness）— 7 工具 | 工具 | 功能 | |---|---| | harness_plan | 把 chat 规划固化成 PRD → Sprint → Goal 文件（写入 .ai/harness/） | | harness_goal | 读最新 handoff → 判断下一步 → 返回可执行指令 | | harness_resume | 从 handoff 精确恢复：进度、阻塞项、改动文件 | | harness_review | git diff vs Goal 验收标准 → 通过/不通过+理由 | | harness_status | 全局状态：活跃 sprint、goal 进度、阻塞依赖图 | | harness_handoff_read | 读指定 handoff 文件原始内容 | | harness_handoff_write | 写 handoff 文件（给下一个执行器交接） | ### 域 2：RECALL（来自 recall 技能）— 7 工具 | 工具 | 功能 | |---|---| | recall_search | 跨平台关键词搜索（Claude + WB + Codex 三路并行） | | recall_session | 按 session ID 拉取完整对话详情 | | recall_codex | 读 Codex 线程（含系统注入过滤） | | recall_codex_filter | 纯工具：剥离 Codex JSONL 系统注入噪声 | | recall_wb_tasks | 查 WB 任务索引（含已归档，只读 SQLite） | | recall_context_build | 从历史对话+当前仓库构建统一上下文 | | recall_handoff_report | 从旧会话生成结构化交接报告 | ### 域 3：PARALLEL（来自 parallel 技能）— 7 工具 | 工具 | 功能 | |---|---| | parallel_worktree_create | 给分支创建隔离 worktree | | parallel_worktree_list | 列出所有活跃 worktree 及分支/路径 | | parallel_worktree_remove | 清理指定 worktree | | parallel_conflict_check | 扫描 N 个分支间文件重叠，报告潜在冲突 | | parallel_merge_plan | 根据依赖关系生成安全合并顺序 | | parallel_status | 所有并行 agent/task 实时状态面板 | | parallel_lock | 共享资源互斥锁 acquire/release | ### 域 4：ORCHESTRATION（胶水层）— ~4 工具 | 工具 | 功能 | |---|---| | agent_orchestrate | 一键编排：recall上下文 → harness_plan拆任务 → parallel_worktree隔离 → 返回执行计划 | | state_snapshot | 保存全局恢复点（git+harness+worktree 状态） | | context_unified | 融合 记忆+状态+并行视图 为一份上下文 | | agent_health | 检查各平台 agent/session 存活状态 | ## 接入方式示例（mcp.json） ```json { "agent-orchestrator": { "command": "node", "args": ["/path/to/agent-orchestrator-mcp/dist/index.js", "--repo", "/your/target/repo"] } } ``` # 请你回答以下问题 1. **架构评审**：这个 4 域 22 工具的划分是否合理？有没有工具该拆、该合、或该删的？ 2. **工具粒度**：每个工具的输入输出 schema 你觉得该怎么设计？（特别是 harness_goal、agent_orchestrate 这两个最核心的工具） 3. **域间交互**：Orchestration 域调用其他三个域时，你建议用什么模式？是简单的函数调用，还是需要一个中间的事件总线/状态机？ 4. **错误处理策略**：MCP tool 执行失败时（如 worktree 已存在、handoff 文件损坏、Codex JSONL 解析失败），错误信息应该怎么结构化返回给 LLM agent？ 5. **安全性**：parallel_lock（互斥锁）、harness_handoff_write（写仓库文件）这些有副作用的工具，是否需要额外的确认机制？还是完全信任调用方 agent？ 6. **性能考虑**：recall_search 要扫大量 JSONL 文件，有什么索引/缓存策略？第一次搜索慢 vs 后续搜索快的体验怎么保证？ 7. **与现有 repo-harness 的关系**：我的 repo-harness 已经装了（Bun 版，带 Codex hooks）。这个新 MCP Server 应该： - (a) 完全替代它的功能？ - (b) 调用它作为底层引擎？ - (c) 与它并存、各管各的？ 给出你的推荐及理由。 8. **如果你来重新设计**：你会怎么调整？有没有我想不到的坑或者更好的抽象？ 9. **实现优先级**：如果分阶段交付，你建议的 MVP 路线是什么？（哪些工具必须第一批做，哪些可以后续加） 10. **命名**：`agent-orchestrator-mcp` 这个名字你觉得合适吗？有没有更精准的表达？ 请尽量具体、技术化地回答。我可以根据你的反馈调整设计方案后再动手实现。 ``` ## 复制到这里结束 ↑