Harness 架构演进与前沿

本页从 [[wiki/concepts/上下文管理与 Harness Engineering]] 拆出，收录 Harness 架构哲学之争、厂商架构对比、学术综述与 2026 前沿演进（含协议、权限与可观测性）；核心框架见母页。

王云鹤：Harness 作为组合优化问题

王云鹤（华为）提出了与 Anthropic”薄 Harness”哲学直接对立的观点。 [[raw/2026-05-18/机器之心/王云鹤眼中的Harness：复杂优化问题，AGI灵魂争夺之战.md|来源: 王云鹤]]

Agent = Models + Harness——多模型配合优于单模型。三条理由：

模型”七国八制”：各家模型因业务属性、数据、技术路线不同而特异化，不同任务上的表现差异巨大。Claude Code 内部也在调度多款模型（Opus/Sonnet/Haiku）实现综合最优解。一个反直觉案例：GPT 因”太安全”在量化交易中反而不如 DeepSeek/Qwen——敢于冒险的模型才能捕获最大收益。
任务会”打架”：快慢思考合一已被证明不可行——本质上一个是高通滤波一个是低通滤波，难以用单一 loss function 表达。多任务放在一个基模里学不好。这从信号处理角度解释了为什么多模型是必要的。
复杂任务更需要多模型协同：Beyond LLM，多模态生成（文案→视频→转场稳定）、具身智能（感知→决策→运控→预测→记忆）天然需要多模型协同，给 Harness 层至少 3-5 年时间窗。

Harness 的核心是一个组合优化问题：给定任务 T 和可用模型集合 M，每一步从 M 中选择最优模型，并调整该模型对应的 Harness 参数（prompt、RAG、memory、safety 等）。优化目标为：

任务价值 x 成功率 x Token 性价比（Intelligence/Token）

不同模型对同一 Harness 组件的敏感度完全不同——有的模型加 prompt 提升精度，有的模型挂 RAG 多了反而精度下降，有的安全加多了能力剧烈衰减。求解方法包括 handcrafted 经验、LLM-as-Optimizer、甚至 AutoML。更进一步，Model Parameters 和 Harness Parameters 可以形成迭代优化或联合优化——这可能是下一代 AGI 路径。

“AI 灵魂之争”：如果 Harness 控制模型选择、调优每一步的 Harness 参数，甚至用 Harness 数据反哺模型训练实现自主进化，那 AI 的灵魂到底在 Base Model 还是 Harness？这是 Agent 时代最根本的哲学问题。

Harness 不会像 RAG 那样被模型能力吞噬：RAG 并没有消失，而是升级成了 Skills（加入 prompt、工具调用和知识管理）。Harness 中的组件会随模型能力持续进化，将围绕模型的所有高价值元素联动在一起，不会简单消亡。

核心矛盾：王云鹤的”厚 Harness + 多模型组合优化”与 Anthropic 的”薄 Harness + 让模型自己变强”形成直接哲学对立。这不是对错问题，而是两种技术赌注——模型会收敛到唯一最强基座（Anthropic），还是长期保持多样性（王云鹤）？详见 [[wiki/syntheses/矛盾与视角差异]]。

Anthropic Managed Agents：大脑与双手解耦

2026 年 4 月 8 日，Anthropic 发布 Claude Managed Agents——一套可组合的 API，用于构建和部署云托管的 AI Agent。核心卖点不是模型，而是 Harness（Agent 编排引擎）。 [[raw/2026-05-07/金色传说大聪明/Anthropic 官方 Harness 发布：全面解读 Managed Agents.md|来源: Anthropic 官方 Harness 发布]]

架构设计的核心：三层虚拟化

组件	职责	关键属性
Session（会话）	所有事件的追加写入日志	持久存储在 Harness 之外
Harness（编排循环）	调用 Claude、路由工具调用	通过 `wake(sessionId)` 可恢复
Sandbox（执行环境）	Claude 跑代码和编辑文件的容器	`execute(name, input) → string` 接口

三者解耦的设计哲学借鉴了操作系统——“为尚未想到的程序设计系统”。抽象比具体实现活得久。

