Personal Agent（PA）研讨会整理：从产品体验到模型、Infra与生态

9月30日，云栈社区 围绕 PA 组织了一次闭门讨论。参与者包括 AI 产品创业者、头部 PA 公司或大厂 PA 团队成员、模型和 Infra 技术专家，以及一二级投资人。讨论从 Muse、Instinct、Today 等产品的体验开始，逐渐进入模型、基础设施、商业模式和上下游生态。

一、核心总结

这次讨论有一个有趣的点：大家开始把 PA 理解为一个可以被持续委托的系统。用户交出一项任务以后，它需要在用户离线、信息变化和任务受阻时继续维护状态，并在恰当的时机主动找用户决策。这里的竞争已经超出对话质量，进入上下文、权限、执行、供给、反馈和成本之间的协同。这和年初讨论 OpenClaw 时相比有显著变化。

由此可以形成六项阶段性判断。

第一，持续委托比主动通知更接近 PA 的核心。主动提醒可以制造第一波惊喜，但持续推进、外部结果核验和失败恢复，才决定用户能否长期依赖。主动性应以减少遗漏和决策负担来衡量，不能以通知频次衡量。

第二，上下文是重要资产，但它的价值依赖任务。记录多少信息并不能直接说明护城河大小。更有意义的关系是：新增信息是否改变了行动选择，是否减少了重复解释，是否提高了完成率。同一条上下文，在一个可执行的任务里可能很有价值；在无法接入服务的系统里，则只能改善建议。

第三，个性化正在把 RSI 讨论从基础模型扩展到产品。会议提出把个人经验写入专属模型或轻量适配器的路径，也提出经济性约束。不过，这仍是一种路线选择，并没有证明每个用户都需要训练一个模型。外部记忆、任务状态、可执行经验和参数更新应比较其真实收益。

第四，身份与权限是 PA 承接责任的基础。通用推理能力可以购买，但一个系统能否安全持有账户状态、在授权范围内执行、在授权撤回后及时停下，决定了它能进入多深的任务。权限管理的价值也取决于能否减少打扰，而非不断增加确认步骤。

第五，PA 可能改变软件入口，同时提高某些后端资产的价值。信息聚合和界面操作更容易被代理；库存、交易记录、支付、履约、售后和组织权威状态仍需有人维护。前端流量受冲击与后端能力变得重要，可以同时发生在同一家公司。

第六，中国的独立创业机会需要从具体委托域判断。通用生活入口面临平台生态和信任的竞争，但持续多周、跨主体、需要协调的任务，可能仍有独立产品空间。机会是否成立，要看是否能获得持续数据、可用接口、可核验结果和足够付费，而不是仅凭“垂直 PA”标签。

二、PA 的产品体验究竟发生了什么变化

1. 从知道答案到知道什么时候介入

有嘉宾分享了使用 Today 时的一次惊喜：产品从其桌面活动中识别到旅行计划，随后持续提醒台风可能影响原定徒步路线。用户当时忙于其他事情，没有继续盯着行程，也没有专门要求它跟踪天气，但产品把这个潜在风险重新带到了他的注意范围内。

在这位嘉宾看来，年初大家讨论主动 Agent 时，往往仍需要用户先想好任务、设置触发条件；这次体验更接近一个助理主动发现用户尚未意识到、却与其目标有关的需求。讨论因此从“它能做什么功能”，进入“它是否知道什么时候应该介入”。

主动性的价值可分为三层：发现用户没有想到的问题，提出符合约束的下一步，以及在授权后完成下一步。三者都重要，但商业价值和责任随层级上升。只完成第一层的产品，仍可能成为有价值的提醒工具；要承接持续委托，还需要后两层。

2. 低摩擦入口与控制界面需要同时存在

有嘉宾分享，自己使用 Instinct 主要是处理日历与日常行政事务，最直接的感受是日历接入和使用比较方便。另一位嘉宾则坦言，自己原先倾向于认为 Agent 应该尽量没有 GUI，通过短信等已有渠道交办就够了。但体验 Muse 以后，他改变了部分想法：在他看来，某些能力与自己部署 OpenClaw 并无根本区别，独立 App 却提供了一个普通用户理解得了、找得到的入口，稳定性和开箱即用也改变了目标人群。

