本文深入探讨了 Agent Skills 框架的设计技巧与实战经验，旨在解决单一智能体能力单一的问题。通过将能力模块化、设计 Pipeline 架构、采用三层上下文管理、实现渐进式上下文披露等策略，有效提升了智能体的执行效率与任务处理能力。文章详细解析了 Skill 的设计、上下文流转、规则引擎与 LLM 的结合等关键点，并对比了 Agent Skills 与 Multi-Agent 的优劣，为开发者提供了一套实用且高效的智能体设计思路。

---

如何让单一智能体也能拥有多种能力？本文聊聊 Agent Skills 框架设计中那些值得反复琢磨的设计技巧与实战经验

---

一、从一个问题场景说起

程序员老张今年 45 岁，拿到体检报告后一脸懵——空腹血糖 7.2、甘油三酯 2.8、尿酸 520、谷丙转氨酶 52……十几项指标密密麻麻，红色箭头此起彼伏。他想知道三件事：

1. 这些数字到底什么意思？（数据解析）
2. 我有哪些健康风险？（风险评估）
3. 接下来该怎么办？（建议生成）

如果你是 AI 工程师，接到这个需求会怎么设计？

最直觉的做法：写一个超长 Prompt，让 LLM 一口气从解析到建议全搞定。Demo 能跑，但到了生产环境——Prompt 越来越长，token 爆炸；某一步算错，整个输出全废；想换个风险评估策略，得改整条 Prompt，牵一发动全身。

那上 Multi-Agent？三个 Agent 各管一摊、互相通信？也不是不行，但你会发现：三步是严格串行的，后一步依赖前一步的输出，压根不需要"协商"和"并行"——Multi-Agent 引入的通信协议、独立 Memory、A2A协调开销，在这个场景下全是多余的复杂度。

我们真正需要的是：把大任务拆成标准化的小技能，用一个编排器按序调度，共享同一份上下文。 这就是 Agent Skills 要解决的事——用 Anthropic 的话说，真正的突破不是造更多的智能体，而是将能力以模块化方式沉淀，让单一智能体成为可复用能力的执行引擎。

一个简单的类比：如果 Multi-Agent 是多进程——各自独立内存、靠 IPC 通信、隔离性好但开销大；那 Agent Skills 就是同一进程下的多线程——共享内存、轻量调度、按需执行不同功能。不是说谁更好，而是看你的问题需要隔离还是共享。

Agent Skills 可以理解为 通用 Agent 的扩展包，Agent 可以通过加载不同的 Skills 包，来具备不同专业知识、工具使用能力，稳定的完成特定的任务

---

二、自研架构：Skills 框架的 Pipeline 设计

目前社区 Google ADK、Deep Agent 等框架已经集成了 Skill 设计，如果你期望自己动手开发一个 Agent Skills 框架时，那么整个框架的设计思路可以用一句话概括：一个协调器统一调度，多个 Skills 各司其职，三层上下文贯穿始终

五个核心角色的职责很清楚：

角色	职责
AgentContext	三层结构化上下文，贯穿整个流程的"信息中枢"
Planner	理解用户意图，把大任务拆成小步骤
Executor	逐步执行每个 Skill，管理多种执行模式
Synthesizer	把多步结果综合为连贯的自然语言回答
Coordinator	串联以上所有角色的调度中心

Pipeline 本身不复杂。但框架真正的设计功力，藏在几个关键问题的解法里。

---

三、Skill = 一个文件夹，而非一个 Agent

在讨论编排之前，先回答一个根本性的问题：一个 Skill 到底长什么样？

一个 Skill 就是一个目录。放进 skills/ 文件夹，框架自动发现、自动注册——零配置，即插即用：

skills/parse_report/├── SKILL.md           # 必需：元数据 + 使用文档（YAML front matter）├── prompt.template    # 可选：Prompt 模板└── executor.py        # 可选：自定义执行逻辑

SKILL.md 的 YAML front matter 定义了 Skill 的身份——名字、描述、触发词、标签。Planner 正是读这些描述来决定选哪个 Skill：

name: parse_report_skilldescription: 解析体检报告原始数据，提取并分类各项检验指标triggers:  - 体检报告  - 体检数据  - 化验单tags:  - 健康  - 体检

Skill 的执行有三种模式，Executor 按优先级依次检测：

1. 有 executor.py → 走自定义执行器（可以混合规则引擎 + LLM，后面详述）
2. 有 prompt.template → 填充模板后调用 LLM
3. 都没有 → 把 SKILL.md 的文档部分作为 system prompt，直接调用 LLM

