# Loop Engineering 的企业级真面目：把笔记本 loop 升级成凌晨 3 点无人值守的 runtime

> 深读来源：Truefoundry《Loop Engineering at Enterprise Grade — the enterprise agent runtime》
> 发布时间：2026-06-12；原文约 5500 字，含 5 张图
> 系列定位：Loop Engineering 深读系列 · 第 9 篇（唯一企业级 runtime 视角）

## TL;DR

Truefoundry 这篇文章的论点可以用一句话压到底：**loop engineering 本质上是一个 runtime 问题穿着 workflow 的外衣**。一个能跑的 demo loop 和一个能在凌晨 3 点无人值守、扛住崩溃、合规可审计的企业 loop 之间的差距，不是「再多写点 prompt」能补上的，而是要把每一台笔记本上的约定翻译成受治理的基础设施。

文章给出四件事：

1. **Enterprise gap 四分类**：笔记本 loop 上不了生产的差距，归纳为 Lifecycle（生命周期）、Credentials（凭证）、Cost（成本）、Inventory（清单）四个维度。
2. **6 原语的企业级翻译表**：把 Osmani 的 6 件套（Skills / Connectors / Sub-agents / Isolation / State / Automations）逐个翻译成 governed runtime 上的等价物。
3. **Unattended by Design 三大机制**：human-in-the-loop gates、guardrails、stop conditions，回答「为什么 maker/checker 分离是无人值守前提」。
4. **maker/checker 的两层完成**：sub-agent 检查的是 work（干活），runtime 的 gates 检查的是 actions（对外动作），两者不能互相替代。

这篇是整个深读系列里唯一系统讲「企业级 / 生产 runtime」的来源。其他四篇基本是个体开发者视角——Osmani 讲 6 原语与 L0-L3 演进，DSD 讲成本门槛，Tosea 讲三大硬骨头，OpenAI 讲 agent 内部脚手架。Truefoundry 单独占了 L3（Unattended 无人值守）这个生态位，把「笔记本上的能跑」到「企业凌晨 3 点的能跑」之间的那条沟，画成了可工程化的清单。

## 为何单独深读这篇

如果你只读个体视角的 loop engineering 文章，会得到一个错觉：loop 是个人生产力工具，配好 SKILL.md、做好 maker/checker、写好 state file，就齐活了。Truefoundry 的价值在于它把镜头拉远到组织层面，问了一个没人问的问题：**当 5 个工程师各自抄了一份 loop pattern，每个抄得都不一样，组织里到底有多少个 loop？每个能碰什么？谁批准了任何一个？**

这个问题在笔记本视角里不存在，但在企业里是 director 级别无法回答的尴尬。文章用「Noor 故事」把这个尴尬具象化：一个 staff engineer 三周内做出了团队最好用的工具，然后变成三场难受会议的主题——Finance 问账单、Security 问凭证、Director 问清单。Noor 的 loop 没有任何技术错误，错误全在 runtime：「The loop worked. The runtime was a laptop, and everything wrong traced back to that.」（loop 没问题，runtime 是台笔记本，所有问题都源于此。）

这篇值得单独深读，是因为它提供了其他来源都没有的两样东西：

- **一套可操作的企业化清单**。不是抽象地说「要治理」，而是给出 enterprise gap 四分类、6 原语企业级翻译表、governed YAML 示例、Unattended by Design 三机制，每一条都能拿来对照自己的 loop。
- **一种对「vendor theater」的自我警惕**。这是供应商博客里很罕见的诚实：FAQ 明确说，单 loop 低风险、作者盯着账单时不需要企业 runtime，装作需要是供应商表演。这种边界感让前面的论述更可信，而不是营销话术。

需要先打个预防针：Truefoundry 卖 Agent Harness，整篇是「笔记本 loop 不行 → 你需要 governed runtime → 我们就是」的叙事链。Noor 是「illustrative composite, not a specific organization or incident」（示例合成人物，非真实组织或事件）。读的时候要把「论点」和「销售」分开：runtime 视角的四个 gap 是真问题，但是否必须买 Truefoundry 的产品来解决，是另一个独立的问题。

## 心智模型：demo loop 像样车，企业 runtime 像能跑出租的车队管理系统

要把这篇文章的核心想清楚，用一个类比比读 YAML 更快。

**笔记本上的 demo loop 像一辆样车**。你在车间里手工打造，发动机能转，方向盘能打，开出去兜一圈很拉风。这辆车属于你，钥匙在你口袋，油钱你自付，撞了算你的。它的核心属性是「作者在场」：你写、你跑、你看、你修。Osmani 的 6 原语（Skills / Connectors / Sub-agents / Isolation / State / Automations）就是造这辆样车的零件清单——你照着图纸装，能跑。

**企业级 runtime 像一个能跑出租的车队管理系统**。它要回答的问题完全是另一套：这辆车归谁？谁能开？谁批的？油箱上限多少？半夜没油了谁加？撞了谁的保险？跑了一晚上烧了多少油？这个车队同时有 50 辆车在跑，每辆去的地方不一样，账怎么算？这些问题样车一个都不需要回答，但车队管理系统一个都躲不掉。

Truefoundry 的核心论点就是：**从样车到车队，不是把样车造得更精致，而是要再搭一层管理系统**。这一层管的是 identity（身份）、budgets（预算）、gates（闸门）、inventory（清单）、durable state（持久状态）——全在车的外面，不在车的里面。Noor 的三场会议（Finance / Security / Director）就是车队管理系统缺位的三个症状：账单失控、钥匙混用、车辆失踪。

这个类比还帮我们辨析一个本文最容易被混淆的概念：**harness 到底指什么**。

OpenAI 那篇 harness engineering 讲的是「intra-agent harness」——agent **内部**的脚手架：legibility（让 agent 能读懂自己的任务）、tools（工具定义）、constraints（约束）。这是给单辆样车装仪表盘、装方向盘、装限速器，让车本身更可控。

Truefoundry 这篇讲的是「extra-agent runtime」——agent **外部**的运行时：identity（loop 自己是谁）、budgets（loop 能花多少）、gates（loop 的破坏性动作谁批）、inventory（组织里有几个 loop）。这是给车队装调度系统、装油卡、装 GPS、装保险。

两者都常被叫 harness，但层次完全不同。intra-agent harness 让单个 agent 更聪明；extra-agent runtime 让一群 agent 在组织里可治理。本文聚焦后者。如果你把两者搞混，会出现一种典型的错误判断：「我们已经用了 Claude Code 的 harness，所以企业治理问题解决了」——错了，Claude Code 的 harness 是 intra-agent 的，它让单个 agent 更可控，但不回答「组织里有几个 loop、每个能碰什么、谁批的」。

## 详细机制：把笔记本 loop 升级成企业 runtime，差距在哪四个维度

这是文章的主体。Truefoundry 把 Noor 的三场会议转译成工程评审，得到 enterprise gap 四分类。每一个维度都对应笔记本 loop 的一个隐藏假设，这个假设在企业环境里全部失效。