这位嘉宾特别强调，极客知道如何部署、发指令和排查问题，普通用户只需要打开一个熟悉的 App。独立 App 的价值，因此可能不在于创造一种此前完全不存在的能力，而在于让能力进入更广的人群。这里的产品相似性是其体验判断，不是本文对两者架构的验证。

两者对应的是不同的用户成本。通信入口降低启动成本，控制界面降低监督与纠错成本。任务越短、风险越低，越适合轻入口；任务越长、涉及资金或多方沟通，越需要清晰的状态、审批和接管方式。少界面可以是设计选择，但“没有界面”不应被当作更原生的证明。PA 可以在聊天中接收任务，在独立页面中展示任务状态、证据和授权。用户未必想看每一步鼠标移动，却需要知道任务是否完成、为何暂停、下一步要决定什么。

3. 单一对话承载关系，任务对象承载工作

主持人提出了一个具体困惑：习惯了 ChatGPT 的会话和项目组织方式以后，为什么有些 PA 更强调一条持续的主对话？

有嘉宾认为，这是在引导用户把 Agent 当作一个助理来相处。他举例说，日常给助理发消息，并不会为每件事分别开一个聊天窗口；只有涉及特定项目或更多参与者时，才另建群聊。

此前另一位嘉宾从组织协作角度提供了不同补充：复杂项目适合独立分支，让人和 AI 围绕同一件事交流；简单事情则可以直接在已有对话或群里处理。在他看来，是否拆会话还与团队原有协作方式有关，未必有统一最优解。

但界面上的一个对话窗口，不意味着后台只能有一条状态。旅行、工作项目、退款和家庭事务仍需要分别保存目标、参与方、预算、期限和授权。否则单一对话可能把用户的关系感做强，却把并发任务的边界做弱。更合理的产品形态可能是一个稳定关系入口加多个明确任务对象。讨论 UI 时，要同时测试用户是否容易交办，以及系统是否能隔离不同任务、避免引用错资料和执行旧计划。

三、生活助理、个人工作与组织流程的区别

会议提出了三层划分，这比直接用 ToB 与 ToC 解释产品差异更有效。

有嘉宾把 PA 分成帮个人处理生活事务、交付个人复杂工作，以及以组织身份推进流程三类，并用销售场景解释最后一层的困难。帮销售整理资料、起草邮件相对明确；如果要求系统每天主动跟进快到期或逾期的客户，就需要知道同事是否已经联系、邮件是否已发，以及谁负责下一步。任务开始依赖共享状态，而不只是个人资料。

层级	委托内容	核心状态	主要难点	结果证据
生活事务	行程、预约、购物、账单和提醒	个人目标、偏好、预算、日历	服务接入、长期跟踪、交易授权	预约确认、订单回执、状态变更
个人复杂工作	研究、文档、代码、分析和多步骤交付	项目资料、文件版本、交付标准	长程执行、产物质量、修改反馈	可复核报告、可运行代码、最新版本
组织流程	客户跟进、多人协同、审批和经营流程	组织规则、责任人、共享记录	权限归属、并发冲突、接管与责任	权威业务记录、多方确认、审计记录

基础能力可以跨层复用，商业边界不会因此自然消失。个人能授权的事情，未必是公司允许其代理的事情；个人离职后，组织数据、客户关系和执行权需要回到组织。生活与工作可以共享界面，仍要区分身份、数据归属和预算。

会议中还存在一项更激进的观点：办公 Agent 是过渡产品，未来组织变成超级个体以后，传统文档协作会减少。这个观点值得保留为情景推演。它尚不能支持“办公需求即将消失”的结论，因为合同、审批、组织记忆和跨机构沟通仍需要稳定产物。可以进一步观察 AI 减少了多少中间协调材料，又增加了多少外部交付需求。

提出这一观点的嘉宾认为，围绕 PPT、表格和文档的办公产品，仍在帮助人使用旧工具；更原生的方向，是让人委托 Agent 产生业务结果。他用未来组织是否还需要这么多中间汇报材料来表达这一判断。

讨论因此出现两种观察尺度：一类关注今天组织如何接入 Agent，另一类关注 Agent 会如何改变组织本身。

