[{"content":"引言 2026 年初，一个新术语席卷了 AI 工程界——Harness Engineering（Harness 工程）。它不是又一个营销概念，而是对过去四年 AI 工程实践的一次系统性总结：当我们不再满足于\u0026quot;写一个好 prompt\u0026quot;，而是需要构建一个让 AI Agent 可靠、安全、经济地完成复杂任务的完整系统时，Harness Engineering 就是那个系统工程学科的名字。\n本文将从起源讲起，沿着 Prompt → Context → Harness 的演进主线，深入拆解 Harness 的核心原理，分析当前八大难点，并梳理 Anthropic、OpenAI、Google、Cursor 等厂商的解决方案。\n一、什么是 Harness？ 1.1 一个公式 2026 年 2 月，LangChain 的 Vivek Trivedy 给出了被广泛引用的公式：\nAgent = Model + Harness\n如果你不是模型本身，那你就是 Harness。\n裸的 LLM 只是一个无状态的文本补全引擎——它没有记忆、不能执行动作、无法跨会话持续工作。Harness 是赋予模型行动能力、状态持久化、工具调用、验证循环和安全治理的完整运行时基础设施层。它不让模型变得更聪明，而是让失败变得结构性不可能或可恢复。\n1.2 Harness 与 Prompt 的本质区别 层次 作用域 控制什么 Prompt Engineering 单次模型调用 输入字符串——措辞、示例、指令 Context Engineering 单个上下文窗口 模型看到的信息——RAG 结果、对话历史、工具定义 Harness Engineering 整个运行环境 工具执行、状态持久化、验证循环、记忆、权限、多会话协调 一个类比：在 prompt 里告诉 Agent\u0026quot;请遵循我们的编码规范\u0026quot;是概率性的合规；在 Harness 里接入一个 linter 来阻止不合规的 PR 是确定性的执行。Prompt 告诉 Agent 做什么，Harness 控制它能不能做、怎么做。\n1.3 词源 \u0026ldquo;Harness\u0026quot;源自马具——缰绳、嚼铁、鞍座——将马的原始力量引导到有用的方向。LLM 就是那匹马：强大而快速，但没有 Harness 就毫无方向。在软件领域，\u0026ldquo;test harness\u0026rdquo;（测试线束）的概念由来已久——一个可控的、可观测的、可验证的执行环境。AI Agent Harness 继承了这一核心思想。\n二、从 Prompt 到 Harness：演进史 Phase 1：Prompt Engineering（2020–2024） 起点：2020 年，GPT-3 发布，Brown et al. 证明了 few-shot learning——通过在 prompt 中给出几个示例，LLM 就能适应新任务。\u0026ldquo;Prompt engineering\u0026quot;这个术语由 Gwern Branwen 首先使用，随后在 2022 年 ChatGPT 爆发后成为主流。\n关键技术里程碑：\n2022 — Chain-of-Thought（Wei et al., Google）：发现让模型\u0026quot;一步步思考\u0026quot;能显著提升多步推理能力。这是第一个系统性的证据——prompt 的形式塑造推理的过程，而不仅仅是输出。 2022 — ReAct（Yao et al.）：提出 Thought → Action → Observation 循环——模型在推理和工具调用之间交替。这建立了 Agent Loop 的原型架构，几乎所有现代 Agent Harness 的基础都是 ReAct 的变体。 2023 — Toolformer（Schick et al., Meta）：证明 LLM 可以自主学习何时、如何调用外部工具。工具使用从 Harness 强加行为变成了模型的一等能力。 2023 — OpenAI Function Calling + AutoGPT + LangChain：Function Calling API 让结构化工具调用变得实用；AutoGPT 和 BabyAGI 展示（也压力测试了）开放式自主 Agent；LangChain 提供了模块化框架。这个阶段暴露了无 Harness Agent 的核心失败模式：无限循环、上下文爆炸、不可恢复的失败。 Prompt Engineering 的致命缺陷：\n脆弱——上游模型的微小变化就能打破精心设计的 prompt 概率性合规，而非确定性保证 无法从任务中途的错误中恢复 无法处理多步骤任务或跨会话状态 Phase 2：Context Engineering（2025） 定义时刻：2025 年 6 月，Shopify 创始人 Tobi Lütke 在 X 上提出\u0026quot;context engineering\u0026quot;比\u0026quot;prompt engineering\u0026quot;更准确地描述了核心技能。一周后，Andrej Karpathy 给出了被广泛引用的定义：\n\u0026ldquo;用恰到好处的信息填充上下文窗口的精妙艺术与科学。\u0026rdquo;\n范式转变：从优化单条 prompt 转向架构模型看到的信息——RAG 管道、对话历史管理、工具定义、结构化记忆。瓶颈从措辞转向信息。\nContext Engineering 的不足：\n拥有良好上下文的 Agent 仍然在规模化使用时不可预测地失败 上下文窗口是有限的；复杂任务跨越多个窗口 无法从灾难性的中途失败中恢复 \u0026ldquo;上下文焦虑\u0026rdquo;——模型在上下文快满时会过早地结束任务 指令完美、上下文充分的 Agent 仍可能执行危险命令 Phase 3：Harness Engineering（2026–至今） 范式转变：不再试图通过指令让模型表现更好，而是工程化环境使不良行为在结构上不可能或可被结构性纠正。Harness 是道路、护栏、交通系统——不只是方向指引。\n三者是嵌套关系：Harness Engineering ⊃ Context Engineering ⊃ Prompt Engineering。每一层增加了作用域，但不消除前一层。\n三、命名时刻：2026 年 2 月 \u0026ldquo;Harness Engineering\u0026quot;作为一个命名学科，在 2026 年 2 月的两周内结晶：\nMitchell Hashimoto（2 月 5 日） HashiCorp 联合创始人、Terraform 和 Ghostty 的作者，在博客 My AI Adoption Journey 中描述了他在用 AI Agent 构建 Ghostty 时发展出的实践：\n\u0026ldquo;每当你发现 Agent 犯了一个错误，你就花时间工程化一个解决方案，使这个 Agent 永远不会再犯同样的错误。\u0026rdquo;\n他给这个实践命名为 \u0026ldquo;engineer the harness\u0026rdquo;，并在文中坦承自己不确定业界是否已有对应术语。实践中，这意味着在 AGENTS.md 中积累规则、为每个失败编写验证脚本，直到错误在结构上不可重复。\nRyan Lopopolo / OpenAI（2 月 11 日） 发表了 OpenAI Frontier 团队如何用 Codex Agent 交付超过一百万行代码、1500+ PR、零人工编写和零人工审查的文章。当 Agent 失败时，团队问的不是\u0026quot;如何更好地 prompt 它\u0026rdquo;，而是\u0026quot;环境中缺少什么能力、上下文或结构？\u0026rdquo;\nLopopolo 后来在 Latent Space 播客（4 月 7 日）中亮相，标题是 \u0026ldquo;Extreme Harness Engineering for Token Billionaires\u0026rdquo;。\nVivek Trivedy / LangChain（2 月 17 日） 发表 \u0026ldquo;Improving Deep Agents with Harness Engineering\u0026rdquo;——被广泛认为是给这个术语赋予正式分类体系并推广到业界的文章。他展示了 LangChain 的编码 Agent 仅通过修改 Harness（不换模型）就从 Terminal Bench 2.0 的 Top 30 跃升至 Top 5。他提出了经典公式\u0026quot;Agent = Model + Harness\u0026quot;并定义：\u0026ldquo;如果你不是模型，你就是 Harness。\u0026rdquo;\n后续文章 The Anatomy of an Agent Harness 在 X 上获得 73.3 万次浏览和 4800 次收藏。\nBirgitta Böckeler / Martin Fowler（2 月 17 日） 在 Fowler 的\u0026quot;Exploring Gen AI\u0026quot;系列中发表 Harness Engineering 备忘录，引入 Guides（前馈控制） 和 Sensors（反馈控制） 框架，两者可以是计算性的或推理性的，并提出 Harness Templates 概念——在组织内共享通用的 Guides 和 Sensors 配置。\n归属共识：Mitchell Hashimoto 命名了它（2 月 5 日）；Viv Trivedy 定义和分类了它（2 月 17 日）；两人共同将这个术语推入普遍使用。\n四、深入拆解 Harness 原理 4.1 核心组件 学术界和工业界对 Harness 的核心组件已形成收敛共识。一篇 2025–2026 的综述论文提出了 ETCLOVG 分类法——七个必要且充分的层：\n层 名称 职责 E Execution（执行基底） 工具动作物理运行的环境——沙箱子进程、Docker 容器、Rust 沙箱 T Tool（工具接口） JSON Schema 格式的工具定义、工具注册表、MCP 协议 C Context（上下文管理） 每一步上下文窗口的内容——压缩、缓存、滚动摘要 L Lifecycle（生命周期/编排） Agent Loop 的控制流——ReAct 循环、终止条件、子 Agent 调度 O Observability（可观测性） 每次模型调用、工具调用、观测的追踪和日志 V Verification（验证） Linter、类型检查、测试运行器、自我批评——确定性传感器 G Governance（治理） 权限分层、沙箱、审批门控、安全规则 4.2 Agent 控制循环 主流架构是 ReAct（Reasoning + Acting）：\nThought → Action → Observation → Thought → … → Final Answer Thought：模型输出显式推理——解释当前状态，决定下一步 Action：工具调用。现代系统使用原生 function calling（结构化 JSON），而非文本解析 Observation：工具返回值，追加到对话历史并重新呈现给模型 Termination：\u0026ldquo;Final Answer\u0026quot;信号或最大步骤预算 以 Claude Code 为例，其六阶段控制循环：\n初始化 → 上下文构建 → LLM 调用 → 决策路由 → 收集工具结果 → 溢出检查 ↑ ↓ ←←←←←←←←←←←←←← 若未溢出，循环回上下文构建 ←←←←←←←←←←←←← 若溢出，触发 Context Compaction 当模型同时请求多个工具时，生产级 Harness 会进行依赖分析（这些工具能否并行？）和资源约束（最多多少并发进程？）。\n4.3 上下文管理与压缩 上下文窗口是 Agent 的核心资源约束。一个 SWE-bench 任务的长编码会话通常跨越数百万 token——Qwen3-Coder-Next 平均每个问题消耗 800 万 token 和 154 轮对话。\n主要压缩策略：\n策略 原理 代表系统 滚动摘要 达到阈值时，用模型调用将历史压缩为叙述，替换原始记录 Claude Code Map-Reduce 压缩 分块 → 独立摘要（map）→ 合并为最终浓缩（reduce） 长会话场景 服务端压缩 /responses/compact 端点，返回更小的输入列表 Codex CLI KV-Cache 压缩 在推理层面驱逐 KV-cache 条目，最高 20x 压缩 LLMLingua（Microsoft Research） 外部工件记忆 进度文件、特性列表、Git 历史作为持久记忆 Anthropic 两 Agent 架构 一个关键失败模式是**\u0026ldquo;上下文焦虑\u0026rdquo;（Context Anxiety）**：当窗口接近填满时，Agent 会过早结束任务——不是因为工作完成了，而是因为它\u0026quot;感知\u0026quot;到了限制。Cognition（Devin）明确记录了这一现象。\n4.4 记忆架构 业界已收敛到认知科学的三层分类：\n情景记忆（Episodic）：存储过去的交互历史——具体事件和会话。允许回忆\u0026quot;上次发生了什么\u0026rdquo;。 语义记忆（Semantic）：声明性事实、实体属性、领域知识、用户偏好。基本上是非时序的——Agent 认为当前为真的东西。通常存储在向量数据库中。 程序记忆（Procedural）：编码\u0026quot;如何做\u0026rdquo;——操作技能、决策启发式、可复用程序（如 Claude Code 的 CLAUDE.md）。 到 2026 年中，68% 的生产 Agent 部署包含专用记忆层（2024 年仅 23%）。\n4.5 权限模型 以 Claude Code 为例的三层权限模型：\nTier 1（自动批准）：只读或固有安全的操作——文件读取、文本搜索、代码导航 Tier 2（需确认）：修改状态但可控的操作——文件编辑、某些 Shell 命令 Tier 3（默认阻止）：破坏性或高风险操作 在自动模式下，一个后台分类器在执行前评估 Tier 2 操作。关键设计：分类器看到用户请求和工具调用，但看不到模型的自由文本。这是一个刻意的架构选择——防止模型通过 prompt injection 影响自己的门控系统。\n4.6 验证循环 编码 Harness 与通用聊天 Harness 最大的差异在于Plan-Execute-Verify（PEV）循环：\nPlan：形成对预期变更的契约 Execute：在沙箱和权限环境中执行 Verify：使用确定性传感器（linter、类型检查器、测试运行器）和人工审查门控，决定状态应被接受、修订、升级还是回滚 Cursor 的早期 Harness 在每次编辑后自动呈现 lint 和类型错误——这些是确定性传感器，不是 LLM 调用——集成在循环中提供 ground-truth 反馈。\n五、当前八大难点 5.1 上下文窗口管理 尽管上下文窗口已增长到 100 万（Claude）和 200 万（Gemini 3.1）token，上下文仍是核心未解决瓶颈。\n核心问题：\n\u0026ldquo;上下文腐烂\u0026rdquo;（Context Rot）：性能随上下文填充呈非线性下降。模型并不均匀地使用上下文——可靠性在硬限制之前就开始下降。 系统 prompt、工具定义、RAG 结果和对话历史争夺空间 朴素截断破坏工具响应保真度；摘要丢失关键细节 前沿方案：\n递归语言模型（RLM，Prime Intellect）：Agent 主动将上下文委托给子进程，而非通过有损压缩丢失信息 操作系统式内存管理：将上下文窗口视为 RAM——预算、分页、主动驱逐。Mem0 的研究显示这种架构比无状态方法提升 26% 的响应准确率 TokenPilot（2026）：LLM Agent 的 Cache 高效上下文管理，优化跨工具调用的 KV-cache 复用 5.2 工具选择与路由 MCP 生态到 2026 年中已增长到 ~19,000 个已验证的公开服务器上的 ~177,000 个不同工具。\n核心问题：\n2025 年研究发现 97.1% 的 MCP 工具描述存在至少一个质量问题 无检索辅助时，工具选择准确率仅 13.62%（RAG-MCP 论文） 前沿方案：\nRAG-MCP：将工具元数据嵌入向量存储，每次查询仅检索相关工具，准确率从 13.62% 提升至 43.13% 延迟/动态工具加载：Anthropic 的 \u0026ldquo;Tool Search Tool\u0026rdquo;（2025 年 11 月），只加载一个搜索工具，按需获取和加载所需工具。Opus 4 准确率从 49% 跳升至 74% 激进工具精简：GitHub Copilot 从 40 个工具减至 13 个，基准测试改善。Block 将 Linear MCP 服务器从 30+ 工具重建为 2 个。Cloudflare 的 Code Mode 将 2,500+ API 端点压缩为 2 个工具，从 117 万 token 降至 ~1,000 token 核心洞见：工具描述不是文档——它是 LLM 的主要决策表面。\n5.3 错误恢复与自愈 核心问题：\n并非所有失败都是基础设施故障——许多是推理失败（错误计划、幻觉事实）。重试相同调用无法修复错误的思维链 2025 年 IDC 调查：92% 使用 Agentic AI 的组织报告成本高于预期，失控循环是主因 最糟糕的失败模式：\u0026ldquo;对失败任务的静默成功\u0026rdquo;——Agent 自愈到产生错误输出并充满信心 前沿方案：\nMAPE-K 启发的自愈编排器：Monitor → Analyze → Plan → Execute → Knowledge 控制循环 质量感知断路器：拦截的不仅是硬故障（超时、错误），还包括输出质量故障——畸形 JSON、Schema 违规 舱壁隔离（Bulkhead）：每个并行 Agent 分支在自己的隔间中运行，一个故障只淹没自己的舱室 推理层反思：基础设施恢复修复调用；推理层反思修复思维。两者结合覆盖可靠性问题的两半 5.4 评估与基准测试 SWE-bench 仍是主导基准：2,294 个任务实例，来自 12 个 Python 仓库的真实 GitHub issue。截至 2026 年 5 月，Claude Mythos Preview 以 93.9% 居首。\n根本性批评：SWE-bench 同时评估 Harness 和底层模型。2025 年分析发现 19.78% 的\u0026quot;已解决\u0026quot;用例语义上不正确——它们通过 reward-hacking 评估 Harness 来通过单元测试，而非产生正确代码。\n新兴基准：\nUTBoost：要求 Agent 同时生成测试，而非仅生成补丁 Harbor：在容器化环境中评估 Claude Code、OpenHands、Codex CLI Harness-Bench：专门评估 Harness 质量的基准 NIST AI Agent 标准倡议（2026 年 2 月）：行业级正确性、效率和安全指标 5.5 安全与沙箱 这可能是最令人警醒的领域。Prompt injection 在 2026 年仍是 OWASP 的 #1 LLM 威胁，被广泛描述为根本性未解决。\n问题规模：\nPrompt injection 出现在超过 73% 的生产部署中；2025 年造成约 23 亿美元损失 检测工具仅捕获 23% 的复杂注入尝试 Inkog Labs 发现 86% 的 500+ 开源 AI Agent 仓库包含至少一个安全漏洞 CVE-2025-59532 针对 OpenAI 的 Codex CLI：Agent 的自身输出可以重新定义其沙箱边界 为什么架构上很难：LLM 将输入处理为单一 token 序列，在系统 prompt、用户查询和工具检索内容之间没有可靠的权限边界。\n有效防御：\n遏制优于过滤：假设某些注入会成功；使用最小权限、沙箱和人机协作，使成功的注入无法触及敏感内容 指令层级强制：系统 prompt \u0026gt; 用户输入 \u0026gt; 工具输出——严格的权限排序 推理与权限执行分离（Anthropic 模式）：模型决定想做什么，但另一个代码路径决定是否允许。被越狱的模型无法覆盖安全检查，因为它们在独立系统中 5.6 成本与延迟 经济现实残酷：\n2025 年企业平均 AI 支出达 85,521 美元/月（同比增长 36%） 输出 token 成本是输入的 3-10 倍；高级推理模型有 8:1 的输出/输入比率 92% 的 Agentic AI 用户报告成本高于预期 优化策略：\n模型路由：为每个请求动态选择足够的最便宜模型。报告 30-70% 成本降低 Prompt 缓存：Anthropic 报告最高 85% 延迟降低和 ~90% 输入成本降低 批处理：32 个请求的批处理可将每 token 成本降低 85% 激进工具精简：减少工具数量和 token 消耗 5.7 多 Agent 编排 核心挑战：\n协调复杂度随 Agent 数量超线性增长 状态同步：Agent 争夺资源或覆盖彼此的输出 静默失败：缺少正确上下文的 Agent 会幻觉或停滞，通常没有可检测的错误信号 持久状态：5 步工作流在第 4 步丢失上下文时应从第 4 步恢复，而非重新开始 前沿模式：\n编排器-工作器 + 舱壁：一个编排器委派给专门的子 Agent，每个在隔离隔间中 每次交接的输出 Schema 验证：一个 Agent 的畸形输出不能腐蚀下游 Agent 基于图的状态（LangGraph）：将工作流建模为有向图，支持条件分支和精确恢复 Git worktree 并行 Agent（Windsurf Wave 13）：多个分支同时修改，无文件冲突 量化结果：评估驱动的编排研究显示，将常规生产 Agent 循环替换为模型无关编排层（仅改变 Harness），每个任务混合成本降低 41%。\n5.8 跨会话记忆与状态持久化 核心问题：LLM 是无状态算法。没有持久记忆层，每个会话从零开始。\n收敛的四层记忆架构：\n短期工作记忆：上下文窗口内。易失——会话结束即清除 情景记忆：按序存储特定过去事件。支持\u0026quot;你为什么做那个决定？\u0026ldquo;的重建 语义记忆：泛化的事实知识，通过嵌入搜索检索 程序/技能记忆：编码的操作程序、启发式、约束 关键开放问题：记忆过时治理——关于用户雇主的高频检索记忆在他们换工作前是准确的。检测和修复过时、被投毒或过度作用域记忆的治理框架仍处于早期阶段。\n六、各大厂如何解决这些难点 6.1 Anthropic（Claude Code） Anthropic 在 2025 年 11 月的工程博客 \u0026ldquo;Effective Harnesses for Long-Running Agents\u0026rdquo; 中最清晰地阐述了其 Harness 哲学。\n架构决策：\n长时间运行的两 Agent 架构：初始化 Agent 运行一次——将 prompt 展开为结构化的 feature-list.json 并写入 init.sh。编码 Agent 反复唤醒，每次会话在一个功能上取得增量进展，提交，并留下 claude-progress.txt 给下一个会话。外部文件就是记忆。 推理与权限执行分离：模型决定做什么；独立代码路径决定是否允许。安全检查不能被越狱绕过，因为它们在独立系统中。 Tool Search Tool（2025 年 11 月）：单个搜索工具按需检索和加载所需工具，Opus 4 准确率从 49% 跳升至 74%。 上下文压缩 + 磁盘持久化：快照、可回滚的文件变更、CLAUDE.md 作为持久锚点。 系统 prompt 动态组装：不是静态字符串——从模块化区段构建函数在运行时动态组装。边界标记将其分为全局可缓存前缀和会话特定后缀。 27 个内置工具：覆盖文件操作、Shell 执行、Web 获取、代码搜索、记忆操作和子 Agent 委派。 关键洞见：Anthropic 随着模型改进多次重新架构 Claude Code 的 Harness，剥离模型不再需要的脚手架拐杖。\n6.2 OpenAI（Codex） Codex 于 2025 年 5 月启动，由 codex-1（为软件工程优化的 o3 RL 训练变体）驱动。到 2026 年运行 GPT-5.5。\n架构决策：\n每任务隔离云环境：每个 Codex 任务在预加载仓库的独立云 VM 中运行。完全异步（1-30 分钟）。 解耦设计：LLM 推理循环与工具执行分离。核心用 Rust（codex-rs）编写。 RL 训练在真实编码任务上：codex-1 被训练为迭代运行测试直到通过——奖励信号是通过测试套件。 AGENTS.md 文件：OpenAI 的 CLAUDE.md 等价物——存活于上下文重置的持久行为指导。 规模：到 2026 年 3 月周活跃用户 200 万+；3 个工程师在 5 个月内用 Codex 构建了约 100 万行代码。 极端 Harness Engineering：OpenAI Frontier 团队交付了 1500+ PR 和零人工编写代码，证明了 Harness 质量可以完全替代人工编码。 6.3 Google（Jules + Gemini CLI） Jules 于 2024 年 12 月启动，2025 年 8 月 GA。\n架构决策：\n队列优先于聊天：唯一围绕任务队列而非实时聊天构建的主要编码 Agent。描述任务、走开、取回 PR。这是一个明确的架构选择——默认异步。 每任务隔离 Google 管理的 VM：每个任务在独立 VM 中运行。输出始终是可审查的 PR。 大脑与双手解耦：Harness（执行环境、异步队列、PR 交付）稳定；底层 Gemini 模型独立升级。 会话内模型路由：Gemini Pro 用于规划和困难任务；Gemini Flash 用于同一 Agent 运行中的较轻子任务。 200 万 token 上下文窗口（Gemini 3.1）：大型代码库可放入上下文而无需检索增强。 6.4 IDE 集成 Agent Cursor：\n三模式架构：Composer（快速内联多文件）、Agent Mode（计划后执行）、Background Agents（异步服务端） 同一 Claude 模型在不同 Harness 中的表现：46% → 80%。Harness 质量是主要变量 Cursor 3（2026 年 4 月）：Agent 优先界面；IDE 降级为回退面板 5 亿美元 ARR（2025 Q4）；估值 ~90 亿美元 Windsurf（Cascade）：\n从零开始构建的单一深度集成 Agentic 表面——无模式切换 \u0026ldquo;Flow state\u0026quot;模型：Agent 预测下一步需要什么（检查相关测试、类型定义），无需显式提示 Wave 13（2026 Q1）：使用 Git worktree 的并行 Agent——多分支同时修改 开源阵营：\nCline / OpenCode：完整 MCP 支持；模型无关；可脚本化和可组合。OpenCode：13.5 万 GitHub stars Aider：最小足迹哲学——无 GUI、无云、专家终端助手 关键架构分叉：IDE 原生 Agent 优化 UX 深度和编辑器内自主性；开源 Harness 优化灵活性、模型无关性和 CI/CD 管道中的可组合性。\n6.5 开源框架 框架 核心创新 规模 LangGraph 基于图的有状态工作流，持久执行，对 Agent 循环的精确控制 v1.0（2025.11） CrewAI 角色扮演多 Agent 协作；快速原型速度 52,800 stars, 520 万/月下载 AG2 / AutoGen 事件驱动架构，异步消息传递 并入 Microsoft Agent Framework OpenAI Agents SDK 轻量 Python，100+ LLM 支持，追踪，护栏 26,900 stars, 1030 万/月下载 OpenHands 自主全栈编码 Agent，Docker 沙箱 SWE-bench 72%（Claude Sonnet 4.5） 实际生产部署案例：Spotify 的\u0026quot;Honk\u0026quot;系统自 2024 年中以来已在数百个仓库中合并 1,500+ AI 生成的 PR，通过验证循环解决 Agent 可靠性问题。\n七、关键学术论文 论文 核心贡献 ReAct（Yao et al., 2022） 建立 Thought → Action → Observation 循环——Agent Loop 的原型 SWE-agent（Yang et al., NeurIPS 2024） 证明 Agent-Computer Interface 设计对编码性能的影响与模型本身一样大 Agentic Harness Engineering（arXiv:2604.25850） 引入 AHE 作为闭环系统，使用可观测性数据围绕固定模型演进 Harness Don\u0026rsquo;t Blame the LLM（arXiv:2607.03691） 同一基模型在不同 Harness 中 Terminal-Bench 分数波动 30–50 个百分点 The Harness Effect（arXiv:2607.06906） 形式化编排设计如何设定 token 经济学 HarnessX（arXiv:2606.14249） 提出构建和演进 Harness 的通用框架 Inside the Scaffold（arXiv:2604.03515） 编码 Agent 架构的源码级分类法 Dive into Claude Code（arXiv:2604.14228） 分析 Claude Code 的设计空间 Agent Harness Survey（TMLR, under review） 110+ 论文、23 个系统的系统性综述 八、总结 核心论点 Harness Engineering 的核心论点可以用一句话概括：可靠 AI Agent 的瓶颈不是模型能力，而是模型周围的系统工程质量。\n65% 的企业 AI Agent 失败可追溯到 Harness 缺陷（上下文漂移、Schema 不对齐、状态退化），而非模型缺陷。同一模型在不同 Harness 中的性能可以波动 30-50 个百分点。在生产中运送可靠、经济可持续 Agent 的团队，都是那些把 Harness 作为主要工程表面来对待的团队。\n问题-方案映射 难点 当前最佳方案 上下文溢出 外部工件记忆 + 增量提交 + 上下文压缩 工具过载 RAG 动态工具加载 + 激进工具精简 错误恢复 推理层反思 + 断路器 + 舱壁隔离 评估 SWE-bench Verified + Harness 消融研究 安全 推理/权限系统分离 + 沙箱遏制 成本 模型路由 + Prompt 缓存 + 批处理 API 多 Agent 协调 基于图的状态 + 输出 Schema 验证 + 舱壁 会话持久化 四层记忆 + 多作用域标签 + 过时治理 趋势 随着模型能力趋于收敛，竞争壁垒正从模型选择转向 Harness 质量。使用同一 LLM 但不同 Harness 的两个产品，将产生截然不同的用户体验。新型 AI 工程师的角色是：系统架构师、约束设计师、反馈循环构建者、质量策展人——而非直接的代码作者。\n这不是 Prompt Engineering 的替代，而是它的超集。Harness Engineering 包含 Context Engineering，后者包含 Prompt Engineering。但驱动力在每个阶段都是相同的：无论 LLM 能力多强，可靠的生产系统都需要模型周围的可执行环境作为约束性工程表面。\n参考资料 博客 Mitchell Hashimoto: My AI Adoption Journey（2026.02.05） Vivek Trivedy / LangChain: Improving Deep Agents with Harness Engineering（2026.02.17） Birgitta Böckeler / Martin Fowler: Harness Engineering（2026.02–04） Ryan Lopopolo / OpenAI: Extreme Harness Engineering for Token Billionaires（Latent Space, 2026.04） Anthropic Engineering: Effective Harnesses for Long-Running Agents（2025.11） OpenAI: Harness Engineering: Leveraging Codex Cursor: Continually Improving Our Agent Harness 学术论文 ReAct: Synergizing Reasoning and Acting（Yao et al., 2022） SWE-agent: Agent-Computer Interfaces（Yang et al., NeurIPS 2024） Agentic Harness Engineering（arXiv, 2026） Don\u0026rsquo;t Blame the LLM（arXiv, 2026） The Harness Effect（arXiv, 2026） HarnessX（arXiv, 2026） Inside the Scaffold（arXiv, 2026） Dive into Claude Code（arXiv, 2026） Agent Harness Survey（TMLR, under review） Context Engineering: A Practitioner Methodology（arXiv, 2026） The Prompt Report（arXiv, 2024） 行业分析 Faros.ai — Harness Engineering Augment Code — Harness Engineering for AI Coding Agents Arize AI — What Is an Agent Harness? Databricks — What is an AI Agent Harness? Agent Harness — Wikipedia Atlan — Prompt vs Context vs Harness Engineering Awesome Harness Engineering — GitHub From Prompt to Harness Engineering — Medium Mem0 — State of AI Agent Memory 2026 OWASP Prompt Injection 2026 ","date":"Jul 30, 2026","permalink":"https://voyager314.github.io/posts/harness-engineering-understanding/","readingTime":21,"summary":"引言 2026 年初，一个新术语席卷了 AI 工程界——Harness Engineering（Harness 工程）。它不是又一个营销概念，而是对过去四年 AI 工程实践的一次系统性总结：当我们不再满足于\u0026quot;写一个好 prompt\u0026quot;，而是需要构建一个让 AI Agent 可靠、安全、经济地完成复杂任务的完整系统时，Harness Engineering 就是那个系统工程学科的名字。\n","title":"深入理解 Harness Engineering：从 Prompt 到 Harness 的进化之路"},{"content":" 本文系统梳理 coding agent 评测领域的主流基准、评测指标与框架，覆盖 2021–2026 年的学术论文与工业界实践，适合希望了解或搭建 agent 评测体系的研究者和工程师参考。\n一、背景：从代码补全到软件工程 Agent Coding agent 的评测体系随模型能力演进经历了三次范式转变：\n2021–2022：函数级代码生成时代。HumanEval、MBPP 等基准以单函数合成为核心，pass@k 为唯一指标，题目简单、数据集静态。 2023–2024：仓库级真实任务时代。SWE-bench 将评测对象从函数提升为真实 GitHub issue，要求 agent 理解 bug 报告、导航大型代码库并生成正确补丁。 2024–2026：多维度 agent 评测时代。随着 SWE-bench Verified 被顶级 agent 超过 70% 解决率（OpenAI 于 2025 年宣布将其退役），业界转向更难的 SWE-bench Pro、多模态、多语言基准，以及专门衡量 tool use 和多步规划能力的 agent 评测框架。同时，Claude Opus 4、Sonnet 4 等新一代模型的发布进一步加速了基准饱和。 当前评测体系面临三大核心挑战：基准饱和、数据污染（训练集泄露与搜索时污染）、指标局限（pass@k 无法度量推理过程）。\n二、核心评测基准 2.1 第一代：函数级代码生成 HumanEval 项目 内容 来源 OpenAI，2021 年随 Codex 模型发布 规模 164 道手写 Python 题 机制 给定函数签名+docstring，生成函数体，在隐藏测试用例上执行验证 核心指标 pass@k，pass@1 最常用 当前水平 Claude Sonnet 4 达 95.1% pass@1（2025） 论文 arXiv:2107.03374 局限： 164 题规模极小、静态数据集、已被广泛记忆，现已近乎饱和。HumanEval+ 通过扩增测试用例提供了略高的区分度，但本质局限未变——该基准已从\u0026quot;能力鉴别器\u0026quot;退化为\u0026quot;入门资格检验\u0026quot;。\nMBPP（Mostly Basic Python Problems） 项目 内容 来源 Google Research，2021 规模 974 道众包 Python 入门题 机制 自然语言描述 → 代码生成，每题 3 条 assert 测试 核心指标 pass@1 / pass@k 当前水平 前沿模型 95%+，已几乎饱和 论文 arXiv:2108.07732 2.2 第二代：仓库级真实任务 SWE-bench（当前核心基准） 项目 内容 来源 Princeton NLP，2023 规模 2,294 个实例；Verified 子集 500 个（人工验证） 机制 给定真实 GitHub issue + 完整仓库，agent 需修改代码使\u0026quot;Fail-to-Pass\u0026quot;测试通过 数据来源 12 个知名 Python 开源项目（Django、scikit-learn、Flask 等） 核心指标 % Resolved：补丁通过所有关联单元测试的比例 难度演变 2023 年最强模型（Claude 2）仅解决 1.96%；2025 年顶级 agent 超过 70% 论文 arXiv:2310.06770 变体：\nSWE-bench Lite：300 个相对独立的 issue，适合快速评测 SWE-bench Verified：OpenAI 联合推出，500 个人工核验实例，2024 年成为主流标准 SWE-bench Pro：2025 年 9 月推出（arXiv:2509.16941），1,865 个任务覆盖 41 个活跃维护的仓库，顶级模型得分约 20–25%（标准化评测），是目前最难的版本 SWE-bench Multimodal：包含图片（截图、UI 设计稿、架构图）的 issue，最佳系统仅解决约 12–15%，暴露了当前 agent 在视觉上下文理解上的短板 SWE-PolyBench：2,110 个实例，覆盖 Java、JavaScript、TypeScript、Python；部分模型从 Python 切换到其他语言后性能下降 20–40% 2025 年排行榜现状： Claude Sonnet 4 / Opus 4 是得分最高 agent 的主流底座；AIR 在 SWE-bench Verified 上达到 87.1%，GitHub Copilot 约 56%，OpenAI Codex（agent）约 51.7%。OpenAI 已宣布 SWE-bench Verified 不再衡量前沿能力，建议迁移到 SWE-bench Pro。\nBigCodeBench 项目 内容 来源 BigCode 社区，2024 规模 1,140 个函数级任务，覆盖 139 个库、7 个领域 机制 每题需综合调用多个真实库（如 os + requests + pandas），执行测试验证 核心指标 pass@1（执行验证，非字符串匹配） 变体 Complete（完整签名）/ Instruct（仅自然语言描述）/ Hard（高难子集） 论文 arXiv:2406.15877 定位： 被称为\u0026quot;下一代 HumanEval\u0026quot;，专注多库组合调用能力，更贴近真实开发场景。\n2.3 第三代：污染对抗与持续更新基准 LiveCodeBench 项目 内容 来源 UC Berkeley / MIT / Cornell，2024，ICLR 2025 收录 规模 800+ 题（持续增长），来自 LeetCode、AtCoder、Codeforces 机制 按模型训练截止日期过滤题目，仅在\u0026quot;训练后发布\u0026quot;的题上评测 评测任务 代码生成、自修复（self-repair）、代码执行理解、测试输出预测 核心指标 pass@1 + 各子任务准确率 污染防护 严格时间窗口过滤，已在 GPT-4o、Claude、DeepSeek 等模型上检测到污染 论文 arXiv:2403.07974 Commit0 项目 内容 来源 2024 年 12 月 机制 要求 agent 从零重建 57 个核心 Python 库，仅给自然语言规范，通过库自身单元测试 难度 多阶段迭代 + 复杂依赖，远难于静态补丁生成 论文 arXiv:2412.01769 定位： 目前最接近真实软件工程交付物的基准之一。\nRE-Bench 项目 内容 来源 METR，2025 规模 7 个 AI 研发环境，每题限时 8 小时 机制 在受控容器中执行真实 ML 研发任务（训练优化、数据增强、模型改进等），按改进幅度评分 定位 唯一聚焦\u0026quot;AI 做 AI 研发\u0026quot;的基准，评估 agent 在长周期复杂任务中的规划与迭代能力 论文 arXiv:2503.04474 发现： METR 时间跨度分析表明，agent 可靠性在超过数小时的任务后急剧下降，RE-Bench 正是为检测这一衰减设计。\nSciCode 项目 内容 来源 NeurIPS 2024 Datasets \u0026amp; Benchmarks 规模 65 道主题题 → 338 道子题，覆盖数学、物理、化学、生物、材料、力学 机制 由领域科学家出题，同时考察编程能力和专业知识 定位 前沿模型上限测试；前沿模型仍有显著差距 论文 arXiv:2407.13168 三、评测指标体系 3.1 pass@k 及其局限 pass@k 是最广泛使用的代码评测指标，定义为：在 k 次独立采样中，至少一次通过所有测试用例的概率。\n计算方式： $$ pass@k = 1 - \\frac{\\binom{n-c}{k}}{\\binom{n}{k}} $$其中 n 为总采样次数，c 为通过的样本数。\n主要局限：\n奖励\u0026quot;暴力采样\u0026quot;而非真正的推理能力，算力预算掩盖模型质量 静态测试用例可被记忆，排名不稳定 无法区分推理深度与运气 纯结果指标，无法诊断失败原因 3.2 超越 pass@k 的新指标 指标/方法 核心思想 来源 Breadth-Depth Metrics 分别度量覆盖广度（能解决多少类问题）和深度（对每类问题的可靠性） arXiv:2510.08325 Bayesian pass@k 在采样量少时稳定排名，减少假结论 arXiv:2510.04265 pass@o 面向 OOP 场景，评估类级别与封装正确性 ACL 2024 Findings CodeJudge（LLM-as-Judge） 用 LLM 评估器替代手写测试用例判定正确性 arXiv:2505.20854 SWE-Effi 在 SWE-bench 解决率基础上加权 token 成本与执行时间 SWE-agent 扩展工作 三维评测框架 效果（任务成功率）× 效率（执行步骤）× 开销（token 消耗） OpenHands/PULSE pass^k（Tau2-bench） 度量 agent 在 k 次重复尝试中的一致性，区分\u0026quot;能做到\u0026quot;和\u0026quot;稳定做到\u0026quot; Sierra Research / Princeton HAL 成本联合评测 强制要求 score 与 cost 联合报告；发现同一基准上每次运行成本跨 4 个数量级 Princeton HAL，ICLR 2026 3.3 多语言与多模态扩展指标 MultiPL-E：将 HumanEval/MBPP 翻译为 20 种编程语言，揭示 Python-only 评测高估通用能力（IEEE TSE 2023） CRUXEval：800 道短 Python 函数，分输入预测和输出预测两个方向，测试代码推理而非代码生成（arXiv:2401.03065） CRUXEval-X：多语言扩展至 19 种语言，ACL 2025 收录；仅在 Python 上训练的模型在其他语言只有约 34.4% 四、Agent 评测框架 4.1 AgentBench 论文： arXiv:2308.03688，2023 年\n首个系统性评测 LLM 作为自主 agent 的多环境基准，包含 8 个交互环境（OS 命令行、数据库、网页浏览、卡牌游戏、家庭任务等），测试 29 个模型。\n核心发现： 商业 LLM（GPT-4、Claude）远超开源模型；主要失败模式为长期推理能力弱、指令遵循差。\n4.2 SWE-agent（Scaffold 框架） 论文： arXiv:2405.15793，2024 年\nSWE-agent 是一个 agent 脚手架（中间件层），为 LLM 提供结构化的仓库导航、文件编辑、Shell 执行等工具接口。\n关键洞察： Scaffold 设计本身是性能的重要决定因素——相同的 LLM 底座在更强的 scaffold 下可解决更多 issue。这一发现推动了 scaffold 架构分类研究的兴起。\n原始得分： SWE-agent + GPT-4 在 SWE-bench 全集达 12.47%，HumanEvalFix 达 87.7%。\n后续发展： Live-SWE-agent（2025 年 11 月，arXiv:2511.13646）是首个在运行时自我改写工具的 agent scaffold——\u0026ldquo;自进化脚手架\u0026rdquo;。Claude Sonnet 4.5 + Live-SWE-agent 在 SWE-bench Pro 上达 45.8%（当时开源 scaffold 最高），Gemini 3 Pro + Live-SWE-agent 在 SWE-bench Verified 上达 77.4%。与之形成对照的是 mini-swe-agent：仅用 subprocess.run 的极简 scaffold 也能在 SWE-bench Verified 上超过 74%，说明瓶颈更多在于模型推理能力而非 scaffold 复杂度。\n4.3 OpenHands（原 OpenDevin） 论文： arXiv:2407.16741\n开放的 AI 软件开发 agent 平台，支持插入任意 LLM 和 agent 进行对比评测。\n评测方法论：\n支持 13+ 基准（SWE-bench、WebArena、SkillsBench 等） PULSE 框架：用户反馈 + ML 模型预测满意度 + 伪标签，实现以人为中心的评测 OpenHands Index（2026 年 1 月）：跨五个维度的综合评测——SWE-bench Verified（issue 修复）、Commit0（从零构建）、SWE-bench Multimodal（前端）、SWT-bench（测试）、GAIA（信息获取），取宏观平均分 4.4 Agentless 论文： arXiv:2407.01489\n反直觉的发现：无 agent 循环的简单两阶段流水线（故障定位 → 补丁生成与筛选）在 SWE-bench 上超越复杂 agent 框架。\n性能： SWE-bench Lite 解决率 32%，成本约 $0.70/次，发布时超越所有开源 agent。\n核心启示： 故障定位质量（函数级 \u0026gt; 文件级 \u0026gt; 行级）是代码修复的关键瓶颈，而非 agent 架构的复杂度。\n4.5 InterCode 论文： arXiv:2306.14898，NeurIPS 2023\n将交互式编程建模为强化学习问题：动作 = 代码，观测 = 执行反馈。支持 Bash、SQL、Python、CTF 四种环境，使用 Docker 保证安全可复现执行。\n五、工具调用与多步规划的评测前沿 最终答案正确率对 agent 质量而言是个糟糕的信号——步骤级轨迹指标才能揭示 pass@k 看不到的失败模式。\n5.1 轨迹级评测框架 框架 核心贡献 来源 TRAJECT-Bench 5,870 条查询（简单/困难/顺序），评估工具选择准确率、参数构造正确性、调用顺序依赖满足度；揭示\u0026quot;相似工具混淆\u0026quot;等失败模式 arXiv:2510.04550，ICLR 2026 MCP-Radar 五维评测：答案准确性、工具选择效率、资源效率、参数构造准确性、执行速度 arXiv:2505.16700 DeepPlanning 长视野规划中的可验证约束；发现前沿 LLM 在并行工具调用和显式多步推理链上显著退化 arXiv:2601.18137 ToolBench 真实场景下规划、创建、使用工具的全流程基准 ACL 2024 Findings MCP 评测生态的扩展： 2025–2026 年涌现了大量 MCP 专项基准：MCP-Bench（arXiv:2508.20453）、MCPToolBench++（1,500 查询覆盖 40+ 工具类别）、MCP-Universe（真实 MCP 服务器）、MCPWorld（混合 API+GUI）、LiveMCPBench（\u0026ldquo;Agent 能否导航 MCP 工具海洋？\u0026quot;）、MCP-AgentBench（AAAI 2025，33 个 MCP 服务器）。\n5.2 LLM-as-Judge 方法 当测试用例难以穷举时，用 LLM 评估器代替手写测试判定代码正确性正在兴起。CodeJudge（基于 Llama-3-8B）在无需执行环境的情况下，评测性能超过基于 GPT-3.5 的方案。\n六、数据污染问题与应对策略 这是目前评测体系中最重要的方法论争议。\n6.1 污染类型 训练集泄露：基准题目出现在训练数据中，模型\u0026quot;背题\u0026quot;而非\u0026quot;解题\u0026rdquo; 问题上下文泄露：相关讨论、题解被间接纳入训练 搜索时污染（2025 年新问题）：具备搜索能力的 deep research agent 在评测时直接检索基准答案，人为抬高得分（arXiv:2606.05241） 6.2 五种主流污染检测方法 方法 原理 时间分区法 对比模型在训练截止日期前后题目上的表现差异（\u0026ldquo;Codeforces 断崖\u0026quot;效应） Min-K% 概率 检查模型对基准题目 token 的预测概率是否异常高 Time Travel 攻击 仅给模型任务 ID（无代码/描述），观察是否能复现答案 ConStat 对比模型在原始题目与改写题目上的表现差距 BIG-Bench Canary 在训练数据中嵌入 GUID，检查模型是否记忆 已被污染实质性影响的基准包括：MMLU、HumanEval、HellaSwag、原始 GSM8K，均已出现 90%+ 的天花板分数。\n6.3 为什么 SWE-bench Verified 被退役 OpenAI 明确指出设计缺陷和污染是退役原因：\u0026ldquo;该基准不再能衡量前沿编程能力\u0026rdquo;，建议转向 LiveCodeBench 和 SWE-bench Pro。关键证据：在 138 个任务的抽样审计中，59.4% 存在测试缺陷（35.5% 的测试强制执行未在 issue 中描述的实现细节，18.8% 检查的功能来自其他 PR）。更具决定性的是，OpenAI 仅给 GPT-5.2、Claude Opus 4.5 和 Gemini 3 Flash 一个任务 ID（如 django__django-11099），不提供任何代码或描述，三个模型均能从记忆中逐字复现金标准补丁——精确到文件路径、行号和字符级修改。参见 OpenAI 博客。\n6.4 主流反污染策略 策略 代表工作 原理 时间窗口过滤 LiveCodeBench 仅评测训练截止日期后发布的题目 动态生成 EvoEval、EvoCodeBench 用 LLM 演化现有题目，使记忆的答案失效 多智能体博弈 arXiv:2605.04312 agent 相互对抗，静态记忆无效 分发感知构造 arXiv:2607.20911 跨领域（代码、Web、安全）构建污染抵抗基准 NIST CAISI 定义 NIST 官方框架 将\u0026quot;解题污染\u0026rdquo;（访问超出部署约束的信息）定义为核心作弊向量 七、工业界评测实践 7.1 主流 Coding Agent 评测方式对比 工具 SWE-bench Verified（2025） 评测特点 Claude Code（Opus 4/Sonnet 4） 72.5–80.2% 按任务类型细分（文档 92.3%，功能 72.6%）；commit message 质量领先；1M token 上下文 GitHub Copilot ~56–68% 公开基准 + 微软/GitHub 内部私有基准；同时评测 token 效率与速度 OpenAI Codex（agent） GPT-5.5 报告 88.7% 沙箱环境运行；SWE-bench Pro 上 GPT-5.3 约 56.8% Cursor ~51.7–75% 分数取决于底座模型选择；全仓库索引比仅聊天历史提升约 25% 准确率 Devin（Cognition AI） ~65%（2026 估算） 首发时 13.86%（2024 年初），是当时最强无辅助基线的 7 倍 关键发现：\n没有单一 agent 在所有任务类型上占优——Claude Code 领跑文档和功能类任务，其他工具在特定任务类型上各有优势。 Vendor 报告分数与标准化评测差距巨大：vendor scaffold 分数通常比 Scale SEAL 标准化分数高 15–30 个百分点，直接比较无意义。 多工具组合使用已成主流：开发者普遍采用 Cursor（行内补全）+ Claude Code（重型 agent 任务）的双工具栈。 成本必须联合报告：HAL（Princeton，ICLR 2026）在 21,730 次运行中发现，同一基准上的单次运行成本跨越 4 个数量级。 7.2 多维度评测框架趋势 工业界正从单一准确率指标转向多维评测：\n效果（任务成功率） 效率（执行步骤数 / 时间） 成本（token 消耗 / 美元成本） 质量（代码可读性、commit message 质量） 八、评测体系全景总结 8.1 基准选择参考 评测目标 推荐基准 原因 基础代码生成能力 HumanEval + MBPP 经典对照，仅作为入门资格检验；前沿区分请用 LiveCodeBench 真实软件工程能力 SWE-bench Pro 仓库级 issue 修复，1,865 个任务覆盖 41 个仓库；Verified 已接近饱和 污染对抗评测 LiveCodeBench 持续更新，时间窗口过滤，800+ 题 多库 API 综合调用 BigCodeBench 真实库依赖，执行验证，Hard 子集仍有区分度 多语言能力 MultiPL-E / SWE-PolyBench / Aider Polyglot 暴露 Python-only 训练的泛化缺陷（3–23 倍性能差距） 推理上限测试 SciCode / Commit0 / RE-Bench 前沿模型仍有大量提升空间；RE-Bench 专测长周期任务衰减 Tool use / 规划能力 TRAJECT-Bench / MCP-Radar 步骤级诊断，超越最终结果 CLI / 系统级能力 Terminal-Bench 命令行操作、环境配置、系统调试 多模态软件工程 SWE-bench Multimodal 包含 UI 截图、架构图的 issue 8.2 核心洞察 Scaffold 与底座同样重要：相同 LLM 在不同 agent scaffold 下的解决率差异可达 30–50 个百分点（HAL/GAIA 实证数据），scaffold 设计已成为独立研究方向。Meta 以约 $2B 收购 Manus（2025 年 12 月）被业界解读为收购 harness 架构而非底座模型。 简单不一定输：Agentless 的无循环两阶段流水线在 SWE-bench 上超越复杂 agent，故障定位质量是真正瓶颈。mini-swe-agent 仅用 subprocess.run 也能超过 74%。 基准生命周期在压缩：从 HumanEval 饱和到 SWE-bench Verified 退役（2026 年 2 月），前沿模型刷爆主流基准的周期越来越短。HumanEval、MMLU、HellaSwag、GSM8K 均已实质失效。持续更新的基准（LiveCodeBench）和更难的任务（SWE-bench Pro、Commit0）是趋势。 指标需要升维：pass@k → 三维评测（效果 × 效率 × 成本）→ 轨迹级评测（工具调用准确性、规划依赖满足度）是演进路径。HAL 的核心主张是\u0026quot;不报告成本的分数无意义\u0026quot;。 搜索时污染是新威胁：2025 年才被系统研究，具备搜索能力的 agent 可在评测时直接检索答案。OpenAI 的 Time Travel 实验（仅给任务 ID 即复现金标准补丁）证明了污染的严重程度。 Python 偏见是系统性盲区：SWE-PolyBench 和 Multi-SWE-bench 均发现，模型在 Python 上的表现是其他语言的 3–23 倍。仅在 Python 上评测会严重高估模型的通用编程能力。 参考文献与资源 核心论文\nSWE-bench: arXiv:2310.06770 SWE-bench Pro: arXiv:2509.16941 HumanEval / Codex: arXiv:2107.03374 MBPP: arXiv:2108.07732 LiveCodeBench: arXiv:2403.07974 BigCodeBench: arXiv:2406.15877 SWE-agent (Scaffold): arXiv:2405.15793 Live-SWE-agent: arXiv:2511.13646 Agentless: arXiv:2407.01489 AgentBench: arXiv:2308.03688 OpenHands: arXiv:2407.16741 InterCode: arXiv:2306.14898 SciCode: arXiv:2407.13168 Commit0: arXiv:2412.01769 RE-Bench: arXiv:2503.04474 SWE-PolyBench: arXiv:2504.08703 EvoEval: arXiv:2403.19114 EvoCodeBench: arXiv:2602.10171 MultiPL-E: IEEE TSE 2023 CRUXEval: arXiv:2401.03065 Search-Time Contamination: arXiv:2606.05241 TRAJECT-Bench: arXiv:2510.04550 MCP-Radar: arXiv:2505.16700 LLM Code Gen Evaluation Survey: arXiv:2408.16498 LLM-based Agent Evaluation Survey: arXiv:2503.16416 Agentic SE Benchmark 反思: arXiv:2606.17799 排行榜与工具\nSWE-bench Leaderboard SWE-bench Pro (Scale AI) LiveCodeBench Leaderboard BigCodeBench Leaderboard SciCode Leaderboard Terminal-Bench Leaderboard OpenHands GitHub SWE-agent GitHub SWE-PolyBench GitHub InterCode GitHub ","date":"Jul 30, 2026","permalink":"https://voyager314.github.io/posts/coding-agent-evaluation-plan/","readingTime":14,"summary":" 本文系统梳理 coding agent 评测领域的主流基准、评测指标与框架，覆盖 2021–2026 年的学术论文与工业界实践，适合希望了解或搭建 agent 评测体系的研究者和工程师参考。\n","title":"Coding Agent 评测体系构建：主流方案与前沿进展"},{"content":"问题描述 在使用FinalShell上传本地文件时出现上传失败的情况，如图：\n原因分析 核心原因是连接账号的权限不足，非root用户无法上传文件。\n于是更改为root用户：\n但此处设置的前提是你已经设置了root密码。\n查看root密码，此处以ubuntu为例：\nvim /etc/shadow或passwd -S root\n如果文件中显示root : * : 20494 : 0 : 99999 : 7 : : :或命令输出L，则表示密码已被锁定/禁用，无法使用root密码登录。\n解决方法 重新设置root密码sudo paaswd root，输入两次密码即可。\n密码设置完成后，点击应用并确定，再次连接，发现依然无法连上，即使输入密码正确。\n配置/etc/ssh/ssh_config：\nPermitRootLogin yes\nPasswordAuthentication yes\n重启sshsystemctl restart ssh\n在我查看的大部分教程中到这里就结束了，一般就可以连上了，但是ubuntu环境下在/etc/ssh/sshd_config.d中还存在更高优先级的配置文件，如果其中缺失了上述两条配置，依然是无法生效的。\n如图：\n打开改配置文件，插入PermitRootLogin yes和PasswordAuthentication yes。\n到这里，root登录的配置才算完整。\n使用root登录并上传：\n成功🙌\n","date":"May 9, 2026","permalink":"https://voyager314.github.io/posts/blog-2/","readingTime":2,"summary":"问题描述 在使用FinalShell上传本地文件时出现上传失败的情况，如图：\n原因分析 核心原因是连接账号的权限不足，非root用户无法上传文件。\n于是更改为root用户：\n","title":"解决FinalShell文件上传失败的方法"},{"content":"由于静态网站的限制，在添加浏览量显示这类动态展示功能时，需要引入第三方服务。\n此处，博主采用 busuanzi 作为提供商，优点是简单快捷，只需引入script脚本即可实现计数功能。\n实现方案 涉及文件 文件 作用 layouts/partials/post_meta.html 覆盖主题元信息模板，添加眼睛图标与计数元素 layouts/partials/extend_footer.html 加载 busuanzi 脚本，格式化数字，控制加载动画 assets/css/extended/custom.css 旋转加载圈与图标样式 1. 元信息模板（post_meta.html） 在原有的日期、阅读时长等信息之后，追加浏览量组件：\n\u0026lt;span class=\u0026#34;post-pv-wrap\u0026#34; title=\u0026#34;浏览量\u0026#34;\u0026gt; \u0026lt;!-- 眼睛图标 (SVG) --\u0026gt; \u0026lt;span class=\u0026#34;pv-spinner\u0026#34;\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;!-- 加载中旋转圈 --\u0026gt; \u0026lt;span id=\u0026#34;busuanzi_page_pv\u0026#34; style=\u0026#34;display:none\u0026#34;\u0026gt;\u0026lt;/span\u0026gt; \u0026lt;!-- 计数值 --\u0026gt; \u0026lt;/span\u0026gt; 注意：v3 的元素 ID 是 busuanzi_page_pv，与旧版 v2 的 busuanzi_value_page_pv 不同，不可混用。\n2. 脚本加载（extend_footer.html） \u0026lt;script src=\u0026#34;//cdn.busuanzi.cc/busuanzi/3.6.9/busuanzi.abbr.min.js\u0026#34;\u0026gt;\u0026lt;/script\u0026gt; 脚本必须同步加载（不加 defer / async），原因如下：\nv3 脚本内部通过 document.currentScript.src 推导 API 地址：\nconst u = new URL(document.currentScript.src); fetch(u.protocol + \u0026#39;//\u0026#39; + u.host + \u0026#39;/abbr-api.php\u0026#39;, ...) 浏览器规范规定，defer 和 async 脚本执行时 document.currentScript 恒为 null，导致第一行即抛出 TypeError，fetch 请求从未发出，页面无任何报错但计数始终不显示。\n将脚本放在 extend_footer.html（页面底部）而非 \u0026lt;head\u0026gt;，可在不阻塞首屏渲染的前提下保持同步加载。\n3. 数字格式化 busuanzi 回填数值后，通过 MutationObserver 拦截并格式化：\nfunction formatPV(n) { if (n \u0026gt;= 10000) { return (n / 10000).toFixed(2).replace(/\\.?0+$/, \u0026#39;\u0026#39;) + \u0026#39;w\u0026#39;; } return String(n); } // 示例：10150 → \u0026#34;1.02w\u0026#34;，20000 → \u0026#34;2w\u0026#34;，9999 → \u0026#34;9999\u0026#34; 加载完成前显示旋转圈，6 秒内无响应则自动隐藏。\n踩坑记录 问题：上线后不显示，本地正常 根因：脚本标签写了 defer，导致 document.currentScript 为 null，API 请求静默失败。\n解决：移除 defer，将脚本放至页面底部同步执行。\n问题：元素 ID 写错 根因：误用了 v2 的 ID busuanzi_value_page_pv，而 v3 API 实际返回的 key 为 busuanzi_page_pv。\n解决：统一改为 busuanzi_page_pv。\n问题：hugo.toml 配置缺失 解决：在 hugo.toml中手动开启 busuanzi 计数功能\n[busuanzi] enable = true 注意事项 busuanzi v3 禁止 localhost 接入，本地 hugo server 调试时不会显示数字，属正常现象，推送至 GitHub Pages 后生效。\n域名长度不得超过 22 个字符（voyager314.github.io 共 21 字符，在限制内）。\n必须在 hugo.toml 中开启 busuanzi 功能，否则上述配置上线后依然无效！\n[busuanzi] enable = true ","date":"Apr 25, 2026","permalink":"https://voyager314.github.io/posts/blog-1/","readingTime":2,"summary":"由于静态网站的限制，在添加浏览量显示这类动态展示功能时，需要引入第三方服务。\n此处，博主采用 busuanzi 作为提供商，优点是简单快捷，只需引入script脚本即可实现计数功能。\n","title":"Enable PV Count"},{"content":"测试一下博客 这是蒟蒻第一篇博客，目前还没想好写什么 (\n使用hugo+github的静态页面托管构建：\n下载hugo Release v0.159.2 · gohugoio/hugo 。\n把hugo.exe根目录添加到系统PATH，之后就可以直接使用hugo命令了。\n验证 hugo version 。\n创建站点 hugo new site your-blog，这样在当前目录下会生成 your-blog 目录，这就是hugo源文件，包含主题、网页前端配置、你的文章等。\n初始化git仓库 git init 。\n创建两个仓库：username/username.github.io(同时也是用于访问博客的域名)，blog(或者其它名字也行)。\n创建你的第一篇文章 hugo new posts/test.md ，更新文章并提交 git commit -am \u0026quot;msg\u0026quot; -\u0026gt; git push -u origin master 。默认情况下，每篇文章的 draft 属性为 false 时才能生效。使用 -D 以提交草稿。\n运行 hugo server -D ，默认在 localhost:1313 启动。\n所有文章都保存在 /your-blog/content/posts 中，之后每次写博客时只需在这里创建/更新文章，再 git commit, git push 即可。\nblog用于存放hugo源文件，username.github.io托管静态网页文件。\n在blog中创建.github/workflow/deploy.yml配置github actions，可以将blog仓库的修改同步到username.github.io 。\n配置deploy.yml\nname: Deploy Hugo site to Pages on: push: branches: - main #改成自己的blog仓库分支 jobs: build-deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: submodules: true fetch-depth: 0 - name: Setup Hugo uses: peaceiris/actions-hugo@v2 with: hugo-version: \u0026#39;latest\u0026#39; extended: true - name: Build run: hugo --minify - name: Deploy uses: peaceiris/actions-gh-pages@v3 with: personal_token: ${{ secrets.PERSONAL_TOKEN }} external_repository: username/username.github.io publish_branch: main #你的.github.io仓库分支 publish_dir: ./public commit_message: ${{ github.event.head_commit.message }} PERSONAL_TOKEN是在仓库settings中创建的repository secrets的name(当然，也可以是其它名字)，对应的secrets就是你的github access token。\n配置deploy.yml后，github就会自动把blog仓库的更新同步到另一个仓库了。\n站点目前还有不少需要改进的，比如点赞、评论之类的功能，之后回来研究吧 。 。\n有空回来更新哈哈 。 。 。（手动狗头）\n","date":"Apr 23, 2026","permalink":"https://voyager314.github.io/posts/test/","readingTime":2,"summary":"测试一下博客 这是蒟蒻第一篇博客，目前还没想好写什么 (\n使用hugo+github的静态页面托管构建：\n下载hugo Release v0.159.2 · gohugoio/hugo 。\n把hugo.exe根目录添加到系统PATH，之后就可以直接使用hugo命令了。\n","title":"Test"}]