【AI城】同样的AI模型，为什么有人能写出100%可用的代码？

Uncle 城

372人浏览 · 2026-04-04 18:03:34

Uncle 城 · 2026-04-04 18:03:34 发布

大模型不是关键，Harness 才是

课前预习：三个核心概念（30秒）

在开始之前，先快速扫一眼今天会遇到的三个关键词：

概念	一句话理解
Harness	给 AI Agent 套上的"操作系统"
Context Engineering	管理信息输入，决定什么该留、该压、该丢
Feedback Loop	Agent 写完代码后自己验证，自己 review

一、破除误区：差距不在模型（1:30-4:00）

先问一个问题。大家觉得，大部分时候 AI 行业最热的话题是什么？

OpenAI 发布 GPT-4 了。Anthropic 发布 Claude 3 了。Meta 开源 Llama 3 了。Google 发布 Gemini 了……

每次发布，媒体标题都是"最强模型诞生"、“超越 GPT-4”、“革命性突破”。

然后呢？然后大家就开始等下一个"革命性突破"。

但你有没有注意到一个现象——f

同等能力的模型越来越多，但不同产品之间的体验差距并没有缩小，反而在拉大。

比如编程场景，有的产品写出来的代码 bug 一堆，有的产品写出来的代码可以直接提交。

为什么？

因为模型是一样的。差距不在模型，在于怎么用模型。

这个"怎么用模型"，在 AI 行业里有一个专门的概念，叫做 Harness。

但"怎么用模型"这个说法，其实还不够准确。

更准确的说法是——怎么让模型稳定、可靠、不失控地工作。

这就是我们今天要讲的 Harness Engineering，驾驭工程。

⏱️ 小结：记住一个核心观点——模型是 CPU，Harness 是操作系统。 算力再强，没有操作系统也跑不起来。

二、什么是 Harness Engineering？（11:00-14:00）

好，现在可以给 Harness 下一个正式的定义了。

Harness Engineering，驾驭工程，是围绕 AI 智能体设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。

有人给了一个很精准的类比 [2]：

模型是 CPU，算力再强，没有操作系统也跑不起来。

而 Harness，就是 AI Agent 的操作系统。

操作系统做什么？管理内存、处理启动流程、提供标准驱动。

Harness 做什么？上下文管理、架构约束、反馈循环、工具链、生命周期管理。

arxiv 上有一篇论文叫《Building Effective AI Coding Agents for the Terminal》[5]，把 Agent 的运行架构分成了三层：

层次	功能	比喻
Scaffolding 脚手架	预执行组装，系统 prompt 编译	操作系统 BIOS
Harness 运行时编排	推理循环包装，工具协调	操作系统内核
Context Engineering	Token 预算管理	操作系统内存管理

用一个公式来表示：

coding agent = AI model(s) + harness

⏱️ 过渡：好，定义讲完了。接下来我们从历史角度看看，为什么 Harness 这个概念现在才火起来。

三、Harness 的演进史：为什么是现在？（8:00-11:00）

你可能会问，既然 Harness 这么重要，为什么最近才火起来？

要回答这个问题，得先搞清楚 AI 工程范式的三次演进。

第一阶段：Prompt Engineering，2022-2024

这个阶段核心关注的是：怎么写好一条指令。

大家研究的是 few-shot、chain-of-thought、角色设定。这个时候大家都是在打磨"一次性的输入"。

AI猫娘大家都还记得吧，抛开玩梗性质，就算是帮忙写代码也只是给出一串所谓的"你现在是一个程序员巴拉巴拉"这样的单条提示词

第二阶段：Context Engineering，2025

这个时候开始单条 prompt 不够用了。

你开始需要为模型动态构建整个上下文环境——相关文件、历史对话、工具定义、知识库检索结果，让模型在做每一个决策时，都能看到它需要的信息。

第三阶段：Harness Engineering，2026 年初

这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月首次提出。 [4]

他的定义只有一句话：

“每当你发现 Agent 犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错。”

这句话看起来平平无奇，但它击中了一个很多人隐隐感觉到却没有说清楚的痛点：

模型能力够了，可它就是不听话。

六天后，OpenAI 在百万行代码实验报告中正式采用这个术语。随后一个月，这个概念火遍了整个 AI 工程圈。

四、从三个故事说起（4:00-8:00）

在开始之前，先讲三个真实发生的故事。

