Evals、Harness、Forward-Deployed：AI 招聘里，正在长出一些以前没有的工作

Evals、Harness、Forward-Deployed：AI 招聘里，正在长出一些以前没有的工作

这是「现在公司到底在招什么样的 AI PM」系列第三篇。

前两篇先做了两件事：

第一篇把 AI PM 拆成了几种完全不同的工作；

第二篇再看，不同岗位所谓的“技术要求”，到底差在哪里。

整理到这里以后，我发现另一个挺有意思的变化：

AI 产品团队本身，也正在重新分工。

截至 2026 年 8 月 20 日，我整理的 43 个公开 AI 产品岗位里，除了比较熟悉的 AI Product Manager，还反复出现了一些几年前很少见的名字：

AI Evaluations、Agent & Harness、Model Behaviors、Human Data Platform、Safeguards、Forward-Deployed……

一开始看到这些词，很容易觉得：

AI 行业是不是又在发明新名词？

但把 JD 逐条看下来以后，我反而觉得它们出现得很自然。

一个行业开始成熟时，经常会发生一件事：

原来由某个人“顺便负责”的问题，慢慢复杂到需要一个明确的 Owner。

AI 现在正在经历这个过程。

1. Evals：有人开始专门负责“什么叫好”

Evals 很容易被理解成：

AI 版 QA。

但它和传统测试其实有一个很根本的区别。

普通软件里，我们经常可以提前写清楚：

输入是什么，正确输出应该是什么。

AI 不一定。

同一个问题可以有很多合理答案；一个版本整体变好了，也可能在某些关键场景退化；平均分很高，也可能偶尔犯一个完全不能接受的错误。

所以 Eval 首先要回答的甚至不是：

测试有没有通过？

而是：

到底什么算好？

接下来才是：

测试什么；Test Set 从哪里来；Rubric 怎么定义；哪些能用规则判断；哪些可以 LLM-as-a-Judge；哪些必须人工 Review；模型换版本以后如何做 Regression；线上出现的新 Failure 怎么重新进入测试集。

Box 现在就有一个直接叫 Product Manager, AI Evaluations 的岗位。

PM 会负责 Dataset、Graders、Offline / Online Evaluation、Model Selection 等工作。

这时候 Eval 已经不只是“产品做好以后测一下”。

它开始影响：

模型怎么选、产品怎么迭代、什么时候可以上线。

所以我现在更倾向于把 Evals 理解成：

AI 产品里的质量基础设施。

即使未来并不是每家公司都有一个专门的 Eval PM，这套能力也很可能会进入越来越多普通 AI PM 的工作里。

2. Harness：模型之外，还有一整层东西决定 Agent 好不好用

Harness 是我最近才越来越认真理解的一个概念。

不同公司对它的边界并不完全一样，所以我不太想给它一个特别死的定义。

如果一定要用一句比较直白的话来说：

模型负责“想”，Harness 负责让它在一个真实系统里“做事”。

一个 Agent 真正运行起来，往往还需要：

Context；Memory；Tools；Permissions；Sandbox；Orchestration；Retry；Fallback；Observability；Evaluation。

以前这些事情很容易被看成 Engineering Detail。

但当 Agent 不再只是回答一句话，而是开始：

调工具、查数据库、改文件、提交请求、执行真实动作，

以后，它们就直接变成产品问题了。

例如：

这个 Agent 到底可以看到什么？

哪些工具能调用？

什么操作必须要求确认？

如果执行到一半失败，是重试、回滚，还是交给人？

它为什么做出这个决定，有没有 Trace 可以看？

Binance 已经直接出现了：

Product Manager, AI Agent & Harness

JD 里会明确涉及 Task Flow、Capability Boundary、Failure Fallback、Harness Evaluation、Task Set 等。

我觉得这个职位名称本身挺有意思。

它说明有些公司已经不再把 Agent 周围这一层当成：

“模型接上几个 API 就好了。”

而是开始把它当成一个需要长期设计和经营的产品系统。

3. Model Behaviors：连“模型应该怎么表现”也开始有 Product Owner

Anthropic 目前还有一个让我觉得很新鲜的岗位：

Research Product Manager, Model Behaviors

模型能力过去很容易被想成：

数学 Benchmark 多高；Coding 能力多强；知识覆盖多广。

但真实使用里，还有一批更难用单一 Benchmark 表达的问题：

不知道的时候，要不要承认不知道？

面对模糊要求，是直接猜，还是先澄清？

什么时候应该拒绝？

怎样表达不确定性？

会不会为了让用户开心而过度迎合？

面对冲突指令怎么办？

这些其实都会强烈影响产品体验。

也就是说，AI 时代 PM 负责的“产品对象”正在往前延伸。

以前我们主要设计：

页面、流程、功能。

现在甚至开始有人专门负责：

模型应该怎样表现。

而且这件事需要研究、数据、Eval 和产品判断一起完成。

4. Human Data Platform：人类反馈也开始变成一个产品系统

AI 背后其实一直有很多“人”。

有人需要判断：

两个答案哪个更好；

这个结果有没有风险；

Agent 到底算不算完成任务；

哪一种错误更严重。

数量少的时候，可以手工解决。

规模变大以后，很快就会出现一整套问题：

任务怎么设计？谁适合来判断？不同人的标准一致吗？怎么质检？成本怎么控制？哪些反馈进入 Training？哪些进入 Eval？

