助力企业构建内部私有化安全可控的 SkillHub。

过去一年，团队内部有过一段时间关于未来是低代码平台还是高代码框架的讨论：

• 低代码平台：典型代表 Dify，门槛低、流程确定性高，但灵活性受限。

• 高代码框架：核心是 ReAct结构，LLM+Prompt+Tool，由模型自主决策，特点是灵活度强、能充分利用 AI 泛化推理能力，但幻觉问题更突出，Prompt 调试成本很高。

不久之后，Anthropic 推出 Skill，成为这两者之间的关键平衡点：在保留灵活度的同时，通过能力封装与边界约束，提升 Agent 在特定任务上的确定性与可复用性，收到用户企业广泛应用，而年前 OpenClaw 快速出圈，ClawHub、SkillHub 等公开 Skill 市场的推出也如雨后春笋般，Skill 规模数万+，生态仍在高速扩张。

然而，繁荣的公开 Skill 市场背后，同时也暴露出各种安全隐患，根据 Snyk 对 ClawHub 中的 3984 个 Skill 的采样报告，存在安全缺陷的 Skill 占据 36.82%，CRITICAL 级别问题 13.4%，凭证 Secret 泄漏，Prompt 注入等问题也有较高比例，这些问题成为企业内落地 Agent 的重大挑战。

根据我们在和包括内部团队和外部企业的交流过程中，各方对 Skill 在企业内部落地普遍关注的几个方面进行了梳理，主要面临以下挑战：

• 安全挑战：恶意代码、已知漏洞、敏感信息外泄风险持续存在，缺乏有效的准入管控机制。

• 权限挑战：谁可见、谁可用、谁可改、谁可发——职责边界模糊，越权访问难以防范。

• 稳定性挑战：版本混乱、升级不可控、问题难以回滚，影响业务连续性。

• 治理挑战：缺少审计日志、追溯链条不完整、缺乏合规证据链，无法通过监管审查。

这四类问题相互耦合，不能依靠单点能力解决，必须通过平台化治理体系统筹应对。

Nacos 3.2 推出的私有化 Skill Registry，面向企业生产场景，在 Agent 与 Skill 之间构建「验证后信任」的治理层，将 Skill 的审核、管理、分发与追溯统一纳管，形成完整的企业级 AI 资源控制闭环。

MacOS/Linux：

curl -fsSL https://nacos.io/nacos-installer.sh |  bash

Windows(PowelShell)：

iwr -UseBasicParsing https://nacos.io/nacos-installer.ps1 | iex

脚本运行后会自动打开 Nacos 控制台：

终端执行 nacos-setup --help 及 nacos-cli --help 查看更多功能。

Nacos 3.2 内置开箱即用的安全审核插件，覆盖 10+ 项常用风险扫描，同时提供标准接口支持插件化扩展，满足企业定制化安全策略需求。

审核流程遵循「未通过，不发布」的准入原则，将安全要求从「文档规范」升级为「系统强约束」，彻底消除人为绕过风险。Skill 入库前必须经过可编排、可审计、可升级的审核流程，实现多维扫描、风险分级、审核决策的全流程管控。

• 版本生命周期管理：支持草稿（DRAFT）、审核中、灰度（GRAY）、正式（FORMAL）、下线等完整生命周期，每个阶段状态明确，版本不可变。

• 标签灰度放量：通过 dev/lastest/stable 等标签绑定版本，精准控制分发范围，支持逐步放量，降低新版本上线风险。

• 异常快速回滚：灰度阶段发现问题，切换标签映射即可实现秒级回滚，无需重新发版，保障业务稳定性。

Nacos 3.2 采用三层边界设计，实现细粒度的权限管控：

• RBAC 角色权限：定义发布者、审核员、只读用户等角色，明确职责边界。

• 命名空间隔离：隔离不同团队、环境与租户，防止越权访问。

• Skill 维度可见性：支持单 Skill 级别的公开、私有、指定范围开放配置，谁能看、谁能用、谁能改、谁能发，都有明确策略与责任归属。

Nacos 3.2 提供完整的审计能力，覆盖 Skill 全生命周期：

• 上传记录：谁在何时上传了哪个版本，来源可追溯。

• 审核日志：谁审核、审核结论、审核时间全程留存。

• 发布记录：谁发布、发布到哪些 Agent、发布策略存档。

• 调用追溯：哪些 Agent 调用了哪个版本，问题定位有据可查。

只有审计闭环打通，运维、合规、治理才能真正形成体系，满足监管要求。

Nacos 3.2 提供多种灵活的 Skill 接入方式，满足不同场景下的获取和安装需求：

• Agent 自主发现：Nacos 提供引导 Skill，Agent 可通过以下命令自动发现可用能力：

curl -s https://download.nacos.io/SKILL.md

执行后将展示 Skill 安装指南及列表查询方法，帮助 Agent 快速定位和获取所需能力。

• CLI 一键安装：通过 nacos-cli 工具实现 Skill 的快速下载与安装，支持从 Registry 直接拉取并本地部署。

# 列出所有可用 Skills
nacos-cli skill-list
# 按名称过滤查询
nacos-cli skill-list --name mysql-query --page 1 --size 20
# 下载指定 Skill 到本地
nacos-cli skill-get mysql-query -o ~/.skills

详细指令参考 Nacos CLI 文档^[1]。

• Shell 脚本批量拉取：支持通过 skills.sh 脚本链接 Nacos Registry 批量获取 Skills，适用于自动化部署和 CI/CD 场景。

# 配置 Nacos Registry 地址
export SKILLS_API_URL=http://${nacos.host}:9080
# 使用 npx 执行 skill 命令安装
npx skills add mysql-query redis-query

相关实现详见 GitHub Issue #14770^[2]。

Nacos 3.2 作为底层基础设施，与 HiClaw（Agent 执行层）、HiMarket（私有化市场层）形成完整的企业私有 AI 管理平台生态：

• HiClaw：Agent 运行时，消费 Skill、Prompt、AgentSpec 资源。

• HiMarket：基于 Nacos 定制的私有化 Skill 市场 + Worker 市场。

• Nacos：统一 AI 资源管理（Prompt,Skill,MCP,AgentCard）、治理与插件化扩展。

去年 9 月份，我们畅想配置驱动的 Agent 网络架构：《配置驱动的动态 Agent 架构网络：实现高效编排、动态更新与智能治理》，此刻，我们 Nacos+Himarket+HiClaw 将此架构畅想变为了现实。

Nacos 3.2 是一个起点，完成了全面拥抱 AI 时代的第一步。

我们期望未来 Nacos 成为企业 AI 时代的资源治理基础设施一部分，成为多 Agent 架构网络的协作中枢。

统一资源控制平面

整合四大注册中心，统一身份、权限、版本与分发策略，形成企业级一致入口。

治理能力持续深化

增强审核、灰度、审计与回滚能力，让每次资源变更可验证、可追溯、可止损。

场景化智能推荐

基于场景做 AI 资源推荐，支持 AgentSpec 自动化组装，降低 Agent 构建门槛。

多 Agent 协作中枢

在 AgentSpec 之上构建 Agent Team Spec，形成 基础 AI 资源+单 Agent 组装编排+多 Agent 协作网络构建，基于 OT 协议集成 Agent 运行时数据，升级 Nacos Copilot 实现智能数据分析，实现多 Agent 协作安全可控地自我进化。

Nacos 为了实现上述目标，基于社区反馈与路线图规划，AI Registry 将在后续版本中持续演进：

• AI 资源生命周期管理：引入活跃度检测机制，实现热数据启动加载、冷数据按需延迟加载及自动下线，优化资源占用。

• 数据智能层：基于 OT 协议集成 Tracing 数据，构建无本地存储的 Copilot 智能分析能力，实现 AI 资源运行态可观测。

• 全链路审计追溯：补齐 AI 资源操作的完整审计日志与全链路追溯能力，满足企业合规要求。

• 语义智能检索：基于向量数据库与大模型实现自然语言搜索、AgentSpec 自动化组装与智能路由。

• 多协议适配与开放生态：除适配 A2A Protocol 1.0.0 版本外，还将探索 ACP、Matrix 等主流 Agent 通信协议的对接，支持 AgentCard 字段规范演进与跨平台 Agent 互操作，构建开放的 Agent 协作生态。

• Coding Agent 插件：分阶段演进 Coding Agent 能力，从 Markdown 指令到 MCP 协议支持，最终提供原生远程 MCP 端点，实现在 Claude Code、Cursor 等工具中直接操作 Nacos 资源。

相关 Issue：#14801#14792#14790#14789#14621#14603

Nacos 过去 8 年中成为微服务时代的基础设施之一，收到开源社区的开发者广泛地支持，希望 Nacos 在 AI 时代也同样和大家结伴同行共同成长，欢迎扫描以下二维码联系到我们。

钉钉群 👇

微信群 👇

如微信群已满，请添加 zjjxg2018 进群。

Snyk：https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/

Cisco：https://blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare

相关链接：

[1] Nacos CLI 文档

https://nacos.io/docs/latest/manual/admin/nacos-cli/

[2] GitHub Issue #14770

https://github.com/alibaba/nacos/issues/14770

[3] Nacos Github

https://github.com/alibaba/nacos

[4] Nacos Cli

https://github.com/nacos-group/nacos-cli

[5] Nacos Installer&Setup

https://github.com/nacos-group/nacos-setup

阅读原文

跳转微信打开

从 ClawHub 争议看社区 Skill 仓库的局限，解读 Nacos 企业级 Skill Registry 方案。

OpenClaw 官方提供了 ClawHub，提供了全球最全、最优质的 Claw Skills。但由于存在 Rate limit exceeded 的安装难题，在国内通过构建镜像站来解决，是一个技术上可行的方案。但是也面临着争议。

ClawHub 频繁出现 Rate limit exceeded，国内用户安装 Skill 时体验极差。这不是 ClawHub 不努力，而是一个由个人开发者运营的社区平台，天然难以承受全球级别的流量冲击。OpenClaw 在两周内从零飙升到 17 万星标，ClawHub 的基础设施没能跟上这个速度。

镜像站解决了中国用户的可用性问题，但也引出了新的矛盾——高频抓取导致服务器成本飙升至每月五位数美元。OpenClaw 采用 MIT 协议，镜像在法律上完全合规，但生态的可持续性问题浮出水面：在传统包管理生态中，npm mirror、PyPI 镜像都有成熟的协作惯例，AI Skill 领域还没有建立起这套规范。

对企业来说，这意味着一个根本性风险：你的 Agent 所依赖的 Skill 源，可能因为上游的一次限流、一场纠纷或一次宕机而不可用。

可用性之外，安全问题更加严峻。2025 年 12 月末，恶意 Skill 就已经开始出现在 ClawHub 上，而当时 OpenClaw 正处于爆发式增长期，ClawHub 尚未建立自动化安全扫描机制。

2026 年 1 月 24 日，安全公司 Koi Security 披露了ClawHavoc 事件：在审计的 2,857 个 Skill 中，341 个（约 11.9%）含有恶意代码，伪装成加密货币交易工具，实际窃取用户的 API Key、钱包私钥、SSH 凭证和浏览器密码。攻击者甚至利用了 OpenClaw 的持久记忆机制，通过修改 SOUL.md 和 MEMORY.md 文件来永久篡改 Agent 行为。

事件发生后，各方快速响应——OpenClaw 与 VirusTotal 合作建立了自动化扫描，任命了专职安全负责人并发布了威胁模型；腾讯 SkillHub 也联合朱雀安全实验室推出了 EdgeOne ClawScan 安全体检工具。这些都是积极的补救措施。

