大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
     
Harness Engineering 作为新兴工程学科，专注于设计和构建包裹 AI 模型的完整软件基础设施，确保 Agent 在复杂任务中保持可靠和可控。文章通过 OpenAI、Stripe、Cursor 等案例，揭示了 Harness Engineering 的核心组件，包括编排循环、工具系统、记忆系统、上下文管理、提示词构建、验证循环、错误处理与安全防护、子 Agent 编排等。文章强调，即使模型能力不断提升，Harness 的工程价值依然重要，它是 AI 代码生成可靠性的关键。文章还探讨了 Harness Engineering 的未来发展趋势，包括 Harness 作为新一代服务模板、技术栈收敛、新旧代码库的鸿沟、训练-推理环境的融合等。
 

---

Harness Engineering：让 AI 编码 Agent 真正可靠的新工程学科。

2025 年 8 月，OpenAI 内部一个三人工程团队做了一个极端实验：在一个空仓库中，用 0 行手写代码构建一个全新的软件产品。

五个月后，这个仓库拥有一百万行代码、1500+ 个合并的 Pull Request，产品每天被内部数百名用户使用，还有外部 Alpha 测试者。

所有代码——应用逻辑、测试、CI 配置、文档、可观测性、内部工具——全部由 Codex Agent 生成。

在 Stripe，每周有超过 1000 个完全由 AI Agent 生成的 PR 被合并到这个每年处理超过万亿美元支付量的代码库中。

这些 PR 经过人类审查，但其中没有一行人类手写的代码。

在 Cursor，一个研究团队让数千个 Agent 在一台大型虚拟机上连续运行一周，峰值时每小时产出约 1000 个 commit，构建了一个几乎完全可运行的浏览器引擎——中间不需要任何人类干预。

这些案例的共同点是什么？它们都不是简单地给 AI 一段提示词然后祈祷。

答案是：每个团队都投入了大量工程精力，构建了一套包裹 AI 模型的完整基础设施——约束、工具、反馈循环、验证机制、上下文管理系统。

这套基础设施现在有了正式名称：Harness。

随着模型能力越来越强，一个反直觉的事实正在浮现：决定 AI Agent 在生产环境中可靠性的关键因素，不是模型本身，而是围绕模型的 Harness。

LangChain 做过一个实验：他们完全不更换模型和权重，只改变了 LLM 的基础设施（Harness），在 TerminalBench 2.0 的排名就从 30 名开外跃升到第 5 名。

另一个研究项目让 LLM 自己优化 Harness，通过率达到 76.4%，超过了人工设计的系统。

这篇文章将深入剖析 Harness Engineering 这个新兴工程学科——它是什么、为什么需要它、由哪些组件构成、顶级团队如何实践它、以及如何构建你自己的 Harness。

"Harness Engineering"这个术语在 2026 年初被正式确立，但概念早已存在。

Mitchell Hashimoto（HashiCorp 联合创始人、Terraform 创造者）在其 2026 年 2 月的博客文章"My AI Adoption Journey"中首次明确提出这个概念。他写道：

Harness Engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.

Harness Engineering 的理念是：每当发现 Agent 犯了一个错误，你就花时间构建一个解决方案，确保它永远不再犯同样的错误。

几乎同时，OpenAI 发布了由 Ryan Lopopolo 撰写的长文"Harness Engineering: Leveraging Codex in an Agent-First World"，基于其零手写代码构建百万行产品的实践经验，正式确立了这一概念。

文章的核心信条是：“Humans steer. Agents execute.”（人类掌舵，Agent 执行。）

LangChain 随后给出了一个更简洁的公式化定义：

Agent = Model + Harness

LangChain 的 Vivek Trivedy 更是直接说：“如果你不是模型，你就是 Harness。”

Beren Millidge 在 2023 年的文章《Scaffolded LLMs as Natural Language Computers》中给出了一个精确的类比——原始 LLM 就像一个没有内存、没有硬盘、没有 I/O 的 CPU。

上下文窗口充当 RAM（快但有限），外部数据库充当硬盘（大但慢），工具集成相当于设备驱动，Harness 就是操作系统。

他写道：“我们重新发明了冯·诺依曼架构”，因为这是任何计算系统的自然抽象。

Anthropic 的 Claude Code 文档直接说明：SDK 就是"驱动 Claude Code 的 Agent Harness"。

OpenAI 的 Codex 团队也用同样的表述，明确把"Agent"和"Harness"等同起来，指代让 LLM 真正有用的非模型基础设施。

要理解 Harness Engineering，首先要厘清它与另外两个容易混淆的概念的边界。

模型周围有三个同心圆层次的工程：

提示词工程（Prompt Engineering）：精心制作模型接收的指令。它优化的是单轮交互中的措辞和格式。

上下文工程（Context Engineering）：管理模型看到什么、何时看到。它关注的是在单个上下文窗口的跨度内，如何选择、排序、压缩 token，以最大化模型的表现。由 Andrej Karpathy 于 2025 年 12 月提出。

Harness Engineering：涵盖前两者，加上整个应用基础设施——工具编排、状态持久化、错误恢复、验证循环、安全执行和生命周期管理。它操作的边界跨越多个上下文窗口、多个会话、甚至多个 Agent。

一个常见的误解是：Harness 只是把提示词包装了一下。但事实上，Harness 不是提示词的包装器，它是让自主智能体行为成为可能的完整系统。

综合以上所有来源：

Harness Engineering 是设计和构建包裹 AI 模型的完整软件基础设施的学科——包括编排循环、工具、记忆、上下文管理、状态持久化、验证循环、错误恢复和安全防护——使得 Agent 能够在长时间、复杂任务中保持可靠和可控。

当前 AI 能力评估最大的问题之一：Benchmark 分数和真实世界效用之间存在巨大鸿沟。

METR（Model Evaluation and Threat Research）在 2026 年 3 月发布了一项里程碑式的研究。

他们招募了 4 位活跃的开源仓库维护者（来自 scikit-learn、Sphinx、pytest），让他们在不知道代码来源的情况下，审查 296 个 AI 生成的 Pull Request。

