1. ChatGPT Pro 今天 15:40 Macaron-V1既然是开源的。我是否可以挂在 fireworks或者model平台上复现。然后这个训练数据怎么来？？我能蒸馏比如说k3么。反正k3也是开源的，还在特定领域达到k3的部分能力。然后需要多少数据呢。然后这个是训练和使用是分开的么还是说可以使用中训练。或者一个用户一个微调版本。还是说这个训练针对所有用户。我对落地还是很迷糊官方提供的api能干么比如就拿陪聊场景好啦我想让角色更好的记忆到用户，用这个Macaron具体该怎么用比以往直接用基座模型有哪些好处，有哪些不同。思考了 11m 24s [模型:gpt-5.6-pro] 截至 2026 年 7 月 31 日，我的核心判断是： Macaron-V1 可以复现“推理和架构”，但目前不能完整复现官方训练结果。你也可以用 K3 开放权重做特定领域蒸馏，但陪聊产品不应该靠“一个用户一个完整 LoRA”来记忆用户。正确组合是：共享的陪聊 LoRA + 外部长期记忆库 + 周期性持续训练。而且有一个特别容易混淆的地方： Macaron 的 MoL 解决的是“能力模块化”，不是“用户记忆持久化”。一、你说的“复现”，其实有三种 1. 复现 Macaron-V1 的推理：可以目前官方开放了： Macaron-V1-Venti / Tall 权重 L0 Chat、L1 Agent、L2 Coding、L3 GenUI 四个 LoRA Mixture-of-LoRA Harness 路由 Prompt、摘要 Prompt、状态管理代码 OpenAI 兼容的 Chat Completions 和 Responses API Tall 是一个 Qwen3.6-35B-A3B 基座，加四个 Rank-64 LoRA；官方把它描述为约 50B 的整体系统。Venti 则是 744B GLM-5.2 基座，加四个约 1B 的 LoRA。每次请求先由 L0 判断交给哪个专家，然后目标 LoRA 回答，再生成一个跨 LoRA 的内部摘要。所以你可以下载权重和 Harness，自己在 Modal、裸 GPU 集群或其他支持 vLLM/SGLang 的环境运行。 2. 复现 Macaron-V1 的完整训练结果：目前不行开源的并不是：原始训练集全部用户反馈数据完整奖励函数 LivingBench 训练数据完整过滤规则所有训练超参数 MindForge 生成的轨迹官方完整测试集和实验日志官方目前只解释了大体路线：从真实用户需求、Macaron App 对话、用户反馈和修正中构建任务，再通过 Discovery → Expansion → Update 的递归自改进流程产生新任务、轨迹和训练数据。完整技术报告和完整基准方法仍标为“即将发布”，开源 Harness 仓库也明确说没有包含日志、实验补丁和测试套件。因此你能做的是：复现 Macaron 的方法论和服务框架，训练出自己的 Macaron-like 模型，而不是按官方数据一比一复刻官方分数。 3. 在其他基座上复现 Macaron 架构：完全可以 Macaron 的核心并不依赖某个神秘模型结构，本质上是：冻结的共享基座 ├── L0：聊天与路由 ├── L1：Agent / 工具调用 ├── L2：编程 ├── L3：生成式 UI └── L4：你自己的陪聊专家你完全可以做成： Qwen3-30B-A3B ├── L0 Router ├── L1 Companion ├── L2 Tool Agent └── L3 Memory Manager 这不再是官方 Macaron-V1 权重，但保留了它最有价值的 MoL 思路。二、挂在 Fireworks 或 Modal 上，哪个更合适下面我按你说的 “model 平台” 是 Modal 来理解。方案可行性适合做什么 Macaron 官方 API 很高最快验证模型效果 Modal 很高最忠实地复现官方 Harness Fireworks 中高多 LoRA 生产部署，但需要自己补路由代理自建 GPU 高最大控制权，运维最重 Modal：最适合做忠实复现 Modal 可以直接运行任意 Python/Docker 服务，也有官方 vLLM、SGLang 和超大模型多 GPU 部署示例。因此你可以把官方架构近似原样放进去：外部请求 ↓ Macaron MoL Proxy ↓ vLLM / SGLang ↓ L0 / L1 / L2 / L3 官方 Harness 当前写死的生产配置要求 8 张可见 GPU，Tall 和 Venti 的参考启动脚本都是 TP8；Modal 也提供了 2、4、8 张 H200/B200 部署超大模型的模式。我的建议是：只考虑 Tall，不要一开始碰 Venti 先缩短最大上下文先只挂 L0 + 你自己的 Companion LoRA 编程和 GenUI LoRA 暂时不加载验证有价值后再扩展成完整 MoL 否则一上来就是 8 GPU、四 LoRA、长上下文和三阶段内部调用，成本与复杂度都过高。 Fireworks：可以部署，但不是上传后自动变成 Macaron Fireworks 支持：上传自定义 Hugging Face 模型上传外部训练的 LoRA 一个基座挂多个 LoRA 每次请求动态指定 LoRA 但外部 LoRA 目前只能用于 dedicated/on-demand 部署，不能直接放在普通 Serverless；Multi-LoRA 还要求 BF16 部署，FP8/FP4 部署不能动态挂载 Adapter。 Fireworks 帮你完成的是：共享基座 + 动态选择某个 LoRA 它不会自动替你完成 Macaron 的： L0 路由 → 目标 LoRA 回答 → 隐藏摘要 → 分专家上下文管理 → Tool-call stickiness 因此真正的结构会是：你的 Macaron Proxy ↓ Fireworks Base + Multi-LoRA Deployment 还有一点：Tall 的 Rank-64 位于 Fireworks 支持范围上限，但 Qwen3.6 MoE 和具体 target_modules 是否能直接通过其模型验证器，仍需要实际上传验证或联系 Fireworks 开通。不能把它视为百分之百一键部署。最现实的顺序第一阶段直接调用 Macaron 官方 API验证效果；第二阶段在 Modal 复现 Tall 或更小的 Macaron-like 架构；到了有稳定流量、需要多 LoRA 共享算力时，再迁往 Fireworks dedicated。三、训练数据到底从哪里来官方没有放出完整 Macaron-V1 数据集，但已经披露了数据来源类别： Macaron App 里的真实用户需求。用户对话、反馈和修正。 LivingBench 中模拟的动态用户、动态环境和带噪声工具。模型自己生成更难任务，再验证、过滤和训练。公共对话数据与结构化任务数据。官方公开得最具体的是 A2UI 子模型：它使用 MultiWOZ、SGD、ESConv 和 AnnoMI，采样 4,306 个基础对话，形成了 14,245 个 assistant-turn 训练样本，然后先做 SFT，再做 GRPO。注意这只是一个非常窄的“生成式 UI”能力，不代表整个 Macaron-V1 只有一万多条数据。对于陪聊，你的数据应该分成四类。 1. 角色和聊天风格数据训练：角色说话方式回答长度幽默感情绪表达是否主动追问什么时候沉默如何表达不同意见如何处理冲突与冷场这些可以由人工编写一小批种子，再让教师模型扩展。 2. 长期记忆行为数据这不是简单地把“Luke 喜欢网球”放进训练集，而是训练模型：什么时候应该回忆什么时候不应该主动提起新信息和旧记忆冲突时怎么办用户改变偏好后如何覆盖旧信息如何区分明确事实与模型推测如何避免把 A 用户的记忆泄漏给 B 用户如何询问用户是否允许保存敏感信息例如一条训练轨迹可以跨越模拟的三个月：第 1 天：用户说自己不喜欢太甜的饮料第 8 天：用户点了无糖咖啡第 24 天：用户说最近开始喜欢少量蜂蜜第 60 天：用户问“你还记得我喝咖啡的习惯吗？” 模型要回答当前有效偏好，而不是机械复述最早信息。 3. 偏好对比数据同一个问题生成两个答案： Chosen：自然地用到了相关记忆，但没有刻意炫耀“我记得你”。 Rejected：突然列出用户过去的全部隐私信息，让人产生被监视感。这些数据用于 DPO，比单纯 SFT 更适合优化陪聊中的“分寸感”。 4. 真实产品数据上线后最有价值的是：用户主动纠正模型的地方用户删除了哪些记忆哪些回复被重试哪些回复之后用户继续聊了很久哪些主动回忆让用户反感哪些回复被点赞、收藏或分享必须经过用户同意、脱敏和权限隔离。尤其陪聊涉及关系、健康、家庭和情绪信息，不能默认把所有聊天记录送去训练。四、蒸馏 K3：可以，但要分清“权重”和“API” 使用 K3 开放权重：原则上可以 K3 的开放权重许可明确允许：使用修改微调创建衍生作品部署和销售但有收入、MaaS 和品牌展示方面的附加条件。所以相对稳妥的方式是：自己托管 K3 权重 → 用 K3 生成和评判陪聊数据 → 训练 Macaron Tall / Qwen 学生模型你不可能用少量数据把一个 35B 学生完整蒸馏成 K3，但可以让它在一个非常窄的领域逼近、甚至在你的自定义评测上超过 K3，例如：中国年轻用户的陪聊节奏长期关系记忆动漫角色扮演情绪陪伴中的语言分寸基于用户历史的主动关怀中文口语自然度因为 K3 是通用模型，而你的学生模型可以把容量集中在这一小块。直接调用 Kimi 官方 API 批量蒸馏：不建议 Kimi OpenPlatform 当前服务条款明确禁止未经授权使用其服务开发具有潜在竞争性的模型、产品或服务。也就是说，虽然 API 输出归属条款没有简单写成“禁止一切训练”，但批量调用 API 构造蒸馏数据集存在明显合规风险。所以需要区分：教师来源是否适合蒸馏自托管 K3 开放权重可以，遵守 K3 权重许可明确允许蒸馏的第三方 K3 托管商可以，先看服务条款 Kimi 官方 API 未经授权不建议用户真实数据必须取得同意并做好脱敏五、到底需要多少数据以下是我的工程估算，不是 Macaron 官方数字。这里的“一条轨迹”指一段完整多轮对话，而不是一句问答。目标建议数据量大致能得到什么明显改变口吻和角色 1,000–5,000 条高质量对话角色感明显，但容易过拟合做出可用的陪聊 MVP 5,000–20,000 条多轮轨迹基本角色、情绪回应和记忆策略稳定的垂直陪聊模型 20,000–50,000 条轨迹 + 5,000–20,000 对偏好数据更稳定的长期互动和边界控制逼近 K3 的某一窄能力切片 50,000–200,000 条过滤后的轨迹有可能在自定义领域评测逼近或超过教师完整替代 K3 通用能力远不止上述规模基本不现实换算成 Token，一个比较认真的陪聊专项训练通常会落在：初步实验：约 500 万–2,000 万 Token 可用版本：约 2,000 万–1 亿 Token 较成熟版本：约 1 亿–10 亿 Token 但最重要的不是数量，而是覆盖。10 万条高度重复的“安慰你、抱抱你”远不如 1 万条包含冲突、遗忘、偏好变化、隐私边界、冷场和长期回忆的数据。合理的训练顺序是： SFT：先学会基本角色、格式和记忆行为 ↓ DPO：学会什么回答更自然、更有分寸 ↓ RL / GRPO：只在奖励函数可靠后使用对陪聊而言，RL 最难的不是训练代码，而是定义奖励。模型不能为了提高“用户聊天时长”而诱导依赖、制造焦虑或故意阻止用户离开。六、训练和使用是分开的，还是可以边用边训练权重层面：训练与推理通常是分开的正常生产流程应该是：稳定版本 v1 正在服务 ↓ 收集经过同意和脱敏的新数据 ↓ 异步训练候选 LoRA v2 ↓ 离线评测 ↓ 小流量灰度 ↓ 通过后替换 v1 MinT 所说的“异步训练”是训练任务和采样任务由远程 GPU 执行，并不表示每收到一条用户消息就立即修改模型权重。MinT 提供 SFT、DPO、RL、LoRA 管理、评测和版本化，但仍然是可控的训练—验证—部署流程。记忆层面：可以在使用中立即学习用户说： “我不喜欢别人叫我老板，叫我 Luke 就行。” 系统可以立刻写入数据库： { "user_id": "u_123", "type": "explicit_preference", "key": "preferred_name", "value": "Luke", "confidence": 1.0, "source_turn": "t_938", "updated_at": "2026-07-31", "sensitive": false } 下一句话就能生效，不需要训练。因此“使用中学习”有两个速度：即时学习：写入用户记忆数据库慢速学习：周期性训练和发布新 LoRA 这才是最可靠的持续学习系统。七、是不是一个用户一个微调版本官方 Macaron 的 LoRA 不是按用户划分的它的 L0、L1、L2、L3 是：所有用户共享的能力模块 Chat、Agent、Coding、GenUI 四种专家不是用户 A、用户 B、用户 C 各自一个版本更重要的是，官方 Tall 的每个 LoRA 被描述为约 3.7B 参数。即使按 BF16 粗略计算，一个 Adapter 也可能达到数 GB。这样的 LoRA 根本不适合“一百万用户各存一个”。所以实际产品应该采用：共享基座模型 ↓ 全体用户共享的 Companion LoRA ↓ 可选：不同角色/人群共享的 Segment LoRA ↓ 每个用户自己的外部记忆和关系状态例如：全局 Companion LoRA ├── 二次元角色 Adapter ├── 温柔朋友 Adapter ├── 英语陪练 Adapter └── 情绪支持 Adapter 每位用户： ├── 个人资料 ├── 长期偏好 ├── 事件记忆 ├── 关系状态 └── 未完成话题只有非常重度的付费用户，在拥有数百条明确偏好信号和数千轮有效对话后，才值得试验一个极小的用户专属 Adapter。即使如此，也应优先训练“交互习惯”，而不是把用户事实写进权重。原因是用户事实需要：能修改能删除能查看来源能处理过期能撤回授权能响应隐私删除请求写进模型权重后，这些事情都很难做。八、拿陪聊场景来说，Macaron 具体怎么用推荐架构用户消息 ↓ 记忆提取器 ├── 是否包含新事实 ├── 是否为明确偏好 ├── 是否敏感 ├── 是否覆盖旧事实 └── 是否需要征求保存许可 ↓ 用户记忆库 ├── Profile Memory：稳定资料 ├── Episodic Memory：发生过的事件 ├── Relationship State：关系和交流状态 └── Open Loops：以后需要追问的事情 ↓ 记忆检索器 ├── 相关性 ├── 时间新旧 ├── 重要性 ├── 可信度 └── 隐私权限 ↓ Macaron L0 Router ├── 普通陪聊 → Companion LoRA ├── 查天气/订票 → Agent LoRA ├── 生成互动卡片 → GenUI LoRA └── 普通短答 → Chat LoRA ↓ 回答 ↓ 反馈与训练数据池你可以在 Macaron Harness 中增加一个： L4 Companion 它学习的是：如何使用检索到的用户记忆如何自然地回忆过去如何维持角色一致性如何处理偏好变化如何保持合适的亲密度如何识别需要调用提醒、日历或搜索工具的时刻而外部记忆作为 Context 注入：用户希望被称为 Luke。用户更喜欢自然、连续的中文表达，不喜欢过多模板化列表。用户开始研究 Macaron-V1 和持续学习。之后可以追问用户是否已经测试 Macaron 官方 API。并在系统提示中约束：只有与当前话题直接相关时才能引用记忆。不要为了证明“你记得用户”而主动展示大量历史信息。推测性记忆必须以不确定表达呈现。当新信息与旧记忆冲突时，以更新、更明确的信息优先。敏感信息不得在用户未主动提及时重新提出。九、官方 Macaron API 能为陪聊做什么官方已经提供标准的 OpenAI 兼容接口，可以直接调用 Macaron-V1-Tall 或 Venti；请求格式就是普通 /v1/chat/completions。官方 Harness 还提供 /v1/responses，可以通过 previous_response_id 延续代理中的会话状态。它能帮助你：测试 Macaron 的聊天质量测试 L0/L1/L2/L3 自动路由使用工具调用测试个人 Agent 任务测试 GenUI 快速和 K3、Qwen、GLM 做 A/B 测试但它不会自动：连接你的用户数据库为每位用户永久保存语义记忆根据每次聊天自动微调自动生成一个用户专属 LoRA 让你直接上传一个自定义 L4 Companion 自动满足用户的查看、修改、删除记忆需求 Chat Completions 本身是无状态的，需要客户端重传历史；Responses API 的状态是代理会话状态，也不能等同于完整的跨设备、跨月份用户记忆系统。另外，Macaron 推理 API 和 MinT 训练 API 要分开理解： Macaron API：调用已经训练好的模型。 MinT：远程训练 LoRA、做 SFT/DPO/RL、保存和部署 Checkpoint。当前 MinT 社区版公开支持的主要是 Qwen3 0.6B、4B、30B、235B；企业版列出了 GLM-5/5.1、Kimi-K2/K2.5 和 DeepSeek-V3。K3、Macaron-V1-Tall 和 Venti 尚未列为社区自助训练基座，因此精确训练官方 V1 目前大概率仍要联系其企业团队申请容量。十、Macaron 比“直接用一个基座模型”好在哪里维度单一基座 + Prompt Macaron MoL 聊天、编程、Agent 混合训练容易相互干扰分别放入不同 LoRA 增加新能力重新微调或合并权重新增一个 Specialist 部署复杂度低高单次请求成本较低路由、回答、摘要可能多次调用长期用户记忆仍需外部记忆库仍需外部记忆库多角色版本多套 Prompt 或多模型多个 LoRA 共享基座回滚某项能力较难可单独替换 Adapter 能力冲突更明显通过参数空间隔离缓解纯陪聊产品通常已经够用可能过度设计陪聊 + 工具 + UI + Agent 容易变乱非常适合 Macaron 最大的优势不是“记住用户”，而是：当产品同时需要聊天、行动、编程、工具和 UI 时，可以让不同能力继续进化，而不必全部挤在同一个微调权重里。如果你的产品目前只是纯文本陪聊，那么：优秀基座 + 一个 Companion LoRA + 外部长期记忆通常比部署完整 Macaron 更简单、更便宜，也很可能效果更好。当产品变成：陪聊 + 订票 + 日历 + 主动提醒 + 搜索 + 生成交互界面 + 执行长期任务 Macaron 的价值才会明显放大。十一、我建议你实际这样落地第一层：先不要训练先用同一套外部记忆系统，对比： A：K3 + Memory B：Macaron API + Memory C：普通 Qwen/GLM + Memory 构建约 200 个虚拟用户，每个用户模拟数十轮、跨多个日期的交互，重点测试：用户事实回忆准确率过时记忆使用率记忆幻觉率不恰当主动回忆率角色一致性对话自然度用户偏好遵循延迟与成本第二层：训练一个共享 Companion LoRA 先不要训练 L0、L1、L2、L3 全套，只训练： Base + Companion LoRA 数据以 K3 自托管生成的数据、人类编写种子、模拟长期对话和真实用户纠错为主。第三层：再引入 Macaron 路由只有当陪聊产品开始包含工具执行时，再引入： L0 Router ├── Companion ├── Agent └── GenUI 第四层：持续学习生产数据进入下面的闭环：用户反馈 → 脱敏和授权 → 聚类失败模式 → 生成补充训练集 → SFT / DPO → 离线评测 → 灰度 → 新 Adapter 上线这才是 Macaron 所代表的真正持续学习：不是模型每说一句话就偷偷修改自己，而是把生产环境中的失败，持续转化为可验证、可回滚的新能力版本。最终最适合你的陪聊架构并不是“一用户一 Macaron”，而是：一个共享基座 + 一个全局陪聊 LoRA + 少量角色/人群 LoRA + 每个用户独立的外部长期记忆 + 周期性蒸馏和偏好训练这条路线既保留 Macaron 的模块化能力，也能真正解决用户记忆、成本、隐私和规模化问题。今天 19:12 Nex-N2-Pro是什么与macaron相比有什么相同和不同值得关注么开源到什么程度是否便于复现我可以学到什么。思考了 10m 32s [模型:gpt-5.6-pro] 先给结论 Nex-N2-Pro 值得高度关注，但它不是另一个 Macaron-V1。两者代表了两条几乎相反、但可以互补的路线： Nex-N2：把搜索、编程、工具调用、环境反馈和纠错，统一训练进一个模型。 Macaron-V1：冻结共享基座，把聊天、Agent、编程、GenUI 拆成多个可独立训练、替换的 LoRA。对你正在关注的“持续学习 + 陪聊 + 用户记忆”来说： Macaron 更适合充当产品架构。 Nex 更适合学习如何造数据、造环境、蒸馏长轨迹。最有价值的组合不是二选一，而是： NexForge 式数据生产 + Macaron 式模块化 LoRA + 外部用户长期记忆我的主观工程评分是：维度评价研究关注价值 9/10 Agent 数据方法价值 9.5/10 Nex-N2-Pro 个人复现难度 2.5/10 Nex-N2-mini / 小模型方法复现 7/10 对纯陪聊的直接价值 5/10 对“会行动的个人 Agent”价值 9/10 一、Nex-N2-Pro 到底是什么 Nex-N2 是 Nex-AGI 推出的 Agent 模型系列： Nex-N2-Pro：基于 Qwen3.5-397B-A17B 后训练，397B 总参数、每 Token 激活约 17B 参数。 Nex-N2-mini：基于 Qwen3.5-35B-A3B-Base，35B 总参数、激活约 3B 参数。两者本身都是 MoE 模型，但这里的 MoE 来自 Qwen3.5 基座，并不是 Nex 新发明的基础架构。它的主要创新并不在“重新设计 Transformer”，而在于： Agent 后训练数据长程可执行轨迹模型与 Agent Harness 的联合设计统一的推理—行动行为模式根据任务动态决定思考深度官方将这一套称为 Agentic Thinking。 1. Coherent Thinking：统一的行动思维它不希望模型在不同任务里变成几套互不相干的模式：搜索：一种思路编程：另一种思路调用工具：又一种思路而是把它们统一成：理解目标 → 分解任务 → 跟踪当前状态 → 选择行动 → 观察环境反馈 → 判断是否成功 → 调整策略 → 验证最终结果这种能力最适合混合任务，例如：先搜索某个库的最新文档，修改代码，运行测试，发现版本冲突，再重新检索解决方案并继续修改。官方强调，搜索、编码和工具调用都遵循目标分解、状态追踪、策略调整和自我校验这一套结构。 2. Adaptive Thinking：自适应思考它还训练模型判断：这一步是否需要显式推理；应该思考多深；什么时候直接调用工具；什么时候应该重新规划；什么时候已经验证充分，可以停止。官方报告称，在 Nex-N2-mini 上，自适应思考相比每轮强制开启 Thinking，大致节省了约 20% Token，同时任务完成率相当或略高。这个数字目前主要来自开发方自己的评测，尚不能当成所有场景都会稳定复现的结论。 3. 它不是什么 Nex-N2-Pro 并不是：使用中自动修改权重的在线学习模型；持久化用户记忆系统；一个用户一个模型；类似 Macaron 的多 LoRA 路由器；完整开放了训练数据和训练配方的“可从零重训模型”。更准确地说，它是：基于 Qwen3.5 大基座，经过大量 Agent 轨迹后训练形成的统一 Agent Checkpoint。二、它与 Macaron-V1 的共同点两者表面架构差异很大，但背后的世界观其实很接近。共同点一：都认为模型能力不只来自基座预训练它们都在押注：强基座 + 真实或合成的环境经验 + Agent 长轨迹 + 工具调用 + 后训练也就是说，下一阶段竞争不只是堆预训练 Token，而是让模型在接近生产环境的 Harness 里不断执行任务、观察结果、纠错和积累经验。共同点二：都重视模型与 Harness 的联合设计 Macaron 明确公开了： Router 每个 Adapter 的独立上下文 Tool-call stickiness 跨 Adapter 摘要 REPL Harness HCP 配置协议并强调训练环境和生产环境要尽量一致。 Nex 也不是只训练一个问答模型，而是把：需求理解 → 规划 → 代码或工具执行 → 环境反馈 → 评估和调试 → 继续迭代连成完整闭环。共同点三：都依赖合成轨迹扩展数据 Macaron 使用 MindForge 做递归自改进；Nex 则有 NexForge、NexGAP 和教师模型轨迹蒸馏。本质上都在做：生成任务 → 执行任务 → 收集轨迹 → 过滤轨迹 → 训练模型 → 发现新失败 → 再生成任务共同点四：都不直接等于“长期用户记忆” Macaron 虽然明确关注 Personal Intelligence 和 LivingBench，但其 LoRA 架构主要解决的是：能力隔离；模块更新；路由；上下文协调。 Nex 主要解决的是：统一推理；环境行动；长程执行。两者都仍然需要一个外部用户记忆数据库，才能可靠地跨月、跨设备记住某位用户。三、两者最根本的不同：统一训练与模块化训练维度 Nex-N2-Pro Macaron-V1 核心哲学把多种 Agent 行为统一训练进一个模型把不同能力拆到多个 LoRA 基座 Qwen3.5-397B-A17B Venti 为 GLM-5.2；Tall 为 Qwen3.6-35B-A3B 模型形式一个统一的后训练 Checkpoint 冻结基座 + L0/L1/L2/L3 LoRA 搜索、编程、工具混合强调同一条轨迹内自然混合先由 L0 路由给某个专家路由位置模型内部学习何时思考、何时行动 Harness 在请求级选择 Adapter 新增能力通常要继续训练新 Checkpoint 可以增加或替换一个 LoRA 回滚能力整体版本回滚可单独回滚某个专家防止能力相互干扰靠数据和联合训练靠 LoRA 参数空间隔离跨领域一致性更强调整体一致的思维模式更强调专业化和模块协作持续学习友好度方法上支持继续训练，但未公开插件式机制架构上明确为插件式持续学习设计 Personal Intelligence 不是主要公开定位是 Macaron 的核心公开方向部署复杂度单模型，但模型极大模型较小或较大，额外增加路由与上下文管理 Macaron-V1 的四个公开专家是： L0 Chat：聊天、指令遵循、路由 L1 Agent：长期任务和工具使用 L2 Coding：编程与终端 L3 GenUI：生成式 UI L0 会为新请求选择专家；后续工具交互会留在该专家内；完成后再生成一份隐藏摘要供其他 LoRA 获取进展。所以两者可以用一句话概括： Nex 想训练出一个会统一行动的“大脑”；Macaron 想建立一个共享大脑上的“技能插件系统”。四、哪一种路线更好没有绝对答案，取决于产品的任务结构。 Nex 路线更适合当任务经常是连续混合的：搜资料 → 看代码 → 修改项目 → 调工具 → 运行 → 调试 → 写报告在这种任务中，频繁切换 LoRA 可能造成：上下文摘要损失；路由错误；专家之间责任边界不清；不同专家对当前状态理解不一致。 Nex 把全部行为训练进一个统一模型，理论上更容易保持完整的行动状态。 Macaron 路线更适合当不同能力有清晰边界，并且更新节奏不同：陪聊能力每周升级编程能力每月升级工具 Agent 单独优化 GenUI 单独实验它的优势是：某个 LoRA 训练失败，不影响其他模块；新能力可以单独部署；能力可以由不同团队训练；能做 A/B 测试；适合大量垂直角色或用户分群；训练成本远低于反复后训练一个 397B 模型。所以对小团队而言： Macaron 更像可维护的产品工程架构；Nex 更像追求统一能力上限的模型工程架构。五、Nex-N2-Pro 开源到什么程度这里要区分“开放权重”和“完整可复现”。 1. 模型权重：开放得很好 Nex-N2-Pro 的 BF16 权重已放在 Hugging Face： 397B 参数； Safetensors； Chat Template； Apache-2.0 许可证；可以商业使用、修改和制作衍生版本；提供函数调用和 Reasoning Parser 的启动方法。这一层可以给 5/5。 2. 推理部署：开放得不错官方提供：定制版 SGLang Fork； OpenAI 兼容推理接口； qwen3 Reasoning Parser； qwen3_coder Tool-call Parser； Docker 启动方式；推荐采样参数。这一层可以给 4/5。扣分原因是，它依赖定制 SGLang，而且当前仍有一些兼容性和镜像可用性问题。GitHub Issues 中也有人在追问 vLLM、MTP 和 Anthropic Messages API 的兼容支持。 3. 主模型训练代码：开放得很有限 Nex-N2 的主 GitHub 仓库目前基本只有： figures/ README.md 没有在该仓库里提供：完整训练代码； Nex-N2-Pro 的训练配置；数据清单；全部教师轨迹；奖励模型；过滤规则； Checkpoint 中间版本；实验日志和消融。这一层只能给 1.5/5。 4. 周边训练生态：比主仓库开放得多 Nex-AGI 另外开源了： NexGAP 端到端 Agent 数据管道，涵盖：创建 Agent → 合成 Query → 执行任务 → 收集 Trace → 转成训练格式它有实际代码、端到端脚本、测试、Dockerfile 和 Apache-2.0 许可证。 NexRL 分布式后训练框架，支持把： Agent 服务； Rollout 服务；推理后端；训练后端；权重同步；拆成相对独立的服务。仓库有训练 Recipe、测试和实际代码，但官方自己也说明，目前仍是基础版本，后续会继续补充模型支持、后端集成和算法实现。 NexAU / NexA4A 用于构建 Agent、多 Agent 和自动生成专用 Agent 的框架，可以配合 NexGAP 产生训练轨迹。因此准确描述应该是： Nex-N2 是“完整开放权重 + 开放一部分全栈工具链”，但不是完整公开训练数据与精确训练 Recipe。它比只扔出权重的项目开放得更多，但距离“从原始数据一键训练出相同 Nex-N2-Pro”仍有很大距离。六、与 Macaron 的开源程度相比 Macaron 的开放重点稍有不同。 Macaron 开放得更完整的地方 Macaron 的 Mixture-of-LoRA Harness 仓库实际包含： Proxy； Router；状态管理； Chat Completions API； Responses API； L0–L3 映射；路由 Prompt；隐藏摘要 Prompt； vLLM/SGLang 启动脚本。而且 Harness 使用 MIT 许可证。因此你更容易理解：一个请求究竟如何从 L0 路由到 L1/L2/L3，又如何在多个 LoRA 之间保存状态。 Macaron 同样没有完全开放的地方 Harness 仓库明确说没有包含：模型权重本身——权重在 Hugging Face 单独发布；训练日志； Benchmark；实验 Patch； Test Suite。完整 Macaron-V1 训练集、MindForge 生成轨迹、过滤和奖励配方也没有全部公开。所以两者的开源差异可以概括为：层级 Nex-N2 Macaron-V1 模型权重很完整，Apache-2.0 已开放权重推理启动较完整较完整核心 Harness 分散在 NexAU 等项目 MoL Proxy 非常明确数据生成方法 NexForge 论文非常具体递归自改进理念较多，完整数据较少通用数据管道 NexGAP 已有代码 MindForge/MinT 部分开放精确训练数据未开放未开放一比一训练复现困难困难小规模方法复现较容易较容易独立团队实际成本 Pro 很高 Tall/小型 MoL 相对低七、Nex-N2-Pro 便于复现吗要看你说的“复现”是哪一层。 1. 把原模型跑起来：技术上容易，经济上困难官方 Nex-N2-Pro 参考部署是： 2 台服务器每台 8×H100 共 16×H100 TP=16 而 Nex-N2-mini 的官方参考部署仍是 2×H100。 Nex-N2-Pro 是 397B BF16，原始参数存储量粗略就是： 397B × 2 bytes ≈ 794 GB 再算上： KV Cache；推理缓冲；通信；长上下文； SGLang Runtime；显然不是单台消费级设备适合运行的模型。所以：有 16×H100：推理复现相对直接。独立开发者：不适合自己部署 Pro。试验方法：应选择 N2-mini，甚至更小的 Qwen 基座。 2. 复现官方 Benchmark：中等困难官方给出了相当多的评测条件，例如： Terminal-Bench 使用 Harbor/NexAU； 256K Context；最多生成 64K Token； 4 小时超时； 5 次运行平均； SWE-Pro 和 SWE-Verified 使用优化后的 Benchmark； GDPval 是内部复现的 GDPval-AA。这意味着公开分数不是简单执行一条 lm-eval 命令就能完全复现。尤其是 Agent Benchmark，最终成绩属于：模型 + Prompt + Harness + 工具 + 上下文管理 + 时间预算 + Token 预算不能把所有提升都归因于裸模型权重。 3. 一比一复现训练：目前做不到缺失的关键内容包括： Nex-N2-Pro 完整训练数据；全部教师模型和采样比例；完整 SFT/RL 阶段；是否及如何全参数训练；数据过滤阈值； Adaptive Thinking 的精确训练目标；奖励函数；训练步数和学习率；中间 Checkpoint；完整消融实验。 NexForge 数据明确只是“参与了 Nex-N2 的训练”，并不等于已经公开了 Nex-N2 的全部数据和配方。 4. 复现它的方法论：可以这一层反而很值得做：小型 Qwen Base + NexForge 式任务生成 + NexGAP 式轨迹收集 + SFT / DPO / RL + NexAU Agent Harness 你不需要复现 397B 的最终分数，也能验证它最核心的研究假设：需求驱动的、带真实环境和长行动轨迹的数据，是否能显著提高一个小模型在特定 Agent 领域的能力。八、NexForge 才是整个项目中最值得你研究的部分我认为，对你而言，NexForge 的价值可能大于 Nex-N2-Pro 权重本身。传统数据构造方式的问题很多 Agent 数据生成方法从已有资源出发：我手里有这些 GitHub 仓库 → 从这些仓库生成任务我有这些工具 → 围绕这些工具生成任务我有一套技能树 → 组合技能生成任务问题是，最终数据分布会被现成资源绑架。例如拥有大量代码仓库，就会生成大量：修 Bug；加功能；写测试；但现实用户可能更需要：配置环境；清洗数据；分析日志；批量转换文件；找出系统故障；操作 SaaS；制作表格和文档。 NexForge 的做法：先问“用户需要什么” 它的管道大致是：输入：我想训练一个具备某种能力的 Agent ↓ 研究真实世界中有哪些典型需求 ↓ 建立任务类型与比例分布 ↓ 寻找真实场景 ↓ 生成具体任务指令 ↓ 自动寻找或构造文件、仓库、数据、依赖 ↓ 建立可执行环境 ↓ 让教师模型完成任务 ↓ 保存思考、工具调用、输出和错误恢复 ↓ 清洗并转换成 SFT 训练轨迹论文将它称为 Requirement-First，需求优先，与从仓库、工具或技能图出发的 substrate-first 方法相对。 “只有 3,600 个任务”其实非常有迷惑性 NexForge 的 Terminal-3.6K 并不是 3,600 条普通问答： 3,600 个可执行任务；最终获得 8,521 条教师轨迹；每条轨迹平均约 129K Token；每条轨迹平均约 123 次工具调用；教师每个任务最多尝试三次；训练最大上下文达到 262K；实验中的 35B 模型使用全参数 SFT；论文实验用了 128 张 H100。所以它真正证明的不是： “几千条数据就能轻松练出顶级 Agent。” 而是：几千个高复杂度、可执行、超长、多步骤任务，可以包含极为庞大的有效行动经验。论文报告，Terminal-3.6K 将 Qwen3.5-35B-A3B Base 在 Terminal-Bench 2.0 上从 22.5 提高到 52.0；扩展到 43.2K 任务后达到 58.4。Office-2K 则让同一基座在 GDPval 上从 813 Elo 提升到 1338 Elo。这组结果很值得关注，但仍然要注意：它是作者团队自己的论文结果；教师使用了强大的闭源模型；训练和评测 Harness 会贡献相当一部分能力； 3,600 是“环境任务数”，不是普通 Chat 样本数；训练成本远高于数字表面给人的感觉。九、你能从 Nex-N2 学到什么 1. 不要先找数据，再决定训练什么传统做法：网上有什么数据 → 我就训练什么 NexForge 的做法：产品究竟需要什么能力 → 真实需求的分布是什么 → 再构建相应数据这对你的陪聊项目尤其重要。不应该先下载一个“情绪对话数据集”就开始训练，而应先定义：用户明确要求记住信息偏好随时间变化新旧记忆发生冲突用户要求删除记忆模型不应主动提起敏感信息用户很久后重新出现用户否认模型记录的事实模型需要调用提醒或日历模型应该记住未完成的话题然后控制这些能力在训练集中的比例。 2. 环境本身就是训练数据的一部分一条 Agent 数据不应只是： { "question": "帮我整理文件", "answer": "已经整理好了" } 而应该包括：当前文件系统状态 → 模型调用 list_files → 发现命名不一致 → 读取部分文件 → 生成重命名方案 → 执行 → 遇到冲突 → 恢复 → 验证最终目录对于陪聊记忆，也应该构建一个真正可操作的环境： memory.search memory.write memory.update memory.delete calendar.read calendar.create profile.read relationship_state.update 这样模型学到的是“如何管理记忆”，而不是死背几条用户事实。 3. 训练失败和恢复，而不只是成功答案一个优秀 Agent 的差异往往不在第一次做对，而在：工具失败后是否重试；是否意识到假设错误；是否重新查询；是否验证修改；是否知道什么时候停止。陪聊也是一样：误记用户后能否承认；记忆冲突时会不会询问；用户改变想法后能否更新；不确定时会不会把推测说成事实；用户要求忘记后是否真的删除。 4. 数据分布比单纯数量更重要 NexForge 的消融结果显示，移除任务类型分布约束后，任务会明显坍缩到少数常见的软件工程类型。也就是说，让大模型“自由生成多样化数据”，通常没有想象中多样。因此你需要显式规定： 20% 显式记忆 15% 偏好变化 15% 记忆冲突 15% 不该主动提及 10% 删除与隐私 10% 主动关怀 10% 工具行动 5% 长期关系变化而不是让教师模型随机生成一万段陪聊。 5. 要训练“何时思考”，不只是“如何思考” 很多推理模型的问题是：简单问题也写很长；每次工具调用前都大量分析；已经得到答案仍继续搜索；消耗大量 Token 却没有提高成功率。 Nex 的 Adaptive Thinking 提醒我们，推理预算本身也应成为学习目标：直接回答简短判断深入分析调用工具重新规划停止这些都可以作为行为标签或奖励信号。十、放到你的陪聊场景里，应该怎样结合两者我建议的最终结构是：共享基座模型 │ ├── L0 Chat / Router │ ├── L1 Companion LoRA │ ├── 情绪交流 │ ├── 角色一致性 │ ├── 记忆使用策略 │ └── 关系状态处理 │ ├── L2 Action Agent LoRA │ ├── 日历 │ ├── 提醒 │ ├── 搜索 │ └── 其他工具 │ └── L3 GenUI LoRA ├── 记忆确认卡片 ├── 日程卡片 └── 用户偏好管理界面外部系统： ├── 用户长期记忆数据库 ├── 事件时间线 ├── 隐私与授权状态 ├── 关系状态 └── 反馈与训练数据池这部分使用 Macaron 思路。而训练数据使用 NexForge 思路： “训练一个能够长期理解用户，但不过度侵犯隐私的陪聊 Agent” ↓ 研究真实陪聊失败类型 ↓ 生成跨天、跨周、跨月用户时间线 ↓ 构造记忆数据库和日历环境 ↓ 让教师模型与模拟用户交互 ↓ 记录记忆查询、写入、修改和删除 ↓ 自动检测记忆错误和不恰当引用 ↓ 训练 Companion LoRA 一个可行的 MVP 数据规模不必从 3,600 个超长终端任务开始。可以先构建： 6 类能力 × 每类 100 个用户时间线 = 600 个可执行任务包每个任务 2–3 条教师轨迹 = 1,200–1,800 条多轮轨迹六类能力可以是：显式记忆与正常回忆；用户偏好变化；新旧信息冲突；敏感记忆与不主动提起；删除、纠错和遗忘；记忆与日历、提醒等行动结合。每个任务包包含： { "user_profile": {}, "timeline": [], "initial_memory": [], "hidden_ground_truth": {}, "allowed_tools": [], "privacy_policy": {}, "evaluation_rubric": {} } 然后对比： A：普通基座，无记忆 B：普通基座 + 外部记忆 C：Companion LoRA，无外部记忆 D：Companion LoRA + 外部记忆重点评估：事实回忆准确率；过期记忆使用率；不恰当主动提及率；记忆冲突处理率；删除后再次引用率；角色一致性；陪聊自然度；工具执行成功率。这会比直接问“模型是不是更有感情、更懂用户”客观得多。十一、你现在最应该关注 Nex 的哪一部分优先级不是：第一：下载 397B 权重第二：买 16 张 H100 第三：运行 Nex-N2-Pro 而应该是：第一：NexForge 需求驱动的数据构造方法第二：NexGAP 的任务—执行—轨迹转换管道第三：NexAU 的 Agent 环境第四：NexRL 如何连接 Rollout 与训练第五：Nex-N2-mini 的行为和数据效果第六：最后才是 Nex-N2-Pro 权重 Nex-N2-Pro 的权重证明了这套路线可能达到很高的能力上限；但对创业小团队真正可复用的，是它背后的数据生产思想。最终判断 Macaron 教你如何组织能力，Nex 教你如何生产经验。更具体地说： Macaron 的核心贡献是：冻结基座，把能力拆成可训练、可替换、可组合的 LoRA。 Nex 的核心贡献是：从真实需求分布出发，构造可执行环境和长程教师轨迹，再把行动闭环训练进模型。对你的陪聊项目：不要直接部署 Nex-N2-Pro 作为陪聊模型；它太重，公开训练重点也不在陪聊和长期用户关系。更合理的是用 Macaron-like 的 Companion LoRA 架构，用 NexForge-like 的方式制造长期记忆训练数据，再用外部数据库保存每个用户的真实记忆。因此，Nex-N2-Pro 值得关注，但真正值得你复刻的不是 397B 模型，而是 NexForge → NexGAP → 轨迹训练这条数据飞轮。 2. ChatGPT Pro 今天 15:38 Macaron-V1既然是开源的。我是否可以挂在 fireworks或者model平台上复现。然后这个训练数据怎么来？？我能蒸馏比如说k3 思考了 10m 29s [模型:gpt-5.6-pro] 可以，但要区分三种“复现”：目标可行性结论运行官方 Macaron-V1 权重很高 Modal 可以基本原样部署；Fireworks 需要稍微改造代理层在 Macaron 上增加自己的专家 LoRA 很高这是最值得做的方向从 Qwen/GLM 基座重新训练出官方同等 Macaron-V1 中低官方尚未公开完整训练语料、rollout、过滤器、奖励模型和全套实验配置，暂时只能复刻方法，不能严格复现结果用 Kimi K3 蒸馏 Macaron 专家很高技术上可行，也是我最推荐的方案把 GLM‑5.2/Qwen3.6 直接换成 K3，并继续使用原 LoRA 不可行 LoRA 与基座架构强绑定，必须重新训练以下把你说的“model 平台”按 Modal 理解。一、Macaron-V1 的“开源”到底开放到了哪一层 Macaron-V1 不是单一模型，而是：一个冻结的基座模型 + L0 对话/路由专家 L1 Agent/服务专家 L2 Coding/终端专家 L3 UI/A2UI 专家 + 负责路由、状态、摘要和工具粘性的 Proxy 目前有两个主要版本： Macaron-V1-Tall：Qwen3.6-35B-A3B 基座，加四个 Rank-64 LoRA 专家，总体约 50B。 Macaron-V1-Venti：GLM‑5.2 744B 基座，加四个约 1B 的 LoRA 专家，总体约 748B。一次请求会先由 L0 选择专家，再由相应 LoRA 回答，最后生成供其他专家读取的隐藏摘要；工具调用之后还要保持在原专家上，而不是重新路由。官方已经开放了： Macaron 各版本权重； Mixture-of-LoRA Harness；路由、上下文隔离、摘要和 API Proxy； LongStraw、MinT 的部分训练基础设施； vLLM/SGLang 的启动配置。但截至 2026 年 7 月 31 日，我没有在官方博客、模型集合和 Harness 仓库里看到完整的 V1 训练语料、原始 rollout、奖励模型、过滤分数、失败样本和完整评测集。Harness 仓库也明确表示不包含日志、基准、实验补丁和测试套件。因此它更准确地说是：开放权重 + 开放推理系统 + 开放部分训练基础设施，而不是可以逐 token 重跑的完整训练复现包。官方公布的是训练“方法”：从种子任务出发，生成更难任务，验证和筛选，再执行任务、审计轨迹、改进 Harness，最后用有效轨迹和 HCP 配置更新模型。所以你可以复现系统和方法，但目前不能保证从基座重新训练出完全相同的官方 checkpoint。二、放在 Modal 上：最适合“原样复现” 可以，而且 Modal 是第一选择官方生产配置要求： Linux + CUDA； vLLM 0.24.0 或 SGLang 0.5.13.post1；原始配置使用 8 张可见 GPU； TP8；同一个推理引擎同时驻留 L0～L3； Proxy 对外暴露 OpenAI-compatible API；官方默认上下文设为 262,144 tokens。 Modal 正好支持：单容器最多 8 张 H100、H200、B200、B300；同机 GPU；最大可提供约 2,304GB GPU 显存；自定义 CUDA 容器； Modal Volume 缓存 Hugging Face 权重； vLLM OpenAI-compatible 服务；多节点集群最多 64 张设备。推荐部署方式 Modal Volume ├── base/ │ └── Qwen3.6-35B-A3B └── loras/ ├── L0/ ├── L1/ ├── L2/ └── L3/ Modal 8-GPU Container ├── vLLM / SGLang :8000 └── Macaron MoL Proxy :8200 第一步建议只跑 Macaron-V1-Tall。 Venti 的 744B GLM‑5.2 基座过于庞大，即便官方也是 TP8；在 Modal 上需要 B300 级别的大显存节点、较长启动时间和大量权重缓存。它适合验证旗舰效果，不适合作为第一个工程实验。 Modal 的优点官方 Harness 基本不用重写。可以完整保留每个专家独立上下文。可以自行控制工具调用格式、摘要和路由状态。后续可以把训练环境与生产 Harness 对齐。适合继续做自定义 RL、GRPO、环境验证和持续学习。缺点则是你需要自己维护推理服务、冷启动、显存配置和扩缩容。三、放在 Fireworks 上：能做，但不是“直接上传一个模型” Fireworks 现在已经有： Qwen3.6-35B-A3B； GLM‑5.2； Kimi K3； LoRA 微调； Dedicated Deployment；单个基座最多挂载 100 个 LoRA； Live Merge。这意味着 Macaron 的两个基座已经不再是架构兼容性障碍。但 Macaron 的路由、独立记忆和跨专家摘要不是模型权重的一部分，而是在 Proxy 中。因此不能只是：上传 Macaron 权重 → 点击 Deploy → 自动获得完整 Macaron 你有两种实现方式。方式 A：Fireworks Multi-LoRA + 外部 Macaron Proxy 用户 ↓ 你部署的 Macaron Proxy ├── L0 route ├── per-adapter context ├── hidden summary └── tool stickiness ↓ Fireworks Qwen3.6-35B-A3B Dedicated Deployment ├── L0 addon ├── L1 addon ├── L2 addon └── L3 addon 需要修改官方 Proxy，把原本访问本地 L0/L1/L2/L3 的逻辑，改为调用 Fireworks 上不同的 addon model ID。这是最接近 Macaron 原始设计、同时又省去 GPU 运维的方案。Fireworks 的 Multi-LoRA Dedicated Deployment 最多支持 100 个适配器。方式 B：四个 Live-Merge 端点分别部署： Qwen3.6 + L0 Qwen3.6 + L1 Qwen3.6 + L2 Qwen3.6 + L3 Proxy 负责选择端点。优点是推理性能稳定，没有动态 LoRA 加载开销；缺点是基座模型被重复部署四次，成本明显更高。Fireworks 的 Live Merge 会在部署时把 LoRA 合并进基座，从而消除 LoRA 推理开销。 Fireworks 能不能直接训练这些 LoRA？可以。Fireworks 的标准 SFT 数据使用 JSONL，每条记录包含 messages 数组，目前标准角色主要是 system/user/assistant；支持最多 300 万条样本。但要区分：普通对话、路由、摘要：Managed SFT 很合适； Coding、Agent 工具轨迹：需要把工具轨迹规范化成训练对话，或者使用更自由的 Training API； Macaron 式 Harness-in-the-loop RL：Modal 或 Fireworks 的自定义训练接口更合适； Fireworks 外部 RL rollout 热加载目前属于 Early Access。四、Macaron 的训练数据实际上应该怎么来 Macaron 官方描述的是一种数据生成系统，而不是一个静态数据集：种子任务 ↓ 模型扩写更难、更丰富的任务 ↓ 验证答案、过滤低质量和无学习价值样本 ↓ Agent 在真实 Harness 中执行 ↓ 记录工具调用、环境结果和最终答案 ↓ 审计成功与失败轨迹 ↓ SFT / DPO / RFT / GRPO ↓ 更新后的模型继续生成更难任务这就是它所谓的 Discovery → Expansion → Update 循环。你不需要先拥有几亿条人工数据。真正重要的是：少量高价值种子任务 + 大量可验证的执行环境 + 教师模型生成轨迹。各专家的数据来源 L0：Chat、路由和摘要需要：多轮对话；用户意图分类；该请求应交给 L1、L2 还是 L3；跨专家摘要；拒绝路由或重新路由案例；不确定请求和混合任务。 L0 不需要特别长的答案，但路由准确率极为重要。 L1：Agent 与服务流程需要：浏览、检索、日历、邮件、表单等工具任务；多步骤服务流程；用户偏好和长期记忆；工具失败、权限失败、超时和重试；任务是否真正完成的环境反馈。数据最好来自可执行模拟器，而不是单纯的问答文本。 L2：Coding 需要： GitHub Issue → 修改代码 → 运行测试； terminal 任务；编译错误修复；单元测试、静态检查和安全扫描；多轮 Debug 轨迹；成功和失败 patch 的对比。这里特别适合用 K3 生成候选轨迹，然后只保留通过测试的样本。 L3：UI/A2UI 需要：用户需求 → UI schema； UI 修改指令；结构化组件树；页面渲染截图； schema validator； accessibility 和交互检查； “生成后继续修改”的多轮轨迹。对你最合适的 L4 不建议一开始重新训练 L0～L3。更好的方法是保留官方专家，新建： L4-DeviceOps 或者： L4-Cyber 内容覆盖：设备识别； Bootloader/Root/刷机方案；风险判断； CVE 与设备版本匹配； ADB/Fastboot 工具调用； CyberGym/ExploitGym 任务；执行结果验证；失败恢复与回滚。这既可以验证 Macaron 的“插件式持续学习”，又能直接服务你正在研究的 DeviceOps/CyberGym 产品。五、可以用 K3 蒸馏吗？可以，而且分三种含义 1. 用 K3 作为教师，蒸馏到 Macaron-Tall 最推荐。 K3 教师 ↓ 生成候选轨迹沙箱/测试/环境验证 ↓ 过滤 Qwen3.6-35B-A3B ↓ LoRA SFT/RFT Macaron L4 专家你蒸馏的不是 K3 的参数，而是：任务分解；工具选择；操作序列；代码 patch；错误恢复；最终答案；任务摘要；成功结果。这样得到的 L4 可以继续挂到 Macaron-Tall 上。 2. 以 K3 为 Macaron 新基座，训练 L0～L3 技术上也可以，但不能复用现有 Macaron LoRA。原因是： GLM-5.2 LoRA ≠ Qwen3.6 LoRA ≠ K3 LoRA LoRA 的矩阵尺寸、目标层、注意力结构、MoE 层和 tokenizer 都与基座绑定。因此要构建： K3-Macaron ├── K3 Base ├── 全新 K3-L0 ├── 全新 K3-L1 ├── 全新 K3-L2 └── 全新 K3-L3 而 K3 是约 2.81T 参数、1040K 上下文的巨型 MoE，训练和托管四个专家都很昂贵。Fireworks 当前已经支持 K3 Serverless、Dedicated Deployment 和 LoRA 微调。这条路线适合追求最高能力，不适合先做 MVP。 3. 直接给 K3 训练 LoRA 这是最简单的“获得定制 K3”方案。但它不算蒸馏，只是： K3 + 你的 LoRA 它的优点是能力上限高；缺点是每次推理仍然要运行 2.81T K3，部署和推理成本不会像 Macaron-Tall 那样下降。六、K3 蒸馏的许可问题 K3 的开放权重许可明确允许：使用；复制；修改；微调；创建衍生作品；部署和商业使用。许可中没有看到明确的 anti-distillation 条款，因此自托管开放权重作为教师是许可最清晰的路线。但许可对大型 Model-as-a-Service 业务设有额外条件：连续 12 个月相关营收超过 2,000 万美元时，需要与 Moonshot 另行签约；达到特定大型商业规模还涉及 Kimi K3 品牌展示要求。需要区分：自托管 K3 权重生成训练数据：主要受 K3 Model License 约束；调用 Fireworks K3 API 生成训练数据：还要遵守 Fireworks 服务条款；调用 Moonshot 官方 API：还要遵守 Moonshot API 条款。因此商业规模蒸馏时，最稳妥的是使用开放权重或向服务提供方确认“输出用于训练其他模型”的权限。七、K3 生成训练数据的成本 Fireworks 当前 K3 标准价格是：输入：3 美元/百万 token；缓存输入：0.30 美元/百万 token；输出：15 美元/百万 token。只计算输出： 1 亿输出 token：约 1,500 美元； 5 亿输出 token：约 7,500 美元； 10 亿输出 token：约 15,000 美元。对于 MVP，完全没必要一开始生成十亿 token。例如： 2,000 个种子任务 × 每题 4 个 K3 rollout × 平均 3,000 输出 token = 2,400 万输出 token 纯输出成本大约 360 美元，之后通过测试、环境验证和去重，保留约 3,000～6,000 条高质量轨迹，足够训练第一个领域 LoRA。证明有效后，再扩展到 2 万、10 万甚至百万级轨迹。八、不要直接蒸馏 K3 的“长思维文本” 建议蒸馏：任务工具定义关键决策工具调用环境返回值错误恢复最终结果简洁任务摘要验证分数不建议把大量未经验证的隐藏思维或超长 reasoning 原样塞进学生模型。原因是：长思维中包含探索性错误；学生模型容易模仿语言表象，而不是学会完成任务； token 成本极高；不同模型的推理格式不兼容；真实 Agent 能力主要来自“动作—结果—修正”，不是漂亮的解释文本。最有效的训练样本通常是： K3 提出 4 个解法 ↓ 分别在沙箱中执行 ↓ 只有 1 个通过测试 ↓ 保留成功轨迹 + 从另外 3 个失败轨迹中提取失败原因也就是结果蒸馏，而不是简单的文本模仿。九、最适合你的实际实现方案我建议使用下面这条流水线：人类种子任务 ↓ Fireworks K3 生成 2～4 条候选轨迹 ↓ Modal Sandbox / Docker / CyberGym 验证 ↓ 测试、编译、schema、任务完成度过滤 ↓ 形成 verified trajectory dataset ↓ Fireworks 对 Qwen3.6-35B-A3B 做 Rank-64 LoRA ↓ 得到 L4-DeviceOps 或 L4-Cyber ↓ 挂载到 Macaron Multi-LoRA ↓ 外部 Proxy 增加 L4 路由规则第一阶段训练数据建议包含： task_id specialist task_prompt environment tool_schema teacher_actions tool_results final_answer verifier_score failure_type difficulty data_source license 核心评测指标则是：指标作用 Task Success Rate 最终是否完成任务 Tool-call Validity 工具参数是否合法 Route Accuracy L0 是否选对专家 Recovery Rate 工具失败后能否恢复 Pass@1 第一次执行是否通过 Token/Task 完成一个任务的成本 Base Regression 新 LoRA 是否损害原能力 Unseen-task Generalization 是否只记住训练模板最终建议最优组合不是“把 Macaron 全部重新训练一次”，而是： Macaron-V1-Tall 作为共享基座和系统框架，Fireworks K3 作为数据教师，Modal 作为任务执行与验证环境，先训练一个 L4-DeviceOps/Cyber 专家。部署阶段可以选择：追求官方原样行为： Modal + 官方 vLLM/SGLang Harness 追求省运维和生产化： Fireworks Qwen3.6 Multi-LoRA + 你自己的 Macaron Proxy 追求最高能力、不在意成本：直接训练 K3 LoRA 追求可控成本与持续学习： K3 教师 → Macaron-Tall 专家 LoRA 其中最后一条最能真正验证 Macaron 所宣称的核心价值：不反复重训整个模型，而是不断生成、验证和挂载新的能力模块。 3. ChatGPT Pro 给ai配机器人身体的最低成本当前是多少，能降低到多少。能通过微型化，或者廉价化降低几个数量级么。我想要用身体作为ai的因果训练的反馈来源。比如说通过战斗和争抢资源甚至创造新的身体来获得生存机会来学会有效的因果模型。思考了 16m 39s [模型:gpt-5.6-pro] 结论先行截至目前，“给 AI 配一个机器人身体的最低成本”有三个完全不同的答案：实验室中的绝对单体下限：约 0.01 美元。宾夕法尼亚大学和密歇根大学在 2025 年展示了约 200×300×50 微米、具有计算、传感和推进能力的可编程自主机器人，大规模制造时单体约一美分。但它依靠光供能、在液体中游动，需要显微镜、照明和微纳加工体系，不是可以买回来在地板上争夺资源的通用机器人。真正适合你这个“物理生态—因果学习”项目的下限：约 8–20 美元/体。这是指 3–5 厘米的桌面圆盘机器人，AI、大视觉和主要计算放在场外，每个身体只保留电机、微控制器、电池、碰撞检测、身份标识和无线通信。小批量手工原型约 20–60 美元/体；100–1000 台定制约 8–20 美元/体；一万台规模、设计充分优化后，物料成本可能落到 5–12 美元/体。具有通用抓取能力的最低成本，大约是 100 美元级，而不是 10 美元级。开源 SO-101 单个从臂的公开物料表约 121.94 美元，但不含打印件、摄像头和主机；双臂移动平台 XLeRobot 给出的总成本约 660 美元。当前 Unitree 官方商店中，Go2 系列标价从约 1600 美元起，某些在售配置约 2800 美元；R1 从 4900 美元起，G1 为 13,500 美元，而且普通零售版本并不一定开放二次开发，研究版实际总成本通常还会更高。所以：相对于人形机器人，把身体简化成厘米级桌面机器人，降低 2–3 个数量级是现实的；降低 5–6 个数量级也已经在微型机器人上出现，但那意味着换了一套物理世界和能力边界。一台 10 美元左右的“因果身体”是否真实可行以最廉价的振动式圆盘机器人估算，核心零件大致是： ESP32-C3 芯片约 1.23 美元；双路电机驱动约 0.62 美元；两个振动电机约 1.5–2 美元； 100mAh 左右电池约 0.6–0.9 美元；再加 PCB、充电、电源管理、LED、接触开关、外壳、装配和测试。核心电子与执行部件在批量下已经接近 4–5 美元；加入其余成本后，5–12 美元的物料成本是合理的工程目标，但不包括研发、模具、运输、坏件和人工维护。这并非纯纸面估计。Harvard 的 Kilobot 在十多年前就实现了约 14 美元物料成本、5 分钟装配时间，并组建过 1024 台规模的实体机器人群。它使用振动电机运动、红外邻居通信和简单传感，证明了“十美元级身体组成千体种群”在工程上确实可行。不过，价格和控制精度之间有明显冲突：身体类型批量目标成本特点振动式 PCB 圆盘 5–12 美元极便宜、耐撞，但运动噪声大、难精确复位双轮减速电机圆盘 15–40 美元轨迹和推力更可控，更适合严格因果实验圆盘加简单夹持/磁吸 25–80 美元可以搬运和争夺实体资源 SO-101 固定机械臂约 122 美元起有抓取能力，但数量扩展更昂贵移动双臂平台约 660 美元起接近低成本通用操作平台四足/人形 1600–13,500 美元以上动作空间丰富，但不适合早期大种群实验对于因果学习，运动精度通常比把单价从 12 美元压到 5 美元更重要。干预本身不稳定，会让“动作造成了什么”变得难以识别。比较好的做法是先做 16 台精确双轮版，验证实验协议，再扩展为廉价振动版群体。究竟能降低几个数量级以 10 美元桌面身体计算：相对 4900 美元的 R1，便宜约 490 倍，即 2.69 个数量级；相对 13,500 美元的 G1，便宜约 1350 倍，即 3.13 个数量级；一美分微型机器人相对 G1，差距约 135 万倍，即 6.13 个数量级。但后一个比较几乎是“苹果和浮游生物”的比较。微型化到亚毫米后，重力和惯性不再主导，黏性阻力和表面效应开始主导；普通轮子、腿和机械臂不再适用，机器人通常需要在液体中以电场、化学或光学方式运动。Penn 的研究团队也明确指出，微观尺度中的运动物理与宏观机器人完全不同。因此可以把结论分成两种：保持大致相同能力靠量产、结构一体化和零件国产化，通常还能降低 3–30 倍。想在动作空间、可靠性和自主性不变的情况下再降 1000 倍，并不现实，因为执行器、电池、机械结构和装配不像芯片算力那样持续指数降价。主动牺牲能力把视觉、计算、定位、记忆甚至供电都移到场外，只保留一个物理执行端，降低 100–1000 倍是可行的。所以真正的降本秘诀不是单纯“做小”，而是：让机器人共享昂贵器官。最适合你的架构：共享眼睛、共享大脑、回收身体你的 AI 不需要装在每台机器人内部。更合理的架构是：全局真值，仅供训练器和评估器 ↑ 天花板摄像头 ──→ 对象/关系跟踪 ──→ 因果数据仓库 │ ↑ │ 为每个个体生成局部、带噪声的第一视角 │ ↓ │ 中央世界模型/策略 ──动作指令──→ 机器人本地安全控制器 │ 电机、碰撞、充电 │ 真实物理世界每个身体只需要：两个电机；一个低成本 MCU；身份标签；碰撞环或接触开关； LED 或红外通信；电池和充电触点。中央服务器负责：批量运行所有个体的策略；维护每个个体的记忆、权重和基因；从天花板摄像头生成每个个体能看到的局部观测；记录动作、干预、结果和谱系；进行世界模型训练与反事实规划。这样做仍然是真实具身学习：碰撞、摩擦、遮挡、推力、资源堵塞和其他个体的行为都是真实发生的。被“虚拟化”的只是摄像头安装位置和计算位置。低层电机控制可以在 MCU 上以较高频率运行；较大的因果世界模型只需以 2–10Hz 做宏观决策。一个中央 GPU 可以批量推理几十乃至上百个身体。 32–64 个身体就足以形成第一代实验一个可信的 MVP 可以是： 32–64 个 3–5 厘米圆盘机器人；一个约 1.5–2 米见方的可复位场地； 1–2 个顶部摄像头；若干资源站、充能站和出生区；一台现有 GPU 工作站；自动充电或批量换电装置。我的工程预算估计是：机器人身体：约 800–1600 美元；摄像、灯光、场地和充电：约 1000–2500 美元；备用件、调试器和机械结构：约 500–1000 美元；总计约 2000–5000 美元，不含已有计算机和人力。 64 个个体以 10Hz 运行 8 小时，每天理论上可产生约 1840 万个原始状态—动作步。当然，这些数据高度相关，真正有价值的独立干预远少于这个数字。因此应优化的指标不是“每美元产生多少帧”，而是：每美元能获得多少次统计上有区分度的干预，以及多少无人值守的有效机器人小时。自动充电、自动复位和自动处理卡住的机器人，长期看比再降低两美元 BOM 更重要。你的核心想法成立，但“生存”不会自动产生因果模型身体有一个非常重要的优势：观察只是看到世界发生了什么，动作则近似于对世界执行了一次 do(action) 干预。但这里有三个陷阱。 1. 生存优化不等于因果模型优化自然选择只关心“哪些后代留下来了”，并不关心个体内部有没有正确、可解释的世界模型。一个个体可能依靠以下方式生存：固定反射；对颜色、位置等伪相关进行利用；堵住充电站；攻击身份标签或传感器；利用计分系统漏洞；跟随一个强个体而不理解原因。它同样可以获得很高的繁殖率，却没有形成通用因果模型。 2. 动作也可能存在混杂例如，只有强壮的机器人倾向于发动攻击，那么“攻击之后更容易获得资源”可能只是强壮造成的，而不是攻击造成的。需要保留行为策略概率，并主动安排一部分随机干预，才能区分： P(获得资源 | 发动攻击) 和： P(获得资源 | do(发动攻击)) 3. 反事实不能在同一条时间线上被直接观察一个机器人选择向左后，无法同时知道“当时向右会怎样”。物理世界只能产生一个事实结果。因此反事实必须通过以下方式验证：在模拟器中从完全相同的快照分叉；将实体场地复位到近似相同状态，反复执行不同动作；使用两套尽量一致的“孪生场地”；先由数字孪生生成反事实，再抽样到实体世界验证。多智能体系统对微小误差非常敏感，所以不应要求反事实轨迹逐像素一致，而应比较：获得资源的概率；存活概率；能量变化分布；对手响应类型；谱系长期占比；预测置信度是否校准。 “因果 Token”应该如何设计目前的机器人 Token 化主要是在编码动作。例如 RT-1 把每个动作维度离散成 256 个区间；FAST 则通过 DCT 和 BPE 压缩连续动作片段，通常将一个动作块压缩成 30–60 个 Token，并显著提高训练效率。但你的新意不应只是把“左转、右转、推力”变成 Token，而应把整个因果事件编码为： [状态] 个体A接近资源7 个体B位于A与资源之间 A能量=21 地面摩擦=未知 [干预] do(A 推动 B，方向=北，力度=0.7) [事实结果] B位移=0.17m A能量=-2.1 A获得资源概率上升发生侧滑 [机制推断] B质量偏低当前区域摩擦偏高推力传递置信度=0.73 [反事实] 若 A 绕行： P(获得资源)=0.31 P(受阻)=0.42 预计能耗=1.3 可以分成五类 Token：实体与状态 Token：个体、资源、障碍、位置、能量、所有权。干预 Token：移动、推动、阻挡、抢夺、传递、充能、出生。效果 Token：位移、能量变化、资源转移、损伤或失效。机制与不确定性 Token：摩擦、延迟、强度、对手类型、置信度。谱系 Token：父代、突变、继承参数、寿命经验和后代数量。关键仍然不是给 Token 起了“因果”这个名字，而是训练数据中真的包含：随机化干预；环境机制变化；可复位分叉；行为策略概率；对未见机制的测试。因果性来自实验设计，不来自 Token 命名。生存、战斗和繁殖应该怎样实现不建议第一版让机器人真的破坏彼此。硬件损坏只会提高成本、降低数据质量，并把选择压力推向“谁最会毁设备”。更合理的规则是：资源机器人必须真实移动到资源点、接触或推动实体资源，但资源价值由外部不可篡改的账本记录。这样既保留物理因果，又不会因为电池测量误差破坏实验。可以设置两种资源：能源：决定寿命和行动预算；建造材料：决定是否有资格产生后代。战斗使用非破坏性竞争：推出区域；挡住通路；抢占充能口；红外命中；接触后扣除虚拟能量；抢走带磁性的资源块。这样仍然能产生进攻、防御、联盟、欺骗、威慑和领地行为。死亡死亡不是报废机器人，而是：该个体的控制进程停止；当前身体回到充电或出生区；身体被清空并重新分配给另一个基因组。因此固定 64 个身体可以经历数万代“出生和死亡”，不需要制造数万台机器。繁殖当个体或谱系积累足够资源后：从空闲身体池领取一个身体；复制初始权重、学习规则和记忆结构；执行突变或重组；在出生区启动。还可以比较两种遗传方式：达尔文式：只继承出生时的基因和初始权重；拉马克式：连父代一生学到的部分权重也继承。这本身就是一个很有价值的研究问题。创造新身体第一阶段只“创造新个体身份”，不真正制造硬件。第二阶段可以让基因选择：轮子大小；防撞圈形状；磁铁位置；传感器组合；电池容量；是否携带推杆或夹持模块。第三阶段再让 3D 打印机或机械臂组装真正的新形态。现实中的 Embodied Evolution、Autonomous Robot Evolution 和 RoboFab 已经探索过在线进化、基因编码身体和免人工构造机器人，但当前总体仍偏研究型、低吞吐的概念验证。为什么竞争可能有效，但不能只有竞争 OpenAI 的多智能体捉迷藏实验表明，简单竞争目标可以产生自动课程，逐步催生工具使用和反制策略；DeepMind 的 XLand 也显示，开放式多任务游戏有助于获得更强的零样本适应能力。但是纯零和战斗容易产生几个问题：进化出单一霸主，生态迅速失去多样性；只针对当前对手过拟合；出现循环克制，而不是能力单调增长；破坏基础设施比理解环境更划算；合作、交换和长期规划被淘汰。因此环境中最好同时存在：稀缺资源竞争；需要多人完成的公共任务；可交换的不同资源；季节和资源位置变化；捕食者—猎物关系；可改造的障碍和巢穴；部分亲缘关系；固定归档的历史对手。这可以避免“当前最强策略”垄断，并区分真正的环境理解和针对某一代对手的过拟合。怎样证明它学到的是因果，而不只是更会打架至少需要五组等算力、等交互预算的基线：组别训练方式 A 行为克隆或下一个动作预测 B 无世界模型的多智能体强化学习 C 只看观察数据的普通世界模型 D 带随机干预和反事实目标的因果世界模型 E 因果世界模型加跨代进化测试时不要只换场地颜色，而要区分两类变化。无关外观变化光线；颜色；标签形状；摄像机噪声。因果模型应当尽量保持性能。真正机制变化地面摩擦；机器人质量；电机延迟；资源再生规则；接触扣能规则；对手策略；通信延迟。因果模型应更快识别新机制，并用较少试验恢复性能。CausalWorld 正是围绕这种思路构建：它允许研究者干预质量、尺寸、颜色等底层变量，并专门衡量结构变化下的迁移。真正有说服力的指标包括： do(action) 后的多步结果预测误差；不同动作之间处理效应的误差；反事实行动排序准确率；概率预测校准程度；新摩擦、新延迟下的适应步数；达到同等生存率所需的实体交互次数；删除世界模型后，生存优势是否消失；在历史对手和未见对手上的长期谱系占比。最关键的证伪条件是：在实体交互数量和计算预算相同的情况下，显式因果模型必须在未见机制变化中显著优于普通世界模型和模型自由强化学习。只是在原训练场地里活得更久，不能证明学会了因果。这个项目最大的风险不是机器人造价真正昂贵的是：无人值守率低：卡住、没电、轮子缠绕和通信掉线。干预不可重复：机器人每次推力不同，难以建立反事实基准。基础设施被利用：堵充电口、遮挡摄像头、伪造身份。适应性评价失真：只适应当前对手，形成红皇后循环。安全控制被纳入进化目标：个体可能尝试绕过限速、资源账本或出生规则。机器人进化研究已经专门讨论过无约束繁殖、错误适应和支配风险，并建议把繁殖集中在外部设施中，限制出生数量，保留监控和硬停止能力。第一代系统至少应有：独立于学习模型的不可修改安全 MCU；硬件限速、限力和电流限制；固定人口上限；外部不可篡改资源账本；出生前安全测试；隔离网络；不允许个体访问充电、摄像和制造控制系统；实体急停和软件全局暂停；完整谱系与行为黑匣子。最终判断这个方向在经济和技术上都已经能够做 MVP，而且不需要从人形机器人起步。最合适的第一代身体不是人形，也不是一美分的微型游泳机器人，而是 3–5 厘米、10 美元级、共享视觉和共享计算的桌面圆盘机器人。它可以做到：比人形机器人便宜约 2–3 个数量级；用固定身体池模拟无限代出生和死亡；提供真实摩擦、碰撞、资源争夺和多智能体反馈；通过复位、随机干预和孪生实验验证反事实；后续逐步增加夹持、模块化身体和自动制造。最值得验证的核心猜想不是： “让机器人打得足够久，因果智能自然会出现。” 而是：在相同实体交互预算下，具身随机干预、开放式多智能体生态、显式动作—效果 Token 和反事实训练，是否能产生比普通世界模型及模型自由强化学习更强的机制迁移能力。第一版用 32–64 个可回收身体、软件化繁殖、非破坏性竞争和严格的机制变化测试，总硬件预算控制在约 2000–5000 美元，是目前性价比最高、也最容易证伪核心假设的路线。