Agent Fleet 管理
运营多个 always-on agent（如 Grok Bot）的结构原则。核心命题：fleet 的成败不在单个 bot 的能力，而在组织结构——和人类团队一样，大多数失败是岗位描述写错，不是员工不行。
原则
- Front door + 委派：人只跟一个入口 bot 说话；它做事前先检查”这个任务是否归别的 bot”，是则委派。人停止在自己工具间做 router。
- 一职一 bot，按软件分工：拆分维度用软件边界（Gmail / ServiceTitan / Slack）而非职能动词（“调度”），端到端全能 bot 被证明又慢又错。
- 人名命名是承诺机制：对”某个谁”的委派比对”email 线程”的委派更持久；不起名的 bot 从不干活。解雇 bot 时归因于岗位描述，然后重写。
- 指令分层：base 层放不想重复的背景，role 层放证据标准（“cite the source URL for every claim”），时机层放节奏。改变输出质量的主要是证据标准。
- Silence is the hack：只在真实命中时 ping，否则四周内必被静音；cadence 由工作性质定（“Always-on is always-spending”）。不确定就不答，攒成列表。
- 人工闸门设在 money/send：所有可信的 setup 都在”花钱或发出”处设一道人闸；规则要窄到可执行（“Be careful with money” 不可执行）。反模式：让销售 bot 群发——bot 没有厌倦和尴尬，会做出被全网识别为 spam 的量。
- Solo 优先，慎用无监督 crew：唯一公开对照实验显示无监督 crew 错误率放大至 solo 的 17 倍；每 bot 独立跑、一职一产出，错误落在桌面而不是感染三个同事。
- Counting test：定期数”拥有可见产出的 bot 数”而非 bot 总数。实验不可怕，把实验当员工才可怕。
- 文件是 memory bus：bot 间不共享对话，共享文件系统——协作靠约定文件位置，不靠 prompt 期待。
- bot 群不是安全边界：权限按”登录了什么”划分，不按”在哪个聊天窗口”划分；第一周 read-only，凭据后给。
让 fleet 自己变好：自改进回路
Warp 的规模化经验（详见 自改进 Agent 回路）：每个 agent（spec / review / triage）各带一条”反馈 → improver → 最小 PR → 人审合并”的回路；回路的组织问题同样是中间路线——模板化基础回路 + 领域权重叠加，几个 agent 各配一个 improver，一百个应共享。两条与上表同源的原则：反馈假定会错（sanity-check + 过滤谁算数 + 人工闸门设在过滤或终审，对应第 6 条 money/send 闸门）；用全局指标判斘系统是否在变好（time to merge / 贡献者数 / 成本，对应 counting test）。
与记忆系统的对偶
bot fleet 的记忆问题与 Agentic Memory 同构：跨 bot 上下文不互通 ↔ 跨会话知识不互通；解法也都是外部化（文件/claims）+ 显式 handoff。人类组织早就有这个词：documentation。
来源：Matt Van Horn - Every Grok Bot Hack I Know、Warp - Self-Improving Agents on Claude