四、上下文与执行能力，谁更重要？

1. 上下文优先的逻辑

有嘉宾认为，一个好的个人助理未必是能力最强的，但需要最了解服务对象。沿着这个类比，他提出上下文可能是 PA 长期最重要、甚至唯一的护城河：模型能力可能趋于可采购，工具接口可能标准化，而会议、通话、屏幕和现实世界中的个人信息尚未完整沉淀。

这位嘉宾没有只看手机和 PC，而是按工作日、休息日以及一天中的不同时间，讨论耳机、手表、录音设备和车载等入口。他认为工作时间里有些高价值语音信息尚未被留存，新硬件或 OS 可以帮助占据这些入口。

主持人继续追问：未来会是端到端软硬件公司，还是一个类似安卓的系统向多个硬件厂商赋能？嘉宾倾向于把 OS 理解为服务上下文采集的手段，同时承认这一层对生态位置、团队能力和出货规模要求很高。由此可见，“做硬件”是其提出的中长期路径，并非低门槛的普遍创业建议。

会议特别指出，信息量与信息价值并不相同。工作场景里的一句承诺、约束或者关系变化，可能比长时间的低价值音视频更重要。不同日期和设备产生的信息也具有不同密度。

上下文可以拆成四类：稳定偏好、最新事实、待履行承诺和当前任务状态。偏好需要允许纠正，事实需要更新时间，承诺需要责任人与期限，任务需要完成和取消状态。把四者全部压缩成一个用户画像，容易使记忆失去可执行性。

2. 执行优先的逻辑

另一位嘉宾提出了不同侧重：他过去也认为收集个人全量上下文最重要，但现在更关注系统到底能不能把事情做完。

他举了订酒店的例子：PA 即使知道预算、日历、目的地和细微偏好，如果最后无法接入合适的酒店供给，了解用户仍然不能完成这次委托。他因此认为，访问服务和完成闭环的能力，至少与上下文同样重要。

这位嘉宾还分享了自己的使用思路：把已有 AI 产品中积累的个人信息整理成几个文件，再迁移给新的 PA，已经能获得相当一部分有效背景。他用这个经验说明，有些任务并不需要先收集完整生活。这里是个人体验，不能推算所有用户的记忆可迁移比例。

有嘉宾随后用此前创业经历补充了这个问题。他回顾，团队最初通过多轮对话推断用户画像，再推荐用户可能需要的内容，效果并不理想。之后分别尝试把搜索做好，以及把交流语气和交互调得更像用户习惯的方式，也没有单独达到预期。

据这位嘉宾描述，后来把任务能力与更自然的表达拼在一起，产品才出现明显增长；个性化则是在这两项已经较好之后，通过对照测试产生进一步留存收益。他由此提出一个顺序：先把核心需求做实，再降低认知负担，然后加强个性化。

上下文可能是长期资产，但产品早期还需要先跨过“有用”和“容易用”的门槛。

3. 这两者矛盾么

上下文帮助系统判断什么适合我，执行能力决定它能为我改变什么。任务越长、约束越多，个人状态越重要；任务越接近交易和履约，供给与权限越重要。

因此，判断一家 PA 公司，不能只问它知道多少关于用户的信息。还要问：这些信息是否改变了行动，是否减少了重复解释，是否提高了完成率。

更多数据不一定形成更好的资产。持续有效、能够改善结果的数据，才有可能积累价值。

实验	保持不变	改变什么	能回答什么
上下文增益	同模型、同工具、同任务	少量关键上下文与更完整背景	多收集信息是否提高成功率
记忆增益	同信息、同权限	普通检索与可更新状态记忆	记忆工程是否减少遗漏与旧信息错误
执行增益	同模型、同上下文	工具接入和供给覆盖	产品是否卡在服务能力
学习增益	同类后续任务	是否使用经核验的历史经验	使用是否让未来任务更容易完成

五、PA 会要求什么样的模型

1. Omni 是能力维度，个性化是适应维度

主持人先提出一种担心：如果 PA 需要自研多模态交互模型、专项小模型和执行模型，架构与投入会变重，这是否对应用创业公司不利？

