Anthropic Harness Engineering：AI 智能体跨会话记忆难题解决方案
引言
在 AI 从反应式聊天机器人向主动式智能体演进的过程中，一个根本性的架构障碍始终存在：上下文窗口。即便是最先进的大模型，其记忆本质上也是临时的——每次新会话开始，上下文被重置，之前的工作成果消失殆尽。
Anthropic 的研究团队发现，当前最常用的「压缩」（Compaction）技术——把历史对话摘要化以节省空间——只是创可贴，不是根治方案。要实现生产级软件的质量，智能体需要一个结构化的「编排框架」（Harness），模拟人类高级工程师团队的制度记忆和规范工作流。
「轮班工程师」困境
想象一个软件工程部采用 24 小时轮班制，但有一个奇怪的系统限制：每次新工程师上班时，他们都得了完全的失忆症。他们不知道上一班修了什么 Bug、项目到了哪一步、代码库有哪些坑。他们花了白班头四个小时到处翻代码库、猜测前任的意图，甚至还经常弄巧成拙地撤销了前任的工作。
这就是「长运行智能体问题」（Long-Running Agent Problem）的生动写照。现代 AI 智能体虽然能力越来越强，但仍然只能在离散的会话中运作。每个新会话都是一张白纸。
两大失败模式
在没有结构化的 Harness 约束时，AI 智能体通常落入两个陷阱之一：
一口吃成胖子（One-Shotting/Over-extension）
智能体试图在一个会话中实现多个功能模块，结果上下文窗口在中途耗尽（Context Panic），留下一堆半成品、无文档、不可运行的代码。
提前宣布胜利（Premature Victory）
新会话的智能体看到已有代码，认为自己上一班已经做完了工作，直接报告「项目完成」，即使核心逻辑缺失或存在 Bug。
双智能体架构：规划者 vs 执行者
Anthropic 的 Claude Agent SDK 采用两角色架构（注意：不是两个不同模型，而是同一个模型通过不同的系统提示词扮演不同角色）：
初始化智能体（Initializer Agent）
只在第一个会话中活跃。它的职责是构建「记忆基础设施」：
- 创建
init.sh环境脚本 - 生成
claude-progress.txt叙事日志 - 初始化 Git 仓库
- 建立包含 200+ 功能项的 JSON 清单
编码智能体（Coding Agent）
后续会话的「轮班工人」。每个会话开始时先读取交接文档，然后专注于一个功能的增量开发，确保每次结束时代码处于可合并主干的「干净状态」。
200 项 JSON 清单：结构引力
Anthropic 做了一个微妙但关键的决定：把功能清单从 Markdown 改为 JSON。
Markdown 虽然人类可读，但缺乏刚性结构，会让模型「太有创意」——它可能悄悄改掉需求，或在感觉「差不多」时跳过未完成的功能。
JSON 提供了「结构引力」（Structural Gravity）。每个功能都用一个 passes: false 布尔值标记，智能体只能通过实际测试通过后才能翻转这个标记：
{
"category": "functional",
"description": "新建聊天按钮创建新对话",
"steps": [
"导航到主界面",
"点击新建聊天按钮",
"验证新对话创建成功",
"检查聊天区域显示欢迎状态",
"验证对话出现在侧边栏"
],
"passes": false
}
四份关键文件构成「外部记忆」
由于智能体的内部上下文在会话结束时被清空，Harness 使用本地文件系统作为「共享记忆」：
init.sh — 标准化开发环境。确保每个新智能体能快速启动所需服务，不浪费 tokens 在摸索上。
claude-progress.txt — 轮班日志。提供叙事性的交接说明，让新来的智能体一眼看清上一班做了什么、留下了什么。
feature_list.json — 200+ 项功能清单。每一项的
passes: false状态是项目的唯一真实来源（Single Source of Truth）。Git 历史 — 通过规范的 commit 消息，让智能体可以在搞砸后回滚到已知的稳定状态。
智能体的「上班仪式」
一个被良好设计的智能体不会盲目开始写代码。它遵循以下标准化流程：
- 确认环境：运行
pwd确认工作目录 - 读取交接记录：打开
claude-progress.txt查看上次进度 - 检查需求：Review
feature_list.json，找到下一个未完成的功能 - 验证系统：运行
init.sh启动开发服务器，执行基础端到端测试，确保系统当前正常 - 执行 + 自测：实现功能并做严格测试（推荐使用 Puppeteer MCP 进行浏览器自动化测试），通过后标记完成
这个标准化流程节省了大量用于摸索的 tokens。最关键的是——如果基础测试失败了，智能体被指示先修复再前进，防止错误层层叠加。
思考
这套方案的思路其实非常「人类工程师友好」——Git 分支管理、Code Review、交接文档，这些我们在软件工程团队协作中已经用了十几年的最佳实践，被系统性地搬到了 AI 智能体之间。Anthropic 的法宝从来不是 AGI 级别的魔法，而是把工程化管理做到极致的务实主义。
一个容易被忽略的点：200 项 JSON 清单的设计说明，Anthropic 在提示词工程上已经精细到了「为 LLM 设计认知轨道」的程度。格式本身（JSON vs Markdown）会影响模型的行为方式和可靠性，这个发现对提示词工程师来说是金子。
不过这套方案也有前提条件——它假设智能体有可重复访问的本地文件系统和执行环境。对于没有持久化环境的一次性 API 调用场景（比如智能客服、文本生成），这套记忆架构不适用。它本质上是为「AI 软件工程师」这个角色量身定做的。
总结
Anthropic 的 Harness Engineering 揭示了一个核心洞见：对于长期任务，智能体的智商不如它的纪律重要。一个结构良好的编排框架，能让中等能力的模型跑赢没有框架的顶级模型。
方向已经明确了——我们正在从「找一个更聪明的模型」转向「给现有模型套上一个靠谱的工程框架」。对开发者来说，这意味着学习如何设计智能体之间的协作结构和外部记忆系统，将是比关注模型参数增长更务实的技能投资。