Agent的来时路

如果你在2023年问一个人”Agent是什么”，大概率会得到一个模糊的回答——大概就是ChatGPT加几个插件吧。但如果你在2026年再问同样的问题，答案可能已经变成了”一个能自己规划任务、写代码、跑测试、修Bug，甚至还能自我学习的数字员工”。

三年时间，Agent从”会聊天的机器人”走到了”能干活的员工”。这条路不是一步跨过去的，而是一段有迹可循的来时路。今天我们就沿着这条路走一遍，看看Agent到底是怎么一步步变成现在这样的。

第一站：被动响应的”听话小孩”（2023）

2023年是大模型的元年，也是Agent概念的启蒙期。那一年，Lilian Weng写了一篇著名的博客《LLM Powered Autonomous Agents》，给Agent画了一张蓝图：LLM + Planning + Tools + Memory。这张图后来几乎成了所有Agent文章的开场白。

但蓝图归蓝图，当时的Agent实际能做什么呢？说起来有点寒酸——基本上就是一个”增强版的聊天机器人”。你问它一句，它想一下，然后回答你。再问一句，再想一下，再回答。这个”想一下”的过程，就是当时最核心的架构：ReAct（Reasoning + Acting）。它的逻辑很简单：推理 → 观察 → 回应，一轮一轮地转。

打个比方，这个阶段的Agent就像一个刚入职的新人，你让他做什么他就做什么，你不说话他就等着。你跟他说”帮我查一下明天的天气”，他能调用个天气API给你结果。但如果你说”帮我规划一次为期五天的云南旅行”，他可能查了机票就忘了酒店，查了酒店又忘了路线。不是他不想做，是他的”脑容量”——也就是上下文窗口——实在装不下那么多东西，推理链条一长就容易断。

这个阶段的Agent有几个明显的特征：交互上是一问一答的模式，能力上严重依赖用户的明确指令，一旦任务复杂度超出上下文窗口或者逻辑链条过长，就很容易跑偏甚至直接中断。虽然引入了思维链（CoT）和简单的Function Call，但基本上只能完成单点、短链路的小任务。

第二站：流程编排的”流水线工人”（2024）

到了2024年，Agent开始进入企业视野。但企业可不像个人用户那样能容忍”偶尔跑偏”，企业要的是稳定、可控、可复现。于是，一个很现实的问题摆在了面前：纯靠模型自己想，想不准怎么办？

答案很朴素：既然模型不可靠，那就用工程手段来兜底。这就是Workflow Agent的核心思路——用流程编排来约束模型的行为。

想象一下，你不再让那个新人”自己看着办”，而是给他一份详细的SOP：第一步做什么、第二步做什么、第三步做什么，每一步的判断标准是什么，什么条件下走A分支、什么条件下走B分支，全部写得清清楚楚。他不需要思考”接下来该干嘛”，只需要按流程走就行。

这种模式下，要么整个大框架是一个固定的Workflow，关键节点嵌入LLM做智能判断；要么LLM作为中枢，调用预定义好的子Workflow。本质上就是给模型套了一层”硬壳”，虽然牺牲了灵活性，但换来了极高的可控性和可解释性。

这种方案在企业服务场景极受欢迎。因为很多日常工作并不需要什么”智能决策”，只需要按照步骤1、2、3按时按量保质完成即可。时至今日，Workflow Agent依然是很多企业落地的首选方案，因为它能确保效果的下限。

但Workflow的问题也很明显：它太”死”了。无论外部环境怎么变，Workflow还是死板地按第一步、第二步走，无法根据实际情况做出动态调整。就像一个只会照着菜谱做菜的厨师，盐放多了也不知道尝尝咸淡。

第三站：自主规划的”独立员工”（2025）

2025年是Agent迈向”自主性”的关键转折点。Manus的火爆、Claude Code和Codex等AI编程Agent的出现，标志着Agent能力又一次质的飞跃。

这个阶段的Agent最大的变化是什么？是它终于能”自己想”了。

之前的Agent，要么是你推一下它动一下（ReAct），要么是你画好路线它照着走（Workflow）。而自主Agent不一样，你给它一个目标，它能自己拆解任务、规划路径、调用工具，还能在执行过程中动态调整计划。就像一个真正成熟的员工，你只需要告诉他”这个项目下周要交付”，他自己会安排哪天做需求分析、哪天写代码、哪天跑测试。

这里有一个关键能力的跃升：长程任务执行。只要用户清晰描述需求并设定好开发规范，Agent就可以连续运行很长时间，自主处理复杂的项目代码或业务流程。配合轻量级的自我校验机制，模型能在长程运行中不断修正错误，最终交付高质量的结果。这是从”辅助者”向”执行者”角色的根本转变。

