如果你没搞懂Harness，面试AI产品经理的时候，大概率会被刷掉。

面试官自己可能也没搞懂，但你没说到点子上，对方是听得出来的。

概念你可能看过，但有没有真正上手做过，回答时的感觉是完全不一样的。

其实不止AI，很多行当都是这样：没有在真实场景里解决过真实问题，讲出来的东西就带着一股浓浓的“纸上谈兵”味儿。

不过AI行业实在太新了，真正落地的产品本来就没几个。那问题来了——没做过，怎么才能讲出那种实操感呢？

今天这篇长文，就是想教大家怎么“驾驭”一个新概念。核心思路其实很简单：模拟场景 → 盘点场景问题 → 用技能解决问题

我们拿Harness这个词来练手。通过模拟“我如何在设计写作Agent时应用Harness工程策略，一步一步优化产品”这个流程，来解决三个问题：

1. 帮还不了解Harness的PM掌握这个新概念
2. 帮了解了Harness但不知道怎么用的PM掌握实战能力
3. 演示如何在面试时回答出“实操感”

下面，就是一个“裸奔”的写作Agent，逐步通过Harness策略“武装”成类似Claude Code那样稳定的真·Agent的全过程。

其中关于当前阶段存在什么问题、如何应用Harness策略的论述，就是你在面试时要讲出来的“实操感”。

从零到一：一个写作Agent的Harness工程迭代

模拟场景：开发一个「写作Agent」——用户提供写作主题和风格参考文章，Agent联网调研后在指定路径下输出文稿。

核心思路：以这个写作Agent为例，演示如何从一个「出厂配置」的基本Agent描述，逐层叠加Harness策略，最终形成一份可靠的开发规格。每一层都解决上一层暴露的问题，循序渐进。

第零章：需求背景

用户是谁？

一位内容创作者。他想写一篇关于某个主题的深度文章，手头有几篇风格参考文章，希望AI帮他完成「调研 → 构思 → 撰写 → 修改」的全流程，最终在指定文件夹里输出成品。

我们要造什么？

一个写作Agent。它拥有以下工具：

用户输入：写作主题 + 风格参考文章（文件路径）+ 输出路径。

Agent在输出路径下生成最终文稿。

为什么要用这个场景来演示？

写作任务有个好特性：它天然就是一条链路（调研 → 大纲 → 初稿 → 润色），步骤明确但又不琐碎，特别适合展示Agent怎么规划、怎么执行、怎么从错误中恢复。而且它不需要复杂的代码工具链，方便产品经理理解每一个Harness环节的意图。

v0.1：出厂配置 —— 最基础的Agent描述

「模型 + 循环 + 工具 = 一个能动的Agent。就像新手机出厂设置，能打电话，但还没装App。」

核心思路

一个Agent的最小构成只需要三样东西：

1. 1. 循环（Loop）：接收需求 → 推理 → 调用工具 → 拿到结果 → 继续推理，直到模型认为任务完成。
2. 2. 工具（Tools）：让模型能和真实世界交互——读写文件、搜索网页。
3. 3. 规划（Planning）：让模型在动手前先想清楚「要分几步做」。

V0.1描述

这是面向Coding Agent的提示词版本，毕竟现在产品经理的工作流程已经不再是PRD → 原型图 → 开发协(si)作(bi)了。

这个描述能跑吗？

能。但大概率会碰上这些问题：

• 搜索了20条结果，上下文直接撑爆，后面什么都干不了了。
• 写到一半跑偏了，开始写跟主题无关的内容，但自己完全不知道。
• 中途断了（比如工具调用报错），整个任务就废了，没有恢复机制。
• Agent觉得自己写完了，其实才写了个开头就停了（或者反过来，写完了还不停）。

Agent怎么知道「我做到哪一步了」？

它不知道。因为我们的产品描述里只定义了「Agent需要做哪些事」，但没有定义「做到哪了算哪」。一个没有任务清单的Agent，就像一个没有清单的装修队——干到哪算哪，重复干活、遗漏步骤是家常便饭。

