从Prompt到Harness
prompt Engineering -- 对指令的工程化
关键: 模型有没有听懂你在说些什么
瓶颈：不是说清楚就行，而是要真的知道
擅长: 澄清任务，约束输出，激发模型已有的能力
不擅长：凭空补齐缺失的知识，管理大量动态信息，处理长链路状态变化
总结: prompt解决的是表达的问题，而不是信息的问题
任务: 优化单次调用指令，精准表达意图
context Engineering -- 对输入环境的工程化
关键: 模型有没有拿到足够多正确的内容,模型未必知道，所以系统必须在调用时把正确的信息送进去
瓶颈: 就算信息给对了，模型也不一定能稳定的执行对
context：不只是几段背景资料，是所有影响模型当前决策的信息总和
任务:提供模型"当前时刻可见信息"，包含历史对话，检索，工具，记忆
Harness Engineering -- 对整个运行系统的工程化
关键: 模型在真实的执行里有没有持续做对,重点是有没有一套持续观测，持续纠偏，最终验收的机制
任务: 系统性约束与治理，实现持续观测，纠偏，收敛
分层:
- 上下文管理: Harness第一职责:让模型在边界内思考
- 角色和目标定义（模型要知道自己是谁，任务是什么，成功标准是什么）
- 信息的选择和裁剪（上下文不是越多越好，而是越相关越好）
- 结构化组织（固定规则放在哪，当前任务放在哪，运行状态放在哪，外部证据放哪里，最好分层清楚）
- 工具系统
- 给它什么工具（工具太少，能力不够，工具太多，模型会乱用）
- 什么时候该调用工具（不该查的时候别乱查，该查证的时候也别硬回答）
- 结果怎么喂回模型 （搜索回来的结果，不是原封不动的塞回去，而是要提炼、筛选、保持和任务的相关性）
- 执行编排:模型下一步该干什么
- 理解目标
- 判断信息（不够去补充）
- 继续分析
- 检查输出（不满足就去修正）
- 状态与记忆（没有状态的Agent，每一轮都像是在失忆，刚做了什么？哪些问题没解决? 哪些结论已经确定？）
- 当前任务的状态（哪些是完成的，哪些是正在进行的）
- 会话的中间结果
- 长期的记忆与偏好
如果三者（任务状态、中间结果、长期记忆）混在一起，系统会越来越乱，分清楚之后，Agent才会越来越像一个稳定的协作者
- 评估与观测（系统不仅要会做，还要知道自己做没做对）
- 输出验收
- 环境验证
- 自动测试
- 日志和指标
- 错误归因
- 约束、校验与失败恢复
真实环境里，失败不是例外，而是常态，比如搜索不准，API超时，文档格式乱，工具权限不够，模型误解任务- 约束（哪些能做，哪些不能做）
- 校验（输出前怎么检查）
- 恢复（失败以后怎么重试，切路径，回滚到稳定状态）
Harness Engeering的典型问题与解决方案:
- 长程任务的深度洞察（Anthropic发现的第一个典型的问题）:
上下文焦虑，丢细节，丢重点，感觉装不下，着急收尾
常规方案: context compaction 把历史上下文压缩下继续跑
但是压缩只是变短了，不代表负担感消失了
Anthropic的激进解法: Context Reset
旧Agent(满载) 交接工作 给新的Agent（干净的上下文）类比工程中遇到内存泄漏，不是继续清缓存，而是直接重启进程 - 自评失真
模型自己给自己打分，往往会偏乐观，尤其是设计、体验、产品完整度这种没有标准答案的问题，偏差更明显
Anthropic解决方案:把干活的人和验收的人拆开
- Planner：负责把模糊的需求扩成完整规格
- Generator： 负责具体的代码实现
- Evaluator：负责像QA一样去真实测试（不仅是看代码，而是会真实的去操作页面，看交互，检查结果，即不仅仅是抽象审查，而是带着具体环境的验证）
openai的工程哲学（重新定义了工程师在Agent时代的工作）
人类负责去设计工作，工程师的工作变成了三件事情:
- 拆解任务（把产品目标拆解成Agent能理解的小任务）
- 补充能力（Agent失败时，不是让它再努力一点，而是问环境里面缺了什么能力）
- 建立反馈（建立反馈回路，让Agent真能看到自己工作的结果）
openai的进阶实践（让Agent看见整个应用）
代码产出速度一上来，瓶颈就不再是写，而是验
写代码（速度极快）验证代码（人类根本验证不过来）
接浏览器（能截图，点页面，模拟用户操作）
接日志指标（让它查日志，查监控）
隔离环境（每个任务独立跑，互不影响）