最近直播和社群里，被问到频率最高的一个问题：

提示词工程、上下文工程、Harness 工程……
这些「XXX工程」到底啥区别？产品经理要学哪个？

先回答：所谓「XXX工程」，就是更规范做 XXX 的方式。

• • 提示词工程 = 更规范地写提示词；
• • 上下文工程 = 更规范地为模型构造上下文；
• • Harness 工程 = 更规范地为 Agent 搭建运行环境。

三个概念不是替代关系，是递进关系。它们共同回答一个核心问题：如何让 LLM 产出更好的结果？

今天这篇文章，帮你一次搞清楚。

提示词工程：一切的起点

为什么需要"提示"？

所有 LLM 都有一个共同特征：它不会主动行动。

不管模型多聪明，你不给它输入，它就只是参数文件里沉睡的几十 GB 权重。"提示"（Prompt）是一切的起点 — 没有提示，就没有输出。

而如何"提示"、"提示"什么，直接决定了 LLM 能为你创造多大的价值。

这就是 提示词工程（Prompt Engineering） 存在的意义：一套让"提示"更好地指导 LLM 工作的方法。

提示词工程的本质是什么？

听起来高大上，但提示词工程的核心其实就两件事：

1）把事情的背景信息交代全面

你得告诉模型：你是谁、你要解决什么问题、当前是什么场景、有哪些约束条件。

模型不了解你的业务、你的用户、你的上下文 —— 你不交代，它就猜。

2）把事情的要求约束清楚

你得告诉模型：输出什么格式、面向什么受众、用什么风格、长度多少、哪些是必须包含的、哪些是绝对不能出现的。

你不约束，它就自由发挥。

发现没有？这两件事，产品经理天天在干。

前者是需求分析、需求挖掘、问题定义 —— 这是产品经理的基本功之一。

后者是功能描述、功能拆解、边界界定 —— 这是产品经理的基本功之二。

提示词工程，本质上就是在写 PRD。

只不过这次的"开发人员"是大模型，而且它不需要你用技术语言，用自然语言就够了。

怎么真正掌握提示词工程？

背模板、抄别人的提示词，只能解决表面问题。

真正掌握提示词工程最好的方式，是理解大模型运行的底层原理。

关于 LLM 的底层原理，确保你理解了：LLM 生成的每一个 Token，都来自对前文的分析，但最终的选择是概率性的。

这意味着什么？

• • 前文越清晰，生成越精准。 模型会"模仿"前文的风格和逻辑。你给它一个结构化的提示，它就倾向于输出结构化的内容。
• • 约束越明确，随机性越小。 概率选择意味着模型有"跑偏"的可能。你要求越严格，它跑偏的空间就越小。
• • 示例比描述更有效。 与其用一千字描述你想要什么，不如直接给它一个例子。模型最擅长"模仿"。

一旦理解了这些特性，你就知道该怎么写提示词了 —— 因为你理解了要打交道的对象。

这就是提示词工程。

为 LLM 提供上下文最简单、最直接的方式，也是一切 AI 工程的基础。

🔑 一句话总结：
提示词工程 = 用 PRD 思维给模型交代清楚背景和要求，让它的概率输出更可控。

上下文工程

提示词工程解决了"怎么写好一条提示"的问题，随着 AI 应用越来越复杂，你会发现：一条提示词远远不够。

为什么提示词工程不够用了？

一个场景：你让 AI 客服回答用户问题。

如果只靠提示词，你得在提示里塞进产品文档、用户历史、FAQ、话术模板、合规要求……

很快，提示词就膨胀到几万字，模型的注意力被稀释，效果反而变差。

更麻烦的是，很多信息是动态的 —— 用户的订单状态在变、库存数据在变、最新的政策在变。

你不可能每次都把全量信息塞进提示词。

这时候，你需要的是上下文工程（Context Engineering）。

上下文工程是什么？

所有为 LLM 提供作业支撑信息的方式，都是上下文工程的一部分。

实际上，提示词工程本身就是上下文工程的一个子集 —— 它是最简单的那种：把所有信息直接写在提示里。

但上下文工程的范围远不止于此。

它要回答的问题是：在每次模型调用前，什么样的信息组合，最有可能让模型产出期望的结果？

这个问题的难点在于：

1）信息太多，窗口有限

大模型的上下文窗口就像人的工作记忆 —— 容量有限。

塞太多信息，模型反而"走神"。

随着上下文中的 Token 数量增加，模型准确回忆信息的能力会下降。这不是 bug，是架构限制。

所以，上下文工程的第一原则是：信息充分但紧致 —— 用尽可能少但高信号密度的 Token，最大化获得期望结果的概率。

2）信息来源多样，需要编排

随着 LLM 通过 Function Calling 调用工具的能力越来越强，模型可以获取信息的方式越来越多：

• • 从内部知识库检索（RAG）
• • 调用搜索引擎获取实时信息
• • 查询数据库获取结构化数据
• • 读取文件获取本地资料
• • 调用 API 获取第三方服务数据

每种方式产出的信息格式不同、可信度不同、时效性不同。

如何编排、组织这些信息源，让 LLM 高效高质量地获取更多支撑信息，就值得"工程"一下了。

3）信息是动态的，需要管理

在长时间的 Agent 工作流中，上下文会不断膨胀。

每一轮工具调用都会产生新的信息，但上下文窗口就那么大。这时候就需要一些工程手段：