这个设计的关键在于：Skill 是被动的。 它不是一个有自主意识的 Agent——不需要自己的 Memory、自己的规划能力、自己的通信协议。它只需要满足一个简单的契约：给我输入，我返回输出。

Everything is a Tool 原则

现实中一个 Skill 可能需要调用 API、检索知识库、执行计算脚本。这些异构能力如何统一管理？框架遵循 Everything is a Tool 原则——无论是 API 调用、知识 Source 检索还是代码 Script 执行，都可以抽象为 Tool，在 SKILL.md 中声明绑定：

# Available Tools## 1. check_reference_range工具名称: Calculation Tool工具用途: 检查指标是否在参考范围内工具输入: indicator_name, value工具返回: status, deviation_percent

这让 Skill 的能力描述和执行逻辑彻底解耦——框架不关心你调的是 API 还是本地函数，它只看到"Tool"这一层统一抽象。

---

四、上下文设计—— Skills 框架的「大脑结构」

这是整个框架最精巧的部分，也是区别于"把所有信息塞进一个 dict"的核心设计。

问题：多步执行中，信息传递会变成一锅粥

在链式执行中，信息的种类很杂：用户说了什么、Planner 规划了什么、第 1 步输出了什么、第 2 步又输出了什么、系统有哪些 Skill 可用、token 预算还剩多少……如果全部扁平地扔进一个字典，很快会失控——谁写的、谁能读、什么时候写的，全部混在一起，调试时根本无从下手。

解法：把上下文切成三层，每层职责分明

每个组件只操作自己需要的层：

• Planner 读 用户输入层（用户要什么）+ Skill配置信息层（有哪些 Skill），写回 用户输入层（拆解后的意图 + Skill 的步骤计划）
• Executor 逐步 读/写 工作记忆层（这里存的是每一个Skill执行的输入和输出）
• Synthesizer 读 用户输入层 + 工作记忆层 的累积结果，用于生成最终回答

这种分层带来三个好处：

• 职责边界清晰——每层存什么、谁能写，一目了然，杜绝组件间的数据越权
• 增量更新——每个 Skill 执行完只写自己那一小块，不需要拼全量上下文
• 全链路可审计——每次读写操作自动记入审计日志：

