我为什么开始给自己搭 Harness？

在 LLM 出现以前，我就经常被一件很普通的事情困扰：整理自己电脑里的文件。资料越来越多以后，文件应该放在哪里、哪个版本才是最新的、一个项目上次做到哪、还有什么事情没处理，都会慢慢变成负担。自己当然可以设计目录、定命名规则、做项目记录，但这些事情本身也需要持续维护，规模一大，很容易又乱回去。

LLM 出现以后，我很快意识到一个可能性：这些原本必须由人持续维护的数字工作环境，有没有可能逐渐交给 AI？ 但刚开始使用网页版 ChatGPT 时，这还只是一个模糊想法。那时 AI 对我来说更多还是一个聊天窗口，我真正能优化的主要是 Prompt：怎样把需求、背景和约束说得更清楚。

真正的变化发生在后来 Claude Code、Codex 这类能够直接进入本机工作环境的 Agent 工具出现以后。2025 年 Claude Code 已经可以直接从终端搜索和读取代码、编辑文件、运行测试与命令；Codex CLI 则把同样的 Agent 工作方式带到了本地终端。对我来说，这是 Personal Harness 能从想法变成实际系统的重要技术前提：AI 和真实数字环境之间，不再必须始终由人负责搬运信息。

用得越来越深以后，我也逐渐发现，很多 AI 交付问题并不只是 Prompt 写得不好，而是模型根本没有拿到完成工作需要的历史、状态和约束。更进一步，对长期合作来说，“为什么这样判断”有时和“最终选了什么”同样重要。

最近写《当人和 AI 都在改变，“对齐”还能一次完成吗？》时，我其实已经把自己的 Personal Harness 当成了贯穿全文的一条实践线。那篇文章讨论的是：当人、AI 和环境都会变化，怎样让昨天的反馈真正改变今天的判断。文章最后我写道：

我们不只需要决定 AI 今天应该是什么样，还要决定它和我们明天可以怎样一起变化。

写完以后，我发现还有一个更具体的问题没有真正展开：如果真想让这种变化跨会话、跨任务持续发生，支撑它的 Personal Harness 到底是什么，又应该怎样搭？

一、一个模型要真正工作，还缺哪几层东西？

Harness 最容易被注意到，还是因为 Coding Agent。我以前在《工程演进三段论：从 Prompt 到 Harness，竞争重心在哪里》里简单讨论过这层变化，这篇不准备重新展开。最朴素地说，Harness 就是模型之外那套让 AI 真正能够在一个环境里工作的东西。

OpenAI 对 Codex Harness 的介绍就是从最底层的 Agent Loop（智能体执行循环）开始：用户提出目标，模型判断下一步，调用工具获得结果，再继续判断；随着任务越来越长，Context 怎么管理也成了 Harness 的职责。完整的 Codex Harness 又继续承担会话、工具调用和执行逻辑，并能够被不同 Codex 客户端复用。(OpenAI)

真正把 Codex 放进大型软件工程以后，仅仅“能调用工具”还是不够。OpenAI 后来的 Harness Engineering 实践复盘里提到，很多问题需要通过让代码库、工具、文档和反馈机制变得更适合 Agent 来解决，而不是简单要求模型“再努力一点”。

Harness 目前没有一套行业统一的分类方法。为了理解后面的 Personal Harness，我更愿意用三个连续的问题来看它：

这不是 L1、L2、L3 这样的能力等级，更不是三个互斥的产品类别。更准确地说，它们是可以同时存在于一套系统里的三种 Harness 职责：随着 AI 从回答问题走向长期工作，我们还需要不断给它补什么？

第一层，是让模型从“能回答”变成“能行动”。Microsoft 现在把 Agent Harness 定义为让语言模型能够真正完成工作的运行支撑层，它会驱动模型与工具调用、管理会话状态和 Context、应用审批策略，并让 Agent 在多步骤任务里继续推进。

有了执行能力以后，第二个问题是：面对不同工作，它知道怎样做才算专业吗？ 写代码需要理解仓库、修改实现、运行测试、根据报错继续修复；做研究需要拆问题、寻找来源、处理冲突、判断证据什么时候已经够了。Codex、Claude Code 之所以不只是“能用 Shell 的聊天机器人”，就在于它们已经把大量软件工程所需的环境和工作方式一起交给了模型。

