Harness Engineering 深度研究报告

一、纵向分析：从 CD 创业公司到 AI 软件交付平台

1.1 序章：一个关于“代码之后”的故事

2017年1月24日，思科以37亿美元的价格收购了应用性能监控公司AppDynamics——这个交易发生在一个非常戏剧性的时刻：AppDynamics原定次日上市，思科在最后一刻截胡。对于创始人Jyoti Bansal来说，这笔交易让他一夜之间成为硅谷新贵，个人财富暴涨到数亿美元。

大多数人卖了公司之后会做什么？买岛、打高尔夫、躺在沙滩上晒太阳。Bansal试过。他告诉媒体：“我试过退休。人们说，‘等我退休了，我就要做我享受的事情。’我问自己，‘我真的享受一直打高尔夫或者一直待在沙滩上吗？’我不享受。”

于是他做了硅谷最经典的选择：再创一次业。

但这一次，Bansal不是从零开始。他用自己的5000万美元成立了创业工作室BIG Labs，目标是有系统地孵化新公司。Harness，就是这个工作室诞生的第一个项目。

为什么选持续交付（Continuous Delivery）？这个选择根植于Bansal在AppDynamics的十年经历。做APM（应用性能监控）的时候，他几乎天天听到客户抱怨同一件事：软件变更部署到生产环境的时候，老出事。“我们的软件帮他们在出问题之后定位问题，”Bansal回忆，“但客户真正想要的，是压根不出问题。”

这里面有一个被很多人忽略的行业真相。写代码本身只占了软件工程总工作量的30%左右。剩下的70%——测试、安全扫描、部署、验证、回滚——仍然是高度手动、高度脆弱的流程。Bansal称之为“编码后的世界”（the after-code world）。2017年，这个领域几乎还是一片荒原。

他拉来了一个关键合伙人：Rishi Singh，前Apple的DevOps平台架构师，担任CTO。Singh在苹果见识过世界上最大规模的持续交付流水线是什么样子的，他知道真正的痛点在哪儿。

2017年10月，Harness正式对外发布，带着2000万美元的A轮融资，由Menlo Ventures和BIG Labs领投。

这时候的Harness定位非常清晰：持续交付即服务（Continuous Delivery as a Service）。核心理念是用AI来“看护”软件部署过程——系统自动学习应用的正常行为模式，部署时一旦检测到异常，自动回滚。Bansal当时的口号是“减少99%的错误”。

但说实话，2017年聊“AI驱动DevOps”，市场并不买账。那时候的“AI”更多是规则引擎加机器学习，远不像今天这么性感。Harness早期的产品确实有效，但它面对的是一个极其分散的CD工具市场：Jenkins占据开源阵地，Spinnaker在Netflix体系内流行，还有CircleCI、Travis CI等云原生玩家各占一隅。

更大的问题是：持续交付作为一个独立品类，天花板到底有多高？只做CD，Harness能走多远？

1.2 第一次跃迁：从 CD 到“现代软件交付平台”

2019年4月，Harness完成了6000万美元的B轮融资，IVP、GV（Google Ventures）和ServiceNow Ventures参与其中，估值达到5亿美元。这笔钱给了Harness扩张的底气。

Bansal在一次采访中说了一句很能说明问题的话：Harness的增长速度是AppDynamics同期的两倍以上。背后的驱动力是什么？他归结为“企业向软件的全面转型”——每家公司都在变成软件公司，而软件交付速度正在成为核心竞争力。

但这轮融资之后，Harness开始了一个根本性的转型：从一个单一的CD产品，变成覆盖整个软件交付生命周期的平台。

这个转型不是突然发生的，而是通过一系列产品和收购步步推进的：

2020-2021年：模块化扩张

Harness在2020年推出了Cloud Cost Management（CCM）模块，帮企业优化云支出。这个模块的逻辑很直接：既然我们已经深入了部署流程、知道哪些服务在用多少云资源，为什么不顺便帮客户省钱？CCM迅速成为Harness最受欢迎的功能之一，有些客户甚至先买CCM，再买CD。

紧接着是Feature Flags（特性标志），允许开发团队在不重新部署的情况下动态开关功能。再然后是Service Reliability Management（SRM），以及收购Chaos Native带来的Chaos Engineering（混沌工程）能力。到2021年底，Harness已经拥有六个核心模块：CD、CI、Feature Flags、CCM、SRM和Chaos Engineering。

2022年：跨越临界点

2022年4月，Harness完成2.3亿美元D轮融资，估值飙升至37亿美元。这一轮参与者包括摩根大通、Capital One Ventures等战略投资者——这是一个强烈信号：华尔街的巨头们开始把Harness视为企业级基础设施。

