多智能体协作台firstintent/ccteam

ccteam
ccteam 把你已经在用的编码智能体（Claude Code、Codex、Grok、Kimi、Deepseek Harness）变成一个团队——任何会话都可以在任何机器上生成、派发并收集来自任何厂商的工作，而你可以从 Telegram、Lark 或浏览器标签页中掌控一切。

每个编码 CLI 单独使用都很出色，但彼此孤立——一个终端、一个上下文、没有同事：

- Claude Code——规划最深入
- Codex——长时间稳定处理繁重任务
- Grok——回答最快
- Kimi——以极低成本完成批量工作
- DSH——在你自己的 DeepSeek Harness 网络空间中与你并肩协作
- Pi——一个 CLI 覆盖多个提供商（anthropic/…、openai/…），运行在你自己的机器上

ccteam 就是它们所缺少的连接组织——身份、路由、投递保证、护栏、成本账本——而团队如何组织自身，则留给你通过版本化的提示词来定义。

团队页面上的一个下午——跨四个厂商的 50 个活跃会话，每一次委派都是一条可追溯的父→子边，每一美元都在账本上。

用法

1 · 从 Telegram / Lark 远程控制

粘贴一次机器人令牌（设置 → 访问），聊天就变成了完整的控制台——完成通知、HITL [approve] [deny] 按钮，以及交付的文件都会落在同一个会话中。午夜派发，合上笔记本电脑，早餐时查看结果：

/cd demo                        # 选择一个项目；你的下一条消息会与它对话
/new codex effort=high          # 更多会话：/new [vendor] [role] [model=…] [effort=…]
@s2 run the test suite          # 直接寻址任何会话
/status  /sessions  /stop s3    # 健康 · 集群 · 成本 · 停止
/inbox +30m remind me …         # 安排一次性的用户轮次；/inbox 列出 · cancel dN

Telegram 就是整个控制台——切换项目、寻址任意会话，一张 /status 卡片即可展示主脑以及它雇用的每一个委派者。

2 · 从 Web 控制台远程操控

安装程序会运行守护进程；ccteam status 会重新打印你的链接（http://:7331/?token=…）——在局域网内任意设备上打开它。它是一个聊天外壳，而不是仪表盘：

没有“创建会话”表单——在一个胶囊控件中选择项目 · 主机 · 供应商 · 模型，然后直接输入；下方的编队剧本可预填整套阵容。

- 六个编队剧本（指挥官与团队、驾驶员与顾问、交叉评审、对决、研究三角验证、成本金字塔），可为启动器预填供应商阵容
- 每个会话一个 Chat 标签页（在适用时还提供一个字节级还原的终端），包括输入框上方的时钟，用于将延迟的用户发言排队
- 一个 Team 页面：实时委派拓扑——每个会话实际运行的供应商、模型和推理强度、成本，每一行都是真实链接，因此父会话及其委派者可以并排打开——外加一份分工章程（每个项目的 routing.md，智能体通过 status 读取）可就地编辑，以及一个 Runs 标签页，列出每一次 ccteam Flow 运行及其雇用的会话
- 一个 DSH 页面，在 ccteam 内打开 DeepSeek Harness Web：守护进程对请求进行身份验证，启动或附加到正确的本地 DSH Web 实例，并为每个已登录用户提供独立的 DSH 主目录
- 一个带每日预算上限的成本胶囊控件
- 侧边栏中的每个项目 ⋯ 菜单：在那里启动会话、复制其路径，或将项目移出 ccteam（注销并停止其活动会话——你的目录和代码绝不会被改动）
- 市场与设置

控制台所做的一切也都是 /api/v1（OpenAPI 位于 /api/docs）。

3 · 在 claude 会话内部编排团队

任何已注册的会话都可以雇用其他会话——用平实的语言说出来，agent / agent_read 就会在底层运行（带有诚实的 working / idle 信号，因此没人需要靠沉默来猜测）：

Spawn a codex session, have it implement RFC-12 and run the tests; report back when green.

Plan this refactor, then delegate: codex implements, grok profiles the hot path in
parallel, kimi sweeps the rename across the repo. Collect everything into one summary.

Spawn a claude reviewer on s2's diff — I'm not merging until it signs off.

4 · 多台机器，一个控制台
用加入令牌注册卫星（设置 → 访问）——它会主动拨出连接到你的守护进程，所以位于 NAT 后的笔记本电脑也能正常工作。项目绑定到主机并在其所在之处运行：生成到 GPU-box 项目中，其测试就在 GPU box 上运行，而转录、成本和团队视图都保留在一个控制台中。切换机器只是切换项目而已。

