DeepSeek 最近招聘「Agent Harness 研究员」，这个岗位释放了一个很重要的信号：

Agent 的竞争，正在从“模型能力”，进入“Harness 能力”。

DeepSeek 在 JD 里给出了一个公式：

Model + Harness = Agent

模型负责思考，Harness 负责让思考落地。

上下文管理、长期记忆、工具调用、文件读写、终端执行、Subagent、多 Agent、自进化、评测、真实任务反馈，所有模型之外、但决定 Agent 是否真正可用的系统层，都属于 Harness。

这意味着，Harness 不再只是工程师搭的一层脚手架，而正在成为一个独立的研究方向。

如果从这份 JD 反推，想成为 Harness 研究员，至少要补齐七类能力。

Model 加上 Harness 才能变成可执行、可验证、可复盘的 Agent。
模型提供推理能力，Harness 把推理接入工具、上下文、记忆、评测和真实任务反馈。

补充：三条招聘信息一起看

更值得注意的是，DeepSeek 这次不是只放出一个「Harness 研究员」岗位，而是同时出现了研究、产品、工程三条线。

这说明 Harness 不再只是模型团队旁边的工程支持，而是在被拆成一套完整能力：有人研究 Agent 机制，有人定义产品形态，有人把 Runtime、工具、评测和执行环境做成可用系统。

招聘方向释放的信号岗位链接
Agent Harness 研究员偏研究与评测：关注 Agent 机制、Harness 设计、数据标注、评测基准和模型-Harness 共进化。查看岗位
Agent Harness 产品经理偏产品化：把 Harness 能力转成可交付的 Agent 产品形态，定义场景、交互、权限、验收和工作闭环。查看岗位
Agent Harness 研发工程师偏工程落地：构建上下文、工具调用、执行环境、trace、eval、权限和多 Agent Runtime。查看岗位

这三条岗位放在一起看，信号会更清楚：

Agent 的下一层竞争，不是单点模型能力，而是研究、产品和工程共同组成的 Harness 系统能力。

一、理解 Agent 基本机制

Harness 研究员首先要理解 Agent 是怎么工作的。

不是只知道几个概念，而是要能画出一条完整链路：

用户输入目标
→ Agent 拆解任务
→ 调用工具
→ 读取文件
→ 执行命令
→ 观察结果
→ 修正计划
→ 输出结果
→ 记录 trace

你至少要理解：

  • LLM API
  • Tool Use
  • Agent Loop
  • Reasoning
  • Planning
  • Skills
  • MCP
  • Memory
  • Subagent
  • Multi-Agent

学习目标：自己写一个最小 Agent Runtime。

它不需要复杂，但至少要支持：工具调用、文件读写、命令执行、结果观察、trace 记录。

最小 Agent Runtime 从目标输入开始，经过计划、工具调用、观察、修正，最后输出结果并记录 trace。
最小 Runtime 不追求复杂，先把目标、工具、观察、修正和 trace 闭环跑通。

推荐资料：

二、掌握 Context Engineering 与 Memory

很多 Agent 失败，不是模型不聪明，而是上下文错了。

该看的没看到，不该看的塞太多，关键约束被淹没，历史信息污染当前判断，这些都会让 Agent 变笨。

Harness 研究员必须会设计上下文和记忆策略：

  • 哪些信息进入 system prompt
  • 哪些信息进入短期上下文
  • 哪些信息进入长期记忆
  • 哪些信息进入 skill
  • 哪些信息按需检索
  • 长任务如何压缩历史
  • 什么时候重置上下文
  • 失败经验如何转成下次执行约束

过去大家重视 Prompt Engineering，后来发现真正重要的是 Context Engineering。

Prompt 决定模型从哪里开始；Context 决定模型能走多远；Memory 决定 Agent 能不能长期积累经验。

学习目标：对同一个任务测试不同上下文与记忆策略，比较成功率、token 成本和失败模式。

