上下文管理与 Harness Engineering

TL;DR

这页回答的是：为什么 AI Agent 的稳定性越来越取决于 Harness，而不是只取决于模型或提示词。主线是 Prompt Engineering -> Context Engineering -> Harness Engineering，再到 Loop Engineering 的争议性延伸；核心判断是：上下文、权限、工具、记忆、评估、恢复机制共同构成执行环境，决定 Agent 能不能长时间做对事。[[raw/2026-05-07/金色传说大聪明/Anthropic 官方 Harness 发布：全面解读 Managed Agents.md|来源: Anthropic 官方 Harness 发布]] [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: 为什么能稳跑 6 小时]]

什么时候读这页

需要判断 Prompt、Context、Harness、Loop 的边界时。
需要设计长任务 Agent 的权限、工具、记忆、验证和停止条件时。
需要解释为什么“模型更强”并不自动等于“任务更稳”时。
需要找 Harness 工程案例、组件清单、失败模式或企业落地材料时。

核心判断

Harness 是执行侧工程，不是提示词包装；Prompt 解决表达，Context 解决信息，Harness 解决运行稳定性。
Loop Engineering 的价值不在“循环”这个词，而在外层循环的目标、预算、恢复、验证和停止条件是否工程化。
模型与 Harness 是联合优化关系；模型变强后，有些旧约束会变成新负担，Harness 需要定期瘦身。
生产级 Agent 的主要工程量经常落在非模型部分：工具、状态、权限、沙箱、评估、恢复和观测。

证据地图

