提问

调用max-search技能
关于Harness Engineering：

查一些行业最佳实践
列出一些反直觉的事实
向新时代的AI工程师提一些有用的建议
最终以单人播客文字稿的形式呈现，5000字左右。

🤯 回答

联网搜索：「Harness Engineering platform CI CD best practices adoption trends 2026」、「continuous verification security shift left Harness vs traditional tools」、「反直觉 harness 平台成本效益实施复杂性真实世界案例」、「AI时代软件工程师 CI/CD pipeline 工具链演进趋势技能」、「Harness Drone Jenkins GitLab 对比分析自动化差距」

AI 模型通过实时调用 Tavily 搜索引擎，找到了 8 + 8 + 8 + 8 + 8 条相关信息。

Harness Engineering：新时代AI工程师的生存指南

单人播客文字稿 · 约5200字

节目说明：本期是一期独白式深度播客。没有嘉宾，没有对话，只有我一个人坐在这里，把过去几个月研究 Harness Engineering 这个话题的所有思考，一次性倒给你听。如果你是一个正在用 Claude Code、Cursor 或者任何 AI Coding 工具的工程师，我建议你把这期节目当成一次认知升级的机会。因为我要讲的很多东西，和你现在脑子里的直觉，是相反的。

开场：一个让我震惊的数字

我先给你一个数字，然后我们再展开聊。

Claude Code 的源代码，总共大约 51 万行。

你猜其中有多少行是真正的"AI 决策逻辑"？

答案是：大约 1.6%。

剩下的 98.4%，全部是确定性的基础设施代码——工具注册、上下文管理、错误处理、日志、Hooks、权限控制、状态机……这些东西，没有一行是在"思考"，它们只是在"执行规则"。

这个数字，是我进入 Harness Engineering 这个话题的起点。它让我意识到，我们对 AI 系统的理解，从一开始就跑偏了。

我们花了太多时间在讨论"哪个模型更聪明"，却几乎没有人在讨论：围绕模型的那套基础设施，到底应该怎么设计？

这套基础设施，现在有了一个正式的名字：Harness。

而围绕它的工程学科，叫做 Harness Engineering。

第一部分：什么是 Harness？为什么它在 2026 年突然变得重要？

让我先把这个概念说清楚。

Harness，字面意思是"马具"或"线束"。在 AI 工程语境里，它指的是围绕 AI 模型的所有非模型部分。

Mitchell Hashimoto，就是那个创造了 Terraform 和 Vagrant 的 HashiCorp 联合创始人，在今年 2 月的一篇博客里给出了一个极其精炼的定义：

"Agent = Model + Harness. If you're not the model, you're the harness."

翻译过来就是：如果你不是模型本身，你就是 Harness 的一部分。

Harness 包含什么？具体来说：

System Prompts 和 CLAUDE.md：告诉模型它是谁、能做什么、不能做什么
工具注册（Tools / MCP Servers）：模型能调用哪些外部能力
编排逻辑：任务怎么分解、Sub-agent 怎么派发、结果怎么路由
Hooks 与中间件：在 Agent 生命周期的关键节点自动执行的确定性脚本
状态管理：上下文怎么持久化、检查点怎么设置
可观测性：日志、追踪、成本计量

这个概念为什么在 2026 年突然爆发？

有一个标志性事件：今年春节前后，Claude Code 的源码泄露事件。这件事在业内引发了巨大震动，不是因为泄露本身，而是因为它让所有人第一次看清楚了：一个顶级 AI Coding 工具，它的核心竞争力根本不在模型，而在那套精密的 Harness 系统。

K2 Lab 的创始人王铭在接受采访时说得很直白：这个事件"极大拉齐了行业水平"，让整个行业从"用 AI 写代码"的阶段，正式进入了"系统性 Harness 时代"。

第二部分：行业最佳实践——顶级团队是怎么做的？

好，现在我们来看真实世界里，那些走在最前面的团队，他们的 Harness 是什么样的。

我研究了几个案例，每一个都让我觉得不可思议。