第四站：自我进化的”成长型员工”（2026）

如果说前三个阶段的Agent都是”用完即止”的——任务完成了，经验就散了，下次遇到类似问题还得从头来——那么2026年开始出现的自进化Agent，则试图解决一个更本质的问题：Agent能不能越用越好用？

这背后的核心矛盾是”静态模型”与”动态世界”之间的张力。模型的训练数据有截止日期，世界却在不断变化。一个只会用训练时知识的Agent，终究会过时。

自进化Agent的解法是：在完成任务的过程中沉淀经验。通过记忆模块、反馈循环和自我反思机制，Agent能将前一次任务中获得的教训转化为新的知识或策略。比如，它发现某类Bug总是出现在特定模式下，就会把这个规律记录下来，下次遇到类似代码时主动规避。它发现某个Prompt模板效果更好，就会自动优化自己的提示词。甚至可以通过强化学习来微调局部模型参数，实现真正的自我升级。

打个比方，这就像一个员工不仅会干活，还会写工作笔记、更新操作手册、甚至自己报名培训提升技能。从”一次性消耗品”变成了”可积累资产”。

走过四站之后：六个核心技术如何蜕变

看完Agent发展的四个阶段，你可能会觉得：这不就是模型变强了嘛，有什么好说的？模型变强确实是根本驱动力，但同样的模型能力，用不同的工程方式去组织，效果可以天差地别。接下来我们就拆开来看，Agent的六个核心技术模块，在这条来时路上各自经历了怎样的蜕变。

Prompt：从”小作文”到”动静分离”

如果你在2023年做过Agent开发，一定对写Prompt这件事印象深刻。那时候的思路是”一个任务一个Agent”，每个Agent背后都对应着一段精心调试的System Prompt，里面塞满了人设、任务目标、约束条件、注意事项、各种示例……写起来像写小作文，维护起来像维护遗产——场景一多，Prompt之间互相矛盾、互相重复，管理极其混乱。

这种把”系统级指令”和”任务细节”紧耦合在一起的方式，瓶颈很明显：系统级指令是稳定的，任务细节是多变的，把它们搅在一起，改一个地方可能牵一发动全身。

后来的演进方向很自然：拆开。System Prompt只保留最底层、最通用的系统级指令和基本行为规范，保持极度稳定。而那些具体的、易变的任务要求、领域知识、人设规范等”动态内容”，则被拆解存储到外部文件中，比如SKILL.md、USER.md、SOUL.md、AGENTS.md这些配置文件。Agent在执行特定任务时，会按需渐进式加载对应的文件，而不是一开始就把所有信息塞进上下文。

举个例子来理解这种变化：以前的方式就像你出门旅行，把所有可能用到的衣服、药品、书籍、工具全部塞进一个巨大的行李箱，不管用不用得上都带着，行李箱又重又乱。现在的方式是只带必需品在随身包里（System Prompt），其他东西按需从家里取（渐进式加载文件）。轻装上阵，按需取用。

这种”动静分离”的思路，本质上是一种上下文工程——不只是写好Prompt，而是组织好什么信息在什么时候以什么方式提供给模型。

Planning：从”一步一步想”到”自己拆任务”

Planning这个概念在Agent早期就存在了，但那时候的Planning其实很”朴素”。核心就是靠大模型的思维链（CoT）能力，通过类似”Let’s think step by step”这样的提示词，引导模型进行线性的、串行的逻辑推导。说白了就是”一步一步想”。

“一步一步想”在简单任务上还行，但面对复杂场景就容易出问题。就像你让一个人”一步一步想”怎么造一栋楼，他可能想到第三步就忘了第一步是什么了。线性推导没有全局视野，缺乏回溯和调整的能力，容易陷入逻辑断层或死循环。

现在Planning的质变体现在三个层面：

第一，结构化分解。Agent不再只是”一步一步想”，而是能主动把一个宏大目标拆解成多个可执行的子任务，生成结构化的待办清单。就像项目经理拿到一个大需求后，第一件事不是埋头干活，而是先拆任务、排优先级。

第二，多步协同与长程推理。基于生成的任务清单，Agent能按步骤有序执行，并在执行过程中动态调整计划。不是死板地按计划走，而是边走边看、边看边调。

第三，子Agent的动态构建。在更先进的架构中，Planning甚至能根据子任务的需求，动态实例化专门的子Agent来专项解决某个环节。从”一个人干所有事”变成了”一个团队协同作战”。

这一切的核心驱动力，归根结底是底层基座模型推理能力的升级。模型变强了，Planning才能从”提示词技巧”进化为”智能决策中枢”。

Memory：从”向量检索”到”文件系统化”

