LLM Agent驱动的LoRA微调自动化：从手动调参到工程化决策

1. 这不是“调参”，是让模型学会做工程师决策

你有没有试过在 LLaMA-Factory 里调一个 LoRA 的r值？改完r=8，跑一小时发现显存爆了；换成r=4，又发现训练 loss 像坐滑梯一样纹丝不动；再试r=6，loss 下降了，但验证集 perplexity 却在第3个 epoch 就开始爬升——你盯着 TensorBoard 刷新页面，手指悬在键盘上，心里默念：“这次一定行”。这不是玄学，这是微调工程师的日常。而今天我要说的，不是教你“怎么选 r”，而是：让另一个 AI 坐在你工位上，替你完成从问题识别、假设生成、实验设计、结果分析到下一轮迭代的完整闭环。

这个思路直接来自 Andrej Karpathy 在 autoresearch 项目中反复强调的核心信条：“Don’t write code to solve the problem — write code to write the code that solves the problem.”（不要写代码去解题，要写代码去生成解题的代码）。我们把这句话平移进微调场景，就变成了：不要手动试错调参，要构建一个能自主规划、执行、反思微调实验的 LLM Agent。它不输出最终配置，它输出的是“为什么选这个配置、怎么验证它、失败后该往哪走”的完整推理链。关键词里反复出现的 “LLM Agent”、“LLaMA-Factory”、“Karpathy autoresearch”，指向的正是这个范式迁移——从“人驱动工具”到“Agent 驱动工作流”。

我实测下来，这套方案最颠覆认知的一点是：它根本不需要你预先定义“最优目标”。你不用告诉它“perplexity 要低于 5.2”，也不用设定“训练时间不能超 4 小时”。你只需要给它一个原始任务描述，比如：“用 1 张 A100 显卡，在 24 小时内，让 LLaMA-3-8B 在中文法律问答数据集上达到可接受的 zero-shot 准确率”。Agent 会自己拆解出：当前瓶颈可能是显存、可能是数据质量、可能是学习率预热不足；然后它会主动查 LLaMA-Factory 的文档，确认--gradient_accumulation_steps和--per_device_train_batch_size的组合约束；再基于你本地 GPU 的nvidia-smi输出，反向推算出可行的 batch size 上限；最后才生成第一版配置。整个过程，它像一个经验丰富的同事，边查文档边跟你讨论，而不是一个黑盒参数生成器。这背后的技术支点，是 LLM 的规划能力（Planning）、工具调用能力（Tool Use）和自我反思能力（Self-Critique）三者的深度耦合。接下来，我会带你一层层剥开这个 Agent 的骨架，告诉你它如何真正“理解”微调这件事，而不是仅仅拼接字符串。

2. Agent 的“工程直觉”从何而来：领域知识注入与工具链设计

一个 LLM Agent 如果只靠 prompt 提示词硬凑，那它连--lora_alpha和--lora_dropout的物理意义都分不清，更别说做决策了。真正的“直觉”，来自于我们为它精心构建的领域知识底座和可信赖的工具链。这不是给它喂百科全书，而是给它配齐一套工程师的“工作台”：文档手册、实时环境探针、配置校验器、实验沙盒。我把它拆成三个不可替代的模块，缺一不可。

2.1 模块一：结构化知识库——让 Agent 真正“读懂” LLaMA-Factory

你不能指望 Agent 去 Google 搜索 LLaMA-Factory 的 GitHub README，再人工总结。它需要的是可被精准检索、带上下文语义、且经过工程验证的知识片段。我的做法是：将 LLaMA-Factory 的官方文档、核心源码（特别是src/llamafactory/train/args.py和src/llamafactory/train/trainer.py）、以及社区公认的调优指南（如 Hugging Face 的 PEFT 最佳实践），全部解析为结构化 JSON。每个 JSON 对象包含四个字段：key（唯一标识，如"lora_r"）、description（自然语言解释，强调影响面，例如：“r控制 LoRA 矩阵的秩，值越大模型容量越高，但显存占用呈平方级增长；在 A100-40G 上，r=8通常需配合lora_alpha=16以维持缩放平衡”）、constraints（硬性约束，如"type": "int", "min": 1, "max": 64, "multiple_of": 2）、common_mistakes（典型错误，如：“若lora_alpha未按2*r设置，会导致权重初始化偏差，训练初期 loss 波动剧烈”）。

