Workbuddy连接万物:盖雅发布 Gaia CLI，把"人效"开放给 AI Agent，这件事比看上去要大

我的第一反应是“又一家”。把材料看完之后，我觉得盖雅这一步和前面几家不太一样，值得单独写。

前阵子我写过 Moka 进入 WorkBuddy。后来北森也推出了自己的 Agent 接入能力，i人事也进了 WorkBuddy。这几天，盖雅发布 Gaia CLI，“盖雅 AI 人效专家”同步上架 WorkBuddy。

用户在 WorkBuddy 里直接说话就行。查今天有没有漏打卡，看下周排班，提一笔请假。主管可以问下周部门会不会缺人。HR 可以让它看某个部门近三个月的工时利用率。高管可以让它出一份人效月报。

盖雅说，这套能力不绑定某一个 Agent，Codex、豆包、WorkBuddy、Claude、千问办公都能用。企业按自己的环境选择接入方式就行。Agent 可以换，盖雅的业务能力不用重做。

接法上，盖雅给了两条路：Skills + CLI 或 Skills + MCP——MCP 走标准的 stdio/http，底下是 OpenAPI。开放平台的文档已经公开，企业按自己的 Agent 环境选就行。

图：盖雅官方「跨 Agent 通用解决方案」——同一套业务能力，5 种 Agent 即换即用

这件事不只是盖雅一家在做。Moka、北森、i人事前些天都陆续进了办公 Agent。每家的做法不同，方向是一致的：不让员工再去打开 HR 系统。

我想了一会儿，答案在盖雅自己的人效理论里。

他们把人效看成劳动生产率。公式的分母一路从人头数走到人力成本，最后落在工时上。CEO 章新波在演讲里讲过一个“一个小时的故事”：一万人的企业，每人每月少加一个小时班，按他给的参数算，大约省 540 万元。按 5% 的净利润率倒推，相当于多做了约 1.08 亿元的销售。

图：「一个小时的故事」——1 万人企业，每人每月少加班 1 小时（测算口径来自盖雅，参数未完全公开）

我的理解是，人效最底层的数据就是时间，而时间数据全在考勤和排班系统里。规则明确，动作边界清楚，结果也能校验。这样的场景，最适合让 Agent 先上手。

图：盖雅官方 Skills / CLI / MCP / OpenAPI 四层架构

补卡要核对缺卡记录和补卡条件，请假要校验额度和时间冲突，加班要核对申报工时。这些都由系统来做，Agent 不替系统拍板。审批也走企业原有的流程。

读这份报告要留个心眼：它出自盖雅自己的人效研究院，立场本来就偏外采。不过它也承认，业务足够独特、又有长期产品能力的企业，自研是合理的。这一点我觉得比较诚实。

盖雅演讲材料里有一些案例。雀巢工厂做中央排班后，排班总工时从每周 500 小时降到 2 小时，人效提升 20%。伊顿中国大陆每年节省 13000 小时。大华富阳工厂一线人均产值三年年均涨 11%。

这些都是厂商自己披露的。我想说的不是数字本身，而是数字背后的东西：价值来自多年沉淀的排班、工时和技能数据。Agent 现在要调用的，就是这些东西，而不是一个会聊天的界面。

发布稿讲了 OAuth 2.1，也讲了租户、应用、用户三级数据权限，这是个不错的起点。但我还想追问几件事：

另外，缺口预测、风险画像、异常归因这些分析靠大模型来做，稿子里自己也写的“供参考”。准确率、响应速度、调用成本、客户数据，发布稿一概没给。选型时，我会把查询、申请这类确定性的能力，和模型分析分开验证。

前面几家让我们看到，HR SaaS 在集体往办公 Agent 里走。盖雅这一步，是把人效最底层的时间能力开放出来了。

没有企业专属数据，就没有企业专属智能。

但数据要想真正可信，还得有身份、权限、规则和审计兜着。

接下来我更关心的是另一件事：当越来越多 HR 系统的能力挂进同一个 Agent，这些能力到底该谁来管？

我是雷神，做 HR 数字化十几年，聊 AI 落地的真实一面。如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。

THANKS FOR READING