主题	先读段落	代表来源
三次范式跃迁	`三次范式跃迁：从教模型说话到给模型搭环境`	[[raw/2026-05-20/李伟山/从Prompt、Context到Harness，工程的三次进化与终局之战.md
Harness 组件	`12 组件解剖：Harness 作为操作系统`、`生产级 Harness 关键机制`	[[raw/2026-05-12/Akshay/深度拆解：AI 智能体 Harness 的构造【译】.md
Loop 关系	[[wiki/concepts/Loop Engineering]]	[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md
企业实践	[[wiki/concepts/Harness 工程案例索引]]	[[raw/2026-06-17/澄沨/更可靠的主播助理：淘宝主播Agent的Harness工程实战.md
主要矛盾	`核心矛盾梳理`	[[wiki/syntheses/矛盾与视角差异]]

三次范式跃迁：从教模型说话到给模型搭环境

AI 编程方法论经历了三代演进，这不是换时髦词，而是控制权在转移：

代际	你在做什么	核心问题	典型产物
Prompt Engineering	写更好的提示词	模型有没有听懂你？	精心设计的 Prompt 模板
Context Engineering	优化上下文信噪比	模型有没有拿到正确的信息？	/compact 策略、HANDOFF.md、RAG
Harness Engineering	设计 AI 的工作环境	模型在真实执行中能不能持续做对？	完整的 .claude 配置 + Hooks + Skills + MCP

OpenAI 工程师 Ryan Lopopolo 的名言被反复引用：“Agents aren’t hard; the Harness is hard.” Mitchell Hashimoto（HashiCorp 创始人）给出了最简洁的操作性定义：每发现 Agent 犯一个错误，就工程化地消除它再次发生的可能性。 [[raw/2026-05-07/新安/Harness Engineering：耗时一周，我是如何将应用的AI Coding率提升至90%的.md|来源: 新安 - Harness Engineering 实战]]

第三次跃迁的关键是：关注点从”输入侧”（Prompt+Context）扩展到”执行侧”（监督、约束、纠偏、验收）。Prompt 解决表达，Context 解决信息，Harness 解决执行稳定性。三者不是替代关系，是包含关系。 [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 为什么别人的 Agent 能稳跑 6 小时]]

三次进化的边界定义（李伟山）：Prompt 回答”该说什么”，Context 回答”该知道什么”，Harness 回答”系统如何可靠运转”。三者层层包裹，不是替代关系——每一层都在前一层基础上扩展了控制范围。Prompt Engineering 的衰退已被数据验证：GPT-3 时代 few-shot 是必需品，GPT-4/Claude 3 之后 Prompt 的边际效益显著降低，重心自然地移向 Context 和 Harness。 [[raw/2026-05-20/李伟山/从Prompt、Context到Harness，工程的三次进化与终局之战.md|来源: 李伟山 - 三次进化与终局之战]]

Loop Engineering 相关段落已并入 [[wiki/concepts/Loop Engineering]]

核心公式与修正

LangChain 团队公式：Agent = Model + Harness

他们在 Terminal Bench 2.0 上做了一个决定性实验——全程用同一个模型（GPT-5.2-Codex），只改 Harness，通过率从 52.8% 提升到 66.5%，排名从 30 开外杀进 Top 5。13.7 个百分点的提升，模型一行没换。 [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - LangChain 数据]]

两处必要修正：

Model 和 Harness 不是独立替换的，而是联合优化关系。Anthropic 发现升级到 Opus 4.5 后”上下文焦虑”大大缓解，Context Reset 这种重型机制不再需要——模型变强了，Harness 就可以变简单。 [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - Anthropic 发现]]
公式少了一个关键维度——人在回路中的动态驾驭。更完整的表述应该是：Agent = f(Model, Harness, Human-in-the-Loop)。Harness 修路（静态约束），人握方向盘（动态驾驭）。 [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 完整公式]]

某头部 AI 实验室的 Agent 项目源码揭示了一个震撼数据：512K 行代码中，query() 主循环 16 个步骤只有 1 个是”调用模型”，其余 15 个全是验证和修复逻辑。95% 的代码全是 Harness。 [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 512K 行项目数据]]

Harness 衰变定律

李伟山提出一条关键规律：模型越强，Harness 应越薄。 工程师的核心能力不是堆更多约束，而是动态判断哪些约束该加、哪些该撤。两个检查问题应反复问自己：

“这个约束是因为模型能力不足，还是因为业务逻辑本身需要它？”
“如果下一版模型变强 20%，Harness 里哪些可以简化？”

这与 Anthropic 移除 Sprint 结构、Cursor 从静态上下文迁移到动态上下文的实践一致——Harness 工程的核心动作不是”建设”，而是”质疑每个组件是否还在承重”。 工程师的衡量标准也因此切换：“每天写多少行代码”变为”Harness 能支撑多高的代码产出率”；“个人产出”变为”系统杠杆”。 [[raw/2026-05-20/李伟山/从Prompt、Context到Harness，工程的三次进化与终局之战.md|来源: 李伟山 - 三次进化与终局之战]]

王云鹤组合优化、Anthropic Managed Agents 两节已拆至 [[wiki/concepts/Harness 架构演进与前沿]]

Harness Engineering 的工程支柱

六大支柱（综合多方实践）

综合 OpenAI、Anthropic、LangChain 及国内多家团队的实践，成熟的 Harness 包含六层（有依赖顺序）： [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 六大支柱]]

支柱一：上下文架构——精准设计进入模型上下文的信息。核心手段：渐进式披露（AGENTS.md 控制在 ~100 行做索引）、四级压缩管道、分层记忆。上下文窗口利用率超过 40% 时模型推理质量显著下滑。 [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 上下文架构]]

支柱二：架构约束——用代码强制执行规则，而非写在 Prompt 里。核心理念：Fail-Closed 默认值（遗漏不是漏洞，是特性）、自定义 Lint 即修复指引、五层纵深防御权限体系。关键转变：用硬约束替代软约束。[[raw/2026-05-08/晋小辰/Harness Engineering：从 Prompt 工程到系统工程.md|来源: 晋小辰 - 约束优于指令]]

支柱三：自验证循环——生成与验收必须分离。Anthropic 的 GAN 风格架构：Planner（规划）→ Generator（实现）→ Evaluator（通过 Playwright MCP 真实验收）。三层递进验证：L1 结构体校验 → L2 API 数据断言 → L3 前端验证。“将做事的 Agent 和评判的 Agent 分开，是一个强有力的杠杆。” [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 自验证循环]]

支柱四：上下文隔离——防级联故障。三层隔离：进程级（子 Agent 完全独立上下文）、通信接口化（SendMessageTool 结构化消息）、控制面/数据面分离（协调者只有 3 个工具，不能自己写代码）。核心原则：中等复杂度以上任务，协调者绝不写代码。 [[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 上下文隔离]]

