Agent自进化系列（一）--Agent 的下一阶段：从会做事，到真正学会成长

上周突然收到腾讯云社区寄来的礼盒，我才意识到，自己已经半年没在社区认真沉淀技术文章了。

不是没有想写的主题，而是每次刚产生一个想法，网上似乎已经出现了铺天盖地的同类文章。何况，现在AI 写得比我快太多：我需要整理好久的材料，它可能五分钟就能生成一篇结构完整的文章，再花十分钟校验，似乎就可以发布。

于是很多次，我打开文档，又默默关掉。

前段时间，看到新闻说 AI 公司大量收购、扫描 2022 前的实体书。因为 2022 年前的内容，才是真正由人类长期观察、思考和书写出来的内容，才是 AI 稀缺的训练数据。

这几天，《牛来》又以一种奇特的画风爆火，哈哈。在 AI 时代，“手搓”出来的动画，大家未必认可它的质量，却还是会被“真的有人花了五年把它做出来”这件事吸引。

Agent 越来越强，我们把更多事情交给了 AI。遇到一篇长文章，越来越看不下去，第一反应不是读完，而是让 AI 总结精华；想了解一个方向，也习惯先让 AI 整理直接给结论；甚至准备写文章时，也会自然地让 AI 先生成初稿。效率确实提高了，但自己的思考过程也在消失了。AI太快了，所以我们有时候也要给自己时间，慢慢来～

所以准备继续在社区沉淀文章，也算自己进行一些总结。（当然过程中还是有 AI 的参与，思路探讨文本润色和论文分析。）

本系列主要的技术方向就是：Agent 自进化。

引子：Agent 已经很强，为什么我们仍然不满足？

过去几年，AI 完成了两次重要跨越。

第一次是大模型。它让机器拥有了强大的知识、生成、推理、代码等能力。

第二次是 Agent。模型被放进一套完整的运行系统，获得了上下文、工具、执行环境和反馈循环，开始从“回答问题”走向“完成任务”。

今年 年初OpenClaw 等产品爆火，“养虾”“养马”一度成为技术圈的新热潮，好像不养一个 Agent，都不好意思说自己是干这行的。企业都开始尝试用 Agent 重构原有的软件和工作流，个人也开始让 Agent 编程、搜索、整理文档、生成报告，甚至长期替换人做某一类工作。

Cursor、Codex、WorkBuddy 等产品也是迅速迭代升级。它们可以理解目标、拆解任务、调用工具、修改文件、运行代码，并根据执行结果持续修正。

如果只观察一次任务，我认为今天的 Agent 已经相当强大。

但如果把观察时间从一次任务拉长到十次、一百次，新的问题就出现了：

Agent 可以重复工作，但它会因为这些工作经历而持续成长吗？

今天的 Agent 可以日复一日地处理任务，却不一定会因为昨天的失败，自动改变明天的自己。

这可能是 Agent 从自动化工具走向长期智能体时，必须解决的问题。

一、会做事：Harness 让模型成为 Agent

1. 从“拥有能力”到“完成任务”

底座大模型本质上是一个根据输入上下文生成输出的模型。

它可以回答问题、生成内容、编写代码和进行推理，但它只能看到被提供的上下文。模型本身不会主动读取项目文件，不知道终端刚刚发生了什么，也不会自动保存跨任务状态，更不能直接把一个决定变成对环境的操作。

因此，大模型能力很强，并不意味着它天然就是一个能够工作的 Agent。

从认知功能看，Agent 通常由感知、记忆、决策和行动构成：

Agent = 感知 + 记忆 + 决策 + 行动

而从当前Agent 的工程实现看， 可以广义上认为：

Agent = Model + Harness

这两种表达并不矛盾。

目前很火的一些概念，更多的都是从后者来描述这些功能在大模型时代如何被工程化实现。

2. Harness 到底是什么？

Harness 概念可以说漫天飞了，它是围绕模型构建的一整套Agent运行系统。负责组装上下文、驱动 Agent Loop、选择和执行工具、维护任务状态、控制权限，并把环境反馈重新送回模型。

