强化智能优先：企业为何仍需依赖人类智慧？
如果你并非从事软件开发，在会议或董事会上，你或许曾被问及：“我们要如何落地 AI？如何真正实现投资回报？”全球都在寻找答案，但答案依旧难以捉摸。近期 AI 工程学的突破与往昔的经验教训，有助于我们构建切实可行的方案。
在探讨方案前，必须正视现状。迄今为止，多数 AI 基准测试对该领域而言是一种尴尬的沉默。模型在标准化考试、法考及学术数据集上常能取得近乎完美的成绩，却在真实的专业场景中表现欠佳。缘由很简单：基准测试考查的是模型记忆了什么，而非它能做什么——这被称为“数据污染”，即模型在训练阶段已看过答案。Mercor 的 APEX 基准系列则是一个重大突破。Mercor 未依赖教科书或公共数据集，而是招募领域专家——投行分析师、管理顾问、大所律师及初级保健医生——根据日常工作定制任务。这些贡献者平均拥有七年以上经验，其专家主导的设计成为输出质量的标杆。因任务源自私有专业场景（真实客户交付物、实际案卷），模型单纯靠记忆答案的可能性大幅降低。这些任务包含多步骤，缺乏可编程结构，要求从业者反思方法，利用记忆与专业知识，并在复杂问题上交付高质量成果。
启用深度思考后，各模型在 APEX-v1-extended 排行榜上的平均得分。
这些更具现实意义的任务揭示了什么？表现最佳的模型 GPT-5 在开启高推理模式下，平均得分为 67.0%。在投资银行任务（最难的领域）中，最高得分降至 63.0%，由 Gemini 3 Pro 获得。这些并非灾难性的失败，但当标准是专家平均每项任务花费 2.7 小时精心制作的专业级输出时，这代表了显著的差距。
| Model | Provider | Overall | Invest. banking | Law | Mgmt. consulting | Medicine | |-----------------------|------------|-----------|-------------------|-------|--------------------|------------| | Opus 4.5 (On) | Anthropic | 63.1% | 55.2% | 74.0% | 58.4% | 64.6% | | Sonnet 4.5 (On) | Anthropic | 57.2% | 45.7% | 72.4% | 50.7% | 59.6% | | Opus 4.1 (On) | Anthropic | 51.4% | 42.0% | 61.8% | 49.4% | 52.1% | | Gemini 3 Pro (High) | Google | 64.3% | 63.0% | 68.5% | 64.0% | 61.6% | | Gemini 2.5 Pro (On) | Google | 59.4% | 54.1% | 68.5% | 58.9% | 55.8% | | Gemini 2.5 Flash (On) | Google | 57.3% | 51.1% | 68.8% | 55.6% | 53.6% | | GPT 5.1 (High) | OpenAI | 59.4% | 44.3% | 77.4% | 51.9% | 64.0% | | GPT 5 (High) | OpenAI | 67.0% | 61.3% | 77.9% | 63.1% | 65.5% | | o3 (On) | OpenAI | 63.5% | 57.7% | 75.5% | 59.0% | 61.5% | | Grok 4 | xAI | 63.5% | 59.6% | 70.2% | 59.8% | 64.3% |
具有讽刺意味的是，当赋予 AI 代理权——即不仅限于问答，还能跨步骤行动、规划与执行——情况会变得更糟。APEX-Agents 将此框架用于代理系统，要求模型像处理现场业务的人类分析师一样，操作真实文件系统、使用软件工具并做长周期规划。在此，领先的模型 Gemini 3 Flash 和 GPT-5.2 在 Pass@1 基准下得分仅分别为 24.0% 和 23.0%，Claude Opus 4.5 和 Gemini 3 Pro 均为 18.4%。模型不仅远逊于专业人士，赋予更多自主权反而令表现更差，而非更好。
APEX-Agents 在各工作领域的得分。
考虑到备受关注的编码代理，人们或许认为前沿模型在软件工程方面表现尚可。但 APEX-SWE 揭示了另一面。与 SWE-Bench（专注于单一仓库 Bug 修复，极度饱和及污染，前沿模型仅凭任务 ID 即可逐字复现，得分超 75%）不同，APEX-SWE 测试的是工程师实际耗时最多的工作：集成（连接异构云系统）与可观测性（从日志等调试生产故障）。这些活动占工程师非写码时间的大部分。发布时，Claude Opus 4.6 以 40.5% 领跑 APEX-SWE，GPT-5.3 Codex 以 41.5% 夺冠。这三个基准呈现的模式一致：任务越贴近真实专业工作——多步骤、模糊、依赖上下文、植根私有系统——AI 越吃力。
这引发了一种不安的张力。上述基准不仅揭示性能差距，更暴露了叙事差距。过去几年，围绕 AI 的主流叙事是“即将被取代”：我们正将智力劳动移交机器，只需坐享其成。正如 Neil Postman 在《娱乐至死》中对赫胥黎愿景的解读：“人们会爱上压迫，崇拜那些抵消他们思考能力的技术。”这种渴望是消极的——视 AI 为思考的替代品。然而，基准测试表明实践截然不同。AI 并未抵消思考能力，反而要求更高。更好的问题不是“如何将任务交给 AI”，而是“如何设计系统，让 AI 与人类判断在各自擅长的领域发挥最佳作用？”
这种性能差距存在结构性原因，与抽象的模型智能无关。它取决于语言模型处理信息的方式。HumanLayer 创始人 Dexter Horthy 用“愚笨区”概念描述此问题。简单来说，语言模型有有限上下文窗口（如 Claude Code 约 20 万 token，可用约 16.8 万）。填满后，性能并非优雅降级，而是显著恶化。Horthy 经验法则（Geoffrey Huntley 确认）：约 40%–60% 处，边际收益递减。操作后半部分即进入“愚笨区”：模型对自身工作记忆的推理能力被噪声、无关信息及累积先验上下文权重破坏。不仅是词汇检索，更是对模糊任务的语义理解。让我们来看看导致这种注意力丧失的一些机制。首先，“上下文腐烂”表明 Prompt 变长，生成质量急剧下降。像 NoLiMa 这样更具针对性的基准测试证实，即使任务完全在模型的上下文限制内，如果相关信息分布在 Prompt 各处而非集中在一处，表现也会受损——关键是，当它需要潜在的关联推理而非简单的字面匹配时，情况尤为严重。这不仅是一个小麻烦。它是代理式 AI 系统在复杂任务中失败的根本原因之一。一个处理多步骤企业工作流的长期运行代理不可避免地会积累上下文：先前的工具输出、失败的尝试、纠正指令、中间文档。窗口被填满，性能下降。由于语言模型核心是“无状态”的——它们唯一的“记忆”就是当前存在于上下文窗口中的内容——模型本身没有恢复机制。这种失败模式还有一个纯数学维度。如果模型在单个步骤上达到 90% 的准确率，一个五步的自主工作流复合准确率约为 59%——这还假设每一步都是独立的。在实践中，实际的复合率更糟。上下文腐烂和复合错误级联并不是相互竞争的解释，而是相互强化的，它们共同解释了 APEX-Agents 的结果。更严重的是一个更微妙的问题，表现为“轨迹污染”。模型会根据完整上下文预测最可能的后续内容，而在一个充斥着错误纠正循环的上下文中，统计上更有利于产生呼应这些后续错误的预测，这是直接的自回归统计结果。正如 Horthy 所指出的，不主动管理轨迹的从业者肯定会得到更差的输出。上下文窗口不仅承载信息，还承载着行为惯性。
工程界一直在应用层面汇集一套互补的实践来驯服这个问题。Mitchell Hashimoto 将这些实践命名为“治理工程”——这是一门配置、定制并刻意约束编码代理的上下文窗口和集成点，以最大化其输出质量的综合学科。这里的核心见解是反直觉的：停止使用概率性的自然语言进行控制流管理，转而使用确定性的路由。从这一学科中产生并被最广泛采用的工作流是 HumanLayer 团队所称的“频繁有意压缩”。这种工作流不是让代理在单个庞大的上下文中处理复杂任务，而是刻意将工作划分为三个压缩阶段：研究-计划-执行 (Research-Plan-Implement, RPI)。研究阶段使用全新的、极简的上下文窗口来收集关于代码库或问题的客观信息——刻意不让其知道将要构建什么，以防止模型向预定解决方案进行模式匹配。计划阶段获取该研究文档，并生成详细的、针对特定文件的执行计划，包含具体的代码片段、测试标准和供人类审阅的明确设计问题。只有在那之后，执行阶段才会开始，使用包含计划、特定目标文件且几乎没有其他内容的精简上下文。这里关键的哲学点——也是采用 RPI 的团队最常误解的一点——是，这并不是一种将人类排除在环路之外的方法。这是一种让人类在最高杠杆点保持参与的方法：审阅设计、回答开放性问题、在错误传播到数百行代码之前发现偏差。正如 Horthy 所说：“一行坏代码就是一行坏代码；一行坏的研究可能导致一百行坏代码。你不应该外包思考。”此外还有一个务实的经济维度。RPI 的每个阶段都在精简的、专用上下文窗口内运行，这直接转化为每项任务消耗更少的 token。对于每天运行数百个代理会话的企业来说，一个庞大的 200,000 token 上下文与三个集中的 30,000 到 50,000 token 上下文之间的区别并非小事；它是可行运营成本与不可持续成本之间的区别。RPI 提供了一个纪律严明的替代方案：以更低的成本获得更好的结果，正是因为它将上下文视为稀缺资源而非无限的画布。RPI 和治理工程在“棕地”环境中最具价值——即现有的代码库、遗留系统、复杂的跨仓库架构，在这些环境中，上下文很快就会被冲突的历史信息污染。这并不是说单个精简的上下文窗口就能捕捉遗留系统的全部纠葛——研究阶段本身可能涉及多个子代理探索，每个子代理针对依赖关系和副作用的特定问题，然后将发现压缩到单个文档中。这种纪律在于压缩，而不是假装问题很简单。对于“绿地”项目（没有先前代码可研究，也没有现有模式可对齐），大多数前沿模型都足够聪明，可以在干净、极简的上下文中处理定义明确的任务。难点——以及企业 ROI 问题所在——在于棕地环境。Vercel 工程团队的一个例子说明了这一点，他们花了数月时间构建了一个复杂的 Text-to-SQL 代理，结果发现让 Claude 直接访问他们结构良好的语义层文件，表现优于他们构建的复杂 Pipeline。然而，他们的结论非常精准：这种方法之所以奏效，是因为他们的语义层已经有了完善的文档和一致的命名。如果底层数据层充斥着遗留命名规范和未记录的 Join，再智能的访问也无济于事——你只会更快地得到错误的查询。
研究、计划、执行工作流
但问题依然存在：在技术上，如何调查开始治理工程所需的数 TB 企业信息？最有前景的研究级回应之一来自 MIT CSAIL 2026 年 1 月的一篇论文。递归语言模型不是将长 Prompt 直接喂给神经网络并依赖长上下文方法解决记忆问题，而是将 Prompt 视为外部环境的一部分——一个存储在持久 Read-Eval-Print Loop (REPL) 中的变量。模型随后可以通过代码和对自身的子调用，以编程方式检查、分块、过滤和递归查询该环境的各个部分。在任何给定时间，只有固定大小的元数据占据活动上下文窗口，这意味着无论底层语料库有多大，模型永远不会在“愚笨区”运行。结果令人震惊。RLM 在 1000 万+ token 规模上表现强劲——比当前任何前沿模型的上下文窗口高出两个数量级——并且在长上下文任务上显著优于所有测试的基准模型，通常在成本相当或更低的情况下领先两位数。此外，RLM 经常表现出与人类研究员数世纪以来工作方式相似的涌现行为：通过模式匹配（正则查询）进行过滤、按逻辑边界对文档分块，以及在持久 REPL 上缝合来自并行子调用的输出。AI 社区正以一种自然的方式重新发现认识论的纪律——搜索、沉思、验证假设、提炼、再次搜索、跨源三角定位、测试——只不过在 LLM 的世界里，这主要表现为智能的 grep 和符号递归。然而值得注意的是，目前展示的 RLM 是在结构良好的语料库上运行的，那里的程序化搜索是可靠的。在更混乱的企业数据领域——非结构化文档、不一致的 Schema、未记录的 Join——RLM 优雅的递归会遭遇困扰其他所有方法的数据质量问题。模型只能 grep 那些可以被 grep 的内容。为了让 RLM 范式在企业环境中兑现承诺，底层数据层必须首先变得可导航。
这一切引发了一个显而易见的问题：如果模型、基准测试和工程实践都在同步改进，为什么企业 AI 感觉仍然像是一个转瞬即逝的实验，而不是一种变革力量？答案有一个精确的历史先例。斯坦福大学经济史学家 Paul David 在 1990 年写了一篇具有里程碑意义的论文——《发电机与计算机：现代生产力悖论的历史视角》，他在文中记录了一个世纪前几乎完全平行的案例。Robert Solow 曾在 1987 年著名地指出：“我们到处都能看到计算机，唯独在生产力统计数据中看不到。”David 表明这种悖论并不新鲜：在 1900 年，当时的观察者对电动机（发电机）也可以做出完全相同的评论，电动机当时已商业化近二十年，却仍未产生明显的生产力激增。在这两个案例中，原因都是一样的。工厂在物理组织上是围绕中心化蒸汽动力的逻辑构建的：一台巨大的发动机驱动一个由架空轴和皮带组成的网络，工作站围绕该中心脊柱排列。将蒸汽机更换为电动机，同时保持工厂布局不变，几乎无法发挥这项技术的潜力。正如 David 所记录的，工厂电气化直到 1920 年代初才达到全盛——那是爱迪生 1881 年开设第一座中心电站四十年后——这仅仅是因为工程师和经理们学会了从底层重新设计工厂，为每台机器分配独立的电动机（即所谓的“单元驱动”系统），重新安排工作流以提高灵活性，并从根本上重新思考工作的组织方式。当生产力提升最终到来时，其规模是巨大的：1919-29 年间美国制造业全要素生产力增长率 5 个百分点的加速中，统计上约有一半可归因于那十年间分布式电动机容量的增长。当今企业界中的“蒸汽机”就是遗留系统：由 COBOL 运行的大型机、二十个命名规范不一致的去中心化数据源、数十年来积累的未记录业务逻辑。部署在这些基础设施之上的 AI 表现将不尽如人意——不是因为模型不聪明，而是因为从开始运行的那一刻起，它的上下文窗口就会被矛盾、陈旧且结构不连贯的信息填满。再多的 Prompt 工程也无法补偿糟糕的数据层。正如发电机历史所暗示的，前进的道路将是漫长的，且远非自动完成。它需要从底层重新设计组织的信息架构——即使在技术层面有了治理工程，更广泛的组织复杂性也要求进行远超单一工程学科的变革。治理工程不能替代枯燥的数据治理工作——清理命名规范、记录 Join、整合 Schema。治理工具运行在数据层之上；如果数据层是不连贯的，治理工具就会继承这种不连贯。两者是互补的：数据工程决定模型看到什么；治理工程决定它看到的内容是否值得看。正如我们所主张的，增强智能范式可能是加速这两者的最实际方法——利用 AI 让旧工厂变得足够清晰，以便进行重新设计。
这一切对短期战略意味着什么？诚实的答案是——虽然很少被明确表达——产生最直接企业价值的并不是人工智能（即自主系统取代人类判断），而是我们更准确称之为“增强智能”的东西：AI 作为一个工具，在特定的、定义明确的杠杆点放大人类能力，而人类判断在真正关键的地方保持参与。最能立即解决的工作流是那些高成本、高度手动且结构定义良好的工作流：数据对账、文档草拟、代码审查、初步研究综合、监管报告。这些活动消耗了大量的专业时间，却不需要使人类专业知识真正不可替代的判断力、创造力或责任感。为什么不从那里开始呢？此外，如果我们认真对待杰文斯悖论，自动化这些低判断任务将增加对它们或其更高级变体的需求。这根本不是悖论：当分析成本下降时，组织会委托更多的分析。当初步监管审查只需几分钟而非几小时时，公司会进行以前跳过的审查。总工作量会扩大，随之而来的是对能够监督、解释并在更高复杂性水平上根据输出采取行动的人类专业人士的需求。另一方面，这种动态可以帮助解决特定的人才问题——更重要的是，它直接连接到我们上面确定的数据工程挑战。那些掌握着处理每日数万亿美元交易系统的稀有遗留系统专家，不必成为组织永久的负担。如果 AI 基础设施和数据层构建得当，这些制度性知识可以被逐步编码、记录，并使运行在其上的代理能够导航。这就是应用于“发电机问题”本身的增强智能：利用 AI 记录未记录的 COBOL 系统，从数十年前的代码中逆向工程业务逻辑，映射使遗留数据层如此险恶的命名规范和隐藏依赖。人类专家仍然做出架构决策——保留什么、淘汰什么、如何重组——但 AI 加速了这一过程。今天在治理工程和数据架构上的正确投资，不仅是让 AI 在当下运行得更好的方法；它也是解决人才问题最务实的答案，是通往 Paul David 历史告诉我们不可避免的组织重构的最快路径。从长远来看，随着 AI 集成到企业信息栈的每一层——一旦治理工程不再是一个项目，而是系统中内置的假设——行业将为一种完全不同的范式做好准备：AI 不再是生产力工具，而是操作系统。在这个基础上，人类监督和代理工作流是刻意的设计选择，而非对模型局限性的妥协；它在人类判断真正不可替代的地方利用人类判断，并在其他所有地方部署 AI。电气化工厂并没有消灭工人。它改变了工作的意义——而实现这一目标花了四十年时间。正如 Postman 警告的那样，危险不在于技术会从外部压迫我们，而在于我们会如此盲目地爱上它，以至于停止仔细思考如何用好它。前进的道路恰恰需要相反的东西：更多的人类思考、更仔细的设计，以及对 AI 目前能做和不能做的事情有更清醒的认识。
这里有一个显而易见的诱惑：如果模型周围的治理（Harness）如此重要，为什么不使用 AI 来优化治理本身呢？即刻的反对意见同样显而易见——如果底层模型容易出现推理错误和上下文腐烂，使用同样有缺陷的推理引擎来工程化其自身的上下文，只是将幻觉提升了一个层级。这是“蛇吞尾”问题，而且是真实存在的。但最近的研究表明，情况更为微妙。斯坦福、MIT 和 KRAFTON 2026 年 3 月的一篇论文介绍了 Meta-Harness：一个自动化的外环，用于搜索 LLM 应用的治理代码。直觉是，如果治理能在同一基准测试上产生 6 倍的性能差距，那么寻找最佳治理本身就是一个值得自动化的显著工程问题。结果令人印象深刻：在文本分类上，Meta-Harness 比手工设计的先进系统提高了 7.7 分，同时减少了 4 倍的上下文 token 消耗；在检索增强推理上，单个发现的治理提高了五个留出模型的准确率；在竞争激烈的 TerminalBench-2 代理编码基准测试中，发现的治理超过了所有手工工程的基准。这告诉我们治理工程的未来值得深思。Meta-Harness 表明，这一演进的下一步可能是 AI 辅助的治理优化：系统从自身先前的失败中学习足够的诊断细节，以提出针对性的改进。上下文工程的技艺本身正成为自动化的目标。然而，Meta-Harness 并没有消除人类的工作；它将工作重新组织到了更高的元层级——因为像 AI 对齐这样的一些 LLM 问题，仍是尚未解决的棘手技术挑战。