我最近完整复盘了一遍 Marketingskills 这个项目。它的目标说起来很朴素给营销场景里的 AI 代理建一个可扩展的技能库让代理不再只会“对话”而是能真正拆解、执行营销任务。做完之后我最大的感受是这个项目表面上是在写一堆技能模板本质上是在回答一个问题——营销工作流里哪些环节可以被标准化成代理能稳定调用的“动作”。这篇博文会把项目里的架构设计、技能封装方式、编排逻辑、评测与回归流程都拆开讲一遍也会把实际踩过的坑一并交代清楚适合正在做 AI 代理落地、或者想把大模型接进营销业务的同学参考。1. 为什么营销 AI 必须有一张“技能地图”1.1 从闲聊到干活差的不只是模型刚接触智能代理的团队很容易陷入一个误区只要把大模型的接口接进系统再给它挂一套营销知识库的检索能力它就能当营销助理用了。实际跑一段时间就会发现它的回答质量不稳定同一个问题换一个场景、换一个说法结果就飘。更严重的是它经常“只说不做”——给出了一大堆建议却没有产出任何可以直接使用的东西。这个问题的根源不在模型本身而在于代理缺少一套明确、可控、可复用的“动作单元”。对话能力解决的是“理解和表达”而营销任务需要的是“规划和执行”。这两者之间需要一层桥梁把模糊的营销需求翻译成一组可执行的标准化操作。Marketingskills 项目做的事情就是把营销领域的高频动作沉淀成一张技能地图让代理接到任务时能快速定位该调哪一个技能、按什么顺序调、以及每个技能的数据从哪里来、结果交给谁。我见过不少团队在同一个地方栽跟头他们花大量精力调试提示词希望模型“自己理解该做什么”但模型对同一个任务的判断每次都不一样。绕了一圈之后大家才意识到稳定性的瓶颈不在模型的聪明程度而在系统有没有把“该做什么”这件事实体化、模块化。技能库本质上就是这张标准化的操作清单。1.2 营销技能天然适合被标准化营销工作有一个特点流程相似但内容多变。不管是写一篇推文、策划一次投放、还是做一轮线索清洗骨架基本都是固定的变化的只是素材、参数和目标。这个特点决定了营销动作很适合被抽象成“技能”——每个技能有固定的输入输出约定而内部的创意空间留给大模型自由发挥。拿“生成活动主题”来说输入是活动目标、目标人群、投放渠道输出是若干主题候选拿“输出投放周报”来说输入是时间范围、数据源、统计口径输出是一份结构化报告。把这类动作封装好之后代理就不再需要从零理解每个任务而是像工人从工具箱里取出对应工具一样按需调用。这也是为什么我在设计技能库时坚持要先从工作流倒推需求而不是从模型能力正推——先想清楚要干哪些活再看哪些活适合做成技能而不是先看手头有什么模型再想怎么让它尽量干活。2. 技能的标准化封装描述、契约与上下文2.1 一条技能记录长什么样在 Marketingskills 里每条技能不是一段孤立的提示词而是一条完整的结构化记录包含五个核心部分技能描述、输入契约、输出契约、执行逻辑、依赖的工具。这里我给出一个简化后的 JSON 示例对应“多渠道文案改写”这条技能{ skill_id: content.copy_rewrite, name: 多渠道文案改写, version: 1.2.1, description: 根据源文案与目标渠道特性改写为适配该渠道的文风与长度要求仅用于已有文案的改写不负责从零创作, category: content, input_schema: { source_text: { type: string, required: true, max_length: 5000 }, target_channel: { type: enum, values: [article_page, email, social_post, short_video, landing_page] }, tone: { type: string, enum: [professional, casual, playful], default: professional } }, output_schema: { rewritten_text: { type: string, required: true }, length_check: { type: object, properties: { char_count: { type: integer }, channel_limit_ok: { type: boolean } } } }, execution: { prompt_template_id: tmpl_copy_rewrite_v2, llm_config: { temperature: 0.6, max_tokens: 2000 }, post_processors: [length_validator, prohibited_word_filter] } }这段结构看着简单但每部分都有讲究。技能描述是给代理“看”的路由模块要靠它来决定何时调用所以描述必须写清楚触发条件和边界比如“仅用于已有文案的改写不负责从零创作”这种限定能避免代理在错误场景下强行调用。输入输出契约则负责兜底防止代理传入格式错误的数据或拿到非预期的输出。2.2 为什么输入输出契约比提示词更重要很多人在做技能库时把全部精力都放在打磨提示词上却忽略了对输入输出的契约化管理。这在实际运行中会出大问题。举一个真实的例子。早期版本里“周报生成”技能对输入只定义了一个日期范围没有规定数据口径。结果代理在周一的时候拿上周五的数据生成了本周周报下游团队还照常用了。后来给输入契约增加了一道日期有效性校验在输出契约中增加了“数据截止时间”字段这类问题才被系统性地拦住。契约的价值有三个层次第一它让技能可以被其他模块稳定调用不用靠猜返回结构第二它让异常情况在入口处就被拦截而不是等错误流到下游才暴露第三它可以作为自动评测的基准系统能直接判断某次执行结果是否成功。所以设计技能时建议先花时间把输入输出的字段、类型、约束条件定义清楚再动手写提示词。契约定得越死代理的发挥空间越受控最终效果反而越可靠。2.3 技能、提示词与插件的边界还有一个容易混淆的问题技能skill、提示词prompt和插件plugin到底什么区别我在项目里给它们的定位是提示词是技能内部的一种资源技能可以引用多个提示词模板同一个模板也可以在多个技能之间复用插件则偏向“外部能力接入”比如查词频统计的工具、调取内容素材的接口技能通过执行逻辑去调用这些插件。技能本身处在中间层负责把“意图”翻译成“能力调用”。打个比方插件是工具箱里的电钻提示词是操作说明书技能则是“钻孔”这个标准动作——它规定了你需要什么材料、钻完之后要交付什么结果。没有技能这一层代理面对“把这段文案改成短视频风格”的需求还得自己判断该用哪个说明书、要不要用电钻。有了技能层这些判断被收敛到一处可维护性立刻高很多。项目里我们经常调整提示词模板但因为技能层没有变路由逻辑、评测逻辑、下游调用方就都不需要跟着改这是模块化最直接的红利。3. 先把哪些营销技能放进库按工作流倒推3.1 从营销工作流拆技能清单设计技能库时里面到底放什么不能靠拍脑袋而是倒推先列出营销团队的高频工作流再把工作流拆成原子动作最后评估每个动作适不适合做成技能。以内容营销这条线为例工作流大概是确定主题、关键词研究、生成初稿、多平台改写、标题优化、发布排期、数据回收、复盘改进。顺着这条流拆下来“关键词研究”“初稿生成”“平台改写”“标题生成”“复盘总结”都是高复用动作非常适合做成技能而“发布排期”这种强依赖外部系统的动作更适合用集成接口去做不必强行做进技能库。我整理过一张技能取舍的对比表这里简化一下工作流高频动作是否做成技能原因内容营销关键词研究、文案生成、标题优化是输入输出边界清晰复用率高内容营销CMS 发布否强依赖外部系统交给集成层更合适投放管理受众圈选、预算分配建议是决策型动作可标准化输出建议投放管理实际扣费、出价执行否涉及资金与实时竞价必须人工确认数据解读周报生成、异常指标解读是规则相对固定输出结构化数据解读临时取数查询视情况查询口径多变需要动态 SQL 能力这张表说明一个原则技能库只放“边界清晰、判断收敛、结果可校验”的动作。凡是需要大量人工判断、或者涉及资金动作的宁可保留人工确认环节也不要让代理全自动执行。技能库不是越大越好而是越精准越好。3.2 内容生产类技能重质量也要可校验内容类技能是技能库里最活跃的一类有文案生成、标题生成、平台改写、摘要提取等。这类技能的设计难点不在生成而在校验。比如“标题生成”技能早期版本只是让模型输出几个标题结果质量参差不齐经常出现同质化、缺少信息量的问题。后来我给这条技能加了两个后置校验器第一个做去重过滤掉相似度超过阈值的标题第二个做字数与符号校验确保标题符合目标渠道的规范。模型输出通过校验器之后再决定是直接采用还是带着校验失败的原因重新生成一次。这个“生成-校验-再生成”的闭环让内容质量稳定了很多。提示内容类技能的温度参数不要一刀切。生成型任务比如活动主题脑暴温度可以调高一些产出更发散改写型任务比如关键词改写温度控制在 0.6 左右既保留表达多样性又不会偏离原意太多。这个参数应该在技能记录里固化下来而不是每次调用时临时指定否则同样的技能在不同请求下行为差异会很大。3.3 数据解读与分析类技能口径即契约分析类技能比内容类更看重“口径”这件事。同一份销售数据按订单金额算和按回款金额算得出的结论可能完全不同。所以“周报生成”技能在实现时把计算口径的选项直接做进了输入契约参数包括统计维度、指标定义、汇总粒度。代理调用时必须先把口径交代清楚输出里也必然附带“指标定义”字段。这样做有一个额外好处下游的报表可以直接引用技能输出里的口径说明避免口径在各处被稀释。再往深一层分析类技能的提示词里有一类固定的结构我叫它“指标异常解释框架”。当某个指标出现异常波动时技能会按固定顺序排查先确认数据口径再看时间周期再看结构拆分最后才给出业务归因。这个框架听着简单却能显著减少模型“拍脑袋归因”的毛病。很多时候模型会凭印象说“可能是市场竞争加剧导致下滑”但按框架排查后发现只是数据口径变了结论完全不同。3.4 线索运营与触达类技能把决策权留给人类线索评分、触达时机建议、个性化邮件初稿这些动作非常适合做成技能因为可标准化又能节省大量人力。但在设计上我有一条原则技能输出建议人类做最终决定。“线索评分”技能的输出是一份包含评分、评分原因、建议后续动作的报告而不是自动跳过某条线索或自动发送邮件的指令。“邮件初稿”技能会生成个性化的首段和主题行但发送前必须经过人工审批。技能库会在输出契约里带上“需要人工确认”的标记编排层发现这个标记时就会把执行流挂起等待人工接入。这套设计看上去多了一步但安全性和可控性提升很多。营销触达直接关系到用户感受甚至会影响品牌形象和合规底线宁可慢一点也不能让代理全自动操作。线上运行一段时间后我反而发现人工确认环节的负担没有想象中高因为大部分用例在人工快速过目后就能放行真正需要退回修改的还是少数。这说明技能质量到位之后人工兜底并不会成为瓶颈反而会给团队带来更高的信任感。4. 编排层技能库真正值钱的部分4.1 路由谁来决定调用哪个技能技能库搭好之后下一个核心问题就是代理怎么知道该用哪个技能。Marketingskills 的做法是单独设计了一个路由模块它先做意图识别再做技能匹配最后决定调用顺序。路由的输入是用户请求和当前上下文输出是一个技能调用计划。比如用户说“帮我把上周的投放数据整理成周报再挑三个表现最好的渠道写优化建议”路由会把这个请求拆成两步先匹配“周报生成”技能再匹配“渠道建议”技能并把第一步的输出作为第二步的输入。早期我用单次提示词让大模型直接输出技能调用计划效果不稳定经常漏技能或者传错参数。后来改成两步走先让模型只输出意图分类再用规则引擎根据分类结果决定技能链准确率明显提升。这说明路由环节把“自由度”降低一点稳定性反而会更高。意图分类的维度不用太多能把营销场景的大类分清楚就够了具体的技能组合交给规则去决定既好维护又容易调试。4.2 状态管理与多技能协作当一次任务涉及多个技能时状态管理就变得关键。每个技能执行完之后会产生中间结果这些结果要能被后续技能引用也要能被用户追溯。项目的做法是引入一个轻量的执行上下文对象按阶段记录技能调用历史、输入输出摘要、依赖关系。代理在执行链路上可以随时读取上文避免重复传递参数。比如“周报生成”之后接“渠道建议”渠道建议技能不需要用户重新给一遍数据直接从上下文里取周报中的关键指标即可。这个设计最大的收益是支持了“组合技能”的概念。有些复杂任务比如“月度营销复盘”可以定义为一个组合技能内部编排了数据拉取、指标分析、内容复盘、建议生成四个子技能。代理执行时只需要调用组合技能编排层负责内部调度。不过组合技能也有代价——上下文会越来越长中间结果如果不做裁剪很快就会超过模型的注意力和成本预算。我现在的做法是每条技能只把“摘要化”的关键输出写入共享上下文原始完整结果放到可查询的存储里需要时再拉取。这样既保持了上下游衔接又避免上下文无限膨胀。4.3 失败降级与人工兜底编排层不能只考虑顺利路径还要考虑失败路径。项目里定义了三级降级策略第一级技能执行失败但可以重试例如模型输出校验不通过就带上错误原因重新执行一次第二级技能不可用时走替代路径比如“周报生成”技能暂时异常就降级调用“数据摘要加模板填充”的简易路径第三级整条链路都完不成时把执行记录整理成待人工处理清单推送给运营团队。这套降级策略跑了一段时间后最大的价值不是减少报错而是让失败变得可见、有记录。每一条降级记录都带着完整的链路信息包括在哪一步失败、失败原因是什么、走了哪条替代路径后面去优化具体故障点就非常方便。我见过不少团队把代理做成一个黑盒出问题就只会重试最后用户感知到的就是“这个 AI 经常卡住”。有了降级和兜底至少每一次失败都有明确去向和记录不会让任务无声地消失。5. 评测与灰度上线的工程实践5.1 没有评测集技能库就是一盘散沙技能库做得再漂亮没有一套评测机制线上效果就完全不可控。这是这个项目给我印象最深的一点。我们为每条技能单独建立评测集每个评测集至少包含三类用例标准用例覆盖典型场景边界用例覆盖异常输入对抗用例覆盖误导性输入。以“标题生成”为例标准用例是正常的文章主题边界用例是超长主题、空主题、纯数字主题对抗用例则是一些含糊甚至带有诱导性的输入。评测执行时我们用两种判断方式结合。第一种是规则判断比如输出是否满足契约、字数是否超限、是否包含禁用词第二种是模型评判用另一个大模型按照打分标准对生成结果打分。两条结合既保底又保质量规则判断拦硬伤模型评判看软质量。5.2 回归测试与版本管理技能会不断调整提示词和参数每次改动都存在回归风险。所以项目为每个技能做了版本快照提示词模板、输入输出契约、评测用例全部跟着版本走。当某条技能的新版本准备上线时先把新旧版本在评测集上各跑一遍对比通过率和得分。如果新版本在标准用例上得分持平在边界用例上更好就可以进入下一步。这里有个很实际的坑不要因为新版本某个点看着更聪明就急着升级评测分数才是唯一的判断依据。我遇到过表面上惊艳、实际在某些老用例上倒退的模型配置最后就是靠回归测试拦下来的。没有回归这一关线上就会出现“刚才还好好的今天怎么变笨了”的诡异问题。5.3 灰度发布与线上监控技能升级都走灰度流程先放量给一小部分流量观察线上效果再逐步放开。线上监控主要看三个指标技能调用成功率、输出校验通过率、人工纠错率。调用成功率反映技能本身是否稳定可用输出校验通过率反映生成质量是否达标人工纠错率则反映代理产出被人修改的比例。纠错率这个指标最容易被忽略但它的信息量很大——如果某个技能的纠错率长期偏高说明它的输出和业务预期的差距没有被评测集覆盖。灰度观察期一般持续三到五天积累足够的样本之后再放全量开关。这里再说一个容易被忽略的细节灰度期间的日志要按版本号打点否则你根本分不清线上某个异常到底是新版本引入的还是本来就有。6. 复盘与下一步技能库如何长成生态6.1 几个关键经验复盘下来有几条经验值得后续实践复用。第一技能粒度宁粗勿细一个技能至少要能独立完成一个有价值的动作拆到太细会大幅增加路由判断和上下文传递的负担。第二所有技能的输入输出必须走契约校验这项基础工作省不掉一开始嫌麻烦后面会帮你挡住大量低级错误。第三评测集要跟着技能一起演进新场景出现了就要补用例而不是只依赖模型自身的通用能力。另外在技能库的后续发展中跨技能的参数冲突需要提前处理。比如“周报生成”输出的“核心指标”和“渠道建议”需要的“渠道维度”如果不一致下游就会拿到对不上的上下文。现在我们在编排层增加了一组字段映射规则专门处理这类对齐问题。这类问题的本质是技能之间缺少一个公共的“语义中间层”如果一开始设计技能时就统一定义指标维度和渠道维度后面能省很多事。6.2 可能的演进方向技能库未来有两个明显的演进方向。一个是技能模板的生态化把高质量的技能记录沉淀成可复制的模板库让更多团队拿去定制另一个是多代理协作让不同技能由不同代理承载比如内容代理、数据分析代理、投放代理再由一个主代理统一调度。这两个方向的本质都是把技能库从一维的工具集升级成多维的能力网络。我现在的习惯是每次上线一个新技能之前都会问自己三个问题这个技能的输入边界清楚吗它的输出能被自动校验吗如果它失败了系统知道怎么降级吗三个问题都答得上来的技能放进库里才放心。营销场景在变流量玩法在变但把复杂任务拆成可靠动作的思路短期内不会变。这个项目做到后面我越来越觉得技术方案会迭代唯一值得长期投入的是把基本功做扎实——契约、评测、编排一个都不能省。