一张路线图：五篇指南都在把聊天变成长期工作系统

Eric Zakariasson 原先把 Coder、Writer、Researcher 分别放在不同聊天里。单个项目还能应付；几个项目一起推进时，信号和噪声混在一起，Bot 也很难知道彼此做到哪里。于是他把人类团队熟悉的结构复制过来：一个项目一个频道、一个固定 roster、一条项目记录，再用任务看板保存状态。

其余四篇沿着这条路继续往下走。移动工作室把职责拆成分析、创意、工程、部署和修复；设计团队让不同 Bot 分别负责探索、动作、Figma 生产和工程解释；GTM 团队建立会议、邮箱、拓客、账户和幻灯片岗位；PM 团队再加入 Chief of Staff、工程经理、工程 Agent、数据分析和招聘。

把五篇合起来，落地顺序可以压成七步：

1. 写清每个 Agent 的岗位和拒绝事项。
2. 用 Manager、Specialist 和项目频道分开责任与上下文。
3. 接入完成工作所需的真实账号、数据、电脑和生产资产。
4. 把重复动作录成技能，给例程设时间和输入来源。
5. 让 Agent 直接交接可验收产物，形成反馈闭环。
6. 把外发、花钱、删除、部署和高歧义判断留给人。
7. 先跑通一个闭环，责任真的增加时再扩充角色。

这七步是对五篇实践的编辑归纳，xAI 没有把它们正式命名为一套框架。

第一步：把每个 Agent 写成一份有边界的岗位

移动开发指南给出了最完整的定义。一个长期 Bot 有六个构件：岗位说明决定“是谁”；连接决定“能碰到什么”；独立电脑决定“在哪里工作”；例程决定“什么时候自己行动”；技能决定“怎样重复完成一个任务”；交接决定“把结果给谁”。

六项里最容易被忽略的是拒绝事项和交接。Analytics Agent 是唯一可以宣布数据发现的角色，它不能写广告，也不能碰应用代码。Creatives Agent 根据发现制作广告规格和变体，却不能购买媒体。工程 Agent 接收的是规格，不是含糊建议。GCS Agent 掌管证书、部署和回滚，没有经过它的变更不能到玩家手里。

Analytics 的配置还把时间、来源和输出写得非常具体：每天 19:10 汇总 Meta 与 AppLovin 的花费、安装和 CPI；每天 6:30 检查 PostHog 中房间规模与 Partner Challenge 漏斗；周一 9:00 汇总 7 天、30 天 CPI 与 Apple、Google Play 收入。广告赢家与输家交给 Creatives，产品发现以规格交给 Engineer，任何会花钱的动作先询问人。

第二步：用 Manager、Specialist 和项目频道搭组织

五篇里的角色名称很多，组织形态却很稳定：保留一个通用入口负责日常协调；让 Manager 拆任务、分配工作和验收；让 Specialist 拥有明确的数据、工具与责任；再用项目频道把不同目标的上下文隔开。

Ryan Perry 对移动开发的拆法解释了为什么职责必须分开：他把写出游戏本体估作约 15% 的工作，其余约 85% 是获客、创意、客户端、后端与 live ops、商店发布、QA 和事故响应。对应的六个席位是 Orchestrator、Analytics、Creatives、Rank’em Engineer、GCS 与 Bug Fix；每个席位都写了职责禁区。设计指南用 Figma Bro、Motion God、Experiments 和 Devbot 做同样的角色隔离，GTM 页面相关卡片则再次指回“频道、roster、Notion 看板”这套项目控制面。

原始 roster 把六个岗位和各自工作面放在同一张图里。

多项目指南把这个结构做得最简洁。Notion 里有 Projects 和 Tasks 两个数据库；Projects Manager 使用 Project Ops 技能创建项目、开频道并提出 roster。配员先复用已有 Coder、Researcher、Writer；除 PM 外最多提议五个 Bot；只有没有合适角色时才新建，而且必须由人批准。这里的六 Bot 上限只是作者自行设定的实验值。

项目频道同时容纳人、PM 和固定 roster，承担上下文边界。

任务板把 Backlog、Planning、In progress、Blocked 和 Done 变成共享状态。

项目开始后，人和 roster 在频道里拆任务。PM 大多观察进度并保持数据库更新。Bot 卡住时把任务标成 Blocked，再到频道里找人。这一步很朴素，却解决了多 Agent 最常见的失控方式：系统不再用沉默掩盖失败，人也不用逐个聊天追问进度。

