★ FEATURED ARTICLE 这两年做 AI 代理落地我最大的一个感触是很多团队把精力都花在选模型、调提示词上却忽略了一个更基础也更值钱的东西——技能库。所谓技能库就是把希望代理“会做”的动作预先拆解成一组结构化、可复用、可编排、可评估的原子能力。Marketingskills 项目就是典型的营销域 AI 代理技能库实践把内容生产、受众分析、竞品摘要、投放复盘这些高频营销动作变成代理真正能调用的技能再用统一的执行器把它们串联起来形成一条从“自然语言需求”到“业务交付物”的流水线。如果你正在做 AI 代理类应用或者想把自己的营销运营经验产品化这篇文章值得读完。我会从为什么需要技能库、技能怎么定义、执行链路怎么搭、踩过哪些坑、怎么评估效果这几个角度把整个项目的技术骨架和实操经验拆开讲清楚。即使你现在不碰营销域这套“技能定义—注册—路由—执行—评测”的方法论一样能平移到客服、研发效能、人事运营等其他场景影响范围远不止营销本身。1. 项目定位为什么营销 AI 代理需要“技能库”而不是“提示词库”1.1 提示词控制的是“怎么说”技能库控制的是“做什么”不少人一开始做营销代理第一反应是写几十条提示词把品牌调性、文案风格、投放话术全塞进去然后指望模型自己“理解”营销。这种做法的瓶颈很明显提示词再长模型也只是在“说”它没有能力去查昨天的投放数据没有权限去拉竞品信息更不知道什么场景该调什么接口。说白了提示词库培养的是一个话痨不是一个干活的员工。技能库的思路完全不同。它把营销动作拆成一个个有输入、有输出、有工具绑定、有验收标准的任务单元。比如“生成广告文案”是一个技能“拉取指定渠道的投放数据”是另一个技能“做竞品动态摘要”又是一个技能。代理接到用户请求后先判断该调用哪些技能再按技能定义去执行最后把多个技能的结果拼装成最终交付物。这个过程更像是在给代理一张 SOP 表而不是一本话术手册。我经常用一个类比把代理当成新来的营销实习生。你给他一本写满漂亮话的提示词手册他只能陪你聊天你给他一份“任务—步骤—工具—验收标准”的作业流程再配上系统权限和函数接口他才能真正交出周报、复盘、投放建议这些业务成果。技能库就是那张作业流程表外加一整套工具箱。1.2 技能库要解决的三个核心问题第一是可复用。同一个“竞品摘要”技能内容团队可以用来盯竞品动态投放团队可以用来分析竞品素材产品团队可以用来做功能对标。如果这些能力以提示词形式散落在各个文档里每个团队都得各写各的口径还经常对不上。做成技能之后一次定义处处调用改一处全局生效。第二是可编排。营销任务很少有单技能能完成的。一个常规的月度复盘至少要经历“数据拉取—指标汇总—异常检测—复盘结论生成”几个环节。技能库允许你把多个技能组成工作流让代理按顺序执行前一个技能的输出直接作为后一个技能的输入。这样业务上一条完整链路在系统里就是一张编排清单需求一变改编排就行。第三是可评估。纯提示词方案最难回答的问题是“它到底做得好不好”。技能库把每个能力的输入输出都结构化了你可以在历史请求里抽一批典型样本标好期望的技能选择、参数内容、输出特征做成评测集。以后每次改技能拿同一套评测集跑一遍就知道是变好了还是变差了。这个能力是生产级应用和 demo 的分水岭。1.3 总体架构的选型思考在做架构选型时我参考了生产级 Agent 系统的常见分层最后把 Marketingskills 项目切成了七个模块技能定义层每个技能一个 YAML/JSON 文件描述它的名字、用途、参数、执行器、输出格式和示例。技能注册表启动时扫描技能目录、解析元数据、绑定执行函数建立内存索引。路由编排层由大模型根据用户请求从技能列表里选出候选技能并填充参数这一步本质上是函数调用。执行器真正运行技能函数调用外部工具连接器返回结构化结果。工作内存在多技能串联时保存中间结论和关键摘要避免上下文爆炸。护栏层做参数合法性校验、敏感信息过滤、输出格式检查。观测与评测层记录调用链路、技能命中情况、参数质量供离线评测和线上回溯。这样的分层设计有什么好处最直观的一点是“哪个环节坏了就换哪个”。今天换一个大模型技能定义和执行器不需要重写明天换一个数据源接口只需要改连接器后天想增加一道人工审核也只需要在护栏层加一个节点。分层让整个系统可测、可替换、可演进这是撑起后续所有迭代的地基。2. 技能定义与目录设计把营销动作变成可调用的函数2.1 技能的本质可被模型调用的业务动作把技能理解成“带语义的函数”会更准确。它和普通函数的区别在于函数的参数是给程序员看的技能的参数是给大模型看的。模型不是靠读源码来理解技能而是靠一段描述性的元数据来学会“什么时候用、传什么参数、拿到什么结果”。所以一个技能至少要包含五类信息第一给模型看的名字和描述第二参数结构包括必填项、可选项、类型、示例值第三执行函数真正跑逻辑的代码第四返回结构声明告诉模型结果长什么样第五示例样本包括正例和反例。缺少任何一个维度都会在路由选错、参数幻觉、结果解析失败上付出代价。我在设计技能 schema 时参考了主流大模型函数调用function calling的规范把参数定义为 JSON Schema因为这是模型和代码两端都比较容易理解的标准格式。技能名必须用“动词宾语”结构避免抽象营销术语比如用generate_campaign_copy而不是marketing_optimization。2.2 技能定义与参数设计规范下面是一个真实场景下“生成周报”技能的简化定义你可以照着这个格式去建模自己的技能{ name: generate_marketing_report, version: 1.2.0, description: 根据指定的时间范围、渠道集合和业务指标生成面向管理层的市场营销周报。适用于周度复盘、月度复盘、活动专项复盘。不适用于财务预测或销售预测。, parameters: { type: object, required: [time_range, metrics], properties: { time_range: { type: string, description: 统计时间范围格式 YYYY-MM-DD 至 YYYY-MM-DD, examples: [2025-01-06 至 2025-01-12] }, channels: { type: array, items: { type: string }, description: 需要的渠道子集缺省表示全部渠道, examples: [华东投流, 私域社群] }, metrics: { type: array, items: { type: string }, description: 需要包含的核心指标可选范围曝光、点击、CTR、CVR、转化成本、ROI, examples: [曝光, 点击, CVR] } } }, executor: report_skill_executor, returns: 结构化 Markdown 文档包含摘要、核心指标趋势、异常波动说明, examples: [] }这个定义里有几个容易被忽视的细节。description 一定要写“适用条件”和“边界条件”。我写了一句“不适用于财务预测或销售预测”作用就是告诉模型别在错误场景里硬套。参数描述里的 examples 也很关键因为模型对示例值的敏感度远高于对格式说明的敏感度你给它一个“2025-01-06 至 2025-01-12”它就更容易输出同样格式的时间范围而不是自己发明一个带着时分秒的时间戳。2.3 营销域技能清单与编排关系营销域可技能化的动作其实不少但真正值得第一批做进库里的都是高频、口径清晰、结果容易判定的动作。以下是我在项目中常用的技能清单供你规划自己的技能库技能名称核心输入输出依赖工具audience_analysis人群筛选条件、时间范围结构化人群特征报告数据平台查询接口competitor_intelligence竞品名称、时间范围竞品动态要点列表第三方情报接口content_generation选题、受众画像、风格、字数多版本内容草稿大模型生成服务copy_optimization原始文案、目标人群、投放目标优化版文案与修改说明大模型生成服务seo_keyword_suggestion主题、种子关键词、目标市场关键词分组与建议列表关键词研究接口campaign_performance_review投放计划 ID、时间范围复盘结论与异常项列表广告平台报表 API技能之间不是孤立的。比如用户说“帮我看一下华东区上周投放做一个周报”系统实际上要走一条链路先用data_pull技能去广告平台拉数据再用campaign_performance_review做异常检测接着用audience_analysis看人群结构变化最后用generate_marketing_report把结果拼成周报。这就是编排的价值把一条业务主线分解成多个可复用的技能节点任何一个节点都可以单独替换或升级。2.4 技能仓库的组织与版本管理技能多了之后最怕的是“改坏了不知道”。我把技能仓库当作一个代码仓库来组织每个技能占一个目录包含元数据、执行代码、测试样本三件套skills/ audience_analysis/ skill.yaml executor.py tests/samples.json report_generation/ skill.yaml executor.py tests/samples.json shared/ connectors/ schemas/技能也做语义化版本管理接口不能随便乱改。参数增删属于大版本变更影响面大只改描述文案属于小版本可以直接发布。评测集跟着技能版本走一个技能换了版本就跑一遍对应版本的评测集确认没有回归才允许上线。这个习惯让我后期省了无数排查问题的时间。3. 核心实现拆解从注册表到执行器的完整链路3.1 技术栈与模块划分Marketingskills 项目的实现语言我选了 Python原因很现实营销数据分析、脚本工具、模型 SDK 几乎都能在 Python 生态里找到现成的东西团队协作成本也低。模型层用的是支持函数调用的主流大模型 API执行器模块通过 FastAPI 暴露 HTTP 接口方便和现有的营销工作台、协作工具对接连接器层统一封装外部 SaaS 接口。模块划分遵循一个原则核心引擎保持轻量业务逻辑下沉到技能内部。注册表只负责“找技能”路由层只负责“选技能”执行器只负责“跑技能”外部依赖全部藏在连接器后面。这样一来某个广告平台的接口升级了只需要改对应的连接器技能定义完全不用动。3.2 注册表把技能变成可检索的资产注册表是技能库的大脑。它的职责是启动时扫描技能目录、解析技能元数据、绑定执行函数然后在内存里维护一份可检索的技能列表。下面是一个核心代码骨架from dataclasses import dataclass, field from pathlib import Path import yaml import importlib dataclass class Skill: name: str version: str description: str parameters: dict executor: callable examples: list[dict] field(default_factorylist) enabled: bool True class SkillRegistry: def __init__(self): self._skills {} def load_skills(self, directory: Path): for skill_file in directory.glob(*/skill.yaml): raw yaml.safe_load(skill_file.read_text()) executor importlib.import_module( fskills.{raw[name]}.executor ) skill Skill( nameraw[name], versionraw[version], descriptionraw[description], parametersraw[parameters], executorexecutor.run, examplesraw.get(examples, []), ) self._skills[skill.name] skill def get_skill(self, name: str): return self._skills.get(name) def list_enabled_skills(self): return [s for s in self._skills.values() if s.enabled]这段代码的核心价值是“把技能变成可检索的资产”。业务同学只要会写skill.yaml就可以在半天内新增一个技能不需要理解模型和路由的细节。注册表保证了所有技能都以同样的标准进入系统而不是散落在各处没人维护。3.3 路由与执行器让模型选得对、跑得稳路由是技能库最容易出问题的环节。我的做法是让模型优先让代码兜底。模型的职责是从技能列表里选出候选技能并填充参数代码的职责是检验模型的选择和参数是否合法。路由分四步走把启用中的技能列表压缩成“技能名描述参数 Schema”交给模型。模型返回一个候选调用计划包含技能名和参数。代码逐项校验技能是否存在、参数是否符合 JSON Schema、必填项是否齐全。校验不通过就触发一次修正流程让模型重新选择或者直接向用户提出澄清问题。代理执行的核心逻辑可以抽象成下面这个流程def plan_and_execute(user_request, registry): skills registry.list_enabled_skills() schema [ { name: s.name, description: s.description, parameters: s.parameters, } for s in skills ] plan llm.select_skills(user_request, schema) for call in plan[calls]: skill registry.get_skill(call[name]) if not skill: raise SkillNotFound(call[name]) validated validate_against_schema( call[arguments], skill.parameters ) result skill.executor(**validated) plan[results].append(result) return llm.finalize(user_request, plan)这个设计把决定权交给模型把正确性留给代码。模型可以自由组合技能但传错参数、乱填时间格式这些低级错误被代码拦在门外。实测下来只要技能描述和示例做得到位路由命中率可以稳定在八成以上剩下的两成错误统一走修正流程就行。3.4 跑通一个完整场景生成华东区投放周报以“华东区上周投放周报”为例我带你走一遍完整链路。用户输入“帮我看看华东区上周的投放数据生成一个周报给我。”第一步路由层识别到两个核心意图一个是“看数据”对应data_pull技能另一个是“生成周报”对应generate_marketing_report技能。模型在参数里填入time_range为“2025-02-10 至 2025-02-16”channel为“华东区投放计划”metrics为“曝光、点击、CVR、ROI”。第二步执行器调用data_pull。这个技能内部封装了广告平台报表 API 的分页逻辑把华东区该时间段的投放计划、各天曝光、点击、转化、消耗全部拉回来做一次数据清洗。清洗完成后返回一个结构化数据集。第三步generate_marketing_report接收数据集内部做三件事汇总本周核心指标计算环比变化对比前四周均值做异常检测比如某天 CVR 低于均值两个标准差就标红。最后生成一份 Markdown 周报包含概览、趋势、异常提醒、建议动作四节。第四步模型拿到执行结果后结合用户的问题做最终回复。它的回答不再是一堆通用套话而是有真实数据支撑的结论“华东区上周曝光环比下降 12%主要原因是周一素材审核失败导致停投 3 小时CVR 整体稳定但周三新素材点击率明显偏低建议重新测试素材方向。”这个场景的价值在于代理做的事情从“生成一段貌似专业的回答”变成了“基于真实数据完成一次业务分析”。技能库让代理第一次有了业务交付能力。4. 实操中的坑与经验记录从 0 到 1 搭建时的避坑指南4.1 先做三个技能别急着扩库我最初犯过一个错误一口气规划了二十多个技能从内容生成到预测建模都想覆盖。结果一周后发现根本维护不过来评测集没法建模型经常在相似技能之间摇摆比如把content_generation和copy_optimization混在一起用。后来我砍到只剩三个技能才跑通闭环。第一批技能怎么选我给三个标准高频业务里每周都会用到的口径清晰对“什么算对”有统一认知的结果易判定人工很快能判断输出好坏的。按这个标准第一批通常就是“数据拉取”“报告生成”“内容产出”。这三个技能形成一个最小闭环先把注册、路由、执行、评估这条链路跑顺再往后扩就轻松得多。4.2 工具接口集成的三个深坑连接外部营销工具是踩坑重灾区我挑三个最典型的说。第一个是鉴权与 token 过期。很多营销平台接口的 access_token 有效期很短如果直接在技能里硬编码 token第二天就全部失效。我的做法是连接器统一管理 token 的获取、缓存、刷新技能参数里永远不出现 token 字段。第二个是分页与数据量上限。广告平台报表接口通常有单次返回量限制不处理分页就会出现数据被截断周报里的数字和后台对不上。每个数据类技能内部都要封装分页循环同时暴露一个limit参数避免用户无感知地拉取超大范围的数据导致超时。第三个是字段语义映射。这是最隐蔽的坑“曝光”和“展示次数”在两个平台可能是一个意思“点击”在不同系统里可能计入或不计入同一种交互。如果技能之间不做统一口径最后对比数据时会发现各说各话。我加了一层 normalization在技能内部把不同平台字段换算成统一内部口径再输出这样下游技能看到的永远是同一套语义。4.3 上下文与工作内存的管理多技能串联最大的问题是上下文被撑爆。早期版本里data_pull执行后会把几千行原始数据全部塞回对话上下文结果后续技能生成报告时经常“记忆错乱”引用错数字甚至编造不存在的指标。解决思路是引入工作内存和工作摘要。每个技能执行完不是把所有原始结果回传给模型而是返回一份压缩后的结构化摘要写进共享内存。模型最终生成时只读这份摘要加上必要的汇总指标不读全量明细。我给自己定了一条上下文预算规则用户请求约 200 token技能描述约 100 token 每个工作摘要控制在 2000 token 以内。超过预算就强制触发一次摘要压缩。这样既保住了关键信息又给模型留下足够的生成空间。4.4 技能描述文案的四个技巧技能描述写得好不好直接决定模型能不能选中正确的技能。这里有四条实战经验每条都踩过坑才总结出来的。技能命名必须“动词宾语”。比如generate_campaign_copy就比copywriting清晰得多模型一眼就知道这个技能是要干什么。description 里必须写“适用条件边界条件输出形式”。例如“仅用于基于已有投放数据的周报生成不要把它用在财务预测上”这句话能挡住大量错误路由。参数 description 一定要给示例值。别只写“时间范围”要写“时间范围格式 YYYY-MM-DD 至 YYYY-MM-DD例如 2025-01-06 至 2025-01-12”。模型对示例的模仿能力远超对抽象规则的遵循能力。给每个技能配 3 条正例和 1 条反例。反例的价值很大比如“用户问‘今天吃什么’时不要调用竞品摘要技能”这能显著降低无关请求对技能路由的干扰。5. 质量评估与回归测试让技能库越用越稳5.1 评测集技能库的命根子没有评测集的技能库就像没有测试用例的代码库改一发就能崩一晚。我从第一个版本开始就同步构建评测集规模不大但覆盖了典型的营销请求类型。评测样本用这个结构组织[ { request: 看一下华东区上周投放给我一个周报, expected_skills: [data_pull, generate_marketing_report], expected_params: { time_range: 2025-02-10 至 2025-02-16, channel: 华东区投放计划 }, check: [ output_contains_ctr, output_contains_anomaly, output_has_action_items ] } ]评测集不是一次性资产每周都应该往里补充新样本尤其是线上出现过误判、漏判、选错技能的请求。这些真实记录比人工想象出来的测试用例有价值得多因为它们是实际业务流里最容易翻车的地方。5.2 四个关键指标与目标值评测指标不要贪多我长期只盯四个各有侧重指标定义合理目标技能命中率模型选中的技能与期望技能的交集数 / 期望技能数不低于 0.85参数完整率必填参数被正确填写的比例不低于 0.90执行成功率技能调用无异常且返回结构化结果的比例不低于 0.95输出可用率人工或评审模型认定“可直接交付”的结果占比不低于 0.80这四个指标单独看都不完善合在一起就是一个完整的体检报告。参数完整率反映模型对技能定义的理解程度命中率反映技能描述的质量执行成功率暴露连接器层的稳定性输出可用率是对端到端质量的最终判断。如果命中率低先改描述如果参数完整率低先补示例如果执行成功率低查连接器如果输出可用率低问题多半出在最终生成环节的提示词和上下文管理上。5.3 让评测跑在发布之前评测不能只在开发阶段做要把技能库当成一个需要持续发布的产品来运营。我的做法是把评测集成进发布流程每次技能定义或执行器有改动先跑一遍评测集任何指标低于阈值就拦下来线上流量按比例灰度新技能或新版本先只让 10% 的请求命中观察一周执行成功率和用户反馈稳定之后再全量放量。灰度发布需要注册表支持 canary 标签给新旧版本标记不同流量比例。这个机制成本很低但价值很大因为很多问题只会在真实用户请求里暴露而灰度期就是你的安全缓冲带。6. 从营销技能库到通用代理技能库影响范围的延伸6.1 可复用的抽象层价值做完营销技能库之后你会发现一个很有意思的事技能的定义规范、注册表、路由逻辑、评测机制几乎和“营销”这个业务域没有关系。换到客服域只需要把技能换成“工单查询”“话术推荐”“客户情绪分析”换到研发域只需要把技能换成“代码检索”“缺陷分类”“发布检查”换到人事域只需要把技能换成“简历筛选”“面试反馈汇总”“入离职流程查询”。这就是抽象层的价值。你真正积累下来的不只是几个营销技能而是一套代理技能化的方法论业务能力怎么拆、元数据怎么写、路由怎么调、评测怎么建。模型和工具可能会频繁更换但技能资产会随着积累越来越值钱。这是 AI 代理类项目里最值得投入的长期资产。6.2 下一步可做的三个方向顺着这套架构有三个方向我比较看好也是我准备在后续迭代中做的。第一个方向是技能自动生成。从历史日志里找出高频的“用户请求—技能组合”对用大模型自动生成技能草稿人工审核后入库。这能把建库成本压得很低适合技能库从几十个往几百个扩展的阶段。第二个方向是技能商店。技能定义可以跨团队、跨项目共享一个团队沉淀的“竞品摘要”技能另一个团队可以直接安装复用。这会让技能库从内部资产变成组织级资产。第三个方向是人工审批节点。对高风险的技能比如对外发布内容、大额投放建议执行前加一道人工确认。技能库和审批流结合起来才能放心地把代理接进真正影响业务结果的流程里。我自己的体会是判断一个 AI 代理项目稳不稳就看它的技能库长什么样。技能定义得清楚后面几乎水到渠成定义得含糊再强的模型也救不回来。如果你正在做类似的 Agent 项目我的建议是克制一点别一口气规划五十个技能先把三五个真正高频、口径统一的技能做扎实完整跑通“注册—路由—执行—评估”这条闭环再逐步扩展。最后分享一个小技巧每次线上出现一次技能误选都把它追加进评测集然后回头看看是描述问题还是参数问题。一个月之后你再翻这些记录会发现自己对“模型如何理解技能”这件事的理解比做任何提示词工程都要深得多。
阅读完成 · 觉得有帮助？
