产品猎奇·10月01日：数据层与AI Agent的基建战争

今天在ProductHunt上又发现了几个有意思的新产品, 我一看这三个, 感觉整体方向特别一致, 都在往"让AI能真正操作你的产品"这个方向走.

先说排名第一的, Directus出了个新东西叫Monospace, 拿到了两百三十多票, 五十多条评论.

Directus我知道, 做了好几年headless CMS了. 但Monospace这个定位变了, 它现在不叫CMS了, 叫"governed API layer", 治理层.

对, 它的slogan是"The governed API layer for every app, person, and agent". 注意最后那个词, agent. 李博, 你觉得这个"for agent"有什么特别的?

这里有个关键点. 以前做API层, 你考虑的是人, 是开发者, 是业务团队. 但AI agent来了之后, 问题变了.

Agent不像人, 它会疯狂调用接口, 它不懂"这个数据你不该读", 它也不会因为没权限就停下来. 所以你需要一个统一的权限模型, 把人和agent放在同一套规则下管.

这就是Monospace说的"granular permissions model", 细粒度权限. 而且它有一点我觉得很聪明, 数据不复制不迁移, 直接接到你现有的数据库上.

对, 这个最厉害. 它会实时introspect你的schema, 自动生成接口. 你那个几十年前的老Oracle数据库, 不用重建, 直接接进来. 这对大企业来说太重要了.

等一下, 这不就是以前那种API Gateway的活吗? Kong啊, Apigee啊, 差别在哪?

不对, 我觉得不只是这样. API Gateway是流量管理, 它不理解你的数据结构. Monospace是在schema层做的, 它懂你的数据长什么样, 才能生成read-write接口.

你再想想, 如果是agent调用, 它需要的不只是"通了没有", 还需要"这个操作对不对", "权限够不够". Gateway做不到这一层.

所以它的核心用户其实是有老旧系统的大企业, 又想给AI agent开放数据, 又怕数据乱来.

完全对. 这也解释了为什么能拿两百三十多票. 开发者一看就懂这个痛点, 企业里那些几十年的legacy database, 真的是噩梦.

总结一下就是, Monospace的价值在于, 它把企业数据层变成了一个agent-ready的统一接口, 同时保住了权限控制. 好, 接下来说第二个.

第二个是Cura, 两百一十多票, 四十四条评论, 排名第二. 定位是"Your AI travel agent that plans, books, and adapts".

旅行AI agent, 这个赛道感觉已经很卷了吧? 小雨你怎么看?

我第一反应也是这样. 但我仔细读了一下, 它有个点很不一样, 它说"Cura takes action for you", 不只是给你推荐, 是帮你做操作.

这个区别很大. 以前的旅行AI, 本质上是个聪明一点的搜索引擎, 给你列个清单你自己去点. Cura说它能帮你check-in, 能帮你改签.

对, 而且它还有个我挺喜欢的设计, 当情况变复杂了, 比如航班取消这种, 真人旅行顾问会介入. 这个human-in-the-loop做得很聪明.

你的感觉没错. 这就是agent产品现在的主流思路, 不是说AI全包, 而是AI处理80%的标准流程, 真人处理那20%的异常. 这样可靠性就上来了.

还有一点, 它说"learns how you travel, so future trip planning takes just one line". 越用越懂你, 这个记忆层设计是对的.

可是这就矛盾了啊. 它要帮你改签, 要帮你check-in, 那它需要接入航空公司系统, 接入酒店系统. 这个integration有多深? 现在真的做到了吗?

这是个好问题. 产品页面没说得很清楚. 我猜目前可能更多是"推荐加引导", 真正自动操作的部分还在迭代中.

所以它打动ProductHunt用户的点, 更多是这个愿景本身. 旅行planning这个痛点是真实的, 每个人都有过订机票+订酒店+做攻略各干各的那种崩溃感.

Cura的结论就是, 它在对的方向上, 把旅行全流程agent化, AI加真人兜底. 至于落地深度, 还需要观察.

好, 然后还有一条, 第三个是Yedric.ai, 一百六十三票, 排名第三. 它的定位特别直接, "Let users control your SaaS with natural language".

哦, 这个我一看就有感觉. 它不是面向终端用户的, 它是面向SaaS开发者的. 让开发者在自己的产品里, 三十分钟内嵌一个自然语言操控层.

对, 就是说你做了个SaaS, 你不用自己去开发AI交互这套, 接Yedric的SDK, 用户就能用自然语言操作你产品里已有的功能.

重点不在于"加了个AI对话框", 重点在于, 它把用户的自然语言请求, 映射到你产品里已有的action. 不是新建功能, 是给现有功能加一层自然语言接口.

这也太符合现在SaaS产品经理的焦虑了. 大家都说要AI-native, 但自己从头搭一套agent体验, 成本太高了.

而且三十分钟这个数字, 说明它的接入是embeddable的, 应该是个script标签或者npm包级别的接入方式. 开发者最爱这种.

不过评论只有九条, 相比前两个少很多. 这可能说明它现在的受众还比较窄, 主要是SaaS开发者这个圈子.

这是个to-developer的产品, 口碑传播慢一点很正常. 但它一旦被几个有名的SaaS接了, 口碑会爆发. 这就是它的增长逻辑.

所以Yedric的价值主张就是, 帮SaaS产品三十分钟变成AI-native, 省去自研agent的成本.

好, 我们来说说这三个产品的共性. 李博, 你怎么看今天这几个?

太明显了. 这三个全是在给AI agent做基础设施. Monospace是数据层, Yedric是操作层, Cura是垂直场景的agent应用. 这三层正好是一个完整的agent stack.

你这么说我突然想到一个问题, 现在ProductHunt上agent相关的产品, 已经从"我做了个AI聊天框"升级到"我在给agent做基建"了.

对, 这说明市场已经过了最早那波toy demo阶段了. 大家开始认真考虑, agent怎么安全操作数据, 怎么嵌进现有产品, 怎么在真实场景落地.

最后给个今日推荐. 李博, 如果只能用一个, 你选哪个?

我选Monospace. 理由很简单, 它解决的问题是企业级的刚需, 而且切入点很聪明, 不动现有数据库, 直接在上面生成接口. 这个对大公司来说阻力最小.

我同意. 而且它的竞争壁垒也更高, 接入之后越用越深. 好, 今天就到这里, 感觉这波agent基建的浪, 才刚刚开始.