故事一：LangChain 的实验 [1]

LangChain 是一个做 AI 开发框架的公司，他们今年做了一个实验。

他们用同一个模型——GPT-5.2-Codex，模型参数一个都没动——只改变了外部的工程环境，在 Terminal Bench 2.0 编程基准测试上，成绩从 52.8% 提升到 66.5%。

提升了 13.7 个百分点。

排名呢？从第 30 名开外，直接冲进了前 5。

只改 Harness，不换模型。

故事二：Nate B Jones 的研究 [2]

研究员 Nate B Jones 做了另一个实验，结论更极端：

同一个模型，同一个提示词，只改变运行环境，编程基准测试的成功率从 42% 跳到了 78%。

差了将近一倍。

变量只有 Harness。

换句话说：Harness 带来的提升，相当于换了一代模型。

故事三：OpenAI 的百万行代码实验 [3]

OpenAI 的 Codex 团队做了可能是最有说服力的一个证明：

从一个空的 Git 仓库开始，5 个月，大约 100 万行代码、1500 个 PR，全部由 AI Agent 生成。

人类工程师一行代码都没写。

团队一开始只有 3 个工程师，后来扩到 7 个。平均下来，每位工程师每天合并 3.5 个 PR。他们估算，如果用传统方式手写，这个项目的工期应该是现在的 10 倍。

Codex 团队的核心工程师 Ryan Lopopolo 说过一句很直接的话：

“Agent 不难，Harness 才难。”

三个故事，同一个结论：

模型不是瓶颈，Harness 才是。

⏱️ 过渡：好，记住这三个数字——52.8%、42%、100万行。理论讲完了，接下来看实战。

五、Claude Code 源码深度解析（14:00-18:00）

⚠️ 声明：这期是深度解析版，如果你只想知道 Harness 怎么用，可以跳到第六部分。

好，现在你已经知道 Harness 的基本概念了。

接下来我们透过 Claude Code 的源码泄露 [12]，来看看一个顶级 Harness 到底长什么样。

Claude Code 的源码被泄露之后 [12]，科技圈最震惊的不是它用了什么模型，而是它的工程复杂度。

整体架构

Claude Code 整体用 TypeScript + Node.js 开发，终端 UI 使用的是 React + Ink。

它的核心目录结构是这样的：

entrypoints/：启动初始化
query/：Agent 循环引擎
tools/：45+ 工具实现
commands/：100+ 命令
services/：业务逻辑（API、MCP、分析等）
utils/swarm/：多 Agent 协作核心
skills/：技能系统
buddy/：电子宠物彩蛋

一个编程工具，光是命令就有 100 多个，这本身就说明了它的 Harness 设计有多精细。

启动流程：六阶段

Claude Code 的启动流程被设计成了六个阶段：

阶段	职责	关键点
Stage 1	并行预读取 MDM 配置与 Keychain	~65ms
Stage 2	配置验证	有问题直接弹窗终止
Stage 3	安全环境变量注入	只加载必要信息
Stage 4	用户信任确认	安全边界，Agent 才知道自己能做什么
Stage 5	完整初始化	OAuth、Git、LSP、遥测全部加载
Stage 6	延迟加载	用户上下文按需获取

工程细节：它使用了动态 require()，节省了 400-700KB 的初始加载量。代码层面的一点优化，用户感知到的就是快。

Agent 循环引擎：流式执行

核心流程：准备上下文 → 流式调用 Claude API → 工具边流边执行 → 根据 stop reason 决定是否继续循环

stop reason 是一个关键概念。Claude Code 会根据不同的 stop reason 决定下一步是继续循环，还是结束任务。

两个安全阀：maxTurns（最大循环轮次）和 maxBudgetUsd（预算上限）。

四层权限管道

Claude Code 的权限系统不是简单的"允许/禁止"开关，而是一套四层决策管道：

规则匹配（毫秒级）
    ↓
Bash 分类器（22+ 危险操作模式）
    ↓
Transcript 分类器（基于对话上下文）
    ↓
独立 Sonnet API（温度=0，最终决策）

四层加起来，既保证了速度，又保证了安全。这就是为什么 Claude Code 很少出现"AI 擅自删文件"这类事故。

上下文管理：95% 自动压缩

token 使用量达到 95% 时，自动压缩早期消息。支持嵌套压缩。

默认上下文窗口 200K tokens，Opus/Sonnet 4.6 最高支持 1M tokens。输出 token 默认 8K，可扩展到 64K。

