LangChain 开源付费媒体智能体：模型管判断、代码管计算，六个月吃下五条投放渠道

一句话结论

LangChain 把自家付费媒体投放做成一个常驻 Slack 的智能体：每周一自动拉广告平台数据+数据仓库管道，产出各平台品牌 PDF 周报；团队在 Slack 里 @ 它追问任何成本和管道问题；它能提案加关键词、改定向、建新搜索广告，改动走 Block Kit 审批卡、指定成员批准后由代码执行并回验。六个月内付费渠道从占营销管道 0% 做到 20%，合格线索成本（CPL）三个月降 30%（月花费涨 60% 的同时），自建省下每月约 5000 美元代理费；把计算挪进代码后，单次报告工作流便宜 40 倍、快 13 倍（18 分钟→85 秒）。整套智能体已开源。

为什么自己造：营销团队的规模化困境

LangChain 前三年的销售管道基本靠自然增长：开源、内容、YouTube、社区和线下聚会。今年 1 月他们要启动付费广告计划，触达自然渠道够不到的人群——新区域和企业决策者。目标是在六个月内从自然增长引擎扩展到五条付费渠道。

小营销团队随之而来的是三重技术障碍：每个广告平台自己的数据 schema，跨渠道对齐性能很困难；广告参数与他们真正关心的结果（销售咨询、注册、内容下载）无法干净映射；产品发布节奏加快、campaign 数量增长后，「什么在跑、什么有效、下一步试什么」靠人工已经管不过来。

于是他们造了一个智能体：追踪新品发布、起草 campaign、加关键词、测变体、把实验提案提交团队审批，长期形成一个持续学习闭环——分析表现、做一处改动、观察结果、记录学到的东西、用到下一轮 campaign。

核心成果数据

• 付费媒体六个月内从占营销管道 0% 做到 20%。
• 合格线索成本（CPL）从 6 月到 8 月降 30%，月花费同期涨约 60%；最大社交渠道 LinkedIn 的 CPL 比 1 月低 40%。
• 把分析和报告从代理机构收回来，每月省约 5000 美元。
• 优化智能体本身——计算挪进代码、砍掉多余模型调用——早期报告工作流便宜约 40 倍、快 13 倍，运行时间从 18 分钟降到 85 秒。

造了什么

付费媒体智能体是一个常驻 Slack 的长驻智能体。每周一，它把广告平台数据与仓库里的线索和管道数据合并，给每个平台发一份摘要和品牌化 PDF，解释什么变了、为什么、团队下一步该做什么。

团队可以在话题串里 @ 它追问 campaign、成本或管道问题。它也能基于自家 playbook 和编码进去的判断规则，提案新关键词、定向改动、广告文案或新搜索 campaign。

怎么造的：把智能体当知识工作者

整个构建围绕一条原则：编码智能体就是知识工作者。知识工作读文件、转信息、跑分析、写结论；编码智能体用文件和 shell 干同样的事。

他们像对待一位新入职的付费媒体分析师那样对待它：给一台电脑、干活要用的软件、数据的访问权、以及业务运作方式的文档。

操作系统层用 LangChain Deep Agents 做智能体骨架，不用从零造基础设施。像操作系统一样，Deep Agents 管文件访问、代码执行和工作内存，给模型规划任务、向子智能体分派、随任务变复杂管理上下文的工具。付费媒体的工具、技能和业务知识叠在这个地基上。

电脑：每次运行默认有一个 LangSmith Sandbox——隔离的 microVM，32GB 磁盘加一个 shell。装 pandas 和 DuckDB 做分析、openpyxl 处理表格、WeasyPrint+Jinja2 生成报告。旁边是工作数据和业务知识，以 Markdown 存在六个技能和一份十九页 wiki 里。软件和 wiki 烤进快照（sandbox 的启动镜像），平均启动时间省 10 秒。不同智能体需要不同的电脑：内容生成智能体的 sandbox 像视频剪辑工作站（无头浏览器、ffmpeg、媒体工具、品牌手册）；财务智能体可能要 openpyxl 和 DuckDB。活儿决定电脑怎么配。

上下文五层法：提示词是地图不是容器

有了电脑，下一个挑战是给对上下文。人类分析师需要理解角色、方法、公司、正在发生的事、要遵守的规则。天真的做法是全塞系统提示词——结果又长又贵还容易过时。

更好的思考方式：瓶颈往往在上下文窗口而不是模型。很多看似推理失败的案例其实是上下文失败——要么缺对的信息，要么太多无关信息抢注意力。他们不把提示词当知识容器，而是当地图：知识放在位置可预测的结构化文件里，智能体按任务需要只加载当下要用的部分。

上下文分五层（按变化速度排序）：

