只需安装一个安全路由入口就能根据任务自动选择、组合可信 Skill并生成可验证的执行方案。30 秒理解这个项目你不再需要从社区里逐个挑选、检查和搭配 Skill。安装 safe-agent-router 作为统一入口直接描述任务它会从经过治理的可信目录中选择方法、组合工作流并生成执行图再交给宿主 Agent 按自身权限执行。AI Agent 的 Skill 生态正在快速扩张。今天你可以为 Agent 安装网页开发 Skill、代码审查 Skill、浏览器自动化 Skill、SEO Skill、PDF Skill、邮件 Skill、发布 Skill甚至可以找到几十种功能相近但实现方式完全不同的版本。这看起来意味着 Agent 越来越强。但真正使用一段时间后很多人会遇到另一组问题我应该为自己的场景安装哪些 Skill同类 Skill 有十几个哪一个更可靠社区 Skill 里的命令安全吗Skill 会不会要求读取密钥、执行 Shell或者绕过权限限制一个任务需要多个 Skill 时应该先用哪个、后用哪个两个 Skill 的能力重叠时应该保留谁执行结束后谁来负责测试、验证和发布检查安装的 Skill 越来越多会不会让 Agent 的上下文越来越混乱用户真正想完成的事情可能很简单帮我构建一个官网检查代码和 Skill 路由质量验证通过后发布。但在传统 Skill 使用方式下用户往往需要先成为半个 Skill 专家。这正是我们开发Safe-Agent-Skills和Hybrid Router v2的原因。我们不希望用户先学习整个 Skill 市场再手动安装和搭配几十个 Skill。我们希望用户只保留一个可信入口然后直接描述自己想完成什么。路由器负责回答三个问题这个任务实际上包含哪些意图应该选择哪些可信 Skill 和场景工作流它们应该以什么顺序执行在哪里验证哪些动作需要宿主批准一、Skill 越多Agent 不一定越可靠很多 Agent 系统仍采用一种非常直接的扩展方式需要什么能力就安装一个 Skill。如果任务比较复杂就继续安装更多 Skill。需要开发网页 → 安装网页开发 Skill需要设计界面 → 安装 UI Skill需要浏览器验证 → 安装 Playwright Skill需要 SEO → 安装 SEO Skill需要安全检查 → 安装安全审计 Skill需要发布 → 安装部署 Skill这种方式在 Skill 数量较少时还能工作。当 Skill 数量增加以后问题会从“缺少能力”转变为“能力治理失控”。1. 用户很难判断应该安装什么用户通常知道自己的业务目标却不知道目标应该映射到哪些技术能力。“建设一个产品官网”背后可能同时需要需求整理页面结构设计视觉一致性响应式实现SEO 内容浏览器截图验证构建检查发布检查。要求普通用户自己发现并组合这些 Skill本身就是一种额外负担。2. 社区 Skill 不等于可信 Skill一个 Skill 受欢迎、Star 很多不能自动证明它适合进入受控 Agent 环境。社区 Skill 中可能出现curl | bash 一类远程下载执行未限制的 Shell 或解释器调用读取环境变量、Token 或密钥的指令要求绕过沙箱或审批流程对整个文件系统的宽泛访问将工具权限当作 Skill 自身权限含糊不清的来源、许可证或版本信息。即使 Skill 没有恶意它也可能不适合你的宿主环境。3. Skill 之间会重复、冲突和相互覆盖多个 Skill 可能都声称自己可以“审查代码”“优化 UI”或“完成发布”。如果把它们全部塞进 Agent 上下文可能出现重复执行相同检查对同一问题给出不同流程一个 Skill 要求先发布另一个要求先审计验证步骤被实现步骤覆盖上下文不断膨胀真正重要的边界反而被稀释。4. 找到 Skill 不等于完成编排即使已经选对 Skill复杂任务仍然存在依赖关系。例如构建网站 ──┐ ├─→ 验证通过 ─→ 发布 审计路由器 ─┘发布不能只等待网站构建完成也不能只等待路由审计完成。它必须同时依赖两条工作流的验证结果。这已经不是简单的关键词匹配问题而是一个工作流编译问题。二、传统方式安装、检查、组合全靠用户自己如果完全依赖人工用户通常要经历这样的流程flowchart LR A[描述业务目标] -- B[搜索社区 Skill] B -- C[阅读多个 SKILL.md] C -- D[判断来源与安全性] D -- E[逐个安装] E -- F[处理重复和冲突] F -- G[手动安排执行顺序] G -- H[补充测试与验证] H -- I[执行任务]这条链路的问题在于真正需要完成业务任务的人被迫承担了 Skill 发现、供应链审查、能力建模和工作流编排四种额外角色。我们希望把这条链路收敛成flowchart LR A[安装一个可信路由入口] -- B[直接描述目标] B -- C[自动拆解任务] C -- D[选择可信 Skill] D -- E[组合场景工作流] E -- F[生成执行与验证 DAG] F -- G[交给宿主 Agent 执行]用户不再需要先回答“我要安装哪十个 Skill”。用户只需要回答我想完成什么三、一个可信入口不是一个万能执行器Safe-Agent-Skills 提供的核心入口是safe-agent-router它的职责不是亲自完成所有操作而是成为 Skill 生态的统一选择和编排入口。更准确地说它是一个可信 Skill 选择器 场景工作流组合器 执行计划编译器。当用户提交任务后路由器会解析当前任务与相关上下文将复合任务拆解成多个意图从可信场景目录中检索候选工作流过滤非可信 Skill 和无效引用组合多个场景生成全局依赖 DAG添加验证门、完成门和审批标记输出给 Codex、Claude Code 或其他宿主 Agent 使用的 Task Pack。它不会因为选中了某个 Skill就自动获得 Shell、网络、浏览器、账号或发布权限。这些权限始终属于宿主运行时。flowchart TB U[用户任务] -- R[Safe Agent Router] R -- I[多意图拆解] I -- S[可信场景与 Skill 选择] S -- D[全局 DAG 与验证门] D -- P[Task Pack] P -- H[宿主 Agent] H -- A{宿主权限与审批} A --|允许| T[工具执行] A --|拒绝或缺失| B[等待审批或阻断] R -.不授予权限.- A因此“只安装一个 Skill”真正代表的是只安装一个可信入口不再手工维护大量零散社区 Skill具体方法由路由器按任务从可信目录中选择具体执行仍由宿主控制。四、可信从哪里来先治理 Skill 供应链再讨论自动选择如果路由器只是从未经治理的社区 Skill 中随机挑选那么“自动选择”反而会放大风险。Safe-Agent-Skills 的第一层能力不是智能路由而是 Skill 供应链治理。1. 记录来源而不是只复制内容每个进入目录的 Skill 都需要尽可能记录来源类型来源地址或本地路径作者或所有者许可证来源提交文件清单内容哈希导入时间Skill 与来源之间是导入、参考还是本地创作关系。缺失的信息会被明确记录为未知而不是直接省略。2. 在信任之前进行风险扫描系统会对 Skill 内容进行确定性的预检识别包括但不限于破坏性 Shell 命令混淆后的远程执行下载后立即执行密钥或 Token 形态字符串环境变量和凭据外传权限提升与策略绕过未限制的文件系统访问。扫描结果是审计证据不只是一个提示框。3. 将方法与执行权限分离社区 Skill 里有价值的部分通常是方法什么时候使用需要什么输入应该按什么流程处理应该输出什么如何验证结果。危险部分往往是把这些方法与直接执行命令、扩大权限或绕过策略绑定在一起。Safe-Agent-Skills 会保留方法移除或隔离不应由 Skill 决定的执行权限。4. 默认只路由到 trusted Skill目录中的 Skill 有明确状态。正常任务默认只使用可信 Skill。来源不完整、分类不确定、内容存在风险或仍需人工确认的 Skill不会因为关键词匹配成功就自动进入执行计划。这是一种失败关闭策略宁可报告能力缺失也不使用一个无法证明可信的 Skill 顶替。五、路由器如何理解一个真实复合任务我们使用下面这条任务作为 Hybrid Router v2 的强制验收案例构建官网同时审计 Skill 路由器验证通过后发布更新这句话至少包含三个不同意图构建官网审计 Skill 路由器在前面的工作验证通过后发布更新。Hybrid Router v2 最终选择了三个可信场景website-build-launchskill-router-quality-reviewopen-source-release随后它将这些场景编译为一个全局执行图30 个节点31 条依赖边图状态为 ready图结构无环7 个节点被标记为需要宿主动作或审批。可以把简化后的结构理解为flowchart LR W1[网站需求与实现] -- W2[网站测试与浏览器验证] R1[路由器结构审计] -- R2[路由质量与安全验证] W2 -- G[发布前验证门] R2 -- G G -- P[开源发布与更新]发布工作流同时依赖网站路径和路由审计路径。这说明系统做的不是看到“官网” → 找一个网页 Skill而是识别多个意图为每个意图选择可信场景合并场景中的 Skill建立跨场景依赖插入验证与完成门标记需要宿主权限的节点输出统一 Task Pack六、Contract v2让 Skill 不只是自然语言说明书仅靠一份自由格式的 SKILL.md很难可靠完成自动编排。Hybrid Router v2 引入了结构化 Contract用于描述 Skill 的关键编排属性例如stage_hintSkill 适合处于哪个阶段capability_vectorSkill 提供哪些能力requires_context需要哪些上下文produces_artifacts会产生哪些交付物produces_evidence会产生哪些验证证据requires_after依赖哪些前置 Skillconflicts_with与哪些 Skill 冲突approval_classes涉及哪些宿主审批类型retry_policy重试应如何由宿主决定。这让路由器可以区分一个 Skill 是负责规划、执行、审查还是验证哪些能力是强制的哪些步骤不能提前执行哪些动作涉及 Shell、网络、浏览器或发布权限某个任务包是否缺少必要能力。需要注意的是Contract 仍然不会授予权限。例如approval_classes 包含 shell_execution只意味着宿主应该将节点视为需要审批的动作而不是允许 Skill 自己执行 Shell。七、为什么选择确定性路由而不是一开始就全部交给 LLMHybrid Router v2 当前采用确定性路由而不是让大模型自由决定所有 Skill 和依赖。这样做有几个原因。1. 结果更容易复现相同任务、相同目录和相同配置应尽量得到相同的意图、场景和执行图。系统会为关键路由输入生成经过敏感信息清理的稳定 route_id便于审计和比较。2. 决策过程更容易解释候选场景、选择结果、缺失能力、阻断原因和图依赖都可以被结构化输出。3. 安全边界更容易证明确定性规则可以明确保证只选择可信场景不引用未知 Skill