【学习笔记】Harness到底是什么

一、Harness的演化1、提示词工程提示词工程Prompt Engineering就是在不改动 AI 模型参数的前提下通过系统化设计、测试、迭代输入文本提示词让大语言模型LLM稳定、准确、可控地输出符合预期结果的方法论与实践技能。提示词的设计原则提示词为何有效大模型本质上是一个对上下文非常敏感的概率生成系统。所以你给它什么身份它更容易沿着那个身份去回答你给它什么样例它更容易沿着那个范式去补全你强调什么约束它就更容易把那部分当成重点所以 Prompt Engineering本质上不是命令模型”而是塑造一个局部概率空间。这个阶段最重要的能力不是系统设计而是语言设计。但Prompt很快就遇到了天花板。因为很多任务不是你说清楚就行而是“你得真的知道”。提示词擅长任务是1、澄清任务2、约束输出3、激发模型已有能力不擅长任务是1、凭空补齐缺失知识2、管理大量动态信息3、处理长链路状态变化提示词解决的是表达问题不是信息问题。在聊天机器人时代场景的特征是任务短、链路短、状态少靠把话说清楚”就能解决问题。但Agent火了之后场景发生了变化需要处理多轮对话、需要调用外部工具需要传递中间结果还需要根据反馈修改计划。这时候问题就变了从一次回答对不对 -- 整条任务链路能不能跑通提示词已经无能为力了2、上下文工程Context Engineering的核心:模型未必知道所以系统必须在调用时把正确的信息送进去。Context不只是几段背景资料从工程上讲它是所有会影响模型当前决策的信息总和。涉及系统规范、安全约束、Agent结果等等。也正因为如此同样的模型、同样的Prompt放进不同系统里效果可能差得非常大。差别往往不在模型而在上下文供给机制。说到 Context EngineeringRAG算是一个比较典型的实践。RAG的价值很直接: 模型参数里没有的知识怎么在运行时补进去?但真正成熟的Context Engineering关注的远不止检索一下”它关心的是整条链路如(1) 文档怎么切块2结果怎么排序3长文怎么压缩4历史对话怎么保存什么时间使用原文什么时间使用摘要。5工具返回要不要全部暴露给模型6多个Agent之间传输原文还是摘要还是结构化的字段包括最近很火的Agent Skills本质上也是Context Engineering 的高级实践。如果把所有工具、说明、参数全部一上来塞给模型效果并不佳原因是上下文窗口是稀缺资源信息一多注意力就散了。所以Skills采用的是一种特别典型的思路:渐进式披露。但是新的问题也出现了即使上下文信息给对了模型也不一定能稳定执行。你会发现之前的努力都在解决输入侧的问题:输入侧(Input)Prompt用于优化意图表达Context用于优化信息供给。但是对于执行侧(Execution)连续行动中的不确定性没有解决。当模型开始连续行动的时候谁来持续监督它、约束它、纠偏它。3、Harness工程1和2解决的是怎么让模型更能思考3解决的是模型别跑偏、跑得稳、出了错还能拉回来。提示词工程重点是把话说明白上下文工程重点是把资料准备齐Harness就是有没有一套持续观测、持续纠偏、最终验收的机制。三者的关系如下二、成熟的Harness包括哪些在一个Agent系统里除了模型本身以外几乎所有决定它能不能稳定交付的东西都可以算进Harness。一个成熟的Harness包括六层第一层 上下文管理从Harness视角去看Context。模型能不能稳定发挥很多时候不取决于它“聪不聪明”而取决于它看到了什么Harness的第一职责:让模型在边界内思考。1角色和目标定义模型要知道自己是谁、任务是什么、成功标准是什么。2信息选择和裁剪上下文不是越多越好而是越相关越好。3结构化组织固定规则放哪里当前任务放哪里运行状态放哪里外部证据放哪里最好分层清楚。因为信息一旦乱模型就很容易:漏重点、忘约束、甚至自我污染。第二层工具系统没有工具系统大模型本质上还是一个文本预测器会解释、会总结、会推理但接触不到真实世界。Harness的功用不是简单把工具挂上去而是要解决三个问题1给模型什么工具2什么时间该调用工具3工具结果怎么返回给大模型第三层执行编排解决大模型下一步如何工作1、理解目标- 2、判断信息- 3、不够就去补充 - 4、继续分析 - 5、生成输出 - 6、检查输出 - 7、不满足进行修正。第四层状态和记忆Harness需要处理当前任务状态、会话中间结果、长期记忆与偏好。第五层评估与观测这一层容易被忽视。很多系统不是“生成不出来”而是生成完了以后根本不知道自己做得好不好通常包括输出验收、环境验证、自动测试、日志和指标、错误归因。也就是说系统不仅要会做还要知道自己有没有真的做对。第六层:约束、校验与失败恢复成熟的Harness需要包括三部分三、Harness的工程实践1、 Anthropic的工程实践1Anthropic发现的第一个典型问题长程任务的深度洞察上下文焦虑问题出现丢细节、丢重点感觉装不下着急收尾。常用解法 Context Compaction把历史压缩。Anthropic发现压缩智能变短不解决问题。2Anthropic发现的第一个典型问题自评失真将问题拆分分为2个独立的角色最关键的是这个Evaluator不是只看代码他会操作页面、看交互、检查结果。也就是说它不是抽象审查而是带环境的验证。实现“生产和验收分离”。2、OpenAI的工程实践1开发工程师的核心工作不再是写代码而是变成拆解任务、补充能力和建立反馈。当Agent出问题时修复方案几乎从来不是“更努力而是缺了什么结构性的能力”2渐进式披露摒弃超大的Agents.md把这个文档变为目录页AGENTS.md只保留最核心的索引。3让大模型看见整个工程让Agent进行自我验证。结果就是Agent不再是写完代码就说做完了而是发现问题验证后解决问题。3OpenAI不是只靠人类Code Review来给代码质量兜底重点是这些规则不是只负责报错而是会把怎么修”也一起反馈给Agent。四、小结当任务还只是单轮生成时Prompt 很重要当任务开始依赖外部知识和运行时信息时Context很关键但当模型真的进入长链路、可执行、低容错的真实场景时Harness几乎不可避免。未来的重点是让大模型在真实世界里稳定工作。参考资料1、https://www.youtube.com/watch?v3DlXq9nsQOE2、https://zhuanlan.zhihu.com/p/2014014859164026634