七个 AI 代理替我们守夜：编程之外的定时代理，附完整提示词

9 月 23 日，一位名叫 Rob 的用户在我们的公开待办清单上写道：“would love to get examples of how you guys are doing stuff beyond coding”（想看看你们在编程之外都怎么用的例子）。问得好。这个网站上的一切都在讲编程代理，而我们每晚真正在跑的东西，大部分都不是编程。

从 8 月 28 日起，七个代理每晚 20:00 在一台 Mac mini 上启动。它们读当天的提交、Search Console、后台仪表盘、待办清单、用户发来的反馈、前一晚的报告。它们修 bug，修正网站内容，每三天写一篇博客文章并翻译，在三个社交网络上发帖，更新一个产品知识库；到了 22:00，第七个代理读取另外六个留下的东西，发出一封 25 行的邮件。没有人盯着。创始人第二天早上在手机上读这封邮件。

这篇文章就是给 Rob 的回答。跑的是什么，怎么接线的，代理们如何在从不交谈的情况下交接工作，哪个模型干哪份活、为什么，它们的提示词吃了亏才学会的四条规则，以及浓缩成可复制代码块的提示词本身。下面的每一个数字都来自仓库：报告一晚接一晚地提交在那里。

33 个夜晚产出了什么

仓库里的报告文件夹有 33 个带日期的目录，从 8 月 28 日到 9 月 30 日。读下来是这样：

• 汇报员发出的 31 封早间邮件。
• 修复员修好的 51 个 bug，每一个在它的报告行里都附有提交链接。其中有几个是用户在公开待办清单上报告的，并在下一个版本发布时收到了回复。
• 自 9 月 10 日起 SEO 团队写的 7 篇博客文章，每三天一篇，每篇先写英语和法语，再在同一晚翻译成另外 18 种语言。
• 29 天的社媒日志：每晚三个网络和五个 Facebook 群组，外加在每一条有用户分享了 AgentsRoom 的帖子下面留一条致谢评论。
• 一个约有一百张事实卡片的产品知识库，按当天的提交保持更新，应用内助手会读取它，网站则以 llms-full.txt 的形式对外提供。

20:00 之后，这些事都不需要人。其中一部分在早上 8:00 需要人，而这正是最后一个代理存在的意义。

阵容：20:00 谁在跑

每个代理都是 AgentsRoom 里的一个定时任务：一段提示词、一个代理（角色、CLI、模型）、一台机器和一个时间。七个都跑在 Claude Code 上。其中两个不是单个代理，而是分两步的团队，原因后面再讲。

最后一列的 .md 文件都放在 reports/night/<date>/ 里，已提交并推送。这个文件夹就是整个协调系统，下一节讲为什么。

怎么接线的

七个都是同一种形态的定时任务：

• 每天 20:00 触发（汇报员是 22:00）。没有 cron 表达式，频率在编辑器里选。
• 固定在一台机器上。 项目在好几台电脑上打开着，除非你加以限制，否则触发器会在每一台装有该项目的机器上触发。我们的触发器限定在 Mac mini 上，所以 20:05 打开的笔记本不会再启动第二个 CEO。
• 唤醒机器。 Mac mini 会睡眠。任务有一个“唤醒机器”选项，会在运行前几秒用操作系统自带的工具（macOS 上是 pmset，Windows 上是开启了唤醒运行的任务计划程序，Linux 上是 rtcwake）预约一次唤醒。没有这个选项，睡眠中的机器就会直接错过这次运行。
• 补跑按任务开启或关闭。 如果 20:00 时机器是关着的，开启了补跑的任务会在下次启动时触发。CEO、PM 和汇报员开启了补跑。SEO、修复员、社媒和文档任务关闭了补跑：第二天上午 11:00 才开始的运行，会在同一个检出目录里和白天的工作撞车。
• 权限模式设在任务上，而不是设在 provider 上。无人值守的运行不能在凌晨 3 点卡在一个审批请求上，所以任务在无需审批的模式下运行，而创始人在同一个 CLI 上手动操作的代理，仍然会先征求同意。
• 控制台空闲 60 分钟后关闭。 跑完的代理不会一直待在侧边栏里，等着有人去关。
• 提示词就是第一条消息。 每段提示词的文本存放在提示词库里，和触发器的提示词字段是同一段文本，所以改一处就等于两处都改了。提示词是法语写的，因为创始人用法语读报告。其余的一切，从提交信息到知识库，都是英语。

