# The architect's guide to harness engineering: How to choose or build the one for you.
**作者**: Alex Ker
**日期**: 2026-07-13T18:50:59.000Z
**来源**: [https://x.com/thealexker/status/2076741193367761378](https://x.com/thealexker/status/2076741193367761378)
---
"We shape our tools, and thereafter our tools shape us." – McLuhan. The next generation of trillion-dollar opportunities will come from choosing the best model for your harness, and the best harness for your model. Models and harnesses need co-optimization and co-evolution.
We’ve seen firsthand how frontier teams at OpenEvidence, Notion, and Cursor mold and deliver intelligence to doctors, thinkers, and developers. But as an individual or organization, choosing or customizing a harness is personal and situational; it's often a topic of endless debate amongst the frustration of choice paralysis.
So we wrote a guide to help you think through this decision of choosing your AI harness. We start from the practical question of which harness fits your role. Then, from first principles, we discuss the must-have primitives behind what makes a harness useful, presenting a framework that you can use to evaluate if simply a vanilla option will suffice, or if it’s worth investing in your own bells and whistles. Finally, we wrap up with some musings on where we think harness engineering is heading, so you can build with those constructs in mind.
## Buy, customize, or build?
Non-Engineers (GTM, Ops, most knowledge workers):
You probably shouldn’t customize your harness… most of the time. You should be focused on finding and buying the best harness. Identify the best AI-native applications (Harvey for Legal, Clay for GTM, Descript for Video), learn the constraints and strengths, understand how their scaffolding plugs into your workflow and removes part of the work.
This is because out-of-the-box, less customized experiences provide strong guardrails to prevent degenerate behaviors in sensitive, mission-critical use cases. And constantly gathering and maintaining your evals is infeasible for you as the end-user. The central focus is populating these existing harnesses with the right context, meaning your real job is to be a good context engineer. I’ve suggested some things to maximize your experience inside the harness in a previous how to optimize your harness article.
Engineers (including the non-technical, technical tinkerers):
Here the picture is completely different. The bring-your-own-model setup lets you use a mix of frontier open-source, closed, or even self-hosted models to run harnesses that are both performant and cost-effective. As we move towards a world with long-running and self-managing (i.e. autoresearch) agents, you can spin up subagents in parallel to handle both high-quality deep work and frequent, routine, shallow work.
To get the most out of the harness, you will want to understand how harnesses work under the hood, so you can take the highest leverage actions.
Generally, if you catch error cases or rough edges, you can document them in a file so as to prevent the harness from falling to the same pitfalls and recovery loop, which is a reason behind frequent compactions as well as entering the “dumb zone”. Repeated operations like grep and explorations can be avoided if you encode the structure of a huge codebase into a .md file at the root of the codebase and instruct the harness to look there first. Unused tools can be disconnected to save additional context windows. By doing these practices, you are effectively polishing the final mile performance of the harness, systematically reducing the probability of slop generated and saving on tokens for computations where they are needed.
To take it a step further, if you have a set of user trajectories and a set of evaluations of what “good” looks like, consider post-training or fine-tuning a harness jointly with your model to produce the optimal outputs. For example, in coding, teams like Cursor and OpenCode have created harnesses optimized for specific models oriented against evaluations. That involves shaping system prompts, tool formats, etc., according to online and offline metrics to maximize user delight and retention. In enterprise, RL and SFT are the start of building a differentiated intelligence and moat. But since this is the frontier, most teams are not here by definition and don’t need to be. Exhaust the out-of-the-box and customization approaches first.
## Properties of a useful harness
In general, when we’re talking about harnesses, we think there are 3 categories of harnesses (from least to most composable). Depending on your use case, you will likely want to focus on one category over another:
1. Frameworks and SDKs: These are for building harnesses. Similar to how Django doesn’t give you an app, but instead the building blocks for building an app. Examples include Vercel AI SDK, Anthropic Agent SDK, and Mastra.
2. Extensible: Ship with few to no built-in features beyond the base tool-use loop. Analogous to vanilla emacs or vim in the text editor space. Pi and Deep Agents are the best examples in this category.
3. Turnkey: Batteries-included harnesses with lots of features, often tied to paid or proprietary APIs. This category includes OpenCode, Codex, Claude Code, and Cursor agent.
To think about what harness to use, we can reduce it down to two main components:
1. Harness-task fit. Is it post-trained with the models and tools you need? Does it offer the right features and level of abstraction for what you're trying to do?
2. Fluency. Is it a harness you actually know and understand how to drive?
The eight properties that follow are the diagnostic for question one. There are no concrete recommendations here. As harnesses are updated weekly, we focus on timeless principles instead. Score your candidate against these eight; the gaps tell you whether vanilla is sufficient or you need to build. Read them as questions to ask yourself. Overall, they cluster into how the harness manages context, how it connects to the outside world, and how it behaves in production.
Context and State (within a task)
- Does the harness maintain stateful context across turns? How does it handle interruptions and continuations? What's the compaction mechanism over long horizons, how lossy is it, and can you mitigate that? How does it spin up subagents to fight context rot? Can it parallelize workstreams, whether interwoven or independent?
Memory (across tasks)
- What persists between sessions, and how — local cache, database, or remote? When is that memory retrieved and used?
MCP/Tool Support
- Does the harness have an extensible integration with Model Context Protocol servers? For example, can it be configured to be enriched with Clay data, to output directly to Grafana dashboards, or to ingest from your Notion pages? How faithfully does it interact with other applications? How does the harness let the model take actions? Is it compatible with your desired group of tool calls?
Standard Adherence
- How much does the harness follow an open spec vs. a proprietary structure? OpenCode relies on an SQLite store and open conventions for where tools, MCPs, and skills get installed; Claude Code uses a Claude-specific structure (claude.md, a dedicated Claude directory, its own way of structuring session history in files). Open standards mean portability and less lock-in; proprietary structures can mean tighter integration but harder migration if you decide to share context across harnesses.
Model Selection Flexibility
- How easy is it to try new model endpoints? Can you easily override settings, config files, and environment variables to point to non-native endpoints? As new cutting-edge open source models are released every month, can you try them out in your existing harness setup, or do you need to try them in a different harness? Do all models work equally well in the harness?
Remote Access
- Can you access sessions remotely? Does the harness have built-in features (e.g. Claude Code’s /remote-control), or do you need to install a third-party or community-sourced plugin or wrapper? Will the session still be accessible if you close your laptop?
Observability/Debugging Surface
- How is logging and tracing tracked? Can you catch failure modes when something breaks? Is there an early signal when it's heading the wrong way? Does the harness have operations that let you roll back to an earlier state and course-correct, or, better yet, can it fix itself if it lands in a bad state?
Hackability Spectrum
- This is the key question to ask if you are a technical decision-maker making a harness decision for your team or company.
- You can also see this as the opinionated vs. composable tradeoffs. If a harness has more opinions, it will likely have less friction and will be easily adopted in enterprise—think Copilot. But if it is not opinionated and highly malleable, there are many ways to push the harness to its potential, but also run into pitfalls (like security vulnerabilities and extreme token consumption)—think OpenClaw.
- If you live in a mature organization, finding an opinionated option with guardrails for your team is the way to go, even though it will inevitably stifle some creativity. The sweet spot is finding and/or customizing a harness where the troughs of failure are not critical, but the ceiling of productivity is as uncapped as possible. The composable and hackable harness will empower you, the user, to smooth out what’s not working instead of waiting for the harness maintainer to maybe make that change, upstream.
## The future
As we phase out of the era of prototyping with intelligence and into years of pushing AI across different contexts in production, the hallmark of this shift is a harness that can support, route, and orchestrate many models. Whether you’re an individual, a team adopting a standardized harness, or even a company creating a new one, it comes down to two linked decisions: how you route and how you serve.
Routing across subagents
Karpathy noted that one quirk of LLMs is their jagged edges of intelligence. They might be superhuman in some domains while fumbling hard in others. So the corollary to this is that specialization will become the dominant paradigm: it makes sense to employ multiple models and route each task to the appropriate model using independent subagents.
An increasingly common and strategic pattern is creating dynamic routing inside the harness: have a lightweight classifier to decide if you should route to good open-source defaults to save on costs, a fine-tuned model that maximizes performance metrics such as latency or throughput, or a frontier closed model for a review pass. It's important to keep an eye on cache reuse. Within a multi-turn session, routing to different models can incur a cache hit. For optimal speed and cost, the harness architecture should also be cache-aware, such that requests hit the warm cache associated with a given model whenever possible.
For read-only tasks like investigations or research, subagents can use smaller, faster models. This subagent (or many copies) can be spun up to handle focused, parallelizable tasks, like reading from many sources and collating information on a topic. We see the setup of this subagent layer also being beneficial for modularization. Just like object-oriented programming oriented itself around classes and encapsulation, subagents are a pattern that increases efficiency and compartmentalizes work. And since context rot is one of the primary causes of degradation in output quality and hallucination, operating many models independently will keep the context clean.
Serving for performance
Once routing is in place and each workload is matched to the right kind of intelligence, the performance of the models themselves is tied directly to user experience. The experience is determined by the infrastructure around the inference itself.
It’s not only important to choose the right harness but equally critical to choose the right model for agentic use cases that meet your requirements. For example, GLM 5.2 is a stellar candidate for both quality and performance. Additionally, the bring-your-own-model harness, or a proxy, gives you the flexibility to choose the best model-harness combination for tasks. Our friends at LangChain have created Harness Profiles specifically for this purpose that you can read about here.
The principle worth keeping regardless of vendor: performance is part of harness-task fit, and BYO-model is how you control it. If you need guaranteed rate limits, burst handling, and uptime, hosting your own open or custom models is how you get there. Dedicated infrastructure is what lets you control caching, batching, and disaggregation to squeeze out responsiveness without giving up quality. We expect mature builders to serve harnesses with performance in mind and continue to find ways to optimize along this vector.
## Final thoughts
Harnesses are not a one-size-fits-all solution and should not be treated as such. We walked through how to approach harness engineering from both the technical and non-technical sides: when to buy, when to customize, and when to build from scratch.
Rather than concrete recommendations that will age poorly as harnesses are added and deprecated, we shared a set of timeless questions to help you understand and guide your decision. To a large extent, the best harness properties will be standardized, and eventually commoditized, which makes all harnesses intuitive to use. And my bet is that routing the intelligence towards the right models and having performant inference will fold into the harness itself and be table stakes as it evolves.
The takeaway should be to choose your non-negotiables (e.g. strong compaction because you have huge contexts, operability across multiple models, remote access, etc) and become fluent at using one particular harness. And with fluency come the ways to fork, modify, or command the harness to do precisely what you want.
## 相关链接
- [Alex Ker](https://x.com/thealexker)
- [@thealexker](https://x.com/thealexker)
- [35K](https://x.com/thealexker/status/2076741193367761378/analytics)
- [article](https://x.com/thealexker/status/2045203785304232162?s=46&t=qLTUK63eMdrw2KTz3cCnrg)
- [dumb zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone)
- [here](https://x.com/Vtrivedy10/status/2049535740233523600)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:50 AM · Jul 14, 2026](https://x.com/thealexker/status/2076741193367761378)
- [35.9K Views](https://x.com/thealexker/status/2076741193367761378/analytics)
- [View quotes](https://x.com/thealexker/status/2076741193367761378/quotes)
---
*导出时间: 2026/7/14 10:10:42*
---
## 中文翻译
# 架构师的 harness 工程指南：如何选择或构建适合你的 harness
**作者**: Alex Ker
**日期**: 2026-07-13T18:50:59.000Z
**来源**: [https://x.com/thealexker/status/2076741193367761378](https://x.com/thealexker/status/2076741193367761378)
---
“我们塑造工具，而后工具塑造我们。”——麦克卢汉。下一代万亿美元级的机会将来自于为你的 harness 选择最佳模型，以及为你的模型选择最佳 harness。模型和 harness 需要共同优化、共同进化。
我们亲眼见证了 OpenEvidence、Notion 和 Cursor 的前沿团队如何为医生、思考者和开发者塑造并交付智能。但作为个人或组织，选择或定制一个 harness 是个人化的、因场景而异的；这常常是引发无休止争论的话题，同时还伴随着选择瘫痪的困扰。
因此，我们写了一份指南，帮助你思考选择 AI harness 这一决策。我们从“哪种 harness 适合你的角色”这一实际问题入手。然后，我们从第一性原理出发，讨论让 harness 有用背后必备的基本要素，并给出一个框架，你可以用它来评估是仅用基础版本就足够，还是值得投入打造自己的花哨功能。最后，我们对 harness 工程的未来走向分享一些思考，以便你在构建时将这些概念铭记于心。
## 购买、定制，还是自建？
非工程师（GTM、运营、大多数知识工作者）：
大多数情况下，你可能不应该定制你的 harness……你应该专注于寻找并购买最好的 harness。找到最好的 AI 原生应用（法律领域的 Harvey、GTM 领域的 Clay、视频领域的 Descript），了解它们的约束和优势，理解它们的脚手架如何接入你的工作流程并分担部分工作。
这是因为开箱即用、较少定制的体验能提供强大的护栏，防止在敏感、任务关键的使用场景中出现退化行为。而作为最终用户，持续收集和维护你的评估集是不现实的。核心重点是用正确的上下文填充这些现有的 harness，也就是说，你真正的职责是做好一个上下文工程师。我在之前那篇关于如何优化你的 harness 的文章中给出了一些最大化使用体验的建议。
工程师（包括非技术的技术爱好者）：
这里的情况完全不同。自带模型（bring-your-own-model）的设置让你可以混合使用前沿的开源模型、闭源模型，甚至是自托管模型，来运行既高性能又高性价比的 harness。随着我们迈向一个拥有长时间运行、自我管理（即自动研究）智能体的世界，你可以并行启动子智能体，同时处理高质量的深度工作和频繁、常规的浅层工作。
要充分发挥 harness 的效用，你需要了解 harness 在底层是如何工作的，这样你才能采取杠杆率最高的行动。
一般来说，如果你发现了错误案例或不完善的边缘情况，可以将它们记录在一个文件中，以防止 harness 陷入同样的陷阱和恢复循环——这也是频繁压缩（compaction）以及进入“笨拙区”的原因之一。如果你把庞大的代码库结构编码到代码库根目录的一个 .md 文件中，并指示 harness 优先查看该文件，就可以避免 grep 和探索等重复操作。可以断开未使用的工具以节省额外的上下文窗口。通过这些实践，你实际上是在打磨 harness 的最后一英里性能，系统性地降低生成垃圾内容的概率，并把 token 节省到真正需要的计算上。
再进一步，如果你有一组用户轨迹和一组关于“好”的标准评估，可以考虑对 harness 与你的模型进行联合后训练或微调，以产生最优输出。例如，在编程领域，Cursor 和 OpenCode 等团队创建了针对特定模型、面向评估进行优化的 harness。这包括根据在线和离线指标来塑造系统提示词、工具格式等，以最大化用户满意度和留存率。在企业级应用中，RL 和 SFT 是构建差异化智能和护城河的起点。但由于这是前沿领域，按定义大多数团队并不在此，也不需要在此。先把开箱即用和定制化的方法用尽再说。
## 一个有用的 harness 的特性
总体而言，当我们谈论 harness 时，我们认为 harness 分为 3 类（按可组合性从低到高）。根据你的使用场景，你可能会更倾向于关注某一类：
1. 框架和 SDK：用于构建 harness。就像 Django 不会直接给你一个应用，而是提供建构应用的基础组件。例子包括 Vercel AI SDK、Anthropic Agent SDK 和 Mastra。
2. 可扩展型：除了基础的工具调用循环外，几乎没有或完全没有内置功能。类似于文本编辑器领域的原版 emacs 或 vim。Pi 和 Deep Agents 是这一类别中最好的例子。
3. 开箱即用型：功能丰富的“电池全含”型 harness，通常与付费或专有 API 绑定。这一类别包括 OpenCode、Codex、Claude Code 和 Cursor agent。
要思考该使用哪种 harness，我们可以将其归结为两个主要组成部分：
1. Harness 与任务的匹配度。它是否针对你需要的模型和工具进行了后训练？它是否为你想做的事情提供了合适的功能和抽象层级？
2. 熟练度。它是否是你真正了解并知道如何驾驭的 harness？
接下来的八个属性是回答第一个问题的诊断标准。这里没有具体的建议。由于 harness 每周都在更新，我们关注的是经久不衰的原则。用这八条来给你的候选对象打分；差距会告诉你现成的方案是否足够，还是你需要自建。把它们当作需要问自己的问题来读。总体上，它们归为三类：harness 如何管理上下文、它如何与外部世界连接、以及它在生产环境中的表现。
上下文与状态（单个任务内）
- harness 是否能在多轮之间维护有状态的上下文？它如何处理中断和续接？长跨度下的压缩机制是什么，损失有多大，能否缓解？它如何启动子智能体来对抗上下文腐化？它能并行化工作流吗，无论是交织的还是独立的？
记忆（跨任务）
- 会话之间什么内容会持久化，以何种方式——本地缓存、数据库还是远程？这些记忆何时被检索和使用？
MCP/工具支持
- harness 是否与 Model Context Protocol 服务器有可扩展的集成？例如，能否配置它以接入 Clay 数据进行增强、直接输出到 Grafana 仪表盘，或从你的 Notion 页面摄取内容？它与其他应用的交互有多可靠？harness 如何让模型执行操作？它是否与你所需的工具调用集合兼容？
标准遵循度
- harness 在多大程度上遵循开放规范而非专有结构？OpenCode 依赖 SQLite 存储和开放的约定来决定工具、MCP 和技能的安装位置；Claude Code 则使用 Claude 专属的结构（claude.md、专用的 Claude 目录、自己组织会话历史文件的方式）。开放标准意味着可移植性和更少的锁定；专有结构可能意味着更紧密的集成，但如果你决定跨 harness 共享上下文，迁移会更困难。
模型选择灵活性
- 尝试新的模型端点有多容易？能否轻松覆盖设置、配置文件和环境变量以指向非原生端点？随着每个月都有新的尖端开源模型发布，你能否在现有的 harness 配置中试用它们，还是需要在另一个 harness 中尝试？所有模型在 harness 中的表现是否一样好？
远程访问
- 你能否远程访问会话？harness 是否有内置功能（例如 Claude Code 的 /remote-control），还是你需要安装第三方或社区开发的插件或包装器？如果你合上笔记本电脑，会话仍然可以访问吗？
可观测性/调试界面
- 日志和追踪是如何记录的？当出现问题时，你能否捕捉到故障模式？当它走向错误方向时，是否有早期信号？harness 是否有操作可以让你回滚到较早的状态并纠正方向，或者更好的是，当它陷入糟糕状态时能否自我修复？
可改造性光谱
- 如果你是一个为团队或公司做 harness 决策的技术决策者，这是需要问的关键问题。
- 你也可以把这看作是强主张与可组合之间的权衡。如果一个 harness 主张更多，它的摩擦可能更小，也更容易在企业中被采用——想想 Copilot。但如果它没有强主张且高度可塑，有很多方式可以将其潜力发挥到极致，但也会踩到坑（比如安全漏洞和极端的 token 消耗）——想想 OpenClaw。
- 如果你身处一个成熟的组织，为团队找到一个带有防护栏的强主张方案是正确之路，尽管它不可避免地会压制一些创造力。最佳平衡点在于找到和/或定制一个 harness：失败的谷底不致命，而生产力的天花板尽可能不被封顶。可组合、可改造的 harness 将赋能你，让用户自己去修复不奏效的部分，而不是等待 harness 维护者也许有朝一日在上游做出那个改动。
## 未来
随着我们逐步告别用智能做原型的时代，进入在生产的各种不同场景中推动 AI 落地的岁月，这一转变的标志是能够支持、路由和编排多个模型的 harness。无论你是个人、采用标准化 harness 的团队，还是正在创建新 harness 的公司，归根结底是两个相互关联的决策：你如何路由，以及你如何服务。
跨子智能体路由
Karpathy 指出，LLM 的一个特点是智能呈锯齿状。它们在某些领域可能超越人类，而在其他领域则表现得很吃力。由此推论，专业化将成为主导范式：使用多个模型，并通过独立的子智能体将每个任务路由到合适的模型，是有道理的。
一种日益常见且具有战略意义的模式是在 harness 内部创建动态路由：用一个轻量级分类器来决定应该路由到优秀的开源默认模型以节省成本、路由到在延迟或吞吐量等性能指标上最大化的微调模型，还是路由到用于审查环节的前沿闭源模型。关注缓存复用也很重要。在多轮会话中，路由到不同模型可能会导致缓存失效。为了获得最优的速度和成本，harness 架构还应该是缓存感知的，使请求尽可能命中与给定模型关联的温缓存。
对于调查或研究等只读任务，子智能体可以使用更小、更快的模型。这种子智能体（或其多个副本）可以被启动来处理聚焦的、可并行的任务，例如从众多来源读取信息并就某个主题整理汇总信息。我们看到，建立这一子智能体层也利于模块化。就像面向对象编程围绕类和封装来组织代码一样，子智能体是一种能提高效率并将工作隔离分区的模式。而且，由于上下文腐化（context rot）是输出质量下降和幻觉产生的主要原因之一，让多个模型独立运行可以保持上下文干净。
服务于性能
一旦路由机制到位，每种工作负载都匹配到了合适类型的智能，模型本身的性能就直接关系到用户体验。而体验是由推理之外的底层基础设施决定的。
选择合适的外壳固然重要，但为满足你需求的智能体场景选择合适的模型同样关键。例如，GLM 5.2 在质量和性能两方面都是出色的候选。此外，自带模型（BYO-model）的外壳或代理层让你可以灵活地为任务选择最佳的“模型-外壳”组合。我们在 LangChain 的朋友们专门为此创建了 Harness Profiles（外壳配置档案），你可以在这里阅读相关内容。
无论使用哪家供应商都值得坚持的原则是：性能是“外壳-任务”匹配的一部分，而自带模型正是你掌控性能的方式。如果你需要保证的速率限制、突发流量处理和正常运行时间，自行托管开源或定制模型就是实现之道。专用基础设施让你能够控制缓存、批处理和分离式部署，从而在不牺牲质量的前提下榨取响应速度。我们期待成熟的构建者在搭建外壳时以性能为导向，并继续在这一方向上寻找优化空间。
## 结语
外壳不是万能的解决方案，也不应被当作万能方案对待。我们从技术和非技术两个角度梳理了如何进行外壳工程：何时购买、何时定制、何时从零构建。
我们没有给出那些随着外壳不断新增和淘汰而很快过时的具体建议，而是分享了一套经得起时间考验的问题，帮助你理解并指导决策。在很大程度上，最优秀的外壳特性将被标准化，并最终商品化，这使得所有外壳都变得直观易用。而我的判断是，将智能路由到合适的模型以及高性能推理，最终会融入外壳本身，并随着其演进成为基本门槛。
核心要点是：确定你的不可妥协项（例如，因为上下文巨大而需要强压缩、跨多个模型的可操作性、远程访问等），并熟练掌握某一个特定的外壳。而随着熟练度的提升，你就能掌握分叉、修改或指挥外壳精确执行你所需操作的方法。
## 相关链接
- [Alex Ker](https://x.com/thealexker)
- [@thealexker](https://x.com/thealexker)
- [35K](https://x.com/thealexker/status/2076741193367761378/analytics)
- [article](https://x.com/thealexker/status/2045203785304232162?s=46&t=qLTUK63eMdrw2KTz3cCnrg)
- [dumb zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone)
- [here](https://x.com/Vtrivedy10/status/2049535740233523600)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:50 AM · Jul 14, 2026](https://x.com/thealexker/status/2076741193367761378)
- [35.9K Views](https://x.com/thealexker/status/2076741193367761378/analytics)
- [View quotes](https://x.com/thealexker/status/2076741193367761378/quotes)
---
*导出时间: 2026/7/14 10:10:42*