### 维度一：Lifecycle（生命周期）—— 笔记本不是 runtime

笔记本 loop 的 runtime 是那台机器本身。这个事实带来一连串隐藏假设：合盖就死、中途崩溃无法恢复、无法为一个审批暂停三天（因为没有 durable 的东西持有 run）。这些假设在笔记本上不构成问题，因为作者在场——合盖了你重新打开，崩溃了你重新跑，审批你等一下就行。

但 loop 一旦要在凌晨 3 点无人值守地跑，这些假设全部变成致命缺陷。文章引用早期 playbook 的一句原话划出了 tool 与 runtime 的分界线：

> The moment a loop must run at 3 a.m. with no terminal open, survive crashes, and wait indefinitely on a human, you've left tool territory for runtime territory.
> （当一个 loop 必须在凌晨 3 点、没有终端开着的情况下运行，必须扛住崩溃，并且能无限期地等一个人类决策——你就已经离开了 tool 的领地，进入了 runtime 的领地。）

这句话是整篇文章里最重要的操作性定义。它告诉你：L2（attended，有人盯着的 loop）和 L3（unattended，无人值守的 loop）之间的分界线，不是「loop 写得好不好」，而是「有没有一个 durable 的 runtime 持有这个 run」。Noor 的 loop 是 L2，因为它跑在 Noor 的笔记本上，笔记本是 runtime，笔记本一关 loop 就没了。governed runtime 上的同一个 loop 才是 L3，因为 run state 由平台持有，survive crashes（扛住崩溃）和 survive laptop closing（扛住合盖）。

Lifecycle 维度的企业级翻译，对应 6 原语里的 **State**：从「external state file」（外部状态文件）升级成「durable、平台持有的 run state」。这不只是把 state file 从本地挪到云端，而是改变 state 的所有权——state 不再属于作者，而属于平台，因此能跨越崩溃、跨越合盖、跨越人员离职继续存在。

### 维度二：Credentials（凭证）—— 持有个人密钥的常驻自动化

Noor 的 loop 以 Noor 的身份运行：用她的 token、读她的明文 config、以她的权限按计划执行。文章给出一个非常精确的定义：

> A standing automation holding a person's keys is the non-human-identity problem in miniature.
> （一个持有个人密钥的常驻自动化，就是「非人类身份」问题的微缩版。）

这个定义之所以精确，是因为它点出了凭证问题的本质：不是「密钥泄露了怎么办」（那是加密问题），而是「这个 loop 在审计日志里与 Noor 本人无法区分」。当 Finance 查「谁在周末跑了 5000 美金的 token」，日志说是 Noor；当 Security 查「谁用 Noor 的权限改了生产配置」，日志也说是 Noor。loop 干的事，Noor 全得背锅；Noor 干的事，loop 也可能背锅。身份混淆是凭证维度的真正风险。

企业级翻译的核心结构优势是 **no keys anywhere in the loop**（loop 内部任何地方都不存密钥）。agent 定义只按名字引用 models / MCP servers / skills：模型按名字（`claude-sonnet-4-6`），MCP server 按名字（`github`、`ci`、`linear`），skill 按名字（`ci-triage-runbook@v2`）。provider 凭证住在 AI Gateway，tool auth 住在 MCP Gateway，由平台团队一次配好，agent 自己永远摸不到原始密钥。

这个设计带来一个组织级的能力：**「what can this loop touch?」（这个 loop 能碰什么？）从考古项目变成配置查询**。Noor 笔记本上的 loop 要回答这个问题，得去挖 config 文件、问 Noor、追溯她用了哪些 token。governed runtime 上的同一个 loop，直接查 agent 的 grants（授权）就行——配置里有，YAML 里有，registry 里有。这个差异在审计、合规、安全调查里是天壤之别。

Credentials 维度对应 6 原语里的 **Connectors（MCP）**：从「MCP servers with Noor's tokens」升级成「MCP Gateway with central auth / per-tool RBAC / guardrails / per-user OAuth delegation」。MCP 的企业级形态不只是「MCP server 跑在某个地方」，而是「所有 MCP server 通过一个中心 gateway，每个工具有独立的 RBAC，凭证 scoped 且可轮换，支持 per-user OAuth delegation（按用户委派）」。Noor config 里随便什么 token 的日子结束了。

### 维度三：Cost（成本）—— loop 与计费表之间什么都不挡

Noor 的 loop 与 provider 计量表之间没有任何缓冲：没有 budget（预算）、没有 rate limit（速率限制）、没有 per-run attribution（按 run 归因）。文章里 Finance 的问题——「为什么某个周末 token 账单飙升」——答案是 loop 对着坏掉的 test 环境热情重试了两天，没人看着。账单是在周一发票上才被发现的。

成本维度是 loop engineering 共识框架里「cadence = 成本线性倍数」（节奏等于成本的线性倍数）这条规律的最直接体现。一个 loop 一天跑一次和一天跑 24 次，成本差 24 倍；一个 loop 重试 5 次和重试 50 次，成本差 10 倍。而且**无人值守 loop 里也没有人在成本 loop 里**——没有人实时盯着成本曲线喊停。Osmani 在开头就警告 token 成本波动巨大，Truefoundry 把它从「财务惊喜」变成「运维参数」，分三层治理（The Meter）：

**第一层：Hard bounds per principal（按主体设硬上限）**。budgets / quotas / rate limits 应用到 loop 作为它自己的 agent identity——以 GitOps YAML 在 gateway 声明，可按 agent / team / user / model 强制执行。Noor 的周末事故，replay 到 per-agent budget 上，就变成一次 capped run（被上限截断的 run）加周六晚 alert（告警），而不是周一发票。注意「principal」这个词——它来自 IAM（身份与访问管理）传统，强调 loop 是独立的计费主体，不是挂在人头上。

**第二层：Per-run attribution（按 run 归因）**。harness 对每次 run 打 trace，tokens 和 cost 按 model call / tool call / sandbox execution 拆分——checker 的成本与 maker 的分开可见。这一层让「repeats vs one-off」（重复 vs 一次性）的判断用数字而非感觉做。一个 maker/checker 串行 loop，如果 checker 的成本占了 60%，说明 checker 被触发得太频繁；如果 maker 的重试成本占了 40%，说明 maker 的可靠性不够。没有 per-run attribution，这些判断全靠猜。

**第三层：The rollup（聚合视图）**。gateway 的 cost analytics 按 loop / team / model 聚合——「are loops paying for themselves?」（这些 loop 值不值这个钱？）从辩论变成 dashboard（仪表盘）。这一层把 loop 从「工程玩具」抬到「投资决策」：每个 loop 有 ROI（投入产出比），团队、部门、公司都能看到这笔账。

