前段时间有个粉丝面滴滴二面聊到 Agent 系统设计他项目里做了好几个 skill 串起来跑面试官就顺着问了一句你做了一堆 skill它们之间怎么传数据的或者说怎么建立依赖的他想了想说把前面 skill 的结果放进 context后面的 skill 读整个 context 就能拿到了。面试官点点头又问那如果 skill 数量多了context 越来越长怎么办模型还能注意到中间的信息吗他愣了一下说可以做摘要压缩。面试官继续追问那执行顺序谁来管版本更新了怎么回滚有些操作要先鉴权怎么保证他发现自己一个都答不利索其实每个点他都在项目里遇到过但从来没系统梳理过。这个问题很典型——很多人做 skill 编排都是能跑就行没想过依赖关系到底有几种、每种怎么解。今天就把这个说清楚。1. 数据依赖两个 skill 之间最常见的一种关系呢就是后面的 skill 需要前面那个的输出结果才能接着往下干活。这种情况的话其实不需要什么复杂的状态管理机制。最直接的办法是什么呢就是把 A 的执行结果追加到共享的 context 里面去然后 B 调用的时候把整个 context 一并带上它自然就能读到 A 的结果了。context 用户请求发邮件给 Alice\n\n# 执行 Aresult_a call_llm(skills[fetch_user] \n\n上下文\n context)context f[fetch_user 结果]\n{result_a}\n\n# B 读整个 contextA 的结果已经在里面了result_b call_llm(skills[send_email] \n\n上下文\n context)这里有个值得一提的点哈context 会随着 skill 链条的增长变得越来越长。研究者们把这种现象叫做lost-in-the-middle——也就是说呢模型其实更容易注意到 context 开头和结尾部分的内容反而中间那一段的信息就比较容易被忽视掉。这也是为什么面试官会追问context 越来越长怎么办——他想看你有没有意识到这个边界。所以嘛如果 skill 数量比较多、context 累积得很长的话可以考虑在追加新内容之前先对之前的结果做一轮摘要压缩。这样子做的话效果会好一些。◆ ◆ ◆2. 执行顺序依赖知道该跑哪些 skill 是一回事知道先跑哪个又是另一回事了。一种做法呢是让大语言模型在规划阶段自己来决定执行顺序。另一种就更简单粗暴一些了——直接在 md 文件名前面加上数字前缀然后按文件名排序排出来的顺序就是执行顺序。01_fetch_user.md02_send_email.md这个方案的好处在哪里呢就是它很透明。执行逻辑从文件列表里一眼就能看清楚不依赖任何隐含的规划逻辑。面试的时候如果能说出这个方案至少说明你认真想过执行顺序的问题不是全靠模型自己猜。不过呢它也有比较明显的边界情况。当 skill 的数量增长到几十个、执行路径因为用户输入不同而产生分叉的时候光靠静态的数字前缀就不够用了。到了这种时候才真正需要让规划层去做动态的决策。◆ ◆ ◆3. 工具/环境依赖有些 skill 需要连接数据库有些需要去调用外部的 API还有些需要知道当前登录的用户是谁。这些环境信息如果缺失的话skill 轻则会返回错误重则可能静默失败——也就是啥也不说就出问题了。解决方式是什么呢就是在 context 的最开头注入一段环境快照让后续所有 skill 都能读到这些信息。context f环境信息- 数据库已连接- 当前用户admin- API 状态正常用户请求{user_request}这个思路其实跟软件工程里面的依赖注入是类似的——不让 skill 自己去猜测或者自己去获取环境信息而是由外部统一注入进去。有一点需要留意哈注入进 context 的内容会被大语言模型完整读取。今年有研究发现debug 日志里面出现的 API 密钥和 token有相当比例会通过这个路径泄露出去。原因是什么呢就是因为 agent 框架习惯把 stdout 直接喂进 context window 里面。所以嘛环境信息里如果有敏感字段的话记得在注入之前做一下脱敏处理或者替换为占位符。◆ ◆ ◆4. 版本依赖Skill 文件不是一成不变的。提示词会更新、行为会调整、边界条件会修复——这些变动都会产生新的版本而旧版本可能还在被某些流程引用着。最简单的版本管理方式是什么呢就是在文件名里面带上版本号Agent 加载的时候取最新的那个就行。send_email_v1.mdsend_email_v2.md ← 用这个这个方案的实际价值呢不只是用新不用旧这么简单更关键的是它保留了历史版本。当新版本的行为出了问题的时候可以快速回滚到 v1 来进行对比不需要去猜我到底改了什么。相比之下如果 skill 文件直接覆盖写入、不留历史的话调试的时候就没有基准可以参照排查问题的成本会高出不少。◆ ◆ ◆5. 权限依赖某些操作需要先确认身份——如果不做鉴权就直接跑到发邮件那一步要么会报错要么更糟糕的是可能静默执行了不该执行的动作。处理方式是什么呢就是把 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只在实际发起外部请求的时候才去读取。◆ ◆ ◆6. 循环依赖A 依赖 BB 又依赖 A——这种情况在模块化系统里面是个经典的工程噩梦。Java 项目里面的循环 import、微服务里面的服务互调都踩过这个坑。但是在 md-skill 的架构下面呢这个问题天然就不存在。原因其实很简单context 是单向追加的执行顺序是线性的没有任何机制能让已经执行完的 skill回过头来等待后面的结果。这并不是什么精心设计出来的防护措施——而是线性执行模型附带的一个好处。真正需要保证的呢是规划层不要把 A、B 排进一个相互等待的死循环里面去。这属于规划逻辑的职责范围不是 skill 文件自身能解决的问题。◆ ◆ ◆7. 总结依赖类型解法数据依赖结果追加进 context顺序依赖文件名加数字前缀工具依赖context 开头注入环境信息版本依赖文件名带版本号权限依赖auth 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%免费】