Personal Agent 产品研究：Instinct 怎样让人愿意再次委托

Personal Agent 要让人愿意反复使用，得让用户真的少操一份心。把操作交出去以后，如果仍要追问进度、重读结果、催它改错，委托就没有完成。

一个 Instinct 使用者在 Reddit 上记录了自己的压力测试：跨应用买零食和监控机票价格，也研究创业公司。他对部分结果满意，却也遇到步骤之间的长时间等待，以及需要人介入的网站验证。他愿意让 Agent 找东西并比价，也愿意让它准备订单，暂时不愿把信用卡交给它自由付款。压力试用原帖

这份反馈比“我的助手无所不能”更值得认真看。一个人可以同时认可能力、继续使用，也坚持把最后一步留在自己手里。用户交出去的是某一件事情，以及其中允许代理处理的部分。产品若把这些差别抹平，就会把谨慎的用户误判成尚未建立信任的人。

我更关心第二次委托：第一次可能来自新鲜感，第二次开始涉及一种现实判断——上次交给它，究竟比自己做省了多少事？

下面以 Instinct 为主案例，沿着一件事从提出请求到等待，再到授权和完成的过程，看 Poke、Town 和 Muse 的不同选择。资料核验截至 2026 年 10 月 3 日。我没有亲自试用这些产品，也没有采访创始人或评论者；公开访谈、文档和使用者自述能帮我们发现机制与问题，尚不足以证明某种设计已经提高留存。匿名帖子有推广动机和选择偏差的可能，文中也不会用它们估算总体满意度。

第一件事要足够小，也要有一个可以确认的结果

Instinct 把自己描述成可以发消息、打电话联系的个人助手，拥有自己的电话和电脑，连接用户的应用与设备。这个表达的吸引力很直接：用户只需要说想做什么。Instinct 官网

但“你可以让我做任何事”，也把挑选任务的负担交给了用户。第一次见面，我该让它写一封邮件，还是买一张机票？如果失败，是我没有说明白、没有连接正确账户，还是它做不到？自由输入框容纳了所有可能，也容纳了所有不确定。

前面的压力测试里，找商品和支付被用户划出了边界。这个边界未必需要等待技术成熟才有价值。搜集候选商品和检查库存，本身就占用人的时间，整理差异也是如此；只要 Agent 能可靠地完成其中一段，用户就可以获得收益。一个产品不必在首次使用时证明它能独立完成整个生活事务，倒是需要让用户看见：这一段已经结束，下一步还由谁负责。

同一讨论里，另一位使用者称，自己通过 WhatsApp 让 Instinct 清理 Gmail 的推广邮件，并辅助线上教学。教学消息由 Agent 起草，自己检查、发送。他喜欢的一个细节是，发出请求后会收到表情回应，知道助手已经开始处理。WhatsApp 使用者的评论

这条自述没有提供邮件日志，也没有证明清理过程零错误。它仍给出了一个实用的产品线索：价值可以在发送之前出现。草稿帮用户减轻了组织表达的工作，审发留住了他对教学关系的控制。接受人工检查并不一定削弱委托，关键要看检查的范围是否比原工作小。

假如我来选首个任务，会优先找用户本来就要做的事情，结果要容易验收，出错也要容易恢复。比如把一批指定发件人的邮件整理成带原文链接的待办，或者根据几封往来邮件准备一份回复草稿。这是设计建议，不是对 Instinct 当前流程的描述。第一次不需要接管整个邮箱，也不需要用户先交出支付权；验收之后，再问是否把同类事情持续交给它。

“整理邮箱”仍然太大。把哪些邮件移到哪里，是一种后果；是否删除、是否退订，又是不同后果。给推广邮件加标签容易检查，删除重要通知则可能让用户付出更高代价。低风险也不能只由功能名称决定：同样叫“归档”，几十封无关推广和一封正在处理的合同邮件，对人完全不同。

