LangGraph 跟你讲 Checkpoint，A2A 讲 Task，AG-UI 讲 Event，Deep Agents 又带来了 Todo、Subagent 和虚拟文件系统。OpenAI 旧 Assistants API 里的核心概念还是 Thread 和 Run，到了 Responses API 与 Agents SDK，又换成了 Response、Conversation、Session 和 RunState。

每换一个框架，就是一套新名词、一种新的 API 形状，像是每家都在卖自己的世界观。

我最烦的就是这个。不是学不动，而是不想每换一个工具，就重新背一遍对象体系。学了几套之后，我停下来想了个问题：这些名字底下，有没有一层东西是不太变的？

一个 Agent 任务，怎么被启动，怎么带着上下文往下跑，怎么被观测，断了怎么接上，最后怎么产出结果。

答案是有，但它不是一套已经定稿的行业标准，而是一组反复出现的问题。把各家的名词往下拆两层，你会发现它们都在回答同一件事。

这篇文章提出六类对象，把它们当作观察 Agent 系统的镜头。它们不一定以相同名字出现在每个协议或框架里，有些甚至只存在于运行时内部。但掌握这组概念之后，再看一个新框架，你就能更快判断它究竟解决了什么问题，又把哪些难题留给了你。

先把三层东西分开，别搅在一起

聊这个话题最容易犯的错，是把三层不同的东西摆在一起比较。

第一层是具体的通信协议，比如 A2A、AG-UI，以及仍处于草案阶段的 AITP。它们分别处理 Agent 与 Agent、Agent 与前端、跨信任边界的 Agent 之间怎么交换信息。

第二层是跨系统反复出现的概念对象，比如 Thread、Run、Step、Event。这一层不是某个组织发布的统一规范，而是本文要提炼的共同语言。

第三层是运行时能力，比如状态怎么保存，任务怎么调度，中断后怎么恢复，工具副作用怎么控制。

这三层相关，但不能画等号。协议定义系统对外如何交互，运行时决定一次执行在内部如何发生；一个运行时可以支持多种协议，一个协议也可以由完全不同的运行时实现。

这也是为什么不能简单地说“某个 API 算运行时，另一个不算”。以 OpenAI 为例，Responses API 已经提供托管工具、后台执行和请求内的多轮模型—工具交互，更像托管的 Agent 执行原语；Agents SDK 则把可定制的运行循环、工具执行、交接、状态和追踪显式交给开发者。两者不是非黑即白的分类，而是处在不同的抽象层级。

判断一个系统提供了多少运行时能力，关键不是它能不能调用模型，而是它替你接管了多少执行语义：循环由谁推进，状态由谁保存，失败由谁重试，权限由谁判断，副作用由谁兜底。

先记住这六类对象

下面六类对象，是我理解 Agent 系统时最常用的一组镜头：

• Thread／Session：一段持续上下文，回答这是哪一段交互、哪些历史属于它。

• Run／Task：一次具体执行，回答这次执行的目标和状态是什么。

• Step：一个可观测的步骤，回答哪一步调用了模型、工具或子任务。

• Event：执行中的状态变化，回答现在发生了什么、客户端如何得知。

• Artifact：可保存、可追溯的产出，回答结果在哪里、由哪次执行产生。

• Checkpoint：某个持久化边界上的运行状态，回答中断后可以从哪里恢复。

这六类对象不是所有协议都必须具备的“六件套”。A2A 明确定义了 Task、Message、Artifact 和状态更新事件，却没有规定通用的 Step 或 Checkpoint；AG-UI 明确暴露 Thread、Run、Step 和各种事件；Checkpoint 则更多是 LangGraph 这类运行时内部的一等能力。

真正值得学习的不是名字，而是边界。一个能用于生产的 Agent 系统，除了表达这些对象，还得明确一组跨对象的语义：流式输出、中断、恢复、取消、重试、并发、幂等、权限和审计。

对象告诉你“系统里有什么”，这些语义才告诉你“系统遇到真实世界时会怎么做”。

玩具和生产之间，卡着一条叫状态的线

六类对象里，最能区分“能演示”和“能长期运行”的，是 Checkpoint 所代表的持久化能力。