案例一：OpenAI Codex 团队——零手写代码的百万行产品

OpenAI 内部有一个团队，用 Codex 构建了一个超过百万行代码的产品。这些 PR 经过人类审查，但其中没有一行是人类手写的代码。

他们是怎么做到的？

核心是一套叫做 DevBox 架构的 Harness 设计：每个 Agent 运行在隔离的开发环境里，可观测性工具——日志、指标、追踪——全部通过本地可观测性栈暴露给 Agent。Agent 可以用 LogQL 查日志，用 PromQL 查指标。

这意味着什么？这意味着你可以给 Agent 下这样的指令："确保服务启动在 800ms 内完成"，或者"这四个关键用户旅程中没有 span 超过两秒"——这些指令变得可执行，而不只是可理解。

最佳实践一：给 Agent 可观测性，而不只是代码库访问权限。

案例二：Stripe Minions——在亿行代码库上运行的无人值守 Agent

Stripe 的案例更极端。他们的代码库包含数亿行代码，每年处理超过一万亿美元的支付量。他们构建了一个叫做 "Minions" 的 Agent 系统。

Stripe 的 Harness 有几个关键设计：

第一，Devbox 预热机制。Minion 运行在隔离的开发环境中，与 Stripe 工程师日常使用的机器类型相同。Devbox 预热后 10 秒内可以启动，Stripe 代码和服务预加载。它们与生产资源和互联网隔离，因此可以在无需人类权限检查的情况下并行运行大量 Minion。

第二，Toolshed MCP 服务器。Stripe 构建了一个名为 Toolshed 的中心内部 MCP 服务器，托管超过 400 个 MCP 工具，覆盖内部系统和 SaaS 平台。Minion 可以连接到可配置但经过策展的工具子集。

注意这个词：策展（curated）。不是把所有工具都给 Agent，而是根据任务类型，给它一个精心挑选的工具子集。这是一个非常重要的设计原则。

最佳实践二：工具不是越多越好，策展比堆砌更重要。

案例三：Cursor 的千 Agent 并行实验

Cursor 的一个研究团队让数千个 Agent 在一台大型虚拟机上连续运行一周，峰值时每小时产出约 1000 个 commit，构建了一个几乎完全可运行的浏览器引擎——中间不需要任何人类干预。

这个案例说明了什么？它说明了 Harness 的并行化设计是下一个重要战场。当你的 Harness 设计得足够好，Agent 就可以像工厂流水线一样并行运转，而不需要人类在中间协调。

最佳实践三：Harness 的终极目标是让 Agent 可以无人值守地并行运行。

案例四：LangChain 的 TerminalBench 实验——最震撼的数据

这个案例我要单独拿出来讲，因为它是整个 Harness Engineering 领域最有说服力的实验数据。

LangChain 做了一个实验：他们完全不更换模型和权重，只改变了 LLM 的基础设施（也就是 Harness），在 TerminalBench 2.0 的排名就从 30 名开外跃升到第 5 名。

从 30 名开外到第 5 名。模型没变，只改了 Harness。

这个数据应该让每一个还在纠结"用 GPT-4o 还是 Claude Opus"的工程师停下来想一想：你花在选模型上的时间，是不是应该花在设计 Harness 上？

最佳实践四：在优化模型之前，先优化 Harness。Harness 的收益往往大于换模型的收益。

第三部分：反直觉的事实——你以为你懂，其实你不懂

好，现在进入我最喜欢的部分。我要讲一些反直觉的事实。这些东西，和大多数工程师的直觉是相反的。

反直觉一：决定 AI Agent 可靠性的，不是模型，是 Harness

这是整个领域最大的认知误区。

大多数人在 Agent 表现不好的时候，第一反应是"换个更好的模型"。但 LangChain 的实验已经证明，很多时候 Agent 表现不佳，并非"脑子"不够好，而是"世界"太难懂。

Anthropic 自己也做过一个实验：他们将 Claude 放在一个高度结构化的数字环境里，提供有限且被清晰定义的 API 工具。结果发现，在一个友好的环境中，Agent 的表现远超在真实终端的混乱环境中的发挥。

