个人智能体多 Bot 分工实践指南：从总控到职能 Bot 的完整编制方案

一、背景：为什么需要“多 Bot 分工”

过去两个月，笔者持续使用一类个人智能体产品（personal agent）处理日常工作。这类工具的核心特征并不复杂：它以对话气泡为基本交互单元，允许用户创建多个相互独立的 Bot，每个 Bot 拥有自己的职责范围、存储路径与自动化规则；同时它可以打通本地电脑，通过远程方式执行本地事务，或登录云端主机上的账号，以定时/定期任务的方式完成重复性工作。

用下来的核心结论是：单个 Bot 什么都能做，等于什么都做不好；多 Bot 分工 + 一个总控，才是可持续的用法。

但分工不是随便建几个 Bot 就完事。如果没有统一的规则管理、清晰的职责边界和轻量的反馈机制，Bot 数量一多，反而会变成一堆互相不知道对方存在的“孤岛”。本文把这套编制方案完整拆开讲，包括总控 Bot 的职责、职能分组的划分逻辑、跨 Bot 规则同步的实现思路，以及一个很实用但容易被忽略的技巧——用消息表情做快捷反馈闭环。

需要提前说明边界：这类工具不适合流程长、逻辑复杂、需要反复回看与评审的任务。它的对话形态类似即时通讯，一问一答若干气泡，项目一旦拉长，无论查它发的内容还是查自己发的内容都很费劲。因此像编码这类需要长上下文、需要反复 diff 与来回评审的工作，不应交给它，而应交给具备长上下文能力的智能编程工具或专门的代码智能体；个人智能体只负责派活与串联。反过来，收集类、整理类、规则明确的日常杂事，它处理得相当好。

二、总体架构：总控 Bot + 职能分组

整体编制采用两层结构：

总控 Bot（主管）
├── 收藏组
│   ├── 收藏 Bot（等待决定队列）
│   └── 归档 Bot（已决定内容落库）
├── 学习组
│   ├── 资料采集 Bot
│   └── 摘要整理 Bot
├── 本地事务组
│   ├── 本地文件操作 Bot
│   └── 定时任务 Bot（云端主机）
└── 规则与配置（由总控统一维护，向各分 Bot 下发）

2.1 总控 Bot 的职责

总控 Bot 相当于“主管”，一切随手事务先交给它，由它分配。具体承担四类工作：

1. 随手事务处理：不需要专门 Bot 的一次性小任务，直接由总控完成，避免 Bot 数量膨胀。
2. 对分 Bot 发号施令：把任务转派给对应职能 Bot，并在必要时汇总结果。
3. 本地电脑相关操作：通过本地连接通道执行文件读取、目录整理、脚本调用等操作。
4. 统一管理分 Bot 规则：这是最关键的一条。所有收藏类 Bot 的存储路径、命名规范、状态字段，只需要告诉总控一次，由它同步修改全部分 Bot 的设置。

第 4 点值得展开。多 Bot 系统最容易腐化的地方就是“配置漂移”：今天给收藏 Bot 定了路径 A，明天新建一个归档 Bot 随手写了路径 B，一周后你自己都记不清哪个 Bot 把文件写到了哪里。把规则的写权限收敛到总控一个入口，分 Bot 只读不写，是成本最低的治理手段。可以用一段伪配置表达这种“单一事实来源”的思路：

# 由总控 Bot 维护的全局规则（示意）
storage:
  collection_root: "/data/agent/collections"
  archive_root: "/data/agent/archive"
  naming: "{date}-{source}-{topic}"
states:
  collection: ["pending_decision", "decided", "archived"]
sync:
  targets: ["collector-bot", "archiver-bot", "study-bot"]
  mode: "push_on_change"   # 总控变更后主动下发

分 Bot 侧只保留引用，不保留副本：

# 分 Bot 侧配置（示意）
inherit_rules_from: "master-bot"
role: "collector"

这样任何路径调整都是单点修改、全局生效，不会出现“改了三个 Bot 漏了第四个”的情况。

2.2 分组划分的原则

分组不应按“工具类型”划分，而应按你自己的任务节奏划分。笔者的划分是：收藏、学习、本地事务三组。判断标准很简单——问自己三个问题：

• 这类任务是否高频且碎片化？（是 → 归入收藏组）
• 是否需要沉淀为可检索的知识？（是 → 归入学习组）
• 是否需要触达本地文件系统或云端主机？（是 → 归入本地事务组）

