我最近花了整整两周时间把 NVIDIA 内部流传出来的一个 Agent 自进化实验复现了一遍代号 KDA。核心玩法用八个字就能说清楚让 KDA 写 KDA。这里的 KDA 我按工程口径理解为 Knowledge-Driven Agent也就是知识驱动型智能体。实验的目标不是做一个能陪你聊天的 agent也不是做一个能帮你查资料的 RAG 助手而是让一个智能体在跑任务的过程中不断沉淀工具、经验和知识再用这些沉淀自动生成下一版本的自己。说实话刚看到标题那会儿我也觉得有点玄以为是什么 PR 造概念。真正把手头项目停掉去复现以后我对 Agent 自进化的认知清晰了不少它不是让模型突然自己长出智力而是把提示词工程、代码生成、沙盒执行、评测反馈、记忆归档整个串成一个自动化闭环。如果你也在做 Agent 开发或者正被工具调用、多步骤任务链路、上下文管理、并发调度这些问题反复折磨这篇文章值得你从头看到尾。我会把我复现时用的环境配置、核心代码骨架、排障记录和对这件事的真实判断都放出来能抄的你就直接抄。1. 这个自进化实验到底在做什么1.1 一句话理解 KDA很多人第一次听到“让 KDA 写 KDA”会下意识以为是用一个大模型去写另一个大模型。实际上不是。KDA 的进化对象不是模型权重而是围绕模型能力生长的知识包和工具链。你可以把 KDA 理解成一个容器里面装着三样东西一套系统提示词包含角色的工作方式、输出格式、禁忌事项一组工具定义每个工具都有名字、参数 schema、执行逻辑一份记忆库记录历史任务怎么完成的、卡在哪里、用什么方案解决。所谓“让 KDA 写 KDA”就是让当前这个容器里的 Agent 在完成真实任务时把新的工具、更好的提示词和可复用的经验写回去生成一个功能更强的新容器然后新容器继续跑任务、继续迭代。这个思路和传统 Prompt Engineering 有本质区别。传统做法是“人写 AgentAgent 用”效果好坏取决于人能不能把所有边角料都想全。KDA 的思路是“Agent 边用边写”把那些只在真实运行中才会暴露出来的工具拼装、调用顺序、错误恢复方式沉淀下来变成下一轮可以直接调用的知识。1.2 NVIDIA 为什么盯上 Agent 自进化NVIDIA 有足够的动机做这个方向因为他们要维护的自动化和基础设施太多了。第一层是软件栈。GPU 驱动、CUDA 版本、容器镜像、推理引擎之间有一堆排列组合每个组合都可能踩到不同的坑。如果让 Agent 去处理这些环境问题它需要知道“什么场景配什么参数”“报了什么错应该怎么处理”这些知识靠人工维护成本极高。自进化的价值在于Agent 每次解决一个新问题这个解法会被验证、被保存下一次同类问题出现时不需要再从头推理。第二层是大规模编排。H100 千卡级别的部署里调度、监控、诊断、恢复这种活通常有固定套路但又经常出现没有前人文档覆盖的新故障模式。想让 Agent 能应对新故障最直接的办法就是让它在真实故障里积累经验。KDA 这种设计等于给 Agent 装了一个“自动写文档、自动更新策略”的机制。第三层是验证一个技术方向代码生成模型到底能不能可靠地改进自己的工具链。这个验证一旦跑通后面的一整套工具链维护、知识库更新、自动化测试生成都能从人肉模式切到 Agent 自动模式。老实说NVIDIA 不只是想看一个 Agent 能不能变强他们更想看的是当 Agent 的改进行为可以被自动验证时它的进化速度能不能跑赢人工维护。1.3 一条可以被复制的自进化路径我在复现时把实验拆成了四个阶段按这个顺序推动顺序乱了很容易出现 Agent 一直在改、但越改越乱的局面。第一阶段是种子行为定义。先写清楚初始 Agent 的技能边界不让它去改动自己的系统提示词只让它通过完成任务暴露问题。第二阶段是能力封装。把每次解决具体问题的代码封装成工具注册到工具列表里同时生成对应的说明文档。这个阶段最容易忽视的是工具 schema 质量schema 写不清模型根本不知道怎么用。第三阶段是验证与反思。让 Agent 在沙盒里执行自己的生成结果再通过单元测试或对比测试判断效果。执行失败时要求它读取报错并生成修复补丁成功后才允许进入知识沉淀环节。第四阶段是知识入库与升级。把通过验证的工具描述、调用示例、失败案例写入向量库和结构化记忆表同时更新下一轮 Agent 的上下文素材。下一轮 Agent 在启动时自动加载这些知识相当于站在前一轮的肩膀上开工。注意这条路径里每一步都必须有明确的通过标准。没有标准Agent 自己写的测试可能会自欺欺人最后“进化”到一个看起来很美但实际没法用的状态。2. 关键架构把“写 Agent 的 Agent”从脚本变成系统2.1 一个最小的自进化闭环先画一个最小的闭环长什么样任务池里取一个任务由当前版本的 Agent 生成一段代码或一个工具实现把代码丢进沙盒执行拿到真实输出用评测器可以是规则、单元测试也可以是另一个模型打分如果失败让反思模块根据错误信息生成修复意见把修复意见交给生成器重新生成如果通过把最终版本和它的使用说明写入知识库累积到一定数量后用知识库生成下一版 Agent 的上下文。这里最像“进化”的地方在最后一步。前 7 步本质上是一个“自动修复循环”很多 CI 工具也在做。最后一步真正决定你是做“自动补丁”还是“Agent 自进化”不是改完一个 bug 就完事而是把这次的工具、经验、失败教训变成未来所有任务都能用上的公共知识。我在实现时把整条链路做成了一种事件管道生成、执行、评测、反思、归档每个环节都是独立组件。这样不管是用 LangGraph 还是自己写循环都能很自然地对接到里面去。2.2 harness 和 agent差别比很多人想的更大自进化实验里流传很多术语最容易混的是 harness 和 agent。如果不把这两个概念拆清楚后面做架构设计会一直偏。harness 是 Agent 运行时的外壳。它负责管理循环、处理工具调用协议、维护上下文窗口、把模型输出解析成可执行动作、控制超时和重试。agent 是模型在当前状态下输出的一段思考加一个动作序列。你可以把 harness 理解成赛车agent 理解成驾驶员。赛车底盘不稳再好的驾驶员也跑不出成绩驾驶员决策不对再好的底盘也没用。在 KDA 实验里被“进化”的是 agent 的行为但承载行为的是 harness。只改 agent 的提示词不调整 harness很多改进会被底层的调用超时、上下文溢出、工具结果过长这类问题吞掉。我在复现时做的第一个调整就是让 harness 支持把工具返回结果截断成摘要这个改动带来的提升比在提示词里多写十句“请谨慎处理长文本”都大。所以做自进化项目时你必须要决定哪些东西归 harness 管哪些东西归 agent 模型管。我的建议是循环控制、超时、重试、并发限制、上下文管理全放 harness任务拆分、工具选择、决策和反思放 agent工具实现本身单独成模块。让模型自己改自己的 harness 是高风险动作容易把运行框架改坏先不要开放这个权限。2.3 框架选型别为了省事把控制权交出去做一个自进化 Agent 时主流框架可以用但不能无脑用。我的实际经验是外部框架负责辅助能力核心进化循环一定要自己控制。下面是我测过几个方向的判断框架适用场景我在 KDA 实验里的判断LangGraph状态机显式可控适合构建有明确环节的循环适合做执行器和评测器但工具调用协议需要自己定义AutoGen多 Agent 对话协作适合角色扮演和方案讨论用来做反思模块可以做主循环容易失控Semantic Kernel微软生态优先强调插件化适合企业内部工具做自进化实验不值得硬绑自己写循环完全透明想怎样改就怎样改原型阶段最推荐几十行就能跑别上太重我最后的核心循环是自己写的大概两百行代码因为自进化的关键是“修改什么、验证什么、何时入库”这些策略。框架给的抽象越漂亮我越难精确控制验证时机。你如果只是要做原型建议也别一开始就套重型框架。先手写一轮等你对流程的每个环节都有了明确认识再考虑引入框架去补齐工具调用、记忆、监控这些通用能力。2.4 AI Agent 怎么扛并发自进化实验里是硬仗热词里有个问题问“AI Agent 怎么扛并发”在自进化实验里这个问题被放大了。因为每轮进化不是只跑一个候选方案经常要同时跑好几个版本原始版、修复版、加了新工具的版本、换了提示词的版本。如果不做并发控制显存和 API 配额都会被瞬间打爆。我用的是一套很朴素的方案。第一池化推理实例。不要让每个任务单独申请一个 GPU 独占进程而是提前 loading 一个或多个推理服务Agent 任务通过请求队列去拿结果。这样显存占用稳定响应时间也稳定。第二限制并发 Agent 数。我当时只允许同时跑 4 个候选任务。太多的话沙盒执行结果相互挤占资源评测抖动会明显变大你根本分不清方案变好是真实改进还是机器变快了。第三共享上下文缓存。同一个 Agent 版本处理相似任务时系统提示词和工具定义完全一样这段输入可以按 prompt hash 做缓存能省很大一笔推理开销尤其在本地部署的时候。第四统一任务状态存储。每个候选任务从提交、执行到归档状态全部写入数据库。这样即使某个 Worker 崩了任务状态还留着重启后能接着跑而不是从头再来。并发控制做不好自进化实验会从“科学实验”退化成“资源消耗战”。我见过有人因为没限制并发一夜之间把显存打满整个训练服务器被 OOM 拖垮。这属于很低级但很高频的坑。3. 实操从一台 NVIDIA GPU 机器出发跑通第一个自进化循环3.1 NVIDIA 驱动和容器 runtime 的安装顺序如果你本机或服务器上用的是 NVIDIA GPU第一步是把驱动和容器运行环境装干净。这套顺序我整理过很多次照着敲基本不会出问题。# 1. 安装驱动相关包 sudo apt update sudo apt install -y ubuntu-drivers-common sudo ubuntu-drivers autoinstall sudo reboot # 2. 确认驱动可见 nvidia-sminvidia-smi 能看到 GPU 和驱动版本就代表驱动这层过了。下一步装容器运行时因为后面沙盒要在 Docker 里用 GPU。# 3. 配置 NVIDIA Container Toolkit curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -fsSL https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit # 4. 让 Docker 使用新的 runtime sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker # 5. 验证容器内 GPU 可见 docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi注意几个细节。第一不要装完驱动立刻装 CUDA Toolkit先确认容器能识别 GPU再去装你项目真正需要的 CUDA。第二如果机器开了安全启动驱动装完可能无法加载这时候需要在 BIOS 里处理好签名验证或者按照驱动安装时的提示注册 MOK。第三如果你装完驱动后重启直接黑屏很可能是内核模块与显卡不匹配进恢复模式后先用nvidia-smi看一眼日志再用 apt 重新安装推荐版本。3.2 建立让 AI 代码放心执行的沙盒自进化的 Agent 会生成代码这些代码不能直接放在宿主机上跑。我当时的做法是给每个候选任务起一个一次性容器容器里只放任务需要的依赖跑完就销毁。Dockerfile 的一个参考写法FROM nvidia/cuda:12.4.1-runtime-ubuntu22.04 RUN apt-get update apt-get install -y \ python3-pip python3-dev git curl build-essential \ rm -rf /var/lib/apt/lists/* RUN pip3 install --no-cache-dir \ numpy pandas pydantic requests RUN useradd -m -s /bin/bash sandboxuser USER sandboxuser WORKDIR /workspace启动容器时加上资源限制和超时docker run \ --rm \ --gpus all \ --network none \ --memory 4g \ --cpus 2 \ --user sandboxuser \ -v /tmp/kda_workspace:/workspace \ kda-sandbox:latest \ timeout 120 python3 /workspace/task.py把网络直接设为 none 是防呆设计防止 Agent 生成的代码偷偷联网下东西。如果任务确实要调内部 API再通过参数白名单单独放开不要默认全开。这些限制看起来很基础但作用非常大。我在复现时曾经让 Agent 写了一段会不断 fork 的测试代码如果没有 CPU 限制宿主机负载能被直接拉满。沙盒不是“可有可无的规范”是自进化实验的生命线。3.3 记忆和知识库让每一轮实验都不白跑KDA 的“知识驱动”体现在哪里就体现在记忆模块。没有记忆模块Agent 每轮任务都像失忆一样重新探索效率极低。我的记忆模块分两层。第一层是短期执行记忆存在数据库里记录一次任务从开始到结束的关键事件任务描述、生成的代码、执行输出、评测分数、修复补丁、最终结果。这层记忆主要是给反思模块看的让它可以回头分析“哪里出了问题、是怎么修的”。第二层是长期语义记忆存在向量库里。当新任务进来时系统先从向量库里检索相似历史任务把相似的工具和方案摘要注入到 Agent 的上下文里。这一步跑好了Agent 遇到相似任务时可以直接复用经验而不是每次都从零开始。我当时用的向量库是 Chroma够用且轻。入库前会把代码实现和说明文字一起向量化。检索时只取 top-3防止上下文被塞满。还有一件事必须做给每条记忆打标签。标签至少包含任务领域、工具名、成功失败、模型版本。没有标签的知识库检索出来一堆无关内容比不检索还糟。3.4 一个可运行的“让 KDA 写 KDA”核心骨架自进化循环的主程序看起来不像某些框架那么玄核心就是一个不断迭代的设计。我写一个最小版本from dataclasses import dataclass, field dataclass class KDA: system_prompt: str tools: dict field(default_factorydict) knowledge_base: list field(default_factorylist) def generate(self, task: str) - str: # 调用大模型生成一段能完成任务的代码 messages [ {role: system, content: self.system_prompt}, {role: user, content: f任务{task}\n可用工具{list(self.tools.keys())}}, ] return call_llm(messages) def execute(self, code: str, sandbox) - str: # 在一次性容器沙盒里执行代码拿到真实输出 return sandbox.run(code, timeout120) def evaluate(self, task: str, result: str) - float: # 规则打分跑通给 1跑不通给 0能进一步细化就再加 return 1.0 if PASS in result else 0.0 def reflect(self, task, code, result, score) - str: if score 1.0: return # 把失败信息交给模型让它生成修复合订 messages [ {role: system, content: 你是一个调试工程师根据执行结果写修复方案。}, {role: user, content: f任务{task}\n代码{code}\n执行结果{result}}, ] return call_llm(messages) def improve(self, code: str, reflection: str) - str: # 把反射结果和原代码一起交给生成器生成修复版本 messages [ {role: system, content: self.system_prompt}, {role: user, content: f原代码\n{code}\n修复意见\n{reflection}}, ] return call_llm(messages) def run_evolution_cycle(self, task: str, sandbox, max_rounds3) - str: code self.generate(task) for _ in range(max_rounds): result self.execute(code, sandbox) score self.evaluate(task, result) if score 1.0: self.knowledge_base.append({task: task, code: code, result: result}) return code reflection self.reflect(task, code, result, score) code self.improve(code, reflection) return code这段伪代码的核心价值在于把“生成、执行、评估、反思、改进、入库”六个环节拆了出来。真实项目中评估不会这么粗糙至少要包含单元测试、回归测试和结构化指标但骨架结构是一样的。我建议你把这段代码放到 Git 仓库里每轮进化都打一个 tag方便回滚。3.5 本机推理与性能监控的实用检查单如果自进化实验不是走 API而是用本机 GPU 推理那 3.1 之后还要多做一些检查。我每次跑实验前都会过一遍这个清单nvidia-smi看驱动和显存占用用nvidia-smi -q -d TEMPERATURE看温度避免实验还没跑完就撞上高温掉频跑一次小规模推理记录首 token 延迟和平均吞吐用docker stats观察显存和 CPU 上限确认沙盒没有超额占用资源如果用到带有 ECC 的 GPU看到 ECC corrected error 的报告不要慌先检查错误类型必要时用驱动工具重置相关统计不要一看到报错就停掉整个实验。还有个小坑提一下Windows 上如果发现 NVIDIA 控制面板找不到多半是系统服务被禁了重新装一遍驱动或者启动对应服务就行。Linux 桌面环境下用nvidia-settings也能完成大部分显示设置。这些问题不大但卡住时会很浪费时间。4. 常见问题与排障记录4.1 自进化循环最容易挂掉的四个环节自进化循环挂掉的位置通常不是模型本身而是它周围的基础设施。我按踩坑频率排了个序。第一是工具返回内容过长。模型调工具后工具返回一坨几万字日志上下文直接超限Agent 就报“agent execution terminated due to error”。我的解决办法是让工具在返回前做摘要只保留关键行。日志文件重定向到文件工具返回文件路径而不是把内容全量塞给模型。第二是无限循环和重复调用。没有超时保护Agent 能在工具调用和反思之间循环几十轮。解决办法是两层一层是外层调用加 timeout另一层是在 harness 里设置最大循环次数超过就强制停止并返回部分结果。第三是评测集不够硬。Agent 自己生成的示例和测试大概率会绕开它的弱项。如果你只拿 Agent 自己选的测试来评估它很容易给你“进化”出一个高分但实际没用的模型。必须有人工维护的黄金评测集且每个改动都要先过这个黄金集。第四是知识库污染。一旦某个错误的工具或错误经验进了知识库后面所有 Agent 都会被影响而且这种污染很难一眼发现。我的建议是知识库入库前加自动测试不通过的代码绝不进库宁缺毋滥。4.2 NVIDIA 驱动、CUDA 和容器环境的坑自进化实验环境问题大多是这几类。驱动装完但nvcc不可用这是没装 CUDA Toolkit驱动只是驱动确认你的项目到底需要哪个 CUDA再安装对应版本。Docker 容器里跑nvidia-smi报错多半是容器 runtime 没有配置好执行一下sudo nvidia-ctk runtime configure --runtimedocker然后重启 Docker。Ubuntu 下驱动升级完重启失败常见原因是内核更新后模块没有重编回到旧内核或者重新安装驱动即可。显存缓存目录膨胀比如 Windows 下AppData\Local\NVIDIA\DXCache越变越大那是图形着色器缓存可以定期清理不影响实验。我在复现时还被 ECC 报错误导过一次。GPU 日志里出现大量 corrected error我一度以为是卡要坏了结果翻文档才发现是 ECC 正常工作时的统计日志。后来实验前直接重置 ECC 统计把“报错不可怕、可怕的是没记录基线”这条观念记牢了。4.3 Agent 安全与沙盒隔离的底线自进化实验里的 Agent 有代码生成能力这属于高权限角色。安全底限如果没守住你收获的不是进化是一堆麻烦。我的几条底线原则Agent 生成的代码永远不在宿主机直接运行只能在沙盒容器里跑沙盒容器默认关闭网络需要联网的任务走白名单容器内使用非 root 用户文件系统只读挂载工作区之外的目录API 密钥等敏感信息不写进 prompt只用环境变量注入到白名单进程每一轮候选改动提交前都要过一个人工审批门全自动跳过这一步的风险极高。有些人会觉得这些都是小题大做直到 Agent 生成的代码把主机的临时目录写满才发现问题。自进化系统的价值确实大但它的潜在破坏力也和价值成正比安全不是可选项。4.4 用数据观察进化是否真的发生了判断一个 Agent 是不是真的在进化不能只靠感觉。我建议每轮记录这几个指标指标含义怎么判断首轮成功率不改代码直接通过的比例应该逐步上升平均修复轮数从失败到通过需要几轮反思应该逐步下降工具复用率新任务使用历史工具的比例说明知识迁移有效向量检索命中率相似任务能找回有用记忆返回内容相关度要保持黄金评测集通过率人工验证集上的表现这个绝对不能下降如果这些指标连续几轮没有变化别去调模型了先检查是不是任务池太简单、评测区分度太低或者知识库注入没有生效。我遇到过最有迷惑性的情况普通测试分数一路涨黄金评测集分数却在跌本质是 Agent 在“过度拟合”那些简单任务。解决办法是把任务池和评测集都分成基础、进阶、挑战三层每层都看通过率。5. 踩坑之后我对 Agent 自进化的真实判断复现完这套实验我对 Agent 自进化的理解比之前务实了很多。它不会让你 overnight 得到一个全知全能的超级 Agent。真正发生的是系统把以前靠人肉维护的提示词、工具和知识积累变成了半自动流程。该写代码还是写代码该调 bug 还是调 bug只是这些工作被封装成了“Agent 生成、沙盒验证、知识回流”的循环。对于工具会持续变多的项目和需要大量重复调参的Agent应用这套机制能节省的时间非常可观。我实际操作下来觉得最有价值的不是最后生成的 Agent而是过程中形成的知识库和验证体系。你越早让 Agent 开始沉淀经验后面每个新任务花的推理成本就越低。如果你要照着做,有两点提醒。第一先让人工手动跑通一条完整链路再逐步自动化不要上来就全自动;第二每次进化都保留版本记录这次改了什么、为什么改、验证结果是什么。这比模型再聪明都重要,因为你永远需要回滚的余地。最后再分享一个小技巧:不要只让 Agent 修改自己的系统提示词那是最难验证也最容易退化的一步。更好的做法是让 Agent 生成独立的工具模块和知识条目通过测试后再注册到 Agent 的能力池里。这样每一轮进化都是一个增量更新既能观察效果也能避免把整个 Agent 改坏。自进化这件事控制风险比追求速度重要得多。