企业官网建设流程全解析

前段时间有个粉丝面滴滴，二面聊到 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 读整个 context，A 的结果已经在里面了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 依赖 B，B 又依赖 A——这种情况在模块化系统里面是个经典的工程噩梦。Java 项目里面的循环 import、微服务里面的服务互调，都踩过这个坑。

但是在 md-skill 的架构下面呢，这个问题天然就不存在。

原因其实很简单：context 是单向追加的，执行顺序是线性的，没有任何机制能让"已经执行完的 skill"回过头来等待后面的结果。

这并不是什么精心设计出来的防护措施——而是线性执行模型附带的一个好处。真正需要保证的呢，是规划层不要把 A、B 排进一个相互等待的死循环里面去。这属于规划逻辑的职责范围，不是 skill 文件自身能解决的问题。

◆ ◆ ◆

7. 总结

六种依赖类型，解法几乎都指向同一个核心：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%免费】