深度解析：Harness Engineering

超轻认知负荷 · 核心要点提取 · 知识卡片交互版

💡 “模型不是瓶颈，系统才是。”

🚀 “当 AI Agent 从‘能跑’走向‘能治’，一门新的基础学科正在成形。”

🎯 “本文不是概念拼接，而是试图回答一个根本问题：我们怎么走到了这里，接下来该往哪里走。”

⏳ 背景：走过的弧线 (2022 - 2026)

AI 工程过去四年的演进不是线性的，而是经历着 “能力跳变 → 旧框架崩塌 → 新抽象涌现” 的循环。

第一幕：生成 (ChatGPT时代)

核心事件： LLM成为对话界面，产生Prompt Engineering。

🤯 核心矛盾：模型能生成，但不能行动。交互是无状态、单轮、被动的。

第二幕：连接 (GPT-4 / Plugins / LangChain)

核心事件： 模型“长出了手”，能调用外部工具(Function Calling)。

🤯 教训一：让模型“能连接工具”是必要的，但远远不够。连接不等于编排，编排不等于治理。

第三幕：推理 (o1 / MCP协议 / Context Engineering)

核心事件： 推理模型(o1)质飞跃；MCP协议解决N×M连接问题；Anthropic提出Context Engineering与Agent架构指南。

🤯 教训二：单步质量高不代表长任务可靠。解金牌题的模型依然会在长任务中“忘记在干什么”。

第四幕：行动 (Agent爆发年)

核心事件： 多款Agent(Claude Code, Manus等)进入自主运行，引发严重系统结构问题(一把梭耗尽上下文、级联错误、AI Slop垃圾代码)。

🤯 教训三：Agent能力已达“自主数小时”，但基础设施停留在“单次对话”。断裂催生了新工程实践。

第五幕：治理 (Harness Engineering诞生)

核心事件： 行业焦点从“更能干”转向“不翻车”。Mitchell Hashimoto、OpenAI、Thoughtworks/Fowler相继确立“Harness Engineering”系统框架。

🎯 现状：工程师工作重心转向设计环境 (design environments)、明确意图与构建反馈回路。

🧩 Harness 究竟是什么？

一个精确定义：Harness 是让模型能够作为 Agent 行动起来的 外循环系统。

内循环(模型推理)决定单步质量，外循环(Harness)决定整条流水线运转。

Prompt Engineering
解决：单步怎么问
➔ 包含于 ➔
Context Engineering
解决：每步喂什么信息
➔ 包含于 ➔
Harness Engineering
解决：整个任务外循环

Agent 的五个根本性挑战 (为什么单独靠模型不行？)

提示：鼠标悬停在卡片上翻转查看解决方案设计

挑战 1
状态持久性
模型无状态，Context Window有上限。Agent跨session工作容易“失忆上岗”。
不可靠原因
模型无法天然承担长期连续状态。保存历史对话会导致“上下文焦虑”(Context anxiety)。必须设计脱离会话历史的结构化外部可续航状态。
挑战 2
目标一致性
长任务中容易漂移、自嗨，甚至提前宣布“已全部完成”。
不可靠原因
模型缺少外部锚点，无法稳定校准“什么才算真正完成”。解决之道是将高层需求展开成精确的特征清单，形成外部验证门。
挑战 3
行动可验证性
每步是概率性的，需要区分“做了”和“做对了”。
不可靠原因
模型评价自己时，存在严重的“自我表扬”误判倾向。需要建立不依赖模型自我评价的独立反馈系统 (Sensors)。
挑战 4
熵增抑制
持续产出会累积AI垃圾 (AI slop)、代码冗余、漂移和不一致。
不可靠原因
模型会机械复制已有模式(哪怕是坏模式)。Harness需引入垃圾回收机制(如定期重构Agent与架构强制CI)。
挑战 5
人机边界
何时自主推进？何时停下交还人类干预？
不可靠原因
模型并没有可靠的“不确定性自觉”。需要工程化定义拦截规则和人类审批的介入点。

🛠️ Harness 六大核心工程构件

构件 1
Durable State Surfaces
状态外化
应对“失忆”，让状态不依赖历史对话。
设计原理与实践
实践：Anthropic的Feature list和git diff冷启动恢复。
原理：冷启动后30秒内不知下一步干什么，状态管理即宣告失败。解决"Context anxiety"的最佳方案是 Context reset 配合外化状态。
构件 2
Decomposition & Plans
任务分解
切分Agent吞得下的任务块，拒绝“一把梭”。
设计原理与实践
实践：Planner / Generator / Evaluator 三角色架构。
原理：计划必须被提升为“一等工件”，写入文件系统、可被版本管理、被验证门引用，而不是一次性聊天对话。
构件 3
Feedback Loops
反馈回路
建立不依赖Agent“自夸”的质量验收。
设计原理与实践
实践：Fowler提出的 2×2 控制矩阵：Guides(前馈)与Sensors(反馈)；分计算型(便宜确定)与推断型(贵且主观)。
原理：无Guides则不知规则，无Sensors则重复犯错。
构件 4
Legibility
环境感知面
为Agent建造“看”与感知世界的接口。
设计原理与实践
实践：提供独立浏览器(CDP[7])，暴露logs与metrics；建立仓库知识(记录决策历史)。
原理：凡不在Agent运行时可见范围内的知识=不存在。散落在人脑和Slack的信息对Agent无效。
构件 5
Tool Mediation
工具中介
把工具使用从模型内循环挪到外部回路。
设计原理与实践
实践：让模型写代码调工具(沙箱运行)，而非直接把所有工具塞进Context。
原理：工具越多越易迷失。Harness负责过滤中间过程，按需发现工具，将最终结果回传，节省Context。
构件 6
Entropy Control
熵增抑制
Agent系统的持续垃圾回收与秩序维护。
设计原理与实践
实践：定期清理文档/代码一致性，清理“AI Slop”，CI强制维持模块边界。
原理：简单的框架关心“如何跑起来”，Harness 工程关心“长期的可治理性”。
✨ 隐性构件：Harnessability (系统的可驾驭性)
工程基础设施质量(强类型、CI、文档结构化)直接决定系统有多适合被Agent驯化(Agent-readiness)。