Poke 的 Recipes 给这种起步方式提供了一个有意思的对照。官方文档说明，配方会打包首次使用所需的上下文和预填的第一条消息，也包含必要集成与安装分享链接；发布后的修改只影响新加入的用户。这是产品机制说明，还没有给出完成率证据。Poke Recipes 文档

我会把它理解成一种“可安装的第一件事”：用户先认领具体用途，再补充完成它需要的信息。比起让每个人从空白对话里探索全部能力，这种入口更容易说明预期结果，也更容易解释为何需要某项权限。

配方同样有代价。默认内容若承诺太多，用户会以为点了安装就等于事情已经有人负责；旧用户若没有随版本更新，产品团队还得知道他们使用的是哪一套规则。一个被包装得很方便的委托，仍需要交代授权和运行频率，也要说清停止条件与结果去向。安装量只能证明入口有人点，不能证明事情已经交了出去。

首个任务的选择因此应该由验收倒推。能不能在几分钟内指出它处理了哪几封邮件、哪一条还需判断？用户能否随手打开原文确认？如果唯一的完成证明是 Agent 自己说“已搞定”，第一次成功很容易只存在于对话里。

聊天负责开门，事务需要留下可以查看的记录

那个 WhatsApp 使用者喜欢表情回应，我觉得这比许多复杂的进度动画更接近问题。它解决的是一件很小但真实的事：消息送到了，委托已被接住。用户可以先把注意力移开。

另一个评论者却称，使用一天后，消息显示已读，助手没有回应。有人回复说自己通过 WhatsApp 使用没有问题。两条相反的反馈不足以确定渠道故障、宕机范围或原因，但“已读”显然无法告诉人任务现在处于什么状态。未获回应的用户评论

传统聊天里，已读通常与“对方看见了”有关。代理产品把它放在执行链路里，用户还会继续推测：它在工作吗，还是漏掉了？要不要再发一次？如果重复发送，它会不会重复下单？原本省掉的操作，会变成检查它是否在操作。

我会把收到与开始分开表达，阻塞和完成也各自说明。收到请求后可以简短回应；真正开始查询后再给必要状态；卡在登录或验证时说明需要用户做哪一步；结束时返回能核对的结果。这些状态不需要铺成四个聊天气泡，更不需要每次工具调用都打扰人。对用户有意义的变化才值得出现在对话里。

比如一个机票监控的设计示例，可以在最初确认“这些日期、这些机场、只提醒、不购买”，随后保持安静。当价格满足条件时，消息带上检查时间、可打开的航班链接和下一步选择。如果信息过期，就明确说需要重新确认。没有变化时，用户仍能主动打开任务记录，看最后一次成功检查是什么时候。

聊天适合临时发起请求，长期任务却容易被新消息埋住。一个人在同一窗口里问过旅行和报销，也问过家庭聚会，几天后想停掉其中一项监控，不该靠回忆原话来猜系统现在的安排。他需要有一处地方，可以看见正在运行什么、改过什么，以及怎样停止。这个地方可以是一张可打开的任务卡、一个网页或独立应用，形态取决于任务密度。

Poke 的一个用户原帖提供了反证线索：作者喜欢 iMessage 内主动助手的想法，但也希望有独立应用。帖子的身份与推广关系没有得到核实，不能据此判断多数人偏好；它至少提醒我们，减少新界面不能替所有用户完成界面选择。Poke 用户对独立应用的需求

还有一段更容易被营销叙事忽略的纠正。Instinct 讨论中，一位用户先称它能处理短信，追问之后承认自己连接的是 Gmail、Calendar 和 Drive，iPhone 短信仍有限制。他还称，Agent 能持续检查商品库存，并在其批准后付款。这些都是个人自述；其中最应保留的事实，是他亲自纠正了自己的能力理解。关于短信访问的追问与纠正

