Agent 核心技术范式怎样演变：从 ReAct 到自进化

近两年，Claude Code、Codex、OpenClaw、Hermes 一类的产品和框架快速出现。它们表面上有不同的交互、工具和工作空间，底层却在回答同一件事：模型怎样从一次回答，变成一个能持续处理真实任务的执行者。

这使学习 Agent 变得容易混乱。早期文章里的 ReAct、CoT、Function Calling、向量数据库、工作流并没有过时；它们仍然在许多系统中发挥作用。不过，模型能力、上下文容量和运行环境改变以后，这些概念的职责与组合方式已经不同了。把新旧概念混在一起时，常会出现两种极端：要么觉得给模型一个长 Prompt 就够了，要么以为换一套新框架就能获得自主能力。

本文沿用一个简单的观察框架：先看 Agent 的四种能力形态，再从 Prompt、Planning、Memory、Tools、Workflow 和 Environment 六个维度看它们怎样变化。这是一张技术地图，不是一条严格的产品年代线。四种形态仍然并存，实际系统也常常把它们组合使用。

一、从被动响应到自进化的四种形态

Agent 的四段能力演进

第一种是早期的 ReAct Agent。ReAct 把 Reasoning 与 Acting 放在同一个循环里：模型理解请求，选择一个动作，读取观察结果，再决定下一步或直接回答。它让模型不再只是输出文本，也能搜索、查库或调用函数。早期产品大多是这种形态的扩展版，适合问答、单次工具调用和短链路任务。模型一旦需要记住很长的状态、处理大量例外或在失败后恢复，简单循环就开始吃力。

第二种是 工作流 Agent。当业务需要稳定性时，团队会把关键步骤、分支和审批写进 Workflow。模型负责理解、生成或路由，确定性系统负责顺序、状态和兜底。它看起来没有那么“自主”，却很适合规则清楚、重复发生、容错率低的企业流程。很多人今天看到的 Harness，其实延续了这类工程思路：用边界、验证和权限去承接概率模型。

第三种是 自主 Agent。近一代 Coding Agent 与通用执行型 Agent 的变化，主要不在于多了一个聊天窗口，而在于它们能够处理更长的任务：先把目标拆成 Todo，读取仓库或文件，执行命令、修改内容、运行验证，再根据结果继续推进。任务可以跨越很多次模型调用，模型也可以在过程里修正计划。所谓自主，并不表示它脱离约束，而是它在明确的工作空间、工具边界和完成条件内拥有更多推进空间。

第四种是 自进化 Agent。它关心的不再只是完成这一次任务，还会把可复用的经验沉淀为记忆、Skill、知识条目或候选工作流，再由评测和反馈决定哪些变化留下来。这里的“进化”不应理解为系统可以随意重写自己。更可靠的路径是：任务轨迹产生候选经验，经过隔离验证后再写入可回滚的资产。这样，Agent 才有机会从一次性工具变成可以积累的能力。

四种形态不是替代关系。固定的报销审核适合工作流，复杂代码改造需要更强的自主循环，个人知识管理又可能从自进化中受益。技术选型首先看任务是否明确、执行是否复杂、失败成本多高，以及是否存在能判断完成与否的证据。

二、Prompt：从一段“大作文”到渐进式上下文

早期构建 Agent 时，常见做法是“一个任务一个 Agent”。写作、检索、编辑、绘图分别对应一段精心调过的 System Prompt，里面同时放角色、人设、目标、约束、示例、领域知识和工具说明。场景少时很直接，场景一多，Prompt 就变成难以维护的配置集合：改一条规则要改多个副本，动态任务信息和稳定行为准则也混在一起。

今天更常见的组织方式是保留较小、稳定的系统指令，把会变化的内容放到外部文件与工具结果中，需要时再读入。这种方式可以叫作 Context Engineering。它不只是在“写得更好的 Prompt”，而是在管理当前一轮模型到底看到哪些高信号信息。

其中有两类内容最典型。第一类是 Skill：把某项任务的方法、前置条件、工具用法和验收要求写成可发现的 Markdown 文件。第二类是项目或用户级配置，例如 AGENTS.md、CLAUDE.md、USER.md，用于保存较稳定的规范与偏好。它们让系统指令保持克制，也让 Agent 可以通过渐进式披露加载与当前任务真正相关的材料。

这并不意味着 Prompt 从此不重要。相反，System Prompt 仍然定义边界、优先级和基本行为；变化的是它不再独自承担全部领域知识与任务细节。关于提示词契约、上下文选择和不可信内容进入系统的边界，可以继续阅读《提示词工程：从 System Prompt 到 Prompt Injection 防护》与《Context Engineering：Agent 每一步究竟看见了什么》。

三、Planning：从线性思考到长程任务管理

早期 Agent 对 Planning 的理解，很大程度来自模型的思维链能力。提示模型“一步一步想”，它可以完成有限的线性推理。这个方法对小任务很有效，却很难承受复杂执行：中途工具失败、外部信息变化、子任务互相依赖时，一段隐含推理无法承担任务状态。

自主 Agent 的规划通常会显式留下工件。一个大目标被拆成若干可执行子任务，重要依赖写入 Todo、任务图或文件；执行完一步后，系统记录结果、失败原因和下一步。模型仍在判断如何拆解和调整，但不必把所有事情都藏在一段连续的对话里。

长程任务还会引入专门的子 Agent 或子工作流。它们的价值不是“多几个模型一起思考”，而是把不同作用域、工具权限与上下文隔离开。例如，一个 Agent 负责定位问题，一个负责执行测试，主 Agent 收集证据后再决定修改路径。规划能力最终落在任务状态、验收条件和恢复机制上，而不只取决于模型写出多少推理文字。《ReAct、Planning 与 Reflection：Agent Loop 怎样形成反馈闭环》展开讨论了这条循环。