一个任务只归一个组，跨组流转由总控负责串联，避免职责重叠。

三、快捷反馈闭环：用消息表情做状态标记

这是笔者认为最值得分享的一个技巧，成本极低但收益明显。

这类工具的对话是气泡形态。当 Bot 一次回复内容较多、你来不及细看时，不需要打字回复，长按任意一条回复气泡，选择一个表情作为快捷反馈即可。关键在于：你需要事先告诉总控 Bot，每个表情代表什么处理语义，由它把后续动作编排好。

笔者目前只定义了两个表情，保持极简：

表情	语义	后续动作
👍	稍后处理	转发至收藏 Bot，状态置为 pending_decision
✅	已确认，可归档	转发至归档 Bot，状态置为 archived

以 👍 为例，完整链路是：你在气泡上点👍 → 总控识别该反馈 → 将该气泡内容（含上下文摘要）写入收藏 Bot → 收藏 Bot 中该条记录状态为“等待决定” → 你在晚间或碎片时间集中查看，逐条决定如何处理（ deep dive、丢弃、转入学习组、转派给编码智能体等）。

这个机制的价值在于把“判断”和“处理”在时间上解耦。看到有价值但当下没空处理的信息，一个表情就完成入队，不打断当前工作；集中处理时，队列里的每一条都带着明确状态，不会混淆“已看过”和“没看过”。

对应的伪代码大致如下，重点在“语义映射”和“状态机”两处：

# 表情反馈处理（示意，非真实接口）
FEEDBACK_MAP = {
    "thumbs_up": {"target": "collector-bot", "state": "pending_decision"},
    "check":     {"target": "archiver-bot",  "state": "archived"},
}
def on_reaction(bubble, reaction):
    rule = FEEDBACK_MAP.get(reaction)
    if not rule:
        return
    payload = {
        "content": bubble.text,
        "context": bubble.context_digest,   # 附上下文摘要，避免脱离语境
        "state": rule["state"],
        "created_at": now(),
    }
    dispatch(rule["target"], payload)

设计上有两个细节要注意：一是必须附带上下文摘要，否则几天后回看一条孤立的气泡，你根本想不起它当时在回答什么；二是状态字段要少而明确，三态（待决定/已决定/已归档）足够，状态一多就没人维护了。

四、能力边界：什么该交给它，什么不该

多 Bot 分工的前提是承认单 Bot 的能力边界。基于两个月的实践，边界可以归纳如下：

适合交给个人智能体的任务：

• 信息收集与去重：按主题抓取、合并、标注来源；
• 结构化整理：把散乱内容整理成表格、清单、目录；
• 规则明确的定时任务：每日固定时间在云端主机上执行登录、检查、汇总等自动化流程；
• 本地文件操作：按规则重命名、移动、归档；
• 任务派发与串联：作为调度层，把活分给其他专用智能体。

不适合的任务：

• 长流程、多阶段、需要反复回看的项目；
• 需要持续评审代码改动的编码工作；
• 需要精确 diff 对比与版本追溯的变更管理。

原因很直接：气泡式对话在长上下文场景下的检索体验很差，向上向下反复滚动既低效又容易丢信息。正确做法是让个人智能体做“调度层”，编码类任务转派给具备长上下文与代码评审能力的智能编程工具或专用代码智能体，它只负责下发任务、接收结论、串联流程。这也是多 Bot 架构真正的价值所在——它不是把所有活都干了，而是把活分对了。

五、落地检查清单

如果你准备照着搭一套，建议按下面顺序推进：

1. 先建总控 Bot，把存储根路径、命名规范、状态字段三件事定下来，写进总控规则；
2. 按任务节奏分组，每组不超过两个 Bot，宁少勿多；
3. 配置规则继承，分 Bot 引用总控规则而非复制，确保单点修改全局生效；
4. 定义表情语义，最多两到三个，配套状态机与上下文摘要；
5. 划清边界，把长流程与编码类任务明确排除在外，写好转派规则；
6. 每周复盘一次队列，清理长期停留在“待决定”状态的条目，防止队列腐化。

多 Bot 分工不是一个“建得越多越强”的游戏，而是一个规则收敛、职责单一、边界清晰的治理问题。把总控做薄、把规则做单点、把反馈做轻量，这套编制就能长期稳定运转。