能够在 iMessage 接收委托，不等于能够读取用户全部 iMessage。 如果产品让入口与数据权限看起来像同一件事，用户就可能对它拥有的信息产生错误预期。随后出现“为什么这条短信你不知道”的失望，未必来自模型记性差，也可能来自一开始就没有讲清楚。

Town 采用的是另一种组合：助手拥有独立的 @town.com 地址，用户可以直接发邮件，也可以把助手抄送进与他人的邮件线程，对方无需加入 Town。文档还区分了从用户账户起草的邮件和助手以自身地址发送的回复。这些是当前文档的功能说明，不能据此保证每次协调都成功。Town Email 文档

这对商务邮件很自然，因为事情原本就在邮件线程里。但同一封消息“由我发出”还是“由我的助手发出”，会改变收件人的理解。把身份藏起来可能换来一时顺滑，也可能在误发或越界时加重关系成本。产品最好让发起者和接收者都知道：谁在说话，谁决定了内容，谁可以继续处理。

下面的比较只看一条委托路径中的设计选择。它没有给产品打分，也不把文档承诺当作已经测得的体验。

对话可以保持简单，事务记录不能随之消失。这里最该少的是用户解释和追问的次数。

主动工作的价值，取决于它省下了哪一次惦记

持续监控是 Personal Agent 与单次问答拉开距离的地方。用户不必在每次需要新结果时再来问，代理可以带着条件等下去。

压力测试的作者说，机票任务大约每天检查三次。这个频率本身不证明价值：检查得勤，也可能查错日期、只查到一部分网站，或者把早已过期的价格告诉用户。它说明的只是任务跨越了多次运行。真正应该交付的是：在用户指定的条件里，有没有出现值得行动的变化。机票监控自述

访谈里的另一个细节与此相通。Patrick O’Shaughnessy 说，数月使用 Instinct 的过程中，大约接到三次电话；对话随即举了签署截止临近时打电话提醒的例子。这来自公开访谈的机器转录，没有任务日志；截止提醒也不应被扩写成一桩已完整核实的实际交易。EP.493 官方节目页 、公开机器转录

我从这里得到的产品判断是：主动性需要与后果相称。日常摘要可以等用户方便时看，接近截止且需要本人动作的事情，才可能值得升级为更强的提醒。频繁说“我还在替你看着”，反而会把原来的惦记转换成新的通知负担。

但电话少，也不能直接证明提醒准确。它可能克制得恰好，也可能漏掉重要事件。产品需要同时看该提醒时有没有提醒，以及提醒后用户是否真的需要行动。只统计打开率，很容易鼓励系统用更急迫的语言争取注意力。

另一位 Instinct 评论者称，自己每天早上八点收到岗位列表；助手按其活动历史推荐纽约活动，等他选择之后注册、加入日历，还处理商家的取件与退款邮件。原帖没有交易凭证，无法确认每一次退款都已完成。岗位、活动与商家邮件的使用自述

这组事情吸引我，因为它保留了人的不同决策。岗位信息定时送达，活动由人选择，选完之后才进入登记与日历。一个产品可以在准备阶段主动，在偏好判断处等人，在已选定的手续上继续工作。主动性可以沿事务分配，不必整个人生都采用一个开关。

早上八点适不适合，应该由这位用户的习惯决定。不能因为一个使用者喜欢定时列表，就把晨间简报做成所有人的默认值。同样一份活动推荐，对准备社交的人有用，对正忙着处理工作的人可能只是新增邮件。

Town 使用者 David Berkowitz 的亲历通讯把成本说得更具体。他询问自己的额度用在哪里，发现后台读邮件与打标签占了消耗，起草回复也在消耗额度，随后关闭一些功能和逐会议简报；为通讯搜集新闻的 routine 则是他认为有用的部分。他也写到，助手模仿自己声音代写的效果令他失望。这里保留的是其 2026 年 8 月的体验，不能拿文中旧价格当今天定价。Berkowitz 的 Town 试用通讯