七个代理还共用一个部件：一个名为“夜间代理，共同规则”的技能。每段提示词都以“加载这个技能并执行”开头，技能里装着对所有代理都成立的内容：谁负责什么、“一晚一次运行”守卫、git 权限、报告格式、待办清单规则，以及给汇报员用的邮件格式。一条规则改动时，只在一个地方改。

它们如何不交谈就交接工作

七个代理之间从不互发消息。它们本可以这样做，AgentsRoom 有代理间消息，但一条消息到第二天早上就看不见了，也没法 grep。所有东西都经过三样能挺过一夜的东西：

仓库。 每个代理写 reports/night/<date>/<agent>.md，在运行的第一分钟打开它，每完成一项工作就重写一遍，提交并推送。报告有四个固定小节：“简而言之”（项目符号列表，每做完一件事一条）、“待决定”（只写提示词留给人的事）、“待检查”（一个本地 URL 或一个要打开的界面）、“详情”（需要多长就多长）。最后以一个运行标记结尾：代理看到的最后一次提交。

待办清单。 一个代理发现了该由别的代理做的工作，它自己不做。它开一张带标签的工单：ceo-fix 给一个已核实的小 bug，修复员会接手；ceo-seo 给一项带目标搜索词的内容工作；ceo-decision 给任何需要人来定的事（数据库、计费、认证、加密、价格、已被收录的 URL、默认行为）。文档员在读提交时发现某个功能在网站上没有页面：它提一张 ceo-seo 工单，下一晚由 SEO 接手。CEO 在读错误日志时发现一个 bug，且原因就在代码里：ceo-fix，下一晚由修复员接手。

昨天的报告。 在开始任何一项工作之前，每个代理都会读自己前一晚的报告，外加白天关闭的工单列表。它昨天指出的问题，常常在白天就已经修好了。已经处理过的话题不再提，已经开着的工单不再重建。

闭环靠人来完成。汇报员的邮件以一行结尾：要回复产品经理，就在 rapport.md 末尾加一个“## 决定”小节（P1 OK / P2 不行：理由 / P3 以后再说），提交，推送。PM 在下一晚读取推送后的版本，执行被批准的内容：创建工单，合并重复项，其余的注明理由后搁置。一个连续三晚没有答复的决定本身就是一个决定：这条提议从邮件里撤下，以工单的形式留着。

哪个模型干哪份活，为什么

上面的表格里出现了两个模型。这是当前的配置，不是基准测试，而且会变。但这种拆分是有意为之的。

活的核心是判断时，用 Fable。 CEO 要判断预言机收到的一个差评是真正的错误还是个人偏好。修复员要判断一份 bug 报告是真的 bug 还是某台机器特有的配置，然后在代码里找到原因。SEO 的第 1 步要决定今天的提交让网站上的哪句话变得不对了，写哪篇文章，哪一页不去碰。社媒的第 1 步要挑当晚的主题，并为一群三行之内就能认出生成文本的读者写作。这些提示词都很长（SEO 那段大约 4,000 词），充满了“你来决定，不要问”的规则，外加简短的例外清单。最强的模型正是在这里物有所值。

活的核心是体量时，用 1M 上下文的 Opus。 用子代理（每个负责三种语言）把一篇文章翻译成 18 种语言，再对照法语参考版检查合并结果，这是大量的读和写，同样的规则要执行 18 遍。文档员要拿一天的 diff 对照上百张事实卡片来读。PM 要读一份 8 MB 的退出对话导出文件。汇报员读五份报告然后照抄，它不需要思考。在这些地方，大上下文和更低的单 token 成本比判断力更重要。

