上一篇讲了在腾讯云 CVM 上怎么把 ccteam（仓库 `firstintent/ccteam`，星标 635，综合分 67.8）装起来。这篇换视角：假设你已有一台常年开机的 CVM，怎么用它管一支真正跨机器的编码团队。
## 场景设定

一台 CVM 作**控制台主机**：跑 ccteam 守护进程、控制台，以及除 Claude 之外的厂商会话。一台**卫星机**承载 Claude 会话——它用加入令牌注册后**主动拨号**连到守护进程，躲在哪层 NAT 后都不影响。
这个分工来自一条硬限制：**卫星机执行目前只跑 Claude 会话；其他服务商在守护进程所在的机器上运行**。
## 上午：把工作写下来，而不是开口要

题外一句：如果某类工作的形状已经明确，用 **Flow** 而不是逐个会话手动派活。README 的说法是：**"当工作的形状已经明确，就把它写下来，而不是开口去要。"**
```

````flow` 是一段普通 JS 脚本，由 ccteam runner 执行，`agent() / parallel() / pipeline() / phase()` 作用于真实的跨 harness 雇佣。三条对实战很关键的性质：**每个叶子节点都是账本上自己的会话**（开销可追溯）；**运行过程会记入日志，一次运行能挺过守护进程重启**，`--resume` 会接着跑下去——**worker 比 runner 活得久**。刹车参数记在手上：`--parallel` / `--max-agents` / `--max-cost`。
## 中午：从 IM 远程看结果

CVM 部署的一个实际收益是能离开工位。README 的第一节用法就是把 Telegram / Lark / Slack 变成完整控制台：粘一次 bot token（**Settings → Access**）后，完成通知、HITL 的 `[approve]` `[deny]` 按钮、交付的文件都落在同一会话串里——**"半夜派活，合上笔记本，早饭时看结果。"**
两个值得提前配的细节：**群组回复策略**建议改成"只在被 @ 时回复"，避免团队群刷屏；**Slack 的命令前缀是 `!`**，那里是 `!status` 这种写法。Slack 另有一条实用设计：**每个会话有自己的会话串**，顶层消息开启会话、串内回复只跟它对话，所以**并行会话永不交错**。
## 下午：三类常用工作流

README 给了三种组合：**规划 → 构建 → 把关**（一个模型拆解并设约束、一个实现、第三个在合并前审 diff）；**长跑 + 快问**（一个模型扛长任务、另一个先回答快问题）；**批量省预算**（重复性的 80% 分给便宜模型，需要判断的活留给贵的）。
落实第一类时 `wait` 参数有用——默认是异步的，但"一分钟内能出结果的问答"可以内联等：
```

```派活时 `model` 和 `effort` 会被**原样转发**，而**服务商对自己的取值有最终裁决权**——被拒绝的档位会以真实错误返回，不会让会话悄悄跑在默认档上。**各家档位阶梯不同**（claude low…max / codex low…xhigh / grok low|medium|high / kimi low|high|max），所以派活前用一次 `status` 拿花名册最省事。
## 收工前：看拓扑与账

**Team 页面**：实时委派拓扑——服务商、每个会话实际运行的模型与推理强度、成本；每行都是真实链接，**父会话和它的委派可以并排打开**。还有一份分工章程（每个项目的 `routing.md`，智能体通过 `status` 读取）可以就地编辑。**Runs 标签页**列出每次 Flow 运行和它雇佣的会话。
看账时记住一条边界：**账本只记 ccteam 路由过的轮次**。README 明说**原生 DSH 轮次跑在 DSH 内部、不算 ccteam 会话、不进成本账本**。所以在 CVM 上要养成习惯——**想被记账的工作就走 ccteam 委派**。另外预算的性格是**"只拦不杀"**：它拦住的是新委派，不会终止正在跑的任务。
## 一点运维经验

**第一，会话的持久性比想象中好，可以放心重启。** 会话 id（`s1`、`s2`……）**在守护进程重启后依然有效、能从磁盘冷恢复**；**一个会话一个进程**，重启**绝不会在回合中途杀掉智能体**——守护进程会让进程跑完、把消息排队、从服务商自己的记录找回回答、再按 id 恢复。空闲会话一小时后才释放 harness 进程，下次发消息立刻回来、**id 与对话不变**。
**第二，CVM 重启后要手动拉起来。** 这条唯一需要写进 runbook：重启机器后跑一次 `ccteam start`；它幂等，重复执行只会报告已有一个在跑。
需要精细控制委派规则时还有一个钩子：`<project>/.ccteam/hooks/pre-agent`，**每次调用都重新读取**，退出 2 就拒绝并把 stderr 原样转达给发起方。注意它是 fail-closed——**脚本出错时会拒绝而不是放行**，所以钩子写坏会拒掉所有委派。
## 总结

用 CVM 管跨机器团队的分工由一条限制决定：**卫星机只跑 Claude 会话，其他厂商在守护进程所在机器上跑**。工作流层面，形状明确的工作用 Flow 写下来（可 resume、每个叶子都记账），不确定的用 IM 远程盯；收工前看 Team 拓扑与 Runs 账本，并记住只有**通过 ccteam 委派**的轮次才进账本。同类插件的中文清单与安装形态见 [DeepSeek Harness Hub 插件清单](https://dpharness.com/top?utm_source=txyun&utm_medium=article)。
## 适合与不适合

**适合**：已经在用多个编码 CLI、想统一管起来的团队；有 GPU 机器或第二台服务器可作卫星机的场景；需要离开工位也跟得上进度的人；想把"团队怎么组织自己"写成版本化文件的工程负责人。
**不适合**：只有一台机器、只用一家厂商的用户——引入守护进程与多机配置不划算；希望 ccteam 自动排期调度的场景——它明确"从不排期"；以及想靠它统计全部 AI 开销的团队——DSH 原生轮次不进账本。
标签：ccteam、DeepSeek Harness、腾讯云、实战案例、多机编排
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。

上一篇讲了在腾讯云 CVM 上怎么把 ccteam（仓库 firstintent/ccteam，星标 635，综合分 67.8）装起来。这篇换视角：假设你已有一台常年开机的 CVM，怎么用它管一支真正跨机器的编码团队。

用 ccteam 管一支跨机器的编码团队

开发工具

架构设计

运维

用CVM统一管理多机编码团队：控制台主机跑ccteam守护进程，卫星机承载Claude会话并通过令牌注册。Flow脚本实现可追溯、可恢复的自动化任务；IM远程控制支持HITL审批。适合多厂商、多机场景，注意仅ccteam委派轮次计入成本账本。

代码解释

服务器

智能体

路由

Agent

快速部署LLM、AI绘画等应用,助你玩转AIGC！


4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

用 ccteam 管一支跨机器的编码团队-腾讯云开发者社区-腾讯云

用 ccteam 管一支跨机器的编码团队

用 ccteam 管一支跨机器的编码团队

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