渐进式工具披露

Claude Code 有 45+ 内置工具，还有大量 MCP 工具。如果一次性全部告诉模型，会占用超过 10% 的上下文。

解决方案是渐进式披露：

内置工具：部分延迟加载
MCP 工具：全部延迟加载
Skill 工具：只加载 frontmatter（name、description、when_to_use、arguments、paths、hooks）

模型通过 ToolSearch 按需查询工具 schema，而不是一次性全部加载。

⏱️ 过渡：好，Claude Code 的冰山一角就看到这里。现在进入最实用的部分——Harness 到底怎么设计。

六、Agent 的四种典型失败模式（18:00-20:00）

讲 Harness 怎么设计之前，先说一个前置问题：Agent 为什么会失败？

Anthropic 的工程师总结了三种典型的失败模式 [6]：

失败模式一：试图一步到位（One-shotting）

Agent 倾向于在一个会话里把所有功能都做完。结果是上下文窗口耗尽，留下一堆没有文档的半成品代码。

下一个会话启动时，Agent 只能花大量时间猜测之前发生了什么。

失败模式二：过早宣布胜利

在项目后期，当部分功能完成后，Agent 会环顾四周，看到已有进展就直接宣布任务完成——即使还有大量功能未实现。

失败模式三：过早标记功能完成

Agent 写完代码就标记为"完成"，却没有做端到端测试。单元测试通过了，不代表功能真正可用。

还有一个危险特性：Agent 非常擅长模式复制。

代码库里有什么模式，它就忠实地复制并放大——包括坏模式和架构漂移。

这意味着不加约束的 Agent，会以惊人的速度积累技术债务。

⏱️ 关键认知：这四种失败模式，就是 Harness 要解决的核心问题。

七、Harness 的四大护栏（20:00-25:00）

综合 OpenAI、Anthropic、LangChain 的实践，Harness 可以归纳为四个核心组件。

护栏一：上下文工程（Context Engineering）

本质上是给 Agent 的一份"入职手册"。

最常见的形式是项目根目录的 AGENTS.md 或 CLAUDE.md 文件。

关键工程点：文件不能太长。

ETH Zurich 的研究发现 [7]，AGENTS.md 文件应该控制在 60 行以内。过长的指令文件反而会降低 Agent 的表现。

为什么？因为上下文是稀缺资源。过多的指导会挤掉任务、代码和相关文档的空间。

正确的做法是：提供一个稳定、小巧的入口点，然后"教"Agent 根据当前任务按需检索和拉取更多的上下文。

Mitchell Hashimoto 的 Ghostty 项目里，AGENTS.md 每一行都对应一个历史 Agent 失败案例——文档是活的反馈循环，不是静态制品。

护栏二：架构约束（Architecture Constraints）

这是 Harness 最核心的一环。

OpenAI 团队建立了严格的分层架构规则：

Types → Config → Repo → Service → Runtime → UI

每一层只能依赖下面的层，不能反向依赖。

关键在于：这些规则不是靠 prompt 告诉 Agent"请遵守"，而是用确定性的 linter 和结构化测试来机械执行。

Agent 违反了架构规则？CI 直接挂掉，没得商量。

而且 linter 的报错信息里，还嵌入了修复指引，告诉 Agent 应该怎么改。

Cursor 团队在"Self-Driving Codebases"研究 [8] 中发现了类似结论：

“约束比指令更有效。”

这背后有一个反直觉的洞察：约束解空间反而让 Agent 更有生产力。

护栏三：反馈循环（Feedback Loop）

传统开发中，人类工程师负责代码审查。在 Harness 里，这个工作变成了Agent 对 Agent的方式。

LangChain 总结出一个叫 PreCompletionChecklistMiddleware [1] 的机制——它会在 Agent 退出之前拦截它，提醒它对照任务规格做一次验证。

具体流程：

规划与发现：读取任务规格，扫描代码库，制定计划
构建：按计划实现，同时构建测试用例
验证：运行测试，对照任务要求而非自己的代码进行检查
修复：分析错误，回顾原始规格，修复问题

LangChain 把这叫做Build & Self-Verify。

护栏四：熵管理（Entropy Management）

随着时间推移，AI 生成的代码会积累大量问题：文档过时、架构漂移、风格走样。

OpenAI 团队管这个叫"垃圾回收"。

