★ FEATURED ARTICLE 最近半年我一直在做营销场景的AI代理项目最头疼的从来不是大模型本身跑得好不好而是怎么让模型稳定、可控地调用各种营销能力。今天想通过梳理 Marketingskills 这个项目聊聊我搭建AI代理营销技能库时的完整思路。这个项目解决的核心问题很直接营销团队有大量分析、内容生成、投放优化、用户分群的需求但这些能力分散在不同系统里模型要么不知道怎么用要么用起来全靠运气。技能库做的事情就是把营销能力组织成一套标准化的、可注册、可调用、可评测的模块让AI代理真正听得懂、调得动、还调得准。这篇文章适合两类人一类是正在做AI代理落地的工程师另一类是负责营销自动化或数字化转型的产品经理看完整套技术路径基本能判断自己的项目适合同样的做法。1. 技能库的整体设计思路1.1 为什么AI代理需要技能库而不是一堆Prompt我在项目前期走过一段弯路当时团队的想法很简单把各种营销分析需求写成Prompt模板塞给模型让它自由发挥。结果很惨烈。同样一个帮我分析上周各渠道的广告效果的问题模型今天会自己编一个ROI算式明天又会把口径完全搞错后天干脆拒绝回答。问题出在哪出在模型只能靠语义理解猜测你的意图但它不知道你的数据表结构、不知道你的定义口径、更不知道该调用哪个内部接口。后来我换了个角度看这件事大模型就像一个刚入职的高智商实习生它不缺理解力缺的是岗位说明书和工具手册。你说分析一下投放数据它想问去哪拉数据什么叫分析口径是什么输出什么格式当你给它一套标准化的技能库每个技能都明确写清楚这个技能能干什么、需要什么参数、会返回什么结构、遇到什么情况不适用它就能像一个干练的助理一样先选工具再执行任务不再自由发挥。这背后的核心逻辑是把模型会思考的优势和程序确定性执行的优势结合起来。模型负责意图识别和表达组织技能库里的每个技能负责确定性的数据和动作。两者一组合既有灵活性又有可控性。这才是AI代理能落地的关键也是我在做 Marketingskills 这个项目时最重要的一个认知转变。提示技能库本质上不是模型追加的知识而是一层介于大模型和业务系统之间的能力编排层。它的好坏决定你的代理是专业助理还是花哨玩具。1.2 技能库的四个核心模块在设计技能库时我没有一开始就写代码而是先梳理了它必须包含的四个核心模块缺一个都会在后面的迭代里踩坑。第一个是技能描述描述文件用自然语言和结构化字段说明技能的用途、适用场景、参数约束和输出格式。它解决的是模型什么时候该选这个技能的问题这一层会直接影响意图路由的准确率。第二个是参数Schema定义每个技能的输入输出结构。比如一个广告账户日报技能入参需要账户ID、日期范围、数据维度出参需要曝光、点击、花费、转化数、成本等字段。参数Schema的主要作用是让大模型知道该怎么格式化地向技能传递数据避免出现模型传了个字符串、接口却要数组这种鸡同鸭讲的状况。第三个是执行函数也就是技能真正触达业务系统的逻辑。它可以是内部接口的封装、SQL查询的模板、投放平台的操作脚本甚至可以是另一个模型的调用。执行函数必须幂等、可重试、有超时处理因为AI代理发起的调用频率和人为操作完全不同系统崩溃和重复提交的概率会高很多。第四个是评测用例这是很多人容易忽略但又最重要的部分。每个技能都要配一组可执行、可断言、可回归验证的测试数据。比如渠道ROI对比技能就要准备一组已知答案的历史数据用来验证每次改动后技能输出是否依旧正确。这四个模块合在一起就构成了一个完整的技能节点。单个技能节点好写难的是把它们组织成一套能让产品快速扩展的体系。后面的章节我会展开讲技术细节。2. 技能定义标准与营销场景拆解2.1 用接口文档的思路定义技能我是做后端出身所以从一开始我就用接口文档的思维来定义技能。每个技能的本质就是一份同时写给人和机器看的说明人读了知道这个技能做了什么模型读了知道该在什么场景下调用它。这里我分享一个实测效果很好的技能描述模板类似YAML结构skill: name: campaign_roi_analyzer description: 计算各渠道广告投放的ROI支持按时间范围和转化口径进行筛选。 trigger: 当用户提到广告效果ROI投产比渠道表现等关键词时优先考虑该技能。 avoid: 当用户只询问营销活动的创意内容或文案建议时不要使用该技能。 category: data_analysis version: 1.2.0 input: - name: date_range type: string required: true description: 日期范围格式为 YYYY-MM-DD~YYYY-MM-DD最多支持90天。 - name: channels type: array required: false description: 渠道列表允许的枚举值包括 natural_search、paid_social、paid_search、email。 - name: conversion_metric type: string required: false default: roi description: 转化口径支持 roi / cpa / ctr 三种枚举。 output: type: array fields: - name: channel type: string - name: spend type: number - name: revenue type: number - name: roi type: number notes: 数据来自数据仓库每天凌晨2点更新查询当天数据可能不完整。你可能注意到我特意写了trigger和avoid两块这是我在实践中总结出来的重点。只写一段笼统的 description模型经常误判。比如一个同时掌握了内容创作和数据分析技能的代理用户问帮我看看上个月哪条文案转化最好它可能用内容创作技能生成一段新文案而不是用数据分析技能去查历史转化数据。加了触发词和排除条件后命中率会明显提升。我自己的经验是加了这两个字段之后技能选择的准确率能提升至少十个百分点。写技能描述本身不是纯粹的技术活它需要大量业务语感。最好的写法是想象一个新人运营入职你用一句话告诉他什么情况下用这个工具什么情况下千万别用这句话就是技能描述的核心。2.2 营销技能的分类粒度营销领域的技能库如果不做分类很容易变成一个大杂烩。我在 Marketingskills 项目里把技能按业务逻辑分成了五个大类这个分类现在已经沉淀成了一块比较稳定的能力地图分享给大家参考技能类别代表技能核心价值常见调用场景内容生成类广告文案生成、落地页文案改写、邮件主题行A/B测试批量产出与品牌调性一致的内容帮我写5版双11预热海报文案用户分析类用户分群、RFM评分、高价值用户识别、流失预警让运营从经验驱动变成数据驱动把近90天高活跃高付费的用户单独分出来投放优化类预算分配建议、出价调整、渠道自动巡检把优化师的排查逻辑沉淀成可调用的动作本周哪个渠道预算超了30%数据分析类渠道ROI对比、漏斗分析、留存报表、归因报告快速响应业务日常看数诉求出一份上周各渠道消耗和转化的对比表流程自动化类线索打分入池、竞品监控简报、日报自动推送串联前四类能力形成完整的自动化闭环每天早上9点生成一份TOPLINE数据日报分类的意义不仅仅是文档好看它决定了两件事。第一技能库的检索范围可以按类别缩小模型对几十个技能的误选率远高于对五六个技能的误选率第二评测和权限控制可以分类进行比如分析类技能开放给全员投放优化类技能只开放给投放总监这样既能保护业务安全也能让代理的权限粒度更细。关于粒度我想多说一句。很多团队做技能库容易走极端要么一个技能管一大堆事要么一个技能只做一个小函数。我的建议是可交付、可维护、可复用三个标准一个技能必须能独立完成一个完整的业务动作而不是一个碎片函数同时它的实现逻辑要能被一个不熟悉代码的运营看懂最后它得能被多个场景复用。满足这三点粒度基本就是合适的。2.3 技能的版本管理与数据组织技能库的目录结构看起来是小事做不好却会直接拖垮团队协作。我在初期曾把几十个技能文件全部扔在一个目录里叫skills/结果两周之后谁都不敢改文件因为改动一个可能导致其他依赖它的技能一起出问题。后来我彻底重构了目录结构按类别/技能名/版本来组织skills/ content/ ad_copy_generator/ 1.0.0/ skill.yaml impl.py tests.yaml 1.1.0/ skill.yaml impl.py tests.yaml landing_page_writer/ 1.0.0/ skill.yaml impl.py tests.yaml data_analysis/ campaign_roi_analyzer/ 1.0.0/ skill.yaml impl.py tests.yaml为什么要把版本目录做得这么重因为AI代理的迭代速度和传统软件开发完全不同。今天你改了一个技能的描述明天所有依赖它的流程都可能发生变化。如果没有版本化出了问题根本没法回滚。我现在的习惯是任何一个技能只要被线上流程引用它的当前版本就不可变任何修改必须开启一个新版本并且新版本必须通过全部评测用例之后才能切换。听起来繁琐但这是保证线上代理行为稳定的基础。除了目录我还会在每个技能目录里维护一个CHANGELOG.md记录每次版本的改动原因、变更内容和影响范围。这也有一个实用目的后续模型评测如果发现某个行为发生了漂移我可以快速定位是哪个技能的哪次改动引起的。3. 工程实现从技能注册到模型路由3.1 技能注册与大模型函数调用技能定义好了接下来就是让模型看见这些技能。这一步我采用的做法是把技能库的Schema暴露给大模型的函数调用机制。具体拆分下来有三步启动时扫描技能目录读取所有skill.yaml解析出技能名称、描述、参数Schema把解析结果转换成模型平台要求的函数定义格式把函数定义随每次请求发给模型模型根据用户问题决定是否发起调用以及传入什么参数。这里有个细节值得注意技能的参数定义不要直接复制接口原始参数而是要在中间加一层面向问题的参数翻译层然后在这个逻辑层里处理从自然语言到业务参数的各种细节处理把用户说上周翻译成具体的日期根据默认值补齐缺失参数这类工作都应该在这一层完成。换句话说模型的函数调用结果不是直接对接API而是先进到一个参数解析和执行调度器里。我贴一段简化版的注册核心逻辑做个示意import yaml from pathlib import Path def load_skills(skills_dir: str) - list[dict]: schemas [] for skill_file in Path(skills_dir).rglob(skill.yaml): with open(skill_file, r, encodingutf-8) as f: skill yaml.safe_load(f) schema { name: skill[skill][name], description: build_description(skill[skill]), parameters: build_parameters_schema(skill[skill][input]), } schemas.append(schema) return schemas每次请求把几十个函数全部塞给模型评测下来效果不错因为技能schema本身包含的token量不大决策效率高适合快速响应场景。同时我也加入了按分类分组加载的能力比如数据类对话只加载数据分析和用户分析两类技能这样更稳也更省。3.2 技能执行链路的容错设计模型把参数传回来不等于任务就完成了。真正执行时链路中的不确定性非常高。我在技能执行器里重点设计了下面几个环节。第一步是参数严格校验也就是先启动一次严格的schema校验用校验函数检查必填字段是否完整、枚举值是否合法、日期格式是否正确。校验失败时不是直接报错而是返回一个参数缺失清单再把清单抛回给模型让它补参数。我之前试过让模型直接执行错误请求体验极其糟糕用户看到的就是一堆晦涩的报错。第二步是执行策略包括超时控制、重试机制、幂等控制。内部接口调用设3秒超时重试一次超过就降级外部投放平台调用设10秒超时配合接口登录状态检测因为外呼的稳定性和内网完全不同。重试必须考虑幂等性比如创建订单这种操作不能因为网络抖动就重复提交。第三步是结果回填目前我采用的是一种轻量方案先由执行函数产出结构化结果再由模型基于结果做进一步整理和自然语言表达。这里大家可以注意一下建议不要让模型直接操作原始数据表而是把已经算好的指标格式化好再交给模型包装措辞能大幅减少生成内容出错的风险。def execute_skill(skill_name: str, params: dict) - SkillResult: validator get_validator(skill_name) errors validator.validate(params) if errors: return SkillResult(statusparam_error, error_payloaderrors) skill_fn get_impl(skill_name) try: raw skill_fn(params) return SkillResult(statusok, dataraw) except SkillTimeoutError: return SkillResult(statustimeout, message技能执行超时请稍后重试) except SkillApiError as e: return SkillResult(statusupstream_error, messagee.message)这个封装的价值在于模型不再直接面对各种异常而是收到结构化的状态码和提示语。这样不仅出错时用户看到的反馈是友好的代码调试时也能清晰归因。3.3 评测闭环让技能库可持续迭代如果说技能注册和执行构建了代理的骨架评测闭环则是注入的血液没有它技能库会不断腐化。我在项目里建设了两层评测机制。第一层是离线回归集。每个技能都要配20-30条典型测试用例覆盖主路径、边界路径和反例。拿渠道ROI对比技能来说主路径是一组标准查询期望返回指定表格边界路径是查询天数超过90天应返回截断提示反例是用户问情感文案应判定不触发该技能。每次技能改动我都要全量跑一遍回归集任何一条用例挂了就必须修复后才能上架。第二层是在线行为指标。我设计了一个很简单的日志系统记录每次模型调用的完整链路用户问题、模型选技能的结果、参数解析结果、执行状态、用户是否追问。每周我会把模型选错技能率参数解析失败率执行超时率三个指标拉出来比一比。这个方法很土但很管用能直观反映模型和技能库的健康度。这里我也想强调一下技能评测不要只看答案对不对还要看路径稳不稳。同一个问题今天走技能A明天走技能B哪怕结果一样也是不稳定。对AI代理来说确定性有时候比创造性更重要因为业务方要的是一个可预期的系统。4. 踩坑实录与排查方法4.1 模型经常选错技能怎么排查这类问题在技能库上线初期的频率非常高。我处理模型选错技能问题的路径通常是翻日志看用户原话、模型选中的技能名称、模型给出的理由把错误case归类是描述不清晰、字段缺失、还是相似技能太多导致的混淆。如果是描述不清晰就按前面说的trigger和avoid语法重写描述。如果是字段缺失比如用户说看一下最近的数据但没有指明技能必须的转化目标那我就把旧的必填参数改成带默认值让模型不必追问也能完成执行。如果是相似技能太多比如同时存在广告文案生成和邮件文案生成它们描述高度重叠我一般选择合并成一个技能用参数区分场景反而效果更好。还有一种坑很多人想不到模型的系统提示词里如果写了太多关于你是营销专家之类的身份设定它会倾向于自由发挥而不是调用工具。我的经验是系统提示词越精简越好只保留必要的角色边界和输出风格把一切业务能力交给技能库去承载。4.2 参数传递老是出错模型传参数出错的症状很多比如把paid_social写成paid-social日期格式写成2024.05.01而不是2024-05-01字符串串传给数组字段等。我和团队做过一次统计参数类错误占技能执行失败原因的六成以上。解决问题的一个有效做法是在参数Schema中提供枚举值列表时加上也包括xxx的说法这类对语义的补充说明同时把每个参数的合理格式写更绝对一点比如只使用标准ISO格式不接受点号分隔。说实话模型还是经常漏看因此必须做一层宽松解析兜底例如日期解析函数里多支持几种分隔符渠道枚举词做一次别名映射把百度巨量广告映射到标准channel ID。工程上做兜底不一定非要模型完全遵守格式实用为主。4.3 技能执行结果与业务期望不符还有一种情况参数调用完全成功没有报错但输出的结论业务方完全不认同。这种问题不是模型的原因而是技能本身的分析口径或数据链路配置有问题。我遇到过一个典型case渠道ROI分析技能返回结果偶尔跟业务方自己导出的报表不一致。查了几个小时后发现数据仓库的表有一个分区延迟技能读的是当天分区业务方报表读的是前一天分区两边基数不同自然对不上。后来我在技能说明里明确标注了数据更新时间并且给技能加了一个data_freshness字段由执行函数强制校验超过延迟阈值就在结果里提示数据截至XX时间可能不完整。这样至少不会让业务方拿着过期数据做决策。这个案例给我的启发是一个技能的好坏不只看执行是否正确还要看它在数据链路异常时是否诚实。宁可让代理说数据暂未更新也不要让它拿着半成品数据硬算出一个自信满满的结论。4.4 性能与成本如何平衡技能库数量成长之后性能问题会慢慢浮现。我带项目时技能总数从十几个涨到五十多个每次请求都要把所有技能的Schema发给模型token开销变大响应变慢单次成本也随之上涨。我做了三个维度的优化。第一按对话场景做技能预分组把技能打上sales_botanalysis_botcontent_bot等场景标签启动不同bot时只加载对应的子集二是为高频查询做结果缓存比如本周各渠道消耗汇总这类重计算且数据变化不频繁的技能按照缓存key匹配并在十分钟内直接命中缓存三是把大段技能描述里相同的内容比如通用的时间格式说明、公共枚举值定义抽出来作为公共字段复用减少每个技能重复复制导致的token膨胀。优化手段解决的问题实际收益场景化技能分组技能数过多导致选择准确率下降模型选择准确率提升12%响应时间降低35%高频结果缓存重复计算浪费时间和成本单技能执行耗时从4秒压到0.3秒公共字段精简Schema过大导致token成本上涨整体token消耗下降20%左右降本增效的核心其实是不让模型做重复的苦力。凡是能用缓存、规则和预计算解决的计算都不要浪费模型的窗口长度和调用次数模型只负责它真正擅长的语义调度和表达。5. 扩展方向与实践心得5.1 从单技能调用走向技能编排技能库稳定运行一段时间后我明显感觉到下一个瓶颈不是单个技能的鲁棒性而是多技能的协同编排。比如用户问这个季度预算有限建议怎么分配到各渠道只靠单个技能对象跑不出来的需要先调预算结构分析技能算出现状再调渠道效率对比技能找到高效渠道最后可能还要调历史活动复盘技能寻找可复用经验。我在 Marketingskills 项目的后期已经尝试把这些复合任务流程沉淀成流程模板每个模板定义一个技能调用序列和执行条件。这样用户只需要表达一次目标代理就能按照预设的最佳路径逐步执行而不是每次都从零推理。这一步跨过去后整个项目的价值会从一个高效助理跃升为一套可复用的营销自动化工作流引擎。5.2 技能库的生态共建比孤岛建设重要最后说一点组织层面的体会。技能库如果只是工程团队自嗨价值有限。我做过一个尝试邀请业务团队的核心运营和投放同学一起参与技能描述评审请他们给每个技能写出他们认为的最典型的触发场景和最容易被误用的情况。结果他们写出的trigger单词比我们工程师写的精准得多。从那以后我基本固化了一个流程新技能上线前要做一次业务侧操作性问答至少找两位一线使用者确认描述再进评测。这种做法本质上是在行为层面对齐预期效果远远好于让业务只看一份技术文档。如果你也是刚开始搭技能库这个建议能帮你省掉大量后期的纠错成本。关于这个项目我个人最大的体会是搭建技能库最大的难点不在于写多少行代码也不在于调优某个模型而在于你是否能持续维护一套人和模型都能理解的业务共识。它既像一份严谨的接口契约又像一本不断更新的营销操作手册。只要这套共识在任何模型平台、任何营销系统都可以被平滑地接入你的代理体系。希望我踩过的这些坑和沉淀下来的方法能帮你少走一些弯路。
阅读完成 · 觉得有帮助？
)