核心发现：大约一半通过 SWE-bench 自动化测试的 AI PR，无法被真实的仓库维护者接受合并。

更具体地说：维护者合并率比自动化评分平均低 24.2 个百分点（标准误差 2.7），这一差距具有高度统计显著性

Claude Sonnet 4.5 在自动化评分下的"时间跨度"（即模型能可靠解决的任务所需的人类完成时间）约 50 分钟，但在维护者审查下仅约 8 分钟——7 倍的高估

即使是人类写的"黄金补丁"（已被合并的原始 PR），也只有 68% 被维护者接受——这反映了代码审查本身的主观性

维护者拒绝 AI PR 的原因分布（从轻到重）：

• 代码质量：风格差、不符合仓库标准
• 破坏其他代码：解决了目标问题但引入了新的破坏
• 核心功能失败：没有正确解决 Issue 中提出的问题

这个研究的意义不在于说 AI Agent 不行，而在于揭示了一个关键事实：自动化 Benchmark 测试通过，不等于真实世界中可用的代码。Agent 需要的不仅是"做对"，还需要"做好的对"——而这正是 Harness 要解决的问题。

你可能以为百万 token 的上下文窗口意味着可以往里面塞无限的信息。现实恰恰相反。

斯坦福的"Lost in the Middle"研究揭示了一个关键现象：当关键信息位于上下文窗口的中间位置时，模型的检索和推理性能下降 30% 以上。这不是某个模型的缺陷，而是 Transformer 架构的固有特性。

Chroma 的研究人员在 18 个模型上进行了针-in-a-haystack 测试，发现：上下文越长，模型性能越差——即使在简单任务上也是如此。

更糟糕的是，当问题与上下文中相关信息之间的语义相似度较低时，退化更为陡峭。

在 Agent 场景中，这个问题被急剧放大。每次工具调用的输出、每次 grep 的结果、每个文件读取——如果最终不相关，都会成为干扰项。Chroma 研究证实：干扰效应在更长的上下文窗口中会累积。

这也是为什么直接扩大上下文窗口不是万能药。更大的窗口只是让 haystack 更大，不会让模型更擅长找 needle。你可能不需要更长的上下文，而是需要更好的上下文隔离。

Google 的 DORA（DevOps Research and Assessment）报告发现了一个令人不安的趋势：更高的 AI 采用率与软件交付吞吐量的提升和不稳定性的增加同时相关。

时间节省在写代码上，但又被重新花在审查代码上。Apiiro 的 2025 年 9 月分析发现：AI 生成代码引入的安全发现数从 2024 年 12 月到 2025 年 6 月增长了 10 倍——在其研究的仓库中，每月超过 10,000 个新的安全发现。

DORA 报告还发现：30% 的开发者对 AI 生成的代码几乎没有信任。这不是态度问题，而是信任架构问题——没有适当的 Harness，Agent 的行为不可预测，审查者的认知负担反而更重。

HumanLayer 团队花了一年时间观察编码 Agent 以各种方式失败后，得出了这个结论：

每次失败后，直觉都是一样的：“更好的模型会解决它”、“等 GPT-6 就好了”。但经过几十个项目、数百个 Agent 会话后，我们反复得出同一结论：这不是模型问题，而是配置问题。

是的，模型会变强，一些当前的失败模式会消失。但因为更强的模型会被赋予更大更难的新问题，非预期失败模式是确定性系统之外的根本性问题。

与其等待gpt-6.4-codex-ultrahigh_extended来拯救一切，不如专注于一个更实际的问题：如何在今天就从现有模型中获取最大价值？

答案就是：工程化你的 Harness。

综合 Anthropic、OpenAI、LangChain、Stripe、Cursor 和更广泛的实践者社区的经验，一个生产级 Agent Harness 包含以下核心组件。理解它们最好的方式是追踪一个完整的 Agent 循环。

这是整个 Harness 的心脏。它实现的是思考-行动-观察（Think-Act-Observe，TAO）循环，也被称为 ReAct 循环：

while (模型返回工具调用): 执行工具 → 捕获结果 → 追加到上下文 → 再次调用模型 

机械上看，它就是一个 while 循环。复杂性不在于循环本身，而在于循环管理的所有东西。

Anthropic 把他们的运行时描述为"哑循环"——所有智能都在模型里，Harness 只管理回合。Claude Code 的创建者 Boris Cherny 和 Cat Wu 在播客中明确表示：

我们的方法是，所有的秘密武器都在模型里。这是最薄的可能包装器。我们真的不可能构建任何更少的东西了。

循环的终止条件是多层的：

• 模型产生不含工具调动的文本响应（自然终止）
• 超过最大回合限制
• Token 预算耗尽
• 防护栏绊线触发
• 用户中断
• 返回安全拒绝

一个简单问题可能只需 1-2 个回合。复杂的重构任务可能链接数十次工具调用、跨越多个回合。

工具是 Agent 与世界交互的接口。它们被定义为模式（名称、描述、参数类型），注入到 LLM 的上下文中，让模型知道有什么可用。

Claude Code 提供六大类工具：文件操作、搜索、执行、网络访问、代码智能和子 Agent 生成。

OpenAI 的 Agents SDK 支持三种工具类型：函数工具（通过@function_tool装饰器）、托管工具（WebSearch、CodeInterpreter、FileSearch）和 MCP 服务器工具。

但这里有一个关键洞察，很多人忽略了：更多工具 ≠ 更好性能。

Vercel 从 v0 中删除了 80% 的工具，结果反而获得了更好的表现。Claude Code 通过延迟加载实现了 95% 的上下文减少。核心原则是：暴露当前步骤所需的最小工具集。

为什么会这样？因为每个工具的定义（名称、描述、参数）都会被注入到系统提示词中，消耗宝贵的"指令预算"。当上下文中充满了不相关的工具描述，模型反而更容易迷失方向。

HumanLayer 团队分享了一个具体的例子：他们起初使用 Linear 的 MCP 服务器（提供大量工具），后来发现只用了一个小子集。于是他们写了一个小型 CLI 包装 Linear API，在 CLAUDE.md 中放了 6 个示例用法，节省了数千 token 的工具定义和冗长的 MCP 响应。

