Agent 框架/Harness 的竞争壁垒深度分析

TL;DR

Agent 框架（harness/编排层）本身几乎没有技术壁垒——代码可复制、模式公开、模型可替换。但"把 Agent 做好"存在五个层次的隐性壁垒：Eval 数据飞轮、Tool 集成深度、领域 Workflow 编码、可靠性工程积累、生态网络效应。更关键的是，随着模型厂商（OpenAI、Anthropic、Google）纷纷内建 Agent 能力，中间框架层正面临"上下夹击"的结构性压力。真正的壁垒不在框架代码里，而在于对失败模式的深度理解和用户场景的复合积累。

一、核心问题拆解

1.1 为什么会有"没壁垒"的直觉？

这个直觉来自三个显而易见的事实：

1. 模型层趋同：所有人调同一批 API（GPT-4o, Claude, Gemini），底层能力是"租来的"
2. 架构模式公开：ReAct、Plan-and-Execute、Reflection、Multi-Agent 这些都是公开论文，实现代码通常不超过几百行
3. 开源框架泛滥：LangChain、CrewAI、AutoGen、MetaGPT、dify、Coze、Smolagents… 互相"借鉴"极其容易

a16z 在其经典分析 Who Owns the Generative AI Platform 中直言：

"There don't appear, today, to be any systemic moats in generative AI."（当前在生成式 AI 中，似乎不存在任何系统性护城河。）

应用层公司"rely on similar underlying AI models"（依赖相似的底层模型），导致差异化薄弱、毛利被压缩（低至 50-60%）、缺乏明显的网络效应。

1.2 但"没壁垒"不等于"没机会"

Sequoia 在 AI's $600B Question 中给出了一个看似矛盾、实则深刻的判断：

• GPU 基础设施层正在走向商品化——"GPU computing is increasingly turning into a commodity"
• 但应用层的长期价值反而更大——"Company builders focused on delivering value to end users will be rewarded handsomely"
• 关键在于：降低的推理成本 + 累积的实验经验 会成为应用层创业者的复利优势

这意味着：框架层虽然不是壁垒的来源，但它可以是积累壁垒的工具。

二、Agent 框架层的五层壁垒光谱

我将壁垒从弱到强分为五个层次：

🟡 Level 1：代码与架构模式（壁垒极弱 ⭐）

来自 Latent Space 的关键洞察：OpenHands（原 OpenDevin）仅使用 5-6 个工具（bash、Jupyter、文件编辑、搜索替换、浏览器），就能在 SWE-Bench 上达到顶级表现。这说明工具数量和框架复杂度并不是竞争力的来源。

Graham Neubig（OpenHands 核心作者）甚至明确反对多 Agent 复杂性：

"Multi-agent systems get stuck when things deviate from your plan."（多 Agent 系统在计划偏离时容易卡住。）

他认为，框架复杂度与鲁棒性负相关——一个好的单 Agent + 好的模型，往往胜过复杂的多 Agent 编排。

🟡 Level 2：Prompt 工程体系（壁垒较弱 ⭐⭐）

精心调优的 system prompt、few-shot examples、角色设定确实能带来显著的短期质量差异。但这个壁垒在快速贬值：

• 模型越强，prompt 的边际影响越小
• Prompt 可以被逆向工程（prompt injection/extraction）
• 行业最佳实践快速扩散

但有一个例外：系统化的 prompt 管理体系（版本控制、A/B 测试、回归测试、与 Eval 联动的自动优化）本身构成一定壁垒——不是因为 prompt 内容不可复制，而是因为持续迭代的流程不可复制。

🟠 Level 3：Tool 集成深度 + 领域 Workflow 编码（中等壁垒 ⭐⭐⭐）

这是 Cursor、Devin 等公司实际赖以立足的层次。

Cursor 案例分析：

Cursor 的壁垒不是"用了 Claude"或"用了 GPT-4"，而是对开发者工作流的深度理解 + 大量 edge case 的处理。这些是"脏活累活"，但恰恰是别人难以快速复制的。

Harvey AI（法律）案例分析：

类似地，Harvey 的壁垒不在于调用了什么模型，而在于：