他们的做法是：定期启动专门的 Agent，去扫描文档不一致、架构违规等问题，提交修复 PR。这些 PR 大多能在一分钟内审查并合并。

另一个做法是Doc-gardening Agent——自动扫描文档与代码之间的不一致，发现过时内容就自动提交 PR 修复。

Agent 为 Agent 维护文档。

⏱️ 过渡：四大护栏讲完了。接下来是五个可以直接落地的实战技巧。

八、LangChain 的五个实战技巧（25:00-28:00）

好，现在你已经知道 Harness 的四大护栏了。

再来看 LangChain 在实际优化过程中的五个具体操作技巧：

技巧一：Trace 分析，把失败变成改进素材 [1]

LangChain 把 Trace 分析做成了一个Agent Skill [1]——每次实验跑完，系统自动抓取 traces，并行启动多个错误分析 Agent，主 Agent 汇总发现和建议，然后针对性地修改 Harness。

这跟机器学习里的 boosting 逻辑类似：专注于之前轮次的错误。

技巧二：给 Agent 提供环境上下文 [1]

LangChain 有一个 LocalContextMiddleware [1]，在 Agent 启动时自动：

映射当前工作目录和父子目录结构
查找 Python 等工具的安装路径
把这些信息注入给 Agent

为什么要这么做？因为 Agent 在陌生环境里，很容易犯"上下文发现"相关的错误——它不知道目录下有什么，不知道有哪些工具可用。

技巧三：检测并破解 Doom Loop

Doom Loop 是什么？

Agent 一旦决定了某个方案，就会不断重复这个方案的小修小补，哪怕方向是错的，也会执着地继续。

LangChain 的 LoopDetectionMiddleware [1] 通过工具调用的钩子追踪每个文件的编辑次数。一旦某个文件的编辑次数超过阈值，就给 Agent 的上下文里追加一条提醒：“考虑重新审视你的方案。”

技巧四：推理预算的"三明治"策略

LangChain 发现，gpt-5.2-codex 有四种推理模式：低、中、高、极高。

全称用极高推理模式，得分反而只有 53.9%，因为消耗了太多 token 导致超时。

测试发现，**高-高-高的"推理三明治"**效果最好：规划阶段用高推理，执行阶段用高推理，验证阶段再用高推理。

方向：自适应推理才是未来。

技巧五：工具不是越多越好 [2]

Vercel 做过一个实验 [2]：把 Agent 的工具从 15 个砍到只剩 2 个，准确率反而从 80% 升到了 100%。

这听起来反直觉，但道理很简单。

给一个实习生 15 把不同的螺丝刀让他修电脑，他可能会手忙脚乱。给他一把十字和一把一字，他反而知道该怎么干了。

Stripe 有 500 个工具 [9]，但每个 Agent 只能看到精心筛选过的子集。

⏱️ 过渡：好，五大技巧讲完了。现在进入最容易被问到的问题——Harness 和模型，到底谁更重要？

九、行业路线之争：Big Model 还是 Big Harness？（28:00-31:00）

好，讲到这里，你可能会问：Harness 真的比模型重要吗？模型厂商不断提升模型能力，Harness 的价值会不会最终被稀释？

这个问题，整个行业也在争论。

Big Model 阵营认为：模型能力的增长才是主旋律，Harness 只是权宜之计。

OpenAI 的 Noam Brown 说过 [10]：

“Harness 就像一根拐杖，我们终将能够超越它。”

他的论据：推理模型出现之前，开发者们在 GPT-4o 上搭建了大量复杂的 Agentic 系统来模拟推理能力。然后推理模型一出来，很多基础设施一夜之间就不需要了。

他的建议是：

“别花六个月搭建一个可能六个月后就被淘汰的东西。”

Big Harness 阵营认为：模型是引擎，Harness 是方向盘和刹车。引擎再强，没有方向盘你也到不了目的地。

LlamaIndex 创始人 Jerry Liu 的话说 [2]：

“Model Harness 就是一切。”

我的看法：两边都对了一半，但应用场景不同。

场景	建议
基础模型选型	先看 Big Model 阵营的观点
应用落地开发	先看 Big Harness 阵营的观点

Harness 确实在不断演进和简化。Manus 6 个月内重构了 5 次 Harness [2]。LangChain 一年内重新架构了 3 次研究型 Agent。

模型变强了，Harness 就该变薄。