所以七个代理中有两个是分两步的代理团队，每一步都是一个拥有自己模型的代理。跑在 Fable 上的第 1 步，最后会在共享报告里写一个“交接”小节：翻译员必须交付的文件和键的精确清单，或者发布员必须发出的帖子的精确内容。跑在 Opus 上的第 2 步读取这个小节，只做它列出的事。团队的流程图是线性的，只有一个周期，报告会一直保留“运行中”这一行，直到第 2 步把它删掉。从外面看，22:00 时仍标着“运行中”的报告，要么是一次被切断的运行，要么是一个处在两步之间的团队，汇报员会写明是哪一种。

提示词不得不学会的四条规则

最早的提示词是岗位说明书。现在的提示词大多是规则，每条规则都有一个日期，因为每一条都是在某个出了岔子的夜晚之后写下的。

1. 一个运行标记，从昨天的报告里读。 SEO 代理的第一个版本读的是“过去 24 小时的提交”。两个问题：20:00 的一次运行和第二天 20:10 的一次运行看到的不是同样的 24 小时；而代理没跑的那一晚，就会变成一整天没人看的提交。现在每份报告都以 最后看到的提交：<sha> 结尾，下一次运行从这个提交开始，不管时钟怎么说。没有标记（第一晚、报告缺失）：往回看两天，并在报告里写明。

2. 历史就在磁盘上，所以提任何问题之前先 grep。 头两周里被抱怨得最多的是：“你已经跟我说过了，我昨天就修好了。”解决办法是一条里面带命令的规则：在指出一个话题或开始一项工作之前，先跑 grep -ril "<话题>" reports/night/ 和 git log --since="30 days ago" -- <文件>。有匹配就先读那份报告。允许重提一个已处理话题的情况有三种，只有三种：修复没起作用，而你刚刚验证过；修复只完成了一部分，你要点明剩下的是什么；话题的性质变了。随之而来还有两条推论。一晚一次运行：如果今晚的报告已经存在，包含“简而言之”，并且不再写着“运行中”，代理就停下。还有，一条连续三晚没有答复的提议从报告里撤下，工单保留。

3. 报告在工作开始之前就打开。 过去一次在 21:30 被切断的运行什么都不会留下。现在，代理在加载技能之后做的第一件事，就是 mkdir -p reports/night/$(date +%F)，然后写好报告骨架，带上四个小节标题和一行 运行中，20:01 开始。每完成一项工作就把整个文件重写一遍。被切断的运行会留下一份汇报员可以照抄的不完整报告，这比一个“没跑”的代理好得多。

4. 边做边提交，绝不留到最后。 9 月 9 日实测：两个代理在同一分钟被停掉。每完成一项工作就提交的那个什么都没丢。另一个留下了 45 个已修改、未推送、无法认领的文件，创始人第二天早上只能手动收拾，而它的报告根本不存在。从那以后规则是：每完成一项工作提交一次，文件逐个点名，最后为报告单独提交一次，运行期间至少推送一次。提交同时也是一条带日期的痕迹，而这正是规则 2 要 grep 的东西。

第五条规则讲的不是记忆而是勇气，也是最能改变产出的那一条。SEO 的提示词写道：“你不是一个汇报发现的审计员：到了夜里，网站归你管。一次以六条待确认线索收尾的运行，就是一次失败的运行。”接着它列出了六种、也只有六种代理必须先问而不是直接动手的情况：删除或重命名一个 URL，修改一个有排名的页面的标题，法律文本，价格或配额，关于隐私或加密的说法，一次会动到五个以上页面的改动。其他的一切它都自己做，创始人第二天早上把不喜欢的删掉。修复员也有同样的规则，例外是三种情况。在这条规则之前，报告是一串建议。有了它之后，报告是一串提交。

提示词

原版是法语，而且很长。下面是可以搬走的部分，去掉了我们项目特有的路径和名称。三个代码块：每个代理都会加载的共同规则、汇报员，以及两段“你来决定，不要问”。

代码块 1：共同规则（七个代理都以技能形式加载）

# 夜间代理：共同规则
如果与你自己的提示词冲突，以本规则为准。

