前言

近几年，随着基座能力的快速升级与迭代，Agent 领域迎来了爆发式的增长。特别是近期，像 Claude Code、Codex、OpenClaw、Hermes 等新一代 Agent 产品和框架不断涌现，Agent 的能力相比早期版本出现了质的跃升，进一步推动了整个 Agent 生态的繁荣发展。

Agent 相关的技术，并不是一蹴而就发展成现在这样的，很多技术概念前后之间也是有一定的相关、继承关系的。即便发生了演变前后的技术，也并非简单的替代关系，甚至还是可以相互结合使用。因此，在 Agent 的技术理念已经发生较大变化。

如果搞不清楚 Agent 技术范式背后的演化逻辑，很容易陷入 “为了升级架构而升级架构” 或者 “盲目追求最新技术概念” 的误区。因此，本文旨在结合最新的行业实践和技术趋势，拆解 Agent 的演化范式，从而能够帮助我们理清思路，找到最适合特定场景的技术选型。

从被动响应到自进化：Agent 发展的四个阶段

回顾 2023~2026 这三年的时间，Agent 的技术形态并非线性平滑过渡，而是经历了四个具备显著特征的阶段演进。理解四个阶段的演进过程，有助于我们看清当前技术选型的底层脉络。

1. 阶段一：早期 Agent（被动式 ReAct）
2. 阶段二：工作流 Agent（结构化与可控性）
3. 阶段三：自主 Agent（复杂规划与长程任务）
4. 阶段四：自进化 Agent（持续学习与自我升级）

阶段一：早期 Agent（被动式 ReAct）

2023 年是 LLM 爆发的元年，也可以说是 Agent 概念的启蒙期。这一阶段的代表性理论源自 Lilian Weng 的那篇博客《LLM Powered Autonomous Agents》，它定义了基于大模型的 Agent 基本架构：LLM + Planning + Tools + Memory，给出了当时早期 Agent 比较理想的模型。这个时期，也有如 AgentGPT、AutoGen、MetaGPT 等等各种开源项目落地实现。

这个阶段的 Agent 本质上是「被动式响应」的。Agent 的核心架构基本上是基于比较初步的 ReAct 架构（Reasoning + Acting），基本上是符合单步的Reasoning → Observe → Response这样的过程链条，受限于基础模型的效果，能够做好 3 轮以上 Reasoning 的模型并不多。

早期 Agent 核心特点

1. 交互形态：类似于增强版 Chatbot，处于 “一问一答”“指令 - 执行” 的聊天状态。
2. 能力边界：严重依赖用户的明确指令。虽然引入了思维链（CoT，Chain of Thought）和简单的工具调用（Function Call）链条，但相对来讲，基本上只能完成单点、短链路的小任务。
3. 局限性：缺乏长期规划能力，一旦任务复杂度超出上下文窗口或逻辑链条过长，极易出现偏离或中断。

阶段二：工作流 Agent（结构化与可控性）

在 2024 年时期，随着 To B 业务对稳定性要求的提升，纯靠 ReAct 这种 “理想方式” 解决不了复杂问题的情况下，Agentic Workflow 成为了主流。这一阶段的核心理念是：用工程化的约束来弥补模型的不确定性。像 LangGraph、Dify 等都提供 Workflow 的流程编排。

与早期 Agent 阶段的纯模型驱动不同，Workflow Agent 引入了大量的硬约束和流程编排，这也可以理解为早期的 Harness（驾驭工程里的 “约束”）。虽然当时没有这个概念，但所做事情的目标本质是一样的。

阶段二 Agent 特点

1. 架构特征：要么是整个大框架是一个固定的 Workflow，关键节点嵌入 LLM；要么是 LLM 作为中枢，调用预先定义好的子 Workflow。是一套偏重的 Harness，虽然牺牲了一定的灵活性，但换来了极高的可控性和可解释性。
2. 应用场景：Workflow 在 To B 领域极受欢迎。因为很多企业服务或日常重复性工作，并不需要真正的 “智能决策”，只需要按照步骤 1、2、3 按时、按量、保质完成即可。
3. 价值体现：对于非长尾、非极度复杂的场景，Workflow Agent 依然是目前性价比最高、落地最稳定的方案。时至今日，仍有大量企业在使用这种形态，因为它能确保效果的下限。

