GPT + dot 数字员工军团怎么搭：ACN、Loop 与 RSI 的实操拆解
YouTube 视频《GPT + dot：搭建数字员工军团｜ACN × Loop × RSI 实操》由灵姐说 AI | Ling Talk AI发布，时长约 23 分钟。视频用一个隐去客户名称和敏感数据的真实项目，演示云端 dot 如何接收目标、拆解任务、调度本地 GPT，并让不同会话承担资料、执行和复核职责。
本文依据字幕和视频章节整理。ACN、Loop、RSI 是视频作者使用的框架名称，文章沿用其定义，不把视频中的演示直接表述成已经被独立验证的通用产品能力。视频还提到本地机器离线导致安装后的实测暂时无法完成，因此文中的“候选能力”“协同协议”和“自我增强”都应理解为需要项目验证的工程方向。
先看整体：一个统筹者，多个工作节点
视频的核心画面是：用户只和云端 dot 这个统筹者对话，dot 再把工作分发给多个本地 GPT 会话。节点可以是不同项目、不同 session 或不同职责的 Agent。资料节点补充上下文，执行或开发节点处理任务，复核节点检查结果，阶段状态回到共同的工作记录中。
这不是简单地“多开几个聊天窗口”。一个可交接的协同网络至少要回答四个问题：
- 当前目标、优先级和验收标准是什么？
- 哪个角色负责执行，哪个角色负责复核？
- 资料、阶段成果和阻塞状态保存在哪里？
- 下一位节点从哪个版本、哪个状态继续？
视频以飞书作为共享资料、任务和结果的示例，但同样的结构也可以落到项目数据库、文档库或团队 IM。工具名称可以变化，共同状态和交接边界不能省略。
一、ACN：用角色、路由和共同记录组织 Agent
ACN 在视频中展开为 Autonomous Collaborative Network。作者将它解释为一种多 Agent 协同机制：纵向有 dot 这样的统筹者，横向有资料、执行、复核等角色节点，节点之间通过路由和共享状态完成协作。
1. 角色节点：先定义职责再创建会话
角色节点不是“一个更聪明的模型”，而是一个有明确输入、输出和责任边界的协作单元。例如：
| 节点 | 主要职责 | 交付物 |
|---|---|---|
| 统筹节点 | 接目标、拆任务、排优先级、跟进阻塞 | 任务分派、状态汇总、下一步 |
| 资料节点 | 查找、整理和返回指定版本的背景资料 | 资料链接、摘要、来源和版本 |
| 执行节点 | 编写内容、代码或工具步骤 | 阶段成果、变更说明、待解决问题 |
| 复核节点 | 按目标和标准检查成果 | 问题清单、证据、通过或返工结论 |
同一个模型可以承担不同节点，但职责仍要写清楚。否则所谓的“多 Agent”只是多个窗口重复做相同的事。
2. 路由：决定问题应该交给谁
视频中的路由包含两类判断：工作请求交给哪个节点，能力缺口向哪个节点求助。一个实用的请求至少应包含：任务 ID、目标、所需资料、当前状态、期望输出、验收标准和回传位置。
例如执行节点发现缺一份背景资料，不应重新向用户提问并丢失上下文，而应向资料节点发起带版本要求的请求。资料节点返回后，执行节点把新状态写回共同记录，dot 再继续跟进。
3. 共同记录：让交接不依赖聊天记忆
视频反复强调，完整聊天内容不一定自动同步。真正需要同步的是工作资料、任务表、阶段成果、阻塞、求助和版本。共同记录至少可以包含：
任务 ID：
目标与验收标准：
当前负责人：
输入资料及版本：
已完成的阶段成果：
当前阻塞与需要的帮助：
下一步动作：
最后更新时间：
阶段性成果要及时回写，不要等整个任务结束才同步。视频给出的原因很现实：某个节点可能暂时离线，其他节点仍然需要看到最新状态才能完成交接。
4. 心跳与增量反馈
长任务可能因为算力紧张或节点等待而停滞。视频在第一轮协同提示词中加入“心跳”要求，让 dot 定期检查长任务状态，报告已经完成的工作、当前阻塞和需要哪个节点补条件。
心跳不是无意义地重复询问。它应该产生可判断的状态变化：新成果、新错误、新请求、超时或需要人工决定。否则频繁轮询只会增加 token 消耗。
二、Loop：每轮都要说明改变了什么
视频对 Loop 的定义很具体：先提出方案，明确如何判断有效；根据反馈修改；再次检查修改后的结果；再比较问题是否缩小或解决。Loop 可以很小，例如补一份资料，也可以作用于整个协作网络。
每一轮至少记录三件事：
- 改了哪里？
- 依据是什么？
- 检查后问题是否真的缩小？
这样做可以避免“模型说已经优化”成为终点。反馈必须改变下一步，否则只是重复生成。
专家团 Loop
视频还展示了更大范围的专家团 Loop：让不同节点围绕同一版方案提出问题、模拟风险、审计结果并再次修改，直到没有未解决的专家异议。它适合高价值方案和复杂流程，不适合所有简单任务。
专家团的关键不是增加角色数量，而是让每个角色拥有不同的检查视角。例如安全节点检查权限，资料节点检查来源，执行节点检查可操作性，复核节点检查验收标准。每轮输出都应回到同一版方案，而不是各自生成互不相干的长文。
三、RSI：把能力缺口变成候选 Skill
视频把 RSI 描述为一种能力增强方向：Agent 不只接收“完成一项工作”的请求，也可以接收“建立一项能力”的请求。当 dot 发现资料、工具或执行方法不足时，它向本地 GPT 或项目节点请求候选方案，把有效步骤整理成候选 Skill，再经过验证、修订、版本保存和后续复用。
可以把这条链路写成：
发现缺口 → 提出候选方法 → 在受控任务中验证
→ 记录证据和限制 → 修订并版本化 → 后续显式调用
这里的“自我增强”不是让系统未经审核地修改自己的生产权限。候选 Skill 必须有适用范围、输入输出、依赖、失败条件、测试样例和版本记录。视频本身也把 RSI 作为探索方向和协同框架中的补强机制，读者不应把它理解成已经证明的完全自主自我改进系统。
四、从实操项目提炼的落地顺序
视频现场先让 dot 读取原有资料和任务表，再建立协同规则，随后自动出现“资料”“复核”“执行与能力”三个角色节点。节点之间通过 GPT 任务消息通信，dot 继续负责组织和跟进。
如果要在自己的项目中复现这个结构，可以按下面的顺序推进：
- 先写一个真实目标和验收标准，不要从“创建多少 Agent”开始。
- 建立一个共享状态文件或表，冻结任务 ID、版本和交接字段。
- 先创建资料、执行、复核三个最小角色，明确每个角色的输入和输出。
- 写清路由：什么请求发给谁，结果回到哪里，缺资料如何求助。
- 给长任务加增量回报和心跳，但设置合理的检查间隔和超时。
- 用一个小任务跑通一次 Loop，保留修改前后差异和检查证据。
- 只有在重复出现同类缺口时，才把解决步骤整理成候选 Skill。
- 在隔离环境验证候选 Skill，再决定是否版本化和允许后续调用。
五、成本、权限和验证边界
一个 Agent 驱动 N 个 Agent 可以并行工作，但视频也明确提醒 token 消耗会增加。并行度、心跳频率、共享上下文大小和专家团轮数都需要预算。不要只看“能不能跑通”，还要记录单个任务的总 token、等待时间和返工次数。
权限也要按节点拆分。资料节点不应自动拥有部署权限，复核节点不应直接修改生产文件，候选 Skill 不应绕过人工审查获得新的凭据。对外部系统、支付、删除和密钥操作，仍要保留明确的审批边界。
视频中的客户项目画面经过隐私处理，且某次本地安装因为设备离线而未完成实机验证。实践时应把“提示词已经生成”“包说明已检查”“本地环境已安装”“端到端任务已验证”分成四个不同状态，不能用前一项替代后一项。
视频章节
- 0:00 数字员工军团的概念
- 1:03 dot 如何组织工作
- 6:37 真实项目中的协同机制
- 10:13 ACN：自治协同网络
- 15:16 Loop：反馈与持续修正
- 17:51 RSI：能力缺口与候选 Skill
- 19:28 实操：创建多个角色节点
- 22:24 从问答到持续工作
来源：灵姐说 AI | Ling Talk AI，《GPT + dot：搭建数字员工军团｜ACN × Loop × RSI 实操》，YouTube 原视频。