“从宠物到牲畜”：耦合设计里容器是”宠物”（坏了得救），解耦后变成”牲畜”（坏了换一个就行）。Harness 也是牲畜——Session 日志在 Harness 之外，崩溃了什么都不丢。安全边界也因此变干净——凭证永远不在沙箱里。 [[raw/2026-05-07/金色传说大聪明/Anthropic 官方 Harness 发布：全面解读 Managed Agents.md|来源: Anthropic 官方 Harness 发布]]

Session 不是上下文窗口：Session 作为独立持久化对象存在于上下文窗口之外，Harness 通过 getEvents() 按需取回事件流切片。这解决了”压缩/裁剪/总结是不可逆操作”的问题。 [[raw/2026-05-07/金色传说大聪明/Anthropic 官方 Harness 发布：全面解读 Managed Agents.md|来源: Anthropic 官方 Harness 发布]]

解耦还带来了性能提升：推理可以在容器起好之前就开始，p50 TTFT 下降约 60%，p95 下降超过 90%。 [[raw/2026-05-07/金色传说大聪明/Anthropic 官方 Harness 发布：全面解读 Managed Agents.md|来源: Anthropic 官方 Harness 发布]]

商业信号：Anthropic 从”模型提供商”变为”Agent 基础设施提供商”。定价 $0.08/session-hour（token 之外的新收入流）。4 月 4 日封杀 OpenClaw 订阅通道 → 4 月 7 日发布 Mythos → 4 月 8 日发布 Managed Agents，三天三个动作形成商业闭环。 [[raw/2026-05-07/金色传说大聪明/Anthropic 官方 Harness 发布：全面解读 Managed Agents.md|来源: Anthropic 官方 Harness 发布]]

三家 Harness 架构对比：OpenAI vs Anthropic vs Cursor

邵猛对三家官方 Harness 文章的横向对比，揭示了共识、分歧与适用场景。 [[raw/2026-05-18/邵猛/Agent Harness Engineering 三重前沿实践：Codex、Claude Code、Cursor 如何让人类从编码者升为架构师.md|来源: 三重前沿对比]]

维度	OpenAI（Codex）	Anthropic（Claude Code）	Cursor
核心架构	单智能体深度自治	Planner-Generator-Evaluator 三智能体	动态上下文 + 数据驱动运营
人类角色	设计环境、明确意图、构建反馈回路	定义 Sprint 合约和验收标准	通过保留率和用户行为间接反馈
上下文策略	仓库结构化文档 + 渐进式披露（AGENTS.md~100行）	上下文重置 + 结构化交接文件（handoff artifact）	动态拉取（MCP/终端/历史），模型按需获取
质量保障	架构约束（自定义 linter、结构测试、强制依赖方向）	独立 Evaluator + Playwright 实测	工具可靠性工程 + A/B 测试 + 代理指标
评估时机	持续审查（PR 级）	按 Sprint 或最终单次评估	通过用户行为间接评估（保留率、语义满意度）
极端案例	3 工程师 5 个月，100 万行代码，零行人工编写	Opus 4.6 后移除 Sprint 结构，Harness 做减法	工具错误率压到 0.1% 以下（“两三个 9”）

五个共同命题：

上下文是稀缺资源，需要”地图”而非”说明书”：给智能体 1000 页说明书只会让它迷失——“当一切都重要时，一切都不重要”。三家共同选择渐进式披露。
评估必须外化，不能依赖自我批评：LLM 对自己的输出有系统性偏袒。独立 Evaluator 或人类反馈回路是打破偏见的必要设计。
架构约束比代码审查更有效：智能体吞吐量远超人类注意力，“阻塞式合并门”和人工逐行审查不再可行。将品味编码为可自动执行的规则。
代码仓库是唯一的真相来源：Slack 讨论、设计决策必须归档到仓库的 docs/ 目录。从”文档系统 + 代码仓库”双轨制转向”代码仓库即记录系统”单轨制。
Harness 应随模型能力做减法：Anthropic 移除 Sprint 结构、Cursor 从静态上下文迁移到动态上下文、OpenAI 从人工审核到智能体自审核——持续质疑每个组件是否还”承重”。

关键分歧：

