最近刷几个模型厂牌的招聘信息(定期刷可以提前预知这些公司的动作)，发现 DeepSeek 和 Kimi 都上了 Harness 产品经理岗位。
是的，DeepSeek 要推出桌面 Agent 客户端了！
一个叫"Agent Harness 产品经理"，一个叫"Harness Product Engineer"。
这篇文章就从这两份 JD 出发，借着专业团队对 Harness 这个概念的定义，把里面提到的概念一个个拆开讲清楚。
回答本文标题的问题：天天嚷着要做 Agent Harness，到底要做什么？
先看 DeepSeek 的定义：Model + Harness = Agent
deepseek-jd
DeepSeek 在 JD 开头写了一句话，非常精确：
Model + Harness = Agent
我们正在把 DeepSeek 的前沿模型能力，转化为领先的 Agent 产品。
这其中除模型本身以外的所有工作，都属于 Harness 的范畴。
这句话值得反复读。
它说的是：模型本身（训练、推理、参数优化）不是 Harness。
模型之外的一切——怎么给模型喂信息、怎么管理工具、怎么设计交互、怎么处理错误、怎么让 Agent 在真实环境中跑起来——才是 Harness。
Agent Harness 架构层次
如果把 Agent 比作一辆自动驾驶汽车，模型是发动机，那 Harness 就是底盘、转向、刹车、传感器融合、路径规划、人机交互……发动机再强，没有这些东西，车也开不起来。
Kimi 的视角：Harness 决定 Agent 能走多远
kimi-jd
Kimi 的 JD 开头用了另一种表述：
当 Agent 开始在真实世界中长时间调用工具、穿梭于浏览器、终端、桌面和移动端环境，并持续完成复杂任务时，真正决定它能走多远的，往往不只是模型本身，而是harness 与 LLM 的共同优化结果。
Harness 决定状态如何被管理、上下文如何被交接、反馈如何被闭环，也决定 Agent 在长时间、高复杂度执行中能否保持稳定、清醒与可控。
这段话信息量很大。它点出了 Harness 需要解决的四个核心问题：
| 核心问题 | 通俗解释 |
|---|---|
| 状态管理 | Agent 执行到哪一步了？已经做了什么？还差什么？ |
| 上下文交接 | 每一步执行完，下一步需要知道什么信息？信息怎么传递？ |
| 反馈闭环 | 工具调用成功了还是失败了？错误信息够不够清晰？怎么从错误中恢复？ |
| 稳定、清醒与可控 | 跑了 50 步之后，Agent 还记不记得自己在干嘛？会不会跑偏？ |
这四个问题，就是 Harness 产品经理每天要面对的战场。
拆解 JD 中的关键概念
接下来我们把两份 JD 中反复出现的技术概念逐个拆开。每个概念我会回答三个问题：它是什么？它为什么重要？PM 需要做什么？
1. Agent Loop
是什么：Agent 的基本运行模式。
Agent 不是"问一句答一句"，而是一个持续运转的循环——接收任务 → 推理思考 → 调用工具 → 获取结果 → 更新状态 → 继续下一步，直到任务完成。
Agent Loop 循环示意
为什么重要：传统的 Chatbot 是"一问一答"，而 Agent 是"给它一个任务，它自己跑完"。
这个"自己跑"的过程就是 Agent Loop。Harness 的核心工作就是设计这个循环的每一步。
PM 要做什么：定义循环的边界——什么时候该停下来问人？什么时候该自主决策？循环最多跑多少步？每一步之间的信息怎么传递？
2. Context Engineering（上下文工程）
是什么：管理 Agent 每次调用模型时"喂进去"的信息。
LLM 有一个上下文窗口（Context Window），就像一个工作台，空间有限。Context Engineering 就是决定工作台上放什么、不放什么、什么该压缩、什么必须保留。
这个概念是 Prompt Engineering 的进化版：
- •Prompt Engineering：怎么写好一句提示词
- •Context Engineering：怎么管理 Agent 运行过程中所有的上下文信息
- •Harness Engineering：怎么设计整套系统让 Agent 稳定运行（Context Engineering 是其中的一部分）
Context Engineering 概念
为什么重要：上下文窗口是有限的。
一个长任务可能跑几百步，但上下文窗口装不下所有历史。哪些信息该保留？哪些该压缩（compaction）？压缩后会不会丢失关键信息？这些直接决定 Agent 的表现。
Kimi 的 JD 里有一句话特别精准： “你关心 Agent 在每一个 step 中获得的 context，在意 error message 是否给了 Agent 足够直接的引导，希望优化每一次 compaction 后留下的关键信息。”
PM 要做什么：设计信息优先级策略——系统提示词占多少空间？工具定义占多少？对话历史保留多少轮？文件内容怎么截断？错误信息怎么精简但不失关键信息？
3. Tool Use 与 MCP（工具调用）
是什么：Agent 不只是"说话"，它要"做事"。
Tool Use 就是让 Agent 调用外部工具的能力——读写文件、执行代码、搜索网页、操作数据库、调用 API 等。
MCP 是 Tool Use 的子集，是 Anthropic 提出的一个开放协议，标准化了 Agent 与工具之间的通信方式。也就是按照统一的规范写 Tool Use 的代码。
为什么重要：工具是 Agent 的"手脚"。
没有工具，Agent 只是一个聊天机器人。工具的质量直接影响 Agent 能完成什么任务。DeepSeek 的 JD 明确要求 PM 熟悉 MCP 协议。
PM 要做什么：决定 Agent 需要哪些工具、工具的优先级、工具调用的权限控制（哪些操作需要用户确认）、工具失败时的降级策略。
4. State Management（状态管理）
是什么：跟踪 Agent 在执行任务过程中的"当前状态"。
包括：任务进度、已完成的步骤、待处理的事项、中间结果、错误记录等。
为什么重要：长任务执行中，Agent 需要知道"我做到哪了"。
如果状态管理混乱，Agent 可能重复做同一件事，或者遗漏关键步骤。Kimi 的 JD 把状态管理列为 Harness 的核心职责之一。
PM 要做什么：设计状态的可视化方案（让用户能看到 Agent 的执行进度）、状态持久化策略（Agent 中断后能否恢复）、状态异常的检测和处理机制。
5. Sandbox（沙箱）与环境设计
是什么：Agent 执行代码和操作的隔离环境。
沙箱确保 Agent 的操作不会影响真实系统——比如 Agent 写了一段有 bug 的代码，沙箱可以防止它删掉你的系统文件。
为什么重要：Agent 需要在浏览器、终端、桌面、移动端等多种环境中工作。
每种环境都有不同的能力和限制。
Kimi 的 JD 明确提到了"面向长时复杂任务的 long-running agent harness，让 Agent 能在浏览器、终端、桌面、移动端等环境中持续推进工作"。
PM 要做什么：定义 Agent 的环境边界（能访问什么、不能访问什么）、权限模型（哪些操作需要授权）、环境异常的处理策略。
6. KV Cache
是什么：LLM 推理时的性能优化技术。
模型在处理 token 时会生成中间计算结果（Key-Value 对），缓存这些结果可以避免重复计算，大幅提升推理速度。
大模型定价策略了，“缓存命中”和“缓存未命中”的价值，相差几十倍。
为什么重要：Agent 需要频繁调用模型（每一步都可能调一次），如果每次都从头计算，速度和成本都不可接受。
KV Cache 直接影响 Agent 的响应速度和运行成本。
DeepSeek 的 JD 明确要求 PM 理解 KV Cache。
PM 要做什么：不需要自己实现 KV Cache，但需要理解它的原理和限制（比如缓存命中率、上下文长度对缓存效率的影响），以便在产品设计中做出合理权衡。
7. Reasoning 与 Planning（推理与规划）
是什么：Agent 的"思考能力"。Reasoning 是对当前情况的分析和推理，Planning 是对任务的整体规划和步骤拆解。
为什么重要：简单任务可以一步一步做，但复杂任务需要先规划再执行。
Planning 能力决定了 Agent 能处理多复杂的任务。
DeepSeek 的 JD 提到了 Reasoning 和 Planning，Kimi 的 JD 则强调了"从 agent trace、失败案例和长任务运行日志中反推出系统真正的结构性问题"
—— 这意味着 PM 需要理解 Agent 的推理过程，才能判断问题出在哪里。
PM 要做什么：设计 Planning 的展示方式（用户能否看到 Agent 的计划？能否修改计划？）、规划失败时的降级策略。
8. Memory（记忆）
是什么：Agent 跨会话、跨任务的信息持久化能力。
包括短期记忆（当前任务内的信息）和长期记忆（跨任务积累的知识和偏好）。
为什么重要：没有 Memory 的 Agent 每次对话都是从零开始。
有了 Memory，Agent 可以记住用户的偏好、历史决策、常用工具和工作模式，越用越好用。
PM 要做什么：设计记忆的存储、检索和遗忘策略——什么信息值得记住？记忆怎么检索？用户能不能查看和编辑 Agent 的记忆？隐私怎么保障？
9. Subagent 与 Multi-Agent（子智能体与多智能体）
是什么：一个 Agent 可以拆分出多个子 Agent 来并行处理不同任务，或者多个 Agent 之间协作完成复杂任务。
为什么重要：复杂任务往往包含多个独立子任务。
与其让一个 Agent 串行处理所有事情，不如让多个 Agent 各司其职、并行推进。
DeepSeek 的 JD 提到了 Subagent 和 Multi-Agent，OpenClaw、Hermes 等主流 Agent 产品都有非常棒的自动激活子 Agent 加速任务的设计。
PM 要做什么：设计任务拆分和分配策略、子 Agent 之间的通信机制、结果汇总和冲突解决方案。
汇总：两份 JD 的关键词全景
把两份 JD 中出现的所有技术关键词整理成一张表：
| 类别 | 关键词 | 来源 |
|---|---|---|
| 核心框架 | Agent Loop, Harness Engineering | DeepSeek + Kimi |
| 上下文管理 | Context Engineering, Prompt Engineering, Context Window, Compaction | DeepSeek + Kimi |
| 工具生态 | Tool Use, MCP | DeepSeek |
| 状态与反馈 | State Management, Feedback Loop, Error Handling | Kimi |
| 推理能力 | Reasoning, Planning | DeepSeek + Kimi |
| 记忆系统 | Memory | DeepSeek |
| 多智能体 | Subagent, Multi-Agent | DeepSeek |
| 运行环境 | Sandbox, Environment Design | Kimi |
| 底层技术 | LLM API, KV Cache | DeepSeek |
| 工程实践 | Agent Trace, Long-running Execution, Fault Tolerance, Retry Logic | Kimi |
| 设计方法论 | Load-bearing Design, Minimal Effective Structure | Kimi |
两份 JD 的异同：两个视角看同一件事
DeepSeek 和 Kimi 对 Harness 产品经理的理解高度一致，但侧重点不同：
| 维度 | DeepSeek | Kimi |
|---|---|---|
| 岗位名称 | Agent Harness 产品经理 | Harness Product Engineer |
| 核心定位 | 产品规划 + 用户研究 + 团队协调 | 系统设计 + 技术架构 + 亲手打造 |
| 对 Harness 的定义 | 除模型以外的所有工作 | 状态管理 + 上下文交接 + 反馈闭环 |
| 用户研究要求 | 强调：设计系统性数据收集方法（问卷、访谈、A/B 测试） | 强调：从 agent trace 和失败案例中反推结构性问题 |
| 技术深度要求 | 理解原理，能 vibe coding 即可 | 需要能判断问题出在模型/prompt/工具/环境/orchestration 哪一层 |
| 对 Agent 产品的态度 | 强调热情和品味，列举了大量需深度使用的产品 | 强调不满足于现有体验，是"重度榨取者" |
| 产出预期 | 产品路线图 + 指标体系 + 用户社群 | 核心 harness + 交互范式 + 系统支撑结构 |
简单说：DeepSeek 招的是"懂技术的产品经理"，Kimi 招的是"懂产品的工程师"。
PM 到底要会什么？从 JD 提炼的能力模型
综合两份 JD，Agent Harness 产品经理需要具备以下能力：
必备能力
1. Agent 产品的深度使用经验
这是两份 JD 共同的硬性要求。
DeepSeek 列了一串产品清单：Claude Code、Codex、Cursor、OpenCode、GitHub Copilot、Manus、OpenClaw、Hermes 等。
不是"用过"就行，是要深度使用、融入工作和生活。
为什么这么重要？
因为 Harness 的设计决策极其依赖直觉——“这个 error message 够不够清晰？”“compaction 之后信息丢没丢？”“这个工具调用的反馈够不够及时？”
——这些判断只能来自大量真实使用经验。
2. 理解 LLM 和 Agent 的技术原理
不需要会写模型训练代码，但需要理解：
- • LLM API 的输入输出机制
- • Agent Loop 的运行逻辑
- • 工具调用的协议和流程
- • 上下文窗口的限制和管理策略
- • KV Cache 对性能的影响
DeepSeek 明确说"能够使用 vibe coding 写代码，不一定需要技术背景"。
这说明岗位不要求你是工程师出身，但要求你能用 AI 辅助写代码，有动手验证想法的能力。
3. 系统性的用户研究能力
DeepSeek 要求"设计系统性的收集数据的方法（包括问卷、访谈、A/B 测试、灰度测试等），并使用统计学的工具严谨科学的分析数据"。
Kimi 则要求"从 agent trace、失败案例和长任务运行日志中反推出系统真正的结构性问题"。
两个视角合在一起：你需要既能从用户侧获取反馈（问卷、访谈），也能从系统侧提取信号（日志、trace、失败案例），然后用科学的方法分析这些数据。
假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。
接下来告诉你一条最快的邪修路线，
3个月即可成为模型大师，薪资直接起飞。
阶段1:大模型基础
阶段2:RAG应用开发工程
阶段3:大模型Agent应用架构
阶段4:大模型微调与私有化部署
配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇
