Update nexus wiki content

wiki/concepts/Harness-Engineering.md

@@ -0,0 +1,49 @@
+---
+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]]