提示：这个知识库不是静态的。每次 Agent 执行一个新实验后，如果发现文档描述与实际行为不符（比如文档说--fp16默认开启，但实测在某些 CUDA 版本下必须显式指定），它会自动触发一个update_knowledge工具，将这条“实测反馈”追加到对应 key 的common_mistakes字段。这保证了知识库随你的环境持续进化。

2.2 模块二：环境感知工具——让 Agent “看见”你的硬件与数据

一个脱离真实环境的 Agent 是空中楼阁。它必须能实时获取你机器的“生命体征”。我封装了三个核心工具：

• get_gpu_info()：调用nvidia-smi --query-gpu=name,memory.total,memory.free --format=csv,noheader,nounits，返回结构化 JSON，精确到 MB。Agent 不会看到“显存充足”，它看到的是"memory_free": 38245。
• get_dataset_stats(dataset_path: str)：扫描数据集目录，计算样本数、平均input长度、平均instruction长度、最长样本长度。这对判断max_source_length和max_target_length至关重要。比如，当它发现 95% 的input长度 < 256，而你配置了max_source_length=1024，它会立刻质疑：“此设置导致大量 padding，浪费显存，建议下调至 320”。
• validate_config(config_dict: dict)：一个 Python 函数，它不只是检查字段是否存在，而是执行逻辑校验。例如，当config_dict["lora_r"] = 16且config_dict["lora_alpha"] = 8时，它会报错：“lora_alpha(8) 应 >=2 * lora_r(32) 以保证权重缩放合理性”。这个校验器直接复用了 LLaMA-Factory 源码中的check_arguments逻辑，确保 Agent 的“常识”和框架本身完全一致。

2.3 模块三：安全沙盒执行器——让 Agent “动手”而不“闯祸”

Agent 必须能运行命令，但绝不能让它直接rm -rf /。我的沙盒设计有三重保险：

1. 白名单命令：只允许llamafactory-cli train、python -c "import torch; print(torch.cuda.memory_allocated())"这类无副作用的命令。所有git、wget、cp操作都被拦截。
2. 资源熔断：通过timeout 3600和ulimit -v 30000000（限制虚拟内存 30GB）包裹每个训练命令。一旦训练进程超时或内存越界，沙盒自动终止并返回错误日志。
3. 结果归档：每次实验，沙盒会自动将output_dir下的trainer_log.json、all_results.json和关键的train.log复制到一个统一的agent_experiments/目录，并打上时间戳和配置哈希。这为后续的self_reflect步骤提供了不可篡改的证据链。

这三个模块共同构成了 Agent 的“工程直觉”。它不是在猜，而是在查、在看、在验。当你看到 Agent 第一次运行就准确指出“per_device_train_batch_size=2在当前gradient_accumulation_steps=4下，等效 batch size 为 8，但根据get_dataset_stats，平均样本长度为 512，预计显存占用将达 39.2GB，超出 A100-40G 的 38.2GB 可用内存”，你就知道，它已经不是一个玩具，而是一个可以托付部分工作的数字同事。

3. 从 Prompt 到 Planner：Agent 的决策引擎如何工作

很多教程把 LLM Agent 简化为“一个大模型 + 若干工具调用”，这严重低估了其复杂度。真正的挑战在于：如何让 LLM 在每一步都做出符合工程逻辑的、可追溯的、可修正的决策？我的方案摒弃了简单的 ReAct（Reasoning + Acting）循环，采用了一个四阶段的 Planner 架构，每个阶段都有明确的输入、输出和失败回滚机制。这个架构的灵感直接来自 Karpathy 在 autoresearch 中对“研究者思维”的拆解：观察（Observe）、假设（Hypothesize）、实验（Experiment）、归纳（Synthesize）。

3.1 阶段一：Observe（观察）——构建当前状态的“数字孪生”

