“我们塑造工具，此后工具也塑造我们。”——麦克卢汉。下一代万亿美元级机会，将来自为你的 harness（承载模型、工具、context 和工作流的运行框架）选择最佳模型，也来自为你的模型选择最佳 harness。模型和 harness 需要共同优化、共同演进。
我们已经亲眼看到 OpenEvidence、Notion 和 Cursor 的前沿团队如何塑造智能，并把智能交付给医生、思考者和开发者。但对个人或组织来说，选择或定制一个 harness 是非常个人化、非常依场景而定的事；在选择困难带来的挫败感中，这也常常变成一个争论不休的话题。
所以我们写了这份指南，帮助你想清楚如何选择自己的 AI harness。我们先从一个实际问题开始：哪种 harness 适合你的角色。然后，我们从第一性原理出发，讨论一个 harness 之所以有用背后必备的基础能力，并给出一个框架，帮你判断一个原生默认选项是否已经足够，还是值得投入精力做自己的额外功能。最后，我们会谈谈自己对 harness 工程未来方向的一些思考，让你在构建时能把这些结构考虑进去。
买、定制，还是自己构建？
非工程师（GTM、运营、大多数知识工作者）：
大多数时候，你可能不应该定制自己的 harness。你应该把精力放在寻找并购买最好的 harness 上。找出最好的 AI 原生应用（法律场景的 Harvey、GTM 场景的 Clay、视频场景的 Descript），学习它们的约束和优势，理解它们的 scaffolding 如何接入你的工作流，并替你拿掉一部分工作。
原因在于，开箱即用、较少定制的体验，会提供更强的护栏，防止敏感、关键任务场景中出现退化行为。而作为最终用户，你也不现实地持续收集和维护自己的 eval。核心重点是给这些现有 harness 填入正确的 context，也就是说，你真正的工作是成为一个好的 context engineer。我之前在一篇关于如何优化 harness 的文章里，提过一些能最大化 harness 内体验的做法。
工程师（包括非科班但懂技术、喜欢动手折腾的人）：
这里的情况完全不同。自带模型（bring-your-own-model）的设置，让你可以混合使用前沿开源模型、闭源模型，甚至自托管模型，来运行既高性能又有成本效益的 harness。随着我们走向一个由长时间运行、自我管理的 agent（例如 autoresearch）组成的世界，你可以并行启动 subagent，同时处理高质量的深度工作，以及频繁、常规、较浅的工作。
要最大化 harness 的价值，你会想理解 harness 在底层是如何工作的，这样才能采取杠杆最高的行动。
一般来说，如果你发现错误场景或边角问题，可以把它们记录在一个文件里，防止 harness 反复掉进同样的坑和恢复循环；这也是频繁压缩以及进入“笨区”背后的原因之一。像 grep 和探索这类重复操作，如果你把一个巨大代码库的结构编码到代码库根目录下的 .md 文件里，并指示 harness 先看那里，就可以避免。用不到的工具也可以断开，以节省额外的 context window。通过这些实践，你实际上是在打磨 harness 最后一公里的性能，系统性降低生成垃圾内容的概率，并把 token 节省给真正需要计算的地方。
再进一步，如果你有一组用户轨迹，以及一组关于“好结果”是什么样的评估，可以考虑把 harness 和模型一起做后训练或微调，让它们产出最优结果。比如在 coding 场景中，Cursor 和 OpenCode 这样的团队已经创建了针对特定模型优化、并面向评估调整的 harness。这涉及根据在线和离线指标来塑造系统提示词、工具格式等，以最大化用户满意度和留存。在企业场景中，RL 和 SFT 是构建差异化智能和护城河的起点。但因为这里处在前沿地带，按照定义，大多数团队还没到这一步，也没必要到这一步。先把开箱即用和定制路线用到尽。
有用 harness 的属性
一般来说，当我们谈 harness 时，会认为 harness 有 3 类（从最不易组合到最易组合）。根据你的使用场景，你很可能会更关注其中一类：
- 框架和 SDK：这些是用来构建 harness 的。类似 Django 本身不会给你一个应用，而是给你构建应用的积木。例子包括 Vercel AI SDK、Anthropic Agent SDK 和 Mastra。
- 可扩展型：除了基础工具调用循环之外，内置功能很少，甚至几乎没有。类似文本编辑器领域里的原生 emacs 或 vim。Pi 和 Deep Agents 是这一类最好的例子。
- 交钥匙型：功能齐全的 harness，内置大量能力，通常绑定付费或专有 API。这一类包括 OpenCode、Codex、Claude Code 和 Cursor agent。
思考要用什么 harness 时，我们可以把问题简化为两个主要组成部分：
- Harness-task fit。 它是否针对你需要的模型和工具做过后训练？它是否提供了适合你目标的功能和抽象层级？
- 熟练度。 这是一个你真的知道并理解如何驾驭的 harness 吗？
接下来的 8 个属性，是用来诊断第一个问题的。这里没有具体推荐。因为 harness 每周都在更新，我们关注的是更经得起时间考验的原则。用这 8 个属性给你的候选项打分；差距会告诉你，原生默认版本是否足够，还是你需要自己构建。把它们当作要问自己的问题来读。总体来看，它们聚集在三件事上：harness 如何管理 context，如何连接外部世界，以及如何在生产环境中表现。
Context 与状态（单个任务内）
- 这个 harness 是否能在多轮交互中维护有状态的 context？它如何处理打断和继续？长周期中的压缩机制是什么，损耗有多大，你能否缓解？它如何启动 subagent 来对抗 context rot？它能否并行化工作流，无论这些工作流是相互交织还是彼此独立？
Memory（跨任务）
- 会话之间会保留什么，又是如何保留的——本地缓存、数据库，还是远端？这些 memory 会在什么时候被检索和使用？
MCP/工具支持
- 这个 harness 是否能以可扩展的方式集成 Model Context Protocol server？例如，它是否可以配置为用 Clay 数据来丰富 context，直接输出到 Grafana dashboard，或从你的 Notion 页面中摄取内容？它与其他应用交互的保真度如何？这个 harness 如何让模型采取行动？它是否兼容你想要的一组工具调用？
标准遵循度
- 这个 harness 在多大程度上遵循开放 spec，而不是专有结构？OpenCode 依赖 SQLite 存储和开放约定来规定工具、MCP 和 skill 安装到哪里；Claude Code 使用 Claude 专属结构（
claude.md、专用 Claude 目录，以及自己在文件中组织会话历史的方式）。开放标准意味着可移植性更强、锁定更少；专有结构可能意味着集成更紧密，但如果你决定在不同 harness 之间共享 context，迁移会更困难。
模型选择灵活性
- 尝试新的模型端点有多容易？你能否轻松覆盖设置、配置文件和环境变量，把它们指向非原生端点？随着每个月都有新的前沿开源模型发布，你能否在现有 harness 设置里试用它们，还是必须换一个 harness？所有模型在这个 harness 中表现都一样好吗？
远程访问
- 你能否远程访问会话？这个 harness 是否有内置功能（例如 Claude Code 的
/remote-control），还是需要安装第三方或社区提供的插件或 wrapper？如果你合上笔记本，会话还可以继续访问吗？
可观测性 / 调试界面
- 日志和 tracing 是如何跟踪的？当某个东西坏掉时，你能否捕捉失败模式？当它开始走偏时，是否有早期信号？这个 harness 是否有操作能力，让你能回滚到更早的状态并纠偏；或者更好的是，如果它落入坏状态，能否自行修复？
可 hack 程度谱系
- 如果你是为团队或公司做 harness 决策的技术决策者，这是要问的关键问题。
- 你也可以把它看成“带强主张”与“可组合”之间的取舍。如果一个 harness 主张更多，它可能摩擦更少，更容易在企业中被采用——比如 Copilot。但如果它不带强主张、可塑性很高，你就有很多办法把 harness 推向它的潜力上限，但也会遇到更多坑（例如安全漏洞和极端 token 消耗）——比如 OpenClaw。
- 如果你身处一个成熟组织，为团队找到一个带护栏、带强主张的选项，是更合适的路线，尽管它不可避免会压制一些创造力。理想位置是找到并/或定制一个 harness：它失败时的低谷不至于致命，但生产力的上限尽可能不封顶。可组合、可 hack 的 harness 会赋能你这个用户，让你能把不顺手的地方磨平，而不是等待 harness 维护者也许会在上游做出那个改动。
未来
随着我们逐步走出“用智能做原型”的阶段，进入多年把 AI 推向不同生产环境的阶段，这一转变的标志，会是一个能够支持、路由和编排多个模型的 harness。无论你是个人、采用标准化 harness 的团队，还是正在创建新 harness 的公司，问题最终都会落到两个相互关联的决策上：你如何路由，以及你如何服务。
跨 subagent 路由
Karpathy 提到过，LLM 的一个怪异之处在于能力边界参差不齐。它们可能在某些领域超越人类，却在另一些领域表现笨拙。由此得到的推论是，专业化会成为主导范式：使用多个模型，并通过独立的 subagent 把每个任务路由到合适的模型，是合理的。
一个越来越常见且具有战略意义的模式，是在 harness 内创建动态路由：用一个轻量级分类器决定是否应该路由到不错的开源默认模型以节省成本，路由到经过微调、能最大化延迟或吞吐量等性能指标的模型，还是路由到前沿闭源模型做一次 review。关注缓存复用也很重要。在多轮会话中，路由到不同模型可能会带来缓存命中问题。为了获得最佳速度和成本，harness 架构也应该具备缓存感知能力，让请求尽可能命中与特定模型关联的热缓存。
对于调查或研究这类只读任务，subagent 可以使用更小、更快的模型。这个 subagent（或它的多个副本）可以被启动，用来处理聚焦、可并行的任务，例如从许多来源读取信息，并围绕一个主题汇总资料。我们也认为，这种 subagent 层的设置有利于模块化。就像面向对象编程围绕类和封装来组织自身一样，subagent 是一种能提高效率、隔离工作的模式。而且，由于 context rot 是输出质量下降和幻觉产生的主要原因之一，让许多模型独立运行，可以保持 context 干净。
面向性能的服务
一旦路由到位，每个 workload 都匹配到了正确类型的智能，模型本身的性能就会直接关系到用户体验。体验由推理本身周围的基础设施决定。
不仅选择正确的 harness 很重要，选择正确的模型来满足你的 agentic 使用场景需求，同样关键。例如，GLM 5.2 在质量和性能两方面都是一个出色候选。此外，自带模型的 harness，或一个代理，会给你灵活性，让你可以为任务选择最佳的模型-harness 组合。LangChain 的朋友们专门为此创建了 Harness Profiles，你可以在这里阅读相关内容。
无论供应商是谁，都值得保留的原则是：性能是 harness-task fit 的一部分，而 BYO-model 是你控制性能的方式。如果你需要有保障的速率限制、突发流量处理和正常运行时间，托管自己的开放模型或定制模型，就是达成这些目标的方式。专用基础设施让你能够控制缓存、批处理和解耦，以在不牺牲质量的前提下挤出响应速度。我们预计，成熟的构建者会带着性能意识来部署 harness，并持续沿着这个方向寻找优化方式。
最后几点想法
Harness 不是一种放之四海而皆准的方案，也不应该被这样对待。我们从技术和非技术两个侧面，梳理了如何看待 harness 工程：什么时候买，什么时候定制，什么时候从零构建。
与其给出会随着 harness 增删而迅速过时的具体推荐，我们分享了一组经得起时间考验的问题，帮助你理解并指导自己的决策。在很大程度上，最好的 harness 属性会被标准化，并最终商品化，这会让所有 harness 都变得直观易用。而我的判断是，把智能路由到正确模型，以及具备高性能推理能力，会随着 harness 演进而折叠进 harness 本身，并成为基本门槛。
最终要点应该是：选择你的不可妥协项（例如，因为你有巨大的 context，所以需要强压缩；需要跨多个模型操作；需要远程访问，等等），并熟练掌握某一个特定 harness。随着熟练度提升，你也会找到 fork、修改或指挥这个 harness 的办法，让它精确完成你想要的事。