v0.2：任务规划与状态管理 —— 让Agent知道自己在干嘛

没有计划的Agent走哪算哪。先列步骤再动手，完成率翻倍。

上一轮的问题

v0.1的Agent有两个致命缺陷：

1. 1. 没有任务清单：模型不知道自己完成了什么、还剩什么。在长任务中，前面做的事会被后面的信息挤出注意力，导致重复干活或遗漏步骤。
2. 2. 没有「完成」的判断标准：模型凭感觉决定什么时候停。有时任务没完成就停了（「我觉得差不多了」），有时完成了还在那磨蹭。

Harness策略

策略一：强制任务规划（TodoWrite）

在循环开始前，要求Agent先生成一份结构化的任务清单。这份清单会作为上下文的一部分，在每一轮循环中持续呈现给模型。

策略二：状态追踪与强制回顾

通过Hooks（自动脚本），每轮循环结束时，自动把任务清单重新拼接到上下文末尾。利用「近因效应」——越靠后的内容对模型注意力影响越大——确保模型每轮都能看到「我做到哪了」。

策略三：熔断机制

设置最大循环轮次（如50轮）。同时，如果连续3轮模型没有更新任务状态，强制注入提示要求模型审视进度。

v0.2描述

这样就好了吗？

好多了。Agent现在有清单了，知道自己做到哪了，也有「完成」的判断标准了。

但新问题又来了：

• 写作任务需要搜索大量资料，每条搜索结果几千字。搜10条，上下文就满了。Agent读了参考文章（可能5000字），又搜了几轮资料后，上下文窗口已经撑到极限，后面写大纲、写初稿的空间就不够了。
• Agent搜资料时搜到了太多无关内容（比如搜「气候变化」结果出来一堆广告），这些垃圾信息占着上下文不走。

上下文窗口是有限的，怎么让Agent在有限空间里「无限」地工作？

v0.3：上下文管理 —— 在有限空间里「无限」工作

上下文窗口是Agent的工作台。台面就这么大，你得决定放什么、不放什么、什么该收起来。

上一轮的问题

上下文窗口（Context Window）就像一个工作台，空间有限。一个1000行的文件大约4000 token，搜索结果可能上万token。写作Agent的完整工作流——搜资料×多轮 + 读参考文章 + 写大纲 + 写初稿 + 润色——轻松突破100K token。如果不做管理，要么上下文撑爆导致任务中断，要么旧信息被挤出导致模型「失忆」。

Harness策略

策略一：首轮上下文精准组装

系统提示词不是「一股脑全塞进去」，而是分层组装：

策略二：消息历史滚动压缩

每轮工具调用的结果不会永远留在上下文中。当消息列表增长到一定程度，早期的工具调用结果会被「归档」——替换为一条摘要 + 指向原始文件的路径。模型如果需要回顾，可以主动读取文件。这就像浏览器标签页：你看完一个网页就关掉它，释放内存；需要时从历史记录里重新打开。

策略三：Subagent分流

搜索环节特别适合用Subagent（子袋里）。主Agent发出指令「帮我搜一下XX主题的最新进展」，Subagent用自己的独立上下文去搜索、筛选，只把结论摘要返回给主Agent。好处是：主Agent的上下文里不包含搜索结果的原始全文，只有一句话摘要。10条搜索 × 每条3000字 = 30000字的原始结果，压缩成10条 × 每条50字 = 500字的摘要。

策略四：技能列表（Skills）按需加载

如果Agent有多种「写作技能」（如学术写作、公众号写作、商业文案），不需要在系统提示词里塞入全部技能的完整说明。只需放一个技能目录（名称 + 一句话描述），当模型判断需要某种技能时，再加载完整说明。

V0.3描述

上下文管理好了，然后呢？

Agent现在能在有限的上下文空间里把任务执行完了。但有一个新风险：