• • 压缩整合：当对话接近窗口上限时，让模型对历史信息做高保真总结，用摘要替换原始内容，保持连贯性的同时释放空间。
• • 结构化笔记：让 Agent 把关键信息写到上下文之外的持久化存储（比如一个 Mermory.md 文件），需要时再拉回来。就像人做笔记一样 —— 你不需要把所有东西记在脑子里，但你得知道去哪里找到它。
• • 子代理分工：把复杂任务拆给多个子代理，每个子代理在自己干净的上下文窗口里工作，最后只把结论汇报给主代理。

产品经理为什么要关心上下文工程？

因为上下文工程的本质是信息架构设计 —— 决定什么信息在什么时候以什么方式进入模型的视野。

这和产品经理做的事情一模一样：

• • 设计产品时，你要决定什么信息展示在首页、什么信息放在二级页面
• • 写需求时，你要决定什么背景先交代、什么细节后补充
• • 做用户研究时，你要判断什么数据是关键信号、什么数据是噪声

上下文工程，就是把这种信息架构的能力，用在了给 LLM 构造输入上。

🔑 一句话总结：
上下文工程 = 在有限的注意力预算内，为模型策划最优的信息组合，不只是写提示词，更是管信息流。

Harness 工程

前两个"工程"解决的是怎么跟模型沟通的问题。当 AI 从"对话助手"进化到"自主 Agent"，光会沟通就不够了 —— 你需要给它一个能行动的环境。

这就是 Harness 工程。

什么是 Harness？

Harness 这个词，直译是"挽具" —— 就是套在马身上的那套装备，让骑手能驾驭马匹。

用在 AI 领域：模型是大脑，Harness 是身体。

没有身体，大脑再聪明也只能"想"，不能"做"。

或者说：模型以外的一切，都是 Harness。

它包括什么？我们可以把它拆成三层：

第一层：执行能力层 —— 给模型装上"手"

Agent 需要工具来执行任务。核心工具有三类：

1. 1. 文件系统工具 —— 增删、读写、搜索文件。这是最基础的能力，95% 的 Agent 任务都离不开文件操作。
2. 2. 浏览器工具 —— 访问和操作用户世界的系统，获取实时信息。
3. 3. 语言解释器 —— 能写代码，还得能运行代码、验证结果。

这三类工具配齐，就能覆盖绝大多数场景。

但配工具不是越多越好 —— 工具要和 Agent 的角色绑定。

一个负责"探索代码库"的 Agent，应该只配只读工具，限制它写文件、删文件的能力。给错工具，比不给更危险。

第二层：上下文环境层 —— 给模型装上"记忆"

模型的工作记忆是有限的（上下文窗口），但 Agent 的任务可能是长期的。如何让 Agent 在长时间工作中保持连贯性？

这层的核心是记忆系统。目前主流有三种方案：

• • 规则式：按固定规则存取信息，比如"每次对话结束自动保存关键信息到文件"
• • 半规则式：Agent 自己决定什么值得记、什么时候查记忆，但存储结构是预定义的
• • 完全模型驱动式：让模型自己决定记什么、怎么存、怎么查

以 Claude Code 和 Hermes Agent 为例，它们都有两个精妙的记忆机制：

• • 交互后 Hook：每次对话结束，自动 fork 一个 Agent，带上系统提示词和交互上下文，把需要保存的信息更新到结构化的 Markdown 文件里。
• • "悄悄做梦"：每隔一天，自动对最近的会话信息进行整理和更新 —— 就像人在睡眠中整理白天的记忆一样。

第三层：治理编排管理层 —— 给模型装上"组织能力"

当任务复杂到一个 Agent 搞不定时，你需要多个 Agent 协作。这就涉及：

• • 任务分配：谁负责什么？怎么把大任务拆成小任务？
• • 权限治理：哪些 Agent 能写文件？哪些只能读？哪些能访问网络？
• • 信息隔离：不同 Agent 之间的上下文要不要互通？互通多少？

这一层解决的不是"单个 Agent 怎么工作"的问题，而是"一群 Agent 怎么协作"的问题。

产品经理为什么要了解 Harness？

有人可能觉得：Harness 不是工程师的事吗？

是，也不是。

Harness 的设计决策，直接影响产品的用户体验、成本结构和能力边界：

• • Agent 能调用哪些工具，决定了它能做什么事（功能边界）
• • Agent 的记忆系统怎么设计，决定了它的对话体验好不好（用户体验）
• • 多 Agent 怎么协作，决定了系统能处理多复杂的问题（能力上限）
• • 每次调用消耗多少 Token，决定了产品的运营成本（成本结构）

Koji 采访新璐的播客里，新璐给了一个非常棒的说法：

在技术变化的周期里，产品经理如果不了解变化的内核和本质，就很难构建真正贴合红利和变化的产品。

Harness 工程目前还处于早期 —— 范式变化快，没有公认的"最佳实践"。但正因如此，现在理解它的人，就能在下一波 AI 产品浪潮中占据先发优势。

🔑 一句话总结：
Harness 工程 = 为 Agent 搭建完整的运行环境（工具 + 记忆 + 协作），让模型从"能想"进化到"能做"。

三者的关系：不是替代，是递进

看到这里，你应该能感受到三个"工程"之间的关系了：

提示词工程是基础 —— 不会写提示词，后面的都不用谈。

上下文工程是进阶 —— 当你的 AI 应用不只是单轮对话，就需要管理信息流。

Harness 工程是全貌 —— 当你要打造真正的 AI Agent 产品，就需要理解整个运行环境。

三者不是非此即彼的选择，而是随着 AI 应用复杂度递增，你依次需要掌握的能力栈。