大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
     
同一个模型，换一套运行环境，编程基准的成功率就从 42% 跳到了 78%。
 

这个数据来自 Nate B Jones 的一项研究，只有一个变量：模型外面包裹的那层「壳」。模型没换，数据没换，提示词也没换，只是改了壳，性能翻了将近一倍。

这层壳，现在有了一个正式的名字：Harness。

而围绕它展开的工程实践，叫 Harness Engineering，是 2026 年 AI 工程圈最热的话题之一。

Harness 概念示意

要理解 Harness Engineering，得先看它是怎么一步步「长」出来的。

2022 到 2024 年，圈子里最火的词是 Prompt Engineering。

这时的核心关注点是，怎么写好一条指令，让模型给出期望的输出。那时候大家研究的是 few-shot、chain-of-thought、角色扮演，本质上都是在打磨「一次性的输入」。

2025 年，风向变了。Andrej Karpathy 和 Shopify CEO Tobi Lütke 几乎同时开始推一个新概念：Context Engineering。

其核心思路是，单条 prompt 不够用了，你得为模型动态构建整个上下文环境，包括相关文件、历史对话、工具定义、知识库检索结果……让模型在做每一个决策时，都能看到它需要看到的信息。

一层套一层

然后到了 2026 年 2 月，Harness Engineering 来了。

它和前两个词的关系，打个比方：Prompt Engineering 是教你怎么写一封好邮件；Context Engineering 是教你怎么把相关附件都带上；而 Harness Engineering，是教你怎么搭建整个办公室，让员工（Agent）能持续、稳定、高质量地工作。

它包含了 Context Engineering，但在更高的层面运作：

约束、反馈循环、架构规则、工具链、生命周期管理，以及对抗熵增的持续治理。

故事得从 Mitchell Hashimoto 说起。

这位 HashiCorp 的联合创始人、Terraform 的缔造者，今年 2 月 5 日写了篇博客，记录自己用 AI 编程的「进化史」。他把采纳之旅分成了六个阶段，从最初用 chatbot 聊天写代码，到后来全天候跑 Agent。

第一阶段叫「Drop the Chatbot」，别用聊天界面了。第二阶段叫「Reproduce Your Own Work」，强迫自己用 Agent 重新做一遍手动完成的工作，哪怕做两遍也要做。第三阶段开始利用下班时间跑 Agent，第二天早上来收获「warm start」。第四阶段，把简单任务交给后台 Agent，自己专注深度工作。

而第五个阶段，他给了一个名字：Engineer the Harness。

他的定义只有一句话：

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

这句话看起来平平无奇，但它击中了一个很多人隐隐感觉到、却没有说清楚的痛点：模型能力够了，可它就是不听话。

他在 Ghostty 项目中实践了这个理念。AGENTS.md 文件里的每一行规则，背后都对应着 Agent 曾经犯过的一个错。他说：

那个文件里的每一行都基于一次 Agent 的不良行为，而且几乎完全解决了这些问题。

几天之后，OpenAI 发了一篇重磅博文。再几天，Martin Fowler 团队的 Birgitta Böckeler 跟进分析。

这个词，在几周内就火遍了整个 AI 工程圈。

OpenAI 的 Codex 团队做了一件事，让整个行业重新思考「工程师」这个词的含义。

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

人类一行代码都没写。

团队一开始只有 3 个工程师，后来扩到 7 个。他们用 GPT-5 驱动的 Codex CLI，从零开始构建了一个完整的生产级应用。平均下来，每位工程师每天合并 3.5 个 PR。

Codex 驱动应用开发

他们估算，如果用传统方式手写，这个项目的工期应该是现在的 10 倍。

而这里面最让人意外的一点是：这 100 万行代码里，不只是业务逻辑。测试、CI 配置、文档、可观测性、内部开发者工具，全都是 Agent 写的。

Ryan Lopopolo，这个项目的核心工程师，写下的一句话是：

Agent 不难，Harness 才难。

这句话，可以说是本次实践的重点。

因为 OpenAI 这篇博文真正的价值，在于他们把 5 个月的实战经验提炼成了一套可复制的方法论。

仓库就是大脑

他们的第一个核心理念是：仓库是 Agent 唯一的知识来源。

代码、markdown、schema、可执行计划，全都版本化地存在仓库里。没有外部 wiki，没有 Notion 文档，没有「口口相传」的潜规则。Agent 看不到仓库之外的东西，所以仓库必须包含 Agent 工作所需的一切。

