应用部分 0. AgentClinic-production 实验室
状态:学习路径的标准内容。 本部分不引入新技术。它说明如何将第二卷作为第一卷之后的单一实验分支来阅读。
第一卷构建了一个小型 AgentClinic:路由、SQLite、功能规格、检查和评审。第二卷中,同一项目被用作教学级生产模型。我们不要求真正的 Kubernetes、Grafana、PagerDuty 或 GitOps。这些词在场景中代表角色:信号从何而来、何种操作可能危险、何处需要回滚、何种工件证明解决方案。
如果将各章作为一组独立的高级技巧来阅读,本卷会很快变得沉重。请换一种方式阅读:一个项目、一个主生产流程、一个不断增长的证据包。默认使用 high_memory_usage 来通过考核;其他事件仅作为展示单独机制的小型实验窗口。
第一遍的实用规则:capstone/README.md 应回答一个事件案例。其他章节的本地示例可以使用不同事件,但只有可验证的原则才计入最终包。例如,从 autoscale_200pct 转移的不是第二个案例,而是保护规则(guard)「不得超出配额扩大影响范围」。从 cdn_error_budget_burn 转移的不是新服务,而是反古德哈特定律不变量「不得以静默 P0 为代价改善 MTTR」。
阅读之前
第 0 部分是方法论性质,没有教学案例。这里没有步骤和控制事实;任务是设定本卷的地图并协调执行栈。从下一章开始,标准的「阅读之前」模块将回归,并作为章节与考核之间的契约发挥作用。
目标
在第 1 章之前需要理解四件事:
- 哪个教学生产案例贯穿考核包;
- 哪些文件被视为每章的成果;
- 哪些命令真正可运行,哪些只是未来生产层的接口;
- 教学最小路径在哪里结束,完整实施路径从哪里开始。
贯穿案例
基础场景名为 AgentClinic-production。这是同一个 AgentClinic,但现在它周围有运维流程。主要考核案例是 appointments-api 中的 high_memory_usage:便于将其推进到 webhook 规范化、readiness 网关、试运行和最终证据包。附加案例展示单独机制,但不必须混合在一个 capstone/ 中。
- 服务
appointments-api; - 告警
high_memory_usage、autoscale_200pct、appointment_latency/appointment_latency_spike、node_not_ready、cdn_error_budget_burn; - 必须经受
/clear、模型切换和他人评审的规格; - 禁止无证据的危险操作:扩大影响范围、丢失审计、静默关闭 P0、自动绕过回滚。
教学分支不必包含真正的生产代码。capstone/ 中的工件、examples/templates/ 中的模板和 examples/ 中的可运行示例已足够。如果某章使用非 high_memory_usage 的案例,仅在 capstone/ 中记录可验证的产出:需要转移到主案例的何种缺陷、反例、预算风险或不变量。
简短转移地图:
| 章节本地案例 | 转移到 high_memory_usage 的内容 |
|---|---|
node_not_ready | 需求来源和「无恢复证据不得关闭」规则 |
appointment_latency / appointment_latency_spike | 一个规格缺陷类别或 stress-mutator 结果(区别:appointment_latency — 事件类别「/agents 路由延迟」,appointment_latency_spike — 第 2 和 5 章 examples/stress-mutator/base/base_spec.json 中的具体教学 payload) |
autoscale_200pct | 扩大影响范围的反例或预算风险 |
cdn_error_budget_burn | 一对 KPI + 反古德哈特定律的保护指标 |
执行栈
第一卷中 AgentClinic 是一个 TypeScript、Hono、服务端 JSX、SQLite 和 Vitest 的应用。这个栈并未消失:在教学模型 AgentClinic-production 中,它仍然是产品本身的栈。
第二卷出现了第二层代码 —— book2/examples/ 中的小型可运行脚本。它们用 Python 标准库编写,仅为了让一个人能在自己的机器上几秒内运行章节的最小示例,无需搭建基础设施。这不是产品栈的变更,也不是暗示生产级 AgentClinic 被重写为 Python。这些是教学模拟器:stress-mutator、对决、Spec CI、令牌预算、readiness 计算器。在真实项目中,这些检查通常作为 pre-commit、GitHub Actions、MCP 工具或自有栈的服务来实现 —— 这里 Python 只是无需构建即可运行的最便宜语言。
规则很简单:book2/examples/ 中的所有内容都可以作为 python3 ... 运行,无需依赖。章节中标记为 [project script] 或 [conceptual interface] 的所有内容 —— 是未来脚本或集成到您项目中的形式,不绑定到 Python。
最小路径
如果时间有限,请按以下方式阅读第二卷:
- 阅读本部分和所选可运行示例的 README。
- 在第 1–3 章中填写三个手工工件:
genealogy.md、poisoned/fixed 对和constitution.md。
- 在第 4–11 章中仅运行
examples/中的[runnable]命令;将其他案例的结果作为原则转移到capstone/,而非作为新领域。 - 在第 12 章中按诊断检查清单验证包。
- 在第 13 章中按一个事件组装小型
capstone/。
最小路径不需要编写外部编排器、MCP 服务器、Kubernetes 集成或真正的 CI 网关。这些元素属于完整路径。
路径验证很简单:每章之后,capstone/ 中应出现一个新的可验证产出。不是完整的生产流程,而是一个可以展示给他人的小记录。
> 如何阅读表格。 「产出」列有意用通俗语言描述,不使用第 4–13 章的术语。如果右栏出现下方短词典中尚未出现的词,它将在需要的那章引入。不要试图通过此表格背诵本卷词典。
| 章节之后 | 最小产出 |
|---|---|
| 1 | genealogy.md 中一个带有两个来源的需求 |
| 2 | 一对「有缺陷 / 已修复」的规格,能展示一个错误类别 |
| 3 | constitution.md 包含两条不可变规则和一条有期限的规则 | | 4 | 一条规则的最小反例或下一个限制器的表述 | | 5 | stress-mutator 的冒烟测试结果或验证器捕获了哪些突变的简要报告 | | 6 | 一个接受和一个拒绝的候选影子规则(可能进入规格的规则) | | 7 | Spec CI 的一行:已覆盖什么,被阻塞什么 | | 8 | 一个有争议变更的裁决文件及证据链接 | | 9 | 模型预算耗尽风险和切换至廉价层的阈值 | | 10 | 一个目标指标和一对反古德哈特定律的保护指标 | | 11 | 生产准入裁决和允许操作的 dry-run | | 12 | 三个 blocker / owner / next_check 条目 | | 13 | 按一个事件组装的 capstone/,包含评分标准的五个 PASS 行 |
如果章节中遇到额外术语但没有此产出,请先完成产出。术语可以稍后补充。
作为参考,请将已填写的示例 [examples/templates/capstone-dossier.md](examples/templates/capstone-dossier.md) 放在手边。这不是无脑复制的模板,而是回答「第一遍之后应留下什么痕迹?」的最小形式。
第一遍的最小词典很短:
capstone/—— 一个事件的最终证据包;genealogy.md—— 需求来源和置信度;validation.md—— 命令、手工事实和阻塞项;judgment.md—— 有争议变更的裁决;readiness.md—— 操作为何被允许、被阻塞或进入半手动模式。
所有其他术语仅在帮助填写这些文件之一时才需要。如果术语不影响当前章节产出,第一遍阅读时不要停留。
真正运行什么
第二卷使用三种命令块:
- [runnable] —— 按所写运行。示例位于
book2/examples/。 - [project script] —— 这是您项目中未来脚本的契约。如果旁边没有标注可运行替代方案,该命令不必存在于教材仓库中。
- [conceptual interface] —— 未来集成的形式。教学过程中不需要运行。
规则很简单:考核包只能引用您实际运行的事实,或无需聊天记录即可阅读的手工工件。
首次冒烟测试
在阅读第 4–11 章之前,验证本地示例能正常工作是有用的:
bash book2/examples/smoke_all.sh
脚本在 book2/examples 的临时副本上运行冒烟测试,因此不会在工作树中留下 out/ 和 __pycache__。如果时间有限,请打开 examples/README.md 并仅选择当前正在阅读的章节块。
考核工作目录
创建未来包的目录:
mkdir -p capstone
暂时保持为空。在第 1–12 章中,您将逐渐理解哪些文件会进入其中。不要在一个证据包中混合多个事件:一个文件可以引用另一个案例的可运行替代方案,但解决方案必须解释一个主要事件。
capstone/
README.md
genealogy.md
poisoned-spec.md
fixed-spec.md
constitution.md
validation.md
judgment.md
budget-note.md
goodhart-note.md
readiness.md
antipattern-audit.md
此结构重复第一卷:先意图和边界,然后计划和事实,然后评审和最终包。第二卷的唯一区别是事实不关乎单一功能,而是关乎危险操作的生产准入。
第一遍时不要仅因为章节中提到了完整路径的文件就将其加入 capstone/。scorebook、metric_network、decision_hash、precedents.md 和 CI 报告仅在您真正创建它们或能解释哪个可运行替代方案证实同一原则时才需要。
为便于定位,哪章开启哪个文件:
capstone/ 文件 | 开启章节 |
|---|---|
genealogy.md | 第 1 章 |
poisoned-spec.md / fixed-spec.md | 第 2 章 |
constitution.md | 第 3 章 |
validation.md(happy + negative + 反例) | 第 4 和 7 章 |
judgment.md | 第 8 章 |
budget-note.md | 第 9 章 |
goodhart-note.md | 第 10 章 |
readiness.md | 第 11 章 |
antipattern-audit.md | 第 12 章 |
README.md(最终组装) | 第 13 章 |
如果途中章节出现此列表之外的第四或第五个文件 —— 这是完整路径。将原则记录为一行并继续。
控制事实
本章之后,已选定一个主要事件案例,已创建空的 capstone/,并已通过 bash book2/examples/smoke_all.sh 命令验证了可运行示例或因明确原因推迟。如果您无法说出主要案例和第一个将进入 capstone/ 的文件,现在进入第 1 章还为时过早。
控制问题
- 为什么 AgentClinic-production 是教学模型,而不是要求搭建真正基础设施?
[runnable]与[project script]有何区别?- 为什么最终
capstone/中不能将high_memory_usage和autoscale_200pct作为两个平等案例混合? - 为什么最终
capstone/必须在没有聊天记录的情况下也能理解?