AI Agent Skill 脚本开发：何时该写与绝不能写

在 AI Agent 的业务落地中，很多开发者习惯直接使用别人写好的 Skill，却从未思考过一个关键问题：创建 Skill 时，什么时候该写代码脚本，什么时候绝对不能写？ 这不仅是一道常见的面试题，更直接决定了 Agent 系统的稳定性、成本与可维护性。

本文基于 B站相关教程内容，系统梳理 Skill 脚本的定位逻辑与设计决策原则，帮助开发者在实战中少走弯路。

Skill 脚本的本质：弥补大模型的短板

要理解什么时候该写脚本，先要搞清楚脚本在 Agent 架构中的角色定位。

大模型擅长的是理解、推理与自然语言处理，但它天生不擅长精确计算、对接外部系统、保证输出格式稳定。脚本的价值，正是用来承接这些大模型做不好的「脏活累活」。

换句话说，脚本和大模型是互补关系：模型负责理解意图、组织语言，脚本负责执行确定性强、要求精确的任务。你当然可以让大模型帮你生成 Skill，但是否需要配脚本，这个决策往往需要开发者自己来判断。

什么时候必须写脚本

结合实际业务场景，有三类情况几乎必须为 Skill 配上脚本。

对接外部系统与数据库

当 Agent 需要查询数据库、调用第三方业务接口时，如果不提供脚本，Agent 很可能会反复试探——参数错了就多轮重试，大量消耗 Token，轮次变多、上下文记忆膨胀、响应变慢，而且很容易把调用参数写错。

把这些能力封装成脚本后，Agent 可以直接调用固定好的接口，省去了这些无效折腾，稳定性和效率都大幅提升。

Token 消耗是 Agent 系统的核心成本之一。大模型每次推理都按输入+输出的 Token 数量计费，多轮重试不仅直接增加费用，还会让上下文窗口（Context Window）快速填满。主流大模型的上下文窗口通常在 8K 到 128K Token 之间，一旦历史对话过长，模型可能开始"遗忘"早期信息，导致行为异常。将外部系统调用封装为脚本，本质上是把不确定的多轮探索压缩为一次确定性调用，既省钱又防止上下文污染。

固定运算与格式处理

数值统计、时间转换、JSON 组装这类确定性任务，如果交给大模型处理，容易出现算错数字、输出格式错乱，偶尔还会产生幻觉，结果极不稳定。

用脚本把逻辑写死，自己完成格式转换和统计，输出就变得可控，不会随机翻车。

复用已有脚本

对于已经存在的运维脚本、编译脚本等，没必要让大模型用提示词重新复刻一整套逻辑。复杂逻辑复刻不全容易出错，而且是在重复造轮子。

正确做法是直接调用现有脚本，拿来即用。

什么时候绝对不能写脚本

反过来，有三类场景如果强行用脚本实现，会带来灾难性的维护成本甚至线上事故。

口语化语义理解与意图识别

以电商客服为例，用户说「我要买奶茶」「我要点外卖」，这些表达需要触发后续的下单逻辑。如果你用脚本去做意图识别，就得写海量的 if-else 和正则表达式去穷举用户的各种说法。

问题在于，用户换一种表达方式脚本就失效了，后续你得不停改代码，越改越乱，维护成本爆炸。这类任务应该交给意图识别模型，而不是硬编码脚本。

意图识别模型（Intent Recognition Model）是专门用于将自然语言输入映射到预定义意图类别的模型，与通用大模型不同，它通常经过大量对话数据的专项微调，能以极低的推理成本稳定处理用语多样的用户表达。在工程实践中，意图识别往往作为 Agent 的第一道路由层，先判断用户想做什么，再交由对应的 Skill 执行，从而避免让通用大模型承担不擅长的分类决策，也避免用脆弱的规则代码维护无穷无尽的表达变体。

频繁变动的业务规则

业务规则经常变，如果用脚本实现，每次改产品需求都要改代码、调试、重新发布，迭代节奏完全被拖慢。

更好的方案是改用配置 + Prompt 的组合——改配置就能调整行为，不用动代码，大幅提升迭代效率。

「配置 + Prompt」模式是一种常见的 Agent 工程实践：将易变的业务规则（如折扣策略、审批门槛、话术规范）写入外部配置文件或知识库，Agent 在推理时动态读取并注入到 Prompt 中，而无需修改代码或重新部署。这种方式将「需要写代码才能改」的变更，降级为「改一个配置文件」，让产品、运营人员也能自主调整 Agent 行为，极大缩短迭代周期。与之对比，把业务规则硬编码进脚本，等同于把产品决策权锁死在了工程侧。

高危操作

删数据、修改线上配置这类高危动作，如果交给脚本并开启自动执行，Agent 可能在条件判断不到位的情况下误触，直接引发线上故障。

这里要特别注意：脚本可以写，但不能交给 Agent 自动执行，必须引入人工审核环节，由人来介入确认。

一句话决策原则

下次面试官问到「Skill 脚本什么时候该写、什么时候不该写」，记住这个判断框架：

• 该写脚本：涉及精确计算、对接外部系统、复用已有脚本
• 不该写脚本：涉及意图识别、频繁变动的规则、高危操作

这套原则的核心逻辑其实很简单——确定性强、要求精确的任务交给脚本，灵活性高、依赖理解的任务交给模型，高危操作则必须留出人工介入的空间。掌握这个分界线，就能在 Agent 的 Skill 设计中做出更合理的工程决策。