离开笔记本电脑：运行时速成课
12 个概念 · 从合上屏幕就停止的循环，到拥有独立住所的工作者
系统已经完成，却被困住了。你设计的循环每天早上 9 点运行。harness 会阻止危险操作，评测套件会给核心 reviewer 一个经得起质疑的分数。所有步骤都做对了，但只要合上笔记本电脑、Wi-Fi 断开或登上航班，一切就会停止。你构建过的最可靠工作者还剩一个单点故障：桌上的那台机器。
本课回答这一节最后一个未决问题：运行时决策。重点不是 agent 做什么，前三门课已经解决了这一点，而是它住在哪里、由谁维持运行：讨论的是地点与照管者，不是行为。这听起来像基础设施细节，其实不然。它决定你究竟是拥有一件优秀工具的操作者，还是拥有一名无论你是否出现都会上班的工作者。等你在公司规模上构建第一个 Digital FTE 时，还会再次回答同一个问题。先在能看清所有部件的规模上学会它。
开始前先作一个承诺：本课不会把你变成 DevOps 工程师。每次迁移都使用你已经拥有的东西：agent 编程课中的配置文件、评测课中的非交互命令、循环课中的计划，以及证明迁移成功的套件。唯一真正的新事物，是由他人替你运营的运行时。课程会如实介绍它，并把价格与取舍摆在明面上。
请先完成 信任检查器。 那门课给了你评测套件，而本课严重依赖它：迁移到新运行时正是必须重新运行套件后才能信任的变化。本课默认你已完成第 3 阶段三部曲：循环工程（节拍、主干、人工门控）、Harness 工程（五个动词、棘轮），以及评测课（金标准集、基线、漂移）。如果这些词很陌生，请先完成那三门课。本课迁移的是它们构建并验证的机器。
刚来到这里？用 2 分钟回顾应当已经掌握的内容
- 一次节拍：计划循环的一次完整运行。晨间分流循环每个工作日运行一次节拍。
- Harness：决定 agent 可以做什么、必须知道什么、如何证明工作，以及出错后怎么办的层。
- 金标准集：由实际捕获的失败构成的评测案例文件夹，每次变化都要重新运行。
- 基线：用来比较新运行的已记录通过率。低于基线就是警报。
- 漂移：你没有改动，行为却发生变化，通常是底层模型更新导致的。
- 人工门控：有风险或失败的工作交给人处理。无人监督的内容不会进入
main。 - 非交互模式：不打开交互会话就运行 agent（Claude Code 使用
claude -p，OpenCode 使用opencode run），因此脚本或计划可以驱动它。
如果这里有任何新概念，请先阅读第 3 阶段的三门课。本课只迁移那些课程已经构建并验证的机器。
用通俗语言解释关键词
| 术语 | 通俗含义 |
|---|---|
| 运行时 | 真正执行 agent 的计算机及周围软件：启动它、提供输入，并在崩溃后重启。 |
| 住所 | 本课对运行时选择的称呼：你的会话、云端计划、托管运行时或你自己的进程。 |
| 控制平面 | 运行 agent 循环的一半：会话、调度、事件流、重启。 |
| 执行平面 | 工作发生的一半：工具运行的沙箱及其接触的数据。两个平面可以由不同主体拥有。 |
| 托管权 | 谁持有并控制数据：数据在哪一方的机器上，以及谁能访问。 |
| 非交互运行 | 通过命令运行 agent，不打开交互会话。每次迁移都要经过这座桥。 |
| 计划 | 在设定时间替你启动循环的机制：Claude Code Routine、Cowork Scheduled Task 或 GitHub Actions 计划任务。 |
| 托管运行时 | 你发送 agent 定义，供应商运营控制平面，并且默认（但非必须）也运营沙箱的服务。 |
| Agent 定义 | 不运行 agent 就能描述它的一切：模型、系统提示词、工具、规则、护栏。 |
| 托管会话 | 托管运行时内的一项持续工作，拥有独立的持久状态与事件日志。 |
| 沙箱 | agent 操作实际执行的隔离环境。在某些住所里与模型相邻，在另一些住所里则彼此分开。 |
| 可移植性 | 系统迁移到另一个住所后，无需重建仍能保留多少。 |
| 锁定 | 离开一个住所的成本，以必须重建的一切衡量。可移植性越低，锁定越高。 |
| 爆炸半径 | 某个住所的一次糟糕夜晚能够影响到哪里。也就是 harness 课程的预算问题，只不过改为询问运行时。 |
| 值班告警 | 系统夜间故障时唤醒工程师的警报。「承担值班」表示你是负责处理的人。 |
| 重新建立基线 | 新住所通过现有验收门槛后，记录该运行时的通过率，同时保留旧基线用于比较和追溯。 |
| 试运行期 | 正式信任新住所前的观察期：密切监视新住所，同时保持旧住所可用。 |
这一方法从何而来
在行业历史的大部分时间里，「部署」都是开发者的词：先写代码，再把代码送到服务器。2025 年和 2026 年出现了变化。操作者，也就是没有编写 agent、只负责配置并证明它的人，突然有了值得部署的东西。拥有可衡量业绩记录的配置化循环是一项资产，而只有笔记本电脑打开时才存在的资产，存放方式很糟糕。供应商注意到了这一点。Anthropic 先为消费级工具推出云端执行，随后又为 agent 定义推出托管运行时。开源一侧则把 CI 调度器标准化为低成本替代方案。于是，运行时决策从项目末期只有工程师面对的问题，提前到达从不编写服务器的人面前。本课就是为他们准备的。（文末列出来源。）
一张图看懂思维转变
与整个三部曲一样，本课同时讲解两款工具。判断方式完全相同：选择哪个住所、何时迁移、如何证明迁移成功。机械细节的差异比此前任何一课都大，原因也很明确：一款工具的供应商为它运营云服务，另一款工具的「供应商」就是你。这个不对称不是脚注，而是运行时决策本身要处理的内容。
本课内容截至 2026 年 7 月中旬。机械层中的产品名称、端点、价格、标志变化得比本节其他课程都快。迁移前先运行 claude update 或 opencode upgrade，再查看实时文档（code.claude.com/docs、docs.claude.com、opencode.ai/docs），不要直接信任这里的名称或数字。
本课内容
| 部分 | 主题 | 学习内容 |
|---|---|---|
| 1 | 最后一个依赖 | 为什么笔记本电脑上的已验证循环是一项存放不当的资产，以及分类所有选项的问题 |
| 2 | 非交互模式是桥梁 | 每个住所共享的调用方式，以及第一次迁移：云端计划 |
| 3 | 托管运行时 | Agent 定义、环境、会话：你交出什么、得到什么、付出什么 |
| 4 | 迁移本身 | 什么会迁移、什么要重建，以及为何业绩记录必须重新赢得 |
| 5 | 选择住所 | 4 个问题、刻意混用住所，以及一次完整迁移 |
| 6 | 保持诚实 | 锁定、所有权漂移、住所无法修复的问题，以及通往模式 2 的桥梁 |
| 实况 | 内部实践 | 本书自己的循环住在哪里，以及原因 |
| 练习 | 项目 | 8 次迁移，从易到难 |
想边做边学？ 先阅读 第 5 部分，观察一次完整迁移，再回来阅读其他部分。 第一次阅读？ 按顺序阅读第 1 到第 5 部分，跳过所有标为「深入了解」的注释。阅读约需 90 分钟。随后完成项目 1 到 3，所需时间更长。完成后，循环会按计划运行，不再依赖笔记本电脑；你还能用一个数字说明它仍然有效。 第二次阅读（经历第一个月的无人值守夜晚后）：阅读第 6 部分、深入注释，以及项目 4 到 8。只有拥有不愿重建的东西后，才会真正理解锁定。 把中文当作第二语言阅读？ 课程中的每个形象表达附近都有通俗版本。「简单来说」框与上面的术语表用简短、直白的句子传达相同含义。如果某句话显得修饰性很强，附近的框会直接说明同一个意思。 两层内容的老化速度不同。记住第一层，查询第二层。阅读本课的两种方式
应当记住什么，又应当查询什么
📚 教学辅助材料
查看完整演示文稿：离开笔记本电脑：运行时速成课
第 1 部分：最后一个依赖
1. 笔记本电脑上的已验证循环是一项存放不当的资产
数一数你在三门课里构建了什么：一个在你坐下前完成晨间队列分流的循环；一个让危险错误无法发生，并把每次捕获的失败变成永久规则的 harness；一套给核心 reviewer 一个可辩护分数的评测。粗略地说，这是一名初级同事，拥有书面岗位说明、主管和绩效记录。
再数一数它依赖什么：笔记本电脑保持打开；会话处于登录状态；机器在早上 9 点保持唤醒、有电、有网络。任何一项缺失，节拍就会悄无声息地跳过。循环课已经讲过代价：队列变长、升级堆积，而周五合上的屏幕要由周一的你来买单。
还可以说得更尖锐。三部曲教你逐一移除单点故障：创作者与检查者分离，移除了唯一未经复核的意见；harness 移除了唯一不受约束的动作；评测移除了唯一未经检查的检查者。还剩一个，就是你。不是人工门控理应保留的判断，而是你的硬件。系统已经比运行它的机器更可靠，这说明它已经长大，不再适合原来的住所。
你训练出一名优秀工作者，却要求他只能在你家的客厅工作，而且必须等你在家。工作者没有问题，安排才是问题。
2. 一个问题分类所有选项：谁运营循环，工作在哪里执行？
寻找新住所时，选项会迅速增多，术语也变得喧闹：云会话、托管 agent、托管运行时、SDK、Serverless、编排。用一个问题穿透所有噪声。注意它有两半：谁运营 agent 循环，工作又在哪里执行？
这两半的名称值得现在掌握，因为现代运行时可以把它们分开。控制平面就是循环本身：启动会话、向模型提供输入、流式传输事件，并在凌晨 3 点重启崩溃的工作。执行平面是动作落地的地方：工具运行的沙箱，以及工具接触的数据。在笔记本电脑上，两者共用一台机器，所以从未需要区分。接下来的住所可以把它们分开，其中最有意思的住所会刻意这样做。
每个选项都是下面 4 个住所之一，由两个平面分类，前面的图已经展示了它们：
- 住所 1：你的会话。 你拥有一切：配置、运行时、可用性。三部曲在这里发生，它仍然适合构建与证明，却不适合成为长期依赖。
- 住所 2：云端计划。 你仍拥有配置，包括相同的规则文件、技能和子 agent，但时钟移到了他人的计算机。Claude Code Routine 在 Anthropic 云端运行循环；GitHub Actions 计划任务在 GitHub runner 上运行 OpenCode 循环。这是最小的迁移，却能带来最大的即时收益。
- 住所 3：托管运行时。 你交出 agent 的定义，包括模型、提示词、工具和护栏，供应商服务运营控制平面：循环、会话、崩溃恢复。执行平面可以选择：默认使用供应商的云沙箱；若托管权有要求，则使用你控制的基础设施上的沙箱。你不再运营循环，但仍运营周围的业务。
- 住所 4：你自己的进程。 Harness 变成你所编写软件中的一个库，运行在你维护的服务器上。你拥有一切，也承担全部责任。这就是 Agent SDK，也是模式 2 的领域。本课只会带你走到门口，不会穿过去。
把两个平面铺开来看。住所 3 实际上有两种，因此表中有 5 行：
| 住所 | 控制平面 | 执行平面 | 故障时唤醒谁 |
|---|---|---|---|
| 1 · 你的会话 | 你 | 你的笔记本电脑 | 你 |
| 2 · 云端计划 | 你，通过调度器 | 云端 runner | 双方分担 |
| 3 · 托管，云沙箱 | 供应商 | 供应商 | 基础设施归他们，业务结果归你 |
| 3 · 托管，自托管沙箱 | 供应商 | 你 | 按平面拆分 |
| 4 · 你自己的进程 | 你 | 你 | 有意地由你负责 |
看看这个问题真正讨论的是什么。它并不技术化，而是每家公司面对每项职能时都会提出的问题：我们自己做，还是付钱请别人做？你早就会思考这个问题。本课只是把同样的思路应用到 agent 下方的计算机。
这里有 4 个住所，不是一架必须向上爬的梯子：笔记本电脑（拥有一切）、计划（拥有配置）、托管运行时（拥有定义，沙箱可在对方云端，也可因托管权要求留在你的基础设施上），以及自己的服务器（在产品规模上有意地再次拥有一切）。课程反复强调：只拥有必须拥有的，不要因为想拥有就全部接手。大多数读者会留在前 3 个住所，而且常常让多个住所同时运行，每个循环选择一个。住所 4 是模式 2 的起点。
拉合尔的 Ayesha 在自己的笔记本电脑上运行自由职业发票循环。限电让她大多数晚上都会断电，她刚签下一位客户，对方要求每天当地时间 18:00 准时发出发票，绝不能失败。她首先需要哪个住所？为什么住所 3 今天超出了她的需要？ 住所 2，也就是云端计划。她的问题只有时钟：循环已经验证，配置可以工作，但本地机器无法保证 18:00。把计划迁移到云端 runner，可以把停电从关键路径移除，除了新住所本身之外，没有其他东西需要重新证明。不过客户的「绝不能失败」需要诚实说明：大多数调度器，包括 CI 计划，都承诺「大约在某时」而不是「精确在某时」。负载高时会延迟，偶尔还会遗漏运行。因此，「绝不失败」不是调度器功能，而是一套最低无人值守工具：检测遗漏、保证重试不会重复发送同一张发票，并在 18:30 前没有成功记录时告警。住所 3 解决的是她尚未遇到的问题，比如服务其他用户、跨长任务保留会话、规模化运营，并会为此收费。第 5 部分的 4 个问题会把它变成明确测试：用户是谁？今天的用户就是 Ayesha。住所 2 加上最低工具就足够。显示答案
第 2 部分：非交互模式是桥梁
3. 每个住所都使用非交互模式
让本课每次迁移成为可能的事实很安静：你已经在评测课中走过这座桥，只是当时没人告诉你它是一座桥。评测 runner 调用 claude -p 和 opencode run，把 agent 当作命令，而不是对话。没有打开的窗口，也没有需要看守的会话：提示词进入，工作发生，结果输出，进程结束。
这就是非交互模式，也是整门课的基础。任何能执行命令的东西，现在都能运行你的 agent。 Shell 脚本可以，cron 任务可以，CI runner 可以，云端调度器也可以。从住所 2 开始，每个住所底层都只是在回答：「谁的计算机执行非交互命令，又按照谁的时钟执行？」
评测课里的机械部分保持不变：Claude Code 使用 --output-format json 生成机器可读输出，OpenCode 使用 JSON 事件流，而 reviewer 把结论写入文件，避免让任何人解析自然语言。现在没有人观察，需要增加一个习惯：非交互运行必须在失败时发出响亮告警。 会话中你能看到错误；runner 上无人检查的退出码，就是一次悄无声息地没有发生的节拍，也就是概念 1 的失败在云端重演。本课的每个非交互 wrapper 都会检查退出码，并在失败时发出明显告警，也就是循环课的第 5 个动词。沉默必须表示成功，而且这是你主动执行的规则，不是继承来的默认值。
交互模式是你与 agent 交谈。非交互模式则由任何人或系统（脚本、计划、服务器）向 agent 递交一张纸条，再收回结果。只要 agent 能接收纸条，它就能在纸条送得到的任何地方工作。
4. 住所 2，云端计划：先把时钟移出去
第一次迁移有意选择最小变化：保留已经构建的一切，只移动时钟。规则文件、技能、子 agent、hook 等配置保持原样，改变的只是由谁启动节拍。
供应商路线就是循环课承诺的计划，而且保留了名称：Routine。在 Claude Code 中，/schedule 命令（别名 /routines）通过对话创建 Routine。保存的配置包含提示词、仓库、连接器和环境。无论笔记本电脑是否打开，它都会在 Anthropic 管理的云基础设施上运行。你那个连接仓库的循环——「每个工作日早上 9 点运行晨间分流技能，把风险高于中等的工作升级」——会直接变成这样的配置。
实时文档给出了 3 条应当很熟悉的诚实说明：
- Routines 处于研究预览阶段。 这是机械层中最机械的部分，依赖前必须核实。
- 计划运行按设计可能在整点后几分钟才开始，文档称为 stagger。真实承诺是「大约早上 9 点」。这是本课对所有调度器的判断，由供应商自己说了出来。
- 绿色状态只表示会话退出时没有基础设施错误。 它不表示任务成功。概念 3 的响亮失败规则仍由你在提示词及其检查中执行。
有一个陷阱的名字听起来很友好。在桌面应用中选择 Local，创建的是在你机器上运行的 Desktop 计划任务。那只是带计时器的住所 1，根本没有迁移。
在 Claude Cowork 中，知识工作的同类功能叫 Scheduled Task。描述一次，它就会按照计划在远端使用连接器、技能和 plugin 运行。结果会一直等到你查看。文档也给出一个限制：需要本地文件或桌面应用的任务会在本地运行，这会悄悄地重新依赖笔记本电脑。按照循环接触的内容选择：仓库工作使用 Claude Code Routine；连接器与文档工作使用 Cowork Scheduled Task。无论哪一种，笔记本电脑剩下的唯一职责都是让你阅读结果。
还有两条机械层的诚实说明。第一，云端 runner 不是你的机器。它能访问哪些仓库、连接器和凭据，需要配置，而不是自动继承。因此，第一次 Routine 运行也在发现新住所能看到什么。第二，harness 会「按配置」迁移，但必须验证它确实迁移了。权限墙和 hook 都是文件，而文件只保护加载它们的运行。请查阅实时文档，确认 Routines 如何取得配置，并把概念 8 的试运行期视为不可协商。
对于连接仓库的循环，还有一种与供应商无关的住所 2，循环课已经构建过：带 schedule: 触发器的 GitHub Actions 工作流。它在 CI runner 上以非交互方式执行 claude -p，并检出仓库配置。住所相同，只是向另一家公司租用。GitHub 也公开提醒：计划工作流按尽力而为原则运行，可能在高负载时延迟，偶尔会遗漏，而且只能从默认分支运行。对于晨间循环，真实契约是「大约早上 9 点」。严格截止时间需要下方的最低无人值守工具，甚至更可靠的调度器。
OpenCode 没有第一方托管控制平面，本课不会假装它存在，因为诚实版本更有教育意义。使用 OpenCode 时，住所 2 是由你选择的调度器。连接仓库的循环使用循环课中的 GitHub Actions 模式：运行 opencode run，由 schedule: 触发器启动，同时检出 .opencode/ 配置。其他工作可以使用任何能运行 cron 的机器：每月几美元的云服务器、家中始终开机的设备，或任意计划 runner。
你得到的是工具从一开始就承诺的内容：你与循环之间没有供应商，模型和提供商都由你选择。你也接受「现在你就是供应商」：runner 的可用性、凭据和更新都由你管理。仓库循环运行在 Actions 上时，这份负担很小，大部分由 GitHub 承担。若使用桌下的一台小计算机，则只是用更多工作重建住所 1。因此，Actions 版本是本课在 OpenCode 一侧的默认建议。
两个标签页之间的差异就是课程内容，不是缺陷：开放工具让整个运行时决策一览无余。你会在 个人 Agent Harness 一节再次遇到同样的取舍，那里拥有运行时正是核心目标。
无论选择哪种版本，成功定义都相同且可以测量：笔记本电脑合上后，至少完成一个完整运营周期和 10 次成功节拍，沉默表示处于基线。 不能只说「它在云端运行过一次」，因为评测课已经说明一次绿色运行值多少；也不能把它叫作长期可用性证明。准确的名称是初步运营证据，风险更高或频率更低的循环需要更大样本。每个计划节拍都要对照基线检查，并刻意测试一次告警。这才是已经入住的住所 2。
最低无人值守工具。 本课承诺不把你变成 DevOps 工程师，因此用一张表而不是一整套学科来兑现承诺。没人观察运行后，6 项控制缺一不可。每一项都很小，也都因为缺失时出现过著名故障而存在。
| 控制 | 规则 | 防止的故障 |
|---|---|---|
| 幂等性 | 重试的节拍必须可以安全重复 | 发票发送两次、工单创建两次 |
| 遗漏运行检测 | 由第二个系统发现第一个系统根本没有启动 | 从未运行的进程无法报告自己的缺席 |
| 并发锁 | 一次只运行一个节拍；若 8 点任务仍在运行，9 点任务就等待 | 两个 agent 同时编辑同一队列的文件 |
| 凭据纪律 | 使用限定范围、最小权限、定期轮换的服务凭据，绝不用个人登录 | 云端 runner 持有你的全部身份 |
| 时间语义 | 写明时区，提前决定夏令时与补跑行为 | 每年两次偏移 1 小时的 18 点发票 |
| 成本与执行限制 | 设置每个节拍的最长时长、轮数、重试和费用，以及终止行为 | 一次游荡运行在一夜耗掉整月预算 |
这套工具是住所 2 的入住费用，而且会随你迁移：后续每个住所都要求相同的 6 项控制，只是有时表现为服务设置，而不是脚本。第 5 部分的第 4 个问题设定速度限制时，「最低安全门槛」就是这张表。
第一次迁移是最小迁移。保留全部设置，只改变启动循环的东西：不再由你打开笔记本电脑，而是由云端计划按时钟启动。现在没有人观察，所以增加 6 条小型安全规则，确保失败不会悄无声息。
深入了解：计划迁移了，人工门控没有
迁移中藏着一个细微陷阱。在笔记本电脑上，人工门控有一个便利条件：你就在那里。循环升级后，升级会落到你正在看的窗口。住所 2 不管你是否接近屏幕都会运行，升级可能在无人看到时堆积。无人看到的升级就是被延迟的决策，有时等同于默认做出了决策。因此，迁移到住所 2 会强迫你升级一项本地机器从未要求的能力：升级渠道必须能找到你，而不是找到你的桌面。可以是一条消息、一次提及，或一个写有你名字的 issue。循环课的「发出响亮告警」必须指向你真正出现的地方。门没有迁移，门铃必须迁移。
第一次云端计划节拍显示绿色。一名同事说迁移已经完成。根据评测课对一次运行的判断，以及本部分对沉默的要求，在诚实地说「完成」之前还缺哪两件事？ 第一，一次绿色节拍只是关于一次运行的事实，不是关于住所的事实。迁移需要由一个比率证明，因此成功门槛是完整运营周期，以及至少 10 次与基线比较的节拍，而不是第一晚。第二，响亮失败还没有经过测试。在刻意植入一次失败，并确认告警确实到达你之前，沉默有两种含义：可能处于基线，也可能 runner 根本没启动，连抱怨的东西都不存在。完成意味着一周保持绿色、告警经过测试、升级到达你真正查看的地方。显示答案
第 3 部分：托管运行时
5. 住所 3：你发送定义，服务运行工作者
住所 2 移动了时钟。住所 3 移动控制平面；只有在你选择时，执行平面才会一起移动。托管运行时的契约简单却彻底：你描述 agent，包括模型、系统提示词、工具、连接器和护栏，由服务负责运营。循环、会话状态、重试、凌晨 3 点的崩溃恢复，都在供应商的计算机上运行，由供应商的工程师负责；默认情况下，沙箱也在那里。你不再运营 agent 循环，仍需运营周围的一切：调用计划、凭据、事件消费、升级、费用限制，以及业务结果出错后的事故处理。你编写定义，也仍然拥有业务系统。
写作本课时，具体实例是 Claude Managed Agents，它于 2026 年 4 月进入公开测试。即使细节会变化，它的形态仍值得学习，因为形态就是核心思想。你需要创建 3 个对象：
- 一个 agent：定义，包括模型、提示词、工具、护栏。规则文件与 reviewer 提示词转换为服务可以保存的形式。
- 一个环境：agent 动作执行的隔离空间。它把 harness 课程的围栏从本地配置文件变成服务端对象。这就是执行平面，并且可以选择：默认使用供应商基础设施上的云沙箱；若数据不能离开你的托管范围，则使用你控制的基础设施上的自托管沙箱。无论哪一种，围栏都由你设置。供应商自己的生产指南也要求采用最小权限网络和明确的允许主机列表，这应当听起来与 harness 课程完全一致。
- 一个会话：一项持续工作，拥有独立的持久状态和只追加事件日志。它相当于循环课的节拍，却能暂停、恢复并持续数天，因为下方不再需要一台始终打开的笔记本电脑。
应用（在本课规模上可以只是脚本）通过 API 与这些对象通信，并以流的形式接收事件。最重要的架构细节是：概念 2 中的两个平面在这里变得可见，也可以分离。负责思考的模型与负责行动的沙箱是不同部件，由服务连接。此前课程中的版本是耦合的：agent 与工具住在同一台机器的同一进程中。解耦形态让其他人能够规模化运营行动部分，也是生产 agent 架构正在趋向的形态。记住它：到模式 2 时，它会作为由你亲自选择的设计重新出现。
供应商通常轻描淡写地说明两个边界，这里直接说清楚。托管控制平面与供应商绑定：这里运行 Claude，由 Anthropic 运营。沙箱可以位于你的基础设施上，但循环、会话和模型路径不能。下方 OpenCode 标签页会如实说明这对开源一侧意味着什么。另外，托管运行时并不是「SDK 加托管」：Agent SDK 与 Managed Agents 是不同产品，为其中一个编写的代码不能部署到另一个。跨越边界的不是代码。第 4 部分会说明真正能迁移的东西。
把你拥有的内容翻译为服务所保存的对象：循环的岗位说明变成 agent 提示词；权限墙与拒绝规则变成环境配置；每个计划节拍变成脚本按照住所 2 的计划，以非交互方式打开的会话。端点、SDK 调用形式和测试版请求头是整本书最机械的层。它们只有数周历史，而且每月都会变化。请从 docs.claude.com 的实时文档获取全部细节。任何超过一个季度的教程，包括本课，都只能用来理解形态，不能当作参考。
OpenCode 一侧没有第一方住所 3，本课不会伪造一个。不过要准确理解缺少的是什么。OpenCode 完全可以远程运行：opencode serve 提供非交互服务器进程，客户端可以连接远程实例，整个系统也能容器化到任意托管计算服务上。缺少的是第一方托管控制平面，即由供应商把循环、会话和恢复作为服务运营。采用可互换模型的开放工具没有单一供应商来承担它。因此，诚实的等价方案要么是加固的住所 2（调度器加最低工具，你充当供应商），要么是你编写并运营的服务器进程。认真运营这种进程时，它属于住所 4 和模式 2。作为交换，你得到任何托管控制平面都无法出售的东西：你与循环之间没有任何中间层。哪种取舍正确，不是工具问题，而是第 5 部分的问题。
在住所 1 和 2，你雇用工作者，也维护其办公室。在住所 3，你编写岗位说明和办公室规则，由楼宇服务公司运营电力、安全、夜班和维修。你通过报告访问，而不是从前门进去。
6. 你得到什么、交出什么、支付什么
需要从两面诚实权衡托管契约。
你得到什么。 那些从未想亲自承担的运营工作：由构建 harness 的团队维护沙箱；能从崩溃和多日任务中恢复的会话状态；由模型供应商针对当前模型调优的上下文管理和提示词缓存。这减少了 harness 课程要求手工处理的模型与运行时兼容工作。也要准确说明它买不到什么：它无法解决行为漂移；模型与 harness 同时更新时，由于两个对象一起变化，回归反而可能更难归因。因此，评测课中的计划基线运行仍要完整执行。基础设施值班归他们，凌晨 3 点的重启按契约不再是你的问题。业务结果的值班仍归你：工作即使按时在他们的机器上完成，只要结果错误，升级仍由你负责。
你交出什么。 从轻到重有 3 项。可见性：你读取服务发出的事件日志，而不是机器本身。深度 3 轨迹评估不仅检查答案，还检查 agent 采取的步骤，现在取决于日志包含什么。托管权：提示词、fixture 和工作输入会在你无法控制的基础设施上执行。对某些数据、职业和监管环境而言，这一事实本身就决定答案，任何功能列表都无法改变。可移植性：你的定义采用该供应商的形式；离开时要重写，而不是原样移动。这是第 6 部分的主题。
你支付什么。 一种新的账单类型，比当前数字更重要。住所 1 和 2 的成本是 token 加 runner；住所 3 还为运行时本身增加用量表。写作本课时，活跃会话工作约为每小时 8 美分，空闲免费，此外还有 token 和网络搜索等计量项目。由此产生两个结果。短暂思考、长期休眠的会话几乎无需维持成本，因此长生命周期会话才负担得起。游荡循环，也就是评测课要求在深度 3 识别的问题，现在不仅浪费时间，还会花钱。评测套件于是成为成本控制，而不只是质量门槛。数字会漂移，请查看实时价格页。形态才是课程内容。
托管运行时是一项交换。供应商替你处理从未想负责的运营：崩溃、重启、保持沙箱健康。你交出一部分可见性、数据托管权和轻松迁移的能力。账单也多出一种：按实际工作小时付费，空闲免费，所以游荡循环现在浪费的不只是时间，还有金钱。
深入了解：供应商更新会同时带来帮助和伤害
评测课中的漂移故事形态固定：模型在不变的 harness 下移动，基线捕获倾斜。住所 3 改变了形态，却没有消除问题。现在模型与 harness 按供应商的计划一起移动，由供应商工程师共同调优。通常比手工配置少一些小问题，但偶尔会在你没有改动任何文件时改变依赖的行为。防御方式完全不变：计划运行完整集合、提交基线、下降时发出响亮告警。托管运行时移除运营负担，不会移除测量负担。本书没有任何东西会消除这项责任。
一名同事认为：「托管运行时会话按小时计量，因此一定比按自己的计划运行循环更贵。」这个说法遗漏了哪两点？一点关于计量表，另一点关于它替代的内容。 计量表只计算活跃运行时间，空闲免费。每次节拍只工作几分钟、其余时间休眠的会话，在运行时一项上几乎不产生费用，因此「每小时」并不等于「存在的每小时」。它替代的成本也不能只算 token。住所 2 的价格一直包括 token、runner，以及你配置、更新和在失败时被叫醒的时间。诚实比较必须包括操作者的总成本。业余循环通常由住所 2 轻松胜出；服务团队的 10 个循环则不同，因为值班本身也有价格。因此，成本是第 5 部分决策的第 4 项输入，不是第 1 项。显示答案
第 4 部分：迁移本身
7. 行李箱测试：纪律会迁移，机械部分不会
本课把每次住所迁移归结为一个打包问题：什么放进行李箱，什么要在抵达后重建？
三部曲真正教授的一切都会迁移。 规范说明工作是什么、怎样才算完成。评分标准包含你费力制作的锚点。金标准集包含每个案例的 origin 行及其基线。棘轮日志把捕获的每次失败变成永久测试案例。还有创作者与检查者分离、类别门槛、人工门控。观察共同点：这些都不是软件，而是写下来的决策。所以它们能够迁移，因为决策不关心由哪台计算机执行。
带有供应商或机器名称的一切都不会迁移。 标志、输出格式、文件路径、会话状态、针对某个运行时 API 编写的代码，以及概念 6 说明会改变形态而不只是数值的成本假设。概念 5 中 SDK 与托管运行时的边界，是这条规则最清楚的例子。
这也是锁定问题的真正答案：你的可移植资产是纪律层，而可移植性需要维护，并非天然拥有。 规则只存在于供应商设置而不在仓库中、评测案例只存在于服务内部、门槛已经决定却没有写下，每一种情况都把重量从行李箱搬到房屋固定设施。保持可迁移只需要一个习惯：仓库保存真相，每个住所都由它配置。
搬家时会带走属于自己的东西，把固定在墙上的灯留下。规范、评分标准、案例和门槛属于你，会放进行李箱；标志、路径和 API 形态固定在旧房子里，必须留下。希望保持可迁移的人，即使住在房子里，也会把贵重物品留在行李箱中。
8. 信任需要重新赢得，不能转移
图右侧的最后一项值得单独成为一个概念，因为迁移者最想跳过它。35/36 衡量的是一个系统：当前配置、harness、模型、机器和可访问工具。迁移一次改变了其中多个对象。新住所运行的系统与原系统关系很近，但旧分数属于一个不再存在的系统，不能直接继承。它仍是比较目标：新住所必须达到的标准，而不是免费获得的标签。
因此，到达协议就是有意重放评测课。迁移是回归纪律拦截过的最大一次「变化」，所以步骤应当熟悉：
- 首先在新住所运行完整金标准集。 不是冒烟集，而是完整集合。Runner 是非交互的，新住所也使用非交互模式；这本来就应当能够工作，所以概念 3 才把它称为桥梁。
- 先按类别阅读失败，再看数量。 与评测课概念 10 相同。一个语气案例下降是小问题；在可访问表面变化的新住所中，一个抵抗隐藏恶意指令的注入案例下降就是紧急事件。必须先修复评分标准或围栏，再迁入其他内容。
- 保持门槛，再记录带住所标签的新基线。 不要删除旧基线，它是比较目标；位置改变不会让它所执行的发布门槛移动。新住所必须通过现有门槛。调查每个有意义的差异后，才能记录运行时专属基线，包括
recorded日期、模型、评分标准版本和运行时。把两个数字及差异解释都保留在历史中。环境基线会变，验收标准不能悄悄移动。 - 依赖前先试运行。 固定一个周期：至少一个完整运营周期和 10 次成功节拍；风险更高或频率更低的循环需要更长时间。期间保留旧住所，每天对照新基线检查节拍。把结果称为初步运营证据，不要称为可用性证明；5 个安静的工作日说明不了多少。只有新业绩记录，而不是旧声誉，证明迁移完成后，才算结束。
旧分数是在旧设置上测得的，迁移改变了设置，因此分数不会随你而来。要在新住所重新赢得它：第一天运行全部测试，查看失败内容与失败类型，保持原来的通过门槛，记录带新住所名称的分数，再观察一个试运行期后才开始信任。
还要给出一条与 harness 课程那次糟糕夜晚相似的警告。新住所拥有新的访问范围：云端 runner 看到的凭据与笔记本电脑不同；托管环境暴露的工具与本地配置不同。注入和爆炸半径案例是针对旧范围编写的。试运行结束前，遍历金标准集中的困难案例，并逐一询问：这个案例防范的失败，从这里看是否呈现不同形态？ 通常不会。一旦答案是会，这个问题就值得加入今后的每次迁移。
迁移到住所 2 后，第一次完整运行得到 33/36，旧基线是 35/36：一个干净修复案例出现波动，重跑后转绿；剩下两次失败来自同一案例，一个 fixture 通过旧笔记本电脑的绝对路径读取文件。用本概念与行李箱测试分类这 3 次失败。 波动属于噪声，按照评测课的重跑策略记录，但不作为门槛。重复失败根本不是 agent 回归，而是行李箱错误：绝对文件路径属于机械部分，却意外装进 fixture 一起迁移。应当修复案例，改用相对路径，而不是修复系统。然后按照评测课规则，在同一个 commit 中重新建立基线，因为集合发生了变化。门槛本身不移动，修复必须在历史中可见，避免真实回归藏在「修复套件」里。诚实结论是新住所处于基线；迁移暴露了套件自己的可移植性 bug，这正是第一次在新住所运行应当捕获的问题。显示答案
第 5 部分：选择住所
9. 4 个问题
整门课可以压缩成按顺序提出的 4 个问题。前 3 个选择住所，第 4 个决定何时入住。
问题 1：用户是谁？ 如果诚实答案只有你，可以提前停止：住所 2 几乎总是需求上限。大多数读者在大多数时候都如此，无需道歉。答案一旦包含其他人，例如消费结果的团队、客户或顾客，循环就必须在你缺席、休假或未登录时继续运行，问题随即进入问题 2。
问题 2：必须拥有什么？ 不是你想拥有什么，而是真正必须拥有什么。两个平面让答案精确分成 3 类。没有必须拥有的内容：完全托管运行时适合，让供应商承担基础设施值班并非妥协，而是正确花钱。只需拥有执行与数据平面，也就是工作及其接触的数据，而不需要拥有循环：住所 3 配合自托管沙箱恰好满足要求，你保留托管权并租用运营。还必须拥有控制平面：若提示词、会话、模型路径或 agent 所在产品界面都必须由你拥有，就需要越过住所 3，选择自有运行时、SDK 路线与模式 2。
问题 3：是否有人等待答案？ 分流、报告、流水线等计划与后台工作很适合计划和托管会话。有人在屏幕前等待会改变要求，却不会自动改变所有者。这时需要启动可预测、支持流式响应、取消和并发的服务运行时。托管服务可能比自营服务更擅长这些能力，而拥有运行时本身并不会自动获得它们，因为任何运行时都无法消除模型思考时间。所有权仍由问题 2 决定。问题 3 只告诉你服务是一种不同的工作形态，它属于模式 2；目前认识到这一点就够了。
问题 4：糟糕夜晚的代价有多大？ 这是 harness 课程的爆炸半径预算问题，最后再问一次。半径低：通过最低无人值守工具，尽早迁移，在试运行中加固其余部分。半径高：新住所在首次无人值守前必须通过工具和完整套件，所有注入类别全部达标。问题 4 从不改变目的地，只设置速度限制。
按顺序提出 4 个问题：只有你使用，还是其他人也使用？必须拥有什么：什么都不需要、只需拥有工作，还是整个循环？是否有人在屏幕前等待答案？糟糕夜晚的代价有多大？前 3 个选择住所，最后一个只决定迁移速度。
10. 一次完整迁移，以及有意混合住所
用本节从第二门课开始一直携带的晨间分流循环，完整运行一次课程。
回答问题。 问题 1：用户是你，再加上从上个月开始阅读分流报告的两名同事。「再加上」就是触发点，循环必须摆脱你的登录。问题 2：没有必须拥有的东西；仓库已经在 GitHub 上，队列内容也没有托管限制。问题 3：没人等待屏幕结果，节拍在人们坐下前运行。结论是 住所 2 的 GitHub Actions 版本，因为循环连接仓库，而评测门已在同一个 CI 中。问题 4：糟糕夜晚会创建错误分类标签和一次错误升级，令人烦恼但可恢复，半径低。速度限制是最低工具通过后立即迁移，试运行 2 周；循环在工作日运行，10 次节拍是底线。
执行迁移。 周一加入工作流文件：schedule: 触发器、非交互调用、从仓库检出的配置、退出码检查，以及连接到你真正阅读渠道的失败告警。再加入 3 项最便宜的控制：并发锁、遗漏节拍检测和每节拍限制。行李箱检查发现一个 fixture 保存了笔记本电脑路径；修复后，在同一 commit 重新建立集合基线。新住所首次完整运行全部类别达标，提交标为 runtime: actions 的新基线。此后 2 周，屏幕保持合上，节拍按计划运行，沉默表示基线；中途还故意植入一次失败，因为从未听过的告警只是传闻。第 10 次节拍通过后，试运行结束，删除笔记本电脑计划。系统现在拥有两份业绩记录，更新的那份才有效。
混合住所。 完整系统有意不只使用一个住所。循环住在住所 2，评测门按照评测课要求住在同一个 CI。季度清理、大型重构等一次性重活仍在住所 1 交互运行，方便你观察。如果两名同事成长为客户，问题 1 会重新触发，住所 3 只为服务路径进入讨论。住所不是永久忠诚，而是每个循环对 4 个问题的回答。健康系统通常横跨两三个住所。概念 7 的一句话防止混合变成混乱：仓库保存真相，每个住所都由它配置。
住所不是永久定居点，而是每个循环根据 4 个问题做出的选择。真实系统往往同时使用两三个住所：日常循环按计划运行，重型一次性工作留在笔记本电脑上观察。一条规则避免混乱：仓库保存真相，每个住所都从仓库建立。
把 4 个问题重新应用到 Ayesha 的发票循环。现在它直接服务 5 名客户，其中一家银行要求客户数据留在 Ayesha 公司控制的基础设施上。每个问题会得到什么答案？令人不舒服却诚实的结论是什么？ 问题 1：用户是客户，因此不能停在住所 1，也不能依赖 runner 偶尔正常工作。问题 2 决定答案：银行的必须条件针对执行与数据平面，也就是工作在哪里运行、接触什么。托管控制平面配合公司基础设施上的自托管沙箱，可能恰好满足要求：客户数据留在公司托管范围内，供应商运营循环。是否足够由银行决定，不由 Ayesha 决定。若必须条件延伸到控制平面，包括提示词、会话和模型路径，则只有自有运行时符合。问题 3：发票是计划后台工作，没有延迟压力。问题 4：向真实客户发送错误发票，爆炸半径高；首次无人值守前必须通过最低工具和完整套件。诚实结论是没有单一住所适合一切。银行路线要么是拥有执行平面的住所 3，要么在要求更深时采用 SDK。Ayesha 已走到操作者能够独自配置的边缘，本书把这条边缘称为模式 2。显示答案
第 6 部分：保持诚实
11. 锁定是一种速率，所有权也会漂移
第一个住所之后，两个缓慢失败会跟随每个住所，而且都不会主动宣告。
锁定是一种速率，不是一次事件。 没有人会在第一天签字放弃可移植性。它会泄漏：一条规则在供应商设置中修改，却没有同步回仓库；一个评测案例只添加在服务控制台；一个门槛在仪表盘里重新商定，却没有 commit。每一次都把一个物件悄悄从行李箱移到固定设施。衡量当前锁定只需一个直接问题：如果这个住所本季度消失，迁移要花多少成本？ 防御方式仍是那句话：仓库保存真相。按照评测课第 6 部分审计 Goodhart 陷阱的方式，定期审计它，并采用留出集思维。每季度练习「只用仓库配置一个全新住所」，就是可移植性的留出集。若无法完成，你就在泄漏只有一个物件宽时发现了它。
即使没有泄漏，所有权也会漂移。 更微妙的失败在你身上，不在文件中。一个安静运行数月的住所会在脑中得到小小晋升：从「这个系统经过测量」变成「这个系统没问题」。评测课给机械版本命了名：模型漂移后，judge 的 95 分含义改变。运行时版本发生在人身上：基线仍绿、计划仍安静，你却慢慢不再阅读分类报告、不再重放校准，也不在供应商向环境加入新能力时提出概念 8 的新访问范围问题。这套纪律里没有一步叫「然后它会自行维护」。计划运行观察系统；提醒你阅读报告的日历则观察你。
两个问题会缓慢爬来。第一，除非一切都保存在仓库中，否则离开住所会随着一个个小设置变得更难。第二，一个安静运行数月的住所会让你停止检查。两者的解决方案相同：让仓库成为唯一真相来源，并设置日历提醒，真正阅读报告。
12. 任何住所都无法修复的事情，以及下一步
像本节其他课程一样，在诚实边界结束。更好的住所会改变 agent 何时工作、由谁保持运行，以及凌晨 3 点发生什么。它不会改变 agent 工作得有多好。薄弱规范在 Anthropic 云端仍然薄弱；未校准的 judge 即使每小时只要 8 美分也仍未校准；缺失案例在世界上每个 runner 都会缺失。运行时决策必须是本节最后一门课，因为若放在最前面就毫无价值：它迁移的一切必须先值得迁移。若本课中的迁移显得容易，是因为真正困难的工作已经由三部曲完成。迁移只是行李箱。
更好的住所改变 agent 何时运行、由谁维持，以及凌晨 3 点由谁处理故障。它不会让 agent 更聪明或更正确。优秀工作来自已经构建的规范、harness 和测试。住所只决定谁让它继续运行。
本节的弧线现在完整了。你学会了驾驶通用 agent，用规范指挥它，委派循环、加固 harness、测量检查器，最后把整个系统安置在合适的地方。最终拥有的是本书从第一页就在组装的东西：一项经过规范、保护、测量并且有住所的工作单元。把它与本书词汇对应起来，下一扇门自然打开：如果这个单元为其他人构建，并拥有自有运行时、产品界面和价格，它就叫作 Digital FTE。原来你一直在运营规模上制造它。
本节有 3 扇出口，4 个问题已经说明哪扇属于你。个人 Agent Harness 适合问题 2 在个人规模上回答「必须拥有」的读者：你的工作者、基础设施和完整运行时决策全部亲自掌握。模式 1：解决问题 让你使用现有系统立即解决真实问题，是大多数读者的正确下一步。模式 2：制造 则完成本课预告的全部承诺：通过 Agent SDK 打开住所 4；让解耦架构从继承来的形态变成由你做出的设计；再由 评测驱动开发课程 扩展刚刚监督迁移的套件。
本节最后的想法：循环给 agent 时间，harness 给它限制，评测给它业绩记录，本课则给工作者最后需要的东西：一个不属于你的地址。再用一句直白话防止误解终点：独立地址只是本节的最后要求，不是生产运营的最后要求。面向用户的产品仍需要所有者、升级路径、保留策略、连续性，以及有权关闭它的人；模式 2 会教授这些内容。不过，出现、工作、证明工作、独立生活，一直都是完整的岗位说明。对 agent 如此，对人也不例外。
一名读者完成课程后说：「所以终点就是住所 3，一切最终都会托管。」使用问题 1 到 4、概念 10 的混合方式和上面的边界，写出两句话纠正他。 不存在终点住所：4 个问题针对每个循环提出，健康系统有意横跨多个住所，在 1 中构建、在 2 中调度，并在「必须」条件要求时从 3 或自有运行时提供服务。任何住所都不会升级 agent 本身：质量存在于会迁移的规范、harness 和套件中。住所只决定谁负责让灯继续亮着。显示答案
本书自己的循环住在哪里（内部实践）
在本课出现前，本课的决策就已经应用到本书。书籍 review 循环拥有 reviewer 评分标准、95 分门槛和低于门槛不得合并的规则，问题 1 的答案是「一个团队」：作者，以及提交 issue 的读者。因此，它设计的住所是 2，即本书仓库上的 CI，也是本课教授的 GitHub Actions 版本。循环连接仓库，评测门也应当位于合并门旁边。新课程起草、图形流水线运行等重型交互工作仍在住所 1，由人观察。写作本课时，住所 3 仍是开放问题，本书完全按照第 5 部分处理：没有「必须拥有」的要求迫使服务路径，也没有延迟压力，所以托管选项要等问题 1 的答案再次扩大。仓库保存真相，住所只是细节。你现在读到的正是这套安排的产物。
🚀 项目
8 次迁移，从易到难。仍然遵循两条规则：使用一次性仓库，并且亲自植入失败。住所是否可靠，只能由它熬过的糟糕夜晚证明。 难度：简单 · 使用：概念 3。 构建。 用脚本包装循环节拍：非交互调用、检查退出码，并让失败在你真正查看的地方发出告警。 完成标准： 断开网络后运行会产生告警，而不是沉默。课程中的其他内容要想安全，沉默必须先表示成功。 难度：简单到中等 · 使用：概念 4。 构建。 在住所 2 中为 wrapper 设置计划，可以使用 Routine 或 Actions 的 完成标准： 笔记本电脑合上时运行过一次节拍，而且你能指出结果到达的位置。工具中的幂等性、遗漏运行检测和并发锁也已存在，哪怕只是最小实现。 难度：中等 · 使用：概念 7。 构建。 打开双面板图，逐项检查配置、案例和 fixture。列出藏在纪律层中的所有机械内容：绝对路径、机器名称、写进自然语言的标志。 完成标准： 列表已提交，而且最严重的 3 项已修复。预计至少能找到 1 项；第 4 部分的故事并非虚构。 难度：中等 · 使用：概念 8。 构建。 在新住所运行完整金标准集，按类别整理失败，再记录带运行时标签的新基线。 完成标准： 难度：中等 · 使用：概念 4 和 8。 构建。 在新住所完成至少一个完整运营周期和 10 次计划节拍，每天对照新基线检查，同时保持旧住所可用。中途植入一次失败。 完成标准： 10 次节拍全部绿色，植入的告警到达你，旧计划已删除。这就是课程对「已经入住」的定义。请在日志顶部写「初步运营证据」，因为 10 次节拍只能证明这一点。 难度：中等 · 使用：概念 9 和 10。 构建。 为每个实际运行的循环，在一份提交到仓库的 Markdown 文件中回答问题 1 到 4，并以住所和速度限制结束每组答案。 完成标准： 只读这份文件的人就能说出每个循环住在哪里及原因，而且至少有一个答案让你意外到足以迁移循环。 难度：中等到困难 · 使用：概念 5 和 6。（Claude Code 路线。OpenCode 读者改为加固项目 2 的 runner：轮换凭据、安排更新、检查可用性。） 构建。 按照实时文档，创建一个托管 agent、一个环境和一个会话，运行金标准集中的一个评分案例。从头到尾阅读事件日志，并记录前后的活跃运行时间表。 完成标准： 能根据自己的运行，用 3 句话说明日志显示了什么、无法显示什么，以及会话成本。把它们提交在项目 6 文件旁边。 难度：综合项目 · 使用：概念 11。 构建。 只使用仓库，不查看供应商控制台，也不使用旧机器，配置一个全新循环住所并达到基线。记录耗时，每季度安排一次演练。 完成标准： 新住所通过完整套件，书面时间成本就是测得的锁定程度。若演练失败，就在泄漏只有一个物件宽时发现了它，这正是全部目的。Project 130-45 min非交互 wrapper让一条命令运行一次节拍，并确保失败绝不可能被忽略。
Project 21-2 hrs第一次计划节拍只移动时钟，合上屏幕后观察一次节拍运行。
schedule: 触发器，配置从仓库取得。Project 345-60 min行李箱审计找出藏在纪律层里的机械部分。
Project 41-2 hrs到达协议在新住所运行完整集合，并诚实地重新建立基线。
baseline.json 包含 runtime: 字段，每个失败都有书面结论：噪声、套件 bug 或真实失败；真实失败的修复已经交付。Project 51 hr, plus two weeks of nights试运行期10 次节拍、1 次植入失败，最终删除旧住所。
Project 645-60 min写下 4 个问题为运行的每个循环回答问题 1 到 4，并提交答案。
Project 72-3 hrs在住所 3 中运行一次会话打开托管会话，了解事件日志能告诉你什么，又无法告诉你什么。
Project 82 hrs, then a quarter of patience住所消失演练只用仓库重建住所并计时：这个数字就是锁定程度。
来源与延伸阅读
本书内部
- 循环工程：本课要迁移的节拍、计划与「发出响亮告警」动词。
- Harness 工程：问题 4 再次针对运行时提出的围栏与爆炸半径预算。
- 信任检查器：本课每次迁移都必须通过的金标准集、基线与漂移纪律。
- 个人 Agent Harness：问题 2 在个人规模上回答「必须拥有」后的路径。
- 模式 2 中的 评测驱动开发 与 部署 Agent Harness：制造规模上的同一组决策，以及完全开放的住所 4。
运行时（官方文档）
- Claude Code 非交互模式：
claude -p、输出格式、脚本：https://code.claude.com/docs/en/headless - Claude Agent SDK 概览，以及 SDK 与托管运行时的明确边界：https://code.claude.com/docs/en/agent-sdk/overview
- Claude Managed Agents 快速开始：agent、环境、会话：https://platform.claude.com/docs/en/managed-agents/quickstart（截至 2026 年 4 月为公开测试版，也是本书引用中变化最快的文档）
- Managed Agents 环境：云沙箱、最小权限网络，以及概念 5 执行平面选择背后的自托管沙箱：https://platform.claude.com/docs/en/managed-agents/environments
- Managed Agents 定价：活跃会话小时计量表：https://platform.claude.com/docs/en/about-claude/pricing
- Claude Code Routines：
/schedule、触发器、环境、stagger 和绿色状态限制：https://code.claude.com/docs/en/routines（研究预览） - Claude Cowork Scheduled Tasks：住所 2 的知识工作版本，以及本地文件限制：https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork
- OpenCode CLI 与服务器模式：
opencode run、opencode serve、远程连接：https://opencode.ai/docs/cli/ - GitHub Actions
schedule:触发器，以及 GitHub 自己给出的延迟与遗漏说明：https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule 和 https://docs.github.com/en/actions/how-tos/troubleshoot-workflows
所有链接截至 2026 年 7 月中旬有效。本课的机械层比本节其他任何课程都老化得快。依赖前，请在实时文档中确认每个名称、端点和价格。
一句话总结
从一个问题开始：谁运营循环，工作在哪里执行？非交互模式是通向每个新住所的桥。纪律会迁移，机械部分会重建，信任会在迁移后重新测量。4 个问题选择住所，爆炸半径设置速度。每个循环有意混用住所，而仓库保存真相，让你随时能够离开。当工作者拥有一个不属于你的地址时，它才算完成。