FDE 的参考 Agent，为什么要故意留缺陷

周一早上，你来到客户的办公室。他们的 AI 团队有一个 Agent，在 notebook 里跑得好好的，一碰到真实用户就答错，而且没人知道是哪一步出了问题。他们不需要再看一场精致的演示，他们需要的是能看清 Agent 内部、并对它做度量的方法。

这正是 CoreWeave 为前线部署工程师（FDE）AI Agents 岗位描述的工作。这个岗位的人要和客户的 AI 工程团队坐在一起，用 W&B Weave 设计 Agent、做原型，并部署到生产环境。此外，岗位描述里还直接写明了工作坊、深度讲解和赋能培训，目的是帮助客户更快采用产品。

这两项工作其实是同一种能力。你搭建的参考 Agent 就是工作坊的教材，而工作坊就是检验这个 Agent 的地方。本指南介绍如何把两件事都做好，让客户团队在你离开后能自己接着干。

参考 Agent 为什么不该完美？

CoreWeave 完成对 Weights & Biases 的收购后，Weave 随之并入 CoreWeave。CoreWeave 的文档把 Weave 描述为一个可观测性与评测平台，用于追踪、评测和改进 Agent 及 LLM 应用。关键词是追踪和评测。参考 Agent 必须同时服务这两点，而不只是跑得顺。

在 Weave 的追踪模型里，每次 Agent 运行是一个对话（conversation）。对话由若干轮次（turn）组成，每个轮次包含模型调用及其工具调用。对讲师来说，这个结构非常有用：你可以直接指出 Agent 在哪一个轮次、哪一次工具调用出了错，而不是含糊地说一句“模型幻觉了”。

所以，好的参考 Agent 应该故意埋下一两个客户团队在实际工作中会遇到的典型 bug。如果 Agent 一开始就把每个任务都做对，追踪记录没什么可读，评测也没什么可改进，工作坊就成了一场表演。

一个完整的例子

假设客户是一家物流公司。他们的 AI 团队想要一个 Agent：读取投诉邮件，查询订单，再起草回复。你的参考 Agent 只需要两个工具：用 lookup_order(order_id) 查询订单，用 draft_reply(order, issue) 撰写回复。你故意让提示词在“邮件里有多个数字时如何识别订单号”这一点上表述模糊。

接下来是任务集。Weave 的 agent-evals 教程用一个裁判模型，根据每个任务的成功标准，为 Agent 完成任务的情况打分。你从客户脱敏后的真实邮件中写出 12 个任务，每个任务配一句话的标准，例如：“回复写明正确的订单号和预计送达日期，且不承诺退款。”

只靠 LLM 裁判是不够的。Weave 采用 LLM 裁判与自定义评分器相结合的方式打分，W&B 的 Agent 页面也明确说明，评分器可以是内置的、第三方的，也可以自己编写。

你再加一个非常简单的手写评分器：把工具调用中的 order_id 与正确答案比对。裁判负责评价回复质量，评分器负责核对事实，不涉及任何主观判断。

假设 v1 跑完，order_id 评分器在 12 个任务中只对了 7 个。在工作坊上，你打开一个失败任务的追踪记录，逐个轮次讲解。

模型读完邮件，用电话号码而不是订单号调用 lookup_order，拿到一个错误，却仍然起草了一封语气十足笃定的回复。在场所有人都能看到，bug 出在第一次工具调用，而不是撰写环节。

现在把键盘交给客户团队。他们修改提示词，并增加一步校验订单号格式，得到 v2。Weave 可以用同一套任务集重跑新版本，并根据记录的分数查看 v2 相比 v1 是改进还是退步。假设评分器升到 12 个对 11 个，但裁判给其中一个任务的分数比之前低。

这个退步的任务，是整场培训最有价值的一课。客户团队亲眼看到，修好一处可能弄坏另一处。他们也会明白，为什么每次改动后都要重跑整套任务集，而不是只重试引发 bug 的那封邮件。

工作坊该怎么分段？

一场三小时的培训可以按下表划分。总体原则是：客户团队上手操作的时间应逐段增加。

环节	时长	客户团队做什么	带走什么
阅读追踪记录	40 分钟	追踪失败任务的对话、轮次和工具调用	按步骤整理的失败清单
编写任务和评分器	60 分钟	用自己的数据补充任务，编写一个自定义评分器	属于自己的评测集
修复并对比版本	60 分钟	做出 v2，重跑，解读改进与退步	一张 v1 与 v2 的对比表
商定下一步	20 分钟	选定第一个要应用这套方法的真实 Agent	下一周的计划

最后一个环节在培训超时时最容易被砍掉。不要丢掉它。没有一个真实 Agent 的名字和一位负责人，前三个环节学到的东西都会躺在一个再也没人打开的 notebook 里。

常见错误

最常见的错误，是用自己的数据和技术栈搭参考 Agent，而不是用客户的。CoreWeave 承诺保持 W&B 平台的互操作性，对 FDE 来说，这意味着你要把 Weave 接入客户已经在用的框架和模型，而不是让他们改用你恰好熟悉的工具。

第二个错误，是让 LLM 裁判决定一切。裁判适合给措辞打分，但订单号、金额、日期这类代码能核对的事实，应该用手写评分器。否则客户团队会去争论裁判的分数，而不是修 bug。

第三个错误，是把工作坊当成单向交付。岗位描述要求 FDE 收集一线反馈，并回传给团队，用来影响 Weave 的产品路线图。客户团队每次在某个界面卡住，或者不得不反复编写同一个评分器，都要当天记下来，因为这是给产品团队的数据。

把这项能力变成求职优势

inferencejobs.com 上的招聘信息要求掌握 Python、主流 ML/AI 框架，以及至少五年软件工程或一线编码经验。这些是门槛。但由于工作坊和赋能培训写进了岗位描述，能证明你可以教别人构建和度量 Agent，才是你最该突出展示的。

所以，在作品集里加一个参考 Agent 仓库，三样东西都要有：带标准的任务集、至少一个自定义评分器，以及一张包含退步任务的 v1 与 v2 对比表。

再附上一份你实际讲过的工作坊议程，哪怕只是讲给同事听。简历上要写结果，例如“赋能培训后，X 团队能自己跑评测”，而不是“熟悉 LLM”。

准备面试时，不要只准备讲 Agent 架构，还要准备一个赋能的故事。最有说服力的，是另一个团队在你没有提示的情况下，自己发现了一个退步任务。