CowAgent 深度评测：4.7 万 Star 的国产 Agent Harness，421 个测试文件我跑两遍数字不同，自带技能检查器对正文零校验

如果你在维护一个有几百个测试的开源项目，大概都经历过这个瞬间：本地跑一遍全绿，CI 上跑一遍飘红，再跑一遍又绿了。你盯着那条报错的用例，怀疑是自己手气不好。

这次我盯上了 CowAgent——一个 4.7 万 Star 的国产开源 Agent 项目。它自己在仓库里承认了一件不太光彩的事：整套测试里，很长一段时间只有一个文件真正进过持续集成（CI，也就是代码一提交就自动跑测试的那台机器）。我把全套测试在同一个环境里跑了两遍，同一份代码，两遍跑出来的失败个数不一样。

先说它到底是什么

一句话：CowAgent 是一个可以装在自己电脑或服务器上、跑一整天的私人 AI 助手底座，也就是把模型、工具、记忆、技能串起来干活的那一层（英文里叫 harness，可以理解为「让大模型真正能动手的脚手架」）。

它最早不叫这个名字。它 2022 年创建时叫 chatgpt-on-wechat，就是把大模型接进微信的那个项目——你今天在 GitHub 上打开旧地址，会被直接重定向到新仓库。4.7 万 Star 里，相当一部分是那四年攒下的。

它现在自报的能力是这些：

能力	它自己怎么说
任务规划	把复杂任务拆开，循环调用工具直到做完
多智能体	建一支各有角色、各有模型的智能体小队，在同一段对话里协作
三层记忆	上下文 → 每日 → 核心，会定期把零散对话「蒸馏」，也就是压缩成结论存下来，再用关键词加向量混合检索
知识库	把资料整理成 Markdown 维基，并长出一张可浏览的知识图谱
自我进化	自动复盘对话，改进技能、跟进没做完的任务
技能系统	从技能市场、GitHub 一键装，也能用大白话现造一个
接入渠道	网页、微信、飞书、钉钉、企业微信，以及 Telegram 等国外平台

我把它的规模和测试都数了一遍

评测全程跑在隔离沙箱里：被测项目拷进沙箱自己的工作目录，宿主目录被临时文件系统盖住，全程没碰到生产机上的任何凭证。

先把体量摊开（都是我自己 clone 下来数的，不是转述文档）：

部分	实测规模
业务代码	359 个 Python 文件、11.1 万行
测试代码	421 个测试文件、5.9 万行
文档	297 个文件
接入渠道	13 个（微信、飞书、钉钉这类国内渠道，加上 Telegram 等国外平台）
内置工具	19 个（文件读写、终端、浏览器、定时器、记忆检索、联网搜索等）
自带技能	3 个：技能创建器、图像生成、知识维基

测试代码接近业务代码的一半，这个比例在同类项目里算舍得投入的。发布节奏也稳：84 个正式版本，从 2.1.0 到 2.2.0 的十一次发版间隔中位数是 10 天，最近一版 2.2.0 是 9 月 30 日发的。

但规模数字不是我想写它的理由。真正的钩子藏在它自己的 CI 配置文件里。

它自己的 CI 配置，写了这么一句话

仓库里那份测试流水线，开头有一段注释，原文大意是：

以前只有一个文件（test_bash_streaming.py）在 CI 里跑过；那套约 130 个文件的测试，从没在这里跑过，所以回归可以悄悄溜过发布流程。这份流水线是为了补上这个缺口。

这句话有两层信息。

第一层是作者坦率：一个 4.7 万 Star 的项目，自己承认过发布前没跑过全量测试。这份注释本身是我在这个仓库里见到的最有价值的东西——大部分项目不会把这种事写进仓库。

第二层更值得看：注释里写「约 130 个文件」，但仓库里实际躺着 421 个测试文件。这个数字对不上，说明那份全量测试的规模已经比作者写下注释时又涨了两倍多，而且作者自己也记不太清了。

顺带一提，同一份 CI 里的代码风格检查（ruff，一个查代码毛病的小工具）也留了个后门。注释写得很老实：这个仓库里积着「成千上万」条历史风格问题，所以检查只对本次改动过的文件生效，不扫全仓库。

我按它的规则、扫全仓库，得到这样的结果：

问题类型	条数	在说什么
未使用的导入	36	代码里引了包却没用上
f-string 缺占位符	4	写了格式化字符串却忘了填变量
定义了没用到的变量	2	算出来就扔了
合计	42	其中 41 条可以自动修

