Perplexity 應把 Teammate 做成 coding agent，…

20 billion-dollar Perplexity 正在測試 Teammate，正確方向不是 autocomplete，而是長任務 coding agent。

Perplexity 應把 Teammate 做成能長時間持有上下文、處理任務與事件的 coding agent，而不是另一個 autocomplete 式 copilot。Business Insider 在 2026 年 7 月 7 日報導，Perplexity 自 5 月起內測代號 Teammate 的工具，且描述重點是 model-agnostic、任務擁有、問題調查與服務監控。這些訊號比「又有新產品」更重要，因為工程團隊真正缺的不是更多補全建議，而是能跨 repo、log、CI 與事故脈絡維持狀態的系統。

第一個論點

會贏的產品類別，通常不是回應最快的那個，而是能把任務真正接住的那個。一次 bug 修復不只是一段 prompt，它牽涉 stack trace、feature flag、部署紀錄、權限與代碼責任。Cursor 與 Claude Code 之所以能站穩，是因為它們已經不只是文字生成器，而是開始進入工作流。Teammate 若要更進一步，就不能停留在「幫你寫一段 code」；它要把任務視為有狀態、有歷史、有交接點的持久物件。

Perplexity 在這裡其實有結構優勢，因為它本來就擅長檢索與上下文組裝。若一個 coding assistant 能把 code、文件、ticket 與 observability data 串起來，它就不只是模型包裝器，而是工程決策引擎。以實務來說，工具回覆不該只給結論，還要附上依據：是哪些檔案、哪些 log、哪些依賴關係影響了建議。沒有證據鏈的 patch 建議，只是更像樣的猜測。

第二個論點

model-agnostic 不是妥協，而是正確的架構選擇。工程任務本來就不是單一模型能平均解好的：規劃、程式搜尋、摘要、修補、事故分流，各自需要不同能力。若 Teammate 能在不同後端之間路由任務，Perplexity 就不必每次模型市場變動都重做產品。對一個要做長任務代理的人來說，架構彈性比「我們用了最強模型」更有商業價值。

更重要的是信任。當工具碰到私有 repo 或 production 系統，團隊需要知道每一步到底發生了什麼：取了哪些 context、用了哪些憑證、建議了哪些動作、哪些被人核准、哪些真的執行。這不是加分項，而是能不能進企業的門檻。若沒有完整 audit trail，Teammate 只會是包裝更好的黑盒子，工程主管不會把 code change 或 incident response 交給它。

反方可能怎麼說

最強的反對意見很直接：coding assistant 市場已經很擠，而且 Perplexity 來得晚。Cursor 已經拿到 builder 心智，Claude Code 有強模型與清楚的開發者敘事，GitHub Copilot 更是深嵌在大量工作流裡。在這種局面下，另一個 assistant 很容易變成功能，而不是公司。單靠搜尋強項，不足以保證採用。

這個反對意見成立，但只成立到一半。Perplexity 不需要先在所有維度打敗對手，它只要在最難的那一段做得更好：長時間、具狀態、可稽核的工程工作。若 Teammate 能跨系統調查問題、維持任務記憶、產出可審核的動作，它就不是又一個 chat box，而是另一個品類。限制也很清楚：如果最後只是 code 版對話介面，它會輸；如果它真的是 task-owning agent，它就有位置。

你能做什麼

如果你是工程師、PM 或創辦人，評估 Teammate 時不要先看模型名氣，要看工作流品質：它能不能跨檔案與事故保留任務狀態、能不能揭露檢索與動作紀錄、能不能尊重 repo 權限、能不能讓人類在關鍵步驟逐一審核。若 Perplexity 把這些細節做好，Teammate 就不只是 coding assistant，而會是一個真正能進工程現場的 agent。