Perplexity推出常驻式多智能体工作台Teammates

摘要：Perplexity 发布工作型智能体产品 Teammates，允许用户在同一工作区配置多个长期在线的智能体角色，并并行承担持续性、大规模任务。它建立在可在设备端执行任务的 Perplexity Computer 之上，可复用现有项目、技能与记忆上下文，主攻 OpenAI Dots 和 Anthropic Claude Duet 所在的协作型办公场景。公开信息尚未披露调度模型、沙箱边界、任务成功率、延迟或计费方式，因此其工程价值仍需通过真实工作负载验证。

---

多智能体从一次性对话转向常驻工作区

Perplexity 发布 Teammates，把面向工作的 AI 智能体从单次问答或短生命周期任务推进到常驻式工作区。用户可以为一个工作区配置多个具有不同职责的 Teammate，让它们同时执行研究、整理、写作或其他持续性任务，并共享该工作区中的项目、技能与记忆上下文。

Teammates 构建于 Perplexity Computer 之上。后者可在用户设备上部署智能体并完成任务，而 Teammates 进一步加入多角色协作和并行执行机制，以承接需要跨较长时间持续推进的工作负载。

核心机制：从工具调用升级为角色编排

从公开描述看，Teammates 的技术重点不是新增一个独立基础模型，而是把 Perplexity 已有能力组织成持续运行的多智能体系统。

其基本执行链路可以抽象为：

1. 用户为工作区定义任务和角色边界；
2. 系统将不同子任务分派给一个或多个 Teammate；
3. 每个智能体调用搜索、Computer 或其他已有工具完成局部工作；
4. 项目、技能和记忆上下文在不同角色之间复用；
5. 各智能体并行推进，持续汇总状态并交付结果。

这与“让单个模型多调用几次工具”有本质区别。多智能体并行可以增加任务吞吐，并把 CPU、浏览器与外部服务等待时间重叠起来。不过，并行不等于更快完成单个关键路径任务：若多个智能体重复检索、写入同一份状态，或需要多轮相互校验，端到端延迟和 Token 成本都可能上升。

状态共享是价值核心，也是工程风险

Teammates 可以拉取用户现有 Perplexity 工具中的项目、技能与记忆，这意味着它不必在每次新会话中重建全部上下文。对持续研究、报告迭代和周期性运营任务而言，这种状态复用可以降低重复提示开销，并减少不同智能体各自理解项目背景时产生的偏差。

但共享记忆也会扩大攻击面。多个常驻智能体若能同时访问浏览器、文件、代码仓库或企业系统，就必须明确以下边界：

• 每个角色的最小权限和可写目录；
• 记忆的来源追踪、过期策略与敏感信息脱敏；
• 并发修改时的冲突检测和事务机制；
• 工具调用失败后的重试、幂等与回滚策略；
• 用户审批发生在动作前还是结果提交前。

尤其需要关注 prompt injection：网页或文件中的恶意文本可能跨智能体传播，并通过共享记忆影响其他角色。架构上应将外部内容视为不可信数据，而不是系统指令，并为每个智能体设置隔离的执行上下文。

与 Computer、Dots 和 Claude Duet 的定位差异

Teammates 建立在 Perplexity Computer 之上。Computer 更接近设备端执行层，负责让智能体操作本地应用；Teammates 则增加工作区、角色和并行协作抽象。这种分层有助于复用设备执行能力，但也要求系统处理跨角色依赖：某个智能体完成浏览器操作后，其他智能体如何确认其状态仍然有效。

它与 OpenAI Dots、Anthropic Claude Duet 瞄准的是相近市场：让多个智能体共同完成持续性知识工作，而不是只提供聊天窗口。真正的差异不会由功能名称决定，而取决于任务完成率、等待时间、人工介入频率以及能否在真实软件中稳定执行。

吞吐、延迟与成本的权衡

多智能体并行通常能提高工作区吞吐，因为不同任务可重叠执行。其资源成本却可能高于单智能体方案：每个角色都可能拥有独立上下文、工具调用记录和推理预算，模型调用次数往往随角色数增长。

如果总并发角色数为 (N)，且每个角色平均产生 (M) 次模型调用，则粗略调用量随 (NM) 增长；当多个角色共享部分上下文时，缓存命中可以降低重复预填充成本，但 KV Cache、工具状态和记忆索引仍会占用内存。部署时应根据任务独立性和阶段边界动态分配角色，而不是为所有子任务固定创建常驻进程。

实际评估至少应覆盖：

• 任务完成率与人工返工率；
• p50、p95 端到端延迟；
• 单个成功任务的模型 Token 与工具调用成本；
• 并发工作区下的资源隔离和尾延迟；
• 浏览器或桌面操作失败后的恢复能力；
• 记忆污染、越权访问与错误回传率。

评测仍需避免只看官方演示

当前报道没有披露 Teammates 的底层模型、编排策略、Computer 动作成功率、沙箱实现、任务基准、延迟或价格。官方描述中的“持续”“大规模”协作需要转化为可复现指标，例如数小时研究任务中的信息覆盖率、引用正确率、跨智能体状态一致性，以及遇到权限请求时能否正确暂停。

若没有公开基线，开发团队可自建任务集：同时设置可并行子任务与必须串行的依赖任务，对比单智能体、顺序多智能体和 Teammates；再注入网页提示注入、过期记忆、工具超时与并发写入，观察系统在故障下是否保持可控。

开发者与团队的落地建议

对于个人用户，Teammates 适合作为并行研究与内容整理工作台，但应从边界清晰、可验证的任务开始，例如竞品调研汇总、文档差异检查和周期性报告，而不是直接授权支付、删库或修改生产系统。

对于企业团队，评估重点应放在治理而非演示效果：建立智能体角色与权限矩阵，对文件写入、账号操作和外部发布设置人工审批；为每项操作保留工具调用日志和状态版本；对共享记忆做租户隔离、来源标注与定期清理；同时统计每个业务结果实际消耗的模型与工具资源。

Teammates 显示 Perplexity 正从“信息检索与回答产品”向“设备执行加多智能体协作平台”扩展。其方向与 OpenAI、Anthropic 的工作型智能体正面重合，但公开信息尚不足以证明其可靠性或成本优势。决定其竞争力的，不是智能体数量，而是能否在长时间运行中维持状态正确、权限可控、失败可恢复，并将多智能体并行转化为稳定的业务产出。

---

消息来源：The Verge AI (2026-11-05)

—— 完 ——

主题标签： #Perplexity 关注 #多智能体 关注 #AI智能体 关注 #工作流自动化 关注 #设备端执行 关注