跳转至

Skill 编排的 6 种依赖关系

📊 Level ⭐⭐⭐ | 7.4KB

摘要

系统性梳理多 Skill Agent 系统中的 6 种依赖关系：数据依赖（context 传递）、顺序依赖（前缀 vs 动态规划）、工具/环境依赖（注入思维）、版本依赖（文件名版号）、权限依赖（auth 优先）、循环依赖（线性天然免疫）。核心原则：context 是 skill 之间唯一的信息通道；敏感信息走代码变量层不走 context。

核心要点

  1. 数据依赖：context 追加是朴素解法，超过 5-7 个 skill 需摘要压缩，应对 lost-in-the-middle
  2. 顺序依赖：固定流程用文件名数字前缀（01_/02_），分叉路径用动态规划层——不要过早设计
  3. 工具依赖：依赖注入——context 开头注入环境快照，skill 保持无状态；密钥脱敏避免通过 context 泄露
  4. 版本依赖：文件名带版本号（v1/v2），同时解决「用新不用旧」和「可回溯回滚」两个需求
  5. 权限依赖：auth skill 永远第一个跑，但鉴权 token 不进 context（模型可见）——通过代码变量层传递

深度分析

context 作为唯一信息通道的双刃剑

context 的追加式增长是所有 skill 编排方案的基础假设，但它的天花板在实践中被低估：5-7 个 skill 后，模型对中间信息的关注度急剧下降。摘要压缩不是可选项，而是必选项。

敏感信息的「通道选择」

文章区分了「给模型看的」和「给程序用的」两条通道：context 是前者，代码变量是后者。API 密钥、鉴权 token 等敏感信息应走后者，避免模型在生成回复时意外泄露。这一原则在工具环境依赖和权限依赖中都将复用。

依赖类型的耦合与演化

6 种依赖在文章里是分类呈现的，但它们在真实链条中并不独立：数据依赖是其余五种的放大器。当每个 skill 都把完整结果追加进 context，链条上第 n 个 skill 面对的不只是长度问题，而是前面所有 skill 的决策痕迹——顺序依赖的「先跑谁」、版本依赖的「用的是哪一版」、权限依赖的「auth 结果是什么」都被压进同一段文本。需要调整顺序或替换某个版本时，必须回溯整条 context 才能判断影响面，这正是「文件改名」类小改动在多 skill 链条里变得昂贵的根源。可行的做法是把数据依赖显式化：只传「下一跳需要的最小契约」（字段名与语义），而不是全量中间产物，让上下文长度与链条长度解耦。这与 Harness Engineering 把各层职责边界写清是同一个思路。

静态前缀排序与动态规划层的边界

文件名数字前缀（01_/02_/03_）本质是把执行图冻结在命名空间里：顺序对人和对调试器都可见，出错时能按编号定位到具体一环。动态规划层的代价恰恰在这里——它把顺序藏进运行时的决策逻辑，可观测性下降一个量级，需要额外的 trace 才能回答「这次为什么走了这条路径」。文章给出的判据是「不要过早设计」，只有当执行路径真正分叉、且分叉点依赖运行时输入时才值得引入规划层。判据还可以更严一点：如果所有分支的集合能在设计期穷举，就让它保持为多条静态链条，而不是一个动态规划器——静态链条的每一支都是可 grep、可 diff、可单测的。

循环依赖的「假免疫」

文章指出线性执行天然避免循环：context 单向追加，不存在回溯。但这个免疫是结构性假设换来的，不是靠检查得来的。一旦为了分叉能力引入动态规划层，执行顺序由规划器在运行时决定，「A 触发 B、B 又触发 A」就重新成为可达状态；而这类循环通常表现为上下文无限膨胀或同一个 skill 被反复调用，而不是显式的栈溢出，因而更难被察觉。因此规划层需要同时携带显式依赖声明——每个 skill 声明它需要什么、产出什么——由编排器在派发前做一次可达性检查，把线性模型里的隐式保证补回到动态模型里。这与 阿里 Java 案例 中把编排约束落到显式声明而非隐式约定的做法一致。

第 6 类之外的隐性依赖

文章列出的 6 类依赖有一个共同前提：依赖都表达在 skill 文件与 context 上。真实系统里还有一类不在清单上的依赖——共享文件、环境变量、临时目录、全局配置这类隐式全局状态。两个 skill 各自看都无状态，实际却通过同一个路径的文件或同一个环境变量耦合，链条顺序一改行为就变。这类依赖的麻烦在于它逃过了「context 是唯一信息通道」的审计口径：既不进 context，也不出现在任何依赖声明里，只在特定顺序下才暴露。纳入管理的方式与工具依赖一致——在 context 开头显式注入环境快照，并禁止 skill 读写约定之外的全局资源。

敏感信息通道的失效回流路径

文章的原则是敏感信息走代码变量层、不走 context。这条原则在多 skill 链条里最容易被间接路径击穿：密钥本身没进 context，但它出现在 debug 日志、工具返回值的错误消息或异常堆栈里，被当作「工具输出」追加回上下文，一次鉴权失败的错误信息就可能把 token 片段带进下一跳。因此通道分离必须覆盖所有回流路径——工具返回值要脱敏、错误消息要分类、日志默认不进 context，而不仅是「别把 token 写进 prompt」。这也解释了为什么权限依赖（auth 第一个跑）与工具/环境依赖在安全维度上其实是同一个问题的两个入口。

实践启示

  1. 固定的多 skill 流程先用数字前缀排序——透明可读，比动态规划更值钱
  2. 超过 5-7 个 skill 的链条必须考虑摘要压缩
  3. 敏感信息走代码变量层，不走 context 层
  4. 文件名版本号是简单但有效的版本管理——保留历史才有回滚能力

关联