结论是：重塑环境接口（修路）的收益，大于打磨模型（训练司机）的收益。

反直觉二：更多的 Prompt 不等于更好的控制，机制比提示更可靠

这是第二个大误区。

很多工程师在 Agent 出错的时候，会在 System Prompt 里加更多的约束："不要做 X"、"必须先做 Y"、"记住要 Z"……

但这是错的。

正确的做法是：用机制（Hooks、Linters、Tests）来强制执行质量，而不是用 Prompt 来祈祷模型遵守规则。

搜索结果里有一句话我觉得说得极好："enforce quality with mechanisms, not prompts"——用机制强制质量，而不是用提示词。

Claude Code 的 Hooks 系统就是这个思想的体现。你可以在 PostToolUse 事件上挂载一个脚本，自动运行 typecheck 和 formatter，如果失败就强制 Agent 继续修复。这比在 Prompt 里写"请确保代码通过类型检查"要可靠一百倍。

反馈应该尽可能快。按速度排序：PostToolUse Hook（毫秒级）> pre-commit（秒级）> CI（分钟级）> 人工审查（小时级）。把检查推到最快的层。

反直觉三：Sub-agent 不应该返回原始数据，而应该返回摘要

这个反直觉对于构建多 Agent 系统的工程师特别重要。

很多人在设计 Orchestrator + Sub-agent 架构时，会让 Sub-agent 把所有搜集到的原始信息都返回给 Orchestrator。这看起来很合理——信息越完整越好嘛。

但这是错的。

原因是：Orchestrator 的上下文窗口是有限的，也是宝贵的。如果 Sub-agent 把大量原始数据塞回来，Orchestrator 的上下文很快就会被污染，它的推理质量会急剧下降。

正确的设计是：Sub-agent 作为"智能过滤器"，迭代使用工具收集信息后，只将精炼摘要返回给 Orchestrator。这保护了 Orchestrator 的上下文窗口，让它始终处于"聪明区"——上下文小、相关性高、指令预算充裕。

这个设计还有一个额外好处：成本控制。你可以在 Orchestrator 用昂贵的 Opus 做规划和编排，在 Sub-agent 用便宜的 Haiku 执行具体的搜索和抓取任务。没必要在代码库 grep 上烧 Opus 的 token。

反直觉四：AI 生成代码速度越快，部署瓶颈越严重

这个反直觉来自 Harness 在 2026 年 3 月发布的《State of DevOps Modernization 2026》报告，调查了 700 名工程师和技术管理者。

报告发现：使用 AI Coding 工具最频繁的团队，部署频率确实最高，但其中约 22% 的部署需要补救，平均故障恢复时间（MTTR）高达 7.6 小时。

Harness 的 SVP Bradley Rydzweski 说了一句话，我觉得是今年最重要的工程洞察之一：

"我们在现场看到的情况是，流程的其余部分根本跟不上开发者和工具生成代码的速度。"

翻译成大白话：AI 让你写代码的速度提升了 10 倍，但你的 Code Review、测试、部署流水线还是原来的速度。结果就是：PR 堆积、代码审查时间变长、PR 体积变大、部署风险上升。

这是一个系统性问题，不是个人问题。解决方案不是"写慢一点"，而是同步升级你的 Harness，让整个交付流水线的吞吐量匹配 AI 的生产速度。

反直觉五：依赖内部化（Vendoring）在 AI 时代变得合理了

这个反直觉来自 OpenAI Codex 团队的 Ryan Lopopolo 的一段访谈，我觉得非常有意思。

他说：以前，引入一个外部依赖是理所当然的——自己实现太贵了。但现在，如果一个依赖只有几千行代码，完全可以用 AI 在一个下午内部实现，而且可以把那些通用但和你无关的部分全都剥掉，只保留你真正需要的那部分。

更重要的是：内部化的依赖，Agent 可以以极低的摩擦进行深度审查和修改。而如果你依赖上游开源项目，你需要提 PR、等发布、拉回本地、确认兼容性——这个成本在 AI 时代显得极其昂贵。

