从提示词到Harness工程：AI Agent开发范式的进化之路

AI工程范式为何持续演变

在AI辅助开发已成常态的今天，一个核心问题浮出水面：为什么我们的AI工程方法论会不断演进？从最早的提示词（Prompt），到上下文工程（Context Engineering），再到如今的Harness工程，每一次跃迁背后都对应着一个此前无法解决的工程困境。

本文基于B站Harness工程从原理到实战的教程内容，系统梳理这条演进路径，并结合企业级项目的真实痛点，剖析Harness工程为何会成为AI Agent时代的基础设施。

从一个用户登录需求说起

设想这样一个场景：公司来了一个实习生，你交给他一个需求——"开发一个三层系统的用户登录功能"。对实习生而言，他会瞬间懵掉：项目的技术栈是什么？用户表的数据库结构如何设计？接口规范在哪里？开发环境和测试环境又该怎么连？

这正是当下大模型面临的困境。教程中给出了一个精准的比喻：大模型就像一个高智商的实习生——它能写代码、能理解冗长的文档、能总结分析数据，但它完全不了解你的工程环境。能力再强，也无从下手。

提示词工程：给模型更多信息，但未提升能力上限

当我们把"开发一个用户登录功能"直接抛给豆包这类AI时，会发现它确实能给出一段可运行的代码。但问题在于——这段代码往往不符合真实需求。

于是提示词工程应运而生，并在近几年迅速走红。提示词工程（Prompt Engineering）作为与大模型交互的核心技术，在2022-2023年随GPT-3/4的普及而迅速成熟。角色限定（Role Prompting）、思维链（Chain of Thought, CoT）、小样本示例（Few-shot）……这些技巧确实能提升输出效果。其中，CoT由Google研究员Wei et al.于2022年正式提出，通过引导模型逐步推理来提升复杂任务表现；Few-shot Learning则借鉴元学习思想，在提示中嵌入少量示例让模型快速泛化。角色限定技术则利用了大模型在预训练阶段习得的角色知识，通过身份激活特定领域的专业输出。

值得深入理解的是这三类技术的认知科学基础：CoT本质上是在模拟人类"慢思考"（System 2思维）的外化过程，将隐式推理步骤显式化，从而减少模型跳步导致的错误累积；Few-shot则利用了Transformer在预训练阶段形成的"上下文学习"（In-Context Learning）能力——模型无需梯度更新，仅凭示例即可在推理时临时调整输出分布，这一现象至今在理论上尚未被完全解释清楚，是NLP领域的重要研究课题之一。

但有一个容易被忽视的事实：这些技术本质上都是在利用模型已有的能力，而非扩展能力边界——提示词并没有真正提高模型的能力，它只是给模型提供了更多相关信息。这就像人与人之间的协作——如果你只丢给同事一个需求，却不交代业务背景、技术架构和数据库结构，对方同样无从下手。反之，把业务调研链路、数据库结构讲清楚，同事根本不需要你多说就能定位问题。

关键词只有一个：上下文。任何非极简的问题，在处理复杂业务时都绕不开上下文。

上下文工程：解决了信息问题，却撞上三堵墙

当我们把技术栈、数据库选型（MySQL 还是 MongoDB）、后端框架（FastAPI 还是 Django）、缓存方案等完整上下文提供给 AI 后，代码开发的效果会有质的飞跃。

然而，一旦进入真实的企业级项目，上下文工程就会撞上三堵墙：

第一堵墙：上下文窗口的物理限制

上下文窗口（Context Window）是大模型一次能处理的最大文本长度，以Token为计量单位（通常1个英文单词约1-2个Token，1个汉字约1-2个Token）。主流大模型的上下文窗口历经快速扩张：早期GPT-3仅支持4K Token，DeepSeek早期版本停留在128K，Claude 3系列达到200K，Gemini 1.5 Pro更突破至100万Token。尽管窗口在持续增大，但企业项目动辄几千个文件、几十万行代码、上百个接口、几十张表——全部塞给大模型，窗口依然装不下。

第二堵墙：Token成本难以持续承担

即便窗口足够，把海量代码反复喂给模型，产生的Token成本也是企业难以持续承担的。以GPT-4o为例，输入Token约$2.5/百万，大型项目若将数十万行代码反复提交，单日API费用可轻易超过数千美元。这也是为何业界持续探索RAG（检索增强生成）等技术来降低冗余Token消耗。

RAG（检索增强生成）是解决上下文窗口限制与Token成本问题的主流工程方案，其核心思想是"按需检索，而非全量输入"。RAG的技术链路通常包括：将知识库文档切分为Chunk，通过嵌入模型（Embedding Model）转化为向量，存入向量数据库（如Pinecone、Chroma、Milvus）；在推理时，将用户查询同样向量化，通过近似最近邻搜索（ANN）检索最相关的Chunk，再将其注入大模型的上下文中。在后续的Harness工程框架下，RAG可以被视为一种特殊的Skill——它将"精准的上下文检索能力"模块化，使Agent能够在不超出窗口限制的前提下，动态获取海量代码库或文档中的相关片段，与"只给模型它真正需要的信息"的Harness核心理念高度一致。