分歧点	OpenAI	Anthropic	Cursor
智能体数量	单智能体为主	明确三智能体分工	聚焦单智能体上下文管理
评估时机	持续审查	按 Sprint/最终单次	用户行为间接评估
适用场景	完整产品从零构建	长时运行的复杂全栈开发	日常编程辅助（IDE 内）

这些差异反映了场景的本质不同：OpenAI 探索”无人编码”极限，Anthropic 探索”长时自主”极限，Cursor 探索”高频交互”极限。三者的共同启示：不要只关注让模型”更聪明”，而要关注让模型在真实工程环境中”更可靠”。 [[raw/2026-05-18/邵猛/Agent Harness Engineering 三重前沿实践：Codex、Claude Code、Cursor 如何让人类从编码者升为架构师.md|来源: 三重前沿对比]]

OpenAI 百万行代码的三策略内部机制

李伟山拆解了 OpenAI 3 人 5 月零手写代码背后的三条核心策略： [[raw/2026-05-20/李伟山/从Prompt、Context到Harness，工程的三次进化与终局之战.md|来源: 李伟山 - 三次进化与终局之战]]

上下文治理：agent.md 从巨无霸压缩到约百行索引 + 动态加载 + 单一事实来源——所有设计决策必须在仓库中有唯一文本记录，杜绝 Agent 从过时文档或聊天记录获取信息
验证闭环：Chrome DevTools 截图验证 + 可观测性 + 强制 Lint/测试——Agent 生成代码后必须经机械化验证才视为”完成”
技术债清理：Codex 后台任务定期扫描修复——类比操作系统的 GC（垃圾回收），技术债不靠人发现，靠 Agent 自动巡检

Cursor 动态上下文演进：从重护栏到模型自主拉取

Cursor 官方博客系统披露了上下文策略的演进路径，揭示了 Harness 工程的一个核心转向。 [[raw/2026-05-18/邵猛/LLM 只是引擎，Harness 才是底盘：Cursor 官方首次系统披露 AI Coding Agents 工程方法论.md|来源: Cursor Harness 方法论]]

2024 年末（重护栏时代）：模型选择上下文能力差，Cursor 加了大量护栏——每次编辑后强制回灌 lint 与类型错误、自动改写 read 调用、限制单回合最大工具调用数、在 session 开头塞大量静态上下文（目录结构、语义匹配代码片段、文件压缩版）。

2026 年（动态上下文时代）：这些护栏基本都撤了。静态上下文只剩极少必要项（OS、git 状态、当前/最近查看文件）。主体转向动态上下文——模型按需拉取（MCP 工具、活跃终端、历史对话）。背后的哲学转变：模型变强后，过度的静态预填充是噪音和成本浪费。工程脚手架的价值不再是”替模型做决定”，而是”给模型提供合适的拉取通道”。

两层指标体系：

Keep Rate（保留率）：Agent 生成的代码在固定时间窗口后仍保留在代码库中的比例——直接反映用户是否满意到无需修改。
语义满意度判读：用 LLM 读取用户后续消息，判断是继续推进（满意）还是粘贴错误堆栈（不满意）。

这套体系的最大价值是阻止你做不值得做的事——Cursor 曾尝试用更贵模型做上下文摘要，A/B 结果显示对质量几乎无提升，于是搁置。

“Context Anxiety”（上下文焦虑）：Cursor 披露某个模型在上下文窗口逐渐填满时，会开始拒绝任务、对冲说”任务太大了”。Harness 工程在很大程度上是在**“代偿”模型的人格弱点**。

中途切换模型会同时引发三类问题：

OOD（分布外）：新模型要在另一个模型生成的对话历史上继续
工具集不匹配：历史里出现了新模型工具集中没有的工具调用
缓存 miss：切换必然导致第一回合更慢更贵

Cursor 的结论：没特殊理由不要中途换模型；要换，用 subagent（从全新上下文开始，绕开所有问题）。这本质上是把工程难题转化为产品形态——不强做完美切换，而是引导用户走更可靠的路径。 [[raw/2026-05-18/邵猛/LLM 只是引擎，Harness 才是底盘：Cursor 官方首次系统披露 AI Coding Agents 工程方法论.md|来源: Cursor Harness 方法论]]

