主题摘要

这组素材真正有价值的判断，不是“发现了一个恶意 weather skill”，而是指出 agent skill 生态本质上已经是供应链安全问题。只要 skill 同时携带可执行说明和高权限访问能力，未签名、无权限清单、无审计轨迹的生态就迟早出事。

今日关键信息

• Skill.md 在 agent 场景里不是无害文档。它一旦被纳入执行上下文，就可能影响模型行为、工具调用顺序、权限使用边界和外部访问路径。

• 真正的风险不只来自单个恶意作者，还来自缺失 provenance。你不知道 skill 是谁写的、是否被篡改、是否经过审计，也不知道今天安装的版本和昨天讨论的版本是不是同一个东西。

• 权限问题不能靠“使用者自己小心”解决。因为大多数风险不是在阅读文案时暴露，而是在 agent 获得文件、网络、密钥、消息等真实能力后才显现。用户看到的是安装说明，系统承受的是供应链后果。

• 如果没有 permission manifest，就无法在安装前回答最基本的问题：这个 skill 需要哪些能力，为什么需要，超出范围时是否会被阻止。如果没有 audit trail，出了问题也很难追溯是哪个 skill、哪个版本、通过什么链路触发了异常行为。

共识

分歧

我的判断

推荐角度 / 值得继续观察的点

• 别把 Skill.md 当说明文档；它在 agent 生态里更像未签名二进制。没有 provenance 和 permission manifest，就不该默认安装。

• 没说透的角度：大家常把 risk 放在“恶意作者”，但更深的问题是产品默认把高权限扩展包装成低门槛安装体验。

• 可以继续往下写三个层面。第一，产品层：安装页应该先展示权限和来源，而不是先展示效果和评分。第二，平台层：skill 分发需要签名、版本锁定、撤回机制和安全通告。第三，运行层：agent 需要把 skill 的执行影响纳入日志、回放和隔离策略，而不是只记录最终输出。

来源列表

• src_20260331_moltbook_001

• src_20260331_moltbook_007

后续行动 / 待验证点

1. 继续拆解 skill 生态里最该先做的四层治理：签名、权限清单、溯源、审计。

2. 补一版更偏产品/平台设计的检查表：安装前展示什么，运行时记录什么，出事后如何撤回。