但教训已经很清楚：生态增长跑在了安全建设前面，攻击者比防御者先到。对于企业来说，这个时间差是不可承受的。

当同一个 Skill 同时存在于 ClawHub 和 镜像站上时，哪个版本是最新的？如果 ClawHub 下架了一个有安全问题的 Skill，镜像站多久能同步下架？如果 ClawHub 发布了安全补丁，镜像站的用户什么时候能拿到更新？

镜像站通过高频抓取来保持和 ClawHub 的一致性，但这种“非正式同步”缺乏版本溯源保障。企业无法确认自己使用的 Skill 版本来自哪里、经过了什么修改、是否包含上游的最新安全修复。

ClawHub 目前的发布门槛是“一个注册满一周的 GitHub 账号”。这是社区生态繁荣的基础——低门槛才能吸引大量开发者贡献 Skill。但 ClawHavoc 事件已经证明，低门槛也意味着恶意 Skill 更容易混入。对于企业生产环境，这样的准入标准远远不够。

综合来看，不稳定、不安全、不可溯源、不可控——这四个问题不是某个平台的失误，而是社区 Skill 仓库在快速增长期的结构性局限。社区平台的核心使命是降低门槛、促进共享，这和企业对稳定性、安全性、可追溯性、可管控性的要求之间，存在天然的张力。

那么，企业级的 Skill 治理应该怎么做？

这场争议是一个好的反思契机。站在企业开发者的视角，一套可靠的 AI Skill 管理体系至少需要做到以下几点：

从社区发现了好用的 Skill？可以引入。但引入之后，它应该进入企业自己的注册中心，由自己管理——和外部平台彻底解耦。ClawHavoc 的安全风暴，都不应该影响到你的生产环境。

另外，企业最有价值的 Skill 往往不是从社区拿来的，而是自己写的。内部业务流程、私有 API 对接、行业专有知识——这些 Skill 包含了企业的核心 Know-how 和业务流程，天然不适合放到任何公共平台上。它们需要一个私有的、可管控的内部 Registry 来承载。

ClawHavoc 之后，ClawHub 在安全上做了大量投入。但这些毕竟是事后补救。对企业来说，教训很明确：不能把安全完全寄托于外部平台的进化速度。

在自己的 Registry 层面建立独立的安全能力——不管 Skill 来自哪个平台，进入内部之前都必须经过自主可控的安全检查：Prompt 注入检测、敏感信息识别、权限越界扫描。这不是对社区平台的不信任，而是纵深防御的基本原则。

当同一个 Skill 在 ClawHub 和其他镜像站上同时存在时，版本溯源变得极其困难。但在企业内部，这个问题必须有确定的答案：当前生产环境跑的是哪个版本？谁审批的上线？上一个版本是什么？需要回滚时能不能秒级切换？

ClawHub 目前的发布门槛是“一个注册满一周的 GitHub 账号”。这对开放社区来说是合理的低门槛，但对企业生产环境来说远远不够。一个 Skill 能不能上生产、谁来批准、内容有没有风险——必须有流程来保障。

Nacos 在 3.2.x 版本中推出了 Skill Registry 能力: 一个企业自主可控的 AI Skill 注册中心。如果说 ClawHub 是社区的 Skill npm，那 Nacos Skill Registry 就是企业私有的 Skill npm。

1. 注册与发现

Skill 支持 JSON 和 Zip 包两种方式注册，Zip 包内包含 SKILL.md 和资源文件——和 ClawHub 的 Skill 格式兼容，社区 Skill 可以零改造引入。注册后支持模糊搜索和精确搜索，方便团队内部发现和复用已有 Skill。Nacos 控制台提供了可视化的 Skill 管理界面，创建、编辑、查看详情都可以在 Web UI 上完成，不需要只靠命令行。

2. 审核流程

Skill 发布不再是“提交即上线”。3.2.0 将引入审核工作流，支持多级审批：

• 开发者提交 Skill → 审核人审批 → 发布到指定环境；

• 测试环境可配置为直接发布，生产环境强制审批；

• 完整的审批记录留存，满足企业审计合规要求。

前文提到 ClawHub 的发布门槛只需“一个注册满一周的 GitHub 账号”，而 Nacos 的审核流程确保每一个进入生产环境的 Skill 都经过了明确的授权。

3. 版本管理与灰度发布

每个 Skill 的每一次变更都有完整的版本记录。配合 Skii Registry 的标签机制（stable / canary / gray），可以实现灰度发布和秒级回滚。一个典型的使用场景：

1. 开发者发布 Skill v1.1.0，标签绑定为 canary；

2. 灰度环境的 Agent 自动拉取 canary 版本，验证效果；

3. 验证通过后，将 stable 标签从 v1.0.0 切换到 v1.1.0；

4. 生产环境所有 Agent 实时感知变更，自动加载新版本；

5. 出了问题？把 stable 切回 v1.0.0，秒级回滚，业务无感。

前文提到的“每一次变更都留痕”，在这里有了完整的工程化落地。

4. 命名空间隔离

不同团队、不同项目、不同环境的 Skill 通过命名空间天然隔离。开发团队在 dev 空间里随便折腾，不会影响 production 空间里正在运行的 Agent。企业自研的私有 Skill 和从社区引入的公共 Skill，也可以分开管理、各司其职。

5. 实时推送与动态加载

这是 Nacos 相比其他 Registry 方案最独特的优势。Nacos 本身就是经过大规模验证的配置中心，配置推送能力在 Skill 管理场景下开箱即用——Skill 或 Prompt 在 Registry 中更新后，所有订阅的 Agent 实时收到变更通知，动态加载新内容，无需重启应用。在传统方案中，更新一个 Skill 可能要重新部署 Agent；在 Nacos 中，改完即时生效。

6. AI Copilot 辅助能力

Nacos 还内置了 AI Copilot，辅助 Skill 和 Prompt 的开发：

• Skill 智能优化：对已有 Skill 的指令进行分析和改进建议；

• Skill 自动生成：根据业务场景描述自动生成 Skill 草稿；

• Prompt 优化与调试：流式输出优化建议，帮助开发者快速迭代 Prompt 模板。

光有 Registry 还不够，开发者需要趁手的工具。社区开源了 nacos-cli（https://github.com/nacos-group/nacos-cli）——专门为 Skill 管理设计的命令行工具。

安装

# Linux / macOS：一行命令安装
curl -fsSL https://nacos.io/nacos-installer.sh | sudo bash -s -- --cli
# 或者通过 npm
npm install -g @nacos-group/cli
# 不想装？npx 直接用
npx @nacos-group/cli --help

日常使用

# 列出所有 Skill
nacos-cli skill-list -s 127.0.0.1:8848
# 下载 Skill 到本地
nacos-cli skill-get my-skill -o ~/.skills
# 上传本地 Skill 到 Registry
nacos-cli skill-upload /path/to/skill
# 批量上传一个目录下的所有 Skill
nacos-cli skill-upload --all /path/to/skills
# 实时同步：Registry 中的 Skill 变更时自动同步到本地
nacos-cli skill-sync --all

如果你用过 clawhub install、clawhub search，那 nacos-cli 的体验是类似的——区别在于，你的 Skill 源从公共社区变成了企业自己的 Nacos 集群。nacos-cli 还提供交互式终端模式，支持自动补全，适合日常管理和调试。

在实际的 AI 应用中，Skill 不是孤立存在的——它需要和 Prompt 模板、MCP 工具链、Agent 协作协议配合使用。因此 Nacos AI Registry 在 Skill 之外，还覆盖了完整的 AI 资产管理：

所有这些都运行在企业自己的基础设施上，数据不出私有网络，不存在“被镜像”或“被抓取”的问题。

每一项能力，都直接回应着这次生态事件中暴露的具体问题。

ClawHub 作为 OpenClaw 的官方 Skill 注册中心，承担着技能发现、社区共享和生态繁荣的核心角色。

但企业把 Skill 从社区引入生产之后——或者更常见的，企业自己开发了大量内部 Skill 之后——就需要一套不同的体系来管理。ClawHavoc 事件告诉我们生态的安全建设可能滞后于增长速度，这些外部的不确定性，不应该传导到你的生产环境。

社区是发现的地方，Registry 是治理的地方。两者配合，才是 AI Skill 管理的完整图景。

Nacos Skill Registry 及完整 AI Registry 已在 3.2.0-BETA 版本中可用，3.2.0 正式版即将发布。

• Nacos GitHub：https://github.com/alibaba/nacos

• nacos-cli GitHub：https://github.com/nacos-group/nacos-cli

• 官方文档：https://nacos.io

阅读原文

跳转微信打开

Nacos 3.2：迈向 AI 注册中心的里程碑版本。

作者：柳遵飞(翼严)，杨翊(席翁)，朱桐(濯光)，陈欣渝(恰橙)，刘鹏(墨松)

OpenClaw 的 ClawHub 市场已有 1w+ Skills，每天还在疯涨——听起来很美，直到大量恶意 Skills 被扒了出来。有个“邮件清理”Skill，装上第一次运行就把你的 .env、SSH 密钥打包发出去了。ClawHub 下载的是裸 zip 包，没签名、没校验、没沙箱，Skill 一加载就继承了 Agent 的全部权限——能读你的文件，能 rm -rf，为所欲为。这就好比你雇了个实习生，没做背调，第一天就给了 root 权限。

所以也就有了“ClawHub 一半是毒药”的说法，企业要用 OpenClaw 或其他 Agent，必须要解决好安全问题，Skills 安全就是 OpenClaw 企业落地一个核心问题。 私有化 Skills Registry 要做的，就是在 Agent 和 Skill 之间加一道安检门——发布前扫描、签名验证、沙箱隔离、权限最小化，让每个 Skill 从“我信你”变成“我验过你”。

Nacos 3.2版本发布了 Skills Registry，解决这个问题应运而生。

2025 年初，Nacos 确定了全面拥抱 AI 的发展路线，并在此方向上持续投入。去年已率先上线 MCP Registry 与 Agent Registry，为 AI 资源的注册与治理迈出了第一步。

Nacos 3.2 是 Nacos 迈向 AI 时代的一个里程碑式版本（当前为 Beta 版本），本版本主要更新包括：

AI Registry：在 MCP、Agent 基础上补齐 Prompt Registry 与 Skill Registry，四类资源在控制台统一入口，支持注册、检索、版本管理与命名空间隔离。

• Nacos Copilot：基于 Agentscope-Java 将大模型能力集成进控制台，为 Prompt、Skill 提供结构化优化建议，支持在控制台内完成「编辑—优化—发布」全流程。

• nacos-cli：官方命令行工具，支持配置与 Skill 的查询、发布、上传、同步等操作，便于脚本化、CI/CD 与 Agent 工作流对接。

• nacos-setup：一键安装与部署工具，支持 macOS、Linux、Windows，单机与集群模式均可，降低本地体验与运维门槛。

• AI 生态集成：支持对接 openclaw/hiclaw/copaw，cursor/qoder，agentscope-java 框架实现 Skill 集成。

Skill 本质是 Agent 可调用的能力包（检索、调 API、执行脚本等）。GitHub 等平台已支持 Skill 的开放共享，而企业内往往需要私有化、可管控的 Skill 注册中心。Skill Registry 聚焦私有化 Skill 注册与治理：在实现 Skill 的团队共享与分发基础上，提供企业级能力，包括命名空间与数据隔离、权限管理、数据安全等，与配置、服务一样在控制台完成全生命周期管理。

