AI Agent 的演进:从“回答问题”到“完成任务”

AI Agent 的演进：从“回答问题”到“完成任务”。今天的 AI Agent 很火，但也很容易被误解：它到底是下一代软件形态，还是资本炒作的浮云？是已经可以稳定完成复杂任务，还是流量追逐的噱头？

对技术从业者来说，理解 AI Agent 的演进历程有一个直接价值：它可以帮助我们更理性、更有效、更安全地用好 Agent，了解大模型的能力边界。读懂这条演进路线，才能判断哪些能力已经成熟，哪些只是概念包装；哪些问题可以交给模型，哪些必须依赖工具、上下文、权限、验证和人工监督；也能更清楚地理解大模型擅长什么、不擅长什么，为什么它需要被放进一个有反馈、有工具、有验证的 Agent 系统里。

所以，这篇文章不会从概念定义开始，而是沿着几个重要 milestone 回看：大模型如何从“生成答案”，一步步走向“使用工具、读取反馈、修正行为，并参与真实任务的完成”。

一条主线：Agent 从推理走向行动

如果只看时间线，AI Agent 的演进大致可以被压缩为八个关键节点：

2020：GPT-3 与上下文学习
大模型开始表现出通过 Prompt 中的少量示例适配任务的能力。
2022：Chain-of-Thought Prompting
通过示范中间推理步骤，模型在数学、逻辑、符号推理等任务上表现显著提升。
2022：ReAct
模型不再只是“想”，而是在“思考—行动—观察”的循环中完成任务。
2023：AutoGPT 浪潮
第一波自主 Agent 展示了愿景，也暴露了幻觉、循环、成本和不可验证的问题。
2023：函数调用与工具使用
LLM 与外部系统的交互从脆弱的文本解析转向结构化工具调用。
2023-2024：SWE-Bench 与 SWE-Agent
软件工程任务开始有了接近真实世界的评测方式，Agent-Computer Interface 成为重要设计对象。
2024-2025：推理模型
模型通过更多推理计算、更强验证和自我修正能力，提升复杂任务求解能力。
2025 之后：代码 Agent 与通用 Agent
Agent 开始进入 IDE、Shell、代码库、浏览器和企业系统，成为“人类监督下的执行者”。

这条时间线背后的主线很清楚：Agent 的核心不只是生成文本，而是把推理能力接到外部世界，并用反馈与验证持续修正行为。

三股力量的汇合

现代 Agent 的形成，可以看成三股力量的汇合。

第一股力量是推理。从 Chain-of-Thought 到 ReAct，再到 o1、DeepSeek-R1 这类推理模型，核心目标都是让模型在复杂任务中更会拆解、更会规划、更会检查。

第二股力量是行动与接地。ReAct 引入 Observation，让模型能从外部世界获得反馈；函数调用让工具使用变得结构化；Agent-Computer Interface 则进一步把文件、Shell、测试、搜索、编辑等动作设计成适合 Agent 使用的接口。

第三股力量是评测与验证。AutoGPT 证明“看起来在忙”不等于“真的完成任务”。SWE-Bench 的价值在于，它把真实 GitHub issue 转成可执行、可判定的任务：补丁是否修复问题，不靠模型自说自话，而靠测试和评测环境判断。

接地和评测不是一回事。接地发生在任务执行过程中，帮助 Agent 获得现实反馈；评测发生在任务结束或阶段结束时，用来判断任务是否成功。 但在现代 Agent 中，两者往往被紧密结合：Agent 通过工具接地，再通过测试、日志、运行结果和外部检查来验证。

GPT-3：上下文学习让 Prompt 变成“运行时程序”

这个里程碑主要来自 OpenAI 在 2020 年发表的论文 《Language Models are Few-Shot Learners》。论文训练并评估了 175B 参数的 GPT-3，展示了大模型在不进行梯度更新和任务微调的情况下，可以通过 Prompt 中的任务描述和少量示例，在 zero-shot、one-shot 和 few-shot 场景中适配多种 NLP 任务。

这就是上下文学习。严格来说，模型并没有在推理时真的修改参数；它是在当前上下文中根据示例调整输出行为。但从工程体验上看，这已经足够像“临时学会一个任务”。

在 GPT-3 之前，如果要让模型适配新任务，通常需要收集数据、标注样本、微调模型、部署新版本。GPT-3 之后，很多任务可以通过 Prompt 快速试验：给任务描述，给一两个例子，模型就能尝试完成。