Checkpoint 通常不是整个现实世界的完整快照。它保存的是某个持久化边界上的运行状态，例如消息、图状态、节点输出和执行位置。已经发出的邮件、写入的数据库记录、消耗掉的额度，并不会因为恢复 Checkpoint 就自动回滚。

Checkpoint 保存状态，不会替你回滚现实

所以，真正困难的从来不只是“存”，而是“恢复之后还能对得上”。状态结构、工具副作用、外部资源、权限上下文和代码版本，都可能在中断期间发生变化。只把对话历史写进数据库，离可靠的状态恢复还差得很远。

这也是为什么别把所有状态都叫作“记忆”。更清楚的拆法至少有五层：

1. 对话消息；

2. 当前运行的变量和中间结果；

3. 用于恢复的持久化状态；

4. 文件、报告等外部产物；

5. 跨会话保留的长期记忆。

它们的生命周期、访问权限和一致性要求完全不同。设计系统时，得先问清楚：我要保存的到底是哪一层？

Thread 是上下文边界，Run 才是执行边界。同一个 Thread 上是否允许多个 Run 同时执行，不能靠默认想象。系统可以选择排队、拒绝新 Run、取消旧 Run，也可以分叉出多条执行路径做比较。这个选择直接决定了状态冲突如何处理，必须被明确设计。

错误有时是数据，有时必须是故障

在传统程序里，工具调用失败通常会抛异常，由开发者通过 try/catch 处理。在 Agent 系统里，另一种很有价值的做法是：把模型能够理解并修正的错误，作为工具结果返回给模型，让它调整下一步。

比如参数格式不对、搜索没有结果、商品库存不足、业务条件不满足，这些错误包含了模型可以采取行动的信息。把它们变成结构化结果，往往比直接终止整次 Run 更有用。

但 Error-as-Data 不是所有错误的默认归宿。429 限流、鉴权失败、网络超时、存储损坏、权限系统异常，通常应该先由运行时按照确定性的策略处理：遵守 Retry-After、指数退避、熔断、刷新凭证，或者向上抛出故障。必要时，运行时可以再把经过筛选的错误信息交给模型，但不该让模型承担基础设施的可靠性策略。

模型负责根据语义调整计划，运行时负责根据策略处理故障。

模型调整计划，运行时处理故障

Checkpoint 也不等于自动回滚。一个十步任务在第八步失败，持久化机制可以避免重复计算已经固化的部分，但失败节点可能会从头重新执行，节点中的外部副作用也可能再次发生。LangGraph 会在特定执行边界保存状态，并保留部分已经成功的写入；其他系统也可以通过可序列化的 RunState，或 Temporal、Dapr、Restate、DBOS 这类耐久工作流引擎实现暂停和恢复。

因此，判断恢复能力时，不能只问“有没有 Checkpoint”，还得继续问：保存边界在哪里，恢复时哪些代码会重放，副作用是否幂等，外部调用有没有去重键。

中断不是异常，而是一种执行状态

做过人机协作的都知道，最常见的需求是：Agent 干到一半停下来，等人确认要不要发这封邮件、要不要提交这个订单。

很多人的第一反应是加一个“询问用户”的接口。但真正的基础设施不是一个接口，而是把中断当成执行状态的一部分。需要输入、等待授权、被拒绝、等待外部条件，这些都应该进入状态机，而不是被当成意外异常处理掉。

要让 Agent 几小时甚至几天后继续执行，运行时必须保存足够的状态，但实现方式不一定非得叫 Checkpoint。它可以是图快照、事件日志、可序列化的 RunState，也可以由耐久工作流引擎托管。

关键不是对象叫什么，而是进程退出后能不能继续，恢复后会不会重复执行危险操作，审批决定能不能被审计。

工具这一层，可能最先形成共同语言

在各种 Agent 能力里，工具层最有可能率先形成共同语言。

原因不复杂：工具边界相对清晰，输入输出通常可以结构化，也比较容易与主循环解耦。以 JSON Schema 描述工具参数，已经成了常见做法，但各家格式仍有差异，还不能说已经存在一套完全统一的工具定义。

MCP 又向前走了一步。它不只定义工具发现和调用，也覆盖资源、提示模板、生命周期和能力协商。一个 MCP 服务可以被多个兼容的客户端或运行时接入，减少重复适配；但前提是双方支持相应能力，并把传输、认证和权限配置好。

