为什么在自己动手前，必须先把市场看清

只要你认真想过“要不要自己做一套 Agent 系统”，调研就成了最便宜的防错手段。今天最常见的误判，往往是把本来处在不同层级的玩家混在一起比较，最后在错误的方向上重复投入。

Agent 赛道这两年已经明显分层。有的产品直接贴着真实工作流长，开始承接任务入口、后台执行、结果回流和人工审批；有的框架更像底座，重点放在 durable execution、checkpoint、workflow state 和恢复机制；还有一批工具虽然更轻，却因为足够顺手，正在改写开发者对 Agent 的默认想象。

这篇调研的价值，不在于把热门名字排成一列，而在于先把地图画清楚：谁在做系统，谁在做平台，谁在做工具；谁拿到入口，谁控制 runtime，谁塑造社区认知。只有把它们放在同一张图里，后面的产品判断才有意义。

先把系统、平台、工具三层拆开

更稳妥的切法，是先把市场拆成三层。

  • 系统层面向最终工作，负责任务入口、后台执行、结果回流、审查和人工接管界面。
  • 平台层面向构建者，负责状态管理、持久化、checkpoint、恢复、预算和工具编排。
  • 工具层面向局部效率，通常以 CLI、插件、开源代理或实验框架的形式出现。

这三层的差别，不在于有没有接入 LLM，而在于各自承担了哪一段责任。系统层要回答“任务最后有没有做完”，平台层要回答“这套东西能不能稳稳跑下去”，工具层要回答“某个动作能不能更快、更顺手”。很多产品在演示里看着相似，一旦按责任拆开，位置其实很清楚。

  • 系统层代表：Codex app、GitHub Copilot coding agent。

主要价值：任务委派、后台执行、回流审查、人机协作。 主要短板：可移植性偏弱，往往更依赖闭源生态。

  • 平台层代表：LangGraph、Microsoft Agent Framework、AWS Strands、OpenAI Agents SDK。

主要价值：状态、耐久执行、工具编排、恢复机制。 主要短板：离终端工作台较远，分发能力通常不强。

  • 工具层代表：OpenHands、Cline、CrewAI、AutoGen。

主要价值：快速上手、社区实验、局部工作流提效。 主要短板：治理、审计和团队一致性往往更弱。

第一类玩家：已经很像工作系统的产品，优势在分发和工作流整合

这一层里最值得看的，是 OpenAI 的 Codex app、GitHub 的 Copilot coding agent 与 Agent HQ，以及 Anthropic 把 Claude Code 接进 GitHub Actions 的路线。它们有一个很关键的共同点：都在把 Agent 从“会回答问题的助手”推向“能接任务、能后台执行、能把结果带回审核流的工作单元”。

OpenAI 对 Codex app 的定义，已经很接近 cloud-based engineering workbench：并行 agent、skills、automations、sandbox 和任务管理一起出现，说明它要解决的是协作面，而不只是对话面。GitHub 的路线更直接，coding agent 接 issue、后台工作、回 draft PR，Agent HQ 再把多个 agent 入口和结果收拢进同一个协作空间。Anthropic 则沿着仓库工作流切入，把 Claude Code 接进 GitHub Actions，让 agent 的执行天然附着在 CI/CD 和 repo 审核流上。

这类系统最强的地方，是它们离真实工作足够近。它们掌握任务入口、代码上下文、审查界面、身份权限和协作对象，因此天然带着 workflow gravity。用户不需要先学一套新的 runtime，再自己拼界面；任务一旦被委派，agent 就能直接在现有工作语境里跑起来。

  • 系统层玩家最强的资产在分发和默认入口，开源社区热度通常不是决定因素。
  • 谁离 issue、PR、review、审批流最近，谁就更容易先形成真实使用习惯。
  • 这类产品已经部分具备“Agent Operating System”的外壳，但底座未必最开放。

第二类玩家：真正决定长任务上限的平台，优势在 durability 和编排

如果说系统层在回答“怎样把 Agent 变成产品”，平台层就在回答一个更硬的问题：任务为什么能稳定地跑下去。这里最值得重视的是 LangGraph、Microsoft Agent Framework、AWS Strands Agents 和 OpenAI Agents SDK。它们各自风格不同，但都在推动行业从“单次调用 LLM”走向“持续运行的 agent runtime”。