这倒是跟传统软件工程的「文档即代码」理念一脉相承。只不过以前是为了让人类开发者少踩坑，现在是为了让 Agent 少犯错。

而且随着项目推进，他们发现需要把越来越多的「隐性知识」显性化，推入仓库。以前靠老员工口头传授的东西，现在必须写成文档，因为 Agent 不会来问你、也不会去茶水间聊天。

给 Agent 写的代码

第二个理念则跟传统认知完全相反：代码不仅要对人类可读，更要对 Agent 可读。

传统的代码可读性，讲的是命名规范、注释、模块化，让下一个接手的程序员能看懂。但 OpenAI 团队发现，Agent 理解代码的方式跟人类不一样。

它们更依赖结构化的线索：严格的分层架构、一致的命名模式、显式的类型定义。那些对人类来说「一看就懂」的隐含约定，对 Agent 来说可能是致命盲区。

所以他们在架构设计上做了大量工作，确保代码结构本身就能引导 Agent 做出正确的决策。这是一种新的可读性标准：application legibility，应用的可读性。

自主性分级

第三个理念是渐进式的自主性提升。

他们没有一上来就让 Agent 全权负责所有事情。而是从简单任务开始，逐步提升 Agent 的自主权限。随着 Harness 越来越成熟，Agent 获得的自由度也越来越大。

到了后期，单个 Codex 任务可以连续运行 6 个小时以上，自主完成复杂的功能开发。

这也呼应了一个规律：自主性的提升，必须建立在约束系统成熟的基础上。 你不会让一个实习生第一天就独立负责核心模块。

合并哲学

他们的 PR 合并策略也值得一说。

每个 Codex 任务产出的 PR，在合并前会经过 linter、结构化测试和自动化检查。工程师做的是「审查」，不再是「修改」。

如果一个 PR 需要大量修改才能合并，他们会反思：Harness 哪里出了问题，为什么 Agent 会产出这样的代码？

然后把修复方案反哺回 Harness，让这类问题下次不再出现。

团队增长反而提升了吞吐量，这个结论也有些违反直觉的。

传统团队加人往往有「布鲁克斯法则」的问题（加人反而更慢），但在 Agent 驱动的模式下，每个工程师都是独立的「Harness 调参师」，互相之间的协调成本很低。

他们的工程师角色发生了根本性的变化。OpenAI 团队自己描述：

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

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

那么……Harness 到底是个什么东西呢？

Philipp Schmid 给了一个特别好懂的类比：

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

而 Harness，就是给 AI Agent 套上的那层操作系统。

它包括上下文管理（怎么把信息喂给 Agent）、架构约束（什么能做什么不能做）、反馈循环（怎么让 Agent 知道自己做对了没）、工具链（Agent 能用哪些工具），以及整个生命周期的管理。

这个类比其实揭示了一件事：过去两年，我们一直在升级 CPU，更大的模型、更长的上下文、更强的推理能力。

但操作系统呢？还停留在 DOS 时代。

大多数人用 AI Agent 的方式，还是「打开终端，输入命令，看结果」。没有文件系统的概念，没有进程管理，没有标准驱动，没有权限控制。

难怪它不好用。

arxiv 上的一篇论文，Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned，（2603.05344）给出了一个更精确的技术定义，把 Agent 的运行架构分成了三层：

Scaffolding（脚手架）：预执行阶段的组装，包括系统 prompt 编译、工具 schema 构建、sub-agent 注册表填充。相当于操作系统的 BIOS 和引导程序。

Harness（运行时编排）：核心推理循环的包装层，协调工具执行、上下文管理、安全执行和会话持久化。相当于操作系统的内核。

Context Engineering（上下文工程）：Token 预算管理，决定什么信息该进来、什么该压缩、什么该丢弃。相当于操作系统的内存管理。

用一个公式来表示：coding agent = AI model(s) + harness

OpenAI 团队把他们的 Harness 拆成了三个部分。

上下文工程

也就是怎么把正确的信息喂给 Agent。

他们在仓库根目录放了 AGENTS.md 文件，Agent 每次启动都会自动读取。但这个文件更像「目录」，大概只有 100 行左右，告诉 Agent 到哪里去找更详细的信息。

