1. 先说说这次发布我为什么觉得值得专门写一篇这几天 AI 圈讨论度最高的一条消息应该就是 Hy4 preview 的发布770B 总参数的 MoE 模型代码和权重一起放了出来同一时间配套的 WorkBuddy 官宣限时两周免费用。消息一出很多群里的反应分成两派一派盯着“770B 怎么部署”另一派盯着“WorkBuddy 是什么免费两周够干嘛”说实话这两个问题恰好指向了这次发布的两个关键面模型本身的技术含量以及普通用户能不能真正把它用起来。先说我的判断如果你只是想吃瓜可以继续围观如果你是做大模型应用、Agent 开发或者平时要处理大量重复办公事务这次值得花一点时间把原理跑通。因为 Hy4 preview 这种量级的开源 MoE短期并不会有多少人能私有化部署完整版但它的架构设计和配套工具链条会直接影响后面半年里很多产品怎么做选型。WorkBuddy 的限时免费则是一个低门槛入口能让你在没有太多技术背景下也亲身体验到“模型 工具”的组合能做到什么程度。这篇文章我不打算写成一个发布会通稿而是把三个最容易被误解的概念拆开。第一770B 总参数和 MoE 架构意味着什么第二开源模型要落到真实环境里到底卡在哪里第三WorkBuddy 免费两周可以用来做什么、应该怎么用才不会白领这波福利。算法和工程向的朋友可以重点看前几部分产品运营向的朋友可以直接跳到 WorkBuddy 实操部分各有各的收获。1.1 “770B”没有你以为的那么大但也没有想象中那么小很多人看到 770B 第一反应是“比 GPT-4 还大”这里要先建立一个基础认知总参数数量并不是模型能力唯一的决定性指标尤其当模型采用 MoE 架构时总参数和单次推理实际参与计算的参数完全是两码事。用大家熟悉的话来说一个模型如果有 770B 参数但实际每一次处理 token 时只激活其中的一小部分专家网络那它真正消耗的计算资源和延迟可能和一个几十 B 参数的密集模型差不多但知识容量却因为“带了更多专家”而更宽。我自己接触 MoE 模型时也踩过类似的理解偏差。最早以为总参数越大越跑不动后来真去部署一个 600B 级别的 MoE才发现它的显存需求确实很大但计算效率并不像同参数量的密集模型那样爆炸。换句话说“770B”如果全量激活那基本是无数企业碰都不敢碰的量级但套上 MoE 之后它更像是把一个大图书馆拆成了几百个分馆每次咨询只叫几个相关领域的馆员过来而不是把所有员工都喊到大厅。不过大家也别走到另一个极端觉得 MoE 就是“用少量参数模拟大模型效果”。总参数量依然决定了模型能记住多少知识和模式专家数量越多可分配的知识容量就越大。只是训练和推理时要解决怎么让每个 token 选中合适的专家、怎么避免专家之间的竞争和重复。所以 770B 这个数字不是用来吓人的而是用来表达“这个模型的容量上限到了一个新台阶”。1.2 “preview”和“开源”放在一起机会和风险都很大标题里的 preview 三个字很多人会忽略但在技术选型时它比 770B 还重要。preview 意味着这个版本更接近技术预览不是长期稳定版。也就是说模型架构、API 行为、甚至部分参数都有可能在未来版本中调整发布方希望大家先跑起来看效果、给反馈而不是直接把它当成核心系统的唯一底座。做应用的同学如果准备接入最好在架构上留一层抽象方便后面无缝切换到正式版。开源这一条才是这次发布更值得关注的信息。模型权重、基础代码、评估资料一并开放意味着你可以在自己的环境中跑推理也可以在私有数据上做测评不再像闭源 API 那样只有一个黑盒。对研究团队来说能亲眼看清楚专家路由怎么分布、长上下文下的注意力怎么处理这些信息价值远高于跑几个 benchmark。但开源不是“免费午餐”。你要先看它的开源协议是否允许商用是否对月活用户数或生成内容有附加条款是否有“不能用于特定领域”的限制。后续在第 3 部分我会专门展开讲这里先提个醒别看到 GitHub 上写着开源就默认能任意商用。1.3 WorkBuddy 限时免费是这次发布里对普通人最友好的部分如果模型开源对普通用户还是有点远那 WorkBuddy 限时两周免费就是最容易直接上手体验的部分。从名字看WorkBuddy 和你可能听说过的 CodeBuddy 属于同一个家族但定位完全不同CodeBuddy 偏开发者场景WorkBuddy 更偏日常办公和业务执行。它能做的事情包括但不限于根据数据文件生成周报、把一个自然语言需求变成可打开的网页、串联多个工具完成一个业务流程甚至可以把你经常用的流程沉淀成 Skill 方便复用。这次的限免意味着你不必自己处理 770B 模型的部署也不用承担 API 费用就能体验到大模型加 Agent 工具链的完整效果。不过注意“限时两周”这种活动通常不会自动续期你需要先看清楚活动入口、激活期限和截止日期最好在动手之前就规划好要测试哪些场景。白白注册一个账号然后放到最后一天才打开往往就来不及了。2. MoE 架构拆解770B 如何做到“算得少、知识多”想判断 Hy4 preview 的部署成本和应用价值光知道“MoE 是混合专家”还不够最好把它的工作机制理解到能向别人解释的程度。这部分我不会堆太深的公式而是把几个关键点讲透。你搞懂之后再去看官方技术报告或者网上那些部署教程基本就不会被各种名词绕晕。2.1 一句话理解 MoE不是一个模型包揽全部而是一群专家坐在诊室里传统 Transformer 模型里每一层基本都要把所有 token 都经过同一个前馈网络那个前馈网络本质上就像一个全科医生什么病症都要看。而 MoE 模型的思路是把前馈网络扩展成很多个相对独立的专家网络同时在前面加一个分诊台也就是路由网络也叫门控网络。每个 token 进来之后不需要所有专家都处理它而是由路由网络快速判断“这个 token 擅长被哪些专家处理”然后选排名靠前的几个专家出来干活。这就像一个大医院虽然有几千名医生但普通感冒不会被叫到心外科。每个 token 的选择是动态的上下文不同它可能走不同的专家路径。正是因为这种“按需分配”MoE 模型才能在总参数量非常大的前提下保持比较合理的单次推理计算量。你用 770B 总参数的模型并不等于每生成一个字都要你等待计算 770B 参数而是只等被激活的那一小批专家算完。2.2 路由机制与 Top-K 选择专家不是越多越好核心机制里还有一个不能忽略的数字就是 Top-K。MoE 模型在路由时通常会设定一个 K 值比如“每次选择得分最高的前 2 个专家”或“前 8 个专家”。K 越大每次参与的专家越多效果理论上会更稳定但计算量也会上升K 太小路由一旦判断出错模型表现就会明显下降。而且专家数量并不是一味增加就好。专家越多每个专家的“知识分工”理论上可以更细但训练难度和路由判别难度也会上升。如果路由质量不够好大部分 token 可能总是涌向少数几个“明星专家”其他专家长期得不到充分训练形成负载不均衡最终模型的 capacity 并没有被真正利用起来。我在之前看一些 MoE 模型评测时发现同样总参数的模型专家路由均衡程度不同最终效果差异可以非常大这也是 MoE 训练里最需要调的部分之一。如果把 Hy4 preview 的总参数 770B 放进去看我们可以做一个粗略推测如果它采用类似业界常见的 MoE 设计专家层的总参数可能占了绝大部分实际每次推理激活的参数大概在几十 B 量级。具体要看官方技术报告里的配置但理解这个逻辑之后你再看到“总参数 770B”时心里就有数了这是容量指标不是算力成本指标。2.3 一个反直觉的结论训练更贵推理相对便宜MoE 模型有个让很多人困惑的特点训练阶段往往比同等效果的密集模型更贵推理阶段则相对更划算。原因是训练时每个 token 虽然只激活少数专家但反向传播需要更新的参数范围、需要同步的梯度和通信量都很复杂而且为了保证所有专家都被充分训练还需要额外的负载均衡损失。这就像一个大公司虽然平时每个项目只派几个小组去谈但到了年终考核所有小组都要被盘点、调整绩效管理成本自然高。推理阶段就不一样了。推理不需要更新参数激活多少专家就算多少计算量。于是 MoE 往往能做到“总参数很大但推理吞吐还不错”。这也是为什么很多 API 服务愿意用 MoE 模型做底座在单位算力成本下能服务更多用户。不过要记得一个反直觉等式MoE 推理省的是计算量不是显存。因为哪怕某个专家这次没有被激活它的权重也依然要加载在显存或者内存里否则遇到下一个 token 又需要时难道现场从硬盘加载吗所以显存占用看总参数计算量看激活参数这两个维度必须分开算。2.4 实际工程里绕不开的负载均衡与专家并行如果你以后会参与 MoE 模型的部署和调优除了关注层数、专家数还要关注一个工程细节专家并行。因为那么多专家的权重不可能均匀塞进一张卡通常会被切分到多张 GPU 上每次路由需要跨卡收集 token把 token 发给对应专家所在的卡上计算然后再把结果拼回来。这个流程在工程上称为 All-to-All 通信通信开销可能比计算本身还大。负载不均衡会进一步加剧通信热点某个专家如果接收了太多 token它所在的 GPU 就会变成瓶颈其他卡上闲着整体速度被拖慢。缓解手段包括负载均衡损失、动态调整路由阈值、把热门专家多复制几份等。多数开源部署框架里会提供这类优化选项但默认参数不一定适合你的业务数据分布所以做部署调优时不能只看模型本身的 benchmark还要拿自己的 token 分布实测。3. 开源 770B MoE 到底能不能私有化部署“开源”两个字听起来很诱人但每次有超大模型开源都会看到一堆人问“我的 4090 能跑吗”针对 770B 这种量级我直接说结论单卡基本不用想。这个部分我会把门槛掰开揉碎讲清楚然后再给出一条不必自己硬扛的落地路径。3.1 先算一笔账要准备多少显存才够装下模型评估部署成本的第一步是算权重占用。模型权重所占空间可以按“参数量 × 每参数字节数”来粗略估算。如果你用 FP16 或 BF16 精度存储每个参数占 2 字节用 INT8 量化每个参数占 1 字节用 INT4 量化每个参数只占 0.5 字节。770B 参数在不同精度下的权重体积大致是这样精度每参数占用770B 权重大致体积FP16/BF162 字节约 1540 GBINT81 字节约 770 GBINT40.5 字节约 385 GB可以对应一下硬件一张 H100 或 A100 的显存通常是 80 GB一张消费级 RTX 4090 是 24 GB。哪怕采用 INT4 量化权重大概要 385 GB光是把权重放进去就需要 5 张 80 GB 显卡。而且这只是裸权重推理时还有 KV Cache、中间激活值、通信缓冲区等额外开销。真正部署时给足冗余之后你可能需要 6 到 8 张 H100 或 A100并且这些卡之间必须有高速互联否则 All-to-All 通信会把效率拖到无法接受。所以我经常对朋友说评估 MoE 模型部署别先看激活参数那是推理计算量先看总参数和量化方案那才是显存容量的下限。下面这段代码可以用来快速估算基础权重占用适合你在接触其他大模型时直接套用。def estimate_weight_gb(params_b: float, bits: int 16) - float: # params_b: 参数量单位 B10 亿 # bits: 每个参数的位宽FP16/BF16 传 16INT8 传 8INT4 传 4 bytes_per_param bits / 8 weight_gb params_b * 1_000_000_000 * bytes_per_param / 1_000_000_000 return weight_gb for bits in (16, 8, 4): gb estimate_weight_gb(770, bits) print(f{bits}-bit: about {gb:.0f} GB)跑出来的结果就是上面表格里的数字。注意这里用的是十进制 GB没有包含任何运行时额外开销所以只适合做第一轮可行性判断。你在规划预算时建议在这个基础上再乘 1.3 到 1.8。3.2 本地部署硬门槛显卡只是起点通信和散热才是大坑可能有人会想那我直接去云上租 8 张 A100 不就行了理论上是可行的但实际落地还有几个隐形成本。第一多卡通信要求。MoE 推理时的 All-to-All 通信非常依赖卡间互联带宽8 张卡如果是通过 PCIe 连接带宽瓶颈会非常酸爽通常需要支持 NVLink 或 RoCE 这类高速互联的集群。第二推理框架要选对。一个 770B MoE 模型如果只在 Hugging Face Transformers 里加载然后写个循环生成大概率慢到怀疑人生。你需要用支持专家并行、连续批处理、Paged Attention 这些特性的推理框架比如 vLLM、SGLang 或 TensorRT-LLM。选型时还要看这些框架对这次 Hy4 preview 的适配进度通常开源社区会在第一时间跟进但你需要多关注版本分支和 issue。第三长期运行的成本。云上的 8 卡 A100 集群按小时收费也是一笔不小的数字用于短期评测还能接受如果要长期在线服务必须引入量化、批处理优化和弹性扩缩容。否则你会发现开源模型的软件授权费用省了硬件运维成本一点没少。3.3 更落地的路线API、托管集群、Agent 工具链那对绝大多数开发者来说正确的打开方式是什么我建议按优先级来。如果你只是想验证模型效果直接用官方或云平台提供的 API 是最快的。先跑通产品逻辑积累足够的评测数据再考虑要不要私有化。评测还没做就着急上集群大概率是烧钱买了教训。如果确实有数据合规要求需要把模型部署在自己的 VPC 或私有环境里可以考虑托管集群方案。现在的云厂商都提供大模型推理服务你上传模型权重或直接选择官方镜像平台帮你处理 GPU 调度、弹性伸缩、监控告警。不要上来就自己租裸金属卡然后从零配环境除非你本来就有一个专职的推理优化团队。最后就是 WorkBuddy 这类 Agent 工具链。它相当于是把模型能力封装成任务流让非工程背景的用户不需要接触部署也能用上 Hy4 preview。模型开源之后真正的价值往往不只在“权重可下载”而在于周边工具到底能不能帮你把模型接到真实业务里。如果你要做周报、做数据分析、做网页原型这类偏业务场景最快验证路径一定是 WorkBuddy 而不是自己扛模型。3.4 开源协议和商用合规清单没你想的那么简单每次大模型开源我都会强调一条原则不要把“开源”直接等同于“免费商用”。模型开源和软件代码开源不完全一样模型权重可能受额外条款约束。这次 Hy4 preview 如果后续你想商用建议对照这几项逐一确认模型许可证是什么是 Apache 2.0、MIT还是自定义的模型许可是否有“月活用户超过一定数量需要另行申请”这类条款是否可以基于它做微调微调后的权重是否仍受原许可证约束生成内容有没有特殊限制比如是否需要标识 AI 生成、不能用于某些高合规行业如果同时使用了开源代码库还要检查代码库自身的许可证。很多团队在项目原型阶段完全不在意协议等产品上线、开始有收入之后收到合规函才慌。看一个模型能不能用先把许可文件从头到尾读一遍这一小时别省。4. WorkBuddy 免费两周重点不是“省了多少钱”而是你能验证什么如果你不是算法工程师前面几部分可能看着会有点远。没关系这次发布里离你最近的部分是 WorkBuddy。接下来的内容我会按功能拆解再到实操尽量让你打开之后可以直接照做。4.1 为什么说 WorkBuddy 不是普通聊天助手现在市面上的聊天助手很多但用完你会发现它们多数只擅长“生成文字”不擅长“把事情办完”。比如你让它做一份报表它能给你一份 Markdown 表格但很难真正读取你上传的 Excel、按你的模板生成 PPT再帮你打包下载。WorkBuddy 这类产品要解决的恰恰是“从生成到执行”这一段。它本质上是一个 AI 工作台也叫 Agent 工作台。你可以在里面上传文件、配置任务流程、调用模型甚至把多个工具串成一个自动化流程。模型在这里更像是“大脑”而 WorkBuddy 提供了“手和脚”它能读取文档、调用搜索、生成网页、执行脚本然后给出一个完整可交付的结果。这种设计大大降低了使用门槛你不需要自己懂 Prompt 工程也不需要对 API 有任何了解。我也建议你把 WorkBuddy 理解成“一个可以随时指挥的实习生”而不是“搜索框”。给它一个清晰的目标和边界它能把脏活累活接过去但如果你连自己想要什么都没有想清楚那它也会回复一堆看起来很对但没有落地价值的内容。4.2 和 CodeBuddy 的区别一个面向程序员一个面向业务执行很多人看到 WorkBuddy 这个名字会想到 CodeBuddy。两者确实有交集但核心使用场景有明显差异。CodeBuddy 更像是给程序员的结对编程工具强调在 IDE 里理解代码仓库、补全代码、修复报错、跑测试。而 WorkBuddy 更侧重办公和业务侧的任务比如资料整理、内容生成、流程编排、报表产出。可能你会问那它能写代码吗也可以写但它更擅长的是把一个自然语言业务需求变成一个小工具、一个网页、一段自动化脚本。比如运营人员可能要做一个活动报名页不需要手写 HTML 和 CSS直接把需求描述给 WorkBuddy它能生成一个可以打开的页面。对没有工程背景的人来说这种交互方式更友好对程序员来说则像是多了一个会做杂活的助手能节省不少碎片化时间。4.3 限时免费用你真正要验证的是这三件事免费两周听起来像薅羊毛窗口但如果你只是随便玩一下可能什么都验证不出来。我建议把自己当作用户研究负责人带着三个问题去测试。第一模型能力边界在哪里。面对不同的任务类型它是理解得更好还是只会套模板这决定了你敢不敢把它放进核心工作流。第二工具调用链是否顺畅。多步骤任务会不会中断读取文件是否会乱码长任务后台运行是否稳定这些小问题才是实际工作中最消磨耐心的。第三你自己的任务拆解能力够不够。用 WorkBuddy 的过程也是你学习“如何跟 AI 协作”的过程任务目标越清晰结果就越可控。免费期正好是一个试错成本极低的训练窗口。4.4 领取免费权益时的几个注意事项不同活动的领取方式不一样但有几个通用提醒。先确认活动页面的时间计算方式有些按自然日两周有些按首次激活后的 14 天尽量在准备充足之后再激活别在没时间研究时贸然开启。其次认真看免费版的额度边界是有任务次数限制还是限制对话轮次还是只给你某些模型选型搞清楚之后再做规划否则跑到一半发现额度不够就尴尬了。最后也是最重要的别一上来就把公司核心数据传进去。你至少要等确认了数据存储位置和隐私条款之后再做敏感数据测试。用公共示例数据先跑通流程永远是更稳妥的做法。5. WorkBuddy 实操手册三件事帮你快速用回本了解完工具定位之后就看具体怎么用了。下面三个场景是我认为门槛低、见效快、能代表 WorkBuddy 核心能力的真实任务建议你按顺序做一遍相当于完成一次从入门到进阶的练习。5.1 场景一把一堆杂乱资料变成一份能直接汇报的文档最基础的用法是“资料整理 结构化输出”。你可以准备一个文件夹里面放两三份 PDF、一个 Excel 和一个网页链接然后新建任务在任务描述里写清楚你的目标。比如请阅读 uploads 文件夹里的资料包括 3 份行业报告和 1 份历史销售数据。 帮我整理成一份“行业趋势与业务建议”文档 1. 提取每个报告的核心结论 2. 结合销售数据找出趋势变化和关键风险 3. 输出为 Markdown 文档分节清晰每节不超过 200 字 4. 如果数据之间有冲突请明确标注不确定的地方。这个任务看起来简单其实能同时验证 WorkBuddy 的文件读取能力、信息提取能力和结构化输出能力。我自己的经验是第一次跑这种任务时不要只给它一句话要求最好把文件名、输出格式、长度限制都写清楚。你写得越具体它返工的可能性越低。5.2 场景二用自然语言生成一个完整的活动落地页第二个值得尝试的场景是让 WorkBuddy 直接生成网页。你不一定要是程序员也可以把一个需求描述出来让它产出可运行的 HTML 页面。比如帮我生成一个“AI 办公体验周”活动报名页 - 主题色使用蓝色系风格现代简约 - 包含活动时间、报名按钮、往期回顾图片占位区 - 生成完整 HTML 文件不要使用外部依赖的框架 - 页面需要适配手机端。这里你可能会发现模型生成一个静态页面的速度非常快但如果你要更复杂的交互比如表单提交、数据存储单靠一次生成可能不够。更好的姿势是把它当作“前端实习生”先让它做一版出来你提出修改意见它再迭代。我以前做原型时经常用这种对话方式快速完成页面草稿整体效率比从零开始写高很多。5.3 场景三沉淀一个你自己的 Skill让复杂工作一键复用如果你在第一个场景里积累了一套比较满意的任务模板下一步就是把它做成 Skill。Skill 的本质是把你刚才写的任务描述、约束条件、处理流程保存成一个“技能包”下次面对类似任务时不需要重新输入大段需求直接调用 Skill 就可以。具体操作一般是进入 WorkBuddy 的技能或模板管理页面新建一个 Skill填写名称、适用场景描述和处理步骤然后把刚才那段有效的提示词填进去。你还可以把你的行业术语、输出规范、常见坑都写进 Skill 描述里相当于给 AI 留下一份“操作手册”。很多人低估了这个功能的长期价值。我自己在使用各种 Agent 工具时有个感受真正拉开效率差距的不是某一次对话的 Prompt 写得好不好而是你能不能把那些有效流程固化成可复用资产。两周免费期内如果你能沉淀出两三个高频使用的 Skill那这次体验的价值就很扎实了。5.4 实操时的几个质量校验方法用 WorkBuddy 跑任务时建议每次都做一个“输出质量检查”不要拿到结果直接就用。我会先做三件事第一随机挑一个数据点回源文件里核验确认它没有编造数字第二看它是不是严格按你的输出模板做了如果没做先别急着改内容而是修改指令里的格式约束第三把它给出的“建议”和“结论”分开看搞清楚哪些是基于数据的客观陈述哪些是模型基于常识的推测。另外一个很实用的小技巧是在任务描述里加一句“如果信息不足请明确回答不知道不要猜测”。这句话能显著减少幻觉带来的误导。对业务使用者来说模型的“自信”未必可信反而是能主动承认不确定的模型更适合放进生产流程。6. 我在实操中遇到的高频问题排查记录这部分内容可能没有前面那么“顺”但从真实使用体验来说发现问题、解决问题的过程往往更值得收藏。我把自己和身边朋友在类似工具、类似模型上踩过的坑整理成了一个速查表后面又挑几个重点案例展开说。问题现象可能原因建议处理方式任务一直卡在“思考中”任务太长工具循环次数过多拆成小任务降低单次复杂度回答内容很流畅但数字对不上模型没有真正解析文件或只读了部分内容追问来源要求它引用文件具体位置频繁提示超时或限流免费额度并发有限或上传文件太大错峰使用精简上下文后再重试生成结果不遵守输出格式提示词里格式约束不够明确给出“必须包含的章节”和“禁止出现的内容”免费期结束后扣费没有留意自动续费或额度规则提前检查账号设置必要时关闭自动续费6.1 任务一直卡在“思考中”大概率是任务粒度太大这种问题最常出现在你一次性丢给它一个非常复杂的任务时比如“把公司过去三年的所有数据整理成完整经营分析报告”。它的思考过程需要很多步只要其中有一步工具调用超时或模型输出不稳定整个任务就会卡住。我的处理方式很简单把大任务拆成几个阶段先让它读取数据并输出数据摘要再让它基于摘要生成结论最后再让它套模板出报告。每一步都让它先保存中间结果或输出一段总结。好处有两个一是即使后面某一步失败你也保留了之前的工作成果二是你可以随时检查每个中间环节是否符合预期避免最后才发现模型理解方向从一开始就偏了。6.2 回答很像样但数据全是编的别慌AI 在工具链里最危险的表现是“一本正经地胡说八道”。有时候你问它某个 Excel 里的数值它没有真正读取文件而是凭经验给出一个看似合理的数字。这种问题在 Agent 场景里必须零容忍。排查思路是这样的先要求它直接引用文件里对应的行和列如果它做不到说明它没有成功调用文件解析工具。你可以在任务描述里强调“所有数字必须来自上传文件来源不确定时不要输出”再观察结果。如果还是有问题那就换一种更小的测试文件比如只有五行数据的 CSV先确认工具调用链路本身是通的。6.3 限流、超时和高并发免费期最常见的隐形天花板免费额度通常会有并发限制也可能因为用户量短时间暴涨导致服务排队。遇到这种情况第一选择是错峰避开工作日上午这些高峰时段第二是给任务“减负”把几十页的 PDF 拆成关键章节或只上传最近一个月的数据而不是一整年。少传一点文件就少一次解析开销也降低限流概率。如果任务执行到一半提示超时先检查是否输出了部分结果。很多平台支持断点续跑或重新运行你可以把已经完成的内容复制出来再让它在剩余的基础上继续不一定要整个任务全部重跑。6.4 免费期结束前你需要做一次“资产备份”限时免费最大的坑不在领取而在结束。我在不少类似活动里看到用户注册之后放着没用等想起来时免费期已经过了或者免费期结束后聊天记录、生成的 Skill 被清理。所以你在体验过程中如果生成了有价值的内容建议及时导出到本地。另外如果你建立了自己的 Skill也要看它是否支持导出。能导出的就备份成文件不能导出的至少把技能的描述和提示词复制下来。这样即使后续不想付费你的方法论仍然留存在自己手上。对于大多数 Agent 工具决定你愿不愿意长期付费的往往不是模型本身而是你已经在里面沉淀了多少不可替代的资产。6.5 我对