LangGraph 的价值，在于它很早就把 persistence、durable execution、human-in-the-loop 和 graph state 当作一等能力来做。Microsoft Agent Framework 的重点更偏企业集成和 workflow 编排。AWS Strands 强调多 agent 协作、MCP 整合和企业生产系统语境。OpenAI Agents SDK 则更轻，开发者更容易上手，适合快速构建 tool-using agent；如果看超长任务的治理能力，它目前更像一块好用的底板，离完整耐久平台还有一段距离。

平台层真正决定的是终局产品最难替代的那部分能力：状态、恢复、重试、并发、事件边界和工具协议。这些地方做扎实，系统层可以继续迭代 UI 和任务入口；这些地方一旦松，前台再漂亮，也只是包在一个不够稳的后端外面。

  • 平台层真正决定的是平均可靠性，不是一场 demo 的峰值表现。
  • 终局产品必须有平台层能力，但平台层本身很难自动长成终端工作系统。
  • 未来真正的壁垒很可能落在 durability + governance，很难靠几套 prompt 模板建立。

第三类玩家：社区最热的工具层，优势在实验速度和生态外溢

如果只看社区热度，开源工具层反而是最热闹的。OpenHands、Cline、CrewAI、AutoGen 以及 OpenAI Agents SDK 这类项目，在 GitHub 上都已经积累了相当高的 stars。它们未必最接近终局产品，却往往最先影响开发者的工作方式和行业叙事。

截至 2026 年 3 月 13 日，我查询 GitHub 仓库快照时看到的星标数量大致是这样：OpenHands 约 6.9 万，Cline 约 5.89 万，AutoGen 约 5.56 万，CrewAI 约 4.59 万，LangGraph 约 2.63 万，OpenAI Agents SDK 约 1.99 万。这个数字当然不等于企业采用率，也不等于收入能力，但它非常适合观察哪一类抽象正在被开发者大量试用、 fork、讨论和二次封装。

工具层的真正价值，在于它们通常比系统层更开放，比平台层更容易上手，因此特别适合承接实验、扩散经验和形成社区共识。很多后来会被终局产品吸收的交互习惯，最早往往都是在这一层被试出来的。它们的问题也很直接：越靠近工具层，越容易让人误以为“装一个 agent 就够了”，从而忽视状态治理、审批边界和组织协议这些更难也更贵的部分。

GitHub 热度快照（2026-03-13）大致如下：

  • OpenHands：69,036 stars
  • Cline：58,945 stars
  • AutoGen：55,558 stars
  • CrewAI：45,946 stars
  • LangGraph：26,301 stars
  • OpenAI Agents SDK：19,954 stars

流行度要分三种看：社区热度、分发强度和组织渗透

一谈到“谁更流行”，讨论很容易失真，因为这里至少混着三种完全不同的流行度。第一种是社区热度，最容易被 GitHub stars、教程数量、issue 活跃度和二次封装放大；第二种是分发强度，也就是产品是否卡住天然入口，例如 GitHub、OpenAI 工作台或企业工作流；第三种才是组织渗透，看它能否真正进入团队日常工作，也不只是长期停在试用和演示阶段。

这三者里，社区热度最显眼，却离真实采用还有一段距离；分发强度常常决定谁先跑起来；组织渗透最慢，但对终局价值最重。拆开以后，很多表面上的“谁会赢”就不那么迷惑了。一个项目可以非常热，却仍停留在工具层；一个系统可以不算热闹，却已经在组织里变成基础设施。

面向终局产品，今天每一类玩家各自最强的优势是什么

如果把问题换成“谁最有机会长成未来更完整的 Agent OS”，三层玩家其实各有自己的起手优势。系统层最强的是工作流黏性：谁已经占住 issue、PR、审批、团队权限和异步任务入口，谁就更容易把 agent 变成组织默认工作方式。平台层最强的是运行基础设施：谁更早把状态、恢复、审计和预算做扎实，谁就更有机会成为别人的底座。工具层最强的是认知扩散和实验速度：谁更快成为开发者的默认玩具和默认扩展点，谁就更容易在未来生态里形成事实标准。