这是个值得注意的设计选择。ETH Zurich 的一项研究发现，CLAUDE.md / AGENTS.md 文件应该控制在 60 行以内。过长的指令文件反而会降低 Agent 的表现。

Agent 知识的边界

但上下文工程远不只是一个 markdown 文件。

他们还给 Agent 接了浏览器（通过 Chrome DevTools Protocol），让它能看到 UI 渲染结果，自己判断页面做得对不对。

接了完整的可观测性栈（基于 Vector、Victoria Logs/Metrics/Traces），而且是每个 worktree 都有一套本地的日志、指标和链路追踪。Agent 可以自己查报错，自己看性能数据，自己定位问题在哪一层。

本地可观测性栈

这就好比，你不仅给新员工发了入职手册，还给了他所有系统的监控大屏的权限。大多数公司连人类工程师都没配这么齐全的可观测性，OpenAI 倒先给 Agent 配齐了。

架构约束

这才是 Harness 最核心的一环。

他们设计了严格的分层架构：Types → Config → Repo → Service → Runtime → UI，每一层只能依赖下面的层。

分层架构

这些规则没有靠 prompt 告诉 Agent「请遵守」，用的是确定性的 linter 和结构化测试来机械执行。Agent 违反了架构规则？CI 直接挂掉，没得商量。

而且 linter 的报错信息里，还嵌入了修复指引，告诉 Agent 应该怎么改。这一招，相当于把「老师傅的经验」写进了编译器。

Cursor 团队在他们的「Self-Driving Codebases」研究中，也得出了类似的结论：

约束比指令更有效。告诉 Agent「不要留 TODO」比告诉它「完成所有实现」效果更好。

这背后有一个反直觉的洞察：约束解空间反而让 Agent 更有生产力。 当 Agent 可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义了清晰的边界，Agent 反而更快收敛到正确答案。

熵管理

他们管这个叫「垃圾回收」。

AI 生成的代码写多了，文档会过时，架构会漂移，风格会走样。所以他们定期启动专门的 Agent，去扫描文档不一致、架构违规等问题，提交修复 PR。这些 PR 大多能在一分钟内审查并合并。

就像你家如果不定期打扫，再好的装修也会变成垃圾场。

OpenAI 团队把这种心态总结成了一句话：

当 Agent 遇到困难时，我们把它当作一个信号：找出缺了什么，是工具、是护栏、还是文档，然后把解决方案反哺回仓库。

Harness 改进飞轮

这其实构成了一个持续改进的飞轮：

Agent 犯错 → 人类诊断原因 → 改进 Harness → Agent 下次不再犯同样的错 → 新的错误出现 → 循环继续。

如果只有 OpenAI 一家在做，Harness Engineering 可能只是个噱头。但事实上，多家公司几乎同时走向了同一个方向。

Stripe：每周 1300 个 PR

Stripe 内部的「Minions」系统，可能是目前规模最大的 Agent 编程实践。

每周合并 1300 多个 PR，全部由无人值守的 Agent 完成。 这些 Agent 没有人在旁边盯着，也没有人在引导。

它的架构有个值得细看的设计：Blueprint 编排系统，把工作流拆成确定性节点和 Agentic 节点的混合体。

确定性节点（比如「运行 linter」「推送更改」）按固定路径执行，不调用 LLM。Agentic 节点（比如「实现这个功能」「修复 CI 失败」）才让 LLM 行使判断。

Blueprint 编排：确定性与 Agentic 节点交替

这就像一条生产线：传送带是确定性的，工人的手艺活是 Agentic 的。你不会让工人自己决定传送带往哪走。

Stripe 还有一个硬性限制：CI 最多跑两轮。第一轮 CI 失败了，Agent 自动修复，再跑一次。如果还失败，直接转交人类。不允许 Agent 在 CI 上无限重试。

它们的内部工具平台「Toolshed」挂载了大约 500 个 MCP 工具，但给每个 Agent 的只是精心筛选过的子集。因为他们发现了一个关键规律：更多的工具并不等于更好的表现。

Stripe 工程团队的总结：

成功取决于可靠的开发者环境、测试基础设施和反馈循环，跟模型选择关系不大。如果对人类友好，对 LLM 也一样友好。

Cursor：每小时 1000 个 commit

Cursor 的「Self-Driving Codebases」研究走得更远。

他们搭建了一个多 Agent 系统，能实现约 每小时 1000 个 commit，一周内超过 1000 万次工具调用。启动后无需任何人工干预。

