揭秘ClaudeCode、Cursor、OpenAI智能体工程技术

admin 2026-3-22 05:59 82人围观网络安全

2026年开年以来，Harness工程一词热度渐高，OpenAI在2月发布的一篇详细的内部实验报告标题中使用了此词，ThoughtWorks首席科学家Martin Fowler在X上也表示Harness工程是AI赋能软件开发的关键部分。近日，一位资深全 ...

2026年开年以来，Harness工程一词热度渐高，OpenAI在2月发布的一篇详细的内部实验报告标题中使用了此词，ThoughtWorks首席科学家Martin Fowler在X上也表示Harness工程是AI赋能软件开发的关键部分。

近日，一位资深全栈工程师在X上发布了一篇名为《Harness就是一切：Cursor、Claude Code和Perplexity到底构建了什么》的文章。他将Harness之于Agent，类比于应用商店和开发工具之于移动端、搜索引擎和浏览器之于互联网，认为是目前应用AI领域最核心的工程问题。

有人在文章下方评论：“这是AI领域的下一个千亿级的机会，大多数人会错失，它就是Harness工程。”

无独有偶，在3月18号，MiniMax发布自家第一个模型深度参与迭代自己的M2.7模型时，着重强调了M2.7能够自主构建Agent Harness，完成高度复杂的生产力任务。

以下为万字原文对Harness的详细阐述：

AI用得不好，是因为环境没构建对

你之所以觉得AI用得不对，并不是因为还没找到正确的模型。你用错AI的原因是，你没有构建正确的环境。

这就是为什么有些团队仅凭三名工程师就能交付数百万行代码，而其他团队甚至连让智能体流水线完成一次连贯的重构都困难重重。

这种差距不在于GPT-5与Claude Opus的区别，也不在于温度设置或最大Token数。甚至不在于提示词，尽管每个人都为了提示词争论不休，浪费了数月的人生。

真正的区别在于Harness。

这篇文章将探讨这个词在技术和哲学上的真正含义，因为业界已经养成了一种随意使用它的坏习惯。Harness不是系统提示词，不是API调用的包装器。它不是评测框架、提示词模板，也不是带记忆的聊天机器人。

Harness是语言模型运行的完整设计环境，包括：它可以调用的工具、它接收信息的格式、它历史记录的压缩与管理方式、在错误级联前拦截错误的护栏，以及允许它将工作移交给“未来的自己”而又不丢失连贯性的脚手架。

当你审视Anthropic为使Claude Code真正落地而构建的内容、OpenAI如何通过Codex交付数百万行零人工编写的代码，以及普林斯顿NLP小组在里程碑式的SWE-agent论文中发表的关于“智能体-计算机接口（ACI）”的研究时，你会发现所有严肃对待这一领域的团队都在呈现同一种模式。

模型几乎无关紧要，Harness就是一切。

这是关于该理念如何成为2025和2026年应用AI工程定义类洞察的详细技术分解。它涵盖了研究、实际实现、驱动设计决策的失败模式，以及无论你是在构建编码智能体、研究智能体还是长期运行的自主软件工程师时都会重复出现的模式。

读完本文，你不仅会理解什么是Harness，还会明白为什么正确构建它已成为行业内最有价值的工程技能。

没人讨论的问题

为什么原始能力是不够的

2024年中期，AI基准测试中发生了一件奇怪的事。研究人员发现，同一个前沿模型在相同的编码任务上，由于任务呈现方式和可用工具的不同，会产生截然不同的结果。模型没变，底层的智能没变，改变的是接口。

这本不该让人感到惊讶。几十年来我们都知道，合适的工具能让工程师的生产力产生质的飞跃。一个拥有现代IDE、调试器、版本控制和CI/CD流水线的软件开发人员，其效率比仅在原始终端使用文本编辑器的同一人高出几个数量级。IDE并没有让开发人员变聪明，它只是减少了摩擦、在正确时刻呈现信息、及早发现错误并组织工作单元。

语言模型也是如此。它们并不是基于无限内部知识库工作的通用推理者。它们是运作在上下文窗口中的精密模式匹配引擎。它们在特定时刻所知道的一切，都取决于窗口中的内容；它们产出的一切，都受限于这些上下文的结构。输入格式不是装饰，它是智能体的认知架构。接口不是便利层；对于语言模型智能体来说，接口即思想。

这是普林斯顿NLP小组2024年发表的SWE-agent论文的核心主张，且经受住了推敲。该论文引入了智能体-计算机接口(Agent-Computer Interface,ACI)的概念，并证明了精心设计的ACI与标准Linux Shell相比，能让同一模型在基准测试中的性能产生64%的相对提升。相同的模型，相同的任务，相同的计算预算，变量只有接口。

64%不是边际收益，而是工具“能用”与“不能用”的区别。而这完全源于环境设计，而非底层模型的改进。

上下文窗口不是内存条

关于AI智能体的一种原生模型是将上下文窗口视为RAM（随机存取存储器）。你加载数据，模型处理，然后输出。这种观点认为：更多的上下文等于更好的性能，更长的提示词等于更深的理解。这种观点是错误的，如果你围绕它构建智能体，它会毁了你的工作。

