企业官网建设流程全解析

做 AI 代理类产品最头疼的一件事，通常不是单次对话效果，而是营销技能没法规模化沉淀。今天想聊的 Marketingskills 项目，就是专门来解决这个问题的：它把营销场景里反复用到的方法论、提示词、工具调用和评估标准，整成一套可注册、可调用、可迭代的“技能库”，让 AI 代理不再是一段写死的流程，而是一组可组合的营销能力包。

这个项目解决的是三个层面的事：一是把零散写在业务代码里的营销逻辑抽离成标准化技能；二是给这些技能配上清晰的描述、参数和使用说明，让代理知道什么场景该用什么；三是建立评测闭环，让每次技能改动都能量化验证。适合正在做 AI 营销中台、智能客服、内容自动化这类方向的同学参考，也适合独立开发者想在项目里快速集成营销 Agent 能力时抄作业。

1. 项目全景：为什么需要一个 AI 代理营销技能库

1.1 营销场景的碎片化痛点

营销场景天然是碎片化的。一个完整的营销代理，至少要覆盖内容生成、受众分析、渠道适配、投放归因、异常预警、合规检查这几类能力。每一类能力背后，又依赖不同的模型参数、提示词、外部工具和评判标准。比如生成一篇推文，要选择语气、控制长度、判断是否含违禁词；做投放分析，要对接广告后台、拉取转化数据、计算 ROAS。这些逻辑如果散落在各个业务脚本里，时间一长就会变成“没人敢改”的代码。

更麻烦的是，营销技能之间还会互相影响。内容生成的结果要喂给投放分析，投放分析输出的异常信号要触发新的内容调整。如果每个技能都是独立的黑盒，没有统一的描述和输入输出规范，代理在编排时很容易选错工具或者传错参数。

我在实际项目里见过最典型的场景：运营同学提出“帮我写五个版本的双十一预热文案”，结果代理调用了两个不同的内容工具，一个输出长文一个输出短句，格式完全对不上。原因不是模型不行，而是技能库没有做标准化，代理不知道每个技能的边界和输出结构。Marketingskills 项目要解决的，本质上就是这个“能力管理”问题。

1.2 技能库到底解决什么问题

技能库的核心价值可以浓缩为四个动词：注册、发现、执行、评估。

注册是指把一类可复用的营销能力封装成标准技能包，包含名称、描述、参数、工具依赖、提示词模板和输出格式。发现是让代理在拿到任务时，能从一堆技能里选出最合适的那一个。执行是技能被选中后，能稳定地完成调用、拿到结果。评估则是每次技能变更后，用一批预置用例判断效果是否达标。

听起来很像普通的服务注册中心，但技能库有自己的特殊性：它描述的对象不是 API，而是“代理行为”。因此描述信息除了接口参数，还要包含这个技能适合什么任务、不适合什么任务、依赖哪些工具、输出结构长什么样。描述写得越清楚，后续智能路由的准确率就越高。

另外，技能库还天然承担版本管理的职责。同一个文案技能，可能因为促销节点不同存在多个版本：日常版、大促版、品牌公关版。在传统代码里这往往靠分支管理，在技能库里则可以通过标签和权重来灰度，让代理在特定时间段偏向使用某个版本，同时保留回滚能力。

1.3 项目定位与适用范围

Marketingskills 项目的定位很明确：它不是一本营销方法论百科，而是一个“可执行的能力包仓库”。换句话说，它不关心你懂不懂 STP 理论，它关心的是代理能不能稳定调用一套标准技能完成“人群细分”这个任务。

从适用范围上说，适合这几类团队：

• 正在建设营销中台，希望把各业务线 Agent 能力统一管理的团队。
• 做智能客服或私域运营工具，希望快速接入内容生成、话术推荐能力的团队。
• 独立开发者或研究者在做代理原型，不想每个新场景都从零写提示词的团队。

实际落地时，技能库可以和现有 Agent 主流程平行部署：主流程负责多轮对话和任务拆解，技能库负责具体技能的执行和评估。两者通过标准消息协议通信，互不侵入。

2. 整体架构与核心设计思路

2.1 四层模块划分

Marketingskills 的项目架构我拆成四层，每一层都有非常明确的边界。

第一层是技能注册层，负责技能包的定义、上传、审核和版本发布。一个技能包在这里就是一个结构化的描述文件，外加若干可执行脚本或提示词模板。注册层会做基础校验，比如描述是否为空、参数是否有默认值、依赖的工具 ID 是否存在。

