Harness Engineering
通过工程化体系，系统性约束、引导、纠错智能体行为，提升可用性。
概述：Agent = Model + Harness
工业界的 Harness Engineering，指横跨电气、结构、工艺、制造的系统集成学科。例如，Boeing 787 线缆约 500KM，将成千上万根导线、连接器、端子、护套、卡扣——组织成可制造、可装配、可维修、可靠运行的线束总成，对线束工程师（Harness Engineer）提出了覆盖电气、机械、物料、工艺、图纸等多维能力要求。在近年的 LLM 智能体语境中，Harness Engineering 被借用来表示"包裹 AI Agent 的运行底座"：调度、权限、工具调用护栏、校验反馈循环、上下文管理——即 Agent = Model + Harness。这里的 harness 是"驾驭/套缰"的比喻义，和物理线束同源（都来自 horse harness 马具）。
The concept of recursive self-improvement (RSI) dates back to I. J. Good (1965). A harness is the system surrounding a base model that orchestrates execution and decides how the model thinks and plans, calls tools and acts, perceives and manages context, stores artifacts, and evaluates results.
作为智能体开发中关键的工程方法论，Harness Engineering 的核心理念与目标是通过优化模型周围的系统，而非频繁更换模型本身，来提升Agent的可靠性。
智能体经历的范式演进
| 对比维度 | Prompt Engineering (2023-2024) | Context Engineering (2025) | Harness Engineering (2026~) |
|---|---|---|---|
| 核心关注点 | 如何提问（输入措辞） | 给什么信息（信息输入） | 如何确保做对（运行环境） |
| 优化对象 | 单次提示词质量 | 上下文信息结构 | 智能体全生命周期控制 |
| 时间维度 | 单轮交互 | 多轮对话 | 完整任务闭环 |
| 解决核心问题 | 单次对话质量 | 知识边界与幻觉 | Agent 可靠性与可持续性 |
| 错误处理 | 人工重试 | 人工筛选上下文 | 自动化反馈回路 |
| 可验证性 | 无 | 有限 | 内置验证机制 |
| 工程目标 | 提升单次输出质量 | 扩展知识边界 | 确保复杂任务稳定完成 |
| 控制范围 | 仅输入端（提示词） | 输入 + 部分中间状态 | 输入→执行→输出→反馈全链路 |
| 代表技术 | Few-shot、CoT、角色扮演 | 向量数据库、检索增强、记忆系统 | 沙箱环境、权限控制、自动验收、状态管理 |
| 工程师角色 | 提示词雕琢师 | 信息架构师 | 系统设计师（驾驭者） |
核心价值（R.E.S.T模型）
- 可靠性（Reliability）：生产级 Agent 的核心前提。通过检查点恢复、操作幂等性、行为一致性管控，实现任务中断可续、错误可容错、输出可预期，彻底解决 Agent 随机翻车的核心痛点。
- 效率（Efficiency）：规模化落地的核心保障。通过 Token 预算管控、上下文智能规约、资源配额管理，实现成本可控、低延迟响应、高吞吐量处理，根治长任务 Token 消耗失控的问题。
- 安全性（Security）：企业级落地的不可逾越红线。通过最小权限原则、沙盒隔离执行、输入输出全链路过滤，实现权限可控、风险可隔离、操作可拦截，从根源规避越权访问、数据泄露、指令注入等安全风险。
- 可观测性（Traceability）：系统迭代的基础。通过全链路追踪、决策归因、状态审计，实现问题可溯源、行为可解释、历史可复盘，破解 Agent 黑盒不可控的难题。
Harness Engineering 中，所有系统内外的交互都必须由明确的、机器可读的契约（Schema、API、Event）来定义，这是实现模块化、可测试性和系统演进的基础。安全不是事后添加的功能，而是系统设计的出发点，遵循最小权限、零信任和纵深防御原则。系统的每一个行为、每一次决策、每一次资源消耗都应该是可度量的，没有度量就没有分析和优化。
Harness 本质上是一个包裹在 LLM 之外，带边界控制、工具路由与确定性反馈的 REPL（Read-Eval-Print Loop）容器，完整管控 Agent「感知 - 规划 - 行动 - 反思」的全生命周期，将非确定性的模型推理，接入确定性的工程体系。生产级的 Harness 体系采用管控分离的分层架构，实现高可用、高可扩展。其中，
- 控制平面负责决策与管控，核心能力包括任务调度、资源配额、行为规划、策略规则、权限管控；
- 数据平面负责纯执行，核心承载 Agent 运行实例、状态存储、记忆管理、沙盒执行环境。
Harness 技术架构
典型分层
- Environment（环境层）：
文件系统、Shell、网络、代码仓库、沙箱容器——Agent 能物理触碰的世界。 - Tool（工具层）：
统一工具接口、MCP 服务、内置 Bash/Read/Edit、业务 API 封装。把"模型想调用"翻译成"系统真执行"。 - Control（控制层 / 护栏）：
权限系统、沙箱隔离、超时中断、输入输出护栏（OpenAI 三级：input/output/tool guardrail）、Hard Stops 与 Escalation 规则。 - Memory（记忆层）：
会话持久化、MEMORY.md / AGENTS.md、PROGRESS.md 检查点、上下文压缩（摘要化丢弃冗余工具输出）、向量库长期记忆。 - Orchestration（编排层）：
Agent loop（ReAct / Plan-Execute）、子 Agent 委派、任务路由、错误分类与重试（瞬时错退避、可恢复错回灌模型、用户可修复错人工介入）。 - Evaluation & Observability（评估观测层）：
Trace 记录全流程、Hooks 卡口、结构化输出校验、CI 测试反馈、bad case 回归、Replay 复现。
Red Hat 在此基础上把外层再加一层 Infra → Sandbox → Harness → Runtime → Model 的俄罗斯套娃视图，强调沙箱是与 Harness 相邻而非内含的安全边界。
技术要点
- 上下文架构：
信息优先级分层（e.g., 动态裁剪低优先级历史记录）、Token 监控（上下文利用率）、结构化上下文、滚动窗口管理（滑动窗口、摘要压缩） - 架构约束：
工具白名单、参数强类型、权限分级、沙箱、工具幂等校验（重复执行统一操作不会产生副作用） - 上下文隔离：
任务边界隔离、错误隔离、角色上下文隔离 - 熵增对抗：
上下文蒸馏、状态清理、规则冲突检测、死亡引用清理、知识蒸馏沉淀（session 记忆 → user/repo 记忆） - 自验证循环：
前/后置条件验证（Claude Code Hooks允许集成自定义验证逻辑）、自我校正、限次重试、进展跟踪（受 GAN 启发，用单独的 Agent 做评判审查） - 可拆卸性（Detachability，即模块化）：
抽象接口、Prompt 模板分离、能力特性（是否支持视觉、长上下文、函数调用等）标记。应用层 → Harness Core（模型无关） → Adapter（可替换，prompt/schema/response适配） → API。
建议采用由实际问题驱动的迭代方式，而不是预先设计所有防护机制，避免过度工程化，即：先简单再复杂，随模型演进动态调整。反向同样成立：随着模型能力提升，应主动精简 Harness。
Agent 的能力边界取决于其可用工具的质量：与其提供二十个功能模糊的工具，不如提供五个边界清晰、文档完善的工具。