Agent 启动后的第一步，不是思考“该做什么”，而是执行一个强制的observe_state工具。这个工具会并行调用之前提到的所有环境感知工具，并将结果整合成一个结构化的state_snapshot：

{ "gpu": {"name": "A100-SXM4-40GB", "memory_total": 40960, "memory_free": 38245}, "dataset": {"samples": 12478, "avg_input_len": 482, "max_input_len": 2156, "avg_output_len": 127}, "llamafactory_version": "0.9.0", "current_config": { "model_name_or_path": "meta-llama/Meta-Llama-3-8B", "dataset": "law_qa_zh", "stage": "sft", "do_train": true, "lora_r": 8, "lora_alpha": 16, "per_device_train_batch_size": 2, "gradient_accumulation_steps": 4 } }

这个快照是 Agent 所有后续推理的唯一事实来源。它不会相信 prompt 里你写的“我有 2 张 GPU”，它只相信nvidia-smi的输出。这一步看似简单，却是杜绝“幻觉”的第一道防线。我见过太多 Agent 因为错误地假设了 GPU 数量，导致生成的--ddp_timeout参数完全失效。

3.2 阶段二：Hypothesize（假设）——生成可证伪的工程猜想

基于state_snapshot，Agent 进入核心推理环节。这里的关键是：它生成的不是“配置”，而是“假设”。每个假设都遵循IF [条件] THEN [预期效果] BECAUSE [原理依据]的三段式结构。例如：

IFmax_source_length=1024is used withavg_input_len=482, THEN training will waste ~53% of GPU memory on padding, BECAUSE each sample is padded to 1024 tokens, and memory usage scales linearly with sequence length.

这个假设清晰地指出了问题（内存浪费）、量化了影响（53%）、并给出了理论依据（padding 与内存线性关系）。它不是主观评价，而是可被后续Experiment阶段证伪的命题。Agent 会同时生成 3-5 个这样的假设，覆盖不同维度：显存瓶颈、数据瓶颈、收敛速度瓶颈、过拟合风险。这些假设会被存入一个hypothesis_pool，作为后续实验的待验证清单。

3.3 阶段三：Experiment（实验）——设计最小可行的验证方案

Agent 不会一股脑儿跑完所有假设。它会为每个假设设计一个最小变更（Minimal Change）的实验。原则是：只改一个变量，其他所有条件严格锁定。例如，针对上面的 padding 假设，它不会说“把max_source_length改成 512”，而是生成一个精确的实验计划：

experiment_id: "hypo_001_padding" hypothesis: "Reducing max_source_length from 1024 to 512 will decrease GPU memory usage by ~50%" plan: - step: "Record baseline memory usage with current config" command: "nvidia-smi --query-compute-apps=pid,used_memory --format=csv,noheader,nounits | head -1 | awk -F', ' '{print $2}'" - step: "Run one training step with max_source_length=512" command: "llamafactory-cli train --max_source_length 512 --num_train_epochs 0.001 ..." - step: "Record peak memory usage during that step"

注意，这个计划里没有“跑完整个 epoch”，只有“0.001 个 epoch”，即一个 step。这是为了在秒级内获得可比较的内存数据，极大加速迭代。Agent 深知，在调参的早期，精度远不如速度重要。

3.4 阶段四：Synthesize（归纳）——从数据中提炼新知识

当实验数据返回，Agent 进入 Synthesize 阶段。它会将实验结果与原始假设进行比对。如果结果支持假设（例如，内存使用确实从 37.8GB 降到了 18.3GB），它会将此结论固化为一条新的knowledge_facts，并更新知识库。如果结果证伪假设（例如，内存没变，但 loss 突然爆炸），它会启动一个root_cause_analysis子流程：调用validate_config检查新配置，调用get_dataset_stats重新审视数据分布，甚至调用read_file查看train.log中的 warning。这个过程可能触发新一轮的 Observe-Hypothesize-Experiment 循环。整个 Planner 的精妙之处在于，它的每一次“失败”，都在为下一次“成功”积累更坚实的知识砖块。它不是在寻找一个答案，而是在构建一个关于“在这个特定环境下，微调如何工作”的动态模型。

