Agent 系列（五）：从 LLM 的角度聊 Prompt、Context 和 Harness

大模型应用开发走到今天，很多概念边界变得越来越细化...

Prompt Engineering 在两三年前还是非常热的关键词，现在可能也提，但是热度已经降了下来；后来我们开始谈 Context Engineering，到今年我们又开始谈 Harness Engineering。表面看，这些概念像是一代代工程范式的变化；现在看到很多 blog 文章都是从 “怎么写提示词” 、 “怎么拼上下文” 、“怎么搭工作流” 去理解这三个的区别，其实也没毛病，但是今天我想从模型的角度去聊聊。

话说回来，为什么大模型应用工程化会沿着这条路径演进呢？ 答案要回到模型本身。

大模型本质上是基于 Transformer 架构构建的预测型系统，它接收一段 token 序列，经过多层自注意力、前馈网络和归一化计算，最终在当前位置预测下一个 token 的概率分布。模型并不天然理解业务目标，它是在输入条件约束下，沿着概率更高，或者更符合采样策略的方向继续生成。

关于 LLM 原理可以参考我前面公众号的 LLM 系列文章。

因此，从我的理解来看，Prompt、Context、Harness 这些工程范式，本质上都在解决同一个问题：如何让模型在生成时处于更合适的条件分布之中。 只不过，它们关注的粒度、工程边界和系统位置不同，Prompt 关注任务表达，Context 关注信息组织，Harness 关注运行结构，三者共同构成了大模型应用从输入控制到系统治理的完整外延。

Prompt Engineering

输入信号

Prompt Engineering 之所以重要，根源在于模型的预测机制。

在推理阶段，模型会先经历 prefill，这个阶段会把输入 token 全部送入模型，计算每个 token 对后续生成可能产生的影响，并生成对应的 KV Cache；随后进入 decode 阶段，模型逐 token 生成输出，每一步都会基于已有上下文和缓存继续预测下一个 token。

Prompt 作为最初输入给模型的内容，它是整个生成过程中的条件基础。Prompt 的作用，就是给模型设置一个更明确的任务边界，它告诉模型当前要 扮演什么角色、解决什么问题、遵循什么约束、使用什么格式、避免什么行为。

从模型角度看，Prompt 并没有改变模型权重，它改变的是模型在当前上下文中的激活状态和注意力分布，让模型更容易沿着某类输出模式继续生成。

同样问一句 “分析这家公司”，模型可能输出财务分析、行业分析、投资建议、舆情摘要，也可能只是泛泛介绍公司背景；加入 Prompt 后，任务空间会被压缩，例如可以要求模型从经营风险、财务压力、政策影响和短期市场情绪四个维度展开分析，并给出不确定性说明；这样的 Prompt，本质是在给模型建立一个更窄、更明确的生成通道。

Prompt 并没有让模型获得新的知识，但是它改变了模型组织已有知识和生成路径的方式；所以，Prompt Engineering 的核心就是给模型足够清晰的 条件信号。这也是早期大模型应用高度依赖 Prompt 的原因，模型能力还没有被复杂系统接住时，Prompt 是最直接、成本最低、效果最明显的控制手段。

Prompt 的边界

Prompt 在早起模型不够强大的时候确实能够一定程度上解决很多问题，但它的上线天花板也比较低：

• • 第一个边界是信息不足：模型无法可靠知道私有知识，单靠 Prompt 要求模型 准确回答，无法弥补信息缺失；通过 few shot 的方式来外置知识，又很容易突破模型上下文窗口大小的限制。
• • 第二个边界是任务复杂：复杂任务往往需要多个输入来源，例如文档、数据库、历史对话、规则、样例、工具返回结果。Prompt 很难稳定组织这些信息。
• • 第三个边界是多轮漂移：模型在长对话中容易遗忘早期约束，或者被后续信息带偏（记忆和对话的上下文的压缩等等），尤其在 Agent 场景中，模型需要不断接收观察结果、工具输出和中间状态，Prompt 很难一次性覆盖整个执行过程。
• • 第四个边界是输出不可控：Prompt 可以约束格式和语气，但很难保证模型始终选择正确工具、引用正确证据、执行正确步骤。

