本文介绍了 Agent Skills 框架的设计技巧与实战经验通过将大任务拆分为标准化的小技能并使用编排器按序调度实现单一智能体的多能力扩展。文章详细阐述了 Skills 框架的 Pipeline 设计、Skill 的定义与执行模式、上下文设计、数据流动方式以及规则引擎与 LLM 的结合等关键点帮助读者理解如何构建高效、可维护的智能体系统。一、从一个问题场景说起程序员老张今年 45 岁拿到体检报告后一脸懵——空腹血糖 7.2、甘油三酯 2.8、尿酸 520、谷丙转氨酶 52……十几项指标密密麻麻红色箭头此起彼伏。他想知道三件事这些数字到底什么意思数据解析我有哪些健康风险风险评估接下来该怎么办建议生成如果你是 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 正是读这些描述来决定选哪个 Skillname: parse_report_skilldescription: 解析体检报告原始数据提取并分类各项检验指标triggers: - 体检报告 - 体检数据 - 化验单tags: - 健康 - 体检Skill 的执行有三种模式Executor 按优先级依次检测有executor.py→ 走自定义执行器可以混合规则引擎 LLM后面详述有prompt.template→ 填充模板后调用 LLM都没有→ 把 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( timestampdatetime.now().isoformat(), layerlayer, # user_input | scratchpad | environment opop, # read | write | delete | compress keykey, sourcesource, # 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 拼成字符串传入。结果——第一步精度下降用户说帮我解析报告并评估风险再给建议如果把这整句话原封不动传给parse_report_skill它不知道自己只需要做解析这一件事容易跑偏Token 爆炸式增长步骤越多拼接越长第三步可能收到几千字符的前置信息LLM 在海量上下文中迷路解法每一步只看到最小必要上下文核心理念不区分第一步和后续步骤统一通过同一个方法构建输入。每个步骤收到的输入由三部分组成用一个例子说清楚。用户说“帮我解析体检报告并评估风险再给出建议。” 如果步骤 3generate_advice_skill收到的主指令还是这整句话它不知道该做解析、评估还是建议。但如果收到的是 Planner 分解出的 sub_task——“基于解析数据和风险评估生成个性化健康建议”——职责就非常清晰了压缩策略遵循一个直觉——越新的步骤输出越重要始终保留原始请求LLM 不能忘记用户到底要什么完整保留最新一步的输出当前步骤通常直接依赖它可截断较早的步骤输出加…已压缩标记可丢弃已被后续步骤消化吸收的最早步骤结果是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 不是简单地把数据丢给 LLMdef 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_reportBMI 计算、血压分级、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[风险评估, 健康风险, 疾病风险, 风险分析, 健康评分] modes0| utils.skill_loader — 已加载 Skill: Skill generate_advice triggers[健康建议, 调理建议, 怎么改善, 注意事项, 保健方案, 体检建议] modes0| utils.skill_loader — 已加载 Skill: Skill parse_report triggers[体检报告, 体检数据, 解析报告, 检验结果, 化验单, 体检解读] modes0| utils.skill_loader — 共发现 3 个 Skill: [assess_risk, generate_advice, parse_report]| __main__ — 已加载 3 个 Skill: [assess_risk, generate_advice, parse_report]Phase 1 — Planner 规划 SkillsPlanner 收到用户输入 可用 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 SkillsMulti-Agent核心范式单体智能体 可扩展能力模块多智能体系统 任务分发与协作上下文共享渐进式披露精准裁剪隔离各 Agent 独立上下文通过消息传递通信成本低——所有思考在单次模型调用内部完成高——每次 Agent 间调用都是独立模型调用调试审计日志 结构化追踪因果链一目了然需翻消息日志跨 Agent 问题定位困难典型 token 消耗6,000 - 10,00015,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 设计的手艺。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取
小白程序员必看：收藏这篇，轻松让单一智能体拥有多种能力（Agent Skills 框架实战）
发布时间：2026/7/25 22:33:42
本文介绍了 Agent Skills 框架的设计技巧与实战经验通过将大任务拆分为标准化的小技能并使用编排器按序调度实现单一智能体的多能力扩展。文章详细阐述了 Skills 框架的 Pipeline 设计、Skill 的定义与执行模式、上下文设计、数据流动方式以及规则引擎与 LLM 的结合等关键点帮助读者理解如何构建高效、可维护的智能体系统。一、从一个问题场景说起程序员老张今年 45 岁拿到体检报告后一脸懵——空腹血糖 7.2、甘油三酯 2.8、尿酸 520、谷丙转氨酶 52……十几项指标密密麻麻红色箭头此起彼伏。他想知道三件事这些数字到底什么意思数据解析我有哪些健康风险风险评估接下来该怎么办建议生成如果你是 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 正是读这些描述来决定选哪个 Skillname: parse_report_skilldescription: 解析体检报告原始数据提取并分类各项检验指标triggers: - 体检报告 - 体检数据 - 化验单tags: - 健康 - 体检Skill 的执行有三种模式Executor 按优先级依次检测有executor.py→ 走自定义执行器可以混合规则引擎 LLM后面详述有prompt.template→ 填充模板后调用 LLM都没有→ 把 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( timestampdatetime.now().isoformat(), layerlayer, # user_input | scratchpad | environment opop, # read | write | delete | compress keykey, sourcesource, # 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 拼成字符串传入。结果——第一步精度下降用户说帮我解析报告并评估风险再给建议如果把这整句话原封不动传给parse_report_skill它不知道自己只需要做解析这一件事容易跑偏Token 爆炸式增长步骤越多拼接越长第三步可能收到几千字符的前置信息LLM 在海量上下文中迷路解法每一步只看到最小必要上下文核心理念不区分第一步和后续步骤统一通过同一个方法构建输入。每个步骤收到的输入由三部分组成用一个例子说清楚。用户说“帮我解析体检报告并评估风险再给出建议。” 如果步骤 3generate_advice_skill收到的主指令还是这整句话它不知道该做解析、评估还是建议。但如果收到的是 Planner 分解出的 sub_task——“基于解析数据和风险评估生成个性化健康建议”——职责就非常清晰了压缩策略遵循一个直觉——越新的步骤输出越重要始终保留原始请求LLM 不能忘记用户到底要什么完整保留最新一步的输出当前步骤通常直接依赖它可截断较早的步骤输出加…已压缩标记可丢弃已被后续步骤消化吸收的最早步骤结果是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 不是简单地把数据丢给 LLMdef 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_reportBMI 计算、血压分级、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[风险评估, 健康风险, 疾病风险, 风险分析, 健康评分] modes0| utils.skill_loader — 已加载 Skill: Skill generate_advice triggers[健康建议, 调理建议, 怎么改善, 注意事项, 保健方案, 体检建议] modes0| utils.skill_loader — 已加载 Skill: Skill parse_report triggers[体检报告, 体检数据, 解析报告, 检验结果, 化验单, 体检解读] modes0| utils.skill_loader — 共发现 3 个 Skill: [assess_risk, generate_advice, parse_report]| __main__ — 已加载 3 个 Skill: [assess_risk, generate_advice, parse_report]Phase 1 — Planner 规划 SkillsPlanner 收到用户输入 可用 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 SkillsMulti-Agent核心范式单体智能体 可扩展能力模块多智能体系统 任务分发与协作上下文共享渐进式披露精准裁剪隔离各 Agent 独立上下文通过消息传递通信成本低——所有思考在单次模型调用内部完成高——每次 Agent 间调用都是独立模型调用调试审计日志 结构化追踪因果链一目了然需翻消息日志跨 Agent 问题定位困难典型 token 消耗6,000 - 10,00015,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 设计的手艺。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取
