用了一段时间 Grok Bot，我越来越觉得，它适合成为人与一群 Agent 打交道的入口。事情交出去以后，我还能继续说下一件事，补充前面的要求，或者纠正它对我的理解。几件工作可以各自往前走，对话也能接着进行。
这种顺畅，比单次回答快一点更影响日常使用。一个入口如果经常被手头的任务占住，人就得等它做完，再来交代新的事情。工作一多，人又会回到逐个打开项目、逐个追问进展的方式。Grok Bot 让我看到另一种组织工作的可能：对话留在面前，执行交到下面。
这里的主 Bot，指直接与人交谈的入口；子 Bot 负责接下某类工作并继续跟进；项目 Agent 则在具体项目里做事。我没有 Grok Bot 官方内部架构的完整材料，下面这套分工，是我根据使用体验和自己组织 Bot 的实践形成的理解。
入口要留出理解人的空间
我在之前的使用记录里，写过 Grok Bot 记规则和偏好很快，也写过它能在同一个会话里跟进几件任务。这两种感受放在一起，才比较接近我说的高效。
主 Bot 不被一项具体工作长期占住，人就可以不断把需求加进来。它接住一句话，弄清楚想做什么，把执行交出去，仍然留在对话里。正在修改的文章可以继续改，另一个需求也可以开始安排。主界面因此能够同时承接沟通和进展，不必跟着某项工作的执行过程一直等下去。
这也给主 Bot 留出了更值得花时间的事情：理解我怎样提要求，哪些偏好会反复出现，什么地方需要和我对齐，以及我遇到取舍时通常怎样决定。一次纠正如果只改了当前任务，下次还得再解释；如果它能把这次纠正理解清楚，之后的合作就有了积累。
这些学习发生在来回沟通里。我补充一句话、否定一个做法，或者决定先做哪件事，都可能帮助它更准确地理解下一次要求。主 Bot 保持可交流，才有机会持续学习这些东西。至于改文件、检查结果、等待某项工作完成，可以由子 Bot 接着跟进。
图 1：人向主 Bot 提出需求，主 Bot 将工作交给子 Bot，子 Bot 分别联系各项目的 Agent。项目 A—D 为示意。
从使用者的角度看，这样的分工让交流连续起来。一项任务在执行时，我可以继续提出另一项要求；需要修改原来的方向，也有一个一直能接话的对象。具体能并行多少工作，仍然受执行资源和任务之间的依赖限制，但入口不必被其中一件事占满。
项目多了，就需要有人替人跟进
我原来习惯以项目为单位使用 Agent。一个项目有自己的文件、讨论和未完成的工作，围绕它继续开会话，很自然。项目 Agent 熟悉本项目的事情，接着做也方便。
难处出在项目多了以后。几十个、上百个项目各有会话，人要记得哪件事交给了谁，上次说到哪里，哪里还等着自己回答。单个 Agent 可以很好用，所有项目放在一起，却仍然需要人挨个联系。这很像一个管理者直接管公司里所有一线员工，安排工作、了解进度、处理问题都经过他。
上一篇《我在 Grok Bot 里面构建了一个公司组织实战案例》记录的，就是我对这个问题的调整。我把直接打交道的对象收拢到几个按工作分工的 Bot，由它们再去联系项目 Agent。“家里 Agent 管家”“日程管理大王”“InfiniSynapse BP”等名字，对应的是我平时会想到的一类事情。
图 2：旧文素材中的 Bot 列表，显示首席汇报官，以及家里 Agent 管家、健康、日程管理大王等入口。
这一层的职责很具体。子 Bot 接到需求，找到有关项目，把要求交给项目 Agent，再跟进进展。需要人决定的事情带回来，结果完成后也带回来。项目里的文件和实际操作，仍然由项目 Agent 处理。
在这套组织方式里，一个项目对应一个 Agent。项目里可以有多次讨论、多个会话，但对于上面的管理层来说，它有一个明确的工作对象。子 Bot 可以联系多个项目，人也可以通过同一个入口继续了解这些工作的情况。中间层把各个项目组织起来，人就不必承担每一次传话和追问。
图 3：旧文的三层组织图，顶层为 WilliamZhu 与首席汇报官，中间为领域 Bot，底层为项目 Agent。
旧图把我和首席汇报官放在同一顶层，讲的是当时怎样组织各类工作。这篇文章进一步关心直接与人交谈的主 Bot：它理解需求，子 Bot 承担中间的管理，项目 Agent 完成具体工作。对话入口与下面的分工接起来，就形成了从人到项目的层级管理。
知识丰富，仍然需要分配窗口和注意力
为什么一定要把工作分出去？大模型已经知道很多事情，继续扩大窗口，是否就能把所有项目都放进一个对话？
模型知道多少，与它这一次能读进多少、同时处理多少，是两回事。上下文窗口，就是当前一次工作能带进来的材料范围。项目文件、历史讨论、正在修改的内容和新要求，都要占用这个范围。窗口可以变大，眼前需要处理的材料也会随着项目增加而增长。
注意力还有另一层限制。材料进入窗口，不等于每个细节都会被同样稳妥地处理。某个项目刚改过的要求、另一个项目尚未确认的问题，以及人刚刚补充的偏好，可能同时影响下一步。模型需要从这些内容里找到当前真正有关的部分。
这里说的注意力，既包括模型处理上下文的注意力机制，也包括使用中表现出来的关注与取舍能力。我不把它当作一个可以随意标出数值的容量。要说明的是：即使模型知识丰富，也不能因此假定它拥有无限的窗口和无限的注意力。
图 4：上方为可按需取用的知识资料；左侧把多项工作放在一个有限窗口中，右侧分别画出主 Bot、子 Bot 和项目 Agent 的窗口及当前关注内容。数量和大小均为示意。
分层的用处，是让每一层围绕自己的问题使用窗口和注意力。主 Bot 关注人的目标、偏好和需要决定的事情；子 Bot 关注所负责工作的安排、进展和依赖；项目 Agent 关注具体文件、操作和检查。项目中的细节留在项目里，需要上层判断的内容再带上来。
这样，窗口压力和注意力压力就分散到不同的工作单元。它们各自有边界，也各自能把相关材料放在一起处理。分工后的沟通当然有成本：要求可能传偏，结果也可能被概括得不够准确，所以层与层之间还要把必要的信息交代清楚。
我在旧文里记录过一次这样的偏差：中间的 Bot 转达发布要求时，自行加上了“一字不改”，改变了原来的执行方式。后来我纠正它，没有说过的约束不要替我补。这件事说明，中间层需要学习我的决定，同时把要求准确地传下去。多设几个 Bot 本身，并不会自动让合作变好。
人的协作也有类似的原因。一个人能学很多东西，仍然不能同时掌握所有项目的细节，也不能把注意力一直分给每一项工作。分工让人把有限的学习精力和注意力放在相应的职责里。模型的知识储备可以远比个人丰富，到了持续处理多项工作的场景，窗口和注意力仍然需要这样安排。
所以我会保留必要的层级，也会按实际工作调整它。哪类事情值得有人持续跟进，就交给一个子 Bot；项目 Agent 继续守着自己的项目。层级是否有用，要看它有没有减少人的注意力负担，有没有让该做的工作接着往前走。
Grok Bot 是新时代的 AI 交互入口，我看重的就是这套关系：人在一个持续可交流的地方提出要求，主 Bot 逐渐理解人，子 Bot 把事情管起来，项目 Agent 把事情做下去。分层分工，让有限的窗口和注意力能够承担更多工作。
本文接着《我在 Grok Bot 里面构建了一个公司组织实战案例》和《我给 Grok Bot 配了一套工具：通讯、文件存储与健康管理》的使用记录讨论，也参考了已有的 Grok Bot 多任务、偏好学习与分层经验帖。
旧图来源（以下为仓库内路径）：
- 图 2 来自《我在 Grok Bot 里面构建了一个公司组织实战案例》的原始素材
writing-studio/auto-coder/grok-bot-project-delegation/images/source/reference/bot-list.jpg，复制为本文的images/existing-bot-list.jpg。 - 图 3 来自同篇文章的
writing-studio/auto-coder/grok-bot-project-delegation/images/01-from-projects-to-domains.png，复制为本文的images/existing-three-level-organization.png。
图 1、图 4 为本文补绘的分工示意图，不是产品界面或官方内部架构图；可复现的 Three.js 场景与导出脚本保存在同目录的 scene/，图片记录见 scene-manifest.json。