Prompt、Context & Harness Engineering

Prompt Engineering

提示词工程（Prompt Engineering）就是从"随便说一句"到"系统化提要求"的进化过程。

最常见的起步：在输入框里打一句"帮我写个简历"。AI 确实输出了，但格式和内容都不太对——姓名写在了左下角，教育经历堆成一坨，项目经历像散文。为了让效果更好，你会开始往里加规则：个人信息要居中、教育经历用表格列出、项目经历按 STAR 法则拆解。这种详细规定步骤和输出格式的提示词，就叫结构化提示词（Structured Prompt）。

太长了对吗？于是 Prompt Engineering 的思路就是：把提示词固化下来，用一条简短的命令去触发它——层层演进，从一句话到一个体系。

Command

Command 的本质是用短命令替换一段固定内容。结构化提示词虽然效果好，但每次都手敲几百字不现实——于是我们将长提示词固化到文件里，绑定一个简短命令（比如 /resume），需要时通过快捷键呼出，客户端自动把完整提示词发出去。

System Prompt

提示词越来越长之后，你会发现一个新问题：AI 开始"不听话"了——让它用表格它给纯文本，你让它居中它直接忽略。这就引出了 System Prompt。

大模型实际接收两层指令：我们在聊天框里输入的内容叫用户提示词（User Prompt），而 AI 客户端在背后默默注入的那层优先级更高的指令叫系统提示词（System Prompt）。同样的要求放进 System Prompt，大模型的遵循效果通常远好于放进 User Prompt。

怎么把自己的内容作为 System Prompt 发给大模型？一些 AI 客户端专门留了口子，可以用文件形式记录系统提示词——比如 Cursor 的 .cursorrules、Claude Code 的 CLAUDE.md。文件里最常见的一句就是："请用中文回复我"。

Metadata

写简历、写周报、写邮件……不同场景的要求各不相同，全塞进一个 System Prompt 文件里明显不合适——太长太杂，模型反而不知道重点在哪。于是按场景拆成一个个独立的 .md 文件。

但 AI 怎么知道该用哪个文件？把全部文件都发给大模型读一遍也不现实——每个文件的内容都会变成 token，文件越多越贵。解决方案：在每个文件开头加一段很短的描述，写清楚这个文件干什么、什么场景该调用。这种提示性描述就叫元数据（Metadata）。

当用户发送"帮我写个简历"时，客户端只把所有文件的 Metadata 发给大模型。因为 Metadata 极小（几十个 token），几乎不费钱。大模型判断出是"简历"场景后，客户端才加载对应的完整提示词进 System Prompt。这种"按需加载"的策略，既保证了提示词效果，又省下大量 token。

Reference / Script

需求越来越细，单个文件还是会膨胀。比如同样是"写简历"，产品岗要突出业务理解，开发岗要体现工程复杂度，算法岗要聚焦论文成果。继续拆：在主入口文件中留一个"岗位路由"，不同岗位路由到不同子文件，子文件太大再继续下钻。

AI 客户端会沿着路由一路下钻，只读取需要的那一小撮文件，用不到的文件完全不消耗 token。这种按需加载的方式就是渐进式披露（Progressive Disclosure）。

拆出来的文件按用途分为两类：

• Reference（参考资料）：放在 references/ 目录下，大模型有需要时去读里面的材料。负责"读"。
• Script（执行脚本）：放在 scripts/ 目录下。既然能通过系统命令读文件，那也能执行代码——写个 Python 脚本把文本写入 Word 再导出 PDF，在提示词里写清楚什么时候该跑哪个脚本。负责"跑"。

Skill

Skill 是 Prompt Engineering 的终极形态，也是上面所有概念的落地合集：

• 把 User Prompt 升级为以文件形式存在的 System Prompt（Command + System Prompt）
• 通过 Metadata 实现按场景加载（Metadata）
• 按需拆分文件路由到 Reference 和 Script（Reference/Script）

将主入口文件改名为 skill.md，和 references、scripts 一起打包成一个文件夹——比如写简历的叫 resume-writer，写文章的 article-writer。这个被外化为文件夹形式存在、可动态加载的系统提示词，就是 Skill。

Skill 与 MCP

如果大模型是大脑，那 MCP（Model Context Protocol）就是给大脑配的手——MCP 插件就是手上的工具，让大模型能操控外部系统。但给一个大学生全套工具箱，他也不一定能修好车——他缺的是经验和流程。

Skill 就是操作经验：规定在什么场景下、按什么顺序、组合使用哪些工具。注意，这里说的"工具"既可以是 MCP 插件，也可以是本地 script 脚本。