但"变薄"和"消失"是两回事。

打个比方：车速越快，护栏越重要。

时速 30 公里的自行车道，可以没有护栏
时速 120 公里的高速公路，护栏是标配
时速 300 公里的磁悬浮列车，整个轨道都是封闭的

模型能力在提升，Harness 也在进化。但架构约束、反馈循环、熵管理这些东西，本质上不会消失，只会换一种形态。

Noam Brown 说 Harness 是拐杖，这话对——但拐杖会消失，方向盘和刹车不会。

⏱️ 过渡：路线之争就到这里。接下来介绍一个最新研究，它可能会彻底改变我们设计 Harness 的方式。

十、斯坦福研究：Meta-Harness（31:00-34:00）

斯坦福大学最近提出了一个概念，叫 Meta-Harness [11]。

核心思路：用 AI 来自动设计并优化 Harness [11]，替代人工调参的过程。

这个研究团队包括 Yoonho Lee（斯坦福博士生）和 Omar Khattab（DSPy 作者）。

三阶段循环搜索

Meta-Harness 的工作原理是一个三阶段循环：

翻档案 —— Coding Agent 读取历史 Harness 代码、评估分数与执行记录
跑评估 —— 对新设计的 Harness 进行任务测试，记录性能与运行轨迹
存档 —— 将代码、分数、推理过程等写入文件系统，供后续迭代参考

关键设计：赋予 Agent 完整的文件系统访问权限（而非压缩摘要），以捕捉长程因果依赖。

数据说话

斯坦福在一系列基准上测试了 Meta-Harness [11]：

文本分类 [11]：准确率提升 7.7%，上下文使用量仅为后者的 1/4
数学推理（IMO 级别） [11]：5 个未知模型上平均提升 4.7%
TerminalBench-2 [11]：Haiku 4.5 达到第一，超越所有用大模型的方案

注意这里的关键细节：用 Haiku 4.5 这样的小模型，超过了所有用大模型的方案。

搜索效率：仅需 4 次评估即达到同类方法的最终性能，最终领先 10% 以上。

历史信息的价值

赋予 Agent 完整访问历史文件（而非摘要），中位数准确率从约 34% 提升至 50%。

这个数字说明：Harness 的优化空间，可能比我们想象的还要大。

斯坦福的结论是：Harness 设计可以被自动化，且效果显著优于人工调优。

这也揭示了一个更大的趋势：Harness 正在从"艺术"变成"工程"。

十一、结尾：工程师角色的转变（34:00-36:00）

最后聊一个趋势。

OpenAI 团队在总结他们的工作时，说了这么一句话：

“我们现在最大的挑战，在于设计环境、反馈循环和控制系统。”

换句话说：他们不写代码了，写的是规则。

Stripe 的工程师也不写代码了，他们设计的是 Blueprint——确定性节点和 Agentic 节点的混合编排。

这说明一个根本性的变化正在发生：

工程师的价值，正在从"写代码的人"变成"设计让 Agent 可靠工作的系统的人"。

Harness Engineering 的核心，不是某一家公司的实验，而是整个行业正在经历的范式转移。

它的本质，和管理一个团队没有区别：

给新人写 onboarding 文档（AGENTS.md）
定代码规范和架构原则（linter 和结构测试）
做 code review 确保质量（CI/CD 检查）
定期做技术债清理（垃圾回收）
给工具做精简和选型（工具链管理）
遇到反复出现的问题就写进 wiki（反馈循环）

AI Agent 越强，就越像一个能力很强但需要管理的员工。

你不会把一个刚入职的天才工程师扔进一个没有文档、没有规范、没有 CI 的项目里，然后指望他写出完美的代码。

同样的道理，你也不该把一个强大的 AI 模型扔进一个没有 Harness 的环境里，然后抱怨它不好用。

下次看到两个 AI 编程工具，别只看模型参数。

问这三个问题就够了：

问题	看什么
出错时怎么自动恢复？	反馈循环是否完整
上下文满了怎么压缩？	熵管理是否到位
代码质量谁来把关？	架构约束是否有效

这才是真正看懂一个 AI 产品的方式。

好了，这就是今天的全部内容。

如果你觉得这期视频有收获，欢迎一键三连。

我是【AI城】，关注我，下期我们深挖 Harness 具体组件的实际工程实现。

我们下期见。

附录一：核心数据一览

