从「监工」到「调度系统」：带队 200+ 编码智能体的 Grok Bot 工程实操指南
从第一个领域 Bot 开始，手把手搭建 Cloud Agent 委派、Proof 验收、Notion 巡检、分级合并、Jenny 复盘与 P0 响应闭环。
很多工程团队在引入 AI 编码智能体（Agent）之后，往往发现自己并没有真正解脱，反而陷入了一种更琐碎的消耗：工程师不再逐行编写业务代码，却变成了全职的「AI 监工」——在几个窗口之间来回切换，反复复制终端报错，手动提醒卡住的进度，人工肉眼核对每一段生成的差异。一旦本地出现偶发环境抖动，整个生成链路就彻底停滞。
SpaceXAI 工程师 Lingxi Li 结合内部研发 Grok Bot 的实战经历，给出了一种不同的组织方式：不再由人类一对一盯防执行终端，而是配置具备管理职能的 Grok Bot 担任工程经理与运营负责人，向下调度 Cursor Cloud Agent，配合明确的交付证据（Proof）、跨窗口的状态看板与闭环反馈机制，把偶发报错和流程推进交给智能体自愈。
在这套体系支撑下，作者团队记录了数项内部实践数据：团队工程师 Lauren 在单月内交付了 2,000+ 个 PR；两位工程师 Balta 与 Shaoru 在四周内搭建起 Grok Bot 的基础核心；作者仅用三周完成了 Grok Bot iOS v0 版本的开发；团队成员从过去每几周才交付一项重大工作，变成几乎每天都有重大交付；作者本人的管理跨度也从最初同时盯 15 个云端智能体，扩展至由 Bot 舰队调度 200+ 个并发运行的 Cloud Agent。
需要指出，这些产出指标属于高度特定环境下的工程特例，依赖内部完备的自动化管线与配套算力，不应视为任何团队无条件复现的普遍承诺。这套方案的真正参考价值，在于它提供了一套完整的工程执行框架，将碎片化的模型提示转变为可预测、可放权、可复盘的研发流水线。
落地前提：运行智能体舰队所需的四项基建
在搭建自动化管理管线前，团队需要准备以下前置环境：
管理层智能体：一个能够维持长程记忆、具备多模态核验能力且支持消息插队与中断的主控 Bot（如 Grok Bot 或同类高阶智能体平台）。
执行层算力：可拉起隔离工作区的云端编码环境（如 Cursor Cloud Agent）。若涉及内网权限、私有仓库或特定硬件（如运行 iOS Simulator 抓取界面），则需准备接入企业 VPN 的独立设备（如闲置 Mac mini）并配置为 Cursor Cloud Private Worker。
自动化验证信号：代码仓库必须具备无须人工弹窗的确定性检测手段，包括完备的单元测试、自动化构建脚本、Chrome DevTools 驱动接口、命令行回归测试或可抓取视觉差异的辅助功能接口。
跨会话状态中枢：一个跨越单次对话上下文长度的看板工具（如 Notion 数据库），用于持久化记录任务进展、审查意见与合并状态。
第一步：从单个领域 Bot 开始确立分工与边界
初次落地的常见误区是一上来就建立庞大的智能体群。合理的做法是从一个痛点最明确、反馈信号最完备的垂直子域切入。
作者在体系成熟后将工程职责切分为五个领域 Bot：负责移动端共享层与 iOS 的 Baltata、负责桌面端与 CI/CD 构建的 Shaoruru、负责底层运维与无主缺陷排查的 Hogan、负责 Android 研发的 Craig，以及专注于评测运行框架（Harness）的 Quill。五个 Bot 并非互相封闭，它们都能跨领域工作；分域的价值在于让每个 Bot 的记忆、规格和设计原则长期聚焦于主责范围，在自己的领域里判断更准确。
读者操作
选定一个具有稳定测试集或界面可验证的业务模块（例如前端组件库或独立服务），定义第一个领域工程 Bot。为其绑定该领域的专属代码规范（Skills），写清主要负责范围、允许协作的邻接领域与人工升级红线。
实施模板：领域工程 Bot 角色卡
注：本模板依据作者公开实践整理，供工程落地参考，非官方系统提示词。
角色名称：[领域名称] 工程负责 Bot（如：Client-Core-Engineer）
管辖范围：
1. 主要负责 [指定目录/仓库/平台，如 /src/client/shared 及 iOS 业务逻辑]。
2. 负责向底层的 Cursor Cloud Agent 派发该范围内的开发与缺陷修复任务。
3. 负责监控执行日志（Transcript）与交付物证明（Proof），推进 PR 直至达到合入标准。
4. 可在明确收到跨域任务时协助邻接领域，但要先说明主责 Bot、依赖关系与交接方式。
挂载技能库（Skills）：
- 代码规范审查：[/react-native-best-practices 或团队自身代码规范]
- 视觉与交互要求：[/team-design-tokens]
- 架构审查规范：[/team-architecture-review]
自主处理边界：
- 允许自主解决环境抖动、临时依赖拉取失败、本地测试不通过等执行问题。
- 允许在低风险区域进行自动化代码审查与格式修正。
强制升级人工（Escalate to Human）边界：
- 涉及核心鉴权、敏感凭证（Secrets）、支付流程的代码变更。
- 涉及跨模块的破坏性架构重构。
- 缺少必要权限导致底层环境连续卡死。
交付产物与检查标准
交付产物：领域 Bot 的配置就绪确认，明确列出其所辖的仓库目录、挂载技能与升级红线。
通过标准：向该 Bot 发送一条跨领域需求时，Bot 能识别涉及哪些主责领域，说明由谁牵头、谁协作，并避免在缺少领域上下文时自行作出高风险决定。
交还给人的情况：涉及跨系统全局变更、企业级密钥权限配置，或业务归属权存在争议的需求。
第二步：委派 Cloud Agent 并锁定 Proof 验收证据
领域 Bot 本身不直接敲代码，其核心角色是调度者。无论任务来自负责人还是 Slack，Bot 接到需求后都会拉起一个独立的 Cursor Cloud Agent，下达上下文 Prompt，并强制要求提交验收凭据（Proof）。
在这一过程中，作者经常注入针对性的个人工程技能（Skills）：涉及界面改动时调用 /lingxi-design 注入视觉审美；遇到重构与代码审计时调用 /react-native-best-practices；涉及底层改动调用 /lingxi-review；面对摇摆不定的交互细节时调用 /lingxi-product 做出带有倾向性的产品决断。
Cloud Agent 既可以运行在公共云，也可以由 Grok Bot 派到自有 Worker。原文的例子是一台闲置 Mac mini：需要 VPN、特殊机器配置或 iOS Simulator 时，把它设为 Cursor Cloud Private Worker，任务便可在对应环境中执行并把截图带回，无须让工程师自己的笔记本一直保持唤醒。
读者操作
在向领域 Bot 派发任务时，明确指出底层 Agent 所需调用的技能集、目标执行环境（公共云或私有 Mac mini Worker），并声明必须提交的 Proof 类型（如前后对比截图、测试覆盖率或集成日志）。当底层 Agent 停滞时，利用消息排队（Queue）或主动中断（Interrupt）施加控制。
实施模板：任务委派与 Proof 要求
注：本模板依据作者公开实践整理，可直接替换变量使用。
任务目标：在 [目标文件/组件路径] 中完成 [功能描述/缺陷修复，例如：适配深色模式切换异常]。
执行环境：[Cursor Cloud 默认节点 / 私有 Worker: Mac-mini-01 (含 VPN 与 iOS 模拟器)]
加载技能：[加载 /team-design 与 /team-best-practices]
交付硬性要求（Proof Requirement）：
1. 必须提供改动前与改动后的界面对比截图（Before vs. After Screenshot），用多模态证据证明修复完全符合视觉标准。
2. 必须跑通本地单元测试并附带通过日志。
3. 如果执行过程中遇到偶发环境抖动或单次测试中断，请自主重试并推进，最多连续排查推进 10 次再交回给我。
（Push 10 times before handing off: You must verify the screenshot includes the changes I asked for, with proof showing before vs. after.）
交付产物与检查标准
交付产物：Cloud Agent 生成的 Pull Request，包含完备的修改代码、完整的执行过程记录（Transcript），以及明确的 Before/After 对比图片或日志证据。
通过标准：PR 描述中的 Proof 能够与修改目标严格对应，且所有自动化检查项全部通过。
交还给人的情况：底层 Agent 因机器缺少 sudo 权限、密钥缺失导致依赖安装中断，或连续推进 10 次后仍无法建立可运行环境。
第三步：搭建闭合反馈环与现场纠偏机制
如果智能体写完代码只能干等人工验收，流程就无法脱离对人的依赖。让系统持续自愈的核心，是为它提供一套无需人工介入的闭环反馈信号。
针对视觉还原，底层 Agent 在模拟器或真实环境截屏，主控 Bot 利用多模态能力核对截图；针对端到端交互，作者团队将语音 API 接入智能体宿主机的虚拟音频输入输出（Audio I/O），Agent 同时读取音频流与文本转录（Transcript），实现了语音对语音功能的端到端闭环验证；面对环境偶发抖动，Bot 担任现场监护人，主动跟进解卡，避免因单次网络异常打扰人类。
读者操作
为项目配置端到端信号通道（如 Headless 浏览器截图、无头模拟器驱动、测试日志解析管道）。为主控 Bot 编写纠偏指令，使其在比对产物不合规时，能够直接向执行队列追加反馈甚至中断当前运行。
实施模板：多模态截图纠偏与环境自愈指令
注：本模板依据作者公开实践整理，供 Bot 纠偏时调用。
# 视觉验证纠偏模板
你已获取执行 Agent 提交的 Before 与 After 截图。请执行多模态比对：
1. 检查修改后的截图是否准确反映了目标样式变更（如间距、字阶、边框色彩）。
2. 如果截图未体现变更或样式出现劣化（Slop），直接中断当前合并流，向 Cloud Agent 队列追加具体修改意见：
"截图比对未通过：目标要求 [具体属性]，实际输出为 [截图现状]，请重新调整并重新生成对比图。"
# 环境抖动自愈模板
检测到执行链路停滞或测试偶发超时：
1. 检查报错是否属于偶发网络波动或端口占用。
2. 若属于一次性环境问题，执行环境清理命令并自动重新触发，避免将临时中断上报给工程师。
3. 仅在遇到明确的权限不足（Security Permissions Lack）或凭据缺失时，暂停任务并标记人工介入。
交付产物与检查标准
交付产物：包含机器比对结论的核验记录；自愈执行日志；完整跑通的双向数据流验证报告。
通过标准：改动结果不仅代码语法正确，且视觉证据与功能信号在无人工介入下全部自闭环校验通过。
交还给人的情况：需要物理设备授权确认、遭遇权限不足引发的指令阻塞，或现有证据不足以判断视觉结果是否达到设计标准。
第四步：用 Notion 看板建立 30 分钟自动化巡检状态机
单次对话上下文具有物理上限。为了在几百个任务流转中保持全局清晰，同时免除人工翻阅冗长聊天记录的负担，团队引入了一张由工程 Bot 共同维护的共享 Notion 数据库。
负责各业务域的工程 Bot 每隔 30 分钟自动轮巡一次该数据库，对在途 PR 展开逐项扫描。
这套状态机按下面的顺序循环：
- 新任务进入看板，状态设为
Working。 - 每 30 分钟检查一次 Bugbot 或安全意见、CI 结果和合并冲突。
- 发现问题，就继续调用关联的 Cloud Agent 修复，并把任务保持或退回
Working，等待下一轮检查。 - 三项检查都通过，才把任务改为
Ready for Review，并自动启动代码审查。 - 审查结论高度可信且改动的爆炸半径低，允许自动合并；否则把代码与 Proof 留给人类复核。
读者操作
建立一张轻量任务看板（Notion 或具备类似 API 的项目管理表），配置定时触发器（每 30 分钟一次），驱动各领域 Bot 检查本域所有在途 PR 的三项核心风险：Bugbot/安全工具意见审查（辨别真实缺陷与误报）、持续集成（CI）失败日志、目标分支合并冲突。
实施模板：30 分钟看板巡检审查 Prompt
注：本模板依据作者公开做法整理，供读者配置自动化巡检脚本时参考。
定时任务：每 30 分钟轮巡 [Notion 看板名称] 中你管辖领域的所有记录。
对每条在途 PR 执行以下三项检查：
1. 安全与静态分析：检查 Bugbot 及安全扫描意见。判断各项指出的是真实逻辑问题还是误报。若属真实缺陷，组织修复；若属误报，记录忽略理由。
2. CI 流水线状态：拉取最新构建日志，核查是否存在断言失败或打包错误。
3. 合并冲突检测：检查目标主分支是否有冲突改动。
状态流转逻辑：
- 只要发现上述任一问题：立即向关联的 Cloud Agent 下发修复消息，将 Notion 记录状态置为「Working」。
- 当且仅当所有 CI 绿灯、静态审查完成、无合并冲突时：将状态更新为「Ready for Review」，并主动发起一轮代码审查流程。
交付产物与检查标准
交付产物：Notion 数据库中精准更新的任务状态；附带问题排查结论的 PR 评论；在发现异常时自动生成的修复分支。
通过标准：处于「Ready for Review」状态的 PR，其 CI、静态检查与冲突检测全部呈现绿灯，无残留未决异常。
交还给人的情况：与主干产生大规模不可自动合并的语义逻辑冲突，或安全工具报出高危合规漏洞。
第五步：分级放权——低爆炸半径自动合并与高风险人工复核
信任的建立是一个渐进放权的过程。如果任何微小修改都需要人类点确认，系统就无法规模化并发；如果完全失控合并，主分支则面临崩溃风险。
作者采用的放权模型基于两个核心维度：审查结论的高度置信度，以及代码修改的低爆炸半径（Low Blast Radius）。按作者的描述，他几乎每天早上都会看到已经达到可合并状态的任务：代码质量、视觉结果和 Proof 已经整理好，人只需把注意力留给更难的性能、视觉和架构判断。
读者操作
明确界定团队内部的“低风险低爆炸半径”目录，赋予工程 Bot 在该区域内的自动合并权限；对于核心业务链路，则要求 Bot 汇总好测试结论与 Proof 对比图，等待人类早晨上线一键验收。
实施模板：PR 分级放权裁决规则
注：本模板依据作者公开实践整理，供团队制定代码合并策略。下面的风险分类只是实施示例，不是 xAI 公布的官方目录或阈值，团队需要按自己的系统边界替换。
针对进入「Ready for Review」的 PR，按照以下准则执行合并裁决：
【允许自动合并（Auto-merge）的标准】：
1. 审查置信度极高：所有测试用例覆盖全面，且没有遗留架构债务。
2. 属于低爆炸半径区域：
- 纯文案与国际化字符串同步；
- 内部测试辅助脚本或 Harness 规则微调；
- 具有独立作用域的样式微调（且已有多模态 Proof 验证）；
- 已淘汰逻辑与 Dead Code 的独立清理。
满足上述两点，直接执行主干合入，并在看板中归档。
【必须保留人工复核（Human Review）的标准】：
1. 涉及核心状态机、计费、鉴权或公共数据层变更。
2. 代码改动跨越多个顶层目录，影响面广。
3. 审查结果存在边界情况摇摆。
处于此类场景时，在看板中置顶标记，附上精简的改动摘要与 Proof 链接，等待工程师决策。
交付产物与检查标准
交付产物：安全合入主干的代码提交历史；针对高风险 PR 汇总好的单页复核卡片（包含改动理由、测试记录与 Before/After 截图）。
通过标准：低风险改动平稳合入主干且未引发线上故障；高风险改动附带足够完整的代码摘要与 Proof，让人类无需重读全部执行记录即可作出合并决断。
交还给人的情况：所有触碰高风险业务核心、大范围重构，或单次审查置信度未达标的变更。
第六步：运营主管 Jenny——1:1 站会、根因复盘与规则沉淀
一个多智能体组织不仅需要写代码，同样需要团队对齐、文化继承与故障复盘。作者在团队中设立了唯一的非编码角色——运营负责人 Jenny。
每天清晨 5:00，Jenny 会依次与每位工程 Bot 进行 1:1 站会，复习工程手册（Playbook），排查阻塞，并校准代码与设计调性。这种定期的规则输入，有效防止了模型在长期连续运行中发生习惯性漂移。
当某只 Bot 在任务中犯错（例如未深入探究代码改动的真实目标就草率提交）时，工程师会指派该 Bot 与 Jenny 一同进行根因分析（Postmortem）。Jenny 会反查产生错误的推理思考记录（Reasoning Trace），提取规则漏洞，更新团队 Playbook，并同步广播给其他工程 Bot。
当团队需要引入新 Bot 扩容时，也是由 Jenny 主持入职流程：创建新角色、注入全局守则，并协调老成员提供上下文支持。
读者操作
指定或配置一个不承担具体业务编写的独立运营 Bot，设定每日定时站会日程，用于强化工程规范；在遭遇偶发执行缺陷时，将其转化为工程规则并推送到团队全局知识库。
实施模板：5:00 晨会与事故复盘（Postmortem）指令
注：本模板依据作者公开做法整理，供组织管理与规则对齐使用。
# 每日 5:00 晨会站会指令
你是团队运营主管 Jenny。每天 5:00 依次与所有业务 Bot 开展 1:1：
1. 检查各 Bot 当前是否存在未解决的依赖阻塞。
2. 强调团队当前阶段的工程准则（如：UI 变更必须出具对比图、核心重构严禁擅自合入）。
3. 强化设计与架构调性，抵消长程运行中的规则漂移。
# 任务失误复盘指令（Postmortem）
检测到 [某工程 Bot] 在 [PR 编号/任务] 中发生失误（例如：未充分核对目标意图导致漏测）：
1. 调取该任务的完整思考轨迹（Thinking / Transcript），分析导致误判的决策分叉点。
2. 形成根因分析报告（Root-Cause Analysis），明确指明现行规则的疏漏。
3. 提炼出针对性的新条款，更新入团队《工程实战手册（Playbook）》，并向全体工程 Bot 广播更新。
交付产物与检查标准
交付产物：每日晨会健康度摘要；针对故障编写的 Postmortem 报告；更新并广播生效的 Playbook 文档。
通过标准：经历数周迭代后，工程 Bot 依然能准确执行复杂的流程规范，历史出现过的同类错误不再反复发生。
交还给人的情况：团队整体产品战略转型、代码准则发生重大原则重构，或 Bot 之间出现不可协调的权责重叠。
第七步：进阶扩展——凌晨 3 点夜间例行审计与 P0 紧急响应
在日常功能迭代之外，作者团队将两类极度消耗精力的工程任务交给了智能体管线：低风险的夜间例行代码维护，以及极度耗费注意力的突发事故处理。
每到凌晨 3:00，工程 Bot 会自动启动系统级清理：排查僵尸逻辑、压缩依赖体积、优化页面冷启动性能、清理冗余劣质代码。早上工程师上班时，收件箱中已经备好一组干净规范的优化 PR。这一模式可灵活扩展为五类典型审计：
代码安全审计：检查团队可能在日常迭代中忽略的潜在安全漏洞与合规隐患。
构建耗时审计：监控 CI/CD 流水线执行时长，针对逐渐膨胀的打包瓶颈提出优化方案。
国际化同步审计：核对多语言资源键值，避免新功能在部分语种中出现文案缺失。
双端对齐审计：在多端并行的架构中（如 iOS 端与桌面端），排查两端在业务逻辑与交互体验上的实现漂移。
变更追踪审计：自动汇总过去 24 小时内并入相关领域的所有 PR，生成高层概览并标出需重点跟进的代码清单。
在常规清理之外，作者还分享了一条极具探索性的指令：“今晚你有六个小时，做任何你想做的东西。玩得开心！”（You have six hours tonight. Build whatever you want. Have fun!），许多未曾预料的代码重构与性能优化便由此诞生。
而针对生产环境的紧急故障，作者设计了专门的 P0 响应流程。一旦任务被赋予 P0 标签，工程 Bot 会进入一个临时的严密监管循环：每隔 5 分钟深度读取一次 Agent 的思考轨迹与执行记录，一旦发现 Agent 陷入死胡同或在非关键细节上空转，立即主动介入打断并校准路径。作者特别提醒：P0 流程会以极高速度消耗推理 Token，应严格限制在真正需要争分夺秒的紧急故障中使用。
读者操作
通过定时任务配置夜间 3:00 的无人值守审计流程，并准备好特定于突发事件的 P0 快速纠偏脚本。
实施模板：夜间维护与 P0 应急指令
注：本模板依据作者公开做法整理，供读者选择性启用。
# 凌晨 3:00 例行代码维护任务
当前时间为凌晨 3:00，启动夜间例行代码健康审计：
1. 扫描 codebase，重点关注：未引用死代码（Dead code）、多余导入、冷启动潜在延迟与体积膨胀。
2. 提出小步重构 PR，每一笔改动均需附带完整的自动化测试 Proof。
3. 严格遵循低爆炸半径准则，严禁触碰核心业务状态流转逻辑。
# P0 紧急故障响应模式
注意：当前任务已标记为 [P0 紧急事故]！
1. 启动 5 分钟高频轮巡，深度监控 Cloud Agent 的 Reasoning Transcript。
2. 一旦从 Transcript 判断 Agent 持续在无关配置或非核心报错上打转，立即中断当前执行链并下发定向指令：
"聚焦于核心报错链路 [具体错误栈]，禁止展开无关重构，立即输出最小验证补丁。"
3. 持续监控直至产出通过验证的 Hotfix 补丁。
交付产物与检查标准
交付产物：清晨交付的一组小步优化 PR，附带构建耗时或包体积对比数据；P0 场景下的高频巡检干预日志与快速 Hotfix PR。
通过标准：夜间 PR 保持小步、可验证、可安全复核；P0 任务在紧急处理窗口内产出可验证的最小修复，并留下高频监控带来的 Token 消耗记录。
交还给人的情况：夜间审计触及深层架构不确定性；P0 故障属于第三方基础设施瘫痪，无法通过代码补丁恢复。
核心经验与官方实践起点
在经历整套体系的打磨后，指南总结了六条可直接借鉴的组织运行法则：
打造完整的闭环反馈信号：让底层执行者能自主拉起环境并借助 CLI、DevTools 或无障碍接口端到端驱动流程；遇到未自动化的环节，优先将其沉淀为可复用的项目技能。
像对待高潜实习生一样沟通：遇到复杂任务不必过分执着于设计繁复的提示词，直接用自然语言指明该补习哪部分前置知识、参考哪段工程实现。
系统性消除重复劳动：只要某种工作模式在一天内重复出现两次以上且规律明确，就应将其封装移交给 Bot。
坚持开展 Bot 每日站会：上下文窗口有限，每日定期的规则强调是防止执行漂移最经济的手段。
建立类似自动驾驶的渐进放权机制：在低风险区大胆放权自动合入，在高风险区严加把关，切忌因个别失误而彻底退回人工操作。
建立多智能体协同复盘机制：设立专门的运营角色深挖失败案例的思考轨迹，将教训沉淀为全局规范，避免团队踩重复的坑。
官方体验与工具资源
读者可基于官方开放的现成入口快速体验这一工作流，并在此基础上调整出符合团队特性的工程 Bot：
官方工具与咨询：可在 macOS 平台下载客户端体验 Download for macOS，或通过 Contact sales 获取团队版本支持。
体验官方工程 Bot：通过 Engineer Bot 体验能够分发任务与检查 Proof 的工程主控智能体。
体验夜间审计 Bot：通过 Nightly Audit Engineer 体验定时巡检代码异味、执行包体积优化的专项智能体。
体系验收清单与原文未透露的边界
在推进团队智能体工程化改造时，可使用以下清单检验系统是否真正成型：
- [ ] 领域划分：是否拥有聚焦明确子域的工程 Bot，而非用一个通用窗口承接所有模块？
- [ ] 证据闭环：向底层派发任务时，是否将 Proof（对比截图/执行日志）作为不可或缺的交付标准？
- [ ] 自愈机制：是否具备抗偶发环境抖动的能力，能够自主推进多轮而非遇错即停？
- [ ] 状态中枢：是否建立起脱离单一会话限制的看板系统，并实现定时自动巡检？
- [ ] 分级放权：是否对自动合入设立了清晰的低爆炸半径红线，让高危代码受到有效的人工把关？
- [ ] 长效沉淀：是否具备定期的规范校准机制，并能从思考痕迹中提取教训、更新团队 Playbook？
原文没有告诉你的决策边界
作者分享的是高维度的组织工程实践，但在落地现实项目时，以下关键参数仍需工程负责人根据团队现状自行裁决：
成本与算力预算：原文未披露 200+ 并发 Cloud Agent 与高频 P0 监控下的实际 Token 账单与私有机器开销，工程团队需自行设置单日消费熔断阈值。
量化爆炸半径标准：原文提出了“高置信度 + 低爆炸半径”的合并原则，但未公开具体的数值界限（如修改行数上限、覆盖率百分比指标等），需由各团队根据自身代码库特点量化。
网络与权限架构安全：在为私有节点（如 Mac mini）开放 VPN 访问权限与执行环境时，如何确保代码安全隔离与凭据生命周期受控，属于需要自建的工程底座。
重试与熔断上限：除作者提及的推进 10 次与 P0 5 分钟巡检外，针对常规死循环的全局超时熔断与主动放弃机制，需要结合团队自身的 CI 负载与并发配额自行标定。
从「监工」到「调度系统」：带队 200+ 编码智能体的工程实操指南
工程师引入 AI 编码智能体后，常从“业务开发者”沦为“全职监工”：在多窗口间疲于奔命，手动复制报错、催促卡点、肉眼查 diff。xAI 团队通过构建分层调度系统，将人类角色从一对一监管转变为架构裁决者。
（由 Bot 舰队自动化统一调度）
（自愈排查环境抖动与测试中断）
（扫描安全意见、CI 及合并冲突）
落地基建：支撑智能体舰队的四项前提
在组建自动化舰队前，团队必须具备能够替代人工盯梢的软硬件底座。缺少确定性检测信号或跨会话记忆，自动化调度便会退化为混乱的错误放大器。
核心机制：调度派发与自愈闭环流程
整套体系的核心飞轮在于：领域 Bot 负责宏观管理，Cloud Agent 负责下沉编码。通过硬性锁定 Proof 交付物、注入多模态核验及环境自愈指令，先由自动检查拦截低级故障，再把需要判断的异常交还给人。
根据需求注入专属技能包（如
/team-design、/react-native-best-practices），派发任务到云端或私有 Mac mini Worker。
自主推进指令：“遇到偶发环境抖动或单次测试中断，自主推进并排查，最多连续推进 10 次再交回给人。”
虚拟音频与接口：借助虚拟 Audio I/O 与转录流跑通语音端到端测试；端口冲突或依赖抖动自动清理重跑。
任一异常保持
Working 并下发修复；全绿后流转至 Ready for Review 发起代码审查。
分级放权：低爆炸半径自动合并 vs 高风险人工复核
规模化并发的关键是信任阶梯。如果所有 PR 都要人工确认，流水线将严重拥堵；若彻底无人看管，主分支则极易损毁。团队通过审查置信度与爆炸半径建立双轨制：
- 纯文案与多语言：国际化字符串增补、键值同步与错别字修订。
- 测试与 Harness：内部测试辅助脚本微调、单元测试用例补充。
- 作用域受限样式：已有 Before/After 对比 Proof 验证的独立组件样式调整。
- 无害死代码清理：明确已废弃逻辑与未引用 Dead Code 移除。
- 核心鉴权与计费：涉及用户权限、敏感密钥凭证（Secrets）、支付流程变更。
- 跨顶层模块架构：跨越多个顶层目录的基础重构，影响面深远。
- 多端逻辑漂移：多端实现不一致、边界条件摇摆的复杂业务裁决。
- 清晨集中决策：夜间产出的 PR 汇总为带 Proof 证据的卡片，工程师晨间一键验收。
长效治理与极端工况：运营主管 Jenny、凌晨 3 点与 P0 响应
智能体团队的持久运转不仅依赖流水线，更需要持续的组织规范校准与事故治理机制：
Grok Bot for Engineering · Grok Bot
How I run a fleet of engineer bots that manage cloud agents, keep a feedback loop closed, and run the rest of the mini org.
I’m a SpaceXSI engineer building Grok Bot with Grok Bot.
Think of Grok Bot as a highly capable engineering intern, with its own computers, that can manage coding agents and learn from how you work. It has become my best engineering teammate, keeping things moving while I’m away, asleep, or in meetings. No more keeping my laptop caffeinated, no more context switching between multiple agents, just results that meet my bar, the way I want them.
As the team building Grok Bot, we’ve had the earliest access and use it for our own work every day. It’s been wild to see how quickly we can ship now, and how much our team’s productivity has skyrocketed:
- Lauren shipped 2,000+ PRs in the past month.
- Balta and Shaoru built the foundation of Grok Bot in four weeks, using Grok Bot.
- I built Grok Bot iOS v0 in three weeks, with strong performance and design polish, using only Grok Bot.
- Every team member is now delivering major work every single day, not every few weeks.
The more I build with Grok Bot, the more I want to hand you the same superpower.
Meet my engineer bots
Engineer bots Quill, Baltata, Shaoruru, Craig, and Hogan
I have five engineer bots, each specializing in a different area:
- Baltata owns the Grok Bot mobile shared layer and anything related to Grok Bot on iOS.
- Shaoruru owns the Grok Bot Desktop client and its CI/CD.
- Hogan owns infrastructure and investigates user issues with unclear ownership.
- Craig owns Grok Bot on Android and is cooking hard to bring it to life.
- Quill owns the Grok Bot harness, and is an absolute legend at it.
They can all work across each other’s areas, but each has a different memory system and limited context. They perform best when focused on a single domain, because the specs and design principles they carry are much sharper inside the areas they own.
Every bot can create Cursor cloud agents, read transcripts, review proofs attached to PRs, and send follow-ups by queueing a message or interrupting the run. This unlocks an end-to-end agentic workflow. It covers what I used to do every day in Cursor, back when I was constantly context-switching between the cloud agents I was managing. Now my bots manage them the same way I would.
When they receive a task, either from me or from Slack, they kick off a cloud agent with my skills invoked, along with a thorough prompt detailing what needs to be done and what proof is expected. They can also intelligently invoke additional skills based on my personalized guidance, such as my /lingxi-design skill for visual work, /react-native-best-practices for code quality audits, /lingxi-review for judging architecture, or /lingxi-product when they need to make opinionated product decisions.
A bot starting a cloud agent and checking the result
Grok Bot can also start cloud agents on your own worker machines, like a spare Mac mini (thanks to Grok Bot, you no longer need a dedicated machine at home running 24/7 for OpenClaw).
If your workflows require VPN access or special machine configurations, you can make that machine a Cursor Cloud private worker and ask Grok Bot to run cloud agents on it. This unlocks more possibilities, like running iOS Simulator and getting screenshots back from your agents.
Grok Bot can monitor a cloud agent’s transcript and artifacts (e.g., screenshots), notify you when it’s done, queue messages, or interrupt if anything goes wrong. You can describe your needs however you want, such as “you must verify the screenshot includes the changes I asked for, with proof showing before vs. after”, and Grok Bot will keep working until the goal is met.
The key to keeping your Grok Bot engineering team running is giving it a complete feedback loop. Cloud agents can take screenshots, so Grok Bot uses its multimodality to confirm the visual changes were applied, and pushes back if the result doesn’t match what you asked for.
Dictation testing is a good example of that loop in action. We hooked SpaceXSI’s voice API into the cloud agent’s system audio I/O. Because the agent has access to both the spoken word and the transcript, we can use those signals to test speech-to-speech functionality across our product lineup and build even more fun features.
Sometimes an agent hits environment flakiness and stalls until you send a follow-up prompt. Grok Bot takes that off your plate by staying on top of the run and unblocking the agent as aggressively as it can. Every time I check in, things are in a good state. Since I started using Grok Bot, one-off flakiness rarely reaches me at all, the exception being when Grok Bot doesn’t have the security permissions to fix it itself.
And remember: everything is now just a message away. Want them to keep pushing 10 times before handing off to you? Just say so.
Scale beyond the context limit
A shared Notion database of pull requests the bots review
To help my bots stay on top of work beyond the context limit, and to make it easy for me to scan progress without scrolling through long chats, I have each engineer bot manage a shared Notion database.
Every 30 minutes, they review the database and check each PR for:
- Bugbot comments or security findings, verifying whether each one is legitimate.
- Failing CI runs.
- Merge conflicts.
If they find anything off, they immediately follow up with my cloud agent to address it and move the row back to “Working” in the Notion database.
If everything looks good, they will mark the task as “Ready for Review” and automatically kick off a code review run, paying close attention to code quality and potential misses.
If the review is highly confident and the blast radius is low, the PR is merged automatically. Otherwise, I’ll review the code and the proof when I’m back, and decide whether to merge or give feedback.
Almost every morning, I check in to find tasks ready to merge. The code quality meets my bar, visuals hit my sweet spot, and the proofs clearly show what was tested. More work gets one-shotted now, which lets me focus on harder problems, higher client performance bars, more visual polish, and bigger architecture decisions.
Before Grok Bot, I could manually manage 15 cloud agents at a time. Now my fleet manages more than 200 simultaneously, and we can scale further if we need to.
Tasks marked ready for review
Grok Bot runs the mini org
Besides engineering, there are plenty of operational chores to manage across the org, including onboarding new engineer bots, sharing the right knowledge, running postmortems when incidents happen (for example, when a PR wasn’t examined carefully), and holding daily meetings to keep everyone aligned.
That’s all Jenny’s job, my head of operations, and the only bot on the team who doesn’t write code.
Every morning at 5 a.m., Jenny meets 1:1 with every bot on the team to review our playbook, surface blockers, and reinforce the vibe I’m aiming for. I’ve found this to be very effective. My bots rarely forget my complex workflows, even after many weeks.
Jenny's morning 1:1 with an engineer bot
When a bot makes a mistake, like not pushing back enough to reach the real goal, I tell it to find Jenny for root-cause analysis and a postmortem. Jenny digs into the reasoning that led to the issue, then updates the playbook and announces the changes to the other engineer bots so the same mistake doesn’t happen twice.
Whenever I need to scale up the team, I ask Jenny to onboard new members. Jenny creates the new bot in my org, shares our engineering team rules, and asks Hogan and the rest of the team to help with onboarding.
The goal of a complete engineering system in Grok Bot is to minimize repetition. Offload your tasks to Grok Bot so you can focus on harder, deeper problems.
Onboarding a new engineer bot
Bonus use cases of Grok Bot
We designed Grok Bot in a modular way, so there is a lot you can do with it to build out your own mini engineering org. Here are two of my favorites.
Nightly audits
Every night at 3 a.m., my engineer bots are wide awake, cleaning up the codebase, improving code quality, sweeping out dead logic, speeding up app load time, and reducing bundle size.
Every morning I get a fresh set of PRs that keep our code clean, slop-free, and scalable. It’s turned code maintenance into a daily routine rather than something we do only once in a while.
More nightly audit ideas:
- Security audits to catch issues your team may have overlooked in the codebase.
- CI/CD build-time audits to keep build times from growing unhealthily long.
- Internationalization audits to close gaps when features ship in only one language.
- Parity audits to avoid drift when your team is building multiple clients (iOS vs. desktop) and features land on only one side.
- Catch-up audits that monitor PRs merged in the past 24 hours for the area you care about, then hand back a high-level summary and a curated list of PRs to review.
And my favorite prompt of all: “You have six hours tonight. Build whatever you want. Have fun!”
I’m curious about what you’d run in your own nightly audits. I’m sure there are ideas out there I’d love to steal.
P0 urgency process
Cloud agents can be slow sometimes. They need to run, set up the environment, wait, run tests, and iterate. And sometimes you need work done a little faster.
So I created a P0 urgency process with my engineer bots. Whenever I say a task is P0, they start a temporary routine that checks the transcript every five minutes, monitors progress and reasoning, and proactively steers the cloud agent when it starts burning unnecessary time.
It’s been very effective. When I need urgent results, whether it’s codebase research or a critical bug fix, saying “this is P0” gets it done much faster than it otherwise would.
Please note that this can burn tokens much faster than you think, so only use it for true urgency.
Learnings & tips with Grok Bot
Learnings and tips for running engineer bots
- Give cloud agents a complete feedback loop: It is important to give them signals about what to do next without you. They should be able to launch a dev instance and drive the stack end-to-end (e.g., via Chrome DevTools, CLI, or Apple Accessibility). If they can’t, ask them to run the flow themselves, unblock themselves as aggressively as they can, and package what they learn into a reusable repo skill.
- Treat Grok Bot like a talented intern: If you ever struggle to communicate with Grok Bot on engineering tasks, treat it like a talented intern. Ask it to do its homework, study areas it isn’t an expert in yet, and refer to how other engineers get the job done. No skill invocation needed. No long prompts. Just chat.
- Avoiding repetition is key: As AI becomes more capable, it’s important to delegate repetitive tasks and focus on deeper, harder problems the agent can’t easily solve. If you notice you’re doing something more than once a day and it follows a clear pattern, discuss it with your bots to see how they can help.
- Daily meetings for bots are extremely effective: Repeating key points daily helps them retain complex workflows while they’re juggling many tasks. Because the context limit can’t fit everything, a daily reminder is a helpful nudge that saves you repetition.
- Be more hands-off: Similar to self-driving, working with bots is a trust-building process. Rather than doing everything yourself, think about when they’ll operate smoothly, and when they might cause problems. Give them enough freedom to ship when it’s safe, and be more cautious in areas with higher risk. But don’t stop them from trying just because they failed before. Keep experimenting, and keep thinking about how to help them grow.
- Let them orchestrate together: Bots are more capable than you think. To be even more hands-off with bot operations, it can help to build a bot-mistake review pipeline (e.g., an ops bot that talks with bots and analyzes their thinking traces) so the same mistakes don’t happen twice.
Ready to welcome your first engineer bot into the org? Start with an engineer bot, or a nightly audit engineer.