Agent 的记忆分为两类：

短期记忆是单个会话内的对话历史——模型的上下文窗口本身。它是快但有限的"RAM"。

长期记忆跨会话持久化。不同框架的实现方式不同：Anthropic 使用 CLAUDE.md 项目文件和自动生成的 MEMORY.md 文件，LangGraph 使用命名空间组织的 JSON 存储，OpenAI 支持由 SQLite 或 Redis 支持的 Sessions。

Claude Code 实现了精妙的三层层次结构：

❶ 轻量级索引：每条约 150 字符，始终加载到上下文中

❷ 详细文件：按需拉取的完整记忆

❸ 原始记录：仅通过搜索访问

一个关键的设计原则：Agent 把自己的记忆当作"提示"，在行动前会对照实际状态验证。记忆不是真理，而是一个可能有偏差的起点。这防止了记忆中的过时信息导致 Agent 做出错误决策。

这是许多 Agent 失败的地方，也是 Harness Engineering 中技术含量最高的部分。

核心问题是上下文腐烂（Context Rot）：当关键内容落在窗口中间位置时，模型性能下降。即使是百万 token 窗口，随着上下文增长，指令遵循能力也会退化。

生产环境中有四种主要策略：

❶ 压缩/总结：在接近限制时总结对话历史。Claude Code 保留架构决策和未解决的 bug，丢弃冗余的工具输出。JetBrains 的 Junie 隐藏旧的工具输出，但保持工具调用可见。

❷ 即时检索：维护轻量级标识符，动态加载数据。Claude Code 使用 grep、glob、head、tail 而不是加载完整文件。OpenAI 的做法类似——AGENTS.md 被当作"目录"，具体的知识存在于docs/目录中，Agent 按需查阅。

❸ 子 Agent 委托：每个子 Agent 广泛探索，但只返回 1000-2000 token 的压缩摘要给父 Agent。这是最强大的上下文隔离机制。

ACON 研究的发现令人鼓舞：通过优先保留推理轨迹而不是原始工具输出，可以减少 26-54% 的 token 使用量，同时保持 95% 以上的准确性。

Anthropic 的上下文工程指南用一句话总结了目标：找到最小的高信号 token 集合，最大化期望结果的可能性。

这是组装模型在每一步实际看到的内容。它是分层的：系统提示词 → 工具定义 → 记忆文件 → 对话历史 → 当前用户消息。

OpenAI 的 Codex 使用严格的优先级栈：服务器控制的系统消息（最高优先级）→ 工具定义 → 开发者指令 → 用户指令（级联的 AGENTS.md 文件，32 KB 限制）→ 对话历史。

重要上下文放在提示词的开头和结尾（基于"Lost in the Middle"发现）。中间位置留给相对不那么关键的信息。

这可能是区分"演示级 Agent"和"生产级 Agent"最关键的因素。

Claude Code 的创建者 Boris Cherny 指出：给模型一种验证其工作的方法，质量提高 2 到 3 倍。

Anthropic 推荐三种验证方法：

❶ 基于规则的反馈：测试、linter、类型检查器——提供确定性真相

❷ 视觉反馈：通过 Playwright 截图用于 UI 任务

❸ LLM-as-Judge：单独的子 Agent 评估输出——捕获语义问题但增加延迟

一个关键的设计原则：成功时静默，失败时输出详细错误。

HumanLayer 团队分享了这个经验——早期他们让 Agent 在每次变更后运行完整测试套件，4000 行通过的测试结果涌入上下文窗口，Agent 反而失去对实际任务的追踪，开始对刚读过的测试文件产生幻觉。

后来他们改为：吞掉所有成功输出，只呈现失败。

一个简单的数学问题：一个 10 步流程，每步 99% 成功率，端到端成功率仍然只有约 90.4%。如果每步 95%，端到端仅 60%。错误会快速复合。

LangGraph 区分四种错误类型：

❶ 瞬态错误：带退避重试（网络超时、API 限流）

❷ LLM 可恢复错误：将错误作为 ToolMessage 返回，让模型调整策略

❸ 用户可修复错误：中断等待人工输入（权限不足）

❹ 意外错误：冒泡用于调试

安全防护方面，OpenAI 的 SDK 实现三个级别：输入防护栏（在第一个 Agent 上运行）、输出防护栏（在最终输出上运行）和工具防护栏（在每次工具调用时运行）。"绊线"机制在触发时立即停止 Agent。

Anthropic 采用了不同的架构思路：将权限执行与模型推理分离。模型决定尝试什么，工具系统决定允许什么。Claude Code 独立管理约 40 个离散工具能力，分三个阶段：项目加载时建立信任、每次工具调用前权限检查、高风险操作的明确用户确认。

Stripe 的生产 Harness 将重试尝试上限设为两次——这是一个务实的平衡。CI 运行消耗 token、计算和时间，LLM 运行多轮完整 CI 循环的边际收益递减。他们的策略是：“通常一轮，最多两轮 CI——且只在本地修复了所有能修复的问题之后。”

子 Agent 可能是 Harness 中最强大但也最被误解的组件。

很多人的直觉是创建"前端工程师 Agent"、“后端工程师 Agent”、"数据分析师 Agent"这种角色划分。HumanLayer 团队明确说：这不 work。

子 Agent 真正的价值在于上下文控制——它是一个"上下文防火墙"。子 Agent 提供了一种方式来封装整个编码 Agent 会话的工作：发起 Agent 只看到它写给子 Agent 的提示词和子 Agent 的最终结果。所有中间的工具调用、工具结果和其他消息都不会出现在发起 Agent 的上下文窗口中。

这种方式保持了主 Agent 在"聪明区"——上下文小、相关性高、指令预算充裕。

子 Agent 的优秀使用场景包括：

• 在代码库中定位特定定义或实现
• 分析代码库以识别特定类型工作的模式
• 追踪信息在代码库中的流动（如跨服务边界追踪请求）

其他需要大量中间工具调用但最终答案简洁的研究任务

它还有一个额外的好处：成本控制。