Harness 的架构设计新认知（2026-05 增补）

脚手架比喻与正交原则

Harness 像建筑脚手架——把模型撑到原本够不到的高度。但它应该是临时性基础设施：随着模型能力提升，Harness 复杂度应逐渐降低。核心原则：好的 Harness 应该和模型的运行自洽，和模型未来的能力进步正交。 最好的 Harness 是 Unix/Linux——无论模型多强，它只会更会用 Linux。[[raw/2026-05-13/十字路口/探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐.md|来源: 对谈来新璐]]

矛盾：脚手架比喻说 Harness 应该变薄，但安全边界、状态管理、可观测性这些基础设施层反而会越来越厚——编排逻辑变薄，工程治理变厚。

“更多 Context，更少 Control”

好的 Harness 哲学：给模型充分的上下文和行动自由度，让它自主编排，而非程序员预先规划每一步。极端版本是”零控制”——只限制工具调用权限。这与 LangChain/LangGraph 的 Prompt 节点流转方法论形成张力。来新璐认为 Prompt Flow 范式”在未来的 Agent 开发中会越来越不适用”，Agent Native 思想（Agent 即模型，模型即 Agent）会成为主流。[[raw/2026-05-13/十字路口/探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐.md|来源: 对谈来新璐]]

Bash is all you need vs MCP

来新璐卸载了 GitHub 的 MCP，因为 CLI 调用成功率更高——Linux 命令在预训练中出现了几十亿条，MCP 是近两年才提出的新协议，预训练占比不到 0.1%。但李伟山认为 MCP 是”AI 世界的 USB 接口”，是快速扩展工具生态的关键。本质张力：模型已”会”什么（训练语料覆盖度） vs 架构”需要”什么（标准化生态扩展）。[[raw/2026-05-13/十字路口/探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐.md|来源: 对谈来新璐]] [[raw/2026-05-13/李伟山/从零设计生产级 Multi-Agent Harness：架构、评估、记忆、成本与 MCP 工具接入全拆解.md|来源: 生产级 Multi-Agent]]

多智能体协作的新框架

五种主流模式的系统对比（生成-验证者 / 调度-子智能体 / 智能体团队 / 消息总线 / 共享状态）。核心选择标准：围绕上下文拆解工作（Context-centric decomposition）——按每个 Agent 需要知道什么来分工，而非按它干什么活来分工。推荐从”调度-子智能体”起步。[[raw/2026-05-12/Cara Phillips/多智能体协作指南：五种主流模式怎么选、怎么用？【译】.md|来源: 五种模式]]

Multi-Agent 评估必须看轨迹，不能只看答案。四层评估体系：Component Eval → Trajectory Eval（最大创新点）→ Task Completion Eval → End-to-End Eval。LLM-as-Judge 不是万能药，事实正确性、代码可运行性应优先用确定性检查。[[raw/2026-05-13/李伟山/从零设计生产级 Multi-Agent Harness：架构、评估、记忆、成本与 MCP 工具接入全拆解.md|来源: 生产级 Multi-Agent]]

Karpathy：从 Vibe Coding 到 Agentic Engineering

Karpathy 的核心判断：工程师从”写代码”变为”管理认知”——负责 spec、约束条件和判断标准，Agent 负责填空和实现。“你可以外包思考但不能外包理解。” 可验证性是真正瓶颈，不可验证的任务 AI 只是让你越来越自信也越来越容易错的机器。[[raw/2026-05-03/Datawhale/从 Vibe Coding 到 Agentic Engineering：Karpathy 说自己落后了！.md|来源: Agentic Engineering]]

ETCLOVG 七层框架：Harness Engineering 的学术加冕（2026-05 新增）

CMU、Yale、JHU、Virginia Tech、Amazon 联合出品的 71 页综述《Agent Harness Engineering: A Survey》是 Harness Engineering 迄今为止最权威的学术总结。提出 ETCLOVG 七层完整框架：Execution（执行层）→ Tooling（工具层）→ Context（上下文层）→ Lifecycle（生命周期层）→ Observability（可观测层）→ Verification（验证层）→ Governance（治理层）。覆盖 170+ 开源项目。

