← 返回文档集

# AI 自主开发与自我纠错：各家公司如何构建闭环

> 本章关注的不是让 AI “自我反思”几句，而是让 AI 在真实开发任务中能够：发现问题 → 获取证据 → 修正 → 再验证 → 必要时回滚或交给另一个 Agent。

## 一句话结论

各家公司真正依赖的不是模型凭空自省，而是把 Agent 放进一个有工具、有测试、有沙盒、有检查点、有评估和有人类兜底的反馈系统。

## 1. 共同的自我纠错闭环

    明确目标与验收标准
      → Agent 探索项目/环境
      → 形成计划
      → 小步修改或执行
      → 运行测试、构建、Lint、截图或外部检查
      → 读取真实结果
      → 定位失败原因
      → 修正并再次验证
      → 通过后再交付；连续失败则暂停、回滚或升级人工

关键点是：错误必须以 Agent 能读取的外部信号返回。只有“请检查一下你有没有错”通常不够，因为模型很容易用同一套错误假设再次评价自己。

## 2. Anthropic / Claude：把验证变成 Agent 的工作循环

### 主要做法

Anthropic 的 Claude Code 当前最佳实践明确建议：

- 给 Agent 一个可以运行的检查：测试、构建、Lint、脚本、fixture 对比或截图；
- 先探索，再计划，再编码；
- 让 Agent 读取检查结果并自行迭代；
- 在错误方向刚出现时尽早纠偏；
- 用独立 Subagent 做调查或对抗式复核；
- 用 checkpoints、会话恢复和回滚降低错误成本；
- 对长任务主动管理上下文，不让旧错误和无关输出污染当前工作记忆。

### Anthropic 的关键判断

Claude Code 文档把“让 Agent 有办法验证自己的工作”视为从“需要人一直盯着”到“可以暂时离开”的分界线。验证信号可以是：

- 单元测试或集成测试；
- 构建退出码；
- Linter 或类型检查；
- 运行中的页面截图；
- 与设计稿或 fixture 的差异比较；
- API 回执或数据库状态。

### Context Engineering 对纠错的影响

Anthropic 的 Context Engineering 文章进一步强调：

- 长上下文会出现 context rot，信息越多不一定越可靠；
- Agent 应通过工具逐步探索，而不是一次性加载整个代码库或数据集；
- 使用 compaction、结构化笔记和持久化状态保持长期任务方向；
- 让 Agent 只保留当前步骤所需的高信号上下文；
- 多 Agent 可以用来分担探索、执行和审查，但不应只是把同一份混乱上下文复制给多个模型。

### 适合复用的 Claude Code 流程

    请先探索相关文件和现有测试，不要修改代码。
    然后给出计划、假设和验收标准。
    实现后运行指定测试、构建和截图检查。
    如果检查失败，先解释失败原因，再修改并重跑。
    所有检查通过后，再总结改动、验证结果和剩余风险。

## 3. OpenAI / GPT：用 Traces、Datasets 和 Evals 纠正 Agent 行为

### 从 Trace 开始，而不是直接改 Prompt

OpenAI 的 Agent Evals 文档推荐：

1. 先看 Trace：记录模型决策、工具调用、handoff、guardrail、错误和最终输出；
2. 定位具体失败步骤：是工具选错、参数错、路由错、状态丢失，还是最终生成错误；
3. 形成 Dataset：把真实失败案例和代表性任务固定下来；
4. 用 Grader/Eval Runs 重复评估：修改提示、工具、模型或编排后重新跑同一批任务；
5. 把评估变成持续改进飞轮，而不是上线前一次性测试。

### OpenAI 推荐的纠错分层

阶段 | 主要手段 | 解决的问题
--- | --- | ---
调试阶段 | Traces | 看清 Agent 实际做了什么
可重复阶段 | Datasets + Eval Runs | 判断改动是否真的变好
质量阶段 | Graders | 自动判定结果、工具调用和流程质量
生产阶段 | 监控、人工反馈、回归集 | 防止版本升级后退化

### Responses API 与 Agents SDK 的分工

