SofaGenius 是一个 AI 研究助手 — 你在聊天框里说一句话，
它就帮你跑模型训练、看实验数据、找数据集，全程不需要写一行代码。
这个页面带你看看，这件「躺着就能干」的事情背后到底是怎么运转的。
从你的浏览器到 GPU，一共要穿过七层楼。点击任意一层，看看它在干什么。
你打开网页，看到一个聊天界面。左边是对话区，右边是可视化卡片区。你说一句话，比如「帮我训练一个代码生成模型」，消息就发出去了。
前端用 React 19 写的，部署在 Vercel 上。聊天消息通过 SSE（一种实时推送技术）流式传回来，所以你能看到 Agent 一边思考一边打字。
每次你登录，Supabase 帮你验证身份（用 JWT token）。你的对话历史、可视化卡片、W&B / HuggingFace 的密钥，全都存在 Supabase 的 PostgreSQL 数据库里。
这样你关掉浏览器再打开，之前的对话还在。就像 iCloud 自动同步。
这是整个系统的大脑。你的消息先经过一个轻量级分类器（Claude Haiku），判断你想干什么：看实验数据？找数据集？还是训练模型？然后把任务分配给对应的专家 Agent。
每个 Agent 手里都有一套「工具」— 比如训练 Agent 可以调用 Modal 的 GPU，数据 Agent 可以用 SQL 查数据集。Agent 会自己决定用哪个工具、传什么参数。
当 Agent 决定要训练模型，它不是在你的电脑上跑 — 它会叫 Modal 帮忙开一台带超强 GPU 的云服务器。训练跑完，服务器自动关掉，只收你用了多少秒的钱。
一个 sanity check（1 步训练）大概花 $0.01，几秒钟搞定。完整训练可能要 $3-10，跑 1-3 小时。
GPU 开好了，但还需要「训练框架」来指挥 GPU 干活。Unsloth 负责加速模型加载和 LoRA 适配，TRL（HuggingFace 的训练库）提供 SFTTrainer 和 GRPOTrainer 来跑不同训练方法。
SofaGenius 支持两种训练方法：SFT（照着标准答案学）和 GRPO（用奖励信号自己找最优解）。两种方法都用 LoRA — LoRA 不是某种训练方法，而是一种省显存的技术，SFT 和 GRPO 都通过 LoRA 来高效地更新模型参数。
训练完成后，模型的「毕业成果」（权重文件）会上传到 HuggingFace Hub — 这是 AI 界的 GitHub，全世界的研究者都在上面分享模型和数据集。
训练用的数据也是从 HuggingFace 上下载的。SofaGenius 的 Scout Agent 还能帮你在上面搜合适的数据集和模型。
vLLM 是一个高性能推理引擎，让训练好的模型跑得飞快，用来做评估和实际部署。
Weights & Biases (W&B) 是实验记录本 — 训练过程中的每一步 loss 值、reward 变化都会实时记录，SofaGenius 的 Training Agent 可以帮你分析这些曲线，发现异常（比如 loss 突然飙升 = 训练炸了）。
就像团队群聊里的协作接力 — 每个服务负责一段，完成后交棒给下一个。
lilyzhng/uigen-ui-code-gen 这份数据训练一个代码生成模型，用 GRPO 方法。
propose_training(method="grpo", task_type="ui_generation", run_mode="overfit")
grpo-ui-genexp 模式（50 步 / 100 条数据），验证模型确实在学习。你说一声我就安排。
analyze_run_health()...Orchestrator 听懂你的意图后，把任务交给对应的专家。每个 Agent 手里有自己的工具箱。
为什么这样设计？怎么加新功能？这一节给你看看「引擎盖下面」的设计决策。
核心区别在于一个问题：你能不能写出代码来自动判断模型的输出好不好？
举个例子：训练模型生成 React UI 代码。SFT 只能学到训练数据里那些 UI 的写法。GRPO 可以用 5 个奖励函数来引导：代码写完了吗？括号配对了吗？有交互逻辑（useState/onClick）吗？引号闭合了吗？长度合适吗？模型可能会发现训练数据里没有的、但奖励更高的写法。
当你说「帮我训练一个代码生成模型」，Launch Agent 不会直接开始训练。它会先在内部走一遍结构化推理链（Reasoning Chain），像一个资深 ML 工程师一样帮你分析：
这就像去看医生：你不需要知道该吃什么药，医生会根据你的症状来判断。Training Advisor 把 ML 决策的门槛从「需要了解 SFT/GRPO 的原理」降低到「说一句话描述你想干嘛」。
系统用了一个叫 _GRPO_TASKS 的注册表 — 每种 GRPO 任务只是一个字典，声明 5 个东西：
比如你想加一个新任务 "math_reasoning"（训练模型做数学推理），步骤是：
写奖励函数 — 在 backend/modal_app/ 里新建一个文件，定义 reward functions。比如 _answer_correct_reward（答案对不对）、_step_validity_reward（推理过程合法吗）。
注册到 _GRPO_TASKS — 在 app.py 的注册表里加一个 "math_reasoning" entry，指向你刚写的函数。
加默认参数 — 在 modal_launcher.py 的 _GRPO_TASK_DEFAULTS 里加一行："math_reasoning": {"max_completion_length": 1024, "wandb_project": "grpo-math"}。
就这么多。不需要改 Agent 代码、不需要改前端、不需要加新 API。用户说「帮我用 GRPO 训练 math reasoning」，Agent 会自动调用 propose_training(method="grpo", task_type="math_reasoning")。
加新 Agent 也一样简单：在 backend/agents/ 里写一个新文件（定义 SYSTEM_PROMPT + TOOLS），然后在 orchestrator.py 的 _AGENT_MAP 里加一行注册就行。整个系统的扩展点都是字典/注册表，不需要改核心代码。
这是一个强制性的安全网。不管 SFT 还是 GRPO，Agent 都会按这个顺序走：
每步都需要用户手动批准（Human-in-the-loop），Agent 不会自己跳到下一步。这样你花 $0.01 就能发现配置问题，而不是直接烧 $10 发现数据格式不对。
训练完模型不等于完事了 — 你怎么知道它变好了而不是变傻了？评估就是给模型「考试」。
为什么需要评估？ 训练只管「教」，评估才管「考」。你训练了一个代码生成模型，loss 下降了，但 loss 低不代表模型真的写得好 — 可能它学会了格式但逻辑全错，或者在训练数据上表现很好但遇到新问题就傻了（过拟合）。 评估帮你回答一个核心问题：模型在真实任务上到底行不行？
不只测模型本身，而是测「模型 + 工具调用 + 多步推理」的完整 Agent 能力。给 Agent 真实任务（比如修 GitHub 上的 bug），看它能不能搞定。
学术界通用的「标准化考试」。只测模型，不涉及工具调用。结果可以跟其他模型直接对比（排行榜上的分数就是这么来的）。
两个框架可选：
lm-eval-harness — 经典框架，分数可发论文
lighteval — HuggingFace 出品，用 vLLM 加速，跑得更快
标准基准测不了的东西，自己设计考试。比如 UI 代码生成：让模型写一段 React 代码，用 Playwright 浏览器截图，再让 VLM（视觉大模型）做裁判打分。
核心能力：
为什么用 VLM 当裁判？ 因为有些质量维度（「这个 UI 看起来好不好」「布局合不合理」）没法用规则代码判断。 VLM 可以「看」截图，像人类一样评价视觉效果。评分维度可以按领域定制 — 电商网站关注转化率设计，医疗界面关注信息可读性。
get_eval_results 工具从 W&B 拉取分数，生成 Eval Card 展示在右侧面板。
SofaGenius 站在这些服务的肩膀上。免费额度能撑很久，需要升级的时候再花钱。
第一次见到这些词？正常。每个都用人话解释一遍。
概念之间的关系： 微调（Fine-tuning）是总称，SFT 和 GRPO 是两种具体方法。 LoRA 是一种省显存的技术，SFT 和 GRPO 都用它来高效更新参数，训练出来的小参数叫 Adapter。 训练跑在 GPU 上（用 Gradient Checkpointing 省内存），过程中会产生 Loss（两种方法都有）和 Reward（只有 GRPO 有）。 训练完的模型用 vLLM 跑推理。前端通过 SSE 实时看到 Agent 的回复。