AI Agent Field Notes
← 返回文档集

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

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

一句话结论

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

1. 共同的自我纠错闭环

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

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

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

主要做法

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

Anthropic 的关键判断

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

Context Engineering 对纠错的影响

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

适合复用的 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 的分工

OpenAI 的核心原则

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

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

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

发现的问题

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

Cursor 的解决思路

可复用的代码 Agent 流程

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

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

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

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

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

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

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

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

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

对于纠错，可以使用：

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

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

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

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

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

有效方法 2：独立评审 Agent

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

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

有效方法 3：Evaluator-optimizer

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

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

有效方法 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 更会反思”，而是“让错误尽快暴露，而且暴露后能安全修复”。

原始资料