D轮之后，Harness继续扩张产品线：推出了Security Testing Orchestration（STO），把安全测试编排进CI/CD流水线；收购了开源CI项目Drone，补齐了CI能力；2023年又推出了Internal Developer Portal（IDP），解决开发者的自助服务体验问题。

Gartner在2023年发布首份DevOps平台魔力象限报告，将Harness列为“远见者”（Visionary）象限，肯定其“远见完整性”和“执行能力”。同一年，Forrester Wave的集成软件交付平台评测中，Harness在CI/CD和平台能力两个维度上都拿到了最高分。

2024年：补齐Spinnaker版图

2024年1月，Harness收购了Armory的关键知识产权和技术资产。Armory是Spinnaker生态里最重要的商业公司，其团队深度参与了Spinnaker的核心开发。

这笔收购很有战略眼光。Spinnaker是Netflix开源的持续部署平台，在需要多环境、多云的复杂部署场景中地位极高。Harness通过Armory直接继承了Spinnaker社区的技术积累和客户基础，还顺势把Armory的核心工程师收入麾下。加上此前收购的Drone（开源CI）和Chaos Native（混沌工程开源项目），Harness在开源社区的布局已经相当扎实。

至此，Harness的“现代软件交付平台”雏形已经完整：从CI到CD，从特性管理到成本优化，从安全到可靠性工程，覆盖了软件从代码提交到生产运行的全链路。

1.3 第二次跃迁：押注AI原生

2025年是Harness历史上最关键的一年。不是因为融资额，而是因为公司的战略定位发生了根本性变化——从“现代软件交付平台”进化到“AI软件交付平台”。

这个转型有三个关键节点：

第一，与Traceable合并（2025年2月）。 Traceable是Bansal在2018年联合创立的另一家公司，专注API安全。Bansal同时经营着Harness、Traceable和风投机构Unusual Ventures三摊事。2025年初，他做了一个果断的决定：把Traceable并入Harness。理由是：“DevOps和应用安全正在深度融合，我们看到了整合的乘数效应。”合并后，Harness的应用安全业务ARR预计达到5000万美元，增长势头强劲。

第二，E轮融资和55亿美元估值（2025年12月）。 高盛领投2亿美元，IVP、Menlo Ventures、Unusual Ventures跟投，另外还有4000万美元的员工股票回购要约。投后估值55亿美元，比2022年的37亿美元上涨49%。此时Harness的ARR已超过2.5亿美元，同比增长超过50%。

但这轮融资更值得关注的是时机和叙事逻辑。Bansal在融资公告中抛出了一个新概念：“AI速度悖论”（AI Velocity Paradox）。意思是：AI让代码生成的速度飙升，但代码之后的测试、安全、部署流程仍然是手动的、碎片化的。前端加速、后端不动，瓶颈只会越来越堵。Harness的定位非常精准——用AI来搞定“代码之后”的一切。

这个叙事完美地切中了2025年底的市场情绪。企业刚经历了一波AI编程工具的大规模采用，GitHub Copilot、Cursor等工具确实让写代码更快了，但随之而来的是生产环境中的问题也越来越多。Harness的解决方案是：用AI智能体（AI agents）自动化测试、验证、安全扫描和治理，所有智能体都运行在一个“软件交付知识图谱”之上，这个图谱映射了代码变更、服务、部署、测试、环境、事件、策略和成本之间的关系。

Bansal说：“这个知识图谱是我们的AI智能体使用的上下文。”它让系统深度理解每个客户的软件交付流程和架构，而不仅仅是跑通用的AI模型。专门构建的智能体利用这些上下文来生成匹配每个客户特定策略、架构和操作要求的流水线。

第三，收购Qwiet AI（2025年9月）。 就在E轮融资前三个月，Harness收购了Qwiet AI（前身是ShiftLeft），这是一家专注于AI驱动的漏洞检测和可达性分析的公司。Qwiet AI的代码属性图（Code Property Graph）技术与Harness的软件交付知识图谱集成后，能够更精准地识别真正的安全风险。Qwiet声称拥有97%的真阳性率和90%的误报降低率。

这次收购的背景是：AI生成代码越来越多，其中夹杂着大量安全漏洞——模型训练的代码库本身就不干净，生成的代码自然继承了很多不安全模式。Harness收购Qwiet AI，就是要在安全测试这个关键环节建立壁垒。

