推文

@kafkaup · 2026-10-15 07:54

一个偏产品工程化的话题：企业级的 skill 应该怎么写？ 很多团队在做 Agent 或者 workflow 的时候，skill 写得很草率：一个 name、一个 description，加上一大段 prompt，看起来能用。但随着 skill 的数量越来越多，就会出现新的问题。比如模型无法准确命中，该调用的时候不调用，不该调用的时候调用了；或者一大段无关紧要的东西被塞进上下文，导致 token 成本浪费；更严重的是，有时 skill 之间的职能边界不清，还会导致模型产生幻觉和越权执行。 所以，企业级 skill 的问题不能只理解成怎么把提示词写得更完整，它更像是在设计一个可以被模型发现、调用、执行和维护的能力模块。 企业级 skill 最关键的一点是分层：不同的信息应该放在不同的位置，每一层都有对应的服务场景。我一般会把它拆成四层：触发层、执行层、兜底层和参考层。 1. 触发层 决定模型什么时候要调用这个 skill。这里主要写 name 和 description，但 description 不能写成宣传语，也不能把所有执行细节都塞进去。它应该写清执行什么任务、典型的触发场景是什么、不适用场景是什么，以及和相邻 skill 的边界在哪里。 这层的作用非常明确，就是帮助模型做 discovery 和 routing（在一堆 skill 里找到正确的那一个）。因为触发层经常暴露给模型，所以要短、准、边界清晰；写太长不仅增加成本，还会让模型误以为什么场景都可以调用它。 2. 执行层 决定 skill 在被调用后应该怎么完成任务。在这一层才适合写入具体的执行规范，比如输入要求、处理步骤、关键参数、工具调用、输出格式和质量标准。企业级 skill 最怕每次输出都不一样，这不仅让能力显得很不稳定，工程上也难被后续流程消费。 执行层的流程一般包括几个部分： (a) 进入任务前检查输入是否足够 (b) 抽取关键对象和目标任务 (c) 按照固定的维度来处理 (d) 输出时遵守固定的格式 (e) 明确哪些内容可以推断，哪些内容必须标注不明确 如果会调用工具，也要写清楚调用条件：比如什么时候需要检索，什么时候只基于用户上传的文件，什么时候先做结构化提取，什么时候需要等待用户确认。这一层的目标是减少模型的自由发挥，让它按稳定的流程交付。 3. 兜底层 解决异常情况发生时该怎么处理。很多人写主要流程很清楚，但几乎不写异常处理，然而在实际产品里，异常才是常态：用户可能没有上传文件、参数缺失、工具失败、外部依赖失效、检索没有结果、依赖系统超时，或者用户请求超出了能力边界。如果这些不提前写清楚，模型就容易硬凑、编造、误调用，或者在错误路径上执行。 兜底层要明确几类策略：缺少必要输入时追问、工具失败时说明原因、结果置信度低时标注不确定、超出能力边界时拒绝或转到其他 skill、涉及高风险操作时等待确认等。兜底层也可以理解为异常处理和治理策略，它不只是 fallback，还包括追问、降级、拒绝、转人工、停止执行和安全提示。 4. 参考层 解决哪些资料需要在必要时加载。这里可以放模板、schema、术语表、示例库、业务标准、行业规范、few-shot 等。 参考层的原则是：不要默认全部塞进主 prompt。数量少时或许能接受，但数量一多就会变成 token 黑洞，模型看到大量无关信息既耗成本，又容易误触发或幻觉。所以参考层必须按需加载：要求固定格式时再输出模板，需要结构化 JSON 时再加载 schema，进入专业场景时加载术语表或行业规则，需要风格对齐时再加载示例等。能挂载就不要常驻，能按需就不要预加载。模型看到的信息越多不一定越好，信息要在正确的时机出现。 总结一下，企业级 skill 按照四个层级来写： • 触发层：让模型知道什么时候该用它 • 执行层：让模型知道调用后该怎么做 • 兜底层：让模型知道遇到参数缺失、低置信、工具失败和越界请求时该怎么处理 • 参考层：把模板、schema、示例等按需加载，避免一开始就把上下文塞爆 再往产品设计上抽象一点，skill 不是一段长提示词，而是一个被模型调度的能力模块：它既要能被正确发现，也要能稳定执行，还要在失败时可控、在需要资料时按需加载参考。这样写出来的 skill 才不会越写越重、越写越乱，才真正接近企业级可维护的水平。

曝光 296 · 评论 1 · 点赞 0 · 书签 2 · 曝光/时 180.97681272023127