不在电脑前也能管好多 AI 编程任务：用 Fleet 把 Claude Code 与 Codex 放进 Telegram 话题
AI 编程 Agent 的价值不只在于一次生成代码，也在于它们能够持续完成任务、提出问题、回传结果。问题是，当一个项目里同时跑着 Claude Code 和 Codex，开发者往往得守在电脑前，在多个终端、会话和通知之间切换。临时离开工位后，想确认任务是否卡住、补一句约束、接收生成的文件，通常又会变成一次远程桌面操作。
Fleet 提供了一个很小但实际的替代路径：它把本机运行的 Claude Code 或 Codex 映射到一个 Telegram 超级群的不同话题。每个 Agent 对应一个话题；手机里的文本或语音消息被送回本机 Agent，代码、文件、截图、进度和追问则回到相应话题。它不是云端 Agent 托管服务：runner、配置和队列都在自己的机器上，Telegram 只是消息通道。
这类结构适合的不是“手机上写代码”，而是处理执行中的开发任务。例如，桌面上让一个 Agent 排查 CI，另一个 Agent 整理重构方案；离开工位时，你只需在各自话题里问进度、补充限制或要求停止。回到电脑后，终端仍是实际工作界面，而群聊是低摩擦的异步控制面。
先理解边界：聊天入口不是执行环境
Fleet 的关键设计是把“远程可达性”和“代码执行权”分开。Telegram Bot API 通过 long polling 与本机 runner 通信，因此不要求部署公网 webhook，也不需要为本机开放入站端口。README 明确说明，bot token 和 API 密钥存放在 ~/.fleet/config.json，状态、日志和投递队列位于 ~/.fleet/。
这带来两个直接结果。
第一，Telegram 账号和群管理权限成了控制边界。首次关联时，/link 会把 runner 绑定到指定 Telegram 用户和群组；bot 需要被设为管理员，群组还必须启用 Topics。不要把它当成“任何群成员都能调用本机 Shell”的机器人：部署前应确认群成员、管理员权限和 bot token 的保管方式。
第二，设备仍需要保持能运行 Agent。Fleet 不会替你提供计算资源；它只是将本机终端会话的输入输出桥接出去。笔记本休眠、Node.js 不可用、Claude Code 未登录，都会直接影响远程协作。官方提供的 fleet doctor 因而应成为安装和升级后的首个检查点。
最小可复现流程
当前 npm 包为 @sand0vvv/fleet，包元数据要求 Node.js 18 或更高版本。官方 README 的最小启动顺序如下：
npm i -g @sand0vvv/fleet fleet init fleet doctor fleet start
fleet init 以交互方式收集 bot token、语音转写提供方和默认设置；fleet start 启动本地 runner。随后在已启用 Topics 的 Telegram 超级群中发送 /link，将这个 runner 关联到自己与该群。
接下来在群组的 General 话题里创建一个项目 Agent：
/spawn /absolute/path/to/your-project
官方命令格式还支持在路径后指定 codex 与模型参数。创建成功后，Fleet 为项目建立独立话题和本地终端窗口。若在机器本地已经进入项目目录，也可使用 fleet claude 或 fleet codex 启动对应 Agent。这里建议先从一个非生产仓库开始，验证 bot、路径、终端和权限链路后，再把它纳入日常开发流程。
为什么“一个 Agent 一个话题”比统一群聊更可靠
多 Agent 协作最容易失去的是上下文归属：一句“继续”到底是给谁的？一份补丁来自哪个仓库？Fleet 用话题作为路由单元，避免把所有输出塞进同一个滚动窗口。README 中列出的 /list、/status 、/sessions 与 /use 负责查看 Agent、状态及会话；/new 则安排下一次重启使用新会话。
对于有状态的任务，这一点尤其重要。README 描述称：关闭 Claude 的终端窗口会让 Agent park，下一条消息到来后会继续既有会话；Codex 也会恢复其上一会话。它还说明，发往离线或 parked Agent 的消息会落盘排队，runner 侧的回复与文件也有按序重试机制。它们减少的是网络波动和临时离开造成的消息丢失，不等于替代 Git、PR、CI 或代码审查。
实践中可以把话题分成三类：一个话题只跑一个仓库或子任务；General 话题只做创建、列表和用量查看；涉及发布、删除、密钥或线上变更时，仍要求 Agent 在话题中回传计划与证据，并在本机或正式审批系统里完成最终确认。不要为了“随时可控”而把高风险操作变成一句不经审查的聊天指令。
给远程任务补一层可验证的交接
要让这种协作在第二天仍然可追踪，建议把每个话题的首条任务写成一份很短的交接契约：目标是什么、允许改哪些目录、禁止触碰什么、完成时要回传哪些证据。对代码修改，可以要求回传变更文件列表、实际执行过的测试命令与结果；对排障任务，可以要求先给出假设和观察到的日志，再提出下一步操作。这样即使手机上只看到摘要，也能判断 Agent 是在推进、等待输入，还是偏离了任务边界。若任务包含多个阶段，还可以在话题开头固定一个简洁状态格式，例如“计划 / 当前动作 / 阻塞项 / 已验证结果”。这不是 Fleet 的强制协议，却能避免把自然语言聊天误当作任务看板：接手者能快速区分已经执行的事实、等待确认的提议，以及尚未验证的推测。
不要把 Telegram 消息本身当作唯一记录。关键结论仍应写回 issue、PR、提交说明或项目文档；涉及配置的决定最好落到版本控制的文件中。Fleet 的磁盘队列解决的是投递可靠性，不能替代团队对“为什么这样改、谁批准、怎样回滚”的工程记录。把两者组合起来，远程控制才不会演变为难以复盘的聊天历史。
语音、文件与实时会话的取舍
Fleet 支持将 Telegram 语音消息转写为文本，转写提供方在 fleet init 中选择；文件附件会被下载到 Agent 的 .inbox/。这对移动场景很有用，例如把一段复现步骤、截图或日志直接交给正在排查问题的 Agent。
但手机输入也会放大指令歧义。长任务最好在第一条消息里写清目标、不可修改的目录、验证命令和停止条件；后续只补充差异。对于需要持续观察的调试，保留本机终端更合适：Fleet 的话题状态会标出 running、parked 或 stopped/crashed，而终端仍能展示完整的交互与原始输出。
另一个值得提前约定的策略是资源管理。/hide 与 /show 用于关闭或重新打开窗口，/stop、/restart 和 /kill 对应不同强度的终止操作。把“暂停等待反馈”“重启 Agent”“删除记录”混为一谈，会使任务追踪和会话恢复变得不可预测。团队应把这些动作写入自己的协作约定，而不是只依赖命令名猜测结果。
适用场景与不适用场景
Fleet 适合已经本地使用 Claude Code 或 Codex、需要在手机上异步管理多个任务的人：个人维护多个仓库、值班时跟进自动化修复、或在长时间构建期间接收提问和产物。MIT 许可证、npm 安装方式和本地 long polling 使它的部署门槛较低。
它不适合替代集中式权限管理、企业审计平台或隔离执行环境。项目仍是早期软件，README 也提示可能存在粗糙边缘；而且本机 Agent 拥有的文件与凭据权限并不会因消息入口改成 Telegram 而自动缩小。若项目涉及生产密钥、客户数据或破坏性部署，应先限制 Agent 工作目录、分离凭据、使用最小权限 token，并保留现有的审批与审计链路。
把聊天软件当作控制面，而不是当作执行面，才是这种工具最稳妥的用法。Fleet 的价值在于：不改变本机开发栈的前提下，让多个已经在跑的 AI 编程任务拥有一个随身、分话题、可恢复的沟通入口。