跨国深谈← 返回←Datadog 4000 人AI赋能实战：删掉上下文反而更好

Datadog 4000 人AI赋能实战：删掉上下文反而更好

关联

人物 Simon Maple · Guy for Germany · Simon Boudrien

公司 Datadog · Cursor

概念 智能体 · 评估 · 上下文 · 开源权重模型 · 代码审查

Datadog 内部做了一个实验：把仓库里所有的智能体上下文文件全部删掉，然后跑 eval——结果性能反而显著提升了。这不是模型变好了，而是那些一年前写给 Sonnet 3.5 时代的上下文，在今天的模型面前已经变成了噪音，甚至是有害的上下文腐烂 。

从 200 人 POC 到 4000 人全面铺开

2025 年初，Datadog 内部发起了一个 cursor 的 POC，原本目标是 100 到 200 人试用。结果需求远超预期，一个月内就有大约 1000 名开发者几乎每天都在用，产品经理甚至需要手动往允许列表里加邮箱来给人开权限 。这股拉力让团队意识到需要专门建一个组来拥有这些工具和体验。

到了夏天，Cloud Code 出来后带来了第二波采用浪潮。对 Datadog 来说，Cloud Code 有一个独特优势：他们有巨大的 monorepo（单体仓库），VS Code 打开这些仓库性能很差，但 Cloud Code 跑在终端里不需要启动整个 IDE，所以很多重度用户迅速转了过去 。

12 个人服务 4000 人：Signal 和 Flow 两个团队

最初的 AI 开发者体验团队把精力全放在了 eval、指标和成本管理上，结果没有余力去重新思考开发流程本身。同时 Opus 4.5 发布后，PR 数量几乎一夜翻倍，SDLC 里的瓶颈（尤其是代码审查）变得前所未有的严重 。

于是他们拆成了两个团队，各约 6 个人：「Signal」负责指标、eval、成本治理；「Flow」专注于体验本身，解决流程瓶颈。12 个人对应 4000 名工程师 。

在成本管理上，他们刻意不走配额限制的路子——如果工程师因为手头工作确实需要大量 token，不应该被卡住。而是从系统性角度去压缩输出、减少浪费 。

Eval 实操：用历史事故回放来验证代码审查

他们的 eval 平台是用 Go 自建的，当时开源方案不够成熟，而 Datadog 自己的指标平台正好可以直接消费数据。不过 Simon 认为，今天用现成方案也完全可以，关键是能支持多种模型和多条测试线 。

第一个具体应用是代码审查 eval：从 Datadog 自己的事故数据集里，拿出已知导致过事故的 PR，让智能体做代码审查，再用一个 judge 智能体判断审查评论是否指出了会导致事故的问题。这是一个「正确答案」非常明确的场景 。

执行节奏上，eval 每晚跑一次；如果有人改了引导文档且想看影响，可以临时手动跑几轮（因为 eval 结果有波动，单次不够稳定）。成本方面，相比编码智能体本身的消耗，eval 的开销不算大，但如果每个 PR 都跑就太贵了 。

Eval 的所有权分散到了各平台团队，让他们覆盖自己平台的使用场景。但有一个明确承认的盲区：创造性的、开放式的工作（比如「应该用什么方案解决这个问题」）很难用 eval 覆盖，他们暂时接受这个缺口 。

他们正在做的下一步是：从真实的智能体使用轨迹中自动提取常见场景，再用智能体把轨迹转成 eval 用例——让 eval 的编写和更新也自动化，不依赖人 。

上下文的教训：少写、写对、别怕删

上下文在 Datadog 主要有两个来源：仓库里提交的文件，以及一个中心化的云端市场（有数百个插件/skills）。早期不设结构、让大家自由贡献是对的——门槛低，好想法容易传播 。

但用户多了之后，改一个上下文文件就影响 4000 人，变得很紧张。而且云端市场插件太多，没人知道哪个好。所以他们转向了团队级的市场：按平台或团队维护自己的上下文集合 。

然后就是开头那个实验的背景：前端团队发现 eval 表现不好，怀疑是上下文在拖后腿，于是清空了整个上下文文件跑 eval——结果分数涨了。那个文件里有一整段教智能体怎么用 yarn，但这些东西早就在模型的训练集里了，写进上下文纯粹浪费了宝贵的上下文窗口 。

