同一天把四个开源Agent框架的公开字段拉了一遍，最贵的那格不在功能表上

摘要：选开源智能体框架，功能对比表是最没用的那张表——四个主流框架理论上都能搭多智能体系统，差别只在胶水代码由谁写。真正会持续付账的是维护那一栏，而它在功能表上完全不出现。同一天把四个仓库的公开字段拉了一遍，最刺眼的两件事都跟功能无关：其中一个已经三个半月没有任何推送，另外三个当天都在推；还有一个的许可证栏挂着一个连开源促进会都不认作软件许可证的内容授权协议，而它真正的代码授权藏在同目录下的第二个文件里，接口从来不报。这篇给出四个公开字段的读法与派生比值、自建与托管各自省掉和卖掉了什么、出口成本怎么在选型阶段就先量一遍，以及一份三十分钟能跑完的自查。

先说结论：这类框架的选型，功能对比表是价值最低的那份材料。

原因很朴素——四个主流框架理论上都能搭出多智能体系统，能力上没有谁做不到谁能做的事。真正的差别只有一句话：胶水代码由谁写。是框架替你写好了，还是留给你写。

而这句话里藏着一笔功能表上完全不显示的账：框架替你写好的那部分，它会一直替你维护下去吗？

为什么框架功能对比表基本帮不上忙？

把智能体框架的成本拆开，是三笔性质完全不同的钱。

选型的时候，人的注意力几乎全在第一栏，因为它最容易感知——文档好不好读、上手要几天、示例能不能跑通。第二栏还算被讨论。第三栏基本没人提，可它是唯一一笔你停止使用之前不会停止支付的钱。

维护成本具体是什么？它是接口变更之后你要改的那些地方、依赖冲突要花的那半天、某个行为悄悄变了导致的线上事故、以及最贵的那一种——项目不动了，而你的需求还在动。

所以该看的是仓库，不是官网

官网负责说服你，仓库负责暴露真相。而且暴露的方式相当直接：所有需要的字段都在公开接口里，一条命令就能全拿到，不需要注册、不需要读源码。

这套读法站内那篇讲从公开字段判断一个开源项目值不值得把工作流搬上去的文章展开过一遍，那篇是方法，这篇是把方法用在同一个赛道的四个具体对象上，看它能不能真的分出高下。

同一天把四个仓库的字段拉一遍，看到了什么？

下面这组数字全部取自2026年7月30日的公开接口，同一天、同一次拉取，避免时间错位。

这张表里有两处一眼就该停下来的地方，而且两处都跟功能无关。

第一处是最后推送那一栏：AutoGen停在2026年4月15日，到拉取那天已经三个半月没有任何推送；另外三个都是当天在推。

第二处是许可证那一栏，下一节单独讲，因为它比看上去复杂。

把绝对数换成比值，排序会变

星标数字差得很大，直接比没有意义。换成比值之后，四个项目的画像才分得开：

这三列各说一件事：

• 未关问题占星标比大致反映“问题堆积速度相对社区规模”。四个项目都在1.3%到1.7%之间，差别不大——也就是说单看这一列，分不出高下。这本身是个有用的结论：不是每个指标都有区分度，用一堆没区分度的指标凑一张打分表，只会把噪声放大。
• 分叉占星标比反映“有多少人不只是收藏，而是真动手了”。OpenClaw的21%明显高出一截，符合它的定位——它更像一个人人都要改成自己那份的个人助理，而不是一个直接引入的库。
• 订阅占星标比是四列里最容易被忽略、也最诚实的一个。订阅意味着愿意接收这个仓库的每一条通知，是成本最高的一种关注。AutoGen在这一列反而最高，说明它的关注者里“真的在用、需要跟进变更”的比例不低——这跟它三个半月没推送形成了一个不太妙的对照：一群在等的人，和一个停着的仓库。

一次被这几个字段拦下来的选型

去年底有个做工业配件的外贸站找我看方案，他们要搭一套自动询盘处理：读进客户邮件、抽出型号和数量、去库存系统查、生成报价草稿、转人工确认。技术负责人已经选好了框架，理由是社区活跃、示例最多、星标数最高。

我照上面这套字段拉了一遍，只花了不到十分钟，看到两件事。