这个案例使“替我操心”出现了一个现实条件：它操的心要是我在乎的事。后台读过多少封邮件、生成多少份简报，都无法独自证明价值。当用户得先向助手询问账单并理解额度，再停掉自动工作，他又多了一份管理任务。

Town 文档将 Routines 作为定时或事件触发的持续任务入口。这给产品一个可管理的对象，但管理能力还需要落实到用户读得懂的开销与结果。Town Routines 文档

我会在持续任务里放一个可见的运行约定：关注什么变化，多久检查一次，何时通知，持续到哪天，允许消耗多少，以及一键暂停在哪里。月度账单也应该按用途说明，用户才能判断某项活动是否值得继续。这里的预算可以是额度、金额或次数，未必要暴露底层 token。

主动推荐进一步考验这个约定。创始人的公开发布内容镜像称，Instinct Selections 引入厨师、设计师和当地向导等人的推荐；镜像不包含原帖完整媒体上下文，我没有把它当作完整发布档案。创始人发布内容的镜像

9 月 30 日的报道记录了用户对未经请求的购物推荐感到不适。TechCrunch 报道

这条反馈可以讨论，却不能据此认定 Selections 已经是广告，或者它按佣金给商品排序。应当追问的产品问题更具体：用户为了处理旅行事务提供的信息，是否也默认用于主动建议买新东西？“帮我少漏一件事”与“替我发现下一笔消费”涉及不同目标，即使使用相同数据，也值得分别取得同意。

推荐可以设计成按需查询，也可以让用户订阅某类灵感，并设定频率。若它进入购物流程，最好还能解释候选来源、选择理由，以及是否存在商业关系。解释本身无法消除利益冲突，至少能让用户知道需要检查什么。关掉推荐后，原有事务仍应继续处理，否则“可选择”会变成一种名义上的自由。

授权应该跟着后果走，不能靠使用天数自动扩大

从公开材料看，用户的信任并没有只有“完全相信”与“完全不信”两个状态。有人让 Instinct 整理邮件却自己发送，有人让它准备订单但保留付款，有人愿意让它跨天监控。这些安排各自成立，产品需要容纳它们。

Noah Shinn 在访谈中谈到逐渐建立委托关系，也强调让用户理解接下来会发生什么。我赞同后一个方向，但我不会把“用户用了几周”当成扩大所有权限的理由。熟悉它写草稿，不等于授权它发送；确认它会找机票，也不等于确认它会判断票规。公开机器转录

权限界面常常围绕工具命名：读邮箱与写日历，也包括访问浏览器。用户更容易理解的是后果：会不会向别人发消息，会不会花钱，会不会取消已有服务，会不会让别人获得我的资料。产品可以保留技术权限，但确认时应该把它翻译成具体动作。

比如“允许管理日历”至少可能包含查看空闲时间和给自己留一个占位，也可能包括邀请他人或修改已有会议。后三件事的影响并不相同。用一个总开关解决它们，操作会少一些，理解成本和误操作代价却可能更高。

Town 当前的 Modes & Approvals 文档区分会话、routine 和具体工具的权限；会话允许范围在新聊天开始时重置，routine 有持续设置，单次批准与更广范围的允许也不同。该文档在 9 月 30 日更新。因此，不能再用“任何消息都会单独审批”来概括它。Town 当前授权文档

这些控制能细到工具层面，代价是用户可能不清楚哪一层在生效。一次审批如果悄悄改变了未来行为，今天省下的点击会变成明天的意外。我的设计建议是让批准按钮说清范围：这一次或这一类动作，还是这段会话或这个持续任务；扩大范围后，任务记录里应留下可撤销的条目。

过于频繁的确认也会损害安全。如果每一次查询、加标签都弹出相同强度的提示，用户很快会习惯一路允许。应该被认真确认的动作，需要足够清楚的对象与后果。采购时是商家与商品，也包括总额与交付；发送时是身份、收件人和最终正文；取消时是失去的权益及生效时间。