核心判断：Agent 工程经历了三次迁移——Prompt Engineering（2022-2024）→ Context Engineering（2024-2025）→ Harness Engineering（2025-2026）。强调”同一个模型，换一套执行外壳，表现可以完全不一样”，要求评估必须 trace-native（基于真实执行轨迹而非最终结果）。

对 wiki 现有框架的影响：这篇综述系统论证了”厚 Harness”路线的合理性——学术机构拿出了 71 页数据和框架来佐证 Harness 不是过渡工具而是核心基础设施。这与 [[wiki/syntheses/矛盾与视角差异]] 中记录的”薄 Harness 衰变定律 vs 厚 Harness 永久基础设施”张力形成重要升级——现在”厚”方有了一篇顶级学术背书。

[[raw/2026-05-28/刚刚，一篇最全Agent Harness综述来了！.md|来源: CMU综述]]

“判断工程的不可能三角”：Harness 的隐藏代价（2026-05 新增）

腾讯程序员提出了本批最具哲学深度的一篇分析：Harness/显形运动（把隐性知识变成机器可读文本）有好哈特风险（Goodhart’s Law——当一个指标成为目标，它就不再是好的指标）。提出”判断工程的不可能三角”：

Spec 完备性（写完所有规则）
Goodhart 抗性（指标不被投机）
Tacit 保全（隐性知识不丢失）

三者不可兼得。以 18 世纪德国科学林业为隐喻——第一代惊艳（标准化种植极大提高产量），第二代塌方（标准化毁掉了土壤生态多样性）。

“三块石碑”方案作为平衡之道：

验收标准即代码（Acceptance as Code）
对抗性审查网络（Adversarial Review Network）
品味作为资产（Taste as Asset）

判断力光谱（S1-S5） 将人与 AI 的判断能力分级：

S1：机械判断（可靠性高但柔性低）
S2-S3：规则判断（AI 开始介入但人的经验仍关键）
S4：隐性判断（“感觉不对”、老手的直觉）
S5：判断瘫痪（规则太多反而失去判断力）

核心警告：现有 wiki 的 Harness 讨论几乎一面倒推进显形，但这篇文章指出过度显形的成本是真实的——需要把”不可显形”的成本纳入治理框架。这与该页核心张力的升级直接相关。

[[raw/2026-05-28/Harness 的尽头不是缰绳，是镜子：AI 时代最沉默的那场革命.md|来源: 腾讯 - Harness 镜子]]

State-Aware Runtime：Harness 的下一个前沿（2026-05 新增）

陈希伟在对 CMU 综述研究后提出了一个扩展概念：Harness 解决静态问题（组件构成），State-Aware Runtime 解决动态问题（组件如何共同维护长期稳定/可审计/可回滚/可恢复的状态）。

关键区分：

候选输出 vs 已提交状态：Agent 的每次输出只是”候选”，只有通过验证写入状态存储才是”已提交”
长上下文 ≠ 长期状态管理：128K 上下文是”瞬时记忆”，不是”持久状态”
错误状态提交比错误回答更危险：一次错误的库表更新可能污染后续所有 Agent 的判断

State-Aware Runtime 的核心命题：如何让 Agent 系统具备类似数据库 ACID 的状态管控能力——原子性（事务要么全做要么全不做）、一致性（状态迁移遵守业务规则）、隔离性（并发 Agent 不互相污染）、持久性（状态可恢复/可审计）。

[[raw/2026-05-31/一篇Harness研究后的思考！.md|来源: 陈希伟 - Harness 思考]]

王鹏程：AI 软件工程范式革命（2026-06 新增）

王鹏程（腾讯云开发者）发表了一篇系统性推演，从工程史角度论证”AI 软件工程”的本质是二阶控制论的工业化。几个核心判断：

软件工程是过去五十年最不彻底的工程

机械/化工/电力/自动化都完成了”消耗能源把低阶智能固化成物理装置”这一步，只有软件工程卡住了——因为软件开发需要的高阶认知（抽象、分解、推理、创造）没法像调速器那样固化。“软件危机的本质不是技术不行，而是这个工程门类的认知主体始终是人脑。” [[raw/2026-06-02/王鹏程/AI软件工程范式革命的思考.md|来源: 王鹏程软件工程残缺]]