到2025年底，Harness的客户规模超过1000家企业，包括美国联合航空、晨星、Keller Williams、澳大利亚国民银行等。过去一年处理了1.28亿次部署、8100万次构建、保护了1.2万亿次API调用，帮助客户优化了19亿美元云支出。

2026年3月，Harness登上《财富》美国最具创新力公司榜单第24位，被评价为“将AI应用到代码之后的一切”。

2026年4月，Infosys与Harness宣布战略合作，将Infosys Topaz Fabric（一个智能体服务套件）与Harness平台整合，目标是为全球企业加速智能体驱动的软件交付转型。

1.4 关键决策的复盘：为什么选了这条路而不是那条？

回顾Harness八年的发展，有几个决策节点值得深入分析：

为什么不只做CD？

早期Harness完全可以把自己定位成“最好的CD工具”。CD市场虽然不大，但足够养活一家小而美的公司。Bansal显然不这么想。他经历过AppDynamics从一个单点工具成长为平台的完整过程，知道单点工具的估值天花板在哪里。所以从B轮开始，Harness就坚定地走平台化路线。

这个选择的代价是资源分散。一个团队同时做CD、CI、CCM、STO、FF、SRM、Chaos……每个模块都是一个独立战场。Harness选择的方式是：核心模块自研，边缘能力通过收购补齐（Drone、Chaos Native、Armory、Qwiet AI）。这种“平台+并购”的策略需要大量的资本支持——好在Bansal的融资能力足够强。

为什么2025年才全力转向AI？

实际上Harness从2017年成立就声称用AI做持续验证。但那时的“AI”和今天的“AI”完全是两个概念。2023年大模型爆发后，Harness并没有立刻冲进去喊“AI DevOps”，而是花了两年时间构建软件交付知识图谱。这是Bansal的典型风格——先搭基础设施，再讲故事。到了2025年，知识图谱、AI智能体、编排引擎全部就绪，E轮融资的叙事水到渠成。

为什么跟Traceable合并而不是保持独立？

Traceable作为独立公司做得不错，API安全市场本身也在增长。但Bansal看到了一个更大的机会：AI时代，安全测试和软件交付的边界在消失。如果测试、部署、安全是同一个流程的不同阶段，那把安全能力内置到平台里，比让客户买两个产品再集成，要强得多。这是一步“舍小求大”的棋。

为什么在这个时间点让员工套现？

E轮融资中的4000万美元要约收购很有意思。一般创业公司到后期才会考虑员工流动性问题，但Harness从2017年到现在已经八年了，早期员工手里的期权确实需要变现通道。Bansal在IPO之前安排这次回购，既能留住核心人才，又能缓解上市压力。他明确表示IPO仍然是目标，但“时机合适时才会上市”。

1.5 当前状态的速写

截至2026年4月，Harness的轮廓大致如下：

• **估值**：55亿美元（2025年12月E轮）
• **ARR**：超过2.5亿美元（2025年），同比增长50%+
• **总融资**：约5.7亿美元股权融资
• **员工**：1200+人，分布在全球14个办公室，约33%在印度（班加罗尔有大型工程团队）
• **客户**：1000+企业客户
• **产品矩阵**：CD、CI、Feature Flags、CCM、SRM、STO、IDP、Chaos Engineering、Harness AI（AI智能体平台）、AI Test Automation等
• **行业地位**：Gartner DevOps平台魔力象限“远见者”（2023），Forrester Wave ISDP最高分，Fortune最具创新力公司第24位（2026）

二、横向分析：在DevOps平台的丛林中

2.1 竞争格局概览

Harness所处的赛道可以用一个词形容：拥挤。从开源的老牌工具到云厂商的原生服务，从垂直品类的专精选手到全栈平台巨头，每个角落都有玩家。

Gartner在2025年9月发布的DevOps平台魔力象限中，列出了10家主要厂商：Atlassian、Buildkite、CircleCI、CloudBees、GitLab、Harness、Huawei、JetBrains、Microsoft、Octopus。但这只是企业级平台的名单。如果再算上开源工具（Jenkins、Spinnaker、ArgoCD）和云厂商原生服务（GitHub Actions、AWS CodePipeline、Google Cloud Build），实际可供企业选择的CI/CD方案超过20种。

根据Harness自身披露，其直接竞争对手包括微软的GitHub、GitLab、Jenkins和CloudBees。

这里面需要做一个分类。不是所有“竞争对手”都在同一个维度上竞争：