但即使一个 Agent 已经非常会做研究，还有一类信息它天然不知道：这次到底是在替谁工作？ 一家企业有自己的数据、业务流程和组织规则；一个人也有自己的项目、文件、历史判断和工作方式。到了这一层，需要补的已经不再只是“如何做研究”或“如何写代码”，而是这个具体主体真实存在的工作环境。

OpenClaw 是一个很有意思的例子。它官方把自己定位为运行在个人设备上的 Personal AI Assistant（个人 AI 助手），但如果不看产品自称，而是看实际承担的系统职责，按本文的框架，它已经可以视为一种完成度很高的 Personal Harness 实践：有长期 Workspace、用户信息、Memory、Skills、会话和工具，也把个人设备与消息渠道接到了同一个长期运行环境里。(OpenClaw) (Workspace 文档)

但这里也让我进一步想清楚了一个区别：一个系统“属于个人”，和它真正“理解这个人”，并不是一回事。 Personal AI Assistant 更容易从“这个 AI 能长期替我做什么”出发；而我理解的 Personal Harness，更关心“它怎样越来越理解这个具体的人，并在遇到不同问题时，知道该调用哪些与这个人有关的历史、画像、判断方式和边界，再开始工作”。

这也是为什么 Personal Harness 不能只靠一份用户说明或一段长期 Memory。真正重要的是，系统能不能持续形成对人的可校正理解，并把这种理解按任务需要调用进来：哪些历史与当前问题有关，哪些旧偏好已经过时，哪些判断方式只在特定场景成立，什么事情可以直接推进，什么事情必须重新找本人确认。Personal 的核心，不只是数据属于谁，而是系统是否逐渐形成了“怎样和这个人一起工作”的能力。

从这个角度看，一个产品完全可能同时覆盖多层 Harness。OpenClaw 既有底层运行能力，也已经包含大量 Personal 层能力；Codex 则同时拥有运行层和很强的 Coding 专业环境。这里真正重要的不是产品把自己叫什么，而是它实际为模型补上了哪些工作环境，以及“Personal”这一层到底深入到了什么程度。

所以，如果把前面的关系压成一句话，就是：

先让模型能行动，再让它学会做好一类工作，最后让它真正进入某个具体的人或组织的环境。

我后来真正开始自己往外搭的，就是最后这部分，而且重点也越来越清楚：不是简单给 AI 多放一些“关于我的资料”，而是让它逐渐知道，面对不同问题时，哪些与我有关的 Context 真正应该参与工作。

Personal Harness 也并不是我自己发明的名字。现在已经有公开项目直接使用 Personal AI Harness 或 Personal Harness Configuration 来描述围绕个人数据、Memory、Skills、Prompt 和工作流形成的系统，只是目前还没有稳定统一的定义。本文沿用这个说法，讨论的是我自己这套更偏长期个人工作环境的实践。

二、对我来说，Personal Harness 首先改变了“怎么开始工作”

现在拿到一批新资料，我通常先把它们放进自己设立的“待整理”区域，然后直接在 Codex 的聊天窗口里说我要完成什么。系统会按照已有规则寻找相关 Context，把文件放到合适的位置，继续维护任务状态和后续事项。我仍然负责目标、判断和真正需要讨论的取舍，但已经越来越少亲自维护那些“不值得长期占用人脑”的数字环境。

以前的操作单位是文件、文件夹、软件和页面；现在很多时候，我正在尝试把工作的入口变成一句更接近意图的话：

“我要完成这件事。”

但 Personal Harness 真正需要补的并不只是文件管理。长期合作以后，AI 需要拿到的 Context 会逐渐包含很多零碎、却会影响任务的信息：最近在关注什么，为什么某件事突然提高了优先级，一个方案以前是不是已经讨论过，对某件事的看法最近有没有变化，甚至只是工作过程中冒出来、暂时还没有整理成熟的想法。

这些东西有些最后会被证明毫无价值，有些却会成为下一次工作非常重要的背景。模型本身再强，也不可能凭空拥有一段从未被记录过的个人经历和项目历史。