第一件，那个项目最后一次推送在两个多月前。第二件，最新的十几条未关问题里有四条在问同一件事——某个依赖升级之后导入报错，其中最早那条挂了三十多天没有维护者回复，底下跟了七八个“同样问题”。

这两件事单独看都不致命。合起来看，含义是：这个项目正处在一个已知的破损状态里，而修它的人现在不在。

他们的团队一共三个人，没有一个能在报价流程挂掉的时候去读框架源码。这就是那条“最后推送要和你自己的节奏比”的判据发挥作用的地方——对一个每周都要跟客户交付的团队，两个月的静默加一个未修的导入错误，等于把风险全接到了自己这边。

最后的方案是换成另一个当时还在正常推送的框架，多花了大概三天的迁移工作量。三个月后回头看，那三天买回来的是至少两次不用自己排查的上游修复。

这件事我印象深，是因为整个判断没有涉及任何一条功能对比。两个人对着功能表能吵一下午，对着最后推送时间和一条挂了三十天的问题，五分钟就能达成一致。

那个显示成内容许可证的软件框架

这是我这一轮核材料时挖到的最硬的一处，值得单独一节。

AutoGen的接口返回的许可证标识符是CC-BY-4.0，也就是知识共享署名4.0国际许可协议。这是一个内容授权协议——用来授权文章、图片、音乐、数据集的那一类，不是用来授权软件的。

这不是我的判断，是发布这套协议的组织自己的判断。知识共享官方常见问题里关于能不能把CC协议用于软件的那一条写得非常直接：他们建议不要把知识共享协议用于软件，并强烈鼓励改用那些已经很成熟的软件许可证。理由列了三条——CC协议缺少管理源代码获取的条款，而源码的可获得性对软件的复用与修改至关重要；软件通常需要专利方面的处理，CC协议不涉及；以及现行的CC协议与主流软件许可证互不兼容，混用会造成集成问题。

另一个佐证：这个标识符本身可以在软件包数据交换标准的许可证登记表里查到——接口返回的那串字符正是从这张表来的；而它不在开源促进会批准的开源软件许可证列表里，MIT在。也就是说，一个软件框架的许可证栏上，挂着一个连开源促进会都不认作开源软件许可证的东西。

真相在同一个目录下的第二个文件里

但事情还有一层。我把仓库根目录列了一遍，发现那里同时存在两个授权文件：

• LICENSE，18,650字节，打开第一行是Attribution 4.0 International——就是那份CC协议全文。
• LICENSE-CODE，1,141字节，打开第一行写的是MIT License，版权归微软公司。

所以这个项目的真实状态是：文档与内容用CC协议，代码用MIT，两份分开放。这在法律上完全说得通，也是不少大厂仓库的常规做法。

问题出在接口那一头。许可证字段是自动检测的，检测的对象是根目录里那个叫LICENSE的文件，它不会去看旁边还有没有第二个。于是接口报出去的是内容协议，而真正约束你怎么用这些代码的那份，在检测结果里根本不出现。

这件事在什么场景下会真的咬人

三个场景，从轻到重：

1. 你自己判断。看一眼仓库页面上那行标签，以为不能商用或者用法受限，直接把这个框架排除掉了。损失是选错，不算严重，但你根本不知道自己损失了什么。
2. 企业合规扫描。这一类工具直接消费接口返回的标识符，扫到一个非批准的内容协议会自动标红。接下来是走人工复核流程，快则几天，慢则两周，而且复核的人多半也是先看那个标识符。
3. 反向的误判。更阴的一种——有些仓库的标签显示得很干净，你就默认整个仓库都是那个协议。实际上标签只说明根目录那一个文件是什么，子目录里可能另有约定，依赖树里更是什么都有。

所以这一条的通用做法很简单，但几乎没人做：下判断之前把授权文件本身打开读一遍，并且顺手看一眼根目录里还有没有第二个。这件事花不到一分钟。

顺带一个有点好笑的事实：决定一个几万星项目在页面上顶什么许可证标签的那套检测逻辑，它自己只是一个小工具库。整个开源世界的许可证标签，靠的是它对着一份已知协议短名单做比对，比对不上就交白卷。

许可证这一栏还有哪几种偏法

把这一类问题归个类，大概有四种形态，AutoGen属于第三种：

