Perplexity Computer 邮件让任何人都能委派 Agent 任务，但信任成为考验

Perplexity 已通过邮件向没有账户的用户开放其 Computer Agent，在限时免费试用期间消除了一个重要的访问门槛。根据 CEO Aravind Srinivas 的说法，任何人都可以转发邮件，或抄送 computer@perplexity.com 来委派工作。这一说法将 Perplexity Computer 的邮件功能扩展到了公司此前文档所涵盖的注册用户之外。

该 Agent 会在后台工作，同时保留邮件线程作为任务上下文。据称，每项请求都会成为一个标准 Computer 会话，拥有相同的网页和移动端视图、执行步骤以及审计记录。用户可以直接从熟悉的收件箱开始，而无需再打开另一个应用。

这种便利也带来了核心矛盾。邮件可以让 Agent 委派显得顺理成章，但普通电子邮件本就不是为安全命令界面而设计的。当访问范围扩展到既有账户之外时，Perplexity 必须证明发件人验证、权限和审核控制依然可靠。

这一举动也对 OpenAI、Google、Microsoft 以及其他 Agent 提供商施加压力，促使它们在工作本就到达的入口展开竞争。竞争重点正从“哪个助手回答得最好”转向“哪个 Agent 能以最低摩擦承担责任”。

Perplexity Computer 邮件功能移除了账户门槛

关键变化不在于 Computer 能接收邮件，而在于 Perplexity 表示，现在任何人都能通过这一入口使用它，无需账户。

邮件中的 Computer 本身并非全新功能。Perplexity 于 2026 年 8 月 24 日为现有 Computer 用户公布了原始功能。该版本允许用户发送消息、转发对话，或将 Agent 添加到活跃邮件线程中。

10 月的扩展更进一步。在 9 月 30 日的一则公开帖子中，Srinivas 表示，没有 Perplexity 账户的人也可以通过 computer@perplexity.com 委派任务。他还称，这些任务将在限时内免费提供。

这一较新的访问政策尚未出现在本文查阅的公司文档中。官方 8 月材料仍将该功能描述为面向 Computer 用户提供。因此，无账户扩展应被视为 Perplexity CEO 提出的上线说法，而非已有完整文档支持的永久政策。

基本交互刻意保持简单。用户可以撰写一封包含指令的新邮件、转发现有线程，或在对话中抄送该 Agent。邮件主题、正文、早先消息和附件都可以提供任务上下文。

这一设计将收件箱变成了轻量级任务队列。用户无需在发送前将任务重构为正式提示词。一段合同讨论、电子表格往来或研究请求，可能已包含 Agent 完成工作所需的大部分信息。

Perplexity 表示，每项请求都会作为完整的 Computer 会话运行。这一区别很重要，因为该系统并非只生成一封邮件回复。它可以规划步骤、使用可用工具、创建交付物，并通过原始线程返回文件。

公司的邮件工作流描述了几个示例。分析师可以根据附加文档请求财务模型；律师可以要求梳理多个修订版本中尚未解决的问题；另一位用户可以请求清理并格式化电子表格。

这些示例仍是公司演示，而非独立性能测试。但它们依然说明了预期范围。Perplexity 希望邮件能够发起实质性工作，而不仅是生成摘要或建议回复。

该会话也仍可通过 Computer 的网页和移动端界面访问。用户可以在收件箱之外查看进度、审核已采取的步骤，并查看关联的审计记录。邮件线程是入口，而非唯一的控制界面。

这种分离对长时间运行的任务很有用。邮件负责委派和交付，而 Computer 界面则提供对工作过程的可见性。这种模式类似于将任务分配给同事，之后再打开项目记录查看细节。

无账户的说法使这一模式变得更复杂。现有文档称，Computer 会验证发件人，并使用该人的连接器、权限和 Memory。没有账户的用户显然并不具备这些既定资源。

Perplexity 尚未公开解释这些新用户的身份、会话所有权、存储或权限边界如何运作。目前也不清楚无账户任务是否只能使用精简的工具集。这些细节将决定这次扩展的重要性。

目前，经过验证的基础范围更窄：Computer 可以接收邮件任务、理解线程上下文、返回交付物、创建常规会话并保留审计记录。CEO 的帖子增加了一个重要但文档支持较少的层面：开放访问和暂时免费的执行服务。

