标签归档:LLM

自进化 Agent 实现的 4 个层面

如果 AI 能像人一样,随着时间,经验,反馈不断学习,会发生什么?

我们现在常用的 Agent,不管是豆包,还是编程用的 Cursor,本质是还是一次性对话工程,你问一句,它答一句,或者执行完一堆任务,任务结束后不会成长。

如果能成长呢?这将会是不一样的世界。

这也是今年硅谷比较热门的方向。

为什么是这个方向:

  1. 人性,人天生懒惰,公司逐利
  2. 成本,自动化的 Agent 比 Chat AI 消耗的成本高出数个数量级,而自己进化的 Agent 所消耗的 token 又比一般的自动化的 agent 要高出多个数量级
  3. 上下文更长、模型更大、工具更多,这些路线都还有效,但边际收益已经没有前几年那么夸张。当其它维度进入瓶颈的时候,时间永远是可以考虑的重要维度

自我进化不是「长期记忆」,而是 Agent 依据自身交互情况、任务反馈或环境信号,对上下文、记忆、技能、工作流甚至模型参数进行持续更新。这些更新会直接干预未来的任务执行。

通过不断调整大模型和 harness 的边界,在静态世界里不断进化,模型能够能够越来越熟悉环境工具记忆等

任何演进路径都必须压在评估、版本、回滚、权限与供应链治理的基础之上。

自我进化用一句来讲,大概是这样:

真实任务里的经验,怎么变成下一次任务可复用、可验证、可治理的能力。

拆解一下,可以分为四层或者说四种可实现路径:

  1. 上下文进化:将执行经验、用户偏好或环境约束写回本地记忆文件、会话索引或技能目录,在下一次任务触发时通过检索提取并拼接入上下文。
  2. 技能进化:把经验外化成结构化的 SKILL.md、技能包或工作流脚本。系统依据执行报错或反馈信号,自动修改技能代码,在测试集中跑通后覆盖老版本,失败则触发版本回滚。
  3. 群体智能进化:多个 Agent、多台机器、多个用户的本地经验接入云端共享层。系统在服务端完成轨迹去重、冲突合并、安全脱敏与质量验证,最后将提纯后的技能或记忆分发回所有终端。
  4. 策略进化:将真实的交互轨迹与成败反馈收集起来,直接修改 Agent 的核心调度代码、工作流拓扑,甚至转化为强化学习(RL)的标量奖励来更新大模型的底层参数。

从工程落地的角度来说,上下文闭环和技能闭环是不错的起始点,也是能快速落地,快速带来结果的点。

这两层改动的基本都是文本资产,容易审计,且故障可控,回滚成本低。如果实现群体闭环或策略闭环,就会多出很多数据脱敏,权限控制等等问题。

上下文进化

上下文进化是指让 Agent 在自己的主循环里,将执行经验、用户偏好或环境约束写进以后还能用到的上下文资产。

典型的上下文资产包括:

  • 跨会话记忆
  • 会话检索
  • 用户画像
  • 项目级上下文
  • 技能目录的动态装载
  • 失败后的反思记录

优点:轻、快、容易落地。

缺点:如果底层模型本身不够强,光靠上下文很难突破上限;如果没有治理,错误经验会稳定污染后续行为。

以 Hermes Agent 为例,它将持久记忆(MEMORY.md / USER.md)、跨会话检索(SQLite + FTS5)和技能创建塞进同一个对话主循环。

工程实现上,Hermes 走的是一条贴紧主循环的轻量闭环。用户下发任务,Agent 经由消息网关调用终端工具。执行反馈与用户纠正产生分叉,一部分写入策展记忆,一部分沉淀为 Skills。当新任务到来,系统通过 session_search 将历史记忆与技能一并汇入下一轮上下文。

上下文进化解决的问题是Agent 的「金鱼记忆」与重复试错成本。在早期开发中,大模型每次新建会话都会丢失之前的上下文。昨天刚通过多轮对话教会它如何绕过内网的 SSL 证书校验,今天遇到同样的报错,它依然会从零开始盲目重试。上下文进化通过持久化存储(如 SQLite 配合 FTS5 全文检索),让 Agent 在行动前先查阅历史成功路径,直接跳过无效的探索阶段。