四种的共同点是：标签这个字段的语义比大家默认的窄得多——它只回答“根目录那一个文件是什么”，不回答“这个仓库能不能这么用”。而绝大多数人是拿它当后一个问题的答案在用的。

对应的自查也就四步，加起来两分钟：打开根目录的授权文件读前十行；看根目录还有没有第二个授权文件；如果引入的是某个子目录，看那个子目录里有没有单独的授权文件；最后，如果显示的是无法确定，别直接排除，去读文件——很可能只是末尾多了一句无害的附加说明。

这四个数该怎么读成一个运维判断？

回到主线。上面那些字段，怎么变成一句“选它还是不选它”？

最后推送时间：唯一一个能单独否决的字段

其余字段都是参考，这一个是闸门。判断的方式不是看绝对天数，是看它和你自己的发布节奏比。

如果你一年动两次，一个季度没推送完全无所谓；如果你每两周要跟着上游模型的接口变更调一次，那三个半月的静默意味着中间至少积了三到五轮你得自己扛的变更。同样一个数字，对两种团队的含义差着量级。

未关问题：别看数量，看最新几条在问什么

问题数量本身几乎没有信息量——用的人多问题就多。有信息量的是最新那几条的内容：如果是新功能请求和使用咨询，说明项目在正常长；如果最新几条都在问“某版本之后跑不起来了”“依赖冲突怎么办”，而且没人回，那就是另一回事了。

这一步没法自动化，得自己点进去翻五分钟。五分钟换一个季度的返工风险，划算。

星标：那个只增不减的字段

最后提醒一句老生常谈但反复有人栽：星标是那个页面上唯一只增不减的字段。项目彻底死掉，星标一颗都不会掉。它记录的是历史上的热度峰值，不是当下的状态——而它恰好是所有推荐文最爱报的那个数。

AutoGen在这四个项目里星标第二高，但它是唯一一个停着的。这两件事同时成立，一点都不矛盾。

把四个字段合成一张判据卡

为了不用每次都重新推一遍，我把它们压成了一张随手能对的卡：

右边那一列是这张卡最实用的部分。六个字段里只有前三个能给出否决，后三个全是程度判断。把程度判断加权求和搞出一个综合评分，是这类选型里最常见也最没用的做法——它把三个能否决的信号和三个只能参考的信号搅成了一个数，然后你就再也分不清那个数是被什么拉低的。

自建到底省了什么，花了什么？

把框架跑在自己的服务器上，省的是订阅费。这一点很清楚。不那么清楚的是花掉了什么。

这张表里最容易被低估的是升级适配那一行。它的特点是平时为零，某一次突然变得很大——上游改了一个接口，你的四处调用全挂，而你那天正好在忙别的。这种成本没法摊平进月度预算，只能按“一年被打断几次、每次几天”来估。

还有一行值得单独说：合规举证。做出海生意的团队迟早会遇到客户或者平台要一份说明，问你的智能体处理数据的路径是什么、有没有第三方留存。自建的答案是“我自己写”，托管的答案通常是“把厂商的合规文档发过去”。这一格的价值在没遇到之前完全是零，遇到那天很高。

升级适配这笔账怎么估出一个数

“一年被打断几次”听起来只能拍脑袋，其实可以估得挺准，方法是往回看而不是往前猜。

拉出这个项目过去十二个月的发布记录，数三个数：

1. 总共发了几个版本。这是变更频率的基数。
2. 其中有几次是不向后兼容的。发布说明里通常会标出来，标不出来的项目本身就是个信号。
3. 不兼容的那几次，涉及的是不是你会用到的部分。这一步要点进去看，是唯一花时间的。

第三个数乘以你估计的每次修复工时，就是一年的升级适配成本。我实际算过几次，主流框架的这个数通常落在一年三到八人天之间——听着不多，问题在于它不是均匀分布的，而是集中在几个你没法选择的时间点上。

所以这笔账真正的口径不是“一年多少人天”，是“一年有几次，我的交付要为它让路”。三个人的团队一年被打断五次，每次两天，感受上远远不止十人天。

顺带一个反向的提醒：推送频率过高也是成本。一个每天都在推的项目，如果同时不承诺兼容性，你实际上是在跟一个移动靶对齐。这时候锁死版本比跟进更新更省心——代价是你放弃了上游的修复，两边取舍。

托管服务买的是什么，卖掉的是什么？