• **全栈DevOps平台**：GitLab、Microsoft（GitHub）、Harness、Atlassian——覆盖从代码托管到部署监控的完整流程
• **专注CI/CD的工具**：CircleCI、Jenkins、Buildkite、CloudBees——核心在CI和CD环节
• **云原生CD专业工具**：Spinnaker、ArgoCD——专注Kubernetes环境下的GitOps部署
• **云厂商原生服务**：AWS CodePipeline、Azure DevOps、Google Cloud Build——深度绑定自家云生态

Harness的独特之处在于：它从CD起步，向上延伸到CI，横向扩展到安全、成本、特性管理，最终覆盖了CI/CD+DevSecOps+FinOps的融合场景。在这个维度上，真正能跟它进行全面对标的是GitLab，部分对标的是GitHub Actions。CircleCI和Jenkins则在更窄的CI/CD维度上构成竞争。

以下选取四个最具代表性的竞品进行深入分析：GitLab（全栈平台的直接对手）、GitHub Actions（生态巨头的降维打击）、CircleCI（同代云原生CI玩家）、Jenkins（无法绕过的开源基线）。

2.2 GitLab：最完整的对标者

如果要在市场上找一个跟Harness最像的对手，答案毫无疑问是GitLab。两者都是从单点能力起步（GitLab从代码托管，Harness从持续交付），逐步扩展为覆盖软件交付全链路的平台。

技术路线对比

GitLab的核心哲学是“单一应用”（single application）。代码托管、CI/CD、安全扫描、项目管理、Wiki、容器镜像仓库——所有功能都集成在同一个界面和同一个数据模型中。用户从创建issue开始，到写代码、跑流水线、部署、监控，全程不离开GitLab。

Harness走的是另一条路：不是“单一应用”，而是“统一平台”。Harness的各个模块（CD、CI、CCM、STO等）可以独立购买和使用，但它们共享同一个底层——软件交付知识图谱。这意味着不同模块之间的数据是打通的：CI的构建数据可以影响CD的部署策略，CCM的成本数据可以和部署决策联动，安全扫描的结果可以自动触发流水线的阻断。

两者的技术路线差异，根植于它们的起源。GitLab是代码托管起家，天然以“仓库”为中心；Harness是持续交付起家，天然以“流水线”和“部署”为中心。GitLab的CI/CD是“从仓库视角看流水线”，Harness的CD是“从部署视角看整个交付流程”。

商业模式对比

GitLab采用开源核心+商业版模式。核心功能开源，高级功能（如安全扫描、合规管理、高级分析）收费。定价按用户数收取订阅费，从免费版、Premium（29美元/用户/月）到Ultimate（99美元/用户/月）不等。

Harness是纯SaaS订阅模式，部分模块有开源版本（如收购来的Drone CI），但核心平台不开放源代码。定价按模块和使用量（如部署次数、构建分钟数）组合收费，客单价通常高于GitLab。

用户口碑与使用场景

GitLab的最大优势是“一站式”和“开发者友好”。开发者已经习惯了在GitLab里写代码、提MR、跑CI，不需要切换到另一个工具。对于中小团队，GitLab几乎能满足所有需求。

但从Gartner Peer Insights上的评价来看，GitLab在复杂部署场景（如多环境、多云的渐进式发布、蓝绿部署、自动回滚）上不如Harness专业。Harness的CD模块被认为是市场上最成熟的商业化CD解决方案之一，尤其在需要精细控制部署策略的企业场景中优势明显。

生态位分析

GitLab占据的是“从代码到云的起点”。它的竞争策略是：只要开发者用我的代码仓库，流水线自然用我的，项目管理和安全扫描也会跟着用。这种“仓库为王”的策略非常有效——GitLab拥有超过3000万注册用户。

Harness占据的是“代码之后的专业地带”。它的策略是：不管你的代码存在哪里（GitHub、GitLab、Bitbucket都行），只要你需要高质量的持续交付、成本优化、安全编排，Harness都能做。这是一个更“后置”的生态位，但竞争壁垒更高，因为CD的专业性比CI更强。

2.3 GitHub Actions：生态巨头的天然优势

如果说GitLab是Harness的对标者，那GitHub Actions就是Harness最危险的对手——不是因为它产品多好，而是因为它的分发渠道无与伦比。

技术路线对比

GitHub Actions本质上是一个事件驱动的自动化引擎。代码push触发workflow，workflow里运行一系列action（可以是官方提供的、社区贡献的，也可以是自己写的）。它的设计哲学是“模块化”和“社区驱动”——任何人都可以发布action到GitHub Marketplace，供其他开发者复用。

Harness的流水线设计更偏向“声明式”和“集中管控”。用户通过YAML或可视化界面定义pipeline，平台负责执行、验证和回滚。两者都能做CI/CD，但思路完全不同：GitHub Actions像一个“自动化积木盒”，Harness像一个“自动化生产线”。

