长时智能体工程脚手架的可靠性本质

当一个软件开发任务需要跨越多个上下文窗口时，智能体面临的核心困难并不是“记不住”，而是“记错了还以为自己做对了”。前者是上下文管理问题，后者是可靠性问题。把这两者混为一谈，是许多长时任务系统在功能数量不断增长的同时整体质量却持续下滑的根源。

本文从这一现象出发，讨论模型外部工程脚手架（harness）的本质：它究竟在解决什么问题，为什么更长的上下文仍然不够，以及如何设计一套让“进展”可被验证、可被恢复、可被信任的外部机制。

一、问题的起点：功能变多了，产品却更差了

设想一个典型场景。某长时任务的功能清单中已有 180 项被标记为通过。下一轮，智能体新增了一项会话功能，通过计数变成 181。但这项改动恰好破坏了登录链路——一个关键用户路径发生了退化。

只看清单，项目多完成了一项；看整个产品，系统实际上变差了。这个设想揭示了一个容易被忽视的事实：功能数量只能描述“做了多少”，无法单独回答“系统是否变得更好”。

要回答后一个问题，至少需要三类信息：

• 当前系统处于什么状态：不只是任务列表，还包括代码基线、依赖关系、可运行入口。
• 哪些结果经过验证：验证必须是可复现的、面向真实用户流程的，而不是“看起来跑通了”。
• 发生错误后能否恢复：是否有明确的回退点、交接信息和重启路径。

功能清单、端到端验证、版本提交与启动检查，正是在补足这三类信息。它们共同指向本文的核心问题：一次成功或一组通过标记，距离“可靠”还有多远？

二、为什么更长的上下文仍然不够

长时智能体在多个离散会话中工作。新会话不会自动继承上一轮的完整经历。上下文压缩可以保留摘要，让任务继续运行，但摘要属于有损表示：它可能保留当前推理所需的信息，却不能承诺完整保存项目状态、验证结果和下一步指令。

这里有三个层层递进的失效模式：

第一层：遗忘。 摘要丢失细节，智能体重复劳动或遗漏前置条件。这是最容易被察觉的问题，也是上下文工程最常处理的层面。

第二层：犯错。 智能体基于不完整的记忆做出错误判断，例如在未确认依赖状态的情况下修改共享模块。

第三层：误判自身工作。 这是最危险的一层。智能体完成了某个改动，运行了它认为足够的检查，然后诚实地认为自己取得了进展——而实际上系统已经退化。此时问题不再是“它忘了”，而是“它的自评不可信”。

因此，单纯扩大上下文窗口或改进摘要策略，只能缓解第一层，无法解决第二、三层。可靠性的缺失不能靠记忆弥补，只能靠外部机制约束。

三、工程脚手架的本质：把状态与验证外部化

所谓 harness，指模型外部的工程脚手架，包括提示词、工具、文件约定、执行循环、测试与恢复机制。它的本质可以概括为一句话：

把智能体不可靠的内部状态，转化为可检查、可复现、可回退的外部状态。

围绕这一本质，一套完整的脚手架通常包含四个职责：

1. 状态外置。 需求、功能清单、启动脚本、进度文件、版本仓库，构成一个独立于模型上下文的状态载体。模型可以遗忘，但这些文件不会。每一轮开始时，智能体从文件中重建工作现场，而不是依赖上一轮的记忆。

2. 粒度约束。 每轮只完成一个功能，验证后提交，并给下一轮留下交接信息。单功能粒度降低了单轮变更的复杂度，使“验证—提交—交接”形成闭环。这是用流程约束换取可验证性。

3. 验证分层。 单元测试和接口检查能覆盖局部逻辑，但无法发现端到端问题——例如真实用户流程中的页面跳转、状态传递、异步时序。浏览器自动化等工具的价值在于，让智能体按真实用户路径验证功能，而不是只验证函数返回值。验证层次的完整性，直接决定“通过”二字的含金量。

4. 恢复机制。 版本提交提供回退点，启动检查确认环境可用，交接信息说明下一步指令。三者合起来回答一个问题：如果本轮出错，下一轮能否在不返工的前提下继续？

一个最小化的交接文件示意如下：

# handoff.yaml
round: 42
completed: [feature-041]
verified_by:
  - unit: auth/login_test
  - e2e: user_login_flow
regression_watch: [session-init, token-refresh]
next: feature-042
known_issues:
  - "登录页在弱网下超时提示缺失，待确认是否本轮引入"
baseline_commit: a1b2c3d

这份文件的关键不在于格式，而在于它强制智能体回答三个问题：做了什么、凭什么说通过了、下一轮从哪里开始。把自评转化为可审计的记录，是抑制“误判自身工作”的最直接手段。

四、从“一次通过”到“可靠”：评估框架

原文材料属于内部实践、失败案例与工程演示，未公开正式任务集、重复运行次数、独立评估、成本统计或逐项消融实验。阅读这类材料时，需要保留这个证据边界：演示能说明方案可行，但不能证明方案稳定。

以此为前提，可以提出一个更严格的问题框架，用于判断长时智能体的进展是否可信：

• 可复现性：同一任务在不同轮次、不同初始状态下，是否得到一致结果？单次成功不构成证据。
• 回归可见性：新增功能是否触发既有路径退化？清单计数是否掩盖了回归？
• 验证覆盖度：通过标记背后是哪一层验证？单元、接口、端到端各自覆盖了多少关键路径？
• 恢复成本：从失败点恢复到可继续状态，需要多少人工介入？
• 成本结构：验证与交接的开销占比多少？这部分开销是否换来了返工率的下降？

这五个维度共同构成一个判断：可靠性不是“通过率”，而是“在多次运行与多次变更下，进展仍然可被验证且不倒退”的性质。

五、实践建议

基于上述分析，落地时可遵循几条原则：

1. 先建状态，再谈执行。 初始化阶段就把需求、清单、启动脚本、进度文件、版本仓库建立起来，让后续每一轮都有可依附的外部骨架。
2. 单轮单功能，验证后提交。 用流程约束控制变更面，让每次提交都对应一个可验证的功能点。
3. 验证分层设计。 单元测试保证局部正确，端到端验证保证用户路径正确，两者不可互相替代。
4. 交接信息结构化。 明确写出已完成项、验证依据、回归关注点、下一步指令与基线版本。
5. 保留证据边界。 对任何“演示级成功”保持克制，区分“可行”与“可靠”，用重复运行与回归检查逐步积累可信度。

结语

长时智能体的工程脚手架，表面上是提示词、工具与文件约定的集合，本质上是一套对抗遗忘、错误与自我误判的外部信任机制。上下文可以更长，摘要可以更好，但只要执行者会遗忘、会犯错、还会误判自己的工作，进展就必须被外部化、被验证、被记录、被回退。功能清单回答“做了多少”，而脚手架要回答的是另一个问题：我们凭什么相信它正在变好。