From Skill Management to Skill Ecosystem Control Plane

[lostlight530]

From Skill Management to Skill Ecosystem Control Plane

When I first discussed Skills in #2179 the main question was how Skills should differ from Sub-agents

Nexent has now moved much further

Skills can be created from natural language
Loaded only when needed
Packaged with scripts and configuration
Managed through draft and published versions
Imported exported and attached to different Agents

So the question no longer feels like

Should Nexent support Skills

It starts to feel more like this

When Skills become an ecosystem what should the platform make explicit

I recently tested several public Skill implementations

What stood out was not which ecosystem had more Skills

It was that Skills no longer share one execution model

Some Skills are mostly instructions

Some wrap an existing CLI

Some carry their own Python or Shell scripts

Some depend on platform runtime APIs

Some exist mainly to search discover and install other Skills

They may all use SKILL.md

But operationally they are very different objects

1 Execution model

Should a Skill explicitly declare how it works

For example

• instruction
• cli
• script
• runtime
• composite
• registry

This may help Nexent distinguish a lightweight instruction package from a Skill that can execute code access the network or depend on an external runtime

2 Runtime contract

A reusable Skill may need more than a description and tool list

It may also need to declare

• required binaries
• environment variables
• authentication method
• operating system compatibility
• Python Node or Shell requirements
• network access
• file system access
• external services
• possible side effects

At that point the Skill is not only teaching the Agent how to act

It is also declaring the conditions under which the capability can run safely

3 Discovery model

When a platform has only a few Skills a normal list is enough

When the number grows discovery becomes part of the architecture

A Skill index may eventually need to understand

• tags
• triggers
• categories
• languages
• services
• dependencies
• execution model
• permissions
• compatibility
• source
• version
• trust level

This feels like more than search

It becomes capability routing before runtime

4 Trust lifecycle

The open discussions around Skill Market and upload safety already point in this direction

But safety may not end after one upload scan

The full lifecycle may look more like

Discover → Inspect → Scan → Approve → Install → Configure → Bind → Activate → Observe → Update or Rollback

Different Skills may require different approval boundaries

A read-only documentation Skill is not the same as a Skill that can send email modify files call cloud APIs or execute local scripts

The platform may eventually need to make that difference visible

5 External compatibility

Nexent already has useful native capabilities

• NL-to-Skill
• parameter schemas
• version management
• Agent-level configuration
• script execution
• import and export

I do not think these should be replaced by the lowest common standard

A more interesting direction may be

Standard Skill package → compatibility adapter → Nexent metadata → security review → managed runtime

This would allow Nexent to accept external Skills while still preserving its own control plane

What changes architecturally

The important shift may be this

A Skill is no longer only reusable knowledge
It becomes a managed capability asset

Once that happens the platform needs to know not only what the Skill teaches

But also

• how it executes
• what it depends on
• what it can access
• who approved it
• which Agents use it
• which version is active
• how it behaves after installation
• how it can be disabled or rolled back

That feels like the layer above individual Skill creation and Skill Market

Not only managing Skill files

But governing a growing capability ecosystem

The question

If Nexent continues in this direction what should become explicit first

• Skill execution types
• dependency and runtime contracts
• discovery metadata
• permission and trust levels
• external compatibility
• lifecycle observation
• something else

I increasingly feel that the next difference between Agent platforms may not be who supports more Skills

But who can keep a growing Skill ecosystem understandable portable and governable

---

从 Skill 管理走向 Skill 生态控制平面

我在 #2179 里第一次讨论 Skills 时

核心问题还是 Skills 应该如何与 Sub-agent 分层

现在 Nexent 已经向前走了很多

Skills 可以通过自然语言生成
可以按需加载
可以携带脚本和配置
可以管理草稿与发布版本
可以导入导出并绑定到不同 Agent

所以现在的问题已经不再是

Nexent 要不要支持 Skills

而开始变成

当 Skills 形成生态以后 平台应该显式化什么

最近实际测试了几类公开 Skill 实现

最明显的差异不是哪个生态的 Skill 更多

而是它们已经不再共享同一种执行方式

有些 Skill 主要是指令

有些包装现成 CLI

有些自带 Python 或 Shell 脚本

有些依赖平台 Runtime API

还有一些主要负责搜索 发现和安装其他 Skills

它们都可能使用 SKILL.md

但从运行角度看 已经是完全不同的系统对象

1 执行模型

Skill 是否应该显式声明自己的运行方式

例如

• instruction
• cli
• script
• runtime
• composite
• registry

这样平台才能区分一个轻量指令包

和一个能够执行代码 访问网络或依赖外部 Runtime 的能力包

2 运行契约

一个可复用 Skill 可能不只需要描述和工具列表

它还可能需要声明

• 依赖的二进制程序
• 环境变量
• 认证方式
• 操作系统兼容性
• Python Node 或 Shell 版本
• 网络访问
• 文件系统访问
• 外部服务
• 可能产生的副作用

走到这里以后

Skill 不只是告诉 Agent 应该怎么做

也开始声明这项能力在什么条件下才能安全运行

3 发现模型

当平台只有少量 Skills 时 普通列表已经足够

当数量增长以后 发现机制本身就会成为架构的一部分

Skill 索引未来可能需要理解

• tags
• triggers
• category
• language
• service
• dependencies
• execution model
• permissions
• compatibility
• source
• version
• trust level

这已经不只是搜索

而是 Runtime 之前的能力路由

4 信任生命周期

现有 Skill Market 和上传安全检查已经开始触碰这个方向

但安全可能不会在上传扫描以后结束

完整生命周期可能更像

发现 → 检查 → 扫描 → 审批 → 安装 → 配置 → 绑定 → 激活 → 观察 → 更新或回滚

不同 Skill 也应该具有不同的审批边界

只读文档 Skill

和能够发送邮件 修改文件 调用云 API 或执行本地脚本的 Skill

不应该被视为同一种风险对象

平台可能需要把这种差异显式呈现出来

5 外部兼容层

Nexent 已经拥有很多有价值的原生能力

• NL-to-Skill
• 参数 Schema
• 版本管理
• Agent 级配置
• 脚本执行
• 导入与导出

这些能力不应该为了兼容最低标准而被削弱

一个更有意思的方向可能是

通用 Skill 包 → 兼容适配 → Nexent 原生元数据 → 安全审查 → 托管运行

这样既能接收外部 Skills

又能保留 Nexent 自己的控制平面能力

真正的架构变化

最重要的变化可能是

Skill 不再只是可复用知识
而开始成为可管理的能力资产

到了这一步

平台需要知道的不只是 Skill 教了什么

还包括

• 它如何执行
• 它依赖什么
• 它能够访问什么
• 谁批准了它
• 哪些 Agent 正在使用
• 当前激活的是哪个版本
• 安装以后运行状态如何
• 出现问题时如何禁用或回滚

这可能是 Skill 创建和 Skill Market 之上的下一层

不是只管理 Skill 文件

而是治理一个持续增长的能力生态

最后的问题

如果 Nexent 继续沿着这个方向发展

最先应该显式化的是哪一层

• Skill 执行类型
• 依赖与运行契约
• 发现元数据
• 权限与信任等级
• 外部兼容
• 生命周期观察
• 还是其他部分

我越来越感觉

下一代 Agent 平台真正的差异

可能不是谁拥有更多 Skills

而是谁能让持续增长的 Skill 生态始终保持可理解 可迁移和可治理