# Agent 可以替我办事，到哪里应该停下来？

Next Token 博客

查询、下单、付款、对外承诺，是委托 Agent 时不同的权限层级。助理与数字分身的差别，就藏在每一次"要不要先问一下"里。

发布：2026-10-08
更新：2026-10-10

把订酒店这件事整个交出去：告诉助理出行时间和预算，然后等结果。听起来很省事，但中间藏着无数个决策点——住哪个区、什么价位、选哪条取消政策、以谁的名义向谁确认了什么。委托不是一句话，而是一串需要划界的问题：Agent 替人办事，从哪一步开始应该停下来问人？

## 助理，不是分身

Personal Agent 兴起后，一个老问题重新变得现实：这类产品究竟是用户的助理，还是用户的数字分身？目前这一波产品的共识落在助理上——管理邮件、管理日程、订机票订酒店，这些过去由秘书承担的事务。助理与分身的区别不在能力清单，而在意志：助理执行用户的决定，在重大的地方回头请示；分身则替用户形成判断、替用户表态。

这个定位直接决定权限设计的形状。做助理，意味着 Agent 可以被授予能力，但不应该被默认授予替人做决定的权力。委托的深度也分层：整理邮件、汇总日程，出错可以重来；订错一间房，钱已经花了，行程可能已经变了——风险随不可逆程度上升，请示的点应该跟着风险走。哪些决定仍归主人，需要产品显式划出来，也需要用户自己心里有一份清单。

## 价格只是约束之一

一种推断是：Agent 能搜遍全网，总能找到更便宜的渠道，订单自然会流向出价最低的一方，渠道格局因此重排。这个推断把订房简化成了一次比价。

实际的使用逻辑更复杂。一次被提出的反问是：便宜若以糟糕的体验为代价呢？用户住完会说，以后别从这个渠道订了，这个渠道每次订得都很垃圾。价格之外还有位置、偏好、取消政策和渠道可靠性，这些信息分散在行程本身和历次反馈里。订房这件事需要知道的，不只是当前行情，还有主人的习惯——理想的状态是这些偏好在下单之前就在上下文里，而不是靠订错一次来补课。

因此反馈回路是委托系统的一部分，而不是附加功能：住过之后的结果要能流回下一次决策，否则 Agent 会一直重复同一种"便宜但不对"的选择。只优化价格的委托，等于把最难的判断悄悄推给了用户自己。

## 承诺、付款与分享是三件不同的事

把委托拆开看，至少有四个层级，风险各不相同。读取与整理——看邮件、排日程、汇总订单，风险在于隐私。执行与下单——订酒店、买东西，花的是真金白银，通常值得留一个确认点。对外承诺——取消订单、改期、答复别人"明天下午在家"，以用户的名义产生了真实世界的义务，撤回成本发生在现实里。分享信息——把行程、地址、财务状况告诉其他服务或其他人，一旦给出就可能收不回来。

层级不同，授权方式应该不同：读取可以一次授权长期有效，下单逐笔确认，对外承诺和分享信息则应该是最高门槛。这里的产品空间还很大。一个具体的例子是 [Instinct](https://nexttoken.tv/wiki/products/instinct) 的好友网络：加进来的好友可以向助手询问用户的各类信息，产品方据此建议用户只添加真正的亲密好友。用"亲密好友"来框定信息访问范围，本身就是对分享权限的一次设计尝试——边界要比社交软件好友更窄才安全，这样的设定能否成立，仍有待验证。

## 站在哪一边

传统中介和代理有自己的利益，订哪个渠道未必只对用户最优。新一代订房助理刻意与这个模式拉开距离，被概括为"完全站在你这边的，以你的权益为核心的"。定位可以这样宣称，立场却不能只靠宣称：收入来自哪里、与哪些渠道有合作，都会影响推荐的中立性。用户可检验的办法不多，反馈与更换的自由是最实际的一种——助理若经不起"下次别用它"的纠正，所谓站在一边就只是说辞。

## 停下来的地方，就是产品

让 Agent 停下来问，不是能力不足，而是委托关系应有的结构。真正的问题从不是"能不能全部代办"，而是每一类代办对应哪种确认方式：什么一次授权，什么逐次点头，什么永远留在主人手里。助理与数字分身之间那条线，正是一处处停顿连起来的。

## 相关资料

- [助理还是数字分身](https://nexttoken.tv/weekly/005/transcript#quote-64cec465b0931b169aac)
- [订房助理的模式与信任](https://nexttoken.tv/weekly/005/transcript#quote-38c7127987d368463a3f)

## 来源与相关链接

- [网页版文章](https://nexttoken.tv/blog/agent-delegation-boundaries)
- [Weekly #005 完整文字稿](https://nexttoken.tv/weekly/005/transcript)