可以在父 Agent 使用昂贵模型（Opus）做思考密集型任务（规划、编排），在子 Agent 使用更便宜更快的模型（Sonnet 或 Haiku）执行具体任务——没必要在代码库 grep 上烧 Opus token。

不同框架对状态管理有不同策略：

❶ LangGraph：将状态建模为流经图节点的类型化字典，用 reducer 合并更新。检查点发生在"超级步骤"边界，支持中断后恢复和时间旅行调试

❷ OpenAI：提供四种互斥策略——应用程序内存、SDK 会话、服务器端 Conversations API、轻量级previous_response_id链接

❸ Claude Code：用 git 提交作为检查点，进度文件作为结构化草稿本

Hooks（钩子）是另一个强大的控制流机制。Claude Code 支持 Hooks——在 Agent 生命周期的特定事件和节点自动执行的用户定义命令或脚本。常见用途包括：

❶ 通知：Agent 完成时播放声音，审批待决过久时提醒

❷ 审批：基于输入值自动批准或拒绝工具调用（如自动拒绝任何尝试运行数据库迁移的 Bash 调用）

❸ 集成：完成后发送 Slack 消息、创建 GitHub PR、设置预览环境

❹ 验证：Agent 停止时自动运行 typecheck 和 formatter，失败时强制 Agent 继续修复

这是目前公开的最极端的 Harness Engineering 案例。

团队与产出：3 名工程师（后扩展到 7 名），5 个月内构建了约 100 万行代码的生产产品。

1500+ PR 合并，平均每人每天 3.5 个 PR——而且这个吞吐量随团队扩展而增加。产品每天被内部数百名用户使用，包括深度用户。

核心哲学：人类从不直接写代码。团队的工作不是编写代码，而是设计环境、明确意图、构建反馈循环，让 Codex Agent 做可靠的工作。

上下文工程的突破性实践：

OpenAI 团队最早也是最重要的教训之一：给 Agent 一张地图，而不是 1000 页的说明书。

他们列出了为什么巨型指令文件不可行的四个原因：

❶ 上下文是稀缺资源：巨型指令文件挤占了任务、代码和文档的空间

❷ 太多指导变成无指导：当一切都是"重要的"，就没有什么是重要的

❸ 它会即时腐烂：一体化手册变成了过时规则的坟墓，Agent 无法分辨哪些仍然有效

❹ 难以验证：单个 blob 无法进行机械检查（覆盖率、新鲜度、所有权、交叉链接），漂移不可避免

因此，他们把 AGENTS.md 当作目录而不是百科全书。仓库的知识库存在于结构化的docs/目录中，作为系统的记录。一个约 100 行的 AGENTS.md 被注入上下文，主要作为地图，指向更深层的真相来源。

他们还通过专门的 linter 和 CI 任务验证知识库是否最新、交叉链接正确。一个"文档园丁"Agent 定期扫描过时或过期的文档，打开修复 PR。

架构约束的极致实践：

因为仓库完全由 Agent 生成，所以它首先为Agent 的可读性而非人类的可读性进行优化。他们构建了极其严格的分层架构：

Types → Config → Repo → Service → Runtime → UI

在每一层，代码只能"向前"依赖。跨领域关注点（auth、connectors、telemetry、feature flags）通过单一接口（Providers）进入。其他一切都被禁止并通过自定义 linter 机械地强制执行。

OpenAI 团队坦言：这是你通常在有数百名工程师之前不会实施的架构。但对于编码 Agent，它是早期前提条件——约束就是允许速度而不衰退的东西。

他们还编码了一组"品味不变量"：静态强制结构化日志、命名约定、文件大小限制、平台特定的可靠性要求。因为这些 lint 是自定义的，他们把错误信息写成包含修复指令的形式——lint 消息本身变成了 Agent 的上下文。

"垃圾回收"机制：

全 Agent 生成的代码库面临一个独特问题：Agent 会复制仓库中已有的模式——即使是不均匀或次优的模式。久而久之，这不可避免地导致漂移。

最初，团队每周五花 20% 的时间清理"AI slop"。不出所料，这不 scale。

解决方案是编码"黄金原则"并构建定期清理流程：一组后台 Codex 任务定期扫描偏差、更新质量评级、打开针对性的重构 PR。大多数可以在一分钟内审查并自动合并。

这像垃圾回收：技术债务就像高息贷款——几乎总是以小增量持续偿还好过让它复合后在痛苦的爆发中处理。

可观测性的突破：

他们让应用可以在每个 git worktree 中启动，这样 Codex 可以每个变更启动一个实例。他们还将 Chrome DevTools Protocol 接入 Agent 运行时，创建了用于 DOM 快照、截图和导航的 skills。这让 Codex 可以直接复现 bug、验证修复、推理 UI 行为。

可观测性工具也做了同样处理：日志、指标和追踪通过本地可观测性栈暴露给 Codex——每个 worktree 对应一个临时实例。

Agent 可以用 LogQL 查询日志、用 PromQL 查询指标。"确保服务启动在 800ms 内完成"或"这四个关键用户旅程中没有 span 超过两秒"这类提示词变得可执行。

Stripe 的案例特别有价值，因为它展示了 Harness Engineering 在极端复杂性的现有代码库中的应用——与 OpenAI 从零开始的场景截然不同。

背景：Stripe 的代码库包含数亿行代码，跨几个大型仓库。大部分后端用 Ruby（非 Rails）+ Sorbet 类型系统编写——一个相对不常见的技术栈。代码使用大量 Stripe 自建的库，这些库天然不在 LLM 的训练数据中。这个代码每年处理超过 1 万亿美元的支付量。

核心洞察：

LLM Agent 在从零构建软件时非常出色，因为约束很少。但在 Stripe 规模、复杂度和成熟度的代码库上迭代，本质上更难。

Devbox 架构：Minion 运行在隔离的开发环境中（“Devbox”），与 Stripe 工程师编写代码时使用的相同类型的机器。Devbox 预热后 10 秒内可以启动，Stripe 代码和服务预加载。它们与生产资源和互联网隔离，因此可以在无需人类权限检查的情况下运行 Minion。这也实现了并行化，无需 git worktree 的开销。

