Context Engineering要过时？AI圈新风口「Harness Engineering」，OpenAI/Anthropic齐发力

原文: https://mp.weixin.qq.com/s/O_K5s6qjI7Kp_eOU_we4Fg
欢迎关注公zh: AI-Frontiers

LLM往期文章推荐

3年，从0到全球领跑：万字长文拆解DeepSeek大模型技术演进

从ResNet到mHC：DeepSeek重构残差连接，额外开销仅6.7%，附复现代码

收藏！LLM开发全链路：5大步骤+15大框架，从数据治理到RLHF一文通关

收藏！LLM-RL训练框架：3大流派+6大框架，一文搞定

万字长文解读Qwen进化史：27篇论文深度复盘Qwen模型家族

随着LLM从简单的chatbot演进为可自主执行复杂任务的Agent，AI圈的范式正在发生深刻的转变。

最近，AI圈内又火了一个新名词：Harness Engineering。

遥想当年，Prompt Engineering刚摸到门道，Context Engineering闪亮登场；Context Engineering刚弄明白，Harness Engineering又强势来袭。短短一个月，整个社区都在热议，从OpenClaw到智能Agent，再到「未来人类究竟该扮演什么角色」，话题热度居高不下。

Harness Engineering的起源与社区爆发历程

image

Harness Engineering并非横空出世，而是由行业先驱在解决AI Agent落地痛点时，不断的实践累积而成的共识。这一过程标志着开发者从「指令编写者」向「系统架构师」的身份转变。

Mitchell Hashimoto的先驱性探索

Harness Engineering术语的普及，很大程度上归功于HashiCorp的联合创始人、Terraform的创造者Mitchell Hashimoto。2月5日，在他的技术博客「My AI Adoption Journey」（https://mitchellh.com/writing/my-ai-adoption-journey）中，分享了 AI 编程六条进阶路径。并指出：即便使用最强模型，简单交互无法解决生产级复杂问题。靠改提示词修复 Agent 错误，只会陷入「打地鼠」式循环，旧问题刚改、新幻觉又来。

Hashimoto提出Harness Engineering,其核心思想：每当Agent出错，不用自然语言临时修正，而是用工程化约束、闭环校验与自动化工具，从逻辑上杜绝同类问题复现。即，将基础设施即代码（IaC）的严谨性带入了 AI 领域，确立了治理架工程的基调：构建一个「确定性」的壳，来包裹「概率性」的核。

OpenAI 的规模化验证

在Hashimoto的理念Harness Engineering出现后，仅6天后，OpenAI Codex团队发布了一项震撼性的实验报告「Harness engineering: leveraging Codex in an agent-first world」（https://openai.com/zh-Hans-CN/index/harness-engineering/），将Harness Engineering概念推向了社区讨论的巅峰。OpenAI宣布，在无人工手写代码的情况下，构建了超100万行代码的生产级应用。

项目的核心并非依赖某种「超级提示词」，而是一套高度自动化的Harness Engineering系统。工程师角色转为「领航员」与「环境设计师」，通过严格分层架构（Types→Config→Repo→Service→Runtime→UI），并由 Codex自动生成Linter与结构化测试，强制约束架构。

OpenAI 的规模化验证

Anthropic的理论深化

一个月后，在OpenAI发布官方博客的同一时期，Anthropic也发布了题为「Harness design for long-running application development」（https://www.anthropic.com/engineering/harness-design-long-running-apps）的技术文章，为 Harness Engineering概念提供了更深层次的技术内涵。Anthropic的文章重点关注了长期运行应用的工程设计，特别是在前端设计和自主软件工程领域的实践。

Anthropic分享了Harness Design的两个核心经验：将任务分解为可处理的块，以及使用结构化工件在会话之间传递上下文。最终结果是一个三智能体架构（规划器、生成器和评估器）能够在数小时的自主编码会话中生成丰富的全栈应用。

值得注意的是，Anthropic的实践特别强调了上下文重置（context reset）的重要性。实践发现，对于像Claude Sonnet 4.5这样模型，存在强烈的「上下文焦虑（context anxiety）」，仅靠压缩无法解决，因此上下文重置成为 Harness设计的关键要素。

什么是Harness Engineering

Harness Engineering是指设计、构建和迭代一套完整的运行环境与制度体系，包含工具接口、沙箱环境、架构约束、自动化测试、反馈循环及监控仪表盘，旨在引导和约束AI智能体，使其能够自主、可靠地完成复杂长周期任务，而无需人类实时干预。

Harness Engineering的核心公式可以表达为「Agent = Model + Harness」，揭示了Harness Engineering的本质：模型负责原始推理能力，而Harness负责除此之外的一切。从技术架构角度看，Harness是模型之外、构建者可以工程化控制、让Agent真正能干活的那部分系统。

Anthropic对Harness的定义更加简洁有力：「模型之外的一切」，所有的代码、配置、执行逻辑、约束规则、反馈回路，只要不是模型本身，都属于Harness的范畴。这一定义明确了Harness的边界，将所有工程化可控的部分都纳入其中。

从学科角度看，Harness Engineering是一门设计约束（constraints）、上下文（context）和反馈循环（feedback loops）来围绕AI模型构建可靠系统的学科。它不仅关注技术实现，更强调系统性的工程思维和架构设计。

Harness Engineering的核心组件

