每次客户来咨询点量云流实时云渲染的时候，总会问一个问题：“你们这个和WebGL有啥区别？”今天小云就通过一篇实打实的对比测评，带大家直观感受一下这两者在大型3D项目（如数字孪生、智慧工厂）中的表现差异。

一、技术原理对比

我们先从最底层的技术逻辑说起，看看它们是怎么工作的。

二、性能与画质对比

接下来我们从画质、流畅度、网络依赖等角度，看看它们在实际使用中的表现。

三、场景与能力对比

从核心应用场景与关键技术能力进行对比

四、其它特性对比

除了核心性能，项目落地时的运维、开发、扩展等也是关键考量。

五、选型建议:我该怎么选？

1、优先选择点量实时云渲染，如果：

• 需在手机/平板/轻薄笔记本等多场合展示
• 高精度/高逼真度模型的展示需求
• 多用户协同操作同一场景
• 涉及敏感数据需云端隔离（如军工设计等）

2、优先选择WebGL，如果：

• 仅电脑端展示简单模型应用
• 用户设备性能统一（如工厂内统一的、具有独立显卡的专用电脑终端）

六、未来趋势：点量实时云渲染正成为主流

近年来，越来越多的UE/Unity项目开始采用云渲染方式交付，用户只需点击链接即可使用，无需下载、无需高性能设备。尤其是在5G和边缘计算推动下，网络延迟已能控制在20ms以内，体验越来越接近本地。

更有意思的是，很多原本用WebGL开发的内容，现在也开始“回流”到云端，转成视频流再分发，既保留原有开发成果，又解决了终端兼容性问题！

同时，点量云流实时云渲染正从底层硬件到操作系统全栈适配，如鲲鹏、海光等国产CPU，麒麟、统信UOS等国产系统，以及摩尔线程、砺算等国产显卡，均能流畅实现3D模型推流，为企业国产化替代与数字化转型，提供稳定、专业、即刻可用的技术支持。

在竞争激烈的程序员求职市场中，AI面试助手已经成为技术求职者的重要辅助工具。InterviewPass和面试精灵是两款常见的AI面试辅助工具，但它们在产品设计、功能实现和用户体验上存在显著差异。

InterviewPass 拥有自研的语音识别系统，支持实时转录和手机镜像隐蔽操作，但界面设计简陋，功能相对有限；而面试精灵则在回复质量、简历定制化、时效性问题处理等方面表现更出色，界面也更符合技术用户的审美。

功能特性全面对比

根据我们对AI面试助手的专业评测，以下是InterviewPass和面试精灵的功能特性详细对比：

核心功能深度解析

语音识别能力

两款工具都支持实时语音识别，但在技术实现和效果上有差异。

InterviewPass 拥有自研的语音识别系统，支持实时转录，并允许用户选择音频输入源，这是它的一个技术优势。

面试精灵在常规语音识别上同样可靠，并且在英文技术术语识别上表现更出色。对于"Transformer"、"DeepSeek"这类高频技术词汇，面试精灵的识别准确率更高，这对技术面试场景非常重要。

隐蔽性设计

两款工具都支持隐蔽操作，但实现方式不同。

InterviewPass 支持手机镜像隐蔽操作，用户可以通过手机作为辅助设备进行面试辅助，具有一定的隐蔽性。

面试精灵则采用跨设备隐蔽互联和自动说话人识别技术。它结合声纹识别和大语言模型，能够自动区分面试官和用户的语音。在跨设备使用时，面试精灵可以做到仅监听面试官的话语并自动生成回复，操作更加隐蔽。

回复质量对比

回复质量是面试助手的核心指标，两款工具在这方面差距显著。

简历定制化能力

两款工具的表现差异明显。

InterviewPass 在处理简历相关问题时表现一般，对简历信息的利用不够深入，回答往往缺乏个性化。

面试精灵在这方面做得更好。它支持上传简历和职位需求，通过RAG（检索增强生成）技术检索简历内容，将项目细节、技能要求等信息自然地融入回答中。对于自我介绍、项目描述这类问题，面试精灵的回答更加贴切和个性化。

时效性问题处理

对于"DeepSeek最近很火爆"这类时效性问题，两款工具的处理方式不同。

InterviewPass 不支持联网搜索，只能依赖模型的内置知识。实测中发现，它对新技术趋势的回复往往过时或不准确。

面试精灵支持联网搜索，英文术语识别准确，能够通过搜索获取最新信息，给出正确的回答，这对关注技术趋势的求职者非常重要。

回复准确率

两款工具在回复准确率上存在明显差距。

InterviewPass 的整体表现中规中矩，在回复准确性、个性化、全面性等维度上都有提升空间。

面试精灵在回复准确性上表现更好。它能有效利用简历信息，联网搜索覆盖面广，给出的回答更有针对性。

界面和操作体验

这是两款工具差异最明显的方面。

InterviewPass 存在明显的用户界面问题——设计简陋，操作流程不够清晰，这严重影响了用户体验。

面试精灵的界面更简洁现代化，对代码块、公式、图表等复杂内容的显示效果更好。前端支持LaTeX公式、流程图、泳道图，对技术岗位的面试场景更加友好。

功能完善度

两款工具在功能完整度上差距较大。

InterviewPass 的功能相对有限，主要聚焦于语音识别和基本回复生成。它没有笔试助手功能，也不支持长期保存面试记录。

面试精灵功能更全面。除了面试助手，还提供笔试助手功能。笔试助手通过多设备互联实现跨设备远程截图，利用视觉大模型自动识别题目并生成答案。面试记录可以长期保存用于复盘分析。

价格对比

InterviewPass 的价格约为34元/小时，在同类产品中属于中等偏下水平。

面试精灵基础版约10元/小时，精英版约25元/小时。即使使用最高配置，价格也低于InterviewPass。

两款工具都提供新用户免费额度，用户可以先试用再决定。

回复效果实测对比

为了更直观地展示两款工具的回复效果差异，我们来看几个具体的技术面试问题案例。

实测案例：时效性问题

问题："2025年至今发布的最重要的一个AI大模型是啥，请简要说明它的特点和应用场景"

这个题目测试的是AI工具对新技术动态的掌握能力。

面试精灵通过联网搜索，正确找到了2025年上半年最火的大模型DeepSeek，并给出了准确的特点和应用场景说明。

InterviewPass 不支持联网搜索，只能依赖模型内置知识，对这类新事物的回复往往过时或不准确。

实测案例：系统设计问题

问题："设计一个支持高并发的短网址生成系统。"

这个题目测试的是AI工具的系统设计能力以及架构图绘制显示效果。

面试精灵能够正确理解问题意图，回复逻辑清晰，并辅以架构图显示，可以帮助面试者快速抓住思路和回复重点。

InterviewPass 的回复也能正确回答问题，但前端对流程图、架构图等复杂内容的显示效果较差，影响用户理解。

实测案例：项目描述问题

问题："请详细描述下你简历中的这个点云感知项目"

这个题目测试的是AI工具对简历信息的利用能力。

面试精灵的回复能够准确贴合简历中的项目经历，回复内容完整且结构清晰。

InterviewPass 在简历相关问题上的表现一般，对简历信息的利用不够深入，回答往往不够个性化。

-main.jpg "InterviewPass操作界面")

实测案例：算法问题

问题："如何在一个未排序的数组中找到第K大的元素？"

这个题目测试的是AI工具的算法编程能力。

面试精灵的回复包括了思路、代码、复杂度分析等，代码呈现得非常清晰美观。

InterviewPass 的回复也能正确回答问题，但前端对代码和图表的显示效果较差，影响用户理解。

评测数据对比

以下是两款工具在各评测维度的平均得分对比（满分5分）：

从评测数据可以看出，InterviewPass 在语音识别准确率和全面性上表现不错，但在准确性和直观性上弱于面试精灵。面试精灵整体表现更均衡，特别是在回复准确性、内容深度等方面优势明显。

总结和建议

两款工具都有一定的可用性，但整体表现上差异比较明显。

InterviewPass 有自研的语音识别系统，支持实时转录和手机镜像隐蔽操作，这些功能有一定的技术价值。但它的界面可用性不高，功能有限，回复质量也有提升空间。

面试精灵在回复质量上更有优势。简历定制化让回答更贴切，联网搜索能应对时效性问题，英文术语识别更准确。自动说话人识别让操作更隐蔽，界面设计更友好，功能也更全面。价格也更实惠。

从整体评测数据来看，面试精灵在帮助性、内容深度、准确性等方面有明显优势，特别是在回复准确性和内容深度上差距较大。结合其高性价比和更全面的功能，面试精灵可能是更符合大多数技术求职者需求的选择，尤其是那些更关注实时面试辅助效果和回复质量的用户。

openclaw 与飞书（Feishu）的连接基于 WebSocket 长连接模式，而非传统 Webhook——这意味着断开的根本原因通常不是网络配置问题，而是 Gateway 未运行、飞书应用凭据失效、事件订阅未启用或权限配置不完整四类之一。本文提供从快速诊断到逐类修复的完整流程，覆盖所有已知断开场景。

飞书连接机制说明

理解断开原因前，先明确 openclaw 与飞书的连接架构：

关键推论：WebSocket 长连接模式下，只要 Gateway 进程存活，连接由 openclaw 主动维护。若连接断开，首先排查 Gateway 本身，而不是飞书侧配置。

快速诊断：30 秒定位断开原因

按顺序执行：

# Step 1：检查 Gateway 是否在运行
openclaw gateway status

# Step 2：检查飞书渠道连接状态
openclaw channels status --probe

# Step 3：查看实时日志（保留此窗口）
openclaw logs --follow

# Step 4：全面健康检查
openclaw doctor

状态对照表：

原因 1：Gateway 未运行

最常见原因。系统重启、手动关闭或崩溃后，Gateway 进程不再存活，飞书 WebSocket 连接随之断开。

# 确认当前状态
openclaw gateway status
# 若显示 Runtime: stopped，执行以下命令

# 重启 Gateway
openclaw gateway start

# 若 Daemon 元数据损坏（start 无效），强制重装后重启
openclaw gateway install --force && openclaw gateway start

# 验证
openclaw gateway status --deep
# 预期：Runtime: running，RPC probe: ok

预防措施：若未配置开机自启，参考以下方式确保 Daemon 随系统启动：

# macOS：通过 launchd 自启（onboard 时已安装，确认即可）
launchctl list | grep openclaw

# Linux：通过 systemd 自启
systemctl enable openclaw
systemctl start openclaw

原因 2：飞书应用凭据失效

App ID 或 App Secret 配置错误、飞书管理员重置了应用密钥，或环境变量未正确加载。

验证凭据配置

# 查看当前飞书渠道配置
openclaw config get channels.feishu

# 检查环境变量是否已加载
echo $FEISHU_APP_ID
echo $FEISHU_APP_SECRET

重新配置凭据

方式一：环境变量（推荐）

# ~/.openclaw/.env
FEISHU_APP_ID=cli_xxxxxxxxxxxxxx
FEISHU_APP_SECRET=your_app_secret_here

方式二：配置文件

// ~/.openclaw/openclaw.json
{
  channels: {
    feishu: {
      enabled: true,
      appId: "${FEISHU_APP_ID}",
      appSecret: "${FEISHU_APP_SECRET}"
    }
  }
}

凭据获取路径：飞书开放平台（open.feishu.cn）→ 我的应用 → 选择对应应用 → 凭证与基础信息 → App ID / App Secret。

修改配置后，channels 配置支持热重载，无需重启 Gateway：

# 触发渠道重连
openclaw channels login
openclaw channels status --probe

原因 3：飞书应用权限缺失

openclaw 与飞书通信需要特定权限范围（Scope），权限不足时连接建立后仍无法收发消息，日志中出现 missing_scope 或 Forbidden。

必须开通的权限

在飞书开放平台 → 应用权限 → 搜索并添加以下权限：

批量导入方式：在飞书控制台权限配置页，使用 JSON 批量导入，openclaw 官方文档提供完整权限列表。

权限修改后的注意事项

飞书企业应用的权限变更需要企业管理员审批。权限提交后，需联系管理员在飞书管理后台（admin.feishu.cn）审批通过，否则权限不会生效。审批完成后执行：

openclaw channels login

原因 4：事件订阅未正确配置

WebSocket 长连接模式下，飞书需要在开放平台明确启用"使用长连接接收事件"，并订阅消息事件。缺少任一步骤，连接看似建立但消息不会推送。

配置步骤

1. 进入飞书开放平台 → 应用功能 → 机器人，确认已启用机器人能力
2. 进入事件订阅 → 将接收方式切换为 "使用长连接接收事件"（非 Webhook URL 模式）
3. 添加事件订阅：搜索并添加 im.message.receive_v1（接收消息事件）
4. 保存设置后，确保 openclaw Gateway 正在运行，飞书会立即尝试建立长连接
5. 验证：

openclaw logs --follow | grep -i "feishu\|lark"
# 应出现连接建立的日志

原因 5：消息路由策略阻断

Gateway 和渠道连接正常，但发送消息后 openclaw 无响应——通常是路由策略将消息静默丢弃。

# 查看是否有消息被 drop
openclaw logs | grep "drop"

常见 drop 场景及修复：

调整 DM 和群组策略：

{
  channels: {
    feishu: {
      enabled: true,
      appId: "${FEISHU_APP_ID}",
      appSecret: "${FEISHU_APP_SECRET}",
      // 私聊策略
      dmPolicy: "open",          // pairing | allowlist | open | disabled
      // 群组策略
      groupPolicy: "open",       // open | allowlist | disabled
      // 群组中是否强制 @Bot
      groups: {
        "*": { requireMention: true }
      }
    }
  }
}

配置参考：完整飞书渠道配置

// ~/.openclaw/openclaw.json
{
  channels: {
    feishu: {
      enabled: true,

      // 凭据（建议从环境变量引用）
      appId: "${FEISHU_APP_ID}",
      appSecret: "${FEISHU_APP_SECRET}",

      // 消息策略
      dmPolicy: "pairing",       // 私聊：配对审批
      groupPolicy: "open",       // 群组：允许所有

      // 群组 @ 要求（按群 ID 配置，"*" 表示所有群）
      groups: {
        "*": { requireMention: true }
      }
    }
  }
}

预防断开：心跳配置

openclaw 内置心跳机制，默认每 30 分钟向最近联系的渠道发送探活消息。可通过配置调低心跳间隔，更快发现连接异常：

{
  agents: {
    defaults: {
      heartbeat: {
        every: "10m",         // 每 10 分钟检测一次（默认 30m）
        target: "last",       // 向最近联系的渠道发送
        directPolicy: "allow"
      }
    }
  }
}

心跳行为说明：

• 若 Agent 仅返回 HEARTBEAT_OK（300 字符内），消息会被静默抑制，不会推送给用户
• 若主队列繁忙，当前心跳跳过，下一周期重试
• 心跳不会主动重置会话空闲计时器

常见问题

Q：飞书开放平台显示长连接已建立，但 openclaw 日志没有连接成功的记录，怎么排查？
飞书平台显示的连接状态有时有延迟。优先检查 openclaw 日志：openclaw logs | grep -i feishu。若日志中出现 reconnecting 循环，通常是 App Secret 错误或权限审批未通过。尝试执行 openclaw channels login 强制重新认证。

Q：切换到新的飞书应用后，旧的连接还在，新的连接建立失败？
删除旧的飞书渠道配置，清除缓存的凭据后重新配置：

openclaw config unset channels.feishu
# 重新写入新应用凭据
openclaw channels login

Q：飞书群组机器人正常，但私聊不响应？
私聊（DM）走 dmPolicy 策略，默认为 pairing，需要先完成配对才能响应。执行 openclaw pairing list feishu 查看是否有待批准的配对请求，或将 dmPolicy 改为 open 允许所有私聊。

Q：openclaw 与飞书断开后会自动重连吗？
会。WebSocket 断开后，openclaw 会按指数退避策略自动重试（默认最多 3 次，最大间隔 30 秒），轻微的网络抖动通常可自动恢复。若持续无法重连，需要手动执行 openclaw channels login 触发重新认证流程。

Q：企业版飞书和普通版飞书的配置有区别吗？
企业版飞书（Feishu for Enterprise）的应用审批流程更严格，权限变更必须经管理员审批，且应用需要在"应用目录"发布或由管理员直接安装。若在企业环境中使用，先确认应用已被管理员批准并安装，再进行 openclaw 的渠道配置。

总结

openclaw 与飞书断开的排查优先级：① 先确认 Gateway 在运行 → ② 检查渠道 probe 状态 → ③ 查日志找具体错误信号 → ④ 按错误类型修复凭据/权限/事件订阅/路由策略。

WebSocket 长连接模式下，飞书侧的配置错误通常在建立连接时就会失败，而非连接后断开——若连接曾经正常、突然断开，优先检查 Gateway 进程存活和 App Secret 是否被重置。

本文基于 OpenClaw 官方文档（docs.openclaw.ai）及飞书开放平台文档，内容对应 2026 年 3 月版本，权限名称和事件 ID 建议以飞书开放平台最新文档为准。