因此，上下文学习是 Agent 的起点。没有它，Chain-of-Thought、ReAct、工具 Schema、CLAUDE.md、Skills、系统提示词都很难以今天这种方式存在。现代 Agent 的很多“配置”本质上都是上下文工程。

Chain-of-Thought：让模型先拆解，再回答

这个里程碑主要来自 Google Research 在 2022 年发表的论文 《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》。论文的核心发现是：在 Prompt 示例中加入中间推理步骤，可以显著提升大模型在算术、常识和符号推理等复杂任务上的表现。

Chain-of-Thought Prompting 的核心想法很简单：对于复杂问题，不要直接要求模型给答案，而是在示例中展示中间推理步骤，让模型学习“先推导，再回答”的模式。

这件事的重要性在于，它证明了模型能力不仅取决于参数规模，也取决于如何提示。对于算术、常识推理、符号推理等任务，逐步推理的提示方式能显著提升表现。

不过，CoT 也需要被正确理解。它不是万能推理引擎，也不保证每一步都真实可靠。模型生成的推理过程可能看起来合理，但仍然可能包含错误。并且在许多产品形态中，系统不会把完整内部推理暴露给用户，而是用更安全、简洁的方式给出结果和必要解释。

对 Agent 来说，CoT 的价值在于建立了一个基础范式：复杂任务需要先拆解、再执行，而不是一次性生成答案。

后续的任务规划、步骤分解、自我检查、反思、测试驱动修复，都可以看作这个范式的延伸。

ReAct：Agent 的核心循环出现了

这个里程碑主要来自 2022 年的论文 《ReAct: Synergizing Reasoning and Acting in Language Models》。这篇论文提出让语言模型交替生成 reasoning traces 和 task-specific actions，使模型既能进行任务推理，也能通过行动与外部环境交互。

CoT 解决的是“如何想得更清楚”，但它仍然主要发生在模型内部。ReAct 往前走了一步：让模型在同一个轨迹中交替生成推理和行动。

一个典型 ReAct 循环包含四类元素：

Thought：我现在知道什么？下一步该做什么？
Action：调用搜索、计算器、数据库、文件系统、Shell 或其他工具。
Observation：工具返回了什么结果？现实世界给了什么反馈？
Next Thought：基于反馈修正计划，继续下一步。

这就是现代 Agent 最基本的执行循环。

ReAct 解决了两个问题。

第一，纯 CoT 容易在没有事实来源时编造。ReAct 允许模型通过工具获取外部信息，从而减少完全依赖参数记忆带来的幻觉。

第二，纯行动缺少规划。模型如果只是机械调用工具，很容易行动随机、成本高、无法纠错。ReAct 让模型在行动前有理由，在观察后能调整。

这也是为什么 ReAct 对 Agent 如此关键。今天的代码 Agent、浏览器 Agent、数据分析 Agent、运维 Agent，本质上都在实现某种形式的 ReAct：读取环境、推理下一步、执行动作、观察结果、循环迭代。

AutoGPT：第一波浪潮留下的教训

2023 年的 AutoGPT 浪潮让很多人第一次直观看到“自主 Agent”的想象力：用户给一个目标，Agent 自动拆解任务、搜索网页、写文件、调用工具，然后不断循环执行。

这个愿景非常吸引人，但早期完全自治 Agent 大多不稳定。它们经常出现几类问题：

幻觉循环：不断生成看似合理但错误的计划；
目标漂移：执行过程中逐渐偏离用户真正想要的结果；
接地不足：工具返回的是非结构化文本，模型容易误读或忽略；
验证不足：没有可靠机制证明任务真的完成；
上下文限制：历史步骤太长后，模型忘记目标和约束；
成本失控：自主循环消耗大量 token 和工具调用，但产出有限。

AutoGPT 的失败不是没有价值。相反，它给 Agent 领域留下了非常重要的工程教训：

没有接地、验证、边界和人类监督的完全自治，并不是可靠的产品形态。

后来的 Agent 系统没有简单追求“让模型一直自动跑”，而是转向更务实的路线：明确工具边界，结构化观察结果，加入测试与评估，把人类放在关键决策和验收环节中。

这也是为什么今天更成熟的 Agent 产品通常不是“设定目标然后离开”，而是“人类给目标，Agent 执行可验证步骤，人类在关键点审查和接管”。

函数调用：工具使用从文本约定变成结构化接口

早期 Agent 调用工具时，常常依赖文本格式，例如：

Action: searchInput: population of France 2024

这种方式脆弱：模型可能写错字段，漏掉参数，生成不存在的工具名，或者输出一段很难解析的自然语言。

