第五章的追问#

第五章让我们完成了从"问题到框架、从理论到人"的闭环。我们知道了 AI 能做什么，知道了 Harness 如何让 AI 协作，知道了 DevOps 和 SRE 如何为 Harness 提供理论土壤，也知道了人在 Harness 中应该扮演什么角色。

但这里有一个关键问题还没有回答：这些碎片如何组装成一个可运转的系统？

Planner 产出的 Design、Generator 写出的代码、Evaluator 运行的验收、人类的判断——这些产出在软件全生命周期中如何流转？一个阶段结束后，信息如何传递给下一个阶段？更重要的是，运营阶段的反馈如何回流到规划阶段，让整个系统持续进化？

这就是本章要设计的"全生命周期闭环框架"——不是一张分工表，而是一张运转图。

6.1 从线性流程到闭环系统#

传统的软件生命周期通常被画成一条直线：需求分析 → 架构设计 → 编码实现 → 测试验证 → 部署上线 → 运维监控。这条线的终点是"交付"——项目做完了，团队解散，进入维护模式。

但 Harness 的生命周期不是一条直线，而是一个闭环。交付不是终点，运营数据回流到规划阶段才是新一轮迭代的起点。

这个转变的本质，是把软件生命周期从"瀑布"重新理解为接力赛。在接力赛中，每一棒的责任不是"跑完自己的路段"，而是"把交接棒完好地传递给下一棒"。交接棒掉了，比赛就输了——无论你这一棒跑得有多快。

Harness 的"交接棒"就是上下文文件（Context Handoff）。

第二章介绍了上下文交接的概念：一个轮次结束时，Planner 将本轮的完整上下文——任务清单、代码变更、验收结果、人类反馈——整理成结构化的交接文件。下一个轮次启动时，新的 Agent 直接读取这份文件，零损耗地继承全部上下文。

但第二章只讲了一个轮次内部的交接。本章要讲的是：Harness 的全生命周期由多个轮次组成，轮次之间的上下文交接构成了闭环的骨架。

6.2 四阶段管道：重叠运转的生命周期#

Harness 的闭环由四个大阶段构成：规划期、实现期、交付期、运营期。

阶段Harness 核心动作关键产出
规划期Planner 将人类需求翻译为 DesignDesign（用户旅程、效果描述、验收标准）
实现期Generator 读取 Design，自行拆解任务并编码；Evaluator 分层验收代码 + 测试报告
交付期自动化部署流水线将代码发布到生产环境部署配置 + 监控规则
运营期可观测性系统收集监控数据，异常检测触发响应监控数据 + 反馈报告

但这张表有一个误导性：它让四个阶段看起来是串行的——做完规划再做实现，做完实现再做交付，做完交付再进入运营。

Harness 的真实运转方式是重叠的。Planner 在 Generator 编码的同时，已经在读取上一轮运营期的监控数据，开始规划下一轮的 Design。Generator 完成当前任务后，不需要等待 Planner"做完"——新的 Design 已经准备好，Generator 可以立即开始下一轮实现。

第一轮迭代：
规划期 ──[Design A]──► 实现期 ──[代码A]──► 交付期 ──[部署A]──► 运营期
                           ▲                                      │
                           │                                      │
第二轮迭代：                │         监控数据实时回流              │
规划期 ◄───────────────────┘◄─────────────────────────────────────┘
   │
   ▼
实现期 ──[代码B]──► ...

这种重叠运转的关键在于：上下文交接是连续的，而不是脉冲式的。 监控数据不是等运营期"结束"才一次性交接给 Planner，而是持续流入。Planner 持续消费这些数据，持续产出新的 Design。Generator 持续读取最新的 Design，持续编码实现。

四阶段像四条并行的传送带，各自以独立的速度运转，但同一轮次的产出按顺序交接——Design A 必须先交接给 Generator，Generator 才能开始实现代码 A；代码 A 必须先通过 Evaluator 验收，才能进入交付期部署。

6.3 上下文交接：四阶段的接力机制#

第二章把 Context Handoff 定义为"一个轮次结束时的信息打包传递"。本章要把这个定义往前推一步：Harness 的验收本质上就是上下文交接的质量检查。

传统的验收是"检查清单打勾"——测试用例全绿、代码覆盖率达标、安全扫描无高危漏洞。但 Harness 的验收标准是另一个维度：交接文件的质量，是否足以让下一阶段零损耗地继承全部上下文，直接开始工作？

这个标准把"验收"从"检查动作"重新定义为"交接动作"。不是看产出对不对，而是看产出能不能传下去。

6.3.1 交接即验收#