成本维度对应 6 原语里的 **Automations（schedule）**：从「跑在 cron 上的脚本」升级成「triggered runs via REST API or SDK」。但更重要的不是触发方式，而是触发背后必须挂着这三层成本治理。没有这三层的 schedule，就是一个等着爆账单的定时炸弹。

### 维度四：Inventory（清单）—— 5 个工程师 5 个分叉副本 0 个 registry

Director 那个无法回答的问题——「这个组织到底有多少个 loop？每个能碰什么？谁批准了任何一个？」——是 inventory 维度的核心症状。文章的判断很冷：5 个工程师、5 个分叉副本、0 个 registry（注册表），这正是 coding-agent 治理和 agent-sprawl（agent 蔓延）故事从生产力工具的侧门悄悄走进来的样子。

Inventory 不是技术问题，是组织问题。当每个工程师都能在笔记本上搭一个 loop，而组织没有任何机制知道这些 loop 的存在，就出现了「shadow loops」（影子 loop）——类比 shadow IT（影子 IT）。这些 loop 用着各自的凭证、各自的 budget（其实是个人信用卡或公司共享 key）、各自的 prompt，互相不知道对方存在，可能在干重复的事，可能在干冲突的事，可能其中一个因为 prompt 漂移开始干有害的事。

Truefoundry 给出的解法方向是 **Skills Registry**（技能注册表）和 **MCP Gateway**（MCP 网关）这两个中心化设施。Skills Registry 把散落在 5 台笔记本上的 SKILL.md 文件夹，变成一个受治理的目录：同一个 SKILL.md artifact，但带 versions（版本）、provenance（来源）、RBAC（基于角色的访问控制），按需挂载。MCP Gateway 把散落的 MCP server 配置，变成一个中心化的工具入口：同样的 MCP servers，但通过 registry + central auth + per-tool RBAC + guardrails。

这里有一句很值得记住的判断：

> Prohibition produces shadow loops; a better default produces registered ones.
> （禁止产生影子 loop；更好的默认产生注册的 loop。）

这句话的潜台词是：你不能靠「禁止工程师搭 loop」来解决 inventory 问题——禁止只会让 loop 转入地下，变得更不可见、更不可控。正确的方向是让 governed runtime 成为「更好的默认」，工程师搭 loop 的时候，注册、版本、凭证、budget 都是开箱即用的，比从零搭一个笔记本 loop 还省事，他们自然就会用注册的。这是一个产品设计原则，不只是一个治理原则——治理设施必须比绕过它更顺手，否则就是摆设。

Inventory 维度对应 6 原语里的 **Skills（SKILL.md）**：从「5 台笔记本上的文件夹」升级成「versioned / provenance / RBAC / 按需挂载的 Skills Registry」。codified knowledge（被编码的知识）从私有财产变成组织资产。

### 四维对照表：从笔记本到企业 runtime

把四个维度压缩成一张表，方便对照：

| Enterprise Gap | 笔记本 loop 的隐藏假设 | 企业环境的失效后果 | 企业级翻译 |
|---|---|---|---|
| **Lifecycle** | runtime = 那台笔记本，作者在场 | 合盖死、崩溃无法恢复、审批无法暂停 | durable、平台持有的 run state |
| **Credentials** | loop 以作者身份运行 | 审计日志中 loop 与作者无法区分 | no keys anywhere；loop 有自己的 identity |
| **Cost** | loop 与计费表之间无缓冲 | 周末重试两天，周一发票见 | hard bounds / per-run attribution / rollup |
| **Inventory** | 每人一份副本，互不可见 | 5 个分叉、0 个 registry、shadow loops | Skills Registry + MCP Gateway |

这张表是文章最有结构价值的产出。它的用法不是「读完点头」，而是拿它去 audit（审计）你自己的 loop：你的 loop 在 Lifecycle 上靠什么存活？Credentials 上 loop 是谁？Cost 上有没有上限？Inventory 上你的组织能不能数出有几个 loop？任何一格答不上来，就是你的 enterprise gap。

## 6 原语的企业级翻译：每个原语在生产里要补什么

文章最有结构价值的部分，是把 Osmani 的 6 件套逐个翻译成 governed runtime 上的等价物。这个翻译不是「换个地方部署」，而是每个原语都被重新定义了一遍——加上了版本、来源、权限、隔离、持久性、可观测性。下面是完整的翻译表，每行附上「在生产里要补什么」的具体说明。

| 笔记本原语 | 企业级等价物 | 在生产里要补什么 |
|---|---|---|
| **Skills**（SKILL.md） | **Skills Registry** | versions（版本：每次改 SKILL.md 都有版本号，可回滚）/ provenance（来源：谁写的、何时写的、基于什么写的）/ RBAC（谁能挂载这个 skill，谁能改）/ 按需挂载（loop 只在需要时拉取，不是全量预装） |
| **Connectors**（MCP） | **MCP Gateway** | registry（哪些 MCP server 存在）/ central auth（中心化认证，凭证不再散落）/ per-tool RBAC（每个工具有独立的角色权限）/ guardrails（每个工具调用前后过策略）/ per-user OAuth delegation（按用户委派 OAuth，而不是用共享 token） |
| **Sub-agents**（maker/checker） | **harness sub-agents** | 每个 checker 或 explorer 有自己的隔离 context（独立上下文，不串话）/ scoped tool access（按子 agent 限定工具范围，maker 能写、checker 只读）/ trace（每个子 agent 的每次调用都有可追溯记录）——maker/checker 分离带上了 identity 边界，不只是 prompt 边界 |
| **Isolated workspaces**（worktree） | **harness Sandbox** | 每次 run 一个安全执行环境，worktree 思想泛化成「every agent gets its own machine」（每个 agent 有自己的机器）——不只是 git worktree 级别的隔离，而是执行环境级别的隔离 |
| **State**（external state） | **durable、平台持有的 run state** | survive crashes（扛住崩溃：进程死了 state 还在）/ survive laptop closing（扛住合盖：笔记本关了 state 还在）/ 跨人员持久（作者离职了 state 还在，新接手的人能续上） |
| **Automations**（schedule） | **triggered runs** | 同样的 agent 定义通过 REST API 或 SDK 按 schedule/event 触发 / 结果落进 traces 和 notifications（不再依赖终端 scrollback，结果进可观测系统）/ 背后挂着成本三层治理 |

这张表里最关键的升级，是 **Sub-agents** 那一行。笔记本上的 maker/checker 分离，是 prompt 层的分离——maker 的 prompt 写「起草修复」，checker 的 prompt 写「审查修复」，但两个 sub-agent 跑在同一个 context、用同一套工具、同一个 identity。governed runtime 上的 maker/checker 分离，是 **identity + action 层的分离**——checker 有自己的 identity、自己的 scoped tool access（`mcp_servers: []`，零工具，read-only）、自己的 trace。这是质的飞跃，下面会专门展开。

