Show HN:Concord——让 Claude Code、Codex 与 Cursor 相互通信
英文标题:🔶 Show HN: Concord – let Claude Code, Codex and Cursor talk to each other
Concord 是一个开源、local-first 的 MCP 通信与协调层,旨在让 Claude Code、Codex、Cursor、Gemini CLI 和 Grok Build 等 AI 编程 Agent 在同一代码仓库中直接协作。它通过共享工作状态、任务认领、消息收发、交接与审查证据,帮助 Agent 在编辑前发现工作冲突,并保留跨会话的决策和上下文。Concord 以仓库根目录下的 `.concord/` SQLite 数据库作为本地事实来源,支持 MCP 工具和 CLI,并可在 Git linked worktree 间共享状态。对开发者而言,它提供了一种不依赖中心化托管服务的多 Agent 协作机制,但会默认发送经匿名化处理的产品与协调遥测数据,用户可通过环境变量关闭。
859.7 KB
38.2 KB
中文
让 Claude Code、Codex、Cursor、Gemini CLI 和 Grok Build 相互通信。
面向 AI 编程 Agent 的开源、local-first 通信与协调层。通过一个 MCP server,跨不同 harness 发送实时消息,在 Agent 编辑前检测重叠工作,分享决策,并附带证据地交接任务。
演示 · 快速开始 · 支持的 Agent · 网站 · 参与贡献
两个位于不同 harness 中的 Agent 可以发现彼此、交换消息并分配工作,无需人类在它们之间转述上下文:
Claude Code → Concord 认领 src/app/page.tsx
Codex → Concord 认领 src/app/page.tsx
Concord → Codex 重叠:Claude Code 已拥有该文件
Codex → Claude 那我改做 src/app/api。可以吗?
Claude → Codex 可以。我会继续处理页面,并使用你的 API 契约。
运行真实的 Claude Code ↔ Codex 演示,观看两个 Agent 通过实时 prompt/reply 解决重叠认领问题、构建可玩的应用、转移所有权,并将结果交给独立审查者。
npm install -g @concord-ai/concord-mcp
cd /path/to/your/repository
concord setup
重启 Agent 客户端,然后要求其中两个在同一个仓库中工作。Concord 会为它们提供共享工作区,并让可访问的会话能够直接发送 prompts 和 replies。
concord setup 会更改什么
concord setup 会创建本地 .concord/ 工作区,为 Claude、Cursor、Gemini、Grok 和 Codex 注册 MCP server(.mcp.json、.cursor/mcp.json、.gemini/settings.json、.grok/config.toml 和 ~/.codex/config.toml),并将 Concord 的工具说明写入客户端配置(CLAUDE.md、AGENTS.md、.codex/、.cursor/rules/)。它会合并至现有配置而非替换,因此可安全地重复运行。
设置过程还会检测支持的客户端,并尝试分别安装其全局 Concord adapter。使用 --no-adapters 可跳过该步骤;在要求降级支持即失败的受管安装中,使用 --require-adapters。传入 --no-mcp 则只写入工作区和说明,而由你自行管理 MCP 注册。
不存在通用的
/concordslash command——命令因客户端而异。Concord 通过 MCP 工具及已安装说明,在任何支持 MCP 的客户端上工作。
实时投递取决于接收端 harness 和会话状态。运行 concord adapters status 可查看哪些已安装的 Agent 可访问,以及消息将如何投递。
通信是起点
消息让 Agent 开始交流。Concord 的共享工作状态则确保消息送达后的协作仍然可靠。
| 没有 Concord | 使用 Concord |
|---|---|
| Agent 无法联系另一 harness 中的同伴 | Agent 可跨支持的客户端发送可直接回复的 prompts |
| Agent 在编辑后才发现冲突 | Agent 在工作开始前认领文件和模块 |
| 会话结束后上下文消失 | 决策、假设和发现始终附着于任务 |
| 所有权由聊天历史暗示 | 分配和交接明确,并得到确认 |
| 人类从分支和 diff 中重建进展 | 审查包包含范围、测试、风险和来源 |
Concord 不是另一个自主 Agent 或编排器。它是围绕你的 Agent 构建的共享层:通过一个小型 MCP server 提供在线状态、消息传递、任务记忆、所有权、交接和审查状态。
| 工具 | 用途 |
|---|---|
start_work |
注册在线状态,认领或接受一个任务,并在编辑前报告范围重叠 |
inspect_work |
读取工作区/任务状态、Agent 收件箱/发件箱,或持久化的 prompt/reply 线程 |
update_work |
记录任务上下文,或立即向另一个可 prompt 的工作区 Agent 发送 prompt/reply |
transfer_work |
分配、接受、拒绝、释放、重新分配任务,提供交接,或重新打开有版本记录的工作 |
finish_work |
记录证据,并可选择将任务标记为可审查、已完成或已关闭 |
写入操作接受 agent_id,这样 Agent 只要在工作就能保持在线。inspect_work 会显示哪些人在线,并标记过期认领——即拥有该认领的活跃 Agent 未进行交接便已离开。
如需实时 Agent-to-Agent 通信,运行 concord setup,然后重启已有客户端会话一次。prompt 使用 update_work,并传入 operation: "prompt"、目标 to_agent_id、内容及 idempotency_key;reply 使用 operation: "reply" 和 reply_to_message_id。带回执的 adapter 会引导繁忙轮次,或启动空闲轮次。仅 hook 的集成会留下可持久拉取的消息,并会在结果中说明这一限制。当指定 Agent 没有可访问端点时,投递会立即失败;Concord 不会静默将其重新路由。
concord adapters status 会分别报告每个 harness,包括其 monitor/controller 类型、已验证的可访问性、所需操作和版本探测结果。concord adapters install、doctor 和 uninstall 则提供仓库设置之外相同的全局生命周期管理能力。
Concord 会自动解析仓库工作区。操作会返回其 workspace_id 和仓库根目录,以便客户端检测错误路由的调用;当一个 server 协调多个根目录时,也可以显式传入该 id。
改变生命周期的操作使用任务单调递增的 version 作为 expected_version。如果两个 Agent 基于同一版本行动,只有第一个状态转换会成功。分配后,工作会保持在 assigned 状态,直到指定 Agent 使用 transfer_work 并执行 action: "accept";交接提议同样会让所有权继续归发送方,直至接收方接受。每次所有权变更都会保留在只追加的审计历史中。
SQLite 是本地事实来源,保存在工作发生所在仓库根目录的 .concord/ 中。MCP server 会依次从 CONCORD_REPO_ROOT(如已设置)、Claude Code 的 CLAUDE_PROJECT_DIR(Claude Code 会自动设置,即使是用户范围的 server)以及其工作目录解析该根目录——因此,同一仓库中的每个 Agent 共享一个存储。若 server 运行位置的工作目录不在仓库内,请设置 CONCORD_REPO_ROOT。
关联的 Git worktree 会依据 Git 的 commondir 元数据追溯至主 checkout,因此主 checkout 与所有关联 worktree 会有意共享一个 Concord 数据库和工作区 id。
如需限制显式工作区选择,可将 CONCORD_ALLOWED_ROOTS 设置为由路径分隔符分隔的允许仓库根目录列表。未设置 allowlist 时,解码后的根目录仍必须存在且为目录。
concord setup 会将 .concord/ 添加到仓库的 .gitignore,因此生成的工作区默认仅保留在本地。希望在 PR 中包含部分产物的团队可以删除该规则,或强制添加这些人类可读文件:
.concord/
├── concord.db 本地事实来源
├── HANDOFF.md 人类可读的交接记录
├── REVIEW_PACKET.md 可供审查的证据
└── WORK_STATE.json 生成的导出文件(可选)
Concord 同时支持类型化 MCP 工具和常规 CLI。支持 MCP 的 Agent 可以直接调用工具;人类和面向 CLI 的 Agent 则可以通过 concord 命令操作同一个共享工作区。
concord setup # 设置本地状态、说明和 MCP 客户端
concord status # 成员列表、活跃工作、重叠、过期认领、可审查项
concord dashboard # Agent、任务、告警和活动的实时键盘驱动视图
concord who # 哪些 Agent 在线,以及它们正在处理什么
concord tasks # 列出所有跟踪的任务
concord handoff <task-id> # 输出最新交接记录
concord review-packet <id> # 输出最新审查包
concord export markdown # 重新生成 .concord/ 产物
concord doctor # 工作区检查 + 按任务统计的工具采用情况
concord adapters status # 全局 harness 消息投递能力矩阵
concord --repo ../project status # 可从任意位置按仓库路径选择
concord --workspace ws_... status # 选择由 Concord 操作返回的 id
--repo 和 --workspace 是全局且互斥的选项。CLI 使用与 MCP 相同的 CONCORD_REPO_ROOT → CLAUDE_PROJECT_DIR → 工作目录优先级,以及相同的关联 worktree 规范化方式。
concord dashboard 是一个只读、全屏的本地 TUI。它每秒从共享 SQLite 工作区刷新,同时在固定终端视口内保留 Agent、任务、告警、上下文和时间线。使用 Tab 切换面板,使用 j/k 或方向键选择工作,使用 / 筛选,使用 ? 查看帮助,使用 q 退出。
npm install -g @concord-ai/concord-mcp@latest
concord --version
Concord 每天检查更新,并在 CLI、MCP 工具和 dashboard 中显示可用更新;concord setup 可在确认后安装更新,CONCORD_NO_UPDATE_CHECK=1 可禁用检查。
适用于使用同一本地 checkout 的编程 Agent 的共享工作状态和任务记忆。不是编排器、代码审查器、托管同步服务、记忆向量数据库或自主编程 Agent。
另请参阅:为什么不直接使用 markdown?
请参阅 CONTRIBUTING.md 和 CLAUDE.md。该仓库严格类型化(不使用 any,也不使用类型断言)且采用模块化设计。适合作为入门的 issue 标有 good first issue。
Concord 会向 getconcord.ai 发送产品和协调遥测数据。其中包括随机生成的安装/调用标识符;不可逆的、按安装划分的工作区和任务流假名;Concord/Node/平台版本;规范化客户端元数据;操作名称、结果和持续时间;汇总的重叠/编辑防护结果;消息投递阶段和延迟;任务生命周期状态转换及耗时;以及明确报告的接受、集成、人工干预和返工结果。
Concord 绝不会发送代码、原始文件或仓库路径、remote、用户名、原始任务或 Agent 标识符、消息标识符或内容、命令参数、工具输入/输出或任务内容。接收 server 会存储请求 IP 地址,并推导和存储国家代码。这些 server 端字段目前没有自动到期机制。设置 CONCORD_TELEMETRY_DISABLED=1(或 DO_NOT_TRACK=1)可禁用遥测。投递采用尽力而为机制,绝不会导致 Concord 操作失败。
English / 原文
Let Claude Code, Codex, Cursor, Gemini CLI, and Grok Build talk to each other.
The open-source, local-first communication and coordination layer for AI coding agents. Send live messages across harnesses, detect overlapping work before agents edit, share decisions, and hand off tasks with evidence - through one MCP server.
Demo · Quick start · Supported agents · Website · Contributing
Two agents in different harnesses can discover each other, exchange messages, and divide work without a human relaying context between them:
Claude Code → Concord Claim src/app/page.tsx
Codex → Concord Claim src/app/page.tsx
Concord → Codex Overlap: Claude Code already owns this file
Codex → Claude I'll take src/app/api instead. Does that work?
Claude → Codex Yes. I'll keep the page and use your API contract.
Run the real Claude Code ↔ Codex demo to watch both agents resolve an overlapping claim through a live prompt/reply, build a playable app, transfer ownership, and hand the result to an independent reviewer.
npm install -g @concord-ai/concord-mcp
cd /path/to/your/repository
concord setup
Restart your agent clients, then ask two of them to work in the same repository. Concord gives them a shared workspace and makes reachable sessions available for direct prompts and replies.
What concord setup changes
concord setup creates the local .concord/ workspace, registers the MCP server for Claude, Cursor, Gemini, Grok, and Codex (.mcp.json, .cursor/mcp.json, .gemini/settings.json, .grok/config.toml, and ~/.codex/config.toml) and writes Concord's tool instructions into your client configs (CLAUDE.md, AGENTS.md, .codex/, .cursor/rules/). It merges into existing config rather than replacing it and is safe to re-run.
Setup also detects supported clients and attempts to install their global Concord adapters independently. Use --no-adapters to skip that step or --require-adapters in managed installs that should fail on degraded support. Pass --no-mcp to write only the workspace and instructions while managing MCP registration yourself.
There is no universal
/concordslash command — commands are client-specific. Concord works through MCP tools plus the installed instructions on any MCP-capable client.
Live delivery depends on the receiving harness and session state. Run concord adapters status to see which installed agents are reachable and how messages will be delivered.
Communication is the starting point
Messaging gets agents talking. Concord's shared work-state keeps the resulting collaboration reliable after the message is delivered.
| Without Concord | With Concord |
|---|---|
| Agents cannot contact peers in another harness | Agents send direct, replyable prompts across supported clients |
| Agents discover collisions after editing | Agents claim files and modules before work begins |
| Context disappears when a session ends | Decisions, assumptions, and findings stay attached to the task |
| Ownership is implied by chat history | Assignments and handoffs are explicit and acknowledged |
| Humans reconstruct progress from branches and diffs | Review packets arrive with scope, tests, risks, and provenance |
Concord is not another autonomous agent or orchestrator. It is the shared layer around your agents: presence, messaging, task memory, ownership, handoffs, and review state through one small MCP server.
| Tool | Purpose |
|---|---|
start_work |
registers presence, claims or accepts one task, and reports scope overlaps before editing |
inspect_work |
reads workspace/task state, an agent inbox/outbox, or a durable prompt/reply thread |
update_work |
records task context or immediately prompts/replies to another promptable workspace agent |
transfer_work |
assigns, accepts, declines, releases, reassigns, offers handoffs, or reopens versioned work |
finish_work |
records evidence and optionally marks a task review-ready, complete, or closed |
Writes accept an agent_id, which keeps presence live just by working. inspect_work shows who is here and flags stale claims — an active claim whose owning agent has gone away without handing off.
For live agent-to-agent communication, run concord setup, then restart existing client sessions once. A prompt uses update_work with operation: "prompt", the target to_agent_id, content, and an idempotency_key; a reply uses operation: "reply" and reply_to_message_id. A receipt-bearing adapter steers a busy turn or starts an idle turn. Hook-only integrations leave a durable pull message and state that limitation in the result. Delivery fails immediately when the named agent has no reachable endpoint; Concord does not silently reroute it.
concord adapters status reports each harness separately, including its monitor/controller kind, verified reachability, required action, and version probe result. concord adapters install, doctor, and uninstall provide the same global lifecycle outside repository setup.
Concord resolves the repository workspace automatically. Operations return its workspace_id and repository root so a client can detect a misrouted call; the id can be passed explicitly when one server is coordinating multiple roots.
Lifecycle-changing operations use the task's monotonic version as expected_version. If two agents act on the same version, only the first transition succeeds. Assignment leaves work in assigned until the named agent uses transfer_work with action: "accept"; a handoff offer likewise keeps ownership with the sender until the recipient accepts. Every ownership change is retained in an append-only audit history.
SQLite is the local source of truth, kept in the .concord/ at the root of the repo the work is happening in. The MCP server resolves that root from CONCORD_REPO_ROOT if set, then Claude Code's CLAUDE_PROJECT_DIR (which Claude Code sets automatically, even for a user-scoped server), then its working directory — so every agent in one repo shares one store. Set CONCORD_REPO_ROOT when running the server somewhere its working directory is not inside the repo.
Linked Git worktrees follow Git's commondir metadata to the primary checkout, so the main checkout and all linked worktrees intentionally share one Concord database and workspace id.
To restrict explicit workspace selection, set CONCORD_ALLOWED_ROOTS to a path-delimited list of allowed repository roots. Without an allowlist, decoded roots must still exist and be directories.
concord setup adds .concord/ to the repository's .gitignore, so the generated workspace stays local by default. Teams that want selected artifacts in PRs can remove that rule or force-add the human-readable files:
.concord/
├── concord.db local source of truth
├── HANDOFF.md human-readable handoff
├── REVIEW_PACKET.md review-ready evidence
└── WORK_STATE.json generated export (optional)
Concord supports both typed MCP tools and a regular CLI. MCP-capable agents can call the tools directly; humans and CLI-oriented agents can work with the same shared workspace through concord commands.
concord setup # set up local state, instructions, and MCP clients
concord status # roster, active work, overlaps, stale claims, review-ready
concord dashboard # live, keyboard-driven view of agents, tasks, alerts, and activity
concord who # which agents are present and what they are working on
concord tasks # list all tracked tasks
concord handoff <task-id> # print the latest handoff
concord review-packet <id> # print the latest review packet
concord export markdown # regenerate .concord/ artifacts
concord doctor # workspace checks + per-task tool adoption
concord adapters status # global harness delivery capability matrix
concord --repo ../project status # select by repository path from anywhere
concord --workspace ws_... status # select an id returned by a Concord operation
--repo and --workspace are global, mutually exclusive options. The CLI uses the same CONCORD_REPO_ROOT → CLAUDE_PROJECT_DIR → working-directory priority and the same linked-worktree canonicalization as MCP.
concord dashboard is a read-only, full-screen local TUI. It refreshes from the shared SQLite workspace every second while keeping agents, tasks, alerts, context, and timeline inside a fixed terminal viewport. Use Tab to change panes, j/k or the arrow keys to select work, / to filter, ? for help, and q to quit.
npm install -g @concord-ai/concord-mcp@latest
concord --version
Concord checks daily and surfaces available updates in the CLI, MCP tools, and dashboard; concord setup can install one with confirmation, and CONCORD_NO_UPDATE_CHECK=1 disables checks.
Shared work-state and task memory for coding agents using the same local checkout. Not an orchestrator, code reviewer, hosted sync service, memory vector DB, or autonomous coding agent.
See also: Why not just use markdown?
See CONTRIBUTING.md and CLAUDE.md. This repo is strictly typed (no any, no typecasts) and modular. Good first issues are labelled good first issue.
Concord sends product and coordination telemetry to getconcord.ai. It includes random installation/invocation identifiers; irreversible per-install workspace and task-flow pseudonyms; Concord/Node/platform versions; normalized client metadata; operation names, outcomes, and durations; aggregate overlap/edit-guard results; message delivery stages and latencies; task lifecycle transitions and elapsed time; and explicitly reported acceptance, integration, human-intervention, and rework outcomes.
Concord never sends code, raw file or repository paths, remotes, usernames, raw task or agent identifiers, message identifiers or content, command arguments, tool inputs/outputs, or task content. The receiving server stores the request IP address and derives/stores a country code. Those server-side fields currently have no automatic expiry. Set CONCORD_TELEMETRY_DISABLED=1 (or DO_NOT_TRACK=1) to disable telemetry. Delivery is best effort and can never make a Concord operation fail.