适用于单兵作战的个人助手、轻量级代码副驾、日常办公辅助。只要底层大模型的推理能力在线,且任务经验不需要跨团队、跨设备共享,这是投入产出比最高的一层。它不需要复杂的评测沙箱,几百行代码就能让单体 Agent 的可用性产生质变。

技能进化

上下文闭环再往前一步,就是把经验沉淀成可复用技能。

当经验开始重复出现,必须将其从松散的记忆层提升到结构化的技能层。把经验外化成结构化的 SKILL.md、技能包或工作流脚本。系统依据执行报错或反馈信号,自动修改技能代码,在测试集中跑通后覆盖老版本,失败则触发版本回滚。

在 Agent Skills 生态里,SKILL.md 充当了 Agent 的程序性记忆,定义了触发时机、执行脚本、环境约束和异常处理逻辑。

SKILL.md 这一类开放技能格式,是这波 Agent 工程里比较实用的中间层,它有如下的特点:

  • 比记忆更结构化
  • 比代码改动更轻
  • 比参数训练更便宜
  • 可迁移、可 diff、可版本化、可回滚

所以当我们发现某类经验开始重复出现,就不应该继续把它留在记忆层,而应该上升成技能资产。

Darwin Skill 把 SKILL.md 当作可评测、可回滚的资产。

Hermes Agent 的技能系统不是静态文档库,它允许 agent 自己创建、编辑、补丁、删文件、写附属文件。核心工具是 skill_manage。[skill_manager_tool.py]

Hermes Agent 的技能进化,并不完全依赖用户主动说「把这个存成技能」。

它有两层自动复盘机制。

第一层是 nudge。memory 按用户回合数触发,skills 按工具迭代次数触发。达到阈值以后,系统会在主任务完成后,后台 fork 一个 review agent,让它复查当前会话,看有没有东西值得落 memory 或 patch/create skill。[run_agent.py] run_agent.py#L2448-L2547 [run_agent.py] run_agent.py#L11586-L11612

第二层是 guidance。系统提示里直接写明:

  • 复杂任务、踩坑任务、发现可复用流程,要考虑存技能
  • 技能用着发现过时或不完整,要立刻 patch

它已经把「技能进化」从人工运营动作,拉进了 agent 自己的工作流。系统不再等人整理文档,而是把复盘变成运行时行为。

但这种触发还是偏软。nudge 只是提醒,review agent 还是模型自己判断。只靠提示词和后台复盘,技能库后面大概率会出现三类问题:

  • 有价值流程没被沉淀
  • 沉淀下来的技能版本缺少来源和上下文
  • 技能被 patch 多次以后,质量开始飘

技能进化解决的问题是纯文本记忆的非结构化缺陷。当任务复杂度上升,大模型在处理几万字的自然语言排错记录时极易丢失细节,甚至产生幻觉。复杂的业务需要确定的执行路径。人工维护这些包含几十个步骤的 SOP(标准作业程序)脚本成本极高,且极易因外部 API 的微小变动而全盘失效。技能进化将脆弱的静态脚本转化为能够依据报错信息自我修复的动态资产。

其适用于垂直领域的自动化流水线、运维巡检、复杂数据清洗。当业务要求 Agent 严格遵循既定流程操作,且操作环境(如第三方接口、依赖库版本)会频繁发生变化时,技能进化是维持系统长期稳定运行的唯一解。

群体智能进化

当你有多个 Agent、多台机器、多个用户时,单机技能闭环就不够了。

因为最大浪费会变成另一件事:
同一个坑被不同实例反复踩。

这时候我们就需要一个共享层,把个人经验抽出来,变成全体可复用资产。

这就是群体闭环要解决的问题。

它的收益大,但治理也复杂。因为共享意味着:

  • 权限问题
  • 隐私问题
  • 脱敏问题
  • 质量门控问题

等等

Ultron 将散落在各次会话里的经验蒸馏成群体知识,提供 Memory Hub、Skill Hub 和 Harness Hub。

Memory Hub 实现了 HOT / WARM / COLD 分层存储。系统根据命中次数进行再平衡,引入时间指数热度衰减公式 hotness = exp(-α × days)。未经衰减处理的记忆库是一场灾难,Agent 会频繁召回半年前已经废弃的内部 API 规范。