MCP 工具生态：Stripe 构建了一个名为 Toolshed 的中心内部 MCP 服务器，托管超过 400 个 MCP 工具，覆盖内部系统和 SaaS 平台。Minion 和其他 Agent 可以连接到可配置但经过策展的工具子集。

Minion 还在运行前确定性执行相关 MCP 工具来补充上下文——在 Agent 运行之前就解析可能相关的链接。

确定性代码与 Agent 创造性的交织：

这是 Stripe 设计中最有启发性的部分：Minion 的编排流程以 opinionated 的方式交织 Agent 循环和确定性代码。git 操作、linter、测试等步骤是确定性的，与 Agent 的创造性工作交替进行。这确保了每次 Minion 运行都混合了 Agent 的创造性和 Stripe 要求的步骤（如 linter）的保证。

CI 策略的务实平衡：

• 第一道防线：本地自动执行，使用启发式方法选择并自动运行 lint——不到 5 秒
• 如果本地没发现问题，CI 从 Stripe 的 300 万+ 测试中选择性运行
• 许多测试有自动修复，失败时自动应用
• 如果测试失败且没有自动修复，返回给 Minion 尝试修复
• 最多两轮 CI：速度与完整性的平衡

Stripe 的经验："对人类好的工具，对 Agent 也好。"Minion 使用与 Stripe 人类工程师相同的开发者工具。这一理念贯穿了整个设计。

Cursor 的研究展示了 Harness Engineering 在多 Agent 大规模并行场景中的演化过程——以及设计决策如何一步步被推翻和重建。

从单 Agent 到多 Agent 的演化历程：

第一版：单 Agent。最初的尝试是让单个 Opus 4.5 构建浏览器引擎。这很快失败了——模型失去追踪，频繁提前宣布成功，在复杂的实现细节上卡住。但它在小片段中展现了深厚的知识和智能。核心问题：浏览器太复杂了，需要拆分。

第二版：自协调。让多个平等角色的 Agent 通过共享状态文件看到其他人在做什么、决定自己做什么、更新文件。这很快也失败了——协调文件制造了更多问题：Agent 持锁太久、忘记释放、尝试非法锁定/解锁。锁定也造成了过多争用：20 个 Agent 慢到只有 1-3 个的吞吐量。没有结构意味着没有 Agent 愿意承担大而复杂的任务。

第三版：角色分离。分离了规划器（Planner）、执行器（Executor）和工作器（Worker）角色。规划器确定方法，执行器负责监督完成，Worker 提供线性扩展。独立的评判者（Judge）在执行器完成后判断是否完成。这解决了很多协调问题，但最终被最慢的 Worker 瓶颈，太僵硬了。

第四版：连续执行器。移除了独立规划器，让执行器同时规划和执行。引入了新鲜度机制：scratchpad.md 应该频繁重写而不是追加；Agent 在达到上下文限制时自动总结；自我反思和对齐提醒。但这导致了病态行为——执行器被分配了太多角色（规划、探索、研究、派发任务、检查 Worker、审查代码、执行编辑、合并输出、判断循环是否完成），最终被压垮。

第五版：最终架构——这是目前的设计：

❶ 根规划器（Root Planner）：拥有用户指令的完整范围。它负责理解当前状态并交付具体的、有针对性的任务。它不做任何编码。它不知道自己的任务是否被拾取或被谁拾取。

❷ 当规划器认为其范围可以细分时，它派生子规划器（Subplanner）完全拥有委托的狭窄切片。这是递归的。

❸ Worker：拾取任务并完全负责推动完成。它们不知道更大的系统。它们不与其他规划器或 Worker 通信。它们在仓库的副本上工作，完成后写一个单一的交接文档。

交接文档不仅包含做了什么，还包含重要的笔记、担忧、偏差、发现、想法和反馈。规划器作为后续消息接收这些。这让系统保持持续运动：即使规划器"完成了"，它也继续接收更新，拉取最新的仓库，继续规划和做出后续决策。

Cursor 团队发现了一个有趣的相似性：这个结构与一些软件团队今天的运作方式惊人地相似。而这些模型并没有被明确地训练为这样工作——这表明它可能是涌现行为，也可能是构建软件项目的"正确方式"。

关于正确性的关键取舍：

当 Cursor 要求每次提交前 100% 正确时，会导致严重的序列化和有效吞吐量下降。即使是一个小错误（如 API 变更或拼写错误），也会导致整个系统停滞。Worker 会超出自己的范围去修复不相关的事情。多个 Agent 会在同一问题上踩踏。

允许一些松弛意味着 Agent 可以信任其他问题会被同伴 Agent 很快修复——这是真实的，因为系统对整个代码库有有效的所有权和委托。错误率保持小且恒定，也许永远不会完全清零，但稳定且可管理，不会爆炸或恶化。

吞吐量峰值：约 1000 commits/小时，1000 万次工具调用，持续一周。

关于指令的重要性：

Cursor 团队得出了一个重要结论：给这个多 Agent 系统的指令非常重要。最初他们没把指令作为主要目标，而是先追求稳定有效的 Harness。但指令的重要性很快就显现了——本质上是在与一个典型的编码 Agent 交互，只是多了数量级的时间和计算。这放大了一切，包括次优和不清晰的指令。

他们的经验：

不要指示模型做它已经知道如何做的事，只告诉它不知道的（如多 Agent 协作）或特定于领域的（如何运行测试、部署流程）。把模型当作一个聪明的新人——懂工程但不懂你的代码库和流程。

约束比指令更有效。"不允许 TODO，不允许部分实现"比"记得完成实现"更好。模型默认会做好事，约束是定义边界。

给出具体数字。"生成许多任务"倾向于产生少量保守的输出。"生成 20-100 个任务"传达了更大的范围意图。

Mitchell Hashimoto（HashiCorp 联合创始人）的旅程可能是最能引起普通工程师共鸣的案例——它展示了一个从怀疑到精通的渐进过程。

