Agent核心技术概念与范式发生了哪些演变以及背后的思考

来源：htmlDecode("阿里云开发者")

原文链接：https://mp.weixin.qq.com/s/11Krmb5KYmCHDQ4zN9O4uQ

阿里妹导读

文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
背景
近几年，随着基模能力的快速升级与迭代，Agent 领域迎来了爆发式的增长。特别是近期，像 Cloud Code、Codex、OpenClaw、Hermes 等可以说是全新一代的 Agent 产品和框架在不断涌现，Agent 的能力相比早期版本也出现了进一步的跃升，进一步推动了整个 Agent 生态的繁荣发展。
在此之前，我曾写过很多文章来介绍 Agent 的基本概念定义和基础范式，详情可以参考我之前写过的《为什么一定要做Agent智能体？》、《如何构建和调优高可用性的Agent？》等等文章。在当下这个时间节点，我们正处在 Agent 发展的快速变化期，现在的许多主流 Agent 技术在架构理念、实现路径上，与早期的 Agent 技术已经发生了较大的变化。然而，有许多的同学在学习和阅读 Agent 相关的文章内容的时候，仍然学习到了比较早期的内容，导致这里面有许多新旧技术概念混在一起，很容易搞不清楚，加上仍然还有些营销号现阶段还在转载比较早期的文章，导致大家越了解越迷糊。我之所以突然产生写这篇文章的想法，就是因为有不少同学在和我交流的时候，突然提到的一些技术概念，甚至会让我产生一丝 “穿越感” ~
Agent 相关的技术，并不是一蹴而就发展成现在这样的，很多技术概念前后之间也是有一定的相关、继承关系的。即使发生了演变前后的技术，也并非简单的替代关系，甚至还是可以相互结合使用。因此，在 Agent 的技术理念已经发生较大的变化的时候，我觉得非常有必要对 Agent 演化前后的范式进行一次更深入对比，梳理出 “Agent 技术是怎样变化的？为什么会这样变化？” 。
如果搞不清楚 Agent 技术范式背后的演化逻辑，很容易陷入“为了升级新架构而升级架构”或者“盲目追求最新技术概念”的误区。因此，本文旨在结合最新的行业实践和技术趋势，以及我个人对 Agent 的长期理解，详细拆解 Agent 的演化范式，希望能帮助大家在纷繁复杂的技术浪潮中，理清思路，找到最适合特定场景的技术选型。
从被动响应到自进化：Agent 发展的四个阶段
回顾 2023~2026 这三年的时间，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 基本上有如下几个特点：
● 交互形态：类似于增强版的 Chatbot，处于一种“一问一答”或“指令-执行”的聊天状态。
● 能力边界：严重依赖用户的明确指令。虽然引入了思维链（CoT，Chain of Thought）和简单的工具调用（Function Call）链条，但相对来将，基本上只能完成单点、短链路的小任务。
● 局限性：缺乏长期规划能力，一旦任务复杂度超出上下文窗口或逻辑链条过长，极易出现偏离或中断。在这个阶段，我们曾经做过的早期 Agent 探索可以详看我在24年初的文章《基于通义千问的阿里云小智服务领域Agent设计与实践总结》。
** 阶段二：工作流 Agent（结构化与可控性） **
在2024年时期，随着 to B 业务对稳定性要求的提升，纯靠 ReAct 这种“理想方式”解决不了复杂问题的情况下， Agentic Workflow 成为了主流，。这一阶段的核心理念是：用工程化的约束来弥补模型的不确定性。像 LangGraph、Dify 等都提供Workflow的流程编排。
与早期 Agent 阶段的纯模型驱动不同，Workflow Agent 引入了大量的硬约束和流程编排，我觉得这也可以理解为早期的 Harness （驾驭工程里的“约束”）吧，虽然当时没有这个概念，但所做事情的目标本质是一样的。这个阶段的 Agent 主要是如下几个特点：
● 架构特征：要么是整个大框架是一个固定的 Workflow，关键节点嵌入 LLM ；要么是 LLM 作为中枢，调用预定义好的子 Workflow 。是一套比较重的 Harness，虽然牺牲了一定的灵活性，但换来了极高的可控性和可解释性。
● 应用场景：Workflow 在 to B 领域极受欢迎。因为很多企业服务或日常重复性工作，并不需要真正的“智能决策”，只需要按照步骤 1、2、3 按时、按量、保质地完成即可。
● 价值体现：对于非长尾、非极度复杂的场景，Workflow Agent 依然是目前性价比最高、落地最稳定的方案。时至今日，仍有大量企业在使用这种形态，因为它能确保效果的下限。
** 阶段三：自主 Agent （复杂规划与长程任务） **
我个人认为，2025年是 Agent 迈向 “自主性”的关键转折点。先是以 Manus 为代表的通用 Agent的火爆，以及 Claude Code、Codex 等 AI Coding Agent 的出现等等，标志着 Agent 能力再一次质的飞跃。随后在2026年初火爆的 OpenClaw 等框架，继续扩大了受众群体，进一步巩固了这一技术趋势。
这一阶段的 Agent 可以被称为“自主 Agent”（Autonomous Agent），主要特征如下：
● 核心变化：它不再满足于快速调用几个工具后给出结论，而是具备了复杂的 Planning（规划）能力。面对用户模糊或宏大的需求，它能自行拆解任务、规划路径、调用工具，并进行多轮迭代。
● 长程任务能力：只要用户清晰描述需求，并设定好开发规范（Specs），Agent 就可以连续运行很长时间，自主处理企业级的项目代码或复杂业务流程。
● 自我校验：配合轻量级的 Harness 或自我校验机制，模型能够在长程运行中不断修正错误，最终交付高质量的结果。这是从“辅助者”向“执行者”角色的根本转变。
** 阶段四：自进化 Agent（持续学习与自我升级） **
随着2026年 Hermes Agent 等新一代框架的兴起，再配合上 LLM-Wiki 等这些开源项目，Agent 可以自我沉淀Skill、自我沉淀知识库，甚至可以通过 RL 训练来提升模型能力，让 Agent 的发展进入了 “自进化”（Self-Evolving）的新阶段。
这一阶段的核心本质，是开始解决“静态模型”与“动态世界”之间的矛盾。
● 机制原理：Agent 不仅仅是在完成任务，更是在完成任务的过程中沉淀经验。通过记忆模块、反馈循环和自我反思机制，Agent 能够将从前一次任务中获得的教训转化为新的知识或策略。
● 最终目标：实现 “越用越好用” 。Agent 能够根据历史交互数据，自动优化自身的提示词、工具选择策略甚至微调局部模型参数，实现自我升级和进化。
● 意义：这标志着 Agent 从“一次性消耗品”变成了 “可积累资产” ，为构建真正具备长期生命力的数字员工奠定了基础。
从最早期的 ReAct Agent，到结构化 Workflow Agent，再到后面可以自主规划长程任务的Agent，直至2026年开始出现的自进化 Agent，Agent 的范式演化清晰地展示了一条从“简单交互”到“复杂执行”，再到“智能成长”的技术进阶之路。需要注意的是，这四个阶段并非完全的替代关系，而是并存且互补的。在实际落地中，我们需要根据业务的复杂度、对稳定性的要求以及成本预算，选择合适的 Agent 范式，或者将多种范式组合使用。接下来，我们将从更深入的技术概念的角度，来展开介绍核心技术的前后演进变化。
六个核心 Agent 技术概念前后变化的思考
现如今，创建一个哪怕是最轻量级的 Agent，除了最关键的 Agent Loop，还会涉及到Prompt、Planning、Memory、Tools、Workflow、Environment等各个方面，今天我就以这六个最核心的技术维度，展开来介绍这些概念和实现都发生了哪些变化，以及为什么会发生这些变化？
** Prompt：深耦合 → 渐进式加载 **
既然要深入聊一下 Agent 里面各项技术的核心细节变化，那么就从大家最早开始接触LLM，也是写的最多、最熟悉的提示词（Prompt）开始吧。
回想早期构建 Agent 的阶段，我们绝大部分的精力都耗费在撰写 Prompt 上。当时为了解决特定领域或独立场景的问题，我们的做法往往是 “ 一个任务创建一个Agent ” 。比如，为了完成一篇高质量的文章，我们会拆解出多个 Agent：一个负责撰写初稿的“写作 Agent”，一个负责润色优化的“编辑 Agent”，还有一个负责生成配图的“绘图 Agent”等等。每个 Agent 的背后，都对应着一段精心调试、独立存在的System Prompt，这个 Prompt 里需要包括Agent的人设、任务目标、任务要求、约束条件、注意事项、各种示例等等。这种模式下，Prompt Engineering 几乎等同于针对每个任务单独写一段“小作文”，不仅维护成本极高，而且随着场景增多，Prompt 的管理变得极其混乱。
但随着实践的深入，我们发现这种将 “系统级指令” 与 “任务要求&细节” 紧耦合的方式存在明显的瓶颈。于是，在 Agent 近期的技术演进中，出现了许多 System Prompt 层面的 “ 解耦策略” 。核心思路是：尽量固化System Prompt，将动态的、具体的任务要求剥离出来。所以，现在的 Agent 系统的 System Prompt，基本上只保留最底层、最通用的系统级指令和基本行为规范，所需要的一些工具信息、Skill使用方式，基本保留的都是比较“固定”的部分，不太容易变化，使其保持极度的 “稳定” 。而原本堆积在System Prompt中的大量具体的、细节的，比如任务要求、领域知识、人设规范等 “动态内容” ，则被拆解并存储到了外部的文件系统中，然后通过渐进式披露（Progressive Disclosure）的方式来进行读取和加载。
具体来说，Prompt的动态性主要分为两个方向：
● Skill层面的沉淀：我们将执行某项具体任务的方法论、步骤要求、领域约束等，沉淀为独立的Markdown文件，比如 SKILL.md 等。这些文件构成了Agent的“技能库”或者“要求库”，Agent在执行特定任务时，会动态的渐进式披露加载对应的Skill中的Markdown文件，从而获取具体的操作指南。
● 配置文件存储：对于人设定义、用户偏好、搜索规则等通用规范，我们将其存储在类似 USER.md 、 SOUL.md 或 CLAUDE.md 、 AGENTS.md 这样的配置文件中。同样通过渐进式加载文件系统的方式，实现了对Prompt内容的模块化管理。
这种从“单体大System Prompt”到“System Prompt + 渐进式加载上下文文件”的转变，主要是“ 上下文的组织形式发生了变化 ” ，这样做让 System Prompt 变得更加纯粹和稳定，而将易变的业务逻辑和领域知识通过结构化的 Markdown 文件进行灵活挂载。这不仅降低了维护复杂度，也让Agent在面对不同场景时，能够更灵活地组合所需的上下文信息，实现了真正的“动静分离”。
** Planning：思维链 → 复杂长程任务 **
Agent 演化过程中，第二个显著的变化发生在 Agent 的 “规划（Planning）”层面。
还是回到早期 Agent 的理论基础，在 Lilian Weng 的《 LLM Powered Autonomous Agents 》一文中的 Planning 在刚提出的时候是一个非常新鲜的概念，这让很多人都坚信：一个真正会对任务做“Planning”的 Agent 才是真正意义上的 Agent 。然而，在那个基础模型还不够强的时代，Planning 的实现还是相对比较朴素的，主要就是依赖大模型原生的思维链（CoT， Chain of Thought）能力，比如通过类似 “Let's think step by step” 这样的提示词引导模型进行线性的、串行的逻辑推导。这种模式在处理简单任务时尚可应付，但在面对复杂场景时，往往显得力不从心，容易陷入逻辑断层或死循环。
然而，随着基础模型推理能力的飞速迭代，尤其是在 Reasoning 能力的显著增强的今天，如今的 Planning 机制其实已经发生了质的飞跃。现在的 Agent 不再仅仅满足于单步的思考，而是具备了更高级的如下的能力：
1. 复杂问题的结构化分解：Agent 能够主动将一个宏大的、模糊的目标拆解为多个可执行的子任务（Sub-tasks），并生成结构化的 Todo List。
2. 多步协同与长程推理：基于生成的任务列表，Agent 能够按步骤有序执行，并在执行过程中动态调整计划。这种能力使得 Agent 能够处理具有极长上下文依赖的复杂任务，保持逻辑的一致性和连贯性。
3. 子 Agent 的动态构建：在更先进的架构中，Planning 甚至涉及到根据子任务的需求，动态实例化或调用特定的子 Agent 来专项解决某个环节的问题，实现了从“单体思考”到“协同作战”的转变。
Planning 层面能够做到这样的演化的核心驱动力，归根结底在于“ 底层基座模型推理能力升级 ”所带来的。随着模型在逻辑推理、长文本理解以及复杂指令遵循上的表现越来越强，Agent 的 Planning 模块也从简单的“提示词技巧”演变成了真正的“智能决策中枢”，能够胜任更加复杂、长周期的自主任务规划。
** Memory：检索增强 → 文件系统化 **
第三个关键的变化，我们来看下“记忆（Memory）”模块的演进上。在 Lilian Weng 早期的经典架构中，Memory 被划分为短期记忆（Short-term Memory）和长期记忆（Long-term Memory）。当时的定义相对直观：
● 短期记忆：主要指对话上下文，包括 System Prompt、历史对话中的 User 和 Assistant 回复等。
● 长期记忆：主要指外部知识库，通常通过 RAG 从向量数据库中检索相关的文档或知识片段，作为背景信息注入给大模型。
然而，随着 Agent 应用场景的复杂化，这种简单的 Memory 管理方式已无法满足需求，两个维度的记忆机制都发生了演变。
短期记忆层面（Short-term Memory），核心挑战从“存储”转向了“管理”与“压缩”。由于 Context Window（上下文窗口）有限且成本敏感，为了保证长上下文下 Agent 的效果，以及高效利用有限的 token 就成为关键。从OpenClaw、Hermes这些最佳实践来看，上下文不再只是简单堆砌历史对话，而是引入了多种记忆压缩策略：
● 阈值控制：基于固定 token 数或动态语义密度阈值触发压缩。
● 结构化摘要：对中间过程的对话进行 Summary 提炼，同时保留头尾的关键指令和最终结论，确保核心意图不丢失。
● 重点提取：从冗长的对话流中提取关键事实或状态变化，剔除无关噪音。这些手段使得短期记忆更加精炼、高密度，显著提升了模型在长对话中的注意力集中度。
长期记忆层面（Long-term Memory），变化相对更大，逐步在从“向量数据库主导”向“文件系统主导”回归的趋势，并细分为两个子方向：
● 事项型记忆（Episodic Memory）：针对用户偏好、历史行为、每日待办等动态变化的“事实”，越来越多的框架，比如 OpenClaw、Hermes Agent等就倾向于使用文件系统进行记录。例如，通过生成 MEMORY.md 或每日的Memory日志文件，以结构化的 Markdown 格式存储关键事件。这种方式比向量检索更可控、更易读，也便于 Agent 直接读取和理解时间序列上的状态变化。
● 知识型记忆（Semantic Memory）：随着 Karpathy 等提出的 LLM-Wiki、GBrain这类本地化知识库理念的普及，大模型在知识存储上也在发生变化。传统的纯 RAG 方案正在被更灵活的本地文件系统 + Obsidian 等笔记工具所补充甚至替代。通过这些文件系统知识工具，Agent 可以直接访问组织良好的 Markdown 知识库，非常适合个人知识库的构建使用。当然，如果是企业级的知识库，存储了海量知识的背景下，仅通过这类“文件系统即记忆”的模式，还是不太够的，只通过
grep 类的命令关键词检索，很容易不准确。因此，除了文件系统之外，还需要搭配 QMD 或者 SQLite 等轻量化的向量化检索机制，甚至更加高度复杂的场景还需要企业级的向量检索，才能不仅保留 RAG 的海量知识优势，还赋予了开发者通过目录结构、标签、链接来显式组织知识的能力，使得知识的召回更加精准和可解释。
综上所述，Memory 的演进本质上是开始从纯向量文本检索走向“文件系统化的沉淀+向量检索混合管理” 。无论是短期的对话压缩，还是长期的事项记录与知识沉淀，都在追求更高的记忆效果、可读性和效率的均衡。
** Tools：Function Call → CLI / Script **
第四个部分，也是我认为 Agent范式中变化最为大的一个部分，在于“工具（Tools）”执行方式的变化。
回顾 Agent 发展的早期阶段，工具调用的主流范式是 Function Call 。我们需要针对具体的业务场景，将系统能力封装成标准的 API，并注册为模型可调用的函数。这种方式虽然实现了模型与外部系统的连接，但存在一个显著的痛点：极高的开发与维护成本。现实中，大量的系统或数据源并没有现成的 API 可供调用，为了弥补这一缺口，团队往往需要投入大量精力去“补全”API，这不仅费时费力，而且随着工具数量的膨胀，API Schema 的管理变得极其复杂。随后出现的 MCP（Model Context Protocol）虽然在协议层面优化了工具的注册与发现机制，实现了“一次注册，自动暴露”，但这本质上仍停留在接口标准化的层面，并未从根本上改变工具调用的底层逻辑。
而真正的范式转移发生在两个关键维度的变化： CLI 命令行原生化与 Script 脚本化。
首先， CLI（命令行界面），一种除了程序员之外，大部分人比较陌生的工具，在 Agent 时代再次焕新了它的生机。其实 CLI 这种枯燥的命令行和参数，对人类来讲并不是一种友好的交互方式，但对机器而言反而是足够友好的，从而演变成了 Agent 时代的“天然工具”。
CLI的主要的特点如下：
● 零样本学习优势：对于人类用户，记忆 grep 、 cat 、 vim 等 Linux / Unix命令及其参数是高门槛的；但对于大模型而言，这些命令是其预训练数据中海量代码和技术文档的一部分，属于 “ 先天知识 ” 。这意味着，让模型通过 CLI操作文件系统或网络，无需额外定义复杂的 API Schema（名称、描述、参数类型等），只需指令其使用标准命令即可。这节省了巨大的 token 空间和调试成本。
● 可扩展性与自解释性：即使面对模型未曾见过的第三方 CLI 工具，只要遵循标准的 Linux/Unix 规范（如支持 --help ），模型就能在运行时通过查询帮助文档，自主理解参数用法并执行调用。这种“按需查询、即时学习”的模式，完美契合了上下文工程的渐进式加载理念。
● Skill 集成：新的第三方 CLI 工具可以通过 Skill 进行包装，在 Skill 的描述文件中提供安装指南和使用示例，使模型能够快速掌握新工具的使用。
同时，在 Agent Skills 体系中， Resources 形态的 Script 脚本逐渐也成为工具承载的主流模式。无论是 Python 还是其他语言，具体的工具逻辑被封装为独立的脚本文件。这些脚本具有极强的灵活性：
1. 本地与远程的统一：它们既可以直接执行本地命令（如文件操作、环境配置），也可以内部封装对远程 API 的调用。
2. 协议的黑盒化：复杂的 API 鉴权、参数拼接等细节被隐藏在脚本内部，Agent 只需关注“调用哪个脚本”以及“传入什么核心参数”，极大地降低了模型理解的门槛。这也是为什么安装一个 Skill 往往就能赋予 Agent 处理复杂任务的能力——因为 Skill 不仅包含了 Prompt 指引，更内置了可执行的工具脚本。
综上所述，从早期的 Function Call 到如今的 CLI + Script 模式，Tools 的演进核心是从“人为适配模型”转向“利用模型原生能力”。我们不再试图为每一个操作编写专用的 API 接口，而是充分利用模型在预训练阶段积累的通用计算机操作知识（CLI）和代码执行能力（Script），构建更加轻量、灵活且易于扩展的工具生态。
** Workflow：刚性编排 → 动态混合封装 **
第五个值得关注的演变维度，是 Workflow（工作流）。
在 Agent 发展的早期阶段，由于基础大模型的指令遵循能力和逻辑稳定性相对较弱，我们往往依赖显式的、硬编码的 Workflow 来保障任务的执行。这种模式类似于传统的 “ 状态机 ” 或 “ 流水线Pipline ” ，将复杂任务拆解为严格固定的“第一步、第二步、第三步”，强制模型按部就班地执行。这种方式虽然牺牲了灵活性，但在当时是确保 Agent 不“跑偏”、不掉链子的必要手段。
然而，Workflow 也存在着很多的问题，比如运行过程非常 “ 机械化 ” ，无论Agent的外部环境发生了怎样的变化，Workflow 还仍然死板的严格遵循第一步、第二步...这样去运转，无法根据实际情况做出动态调整。但是，随着模型能力的不断跃升以及前文提到的 Agent Skills 体系的出现，Workflow 的形态正在发生深刻的重构：从“刚性的流程编排”转向“动态的 Skill 封装与混合架构” 。主要分为两部分：
● 逻辑内聚化：原本分散在 Workflow 引擎中的步骤定义、约束条件、核心判断逻辑，现在可以直接写入 Skill 的 Markdown 描述文件（如 SKILL.md ）中。模型通过阅读 Skills 的文档，即可理解任务的完整链路。
● 执行脚本化：对于需要精确控制的环节，不再依赖外部工作流引擎的状态跳转，而是通过 Skill 关联的 Resources 的 Script 脚本进行代码级的编排和控制。这意味着，一个复杂的业务流程，现在可以被打包成一个独立的、可复用的 Skills。
这种转变带来了更大的灵活性和智能性，但也引入了新的挑战：可控性与稳定性的博弈。纯 Skill 驱动的模式赋予了 Agent 更高的自主性，但在面对极端复杂或容错率极低的场景时，模型仍可能出现理解偏差或执行跳跃，导致结果不可控。相比之下，传统的刚性 Workflow 虽然笨重，却提供了确定性的边界。
因此，当前的 Agent 研发范式正处于一个新旧技术交叉融合的过渡期。在企业级落地实践中，我们很少非此即彼地选择某一种方案，而是倾向于采用混合架构：
●将成熟的、标准化的子任务封装为 Skills ，通过Markdown文件来维护逻辑，利用其灵活性和易用性；
●Workflow 里的固定运行部分其实是可以全部转换为Script的，但是代码的可读性，很多时候没有Workflow方便。因此，将关键的、对稳定性要求极高的主干流程仍然保留为 Workflow ，或者将特定的 Workflow 封装为一个特殊的 Tool 供 Agent 调用也是一个现阶段比较好的办法。
这种“Skill 为主，Workflow 为辅/兜底”的策略，既利用了新技术的红利，又保留了一定的确定性，是当前平衡开发效率与运行稳定性的最佳实践。
** Environment：无状态 → 运行时环境 **
除了上述这些核心模块的演进，Agent 要想真正落地并稳定运行，还离不开一个至关重要的基础设施：运行环境（Environment / Runtime）。
早期的 Agent 对工具调用、子Agent调用都是无状态的，几乎不需要所谓的 “ 运行环境 ” 。但是，随着 Agent 能力的增强，特别是引入了文件系统操作、代码执行等能力后，它不再仅仅是一个“问答机器”，而是一个需要持久化存储、文件读写和状态管理的“数字员工”。这就意味着，Agent 必须拥有一个专属的 Workspace（工作空间）。在这个工作空间中，Agent 可以安全地读取配置、写入日志、生成中间文件，甚至管理其 Skill 和 Memory 数据。
根据应用场景和安全要求的不同，这个 Runtime 环境主要呈现为两种形态：
● 本地个人电脑（Local Desktop）：有着极高的便利性和灵活性。Agent 可以直接操作用户本地的文件系统、应用和网络，实现诸如“整理桌面文件”、“自动化办公流程”等贴近个人生活的复杂任务，OpenClaw 最早就是基于个人电脑的操作而“火”起来的。但是，由于缺乏严格的隔离机制，Agent 的操作失误可能导致用户重要数据丢失或系统配置混乱。因此，在本地环境中，通常需要引入更严格的用户确认机制或权限控制。
● 沙箱环境（Sandbox/Cloud Server）：沙箱是企业级生产环境的主流选择。通过Docker、Kubernetes等容器化技术来构建隔离的沙箱，Agent 的所有操作被限制在特定的虚拟文件系统内。即使 Agent 执行了破坏性命令，也不会影响宿主机或其他服务。提供了必要的安全边界和资源管控，确保 Agent 在不可预测的行为下依然保持系统的整体稳定性。
总结
回顾全文，我们不难发现一个有趣的现象：从宏观架构上看，今天的 Agent 依然由 Prompt、Planning、Memory、Tools 等经典模块组成，这与 Lilian Weng 早期提出的理论框架并无二致。 “形”未变，但“神”已大不同。这并不是简单的技术升级，而是一场深刻的内核重构。Agent 的研发范式变化中， Prompt 从单体的“小作文”演变为解耦的上下文工程； Planning 从线性的 CoT 思维链升级为复杂的长程任务拆解； Memory 从传统的前置向量检索转向文件系统化+向量检索的混合架构； Tools 从高成本的 API 封装回归到原生的 CLI 与脚本交互； Workflow 从刚性的外部编排内化为灵活的 Agent Skills 封装； Environment 从无状态的调用延伸为有状态的隔离运行时Runtime系统环境。
每一个模块背后的运行逻辑、数据流转方式以及工程实现范式，都发生了翻天覆地的变化。我们不再仅仅依赖模型的“智商”去硬扛所有问题，而是通过更精细的工程化手段（如文件化解耦、CLI 原生利用、沙箱隔离等）来弥补模型的不足，放大模型的优势。这也说明 Agent 正在从“魔法调优”到“系统工程”的转变，标志着 Agent 技术正在走向成熟，同时，更是我们对 “ 如何构建好的 Agent ” 这一认知过程的不断深化。虽然各个模块的具体实现方式仍在快速演进，但其核心目标始终未变：即在保证安全、可控的前提下，最大化释放模型的推理与执行潜力，让 Agent 真正成为能够解决复杂现实问题的得力助手。
对于每一位从事 Agent 应用和落地的同学们而言，理解这些演进背后的逻辑，比掌握具体的某个工具更为重要。因为Agent还在持续发展，模型会继续升级、工具会继续变化，框架会持续更新，但这种 “通过工程化手段构建确定性，以承载模型不确定性” 的核心思想，将是未来很长一段时间内构建高质量 Agent 的基石。
我也希望本文对 Agent 技术演进过程的梳理，能为大家在构建自己的 Agent 系统时，提供一些不一样的视角和思考。另外，我哥个人能力也有限，一定也有许多我没有考虑到或者没有总结出的一些方法论，也欢迎大家多多提出、交流，我们互相学习，共同提升，能够更好的利用 Agent 这个技术在自己所属的领域业务中应用落地。本文是我个人技术探索的心路历程，一家之言、经验之谈，行文仓促，如有错误还请各位批评指正！