如果把底座模型理解为一个人的“大脑”，Harness 就更接近围绕这个人建立的工作环境、操作流程、工具体系和管理制度。

Agent = Model + Harness

同一个模型放在普通聊天框中，可能只能给出一段代码；放进 Coding Agent 的 Harness 中，则可以：

1. 阅读代码仓库
2. 理解项目结构和流程
3. 制定修改计划
4. 编辑多个文件
5. 执行测试和编译
6. 读取错误日志
7. 根据报错继续修改
8. 检查任务是否真正完成

这些是它把一次任务做完的路径。同一套 Harness 往往还管很多事情：权限和审批（哪些文件能改、哪条命令需要人点头授权）、沙箱（代码跑在隔离环境里）、会话恢复、以及测试是否算真正完成。没有后面这些，前面那些动作要么落不了地，要么有安全问题。

把上面那些步骤串起来，其实就是一轮又一轮的：

Cursor、Codex 这类产品，日常就是在转这个环。Codex 官方也把它写成：Harness 组织输入，调用模型，根据输出执行工具，再把结果放回上下文，直到任务完成。（Unrolling the Codex agent loop）

模型并没有在每一步重新训练，但在 Harness 的组织下，它已经从一次性的内容生成器，变成了一个可以持续观察、行动和修正的 Agent。

这是 Agent 发展的第一次重要跨越：

底座模型解决“会不会做”的问题，Harness 解决“能不能把事情真正做完”的问题。

二、能工作：从完成一次任务，到长期承担任务

1. 重复工作，不等于从工作中成长

有了 Harness，Agent 不仅可以完成一次任务，还可以反复执行相似工作。

代码 Agent 可以每天读取 Issue、修复 Bug、运行测试；办公 Agent 可以定期收集资料、整理表格、生成报告；个人 Agent 可以监听消息、处理文件、调用外部服务，并在特定时间或者事件发生时自动启动。

从这个角度看，Agent 已经开始像一个数字员工：

• 能使用工具
• 有固定流程
• 能处理环境反馈
• 可以长时间执行复杂任务
• 也可以日复一日地处理同一类工作

但重复上班，和从上班里成长，不是一回事。

假设一个 Agent 每天都要生成一份业务分析报告。

第一天，它把日期格式处理错了。读到报错后，它在这次运行里改对了输出，报告交出去了。

第二天换了一份新数据，它又从零写一遍处理逻辑。如果没有人或者系统把「这类数据要先统一日期格式」写进以后还会读到的规则、校验或标准流程，它很可能再犯同样的错。

这一次怎样把事情做完？

这是任务内适应。当前的 Cursor、Codex、WorkBuddy 已经越来越擅长。

这次经历应该给未来的自己留下什么？

这是跨任务学习，也是长期成长真正开始的地方。

2. 今天的 Agent 并不是“完全失忆”

把今天的 Agent 说成“每天上班都会完全失忆”，并不准确。

失忆的是默认任务循环，不是系统里没有存储器。

今天已经有很多模型外机制可以保留信息和经验：

• 使用 Memory 保存用户偏好、历史事实和任务经验
• 使用 AGENTS.md 保存项目规范
• 使用 Rules 约束未来任务中的行为
• 使用 Skills 封装可复用的操作流程
• 使用 Workflow 固化稳定的任务步骤
• 使用代码和文件保存执行结果
• 使用知识库积累领域信息
• 使用测试用例保存对“正确结果”的定义
• 使用 Trace 和日志记录历史执行过程

以 Codex 为例，OpenAI 官方将这些机制做了明确区分：AGENTS.md 用于持久的项目指导，Memories 用于延续上下文，Skills 用于封装可复用流程，MCP 用于连接外部系统。

国内的 WorkBuddy（腾讯云 CodeBuddy）也是同一套抽屉，只是文件名换成了自己的：CODEBUDDY.md 当项目级记忆（没有它时兼容 AGENTS.md），Rules 管持续生效的规范，Skills 按需加载可复用流程，MCP 接外部系统。

学术界也沿着不同方向探索经验保留。