数据来源	实验条件	结果	引用
LangChain [1]	同模型，只改 Harness	52.8% → 66.5%，Top 30 → Top 5	[1]
Nate B Jones [2]	同模型同提示词，只改运行环境	42% → 78%	[2]
Pi Research [2]	同一天下午，只改 Harness	15 个不同 LLM 编程能力全部提升	[2]
Vercel [2]	工具从 15 个砍到 2 个	准确率 80% → 100%	[2]
斯坦福 [11]	Meta-Harness，Haiku 4.5	TerminalBench-2 第一	[11]

附录二：Harness Engineering 演进时间线

阶段	时间	核心关注
Prompt Engineering	2022-2024	精心构造单次指令
Context Engineering	2025	为每个决策点动态构建上下文
Harness Engineering	2026 年 2 月起	设计完整的控制系统

附录三：知识点速查表

术语	简单定义
驾驭工程（Harness Engineering）	围绕 Agent 设计约束、反馈、控制的系统工程
上下文工程（Context Engineering）	管理信息输入，决定什么该留/压/丢
架构约束（Architecture Constraints）	用 linter 和 CI 强制执行的架构规则
反馈循环（Feedback Loop）	Agent 写完代码后自己验证
熵管理（Entropy Management）	定期清理过时代码，防止技术债积累
Doom Loop	Agent 重复错误方案而不自知
Meta-Harness	用 AI 自动设计优化 Harness（斯坦福研究）
流式执行（Streaming Execution）	工具边执行边流式输出，而非等全部完成
四层权限管道（4-Layer Permission Pipeline）	规则匹配→Bash分类→Transcript分类→独立API决策
渐进式工具披露（Progressive Tool Disclosure）	工具按需加载，避免一次性占10%+上下文
Hook 系统（Hook System）	事件驱动的扩展机制，支持热重载
stop reason	模型停止生成的原因，决定是否继续循环

附录四：视觉素材参考

段落	建议画面
开场	Claude Code 源码截图 + 代码快速滚动
LangChain 数据	Terminal Bench 排行榜，52.8% → 66.5% 数字跳动
Claude Code 架构	目录结构图：entrypoints/ query/ tools/ commands/ services/ swarm/ skills/
启动六阶段	流程图：Stage 1-6 的时间线和职责说明
四层权限管道	决策流程图：规则匹配 → Bash分类 → Transcript分类 → Sonnet API
上下文压缩	进度条图示：95%触发压缩，嵌套压缩机制
渐进式工具披露	工具分类图：内置/MCP/Skill + ToolSearch 按需加载示意
斯坦福 Meta-Harness	三阶段循环图：翻档案 → 跑评估 → 存档
TerminalBench 排名	排行榜截图：Haiku 4.5 第一名突出显示
路线之争	左右对比：Big Model vs Big Harness 双方论点
结尾	全屏大字：“工程师不写代码了，写的是规则”

附录五：引用文献

[1] LangChain Blog. “Improving Deep Agents with Harness Engineering”. Feb 17, 2026.
https://blog.langchain.com/improving-deep-agents-with-harness-engineering/

[2] AGIHunt. “模型不是关键，Harness 才是”. 腾讯新闻, 2026-03-22.
https://news.qq.com/rain/a/20260322A02XZ900

[3] OpenAI Codex Team. “Coding Agent 百万行代码实验报告”. 2026年2月.
https://openai.com/index/harness-engineering/

[4] Mitchell Hashimoto. “Harness Engineering”. HashiCorp Blog, 2026年2月5日.

[5] arxiv. “Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned”. arXiv:2603.05344.

[6] Anthropic Engineers. “Agent 常见失败模式研究”. Anthropic Technical Reports.

[7] ETH Zurich. “AGENTS.md 文件长度与 Agent 表现关系研究”. 2026.

[8] Cursor Team. “Self-Driving Codebases”. Cursor Research, 2026.

[9] Stripe Engineering. “Minions: 规模化 Agent 编程实践”. Stripe Blog, 2026.

[10] Noam Brown (OpenAI). “Is Harness Engineering Real?”. Latent Space Podcast, 2026年3月.

[11] Yoonho Lee & Omar Khattab (Stanford). “Meta-Harness: Automated Harness Design for Coding Agents”. Stanford University, 2026.
https://yoonholee.com/meta-harness/

[12] AGIHunt. “Claude Code 源码深度解析”. 微信公众号, 2026.