函数调用改变了这一点。开发者把工具定义成带类型的 Schema，模型输出结构化的工具调用，Agent 运行时负责校验参数、执行工具，并把结果作为观察写回上下文。

{  "name": "search_web",  "arguments": {    "query": "France population 2024"    }}

这个变化很关键，因为它让 LLM 与外部系统的连接更像一个工程接口，而不是一段脆弱的文本约定。

不过，函数调用也不等于问题全部解决。Schema 只能约束格式，不能保证语义正确。模型仍然可能选择错误工具、传入不合理参数，或者误读工具返回。因此，工具层仍然需要做权限控制、参数校验、错误处理、审计日志和安全隔离。

函数调用真正带来的变化是：工具增强 LLM 开始具备产品化基础。

它把 ReAct 中的 Action 和 Observation 变得更可靠，也让文件、搜索、数据库、Shell、API、浏览器、代码编辑器等能力可以被统一接入 Agent 循环。

下面的Agent代码片段展示了一个Naive的带结构化工具调用的ReAct 循环：

def search_web(query: str) -> dict:    # 定义了一个搜索Web的工具，执行关键字的搜索/抓取。    # 返回 LLM 可检查的结构化证据。    return {"answer": "...", "sources": ["..."]}tool_impl = {"search_web": search_web}tool_schemas = [{    "name": "search_web",    "description": "Search the web",    "parameters": {        "type": "object",        "properties": {"query": {"type": "string"}},        "required": ["query"],    },}]messages = [{"role": "user", "content": "法国2024年人口数量?"}]# ReAct循环while not task_done(messages):    # 1. Agent 暴露 schema；调用LLM， LLM 进行推理返回工具调用或文本    # 返回文本。    reply = llm.chat(messages, tools=tool_schemas)    for call in reply.tool_calls:        # call = {"id": "...", "name": "search_web",        #         "arguments": {"query": "法国2024人口数量"}}        args = validate(call.arguments, schema=call.name)        result = tool_impl[call.name](**args)        # 2. 工具输出以 typed observation 形式返回。        messages += [reply, {            "role": "tool",            "tool_call_id": call.id,            "name": call.name,            "content": to_json(result),        }]        continue    # 3. 没有 tool call，表示最终回答或需要询问用户。    messages.append(reply)    break

SWE-Bench 与 SWE-Agent：Agent 开始面对真实软件工程

这个阶段其实包含两个相互关联的论文节点。第一个是 2023 年的 《SWE-bench: Can Language Models Resolve Real-World GitHub Issues?》，它提出了一个由真实 GitHub issue 和 Pull Request 构成的软件工程评测基准。第二个是 2024 年的 《SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering》，它进一步强调 Agent-Computer Interface，也就是 Agent 与计算机环境交互的接口设计。

在 Agent 发展中，SWE-Bench 是一个重要转折点。它不是让模型解玩具题，而是从真实 GitHub issue 和 Pull Request 中构造软件工程任务：给定一个代码库和一个 issue 描述，模型需要修改代码，让测试通过。

这件事重要在两个方面。

第一，它让“Agent 是否真的解决了问题”变得可测。过去很多 Demo 看起来很聪明，但很难判断结果是否正确。SWE-Bench 把判断标准交给测试和评测环境，而不是交给模型自我评价。

第二，它把软件工程任务的真实复杂度带进评测：大型代码库、多文件修改、历史上下文、依赖关系、测试失败、错误日志、补丁质量。这些都是真实开发中的关键难点。

SWE-Agent 进一步提出 Agent-Computer Interface，也就是 Agent 与计算机交互的接口设计。这个视角非常重要：同一个模型，如果工具接口设计不好，就像让开发者在一个糟糕 IDE 里工作；如果接口设计得好，模型就更容易搜索、阅读、编辑、运行测试和修复错误。

对于代码 Agent 来说，关键动作通常是一个循环：

这说明 Agent 的能力不只来自模型本身，还来自环境设计。代码搜索怎么返回？文件内容怎么裁剪？测试失败怎么摘要？编辑动作是整文件替换还是局部 patch？这些接口细节都会直接影响 Agent 的成功率。

推理模型：从“提示出推理”到“训练出推理”

这个阶段不是只对应一篇论文，而是一类模型训练范式的变化。其中最有代表性的公开论文之一，是 DeepSeek-AI 在 2025 年发布的 《DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning》。这篇论文展示了如何通过强化学习激发模型的推理行为，并介绍了 DeepSeek-R1-Zero、DeepSeek-R1 以及蒸馏模型系列。OpenAI o1 则是同一阶段更早进入大众视野的商业推理模型代表。