阶段三：自主 Agent（复杂规划与长程任务）

我个人认为，2025 年是 Agent 迈向 “自主性” 的关键转折点。先是以 Manus 为代表的通用 Agent 的火爆，以及 Claude Code、Codex 等 AI Coding Agent 的出现，标志着 Agent 能力再一次质的飞跃。随后在 2026 年初火爆的 OpenClaw 等框架，继续扩大了受众群体，进一步巩固了这一技术趋势。

这一阶段的 Agent 可以被称为「自主 Agent（Autonomous Agent）」，主要特征如下：

1. 核心变化：它不再满足于快速调用几个工具后给出结论，而是具备了复杂的 Planning（规划）能力。面对用户模糊或宏大的需求，它能自行拆解任务、规划路径、调用工具，并进行多轮迭代。
2. 长程任务能力：只要用户清晰描述需求，并设定好开发规范（Specs），Agent 就可以连续运行很长时间，自主处理企业级的项目代码或复杂业务流程。
3. 自我校验：配合轻量级的 Harness 或自我校验机制，模型能够在长程运行中不断修正错误，最终交付高质量的结果。这是从 “辅助者” 向 “执行者” 角色的根本转变。

阶段四：自进化 Agent（持续学习与自我升级）

随着 2026 年 Hermes Agent 等新一代框架的兴起，再配合上 LLM-Wiki 这类开源项目，Agent 可以自我沉淀 Skill、自我沉淀知识库，甚至可以通过 RL 训练来提升模型能力，让 Agent 的发展进入了「自进化（Self-Evolving）」的新阶段。

核心本质

开始解决「静态模型」与「动态世界」之间的矛盾。

1. 机制原理：Agent 不仅仅是在完成任务，更是在完成任务的过程中沉淀经验。通过记忆模块、反馈循环和自我反思机制，Agent 能够从前一次任务中获得的教训转化为新的知识或策略。
2. 最终目标：实现 “越用越好”。Agent 能够根据历史交互数据，自动优化自身的提示词、工具选择策略甚至微调局部模型参数，实现自我升级和进化。
3. 意义：这标志着 Agent 从 “一次性消耗品” 变成了「可积累资产」，为构建真正具备长期生命力的数字员工奠定了基础。

阶段补充说明

从最早期的 ReAct Agent，到结构化 Workflow Agent，再到自主规划长程任务 Agent，直至 2026 年出现的自进化 Agent，Agent 的范式清晰展示了一条从「简单交互」到「复杂执行」，再到「智能成长」的技术进阶之路。

需要注意：这四个阶段并非完全替代关系，而是并存互补。在实际落地中，我们需要根据业务的复杂度、对稳定性的要求以及成本预算，选择合适的 Agent 范式，或者将多种范式组合使用。

六个核心 Agent 技术概念前后变化的思考

现如今，创建一个哪怕是最轻量级的 Agent，除了最关键的 Agent Loop，还会涉及到 Prompt、Planning、Memory、Tools、Workflow、Environment 等各个方面。今天我就以这六个核心技术维度，展开介绍这些概念在理念和实现上发生了哪些变化，以及变革背后的原因。

一、Prompt：深耦合 → 渐进式文件加载

早期模式：高耦合 / 高维护成本

过去构建 Agent 时，绝大部分精力都耗费在撰写 Prompt 上。当时主流思路是「一个任务创建一个 Agent」。比如为了完成一篇高质量文章，我们会拆分多个 Agent：写作 Agent、润色编辑 Agent、配图 Agent。每一个 Agent 背后都对应一版精心调试、独立存在的 System Prompt。Prompt 内部需要写清人设、目标、约束、示例、格式要求等全部内容。

这种模式弊端非常明显：

1. 高耦合：每个 Agent 都包含大量重复相似内容
2. 高维护成本：修改逻辑就要逐个更新，成本极高、极易出错
3. 扩展性差：难以复用，不利于规模化落地

当前模式：Prompt 解耦策略

核心思路：固化稳定部分，剥离动态内容，渐进式加载

1. 固定 System Prompt（静态）

   只保留底层通用指令、行为规范、输出格式、安全约束这类几乎不会变动的内容，保证基座稳定不变。