用户口碑与使用场景

GitHub Actions最大的优势是“零摩擦”。代码在GitHub上，workflow文件放在.github/workflows目录里，自动生效。不需要额外注册账号、不需要额外配置webhook。对于已经在GitHub上的项目，用Actions跑CI几乎是肌肉记忆。

但Actions的局限也很明显。首先是执行时间限制（免费版有分钟数限制），其次是复杂CD场景的支持较弱——Actions原生没有“部署验证”、“自动回滚”、“金丝雀发布”等高级CD能力，需要自己组装。再者，Actions缺乏跨项目的统一视图和治理能力——如果一家公司有几百个仓库在用Actions，想统一查看所有流水线的状态、统一管理密钥、统一设置安全策略，是非常痛苦的。

Harness在这些方面是强项：统一的流水线视图、内置的验证和回滚、企业级的RBAC和审计日志。这就是为什么大企业往往在GitHub Actions上跑CI，但把CD交给Harness或Spinnaker。

生态位分析

GitHub Actions占据的是“CI的默认选项”。它的竞争策略是：既然代码都在GitHub上，为什么还要把CI数据搬到另一个平台？直接在原地跑就行了。这个逻辑在CI环节无懈可击。

Harness的应对策略是：我不跟你争CI的入口，我做好CD和“代码之后”的一切。实际上，很多Harness的客户同时使用GitHub Actions做CI，用Harness做CD、安全扫描、成本管理。Harness的产品设计也支持这种混合模式——可以无缝集成GitHub Actions的构建产物，继续完成后续的部署和验证流程。

2.4 CircleCI：云原生CI的元老

CircleCI成立于2011年，是最早把CI搬到云端的公司之一。2021年估值17亿美元，但此后融资节奏放缓，面临激烈竞争。作为一家独立CI/CD公司，CircleCI的处境是整个品类的一个缩影。

技术路线对比

CircleCI的核心竞争力是“快”和“可靠”。通过智能缓存、并行执行、优化的构建环境，CircleCI在纯CI性能上不输任何人。它的“orbs”系统（可复用的配置包）与GitHub Actions的action理念类似，但更早推出。

Harness的CI模块（源自收购的Drone）走的是容器原生路线。Drone的核心理念是“每个构建步骤都是一个Docker容器”，这个设计非常优雅——环境一致性极好，插件生态完全基于容器镜像。Harness收购Drone后，把Drone的轻量级CI引擎与自己的企业级平台能力（统一视图、RBAC、成本管理）结合，形成了一个很有竞争力的CI产品。

用户口碑与使用场景

CircleCI在开发者中有不错的声誉。配置灵活、文档完善、稳定性好。但很多用户反映，CircleCI的定价策略越来越激进，免费额度的缩减让不少开源项目和初创公司转向GitHub Actions或GitLab CI。

从Gartner Peer Insights的数据看，CircleCI的用户满意度处于行业中上水平，但在“平台完整性”这个维度上评分不如Harness和GitLab——毕竟CircleCI只是一个CI/CD工具，没有代码托管、项目管理、安全扫描等配套能力。

生态位分析

CircleCI占据的是“专业CI工具”的生态位。这个生态位正在被挤压：左边是GitHub Actions和GitLab CI这种“自带CI”的平台，右边是Harness这种“CI+CD+更多”的超级平台。

CircleCI的生存策略是“深度”而非“广度”。它不试图做成DevOps全栈平台，而是在CI执行性能、配置灵活性、多云支持上做到极致。对于一些对CI性能要求极高、不想被平台绑定的企业，CircleCI仍然是有吸引力的选择。

但长期来看，独立CI工具的天花板确实有限。CircleCI的估值从2021年后几乎没有增长，而Harness同期翻了近50%。这个对比很能说明问题：在DevOps市场，平台化是获得高估值的必要条件。

2.5 Jenkins：绕不开的“默认基线”

聊CI/CD不可能不聊Jenkins。Jenkins是这个领域的“前浪”——从Hudson时代算起，已经超过15年。至今，Jenkins仍然是全球使用最广泛的CI/CD工具。

技术路线对比

Jenkins是纯开源、插件驱动的CI/CD服务器。它的核心理念是“无限可扩展”——超过1800个插件覆盖了几乎所有想象得到的功能。用户自己部署Jenkins Master和Agent节点，完全掌控数据和执行环境。