• 系统提示词：定义角色和导航。开头一句角色描述，后跟三小节：怎么干活、数字从哪来、怎么呈现结果。其余全是指针——playbook 在这、wiki 在那、先读索引。
• 技能（Skills）：六个指令文件夹，运行时渐进披露，智能体最初只看到各自的标题和描述。
• Wiki：十九页，讲漏斗怎么运作、每个 campaign 的目标、哪个数据源管哪个数字、团队做过什么决定以及为什么。
• 实时工具：花费、设置、管道天天变，智能体按请求时点抓取，这类调用有 218 个。
• 确定性代码：一切要求一致可复现的东西——计算、日期窗口、账户匹配、硬性护栏——都进代码。比如「禁止把头号管道贡献者在一周表现差后就砍掉」这条规则用代码强制，模型无法覆盖。

技能和 wiki 的分界线最微妙：技能讲怎么做活（读数据、跑数字、写报告、按 playbook 解读付费媒体表现），不含任何自家 campaign 细节；wiki 全是 LangChain 特有的东西（哪个 campaign 做认知、哪个该拉 demo、7 月定了什么、为什么）。**技能应该「换家公司也能用」，wiki 不应该。**这套分法沿自 Karpathy 的 LLM wiki 笔记和他们自己的 Wiki Memory 实践。

一个运行时，多个能力档位

最初他们造了两个智能体图：周报智能体走定时、重产物，用 Deep Agent+sandbox+大模型+PDF 生成；Slack 侧要秒回，用便宜模型上的轻量循环，只有 Google Ads 和仓库工具、只读、无 sandbox。

这个分叉只活了五周：每个新能力要实现两遍；功能到达 Slack 和报告的时间不同步；Slack 侧没 sandbox 处理不了附件，也没法对周报 PDF 追问——PDF 是另一张图产的。

错误在于把它们当两个产品。它们是同一分析的两个入口，背后是同一份 wiki、技能、工具和数字源规则。改成每个请求隔离状态与能力：每个话题串有自己的 sandbox 和 checkpoint，每次运行只看到自己需要的工具。现在只有一个图，每次请求全新实例化：Slack @ 和周一定时任务以不同运行模式进入；定时任务只见一个 task() 工具，按平台委派给子智能体；Slack 侧拿到更宽的读、仓库、campaign 操作工具集。同一运行时、不同能力档位，托管在 LangSmith Deployment 上。因为 Slack 侧共享同一 sandbox 架构，智能体还能打开报告 PDF 在产生它的话题串里答追问。

教训：一个运行时配多个入口的能力档位；同一个工厂可以给不同用户不同的技能和权限。

五条关键技术教训

一、模型管判断，代码管计算

第一版周报让模型包办一切：所有 campaign 行、关键词、管道记录、落地页检查全进上下文，让模型算花费、环比、给 campaign 分级、写报告。能用，但效率极差——冻结测试集上单次报告处理约 390 万输入 token（模型要读全部原始数据并反复自行计算），单次 1112 秒、成本 3 美元出头，而且模型每次都要重算底层数字，结果难以信任。

改法：Python 负责取数、对齐日期窗口、算总额和对比、套固定规则，把紧凑结果写进 sandbox；模型只做需要判断的活——串联证据、解释可能原因、按目标评估 campaign、建议下一步。

二、每类指标定义唯一真源

六个平台有各自的 ID、转化定义、归因窗口和 campaign 层级。与其归一成一个完美 schema，不如按指标类型定义该信哪个系统：广告平台是媒体行为（花费、展示、点击）的真源；转化发生后，下游结果（线索、商机、管道）以仓库为准。

为什么重要——两个实战案例：仓库用关键词关联 campaign 数据，但 Google 视频campaign 不总有关键词，约 10% 的 Google 花费在仓库里缺失（Google 自己的数据是对的）；Meta 相反——它能告诉你某条广告产生了转化，但「转化到底是什么」（联系销售 vs 注册）仓库更清楚。

真源规则编码进智能体：写进 wiki，并删掉会让智能体对某类指标查错系统的工具。数据无法可靠 join 时，智能体不硬补——保留局限说明，答案里带上来源、日期窗口和归因模型，让团队明白每个数字怎么来的。不需要先有完美数据模型才能跨系统工作；更重要的是每类指标的真源显式化，对账不清时保留不确定性。

三、让智能体按需发现工具，别预载全部

答「广告花费带来多少管道」要跨两套系统：广告平台给花费和点击，BigQuery 仓库把 campaign 活动和网站转化关联到合格线索、Salesforce 商机和管道。

Pipeboard 的 MCP 暴露 200+ 广告平台工具。6 月时即便是精简只读目录，加载可用工具的名字、描述、参数就要 3.8 万 token——发生在读到用户问题之前。仓库侧有对称问题：固定查询覆盖常见问题，每种新分组（按单个销售商机看管道）都要再写一个专用工具。