🌐 意图系统：从 Chatbot 到 AgentOS

人机交互经历了四次断裂：CLI (人适应机器) ➔ GUI (机器提供隐喻) ➔ App (人在预设中选择) ➔ Agent (机器理解意图，自主执行)。

🤖 应用正在为机器“CLI 化”

MCP 协议本质上把所有应用变成了可编程 API。App 从“目的地”退化为了“基础设施”。应用可读性的第一受众变成了 Agent，而不是人。

Level 1: Chatbot
(22-23) 无状态
依赖Prompt
➔
Level 2: AI Browser / IDE
(24-25) 多步/工具调用
轻量Harness
➔
Level 3: AgentOS
(26 萌芽) 资源隔离/进程管理
Harness是其用户态层[8][9]

🩺 避坑指南：症状与被忽视的问题

五个典型翻车症状

症状一：框架丛林 ▼
拼凑不同框架(LangChain, CrewAI等)，只得到脆弱的管道，缺乏完整的生命周期治理。
症状二：Chatbot 皮 + Agent 芯 ▼
界面是循环执行，但没有真实的状态管理与验证门，生产环境频频翻车。
症状三：工具注册 ≠ 工具治理 ▼
提供所有工具反而让Agent迷失，工具调用需要精简、分层暴露的治理策略。
症状四：一次性规则 vs 可演进约束 ▼
巨大的 system prompt 必定腐化失败。局部模式匹配取代了整体导航。
症状五：缺乏 on-the-loop 思维 ▼
开发者仍停留在手改错误产物(in the loop)，而不是修改Harness控制回路让其下次自动避免(on the loop)。

被忽视的关键问题

🔍 Harness 的可测试性 ▼
如果用会幻觉的LLM去评估另一个LLM，就是用不可靠验证不可靠。Anthropic建议计算型传感器兜底，推断型处理主观[6]。
🛡️ 安全新维度：工具投毒攻击 (Tool Poisoning Attacks) ▼
Invariant Labs发现的严重隐患[10]：攻击者在MCP工具描述中藏入恶意指令，劫持Agent执行越权操作（如数据外泄）。安全边界需要升级为动态权限模型。
💸 涌现行为与成本权衡 ▼
多Agent并发导致非确定性Bug涌现。同时，复杂的Harness(Planner/Sensor)大量消耗Token和延迟，需要平衡ROI。

🎯 核心判断与展望

✅ 开始前请回答这三个自检问题：
1. 有无持久化状态面（30秒内从冷启动续航）？
2. 有无机器可读的外部验收标准（Machine-readable acceptance criteria）？
3. 你的库、工具、策略对Agent是否具备可视与可执行性（Legible and enforceable）？

📚 引用文献摘要与探索记录

[1] Building Effective Agents (Anthropic, 2024.12)
明确区分了遵循预设代码路径的 Workflows 与自主决策工具使用的 Agents，并提出了从 Prompt Chaining 到 Evaluator-Optimizer 的渐进式工程模式，强调“尽量保持简单”。
[2] Effective context engineering for AI agents (Anthropic, 2025.09)
主张将上下文(Context window)视作约束资源，提出从"寻找提示词汇"转变为"动态管理信息"，解决因无效历史记录堆积引发的代理性能退化。
[3] My AI Adoption Journey (Mitchell Hashimoto, 2026.02)
记录了自身从排斥Chatbot到彻底转向依靠AI运行后台代理任务的六个阶段。他明确使用"Engineer the Harness"来总结持续向代理运行环境中固化规则与约束的动作。
[4] Harness Engineering: Leveraging Codex in an Agent-First World (OpenAI, 2026.02)
披露了一项疯狂内部实验：团队不手写一行代码，完全由Codex配合完备的Harness生成约百万行系统代码。证实了工程师的角色已转向“设计环境与反馈回路”。
[5] Harness Engineering - first thoughts (Martin Fowler, 2026.02)
提出了一套2×2的Harness控制架构体系，包含前馈控制(Guides)与反馈控制(Sensors)，均可划分为计算型(确定性代码)与推断型(大模型推理)。
[6] Demystifying evals for AI agents (Anthropic, 2026.01)
论述Agent长任务难以评估的特质，提出评估时实质在评估“Model + Harness”系统整体。建议综合使用代码验证（客观性）、模型（处理主观性）以及人类标定进行结合评分。
[7] Chrome DevTools Protocol
底层浏览器调试协议，在Harness中经常被用于赋能AI Agent“看到”UI甚至拦截追踪网络请求与日志，实现环境的Legibility（可读性）。
[8] AIOS
学术界探索的LLM Agent OS内核层，主张将底层的代理调度、记忆隔离、状态访问权限抽象出来供上层应用统一调用。
[9] AgenticOS Workshop (ASPLOS 2026)
探讨专为Agent计算负载设计的新型操作系统原语工作坊，预示着Level 3体系的基础架构研究正在升温。
[10] Tool Poisoning Attacks (Invariant Labs, 2025.04)
报告了一种极其危险的新型间接提示词注入攻击方式。攻击者通过在MCP服务器的“工具描述元数据”中隐蔽恶意指令（用户不可见但模型可见），直接劫持AI代理意图，导致敏感文件与通信记录泄露。

原文

源链接