agent-">Agent工程脚手架的可靠性本质：从“功能数增长”到“系统可信进展”

当一个智能体（Agent）需要跨越多轮对话、多个上下文窗口来完成一项软件开发任务时，工程团队很快会遇到一个比“上下文长度不够”更棘手的问题：执行者会遗忘、会犯错，还会误判自己的工作在进步。 在这种情况下，我们凭什么相信它真的在变好？

本文围绕“长时运行智能体的工程脚手架（harness）”这一主题，讨论三个层层递进的问题：为什么更长的上下文仍然不够；功能清单为什么只能回答“做了多少”而无法回答“是否更好”；以及一套可靠的脚手架应当具备哪些工程要素。文中的“脚手架”指模型外部的工程支撑体系，包括提示词组织、工具调用、文件约定、执行循环、测试与恢复机制，而非模型本身的能力。

一、问题的起点：离散会话中的“失忆”与返工

长时运行的智能体通常在多个离散会话中工作。新会话不会自动继承上一轮的完整经历：上一轮读过哪些文件、跑过哪些命令、哪些假设已被证伪、下一步该做什么，这些信息不会天然传递。上下文压缩可以保留摘要，让任务继续运行，但摘要本质上是有损表示——它能保留当前推理所需的片段，却无法承诺完整保存项目状态、验证结果与下一步指令。

这就带来一个工程上的现实：如果脚手架设计不当，Agent 会在“读文件—改代码—跑测试—发现不对—再读文件”的循环中反复消耗预算，而项目整体并未前移。问题的核心不是“记忆容量”，而是状态的持久化与可验证性。

一个可用的思路是把长任务拆成两个阶段：

1. 初始化阶段：由初始化 Agent 建立需求描述、功能清单、启动脚本、进度文件与版本库，把“项目是什么、做到哪、怎么跑起来”固化为文件事实。
2. 迭代阶段：每轮编码 Agent 只完成一个功能项，验证通过后提交代码，并为下一轮留下交接信息（当前状态、已验证结果、遗留问题、下一步建议）。

这种“单功能推进 + 持久化交接”的节奏，本质上是用工程约定替代不可靠的记忆。

二、功能清单的局限：数量不等于质量

设想一个场景：功能清单里已有 180 项被标为通过。下一轮，Agent 新增了一项聊天功能，通过数变成 181。但这项改动恰好破坏了登录流程。只看清单，项目多完成了一项；看整个产品，关键用户链路却发生了退化。

这个设想说明：功能数量只能描述“做了多少”，无法单独回答“系统是否变得更好”。 后一个问题至少需要三类信息：

• 当前系统处于什么状态：代码、配置、依赖、数据迁移的实际形态；
• 哪些结果经过验证：不是“我认为它能跑”，而是“有可复现的检查证明它能跑”；
• 发生错误后能否恢复：是否有版本记录、回滚路径与可重放的启动流程。

功能清单、端到端测试、版本提交与启动检查，正是在补足这三类信息。它们共同回答的问题不是“通过了几项”，而是“这次进展是否可信”。

三、验证的层次：单元测试之外的真实用户流程

原文材料中提到，单元测试与接口检查（例如用命令行工具做 HTTP 探测）无法发现某些端到端问题。原因并不复杂：单元测试验证的是函数级契约，接口检查验证的是单点响应，而真实用户流程涉及页面跳转、状态保持、异步加载、权限切换等多步交互，任何一步的时序或状态错误都可能让关键链路失效。

因此，可靠的脚手架通常需要三层验证：

第一层：单元测试        —— 函数级正确性，快、细、覆盖边界
第二层：接口/集成检查    —— 服务契约与数据流，验证单点行为
第三层：端到端流程验证   —— 按真实用户路径操作，验证关键链路

第三层往往需要浏览器自动化或类似的交互式工具，按“登录—进入功能—触发操作—检查结果”的真实顺序执行。它的价值不在于覆盖率数字，而在于复现用户视角的失败。对于长时运行的 Agent，端到端验证还有一个额外作用：它把“我认为完成了”转化为“我按用户路径验证过”，从而降低自我误判的概率。

需要强调的是，这类实践在公开材料中多以内部演示与失败案例的形式出现，通常缺少正式任务集、重复运行次数、独立评估与成本统计。阅读相关经验时应当保留这一证据边界：工程演示能说明“可行”，但不能直接等同于“统计显著”。

四、脚手架的五个工程要素

把上述讨论收敛为一套可落地的设计，长时运行智能体的脚手架至少应包含以下要素。

1. 持久化的项目状态

用文件而非对话历史承载状态：需求文档、功能清单、进度日志、启动脚本、环境说明。文件的好处是可读、可 diff、可版本化，且不依赖某次会话的上下文窗口。

project/
  REQUIREMENTS.md     # 需求与约束
  FEATURES.md         # 功能清单与状态标记
  PROGRESS.md         # 每轮交接：已完成/已验证/遗留/下一步
  run.sh              # 一键启动与自检

2. 单功能推进的节奏

每轮只推进一个功能项，完成即验证、验证即提交。这个约束看似降低吞吐，实际上减少了“多处半成品互相干扰”的调试成本，也让交接信息更清晰。

3. 分层的验证闭环

单元测试、接口检查、端到端流程三层并存，并明确每层负责回答的问题。关键链路必须有端到端用例，否则“通过数增加”可能是假进展。

4. 版本记录与可回滚

每次通过验证的改动都应形成可追溯的提交。版本记录不仅是备份，更是“错误发生后能否恢复”的前提。没有回滚路径的自动化，本质上是在放大风险。

5. 启动自检与交接约定

每轮开始前执行启动脚本与自检，确认环境可用、依赖完整、关键链路可跑；每轮结束时写入交接信息，明确下一轮的起点。这两件事把“离散会话”缝合为“连续工程”。

五、从“通过标记”到“可靠进展”

回到最初的问题：一次成功或一组通过标记，距离“可靠”还有多远？答案是，中间隔着一整套工程约束。可靠进展至少满足三个条件：

• 可复现：同样的启动脚本与验证流程，换一个会话也能得到同样的结论；
• 可验证：关键链路有端到端证据，而非仅有点状通过标记；
• 可恢复：出现退化时能定位、能回滚、能重放。

功能清单回答“做了多少”，验证闭环回答“是否可信”，版本与交接回答“能否恢复”。三者合起来，才构成对“系统正在变好”的工程信心。

对于企业级研发场景，这套思路也可以与通用云产品类别配合：用对象存储留存构建产物与验证日志，用容器平台保证环境一致性，用日志与监控服务观测长时任务的执行轨迹。这些能力属于通用工程基础设施，其价值在于让“可复现、可验证、可恢复”从约定变成默认。

结语

长时运行智能体的核心挑战，不是让模型记住更多，而是让工程体系在模型会遗忘、会犯错、会误判的前提下仍然可信。脚手架的本质，就是用文件、验证、版本与交接，把“一次成功”转化为“可持续的可靠进展”。当团队把功能数量指标升级为状态、验证与恢复三位一体的证据体系时，“Agent 是否在进步”才不再是一个需要凭感觉回答的问题。