IT之家 4 月 18 日消息， 在 Valve 推出 Proton 11.0-Beta1 兼容层后 ，网友 @ aagaming.me 在 Bluesky 平台发布动态，称成功在任天堂 Switch 游戏掌机上运行 Steam， 证明 Arm64 Linux 与 Proton 兼容层的技术可行性。 IT之家昨日报道，最新兼容层添加支持 NTSync 内核驱动外，还技术布局准备支持 Valve 的 Steam Frame 游戏头显，重点集成 FEX 2604 翻译层，动态将 x86 Windows 游戏指令转换为 ARM Linux 兼容指令。 根据网友演示，在任天堂初代 Switch 游戏掌机上，通过 Proton 预览版成功运行 Steam。不过由于初代 Switch 搭载 Tegra X1，该芯片发布于 2015 年，距今已超过 10 年，无法流畅运行游戏，消息源指出理论上其它 ARM 设备也能通过这种方式原生支持 Steam。
根据官方发布信息， Hermes Agent v0.10.0（标签 v2026.4.16）于 2026 年 4 月 16 日发布 ，这次版本更新的核心关键词只有一个： Tool Gateway。 这是一个足以改变日常使用体验的重要版本。对于已经订阅 Nous Portal 的用户来说，Hermes Agent 0.10.0 带来的不是单点增强，而是一次工具接入方式的明显升级： 无需再单独配置一堆第三方 API Key，就能直接获得多种工具能力。 这次更新最重要的变化 1. Tool Gateway 正式上线 Hermes Agent 0.10.0 的最大亮点，是 Nous Tool Gateway 的发布。 从这个版本开始， 付费 Nous Portal 订阅用户 可以直接通过现有订阅，使用 Hermes Agent 中的一系列工具能力，包括： Web Search Image Generation Text-to-Speech Browser Automation 也就是说，过去需要分别申请、配置、维护的多个外部服务 Key，现在被整合进了统一接入路径中。 对于使用者来说，这意味着更低的接入门槛、更少的配置成本，以及更顺滑的开箱体验。 为什么这次更新很重要 Hermes Agent 过去已经具备较强的模型与工具协同能力，但工具接入一直存在一个现实问题： 功能越强，配置越复杂。 而 0.10.0 的方向很明确—— 把“能用”变成“好用” 。 官方说明提到，在启用 Nous Portal 后，用户只需要运行： hermes model 然后选择 Nous Portal ，再决定启用哪些工具即可。 这意味着 Hermes Agent 正在把工具能力从“高级用户手动拼装”，推进到“订阅即可直接调用”的阶段。 0.10.0 带来的直接收益 更低的接入成本 不需要为搜索、图像生成、语音合成、浏览器自动化分别准备独立凭据，减少了大量初始化工作。 更统一的工具管理体验 新版本明确提到，它已经和以下命令完成集成： hermes tools hermes status 这意味着工具可用性、状态查看和配置路径更加统一，运维和排查也会更直接。 更合理的运行时优先级 官方说明特别指出： 即使系统中已经存在直接 API Key，运行时也会 优先正确选择 gateway 。 这类细节非常关键，因为它降低了多配置共存时的行为不确定性，避免“明明开了新能力却没走新链路”的问题。 配置方式更清晰 旧版隐藏环境变量 HERMES_ENABLE_NOUS_MANAGED_TOOLS 已被更清晰的订阅检测与配置方式替代。 同时支持通过 use_gateway 进行按工具启用，这让配置更透明，也更适合团队化使用。 不只是新功能，也是一轮稳定性增强 除了 Tool Gateway，本次版本还包含大量修复与可靠性改进。 官方发布说明中提到，0.10.0 包含 180+ 提交 ，修复和优化覆盖： agent core gateway CLI tool system 从变更方向来看，这不是一次单纯“上新功能”的版本，而是围绕 工具运行链路、平台兼容性与稳定性 做的一次集中增强。 对于已经在生产或高频使用 Hermes Agent 的团队来说，这类版本往往比单纯功能更新更有价值。 谁最适合尽快升级 如果你属于以下场景，建议优先升级到 0.10.0： 已经是 Nous Portal 付费用户 正在频繁使用 Hermes Agent 的工具能力 希望减少第三方 API Key 管理负担 希望统一搜索、生成、语音、浏览器自动化的调用入口 希望获得更稳定的 gateway / CLI / tool system 体验 升级后的重点关注项 建议升级后重点验证以下内容： hermes model 中 Nous Portal 的接入是否正常 工具启用与关闭是否符合 use_gateway 配置预期 hermes tools 与 hermes status 的状态展示是否一致 已配置的旧 API Key 是否被正确让位给 gateway 路径 浏览器自动化、搜索、图像生成、TTS 的实际调用链路是否符合预期 总结 Hermes Agent 0.10.0 的意义，不只是“多了几个工具”。 它真正带来的变化是： Hermes Agent 正在从“需要手工拼装的强大工具”，进化成“订阅即可完整启用的智能工作平台”。 如果说此前的重点是能力建设，那么 0.10.0 更像是一次 产品化体验升级 。 尤其对 Nous Portal 用户而言，这将显著降低工具使用门槛，并让 Hermes Agent 的日常工作流更加完整、统一、可靠。 参考来源 官方 Release： Hermes Agent v0.10.0 (2026.4.16) 官方 Changelog 对比： v2026.4.13…v2026.4.16 5 个帖子 - 3 位参与者 阅读完整话题
IT之家 4 月 15 日消息，AI 智能体正逐渐成为现代开发工作流中的标配，但现代网络却还停留在“面向人类”而非“面向 AI”的时代。 在这种情况下，无论是 VPN 组网还是 SSH 隧道都得手动配置 —— 这些工具对于自主运行的软件来说既不顺手也不安全。现在，Cloudflare 试图用 Mesh 填补这一空白。 当地时间 4 月 14 日，Cloudflare 宣布推出私有组网服务 Cloudflare Mesh，将 AI 智能体、人与多云端基础设施统一整合到一个安全网络内，为企业组织构建、部署和治理新一代 AI 应用提供网络基座。 在此之前：AI 智能体要想真正发挥作用，必须深度访问私有数据库、内部 API 和预发布环境，但用传统 VPN 或手动隧道来授权不仅慢，而且伴随较高风险。所以很多团队要么限制智能体访问导致功能受限，要么冒险把私有基础设施暴露在公网上。 Cloudflare 联合创始人兼 CEO 马修 · 普林斯表示：“AI 智能体已是现代开发工作流中的标配，但它们正被一个专为人类设计的网络模型拖累。多年来，开发者只有两个选择：要么花好几天折腾复杂笨重的 VPN，要么冒着危险把私有基础设施暴露在公网上。Cloudflare Mesh 则消除了这种取舍 —— 无论智能体运行在 Cloudflare 上、私有数据中心里还是其他公有云中，我们都能为智能体和基础设施之间提供安全桥梁，确保团队部署的每个智能体从一开始就是安全的。” Cloudflare 强调，Mesh 与很多人在用的 Cloudflare Tunnel 截然不同 —— 后者是单向将流量代理到特定服务，而 Mesh 提供的是多对多的全网互通，网络中任意节点均可通过私有 IP 直接相互访问。所有流量经由 Cloudflare 全球 330 多个城市的边缘网络路由，敏感数据全程加密且对外部威胁不可见。 在安全管控层面，Mesh 运行于 Cloudflare One 平台，现有的 Gateway 策略规则无需额外配置即可自动适用于所有 Mesh 流量。每账号免费提供 50 个节点和 50 个用户，所有 Cloudflare 账户均可使用。 另外，Mesh 还为 AI 智能体引入了身份层。在 Mesh 环境中，每个智能体都像人类员工一样拥有独立身份，安全团队可以编写精细的策略 —— 例如允许某个编码智能体或沙箱读取预发布数据库，但严格阻止其访问生产环境中的财务记录。典型应用场景包括：在手机上安全访问家中设备的本地服务而不暴露公网端口；让笔记本上的 AI 编码工具直接查询云端 VPC 中的预发布数据库；以及在 Cloudflare Workers 上部署的智能体通过 Workers VPC 绑定访问内部 API。 Cloudflare 还同步宣布与 Wiz（IT之家注：现为 Google Cloud 旗下）建立合作伙伴关系，提供跨企业环境的统一 AI 安全与可视化方案，帮助企业在多云和本地系统之间运行智能体工作负载时，不再需要拼接多个 VPN、身份和安全管理工具。 后续规划包括主机名路由（按服务名而非 IP 地址访问）、Mesh DNS（节点加入后自动获得内部域名）、身份感知路由（支持按智能体而非按用户制定访问策略）以及 Docker 容器支持。
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 开发动机： 不知道论坛里做嵌入式软件的佬友多不多，我干这行工作差不多已经三年了。 从AI刚开始流行时就一直在学习使用，这一年内也是看到AI工具的快速发展。 上一年一直在做STM32相关的工作，由于基础不行所以做着还是挺吃力的（前一两年主要做些应用层的事，再加上一些杂七杂八的工作），但是在AI的加持下还是磕磕碰碰的能完成任务。 之前对于AI在嵌入式开发中的使用主要是分析代码、生成代码，但是AI生成的代码通常不能一次性成功，需要下载到芯片多次调试反馈AI再调后才能使用。 有一段时间好好学习了一下ClaudeCode的各种概念，但好像有用的也就全局提示词，MCP、Skill 这些基本没有太合适嵌入式开发的，对Skill更是疑惑不解，感觉本质上就是一堆提示词 。 但是随着使用ClaudeCode、Codex的时间越长，慢慢发现，AI非常善于使用命令行，最近各大软件也纷纷推出自己的CLI工具。此时突然明白了Skill的一个重要的用法，就是将一些命令行工具的使用沉淀为Skill，让AI在合适的地方自己去调用这些工具，完成原本MCP的功能。 之前玩过Linux板子，倒腾过GDB+VSCode远程调试。那时还不明白，为啥GDB调试是命令行形式的而不用Keil这样的GUI？还很疑惑，真有人通过命令行去调试开发吗？感觉完全不可思议。现在才恍然大悟，这样的设计简直天才。 于是我就去调研，看看SMT32开发工具中，有没有这样的实现。结果是这些工具都有对应的命令行工具及实现。 所以，现在我们能将AI在嵌入式领域的开发中，编译、调试验证的最后一小步打通，形成闭环开发。（当然，还有很多涉及外部工具的工作无法完成，但我觉得这已经是一个很大很大的进步了） 项目介绍： 项目链接： github.com GitHub - zhinkgit/embeddedskills: An open-source collection of embedded development... An open-source collection of embedded development and debugging skills for Claude Code, Copilot, TRAE, 和 other AI coding assistants that support the Skill protocol. Once installed, the AI assistant can directly operate compilers, debuggers, 和 communication buses, automating the full workflow from code generation to hardware verification. 补充说明： 由于Python的生态非常好，有非常多的工具库可以调用，所以使用Python做为脚本语言。 现在单片机的开发在我了解主要分为几类，工程类别：1、keil 2、CMake。下载调试类别：1、jlink 2、openocd。再加上我经常用到的一些通信调试：串口、CAN、以太网。这些均已沉淀为Skill。 由于目前的工作中没有Linux相关的任务，所以没有开发Linux相关的Skill，但是原理都是一样的，可以自行开发或者提 Issue 和 PR。 同上，可能有些芯片的工程类别覆盖不全，包括ESP、IAR啥的，但原理都是一样的。 使用Codex验证了Skill的基本功能，还未大规模使用，欢迎大家提 Issue 和 PR。 感谢社区佬友的AI经验分享，欢迎做嵌入式开发的佬友交流心得，如果好用请给一个免费的小 哦。 1 个帖子 - 1 位参与者 阅读完整话题