軟件開發(fā)者大部分時間并非在編寫代碼；最新行業(yè)研究發(fā)現(xiàn)，實際編程僅占開發(fā)者工作時間的16%，其余84%都被運營和支持性任務占用。當工程團隊被要求"用更少資源做更多事情"，CEO們吹噓他們的代碼庫有多少由AI編寫時，一個問題仍然存在：如何優(yōu)化工程師們工作的其余84%的任務？

**讓開發(fā)者保持在最高效的狀態(tài)**

影響開發(fā)者生產(chǎn)力的主要因素是上下文切換：在構建和交付軟件所需的日益增長的工具和平臺之間不斷跳轉。哈佛商業(yè)評論研究發(fā)現(xiàn)，普通數(shù)字工作者每天在應用程序和網(wǎng)站之間切換近1200次。每次中斷都很重要。加州大學發(fā)現(xiàn)，完全從單次中斷中重新獲得專注需要約23分鐘，有時更糟，因為近30%的被中斷任務永遠不會被重新開始。上下文切換實際上是DORA這一最受歡迎的軟件開發(fā)性能框架的核心。

在AI驅動的公司試圖讓員工用更少資源做更多事情的時代，除了"僅僅"給他們提供大語言模型訪問權限外，一些趨勢正在涌現(xiàn)。例如，Brex首席工程師Jarrod Ruhland假設"開發(fā)者在專注于集成開發(fā)環(huán)境(IDE)時能交付最高價值"。基于這一想法，他決定尋找新方法來實現(xiàn)這一點，而Anthropic的新協(xié)議可能是關鍵之一。

**MCP：將上下文引入IDE的協(xié)議**

編程助手，如由大語言模型驅動的IDE（如Cursor、Copilot和Windsurf），正處于開發(fā)者復興的中心。它們的采用速度前所未有。Cursor成為歷史上增長最快的SaaS，在推出12個月內就達到了1億美元的年度經(jīng)常性收入，財富500強公司中有70%使用Microsoft Copilot。

但這些編程助手僅限于代碼庫上下文，雖然能幫助開發(fā)者更快地編寫代碼，但無法解決上下文切換問題。一個新協(xié)議正在解決這個問題：模型上下文協(xié)議(MCP)。該協(xié)議由Anthropic于2024年11月發(fā)布，是一個開放標準，旨在促進AI系統(tǒng)（特別是基于大語言模型的工具）與外部工具和數(shù)據(jù)源之間的集成。該協(xié)議非常受歡迎，在過去6個月中新MCP服務器增長了500%，6月份估計下載量達到700萬次。

MCP最具影響力的應用之一是能夠將AI編程助手直接連接到開發(fā)者每天依賴的工具，簡化工作流程并大幅減少上下文切換。

以功能開發(fā)為例。傳統(tǒng)上，這涉及在多個系統(tǒng)之間跳轉：在項目跟蹤器中讀取工單、查看與團隊成員的對話以獲得澄清、搜索文檔獲取API詳細信息，最后打開IDE開始編碼。每個步驟都在不同的標簽頁中，需要心理轉換，這會拖慢開發(fā)者的速度。

有了MCP和現(xiàn)代AI助手如Anthropic的Claude，整個過程可以在編輯器內完成。例如，在編程助手內實現(xiàn)功能的過程變?yōu)椋?/p>

- 使用Linear MCP服務器提取工單詳情；

- 使用Slack MCP服務器展示相關對話；

- 使用Glean MCP服務器引入正確的文檔；

- 通過詢問Cursor為其編寫腳手架來編寫功能。

同樣的原理可以應用于許多其他工程師工作流程，例如SRE的事件響應可能如下：

- 通過Rootly MCP服務器提取事件；

- 通過Sentry MCP服務器檢索跟蹤數(shù)據(jù)；

- 通過Chronosphere MCP服務器導入可觀察性指標；

- 通過詢問Claude Desktop解決導致事件的錯誤。

**沒有什么新鮮事**

我們以前見過這種模式。在過去十年中，Slack通過成為數(shù)百個應用程序的中心來改變工作場所生產(chǎn)力，使員工能夠在不離開聊天窗口的情況下管理各種任務。Slack的平臺減少了日常工作流程中的上下文切換。