Harness是纯SaaS（也支持自托管部署），AI驱动的自动化平台。它的核心理念是“智能自动化”——减少手动配置，用AI来做验证和决策。

两者的技术代差非常大。Jenkins像一个“工具车间”，给你一堆零件让你自己组装流水线；Harness像一个“自动化工厂”，预设了生产流程，你只需要告诉它目标和约束。

用户口碑与使用场景

Jenkins最大的优势是“免费”和“可控”。对于预算有限或者对数据主权要求高的团队，自建Jenkins是不二之选。Jenkins的灵活性也无可匹敌——几乎没有它做不了的事。

但Jenkins的痛点同样著名。首先是维护成本——Jenkins Master需要运维、插件需要更新、配置需要管理。其次是体验碎片化——每个团队的Jenkins用法都不一样，新人上手成本高。第三是缺乏现代功能——自动回滚、智能验证、成本可视化这些Harness的标配，Jenkins需要大量定制开发才能实现。

实际上，许多Harness的客户正是从Jenkins迁移过来的。他们不是不喜欢Jenkins的免费，而是无法忍受Jenkins的维护成本和体验问题。Harness的市场团队也把“替代Jenkins”作为核心卖点。

生态位分析

Jenkins占据的是“开源默认基线”。在任何一个CI/CD工具选型中，Jenkins都是对照组。新工具必须证明自己比Jenkins“足够好”才能说服用户切换。

但Jenkins本身不是Harness的直接商业竞争对手。Jenkins不收费，它的维护者是CloudBees（Jenkins的商业公司）以及广泛的社区。Harness的竞争逻辑是：把那些“受够了Jenkins”的企业用户，从自建方案迁移到SaaS平台。

CloudBees才是Jenkins生态中与Harness直接竞争的商业实体。CloudBees提供Jenkins的企业级版本和支持服务，定位与Harness有所重叠。但CloudBees的模式更像“Jenkins Plus”，而Harness是“平台原生”——底层架构、用户体验、AI能力都是从头设计的，不存在Jenkins的历史包袱。

2.6 横向总结：Harness的生态位与竞争态势

把四个竞品放在一起看，Harness的竞争位置就比较清楚了：

| 维度 | Harness | GitLab | GitHub Actions | CircleCI | Jenkins |

|------|---------|--------|----------------|----------|---------|

| 定位 | AI软件交付平台 | 完整DevOps平台 | CI/CD自动化引擎 | 云原生CI | 开源CI/CD服务器 |

| 起步领域 | CD | 代码托管 | CI | CI | CI |

| 部署方式 | SaaS/自托管 | SaaS/自托管 | SaaS（GitHub内） | SaaS/自托管 | 自托管 |

| AI能力 | 核心差异化（知识图谱+智能体） | AI功能补充 | Copilot集成 | 有限 | 几乎无 |

| 平台完整性 | 高（CI到运维） | 极高（全流程） | 中（偏CI） | 低（专注CI/CD） | 低（需插件拼装） |

| 定价模式 | 按模块/用量 | 按用户/月 | 按分钟/免费额度 | 按用户/用量 | 免费 |

| 目标用户 | 中大型企业 | 全部规模 | 全部规模 | 中小团队/开发者 | 全部规模 |

Harness的核心优势：

1. CD能力的绝对领先。Harness的持续交付模块是市场上最成熟、功能最完整的商业化CD解决方案，尤其在企业级复杂部署场景中几乎没有对手。

2. AI原生架构。软件交付知识图谱+AI智能体是Harness的护城河，其他对手在AI集成上更多是“外挂”模式。

3. FinOps融合。Harness是唯一把云成本管理深度整合进交付流程的平台，CCM模块是很多企业购买Harness的入口。

4. 平台开放性。不绑定特定代码仓库或云厂商，可以灵活集成到任何现有技术栈。

Harness的明显短板：

1. 缺乏代码托管。Harness没有自己的代码仓库，这意味着它永远处于下游位置，需要依赖GitHub、GitLab或Bitbucket的集成。

2. 开发者心智份额不足。GitLab和GitHub是开发者的“日常”，Harness是“上线时才会想起”的工具。用户使用频次和粘性天然有差距。

3. 定价偏高。Harness的企业级定位意味着价格高于大多数竞品，对中小团队不够友好。

4. 部分模块成熟度不足。根据Gartner Peer Insights的反馈，Harness的一些新模块（如IDP v1、Feature Flags）存在“未完全成熟就GA”的问题，导致客户体验波动。

Harness的机会：

1. AI代码生成带来的CD需求爆发。AI让代码产出速度暴增，但测试、部署、安全的瓶颈更突出了。这正是Harness的核心叙事——“AI速度悖论”的解法。

