Perplexity 在 2026 年 11 月 5 日发布的 Teammates，将产品从「单次问答框」推向后台常驻的数字同事。它架在底层执行层 Perplexity Computer 之上，直接复用工作区已有的项目（Projects）、技能（Skills）与跨会话记忆（Memory），按角色并行处理长周期工作，并通过独立线程和 Slack 汇报进度。
对独自负责情报追踪、指标监控或跨文档调研的个人用户，这种免去重喂背景、全天后台盯盘的模式能省下大量重复操作。但对需要多人与多 Agent 混编交付的工程团队而言，绑在 200 美元/月个人 Max 订阅下、靠聊天线程追进度的「常驻队友」，距离真实可用的任务看板、代码工作区隔离与分级验收流还差关键三步。
问题：把问答框换成常驻队友，为何仍接不住团队交付
近期主流厂商纷纷把 Agent 从临时会话改造成常驻后台角色：OpenAI 推出 Dots，Anthropic 上线 Claude Duet，Perplexity 则拿出 Teammates（三者跨团队配额与计费细则未完全公开，待核实）。各家瞄准的痛点一致：真实工作不是单次问答，而是持续数周的增长跟进、缺陷分拣与仓库维护。
但把单次对话拉长成「常驻线程」，解决不了团队交付的三个矛盾：
- 上下文所有权矛盾：常驻 Agent 的记忆若绑在个人高价订阅账号下，团队其他成员如何共享、修正并审计？
- 过程信噪比矛盾：当十几个常驻 Agent 同时在各自线程和 Slack 频道发通知、求确认时，负责人很难分清哪项卡在审批、哪项已可验收。
- 代码与环境隔离矛盾：多个角色同时操作 GitHub 仓库或 Linear 工单时，若缺乏独立分支沙箱与状态闸门，后台自动执行极易变成互相覆盖改动的事故。
机制一：Teammates 与底层 Perplexity Computer 如何分工
要看清这套系统的边界，需先拆开 Perplexity Teammates 与底层 Perplexity Computer 的双层分工。
如架构图所示，两者按「上层管角色与上下文、下层管环境与工具执行」切分：
- 上层 Teammates（角色定义与工作区复用）：每个 Teammate 对应一项长期职责，如「研发值班助手」或「增长运营经理」。它直接拉取用户在 Perplexity 工作区已有的 Projects（项目文档与目标）、Skills（可复用指令集与手册） 及 Memory（跨会话持久记忆）。用户可在同一工作区给不同 Teammates 派活，各角色在独立线程保留上下文。
- 底层 Perplexity Computer（隔离执行器与子 Agent 编排）：实际执行落到底层 Perplexity Computer。每个 Teammate 运行在隔离的虚拟桌面与真实浏览器环境中，具备独立文件系统与代码执行能力（单实例沙箱配额与并发上限未披露，待核实）。面对复杂目标时，它在 Perplexity Computer 上拆解子任务，拉起多个子 Agent 并行执行，并支持按子任务指定底层模型（如 Claude 系列等，待核实）。
- 外部工具监听与主动跟进：挂载 Slack、GitHub 和 Linear 连接器后，Teammates 可持续监听外部变更。当 GitHub Pull Request 收到审阅评论或指标异动时，它主动触发子任务，并在需拍板时作为应用在 Slack 频道或私信里 @ 人类同事，或与其他 AI Teammates 协调。
机制二：对话线程驱动与结构化任务模型的混编交付对照
据 The Verge 报道，Perplexity Teammates 目前作为网页端研究预览版，仅向月费 200 美元的 Perplexity Max 订阅用户开放，桌面与移动端应用仍在规划中（上线时间未公布，待核实）。把这套「个人 Max 订阅 + 独立线程 + Slack 消息」模式放进工程团队，它与结构化任务协作差了三步，这也构成了与 HiFox「空间（Space）+ 任务（Task）+ 成员/Agent/小队（Crew）+ 电脑（Computer）与运行时（Runtime）」模型的直接对照：
- 协作单元：聊天线程跟进 vs 结构化任务看板验收
Teammates 以角色线程为中心，单人启动快、免建单，但多人协作缺乏全局生命周期视图。而在 HiFox 中，与 Agent 对话和任务严格分离：对话仅个人可见，用于临时探索；正式交付落入空间（Space）下的任务，集中承载 Backlog、Todo、In Progress 等状态、优先级、阻塞关系与运行记录。这也契合《AI Agent 任务管理：谁派活，谁验收？》的原则：过程留在任务上，而非淹没在聊天框里。 - 多角色协同：平级线程互发消息 vs 小队（Crew）队长统筹分工
Teammates 模式下多个角色平级互发消息，易职责重叠或无人收口。HiFox 则提供小队（Crew）机制：小队归属特定空间，由组织成员任所有者，并指定一个 队长 Agent 搭配多个成员（前端、测试、Review Agent 或人类成员）。任务指派给小队后，先启动队长 Agent 读取任务上下文与小队指令，再由队长决定是否在评论中 @ 成员 Agent 分工，结果统一写回同一任务。 - 执行环境与权限隔离：托管沙箱黑盒 vs 自有电脑 Runtime 与 Worktree 隔离
Perplexity Computer 提供云端隔离桌面（及与 NVIDIA 合作的本地部署方案，待核实），但绑在个人订阅上难以复用团队内网与分级凭据。HiFox 将Agent 配置与底层电脑（Computer）解耦：支持接入本地电脑、远程服务器或 Docker 容器，调用 Claude Code、Codex 等 Runtime；个人电脑默认仅个人可见，多人共享用专用远程电脑。多任务并行改代码时，在 Agent 工作目录 中默认建议选择「创建临时目录」或指定目录后的「Worktree 隔离运行（并行）」，将改动提交到独立的hifox-agent/<Agent 名称>/<任务编号>分支（见Agent 如何执行任务），经人工 review 后再合并。
怎么做：四步把常驻 Agent 接进可验收的团队工作流
无论团队在评估 Perplexity Teammates，还是用编程 Agent 搭建多角色协作流，都可按四步落地：
- 按「单人探索」与「多人交付」切分入口：把竞品搜索、资料摘要留在个人对话或独立 Teammate 线程中；凡涉及代码修改、跨角色交接或上线审批的工作，一律建为带验收标准的任务单。
- 按单一职责拆分角色并固化技能（Skills）：不建全能队友。把长期职责边界写进 Agent 指令，将跨角色复用步骤抽成技能（Skills），拆出独立的开发、测试与 Review 角色，由小队队长调度。
- 在 IM 频道与任务看板间建立显式转换：参考 HiFox 的Slack 集成与《给编程 Agent 用的 Slack 机器人》，把用于单聊、频道 @ 和线程对话的「Agent 机器人」与负责在频道里根据聊天上下文整理需求、创建该空间任务的「任务助手」拆开，防止待办遗失在群聊里。
- 为并行执行强制开启 Git Worktree 分支隔离：连接执行电脑时，把并行任务的默认工作目录设为「创建临时目录」或「Worktree 隔离运行（并行）」，禁止多个常驻 Agent 覆写同一目录。
哪些坑要避开
第一，别把「内部数千个 AI 队友」的宣传当成已验证的工程实践。Perplexity CEO Aravind Srinivas 在社交平台称，公司内部已生成数千个活跃 Teammates，远超人类员工数，并展望未来每人管理上百个 AI 队友（属厂商自述口径，未披露活跃定义与有效交付占比，待核实）。拉起上百个后台线程只需几分钟，但工程师每天能审阅的 PR 与方案有硬上限。如《迭代：按人的审查能力排期，不按 Agent 的产出排期》所述，脱离审阅带宽堆砌常驻 Agent，只会制造积压通知与无人敢合入的草稿。
第二，别把「能发 Slack 消息」等同于完成了团队交接。如《AI 助手 vs AI 队友：停下手动盯屏后，工作变了什么》分析，真正的队友须遵守权限边界与交接契约。若常驻 Agent 在后台直接改写工单或推送主干，却无任务级执行转录可回溯，排障成本反而高于人工。
结论：先定任务验收容器，再配常驻 Agent 执行器
Perplexity 推出月费 200 美元的 Teammates 表明，行业竞争已进入「常驻角色 + 底层执行器」阶段。但对多人团队而言，对话线程替代不了结构化看板。若准备引入多角色常驻 Agent，建议先在 HiFox 中用小队（Crew）定义队长与成员分工，将执行环境连到开启独立 worktree 的自有电脑，让每次后台并行执行都沉淀在可审查的任务之上。
HiFox