值得注意的是，RAG的检索质量高度依赖Chunk切分策略与嵌入模型的选择。固定长度切分（Fixed-size Chunking）实现简单但可能割裂语义；语义切分（Semantic Chunking）通过检测相邻句子嵌入向量的余弦相似度突变来确定边界，保留了更完整的语义单元；而针对代码库的RAG则通常采用AST（抽象语法树）感知切分，以函数或类为最小粒度，避免将同一函数的实现代码切割到不同Chunk中。这些工程细节直接决定了RAG在工程代码检索场景中的实际可用性。

第三堵墙：注意力衰减（最核心的瓶颈）

这是最本质的问题。2023年斯坦福大学发表的论文《Lost in the Middle》首次系统量化了这一现象：在多文档问答任务中，当相关信息位于输入序列中间位置时，模型性能显著下降，而信息位于开头或结尾时表现最佳，呈现出典型的U型曲线。

其技术根源在于Transformer的自注意力机制（Self-Attention）——通过计算序列中每个Token与其他所有Token的相关性权重来建立全局依赖关系，其计算复杂度为O(n²)，序列长度翻倍则计算量翻四倍。在处理超长序列时，位置偏置（Positional Bias）效应加剧，模型对中间Token的注意力权重被稀释。业界为此形成了两条技术路线：一是改进注意力计算效率（如Flash Attention将内存复杂度从O(n²)降至O(n)，使百万Token的处理成为可能）；二是改进位置编码（如RoPE旋转位置编码通过相对位置表示提升长程依赖捕捉能力，已被LLaMA、DeepSeek等广泛采用）。然而即便如此，当前大模型底层基于Transformer架构，当输入文件过大时，模型只会牢牢记住开头和结尾的内容，而中间部分往往被遗忘。这种"中间遗忘"现象，对需要环环相扣的工程开发而言是致命的，也正是Harness工程强调精准上下文管理而非暴力扩窗的根本原因。

从另一个维度理解这一瓶颈：即便"针在草堆中"的信息理论上位于窗口内，模型能否"找到"这根针，取决于注意力分配的质量而非窗口大小。这与人类工作记忆（Working Memory）的容量限制高度类似——心理学研究表明人类工作记忆的有效容量约为"7±2个组块"，窗口越大并不意味着有效利用率越高。Harness工程的精髓之一，正是通过结构化约束减少无关信息对注意力的稀释，确保模型的"认知资源"集中在真正重要的上下文上。

开发是一条完整的流程链

以用户登录为例，传统开发是一套连贯流程：提出需求 → 设计校验方案（邮箱、手机号、密码加密算法）→ 开发功能 → 运行测试 → 发现问题继续修复 → 提交。每个步骤环环相扣。无论是提示词还是上下文工程，都无法稳定支撑这种长链条、高复杂度的工程任务。

Harness工程：驾驭大模型这匹"烈马"

正是在上下文工程的瓶颈之上，诞生了 Harness 工程。

Harness 一词原意为"马具"，引申为"驾驭、利用"。在AI语境中，这匹"马"就是能力已然强大的大模型（如写代码效率极高的Claude）。我们的目标是通过一系列约束——提示词、指导文档、Skill、MCP等——让模型像被驯服的马一样，在设定好的轨道上稳定、可靠地完成任务。

Harness工程并非凭空出现，而是伴随着AI Agent工程实践的成熟逐步从业界实践中提炼而来。2023年后，随着GPT-4、Claude 3等大模型在代码生成领域展现出超越初级工程师的能力，工程界的核心矛盾从"模型够不够聪明"转向"如何让模型在真实工程环境中稳定可控地工作"。Harness作为一个工程范式，吸收了DevOps基础设施即代码（Infrastructure as Code）的思想，同时借鉴了软件架构中的约束驱动设计（Constraint-Driven Design），将AI系统的不确定性通过结构化约束转化为可预期的工程输出。

Harness工程的组件体系可以从四个层次理解：约束层（CLAUDE.md、.cursorrules等AI行为规范文件，定义模型在该项目中的编码风格、禁止行为和工作边界）、知识层（架构决策记录ADR、接口文档、数据库Schema，为模型提供项目的结构化认知底座）、能力层（Skill/Tool定义、MCP Server，将具体业务能力封装为模型可调用的标准接口）和协调层（Agent编排逻辑、任务分解策略，控制多步骤任务的执行流程与异常处理）。这四层共同构成了驾驭大模型的完整"马具"，缺少任何一层都会导致模型在真实工程场景中失控或低效。

Agent = Model + Harness：一个值得深究的公式

教程中引用了一个广为流传的公式：

Agent = Model + Harness

