Agent 工程化对比：Anthropic vs OpenAI

Agent 工程化范式对比

基于 Anthropic 与 OpenAI 内部工程实践的分析

核心差异摘要：
Anthropic 的文章关注“接力赛”——如何让不同的 Agent 跨越遗忘（上下文窗口）完成同一个长任务。
OpenAI 的文章关注“无人驾驶”——如何构建一个环境，使得人类只需掌握方向盘（Prompt），而由 Agent 编写每一行代码。

1. 共同点：Agent 开发的共识

尽管侧重点不同，两家顶尖 AI 实验室在通过 Agent 进行软件开发时，达成了一些惊人的一致：

Git 是事实的唯一来源： 两者都强调 Git 仓库（代码、日志、文档）是 Agent 理解世界的基石，而非依赖模型内部的记忆或外部的聊天记录。

赋予 Agent “视觉”能力： 两者都认为仅仅看代码是不够的。Anthropic 使用 Puppeteer，OpenAI 使用 Chrome DevTools Protocol，目的都是让 Agent 像人类一样看到 UI、日志和报错，从而进行自我修正。

拒绝“一步到位”： 两个团队都发现 Agent 倾向于尝试一次性完成任务（One-shot），但这往往会导致失败。解决方案都是将任务分解为增量的、可验证的步骤。

人类角色的转变： 工程师不再是“打字员”，而是“架构师”和“验收者”。人类负责定义意图和设计反馈循环，Agent 负责执行。

2. 各自策略的特点

Anthropic：结构化交接 (Structured Handoff)

核心隐喻：轮班工作。 就像早班和晚班的工程师交接一样，上一个 Agent 必须留下清晰的文档给下一个 Agent。

双 Agent 架构： 明确区分“初始化 Agent”（搭建环境、制定计划）和“编程 Agent”（执行具体任务）。
状态文件驱动： 使用 feature_list.json 和 claude-progress.txt 作为外部存储器，解决上下文丢失问题。
防御性测试： 每个会话开始时先运行 init.sh 和基础测试，防止基于错误的代码继续开发。
增量式推进： 强制 Agent 每次只修改 JSON 列表中的一个状态，严禁一次性重写所有功能。

OpenAI：Agent 原生环境 (Agent-Native Environment)

核心隐喻：平台工程。 打造一个专为机器而非人类优化的工厂，所有的文档和工具都是为了让机器能读懂。

零人工代码 (0 lines of manual code)： 极端的约束条件，倒逼基础设施的完善。连 CI 配置、文档、甚至 Git 仓库本身都是 Agent 生成的。
知识库即索引： 摒弃巨大的 System Prompt，将知识结构化存储在 docs/ 目录，AGENTS.md 仅作为目录索引。
机械化约束： 使用 Agent 生成的 Linter 来强制执行架构分层（如数据流向），防止代码腐化（Entropy）。
可观测性内嵌： 将日志（LogQL）、指标（PromQL）直接暴露给 Agent，使其能根据运行时数据自我调试。

3. 深度对比与设计原因

维度	Anthropic (Long-running Agents)	OpenAI (Agent-first World)
核心痛点	遗忘与幻觉： Agent 在长任务中耗尽上下文，或在中途迷失方向，导致项目烂尾。	速度与规模：人类编写代码速度太慢。目标是将工程速度提高几个数量级。
上下文管理策略	“接力棒”模式：通过极其精简的 `claude-progress.txt` 和 JSON 状态文件，在不同会话间传递关键信息。	“图书馆”模式：建立分层文档系统（`docs/`），Agent 按需检索。强调如果 Agent 在仓库里看不到，这个知识就不存在。
对代码质量的控制	测试驱动：依赖端到端测试（Puppeteer）来验证功能是否真的完成，防止 Agent 欺骗性地标记“完成”。	Linter 驱动：依赖自定义的 Linter 和架构规则来强制执行代码风格和依赖关系，防止代码结构随时间“漂移”。
设计原因 (Why?)	为了解决可靠性问题。如果不强制分步和状态检查，Agent 会产生看似完成实则破碎的代码。这种设计是为了让目前的模型能“跑完马拉松”。	为了解决可维护性问题。在全自动生成的代码库中，如果不通过机械化手段强制执行架构规则（Golden Principles），代码库会迅速变成不可维护的“垃圾山”。
交互模式	初始化 -> 循环执行：用户设定目标，初始化 Agent 拆解，编程 Agent 循环执行直到完成。	人机回环 (Ralph Wiggum Loop)：人类提示 -> Agent 编码 -> Agent 自我审查 -> Agent 修正 -> 合并。

维度

Anthropic (Long-running Agents)

OpenAI (Agent-first World)

核心痛点

遗忘与幻觉： Agent 在长任务中耗尽上下文，或在中途迷失方向，导致项目烂尾。

速度与规模： 人类编写代码速度太慢。目标是将工程速度提高几个数量级。

上下文管理策略

“接力棒”模式： 通过极其精简的 claude-progress.txt 和 JSON 状态文件，在不同会话间传递关键信息。

“图书馆”模式： 建立分层文档系统（docs/），Agent 按需检索。强调如果 Agent 在仓库里看不到，这个知识就不存在。

对代码质量的控制

测试驱动： 依赖端到端测试（Puppeteer）来验证功能是否真的完成，防止 Agent 欺骗性地标记“完成”。

Linter 驱动： 依赖自定义的 Linter 和架构规则来强制执行代码风格和依赖关系，防止代码结构随时间“漂移”。

设计原因 (Why?)

为了解决可靠性问题。如果不强制分步和状态检查，Agent 会产生看似完成实则破碎的代码。这种设计是为了让目前的模型能“跑完马拉松”。

为了解决可维护性问题。在全自动生成的代码库中，如果不通过机械化手段强制执行架构规则（Golden Principles），代码库会迅速变成不可维护的“垃圾山”。

交互模式

初始化 -> 循环执行： 用户设定目标，初始化 Agent 拆解，编程 Agent 循环执行直到完成。

人机回环 (Ralph Wiggum Loop)： 人类提示 -> Agent 编码 -> Agent 自我审查 -> Agent 修正 -> 合并。

4. 总结与启示

这两篇文章实际上是在解决 Agent 软件开发的两个不同阶段的问题：

Anthropic 展示了“如何开始”： 当你需要让 Agent 处理一个超出单次对话窗口的任务时，你需要明确的状态管理和任务交接协议。JSON 状态列表和进度文件是最简单有效的“外部记忆体”。

OpenAI 展示了“如何规模化”： 当 Agent 编写的代码量达到百万行级别，且不再有人类手动维护时，你需要架构约束和可观测性。代码库必须变得对 Agent “可读（Legible）”，这意味着所有的隐性知识（Slack 讨论、口头约定）都必须显性化为仓库里的 Markdown 文档和 Linter 规则。