第二层是执行引擎层，负责根据任务选择合适的技能，并按照技能定义完成多步调用。引擎内部会维护一次会话的技能上下文，记录哪些技能已经被调用、调用了多少次、结果如何。这个上下文非常关键，否则代理很容易陷入重复调用同一个技能的循环。

第三层是工具适配层，负责把外部系统（比如广告后台、内容平台、数据库）的统一调用协议转换成技能可理解的格式。工具适配器隔离了外部接口的不稳定性，让技能包本身不依赖特定外部系统。

第四层是评估反馈层，负责收集技能执行的输入、输出、中间步骤、消耗耗时和成功率，并把结果沉淀为评估报告。这一层还负责把“硬失败”（比如工具报错）和“软失败”（比如输出与预期不符）区分开，分别触发告警和重试策略。

这四层架构带来的最大好处是替换成本低：工具换新接口时只改适配层，技能描述变差时只改注册层，模型升级时只改执行策略层。营销行业变化快，这种可替换性比什么都重要。

2.2 为什么“描述信息”比代码更重要

写技能库时，最容易低估的就是描述信息。很多人会把精力花在实现逻辑上，描述只写一句话：“生成文案”。等真正跑起来才发现，代理根本不知道这个技能生成的是长文案还是短文案，面向的是小红书还是微信群，语气是活泼还是严肃。

技能描述本质上是一份“给 AI 看的接口文档”。代理不是通过读源码来判断技能的，它只能靠描述文本在多个技能之间做选择。描述里写清楚“适合什么”“不适合什么”“典型用法”“输出结构”，路由准确率会明显提升。

一个更直接的类比是岗位 JD：技能就是岗位，描述就是 JD，代理就是面试官。JD 写得模糊，面试官选的必然是人不对。同理，技能描述写得模糊，代理选的就必然是技能不对。

项目里建议的描述字段包括：技能名称、一句话摘要、适用场景、不适用场景、输入参数说明、输出格式说明、典型调用案例。这个案例很重要，它相当于给代理一个示例，让代理能模仿调用方式，而不是凭空猜测。

2.3 与主流 Agent 框架的集成方式

技能库做出来不是封闭系统，它要给外部代理用。常见集成方式有两种。

一种是插件式集成：把技能库封装成一组标准工具，注册到主 Agent 框架里。代理每轮决策时，会浏览全部技能描述，选择合适的工具来调用。这种方式的优点是接入简单，缺点是技能数量变多后，代理浏览描述的开销会变大，容易决策超时。

另一种是服务化集成：技能库独立部署，通过 HTTP 或消息队列对外提供服务。代理把任务发给技能库服务，服务内部完成技能选择和执行，把结果返回给代理。这种方式耦合更小，适合技能库内部逻辑复杂、多团队协作的场景。

Marketingskills 项目我更推荐服务化集成，尤其是技能数量超过二十个以后。那样可以在技能库内部做更精细的过滤、排序和缓存，而不至于把全部压力都抛给主代理。

3. 核心实现：从技能定义到编排执行

3.1 技能定义的结构化方案

技能定义是技能库的地基。我建议用 JSON 或 YAML 描述，核心结构大概长这样：

{ "skill_id": "content_generator", "name": "营销文案生成器", "version": "1.2.0", "summary": "根据产品信息与平台特性生成多版本营销文案", "tags": ["文案", "内容", "营销"], "applicable_scenarios": [ "新品上市预热文案", "促销活动推广", "私域社群种草内容" ], "not_applicable_scenarios": [ "品牌危机公关声明", "政策法规类正式表述" ], "parameters": [ { "name": "product_info", "type": "object", "description": "产品关键信息，包含名称、卖点、目标人群", "required": true }, { "name": "platform", "type": "string", "enum": ["小红书", "微信群", "公众号", "电商详情页"], "description": "内容投放平台", "required": true }, { "name": "tone", "type": "string", "default": "活泼", "description": "文案语气风格" } ], "output_schema": { "type": "object", "properties": { "versions": { "type": "array", "description": "生成的所有文案版本" }, "risk_flags": { "type": "array", "description": "命中合规规则的提示" } } }, "tools_required": ["inventory_service", "compliance_checker"], "evaluation_set": ["case_daily_promo", "case_new_product_launch"] }