这些边界推动工程重心从 Prompt Engineering 走向 Context Engineering。

Context Engineering

信息组织

Context Engineering 仍然是在给模型提供信息，但它关注的对象不再是一段静态提示词，它关注的是整个上下文窗口的组织方式。

澄清一下，Context Engineering 也不是直接在 decode 阶段约束模型，它和 Prompt 是一样的，仍然发生在模型调用之前，也就是构造本轮输入时；不同的时，Context Engineering 关注的是，在一次模型调用之前，系统应该选择哪些信息、裁剪哪些信息、压缩哪些信息、排列哪些信息，以及用什么结构呈现给模型，而 Prompt 仅仅是静态的一次性输入。

在一个知识问答系统中，Context Engineering 需要决定检索哪些文档片段，如何排序，是否保留引用，是否加入用户历史问题，是否加入业务规则，是否加入回答样例，是否压缩早期对话。

在一个 Agent 系统中，Context Engineering 还要决定当前任务目标是什么，历史执行到了哪一步，已经调用过哪些工具，工具返回了什么结果，哪些状态需要保留，哪些中间过程可以丢弃。

这些动作表面上确实也是在 “拼上下文”，但是它是在构造模型的局部环境；首先模型没有真正意义上的长期记忆，它只能在当前上下文窗口中进行条件生成，所谓让模型 “记住”，在工程上通常意味着三件事：

• • 1、把重要事实保存到外部存储
• • 2、在需要时检索出来
• • 3、以合适的结构重新放回上下文

所以 Context Engineering 的核心，不只是长上下文，也不只是 RAG，它属于是上下文选择、上下文压缩、上下文排序和上下文边界控制，它决定模型在本轮生成中能看到什么。

context 质量如何影响推理轨迹

前面我提到过，context 不能理解成信息或者历史对话的堆叠，因为会涉及到上下文超限和中间遗忘的问题，也就是说 context 越长并不意味着生成的结果越好。

Transformer 的注意力机制允许模型在 token 之间建立关联，但是这种预测性的机制不能代表模型每次都会稳定的关注最重要的信息，长上下文中存在噪声、冲突、重复、过时信息时，模型的生成路径会被干扰，这也是 Context Engineering 强调结构的原因。

同样是给模型十段资料，直接堆进去和按 “任务目标、已知事实、证据材料、约束规则、输出要求” 组织进去，效果会完全不同；模型对 输入顺序、标题层级、分隔符、字段命名、证据位置 都很敏感，这些细节会影响注意力分配，也会影响输出模式。

例如合同审查场景中，如果只是把合同全文塞给模型，再要求它 “找风险”，模型可能生成一份看起来完整但证据不足的意见。那比较合理的的方式是先把上下文拆成结构化材料，包括合同基本信息、关键条款摘录、标准条款模板、历史审查意见、风险规则清单、用户关注重点和输出格式要求；这样，模型生成时的条件分布会更稳定，它不需要从一大段混乱文本中自己寻找所有线索，而是在一个被工程化组织过的上下文现场中完成推理。

Context Engineering 的价值就在这里，它不改变模型权重，但会改变模型所处的信息环境。

Harness Engineering

运行结构

当 Prompt 和 Context 都解决到一定程度后，新的问题会出现；模型调用只是系统中的一个环节，真正的业务结果需要一整套外部结构来保证，这就是 Harness Engineering 需要解决的问题。

Harness 关注的不是单次模型输入怎么写，它需要解决如何把模型放进一个可运行、可观测、可评估、可治理的系统中；一个成熟的大模型应用，需要模型之外的多层结构，比如 输入预处理、上下文构造、工具调用、权限校验、结果解析、质量评估、异常重试、人工审批、日志追踪、反馈回流、版本管理和成本控制，这些动作在两年前做 LLM 应用时，我们在代码里面搞的一对兜底处理逻辑是一个思路，只不过这里换了个名字，另外随着大模型能力的不断增强，工程化层面需要兜底的也会越来越少。