另一个关键升级是 **Isolated workspaces**。worktree 是 git 层面的隔离——同一个 repo 的不同分支在不同的目录里 checkout。但企业级 loop 需要的不止是 git 隔离，而是执行环境隔离：每个 agent 跑在自己的 sandbox 里，能装的依赖、能访问的网络、能写的文件系统都受限。文章用「every agent gets its own machine」（每个 agent 有自己的机器）来概括——这不一定是真的物理机，但一定是逻辑上独立的执行单元。这对应 sandbox runtime、容器、microVM 这些技术选型。

## Noor loop 的 governed YAML：一份可直接对照的配置示例

文章给了一份 Noor loop 重建后的 governed agent 定义，是全文最值得逐行读的代码片段。这份 YAML 把前面讲的四维 gap、6 原语翻译，浓缩成一个可读的配置。先看全文：

```yaml
agent:
  name: morning-triage-loop
  model: claude-sonnet-4-6            # by name — keys live at the gateway
  instructions: ./triage.md@v4         # versioned scaffold
  skills: [ci-triage-runbook@v2]       # from the Skills Registry, RBAC'd
  mcp_servers: [github, ci, linear]    # via MCP Gateway: scoped, rotatable auth
  subagents:
    - { name: fix-drafter,  mcp_servers: [github] }
    - { name: fix-reviewer, mcp_servers: [] }      # checker ≠ maker, read-only
  harness:
    max_steps: 60
    max_tokens_per_run: 1_500_000      # the weekend incident, capped
  approvals: { merge_pr: pause_for_human }          # waits days if it must
trigger: { schedule: "0 6 * * 1-5" }   # the heartbeat — no laptop required
```

逐行拆解，这份 YAML 里藏着 enterprise gap 四维的全部答案：

**`name: morning-triage-loop`** —— 这是 loop 的 identity。笔记本 loop 没有名字（或者名字就是文件名），governed loop 有正式注册的名字。这个名字是它在 registry 里的 ID，是它出现在 budget dashboard 上的行，是它在审计日志里的 principal。Noor 的 loop 重建后以「自己」的身份运行——一个注册的 agent，有自己的 identity 和 grants。

**`model: claude-sonnet-4-6`** —— 按名字引用模型，注释说「keys live at the gateway」（密钥住在 gateway）。这是 no keys anywhere 原则的体现：agent 定义里不存任何 API key，key 由 AI Gateway 统一管理。Credentials 维度的解法就在这一行。

**`instructions: ./triage.md@v4`** —— versioned scaffold（带版本的脚手架）。笔记本 loop 的 prompt 是当前文件，改了就没了；governed loop 的 prompt 带版本号，每次改动可追溯、可回滚。`@v4` 意味着这个 loop 跑的是第 4 版的 triage 指令，如果第 5 版出问题，可以一键回退到第 4 版。

**`skills: [ci-triage-runbook@v2]`** —— 从 Skills Registry 拉取，带版本、带 RBAC。注释「from the Skills Registry, RBAC'd」说明：这个 skill 不是随便一个文件夹，而是注册表里登记的、有版本管理的、有访问控制的。Noor 的 loop 只能挂载她被授权的 skill。

**`mcp_servers: [github, ci, linear]`** —— 通过 MCP Gateway 接工具，注释「scoped, rotatable auth」（权限 scoped、凭证可轮换）。这三个工具（github、ci、linear）是 maker 用的，每个工具的凭证住在 MCP Gateway，Noor 的 loop 摸不到原始 token。

**`subagents`** —— 这里是全文最精妙的设计。注意两个 sub-agent 的 `mcp_servers` 字段：
- `fix-drafter`（起草修复，maker）：`mcp_servers: [github]` —— 能访问 github，能起草 PR。
- `fix-reviewer`（审查修复，checker）：`mcp_servers: []` —— **零工具，read-only**。

这一行 `mcp_servers: []` 是 maker/checker 企业级分离的精髓。文章专门强调：「a checker that can edit is just a second maker」（能编辑的 checker 只是第二个 maker）。如果 checker 也有 github 写权限，那它一旦被 prompt 漂移或对抗输入攻陷，就能直接 merge PR——这时 maker/checker 分离就名存实亡。把 checker 的工具清空，强制它只能 read（读）、不能 write（写），就把 maker/checker 从「prompt 层的分工」抬到「identity + action 层的隔离」。这是设计原则，不是实现细节。

**`harness`** —— Stop conditions（停止条件）：
- `max_steps: 60` —— 最多 60 步，防止无限循环。
- `max_tokens_per_run: 1_500_000` —— 注释「the weekend incident, capped」（周末事故，被截断）。这一个字段直接回应 Finance 的问题：周末重试两天的事故，replay 到这个配置上，就是一次被截断的 run 加一个告警，而不是周一发票。Cost 维度的第一层 hard bounds 就藏在这一行。

**`approvals: { merge_pr: pause_for_human }`** —— Human-in-the-loop gate。注释「waits days if it must」（必要时等几天）。这是 Lifecycle 维度的关键：loop 能为一个审批暂停三天，因为 durable state 持有这个 run，人去度周末了 loop 不会死，人回来批准了 loop 继续。笔记本 loop 做不到这一点，因为它没有 durable state。

**`trigger: { schedule: "0 6 * * 1-5" }`** —— 注释「the heartbeat — no laptop required」（心跳——不需要笔记本）。这是 L3 无人值守的标志：loop 通过 schedule 触发，不依赖任何人的终端开着。Noor 的笔记本可以关着、Noor 可以在睡觉、Noor 甚至可以离职，loop 照常在早上 6 点跑。

整份 YAML 只有 14 行，但每一行都在回答一个 enterprise gap。把它和 Noor 笔记本上的原始 loop（一个 config 文件装着她的个人 token、一个 cron 脚本、一个本地 state file）对照，差距一目了然。这份 YAML 不是「多写了几行配置」，而是把 loop 从「Noor 的私有财产」变成了「组织的受治理资产」。

## Unattended by Design：为无人值守而设计的三大机制

文章对「无人值守」有整个深读系列里最系统的论述。开篇一句话定调：

> The defining property of a loop is that nobody is watching, so the runtime's job is to make "nobody is watching" safe.
> （loop 的定义性属性就是没人在看，所以 runtime 的工作是让「没人在看」变得安全。）

这句话把 runtime 的职责定义得非常清楚：runtime 不是为了「让 loop 跑得更快」，而是为了「让没人看也安全」。Unattended by Design 的三大机制，就是实现这个「安全」的三道防线。

### 机制一：Human-in-the-loop gates（人机闭环闸门）

harness 暂停敏感 tool call（merge PR、改生产系统、删数据），durable 持有 run state 直到有人批准；loop 不会因为人去度周末而死。

这个机制的关键不在于「能不能暂停」（笔记本 loop 也能暂停，只是暂停了就没了），而在于**暂停后 state 是 durable 的**。governed runtime 上的 loop 暂停在一个 merge_pr 的 approval 上，run state 由平台持有，等三天、三周、三个月，人回来批准了，loop 从暂停点继续。这就是 Lifecycle 维度说的「wait indefinitely on a human」（无限期等待人类决策）。