要构建一个工业级的治理架，需要深入理解其内部的技术细节。基于OpenAI、Stripe和Anthropic 的实践，可以总结出以下核心组件：

① 确定性约束门控

这是Harness Engineering与传统AI应用最大的不同。不请求代理遵循规则，而是通过工程手段强制执行。

  • 架构Linter： 自动检测代码变更是否违反了预定义的依赖规则（例如UI层不得直接调用DB）。

  • 重试上限 (Retry Caps****)： 鉴于LLM的随机性，如果一个代理在两次尝试后仍无法修复编译错误，Harness会判定进一步重试的收益递减，转而呼叫人类。Stripe发现两轮重试是一个平衡成本与成功率的临界值。

  • 前置提交钩子 (Pre-commit Hooks****)： 代理生成的任何内容都必须先通过死代码检测、静态类型检查（如 Pyright）和Shell脚本校验，才能被正式视为「成果」。

② 反馈循环与自我验证

代理的闭环进化依赖于「执行错误」作为学习信号。

  • 写-测-修 循环 (Write-Test-Fix Cycle)： Harness在沙盒中自动运行测试。如果失败，它不会让代理「重写」，而是将堆栈跟踪信息喂回给代理，促使其基于错误进行推理。

  • 预完工检查清单 (Pre-completion Checklist)： 在代理宣告任务完成之前，Harness会强行触发一个独立审计代理，逐项核对任务需求是否被满足。这一机制在LangChain的实验中提升了13.7%「The Anatomy of an Agent Harness」（https://blog.langchain.com/the-anatomy-of-an-agent-harness/）的基准测试分数。

③ 上下文治理与「Gardening」

在大规模代码库中，上下文污染是代理失效的主因。

  • 上下文防火墙 (Context Firewall)： 通过派生子代理（Sub-agents）来处理特定的子任务，子代理的中间讨论噪声不会污染父代理的主线程，从而维持长期的连贯性。

  • 熵值管理 (EntropyManagement/Garbage Collection)： AI代理倾向于复制现有的坏代码模式。治理架需要定期运行「园艺代理」，专门执行代码重构、删除死代码和同步陈旧的文档。

Prompt /Context/Harness Engineering各司其职

Prompt Engineering（2023-2024）

  • 关注「怎么跟 AI 说话」

  • 精心设计一段提示词，希望模型给出理想输出。Prompt Engineering 是优化一次性的输入-输出对。

  • 局限很明显：一条消息能塞的信息有限，任务一复杂就失控。

Context Engineering（2025）

  • 关注「给AI看什么信息」

  • 不再只盯措辞，而是设计整个信息环境：系统提示、对话历史、记忆、RAG 检索结果、工具调用输出。

Harness Engineering（2026）

  • 关注「构建什么环境让AI工作，这个环境如何保证它的产出是可靠的」

  • 比 Context Engineering 更进一步，不仅管理输入给模型的信息，还包括模型之外的整个执行环境。

对开发人员的影响

Harness Engineering的兴起正在引发开发人员技术栈的根本性变革。传统的编程技能要求正在被重新定义，新的能力体系正在形成。Harness Engineering要求工程师掌握三类核心能力：

  • 系统架构设计能力成为首要要求。工程师需要理解如何通过模块化拆分降低智能体认知负荷，例如按「契约点」（API Spec、数据库 Schema）拆分多智能体角色。这种能力要求开发人员从传统的 「实现思维」 转向 「设计思维」，更多地关注系统的整体结构和组件间的协作方式。

  • 熵控能力（Entropy Control）是Harness Engineering时代的独特要求。由于智能体持续迭代可能导致系统失控，工程师需要通过版本化文档、自动化清理工具（如 「代码熵管理」）来防止系统混乱。这种能力涉及对系统演进规律的深刻理解和对自动化工具的熟练运用。

  • AI协作能力成为基础技能。工程师需要掌握思维链、少样本学习等结构化方法，用专业框架让AI稳定输出，把准确率从60%提升到90%以上。同时，还需要掌握向量数据库、文本分块、检索召回优化等技术，让AI基于企业私有数据可靠回答，这是目前企业最紧缺的硬技能。
传统技术栈 Harness Engineering技术栈 变化说明
编程语言精通 多语言基础 + AI 工具链 从专精转向广度，重点掌握 AI 集成能力
框架深入掌握 模块化设计 + API 契约 从实现细节转向接口设计和协作模式
算法与数据结构 系统思维 + 架构模式 从算法实现转向系统优化和性能分析
数据库操作 向量数据库 + 知识图谱 新增非结构化数据处理能力
前端技术 响应式设计 + AI 交互 增加 AI 驱动的用户界面设计能力

参考资料

  • Mitchell Hashimoto (HashiCorp), My AI Adoption Journey, Mitchell Hashimoto Blog, 2026-02-05

  • Ryan Lopopolo (OpenAI), Harness engineering: leveraging Codex in an agent-first world, OpenAI Official Blog, 2026-02-11

  • Phodal Huang, Harness Engineering 实践指南：落地探索的三大原则, 2026-03-10

  • Vivek Trivedy (Langchain), The Anatomy of an Agent Harnes， 2026-03-10

  • Prithvi Rajasekaran (Anthropic Labs), Harness design for long-running application development, Anthropic Engineering Blog, 2026-03-24

posted @ 2026-04-01 09:08  AI-Frontiers  阅读(139)  评论(0)    收藏  举报