从Prompt Engineering到Harness Engineering

Prompt Engineering

首先要明白LMM的原理: 本质上是:根据你输入的内容,预测下一个字,即生成式语言模型

因此,准确的提示词能够让AI更好地预测你的想法 写提示词的本质,不是在命令模型,而是在塑造它的概率空间

Context Engineering

Context Window:LLM能够看到的信息 Agent Skill的思路:渐进式披露

Harness Engineering

Harness Engineering的出发点:当模型从「回答问题」走向「执行任务」，系统就不能只负责喂信息，还要能「驾驭」整个执行过程

Harness的组成和结构

分为六层,可以按照功能分为下面的三组

输入侧: 上下文精细化管理+记忆与状态管理

动作侧: 工具系统+任务执行编排

校验侧: 评估观测+约束恢复

六层为: 上下文精细化,记忆与状态,工具系统,执行编排,评估与观测,约束与恢复

第一层:上下文精细化

• 确定角色和目标
• 按需给予相关信息
• 结构化组织

第二层:工具系统的可控调用

• 给予tools列表
• when to use
• return tool result to LLM

第三层:任务执行的全局编排

给予模型一条精确的workflow

第四层:记忆与状态的分层管理

Agent的状态不应该在上下文中,而是应该外化到文件系统中 AI没有记忆

第五层:独立的评估和观测系统

Eval集: 典型任务+标注好的标准答案;在Harness被更改的时候,把这些任务跑一次

Trace+日志+指标

第六层:约束校验和失败恢复机制

• 约束:定义"什么事不能做"

  最好能硬编码到代码或者linter规则中

• 校验:子啊每一步输出前后都做自动检查

• 恢复:失败后有预案

落地:

更诡异的是，Cognition（就是做 Devin 那家公司）在用 Claude Sonnet 4.5 重做 Devin 的时候，观察到一个特别有意思的现象，他们把它叫做「上下文焦虑」（Context Anxiety）。

什么意思呢？就是模型自己好像也能感觉到「我快撑不住了」。当它觉得上下文窗口快用完的时候，模型不仅开始丢细节，还会出现一种奇怪的行为：它开始着急地想收尾。它会突然简化方案、跳过验证步骤、急匆匆地宣布「任务完成」。

原则一：重启胜过修补，状态沉到文件里，Agent 随时可以在一个干净的上下文窗口里接力继续。

二:自我反思总是偏向乐观的

三角分工:

• Planner（规划者）：负责把模糊的需求扩展成完整的规格说明
• Generator（生成者）：负责一步一步去实现
• Evaluator（验收者）：负责像 QA 一样真实地测试

原则二：生产和验收必须分离，而且验收方必须能摸到真实世界

三:Agent失败后,工程师应该做什么?

原则三：Agent 反复失败的时候，别问模型能不能更努力，要问环境还缺什么

四:规范文件越写越长,为什么Agent反而越来越糊涂

核心思路:渐进式披露

• 主文件只保留 100 行左右的核心索引。你没看错，OpenAI 原文博客里特地写明了这个数字：整个 AGENTS.md 控制在大约 100 行，它不告诉 Agent 每条细节规则，只告诉 Agent「你想看什么，去哪儿看」
• 详细的内容拆到具体的子文档里：架构文档一份、设计原则一份、产品规格一份、执行计划一份、质量评分一份，每份都有清晰的主题
• Agent 平时只看目录，只有真的需要某一部分的时候，才钻进对应的子文档

原则四：规则文件宁缺毋滥，给模型看的东西少即是多

五:AL slop: AI代码泔水

• 把人类工程师关于"什么是好代码"的经验，写成一套「Golden Principles」（黄金原则）沉进仓库
• 让一批后台 Agent 按固定节奏自动跑

原则五：技术债不是攒一堆集中还，而是每天让后台 Agent 自动偿还一点