LangChain 前三年几乎靠开源、内容和社区自然增长。今年一月他们要从零启动付费投放，半年内扩到五个渠道——一个小营销团队要同时盯多平台 campaign、素材实验和不断膨胀的效果数据，手工管不过来。
于是他们造了一个 Paid Media Agent，并且开源了全部代码。
#结果
- 付费渠道六个月从 0 做到 20% 的营销管线
- 单个合格线索成本（CPL）六月到八月降 30%，月花费反而涨了约 60%；最大渠道 LinkedIn 的 CPL 比一月低 40%
- 分析和报告收回内部，每月省约 $5K 代理费
- 报告工作流优化后便宜 40 倍、快 13 倍：运行时长从 18 分钟降到 85 秒
#造了什么
一个住在 Slack 里的长时程 agent。每周一它合并广告平台数据和数仓里的线索管线数据，按平台产出摘要和品牌化 PDF，说清变了什么、为什么、下一步该做什么。团队在帖子下 @ 它追问 campaign、成本、管线问题；它也会按 playbook 主动提议新关键词、定向调整、广告文案或新搜索 campaign，走人工审批后落地。目标是跑成一个持续学习循环：分析效果 → 提议改动 → 观察结果 → 沉淀经验。
#怎么搭的：coding agent 是知识员工
核心原则一句话：coding agent 是一个知识工作者 。知识工作就是读文件、转换信息、跑分析、写东西——coding agent 用文件和 shell 做的也是这些事。
所以团队把它当一个新来的投放分析师来装备：给一台电脑（沙箱）、要用的软件、数据访问权限、公司业务文档。沙箱里预装 pandas 和 DuckDB，软件和业务 wiki 打进快照镜像，启动快了 10 秒。不同 agent 配不同电脑：内容生成 agent 的沙箱更像剪辑工作站（无头浏览器、ffmpeg、品牌手册），财务 agent 才需要 openpyxl 和重型数仓。
#上下文分五层，prompt 只当地图
给对了电脑之后，更难的是给对上下文。朴素做法是全塞进 system prompt——又贵又容易过期。他们的认知是：瓶颈常在上下文窗口而非模型本身，很多"推理失败"其实是上下文失败 ——要么缺关键信息，要么无关信息抢注意力。
所以 prompt 不当知识仓库，只当地图 ：知识放在结构可预期的文件里，agent 按需加载。具体分五层，按变化速度排序：
- System prompt ：只定义角色和导航——一句话说清职责，三个小节讲怎么操作、数字从哪来、怎么呈现，其余全是指针（playbook 在这、wiki 在那、先读索引）
- Skills ：六个文件夹的操作说明，运行时渐进披露，agent 一开始只看到标题和描述
- Wiki ：十九页公司特定知识——漏斗怎么运转、每个 campaign 图什么、哪个数据源对哪个数字负责、七月做了什么决定为什么
- 实时工具 ：花费、设置、管线天天变，请求时才取（218 个调用）
- 确定性代码 ：凡是要求一致可复现的都写成代码——计算、日期窗口、账户匹配、硬性护栏。比如"不许因为一周数据差就砍掉管线主力渠道"是代码强制的，模型无法覆盖
最难画的一条线是 skill 和 wiki 的分界，他们给的判据很漂亮：skill 应该"搬到别的公司也能用"，wiki 不应该 。skill 装的是可复用的工作方法，wiki 装的是这家公司特有的上下文。
#一次踩坑：两套 graph 合并成一个 runtime
最初他们建了两个 agent graph：周报 agent 走定时任务、重产物（Deep Agent + 沙箱 + 大模型 + PDF）；Slack 问答要秒回，用便宜模型的轻量 loop，无沙箱、只读。
这个分裂只撑了五周——每个新能力要实现两遍，功能在不同入口不同步，Slack 没法处理附件也没法回答周报 PDF 的追问。错误在于把"两个入口"当成了"两个产品"：它们背后是同一套 wiki、skills、工具和规则。
现在只有一个 graph，每次请求新实例化：Slack @ 和周一 cron 只是不同 run mode，定时模式只暴露一个 task() 工具去派 subagent，Slack 模式拿到更宽的读取和 campaign 工具集。同一 runtime，按入口配能力 profile。
#六条技术教训
1. 模型只做判断，计算全给代码。 第一版周报把几百万行 campaign 数据全塞进 context 让模型自己算——单次报告吃掉 390 万输入 token，1112 秒、$3+，还不敢信结果。改成 Python 取数、对齐日期、算汇总、应用规则、写一版紧凑结果进沙箱，模型只做需要判断的事：串证据、解释原因、对照目标评估、给建议。
2. 每个指标指定唯一权威数据源。 六个平台 ID、转化定义、归因窗口都不一样，硬 normalize 成一个完美 schema 是徒劳。改为逐指标定边界：广告平台对花费/展示/点击负责，数仓对线索/商机/管线负责。真实教训：约 10% 的 Google 花费在数仓里丢了（视频 campaign 没有关键词可 join），而 Meta 能说清转化发生、数仓才说得清转化是什么。规则写进 wiki，并直接收走"会去错系统取数"的工具。join 不干净时 agent 不硬填坑，而是把来源、日期窗、归因模型标在答案里。
3. 让 agent 自己发现工具，别全量加载。 Pipeboard 的 MCP 暴露 200+ 广告平台工具，六月时较小的只读目录也要 3.8 万 token 才能装完工具定义——问题还没读就先花这么多。解法是给一个小接口：search 按问题找至多 8 个工具，read 只载入选中工具的完整 schema，run 执行（写操作走单独的审批通道）。首轮 token 降到约 1.2 万，同质量下便宜 4 倍；目录后来扩大近三倍，成本基本不变。数仓侧同样思路：保留固定查询工具走快路径，加一个"describe 表结构 + 跑分析查询"的通用接口处理意料外的问题——60 次实测里带查询接口的版本答出了所有分析问题。
4. 隔离要显式设计，subagent 只给你独立窗口。 他们测了三种架构：每平台独立 run（无法跨平台综合）、单 agent 管全部、父 agent 委派每平台一个 subagent。最终选第三种，但独立上下文不等于真隔离：两个 subagent 共享同一个"完成"标志位，先写完的会让后写的误以为自己也完了直接停手；还有个 subagent 为验证自己的 PDF 有没有渲染成功反复检查、烧了一堆 token 最后试图从零造 PDF。修法：每平台独立产物位置和完成状态，subagent 只给三个工具（读 context、计算、渲染），渲染成功即收工。
5. 给 agent 一条从分析到行动的路。 只会分析的 agent 只是个更好看的仪表盘。它能直接在 Slack 提议改动（加关键词、改地域定向、建搜索 campaign），但权限要跟上：服务器按 Slack 用户 ID 校验，指定成员才能批准；提议以 Block Kit 审批卡呈现，授权人可对比现值与提议值、编辑后批准；代码执行改动并回查平台确认生效。agent 管分析和建议，人管动不动手。
6. 界面跟着工作走。 Slack 作为第一界面的好处是审批卡和分析讨论在同一个 thread 里，跨团队的人能插话而 campaign owner 仍掌决定权。但复杂工作（多广告组、批量改、多轮修改）超出 Slack 的承载，这部分正在迁向围绕 agent 的专用界面，Slack 退守轻量问答和审批。
#下一版会带走的原则
按招聘的标准装备 agent（沙箱、库、数据、文档）；可复用方法和公司知识分层；可复现的工作写代码；边界显式设计；优化目标先问"能不能把活干完"再看 token 成本；让真实使用暴露集成短板——agent 反复答不好的问题，就是该补干净 join 和专用工具的地方。
下一步是让它更主动：持续盯效果、浮出值得注意的波动、提议新实验。更大的图景是把 GTM 各环节的 learnings 连成共享知识——campaign 互动反过来指导销售跟进，管线进展校准理想客户画像。