让 AI Agent 接管云 GPU 微调：工具接入、分工边界与知识沉淀
结论先行
这篇文章记录一次真实经历：我没有本地 GPU，于是尝试让 AI Agent（Claude Code / opencode 这类编码代理）直接驱动云端 GPU 完成 LoRA 微调——从开机器、装环境、跑训练到拉结果。
结论有三条：
- 平台选择的真正成本不是”卡贵不贵”，而是”算力费用 + agent 接入摩擦”。 免费的卡如果 AI 接不上，反而更贵。
- 让 agent 干脏活，但根因定位与防呆必须由人把关。 否则它会把你的坑重踩一遍——我确实又踩了一遍。
- 把一次踩坑变成可复用资产：通用经验做成 Agent Skill，项目细节进知识库。
Stage 1：工具接入——先让 AI 能把机器开起来
三平台对比
我实际比较了三个平台。关键差异不是有没有 API，而是 agent / MCP 的接入程度：
| 平台 | 成本 | AI / MCP 接入 | 适合什么 |
|---|---|---|---|
| Kaggle | 免费 T4（周配额） | 有官方 MCP，可用于代码调试；但依赖与训练框架版本强耦合，T4 无 bf16 | 免费跑通、验证流程 |
| ModelScope DSW | 免费 GPU | 没有环境调试的 MCP，只能自己调 API；改用 browser-use / computer-use 则 token 成本爆炸 | 人类手动可用，AI 不可控 |
| CompShare（优云智算 / 优刻得） | 约 ¥2/h（单卡 RTX 4090 24G） | 官方 CLI + Skills、真 SSH，可脚本化，摩擦 ≈ 0 | 让 AI 直接控、快速迭代 |
为什么”便宜的卡”反而更贵
一句话：总成本 = 算力 ¥ + agent-token 摩擦。
- Kaggle 免费，但 kernel 是提交式的，环境依赖和训练框架版本强耦合，改错一次就要等配额排队；而且 T4 是 Turing 架构，没有 bf16 张量核——用 bf16 会退回 FP32 GEMM，实测步时 69.7s vs fp16 的 21.0s（bf16 慢 3.3×），所以只能退回 fp16。
- ModelScope 免费，但它的 agent 接口不可脚本化。没有可用的”环境调试 MCP”，就只能自己调 API；再退一步用浏览器 / computer-use 去点，token 花费直接失控。实测探索烧掉的 token 价值，远超 CompShare 那点钱。
- CompShare 要花钱，但它提供官方 CLI/Skills 与真正的 SSH 会话，agent 可以像操作本地机器一样操作实例。接入摩擦 ≈ 0，这才是它值钱的地方。
这段决策记录在项目 ADR-0006。它教会我一件事：给 AI 选工具时，要把”接入成本”当成一等公民，而不是只比价格表。
Stage 2：分工边界——三道闸 + 一张安全网
这是我这次最重要的教训。
事故：三个模型白训
我让 AI “照着 Kaggle 上 LLaMA-Factory 的配置，改成 CompShare 4090 + Unsloth（fp16 → bf16）”。
问题出在框架语义不能平移：
- LLaMA-Factory 的 SFT 默认就是 masked（只在回答上算 loss）；
- Unsloth 不是，它需要显式调用
train_on_responses_only之类的方法才会做响应掩码。
AI 没有去读 Unsloth 的文档，直接按”改个精度参数就行”的默认写法开训。结果：没有掩码、chat 模板也没对准。这意味着它其实在学”续写整段 prompt”，而不是学”抽取 JSON”——三个尺寸（0.6B / 1.7B / 4B）全部作废，重训。
更早还有一次相似的坑：LLaMA-Factory 在 Kaggle 镜像上静默 exit 0，没有 traceback、没有 loss，看起来”正常结束”。我一度判断是”镜像与框架版本不兼容”，后来把训练日志重定向到文件才看到它其实停在 Trainer.__init__ 中途；真正的原因是几条配置遗漏：CUDA_VISIBLE_DEVICES 与框架的多卡探测互相打架、yaml 少了 do_train: true、少了 report_to: none；再用干净环境 pin 住版本矩阵才解决。
这两次失败的共同点：不是 AI “笨”，而是我把”动手”和”判断”一起交出去了。
从失误里长出来的框架
AI 在协作里会以三种方式失灵，所以要分层设闸：
| 层 | AI 的失灵 | 控制手段 |
|---|---|---|
| 闸 1 · 研究闸（动手前） | 不知道、不问就做、从零造轮子 | 先读目标框架 / 版本矩阵 / 社区；跨框架移植先核对损失与模板语义；禁止默认开写 |
| 闸 2 · 验证闸（花钱前） | 跑偏、静默跳过关键参数 | dry-run + 极小规模 anchor 对照 + 机器可验证据（如 mask_check 不能全是 -100、format_check 通过） |
| 闸 3 · 放行闸（人把关） | 代价外溢（长时间 / 大钱） | 昂贵训练前，人 review 配置与证据后才放行 |
| 安全网（出错后） | 返工不可控 | checkpoint 早存勤存 + 小步提交，把返工损失封顶 |
注意最后一条：checkpoint 不是正确性闸，它是成本保险。 它的作用不是阻止错误，而是让错误发生时的损失有上界。我训 1.7B 时就因为唯一的保存点正好是崩溃点，白白丢掉 38 分钟；把保存间隔调小之后，同样的崩溃只值 12 分钟。
Stage 3：知识沉淀——把经验变成 AI 能复用的资产
一次项目做完，最有价值的不是结果，而是流程与易错点。但它们不该都塞进 prompt。我把它拆成三处：
- 通用流程 → Agent Skill（放”怎么做”）。 比如”动手前先判断要不要调研””同类目标失败三次就停手调研””checkpoint 怎么设计””昂贵运行前怎么设闸”。这次我把它们各自落成了小 skill：
research-first、checkpoint-design、expensive-run-gates、decision-design。
关键原则：不要从零造。 GitHub 上已有大量成熟的 skill 实现，先参考再裁剪，比自研更稳。 - 项目事实 → Agent 知识库（放”是什么”）。 本项目的版本矩阵、错误目录、数据事实、结果数字，塞进 skill 只会让它无限膨胀。我现在用一个 Markdown 单源、有界索引 的 agent 知识库：根索引只列域，正文原子化，索引由脚本生成；刻意先不上向量库——先用索引 + 文本检索，把 FTS5 / embedding 留成有明确触发条件的扩展窗口。
- 个人长期笔记 → 人用的工具，与 agent 知识库分开。 我也有 Obsidian 存个人笔记，但那是给我看的、不是给 agent 检索的；两者职责不同，不必强行合并。
一个反直觉的点：同样的内容放 skill 还是放知识库，取决于它是”怎么做”还是”是什么”。 放错地方的代价，是 skill 越来越长、知识库越来越空。
这套做法本身就是从踩坑里长出来的：我早先的全局 AGENTS.md 里塞了两条协议（强制调研、长驻进程），后来发现——规则该留在 AGENTS.md 当”绊线 + 闸门”，流程方法则全部下沉到 skill。把个人的痛，变成 agent 下一次的默认行为。
总结与复盘
学到了什么
- 微调的完整流程：数据处理、tokenizer、训练参数、响应掩码、chat 模板、checkpoint 设计。
- 与 AI 协作的关键：接好外部工具、把关键节点留给人、token 要省着花。
- 一次真实的工程决策：平台选择的成本函数、跨框架移植的语义陷阱、静默失败的排查。
遗憾与建议
- 我一开始忘了这个项目只是”熟悉流程 + 简历项目”，在容量曲线上投入了过多成本和时间，评测反而做得晚了。更合理的顺序是：先用最小验证跑通流程，评测优先，再谈规模。
- 如果重来，我会先训 0.6B 并与已知结果对比，用最低成本确认整条链路成立，而不是一上来就铺满三个尺寸。
项目与证据：github.com/Alex-tangt/kg-triplet-sft
相关决策：ADR-0005（训练管线与复现解耦）、ADR-0006（算力平台与 bf16 曲线）。
这是”AI 协作”系列的第一篇。后续会写 GraphRAG 与图知识库、模型微调与评测方法等专题。