# 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*
---
## 中文翻译
# 架构师的人工智能引擎工程指南：如何选择或构建适合你的工具
**作者**: Alex Ker
**日期**: 2026-07-13T18:50:59.000Z
**来源**: [https://x.com/thealexker/status/2076741193367761378](https://x.com/thealexker/status/2076741193367761378)
---
“我们塑造了工具，此后工具塑造了我们。”——麦克卢汉。下一代的万亿美元级机会将来自于为你的引擎选择最佳的模型，以及为你的模型选择最佳的引擎。模型和引擎需要共同优化和共同演进。
我们亲眼见证了 OpenEvidence、Notion 和 Cursor 的前沿团队如何塑造并传递智能给医生、思想者和开发者。但作为个人或组织，选择或定制引擎是个人的且视情境而定的决定；这往往是导致无尽争论的话题，令人陷入选择困难的挫败感中。
因此，我们编写了一份指南，帮助你理清选择 AI 引擎的决策思路。我们首先从“哪种引擎适合你的角色”这个实际问题入手。然后，从第一性原理出发，我们讨论了让引擎发挥作用所必需的原始要素，提出了一个评估框架，帮助你判断简单的原厂选项是否足够，还是值得投资打造你自己的花哨功能。最后，我们总结了一些关于引擎工程未来走向的思考，以便你在构建时能将这些架构纳入考虑。
## 购买、定制还是自建？
非工程师（GTM、运营、大多数知识工作者）：
大多数时候，你大概不应该定制你的引擎……你应该专注于寻找并购买最好的引擎。识别最好的 AI 原生应用（法律领域的 Harvey、GTM 领域的 Clay、视频领域的 Descript），了解它们的局限和优势，理解它们的脚手架如何接入你的工作流程并移除部分工作。
这是因为开箱即用、定制化程度较低的体验提供了强大的护栏，可以防止在敏感、关键任务用例中出现退化行为。而且作为最终用户，不断收集和维护评估指标对你来说是不可行的。核心重点是用正确的上下文填充这些现有的引擎，这意味着你真正的任务是成为一名优秀的上下文工程师。在之前的一篇关于如何优化引擎的文章中，我提出了一些建议，以最大化你在引擎内的体验。
工程师（包括非技术人员、技术极客）：
在这里，情况完全不同。自带模型（BYO-model）的设置允许你混合使用前沿的开源、闭源甚至自托管模型来运行既高效又具成本效益的引擎。随着我们迈向一个拥有长时间运行和自我管理（即自动研究）智能体的世界，你可以并行启动子智能体来处理高质量的深度工作和频繁、常规的浅层工作。
为了充分利用引擎，你需要了解引擎在底层是如何工作的，这样你才能采取最高杠杆率的行动。
通常，如果你遇到错误案例或粗糙的边缘情况，可以将它们记录在文件中，以防止引擎陷入同样的陷阱和恢复循环，这也是频繁进行压缩以及进入“愚蠢区”的一个原因。如果你将巨大的代码库结构编码到代码库根目录下的一个 .md 文件中，并指示引擎首先查看那里，就可以避免像 grep 和探索这样的重复操作。未使用的工具可以断开连接以节省额外的上下文窗口。通过这些实践，你实际上是在打磨引擎的最后一公里性能，系统地减少产生垃圾内容的概率，并将计算令牌节省在需要的地方。
更进一步，如果你有一组用户轨迹和一组关于什么是“好”的评估标准，可以考虑联合模型对引擎进行后训练或微调，以产生最佳输出。例如，在编程方面，Cursor 和 OpenCode 等团队创建了针对特定模型优化的引擎，并以此进行评估。这包括根据在线和离线指标调整系统提示词、工具格式等，以最大化用户满意度和留存率。在企业中，RL（强化学习）和 SFT（监督微调）是构建差异化智能和护城河的开始。但鉴于这是前沿领域，大多数团队按定义来说还未到达这一阶段，也不必急于求成。先穷尽开箱即用和定制化的方法。
## 实用引擎的属性
一般来说，当我们谈论引擎时，我们认为有 3 类引擎（按可组合性从低到高排列）。根据你的用例，你可能更倾向于专注于某一类别：
1. 框架和 SDK：这些用于构建引擎。就像 Django 不会直接给你一个应用程序，而是提供构建应用程序的构建模块。示例包括 Vercel AI SDK、Anthropic Agent SDK 和 Mastra。
2. 可扩展：除了基础工具使用循环外，几乎没有内置功能。类似于文本编辑器领域的原版 emacs 或 vim。Pi 和 Deep Agents 是这一类别的最佳示例。
3. 交钥匙：包含大量功能的“电池内置”引擎，通常与付费或专有 API 绑定。此类别包括 OpenCode、Codex、Claude Code 和 Cursor agent。
要考虑使用哪种引擎，我们可以将其归纳为两个主要组成部分：
1. 引擎-任务匹配度。它是否使用你需要的模型和工具进行了后训练？它是否为你尝试做的事情提供了合适的功能和抽象级别？
2. 熟练度。这是一个你真正了解并且知道如何驾驭的引擎吗？
接下来的八个属性是对第一个问题的诊断。这里没有具体的推荐。由于引擎每周都在更新，我们专注于永恒的原则。根据这八个属性对你的候选对象进行评分；差距会告诉你原厂版本是否足够，还是你需要自行构建。把它们当作问自己的问题来阅读。总的来说，它们聚类为引擎如何管理上下文、如何连接外部世界，以及它在生产环境中的行为方式。
上下文和状态（任务内）
- 引擎是否在多轮对话中维护有状态上下文？它如何处理中断和继续？在长跨度下的压缩机制是什么，信息损失有多大，你能缓解这种情况吗？它如何启动子智能体来对抗上下文腐烂？它可以并行化工作流吗，无论是交织的还是独立的？
记忆（跨任务）
- 会话之间保留了什么，以及如何保留——本地缓存、数据库还是远程？该记忆何时被检索和使用？
MCP/工具支持
- 引擎是否具有与模型上下文协议服务器的可扩展集成？例如，是否可以配置为使用 Clay 数据进行丰富，直接输出到 Grafana 仪表板，或从你的 Notion 页面摄取内容？它与其他应用程序的交互有多忠实？引擎如何让模型采取行动？它是否与你期望的一组工具调用兼容？
标准遵循度
- 引擎在多大程度上遵循开放规范而不是专有结构？OpenCode 依赖于 SQLite 存储和关于工具、MCP 和技能安装位置的开放约定；Claude Code 使用 Claude 特有的结构（claude.md、专门的 Claude 目录、其在文件中构建会话历史的独特方式）。开放标准意味着可移植性和更少的锁定；专有结构可能意味着更紧密的集成，但如果你决定跨引擎共享上下文，迁移会更困难。
模型选择的灵活性
- 尝试新的模型端点有多容易？你能轻松覆盖设置、配置文件和环境变量以指向非原生端点吗？随着每月都有新的尖端开源模型发布，你能否在现有的引擎设置中试用它们，还是需要在不同的引擎中试用？所有模型在引擎中都能同样好地工作吗？
远程访问
- 你可以远程访问会话吗？引擎是否具有内置功能（例如 Claude Code 的 /remote-control），还是你需要安装第三方或社区提供的插件或包装器？如果你合上笔记本电脑，会话仍然可以访问吗？
可观测性/调试界面
- 日志和追踪是如何跟踪的？当出现问题时，你能捕捉到失败模式吗？当它走向错误方向时是否有早期信号？引擎是否具有让你回滚到早期状态并纠正航向的操作，或者更好的是，如果它处于糟糕的状态，它能自我修复吗？
可修改性谱系
- 如果你是为团队或公司做出引擎决策的技术决策者，这是需要提出的关键问题。
- 你也可以将其视为“观点鲜明”与“可组合”之间的权衡。如果一个引擎有更多既定观点，它的摩擦力可能会更小，也更容易在企业中采用——想想 Copilot。但如果它没有既定观点且高度可塑，有很多方法可以推动引擎发挥其潜力，但也可能遇到陷阱（如安全漏洞和极端的令牌消耗）——想想 OpenClaw。
- 如果你身处一个成熟的组织，为团队找到一个带有护栏的观点鲜明选项是正道，尽管这不可避免地会扼杀一些创造力。最佳状态是找到和/或定制一个引擎，使其失败的低谷不是致命的，但生产率的上限是尽可能不受限制的。可组合且可修改的引擎将赋予你（用户）去理顺那些不工作的部分的能力，而不是等待引擎维护者可能在上游做出该更改。
## 未来
随着我们逐步摆脱使用智能进行原型的时代，进入在生产环境中将 AI 推向不同上下文的岁月，这一转变的标志是一个能够支持、路由和编排许多模型的引擎。无论你是个人，采用标准化引擎的团队，甚至是创建新引擎的公司，归根结底都涉及两个相关的决定：你如何路由以及你如何服务。
跨子智能体路由
Karpathy 指出，LLM 的一个怪癖是其智能参差不齐。它们在某些领域可能超越人类，而在其他领域则笨拙不堪。因此，推论是专业化将成为主导范式：使用多个模型并使用独立的子智能体将每个任务路由到适当的模型是合理的。
一种日益普遍且具有战略性的模式是在引擎内部创建动态路由：使用一个轻量级分类器来决定是否应该路由到优秀的开源默认模型以节省成本，路由到针对延迟或吞吐量等性能指标进行微调的模型，还是路由到前沿的闭源模型进行审查。重要的是要关注缓存重用。在多轮会话中，路由到不同的模型可能会导致缓存命中。为了获得最佳速度和成本，引擎架构也应该是缓存感知的，以便请求尽可能击中与给定模型关联的温缓存。
对于调查或研究等只读任务，子智能体可以使用更小、更快的模型。该子智能体（或多个副本）可以被启动以处理专注的、可并行化的任务，例如从多个来源读取并整理有关某个主题的信息。我们看到这种子智能体层的设置对模块化也有益。就像面向对象编程围绕类和封装一样，子智能体是一种提高效率并将工作 compartmentalize 的模式。而且由于上下文腐烂是输出质量下降和幻觉的主要原因之一，独立运行许多模型将保持上下文的清洁。
为性能提供服务
一旦路由到位，每个工作负载都匹配到合适的智能类型，模型本身的性能就与用户体验直接相关。体验由推理本身周围的基础设施决定。
选择正确的引擎固然重要，但为满足你的要求的代理用例选择正确的模型同样关键。例如，GLM 5.2 是质量和性能的绝佳候选者。此外，自带模型引擎或代理为你提供了为任务选择最佳模型-引擎组合的灵活性。我们在 LangChain 的朋友专门为此目的创建了引擎配置文件，你可以在这里阅读相关信息。
无论供应商如何，都值得记住的原则是：性能是引擎-任务匹配度的一部分，而 BYO-model（自带模型）是你控制它的方式。如果你需要保证速率限制、突发处理和正常运行时间，托管你自己的开源或定制模型就是实现这一目标的途径。专用基础设施让你能够控制缓存、批处理和 disaggregation，从而在不牺牲质量的情况下挤出响应速度。我们期望成熟的构建者能够以性能为导向提供服务引擎，并继续寻找沿着这一向量进行优化的方法。
## 最后的想法
引擎并不是一刀切的解决方案，也不应被视为如此。我们探讨了如何从技术和非技术两方面入手进行引擎工程：何时购买，何时定制，以及何时从零开始构建。
与其提供随着引擎的添加和废弃而迅速过时的具体建议，我们分享了一套永恒的问题，帮助你理解并指导你的决策。在很大程度上，最佳引擎的属性将被标准化，最终商品化，这将使所有引擎都直观易用。我敢打赌，将智能路由到正确的模型以及拥有高性能推理将融入到引擎本身中，并随着其发展成为基本要求。
结论应该是选择你的不可谈判条件（例如，因为你有巨大的上下文而需要强大的压缩能力、跨多个模型的可操作性、远程访问等），并熟练使用一个特定的引擎。随着熟练度的提高，你将掌握分叉、修改或命令引擎精确执行你想要的操作的方法。