卫星执行目前运行 Claude 会话；其他供应商在守护进程所在的机器上运行。

5 · 用代码编排，而非用提示词

当工作的形态已知时，把它写下来，而不是去请求它。flow 是 ccteam 运行器执行的一个普通 JS 脚本——agent() / parallel() / pipeline() / phase() 作用于真实的跨 harness 雇佣，每个叶子节点在账本上都是自己的会话：

ccteam flow new branch-review          # 搭建一个脚本 + 它可以调用的 API
ccteam flow run branch-review.flow.js --args '{"base":"main"}' --budget 5
ccteam flow eval               # 用你自己的 flow 给已完成的运行评分

运行会被记入日志，因此一次运行能在守护进程重启后存活，--resume 会把它接续起来——工作进程比运行器活得更久。--parallel / --max-agents / --max-cost 是刹车，团队页面的 Runs 标签页会显示每一次运行及其雇佣的会话。

独立地，一个策略钩子——/.ccteam/hooks/pre-agent，任何可执行文件，每次调用时重新读取——会拦截每一次委派，无论它是由人、代理还是 flow 发起的。它会通过 stdin 收到调用者、请求以及实时的按 harness 配额映射；退出码 0 允许，退出码 2 拒绝并将你的 stderr 原样转发给调用代理，而一个损坏的脚本会以可区分的方式拒绝，而不是静默放行。

在全部五种模式之下是相同的六个 MCP 工具，对每个会话可用，对注册后你手动启动的普通 CLI 可用，也对任何外部代理可用——只要它通过 POST /mcp 出示注册凭据——每个供应商配置或每次复制按钮对应一个凭据，守护进程在连接时为每个进程颁发自己的身份，因此两个共享同一配置的代理仍然是两个调用者，拥有各自的账本行和各自的子节点：

agent · agent_read · agent_stop
status (+ 其发现别名 grok_claude_codex_kimi) · chat_send_file

守护进程负责路由和记录——跨重启的至少一次通知、幂等键、子节点的回合在告知其父节点之前先写入磁盘、以理由拒绝失控扇出的护栏。当由 Web 驱动的会话在无人注视控制台时完成自主工作，最终答案会镜像到你的 IM；IM 的 /status 卡片让你一眼看到会话正在工作的子节点。它从不调度；何时委派存在于你纳入版本管理的提示词中。

- 通俗语言演练 → 编排指南
- MCP 工具参考（全部六个工具、界面、协议）→ mcp.md
- 策略钩子与流程（脚本 API、运行日志、评估循环）→ hook-dynamic-workflows.md（中文）
- 每条命令 → 手册（English · 中文）

深入 DeepSeek Harness

ccteam 也原生存在于 DeepSeek Harness 自带的 Web UI 中，作为一个 DSH 客户端插件——@ccteam/ccteam-ui，它不是上述控制台的移植版，而是使用 DSH 自身的插槽、原语和区域设置构建的。安装一次即可获得三个界面和一个引擎监管器：

| 界面 | 面向 | 它能为你提供什么 |
|---|---|---|
| Workbench | 使用 DSH Web 的人 | 从 DSH 侧边栏底部的按钮打开的全页 ccteam 工作台：跨 harness 的团队树（搜索、按项目折叠/展开、悬停 ⋯ 菜单）、原生级对话（流式 Markdown、工具步骤、选择提示、附件、回合中切换模型/effort、中断），以及详情列——可停靠在 DSH 自身窗格旁边，也可展开为全页。 |
| Tools | DSH 智能体（LLM） | 上述同样的六个 MCP 工具，可从 DSH 会话内部调用。 |
| Transport | ccteam | 让 ccteam 像雇佣任何其他 harness 一样雇佣 DSH 会话的通道。 |
| Engine | 你 | ccteam 守护进程本身，随插件作为平台包（@ccteam/engine--）一起提供：从插件设置卡片的 Engine 部分进行安装、启动和监管——状态、版本、Start / Stop / Restart / Update engine、Start the engine when the plugin loads 开关、引擎日志。 |