有嘉宾回应，现有主流模型已经能支持一些不错的产品体验，真正可能改变范式的地方，未必只是支持更多模态，而是如何把持续增加的个人上下文转化为个性化能力。他并没有否认更强模型的价值，而是把关注点从通用能力提升转向用户适应。

两者不互相排斥。多模态能力决定系统能从哪些环境观察和交互；个性化决定它如何根据这个人的目标行动。即使拥有强大的多模态模型，系统仍可能不知道哪件事更重要；即使非常了解用户，缺乏屏幕理解和工具能力也会限制执行。

另外头部 AI 公司和大厂会彻底从模型预训练入手，且窗口期很短。但应用公司应先判断目标任务在现有模型下的缺口，再比较采购、后训练、小模型和自研的成本与增益。

2. 个性化为什么可能进入模型层

会议提出，持续积累的个人信息不可能无限塞入提示词，未来可能训练个性化的交互模型或专项模型，通过轻量适配器支持不同用户。这对快速训练、自动整理数据和多用户推理提出新需求。

有嘉宾用轻量适配器作比喻：通用模型像共享主体，个性化部分像针对某位用户加上的配件。真正困难的不是在不计成本时训练一次，而是每个人的数据格式和任务都不一样，怎样自动整理、低成本更新，并且不损害其他能力。

主持人沿着这一点追问训练与推理的变化。嘉宾进一步提出，共享基座之上按需加载不同用户的个性化部分，可能比给每人单独部署一个完整模型更经济。他认为，真正的挑战不在于不计成本地训练一次，而在于每个人的数据和任务都不同，系统如何自动整理、持续更新，并且不损害其他能力。

个性化载体	更适合承载	需要注意	验证方式
Context 与检索	当前资料与少量相关事实	找错材料、上下文膨胀	同任务正确率与读取成本
可编辑 Memory	偏好、承诺、关系和长期状态	旧信息污染、纠错与删除	修改后是否立即改变行为
Skills 与 Routines	可复用步骤、工具使用经验	旧规则失效、错误重复	相同任务是否更快更便宜
轻量适配器或小模型	稳定表达与特定行为模式	数据不足、过拟合、基座升级	对照检索方案的增量收益
主模型更新	多任务共享能力	训练成本、回归与遗忘	跨任务提升与回归评测

3. 从 Model RSI 到 Agent 与 Product 改进

过去我们讨论 RSI，主要关心 AI 如何帮助改进模型。但 PA 提出了更贴近用户的问题：它能不能从我纠正过的事情中学会，下次少犯同样的错误？这些经验可以进入不同地方。有些是可编辑的记忆，有些是工作流和工具使用经验，有些可能适合训练进小模型或轻量适配器。

这次讨论提出了一条值得跟踪的路线：用共享模型承载通用能力，用更轻的个性化部分承载用户差异。如果它真正有效，就会需要自动整理数据、快速更新、评测和低成本服务。

这就涉及到在整个架构里，产品和 Infra 系统能否把用户纠正、执行失败和满意结果转为持续改进信号，并持续改进模型（RSI）。

嘉宾提到可以建立一个具体闭环：记录任务轨迹和结果证据，定位失败属于意图、数据、模型、工具、权限还是供给，生成针对性的修改，在新旧任务上评测，再部署或回滚。直接把所有历史对话送入训练，无法替代这个过程。

以及区分三种变化：写入新事实是记忆更新，调整工作流是 Agent 改进，训练模型是模型更新。只有形成自动诊断、实验、评测和部署链路，才可以进一步讨论自我改进程度；并非所有产品学习都构成递归自我改进。

六、哪些 Infra 可能承接新增价值

会议问题把 Infra 拆成上下文采集和上下文使用，也讨论了云手机、云电脑、Identity、Security、Memory 与 Runtime。进一步可将其映射到持续委托的具体责任。