例如，Riot Games連接了大約1000個Slack應用程序，工程師看到測試和迭代代碼所需時間減少了27%，識別新錯誤的時間加快了22%，功能發(fā)布率提高了24%；這些都歸因于簡化工作流程和減少工具切換的摩擦。

現(xiàn)在，軟件開發(fā)中正在發(fā)生類似的轉變，AI助手及其MCP集成充當連接所有這些外部工具的橋梁。實際上，IDE可能成為工程師的新一體化指揮中心，就像Slack對一般知識工作者一樣。

**MCP可能還未企業(yè)就緒**

MCP是一個相對新興的標準，例如，在安全方面，MCP沒有內置的身份驗證或權限模型，依賴于仍在發(fā)展的外部實現(xiàn)。在身份和審計方面也存在模糊性——協(xié)議沒有清楚地區(qū)分動作是由用戶還是AI本身觸發(fā)的，這使得在沒有額外自定義解決方案的情況下，問責制和訪問控制變得困難。F5 Networks CTO辦公室的杰出工程師兼首席布道師Lori MacVittie說，MCP"打破了我們長期持有的核心安全假設"。

另一個實際限制出現(xiàn)在同時使用太多MCP工具或服務器時，例如在編程助手內部。每個MCP服務器都會公布一個工具列表，包括AI模型需要考慮的描述和參數(shù)。用數(shù)十個可用工具淹沒模型可能會壓倒其上下文窗口。隨著工具數(shù)量的增長，性能顯著下降，一些IDE集成已經(jīng)設置了硬限制（Cursor IDE中約40個工具，或OpenAI智能體約20個工具）以防止提示超出模型能處理的范圍。

最后，除了列出所有工具外，沒有復雜的方式讓工具被自動發(fā)現(xiàn)或根據(jù)上下文建議，因此開發(fā)者經(jīng)常必須手動切換它們或策劃哪些工具處于活動狀態(tài)以保持平穩(wěn)運行。參考Riot Games安裝1000個Slack應用程序的例子，我們可以看到這可能不適合企業(yè)使用。

**減少轉椅操作，增加軟件開發(fā)**

過去十年教會我們將工作帶給工作者的價值，從傳輸更新的Slack頻道到"收件箱零"電子郵件方法和統(tǒng)一平臺工程儀表板?，F(xiàn)在，有了AI工具包，我們有機會讓開發(fā)者更有生產(chǎn)力。如果說Slack成為了商業(yè)溝通的中心，那么編程助手很好地定位為軟件創(chuàng)建的中心，不僅是編寫代碼的地方，而且是所有上下文和協(xié)作者匯聚的地方。通過保持開發(fā)者的流暢狀態(tài)，我們消除了困擾工程生產(chǎn)力的持續(xù)心理換擋。

對于任何依賴軟件交付的組織，仔細審視開發(fā)者如何度過他們的一天；你可能會對發(fā)現(xiàn)的情況感到驚訝。

Q&A

Q1：MCP協(xié)議是什么？它能解決什么問題？

A：MCP（模型上下文協(xié)議）是Anthropic于2024年11月發(fā)布的開放標準，旨在促進AI系統(tǒng)與外部工具和數(shù)據(jù)源之間的集成。它主要解決開發(fā)者在不同工具間頻繁切換的問題，讓開發(fā)者能在IDE內直接訪問項目跟蹤器、聊天工具、文檔等，減少上下文切換。

Q2：開發(fā)者為什么需要減少上下文切換？

A：研究發(fā)現(xiàn)開發(fā)者每天在應用程序和網(wǎng)站之間切換近1200次，每次中斷后需要約23分鐘才能重新獲得專注，而近30%的被中斷任務永遠不會被重新開始。實際編程僅占開發(fā)者工作時間的16%，其余84%被運營和支持性任務占用，減少上下文切換能顯著提高生產(chǎn)力。

Q3：MCP協(xié)議在企業(yè)應用中有什么限制？

A：MCP目前還不夠企業(yè)就緒，主要限制包括：沒有內置的身份驗證或權限模型；無法區(qū)分動作是由用戶還是AI觸發(fā)，存在安全風險；同時使用太多工具會壓倒模型的上下文窗口；缺乏工具的自動發(fā)現(xiàn)機制，需要手動管理。