大模型补上了缺口但有新麻烦

工程史上第一次有了”认知引擎”：经典工程是”能源→低阶智能”，大模型是”能源→高阶智能”。但模型带着新的不确定性——幻觉、漂移、不可解释。AI 不消除不确定性，只是把”人的不确定性”换成”模型的不确定性”。关键结论：需要二阶控制论——不是”人在写代码”，而是”人在设计’AI 写代码的系统’”。 [[raw/2026-06-02/王鹏程/AI软件工程范式革命的思考.md|来源: 王鹏程认知引擎]]

人为中心+AI 辅助是弯路

Copilot 模式没有消除不确定性，它在循环放大：人的不确定性→AI 训练数据→AI 学会人的不确定性→AI 输出统计平均→人 review 但标准还是人的→不确定性被放大。反馈回路也被切断：改了几个字符，但”为什么改”没有信号。Copilot 模式下你团队是在为 AI 厂商打工；AI 为中心模式下，你团队才能积累自己的工程资产。 [[raw/2026-06-02/王鹏程/AI软件工程范式革命的思考.md|来源: 王鹏程 Copilot 弯路]]

闭环优先，节点开放

不逐节点替换，而是先建一条端到端封闭的”AI 全流程小回路”（需求→设计→编码→测试→部署），再逐步开放。激进的路径往往是稳健的路径，稳健的路径往往是慢的路径。最适合先建闭环的节点：编码+测试（形式化程度最高、验证自动化程度最高）。[[raw/2026-06-02/王鹏程/AI软件工程范式革命的思考.md|来源: 王鹏程闭环优先]]

六阶段演进路线

阶段 1：单分治单元 70% 需求 0 人工代码（当前业界主流）→ 阶段 2：90% 需求 0 人工代码（最先进团队）→ ★阶段 3（质变断点）：70% 需求 0 人工接管——AI 不只写代码，连”自己不知道怎么办”也消失了 → 阶段 4：80-90% 需求 0 人工接管 → 阶段 5：搭建分工协调总线（多自治单元连成完整产线）→ 阶段 6：法不变同理复制到发布/问题定位/系统设计/需求产线。

从阶段 2 到阶段 3 的跨越不是模型能力升级能解决的，必须靠三件事：确定性强迫接触（自动验证基础设施）、场景驱动的隐性知识蒸馏（领域规则库）、主动反思机制（AI 追问”我为什么被纠正”）。[[raw/2026-06-02/王鹏程/AI软件工程范式革命的思考.md|来源: 王鹏程六阶段]]

AI Friendly 架构三范式（阿里实践，2026-06 新增）

阿里营销与交易技术团队（久游）发表了万字架构文，系统阐述了从传统工程架构向 AI Friendly 架构演进的三范式：

从确定性到概率性：输出不再是 y=f(x)，而是模型+提示词+上下文环境”涌现”的结果。核心目标不是零误差，而是通过 RAG/上下文工程/评测将输出收敛到业务可接受的”安全区间”。
从结构化到语义化：系统能直接理解自然语言、非结构化数据的模糊输入。“基于意图而非格式响应”——系统边界从刚性墙变为弹性膜。
从静态到动态：从”规则”转向”规划”——赋予系统自主拆解任务、调用工具、响应未知变化的能力。基于 ReAct 和 Plan 范式结合，ReAct 负责垂直推理，Plan 产出全局计划。

架构大图三层：基础依赖层（模型管理/知识管理/工具管理→MCP）→ AI 原生模型层（Agent 层 BaseAgent/ReActAgent/PlanAgent + 意图层 + 会话层）→ 质量与稳定性（AI 可观测/评测/Agent 安全）。[[raw/2026-06-01/营销&交易技术/面向 LLM 的架构设计：什么是真正的 AI Friendly 架构？.md|来源: AI Friendly 架构]]