Memory模块的演进可能是六个模块中变化最大的之一。在Lilian Weng的经典架构中，Memory被简单划分为短期记忆和长期记忆：短期记忆就是对话上下文，长期记忆就是通过RAG从向量数据库中检索知识片段。

这个分类在当时够用，但随着Agent应用场景的复杂化，两个维度都遇到了瓶颈。

短期记忆的核心挑战从”存储”转向了”管理与压缩”。上下文窗口有限且成本敏感，简单堆砌历史对话既浪费token又分散模型注意力。现在的做法是引入多种记忆压缩策略：基于token数或语义密度阈值触发压缩、对中间过程做结构化摘要提炼、从冗长对话中提取关键事实剔除噪音。核心思路是让短期记忆更加精炼、高密度，确保模型在长对话中始终聚焦关键信息。

长期记忆的变化更大，出现了一个有趣的趋势：从”向量数据库主导”向”文件系统主导”回归。这听起来有点反直觉——不是应该越来越高级吗？怎么还回退到文件系统了？

其实道理很简单。向量数据库擅长的是海量知识的模糊检索，但它的结果不可控、不可解释。你搜一个关键词，它返回什么片段、不返回什么片段，你很难精确控制。而Agent需要的是一种更可控、更可读、更便于自我管理的记忆方式。

于是长期记忆细分为两个方向：

一个是事项型记忆（Episodic Memory），针对用户偏好、历史行为、待办事项等动态变化的”事实”，越来越多的框架倾向于用文件系统来记录。比如生成MEMORY.md或每日的Memory日志文件，以结构化的Markdown格式存储关键事件。这比向量检索更可控、更易读，也便于Agent直接读取和理解时间序列上的状态变化。

另一个是知识型记忆（Semantic Memory），随着LLM-Wiki、GBrain这类本地化知识库理念的普及，传统的纯RAG方案正在被更灵活的本地文件系统所补充甚至替代。Agent可以直接访问组织良好的Markdown知识库，通过目录结构、标签、链接来显式组织知识，使得知识的召回更加精准和可解释。当然，如果是企业级海量知识库的场景，纯文件系统还是不够的，需要搭配SQLite等轻量化检索甚至企业级向量检索，形成混合架构。

打个比方来理解这种变化：以前的方式就像你把所有资料都扔进一个大仓库，需要什么的时候靠模糊搜索去找，找到什么算什么。现在的方式是你在书架上按类别整理好，每本书贴好标签，需要什么直接去对应的书架上取。当然，有些特别大的仓库还是需要搜索引擎辅助的，但至少核心的组织方式变了——从”堆进去、搜出来”变成了”整理好、取出来”。

Tools：从”造接口”到”用原生”

Tools模块的变化，可能是整个Agent范式中最具颠覆性的一个。

早期的工具调用范式是Function Call：针对具体业务场景，把系统能力封装成标准API，注册为模型可调用的函数。后来出现的MCP虽然在协议层面优化了工具的注册与发现机制，但本质上还是”接口标准化”的思路——你需要什么能力，就得先造一个接口出来。

这有什么问题呢？问题在于现实中大量的系统或数据源并没有现成的API。为了弥补这个缺口，团队往往需要投入大量精力去”补全”API。而且随着工具数量膨胀，API Schema的管理变得极其复杂——每个函数的名称、描述、参数类型、返回格式都要精心维护，模型还要在巨大的函数列表中选择正确的那个，这本身就是一种负担。

而真正的范式转移发生在两个方向：CLI命令行原生化和Script脚本化。

CLI对人类来说是一种枯燥的交互方式，但对大模型来说却是”天然工具”。为什么？因为grep、cat、find、curl这些Linux/Unix命令及其参数，是大模型预训练数据中海量代码和技术文档的一部分，属于”先天知识”。让模型通过CLI操作文件系统或网络，无需额外定义复杂的API Schema，只需指令其使用标准命令即可。这就好比一个人不需要专门学怎么用筷子——他从小就用筷子吃饭，筷子对他来说就是最自然的工具。

更妙的是，即使面对模型没见过的第三方CLI工具，只要遵循标准的Unix规范（比如支持–help），模型就能在运行时通过查询帮助文档，自主理解参数用法并执行调用。这种”按需查询、即时学习”的模式，完美契合了前面提到的渐进式加载理念。

Script脚本化则是另一个重要方向。具体的工具逻辑被封装为独立的脚本文件（Python、Shell等），这些脚本既可以直接执行本地命令，也可以内部封装对远程API的调用。复杂的鉴权、参数拼接等细节被隐藏在脚本内部，Agent只需关注”调用哪个脚本”和”传入什么核心参数”。这也是为什么安装一个Skill往往就能赋予Agent处理复杂任务的能力——因为Skill不仅包含了Prompt指引，更内置了可执行的工具脚本。