从这个角度看，GitHub 和 OpenAI 这样的系统层玩家在争“默认入口”；LangGraph、Microsoft Agent Framework、AWS Strands 这类平台在争“默认 runtime”；OpenHands、Cline、AutoGen、CrewAI 这类工具在争“默认心智与默认接口习惯”。真正的终局产品，大概率会由某一层先拿到优势，再逐步补齐另外两层。

  • 系统层优势：离工作入口近，最容易形成组织级工作流。
  • 平台层优势：离可靠性核心近，最容易沉淀成不可替代底座。
  • 工具层优势：离社区创新近，最容易形成事实上的接口与习惯。

但今天还没有谁已经是终局产品，缺口依然非常明显

如果一定要给一个干脆的结论，我会说：截至 2026 年 3 月，市场上已经有不少“半套系统”，但还没有谁把终局产品需要的能力完整吃下。系统层离工作入口最近，却往往不够开放；平台层 runtime 很强，却离最终用户太远；工具层迭代极快，却常常缺审批、预算、审计、权限和跨团队治理这些真正决定能否进生产的东西。

这也解释了为什么“团队规则 + 系统”会越来越重要。长时间 Agent 靠的不只是多加几个提示词、再接几把工具，它最终要同时容纳运行时能力、组织规则、风险边界和结果审查。缺哪一层，系统都可能看起来聪明，但还不够可靠。

终局产品至少要同时回答五个问题：

1. 任务如何定义和拆解。 2. 状态如何跨 session 持久化。 3. 失败如何恢复和回滚。 4. 人如何随时接管和审批。 5. 成本、权限和审计如何持续可控。

我对未来终局产品的判断：它更接近 Agent Operating System

我越来越倾向于把未来的终局产品理解成一种 Agent Operating System。这里说的 OS，并非字面意义上的操作系统，更像一层新的工作操作层：上面承接任务、审批、协作和异步回报，下面承接 runtime、checkpoint、tooling、state 和 recovery，中间再把团队规则写进系统。

这意味着胜负不会只靠模型更强来决定。更关键的是四件事：系统能不能长时间稳定工作，团队规则能不能被正式固化，外部工具和 repo 工作流能不能顺滑接入，成本与风险控制能不能从补丁变成默认能力。谁能把这条链打通，谁才更接近终局。

如果你要自己做，最值得切入的地方在补缺口

站在创业或产品设计角度，最该回避的事，是再包一层没有明确系统边界的新 agent 外壳。更有价值的切入方式，是看三层玩家之间真正还空着什么：系统层缺更强的可移植 runtime 和规则可编程性；平台层缺真正面向团队工作的产品化界面；工具层缺审计、审批、预算、权限和企业一致性。

所以如果你真要做，我更建议把自己定义成“Agent Ops System”或“Long-running Agent Workbench”，别把自己放进一个泛泛的 AI Agent 平台标签里。前者是在补系统缺口，后者很容易落进“什么都做一点、什么都不形成壁垒”的坑里。对 Freelemon 这种长期关注系统设计的语境来说，这也是更值得追的方向：重点不在追着下一个模型跑，而在定义下一代工作系统该长成什么样。

  • 不要重复造一个没有治理能力的 agent 壳。
  • 优先找系统层、平台层和工具层之间真正没人补好的缝。
  • 把“团队如何工作”写进产品，比把“模型有多强”写进广告更重要。

最后压缩成八条结论

如果把整篇调研再压缩一次，我会留下下面这组结论。它们既可以作为产品立项前的判断框架，也可以作为你后面继续深挖单个赛道时的检验表。

  • 2026 年已经存在不少局部成型的 Agent 系统，但没有谁已经完成终局收敛。
  • 系统层产品最强的是入口和工作流，平台层最强的是 durability，工具层最强的是社区扩散。
  • GitHub stars 能看出社区热度，但不能直接等同于企业采用和终局优势。
  • 闭源工作系统很可能先赢分发，开源工具和平台更可能先赢生态心智。
  • 未来真正的壁垒不会只在模型，更会落在 runtime、team protocol、approval 和 governance。
  • 长时间 Agent 的终局产品更接近 Agent Operating System，不会只是一个更聪明的聊天框。
  • 如果你要自己做，最好从“补缺口”出发，少去重复再做一个通用 agent。
  • 做这类产品之前，严肃调研是避免走弯路的最低成本方式。

更新附注

  • 版本：v1.1

更新日期：2026-03-31 更新原因：重写开头、三层分法、工具层热度段、终局产品判断与收束段，减少模板化对比句和报告腔，让正文从“赛道地图”更自然地推进到“产品判断”。