Anthropic 现在就有 Human Data Platform 相关的 Product Management 岗位。

我觉得这个变化也很能说明问题：

人类反馈不再只是一个后台 Operations 环节。

它本身也需要：

平台、流程、质量标准、工具和产品设计。

换句话说：

“Human in the Loop”里的 Human，也开始被系统化。

5. Safeguards / Safety Measurement：安全从原则变成指标和系统

过去讲 AI Safety，很容易停留在：

AI 应该安全。

当然没错。

但真正做产品时，这句话远远不够。

还需要继续问：

具体有什么 Harm？

怎么检测？

Safeguard 有没有真的减少风险？

False Positive 多高？

哪些风险可以接受？

哪些风险必须阻断？

出了一次事故，怎么进入下一轮产品迭代？

OpenAI 现在有 Safety Measurement PM。

Anthropic 的招聘里则已经进一步拆出：

Rare Harms、Child Safety、Vertical Safeguards 等不同方向。

安全到了这里，已经不只是 Policy。

而是：

Metric + System + Operations + Product Decision。

我觉得这也是 AI 产品和普通软件差异很明显的一块。

很多“价值判断”，最后都需要被翻译成：

系统到底怎么工作。

6. Forward-Deployed PM：有人专门负责把 Demo 送进真实世界

Forward-Deployed 是这轮 research 里我之前关注得比较少，但后来越来越觉得重要的一类。

Scale AI 现在就在招 Forward Deployed Product Manager。

这类 PM 不只是：

收需求 → 写 PRD → 回总部排 Roadmap。

而是会深入客户现场：

理解业务问题；接数据和 API；一起构建 Prototype；测试；部署；再把一次性的客户方案慢慢抽象成可以复用的标准产品。

所以它有点像：

PM + Solutions Architect + Consultant + Builder。

为什么 AI 公司现在越来越需要这种人？

可能因为今天做一个 Demo 已经没有那么难。

真正困难的是：

客户的数据很乱；权限系统很复杂；流程里有大量例外；组织里没有人愿意改变工作方式；模型效果到了真实场景就开始下降。

很多 AI 项目最后卡住的地方已经不是：

模型还不够聪明。

而是：

它没有真正进入工作流。

Forward-Deployed 其实是在专门解决这个“最后一公里”。

7. AI Transformation：还有人开始负责一家公司的 AI Product Portfolio

另外一种新分工，更多发生在传统企业内部。

想象一家公司突然出现：

几十个 AI Idea；很多部门各自做 Pilot；一堆 Vendor 来 Demo；每个人都说自己这个场景特别适合 AI。

很快就需要有人回答：

到底先做什么？

哪些值得 Build？

哪些直接 Buy？

什么能力应该统一做成 Platform？

哪些数据可以用？

怎么治理权限？

怎么算 ROI？

怎么让员工真的采用，而不是 Demo 完就结束？

所以现在也越来越常见：

AI Transformation PM、AI Product Owner、Internal AI Product。

它们不一定负责一个单一 AI Feature。

更像是在经营：

一家公司应该怎样使用 AI。

我觉得它和 Forward-Deployed 很像的一点是：

AI 进入这个阶段以后，模型本身只是问题的一部分。

组织、流程和落地，开始占据越来越大的比重。

把这些新职位放在一起，其实有一条很清楚的逻辑

我后来试着不看职位名称，只看它们为什么存在：

模型会变化→ 所以需要 Evals

Agent 会行动→ 所以需要 Harness / Permissions

模型行为本身影响体验→ 所以出现 Model Behaviors

AI 依赖大量人类判断→ 所以出现 Human Data Platform

AI 会产生新的风险→ 所以需要 Safeguards / Safety Measurement

企业部署很难→ 所以出现 Forward-Deployed

公司同时冒出大量 AI 项目→ 所以需要 AI Transformation

这样看以后，这些名字就没那么像“AI 黑话”了。

它们只是在回答同一个问题：

一个新的复杂问题出现以后，到底应该由谁长期负责？

这对找工作也有一个很实际的影响

如果只搜索：

AI Product Manager

其实很容易漏掉一些和自己很匹配的机会。

现在还可以一起看：

AI EvaluationsAgent PlatformAgent HarnessModel PerformanceResearch Product ManagerModel BehaviorsSafeguardsForward-Deployed Product ManagerAI ApplicationsAI Transformation

当然，这些 Title 现在还没有完全稳定。

有些名字可能几年以后还在，有些可能会消失。

所以比起记住每一个词，我觉得更有用的是：

先看它在解决什么问题。

因为 Title 会变。

问题通常不会那么快消失。

前三篇写到这里，这组 research 的市场地图基本铺完了：

第一篇是 AI PM 到底分成哪些工作；

第二篇是 不同岗位需要多深的技术；

这一篇则是 AI 产品组织正在长出哪些新的专业分工。

最后一篇，我想把视角从“公司在招什么”重新拉回到个人：

如果过去不是 AI PM，面对这么多岗位和技能，到底应该怎么找到自己的位置？

我觉得答案可能不是：

再给自己加一张更长的学习清单。

「现在公司到底在招什么样的 AI PM」系列 3/4。研究基于截至 2026 年 8 月 20 日整理的 43 个公开 AI 产品岗位；本文主要参考 Anthropic、OpenAI、Box、Binance、Scale AI 等公司的当前招聘信息。文中职位名称代表的是正在出现的分工趋势，并不意味着这些 Title 已经形成统一的行业标准。