1. 货拉拉营销广告场景下的大模型落地思路货拉拉的营销广告业务有个很鲜明的特点双边网络效应极强且地域属性、车型属性、时段属性高度耦合。司机侧要拉新、促活、召回货主侧要拉新、首单转化、复购这两端的需求完全不对称投放渠道又散落在信息流、应用商店、短信、Push、地推物料、异业合作等十几个触点上。传统做法是靠运营同学手动配人群包、写文案、调出价一个活动从需求到上线经常要三到五天而且 A/B 实验的样本量根本跑不够很多决策其实是拍脑袋。我们做大模型应用的出发点很朴素把人写文案、人配人群、人盯数据这条链路里最耗时的部分交给模型但决策权和兜底权仍然留在人手里。这句话听起来像口号但落到工程上它决定了整个架构是AI 辅助还是AI 自动两者的技术选型和风险控制完全不一样。1.1 为什么不是直接上一个通用大模型就完事很多人第一反应是接一个通用大模型 API把商品信息丢进去让它写文案。我们早期也这么试过结论是通用模型写出来的货拉拉广告文案放在朋友圈里根本没人点。原因有三个。第一行业黑话和合规红线模型不懂。货拉拉的广告里不能出现最便宜绝对保证这类词平台审核会直接拒同时起步价超时费搬运费另计这些计费规则必须表述准确写错一个字就是客诉。通用模型没有这个约束感。第二人群画像和文案的匹配是隐性的。给搬家用户写一键叫车、师傅帮忙搬给商户写月结账期、开票方便给建材市场老板写大件运输、车型齐全这三类人看到同一句话的反应完全不同。通用模型不知道谁是商户谁是搬家用户。第三成本。营销广告是高频、大批量场景一次活动可能要生成几千条文案变体做实验。如果每条都调通用大模型token 成本会失控。我们必须做分层路由简单任务走小模型或微调模型复杂任务才走大模型。所以最终的技术路线是基座大模型 领域微调 提示词工程 智能体编排 规则兜底五层叠在一起而不是单点依赖某一个模型。1.2 整体架构从模型调用到智能体工作流我们把整个营销广告的大模型应用拆成了四个智能体Agent每个 Agent 负责一段独立职责通过工作流串起来。人群洞察 Agent输入是活动目标拉新/促活/召回和预算输出是推荐的人群包组合和触达优先级。文案生成 Agent输入是人群包特征、渠道、商品卖点输出是 N 条候选文案带合规校验标记。投放策略 Agent输入是历史投放数据和实时出价环境输出是出价区间和预算分配建议。效果归因 Agent输入是投放后的转化数据输出是归因分析和下一轮优化建议。这四个 Agent 不是各自为战而是共享一个上下文记忆层。比如文案生成 Agent 会读取人群洞察 Agent 输出的画像标签效果归因 Agent 的结果又会回流到人群洞察 Agent 的知识库里。这个设计的关键在于营销是一个闭环不是一次性任务如果每个 Agent 都独立调用模型上下文就断了优化无从谈起。提示Agent 拆分粒度不要过细。我们一开始拆了七个 Agent结果调试成本极高Agent 之间的通信开销比模型推理还大。后来合并到四个反而稳定了。经验是一个 Agent 对应一个明确的、可独立验收的业务动作不要为了看起来智能而过度拆分。1.3 技术选型的几个关键取舍基座模型选型上我们没有迷信参数最大的模型。实测下来在文案生成这个任务上一个 13B 级别的中文微调模型配合好的提示词和 few-shot 示例效果能达到通用大模型的 85% 左右但推理成本只有十分之一。对于投放策略这种需要数值推理的任务才路由到更大的模型。微调方式上我们用的是 LoRA低秩适配而不是全量微调。原因很实际全量微调一次要几十张卡跑好几天迭代周期太长LoRA 只需要少量卡几小时就能出一版而且可以针对不同渠道信息流、短信、Push训练不同的 LoRA 权重按需加载。这就像给同一个基座模型换不同的行业皮肤切换成本极低。上下文工程上我们没有把所有历史数据都塞进 prompt。营销场景的上下文很容易膨胀到几万 token既贵又慢而且模型会迷失在中间。我们的做法是分层摘要原始数据先经过规则引擎压缩成结构化标签再经过一次小模型摘要最后才进入大模型的 prompt。这样上下文长度能控制在 2000 token 以内效果反而更稳。2. 核心细节解析与实操要点2.1 人群洞察 Agent 的标签体系怎么搭人群洞察 Agent 的核心不是模型而是标签体系。模型再强如果标签是乱的输出也是垃圾。我们把货拉拉的营销标签分成了四层。层级标签类型示例更新频率基础层人口属性城市、年龄段、注册时长天级行为层交易行为近30天下单次数、客单价、常用车型小时级意图层实时意图近1小时搜索关键词、浏览页面分钟级价值层生命周期新客、成长、成熟、流失预警天级模型的作用是在意图层和价值层之间做交叉推理。比如一个用户近1小时搜索了搬家 大件同时处于流失预警状态模型会判断这是一个高优先级的召回对象推荐用搬家专属券而不是通用券去触达。实操中有一个坑标签的时效性不一致会导致模型误判。我们遇到过行为层标签是小时级更新但价值层是天级更新结果一个昨天刚下过单的用户今天还被标记为流失预警模型就推荐了召回文案非常尴尬。解决办法是在 Agent 里加一个标签新鲜度校验任何标签超过其更新周期的 2 倍时间未刷新就降权处理。2.2 文案生成 Agent 的提示词工程实战文案生成是整个项目里最见效果的环节也是最容易翻车的地方。我们的提示词结构是固定的五段式角色设定你是货拉拉的营销文案专家熟悉货运行业计费规则和平台合规要求。任务描述为以下人群生成 5 条短信文案每条不超过 40 字。上下文注入人群画像标签、渠道特征、活动卖点、历史高转化文案示例。约束条件禁用词列表、必须包含的信息如活动时间、优惠力度、语气要求。输出格式JSON 数组每条包含文案正文、合规标记、推荐指数。这里最关键的是第 3 段的 few-shot 示例。我们不是随便找几条文案放进去而是从历史数据里筛选出同人群、同渠道、转化率 top 10%的文案作为示例。实测下来带高质量示例的 prompt生成文案的点击率比不带示例的高出 30% 以上。注意few-shot 示例不要超过 5 条。我们试过放 10 条模型反而开始抄示例生成的文案同质化严重。3 到 5 条是最佳区间既能引导风格又留有发挥空间。另一个实操要点是合规校验不能只靠模型。我们在模型输出之后加了一层规则引擎用正则和关键词库做二次校验。模型有时候会创造性地写出全网最低价这种词规则引擎能兜住。两层校验的漏网率从单层的 8% 降到了 0.5% 以下。2.3 投放策略 Agent 的参数计算逻辑投放策略 Agent 要做的事情是给定预算和人群包输出每个渠道的出价和预算分配。这个任务不能纯靠模型感觉必须把计算逻辑显式化。我们的做法是模型负责定性判断公式负责定量计算。模型输出的是这个人群包在信息流渠道的竞争激烈程度是高/中/低然后由公式根据竞争程度、历史 ROI、预算约束算出具体出价。出价公式的核心逻辑是建议出价 基准出价 × 竞争系数 × ROI 修正系数 × 预算约束系数其中基准出价来自历史同期数据竞争系数由模型判断给出高1.3中1.0低0.8ROI 修正系数根据该人群包近 7 天 ROI 与目标 ROI 的比值计算预算约束系数在预算紧张时下调。这个设计的好处是可解释、可干预。运营同学看到建议出价能清楚知道是哪个系数在起作用而不是面对一个黑盒数字。我们内部有个说法模型可以给建议但公式必须能算账。2.4 效果归因 Agent 的数据回流机制效果归因 Agent 是整个闭环的最后一环也是最容易被忽视的一环。很多团队做完投放就不管了数据不回流下一轮还是从零开始。我们的做法是T1 回流 实时回流双通道。T1 回流的是完整的转化数据用于更新人群标签和文案库实时回流的是点击和曝光数据用于当天的出价调整。两个通道的数据格式统一都写入同一个特征库。这里有个技术细节归因窗口的选择会直接影响模型判断。货拉拉的转化链路比较长用户可能今天看到广告三天后才下单。如果归因窗口设得太短会低估某些渠道的效果。我们最终把点击归因窗口设为 7 天曝光归因窗口设为 1 天这个参数是经过多轮 A/B 实验调出来的。3. 实操过程与核心环节实现3.1 从零搭建一个文案生成 Agent 的完整步骤假设你现在要从零开始做一个货拉拉的文案生成 Agent我会按下面的顺序推进。第一步数据准备。收集过去 6 个月的历史广告文案字段包括文案正文、渠道、人群包 ID、曝光量、点击量、转化量。清洗掉曝光量低于 1000 的样本剩下的按转化率排序每个渠道取 top 20% 作为 few-shot 候选池。第二步标签对齐。把人群包 ID 映射到标签体系确保每条历史文案都能对应到具体的人群特征。这一步最耗时因为历史数据的人群包命名很乱需要人工梳理一遍。第三步提示词迭代。先用一个基础 prompt 跑 100 条测试人工评估生成质量找出问题比如语气不对、信息缺失、合规问题然后针对性修改 prompt。这个循环我们跑了大概 8 轮才把 prompt 稳定下来。第四步微调模型。当 prompt 优化到瓶颈后用积累的高质量文案数据做 LoRA 微调。训练数据大概 5000 条训练时间 4 小时左右。微调后的模型在同样 prompt 下生成质量有明显提升尤其是行业术语的准确性。第五步上线灰度。先在一个小渠道比如短信灰度观察一周的点击率和客诉率。确认没问题后再逐步扩大到信息流和 Push。实操心得不要跳过灰度直接全量。我们有一次因为赶活动微调模型没灰度就全量上线结果模型在某个小众人群上生成了不合适的文案虽然量不大但客诉处理花了两天。灰度这一步省不得。3.2 智能体工作流的编排实现四个 Agent 的编排我们用的是工作流引擎而不是让模型自己决定调用顺序。原因很简单营销流程是确定的不需要模型来规划。人群洞察 → 文案生成 → 投放策略 → 效果归因这个顺序是固定的用工作流引擎串起来更稳定、更可控。每个 Agent 的输入输出都定义了严格的 schema。比如人群洞察 Agent 的输出必须是{ audience_packages: [ { package_id: string, tags: [string], priority: high|medium|low, estimated_size: number } ], reasoning: string }这个 schema 是下游 Agent 的输入契约任何不符合 schema 的输出都会被拦截并重试。我们统计过加了 schema 校验之后Agent 之间的数据错误率从 12% 降到了 1% 以下。工作流的并发控制也很重要。文案生成 Agent 一次可能要生成几百条文案如果串行调用模型延迟会很高。我们的做法是批量并发 限流同时最多 20 个并发请求超出的排队。这样既能压满模型推理资源又不会把服务打挂。3.3 模型部署与成本控制模型部署我们走的是混合部署路线微调后的小模型部署在自有 GPU 集群上通用大模型走 API 调用。这样做的原因是成本结构不同——小模型高频调用自建更划算大模型低频调用按量付费更灵活。自有集群的配置是 4 台 8 卡机器跑 13B 模型的推理单条文案生成延迟在 800ms 左右。这个延迟对于营销场景是可以接受的因为文案生成是异步任务不需要实时返回。成本控制上我们做了三件事。第一是缓存相同人群包和渠道的文案如果 24 小时内已经生成过直接复用缓存结果。第二是降级当 GPU 集群负载过高时自动降级到更小的模型保证服务不中断。第三是配额每个活动每天有生成条数上限防止某个活动异常刷量。实测下来这套方案把单条文案的生成成本从最初的 0.15 元降到了 0.02 元以下降幅超过 85%。4. 常见问题与排查技巧实录4.1 模型输出不稳定怎么办这是最常见的问题。同一个 prompt今天生成的文案和明天生成的可能风格差异很大。原因通常是模型温度参数设置不当或者上下文注入不稳定。我们的解决方法是温度固定 上下文标准化。文案生成任务把温度设为 0.7既保证多样性又不至于失控。上下文注入时所有标签按固定顺序排列数值型标签统一保留两位小数避免因为格式差异导致模型理解偏差。还有一个隐藏原因是模型版本漂移。如果用的是 API 模型服务商可能在不通知的情况下更新模型版本导致输出风格变化。我们的做法是锁定模型版本号并且在 prompt 里记录版本信息一旦发现输出异常能快速定位是不是版本问题。4.2 合规校验漏网怎么排查合规问题是最不能容忍的。我们建立了一套三层排查机制。层级排查方式覆盖范围响应时间第一层模型自检提示词内置禁用词实时第二层规则引擎正则 关键词库实时第三层人工抽检每日随机抽 5%T1如果发现漏网排查顺序是先看规则引擎的关键词库是不是没覆盖到再看模型的提示词约束是不是不够强最后看是不是模型本身对某个表达有偏好。我们遇到过一次模型特别喜欢用薅羊毛这个词虽然不算违规但和货拉拉品牌调性不符后来在提示词里明确禁止了这类网络用语。4.3 Agent 之间数据传递出错怎么定位Agent 之间的数据传递出错表现往往是下游 Agent 报错或者输出异常。定位方法是在每个 Agent 的输入输出加日志记录完整的 JSON 数据和时间戳。我们遇到过一个典型问题人群洞察 Agent 输出的estimated_size是字符串类型但投放策略 Agent 期望的是数字类型导致计算报错。这种问题靠看日志一眼就能发现但如果没日志可能要排查半天。避坑技巧schema 校验要严格但错误提示要友好。我们一开始的 schema 校验只返回校验失败不告诉具体哪个字段错了排查效率很低。后来改成返回具体字段路径和期望类型排查时间从平均 30 分钟降到了 5 分钟。4.4 效果不达预期怎么归因投放效果不好可能是人群选错了可能是文案不行可能是出价太低也可能是外部环境变化。归因的关键是控制变量。我们的做法是分层归因先看整体 ROI 是否达标不达标再看是哪个渠道拖后腿锁定渠道后看是哪个时间段效果差锁定时间段后看是哪个文案变体点击率低。这样一层层缩小范围最终定位到具体问题。有一个容易被忽视的因素是竞品动作。如果某个时间段所有渠道的效果都下滑很可能是竞品在加大投放抢了流量。这种情况模型是看不出来的需要人工结合市场信息判断。所以我们的归因报告里会留一个外部因素栏位由运营同学填写。5. 一些踩过的坑和真实体会5.1 不要迷信大模型什么都能干我们早期有个误区觉得大模型能力强就把所有任务都交给它。结果发现有些任务用规则引擎做效果比模型好十倍成本只有百分之一。比如禁用词校验、数值计算、格式转换这些确定性任务根本不需要模型。模型真正擅长的是模糊判断和内容生成比如判断一个文案的语气是否合适、生成多个变体、从非结构化数据里提取意图。把模型用在它擅长的地方才是正确的姿势。5.2 提示词工程是持续迭代的活提示词不是写一次就完事的。我们的提示词库有版本管理每次修改都记录修改原因和效果对比。有些提示词改了之后效果提升明显有些改了反而变差这些都需要数据说话。我的体会是提示词优化到一定程度后边际收益会递减。这时候应该转向微调或者换模型而不是继续在提示词上死磕。我们大概在 prompt 优化了 8 轮之后就转向了 LoRA 微调效果提升比继续改 prompt 明显得多。5.3 人机协作的边界要清晰最后说一个非技术但很重要的点人和模型的职责边界必须清晰。我们的原则是模型负责生成候选和给出建议人负责最终决策和兜底。任何直接面向用户的投放都必须经过人工确认或者规则校验不能完全交给模型自动执行。这个原则听起来保守但在营销场景下是必要的。营销广告直接关系到品牌形象和用户信任一次翻车可能抵消几个月的优化成果。模型可以大幅提升效率但最终的责任还是在人身上。这套东西我们跑了大概半年从最初的单点尝试到现在四个 Agent 的完整闭环中间踩了不少坑也积累了一些经验。如果你也在做类似的事情我的建议是从小场景切入先把一个 Agent 跑通再考虑编排。一上来就搞大而全的架构大概率会烂尾。 货拉拉营销广告大模型落地：四Agent智能体工作流实战
1. 货拉拉营销广告场景下的大模型落地思路货拉拉的营销广告业务有个很鲜明的特点双边网络效应极强且地域属性、车型属性、时段属性高度耦合。司机侧要拉新、促活、召回货主侧要拉新、首单转化、复购这两端的需求完全不对称投放渠道又散落在信息流、应用商店、短信、Push、地推物料、异业合作等十几个触点上。传统做法是靠运营同学手动配人群包、写文案、调出价一个活动从需求到上线经常要三到五天而且 A/B 实验的样本量根本跑不够很多决策其实是拍脑袋。我们做大模型应用的出发点很朴素把人写文案、人配人群、人盯数据这条链路里最耗时的部分交给模型但决策权和兜底权仍然留在人手里。这句话听起来像口号但落到工程上它决定了整个架构是AI 辅助还是AI 自动两者的技术选型和风险控制完全不一样。1.1 为什么不是直接上一个通用大模型就完事很多人第一反应是接一个通用大模型 API把商品信息丢进去让它写文案。我们早期也这么试过结论是通用模型写出来的货拉拉广告文案放在朋友圈里根本没人点。原因有三个。第一行业黑话和合规红线模型不懂。货拉拉的广告里不能出现最便宜绝对保证这类词平台审核会直接拒同时起步价超时费搬运费另计这些计费规则必须表述准确写错一个字就是客诉。通用模型没有这个约束感。第二人群画像和文案的匹配是隐性的。给搬家用户写一键叫车、师傅帮忙搬给商户写月结账期、开票方便给建材市场老板写大件运输、车型齐全这三类人看到同一句话的反应完全不同。通用模型不知道谁是商户谁是搬家用户。第三成本。营销广告是高频、大批量场景一次活动可能要生成几千条文案变体做实验。如果每条都调通用大模型token 成本会失控。我们必须做分层路由简单任务走小模型或微调模型复杂任务才走大模型。所以最终的技术路线是基座大模型 领域微调 提示词工程 智能体编排 规则兜底五层叠在一起而不是单点依赖某一个模型。1.2 整体架构从模型调用到智能体工作流我们把整个营销广告的大模型应用拆成了四个智能体Agent每个 Agent 负责一段独立职责通过工作流串起来。人群洞察 Agent输入是活动目标拉新/促活/召回和预算输出是推荐的人群包组合和触达优先级。文案生成 Agent输入是人群包特征、渠道、商品卖点输出是 N 条候选文案带合规校验标记。投放策略 Agent输入是历史投放数据和实时出价环境输出是出价区间和预算分配建议。效果归因 Agent输入是投放后的转化数据输出是归因分析和下一轮优化建议。这四个 Agent 不是各自为战而是共享一个上下文记忆层。比如文案生成 Agent 会读取人群洞察 Agent 输出的画像标签效果归因 Agent 的结果又会回流到人群洞察 Agent 的知识库里。这个设计的关键在于营销是一个闭环不是一次性任务如果每个 Agent 都独立调用模型上下文就断了优化无从谈起。提示Agent 拆分粒度不要过细。我们一开始拆了七个 Agent结果调试成本极高Agent 之间的通信开销比模型推理还大。后来合并到四个反而稳定了。经验是一个 Agent 对应一个明确的、可独立验收的业务动作不要为了看起来智能而过度拆分。1.3 技术选型的几个关键取舍基座模型选型上我们没有迷信参数最大的模型。实测下来在文案生成这个任务上一个 13B 级别的中文微调模型配合好的提示词和 few-shot 示例效果能达到通用大模型的 85% 左右但推理成本只有十分之一。对于投放策略这种需要数值推理的任务才路由到更大的模型。微调方式上我们用的是 LoRA低秩适配而不是全量微调。原因很实际全量微调一次要几十张卡跑好几天迭代周期太长LoRA 只需要少量卡几小时就能出一版而且可以针对不同渠道信息流、短信、Push训练不同的 LoRA 权重按需加载。这就像给同一个基座模型换不同的行业皮肤切换成本极低。上下文工程上我们没有把所有历史数据都塞进 prompt。营销场景的上下文很容易膨胀到几万 token既贵又慢而且模型会迷失在中间。我们的做法是分层摘要原始数据先经过规则引擎压缩成结构化标签再经过一次小模型摘要最后才进入大模型的 prompt。这样上下文长度能控制在 2000 token 以内效果反而更稳。2. 核心细节解析与实操要点2.1 人群洞察 Agent 的标签体系怎么搭人群洞察 Agent 的核心不是模型而是标签体系。模型再强如果标签是乱的输出也是垃圾。我们把货拉拉的营销标签分成了四层。层级标签类型示例更新频率基础层人口属性城市、年龄段、注册时长天级行为层交易行为近30天下单次数、客单价、常用车型小时级意图层实时意图近1小时搜索关键词、浏览页面分钟级价值层生命周期新客、成长、成熟、流失预警天级模型的作用是在意图层和价值层之间做交叉推理。比如一个用户近1小时搜索了搬家 大件同时处于流失预警状态模型会判断这是一个高优先级的召回对象推荐用搬家专属券而不是通用券去触达。实操中有一个坑标签的时效性不一致会导致模型误判。我们遇到过行为层标签是小时级更新但价值层是天级更新结果一个昨天刚下过单的用户今天还被标记为流失预警模型就推荐了召回文案非常尴尬。解决办法是在 Agent 里加一个标签新鲜度校验任何标签超过其更新周期的 2 倍时间未刷新就降权处理。2.2 文案生成 Agent 的提示词工程实战文案生成是整个项目里最见效果的环节也是最容易翻车的地方。我们的提示词结构是固定的五段式角色设定你是货拉拉的营销文案专家熟悉货运行业计费规则和平台合规要求。任务描述为以下人群生成 5 条短信文案每条不超过 40 字。上下文注入人群画像标签、渠道特征、活动卖点、历史高转化文案示例。约束条件禁用词列表、必须包含的信息如活动时间、优惠力度、语气要求。输出格式JSON 数组每条包含文案正文、合规标记、推荐指数。这里最关键的是第 3 段的 few-shot 示例。我们不是随便找几条文案放进去而是从历史数据里筛选出同人群、同渠道、转化率 top 10%的文案作为示例。实测下来带高质量示例的 prompt生成文案的点击率比不带示例的高出 30% 以上。注意few-shot 示例不要超过 5 条。我们试过放 10 条模型反而开始抄示例生成的文案同质化严重。3 到 5 条是最佳区间既能引导风格又留有发挥空间。另一个实操要点是合规校验不能只靠模型。我们在模型输出之后加了一层规则引擎用正则和关键词库做二次校验。模型有时候会创造性地写出全网最低价这种词规则引擎能兜住。两层校验的漏网率从单层的 8% 降到了 0.5% 以下。2.3 投放策略 Agent 的参数计算逻辑投放策略 Agent 要做的事情是给定预算和人群包输出每个渠道的出价和预算分配。这个任务不能纯靠模型感觉必须把计算逻辑显式化。我们的做法是模型负责定性判断公式负责定量计算。模型输出的是这个人群包在信息流渠道的竞争激烈程度是高/中/低然后由公式根据竞争程度、历史 ROI、预算约束算出具体出价。出价公式的核心逻辑是建议出价 基准出价 × 竞争系数 × ROI 修正系数 × 预算约束系数其中基准出价来自历史同期数据竞争系数由模型判断给出高1.3中1.0低0.8ROI 修正系数根据该人群包近 7 天 ROI 与目标 ROI 的比值计算预算约束系数在预算紧张时下调。这个设计的好处是可解释、可干预。运营同学看到建议出价能清楚知道是哪个系数在起作用而不是面对一个黑盒数字。我们内部有个说法模型可以给建议但公式必须能算账。2.4 效果归因 Agent 的数据回流机制效果归因 Agent 是整个闭环的最后一环也是最容易被忽视的一环。很多团队做完投放就不管了数据不回流下一轮还是从零开始。我们的做法是T1 回流 实时回流双通道。T1 回流的是完整的转化数据用于更新人群标签和文案库实时回流的是点击和曝光数据用于当天的出价调整。两个通道的数据格式统一都写入同一个特征库。这里有个技术细节归因窗口的选择会直接影响模型判断。货拉拉的转化链路比较长用户可能今天看到广告三天后才下单。如果归因窗口设得太短会低估某些渠道的效果。我们最终把点击归因窗口设为 7 天曝光归因窗口设为 1 天这个参数是经过多轮 A/B 实验调出来的。3. 实操过程与核心环节实现3.1 从零搭建一个文案生成 Agent 的完整步骤假设你现在要从零开始做一个货拉拉的文案生成 Agent我会按下面的顺序推进。第一步数据准备。收集过去 6 个月的历史广告文案字段包括文案正文、渠道、人群包 ID、曝光量、点击量、转化量。清洗掉曝光量低于 1000 的样本剩下的按转化率排序每个渠道取 top 20% 作为 few-shot 候选池。第二步标签对齐。把人群包 ID 映射到标签体系确保每条历史文案都能对应到具体的人群特征。这一步最耗时因为历史数据的人群包命名很乱需要人工梳理一遍。第三步提示词迭代。先用一个基础 prompt 跑 100 条测试人工评估生成质量找出问题比如语气不对、信息缺失、合规问题然后针对性修改 prompt。这个循环我们跑了大概 8 轮才把 prompt 稳定下来。第四步微调模型。当 prompt 优化到瓶颈后用积累的高质量文案数据做 LoRA 微调。训练数据大概 5000 条训练时间 4 小时左右。微调后的模型在同样 prompt 下生成质量有明显提升尤其是行业术语的准确性。第五步上线灰度。先在一个小渠道比如短信灰度观察一周的点击率和客诉率。确认没问题后再逐步扩大到信息流和 Push。实操心得不要跳过灰度直接全量。我们有一次因为赶活动微调模型没灰度就全量上线结果模型在某个小众人群上生成了不合适的文案虽然量不大但客诉处理花了两天。灰度这一步省不得。3.2 智能体工作流的编排实现四个 Agent 的编排我们用的是工作流引擎而不是让模型自己决定调用顺序。原因很简单营销流程是确定的不需要模型来规划。人群洞察 → 文案生成 → 投放策略 → 效果归因这个顺序是固定的用工作流引擎串起来更稳定、更可控。每个 Agent 的输入输出都定义了严格的 schema。比如人群洞察 Agent 的输出必须是{ audience_packages: [ { package_id: string, tags: [string], priority: high|medium|low, estimated_size: number } ], reasoning: string }这个 schema 是下游 Agent 的输入契约任何不符合 schema 的输出都会被拦截并重试。我们统计过加了 schema 校验之后Agent 之间的数据错误率从 12% 降到了 1% 以下。工作流的并发控制也很重要。文案生成 Agent 一次可能要生成几百条文案如果串行调用模型延迟会很高。我们的做法是批量并发 限流同时最多 20 个并发请求超出的排队。这样既能压满模型推理资源又不会把服务打挂。3.3 模型部署与成本控制模型部署我们走的是混合部署路线微调后的小模型部署在自有 GPU 集群上通用大模型走 API 调用。这样做的原因是成本结构不同——小模型高频调用自建更划算大模型低频调用按量付费更灵活。自有集群的配置是 4 台 8 卡机器跑 13B 模型的推理单条文案生成延迟在 800ms 左右。这个延迟对于营销场景是可以接受的因为文案生成是异步任务不需要实时返回。成本控制上我们做了三件事。第一是缓存相同人群包和渠道的文案如果 24 小时内已经生成过直接复用缓存结果。第二是降级当 GPU 集群负载过高时自动降级到更小的模型保证服务不中断。第三是配额每个活动每天有生成条数上限防止某个活动异常刷量。实测下来这套方案把单条文案的生成成本从最初的 0.15 元降到了 0.02 元以下降幅超过 85%。4. 常见问题与排查技巧实录4.1 模型输出不稳定怎么办这是最常见的问题。同一个 prompt今天生成的文案和明天生成的可能风格差异很大。原因通常是模型温度参数设置不当或者上下文注入不稳定。我们的解决方法是温度固定 上下文标准化。文案生成任务把温度设为 0.7既保证多样性又不至于失控。上下文注入时所有标签按固定顺序排列数值型标签统一保留两位小数避免因为格式差异导致模型理解偏差。还有一个隐藏原因是模型版本漂移。如果用的是 API 模型服务商可能在不通知的情况下更新模型版本导致输出风格变化。我们的做法是锁定模型版本号并且在 prompt 里记录版本信息一旦发现输出异常能快速定位是不是版本问题。4.2 合规校验漏网怎么排查合规问题是最不能容忍的。我们建立了一套三层排查机制。层级排查方式覆盖范围响应时间第一层模型自检提示词内置禁用词实时第二层规则引擎正则 关键词库实时第三层人工抽检每日随机抽 5%T1如果发现漏网排查顺序是先看规则引擎的关键词库是不是没覆盖到再看模型的提示词约束是不是不够强最后看是不是模型本身对某个表达有偏好。我们遇到过一次模型特别喜欢用薅羊毛这个词虽然不算违规但和货拉拉品牌调性不符后来在提示词里明确禁止了这类网络用语。4.3 Agent 之间数据传递出错怎么定位Agent 之间的数据传递出错表现往往是下游 Agent 报错或者输出异常。定位方法是在每个 Agent 的输入输出加日志记录完整的 JSON 数据和时间戳。我们遇到过一个典型问题人群洞察 Agent 输出的estimated_size是字符串类型但投放策略 Agent 期望的是数字类型导致计算报错。这种问题靠看日志一眼就能发现但如果没日志可能要排查半天。避坑技巧schema 校验要严格但错误提示要友好。我们一开始的 schema 校验只返回校验失败不告诉具体哪个字段错了排查效率很低。后来改成返回具体字段路径和期望类型排查时间从平均 30 分钟降到了 5 分钟。4.4 效果不达预期怎么归因投放效果不好可能是人群选错了可能是文案不行可能是出价太低也可能是外部环境变化。归因的关键是控制变量。我们的做法是分层归因先看整体 ROI 是否达标不达标再看是哪个渠道拖后腿锁定渠道后看是哪个时间段效果差锁定时间段后看是哪个文案变体点击率低。这样一层层缩小范围最终定位到具体问题。有一个容易被忽视的因素是竞品动作。如果某个时间段所有渠道的效果都下滑很可能是竞品在加大投放抢了流量。这种情况模型是看不出来的需要人工结合市场信息判断。所以我们的归因报告里会留一个外部因素栏位由运营同学填写。5. 一些踩过的坑和真实体会5.1 不要迷信大模型什么都能干我们早期有个误区觉得大模型能力强就把所有任务都交给它。结果发现有些任务用规则引擎做效果比模型好十倍成本只有百分之一。比如禁用词校验、数值计算、格式转换这些确定性任务根本不需要模型。模型真正擅长的是模糊判断和内容生成比如判断一个文案的语气是否合适、生成多个变体、从非结构化数据里提取意图。把模型用在它擅长的地方才是正确的姿势。5.2 提示词工程是持续迭代的活提示词不是写一次就完事的。我们的提示词库有版本管理每次修改都记录修改原因和效果对比。有些提示词改了之后效果提升明显有些改了反而变差这些都需要数据说话。我的体会是提示词优化到一定程度后边际收益会递减。这时候应该转向微调或者换模型而不是继续在提示词上死磕。我们大概在 prompt 优化了 8 轮之后就转向了 LoRA 微调效果提升比继续改 prompt 明显得多。5.3 人机协作的边界要清晰最后说一个非技术但很重要的点人和模型的职责边界必须清晰。我们的原则是模型负责生成候选和给出建议人负责最终决策和兜底。任何直接面向用户的投放都必须经过人工确认或者规则校验不能完全交给模型自动执行。这个原则听起来保守但在营销场景下是必要的。营销广告直接关系到品牌形象和用户信任一次翻车可能抵消几个月的优化成果。模型可以大幅提升效率但最终的责任还是在人身上。这套东西我们跑了大概半年从最初的单点尝试到现在四个 Agent 的完整闭环中间踩了不少坑也积累了一些经验。如果你也在做类似的事情我的建议是从小场景切入先把一个 Agent 跑通再考虑编排。一上来就搞大而全的架构大概率会烂尾。