解法是给智能体一个小型发现接口。Pipeboard 目录折到三个工具后面：Search（按问题找出至多 8 个工具）、Read（只加载选中工具的完整 schema）、Run（经自家服务器执行；campaign 写操作走独立审批通道）。仓库侧加两个灵活工具：描述可用表和字段、跑分析查询。智能体检查 schema、按问题组合查询，不依赖预建工具。

目录方案把首轮对话压到约 1.2 万 token，对比全量加载 schema 便宜 4 倍且质量持平；此后目录翻了近三倍，上下文成本基本不变。60 次真实运行的 A/B 测试：固定工具对常规问题表现好但对深层问题正确报「不支持」；带查询接口的两个版本答出了全部分析问题。最终两种都保留——固定工具走快车道，查询接口兜住没预料到的问题。

四、显式设计隔离

共享运行时后新问题：怎么让智能体分析五个平台而不把所有平台数据塞一个上下文窗口？在真实数据上测了三种架构：每平台独立运行、单智能体全包、父智能体按平台委派子智能体。

独立运行最简单但实际工作流表现最差——每次运行只见一个平台，系统产出多条 Slack 消息、跨渠道综合做不好。两种合并方案都能产出单一、带跨平台综合的输出；最终选父+子智能体架构：父上下文保持小，每个平台有自己的上下文窗口装平台数据和 caveat。

但独立上下文窗口不自动等于隔离，还要显式设计。两个踩过的坑：其一，两个子智能体写同一报告位置、共享同一个「完成」标志，第一个完成后第二个把状态误认成自己的、没出报告就停了——修法是每个平台有自己的报告位置和完成状态。其二，一个子智能体无法确认自己的 PDF 是否渲染成功，反复查文件烧掉大量 token，最后试图从头重建 PDF——修法是子智能体只给三个工具（读上下文、计算、渲染），渲染成功即完成。

子智能体给你独立上下文窗口，隔离模型的其余部分靠你自己定义：能用哪些工具、能访问哪些文件和状态、必须返回什么、失败怎么处理。

五、给智能体从分析到行动的路径

只会分析表现的智能体终究是块更好的仪表盘。智能体可以在 Slack 里直接提案改动：加关键词、改地理定向、建新搜索 campaign。

行动能力带来新要求：权限。付费媒体之外的团队可以用它问 campaign 表现和管道问题，但只有指定成员能编辑或批准 campaign 改动。服务器先核 Slack 用户 ID 再接受操作，其他人请求被挡、提案保持待审。每个提案出现在 Block Kit 构建的 Slack 审批卡上，授权审核人对比现值与提案值、可编辑、批准最终方案；代码执行批准的改动并回查广告平台确认成功。职责分离清晰：智能体分析表现、推荐行动，人控制行动是否执行。闭环不止要写权限——要带权限、审批和验证的完整行动路径。

（第六条经验：界面匹配工作。Slack 适合聚焦决策——审批卡就住在产生它的分析和讨论里；campaign 一复杂——多广告组多素材、批量编辑、多轮修订——Slack 就难当主工作区，这类工作流正迁往围绕智能体构建的专属界面，Slack 保留为轻量问答、看推荐、批改动的地方。）

下次构建会带走的原则

• 像给新员工配装备一样给智能体配 sandbox、趁手的库、正确的数据访问和清晰的文档；设计好的工作区让它不需要每个新问题都配专用工作流。
• 可复用指令与公司知识分开：技能讲怎么做活，wiki 讲业务，实时工具给当下信息；分层分开让每层可独立更新而不膨胀系统提示词。
• 该可复现的活进代码：计算、对比、硬规则；模型专注解读结果和判断含义。
• 边界要显式设计：子智能体的工具、文件、状态访问、返回物和失败处理都要有清晰规则——独立上下文窗口只是隔离的一部分。
• 以「能否把活干完」为优化目标：token、成本、延迟重要，但以完成率和回答质量一起评估。
• 让真实使用告诉你哪里该改集成：智能体反复答不好的问题，暴露哪里值得做更干净的 join、更好的定义或专用工具。

下一步与开源

当前智能体主要响应定时任务和团队请求。下一步是更主动：持续监控 campaign 表现、浮出值得关注的变化、给团队提案新实验和优化。更大的机会是把这些学习跨 GTM 打通——campaign 互动数据指导销售跟进，管道进展、销售对话和成交结果反过来完善理想客户画像、影响下一轮 campaign。长期让各 GTM 智能体贡献同一份共享知识和 playbook。

整套付费媒体智能体已开源，含广告平台工具、付费媒体技能、示例 wiki、报告和审批工作流。接上自家账户、喂进公司上下文，用 Managed Deep Agents 一条命令部署到 Slack。想在自己团队复用这套智能体工作流的话，建议按「先只读问答、再周报自动化、最后开审批写操作」的顺序逐步配置和测试，每步核对真源规则与权限隔离。

原文信息

原文地址：

• 作者：Amal Irgashev、Danny Lambert、Jan Gomez（LangChain）
• 发布时间：2026-09-13
• 来源：LangChain Blog