Qwen3.8-Max实战：从零构建十倍速学习Skill与长程任务指南

2026年8月3日，Qwen3.8-Max正式上线。相比此前的Qwen3.8-Max-Preview，正式版已经成为Qwen3.8系列的旗舰模型，采用2.4万亿参数MoE架构，支持100万Token上下文，同时具备文本、图片和视频理解、Function Calling、结构化输出、上下文缓存等能力。官方尤其强调了它在Coding、办公自动化和长程Agent任务上的提升。

这次我没有继续用它做普通问答，而是尝试了一个更完整的任务：把原本需要人工逐步执行的“十倍速学习方法”封装成一个Skill。

目标很简单：用户只输入一个学习主题，例如“RAG”“强化学习”或者“量化交易”，Agent就自行完成资料收集、知识拆解、学习路线设计、内容生成、验证和最终HTML制作。

真正测试的并不是“Qwen3.8-Max会不会写HTML”，而是它能不能在一个持续时间较长、文件较多、步骤互相依赖的任务里保持目标一致。

一、为什么用Qwen3.8-Max做Skill

Skill开发和普通Prompt最大的区别，是任务不会在一轮对话内结束。

一个完整Skill可能需要经历：

理解原始方法论
→ 抽取流程
→ 设计Skill目录
→ 编写规则文件
→ 创建参考资料
→ 执行资料搜索
→ 生成学习内容
→ 验证结果
→ 制作HTML
→ 最终检查

这类任务对模型主要有四个要求。

第一是长上下文。Qwen3.8-Max目前支持100万Token上下文，最大输出约13万Token，思考模式下还提供更大的推理预算。

第二是工具调用。Skill不是单纯生成文字，需要模型不断读取文件、搜索资料、执行脚本、检查结果。

第三是长程规划。如果每完成一步就忘记最初目标，最终产出的Skill目录很容易变成一堆彼此独立的Prompt。

第四是多模态能力。正式版Qwen3.8-Max原生支持Image、Text和Video输入，这意味着学习Skill未来不只能处理论文和网页，也可以继续扩展到图片、课程视频和图表材料。

二、第一步不是写Skill，而是把需求变成执行规则

最开始我没有直接让模型创建文件。

我先把原来的“十步学习法”文章放入项目，让Agent完整阅读，然后只给一个目标：

把这套十步学习方法改造成一个可重复调用的Skill。

用户通常只提供一个学习主题。

Skill需要自行判断：
需要查哪些资料；
每个阶段做到多深；
哪些内容需要继续验证；
最终生成一个可以交互浏览的HTML学习页面。

这里最重要的一点是：不要一上来让模型写代码。

先让模型反问需求。

例如：

• 面向小白还是专业用户？
• 每一步是否必须产生独立结果？
• 是否需要联网查论文？
• 用户是否允许中途确认？
• HTML是学习报告还是交互式学习系统？
• 最终是否需要知识测试？
• 搜索失败时如何降级？

经过几轮需求澄清以后，再开始生成Skill，后面的返工会明显减少。

三、Skill应该拆成“编排层+执行层”

最终比较稳定的结构并不是把十个步骤全部写进一个巨大的SKILL.md，而是进行分层。

例如：

tenx-learning/
├── SKILL.md
├── references/
│   ├── research.md
│   ├── knowledge-map.md
│   ├── examples.md
│   ├── verification.md
│   └── html-spec.md
└── templates/
    └── learning-page.html

其中SKILL.md只负责三件事情：

1. 判断什么时候应该调用Skill；
2. 定义十个阶段的执行顺序；
3. 说明什么时候读取对应reference文件。

真正复杂的执行规则拆到references目录。

这样做有一个很实际的好处：减少主上下文污染。

如果所有搜索规范、HTML样式、学习理论和验证标准都一次性加载，模型刚开始执行任务时就会背着大量暂时用不到的信息。

Skill应该在执行到某一阶段时，再读取对应规则。

这比“做一个超级Prompt”更适合长程Agent。

四、用RAG测试一次完整学习流程

Skill完成后，我用“RAG”作为测试主题。

Agent没有立刻开始生成一篇RAG介绍，而是先确认学习目标，例如：

当前基础是什么？
学习RAG主要为了开发项目，还是理解原理？
是否需要阅读论文？
需要掌握向量数据库和Embedding到什么程度？
最终是否需要完成一个小型项目？

确认之后，它再进入资料阶段。

最终学习结构大致覆盖：

概念建立
→ 核心组件
→ Embedding
→ 向量检索
→ Chunk策略
→ Rerank
→ Query Rewrite
→ Advanced RAG
→ Agentic RAG
→ 评估体系

同时加入论文、代码示例、典型错误和知识测试。

这与普通“请给我一份RAG教程”的区别很明显。

后者的目标是生成内容，而Skill的目标是生成一条学习路径。

最终HTML也不是一篇长文章，而是十个步骤组成的交互式页面：

• 左侧展示学习阶段；
• 右侧展示当前学习内容；
• 每一步显示本阶段目标；
• 展示输入资料；
• 展示阶段性结论；
• 提供练习和验证问题；
• 最后给出完整知识地图。

这样生成出来的内容才更接近学习系统，而不是AI整理出来的一份资料。

五、长程任务真正难的是上下文治理

实际跑这种任务后会发现，100万Token上下文虽然很大，但依然不应该把所有资料无脑塞进去。

Qwen3.8-Max官方上下文长度为100万Token，最大普通输入约99万Token。

