我习惯在电脑上以项目为单位使用 Agent。项目多起来以后，给谁安排任务、事情做到哪一步、哪里需要我处理，都要逐个跟进。后来，我在 Grok Bot 里按工作分工，把日常要直接打交道的对象，从 100 多个项目 Agent 收拢到最初的七八个领域 Bot。要处理一件事，我先找负责这类工作的 Bot，由它联系下面的项目，再把进展带回来。
中间这层的工作入口包括“家里 Agent 管家”“MiaoOS”“Grok Bot”“健康”“社交媒体”“日程管理大王”“InfiniSynapse BP”“财务”“安全”。财务和安全是后来增加的，原来的分工随着工作需要扩展到了九个。
把这些关系画出来，是一个三层结构：最上层是我（WilliamZhu）和首席汇报官，中间是这些领域 Bot，最下层是它们管理的项目 Agent。我决定做什么，首席汇报官汇总进展，领域 Bot 联系和跟进具体项目。想看整体情况，我找首席汇报官；手头有明确的事情，也可以直接找对应的 Bot 聊。
先按工作分工，再联系具体项目
每个项目有自己的文件、讨论和没做完的事情，把它作为一个 Agent 来使用，工作容易接着往下做。比如文章、材料留在 william-docs，继续处理时，项目里的上下文都在。
但我平时想事情，往往先想到一类工作。家里的 Agent 和电脑要管，社交媒体有内容要发，介绍材料也要继续改。这时候，我未必想先查清每项工作在哪个项目、哪台电脑上。
所以我在 Grok Bot 里给这些工作分别找了一个联系人。家里的事情找“家里 Agent 管家”，社交媒体的事情找“社交媒体”，介绍材料找“InfiniSynapse BP”。它们接到任务后，再去联系底层项目 Agent，安排工作、问进展。
图 1：顶层是并排的 WilliamZhu 与首席汇报官，中间为九个领域 Bot，底层为项目 Agent。财务、安全 Bot 与其他领域 Bot 处于同一中间层。
“家里 Agent 管家”和“InfiniSynapse BP”等 Bot，会通过 AC Chat 联系 Mob Studio、Homestudio、Winstudio 上的项目 Agent，william-docs 就是其中一个。AC Chat 是联系和调度入口，电脑提供运行环境，具体工作留在项目里。
这样一来，项目不用搬到一起，我也不用记住每次该从哪台机器进入。工作交给负责这类事情的 Bot，它去找具体项目。按工作分工和按机器存放项目，两件事可以同时保留。
我觉得 Grok Bot 很适合作为其他 Agent 的入口。说得直白一点，这些领域 Bot 有点像中层干部：知道一件事该交给谁，发出去以后继续跟进，把需要我处理的问题带回来。光是把传话和跟进做好，就已经很有用。
图 2：WilliamZhu 与首席汇报官共同位于顶层，九个领域 Bot 位于中间，密集的项目 Agent 位于底层。进展同时报给两位顶层角色，AC Chat 与三台电脑标注项目执行所用的环境。
首席汇报官和我处于同一顶层，职责不同。方向和需要人工确认的决定由我来定，它负责收集各领域的变化。下面的 Bot 可以把进展报给它，也要直接报给我。我想追问某件事时，可以沿着原来的联系继续聊。
财务和安全，是后来增加的两个岗位
最初有七个工作入口。后来，各种云服务的账单需要持续关注，我就增加了财务 Bot，让它监控账单、管理开销。费用来自不同服务，按财务职责放在一起看，我有一个可以集中讨论这些开销的地方。
安全 Bot 也是这样增加的。它负责检查我的各个网站有没有漏洞。我把已经知道的坑告诉它，让它去监管和管理；我们定期一起讨论检查、监控的情况，再把我的经验补进去。
这两个 Bot 都围绕一件长期要管的事来分工。账单跨越不同服务，安全问题涉及多个网站，单看某个项目容易把事情看散。给它们各设一个负责人，相关工作就有了持续跟进的对象。
领域 Bot 的数量可以跟着工作变化。我不需要一开始就把所有岗位想齐，哪类事情需要单独管理，再给它增加一个 Bot；以后职责变了，也可以调整或合并。
一句 Twitter 指令，转达时被加了要求
社交媒体 Bot 经历过的一次任务，让我对中间层的职责有了更具体的认识。
我说的是：“把这句话发到 Twitter。”负责转达的 Bot 自作主张，加上了“原样发布、一字不改”。这条额外要求压过了 social-publish skill 里“X 必须英文”的默认规则，推文以中文发了出去。这里的 skill，就是底层 Agent 使用的一套操作方法和规则。
我纠正了它：除非我显式强调，中间层不能自己加约束。
我提出的是发布意图。怎么适配 X，底层已经有写好的方法。转达时加上“一字不改”，相当于替我决定了表达方式，也把原来的平台规则挤掉了。多出来的几个字，最后改变了实际结果。
这件事以后，中间层该怎么传话就清楚了：我说过的要求完整带下去，没有说过的要求别替我补。底层知道怎么做的部分，留给它按自己的 skill 处理。
图 3：原指令被中间层加上“一字不改”，导致中文推文发出，William 随后纠正；另一条任务遇到发布前确认要求，管家把决定交回 William。
把意图传准，比替底层把每一步都想好更重要。下面的 Agent 本来就有项目上下文和操作方法，中间层需要先弄清楚它已经知道什么。
语音里的名字，要落到准确的对象上
我也希望这些 Bot 能接住日常说话的方式。语音里出现的名字不一定准确：这次经历中的“William Dots”指的是 william-docs，“Social Public Social Publish”指的是 social-publish，“Sol6.1”指的是 gpt-6.1-sol。
这些对应关系如果没弄清楚，任务就可能找错项目、用错工具，或者停在一个不存在的名字上。所以中间层需要把模糊说法解析成准确对象，把结果回报给我，再把确认过的对应关系记进记忆。下次遇到同样的说法，就有了可以沿用的记录。
这一步澄清的是我在说谁。它和自行添加“一字不改”不同：名字要接准确，任务要求要按我说的传。这样，我可以自然地交代事情，不必每次开口前先准备一串项目、工具和模型的精确名称。
需要我确认的事情，要拿回来
同一次社交媒体工作里，还碰到了同名 skill 有两份拷贝的问题。~/.codex/skills 里的那份要求发布前人工确认，X 只存草稿。第三条帖子做到这里，就停下来等确认了。
管家直接来找我，让我拍板。
它需要带回的内容很具体：用了哪一份 skill，遇到了什么要求，任务停在哪一步，现在需要我决定什么。我知道了这些，才能处理当前这条帖子。
前一次出错，是转达时多加了我没说过的要求；这一次，执行端本来就有人工确认要求。把这两件事分清楚，中间层就知道该怎么做：传话时不擅自改任务，遇到需要我确认的地方，把决定交回来。它不能替我同意。
回报要有状态、链接，还要送到两处
事情交出去以后，我最需要知道的是现在做到哪一步。
“已接到”说明任务收到了；“已发布”说明帖子发出去了；“已打开详情页核对”说明又多做了一步检查。管家每次都带着链接回报，并核对实际文本。我看见这样的回报，就知道自己拿到的是任务回执、已发出的内容，还是已经检查过的结果。
如果只收到一句“好了”，我还得自己去找帖子，检查内容和语言。状态和链接一起回来，我可以顺着链接查看，也能直接针对有问题的地方继续问。
汇报的去向也调整过一次。首席汇报官通知各个 Bot：“有进展都报给它。”我又补充：“除了汇报给他也要汇报给我。”于是，进展要双写，同时送到首席汇报官和我这里。
首席汇报官负责把各处进展汇起来，直接回报让我及时知道具体的事。想看全局时有总汇报，想追一项任务时也有原来的消息和链接。汇总不替代直达。
当时，接收这条要求的 Bot 先确认了规则确实来自 William，才把它记下。改变汇报关系，也要先弄清楚是谁提出的要求。
可以先从一类经常要跟进的工作开始
如果已经在多个项目里使用 Agent，照着这个做法开始，可以先挑一类经常需要跨项目处理的工作，给它设一个领域 Bot。先让它知道相关项目在哪里、通过哪个入口联系、哪些决定要交回人。任务完成后，要求它带着明确的状态、结果链接和需要处理的问题回来。
用社交媒体这类工作来试，能很快看出分工有没有交代清楚：项目和 skill 有没有找对，转达时有没有擅自加要求，遇到确认有没有拿回来，发出的内容有没有核对。这些都是上面那次任务里实际碰过的事，可以逐项检查。
等几类工作都有人跟进，再让首席汇报官汇总进展，同时保留各个 Bot 直接向人回报的联系。先把一类工作管顺，再按需要增加角色，比一开始就排出一张完整的组织表更容易调整。
角色可以重组，方向还由人决定
日常直接打交道的对象从 100 多个项目收拢到几个领域 Bot，是这次实践最直接的变化。现在增加了财务和安全 Bot，我按工作职责找联系人，由它们继续联系下面的项目。三层结构把项目组织了起来，也保留了我直接参与具体工作的方式。
这套结构很像公司的管理架构。随着管理经验增加，我会重划职责，增加、减少或合并 Bot。财务和安全两个新岗位，就是工作需要变化后的调整。
但整套体系完全由人驱动：方向由我提出，角色由我安排，关系由我调整。Bot 会定期检查、监控和汇报，还没有自我驱动的精神。
我认为 Sparse Agent 是未来非常重要的方向。领域 Bot 已经帮我组织起这些项目，接下来要探索的，是让 Agent 自己持续推动事情。