Muse 的官方安全说明展示了其中一种具体做法：付款时要求人工确认；新网站支付采用单次凭证，并把商家、金额和有效时间限制在这一笔操作里。授权由模型之外的系统负责。这是厂商对发布时设计的说明，不能当作独立安全审计，也不能借来描述 Instinct 的架构。Muse 官方安全设计

对产品同学而言，重要之处是一次委托终于可以有具体范围。用户同意买某件商品，不必被解释成允许以后继续花钱。支付确认也不应只展示一个总价；同额买错型号、把收件地址填错，仍会让人遭受损失。限额约束的是部分代价，商品、送达与取消条件仍需要核对。

错误发生以后，授权记录也有另一种用途：帮助说明当时批准了什么，以及系统实际做了什么，再说明差别在哪里。它能支持客服和争议处理，却不会自动带来退款或赔偿。没有公开政策或经核验个案，我不会替任何产品承诺“出错有人兜底”。

我因此会把补救入口放在完成凭证旁边：订单是否还能撤销，联系商家需要什么，用户怎样接管，已经发生的费用如何显示。如果系统只在成功时交付一个漂亮结果，失败之后把全部查找与交涉留给用户，委托的代价仍然悬在用户头上。

多人的事情，不能只有发起者一个人的授权

个人助手遇到安排会议、家庭活动或照顾父母时，很快会进入别人的生活。它知道发起者想做什么，还不代表它有权要求另一个人配合。

Instinct 访谈描述了代理之间的协调：两人的助手寻找共同可用时间，并按关系提供不同范围的信息访问。这是创始人对产品的说明，不能扩写成已验证的多人协调成功率。公开访谈转录

这类设计有机会减少来回沟通，但代价也容易藏在“信任关系”几个字里。允许同事查询本周几个空闲窗口，与分享整个日历不是同一个授权。双方互为熟人，仍然需要分别决定共享什么和有效多久，还要决定能不能再转给别人。

我的设计示例会从最窄的问题开始：为了本周找三十分钟，只返回可用时段；确认后再写入邀请。若一方需要改期，就退回双方仍可接受的候选。拒绝和迟迟未回应都应是正常状态，不能为了让发起者满意，不断替他催促对方。

家庭事务更值得谨慎。压力测试帖子提到了父母散步相关任务，却没有解释怎样核验散步是否发生。不能据此补造定位、传感器或健康数据链路，更不能把“会给父母发消息”推成“能确认父母的状态”。原帖及相关追问

这类任务的产品承诺应当止于实际掌握的证据。发出了询问和收到对方回复，连同读取了已授权的数据，是三个不同层次。把不确定说清楚，可能没有“替你照顾家人”那么动听，但可以避免给发起者一种并不存在的放心。

如果只有双方都使用同一产品才能方便协调，增长与体验也会相互牵连。Town 的邮件抄送方式不要求外部联系人注册，为这种关系提供了另一条路径；它的限制是仍依赖邮件习惯与线程管理。两种形态应该比较完成同一次协调需要多少来回、多少新增授权，而不该只比较覆盖了多少入口。Town Email 文档

一次漏项，可能让以后每次都需要重查

正面案例里，用户把某一段工作交了出去。负面案例里，最昂贵的变化往往是：他不再知道哪些段落可以放心。

一位自称旅行顾问的 Muse 使用者发帖说，使用约十二天，起初报价研究很有帮助，后来从邮件提取信息到表格时出现漏项；他不得不重新阅读产出，助手反复索要已有信息，也重犯刚刚答应设为长期规则的错误。这是一人的未验证叙述，帖子没有足以确定模型版本、故障原因或平台责任的记录。Muse 旅行顾问原帖

这里值得讨论的机制不依赖于判定哪家产品“记忆不行”。当用户不知道漏掉的是哪一部分，检查范围就从疑点扩大到全部。Agent 可以很快生成一张表，用户却要把原邮件和整张表重新对一遍；下一次，即使表格正确，重查的习惯也可能已经留下。