托管这条路上，三种形态值得分开看，因为它们卖的东西不一样。

第一种是框架厂商自己的商业版。比如CrewAI的企业版文档给出的定位，是把你本地写好的那套东西部署上去，加上追踪、监控、集成这些开源版没有的运营面。这类的优点是概念完全一致，从自建切过去几乎没有学习成本；缺点也在这里，你和这个框架的绑定更深了。

第二种是平台化的运行时。LangGraph平台的概念文档把要解决的问题说得很明白：长时间运行的、有状态的、可能中途需要人介入的智能体，在部署上和普通服务不是一回事——它要处理任务持久化、断点续跑、并发写入这些事。这类托管卖的其实是你不想自己写的那套状态基础设施。

第三种是模型厂商自己的托管智能体。这条路最省事，但概念是它定的。站内那篇拆官方托管智能体的真实用法与避坑的文章讲得比较细，核心是它把智能体、环境、会话、事件流这几个概念做成了持久化对象，你写的东西围绕这套对象组织。

卖掉的那一样叫出口成本

三种托管卖的东西各不相同，但卖掉的东西是同一样：你换掉它那天要付的钱。

这笔钱的大小不取决于它有多好用，取决于它引入了多少只有它有的概念。一个托管服务如果只是帮你跑标准的东西，换掉很容易；如果它让你围绕着它自己发明的那套对象模型来组织代码，换掉就是重写。

出口成本怎么在选型的时候就先量一遍？

这件事有个好处：它可以在还没投入的时候就量，而且量法很朴素。

站内那篇讲换掉当前工具那天你攒的那套资产还剩多少的文章给过一条核心判据，我认为它可以直接搬到框架选型上：可移植的是“你告诉它怎么做”的部分，不可移植的是“你限制它不许做什么”的部分。而后者恰恰是你敢无人值守跑的那半边。

落到具体操作上，三个检查：

1. 把你写的东西按“提示词、流程、约束”三类分一遍。提示词几乎百分百可移植；流程编排看它是不是用了框架私有的图或者角色抽象；约束——工具白名单、权限边界、审批节点、预算上限——这一类的移植率通常最低，而且降级往往是静默的。
2. 数一数私有概念的个数。写一个小时的原型，把你在代码里写下的、只属于这个框架的名词列出来。少于五个，换掉不难；超过十五个，你已经在写这个框架的方言了。
3. 试着不用它跑通最简单的那条路径。如果直接调模型接口加两百行代码就能跑通八成的活，那这个框架给你的其实是便利而不是能力，出口成本天然低。站内那篇讲用官方软件开发包几行代码搭一个智能体的文章正好可以当这个基线用。

为什么“约束”那一半的移植率最低

这一条值得展开，因为它反直觉：大家默认最难搬的是复杂的业务逻辑，实际最难搬的是那些看起来很简单的限制。

原因在于，限制的表达方式高度依赖运行环境。“这个角色只能读不能写”“这一步必须人工确认”“单次任务上限是多少”——这些在不同框架里长得完全不一样，有的是配置字段，有的是装饰器，有的干脆没有对应概念，得你自己在外面包一层。

更麻烦的是降级往往是静默的。搬过去之后，一个原本存在的工具白名单可能被丢弃、一个原本会拦一下的审批节点可能变成直接放行，而迁移过程中没有任何东西会告诉你这一格丢了。你只会看到流程跑通了，然后在某个不确定的时刻发现它做了本来不该做的事。

所以迁移的验收标准不该是“跑通了”，应该是“该被拦下来的那几件事，还会不会被拦下来”。做法很土：迁移前写下五到十条“这套系统绝对不该做的事”，迁移后逐条构造场景试一遍。这一步花半天，能省掉的是那种没人知道什么时候会爆的事故。

独立站团队真正要跑的是哪几类活？

上面全是通用判断，落到出海独立站这边，实际要跑的活其实就那么几类。

注意后两行。站内那篇讲用工作流工具搭SEO智能工作流的文章里有一条至今成立的判断：确定性强的活，用确定性的工具，别请智能体。智能体的价值在于路径不确定时的自主决策，路径确定的时候它带来的只有不确定性。