有了 eval 数据撑腰，删上下文的决定虽然反直觉，但大家看到数字就接受了。没有数据的话，这个决定几乎不可能推行——因为损失厌恶心理很强，PR 审查里总有人问「你确定删这个没问题吗？

万一对某些人有用呢？」。

治理上的另一个转变：与其往上下文文件里塞东西「提前训练」智能体，不如确保工具本身的错误信息清晰、并给出下一步该做什么。在现代大仓库里，你不可能把所有上下文都前置喂给智能体 。

开源模型的差距与后台智能体

基于他们的 eval，开源权重模型要做到完全可用（假设前沿模型不继续进步），还需要在当前基础上提升大约 50% 的性能。而且这还只是针对执行类任务，创造力和开放性任务的差距他们还没法从自己的 eval 里量化 。

不过对于明确、重复的任务，开源模型已经够用了。比如 CI 失败时的 lint 错误和格式问题，后台智能体可以直接帮你修掉，不需要你手动回来处理。他们的思路是把这类「无可争辩正确」的小任务编码成后台智能体，自动推动流程，但严格限制在不改变 PR 核心决策的范围内 。

面试和晋升：从白板 coding 到真实场景

Simon 一直觉得传统的白板编程面试是低信号的。AI 让他们有机会彻底改变面试方式：给候选人一个大代码库，让他们用 AI 理解代码在做什么，然后讨论真实的工程问题——比如一段 diff 该给什么代码审查反馈。这同时也在考察候选人使用智能体的能力 。

晋升标准也在调整。初级工程师的期望提高了：以前他们通常在大型项目里做支持角色，现在因为有了 AI，他们可以独立拥有一整个工作流，关键变成「会不会问对问题」。

高级工程师的变化更大：以前做方案要花大量时间写文档和 RFC 讨论，现在更鼓励先用 AI 快速做几个 POC，实际跑出来看效果，带着具体结果回来做决策。讨论从「我觉得这行不通」变成了「我在这个场景跑过了，它确实能工作」。

本集带走

• 用 eval 证明「少即是多」：上下文会腐烂，定期用 eval 检验你的上下文文件是否还在提供价值——删掉它反而更好是完全可能的，但必须拿数据说话。
• eval 从真实轨迹自动生成：别指望开发者手写 eval 场景，从智能体的实际使用轨迹中自动提取常见模式，转成 eval 用例，让 eval 的维护也自动化。
• 上下文治理的三个原则：① 早期不设结构让大家自由贡献；② 规模大了之后按团队/平台分治，别搞一个巨型市场；③ 与其往上下文里塞「怎么做」，不如确保工具本身的错误信息和下一步指引足够清晰。
• 后台智能体先吃「无可争辩正确」的任务：CI 的 lint 错误、格式问题这类明确的小修复，交给后台智能体自动处理，严格不碰 PR 的核心决策。
• 面试给大代码库 + AI，不看白板编程：考察的是在真实场景中用 AI 理解代码、做出工程判断的能力，同时隐性地测试了候选人的智能体使用水平。
• 高级工程师先 POC 再讨论：用 AI 快速做多个原型，带着实际运行结果回来做决策，而不是花几周写 RFC 纸上谈兵。

【背景】Pi 指的是一个高度可定制的开源智能体工具框架（转写稿中称为 harness），OpenClaw 是基于 Pi 构建的。转写稿中多次出现的 claw code / clock code / flood code 均指 Claude Code。ELAD / ELON 均指 eval。

但随后我们通过时间看到的是，用户越多，改变他们就越困难。
Uh but then what we saw through time is the more user we’ve had, the harder it became to go and like change them.
—— Simon Boudrien · [35:33]

对我们来说发生的事情实际上是，一旦我们删除了整个上下文，eval 开始表现得更好，这是反直觉的，但就是这样，是的，那个文件很大，列出的东西不一定有用，或者不应该进入指导文件。
And what happened for us is actually like the eval started to perform like much better once we deleted the whole context, which was counter uh intuitive, but it’s just like, yeah, that file was pretty big and was listing stuff that was not like necessarily useful or you know, that should not go into like a steering document.
—— Simon Boudrien · [38:11]

基于我们的 eval，我认为开放权重模型要做到完全可行，假设基准线不随着该领域的进步而移动，它们需要表现得比今天好大约 50%。
Yeah so so yeah based on our evals I think open weight model to be like fully viable assuming the bar does not move as progress happened in the space would be that they would need to perform about 50% better than they are today.
—— Simon Boudrien · [47:51]