假设自己做一次报价整理要二十分钟，代理处理后只需核对三分钟，委托很有用；如果解释需求花五分钟，等待时反复查看，最后又用二十分钟重做，它只是增加了一层流程。这是说明注意力成本的假设情景，不是对 Muse 或 Instinct 的测量。

我会把检查成本拆进具体任务：哪些字段需要精确，哪些可以概括，哪些缺了就不能交付。旅行报价里的日期与人数，还有币种和取消条件，比一段流畅的摘要更容易决定结果是否可用。抽取结果若保留原文位置、标明缺失字段和冲突，用户至少可以集中检查未知部分。

这也不能保证用户永远不用复核。产品若曾把错误字段标成已确认，就需要重新验证这些标记是否可靠。可见来源能够缩短核对路线，无法替代来源正确、抽取正确以及引用真的对应这一行。

“以后记住这条规则”同样需要落到可检查的变化。让用户看见当前保存了什么规则、作用在哪些任务上，修改或删除后再观察下一次运行。聊天里的道歉不会自动形成持久行为。对重复工作，最好用少量已知材料试运行，确认规则能影响下一次结果，再恢复自动执行。

代理不确定时怎么停，也属于体验。它可以交付一个部分完成的表格，把缺失处留空，告诉用户哪些原文仍需处理；可以在外发前暂停，避免把未知信息当成确定事实传播。最糟的安排，是先用完整的口吻宣告成功，等用户发现问题后才解释还有限制。

这里还有一个容易被产品评审漏掉的时刻：用户接管。网站要求本人验证，未必意味着整件事需要重来。系统应该尽量保留已完成部分，说明需要人操作哪一步，接管时停止并发动作，交回后再确认状态。本文不展开运行时实现，但用户能否安全接手，直接决定上一次委托会不会变成重复劳动。

我在此前的 Agent 舰队成本文章 中，把人审与重试计入每个成功任务的总成本。个人代理的账也得这样算，还要加上盯进度和善后的时间。只把点击节省下来，把检查与责任藏到另一端，产品算出的收益会比用户实际感到的大得多。

收费方式会进一步影响这笔账。Berkowitz 的 Town 案例提醒我们，按额度收费需要让用户知道后台花在哪里；Instinct 创始人在访谈中表示反对广告模式，并讨论从商家交易中取得分成的方向。这是商业意图的公开说明，不能等同于已完成的长期利益对齐。Town 亲历通讯 、Instinct 访谈转录

订阅会面对“开销是否值得”的判断，交易分成会面对“它是否总想让我买”的怀疑。收入来源不同，产品要交代的冲突也不同。更大的交易量可能来自更多购物，未必来自更少操心；厂商自报的增长、留存和交易规模，没有清楚的样本与计算方法，也不足以回答用户到底节省了多少工作。

我会特别看几种不产生新增消费的成功：停掉无用监控和找回关键邮件，也包括避免漏过退款期限，或者明确告诉用户不必购买。若助手声称站在用户一边，这些结果应该也算价值。一个只奖励下单的内部指标，可能让最会替用户省事的行为显得不重要。

把“愿意再委托”放进四周实验

这些公开材料让我更愿意押注有边界的连续委托：一个具体任务，有用户理解的授权，结果带凭证，失败能接管。这个判断仍可被推翻。如果真实用户即使面对清楚的边界和可靠结果，也很少再次交出同类任务，说明它可能只是偶尔方便的工具；如果增加状态和凭证反而显著加重了负担，则应继续简化，而不是坚持把记录做满。

公开反馈还有一个更直接的挑战：Instinct 讨论里有人称，自己努力使用后仍没有感到它比现有 ChatGPT、Claude 或 Codex 更适合。那只是一个人的偏好，不能代表市场；却提醒我，个人代理需要证明持续处理确有增量。给聊天工具加上记忆与几个连接器，未必足以让用户改变习惯。没有找到使用契合点的评论

