11 篇文章带有标签 “context-engineering”

Harness 工程：给 AI 智能体一个"可靠的家"

想象一下，你有一个非常聪明但有点冲动的助手——它知识渊博、能说会道，但有时候会：

• 忘记五分钟前你们讨论的事情
• 直接执行危险操作而不问你
• 在复杂任务中迷路，绕来绕去
• 做错了事，但你不知道为什么

这就是没有 Harness 的 LLM 智能体。

什么是 Harness？

Harness 这个词在英文里有"马具"、"安全带"的意思。在 AI 智能体的世界里，它就是那个让智能体既能够发挥能力，又不会失控的"安全脚手架"。

这个隐喻是有意的：

• 马是 AI 模型——强大、快速，但它自己不知道去哪里
• Harness是基础设施——约束、护栏、反馈循环，以富有成效地引导模型的力量
• 骑手是人类工程师——提供方向，而不是亲自奔跑

用一个更贴近生活的比喻：Harness 就像是智能体的"驾驶舱 + 安全带 + 导航系统 + 黑匣子"的组合体。

根据 Harness Engineering 将原始模型能力转化为可靠 Agent 行为的脚手架。实用的 Agent 最好被理解为在 Harness 内部运行的模型，而不是带有外围能力的模型。

真实故事：Harness 工程的威力

在我们深入技术细节之前，让我们看看几个真实的例子，了解为什么 Harness 工程如此重要：

Harness Engineering 是 AI 时代的全新软件工程学科 —— 设计和实现系统来约束、引导、验证和修正 AI 智能体的行为，让强大但不可预测的 AI 模型能够可靠地完成复杂任务。

📚 目录

• 核心概念
• 核心原理
• 技术架构
• 企业实践案例
• 最佳实践指南
• 实施路线图
• 未来趋势

核心概念

什么是 Harness Engineering？

Harness Engineering 是设计和实现系统的学科，这些系统能够：

1. 约束：定义 AI 智能体可以做什么（架构边界、依赖规则）
2. 告知：告诉智能体应该做什么（上下文工程、文档体系）
3. 验证：检查智能体是否正确完成任务（测试、 linting、CI 验证）
4. 修正：当智能体出错时引导其自我修复（反馈循环、自我修正机制）

类比：AI 模型是一匹强大但无方向的骏马，Harness 是缰绳、马鞍和全套马具，人类工程师是骑手。没有 Harness 的 AI 是开阔场地里的纯种马——速度快、令人印象深刻，但完全无法用来完成任何实际工作。

为什么 Harness Engineering 至关重要？

模型是商品，Harness 是护城河

AI 行业正在达成一个共识：底层模型的重要性远低于围绕它的系统。LangChain 的实验最能证明这一点：他们的编码智能体在 Terminal Bench 2.0 上的得分从 52.8% 提升到 66.

Harness Engineering 是 2026 年软件工程领域涌现的一门新学科，其核心理念是：在生成式 AI 时代，由于模型能力已趋于同质化（Commodity），构建可靠、可扩展的 AI 智能体系统的关键不再是模型本身，而是在模型周围设计的“Harness”（支架/编排系统）。

通过分析提供的资料，可以从以下几个维度深入理解 Harness Engineering：

1. 核心定义与马车隐喻

“Harness”一词源于马具（如缰绳、马鞍、嚼子），这个隐喻生动地解释了三者的关系：

• 马（Horse）：指代 AI 模型。它拥有强大的动力和速度，但本身并不知道要去哪里，也不具备自我约束力。
• Harness（马具/支架）：指代基础设施。包括约束机制、护栏和反馈回路，用于将模型的原始能力转化为生产力。
• 骑手（Rider）：指代人类工程师。负责提供方向和意图，而不是亲自奔跑（写代码）。

正式定义上，Harness engineering 是设计和实现一个能够约束、告知、验证并纠正 AI 智能体行为的系统学科。

2. Harness Engineering 的三大支柱

根据 OpenAI 和 NxCode 的实践，一个成熟的 Harness 系统包含三大核心组件：

• 上下文工程（Context Engineering）：确保智能体在正确的时间获得正确的信息。这要求将代码库视为唯一的真理来源，不仅包含代码，还包括架构决策、API 契约和动态的观测数据（如日志、指标）。
• 架构约束（Architectural Constraints）：通过机械化的手段强制执行“好代码”的标准。例如使用确定性的 Linter、结构化测试（如 ArchUnit）和严格的依赖层级校验，防止 AI 智能体在生成代码时由于灵活性过高而导致架构腐化。
• 熵管理/垃圾回收（Entropy Management / Garbage Collection）：AI 生成的代码库容易积累“AI 废料（AI Slop）”，文档也容易过时。Harness 系统需要定期运行专门的智能体来清理不一致的文档、修复违反架构约束的代码以及优化冗余逻辑。

本文综合 Anthropic、OpenAI、Martin Fowler、LangChain、Mitchell Hashimoto、NxCode、MiniMax 等前沿文章的分析报告。

一、什么是 Harness Engineering？

1.1 词源与隐喻

