C3-15 Prompt → Context → Harness 工程
Prompt engineering
🦄 回顾1：大模型的基本原理——文字接龙
影响大模型输出的内容的，只有上下文！
因此，在初期（2023-），大家在说prompt engineering，实际上就是之前所说的Prompt技巧：
Context Engineering
📚 回顾2：Agent的几个模块——规划、记忆、工具
每个模块都会影响发送给大模型的上下文，想要Agent效果好，就优化Agent的整个上下文模块（包括规划、记忆、工具），统称为Context Engineering（2025-）
解决什么问题?
Prompt 只能解决"单次对话质量",但 Agent 需要外部知识和历史状态。
做什么?
在合适时机,把正确且必要的信息注入模型的上下文窗口。
核心手段
| 手段 | 说明 |
|---|---|
| RAG(检索增强生成) | 向量检索相关文档,拼进上下文 |
| 记忆注入 | 把历史对话 / 用户画像注入 |
| Token 优化 | 上下文有限,要挑最重要的放 |
| 渐进式披露 | 不一次性塞所有信息,按需加载 |
局限性
Context 做得再好,模型仍然不会自己执行代码、不会自己纠偏、不会在出错后自动恢复。
所以:需要外部知识的任务(问答系统、代码辅助)→ Context 很重要。
Harness Engineering
📚 为了让Agent在能干活的基础上，还能自行纠偏、迭代，Harness Engineering诞生（2026-）
1 | |
Model 只提供推理和生成。
Harness 是模型之外的整套系统:工具调用、文件系统、沙箱环境、编排逻辑、反馈回路、约束机制。
💡 类比:Model 是 CPU,Harness 是操作系统。CPU 再强,OS 天天崩,体验也不会好。
L1:信息边界层
| 解决什么 | 关键设计 |
|---|---|
| 模型看到不该看的信息 | 定义角色与目标,裁剪无关信息 |
| 上下文太杂导致推理质量下降 | 结构化组织任务状态,按需注入 |
Anthropic 实践:把 16 万 token 上下文,用到 40% 就开始质量滑坡。
L2:工具系统层
| 解决什么 | 关键设计 |
|---|---|
| 工具调用不稳定 | 精选工具、控制调用时机、提炼工具返回；沙箱环境 |
| 工具太多模型"选择困难" | 工具描述要精准,MCP 在这里发挥关键作用 |
L3:执行编排层
| 解决什么 | 关键设计 |
|---|---|
| 多步骤任务容易"跑偏" | 让模型按"理解 → 分析 → 生成 → 检查"轨道推进 |
| 长链路任务中途失败 | 分段执行 + 状态交接(Context Reset) |
L4:记忆与状态层
| 解决什么 | 关键设计 |
|---|---|
| 长任务中间结果丢失 | 独立管理当前任务状态、中间产物 |
| 跨会话记忆 | 持久化记忆文件 / 向量数据库 |
L5:评估与观测层
| 解决什么 | 关键设计 |
|---|---|
| Agent 自信地输出错误答案 | 建立独立于生成过程的验证机制 |
| 不知道 Agent 在哪一步失败了 | 接入可观测性栈(日志、Trace、指标) |
L6:约束、校验与恢复层
| 解决什么 | 关键设计 |
|---|---|
| Agent 生成破坏性的代码 | 预设规则拦截(Linter + 结构测试) |
| 执行失败没有后备方案 | 重试、回滚、降级策略 |
📚 开源项目参考：https://github.com/HKUDS/OpenHarness
附：loop engineering
Loop engineering（2026-）的聚焦点在于设计Agent自动迭代的循环，可以参考Claude code中的 /goal
| 维度 | Harness | Loop engineering |
|---|---|---|
| 类型 | 工程系统 / 平台 / 架构层 | 方法论 / 编排模式 |
| 作用对象 | 单个 Agent 行为 | 整个任务流程 |
| 核心能力 | 约束 + 校验 +工具调度 | 自动推进 +任务编排 |
| 抽象层级 | 低一层 | 更高一层 |
| 目标 | “让 Agent 不出错” | “让 Agent 自动干完活” |
类比：工厂
Harness
= 生产线规则 + 质检流程
- 工人怎么干活
- 哪些操作不允许
- 错了怎么修复
👉 控制“每一步怎么做”
Loop engineering
= 工厂调度系统
- 今天生产什么
- 谁来做
- 做完检查
- 下一步干嘛
👉 控制“整个流程怎么自动跑”