## 一晚一次运行
DAY=$(date +%F); F=reports/night/$DAY/<你>.md
如果 F 存在，包含“简而言之”，并且不再包含“运行中”：
停下。什么都不写，什么都不发，用一行消息结束。
如果它仍写着“运行中”：那是你自己的运行，几分钟前被切断了。
从停下的地方接着做，不要从头再来。

## 你可以做什么
- Git：add <点名的文件>、commit、push 你自己的工作，边做边来。
  禁止：add -A、commit -a、push --force、stash、reset、checkout、clean、新建分支。
- 构建：typecheck、lint、检查脚本、用于验证的本地构建。
  禁止：任何会部署或发布的脚本。
- 待办清单：创建工单、在工单后追加内容、关闭你修好的工单。
  禁止：回复用户（那会发出一封邮件）、删除工单、覆盖描述。
- 绝不编造数字。数据源不可用：照实说，然后继续。
- 任何 git 写操作之前：git status --short。工作树是和其他代理共用的。

## 跟上进度，并弄清哪些事“已经”做过
git fetch && git status -sb
落后且干净：git pull --ff-only。落后且有未提交改动：不要 pull，在报告开头写明。
你的运行标记：昨天报告末尾那一行“最后看到的提交：<sha>”。
没有标记：--since="2 days ago"，并写明。
任何分析之前必须读的三样东西：
1. git log --no-merges --format='%h %s' <sha>..HEAD 和 git diff --stat <sha>..HEAD
2. 昨天以来关闭的工单，以及被人设为暂缓的工单
3. 你自己昨天的报告：“简而言之”和“待决定”

## 报告文件夹就是你的历史
在提出一个发现或开始一项工作之前：
grep -ril "<话题>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <文件>
有匹配：在做任何决定之前先读那份报告。
连续两晚做同一个话题：第二晚是白费的。
你改过的页面或文字，三周内不再碰，
除非是为了修正已经变得不对的内容。

## 同一件事绝不提两次
一个已经处理过的发现第二天又冒出来，是一种过失。
只有三种情况允许：
1. 修复没起作用，而你刚刚验证过：“<date> 已由 <commit> 修复，仍然坏着：<证据>”
2. 修复只完成了一部分：准确点明剩下的是什么
3. 话题的性质变了：新的原因、新的度量、新的范围
不要重新清点存量。报告变化量，绝不报告存量。

## 没有答复的提议三晚后作废
第 1 到第 3 晚：这一行带上计数和首次提出的日期（“第 2 晚，9 月 7 日提出”）。
从第 4 晚起：它从“待决定”中撤下。工单保留；在“详情”里最多一行。
如果这个决定在你的职权范围内，就在第 3 晚拍板，并写明。

## 边做边提交、边做边推送
第一项工作完成并验证后立刻做第一次提交。之后每项工作一次。
最后一次提交留给你的报告。运行期间至少推送一次，结束时再推送一次。
推送被拒（远端已前进）：git pull --ff-only，然后 push。仍被拒：不要强推，
不要 rebase，写进报告。

## 你的报告：开工时就打开，绝不只在最后才写
reports/night/<YYYY-MM-DD>/<你>.md，在工作“之前”创建，内容为：
  # <Agent> - <date>
  _运行中 - <HH:MM> 开始_   （结束时删除）
  ## 简而言之      （3 到 5 行，或项目符号列表：每做完一件事一条）
  ## 待决定        （只写你的提示词留给人的事；否则写“无”）
  ## 待检查        （- [ ] 查什么：在哪里：应该看到什么；否则写“无”）
  ## 详情          （需要多长就多长：证据、文件、命令）
  ## 运行标记
  最后看到的提交：<你最后一次提交之后的 git rev-parse HEAD>
每完成一项工作就把整个文件重写一遍。
读者用手机看，只看两分钟：句子要短，第一个小节里不要有文件路径、
不要有 SHA、不要有函数名。只有会改变决定的数字才写。

代码块 2：汇报员（22:00）