但值得注意的是，他们走过的弯路恰恰说明了 Harness 设计的难度：

第一版，单 Agent，复杂任务扛不住。第二版，多 Agent 共享状态文件，结果锁竞争严重，Agent 之间互相打架。第三版，结构化角色分工（Planner → Executor → Workers → Judge），太僵硬了。第四版，持续执行器，角色过载导致各种诡异行为。

最终版本是递归 Planner-Worker 模型：一个根级 Planner 拥有全局视野，生成子 Planner 处理细分任务，Worker 在仓库副本上独立操作。

他们还发现了一个有点黑色幽默的现象：差的初始指令会在数百个 Agent 间被放大。一条模糊的指令，一个 Agent 犯的错，乘以几百个并发 Agent……结果可想而知。

Peter Steinberger：一个人的军队

Peter Steinberger 的故事可能更能说明 Harness Engineering 在个人开发者层面的威力。

这位前 iOS 圈的知名开发者，靠着 Agent 驱动的工作流，2026 年 1 月单月产出了 6600 多个 commit。他同时运行 5 到 10 个 Agent，OpenClaw 项目在 4 个月内拿到了 18 万 stars，成了 GitHub 上增长最快的仓库。

他的做法相当激进：他不逐行审查 Agent 生成的代码。

在他看来，代码审查应该变成「prompt review」。他更关心的是生成代码的那个提示词写得好不好，代码本身长什么样倒在其后了。

他花大量时间跟 Agent 做前期规划，挑战和完善方案，然后一键执行，转身去做下一件事。

他还发现了一个反常识的现象：

喜欢算法谜题的工程师反而很难适应 Agent 工作流，而产品导向的工程师适应得更快。

今年 2 月，他加入了 OpenAI。这件事本身，大概也算是对 Harness Engineering 价值的一种认可吧。

前面说了不少案例，这里把关键数据集中拉出来对比一下。

Nate B Jones 的研究：同一个模型，编程基准成功率从 42% 到 78%，差了将近一倍，变量只有 Harness。换句话说，Harness 带来的提升，相当于换了一代模型。

LangChain 的案例：用同一个模型（gpt-5.2-codex），只改 Harness，Terminal Bench 2.0 的成绩从 52.8% 升到 66.5%。排名呢？从三十名开外直接冲进前五。

Pi Research 的发现更是直接：他们在一个下午内，仅通过修改 Harness，就提升了 15 个不同 LLM 的编程能力。标题就叫《Improving 15 LLMs at Coding in One Afternoon. Only the Harness Changed》。

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

工具越少，怎么反而越准呢？这听起来有点反直觉。但道理其实不复杂，就像你给一个实习生 15 把不同的螺丝刀让他修电脑，他可能会手忙脚乱；给他一把十字和一把一字，他反而知道该怎么干了。

Terminal Bench 2.0 排行榜上也有个值得注意的现象：Claude Opus 4.6 在 Claude Code Harness 上排名第 33，但换一个不同的 Harness 就冲到了第 5。同一个模型，同一个基准，排名差了 28 位。

这说明模型可能对特定的 Harness 存在过拟合。 在 A 环境下如鱼得水的模型，换到 B 环境可能就水土不服了。

Aaron Levie（Box CEO）感叹：

Agent Harness 目前的乘数效应太疯狂了。行业在架构上已经有了一些共识，但在具体怎么做上，还有太多不同的打法。

当然了，Harness Engineering 也不是没有人唱反调。而且反对者的来头都不小。

OpenAI 的 Noam Brown 在 Latent Space 的一次访谈中直接表态：

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

他的论据也有历史支撑。在推理模型（reasoning models）出现之前，开发者们在 GPT-4o 上搭建了大量复杂的 Agentic 系统来模拟推理能力。路由器、编排器、multi-agent 协作……一整套基础设施。

然后呢？推理模型一出来，这些基础设施一夜之间就不需要了。

之前投入了大量工程来构建这些 Agentic 系统……结果我们造了推理模型之后，你根本不需要那些复杂的行为了。事实上，在很多时候，这些东西反而让效果更差了。

他的预判是，OpenAI 将走向一个统一模型的未来：

我们公开说过，我们想要走向一个单一统一模型的世界。你不应该需要在模型上面再加一个路由器。

他给开发者的建议，只有一句话：

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