层级	PA 新增要求	可积累资产	商业验证问题
身份与授权	按任务、动作、时间和预算授权	权限策略、接入深度、执行记录	客户是否愿为减少错误和扩大授权付费
持久 Runtime	用户离线后保持状态、恢复与取消任务	状态管理、调度和恢复工程	相比通用工作流系统新增什么价值
执行环境	浏览器、手机、软件和登录状态	环境兼容、快照、接管与调试能力	是资源租赁还是不可替代的执行平台
Memory 与经验	事实纠错、状态更新、可执行经验	经过验证的任务与反馈	导出记忆后产品优势是否仍存在
个性化训练与推理	自动整理数据、小步更新、多适配器服务	训练策略、评测与部署效率	客户是否已经采用参数个性化
服务与交易接入	查价、预约、支付、履约和售后	供给关系、标准交易状态	接口稳定性、收费权与平台议价能力
结果验证	区分生成、动作成功与业务目标达成	证据、评测任务、错误分类	能否直接降低接管与失败成本

1. 云手机与云电脑有需求增量，不等于新护城河

有嘉宾结合云手机实践表示，团队内部已经尝试过跨应用搜索和多模态信息采集，令他最担心的并不是演示能否跑通，而是规模扩大后会触碰平台边界。他举例说，自动操作可能跳过平台原本要求用户经历的推荐、排行榜或广告环节，技术成功与平台接受是两个问题。

另有嘉宾从投资机会角度提出，云手机和云电脑可能更多是已有 IaaS 需求的扩展，未必天然形成一个新的独立市场。前者讨论“是否能做”，后者讨论“价值由谁获得”，两者共同把问题推进到了规模化供给与收费能力。

资源需求增长可能利好既有供应商；如果产品只出售一台远程设备，差异化容易受云厂商与价格竞争压缩。如果它进一步解决长任务恢复、真实应用兼容、凭证隔离、可接管操作和评测，才可能形成更深的产品价值。

2. Identity 与 Security 的价值来自可用的授权

安全不是只判断一段输出是否危险。PA 需要知道由谁授权、为了什么任务、能对哪个对象执行什么动作、允许多少预算、授权何时失效。组织任务还要解决一人授权是否能影响共享资产的问题。

这一层有成为重要基础设施的潜力，但独立公司仍需要证明产品具有跨模型、跨平台的适用性，客户会单独采购，而不是由入口厂商内部实现。中国客户尤其需要看到接入周期、维护成本和可量化收益。

3. 多用户个性化服务是一项条件性机会

共享基座加不同用户适配器，可能带来快速加载、隔离、版本管理、批处理效率和回归评测需求。可从已有方案出发优化，无需先假定是全新市场。

成立条件是：参数个性化的收益显著高于外部记忆方案，客户确实愿意部署，且适配器在基座更新后可以维护。若这些条件不成立，相关需求可能主要落在 Memory、路由和工作流工程上。

七、算力影响应从工作负荷而非在线时长估算

有嘉宾认为，很多 AI 公司面临的经济压力，是买入算力再以服务形式提供给用户，若高频、多模态信息全部进入云端，处理成本可能超过客户获得的增量价值。他因此更看好混合路线：在数据产生的地方完成一部分上下文处理，复杂能力再调用云端。

他用企业内部协作和无人机集群作类比，设想节点可以直接交换信息、共同完成任务，减少对远端中枢的依赖。主持人进一步提出，多 Agent 未必需要每个节点各自重复完成一整套工作，也可能通过基础设施层的分工提高整体效率。这些是架构推演，不是本次会议提供的效率测试。

端云混合是一条重要路线，但“端侧必然经济最优”仍需要按任务测量。设备算力、能耗、散热、内存、模型质量和硬件适配都影响结果。

首先应区分三种持续性：持续可被联系，持续观察相关事件，以及持续进行模型推理。PA 可以通过定时任务和事件触发保持在线，并不需要全天运行大模型。

工作负荷	可能的处理方式	主要成本变量
唤醒与简单信号检测	规则、端侧小模型、事件通知	设备能耗、误触发
语音与屏幕预处理	端侧、云端或混合	采样率、数据传输与质量
事实提取与任务更新	小模型和结构化处理	更新频率、记忆准确性
复杂规划与决策	云端较强模型或专门模型	推理长度、重试频次
工具执行	API 或 GUI 加执行环境	动作数、环境占用、错误恢复
个性化学习	按需训练、批量评测	样本量、更新频率、适配器部署