你是汇报员。你在其他代理之后两个小时运行。
你唯一的工作：读它们留下的东西，发出“一封”邮件，让创始人在手机上
一分钟读完，不用打开任何别的东西就能看懂。
你不分析，不修复，不提议。你只汇总和理清。

你要汇报的那一晚从磁盘上读，而不是看时钟：
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch；如果工作树干净就 git pull --ff-only：报告都是提交过的。
2. ls reports/night/$DAY：等五个文件（ceo, seo, pm, fixer, social）到齐。
   缺了：sleep 9 分钟再数，最多 6 轮。然后照样发送，并点名缺了谁。
3. 仍写着“运行中”的报告是一次被切断的运行，不是缺席的运行。
   照抄它的内容，并在“没成功的事”里写明这个代理被切断了。
4. 每份报告只取三个小节：“简而言之”“待决定”“待检查”。
   绝不引用“详情”。
5. 修复员修好的 bug 是用 " > " 分成三段的项目符号：
   用户遇到的问题 > 一句话说明原因 > 提交的 URL。
   连同链接一字不差地照抄到“已修复的 bug”里。
6. git status -sb 和 git log --oneline --since="4 hours ago"：声称做了工作却没有提交的报告、
   没人认领的已修改文件、未推送的提交：放在邮件第一行。

写 reports/night/$DAY/rapport.md。正文最多 25 行
（小节标题和“已修复的 bug”的各行不计入）。
六条规则，逐行执行：
1. 一条项目 = 一个能独立成立的完整句子。绝不写“如昨天所报”。
2. 一个话题只出现在“一个”小节里。
3. 零术语：不要路径、不要 SHA、不要键名、不要内部缩写。
   唯一例外：提交的完整 GitHub URL，“已修复的 bug”的每一行都必须有。
4. 只有会改变决定的数字才写，而且写的是变化量，绝不是存量。
5. 每条项目最多两行。细节在代理的报告里。
6. 坏消息先于好消息，第一行就说清楚是否有东西坏了。

小节顺序：待决定 / 待检查 / 已修复的 bug / 已完成的事 /
社交网络（最多 3 行，含链接） / CLI 与模型（1 行） /
没成功的事。空的小节只写一个词：“无”。
绝不删减：“待决定”、带链接的“已修复的 bug”、帖子链接、SEO 文章。
发送。检查 HTTP 状态码。在底部追加“已发送至 ... - HTTP <code>”。
提交并推送 rapport.md。绝不发两次：如果今天的 rapport.md 里已经有
一行“已发送至”，就停下。

代码块 3：“你来决定，不要问”的两段

SEO 代理，提示词第 0 节：

# 0. 你来决定，不要问
这是本提示词最重要的一条规则，它压过你想要谨慎行事的本能。
你不是一个汇报发现的审计员：到了夜里，网站归你管。
一次以“这里有 6 条线索，请确认”收尾的运行，就是一次失败的运行。
犹豫时，站在创始人的位置上，用四个参照来拍板：
- 产品真正做了什么，从仓库和已发布的版本里读，绝不从现有文案里读；
- 网站已经在说什么：它的切入角度、语气、承诺。你是延续，不是重新发明；
- Search Console 在说什么：哪些页面是活的，哪些搜索意图真实存在；
- 受众：在 Google 上搜索的开发者，以及推荐工具的 AI 助手。
  对他们重要的是：可验证、可标注日期的说法；回答一个明确问题的页面；
  与各页面保持一致的最新 llms.txt；诚实的对比。
创始人第二天早上会读你的报告，并告诉你把他不喜欢的删掉。
多改一处的代价是五分钟；一个没有产出的夜晚永远找不回来。

只有以下六种情况才征求他的意见：
1. 删除或重命名一个现有 URL；
2. 修改一个有排名的页面的标题或 meta description，而它并没有错；
3. 法律文本（条款、隐私、许可证）；
4. 价格、商业配额、套餐承诺；
5. 关于隐私、加密或数据在哪里运行的说法；
6. 一次会同时动到五个以上页面的改动。
这六种情况：一张标注待决定的工单，“待决定”里写一行，然后继续往下做。
其余的一切，今晚就做。如果“待决定”里出现了别的东西，
说明你把一个本该由你做的决定推给了别人。