Reflexion 根据任务反馈生成自然语言反思，并把反思保存在情景记忆中，帮助 Agent 在后续尝试中避免重复错误。

Voyager 把在环境中成功执行过的行为封装为代码技能，保存到持续增长的 Skill Library 中，并在后续任务中检索和组合。

MemGPT 借鉴操作系统的分层存储机制，管理上下文内外的不同信息，为长期记忆提供了一套基础架构。关于记忆框架有时间可以再单开一篇详细介绍。

这些工作说明，今天的 Agent 已经不是完全静态的系统。信息、规则、代码和技能，都有地方可以保存。

3. 有经验抽屉，不等于会管理经验

但“有地方可以保存”和“知道应该保存什么”，仍然是两件不同的事，而且难度相差很大的两件事。

产品已经为 Agent 准备了很多“抽屉”：Memory、Rules、AGENTS.md、Skills、Workflow、知识库和测试用例。

真正困难的是：

• 这次经历值不值得保留？
• 它是事实、偏好、教训，还是可复用流程？
• 应该写入 Memory，还是项目规则？
• 应该形成一条 Rule，还是封装为一个 Skill？
• 它只适用于当前任务、当前项目，还是更广泛的场景？
• 新经验与旧规则冲突时，应该相信哪一个？
• 写进去以后，会不会影响其他任务？
• 领域规则太多，抽屉不可能无限扩展，是用检索方式还是需要训模型？

OpenAI 官方建议，当 Codex 反复犯同一种错误时，可以纠正它，并让它把相应规则更新到 AGENTS.md，使修正能够延续到未来任务。

这里最值得注意的是“可以让它”，而不是“它会自主决定”。

默认路径仍然是：人先发现 Agent 重复犯错，再要求它复盘，最后告诉它把结论写进某个位置。Agent 可以执行“把这条经验写进规则”，但还没有稳定掌握“这条经验是否值得写、应该写到哪里、写完会不会产生副作用”。

因此，对于目前主流框架（我只说了目前，确实被AI的快速发展打脸很多次了）：

Agent 已经能保存经验，但通常还不能自主、可靠地管理经验。能存，不等于会成长。

三、会成长：Agent 需要掌握如何更新自己

1. 从经验保存到经验选择

假设一个代码 Agent 在执行任务时遇到了测试失败。

它把错误完整记录下来，并生成了一条反思：

修改数据库字段后，需要同步更新序列化逻辑和相关测试。

这条经验看起来很有价值，但真正的学习才刚刚开始。接下来还有一系列更困难的问题：

• 这次失败是偶然失误，还是可以复用的规律？
• Agent 对失败原因的归因是否正确？
• 这条经验适用于当前代码库，还是所有项目？
• 应该保存为一条 Memory，还是写入项目规则？
• 是否应该封装成一个代码检查 Skill？
• 是否应该直接修改标准工作流？
• 当它与已有规则冲突时，应该保留哪一条？
• 加入这条规则后，会不会让其他任务表现变差？
• 怎么证明未来的 Agent 真的因为这次修改变得更好？

如果这些判断仍然全部由人完成，那么它更接近：

人在环的 Agent 改进。

我们项目中正常的流程是：

1. 用户发现 Agent 重复犯错
2. 用户指出问题
3. Agent 根据要求通过它记录的trace进行复盘
4. 用户决定更新规则、Memory 或 Skill
5. Agent 执行具体更新
6. 新规则在后续任务中继续生效

在这个过程中，Agent 负责执行更新，但人类仍然承担着最关键的学习职责。

因此，当前 Agent 面临的核心问题已经不只是“有没有记忆”，而是：

Agent 能否自主判断什么经验值得留下，并把它转化为正确、稳定、可复用的能力更新？

2. 乱积累经验，也可能让 Agent 变得更差

经验不是越多越好。现在大家用agent为了沉淀经验/skill，通常会尽可能多的保存轨迹，最后得到的可能只是一个越来越大的日志库；如果每次失败都生成一条反思，规则之间可能相互冲突；如果不断把教训追加进 Prompt，Prompt 会越来越长；如果 Agent 可以随意修改 Workflow 或 Harness，还可能造成行为漂移，甚至破坏原来稳定的能力。