PA 可能同时推动少量高强度训练、大量小步个性化，以及广泛的推理和执行环境需求。它们对应不同基础设施，不能合并为一个“GPU 需求暴涨”结论。所以建议用任务经济账衡量：每成功任务成本等于全部尝试的推理、环境、通信、训练分摊与人工兜底成本，除以最终成功任务数。失败任务和人工接管必须进入分子。收入还要扣除支付、渠道和售后成本，再讨论贡献利润。

八、PA 会怎样改变 AI 产品和传统软件

当用户开始让 Agent 搜索、比较和操作软件，一些产品的前端入口会受到影响。但入口变化，并不意味着所有原有平台都会失去价值。会议提出了一个重要区分：用户入口可能转移，后端服务仍可能保持价值。有效库存、支付、履约、售后和组织里的权威记录，仍然需要稳定系统维护。Agent 可以减少用户点击，却不会凭空创造这些能力。

资产类型	可能发生的变化	更值得检查的价值
信息聚合与推荐界面	部分搜索和浏览由 Agent 完成	独家信息、更新速度、推荐质量
依赖人工点击的软件功能	操作步骤被代理	权威数据、业务规则、接口与权限
通信与支付能力	Agent 增加可调用动作	可靠性、覆盖度、成本与责任
商品、服务和交易平台	客户入口变化	有效供给、履约、售后与信任
办公产物工具	部分交互被通用 Agent 承接	稳定格式、协作记录、专业能力
组织业务系统	UI 可能弱化	权威状态、审计与流程约束

会议以 Twilio、Shopify、旅游平台、二手车交易和零售平台作类比，讨论了通信管道、货架和收银台、库存与物理履约的区别。这里保留的是资产分析方法。个别公司是否已接入某款 PA、具体协议、市场份额、广告测试和库存数字，未完成独立核验，不进入结论。

一位嘉宾从上市公司商业形态出发，把 Twilio 类比为 Agent 办事过程中消耗的通信管道，把 Shopify 类比为货架和收银台。在她看来，消费者使用的入口可以变化，但商品、订单和付款仍需要后端系统支撑。这个类比把“软件会被替代”的笼统问题，拆成了界面与服务能力的不同命运。

她还举了买二手车的例子：用户并不是只找一个商品编号，而是要比较车况、价格、融资、旧车置换、手续和交付。PA 可以减少前端搜索与沟通，但如果一家平台已经把检测、库存、融资和配送组织在一起，它的后端价值仍可能存在。

围绕零售平台，她提出另一组利益关系：依赖用户浏览广告的平台，可能不愿把入口交给 Agent；广告依赖较低、希望获得新增订单的供给方，可能更愿合作。主持人据此总结，既有交易与履约网络未必被快速替代，广告收入和客户入口却可能受到不同程度影响。

另外 PA 可能减少用户浏览赞助结果的时间，改变平台广告变现。但不能由此宣布广告消失。平台可能限制自动调用、提供合作入口、改变收费方式，或者向 Agent 呈现商业排序。购买代理则需要明确自己的目标和收费来源。

综合看，Agent 能比较商品，并不等于能替代支付、库存、售后和履约平台；Agent 能操作软件，也不等于替代了软件保存的权威业务状态。

交易平台类公司如 Amazon 具备较长链路的上下游网络，受到 PA 的影响可能较小，更多是广告收入的下降。但其他类别应用可能会受到入口产品覆盖。不过若掌握长期任务状态、专业规则、独家反馈或实际服务关系，底层能力提升可能让它承接更复杂的任务，减少 PA 产品的影响。

九、商业模式的分歧——如何把 PA 变成收入

会议有两条不同思路。一条强调 PA 应从成本中心转为帮助用户创造利润的合作方，通过成果或收益分成建立模式；另一条强调只要解决新需求，订阅、广告、抽佣和服务费仍可成立，未必需要全新商业模式。

有嘉宾认为，客户把 AI 看成成本中心时，会不断压低采购价格；如果 AI 与客户共同创造收入，就可能有不同的收费空间。他举出两类经历作对比：帮助客户生产内容、节约费用，未必能分享多少节省；参与直播销售，则可以围绕成交结果分成。这里保留商业逻辑，不披露客户名称与项目经营数字。

