--- status: draft chapter-type: presentation --- # Part 0 · 公开分享：给 AI 套上缰绳（60 分钟） > *把整本《Harnessing AI》压成一小时，让同行一次听懂 > Harness Engineering 在讲什么、为什么非做不可、以及周一上班 > 可以从哪一行代码开始。* ```{admonition} 使用说明 :class: tip 这一部分**不是**一章独立的技术内容，而是整本书的 **60 分钟公开分享版**。 面向的是 *对 AI 编码实践感兴趣的同行* —— 软件工程师、架构师、技术负责人， 大多数人用过 Cursor / Codex / Claude Code，但没专门做过 harness 系统设计。节奏是 **8 段 × 约 7 分钟 + Q&A 4 分钟**。 - `index.md`（本文）—— 可直接通读的讲稿，讲者可以当"口水稿"用。 - `outline.md` —— 分钟级 speaker outline，精确到每分钟讲什么， 含**目标 / 钩子 / 可跳 / 别讲 / 深一层**五段式。 - `slides.md` —— 每页一张 slide 的大纲（每 `##` 对应一张）， `>` 引用块是 speaker notes，方便复制到 Keynote / Google Slides 的 Outline 视图一次性导入。 - `../_handson/13-one-hour-talk/SLIDES.md` —— 已经排版好的 Marp 兼容版幻灯片（带讲者备注），可直接投影或导出为 PDF。 书中所有用到的概念、数字、引用，都指向后续章节里的某一章。 这一讲只给 **主脊** —— 不陷入任何一个细节 —— 细节请回到相应 Part。 **术语约定**：讲稿里涉及 `AGENTS.md / CLAUDE.md 兼容层 / SKILL.md / MCP / pre-commit / Bridle / Fence / Paddock / Groom / SDD / TDD / MDD / HarnessCard` 这些概念时，**保留英文原词**。这些词 在书里都有精确定义，硬翻反而会丢掉它们的工程意涵。 ``` ## F.0 · 开场（2 分钟） ### 为什么今天站在这里 **一句话中心论点.** 2026 年，AI 编码的杠杆点 **从模型本身移到了 模型周围的环境**；软件团队写代码的方式正在被这一转移重塑，而且 再不讨论一次，下一轮 code review 上很容易各说各话。 **白板时刻.** 在白板左边写一个大写的 "M"（Model），右边写一个 大写的 "E"（Environment）。画一个箭头从 "M" 指向 "E"，箭头上写 "2022–2024"；再画一个箭头从 "E" 指向 "M"，写 "2026"。说： 「过去我们想着怎么把模型调得更听话；现在我们想着怎么把环境建 得让一个普通模型也干不坏事。」 **三条 2026 年的事实.** 每条 15 秒： - **OpenAI 的 Codex 团队**，8 周内上线约 **100 万行生产代码**， 其中 **0 行由人手写**。 - **LangChain 团队** 没换模型，只改了模型 *周围的脚手架*，就把 Terminal Bench 2.0 成绩从第 30 名冲进前 5。 - **Anthropic** 在 *权限弹窗、技能编写规范、MCP server 契约* 上 花的工程时间，比花在模型权重上的多。 **回书链接.** 第 01 章《前言》及第 02 章《四阶段演进》。 ## F.1 · 起点：四个阶段（7 分钟） ### 从 Prompt 到 Harness，为什么每一步都卡在下一步面前 **一句话中心论点.** 工作工程师跟大模型协作的方式，在 2022–2026 年 间经历了 **四阶段演化**；每一个阶段都解决了上一阶段无法解决的问题， 也都有一个上一阶段观察不到的新问题。 **白板时刻.** 画一条时间轴，标四个节点： ``` 2022–2024 2025 2025–2026 2026– Prompt → Context → Skill → Harness 怎么问？ 给看什么？ 怎么把流程写下来？ 造什么环境？ ``` 每一步的 **主要人工制品**： - **Prompt**：一条巧妙的提示字符串。 - **Context**：一张检索 ／ 上下文图。 - **Skill**：一份 `SKILL.md` 或 command 定义。 - **Harness**：**仓库本身** —— `AGENTS.md` ＋ 护栏 ＋ 钩子 ＋ 巡检。 **两句要带走的话.** 1. *前三个阶段都在调「询问层」，Harness 阶段把干预点移到了「环境层」。* 2. *前三个阶段可以一个工程师单独做，Harness 必须以仓库为单位做。* **一个要提防的误读.** "Harness 就是 prompt 长一点。" 不是。Prompt 是 一次对话一次性塞进去的文本；Harness 是留在仓库里、下一轮智能体 也会读到、且违反就被机械拒绝的那一组制品。 **回书链接.** 第 02 章《四阶段演进》完整论证，尤其是 Stage 1 / 2 / 3 各自裂缝的那三段。 ## F.2 · 定义：Harness Engineering 是什么（7 分钟） ### 一句话定义，五条「是」，五条「不是」 **一句话中心论点.** *Harness Engineering 是一门 **刻意设计、运行、 演化 AI 编码智能体周围结构** 的工程学科，目的是让它产出的软件 **可验证、可观测、可理解**。* **白板时刻.** 在 "一句话定义" 下面写三个竖排的字： ``` 可验证 verifiable 可观测 observable 可理解 understandable ``` 然后说：「这三词不是修辞，每一个背后都有一门四十年历史的工程学科。 我们马上讲。」 **五条「是」（快念）.** 1. **面向智能体的规约** —— `AGENTS.md` ／ `CLAUDE.md` 兼容层 ／ `SKILL.md` ／ MCP server manifest，把它们当代码 review。 2. **审批门与护栏** —— pre-commit 钩子、lint 规则、PR 强制评审、 CI 必过项。无论作者是人还是 AI，坏制品一律拦。 3. **沙箱** —— 容器 ／ VM ／ 只读挂载 ／ 临时 worktree，让智能体碰 不到生产。 4. **面向智能体的文档** —— runbook ／ ADR ／ skill 文件，智能体自己 能读懂，以减少环境幻觉。 5. **度量与反馈面** —— 测试通过率、每轮成本、lint 违规数、 from-fail-to-green 时间，团队 *每周* 看一次。 **五条「不是」（更快念）.** - **不是** 推理运行栈（那是 AI Engineering）。 - **不是** ML 评测基准（那是输入，不是本体）。 - **不是** IDE 插件（Cursor ／ Copilot 是客户端，harness 住在仓库里）。 - **不是** 智能体框架 SDK（LangChain ／ AutoGen 是砖块，不是房子）。 - **不是** 部署流水线（DevOps 接管于 "commit 合入之后"）。 **归属检验.** *如果一件制品塑造智能体 **在 commit 之前** 试图 产出什么，它属于 harness；如果它塑造 commit **之后** 发生什么， 它属于 DevOps。* **回书链接.** 第 03 章《什么是 Harness Engineering？》，尤其是 03.1 一句话定义与 03.2 的「IS ／ IS NOT」归属边界。 ### PDCA × Harness：同一圈螺旋，只是「动手的」换了人 **一句话中心论点.** PDCA（Plan–Do–Check–Act）没有过时；在 AI 编程工具 场景里，**Plan** 主要由规约与任务切分承担（`AGENTS.md` ／ ADR ／ issue triage）， **Do** 由智能体与人在编辑器里完成，**Check** 交给测试、 类型检查、lint、CI 与人工评审，**Act** 体现为 Groom —— 更新规约、 收紧钩子、补测试、必要时 **恢复**。四步每转一圈，马具与代码一起进化。 **白板时刻.** 画一个小圆环四格 `P → D → C → A`，在 **D** 格里写一个很小的 「AI」；外圈写一句：**跑偏最常发生在 D 很快、C 很慢的团队。** **规则 / 校验 / 恢复 —— 三道闸（各约 15 秒）.** - **规则（Rules）** —— 把「允许什么 ／ 禁止什么」写成 **作者无关、 机器可读** 的条文：`AGENTS.md` 路径约束、成本上限、pre-commit 策略。 重点是 **可执行**，不是口号。 - **校验（Check）** —— 在合入前用客观信号回答「这轮改动有没有破坏 不变量」：单测、契约测试、静态分析、schema 校验。校验是 PDCA 里 **Check** 这一象限里 **最该先自动化** 的部分。 - **恢复（Recover）** —— 承认智能体有时会把局部改坏：小步提交、 可回滚分支、`git revert`、从已知 **绿色** commit 重启会话上下文。 没有恢复预案的 **Do** 等于赌博。 **一句收口.** *防跑偏不靠「盯紧模型」，靠 **P 足够清楚、C 足够硬、 A 真正改规则**；恢复不是丢脸，是马具的一部分。* **回书链接.** 第 09 章《运行一具马具》（工作流、钩子、恢复心智）， 第 07 章三护法与 Check 的对应；Fence ／ Paddock 清单见第 08 章。 ### Agent Loop：驯服时把手放在哪一层 **一句话中心论点.** 智能体跑偏通常不是「模型性格不好」，而是 **Agent Loop 的某一层缺规约、缺护栏、缺观察**。看清 loop，才知道该改 prompt、改 context、收紧工具，还是补仓库里的 harness。 **白板时刻.** 画一条最小 loop，不要展开成系统架构图： ```text 用户输入 → context → decision → tools → observation ↑ memory / skill / controller ↓ └────────────────── output ─────────────────────┘ ``` **五个把手（各约 15 秒）.** 1. **输入契约** —— 任务边界、验收标准、禁止事项；决定 agent 从哪里出发。 2. **context / memory** —— 检索什么、注入多少、何时裁剪；决定它以为自己 知道什么。 3. **tools / sandbox** —— terminal、API、MCP、文件写权限；决定它能对世界 做什么。 4. **skill / controller** —— 分解步骤、循环节奏、何时停下求证；决定它按 什么顺序做。 5. **harness / evidence** —— `AGENTS.md`、钩子、测试、审计记录、恢复路径； 决定它在什么制度下写你的代码。 **驯服顺序（给听众的行动建议）.** 工具跑偏时，先看 trace：输入是否含糊、 context 是否污染、工具是否太宽、observation 是否被忽略、输出有没有证据。 再用 F.4 的 3×4 矩阵问：**哪一格缺了、哪一格只是写了没人看。** 真正能让 agent 长时间少人工纠正的，不是某个神奇提示词，而是一个清楚的 **Autonomy Envelope**：允许它自己跑的范围、必须停下来的条件、以及失败后 怎么恢复。 **少即是多：不要把整座图书馆塞进 context.** LLM 已经知道很多通用知识； 工程师要补的不是「更多背景」，而是 **收敛方向、规定边界、给出判据**。 好的 harness 像一份总分总结构：开头给目标和边界，中间按步骤 **progressive disclosure**（需要时才展开细节），结尾要求证据、测试和 下一步。塞得越满，越容易把 agent 诱导到无关细节里；立规矩、分层披露， 反而让它更稳定。 **回书链接.** 第 03B 章《AI Agent 与编程工具的结构》；第 08 章《马具解剖》； 附录 F《工程师落地手册》。 ### （与 F.3 的接头）三护法是 PDCA 里被顶到前面的「规约 + 证 + 观」 一句过渡：**SDD 把「想清楚再干」塞进 Plan；TDD 把 Check 自动化；MDD 让 Act 有据可查。** —— 下面 F.3 展开三护法的因果翻转。 ## F.3 · 三护法：SDD → TDD → MDD（7 分钟） ### 为什么有了智能体以后，因果顺序反了 **一句话中心论点.** Harness Engineering 不发明新学科，它 **征召三门 旧学科**，把它们 **重新排序**、前置到智能体动笔之前：**SDD → TDD → MDD**。 传统软件工程没有失效；在 AI 编程时代，很多原则反而更亮了，因为 agent 把模糊需求、缺测试、缺监控这些旧问题放大得更快。 **白板时刻.** 画两条因果链，上下对照： ``` 传统软件工程 ： test → implement → observe (人写代码) TDD (人) MDD AI 辅助工程 ： specify → test → observe (智能体写代码) SDD TDD MDD ``` **为什么翻转？** 在人写代码时代，测试是第一份可执行规约，人会 顶着它改到合为止；**在智能体时代，人写的主要制品移到更上游 ——`AGENTS.md` ／ `CLAUDE.md` 兼容层 ／ skill 文件**。如果规约含糊， 智能体会非常自信地幻觉出一种行为，这时写的测试只会把幻觉钉住， 而不是抓住它。 **不是推翻，是复用.** 需求澄清、模块边界、代码评审、TDD、CI、可观测性、 postmortem，这些老方法没有退场；它们只是从「约束人」变成了 「约束人 + agent 的共同环境」。AI 编程让工程速度上升，也让坏习惯的 传播速度上升，所以传统软件工程里那些朴素原则 —— 小步提交、先定义 done、测试先行、可回滚、可追踪 —— 现在更值钱。 **三护法各一句.** - **SDD — Specification-Driven Development.** *可理解性护法。* 把意图变成智能体能读的规约（`AGENTS.md` ／ ADR ／ prompt 规约）。 - **TDD — Test-Driven Development.** *可验证性护法。* 先写那条 "还红着" 的测试，作为智能体对规约的解释之证伪面。 - **MDD — Metric-Driven Development.** *可观测性护法。* 把每轮 turns-to-green、每月成本、lint 违规数等指标写下来，每周看。 **一个要提防的误读.** 「我们已经有 CI 了啊。」CI 只是 TDD ／ MDD 的 **牧场**。它在合入那一刻才发声；Harness 的问题是在键盘按下那一刻 发声。 **回书链接.** 第 07 章《三大护法》，特别是「为什么因果 顺序要翻转」那一节。 ## F.4 · 骨架：3 × 4 矩阵（7 分钟） ### 一张表，十二格，装下整个框架 **一句话中心论点.** 画不出来的框架是口号，不是分析工具。本书的 分析骨架是一张 **3 × 4 矩阵**：三行 ＝ 三护法，四列 ＝ 四区域。 **白板时刻.** 直接画这张表： ``` 缰绳 护栏 牧场 梳理 Bridle Fence Paddock Groom (写前引导) (写时拒绝) (写后边界) (维持本身) SDD (说) AGENTS.md prompt-lint acceptance sources-of-truth schema 校验 gate 索引 TDD (证) pre-edit pre-commit CI / 集成 flaky 钩子导引 钩子拒绝 测试 隔离 MDD (观) 北极星指标 成本上限 SLI 面板 指标元审 放在显眼处 触顶拒调用 红线 季度轮替 ``` **四区域各一句.** - **Bridle（缰绳）** —— 智能体敲第一个键之前 *看什么、听什么*。 - **Fence（护栏）** —— 不管作者是谁，*一律拒绝* 坏制品。 - **Paddock（牧场）** —— 智能体 *可以撒欢的那块地* 的边界。 - **Groom（梳理）** —— 维护 *马具本身* 的那些重复性工作。 **三个配对的学术框架（各 10 秒）.** - **CAR ／ HarnessCard**（学术参考）：Control ／ Agency ／ Runtime 三层分解，配一份标准化披露格式。本书案例研究打分的骨架。 - **Thoughtworks 三分法**：context engineering ＋ architectural constraints ＋ garbage collection。最像 DevOps 的那一种。 - **LangChain 五件套**：prompts / tools / middleware / memory / harness。 对单个 agent 实例最细的切法。 **回书链接.** 第 08 章《马具解剖》的"出处"与"05.全景"两节。 ## F.5 · 四个案例研究的教训（7 分钟） ### 同样的矩阵，落到四个真实项目上会怎样 **一句话中心论点.** 同一张 3 × 4 矩阵，落到 *运行时、技能库、 工作流、闭源产品* 这四类项目上，会凸显 **不同的强项与不同的风险**。 **白板时刻.** 画一条横轴，从左到右四个点： ``` OpenHarness Superpowers lazy-scrum-team Claude Code 运行时 + 沙箱 技能库 工作流编码 闭源产品 ``` **每一个案例一句话.** - **OpenHarness（第 10 章，港大 DS Lab，开源）** —— *唯一一份 "就像读过第 08 章之后才写的" 开源参考实现*。十个子系统整齐对 应到矩阵格子；Runtime 层 Paddock 尤其强。警醒：它是参考实现， 不是你的运行时。 - **Superpowers（第 11 章，Joseph Vincent，开源）** —— *OpenHarness 的哲学反面。只出技能库，不出运行时*。三十几份 `SKILL.md`， 强在 SDD × Bridle。警醒："光靠技能能不能做我们的马具？" —— *不能*，少了 Fence 与 Paddock。 - **lazy-scrum-team（第 12 章，开源 skill 包）** —— *把 Scrum 角色 与交接本身当马具*。三件可复用的模式：Artefact State Model、 Rework Matrix、Hard vs Soft Gates。 - **Claude Code（第 13 章，Anthropic，闭源；经由张汉东《马书》分析）** —— *本书唯一的闭源案例*。马具职责分布在 bundled prompt ＋ hooks 契约 ＋ skills 系统 *三处*。警醒：闭源意味着你看得到行为但拿不到源， 分析结论永远带一个有效期标注。 **一句带走.** *矩阵是尺子，案例是用它量出来的刻度；不是照抄答案， 而是选一个最接近自己技术栈的参照。* **回书链接.** 第 07–10 章全部。每一章末尾都有一张填好的 HarnessCard， 可直接当"别人是怎么打分的"的参照。 ## F.6 · 自证其身：Lazy AI Coder 四幕（7 分钟） ### 本书对自己的那座仓库做了一次审计，然后改了五处 **一句话中心论点.** *如果这套框架连书的宿主仓库自己都打不分、 改不动，那它就是错的。* 本书第 15 章把 3 × 4 矩阵扣在 `walterfan/async-harness-book` 自己头上，做了一场四幕实盘。 **白板时刻.** 画四个方块横向排开： ``` Act 1 Act 2 Act 3 Act 4 审计 短板 实盘修复 度量 delta (Audit) (Shortcomings) (Fixes) (Measure) ``` **四幕各一句.** - **Act 1 · 审计.** 填一张初始 HarnessCard，落在矩阵的 **左下角** ——SDD × Fence、SDD × Groom、TDD × Fence、MDD × Bridle ／ Groom 是五格最弱的。不是烂仓库，是「有普通可生存技术债」的仓库。 - **Act 2 · 短板.** 列出五个具体短板，每一个都 **打上严重度、 证据指针、落到哪一格**。 - 缺 `make prompts-lint`（SDD × Fence） - MCP 工具 schema 没对齐 handler（TDD × Fence） - 没有 LLM 调用的成本可观测面板（MDD × Bridle） - …… - **Act 3 · 修复.** 四笔修复 commit 进 main；`reproduce.sh` 可复现。 - **Act 4 · 度量 delta.** 重新打分： - SDD 均值 1.75 → 3.00（+1.25） - TDD 均值 2.00 → 2.75（+0.75） - MDD 均值 1.50 → 1.50（+0.00，没动） - **总分 1.75 → 2.42（+0.67）** **一个要提防的误读.** 「HarnessCard 就是虚荣分数。」不是。只要你 把评分尺（附录 D）公开、把证据指针公开、把变化 delta 公开，它就 不是虚荣分数。"分数涨了但事故没少" ——那才是 *vanity delta*。 **回书链接.** 第 15 章《Lazy AI Coder 四幕剧实例》与附录 D《HarnessCard 模板》。 ## F.7 · 周一上班怎么办：30 ／ 60 ／ 90 天清单（7 分钟） ### 最重要的一条：你不用一次性做完十二格 **一句话中心论点.** *本书最重要的单一主张：你不必一次上 12 格。 你挑 **一格**，上它；然后上它所在的 **整行** 或 **整列**；再走一 次完整的 HarnessCard 评审。* **白板时刻.** 画三个里程碑： ``` Day 1–30 Day 31–60 Day 61–90 一格 一行 或 一列 一次完整评审 one cell one row or column full HarnessCard review ``` **每一段的推荐切入点.** - **Day 1–30 · 一格.** 推荐从下面三者挑一个： - **SDD × Bridle** —— 提交一份基于样本的 `AGENTS.md`。便宜，之后 每一轮都赚。 - **TDD × Fence** —— 装一条 `PreToolUse` 钩子，测试红的时候拒绝 写文件。单兵也能受益。 - **MDD × Fence** —— 给 LLM 调用加一个每会话成本上限。过线就 拒绝新调用。 - **Day 31–60 · 一行 或 一列.** 把第一格扩到所在的整行（同一护法下 补齐四个区域）或整列（同一区域下补齐三个护法）。 - **Day 61–90 · 一次完整评审.** 按附录 D 的评分尺打一张 HarnessCard， 公开 delta。 **三条要提防的误读（快念）.** - **"Day 30 我们就搞定了"陷阱** —— 没人给马具本身排维护班，90 天后 那格的分数从 +1 掉回 +0.3。 - **"Groom 以后再说"陷阱** —— 一开始就没把梳理列入范围；没有 `Groom` 的马具不是马具，是装饰。 - **"凑齐了再发布"陷阱** —— 等到十二格都 ≥ 3 分才敢上线。错了。 你要的是「一格上线 ＋ 公开承认其余十一格的分数」，而不是 「全格就绪的神话」。 **回书链接.** 第 16 章《从这里出发，往哪走》12.2「30／60／90 天行动清单」与其配套的陷阱框。 ## F.8 · Q&A ／ 收尾（4 分钟） ### 三句要被记住的话 ＋ 三道常见问 **三句要被记住的话（逐字念）.** 1. **Harness Engineering 不是给流程再加一层**；是在一组已经过载 的清单中 **提取出那一小撮会机械拒绝坏工作的制品**，其余皆为 装饰。 2. **SDD → TDD → MDD，顺序不能乱**；在 AI 辅助时代，规约是人写 的主要制品，测试是对智能体解释的证伪面，度量是闭环信号。 3. **不要一次做 12 格**；挑 1 格，30 天内上线，60 天内扩到一行一列， 90 天内公开一次 HarnessCard。 **三道常见问（每问 60–90 秒）.** - *Q：这跟我们现有的 CI 流水线有什么区别？* - *A：CI 是 TDD ／ MDD 的 **牧场**。它在合入那一刻发声；马具在 键盘按下那一刻发声。如果你家 CI 周五晚上才抓到周二早上可以 在 commit 时抓住的 bug，你缺的是 Fence，不是又一条 CI 规则。* - *Q：三个护法一定要全上吗？* - *A：不用。30／60／90 清单说得很明白：Day 30 上一格就算一步实 质性进展。单兵先做 TDD × Fence；团队通常从 SDD × Bridle 起步。* - *Q：这不就是 DevOps 的重新包装？* - *A：不是。归属检验很简单：塑造 commit **之前** 的，是马具；塑造 commit **之后** 的，是 DevOps。Harness 比 DevOps 早发生一拍。* **收尾画面.** 把开场那张 M → E 图擦掉一半 —— 只留下 E。说： 「从今天起，讨论 AI 编码时，先从环境开始。回到你的项目后，谁愿意做 Day 30 的那一格？」 **回书链接.** 附录 A（FAQ）、附录 B（术语表）、附录 D（HarnessCard 模板）、附录 E（`CLAUDE.md` 兼容样板）。 ## F.App · 给讲者的附加说明 ### 时间表 ``` 00:00–00:02 F.0 开场 00:02–00:09 F.1 四阶段演化 00:09–00:16 F.2 定义 00:16–00:23 F.3 三护法 00:23–00:30 F.4 3×4 矩阵 00:30–00:37 F.5 四个案例 00:37–00:44 F.6 Lazy AI Coder 四幕 00:44–00:51 F.7 30/60/90 清单 00:51–00:55 F.8 Q&A 收尾 00:55–01:00 缓冲 / 追问 ``` ### 讲稿使用建议 - **投影比例.** 每节 1–2 张幻灯片即可；矩阵表格那一张（F.4） 与 30 ／ 60 ／ 90 里程碑那一张（F.7）建议单独成页。 - **白板优先.** F.0、F.1、F.3、F.4、F.6 都带有「白板时刻」—— 它们比幻灯片更能让听众跟着你的因果链走一遍。 - **延伸阅读.** 现场可以把附录 C 的阅读单当作 handout 打印一张。 - **现场动手（可选，把 90 分钟场做成工作坊）.** F.8 之前加一段 「每人填一张 HarnessCard 的 SDD × Bridle 格」，评分 0–5，证据 写自己仓库里那份 `AGENTS.md` 或它的缺席。 ### 一键资源链接 - 本书仓库： - **配套幻灯片（Marp 兼容，带讲者备注）：** `_handson/13-one-hour-talk/SLIDES.md`（见同目录 `README.md` 的 三种用法说明 —— 直接阅读、Marp 导出、粘贴进 Keynote／PPT） - **分钟级 speaker outline：** 同目录下的 `outline.md` - **每页一张 slide 的文字大纲：** 同目录下的 `slides.md` - 30/60/90 清单：`_handson/16-where-we-go-from-here/checklist-30-60-90.md` - HarnessCard 模板：附录 D - `CLAUDE.md` 兼容样板：附录 E - Agent Loop 与 Autonomy Envelope：第 03B 章 - 工程师落地手册：附录 F - 精选阅读单：附录 C ```{toctree} :hidden: outline slides ```