从模型角度看，Harness 解决的是模型输出无法天然满足业务系统要求的问题，大模型生成的是概率结果，而业务系统需要确定性边界。模型可以给出建议，但系统要决定建议能不能执行；模型可以调用工具，但系统要决定工具权限；模型可以生成答案，但系统要评估答案是否合规、是否引用充分、是否触发人工复核。从这个角度来看，应用落地的重点已经从 “如何让模型说得更好” 转向 “如何让模型在受控系统中可靠工作”。

Harness 让模型能力进入业务闭环

以 Agent 为例，一个 Agent 不能只靠 Prompt 和 Context，如果一个 Agent 要完成 “查询告警信息并生成处理建议” 这个任务，系统至少要处理这些问题：

• • 1、用户是否有权限查询该告警信息
• • 2、模型是否选择了正确工具
• • 3、工具返回结果是否完整
• • 4、是否存在敏感字段
• • 5、生成建议是否符合业务规则
• • 6、是否需要人工审批
• • 7、执行过程是否可追踪
• • 8、失败后能否恢复

这些问题都不能完全交给模型自己解决，因为模型没有天然的权限边界，也没有天然的审计能力，更没有天然的事务一致性。Harness Engineering 要做的，就是把模型包裹在一套工程机制中，让模型负责它擅长的部分，让系统负责边界、状态和责任。这也是为什么今天的 Agent 框架越来越强调 trace、checkpoint、human in the loop、guardrails、eval、tool approval 和 workflow。

这些能力看起来离模型很远，但它们决定模型能不能进入生产环境。

从一次模型调用的链路看，Harness 贯穿在 请求进入、上下文组织、模型调用、工具执行、结果解析、质量评估和输出交付 的全过程中。用户请求进入系统后，先经过输入预处理，完成清洗、校验和规范化；随后进入上下文构造阶段，系统会检索知识、补充历史状态、组织证据材料；模型调用与工具调用发生在中间环节，原始输出随后进入结果解析阶段，被转换成结构化结果或业务可消费的内容。

接下来，系统会进行质量评估，判断结果是否满足准确性、一致性、安全性和格式要求。如果通过，则输出给用户或下游系统。如果没有通过，则进入人工审批、异常重试或回到流程继续处理。

这条链路没有脱离传统软件工程里面涉及到的各个环境，从这个角度来看的话。 Harness 就是一组抽象概念，它描述了大模型应用运行时的真实处理过程，但是怎么落地各个环节，每家公司都有自己的标准和基础。

三个阶段的关系的总结

4 月份在腾讯云社区 AI 公开课上，我做了一个名为《从 ReAct 到 Harness：谈谈 LLM Agent 的演进历程》的主题演讲，这里面我讲了三次范式迁移的分化过程（PPT 可以私信留言）；最近刚好也看到社区、技术群里有几位老师在讲这块的内容，大家其实对于这三者的关系其实还是基本能够达成共识的：

• • Prompt Engineering 解决任务表达问题，让模型知道要做什么
• • Context Engineering 解决信息组织问题，让模型看到依据什么做
• • Harness Engineering 解决系统运行问题，让模型在边界内稳定工作

这三层共同决定大模型应用的质量：只有 Prompt，没有上下文，模型容易空转；只有上下文，缺少 Harness，系统容易失控；只有 Harness，缺少良好的 Prompt 和 Context，模型能力又无法充分发挥。

从 Prompt 到 Context 再到 Harness，从架构上看，可以把它们理解为一个逐渐外扩的系统。最内层是模型本身，它根据上下文预测下一个 token，第一层是 Prompt，它提供任务指令和输出约束；第二层是 Context，它提供事实、状态、历史、证据和规则；第三层是 Harness，它提供工具、流程、权限、评测、观测和治理。

大模型应用工程的演进，就是从输入控制，走向上下文组织，再走向运行时治理。

这条路径为什么会形成？？？答案是： 没有概念怎么炒作，换汤不换药吧.....

PS：文中配图原自大模型生成，仅供参考