前言前段时间圈子里有人去面滴滴二面聊到 Agent 系统设计他项目里做了好几个 skill 串起来跑面试官就顺着问了一句“你做了一堆 skill它们之间怎么传数据的或者说怎么建立依赖的”他想了想说把前面 skill 的结果放进 context后面的 skill 读整个 context 就能拿到了。面试官点点头又追问那如果 skill 数量多了context 越来越长怎么办模型还能注意到中间的信息吗他愣了一下说可以做摘要压缩。面试官继续追“那执行顺序谁来管版本更新了怎么回滚有些操作要先鉴权怎么保证”——他发现自己一个都答不利索。其实每个点他都在项目里遇到过但从来没系统梳理过。这是很多人做 skill 编排的通病能跑就行没想过依赖关系到底有几种、每种怎么解。这篇文章就把 skill 之间的依赖关系彻底拆清楚。读完你能搞明白skill 之间到底有几种依赖关系不是只有数据传递这一种context 作为唯一信息通道它的边界和坑在哪执行顺序、版本管理、权限鉴权这三类依赖的工程解法为什么循环依赖在 md-skill 架构下天然不存在架构师视角的 skill 编排工程取舍和面试高分话术不管你是正在准备大厂 Agent 岗面试的求职者还是在一线做 Agent 系统开发的工程师这篇都能帮你把 skill 编排从直觉拉到机制层面。开拆一、skill 编排从能跑就行到能管得住先说一个很多 Agent 开发者会碰到的场景你做了几个 skill——一个查用户信息、一个发邮件、一个写日报——把它们串起来跑发现效果还行。于是你觉得 skill 编排不过如此就是前一个的输出当后一个的输入嘛。但一旦 skill 数量从 3 个涨到 10 个、20 个问题就全冒出来了执行顺序谁定中间结果怎么传版本更新了旧流程怎么办有些操作需要先鉴权怎么保证这些都不是能跑就行能糊弄过去的。面试官问怎么传数据、怎么建立依赖表面上是在问数据传递实际上是在考你对整个编排系统的认知深度。只答出放 context 里是 60 分能系统说出 6 种依赖类型 每种的解法 各自的边界才是 90 分。先上一张全景图把 6 种依赖关系列清楚依赖类型核心问题解法方向数据依赖后面的 skill 怎么拿到前面的结果结果追加进 context顺序依赖先跑哪个后跑哪个文件名前缀 / 规划层动态决策工具依赖skill 需要的数据库/API/环境信息从哪来context 开头注入环境快照版本依赖skill 更新了旧流程怎么办文件名带版本号保留历史权限依赖某些操作要先鉴权auth skill 固定第一个跑循环依赖A 依赖 B、B 又依赖 A线性执行天然避免你会发现6 种依赖的解法几乎都指向同一个核心context 是 skill 之间唯一的信息通道。管好 context 的内容和顺序大多数依赖问题就自然解了。下面逐个拆。二、数据依赖context 是唯一的信息通道两个 skill 之间最常见的关系就是后面那个需要前面那个的输出结果才能接着往下干活。这种依赖其实不需要什么复杂的状态管理机制。最直接的办法把 A 的执行结果追加到共享的 context 里B 调用时把整个 context 一并带上它自然就能读到 A 的结果。context 用户请求发邮件给 Alice\n\n # 执行 skill A查收件人信息 result_a call_llm(skills[fetch_user] \n\n上下文\n context) context f[fetch_user 结果]\n{result_a}\n\n # 执行 skill B发邮件读整个 contextA 的结果已经在里面了 result_b call_llm(skills[send_email] \n\n上下文\n context)这里有个非常值得注意的边界context 会随着 skill 链条增长变得越来越长。研究者把这种现象叫“lost-in-the-middle”——模型更容易注意到 context 开头和结尾的内容中间那段信息容易被忽视掉。面试官追问context 越来越长怎么办就是想看你有没有意识到这个边界。应对方式如果 skill 数量多、context 累积很长可以在追加新内容之前先对之前的结果做一轮摘要压缩。不是把所有历史原样保留而是提炼出关键信息再往下传。这跟人类开会记纪事是一个道理——你不需要记住每个人说的原话只需要记住结论和待办。数据依赖的要点context 追加是最朴素的解法但它有天花板。当链条超过 5-7 个 skill摘要压缩就不再是可选项而是必选项。三、执行顺序依赖文件名前缀与动态规划的分界线知道该跑哪些 skill 是一回事知道先跑哪个又是另一回事。执行顺序依赖有两种解法适用场景完全不同方案一让大模型在规划阶段自己决定。适合 skill 数量多、执行路径因用户输入不同而产生分叉的场景。模型根据当前 context 动态判断下一步该调哪个 skill。灵活但不够透明——你很难从外部一眼看出执行逻辑。方案二文件名加数字前缀按文件名排序。适合执行路径相对固定的场景01_fetch_user.md 02_send_email.md 03_write_log.md这个方案的好处是极其透明——执行逻辑从文件列表里一眼就能看清楚不依赖任何隐含的规划逻辑。面试时能说出这个方案至少说明你认真想过执行顺序的问题不是全靠模型自己猜。但它有明显的边界当 skill 数量增长到几十个、执行路径因为用户输入不同而产生分叉时静态的数字前缀就不够用了。这时候才真正需要让规划层去做动态决策。工程判断不要一上来就上动态规划。如果你的业务流程相对固定数字前缀的透明性远比动态规划的灵活性值钱。等到分叉多了再上规划层不要过早设计。四、工具与环境依赖依赖注入思维有些 skill 需要连数据库有些需要调外部 API还有些需要知道当前登录用户是谁。这些环境信息如果缺失skill 轻则报错重则静默失败——什么也不说就出问题了。解法在 context 的最开头注入一段环境快照让后续所有 skill 都能读到这些信息context f 环境信息 - 数据库已连接 - 当前用户admin - API 状态正常 用户请求{user_request} 这个思路跟软件工程里的**“依赖注入”**是一脉相承的——不让 skill 自己去猜测或获取环境信息而是由外部统一注入进去。好处是 skill 本身保持无状态换一个环境只需要改注入内容skill 逻辑一行都不用动。但有一个安全坑必须留意注入进 context 的内容会被大语言模型完整读取。业内有研究发现debug 日志里出现的 API 密钥和 token有相当比例会通过这个路径泄露出去——因为 agent 框架习惯把 stdout 直接喂进 context window。所以环境信息里如果有敏感字段注入前必须做脱敏处理或者替换为占位符。真正需要用密钥的地方走代码层面的变量传递不要让它进 context。五、版本依赖别让覆盖写入吃掉你的回滚能力Skill 文件不是一成不变的。提示词会更新、行为会调整、边界条件会修复——这些变动都会产生新版本而旧版本可能还在被某些流程引用着。最简单的版本管理方式文件名里带版本号Agent 加载时取最新的那个。send_email_v1.md send_email_v2.md ← 用这个这个方案的实际价值不只是用新不用旧——更关键的是它保留了历史版本。当新版本的行为出了问题可以快速回滚到 v1 做对比不需要去猜我到底改了什么。相比之下如果 skill 文件直接覆盖写入、不留历史调试时就没有基准可以参照排查问题的成本会高出不少。这在工程上叫丢失了可回溯性——你以为是在维护一个文件实际上是在烧掉自己的调试线索。版本依赖的要点文件名带版本号看起来土但它同时解决了用新不用旧和出问题能回滚两个需求。不要嫌它简单简单本身就是优势——任何人看一眼文件列表就知道当前在用哪个版本、历史改过几版。六、权限依赖auth skill 永远第一个跑某些操作需要先确认身份——如果不做鉴权就直接跑到发邮件那一步要么报错要么更糟糕静默执行了不该执行的动作。处理方式把 auth skill 固定为第一个执行的步骤后续的 skill 从 context 里读取鉴权结果比如 token# 永远第一个执行 context call_llm(skills[auth] \n\n user_request) # 后续 skill 从 context 里拿 token这里有个隐性假设值得说清楚auth skill 的结果被追加进了 context而 context 本身是明文传递给大语言模型的。如果 token 不需要模型去理解、只需要在 API 调用时附上更安全的做法是把 token 放在 Python 变量这一层不让它进入 context只在实际发起外部请求时才读取。这个区分很关键——context 里的信息是给模型看的代码变量里的信息是给程序用的。鉴权 token 属于后者不该让模型看到更不该让它有机会在生成文本时把 token 吐出来。这跟前面环境依赖里说的密钥脱敏是同一个原则敏感信息走代码通道不走 context 通道。七、循环依赖线性执行模型的天然护城河A 依赖 BB 又依赖 A——这种情况在模块化系统里是个经典的工程噩梦。Java 项目里的循环 import、微服务里的服务互调都踩过这个坑。但在 md-skill 的架构下这个问题天然就不存在。原因很简单context 是单向追加的执行顺序是线性的没有任何机制能让已经执行完的 skill回过头来等待后面的结果。这不是什么精心设计的防护措施而是线性执行模型附带的一个好处。不过有一点需要保证规划层不要把 A、B 排进一个相互等待的死循环里。这属于规划逻辑的职责范围不是 skill 文件自身能解决的。换句话说循环依赖在 skill 执行层面被线性模型自然规避了但在 skill 规划层面仍需要人来把关——如果你的规划层是 LLM 驱动的得确保它不会生成A 等 B、B 等 A的执行计划。循环依赖的要点线性执行是天然护城河但护的是执行层不是规划层。规划层的死循环风险得靠规划逻辑自己防。八、从架构师视角看 skill 编排的几个工程取舍前面把 6 种依赖类型拆完了都偏认知。但作为一个做工程落地的人更关心的是在真实项目里skill 编排还有哪些容易被忽略、却最影响结果的工程取舍1. context 不是垃圾桶它是一个有容量的注意力预算。很多人把 context 当成万能口袋——环境信息、历史结果、debug 日志、中间状态全往里塞。但 context 的本质是模型的注意力预算塞进去的每一段都在跟其他段抢注意力。context 越长模型对关键信息的注意力越稀释。工程上的做法是分层管理核心信息放前面、中间结果做摘要、debug 日志走代码通道不进 context。2. 静态排序和动态规划不是二选一而是分层组合。很多团队纠结用文件名前缀还是让 LLM 动态规划其实这两者不矛盾。工程上更稳的做法是两层组合外层用文件名前缀固定主干流程01_auth → 02_fetch → 03_process → 04_output内层在每个 skill 内部让 LLM 根据输入动态决定具体执行路径。主干不动枝叶灵活。3. 版本管理不只是文件名带版本号还要管谁在引用哪个版本。文件名带版本号解决了保留历史的问题但如果 v1 还在被流程 A 引用、v2 已经被流程 B 采用了你得知道哪些流程还在用旧版。别只管版本号不管依赖图。一个简单的做法是在每个 skill 文件头部加一行# used_by: flow_A, flow_B手动维护引用关系。土但有效。4. 鉴权不只是 auth skill 第一个跑还要管 token 的生命周期。auth skill 跑完拿到 token但 token 会过期。如果你的 skill 链条跑了一半 token 失效了后面的操作会静默失败。工程上得有 token 刷新机制——要么在每次调用前检查有效期要么把 token 刷新做成一个可被中途调用的 skill。别假设 auth 跑一次就一劳永逸。5. 摘要压缩不是删字数是保信息密度。context 太长时做摘要压缩很多人的做法是让 LLM “总结一下前面的内容”。但摘要本身会丢失信息——你无法保证 LLM 摘要时保留的恰好是后续 skill 需要的。更稳的做法是结构化摘要不是让模型自由发挥而是按固定模板提取——“已完成步骤”“关键结果”“待处理事项”“环境状态”——把摘要变成结构化数据减少信息丢失。6. skill 编排的终极原则能不传就不传能晚传就晚传。context 里的信息越少模型的注意力越集中。不是每个 skill 都需要看到完整的 context 历史。最小权限原则在 skill 编排里同样适用——给每个 skill 只传它完成当前任务所需的最小 context而不是一股脑把整个历史都塞过去。九、面试话术考官想听的是什么这道题面试官到底想听什么分三层来说。第一层基本认知——能说出不止一种依赖回答分数问题在哪“把结果放 context 里就行”60 分只答了数据依赖没意识到还有其他 5 种“context 传数据 文件名排顺序”70 分答了两种但缺版本/权限/循环“6 种依赖数据/顺序/工具/版本/权限/循环”85 分覆盖全但缺少边界讨论“6 种依赖 每种的解法 边界 工程取舍”90 分有系统框架 有实战深度第二层细节追问——面试官会往下挖的点面试官点头后大概率会追问这几个方向“context 越来越长怎么办”→ 答 lost-in-the-middle 现象 摘要压缩别只说做摘要三个字要说清楚为什么需要摘要注意力稀释。“执行顺序谁管”→ 答静态前缀 动态规划分层组合别一上来就说让 LLM 自己决定——那是 60 分答案。“token 安全怎么保证”→ 答敏感信息走代码通道不走 context 通道这是区分会用和用得好的分水岭。“循环依赖怎么办”→ 答线性执行天然规避执行层循环但规划层要防死循环——答出这个层次区分基本就稳了。第三层设计哲学——一句话升华如果面试官最后问你觉得 skill 编排的核心挑战是什么高分回答是“skill 编排的核心挑战不是怎么传数据而是怎么管 context 的注意力预算。context 是 skill 之间唯一的信息通道但它是一个有容量限制的通道——管好这个通道的内容、顺序和安全边界是 skill 编排从’能跑’到’能管’的关键。”这句话把数据依赖、顺序依赖、安全依赖全部串到了一个统一的框架里比逐个列举 6 种依赖更有高度。面试官想听的就是这种从列举到抽象的能力。总结把全文收一下核心就这么几条skill 之间的依赖关系不止数据传递一种完整说有 6 种数据依赖、执行顺序依赖、工具/环境依赖、版本依赖、权限依赖、循环依赖。只答出第一种是 60 分。6 种依赖的解法几乎都指向同一个核心context 是 skill 之间唯一的信息通道。结果追加进 context、环境快照注入 context 开头、auth 结果从 context 读取——管好 context 的内容和顺序大多数依赖问题自然解。context 不是垃圾桶是注意力预算。lost-in-the-middle 现象决定了 context 越长模型对中间信息的注意力越低。链条超过 5-7 个 skill 时摘要压缩从可选项变成必选项。敏感信息走代码通道不走 context 通道。API 密钥、鉴权 token 这些东西不该让模型看到更不该让它有机会在生成文本时吐出来。循环依赖在执行层被线性模型天然规避但规划层的死循环风险仍需人来把关——线性执行护的是执行层不是规划层。静态排序和动态规划不是二选一而是分层组合外层用文件名前缀固定主干内层让 LLM 在每个 skill 内部动态决策。最后留一句话给你skill 编排的终极原则不是怎么传而是能不能不传——最小权限原则在 context 管理里同样适用给每个 skill 只传它完成当前任务所需的最小 context。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
滴滴二面追问：你做了一堆 skill，它们之间怎么传数据、怎么建立依赖？
前言前段时间圈子里有人去面滴滴二面聊到 Agent 系统设计他项目里做了好几个 skill 串起来跑面试官就顺着问了一句“你做了一堆 skill它们之间怎么传数据的或者说怎么建立依赖的”他想了想说把前面 skill 的结果放进 context后面的 skill 读整个 context 就能拿到了。面试官点点头又追问那如果 skill 数量多了context 越来越长怎么办模型还能注意到中间的信息吗他愣了一下说可以做摘要压缩。面试官继续追“那执行顺序谁来管版本更新了怎么回滚有些操作要先鉴权怎么保证”——他发现自己一个都答不利索。其实每个点他都在项目里遇到过但从来没系统梳理过。这是很多人做 skill 编排的通病能跑就行没想过依赖关系到底有几种、每种怎么解。这篇文章就把 skill 之间的依赖关系彻底拆清楚。读完你能搞明白skill 之间到底有几种依赖关系不是只有数据传递这一种context 作为唯一信息通道它的边界和坑在哪执行顺序、版本管理、权限鉴权这三类依赖的工程解法为什么循环依赖在 md-skill 架构下天然不存在架构师视角的 skill 编排工程取舍和面试高分话术不管你是正在准备大厂 Agent 岗面试的求职者还是在一线做 Agent 系统开发的工程师这篇都能帮你把 skill 编排从直觉拉到机制层面。开拆一、skill 编排从能跑就行到能管得住先说一个很多 Agent 开发者会碰到的场景你做了几个 skill——一个查用户信息、一个发邮件、一个写日报——把它们串起来跑发现效果还行。于是你觉得 skill 编排不过如此就是前一个的输出当后一个的输入嘛。但一旦 skill 数量从 3 个涨到 10 个、20 个问题就全冒出来了执行顺序谁定中间结果怎么传版本更新了旧流程怎么办有些操作需要先鉴权怎么保证这些都不是能跑就行能糊弄过去的。面试官问怎么传数据、怎么建立依赖表面上是在问数据传递实际上是在考你对整个编排系统的认知深度。只答出放 context 里是 60 分能系统说出 6 种依赖类型 每种的解法 各自的边界才是 90 分。先上一张全景图把 6 种依赖关系列清楚依赖类型核心问题解法方向数据依赖后面的 skill 怎么拿到前面的结果结果追加进 context顺序依赖先跑哪个后跑哪个文件名前缀 / 规划层动态决策工具依赖skill 需要的数据库/API/环境信息从哪来context 开头注入环境快照版本依赖skill 更新了旧流程怎么办文件名带版本号保留历史权限依赖某些操作要先鉴权auth skill 固定第一个跑循环依赖A 依赖 B、B 又依赖 A线性执行天然避免你会发现6 种依赖的解法几乎都指向同一个核心context 是 skill 之间唯一的信息通道。管好 context 的内容和顺序大多数依赖问题就自然解了。下面逐个拆。二、数据依赖context 是唯一的信息通道两个 skill 之间最常见的关系就是后面那个需要前面那个的输出结果才能接着往下干活。这种依赖其实不需要什么复杂的状态管理机制。最直接的办法把 A 的执行结果追加到共享的 context 里B 调用时把整个 context 一并带上它自然就能读到 A 的结果。context 用户请求发邮件给 Alice\n\n # 执行 skill A查收件人信息 result_a call_llm(skills[fetch_user] \n\n上下文\n context) context f[fetch_user 结果]\n{result_a}\n\n # 执行 skill B发邮件读整个 contextA 的结果已经在里面了 result_b call_llm(skills[send_email] \n\n上下文\n context)这里有个非常值得注意的边界context 会随着 skill 链条增长变得越来越长。研究者把这种现象叫“lost-in-the-middle”——模型更容易注意到 context 开头和结尾的内容中间那段信息容易被忽视掉。面试官追问context 越来越长怎么办就是想看你有没有意识到这个边界。应对方式如果 skill 数量多、context 累积很长可以在追加新内容之前先对之前的结果做一轮摘要压缩。不是把所有历史原样保留而是提炼出关键信息再往下传。这跟人类开会记纪事是一个道理——你不需要记住每个人说的原话只需要记住结论和待办。数据依赖的要点context 追加是最朴素的解法但它有天花板。当链条超过 5-7 个 skill摘要压缩就不再是可选项而是必选项。三、执行顺序依赖文件名前缀与动态规划的分界线知道该跑哪些 skill 是一回事知道先跑哪个又是另一回事。执行顺序依赖有两种解法适用场景完全不同方案一让大模型在规划阶段自己决定。适合 skill 数量多、执行路径因用户输入不同而产生分叉的场景。模型根据当前 context 动态判断下一步该调哪个 skill。灵活但不够透明——你很难从外部一眼看出执行逻辑。方案二文件名加数字前缀按文件名排序。适合执行路径相对固定的场景01_fetch_user.md 02_send_email.md 03_write_log.md这个方案的好处是极其透明——执行逻辑从文件列表里一眼就能看清楚不依赖任何隐含的规划逻辑。面试时能说出这个方案至少说明你认真想过执行顺序的问题不是全靠模型自己猜。但它有明显的边界当 skill 数量增长到几十个、执行路径因为用户输入不同而产生分叉时静态的数字前缀就不够用了。这时候才真正需要让规划层去做动态决策。工程判断不要一上来就上动态规划。如果你的业务流程相对固定数字前缀的透明性远比动态规划的灵活性值钱。等到分叉多了再上规划层不要过早设计。四、工具与环境依赖依赖注入思维有些 skill 需要连数据库有些需要调外部 API还有些需要知道当前登录用户是谁。这些环境信息如果缺失skill 轻则报错重则静默失败——什么也不说就出问题了。解法在 context 的最开头注入一段环境快照让后续所有 skill 都能读到这些信息context f 环境信息 - 数据库已连接 - 当前用户admin - API 状态正常 用户请求{user_request} 这个思路跟软件工程里的**“依赖注入”**是一脉相承的——不让 skill 自己去猜测或获取环境信息而是由外部统一注入进去。好处是 skill 本身保持无状态换一个环境只需要改注入内容skill 逻辑一行都不用动。但有一个安全坑必须留意注入进 context 的内容会被大语言模型完整读取。业内有研究发现debug 日志里出现的 API 密钥和 token有相当比例会通过这个路径泄露出去——因为 agent 框架习惯把 stdout 直接喂进 context window。所以环境信息里如果有敏感字段注入前必须做脱敏处理或者替换为占位符。真正需要用密钥的地方走代码层面的变量传递不要让它进 context。五、版本依赖别让覆盖写入吃掉你的回滚能力Skill 文件不是一成不变的。提示词会更新、行为会调整、边界条件会修复——这些变动都会产生新版本而旧版本可能还在被某些流程引用着。最简单的版本管理方式文件名里带版本号Agent 加载时取最新的那个。send_email_v1.md send_email_v2.md ← 用这个这个方案的实际价值不只是用新不用旧——更关键的是它保留了历史版本。当新版本的行为出了问题可以快速回滚到 v1 做对比不需要去猜我到底改了什么。相比之下如果 skill 文件直接覆盖写入、不留历史调试时就没有基准可以参照排查问题的成本会高出不少。这在工程上叫丢失了可回溯性——你以为是在维护一个文件实际上是在烧掉自己的调试线索。版本依赖的要点文件名带版本号看起来土但它同时解决了用新不用旧和出问题能回滚两个需求。不要嫌它简单简单本身就是优势——任何人看一眼文件列表就知道当前在用哪个版本、历史改过几版。六、权限依赖auth skill 永远第一个跑某些操作需要先确认身份——如果不做鉴权就直接跑到发邮件那一步要么报错要么更糟糕静默执行了不该执行的动作。处理方式把 auth skill 固定为第一个执行的步骤后续的 skill 从 context 里读取鉴权结果比如 token# 永远第一个执行 context call_llm(skills[auth] \n\n user_request) # 后续 skill 从 context 里拿 token这里有个隐性假设值得说清楚auth skill 的结果被追加进了 context而 context 本身是明文传递给大语言模型的。如果 token 不需要模型去理解、只需要在 API 调用时附上更安全的做法是把 token 放在 Python 变量这一层不让它进入 context只在实际发起外部请求时才读取。这个区分很关键——context 里的信息是给模型看的代码变量里的信息是给程序用的。鉴权 token 属于后者不该让模型看到更不该让它有机会在生成文本时把 token 吐出来。这跟前面环境依赖里说的密钥脱敏是同一个原则敏感信息走代码通道不走 context 通道。七、循环依赖线性执行模型的天然护城河A 依赖 BB 又依赖 A——这种情况在模块化系统里是个经典的工程噩梦。Java 项目里的循环 import、微服务里的服务互调都踩过这个坑。但在 md-skill 的架构下这个问题天然就不存在。原因很简单context 是单向追加的执行顺序是线性的没有任何机制能让已经执行完的 skill回过头来等待后面的结果。这不是什么精心设计的防护措施而是线性执行模型附带的一个好处。不过有一点需要保证规划层不要把 A、B 排进一个相互等待的死循环里。这属于规划逻辑的职责范围不是 skill 文件自身能解决的。换句话说循环依赖在 skill 执行层面被线性模型自然规避了但在 skill 规划层面仍需要人来把关——如果你的规划层是 LLM 驱动的得确保它不会生成A 等 B、B 等 A的执行计划。循环依赖的要点线性执行是天然护城河但护的是执行层不是规划层。规划层的死循环风险得靠规划逻辑自己防。八、从架构师视角看 skill 编排的几个工程取舍前面把 6 种依赖类型拆完了都偏认知。但作为一个做工程落地的人更关心的是在真实项目里skill 编排还有哪些容易被忽略、却最影响结果的工程取舍1. context 不是垃圾桶它是一个有容量的注意力预算。很多人把 context 当成万能口袋——环境信息、历史结果、debug 日志、中间状态全往里塞。但 context 的本质是模型的注意力预算塞进去的每一段都在跟其他段抢注意力。context 越长模型对关键信息的注意力越稀释。工程上的做法是分层管理核心信息放前面、中间结果做摘要、debug 日志走代码通道不进 context。2. 静态排序和动态规划不是二选一而是分层组合。很多团队纠结用文件名前缀还是让 LLM 动态规划其实这两者不矛盾。工程上更稳的做法是两层组合外层用文件名前缀固定主干流程01_auth → 02_fetch → 03_process → 04_output内层在每个 skill 内部让 LLM 根据输入动态决定具体执行路径。主干不动枝叶灵活。3. 版本管理不只是文件名带版本号还要管谁在引用哪个版本。文件名带版本号解决了保留历史的问题但如果 v1 还在被流程 A 引用、v2 已经被流程 B 采用了你得知道哪些流程还在用旧版。别只管版本号不管依赖图。一个简单的做法是在每个 skill 文件头部加一行# used_by: flow_A, flow_B手动维护引用关系。土但有效。4. 鉴权不只是 auth skill 第一个跑还要管 token 的生命周期。auth skill 跑完拿到 token但 token 会过期。如果你的 skill 链条跑了一半 token 失效了后面的操作会静默失败。工程上得有 token 刷新机制——要么在每次调用前检查有效期要么把 token 刷新做成一个可被中途调用的 skill。别假设 auth 跑一次就一劳永逸。5. 摘要压缩不是删字数是保信息密度。context 太长时做摘要压缩很多人的做法是让 LLM “总结一下前面的内容”。但摘要本身会丢失信息——你无法保证 LLM 摘要时保留的恰好是后续 skill 需要的。更稳的做法是结构化摘要不是让模型自由发挥而是按固定模板提取——“已完成步骤”“关键结果”“待处理事项”“环境状态”——把摘要变成结构化数据减少信息丢失。6. skill 编排的终极原则能不传就不传能晚传就晚传。context 里的信息越少模型的注意力越集中。不是每个 skill 都需要看到完整的 context 历史。最小权限原则在 skill 编排里同样适用——给每个 skill 只传它完成当前任务所需的最小 context而不是一股脑把整个历史都塞过去。九、面试话术考官想听的是什么这道题面试官到底想听什么分三层来说。第一层基本认知——能说出不止一种依赖回答分数问题在哪“把结果放 context 里就行”60 分只答了数据依赖没意识到还有其他 5 种“context 传数据 文件名排顺序”70 分答了两种但缺版本/权限/循环“6 种依赖数据/顺序/工具/版本/权限/循环”85 分覆盖全但缺少边界讨论“6 种依赖 每种的解法 边界 工程取舍”90 分有系统框架 有实战深度第二层细节追问——面试官会往下挖的点面试官点头后大概率会追问这几个方向“context 越来越长怎么办”→ 答 lost-in-the-middle 现象 摘要压缩别只说做摘要三个字要说清楚为什么需要摘要注意力稀释。“执行顺序谁管”→ 答静态前缀 动态规划分层组合别一上来就说让 LLM 自己决定——那是 60 分答案。“token 安全怎么保证”→ 答敏感信息走代码通道不走 context 通道这是区分会用和用得好的分水岭。“循环依赖怎么办”→ 答线性执行天然规避执行层循环但规划层要防死循环——答出这个层次区分基本就稳了。第三层设计哲学——一句话升华如果面试官最后问你觉得 skill 编排的核心挑战是什么高分回答是“skill 编排的核心挑战不是怎么传数据而是怎么管 context 的注意力预算。context 是 skill 之间唯一的信息通道但它是一个有容量限制的通道——管好这个通道的内容、顺序和安全边界是 skill 编排从’能跑’到’能管’的关键。”这句话把数据依赖、顺序依赖、安全依赖全部串到了一个统一的框架里比逐个列举 6 种依赖更有高度。面试官想听的就是这种从列举到抽象的能力。总结把全文收一下核心就这么几条skill 之间的依赖关系不止数据传递一种完整说有 6 种数据依赖、执行顺序依赖、工具/环境依赖、版本依赖、权限依赖、循环依赖。只答出第一种是 60 分。6 种依赖的解法几乎都指向同一个核心context 是 skill 之间唯一的信息通道。结果追加进 context、环境快照注入 context 开头、auth 结果从 context 读取——管好 context 的内容和顺序大多数依赖问题自然解。context 不是垃圾桶是注意力预算。lost-in-the-middle 现象决定了 context 越长模型对中间信息的注意力越低。链条超过 5-7 个 skill 时摘要压缩从可选项变成必选项。敏感信息走代码通道不走 context 通道。API 密钥、鉴权 token 这些东西不该让模型看到更不该让它有机会在生成文本时吐出来。循环依赖在执行层被线性模型天然规避但规划层的死循环风险仍需人来把关——线性执行护的是执行层不是规划层。静态排序和动态规划不是二选一而是分层组合外层用文件名前缀固定主干内层让 LLM 在每个 skill 内部动态决策。最后留一句话给你skill 编排的终极原则不是怎么传而是能不能不传——最小权限原则在 context 管理里同样适用给每个 skill 只传它完成当前任务所需的最小 context。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
