从软件测试角度聊聊“Prompt / Context / Harness区别”

你可能在错误混用Prompt / Context / Harness

有这么一个真实且频发的场景：

Agent 在处理长任务时开始「遗忘」前面的步骤，把已经完成的事情重复执行了一遍。大多数团队的第一反应是：提示词问题。于是在 System Prompt 里加上「请注意不要重复执行已完成的步骤」。Agent 好了几天，又犯了。

再加一段更详细的指令，描述什么是「已完成」，什么是「待执行」。又好了一阵，又犯了，而且犯得越来越花样多。

最后提示词变成了一份 3000 字的规范，Agent 的实际表现却越来越混乱。

这种错误之所以如此普遍，是因为 Prompt Engineering、Context Engineering、Harness Engineering 这三层的边界给混用了。

这是最基础的一层，也是大多数人接触 AI 的起点。它的核心工作是：用更好的措辞和结构，让模型在单次交互中给出更好的输出。

Few-shot 示例、Chain-of-Thought 引导、角色扮演、输出格式控制------这些都是 Prompt Engineering 的范畴。它的生效范围是一次请求，下一次请求它不认识你。

Prompt Engineering 能解决的问题：模型不理解你的意图、输出格式不对、推理步骤不够清晰。

Prompt Engineering 解决不了的问题：任务执行过程中的状态管理、错误恢复、跨步骤的一致性。

当你意识到「给模型看什么」比「怎么问模型」更重要的时候，你就进入了 Context Engineering 的思维。

它的核心工作是：在有限的 Token 预算内，动态决定哪些信息应该进入上下文窗口，哪些应该被压缩或丢弃。RAG 检索、对话摘要压缩、相关记忆动态注入------这些都是 Context Engineering 的操作。

它的生效范围是一个上下文窗口。跨越了窗口边界，它就需要 Harness 来承接。

这是最容易被忽视、也最容易被误解的一层。

Harness 不是「复杂的提示词」，也不是「高级的 RAG」。它是 Agent 的运行环境本身------工具的授权与执行、跨任务会话的持久化、任务失败的恢复逻辑、高风险操作的人工审批门、整个执行过程的可观测性。

如果说 Prompt 是「告诉 Agent 做什么」，Context 是「让 Agent 看到什么」，那么 Harness 就是「确保 Agent 能在真实世界里可靠地把事情做完」。

AI 工程层	测试工程对应	核心问题
PROMPT Prompt Engineering 指令优化层	测试用例设计怎么写出一个好用例，清晰、完整、可执行	怎么把需求说清楚，让执行者准确理解意图？
CONTEXT Context Engineering 信息管理层	测试数据准备前置条件、测试数据集、Mock 数据的准备与管理	执行前被测对象「喂」什么信息，才能让它做出正确的行为？
HARNESS Harness Engineering 运行环境层	测试框架 / 测试环境 JUnit、TestNG、CI 流水线、Mock Server、质量门控	用什么基础设施来保证测试能稳定、可重复、可追溯地运行？