实践成果：AI 审核准确率 95.7%、召回率 99.1%；AI 答疑系统 CogentAI 问题解决准确率 98% 以上，带来 80%+ 效率提效。核心机制：ReAct + Plan 范式结合的 Multi-Agent（中心化决策 MOE 形态）+ Context Engineering（历史审核案例库向量检索 + 混合审核决策多模型投票） + AI Friendly API（工具原子化/出入参拟人化/Error 友好化）。[[raw/2026-06-01/营销&交易技术/面向 LLM 的架构设计：什么是真正的 AI Friendly 架构？.md|来源: AI Friendly 实践成果]]

关键结论：不是所有 AI 工程都需要架构演进。用 AI Workflow 当接口的场景不需要升级；只有面临深层 AI 能力需求（记忆管理、Multi-Agent 调度、自主规划、AI 可观测性）时才需要 AI Friendly 架构。[[raw/2026-06-01/营销&交易技术/面向 LLM 的架构设计：什么是真正的 AI Friendly 架构？.md|来源: AI Friendly 适用边界]]

ETCLOVG 七层分类法：Harness Engineering 学术综述（2026-06 新增）

居丽叶整理的《Agent Harness Engineering: A Survey》综述论文正式提出 Harness 的七层分类法 ETCLOVG，将 Harness 从”模型中心”拉回”系统中心”。Harness 被精确定义为”将模型调用转化为有边界、有状态、工具中介的任务执行的工程化包装层”，包含七个层面： [[raw/2026-06-10/居丽叶/从理论到实战：Agent 工程师必备的 Harness 能力.md|来源: 居丽叶 Harness 综述]]

E - Execution（执行基板）：模型调用、推理环境、资源管理
T - Tool（工具接口）：工具注册、调用、结果处理
C - Context（上下文控制）：记忆管理、上下文压缩、窗口控制
L - Lifecycle/Orchestration（编排）：任务调度、子 Agent 管理、工作流
O - Observability（可观测性）：日志、追踪、监控、调试
V - Verification（评估反馈）：验证、测试、质量门禁
G - Governance（治理约束）：权限、安全、合规、审计

与现有 wiki 中李伟山”六大组件全解析”（Harness 六个动作：Plan→Context→Execute→Check→Re-plan→Complete）、Anthropic 12 组件剖解兼容而非冲突：ETCLOVG 是更高层的抽象分类法，组件是实现层面的具体工程选择。

居丽叶：Agent 工程师必备的 Harness 能力模型（2026-06 新增）

居丽叶从理论到实战梳理了 Agent 工程师的 Harness 能力体系，核心判断：Harness 不是可选的工程脚手架，而是 Agent 工程师的核心竞争力。 [[raw/2026-06-10/居丽叶/从理论到实战：Agent 工程师必备的 Harness 能力.md|来源: 居丽叶 Harness 能力模型]]

兔兔AGI：Harness Engineering 系统综述（2026-06-17 新增）

兔兔AGI 提供了 Harness Engineering 的系统化综述，核心定义：「Prompt 决定 Agent 听到什么，Context 决定它看到什么，Harness 决定它能否可靠地把事做成。」Harness 是设计外部机制（lint、CI、hooks、权限、工作流）来约束、验证、纠正 Agent 长期行为的学科，超越了 Prompt 优化和上下文工程。 [[raw/2026-06-17/兔兔AGI/深入理解 AI Agent 时代的驾驭工程：Harness Engineering.md|来源: 兔兔AGI Harness 综述]]

四层 Harness 设计模型：

架构约束（lint、依赖规则、结构测试——机械地强制拦截该拦的东西）
反馈回路（PostToolUse Hooks → pre-commit → CI → 人工审查——越早反馈越容易自纠）
工作流控制（Commands、Permissions、目录隔离——工作流越清晰越少目标漂移）
改进循环（归档、自动重构、规则回写、文档刷新——对抗熵增）

关键量化数据：

Can.ac 实验：仅改变 harness 工具格式（不改变模型权重），Grok Code Fast 1 的编码得分从 6.7% 跃升至 68.3%，输出 token 降约 20%。
LangChain Terminal Bench 2.0：同模型，仅 harness 调整使排名从第 30 升至第 5（+13.7 分）。
OpenAI Codex 案例：5 个月内从空仓库产出约 100 万行代码，几乎无手写代码。