四、Memory：从检索增强到文件与检索的混合管理

早期架构常把 Memory 分成两层：短期记忆是对话历史，长期记忆是通过 RAG 从向量库检索到的知识。这个划分仍然有用，但复杂任务开始暴露出新的问题。对话越长，上下文越昂贵、噪声越多；用户偏好、已完成事项、错误恢复点和项目中间状态，也不适合只作为向量片段存在。

短期记忆因此更像上下文管理。系统会在接近窗口或任务阶段切换时压缩过程，保留目标、约束、关键发现、当前状态和待办，而不是机械地保存全部聊天记录。压缩后的摘要本身也是任务工件，需要能被后续 Agent 理解和核对。

长期记忆则逐渐出现文件化趋势。用户偏好、每日记录、项目决策和可读的知识笔记，适合写入 Markdown、数据库记录或版本化文件，因为人和 Agent 都能检查、修订和追溯。面对大量企业知识时，文件系统不必取代 RAG：目录、标签和链接可以提供显式结构，关键词、向量检索或数据库索引负责在规模变大后找到候选材料。更合理的方向是混合管理，而不是给所有信息寻找同一种存储。

《Agent 记忆系统：状态、检索与更新》把会话状态、任务状态、事实记忆和知识检索拆开解释。理解它们的差别，比先选择某个向量库更重要。

五、Tools：从 Function Calling 到 CLI、脚本与协议

Function Calling 为 Agent 提供了标准的动作表达：模型返回工具名和结构化参数，宿主程序完成真实执行。它并没有退出舞台，尤其适合边界清楚、权限敏感、需要稳定 Schema 的业务接口。

变化在于，Agent 不再只依赖为模型专门包装的一组 API。对代码、文件和系统任务而言，CLI 是天然的工具层。模型可以用 --help 理解命令，用 rg 搜索文本，用构建与测试命令验证结果；复杂的认证、参数拼接和远端调用可以藏在脚本里，再通过 Skill 提供使用说明。MCP 则解决了工具与资源的发现、连接和协议问题，让外部能力不必被每个宿主重复接入。

这几种方式并不冲突。Function Call 适合受控业务动作，CLI 适合工作空间内的通用操作，脚本适合封装复杂流程，MCP 适合作为连接器和工具协议。真正的重点始终是执行边界：谁可以调用什么，作用到哪份资源，怎样记录副作用，失败以后如何把结果交回下一轮。工具系统的完整分层见《Agent 工具系统：Function Calling、CLI、Browser 与 MCP》。

六、Workflow：从刚性编排到动态的混合结构

模型能力较弱时，工作流需要把“第一步、第二步、第三步”写得很死，避免模型偏离流程。它牺牲了一些灵活性，却能给业务提供确定的顺序、审批点和异常出口。

如今，很多原本分散在流程图里的说明，能被收进 Skill 的 Markdown 与关联脚本：模型读取说明后理解任务链路，脚本承担那些必须精确执行的部分。这样做让一个复杂能力更容易封装、复用和按需加载，也使 Agent 能对实际环境变化做调整。

但工作流并没有消失。涉及资金、发布、权限、合规或重复批处理时，确定性节点依然值得保留。更现实的组合是：让 Agent 在开放的理解、检索、方案生成与工具选择上发挥能力；把关键主干、校验、审批和可恢复状态留给 Workflow 或代码。Skill 和 Workflow 的关系不是谁替代谁，而是灵活性与确定性怎样分工。《AI Agent 的 Skill 系统设计》解释了 Skill 如何作为可复用的行为单元被加载。

七、Environment：从无状态调用到可控运行时

当 Agent 只是调用一个远端函数时，运行环境很容易被忽略。它获得文件读写、代码执行、浏览器和长期任务能力后，就需要一个真正的 Workspace：配置放在哪里，中间产物如何保存，进程怎样运行，任务中断后从哪里恢复。

本地个人电脑提供了最直接的能力。它能访问用户已有的文件、应用和网络，适合个人自动化与探索，也要求更细的确认和权限控制。沙箱或云端运行时则把文件系统、网络、凭据和资源限制在隔离范围内，适合需要审计、并发与恢复的生产任务。Agent 的能力越接近真实世界，Runtime、权限和可观测性越不能被当作附属配置。

这也是为什么今天谈 Agent，往往最终会谈到 Harness。模型负责理解、判断和生成；Harness 负责组织上下文、调用工具、管理状态、控制权限、收集证据并处理失败。它们共同构成一个可以运行而非只能演示的系统。想继续下钻，可阅读《Harness Engineering：从 Agent Loop 到可靠执行》。

结语：模块名称还在，运行方式已经换了

今天的 Agent 依旧可以拆成 Prompt、Planning、Memory、Tools 等经典模块，外形与早期理论框架并不陌生。变化发生在模块之间的连接方式：Prompt 从单体指令变成受管理的上下文；Planning 从线性推理变成带状态的长程任务；Memory 从单纯检索扩展为文件与索引共同维护；工具从少数函数扩展到 CLI、脚本和协议；工作流开始与 Skill、代码和模型循环协作；运行环境也成为能力与安全的共同边界。

这条演化线指向的不是一个固定框架，而是一种工程取向：用确定性的状态、权限、验证和运行时，承接模型带来的不确定性。模型会继续变化，工具和产品也会更替；理解这些模块为什么要这样组合，才更容易为具体场景选到合适的 Agent 形态。