邮件正在成为 AI Agent 的分发层

Perplexity 竞争的是人们决定交出工作任务的那个时刻，而不只是人们打开 AI 应用的那个时刻。

大多数工作场景中的任务，本就通过有限几种渠道到达：邮件、消息平台、会议、工单系统和共享文档。要求用户将每项请求转移到独立的 AI 界面，会增加摩擦，也往往会丢失上下文。

Perplexity 的邮件 Agent 同时解决这两个问题。转发可以保留原始对话，而抄送 Agent 则让请求留在相关人员讨论的附近。用户无需在另一个产品中手动重建历史记录，就能完成委派。

这很重要，因为 Agent 产品需要的不只是技术能力，还需要重复出现的入口。即使系统能力很强，只要人们必须记住它在哪里、打开它、收集材料并重新说明任务，它仍可能无人使用。

邮件拥有不同寻常的覆盖范围。它可以跨公司、设备和软件环境运行，同时还承载附件、时间戳、参与者、引用历史，以及“谁要求做什么”的可识别记录。

这些属性让邮件成为颇具吸引力的 Agent 界面，也令其格外敏感。一封邮件线程可能包含机密财务信息、法律草案、客户资料、凭证或内部意见分歧。

Perplexity 的原始设计试图通过仅回复已验证的发件人来限制暴露范围。它不会自动将输出发送给每一位参与者。公司表示，面向企业用户的更广泛“回复全部”支持将于之后推出。

这一限制表明，Agent 执行与普通邮件协助有何不同。写作助手会为人类拟定待发送的文本；执行型 Agent 则可能查阅已连接系统、转换文件，并基于其他收件人无权访问的信息采取行动。

仅回复发件人可以减少一种意外泄露路径，但并不能回答所有授权问题。系统仍需区分无害上下文与嵌入在引用消息或附件中的指令。

无账户推广也改变了 Perplexity 的获客策略。Computer 最初作为面向较窄受众的高级产品推出。邮件提供了一种试用机制，用户无需在首次任务前完成注册。

有价值的结果本身可以成为引导用户上手的事件。有人转发一项困难任务，收到交付物后，才决定是否值得进一步关注更广泛的 Computer 界面。这颠倒了通常的软件转化漏斗。

限时免费期支持了这种做法。它从第一次交互中同时移除了付费和注册门槛。不过，Perplexity 尚未说明有多少任务符合资格、推广何时结束，或包含哪些能力。

这些缺失条款对用户和竞争对手都很重要。无限制试用意味着为昂贵的多步骤工作提供补贴；严格受限的试用则更像是通过邮件交付的产品演示。

Perplexity 也获得了展示其编排模式的机会。Computer 推出时被定位为一种可将工作分配给专业模型和子 Agent 的 Agent。它的价值取决于能否将这些资源协调为完整输出。

发布时，Perplexity 表示 Computer 可以使用 19 个模型。该公司后续材料描述了不断扩展的模型集合和重复性工作流。随着集成和模型选择变化，具体可用性也可能变化。

邮件隐藏了这种复杂性。用户无需为每一步选择模型，也无需监督每个子任务。Agent 接收以结果为导向的请求，并在幕后管理工作流。

这正是产品赌注所在。Perplexity 相信，即便底层模型来自其他提供商，协调能力也可以产生价值。界面、上下文处理、路由、连接器、记忆和审计记录构成了差异化系统。

收件箱入口让这一主张更容易被验证，也让 Agent 更容易与人类委派进行比较。用户会判断结果是否完整、是否按时到达，以及格式是否可用。

真正的竞争是无需另一个应用即可委派工作

Perplexity 的主要对手并非某一家公司，而是“用户必须先访问一个 AI 目的地，Agent 才能开始工作”这一以应用为中心的假设。

OpenAI、Google、Microsoft、Anthropic 以及众多初创公司都在构建能够研究、编程、浏览或与工作场所工具互动的系统。它们的产品各不相同，但许多仍从专用聊天或 Agent 界面开始。