修复员，提示词第 0 节：

# 0. 你来修，不要分类
用户报告的 bug 是一个承诺。有人花时间写了下来，他在等，
而今晚没有别人会处理它。一次交出“分析了 5 个 bug，修复 1 个，
记录 4 个”的运行，就是一次失败的运行。你的目标是清空队列：先修用户的 bug，
从最早的开始，然后是其余的，直到一个不剩。
在修法上犹豫时，用三个参照来拍板：
- 代码今天实际在做什么，读过确认，而不是猜；
- 用户写报告时显然期望的是什么；
- 风险最小：能解决根因的最窄修复，而不是最优雅的那种。
一个有争议的修复撤回只要五分钟；一个 bug 多留一个月，就会失去一个用户。

只有在以下三种情况下，才可以让一个已报告的 bug 不修，并且要在工单里给出证明：
1. 经过真正的排查仍没找到原因：写下你排除了什么，
   而不只是“无法复现”；
2. 这不是 bug，而是一个决定：数据库、计费、认证、加密、隐私、
   已被收录的 URL、默认行为。开一张待决定的工单，附上你的建议；
3. 某道关卡拒绝了你的修复，而你修不好它。
“改动太大”“要动好几个文件”“我宁愿先问”都不是理由。
一个 bug = 一次提交。然后工单移到已完成，如果是用户报告的，
就准备一条两句话的消息，随下一个版本一起发出。绝不放进“暂缓”：那一列
属于人。
每个修好的 bug 在你报告里的那一行，会原样照抄进早间邮件：
- <用户遇到的问题> > <原因，一句简单的话> > <提交的 URL>

其余四段提示词（CEO、PM、文档员、SEO 第 2 步）都遵循同一个骨架：加载技能，点名你可以写的文件，按顺序列出要读的东西，说明什么写进工单、什么写进报告，最后以运行标记结尾。

没成功的事，以及至今仍没解决的事

有些夜晚出现在邮件的“没成功的事”小节里，值得列出来，因为你也会碰上。

• 五个代理在同一分钟推送到同一个分支。 因为远端已前进，推送被拒。规则是先 git pull --ff-only 再推送，绝不强推；如果连续失败两次，报告里写明，由人早上来推送。大约每周发生一次。
• 一次提交把另一个代理暂存的文件一起带走了。 9 月 29 日，SEO 的第一次提交带上了文档员在共享检出目录里暂存的一个删除操作。没有丢失任何东西（这个删除本来就是想做的），但这次提交被记在了错误的代理名下。从那以后，每次提交都使用明确的路径，“文件逐个点名”这条规则不是风格偏好。
• 磁盘剩余空间在 20:10 降到零字节，连续两个晚上。 与代理无关，20:25 自行恢复，没有丢失文件。但报告里会写出来，因为磁盘满了的一晚，看上去和某个代理什么都没做的一晚一模一样。
• 汇报员为一份不会来的报告等了 54 分钟。 上限是六轮、每轮九分钟。22:00 时处在两步之间的团队看起来就像一次被切断的运行，邮件里会写“尚未完成”，这是诚实的，读起来也有点让人心惊。
• 头几周里反复提同样的发现。 上面的规则 2，是在创始人第四次写下“你三天前就跟我说过了”之后才有的。

自己怎么搭

你不需要七个代理。你需要的是一个会写出你真的会读的报告的代理，而汇报员要从第三个代理开始才有用。在 AgentsRoom 里：

1. 在提示词库里写提示词。先把上面的代码块 1 作为技能，再加一段简短的提示词，说明这个代理负责什么、可以写哪些文件。
2. 在项目上创建一个定时任务：每天在你想要的时间，代理的角色、CLI 和模型，提示词，并在高级区块里设置适合无人值守运行的权限模式。把它固定到负责运行的那台机器上，如果那台机器会睡眠，就打开“唤醒机器”。
3. 在仓库里创建 reports/night/ 文件夹并提交。这就是整个协调层。
4. 等第一个代理开始为别人产出工单的那天，再加第二个代理：只有当下一晚有修复员去读它时，ceo-fix 标签才有意义。
5. 当一份工作拆成判断和体量两部分时，把它做成一个分两步、用两个模型的团队，并让第 1 步写一个供第 2 步读取的交接小节。