工具一旦能产生真实副作用——改文件、发请求、下订单——运行时就必须长出一个控制面：身份与权限、安全检查、人工审批、预算上限、取消机制、审计记录，以及防止重复执行的幂等策略。

工具越能动手，控制面越重要

到这一步，Agent 运行时就不只是一个执行器，也是一道安全边界。

什么正在收敛，什么还没有

把这些放到两三年的尺度上看，确实能看到一些共同方向，但“收敛”不等于“已经统一”。

正在形成共同语言的，包括任务与运行对象、持续上下文、事件流、产物、结构化工具描述，以及中断、取消、恢复等生命周期状态。不同系统的粒度和语义还不完全相同，但开发者已经可以用相近的问题去比较它们。

短期很难统一的，包括主循环采用图式、代码式还是托管式，Checkpoint 保存到什么粒度，并发执行如何解决状态冲突，工具副作用如何保证一致性，以及多个 Agent 如何协作。可观测性也在出现共同规范，但 Agent 的 Step、Trace、评价数据之间仍没有完全稳定的统一语义。

多 Agent 协作尤其不适合现在就重仓押注。对大多数业务来说，先把单个 Agent 的执行边界、状态恢复、工具安全和质量评估做扎实，再按需要引入协作，通常比一上来就设计复杂的多 Agent 拓扑更稳。

最后

所以，“到底该用哪个框架”不是一个错误的问题，但它通常问得太早了。

框架还会一茬接一茬地出现。今天是 LangGraph、OpenAI Agents SDK、AutoGen、Deep Agents，明天还会有新的图式运行时、新的编排方式和新的托管平台。它们会带来新的对象名、新的 API 和新的最佳实践。

但生产级 Agent 绕不过去的问题一直很稳定：

• 一次执行怎么创建、取消、重试和结束；

• 哪些历史、文件和状态对当前步骤可见；

• 同一段上下文能不能并发执行；

• 崩溃、断网或升级之后能不能安全恢复；

• 外部系统如何获取进展，事件能不能补发和重放；

• 产物如何保存、追溯和关联到具体执行；

• 工具副作用如何去重，权限和审批如何审计。

六类对象提供了一张地图，上面这些运行语义则是检查清单。只盯着框架 API，很容易被短期流行牵着走；先建立这套概念模型，你才能反过来审视一个新框架：它明确表达了哪些对象，隐藏了哪些语义，又把哪些风险留给了使用者。

对我来说，这件事的价值，是把能力从“我很熟某个框架”，抬到“我能判断一个 Agent 系统的边界”。

框架当然值得学，但别只学框架。抽象会过期，问题不会。

本文由 Claude 辅助写作，并经事实核查与修订。

参考资料

A2A Protocol Specification：https://a2a-protocol.org/dev/specification/

AG-UI Events：https://docs.ag-ui.com/concepts/events

AITP：https://aitp.dev/

LangGraph Checkpointing：https://langchain-ai.github.io/langgraph/reference/checkpoints/

OpenAI Responses API：https://openai.com/index/new-tools-and-features-in-the-responses-api/

OpenAI Assistants API deep dive：https://platform.openai.com/docs/assistants/deep-dive

OpenAI Agents SDK：https://openai.github.io/openai-agents-python/running_agents/

Model Context Protocol：https://modelcontextprotocol.io/specification/2025-06-18/server/index

Deep Agents Overview：https://docs.langchain.com/oss/python/deepagents/overview

延伸阅读：《相比层出不穷的 Agent 框架，不变的 Agent Protocol 是什么》

https://mp.weixin.qq.com/s/0N-RnpGVy_PLSDHMwAIFNg

最近，DeepSeek 的一则招聘信息引起了很多 AI 产品经理的注意。

岗位名称不是我们熟悉的“AI 产品经理”，而是一个更具体、也更陌生的角色：Agent Harness 产品经理。

JD 开头只有一句公式：

Model + Harness = Agent

它把 Agent 这件事说得很直白：模型只是发动机。模型之外，负责理解任务、组织上下文、调用工具、保存状态、处理权限、恢复失败并把结果交给用户的整套系统，才是 Harness。

换句话说，用户最终感受到的 Agent，既取决于模型有多聪明，也取决于 Harness 能不能把这种聪明稳定地转化为结果。