• Agent在搜索资料时，执行了bash命令curl下载了一个网页到本地，但写入路径时搞错了，把文件写到了输出路径之外的某个目录。
• 或者更糟——它执行了rm命令，删掉了不该删的东西。

Agent有执行shell命令的能力，万一它做了危险操作怎么办？

v0.4：沙箱与权限管理 —— 给Agent画一个安全围栏

不是不信任模型，而是不能无条件信任。每一次工具执行都必须经过安检。

上一轮的问题

Agent能执行bash命令，意味着它理论上可以做任何事：读写任意文件、执行任意程序、访问网络。即使模型没有恶意，也可能因为推理错误导致破坏性操作——比如把write_file的路径参数拼错，写到了系统目录。

Harness策略

策略一：工作空间沙箱

为Agent定义一个「工作空间」（即输出路径）。所有文件操作的路径都必须解析为绝对路径后，校验是否在工作空间内。

这就是「沙箱隔离」的本质：不是限制Agent的能力，而是限制它的活动范围。就像幼儿园的围栏——孩子可以在院子里随便跑，但跑不出去。

策略二：命令分层权限

不是所有命令都应该被同等对待：

策略三：路径逃逸防护

Agent在多次目录跳转后，可能拼接出../../这样的路径意外逃出工作空间。每次执行文件操作前，必须将路径规范化（resolve），然后校验是否仍在工作空间内。

V0.4描述

安全问题解决了，但还有个效率问题

Agent现在安全了。但我们在v0.3版本里提到的「每轮都更新plan.md」「每轮都检查路径」这些操作——谁来执行？如果全靠模型主动调用工具去做，那就是在浪费模型的注意力。模型应该把注意力集中在「写作」这件事上，而不是每轮都要想起来「我是不是该更新一下plan.md」。

有些操作是机械性的、应该自动执行的，不需要模型操心。怎么实现？

v0.5：Hooks —— 不需要模型操心的自动化

能用程序做的，就别浪费模型的注意力。Hooks是Agent的后台管家。

上一轮的问题

到目前为止，很多操作都依赖模型「主动记得去做」：更新任务清单、检查路径是否安全、拼接上下文信息。但模型不是人，它每轮都是一个全新的请求。它不记得「我上一轮是不是忘了更新plan.md」。如果靠提示词要求它做，它可能会忘；如果靠代码强制它做，它就永远不会忘。

Harness策略

Hooks是在Agent循环的关键节点自动执行的脚本，不需要模型参与：

常见的Hooks设计：

V0.5描述

Hooks是万能的吗？

不是。Hooks解决了「机械性操作自动化」的问题，但有些事不是自动化能解决的——比如用户偏好。假设这个写作Agent是一个长期使用的个人助理。用户用了三个月，每次都说「我想要简洁风格」「不要用太多比喻」「开头要直入主题」。每次新会话都要重复这些。

Agent怎么记住「上一次」和「用户的习惯」？

v0.6：记忆管理 —— 让Agent越用越好

没有记忆的Agent，每次对话都是初次见面。

上一轮的问题

当前的Agent每次启动都是「白纸一张」。它不记得：用户的写作偏好（简洁？华丽？学术？）、之前写过什么主题（避免重复）、用户纠正过哪些错误（「不要用这种开头方式」）、之前任务的产出（方便复用或引用）。

Harness策略

策略一：自动记忆提取

每次任务结束后，通过一个自动Hook调用LLM，从对话中提取值得记忆的信息：

这些记忆以结构化文本存储，在每次新会话的首轮上下文组装时自动注入。

策略二：跨会话检索

当用户说「上次我们写过一篇关于XX的文章，帮我引用一下那篇的观点」，Agent需要能检索历史会话。但不是把历史会话全部塞入上下文，而是通过关键词检索，只拉取相关片段。

V0.6描述

记忆有了，但还有个大问题

一切看起来不错了。但回到一个基本问题：如果工具调用失败了怎么办？

• 搜索API超时了。
• write_file因为权限问题写入失败了。
• read_file读到了一个二进制文件，返回了一堆乱码。
• 网络断了，web_search直接报错。