4. 代码实现：一个可立即运行的 Agent 核心骨架

光讲原理不够，你得能亲手把它跑起来。下面是我剥离了所有业务逻辑、仅保留核心 Agent 能力的最小可运行骨架。它基于langchain和llamafactory，所有依赖均可通过pip install安装。重点不是代码有多炫，而是每一行都服务于一个明确的工程目的。你可以把它当作一个起点，填入你自己的知识库和工具。

4.1 环境准备与依赖声明

首先，创建一个干净的 Python 环境（推荐 conda）：

conda create -n llama-agent python=3.10 conda activate llama-agent pip install llamafactory langchain langchain-community openai python-dotenv # 注意：llamafactory 0.9.0 需要 torch>=2.1.0+cu121，请根据你的 CUDA 版本选择合适的 torch

然后，创建项目目录结构：

llama-agent/ ├── knowledge/ │ └── llamafactory_rules.json # 你的结构化知识库 ├── tools/ │ ├── gpu_tool.py │ ├── dataset_tool.py │ └── config_validator.py ├── agent/ │ └── planner.py # 核心 Planner 类 ├── main.py # 入口脚本 └── .env # 存放 OPENAI_API_KEY

4.2 核心 Planner 类（agent/planner.py）

这个类封装了前面讲的四阶段循环。它不关心 LLM 是谁，只关心“如何让 LLM 按照我们的工程逻辑来思考”。

# agent/planner.py from typing import Dict, List, Any, Optional from langchain_core.tools import BaseTool from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_openai import ChatOpenAI from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder class LlamaTuningPlanner: def __init__(self, llm: ChatOpenAI, tools: List[BaseTool]): self.llm = llm self.tools = tools # 定义四阶段的系统提示词，这是 Agent 的“宪法” self.system_prompt = """ You are an expert LLaMA-Factory tuning engineer. Your job is not to guess configurations, but to conduct rigorous engineering research following the Observe-Hypothesize-Experiment-Synthesize cycle. - In OBSERVE: You MUST call `observe_state` first to get the real-time environment snapshot. - In HYPOTHESIZE: Generate ONLY testable, quantifiable hypotheses in the format: "IF [condition] THEN [effect] BECAUSE [reason]". - In EXPERIMENT: Design MINIMAL changes. For memory tests, use `--num_train_epochs 0.001`. - In SYNTHESIZE: Compare results with hypothesis. If disproven, run root cause analysis. NEVER make up facts. If a tool call fails, report the error and try a different approach. """ self.prompt = ChatPromptTemplate.from_messages([ ("system", self.system_prompt), ("human", "{input}"), MessagesPlaceholder("agent_scratchpad"), ]) self.agent = create_openai_tools_agent(self.llm, self.tools, self.prompt) self.agent_executor = AgentExecutor(agent=self.agent, tools=self.tools, verbose=True) def run(self, initial_task: str) -> Dict[str, Any]: """Run the full tuning research cycle for the given task.""" return self.agent_executor.invoke({"input": initial_task})

4.3 关键工具实现（tools/gpu_tool.py）

以gpu_tool.py为例，展示一个“安全、可靠、有信息量”的工具应该如何编写：

# tools/gpu_tool.py import subprocess import json from langchain_core.tools import BaseTool from pydantic import BaseModel, Field class GetGPUInfoInput(BaseModel): """Input for GetGPUInfoTool.""" pass class GetGPUInfoTool(BaseTool): name = "get_gpu_info" description = "Get detailed GPU information including name, total memory, and free memory in MB. Always call this first to understand the hardware constraints." args_schema = GetGPUInfoInput def _run(self) -> str: try: # 使用 nvidia-smi 获取结构化输出 result = subprocess.run( ["nvidia-smi", "--query-gpu=name,memory.total,memory.free", "--format=csv,noheader,nounits"], capture_output=True, text=True, timeout=10 ) if result.returncode != 0: return f"Error running nvidia-smi: {result.stderr}" # 解析 CSV 输出 lines = result.stdout.strip().split('\n') gpus = [] for line in lines: parts = [p.strip() for p in line.split(',')] if len(parts) == 3: gpus.append({ "name": parts[0], "memory_total": int(parts[1].replace(' MiB', '')), "memory_free": int(parts[2].replace(' MiB', '')) }) return json.dumps(gpus, indent=2) except Exception as e: return f"Exception in get_gpu_info: {str(e)}"