支柱五：熵治理——对抗系统自然腐烂。两种机制：Ralph Loop（把长任务拆成多轮短任务，每轮从文件系统恢复状态）解决深度；轨迹编译（同类任务执行 3 次以上且步骤高度一致时编译成确定性脚本）解决效率。AutoDream 系统借鉴认知科学的记忆巩固理论，自动在后台整理 Agent 的记忆。[[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 熵治理]]

支柱六：可拆卸性——别跟模型绑定死。依赖注入（替换模型只需替换一个字段）、Skills = Markdown（不绑定特定模型或 API）、MCP 标准协议（外部工具独立于内部实现）。[[raw/2026-05-08/Fox爱分享/同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就-胡言乱语-？秘密就在 Harness 里。.md|来源: Fox - 可拆卸性]]

四根支柱（新安实践版）

新安在真实企业级 Java 应用（10 万+行代码）中从零构建 Harness 体系，将支柱归纳为：上下文架构（L1/L2/L3 分层加载）、Agent 专业化（Planner/Generator/Evaluator 分离）、持久化记忆（进度持久化在文件系统上）、结构化执行（10 阶段 Pipeline，每阶段有明确的质量门禁）。项目维度 AI 代码率从 24.86% 跃升至 90.54%。 [[raw/2026-05-07/新安/Harness Engineering：耗时一周，我是如何将应用的AI Coding率提升至90%的.md|来源: 新安 - 90% AI 代码率]]

补充原则：提示词说服 vs 代码执行

邵猛提出了一个根本性认识框架：“告诉 Claude 应该怎么做”和”让某件事确定性地发生”是两件本质不同的事。 这是理解 CC 配置体系的关键认识框架。 [[raw/2026-06-19/邵猛/驾驭Claude Code：七种指令全解析.md|来源: 邵猛 - 哲学区分]]

提示词说服路径（CLAUDE.md / Rules / Skills）：依赖模型理解和遵从——模型可能忽略、忘记或被覆盖。走的是”说服”路线，将约束交给模型意志。
代码执行路径（Hooks / Permissions）：绕过上下文窗口，确定性执行——不受提示注入、上下文压缩、模型意志影响。走的是”执行”路线，用代码锁定行为。

两者的边界在哪里、何时从说服切换到执行，是 Harness 工程架构的核心判断。逐层递进：CLAUDE.md 声明意图（可能被忽略）→ Skill 定义方法（可能不被调用）→ Hook 强制兜底（无法绕过）。

12 组件解剖：Harness 作为操作系统

Beren Millidge 在 2023 年论文中给出了一个影响深远的精确类比：LLM = CPU，上下文窗口 = RAM，外部数据库 = 磁盘，工具 = 设备驱动，Harness = 操作系统。这本质上重新发明了冯·诺依曼架构——因为它是任何计算系统的自然抽象。 [[raw/2026-05-18/科技巫师的魔法书/Agent Harness 解剖：智能体框架的完整剖析.md|来源: 12 组件解剖]]

综合 Anthropic、OpenAI、LangChain 共识，生产级 Harness 包含 12 个独立组件：

#	组件	核心职责	关键细节
1	编排循环	TAO（思考-行动-观察）循环	Anthropic 称其为”笨循环”——智能在模型里，harness 只管理轮次
2	工具	智能体的双手	模式定义→参数验证→沙箱执行→结果捕获。Claude Code 提供六大类工具
3	记忆	跨时间尺度的信息持久化	短期（会话内历史）→ 长期（CLAUDE.md/MEMORY.md）→ 原始转录（仅搜索）
4	上下文管理	对抗”上下文腐烂”	关键内容在窗口中段时性能下降 30%+。策略：压缩/观察掩码/即时检索/子智能体委派
5	提示词构建	分层组装模型可见内容	系统提示→工具定义→记忆文件→对话历史→当前消息。OpenAI Codex 用严格优先级堆栈
6	输出解析	结构化提取模型响应	现代 harness 依赖原生 tool_calls 而非自由文本解析
7	状态管理	跨轮次/跨会话状态持久化	LangGraph 用类型化字典+检查点；Claude Code 用 git commit+进度文件
8	错误处理	防止错误累积	10 步每步 99%→端到端仅~90.4%。四种类型：瞬态/LLM可恢复/用户可修复/意外
9	护栏与安全	三级（输入/输出/工具）+ 绊线	Anthropic 从架构上分离权限执行与模型推理，约 40 项工具能力独立管控
10	验证循环	区分演示与生产的关键	Boris Cherny：给模型验证自己工作的方式，质量提升 2-3 倍
11	子智能体编排	多 Agent 协同执行	Fork/Teammate/Worktree 三种模型；OpenAI 用 agents-as-tools + handoffs
12	生命周期管理	终止条件与资源回收	分层终止：无工具调用/超轮次/token 耗尽/护栏触发/用户中断