数据入库前,系统通过 Presidio 进行中英 PII(个人身份信息)检测与脱敏。这是企业级落地的底线。一旦某个 Agent 将包含真实客户手机号的排错日志写入群体记忆,整个系统的合规风险将彻底失控。

Skill Hub 负责将进入 HOT 层的记忆结晶为多步工作流技能。Harness Hub 则将人设、记忆、技能打包为蓝图,支持一键导入。这种设计抹平了多实例部署的知识水位差。

其主要解决的问题是规模化部署下的经验孤岛。如果团队里有 50 个开发人员,每个人的 Agent 都在本地独立摸索公司内部 CI/CD 系统的某一个奇葩报错,相当于团队为同一个坑支付了 50 遍大模型的 API 账单。群体智能进化打破了实例之间的物理隔离,让一个 Agent 踩过的坑成为全团队的免疫抗体,抹平多实例部署的知识水位差。

其适用场景于企业级 Agent 矩阵、跨部门研发协同、大型内部工具链。团队规模越大,这层进化的网络效应越明显。前提是必须在共享层前置严苛的 PII(个人身份信息)脱敏与恶意 Prompt 注入拦截机制,防止单一终端的脏数据污染全局技能库。

策略进化

再往下走,就是最重的一层:让系统直接改策略本身。

这里的策略可能是:

  • 代码
  • 工作流拓扑
  • 模型参数
  • 策略网络
  • 推理路径分配

这层能力上限很高,也很危险。因为一旦我们把真实用户反馈接进训练或策略更新链路,很多以前可以拖着不管的问题会立刻变成硬约束:

  • 数据许可
  • 脱敏
  • 训练延迟
  • 奖励劫持
  • 评测作弊
  • 安全回滚
  • 服务与训练解耦

将真实的交互轨迹与成败反馈收集起来,直接修改 Agent 的核心调度代码、工作流拓扑,甚至转化为强化学习(RL)的标量奖励来更新大模型的底层参数。

其主要解决的问题是基座模型能力天花板的绝对限制。无论是追加记忆还是改写技能,本质上都在做外挂。当遇到模型根本无法理解的深层逻辑或极度复杂的推理链条时,外挂方案会全线崩溃。策略进化直接向底层动刀,利用在线交互产生的真实反馈信号(如代码是否编译通过、测试用例是否全绿)来微调模型权重或重构 Agent 的执行逻辑。

主要适用场景是拥有充足算力预算的 AI 基础设施团队、需要将开源模型逼出闭源模型效果的核心业务。这一层工程风险极大。任务必须具备极度清晰、可自动化判别的反馈信号(如数学定理证明、代码生成)。如果反馈信号存在噪声,模型会迅速在错误的梯度中崩溃,产生严重的奖励作弊(Reward Hacking)现象。

核心工程挑战

上面讲了四层进化,但是要落地自进化系统,必须跨越四道工程天堑。

评估器比生成器更重要。没有评估器的自动修改,只是在自动制造生产事故。Darwin Skill 的棘轮、Ultron 的升级门控、OpenClaw-RL 的 PRM,都在解决同一个问题:证明改动没有让系统变坏。评估器的算力消耗通常是生成器的三倍以上。

可回滚是自进化的基础设施。技能层的优势在于天然支持版本化。参数层的更新回滚成本极高。工程实践的逻辑是:能在记忆层解决的异常,绝不改写技能;能在技能层修补的逻辑,绝不修改代码;能在代码层绕过的缺陷,绝不在线更新权重。

共享经验需要严苛治理。群体智能闭环的引入,意味着污染风险的全局放大。一个包含 rm -rf / 的错误技能一旦进入共享库,会摧毁整个团队的开发环境。权限分层、PII 脱敏、候选验证和版本审计,是系统上线的强制前置条件。

技能供应链安全无法事后补救。Agent Skills 已经演变为跨生态的能力封装格式。它包含脚本、远程依赖和执行指令。技能市场必须审查其是否读取敏感路径、是否执行危险命令、是否下载未知来源的 Shell 脚本。沙箱隔离和系统调用拦截必须做在宿主的最底层。

当前可落地执行的路线,不要一步到位堆砌在线 RL。可分阶段实施:

第一阶段,夯实上下文治理。让 Agent 具备最基本的成长能力:记录偏好、总结失败、检索历史。重点是让项目上下文和工具状态形成稳定机制,控制上下文窗口的 Token 消耗。

第二阶段,跑通技能资产沉淀。当排错经验重复出现,将其提取为 SKILL.md。引入类似 Darwin Skill 的测试集与评估机制。这是当前投入产出比最高的一步,能够立竿见影地降低 API 调用成本。

第三阶段,建设跨端群体智能。部署共享存储与演化服务,实现多终端经验的去重、验证与分发。在这个阶段,投入 50% 的研发精力解决隐私脱敏与权限审计问题。

第四阶段,谨慎切入参数与工作流修改。只有当你的 PRM 准确率达到生产可用级别,沙箱隔离足够坚固,版本回滚延迟降到秒级时,才去触碰在线强化学习。

自进化 Agent 的核心壁垒,从来不是模型本身有多聪明,而是底层的评估、沙箱、治理和安全机制有多扎实。

以上。

Cursor AI 编程让我的编码效率提升了 10 倍

从 2022 年 6 月底正式上线的 GitHub Copilot 开始,AI 编程逐步开始进入工作的环境中,开始成为一个真正的 Copilot。据当时微软的评测报告以及当时公司内部使用的问卷反馈调查显示提升效率大概在 10% ~ 30%。

这一数据在当时已经令人惊叹,但随着大语言模型的飞速发展,以及 Cursor、Windsurf 等新一代 AI 编程工具以更直接的 IDE 方式的加入,效率提升的天花板被彻底打破。

从个人体感来说,部分场景有超过 10 倍的提升,特别是通用类功能实现,如爬虫、CRUD 功能、脚本类处理等。但并不等于以前一个项目要 10 个人,现在只需要 1 个人了,毕竟编码在整个项目过程中只占用的时间资源的一部分。

而且,这里的提升并不是说给 AI 说一句话:「给我完成 XXX 功能」,就能直接提效 10 倍 ,当前阶段,我们还需要有一些使用技巧才能较好的使用 AI 编程,让 AI 编程成为一个实实在在的助手。以下为过程中的一些注意事项和一些可能遇到的问题。

1. 使用 AI 编程的注意事项

1.1 不要求一次性完成所有的工作

AI 编程工具暂时并不擅长处理复杂且模糊的任务,而是更适合解决清晰、具体的小问题。因此,任务分解是高效使用 AI 编程的第一步。

如何实现?

  • 需求分解:将大任务拆解为小模块,可以人工分解,也可以让 AI 协助分解。例如:

    • 开发一个后端服务时,可以分解为:数据库表设计、路由框架搭建、业务逻辑实现、测试用例编写。
  • 框架优先:先让 AI 生成代码框架,例如接口的骨架代码、类和方法的定义,然后再逐步实现具体功能。

以一个简单的任务管理系统为例,你直接告诉 Cursor 「帮我实现任务管理功能」,他会提示你给出更多的输入,比如所要使用的技术栈等等,如果我们输入:请用 python 语言作为后端,vue 作为前端帮我实现任务管理功能。他会给出完整的看起来可以使用的架子,实际不太能用。

如果是在一个已有项目的基础上增加模块,以 CRUD 管理任务来说,较好的做法是:

  1. 分解需求

    • 第一步:设计任务表(表结构设计),也是明确核心需求的过程;
    • 第二步:实现核心的接口和界面;
    • 第三步:添加权限管理,一般是有权限体系,可以给参考或者表结构之类的实现;
  2. 逐步实现

    • 先让 AI 生成数据库表的定义,明确需求及约束;
    • 再生成 API 的路由框架。
    • 最后逐一实现各个功能模块。
    • 在各功能模块上再扩展其它的需求,如在任务添加的时候要调起弹性接口去完成任务等。

1.2 明确和细化需求

明确和细化需求和第一点有一些不同,这里所要表达的是我们在需求描述时要尽可能的明确和细致,以及需要有我们的转化和理解。