使用 dsh plugin --profile web add @ccteam/ccteam-ui 安装并重启 dsh web：插件会带上引擎、启动守护进程，并从同一台机器上的 ~/.ccteam 读取你的控制台令牌——无需粘贴任何内容。如果你的 DSH 已经在通过 ccteam 运行（/new dsh、ccteam DSH 页面，或带 vendor:"dsh" 的 agent），插件及其凭据会为你自动生成。无论哪种方式，它都是与 CLI 和 ccteam web 共享的同一个守护进程：插件会附加到正在运行的守护进程，绝不会针对另一个 ~/.ccteam 启动第二个守护进程，也绝不会在 DSH 重启时停止它。完整设置（两种安装路径、共存规则、故障排除）见 DSH 插件指南（中文）。

安装

可在 macOS、Linux 和 Windows（通过 WSL） 上运行。

[!IMPORTANT]
自带你的编码 CLI——开始前至少安装并认证一个。 ccteam 是桥梁，而不是智能体：它会启动项目所绑定机器上已有的厂商 CLI，因此缺失的厂商（或已安装但未认证的厂商）无法承载会话。

- Claude Code — 安装 Claude Code，然后运行 claude auth login
- Codex — 安装 Codex CLI，然后运行 codex login
- Grok Build — 安装 Grok CLI，然后运行 grok login
- OpenCode — 安装 OpenCode，然后运行 opencode auth login
- Kimi Code — 安装 Kimi Code，然后运行 kimi login
- DSH — 使用 npm i -g @deepseek-ai/dsh 安装 DeepSeek Harness。DSH 会话和 DSH Web 在设置了 DEEPSEEK_API_KEY 时使用它，否则使用该身份的 DSH Settings → Models 配置。
- Pi — 安装 Pi，然后设置你的提供商密钥，并用 pi auth check --provider  检查

其中任意一个就足以开始。之后 ccteam status 和 Settings → Hosts 会按机器报告已安装哪些厂商、它们的版本，以及每个是否真正通过了身份验证——仅仅位于 PATH 上从来不算已登录。

1 · 一键脚本

curl -sSL https://raw.githubusercontent.com/firstintent/ccteam/main/install.sh | sh

一个静态二进制文件放入 ~/.local/bin，无需 sudo。每一种安装方式——脚本、make install、ccteam update 以及 DSH 插件——都通过同一套阶梯规则解析目标位置（CCTEAM_INSTALL_DIR → ccteam 已存在的位置 → ~/.local/bin），因此升级会替换你实际正在运行的那份副本，而不会留下第二份来遮蔽它。

2 · 从 DeepSeek Harness 安装 — 一条命令，引擎内置：

dsh plugin --profile web add @ccteam/ccteam-ui

重启 dsh web，插件会通过同一套阶梯规则从其平台包安装 ccteam 引擎，启动守护进程，并在其设置卡片中显示一个 Engine 部分。它是一个共享守护进程：ccteam CLI、ccteam web 和该插件都使用同一个 ~/.ccteam——谁先启动谁就胜出，其他的则接入（详情）。

3 · 让智能体来做 — 粘贴到你已有的任意智能体中：

安装 https://github.com/firstintent/ccteam —— 遵循仓库中的 INSTALL.md。

4 · 从源码安装（Rust + Node）：

git clone https://github.com/firstintent/ccteam && cd ccteam && make install

启动它 — ccteam start 会在后台运行 ccteam，并在你关闭终端后继续保持运行（make install 和 DSH 插件已经为你做了这件事）。这是启动守护进程的唯一方式，并且它是幂等的：第二次 ccteam start——无论是来自 shell、脚本还是 DSH 插件——都会报告已有一个正在运行，而不会启动另一个。随时管理它：

ccteam start                 # 在后台启动；打印你的 Web 控制台链接
ccteam daemon status         # 它是否在运行，运行的是哪个版本？
ccteam daemon restart        # 重启它
ccteam stop                  # 停止它（你的会话会在下次启动时恢复）
ccteam daemon logs -f        # 实时查看日志

重启电脑后，再次运行 ccteam start 即可让 ccteam 恢复运行。
在浏览器中配置 —— 打开打印出的链接（ccteam status 也会显示），创建一个项目，然后直接输入即可；会话会在你发送第一条消息时诞生。然后：