还有一层跟本批另一篇有关。决定什么时候该拆子代理、派给哪一档模型那篇讲的是框架内部的派活决策——那些判断和你选哪个框架基本无关，因为四个框架都会让你自己做这个决定。换句话说，框架帮你省掉的是接线的活，省不掉的是判断的活，而后者才是真正决定成本的那部分。

一个母婴站的实际落地节奏

今年上半年有个做母婴用品的站，最后落成的形态挺能说明这套判断怎么用。

他们最初的需求写的是“搭一套AI客服＋内容运营的智能体系统”，听起来非上框架不可。拆开之后是四件事：回答重复的售前问题、把客服工单里的高频问题整理成帮助中心条目、每周出一份竞品价格变动简报、以及给新品页写初稿。

按上面那张表逐条对：第一件是常驻聊天渠道，第二件路径固定，第三件是定时巡检，第四件也是路径固定的批量生成。四件事里只有第一件真正需要框架，另外三件用定时脚本加一次模型调用就能做完。

最后的落地是：三件用脚本，两周做完上线；第一件先用最直接的方式接了个渠道机器人跑了一个月，等积累了足够多的真实对话，才回头去看到底需不需要多角色协作。跑完一个月的结论是不需要——绝大多数问题一轮问答就结束了，多角色是在解决一个他们并不存在的问题。

整件事最后一个框架都没引入。省下来的不只是接入的两周，更重要的是省掉了一份需要长期有人认领的维护责任，而这个站的技术人手是一个半人。

我讲这个例子不是为了说框架没用，是想说明需求描述里的“系统”两个字，经常是被工具的宣传语反向塑造出来的。把它拆成具体要跑的活再对号入座，一半以上的场景会自动出局。

什么情况下这四个都不该选

诚实地画一下边界。以下三种情况，引入任何一个框架都是负收益：

• 团队只有一到两个人，而且没人愿意当这套东西的owner。框架的维护成本是需要有人认领的，没人认领它就会在三个月后变成没人敢动的一坨。
• 你已经在用一套成熟的工作流工具，并且跑得还行。把它换成智能体框架，通常是拿确定性去换灵活性，而你原本的痛点未必是灵活性不够。这一格的判断和站内那篇讲建站到底该选托管、自建还是纯代码的文章是同一套逻辑：换平台的收益要大过迁移成本加上重新踩坑的成本，这个门槛比多数人以为的高。
• 你要做的事路径完全固定。见上一节最后两行。

还有一种情况：你其实要的是工具接法不是框架

相当一部分“我需要一个智能体框架”的需求，拆开之后是“我需要让模型能调用我这几个内部接口”。这两件事的工作量差一个数量级。站内那篇讨论命令行加技能怎么接管了智能体工具链的主干的文章给了另一条路：很多时候一个能跑的命令行工具加一份说明文档，比引入一整个框架管用得多，而且出口成本接近零。

已经选错了怎么止损

更常见的情况其实不是选型，是已经跑在一个不太对的框架上了。这时候要分清两种“不对”。

第一种是能力不匹配——框架做不到你现在需要的事。这种好办，因为它有明确的触发点，而且通常只影响一部分流程，可以在旁边并行搭一条新的，跑稳了再切。

第二种是维护不匹配——框架还能用，只是上游停了。这种难办，因为它没有触发点，永远不会有哪一天你被迫必须动手。它的典型走向是：先锁死版本，然后某个依赖因为安全问题必须升级，然后发现升不动，然后有人花两周把它拆掉。

对第二种，我的建议是提前把这两周花掉：在还没被逼到墙角的时候，用半天时间盘一遍这个框架到底替你做了哪几件事，然后判断其中哪几件用两百行自己的代码就能覆盖。真做这个盘点的时候，多数人会发现答案比预想的乐观——框架提供的能力里，你真正用到的往往不超过三成。

把那三成写下来，就是一份迁移清单，也是一份保险。这份清单最大的价值不在于你会不会真的迁，而在于它把“换掉的代价”从一个模糊的恐惧变成了一个具体的数字。模糊的恐惧会让人一直拖着，具体的数字可以拿去开会。

三十分钟能跑完的选型自查，具体查哪几步？

把这篇的内容压成一份可执行的清单，一个下午的一小段就能做完。

