apollo skill管理

[yyfyfyang]

Apollo什么时候可以推出Skill管理这样的功能呢，目前也没有想好要怎么实现，当前公司内部是使用的apollo，去年花了很大的力气从1.1升级到了2.4.短时间也不会切换别的配置中心，但是当前的ai agent时代，好像确实缺少了这样一个目录管理的能力

[github-actions]

🤖 Issue Triage

感谢反馈。为便于维护者理解您的需求，请补充以下信息：

1. Skill 管理的具体含义和使用场景是什么？
2. 您希望这个功能实现哪些具体能力？
3. 是否有参考的类似系统或功能示例？

更详细的描述将帮助社区更好地评估和讨论此功能请求。

AI generated by Apollo Issue Triage

[yyfyfyang]

背景是：
当前的agent开发中，开发和发布的重心逐渐从代码开发转移到了SKILL和Prompt的开发，Prompt通常是单文件，可以保存为配置项，但是SKILL通常是一个目录，就没有办法保存在Apollo上

1. 能够上传skill到apollo，但是这里是否要和配置的app耦合在一起？是否应该用插件化的方式让应用使用？

[nobodyiam]

结论：Apollo 目前还没有把 Skill 目录作为一等资源进行上传、版本管理和客户端分发的能力，现有能力更适合管理配置项、单文件配置内容或用于指向外部制品的元数据。

从当前实现看，Apollo 的配置模型主要围绕 AppNamespace、Item 和 Release：namespace 定义格式，item 存 key/value，release 存已发布配置快照。客户端侧也主要通过 /configs/{appId}/{clusterName}/{namespace}、/configfiles/{...}、/configfiles/raw/{...} 和 /notifications/v2 获取 namespace 内容或监听变更。Portal 里的 zip 导入/导出能力也是配置迁移格式，例如 ConfigsImportController / ConfigsExportController，并不是通用目录或制品仓库能力。

对于你描述的 Skill 场景，我倾向于先不要把 Skill 目录本身直接强绑定到 Apollo app 里。更可落地的方式是：

1. Skill 目录本体放在 Git、对象存储、制品仓库或内部插件仓库中，Apollo 保存 manifest，例如：
   • skill 名称
   • version
   • 下载地址
   • checksum / signature
   • 适用 app / env / cluster
   • 是否启用、灰度规则等
2. 应用侧或 agent runtime 监听 Apollo 配置变更，读取 manifest 后再从外部仓库下载、校验并加载对应 Skill。
3. 如果是少量单文件 Prompt 或简单 JSON/YAML 配置，继续直接放 Apollo namespace 即可；如果是目录、多文件、依赖和版本组合，建议用外部制品仓库承载内容，Apollo 负责选择、开关、灰度和变更通知。

如果后续要做成 Apollo 原生功能，建议先明确它是不是一个新的 “bundle/artifact” 模型，而不是简单扩展现有 namespace。需要设计的边界包括：目录结构保存方式、大小限制、权限模型、版本回滚、客户端解包和缓存、安全校验、以及是否与 app namespace 共享灰度/发布流程。

因此这个 issue 可以先按 feature request / design discussion 跟进。若要推进实现，建议先补充一个更具体的 proposal：Skill 包格式、消费端流程、是否需要 Apollo 托管文件本体，以及是否接受 “Apollo 管 manifest + 外部仓库管 artifact” 的方案。

[violxx]

今天遇到一个场景，我让ai帮我理业务场景，但是我的很多业务的配置是在Apollo中的，因此，它给我整理的业务逻辑很多地方都是需要重新跟他解释，某个配置当前配置的是什么样的，需要它再次结合告诉它的配置再次整理业务逻辑，我简单根据官方文档让AI帮我写了一个读取测试环境配置的skill，这样下次帮我整理其他业务逻辑时能够主动去Apollo配置后台去查看配置。希望官方能够提供这种skill，大家用着更放心😊

[nobodyiam]

感谢补充，这个场景很有代表性。不过这里可以先把两个需求层次拆开看：

1. 前面讨论的 “Skill 管理” 更偏向把 Skill 目录作为制品进行托管、版本管理和分发；
2. 你补充的场景更像是给 AI agent 提供一个官方的只读 Apollo 配置查询 skill/tool，让 agent 能在授权范围内读取指定 app/env/cluster/namespace 的配置，再用于业务逻辑梳理。

第二类能力从实现入口上可以优先基于现有 Apollo 接口封装，而不一定要先引入新的 Apollo 存储模型。当前可用的读取面包括 Config Service 的 HTTP 接口，例如 /configfiles/json/{appId}/{clusterName}/{namespaceName}、/configfiles/raw/{...}、/configs/{...} 和 /notifications/v2；如果需要走 Portal 管理面能力，则应该优先基于 OpenAPI token 和权限模型，而不是依赖 Portal 页面或 cookie。

如果后续要提供官方 skill，我认为需要先把边界设计清楚：

• 默认只读，不包含发布、修改、删除配置；
• 支持按 app / env / cluster / namespace 做白名单；
• token 使用最小权限，并能和 Apollo 的审计、权限模型对齐；
• 对敏感配置、生产环境配置、批量导出能力要有明确限制；
• 返回内容需要考虑脱敏、大小限制和 agent 上下文泄露风险。

所以这个 issue 可以继续作为 feature request / design discussion 跟进。也欢迎把你现在测试环境用的 skill 形态、调用接口、权限约束和期望的使用方式补充出来，社区可以基于这个用例评估是否先沉淀一个只读示例或官方 skill。

注：本回复由 AI 自动生成并自动发送，用于初步分诊；如需进一步确认，维护者会继续跟进。

[nobodyiam]

结论：@violxx 补充的这个场景很有价值，不过它和本 issue 前面讨论的 “Skill 目录托管、版本管理和分发” 不是完全同一个问题，建议单独开一个 issue 来讨论会更清晰。

我理解这个新场景更像是：为 AI agent 提供一个官方的、默认只读的 Apollo 配置查询能力，让 agent 能在授权范围内读取指定 app / env / cluster / namespace 的配置，再结合配置内容辅助理解业务逻辑。这个方向可以先从 Apollo CLI / OpenAPI 工具链切入，而不一定一开始就直接定义成某个特定 AI 平台的 skill。

可以参考之前的讨论：#5573。那条 issue 里已经提到，Apollo 后续的 agent-facing 能力可以优先从 OpenAPI 契约和 CLI 开始收敛，MCP / Skill 这类上层封装可以在权限、安全边界更清楚后再推进。这样做的好处是：

1. CLI 可以作为稳定的官方工具入口，后续 skill、MCP 或其他 agent runtime 都可以调用它；
2. 读取能力可以先限制为只读，并按 app / env / cluster / namespace 做 scope 控制；
3. 对敏感配置、生产环境配置、批量导出、脱敏和审计可以先形成明确边界；
4. 不需要把 Apollo 直接绑定到某一个 AI 平台的 skill 格式上。

如果你方便的话，建议新开一个 issue，重点描述这个 “官方只读 Apollo 配置查询工具/skill” 的使用场景，例如：

• agent 需要读取哪些配置范围；
• 期望通过 CLI、OpenAPI、MCP 还是 skill 使用；
• token / 权限 / 环境白名单应该如何限制；
• 返回内容是否需要脱敏、大小限制或审计；
• 你现在自建 skill 的大致调用方式和遇到的安全/易用性问题。

这样社区可以把 “Skill 目录管理” 和 “agent 读取 Apollo 配置” 两条设计线分开讨论，后者也可以和 #5573 的 CLI / OpenAPI 方向一起收敛。