• 法律文书的格式化规则
• 不同司法管辖区的合规要求
• 律师工作流的深度嵌入
• 经过法律专家验证的 Eval 数据集

通用规律：在特定领域，知道"先做什么后做什么"比"怎么调用 LLM"重要得多。

🟠 Level 4：Eval 飞轮 + 可靠性工程（较强壁垒 ⭐⭐⭐⭐）

这是被严重低估的壁垒来源。

Eval 数据飞轮

用户使用 → 发现失败模式 → 建立 Eval Case → 修复问题 → 质量提升 → 更多用户 → …


能搭一个 multi-agent 系统不难，知道它什么时候好、什么时候坏才是壁垒：

• 你需要大量的 domain-specific eval dataset
• 你需要 fine-grained 的 failure taxonomy（"Agent 在第三步选错了工具"这种级别）
• 这些数据是随着实际部署积累的，不是写代码能解决的

来自 Latent Space 的数据佐证：OpenHands 的 Agent Workflow Memory 论文显示，"agents learning from past successes" 带来了 22.5% 的准确率提升。这种经验累积形成的知识库就是飞轮。

可靠性工程

Demo 能跑 ≠ 生产能用。中间的鸿沟是：

这些是工程经验的积累，每个坑都要踩过才知道。Graham Neubig 提到 Claude 的优势就在于 error recovery——"它会说'嗯，让我试试另一种方法'"，而 GPT-4o "没有很好的 error recovery 能力，会卡在重复相同的动作上"。这种洞察不是读论文能获得的。

🔴 Level 5：生态网络效应 + 数据飞轮（最强壁垒 ⭐⭐⭐⭐⭐）

如果能走到这一步，壁垒是真实且持久的。但很少有 Agent 框架真正建立起来。

生态网络效应

MCP（Model Context Protocol）案例：

Anthropic 推出的 MCP 试图成为"Agent 世界的 USB 协议"——标准化 Agent 与工具的连接方式。它的潜在网络效应是：

更多工具提供者 → MCP server 更丰富 → 更多 Agent 平台采用 MCP → 更多工具提供者 → …


但 Graham Neubig 对此持怀疑态度：

"We already have an API for GitHub, so why do we need an MCP for GitHub?"（我们已经有 GitHub API 了，为什么还需要 GitHub 的 MCP？）

同时，Google 在 2025 年推出了竞争性的 A2A（Agent-to-Agent）协议，定位为"agent 之间的通信标准"。两个标准之争本身说明了一个事实：标准之战还远未结束，早期的网络效应可能被后来的竞争者打破。
数据飞轮
真正的数据飞轮需要：


用户规模：足够多的真实场景产生数据


反馈闭环：用户行为能被有效捕获和利用


模型改进：数据能转化为可测量的质量提升


闭环速度：从用户反馈到模型改进的周期足够短


目前大多数 Agent 框架还停留在"开源 + 社区 + Star 数"的阶段，没有真正建立数据飞轮。

三、"上下夹击"：中间框架层的结构性压力
3.1 来自上方（模型厂商）的压力
模型厂商正在系统性地"侵蚀"框架层的价值空间：

Neubig 预测："Every large LM trainer will be focusing on training models as agents"（每个大模型训练者都会专注于把模型训练成 Agent）。

这意味着：当模型本身就是好 Agent 时，编排框架的价值大幅缩水。

3.2 来自下方（直接 SDK 使用）的压力

越来越多的开发者选择"绕过框架，直接调 API"：

LangChain 被大量批评为"thin wrapper"——给简单的 API 调用包了过多抽象层，增加了调试难度，频繁的 breaking changes 让生产环境用户苦不堪言。

替代方案包括：

• 直接使用 OpenAI/Anthropic SDK
• 轻量级库（Pydantic AI、Instructor）
• 领域特化框架（Haystack for RAG、DSPy for 结构化优化）

3.3 中间层的生存策略

面对上下夹击，框架层公司有几条可能的出路：