- Responses API 适合应用自己控制 loop、工具分发、状态和重试；
- Agents SDK 适合让 runtime 管理 turns、tools、handoffs、guardrails 和 sessions；
- 不论选择哪一个，应用仍需负责权限、业务状态、审批和外部副作用。

### OpenAI 的核心原则

不要把“模型说自己完成了”当作完成。应该检查：

- 是否调用了正确工具；
- 参数是否符合预期；
- 是否在错误后正确重试；
- 是否越权调用了工具；
- 是否在需要人工审批时暂停；
- 最终结果是否满足业务验收标准。

## 4. Cursor：让 AI 长时间写代码时保持方向

Cursor 的长期运行 Agent 工程复盘提供了一个更接近“AI 自己开发项目”的案例。

### 发现的问题

当大量 Agent 在同一个代码库中长时间并发工作时，简单的共享文件协作容易造成：

- 重复劳动；
- Agent 规避困难任务；
- 任务无人负责；
- 共享状态互相覆盖；
- 长时间运行后目标漂移。

### Cursor 的解决思路

- 使用“规划者 → 执行者 → 评审者”的层级流水线；
- 让规划、实现和审查拥有不同职责，而不是让一个 Agent 自己全程批准自己；
- 根据角色选择不同模型；
- 通过周期性干净重启减少状态漂移；
- 减少不必要的 aggregator，避免把所有结果再交给一个模型重新压缩；
- 让结构化程度处于“完全自由”和“过度编排”之间；
- 给长期任务清晰的目标、边界和完成信号。

### 可复用的代码 Agent 流程

    Planner：拆解任务，写出文件范围和验收标准
      → Builder：实现一个小任务并运行测试
      → Reviewer：检查需求覆盖、回归和安全问题
      → Repairer：只修复已确认的问题
      → Verifier：重新运行全套检查
      → Integrator：合并、记录结果和剩余风险

## 5. Google Gemini / Managed Agents：用沙盒、Hooks 和人工监督控制自治

Google Gemini Agents 文档显示，托管 Agent 可以在一次 API 调用中获得 Linux sandbox，用于执行代码、管理文件和浏览网页。

对“自己开发、自己修正”最重要的不是模型能力，而是运行环境：

- Agent 的文件和命令执行在隔离环境中；
- 网络访问可以通过 allowlist 限制；
- 外部工具和 API 需要明确权限；
- Hooks 可以在特定阶段插入检查、拦截或人工监督；
- 敏感任务应让人检查 Agent 的操作和输出。

这提供了一个重要边界：让 AI 在可破坏的沙盒里自主试错，而不是直接在生产环境里试错。

## 6. Microsoft：把纠错责任拆到编排层

Microsoft 的 Agent Orchestration Patterns 强调，复杂系统不应默认使用多 Agent。应按以下顺序增加复杂度：

    直接模型调用
      → 单 Agent + 工具
      → 多 Agent 编排

多 Agent 只有在以下情况才值得使用：

- 单 Agent 的提示和工具已经过于复杂；
- 不同角色需要不同安全边界；
- 任务可以真正并行；
- 不同专业 Agent 有独立评价标准；
- 单 Agent 无法可靠完成跨领域任务。

对于纠错，可以使用：

- Sequential / Pipeline：每一步输出都成为下一步输入，可在中间插入校验；
- Parallel：多个 Agent 独立分析，再比较差异；
- Handoff：把问题交给更适合的专家 Agent；
- Manager：由管理 Agent 分配任务并汇总结果；
- Group chat / debate：让多个 Agent 互相检查，但需要明确停止条件。

Microsoft 特别强调：多 Agent 会增加协调开销、延迟、成本和失败模式。因此“让更多 Agent 互相反思”不等于更可靠。

## 7. 哪些“自我纠错”方法真正有效

### 有效方法 1：外部可执行验证

    修改代码 → 运行测试 → 读取失败信息 → 修复 → 重跑

这是最可靠的基础闭环，因为反馈来自代码执行环境，而不是模型自评。

### 有效方法 2：独立评审 Agent

让另一个上下文专门找问题：

- 需求是否遗漏；
- 测试是否覆盖；
- 是否引入回归；
- 是否存在安全问题；
- 是否修改了不该修改的文件。