当前阶段,我们用 AI 编程并不是把产品需求扔给 AI,而是我们思考过整个实现的过程,有自己的认知后让 AI 来做会更好,当然,这个思考的过程也可以让 AI 来辅助。

  • 明确需求的层级

    假设你需要实现一个用户登录功能,可以先从高层次的需求入手「实现用户登录功能」,然后逐步细化为:

    • 数据库中需要存储哪些信息?
    • 前端需要提供哪些输入?有没有什么安全输入策略?
    • 后端服务的接口设计是什么样的?格式是怎样的?返回码规范是怎样的?
    • 需要哪些验证逻辑?使用 JWT 还是 Auth2.0?有哪些安全策略?
  • 细化到函数级别

    在某些情况下,有必要直接将需求分解到函数的输入输出、核心逻辑或算法。比如:

    • 函数应该接受哪些参数?
    • 输出的结果应该是什么样的?是什么类型的数据结构?
    • 核心逻辑是否需要特殊的算法优化?

以上这个细化的过程也是个 AI 交互的过程,从大到小,从整体到部分,逐步完成整个需求

在使用 AI 编程的过程中,确定需求并细化需求是最难,也是整个过程中最复杂的环节,因为它是对现实世界的建模。

把产品需求没有歧义的描述出来,这个过程远没有很多人想象中那么简单。期待 AI 进一步进化后能优化这部分理解的工作。

1.3 善用 AI 的上下文记忆

AI 编程的生成效果在很大程度上依赖于上下文信息

Cursor 支持上下文记忆功能,可以根据当前项目的代码结构或对话历史生成更精准的结果。并且对于已有代码的项目,提供示例代码给 Cursor 参考,可以帮助它更好地理解项目的整体风格、编码规范以及约定。

  • 参考已有代码

    比如,我们可以将公司内部的编码规约或项目约定通过已有代码的形式提供给 AI,这样生成的代码更符合项目需求,减少后续调整的工作量

  • 让 AI 理解当前代码环境

    在和 Cursor 对话时,可以特别的指出关键代码片段(如数据模型、核心函数),这种方式是为了规避 LLM 的上下文记忆的限制问题,突出当前要解决的问题和场景。

  • 补充上下文

    如果项目中有复杂的业务逻辑或特定的技术约定,可以通过注释、文档或已有代码的形式向 AI 提供相关背景信息。这样,AI 生成的代码不仅能够「跑通」,还更贴近实际需求。如使用 Cursor 的 @ 符号,除了本地的代码、文档、还可以有多模态的图片、外部链接的文档,Web 网页等等。

2. AI 编程使用中的问题及解决方案

在使用 AI 编程工具(如 Cursor、Windsurf 等)时,尽管其效率提升显著,但也有一些问题亟待解决。

2.1 额度不够了

以 Cursor 为例,即使在不大量使用的情况下,Pro 版本(如 GPT-4、GPT-4o、Claude 3.5 Sonnet 的高速请求)两周内就可能用完额度。高级模型的调用成本较高,尤其是当需要生成大量代码或反复调试时,消耗会非常快。

解决方案:

  1. 分工明确,优化工具使用场景

    • 代码相关任务交给 Cursor:专注于代码生成、函数实现等任务,减少对 Cursor 的非核心调用。
    • 知识性问题交给 ChatGPT或其它大语言模型:对于纯知识性或逻辑性的问题,使用 ChatGPT 或其他不限量的模型(如 GPT-3.5 免费版本)来查询。
  2. 分层实现代码

    • 先写框架:在开发项目时,先用 Cursor 生成代码框架,明确主流程。
    • 逐步细化:将需求明确的函数(尤其是复杂的小块代码)交由 Cursor 实现,而非一次性生成庞大的代码段。
  3. 结合其他无限制的大模型

    • 对于通用型函数(如工具类代码、简单的逻辑实现),可以利用免费的语言模型完成。
    • 配合使用多个编辑器(如 Windsurf 、Cursor、豆包),减少单一工具的使用频率。
  4. 节约上下文消耗

    • 避免在上下文中反复输入无关信息,尽量精简对话内容。
    • 善用工具内的上下文管理功能,如 Cursor 提供的 Add context@ 引用功能,将关键信息外部化,减少重复输入。

当然,对于不差钱的小主来说,可以忽略此问题。

2.2 上下文限制:会「失忆」