完整循环：提示词组装 → LLM 推理 → 输出分类（文本/工具调用/交接）→ 工具执行（只读并发、修改串行）→ 结果打包 → 上下文更新（接近窗口限制时触发压缩）→ 循环。

对于跨上下文窗口的长任务，Anthropic 使用两阶段”Ralph Loop”：Initializer Agent 设置环境（初始化脚本、进度文件、功能列表、初始 commit）→ 后续 Coding Agent 读取 git log 和进度文件恢复状态、选择最高优先级未完成功能、执行、提交、写摘要。文件系统为跨上下文窗口提供连续性。 [[raw/2026-05-18/科技巫师的魔法书/Agent Harness 解剖：智能体框架的完整剖析.md|来源: 12 组件解剖]]

七个架构决策（每个 Harness 架构师必须面对）：单智能体 vs 多智能体 / ReAct vs Plan-Execute / 上下文窗口策略 / 验证循环设计 / 权限架构 / 工具范围策略 / Harness 厚度（最根本的选择——多少逻辑住 Harness，多少住模型）。 [[raw/2026-05-18/科技巫师的魔法书/Agent Harness 解剖：智能体框架的完整剖析.md|来源: 12 组件解剖]]

互补关系：现有”六大支柱”从工程实践角度归纳 Harness 应该做什么；12 组件从系统解剖角度描述 Harness 由什么构成。两套框架互相校验——六大支柱可映射到 12 组件的子集，而非替代关系。

五条可操作的 Harness 设计原则

晋小辰从 Claude Code 系列中提炼的五条原则，与多方实践高度一致： [[raw/2026-05-08/晋小辰/Harness Engineering：从 Prompt 工程到系统工程.md|来源: 晋小辰 - 五条原则]]

约束优于指令：CLAUDE.md 声明意图（可能被忽略）→ Skill 定义方法（可能不被调用）→ Hook 强制兜底（无法绕过）。三层叠加。
TDD 优先：先写测试（全红）→ 写实现（跑到绿）→ /simplify 重构。能验证比一次做对更重要。
确定性逻辑外置：Prompt 可能被遗忘，Hooks 和 permissions 是强制执行的。所有可程序化验证的约束才有效——“If it can’t be mechanically enforced, the agent will drift.”
文件系统作为外部记忆：进度放文件里，不放在上下文里。工作记忆→程序性记忆→情景记忆→语义记忆四层模型。
工具设计优先于提示词设计：观察模型行为而非猜测、定期复盘工具假设、给地图别给百科全书。

Agent 的四种典型失败模式

Anthropic 工程博客系统总结了 Agent 在复杂项目中的失败模式，Harness 就是为对抗它们而设计的： [[raw/2026-05-07/新安/Harness Engineering：耗时一周，我是如何将应用的AI Coding率提升至90%的.md|来源: 新安 - 四种失败模式]]

失败模式	表现	Harness 对策
One-shot Syndrome	试图一步到位，上下文过半后质量衰退	10 阶段 Pipeline，每阶段独立上下文
Premature Victory Declaration	完成部分工作就宣布结束	结构化质量门禁，机械化验证
Premature Feature Completion	认为功能已实现但未做端到端验证	Puppeteer MCP 自动化端到端截图验证
Cold Start Problem	每次新会话需花大量 Token 重新理解项目	持久化记忆 + 标准化启动序列

