Muse 最近很火。案例站一个接一个冒出来，不少人在晒它替自己办成的事：追回一笔退款，取消一个忘了的订阅，盯到一张降价的机票。据 Business Insider 报道，Meta 首席 AI 官 Alexander Wang 甚至在 X 上发起了 #MuseMoneyChallenge，鼓励用户晒它替自己省下的钱。
热闹看多了，我反而好奇一个更朴素的问题：用户到底把什么事交给了它？
9 个 Muse 案例站，806 条记录，去重后是 673 个公开案例。把它们摊开看，能回答一个很实际的问题：当越来越多产品都说自己是个人助理，用户到底想让它做什么？
翻完这些案例，我的第一感受是：用户交给 Muse 的，大多不是难事，是烦事。
用户交出去的事，很多都不难
忘了取消的订阅，迟迟没到账的退款，需要反复联系的客服，随时可能售罄的门票。
这些事单独拎出来，没有一件听上去需要多聪明的 AI。有人让助理联系 Costco 客服并带回通话记录，有人把学校日程从 PDF 放进家庭日历。购物时让它比较选项、找优惠；旅行时让它查价格、改行程、等客服回复。
媒体报道的用户分享里，例子更具体：有创业者让 Muse 重新比了车险，找到一年便宜 3500 美元的方案；有用户让它翻订阅记录，揪出一个一年多都没取消掉的图书订阅，连取消带追回之前的扣款；Coinbase 的产品经理 Nick Prince 买车时带着它，躲开了经销商的加价推销，省了 1250 美元。Barron's 记者 Josh Schafer 的实测更日常：只让它看了一眼信用卡账单 PDF，就揪出一个自己都忘了还在付的 Adobe 订阅，一个月 25 美元。《纽约时报》记者 Eli Tan 接上银行信息后，它找出并取消了两个重复订阅，还要回一笔 44.99 美元的过期报纸试用退款。
麻烦从来不在第一步，在后面。 用户得记得它，等得起它，还要在第一次没办成时继续追。
找到一项订阅只要几分钟，确认它已经取消、退款已经到账，可能要等好几天。机票降价很容易被发现一次，难的是此后每天都看。家庭日历也不是整理完一份文件就永远准确，学校通知还会继续来。有用户干脆让它替自己排队等客服电话——真人接起来了再叫他。这正是"烦"的本质：不是不会做，是不想把时间耗在等待上。
省钱的故事最容易传播。673 个案例里，有 107 个写出了明确金额，中位数是 250 美元。但我觉得更值得看的不是这个数字，而是它背后的形态：人们喜欢用"帮我省了多少钱"来描述助理，说明他们交出去的，本质上是一段自己不想跟的流程。
82% 和 18%：试用和留存之间的距离
按任务持续时间分一下，673 个案例里，553 个是一次性代办，占 82.2%；另外 120 个涉及持续盯办或定期执行，占 17.8%。
前者是追回一笔退款；后者是一直监控票价、定期检查账单，或者每天整理孩子们的活动安排。
这两个数字没有高下之分，但它们对应的是两件完全不同的事。
一次性任务容易让人第一次感到惊喜，也容易展示成果。一个人追回了钱，会愿意告诉朋友；但下个月，未必还有同样的退款需要追。比如 Mashable 报道里那个靠航班延误拿到 250 美元 credit 的旅客——一次性的惊喜，很难变成下个月还回来的理由。一次性的结果，能让用户来试；持续的盯办，才能让用户留下来。
持续任务的要求高得多。它要记住上次看到什么，知道什么时候该再查，发现变化后还要判断值不值得打扰用户。
这也是 Muse 们接下来真正要过的一关。对 Agent 产品来说，留存长这个样子：不是让用户每天回来用，而是让 Agent 替用户一直记着。
"帮我办了"，到底办到了哪一步
再按任务进度分一下：约 29.4% 的案例停留在查找和简单判断，真正走到代为下单或代为沟通办理的，合计不到 37%。
助理查到航班价格、列出改签选项，已经帮了忙。但替用户完成改签，还要面对账户登录、支付、库存变化和失败后的补救。查到了退款规则，离钱真的退回来也还有几步。每往前走一步，用户交出去的权限、信任和耐心都在变。
Barron's 的实测里有个提醒：一位编辑给了完整信用卡权限，Muse 把一笔去年的房贷识别成了今年的可疑大额支出，对了几轮才承认看错。能干活和干得对，是两回事。
我写这篇时，也用 BeatAPI 的 Social Data 读取了相关的公开资料。这次调用解决了一个清楚的问题：让 Agent 取得公开资料并保留来源。但它没有替我长期追踪这个话题，更没有替任何人联系商家。
数据返回了一次，任务并没有结束。
我准备先验证哪一个持续任务
所以对 BeatAPI，我想先从公开信息的持续任务开始验证。
举个具体的例子：一个经营产品的小团队，想知道用户最近在社媒上提出了哪些新问题。Agent 读取公开讨论，保存原链接，和上次结果比较，只把新增且值得处理的问题交给人。人决定要不要回复，下一次再看这个问题有没有变化。
这条流程里，BeatAPI 已有的 Social Data、Web Search、SEO Data 和模型，分别补上公开讨论、网页与搜索信息，以及筛选和分析能力。接下来要验证的，是重复运行后的状态、变化识别、成本控制和行动前确认。
尤其是来源和时间不能丢。没有它们，一份看起来很流畅的简报，读者很难判断哪些内容真的发生了变化。
每增加一项执行能力，我都想先回答几件实际的事：谁授权它做这一步，失败后怎么办，用户从哪里查看发生了什么，哪些动作必须由人点头。这些环节做好之前，"查到信息"还不能算"替你把事办完"。
最后
回到开头那个问题。
Muse 的案例告诉我们，用户愿意交给 Agent 的，大多是不难但磨人的事。一次明确的结果能吸引人尝试，持续记着、反复跟进，才有机会让人留下来。借用那位 Barron's 记者的话："Google is for finding things; I'm for getting things done."用户要的不是更聪明的搜索，是一个替他把事办完的东西。
我接下来要做的，就是选一个足够具体的持续任务，把第一次调用、下一次检查和最后的结果都记录下来。只有这样，才知道 Agent 到底替人省下了什么。