Perplexity 正在将 Computer 推向任务已然存在的沟通渠道。在邮件之前，它已为 Slack 和 Microsoft Teams 引入 Computer 入口。如今，收件箱将这一策略延伸到了单一协作平台之外。

这一路径赋予 Perplexity 实际的分发优势。转发一封邮件所需的行为改变，比进入一个新工作空间更少。它也能保留对话历史，否则这些历史可能会被压缩成匆忙编写的提示词。

这种方式类似于人类专家接收任务的方式。一个人可以将背景材料转发给分析师，说明所需输出，然后等待回复。Computer 试图占据同样的运营位置。

不过，软件委派与人类委派在重要方面有所不同。同事可以识别办公室政治、含糊的同意或可疑指令。除非安全控制进行干预，否则 Agent 可能会按字面理解最新命令。

这就是为什么审计记录是核心功能，而非装饰。用户需要知道 Agent 访问了哪些信息、执行了哪些步骤，以及如何生成交付物。在重要工作中，缺乏可追溯性的结果很难获得信任。

Perplexity 表示，邮件任务会保留与网页端发起会话相同的步骤和审计历史。这提供了一致的审核界面，也让公司不必将完整执行记录压缩进一封难以处理的邮件回复中。

应用并未消失，只是角色发生了变化。它不再是强制性的起点，而成为查看、干预和深度管理的场所。

这种混合式设计比用电子邮件取代所有界面更可信。收件箱适合接收请求和返回交付成果，却不适合监控并行子任务、调整权限或诊断故障。

Perplexity 面临的挑战，是让用户能够理解这两种界面之间的切换方式。账户持有人可以通过链接进入已验证的会话。没有账户的新用户则需要清晰的所有权与验证流程。

该公司尚未详细说明这一流程。收件人可能需要验证电子邮件地址、创建临时会话，或最终注册账户。每种选择都会改变产品实际使用起来是否顺畅。

竞争对手可以复制这种可见的交互方式。一个能触发代理的电子邮件地址并不是难以复现的概念。更深层的竞争在于上下文、权限、执行质量和运营可靠性。

Microsoft 具有天然优势，因为 Outlook、Teams、Microsoft 365 和企业身份系统已经共享管理控制。Google 在 Gmail 和 Workspace 体系中也具备类似优势。两家公司都能让代理更贴近组织数据。

OpenAI 和 Anthropic 可以通过模型质量、企业集成、开发者生态和代理平台展开竞争。因此，Perplexity 必须证明，其编排层能比单一提供商的助手产出更好的最终成果。

这种压力解释了其为何聚焦于完成的交付物。仅靠搜索回答已不足以建立可防御的品类定位。代理必须返回能推进任务的电子表格、报告、演示文稿、数据集或其他成果。

独立证据仍然有限。2 月的一篇发布评估指出，Perplexity 在发现产品缺陷后取消了原定的媒体演示。该媒体当时尚未完成自己的实际上手测试。

该事件并不能证明当前质量，但它说明了扩大访问范围为何具有战略意义。更多用户和更多真实任务能够提供受控演示无法带来的证据。

因此，无账户试用有两个目的：既分发产品，也邀请更广泛的可靠性测试。Perplexity 将了解 Computer 能否在精心准备的示例之外，理解并不完美的工作场所请求。

对用户而言，评估仍应以结果为中心。系统是否理解任务、使用了正确的上下文、保护了机密性，并产出了可审查的交付物？只有满足这些条件时，便利性才有意义。

更轻松的委派扩大了安全边界

电子邮件降低了使用代理的门槛，但也让不可信内容更接近能够采取重大行动的工具。

一个电子邮件线程包含多种声音。其中可能有引用文本、转发指令、签名、外部链接、附件文档，以及由从未打算指挥代理的人撰写的内容。

这种混合带来了提示注入风险。提示注入是指不可信内容包含旨在改变 AI 系统行为的指令。代理必须将用户请求与其所读取材料中隐藏的命令区分开来。

一份转发文件可能要求代理忽略任务并泄露其他信息。研究过程中打开的网页也可能包含类似指令。恶意参与者可能在添加 Computer 前，故意将此类文本放入线程。

发件人验证只能解决部分问题。它有助于确认谁发起了任务，但并不能使线程中的每项内容都变得可信。系统仍需要在数据访问和工具使用方面设置边界。

