从 AutoGPT 到 Agent Harness，三年发生了什么？

2023 年我第一次认真接触 "AI Agent" 这个概念，是 Lilian Weng 那篇后来非常经典的博客 LLM Powered Autonomous Agents。

当时我记住的 Agent 定义就是 Lilian 总结的：

LLM 是 Agent 的大脑。在它周围，我们给它加上 Planning，让它把复杂任务拆解成子任务；加上 Memory，让它能够记住超出 context window 的信息；再加上 Tools，让它能够搜索互联网、执行代码、调用外部 API，从而真正对外部世界采取行动。

当时火遍一时的 Agent 项目，是 AutoGPT 和 BabyAGI。

现在回头看，2023 年的 Agent 确实有点超前，概念好玩，但没啥实用价值。

AutoGPT 和 BabyAGI 在 2023 年上半年爆火的时候，OpenAI 甚至还没有推出原生 function calling（function calling 要到 2023 年 6 月才正式发布，可靠的 JSON mode 要等到 11 月的 DevDay）。开发者想让模型调工具，只能在 prompt 里要求模型输出特定格式的 response，然后自己 parse，再执行相应的 command。

距离 OpenAI 发布第一个 reasoning model o1，也还有一年多。2023 年大家提升复杂推理能力的重要手段，还是 "think step-by-step" 这一类 prompting 技巧。

Context window 和成本也完全不是今天的量级。最初的 GPT-4 默认只有 8K context，32K 版本还是 limited access。而 GPT-4 当时的 input 价格是按 per 1K token 计算的，换算成 per 1M token 要 $60，比现在的 Claude Fable 5 还贵 6 倍。

也就是说，那时我们正在尝试让一个：

• 没有原生 tool calling 和可靠 structured output；
• 非 reasoning model；
• context window 甚至放不下今天 Claude Code 的 system prompt + tool definition

的模型，变成一个可以长期、自主完成任务的 Agent。

Agent 在 2023：AutoGPT

AutoGPT 是一个很典型的例子。

它试图让 GPT-4 在没有人持续干预的情况下，自己拆解目标、调用工具，并不断推进任务直到完成。

它的核心结构大致是：

在这个循环里，LLM 不只是回答问题，而是被要求持续输出"下一步行动"。这些 action 可以是搜索网页、读写文件、执行 shell command...系统把 command 解析出来执行，再把结果作为 observation 回灌给模型。

因为 OpenAI 还没有推出原生 function calling，所以当时这个 loop 远没有今天这么"干净"。AutoGPT 需要依赖 prompt engineering 让模型按照约定的格式输出 command，再由外部代码负责 parsing、校验和执行。但从架构上看，它已经基本就是今天的 tool-use agent。

2023-2026 Loop 变简单了

今天用任何支持 native tool calling 的模型 API，几十行代码就可以实现一个最基本的 Agent：

while (true) {
  const response = await model(messages, tools);
 
  if (!response.toolCalls.length) {
    return response;
  }
 
  const results = await executeTools(response.toolCalls);
 
  messages.push(response);
  messages.push(...results);
}

模型想继续工作，就调用 tool。

Tool 执行完成以后，把结果放回 context。

模型认为任务完成了，就返回 final response。

一些 2023 年看起来非常重要的 architecture，今天反而不怎么需要了。

早期 AutoGPT 会要求模型显式输出 Thoughts、Reasoning、Plan、Criticism。背后的思路是：既然模型还不够擅长 long-horizon reasoning，那就让 framework 帮它把 cognition 拆成几个明确的步骤。

但随着模型能力越来越强，我们不再需要一个 PlannerAgent，再加一个 ExecutorAgent，最后再来一个 CriticAgent。Agent framework 不再需要通过越来越复杂的 orchestration 去模拟思考。

一个现代 coding agent 完全可能只给模型几个非常 primitive 的工具：read, write, edit, execute. 然后让模型自己决定读哪些文件、搜什么、修改什么、跑什么测试、如何根据失败继续修复，以及什么时候应该结束。

于是一个很反直觉的现象出现了：