PM 指南展示了更深的分层。Chief of Staff 是唯一通用角色，负责日历、Slack、收件箱和 Attention List；Engineering Manager 不写代码，只拆技术任务、委派给五个工程 Agent，再按目标验收；工程 Agent 可以继续管理多个 Cloud Agent。作者给多 Agent 的三个理由是可指称职责、并行工作和作用域记忆。Chief of Staff 不该调试计算机使用评测，评测 Agent 也不该整理邮箱。

Kevin Niparko 的完整 PM roster 还包括数据分析 Ashley、产品搭档 PM Pete 和 Recruiter。Chief of Staff 可以学习写作风格并维护注意力清单，但外发、购买和删除仍停在人这里；分层工程组织则让工程经理验收目标、五名工程 Agent 委派 Cloud Agents。所谓“团队”因此不只是角色名单，也包含上下两层的委派与复核。

第三步：接上真实系统、独立电脑和生产资产

岗位写得再好，没有工作环境也只能给建议。五篇反复要求 Agent 接入真实系统：移动团队连接 Meta Ads、AppLovin、Adjust、PostHog、Google Cloud、应用商店和 Sentry；GTM 团队连接 Salesforce、Gmail、Calendar、Sheets、Drive、Slack、Notion、Granola、Figma、X、LinkedIn 和数仓；PM 研究又加入 Gong、客户 Slack、Databricks、Plain 或 Intercom。

GTM Bot 的电脑 24/7 运行，笔记本关机后仍能工作；它从历史 Gmail 和 Slack 学习写作风格，也允许 Krista Letz 用移动 App 和语音在离开电脑时派任务。产品研究 Bot 则把访谈、客户 Slack、用户研究库、Databricks、支持票与 Notion 决策放进同一次检索，避免只凭一个系统回答跨来源问题。

PM 指南里的 Cloud Agent 也不是一台空白云机。它所在的环境已经准备好代码库、项目依赖、Secrets 和测试工作需要的条件，工程 Agent 才能委派实现、运行验证并收回产物。后文所说的“Bot 拆解高阶目标并参与合并 PR”，依赖的是模型、工程环境、分层委派和验收一起工作，不能只归因于模型。

独立云端电脑承担浏览器和终端操作，即使用户自己的电脑关机，例程仍能运行。这个环境也提供一种现实的 fallback：Ryan Perry 因为 Meta Ads API 验证问题无法走接口，于是按下录制键，在 Bot 的电脑上示范一次网页上传创意。Bot 记住 click-path，此后每天可以通过网页 UI 上传并测试至少一个新创意。

设计指南把“真实环境”说得更彻底。Motion God 没有根据截图近似重画 Grok Bot 角色，而是拿产品里真实使用的动画规范文件，在 localhost 搭了一个 playground。设计者可以直接调 timing、spring、distance、scale 和 easing，也可以说“向左下多看一会儿”“弹跳太夸张”，然后立即回放完整序列。

关键帧把抽象的动作反馈变成可以逐帧比较的生产资产。

Figma Bro 也不靠目测。它通过 Figma MCP 读取实际文件的 x/y 坐标、宽高、间距、字体、填充、描边和组件结构，从一个 Auto Layout 组件生成 20 个 starter Bot 角色卡。它还为新用户的工具选择页寻找正确版本的常用工具 Logo，再按使用概率排列。现有 Figma 文件是事实源，Agent 负责复制精度和规模，人负责判断版本是否值得留下；自动化在这里也防止错误 Logo、过期组件、头像来源不一和第十张卡片与第一张间距不同等小偏差批量累积。

批量角色卡证明它处理的是结构化 Figma 生产，不是截图近似。

项目状态

设计分工

真实注意力

软件交付

第四步：用例程、技能和交接跑出闭环

例程负责定时启动，技能负责稳定执行，交接负责让下一岗位接住结果。三者放在一起，Agent 才从“随叫随到的助手”变成持续运转的工作流。

项目 PM 的运行协议同样属于这里：它主要观察进度和维护 Projects/Tasks；任何 Bot 卡住或缺输入，就把任务改为 Blocked 并在频道提醒人。显式状态把失败变成可以接手的交接，不让卡住的任务静默消失。