2. 外部文件系统（动态）

   将频繁变化的业务内容剥离出来，存放在外部文件：

   • Skill / 知识库 / 资源库：业务方法论、领域知识、案例样例
   • 任务要求、人设、约束规则、各类配置

采用 ** 渐进式披露（Progressive Disclosure）** 的方式，Agent 在运行过程中按需读取、加载外部文件内容。

两类典型外部文件

1. Skill 层面沉淀

   我们将执行某类任务的方法论、步骤、约束沉淀为独立 Markdown 文件（如 SKILL.md等），构成 Agent 的技能库。Agent 执行任务时动态加载对应文档，获取执行规范。

2. 配置文件存储

   人设偏好、搜索规则、全局约束写在 USER.md、AGENTS.md、CLAUDE.md 配置文件中，同样渐进加载，实现 Prompt 模块化管理。

变革价值

从「单体大 System Prompt」转变为「固定系统提示 + 渐进加载上下文文件」：

1. System Prompt 更加纯粹稳定，出错概率更低；
2. 易变动的业务逻辑、领域知识通过结构化 Markdown 灵活挂载；
3. 大幅降低维护复杂度，不同场景下可以自由组合上下文信息，真正做到动静分离；
4. 可维护性、扩展性大幅提升，统一一套基座，低成本扩展各类业务能力。

二、Planning：思维链 → 复杂长程任务拆解与推理

Agent 演化过程中，第二个显著变化发生在 Agent 的「规划（Planning）」层面。

早期规划：CoT 思维链线性推导

探索模式：Let's think step by step 底层逻辑：依靠单轮线性思考串行推导，输入问题后分步思考，逐步拆解获取信息，最终整合输出答案。短板

1. 缺乏结构化拆分，难以处理复杂多目标任务；
2. 逻辑断层风险高，长推理能力孱弱；
3. 无法动态协作，难以构建多子 Agent 体系。

在 Lilian Weng《LLM Powered Autonomous Agents》理论基础刚提出时，Planning 实现方式非常朴素，完全依赖大模型原生 CoT 思维链能力，用「一步步思考」这类提示词引导模型串行逻辑推导。这种模式处理简单任务尚可，面对复杂场景极易逻辑断层、死循环。

高级规划：复杂智能决策中枢

高层模式：结构化拆分 + 多步协同 + 长程推理 + 动态构建子 Agent

完整流程：

1. 目标拆解与分析：理解顶层目标，拆分关键要素；
2. 结构化分解（任务拆分）：将大目标拆解为多个子目标，每个子目标对应多项子任务；
3. 多步协同与长程推理：多个子任务有序执行，执行中动态调整路径；
4. 动态构建子 Agent 与工具调用：针对专项环节实例化独立子智能体；
5. 决策输出与执行：整合结果，闭环校验。

随着基座模型推理能力飞速升级，如今 Planning 产生质的飞跃，现代 Agent 的高级规划具备三类核心能力：

1. 复杂问题结构化分解：Agent 主动将宏大模糊目标拆解为多个可执行子任务，生成结构化 TodoList；
2. 多步协同与长程推理：按照任务列表有序执行，执行途中动态调整方案，处理超长上下文依赖任务，保证逻辑一致性；
3. 子 Agent 动态构建：在复杂流程里按需生成专项子 Agent，完成单点攻坚，实现从「单体思考」到「多智能体协同作战」。

演进底层驱动力

底层基座模型推理能力升级，模型在逻辑推理、长文本理解、复杂指令遵循上表现大幅提升，Planning 模块从简单提示技巧，升级为整套智能决策中枢，能够胜任超长周期、自主规划类复杂任务。

三、Memory：检索增强 → 文件系统化的沉淀与检索

在 Lilian Weng 经典架构里，Memory 被划分为短期记忆（Short-term Memory）和长期记忆（Long-term Memory），早期定义非常直白：

1. 短期记忆：主要对话上下文，包含系统提示词、历史用户与模型对话记录；
2. 长期记忆：外部知识库，依靠 RAG 在向量数据库检索文档片段，作为背景信息输入大模型。

随着 Agent 场景复杂化，简单的 Memory 存储模式无法满足需求，短期、长期记忆两条分支都发生重大变革。

短期记忆演变：从「单纯存放上下文」→「管理 + 压缩优化」