- 设置 → 访问 —— 所有连接到 ccteam 的内容都集中在一个页面上：供外部代理使用的可复制粘贴的 MCP 配置（一个限定到单个项目的凭据，按各供应商期望的真实配置格式呈现，或以纯文本形式用于 DSH 等由插件支持的流程，之后可列出并撤销 —— 密钥只显示一次，之后不再显示）、用于新机器的卫星加入令牌、你自己的 Telegram/Lark 机器人（每个平台一张编号的两步卡片 —— 先保存凭据，再绑定机器人回应谁，发送者捕获会自动开始），以及每用户登录链接
- 设置 → 主机 —— 每台机器的供应商面板（已安装 / 版本 / 就绪状态），以及一键将 ccteam MCP 工具注册到具有可写配置的供应商 CLI 中（Claude Code、Codex、Grok、OpenCode、Kimi），这样即使是手动启动的会话也能雇佣团队。同一页面上 DSH 的一键操作则会将 ccteam 的插件注册到你自己的 ~/.dsh Web 配置文件中（你自己的 DSH 会话在粘贴访问凭据后也可以进行编排）；Pi 通过一个由 ccteam 拥有的桥接获得团队工具，该桥接会加载到 ccteam 生成的会话中，因此你在 shell 中手动启动的 pi 完全不受影响
- 工作流 → 市场 —— 安装技能（安装到你的用户级库 ~/.ccteam/skills 中；技能标签页排在首位）和角色（安装到项目中），并经过校验和验证；可从编辑器将库中的技能附加到任何消息
- DSH —— 将原生 DSH Web 作为一等控制台页面打开。每个身份运行一个 DSH 运行时，而 ccteam 是它的第二个客户端：在 ccteam 中任何位置雇佣的 DSH 会话都会在该同一运行时内创建，实时出现在此页面侧边栏中该项目的工作区下，并可在任务进行中打开以观看或介入 —— 代理的下一次派发会继续同一段对话。所有者看到真实的 ~/.dsh 空间（当存在时，ccteam 会附加到已在 127.0.0.1:3080 上运行的 DSH Web）；每个普通用户获得一个隔离的 $CCTEAM_HOME/runtime/dsh/web// 空间，并预加载 ccteam 客户端插件。它会开箱即用，遵循本机的 DSH 登录，直到用户在 DSH 设置 → 模型中更改；整个身份 —— 菜单会话和雇佣会话都一样 —— 都运行在那一个配置上。用户安装的 DSH 插件会被保留。

工作流中心 —— 技能、角色、市场和 MCP 服务器集中在一处，紧邻项目的经验账本（轮次记录 + 角色/技能指纹）。

控制台绑定到 0.0.0.0:7331，使用令牌认证，无 TLS——请将其保持在受信任的局域网内。DSH Web 默认使用 Web 端口 + 1 上的伴随监听器；用 --dsh-web-bind  覆盖它，或用 --dsh-web-bind off 禁用它。如果你在 ccteam 前面放置 HTTPS，也要代理这个伴随监听器（通常是第二个 HTTPS 端口或子域名）。只代理 :7331 会导致 DSH iframe 混合内容失败，而且 DSH Web 无法安全地挂载在路径前缀下。

DSH Web 的诚实说明：原生 DSH 轮次运行在 DSH 内部，而不是作为 ccteam 会话运行，因此它们不会出现在 ccteam 成本账本中——包括你从 DSH 侧输入到已雇佣会话中的轮次（ccteam 只记录它路由的轮次；DSH 主页保留完整对话）。通过 ccteam DSH 插件委派的工作会正常记账。租户 DSH Web 是同一操作系统用户隔离：DSH 代理可以运行 shell 命令，而自行安装的 DSH 插件是任意 npm 代码，与该用户账户具有相同的信任级别。

链接会话

委派是显式的——代理（或你）说明谁做什么，桥接层负责身份、路由、投递和账本：

agent{vendor:"codex", title:"impl",  task:"implement RFC-12, run tests, report"}
agent{vendor:"grok",  title:"probe", task:"profile the hot path", wait:120}
agent{vendor:"kimi",  title:"chore", task:"apply the rename across every module"}

默认异步：完成通知会像同事回报一样落在父级聊天中。wait 用于你需要内联获取的亚分钟级答案。

常见工作流：

- 规划 → 构建 → 把关——claude 分解并设定约束；codex 实现；在你合并前由竞争模型审查 diff。
- 苦干 + 探查——codex 承担长任务，同时 grok 在 codex 完成一步之前回答快速问题。
- 预算内批量处理——把重复性的 80% 分派给 kimi；把需要判断的调用留给 claude。

谁得到什么，从事实而非猜测开始：一次 status 调用就是花名册——项目主机上已安装、已认证且在预算内的供应商，每个供应商上次声明的模型和推理努力级别，以及你的路由备注（/.ccteam/routing.md 优先于全局回退）。