移动团队还展示了例程怎样从工作中长出来。六个 Bot 每天各自负责一项夜间任务，早晨直接交付结果；一次夜间请求执行后，Bot 判断这件事以后应该持续发生，便把它加入自己的固定职责。例程因此不只来自人预先写好的时间表，也可能由 Agent 从重复责任中归纳出来。复制这种做法时，应把“新增长期例程”视为一次职责变更，检查它会持续使用哪些权限、资源和通知渠道。

移动工作室给出了最完整的闭环：Analytics 读取广告与产品数据，形成有资格称为“发现”的判断；Creatives 或 Engineer 把发现变成可测试修改；GCS 控制部署；新的行为数据再回到 Analytics。作者自报，这个循环把一版广告从 party 场景改成 partner 场景，安装成本由 15 美元降到 1 美元。另一轮分析发现高分与留存相关，团队增加 bonus hint，把 D7 留存由约 2.5% 推到 10%，约为原来的 4 倍。

原始对话显示 Analytics 的发现怎样直接进入下一岗位，而不是停在报告里。

Analytics广告 + 产品行为 → 有来源的发现

→

Creatives / Engineer广告变体或产品规格

→

GCS / Release部署、证书、回滚

→

再次测量CPI · 分数分布 · D7 留存

CPI：15 美元 → 1 美元D7：约 2.5% → 10%作者自报，非对照实验

这些数字很亮眼，证据却只有单一团队自报。来源没有提供样本量、对照组、归因窗口、同期改动或长期保持情况。能从案例中拿走的是闭环结构和责任边界，不能拿走“部署六个 Bot 就会得到 15 倍增长”的承诺。

GTM 指南把例程写成了更严格的协议：

• 收件箱只筛客户、潜客、续费、报价、介绍和直接提问，跳过新闻通讯、自动通知、收据、日历 RSVP 与内部噪声；交付摘要和拟回复，绝不自动发送；没有需要回复的消息就保持安静。
• 会后跟进只处理刚结束的外部会议，以 Granola 或 Gong 记录为事实来源，起草收件人、标题、正文和具体下一步。
• 拓客第一次先确认 CRM、邮箱、表格、使用数据、意向工具、账户归属、买家职能与职级；从 15–30 封真实外发邮件学习风格，约 30 天刷新。
• 每次拓客重新确认岗位过滤和数量，先发现 CRM 的真实字段与阶段；严格按职能筛人并去重，找不到近期公开内容就明说找不到。
• 接入产品数据后，每一行还要标出账户中的活跃用户和触及套餐上限的人，把额度触顶当作扩容线索；意向信号优先直接产品提及，不把泛泛的 AI 讨论当成强意向。
• 每一行都显示现有商机阶段、金额和最后一次 CRM 活动，避免把温热管线重新当成冷名单；交付实时表格链接，不交 CSV，LinkedIn 短消息也不能提“已经发过邮件”。
• 起草前核对最近 90 天发件记录、表格的 Emailed 列和 CRM 活动，把已经触达的人标成 Skip Draft；保留在表里，但不重复推销。
• 先展示 2–3 组邮件和 LinkedIn 样本供人审批，再生成整批；实际发送后回写日期，下一轮继续去重。
• 账户专家维护“已经处理过什么”的状态文件，只汇报新内容；播客、视频和演讲要取得文本或真正消费内容，保留 3–6 个要点、竞品提及、情绪、时间戳引文和购买信号。它还从通话中提取功能请求、跟踪支持工单，并为客户匹配相关新功能。拿不到文本时要说明，不能假装看过。

这类提示词的价值不在措辞长，而在运行状态写得完整：第一次怎样初始化、每次怎样确认参数、用什么当事实源、怎样避免重复、哪一步等待批准、完成后回写什么。

PM 的软件交付也沿同一路径运行：人给出高阶目标，Bot 在已经配有代码库、依赖、Secrets 和测试条件的 Cloud Agent 环境中拆解、委派、评审并集成产物。Kevin 自报 Grok Bot 当时贡献了内部合并 PR 的两位数百分比；这个说法缺少时间窗、分母和返工口径，能证明的是该路径已进入真实代码交付，不能证明质量或净效率。

第五步：项目、移动、设计、GTM 和 PM 各自怎样落地

五个领域需要不同角色，不能用同一套万能 Bot 名单覆盖。它们共享岗位、连接、例程、技能、交接和人工门禁，具体工作单元仍由业务决定。