从Function Call到CLI + Script，Tools演进的核心是从”人为适配模型”转向”利用模型原生能力”。我们不再试图为每一个操作编写专用的API接口，而是充分利用模型在预训练阶段积累的通用计算机操作知识和代码执行能力，构建更轻量、灵活且易于扩展的工具生态。

Workflow：从”刚性编排”到”动态混合”

Workflow的演变和前面几个模块是联动的。早期因为模型不够强，我们用硬编码的Workflow来保障执行——第一步做什么、第二步做什么，全部写死。这就像传统的工厂流水线，每个工位只做一件事，产品按固定路线走。

但Workflow太”死”了，外部环境变了它也不知道变通。随着模型能力增强和Skills体系的出现，Workflow的形态开始重构：从”刚性的流程编排”转向”动态的Skill封装”。

具体来说有两个方向的变化：一是逻辑内聚化，原本分散在Workflow引擎中的步骤定义、约束条件、判断逻辑，现在可以直接写入Skill的Markdown描述文件中，模型通过阅读Skills文档就能理解完整链路；二是执行脚本化，对于需要精确控制的环节，不再依赖外部工作流引擎的状态跳转，而是通过Skill关联的脚本进行代码级编排。

但这里有一个现实的博弈：纯Skill驱动赋予Agent更高的自主性，但在极端复杂或容错率极低的场景下，模型仍可能理解偏差或执行跳跃。而传统刚性Workflow虽然笨重，却提供了确定性的边界。

所以当前的最佳实践是混合架构：将成熟的、标准化的子任务封装为Skills，利用其灵活性；将关键的、对稳定性要求极高的主干流程保留为Workflow，或者将特定Workflow封装为一个特殊的Tool供Agent调用。”Skill为主，Workflow为辅/兜底”，既利用新技术红利，又保留确定性。

打个比方：这就像一个公司里，日常事务让员工自主决策（Skill），但财务审批、合同签署这些关键环节还是走固定流程（Workflow）。不是所有事情都需要流程，但关键事情不能没有流程。

Environment：从”无状态”到”有家可归”

最后一个容易被忽视但至关重要的模块：运行环境。

早期的Agent调用工具、调用子Agent都是无状态的，调完就完了，不需要什么”家”。但随着Agent能力增强，特别是引入了文件系统操作、代码执行等能力后，它不再只是一个”问答机器”，而是一个需要持久化存储、文件读写和状态管理的”数字员工”。这意味着Agent必须有一个专属的工作空间，能安全地读取配置、写入日志、生成中间文件，管理Skill和Memory数据。

根据场景和安全要求不同，运行环境主要有两种形态：

本地个人电脑——便利性极高，Agent可以直接操作用户本地的文件系统、应用和网络，实现”整理桌面文件”、”自动化办公”等贴近个人生活的复杂任务。但缺乏隔离机制，Agent的操作失误可能导致用户重要数据丢失或系统配置混乱，所以通常需要更严格的用户确认机制或权限控制。

沙箱环境——企业级生产环境的主流选择。通过Docker、Kubernetes等容器化技术构建隔离环境，Agent的所有操作被限制在特定的虚拟文件系统内。即使Agent执行了破坏性命令，也不会影响宿主机或其他服务。提供了必要的安全边界和资源管控。

打个比方：本地环境就像让员工在你家里办公，方便是方便，但他万一打翻了咖啡就是你的损失；沙箱环境就像给员工一个独立的办公室，他在里面怎么折腾都不影响你家的陈设。

回望来时路

走完这条路，回头看，你会发现一个有趣的现象：从宏观架构上看，今天的Agent依然由Prompt、Planning、Memory、Tools、Workflow、Environment这些经典模块组成，和Lilian Weng早期提出的理论框架并无二致。”形”未变，但”神”已大不同。

Prompt从单体的”小作文”演变为解耦的上下文工程；Planning从线性的CoT思维链升级为复杂的长程任务拆解；Memory从传统的前置向量检索转向文件系统化与向量检索的混合架构；Tools从高成本的API封装回归到原生的CLI与脚本交互；Workflow从刚性的外部编排内化为灵活的Skills封装；Environment从无状态的调用延伸为有状态的隔离运行时。

每一个模块背后的运行逻辑、数据流转方式以及工程实现范式，都发生了翻天覆地的变化。但贯穿始终的核心思想始终未变：通过工程化手段构建确定性，以承载模型的不确定性。

模型会继续升级，工具会继续变化，框架会持续更新。但这个核心思想——用工程的确定性去驾驭模型的不确定性——将是未来很长一段时间内构建高质量Agent的基石。理解了这条来时路背后的演化逻辑，你就能在纷繁复杂的技术浪潮中，找到最适合自己场景的那条路。