搭建自己的 Harness，值得吗？
几年前，产品工程师还是工程招聘市场上最热门的岗位：既需要具备端到端拥有产品功能的产品直觉，又要具备真正把产品交付出来的技术能力。
接着出现了 AI 工程师，这类人了解模型生态，能驾驭各家服务商，也知道如何在产品中应用 AI。
现在，又一个新头衔开始流行起来。如果你最近几个月关注过 AI 领域的讨论，几乎肯定听到过它：harness 工程师。
不过，harness 工程并非一门新学科。它只是工程杠杆作用自然转移的一个新潮名字——一旦你理解了智能体系统的运作方式，这种转移就会变得显而易见。
1、智能体循环
尽管最近几个月人们对 AI 智能体热情高涨，但构建它们的基础原语却出奇地简单。
第一代 AI 产品极其简单：输入一段提示词，输出一个响应。
接着，随着产品野心越来越大，我们看到了工作流（workflow）的出现：由一连串 LLM 调用组成，用来完成更复杂的任务。它们能力更强，但仍然很僵化。每条执行路径都是预先确定的，因此它们无法适应变化、共享上下文，也无法在此前所学的基础上进一步拓展。
智能体循环改变了这一切。
在智能体循环中，模型并不会被预先规定好每一步，而是被赋予一个目标和一组工具，然后被信任地去独立找出完成任务的方法。对于任何给定的请求，它自行决定调用哪个工具，评估结果，判断任务是否完成——如果完成了就返回答案，否则就重复这个过程。
就是这样。
无论一个智能体运行三十秒还是三十小时，它执行的都正是这个简单得不可思议的循环。
一旦你意识到，每个构建 AI 智能体的团队都在基于这些相同的基础原语工作，一个有趣的问题便自然浮现：
产品差异化究竟从何而来？
2、杠杆在哪里
在一个智能体循环中，你真正能介入的地方其实只有两处。
第一处是在模型本身这一层。你可以尝试各种提示词技巧、评估不同服务商、微调模型，或者投资强化学习。
但模型终究是一个黑箱。你可以影响它的行为，却无法从根本上改变它的推理方式。而且随着前沿模型持续改进，对大多数团队而言，模型定制化的投资回报正越来越低。
所以，剩下的只有模型周围的部分：决定加载哪些上下文、开放哪些工具、什么该放进记忆、如何管理压缩（compaction）、工具执行应该是同步还是异步，等等。
这些决策加在一起，构成了智能体循环周围的编排层。这一层就是 harness，而今天的工程杠杆就在这里。
3、我们的 harness 之旅
上个月，我们发布了 Runneth，这是一个为每位客户在专用云端虚拟机中运行的营销智能体。
如今，Runneth 运行在我们自己的定制 harness 之上。但这并不是我们的起点。
我们的首个实现使用 Claude Agent SDK——正是 Claude Code 背后的同一套引擎。由于我们本来就在 Anthropic 模型上构建，从它入手是顺理成章的选择。它让我们能在不必从零搭建编排层的情况下，快速验证产品。
随着 Runneth 逐渐成熟，我们最终迁移到了 Pi——一个核心极简、插件架构丰富的开源 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?
汇智网翻译整理，转载请标明出处