这也意味着，一种新的产品岗位正在出现。

它不是“更懂一点 AI 的传统产品经理”，而是一个同时具备产品判断、技术理解、原型构建和实验评测能力的复合角色。

一、Harness 到底是什么？

Agent 经常给人一种错觉：只要换上更强的模型，产品能力就会自然变好。

但在真实任务里，模型需要面对的远不只是生成一段文字。它还要知道：

• 当前目标是什么；

• 需要读取哪些上下文；

• 应该调用哪个工具；

• 工具参数是否正确；

• 执行失败后要不要重试；

• 哪些操作必须经过用户确认；

• 如何验证结果是否真的完成；

• 长任务中如何保存状态并继续推进。

这些都属于 Harness 的工作。

Anthropic 将 Agent Harness 定义为让模型能够作为 Agent 行动的系统：它处理输入、编排工具调用并返回结果。更重要的是，当我们评测一个 Agent 时，真正评测的是模型与 Harness 的组合，而不是单独评测模型。

OpenAI 在拆解 Codex Agent Loop 时也强调，Harness 的核心作用，是编排用户、模型与工具之间的交互，让模型能够完成真正的软件任务。

所以，一个 Agent 表现不好，不一定是模型不够强。问题也可能出在上下文、工具描述、任务规划、权限、运行环境、验证机制或者交互设计。

而能够判断问题到底出在哪一层，正是 Harness 产品经理最重要的基本功。

二、DeepSeek 到底在招什么样的人？

从公开 JD 看，这个岗位不是以“写 PRD、排需求、跟项目”为主。更准确地说，它接近四个角色的结合：

Agent 系统产品经理 + 原型工程师 + 评测负责人 + 用户研究员

具体来说，主要要完成五件事。

1. 定义产品方向，而不是被动接需求

Harness 产品经理需要规划产品路线图，连接模型研究员、工程师、开源社区和用户。

这里真正困难的不是维护需求池，而是持续判断：

• 什么问题应该交给模型解决；

• 什么问题应该由 Harness 补足；

• 什么能力已经可以产品化；

• 什么需求应该等待下一代模型；

• 哪些临时机制会在模型升级后成为负担。

这是一种动态的产品判断。因为模型能力在快速变化，今天必须由 Harness 兜底的问题，明天可能已经可以直接交给模型。

优秀的 Harness 产品经理不仅要会增加机制，也要敢于删除已经不再必要的机制。

2. 定义“Agent 是否真的有用”

DeepSeek 在 JD 里提出了一个很有意思的问题：

Agent 是否真的在更多场景下，更深入地帮助到更多的人？

这意味着，这个岗位不能只看 DAU、调用次数或者生成字数。

更关键的指标可能是：

• 任务成功率；

• 首次完成率；

• 人工介入率；

• 平均修正轮数；

• 失败后的恢复率；

• 单次成功任务成本；

• 用户真正节省的时间；

• 用户是否愿意把更重要的任务交给 Agent。

产品经理需要把离线任务集、内部真实任务、用户访谈、灰度实验和在线行为数据结合起来，建立一套能够持续判断产品是否变好的证据系统。

3. 推动模型与 Harness 共同进化

传统产品经理通常把问题描述清楚，再交给研发实现。

Harness 产品经理还要多走一步：把真实任务中的失败轨迹、人工修正和用户反馈，转化为模型与系统共同进化的输入。

一次失败可能来自：

1. 模型能力不足；

2. 上下文缺失或污染；

3. 工具定义不清；

4. Agent Loop 不合理；

5. 权限或执行环境受限；

6. 结果验证不足；

7. 产品交互让用户表达错了需求。

不同原因对应完全不同的解决方案：重新训练模型、调整 Context、修改工具 Schema、增加 Skill、改变任务规划，或者重新设计交互。

如果无法进行这种失败归因，就很容易把所有问题都归结成一句：“模型还不够强。”

4. 亲手把想法变成原型

DeepSeek 明确要求候选人能够使用 Vibe Coding 写代码，并借助 AI 完成产品原型、UI 和 UX 设计。

这不等于要求产品经理变成专业后端工程师，更不等于要求手写复杂算法。

它真正要求的是：你不能只在文档里描述想法，而要能使用 Codex、Claude Code、Cursor 等工具，把想法迅速变成一个可以运行、可以观察、可以测试的实验。