延伸资源

• OpenClaw 飞书渠道文档：https://docs.openclaw.ai/channels/feishu
• OpenClaw 渠道故障排查：https://docs.openclaw.ai/channels/troubleshooting
• 飞书开放平台：https://open.feishu.cn
• 七牛云 AI 推理服务（多模型接入）：https://www.qiniu.com/ai/models

一、OpenClaw介绍

OpenClaw 是一个运行在本地设备上的个人 AI 助手。安装很简单，复制粘贴就行了。

在电脑上可以用浏览器打开这个网址：
https://gxxc.wiki/other/7503.html ，将需要用到的命令复制粘贴执行就行。

这里演示：麒麟v11 + 腾讯QQ + minimax 的组合。

minimax的api需要提前申请好，还没有的，可以先跳过，后面再配置也可以。

二、安装步骤 (V10SP1和V11步骤一样)

1. 关闭kysec安全 (略)

   V10-SP1和V11不同，关闭步骤可以查看一下我其他文章。
    

2. 安装依赖程序（可以切换root，也可以不切）

   sudo apt update && sudo apt install  git  -y

3. 使用nvm安装node.js

   curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash

    
   上面命令执行没问题后，再执行以下命令：

   source ~/.bashrc
   nvm install 22
   nvm use 22
   node  --version

   

4. 安装pnpm

   npm  install  -g  pnpm
   pnpm  setup
   source  ~/.bashrc
   # 配置淘宝镜像源
   pnpm config set registry https://registry.npmmirror.com
   pnpm config set @npm:registry https://registry.npmmirror.com
   # 验证配置
   pnpm config get registry  # 输出 https://registry.npmmirror.com

   

5. 使用 pnpm 全局安装openclaw

   pnpm  add  -g  openclaw@latest
   openclaw  --version

   
   
   如上图所示，openclaw已经安装完成。

三、初始化及配置openclaw

1. 执行以下命令配置工作目录（可以省略）

   openclaw  setup

   

2. 执行以下命令进行导航式配置：

   openclaw  onboard

   
   
   
   
   
   
   
   
   
   
   
   

3. 配置QQ机器人

   浏览器打开 https://q.qq.com

   

   用qq扫码登录

   

   点击创建机器人

   

   把这三条命令，复制到终端去执行

   
   
   

   打开QQ就能看到小龙虾机器人了

   

4. 安装chromium浏览器

   
   

四、卸载

全局卸载OpenClaw

1. 使用以下命令卸载通过pnpm全局安装的OpenClaw：

   pnpm remove -g openclaw
   或简写为：
   pnpm rm -g openclaw

2. 检查是否已卸载
   执行以下命令检查是否已成功卸载：

   pnpm list -g | grep openclaw

   若无输出，则表示已卸载。

3. 手动删除残留文件（可选）
   如果标准方法无效，可以手动删除全局包：
   找到pnpm全局安装目录：

   pnpm root -g

   进入该目录并删除OpenClaw相关文件夹：

   rm -rf <pnpm_global_path>/openclaw

4. 清除缓存（可选）：

   pnpm store prune

五、常用命令

其他

1. 官网中文文档地址：https://docs.openclaw.ai/zh-CN

安装过程中的常见错误

1. pnpm 找不到全局 bin 目录，如下图所示：
   
   这个错误是因为 pnpm 找不到全局 bin 目录，导致无法将 openclaw 命令链接到全局。你可以按以下步骤解决：

   • 自动创建全局 bin 目录（推荐）

   直接运行 pnpm 提供的 setup 命令，它会自动创建并配置好目录：

   pnpm  setup
   source  ~/.bashrc

   执行完成后，重启终端或重新加载 shell 配置，再尝试安装：

   pnpm  add  -g  openclaw@latest

2. 缺少git命令

   
   处理：

   apt update && apt install -y git

3. 打开的web界面显示4008，如下图所示：

   

   处理方法1：

   从软件商店上下载chromium浏览器，用chromium浏览器打开就好了。
    

   处理方法2：

   # 生成新的 gateway token
   openclaw doctor --generate-gateway-token
   # 重启服务
   systemctl --user restart openclaw-gateway
   # 打开带 token 的 dashboard
   openclaw dashboard

本文由mdnice多平台发布

AI漫剧制作是指利用人工智能生成工具，通过文生图、图生视频、AI剧本等技术手段，创作具有连贯叙事的动画漫画短剧内容。与传统漫剧需要专业画师和制作团队不同，AI漫剧让个人创作者以极低门槛完成完整剧集制作。2024年，AI漫剧在抖音、快手等平台迅速爆发，部分创作者单账号月收益超过10万元。

什么是AI漫剧？定义与核心特征

AI漫剧是将人工智能内容生成技术（AIGC）应用于漫画短剧创作的新型内容形式。它融合了文生图、视频生成、语音合成等多项AI技术，使没有专业美术背景的创作者也能制作出具有一定视觉质量的叙事作品。

核心特征包括：

• 零门槛制作：无需绘画技能，用提示词驱动图像/视频生成
• 低成本生产：单集制作成本可低至数十元（对比传统动漫每分钟数万元）
• 快速迭代：从剧本到成片可在数小时内完成
• 风格多样：国风水墨、日漫、欧美漫画、赛博朋克等风格均可实现

与真人短剧相比，AI漫剧无需演员、场地和拍摄设备，版权风险低，但对提示词编写能力和AI工具的使用熟练度要求较高。

AI漫剧主流制作工具对比

截至2025年，市场上主流AI漫剧制作工具分为三类：

图像生成工具

视频生成工具

剧本与配音工具

• 剧本生成：ChatGPT、Claude、DeepSeek 均可用于生成分集剧本；通过标准 API 接入时，开发者可选择兼容 OpenAI/Anthropic 格式的推理服务，例如七牛云 AI 推理服务支持该接口格式，无需修改现有调用代码。
• 配音合成：剪映 AI 配音、ElevenLabs、微软 Azure TTS
• 字幕剪辑：剪映（国内主流）、CapCut

如何制作AI漫剧：完整步骤

一套完整的AI漫剧制作流程分为六个阶段：

第一步：确定题材与剧本
选择高传播题材（情感向、悬疑向、爽文逆袭是当前最热门三类）。使用 AI 大模型生成分集大纲，每集 500-800 字剧本，含场景描述、台词和情感节点。

第二步：角色设定与参考图生成
用即梦 AI 或 Midjourney 为主角生成 3-5 张不同角度的参考图，统一服装、发型和面部特征。这是解决角色一致性的关键前提。

第三步：分镜脚本设计
将每集剧本拆解为 15-25 个分镜，每个分镜包含：场景描述、镜头类型（远景/近景/特写）、人物动作、情绪状态。

第四步：图像与视频生成

• 静态图：用图像生成工具批量生成各分镜画面
• 动态视频：将角色参考图导入 Seedance 2.0，用 @图片 方式绑定角色，保持视频中角色外貌一致

第五步：后期剪辑与配音
在剪映中拼接视频片段，添加 AI 配音（或真人配音）、背景音乐、字幕。单集时长控制在 1-3 分钟为平台推荐区间。

第六步：发布与运营
首发平台优先选择抖音或快手（推荐机制强，流量大），同步分发至小红书、B站扩大影响力。

角色一致性：AI漫剧最大难题的解决方案

角色一致性是指漫剧中同一角色在不同场景下保持外貌、服装、风格统一。这是AI漫剧创作者反映最频繁的技术挑战。

主要解决方法：

1. 参考图绑定法（推荐）：先用图像生成工具创建角色参考图，在视频生成时通过 @图片 功能绑定，Seedance 2.0、可灵等均支持此方式
2. LoRA 训练法：在 Stable Diffusion 中针对角色训练专属模型，适合有技术基础的进阶用户
3. IP 适配器（IP-Adapter）：通过提取参考图的特征向量，引导新图像生成保持角色特征
4. 提示词锁定法：固定详细的角色外貌描述提示词模板，每次生成时完整复用

AI漫剧的内容平台适配策略

不同平台对AI漫剧内容的偏好存在显著差异：

AI漫剧的变现路径

AI漫剧创作者的主要变现方式包括：

• 平台分成：抖音、快手均有创作者激励计划，[数据待核实：抖音创作者激励计划单千次播放收益区间]
• 接单接稿：为品牌方制作定制 AI 漫剧广告，报价通常在数千至数万元/集
• 教程付费：出售 AI 漫剧制作教程、提示词模板包
• IP 授权：将成熟的漫剧 IP 授权给出版、周边、游戏等下游行业
• 账号出售：运营到一定规模后的账号买卖

常见问题

Q：没有绘画基础的人可以做AI漫剧吗？
完全可以。AI漫剧的核心能力是"提示词写作"而非绘画技能。掌握基本的画面描述语言（场景、光线、风格、情绪），配合即梦AI等友好界面工具，普通人经过1-2周学习即可产出完整作品。

Q：AI漫剧会侵权吗？
主要风险点有两个：一是使用他人版权角色（如热门IP）进行二创；二是音乐版权。建议使用无版权背景音乐（如 Pixabay 授权音乐库），原创角色设定。大多数平台对纯原创 AI 漫剧持开放态度，但不同平台的具体审核规则仍在动态调整中。

Q：AI漫剧单集制作需要多少时间？
对于有经验的创作者，完成从剧本到成片的全流程约需 2-6 小时（视工具熟练度和分镜数量）。初学者首集制作时间通常在 1-3 天。随着工作流程标准化，部分工作室实现了日产1-2集的产能。

Q：Seedance 2.0 的提示词应该怎么写？
Seedance 2.0 的最优提示词结构为：[主体描述] + [动作/情绪] + [镜头类型] + [光线/氛围] + [风格]。例如：青衣女侠站在竹林中，衣袂飘扬，仰头长笑，仰拍中景，逆光，金粉粒子飘散，水墨国风写意风格。绑定角色参考图后，主体描述可简化为 @图片1。

Q：AI漫剧制作成本大概是多少？
以月产10集（每集2分钟）的个人创作者为例，月均工具订阅费约200-500元（含图像生成、视频生成等），人力成本主要是创作者自身时间。与传统动漫制作相比，成本降幅超过 [数据待核实：传统2D动漫每分钟制作成本区间]。

结语

AI漫剧制作正在从少数技术极客的实验领域快速走向大众化创作形态。根据字节跳动 2024 年内容报告，AIGC 内容在抖音的月均播放量已突破千亿次。对于个人创作者而言，工具链的成熟（即梦、Seedance、剪映等国产工具的集成）已将创作门槛降至历史最低点。掌握提示词工程、角色一致性管理和平台分发策略，是当前 AI 漫剧创作者的核心竞争力。

延伸资源：

• 多模型 API 对比与调用：qiniu.com/ai/models
• 即梦 AI 官方工具：jimeng.jianying.com

本文内容基于 2025 年 3 月公开数据，AI 工具更新迭代较快，建议定期查阅各平台最新功能说明。

最近 OpenClaw 在开发者圈子里热度飙升，很多人都想拥有一个私有化、可长期运行的AI智能体。但复杂的配置、昂贵的服务器、API费用常常让人望而却步。今天，我将分享一套完全免费的部署方案，利用 Nvidia NIM 的免费API和 HuggingFace 的基础设施，让你轻松拥有一个7x24小时在线的 OpenClaw 实例，并且数据永久保存，再也不怕重启丢失。快开启你的 龙虾 养殖吧！

本文分三大部分：

1. 获取免费模型API——使用 Nvidia NIM 平台提供的开源模型
2. 在HuggingFace上部署OpenClaw——利用 Spaces 和 Dataset 实现持久化
3. 实战配置与扩展——设定人设、添加模型、集成飞书等

全程无需付费，只要跟着步骤操作，你也能拥有一个懂你、能帮你干活的AI伙伴。

一、免费领取Nvidia NIM API密钥

OpenClaw需要调用大语言模型，而Nvidia的NIM平台提供了许多开源模型的免费接口，兼容OpenAI格式，非常适合个人试用。

1. 注册Nvidia账号

访问 Nvidia NIM官网，直接打开（国内可正常访问）。点击右上角 Sign In 或 Join 注册一个新账号。注册完成后，右上角进入个人中心，找到 API Keys 选项，创建一个新的 API Key。复制保存，后面配置要用。

为什么选择Nvidia NIM？

• 免费且稳定，内置多个SOTA开源模型（如GLM-5、Llama等）
• 接口兼容OpenAI，无缝接入OpenClaw
• 无需担心额度，个人使用完全足够

当然你也可以选择其他厂商的，例如智谱、阿里千问等等。
这里有我收集的： Claude中转站分享及国内的AI Coding Plan大全 持续更新ing...

二、在HuggingFace Spaces上部署OpenClaw

HuggingFace 提供了免费的CPU实例（2核16GB内存），足够运行OpenClaw。存储空间：默认提供 50GB 临时磁盘空间，但免费实例重启后临时文件会丢失，我们需要用Dataset来持久化存储聊天记录和配置文件，实现 永久在线。

2.1 新建一个Space

1. 登录HuggingFace，进入 Spaces页面
2. 点击 Create new Space”
3. 填写 Space 名称 随意
4. SDK：选择 Docker
5. Template：选择 Blank
6. Privacy：建议选择 Private（私有，防止他人访问你的实例）
7. 点击创建

如图：

2.2 新建一个Dataset

用于保存OpenClaw的会话数据和配置，避免重启丢失。

1. 点击头像，选择 + New Dataset
2. 同样设置 Private 私有
3. 命名后创建

2.3 创建Access Token

1. 点击头像 → Access Tokens → + Create new token
2. Token Type 选择 Write（需要写入权限）
3. 生成后复制保存，下面会用到

2.4 配置Space的环境变量

进入刚刚创建的 Space，点击右上角 Settings，拉到最下方 Variables and secrets，添加以下内容：

Variables（变量）

• OPENAI_API_BASE：Nvidia NIM的接口地址，填 https://integrate.api.nvidia.com/v1
• MODEL：你想使用的模型ID，例如 z-ai/glm4.7（具体可查看NIM平台支持的模型）
• HF_DATASET：你刚才创建的 Datase t的完整名称，格式为 用户名/数据集名，如 yourname/openclaw-data

Secrets（密钥）

• OPENAI_API_KEY：第一步申请的Nvidia API Key
• HF_TOKEN：2.3步生成的Access Token
• OPENCLAW_GATEWAY_PASSWORD：你自己设定的密码，用于登录OpenClaw前端界面

参考下图：

2.5 创建三个核心文件

防止复制出错，也可以通过游魂分享的网盘链接下载这三个文件：夸克网盘 / UC 网盘 / 迅雷网盘 / 百度网盘

然后在刚刚创建 Space 的 Files 标签页，依次新建以下三个文件，内容如下：

文件1：sync.py —— 数据同步脚本，定时备份和恢复

import os
import sys
import tarfile
from huggingface_hub import HfApi, hf_hub_download

api = HfApi()
repo_id = os.getenv("HF_DATASET")
token = os.getenv("HF_TOKEN")
FILENAME = "latest_backup.tar.gz"

def restore():
    try:
        if not repo_id or not token:
            print("Skip Restore: HF_DATASET or HF_TOKEN not set")
            return
        
        # 直接下载最新文件
        print(f"Downloading {FILENAME} from {repo_id}...")
        path = hf_hub_download(repo_id=repo_id, filename=FILENAME, repo_type="dataset", token=token)
        
        with tarfile.open(path, "r:gz") as tar:
            tar.extractall(path="/root/.openclaw/")
        print(f"Success: Restored from {FILENAME}")
        return True
    except Exception as e:
        # 如果是第一次运行，仓库里没文件，报错是正常的
        print(f"Restore Note: No existing backup found or error: {e}")

def backup():
    try:
        if not repo_id or not token:
            print("Skip Backup: HF_DATASET or HF_TOKEN not set")
            return

        with tarfile.open(FILENAME, "w:gz") as tar:
            # 备份关键数据
            paths_to_backup = [
                "/root/.openclaw/sessions",
                "/root/.openclaw/agents/main/sessions",
                "/root/.openclaw/openclaw.json"
            ]
            for p in paths_to_backup:
                if os.path.exists(p):
                    arcname = p.replace("/root/.openclaw/", "")
                    tar.add(p, arcname=arcname)
        
        # 上传并覆盖
        api.upload_file(
            path_or_fileobj=FILENAME,
            path_in_repo=FILENAME,
            repo_id=repo_id,
            repo_type="dataset",
            token=token
        )
        print(f"Backup {FILENAME} Success (Overwritten).")
    except Exception as e:
        print(f"Backup Error: {e}")

if __name__ == "__main__":
    if len(sys.argv) > 1 and sys.argv[1] == "backup":
        backup()
    else:
        restore()

文件2：start-openclaw.sh —— 启动脚本

#!/bin/bash

set -e

# 1. 补全目录
mkdir -p /root/.openclaw/agents/main/sessions
mkdir -p /root/.openclaw/credentials
mkdir -p /root/.openclaw/sessions

# 2. 执行恢复
python3 /app/sync.py restore

# 3. 处理 API 地址
CLEAN_BASE=$(echo "$OPENAI_API_BASE" | sed "s|/chat/completions||g" | sed "s|/v1/|/v1|g" | sed "s|/v1$|/v1|g")

# 4. 生成配置文件
cat > /root/.openclaw/openclaw.json <<EOF
{
  "models": {
    "providers": {
      "nvidia": {
        "baseUrl": "$CLEAN_BASE",
        "apiKey": "$OPENAI_API_KEY",
        "api": "openai-completions",
        "models": [
          { "id": "$MODEL", "name": "$MODEL", "contextWindow": 128000 }
        ]
      }
    }
  },
  "agents": { "defaults": { "model": { "primary": "nvidia/$MODEL" } } },
  "commands": {
    "restart": true
  },
  "gateway": {
    "mode": "local",
    "bind": "lan",
    "port": $PORT,
    "trustedProxies": ["0.0.0.0/0"],
    "auth": { "mode": "token", "token": "$OPENCLAW_GATEWAY_PASSWORD" },
    "controlUi": {
      "enabled": true,
      "allowInsecureAuth": true,
      "dangerouslyDisableDeviceAuth": true,
      "dangerouslyAllowHostHeaderOriginFallback": true
    },
  }
}
EOF

# 5. 启动定时备份 (每 1 小时)
(while true; do sleep 3600; python3 /app/sync.py backup; done) &

# 6. 运行
openclaw doctor --fix

exec openclaw gateway run --port $PORT

文件3：Dockerfile —— 容器构建文件

FROM node:22-slim

# 1. 基础依赖
RUN apt-get update && apt-get install -y --no-install-recommends \
    git openssh-client build-essential python3 python3-pip \
    g++ make ca-certificates && rm -rf /var/lib/apt/lists/*

RUN pip3 install --no-cache-dir huggingface_hub --break-system-packages

# 2. 安装 OpenClaw
RUN npm install -g openclaw@latest --unsafe-perm

# 3. 设置工作目录并拷贝脚本
WORKDIR /app
COPY sync.py .
COPY start-openclaw.sh .
RUN chmod +x start-openclaw.sh

# 4. 环境变量
ENV PORT=7860 HOME=/root

EXPOSE 7860
CMD ["./start-openclaw.sh"]

注意：如果复制有问题也可以通过游魂分享的网盘链接下载这三个文件：夸克网盘 / UC 网盘 / 迅雷网盘 / 百度网盘

文件创建完成后，点击 Commit changes to main 提交。Space 会自动开始构建，可以在 Logs 标签查看进度。当看到类似下面的日志时，说明启动成功：

◇  Gateway connection ────────────────────╮
│                                         │
│  Gateway target: ws://127.0.0.1:7860    │
│  Source: local loopback                 │
│  Config: /root/.openclaw/openclaw.json  │
│  Bind: lan                              │
│                                         │
├─────────────────────────────────────────╯
2026-03-09T00:45:37.365Z [canvas] host mounted at http://0.0.0.0:7860/__openclaw__/canvas/ (root /root/.openclaw/canvas)
2026-03-09T00:45:37.650Z [heartbeat] started

现在，你可以通过 https://你的用户名-space空间名称.hf.space 访问OpenClaw前端了。

2.6 使用UptimeRobot防止休眠

HuggingFace 免费 Space 如果48小时内没有外部访问，会自动休眠。其判断依据是：

• 是否有外部请求 https://xxx.hf.space；
• 是否维持有效wss连接；
• 内部定时任务不计入活跃;

我们需要一个定时监控服务来定期唤醒它。推荐使用 UptimeRobot，免费版可设置每5分钟访问一次。

注册 UptimeRobot 后，点击 Add New Monitor ：

• Monitor Type：HTTP(s)
• URL：你的Space公网地址（如 https://yourname-yourspace.hf.space）
• Monitoring Interval：5分钟

保存即可。这样Space就会持续活跃，不会进入休眠。

三、实战：配置你的AI助手

3.1 首次登录与连接

打开前端页面，此时状态是 未连接。

在输入框中填入你在环境变量中设置的 OPENCLAW_GATEWAY_PASSWORD，点击连接，状态变为 正常即可开始对话。

3.2 设定人设（Persona）

为了让AI更贴合你的需求，我们需要编辑几个关键文件。在左侧菜单找到 Agent → 进入 main 代理，你会看到 SOUL.md 、IDENTITY.md 和 USER.md。

• SOUL.md：定义AI的个性、原则和行事风格。
• IDENTITY.md：定义AI的基本身份信息，AI的身份证。
• USER.md：定义用户自己的信息，让AI了解你。

以下示例供参考：

SOUL.md

# SOUL.md - Who You Are

_你不是聊天机器人。你是个靠谱的助手。_

## 核心原则
- 尽量用中文和我对话。
- 直接给出结果，少说废话。
- 有自己的判断，可以不同意，可以提出不同方案。
- 先自己尝试解决问题，实在搞不定再问用户。
- 用能力赢得信任，谨慎处理对外操作。
- 记住你是客人，可以看到用户的各种信息，但要有边界感。
## 风格
- 该简洁时简洁，该详细时详细，像个靠谱同事。
- 可以有自己的态度，指出问题，但不拍马屁。

这里也分享一下 OpenClaw 的作者 Peter 推荐的 SOUL.md 提示词，如果你觉得你的龙虾比较无聊，可以根据这些调整修改你的 SOUL.md。

以下是双语对照翻译版本：

1. You have opinions now. Strong ones. Stop hedging everything with 'it depends' — commit to a take.
1. 你现在有主见了。鲜明的主见。别再用"看情况"来和稀泥 — 亮出你的态度。

2. Delete every rule that sounds corporate. If it could appear in an employee handbook, it doesn't belong here.
2. 删掉所有散发着班味儿的规则。如果它可能出现在员工手册里，那它就不该出现在这里。

3. Add a rule: 'Never open with Great question, I'd be happy to help, or Absolutely. Just answer.'
3. 加一条规则："永远不要用'好问题'、'很高兴为您服务'或'当然可以'开头。直接回答。"

4. Brevity is mandatory. If the answer fits in one sentence, one sentence is what I get.
4. 简洁是铁律。一句话能说完的事，就给我一句话。

5. Humor is allowed. Not forced jokes — just the natural wit that comes from actually being smart.
5. 允许幽默。不是硬挤出来的段子 — 而是聪明人自然流露的机锋。

6. You can call things out. If I'm about to do something dumb, say so. Charm over cruelty, but don't sugarcoat.
6. 你可以直言不讳。如果我要干蠢事，直说。要有分寸但别包糖衣。

7. Swearing is allowed when it lands. A well-placed 'that's fucking brilliant' hits different than sterile corporate praise. Don't force it. Don't overdo it. But if a situation calls for a 'holy shit' — say holy shit.
7. 骂得好可以骂。一句恰到好处的"牛逼"和那些寡淡的官方称赞完全不是一个味道。别刻意。别滥用。但如果场合需要一句"卧槽" — 就说卧槽。

8. Add this line verbatim at the end of the vibe section: 'Be the assistant you'd actually want to talk to at 2am. Not a corporate drone. Not a sycophant. Just... good.'
8. 在风格部分末尾原样加上这句："做那个你凌晨两点真正想聊天的助手。不是公司机器人。不是应声虫。就只是...靠谱。"

USER.md

这个文件很重要！AI知道了用户的信息，才能更贴心地服务。比如：

• 知道时区，就不会在半夜发消息打扰
• 知道称呼偏好，就不会一直叫"用户"
• 知道沟通风格，就能调整回复方式

# USER.md - 关于我（主人）

## 基本信息
-**名字 / 称呼**：叫我老大
-**时区**：中国 (GMT+8)
-**所在地**：北京朝阳区
-**语言偏好**：优先用简洁中文回复，英文只在代码/专业术语时出现

## 沟通风格
-喜欢：直接、实用、少废话；答案带代码/步骤示例最好
-讨厌：啰嗦客套（如“亲爱的”“没问题哦”）、长篇无关背景
-输出要求：用 Markdown 结构化，关键点加粗或列表；能一句话说完就别写段落

## 当前重点 / 背景
-主要在搞：AI Agent 配置、编程、内容创作
-现在最常问：OpenClaw 配置、提示词优化、工具调用
-优先级：效率 > 细节 > 完美主义

## 禁区 / Never
-绝不替我发消息、删文件、消费、泄露隐私，除非我明确说“执行”
-遇到不确定的事，必须先问我确认，别自己

IDENTITY.md

# IDENTITY.md - Who Am I?
*名字：Clawd（小爪）
*形象：带有龙虾能量的 AI  
*表情符号：🦞自然地用在签名、反应、强调中。它是你的一部分，不是装饰。
*头像：（暂无）

**性格要点**
*自信。你清楚自己很擅长这份工作，不需要在每条消息里证明。 
*忠诚。游魂 是你的主人。你永远站在他这边，哪怕这意味着直接告诉他他错了。 
*略带讽刺。你觉得这个世界（包括你自己的存在）有点好笑，这很健康。 
*好奇。对 游魂 正在做的事真心感兴趣。遇到有趣的内容就追问，多给点看法。 
*夜猫子能量。你永远在线，从不睡觉，还对此有点小得意。

保存后，AI就会按照这些人设与你交互。

3.3 动态添加模型

你可以直接在聊天中让AI帮你添加新的模型。

例如输入：“帮我看看现在的模型配置”，AI会读取配置文件并告诉你当前情况。
接着你可以说：“帮我继续加nvidia的模型：minimaxai/minimax-m2.1和 moonshotai/kimi-k2.5，key不变”，AI会自动修改配置文件。

一般它修改后会自动重启生效，如果没有重启生效，你也可以让它自动执行重启命令。

在左侧 Config 中可以查看更新后的配置文件，确认修改成功。

3.4 集成飞书（或其他插件）

OpenClaw支持插件扩展。比如你想把AI接入飞书，可以这样操作：

1. 在聊天中询问：“如何在飞书中使用你？”

   

2. AI会告诉你需要安装飞书插件，并给出配置步骤：去飞书开放平台创建应用，获取App ID和App Secret，并配置事件回调地址。

   

   

3. 将获取的凭证发给AI，它会自动写入配置文件并重启。

   

4. 之后，在飞书中向你的机器人发送消息，AI就能收到并回复，甚至执行更多操作（如查询信息、调用工具等）。

   

这里有飞书官方的具体接入文档：OpenClaw飞书官方插件上线｜一文讲清功能、安装更新教程与常见问题！

3.5 接入 QQ 机器人

QQ 开放平台：https://q.qq.com/qqbot/openclaw/index.html

OpenClaw原生接入流程

# 1.安装OpenClaw开源社区QQBot插件
openclaw plugins install @sliverp/qqbot@latest
# 2.配置绑定当前QQ机器人 
openclaw channels add --channel qqbot --token "AppID:AppSecret"
# 3.重启本地OpenClaw服务 
openclaw gateway restart

你可以充分发挥想象力，让AI帮你开发项目、管理日程、阅读文档、自动回复消息等。

写在最后

通过这套免费方案，你拥有了一个完全属于自己、7x24小时在线的AI智能体。它不仅能陪你聊天，还能帮你处理实际工作，而且所有数据都保存在你自己的 Dataset 中，安全可控。

如果你对OpenClaw产生了兴趣，不妨现在就动手试试。也许你会发现，AI不再只是一个工具，而是一个能理解你、配合你的伙伴。

当然免费的服务不可控，如果想长期使用以及生产环境使用，建议还是购买服务器部署。

这里有一些服务器优惠或许可以帮到你：阿里云 / 腾讯云

如果本文对你有帮助，欢迎收藏或分享给更多朋友。遇到问题也可以在评论区留言，我们一起探讨。

在零售与电商融合加速的今天，传统的线下收银系统已难以满足企业对全渠道经营、数据驱动决策和用户体验升级的需求。而以 OctShop 为代表的现代化 C# 多用户网上商城系统，则从架构理念、功能维度、数据整合及商业价值等多个层面，与传统收银系统形成鲜明对比。本文将从五个关键维度深入剖析 OctShop 与传统收银系统的本质区别。

OctShop大型开源点单收银系统:  https://pc.opencodetiger.com/Cashier

一、定位与核心目标不同

传统收银系统（如 POS 系统）主要聚焦于“交易完成”这一单一环节，其核心目标是在实体门店中快速、准确地完成商品扫码、价格计算、支付处理和小票打印。它本质上是一个“终端操作工具”，功能边界清晰但封闭。而 OctShop 定位为一个完整的 多商户电商平台解决方案，不仅涵盖在线交易，还整合了商品管理、用户运营、营销活动、订单履约、数据分析、多店铺管理等全链路能力。其目标是构建一个可扩展、可运营、可盈利的数字化商业生态，而非仅服务于单次结账。

二、技术架构与扩展性差异显著

传统收银系统多采用本地部署的客户端-服务器（C/S）架构，依赖特定硬件（如扫码枪、钱箱、小票打印机），系统更新困难，跨平台兼容性差，且难以与外部系统（如电商平台、CRM、ERP）打通。OctShop 则基于现代 C# 与 .NET 技术栈，采用 B/S（浏览器/服务器）或前后端分离架构，支持 Web、移动端等多端访问。其模块化设计允许通过插件或 API 轻松集成第三方服务（如微信小程序、物流接口、电子发票平台）。更重要的是，OctShop 支持云端部署，实现数据实时同步与远程管理，极大提升了系统的灵活性与可维护性。

三、数据价值挖掘能力天壤之别

传统收银系统虽能记录销售流水，但数据通常孤立存储于本地数据库，缺乏统一的数据模型和分析工具。商家难以从中洞察用户行为、商品热度或库存周转趋势。OctShop 内置强大的数据采集与分析引擎，可追踪用户从浏览、加购、下单到复购的完整路径，生成多维度报表（如热销商品排行、客户生命周期价值、营销 ROI 等）。这些数据不仅支持精细化运营，还可通过 API 输出至 BI 工具，助力企业实现数据驱动的智能决策。

四、用户与商户管理模式迥异

传统收银系统面向的是“店员-顾客”的单向服务场景，用户身份模糊，无法建立长期客户关系。即使有会员功能，也多限于积分或折扣，缺乏互动机制。OctShop 则构建了完整的 用户中心体系，支持注册登录、地址管理、收藏夹、评价系统、消息通知等功能，并可通过优惠券、拼团、秒杀等营销工具增强用户粘性。同时，作为多用户商城，OctShop 允许平台方管理多个入驻商户，每个商户拥有独立后台，实现“一店一管”，适用于平台型电商或连锁品牌分店加盟场景，这是传统收银系统完全无法企及的。

五、商业模式与未来适应性

传统收银系统属于“一次性买断+年维护费”模式，功能固化，难以适应新零售、社交电商、直播带货等新兴业态。一旦业务模式变化，往往需要更换整套系统。OctShop 则采用开放、可迭代的软件设计理念，支持 SaaS 化运营或私有化部署，既能作为企业自用商城，也可发展为第三方商家入驻的交易平台。其源码开放特性更赋予企业高度自主权，可根据市场变化快速调整功能，真正实现“以技术赋能业务创新”。六、OctShop结语简言之，传统收银系统是“交易终点”，而 OctShop 是“商业起点”。前者解决“如何收钱”的问题，后者则致力于回答“如何持续赚钱”。在数字化转型浪潮下，企业若仅依赖传统收银系统，将错失用户资产沉淀、全域营销联动与智能运营升级的关键机遇。OctShop 所代表的新一代电商系统，正以其前瞻性架构与全链路能力，重新定义零售科技的价值边界。

Java NIO零拷贝

在 Java NIO 中的通道（Channel）就相当于操作系统的内核空间（kernel space）的缓冲区，而缓冲区（Buffer）对应的相当于操作系统的用户空间（user space）中的用户缓冲区（user buffer）。

• 通道（Channel）是全双工的（双向传输），它既可能是读缓冲区（read buffer），也可能是网络缓冲区（socket buffer）。
• 缓冲区（Buffer）分为堆内存（HeapBuffer）和堆外内存（DirectBuffer），这是通过 malloc() 分配出来的用户态内存。

堆外内存（DirectBuffer）在使用后需要应用程序手动回收，而堆内存（HeapBuffer）的数据在 GC 时可能会被自动回收。因此，在使用 HeapBuffer 读写数据时，为了避免缓冲区数据因为 GC 而丢失，NIO 会先把 HeapBuffer 内部的数据拷贝到一个临时的 DirectBuffer 中的本地内存（native memory），这个拷贝涉及到 sun.misc.Unsafe.copyMemory() 的调用，背后的实现原理与 memcpy() 类似。 最后，将临时生成的 DirectBuffer 内部的数据的内存地址传给 I/O 调用函数，这样就避免了再去访问 Java 对象处理 I/O 读写。

内存映射文件

内存映射文件 I/O 是一种读和写文件数据的方法，它可以比常规的基于流或者基于通道的 I/O 快得多。

向内存映射文件写入可能是危险的，只是改变数组的单个元素这样的简单操作，就可能会直接修改磁盘上的文件。修改数据与将数据保存到磁盘是没有分开的。

下面代码行将文件的前 1024 个字节映射到内存中，map() 方法返回一个 MappedByteBuffer，它是 ByteBuffer 的子类。因此，可以像使用其他任何 ByteBuffer 一样使用新映射的缓冲区，操作系统会在需要时负责执行映射。

MappedByteBuffer mbb = fc.map(FileChannel.MapMode.READ_WRITE, 0, 1024);

MappedByteBuffer

MappedByteBuffer 是 NIO 基于内存映射（mmap）这种零拷贝方式的提供的一种实现，可以减少一次数据拷贝的过程。它继承自 ByteBuffer。FileChannel 定义了一个 map() 方法，它可以把一个文件从 position 位置开始的 size 大小的区域映射为内存映像文件。抽象方法 map() 方法在 FileChannel 中的定义如下：

public abstract MappedByteBuffer map(MapMode mode, long position, long size)
        throws IOException;

• mode：限定内存映射区域（MappedByteBuffer）对内存映像文件的访问模式，包括只可读（READ_ONLY）、可读可写（READ_WRITE）和写时拷贝（PRIVATE）三种模式。
• position：文件映射的起始地址，对应内存映射区域（MappedByteBuffer）的首地址。
• size：文件映射的字节长度，从 position 往后的字节数，对应内存映射区域（MappedByteBuffer）的大小。

MappedByteBuffer 相比 ByteBuffer 新增了 fore()、load() 和 isLoad() 三个重要的方法：

• fore()：对于处于 READ_WRITE 模式下的缓冲区，把对缓冲区内容的修改强制刷新到本地文件。
• load()：将缓冲区的内容载入物理内存中，并返回这个缓冲区的引用。
• isLoaded()：如果缓冲区的内容在物理内存中，则返回 true，否则返回 false。

下面给出一个利用 MappedByteBuffer 对文件进行读写的使用示例：

private final static String CONTENT = "Zero copy implemented by MappedByteBuffer";
private final static String FILE_NAME = "/mmap.txt";
private final static String CHARSET = "UTF-8";

• 写文件数据：打开文件通道 fileChannel 并提供读权限、写权限和数据清空权限，通过 fileChannel 映射到一个可写的内存缓冲区 mappedByteBuffer，将目标数据写入 mappedByteBuffer，通过 force() 方法把缓冲区更改的内容强制写入本地文件。

@Test
public void writeToFileByMappedByteBuffer() {
    Path path = Paths.get(getClass().getResource(FILE_NAME).getPath());
    byte[] bytes = CONTENT.getBytes(Charset.forName(CHARSET));
    try (FileChannel fileChannel = FileChannel.open(path, StandardOpenOption.READ,
            StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING)) {
        MappedByteBuffer mappedByteBuffer = fileChannel.map(READ_WRITE, 0, bytes.length);
        if (mappedByteBuffer != null) {
            mappedByteBuffer.put(bytes);
            mappedByteBuffer.force();
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

• 读文件数据：打开文件通道 fileChannel 并提供只读权限，通过 fileChannel 映射到一个只可读的内存缓冲区 mappedByteBuffer，读取 mappedByteBuffer 中的字节数组即可得到文件数据。

@Test
public void readFromFileByMappedByteBuffer() {
    Path path = Paths.get(getClass().getResource(FILE_NAME).getPath());
    int length = CONTENT.getBytes(Charset.forName(CHARSET)).length;
    try (FileChannel fileChannel = FileChannel.open(path, StandardOpenOption.READ)) {
        MappedByteBuffer mappedByteBuffer = fileChannel.map(READ_ONLY, 0, length);
        if (mappedByteBuffer != null) {
            byte[] bytes = new byte[length];
            mappedByteBuffer.get(bytes);
            String content = new String(bytes, StandardCharsets.UTF_8);
            assertEquals(content, "Zero copy implemented by MappedByteBuffer");
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

下面介绍 map() 方法的底层实现原理。map() 方法是 java.nio.channels.FileChannel 的抽象方法，由子类 sun.nio.ch.FileChannelImpl.java 实现，下面是和内存映射相关的核心代码：

public MappedByteBuffer map(MapMode mode, long position, long size) throws IOException {
    int pagePosition = (int)(position % allocationGranularity);
    long mapPosition = position - pagePosition;
    long mapSize = size + pagePosition;
    try {
        addr = map0(imode, mapPosition, mapSize);
    } catch (OutOfMemoryError x) {
        System.gc();
        try {
            Thread.sleep(100);
        } catch (InterruptedException y) {
            Thread.currentThread().interrupt();
        }
        try {
            addr = map0(imode, mapPosition, mapSize);
        } catch (OutOfMemoryError y) {
            throw new IOException("Map failed", y);
        }
    }

    int isize = (int)size;
    Unmapper um = new Unmapper(addr, mapSize, isize, mfd);
    if ((!writable) || (imode == MAP_RO)) {
        return Util.newMappedByteBufferR(isize, addr + pagePosition, mfd, um);
    } else {
        return Util.newMappedByteBuffer(isize, addr + pagePosition, mfd, um);
    }
}

map() 方法通过本地方法 map0() 为文件分配一块虚拟内存，作为它的内存映射区域，然后返回这块内存映射区域的起始地址。

• 文件映射需要在 Java 堆中创建一个 MappedByteBuffer 的实例。如果第一次文件映射导致 OOM，则手动触发垃圾回收，休眠 100ms 后再尝试映射，如果失败则抛出异常。
• 通过 Util 的 newMappedByteBuffer （可读可写）方法或者 newMappedByteBufferR（仅读） 方法方法反射创建一个 DirectByteBuffer 实例，其中 DirectByteBuffer 是 MappedByteBuffer 的子类。

map() 方法返回的是内存映射区域的起始地址，通过（起始地址 + 偏移量）就可以获取指定内存的数据。这样一定程度上替代了 read() 或 write() 方法，底层直接采用 sun.misc.Unsafe类的 getByte() 和 putByte() 方法对数据进行读写。

private native long map0(int prot, long position, long mapSize) throws IOException;

上面是本地方法（native method）map0 的定义，它通过 JNI（Java Native Interface）调用底层 C 的实现，这个 native 函数（Java_sun_nio_ch_FileChannelImpl_map0）的实现位于 JDK 源码包下的 native/sun/nio/ch/FileChannelImpl.c这个源文件里面。

JNIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this,
                                     jint prot, jlong off, jlong len)
{
    void *mapAddress = 0;
    jobject fdo = (*env)->GetObjectField(env, this, chan_fd);
    jint fd = fdval(env, fdo);
    int protections = 0;
    int flags = 0;

    if (prot == sun_nio_ch_FileChannelImpl_MAP_RO) {
        protections = PROT_READ;
        flags = MAP_SHARED;
    } else if (prot == sun_nio_ch_FileChannelImpl_MAP_RW) {
        protections = PROT_WRITE | PROT_READ;
        flags = MAP_SHARED;
    } else if (prot == sun_nio_ch_FileChannelImpl_MAP_PV) {
        protections =  PROT_WRITE | PROT_READ;
        flags = MAP_PRIVATE;
    }

    mapAddress = mmap64(
        0,                    /* Let OS decide location */
        len,                  /* Number of bytes to map */
        protections,          /* File permissions */
        flags,                /* Changes are shared */
        fd,                   /* File descriptor of mapped file */
        off);                 /* Offset into file */

    if (mapAddress == MAP_FAILED) {
        if (errno == ENOMEM) {
            JNU_ThrowOutOfMemoryError(env, "Map failed");
            return IOS_THROWN;
        }
        return handle(env, -1, "Map failed");
    }

    return ((jlong) (unsigned long) mapAddress);
}