多项目：项目频道是上下文边界

一个项目对应一个频道、一个 roster 和 Notion 项目记录。Projects Manager 做元工作，具体 Specialist 认领任务，PM 维护状态，Blocked 把无法继续的任务显式交回人。项目结束后可以撤下临时角色；责任再次出现时，优先复用已有岗位。

移动开发：把“写完应用”扩成完整工作室

Ryan Perry 用六个 Bot 运营移动游戏 Rank’em；文章发布时，他自报这款游戏在此前一周跨 iOS 与 Android 下载超过 1,000 次。移动案例覆盖获客、创意、客户端、后端与 live ops、发布、QA 和事故响应。作者把游戏本身约占 15%、外围工作约占 85% 视作经验判断。团队当时还计划增加收入 Bot 和更多广告网络，其他岗位等新责任出现再建立。指南目录也用“六个 Bot、一个移动游戏工作室”概括这篇实践。

设计：增加可判断版本的数量

John Bai 没有用常驻 Agent 替换 Figma 或既有设计工具；他用它们更早做出可以反应的实物，并探索更多方向。Experiments 做了三个 ambient access 原型：常驻 Mac 刘海、从桌面角落探出、跟随光标。它把角色动作交给 Motion God，把桌面行为和工程问题交给 Devbot，再汇总成能在真实一天里体验的版本。三个概念都没有原样上线；产物让设计者判断它们何时有帮助、何时打扰。指南目录对这篇的概括也是 always-on Agent、真实生产资产和保留人工判断。

GTM：让每个客户和交付物有自己的维护者

Krista Letz 最初把自己的用法写进内部 Notion，供 Enterprise GTM 团队 dogfooding；内部采用扩展后，她才把这份实践公开。Chief of Staff 负责会议、邮箱和其他 Agent 编排，且每日材料要短、可扫读、适合通勤时用手机查看；Prospecting 维护拓客状态；每个战略账户可以有 Customer Expert，只汇报状态文件中尚未处理的新材料；Data Agent 跟踪客户使用；Product Expert 连接代码库，在电话中给客户可读的技术答案，没有代码库权限时也可以改用 Glean 等内部知识源；1:1 Agent 准备经理同步；Forecasting Bot 从 Granola、Gong、Slack 和邮件更新 Salesforce 机会备注；Slides Bot 依据预先提供的设计规范维护 Figma 母版，也能翻译客户演示文稿；Sales Coach 复盘 Gong 电话。

Slides Bot 的边界可以直接借鉴。通话结束前 5–10 分钟停止录音，它可以根据客户刚说的内容更新“我们听到什么”页。若还没有通话，只能使用公司博客、财报等一手资料，并把页面写成“他们正在优先做什么”，同时明确标记研究来源，不能把公开材料冒充客户原话。

PM：让真实注意力成为新的工作清单

Kevin Niparko 的出发点是 PM 往往管理产品，却没有直属团队；常驻 Agent 首次给了 PM 一支能直接接目标、协助交付的团队。他也明确说这种用法有学习曲线。Attention List 每小时读取 Slack、邮件、Granola 和日历，生成正在关注的项目、当前状态和下一步。它来自实际行为，不依赖人工维护的周目标。Agent 可以用它过滤一天中海量消息、归档与当前关注事项无关的邮件；PM 也可以比较声明的优先级与实际投入，并回看一周注意力分布，找出以后适合交给 Agent 的工作。

Chief of Staff 的一个日历案例把自治边界落到了具体动作：它先创建暂定日历占位，再请人选择开始时间；Kevin 回复 10 点后，它才移动占位。Agent 完成信息收集和机械操作，人只决定影响安排的关键参数。

数据 Agent 依赖已有综合图表做刷新和切片；高歧义解释仍交给人。

PM 团队还包括数据分析 Ashley、产品搭档 PM Pete 和 Recruiter。Engineering Manager 入职时先阅读一名受认可的人类 EM 的 Slack 记录，学习优秀工程经理怎样拆解、追问和验收；专业 Agent 的训练材料因此不只是岗位说明，也包括优秀从业者留下的真实工作轨迹。数据 Agent 主要用综合图表回答已经回答过但需要刷新、或需要换切片的战术问题；高歧义、高品味的分析继续交给人。PM Pete 可以把散落在频道、线程或私信里的功能分歧整理成带原话引用、按 P0–P2 分级的 RFC，也曾研究并购买 Raspberry Pi 的缺失部件，再指导接线。作者自报，Grok Bot 当时占内部合并 PR 的两位数百分比，但没有公开时间窗、分母或返工数据。

