LangChain开源自建付费媒体代理：六个月内付费渠道贡献 20% 营销管道，单次报告成本降 40 倍
LangChain博客披露，其付费媒体代理于每周一汇总各广告平台数据与仓库中的线索和管道，生成摘要和PDF报告；六个月间付费媒体从贡献 0 升至 20% 的营销管道，6 月至 8 月单条合格线索成本降 30%，代理自身的早期报告工作流成本降低约 40 倍、运行时间从 18 分钟降至 85 秒。
AI解读：LangChain把付费媒体分析交给了一个住在Slack里的长时运行代理：每周一它把广告平台数据与仓库中的线索和管道拼在一起，给每个平台发一份摘要加品牌PDF，说明哪些指标变了、可能为什么、下一步做什么，团队可以在消息串里追问。
它不只是做报告，还会根据团队预设的打法和判断提出新关键词、定向调整、广告文案或新搜索广告系列。对于同时管五个付费渠道的小营销团队，这相当于多了一个随时在线的分析师。
LangChain给出的结果是：付费媒体在六个月内从贡献 0 到 20% 的营销管道；6 月到 8 月，单条合格线索成本降了 30%，同时月度支出涨了约 60%；在最大的社交渠道LinkedIn上，CPL比 1 月低 40%；把分析和报告收回内部，每月省下约 5000 美元代理费。
这些数字出自公司自己的博客，属于自报口径，没有第三方审计，也没有披露渠道构成或统计口径，所以适合看作这家公司愿意公开的结果，而不是可以直接套用的行业基准。
技术上的关键取舍是把计算交给代码、把判断留给模型。第一版让模型读取全部原始数据并自己算，单份报告要处理约 390 万输入token，耗时 1112 秒、成本略高于 3 美元；改为Python拉数、对齐日期、算总量和对比、执行固定规则后，早期报告工作流便宜约 40 倍、快 13 倍，运行时间从 18 分钟降到 85 秒。
另一个取舍是数据源边界：广告平台是花费、展示、点击的权威来源，一旦有人转化，后续线索、商机和管道以仓库为准。LangChain发现，由于视频广告不一定有关键词，约 10% 的Google花费曾从仓库中缺失；Meta能告诉它有转化，但仓库更清楚转化具体是什么。代理被要求保留这些无法对齐的不确定性，并附上来源、日期窗口和归因模型。
对于需要跨多个广告平台做分析的人，这份披露里最可复用的部分不是某个数字，而是两个工程模式：一是不强求所有平台归一化成完美schema，而是逐指标指明哪个系统说了算；二是用工具目录按需检索，而不是把两百多个工具定义全塞进上下文——LangChain称这使首轮token从 38000 降到约 12000，且目录此后扩了近三倍，上下文成本基本持平。
代理已在LangChain开源，公司计划在 9 月 23 日太平洋时间上午 11 点的网络研讨会上演示并讲解代码。这些模式是否在其他公司的数据栈上同样成立，目前没有公开证据，只能由使用者自行验证。
LangChain在博客中披露，公司为付费广告业务自建了一个长时运行的付费媒体代理（Paid Media Agent），并已将其开源。该代理常驻Slack，每周一将各广告平台数据与公司仓库中的线索和管道数据合并，为每个平台生成一份摘要和品牌PDF，说明发生了什么变化、可能的原因以及团队下一步可以做什么。团队可以在消息串中 @ 它追问广告系列、成本或管道问题。
按照博客给出的数据，付费媒体在六个月内从贡献 0 提升到公司营销管道的 20%；6 月至 8 月，单条合格线索成本（CPL）下降 30%，同期月度支出上涨约 60%；在LinkedIn这一最大的社交渠道上，CPL比 1 月低 40%。公司称将分析和报告收回内部后，每月节省约 5000 美元代理费用。
代理本身的优化也被量化：早期报告工作流通过把计算移入代码、去掉不必要的模型调用，成本降低约 40 倍、速度提升 13 倍，运行时间从 18 分钟降至 85 秒。
LangChain表示，付费媒体代理已开源，可用作自建代理的起点；公司还将于 9 月 23 日太平洋时间上午 11 点举办网络研讨会，演示该代理并讲解代码与设计决策。
代理每周一在Slack里做什么
该代理被设计为一个持续运行的“付费媒体分析师”。它跟踪新产品公告、起草广告系列、添加关键词、测试变体，并把建议的实验提交给团队审批。长期目标是形成持续学习闭环：分析表现、做出改动、观察结果、记录学到的东西，再应用到后续广告系列。
在实际使用中，每周一它会合并广告平台数据与仓库中的线索和管道数据，为每个平台发布摘要和品牌PDF。团队可以在消息串中提问，它也会基于公司预设的打法和编码后的判断，提出新关键词、定向调整、广告文案或新的搜索广告系列建议。
- 付费媒体六个月内从贡献 0 到 20% 的营销管道（公司自报）
- 6 月至 8 月，单条合格线索成本下降 30%，月度支出上涨约 60%
- LinkedIn渠道CPL比 1 月低 40%
- 将分析报告收回内部，每月节省约 5000 美元代理费
把计算交给代码，把判断留给模型
第一版代理让模型做全部工作：把所有广告系列行、关键词、管道记录和落地页检查都载入上下文，再要求模型计算花费、环比变化、对广告系列分类并写报告。博客称这能跑通但效率低：在固定测试集上，单份报告要处理约 390 万输入token，耗时 1112 秒，成本略高于 3 美元，而且每次都要重新计算底层数字，结果更难信任。
现在的做法是Python负责确定性工作：拉取数据、对齐日期窗口、计算总量和对比、应用固定规则，把紧凑结果写入沙盒；模型转而负责需要判断的部分，比如串联证据、解释可能原因、对照目标评估广告系列并给出下一步建议。博客称这一改动让早期报告工作流便宜约 40 倍、快 13 倍，运行时间从 18 分钟降到 85 秒。
- 第一版：单份报告约 390 万输入token，1112 秒，成本略高于 3 美元
- 优化后：成本约降 40 倍，速度约提升 13 倍，运行时间 18 分钟降至 85 秒
- 代码负责计算、日期对齐、账户匹配和硬性保护规则；模型负责解释与建议
- 示例保护规则：不允许因一周表现差就砍掉最大的管道来源，该规则写在代码里，模型无法覆盖
六个平台、两套数据源，先定义谁说了算
LangChain面对六个平台，各有不同的ID、转化定义、归因窗口和广告系列层级。博客称，把一切归一化成完美schema会增加复杂度，也不一定让数据更可信，因此改为逐类指标指定权威来源：广告平台是花费、展示、点击等媒体活动的权威来源；一旦有人转化，线索、商机、管道等下游结果以公司仓库为准。
这些规则被写入代理的业务wiki，并且移除会让代理查错系统的工具。博客举了两个例子说明为什么这重要：Google视频广告不一定有关键词，而仓库此前用关键词关联广告系列数据，导致约 10% 的Google花费从仓库中缺失，尽管Google自己持有正确的花费数据；Meta能说明某条广告带来了转化，但仓库更清楚转化具体是“联系销售”还是“注册”。
- 广告平台对花费、展示、点击负责；仓库对线索、商机、管道负责
- 视频广告无关键词导致约 10% Google花费曾从仓库缺失
- Meta知道有转化，仓库知道转化是什么类型
- 数据无法可靠关联时，代理保留限制并附上来源、日期窗口和归因模型，而不是填补空白
把两百多个工具藏在一个检索接口后面
博客指出，回答“我们的广告花费带来了多少管道”需要同时访问广告平台和大查询仓库。广告平台的MCP暴露了 200 多个工具；早在 6 月，即便只是较小的只读目录，光是加载工具名称、描述和参数就要 38000 token，而其中大部分与具体问题无关。仓库侧也存在类似问题：为每种新的分组方式（例如按单个销售商机看管道）单独建工具。
解决办法是给代理一个小的查找接口。广告平台目录收敛为三个工具：搜索（按问题找到最多 8 个工具）、读取（只为选中工具加载完整schema）、运行（通过自家服务器执行，写入操作走单独的审批通道）。仓库侧增加了两个灵活工具：描述可用表和字段、运行分析查询。博客称这使首轮token降到约 12000，比加载全部schema便宜 4 倍，且评判质量相同；目录此后扩了近三倍，上下文成本基本持平。在 60 次实盘运行中，固定工具能处理常规问题但会正确报告更深入的问题不受支持，带查询接口的版本则回答了全部分析类问题，最终两种方式都保留。
- 广告平台MCP暴露 200 多个工具；6 月只读目录加载就需 38000 token
- 检索接口把首轮降到约 12000 token，便宜 4 倍
- 目录扩近三倍后，上下文成本基本持平
- 固定工具走快速路径，查询接口处理未预料到的问题
从两个代理图改成一个运行时
博客披露，团队最初建了两个代理图：每周报告代理按计划运行、产出物重，使用Deep Agent、沙盒、大模型和PDF生成；Slack要求秒级回答，因此用更便宜的模型跑轻量循环，带Google Ads和仓库工具，没有沙盒，只读访问。这个拆分只维持了五周，因为每项新能力都要实现两次，功能到达Slack和报告的时间不一致，Slack没有沙盒因此无法处理附件，也无法就周一报告追问，因为PDF来自另一个图。
现在只有一个图，每次请求全新实例化：Slack @ 提及和周一定时任务以不同运行模式进入；定时运行只看到一个task() 工具，按平台委派给相应子代理；Slack获得更广的读取、仓库和广告系列操作工具集。同一个运行时配不同能力配置，托管在LangSmith Deployment上，由后者处理托管、伸缩和计划任务。由于Slack现在共享同一沙盒架构，代理还能打开报告PDF并在产生它的消息串中回答追问。
- 两个代理图的拆分只维持了五周
- 统一后：每次请求实例化一个图，按入口分配能力配置
- 定时运行每平台一个子代理；Slack获得更广工具集
- 统一后Slack可打开PDF并回答对应消息串中的追问
隔离需要显式设计：共享完成标志曾让一个平台漏掉报告
博客称，在测试三种架构后，团队选择了父代理加子代理的方案：按平台单独运行的架构最简单，但在实际工作流中表现最差，因为每个运行只看到一个平台，系统会输出多条Slack消息，难以综合跨渠道表现；合并的两种方案都能输出单一结果并做跨渠道综合，父加子代理让父上下文保持较小，同时给每个平台自己的上下文窗口。
但独立的上下文窗口不等于自动隔离。博客举了两个必须显式修复的问题：两个子代理曾写报告到同一位置并共享同一个“完成”标志，第一个完成后第二个可能误以为自己也完成了，从而不产出报告，修复办法是给每个平台独立的报告位置和完成状态；另一个子代理无法确认自己的PDF是否渲染成功，于是一直检查文件、消耗大量token，甚至尝试从零重建PDF，修复办法是子代理只保留三个工具——读取上下文、计算、渲染，渲染成功即视为任务完成。
- 三种架构在实盘数据上测试：单平台独立运行、单代理全平台、父代理加每平台子代理
- 单平台独立运行产生多条Slack消息，跨渠道综合最差
- 共享完成标志导致某平台不产出报告，改为每平台独立报告位置和状态
- 子代理工具收敛为读取上下文、计算、渲染三个，渲染成功即完成