但“能够放进去”和“应该放进去”完全是两回事。

如果Agent先后搜索几十个网页、几篇论文，再运行大量脚本，原始日志很快就会占据大量上下文。

比较有效的处理方式是：

搜索代理
→ 只返回重要资料和结论

研究代理
→ 整理争议点和关键知识

主代理
→ 保存阶段结果

生成代理
→ 基于整理后的资料制作最终内容

也就是说，让不同Subagent承担不同类型的工作，而不是一个主Agent从头查到尾。

对长程Skill而言，比“上下文有多大”更重要的是：

进入上下文的信息是否仍然有价值。

六、另外两个任务也能检验长程能力

除了学习Skill，还可以用两类任务测试Qwen3.8-Max。

1. Three.js复杂页面

例如要求Agent完成一个3D街区，包括：

• 道路；
• 建筑；
• 店铺；
• 人行道；
• 路灯；
• 树木；
• 车辆；
• 红绿灯；
• 基础交互。

这种任务测试的不只是代码生成，而是文件组织、视觉理解、浏览器反馈和连续修复。

Qwen3.8-Max正式版已经支持原生视觉输入，因此可以把网页截图重新反馈给模型，让它根据实际渲染结果继续调整。官方把这种视觉能力描述为贯穿规划、执行和验证流程。

2. 多文档研究

另一个比较适合的测试，是一次放入大量企业材料，让Agent最终生成完整方案。

正确的方法并不是：

20个文档
→ 全部塞入Prompt
→ 写报告

而是：

材料分类
→ 分代理阅读
→ 提取事实
→ 建立主题索引
→ 发现冲突
→ 生成章节
→ 跨章节检查
→ 最终整合

长上下文的真正用途，不是取消信息管理，而是让模型拥有更大的“工作空间”。

七、多模型协作会成为Skill的重要组成部分

一个复杂Skill不一定所有步骤都应该使用同一个模型。

例如：

当Skill开始运行几十个步骤以后，“每一步都调用旗舰模型”并不一定合理。

因此更成熟的结构是：

Skill
  ↓
任务分类
  ↓
模型路由
  ↓
不同模型完成不同阶段

这时候就会涉及大模型API聚合和统一模型管理。

如果项目除了Qwen3.8-Max，还要同时调用GPT、Claude、DeepSeek、Kimi等模型，可以在业务和模型之间增加统一接入层。星链4SAPI这类大模型API中转站就是其中一种实现方式，通过相对统一的API入口管理不同模型，减少业务代码里维护多组Key、Base URL和模型适配逻辑。

其公开资料目前已经提供Qwen系列模型接入说明，并将多模型调用作为统一接口场景之一。

一个简单的调用结构可以写成：

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["LLM_API_KEY"],
    base_url=os.environ["LLM_BASE_URL"]
)

response = client.chat.completions.create(
    model=os.environ["MODEL_ID"],
    messages=[
        {
            "role": "user",
            "content": "分析以下学习资料，输出关键知识结构。"
        }
    ]
)

print(response.choices[0].message.content)

这样Skill本身关注的是“当前阶段需要什么能力”，而不是把某个供应商写死在代码中。

当然，大模型API中转站主要解决统一接入问题，并不会让底层模型能力发生改变。用于长程Agent时仍应确认模型版本、上下文限制、Tool Calling和多模态字段是否完整支持。

八、从个人Skill到企业Agent，本质是同一个问题

这次做“十倍速学习Skill”之后，一个比较明显的感受是：

未来很多AI应用并不会表现为一个Prompt，而会表现为一套流程。

例如：

企业研究Agent
销售分析Skill
竞品研究Skill
代码迁移Skill
知识培训Skill
招聘分析Skill

它们共同面对几个问题：

• 怎么拆任务；
• 怎么控制上下文；
• 怎么选择模型；
• 怎么判断任务完成；
• 怎么让失败可以恢复；
• 怎么控制Token成本；
• 怎么保存中间结果。

因此，企业选择大模型平台时也不应该只问“有没有GPT或者Qwen”。

更值得检查的是：

1. 模型覆盖是否满足任务；
2. 是否能够通过统一API切换；
3. Tool Calling是否完整；
4. 是否能统计不同模型用量；
5. 长任务失败以后能否恢复；
6. 多模型路由是否容易实现。

对于规模不大的项目，可以直接使用模型官方API；需要同时测试多个模型时，可以通过星链4SAPI这类聚合接入层减少重复适配；规模继续扩大后，再加入LiteLLM或企业内部Gateway处理权限、路由和成本治理。

总结

这次使用Qwen3.8-Max构建「十倍速学习Skill」，真正值得记录的并不是模型生成了多少代码，而是它已经能够参与一个相对完整的软件工程流程：

需求理解
→ 方案设计
→ 文件拆分
→ 工具执行
→ 信息检索
→ 内容生成
→ 结果验证
→ 最终交付

正式版Qwen3.8-Max拥有2.4万亿参数、100万Token上下文以及原生文本、图片和视频理解能力，并针对Coding、办公和长程Agent任务进行了强化。

但实战同样说明了一件事：

模型能力越强，工作流设计反而越重要。

一个没有任务拆解、上下文管理和验证机制的超长Prompt，很难充分发挥100万Token上下文的价值。

而当Skill、Subagent、模型路由和大模型API中转站逐渐组合起来以后，AI开发的重点也开始从“怎么写一个更好的Prompt”，转向“怎么设计一套可以重复运行的智能工作流”。

这可能才是Skill真正值得关注的地方。