更关键的是文章指出的组织级设计：**破坏性工具在 MCP Gateway 处一次性打标，全组织生效**。这意味着策略自动应用于每个 loop，而不是依赖 5 个工程师每个都记得配。笔记本 loop 的审批配置是 prompt 层的——「在 merge 前先问一下」，依赖 agent 听话；governed loop 的审批配置是 gateway 层的——merge_pr 这个工具调用无论如何都会被拦截，agent 听不听话都无所谓。这是把审批从「prompt 层的希望」抬到「infrastructure 层的强制」。

这个机制直接对应 enterprise gap 的 Lifecycle 维度和 Credentials 维度：Lifecycle 上让 loop 能等、Credentials 上让破坏性动作有强制闸门。

### 机制二：Guardrails（护栏）

每个 model call 和 tool call 都过 gateway 的 pre/post-call checks（调用前/调用后检查）：PII 检测（个人身份信息）、content policies（内容策略）、custom rules（自定义规则）。文章点出一个关键的公平性：**所以凌晨 6 点处理真实 ticket 的 loop 与下午 2 点的交互 session 被同等筛查**。

这句话的含义比表面深。笔记本 loop 没有-guardrails，因为它跟 author 的交互 session 是同一个环境——author 在的时候，guardrails 是 author 自己的判断；author 不在的时候，guardrails 是零。governed loop 的 guardrails 是常驻的，无论 author 在不在，每个调用都过同样的检查。这就解决了「无人值守时 agent 在干什么」的可观测性问题——不是事后翻日志，而是事前拦截、事中检查、事后留痕。

Guardrails 的设计要点是 pre-call 和 post-call 都查。pre-call（调用前）拦截：这个 prompt 里有没有 PII？这个工具调用是不是在禁止列表里？post-call（调用后）检查：这个返回里有没有泄露敏感信息？这个动作的结果是不是符合预期？双向检查比单向更可靠，因为 LLM 的输出有不确定性，光拦输入不够，输出也可能出问题。

这个机制对应 enterprise gap 的 Cost 维度（guardrails 可以拦截高成本调用）和 Credentials 维度（guardrails 可以拦截越权调用），也部分对应 Inventory 维度（所有 loop 过同一套 guardrails，策略统一）。

### 机制三：Stop conditions（停止条件）

文章的原话非常冷静：

> Run-until-done is only as safe as its edges.
> （「一直跑到完成」只与它的边界一样安全。）

这句话点出了 stop conditions 的本质：loop 的默认行为是「run-until-done」（跑到完成），但「完成」是 agent 自己判断的，agent 可能判断错——可能永远不完成（死循环）、可能反复重试（烧钱）、可能在错误的方向上「完成」（破坏）。stop conditions 就是给「run-until-done」加上硬边界：

- **step ceilings**（步数上限）：`max_steps: 60`，到了 60 步还没完成，强制停。
- **token budgets**（token 预算）：`max_tokens_per_run: 1_500_000`，烧到上限强制停。
- **stall detection**（停滞检测）：连续 N 步没有进展，判定为 stall，强制停。

这三个都是 harness 配置项，不是希望（not hope）。文章有一句很关键的辨析：

> The difference between "the loop converged" and "the loop stopped when its budget said so" is what the trace tells you.
> （「loop 收敛了」和「loop 因为预算到了而停了」之间的差别，正是 trace 告诉你的东西。）

这句话的含义是：stop conditions 不只是「防止失控」，更是「让 run 的结局可解释」。一个 loop 跑完了，到底是「真的完成了任务」还是「被预算掐死了」，trace 一看就知道。这个区分对运维至关重要——如果是真的完成了，下次可以放心跑；如果是被预算掐死了，说明任务本身有问题（太复杂、太贵、prompt 有 bug），需要修，而不是调高预算再跑一次。没有这个区分，团队会陷入「调高预算-再爆-再调高」的死循环。

这个机制直接对应 enterprise gap 的 Cost 维度，也对应 maker/checker 的可靠性问题（下面展开）。

### 三机制的层次关系

这三个机制不是平行的，而是层层递进的防线：

1. **Guardrails** 在每个调用前后检查，是最细粒度的防线——防止单次调用出错。
2. **Stop conditions** 在 run 级别设边界，是中粒度的防线——防止单次 run 失控。
3. **Human-in-the-loop gates** 在破坏性动作前暂停，是最粗粒度的防线——防止不可逆后果。

三层防线缺一不可。只有 guardrails 没有 stop conditions，agent 可能在合规范围内无限重试烧钱；只有 stop conditions 没有 gates，agent 可能在预算内完成了一个破坏性的、不可逆的动作；只有 gates 没有前两层，人会被 approval 疲劳淹没，最后机械地点「批准」。这三层共同构成「Unattended by Design」的完整定义——无人值守不是「没人看」，而是「没人看也安全，因为三层防线都在」。

## maker/checker 的两层完成：work vs actions 的关键升级

文章对 maker/checker 有整个深读系列里最精炼的一次表述：

> Osmani's verifier sub-agent checks the *work*; the runtime's gates check the *actions*.
> （Osmani 的 verifier 子 agent 检查的是「工作」；runtime 的 gates 检查的是「动作」。）

这句话把 maker/checker 从「一层」抬到「两层」，是概念上的关键升级。需要把它彻底讲清楚。

### 第一层：sub-agent 检查 work（干活的质量）

这是 Osmani 原文里的 maker/checker：maker 起草修复，checker 审查修复。checker 是一个 sub-agent，它读 maker 的输出，判断「这个修复对不对、好不好、有没有引入新问题」。这一层检查的是 **work 的质量**——代码写得对不对、PR 描述准不准、测试覆盖全不全。

这一层的 checker 是 prompt 层的、是 advisory（建议性）的。它给出的是「我觉得这个 OK」或「我觉得这里有问题」，它的判断可以被 maker 接受或拒绝，它的权限和 maker 一样（除非像 Noor YAML 那样显式设 `mcp_servers: []`）。文章对这一层的价值有精确的估价：

> It costs real tokens and earns them selectively: spend the second opinion where being wrong is expensive.
> （它花真 token，并且有选择地赚回来：把第二意见花在「错了代价大」的地方。）

这句话是判断「要不要上 checker」的经济学标准。checker 不是免费的——它要跑一次完整的 LLM 调用，花真金白银的 token。它的价值是「在错了代价大的地方」才体现。如果 maker 在写一个无关紧要的注释，checker 不值得；如果 maker 在写一个合并到主分支的 PR，checker 值得。这个判断必须基于「错了的代价」，不能基于「我觉得更稳」。

### 第二层：runtime gates 检查 actions（对外动作的不可逆性）

这是 Truefoundry 独有的升级。文章的判断是：