CoT 和 ReAct 主要通过提示方式释放模型能力。2024 年之后，推理模型成为新的关键节点。以 OpenAI o1、DeepSeek-R1 等模型为代表，这类模型更强调在回答前进行更长、更系统的内部推理，并在数学、代码、科学推理等任务上取得明显提升。

这种变化对 Agent 很重要，因为 Agent 的难点通常不在单步问答，而在多步任务：

目标不完整，需要澄清或补全；
环境复杂，需要不断观察；
行动有副作用，需要谨慎规划；
中间步骤可能失败，需要回滚或改路；
成功标准不只是“说得对”，还要“做成了”。

推理模型提升的是 Agent 的“控制能力”：更会规划，更会检查，更能处理长链路任务。

但也要避免过度神化。推理模型并不会自动解决 Agent 的全部问题。它仍然需要可靠工具、上下文管理、权限边界、验证机制和人类监督。更强的模型会提高上限，但系统工程决定了能否稳定落地。

现代 Agent 的典型架构

现代 Agent 不是“一个大模型 + 一组工具”这么简单。参考 《Dive into Claude Code》 对 Claude Code 架构的拆解，一个更接近真实产品形态的 Agent，通常由五个部分协同组成：交互层、核心运行层、安全与行动层、后端层和状态层。

1. 交互层：用户如何把任务交给 Agent

交互层负责承接用户入口。它可以是交互式 CLI，也可以是 IDE、桌面端、浏览器、无头 CLI，或者 Agent SDK。不同入口的体验不同，但最终都会把用户输入、文件、上下文、指令和中断信号交给统一的 UI / 渲染层，再进入 Agent Runtime。

这一层的重点不是“聊天框”，而是让 Agent 能被嵌入真实工作流：开发环境、自动化脚本、企业系统或第三方应用。

2. 核心运行层：Agent Loop 与上下文压缩

核心运行层是整个系统的大脑，主要包含两个关键组件：Agent Loop 和 上下文压缩管线（Compaction Pipeline）。

这里的 Agent Loop 可以看作前文 ReAct Loop 在真实产品架构中的工程化扩展。ReAct 提供了最基本的模式：先思考，再行动，再观察反馈，然后继续下一轮推理。现代 Agent 的 Agent Loop 仍然遵循这个核心思想，只是它要处理的不再是论文示例中的简单 Thought / Action / Observation 轨迹，而是更复杂的运行时问题：模型调用、工具路由、权限检查、上下文压缩、状态更新、中断恢复、多 Agent / 子 Agent 协作，以及结果输出。

因此，Agent Loop 不是一个全新的概念，而是 ReAct 模式进入真实系统后的运行时形态。它负责接收任务、调用模型、决定下一步动作、处理工具返回、更新状态，并持续推进任务。它对应的不是一次模型调用，而是一个持续循环：理解当前状态，决定下一步，执行动作，读取反馈，再继续调整。

上下文压缩管线则解决另一个现实问题：Agent 在运行过程中会不断积累上下文，包括用户要求、历史对话、工具结果、错误日志、文件内容和阶段性计划。如果全部原样塞进上下文窗口，不仅成本高，也未必能被模型有效利用。因此，系统需要对上下文进行组装、摘要和压缩，把真正重要的信息以更适合模型使用的方式提供给 Agent Loop。

这也解释了为什么“长上下文”不等于“上下文问题被解决”。Liu 等人在 《Lost in the Middle: How Language Models Use Long Contexts》 中指出，即使模型支持长上下文，当关键信息位于上下文中间时，模型性能也可能明显下降。因此，现代 Agent 需要上下文组装、压缩、索引和记忆机制，而不是简单依赖更大的 context window。

3. 安全与行动层：工具执行必须经过治理

Agent 真正变成“行动系统”，是因为它可以调用工具。但工具一旦能读文件、改代码、执行 Shell、访问外部资源，就必须有安全边界。

因此，安全与行动层通常包含几类能力：

权限系统与自动分类器：判断某个工具请求是否安全，是否需要用户批准；
Hook Pipeline：在工具执行前后插入检查、拦截、日志、策略或扩展逻辑；
内置工具：例如读写文件、搜索、编辑、运行命令等基础能力；
MCP 工具：通过 Model Context Protocol 接入外部系统和服务；
Shell 沙箱：限制命令执行范围，降低破坏性操作风险；
Plugins & Skills：为特定任务注入可复用能力；
Subagent Spawning：把子任务交给子 Agent，但通常只把摘要或转录结果返回主循环，避免上下文无限膨胀。