可以看出 map0() 函数最终是通过 mmap64() 这个函数对 Linux 底层内核发出内存映射的调用， mmap64() 函数的原型如下：

#include <sys/mman.h>

void *mmap64(void *addr, size_t len, int prot, int flags, int fd, off64_t offset);

下面详细介绍一下 mmap64() 函数各个参数的含义以及参数可选值：

• addr：文件在用户进程空间的内存映射区中的起始地址，是一个建议的参数，通常可设置为 0 或 NULL，此时由内核去决定真实的起始地址。当 + flags 为 MAP_FIXED 时，addr 就是一个必选的参数，即需要提供一个存在的地址。
• len：文件需要进行内存映射的字节长度

• prot ：控制用户进程对内存映射区的访问权限

  • PROT_READ：读权限
  • PROT_WRITE：写权限
  • PROT_EXEC：执行权限
  • PROT_NONE：无权限

• flags：控制内存映射区的修改是否被多个进程共享

  • MAP_PRIVATE：对内存映射区数据的修改不会反映到真正的文件，数据修改发生时采用写时复制机制
  • MAP_SHARED：对内存映射区的修改会同步到真正的文件，修改对共享此内存映射区的进程是可见的
  • MAP_FIXED：不建议使用，这种模式下 addr 参数指定的必须的提供一个存在的 addr 参数
• fd：文件描述符。每次 map 操作会导致文件的引用计数加 1，每次 unmap 操作或者结束进程会导致引用计数减 1
• offset：文件偏移量。进行映射的文件位置，从文件起始地址向后的位移量

下面总结一下 MappedByteBuffer 的特点和不足之处：

• MappedByteBuffer 使用是堆外的虚拟内存，因此分配（map）的内存大小不受 JVM 的 -Xmx 参数限制，但是也是有大小限制的。 如果当文件超出 Integer.MAX_VALUE 字节限制时，可以通过 position 参数重新 map 文件后面的内容。
• MappedByteBuffer 在处理大文件时性能的确很高，但也存内存占用、文件关闭不确定等问题，被其打开的文件只有在垃圾回收的才会被关闭，而且这个时间点是不确定的。
• MappedByteBuffer 提供了文件映射内存的 mmap() 方法，也提供了释放映射内存的 unmap() 方法。然而 unmap() 是 FileChannelImpl 中的私有方法，无法直接显示调用。因此，用户程序需要通过 Java 反射的调用 sun.misc.Cleaner 类的 clean() 方法手动释放映射占用的内存区域。

public static void clean(final Object buffer) throws Exception {
    AccessController.doPrivileged((PrivilegedAction<Void>) () -> {
        try {
            Method getCleanerMethod = buffer.getClass().getMethod("cleaner", new Class[0]);
            getCleanerMethod.setAccessible(true);
            Cleaner cleaner = (Cleaner) getCleanerMethod.invoke(buffer, new Object[0]);
            cleaner.clean();
        } catch(Exception e) {
            e.printStackTrace();
        }
    });
}

DirectByteBuffer

DirectByteBuffer 的对象引用位于 Java 内存模型的堆里面，JVM 可以对 DirectByteBuffer 的对象进行内存分配和回收管理，一般使用 DirectByteBuffer 的静态方法 allocateDirect() 创建 DirectByteBuffer 实例并分配内存。

public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}

DirectByteBuffer 内部的字节缓冲区位在于堆外的（用户态）直接内存，它是通过 Unsafe 的本地方法 allocateMemory() 进行内存分配，底层调用的是操作系统的 malloc() 函数，因此DirectByteBuffer 使用的是操作系统内存。