2. 企业从DIY Jenkins向商业平台迁移。大量企业仍然在用自建Jenkins，维护成本高、缺乏AI能力。这是Harness的增量市场。

3. DevSecOps融合。安全正在成为交付流程的有机组成部分，Harness通过Traceable和Qwiet AI的整合，在这个方向上领先竞品。

4. 国际市场扩张。Harness目前主要收入来自美国，欧洲和亚太市场潜力巨大。与Infosys的合作是第一步。

Harness的风险：

1. GitHub Actions和GitLab CI的持续进化。如果这两个平台在CD能力上追上来，Harness的核心优势会被削弱。

2. 云厂商的“自带CD”服务。AWS、Azure、GCP都在加强各自的DevOps服务，对于深度绑定单一云厂商的客户，可能选择云原生方案而非第三方平台。

3. IPO压力。55亿美元估值已经很高，公开市场是否能接受这个估值，取决于Harness能否保持50%+的增长率和持续改善利润率。

4. AI能力同质化。所有对手都在加AI功能，Harness的差异化能维持多久，是长期竞争力的问题。

三、横纵交汇：Harness的过去、现在与未来

纵向追溯了Harness八年来的每一步脚印，横向剖析了它和四个主要对手的竞合关系。现在，把两条线叠在一起，看看Harness到底站在什么位置，要往哪里走。

3.1 历史纵深的启示：平台化是刻在基因里的选择

回头看Harness的发展史，有一条主线非常清晰：从第一天起，它就不满足于做一个小而美的CD工具。

2017年成立时，市面上有Jenkins、有CircleCI、有Travis CI。如果Bansal只是想做一个“更好的CD工具”，技术上完全可行，商业上也能赚到钱。但他经历过AppDynamics从单点工具长成平台的全过程，知道单点工具的天花板在哪里——被大平台收购或者被降维打击。

所以他选择了一条更难的路：用八年时间，从CD开始，逐步扩展到CI、安全、成本管理、特性管理、可靠性工程……每一步都需要新的技术投入、新的市场开拓、新的组织能力。这个过程不是线性的，有并购（Drone、Armory、Qwiet AI）、有合并（Traceable）、有自研（CCM、IDP、Harness AI）。

平台化的代价是资源分散和整合复杂，但收益是估值和客户粘性。55亿美元的估值，不是“CD公司”能达到的数字。这是资本市场对“平台”的定价。

3.2 横向竞争的真相：Harness不是跟Jenkins打仗，是在跟GitLab和GitHub抢未来

很多人把Harness跟Jenkins对比，这是Harness营销的结果——把Jenkins当靶子，能最有效地说服客户迁移。但实际上，Jenkins根本不是Harness的真正对手。

真正的战争在Harness、GitLab、GitHub Actions三者之间。

GitLab的策略是“以代码仓库为据点，向下游扩张”。你在GitLab写代码，自然用GitLab CI，顺便用GitLab的安全扫描和项目管理。GitLab的护城河是代码——这是开发者每天都要打交道的东西。

GitHub Actions的策略是“以生态为据点，零摩擦渗透”。代码在GitHub上，workflow就地执行，不需要额外工具。GitHub的护城河是生态——全球最大的开发者社区。

Harness的策略是“以后置专业能力为据点，向上游整合”。不管代码在哪，只要部署环节足够专业，客户就会为这份专业性买单。Harness的护城河是深度——在CD这个垂直领域做到极致，然后横向扩展。

三种策略没有绝对的对错。GitLab和GitHub有“入口优势”，Harness有“深度优势”。问题是：入口优势能转化为深度优势吗？深度优势能抵御入口优势的侵蚀吗？

目前来看，GitLab和GitHub在CD上的投入还不够，给了Harness时间窗口。但窗口不会永远开着。Harness必须在这个窗口内，把“深度”变成“平台”——让客户因为离不开Harness的AI能力和知识图谱，而不是仅仅因为CD功能。

3.3 AI时代的变量：知识图谱是真正的护城河

2025年E轮融资时，Bansal反复强调“软件交付知识图谱”是Harness与其他AI平台的关键差异化因素。这不是营销话术，而是对竞争格局的深刻理解。

为什么？因为大模型时代，AI能力本身会迅速商品化。今天Harness说自己有AI智能体，明天GitLab也会发布AI功能，后天GitHub Copilot也能做部署建议。如果Harness的AI只是“调用大模型API做自动化”，差异化会很快消失。