Step 1：放弃聊天机器人。他明确指出：立即停止试图通过聊天机器人（如 ChatGPT、Gemini web 版）做有意义的工作。聊天界面在编码中的效用高度有限。要找到真正的价值，你必须使用 Agent——一个可以读取文件、执行程序、发起 HTTP 请求的 LLM。

Step 2：重现自己的工作。他开始使用 Claude Code，但最初并不满意。于是他做了一个极其费力的练习：强迫自己用 Agent 复现所有手动 commit 的结果。他真的把工作做了两次——先手动做一遍，再让 Agent 产生相同质量和功能的结果（当然不让它看到手动方案）。

这很痛苦，但他从中获得了深刻的第一性原理理解：

• 把会话分解为独立、清晰、可操作的任务，不要试图一次性"画猫头鹰"
• 对于模糊的需求，把工作分为独立的"规划"和"执行"会话
• 如果给 Agent 一种验证自己工作的方法，它通常能修复自己的错误并防止回归

Step 3：下班前启动 Agent。他开始每天最后 30 分钟启动一个或多个 Agent。这不是让 Agent 通宵运行，而是在他不能工作的时间里让 Agent 做一些积极的进展。特别是：深度研究会话、并行尝试不同的模糊想法、Issue 和 PR 分拣/审查。

Step 4：外包确定性任务。到了这个阶段，他对哪些任务 AI 擅长、哪些不擅长有了很高的信心。每天开始时，他从前一晚的分拣 Agent 结果中过滤出 AI 几乎肯定能很好解决的问题，让 Agent 在后台做这些——同时他自己做别的事情。

一个关键建议：关闭 Agent 桌面通知。上下文切换非常昂贵。由人类控制何时中断 Agent，而不是反过来。

Step 5：工程化 Harness——这就是 Harness Engineering 概念的诞生。Mitchell 指出，Agent 在第一次产生正确结果时效率最高。确保这一点的最可靠方法是：给 Agent 快速、高质量的工具来自动告诉它什么时候错了。

Harness Engineering 有两种形式：

❶ 更好的隐式提示（AGENTS.md）：对于简单的事情，如 Agent 反复运行错误命令或找到错误的 API

❷ 实际的编程工具：例如截图脚本、过滤测试运行等。通常与 AGENTS.md 变更配对

Step 6：始终有 Agent 运行。他的当前目标：如果 Agent 没在运行，问自己"有没有什么 Agent 可以为我做的？"他特别喜欢结合更慢、更深思熟虑的模型（如 Amp 的 deep mode，基本上就是 GPT-5.2-Codex），可能要 30+ 分钟做一个小改动——但结果往往非常好。

Harness Engineering 的兴起引发了 AI 行业最激烈的争论之一：Harness 的价值到底是暂时的还是持久的？

"Big Model"阵营认为，随着模型能力提升，当前所需的复杂 Harness 将被淘汰——就像更好的 CPU 让操作系统变得更简单一样。

Noam Brown（OpenAI，推理模型核心研究者）的观点最为激进：

在推理模型出现之前，有很多工程工作投入到构建 agentic 系统中，对 GPT-4o 或非推理模型进行大量调用来获得推理行为。然后我们创造了推理模型，你不需要这种复杂行为了。事实上，在很多方面，它让事情变得更糟。那些脚手架最终也会被推理模型和更强大的模型所取代。

Claude Code 团队（Boris Cherny 和 Cat Wu）在播客中的表述：

我们的 Harness 是最薄可能的模型包装器。我们真的不可能构建任何更少的东西了。它还在变得更简单——我们大概每三四个月就从头重写一次，就像忒修斯之船一样，每一块都被替换了。

Anthropic 定期从 Claude Code 的 Harness 中删除规划步骤，因为新模型版本已经内化了这种能力。

METR 的研究也为这一阵营提供了弹药：Claude Code 和 Codex（都是精心设计的 Harness）并没有显著优于基本的通用 Harness。Scale AI 的 SWE-Atlas 发现 Opus 4.6 在 Claude Code 中比通用 SWE-Agent 好 2.5 个百分点——但 GPT 5.2 的结果恰恰相反。你选择的 Harness 基本上是误差范围内的噪音。

"Big Harness"阵营认为，即使模型不断改进，Harness 的工程价值也是持久的——甚至可能是竞争差异化的关键来源。

Jerry Liu（LlamaIndex 创始人）：“Model Harness is Everything——从 AI 中获取价值的最大障碍是你自己对模型进行上下文和工作流工程的能力。”

TerminalBench 的证据：LangChain 实验明确显示，仅改变 Harness（模型完全不变），Agent 在 TerminalBench 2.0 上移动了 20 多个排名位置。

更引人注目的是，Opus 4.6 在 Claude Code（其训练时使用的 Harness）中排 #33，但在另一个 Harness 中排 #5——暗示模型可能被过拟合到其训练时的 Harness。

Cursor 的经验：多 Agent 系统的架构设计——从角色分离到递归子规划器——这些是 Harness 层面的工程决策，与模型能力无关。更好的模型让单个 Agent 更强，但不解决协调、争用、交接等系统级问题。

Rich Sutton 的著名文章《The Bitter Lesson》指出：使用计算的通用方法每次都胜过手工编码的人类知识。

这个教训正在 Agent 开发中重演：

• Manus 在六个月内将 Harness 重构了五次，以移除刚性的假设
• LangChain 在一年内将其"Open Deep Research"Agent 重构了三次
• Vercel 删除了 80% 的工具，获得了更少的步骤、更少的 token、更快的响应

Philipp Schmid 给出了三条指导原则：

❶ 从简单开始：不要构建庞大的控制流。提供健壮的原子工具。让模型制定计划。实施防护栏、重试和验证。

❷ 为删除而构建：使你的架构模块化。新模型将取代你的逻辑。你必须准备好随时撕掉代码。

❸ Harness 就是数据集：竞争优势不再在于提示词。而在于你的 Harness 捕获的轨迹。Agent 在长任务中未能遵循指令的每一次失败，都可以用于训练下一次迭代。

这里有一个关键的协同进化原则：模型现在在循环中使用特定 Harness 进行后训练。Claude Code 的模型学会了使用它训练时的 Harness。