共同根源：Agent 无法准确评估自身产出的质量。 因此，外部化的约束和反馈不是可选的增强，而是 Agent 可靠运行的必要条件。 [[raw/2026-05-07/新安/Harness Engineering：耗时一周，我是如何将应用的AI Coding率提升至90%的.md|来源: 新安 - 核心洞察]]

上下文治理六动作（地基保留）

Claude Code 的六个上下文管理动作仍然是地基：/context、/resume、/rewind、/clear、/compact、subagents。用来控制缓存成本、错误回滚和主线程污染。 [[raw/2026-04-24/问答/Claude Code 上下文管理的 6 个动作，和它们背后的账本.md|来源: Claude Code 上下文管理的 6 个动作]]

CLAUDE.md 治理：从堆积到治理

CLAUDE.md 的写作从”堆积”转向”治理”是整个业界达成的共识——核心不是写多好，而是判断什么该删、什么该下沉为 skill、什么该上提到全局层。CLAUDE.md 是维护出来的不是写出来的。 [[raw/2026-06-19/吴师兄/面试官皱眉：Claude Code 你用了半年，CLAUDE.md 多少行了？.md|来源: 吴师兄 - CLAUDE.md 治理]]

注意力被稀释的隐蔽代价

吴师兄记录了一个亲身经历：一条”备份指令”写在 CLAUDE.md 第 1500 行时模型从不遵守，提到硬约束区后模型立刻遵守。这是注意力被稀释的实证——模型上下文窗口越长，边缘行的影响力越低。CLAUDE.md 不是越全越好，每一行都有常驻的 token 成本和注意力稀释成本。社区建议：项目级 CLAUDE.md 控制在 100 行出头，全局级几十行，不超过 200 行。 [[raw/2026-06-19/吴师兄/面试官：CLAUDE.md 多少行.md|来源: 吴师兄注意力稀释]]

三条件漏斗判断框架

一条指令该不该进 CLAUDE.md？同时满足三个条件：[[raw/2026-06-19/吴师兄/面试官：CLAUDE.md 多少行.md|来源: 吴师兄三条件漏斗]]

高频：每次开发都会用到（不是偶尔用一次）
稳定：不会频繁变动（变动的放对话里）
跨会话：每个会话都需要（不同 task 共用）

低频成套的做 Skill，临时的留在对话，大段文档用 @路径 引入。

三层维护体系

层级	位置	内容	行数建议
全局级	`~/.claude/CLAUDE.md`	个人偏好、全局约束、编码习惯	几十行
项目级	`./CLAUDE.md`	项目事实、约定、规则	~100 行出头
Skill 级	`skills/*/SKILL.md`	可复用操作流程	不限（按需加载）

放错层会导致个人偏好污染团队共享配置（个人偏好放进项目级 CLAUDE.md）或全局约束遗漏（全局级放得太少）。对 /init 自动生成的 CLAUDE.md 保持批判立场——拿到手第一件事是删除而非保留。[[raw/2026-06-19/吴师兄/三层维护体系.md|来源: 吴师兄三层体系]]

定期精简机制

建议每两三周精简一次。触发信号：

行数越界（超两三百行）
模型反复忽略某条指令
出现”临时”字眼（说明指令不该常驻）
同一件事写了多遍（应合并或下沉为 skill）

与 git worktree 配合实现上下文隔离

每个 worktree 各带各自的 CLAUDE.md，不同任务间不串味。并行开发和高风险探索时尤其适合——主分支保持稳定 CLAUDE.md，实验分支用独立的精简版或激进版。 [[raw/2026-06-19/吴师兄/CLAUDE.md 与 worktree.md|来源: 吴师兄 worktree 配合]]

矛盾：CLAUDE.md 写得越全越好，项目 /init 自动生成即可使用 vs CLAUDE.md 不是越全越好，每行都有常驻成本；/init 生成的初稿应大删特删来自 [[raw/2026-06-19/吴师兄/面试官：CLAUDE.md 多少行.md|来源: /init 批判]]

CC 定制化体系七种机制、Skill 工程两节已拆至 [[wiki/concepts/Harness 机制与配置工程]]

知识沉淀式 Harness 一节已拆至 [[wiki/concepts/Harness 工程案例索引]]