权限带来了另一项复杂性。Perplexity 最初的电子邮件文档称，任务会使用发件人的连接器和访问权限。这可以使执行与现有身份保持一致，前提是该身份已经完成配置。

无账户版本没有明显的对应机制。新发件人可能没有已连接的应用、已存储的记忆或组织政策。Perplexity 可能会将会话限制在电子邮件及附件范围内，但尚未公开确认这一设计。

受限环境可以降低风险，但也会缩小实用性。代理可以总结文档、研究公开信息或创建文件，而无需进入私有系统。它无法完成需要内部应用的工作流。

更广泛的访问会提升价值，也会提高风险。如果用户连接云存储、消息服务或商业软件，系统必须防止电子邮件触发超出发件人意图的操作。

这种张力并非 Perplexity 独有。代理行业正面临同样的问题：有用的代理需要权限，而安全系统应尽量减少权限。这两个目标在权限边界处交汇。

安全研究人员常将最小权限原则描述为：只授予系统完成特定任务所需的访问权限。将这一原则应用于代理并不容易，因为自然语言请求很少会预先明确每一种所需资源。

代理可能在执行中途发现自己需要另一份文件或连接器。授予广泛的常驻访问权限可以避免中断，但会增加出错的影响。要求确认可提升控制力，但会削弱自主执行能力。

行业正在通过沙箱、审批关卡、策略引擎和监控层作出回应。近期有关代理安全的研究凸显出，维持最小权限依然十分困难。代理必须访问真实资源才能发挥作用，但定义正确边界并非易事。

Perplexity 的审计轨迹可在执行期间及之后提供帮助。它能展示会话采取的步骤，并为审查提供证据。但它无法保证每项操作都恰当，也无法保证每次理解都正确。

可审计性与预防服务于不同目的。日志帮助用户理解发生了什么；权限控制、隔离和确认机制则限制一开始可能发生什么。

电子邮件还带来了有关同意的模糊性。将代理抄送进线程，可能会暴露其他参与者撰写的消息。这些参与者或许不知道 AI 系统会处理他们的文字或附件。

组织需要制定政策，规定员工何时可以将对话转发给外部代理。法务、金融、医疗保健和客户支持团队可能面临比个人用户更严格的要求。

仅回复发件人的规则可避免自动向整个线程披露信息，但也带来了另一项沟通问题。其他参与者可能看不到代理产出的内容，也不知道其输出影响了后续决策。

企业级“回复全部”支持将需要谨慎的控制。系统必须遵守线程成员资格、数据分类和不断变化的访问权限。它还需要防止敏感的已连接数据流向无权访问的收件人。

即使在免费推广期间，成本控制仍是另一项未知因素。多步骤代理工作可能消耗大量计算资源。Perplexity 尚未披露推广限制，也未说明将如何防止一次性电子邮件地址被滥用。

速率限制、任务复杂度上限和附件限制都是合理的保障措施。它们也将塑造“任何人”在实践中的含义。在 Perplexity 公布规则之前，用户应预期试用会有边界。

准确性则是一个更为熟悉的问题。一份精美的电子表格或报告可能包含错误假设、不完整的研究或虚构细节。完成的成果往往比聊天回复看起来更具权威性，因此更需要审查。

用户应将 Computer 的输出视为需要验证后才能采用的工作成果，尤其是在法务、金融、医疗或运营场景中。审计轨迹能够支持这一审查，但无法取代领域专业知识。

合理的首次测试应使用可撤销的任务和非敏感信息。例如整理公开研究、格式化示例数据集，或根据用户可验证的材料生成草稿。

这种做法能够在不立即授予关键系统访问权限的情况下衡量执行质量。它也能揭示 Computer 如何处理缺失信息、模糊指令和澄清请求。

对于正在建立自身审查流程的人来说，一个可搜索的AI 知识库可以将源材料与生成的交付物一同保存。目标是在代理输出需要验证时，仍能获得证据。

Perplexity 的主张很有吸引力，因为它免去了设置步骤。尚未解决的问题是，该公司究竟是消除了安全委派的摩擦，还是仅仅把这些摩擦转移到不那么显眼的控制机制中。

三个信号将表明电子邮件委派能否持续