最低限度的工程能力应当包括：

• Python 或 TypeScript 基础；

• REST API 与 JSON；

• 模型 API 和 Function Calling；

• MCP Client 与 Server；

• 文件系统、命令行和 Git；

• 简单数据库、测试与日志；

• Docker、沙箱、权限与审批的基本概念；

• 能阅读、修改和验证 AI 生成的代码。

关键不在于你手写了多少代码，而在于你能否发现代码和系统中的问题，并把产品判断转化为可验证的实验。

5. 从用户和社区里提取信号

岗位还要求维护用户社群，并能使用英文与开源社区进行书面沟通。

Agent 产品仍处在快速变化期，很多重要需求不会整齐地出现在需求池里。产品经理要能区分：

• 用户说了什么；

• 用户真正遇到了什么；

• 高频抱怨是不是最值得解决的问题；

• 少数高级用户的问题是否代表未来方向；

• 某次失败是偶发错误，还是系统性缺陷。

这要求产品经理既能贴近用户，又不能被声音最大的用户牵着走。

三、JD 背后的四项核心能力

DeepSeek 在岗位要求中列出了 LLM API、KV Cache、Agent Loop、Tool Use、Reasoning、Planning、Skills、MCP、Memory、Subagent、Multi-Agent，以及 Prompt、Context 和 Harness Engineering。

同时，它还要求候选人深度使用 Claude Code、Cowork、Codex、Cursor、OpenCode、GitHub Copilot、Manus、OpenClaw、Hermes 等产品，并将这些产品真正融入工作和生活。

注意，关键词不是“体验过”，而是“深度使用”。

所谓深度使用，至少意味着：

• 用它完成过几十个真实任务；

• 知道它在什么条件下容易失败；

• 理解权限、工具、上下文和任务拆分机制；

• 能比较不同产品的 Agent 行为；

• 能说清某个产品为什么成功，而不是只列功能表。

把整份 JD 压缩后，可以得到四项核心能力。

产品判断力：能判断什么问题值得做、用户为什么需要，以及产品价值如何被验证。

技术理解力：不必成为模型研究员，但能够和研究员、工程师讨论上下文、工具调用、缓存、训练反馈和评测。

构建能力：能亲自做原型、接模型和工具、看日志、改 Prompt、调工作流。

实证能力：不能只说“体验更好了”，而要拿出任务集、运行轨迹、指标、用户反馈和实验结果。

因此，这个岗位最核心的竞争力不是懂多少 Agent 概念，而是：

能够把一个不稳定的模型，变成可以稳定完成真实任务的产品，并用证据证明它确实变好了。

四、从公开信息看，面试可能考什么？

需要先说明一个事实：截至 2026 年 7 月 11 日，公开网络上仍然缺少完整、可核验的“DeepSeek Agent Harness 产品经理本人面经”。

这个岗位在 2026 年 5 月才公开出现，招聘时间很短。网上不少所谓“DeepSeek Harness 产品经理面试题大全”，实际上是根据 JD 推测，甚至是课程营销内容，不能当成真实题库。

此前流传较广的一篇文章，描述了三轮 DeepSeek Agent 面试：第一轮深挖 Agent 链路、记忆、Token 成本和故障处理；第二轮设计可商用系统；第三轮讨论赛道判断和独立负责方向。但截图中写得很清楚：这是“Agent 开发岗”，不是 Harness 产品经理。

它能帮助我们理解 DeepSeek 对真实项目和生产落地的重视，却不能证明产品经理也会经历完全相同的考核。

公开转载信息显示，DeepSeek Harness 团队通常采用“一轮笔试加三轮面试”的流程；团队负责人崔添翼也公开表示，Harness 团队仍然非常缺人，自己几乎每天都在面试。具体轮次和考核内容仍应以实际招聘通知为准。

结合 JD、团队结构以及其他公司的真实 AI 产品面试，下面几类问题出现的概率很高，但它们是合理推断，不是泄露真题。

Agent 产品判断

• Claude Code 的核心竞争力来自模型还是 Harness？

• Codex、Claude Code、Cursor、Manus 的本质差异是什么？

• DeepSeek 应该先做代码 Agent，还是通用桌面 Agent？

• 哪些能力属于模型，哪些能力应该由 Harness 负责？