也就是说，一个完整的AI Agent，除去大模型本身，其余的一切——无论是提示词、指导文件、Skill 还是 MCP——都属于 Harness 的范畴。Harness 就是控制模型的"缰绳与马鞍"，让模型的潜力真正符合需求，转化为实实在在的生产力。

值得特别说明的是其中两个关键组件：

MCP（Model Context Protocol）是Anthropic于2024年11月正式开源的标准化协议。在MCP出现之前，不同AI工具调用外部能力的方式高度碎片化：LangChain有自己的Tool接口，AutoGen有另一套定义，OpenAI的Function Calling格式与Anthropic的Tool Use格式也存在差异。MCP通过定义标准化的Server/Client架构，类比USB接口之于硬件生态，为大模型提供了统一的"工具调用插座"，使得数据库查询、文件读写、API调用等能力可以被标准化封装为Server供模型调用——即插即用。这与万维网通过HTTP协议统一信息访问的逻辑如出一辙：标准化本身即是生产力。目前MCP生态已涵盖数据库连接、浏览器自动化、代码执行沙箱、云服务API等数百个官方与社区Server。

从协议设计角度看，MCP采用JSON-RPC 2.0作为底层通信格式，支持stdio和HTTP+SSE两种传输模式，前者适合本地进程间通信（如Cursor调用本地工具），后者适合远程服务部署。MCP Server的核心能力抽象为三类原语：Tools（模型可主动调用的函数）、Resources（模型可读取的结构化数据源）和Prompts（可复用的提示词模板）。这种分层设计使得MCP Server的开发者可以精细控制模型的能力边界，而不是将所有权限一次性暴露给模型——这与Harness工程"约束即保障"的核心理念深度契合。

Skill 在各主流Agent框架（如LangChain、AutoGen、Cursor）中通常对应函数调用（Function Calling）或工具定义（Tool Definition），是将具体业务能力模块化的核心抽象。Harness工程的本质，正是将这些分散的工程组件系统性地编排成可复用、可维护的AI基础设施。

OpenAI的Codex实验：仓库即一切

这一理念并非空想。OpenAI Codex是基于GPT系列针对代码任务专门微调的模型，于2021年发布并驱动了GitHub Copilot的早期版本。据教程介绍，OpenAI曾用Codex做过一个内部实验，目标极具颠覆性：人类不手写任何一行代码，只负责项目的架构设计，具体编码全部交给智能体完成。

实验从一个空的Git代码仓库起步，由此引出了 Harness 工程最重要的一条铁律：

仓库即一切（Repository is everything）

这一理念与软件工程中的"单一事实来源"（Single Source of Truth, SSOT）原则高度契合，也与DevOps领域的GitOps理念一脉相承。GitOps由Weaveworks于2017年提出，其核心原则是：系统的期望状态应以声明式方式完整存储在Git仓库中，任何变更通过Git操作触发，而非直接操作运行时系统。将这一思想引入AI Agent工程，产生了一套新的工程实践：Architecture Decision Records（ADR）将架构决策文档化，避免"知识孤岛"；CLAUDE.md、.cursor/rules等AI配置文件将对模型的行为约束版本化管理；Changelog的严格维护则为Agent提供了项目演进的时序上下文。从认知科学角度看，Git仓库扮演了Agent的"外部化长期记忆"角色，弥补了大模型无持久化状态的先天局限，同时保证了人类工程师之间、以及人类与AI之间的知识同步。

进一步从信息论角度理解"仓库即一切"的工程意义：Git的版本控制机制不仅保存了代码的当前状态，更以commit历史的形式保存了代码演化的完整轨迹。对于AI Agent而言，这意味着它不仅能读取"现在是什么"，还能通过git log、git blame等操作理解"为什么这样做"以及"之前是什么样子"——这种时序上下文对于理解遗留代码、避免重复引入已知Bug至关重要。这也是为什么在Harness工程实践中，规范的commit message、详尽的PR描述和及时更新的CHANGELOG不是可选项，而是让AI Agent有效工作的基础设施。

为什么如此强调？因为大模型只能读取仓库中的内容——它读不到你脑海中的构想，也读不到你写好却没上传的文档。复杂项目的资料往往是分散的，有些还没上传，有些还停留在设想阶段。因此，使用Harness工程开发的核心纪律就是：任何想法、任何更新，都必须及时沉淀到仓库中，否则对AI而言就等于不存在。

结语：工程化才是AI落地的关键

从提示词到上下文工程，再到 Harness 工程，这条演进路径清晰揭示了一个趋势：AI 落地的瓶颈，早已不在模型能力本身，而在于如何用工程手段驾驭模型。

模型是那匹能力强悍的烈马，Harness才是让它跑在正确赛道上的马具。对于希望将AI真正转化为生产力的团队而言，理解并构建自己的Harness工程体系——分层规范、仓库沉淀、Skill与MCP协同——将是下一阶段的核心竞争力。