他的结论是：如果 token 足够便宜，依赖内部化本身就会变成一件顺理成章的事。

反直觉六：Harness 不是"终将被吞掉的中间件"，而是"控制平面"

这是一个关于 Harness 长期价值的反直觉。

有一种观点认为：随着模型能力越来越强，Harness 会被模型 API 逐渐吞噬，最终消失。

这个观点对了一半，错了一半。

对的部分：那些只是封装了"Prompt 链"和"基础执行循环"的套壳框架，确实正在被底层模型无情地降维打击。

错的部分：API 可以吞噬"机制"，但替代不了"策略"。

什么是策略？是：什么时候该触发降级方案、如何在有限的 token 预算下动态切分任务、多个不同能力的 Agent 发生决策冲突时该听谁的、如何保证输出结果符合特定行业的合规性。

这些东西，模型 API 永远给不了你。因为它们是你的业务逻辑，不是通用逻辑。

所以，Harness 的本质从来不是"封装逻辑的中间件"，而是复杂系统的**"控制平面"与"策略层"**。这个价值，不会被模型进化所消解。

第四部分：给新时代 AI 工程师的建议

好，现在进入最后一个部分。我要给你一些具体的、可操作的建议。

这些建议，是我综合了 Anthropic 的研究报告、Harness 的行业调查、以及多个顶级团队的实战案例之后，提炼出来的。

建议一：先建 MVH（Minimum Viable Harness），再迭代

很多工程师在接触 Harness Engineering 之后，第一反应是：这也太复杂了，我从哪里开始？

答案是：从最小可行 Harness 开始，每次 Agent 犯错，就加固一层 Harness。

MVH 的最低配置是什么？

一个 CLAUDE.md（或 AGENTS.md），定义 Agent 的角色、工作流程和约束
一个 PostToolUse Hook，在每次工具调用后自动运行 linter 和 typecheck
一个 pre-commit 钩子，防止明显的错误进入代码库

就这三样东西，已经能解决 80% 的 Agent 可靠性问题。

然后，每次你发现 Agent 在某个地方犯了错，不要只是修复那个错误，而是问自己：我能在 Harness 里加什么机制，让这个错误永远不再发生？

这是一个复利游戏。你的 Harness 会随着时间越来越强，而不是每次都从头开始。

建议二：把反馈速度当成第一设计原则

这是我认为最被低估的工程原则之一。

反馈越快，Agent 的修正成本越低，最终质量越高。

按速度排序，你应该把检查推到尽可能快的层：

PostToolUse Hook（毫秒级）：每次工具调用后立即检查
Pre-commit（秒级）：提交前自动运行
CI Pipeline（分钟级）：合并前自动运行
人工审查（小时级）：只用于真正需要人类判断的决策

如果你现在的架构是"Agent 写完所有代码，然后人工审查"，你的反馈循环太长了。Agent 在这个过程中积累的错误，会像滚雪球一样越来越难修复。

建议三：重新定义你的工程师角色

Anthropic 在今年 2 月发布的《Agentic Coding Trends Report》里有一个重要发现：随着 Agent 使用的扩展，工程师的价值正在向上游转移——系统设计、Agent 编排、质量评估、战略性问题分解。

这意味着什么？

这意味着，如果你还在把大部分时间花在写代码上，你正在做一件 AI 越来越擅长的事情。而你应该把时间花在 AI 越来越不擅长的事情上：定义"应该构建什么"，而不是"怎么构建"。

瓶颈已经从"写代码"转移到了"明确定义要写什么"。

这不是说写代码不重要，而是说：你的核心竞争力，应该是把模糊的业务需求转化为精确的、可被 Agent 执行的规格说明（Spec）。

K2 Lab 的王铭说了一句话我很认同："关键在于 Harness 的设计。" 他们团队代码 AI 生成率达到 99%，但他们花了大量时间在 Harness 框架的设计上——定义好规则，结合模型能力，产出系统。