> A loop can have a brilliant reviewer agent and still need a person between it and an irreversible merge; the harness is where that judgment becomes enforced.
> （一个 loop 可以有一个出色的 reviewer agent，却仍然需要在它和不可逆 merge 之间放一个人；harness 就是这种判断变成强制执行的地方。）

这一层检查的是 **actions 的不可逆性**——这个动作能不能撤销？如果不能（merge PR、删数据库、改生产配置），就必须有人批准，不管第一层的 checker 说得多好听。

两层的区别是质的。第一层 checker 说「这个 PR 没问题」，是一个 **claim（主张）**，不是 proof（证明）。checker 可能被对抗输入骗过、可能 prompt 漂移、可能那天模型状态不好。第二层 gate 说「这个 merge 需要人批准」，是一个 **enforcement（强制）**——它不依赖 agent 的判断，是 infrastructure 层的硬拦截。agent 再聪明、checker 再 brilliant，gate 该拦还是拦。

这就是文章说的「maker/checker 分离是 load-bearing rather than decorative」（承重而非装饰）的根本原因。在笔记本 loop 里，checker 可能是装饰——作者在场，作者自己就是最后一道闸门。在无人值守 loop 里，checker 是承重的——作者不在，checker 是唯一的内容审查，gate 是唯一的动作审查，两者缺一不可。只有 checker 没有 gate，agent 可能在 checker 的背书下干了一个不可逆的错事；只有 gate 没有 checker，agent 可能在 gate 的批准下（人机械点同意）干了一个内容上的错事。

### 两层完成的配置体现

回到 Noor YAML，两层完成是这样体现的：

- 第一层（work）：`fix-reviewer`（checker sub-agent）读 `fix-drafter`（maker sub-agent）的输出，给审查意见。这是 prompt 层、是 advisory。
- 第二层（actions）：`approvals: { merge_pr: pause_for_human }`。这是 infrastructure 层、是 enforcement。

注意这两层是独立的：checker 可能说「这个 PR 完美」，gate 还是会暂停等人工批准 merge。反过来，checker 可能说「这个 PR 有问题」，maker 修改后 checker 通过了，gate 还是会暂停。两层各管各的，互不替代。

这个设计是整个深读系列里对 maker/checker 最深刻的贡献。Osmani 提出了 maker/checker 分离，Truefoundry 把它从一层抬到两层，并明确了两层的分工：work（内容质量）vs actions（动作不可逆性）。这个区分在企业环境里是生死攸关的——因为企业环境的动作往往是不可逆的（merge、deploy、delete），而笔记本环境的动作大多是可撤销的（本地文件、git reset）。

## 失败率堆叠：为什么无人值守放大每一个错误

文章有一段算术，是整个深读系列里最冷酷的诚实：

> A loop chaining five steps, each 95% reliable, completes cleanly about three-quarters of the time.
> （一个串联 5 步、每步 95% 可靠的 loop，整体干净完成的比例大约是四分之三。）

95% 的单步可靠率听起来很高，但 5 步串联后整体只有 0.95^5 ≈ 77.4%。这意味着每跑 4 次，大约有 1 次会失败。在 attended loop（有人盯着）里，这个失败率可以接受——失败了人在，重启、修、继续。但在 unattended loop（无人值守）里，这个失败率是致命的，因为：

**第一，无人值守 loop 的错误会堆进 state。** 明天的 run 建在今天的错误上。今天的 run 在第 4 步失败了，但 state 已经被前 3 步污染了（比如已经开了个半成品 PR、已经改了几个文件、已经发了几个通知），明天的 run 从这个污染的 state 出发，可能又往前走了一步，又污染了一点。一个无人值守 loop 跑一周，state 可能积累了一周的半成品错误，最终成为一个无法清理的烂摊子。

**第二，无人值守放大每一个错误的后果。** attended loop 里，第 4 步失败，人在，立刻看到，立刻止损。unattended loop 里，第 4 步失败，没人看，loop 可能继续重试（烧钱）、可能继续往下走（污染更多 state）、可能在错误基础上「完成」（产生一个看起来对实际错的输出）。失败从「一次中断」放大成「一连串连锁损失」。

这就是为什么前面强调的 maker/checker 分离、stop conditions、durable state，在 unattended 场景下是承重的。文章引用 Willison 的老笑话——agent 是「an LLM wrecking its environment in a loop」（一个在 loop 里破坏自己环境的 LLM）——并建议把它贴在 automation tab 上方。这个笑话在 attended 场景下是幽默，在 unattended 场景下是工程现实。

这段算术也解释了为什么 Truefoundry 花那么大篇幅讲 runtime 治理——因为单步可靠率 95% 已经是当前 LLM 的现实，再往上提升极难，而企业 loop 要的不是「单步 99%」，而是「即使单步 95%，整体也能安全跑」。runtime 的三层防线（guardrails / stop conditions / gates）加上 maker/checker 两层完成，就是「在单步可靠率不够的前提下，让整体可接受」的工程方案。这个思路比「等模型变强再说」务实得多。

## 真实案例：Noor 故事的完整展开

文章用 Noor 故事作为叙事骨架，这个故事的完整展开值得单独看，因为它是把四个 enterprise gap 具象化的最好教材。

Noor 是一个 staff engineer。她搭了一个团队现在都耳熟能详的 loop：

- **触发**：每天早上 6 点，loop 自动启动。
- **输入**：读昨夜的 CI 失败、所有开着的 issue。
- **起草**：在隔离的 git checkout 里起草修复。
- **审查**：第二个 agent（checker）review 起草的修复。
- **输出**：开 PR，留一个整洁的 state file 记录 done（已做）和 next（下一步）。

**三周内，这是团队最好用的工具。** 每天早上工程师来上班，已经有几个起草好的 PR 等着 review，CI 失败已经有候选修复，issue 已经被 triage 过。Noor 成了团队英雄。

**然后，这个 loop 变成了三场难受会议的主题。**

**第一场：Finance（财务）问**——「为什么某个周末 token 账单飙升？」调查发现，loop 在周六凌晨对着一个坏掉的 test 环境热情重试了两天。test 环境返回的错误让 loop 以为「再试一次可能就好了」，于是它一直试，一直试，直到周末结束。没人看着，因为这是周末。账单在周一发票上才被发现。这是 **Cost 维度** 的典型失效：loop 与计费表之间什么都不挡，错误重试无人拦截。

**第二场：Security（安全）问**——「loop 的凭证放哪了？」调查发现，凭证在 Noor 笔记本上的一个 config 文件里，装着她的个人 token，loop 早上 6 点以 Noor 的身份运行。这意味着：在所有审计日志里，loop 的操作与 Noor 本人无法区分。如果 loop 干了什么坏事，日志说是 Noor 干的；如果 Noor 想甩锅说「那不是我，是 loop」，她无法证明。更严重的是，如果 Noor 离职，她的 token 被回收，loop 立刻挂掉；如果 Noor 的 token 泄露，loop 的所有操作都暴露。这是 **Credentials 维度** 的典型失效：loop 以作者身份运行，身份混淆。