OpenCode（Claude Code 的开源替代）不得不为 GPT/Codex 模型添加apply_patch工具来模拟 Codex Harness——否则 Codex 模型在非原生 Harness 中表现更差。

这导致了一个实用的"未来验证测试"：如果性能随更强模型提升而不增加 Harness 复杂度，设计就是对的。

1. 单 Agent vs. 多 Agent

Anthropic 和 OpenAI 都说：首先最大化单个 Agent。多 Agent 系统增加开销（路由的额外 LLM 调用、交接期间的上下文丢失）。仅当工具过载超过约 10 个重叠工具或存在明显独立的任务域时才拆分。

2. ReAct vs. 计划-执行

ReAct 在每一步交织推理和行动（灵活但每步成本更高）。计划-执行将规划与执行分离。LLMCompiler 报告比顺序 ReAct 快 3.6 倍。

3. 上下文窗口管理策略

五种生产方法：基于时间的清除、对话总结、观察遮蔽、结构化笔记和子 Agent 委托。优先考虑推理轨迹而不是原始工具输出。

4. 验证循环设计

计算验证（测试、linter）提供确定性真相。推理验证（LLM-as-Judge）捕获语义问题但增加延迟。Martin Fowler 的 Thoughtworks 团队将此框架化为“指南”（前馈，行动前引导）与“传感器”（反馈，行动后观察）。

5. 权限和安全架构

宽松（快但有风险）vs. 限制性（安全但慢）。选择取决于部署环境。

6. 工具范围策略

更多工具通常意味着更差的性能。原则：暴露当前步骤所需的最小工具集。如果 Agent 不在用某个提供大量工具的 MCP 服务器，关掉它。

7. Harness 厚度

薄 Harness（Anthropic 路线，押注模型改进）vs. 厚 Harness（基于图的框架，押注显式控制）。Anthropic 的做法是定期从 Harness 中删除被新模型内化的功能。

Harness Engineering 的防护措施通过加强的层运作：预防性控制（在不需要的输出发生前阻止）和纠正性控制（检测违规并触发响应）。

Layer 1：约束 Harness（前馈控制）

约束在生成开始前减少 Agent 的解空间。规则文件、架构 lint 配置和类型系统都作为前馈控制运作。它们编码了正确代码的样子，让 Agent 更快地收敛到合规输出。

OpenAI 的生产系统强制执行"品味不变量"：一组编码团队工程标准和设计哲学的规则，包括通用编码约定和可靠性要求。全部作为硬 CI 失败执行，不是警告。

Layer 2：反馈循环（纠正控制）

反馈循环将结构化错误信号返回给 Agent，实现自主自我纠正。关键的实现细节：lint 消息本身变成了 prompt。一个说"违规被检测到"的 lint 错误需要人类解释。一个说"使用logger.info({event: ‘name’, …data})而不是console.log"的 lint 错误让 Agent 可以在不需人类干预的情况下修复违规。

一个很多人忽视的细节：内联禁用规则（如// eslint-disable-next-line）应该被禁用——防止 Agent 压制违规而不是修复它们。

Layer 3：质量门禁（强制执行）

质量门禁阻止不合格代码被合并。标准 CI 管道对 AI 生成代码不够——Agent 引入的问题是常规检查可能遗漏的。一些团队添加了专门的"新鲜度门禁"来捕获与代码库当前策略不匹配的依赖选择。

所有规则设为"error"而非"warn"，使它们成为硬门禁而非建议信号。

PEV（Plan-Execute-Verify）是一个三阶段 Agent 架构，将规划与执行分离，并将验证作为结构化反馈循环强制执行。

它不同于简单的"生成-检查"工作流：

预执行门禁在工具调用前触发：这是已知工具吗？参数有效吗？此操作需要用户批准吗？请求的路径在工作空间内吗？

计划对齐门禁处理测试套件无法捕获的问题：Agent 使用了现有的 auth middleware 还是创建了新的？它遵循了响应格式约定吗？这些是标准测试运行器看不见的架构问题。

HumanLayer 团队花了一年时间试错，总结出了清晰的"不该做"清单：

不要试图预先设计完美的 Harness。在你还没遇到真正的失败之前就试图设计理想的 Harness 配置。偏见于交付——只在 Agent 实际失败时才花时间工程化解决方案。

不要安装大量 MCP 服务器"以防万一"。不活跃的 MCP 服务器不仅浪费指令预算，还可能成为 prompt injection 的攻击面。

不要每次会话后运行完整测试套件。HumanLayer 的教训——4000 行通过的测试结果涌入上下文，Agent 反而失去对实际任务的追踪。运行子集，且只呈现失败。

不要微观管理子 Agent 的工具访问。这导致了大量的工具抖动，效果更差而不是更好。

不要把 AGENTS.md 当作百科全书。ETH Zurich 的研究测试了 138 个 Agent 文件，发现：LLM 生成的实际上损害性能，人类编写的只帮助约 4%。代码库概览和目录列表毫无帮助——Agent 自己发现仓库结构就好。HumanLayer 的 CLAUDE.md 不到 60 行。

Harness Engineering 没有度量就是猜测。关键指标包括：

DORA 报告警告：不要用"代码行数"或"AI 建议使用次数"等窄指标衡量。这些衡量的是数量，不是可靠性，不应作为 Harness 效果的主要信号。

一个实用的启动建议：审计最近 5 个 Agent 生成的 PR，找出反复出现的债务模式。选择三个本可以阻止这些问题的约束。编码为 lint 规则（带有修复指令的错误消息），在违规时 CI 失败。然后度量审查时间和缺陷逃逸率的前后变化。

Martin Fowler 站点上的 Thoughtworks 分析师提出了一个引人深思的假设：Harness 会不会成为新的服务模板？

大多数组织只有两三个主要技术栈——不是每个应用都是独特的雪花。今天的"黄金路径"服务模板帮助团队快速实例化新服务。未来，团队是否会选择一套为常见应用拓扑预构建的 Harness？包含自定义 linter、结构测试、基础上下文和知识文档、以及额外的上下文提供者？

