同时用几个 AI 做事，很容易遇到一个问题：它们各自都能干活，连接它们的人却一直是自己。
把需求复制给写代码的 Agent，再把结果交给另一个 Agent 审查；这边缺资料，过去补一下；那边卡住了，再回来问一句。窗口开得越来越多，自己也越来越像一个负责转发消息的项目经理。
最近，我在尝试用 Dot + Lody 接过这部分工作。核心做法很直接：在 Dot 自己的云端执行环境中安装并使用 Lody CLI，让 Dot 能联系已有机器上的 Agent、派发任务、查看进展，再把结果带回来。
这篇文章聊聊我为什么这样搭配，以及接通工具之后，怎样让几个 Agent 真正接得上彼此的工作。
Dot 管目标，Lody 连接执行
我给这两个工具的分工是：Dot 负责和我沟通，记住正在推进的目标，协调各个项目；Lody 提供访问机器、选择 Agent 和操作会话的入口。
Dot 有自己的云电脑，可以持续处理任务，也能向 Work 或 Codex 委派工作。Lody CLI 则提供了查询工作区和机器、创建会话、继续对话、查看状态与历史等命令。把 CLI 放进 Dot 的工具箱，Dot 就有了一条联系这些执行者的路线。
例如，一个项目的代码和开发环境已经在本地机器上，Dot 可以通过 Lody 把任务交到那个环境中的 Agent。需要复核时，再由具备条件的会话接手检查。任务可以留在适合它的地方完成，我主要和 Dot 讨论目标、进展以及需要取舍的问题。
遇到需要独立云端开发环境的工作，Dot 也可以创建 Codex Cloud 任务。这是另一条可选路线。Dot 自己的云电脑和 Codex 云任务分别准备工具与身份，某一端的安装和登录不会自然传到另一端。
我先把执行位置分清楚
让 Dot 使用 Lody，需要分别准备两端：Dot 的执行环境里有可用的 CLI 和登录身份，承担工作的机器上有已配置好的 Agent。前者负责发出指令、查看会话，后者在自己的环境中完成工作。
具体安装与登录跟随 Lody 快速开始。给 Dot 的第一项工作可以很简单：检查现有安装和登录，只读查看指定工作区里的机器、Agent 和会话。能找到正确的目标，再交一项输入清楚、结果容易核对的任务。凭证放在环境支持的安全配置中，不写进任务描述。
环境重载后的检查也适合整理成一段简短指引：先看 CLI、登录和原会话是否可用，只补缺失部分，并沿保存的任务引用继续。这样接续工作时，才知道哪些已经做过，哪些还需要处理。
一个项目有人负责，协作才不会全堆在 Dot 身上
接通工具之后，所有细节都交给 Dot 盯着也不合适。多个项目一起推进时，它既要和我沟通，又要处理每个执行者的具体问题，很容易重新变成一个繁忙的消息转发站。
所以，我把分工再往下放一层：Dot 沟通各项目负责人，项目负责人组织本项目的执行、复核和验收。
以一个功能修改为例：负责人先弄清预期行为和验收方式，再判断能否拆开。接口尚未确定，就先把接口讨论清楚；输入稳定、工作互不冲突的部分，再交给不同 Agent 并行。执行者提交变更和自检结果，复核者检查，负责人确认交付后向 Dot 回报。
小改动不用走成一场会议。负责人可以自己处理，在同一轮里交代做了什么、检查了什么。只有需要交接、并行或后续恢复时，才把分工展开。
角色库和协作规则也因此要分开：代码、设计、研究等角色描述专业能力；项目负责人、执行者、复核者描述本次工作中的责任。同一个 Agent 可以做不同的事，但每次都得知道结果交给谁。
大家看同一份进度，比多开几个会话更有用
跨会话协作最容易丢的，往往是最新进展。执行者在自己的对话里说完成了，负责人看到的还是上一版，Dot 又拿着另一份摘要。
我把统一记录入口选在 GitHub Projects：看板用来了解当前有哪些任务、谁在做、卡在哪里、下一步是什么；详细要求和关键进展放在关联任务里，代码、文件和复核报告通过链接展开。
我给这套协作约定的做法是：各角色开始工作、跟进和交接时，都先从同一个正式入口了解现状。 聊天里产生的新决定和新结果，再回到对应任务中。这样接手的人可以沿着记录找到上下文，不用翻完几个人的聊天历史。
这也是我正在继续补齐的一环：看板创建好之后，还要接上任务、执行会话和结果回执。对已经运行的任务，补齐关联即可；不用为了换工具再做一遍。
在此基础上，我又单独定义了流程审计职责，检查有没有任务漏记、状态与证据是否对得上、遗留问题有没有人接手。它和检查代码或音频质量的复核者分工不同，也不替项目负责人验收。审计只看已有看板还不够，得拿派发和执行记录回来对照，才能发现那些压根没入板的任务。
一次小测试，让我重新看待“完成”
在一次云控制端通过 Lody 协作远端 Agent 的测试里，任务要求读取资料并生成一个小文件。第一次回合返回了 completed，实际回复却是 DOWNLOAD_FAILED：资料没有下载下来，文件也没有生成。
如果只看状态，这项工作已经结束；看过回复才知道，目标根本还没完成。
后续我们沿原会话补交资料，明确发起新回合，再核对回传的文件内容。这个过程让我更在意结果里有没有说清楚三件事：做了什么，交付在哪里，还有什么没检查。
代码测试通过，就报告测试通过；产物经过实际复核，再报告对应的检查结果。像音频这类文件，可以由具备条件的会话在产物所在机器上检查，把报告交给负责人，不必都搬到 Dot 那一端。
请求超时也是类似的道理。没收到回复时，先沿原会话和任务引用查看，弄清事情做到哪里，再决定下一步。直接再派一遍，反而可能让两个执行者同时做同一件事。
上面的案例验证的是云控制端与远端 Agent 的交接，并非一次由 Dot 全程发起的测试。这套协作方式是随着不同环节的实践逐步补齐的；记录好每一步，后面的接入和调整才有依据。
我希望最终形成的日常工作方式是：我和 Dot 讨论目标与取舍，项目负责人安排工作，执行者交付可以检查的成果。需要了解进展时，打开共同的任务入口，就能顺着记录找到正在做的事，以及下一步该找谁。
具体实现移步这里。