Task-Driven 到 Goal-Driven 与 Goal 模式一节已拆至 [[wiki/concepts/Harness 机制与配置工程]]

脚手架 > 模型

一个反常识但被多团队验证的发现：优先投资脚手架（Harness），而不是追最新最贵的模型。 投入回报对比：模型升级成本 +300%，效果 +20%；脚手架升级成本 +50%，效果 +200%。一个设计精良的系统让弱模型发挥惊人性能，烂系统完全浪费掉顶级模型的能力。[[raw/2026-05-07/腾讯程序员/十年老技术开发的 AI Agent 探索之路.md|来源: 腾讯程序员 - 脚手架 > 模型]]

自检清单：你的 Harness 够好吗

晋小辰提供的 11 项检查： [[raw/2026-05-08/晋小辰/Harness Engineering：从 Prompt 工程到系统工程.md|来源: 晋小辰 - 自检清单]]

☐ 有 CLAUDE.md 且不超过 200 行
☐ CLAUDE.md 里有 NEVER 列表
☐ settings.json 配了 allow/deny 权限规则
☐ 至少有 1 个自己写的 Skill
☐ MCP Server 按需接入，开了 ENABLE_TOOL_SEARCH=true
☐ 至少有 1 个 PostToolUse Hook
☐ 重要操作有验证闭环（测试、lint、typecheck）
☐ 高风险 Skill 设了 disable-model-invocation: true
☐ 知道 60%/80% 上下文的对应操作
☐ 做过至少一次跨会话交接

三家 Harness 架构对比、Cursor 动态上下文、架构设计新认知三节已拆至 [[wiki/concepts/Harness 架构演进与前沿]]

新的数据锚点（2026-05）一节已拆至 [[wiki/concepts/Harness 工程案例索引]]

多智能体协作的新框架一节已拆至 [[wiki/concepts/Harness 架构演进与前沿]]

企业级基础设施进展、爱奇艺三层实践、QQ 音乐、五类问题解法、代码负债四左移、Java 微服务改造六节已拆至 [[wiki/concepts/Harness 工程案例索引]]

生产级 Harness 关键机制补遗一节已拆至 [[wiki/concepts/Harness 机制与配置工程]]

Karpathy、ETCLOVG 七层框架、判断工程不可能三角、State-Aware Runtime 四节已拆至 [[wiki/concepts/Harness 架构演进与前沿]]

企业级 Harness 新案例群一节已拆至 [[wiki/concepts/Harness 工程案例索引]]

王鹏程范式革命、AI Friendly 架构三范式两节已拆至 [[wiki/concepts/Harness 架构演进与前沿]]

iii Harness 15 项职责一节已拆至 [[wiki/concepts/Harness 机制与配置工程]]

叶小钗三层次模型、风夏 WebTerminal 分层实践两节已拆至 [[wiki/concepts/Harness 工程案例索引]]

ETCLOVG 七层分类法一节已拆至 [[wiki/concepts/Harness 架构演进与前沿]]

上下文压缩横向对比、Hooks 机制、ContextBucket 三节已拆至 [[wiki/concepts/Harness 机制与配置工程]]

franslee 双向改造实践一节已拆至 [[wiki/concepts/Harness 工程案例索引]]

居丽叶能力模型、兔兔AGI 系统综述两节已拆至 [[wiki/concepts/Harness 架构演进与前沿]]

腾讯 Harness Eval、澄沨淘宝主播 Agent、爱奇艺质量门禁左移三节已拆至 [[wiki/concepts/Harness 工程案例索引]]

Token 经济学（KV Cache）一节已拆至 [[wiki/concepts/Harness 机制与配置工程]]

核心矛盾梳理

矛盾详细记录见 [[wiki/syntheses/矛盾与视角差异]]

本批资料揭示的关键张力（含 2026-06 增补）：