好的回答不能停留在功能对比，而要进入 Agent 行为：它如何获取上下文、拆解任务、调用工具、验证结果、恢复失败并建立用户信任。

技术机制

• 一个完整 Agent Loop 如何运行？

• Function Calling、MCP 和 Skill 有什么区别？

• Memory 与 Context 有什么区别？

• 什么情况下需要 Subagent？

• 单 Agent 与 Multi-Agent 应该如何选择？

• 长任务如何跨越上下文窗口？

• KV Cache 对成本和响应速度有什么影响？

MCP 官方文档将 Tools、Resources 和 Prompts 定义为服务端可以暴露的三类核心原语。理解这些概念，不是为了背定义，而是为了知道 Agent 如何发现能力、获得上下文并执行外部操作。

数据与评测

例如：“如何判断一个代码 Agent 的某次升级真的有效？”

一个完整回答至少要覆盖任务成功率、人工介入、工具失败、测试通过率、耗时、成本和回归问题，并说明离线任务集、在线实验与用户访谈之间是什么关系。

OpenAI Agents SDK 默认记录模型生成、工具调用、Handoff 和 Guardrail 等完整轨迹；Anthropic 也强调，应同时查看运行轨迹与最终环境状态，因为 Agent 说“完成了”，不代表任务真的完成了。

现场构建与项目深挖

候选人可能被要求在限定时间内完成一个可运行原型，接入模型与工具，展示运行轨迹，再解释失败原因和下一轮实验。

过往项目也可能被连续追问：

• 为什么必须用 Agent，而不是普通工作流？

• 失败案例是什么？

• 哪些改进有效？

• 如何证明效果不是模型升级带来的？

• 用户量扩大一百倍后会发生什么？

• 如何处理权限、安全和人工审批？

这些问题的共同目的，是验证候选人究竟做过真实系统，还是只拼过一个可以演示的 Demo。

五、想走这条路，应该怎样学习？

最有效的方式，不是继续扩大概念地图，而是围绕一个真实 Agent 产品，建立完整的证据链：

产品定义 → Harness 构建 → 真实运行 → 轨迹分析 → Eval → 用户验证 → 版本迭代

第一步：建立 Agent 行为分析能力

每次 Agent 失败时，尝试判断问题属于哪一层：用户目标、Prompt、Context、Planning、工具选择、工具参数、执行环境、结果验证、状态保存，还是模型能力上限。

不要只记录“这次效果不好”，而要记录输入、上下文、计划、工具调用、失败位置、人工修正和最终结果。

长期积累后，你会得到一份比传统竞品分析更有价值的“Agent 行为库”。

第二步：系统掌握 Harness 的八个模块

建议依次学习：

1. Agent Loop；

2. Tool System；

3. Context Engineering；

4. Memory；

5. Planning 与任务分解；

6. Skills；

7. Subagent 与 Multi-Agent；

8. Evals 与 Observability。

不要为了使用新概念而使用新概念。比如，多 Agent 的价值应该来自上下文隔离、任务并行或专业分工，而不是让架构图看起来更复杂。

第三步：把数据能力提升为“Agent 实验科学”

至少要掌握样本与偏差、分布与置信区间、A/B 测试、灰度发布、定性访谈编码、失败分类，以及 Offline Eval 和 Online Metric 的关系。

真正困难的问题通常不是“新版本成功率提高了多少”，而是：

成功率提高，究竟来自 Harness 改进、模型升级、任务集变简单，还是评分标准发生了变化？

如果不能回答这个问题，就很难真正推动产品进化。

六、最值得做的作品：一个真实任务 Agent Harness

如果只能做一个求职作品，我更建议做“真实软件研发任务 Agent Harness”，让它完成从 Issue 到 Pull Request 的闭环：

1. 阅读代码仓库；

2. 理解 Issue；

3. 生成实施计划；

4. 修改代码；

5. 运行测试与静态检查；

6. 自我审查并修复；

7. 生成 PR 描述；

8. 等待人工审批。

Harness 至少应包含：

• 文件与终端工具；

• MCP 接口；

• Context 管理；

• 任务状态持久化；

• 权限与审批；

• 错误恢复；

• Trace 与日志；

• 客观结果验证；

• 一个简单 Subagent；

• 模型切换与对比。