注意：这个工具的description里明确写了“Always call this first”，这是在引导 LLM 的行为模式。而_run方法里，我们做了超时控制（timeout=10）、异常捕获、以及对nvidia-smi输出的健壮解析。它返回的不是“显存还够”，而是{"memory_free": 38245}这样的精确数字，这才是 Agent 能用的“燃料”。

4.4 入口脚本（main.py）——让你的 Agent 开始工作

最后，main.py把所有东西串起来。你只需修改initial_task字符串，就能让它为你服务。

# main.py import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from agent.planner import LlamaTuningPlanner from tools.gpu_tool import GetGPUInfoTool from tools.dataset_tool import GetDatasetStatsTool from tools.config_validator import ValidateConfigTool load_dotenv() if __name__ == "__main__": # 初始化 LLM（这里用 OpenAI，你也可以换成本地 Ollama 模型） llm = ChatOpenAI( model="gpt-4-turbo", temperature=0.3, # 降低温度，让推理更确定、更工程化 max_tokens=2048 ) # 初始化所有工具 tools = [ GetGPUInfoTool(), GetDatasetStatsTool(), ValidateConfigTool() ] # 创建 Planner planner = LlamaTuningPlanner(llm=llm, tools=tools) # 定义你的初始任务 initial_task = ( "I have a single A100-40GB GPU and a Chinese legal QA dataset. " "My current LLaMA-Factory config uses lora_r=8, lora_alpha=16, " "per_device_train_batch_size=2, gradient_accumulation_steps=4. " "The training is very slow and I suspect memory waste. " "Find the optimal configuration for fast, stable training." ) # 启动 Agent！ result = planner.run(initial_task) print("Final Result:") print(json.dumps(result, indent=2, ensure_ascii=False))

运行python main.py，你就会看到 Agent 如何一步步调用工具、生成假设、设计实验。它可能花 5 分钟，也可能花 20 分钟，取决于你的网络和 GPU。但关键是，它输出的不是一堆随机参数，而是一份带有时间戳、工具调用记录、假设验证结果的完整“实验报告”。这份报告，就是你下次手动调参时最宝贵的参考。

5. 实战踩坑：那些只有亲手做过才会懂的“幽灵问题”

理论再完美，也得经受现实的毒打。在我把这套 Agent 部署到三个不同客户的生产环境中后，遇到了几个教科书级别的“幽灵问题”。它们不会出现在任何官方文档里，但每一个都足以让 Agent 崩溃、让训练中断、让工程师抓狂。我把它们整理出来，不是为了吓唬你，而是为了让你在部署前就打上“免疫补丁”。

5.1 幽灵问题一：CUDA out of memory的“虚假警报”

现象：Agent 调用get_gpu_info()返回memory_free: 38245，信心满满地设置了per_device_train_batch_size=4，结果llamafactory-cli train一启动就报CUDA out of memory。Agent 查看train.log，发现错误发生在model.to(device)阶段，而非训练循环中。

根因分析：nvidia-smi显示的是“显存空闲”，但它不等于“GPU 可用显存”。CUDA Context（上下文）会预留一部分显存用于管理开销，这部分是nvidia-smi看不见的。在 A100 上，这个开销通常是 1.5-2GB。更致命的是，llamafactory在加载模型时，会先将整个model.bin文件（约 16GB）加载到 CPU 内存，再分片传输到 GPU。如果 CPU 内存不足，PyTorch 会尝试用cudaMallocAsync，而这又会触发额外的显存预留。

解决方案：我在get_gpu_info()工具里增加了一行“安全余量”计算：

