> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 搭建自己的 Harness，值得吗？ - URL: https://www.hubwiz.com/blog/is-it-worth-to-build-your-won-harness/ - Published: 2026-08-13T13:42:20.000Z - Updated: 2026-10-13T15:21:16.000Z - Description: Harness只是工程杠杆作用自然转移的一个新潮名字——一旦你理解了智能体系统的运作方式，这种转移就会变得显而易见。 - Author: admin - Tags: AGENT, HARNESS ENGINEERING, #Import 2026-10-14 14:41 几年前，产品工程师还是工程招聘市场上最热门的岗位：既需要具备端到端拥有产品功能的产品直觉，又要具备真正把产品交付出来的技术能力。 接着出现了 AI 工程师，这类人了解模型生态，能驾驭各家服务商，也知道如何在产品中应用 AI。 现在，又一个新头衔开始流行起来。如果你最近几个月关注过 AI 领域的讨论，几乎肯定听到过它：**harness 工程师**。 不过，harness 工程并非一门新学科。它只是工程杠杆作用自然转移的一个新潮名字——一旦你理解了智能体系统的运作方式，这种转移就会变得显而易见。 ## **1、智能体循环** 尽管最近几个月人们对 AI 智能体热情高涨，但构建它们的基础原语却出奇地简单。 第一代 AI 产品极其简单：输入一段提示词，输出一个响应。 接着，随着产品野心越来越大，我们看到了工作流（workflow）的出现：由一连串 LLM 调用组成，用来完成更复杂的任务。它们能力更强，但仍然很僵化。每条执行路径都是预先确定的，因此它们无法适应变化、共享上下文，也无法在此前所学的基础上进一步拓展。 智能体循环改变了这一切。 在智能体循环中，模型并不会被预先规定好每一步，而是被赋予一个目标和一组工具，然后被信任地去独立找出完成任务的方法。对于任何给定的请求，它自行决定调用哪个工具，评估结果，判断任务是否完成——如果完成了就返回答案，否则就重复这个过程。 ![](https://www.hubwiz.com/blog/content/images/2026/08/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F1fe6f86c-7570-4f68-9f57-ceccc26a3866_2561x873.png) **就是这样。** 无论一个智能体运行三十秒还是三十小时，它执行的都正是这个简单得不可思议的循环。 一旦你意识到，每个构建 AI 智能体的团队都在基于这些相同的基础原语工作，一个有趣的问题便自然浮现： *产品差异化究竟从何而来？* ## **2、杠杆在哪里** 在一个智能体循环中，你真正能介入的地方其实只有两处。 第一处是在模型本身这一层。你可以尝试各种提示词技巧、评估不同服务商、微调模型，或者投资强化学习。 但模型终究是一个黑箱。你可以影响它的行为，却无法从根本上改变它的推理方式。而且随着前沿模型持续改进，对大多数团队而言，模型定制化的投资回报正越来越低。 所以，剩下的只有模型周围的部分：决定加载哪些上下文、开放哪些工具、什么该放进记忆、如何管理压缩（compaction）、工具执行应该是同步还是异步，等等。 这些决策加在一起，构成了智能体循环周围的编排层。**这一层就是 harness，而今天的工程杠杆就在这里。** ![](https://www.hubwiz.com/blog/content/images/2026/08/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F5a97045e-c17d-4464-a40c-5598df7b6601_2609x1519.png) ## **3、我们的 harness 之旅** 上个月，我们发布了 [Runneth](https://runneth.com/?ref=hubwiz.com)，这是一个为每位客户在专用云端虚拟机中运行的营销智能体。 ![](https://www.hubwiz.com/blog/content/images/2026/08/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F5f38d6ac-1bac-4040-b427-cd01a3c74745_1598x912.png) 如今，Runneth 运行在我们自己的定制 harness 之上。但这并不是我们的起点。 我们的首个实现使用 [Claude Agent SDK](https://code.claude.com/docs/en/agent-sdk/overview?ref=hubwiz.com)——正是 Claude Code 背后的同一套引擎。由于我们本来就在 Anthropic 模型上构建，从它入手是顺理成章的选择。它让我们能在不必从零搭建编排层的情况下，快速验证产品。 随着 Runneth 逐渐成熟，我们最终迁移到了 [Pi](https://pi.dev/?ref=hubwiz.com)——一个核心极简、插件架构丰富的开源 harness——因为它更契合我们的需求。它在可扩展性、上下文管理和编排等方面做出的不同决策，与我们正在构建的产品更加一致。 不过，我们仍然遇到了几类反复出现的痛点： - **固执的默认设定**：每个开源 harness 都会对其智能体循环的运作方式做出独特的架构决策。这些默认设定对它们所面向的用例是合理的，但不一定是我们自己会做的选择。即便是 Pi 这种刻意保持极简的架构，仍然内置了一些我们希望能定制化的核心假设。 - **延迟**：智能体循环的每一圈都要花费时间，而并不是每个请求都需要多次迭代。我们智能体的很多请求都遵循可预测的模式，所需的上下文、工具和执行路径早已明确。如果无法对循环进行更深入的控制，就没有干净的方法跳过不必要的推理步骤，这会给那些本可更高效处理的请求带来延迟。 - **成本**：大多数流行的 harness 都设计为本地运行，在那里计算成本并不是约束。但我们的环境大不相同。因为我们的智能体运行在虚拟机中，内存和计算会直接转化为基础设施成本。Pi 每个会话大约占用 100 MB 内存，当你并发运行数百个会话时，这笔开销很快就会累积起来。 我们与 Anthropic 团队讨论了这些挑战，他们的建议很明确： **尝试自己构建一个 harness。** 于是我们照做了。 我们分析了能找到的所有开源 harness 的源码，比较了每个 harness 所做的架构决策。在此基础上，我们借鉴了他人行之有效的做法，设计了自己的 harness，并用 Rust 构建，以利用它在内存效率、无运行时开销、性能和安全性方面的优势。 ## **4、拥有 harness 为我们解锁了什么** 我们的 harness 还很新，但早期结果令人振奋。我们已经把每个会话的内存占用从约 100 MB 降到了约 10 MB，并且在许多方面获得了显著的掌控力，例如： - **提示词增强**：对于已经充分理解的模式，我们现在可以在模型看到请求之前就拦截它，对其进行增强、替换、注入领域特定上下文、预选执行路径，或以其他方式优化处理方式。 - **学习提取**：当用户纠正模型的输出时，我们的 harness 会捕获这些纠正并存储起来。当遇到语义相似的请求时，这些经验会被自动套用。 - **分离式工具执行**：许多 harness 在工具执行时会阻塞。智能体调用一个工具，等待它完成，然后继续推理。这对短时操作没问题，但在我们的虚拟机环境中，有些命令可能要运行好几分钟。与其让智能体空转，我们的 harness 会把耗时较长的工具调用分离出来，异步轮询它们，让执行得以并行继续。 - **多人协作**：现成的 harness 都为在隔离环境中独自工作的单个用户设计。因此，协作需要在各自独立的智能体之间不断来回搬运上下文和反馈，每一次都相当于从零开始。我们的 harness 支持多个用户在同一虚拟机上协作，意味着整个团队可以在同一环境、同一批文件上工作，共享记忆和对话历史。 - **权限控制**：为了支持多个用户共享一台虚拟机，harness 必须可靠地区分他们。与我们不采用在系统提示词中指定用户身份的做法不同，我们的 harness 把用户身份硬编码到每一次工具调用中，使权限执行具有确定性。而且由于我们的虚拟机运行 Linux，我们还把每个用户直接映射到 Unix 权限系统，因此在操作系统层面强制执行读、写、执行权限。这为我们提供了安全可靠的多用户访问基础。 ## **5、权衡取舍** 读到这儿，你可能会忍不住得出结论：每个智能体团队都应该尝试自己构建 harness。 但事实并非如此。 构建一个定制 harness 是一项巨大的投入。你会继承开源框架已经解决的所有挑战：工具执行、上下文管理、记忆压缩、可观测性、调试、测试，以及无数只有当智能体上线运行后才会暴露出来的边缘情况。 对很多团队来说，这个权衡并不划算。 如果你的产品能很好地契合某个现有 harness 的假设，那么在它之上构建几乎肯定比从零开始更明智。也就是说，对很多团队而言，搭配精心设计的工具和技能（skills）的 Claude Agent SDK 就足够了；而对另一些团队来说，插件丰富的 Pi 会是绝佳选择。 不过对我们而言，这是一场值得下的赌注。随着时间推移，拥有 harness 所带来的好处逐渐超过了构建它的成本。 --- 原文链接：[We built our own custom harness, was it worth it?](https://motionengineering.substack.com/p/we-built-our-own-custom-harness-was) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)