Skill 与 Workflow

很多任务其实可以拆解成好几个步骤——比如做视频可以分为找选题、写文案、做分镜。为了解决这类流程化需求，社区出现了低代码工具（比如 n8n），通过拖拉拽快速构建流水线。这种通过规则配置把多个步骤编排调度的流程叫 Workflow。

Skill 本质上也是做逻辑编排，但核心差异是：

• Workflow：流程结构在设计阶段就固定好了，执行路径是静态的。
• Skill：执行流程由大模型实时驱动，可以根据上下文动态调整路径，灵活性更高。

两者最终都能做到类似的功能。不那么准确地说：Skill 可以理解为大模型驱动的 Workflow。

Context Engineering

提示词写得越长越仔细，模型知道的就越多，回答就越准。反过来，大模型回答不准，那大概率是因为知道的不够多。于是大家很自然不断往大模型里塞各种资料——这些打包到一起发给大模型的所有信息就叫上下文（Context）。提示词只是上下文的一部分。

但大模型再强，一次性能处理的上下文也有最大限制，这个限制叫上下文窗口（Context Window）。在 AI Agent 应用里，多对话几轮就很容易将上下文窗口打满，于是就需要通过一些策略去压缩或丢弃部分信息。在这个过程中不可避免会丢失关键信息，从而破坏上下文的完整性和准确性——这类问题被统称为上下文腐化（Context Corruption）。

召回：获取什么信息。可以来自外部新闻、历史聊天记录、当前代码环境、程序运行报错等。

压缩：将大量信息分批发给大模型做总结提炼，去掉冗余，只保留关键信息。

组装：调整信息的位置和顺序。由于大模型对开头和结尾的内容记忆更牢，核心约束放前面，参考信息往后排。

Harness Engineering

一句话概括：让模型在真实的系统中可控可靠执行的一套工程体系。目前的难点不再是让模型会做事，而是让模型稳定地做对事。

ReAct

提示词工程解决了大模型无引导乱说话的问题，上下文工程解决的是上下文的组织问题。模型是更聪明了，但它只能聊天，没法帮我们干活。

于是我们可以给大模型加入 Bash、沙箱、文件系统、MCP 这些能力，让它能像人一样操作外部工具、读写代码文件、执行命令、做测试。它们共同构成了执行层。将它们串成一个流程，在外部套一层循环——

驾驭工程的四层架构

可以通过聊天帮你执行任务的程序就是所谓的 AI Agent。Agent 的本质就是一个 for 循环。只要这个循环一长，上下文就一定会膨胀。上下文工程做再好也可能会腐化。随着它看过的文件越来越多、拿到的信息越来越杂，前面定好的目标和约束后面可能慢慢就被冲淡了，理解也会越来越偏。

① 记忆层

保证每次给大模型的上下文中都包含一些可复用的核心信息——项目目标、技术栈、需求背景、代码风格、禁止事项等。只要保证这部分一直在，大模型就能在大框架约束下减少理解偏移。

这些核心信息可以单独写成规则文件（Rule Files）固定在代码仓库里。规则文件会在调用大模型时作为系统提示词自动注入上下文。规则文件写多了会变长，那就拆成几份更短的文件，再加一个简单的路由——比如背景就读 bg.md，技术栈就看 stack.md。一般情况下只需要加载文件地址路径，真正需要的时候再加载文件的全部内容。

② 执行层

有了记忆层和执行层的配合，Agent 就能不停写代码、跑 Linter 和单元测试。过程中发现执行有问题，还可以将测试输出和报错加入到上下文里，驱动 Agent 在下一轮循环中自动修复。

③ 反馈层

Agent 不是一条路走到黑。通过将 Linter 报错、单元测试失败、运行时异常等执行结果自动注入回上下文，驱动大模型在下一轮循环中自动修复问题——这套"校验 → 报错 → 修复 → 再校验"的闭环机制形成了反馈层（Feedback Layer）。

④ 编排层

Agent 的循环如果缺乏全局规划和清晰的结束目标，很容易跑偏甚至陷入无效死循环。将大任务拆解为有明确执行标准的多个子任务，按规划驱动 Agent 分步执行——这种以全局规划为核心、对任务做拆解与全流程管控的能力形成了编排层。

总结

编排层、执行层、反馈层和记忆层，这些能力共同组成了一套包裹着大模型的工程外壳，它就是 Agent Engineering（驾驭工程）。提示词工程解决"说什么"，上下文工程解决"给什么"，驾驭工程解决"怎么做"——三者层层递进，构成了 AI Agent 开发的完整技术栈。