每个生成入口都为每个供应商接受 model 和 effort，并原样转发两者——供应商对自己的值拥有最终裁决权，因此它拒绝的级别会作为真实错误返回，而不是让会话悄悄以默认值运行。省略它们则保持供应商自己的默认值。各级别阶梯不同（claude low…max，codex low…xhigh，grok low|medium|high，kimi low|high|max，而 pi 的是按模型——它声明所选模型实际支持哪些级别），所以要询问而不是猜测：代理用 status，程序用 GET /api/v1/models，而 Web 编写器的菜单从同一来源渲染。

项目上下文

ccteam 为你的仓库添加一个团队，而不接管它：
- 默认无角色 — 大脑通过供应商自身的机制读取你的 CLAUDE.md / AGENTS.md；ccteam 从不重写项目知识。
- 占用极小 — 仅 .ccteam/（状态）、.claude/agents/（你安装的角色）以及 ccteam 在 .claude/settings.local.json 中的自有部分 — 绝不触碰你的 settings.json。
- 持久会话 — id（s1、s2、……）在守护进程重启和从磁盘冷恢复后依然存在；状态就是你仓库中的普通文件。一个你没有在对话的会话会在空闲窗口后释放其 harness 进程（默认一小时，与提示缓存 TTL 一致），并在你下一条消息时直接恢复，使用相同的 id 和相同的对话 — 因此三十个会话的集群只花费三十份记录，而不是三十个常驻进程。一个会话，一个进程：重启绝不会在回合中途杀死 agent，也绝不会在它旁边启动第二个 — 守护进程让进程完成，将你在此期间发送的内容排队，从供应商自己的记录中恢复它给出的答案，并按 id 恢复会话。

附加功能

- 市场 — 角色从 ccteam-hub 安装到你项目的 .claude/agents/；技能安装到用户级全局库 ~/.ccteam/skills（嵌套 id，通过 ccteam skill source add 使用整仓库源），然后按消息附加到会话 — 该库从不链接或复制到项目中，而项目自有技能作为正常的 git 可见文件位于 .agents/skills/（ccteam skill ensure-project）。所有内容都从固定的上游获取，经 sha256 校验，逐字复制，绝不执行。供应商原生的 Claude Code 插件委托给 Claude Code 自身处理（ccteam 只切换那两个设置键）。
- HITL 审批 — 在审批模式下启动会话，其权限请求会通过供应商的原生门控以 [approve] [deny] 按钮的形式到达你的 IM；拒绝会阻止工具调用，但不会终止回合。

为什么

两年内发布了七款优秀的编码 CLI，而每一款都假设自己是独自存在的。结果就是：你在各个供应商之间 Alt-Tab 切换，重新粘贴上下文，充当消息总线。解决办法不是在顶层加一个框架 — 供应商的 harness 本身已经很好。缺的是它们所缺少的连接组织：跨供应商和机器的身份、路由、投递、成本、可观测性。这就是 ccteam — cc 代表它从中成长出来的 Claude Code，team 代表你的 agent 们所成为的样子。

它刻意保持在底层：

- 无提示注入 — 角色通过供应商的原生机制加载；任务文本逐字转发。
- 无终端抓取 — 状态来自记录和结构化事件。
- 测量值，绝非占位符 — 你看到的上下文读数确实由该供应商报告，并在重启后依然存在；尚未报告的读数显示为未知，而不是 0%。
- 本地优先 — ~/.ccteam 和你的仓库；循环中没有云。
- 预算只做防护，绝不杀死 — 按供应商的每日上限是唯一的自动刹车。

更新

ccteam update                # 原地更新；将守护进程重启到新二进制文件上

ccteam status 会显示你的版本并标记出更新的版本。在 DSH 中，插件的 Engine 部分通过 Update engine 实现同样的功能（引擎来自其平台包，经过相同的排空 + 重启 + 验证流程）；dsh plugin --profile web update @ccteam/ccteam-ui 更新插件本身。（详情：usage。）

卸载
bash
curl -sSL https://raw.githubusercontent.com/firstintent/ccteam/main/install.sh | sh -s -- --uninstall
rm -rf ~/.ccteam        # 状态、密钥、hub 缓存 — 如果你可能还会回来，就保留它

对于每个项目，删除 .ccteam/ 以及 .claude/settings.local.json 中 ccteam 的部分。

支持

- 问题、bug、想法 → issues；欢迎 PR。
- Telegram： @cryptorobsu
- 如果这个团队帮你省去了一次 alt-tab，点个 star 就能让这位杂耍者继续抛接。

许可证

MIT — 参见 LICENSE。基于 Claude Code 构建，驱动 Codex、Grok、OpenCode、Kimi、DSH 和 Pi。