评审 Agent 不应拥有与实现 Agent 完全相同的目标和上下文，否则容易“替自己辩护”。

### 有效方法 3：Evaluator-optimizer

一个模型生成，另一个模型根据明确标准评价并提出修改意见，再循环迭代。适合：

- 文案质量；
- 结构化报告；
- 代码风格；
- 有明确 rubric 的输出。

不适合没有清晰评价标准、只能凭感觉判断的任务。

### 有效方法 4：Trace + 回归数据集

把失败案例保存下来，确保下一版真的修复，而不是换一种方式失败。对长周期项目尤其重要。

### 有效方法 5：检查点和回滚

每个阶段保存：

- 当前目标；
- 已完成任务；
- 测试结果；
- 修改文件；
- 未解决问题；
- 下一步计划。

一旦 Agent 方向明显错误，应回到最近一个通过检查的 checkpoint，而不是让它在错误状态上继续堆补丁。

## 8. 哪些方法经常失败

### 失败模式 1：只要求“请自我反思”

模型可能生成一段看似严谨的反思，但没有访问真实环境，也没有改变错误结果。

改进： 给出可运行的检查和失败信号。

### 失败模式 2：让同一个 Agent 自己批准自己

实现者、评审者和验收者共享同一组错误假设时，评审容易流于形式。

改进： 使用独立上下文、不同角色、不同检查标准，必要时使用不同模型。

### 失败模式 3：把整个代码库塞进上下文

上下文越长，Agent 不一定越聪明；旧日志和无关文件会污染注意力。

改进： 让 Agent 通过搜索、文件系统和工具渐进式获取信息，并保存结构化笔记。

### 失败模式 4：没有停止条件

Agent 会在同一错误上循环重试，产生越来越多无效修改。

改进： 设置最大步数、预算、超时、重复错误检测和人工升级条件。

### 失败模式 5：直接让 Agent 修改生产环境

自主试错和生产写入不应发生在同一个权限层里。

改进： 沙盒 → 测试环境 → 预览部署 → 人工审批 → 生产发布。

## 9. 推荐的自主开发架构

    任务层：目标、范围、验收标准
        ↓
    规划层：拆解任务、选择工具、生成执行计划
        ↓
    执行层：修改代码、运行命令、调用 API
        ↓
    验证层：测试、构建、Lint、截图、Evals、外部回执
        ↓
    审查层：独立 Agent 检查需求、安全、回归和质量
        ↓
    状态层：checkpoint、日志、trace、数据集、失败案例
        ↓
    控制层：权限、预算、超时、审批、回滚、停止条件

## 10. 最小可行实现

如果要今天就实现一个“AI 自己开发、自己纠正”的 MVP，建议只做：

1. 一个明确的小任务，例如修复一个已知 Bug；
2. 一个执行 Agent；
3. 一个测试命令；
4. 一个独立 Reviewer；
5. 一个最大迭代次数；
6. 一个 git checkpoint；
7. 一个最终报告，包含改动、测试结果和未解决问题。

    for attempt in 1..MAX_ATTEMPTS:
        plan = planner(task, current_state)
        change = builder(plan)
        result = run_tests()
        if result.pass:
            review = independent_reviewer(change, result)
            if review.pass:
                return success(change, result, review)
        save_failure(change, result)
        rollback_or_repair()
    return human_review(required=True)

## 最终结论

各家公司所谓的“AI 自己开发自己纠正”，实际都不是让模型脱离现实进行自我反省，而是：

- 让 AI 能操作真实但受控的环境；
- 让环境返回测试、构建、工具和业务结果；
- 让 Agent 根据结果继续迭代；
- 用独立角色和评估集发现盲点；
- 用 checkpoint、权限、预算和人工审批限制错误扩散。

最重要的设计不是“让 AI 更会反思”，而是“让错误尽快暴露，而且暴露后能安全修复”。

## 原始资料

- Anthropic — Best practices for Claude Code
- Anthropic — Effective context engineering for AI agents
- OpenAI — Evaluate agent workflows
- OpenAI — Agents SDK
- Google — Agents overview
- Microsoft — AI agent orchestration patterns
- Cursor — Scaling long-running autonomous coding