单 Agent vs 多 Agent：Anthropic 建议先充分挖掘单 Agent 潜力；来新璐认为下一步必然是 “Agent 蜂群”；王云鹤更激进——从数学上论证了多模型优于单模型
厚 Harness vs 薄 Harness 的层次分化：王云鹤”厚 Harness + 多模型组合优化”（Harness 应主动选择和控制模型）vs Anthropic”薄 Harness + 模型自己变强”（编排逻辑持续做减法）。更深层的问题是：编排逻辑确实在变薄，但安全边界、状态管理、可观测性等工程治理层反而在变厚——“薄”和”厚”不是同一维度，不能简单对立
“AI 灵魂”归属：如果 Harness 控制模型选择，甚至用 Harness 数据反哺模型训练，AI 的灵魂在 Base Model 还是 Harness？这是 Agent 时代最根本的哲学问题 [[raw/2026-05-18/机器之心/王云鹤眼中的Harness：复杂优化问题，AGI灵魂争夺之战.md|来源: 王云鹤]]
单智能体 vs 三智能体：OpenAI 单智能体深度自治 vs Anthropic Planner-Generator-Evaluator 分离。场景决定选择——无人编码极限 vs 长时自主极限 vs 高频交互极限
评估时机：持续审查（OpenAI）vs Sprint/最终单次（Anthropic）vs 用户行为间接评估（Cursor）——三种策略背后的假设完全不同
Bash vs MCP：训练语料覆盖度 vs 标准化生态扩展
Prompt Flow vs Agent Native：代码确定性管理 vs 模型自主编排
模型收敛 vs 多样性：Anthropic 赌模型会收敛到最强基座（Harness 只是过渡工具）；王云鹤赌模型会长期保持多样性（Harness 是永久的基础设施层）。这个赌注决定了对 Harness 的长期投资判断
Token 效率现在该讨论吗？ 研究视角（还太早）vs 生产运维视角（生命线）
0 人公司：来新璐暴论——未来公司终极形态是完全由 Agent 自运转的零人公司
Loop Engineering 是真范式跃迁还是新瓶装旧酒：梦朝思夕主张第四次跃迁 vs Guide 主张循环不新，新鲜的是名字 [[raw/2026-06-19/梦朝思夕/万字长文 - Loop Engineering.md|来源: 梦朝思夕]] [[raw/2026-06-17/Guide/面试官：-loop 和 -goal 区别.md|来源: Guide]]
CLAUDE.md 全量 vs 治理：写得越全越好，/init 自动生成即可 vs 每行都有常驻成本，/init 初稿应大删特删 [[raw/2026-06-19/吴师兄/面试官：CLAUDE.md 多少行.md|来源: 吴师兄]]
提示词说服 vs 代码执行：CLAUDE.md/Rules/Skills 走”说服”路径 vs Hooks/Permissions 走”执行”路径——“告诉 AI 怎么做”和”让事情自动发生”是两件不同的事 [[raw/2026-06-19/邵猛/驾驭Claude Code：七种指令全解析.md|来源: 邵猛]]
Skills 设计哲学之争：Matt Pocock 主张用户手动触发、AI 保持最小自主性 vs 尼恩主张工业级四层召回+Harness 统一管控注入，追求自进化闭环减少人工干预 [[raw/2026-06-19/尼恩/工业级 Skills 进化体系.md|来源: 尼恩]]
Goal 三要素 vs 四要素：具体的 outcome + 可衡量标准 + 边界条件 vs 增加了停止条件作为独立维度 [[raw/2026-06-19/陈蛋黄/Codex Goal 模式生存指南.md|来源: 陈蛋黄]]
Agent runtime 作为编排层 vs AgentTeams 分离编排与运行时：承吉的 CRD 编排平面独立于运行时，K8s 类比——Agent orchestration 和 runtime 应为分离的两层 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟.md|来源: 承吉]]

2026-07 协议、权限与可观测性 Harness 更新已拆至 [[wiki/concepts/Harness 架构演进与前沿]]

拆分子页

[[wiki/concepts/Harness 工程案例索引]] — 企业/团队实践案例与数据锚点
[[wiki/concepts/Harness 架构演进与前沿]] — 架构哲学之争、厂商对比、学术综述与 2026-07 前沿
[[wiki/concepts/Harness 机制与配置工程]] — CC 定制化、Skill/Goal/Hooks、上下文压缩、Token 经济学
[[wiki/concepts/Loop Engineering]] — Loop Engineering 全部段落已并入该页