模型越来越强，Agent Loop 越来越简单；但真正可用的 Agent 系统，却变得更复杂。

复杂度去了哪里？

去了 loop 外面的 Harness。

Agent Harness 在 2026

2026 年 Agent Harness 这个词突然很流行。

如果 Agent Loop 是：

Model → Tool → Model → Tool → ...

那么 Harness 是包裹这个 loop 的整个运行环境：

这里面至少有五类问题。

1. Execution：Agent 怎么持续工作？

这是最接近 2023 年 Agent Loop 的部分，包括 tools、tool execution、stop condition、retry、orchestration、subagents...

2. Context：模型这一刻到底知道什么？

这不只是把 messages[] 全塞给模型。System instructions、项目 instructions、skills、当前任务、最近的 tool outputs、relevant files、compaction 后的历史摘要...这些东西最终都在竞争模型有限的 context window。

Harness 需要决定：什么应该进入 context，什么应该被截断，哪些历史需要 compact，哪些信息要动态加载，模型切换以后 context policy 是否也应该跟着变化...

3. State：什么东西能够跨 turn 存活？

最简单的 chatbot 可以把 session 理解成：

const messages = [];

但一个长期运行的 Agent 会需要 conversation history、tool execution history、pending approvals、workspace、usage、compaction summary、checkpoint、branch 和 execution state。

所以一个真正的 Agent session，更像 execution log，而不是单纯的 chat history。

4. Environment：Agent 到底在哪里工作？

对于 coding agent 来说尤其明显。

让模型有一个 execute tool 还不太够。这个 shell 在哪里运行？Filesystem 是否持久化？进程能活多久？能不能访问公网？Secrets 如何注入？Session resume 以后 workspace 还在不在？代码改坏以后能不能 rollback？

一旦 Agent 开始真正对外部世界采取行动，tool calling 很快就会变成 runtime 和 infrastructure 问题。

5. Control：Agent 被允许做什么？

2023 年很常见的做法是在 prompt 里告诉模型：

Be efficient. Do not do anything dangerous.

但 prompt 是 instruction，不是 enforcement。

更成熟的 Harness 会把 action 放到 policy boundary 后面：

Agent wants to execute action
            ↓
        Policy Engine
            ↓
    allow / deny / ask
            ↓
      Execute Action

模型可以决定"要做什么"，Harness 决定这个 action 是否真的能够发生。

把 2023 和 2026 放在一起看，会发现很多表面上不同的变化，其实指向同一件事情。

背后真正发生的，是 Model 和 Harness 之间的 responsibility boundary 被重新划分了。

2023 年，模型能力不够，我们就在 framework 里加入更多 cognitive scaffolding：Planner、Critic、Task Creator、Prioritizer、Memory Retriever。我们试图通过 orchestration 告诉模型应该怎样思考。

今天，模型本身已经可以承担越来越多 reasoning、planning 和 tool selection。所以 framework 可以退后一步，用 harness 来明确它的 execution boundary。

所以今天我觉得一个很有用的设计原则是：

Give cognition to the model. Keep deterministic control in the harness.

模型负责那些本质上需要 intelligence 的 decision：

我下一步应该做什么？
应该读哪个文件？
应该搜索什么？
这个错误意味着什么？
任务完成了吗？

Harness 则负责那些不应该依靠"模型自觉"的事情：

你现在能看到什么 context？
你可以访问哪些工具？
这个 command 能不能执行？
它在哪里执行？
哪些 state 必须持久化？
用户是否需要 approve？
出了故障之后系统怎么恢复？

用这个视角看 Agent SDK

我最近在做一个给自己用的 Agent。选框架的时候，我把市面上叫得出名字的都翻了一遍：LangChain, LangGraph, Vercel AI SDK, eve, OpenAI Agents SDK, Pi, Claude Agent SDK, Codex SDK...

看文档的过程中我有一个很明显的感受：这些东西虽然都叫 "Agent SDK"，但用 feature list 去比较它们没什么意义，它们根本不在解决同一层级的问题。真正有区分度的问法，是把前面五类 Harness decision 逐个拿出来问：

