50 lines
2.1 KiB
Markdown
50 lines
2.1 KiB
Markdown
---
|
||
title: "Harness Engineering"
|
||
type: concept
|
||
tags:
|
||
- "harness-engineering"
|
||
- "agentic-ai"
|
||
- "system-design"
|
||
sources:
|
||
- "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
|
||
last_updated: 2026-04-20
|
||
---
|
||
|
||
## Overview
|
||
Harness Engineering——为 LLM 设计系统脚手架的工程学科，使 AI Agent 能在长周期自主任务中可靠执行。核心理念：**LLM 本身不是 Agent，Agent = LLM + 代码脚手架**。
|
||
|
||
## Evolution of AI Engineering
|
||
|
||
| Era | Focus | Limitation |
|
||
|-----|-------|------------|
|
||
| Prompt Engineering | 如何问（Instructions） | 脆弱，步骤间无持久性 |
|
||
| Context Engineering | 如何知道（RAG） | 无状态，无法控制长周期执行 |
|
||
| **Harness Engineering** | 如何约束和运行 | 解决连续多步执行控制 |
|
||
|
||
每个时代并非替代前一个，而是**吸收**前一个——Harness Engineering 仍需要好的提示词和好的上下文，但它增加了前两者都无法提供的执行层。
|
||
|
||
## 4 Design Principles
|
||
|
||
### 1. 约束而非指令（Constrain, don't instruct）
|
||
永远不要依赖模型"选择正确"——如果可以用程序化方式限制选择，就这样做。
|
||
- 提示词说"永远用有效 JSON 响应" = **希望**
|
||
- Schema 验证器拒绝格式错误输出 = **保证**
|
||
|
||
### 2. 外部化状态（Externalize state）
|
||
如果一条信息对任务连续性重要（已完成什么、待处理什么、什么失败了），它必须存在于 context window 之外。
|
||
- Context window 是易失的
|
||
- 磁盘文件是持久的
|
||
|
||
### 3. 每步可验证（Make every step verifiable）
|
||
如果你无法检查它，你就无法信任它。Harness 的每一层都应产生可被模型自身以外的东西验证的输出。
|
||
|
||
### 4. 局部失败而非全局崩溃（Fail locally, not globally）
|
||
单步工具调用失败应触发该步重试，而非重启整个管道。任何失败的爆炸半径应尽可能小。
|
||
|
||
## Implementation
|
||
- [[7-Layer-Harness-Stack]]：完整 7 层实现规范
|
||
- [[Minimum-Viable-Harness]]：Day 1 可构建的最小可行版本
|
||
|
||
## Source
|
||
- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
|