METR（一个专注 AI 安全评估的研究组织）的数据也给了 Harness 阵营一记闷棍。

他们找了 scikit-learn、Sphinx、pytest 三个知名开源项目的 4 位活跃维护者，让他们审查 296 个 AI 生成的 PR。结果发现：维护者的合并率，大约只有自动化评分通过率的一半。

以 Claude Sonnet 4.5 为例，自动评分器给出的成绩对应大约 50 分钟的任务范围，但维护者实际愿意合并的 PR 对应的任务范围只有 8 分钟左右。这代表了 7 倍的能力高估。

而在他们的测试中，Claude Code 和 Codex 并没有比一个基础脚手架表现更好。Harness 的选择，基本落在误差范围内。

Scale AI 的 SWE-Atlas 基准测试也指向了类似的结论。

Latent Space 给 Noam Brown 这一派的观点起了个名字，叫「Bitter Lesson 阵营」。出自 Rich Sutton 那篇著名的 AI 随笔：别在工程花活上下太多功夫，算力的增长终究会碾平一切。

你那些花里胡哨的 AI 脚手架，终将被规模冲走。

Latent Space 在 3 月初做了一期专题分析，标题就是《Is Harness Engineering Real?》，把整个行业分成了两大阵营。

Big Model vs Big Harness 路线之争

Big Model 阵营

核心观点：模型能力的增长才是主旋律，Harness 只是权宜之计。

Claude Code 团队的 Boris Cherny 和 Cat Wu 在受访时表示：

所有的秘密武器都在模型本身。我们追求的是最薄的那层包装。

他们强调的是持续简化，别往上堆复杂性。Claude Code 本身就是这个理念的产物，它的 Harness 层尽可能地薄，把更多的事情交给模型自己判断。

Big Harness 阵营

核心观点：模型是引擎，Harness 是方向盘和刹车。引擎再强，没有方向盘你也到不了目的地。

Jerry Liu（LlamaIndex 创始人）的话代表了这一派的立场：

Model Harness 就是一切。从 AI 那里获取价值的最大障碍，是你自己为模型做上下文工程和工作流工程的能力。

支撑这个观点的数据也不少。调研显示，开发者在 60% 的工作中使用 AI，但真正完全委托给 AI 的任务只有 0 到 20%。这中间的巨大鸿沟，在 Harness 阵营看来，问题出在 Harness 上，跟模型本身关系不大。

Cursor 的 $50B 估值（应该算是 Harness 公司的代表了），某种程度上也在印证这个方向的价值。

那……到底谁对呢？

我觉得两边都对了一半，但都忽略了一个更深层的东西。

Philipp Schmid 观察到一个现象：Harness 本身也在不断被简化。

Manus 在 6 个月内重构了 5 次 Harness。LangChain 一年内重新架构了 3 次研究型 Agent。Vercel 砍掉了 80% 的 Agent 工具。

这说明 Harness 并非一劳永逸的。它需要跟着模型能力一起演化。模型变强了，Harness 就该变薄。

但「变薄」和「消失」是两回事。

Böckeler 在 Martin Fowler 网站上的分析提出了一个关键洞察：Harness 真正的价值，其实在于约束解空间。

她认为，要大规模维护 AI 生成的代码，关键在于通过特定的架构模式、强制的边界、标准化的结构，把解空间收窄到一个可控的范围内。

这就是我想说的「护栏悖论」：

车速越快，护栏越重要。

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

护栏悖论：车速越快护栏越重要

模型就是引擎。引擎越强，速度越快，你就越需要精心设计的约束系统来确保它跑在正确的方向上。

Noam Brown 当然也说得对，很多脚手架确实会随着模型进化而被淘汰。但架构约束、反馈循环、熵管理这些东西，本质上不会消失，只会换一种形态。

就像从马车到汽车，马鞭消失了，但方向盘和刹车不会消失。

Harness 阵营真正应该担心的，其实是自己搭建的 Harness 会不会六个月后，就过时了。

Noam Brown 说的「别花六个月搭建一个可能六个月后就被淘汰的东西」，在这个语境下反而成了最好的 Harness Engineering 建议：Harness 要轻，要模块化，要随时准备被拆掉重来。

Philipp Schmid 的建议可以用三个词概括：Start Simple. Build to Delete.

说了这么多理论，那具体怎么做呢？

从目前行业的实践来看，Harness 的配置杠杆大概有这么几类：