最近我又开始想得更远一点。最初我希望的是：自己的文件和数字工作环境能不能尽量交给 AI 管理？ 现在逐渐出现了另一个问题：以后别人和我协作时，有多少事情可以直接先交给“我的 AI”？

如果它已经知道项目背景、过去为什么这样判断、哪些条件会改变优先级，以及什么事情通常需要我本人拍板，那么很多原本必须重新找我解释和确认的问题，也许不需要每次都从零开始。当然，这不意味着 AI 已经可以代表我做所有决定；恰恰相反，哪些事情可以自己处理、哪些必须回来找我，本身也是 Harness 需要管理的边界。

但随着真实的判断依据越来越多地被沉淀下来，真正需要我本人反复参与的重复性判断，理论上应该越来越少。

我现在这套 Harness 的日常入口仍然是 Codex Desktop，很多规则、Skills 和文件机制也依赖它当前提供的能力。但我越来越在意的是另一件事：哪些只是这一代工具的实现细节，哪些才是值得长期留下的个人资产。

对我来说，后者不是一条专门针对 GPT 或 Claude 写下的 Prompt，而是自己的工作历史、项目状态、判断过程，以及那些已经在真实任务中被反复验证过的协作方式。

三、比“记住结果”更重要的，是留下判断的来路

现在模型原生的 Memory 已经可以保存不少个人背景和偏好，所以我并不想再造一套“更强的 Memory”。真正让我继续往下搭的问题是：一件事情留下以后，下一次究竟应该怎么用？

一次会话里冒出的想法，不一定值得变成长期偏好；一次任务成功，也不应该直接变成永久规则。某个失败可能只属于当前项目，也可能暴露了一套通用方法的问题。所以对我来说，长期协作的问题并不是简单地“记得越多越好”，而是要不断判断：什么值得留下、应该留下在哪里，又应该怎样影响以后。

长会话里的决策记录，就是我比较早遇到的一个具体问题。我的 Codex 会话经常很长，Context 到一定程度以后会被压缩。如果只剩最后一段摘要，一些关键决定的来路很容易被磨平，所以我会让长任务额外保存辅助记录。最开始这么做只是为了任务中断以后能够继续，但真正使用以后，我发现这些记录还有第二个价值：它们保存了我做决定时真正考虑过什么。

最终结果也许只有一句“选择 B”，过程里却可能留下为什么最开始考虑 A、真正担心的是什么、什么问题让 A 被否掉，以及后来什么条件改变了优先级。对长期合作来说，这些信息有时比“最终选择了 B”本身更有价值。

后来，这又进一步长成了我现在的用户画像机制。日常任务真正需要读取的其实很简单：一部分是已经确认、能够跨任务复用的核心画像和协作边界；另一部分是我在分析、研究和做判断时经常使用的检查视角。

但这两类结果背后并不简单。

画像还有自己的治理规则、变更记录和证据台账。新的反馈也不会因为在一次会话里出现，就直接写进长期画像，而是会经过沉淀、范围判断、冲突检查和晋升，再决定最后应该进入用户画像、分析方法、Skill、工作规则，还是只留在当前任务里。这条生成、治理和更新链路现在已经基本自动运行，真正需要我介入的，更多是到达重要决策边界时的确认。

所以我日常感受到的反而不是“为了 Personal Harness 多维护了很多文件”，而是背后的复杂度越来越少需要我亲自处理。

Memory 保存过去，Harness 决定过去怎样影响下一次行动。

这里我尤其在意画像机制中的一个原则：画像是透镜，不是迎合机制。 过去的偏好可以帮助 AI 更快知道我习惯检查什么、关心什么，但不能替代当前事实。面对可争论的判断，它仍然应该检查反例、替代解释和失败条件，而不是因为“以前的我这样想”就继续顺着走。

过去可以成为下一次判断的起点，但不能成为下一次判断的牢笼。

这也是上一篇“持续对齐”真正想讨论的问题之一：如果未来人和 AI 会长期共同学习，我们不只是需要 AI 更了解今天的我，还需要保留双方明天一起改变的空间。

四、这套 Harness 不是一次设计出来的，而是被问题一点点逼出来的

如果现在回头看，我当然可以把自己的 Harness 拆成很多部分：文件治理、Context 路由、任务恢复、用户画像、经验沉淀、Skill 生命周期、质量审计、模型与工具选择……实际机制远不止下面这些。