这一层的核心思想是：Agent 可以行动，但不能无限制行动。工具调用必须经过权限、沙箱、审计和策略控制。

4. 后端层：把动作落到真实环境

后端层负责承接具体执行。它可能是本地环境，也可能是云端、远程机器或外部服务。Shell 命令、文件操作、API 调用、代码执行、浏览器动作，最终都要落到某个执行后端或外部资源上。

这也是 Agent 与普通 Chatbot 的关键区别：Chatbot 主要生成文本；Agent 会把决策转化为真实环境中的动作。因此，后端层的隔离、权限和可回滚能力，会直接影响 Agent 的可靠性和安全性。

5. 状态层：让 Agent 能连续工作

状态层支撑 Agent 的连续运行。它通常包括：

Context Assembly：把当前任务所需的信息组装进上下文；
Runtime State：记录当前任务进度、工具状态、中断状态和执行结果；
Session Persistence：持久化会话，支持恢复和追踪；
CLAUDE.md + 记忆：保存项目级规则、用户偏好和长期上下文；
Sidechain Transcriptions：记录子 Agent 或旁路执行链路的摘要与转录。

如果说 Agent Loop 决定“下一步做什么”，状态层则保证 Agent 不会在长任务中失忆，也不会把所有历史原样塞进模型。它是上下文工程、任务连续性和可追踪性的基础。

这套架构说明了一个事实：Agent 不是一个模型，而是一个系统。 模型是核心推理引擎，但真正决定可靠性的，是工具接口、上下文组织、反馈循环、验证机制和安全边界。

开放挑战：现代 Agent 仍然没有被完全解决

即使到了今天，Agent 仍然面临许多困难。

1. 上下文工程

上下文窗口变大并不等于上下文问题消失。Agent 需要决定：哪些信息应该放进上下文？哪些信息应该通过工具按需读取？历史步骤如何摘要？用户约束如何保持不丢？这不是简单的“塞更多 token”，而是上下文工程。

2. Lost in the Middle 参见论文《Lost in the Middle: How Language Models Use Long Contexts》

长上下文模型仍然可能忽略中间位置的信息。对于 Agent 来说，这意味着关键约束、错误日志或历史决策可能被模型漏掉。因此，系统需要通过摘要、索引、引用、分层记忆和按需检索来组织信息。

3. 工具可靠性

工具调用格式可以被 Schema 约束，但工具选择、参数语义、权限边界、执行副作用仍然是工程问题。Agent 不能被允许随意执行危险命令，也不能在没有审计的情况下访问敏感数据。

4. 成功标准

很多任务没有像测试用例那样清晰的通过标准。例如写一份市场分析、设计一个架构方案、处理一个客户问题，成功标准往往是多维的。这类任务需要把评测、人工审查和业务指标结合起来。

5. 人机协作边界

最可靠的 Agent 不是完全自治，而是知道什么时候继续、什么时候停下、什么时候请求确认、什么时候把风险交给人类判断。

这也是未来 Agent 产品设计的核心：不是让 AI 无限自动化，而是让 AI 在正确边界内高效执行。

结论：Agent 的本质是“可反馈、可验证、可监督的行动系统”

AI Agent 的演进不是从聊天机器人直接跳到自主智能体，而是经历了清晰的能力积累：

GPT-3 让模型具备上下文适配能力；
CoT 让模型更会拆解复杂问题；
ReAct 把推理与行动接成循环；
AutoGPT 暴露了完全自治的工程风险；
函数调用让工具使用结构化、可产品化；
SWE-Bench 让真实软件工程任务可评测；
推理模型提高了长链路任务的规划与检查能力；
代码 Agent 把这些能力落到了真实开发流程中。

因此，一个成熟 Agent 不应该被定义为“能自己跑很久的模型”，而应该被定义为：

一个能围绕目标进行推理，调用工具作用于外部环境，读取反馈修正行为，并在可验证边界内接受人类监督的行动系统。

这也是为什么现代 Agent 会长成今天这个样子：它不是为了炫耀自治，而是为了在真实世界中可靠地完成任务。

参考资料

Brown et al., Language Models are Few-Shot Learners, NeurIPS 2020, arXiv:2005.14165
Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, NeurIPS 2022, arXiv:2201.11903
Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023, arXiv:2210.03629
OpenAI, Function Calling and Other API Updates, 2023
Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024, arXiv:2310.06770
Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, NeurIPS 2024, arXiv:2405.15793
OpenAI, Introducing OpenAI o1, 2024
DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025, arXiv:2501.12948
Anthropic, Claude Code
Anthropic, Model Context Protocol