Harness 的七个配置杠杆

AGENTS.md / CLAUDE.md 文件。 这是最简单的入门方式。在仓库根目录放一个 markdown 文件，写上架构约定、命名规范、测试期望。Agent 每次启动都会自动读取。记住前面说的，控制在 60 行以内，写「目录」别写「百科全书」。

每次 Agent 犯了一个错，就加一条规则。这就是 Mitchell Hashimoto 所说的 Harness Engineering 最核心的操作。

确定性约束。 linter、类型检查、结构化测试、pre-commit hooks。这些是「硬约束」，Agent 无法绕过。OpenAI 和 Stripe 的经验都表明，硬约束比软性的 prompt 指令更可靠。

工具精简。 别给 Agent 塞太多工具。Vercel 从 15 砍到 2 的案例已经说明了，工具多了 Agent 反而不知道该用哪个。Stripe 有 500 个工具，但每个 Agent 只能看到精心筛选过的子集。

Sub-Agent 隔离。 把复杂任务拆成多个子任务，每个子 Agent 有自己的上下文窗口。这样可以防止中间噪声在主线程中累积，同时也可以给不同的子任务用不同的模型。

反馈循环。 Agent 写完代码后，必须能自己跑测试、看截图、查日志。这就是 Mitchell Hashimoto 说的「给 Agent 造工具」。让 Agent 自己验证自己的产出，别什么都靠人工盯。

CI 限速。 Stripe 的做法值得借鉴，最多两轮 CI。Agent 不应该在 CI 上无限重试。跑两次还不过，就交给人类。这既控制了成本，也防止了 Agent 在错误方向上越跑越远。

垃圾回收。 定期启动 Agent 扫描技术债、过时文档、架构漂移。这是容易被忽略但极其重要的一环，尤其当你的代码量大了之后。

几个值得关注的趋势：

Harness 会成为新的「服务模板」。 Böckeler 提出了一个设想：未来的组织可能会从一组预制的 Harness 模板中选择，然后根据自己的需求定制。这有点像今天的 CI/CD 模板或者 cookiecutter 项目脚手架，只是层级更高。

技术栈会收敛。 当写代码本身不再是瓶颈时，团队会更偏向选择那些「有好 Harness 可用」的技术栈。AI 友好性可能会超过开发者个人偏好，成为选型时的首要考量。

Harness 会反哺模型训练。 Philipp Schmid 提出了一个前瞻性的观点：Harness 捕获的 Agent 失败轨迹，可以成为模型训练的高质量数据。哪些约束被反复触犯？哪些错误模式在不同项目中重复出现？这些数据对模型改进的价值，可能远超传统的训练数据。

「旧代码」问题。 Böckeler 提了一个绕不开的问题：OpenAI 的实验是从空仓库开始的，Harness 从第一天就存在。但对于那些已经有几十万行代码的老项目呢？给老代码加 Harness，可能就像给一个从不跑测试的项目补测试一样痛苦。

学科化。 AIE Europe 已经设立了全球第一个 Harness Engineering 专题赛道。arxiv 上也有了专门的论文。这个概念正在从一个 buzzword 向一个正式的工程学科演进。

写到这里，我忽然意识到一件事。

Harness Engineering 说的这些，上下文管理、架构约束、反馈循环、定期清理……这不就是管理吗？

想想看，一个好的技术 leader 是怎么带团队的？

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

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

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

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

Peter Steinberger 说，喜欢算法谜题的工程师反而很难适应 Agent 工作流，产品导向的工程师适应得更快。

这也印证了一个趋势：未来最吃香的 AI 工程师，可能是最懂「管理」的那种。

管理谁？管理 Agent。

Stripe 的工程师们已经不写代码了，他们写的是 Blueprint、是规则、是约束。OpenAI 的工程师们也不写代码了，他们设计的是环境、反馈循环和控制系统。

@tomiezhang 发了个「暴论」：

大模型开发将是最后的程序员，下来是所谓的 Harness Engineering 开发，所有纯码农，将在 2028 年前消失。

怎么讲，2028 这种预言有点太没依据，纯拍脑袋了……

但方向大概没错：写代码正在变得像打字一样廉价。

而在模型之外，设计让 Agent 持续、稳定、高质量写代码的那套系统，正在变成最值钱的技能。

未来最稀缺的，可能不是训练模型的人，

而是管理模型的人。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】