受限于上下文窗口（Context Window）长度与 Token 成本，现代短期记忆核心目标是：在有限上下文内保留关键信息，提升推理质量与执行效率。主流优化策略：

1. 阈值控制：基于固定 Token 数值、或者动态语义密度阈值触发内容压缩；
2. 结构化摘要：对中间冗长对话做 Summary 提炼，只保留首尾关键指令、最终结论，保证核心意图不丢失；
3. 重点提取：从超长对话里抽取关键事实、状态变更，剔除冗余噪声，提升长对话注意力集中度。

长期记忆演变：从「向量库单一支配」→「文件系统 + 向量检索混合架构」

分为两大分支：

1. 事项型记忆（Episodic Memory 情景记忆）

   针对用户行为、历史任务、状态变化，主流方案改用文件系统记录。例如 OpenClaw、Hermes Agent 采用 MEMORY.md 结构化 Markdown 记录事件时序，对比纯向量检索：可读性更强、人工可编辑、状态追踪更直观可控。

2. 知识型记忆（Semantic Memory 语义记忆）

   依托 LLM-Wiki、GBrain 等本地化知识库方案，以「文件系统 + Obsidian 笔记」为载体构建知识库；企业海量知识库场景下，搭配 QMD、SQLite 轻量化向量库，兼顾全文结构化浏览、精准向量检索，解决纯文件检索模糊匹配不准、纯向量可读性差的问题。

Memory 整体演进总结

Memory 整体演进路线：纯向量文本检索 → 文件系统化沉淀 + 向量检索混合管理；无论短期上下文压缩优化，还是长期事件、知识沉淀，都在平衡记忆效果、可读性、运行效率三者，兼顾落地实用性。

四、Tools：Function Call → CLI / Script

早期工具形态：以 Function Call 为主

早期 Agent 工具调用范式基于 Function Call，开发者针对业务场景定制 API 接口，封装成模型可调用函数。

缺陷

1. 接入成本极高：每一个外部能力都需要单独开发、封装、注册 API；
2. 扩展性弱：新增第三方工具就要改写 Schema、新增调用逻辑；
3. 模型边界受限：只能调用预设好的接口，无法灵活拓展系统原生能力；
4. 维护成本高：大量 API 随业务迭代更新，Schema 管理极度繁琐。

即便 MCP 协议优化了工具注册逻辑，底层调用模式依然没有本质改变。真正范式变革来自 CLI 命令原生调用、Script 脚本化封装两大方向。

当前工具形态：CLI 命令行 + Script 脚本为主

1. CLI 命令行模式优势

1. 零样本学习优势：grep、cat、vim、ls 等 Linux 基础命令是大模型预训练原生知识，不需要额外写接口描述、参数说明，模型天生理解调用方式，节省大量 Token 与调试成本；
2. 极强可扩展性：陌生第三方 CLI 工具，只要自带 --help 帮助文档，Agent 运行时自动读取文档自学调用；完美契合渐进式加载设计；
3. Skill 易集成：新工具只需在 Skill 文档内写明安装方法、使用示例，模型即可快速上手使用。

2. Script 脚本模式优势

Python 等各类脚本文件成为工具主流载体：

1. 本地远程统一：既可以执行本地文件操作、环境配置，也可以封装远程 API 调用逻辑；
2. 屏蔽底层复杂度：鉴权、参数拼接、异常捕获全部封装在脚本内部，Agent 只需要传入核心参数调用脚本即可，大幅降低模型理解门槛；
3. 高度灵活：复杂业务能力打包进脚本，一份 Skill 附带提示词 + 可执行脚本，开箱即用。

Tools 演进核心逻辑

从「人为定制接口适配模型」，转变为「利用模型原生知识适配系统」；充分利用大模型预训练阶段掌握的计算机命令知识、代码编写执行能力，搭建轻量化、高灵活、易扩展的工具生态。

五、Workflow：刚性流程编排 → 动态封装与混合架构

早期 Workflow：刚性流程编排

早期因为模型稳定性不足，业界普遍采用硬编码流水线、状态机编排 Workflow，把复杂任务拆分为固定步骤，强制模型按既定节点执行。

缺陷