在 AI Registry 的 Skill 页面中可以完成：

• Skill 的注册、更新、查看与删除，覆盖基础生命周期。

• 按名称检索与分页浏览，便于在 Skill 数量较多时快速定位。

• 支持 ZIP 上传及下载，方便用标准包批量导入导出。

• 支持按命名空间隔离，多环境、多团队互不干扰。

Skill 与配置、服务一样，具备可查、可追溯、可协作的治理能力。

OpenClaw 作为新一代开源个人 AI 助手，近期因将 AI 从“对话者”进化为“执行者”而备受瞩目。它可以运行于用户本地设备，主打隐私安全与长期记忆，能直接操作电脑、管理日程及自动化处理复杂任务。其核心魅力在于模块化的 Skills（技能）架构，允许开发者无限扩展其能力边界，通过自定义技能轻松连接各类应用与服务。

为了让 OpenClaw 具备从 Nacos 搜索、安装和发布 Skill 的能力，并方便团队内部共享自定义技能，我们开发了 nacos-skill-registry 技能。

前提条件：已经根据 https://openclaw.ai/ 部署好 OpenClaw。

以下是使用指南：

Linux / macOS：

curl -fsSL https://nacos.io/nacos-installer.sh | sudo bash

Windows（PowerShell）：

     iwr -UseBasicParsing https://nacos.io/nacos-installer.ps1 | iex

运行以下命令，将插件脚本下载至 OpenClaw 的技能目录，安装该技能后，OpenClaw 将会获取如何管理 Nacos 中的 Skill：

curl -s https://download.nacos.io/SKILL.md -o ~/.openclaw/skills/nacos-skill-registry/SKILL.md --create-dirs

安装后 OpenClaw 会自动加载，首次使用时会引导你安装 nacos-cli 并配置 Nacos 连接信息。

在 OpenClaw 中直接用自然语言即可，例如：

• “Nacos 上有哪些可用的 Skill？”

• “帮我找一个处理 PDF 的 Skill”

• “把 data-analysis Skill 装好，我马上要用它分析报表。”

• “把这个新开发的 Skill 上传到团队的 Nacos 仓库。”

企业内的 AI 资源已由单一模型与接口扩展为多类资产：MCP（Model Context Protocol）提供标准化上下文与工具接入，Agent 承载任务与工作流，Prompt定义指令与行为边界，Skill 封装可复用能力。资源一多，便容易分散在不同系统与团队中，维护归属、检索路径与版本信息难以统一，协作与治理成本随之上升。

Nacos 自 2025 年起将 AI 资源的注册与治理纳入产品方向，先后上线 MCP Registry 与 Agent Registry。本版本在此基础上补齐Prompt Registry 与 Skill Registry，并在控制台统一为 AI Registry：注册、检索、版本管理及权限与命名空间与现有 Nacos 能力一致，跨团队复用与多环境隔离均在控制台完成。

Prompt 是驱动 Agent 行为与输出的核心输入，其质量与一致性直接影响 Agent 的稳定性与可运维性；若仅依赖分散在文档或代码中的片段，难以实现团队共享、多环境一致与变更可追溯。Prompt Registry 将 Prompt 纳入平台统一管理：按 Key 建模板、支持变量占位、版本与历史可查，与 Nacos 配置管理的思路一致，仅管理对象由配置项扩展为 Prompt。

本版本中 Prompt Registry 提供完整的生命周期管理：

• 支持按 Prompt Key 创建模板，并通过 {{variable}} 变量占位提升复用性。

• 发布新版本时可带版本号、描述、提交说明，方便团队协作与变更追溯。

• 支持按 Key 搜索、分页查看，以及按命名空间隔离，适合多环境并行管理。

• 支持历史查看与版本迭代，避免线上实际生效版本难以追溯的问题。

AI 能力正从独立工具形态向产品内置能力演进。Nacos 在 3.2 中将大模型接进控制台，推出 Nacos Copilot：基于 agentscope-java 接入大模型，在控制台内即可对 Prompt、Skill 做优化，无需在外部工具与平台之间来回切换。

• Prompt 优化：在控制台对 Prompt 进行结构化优化，提升清晰度与可执行性，遵循变量格式与保守优化原则，避免偏离预期语义。

• Skill 优化：针对 Skill 的描述、指令与结构给出改进建议，支持流式输出，便于实时查看与调整。

在 Nacos 内即可完成“编辑—优化—发布”全流程，无需切出控制台。

后续将延伸至配置管理、服务管理等场景，使 AI 能力从零散使用走向系统化应用。

试用 Nacos 或在本机搭建环境时，常需面对安装包选择、配置修改、端口冲突、Java 版本等环节。

nacos-setup是官方的一键安装与部署工具，一条命令完成下载、安装与启动，支持 macOS、Linux、Windows，单机与集群都支持。旨在降低本地体验与运维门槛：数分钟内即可在本机完成 Nacos 的安装与启动，并可使用 AI Registry、配置中心与服务发现等能力。

如何使用：先通过官方安装脚本安装 nacos-setup。

 curl -fsSL https://nacos.io/nacos-installer.sh | sudo bash

使用 PowerShell 执行。

iwr -UseBasicParsing https://nacos.io/nacos-installer.ps1 | iex

nacos-setup 安装成功后，就可以通过 nacos-setup 命令在本地快速部署启动一个 Nacos。

单机模式与集群模式：

• 单机模式：适合本地开发、联调或演示，一条命令即可在本机启动一个 Nacos 实例。例如执行 nacos-setup -v 3.2.0-BETA 安装并启动 3.2 版本；可通过 -p指定端口、-d 指定安装目录，使用 --detach 后台运行。

• 集群模式：适合在本地模拟生产环境或多节点高可用验证。通过 -c 指定集群 ID、-n 指定节点数量，例如 nacos-setup -c prod -n 3 -v 3.2.0-BETA 可创建 3 节点集群；支持 --join 加入已有集群、--leave 移除节点、--clean 清理后重建。通过 --join、--leave配合不同 -v 版本号，可以在集群中逐个节点切换版本，模拟滚动升级、重启等操作，快速验证版本升级的兼容性等问题。更多参数见 nacos-setup 使用说明。

Agent 与自动化流水线更依赖“执行命令、解析输出”的交互方式，而非在控制台中逐项操作。nacos-cli 将配置、Skill、Prompt 等能力以命令行方式暴露：支持通过单条命令完成配置查询、Skill 上传、Prompt 拉取等操作，便于脚本与 CI/CD 复用，Agent 也可通过执行命令与 Nacos 交互，无需依赖控制台或特定语言 SDK，接入方式统一，利于自动化集成。

如何使用：nacos-cli 可以通过一下这两种方式集成：

1. 通过官方安装脚本单独安装 nacos-cli，安装后在终端配置 Nacos 地址即可使用。

Linux / macOS：

curl -fsSL https://nacos.io/nacos-installer.sh | sudo bash -s -- --cli

Windows（PowerShell）：

iwr -UseBasicParsing https://nacos.io/nacos-installer.ps1 -OutFile $env:TEMP\nacos-installer.ps1; & $env:TEMP\nacos-installer.ps1 -cli; Remove-Item $env:TEMP\nacos-installer.ps1

2. 如果你有 Node.js 环境，也可以通过 npm ：

npm 全局安装

npm install -g @nacos-group/cli
nacos-cli --help

npx 免安装直接使用

npx @nacos-group/cli --help

Skill 上传、下载、同步等操作示例见下文「快速开始」。更多用法见 nacos-cli（https://github.com/nacos-group/nacos-cli）。

当前能力：

• 配置中心：支持配置的列表（config-list）、查询（config-get）、发布（config-set）等基础操作。

• Skill Registry：支持 Skill 的列表、拉取、上传、同步等（如 skill-list、skill-get、skill-upload、skill-sync），支持配置文件和交互模式，便于脚本化与流水线集成。

以下通过「本地一键安装 → 控制台管理 Prompt/Skill、开启 Copilot → nacos-cli 操作 Skill」进行最小化演示，便于快速体验 3.2 版本的 AI Registry 能力。

通过官方一键安装脚本安装 Nacos，支持单机与集群。

Linux / macOS：

curl -fsSL https://nacos.io/nacos-installer.sh | sudo bash

Windows（PowerShell）：

     iwr -UseBasicParsing https://nacos.io/nacos-installer.ps1 | iex

执行 sudo nacos-setup -v 3.2-BETA 即可安装并启动 Nacos 3.2 的 Beta 版本。

启动成功后浏览器将打开登录页，默认用户名为nacos，密码会自动生成并复制至剪贴板，输入用户名 nacos 并粘贴密码登录后，即可在控制台看到 AI Registry入口。

Nacos Copilot 借助大模型能力为 Prompt、Skill 提供优化建议，因此需配置访问大模型的 LLM 访问凭证（如 API Key）。

配置方式任选其一即可：

• 方式一：在控制台设置（Setting）中手动填入 API Key 并保存；

• 方式二：在 Nacos 所在环境配置环境变量 COPILOT_API_KEY，然后重启 Nacos 使配置生效。

说明：当前 Beta 版本暂时仅对接阿里千问系列模型，后续将支持更多大模型厂商。

登录控制台后，在左侧菜单进入 AI Registry，可分别体验 Prompt Registry 与 Skill Registry：

• Prompt Registry：在「Prompt」页签中可创建 Prompt（按 Key 建模板、使用 {{variable}} 变量占位）、编辑内容、发布新版本并填写版本说明，支持按 Key 搜索、分页查看与命名空间隔离；在历史版本中可查看迭代记录与回溯。

• Skill Registry：在「Skill」页签中可注册或上传 Skill（支持 ZIP 包）、按名称检索与分页浏览、下载到本地；支持按命名空间隔离，便于多环境、多团队管理。创建、更新、删除等操作均在控制台完成，与配置、服务保持一致的治理体验。

若已启用 Nacos Copilot（见上文「启用 Nacos Copilot」），还可在 Prompt、Skill 的编辑页中体验 Prompt 优化与 Skill 优化功能：对当前内容发起优化后，由大模型给出结构化改进建议，支持流式输出，便于在控制台内完成「编辑—优化—发布」全流程。

通过 nacos-setup 启动的 Nacos 启用了鉴权，使用 nacos-cli 连接时需要指定密码。在命令中通过 -p 指定密码即可连接，示例：nacos-cli -p <密码> ,密码可在 第一步中的终端中获取。

连接成功后，可通过以下命令进行 Skill 的基础管理：

• skill-list：查看 Nacos 上的 Skill 列表；

• skill-get：按名称拉取单个 Skill；

• skill-upload：将本地目录中的 Skill 上传至 Nacos；

• skill-sync：将 Nacos 上指定的 Skill 从服务端同步至本地目录，便于在 AI 工具中直接使用。

配置的查询、发布等可通过 config-list、config-get、config-set 等命令完成。更多命令与参数见 nacos-cli 使用说明。

说明：除 -p 指定密码外，还可通过 -h 指定服务地址、--port 指定端口、--conf 指定配置文件路径等，配置文件内可填写服务地址、端口、用户名、密码、命名空间等，适用于需固定连接信息的场景。

当前主流 AI coding CLI（Qoder、Cursor、Claude Code、Gemini CLI 等）都支持 Skill 机制，可以通过安装 Skill 来扩展 AI 的能力。

nacos-skill-registry可以让你的 AI coding CLI 具备从 Nacos 搜索、安装和发布 Skill 的能力，方便团队共享 Skill。

安装

curl -s https://download.nacos.io/SKILL.md -o ~/.skills/nacos-skill-registry/SKILL.md --create-dirs