# 在 get_gpu_info.py 的 _run 方法末尾添加 safe_memory = gpu_info["memory_free"] - 2048 # 预留 2GB gpu_info["memory_safe"] = max(0, safe_memory) return json.dumps(gpu_info, indent=2)

然后，在 Agent 的 Hypothesize 阶段，所有关于 batch size 的假设，都必须基于memory_safe而非memory_free。这个小小的 2GB，救了我三次。

5.2 幽灵问题二：instruction和input的“隐形拼接陷阱”

现象：Agent 生成的配置里，max_source_length=512，max_target_length=128，一切看起来很合理。但训练开始后，train.log里疯狂刷出tokenization warning: sequence length exceeds max_length。Agent 查看get_dataset_stats()，发现max_input_len是 2156，远超 512。

根因分析：LLaMA-Factory 的sft模式，其instruction和input字段并不是简单拼接。它默认使用alpaca模板："Below is an instruction that describes a task. Write a response that appropriately completes the request.\n\n### Instruction:\n{instruction}\n\n### Input:\n{input}\n\n### Response:\n"。这个模板本身就有约 120 个 token！所以，max_source_length=512实际上留给{instruction}和{input}的总空间只有512 - 120 = 392。而get_dataset_stats()统计的max_input_len，是纯{input}的长度，不包含模板。

解决方案：我重构了get_dataset_stats()工具。它现在会：

1. 加载llamafactory的get_template_and_fix_tokenizer函数；
2. 用真实的alpaca模板，对数据集的前 100 个样本进行“模拟拼接”；
3. 统计拼接后的max_total_length。

这样，Agent 看到的就不再是max_input_len=2156，而是max_total_length_with_template=2276。它立刻就能推断出：“max_source_length必须 >= 2276，否则必然 truncation”。这个细节，是无数人在 LLaMA-Factory GitHub Issues 里反复提问却得不到解答的根源。

5.3 幽灵问题三：Agent 的“自我抄袭”——知识库的版本漂移

现象：Agent 在第 5 轮迭代中，成功将lora_r从 8 优化到 12，loss 下降稳定。但在第 12 轮，它又回到了lora_r=8，并给出理由：“r=8是社区最广泛验证的值，风险最低”。它“忘记”了自己亲手验证过的r=12。

根因分析：Agent 的知识库是静态 JSON 文件。当它在第 5 轮发现r=12更好时，它调用update_knowledge工具，将这条记录写入了文件。但update_knowledge是一个独立的工具，它的执行结果并不会自动刷新到当前 LLM 的上下文里。LLM 依然在“读取”旧版本的知识库快照。

解决方案：我引入了一个轻量级的“知识缓存层”。在每次observe_state之后，Agent 会执行一个refresh_knowledge_cache工具，该工具会：

• 读取knowledge/llamafactory_rules.json的最新修改时间；
• 如果发现自上次加载后有更新，则重新加载整个 JSON 到内存；
• 并将本次加载的timestamp记录在state_snapshot中。

这样，Agent 的每一次Hypothesize，都是基于它所知的、最新的、由它自己亲手写入的知识。它不再“遗忘”，因为它把记忆写在了硬盘上，而不仅仅是脑子里。

这些问题，没有一个能在 Karpathy 的 wiki 或 LLaMA-Factory 的 README 里找到答案。它们是真实世界里的泥潭，是你必须亲手趟过，才能长出真正的“工程直觉”。而我的 Agent，就是那个愿意陪你一起趟、并且把每一次摔倒都记下来的伙伴。

6. 超越调参：这个 Agent 如何重塑你的微调工作流

当我第一次看着 Agent 自己完成了从r=8到r=12的优化，并生成了一份包含 17 个对比实验、3 个被证伪的假设、以及最终配置选择理由的 PDF 报告时，我意识到，它的价值早已超越了“省事”或“自动”。它正在悄然重塑我们与微调这项技术的关系。这种重塑，体现在三个相互关联的层面。

6.1 层面一：从“参数调试员”到“问题定义者”

