1968 年，一項開創性研究發現了一件事，從此塑造了矽谷數十年的發展：頂尖軟體工程師的生產力遠超同儕。自此之後，每家科技公司都在尋找那些能創造非凡成果的稀有人才。
一月假期結束後，我們的工程團隊受到前沿模型進展的啟發，開始並行使用 git worktrees、Claude Code 和 Codex 來運行 Agent。在某些任務上，他們的工作效率提升了 5 倍。
這引出了一個更大的問題：如果 Agent 能在一個月內讓工程師變得如此高效，那麼要怎麼讓 Sierra 的每個人都達到這個水準？我們成立了一個六人的 AI 加速團隊來尋找答案。這篇部落格解釋了我們建立的內容，以及我們在此過程中的收穫。
1. 單一 Agent
我們從一組角色專屬的 Agent 開始：一個支援 Agent（PINE）、一個數據分析師（Pinewood）、一個工程師（Pinecone）和一個銷售 Agent（Reggie Jr）。每個角色一個 Agent 看似直觀，但在實踐中卻失敗了。
表面上看，問題在於員工需要記住哪個 Agent 負責什麼。我們喜歡以松樹命名，這也沒幫上忙。但更深層的問題是結構性的——最重要的工作往往跨越團隊，而非僅限於團隊內部。
企業的核心是一系列要完成的工作。以推出產品為例，這涉及技術團隊以及銷售、行銷、法務和營運。部門之所以存在，是因為一個團隊或一個人無法完成工作的每個部分。AI 改變了這一點，因為它越來越能夠端到端地完成工作。
因此，我們將所有這些角色專屬的 Agent 整合成一個 Pinecone：一個單一的 Agent，只有一個 Slack 帳號、一個 URL，以及從問題到完成結果之間不間斷的執行緒。Pinecone 會自行判斷要從哪些系統獲取資訊，以及如何處理請求，員工無需操心。這在技術上很困難，但這正是 AI 的意義所在：科技吸收複雜性，而不是讓員工來承擔。
這個教訓我們已經從自己的平台中學到了。建立在 Sierra 上的 Agent 是全方位服務的：一個 Agent 可以處理從產品探索到帳戶設定、故障排除、帳單等一切事務。而不是像舊式 IVR 那樣「按 1 找銷售，按 2 找支援」。
將一切濃縮到一個 Agent 中，能讓你更接近企業價值的所在——也就是要完成的工作。每一項改進都惠及整個業務，因此每個人的表現都會變得更好、更快。
2. 主動而非被動
大多數工作並非一次就能完成。它會隨著團隊學習、優先事項轉移和新資訊出現而持續數天、數週甚至數月。一個只在被召喚時出現、在會話結束時消失的 Agent 用處有限。Pinecone 會貫穿整個過程——持續攜帶上下文，並在需要時重新接續執行緒，直到整個工作（而非僅僅單一請求）完成。
持續性也使 Pinecone 能夠主動出擊。它無需等待被詢問，可以在下一步準備就緒時採取行動——例如工件觸發 Webhook、Linear 中出現任務、收到審查意見。它會收集上下文並進行初步處理，在需要人類判斷時才引入他們。會議前，準備筆記已就緒。面試後，在你坐下來打分之前，摘要已經起草完畢。審查意見到達時，附帶了摘要、關鍵風險和建議的評論。目標不是增加更多通知，而是減少未完成的工作。
我們還沒有完全掌握這一點——大多數會話仍然由人類提示開始——但反轉這種關係，讓 Agent 在需要時提示人類，正是持續性引領我們前進的方向。
3. 商業上下文是瓶頸，而非智力
AI 的瓶頸曾經是原始智力——模型是否足夠聰明。如今，前沿模型對大多數商業需求來說已經足夠。因此瓶頸轉移到了上下文：你公司的特定資訊、工作流程、歷史記錄，以及訓練集中不會出現的判斷決策。
一月份，我們團隊的兩個人用 Claude Code 和 Opus 4.6 快速搭建了一個數據分析師 Agent，並透過模型上下文協定（MCP）和命令列工具連接到我們的系統。在沒有太多額外指導的情況下，它能在幾分鐘內調查跨 Slack、GitHub、ClickHouse、Salesforce 和 PagerDuty 的客戶問題。過去需要耗費一下午的工作，現在成了除錯和事件回應的第一步。
同樣的模式遠遠超出了除錯的範疇。擁有完整上下文的 Agent 可以準備客戶會議、研究帳戶、審查合約或 RFP、追蹤產品決策，並將分散的工作轉化為完整的工件。當然，讓 Agent 存取所有這些上下文會引入一個新問題。不受限制的 Agent 會帶來巨大的安全和隱私風險。我們的 MCP Gateway 解決了這個問題：Pinecone 繼承每位員工的存取權限，在每次工具呼叫時執行策略，隔離客戶資料，並留下稽核軌跡。
閱讀圖片描述
ALT
Sierra MCP Gateway 將 Agent 連接到 37 個系統
Pinecone 建立在 Claude Code 和 Codex 之上。它們的頻繁改進是順風，但技術水準不斷變化——一個模型可能最擅長規劃，另一個擅長編碼，第三個擅長寫作。擁有模型之上的層級，讓我們能將每個任務路由到最合適的模型，在停機時進行故障轉移，管理成本，同時避免受制於任何單一供應商。但持久的優勢不在於擁有底層模型，而在於擁有上下文、工作流程和路由層，這讓每個模型都變得更有用。
我們也在嘗試讓 Pinecone「作夢」：反思每日工作，並提出改進自身技能的建議。隨著時間推移，這就是一個只為 Sierra 工作的 Agent 與一個從 Sierra 學習的 Agent 之間的差異。
4. Agent 是 UI，記錄系統是後端
每一項工作都會產生具體的成果——一個工件。編碼 Agent 最先發現了他們的工件：Pull Request。其他部門也有各自的對應物——客戶案例、合約、RFP 問卷、提案簡報、績效評估。
工件既是輸入也是輸出。它們為 Agent 提供執行工作所需的上下文——也同時是完成工作的歸屬地。要求 Pinecone 修改提案簡報，簡報本身就會被更新，而不是收到一則聊天訊息告訴你要改什麼。
我們發現最好的做法是與你的記錄系統協作，而不是取代它們。GitHub 保留 PR，Salesforce 保留帳戶，Linear 保留問題——Agent 是橫跨它們的層。
取代這些系統意味著要重新創造數十年來成熟的軟體。更糟的是，這會將公司一分為二——一部分人透過 Agent 工作，另一部分人直接在原始工具中工作，各自擁有不同的真相版本。我們的賭注是，隨著時間推移，這些產品會更像後端，而 Agent 則成為主要介面。
5. 成果，而非僅僅活動
自 Pinecone 三月首次提交以來，它已為 600 多人運行了超過 75,000 次會話。如今，我們 70% 的 PR 是透過它開啟的，同時還有數百個自動化任務在安靜地處理著沒有人明確提示的工作。
這類數字很誘人，讓人想先拿出來說。在早期階段，它們的確是值得追蹤的指標——它們證明某個東西真的在被使用，而不是停在路線圖投影片上積灰塵。但會話次數和工具呼叫是活動，而非成果。一個團隊可以透過最大化 token 使用量，讓採用圖表看起來很 impressive，但下游卻沒有任何實質改善——同樣的錯誤數量，同樣的週期時間，只是有更多 AI 參與其中。
所以 token 使用量是一個不錯的起點。團隊需要先養成使用工具的習慣，然後才能衡量它是否有效。但這不是價值的所在，我們也不希望故事到這裡就結束。我們努力想問的問題不是 Agent 做了多少事，而是因為它，實際改變了什麼：交易是否更快完成？客戶問題是否在第一次就得到解決？某人是否因為不再需要深夜完成審查而拿回了自己的夜晚？
我們目前還沒有很好的方法來衡量這一點。會話和工具呼叫只是比較容易計算。但這個差距——我們今天能衡量的和我們真正關心的之間的差距——是我們接下來要努力的方向。
1968 年的那項研究發現了頂尖與一般之間 10 倍的差距——五十年來，唯一的答案就是去尋找那些稀有人才。現在有一個更好的答案：給每個人一個 Agent，讓他們擁有少數人的優勢。目標不僅是完成更多工作，更是讓人們有更多時間去做只有人類能做的事：判斷、品味、創造力，以及建立關係。
接下來
我們將深入探討我們建立的系統：
- Allen Chen 談 Pinecone、它的多次迭代，以及背後的技術架構
- Mihai Parparita 談 MCP Gateway 與安全收集完整上下文
- Rohith Ravi 談 Agency——這一切背後的基礎設施
