Context Engineering、Prompt Engineering 与 Harness Engineering 分别是什么？

核心回答

三者是构建 Agent 时不同的工程关注点，范围存在重叠：

• Prompt Engineering（提示词工程）：把目标、规则、示例和输出要求表达清楚，并通过测试改进指令，让模型理解“这一步要怎样做”。
• Context Engineering（上下文工程）：决定当前步骤给模型看什么，包括指令、历史、记忆、检索证据、工具定义与结果；负责筛选、组织、按需加载和预算管理。
• Harness Engineering：建设模型周边的执行与反馈系统，把模型调用、工具执行、状态、权限、停止条件、结果验证和失败恢复接成可运行的任务闭环。

例如售后助手中，写清楚回答规则属于 Prompt；取到当前订单、有效政策和必要历史属于 Context；真正校验权限、执行工具、记录结果并处理超时属于 Harness。把这理解为工程关注范围的扩展比较合适，它们不是相互替代的三个时代，也不是业界统一规定、边界严格的三层架构。

展开说明

1. 分别在改什么

Prompt Engineering 的直接修改对象是模型收到的指令及其组织方式，例如任务边界、消息模板、典型示例和输出格式。它不只是调整几个词，也包括设计可检验的提示模板，并根据失败样例迭代。

Context Engineering 的对象是一次次模型调用的完整输入。例如当前步骤需要哪条政策、保留哪段历史、召回哪些用户偏好、提供哪些工具、长结果怎样裁剪。提示词是上下文的一部分；上下文工程还要处理来自存储和环境的动态信息，不能只靠修改固定 System Prompt 完成。

Harness Engineering 则处理执行过程。模型返回工具调用以后，由谁解析和校验参数，如何执行并把反馈送回模型，任务状态存在哪里，什么时候结束或等待确认，遇到故障怎样继续，这些都需要代码和运行环境支撑。上下文组装通常也会通过 Harness 中的中间件或调用前处理实现，所以它们不是互不相干的三个模块。

2. 同一个任务怎样串起三者

假设要设计一个售后助手，用户要求“核对订单 A17 的售后条件，符合时创建一张工单”。

Prompt 可以明确：先依据订单和有效政策判断，信息不足时澄清，回答中说明依据与处理状态。示例展示如何区分“符合条件”“还缺资料”和“已经创建成功”。这些指令指导模型如何理解和表达。

Context 负责给这一步补齐依据：当前订单状态、适用版本的售后政策、用户已确认的信息，以及查询和创建工单工具的用途与参数 Schema。只提供当前需要的内容，避免把旧政策、其他用户订单和冗长工具日志混进来；服务端凭据由工具运行环境管理。

Harness 接到模型提出的创建请求后，验证调用者与订单权限、业务条件及必要授权，执行创建并保存工单回执。若网络超时，按照服务端幂等契约核对真实结果；只有取得相应证据才把状态推进为成功。最后将结果反馈给模型，生成用户能理解的答复。

因此，写“不要重复创建”属于指令设计，给模型提供“此前已创建工单”的可靠状态属于上下文组织，而服务端用业务标识防重、核对超时结果才落实了执行保证。

3. 如何理解“从 Prompt 到 Context 再到 Harness”

这种说法强调：当任务从一次回答扩展到检索、多轮交互和真实操作，工程问题随之增加。系统除了要表达清楚，还要提供合适依据，并把动作、反馈和状态维护好。简单文本任务可能只需要清楚的模板与结果检查，多步骤业务则需要更多执行支撑。

这不是要求每个项目建设完整的平台，也不意味着换了术语就不再需要提示词。一个函数中的轻量循环也可以承担必要的 Harness 职责；状态恢复、沙箱、多 Agent、跨服务调度等能力，应按任务需要增加。

还要看资料中的具体语境。有些文章把 Harness 用来指 Agent 的运行支撑，有些评测文档说的是 evaluation harness，即准备环境、运行任务、收集轨迹和评分的测试执行系统。两者会复用工具和运行能力，但不能把 Harness 一概解释成测试框架，也不能把它等同模型本身。

常见追问

三者之间怎么判断问题应该改在哪里？

先看失败证据。模型拿到了正确资料，却误解任务或输出格式，先检查指令和示例；关键政策未召回、旧事实被注入，则检查上下文链路；工具越权、重复提交、状态没有保存，则检查执行层。一次失败可能涉及多处，要沿实际输入、工具请求和业务结果定位，不能只凭术语归类。

RAG、Skill 和 MCP 分别属于哪一个？

它们可能参与多个环节。RAG 为当前调用提供外部证据，检索配置和结果注入涉及上下文工程；Skill 提供可复用任务知识与流程，其说明和示例也涉及提示设计，发现与按需加载涉及上下文管理；MCP 提供工具等能力的连接协议，宿主还需把发现的能力适配给模型，并由执行层管理实际调用。不能简单把一个组件永远归到唯一一层。

换更强的模型以后，Harness 可以省掉吗？

更强的模型可能更会选工具、规划和理解资料，但实际访问外部系统、保存状态及执行权限仍由程序负责。可以减少不再有价值的规则和补丁，同时保留业务真正需要的执行约束与结果验证；用同一批任务比较整体行为，而不是只比较模型的文本回答。

对应教程

参考资料