Microsoft Copilot Harness 透過 Foundry 開放，改變自建還是採購的決策
Microsoft 於 10 月 28 日透過 Foundry 開放其 Microsoft Copilot harness，將原屬內部的執行基礎提供予開發人員，同時仍由其掌控營運。Harness 是圍繞 AI 模型的軟件，用於編排指示、背景資訊、工具及執行流程。這項公告改變了企業可以採購而毋須自行建立的部分，但並未免除其對最終工作成果的責任。
核心選擇在於，是自行維護這套執行機制，還是採用 Microsoft 的受管理方案。代理是利用模型及工具推進任務的軟件，所需的不只是存取強大模型。總要有人決定它如何持續執行、處理故障，以及維持在業務界線之內。
Anthropic 已提供競爭性的受管理方案，讓買方可在 Microsoft 產品家族以外作出有用的比較。Microsoft 的獨特主張著重透過共享基礎設施存取不同模型家族。對開發團隊而言，這帶來一個實際問題：哪些責任較容易交託，哪些仍需要因應應用程式作出判斷？
Microsoft Copilot Harness 進入 Foundry 公開預覽
Microsoft 正將共享的產品基礎轉化為客戶應用程式可用的受管理建構元件。
根據 Microsoft 的多模型 harness 公告，GitHub 的工程團隊在 Microsoft 將其採用至各項 Copilot 體驗前，已開發出這套 harness。公司列出 Copilot Code、Copilot Studio、GitHub Copilot app、命令列介面及 VS Code 為其使用者。
Foundry Agent Service 是 Microsoft 用於建立及營運代理的平台，現於公開預覽階段提供這套 harness。這個狀態相當重要，因為公告結合了一項成熟的內部技術與一項新推出的受管理服務。已在 Microsoft 產品中累積的經驗，並不會自動證明它已適用於每位外部客戶的工作負載。
Microsoft 描述了一種責任分工：由它負責執行機制，而客戶提供其應用程式專屬的指示及連接。這項安排令推出服務的意義超越程式編碼助手。開發研究助手或營運代理的公司，可以考慮採購過去被視為內部工程工作的基礎設施。
公告亦提到可下載的軟件開發套件，即開發人員用來將技術整合至應用程式的套件。這條途徑不應與受管理的 Foundry 體驗混為一談。選擇分發方式與選擇誰來營運服務雖然相關，卻回答不同問題。
對企業買方而言，眼前改變是多了一個實作選項。評估代理的團隊不再需要假設，支援不同模型便必須自行維護周邊執行系統。Microsoft 正提出代客戶維護這個共享基礎。
這項提議值得精確解讀。採購受管理 harness，並不代表某個特定工作流程必然產生正確答案或採取恰當行動。它改變的是誰提供部分機制。買方仍需證明完整應用程式符合其自身要求。
設想一個假定的研究應用程式，比較供應商公告並編製內部簡報。其有用產出包括準確來源、清晰日期，以及明確處理相互矛盾的資訊。能運作的執行系統可支援這項工作，但無法為機構界定那些編輯要求。
因此，這次推出改變了架構討論的起點。團隊不必只問哪個模型應回答請求，還可問代理執行的哪些部分值得自行工程開發。這比在選擇選單中多出另一個模型更具影響。
壓力落在自行維護執行機制的團隊身上
Microsoft 的方案令內部基礎設施項目受到審視，特別是那些複製既有能力卻未帶來業務優勢的項目。
最大壓力落在已為代理維護周邊機制的應用程式團隊身上。他們的管理人員現在有另一個外部選項可供檢視。繼續採用自訂實作，成為需要充分理據支持的決定，而不再是推出代理的預設前提。
這些理據仍可能相當有力。企業可能需要不尋常的執行行為、專門整合，或直接控制工作如何推進。關鍵分別在於，這些要求是否實質影響應用程式。當機構能清楚指出該控制權帶來甚麼成果時，自行擁有及維護方案便較為合理。
採購基礎設施會帶來另一項責任：理解供應商的邊界。開發團隊不能只憑示範所展示的能力評估受管理服務，必須辨識平台在哪裡結束，以及其自身軟件、程序與監督從哪裡開始。
Microsoft 的受管理代理執行公告概述了技能、已連接工具、檔案及程式碼執行，以及有界委派。技能是連同指示及支援資源封裝的可重用程序。工具讓代理可存取外部資訊或採取行動。這些能力所描述的，是比單純文字生成更廣泛的應用程式基礎。
同一公告亦提供早期客戶觀點。Confluence Technologies 的首席技術總監 Chris Evans 表示，公司在不足一星期內便讓方案運行起來。這是一則有用的實作軼事，但不足以證明典型部署時程或長期營運成果。
對買方而言，重要分別在於達致初步可運作狀態，與維持可靠服務之間。內部原型可以容忍營運應用程式無法容忍的假設。受管理基礎可縮短部分工程工作，但整合審查、驗收標準及責任歸屬的決定仍未解決。
因此，有用的財務比較應審視完整工作流程，而非單一模型回應。相關考量包括工程維護、故障調查、人手審核，以及已連接系統的變更。由於這些責任因機構而異，這次推出不會帶來放諸四海皆準的計算方式。
壓力亦延伸至圍繞模型提供產品的基礎設施供應商。Microsoft 的分發方式令客戶有更多理由質疑自己還需要哪些獨立元件。這並不表示獨立產品變得不必要，而是提高了它們說明所提供額外控制、可見性或專業化價值的門檻。
對知識工作者而言，影響以另一種形式出現。他們會感受到代理能否完成可用交付成果、保留恰當證據，以及適當地升級處理不確定性。當架構改變能減少未完成工作，或令錯誤更容易識別及修正，這項改變才對他們有意義。
這正是自建還是採購的討論不應只屬於工程師，也應由產品負責人參與的原因。機構必須先界定何謂令人滿意的成果，才決定哪種基礎設施安排能交付它。否則，技術上成功的部署可能仍令實際業務問題大致未獲處理。
模型選擇與執行時期控制是兩項不同決定
可存取不同模型，不代表客戶可無限制控制受管理服務如何執行其工作。
Microsoft 的harness 可用性 FAQ劃定了預覽版的界線。不支援自攜模型。客戶在建立新的 prompt agent 時選擇 harness，之後不能切換。可用性亦可能因地區、用戶端、工具、網絡及配額而異。
這些限制釐清了多模型支援的含義。客戶可在服務界線內評估受支援的選項。這與假設任何模型、連接或部署安排都必然可行不同，即使更廣泛的策略著重選擇亦然。
這個分別在採購期間尤其重要。模型在供應商產品組合其他地方出現，並不能回答它是否獲特定受管理體驗支援。買方需要評估打算採用的組合，包括相關部署位置及已連接系統。
更換模型與維持應用程式行為之間亦有分別。即使介面保持一致，不同模型仍可能作出不同決定或產生不同輸出。應用程式負責人應將模型變更視為須按業務要求評估的事項，而非單純行政替換。
設想一個審閱供應商提案的假定採購助手。其中一項任務是擷取交付日期，另一項是詮釋含糊的取消條款。機構可能偏好不同模型特性處理這些工作，但仍需對可接受的證據及升級處理方式作出一致定義。
共享執行基礎可令這種比較較易組織，但無法證明相同指示在所有受支援模型上都同樣有效。有用的成果是可受控地比較結果，並清楚記錄改變了甚麼及原因。
Anthropic 的受管理代理架構提供了相關的競爭比較。其 2026 年 4 月的工程說明描述，將模型及 harness 與執行環境及持久會話紀錄分離。其表明目標是讓實作可在穩定介面背後演進。
這項比較顯示，業界競爭不僅限於模型選擇。供應商亦在競爭自己可吸收哪些執行責任，同時維持客戶可依賴的介面。Microsoft 對多個模型家族的著重，處理的是這項更廣泛採購決定中的一個面向。
兩種架構描述均未證明存在普遍勝者。企業在受管理方案之間作出選擇時，需要比較實際工作流程、所需整合及營運限制。一項很適合某個應用程式的服務，可能會為另一項應用程式帶來不合適的假設。
更深層的取捨關乎靈活性位於何處。團隊可保留在受支援模型之間選擇的空間，同時接受供應商的執行設計。另一選擇是保留更多執行控制權，並承擔維護責任。這些是不同形式的靈活性，會帶來不同的工程後果。
對 Microsoft Copilot harness 而言，最有力而務實的解讀因而是有限度的選擇。客戶可多一條受管理的途徑開發 agent。他們應按該途徑已記錄的功能作出評估，而非將較廣泛的品牌定位視為普遍相容性的承諾。
Microsoft 的評估結果需要審慎解讀
Microsoft 的內部結果支持進一步評估，但並不證實每個 Foundry 應用程式都能取得同等改善。
在其 agent 評估結果中，Microsoft 比較了 Copilot Studio 內的 Copilot harness 與 Standard harness。該公司表示，使用 OpenAI 模型時通過率提升 10.8 個百分點；使用 Anthropic 模型時則提升 22.1 個百分點。
Microsoft 亦表示，在已評估個案中，工具呼叫失敗後仍會繼續嘗試的比例為 84–91%，相比之下，使用 Standard harness 的比例不足 7%。其附註明確區分持續使用工具及成功重試，與成功完成整體任務之間的差異。這些均為公司自行報告的結果，本文未有確立其獨立驗證。
這項限定是解讀此公告的核心。持續性描述的是出錯後的行為；完成則描述所要求的結果是否已達成。系統可以持續運作，卻仍可能誤解任務、採用不合適的證據，或產出不可接受的結果。
在假設的客戶服務流程中，這個分別會變得具體。一個 agent 或許能成功重試並存取個案紀錄，卻仍建議了錯誤的處理方案。衡量從連線失敗中的復原，有助說明執行行為；但不能判定客戶是否獲得準確答案。
同樣地，較高的評估通過率取決於評估所要求的內容。買家在將結果套用到自身環境前，需要了解相關任務、驗收準則及配置。百分點提升只有相對於所衡量的測試才具參考價值。
這並不減低周邊執行系統的重要性。Microsoft 所報告的比較結果，與「模型能力本身並不單獨決定 agent 成果」的觀點一致。它讓客戶有理由將執行方案與模型選擇一併測試，同時清楚交代歸因與限制。
Microsoft 亦描述了一個內部支援應用程式，於 2026 年 8 月的全自主解決率超過 35%。該公司將此指標界定為無須人工介入即可解決個案。這是一個具體的已報告部署案例，但其作為比較基準是否合適，取決於所處理的個案及營運條件。
對正在評估類似應用程式的企業而言，自主性應與正確性及後果一併考慮。一宗在無介入下解決的個案，在處理準確且恰當時可以是有用證據。單憑沒有介入，無法證明結果符合該機構的標準。
評估亦應計及轉移給審核人員的工作。若 agent 產出更多材料卻需要大量修正，產出量可能會錯誤反映其實際貢獻。商業問題在於已完成且可接受的工作，以及取得該成果所需的投入。
相同邏輯亦適用於要到較後階段才會顯現的失誤。一份措辭精緻但包含未獲支持主張的簡報，在交付時看來可能成功。檢查證據及歸因的評估，則會揭示不同結果。驗收準則應反映成果實際會如何被使用。
目前而言，Microsoft 的數字是關於其自身已測試環境的有用證據。它們足以支持進一步調查，但不能取代針對客戶的測試。買家不應將供應商比較結果轉化為對未納入所報告評估的工作負載之預測。
受管理的執行仍由客戶承擔業務責任
委託基礎設施並不會轉移決定 agent 可獲准做甚麼的責任。
最清晰的界線涉及具重大後果的行動。準備建議的 agent，與令機構受該建議約束的 agent，需要不同控制措施。受管理的執行服務可以支援任一設計，但機構必須決定授權的開始與終止位置。
Fashable 在 Microsoft 的發布材料中提供了客戶角度。行政總裁 Orlando Ribas Fernandes 描述了採購工作流程方面的機會，同時將具商業約束力的決策維持在人手控制之下。這是預期的營運界線，而非證明每項建議能力均已產生可量度成果的證據。
這個例子說明，不能從自動化推斷問責。採購助理或可比較規格、識別遺漏資訊，或準備談判材料。授權購買則引入不同責任。即使這些活動出現在同一段對話中，這個區別亦應保持清晰。
長時間運作的工作引入另一條界線：記得曾經發生甚麼，與知道甚麼仍然有效，是兩回事。agent 可以保留先前結果，卻未必知道情況已經改變。應用程式擁有人需要決定何時必須重新核實較早資料，以及哪些決策依賴最新證據。
Anthropic 的長時間運作 agent 研究描述了跨工作階段未完成工作及過早宣稱完成的失敗案例。其建議方法採用明確的進度紀錄及漸進式工作。更廣泛的啟示是，持續執行需要可靠地交代尚未完成的責任。
對企業而言，這項啟示意味著應將完成視為業務條件。當任務符合其驗收準則，包括任何必要的審核或確認時，才算完成。一則信心十足的最終訊息，不能取代這些條件成立的證據。
重新啟動中斷的工作會帶來相關疑慮。假設一個 agent 準備報告並將其提交至另一個系統。若提交成功但確認訊息遺失，重複執行該行動可能產生重複紀錄。應用程式需要有方法區分未完成的行動與未獲確認的行動。
Microsoft 另行宣布，適用於 hosted agents 的長時間運作韌性已正式推出，客戶可自行帶來執行邏輯。其文件將儲存進度及防止重複的責任置於應用程式程式碼。這項獨立功能不應被視為新 harness 預覽版的全面保證。
資訊質素帶來另一項責任。連接過時指引的 agent 可以一致地執行指令，卻仍產出不合適的工作。考慮建立可搜尋知識庫的團隊，應將來源資料的組織及維護視為應用程式的一部分。
這種關係令知識管理與此發布相關，卻不意味著存在特定整合。基礎設施決定工作如何推進；可取得的證據則限制 agent 可以合理得出的結論。改善其中一方，並不會消除另一方的弱點。
因此，機構應在完整工作流程中分配擁有權。必須有人負責來源材料、權限、驗收準則，以及結果失敗時的修正。受管理的執行可以改變工程負擔，卻不會消除這些組織決策。
最可信的採用理由，同時指出供應商承擔的工作及客戶保留的責任。這種清晰度有助判斷服務是否整體上降低複雜性，也可防止成功的原型演變成沒有任何人全面負責的應用程式。
三項訊號將顯示受管理方案是否實現承諾
下一批有用證據應關乎服務成熟度、比較結果及客戶營運，而非額外的發布主張。
第一項訊號是 Microsoft 在未來數月如何發展 Foundry 預覽版。買家應留意更清晰的可用性、支援的配置、遷移選項及生產環境指引。更廣泛且已記錄的支援，將加強在更多應用程式中採用共同受管理基礎的理由。
最有意義的擴展，應解決目前阻礙實際部署的要求。另一種受支援配置，只有在讓機構可於其技術及業務限制內運作時才有意義。單靠更長的功能清單，較難說明某個特定應用程式是否變得可行。
若預覽版限制對客戶預定環境仍然重大，該客戶立即採用的理由便會減弱。這是針對工作負載的判斷。一項限制對研究原型可能無關緊要，對連接敏感營運系統的應用程式卻可能是決定性因素。
第二項訊號是能夠區分模型變更與執行變更的比較證據。評估應清楚說明哪些元件有所改變，以及如何衡量成功。這有助買家判斷所報告的效益來自 harness、模型，還是兩者的互動。
獨立評估將增加信心，特別是在披露失敗類別及審核要求時。着重已完成工作的一項比較，會比只着重活動的一項比較更直接地支持 Microsoft 的論點。若結果顯示對配置存在顯著依賴性，則應收窄主張可適用的範圍。
競爭發展在同一比較框架內亦很重要。Anthropic 受管理方案的變更，或其他供應商的執行方式，可改變可用替代方案。買家應針對穩定的應用程式要求比較服務，避免變化中的市場令評估演變成無止境的功能追逐。
第三項訊號是超越初始部署速度的客戶報告。有用的案例會描述持續運作、可接受的結果、修正投入，以及客戶保留的責任。若有證據顯示在結果可靠的同時維護需求較低，將加強購買共享執行層的理由。
大量自訂工作的案例則需要更審慎解讀。自訂可能反映有價值的業務專業化，亦可能反映受管理服務的缺口。了解哪個解釋適用，比單純計算客戶撰寫了多少程式碼更重要。
這些訊號亦提供實際方法，以重新檢視較早的決定。團隊今天可以合理地自行建立執行系統，稍後再採用受管理服務。另一個團隊可以由受管理基礎設施起步，並只在該安排持續符合其要求時保留它。
以貴機構熟悉的工作流程評估 Microsoft Copilot harness。訂明可接受的結果、辨識哪些操作須經批准，並記錄仍需人手修正的環節。以相同的證據及完成準則，將託管方案與現有做法作比較。納入資料來源質素、復原行為，以及調查錯誤所需的工作量。決策應緊扣團隊實際可委派的責任範圍，並隨著文件支援及客戶證據逐步累積而重新審視。Microsoft 的推出，為內部維護整個執行基礎架構提供了一個具體替代方案。下一個有用的步驟，是確立該替代方案能改善自身工作流程中的哪些部分，以及哪些證據會改變你的決定。