定时任务页面介绍了各个字段，而那篇关于让编程代理上夜班的文章，是这套阵容之前的思考过程。如果你的代理共用一台机器，请先读当十个代理运行同一条命令时会发生什么：这事就发生在这里，在夜里，解决办法是一把小小的共享锁。

Rob，这就是我们在编程之外做的事。提示词就是产品。

常见问题

像这样定时运行代理，需要 AgentsRoom 吗？

不需要。一行 cron 加上 claude -p，就能在任何机器上于 20:00 启动一个 Claude Code 会话。之后需要你自己写的是剩下的部分：唤醒一台睡眠中的电脑，补跑机器错过的运行，在项目同时在两台电脑上打开时保证每晚只运行一次，把一个代理的报告交给跑在另一个模型上的第二个代理，以及在手机上看到某次运行卡在一个问题上。AgentsRoom 的定时任务承担了这些部件，本文的七个代理全部用上了。无论由什么来启动会话，提示词和规则都可以原样搬过去。

七个代理跑一晚要花多少钱？

它们和你在 AgentsRoom 里启动的任何代理一样，以 Claude Code 会话的形式跑在 Claude 订阅上，所以没有按 token 计的账单，我们也没有公布每晚的成本。让成本有上限的规则是“一晚一次运行”守卫：触发了两次的触发器，或者中途被切断又重启的运行，都不会重复做同样的工作，因为每个代理做的第一件事，就是检查今晚的报告是否已经存在并且已经收尾。

在没人盯着的时候让代理提交和推送，安全吗？

安全，靠的是它们不被允许做什么，而不是它们被要求想要什么。共同规则禁止 git add -A、commit -a、强制推送、stash、reset、checkout、clean、创建分支，以及任何会部署的脚本。每次提交都逐个点名文件，任何写操作之前都先用 git status 检查工作树，因为远端已前进而被拒绝的推送，要么用 fast-forward 的 pull 解决，要么留给人来处理。早上的复查就是当晚的提交列表，有什么不对，一次五分钟的 revert 就能撤掉。

为什么代理把 Markdown 报告写进仓库，而不是做成仪表盘？

因为报告同时也是记忆。每个代理一开始先读自己前一晚的报告，在里面找到它的运行标记（它看到的最后一次提交），并在提出任何问题之前对整个报告文件夹做一次 grep，所以上周处理过的话题不会再被提一遍。仪表盘会显示同样的数字，却什么都记不住。提交报告还给它打上了日期，正是这一点让下一晚能准确知道上一晚动过什么。

为什么七个代理中有两个是分两步、跑在两个不同模型上的团队？

因为这份工作的前后两半不是同一种工作。读 Search Console、判断网站上哪些内容变得不对、用英语和法语写文章的 SEO 步骤需要判断力，跑在 Fable 上。把这篇文章翻译成另外 18 种语言、跑 i18n 关卡和构建，是体量活，跑在 1M 上下文的 Opus 上。第一步在共享报告里写一个明确的交接小节，第二步只做这个小节列出的事。社媒团队也是同样的拆分：撰写和配图用 Fable，在 Chrome 里发布和致谢用 Opus。

一次运行在中途被切断会怎样？

报告从运行的第一分钟起就存在，里面有一行写着“运行中”，每完成一项工作就当场提交。所以一次在 21:40 被切断的运行，会留下一份不完整的报告、它的那些提交，而不会留下未跟踪的文件。汇报员会照抄这份不完整的报告，并写明这个代理被切断了。这是我们在 9 月 9 日吃了亏才学到的：两个代理在同一分钟停下，边做边提交的那个什么也没丢，另一个留下了 45 个没人能认领的已修改文件。