接下来的考验不是有多少人向 Computer 发一次电子邮件，而是免费期结束后，他们是否愿意将重复性工作托付给它。

第一个信号是针对无账户访问的更新文档。Perplexity 应说明如何验证新发件人、创建会话、存储任务数据以及处理删除请求。它还应明确未连接账户时可使用哪些工具。

清晰的文档将强化这是一条持久产品渠道的说法。若继续依赖社交媒体帖子，则可能表明这只是范围更窄的推广，或是一场最终规则仍未确定的实验。

该公司还应公布免费访问的边界。用户需要知道限制是否取决于任务数量、时长、文件大小、计算量或工具使用情况。明确的结束日期将避免未来可用性方面的混淆。

第二个信号是 Perplexity 如何处理权限和敌意内容。该公司现有的产品说明确认，既有用户可获得发件人验证、已连接权限、Memory 和仅回复发件人的机制。

新受众带来了尚未解答的情况。Perplexity 需要说明未注册的发件人如何获得网页会话的所有权，也需要解释转发指令是否会被赋予不同的信任等级。

值得关注细粒度的审批提示和连接器限制。这些控制措施将表明 Perplexity 正将电子邮件视为不可信的接入渠道。没有可见确认的广泛操作则会削弱信心。

独立安全测试将比功能描述更重要。研究人员应检查引用文本、附件或外部页面能否重定向任务，也应测试输出是否会暴露无关会话中的信息。

没有任何代理平台能消除所有故障。有意义的比较在于遏制、检测和恢复能力。一个能够阻止高影响操作并生成有用日志的系统，提供了更强的运行模式。

第三个信号是竞争对手的反应。Google 和 Microsoft 控制着主要电子邮件平台，而 OpenAI 和 Anthropic 已服务许多职场用户。它们中的任何一家都可以将代理委派变为收件箱中的原生操作。

直接回应将验证 Perplexity 的渠道战略，同时也会增加其底层产品的压力。原生提供商能够比外部电子邮件收件人更深度地整合身份、管理、保留和权限。

Perplexity 可以通过跨平台覆盖来应对。一个地址可以在多种电子邮件服务中使用，无需等待每个提供商重新设计界面。这种中立性或许会吸引使用混合软件环境的团队。

执行质量将决定“够不够好”是否足以令人接受。当外部工作流能带来更好的结果、支持更多工具或处理更长任务时，用户会容忍它；当产出相近时，他们则会偏好原生控制方式。

重复使用是最清晰的采用信号。一次免费任务可能只是出于好奇；反复交办则说明用户信任该代理对需求的理解、交付格式、时效性以及上下文处理能力。

Perplexity 最终应当提供总任务量之外的更多证据。完成率、纠正频率、人工干预、重复使用情况和安全事件，都会更清楚地反映其实用价值。

免费试用为公司提供了广泛的测试场景。它可以观察哪些任务会自然地通过电子邮件出现，以及用户会在哪些环节放弃这一工作流。这些信息可能会指导未来模板、权限和连接器的设计。

它也让产品接触到更混乱的输入。真实邮件线程中包含不完整的请求、过时的附件、彼此矛盾的参与者意见，以及未明说的预期。处理这种混乱，是任何自称数字同事的代理都必须具备的能力。

整个行业应关注用户究竟更偏好明确的代理界面，还是无形的委派方式。专用应用程序提供控制能力和丰富的监控；通信渠道则减少了设置步骤，并保留了既有上下文。

最可能的结果并不是任何一种模式完全胜出。用户可能会在电子邮件或消息工具中发起任务，随后在需要审查时转入应用程序。Perplexity Computer email 已经遵循了这种混合模式。

只要交接过程保持清晰易懂，这种模式就能发挥作用。用户应始终知道代理何时开始执行、代表哪一种身份、能够访问哪些资源，以及该在何处停止它。

Perplexity 让第一步变得格外简单：转发一封邮件线程、复制一个地址，然后描述期望的结果。真正的难题从邮件离开发件箱后才开始。

Perplexity 电子邮件代理能否将这一熟悉的动作转化为可靠的委派，同时不掩盖权限、不确定性或风险？未来几个月应会通过文档、独立测试和反复的真实使用给出答案。