1. 五分钟：拉公开字段。把候选项目的星标、分叉、未关问题、许可证、创建时间、最后推送、订阅数一次性拉下来，放进一张表。
2. 一分钟：打开授权文件。不看标签，看文件本身，并确认根目录里没有第二个授权文件。
3. 五分钟：翻最新十条未关问题。看它们在问什么、有没有人回、回复的是不是维护者。
4. 五分钟：把最后推送时间和你自己的发布节奏对一遍。算一下静默期内你可能积压了几轮变更。
5. 十分钟：写一个最小原型。不求跑通，只求把你在代码里写下的私有名词数一遍。
6. 五分钟：估三笔账。开发几人天、每月运行多少钱、一年被上游变更打断几次。第三个数写不出来的，说明第四步没做够。

这六步里最容易被跳过的是第二步和第五步，而它们恰好是唯一两个能给出否决性结论的步骤。其余四步给的都是程度判断。

保哥的实际取舍

我自己给客户做建议时，默认答案是：先别选框架。用最直接的方式把第一版跑起来，跑三到四周，等到确实撞上了某个具体的痛点——状态存不住、并发控制不了、多个角色协作乱套——再回头看哪个框架专治这个痛点。

理由是，框架解决的是一批已知问题，而你在第一版跑起来之前并不知道自己会撞上哪几个。先选框架相当于先买药再生病，买错的概率不低，而且退货很麻烦。

反过来，有一种情况我会建议直接上托管：团队里没有人能在半夜爬起来看日志。这不是技术判断，是运维判断——而运维判断在这类选型里的权重，远比功能对比表暗示的要高。

常见问题解答

GitHub仓库页面显示的许可证标签，为什么可能是错的？

那一栏是自动检测出来的，检测对象是仓库根目录里那个叫LICENSE的文件，拿它跟一份已知协议短名单做比对。有两种常见的偏差：一是文件里有附加说明导致比对不上，接口会返回一个表示无法确定的值；二是仓库里同时存在多个授权文件——比如内容用一份、代码用另一份——检测只报根目录那一个。微软的AutoGen就是第二种，接口报的是内容协议，代码实际用的MIT写在同目录下的第二个文件里。判断之前把文件打开读一遍，并看一眼有没有第二个。

星标数高的框架是不是更安全的选择？

不是，因为星标是仓库页面上唯一只增不减的字段。项目彻底停止维护，星标一颗都不会掉，它记录的是历史热度峰值而不是当下状态。本文那组同日实测里，星标第二高的那个恰好是唯一一个三个半月没有推送的。要判断当下状态，看最后推送时间、最新几条未关问题在问什么、以及订阅数占星标的比例这三个。

自建和托管，成本上到底哪个更划算？

把三笔账分开算才有意义：开发成本一次性，运行成本随用量线性，维护成本持续且往往加速。自建省的是订阅费，付的是升级适配、故障响应和合规举证这三块，其中升级适配的特点是平时为零、某一次突然很大，只能按一年被打断几次来估。人少的团队算下来托管更划算的情况相当常见，因为维护成本是按人算的，而订阅费是按用量算的。

怎么在还没投入的时候就估出换掉一个框架的代价？

写一个一小时的最小原型，把代码里出现的、只属于这个框架的私有名词数出来。少于五个换掉不难，超过十五个说明你已经在写它的方言了。另一个更快的检查是：试着不用框架、直接调模型接口加两百行代码，看能不能跑通八成的活。能跑通说明框架给你的是便利而非能力，出口成本天然低。

为什么说功能对比表对这类选型没什么用？

因为四个主流框架在能力上没有谁做不到谁能做的事，差别只在胶水代码由谁写。而功能表只显示开发成本那一栏，完全不显示维护成本——后者才是你停止使用之前不会停止支付的那笔钱。它具体包括接口变更后要改的地方、依赖冲突、行为悄悄变化导致的事故，以及最贵的那一种：项目不动了而你的需求还在动。

什么情况下压根不需要智能体框架？

三种。一是团队只有一两个人且没人愿意当这套东西的负责人，无人认领的框架三个月后会变成没人敢动的一坨；二是已经在用一套跑得还行的工作流工具，换过来是拿确定性换灵活性，而你的痛点未必是灵活性；三是要做的事路径完全固定——批量改页面、定时巡检、日报告警这类，定时脚本加一次模型调用就够了。智能体的价值在路径不确定时才成立。

权威参考资料