1. 僵化死板，无法根据环境变化动态调整分支；
2. 变更成本高，业务微调就要重构整个流程链路；
3. 智能度低，全程机械化执行，容错性差。

当前 Workflow：动态 Skill 封装 + 混合架构

现代 Workflow 完成两大转变：

1. 逻辑内聚化：原本分散在流程引擎里的判断逻辑、约束条件、分支规则，全部写入 Skill 的 Markdown 描述文件，模型阅读文档自主理解完整业务链路；
2. 执行脚本化：精准管控的关键环节，不再依赖外部流程引擎做状态跳转，通过 Skill 绑定 Script 脚本实现精细化控制。

落地混合最佳实践

纯 Skill 自主性太高，极端低容错场景容易跑偏；刚性 Workflow 稳定性强但灵活性不足。因此主流落地采用混合架构：

1. 标准化子任务封装为 Skill，依靠 Markdown 文档保证灵活迭代；
2. 项目主干、高确定性要求流程保留轻量化 Workflow 兜底；
3. 稳定固定 Workflow 也可以封装成一个特殊 Tool，供自主 Agent 按需调用。

「Skill 为主，Workflow 兜底」是现阶段平衡开发效率、运行稳定性最优方案。

六、Environment：无状态 → 运行时 Runtime 环境

早期环境：无状态运行

早期 Agent、子 Agent 工具调用全程无状态，不需要专属运行环境。

局限

1. 无持久化存储，无法留存中间运行结果；
2. 缺少文件读写能力，不能落地复杂长任务；
3. 无状态隔离，多任务并行极易互相污染。

当前环境：有状态 Runtime 运行环境

随着 Agent 具备文件读写、代码执行、长周期自主运行能力，专属运行 Workspace（工作空间）成为必备基础设施，分为两大主流形态：

1. 本地桌面环境

   依托本机文件系统，自由度极高，适合个人场景；缺点是无安全沙箱，异常脚本可能污染本机系统文件，一般搭配权限校验、二次确认机制规避风险。

2. 沙箱容器环境（Sandbox）

   基于 Docker、K8s 构建隔离容器，是企业级落地首选；Agent 所有运行行为被限制在虚拟容器内，即便执行高危命令，也不会影响宿主机服务；自带资源配额、网络隔离、超时销毁机制，保障系统整体稳定安全。

现代运行环境必备能力：文件系统读写、日志记录、状态管理、资源管控、网络权限隔离，让 Agent 真正拥有专属「数字工位」，支撑超长任务自主闭环运行。

全文总结

纵观六大模块演变：宏观架构上，现代 Agent 依旧沿用 Prompt + Planning + Memory + Tools + Workflow + Runtime 经典骨架，和 Lilian Weng 原始理论架构外形一致；但内核全部重构，六大模块全部完成范式升级：

模块	过去形态	当前形态
Prompt	高耦合整块提示词	静态基座提示 + 外部文件渐进加载
Planning	CoT 线性思维链串行推理	多层级结构化拆解 + 多智能体协同长程规划
Memory	RAG 向量检索为主	短期记忆压缩治理 + 长期记忆「文件 + 向量」混合存储
Tools	Function Call 自定义 API 调用	CLI 原生命令 + Script 脚本双主流形态
Workflow	刚性固定流水线编排	Skill 柔性封装 + 刚性流程兜底混合架构
Environment	无状态极简调用	带沙箱 / 隔离空间的有状态 Runtime 运行环境

每一个模块背后的运行逻辑、数据流转方式以及工程实现范式，都发生了翻天覆地的变化。我们不再仅仅依靠模型 “智商” 硬扛所有问题，而是通过更精细的工程化手段（文件化解耦、CLI 原生利用、沙箱隔离等）弥补模型的不足、放大型模型优势。这也标志着 Agent 正在从「魔法调优」走向「系统工程」，Agent 技术走向成熟。

贯穿所有演变的核心底层思想：用工程化手段构建确定性，来承载大模型本身的不确定性，在安全可控的前提下最大化释放模型推理、执行能力，让 Agent 真正落地解决现实业务问题。

对于所有做 Agent 落地实践的从业者来说，理清演变背后逻辑，远比死记某一个框架、某一行代码更加重要。模型、框架、工具会持续迭代更新，但这套工程化平衡思路，会长期作为高质量 Agent 搭建的底层基石。