1. 别急着写代码先搞懂 Agent Skill 到底是个什么东西我最早接触 Agent Skill 这个概念的时候也跟很多人一样以为它就是给 AI 写一段提示词Prompt或者封装一个 API 调用。一直到我自己在做一个公众号审稿自动化流程时被各种“看似能用、一跑就废”的方案折磨了几轮才真正想明白 Skill 的定位。先说一个最容易混淆的点Skill 不是 Agent也不是 Memory更不是 MCPModel Context Protocol。这几个词在 AI Agent 圈子里天天被挂在嘴边但它们是完全不同的层次。Agent是一个“执行者”它负责理解目标、拆解任务、调用工具、做决策。它像一个项目经理知道整体流程怎么走。Skill是 Agent 可以调用的“单项能力包”比如“总结这篇公众号文章”“检查错别字”“生成摘要”。它解决的是“怎么做某一件具体的事”。Memory是“记忆”保存的是上下文、历史对话、用户偏好、长期知识。它解决的是“记得住”的问题。MCP是“连接标准”相当于给 Agent 提供了一套统一插头让它能方便地接上各种外部工具和数据源。打个比方Agent 是一家餐厅的店长Skill 是后厨里的一套套标准化菜谱Memory 是店长脑子里记住的老顾客口味MCP 是餐厅和供应商之间的标准化订货接口。四者各司其职互相配合但千万不要混为一谈。那 Skill 和普通 Prompt 到底有什么区别这是很多人最困惑的地方。我的理解是Prompt 是一段话让 AI 临时按你说的做Skill 是一套结构化的、可复用的、带输入输出的“行为单元”。一个合格的 Skill 通常包含明确的名称和描述告诉 Agent 这个 Skill 是干什么用的、什么时候该调用它。结构化的输入参数定义比如“需要审稿的文章标题”“正文内容”“目标读者群体”。分步骤的执行逻辑可能是一段精心设计的指令也可能是多个步骤的编排甚至调用外部工具。输出格式定义比如指定输出 JSON、Markdown还是纯文本。使用示例Few-shot examples帮助 Agent 理解什么情况下用、怎么用。也就是说Prompt 是“一次性筷子”Skill 是“一套标准餐具”。一次性的东西用完就扔而 Skill 的价值在于它可以被复用、被组合、被版本化同一个 Skill 可以在不同 Agent 里共享。回到我的场景我需要一个公众号审稿 Agent它要能帮我干几件事——检查文章有没有敏感词和错别字、评价标题是否抓人、判断内容结构是否清晰、输出修改建议、最后生成一段适合公众号发布的摘要。如果这些逻辑全部堆在一个 Prompt 里Agent 每次都要重新理解一整段复杂指令容易遗漏、容易走偏而且换一个场景就完全不能用了。但如果把它们拆成独立的 Skill每个 Skill 专心做好一件事Agent 可以根据实际情况灵活调用组合出完整的审稿流程。这就是“Skill 化”的核心价值。所以如果你也想自己写 Agent Skill第一步不是打开代码编辑器而是先想清楚我的 Agent 要反复执行哪些“单项能力”每个能力包的边界在哪里只有把这一步想透后面写出来的 Skill 才是真正好用、能落地的。2. 公众号审稿流程拆解从“一个复杂任务”到“多个 Skill 的组合”我把公众号审稿这个需求拆开之后发现它天然适合用多个 Skill 协同工作。这其实也反映了 Agent 工作方式的一个关键原则别让一个 Skill 干太多事不然它就退化成一个大 Prompt 了。先看审稿这件事到底涉及哪些能力。在我实际整理的过程中拆出了这么几块通读与整体评价审稿人第一步肯定要把文章读完对文章的主题、定位、目标读者有个整体判断。然后才是“这篇文章到底写得怎么样”的总评。敏感信息与合规检查公众号发布有一个绕不开的坎——内容安全。错别字、病句、敏感词、不当表述这些如果上线之后出了问题处理起来很麻烦。这一块需要专门的检查逻辑。标题与开头的吸引力评估公众号文章能不能被点开标题和开头的权重极高。这个环节需要从内容运营的角度去做判断而不是简单地纠错。结构与逻辑分析一篇长文如果结构松散、逻辑跳跃读者很难看完。这里需要分析段落划分、论证思路、信息密度。修改建议与具体的润色优化发现问题之后还要能给出可操作的修改建议甚至直接给出润色后的句子。摘要生成与发布文案公众号文章发布时通常需要一段推荐语或摘要这个 Skill 负责从正文里提炼核心卖点生成适合发在朋友圈或公众号平台的文案。把这六块拆出来之后你可能会发现有些 Skill 之间存在依赖关系。比如“修改建议”肯定要建立在“通读评价”的基础上而“摘要生成”又需要先了解全文的核心内容。这就涉及到 Skill 编排的问题——在 Agent 层面我们可以通过工作流Workflow把多个 Skill 串起来也可以让 Agent 根据情况自动决定调用顺序。我建议在初版设计中先用“顺序执行 必要分支”的方式把流程定下来而不是一上来就搞复杂的动态路由。顺序执行的优点是稳定、可调试等跑顺了再逐步放开让 Agent 有更多自主决策空间。在拆解 Skill 时还有几个细节特别值得注意每个 Skill 的输入输出要尽量标准化。比如“文本检查类” Skill 的输入统一是“文章内容字符串”输出统一是“检查结果结构化数据”。这样上一个 Skill 的输出可以直接作为下一个 Skill 的输入编排起来非常顺。职责边界要清晰但也不能过细。比如“错别字检查”和“敏感词检查”可以拆成两个 Skill但在前期资源有限时合并成一个“文本合规检查” Skill 也完全可行。我的建议是先合并、后拆分不要一上来就追求极致的原子化。每个 Skill 都要设计好“失败模式”。比如输入为空、输入超长、内容类型不对这些情况该怎么处理。很多 Skill 写出来不好用问题就出在只考虑了正常路径没考虑异常路径。有人可能会问我用一个大 Prompt 把这些逻辑全部写进去效果不也差不多吗说实话在小规模场景下大 Prompt 确实能跑而且开发速度更快。但一旦你要面对多篇文章、不同作者、不同领域的审稿需求大 Prompt 的劣势就暴露出来了改一个细节要动全局调试时不知道是哪段逻辑出了问题不同需求之间还会互相干扰。而拆成 Skill 之后每个模块都可以独立测试、独立优化换需求时只需要替换对应模块。这才是 Skill 真正值钱的地方。3. 核心开发实战手写一个“公众号文章质量分析” Skill前面讲了那么多概念和思路这一节直接上干货。我以“公众号文章质量分析”这个 Skill 为例完整走一遍开发过程。这个 Skill 是整个审稿流程里最核心的一环——它负责对文章做整体评价输出结构化质量报告供后续的修改建议 Skill 和摘要 Skill 使用。3.1 设计 Skill 的元信息Meta每个 Skill 在定义时第一件事是写清楚元信息。这里我用一个类 JSON 的结构来描述它这也是目前各大 Agent 开发框架里比较通用的方式。元信息的作用是让 Agent 在决策时“知道有这个 Skill 存在、什么时候该调用它、传什么参数”所以描述一定要写得精确参数定义要严谨。{ name: article_quality_analysis, description: 对一篇公众号文章进行整体质量分析输出结构化的质量评估报告。适用于文章初稿完成后的第一次整体审阅或改稿后的复评。评估维度包括主题清晰度、结构逻辑、信息密度、语言表达、可读性等。, inputs: { title: { type: string, description: 文章标题, required: true }, content: { type: string, description: 文章正文内容为纯文本格式, required: true }, target_audience: { type: string, description: 目标读者群体描述如‘互联网从业者’‘新手妈妈’, required: false } }, output: { type: json, description: 结构化质量分析报告 }, tags: [审稿, 质量分析, 公众号] }这里有个细节description一定要包含“什么时候该调用”的信息。比如我写了“适用于文章初稿完成后的第一次整体审阅或改稿后的复评”这样 Agent 在编排任务时就能更准确地判断调用时机。很多新手写 Skill 时容易忽略这一点导致 Agent 不敢用或者误用这个 Skill。3.2 编写核心指令System Prompt元信息之外最重要的就是 Skill 的执行指令。这一段指令的质量直接决定了输出结果的上限。我不会写那种长长的、无所不包的大段落而是把指令拆成几个清晰的部分。第一部分是角色与目标设定你是一位资深的公众号内容编辑拥有8年新媒体行业从业经验擅长从读者视角审视文章质量。 你的任务是对给定文章进行全面的质量分析输出一份结构化的分析报告。 分析时要保持客观、专业既不要一味吹捧也不要刻意挑刺。第二部分是分析维度与评分标准。我总结了六个维度每个维度都有自己的权重和评分说明维度权重评分1-10评估要点主题聚焦度20%文章是否围绕一个核心主题展开是否有多主题混杂的情况结构逻辑性20%段落衔接是否自然论证链条是否完整是否有突兀的跳转信息密度15%有效信息含量是否充足是否有大量注水内容语言表达20%用词是否准确、句式是否多样、语言风格是否与公众号定位匹配可读性15%是否方便快速浏览读者能否在5分钟内抓住核心观点读者价值10%读者读完能否有所收获是否有可执行的建议或认知增量第三部分是输出格式要求。我强制要求输出 JSON这样下游 Skill 解析起来非常方便{ overall_score: 8.5, dimension_scores: { topic_focus: 9, structure_logic: 8, information_density: 7, language_expression: 9, readability: 8, reader_value: 8 }, summary: 一句话概括这篇文章的核心内容和质量印象, strengths: [优点1, 优点2, 优点3], weaknesses: [不足1, 不足2, 不足3], critical_issue: 如果文章存在严重问题在此说明没有则写null }3.3 让 Skill 更聪明的 Few-shot 示例光有指令还不够我建议再加上 1-2 个示例Few-shot examples尤其是第一次写 Skill 的时候。为什么因为大模型对“质量分析”这个抽象任务的理解可能跟你的预期有偏差。给一个具体示例相当于把“我心里想要什么”变成“AI 看得懂的样本”。我举一个简化的例子输入文章主题如何用 Notion 搭建个人知识库 示例输出片段{ overall_score: 7, dimension_scores: { topic_focus: 8, structure_logic: 6, ... }, summary: 文章提供了Notion知识库的搭建入门指南步骤清晰但深度不足部分章节存在工具操作与知识管理理念的脱节。, strengths: [实操步骤清晰, 图文结合较好, 适合新手入门], weaknesses: [缺少进阶技巧, 结构有些松散, 理论支撑不足] }注意示例的质量很重要。如果示例本身评分标准不一致模型学到的规矩就会乱。我建议花点时间打磨示例让它能覆盖“中等质量文章”的典型情况。3.4 合成为一个完整的 Skill 文件完整的 Skill 文件会被模型直接使用。实际项目中更多是放在一个特定目录里由框架自动加载。如果是在 Claude或类似支持 Skill 能力的 Agent 平台里可以通过 Skill 编辑器创建填入 Name、Description、Instruction 即可核心还是要把 Instruction 写好。我这里给出一个适合 copy 走的完整版# 公众号文章质量分析 Skill 你是一位资深的公众号内容编辑拥有8年新媒体行业从业经验擅长从读者视角审视文章质量。你的任务是对给定文章进行全面的质量分析输出一份结构化的分析报告。 【分析流程】 1. 先通读全文理解文章的核心主题、写作目的和目标读者。 2. 逐维度评估主题聚焦度、结构逻辑性、信息密度、语言表达、可读性、读者价值。 3. 综合各维度得分给出整体评分1-10分可保留一位小数。 【评分标准】 - 9-10分优秀几乎无可挑剔。 - 7-8分良好有明确亮点但存在可改进之处。 - 5-6分及格核心内容完整但明显不够出色。 - 3-4分较差存在明显缺陷。 - 1-2分极差需要推翻重写。 【输出格式】 使用JSON格式输出必须包含以下字段 - overall_score: 整体评分 - dimension_scores: 各维度评分 - summary: 100字以内的整体评价 - strengths: 至少2个优点 - weaknesses: 至少2个不足 - critical_issue: 严重问题说明无则填null 【注意事项】 - 不要过度挑剔语气词和标点等细枝末节除非严重影响阅读。 - 对优点和不足的描述要具体避免‘语言流畅’‘结构清晰’这类空泛表达要说明好在哪、差在哪。 - 如果文章主题明显属于自己不了解的领域请基于通用表达逻辑和行文结构做判断不要不懂装懂。这段指令的关键在于流程明确、标准量化、输出可解析、避免空洞表达。这四个要素缺一不可。3.5 踩过的坑输出格式不稳定怎么办我在实际使用中遇到最大的问题就是大模型输出的 JSON 格式不够稳定。有时候字段名变了有时候飘出一段解释文字下游解析直接报错。针对这个坑我的解决办法有三个在指令里反复强调“只输出JSON不要输出其他任何内容”。必要时可以加一句“不要使用Markdown代码块包裹”。在调用侧增加JSON提取与修复逻辑如果解析失败用正则把第一个{到最后一个}之间的内容提取出来再尝试解析。这个方法能解决 80% 的格式漂移问题。强制约束枚举值比如评分只能用数字避免模型输出“8分”或者“良好”这类模糊值。这三个手段组合使用之后我这边 JSON 解析的成功率能从 70% 左右提升到 95% 以上。这个提升幅度非常明显强烈推荐你在开发时提前考虑。4. 组合出完整的审稿 Agent从文章输入到审稿报告的全流程编排单个 Skill 写完之后接下来要解决的问题是怎么把它和另外几个 Skill 组合成一个完整的审稿 Agent我在这一节把完整的设计思路和流程细节展开讲你可以直接照着搭。4.1 审稿 Agent 的工作流程设计我的初版采用了一个**“主流程固定 分支判断”**的结构接收输入用户提供一个公众号文章链接或者直接粘贴正文。如果是链接先调用“网页内容提取”工具把正文抓取下来。文本合规检查跑一遍“合规检查” Skill检查错别字、敏感词、禁用词。文章质量分析调用上面写的“文章质量分析” Skill输出整体评分和维度分析。标题与开头吸引力评估专门分析标题和开头段落输出“是否吸引点击”的判断和建议。生成修改建议结合第2步和第3步的结果生成一份“重点修改建议”清单区分必须改和优化项。摘要生成最后调用“摘要生成” Skill输出适合发布的推荐语和摘要。这个流程的好处是每个环节都有明确的输入输出Agent 不需要在大段记忆里“临场发挥”而是像流水线一样逐站完成。4.2 如何定义 Agent 的编排逻辑在大多数 Agent 开发框架里编排逻辑要么写在工作流配置里要么写在 Agent 的系统提示词里。我偏向把“流程”和“自由度”做一个平衡前三步走固定顺序后三步给 Agent 一定的自主权。为什么这样设计因为前面三步是强依赖关系——文章没提取出来就无法做合规检查合规检查不过质量分析也没意义。但后面三步相对独立修改建议和摘要可以并行或者根据用户需求只执行其中一项。给 Agent 自主权可以让流程更灵活不至于“非要走完所有步骤才能给用户一个答复”。如果你用的框架支持“工作流 子Agent”模式我强烈建议用这种混合方式。纯工作流太死板纯 Agent 自由发挥又容易偏离预期混合是实战中最实用的状态。4.3 上下游数据如何传递Skill 与 Skill 之间的数据传递是编排环节里最容易出隐性 Bug 的地方。我的经验是每个 Skill 的输出只要是需要给别的环节用的都强制用结构化 JSON并且在设计时明确“给下一个环节的关键字段”。比如质量分析 Skill 输出的critical_issue字段如果为 null修改建议环节就知道“这篇文章没有致命问题重点放在优化项上”如果非 null修改建议环节就要把这条作为最优先级处理。这里有一个非常典型的坑如果两个 Skill 是不同团队或不同时间开发的字段命名习惯不一致比如一个用overall_score另一个用total_score传递时就容易断裂。处理办法是在编排层做一个轻量级的字段映射或者在定义 Skill 时统一约定好公共数据模型。不要小看这个动作它能帮你省下大量排错时间。4.4 完整示例一次真实的审稿过程为了让流程更直观我模拟一次真实的审稿调用过程。用户输入文章标题30岁以后我靠这3个习惯摆脱了无效加班 文章正文这里省略正文假定是一篇约2000字的职场感悟文章 目标读者30-40岁的职场人士Agent 依次执行的调用第一步调用text_compliance_check{ input: 文章正文, check_type: [typo, sensitive_word], output: { typo_count: 2, sensitive_word_count: 0, typo_list: [‘的’与‘地’混用1处, ‘在’与‘再’混用1处], sensitive_word_list: [] } }第二步调用article_quality_analysis。假设输出的核心结果是{ overall_score: 7.8, dimension_scores: { topic_focus: 8, structure_logic: 7, information_density: 7, language_expression: 8, readability: 9, reader_value: 8 }, summary: 文章以个人经历切入主题聚焦可读性强但在信息密度和结构深度上仍有提升空间。, strengths: [开篇有代入感, 三个习惯的结构清晰, 每部分都有具体做法], weaknesses: [第二部分论证较单薄, 缺少反例或风险提示], critical_issue: null }第三步调用headline_attractiveness_analysis专门评估标题{ headline_score: 8, hook_score: 9, clarity_score: 8, suggestions: 标题精确命中目标人群痛点可考虑增加数字来增强确定性。 }第四步生成修改建议{ must_fix: [ 修正2处错别字……, 补充第二部分中‘习惯二’的具体执行案例 ], optimize_suggestions: [ 增加一段关于‘习惯一’的常见误区说明, 结尾可加入一句行动号召提升转化感 ], priority_order: [ 先修正错别字, 补充案例, 优化结尾 ] }第五步生成摘要{ push_title: 30岁后告别无效加班我坚持了3个习惯, summary: 加班不等于努力。这篇文章从个人真实经历出发分享三个帮助作者摆脱无效加班的具体习惯适合被工作困住却不知如何突破的职场人阅读。, tags: [职场, 效率, 个人成长] }这套流程走下来一篇审稿报告就完整了。作为用户你拿到的不是一句“写得挺好的”而是从合规、质量、标题吸引力、修改建议到发布摘要的一整套内容包。这就是多个 Skill 组合起来的真正威力每个 Skill 负责一个专业切面组合起来就是一位逼近资深编辑水平的审稿助手。5. 输出结构不稳定的自救方案JSON 提取与兜底策略在上一节的调用示例里所有输出都是干干净净的 JSON看起来非常理想。但说实话真实世界里几乎不可能这么顺利。这一节专门展开讲输出稳定性的问题因为这是任何一个写 Agent Skill 的人都会撞上的墙。大模型输出的不稳定主要表现有这么几类在 JSON 前后添加了“好的以下是分析结果”之类的废话。用了 Markdown 代码块包裹 JSON有的加了json有的没加。字段值里混入了多余内容比如评分写成了“8分主题明确”而不是8。缺少某些必填字段。字段名轻微变化比如overall_score变成了overallScore。在我维护审稿流程的这段时间里前两类问题出现最频繁。下面是我实际采用的兜底策略按优先级排列5.1 正则提取 JSON 片段如果解析 JSON 直接失败第一步尝试用正则从原始输出中提取最外层的大括号内容import json import re def extract_json(text: str) - dict: # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 提取从第一个 { 到最后一个 } 之间的内容 pattern r\{.*\} match re.search(pattern, text, re.DOTALL) if not match: raise ValueError(无法在输出中找到JSON内容) json_str match.group(0) try: return json.loads(json_str) except json.JSONDecodeError: raise ValueError(提取到的JSON仍然无法解析)这个做法能解决的问题模型在 JSON 前后加了说明文字、用了代码块只要代码块的语言标记没有干扰大括号匹配等常见情况。5.2 去掉 Markdown 代码块标记如果用了json 包裹上面的正则其实已经能处理因为不是大括号。但如果代码块内部还有反引号字符可能干扰。再补一个更暴力的清洗def clean_extracted_json(text: str) - str: # 去掉Markdown代码块标记 text re.sub(r(?:json)?, , text) # 去掉首尾空白 text text.strip() return text5.3 设置宽松的字段校验如果提取到了 JSON但字段缺失不要直接报错让整个流程中断。更好的做法是设置默认值并记录告警def sanitize_report(data: dict) - dict: defaults { overall_score: 0, dimension_scores: {}, summary: , strengths: [], weaknesses: [], critical_issue: None } # 对每个字段确保键存在且类型正确 data[overall_score] float(data.get(overall_score, 0)) data[dimension_scores] data.get(dimension_scores, {}) data[summary] str(data.get(summary, )) data[strengths] list(data.get(strengths, [])) data[weaknesses] list(data.get(weaknesses, [])) data[critical_issue] data.get(critical_issue, None) return data这样即使模型输出不完整流程也能继续走只是对应字段为空。对用户来说拿到一份“部分字段为空”的报告比直接报错要友好得多。5.4 终极手段解析失败后让模型自修复如果一个 Skill 的输出反复解析失败我会再加一个“自修复”步骤把原始输出和解析错误信息一起回传给模型让它重新输出一遍 JSON你上一次输出的JSON格式无法解析解析器报错如下{error_message} 请只输出一个格式合法的JSON对象不要输出任何其他内容。原始内容如下{original_output}实测下来自修复对大多数情况都有效。但它会额外消耗一次模型调用所以不是最优解只作为最后一层保险。我在实战中建议的顺序是先靠指令约束 → 再做正则提取 → 再做字段清洗 → 最后自修复。四层保险下来整套流程的稳定性已经非常可用了。如果你在看这篇文章时已经遇到过解析崩溃的坑可以把这套方案直接抄走用。6. Skill 的调试方法论怎么判断是你的 Skill 写得不好还是模型能力不够开发完 Skill接下来就是没完没了的调试。很多人在这一步特别容易陷入焦虑明明指令写得很清楚了模型还是输出怪东西。到底该改 Skill还是该换模型我总结了一套自己的判断流程。6.1 先做“最小复现测试”不要一上来就拿着几百篇文章去批量验证。先拿着 1-2 篇有代表性的文章手动触发单个 Skill 跑一跑。比如单独跑“文章质量分析” Skill看它的输出是否落在预期范围内。如果最小复现测试已经跑偏说明问题是 Skill 本身的问题而不是流程编排的问题。这时候先去检查 Skill 指令、示例、参数定义。6.2 判断问题出在“理解”还是“执行”同样是输出不合格原因可能完全不同。理解问题模型没能理解你要的格式或者对“质量分析”的理解太宽泛导致输出泛泛而谈。这种情况通常需要加强 Few-shot 示例、把评分标准写得更具体。执行问题模型理解了要求但输出时格式漂移、字段缺失。这种情况通常需要加强输出格式约束或者做更多的后处理兜底。怎么区分一个很简单的办法在输出里找关键词。如果输出内容在逻辑上是合理的只是格式不对那大概率是执行问题如果输出内容本身就驴唇不对马嘴那大概率是理解问题。6.3 不同的失败用不同手段修根据我的经验整理了下面这个对照表失败表现根源修复方向输出内容太泛泛缺少针对性理解问题补充更多 Few-shot 示例增加维度拆解格式对但评分明显不合理理解问题强化评分标准补充典型评分案例JSON 字段缺漏、格式飘移执行问题强约束输出格式增加后处理兜底该调用的 Skill 没调用编排问题优化 Skill 的 description让 Agent 更容易判断调用时机调用了但传参错误编排问题检查输入参数定义是否清晰必要时增加前置校验6.4 建立回归测试集调试一段时间后你一定会发现一个规律改好了 A 案例B 案例可能又坏了。为了避免“按下葫芦浮起瓢”我强烈建议建立一个轻量级的回归测试集。不用特别复杂就是把 10-20 篇不同风格、不同长度的文章存起来每次改完 Skill 后批量跑一遍对比输出结果是否出现新的退化。注意不要只看是否解析成功还要人工抽查 2-3 篇的输出质量。解析成功不等于内容合格这一点要特别警惕。有了这套回归测试集你才能放心地去迭代优化 Skill。否则每改一次都像在玩随机骰子心里完全没底。7. 进阶优化让 Skill 更懂你的公众号运营策略基础版的审稿 Skill 能帮你检查错别字、分析质量、生成摘要但如果你希望它更贴合自己的公众号定位还有几个值得投入的优化方向。7.1 把“读者画像”内嵌到 Skill 里不同公众号的读者群体对“好文章”的定义完全不一样。同样是 2000 字的深度文面向投资人的号和面向新手妈妈的号评价标准差着十万八千里。我在质量分析 Skill 的指令里增加了一个可选参数reader_profile用来描述目标读者的特征。传入后模型在评分时会主动带入这个画像如果提供了reader_profile请在分析时始终站在该读者群体的视角进行评分。例如 - 新手妈妈重视实操性、易读性对专业术语容忍度低。 - 投资从业者重视数据完整性、逻辑严密性对煽情表达容忍度低。这样同一个 Skill在不同的读者画像下会给出不同的评分逻辑。这是让 Skill“脱胎换骨”的极简单做法。7.2 增加历史审稿偏好记忆如果平台支持 Memory 功能可以允许 Agent 记录用户的历史审稿偏好比如“作者偏好短句、喜欢在开头抛案例”然后在后续审稿时参考这些偏好生成建议。这里要注意 Skill 和 Memory 的协作边界Memory 负责记住偏好Skill 负责在输出时应用偏好。不要把偏好硬编码在 Skill 里否则换一个作者就全乱了。7.3 让 Skill 自我反思和迭代比较进阶的玩法是在流程末尾加一个“反思”环节让 Agent 对比本次审稿报告和作者的实际修改判断哪些建议被采纳了、哪些没有并总结原因。然后把这些反馈存入 Memory反过来优化后续审稿建议的侧重点。这个闭环是很多成熟 Agent 产品和普通玩具的区别。虽然初期实现起来会多一些工作量但一旦跑通它带来的个性化效果是非常惊人的。它会让你觉得这个审稿 Agent 越来越像一位真正了解你的主编。8. Skill 开发的几条实用经验总结文章写到这儿主体内容已经全部展开。最后这部分我把自己这段时间开发 Agent Skill 的几条核心经验做一个“不套路”的收尾也相当于给想动手的同学一份速查清单。第一条经验Skill 的颗粒度宁粗勿细。除非你的场景极其复杂否则不要一上来就把事情拆到原子级。先做几个大而全的 Skill跑通流程再逐步拆分。我一开始把“错别字检查”“敏感词检查”“语气检查”拆成三个独立的 Skill结果发现它们对模型的能力要求高度重叠拆开之后反而多了一堆编排开销。后来合并成一个“文本合规检查”效果反而更好。第二条经验Skill 的描述description和指令instruction要分开写别混在一起。description 是写给 Agent 的“搜索引擎摘要”它决定 Agent 会不会调用这个 Skillinstruction 是写给模型的“执行手册”它决定调用后输出的质量。两件事目的不同写作方式也应该不同。description 要短而准突出调用时机instruction 要长而细突出执行步骤和输出要求。第三条经验一定不要在输出格式上妥协。哪怕初期开发时你觉得“稍微飘一点没关系”也要尽早把输出结构定成强规范。因为一旦下游依赖这个输出格式稳定性的问题就会被无限放大。宁可前期多花时间打磨输出约束也不要后期在解析上打补丁。第四条经验建立“小步迭代”的开发节奏。每写完一个 Skill就立即用一个最小的示例跑一次确认没问题再写下一个。不要一次性写完五六个 Skill 再统一测试那样出现问题时你根本不知道是哪一个环节的锅。这个开发节奏听起来很简单但真的能帮你省掉大量定位问题的时间。第五条经验把“不确定”交给 Agent把“确定”写死在代码里。Skill 的优势是灵活性但它并不适合承载需要精确计算的逻辑。如果某个环节的目标非常明确比如“提取正文内容”用传统代码处理会更稳定只有像“分析质量”“判断标题吸引力”这类主观判断任务才适合交给 Skill 去发挥大模型的语义理解能力。用对工具比什么都重要。如果你正在被“Agent Skill 到底怎么写”这个问题困扰我希望这篇文章能帮你理清思路。不要被概念吓到也不要把所有逻辑一股脑塞进一个 Skill。先把流程拆开、把边界画好、把输出定死一步一步来你会发现 Agent 开发和写一份操作手册没有本质区别——都是“分而治之逐一攻破”。