Context Engineering 把 system prompt、短期上下文、长期记忆、Skill 和按需检索组织成可控上下文系统。
上下文不是越多越好，而是要把正确的信息放在正确的位置。

推荐资料：

三、掌握 Tool Use 与执行环境设计

一个真正可用的 Agent，不是只会聊天，而是能稳定执行。

它要能读文件、改代码、跑命令、看报错、修复问题、生成 artifact，并且在执行出错时能恢复。

所以 Harness 研究员要研究的不只是“给 Agent 接更多工具”，而是：

  • 模型如何选择工具
  • 工具描述如何影响行为
  • 工具结果如何进入上下文
  • 工具失败如何反馈给模型
  • 执行过程如何被记录为 trace
  • 哪些操作需要权限控制
  • 哪些错误应该触发恢复机制
  • 哪些执行行为应该进入评测数据

这里的关键不是“让 Agent 能做更多事”，而是“让 Agent 能稳定、可控、可复盘地做事”。

比如 coding agent，每次改完代码后，应该自动跑测试；测试失败后，错误应该重新反馈给 Agent；遇到高风险命令时，系统应该能拦截，而不是只靠 prompt 提醒。

学习目标：做一个安全 coding harness。

最低要求：

改代码
→ 自动跑测试
→ 测试失败后反馈给 Agent
→ 阻止危险命令
→ 生成 diff summary
→ 记录执行 trace

推荐资料：

四、学会 Subagent 与 Multi-Agent

DeepSeek JD 里明确提到 Subagent 与 Multi-Agent，这说明他们关心的不只是单 Agent，而是复杂任务协作。

但 Multi-Agent 不是角色越多越好。

它真正解决的是四个问题：

  • 上下文隔离
  • 专业分工
  • 并行执行
  • 独立验证

一个有效结构可能是：

Planner：拆解任务
Builder：实现功能
Tester：编写测试
Reviewer：审查风险
Evaluator：根据验收标准打分

这里最重要的不是“多智能体聊天”，而是让不同 Agent 承担不同责任，并且让执行过程可验证、可回滚、可复盘。

学习目标：做一个多 Agent 编程实验，观察多 Agent 在什么情况下提升质量，什么情况下制造噪声。

Planner、Builder、Tester、Reviewer、Evaluator 五类子 Agent 围绕同一目标分工协作。
Multi-Agent 的价值不是“角色更多”，而是上下文隔离、专业分工和独立验证。

推荐资料：

五、建立 Harness Eval 与数据标注能力

这是 DeepSeek JD 里最关键的一条。

JD 明确要求：提出 Harness 领域的基准测试与评测方法，构建评测基准数据和制定数据标注策略。

这说明 Harness 已经不是单纯工程问题，而是研究问题。

一个 Harness 不能只靠感觉判断好坏，而要能量化：

  • 任务成功率
  • token 成本
  • 执行时间
  • 工具调用次数
  • 工具失败恢复率
  • 上下文污染率
  • 安全违规率
  • regression 情况
  • trace 可复盘性

更重要的是，Harness Eval 不只是跑 benchmark，还包括设计任务分布、定义成功标准、标注失败原因、沉淀 failure taxonomy。

真正有价值的数据不是“任务成功 / 失败”，而是知道失败发生在哪一层：

Context
Memory
Planning
Tool Use
Execution
Subagent
Evaluation
User Feedback

没有 Eval，Harness 只是经验调参；有了 Eval，Harness 才能持续进化。

比如同一个模型，换不同 Harness 配置，可以比较：

无 memory
有 memory
有 hooks
有 evaluator
有 subagent
有 context compression

最后看哪一种配置在真实任务里成功率更高、成本更低、失败更少。

学习目标：自建一个小型 Harness Bench，用 30 个真实任务评估不同 Harness 策略，并标注失败原因。

Harness Eval 从成功率、成本、执行时间、工具恢复、上下文污染、安全违规和回归风险多个维度评测。
Harness Eval 的关键不是只判成功失败，而是定位失败发生在哪一层。