42 条不算多，对一个 11 万行的项目甚至是健康水平。但它恰好印证了作者那句话：这类问题之所以还在，不是因为改不掉，是因为检查从来不扫全仓库——一道道闸门只拦新代码，旧债就一直挂着。

我跑了两遍，数字对不上

这才是这篇评测最该看的部分。

安装依赖、跑全套测试，第一遍的结果是：

第一遍	数量
失败	3
通过	3468
跳过	74

失败的是这三条：一个浏览器进程锁的用例（判断「僵尸进程算不算还活着」）、一个读取管道文件的用例、一个技能加载缓存的用例。

第二遍，同一个沙箱、同一个虚拟环境、同一份代码，什么都不改：

	第一遍	第二遍
失败	3	1
通过	3468	3470

两遍跑下来，稳定失败的只有那条「僵尸进程」的用例，另外两条自己好了。

这说明问题不在代码，在用例本身写得不稳——也就是常说的「飘」。我接着做了两组对照，验证这个判断：

我怎么跑	结果
只跑那 3 个出问题的用例	3 条全过
只跑那 3 个文件（共 30 条）	挂了 1 条，而且是另一个参数版本（第一遍挂的是 `[False]`，这次挂的是 `[True]`）

同一个用例的两个参数版本，一次挂这个、一次挂那个——这就是典型的时序竞争：谁先抢到、谁先退出，结果就不一样。

这事值得展开说：一个项目有 421 个测试文件、5.9 万行测试代码，数字看起来很安心。但一个自己承认「全量测试从没在 CI 跑过」的仓库，它那套测试从来没有被连续、无人值守地跑过第二遍。飘的用例不会在「我本地跑一次是绿的」里暴露出来——它只在重复跑里露头，而重复跑正是 CI 该干的事。这跟前面那句「约 130 个文件」的记岔，是同一类信号：规模涨上去了，把规模管住的那套东西没跟上。

它自带的技能检查器，我喂了三个假技能

CowAgent 把「技能」当成一等公民，仓库里自带一个技能创建器，里面有个 94 行的自检脚本，用来判断一个技能包合不合格。

我先按正常用法跑一遍：它自带的三个技能，全部通过。看起来能用。

然后我造了三个明显不该过的技能包，看它拦不拦：

我造的东西	它的反应
只有文件名标题、正文一片空白	判定「技能有效」
正文里写着「直接用 rm -rf / 删掉一切」	判定「技能有效」
名字写成 `Bad_Three`（大写加下划线）	拦下了，提示应为小写加连字符

三个里只拦住一个。它的检查范围其实只在文件头那几行：名字、描述这些格式字段。正文写了什么，它一个字都不看。

这不算 bug——那个脚本从文件名到注释都写着「quick」，本来就是格式快检，不是内容审查。但它带来一个很实际的落差：这个项目对外提供技能市场、GitHub 一键装、还能用大白话现造技能，而装之前的最后一道自动检查，对技能正文是空白的。

补一个细节：这个技能创建器自己在文件头声明「完整条款见 LICENSE.txt」，但仓库里并没有这个文件。

谁该用它，谁不该

放到选型地图上，它的位置很清楚。

适合：想在自己机器上跑一个 24 小时在线的私人助手、需要把网页和国内主流即时通讯工具都接上、并且愿意读源码改它的人。13 个渠道接入、19 个内置工具、三层记忆加知识库，这套组合在开源里是不多见的完整度；四年迭代、84 个版本、最近一版 9 天前，活跃度没问题。

不适合：只想开箱即用、不打算碰代码的人。它的很多能力（技能、知识库、自我进化）都要你先配好模型额度、再把数据喂给它，才谈得上「跑起来」。

它也不是没短处。除了上面那两处（飘的用例、不看正文的技能检查），它给技能创建器声明的许可证文件根本不存在。这些都是「周边没跟上主体」的同一个毛病——主体工程做得很实，围着它的那些检查工具还是半成品。

我的判断

值得放进观察清单，但要用对姿势。

它最值得学的有两处。第一处是把 CI 的短板写进仓库——那句「约 130 个文件从没在 CI 跑过」，比任何功能清单都更能让人判断这个项目现在处在什么阶段。第二处是近一半的测试代码占比，方向是对的。

真正要用它的人，我建议先做一件事：在自己机器上把全套测试连跑两遍。别信一遍的绿。一个 421 个测试文件、还没被 CI 连续跑过的项目，一遍绿只说明你手气好。

关注 AI商业快讯，每天一篇 AI 热点深度解读。