每个阶段向下一个阶段交接时，都需要回答三个问题：

  1. 交接文件包含什么？——下一阶段需要哪些信息才能零起点开始工作？
  2. 验收标准是什么？——接收方能否基于这份文件直接开始，无需额外澄清？
  3. 不通过怎么办？——交接质量不达标时，当前阶段如何修正？

这三个问题构成了 Harness 闭环的"闸口机制"。每个阶段都有一道闸口：交接质量达标，闸门打开，流程进入下一阶段；交接质量不达标，闸门关闭，当前阶段继续迭代，直到交接文件合格。

6.3.2 规划期 → 实现期：Design 交接#

规划期向实现期交接的文件是 Design——但这里的 Design 不是传统意义上的"设计文档"，而是一份机器可读的执行蓝图。

Design 交接文件至少包含：

  • 用户旅程：用户如何完成目标流程，每个步骤的系统响应是什么
  • 效果描述：系统应该呈现什么状态、禁止出现什么状态
  • 验收标准：功能、性能、安全、兼容性的量化指标
  • 约束条件：技术栈限制、性能基线、安全红线、与现有系统的接口契约
  • 决策痕迹：为什么这样设计、排除了哪些备选方案、已知的技术债

验收标准：Generator 能否基于这份 Design 直接开始编码，无需向 Planner 追问"这里是什么意思"？

如果 Generator 读完 Design 后还有模糊点——比如"支持高并发"没有定义 QPS 基线、“兼容旧版本"没有定义兼容范围——交接就不合格。Design 退回 Planner 补充，直到模糊性被消除。

6.3.3 实现期 → 交付期：代码与已知问题清单交接#

实现期向交付期交接的文件不仅包含代码和测试报告，还包含一份至关重要的文档——已知问题清单。

这不是耻辱柱，而是风险透明度。已知问题清单明确列出：

  • 当前版本有哪些已知但未修复的问题
  • 每个问题的影响范围和触发条件
  • 为什么这些问题在这个 sprint 不被修复（如：超出范围、成本过高、影响可控）

验收标准：运维团队能否基于这份交接文件独立完成部署，并对上线后的风险有清晰预判？

传统开发中，已知问题散落在 bug 系统、邮件、口头沟通中，运维上线时往往对"这个版本有什么坑"一无所知。Harness 要求把这些信息结构化地写入交接文件，让下游明确知道风险在哪里，而不是在故障发生后才被动应对。

6.3.4 交付期 → 运营期：部署与监控配置交接#

交付期向运营期交接的文件核心不是代码，而是可观测性配置——系统如何被监控、什么指标代表健康、什么告警需要响应、出了问题怎么回滚。

交接文件至少包含：

  • 部署配置：环境变量、依赖服务地址、启动参数
  • 监控指标定义：关键 SLI（请求延迟、错误率、吞吐量）及其正常范围
  • 告警规则：什么条件下触发什么级别的告警，通知给谁
  • 应急预案：常见问题（如内存泄漏、数据库连接池耗尽）的识别特征和回滚步骤

验收标准：运维系统能否基于这份交接文件自主监控和响应常规异常？

这与第四章的"可观测性"论述形成呼应：Harness 依赖可观测性系统提供的感官输入来运作。如果交接文件没有定义清楚"什么是正常、什么是异常”，运营期的监控就是盲目的。

6.3.5 运营期 → 规划期：反馈数据实时回流（闭环的关键）#

运营期向规划期交接的是反馈数据——但这道交接与传统开发有本质不同：它不是在项目"结束"时才发生，而是持续实时发生的。

监控数据持续流入 Planner：

  • 性能趋势：API 响应时间是否在缓慢恶化？错误率是否在悄然上升？
  • 用户行为：哪些功能被高频使用？哪些路径存在卡顿？用户在哪里放弃？
  • 故障模式：系统在什么条件下容易出问题？是否有反复出现的异常？
  • 业务反馈：运营团队的人工观察、客服记录的用户投诉、产品经理的市场洞察

Planner 持续消费这些数据，持续产出新的 Design。Generator 完成当前任务后，立即拿到基于最新反馈的 Design 开始下一轮实现。

这是闭环的闭合点。 没有这道回流， Harness 就只是一个线性的流水线——从需求到部署，然后停止。有了这道回流，Harness 才成为一个自我进化的闭环系统：运营数据驱动规划调整，规划调整驱动新的实现，新的实现产生新的运营数据，循环往复。

6.4 监控回流：两种闭环路径#

运营期的监控数据回流，根据问题的严重程度，走两条不同的路径。

自动修复闭环（小问题 AI 自治）#