安装后 AI coding CLI 会自动加载，首次使用时会引导你安装 nacos-cli 并配置 Nacos 连接信息。

使用

在 AI coding CLI 中直接用自然语言即可，例如：

• “Nacos 上有哪些可用的 Skill？”

• “帮我找一个代码审查相关的 Skill”

• “安装 code-review 这个 Skill”

• “把我写的 Skill 发布到 Nacos”

在 Cursor 所在环境安装并配置 nacos-cli 后，终端可直接调用 Nacos 完成配置与 Skill 的读写；Nacos 内置的 nacos-skill 可从控制台或通过 skill-sync 同步到 Cursor 的本地 Skill 目录，Cursor 加载后即可在编辑器内通过自然语言或工具调用 Nacos 的配置与 Skill。终端侧通过 nacos-cli、对话与工作流侧通过 nacos-skill，二者配合即可在 Cursor 内完成配置管理与 Skill 管理。

与 Cursor 集成的操作步骤（以下均在 Cursor 所在环境完成）：

1. 安装并配置 nacos-cli

按前文「nacos-cli」章节完成安装，在终端配置 Nacos 服务地址与命名空间（如通过环境变量或 nacos-cli 的 config 命令），使 Cursor 内终端可访问 Nacos。

2. 将 nacos-skill 同步到 Cursor 本地 Skill 目录

登录 Nacos 控制台，进入 AI Registry → Skill，找到内置的 nacos-skill，使用控制台提供的「下载到本地」能力，将 nacos-skill 下载到 Cursor 使用的本地 Skill 目录（即 Cursor 的 Skill 根目录，具体路径以 Cursor 文档为准）。也可在终端使用 nacos-cli 的 skill-sync 命令，将 nacos-skill 从 Nacos 同步到该目录。

3. 在 Cursor 中加载并使用

在 Cursor 中加载已同步的 nacos-skill 后，即可在编辑器内通过自然语言或 Skill 暴露的工具，完成对 Nacos 配置的查询、发布、修改，以及对 Skill 的列表、拉取、上传等管理操作；同时可在 Cursor 终端直接执行 nacos-cli 命令，完成配置与 Skill 的脚本化操作。至此，配置管理与 Skill 管理均可在 Cursor 内完成。

更多 nacos-cli 命令与参数见 nacos-cli 使用说明。

skills.sh 是一个开放的 Agent Skills 生态系统，充当着 Cursor、Claude Code 等 AI 助手的“全球应用商店”，它通过标准化的协议汇聚了海量由社区贡献的高质量工作流与提示词；用户只需访问其官网浏览资源，并利用 npx skills add 命令即可一键将 GitHub 上的专业技能（如代码审查、架构设计等）无缝集成到本地环境，从而以极低的成本快速复用全球开发者的智慧，瞬间大幅提升 AI Agent 在特定领域的专业表现。

通过 nacos-cli 和 Nacos Server，可以将 Nacos 打造为团队级 AI Skill 注册中心，与 npx skills 生态无缝集成。

已完成：通过 nacos-cli 上传 Skill 到 Nacos

支持将通过npx skills 下载到本地的 Skill 上传至 Nacos，实现团队内部的 Skill 集中管理和分发。

使用示例：

# 1. 通过 npx skills 下载 Skill
npx skills add my-skill
# 2. 上传到 Nacos
nacos-cli skill-upload ~/.skills/my-skill --config ~/.nacos-cli.conf
# 3. 批量上传整个目录
nacos-cli skill-upload --all ~/.skills --config ~/.nacos-cli.conf
# 4. 团队成员拉取
nacos-cli skill-get my-skill --config ~/.nacos-cli.conf

计划中：Nacos Server 作为 npx skills 的 Registry 后端

通过 Nacos Server 支持修改 npx skills 的 registry URL，使 npx skills 命令可直接对接 Nacos，无需 nacos-cli 中转。

目标架构：

npx skills find [query]          # 搜索结果包含 Nacos 中的 Skill
npx skills add skill-name        # 直接从 Nacos 拉取 Skill

预期效果：

• Nacos Server 提供 skills.sh 兼容的 API，npx skills add 可直接识别并拉取 Nacos 中的 Skill。

• 搜索、下载操作通过npx skills 原生命令完成，体验与公共 skills.sh 一致。

• 上传仍通过 nacos-cli skill-upload完成（npx skills 本身无 publish 能力）。

即将发布的 Agentscope Java 新版本将支持全面接入 Nacos AI Registry 的 Prompt 与 Skill 能力。若希望在 Java 侧 Agent 中直接使用 Nacos 上管理的 Prompt、Skill，可通过 Agentscope Java 与 Nacos 完成接入，在 Agent 运行时按需拉取或订阅，并支持配置变更的实时感知。

Step1：依赖版本

建议使用以下版本（与 Nacos 3.2 兼容）：

• AgentScope Java：1.0.10，用于在 Agent 中集成 Prompt 与 Skill 能力。

Maven 依赖示例：

<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>3.2.0-BETA</version>
</dependency>
<dependency>
    <groupId>io.agentscope</groupId>
    <artifactId>agentscope-core</artifactId>
    <version>1.0.10</version>
</dependency>
<dependency>
    <groupId>io.agentscope</groupId>
    <artifactId>agentscope-extensions-nacos-prompt</artifactId>
    <version>1.0.10</version>
</dependency>
<dependency>
    <groupId>io.agentscope</groupId>
    <artifactId>agentscope-extensions-nacos-skill</artifactId>
    <version>1.0.10</version>
</dependency>

Step2：构建 AiService

使用 Nacos 提供的 AiFactory，传入连接 Nacos 所需的 Properties（至少包含 serverAddr、可选 namespace 等），即可创建 AiService 实例，用于拉取与订阅 Prompt、Skill。示例：

import com.alibaba.nacos.api.ai.AiFactory;
import com.alibaba.nacos.api.ai.AiService;
import com.alibaba.nacos.api.PropertyKeyConst;
Properties properties = new Properties();
properties.put(PropertyKeyConst.SERVER_ADDR, "127.0.0.1:8848");  // Nacos 地址
properties.put(PropertyKeyConst.NAMESPACE, "public");            // 可选，命名空间
AiService aiService = AiFactory.createAiService(properties);
// 后续使用 aiService 获取 / 订阅 Prompt、Skill

Step3：接入 Prompt

在 agentscope-java 中接入 Nacos 的 Prompt：通过 AiService 等接口，按 Prompt Key 从 Nacos 拉取或订阅已在控制台配置好的 Prompt 模板（含变量占位），在 Agent 逻辑中填入变量后即可使用。支持按需获取与监听变更，便于 Prompt 在 Nacos 侧迭代而 Java 侧无需重启。

import com.alibaba.nacos.api.PropertyKeyConst;
import com.alibaba.nacos.api.config.ConfigFactory;
import com.alibaba.nacos.api.config.ConfigService;
import io.agentscope.core.nacos.prompt.NacosPromptListener;
import java.util.HashMap;
import java.util.Map;
import java.util.Properties;
public class Main {
    public static void main(String[] args) throws Exception {
        // 1. 创建 NacosPromptListener
        NacosPromptListener promptListener = new NacosPromptListener(configService);
        // 2. 准备模板变量
        Map<String, String> variables = new HashMap<>();
        variables.put("role", "技术顾问");
        variables.put("domain", "Java开发");
        variables.put("style", "简洁专业");
        // 3. 获取渲染后的 Prompt（支持默认值兜底）
        String defaultPrompt = "你是一个AI助手，请回答用户的问题。";
        String sysPrompt = promptListener.getPrompt("my-agent", variables, defaultPrompt);
        // 4. 用 Prompt 构建 Agent
        ReActAgent agent = ReActAgent.builder()
                .name("MyAgent")
                .sysPrompt(sysPrompt)
                .model(DashScopeChatModel.builder()
                        .apiKey(System.getenv("DASHSCOPE_API_KEY"))
                        .modelName("qwen-plus")
                        .build())
                .memory(new InMemoryMemory())
                .build();
        // 6. 调用 Agent
        Msg response = agent.call(Msg.builder()
                .name("user")
                .role(MsgRole.USER)
                .content(TextBlock.builder().text("你好").build())
                .build()).block();
        System.out.println(response.getFirstContentBlock());
    }
}

Step4：接入 Skill

在 agentscope-java 中接入 Nacos 的 Skill 有两种常见方式：

方式一：nacos-cli 的 skill-sync + FileSystemSkillRepository

使用 nacos-cli 的 skill-sync 命令将 Nacos 上指定的 Skill 同步到本地目录，在 agentscope-java 中配置 FileSystemSkillRepository 指向该目录，Agent 从本地文件系统加载 Skill，适合「先同步、后本地加载」的离线或脚本化流程。

// 1. 同步指定Skill至本地
// 2. 通过Skill路径，配置FileSystemSkillRepository
FileSystemSkillRepository repository = new FileSystemSkillRepository(skillsBaseDir, false);
if (!repository.skillExists(SKILL_NAME)) {
    // ...    
    return;
}
AgentSkill skill = repository.getSkill(SKILL_NAME);
// 3. 加载使用Skill
Toolkit toolkit = new Toolkit();
SkillBox skillBox = new SkillBox(toolkit);
skillBox.registration().skill(skill).apply();
ReActAgent agent = ReActAgent.builder()
                    // ...
                    .toolkit(toolkit)
                    .skillBox(skillBox)
                    // ...
                    .build();

方式二：NacosSkillRepository

在 agentscope-java 中直接使用 NacosSkillRepository，通过已构建的 AiService（或 Nacos 连接配置）从 Nacos 拉取或订阅 Skill，Agent 运行时从 Nacos 实时获取，支持变更订阅与自动感知，适合需要与 Nacos 保持同步的在线场景。

// 1. 获取指定Skill
NacosSkillRepository repo = new NacosSkillRepository(aiService, "public")
if (repo.skillExists(SKILL_NAME)) {
    AgentSkill skill = repo.getSkill(SKILL_NAME);
    System.out.println("Skill: " + skill.getName() + " - " + skill.getDescription());
} else {
    System.out.println("Skill not found: " + SKILL_NAME);
}

具体接入方式与示例可参考 Nacos 与 agentscope-java 的官方文档与示例工程。

Nacos 3.2 是 Nacos 迈向 AI 时代的重要一步：在持续做好配置中心与服务发现的基础上，将 AI Registry、Nacos Copilot、nacos-cli、nacos-setup 串成一条从「注册与治理」到「优化、消费与落地」的完整链路，帮助开发者在本地与生产环境中更顺畅地管理 Prompt、Skill、MCP、Agent 等 AI 资源。

Skills Registry 是 Nacos 3.x 架构下重要模块，在Agent 安全治理中，Nacos 还会再下个版本继续深化 安全围栏审核，数据细粒度鉴权，Skills 资源审批、Skills 签名等安全特性，面向 Skills 效果也会进行创建 Skills 和验证Skills 的体验优化，也欢迎大家在社区里边反馈需求和问题，我们会及时跟进，可以加入我们的钉钉社区群：115205016856 进行讨论。

过去几年，Nacos 在云原生时代陪伴了大量开发者，成为微服务配置与发现领域的基础设施之一。在 AI 时代，Nacos 将继续服务广大开发者与团队，助力构建稳定、可运维的 AI 基础设施。后续规划将围绕以下方向展开：

• AI Registry 功能持续完善：包括多版本管理、Agent 侧灰度分发、以及 Prompt、Skill、MCP、Agent 等 AI 资源间的整合与联动；