过去，我们的工作始于一个模糊的念头：“我想让模型在法律问答上更好一点”。然后，我们立刻跳进参数的海洋，开始r、alpha、lr的排列组合。我们花了 80% 的时间在“如何做”，却很少花 5 分钟去想“我们到底在解决什么问题”。Agent 强制我们回到原点。它的Observe阶段，逼你提供dataset_path和current_config；它的Hypothesize阶段，要求你用IF-THEN-BECAUSE的句式来表达。这本身就是一种强大的问题澄清术。当 Agent 输出第一个假设：“IFper_device_train_batch_size=2is used, THEN training throughput is suboptimal BECAUSE GPU utilization is only 35% (observed via nvidia-smi dmon)”，你突然发现，你原来的问题根本不是“模型不准”，而是“硬件没吃饱”。这个认知的跃迁，是任何自动化都无法替代的，它源于 Agent 对工程逻辑的刚性要求。

6.2 层面二：从“经验传承”到“可验证知识”

资深工程师的“经验”，常常是模糊的、情境化的、难以言传的。比如，“在 A100 上，r=12通常比r=8更稳，但要看数据量”。这种说法无法被新人复现，也无法被代码检验。而 Agent 的每一次Synthesize，都在生成一条可验证、可审计、可共享的知识。它写入knowledge/llamafactory_rules.json的，不是一句感想，而是一条结构化的事实：

{ "key": "lora_r_a100_stability", "description": "On A100-40GB with datasets > 10k samples, r=12 shows lower loss variance than r=8.", "evidence": [ {"experiment_id": "exp_20240515_001", "dataset": "law_qa_zh", "samples": 12478, "loss_std": 0.021}, {"experiment_id": "exp_20240515_002", "dataset": "law_qa_zh", "samples": 12478, "loss_std": 0.038} ], "last_updated": "2024-05-15T14:22:01Z" }

这条知识，可以被团队里的任何一台机器上的任何一位 Agent 读取、质疑、并用新的实验去更新。它把个人的、隐性的“经验”，转化成了组织的、显性的“资产”。这正是 Karpathy autoresearch 项目最核心的遗产：将研究过程本身，变成可复用、可积累的基础设施。

6.3 层面三：从“单次任务”到“持续进化系统”

最让我兴奋的，不是 Agent 能帮我调好一个模型，而是它如何让整个微调流程变成一个活的、呼吸的、自我进化的系统。想象一下这个场景：你部署了一个面向客户的法律问答服务。每天，用户的真实 query 会沉淀为新的feedback_data.json。一个后台 Cron Job 会定期触发 Agent，给它一个新的initial_task：“分析过去 24 小时的用户反馈，找出模型表现最差的 3 个问题类型，并为它们生成针对性的微调配置”。Agent 会：

• observe_state：拉取最新的feedback_data.json和线上模型的model_card.json；
• hypothesize：生成假设，如“IFinstruction中包含‘赔偿金额’一词，THEN 模型倾向于给出模糊回答 BECAUSE 训练数据中缺乏具体数字案例”；
• experiment：用feedback_data.json的子集快速微调一个mini_model；
• synthesize：将mini_model的 A/B 测试结果，写入知识库，并触发一个update_production_pipeline工具，自动将新配置合并到主训练流水线。

这个系统，不再需要你手动监控、手动分析、手动发起训练。它自己感知、自己诊断、自己修复。它把“微调”从一个季度一次的大型项目，变成了一个每小时都在发生的、细粒度的、数据驱动的持续优化过程。这，才是 LLM Agent 真正的终局——它不是一个工具，而是一个数字孪生的、永不疲倦的、永远在学习的微调工程师。

我在实际使用中发现，最大的收益往往不在技术层面，而在心理层面。当我不再需要为一个r值纠结半小时，我的注意力就能完全聚焦在更高维的问题上：这个法律问答的边界在哪里？哪些问题是模型永远不该回答的？如何设计一个让用户信任的拒绝机制？Agent 解放了我的手和眼，却把我的大脑，推向了更本质、更富创造性的领域。这或许，就是 Karpathy 所说的“autoresearch”最动人的地方：它不是让我们失业，而是让我们终于有机会，去做只有人类才能做好的事。