推荐资料：

六、研究 Self-Evolving Harness

DeepSeek JD 里还提到自进化 Agent。

这可能是 Harness 方向最前沿的部分。

核心问题是：

Agent 能不能从自己的失败 trace 里发现问题，并反过来修改自己的 Harness？

比如一次任务失败后，系统不只是重试，而是分析：

  • 是 prompt 不清楚？
  • 是工具描述错了？
  • 是上下文缺失？
  • 是 memory 污染？
  • 是缺少 evaluator？
  • 是 skill 过期？
  • 是执行环境限制不足？
  • 是 Subagent 协作失败？
  • 是任务成功标准不清？

然后生成一个 Harness Patch，再通过回归测试判断是否接受。

这个方向很关键，因为未来 Agent 的进化，不应该只依赖人工调 prompt，而应该来自真实任务中的失败反馈。

也就是：

真实任务
→ 执行 trace
→ 失败分析
→ Harness Patch
→ 回归测试
→ 接受或拒绝
→ 新版本 Harness

学习目标：做一个 Trace → Harness Patch 原型，把失败轨迹转成 skill、hook、rule、eval case 或 context policy。

Self-Evolving Harness 从真实任务 trace 中分析失败，生成 Harness Patch，经回归测试后进入新版本。
自进化 Harness 的关键，是把失败 trace 变成可验证的系统更新，而不是只做一次重试。

推荐资料：

七、理解 Model-Harness Co-Evolution

DeepSeek JD 里最值得注意的一句话，是：

实现模型与 Harness 的共同进化。

这说明 Harness 不是模型外面的一层壳，而是模型能力进入真实世界后的反馈系统。

一个好的 Harness 会持续收集：

  • 真实任务 trace
  • 工具调用记录
  • 失败样本
  • 用户中断和接管
  • 上下文缺失案例
  • 任务成功与失败原因
  • 不同模型在同一任务下的表现差异

这些数据反过来可以变成 eval case、训练样本、工具协议修改、memory 策略调整、skill 更新和产品机制优化。

模型变强以后，Harness 也要随之变化。

新模型可能更擅长长程规划，也可能更依赖清晰工具边界；可能更会写代码，也可能更容易在长上下文里忽略约束。

所以 Harness 研究员要站在模型团队和产品团队之间，把真实任务中的失败，转化成模型和系统共同进化的信号。

学习目标：建立一套 Trace → Failure Taxonomy → Eval Case → Harness Patch → Model Feedback 的闭环。

推荐资料：

最后：Harness 研究员的能力地图

从 DeepSeek 这份 JD 反推，Harness 研究员要走的不是单一技术路线，而是一条复合路径：

第一层：会用 Agent
Claude Code / Codex / Cursor / Manus / 通用 Agent 高频使用

第二层：会拆 Agent
理解 Loop / Tool / Context / Memory / Skill / MCP

第三层：会造 Harness
文件系统 / 工具调用 / 执行环境 / Trace / Evaluator

第四层：会评测 Harness
Benchmark / Validator / Failure Taxonomy / 数据标注 / Regression

第五层：会进化 Harness
Trace Mining / Skill Evolution / Context Policy Update / Harness Patch

第六层：会连接真实任务
用户反馈 / 人工接管 / 失败复盘 / 场景优化

第七层：会和模型共同进化
把真实任务反馈转成训练信号、工具协议、能力假设和产品机制

过去大家以为 Agent 的核心是 prompt。

后来发现，核心是 context。

再往后看，真正决定 Agent 能不能进入生产环境的，是 Harness。

未来真正稀缺的人，不是只会写提示词的人，而是能设计、评测、治理、进化 Agent Harness 的人。

DeepSeek 这个岗位的意义在于，它把这个方向明牌写了出来。

Harness Engineering，正在从工程实践变成研究方向。

而这也意味着，一个新的学习路径和职业方向，正在出现。