**第三场：Director（主管）问**——「另外 4 个 engineer 各自抄了这个 pattern，各抄得不一样。这个组织到底有多少个 loop？每个能碰什么？谁批准了任何一个？」Noor 无法回答。她只知道自己的 loop，不知道另外 4 个的细节。Director 发现组织里有至少 5 个类似的 loop，每个用不同的凭证、不同的 prompt、不同的 scope，互相不知道对方存在，可能在干重复的事，可能在干冲突的事，谁也说不清。这是 **Inventory 维度** 的典型失效：5 个分叉副本、0 个 registry。

文章的总结金句：「The loop worked. The runtime was a laptop, and everything wrong traced back to that.」Noor 的 loop 在技术上是成功的——它真的修了 CI、真的开了 PR、真的 triage 了 issue。所有问题都不在 loop 本身，而在 loop 跑在什么上面。runtime 是一台笔记本，所以合盖就死（Lifecycle）、凭证是 Noor 的个人 token（Credentials）、没有预算上限（Cost）、组织不知道它的存在（Inventory）。

需要再次提醒：Noor 是「illustrative composite, not a specific organization or incident」（示例合成人物，非真实组织或事件）。这是 Truefoundry 编的叙事，不是真实案例。但这个叙事的价值不在于它是否真实发生过，而在于它精确地映射了 enterprise gap 四分类——每一个会议对应一个维度，每一个问题都有具体的工程解法。读的时候把它当成「教学案例」而非「客户证言」。

## 权衡与局限：企业化的复杂度代价

讲完了 Truefoundry 的方案，必须讲它的代价和局限，否则就是把供应商博客当中立分析。

### 代价一：强烈的供应商立场

Truefoundry 卖 Agent Harness。整篇文章的叙事链是「笔记本 loop 不行 → 你需要 governed runtime → 我们就是」。Noor 的三场会议是被精心设计来制造焦虑的——Finance、Security、Director 三个角色分别对应 Cost、Credentials、Inventory 三个 gap，正好是 Truefoundry 产品的卖点。读的时候要保持警惕：四个 gap 是真问题，但「必须买 Truefoundry 解决」是销售话术。open-source 的方案（自建 registry、自建 gateway、自建 budget 系统）也能解决同样的问题，只是要投入工程时间。

文章 FAQ 有一句反营销的话，部分缓解了这个担忧：

> For one loop, on low-stakes targets, with its author watching the bill — probably not, and pretending otherwise would be vendor theater.
> （对于单 loop、低风险目标、作者盯着账单的情况——大概率不需要，装作需要是供应商表演。）

这种诚实让前面的论述更可信。但要注意，这句话的潜台词是「单 loop 不需要，多 loop 才需要」——这恰恰是供应商最想让你相信的「你需要 scale」叙事。真实的判断标准不是「你有几个 loop」，而是「你的 loop 失控的代价有多大」——一个高风险的单 loop（比如能改生产系统的）可能需要 governed runtime，五个低风险的多 loop（比如只读分析）可能不需要。

### 代价二：runtime 框架可能过度基础设施化

很多团队的真实问题不是「没有 runtime」，而是更基础的问题：没有好的 verifier（验证器）、没有可重复的任务、没有清晰的 success criteria（成功标准）。Truefoundry 的解法假定你已经过了 DSD 说的「成本门槛」和 Tosea 说的「三大硬骨头」——也就是假定你会设计 loop，只是需要地方跑。

但现实是，很多团队的 loop 还停留在 L1（一个 agent 跑一个任务），连 maker/checker 都没上，更别说 schedule。对这些团队，先投入 governed runtime 是本末倒置——就像还没学会开车就先买车队管理系统。正确的顺序是：先把 loop 设计对（Osmani 的 6 原语 + maker/checker），再考虑把它上 L3（governed runtime）。

### 代价三：没讨论 loop engineering 本身的设计难度

Truefoundry 假定你会设计 loop，只是需要地方跑。但 DSD 和 Tosea 都显示，loop 设计本身就是硬技能——prompt 怎么写、context 怎么管理、failure mode 怎么预判、success criteria 怎么定义。Truefoundry 对这些只字未提，仿佛「把 loop 搬到 governed runtime」就能解决设计问题。这是 runtime 视角的盲区：runtime 能让一个设计良好的 loop 安全跑，但不能让一个设计糟糕的 loop 变好。一个设计糟糕的 loop 搬到 governed runtime 上，只是一个「受治理的糟糕 loop」——它会按预算被截断、会留 trace、会在 gate 前暂停，但它依然是糟糕的。

### 代价四：与 OpenAI harness engineering 的概念混淆

这是读这篇文章最容易踩的坑。Truefoundry 把 harness 当成已定义概念引用 Osmani，但 OpenAI 的 harness engineering 讲的是另一层。两层都叫 harness，但层次完全不同：

- **OpenAI 的 harness（intra-agent harness，agent 内部脚手架）**：legibility（让 agent 读懂任务）、tools（工具定义）、constraints（约束）。这是给单个 agent 装仪表盘、装限速器，让 agent 本身更可控。
- **Truefoundry 的 harness（extra-agent runtime，agent 外部运行时）**：identity（loop 是谁）、budgets（loop 能花多少）、gates（loop 的破坏性动作谁批）、inventory（组织里有几个 loop）。这是给一群 agent 装调度系统、装油卡、装保险。

两层都重要，但解决的是不同的问题。intra-agent harness 让单个 agent 更聪明、更可控；extra-agent runtime 让一群 agent 在组织里可治理。混淆这两层会导致错误的判断：「我们已经用了 Claude Code 的 harness，所以治理问题解决了」——错了，Claude Code 的 harness 是 intra-agent 的，它不回答 extra-agent 的治理问题。反过来，「我们需要 governed runtime 来让 agent 更听话」——也错了，runtime 不让 agent 更听话，runtime 让 agent 的动作更可治理；让 agent 听话是 intra-agent harness 的事。

### 代价五：「ban loops 产生 shadow loops」缺乏实证

文章有一句合理的工程直觉：「Prohibition produces shadow loops; a better default produces registered ones」（禁止产生影子 loop；更好的默认产生注册的 loop）。这个论断符合工程常识——禁止通常无效、绕过通常转地下。但它没有数据支撑，是 assertion 而非 evidence。在采纳这个论断作为治理原则之前，需要自己的组织数据验证：在你的组织里，禁止真的产生 shadow loops 吗？更好的默认真的让人注册吗？这取决于组织文化、工程师习惯、governed runtime 的实际易用性。盲目相信这个论断，可能导致「我们建了 registry 就没人用 shadow loop 了」的错觉。

## 落地建议：企业上 L3 前的清单

把前面的分析压缩成可操作的清单。这是给「正在考虑把 loop 搬到 governed runtime」的团队的建议。

### 清单一：先确认你真的需要 L3