但逐项介绍意义不大，也很容易把文章写成一份 README。真正有意思的是，它们大多不是我先画完一张完整架构图再开始实现，而是在工作里反复撞到问题以后，一点点长出来的。下面只是其中几个代表性的例子：

表里只是几条典型路径。具体机制一直在变，但形成方式基本相同：先由真实工作暴露摩擦，再判断它值不值得被变成长期的系统能力。

如果只看这张表，很容易产生另一个疑问：机制越来越多，最后是不是反而要花大量时间管理 Harness 本身？

我自己的实际体验恰恰相反。

现在我已经不需要知道系统到底有多少机制、分别存在哪里、什么条件下会生效，也不需要手动维护大部分机制之间的关系。随着 Harness 继续演化，机制本身的登记、沉淀、检查、晋升、追溯和退役，也开始由相应的管理机制接走。

后台的复杂度，是为了让前台的人可以忘掉复杂度。

这也是为什么我不太喜欢先设计一套看起来非常完整的 Harness，再要求自己的工作去适应它。一个机制如果从来没有真实消费者，或者只是因为“理论上应该有”，那么它迟早会成为新的维护成本。

五、好的 Harness，应该让人和模型都少做无效工作

现在回过头看，我判断 Harness 有没有开始产生效果，已经不太看里面有多少规则、多少文件或者多少 Skill，而是看它有没有真正减少人和模型在任务开始前、执行中和维护阶段反复付出的成本。

一个更直接的变化发生在我自己怎么向 AI 提问题。

以前遇到一个复杂问题，我经常会先自己想一遍：这到底是什么问题，背景应该怎么组织，哪些条件必须提前说，怎样整理成一个 AI 比较容易理解的 Prompt。也就是说，在真正把问题交给 AI 以前，我会先替它做一层“翻译和预加工”。

现在越来越多时候，我会直接把原始问题、相关材料，甚至还没有完全想成熟的念头交给它。因为项目状态、历史 Context、已有方法，以及一部分稳定的分析习惯已经存在于 Harness 里，我不再需要每次先把自己的整个工作环境压缩成一段 Prompt。

少替模型思考，多把真实环境交给模型。

对我来说，这可能比“多装了多少 Skill”更能说明 Harness 开始起作用。它减少的不只是操作文件的时间，也开始减少人与 AI 真正协作以前那层重复发生的表达、整理和加工。

这里还有一个看起来有点反直觉的问题。机制文件越来越多，很多人第一反应可能是：那模型每次是不是得读取越来越多内容，最后 Token 和成本反而越来越高？

我的实际做法并不是让模型每次把整套 Harness 全部读一遍。现在已经有一套相对完整的 Context 路由机制负责这件事：任务进来以后，先判断任务类型和风险，再决定应该加载哪些规则和 Skills；随后通过文件索引找到候选材料，继续检查相关性、权威性和新鲜度，在 Context 预算内组装当前任务真正需要的背景和证据，最后再决定使用什么模型和推理强度。文件索引只是这条路由链路中的一个环节，多数时候 AI 先需要知道的是“应该去哪里找、哪份更可能是当前事实、还需要继续读什么”，而不是因为本地存在很多文件，就把它们全部阅读全文。

后台拥有的信息可以越来越丰富，但单次任务真正进入 Context 的，仍然应该只是最低充分的那部分。

Context 质量本来就是影响模型表现的重要变量。我的实际体验是，当当前任务拿到的 Context 更准确、更相关以后，一些过去更依赖高能力模型的任务，换成更低一档的模型也能得到不错的结果。有时模型能力虽然弱一些，但因为它不需要花那么多能力去猜背景、边界和工作方式，最终效果并不会同步下降。

如果更准确的 Context 能让一部分任务下沉到成本更低的模型，那么 Harness 的成本账就不能只看它额外读取了多少 Token。 Context 本身当然也有成本，但更值得比较的，是为了把同一件事做到足够好，最终用了什么模型、多少推理、发生了多少返工，又投入了多少人的时间。

这个变化也影响了我怎么看外部工具。

刚开始构建 Harness 时，我关注过不少高 Star 的 GitHub 项目。看到一个设计很完整的新工具，很自然会想：这个是不是应该也装进来？