这里有几个设计细节值得展开说：

• tags 是给开发者看的，同时也是给路由策略做粗筛用的。技能很多时，先用标签缩小候选范围，再用 summary 和场景描述做精排，性能会好很多。
• not_applicable_scenarios 很多人会省略，但它特别重要。代理在模糊任务下经常“过度选择”，明确写上不适用场景，能显著降低乱调用的概率。
• evaluation_set 是关联的离线评测用例 ID。发布新版本技能时，系统会自动跑这些用例，判断新版是否优于旧版。

3.2 几个典型营销技能配置示例

光说结构有点抽象，我拿三个真实会在营销场景里用到的技能拆一下。

第一个是周报数据解读技能。它的输入是渠道数据和业务目标，输出是本周数据亮点、异常点和下周建议。这个技能要调用的工具是一个查询接口，返回订单量、转化率、客单价等指标。最关键的参数是“对比周期”，默认是前一周，也可以指定去年同期。

第二个是广告投放异常排查技能。它负责在 ROAS 下降时去查候选原因，比如预算是否耗尽、素材是否被拒、竞争环境是否变化。这里的执行逻辑不是一个 Prompt 能搞定的，需要分步：先查账户级数据，再查广告组级数据，再查素材级数据，最后汇总成一份排查报告。

第三个是用户分群与触达策略技能。它输入用户行为标签，输出多个用户分群的描述、推荐触达渠道和话术方向。这个技能的特点是依赖团队沉淀好的用户分群逻辑，所以参数里有“分群规则版本号”，避免每次结果不一致。

这三个技能放在一个库里，就能看出技能库的威力：代理不需要知道底层工具的新接口，只需要按技能的描述把任务传进来，技能内部把“怎么拆步骤”“怎么调接口”“怎么汇总结果”全包了。

3.3 技能编排与路由逻辑

技能装进库里之后，接下来最关键的是“选哪个技能”。我实验下来，最稳的不是纯靠大模型自由选择，而是“规则粗筛 + 模型精排”的两段式路由。

粗筛阶段，用关键词和标签把候选技能缩小到 5 个以内。比如任务里出现“投放”“ROAS”“账户”，优先匹配广告投放相关技能；出现“文案”“种草”“推文”，优先匹配内容生成相关技能。这个阶段不需要大模型，一个简单的倒排索引就能搞定，速度快、成本低。

精排阶段，把候选技能的完整描述、当前任务文本、会话历史拼成一个选择 Prompt，让模型输出最合适的技能 ID 和参数映射。这里有一个细节：不要让模型直接输出“调用参数”，而是让模型先输出“对用户任务的理解”，再输出“选中的技能 ID”，最后再逐字段填参数。这个中间步骤能明显减少参数幻觉。

路由逻辑里还需要处理一个情况：多个技能都部分匹配任务。比如“生成一篇小红书文案”既可能匹配内容生成技能，也可能匹配用户分群技能。这时候要靠适用场景文本做区分。内容生成技能里写上“适用于文案创作，不做用户人群分析”，用户分群技能里写上“适用于人群划分，不输出完整文案内容”。边界越清楚，代理越不容易选错。

3.4 评估闭环：让技能越用越准

技能库不能只做加法，还要做反馈循环。我给每个技能配了三层评估机制。

第一层是离线评测。维护一批 golden case，每个 case 包含输入、期望输出结构和关键检查点。技能版本发布前，先跑一遍全部 case，分数低于旧版就阻断发布。这块相当于给技能库加了一个“CI 门禁”。

第二层是在线观测。技能被真实调用时，记录完整调用链、耗时、成功率、用户反馈打分。如果某个技能连续调用失败，或者输出被用户多次修改，就标记为低置信度技能，让代理后续减少选择它的概率。

第三层是人工抽审。每周抽一部分技能输出，由运营同学标注质量等级，并反哺到描述文本和提示词模板。这个环节容易被技术团队忽略，但营销技能的很多坑其实是语义层面的，只有运营能发现“文案风格不对”“语气太机械”这类软问题。

这套评估闭环跑起来以后，技能库会越用越清晰。它的本质是把“玄学调 Prompt”变成“数据驱动迭代”。

4. 实操过程与踩坑记录

4.1 从零搭建一个最小可用技能库

这个项目不需要一开始就铺得很重，我建议按下面八步搭出一个最小可用版本，跑通以后再逐步加能力。