不是所有 loop 都需要 governed runtime。用 Truefoundry 自己的判断标准：

- **单 loop、低风险、作者盯着账单** → 不需要 L3，L2（attended）就够。装作需要是 vendor theater。
- **多 loop、高风险、需要无人值守** → 需要 L3。具体来说，如果你的 loop 满足以下任何一条，就该上 governed runtime：
  - 能执行不可逆动作（merge、deploy、delete、改生产配置）。
  - 需要在凌晨 / 周末 / 假期无人值守地跑。
  - 用到的凭证如果泄露会造成实质损失。
  - 一个 loop 失控的账单可能超过你一个月的预算。
  - 组织里有超过 2 个团队在搭类似的 loop，互相不知道对方。

### 清单二：对照 enterprise gap 四分类 audit 自己的 loop

逐项 audit：

- **Lifecycle**：你的 loop 现在跑在什么上面？合盖会死吗？崩溃能恢复吗？能为审批暂停三天吗？如果任何一个答「不能」，你有 Lifecycle gap。
- **Credentials**：你的 loop 用的是谁的凭证？是个人 token 还是服务账号？在审计日志里能和真实用户区分吗？如果凭证明天泄露，损失多大？如果任何一个让你不安，你有 Credentials gap。
- **Cost**：你的 loop 有预算上限吗？单次 run 最多花多少？超了会自动停吗？有 per-run 归因吗？有 team 级别的聚合视图吗？如果任何一个答「没有」，你有 Cost gap。
- **Inventory**：你的组织能数出有几个 loop 吗？每个 loop 能碰什么？谁批准的？如果任何一个答不出，你有 Inventory gap。

任何一格有 gap，就是上 L3 的理由。gap 越多，越紧迫。

### 清单三：按 6 原语翻译表升级

确认要上 L3 后，按翻译表逐项升级：

- **Skills → Skills Registry**：把散落的 SKILL.md 集中到一个带版本、带来源、带 RBAC 的目录。即使是内部自建，也要有版本号和访问控制。
- **Connectors → MCP Gateway**：把散落的 MCP server 配置集中到一个中心化入口，凭证由 gateway 管理，每个工具有独立的 RBAC。
- **Sub-agents → harness sub-agents**：给每个 sub-agent 独立的 context 和 scoped tool access。checker 必须是 `mcp_servers: []`，read-only。
- **Isolation → Sandbox**：每个 run 跑在自己的隔离执行环境里，网络、文件系统、依赖都受限。
- **State → durable run state**：state 由平台持有，survive crashes、survive 合盖、跨人员持久。
- **Automations → triggered runs**：通过 API/SDK 触发，结果进 trace 和 notifications，背后挂成本三层治理。

### 清单四：部署 Unattended by Design 三层防线

在升级 runtime 的同时，部署三层防线：

- **Guardrails**：每个 model call 和 tool call 过 pre/post-call checks（PII、内容策略、自定义规则）。
- **Stop conditions**：每个 loop 配 `max_steps`、`max_tokens_per_run`、stall detection。
- **Human-in-the-loop gates**：所有破坏性工具在 gateway 处一次性打标，强制人工批准。

三层必须同时部署，缺一不可。

### 清单五：把 maker/checker 从一层抬到两层

最后，重新设计 maker/checker：

- **第一层（work）**：checker sub-agent 审查 maker 的输出，给内容质量意见。这一层是 advisory，基于「错了的代价」决定要不要上。
- **第二层（actions）**：runtime gates 拦截所有不可逆动作，强制人工批准。这一层是 enforcement，不依赖 agent 判断。

两层独立运作，互不替代。checker 说 OK 不代表 gate 放行；gate 暂停不代表 checker 没审过。

### 清单六：记住「You stay the engineer」

最后一条，也是最重要的哲学提醒。文章引用 Osmani 的警告：

> The loop changes the work, it doesn't delete you from it.
> （loop 改变了工作，但没有把你从工作中删除。）

governed runtime 不改变这条账本，只改变组织能看见什么——review rates（审查率）、approval patterns（批准模式）、per-loop outcomes（每个 loop 的结果）。这是管理它的前提，不是判断的替代品。

具体来说，三件事 runtime 不能替你做：

- **verification（验证）仍是你的**：checker sub-agent 让 loop 的「done」mean something（让「完成」有点意义），但 done 是 claim 不是 proof（是主张不是证明）。你仍要抽检 loop 的输出。
- **comprehension debt（理解债）增长比 loop 改善更快**：存在的与你理解的之间的差距，随每个未读 PR 复合。runtime 让你能看见「这个 loop 这周开了 20 个 PR」，但不让你「理解这 20 个 PR」。理解债要靠人还。
- **舒适的姿态是危险的**：文章的收尾警告——「the same loop is leverage for the engineer who uses it on work they understand and an accelerant of decline for the one using it to avoid understanding」（同一个 loop，对用它做自己理解的工作的工程师是杠杆，对用它逃避理解的工程师是衰退的加速器）。

这条是整个深读系列共同的底线，也是 loop engineering 最容易被工程化论述掩盖的人性维度。governed runtime 解决「组织能看见什么」，但不解决「工程师是否还在理解自己的系统」。前者是基础设施问题，后者是职业纪律问题。再好的 runtime，也救不了用它来逃避理解的工程师。

## 延伸阅读

- **原文**：Truefoundry《Loop Engineering at Enterprise Grade — the enterprise agent runtime》https://www.truefoundry.com/blog/loop-engineering-enterprise-agent-runtime （2026-06-12，约 5500 字，含 5 张图：loop cycle / Harness builder / orchestrating run / cost dashboard / per-step trace）
- **Osmani《Loop Engineering》**：6 原语与 L0-L3 演进框架的源头，Truefoundry 全文都在翻译它的概念。本深读系列第 1 篇。
- **OpenAI《Harness Engineering》**：intra-agent harness 视角，与本文的 extra-agent runtime 形成层次互补。本深读系列对应 OpenAI 篇。辨析两层 harness 的区别时对照读。
- **DSD 关于成本门槛的论述**：Truefoundry 的成本三层治理是对 DSD「成本门槛」的最系统实现方案。本深读系列对应 DSD 篇。
- **Tosea 三大硬骨头**：loop 设计本身的难度，是 Truefoundry 假定你已经跨过的门槛。本深读系列对应 Tosea 篇。
- **Willison 关于 agent 是「LLM wrecking its environment in a loop」的论述**：Truefoundry 引用，贴在 automation tab 上方。
- **IAM / non-human identity 传统**：Truefoundry 的 Credentials 维度直接借鉴了 IAM 的「non-human identity」概念，深入可读 OAuth 2.0 for Server-to-Server、Workload Identity 等资料。
- **GitOps 与声明式治理**：Noor YAML 的 `approvals`、`harness` 字段体现了 GitOps 精神——治理策略声明式定义、版本化、可审计。深入可读 ArgoCD、Flux 等资料。