为什么在自己动手之前，必须先做一轮严肃调研

如果你看完前一篇关于长时间 Agent 的文章，第一反应是“这最后是不是应该做成一个系统”，那直觉其实是对的。但真正危险的地方也恰恰在这里：一旦把问题定义成系统问题，调研就不能只停留在模型能力或少数 demo 成功案例上，而必须看版图、看分层、看生态、看社区接受度，还要看不同玩家各自站在什么起点上。

今天的市场已经不再是“只有几个 agent demo”的阶段，而是出现了明显分层。有些产品已经长得很像工作系统，开始承接任务委派、后台执行、PR 回流和人类审批；有些框架没有终端产品外观，却在 durability、checkpoint、workflow state 这些核心底座上占住了位置；还有一些工具虽然不具备完整系统形态，却因为安装简单、社区活跃、迭代极快，正在影响开发者对 Agent 的默认想象。

所以严肃调研的意义，不是为了列一个产品清单，而是为了避免犯两个最常见的错误：第一，把分发强的产品误认为技术底座最强；第二，把社区热度高的工具误认为最接近终局产品。真正有价值的判断，必须把系统形态、平台能力、工具生态和社区流行度放在同一张图里一起看。

先把系统、平台、工具三层分开，不然后面的讨论一定会乱

我更推荐先把这个市场拆成三层。第一层是系统，也就是用户可以直接拿来工作的 Agent workbench 或任务系统，典型形态是任务入口、后台执行、结果回流、审查与接管界面。第二层是平台，也就是工程团队用来搭自己系统的 runtime 和 workflow infrastructure，它们负责状态管理、持久化、checkpoint、工具调用、恢复和预算控制。第三层是工具，通常更轻、更贴近开发者单点需求，可能是开源 coding agent、CLI、IDE 插件或多 agent 实验框架。

这三层最大的区别，不在于是否调用 LLM，而在于对“工作责任”的承接深度。系统承接的是任务完成责任，平台承接的是运行可靠性责任，工具承接的是局部效率责任。很多产品看起来都在做 agent，但一旦放回这套分层里，它们的定位就会立刻清晰很多。

层级 | 代表形态 | 主要解决什么 | 典型短板
系统 | 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 仅仅理解成“在本地回答问题的助手”，而是在努力把任务委派、异步执行、结果回流和人类 review 变成标准工作流。

OpenAI 官方对 Codex app 的定义，本质上已经接近一个 cloud-based engineering workbench：支持并行 agent、skills、automations、sandbox 和任务管理。这说明 OpenAI 自己也不再把 agent 当作单次问答，而是在做一个带运行时和协作面的工作台。GitHub 的路线更直接：coding agent 可以接 issue、后台工作并回 draft PR，Agent HQ 进一步把多个 agent 入口、会话和工作结果收拢到同一个协作空间里。Anthropic 则沿着仓库工作流切入，把 Claude Code 放进 GitHub Actions 里，让 agent 运行直接附着在 CI/CD 与 repo 审核流上。

这类系统当前最强的地方，不是“底层一定最先进”，而是它们离真实工作最近。它们掌握任务入口、代码上下文、审查界面、身份权限和协作对象，因此天然拥有 workflow gravity。用户不需要先学一套新的 agent runtime，再自己拼 UI；只要任务被委派，agent 就能在现有的 GitHub 或工作台语境里运转。

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

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

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

LangGraph 之所以重要，不是因为它最会讲 agent，而是因为它很早就把 persistence、durable execution、human-in-the-loop 和 graph state 放成了一等能力。Microsoft Agent Framework 的价值也类似，只是更偏企业集成和 workflow 编排。AWS Strands 明确强调多 agent 协作、MCP 整合和企业级生产系统语境。OpenAI Agents SDK 则更偏轻量、开发者友好的 agent abstraction，利于快速构建 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 就能解决”，而弱化掉状态治理、审批边界和组织协议这些真正难的部分。

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 活跃度、教程数量、YouTube 内容和二次封装数量观察。第二种是分发强度，也就是产品是否占住一个天然入口，比如 GitHub 本身、OpenAI 工作台、Anthropic 的 repo 自动化入口。第三种是组织渗透，指的是它是否真正进入团队日常工作流程，而不是停留在黑客松和技术展示里。

这三种流行度里，社区热度最容易看到，却未必最接近收入和组织采用；分发强度往往决定短中期谁先跑出来；组织渗透则最慢，但对终局产品价值最大。GitHub Copilot coding agent 和 Agent HQ 这类产品的优势，更多来自分发与组织渗透潜力；OpenHands、Cline 这类项目的优势，更多来自社区热度和实验扩散速度；LangGraph、Microsoft Agent Framework 这类平台的优势，则体现在系统设计者对它们的依赖深度，而不是普通用户能否记住它们的名字。

一旦把这三种流行度拆开看，很多“谁会赢”的讨论就不会再那么表面。终局产品不太可能只靠 stars 赢，也不太可能只靠入口赢，更不可能只靠框架优雅赢。它需要同时跨过至少两道门槛：一是系统可靠性足够强，二是工作入口足够近。

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

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

从这个角度看，GitHub 和 OpenAI 这样的系统层玩家更像在争“默认入口”；LangGraph、Microsoft Agent Framework、AWS Strands 这类平台更像在争“默认 runtime”；OpenHands、Cline、AutoGen、CrewAI 这类工具更像在争“默认心智与默认接口习惯”。真正的终局产品，很可能不是某一层单独胜出，而是某一层先拿到优势后，逐步补齐另外两层。

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

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

如果必须给一个直白结论，我会说：截至 2026 年 3 月 13 日，市场上已经有很多“半套系统”，但还没有哪一家把终局产品需要的五层能力真正吃全。系统层往往工作流和入口很强，但可移植性、开放协议和外部生态兼容性不够；平台层往往 runtime 很强，但离最终用户太远，默认不会自动长出好产品；工具层则迭代很快、社区很旺，但通常缺少企业真正关心的审批、预算、审计、权限和跨团队治理。

这也是为什么你前面那篇长文最后会自然落到“团队规则 + 系统”这个判断上。因为今天没有任何一类玩家，能单靠一个软件壳就解决长时间 Agent 的全部问题。要让系统真正进入生产，就必须把运行时能力、团队协议、风险门槛和结果审查一起设计进去。

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

我对未来终局产品的判断：它更像 Agent Operating System，而不是超级聊天框

我现在越来越倾向于把未来的终局产品理解成一种 Agent Operating System。这里的“OS”不是字面意义上的操作系统，而是说它会像一个工作操作层：上面承接任务、审批、协作、异步通知和晨报，下面承接 runtime、checkpoint、tooling、state 和 recovery，中间再通过 team protocol 把规则固化进系统。

这意味着终局产品不会只靠更强的模型赢。它真正的差异，会来自四件事：第一，能不能让 agent 长时间稳定工作；第二，能不能让团队把自己的规则写进系统；第三，能不能把外部工具和 repo 工作流接得非常顺；第四，能不能把成本和风险控制做成默认能力，而不是事后补丁。

如果这个判断成立，那么未来最有竞争力的产品路径，不是只做前台，也不是只做框架，而是想办法把 workbench、runtime 和 team protocol 串成一条完整链路。谁能做到这一点，谁才最像真正的终局形态。

如果你要自己做，最值得切入的不是“再做一个 Agent”，而是补缺口

站在创业或产品设计角度，最不值得做的事情，是再做一个没有明显系统边界的新 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”出发。
• 做这类产品之前，严肃调研不是可选项，而是避免走弯路的最低成本方式。