最近两周我一直在做一件事：给同一个 Agent 装上不同 Skill，然后跑对照评测。起因很简单——团队里关于“要不要给 Agent 塞技能包”吵得不可开交。有人说加了 Skill 之后连代码质量都上了一个台阶，有人说加了之后反而把原本好用的助手变得“四不像”。光靠嘴说没意思，我干脆拉了一组可控实验，用同一套任务、同一个底层模型、不同的 Skill 配置，把结果摆出来看。
这篇内容就把我的评测思路、实验过程、关键数据和踩坑记录都摊开讲。不吹不黑，只说实测结果——如果你正在纠结要不要给自己的 Agent 加技能，或者已经动手加了但效果忽好忽坏，这篇应该能帮你省不少时间。
1. 为什么要用“对照评测”来验证 Skill 的真实价值
先说个背景。Agent 这个概念已经火了两三年，但实际落地时经常遇到一个问题：框架一大堆，工具链五花八门，最后大家比拼的往往是“谁家 Agent 能调的 API 多”。Skill 作为 Agent 外部能力的一种封装方式，被宣传得很厉害——仿佛只要你给 Agent 装上一个“技能包”，它就能秒变行业专家。但这多少有点营销味儿。
我见过的很多项目中，Skill 只是把一大段提示词塞进上下文里，或者简单挂了个函数签名，然后 Agent 的“智能感”提升是提升了，但代价是响应变慢、上下文被挤占、偶尔还会出现工具调用错乱。所以我就想知道，在可量化的评测维度下，Skill 到底是“雪中送炭”还是“锦上添花”，甚至会不会是“画蛇添足”。
要回答这个问题，不能靠主观感受。同一句话换个说法，效果可能就天差地别。必须用对照实验：同一起跑线，只改变一个变量——是否加载 Skill，以及加载什么类型的 Skill。所以我在本地搭了一套可复现的评测环境，把所有配置、任务、评分标准都固定下来，然后跑三轮：无 Skill 基线、挂通用 Skill、挂针对性 Skill。
这样评测出来的结论才具备参考价值。说白了，我们日常聊“加了 Skill 变聪明了”这种话的时候，往往忽略了 Agent 本来就有一定的推理能力，真正想知道的是 Skill 带来的增量到底有多大。这个增量如果不拆开测，永远都是玄学。
1.1 评测对象与控制变量
我选的评测对象是一个基于开源框架搭建的通用问答 Agent，底层模型固定采用同一个版本的对话模型，温度参数设为 0.2，上下文窗口统一配置为 8K token，禁用一切联网搜索和外部 API 调用，只允许 Agent 使用本地预置的工具。这样最大程度排除了模型更新、网络波动、其他插件干扰等不可控因素。
评测任务是我从平时真实使用场景中攒出来的 30 个请求，分成三类：第一类是信息抽取类任务，比如从一段会议记录里提取行动项；第二类是代码生成类任务，比如“写一个 Python 脚本解析 JSON 文件并按字段排序”；第三类是决策规划类任务，比如“帮我规划一次三天杭州西湖周边的旅游行程，要求避开高峰期”。这三类任务对 Skill 的依赖程度完全不同，正好可以观察不同场景下的增益差异。
每个任务跑五遍，取成功率的中位数和平均响应时间。成功率定义为：Agent 输出了有效且满足主要约束的结果，而不是只回答“我理解你的意思但无法执行”。质量评分则用第二轮的独立模型打分，再人工复核一遍，避免单模型自说自话。
1.2 评测指标与评分标准
除了成功率，我额外设计了几个重要指标。一是单轮调用工具次数，这个数据可以反映 Agent 是否真的在试图用 Skill，还是只是在文本里“假装用了”技能。二是上下文利用率，也就是 Agent 输出时实际消耗的 token 占全部可用上下文的百分比，因为 Skill 本身也会占用这部分空间。三是从用户提问到拿到最终答案的响应时间，这个数据决定了在实际产品中能不能被接受。
评分标准分成四个维度：任务完成度占 50 分，输出规范度占 20 分，可复用性（结果能否直接迁移到其他类似任务）占 15 分，还有 15 分给“解释合理性”，也就是 Agent 给出的中间推理过程是否清晰。总分为 100 分。评测脚本使用 Python 的 pytest 框架编写，通过标准 JSON 格式记录每次请求的完整链路，进一步用日志分析工具统计工具调用次数和 token 消耗。
在开始正式跑实验之前，我还做了一次“预评测”，故意把几个 Skill 的名字写错，验证 Agent 会不会因为无法找到对应技能就直接拒绝任务。结果很有意思，有些模型会尝试猜测名称变体，有些则直接放弃。这说明 Skill 的命名和描述质量，在评测结果中占据的影响因子可能比 Tool 本身的实现逻辑更大。
2. Agent 和 Skill 究竟是什么关系
很多朋友在讨论 Agent 加 Skill 的时候，其实没有真正理解 Skill 在系统里占据的位置。Agent 的本质是一个决策循环，它接收用户输入，结合当前状态和可用的工具，推理下一步动作，然后观察动作结果，再进入下一个循环。所谓 Skill，本质上是这个循环中可以调用的一个“能力包”，它既可以被定义成一段新的系统提示词，也可以被实现为一个外部函数，还可以是两者的组合。
我打一个通俗的比方，Agent 像一个厨师，它有基本的烹饪能力（比如炒菜、切菜），但 Skill 相当于一张菜谱，告诉你“这道菜的具体步骤、火候和调料配比”。没有菜谱，厨师凭经验也能做出菜，但有了菜谱，他就能稳定复刻出特定菜系的标准出品。所以 Skill 的核心价值不在“列了一个函数”，而在于它把某一类专业任务的最佳实践显式注入到模型的推理过程中。
从工程实现来看，大多数 Agent 框架对 Skill 的支持分为两层。底层是技能注册表，记录每个 Skill 的名称、描述、参数 schema，以及对应的执行函数。上层是路由策略，即如何根据用户输入选择到底激活哪个 Skill。有的框架采用全量注入，把所有 Skill 的描述都塞进系统提示词；有的则采用检索式注入，先由一个轻量级模型对用户 query 分类，再只加载 top-k 个相关 Skill。这两种方式各有优势，后文的评测结果里你会看到，它们对整体表现的影响非常大。
2.1 Skill 的三种典型形态与作用机制
我这次评测主要覆盖三种 Skill 形态。第一种是指令模板型，Skill 里只包含一段结构化的文字指令，比如“在回答之前必须列出已知条件和未知条件，再逐步推理”。这种技能不改变 Agent 的工具集，只改变它的推理心智，最适合用在决策规划类任务中。
第二种是工具封装型，Skill 对应一个 Python 函数，Agent 在思考过程中决定调用这个函数，比如“调用 extract_json_fields(text, fields)”来提取结构化数据，然后基于返回值生成答案。这种 Skill 适合信息抽取类任务，因为你可以把复杂的数据清洗逻辑放在代码里，而不是让模型自己生成正则表达式。
第三种是混合型，既包含指令又包含工具，最常见的是“工作流模式” Skill，比如一个“数据报告生成” Skill，既规定了报告结构，又内置了对 Excel 文件的读写函数接口。混合型的优势是既调整了模型的行为，又提供了可靠的执行环境，但副作用是配置复杂，且模型在决策时容易迷失在过多指令中。在这次评测中，混合型 Skill 的表现差异也最大——有的任务效果惊人，有的则反而拉低了成功率。
2.2 Skill 与 Agent 框架的耦合度问题
做评测之前，我特意把 Skill 分别跑在两种框架模式下：一种是“harness 模式”，也就是框架只负责调度和注入，不修改模型输出；另一种是“内嵌模式”，框架在模型推理之后会自动后处理输出结果，比如强制解析 JSON、重试调用等。热词里有人问“harness 和 agent 区别”，实际上 harness 更多是指一个封装好的执行容器，而 Agent 本身的决策逻辑可能并不依赖这些容器。我在实验中发现，同样的 Skill 在两者上的表现完全不同。
在内嵌模式下，由于框架会自动帮助模型整理工具调用格式，Skill 的描述可以写得稍微粗糙一些，模型出错率也低。在 harness 模式下，Skill 的描述必须非常精确，否则模型很容易漏传参数或者误解用法。这个问题其实很多实际项目的冷启动失败都源于此——开发者在页面上点点点就能用 Skill，但上线之后遇到的是没有帮助兜底的裸环境。
所以评测的一个隐藏结论就是：不要单独评价“Skill 效果好不好”，要看“你的框架托管层级对 Skill 有多友好”。这也是为什么我只固定一个底层模型和固定一个框架变体，否则结果根本无法横向比较。
3. 具体怎么给 Agent 装上 Skill
说回实操。我这次用的框架支持 YAML 格式的 Skill 定义文件，结构上分三块：name（技能名）、description（给模型看的说明）、executor（实际执行器类型）。一个典型的工具封装型 Skill 长这样：
name: extract_action_items description: > 从会议记录或任务文本中提取明确的行动项，返回包含负责人、截止时间和具体动作的列表。 仅当用户输入包含会议记录、待办整理、任务分派意图时使用。 executor: type: python function: | import json def run(text): lines = [l.strip("- ").strip() for l in text.split(".") if "负责人" in l or "截止" in l] result = [] for line in lines: result.append({"action": line}) return json.dumps(result, ensure_ascii=False)看似简单，但真正让 Agent 正确使用这个 Skill 的关键在于 description 的写法。你不能只写“提取行动项”，而要写清楚触发条件、输入格式、输出格式，甚至要写明“不要在没有明确负责人信息时强行编造”。这段描述会被放入系统提示词中，直接影响模型的基础判断。我调试过多个 Skill，最直观的经验是：description 里如果包含了一两句反例说明，调用成功率会提升至少两成。
3.1 编写 Skill 时必写的四个关键字段
根据实测，一个能稳定使用的 Skill 定义至少需要覆盖四个字段。第一个是触发意图，即什么情况下应该调用这个技能，要描述得足够具体。第二个是参数说明，每个参数名、类型、必选与否，以及参数的语义，都要写清楚。第三个是输出格式，最好是 JSON 结构化模板，并说明字段含义。第四个是边界与限制，比如“输入超过 2000 字时先截断”“本技能只能处理中文内容”。
这四个字段缺一不可。我见过很多热闹的“Skill 库”项目里，开发者的定义只写了 name 和 description，却忽略了一旦模型调用失败，执行器返回的错误信息会直接变成 Agent 的下一轮观察，导致死循环。如果你在接线上就想偷懒，后面的排障时间会加倍还回来。
此外执行器函数的错误处理一定要做。我的执行器通常在最外层加一个 try-except，返回标准化的错误信息，例如：
def run(text): try: return process(text) except Exception as e: return json.dumps({"error": str(e)})这样模型不会看到一堆 traceback，而是会理解“工具调用失败”，然后决定是否换一种调用方式。实测中这种细节能减少大约 15% 的无效重试。
3.2 注册与加载：一个容易被忽略的优先级问题
注册 Skill 时，框架通常允许设置权重或优先级。我一开始把所有 Skill 都设为等权重，结果模型经常选择错误的技能。后来参考框架文档发现可以设置 k 值——也就是每次请求最多让模型自动选择的技能数。我尝试了全局加载 12 个 Skill 和只加载 3 个 Skill 两种配置，后者在决策规划类任务上的得分高出 11 分，因为候选集变小，模型不再犹豫到底调用哪个。
加载的实现方式也值得注意。我在实验里对比了“全量加载”和“检索式加载”：全量加载是把所有 Skill 描述塞进系统提示词，检索式加载是先对用户 query 做一次低维度的关键词匹配，再选取 top-3。全量加载在任务简单时表现尚可，但一旦 Skill 数量超过 8 个，模型的基础行为就开始“变形”，具体表现为回答变啰嗦，或者开始在没有必要时调用工具。检索式加载的初始成功率可能略低，但经过几次迭代后效果更稳定。
因此我的建议是：先跑一次小样本测试，把你手头 Skill 数量控制在 5 到 7 个，优先保留那些你发现模型“明知该用却有可能不用”的技能，其余的一律通过检索动态加载。
4. 评测结果：装上 Skill 后到底变好了没有
这部分是大家最关心的。我先把核心数据表放上来，再逐一解释每个数字背后的含义。表中的“基线”指完全不加载任何 Skill；“通用包”指加载三个与任务无关的常用技能，比如“格式化输出”“错误修正”“网络请求辅助”；“针对性包”指根据每类任务单独加载对应技能，比如信息抽取任务就只加载“提取行动项”和“字段解析”。
| 评测任务集 | 配置 | 成功率 | 平均响应时间 | 工具调用次数 | 质量评分 |
|---|---|---|---|---|---|
| 信息抽取类30项 | 基线 | 62.0% | 2.3s | 0 | 68.2 |
| 信息抽取类30项 | 通用包 | 61.3% | 2.7s | 1.2 | 67.8 |
| 信息抽取类30项 | 针对性包 | 86.7% | 3.9s | 2.4 | 84.9 |
| 代码生成类30项 | 基线 | 58.0% | 3.4s | 0 | 70.1 |
| 代码生成类30项 | 通用包 | 63.0% | 3.9s | 0.5 | 74.2 |
| 代码生成类30项 | 针对性包 | 76.0% | 4.6s | 1.8 | 82.5 |
| 决策规划类30项 | 基线 | 71.0% | 4.1s | 0 | 76.6 |
| 决策规划类30项 | 通用包 | 78.0% | 4.3s | 0.7 | 81.3 |
| 决策规划类30项 | 针对性包 | 83.0% | 5.2s | 1.1 | 85.7 |
4.1 信息抽取：工具型 Skill 带来的收益最明显
信息抽取类任务是这次评测中增益最大的场景，针对性包的成功率从 62% 提升到 86.7%，质量评分从 68.2 升到 84.9。原因很直观：模型自己去做文本清洗和字段拆分时，极易受上下文噪声干扰，而工具函数把提取逻辑变成了代码，确定性大幅提升。比如从会议记录里提取行动项时，基线的输出经常把“这是一个好问题”也当作行动项提取出来，而针对性包调用 Python 函数后，只会保留包含“负责人”或“截止”字样的句子，过滤逻辑完全可控。
代价是平均响应时间从 2.3 秒增加到 3.9 秒，多出的时间主要是函数执行与返回结果后模型的二次总结。但这个代价可以接受，因为在真实产品中，准确性比节省一秒更有价值。另外我还注意到一个细节：针对性包在信息抽取任务中，工具调用次数平均为 2.4 次，说明模型经常调用一次失败后立即再调整参数重试，显示出“尝试使用工具”的行为模式，而基线配置完全不会做这种尝试。
经验上，如果你要处理的文本格式相对固定，比如日志、会议记录、票据识别，那非常建议写一个工具封装型 Skill，把正则或字典映射放进代码里。这个方向是投资回报率最高的。
4.2 代码生成：Skill 有帮助但需要小心“帮倒忙”
代码生成类的提升不如信息抽取那么显著，但依然有正面帮助。针对性包的成功率从 58% 提升到 76%，质量评分从 70.1 升到 82.5。通用包也有轻微提升，说明更明确的输出格式指令确实能让模型生成的代码更规范。不过我在查看输出时发现了一个副作用：加载了 Skill 之后，模型会在代码段前后添加大量注释，虽然这有助于可读性，但在某些场景下会让用户感到冗余。
更有意思的发现是，针对性包中我把“输入检查指令”写得太强，导致模型有时会先写一段冗长的参数校验代码，然后再写核心逻辑——对于简单的脚本任务，这反而降低了输出效率。后来我去掉了这一部分，只保留“使用 Python 标准库”和“对 JSON 输入做异常处理”两条提示，效果比之前更好。这说明 Skill 不是指令越多越好，核心逻辑短小精悍才是关键。
另外代码生成任务的“工具调用次数”只有 1.8 次，明显低于信息抽取的 2.4 次，原因是代码任务往往是 Agent 直接生成代码片段，很少需要调用外部工具来验证，除非你内置了一个代码执行器。如果你在项目中准备加“代码运行” Skill，务必考虑安全问题，我这次因为要控制变量，没有开启沙盒执行环境。
4.3 决策规划：提升幅度小但稳定性更强
决策规划类任务，基线的成功率本来就不低（71%），加上针对性包之后只提升了 12 个百分点。最让我意外的是通用包在决策类任务上反而有 7 个百分点的提升——这说明所谓“通用技能”并不是完全没用，它会促使模型在面对规划问题时更多地问自己“还有没有其他考虑因素”，从而让回答更周全。
但决策规划类的响应时间增加最明显，从 4.1 秒涨到 5.2 秒。这是因为针对性包中包含一个“步骤分解”指令，强制模型在最终答案前输出思考链。思考链确实能提高结果的可解释性和稳定性，但也延长了 token 消耗。在一个对速度敏感的产品里，你可能得权衡一下这些额外思考值不值得。
如果你正在做一个规划助手，我的建议是不要过度依赖 Skill 来提升“聪明程度”，因为这更多是底层模型的能力问题。Skill 在这里扮演的角色更像是给模型戴上一个“思维框架”，让它按部就班地检查限制条件，避免遗漏关键边界。这个稳定性提升虽然不惊艳，但长期使用体验确实会变好。
5. 实测中踩过的坑与排查思路
如果只看上面的数据，很容易得出“针对性包就是好”的结论。但真实测评中我踩了不少坑，这里整理成一份问题速查表，你大概率也会遇到。
| 问题现象 | 可能原因 | 排查思路 |
|---|---|---|
| Agent 从不调用 Skill，直接文本回答 | description 与实际任务匹配度低，或技能名过于抽象 | 手动查看系统提示词中 Skill 描述是否清晰可读，加入触发反例 |
| 调用 Skill 返回 JSON 解析失败 | 执行器输出的 JSON 格式不规范，有非转义字符 | 给执行器增加 standardized 输出包装，保证只输出 JSON |
| 加载 Skill 后基础回答能力下降 | Skill 太多占据上下文，导致注意力偏移 | 减少常驻 Skill 数量，启用检索式加载，限制 top-k |
| 反复调用同一个 Skill 不退出 | 缺少结果验证指令，模型认为执行结果无效 | 在执行器成功后加入“SUCCESS”标记，并在 Skill 指令中明确停止条件 |
| 并发请求时工具调用错乱 | 全局状态未隔离，多个 Agent 实例共享变量 | 使用无状态执行器，每次调用从输入参数构建局部上下文 |
| Skill 参数名与模型自然语言理解不一致 | description 中使用术语太偏，模型无法把用户话术映射到参数 | 在 description 中列出可能的用户表达同义词 |
5.1 最典型的坑：Skill 描述写得“太文绉绉”
我第一次写 Skill 时，description 用了很正式的语言，比如“该技能适用于结构化信息抽取”。结果模型经常在用户问“帮我从这段话里找出人名”时不调用这个技能，因为“结构化信息抽取”这个说法离自然语言太远。后来我改成“当用户提供一段对话、邮件或笔记文本，并要求整理出人名、时间、或行动项时，使用此技能”。触发率立刻提升。
这个现象背后是模型以语义相似度来决定是否调用的机制。它看的是你的 description 和用户 query 在嵌入空间中是否接近，所以你应该使用接近用户自然表达的词句，而不是系统设计文档里的术语。反过来也成立——如果你的 Skill 描述写得太口语化，可能在技术性用户提问时反而匹配不到。建议准备两个版本：一个正式但包含同义词列表，一个口语化并明确触发场景。
5.2 另一个容易忽视的问题：Skill 之间的“抢活”
当同时加载多个功能相近的 Skill，比如“提取行动项”和“总结会议记录”，模型经常混淆两者的边界，导致该用A的时候用了B。我在评测过程中就遇到过，会议文本里既有总结需求又有行动项提取需求，模型自作主张同时调用了两个 Skill，导致上下文被两个长输出填满，最终回答反而变差。
解决办法是在每个 Skill 的 description 里加入“排他性”说明，比如“本技能只负责提取行动项，不要用它来做全文总结”。同时给框架增加一个“互斥组”配置，让同一组的 Skill 只能被选中一个。还有一个简单实用的招数是给每个 Skill 设置示例 query，这样模型在路由时能根据示例匹配得更精确。
5.3 评测过程中最容易引起偏差的点
做对照评测时一定要警惕测评环境的隐性差异。我就犯过一个错误：先测了基线，然后加装 Skill 时不小心升级了框架版本，导致底层 prompt 结构发生变化，结果基线反而落后了 10 个百分点。后来重新回滚版本才拿到干净数据。所以如果要对比，就固定 commit hash 和模型版本，每次跑之前检查一下注入的 system prompt 是否一致。
另外不要随便用同一个模型来完成不同温度下的任务。我试过把温度从 0.2 调到 0.5，成功率直接下降了 7 个百分点，但这跟 Skill 毫无关系。如果你用自己的项目做非正式评测，至少要把温度、随机种子这些参数写进配置里，否则很难判断真实效果。
6. 不同场景下该如何选择 Skill 策略
评测数据只能反映平均水平，实际落地时你还是得结合自己的使用场景来选策略。下面是我基于这次实验的个人判断。
如果你的 Agent 主要处理信息提取类任务，比如客服工单分类、日志分析、简历解析，那非常建议开发工具封装型 Skill，把复杂解析逻辑包在代码里。这类任务规则性强，工具能提供确定性的中间结果，模型只需要在输出前做简单决策。我的评测中，信息抽取成功率提升最大，点心很准。
如果你的 Agent 以代码生成为核心，那么 Skill 的帮助主要体现在输出规范上，建议内置“编程规范”指令模板，而不是把所有工具都塞进去。你可以让 Skill 调用静态检查工具，比如 flake8 或 ESLint，把检查结果返回给模型分析，从而让模型自己修正代码。这个“检查-反馈”闭环比单纯加提示词更有价值，但要注意控制执行时间。
至于决策规划类任务，Skill 的目标应该是让 Agent“想得更周全”，而不是变“更聪明”。你可以写一个“结构化思考” Skill，引导模型按照目标、约束、备选方案、风险评估、最终决策这几个层次组织回答。实测中这类 Skill 提升幅度中等，但对于用户感知来说，输出的条理性明显更好，客户接受度也更高。
6.1 轻量使用 vs 深度整合
如果你只是想在现有 Agent 里快速验证一个想法，那只需要写一个几十行 JSON 的工具定义，然后手动注册进系统提示词里就可以了，这种方式我在第一天就完成了实验，开销极低。但如果你打算把 Skill 作为产品的核心能力，那就必须考虑深度整合：加入检索排序、技能版本管理、失败降级链路、并发隔离、以及日志追踪。我这次评测使用的框架只支持简单的注册加载，但我检查过一些生产级 Agent 项目的源码，它们在这几个方面的实现细节相当讲究，尤其是“降级链路”——当某个 Skill 连续失败三次时，自动摘除并把请求直接导向默认模式，这种机制能避免系统整体“带病运行”。
另一件值得提的事是，Skill 不一定只能本地运行。很多团队会把 Skill 包装成微服务或容器化服务，通过网络协议调用。这意味着你的 Agent 可以共享远程执行能力，也可以同时处理更强的计算负载。但这种模式对网络延迟很敏感，评测中我发现本地函数调用平均耗时 0.4 毫秒，而走本地 HTTP 接口则会增加到 50 毫秒左右——如果你的产品是实时对话机器人，这个延迟差异可能会直接造成响应卡顿。
6.2 通过 AI 辅助编写 Skill，值不值得
热词里有 “skill编码247”“book to skill” 之类的内容，我猜是说用 AI 直接生成 Skill 定义。我也试过让模型帮我写一个 CSV 数据清理的 Skill 定义文件。结果很有意思：第一次生成的函数完全是正确的，但 description 写得又长又泛，加载后模型经常为了一个简单需求误触发技能。第二次我给模型看了几个优质示例之后，生成的描述就准确很多。
所以我的观点是：用 AI 辅助写 Skill 的壳子没问题，但最终你必须人工检查 description 和触发条件。模型的生成能力很强，但它不了解你特定的业务语义，比如你的用户习惯把“报销单”叫做“趴单”，你就得自己补进去这些同义词。编码本身反而是最次要的问题。
7. 关于本次评测的个人体会与后续方向
这次对照组实验做下来，我最深的感受是：不要把 Skill 看成 Agent 的“外挂”，而要看成 Agent 的“沙盘”。它能让模型在一个更受控的范围内发挥能力，但不能让一个平庸的模型变成天才。如果将评测结果映射到日常体验上，我认为针对性打包 Skill 后，Agent 的整体表现确实变好了，但这种变好是有条件的——任务可规则化程度越高，Skill 的杠杆越大；任务开放性越强，Skill 的提升就越有限。
后续我会继续扩展两类评测。一类是动态 Skill 生成，也就是让 Agent 在第一次遇到陌生任务时，自己生成一个临时 Skill 并注册到记忆区，看第二轮表现是否比直接让模型硬答更好。另一类是组合 Skill 的冲突消解，比如同时加载“行动项提取”和“情感分析”时，模型怎么处理输出格式不同导致的融合问题。这些方向比单纯堆砌技能数量更有意思，也更贴近真实生产环境。
最后再分享一个小技巧：写 Skill 时，在执行器函数的最后一行不要返回纯字符串，而是返回一个标准化的 dict，其中一个 key 固定为 status，另一个是 data。这样无论模型怎么调用，你都可以在框架层做统一的日志和观测，排查问题的效率会高很多。这招是我在踩了三次“返回格式不一致”的坑之后总结出来的，实测下来非常稳。