但真正把它们交给现有 Harness 评估以后，结果往往不是直接安装。很多项目最后停留在待观察；还有一些真正有价值的地方，是其中某个思路或者机制被吸收到我已有的系统里，而不是把整个项目原样搬进来。

这件事后来让我越来越警惕“能力收藏”。一方面，基础模型和 Agent 工具正在快速吸收过去需要额外组件才能完成的共性能力；另一方面，Personal Harness 真正有价值的东西往往不是某个孤立插件，而是它能不能和已有 Context、工作方式以及其他机制真正组合起来。

Anthropic 在长期 Agent 的实践里也遇到过类似的问题。Sonnet 4.5 在 Context 快到极限时容易提前收尾，因此他们曾在 Harness 中加入上下文重置，让新的 Agent 带着必要状态继续工作；到了 Opus 4.5，这种行为消失以后，原来有用的机制反而成了多余负担。后来随着模型继续进步，他们又开始尝试删除过去为了帮助旧模型完成长任务而加入的更多结构。(Anthropic)

Harness 中的很多东西，本质上是在编码“这一代模型还做不到什么”。

而这个判断随时可能过期。今天为了弥补模型能力增加的特殊 Prompt、规划机制，或者为了绕过 Context 限制设计的额外流程，下一代模型如果已经能自己做好，就应该让它们消失。这不是 Harness 被模型“打败”了，反而说明它完成了这一阶段的作用。

真正不会因为一次模型升级就凭空消失的，是你的真实经历、决策历史、当前项目状态、关注重点和现实约束。未来模型很可能彻底改变我们保存、压缩和调用这些信息的方式，但它不能替你经历过去，也不能凭空知道你为什么改变过一个判断。

六、让 AI 知道更多，不等于让它做得更多

当越来越多真实工作环境进入 Personal Harness，另一个问题才开始变得重要：

AI 越来越了解我，是否意味着它也应该拥有越来越大的自主权？

我现在的答案是否定的。Context 和权限应该分开设计。

一个 AI 可以知道完整的任务历史，但仍然只能读取文件；也可以被允许在明确的本地目录里自主完成安全、可逆的工作，却继续不能自动上传资料、删除内容或者对外发布。系统有多完整，和 AI 获得多少行动权限，本来就是两回事。

这和人类组织里的权限其实很像：知道一件事，和有权代表谁做一件事，并不是同一个问题。

Personal Harness 越往长期发展，这条边界反而越重要。因为当系统掌握越来越多个人工作信息以后，“它了解我”与“它可以代表我做什么”之间，需要一条越来越清楚的线。

而这也会影响前面提到的另一个方向：如果未来别人真的开始更多地直接与“我的 AI”协作，那么什么事情可以由它直接处理，什么事情必须回到本人，会比今天更加重要。

七、不是每个人都需要 Personal Harness

如果只是偶尔问几个问题、写一段文案，搭一整套任务状态、画像、Skill 和审计体系，很可能只是在制造新的维护成本。所以我现在判断 Personal Harness 是否值得开始，首先看的不是职业名称，而是工作的形态。

如果 AI 经常需要处理大量本地文件，一个任务会跨天、多轮甚至反复中断，结论和输入又需要追溯，同时你已经不断遇到“这个背景是不是解释过很多次”“上次到底做到哪里”“为什么又找错了文件”“这个方案之前是不是已经否掉了”这些问题，那么某种 Personal Harness 的收益会更容易出现。

反过来，纯即时问答未必需要它。纯 Coding 也不一定需要额外套一层复杂的 Personal Harness：如果主要工作就是写代码、运行测试和提交 PR，Codex、Claude Code 自己已经提供了很成熟的执行环境和 Coding 专用能力。只有当工作继续扩展到长期项目、研究、正式文档、跨任务 Context 和个人方法以后，更外面的这一层才会越来越有意义。

Harness 应该从真实的重复成本里长出来，而不是因为 Harness 这个概念听起来先进，就先搭一套。

八、如果未来把它分享出来，我更想分享“起点”，而不是我的答案

等这套实践继续稳定下来，我希望把其中真正可分享、可复用的部分抽取出来，做成一个 GitHub 项目。

但想得越多，我越确定一件事：真正应该公开的，不是“我的 Personal Harness 本身”。