建议四：建立团队级的 Harness 规范，而不是个人级的

这个建议特别针对有一定规模的团队。

很多团队现在的状态是：每个工程师都有自己的一套 Prompt 技巧和 Agent 使用方式，但没有团队级的统一规范。这会导致：

经验无法沉淀和传播
踩过的坑，别人还会再踩
AI 生成的代码风格不一致，难以维护

正确的做法是建立团队级的 Harness 规范，包括：

Constitution Rules：不可逾越的底层约束（安全规范、代码风格、架构边界）
SPEC 模板：标准化的需求描述格式
Skills 库：可复用的 Agent 技能集合
CI 规则和 Lint 规则：统一的质量门

这些规范应该像代码一样用 Git 管理，像产品一样持续迭代。

有一个细节我觉得很重要：当某次 Agent 协作成功解决了一个复杂问题，应该把这次高质量的解决方案总结成 Markdown 文档归档。这样，下次遇到类似问题，AI 的准确率会明显提高。知识是可以积累的。

建议五：认真对待可观测性，这是 Harness 的神经系统

这个建议来自 OpenAI Codex 团队的实战经验。

他们在构建 Harness 的时候，第一件事不是写更多的 Prompt，而是把可观测性给到模型。日志、指标、追踪——让 Agent 能够"看到"自己的运行状态。

为什么这很重要？因为一个看不到自己行为后果的 Agent，就像一个蒙着眼睛开车的司机。它可能偶尔走对，但你无法依赖它。

LangChain 的调查数据显示：截至 2026 年，89% 的组织已经实施了 Agent 可观测性。这不是可选项，这是标配。

具体来说，你的 Harness 应该能回答这些问题：

这个 Agent 为什么做了这个决策？
它的推理轨迹能否被完整回溯审计？
这次任务消耗了多少 token，成本是多少？
哪些工具调用失败了，失败原因是什么？

如果你现在回答不了这些问题，你的 Harness 还不完整。

建议六：不要等到"准备好了"再开始

最后一个建议，也是最重要的一个。

Harness Engineering 是一个新兴领域，没有人完全准备好了。那些走在最前面的团队——OpenAI、Stripe、Cursor——他们也是在实践中摸索出来的，不是先有完整的理论再开始的。

K2 Lab 的王铭描述了他们的三个阶段：生产力增强阶段、规则制定阶段、Harness 时代。每个阶段都是在上一个阶段的基础上迭代出来的，不是一步到位的。

所以，我的建议是：从今天开始，用最小可行 Harness 起步，然后在每次 Agent 犯错的时候加固它。

不要等到你完全理解了 Harness Engineering 的所有概念再开始。因为这个领域本身还在快速演化，等你"准备好了"，最佳实践可能已经变了。

行动，然后学习。这是这个时代唯一有效的学习方式。

结语：我们正在经历的范式转变

让我用一段话来结束今天的节目。

我们正在经历的，不只是一次工具升级，而是一次软件工程范式的根本性转变。

在旧范式里，工程师的核心工作是写代码。质量由人来保证，通过 Code Review、测试、经验积累。

在新范式里，工程师的核心工作是设计系统——设计 Harness，设计 Agent 的工作环境，设计质量保证机制。代码由 AI 来写，但写什么、怎么验证、出错了怎么处理，这些决策权还在人手里。

这个转变，对不同的工程师意味着不同的事情。

对于那些习惯了"我来写代码"的工程师，这是一次挑战——你需要学会"我来设计系统，让 AI 写代码"。

对于那些一直在做系统设计、架构规划的工程师，这是一次机遇——你的核心能力，在 AI 时代变得比以往任何时候都更重要。

Harness Engineering，本质上是在问一个问题：你怎么让一个概率性的系统，在确定性的商业世界里可靠地运转？

这个问题没有标准答案。但有一点是确定的：答案不在模型里，在 Harness 里。

好，今天的节目就到这里。如果你觉得有收获，把这期节目分享给你的工程师朋友。我们下期见。

关于Harness工程最佳实践及AI时代工程师的建议分享

提问