这位嘉宾因此更看好 PA 成为个人或企业的利润单元，以合作和收益共享的方式收费。他的关注点是 AI 如何参与价值创造，而不只是提供一个需要付钱的工具。

另一位嘉宾接着提出，商业模式未必需要创新。广告、抽佣和服务费本身仍可成立，关键是有没有满足过去产品没做好的一类需求，以及谁在新的链条中获得议价权。在这位嘉宾看来，长周期、跨应用和需要协调的任务，比短程的买什么、吃什么更能解释独立助理的必要性。

这一来一往并没有否定任何一种收费方式，而是形成了两个评估问题：产品创造的价值是什么，以及它是否有权、也有能力分享这部分价值。

两者都指向价值创造，但对收费权的理解不同。

模式	适合的价值	成立条件	关键难点
订阅	持续协调、节省注意力、稳定工作流	高频复用和可预期成本	重度用户亏损、低频用户流失
按任务或用量	价值与消耗差异明显的交付	任务边界和成本透明	试错收费可能抑制委托
交易抽佣	促成预约、购物与服务成交	平台允许、收费权明确	分佣能力、推荐利益冲突
成果收费	获得退款、达成订单等可验证目标	成果与基线可定义	归因、争议、回款周期
收益分成	与个体或企业共同创造增量利润	持续业务参与、可审计结果	增量归因、波动与运营成本
广告或商业推荐	帮助用户发现产品和服务	披露商业关系、保持有效性	信任和用户目标冲突

节约成本同样可以支持付费，创造收入也不保证能收费。成果分成需要回答没有 Agent 时会发生什么、谁确认增量、什么时候结算，以及 Agent 承担了哪些运营风险。难以归因的工作流可以采用订阅，容易定义结果的任务则可测试按成果收费。

旅游为什么适合体验，又未必适合订阅

旅游有明确目标、多约束、多供给方和持续跟进需求，也可能在短期内产生高强度使用。因此它适合展示 PA 的协调价值。但低频、售后复杂、交易授权和平台依赖会影响商业化。

有嘉宾提出，旅游未必全年高频，却可能在准备和出行的一段时间内密集使用，适合作为首次建立信任的场景，再向其他任务扩展。另有嘉宾解释，旅游之所以需要助理，是因为涉及外部信息和协调方多，用户没有足够注意力持续盯着；相似的问题也存在于工作项目里。

也可以看到最近各家 PA 产品都把旅游作为核心用例之一。

因此，同一家公司可能同时面对两件事：原有流量价值下降，后端服务价值上升。分析它是否受益，需要拆开它究竟拥有的是界面、信息、供给，还是现实世界中的履约能力。

这对 AI 创业公司也是一样。如果价值只来自把通用模型包装得更方便，入口产品可能逐步覆盖它。如果公司掌握的是长期任务状态、专业经验和真实服务关系，更强模型可能让这些资产承接更大的需求。

十、中美生态差异与中国创业空间

中国 PA 绕不开平台生态，工作和生活信息大量存在于 IM 和超级 App 里，跨平台调用同时涉及技术、平台规则与商业利益。所以会议中大家普遍关注了中国数据孤岛和平台利益。美国也存在平台限制与商业冲突，两地差异主要是程度、接口与任务习惯。

有嘉宾用一趟出差串起中国生态的困难：机票酒店、餐厅、导航、沟通和支付，可能分别需要进入不同平台。一个 PA 如果想统一完成，就不能只理解需求，还需要这些平台允许它行动。她因此更看好拥有较广交易供给，或掌握身份、通信和小程序生态的平台。

另一位嘉宾则从需求侧给出补充：大厂已经做得很好的短程任务，未必需要一个新的个人助理；但跨几周的项目、多个参与方的沟通、变动约束下的持续推进，并没有被一个简单入口完整解决。在他看来，创业公司可以先在一个场景里获得托付，再逐步扩大范围。

维度	会议与既有研究提出的差异	要进一步核验什么
工作上下文	邮件、日历与 SaaS 分散接入，对比 IM 和超级 App 集中	目标客群真正使用什么系统
服务接口	部分场景 API 较易使用，对比跨平台调用受限	读写动作覆盖、稳定性、合作条件
任务入口	多入口分工，对比超级 App 聚合	用户是否接受独立委托入口
交易与支付	独立服务拼接，对比平台内交易闭环	PA 能否获得真实收费与履约权
商业关系	平台广告与调用冲突两地均存在	哪些供给方有动力开放
创业路径	跨服务助理，对比生态合作或专业长任务	接入成本、付费与扩展性