我的真实用户画像、工作历史、项目状态、决策轨迹和私人 Context，本来就不应该成为别人的模板。即使全部脱敏，把一套已经围绕我长出来的系统原样交给另一个人，也未必有多大意义。

如果未来真的打开这个仓库，我更希望它是一套可以自己长起来的起步骨架。第一次使用时，先了解一个人主要做什么工作、资料在哪里、任务会不会经常跨天、哪些动作需要自己确认，然后给出足够轻的起点。真实需求变复杂以后，再按需增加任务恢复、经验沉淀、Skill 管理和质量检查；没有需要，就不要为了完整感全部装上。

第一轮我会以自己长期使用的 Codex Desktop 和 Windows 作为真实验证基线，但这并不意味着整套方法要绑定在它们上面。真正希望长期保留的部分——Context 组织、用户画像、任务恢复、沉淀与晋升、权限边界——应该尽量和具体运行平台解耦。

换到 Claude Code 或其他能够操作真实工作环境的 Agent 时，更像是重新适配它的规则文件、Skills、权限模型和工具接口，而不是从头重新设计一个 Personal Harness。现在的 AI 本身也已经可以承担相当一部分这种结构理解和转换工作；当然，真正声明兼容以前，实际的权限、工具调用和运行行为仍然需要重新验证。

所以我更关心的，不是一个仓库在首日写着“支持多少平台”，而是：哪些东西应该成为个人可以长期带走的资产，哪些只是当前运行环境的适配层。

因为真正的 Personal Harness，本来就不应该长得一样。同一个起点经过不同人的工作、反馈和判断以后，最终留下来的 Context、方法、规则和画像一定会不同。

所以我更希望未来分享的是一个起点，而不是一套标准答案。

我对 Personal AI 还有一个更远的想象。今天它可能主要还是助手，再往后也许会承担越来越多持续性的事务，甚至在某些场景里开始成为一个人的数字代理。是不是最终会走到“数字分身”，或者科幻作品里 Jarvis 那样的形态，我不知道。

但如果这条路真的存在，一个能够越来越多代表我的 AI，显然不能只靠更强的基础模型。它需要逐渐知道我经历过什么、为什么这样判断、哪些事情可以自己推进，又在什么情况下必须回来找我。

我现在搭 Personal Harness，也是在很早期地实践这个问题。

而这背后还有一个更直接的出发点：在 AI 能力快速增长的时代，怎样尽可能放大它对个人能力的杠杆。

这个杠杆不只是让 AI 在某一次任务里多做几件事。如果每换一个任务、一个会话，我们还是要重新搬运 Context、重新解释历史、重新整理问题、重新告诉 AI 哪些事情已经做过，那么模型越来越强，并不意味着我们真的把这种能力积累了下来。

我更希望的是，今天花时间形成的 Context、方法和纠偏，明天不需要重新付一遍成本；今天仍然需要本人处理的事情，也可能随着长期判断依据的积累，逐渐有一部分被自己的 AI 接过去。

具体模型会继续升级，今天很多 Harness 的实现也一定会被替代。但只要这些真正属于个人的积累能够持续进入下一次工作，人和 AI 的合作就不必每次从零开始。

真正的 AI 杠杆，不只是让一次任务做得更快，而是让每一次合作，都能成为下一次合作的起点。

参考资料

Harness / Agent 官方资料

• OpenAI — Unrolling the Codex agent loop
• OpenAI — Unlocking the Codex harness: how we built the App Server
• OpenAI — Harness engineering: leveraging Codex in an agent-first world
• OpenAI / GitHub — Codex CLI
• Microsoft — Agent Harness
• Anthropic — Claude 3.7 Sonnet and Claude Code
• Anthropic — Scaling Managed Agents: Decoupling the brain from the hands
• Anthropic — Harness design for long-running application development

Personal Harness / Personal Agent 相关实践

• OpenClaw — Personal AI Assistant
• OpenClaw — Agent Workspace
• OKBrain — Personal AI Harness
• rfgamaral / pi-config — Personal harness configuration

此前相关文章

• 《当人和 AI 都在改变，“对齐”还能一次完成吗？》
• 《工程演进三段论：从 Prompt 到 Harness，竞争重心在哪里》