AI Agent 失控：从模型崇拜到环境工程

一个真实场景。

你让一个 AI Agent 负责代码审查，第一天它干得还不错。第二天你让它继续，它忘了昨天的审查标准，开始用另一套逻辑评分。第三天它直接在 PR 里删代码，理由是"看起来没用"。一周后你得到一堆风格不一致的代码、一个报废的测试套件，和一个不知道为什么走偏了的 Agent。

你开始怀疑模型不够强。换了个更强的模型，同样的问题重复出现。

问题不在模型。在运行环境。

模型很强，Agent 却总出问题

过去几年行业焦点一直是"模型能力"。GPT-4o 比 GPT-4 强，Claude 3.7 比 3.5 强，这个逻辑没问题。

但模型强不代表 Agent 强。

一个只训练过单轮对话的模型，你让它跑一周的代码任务，它不会天然理解"任务状态需要持久化"、“不要修改你没要求改的模块”、“每次提交前跑测试”。这些不是模型的缺陷，是运行环境没有提供约束。

Harness Engineering 的核心命题是：如何为 AI Agent 构建一个可靠的、可控的、出了问题能追踪的运行环境。

行业逐渐形成的共识：Agent = 模型（大脑）+ Harness（身体/环境）。模型负责推理，Harness 负责让推理结果可靠地执行。

Harness 的四大支柱

1. 上下文架构：别往模型脑子里塞垃圾

“context 越来越长，输出质量却越来越差”——这是"context rot（上下文腐烂）"。

常见的做法是把所有东西都塞进 context：系统 prompt、几十个 few-shot examples、项目所有文档、最近的对话历史。Context 越来越长，模型在无关信息里打转，开始出现"幻觉指令"——它开始执行 context 里根本没让你做的事。

上下文架构的核心是分层和渐进式披露：

系统层：固定规范（编码风格、架构约束、不变量）
   ↓ 按需注入
任务层：当前目标的背景、验收标准
   ↓ 按需注入
执行层：具体某一步的输入/输出，通过 Tool 调用传递

这样 model 在每一步只看到它真正需要的信息，不需要在每一步都从一堆积压文档里筛选。

2. 机械化约束：代码能拦住的事，别靠嘴说

Prompt 说"不要修改 tests 目录"，模型在压力下可能忽略。

这不是模型的错。Prompt 本质上是在"请求"行为，不是"强制"行为。模型在推理时可能会权衡：写这个测试是否对任务有帮助？然后决定跳过。

机械化约束是用工具强制执行：

• Linter 拦住违规提交：CI 里跑静态检查，Agent 写了不符合规范的代码 → 门禁 fail
• 架构测试：ArchUnit 用代码定义组件边界，Agent 试图跨层调用 → 测试 fail
• 强制门禁：没有 human override 选项，Agent 不能绕过验证

Stripe 的 Minions 系统就是这样跑的。Agent 写代码 → CI 跑测试 → 失败 → Slack 通知 → Agent 自己读错误、修代码、重跑。没有人类介入循环。

Prompt = 建议，机械约束 = 规则。 建议可以被忽略，规则不能。

3. 持久化记忆：解决 AI 的失忆症

模型没有持久化状态。每次对话都是从零开始。

上一轮改了什么、做到了哪一步、下一步该做什么——模型不知道。Session 之间完全割裂，第二天启动和新人入职一样。

传统解法是"上下文传递"，把历史对话塞进新请求。但这解决不了根本问题：上下文会满、传的是消息不是状态、跨 session 依然无法共享。

Harness 的解法是文件系统优先：

/workspace/
  AGENTS.md          # 项目规约，机器可读
  progress.json      # 当前进度状态
  memory/
    20260414.md      # 每日工作日志
    MEMORY.md        # 长期记忆（偏好、决策、技能）

Agent 启动时先读 AGENTS.md 和 progress.json，形成对项目状态的完整认知。执行后把结果写回文件。下一个 session 读同一份文件，无缝衔接。

OpenClaw 的记忆分层就是这个思路的实践：Daily Notes 是原始日志，MEMORY.md 是长期记忆，Agent 每次启动先读这些，形成连续性。

4. 自验证反馈回路：让 Agent 重新理解需求，而不是重跑

传统开发：写代码 → 跑测试 → 失败 → 看错误 → 修代码 → 重跑

Agent 开发多了一步：写代码 → 跑测试 → 失败 → 重新理解需求 → 修代码 → 验证

最后一步是核心差异。Agent 犯的错往往不是"写错了"，而是"理解偏了"。它在错误的假设下写出了逻辑上自洽但不符合需求的代码。

Ralph Loop 是这个模式的典型实现：Agent 提交代码后测试失败，退出信号被拦截，Agent 必须重新对照原始需求评估自己的代码，而不是简单地根据错误信息做表面修复。

行业实践：不只是在概念

OpenAI Codex：5 个月，100 万行无人手写的代码

OpenAI Codex 团队 5 个月产出了 100 万行代码。人类工程师全程没手写一行代码。

人类在做什么？设计 Harness，设计反馈回路，定义验证标准，然后让 Agent 在这个框架里跑。

这是 Harness Engineering 的理想状态：人类做架构，Agent 做实现，环境做验证。

Anthropic：跨 session 的进度保持

通过 claude-progress.txt 和 Puppeteer 浏览器自动化，实现能执行数天复杂任务的 Agent。

不是 Agent 变聪明了，是环境帮 Agent 记住了上下文。它可以在中途暂停、恢复，不丢失状态。

Stripe Minions：无人值守的开发循环

Agent 自动完成从写代码、到通过 CI、到 Slack 提 PR 的全流程。

CI 是反馈回路，Slack 是通知机制。两个组合起来，构成完整的 Agent 工作循环。

为什么 Prompt Engineering 不够用了

这不是说 Prompt Engineering 没用。两者不在同一层。Prompt Engineering 是战术优化，Harness Engineering 是战略架构。

你可以在一个没有 Harness 的系统里优化 Prompt，效果有限。你也可以在一个 Harness 完整的系统里用朴素 Prompt，系统依然可靠运行。

工具链现状

• AGENTS.md / CLAUDE.md：行业标准，存放项目规约和机器可读指令集
• MCP（Model Context Protocol）：连接 Agent 与外部工具的标准化协议
• DeepAgents：LangChain 推出的开源 Harness 框架，支持中间件和自验证逻辑

最后

Harness Engineering 的本质是把"如何让 AI 可靠工作"从玄学变成工程。

当 Agent 出问题时，你该检查的不是模型够不够强，而是 Harness 够不够严：上下文有没有泄漏、约束有没有被绕过、状态有没有丢失、反馈回路有没有闭环。

模型是大脑，Harness 是身体。没有 Harness 的模型是一个会说话的空壳——看起来能动，遇到真实压力就散架。