2.1 office：总路由与渐进加载

它是谁

office 是这组技能里最特殊的一个：它自己不干活，只负责判断该进哪个子技能。官方对它的描述是一句话——创建、编辑、检查或转换 Office 文档、电子表格与演示文稿。

整个技能族的职责，官方原文是：为文档工作流提供渐进加载的 Office 创作与 CLI 操作技能。 这句话里有两个关键词：渐进加载、创作与 CLI 操作。前者决定了它的成本结构，后者决定了目录里七个技能分成两类。

把它理解成前台分诊护士：任务进来，它看一眼症状，指对应科室。真正干活的是后面的六个技能。

七个技能一张表

目录里常驻的只有七条摘要，每条只有名称加描述，没有正文：

技能 官方描述（逐字） 类型
office 创建、编辑、检查或转换 Office 文档、电子表格…… 路由
office-docx Create, read, edit, and validate Word documents (.docx). 创作
office-xlsx Read, create, edit, and validate Excel workbooks, data, and formulas. 创作
office-pptx Create, read, edit, and validate PowerPoint presentations (.pptx). 创作
office-export-pdf Convert an Office document to a requested PDF with LibreOffice... 操作
office-render Render requested document images or inspect visual layout with... 操作
office-recalculate Refresh spreadsheet formula caches and verify calculated values. 操作

两类技能的执行基础不一样：创作技能使用选定的 Python 库，操作技能提供配置的 Node 与 LibreOffice Kit CLI 路径。SDK 与 Desktop 载体分别挂载技能提供者和依赖查询，装好后你在会话里看到的就是这七条摘要。

模型在会话目录里只能读到 name 与 description，从不使用正文或绝对文件路径。选中哪一个，取决于 description 写得准不准，也取决于你的任务描述清不清楚。

路由表

你的意图 路由到 典型说法
写 / 改 Word office-docx 把这份报告改成正式公文格式
做 / 改表格 office-xlsx 按这个 CSV 生成带公式的台账
做 / 改 PPT office-pptx 把这周的周报做成五页汇报稿
转 PDF office-export-pdf 交付版导出 PDF
看排版 / 出图 office-render 渲染第一页给我看看
公式结果不可信 office-recalculate 打开后公式显示的是旧值

为什么需要路由技能

七个技能如果平铺给模型选，会出现两个问题：

  1. 误选。任务只是把这个表格里的数字读出来，模型可能选了负责创建的技能，做出一堆多余动作。
  2. 重复加载。一个复杂任务可能同时需要编辑与渲染，路由可以把顺序排好，避免模型同时抓两份完整说明互相打架。

有了路由层，模型的决策被压缩成一次：先选 office，再由技能内部的指引决定后续路径。

渐进加载是怎么跑的

官方描述的加载路径，翻译成文字流程图是这样的：

会话开始
  └─ 初始目录：七条摘要（名称 + 描述）常驻，成本极低
        ├─ 任务与办公无关
        │     └─ 不加载任何 Office 技能，摘要继续待命
        ├─ 办公任务
        │     └─ 调用 skill 工具加载 office 路由说明
        │           ├─ 需要创作或编辑
        │           │     └─ 进入 office-docx / office-xlsx / office-pptx 之一
        │           └─ 需要图片或外观修改
        │                 └─ 走 office-render
        └─ 纯操作任务（转换、重算等）
              └─ 直接进入对应技能，不过路由

两级的收益在技能数量上去之后才明显：装三十个技能，日常开销仍然是三十条摘要，而不是三万行指令。这是技能体系控制上下文成本的核心手段。

一条容易忽视的规则：宿主不按扩展名注入

渐进加载的官方规则里有一句关键的话：模型按任务选技能，宿主不会根据文件扩展名注入完整说明。

这句话的实践含义很直接：你发给模型一个 .docx，系统不会自动把 office-docx 的完整说明塞进上下文。选不选、选哪个，完全取决于模型对你任务描述的理解。

你的写法 结果
处理这个文件 模型只能猜，可能猜错技能
用 office-docx 技能把这份合同改成公文格式 命中率接近确定性

所以任务描述里带上文件类型和意图，是最便宜的可靠性投资。需要强约束时还可以用 /office-docx 这种用户直调形式，绕过模型自选的随机性——直调走的是人类命令目录，与模型自选是两条独立通道。

外观修改必须渲染的规则

官方为这族技能写了一条贯穿全文的规则，原文要义是：用户要求的外观修改，包括电子表格单元格填充和文本对齐，即使没有明确要求视觉检查，也需要渲染；用户明确要求跳过渲染时以该要求为准。

拆开看是两层：

情形 要不要渲染
改了填充色、对齐、母版、字号这类外观 要，即使你没提看效果
用户明说不用看效果 以用户要求为准，可以不渲染

注意这里覆盖的是电子表格的单元格填充和文本对齐这种最琐碎的外观改动——很多人觉得这算什么视觉问题，但填充色错一行、对齐差一列，交付时就是明面上的事故。唯一例外是用户明确要求跳过渲染，此时以该要求为准。除此之外，外观类改动默认配一次 office-render，这条规则在 2.4 和 2.5 两节还会反复用到。

纯操作任务可以绕过路由

路由的意义在于帮模型选路，但如果任务本身就是纯操作——转个 PDF、刷新一下公式缓存——官方规则说得很清楚：纯操作任务可以直接进入对应技能。

也就是说你不必每次都提 office 这个名字。把需求说清楚，模型自己会判断要不要过路由。写 office 的价值主要在复合任务：既要编辑又要检查，顺序还重要，这时路由的编排能力才体现出来。

启用与配置

这族技能来自 @deepseek-ai/dsh-skill-office，组合配置一行启用：

- name: '@deepseek-ai/dsh-skill-office'

三个可配字段：

字段 默认值 作用
assetRoot 载体资源或包内 assets/ 七个技能目录的绝对路径
node 宿主 Node.js 操作技能用的独立 Node 可执行程序
cli 已安装 Kit CLI CLI 入口绝对路径，设为 false 禁用操作执行

两个要知道的边界。第一，无效技能资源会阻止注册，所以装完发现七个技能没出现，先查 assetRoot 指向的目录是否完整。第二，操作说明加载时只校验现有解释器和 CLI 文件存在，不准备引擎——它不会替你装 LibreOffice。另外资源与执行工具必须位于同一主机，审批、沙箱、取消和输出管理由 Bash 或 PowerShell 负责。

使用建议

建议一：任务描述里带上文件类型。 宿主不按扩展名注入，写清楚是唯一的确定性来源。

建议二：复合任务拆成多轮。 做一份 PPT 并导出 PDF 可以拆成两轮，每轮的技能加载更干净。

建议三：需要强约束时直调。 明确要求走某技能时，用 /office-docx 形式的用户直调。

建议四：涉及外观就先说要渲染。 虽然规则默认要渲染，但你明说一遍，模型执行得更稳。

小结

  • office 是分诊路由，本身不做具体事；六个子技能分创作与操作两类。
  • 渐进加载 = 常驻摘要 + 按需正文，是控制上下文成本的核心手段。
  • 宿主不按扩展名注入，任务描述要写清文件类型与意图。
  • 外观类改动默认必须渲染，除非用户明确要求跳过。
  • 纯操作任务可以直接进入对应技能，不必过路由。

延伸阅读