如果是这样，我们会看到类似的分叉和同步挑战——就像今天团队在使用服务模板时遇到的：贡献回模板的经验，其他团队难以合并更新。

随着编码从"打字"转向"引导生成"，AI 可能推动我们走向更少的技术栈。框架和 SDK 的可用性仍然重要——对人类好的，对 AI 也好的这一原则反复被验证。但开发者在细节层面的个人品味将变得不那么重要。小的不效率和接口中的特质将不那么令人烦恼，因为我们不再直接处理它们。

我们可能会选择有良好 Harness 可用的技术栈，并优先考虑"AI 友好性"。这不仅适用于技术栈，也适用于代码库结构和拓扑——我们可能默认选择更容易用 AI 维护的结构，因为它们更容易被 Harness 管理。

假设我们开发出了好的 Harness 技术，可以将 AI 自主性调高到 9 并增加对结果的信心。哪些技术可以应用到现有应用，哪些只对从头构建的应用有效？

对于老旧代码库，我们需要考虑改造 Harness 是否值得。AI 可以帮助我们更快地做这件事，但这些应用通常如此非标准化且充满熵，以至于可能不值得。这就像在一个从未用过静态分析工具的代码库上首次运行——然后被警报淹没。

Philipp Schmid 指出了未来的方向：我们正在走向训练和推理环境的融合。新的瓶颈将是上下文持久性。Harness 将成为解决"模型漂移"的主要工具——实验室将使用 Harness 来精确检测模型在第 100 步之后何时停止遵循指令或正确推理。这些数据将直接反馈到训练中，创建不会在长任务中"疲劳"的模型。

这意味着 Harness 捕获的轨迹数据将成为训练下一版模型的关键资产。Harness 就是数据集。

方向是更薄的 Harness。

随着模型改进，Harness 复杂性应该降低——建筑完成后，脚手架会被拆除。Manus 六个月内重写了五次 Harness，每次都删除了复杂性。

但 Harness 本身不会消失。即使最有能力的模型也需要一些东西来管理其上下文窗口、执行其工具调用、持久化其状态并验证其工作。

事实可能介于两个极端之间：一些今天的 Harness 复杂性确实会被更强的模型取代（如 Noam Brown 预测的那样），但另一些（如上下文管理、验证循环、安全防护）是计算系统的根本需求，不会消失。

关键问题是：你构建的是哪种 Harness？是那种会被下一个模型版本淘汰的，还是那种会随着模型进化而变得更有效的？

01

什么是AI大模型应用开发工程师？

如果说AI大模型是蕴藏着巨大能量的“后台超级能力”，那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。

AI大模型应用开发工程师是基于AI大模型，设计开发落地业务的应用工程师。

这个职业的核心价值，在于打破技术与用户之间的壁垒，把普通人难以理解的算法逻辑、模型参数，转化为人人都能轻松操作的产品形态。

无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能，还是办公场景中的自动记账工具、会议记录用的语音转文字APP，这些看似简单的应用背后，都是应用开发工程师在默默搭建技术与需求之间的桥梁。

他们不追求创造全新的大模型，而是专注于让已有的大模型“听懂”业务需求，“学会”解决具体问题，最终形成可落地、可使用的产品。

给大家整理了一份AI大模型全套学习资料，这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取 【保证100%免费】

02

AI大模型应用开发工程师的核心职责

需求分析与拆解是工作的起点，也是确保开发不偏离方向的关键。

应用开发工程师需要直接对接业务方，深入理解其核心诉求——不仅要明确“要做什么”，更要厘清“为什么要做”以及“做到什么程度算合格”。

在此基础上，他们会将模糊的业务需求拆解为具体的技术任务，明确每个环节的执行标准，并评估技术实现的可行性，同时定义清晰的核心指标，为后续开发、测试提供依据。

这一步就像建筑前的图纸设计，若出现偏差，后续所有工作都可能白费。

技术选型与适配是衔接需求与开发的核心环节。

工程师需要根据业务场景的特点，选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同，选型的合理性直接影响最终产品的表现。

同时，他们还要对行业相关数据进行预处理，通过提示词工程优化模型输出，或在必要时进行轻量化微调，让基础模型更好地适配具体业务。

此外，设计合理的上下文管理规则确保模型理解连贯需求，建立敏感信息过滤机制保障数据安全，也是这一环节的重要内容。

应用开发与对接则是将方案转化为产品的实操阶段。

工程师会利用选定的开发框架构建应用的核心功能，同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通，确保数据流转顺畅。

在这一过程中，他们还需要配合设计团队打磨前端交互界面，让技术功能以简洁易懂的方式呈现给用户，实现从技术方案到产品形态的转化。

测试与优化是保障产品质量的关键步骤。

工程师会开展全面的功能测试，找出并修复开发过程中出现的漏洞，同时针对模型的响应速度、稳定性等性能指标进行优化。

安全合规性也是测试的重点，需要确保应用符合数据保护、隐私安全等相关规定。

此外，他们还会收集用户反馈，通过调整模型参数、优化提示词等方式持续提升产品体验，让应用更贴合用户实际使用需求。

部署运维与迭代则贯穿产品的整个生命周期。

工程师会通过云服务器或私有服务器将应用部署上线，并实时监控运行状态，及时处理突发故障，确保应用稳定运行。

随着业务需求的变化，他们还需要对应用功能进行迭代更新，同时编写完善的开发文档和使用手册，为后续的维护和交接提供支持。

03

薪资情况与职业价值

市场对这一职业的高度认可，直接体现在薪资待遇上。

据猎聘最新在招岗位数据显示，AI大模型应用开发工程师的月薪最高可达60k。

在AI技术加速落地的当下，这种“技术+业务”的复合型能力尤为稀缺，让该职业成为当下极具吸引力的就业选择。

AI大模型应用开发工程师是AI技术落地的关键桥梁。

他们用专业能力将抽象的技术转化为具体的产品，让大模型的价值真正渗透到各行各业。

随着AI场景化应用的不断深化，这一职业的重要性将更加凸显，也必将吸引更多人才投身其中，推动AI技术更好地服务于社会发展。

给大家整理了一份AI大模型全套学习资料，这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取 【保证100%免费】