因此，真正的自进化不能只有“写入”，还必须包含评价、验证和回滚。

一个完整的成长闭环至少应该包括：

这与普通 Memory Loop 有本质区别：

记忆循环不等于自进化循环

Memory 让 Agent 拥有过去；自进化要让 Agent 利用过去改变未来。

四、什么才叫 Agent 自进化？

会反思、有 Memory、能写 Skill、能修改代码，都只是局部能力，并不自动等于自进化。

我认为，一个相对完整的定义是：

Agent 在与用户和环境的持续交互中，自主获取并评价经验，完成成败归因，判断应该修改自身的哪一部分，执行可持久化的更新，并通过后续任务验证更新是否有效，从而决定保留、修正或者回滚这次变化。

自进化的最低判据：留存、复用、验证

如果要给自进化一个最基础、可以落到工程上检查的判据，我认为可以概括为一句话：

自进化，就是把反馈转化为留存的、可复用的、可验证的改进。

这至少包含三个必要条件：

1. 有留存：任务结束后，经验必须以某种形式形成持久变化。它可以被写入 Memory、Rules、Skills、Workflow 或代码，也可以最终进入模型权重。
2. 可复用：留下的经验必须能够在后续任务中被检索、加载或者直接生效，而不只是躺在日志里。
3. 可验证：系统必须能够利用测试、环境反馈、用户评价或者长期指标，判断这次更新究竟带来了改进，还是产生了新的问题。

反过来，只要缺少其中任何一项，就还不能称为自进化：

1. 无留存：只在当前上下文中完成修正，任务结束后没有任何东西被写下来。
2. 无复用：保存了轨迹或者日志，但后续任务不会读取、检索和使用它，经验没有真正进入未来的决策过程。
3. 无验证：经验虽然被再次使用，却没有任何机制判断它是正确经验、偶然相关，还是一次错误归因。

不过，一个系统即使做到了这三点，如果仍然完全依赖人类判断应该学习什么、修改哪里，以及是否保留更新，它更接近“人在环的持续改进”。真正的自进化还要求 Agent 在经验评价、成败归因、更新对象选择和结果验证等环节，具备一定程度的自主性。

换句话说：

留存解决“有没有留下”，复用解决“以后会不会使用”，验证解决“使用后是否真的变好”，自主更新才解决“Agent 是否掌握了如何成长”。

自进化最低判据：留存、复用、验证、自主更新

结语：会工作之后，Agent 还需要学会成长

回顾 Agent 的发展，可以看到一条清晰的演进路线。

底座大模型提供知识和推理能力，解决“这件事会不会做”；Harness 为模型增加上下文、工具、执行和反馈循环，解决“能不能把事情真正做完”；Memory、Rules、Skills 和 Workflow 让部分经验可以跨任务保留，开始回答“做完以后能不能留下什么”。

但真正的成长还要继续向前一步。

Agent 必须能够从任务反馈中判断什么值得学习，完成正确归因，选择应该修改的部分，并通过未来任务验证更新究竟带来了提升，还是制造了新的问题。

从会做事到会成长：大模型、Harness、经验留存、自进化

因此，自进化不是给现有 Agent 增加一个 Memory 模块，也不只是让模型在任务结束后生成一段反思。

自进化的最低起点，是把反馈转化为留存的、可复用的、可验证的改进；而真正的自主成长，还要求 Agent 逐渐掌握如何评价经验、选择更新并决定保留还是回滚。

今天的 Agent 已经会做事，也开始能够留下经验。下一阶段真正重要的问题，是让它不只是拥有过去，而是能够利用过去，主动塑造未来的自己。

可是「会成长」太容易被用滥。会反思、会写 Memory、会改 Workflow，看起来都像在进化。下一篇先把什么才叫自进化 Agent 说清楚：任何一个自称会进化的系统，都得答得上改了什么、何时改、怎么改、由谁改，这种改变发生在什么环境里以及如何验证修改让Agent变得更好。