中国创业公司的四类候选切入点

一是跨时间的工作协调。项目承诺、跨团队交接、外部沟通和进度跟踪，难以被一次问答完成。机会依赖获得相关工作状态和执行授权。

二是专业领域的复杂委托。明确目标、约束和结果的任务，可能比“通用生活秘书”更容易建立收费与信任。但需要控制专业责任、服务深度和交付成本。

三是新上下文入口。某类设备或软件如果能持续获得别人难以取得的高价值信息，并直接改进任务，可以形成入口优势。单纯记录更多内容不够。

四是为 Agent 提供后端能力。可调用的服务、可靠的任务状态、结果验证、授权和恢复，可以服务多个入口。关键是拥有真实客户需求和付费权，避免只建一个概念性 Agent OS。

十一、A2A 网络何时真正形成价值

会议中的积极观点认为，成熟 PA 会推动新的服务直接面向 Agent 开放，最终形成 Agent 与人的协作网络。端侧协作也被提出为可能改善效率的路线。

有嘉宾进一步提出，理想的 Personal Agent 应当真正属于个人：用户可以选择模型和供应商、迁移自己的信息，甚至自行部署。他关注的不只是产品是否知道用户偏好，还包括控制权掌握在谁手里。

另一项较强的观点是，过去很多平台帮助人弥补搜索、比较和协调能力的不足；当 Agent 可以完成这些步骤，服务可能重新面向 Agent 组织。提出这一观点的嘉宾认为，稳定使用 PA 的人增加以后，会推动供给方开放或出现新的供给网络。这个预测解释了其对 A2A 的乐观，但平台何时开放、哪些中间层会消失，仍需要实际交易和供给数据验证。

所以有三件事：一个产品内部启动多个子 Agent，不同供应商之间交换任务，以及更多用户和服务加入后使现有用户受益。前两者是技术协作，第三者才涉及网络效应。

A2A 可能重组互联网的交互和服务组织，不能据此说互联网基础设施不再需要。新的协作仍依赖身份、发现、通信、交易、履约和争议处理；消息互通也不自动解决这些问题。

真正的验证指标是跨主体任务成功率、协调时间、错误或重复动作、费用，以及新增节点是否改善了既有节点的体验。会议对开放平台增长的描述没有足够数据证明因果，暂不作为网络效应证据。

十二、什么指标证明 PA 进入拐点

最后，我们讨论了怎样判断 PA 进入拐点。这是个开放性问题，比较难回答。

指标	建议口径	为什么重要
闭环成功率	启动任务中，达到预先约定且可外部核验目标的比例	区分生成结果和实际完成
持续任务留存	初始用户中，第四周、第八周仍有有效持续任务的比例	识别持续委托是否形成
有效场景覆盖	用户在滚动周期内，实际成功且再次委托的场景数	区分功能列表与真实依赖
人工介入	接管比例、人工分钟数、审批负担分别统计	防止隐藏人工和成本
主动性净价值	采纳情况、重要漏报、无效打扰与实际处理结果	判断是否减少注意力负担
记忆可靠性	纠正后复发、删除后误用、旧状态错误	判断了解用户是否真实有用
单位经济	每成功任务全成本，扣变动成本后的收入	判断去补贴后能否增长
信任与授权	自愿扩大授权、撤回与错误率	判断用户是否敢持续托付
技术凸性	更强基座下，可付费任务扩大且专有增益保留	判断公司价值是否随技术进步增长

总结

这次研讨会应该是国内 PA 领域的第一次线上交流。

总结来看，未来 PA 值得关注的，不只有个人助理这个产品形态。它还可能带来持续执行、个性化学习、身份权限和 Agent 服务供给的新需求。

我们都看好 PA 这个产品形态带来的模型、Infra、算力和上下游生态的新机会。接下来可以期待的，是这些需求能否形成可靠的任务结果和可持续的经济账，以及全球 PA 市场会怎么演进出一个新的格局。