但知识图谱不同。它不是“通用AI能力”，而是“领域专有知识的结构化沉淀”。Harness的AI智能体运行在客户自己的交付知识图谱之上——这个图谱包含了代码变更与服务的关系、部署历史与事故的关联、测试结果与生产质量的映射。这些数据不是通用大模型能提供的，必须在客户的生产环境中长期积累。

换句话说，Harness的AI护城河不是“算法”，是“数据+上下文”。这是比模型能力更持久的壁垒。

当然，前提是知识图谱确实能产生差异化的价值。如果Harness的AI智能体只是在做跟竞品一样的事情，那知识图谱就只是一个技术概念，不是商业壁垒。

3.4 最大的赌注：“AI速度悖论”叙事

Harness现在押注的核心叙事是“AI速度悖论”：AI让代码写得更快了，但代码之后的测试、部署、安全、合规流程跟不上，形成巨大瓶颈。Harness用AI来解决这个AI造成的瓶颈。

这个叙事非常有力，因为它切中了2026年企业软件工程的真实痛点。但这个叙事要成立，需要两个条件：

第一，企业真的在大规模采用AI生成代码。这个条件正在成为现实。GitHub Copilot、Cursor、Claude Code等工具的普及速度惊人。但企业级AI代码的“后处理”问题才刚刚暴露。Harness赌的是这个问题会越来越大。

第二，Harness的解决方案确实有效。这需要验证。Harness声称其AI智能体可以自动化测试生成、安全扫描、部署验证，但客户实际使用中能节省多少时间、减少多少事故，还需要更多公开案例和数据支撑。

如果这两个条件都成立，Harness有可能成为AI时代的“交付基础设施层”——就像AWS是计算基础设施层一样。如果只成立一个或都不成立，Harness仍然是一家优秀的DevOps平台公司，但估值叙事需要调整。

3.5 未来走向：三条可能的路

基于以上分析，Harness未来有三条可能的发展路径：

路径一：独立IPO，成为AI软件交付平台巨头（最可能）

Bansal已经明确表示IPO是目标。Harness目前的ARR（2.5亿+）、增长率（50%+）、客户质量（1000+企业）都符合IPO条件。时机取决于市场环境和公司准备情况。

上市后，Harness需要证明55亿美元估值的合理性。这需要持续的高增长、改善的利润率，以及在AI叙事上的落地成果。与Infosys的战略合作、国际市场的拓展、产品矩阵的交叉销售，都是支撑这条路径的要素。

路径二：被更大的平台收购（可能性中等）

历史上，ServiceNow、微软、谷歌等巨头都有收购DevOps平台的可能。Harness的AI能力、企业客户基础和知识图谱资产，对任何想要加强开发者工具链的巨头都有吸引力。

但Bansal刚刚经历AppDynamics被思科收购，他更可能想要一个自己掌控的IPO故事。除非价格极其诱人，或者市场环境急剧恶化，否则收购不太可能是首选。

路径三：持续私有化运营，等待更好时机（可能性较低）

Harness已经八岁了，估值55亿美元，股东期待退出。持续私有化运营不是不可能，但压力会越来越大。这条路径只有在市场极度不利、IPO窗口关闭的情况下才会成为主要选项。

3.6 结语：Harness到底意味着什么

理解Harness，不能只看它的产品和融资。要把它放在软件工程30年的演进脉络里看。

软件开发的前20年，主要矛盾是“怎么写代码”——从汇编到C到Java到Python，编程语言和框架的演进一直在降低编码的门槛。最近10年，主要矛盾变成了“怎么交付代码”——DevOps运动、CI/CD工具、容器和Kubernetes，都在解决代码从开发到生产的路径问题。

现在，AI正在把“怎么写代码”的门槛进一步打掉，但“怎么交付代码”的问题变得更加尖锐。写代码变快了，交付的瓶颈反而更突出。

Harness的核心命题就是：当代码生成不再是瓶颈，软件交付本身如何被重新定义？

它给出的答案是：用AI来管理AI生成的代码。不是让人类工程师去做更多的测试、更多的安全扫描、更多的部署验证，而是让AI智能体来处理这些“代码之后”的工作，人类负责设定策略和监督。

这是Harness Engineering最根本的野心——不是做一个更好的CD工具，而是重新定义软件工程中“人”和“机器”的分工。

它能不能做成，取决于产品能否兑现承诺、市场能否接受这个叙事、竞争对手能否迎头赶上。但无论结果如何，Harness已经在这个方向上走了足够远，远到任何讨论AI时代的软件工程，都无法绕过它的名字。

---

*报告完成日期：2026年4月15日*