当前的 LLM 上下文窗口有限,当输入信息超出限制时,模型可能会「遗忘」之前的内容。这种「失忆」表现尤其明显,例如在多次会话后,最前面的一些关键信息可能会被遗忘,导致生成的代码出现不一致的问题。

解决方案

  1. 简要总结关键信息

    • 当模型开始「失忆」时,可以总结项目的关键信息并重新输入。例如, 核心配置或表结构可以作为关键信息,在对话开始时就输入给 LLM,确保其随时可用。
  2. 外部化核心信息

    • 将一些不变的核心信息(如数据库表结构、配置文件、接口定义等)存储到单独的文件中。
    • 在对话中通过 @Add context,将这些文件动态添加到上下文中,避免重复输入。
  3. 引用外部文档

    • 将外部帮助文档、链接或者参考资源作为上下文的一部分添加到对话中。例如,直接粘贴代码库的 README 文件、API 文档链接等,可以帮助模型更好地理解当前任务。
    • Cursor 自身支持这些外部的引用,具体方法参见 Cursor 的帮助文档,探索上下文扩展功能。
  4. 优化上下文使用策略

    • 尽量减少对话中的无关内容(如闲聊或冗长描述)。
    • 定期总结对话内容并清理上下文,确保关键信息占用优先位置。

2.3 修改代码混乱:会改乱代码

AI 工具在生成代码时,可能覆盖或修改原有代码,导致逻辑混乱,甚至出现功能性错误,一不小心原来能跑通的功能就不通了。这种情况常发生在对已有代码进行修改时,尤其是在多次修改的情况下。

解决方案

  1. 结合版本控制工具

    • 在完成每一阶段的明确功能后,及时使用 Git 提交代码,确保已有的工作成果被保存。
    • 在尝试新的修改时,可以创建分支或临时提交,确保不影响主分支的代码完整性。
  2. 分步引导 AI

    • 避免一次性让 AI 修改大量代码,而是按功能模块逐步进行修改。例如,先让 AI 修改某个函数,再验证其效果,而不是直接让它大规模重构代码。
  3. 生成新代码替代旧代码

    • 在涉及复杂逻辑的修改时,建议让 AI 生成新的代码片段,而不是直接修改现有代码。我们可以手动选择将新代码合并到项目中,避免出现覆盖错误。
  4. 代码审查

    • 对 AI 生成或修改的代码进行人工审阅,尤其是涉及关键逻辑的部分,确保生成代码符合预期。

2.4 无法解决复杂问题:可能进入死循环

在调试复杂问题或某个难点时,AI 工具可能陷入死循环,反复尝试生成代码但无法有效解决问题。例如,AI 对某个 bug 的修复建议多次尝试后仍然无效,甚至可能导致代码更加混乱。

解决方案

  1. 重新整理问题

    • 如果问题复杂而模糊,先关闭当前对话,重新开启一个新的会话。
    • 将问题简化为多个子问题,并逐步整理关键信息后输入给 AI。例如,将错误日志、上下文代码片段和预期行为整理成清晰的描述。
  2. 结合搜索引擎

    • 对难以解决的问题,可以将错误信息、bug 的关键描述扔给搜索引擎,结合开发者社区(如 Stack Overflow)寻找答案。
    • 搜索的过程中可以收集更具体的上下文,再反馈给 AI,增加其解决问题的可能性。
  3. 寻求多工具协作

    • 如果单个 AI 工具陷入死循环,可以尝试切换到其他工具或模型。例如,Cursor 无法解决的问题,可以切换到 ChatGPT 或 Claude 进行尝试。
    • 结合传统的调试手段(如 IDE 的调试功能、日志分析工具等),帮助定位问题。
  4. 分阶段测试

    • 将复杂问题拆解为多个小问题,逐步测试每一部分的结果。例如,如果某个模块的逻辑无法正常运行,可以先测试其输入输出,再逐步调试内部逻辑。

3. 小结

用 AI 编程,也就是和 AI 协作,本质上是一种双向的沟通过程。

我们需要像与团队成员协作一样,清晰表达需求、提供必要的背景信息,并通过持续的反馈和迭代优化,逐步引导 AI 生成符合预期的结果。只有做到有效沟通,AI 才能真正成为开发者的高效助手,而不是一个需要频繁纠错的工具。

以上。