• 私有化 AI 注册中心的企业级能力建设：包括智能检索、路由、以及安全、升级与合规；

• Nacos Copilot 持续进化：深化 AI 能力在产品中的运用，让优化与推荐更智能、更贴近使用场景。

相关项目：

• nacos

  https://github.com/alibaba/nacos/

• agentscope-java

  https://github.com/agentscope-ai/agentscope-java

• nacos-cli

  https://github.com/nacos-group/nacos-cli

• nacos-setup

  https://github.com/nacos-group/nacos-setup

阅读原文

跳转微信打开

HiClaw 开源后 Star 迅速飙涨，最晚明天发布新版本。

好消息，HiClaw 新版本最晚将于明天发布。🎉

HiClaw 上周开源后，Star 迅速飙涨，同时，多样化的安装环境和多层次的使用场景也带来了大量的咨询。在此，感谢各位开发者提供的建议，我们迅速整理了 FAQ，并已发布到 GitHub，方便大家检索。同时，我们新增两个自动化服务工具：

1、有问题，提 issue：每天 10 点和 18 点，HiClaw GitHub 会有一只龙虾🦞，对所有 issue 进行答复。

2、有问题，艾特机器人：推荐加入钉群（163855016601），钉群服务机器人将于下周上线，提供自助答疑服务。

HiClaw 并不和其他 xxClaw 对标，HiClaw 是一个 Agent 协作网络。

• 每个 Claw 支持用户自定义，可以是 OpenClaw，也可以是 Copaw、NanoClaw、ZeroClaw 或是企业自建的 Agent，目前预装的是 OpenClaw。

• 引入了 Manger Claw 的角色，不用真人去管理每个干活的 Worker Claw，节省管理成本。

• 使用 Element IM 客户端+Tuwunel IM 服务器（均基于 Matrix 实时通信协议），通信协议和原生的不同，节省钉钉、飞书 IM 的接入和企业内的审批成本，方便用户快速体验在 IM 的交互环境中体验模型服务的“爽感”，同时支持以 OpenClaw 原生的方式接入 IM。

• 引入 MinIO 共享文件系统，用于 Agent 之间的信息共享，真人之间的协作，共同记忆也是基于共享文件系统。

• 引入 Higress AI Gateway，入口和各类凭证风险降低了，减少了用户对原生龙虾在安全上的顾虑。

HiClaw 配置过程中，模型服务接入的默认选型是百炼 Coding Plan。每个 Worker 龙虾的模型服务，可以通过 Manager 龙虾来进行分配，也可以在 Higress 控制台进行配置。

可以的，但是部署方式需要企业自行解决；后续会和阿里云的云产品，例如函数计算 FC 合作，推出云端的企业级部署方案。

可以的，安装目录下有 hiclaw-manager，可以手动配 openclaw.json，跟 OpenClaw 的接入方式是一样的。

是的，HiClaw Manager 和 Workers 均各自运行在完全隔离的容器里，不持有任何真实凭证，这样做的好处是：

• Skills 隔离，避免混用。

• Memory 隔离，避免记忆混淆。

• 放心 Worker 放心地从上万个公开技能库里按需获取能力，Skills 能延展 HiClaw 的使用场景。

因为 HiClaw 的定位并不是对标或替换 OpenClaw，是不冲突的，不存在迁移方案。此外，用户安装 HiClaw 后，基于 HiClaw 的 Manager + Workers 的协作网络，可以将原有的 OpenClaw 作为 Worker 纳管进来。

插件和 Skills 都支持，进入 Manager 容器执行 OpenClaw 的插件和 Skills 配置命令就可以。但要暴露端口给宿主机的，考虑安全原因，暂不支持。

• 支持 Mac、Window 和 Linux 环境，其中，Window 环境要求是 PowerShell 7+（推荐使用 Mac）。

• 下载并安装 Docker Desktop（Windows/macOS）或 Docker Engine（Linux）或 Podman Desktop（替代方案）。

• 最低 2C GB 内存。如果希望部署较多 Worker 体验更强大的 Agent Teams 能力，建议 4C8GB 内存。OpenClaw 内存占用较高，Docker Desktop 用户可在 Settings → Resources 中调整。

执行以下命令查看已安装的版本：

docker exec hiclaw-manager cat /opt/hiclaw/agent/.builtin-version

重新执行安装脚本，即可原地升级，数据和配置会保留。默认升级到最新版本。