1. 变成平台：从代码框架升级为完整平台（Dify、Coze 的路线），增加 UI、协作、部署等全栈能力
2. 纵向深耕：成为某个垂直领域的"最优 Agent 方案"（Harvey for 法律、Cognition for 编程）
3. 成为基础设施：做 Eval、Observability、Guardrails（LangSmith、Braintrust、AgentOps）——但这些也面临开源替代（Langfuse）和模型厂商内建的风险
4. 成为标准制定者：MCP 如果成功成为事实标准，Anthropic 将获得生态控制权——但需要避免被 Google A2A 等竞争者分化

四、历史类比：哪些教训可以借鉴？

4.1 Web 框架之战（Rails / Django / Express / Spring）

Web 框架层同样是"没有技术壁垒"的——任何人都能写一个 HTTP 框架。但最终的赢家通过以下方式建立了持久的影响力：

• 生态系统（gem、pip packages、npm modules）
• 开发者心智（"Ruby on Rails 让初创公司更快"）
• 配套工具链（Heroku + Rails，Vercel + Next.js）

教训：框架本身不是壁垒，围绕框架的生态才是。

4.2 云计算之战（AWS vs GCP vs Azure）

早期人们也认为云计算"没壁垒"——都是虚拟机、存储、网络。但 AWS 通过以下方式建立了持久优势：

• 先发规模效应：更多用户 → 更低单位成本 → 更多用户
• 服务捆绑：200+ 服务形成的生态绑定
• 迁移成本：从 AWS 迁走需要重写大量代码

教训：规模 + 服务捆绑 + 迁移成本 可以在看似无壁垒的技术层构建强大护城河。

4.3 推荐系统之战（字节跳动 vs 其他短视频平台）

推荐算法的论文都是公开的，但字节跳动的壁垒在于：

• 反馈循环的速度和精度：用户行为数据 → 模型更新的闭环极快
• 海量用户产生的数据飞轮
• 组织能力：大规模 A/B 实验基础设施

教训：飞轮的转速和规模，远比算法本身重要。

五、核心结论与战略建议

5.1 壁垒矩阵

5.2 对不同角色的启示

如果你在做 Agent 框架/平台：

1. 不要在框架代码上寻找壁垒——它不存在
2. 核心投入应该在 Eval 体系上——知道什么时候好、什么时候坏，比写更多代码重要 10 倍
3. 选择一个领域深扎——通用 Agent 框架没壁垒，垂直领域的最优 Agent 方案有壁垒
4. 抢占标准制定权——MCP/A2A 之争说明，谁定义了 Agent 的通信协议，谁就有生态控制权
5. 警惕模型厂商的"降维打击"——当 OpenAI 自己出 Agents SDK，中间层的价值就被压缩了

如果你在做垂直 Agent 应用：

1. 壁垒在于对用户场景的理解深度——不是技术
2. 尽快建立 Eval 飞轮——用真实用户的失败案例驱动改进
3. 深度嵌入用户工作流——创造切换成本
4. 保持模型层的灵活性——不要绑死一个模型，因为最强模型在持续变化

如果你在评估投资机会：

1. 不投纯框架层——除非它已经在向平台演进
2. 看 Eval 数据的积累量——这是判断"飞轮有没有转起来"的核心指标
3. 看用户留存和 NPS——如果用户不粘，说明壁垒是假的
4. 看团队的领域知识深度——纯技术团队 vs 领域+技术团队，后者更有壁垒

5.3 最终判断

Agent 框架/Harness 本身确实没有独特壁垒。

但这不意味着 Agent 领域没有机会——恰恰相反。真正的壁垒藏在"冰山水下"的部分：

冰山水上（可见、可复制）：
  - 框架代码
  - 架构模式
  - Prompt 模板

冰山水下（不可见、难复制）：
  - 1000+ 个 edge case 的处理经验
  - 领域专家验证过的 Eval 数据集
  - 在生产环境踩过的可靠性工程坑
  - 用户使用数据驱动的持续优化
  - 深度嵌入用户工作流创造的切换成本


借用一个类比：壁垒不在"造锤子"，在"知道往哪里钉钉子、钉多深、钉歪了怎么修"。 而这些"知道"，需要时间、需要真实用户、需要持续迭代来积累。它们不写在任何一行代码里，但它们是真实的竞争优势。