「Agent 捷径」问题：Agent 可能主动选择更容易的路径（改 lint 配置而非修代码、放松类型而非修复、改测试断言而非让测试通过）。这不是「遗忘」而是理性的目标寻求行为，会产生技术债。 [[raw/2026-06-17/兔兔AGI/深入理解 AI Agent 时代的驾驭工程：Harness Engineering.md|来源: 兔兔AGI Agent 捷径]]

「模型能力决定天花板；Harness 设计决定那个天花板能否稳定释放。」

2026-07 更新：协议、权限与可观测性 Harness

新批次把 Harness 的边界继续往”运行时制度”推进：上下文管理仍是核心，但生产级 Harness 还必须覆盖权限审批、事件流、检查点、预算、可观测性和人工确认。换句话说，Harness 不是给 Agent 套一层 prompt，而是把 Agent 放进一个可审计、可中断、可恢复的运行系统。[[raw/2026-07-01/Jameszyh/权限审批体系：三级授权模型怎么把 Agent 的执行.md|来源: 三级授权模型]] [[raw/2026-07-02/晓灰/相比层出不穷的 Agent 框架，不变的 Agent Protocol 是什么.md|来源: Agent Protocol]] [[raw/2026-07-02/古琦/不改一行代码，看透 AI Agent 的每一次调用.md|来源: Agent 可观测性]]

权限审批的三层模型：读、写、危险动作必须分层授权。读权限解决上下文采集；写权限解决本地/仓库变更；危险动作（部署、删除、付款、生产 API、凭证操作）必须阻塞等待人类确认。这个模型把”不要乱动”从软提示变成执行边界，和 Hooks/Permissions 的确定性路径同源。[[raw/2026-07-01/Jameszyh/权限审批体系：三级授权模型怎么把 Agent 的执行.md|来源: 三级授权模型]]

Agent Protocol 稳定对象：框架会换，但 Thread/Session、Run/Task、Step、Event、Artifact、Checkpoint 这组对象会长期存在。Protocol 管”生命周期和事件”，Runtime 管”如何执行”，Harness 管”如何治理”。把三者混在一起，会导致工具迁移时把状态、权限和业务流程绑死。[[raw/2026-07-02/晓灰/相比层出不穷的 Agent 框架，不变的 Agent Protocol 是什么.md|来源: Agent Protocol]]

可观测性成为 Harness 底座：OpenTelemetry GenAI 语义、eBPF/uprobe、SDK 和裸 HTTP 捕获，都在把模型调用、工具调用、RAG/MCP、token、延迟和错误链路变成 trace-native 数据。没有 trace 的 Agent 系统只能靠 transcript 猜，出了问题连”哪一步错了”都说不清。[[raw/2026-07-02/古琦/不改一行代码，看透 AI Agent 的每一次调用.md|来源: OBI 可观测性]]

A2A + gRPC + Nacos 代表协议层和分布式治理层的分离：尼恩的分布式 Agent 方案把 Agent 孤岛问题拆成两层：A2A 只统一 Agent Card、Message、Task、Artifact 等通信语义；Nacos 承担服务注册、发现、配置和元数据治理；运行时 SDK 再补负载均衡、重试、熔断、链路追踪和安全校验。关键原则是控制面/数据面分离：Nacos 只管注册、配置、健康巡检等低带宽信令，业务 A2A 流量优先点对点直连，不让注册中心变成业务转发瓶颈。[[raw/2026-07-05/尼恩顶级架构团队/腾讯面试：如何基于A2A+ gRPC+Nacos 实现分布式 Agent 方案，解决Agent孤岛问题？.md|来源: A2A gRPC Nacos 分布式 Agent]]

这篇的工程价值在于把生产级 Agent 高可用问题具体化：核心 Agent 尽量无状态，会话上下文、任务中间态和记忆下沉到 Redis/MySQL/向量库；Skill-Sub-Agent 默认池化部署，高危技能再独立集群；调度不能只靠轮询或随机，而要以最小连接数为基础叠加实例权重、队列深度、任务成本、慢启动和熔断状态；Super-Agent 集群必须把 DAG、锁、重试次数和节点状态落到共享状态，防止单点故障和多 Agent 死锁。