我会先做四周同类任务实验，挑一组原本就需要重复处理的真实事情，比如退款跟进和邮件转待办，也可以选库存监控。下面是验证建议，没有任何一家产品的实测结果可以填进来。

第一周先记录用户自己处理时的基线：实际操作多久，隔多久想起来检查一次，在哪些地方需要判断。接着让 Agent 处理同类任务，记录用户解释与批准用了多久，也记录追问、核对和修复的时间。两种方式的任务复杂度要尽量可比，否则最简单的一批交给代理，最复杂的一批留给人，结论会被选样做出来。

之后继续观察三周，让新鲜感有机会下降，也让跨天事务有机会真正遇到变化。结果不能只按对话数算，应该回到原始凭证：退款是否到账，待办是否对应原文，还有库存提醒是否在可购买时送达。商家仍未回应时，状态就保持未完成，不能因为助手写了跟进邮件就把结果计为成功。

我会保留四个比较容易解释的观察值：

• 第二次有效委托：用户是否再次主动交出同类事情，而且结果经核对可用。返工和催问另行记录。
• 用户总投入：解释、审批、检查、修复与善后合在一起用了多少时间，与自己处理相比如何。
• 接管与损失：哪些地方必须由人接手，有没有误发、误买或漏过期限，补救用了多久。
• 主动工作的净价值：提醒中有多少需要行动，用户关闭了哪些任务，以及哪些必要提醒没有发出。

这些指标也各有盲点。第二次委托可能来自任务频繁，低频高价值事务不能只用四周衡量；时间少了，用户仍可能因担心隐私而不用；主动提醒的作用有时体现在避免损失，无法轻易换算成节省的分钟。实验需要保留这些差别，不能再把它们压成一个漂亮的分数。

同样要记录谁退出了、为什么退出。只采访留下的重度用户，会把“不知道交什么”“授权太烦”“不愿支付”的人从结果里消掉。退出者的原因，可能比留下者又做了多少新玩法，更直接地指出产品下一步该改什么。

如果有人愿意持续交出信息搜集，却始终保留最终发送或付款，我会先接受这种产品形态。它已经减轻了一部分工作，不必为了证明代理足够自主，强迫用户把剩下的判断也交出去。真正的机会也可能是一个可靠的事务准备者，随后逐项取得更大范围的委托。

回到开头那位愿意让 Instinct 找东西、却暂时不愿让它自由付款的使用者。他给出的边界很清楚：这一段可以替我处理，这一步我要决定。Personal Agent 若能记住并尊重这种边界，把结果和剩余责任交代清楚，第二次委托才有充分的理由发生。

参考资料

• Instinct 官网：产品定位与入口
• Colossus EP.493：Instinct — The Personal Agent，2026-09-28 。已核对公开节目说明与章节，官方完整转录需要登录。
• EP.493 公开机器转录 。用于访谈片段核读；含广告插入和转录误差，不是新采访。
• Instinct 压力试用原帖与评论 。包含机票监控、岗位与活动、权限纠正等使用者自述，未经独立日志验证。
• WhatsApp 使用者的具体评论
• 消息已读未获回应的具体评论
• Poke Recipes 官方文档
• Poke 用户关于独立应用入口的原帖 。仅采用入口偏好线索，未核实推广关系。
• Town Email 官方文档
• Town Routines 官方文档
• Town Modes & Approvals，更新于 2026-09-30
• David Berkowitz：Should You Hire an AI Townie?，2026-08-07
• Muse 旅行顾问的使用反馈原帖
• Meta：How We Built Safety Into Muse 。厂商对发布时设计的说明，不是独立审计。
• Noah Shinn 公开发布内容镜像：Instinct Selections 。镜像的阅读与媒体上下文有限。
• TechCrunch：Instinct’s new product recommendations are giving some users the ick，2026-09-30 。正文仅采用一句短转述。