上下文窗口更像是智能体在给定会话中的整个工作意识。窗口中的每个Token都有计算成本。每一条无关信息都会与关键信息争夺注意力。模型并没有一种能干净利落地忽略噪音的选择性注意力机制。噪音就在房间里，它会影响推理。

这对智能体设计有具体且可衡量的后果。当你从智能体循环内部在大型代码库运行grep并返回一万行匹配项时，你并没有给智能体更多信息，而是用无关数据淹没了它的工作记忆，这将降低其后每一步的质量，直到上下文被清除。当你因为智能体想看两个函数就用cat倾倒整个文件时，你是在它需要一杯水的时候给了它一支高压水枪。

SWE-agent的研究人员详细记录了这些失败模式。标准Bash接口会导致智能体“空转”：它们会发布返回数千行的grep命令，忘记自己要找什么，接着发布更多grep，导致上下文充满噪音，最终产生错误答案或停滞不前。问题不在于模型智能，而在于接口没有保护智能体免受其自身伤害的机制。

ACI的解决方案是构建一个有返回上限且能总结的搜索工具。如果搜索返回超过50个匹配项，工具会抑制输出并告诉智能体缩小查询范围。这个回想起来简单得近乎受辱的设计决策，是论文中杠杆率最高的变化之一。它将“上下文淹没”这种失败模式转化为了自然的改进循环。

SWE-Agent论文与ACI的诞生

智能体-计算机接口（ACI）究竟是什么

在SWE-agent论文中，ACI被定义为位于语言模型智能体与计算机环境之间的抽象层。将其类比于人机交互（HCI）是刻意为之的。正如HCI研究如何设计符合人类认知架构的接口一样，ACI研究则探讨如何设计符合语言模型（LM）认知架构的接口。

人类的认知架构涉及视觉模式识别、空间记忆、屏幕上的并行注意，以及略读和选择性关注的能力。LM的认知架构则根本不同：它涉及序列化的Token处理、对上下文顺序和格式的敏感性、有限的工作记忆，以及倾向于锚定在提示词中最显著信息的倾向。设计一个好的ACI意味着理解这些约束并围绕它们进行构建，而不是与其对抗。

用于编码任务的SWE-agent ACI包含四个主要组件，每一个都反映了关于语言模型在获得原始计算机访问权限时如何失败的特定洞察。

搜索与导航

搜索组件用专门构建的工具（`find_file`、`search_file`、`search_dir`）取代了标准的`grep`和`find`命令。关键区别不在于语法，而在于输出管理。结果被限制在50条以内。如果查询超过该限制，工具会返回一条消息，解释结果过多并提示智能体细化搜索。这听起来微不足道，但在实践中，它是该论文中最重要的决策之一。

其之所以重要，是因为智能体和处于认知负荷下的人类一样，当感到不确定时，往往会不断重复正在做的事情。当人类迷失在庞大的代码库中时，他们会搜索得越来越宽泛，产生越来越多的噪音。受限搜索工具通过创造一个“强制函数”中断了这种模式：你不能通过模糊不清来推进工作，你必须变得精确。这推动了智能体采取更深思熟虑、更有针对性的行为。

文件查看器

文件查看器是论文中关于认知架构的洞察变得最具体的地方。研究人员测试了多种查看器配置，发现一次显示100行是一个“恰到好处（Goldilocks）”的数字。显示行数更少（他们测试了30行）会导致智能体丢失周围代码的上下文并产生编辑错误；显示更多行（或全量文件）则会导致智能体迷失所在位置并遗漏重要细节。

查看器是有状态的。它在交互过程中保持在文件中的位置。关键在于，它在每个可见行前都添加了明确的行号。这最后一个细节听起来像是装饰性的，其实不然。当智能体需要发布针对第47到52行的编辑命令时，它需要能够直接从视图中读取这些数字，而不是去数行数或进行算术运算。从智能体的工作记忆中移除这项认知任务，为实际的后续问题解决腾出了空间。

带有Lint检查的文件编辑器

文件编辑器的关键创新是带有护栏的即时反馈。`edit`命令接受起始行、结束行和替换文本作为单一操作。每次编辑后，工具会自动对修改后的文件运行Linter（静态代码检查）并报告结果。如果编辑引入了语法错误，编辑会在应用前被拒绝，智能体将收到一条清晰的错误消息，同时显示原始代码和失败的编辑内容。

这闭合了在原生智能体实现中导致级联故障的反馈循环。如果没有Linter，智能体可能会引入语法错误，然后运行测试套件，看到一个似乎不相关的失败（因为真正的错误在别处），花费多个步骤追查错误的问题，最后在追逐幻影中耗尽其上下文窗口。通过将Linter直接集成到编辑器中，语法错误在引入瞬间就被捕获，修复工作在问题传播前就被局部化了。

对比智能体使用原始bash工具时的情况：使用`sed`或输出重定向时，没有集成反馈，编辑静默执行。多行更改需要复杂的参数格式化，极其容易出错。智能体可能成功运行了命令却引入了细微的格式错误（本可以被Linter捕获），然后接下来的十个步骤都在疑惑为什么测试会失败。