在V0.1里，如果工具调用失败，错误信息直接塞进上下文，模型可能会困惑、重复尝试、甚至直接放弃。在长任务中，一次未处理的错误可能导致整个后续流程崩掉。

错误发生了，Agent怎么体面地恢复，而不是直接崩溃？

v0.7：错误恢复 —— 小错不崩，大错可控

做Harness的第一性原理：小错不跳循环，让模型自己处理；大错尽量别犯。

上一轮的问题

在没有错误恢复机制的情况下：

• 一个搜索API超时 → Agent不知道怎么办 → 可能无限重试，浪费轮次。
• write_file失败 → Agent没有意识到文件没写成功 → 继续下一步，结果最终输出缺失。
• 多次失败累积 → 上下文里塞满了错误信息 → 模型的注意力被错误信息绑架，忘记自己在写文章。

Harness策略

策略一：错误信息的结构化处理

工具调用失败时，不是把原始错误日志直接丢进上下文，而是经过Hook处理成结构化的错误摘要：

❌ 工具调用失败：web_search原因：API 请求超时（30秒）建议：换一个搜索关键词重试，或跳过该搜索步骤这是该步骤的第 2 次失败。如果再次失败，建议跳过该步骤。

这比一堆stack trace对模型友好得多。模型看到这个信息，知道该怎么做。

策略二：失败计数与降级

对每个工具维护失败计数：

策略三：关键节点的自动存档

每次write_file或edit_file执行成功后，自动通过Hook保存一个快照（或触发git commit）。如果后续步骤出错导致文稿损坏，可以回滚到上一个正确版本。

V0.7描述

总结：七层迭代全景

回到Harness的基本概念

Model + Harness = Agent

我们用七层迭代，展示了「Harness」到底在做什么：

• 循环让模型能行动。
• 任务规划让模型不迷路。
• 上下文管理让模型不遗忘。
• 沙箱让模型不越界。
• Hooks让机械操作不消耗模型注意力。
• 记忆让模型能成长。
• 错误恢复让模型不崩溃。

每一层都不是「锦上添花」，而是在真实场景中必须解决的工程问题。跳过任何一层，Agent在实际使用中都会暴露对应的缺陷——这就是Harness工程的意义。

附录：给产品经理的自检清单

如果你正在设计一个Agent产品，可以用这份清单逐项检查：

• [ ] 循环控制：Agent有明确的停止条件吗？最大轮次限制是多少？
• [ ] 任务规划：Agent能生成任务清单吗？清单会在每轮循环中被回顾吗？
• [ ] 状态管理：Agent怎么知道自己做到哪了？连续跑偏时有检测机制吗？
• [ ] 上下文窗口：系统提示词占了多少token？工具定义占了多少？给对话历史留了多少空间？
• [ ] 上下文压缩：消息历史太长时怎么处理？压缩后关键信息丢了吗？
• [ ] 沙箱：Agent的文件操作有路径限制吗？能逃逸出工作空间吗？
• [ ] 权限管理：哪些命令直接执行？哪些需要用户确认？哪些永远禁止？
• [ ] Hooks：哪些操作可以自动化？不依赖模型主动记得去做？
• [ ] 记忆：用户的偏好怎么跨会话传递？历史会话怎么检索？
• [ ] 错误处理：工具调用失败时怎么告诉模型？连续失败时怎么降级？
• [ ] 用户追加消息：Agent干活时用户发了新消息，怎么处理？中断还是排队？

另一个版本

上面是按照Agent作业流程的「任务规划」开始，把流程上每个会遇到的问题进行优化的版本。另一个思路是从Agent的另一个基础组件tools的优化开始的。最终解决的东西一样，但却是思维方式的差异：

• 前者是流程导向，通过约束流程的可控性来确保产品的可控性。
• 后者是原子导向，通过约束基本组件的可控性来保证产品的可控性。

篇幅关系，不再赘述了。