"Harness" 直译为"马具"——缰绳、鞍座、嚼子，是用来驾驭一匹强大但不可预测的动物的工具。这个隐喻极其精准：

隐喻	对应实体
马匹	AI 模型——强大、快速，但自身不知道该去哪里
马具（Harness）	基础设施——约束、护栏、反馈循环，引导模型的力量
骑手	人类工程师——提供方向，而不是亲自奔跑

没有 Harness 的 AI Agent 就像旷野中的野马——速度快、令人印象深刻，但对完成任何目标完全无用。

1.2 正式定义

Harness Engineering 是设计和实现以下系统的学科：

1. 约束（Constrain）——限制 AI Agent 能做什么（架构边界、依赖规则）
2. 告知（Inform）——告诉 Agent 它该做什么（上下文工程、文档）
3. 验证（Verify）——检查 Agent 是否正确完成了任务（测试、Linter、CI）
4. 纠正（Correct）——当 Agent 出错时进行修复（反馈循环、自我修复机制）

1.3 与相关概念的区别

Harness Engineering，是在AI大模型时代，以确定性系统外壳约束概率性AI行为，通过上下文工程、架构约束、熵管理三位一体，构建可长期稳定运行的AI Agent系统，推动软件工程从代码实现转向系统设计，成为下一代AI工程化的核心范式。

引言

在人工智能，特别是大型语言模型（LLM）能力迅速发展的时代，软件开发领域正经历一场深刻的范式转移。传统以代码为中心的工程方法正在被一种以语言为中心的新范式所取代。这一新范式将工程设计的核心原则，如控制、可靠性和可扩展性，应用到了人与AI的交互界面上。本报告将深入探讨这一新兴领域，提出“Harness Engineering”（驾驭工程）这一术语，用以描述其背后的系统性原则、核心实践、行业案例及未来挑战。报告旨在为软件工程师、技术领导者及行业观察家提供一个全面的框架，以理解并应用这一即将定义未来技术格局的关键技术。

一、超越提示词与上下文

在深入探讨Harness Engineering之前，必须首先理解它所处的演化脉络。它并非一个凭空出现的概念，而是对已有AI工程实践的一次系统性整合与升华。它标志着行业的焦点从与AI模型的“单次对话”转向了构建一个让AI能够“持续可靠工作”的完整系统。

1.1 定义Harness Engineering

Harness Engineering（驾驭工程）被定义为一个新兴的工程学科，其核心目标是设计和实现一套围

Harness Engineering 定义

Harness engineering 是一门设计和构建约束、反馈循环和生命周期系统的工程学科，用于让 AI 智能体能够可靠地构建软件。它的核心思想是：不直接让 AI 写代码，而是创建一个环境（harness），让 AI 在这个环境中可靠地构建代码。

三大核心支柱

1. Context Engineering（上下文工程）

• 增强的知识库
• 动态上下文注入（可观测性数据、浏览器导航等）
• 提供 AI 完成任务所需的完整信息

2. Architectural Constraints（架构约束）

• 由 AI 智能体监控
• 自定义 lint 规则
• 结构性测试
• 确保生成的代码符合架构规范

3. Entropy Cleanup（熵清理/垃圾回收）

• 定期运行的智能体来发现不一致和违规
• 对抗系统随时间的退化
• 保持代码库的长期质量

典型架构模式

Anthropic 的三智能体架构：

• Planner（规划智能体）：任务分解
• Generator（生成智能体）：代码生成
• Evaluator（评估智能体）：质量评估（基于 Design quality、Originality、Craft、Functionality 等标准）

关键实践

1. 迭代改进：将智能体的困难视为信号，据此添加工具/护栏/文档
2. 自我验证循环：build-test-fix 闭环
3. 循环检测中间件：防止无限循环
4. "推理三明治"：计算预算策略
5. 状态传递：在智能体之间清晰传递任务状态

这四个术语是当前大模型应用开发的核心范式，从指令设计、信息管理、生成式编程到自主智能体构建，层层递进，共同构成了 AI 应用开发的技术栈。

以下是通俗易懂的拆解：

1. Prompt Engineering (提示工程)

这是最基础的技能，重点在于指令的质量。 如果把 AI 比作一个极其博学但有时听不懂人话的实习生，Prompt Engineering 就是学习如何写出完美的“任务说明书”。

• 核心逻辑：通过调整输入的文字（提示词），引导模型输出更高质量的结果。
• 常用技巧：给 AI 设定角色（“你是一个资深翻译”）、提供示例（Few-shot）、要求逻辑推演（Chain of Thought）。
• 比喻：就像是在搜索引擎里输入更精准的关键词，或者给厨师下达非常具体的菜谱要求。

2. Context Engineering (上下文工程)

随着模型处理能力增强，大家发现“怎么说”固然重要，但 “给它看什么资料” 更重要。这就是上下文工程。

• 核心逻辑：管理和优化输入给模型的信息流。AI 的记忆（上下文窗口）是有限的，你需要精准地挑选出最相关的背景知识喂给它。
• 典型应用：RAG (检索增强生成)。当你问关于公司手册的问题时，系统先去数据库里搜出相关的几段话，塞进对话框里，AI 才能据此回答。
• 比喻：开卷考试。Prompt 是考题，Context 就是那本允许你带进考场的、划满了重点的参考书。