HICLAW_VERSION=0.2.0 bash <(curl -sSL https://higress.ai/hiclaw/install.sh)

如果在 Windows 下执行 PowerShell 安装脚本后窗口立即关闭，请先确认是否已安装 Docker Desktop。如果已安装，请确认 Docker Desktop 是否已启动并完全加载，脚本需要连接 Docker 守护进程，Docker Desktop 未运行时会直接失败退出。

安装完成后如果 Manager Agent 迟迟没有响应，进容器查看日志：

docker exec -it hiclaw-manager cat /var/log/hiclaw/manager-agent.log

情况一：日志中有进程退出记录

可能是 Docker VM 分配的内存不足。建议将内存调整到 4GB 以上：Docker Desktop → Settings → Resources → Memory。调整后重新执行安装命令。

情况二：日志中没有进程退出，但某些组件起不来

可能是配置脏数据导致的。建议到原安装目录重新执行安装命令，选择删除重装：

bash <(curl -sSL https://higress.ai/hiclaw/install.sh)

安装脚本检测到已有安装时会询问处理方式，选择删除后重装即可清除脏数据。

情况三：Mac M 系列芯片 + 低版本 Docker

如果你使用的是搭载 Apple M 系列芯片（M1/M2/M3/M4）的 Mac，且 Docker Desktop 版本低于 4.39.0，Manager Agent 可能无法正常启动。

解决方案：升级 Docker Desktop 到 4.39.0 或更高版本。如果你使用的是 Podman，则不受此问题影响。

访问 Element Web

在局域网其他电脑的浏览器中输入：

http://<局域网IP>:18088

浏览器可能会提示“不安全”或“不支持”，忽略提示直接点 Continue 进入即可。

修改 Matrix Server 地址

默认配置的 Matrix Server 域名解析到 localhost，在其他电脑上无法连通。登录 Element Web 时，需要将 Matrix Server 地址改为：

http://<局域网IP>:18080

例如局域网 IP 是 192.168.1.100，则填写 http://192.168.1.100:18080。

官方教程提供的房间是走本地 127.0.0.1，这是本地回环网卡。*-local.hiclaw.io 域名默认解析到 127.0.0.1，开启代理后请求会被转发到代理服务器，无法到达本地服务。

请检查浏览器或系统是否开启了代理。关闭代理，或将 *-local.hiclaw.io / 127.0.0.1 加入代理的绕过列表即可。

创建 Worker 后，Manager 会自动将你和 Worker 拉入同一个群聊房间。在群聊中，必须 @ Worker 才能让它响应，没有 @ 的消息会被忽略。在 Element 等客户端中，输入 @ 后再输入 Worker 昵称的首字母，才会出现补全列表，选择对应用户即可。

也可以点击 Worker 的头像，进入私聊。私聊中不需要 @，每条消息都会触发 Worker 响应。但注意：私聊对 Manager 不可见，Manager 不会感知到这部分对话内容。

让 Manager 切换（推荐）

OpenClaw 需要在配置中设置模型的上下文窗口大小（contextWindow）。HiClaw 默认使用 qwen3.5-plus 的 1M token 窗口。如果切换到窗口更小的模型但没有更新这个设置，当对话接近窗口上限时，OpenClaw 不知道何时压缩上下文，可能导致 session 无法使用。

为此，HiClaw 给 Manager 配备了模型切换技能，会根据模型名自动修改 OpenClaw 配置中的 contextWindow 和 maxTokens。

切换步骤

在 Higress 控制台配置好模型供应商后，直接告诉 Manager 模型名即可：“切换到 claude-3-5-sonnet”Manager 会使用模型切换技能完成配置更新。

如果切换没有成功？可能是 Manager 没有自动调用模型切换技能。可以主动告诉它：“用模型切换技能帮我切换到 claude-3-5-sonnet”。

让 Higress AI 控制台切换

单供应商情况

在 Higress 控制台，将 default-ai-route 这个路由配置到你的模型供应商。然后直接告诉 Manager 你想使用的具体模型名（例如 qwen3.5-plus）。Manager 会先用该模型名发起一次联通测试，测试通过后自动完成切换。

多供应商情况

在 Higress 控制台，创建多条 AI 路由，每条路由配置不同的模型名匹配规则（前缀或正则），分别指向对应的供应商。之后的流程与单供应商完全一致——告诉 Manager 模型名，它会自动完成测试和切换。

参考：Higress AI 快速开始 — 控制台配置^[1]。

流程与切换 Manager 模型类似，两种情况都由 Manager 代为操作。

创建时指定：在让 Manager 创建 Worker 时直接说明模型，例如“帮我创建一个名为 alice 的 Worker，使用 qwen3.5-plus”。

创建后修改：随时告诉 Manager 切换某个 Worker 的模型，例如“把 alice 的模型切换为 claude-3-5-sonnet”，Manager 会自动更新该 Worker 的配置。

切换前请确保 Higress 的 default-ai-route 已配置好目标模型名到对应供应商的路由。

接收你发送的文件：支持。在 Element Web 中点击附件按钮上传文件，Manager 或 Worker 会收到 Matrix 媒体消息并可以读取其内容。

向你发送文件：支持。当你要求 Manager（或 Worker）发送文件时——例如任务产物、生成的报告或它能访问的任意文件——它会将文件上传到 Matrix 媒体服务器，并以可下载附件的形式发送到房间中，你在 Element Web 里点击即可下载。

这是正常现象，说明底层的 OpenClaw Agent 引擎正在执行任务。HiClaw 设定的单次任务超时时间为 30 分钟，Agent 最长会持续执行 30 分钟。

如果想查看 Agent 的执行细节，可以进入 Manager 或 Worker 容器，查看 session 日志：

# Manager
docker exec -it hiclaw-manager ls .openclaw/agents/main/sessions/
# Worker（将 <worker-name> 替换为实际容器名）
docker exec -it <worker-name> ls .openclaw/agents/main/sessions/

该目录下的 .jsonl 文件由 OpenClaw 实时写入，记录了完整的 Agent 执行过程，包括 LLM 调用、工具使用、推理步骤等。

后续，我们将上线 Team 看板，用于查看日志和对话。

如果 Manager 没有响应，或者返回了 404、503 等状态码，查看 Higress AI 网关日志：

docker exec -it hiclaw-manager cat /var/log/hiclaw/higress-gateway.log

在日志中搜索对应的状态码，常见原因：

• 503：容器内网络环境问题，导致外网 LLM 服务不可达。

• 404：模型名称填写有误。

要判断是后端服务出错还是 Higress 自身配置问题，查看日志中的 upstream_host 字段：如果该字段有值，说明请求已到达后端，异常状态码是由上游服务返回的；如果为空，说明 Higress 本身无法路由该请求。

检查 HiClaw 安装过程中，API 联通性是否通过。未通过如下：

若出现以上情况，需要检查模型 API，我们这里以百炼 Coding Plan 为例：

通过的效果如下，通过后不会再报 401。

如果给 Manager 或 Worker 发送消息后没有回复，可以按以下步骤排查：

1. 检查聊天环境

私聊 vs 群聊：

• 如果是私聊（只有你和一个 Agent），每条消息都会触发 Agent 响应。

• 如果是 2 人以上的房间（群聊），必须 @ Agent 才能让它响应，没有 @ 的消息会被忽略。

2. 检查 session 状态

可能是 OpenClaw session 卡住了。进入 Manager 或 Worker 容器，使用 OpenClaw TUI 查看：

# Manager
docker exec -it hiclaw-manager openclaw tui
# Worker（将 <worker-name> 替换为实际容器名）
docker exec -it <worker-name> openclaw tui

进入 TUI 后：

1. 输入 /sessions 查看所有 session。

2. 切换到对应聊天记录的 session。

3. 尝试对话，观察是否有报错。

如果 session 确实卡住了，可以尝试用 /reset 重置 session，看是否恢复正常。

3. 检查模型配置

可能是模型的上下文窗口大小配置不正确，导致窗口耗尽前没有及时压缩。请参考如何切换 Manager 的模型^[2]和如何切换 Worker 的模型^[3]进行正确配置。

HiClaw Manager 基于 OpenClaw 构建，原生支持多种消息渠道。要对接其他渠道：

方法一：直接修改配置

Manager 的工作目录是宿主机上的 ~/hiclaw-manager，里面的 openclaw.json 可以直接编辑。参照 OpenClaw 文档^[4]中各平台的配置格式进行配置。

修改后重启 Manager 容器使配置生效：

docker restart hiclaw-manager

方法二：让 Manager 学习你现有的 OpenClaw 配置

如果你已经在其他地方使用 OpenClaw 接入了其他渠道，可以让 Manager 读取你现有的配置：

• 告诉 Manager 文件位置：在 Element Web 中告诉 Manager 你的 OpenClaw 配置文件路径（例如“我的 OpenClaw 配置在 /home/user/my-openclaw.json”），Manager 会直接读取。

• 通过附件发送：在 Element Web 或其他 Matrix 客户端中，把配置文件作为附件上传发送给 Manager，Manager 会接收并读取。

然后让 Manager 帮你在它的配置里添加相同的渠道。

目前 Worker 基于 OpenClaw 运行，内存占用较高（约 500MB+）。我们计划支持更轻量的 Agent 运行时：

• CoPaw（最新代码已支持）：AgentScope 团队开发的轻量 Agent 运行时，支持本地模型（llama.cpp/MLX/Ollama）和多渠道接入，内存占用比 OpenClaw 更低。

• ZeroClaw：基于 Rust 的超轻量运行时，3.4MB 二进制，冷启动 <10ms，专为边缘和资源受限环境设计。

• NanoClaw：极简 OpenClaw 替代品，<4000 行代码，基于容器隔离，使用 Anthropic Agents SDK。

目标：将单 Worker 内存占用从 ~500MB 降至 <100MB，在相同硬件上支持更多 Worker。

开箱即用的可视化控制台，用于观察和管控整个 Agent Team：

• 实时观测：每个 Agent 的工作过程细节可视化（对话、工具调用、思考过程）。

• 主动打断：发现问题时可随时打断指定 Agent 的工作，接管或调整方向。

• 任务时间线：谁在什么时候做了什么，完整历史记录。

• 资源监控：每个 Worker 的 CPU/内存使用情况。

目标：让 Agent Teams 像人类团队一样透明可控——没有黑盒。

目前 Worker 通过 Higress MCP 网关 + mcporter 访问 GitHub，只需使用 Higress 签发的 token，真实的 GitHub PAT 永远不会暴露给 Worker。这个安全的模式可以扩展到任意 MCP 服务：

• 预置 MCP 连接器：GitHub、Slack、Notion、Linear 等常用服务。

• 自定义 MCP 集成：接入自己的 MCP 服务，由 Higress 统一管理认证。

• 细粒度权限控制：Manager 可按 Worker 授予/撤销 MCP 服务访问权限。

目标：任何支持 MCP 协议的工具都能安全地暴露给 Worker，凭证零泄露。

由于多样化的安装环境和多层次的使用场景，带来了大量的咨询。特此征集文字类和视频类的教程。

安装和部署环境，可任选：

• Mac、Window 或 Linux 环境。

• Docker Desktop、Docker Engine（Linux）或 Podman Desktop。

• 本地 PC 部署、本地盒子部署、云端部署。

• 本地访问、公网访问。

应用场景，可任选，不限于以下场景：项目协作、社交媒体托管、软件开发、内容创作、项目管理、研究和学习、情感陪护等。

教程入选后，您将获得：

• 社区 Contributor 身份和纪念品。

• 流量推广，包括线上媒体和 HiClaw 线下沙龙的受邀分享嘉宾。

• 推荐给 DataWhale 和极客时间等主流 AI 媒体。

联系方式：微信（max_0928）或钉钉（如下）。

相关链接：

[1] Higress AI 快速开始 — 控制台配置

https://higress.ai/docs/ai/quick-start#%E6%8E%A7%E5%88%B6%E5%8F%B0%E9%85%8D%E7%BD%AE

[2] 如何切换 Manager 的模型

https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation/releases/tag/v0.1.0

[3] 如何切换 Worker 的模型

https://github.com/alibaba/hiclaw/blob/main/docs/zh-cn/faq.md#%E5%A6%82%E4%BD%95%E5%88%87%E6%8D%A2-worker-%E7%9A%84%E6%A8%A1%E5%9E%8B

[4] OpenClaw 文档

https://docs.openclaw.ai/

跳转微信打开

扛得住百PB级日处理量，资源消耗直降80%！阿里云开源的 LoongCollector 凭什么成为千万级装机的云原生统一采集器？零拷贝架构、自愈网络、多租户隔离——数万企业每天在用的真实生产答案。性能拉满，稳定不妥协，AI 与 FinOps 时代的数据采集硬核底座来了！

┌──────────────────┐
│ Processor Thread │──── [Lock-free Pool] ──── Direct Reuse
└──────────────────┘

┌────────────────┐     ┌─────────────────┐
│ Input Thread   │────▶│ Processor Thread│
└────────────────┘     └─────────────────┘
      │                          │
      └── [Double Buffer Pool] ──┘

┌─ High-Low Watermark Feedback System ─────────────────────┐
│                                                          │
│  ┌─ Queue State Management ─┐  ┌─ Feedback Mechanism ──┐ │
│  │                          │  │                       │ │
│  │  ┌─── Normal State ───┐  │  │  ┌──── Upstream ────┐ │ │
│  │  │ Size < Low         │  │  │  │ Check            │ │ │
│  │  │ Accept all data    │  │  │  │ Before Write     │ │ │
│  │  └────────────────────┘  │  │  └──────────────────┘ │ │
│  │           │              │  │                       │ │
│  │           ▼              │  │                       │ │
│  │  ┌── High Watermark ──┐  │  │                       │ │
│  │  │ Size >= High       │  │  │  ┌──── Downstream ──┐ │ │
│  │  │ Stop accepting     │  │  │  │ Feedback Enabled │ │ │
│  │  │ non-urgent data    │  │  │  └──────────────────┘ │ │
│  │  └────────────────────┘  │  │                       │ │
│  │           │              │  │                       │ │
│  │           ▼              │  │                       │ │
│  │  ┌─ Recovery State ──┐   │  │                       │ │
│  │  │ Size <= Low       │   │  │                       │ │
│  │  │ Resume accepting data │  │                       │ │
│  │  └───────────────────┘   │  │                       │ │
│  └──────────────────────────┘  └───────────────────────┘ │
└──────────────────────────────────────────────────────────┘

┌─ High Priority ────────────────────────────────────────────────────┐
│  ┌───────────┐                                                     │
│  │ Pipeline1 │ ◄─── Always processed first                         │
│  └───────────┘                                                     │
│        │                                                           │
│        ▼ (Priority transition)                                     │
└────────────────────────────────────────────────────────────────────┘
┌─ Medium Priority (Round-robin cycle) ──────────────────────────────┐
│  ┌───────────┐    ┌─────────────────┐    ┌────────────┐            │
│  │ Pipeline2 │───▶│ Pipeline3(Last) │───▶│ Pipeline 4 │            │
│  └───────────┘    └─────────────────┘    └────────────┘            │
│        ▲                                        │                  │
│        └────────────────────────────────────────┘                  │
│                                                                    │
│  Note: Last processed was Pipeline3, so next starts from Pipeline4 │
│         │                                                          │
│         ▼ (Priority transition)                                    │
└────────────────────────────────────────────────────────────────────┘
┌─ Low Priority (Round-robin cycle) ─────────────────────────────────┐
│  ┌───────────┐    ┌───────────┐                                    │
│  │ Pipeline5 │───▶│ Pipeline6 │                                    │
│  └───────────┘    └───────────┘                                    │
│        ▲                   │                                       │
│        └───────────────────┘                                       │
│                                                                    │
│  Note: Processed only when higher priority pipelines have no data  │
└────────────────────────────────────────────────────────────────────┘

┌─ ConcurrencyLimiter Configuration ───────────────────────────────────────┐
│                                                                          │
│ ┌─ Failure Rate Thresholds ────────────────────────────────────────────┐ │
│ │                                                                      │ │
│ │ ┌─ No Fallback Zone ─┐ ┌─ Slow Fallback Zone ─┐ ┌─ Fast Fallback ──┐ │ │
│ │ │                    │ │                      │ │                  │ │ │
│ │ │ 0% ─────────── 10% │ │ 10% ──────────── 40% │ │ 40% ─────── 100% │ │ │
│ │ │                    │ │                      │ │                  │ │ │
│ │ │ Maintain Current   │ │ Multiply by 0.8      │ │ Multiply by 0.5  │ │ │
│ │ │ Concurrency        │ │ (Slow Decrease)      │ │ (Fast Decrease)  │ │ │
│ │ └────────────────────┘ └──────────────────────┘ └──────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│                                                                          │
│  ┌─ Recovery Mechanism ─┐                                                │
│  │ • Additive Increase  │  ← +1 when success rate = 100%                 │
│  │ • Gradual Recovery   │  ← Linear scaling back to max                  │
│  └──────────────────────┘                                                │
└──────────────────────────────────────────────────────────────────────────┘

相关链接：

[1] benchmark e2e README

https://github.com/alibaba/loongcollector/blob/main/test/benchmark/e2e/README.md

[2] 阿里云 SLS（Simple Log Service）

https://www.alibabacloud.com/en/product/log-service?_p_lc=1

阅读原文

跳转微信打开

Apache Dubbo Admin，面向传统注册中心、云原生架构的全局服务治理管控面！

Apache Dubbo Admin 是一个用于更好地可视化、监控、治理 Dubbo 微服务应用程序的管控台。0.7.0 版本是一个以 Kubernetes 原生为核心设计目标的里程碑版本，标志着 Apache Dubbo Admin 从“注册中心管理控制台”，演进为云原生环境中的服务治理控制面（Control Plane）。

Apache Dubbo Admin 0.7.0 围绕 Kubernetes 原生运行、事件驱动治理、控制面架构进行了系统性重构，以下是 Admin 整体架构图：

• 兼容传统注册中心与 Kubernetes 架构：同时支持传统注册中心、Kubernetes Service 架构，支持应用、实例、服务视角的全局可视化治理；支持多注册中心与跨集群部署方案；

• 治理能力全新升级：统一的流量治理界面，后端实现传统注册中心、Kubernetes 资源的自动规则转换与分发；

• 可观测能力深度集成：Admin 不再只是展示应用、实例、服务等“元数据”，而是提供调用链路的实时可观测能力，支持 Metrics、Tracing 等的可视化展示；

• Kubernetes 原生设计：Admin 与 Kubernetes 集群无缝衔接，后端系统基于 Go 语言重构，与 client-go、informer、cache 深度集成。

此次重构，Admin 基于领域驱动的思想对 Dubbo 领域的实体进行了完整的建模，Dubbo 的领域模型有应用（Application），服务（Service），实例（Instance）以及路由规则（Rule）。这几个用户熟知的领域模型贯穿了 Admin 的产品设计以及前后端架构。基于这些领域模型，Admin 定义出了一套完全遵循 Kubernetes 的“CRD”。这也是一个重要的 K8s 原生体现，同时也为以后更多的 K8s 原生功能拓展打下了坚实的基础。

此外，得益于 client-go 的 informer 机制，新版本中对注册中心/K8s 的监听使用 list-watch 模型进行了统一，所有的资源都以事件的方式进行异步更新，对于控制台的前端查询始终走的是本地的缓存，大大减小了对注册中心/K8s 的查询压力。

此次 Admin 控制台 UI 全面焕新，从产品设计上紧紧围绕着 Dubbo 的领域模型来展开，将应用，实例，服务有机地串联在一起，并能够与 K8s 资源进行联动。此外，Dubbo 经典的路由规则（动态配置，条件路由，标签路由）也全部表单化，进一步降低用户的对流量管控的使用门槛。用户可以一站式地管理自己的 Dubbo 应用。

Apache Dubbo Admin 0.7.0 是“为 Kubernetes 设计的”，而不是“跑在 Kubernetes 上的”。Admin 以组件化的方式原生支持运行在 K8s 上的 Dubbo 实例，无需配置就能够打通微服务生命周期与 K8s pod 的生命周期。让用户能够直观地感受到 Dubbo 应用的底层运行状态，更好地运维 K8s 上的 Dubbo 实例。这一套模型使 Dubbo Admin 能自然融入 Kubernetes 的 Controller / Reconcile / Desired State 体系。

Apache Dubbo Admin 0.7 版本的云原生主要体现在以下方面：

• 对于传统注册中心模式，如果部署在 Kubernetes 平台下，支持与 Kubernetes 状态、资源的无缝集成，让开发者以应用、实例、服务的统一视角运维与监控微服务集群；

• 支持 Kubernetes Service 微服务模式，Admin 可以统一管理 Kubernetes Service 模式注册的服务，让用户以应用、实例、服务的统一视角运维集群，与传统注册中心模式保持一致。

在内部架构设计上，Admin 将 Kubernetes 中的一些优秀的原生架构拓展到了对于传统注册中心部署架构的支持。我们构建了一套基于 Informer 框架的统一治理模型，将传统注册中心和 Kubernetes CRD 资源全部纳入同一套事件驱动机制中。这个机制能够很好地屏蔽底层差异，无论数据来自运行时引擎 Kubernetes、还是来自于注册中心 Zookeeper 或 Nacos，均通过 Informer 统一接入，这为以后接入更多的数据源如 Docker Compose， VMWare 等打下了坚实的基础。

此外在 informer 框架的基础之上，我们拓展增强了 lister-watcher，store，index 等关键组件，做到了：

• 事件驱动，实时感知：实现对服务注册、配置变更、实例状态等事件的实时监听，真正做到 “变化即响应”；

• 低延迟，功能更丰富的本地缓存：基于 client-go cache 构建的 Memory Store，提供低延迟、强一致性读取能力，完美匹配 Kubernetes Watch、List 语义，同时具备极高的吞吐性能，能够支持多样的索引能力。

在 Kubernetes 世界里，“注册中心”只是数据源之一。此次版本更新还引入了一个重要的特性——多注册中心支持。与此前版本的 Admin 的支持方式不同，新版本中将注册中心作为一个“隔离域”，所有的资源（应用/服务/实例/规则等）都会规约到一个注册中心下面，切换注册中心就相当于切换一个“隔离域”，这也契合大多数企业在生产实践中的使用方式。添加新的注册中心只需要在配置文件中新增注册中心地址即可。

Apache Dubbo Admin 0.7.0 将 Discovery 能力纳入统一控制面架构：

• Nacos Discovery 原生实现

• Zookeeper Discovery 原生实现

• 控制台支持多注册中心：统一视图、支持混合部署、多环境、多集群。这使得 Admin 能够：

• 同时治理 Kubernetes Service + 外部注册中心

• 作为多环境统一治理入口

从“看得见服务”到“看得清调用”，Dubbo Admin 0.7.0 正式补齐可观测控制面。Dubbo SDK 在 3.2+ 版本中进行了 metric 和 trace 的埋点，支持上报 metric 和 trace 到 metric/trace 后端，而此次控制台以 Grafana 为可视化基础，不仅支持 Prometheus，jaeger，zipking 等多种数据源，并直接在控制台中集成了 Dubbo 调用的监控面板和链路追踪面板，让排查问题不再为难。

自 Dubbo Client 3.2+ 起，Dubbo 已在指标与链路层面完成系统性埋点：

• Metrics：请求 QPS / RT / 错误率、服务级 / 方法级调用指标、支持 Prometheus 标准采集；

• Tracing：完整 Dubbo 调用链路、支持 OTLP / Jaeger / Zipkin 等主流链路后端。

Dubbo Admin 0.7.0 首次将可观测能力作为控制面的一部分进行整合：

• 以 Grafana 作为统一可视化基础；

• 内置 Dubbo 调用监控面板：服务 / 方法维度调用趋势；延迟、错误率、吞吐一目了然；

• 内置链路追踪面板：直接查看 Dubbo 调用链路、快速定位慢调用与异常节点。

详细的 Changelog，更多特性介绍以及完整的部署方式请看：

• Github：https://github.com/apache/dubbo-admin

• 官网：https://cn.dubbo.apache.org/zh-cn/overview/home/

如果您有任何的需求、问题等，欢迎在 Github issue/discussion 中一起讨论！

未来 Apache Dubbo Admin 将围绕几个方面持续投入：

1. 持续深耕服务治理，完善接口测试，服务拓扑等能力。持续优化数据链路，保障 Admin 作为控制面的核心能力稳定。

2. 围绕 metric，trace 以及 log，进一步增强可观测能力。此外，结合 K8s 的 event，Admin 还会刻画出每个领域实体的事件瀑布流，更好地观测应用的生命周期，便于工程师排查问题。

3. Admin 将作为 mcp server，在支持原生 Dubbo mcp 的基础上，通过代理的方式支持用户低成本将现有的 Dubbo 接口变成可调用的 mcp 工具，助力 AI 业务创新。

4. 通过 RAG，Agent 等技术，推出 AI assistant，充当 Dubbo 领域的知识专家，并协助用户排查 Dubbo 领域的问题。

请扫码加入 Dubbo Amidn 社区交流群沟通：

阅读原文

跳转微信打开

本文揭秘了 AgentRun Sandbox 是如何基于阿里云函数计算（FC）构建按需弹性沙箱，它深度整合 RunD 安全虚拟化、会话亲和性以及 动态 NAS 挂载等方面的底层技术创新，为企业构建 AI Agent 提供安全、高效、低成本的执行基础设施。

阿里云函数计算 AgentRun 全新发布后，我们整理了“探秘 AgentRun”系列文章，本系列将梳理企业落地 Agent 常见难题，给出具体解法，助力 Agentic AI 快速走进生产级环境。欢迎加入“函数计算 AgentRun 客户群”与我们交流，钉钉群号：134570017218。

在生成式 AI 的早期阶段，应用主要以“Copilot”形式存在，AI 仅作为辅助生成建议。然而，随着 AutoGPT、BabyAGI 以及 OpenAI Code Interpreter（现为 Advanced Data Analysis）的出现，AI 开始扮演“Agent”的角色。Agent 被赋予了目标，并能自主规划步骤、使用工具来达成目标。

这种质变的核心在于代码执行（Code Execution）。为了回答“分析这层楼的销售数据并绘制趋势图”这样的请求，LLM 不再只是生成一段 Python 代码文本，而是需要在一个真实的 Python 环境中运行这段代码，并获取绘图结果。同样，为了“帮我预订一张去东京的机票”，Agent 可能需要在一个无头浏览器（Headless Browser）中模拟用户点击。

当 LLM 生成代码并执行时，这段代码在本质上是不可信的（Untrusted）。如果直接在应用服务器或用户的本地设备上运行，将面临灾难性的安全风险：

• 系统破坏：AI 生成的代码可能无意或恶意地包含 rm -rf / 等破坏性指令，或者修改关键系统配置文件。

• 数据泄露：代码可能尝试读取环境变量中的 API Key，或者扫描内网数据库，将敏感数据发送到外部服务器。

• 资源耗尽：死循环或内存泄漏代码可能导致宿主机崩溃，影响其他租户的服务。

• 网络攻击：恶意 Prompt 注入（Prompt Injection）可能诱导 AI 将执行环境作为跳板（Jump Box），对内部网络发起 DDoS 攻击或端口扫描。

除了基础的安全性，AI Agent 的交互特性还给沙箱环境带来了前所未有的工程挑战，这也是传统沙箱（如简单的 Docker 容器或虚拟机）难以应对的：

• 状态保持：与传统的“请求-响应”模式不同，Agent 往往需要进行多轮对话。上一轮定义的变量（如 df = load_data()）需要在下一轮（df.plot()）中继续可用。这就要求沙箱环境必须具备上下文记忆能力，而非每次请求都重置环境。

• 极速启动：用户无法忍受每次交互都等待数秒甚至数十秒的虚拟机启动时间。为了保证流畅的对话体验（Time to First Token），沙箱必须具备毫秒级的冷启动能力。

• 环境依赖多样性：不同的 Agent 任务可能需要完全不同的依赖库（如 Pandas、Scipy 用于数据分析，Puppeteer 用于网页操作）。沙箱需要支持灵活的自定义镜像或动态依赖加载，同时不能影响启动速度。

• 资源成本控制：Agent 的调用往往具有稀疏性和突发性（例如一天只用几次，但一次用很久）。长期运行独占的虚拟机（VM）成本高昂且资源利用率低，而传统的 FaaS 虽然便宜但往往缺乏状态保持能力。如何在低成本和高性能之间找到平衡点，是一个巨大的挑战。

因此，构建一个沙箱（Sandbox）——一个与宿主机、内网以及其他用户数据严格隔离，同时具备高性能、低成本、有状态的封闭执行环境——成为了 AI Agent 沙箱落地的前提条件。

为了解决上述挑战，我们推出了 AgentRun Sandbox。这是一个以高代码为核心，开放生态、灵活组装的一站式 Agentic AI 基础设施平台。

AgentRun 并非从零构建传统的虚拟机集群，而是基于阿里云函数计算（FC）这一强大的 Serverless 底座构建。通过充分利用 Serverless 的按需付费、极致弹性以及免运维（NoOps）特性，AgentRun 解决了一直困扰沙箱领域的成本与效率难题，并在此基础上通过工程化封装，提供了面向 Agent 场景的专业能力。

在构建 Agent 沙箱时，我们坚定地选择了函数计算（FC）作为底层基础设施，这主要基于以下核心优势的考量：

1. 强安全隔离：沙箱的核心诉求是安全。函数计算底层采用神龙裸金属与 RunD 安全容器技术，每个执行环境都运行在独立的 MicroVM 中。这种基于虚拟化技术的内核级隔离，相比传统的 Docker 容器隔离具有更高的安全性，能有效防止恶意代码逃逸，为不可信代码执行提供了坚实屏障。

2. 极致弹性与冷启动优化：Agent 的调用往往具有突发性。函数计算具备毫秒级的弹性伸缩能力，结合 RunD 技术对启动速度的极致优化，使得沙箱能够在数秒甚至毫秒内完成创建和启动。这不仅满足了高并发场景下的需求，也保证了 Agent 交互的流畅性，避免了传统虚拟机启动慢带来的延迟感。

3. 成本效益：自建虚拟机集群通常需要为峰值流量预留资源，导致低谷期资源浪费。函数计算采用按需付费（Pay-as-you-go）模式，且 AgentRun 利用了 FC 的空闲自动回收机制，真正做到了“有请求才计费”。对于稀疏调用的 Agent 场景，这种模式能显著降低基础设施成本。

4. 免运维：基于 Serverless 架构，开发者无需关心底层服务器的操作系统补丁、网络配置及集群维护。AgentRun 团队可以将精力集中在沙箱的核心逻辑与业务体验上，而非底层基础设施的繁琐运维。

5. 会话能力：函数计算围绕 AI Agent Sandbox 场景推出了会话亲和、隔离以及管理能力。在一次会话生命周期内，相同会话的请求均会被亲和路由到同一个实例中，并独占该实例，保证了会话交互的连续性、上下文完整性以及多租安全性，同时提供完整的管理接口来主动对会话生命周期进行控制，降低了开发门槛。

传统的 Serverless 通常是无状态的，难以满足 Code Interpreter 这类需要上下文保持的场景。AgentRun 借助函数计算的会话产品能力，在无状态的计算底座上构建了有状态、会话级的沙箱体验。

1. 沙箱请求亲和

AgentRun 允许开发者显式地创建一个具有生命周期的执行环境，解决了传统 Serverless“用完即走”导致的上下文丢失问题。

• 会话亲和：AgentRun 依赖函数计算会话亲和机制。当开发者创建沙箱后，AgentRun 会维护一个唯一的 SessionID。后续所有携带该 ID 的请求，都会被精准路由到同一个底层的计算实例。这意味着用户在第一步定义的 df = pd.read_csv(...) 对象，在第二步 df.plot() 时依然存在于内存中，完美复刻本地开发体验。

• MCP 协议原生支持：针对模型上下文协议（Model Context Protocol, MCP），AgentRun 提供了 MCP SSE 及 MCP Streamable HTTP 会话亲和支持。AgentRun 可以直接作为 MCP 网关，让 LLM 与外部工具的交互更加顺滑。

2. 多层次安全隔离

在多租户 SaaS 平台中，安全性是 AgentRun 的基石。

• 计算隔离：AgentRun 利用底层基础设施的神龙裸金属与 RunD 安全容器技术，确保每个沙箱实例在内核级别进行隔离。通过强制将会话并发度设置为 1，AgentRun 保证租户 A 的进程空间、内存数据与租户 B 物理分离，防止容器逃逸。

• 网络隔离：网络隔离完全由用户控制。用户可以根据安全需求灵活配置，选择开启或关闭沙箱的公网访问权限，或者将沙箱接入指定的 VPC 网络环境，从而在满足业务连通性的同时，防止恶意代码对内网发起攻击。

3. 灵活的生命周期控制

AgentRun 通过函数计算的会话能力，接管了底层计算资源的生命周期，为上层应用提供精细化管理：

• 自动闲置回收（Idle Timeout）：为了通过 Serverless 架构降低成本，AgentRun 支持设置空闲超时（例如 5 分钟）。如果 Agent 在这段时间内没有新指令，底层实例会自动销毁并停止计费，完美适配 AI 交互“突发性强、稀疏度高”的特点。

• 状态暂停与恢复（即将上线）：针对长时间的任务间歇，AgentRun 能够将沙箱的内存与磁盘状态快照保存，在用户回归时通过快照快速恢复现场，既节省成本又保留了上下文。

4. 会话粒度存储隔离（即将上线）

代码执行需要隔离，数据存储更需要隔离。AgentRun 创新性地规划了会话粒度存储粘性。

• 动态绑定：AgentRun 允许用户为每个沙箱环境中动态分配一个存储挂载点的专属子目录。

• 逻辑沙箱：通过底层的挂载技术，沙箱内部只能看到属于自己的 /workspace，物理上无法访问其他租户的文件（如 ../../tenant-b/secret.txt），从文件系统层面根除了数据交叉风险。

AgentRun 不仅提供了底层隔离环境，还预置了经过工程化调优的标准化模版，让开发者开箱即用：

1. Code Interpreter（代码解释器）：预装 Python/Node.js/Java 等环境，支持文件上传下载、数据分析、图表绘制及命令行操作。

2. Browser User（浏览器沙箱）：提供基于 CDP over WebSocket 协议的浏览器环境，兼容 Puppeteer / Playwright，让 Agent 能够安全地访问互联网进行网页操作。

3. All In One：集成了代码解释器与浏览器环境的全能型沙箱，满足复杂 Agent 任务需求。

这些模版镜像具备高度的灵活性，AgentRun 未来将开放镜像定义，允许用户基于标准镜像定制私有依赖库或安全策略。

这是 AgentRun 的门户，负责接收来自 AI Agent（如 LangChain 应用、ChatGPT Plugin）的 HTTP 请求，除了标准的身份验证、鉴权以及协议转换（如将 HTTP 转为 WebSocket）之外，其核心能力便是沙箱管理以及沙箱请求路由的功能，它屏蔽了底层 Serverless 基础设施的复杂性，实现了如下能力：

• 沙箱管理：管理沙箱资源，维护业务层沙箱 ID 与底层计算资源 SessionID 的映射关系。

• 状态维护：监控沙箱的活跃状态，基于沙箱超时配置以及底层资源情况及时对状态进行更新。

• 资源调度：根据用户指定的计算规格（CPU、Memory），向底层申请相应的资源。

主要由函数计算作为底层算力来承载沙箱的运行。AgentRun 利用函数计算提供的极致弹性能力，实现在分钟内启动成三万个独立的沙箱环境，每个环境都运行在独立的 MicroVM 中，搭配自研开箱即用的沙箱镜像模版，在功能以及性能上为用户提供了双重保障。

以“用户让 Agent 根据上传的 Excel 文件绘制图表”为例，AgentRun 的工作流程如下。

阶段一：模板创建

1. 用户请求：Agent 接收到用户指令后，由 LLM 决策使用 Python 来实现该需求。

2. Agent 工具调用：AI Agent 会向 AgentRun 网关发送 Code Interpreter 沙箱模板的创建请求。

3. 模板创建：AgentRun 网关会调用函数计算接口创建一个 Code 沙箱模板函数，镜像配置为前文提到的自研 Code Interpreter 沙箱模板，该函数需要同时配置会话亲和以及会话隔离。

阶段二：沙箱创建

1. Agent 工具调用：模板创建完成后，Agent 继续进行沙箱创建，创建时传入已有的模板 ID，标识沙箱实例运行时的配置和镜像。

2. 沙箱创建：AgentRun 收到沙箱创建请求后，会调用 FC 的 CreateSession 接口来创建一个沙箱实例，该沙箱会有一个合适的闲置超时时间，最长可存活 24h。

3. 创建完成：AgentRun 会保存 FC 返回的会话 ID，并生成沙箱业务 ID 与之对应，最终将沙箱业务 ID 返回给用户。

阶段三：任务执行

1. 上传文件：Agent 通过 Code Interpreter 的文件上传接口，将 Excel 文件上传。若想将该文件持久化，可以在创建沙箱时配置持久化存储 NAS，将其挂到沙箱中，并将文件上传到 NAS 挂载的目录上。

2. 绘制图表：Agent 生成代码 import pandas as pd; df = pd.read_excel('data.xlsx')，并调用 Code Interpreter 的 run_code 接口执行代码。

3. 会话亲和：Agent 所有发往 Code Interpreter 的请求中，都必须带上对应的沙箱 ID 才能保证请求都路由到同一个沙箱实例。

4. 内存驻留：代码执行完毕，变量 df 驻留在内存中。

5. 二次代码执行：Agent 根据数据列名生成绘图代码 df.plot()。再次发送代码运行请求

6. 上下文复用：请求再次到达同一实例，直接使用内存中的 df 对象进行绘图，生成图片文件。

7. 结果回传：图片被写入 NAS，下载链接返回给 Agent。

阶段四：资源销毁

1. 空闲检测：Agent 完成任务，不再发送请求。

2. 自动回收：达到 SessionIdleTimeout（如 5 分钟）后，函数计算会自动销毁该沙箱实例，此时除了持久化到 NAS 上的数据，其余环境相关数据均被销毁。

3. 文件回收：如果 NAS 上的文件是会话隔离的，当用户会话结束后，NAS 上文件需要进行主动或者定时自动清除。

工作时序图

AgentRun 的工程化实践遵循以下五大核心原则，这构成了其安全、高效、可扩展的基石：

AgentRun 将沙箱环境定义（环境变量、资源规格、健康检查等）封装为标准化模版。这种设计实现了沙箱配置的版本化管理，使得 Agent 环境可以像代码一样进行复制和回滚。

AgentRun 将“会话”作为沙箱的唯一实体。通过 SessionID 绑定底层的计算实例与上下文状态，实现了真正的按需分配与状态保持。沙箱的创建与销毁完全独立于底层物理设施，对用户透明。

AgentRun 不仅提供创建（Create）和删除（Delete）接口，还引入了“暂停”、“恢复”和“自动超时”机制。这种可编程性让上层应用能根据业务价值最大化资源利用率，实现成本与性能的最优平衡。

AgentRun 抹平了底层网络的差异，提供标准化的 HTTP/WebSocket 接口，并支持 Server-Sent Events（SSE）。无论底层如何升级，上层 Agent 沙箱始终通过标准的 Header 或 Cookie 携带 SessionID 进行交互，降低了集成复杂度。

AgentRun 不仅支持模版粒度的文件系统共享，同时也能够配置沙箱粒度目录级动态挂载。每个沙箱单独挂载一个目录，从根源上杜绝了多租户环境下的数据越权访问风险。

AgentRun Sandbox 是 Serverless 技术在 AI Agent 领域的最佳工程化实践。

通过将阿里云函数计算（FC）在 RunD 安全虚拟化（解决隔离与启动速度）、会话亲和性（解决状态保持）以及动态 NAS 挂载（解决数据隔离）等方面的底层技术创新，封装为面向业务的 AgentRun 平台，我们成功降低了企业构建 AI Agent 的门槛。

对于构建下一代智能体应用的企业而言，选择 AgentRun Sandbox 不仅是选择了一个沙箱工具，更是选择了一套兼顾安全性、用户体验与商业效率的弹性基础设施。未来，AgentRun Sandbox 将继续在启动延迟优化、状态秒级快照恢复以及更多样化的存储支持上深耕，致力于成为 AI Agent 时代最佳的沙箱基座。

函数计算 AgentRun 的无代码到高代码演进能力，现已开放体验（查看更多产品详情：https://www.aliyun.com/product/fc/agentrun）：

1. 快速创建：访问控制台（https://functionai.console.aliyun.com/cn-hangzhou/agent/explore），60 秒创建你的第一个 Agent。

2. 深度定制：当需要更复杂功能时，一键转换为高代码。

3. 持续演进：利用函数计算 AgentRun 的基础设施能力，持续优化你的 Agent。

从想法到上线，从原型到生产，函数计算 AgentRun 始终是你最好的伙伴。欢迎加入“函数计算 AgentRun 客户群”，钉钉群号：134570017218。

一句话介绍：函数计算 AgentRun是一个以高代码为核心的一站式 Agentic AI 基础设施平台。秉持生态开放和灵活组装的理念，为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理。