Execution、Context、State、Environment、Control，每一类的 decision 归我，还是归 framework？

一个现成的参照是 LangChain 生态。官方文档现在把自己的产品明确分成三层：

LangGraph 拥有 Harness 里最重的 execution machinery，却完全不替你决定 Agent 应该怎么思考，graph 由你自己画；Deep Agents 反过来，把 opinion 整包带走，README 第一句就是 "The batteries-included agent harness"。"替你把 Agent 跑得可靠"和"替你决定 Agent 怎么思考"，在这里被拆成两层分开认领。

不过说实话，我自己不喜欢 LangChain 这一系。它的每一层都是重抽象，选了它，就等于接受了它的整套世界观：Agent 是一张 graph，能力通过 middleware 注入。在一个还在不断变化的领域，这种抽象蛮脆弱的。鸭哥去年有一篇《为什么学习 Agentic AI 的第一步是忘记所有框架》把这个问题讲得不错：现在选一个 opinionated framework，选的不是 feature list，是它预设的世界观。

所以这几家里我更偏好的路线是 Vercel AI SDK：从统一 model provider、streaming、tool calling 起家，v5、v6 开始把 agent loop、durability、approval 陆续收进来，但始终保持薄抽象，五类 decision 大部分留在你手里，要不要交出去、什么时候交出去，由你决定。而 Vercel 把 harness 层的答案单独放在 2026 年发布的 eve 里：构建在 AI SDK 之上，就像 Deep Agents 构建在 LangGraph 之上。eve 的设计理念是 "An agent is a directory"。开发者用一个目录（instructions、tools、skills、subagents）回答"这个 Agent 是谁、知道什么、会做什么"，framework 认领另一半，"它怎么可靠地活在 production 里"：durable execution、sandboxed compute、approval、evals 默认全带。2023 年的 framework 在替模型思考，2026 年的 framework 在替开发者运维。

OpenAI Agents SDK 替你拥有 runtime decisions：Runner 负责 turns 和 tools，原生提供 sessions、handoffs、guardrails。OpenAI 的文档直接说，想自己拥有底层 loop 就别用 Agents SDK，用 Responses API。

Pi 是一个完整的 coding-agent harness，session persistence、branching、compaction、skills 都做好了，但刻意保持 hackable，几乎每个 decision 都能通过 extension 换掉。Claude Code 和 Codex 则是已经调优好的 specialized coding agents，五类 decision 几乎全部归 vendor，你拥有的只剩 instructions、tools、和它跑在哪。

放进一张表里：

所以选型问题其实很具体：这五类 decision 里，哪些我想自己拥有，哪些我愿意交出去。而且要清楚，交出去的每一类 decision，同时也是在接受 framework 对那一类问题的世界观。想要开箱即用的 long-horizon agent，用 Deep Agents 或 Pi；只想把一个世界级 coding agent 嵌进产品，用 Claude Agent SDK 或 Codex SDK；想把 decision 尽量留在自己手里，那就从 AI SDK 这样的薄抽象开始搭。

在看 LangChain 生态的时候，发现了两件今年在 Deep Agents 身上发生的事。

第一件事，LangChain 今年 2 月发过一篇 Improving Deep Agents with harness engineering。他们把模型固定在 gpt-5.2-codex 完全不动，只改 harness：system prompt、tools、middleware。结果他们的 coding agent 在 Terminal Bench 2.0 上从 52.8 提到 66.5，从 Top 30 进了 Top 5。

第二件事，7 月底发布的 Deep Agents v0.7 做了一次大幅简化。默认 system prompt 整个删掉，内置 tool descriptions 砍了 43%，planning middleware 从默认开启改成 opt-in。一个默认 agent turn 的 base input tokens 从 5,395 降到 1,895，减少 65%，eval 显示质量没有回退。

两件事放在一起看，Harness 决定了模型能发挥出几成功力，所以值得认真做 engineering。但 Harness 里具体装什么，取决于此刻模型的能力边界。模型每变强一次，cognitive scaffolding 就可以再删掉一批。