然后建立 50—100 条真实任务组成的评测集，对比不同模型、Prompt、Context 策略、Skill、Subagent、权限策略和终止条件。

最终输出四项公开成果：

1. 可运行代码；

2. 产品设计文档；

3. Eval 报告；

4. 失败案例与迭代复盘。

这一个完整作品的价值，远高于十个只有聊天界面的 Agent Demo。

七、一个可执行的 12 周路线

第 1—2 周：竞品与行为研究

使用 Claude Code、Codex、Cursor、OpenCode、Manus 等产品完成 30 个真实任务，形成行为记录、失败分类和模型—Harness 边界分析。

第 3—4 周：搭建最小 Harness

完成 Agent Loop、3—5 个工具、MCP、Trace、基础 Context 管理、人工审批与中止机制。

第 5—7 周：打通一个真实任务闭环

停止堆功能，集中解决稳定运行、状态保存、失败恢复和客观验收。

第 8—9 周：建立 Eval

明确什么叫成功、谁来评分、如何避免评测污染，以及怎样区分模型问题与 Harness 问题。

第 10—11 周：真实用户验证

邀请 10—20 位目标用户完成真实任务，记录中断点、人工介入、不信任的时刻以及失败后的恢复方式。

第 12 周：形成作品集与简历证据

不要只写“负责 Agent 产品设计和需求管理”，而要写成：

构建代码任务 Agent Harness，接入 8 类工具并建立 80 条真实任务评测集；通过 Context 压缩、工具错误反馈和自动验证，使任务成功率由 X 提升至 Y，人工介入率下降 Z%，完成 15 位用户灰度测试。

八、面试前，至少要回答清楚这十个问题

1. 你如何定义 Agent Harness？

2. Harness 和 Agent Framework 有什么区别？

3. Claude Code 的竞争力主要来自模型还是 Harness？

4. MCP、Function Calling 和 Skill 有什么区别？

5. Memory 和 Context 有什么区别？

6. 什么情况下应该使用 Multi-Agent？

7. 如何判断 Agent 是否真的完成了任务？

8. 如何区分模型失败与 Harness 失败？

9. 如何设计代码 Agent 的核心指标？

10. 如果明天模型能力大幅提升，现有 Harness 中哪些机制应该删除，哪些仍然需要保留？

最后一个问题尤其重要。

Harness 往往编码了“模型现在做不到什么”的假设。随着模型变强，这些假设会迅速过时。真正优秀的产品经理，不是永远给系统增加复杂度，而是持续重新判断：哪些约束仍然必要，哪些机制已经可以退出历史舞台。

结语

Agent Harness 产品经理不是“更懂 AI 的传统产品经理”，而是一种新的复合岗位：

既理解用户，也理解模型；既能定义产品，也能亲手构建；既有产品品味，也能用实验和评测证明判断。

这条路真正的门槛，不在于背会多少概念，而在于能否拿出三个可验证的成果：

1. 一个真正可运行的 Harness 产品；

2. 一套真实任务 Eval 与失败分类体系；

3. 一份能够说明“为什么这样设计、证据是什么、下一步如何进化”的产品复盘。

做到这三点，你就不只是在准备应聘 Agent Harness 产品经理。

你已经在做 Agent Harness 产品经理的工作了。

参考资料

• DeepSeek Agent Harness 产品经理公开 JD 转录：https://www.sina.cn/news/detail/5299176032438860.html

• DeepSeek 官方招聘：https://talent.deepseek.com/

• DeepSeek Harness 团队招聘信息：https://www.jiemian.com/article/14631494.html

• 《DeepSeek高薪 Agent 岗面经流出》：https://mp.weixin.qq.com/s/FpKFp1PaBtQJB8XWknyY_g

• Anthropic，《Demystifying evals for AI agents》：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

• Anthropic，《Effective harnesses for long-running agents》：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

• OpenAI，《Unrolling the Codex agent loop》：https://openai.com/index/unrolling-the-codex-agent-loop/

• OpenAI，《Harness engineering: leveraging Codex in an agent-first world》：https://openai.com/index/harness-engineering/

• OpenAI Agents SDK Tracing：https://openai.github.io/openai-agents-python/tracing/

• MCP Architecture Overview：https://modelcontextprotocol.io/docs/learn/architecture