当监控检测到已知模式的轻微异常时， Harness 可以启动自动修复闭环：

监控告警 ──► 诊断定位（Generator 分析日志/指标）
                │
                ▼
        生成修复方案 ──► Evaluator 验收修复
                │
                ▼
        自动部署 ──► 监控验证修复效果

这条路径适用于模式明确、影响可控、修复方案标准化的问题。例如：内存使用率超过阈值 → 诊断发现是缓存未设置 TTL → Generator 添加缓存过期逻辑 → Evaluator 验证修复不引入新 bug → 自动部署 → 监控确认内存使用率回落。

人类决策闭环（大问题人工介入）#

当监控检测到未知模式的严重异常时，需要人类介入决策：

监控告警 ──► 人工判断（是否认识这个问题？）
                │
                ▼
        人类决策：修复 / 降级 / 回滚 / 接受
                │
                ▼
        启动新 Harness 迭代（人类输入需求，Planner 产出 Design）

这条路径适用于模式未知、影响严重、需要业务判断的问题。例如：支付链路出现间歇性超时 → 人工判断发现是第三方接口限频 → 决策层决定"先降级为异步支付，同时联系第三方扩容"→ 这个决策作为新需求输入 Harness，启动新一轮迭代。

这两条路径与第五章的"人机协作分层"完美呼应：小问题 AI 自治，大问题人类介入。 自动修复闭环让系统具备自愈能力，人类决策闭环确保关键判断权仍在人手中。

错误预算：闭环的燃料表#

第四章把错误预算定义为 Harness 的"硬约束"——当某项验收标准反复无法通过、评估分数进入平台期时， Harness 停止迭代。这个机制在闭环中有另一个作用：错误预算是闭环的燃料表。

  • 错误预算充足时，系统有余量启动优化迭代（如重构、性能提升）
  • 错误预算紧张时，系统应收敛变更，优先保证稳定性
  • 错误预算耗尽时，系统必须停止发布新功能，全力修复已知问题

错误预算把"是否继续运转"从一个主观决策变成了客观约束。闭环不会因为"感觉还能再试试"而无限消耗资源，也不会因为"怕出问题"而停止进化。它在预算边界内自动调节节奏。

6.5 本章小结#

让我们回顾本章的核心脉络。

闭环的本质： Harness 的生命周期不是线性瀑布，而是四阶段重叠运转的闭环系统。规划期、实现期、交付期、运营期像四条并行的传送带，各自独立运转，但同一轮次的产出按顺序交接。

运转的骨架：上下文交接是闭环的骨架。每个阶段的验收不是"检查清单打勾"，而是"交接文件的质量足以让下一阶段零损耗继承"。交接质量不达标，闸门关闭，当前阶段继续迭代。

闭环的引擎：监控数据从运营期实时回流到规划期，Planner 持续消费反馈、持续产出新 Design。这是闭环的闭合点，也是系统自我进化的驱动力。

闭环的分层：小问题走自动修复闭环（AI 自治），大问题走人类决策闭环（人工介入）。错误预算作为燃料表，在预算边界内自动调节运转节奏。

至此，我们从"AI 能做什么"（第一章）→“如何让 AI 协作”（第二章）→“如何在工程理论中落地”（第三、四章）→“人如何与 AI 共处”（第五章）→“如何组装成闭环系统”（本章），完成了从问题到框架、从理论到系统、从碎片到闭环的完整旅程。

但闭环框架只是一个"容器"。容器里装什么角色、这些角色有什么能力边界、它们之间如何协作——这些问题需要更细粒度的设计。下一章，我们将进入 Agent 角色体系的细化：Planner、Generator、Evaluator 不是单一角色，而是多种专业化变体的集合。复杂的系统需要专业化的分工。

本章内容说明

  • 论文原意：Harness 三角色（Planner / Generator / Evaluator）体系、上下文交接（Context Handoff）机制、评估迭代与硬阈值停止条件，源自 Anthropic《Harness Design for Long-Running Application Development》。
  • 作者分析：“四阶段重叠运转"的生命周期模型、“上下文交接即验收"的独特视角、“四阶段接力机制"的闸口设计、“实时回流"作为闭环闭合点的论述，为本文作者基于 Harness 框架的分析推导。
  • 工程扩展：“已知问题清单"作为交接文件的标准组成部分、“自动修复闭环 vs 人类决策闭环"的分层设计、“错误预算作为闭环燃料表"的扩展应用，是基于工程落地实践的推导，非论文原文。
  • 虚构示例：本章未构造具体场景示例，框架设计基于通用软件生命周期模型推导。