def _audit(self, layer, op, key, source, detail=""):    entry = AuditEntry(        timestamp=datetime.now().isoformat(),        layer=layer,      # user_input | scratchpad | environment        op=op,            # read | write | delete | compress        key=key,        source=source,    # planner / skill:parse_report / coordinator    )    self._audit_log.append(entry)

出了 bug？看一眼审计日志：谁在什么时间读了什么、写了什么，一目了然。当用户问"为什么建议我少吃海鲜？"你能追溯到完整因果链：parse_report_skill 发现尿酸 520 偏高 → assess_risk_skill 判定代谢风险中等 → generate_advice_skill 生成了限嘌呤饮食建议。

---

五、渐进式上下文披露—— Skills 框架的灵魂

这是我认为整个框架最核心的设计，也是踩坑最多之后才想清楚的。

问题：全量灌入 = 精度下降 + Token 爆炸

最初的做法很朴素：第一步给原始 user_input，后续步骤把整个 Scratchpad 拼成字符串传入。结果——

1. 第一步精度下降：用户说"帮我解析报告并评估风险再给建议"，如果把这整句话原封不动传给 parse_report_skill，它不知道自己只需要做"解析"这一件事，容易跑偏
2. Token 爆炸式增长：步骤越多拼接越长，第三步可能收到几千字符的前置信息，LLM 在海量上下文中迷路

解法：每一步只看到最小必要上下文

核心理念：不区分"第一步"和"后续步骤"，统一通过同一个方法构建输入。每个步骤收到的输入由三部分组成：

用一个例子说清楚。用户说：“帮我解析体检报告并评估风险再给出建议。” 如果步骤 3（generate_advice_skill）收到的主指令还是这整句话，它不知道该做解析、评估还是建议。但如果收到的是 Planner 分解出的 sub_task——“基于解析数据和风险评估，生成个性化健康建议”——职责就非常清晰了

压缩策略 遵循一个直觉——越新的步骤输出越重要：

1. 始终保留：原始请求（LLM 不能忘记用户到底要什么）
2. 完整保留：最新一步的输出（当前步骤通常直接依赖它）
3. 可截断：较早的步骤输出（加"…已压缩"标记）
4. 可丢弃：已被后续步骤消化吸收的最早步骤

结果是：Token 消耗线性增长而非指数增长，永远不会因为上下文过长导致 API 报错。

---

六、Skills 之间的数据如何流动

当多个 Skill 形成链式执行时，前一步的输出如何稳定、可控地传给下一步？这个问题看似简单，细想起来有两个难点。

双通道传递：结构化字典 + 文本回退

框架设计了两条并行的数据通道：

• **通道 1（文本通道）😗*自动将前置步骤的文本输出拼入参考信息——这是渐进式上下文机制自然产生的
• 通道 2（字典通道）：通过共享字典传递结构化数据 context["parsed_report_skill"]、context["assess_risk_skill"]

通道 2 是首选——结构化 JSON 完整、无歧义，executor 可以直接 context["parsed_report_skill"]["result"] 取值，不需要从文本里正则提取。但并非所有 Skill 都产出结构化数据（比如纯 LLM 对话型 Skill），这时通道 1 兜底，保证链路不断。

历史 Session 只传一次

另一个关键决策：只有第一步传历史对话 Session，后续步骤不传。

原因：第一步已经基于历史生成了结构化结果，后续步骤通过渐进式上下文拿到这些结果——它们已经是对历史的"提炼版本"。每个 Skill 再塞一遍原始历史，是纯粹的 token 浪费。

---

七、规则引擎 + LLM：双执行引擎的设计

这个设计值得单独讲，因为它体现了一个重要理念——能确定的事情绝不让 LLM 猜。

以 parse_report_skill 为例，它的 executor 不是简单地把数据丢给 LLM：

def execute(llm, user_input, context):    raw = context.get("raw_report")    # ---- 规则引擎：确定性计算 ----    bmi = calculate_bmi(height, weight)    bmi_category = classify_bmi(bmi)    bp_category = classify_blood_pressure(sbp, dbp)    for item in raw["lab_items"]:        status, deviation = check_indicator(value, ref_low, ref_high)    # ---- LLM：自然语言生成 ----    summary = llm.invoke("请用 2-3 句话概括体检结果...")    return {规则计算结果 + LLM 摘要}

“空腹血糖 7.2 超出参考范围 3.9-6.1，偏高 18.0%”——查表就能 100% 准确。让 LLM 来算？它可能说 15%，也可能说 20%——你敢把这种不确定性放进健康建议吗？

但"受检者血糖控制欠佳，需注意糖尿病前期风险"这样的表述，LLM 写得比规则引擎好得多。

规则引擎负责「准」，LLM 负责「智」，各取所长：

Skill	规则引擎做什么 – 执行确定性代码	LLM 做什么 – 调用模型生成
parse_report	BMI 计算、血压分级、15 项指标逐一比对参考范围	生成 2-3 句体检概况摘要
assess_risk	按心血管/代谢/肝脏/肾脏四维度加权评分	生成 3-5 句风险推理说明
generate_advice	基于风险分和异常指标生成建议框架	生成总结摘要、复查计划、注意事项

---

八、Planner Skills的规划与容错

Planner 是整条链路的入口，如果它出了问题，后面全白做。框架在这里设计了两层保护。

Plan 模式：一次性生成完整计划

把所有可用 Skill 的描述传给 LLM，让它一次性输出步骤序列。每个步骤包含 Skill 名称、子任务描述和置信度——低于 0.5 的步骤自动过滤，避免 LLM 硬凑不靠谱的步骤。

RePlan 模式：执行中动态重规划

当某一步失败时，不是直接报错崩溃，而是启动 ReAct 风格的重规划——LLM 看到"原始请求 + 当前执行状态 + 失败原因"，做出三选一决策：

重试时也通过重新构建输入——Scratchpad 里已经记录了失败信息，重构后的输入会自动包含错误上下文，帮助 LLM 避开同样的坑。

---

演示：一次完整的链式执行过程

用户说：「帮我分析体检报告并给出建议。」

Phase 0 — 初始化上下文、加载 Skills

| __main__ — Skills 目录: /xxx/agent-design-sample/AgentSkills/skills| utils.skill_loader — 已加载 Skill: <Skill 'assess_risk' triggers=['风险评估', '健康风险', '疾病风险', '风险分析', '健康评分'] modes=0>| utils.skill_loader — 已加载 Skill: <Skill 'generate_advice' triggers=['健康建议', '调理建议', '怎么改善', '注意事项', '保健方案', '体检建议'] modes=0>| utils.skill_loader — 已加载 Skill: <Skill 'parse_report' triggers=['体检报告', '体检数据', '解析报告', '检验结果', '化验单', '体检解读'] modes=0>| utils.skill_loader — 共发现 3 个 Skill: ['assess_risk', 'generate_advice', 'parse_report']| __main__ — 已加载 3 个 Skill: ['assess_risk', 'generate_advice', 'parse_report']

Phase 1 — Planner 规划 Skills

Planner 收到用户输入 + 可用 Skill 列表，调用 LLM 生成计划：

{  "intent": "体检报告全流程分析",  "steps": [    {"skill": "parse_report","sub_task": "解析体检报告数据","confidence": 0.95},    {"skill": "assess_risk","sub_task": "评估健康风险","confidence": 0.92},    {"skill": "generate_advice", "sub_task": "生成个性化健康建议","confidence": 0.90}  ]}

Phase 2 — 链式执行 Skill

• 步骤 1 parse_report_skill 是链的起点——规则引擎完成 BMI、血压、指标比对等确定性计算，LLM 负责生成摘要，结果通过字典通道（context[“parse_report_skill”]）和文本通道（Layer2.step_1）同时输出

• 步骤 2 assess_risk_skill 优先从字典通道读取步骤 1 的结构化数据，规则引擎按心血管/代谢/肝脏/肾脏四维度加权评分，LLM 生成风险推理说明

• 步骤 3 generate_advice_skill 同时消费前两步的结构化输出，规则引擎生成具体建议条目，LLM 包装为自然语言摘要和复查计划

Phase 3 — 最终返回

• Synthesizer 综合输出 读取 Layer1 原始请求 + Layer2 三步结果，不是机械拼接，而是像医生一样生成连贯的自然语言回答：「根据您的体检报告，总体来看……需要重点关注的是……建议您……」

---

Agent Skills 与 Multi-Agent 的对比

最后简要做一个对比，帮助读者在实际工程中做出选择。

对比维度	Agent Skills	Multi-Agent
核心范式	单体智能体 + 可扩展能力模块	多智能体系统 + 任务分发与协作
上下文	共享，渐进式披露，精准裁剪	隔离，各 Agent 独立上下文，通过消息传递
通信成本	低——所有"思考"在单次模型调用内部完成	高——每次 Agent 间调用都是独立模型调用
调试	审计日志 + 结构化追踪，因果链一目了然	需翻消息日志，跨 Agent 问题定位困难
典型 token 消耗	6,000 - 10,000	15,000 - 25,000
适合场景	线性串行、依赖链清晰、单模型可覆盖	需要并行/对抗/异构模型/信息隔离

两者不是非黑即白。选择取决于你的任务需要"强化个人"还是"建设团队"：

• 任务是线性流程、各步依赖前步输出 → Skills
• 需要多角色对抗/辩论/并行 → Multi-Agent
• 需要调用不同特性的模型 → Multi-Agent
• 涉及隐私/信息隔离 → Multi-Agent
• 技能数量极大（50-100+）→ 考虑分层 Skills 或转向 Multi-Agent

---

十二、设计原则提炼

回头看这个框架，五条原则值得带走：

1. Skill 上下文隔离 — 用户输入、工作记忆、环境信息各自独立，每个组件只操作自己需要的层。这不只是代码整洁，更是防止多步执行中信息混乱的根本手段；

2. Skill 渐进式披露 — 每一步只看到最小必要上下文：自己的 sub_task + 累积的前置结果。Token 消耗线性增长而非指数增长。这是控制成本和保证精度的关键；

3. Skill 结构化契约 — Skills 之间用 TypedDict schema 定义数据格式，不是自由文本传话。字典通道优先、文本通道兜底，兼顾精度和灵活性；

4. Skill 执行引擎 — 确定性计算交给代码，自然语言生成交给 LLM。各取所长，杜绝"让 LLM 做计算"的不确定性风险；

5. Skill 全链路可审计 — 每次 read / write / compress 操作自动记录。不是锦上添花，是生产环境的刚需——你必须能解释 AI 为什么给出这个建议；

---

写在最后

Agent 框架的设计，本质上是在选择正确的抽象层次：

• 太低（纯 LLM 调用）：所有逻辑塞在一个 Prompt 里，不可维护
• 太高（Multi-Agent）：引入了通信、协商、一致性等你可能不需要的复杂度
• 刚好（Coordinator + Skills）：有结构化的编排，但没有过度的抽象

Claude 的 Artifacts、Cursor 的 Agent 模式，本质上都是这个思路——一个核心循环，按需调用不同的能力模块。

Multi-Agent 是手段，不是目的。 当你的任务是确定性的线性流程时，一个好的编排器 + 一组设计良好的 Skills，就是最优解。

就像程序员老张的体检报告——不需要三个医生会诊，一个主治医生按流程做就好。关键是流程清晰、数据准确、每一步可追溯。这就是 Agent 设计的手艺。

---

附：项目源码结构

AgentSkills/├── main.py                    # 入口脚本（交互/Demo）├── config.py                  # 全局配置├── agent/                     # 核心 Agent 组件│   ├── coordinator.py         # 协调器（主循环）│   ├── context.py             # 三层上下文管理器│   ├── scratchpad.py          # 结构化工作记忆│   ├── planner.py             # 任务规划器│   ├── executor.py            # Skill 执行器│   └── synthesizer.py         # 结果综合器├── skills/                    # Skills（即插即用）│   ├── parse_report/          # 体检数据解析│   ├── assess_risk/           # 健康风险评估│   └── generate_advice/       # 健康建议生成├── shared/                    # 共享工具 & Schema│   ├── context_schema.py      # TypedDict 数据契约│   └── metrics_utils.py       # 健康指标计算工具├── utils/                     # 框架工具│   ├── skill_loader.py        # Skill 自动发现与加载│   ├── skill_registry.py      # Skill 注册表│   └── model_client.py        # LLM 调用封装└── dialogue/                  # 对话管理    ├── manager.py             # 会话管理器    └── protocol.py            # 请求/响应协议

AI时代，未来的就业机会在哪里？

答案就藏在大模型的浪潮里。从ChatGPT、DeepSeek等日常工具，到自然语言处理、计算机视觉、多模态等核心领域，技术普惠化、应用垂直化与生态开源化正催生Prompt工程师、自然语言处理、计算机视觉工程师、大模型算法工程师、AI应用产品经理等AI岗位。

掌握大模型技能，就是把握高薪未来。

那么，普通人如何抓住大模型风口？

AI技术的普及对个人能力提出了新的要求，在AI时代，持续学习和适应新技术变得尤为重要。无论是企业还是个人，都需要不断更新知识体系，提升与AI协作的能力，以适应不断变化的工作环境。

因此，这里给大家整理了一份《2026最新大模型全套学习资源》，包括2026最新大模型学习路线、大模型书籍、视频教程、项目实战、最新行业报告、面试题、AI产品经理入门到精通等，带你从零基础入门到精通，快速掌握大模型技术！

由于篇幅有限，有需要的小伙伴可以扫码获取！

1. 成长路线图&学习规划

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。这里，我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。

2. 大模型经典PDF书籍

书籍和学习文档资料是学习大模型过程中必不可少的，我们精选了一系列深入探讨大模型技术的书籍和学习文档，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。（书籍含电子版PDF）

3. 大模型视频教程

对于很多自学或者没有基础的同学来说，书籍这些纯文字类的学习教材会觉得比较晦涩难以理解，因此，我们提供了丰富的大模型视频教程，以动态、形象的方式展示技术概念，帮助你更快、更轻松地掌握核心知识。

4. 大模型项目实战

学以致用 ，当你的理论知识积累到一定程度，就需要通过项目实战，在实际操作中检验和巩固你所学到的知识，同时为你找工作和职业发展打下坚实的基础。

5. 大模型行业报告

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

6. 大模型面试题

面试不仅是技术的较量，更需要充分的准备。

在你已经掌握了大模型技术之后，就需要开始准备面试，我们将提供精心整理的大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

为什么大家都在学AI大模型？

随着AI技术的发展，企业对人才的需求从“单一技术”转向 “AI+行业”双背景。企业对人才的需求从“单一技术”转向 “AI+行业”双背景。金融+AI、制造+AI、医疗+AI等跨界岗位薪资涨幅达30%-50%。

同时很多人面临优化裁员，近期科技巨头英特尔裁员2万人，传统岗位不断缩减，因此转行AI势在必行！

这些资料有用吗？

这份资料由我们和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

大模型全套学习资料已整理打包，有需要的小伙伴可以微信扫描下方CSDN官方认证二维码，免费领取【保证100%免费】