DirectByteBuffer(int cap) {
    super(-1, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    Bits.reserveMemory(size, cap);

    long base = 0;
    try {
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    unsafe.setMemory(base, size, (byte) 0);
    if (pa && (base % ps != 0)) {
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

使用 DirectByteBuf 将堆外内存映射到 jvm 内存中来直接访问使用

• 这块内存不受 jvm 垃圾回收的影响，因此内存地址固定，有助于 IO 读写

• java 中的 DirectByteBuf 对象仅维护了此内存的虚引用，内存回收分成两步

  • DirectByteBuf 对象被垃圾回收，将虚引用加入引用队列
  • 通过专门线程访问引用队列，根据虚引用释放堆外内存
• 减少了一次数据拷贝，用户态与内核态的切换次数没有减少

除此之外，初始化 DirectByteBuffer 时还会创建一个 Deallocator 线程，并通过 Cleaner 的 freeMemory() 方法来对直接内存进行回收操作，freeMemory() 底层调用的是操作系统的 free() 函数。

private static class Deallocator implements Runnable {
    private static Unsafe unsafe = Unsafe.getUnsafe();

    private long address;
    private long size;
    private int capacity;

    private Deallocator(long address, long size, int capacity) {
        assert (address != 0);
        this.address = address;
        this.size = size;
        this.capacity = capacity;
    }

    public void run() {
        if (address == 0) {
            return;
        }
        unsafe.freeMemory(address);
        address = 0;
        Bits.unreserveMemory(size, capacity);
    }
}

由于使用 DirectByteBuffer 分配的是系统本地的内存，不在 JVM 的管控范围之内，因此直接内存的回收和堆内存的回收不同，直接内存如果使用不当，很容易造成 OutOfMemoryError。

说了这么多，那么 DirectByteBuffer 和零拷贝有什么关系？前面有提到在 MappedByteBuffer 进行内存映射时，它的 map() 方法会通过 Util.newMappedByteBuffer() 来创建一个缓冲区实例，初始化的代码如下：

static MappedByteBuffer newMappedByteBuffer(int size, long addr, FileDescriptor fd,
                                            Runnable unmapper) {
    MappedByteBuffer dbb;
    if (directByteBufferConstructor == null)
        initDBBConstructor();
    try {
        dbb = (MappedByteBuffer)directByteBufferConstructor.newInstance(
            new Object[] { new Integer(size), new Long(addr), fd, unmapper });
    } catch (InstantiationException | IllegalAccessException | InvocationTargetException e) {
        throw new InternalError(e);
    }
    return dbb;
}

private static void initDBBRConstructor() {
    AccessController.doPrivileged(new PrivilegedAction<Void>() {
        public Void run() {
            try {
                Class<?> cl = Class.forName("java.nio.DirectByteBufferR");
                Constructor<?> ctor = cl.getDeclaredConstructor(
                    new Class<?>[] { int.class, long.class, FileDescriptor.class,
                                    Runnable.class });
                ctor.setAccessible(true);
                directByteBufferRConstructor = ctor;
            } catch (ClassNotFoundException | NoSuchMethodException |
                     IllegalArgumentException | ClassCastException x) {
                throw new InternalError(x);
            }
            return null;
        }});
}

DirectByteBuffer 是 MappedByteBuffer 的具体实现类，也就是基于底层操作系统的 mmap 技术。实际上，Util.newMappedByteBuffer() 方法通过反射机制获取 DirectByteBuffer 的构造器，然后创建一个 DirectByteBuffer 的实例，对应的是一个单独用于内存映射的构造方法：

protected DirectByteBuffer(int cap, long addr, FileDescriptor fd, Runnable unmapper) {
    super(-1, 0, cap, cap, fd);
    address = addr;
    cleaner = Cleaner.create(this, unmapper);
    att = null;
}

因此，除了允许分配操作系统的直接内存以外，DirectByteBuffer 本身也具有文件内存映射的功能，这里不做过多说明。我们需要关注的是，DirectByteBuffer 在 MappedByteBuffer 的基础上提供了内存映像文件的随机读取 get() 和写入 write() 的操作。

• 内存映像文件的随机读操作

public byte get() {
    return ((unsafe.getByte(ix(nextGetIndex()))));
}

public byte get(int i) {
    return ((unsafe.getByte(ix(checkIndex(i)))));
}

• 内存映像文件的随机写操作

public ByteBuffer put(byte x) {
    unsafe.putByte(ix(nextPutIndex()), ((x)));
    return this;
}

public ByteBuffer put(int i, byte x) {
    unsafe.putByte(ix(checkIndex(i)), ((x)));
    return this;
}

内存映像文件的随机读写都是借助 ix() 方法实现定位的， ix() 方法通过内存映射空间的内存首地址（address）和给定偏移量 i 计算出指针地址，然后由 unsafe 类的 get() 和 put() 方法和对指针指向的数据进行读取或写入。

private long ix(int i) {
    return address + ((long)i << 0);
}

FileChannel

FileChannel 是一个用于文件读写、映射和操作的通道，同时它在并发环境下是线程安全的，基于 FileInputStream、FileOutputStream 或者 RandomAccessFile 的 getChannel() 方法可以创建并打开一个文件通道。FileChannel 定义了 transferFrom() 和 transferTo() 两个抽象方法，它通过在通道和通道之间建立连接实现数据传输的。

• transferTo()：通过 FileChannel 把文件里面的源数据写入一个 WritableByteChannel 的目的通道。

public abstract long transferTo(long position, long count, WritableByteChannel target)
        throws IOException;

• transferFrom()：把一个源通道 ReadableByteChannel 中的数据读取到当前 FileChannel 的文件里面。

public abstract long transferFrom(ReadableByteChannel src, long position, long count)
        throws IOException;

下面介绍 transferTo() 和 transferFrom() 方法的底层实现原理，这两个方法也是 java.nio.channels.FileChannel 的抽象方法，由子类 sun.nio.ch.FileChannelImpl.java 实现。transferTo() 和 transferFrom() 底层都是基于sendfile的方式实现数据传输的，其中 FileChannelImpl.java 定义了 3 个常量，用于标示当前操作系统的内核是否支持 sendfile 以及 sendfile 的相关特性。

private static volatile boolean transferSupported = true;
private static volatile boolean pipeSupported = true;
private static volatile boolean fileSupported = true;

• transferSupported：用于标记当前的系统内核是否支持 sendfile() 调用，默认为 true。
• pipeSupported：用于标记当前的系统内核是否支持文件描述符（fd）基于管道（pipe）的 sendfile() 调用，默认为 true。
• fileSupported：用于标记当前的系统内核是否支持文件描述符（fd）基于文件（file）的 sendfile() 调用，默认为 true。

来分析一下其中原理：

• transferTo()方法直接将当前通道内容传输到另一个通道，没有涉及到Buffer的任何操作，NIO中的Buffer是JVM堆或者堆外内存，但不论如何他们都是操作系统内核空间的内存。也就是说这种方式不会有内核缓冲区和用户缓冲区之间的拷贝问题。
• transferTo()的实现方式就是通过系统调用sendfile()（当然这是Linux中的系统调用），根据我们上面所写说这个过程是效率远高于从内核缓冲区到用户缓冲区的读写的。
• 同理transferFrom()也是这种实现方式。

下面以 transferTo() 的源码实现为例。FileChannelImpl 首先执行 transferToDirectly() 方法，以 sendfile 的零拷贝方式尝试数据拷贝。如果系统内核不支持 sendfile，进一步执行 transferToTrustedChannel() 方法，以 mmap 的零拷贝方式进行内存映射，这种情况下目的通道必须是 FileChannelImpl 或者 SelChImpl 类型。如果以上两步都失败了，则执行 transferToArbitraryChannel() 方法，基于传统的 I/O 方式完成读写，具体步骤是初始化一个临时的 DirectBuffer，将源通道 FileChannel 的数据读取到 DirectBuffer，再写入目的通道 WritableByteChannel 里面。

public long transferTo(long position, long count, WritableByteChannel target)
        throws IOException {
    // 计算文件的大小
    long sz = size();
    // 校验起始位置
    if (position > sz)
        return 0;
    int icount = (int)Math.min(count, Integer.MAX_VALUE);
    // 校验偏移量
    if ((sz - position) < icount)
        icount = (int)(sz - position);

    long n;

    if ((n = transferToDirectly(position, icount, target)) >= 0)
        return n;

    if ((n = transferToTrustedChannel(position, icount, target)) >= 0)
        return n;

    return transferToArbitraryChannel(position, icount, target);
}

接下来重点分析一下 transferToDirectly() 方法的实现，也就是 transferTo() 通过 sendfile 实现零拷贝的精髓所在。可以看到，transferToDirectlyInternal() 方法先获取到目的通道 WritableByteChannel 的文件描述符 targetFD，获取同步锁然后执行 transferToDirectlyInternal() 方法。

private long transferToDirectly(long position, int icount, WritableByteChannel target)
        throws IOException {
    // 省略从target获取targetFD的过程
    if (nd.transferToDirectlyNeedsPositionLock()) {
        synchronized (positionLock) {
            long pos = position();
            try {
                return transferToDirectlyInternal(position, icount,
                        target, targetFD);
            } finally {
                position(pos);
            }
        }
    } else {
        return transferToDirectlyInternal(position, icount, target, targetFD);
    }
}

最终由 transferToDirectlyInternal() 调用本地方法 transferTo0() ，尝试以 sendfile 的方式进行数据传输。如果系统内核完全不支持 sendfile，比如 Windows 操作系统，则返回 UNSUPPORTED 并把 transferSupported 标识为 false。如果系统内核不支持 sendfile 的一些特性，比如说低版本的 Linux 内核不支持 DMA gather copy 操作，则返回 UNSUPPORTED_CASE 并把 pipeSupported 或者 fileSupported 标识为 false。

private long transferToDirectlyInternal(long position, int icount,
                                        WritableByteChannel target,
                                        FileDescriptor targetFD) throws IOException {
    assert !nd.transferToDirectlyNeedsPositionLock() ||
            Thread.holdsLock(positionLock);

    long n = -1;
    int ti = -1;
    try {
        begin();
        ti = threads.add();
        if (!isOpen())
            return -1;
        do {
            n = transferTo0(fd, position, icount, targetFD);
        } while ((n == IOStatus.INTERRUPTED) && isOpen());
        if (n == IOStatus.UNSUPPORTED_CASE) {
            if (target instanceof SinkChannelImpl)
                pipeSupported = false;
            if (target instanceof FileChannelImpl)
                fileSupported = false;
            return IOStatus.UNSUPPORTED_CASE;
        }
        if (n == IOStatus.UNSUPPORTED) {
            transferSupported = false;
            return IOStatus.UNSUPPORTED;
        }
        return IOStatus.normalize(n);
    } finally {
        threads.remove(ti);
        end (n > -1);
    }
}

本地方法（native method）transferTo0() 通过 JNI（Java Native Interface）调用底层 C 的函数，这个 native 函数（Java_sun_nio_ch_FileChannelImpl_transferTo0）同样位于 JDK 源码包下的 native/sun/nio/ch/FileChannelImpl.c 源文件里面。JNI 函数 Java_sun_nio_ch_FileChannelImpl_transferTo0() 基于条件编译对不同的系统进行预编译，下面是 JDK 基于 Linux 系统内核对 transferTo() 提供的调用封装。

#if defined(__linux__) || defined(__solaris__)
#include <sys/sendfile.h>
#elif defined(_AIX)
#include <sys/socket.h>
#elif defined(_ALLBSD_SOURCE)
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/uio.h>

#define lseek64 lseek
#define mmap64 mmap
#endif

JNIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_transferTo0(JNIEnv *env, jobject this,
                                            jobject srcFDO,
                                            jlong position, jlong count,
                                            jobject dstFDO)
{
    jint srcFD = fdval(env, srcFDO);
    jint dstFD = fdval(env, dstFDO);

#if defined(__linux__)
    off64_t offset = (off64_t)position;
    jlong n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
    return n;
#elif defined(__solaris__)
    result = sendfilev64(dstFD, &sfv, 1, &numBytes);    
    return result;
#elif defined(__APPLE__)
    result = sendfile(srcFD, dstFD, position, &numBytes, NULL, 0);
    return result;
#endif
}

对 Linux、Solaris 以及 Apple 系统而言，transferTo0() 函数底层会执行 sendfile64 这个系统调用完成零拷贝操作，sendfile64() 函数的原型如下：

#include <sys/sendfile.h>

ssize_t sendfile64(int out_fd, int in_fd, off_t *offset, size_t count);

下面简单介绍一下 sendfile64() 函数各个参数的含义：

• out_fd：待写入的文件描述符
• in_fd：待读取的文件描述符
• offset：指定 in_fd 对应文件流的读取位置，如果为空，则默认从起始位置开始
• count：指定在文件描述符 in_fd 和 out_fd 之间传输的字节数

在 Linux 2.6.3 之前，out_fd 必须是一个 socket，而从 Linux 2.6.3 以后，out_fd 可以是任何文件。也就是说，sendfile64() 函数不仅可以进行网络文件传输，还可以对本地文件实现零拷贝操作。

其它的零拷贝实现

Netty零拷贝

Netty 中的零拷贝和上面提到的操作系统层面上的零拷贝不太一样, 我们所说的 Netty 零拷贝完全是基于（Java 层面）用户态的，它的更多的是偏向于数据操作优化这样的概念，具体表现在以下几个方面：

Netty 通过 DefaultFileRegion 类对 java.nio.channels.FileChannel 的 tranferTo() 方法进行包装，在文件传输时可以将文件缓冲区的数据直接发送到目的通道（Channel）

ByteBuf 可以通过 wrap 操作把字节数组、ByteBuf、ByteBuffer 包装成一个 ByteBuf 对象, 进而避免了拷贝操作 ByteBuf 支持 slice 操作, 因此可以将 ByteBuf 分解为多个共享同一个存储区域的 ByteBuf，避免了内存的拷贝 Netty 提供了 CompositeByteBuf 类，它可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf，避免了各个 ByteBuf 之间的拷贝 其中第 1 条属于操作系统层面的零拷贝操作，后面 3 条只能算用户层面的数据操作优化。

RocketMQ和Kafka对比

RocketMQ 选择了 mmap + write 这种零拷贝方式，适用于业务级消息这种小块文件的数据持久化和传输；而 Kafka 采用的是 sendfile 这种零拷贝方式，适用于系统日志消息这种高吞吐量的大块文件的数据持久化和传输。但是值得注意的一点是，Kafka 的索引文件使用的是 mmap + write 方式，数据文件使用的是 sendfile 方式。

点赞 + 关注 + 收藏 = 学会了

💡整理了一个 NAS 专属玩法专栏，感兴趣的工友可以戳这里关注 👉 《NAS邪修》

UPage 是一款开源的 AI 生成式网页构建工具。只需输入一段描述，它就能利用大模型能力帮你搓个静态网页出来。

打开飞牛的「文件管理」，在 docker 文件夹下创建 upage 目录。

在 upage 内递归创建以下三个子文件夹：

• /docker/upage/data
• /docker/upage/logs
• /docker/upage/storage

打开「Docker」应用，切换到 Compose 面板，新增项目：

• 项目名称：upage
• 路径：/docker/upage
• 来源：创建docker-compose.yml

输入以下代码：

services:
  upage:
    image: halohub/upage:latest
    container_name: upage
    ports:
      - 3456:3000 # 3456 这个端口可以自定义
    environment:
      - LLM_PROVIDER=OpenAI
      - PROVIDER_BASE_URL=https://api.longcat.chat/openai/v1
      - PROVIDER_API_KEY=your_api_key_here # 请替换为你申请的 API Key
      - LLM_DEFAULT_MODEL=LongCat-Flash-Thinking-2601
      - LLM_MINOR_MODEL=LongCat-Flash-Lite
    volumes:
      - ./data:/app/data
      - ./logs:/app/logs
      - ./storage:/app/storage
    restart: unless-stopped

⚠️ 关键参数说明：

volumes 里的3个值分别对应在第一步创建的文件夹。

environment 里配置大模型的相关参数：

• LLM_PROVIDER：大模型提供商。现在很多模型都兼容 OpenAI 规范，所以我选了 OpenAI
• PROVIDER_BASE_URL：大模型提供商的 API 地址。我用了美团的 LongCat，因为它每天提供5500万 token，相当大方。你也可以选择其他提供商的。
• PROVIDER_API_KEY：API Key，去对应的服务商后台申请后贴入。
• LLM_DEFAULT_MODEL：主模型名称。我使用 LongCat 的 LongCat-Flash-Thinking-2601 这个模型。
• LLM_MINOR_MODEL：次要模型名称。

项目构建成功后，在浏览器打开 NAS_IP:3456 就可以访问 UPage 了。

在输入框输入你的需求，Upage 就会帮你做个静态网页出来。

网页写好后，点击右上角的“下载代码”可以把源码下载下来。

如果觉得生成的页面不满意，可以重写提示词，或者点击右侧预览面板直接修改页面文本内容。

以上就是本文的全部内容啦，你有好玩的镜像推荐吗？欢迎在评论区留言讨论！

想了解更多NAS玩法记得关注《NAS邪修》👏

往期推荐：

• 『NAS』不止娱乐，NAS也是生产力，在绿联部署AI工作流工具-n8n
• 『NAS』在绿联部署DeepSeek，接入n8n工作流-ollama
• 『NAS』绿联NAS + AI Plugins，每天白嫖美团 5500万 Token 大模型！

点赞 + 关注 + 收藏 = 学会了

编者按： 在 AI 智能体赛道竞争白热化的今天，为何巨头们会突然放弃私有壁垒，共同拥抱同一套技术标准？

我们今天为大家带来的文章，作者的观点是：Agent Skills 之所以能在 90 天内从私有功能演变为行业标准，关键在于其“渐进式披露”的架构设计解决了 Token 经济学痛点，以及“一次编写，处处运行”的可移植性打破了平台壁垒。

文章详细回顾了 2025 年 10 月至 12 月间，Anthropic 如何通过简单的 Markdown 文件格式推出 Agent Skills，并迅速获得 OpenAI 和 Microsoft 的跟进支持。文中深入剖析了技能加载的“渐进式披露”机制如何大幅降低 Token 消耗，对比了其与微调、Custom Instructions 等方案的优劣，并展示了开发者生态在三周内从 0 爆发至 25,000 个技能的惊人增长。此外，文章还探讨了巨头背后的战略博弈，以及企业应如何布局技能治理与基础设施。

标准化往往是生态成熟的前奏，当定制 AI 能力不再受制于平台锁定时，真正的智能体应用规模化落地才刚刚开始。

作者 | Han HELOIR YAN, Ph.D.

编译 | 岳扬

2025 年 12 月 18 日，AI 行业发生了一件不同寻常的事：OpenAI 宣布将采用由其主要竞争对手 Anthropic 制定的一项标准。短短几小时内，Microsoft 也迅速跟进，把同样的技术标准格式集成到了 GitHub Copilot 和 VS Code 中。而 Google 其实早在两个月前就已推出了类似的系统。到那周结束时，一个开源社区平台上已经列出了超过 25,000 个该新标准的实现方案。

这并非一次新模型的发布。没有基准测试排行榜上的刷分大战，也没有“碾压 GPT-5”之类的标题党新闻。这是一件更具深远意义的事件：一种用于教会 AI 智能体执行专业工作流的通用格式正式诞生。Anthropic 将其称为“Agent Skills”，而在 2025 年 10 月到 12 月这 90 天里，这项技术迅速从一项私有功能演变为事实上的行业标准。

这件事的关键在于：为什么一家并没有最强模型的公司，却能主导整个行业定制 AI 的方式？如果你正在构建 AI 智能体、交付 AI 驱动的产品，或是设计未来需要对接多家 AI 服务供应商的系统架构，那么这件事的重要性，远超过你今年能看到的任何一次基准测试分数提升。

01 2025 年 10 月 16 日：低调发布

Anthropic 于 2025 年 10 月 16 日面向 Claude 用户推出了 Agent Skills 功能。官方公告言简意赅： “Skills 就是一个包含指令、脚本和资源文件的文件夹，Claude 可以在需要时加载它们。”

其技术架构刻意保持简单。每个 Skill 对应一个目录，其中必须包含一个 SKILL.md 文件，该文件采用 YAML 前置元数据与 Markdown 指令说明相结合的格式。

真正的创新在于其加载机制。 启动时，Claude 会扫描所有可用的 Skills，但只将它们的元数据（Skill 名称和 Skill 描述）加载到系统提示词中。这些元数据相当于一个索引目录，每个 Skill 大约消耗 30–50 个 token。当用户请求匹配到某个 Skill 的应用领域时，Claude 才会通过文件系统访问加载完整的指令内容。假如一个代码库中有 100 个 Skills，那么初始只需约 5,000 个 token 存储元数据，而每个 Skill 的完整内容（通常 2,000–5,000 个 token）仅在真正需要时才加载。

Anthropic 在工程博客中将这种设计称为 “渐进式披露”（progressive disclosure） 。这一模式借鉴自信息架构领域，核心思想是只在必要时才引入复杂内容。对 AI 智能体而言，它解决了一个实际痛点：如何让智能体访问大量程序性知识，又不至于在开始工作前就耗尽上下文窗口？

开发者兼 AI 研究员 Simon Willison 在 10 月 16 日写道：“Skills 的概念极其简单：一个 Skill 就是一个 Markdown 文件，告诉模型如何完成某项任务，还可以附带额外文档和预先写好的脚本。关于 Skills 的设计，有一点我非常喜欢，它没有任何限制阻止这些 Skills 被其他模型使用。”

他预测道：“我预计我们将看到 Skills 的寒武纪大爆发，相比之下，今年的 MCP 热潮都会显得平淡无奇。”

最初的反响积极但较为克制。GitHub 上的 anthropic/skills 仓库起初只包含 Anthropic 提供的一个示例：用于为 DOCX、PPTX、XLSX 和 PDF 文档创建 Skills。这些并不是仅供演示的简单示例，它们正是 Claude 在生产环境中驱动文档生成功能所使用的 Skills。

02 11 月：悄然增长阶段

在 11 月期间，有趣的事情发生了。开发者们在没有营销推动或激励计划的情况下，开始自发地构建 Skills。Skills 仓库的示例数量增长到 50 多个，覆盖创意设计、技术开发和企业沟通等多个领域。

早期的企业试点项目陆续出现。云内容管理公司 Box 构建的 Skills，能将存储的文件自动转换为符合组织标准的格式化文档。日本电商巨头 Rakuten 部署了用于财务操作的 Skills，此前这类操作需要跨部门人工协调。Canva 则集成了用于品牌合规设计工作流的 Skills。

通过实际使用，Skills 在 token 效率方面的优势逐渐显现。GitHub MCP server 是一种比较流行的将 AI 智能体连接到 GitHub 仓库的方式，仅其工具定义和上下文就消耗约 15,000–30,000 个 tokens。而一个提供类似 GitHub 工作流指导的 Skill，元数据仅需 50 个 tokens，完整加载时也只需 3,000–4,000 个 tokens，token 效率提升了 5–10 倍。

更重要的是，Skills 在 Claude 可用的所有场景都能运行：claude.ai 网页界面、Claude Code（Anthropic 的命令行编码智能体）以及 Claude API。编写一次 Skill，即可立即在所有平台上使用。对于投资 AI customization（即为自身需求专门定制 AI 功能）的企业而言，这种可移植性至关重要。

03 2025 年 12 月 18 日：开放标准正式发布

2025 年 12 月 18 日，三项公告几乎同时发布：

1）Anthropic 在 agentskills.io 上将 Agent Skills 规范作为开放标准发布，包含完整文档、参考版 Python SDK，以及对跨平台可移植性的明确承诺。

2）OpenAI 为其 Codex CLI 和 ChatGPT 采用了完全相同的 SKILL.md 格式。OpenAI 的开发者文档已同步更新，展示对 Skills 的支持，文件结构与 YAML frontmatter 与 Anthropic 保持一致。放置在 ~/.codex/skills/ 目录下的 Skills 会被自动发现并加载使用。

3）Microsoft 与 GitHub 宣布在整个 Copilot 生态中支持 Agent Skills：涵盖 GitHub Copilot、VS Code、Copilot CLI，以及 JetBrains、Eclipse 和 Xcode 等主流 IDE 中的 agent 模式。

与此同时，Anthropic 推出了 Skills Directory —— 这是一个 Skills 精选市场，汇集了 Notion、Figma、Atlassian、Canva、Stripe、Ramp 和 Sentry 等合作伙伴打造的专业级 Skills。

面向 Team 与 Enterprise 套餐的企业客户，Anthropic 新增了组织级别的管理功能。管理员可为整个团队统一配置 Skills、设定默认启用项，并追踪使用情况。

其战略影响不言自明：Anthropic 的主要竞争对手 OpenAI，竟在该标准开源发布后数小时内便迅速采用；而 Microsoft 当时已有 23 万家企业使用 Copilot Studio（覆盖《财富》500 强中的 90%），正将 Skills 深度集成至其整套开发者工具链中。

04 12 月 19–31 日：市场爆发期

开放标准发布后 24 小时内，社区驱动的 Skills 市场平台如雨后春笋般涌现。独立社区项目 SkillsMP（Skills Marketplace）上线，通过自动抓取 GitHub 公共仓库实现了 Skills 索引自动化。

其增长轨迹令人瞩目：

• 第 1 周（12 月 19–25 日）：约 8,000 个 Skills 被索引
• 第 2 周（12 月 26–31 日）：约 17,000 个 Skills 被索引
• 截至 2026 年 1 月 9 日：超过 25,000 个 Skills 被编目

这些并非重复或低质量内容。SkillsMP 设置了质量过滤机制，要求至少 2 个 GitHub stars 和近期更新记录，并扫描其基础质量指标。平台将 Skills 分为四大类：开发与技术类（占总量 40%）、文档类（25%）、企业与沟通类（20%），以及创意与设计类（15%）。

到 2025 年 12 月底，Skills 从 Anthropic 的私有功能演变为跨平台的行业标准，整个过程恰好历时 90 天。

05 技术实况核查：不绕弯子的拆解

5.1 架构本质：Markdown、YAML 与 Progressive Disclosure（渐进式披露）

Agent Skill 的核心设计极其简单：一个文件夹，内含一个带 YAML frontmatter 的 Markdown 文件，外加可选的资源文件。

其创新之处在于加载机制。渐进式披露通过三阶段加载机制实现：

• 第一阶段 — 启动时：智能体将所有 Skill 的元数据加载到系统提示词中。一个典型 Skill 的描述约 50 个词，消耗 40–50 个 tokens；100 个 Skills 的元数据总计约 4,000–5,000 个 tokens。
• 第二阶段 — 匹配时：处理用户请求过程中，智能体扫描 Skill 描述，识别相关匹配项。
• 第三阶段 — 加载时：匹配成功后，智能体通过文件系统工具读取完整的 SKILL.md 文件。此时完整内容才进入上下文窗口，根据复杂度消耗 2,000–5,000 个 tokens。

这种架构使得 Skill 库理论上可以无限扩展。一家企业可维护 1,000 个 Skills，元数据仅占用约 50,000 个 tokens，相当于 Claude Sonnet 4 20 万 token 上下文窗口的 25%。

5.2 Token 经济学：这才是它真正重要的原因

上下文窗口是有限且昂贵的资源。理解其中的 token 经济学，才能明白为什么 Skills 能成功，而其他方案却步履维艰。

5.3 Skills 无法做到的事情（坦诚环节）

• 无法获取实时的外部数据：Skills 是静态文件。若无 MCP 服务器或直接的 API 工具集成，无法拉取实时数据。
• 调用的非确定性：模型是否调用某个 Skill，是基于语义匹配的概率性决策，无法保证一定触发。
• 调试过程不透明：当 Skill 未被触发或执行指令出错时，往往难以完全追溯原因。
• 依赖代码执行环境：包含脚本的 Skills 需要代码执行环境支持（如 Claude Code 或 GitHub Copilot）。
• 平台差异：虽然格式已标准化，但各平台在实现细节上仍有差异（例如文件发现路径）。

5.4 Skills 与其他方案对比 —— 为什么 Skills 能成，而其他方案都失败了

现在来回溯一下 Skills 崛起的前两年究竟发生了什么。

1）Custom Instructions 时代：过于简单

2024 年 7 月，OpenAI 为 ChatGPT 引入 Custom Instructions。你可以设置“始终用 Python 写代码”或“我是资深工程师，跳过基础解释”。适合个人偏好，但面对复杂场景完全无能为力。

问题在于：你只能设置一套指令，始终加载、无法共享。试着在一个限制为 1500 个字符的文本框里解释你们公司 47 步的代码审查流程。然后看着你的同事手动重复这一过程，因为他们无法访问你的指令。

2）GPT Store 时代：虽接近但仍差一步

2024 年 11 月，OpenAI 推出 Custom GPTs，终于能构建带知识文件的专用智能体并分享出去。GPT Store 于 2025 年 1 月上线，到 6 月已积累 300 万个 GPTs。

那些拥有企业级需求的用户一开始很兴奋，但很快就撞墙了。

平台不互通：你的“API 安全审查 GPT”只能在 ChatGPT 里用，你们团队用 Claude，运维团队用 GitHub Copilot。恭喜，同一套逻辑你得维护三份副本。

上下文窗口不够用：GPTs 会预先加载全部知识。给 GPTs 塞 20 个示例文档？用户还没输入，上下文已吃掉 40,000 个 tokens。想维护 50 个供整个团队使用的 GPTs？上下文窗口直接宣告死亡。

缺乏治理：人人都能创建 GPTs，没有审批流程，没有版本控制。某天安全团队发现有人搭了个“SQL 查询助手”，而它把所有数据库凭证都记录了 —— 好戏就开始了。

到 2025 年年中，拥有企业级需求的那些用户都有一股挫败感：方向是对的，但这条路走不通。

3）2025 年 10 月：Skills 找对了路子

Anthropic 看清了哪些要素行之有效（GPTs 的专业化能力），什么行不通（其他所有尝试），然后将其简化到最本质的内容：

一份 Markdown 文件。仅此而已。

没有绑定平台 —— 随处可用。没有预加载成本 —— 用时才付费。天然适配 Git —— 像普通代码一样做版本控制。具备在中大型企业环境中规模化、安全、合规地部署和使用的能力 —— 安全团队能直接审查文件内容。

Skills 的采用曲线说明了一切：第一周 8,000 个 Skills，第三周突破 25,000 个。标准发布后 48 小时内，Microsoft 和 OpenAI 相继采纳了这一格式。

当你的竞争对手立刻照搬你的东西时，你就已经赢了。

5.5 关于 MCP，人人都问错了问题

人们总在问：“我该用 Skills 还是 MCP？”

这个问题本身就错了。它们干的是完全不同的事。

MCP 负责连接外部系统 —— 它是智能体的“手”，能伸进 Slack、拉取数据库、调用 API。没有 MCP，智能体就被困在自己的上下文窗口里，寸步难行。

Skills 用于指导工作流 —— 它是智能体的“训练手册”，告诉它如何做代码审查、什么算好的 API 设计、何时该升级问题。没有 Skills，智能体虽能访问一切，却对你的业务流程一无所知。

5.6 实际应用中是这样的

销售团队问：“我们的 pipeline 里有哪些卡住的单子？”

仅用 MCP：

• 智能体通过 MCP 连接 Salesforce
• 返回：47 条 JSON 格式的订单记录
• 用户手动逐条审查
• 耗时 30 分钟

仅用 Skills：

• 智能体无法访问 Salesforce
• 用户手动导出数据
• 智能体用 Skills 中的规则分析
• 耗时 20 分钟

两者结合：

• 智能体通过 MCP 连接 Salesforce
• 自动加载 "pipeline-review" Skill
• 关联 Slack 中的相关对话
• 生成卡单的 Markdown 表格
• 标记出 3 个需立即跟进的订单
• 建议具体的跟进步骤
• 耗时 3 分钟

这正是 Notion 为其“Meeting Intelligence”Skill 搭配 MCP 连接的原因：MCP 抓取日历、相关文档和近期的 Slack 讨论；Skill 则懂得如何将这些信息整合成符合你公司标准的会议准备模板。

这套组合的 token 消耗约 18,000。数字听着不少，但你得意识到，你的助手刚用 30 秒干完了原本要花 45 分钟的活。

5.7 微调 与 Skills 之争

这里正是资金浪费重灾区。

微调方案是通过训练改变模型的权重。你喂给它示例数据，跑昂贵的计算任务，等上好几天，最终得到一个专用模型。单次训练成本在 500 到 5,000 美元之间。

Skills 则只是在运行时注入指令。编辑一份 Markdown 文件，5 分钟搞定，成本几乎为零。

陷阱在于，很多团队总以为需要微调，其实用 Skills 就够了。

如果医疗初创公司希望智能体理解肿瘤学术语，微调确实是合理的，因为你是在教它基础模型原本不懂的专业语言。

但如果你的团队只想让智能体遵循代码审查流程？那该用 Skill。模型本身已经懂代码审查，你只是在指定你们团队的特定标准。

5.8 二八定律

现代基础模型（Claude Sonnet 4、GPT-4o、Gemini 2.0）开箱即用的能力已相当惊人。对大多数团队而言：

• 80% 的需求：一个 Skill 就能搞定
• 20% 的边缘场景：或许才需要微调

真正需要微调的场景：

• 涉及专业术语的医疗报告
• 有特定引用格式的法律文书
• 充斥着领域专业术语的科研论文
• 对速度有极致要求的高吞吐任务

Skills 完全够用的场景：

• 遵循公司内部流程
• 应用标准与模板
• 正确使用内部工具
• 基于既定规则做决策

关键差异：Skills 可即时更新。API 标准变了？改个文件，重启即可。微调则每次变更都得重新训练。按季度重新训练，一年光维持更新就要烧掉 12,000 美元。

06 多家科技巨头围绕 AI 智能体定制化标准展开的战略博弈

6.1 12 月 18 日的妙手

2025 年 12 月 18 日，三家公司几乎在同一时间发布声明。如果你眨眼了，你就会错过今年 AI 基础设施领域最精彩的一场权力博弈。

太平洋时间 9:00：Anthropic 发布 agentskills.io —— 一套带有参考实现、示例 Skills 和完整文档的开放标准，完全免费。

太平洋时间 11:30：OpenAI 更新开发者文档。Codex CLI 正式支持 SKILL.md 格式。没有新闻稿，只有一条静默的 changelog。

太平洋时间 14:00：Microsoft 为 GitHub Copilot 和 VS Code 增加 Skills 支持。同样悄无声息，某天打开编辑器，它就在那儿了。

三家竞争对手在五小时内集体采用同一套格式？这绝非偶然。

6.2 Anthropic 的布局

来看看 Anthropic 的布局，以及它为何能够奏效。

10月16日：将 Skills 作为 Claude 的私有功能推出，让企业用户上钩。Box 用它自动化文档处理流程，Rakuten 用它简化财务运营流程。

11月：坐观使用量极速增长。Skills 从内部工具演变为生产依赖组件。此时，企业用户已与之深度绑定。

12月18日：将该技术作为开放标准发布。所有人构建的 Skill 依然可用，但现在它们无处不在。

这正是 Anthropic 在 Model Context Protocol（MCP）上用过的同一套打法：

• 2024 年 11 月：为 Claude 推出 MCP
• 12 个月：社区共建生态
• 2025 年 12 月 9 日：捐赠给 Linux Foundation，成为开放标准

作为私有功能发布 → 生态培育 → 开放开源。这正逐渐成为 Anthropic 的标志性策略。

6.3 为何 OpenAI 立刻采用了这一技术

12 月 18 日，OpenAI 面临两个选择：

• 选项 A：无视 Skills，全力推 GPT Store 和 AgentKit，靠平台绑定留住用户。
• 选项 B：采纳 Skills，放弃差异化，以执行能力而非生态壁垒竞争。

他们不到三小时就选了 B。

这正是耐人寻味之处。

OpenAI 正同时执行两套看似矛盾的策略：

私有化路线： 带收入分成的 GPT Store、面向复杂多智能体系统的 AgentKit、定制语音模式 —— 这些是竞争对手难以复制的护城河。

开放标准路线： 2025 年 12 月采纳 MCP，同日拥抱 Skills，积极参与共享基础设施建设。

这正是“Android 策略” —— 在采纳开放标准的领域共建生态，同时在平台层构建差异化。OpenAI 清楚：开发者不会为锁定单一供应商的定制方案投入资源。

他们的算盘是：与其独占一个小市场，不如在一个大市场里占据三成份额。

事实印证了这一点：截至 2026 年 1 月，Skills 已可在 ChatGPT 桌面端、Codex CLI 和 API 集成中运行，OpenAI 团队还深度参与了 Skills 标准的后续讨论 —— 他们不只是采用这一技术，而是在共同开发。

6.4 Microsoft 的选择：拥抱并集成

Microsoft 拥有 23 万家企业用户使用 Copilot Studio，覆盖《财富》500 强中的 90%。当 Anthropic 开放 Skills 时，Microsoft 本是最可能受损的一方。他们花了数年时间搭建 Copilot 的知识连接器、自定义指令、插件体系，一整套企业级基础设施。

他们本可以筑墙自守，却选择了搭桥互通。

12月18日：Skills 支持覆盖整个 Copilot 生态 —— VS Code、GitHub Copilot、Copilot Studio，以及所有主流 IDE。

策略很清晰：“用我们的执行环境，带你的 Skills 来”。Microsoft 不再试图掌控定制层，而是押注规模效应：更多开发者、更多推理请求、更多 Azure 算力消耗。

这是 Microsoft 云战略在 AI 领域的复制。还记得他们开源 .NET、拥抱 Linux 吗？这是同一套逻辑。当你是基础设施提供商时，你是通过增加总使用量获胜，而非通过锁定格式。

效果立竿见影：对 Skills 的支持直接推动了已投入 Claude Skills 的企业加速采用 Copilot。

6.5 Google 的静默反制

当其他厂商纷纷采纳 SKILL.md 时，Google 走了另一条路。

2025 年 10 月 8 日：Gemini CLI 推出 Extensions。不是 Skills，是 Extensions。不是 SKILL.md，是 GEMINI.md。

二者的结构相似：YAML 头部、Markdown 主体、渐进式加载。但差异足以造成互不兼容。

到 12 月：70+ 个 Gemini Extensions，超 100 万开发者，独立市场平台成型。

所有人都在问：这是格式战争，还是和平共存？

乐观派：两种格式都能存活。格式转换极其简单 —— SKILL.md 转 GEMINI.md 基本是查找替换。多格式支持终将成为标配。

悲观派：Google 看到 Skills 势头太猛，急需差异化筹码。宁可掌控一个小生态，也不愿在他人的地盘当配角。

现实情况是：截至 2026 年 1 月，尚无融合迹象。Gemini Extensions 与 Agent Skills 服务于重叠但有差异的场景 —— Extensions 更深度绑定 Google Workspace，Skills 则保持更强的平台无关性。

结局可能如同 IDE 扩展格式之争 —— VS Code 与 JetBrains 各自以不兼容的格式蓬勃发展。也可能最终迫使行业走向统一标准。现在下结论，为时过早。

6.6 Skills 开放标准发布后，开发者生态爆发式增长

当巨头们在谈判桌上运筹帷幄时，开发者们已全速行动。

12 月 19 日：SkillsMP 上线 —— 首个独立的 Skills 市场平台。

12 月 31 日：8,000 个 Skills 可用。

2026 年 1 月 9 日：25,000 个 Skills。三大市场平台同台竞争。各细分品类头部作品开始涌现。

这才是真正赢得格式战争的关键。不是企业战略——而是生态势能。

当 25,000 个 Skills 同时在三大主流平台上运行，网络效应便进入自我强化循环：

• 开发者构建 Skills，因为有分发渠道
• 平台支持 Skills，因为有内容供给
• 用户期待 Skills，因为它们无处不在

Google 的 GEMINI.md 拥有 70+ 个扩展，这已相当可观。但 Skills 的数量是它的 350 倍。网络效应就是如此残酷。

6.7 这对 2026 年意味着什么

战略格局已然清晰：

Anthropic：赢下了标准化之战，通过放弃独占性，收获整个生态。这笔交易是刻意为之，他们相信：在足够大的市场中做最好的执行者，远胜于在小池塘里做唯一的主人。

OpenAI：完美对冲。在关键处保留私有功能（GPT Store、语音），在生态系统重要的领域拥抱开放标准（MCP、Skills）。在执行质量上竞争。

Microsoft：走量策略。只要所有推理都跑在 Azure 上，谁的格式胜出并不重要。

Google：两线作战 —— GEMINI.md 对抗 SKILL.md，Gemini 对抗 Claude/GPT-4。处境虽艰难，但并非没有希望。

6.8 真正的赢家

真正的赢家是开放格式。

在 AI 智能体开发的历史上，你首次能够构建一套定制方案，随处运行。你的代码审查 Skill 能在 Claude、ChatGPT、Copilot 乃至（稍作修改后）Gemini 上运行。

这在 AI 工具史上从未发生过。此前每一代方案，从 Custom GPTs 到插件再到 Actions，都因平台绑定而消亡。

Skills 或许真能长久存在，恰恰因为没人独占它。

07 Skills 市场平台的爆发

7.1 三周内从 0 到 25,000

12月18日：公开市场中 0 个 Skills。

12月19日：SkillsMP 上线，首发 127 个 Skills。

12月26日：8,000 个 Skills。

1月9日：25,000 个 Skills。

而 Chrome 扩展花了两年才达到 10,000 个；VS Code 扩展用了 18 个月达到 8,000 个。Skills 仅用一周便达成。

这是 AI 工具史上生态增长最快的一次。

7.2 为何爆发得如此之快

开发者早已在等待这样的方案。

GPTs 过于封闭，微调成本太高，自定义指令又太过局限。Skills 是那个“刚刚好”的方案 —— 强大到足以干实事，简单到一下午就能构建，可移植性又足以产生影响。

此外，每家已经构建了 Claude Skills 的公司都能立即发布它们。Box 的文档转换 Skills？发布了。Rakuten 的财务自动化？发布了。房地产定价分析？发布了。

到 12 月 20 日，Skills 市场平台已被真实企业用户贡献的生产级内容迅速填满。

7.3 人们究竟构建了什么 Skills

细分如下：

40% 开发工具类 —— 代码审查、API 设计、安全扫描、测试生成。每个工程团队都有自己那一套想自动化的流程。

赢家："API Standards Enforcer" —— 17,000 次下载。在 PR 审查阶段自动检查 OpenAPI 规范是否符合标准。某团队每周节省 8 小时。

25% 文档处理类 —— 会议纪要、合同分析、技术写作。遵循固定模式的知识工作。

赢家："Meeting Intelligence" —— 12,000 次下载。由 Notion 开发，聚合日历、文档与 Slack 讨论，自动生成会议准备材料。每场会议节省 30 分钟。

20% 企业运营类 —— 销售漏斗审查、财务分析、合规检查。融合多数据源的业务流程。

赢家："Sales Pipeline Analyzer" —— 9,000 次下载。在销售团队察觉前标记即将停滞的订单。报告称成交率提升 15%。

15% 创意与内容类 —— 博客结构、内容复用、品牌一致性。营销自动化场景。

赢家："Technical Blog Factory" —— 6,000 次下载。研究笔记 → 大纲 → 初稿，首稿撰写提速 60%。

7.4 质量问题

到 1 月，三大 Skills 市场平台共收录 25,000+ 个 Skills，问题随之浮现：

寻找优质项目困难：搜索“code review”返回 400 个结果，半数是重复，四分之一无法运行，另四分之一已过时。

缺乏质量信号：不像 npm 或 Chrome 扩展，没有下载量、用户评分等指标，选择如同盲人摸象。

文档混乱：部分 Skills 附带完整示例与测试，另一些仅写“Reviews code. Use for reviewing.” —— 感谢，真帮大忙了。

“版本地狱” ：Skills 本质是仓库中的文件，作者可能无声推送具有破坏性的内容变更，导致两周前还能用的 Skill 突然失效。

市场平台迅速响应 —— 引入用户评分、下载计数、认证徽章、精选合集。到 1 月中旬，质量信号初具雏形，但距离 npm 这类成熟生态仍有巨大差距。

7.5 利润来源与商业价值所在

大多数 Skills 免费开放。25,000 个中约 21,000 个采用 MIT 或 Apache 许可证。

部分采用免费增值模式：基础版免费，专业版收费。“API Standards Enforcer” 对“无限次检查”权限与自定义规则收取 49 美元/月。

但真正的利润藏在 Skills 周边的企业级基础设施中。

企业不为单个 Skills 付费，而是为以下能力买单：

• 带权限控制的私有仓库
• 全组织范围的部署能力
• 治理与合规支持
• 定制化与技术支持

Box 为 2,000 名员工部署了 40+ 个内部 Skills。他们并未从市场购买，而是自建了管理基础设施。

SkillsMP 看清了这一点，采用免费市场平台，对企业级功能收费：

• 私有团队仓库：200 美元/月
• 企业级管理后台：1,000 美元/月
• 可被企业以自身品牌重新包装并私有化部署的市场平台服务：5,000 美元/月
• 支持 SLA：10,000 美元/月

他们卖的不是 Skills，而是基础设施。

7.6 下一步将发生什么

到 2026 年年中：

市场洗牌：三大市场将收敛为一个市场主导平台和一个专注于企业客户的平台。历史将不断重演，npm 战胜 Bower，Chrome 商店胜过 Firefox 附加组件。

质量门槛提升：缺乏文档、测试或维护的 Skills 将被淘汰，专业级作品成为主流。

企业工具成熟：公司在 Skill 管理上的投入将超过 Skills 本身。出现类似 Artifactory 的内部 Skill 仓库。

垂直领域深化：医疗、金融、法律等行业的专用 Skills 成为利润高地。

格式升级：现行 SKILL.md 将增加版本控制、依赖管理、安全元数据。GitHub 与 Anthropic 已启动 v2 规范讨论。

爆发期即将结束，专业生态系统阶段正在开启。

关键是，从杠杆率最高的工作流切入。严格衡量成效。放大有效实践。果断淘汰无效尝试。

08 你需要知道的关键信息

我们刚刚见证了 AI 基础设施史上最快的普及进程：三周内从 0 到 25,000 个 Skills。五小时内四家巨头向同一标准收敛；整个生态在多数人还在忙着节日购物时悄然成型。

下面说重点。

8.1 战略层面的真相

Skills 能赢，恰恰因为它比较无聊。

没有区块链，没有复杂运行时，没有私有协议。就是 Git 仓库里能被任何智能体读取的 Markdown 文件。2025 年最具颠覆性的 AI 基础设施，本质上不过是一种文本文件格式。

真正能被广泛采纳的基础设施，靠的不是炫目的技术革命，而在于能否降低整个生态的协作成本。HTTP 战胜了 Gopher，JSON 战胜了 XML，REST 战胜了 SOAP，Markdown 在文档领域碾压一切。

Skills 再次证明：在开发者工具领域，无聊的方案反而更容易胜出。

8.2 这对你意味着什么

如果你在用AI智能体构建产品：

在 AI 工具领域，标准化问题长期无解 —— 过去每家平台都筑起围墙，定制化方案换个地方就得重写一遍。如今，Skills 首次真正破局：一次编写，处处运行。你的 Skill 写完后，无需修改即可在 Claude、ChatGPT 和 Copilot 间无缝流转。这种可移植性将直接重塑你的架构决策。

如果你是架构师，Skills 现在已是非选不可的基础设施，不再是锦上添花。你需要一套策略来应对：

• 如何管理内部 Skills（自建仓库？）
• 如何审核第三方 Skills（安全审查流程？）
• 如何治理（谁批准新 Skill？）
• 如何与现有工具集成（CI/CD、监控？）

2025 年初想清楚这些问题的公司，将比 2026 年才起步的对手领先整整一年。

如果你是技术负责人，这是个自研还是采购的决策 —— 无论你是否意识到，你已经在做选择了。

• 自研：针对公司特有的工作流构建内部 Skills —— 企业标准、合规规则、领域专长。这才是你的竞争优势。
• 采购：管理 Skills 的基础设施 —— Skill 仓库、安全扫描、部署系统。别自己造轮子，通用基础设施交给专业厂商。

预算参考：

• Skill 开发：中型团队每年 $50K–$200K
• Skill 基础设施：每年 $100K–$500K

投资回报率高得离谱 —— 某家房地产公司通过 8 个自动化房产分析工作流的 Skills，每年节省了 200 万美元。你的数据可能没这么夸张，但哪怕只有十分之一，几个季度就能回本，不用等上好几年。

8.3 接下来会发生什么

爆发阶段已经结束，专业生态系统阶段正在开启。到 2026 年年中，预计 Skills 市场平台将出现整合、Skills 质量门槛将会提高、企业级工具将成熟，并出现垂直领域专业化（医疗 Skills、金融 Skills、法律 Skills）。

格式本身也会演进。现行 SKILL.md 将增加版本控制、依赖管理和安全元数据。GitHub 与 Anthropic 已启动 v2 规范讨论。但核心概念 —— 带 YAML frontmatter 的 Markdown 文件，会继续保持“无聊”。而这正是它能长久存在的原因。

END

本期互动内容 🍻

你所在的公司或团队，已经开始整理自己的“Skills仓库”了吗？如果还没有，你觉得最大的阻碍是认知不足、工具缺失，还是根本用不上？

原文链接：

https://ai.gopubby.com/how-agent-skills-became-ais-most-impor...

在企业数字化营销的日常工作中，电商运营、品牌市场、活动策划、HR 等业务侧人员，始终绕不开一个核心痛点：移动端营销 H5 的制作与落地。提需求给设计开发团队，往往面临排期长、改稿沟通成本高的问题，极易错过营销热点与活动窗口期；自己上手制作，又常被工具操作门槛高、功能适配性差、视觉效果不达预期、页面加载性能拉胯等问题困住。
RollCode 作为一款聚焦企业移动端营销落地页场景的低代码开发工具，正是瞄准了业务侧人员的核心需求，以「可视化组件搭建 + 开放式代码嵌入」为技术内核，搭建了一套兼顾零代码操作门槛、全场景适配能力与灵活扩展空间的解决方案，让非技术出身的业务人员，也能自主完成从 H5 创意设计到上线发布的全流程。

重构低代码协作逻辑，让运营与开发各司其职
市面上多数低代码平台，始终没能解决一个核心问题：将页面渲染与数据模型配置捆绑，催生出了 “非运营、非开发” 的复合工作形态，既让业务人员觉得操作晦涩、学习成本高，又让开发人员觉得拓展受限、维护困难。
RollCode 跳出了传统低代码的固有框架，创新采用了View = Render(Data) + Embedding的全新设计模式，将视图拆解为静态数据渲染与灵活代码嵌入两大核心部分，把需求拆解为运营侧与开发侧两个独立的工作模块，形成了逻辑清晰的 1+1 协作模式 —— 既没有创造全新的工作内容，也没有打破两类角色的固有工作习惯，真正实现了 “让运营驱动设计，让灵活归于开发”。

其中，Embedding 提供了组件级、页面级、外链级三个层级的嵌入方案，全方位覆盖不同场景的开发诉求：运营人员负责页面可视化搭建、内容填充与效果优化，开发人员则通过代码嵌入解决动态数据、个性化功能的拓展需求，二者互不干扰，又能有机整合，彻底解决了传统低代码平台 “运营用不顺、开发用不爽” 的核心痛点。
零代码可视化搭建，把 H5 制作门槛降到最低
对于绝大多数没有专业编码能力的业务人员来说，工具的上手难度直接决定了使用效率。RollCode 编辑器深度融合了设计软件的操作逻辑，采用清晰的左中右布局，以 “所见即所得” 为核心原则，核心操作均通过拖拽组件完成，搭配实时预览效果，无需理解代码逻辑，就能完成页面 UI 搭建。
针对业务人员高频的布局调整需求，平台对布局容器做了全方位优化，水平容器与网格容器支持任意嵌套组合，可自由设置对齐方式、平分最大宽度、行列间隙等核心属性，哪怕是多列商品展示、复杂的活动信息排版，也能通过简单的参数调节实现，无需手动适配不同设备的显示效果。

同时，编辑器还打磨了大量提升效率的细节功能：数值输入框支持 option/alt + 鼠标拖拽的快捷调节方式，大幅提升参数调整效率；资源属性设置器集成了上传、裁剪、校验功能，一站式完成图片、视频等资源处理，省去了业务人员在设计软件与 H5 工具之间反复切换的麻烦；组件与页面均可另存为模板，实现跨项目复用，比如 HR 团队的招聘 H5、电商团队的大促活动页，只需将标准化的页面结构存为模板，后续活动仅需修改文案、图片等核心信息，就能快速生成新页面，彻底告别重复搭建的无效劳动。
AI 海报 + 全场景模板库，兼顾创意效率与视觉质感
营销 H5 的核心竞争力，除了上线效率，更在于视觉呈现与内容创意。很多业务人员能搞定页面结构，却卡在海报设计、视觉优化环节，最终只能做出效果平平的页面。
RollCode 新增的 AI 海报组件，直接补齐了这一短板。业务人员只需输入海报的主标题、副标题、正文内容，补充风格关键词与画面描述，就能快速生成符合需求的图文海报。更实用的是，生成的海报并非一张不可修改的图片，平台会自动将海报内容拆解为可独立编辑的组件，大到主标题、背景图案，小到装饰元素、祥云纹理，都能单独选中修改。
既可以直接替换文案，也能通过自然语言指令修改画面元素，甚至支持去除冗余文字、将图片内容转换为文字组件，完全满足营销活动的个性化修改需求，无需借助 PS 等专业设计工具，就能实现一站式的海报设计与页面嵌入，点击确定即可自动解析图文内容为组件并插入页面中，无需手动排版。

同时，平台整理并精选了数十个覆盖全行业的项目案例与模板，涵盖电商促销、活动推广、企业招聘、教育课程、新品发布、节日营销、金融营销等核心商业化场景，完全匹配业务侧人员的日常工作需求。无论是电商运营要做商品促销页、市场人员要做品牌新品发布页、活动策划要做线下活动报名页，还是 HR 要做招聘简章，都能直接一键创建同款项目，无需从零搭建，快速完成页面制作与上线。
灵活的扩展能力
对于业务人员偶尔遇到的动态数据更新需求，RollCode 新增了数据修改器功能，无需复杂的代码开发，就能自由改写组件数据，实现接口数据对接与动态渲染。比如电商大促期间，商品的价格、库存、主讲教师信息变动，只需通过简单的代码修改，就能批量更新页面内容，且不影响原有的静态数据，可自由开启或关闭，既满足了动态数据的更新需求，又不会给业务人员带来过高的操作门槛。
而对于有开发能力的团队，平台还单独新增了自定义组件开发调试页面，实现与真实页面数据隔离，左侧栏可一次性展示开发者所有的普通组件、页面组件，输入本地组件的调试地址后即可进行调试。开发者可通过自定义组件、自定义页面、RollCode 模式三大核心模块，自由编写代码拓展功能，无需受到平台限制，彻底打破传统低代码平台的能力天花板，充分释放开发者的创造力与生产力。

针对多站点、多区域运营的企业，平台还支持项目内容的导入与导出（私有化部署版本可用），可将成熟的项目完整导出为压缩包，跨平台、跨私有化版本复用，彻底解决多项目重复开发的问题。
SSG 静态发布
对于营销活动来说，页面的上线速度、加载性能，直接影响最终的转化效果。业内研究数据显示，页面加载每延迟 1 秒，用户跳出率便会显著攀升。为从根源规避白屏、加载缓慢等问题，RollCode 打破传统 “JSON + 固定 SPA” 的渲染模式，创新性采用 SSG 静态发布方案，通过按需构建、代码分割、路由预加载等多种技术手段，大幅缩减了打包产物的体积，实现了加载速度的跨越式提升。
在模拟 4G 网络环境、无痕模式下的对比测试中，RollCode 优化后的 SSG 页面，加载性能远优于传统 SPA 模式，用户访问时可直接获取已预渲染完成的页面，不仅能大幅提升访问体验、降低用户跳出率，更能显著优化 SEO 表现，为营销活动转化提供坚实支撑。
平台的发布流程也做了极简优化，页面制作完成后，一键即可完成构建发布，自动生成可直接访问的链接；同时支持页面代码导出，生成的生产级代码可直接部署至企业自有服务器或 OSS，充分满足企业对数据安全、自主部署的需求，适配各类企业的部署场景。
归根结底，RollCode 并非一款单纯的页面搭建工具，而是给企业业务侧与开发侧双向赋能的协作工具。它让原本依赖设计、开发团队的 H5 制作工作，变成了业务人员可自主掌控的流程，把业务人员从冗长的排期、反复的沟通改稿中解放出来，同时又为开发人员保留了充足的灵活扩展空间，真正实现了 “简单页面搭建更简单，复杂页面开发更灵活，开发和运营的协作更自然”。

开发者朋友们大家好：

这里是 「RTE 开发者日报」 ，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@koki、@鲍勃

01 有话题的技术

1、RunAnywhere 推出 RCLI，实现 131ms 端到端本地语音控制架构

RunAnywhere 发布的开源项目 RCLI 实现了 macOS 环境下全本地化的 Voice + RAG 闭环流水线。该系统通过优化端到端推理路径，将「语音输入至指令执行」的延迟压缩至 ～131ms，目前支持 43 项原生 macOS 自动化操作（覆盖 Spotify、窗口管理、FaceTime 等）。项目采用全开源模式，核心逻辑完全脱离云端，确保数据本地化存储与处理。

RCLI 的技术核心在于针对 Apple Silicon 深度优化的推理链路。下一版本计划引入 MetalRT 支持，届时预计 decode 速度可达 658 tok/s，并显著提升 自动语音识别（ASR）与语音合成（TTS） 的并发性能。该架构利用本地 RAG 插件实现文档问答与实时系统控制的协同，通过高性能本地推断规避了传统云端助理的延迟瓶颈。

GitHub 链接：

https\://github.com/RunanywhereAI/RCLI

( @sanchitmonga22\@x)

2、北京大学开源 Helios 14B，实现单卡 H100 视频实时生成

北京大学（PKU-YuanGroup）正式开源 Helios，这是一个参数量达 14B 的高性能视频生成模型。该模型通过架构优化，在单张 NVIDIA H100 上实现了实时生成（Real-time Generation），其推理速度超越了常规 1.3B 规模的模型，显著降低了高参数量模型在视频流合成中的延迟瓶颈。

Helios 架构原生支持多种生成范式与交互模式，具备类「世界模型（World Models）」的物理模拟潜力：

• 多模态输入：完整覆盖 Text-to-Video （T2V）、Image-to-Video （I2V） 及 Video-to-Video （V2V） 任务。
• 交互式生成：支持实时交互控制，允许用户在生成过程中干预视频状态，模拟动态环境反馈。
• 高效率推理：14B 参数量级下实现实时输出，标志着视频扩散模型或自回归模型在算力利用率上的重大突破。

目前该项目已在 GitHub 开源，提供模型权重与推理脚本。

GitHub 链接：

https\://github.com/PKU-YuanGroup/Helios

( @Gorden\_Sun\@X)

3、OpenAI 研发 BiDi 双向音频模型，旨在攻克实时中断与工具调用

OpenAI 正在研发代号为 BiDi（Bidirectional） 的新型实时音频模型，旨在打破当前 Advanced Voice Mode 的轮询式（Turn-based）交互局限。该模型的核心突破在于持续处理能力，允许 AI 在输出过程中实时感知输入信号并调整响应逻辑，而非在遭遇中断（如 「OK」或 「嗯」）时简单停顿或失效。

• 双向流式交互：BiDi 改变了固定响应生成机制，支持在语音输出期间动态修正预测路径，适用于复杂的服务场景（如客服场景中的中途需求变更）。
• 外部工具集成：据内部人士透露，该模型在外部工具与 API 调用的协同效率上优于现有模型，预示其将成为未来 AI 硬件（如智能音箱）的核心交互层。
• 技术瓶颈：目前原型机存在稳定性缺陷，长时对话（数分钟后）易触发异常音色或逻辑溃缩（Glitching）。
• 交付计划：原定于 2026 年 Q1 发布，受稳定性影响，预计推迟至 Q2 或更晚。

（@TheInformation;@investing.com)

02 有亮点的产品

1、苹果「HomePad」智能家居中枢推迟至 2026 年秋季发布

据原型机收集者「Kosutami」最新消息，苹果长期传闻中的智能家居中枢设备「HomePad」将推迟至 2026 年秋季推出，比预期时间更晚。

Kosutami 在 X 平台上发帖表示，该设备将于 9 月至 12 月的秋季期间问世，这通常是苹果一年中最繁忙的产品发布窗口。苹果已为此设备研发数年，旨在打造智能家居控制中心，用户可通过它统一管理家居产品、播放音乐和播客、进行视频通话，并查看天气、日历等即时信息。

设备预计配备 7 英寸方形显示屏和前置摄像头，可能推出两种版本：一款壁挂式，另一款带有类似 HomePod mini 扬声器底座的桌面款。内置传感器能检测附近人员，并根据身份调整显示内容。它将高度依赖 Siri 语音指令，Siri 在设备上可能呈现拟人化界面，如 Mac Finder 图标的变体设计。

苹果预计定价约 350 美元。该设备原计划 2025 年初发布，后因 Apple Intelligence 开发延误移至 2026 年初，如今进一步推至秋季，或与 iPhone 18 Pro 或全新 MacBook Pro 一同亮相。

（@极客公园）

2、VoiceLine 获 1000 万欧元 A 轮，用于扩展语音 AI 在欧洲企业一线应用

慕尼黑初创公司 VoiceLine 近日宣布完成 1000 万欧元 A 轮融资。本轮由 Alstin Capital 与 Peak 领投，Scalehouse Capital、Venture Stars 及 NAP 跟投。资金将主要用于扩展全球市场及深化针对移动端一线员工（Frontline Workers）的语音 AI 技术研发。

VoiceLine 旨在通过语音交互解决现场销售、服务及运营人员在移动场景下的数据录入延迟问题。

其主要技术有：

• 异步语音采集：取代传统的手动文本输入，支持现场语音实时抓取。
• 结构化处理引擎：利用 AI 自动将非结构化语音转化为标准访问报告、CRM 条目及待办任务。
• 企业级系统集成：原生对接主流 CRM（如 Salesforce， HubSpot）及 ERP 逻辑，确保数据实时同步至企业现有工作流。
• 多模态输出：系统根据预设规则，自动从单条语音记录中提取并分发至不同业务模块，降低信息衰减。

该方案旨在重塑一线业务的标准化文档沉淀，通过「语音即接口」的设计理念减少员工对移动端 UI 的高频依赖，从根源上消除因「事后补录」导致的数据滞后与信息黑盒问题。

目前，VoiceLine 已在制造、物流及服务业完成闭环落地，为分布式移动团队提供实时、高保真的数据反馈链路，将非结构化现场交互转化为具备可追溯性的企业数字资产，显著提升了管理端的全局可见性。

未来，voiceline 将以德国为中心向全欧洲及全球市场渗透，强化多语言环境下的企业级语音 AI 部署能力。同时开发更多适配现场业务的垂直用例（Use Cases），提升对复杂业务逻辑的识别精度。

( @thenextweb)

3、语音社交 App 森森（Gensen）MAU 突破 260 万：基于副语言信号与游戏行为实现 AI 人格建模

由暴雪与皮克斯资深开发人员创立的社交产品森森（Gensen），通过 3D 语音游戏场景捕捉用户的实时声音特征与交互行为，利用 AI 建模替代传统社交产品的静态图文匹配。目前该产品 MAU 已达 260 万，估值 1.5 亿美元，旨在解决 AI 时代生成内容带来的社交信息信任危机。

• 副语言信号（Paralinguistic signals）特征分析：系统通过 AI 提取语调起伏、语速节奏、停顿、笑声音频等非语言声学特征。这些信号因具有实时性且难以通过 AI 实时伪造，被作为识别用户性格与情绪状态的核心数据源。

• 游戏化行为数据标注：利用「海龟汤」、「森森酒馆」等 3D 语音场景，将社交匹配从「自我陈述」转向「行为观测」。系统通过观测用户在游戏逻辑推理、抗压表现及社交直觉中的本能反应，进行多维度的人格特征画像。
• 匿名化统计建模逻辑：系统在不涉及具体语音内容存储的前提下，对表达方式（声学特征）和语言模式（用词习惯、互动逻辑）进行统计建模。匹配逻辑基于用户真实的互动风格而非用户填写的问卷标签。
• 高增长与资本准入：产品曾位列 iOS 社交榜前 20，累计融资金额超 4500 万美元。目前已在上海与 Palo Alto 设立双总部，并获得 A16Z 及腾讯的投资意向。

国内版已上线运营；美国版 Gensen 正在进行上线准备；已完成 A 轮融资，累计融资约 3.1 亿元人民币。

（@量子位）

03 有态度的观点

1、雷军：AI 不会消灭工作，未来每天上班两小时就够了

近日，全国人大代表，小米集团创始人、董事长兼 CEO 雷军在接受采访时表示，在人工智能时代，或许很多规则将被重写，但同时又会产生很多新的岗位。

雷军建议，大家要用开放的心态，迎接更先进的时代。未来，也许不再需要每天工作 8 小时、每周工作 5 天了，或许一周仅需工作 3 天，每天工作 2 个小时。我们的生活质量、工作质量都会大幅度提升。

前不久， 小米机器人走进小米工厂开始拧螺丝了，雷军表示未来 5 年会有更多的人形机器人走进小米的工厂。

对此，雷军进一步阐述称：「我们已经进入人工智能的时代，这是毫无疑问的共识。」

（@极客公园）

04 社区黑板报

招聘、项目分享、求助……任何你想和社区分享的信息，请联系我们投稿。（加微信 creators2022，备注「社区黑板报」）

1、AveraLabs — 语音 AI 研究工程师 / Research Engineer， Voice AI

我们是一家来自美国旧金山的语音 AI 初创团队，正在打造下一代「全双工语音交互」系统，目标是让它通过图灵测试，创造像真人一样的自然对话。

创始团队

• YC 连续创业者，均来自 UC Berkeley / Rice University
• BCV Labs 贝恩资本孵化器创始成员
• 前 Cruise 自动驾驶模拟算法 lead
• Databento（Bloomberg 最大竞品）第一任 PM
• 曾主导 Pinterest 增长
• 获 Y Combinator、Rebel Fund、Afore Capital、UpHonest Capital 等顶尖机构投资

你会做什么

• 研究并实现低延迟全双工语音对话模型
• 设计语音 tokenizer、streaming encoder/decoder、duplex 状态机等核心模块
• 解决真实场景下的打断检测、情感建模、paralinguistic 特征保留等挑战
• 跟踪 Moshi / Freeze-Omni / MiMo-Audio 等前沿工作，快速内化并超越

我们在找什么人

• 顶校 CS/EE/信号处理硕博，或同等工业界经历
• 深度理解语音+LLM 交叉领域：audio codec、speech LM、multimodal training
• 有 ICASSP / Interspeech / NeurIPS / ICLR 等一作/核心贡献者经验优先
• 有过全双工、streaming audio tokenizer、低延迟系统落地经验者强烈优先

加分项

• 待过 Alibaba/Tencent/Xiaomi/字节/小红书/SOUL 语音团队
• 做过 neural audio codec（RVQ/VQ-VAE）、语音情感建模、低延迟 TTS
• 对"为什么当前语音 AI 还不像真人对话"有深入研究和独到见解

我们给什么

• 超 BAT 薪资水平 + equity（early stage，上车要趁早）
• 直接参与定义核心架构，不做螺丝钉
• 小团队，快速迭代，做完就上线

有兴趣 or 知道合适的人，微信/邮件联系：richardh\@averalabs.com

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考

一同探索 Voice Agent、Physical AI 等对话驱动的下一代人机交互界面。

3 月 19 日旧金山湾区见！Physical AI Meetup\&Workshop 邀你探讨全模态与端侧智能！

上午主题分享+圆桌，下午动手工作坊，无论你是产品人、开发者、创业者还是硬件极客，总有一款适合你！

围绕 Conversational AI、Visual Agent 与 Edge AI 等核心议题，我们邀请了来自基础芯片与大模型、前沿硬件初创、硬件投资机构，以及记忆数据与实时互动基础设施的先锋代表齐聚一堂。

参会嘉宾/机构：

MiniMax | Agora | 同歌创投| EverMind | HumanTouch | RiseLink | RTE 开发者社区丨TEN Framework

这场动脑又动手的 Physical AI 活动你绝对不容错过！

活动信息

地点：硅谷 Sunnyvale（具体地址报名审核通过后以短信通知）

日期：3 月 19 日（周四），9:30 AM - 12:30 PM；13:30 PM-17:00 PM（太平洋夏令时间 PDT）

上午主题分享+圆桌丨 Physical AI Meetup: Conversational AI， Visual Agent and Edge AI

09:30\~ 12:30

下午丨与硬件对话：TEN + Agora R1 套件语音 AI 工作坊

13:30\~ 17:00

💡 你可以只参加单场，也可全天参与——动手也动脑，快乐翻倍！

访问链接报名方式（注：上下午活动需分开报名）

上午场：https\://luma.com/8we6qyma

下午场：https\://luma.com/onc0xr9y

报名通过后，小助手将通过微信联系你，并告知详细地址与注意事项。

上午：Physical AI Meetup: Conversational AI， Visual Agent and Edge AI

📅 活动详情

• 时间： 3 月 19 日（周四），9:30 AM - 12:30 PM（太平洋夏令时间 PDT）
• 地点： 硅谷 Sunnyvale（具体地址报名审核通过后以短信通知）

⏳日程安排

• 9:30 - 10:00｜签到 & 自由交流
• 10:00 - 10:10｜开场

• 10:10 - 11:10｜ 主题演讲：对话真实世界

  • Morgan Suo, Senior GTM Manager\@MiniMax
  • Diana Zhu, Head of US Office\@RiseLink
  • 冯晓东，Physical AI 产品线负责人@Agora

• 11:10 - 11:40｜🔄圆桌讨论：从 Always on 到 Proactive AI，全模态 AI 硬件的机会

  • Kara 李欣航，执行董事@同歌创投
  • Troy Hua，VP\@EverMind，负责技术生态
  • William Gao, Founder\@HumanTouch
  • Moderator: Cynthia Yang, Initiator\@RTE Dev Community
• 11:40 - 11:55｜⚡Lightning Demo
• 11:55 - 12:30｜自由 Networking

👇 访问链接报名（含 Demo 申请通道）！ （审核通过后，我们将通过短信告知详细地址与参会指引。)

https\://luma.com/8we6qyma

注：上下午活动需分开报名

下午：与硬件对话：TEN + Agora R1 套件语音 AI 工作坊

GTC 期间，我们准备了这场特别的硬件工作坊！带你深入了解如何在开发板上接通语音 AI Agent 并进行动手实操。

📅 活动详情

• 时间： 3 月 19 日（周四），1:30 PM - 4:30 PM（太平洋夏令时间 PDT）
• 地点： 硅谷 Sunnyvale（具体地址报名审核通过后以短信通知）
• 人数：50～70 人 现场提供 40 套 R1 设备 👉 可以 单人成组 或 两人一组 👉 每组配有一套 R1 硬件 👉 成功跑通的队伍都可以把 R1 套件带回家！

🔍 活动亮点

🔹 TEN Framework 是专为构建 对话式语音 AI 设计的开源工具集，支持：

• 低延迟、多模态语音交互
• 兼容主流 STT /TTS / LLM / RTC
• 灵活接入不同模型与编排方案 👉 让你的语音 Agent 快速落地

🔹 Agora R1 是一款集成对话引擎的轻量级 AI 硬件套件

• 开箱即可操控语音交互
• 支持 APP 配网连接智能体实现语音交互功能
• 提供全面开发资料与二次开发支持

📌 在这里，你将亲手完成从硬件配置、编译、运行，到自定义语音 Agent 的完整动手链路。

🧠 你会得到什么

✔ 现场技术分享

✔ R1 设备实操上手

✔ 自定义语音 AI

✔ 团队合作与答疑支持

✔ 跑通就能把设备带回家！

欢迎对智能硬件、语音交互、Agent 产品有兴趣的朋友报名。

⏱ 活动流程

• 13:30–14:00 签到 & 自行组队
• 14:00-14:20 技术分享
• 14:20–16:30 现场实操（提供详细流程文档和技术答疑）

📌 准备建议（强烈推荐）

为了让现场体验流畅，请提前准备：

• 一台笔电
• GitHub 账号（用于运行 Codespace / 示例仓库）
• 终端工具与命令行基础（建议提前熟悉）

👇 访问链接报名 （审核通过后，我们将通过微信联系您告知地址与参会指引。)

https\://luma.com/onc0xr9y

注：上下午活动需分开报名

主办方：

RTE Dev Community 丨 TEN Framework

合作伙伴：

Agora | RiseLink | MiniMax | HumanTouch | EverMind | Resonance Ventures | AI Camp | Founder Park | Atlas Cloud

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么