第六步：把发送、花钱、删除和高歧义判断留给人

五篇都让 Agent 行动，也都在关键地方设了人工门禁。它们没有用一句“human in the loop”糊过去，而是具体说明哪类动作停在哪里。

外部邮件只起草；广告花费先询问；新建 Agent 先批准；应用变更经过部署角色；PM 仍最终发送大多数消息、编辑重要文档；购买和删除由人确认；高歧义数据问题留给人类分析团队；设计者判断动作是 280 还是 340 毫秒，而不是把“感觉对了”交给 Agent 自评。

另一个同样重要的门禁是保持安静。Chief of Staff 在没有变化时不发消息；收件箱没有需回复内容时不发送汇报；账户周报没有新材料时只发一句。Bot 的工作量可以很大，给人的通知量必须很小，只有需要注意、批准或解除阻塞时才升级。

设计和数据判断还揭示了另一条边界：Agent 可以加速“制作—反应—修改”，却不能替人判断哪个版本感觉正确；数据 Agent 适合刷新综合图表和改变战术切片，高歧义、高品味问题仍由人类数据团队处理。Kevin 最后把经验压成四条：给角色命名、分开记忆、让它在岗位中学习、无事不报且重要事项交给人。

Experiments 的三个 ambient access 概念都没有原样上线；它把动作交给 Motion God、把桌面行为和工程问题交给 Devbot，汇总成可体验版本后，再由人判断它是有帮助、打扰，还是介于两者之间。

第七步：从一个可验收闭环开始，需要时再扩队

五篇没有建议一开始就造几十个 Agent。移动团队先选数据与产品反馈这条最耗时闭环；多项目团队先解决频道和任务状态；设计师先做一个能体验的原型；GTM 先把每日会议准备和收件箱变成例程；PM 先让 Chief of Staff 维护 Attention List。

移动团队当时还计划增加收入 Bot 和更多广告网络；其他岗位要等新问题形成持续责任后再建立。这个扩队顺序比预先画一张庞大组织图更接近五篇的真实做法。

适合起步的任务通常具备四个条件：重复发生；输入来源明确；结果可以检查；执行失败能够停下来找人。完成一次人工示范后，再录成技能；连续运行稳定后，再把输出交给下一个 Specialist；新责任持续出现时，才增加角色。

GTM 的扩展经验补充了这条路径：用一次屏幕示范生成技能，从真实发件箱学习风格，把人的修改持续写回规则；任务多起来后，让 Agent 并行执行，由 Chief of Staff 做审计，并在群聊里让多个角色共享同一段目标和状态。审计不仅寻找还能自动化或并行的工作，也清理已经没有必要的例程，防止自动化系统只增不减。这里扩的是可追踪的责任链，不是孤立聊天数量。

下面这份最小岗位卡是根据五篇材料整理的编辑模板，不是 xAI 原文。六个核心字段来自移动开发指南；拒绝事项、批准点、交付和成功标准把其他四篇的控制做法补了进来。

name: analytics-agent
mission: 读取真实行为和投放数据，形成可复核的发现
refuses:
  - 不写广告创意
  - 不修改产品代码
connections: [ads, attribution, product-analytics, revenue, errors]
environment: 独立云端电脑；缺少连接时先询问，不自行绕过
routines:
  - 每日汇总花费、安装和成本
  - 每日检查产品漏斗是否与广告承诺一致
skills: [导出广告报表, 拉取创意明细]
handoffs:
  findings: creatives-agent
  product-specs: product-engineer
approvals: [任何花钱动作, 无法解释的数据冲突]
deliverable: 带来源、口径、赢家、输家和下一步的报告
success: 下一岗位无需猜测即可执行，人能复核全部关键判断

验收时只问五件事：它是否只做岗位内的工作；使用的事实源是否正确；失败能否显式进入 Blocked；交给下游的是不是可执行产物；关键动作是否真的停在批准点。答不上来时，不要继续扩队。

五篇官方原文：多项目团队、移动应用开发、用 Grok Bot 设计 Grok Bot、Enterprise GTM、产品经理团队。