ESSAYS / Products & Technology
Personal Agent的真正需求和路径在哪里？
背景
我对 Muse，以及 Personal Agent 在国内又一次火起来是有非常多疑问的：
-
Personal Agent 又不是新的概念，甚至是人人都想到过，最触手可及的需求，为什么能在美国、在中国这么火？
- 它没有新的技术、不是新的形态、也没有做 Codex 做不到的事情；
- 在美国火，是普通美国人没有见过类似的产品形态吗？不知道美国的创业公司情况，不敢妄议；
- 在中国火，豆包千问都说帮你解答生活问题，OpenClaw 就已经让一堆人有了个人助理，Codex 用 Computer Use 就能帮你办事，上一轮还在说通用 Agent 吞噬一切了，怎么现在又开始相信 Personal Agent了？Context 这个概念怎么又让你们这么激动了？
-
为什么之前类似的尝试没有做起来？
- 假设：用户需要一个既能帮他做事情，又能陪他聊天解决情感需求的 Her，并且这个 Her 由于掌握了用户很多的 Context，所以两方面能够相互助益；
- 结果：用户对此并不感冒，当时我的推论是用户无法形成这样的需求，因为：
- 没有提效：跟 Agent 说一句话，等模型转出来，还不如自己点两下按钮来得快（这些按钮都是无数 PM 优化 N 遍来的），且还要忍受模型的不确定性；
- 没有赋能：不像 Claude Code 能帮你突破现在的能力边界，一个个人助理能够帮你突破点外卖份数的极限？好像没啥用。个人生活里不存在这样的优化目标；
- 生态不允许：Agent 直接执行交易，那广告怎么赚钱？购物就是为了消遣和增加用户停留时长，我不需要把我享受的时间用来提效；
- 损益不允许：模型调用成本居高不下，且缺乏规模效益，边际成本不会随着人群扩大而下降；也找不到合理的收入模式，订阅吗？那我已经有 Claude Code 了，我不肯继续付钱；抽佣吗，怎么抽？ 导致 Agent 的各种成本都太高，用户局限在办公人群和 Coding 人群上，而无法走入下沉群体。
- 但是，这样的结果是否会武断了一些呢？有没有可能这里真的有机会？
1. 一个通用的损益模型
根本问题：交给 Agent 做，值得吗？即，交给 Agent 做的损益，和自己做的损益相比，更划算。但人并非理性动物，所以分析时代入的损益是”用户自己以为“的直观的损益，不一定是真实客观的损益。且（感觉）省钱比（感觉）省时间要更明显：大部分人不会对省了多少时间有明显的感知，但是钱是实打实的。
一个通用的损益模型，用来判断每一个任务（获得收益/更划算为+，付出成本/不划算为-，+-为不确定）：
| 环节 | 人 | Agent |
|---|---|---|
| 需求传达：能够清楚方便地传达吗？ | 任务可以自己完成：+无成本 任务需要和人沟通：-与人沟通的成本 | 任务可以自己完成：-用户和 agent 的沟通成本 任务需要和人沟通：+-代替用户与他人沟通（懒得组织语言时，agent 省成本） 不需要人的需求传达：++agent 自己发现这里可以省 |
| 需求执行：做得快吗？能够让人（在心理上）觉得赚了、值了吗？ | -主动操作时间 -被动在场时间（排队、等回复、盯页面） -认知负荷（理解规则、记住进度，担心漏掉） -心理成本（不想打电话、怕起冲突、拖延） +过程本身的享受 | +省下几乎所有执行成本 -执行过程本身的享受 |
| 需求验收：检查成本高吗？ | 任务可以立即完成：+无成本，做完即检查完 任务需要延时完成或多次完成：-多次检查的成本 | 一定会有：-用户检查 agent 执行结果的成本，如果检查成本=用户再做一遍，那上面的省下执行成本就毫无意义 任务需要延时完成或多次完成：+免去用户自己多次检查的成本，归为一次 |
| 结算 | / | -收费吗？ -隐私让渡 |
对于每一个可能的任务，进行这样的损益拆解，就可以最终结算得出用户是否觉得把这件事给 Agent 代劳是值得的。举例：帮忙订餐厅，有需求吗？
| 情境 | 和朋友干饭探店 | 商务宴请/社交 |
|---|---|---|
| 需求传达 | 帮我订个餐厅，时间和地点范围，用餐人的喜好和禁忌 喜好和禁忌：强依赖 Context，如果没有相关记忆，把自己的好恶表达出来的成本，远高于看推荐 feed 然后判断“这个好”“这个不好” | 帮我订个餐厅，时间和地点范围，用餐人的喜好和禁忌 喜好和禁忌：比较通用/客气，需求传达成本低 |
| 需求执行 | 可行域 ≈ 附近所有餐厅，可以节省很多搜索成本 但用户执行过程中是有享受的（发现美食的快感） | 可行域 ≈ 适合商务宴请的餐厅，可行域小，节省搜索成本的程度小（比如，如果我想找个地方跟人 coffee chat，我会直接搜索附近的 manner，gaga 以保证稳定出品，并不想冒险尝试新事物；宴请同理，我宁愿找自己吃过的） 但用户执行过程中没有享受 |
| 需求验收 | 目的是挑一个好吃的地方，所以会对着结果精挑细选，验收=自己重新再做一遍，但如果非常了解用户，推荐到心坎上的话，无验收成本 | 目的是差不多就行，所以验收成本很低 |
| 结算 | 可能有（在积累 Context，非常了解用户，推荐到心坎上的话） | 可能有（如果用户对周围的环境不熟悉，需要找一个差不多过得去的餐厅的话） |
根据这个损益函数，可以得出这样的推论：
- 与广告模式冲突。 广告出售用户注意力，这个 Agent 的成功标准是让用户少花注意力。这是生态不允许的深层原因。
- 做得越好越隐形。 日活和使用时长衡量不了它，用户也感知不到省下的东西。产品需要主动展示账本：替你处理了什么，省了多少钱和时间。
- 信任门槛高于普通工具。 用户只要还要回头检查，心力和成本就回来了。因此这些需求一定要能够做得足够好，比如满意率 99%。
- 这些需求早有人类买家：秘书、管家、家庭助理。待回答的是价格能否降到大众可接受。
2. 所有可能的行动域
2.1 生活领域
按日常起居列出 12 个领域。用美国时间利用调查（ATUS）的大类核对覆盖面：个人护理、家务、照顾家人、照顾非家人、工作、教育、消费购物、专业与个人服务、家庭服务、政府服务与公民义务、饮食、社交休闲、运动、宗教、志愿、出行，都能归入下面某个领域。
- 饮食：买菜做饭、外卖、堂食
- 衣着与个护：买衣服、美发美容
- 居住：租房买房、水电网与物业、维修、家政、搬家、闲置处理
- 出行：通勤打车、长途交通、车辆（保养、违章、年检、保险）
- 健康医疗：挂号就诊、买药续药、体检疫苗、报销理赔
- 家庭照护：孩子与学校、父母与老人、宠物
- 财务：缴费、订阅、记账、保险、税、投资、信用卡权益
- 证件与公共事务：护照签证、社保公积金、户籍与居住证、投诉与纠纷
- 工作与学习的个人侧：求职、考试报名（工作任务本身不在范围内）
- 社交关系：约人、聚会、礼物、人情往来、群聊
- 休闲旅行：旅行、演出赛事、兴趣爱好、内容消费
- 数字生活：邮件消息、文件照片、账号设备、隐私
2.2 事务环节
一个领域里的任何一件事，都会经过以下环节中的若干个：
- 触发与记挂：意识到要做。可能是内生的（饿了），也可能是外部到期的（续费、年检、学校截止日）。外部触发的事需要一直记着。
- 选择：收集信息、筛选、拍板。
- 办理：下单、预约、填表提交。
- 履约等待：物流、排队、审批进度、等余票。
- 使用体验：吃、穿、玩、看病本身。（这是 Agent 无法替代的）
- 售后与退出：退换、退款、投诉、索赔、退订、续约谈判、闲置出售。
- 记录归档：记账、票据、病历、证件材料。
2.3 情境变量
“订餐厅”会分成两种（甚至更多）情境，这说明，同一件事，在不同情境下是有不同的需求的。情境变量可以拆成如下几个子项：
| 变量 | 取值的两端 | 改变成本式里的哪一项 | 例子 |
|---|---|---|---|
| 意愿还是义务 | 我想做 / 我得做 | 过程享受；偏好是否隐性 | 朋友聚会选餐厅 / 公务宴请选餐厅 |
| 当下状态 | 有闲有兴致 / 累、烦、手眼被占 | 心力的机会成本 | 慢慢挑外卖 / 逛烦了 |
| 时效要求 | 等得起几天 / 结果必须几分钟内到位 | 时延损失 | 退款索赔 / 饿了点外卖、出门打车 |
| 后果 | 可撤回、损失小 / 不可逆、损失大、丢面子 | 检查成本；出错风险 | 点错外卖 / 签证填错 |
| 熟悉度与能力 | 第 N 次、熟练 / 首次、规则陌生、不会操作 | 认知负荷；是否存在现成最短路径 | 复购 / 第一次在外地看病；老人 |
| 决定权归属 | 我一人定 / 替别人办、多人共同定 | 意图表达；协调成本 | 自己吃 / 替父母挂号 / 五人聚餐 |
然而，同一个用户无法被静态归类，甚至用户也意识不到自己的需求真正是什么，处于什么情境下。推论是：Agent 要么在用户进入不愿投入的情境时被主动调起，要么能从信号里识别这种情境（比如反复浏览却不下单）。
2.4 综合分析
对不同领域、环节、情境的任务进行损益模型搭建，可以得出这样的表格：
● 有空间 ◐ 取决于情境 ○ 无空间
| 领域 | 触发与记挂 | 选择 | 办理 | 履约等待 | 售后与退出 | 记录归档 |
|---|---|---|---|---|---|---|
| 饮食 | ◐ 补货、菜单计划 | ◐ | ○ 复购；● 热门餐厅订位 | ○ 外卖追踪已够用 | ◐ 漏送退款（国内 App 内已简单） | ◐ 饮食记录、控糖 |
| 衣着个护 | ◐ 补货、定期采购 | ◐ | ○ 下单；◐ 预约理发（美国多靠电话） | ○ | ◐ 退换货寄件 | ○ |
| 居住 | ● 合同到期、缴费异常 | ◐ 房源筛选可交出，拍板留给人 | ● 报修、约师傅、搬家询价 | ● 等师傅、等审批 | ● 押金、物业投诉、砍网费、闲置出售 | ◐ 合同票据 |
| 出行 | ● 年检、续保、违章 | ◐ | ○ 打车；● 抢票候补 | ● 余票监控 | ● 延误索赔、改签退票 | ◐ 差旅票据 |
| 健康医疗 | ● 复诊、续药、疫苗 | ◐ | ● 抢专家号、约医生 | ◐ 排队叫号 | ● 医保报销、商保理赔 | ● 病历与检查单 |
| 家庭照护 | ● 学校通知、缴费截止 | ◐ 课外班调研可交出，拍板留给人 | ● 报名、接龙、远程替父母挂号缴费买药 | ● 多方日程 | ◐ 退费 | ● 家庭日历 |
| 财务 | ● 订阅续费、权益到期 | ◐ 保险理财调研可交出，拍板留给人 | ○ 自动扣费已覆盖 | ○ | ● 退订、退款、砍账单、理赔 | ● 记账对账、报税材料 |
| 证件与公共事务 | ● 证件到期 | ○ | ● 签证、社保公积金、居住证 | ● 审批进度 | ● 投诉、小额纠纷 | ● 证件材料库 |
| 工作学习个人侧 | ● 报名截止 | ◐ 职位筛选可交出，投递拍板留给人 | ● 抢考位 | ● 职位、考位监控 | ○ | ◐ |
| 社交关系 | ● 生日、人情往来 | ◐ | ● 多人约时间 | ○ | ○ | ◐ 人情记账 |
| 休闲旅行 | ○ | ◐ | ● 多项预订；● 热门演出抢票 | ● 价格、余票监控 | ● 行程变更、退款 | ○ |
| 数字生活 | ● 账号安全、到期 | ○ | ◐ 设备设置 | ○ | ● 数据删除、骚扰拦截 | ● 邮件分拣、文件照片整理 |
【推断】这张表呈现三个规律：
- 选择一列几乎全是 ◐。 选择需要根据情境来做细致的分析。
- 办理一列按对手方分成两半。 对手方是消费 App 时为 ○，路径已经被压到最短；对手方是机构或稀缺资源（专家号、考位、热门票、签证、报销）时为 ●，但这又涉及公平（黄牛agent抢号）、准入（走后门）等安全问题。
- 触发与记挂、售后与退出、记录归档三列大多是 ●。 这三列分别对应三种用户最不愿付出的心力：一直惦记着别忘、硬着头皮去交涉、枯燥的整理。它们集中在家庭照护、财务、证件、医疗、居住几行。
3. Personal Agent 的需求域
本节沿用全文前提：先放弃权限、生态限制的假设，假设所有功能都对 Personal Agent 开放。
3.1 用例回收
用第 1 节的损益模型拆三个 Muse 用例。表中 + 表示这一环节对该做法划算，- 表示付出成本。
用例一：Facebook Marketplace
卖：家里闲置一键上架
归属：居住 × 售后与退出（闲置出售），●。
| 环节 | 人自己做 | 交给 Agent |
|---|---|---|
| 需求传达 | -和大量买家沟通：回复还在吗、议价、约时间 | -拍几张照片，说一句帮我卖掉，成本极低 +Agent 替用户回复询价、议价、约时间 |
| 需求执行 | -查行情定价、写描述（认知负荷） -等回复、应付爽约（被动在场） -砍价拉扯（心理成本） 享受接近零 | +省下线下交接以外的全部执行成本 |
| 需求验收 | -每条消息都要看，多次检查 | -确认一次定价和文案 +是否成交、钱是否到账，结果自证 |
| 结算 | / | -家中照片、交接地址的隐私 收费可按成交额抽成 |
买：盯 deal
归属：居住或休闲旅行 × 选择（◐），叠加持续监控。
| 环节 | 人自己做 | 交给 Agent |
|---|---|---|
| 需求传达 | +无成本 | 找具体物品（某款书桌、50 美元以内、5 英里内）：-低 找好 deal 本身：-高，依赖品味和 Context |
| 需求执行 | -反复刷新、怕错过（被动在场、记挂） -抢在别人之前联系卖家 +淘货的乐趣（对爱逛的人很大） | +全天盯守，新上架即时筛选、即时联系 -失去淘货乐趣 |
| 需求验收 | +每条当场看完 | -看推送来的几条候选，远少于自己刷几百条 +多次检查合并为每次命中一次 |
| 结算 | / | -低 |
用例二：房东收租、对账、跟进租客和政府部门
归属：横跨多格。财务 × 记录归档（对账、更新表单）●；居住 × 触发与记挂（租金到期、未到账）●；居住 × 售后与退出（租客问题、报修）●；证件与公共事务 × 办理（政府部门）●。
| 环节 | 人自己做 | 交给 Agent |
|---|---|---|
| 需求传达 | -和几十户租客、政府部门反复沟通，催款最难开口 | -一次性设定规则：有钱进来更新表单，没钱进来发催款信，询盘按预设问题回复，过了筛选再通知我。之后每次接近零 +替用户催款、回复询盘 |
| 需求执行 | -每月逐户对账（主动操作） -回复询盘、等租客回复（被动在场） -记住谁交了谁没交（认知负荷） -催款、和政府打交道（心理成本） 享受为零 | +省下几乎全部 |
| 需求验收 | -每月每户都要检查 | -只看例外：未到账、筛选后的询盘 +正常情况无需检查 |
| 结算 | / | -银行账户和租客个人信息的隐私，涉及第三方 收费：用户原本要付给物业管理公司，付费意愿高 |
用例三：打客服电话砍网费
归属：居住 × 售后与退出（砍网费）●，也可归入财务 × 售后与退出（砍账单）。
| 环节 | 人自己做 | 交给 Agent |
|---|---|---|
| 需求传达 | -和客服、挽留专员谈判，要组织说辞 | -一句话加账户信息 +Agent 替用户和人谈 |
| 需求执行 | -排队几十分钟，还要防 session 超时（被动在场） -了解竞品报价和挽留话术（认知负荷） -对抗挽留、开口砍价（心理成本） 享受为零 | +省下全部 |
| 需求验收 | +通话结束就知道结果 | -核对新账单金额，查是否附带新合约期、是否删了服务 下一期账单出来才算完全确认 |
| 结算 | / | -账户凭证和身份验证信息的隐私 收费可按节省额分成（Rocket Money 收首年节省额的 35%–60%） |
主要限制是频率低，一年一次。中国的宽带话费金额小，改套餐大多能在 App 内完成，这个用例在中国的损益明显更弱。
3.2 用损益模型扫总表
结算为正的任务有五个特征，满足得越多，结算越正：
- 要和人或机构打交道：传达和心理成本都转给 Agent；
- 延时完成或多轮往返：被动在场转给 Agent，多次检查合并为一次；
- 结果自证：钱到账、预约成功、已成交，验收成本低；
- 重复且规则明确：传达一次设定，按次摊销；
- 过程无享受。
结算为负的特征：偏好隐性且验收等于重做；路径已被 App 优化到两步以内；时效以分钟计而 Agent 并不比人快；需要高敏感凭证而收益很小。
按环节扫：
| 环节 | 传达 | 执行 | 验收 | 结算 | 判断 |
|---|---|---|---|---|---|
| 触发与记挂 | +一次设定 | +省下记挂 | +只在触发时通知 | 隐私成本低 | 正。要超出日历和平台提醒才算数：触发源是零散的非结构信息（学校邮件、账单、合同）时成立 |
| 选择 | 品味型 -；约束型 + | 享受时 -；义务时 + | 品味型等于重做 - | 低 | 看情境，见第 2.3 节 |
| 办理：消费 App | -比点按钮慢 | 节省很少 | 当场完成 | 低 | 负 |
| 办理：机构 | +约束明确 | +规则复杂、表单多 | 结果自证 | -身份证件等高敏感信息 | 正，隐私成本高 |
| 办理：稀缺资源 | +条件明确 | +一直盯守 | 结果自证 | 低 | 对单个用户为正；涉及公平（Agent 黄牛化） |
| 履约等待 | +无需传达 | +省下盯守 | +合并检查 | 低 | 已有推送的（物流）收益为零；需要人去催、去查的（审批进度、等师傅）为正 |
| 售后与退出 | +替用户和人交涉 | +排队、拉扯全部省下 | 结果自证 | 可按结果收费 | 正。五个特征全满足的格子最集中 |
| 记录归档 | +规则一次设定 | +省下枯燥整理 | 例外制下低 | -财务信息隐私 | 正 |
按领域扫： 对手方多、义务性事务多的行（财务、证件与公共事务、居住、健康医疗、家庭照护），正结算的格子多。以消费体验为主的行（饮食、衣着个护、休闲旅行），机会集中在售后与退出一列，选择一列看情境。
3.3 最终确定的需求域
1. 对抗摩擦的事务
- 范围：退订、退款、索赔、砍账单、投诉，或者和机构办事，比如签证、报销、预约。
- 对用户的收益：Agent 替用户和机构交涉，减少传达成本；排队、拉扯、理解规则全部转给 Agent，减少执行成本；钱是否到账、预约是否成功，结果是自证的，验收成本低。
- 限制：频率低，撑不起日活。且消费者 App 的摩擦分布不对称，买入时的摩擦被无数 PM 压到最低，因为平台从购买中赚钱，一定会鼓励用户多买，但退款时的摩擦被保留甚至刻意加高，因为摩擦帮机构留住收入。既然摩擦帮机构留住收入，那么机构就可能不允许 Agent 来降低这种摩擦。
2. 人原本会放弃的事
- 范围：闲置出售、小额索赔、未领取的权益、遗忘的订阅。
- 对用户的收益：原本不会发生，所以 Agent 只要做得好就是净收益。传达成本低（拍几张照片、一句话），或者为零（Agent 主动发现）；执行全部转给 Agent；验收成本低，结果自证。
- 限制：边界很难把控，很容易出现“我本来不想让你帮我做这件事”的情况，但是可以靠RL 让模型逐渐学习什么是需要帮用户做的，什么不需要，并控制 proactive 的频率上限来解。
3. 监控加通知
- 范围：降价、放票、余位、专家号、考位、二手 deal。
- 对用户的收益：省下无限的盯守，验收由原来的多次查看合并为一次验收。需求在 LLM 之前就被付费验证过，12306 抢票软件、比价和历史价格工具都有大量付费用户。LLM 的增量在长尾：任意网站、任意条件、用自然语言定义触发规则。
- 限制：热门场景已有平台自带提醒，增量小。自动抢购时效以秒计，要求执行极稳定；【事实】Meta 内部测试中，员工用 Muse 盯票和快速售罄商品时遇到很多导致不可靠的失败模式。Agent 抢号还带来公平问题。所以监控加通知成立，自动抢购受限。
4. 家庭与多方协调
- 范围：家庭日程、学校通知、报名接龙、远程替父母办事；社交关系行的多人约时间。
- 对用户的收益：省下记挂和多人之间的反复沟通，主要减少的是心理成本，但只涉及省时间，不涉及省钱，用户感知最弱。
- 限制：很难做，比如 Agent to Agent 约时间，很容易出现 Agent 和人的真实意图不一致的情况（Agent 替你答应了，但你其实不答应，如果加上确认环节，那成本和自己约是一样的，并不更划算）。单次价值低，要和日历、平台提醒拉开差距；省下的价值看不见，需要账本显性化，比如本周替你处理了哪些通知、约好了哪些时间。
当然，这几个需求域也是结合我的直觉选中的，如果本来就在做本地生活，那么对于上面总表里列出的各个子项，可能有更准确的价值判断，或能看到我没看到的需求。但就拿我看到的这几个需求域来讲，确定了这些需求域，接下来就要思考怎么落地，分为两个问题：
- 技术怎么配套，产品怎么做，能够把事情办好，满足用户需求
- 商业化怎么做
以下内容让 Claude Code 做了点探索，但明显深度和切合实际的程度并不够，还得去找人聊。
4. 与这些需求配套的技术/产品方案
4.1 云还是本地？
结论：模型推理在云端，这一点本地和云端 Agent 相同。云还是本地，问的是 Agent 其余部分放在哪里。面向手机用户，其余部分也要放在云端，手机做遥控器、钥匙和审批终端。
拆开看：Agent 由哪几部分组成
- 模型：思考，决定下一步做什么。本地 Agent 和云端 Agent 都通过 API 调用云端模型。
- 循环（harness）：拆任务、调用工具、管理上下文、判断是否完成。
- 执行环境：浏览器、App、文件、账户，动手的地方。
- 状态：记忆、凭证、任务进度、定时任务。
第 2 到第 4 部分放在用户的设备上，就是本地 Agent；放在厂商的服务器上，就是云端 Agent。
电脑能做本地 Agent，手机做不了
四块需求域都是跨时或持续的任务：排队几十分钟、和机构往返几天、全天盯价格和号源。循环和执行环境必须在用户不看设备时一直活着。电脑和手机的区别有三点：
- 能否常驻后台。 电脑插着电、设成不睡眠，一个进程可以跑几天。iOS 会挂起后台应用，后台任务只给很短的运行时间；Android 也有省电限制。在手机上等 40 分钟电话、每 5 分钟查一次价格，都无法可靠运行。
- 能否操作别的应用。 电脑上一个程序可以驱动浏览器、读写文件、执行命令。手机上每个 App 都在沙盒里，一个 App 不能操作另一个 App，除非拿到系统级权限（手机厂商）或无障碍权限（豆包手机助手、AutoGLM 这类方案）。即便拿到，操作也要占用前台屏幕，这段时间用户自己用不了手机。
- 供电和网络。 电脑插电，网络稳定；手机靠电池，网络时断时续。
云端和本地 Agent 的架构区别
两者循环的逻辑相同。架构上的区别来自两个事实：云端的执行环境不带用户身份；云端集中存放大量用户的凭证。
| 部件 | 本地 Agent | 云端 Agent |
|---|---|---|
| 模型 | 调用云端 API | 调用云端 API |
| 执行环境 | 用户自己的浏览器：已登录、设备可信、家庭 IP | 云端浏览器：没有登录态，要用存下的凭证重新登录；陌生 IP 和设备容易触发风控，短信验证码要转回手机 |
| 凭证 | 存在用户自己的电脑上 | 集中存放，一旦泄露影响所有用户。凭证要与模型隔离，模型只能使用、看不到明文；对外连接要过闸门，防止网页里的提示注入把数据带出去 |
| 任务调度 | 机器开着就跑，关机就停 | 持久化的任务队列：定时唤醒、失败重试、重启后从断点继续、多个任务并发 |
| 人工确认 | 在屏幕上弹窗 | 推送到手机，任务挂起等待审批 |
| 执行成本 | 用户自己的硬件和电费 | 厂商为每个用户付虚拟机费用，按活跃时间计，闲置时可以挂起 |
【事实】Muse 给每个用户一台云端虚拟机，内含浏览器、运行环境和存储；独立的 Sentinel 进程审批所有对外连接；凭证存放在单独的服务里，模型接触不到明文密码。这对应表中执行环境和凭证两行。
【中美差异】美国的服务大多有网页版，云端浏览器就能覆盖。中国很多服务只有 App 或小程序，云端执行要靠云手机，难度更高。
4.2 独立 App 还是 IM？
结论：高频的交代和审批放在 IM，低频的授权、设置和账本放在 App。重心看需求域。
用户和 Agent 之间只有四种交互：
- 交代任务：一句话，高频。
- 接收结果、审批：异步，高频。
- 授权账户、设置规则：一次性，需要结构化界面。
- 看账本：替我处理了什么、省了多少钱，低频，需要可视化。
IM 天然适合前两种：不用安装；异步对话是现成习惯，通知会被看到；给助理发消息的心智最自然。家庭与多方协调尤其适合 IM，因为协调本来就发生在群聊里，Agent 可以作为一个成员待在家庭群里。
IM 做不好后两种：授权和权限设置需要表单和网页跳转；账本需要可视化。第 1 节推论 2 和省钱的洞见都要求价值被看见，而 Agent 的功劳放在聊天流里会被冲淡。
所以重心取决于做哪块需求：以家庭协调为主（承担留存），重心在 IM；以省钱类需求为主（承担获客与信任），需要 App 承载账本。
【事实】Instinct 只通过短信、iMessage、WhatsApp 和电话交互，任务覆盖订餐、砍账单、预约、订阅审计等，2026 年 8 月邀请制上线，尚未公布定价。Muse 同时提供独立 App、网页和 WhatsApp。【推断】Instinct 的获客摩擦最低，但账本和授权需要另找界面补上；Muse 的组合更完整。
5. 支撑产品存续的商业模式
看起来还是很难搞。
5.1 向谁收钱
钱从获得价值的一方来。按需求域看价值流向：
| 需求域 | 价值流向 | 能向谁收 |
|---|---|---|
| 对抗摩擦、人原本会放弃的事 | 用户得到，机构失去 | 只能向用户收，按省下或拿回的钱分成 |
| 监控加通知（价格类） | 用户省钱，商家得到订单 | 用户分成，或商家佣金 |
| 家庭与多方协调 | 用户省时间，不涉及商家 | 只能向用户收订阅 |
向用户收：按结果分成最好卖。 用户看得见省了多少钱，收费按这个数字的一定比例，没省下就不收。【事实】Rocket Money 按首年节省额的 35%–60% 收费。收费锚定在用户看得见的钱上，不锚定在算力上，这是省钱洞见在商业上的落点。省时间类需求只能订阅，用户感知弱，付费意愿低。订阅的理由要靠省钱类需求先建立，账本把两类价值放在一起呈现。
成本侧： 一次砍账单省下几十到上百美元，分成收入远高于单次任务的推理成本。成本大头在持续运行的任务（监控、家庭协调），要靠订阅覆盖。
5.2 向商家抽佣
佣金和信任冲突。 Agent 拿了商家佣金，就有动机推用户多买、推付佣金高的商家，这和第 1 节推论 3 的信任门槛直接冲突。而最强的两块需求域（对抗摩擦、人原本会放弃的事）本来就是站在用户一边，从机构手里拿钱。
【事实】Honey 靠联盟佣金盈利。2024 年 12 月它被指控在结账时替换他人的联盟链接，并允许合作商家决定展示哪些优惠码；随后被提起集体诉讼，约 200 万用户卸载。
所以佣金只适合用户本来就要买、Agent 只负责找到并下单的场景，而且要披露佣金，不让佣金影响排序。
商家会同意吗？ 商家接受代理商抽佣，从来不是谈判谈出来的，是需求集中的结果。OTA 抽酒店佣金、美团抽餐馆佣金，过程都一样：先用补贴把用户聚起来；等平台占到商家订单的相当比例，商家不入驻就会失去这部分客人，只能接受费率。Agent 要复刻这条路，前提是它掌握足够多的购买决策。现在 Agent 下单只占商家订单的极小部分，没有议价能力，商家的选择是忽略或封禁。