第一步：定义技能 JSON Schema。先别写具体技能，把结构定下来，后面所有技能都往里套。

第二步：搭一个技能注册中心。简单起见，用一个文件夹加索引文件就行，每个技能是一个 JSON 文件，索引记录 ID 和版本号。等技能超过 30 个，再考虑上数据库。

第三步：实现技能加载器。它负责读技能定义、校验必填字段、把工具依赖注入进来。这一步的重点是日志，要能看清当前加载了哪些技能、版本是多少。

第四步：写第一个技能。我建议从“营销文案生成器”开始，因为它不依赖外部工具，出效果快，能帮你验证整个链路。

第五步：接一个外部工具适配器。比如接一个库存查询接口，让技能能根据库存情况生成“限量发售”类文案。这一步主要验证工具参数传递是否正确。

第六步：跑通一次端到端调用。通过外部代理发一个真实任务，看技能被正确选中、正确执行、正确返回结果。

第七步：补三个离线评测用例。覆盖正常场景、边界场景（比如缺少必要参数）、异常场景（比如工具报错）。跑一遍评测脚本，确保能拦住明显回归。

第八步：做一个小规模灰度。把一个技能开放给 10% 的真实流量，观察成功率，确认没问题再全量放开。

这套流程看起来简单，但每一步都会逼你解决一个实际问题。比如第四步会让你发现自己写的描述不够清晰，第六步会让你发现参数映射经常出错，第七步会让你发现评测用例怎么设计都覆盖不全。这些坑踩过一遍，后面再扩技能就顺了。

4.2 三个典型踩坑：语义冲突、参数幻觉、上下文污染

先说语义冲突。我在一个模拟项目里同时放了“文案生成”和“话术推荐”两个技能，描述都是“生成适合发给用户的内容”。结果代理面对“给用户发条优惠信息”时，随机二选一，输出风格非常不稳定。后来我把话术推荐技能的适用场景改成“用于客服对话，结合用户意图与历史记录生成短回复”，把文案生成技能改成“用于营销内容创作，面向公域或私域广泛传播”，两个技能的调用准确率才稳定下来。

再说参数幻觉。这个问题出现在技能需要多参数时，模型经常把上一轮会话里的信息当成某个参数传进来。比如用户说“查一下上周数据”，技能要求传“start_time”和“end_time”，模型可能直接填了“上周”，而不是换算成具体日期。解决办法是在描述里明确写“参数值必须是具体日期字符串，禁止使用模糊时间词”，同时在执行引擎里加一道参数拦截，发现非法格式就回退重填。

最后是上下文污染。代理一次会话里通常会调用多个技能，前一个技能的输出可能会污染后一个技能的判断。最典型的是文案生成技能输出里包含“建议配合促销活动”，下一个数据解读技能误以为“促销活动已经开始”，于是给出的分析全是错的。这个问题的解法是在技能调用之间做上下文隔离，每个技能只看到自己需要的字段，而不是全部历史输出。

4.3 常见问题速查表

我把实际运行中碰到的高频问题整理成了一张表，方便排查：

这张表的通用性很强，因为这些问题本质上是所有 Agent 技能库都会遇到的。你可以直接当成运维手册用。

5. 一点个人体会

Marketingskills 项目做到后期，我最深刻的体会是：技能库能不能跑起来，关键不在技术，而在“规范”和“流程”。技术架构再漂亮，如果技能描述没有人认真写，评测用例没有人定期维护，工具适配层没有负责人跟进，技能库很快就会变成一堆无人维护的僵尸技能。

另一个体会是，别追求一步到位。一开始做十个技能，不如把一个技能做深、跑稳、评测齐全。技能库的复制成本很低，真正难的是把单技能的质量标杆立起来。只要第一个技能形成了标准，后续技能照着套就好办得多。

我在实际项目里最后还会做一个小扩展：给技能库加一个“成本统计”维度，记录每个技能的一次调用消耗多少 token、大概多少钱。这样优化技能时不只是看效果，还能看成本下降了多少。营销场景往往对预算敏感，这个维度很容易成为向团队汇报的核心指标。

如果你正在搭自己的 AI 代理营销体系，建议从最小的技能库开始，哪怕只放两三个技能，先把“描述规范、路由逻辑、评测闭环”这三件事跑顺。跑顺以后，技能数量的扩张就只是时间问题。