《Context Engineering & Coding Agents with Cursor》（Cursor 的上下文工程与编程智能体），由 Cursor 团队成员 Lee 和 CEO Michael 主讲。视频深入探讨了软件开发的演变、Cursor 如何利用 AI 提升编程效率，以及未来编程智能体的发展方向。

1. 编程的演变与 Cursor 的核心功能

• 编程历史回顾：从打孔卡片到图形界面，再到如今的 AI 辅助编程，AI 正在以前所未有的速度推动软件开发的进步。

• Cursor Tab (代码补全)：

• Cursor 的 Tab 功能深受 GitHub Copilot 启发，但已从简单的“预测下一个词”进化为“预测下一个动作”甚至“预测光标去向”。

• 强化学习：模型会根据用户的“接受”或“拒绝”操作进行实时在线强化学习（RL），在 30 分钟内即可更新模型行为。

• 平衡性：Cursor 致力于在建议速度（不打断心流）和建议质量之间找到平衡点。

2. 上下文工程 (Context Engineering)

• 超越提示词工程：随着模型变强，获取高质量输出的关键不再是“提示词技巧”，而是提供“正确的上下文”。

• 混合检索策略：

• 字符串匹配：单纯依靠 grep (字符串匹配) 是不够的。

• 语义搜索：Cursor 通过对代码库建立索引（embeddings），即使文件名不完全匹配（如 header.tsx vs "top navigation"），也能通过语义准确找到相关代码。

Context Engineering（上下文工程）是为解决 AI Agent 时代输入过长，避免塞爆 Context 的关键技术。其基本概念是 “把需要的放進去，不需要的清出來”。常用招数（基本方法）包括：

1. Select（挑选）：只挑选当下任务最关键的内容。这包括利用 RAG (检索增强生成) 检索额外资讯，并使用 Reranking 或 Small LLM 筛选关键词。此外，只挑选需要的工具（Tool RAG）和记忆（Memory RAG）。
2. Compress（压缩）：对冗长琐碎的内容进行精简和摘要。例如，将过去的对话历史或 Computer Use 产生的细节压缩，让遥远的记忆逐渐淡化，以节省 Context 空间。
3. Multi-Agent（多代理）：将复杂任务拆解并分派给多个子 Agent。子 Agent 独立处理细节，完成后只向 Lead Agent 回报最终结果，从而隔离复杂的互动过程，分散 Context 负担。

• Introduction to GenAI and ML 2025 Fall
• 【生成式人工智慧與機器學習導論2025】第 2 講：上下文工程 (Context Engineering) — AI Agent 背後的關鍵技術
• 李宏毅讲 Context Engineering

本文介绍 Claude Code 的上下文工程。它整合了多种输入来源，包括系统提示、内置工具、MCP工具、自定义子代理、记忆文件和对话历史，以全面理解并完成编程开发任务。还介绍了使用 Claude Code 在您的项目中提供全流程协助，如何编写提示词。

Claude Code 上下文工程

Claude Code 能为您的项目提供全流程协助

📌 计划模式

计划模式是指通过只读操作分析代码库来创建计划，非常适合探索代码库、规划复杂更改或安全地审查代码。

​> Analyze the authentication system and suggest improvements
​> 分析身份验证系统并提出改进建议。

​> I need to refactor our authentication system to use OAuth2. Create a detailed migration plan.
​> 我需要重构我们的身份验证系统以使用 OAuth2。创建一个详细的迁移计划。

  ​> What about backward compatibility?
  ​> 向后兼容性怎么办？

  ​> How should we handle database migration?
  ​> 我们应该如何处理数据库迁移？

探索代码库

• Exploring Generative AI

大型语言模型(LLM)的工作原理根植于模式匹配和对下一个词元的统计预测("随机鹦鹉")。从这种方法中产生的一个有些出人意料的能力是它们也能在一定程度上"推理"解决问题。有些模型的推理能力比其他模型更强，OpenAI的"o1"和"o3"模型是两个突出的推理模型，而DeepSeek的"R1"最近引起了很大轰动。但是当我们在编码任务中使用AI时，这种能力发挥什么作用呢？

剧透提醒：我还没有答案！但我有问题和想法。

我将从两个方面开始讨论，这两个方面在我的理解中是推理能力的限制，而且这些限制在编码环境中是相关的。然后我将分享我的想法，即推理在哪些编码任务中可能有用，在哪些任务中可能没用。

上下文至关重要，尤其是对推理而言

苹果公司去年发表的一篇关于大型语言模型推理局限性的论文引起了广泛关注。作者引入了一个新的基准测试，用来测试LLM在"数学推理"方面的能力。他们的基准测试基于一个已有的包含小学数学问题的测试集。他们选取了100个问题，将其转化为带有变量占位符的模板，然后为每个模板创建了50个变体，形成了一个包含5,000个问题的数据集。在第二步中，他们还创建了一个新的数据集，在问题中添加了无关信息。

他们发现：