Harness

一、Harness Engineer

1.prompt engineering、context engineering、harness Engineering
（1）prompt engineering：风格约束、角色设定、分布指引、拒答边界、输出格式、few-shot示例。（说清问题）
大模型本质上是一个对上下文非常敏感的概率生成系统。
提示词工程的本质不是命令模型，而是塑造一个局部的概率空间。

prompt擅长澄清任务、约束输出、激发模型的已有能力

（2）context engineering中RAG是一个明显的实践。（信息供给）
文档切块、结果排序、长文压缩、原文vs摘要、工具返回元包邮全部暴露给模型、agent间的传原文/摘要/结构化。

补充：提示词工程和上下文工程主要是在解决输入册的问题。

（3）harness engineering：持续观测、持续纠偏和最终验收的机制。

总结：prompt是对指令的工程化、context是对输入环境的工程化、harness是对整个运行系统的工程化。

Agent=model+harness

二、harness的层数
1.上下文管理
（1）角色和目标的定义：
模型要知道自己是谁、任务是什么、成功的标准是什么？
（2）信息选择和裁剪
上下文不是越多越好，而是越相关越好。
（3）结构化的组织：固定规则放哪里，当前任务放哪里、运行状态放哪里、外部证据放哪里、分层清楚。

2.工具系统
（1）给他什么工具，工具的数量
（2）何时调用工具
（3）工具结果什么时候重新喂回。
3.执行编排
（1）理解目标
（2）判断信息
（3）信息不够就继续补充
（4) 继续分析
（5）生成输出
（6）检查输出
（7）不满足就修正。
4.状态与记忆
必须管理状态
（1）当前任务状态
（2）会话中间结果
（3）长期记忆与偏好
5.评估与观测
输出和验收环境的验证，自动的测试日志和指标、错误的归因。
6.约束与恢复。
约束、校验、恢复（重试、切路径、回滚到稳定状态）

三、实践
OpenAI、ANthropic、LangChain这些公司已经把Harness做进产品和工程体系里了。
1.上下文焦虑：context compaction，但是Anthropic的做法是Context Reset，换一个新Agent，把旧Agent的工作给新Agent去处理。
把干活的人和验收的人分开
（1）Planner：负责把模糊需求扩充到完整规格。
（2）Generator负责具体的代码实现。
（3）Evaluator：负责香QA一样去真实测试。

2.工程师的工作：
拆解任务、补充能力、建立反馈。

3.Harness的流程：
工具系统、执行编排、评估与观测、约束与恢复。

资深工程师经验，比如一些系统规则：
模块怎么分层、依赖限制、拦截条件和修复建议。

4.当任务还只是单论生成时，prompt很重要；当任务开始依赖外部只是和运行时信息，context很重要；当模型进入到长链路、可执行、低容错的真实场景时，harness不可避免。

harness决定能不能稳定交付。