上下文工程只是子集：Harness Engineering 才是 Agent 稳定干活的关键

核心洞察

这篇文章最有意思的地方，是它把上下文工程和 Harness Engineering一种在AI模型周围构建结构化控制系统的工程方法论，通过系统提示词、工具/API、测试环境和中间件来引导模型输出，提升任务成功率并控制成本。 的关系讲清楚了。很多人做 AgentIn AI, a system that perceives its environment and takes actions to achieve specific goals, often used in conversational contexts. 产品时只盯着提示词或者 RAG，但真正决定 Agent 能不能稳定干活的，是它整个运行空间怎么搭。作者画的那张图值得多看两眼，越靠近中心越直接操作上下文，越往外越偏基础设施，这个分层思路挺实用。

核心结论

1. 上下文工程的定义是：在有限的上下文窗口中，选择、组织并注入与用户输入或任务高度相关的信息，让大语言模型在合理边界内做出最佳推理和执行。

2. 上下文工程与 Harness Engineering 的关系是：上下文工程是 Harness Engineering 的子集，前者是设计原则，后者是构建目标，负责将其落地为稳定运行的 Agent 环境。

3. 技术演进路径为：上下文 → 上下文工程 → Harness Engineering，每一阶段都在前一阶段基础上向外扩展一层，而非替代关系。

4. RAG 只是上下文工程的一个子集；提示词工程则专注于 LLM 最前置的指令设计，核心是在单个文本字符串里写出完美的指令集。

5. Harness Engineering 的核心是为 Agent 搭建运行空间，设计其能力结构、协作机制和反馈闭环，让它在特定领域里稳定产出高质量结果，且该运行空间需随模型升级逐渐变化。

项目介绍

大语言模型发展得很快，开发者和企业都在往实际业务里塞。但真落地的时候大家发现一个问题：模型本身不是关键，关键是它手里有什么上下文。

上下文工程就是冲着这个问题来的。它是一套系统化方法，研究的是怎么在有限的上下文窗口里，挑出跟用户任务最相关的信息，组织好、塞进去，让模型在合理边界内做出最好的推理和执行。

Harness Engineering 则更进一步。它不只管上下文，还管 Agent 能不能稳定跑起来。它为 Agent 搭了一个完整的运行空间，设计能力结构、协作机制和反馈闭环，让它在特定领域里稳定产出高质量结果。

这个项目的目标，是给开发者和研究者一份大模型应用开发的骨架思路。以上下文组成为核心，把大模型应用开发相关的技术都串起来。

阅读路径

文档按下面的脉络组织，建议按顺序读：

1. 全局认知 — 先理解上下文工程与 Harness Engineering 两个核心概念，建立全局地图
2. 大模型应用开发基础技术 — RAG、搜索代理、向量存储、知识图谱
3. 上下文核心模块 — 从上下文类型出发，逐一了解每种上下文衍生出的工程模块（主体部分，篇幅最大）
4. 上下文管理 — 所有模块都往上下文窗口里塞东西时，怎么裁剪、压缩、协调
5. Agent 运行空间 — 超出上下文工程范围的 Agent 运行需求：形态设计、评估反馈
6. 实践与案例 — 真实项目中的落地经验

如果你的团队在做大模型应用或 Agent 相关的产品，欢迎找我聊聊。微信：a2385472291、email：2385472291@qq.com

什么是上下文工程

上下文工程的定义：是在有限的上下文窗口中，选择、组织并注入与用户输入或任务高度相关的信息，从而让大语言模型能够在合理的边界内做出最佳推理和执行。

这里面最关键的一点：用最相关的信息填充 LLM 的上下文窗口。

怎么为“用户输入”找到最相关的信息，是整个系统的入口，也是衡量系统价值的核心指标。但这种“相关性”不会自己冒出来，得靠开发者去设计、构建和优化。

跟 RAG 的区别：RAG 只是上下文工程的一个子集。

跟提示词工程的区别：提示词工程专注的是 LLM 最前置的指令设计，核心是在单个文本字符串里写出完美的指令集。

Karpathy 的总结：人们通常把提示跟日常使用中向 LLM 提供的简短任务描述联系起来。但在每个工业级 LLM 应用里，上下文工程是一门微妙的艺术和科学，它通过为下一步提供恰到好处的信息来填充上下文窗口。这是科学，因为正确地做到这一点涉及任务描述和解释、少量示例、RAG、相关（可能是多模态的）数据、工具、状态和历史记录、压缩等。太少或形式不正确，LLM 就没有正确的上下文来优化性能。太多或太不相关，LLM 的成本可能会上升，性能可能会下降。做好这一点非常不简单。而且，这也是艺术，因为围绕 LLM 心理和人们精神的指导直觉。

Karpathy 总结的链接：https://x.com/karpathy/status/1937902205765607626?ref=blog.langchain.com

什么是 Harness Engineering

Harness Engineering 我的理解是：为 Agent 搭建运行空间，设计它的能力结构、协作机制和反馈闭环，让它在特定领域里稳定地产生高质量结果。

它不是只做限制模型能做什么，而是在创造条件让模型能做到原本做不到的事。这个运行空间要随着模型的升级逐渐变化。

所以大家更多应该去关注不同领域下，这个 Agent 的运行空间是如何构建的。

上下文工程和 Harness Engineering 的关系

1、从概念范围来看：上下文工程是 Harness Engineering 的子集

Harness Engineering 里有些模块直接服务于上下文（RAG、记忆、系统提示词），有些间接服务上下文（上下文管理、Agent 评估），有些则直接服务于 Agent 稳定运行。但不管在哪一层，它们都在 Harness Engineering 这个大框架下。

越靠近中心，越直接操作上下文。越靠近外层，越偏向基础设施。

2、从技术发展来看：这条演进路径有一条清晰的主线：上下文 -> 上下文工程 -> Harness Engineering

最早我们只关注“塞给模型什么内容”，这是上下文本身的问题。需求变复杂之后，开始系统性地管理上下文的构建方式，于是有了上下文工程。当 Agent 承担起更复杂的任务，单靠上下文管理已经不够，我们需要为它搭建完整的运行环境，Harness Engineering 由此出现。

它不是替代，而是一次扩展，每一个阶段都在前一个阶段基础上，往外多包了一层。

上下文工程是设计原则，Agent Harness 是构建目标。 Harness Engineering 负责将其落地为稳定运行的 Agent 环境。

常见问题（FAQ）

上下文工程和提示词工程有什么区别？

提示词工程专注LLM最前置的指令设计，核心是在单个文本字符串里写出完美指令集。而上下文工程更广泛，是在有限上下文窗口中，选择、组织并注入与任务高度相关的信息，让模型做出最佳推理。RAG也只是上下文工程的一个子集。

Harness Engineering和上下文工程是什么关系？

上下文工程是Harness Engineering的子集。Harness Engineering为Agent搭建完整运行空间，设计能力结构、协作机制和反馈闭环，让它在特定领域稳定产出高质量结果。上下文工程是设计原则，Harness Engineering是构建目标，负责将其落地为稳定运行的Agent环境。

为什么说上下文工程是Agent稳定运行的关键？

因为模型本身不是关键，关键是它手里有什么上下文。上下文工程通过系统化方法，在有限窗口内挑选最相关信息，组织并注入，让模型在合理边界内做出最佳推理和执行。这直接决定了Agent能否稳定干活。