智能體工程的隱形技術債：10分鐘造出一個 Agent，公司卻要為它養一個平臺團隊

作者 | Zohar Einy

譯者 | 平川

策劃 | Tina

本文最初發布于 THENEWSTACK 博客。

Milhad 為 Unsplash+ 供稿

如今，任何人都可以很容易地在本地構建一個智能體。通過一些 LLM 調用、提示和幾個工具定義，這個智能體就能在幾分鐘內為他們完成實際的工作。但是，當這個智能體投入生產并被整個工程部門使用，涉及到真實的數據和實際的后果時，會發生什么呢？

2015 年，谷歌發表了“機器學習系統中的隱性技術債務”。那篇論文為機器學習工程師指明了方向，并一針見血地指出了他們所面臨的所有問題。文中分享的那張圖片也成了經典：一個標有“ML Code”的小方框，被龐大的基礎設施模塊所包圍。

對于智能體，我們看到了相同的模式。智能體只是畫面的一小部分，我們想要命名圍繞它們的所有基礎設施。

智能體工程系統特別擅長積累技術債務。它們有傳統軟件的所有維護問題，同時還要加上一些智能體才有的問題。幾乎每個員工每天都在創建新的智能體。很快，你擁有的智能體將比員工還多。

我們將智能體定義為任何具有動態決策能力的進程，它們能夠通過推理和反思自主確定工具使用和執行路徑。決策、推理和反思需要所有輔助性的基礎設施。

構建智能體很容易。但在生產環境中，智能體代碼只占系統最小的一部分。周邊的一切才是真正復雜的。

在過去的幾個月里，根據與工程領導者的對話和我們自己的經驗，我們繪制出了圍繞智能體的七個基礎設施模塊。每個模塊是一類工作，都是人們構建演示系統時沒有計劃在內的。

如果你做過傳統的工程項目，那么這些模塊中有一些會看起來很熟悉：可觀測性、集成和治理。其他模塊是智能體項目獨有的，例如人機回環、非確定性系統評估和智能體注冊表。

讓我們逐一了解下。

集 成

智能體需要連接到你實際的系統：CI/CD、云提供商、事件工具、可觀測性平臺、代碼庫、密鑰管理器等。

如果不集中管理集成，那么每個團隊都會自己設置智能體連接。

想象一下，一個有 30 個團隊、200 名工程師的工程組織，每個團隊都有多個智能體。每位工程師都為編碼智能體生成自己的 GitLab PAT，為數據智能體生成 Snowflake 憑據，為部署智能體生成 Kubernetes 服務賬戶，為事件智能體生成監控令牌。

那將是數百個集成點，每個都需要單獨配置、單獨調試，并且都有自己的有效時間表。

當每個開發人員都設置自己的憑據時，每個智能體使用的 Token 不同看到的數據就不同。一個開發人員的 GitLab PAT 可以訪問所有代碼庫，其他人的范圍則限定在他們自己團隊。智能體類型相同，但每一個都有一個完全不同的組織視圖。

或者，當 GitLab 的 API 有重大更改時會發生什么？每個獨立創建連接的團隊都要調試相同的問題（或向平臺團隊提交工單）。三個團隊在周一解決了這個問題，到周三又有兩個團隊。有個團隊過了一周都沒有注意到，因為他們的智能體只在事件期間運行。

通過這些集成傳遞的內容也很重要。當三個團隊通過不同的路徑連接到相同的數據源時，對于同一個問題，他們的智能體會得出不同的答案。如果一個團隊的集成拉取了 30 天的部署歷史，而另一個團隊的集成顯示了過去 3 年的所有內容，則他們的輸出就會不同。

現在，MCP 是大多數團隊將智能體連接到工具時采用的方式。但我們不要將 MCP 與集成混淆。MCP 為智能體提供了一種標準的工具調用方式。它并不管理調用的憑證，返回數據的范圍，或者當另一端的 API 發生變化時會發生什么。

集成方面的隱性技術債務可能像下面這樣：

• 一個集成的身份驗證令牌在周五晚上到期，一個事件智能體默默地停止了工作，而直到周一都沒有人注意到這個情況。

• 五個團隊各自維護自己的 GitLab 連接，權限和范圍各不相同，都不知道其他人的存在。

• 當一個集成升級其 API 時，每個團隊都要分別調試其連接。

上下文湖

智能體的好壞取決于它們可以引用和使用的上下文。它們需要兩種上下文。

運行時上下文：如何在智能體執行期間向它們提供準確的上下文？

運行時上下文是智能體在特定執行期間需要的實時數據，例如有關服務的信息，誰擁有這些信息，以及最近部署了什么內容。這與人類在編碼或解決事件時使用的數據相同，但于智能體而言更容易獲取。

想象一下，一個編碼智能體接手了一個工單，為一個服務添加重試機制。它需要知道：服務使用什么語言和框架，這個組織中的其他服務如何處理重試，它調用的下游服務歸誰所有，以及超時設置最近是否有過更改。

有一些團隊在 Markdown 文件中管理他們的運行時上下文：agents.md，.cursorrules 和技能文件。

對于靜態指令，像如何格式化提交或使用哪個 Linter，使用 Markdown 文件就很好。但運行時上下文是不斷變化的：服務所有權轉移；依賴項被添加；配置值更新；每小時都有部署。一個基于.md 文件運行的智能體說“checkout-service 歸 Payments 團隊所有”，它不知道這個服務的所有權在上周二轉移到了 Commerce 團隊。文件在編寫時是準確的，等到智能體讀取的時候，可能就不準確了。

決策痕跡：如何幫助智能體從自己過去的工作或其他智能體的工作中學習？

決策痕跡是之前做過的事情（由人類或智能體完成），是關于為什么做出決策，以及之后發生了什么的歷史。沒有這個歷史作為參考，每次智能體都是從零開始運行。想象一下，智能體打開一個 PR 來修復一個不穩定的測試。它不知道上周另一個智能體嘗試了相同的修復，這個 PR 因為會破壞下游契約而被拒絕，而團隊已經決定完全棄用該測試。因此，它重新打開了相同的 PR。沒有決策痕跡，智能體會重復人類（或智能體）已經解決的錯誤。

一個解決過 50 個事件的智能體已經看到了新智能體沒有看到過的模式，比如哪些修復有效，哪些會導致回歸，以及哪些服務在部署后變得脆弱。沒有痕跡，這些知識會在每次運行后消失。當多個智能體在同一個系統上操作時，它們無法看到彼此的歷史。

LLM 提供商開始通過可以跨團隊共享的 memory.md 文件來解決這個問題。但當你有幾十智能體在運行時，債務還是會出現。你需要找到一種可靠的方法將該記憶（或只是它正確的部分）提供給特定的智能體。

在上下文湖中，隱性技術債務可能像下面這樣：

• 上下文陳舊過時、支離破碎且無人負責。

• 公司標準存在于維基中，而智能體基于 agents.md 文件運行。

• 智能體沒有學習其他智能體為什么以及如何解決一個問題，又不了解它們犯過的錯誤。

智能體注冊表

讓我們了解存在哪些智能體。

組織結構圖在動態變化�，F在不僅僅是人，還有數量為 5-10 倍的智能體。它們是由所有的人類員工在每天的工作中創建的。它們運行在沒有護欄的環境中，它們可以訪問關鍵基礎設施，它們正在做決策。它們也分布在 Claude Code、Cursor、n8n、zapier、Notion、AWS、GCP 等工具中。

典型的模式是這樣的：一個工程師構建了一個分診智能體，其團隊開始在它的幫助下處理事件。另一個團隊構建了自己的版本，因為它不知道第一個智能體的存在。第三個團隊也構建了類似的東西，但是連接到不同的工具，有不同的權限。

在一個有 20 或 30 個工程團隊的公司里，你很快就會遇到責任重疊、行為沖突以及依賴項不可見的智能體。在智能體可以在團隊之間共享之前，你首先需要知道它們存在。

向智能體傳達指令

在實現了智能體的可見性之后，你還需要為它們提供相當于員工手冊的東西：標準、技能以及期望它們如何操作的指令。

如今，工程師們都是獨立地為他們的智能體創建技能文件。問題是，當它們分散在不同的存儲庫中，沒有一個集中的視圖時，團隊最終會創建出重復或不準確的技能。他們會經常與平臺分發的上下文相矛盾。平臺團隊比個別團隊更有洞察力，他們更知道在技能文件中寫什么。

那么，該如何將一致但個性化的編碼規則、命令、技能和鉤子傳遞給正確的智能體呢？

這些信息甚至可能需要多個層次：

• 公司范圍內適用的標準（安全編碼、提交規范）

• 特定于存儲庫的指令（“在這個存儲庫中，事件是這樣創建的”）

• 或者針對工程師子集的團隊級規則

你需要找到一種方法，將這些信息可靠地傳遞給成千上萬的智能體，確保正確的指令能夠到達正確的智能體。

智能體創建

假設你已經可以看到現有的大多數智能體，并向它們傳遞了指令。下一個問題是如何控制智能體的新建過程，而不拖慢團隊的速度？

現在，這個責任落在了平臺團隊身上。

就像軟件目錄中的服務一樣，智能體應該有標準化的屬性，并且應該與公司的其他實體建立連接，比如其他智能體、團隊、服務、部署等。

如果沒有模板，你就會遇到你剛剛解決過的問題。一個工程師啟動了一個智能體，沒有所有者，沒有生命周期狀態，也沒有它所操作的服務的連接。它為他們工作，但其他人都不知道它的存在。六個月后，有人發現它在生產環境中運行，使用了過期的 Token，卻沒有辦法聯系到構建它的人。

一個工程師啟動了一個智能體，沒有所有者，沒有生命周期狀態，也沒有與它操作的服務的連接。這對他們來說有效。其他人都不知道它的存在。

智能體創建應該遵循標準模板。這并不是說人類員工創建智能體時應該放慢速度。恰恰相反，與他們單獨創建相比，一個標準化的智能體創建過程，可以幫助他們更快地達成高質量的工作。

應該允許工程師從他們的工作站創建智能體。如果他們在 Cursor 中工作并且需要啟動一個智能體，那么他們應該能夠從那里做到這一點，而不是從其他地方。也就是說，你作為平臺工程師的工作，是確保在任何地方創建的智能體都遵循你的創建過程。

模板不會限制智能體做什么。它只是確保每個智能體都具備基本要素：所有者、描述、它使用的工具、它連接的服務以及生命周期狀態。這樣，從第一天起就可以對它們進行管理，而不是后續再去費力地追查。

在智能體注冊方面，隱性技術債務可能像下面這樣：

• 智能體不可見

• 團隊正在創建重復的智能體

• 上下文過時

• 當 CISO 要求進行智能體審計時，卻沒有一個列表可以入手

• 沒有一個明確的將智能體提升到生產應用狀態的方法

• 沒有版本控制、回滾或過渡環境

度 量

你怎么知道你的智能體是否在工作？這取決于誰在問。

SRE 想知道智能體做了什么。機器學習工程師或產品經理想知道它是變得更好還是更糟了。工程副總裁想知道它是否值得花錢。最終用戶想知道智能體是否根據他們的反饋進行了學習。

所以，雖然每個人都想對智能體做一些度量，但他們想要度量的東西并不一樣。

1. 怎么知道智能體在做什么？

這是可觀測性。

事件、跟蹤信息和日志記錄了智能體所采取的行動、訪問的數據，以及它是否仍在正確地運行。工程團隊了解傳統系統的可觀測性，但對于智能體，觀測面更廣。

假設你有一個智能體，它可以自動處理 Jira 工單。當它收到一個 Jira 工單時，它會讀取服務目錄，找出相關的存儲庫，通過 GitHub 集成拉取最近的提交，使用編碼智能體生成一個修復，然后回到 GitHub 打開一個 PR，并請求它從軟件目錄中找到的服務所有者進行審查。如果修復對某些東西造成了破壞，哪個步驟出了問題？它拉取了錯誤的存儲庫嗎？誤讀了所有權？生成了糟糕的代碼？

如果你不能完整追蹤整個鏈條中的所有動作，那問題排查的難度會大大增加。

2. 當提示、技能、工具和模型發生變化時，怎么知道智能體是否變好了還是變糟了？

這就是評估。

在標準軟件工程中，你可以編寫一個單元測試，然后判斷是否輸出了一個確切的字符串。在智能體工程中，每個響應都不同，你需要采用一個不同的方法。

通過一個簡單的問題進行評估：在你改變一些東西（比如提示或模型）之后，智能體是否仍然表現得很好？

如果沒有一種方法來跟蹤這一點，更改就會在未經測試的情況下發布，輸出質量可能會悄無聲息地降低。就像用 Opus 替換 Sonnet，你的 PR 審查智能體開始批準它以前標記過的東西。

3. 怎么知道智能體是否真的做出了業務貢獻？

這是業務影響。

在今年的每次財報電話會議上都會有人問：“AI 對你的業務有什么貢獻？”

大多數工程領導者都回答不了，最終，他們是負責度量智能體成本和 ROI 的人。

在整個過程中，追蹤支出是相對比較簡單的一部分工作。你可以追蹤 Token 使用情況、API 調用次數以及每個智能體、每個團隊的計算成本。

投資回報率（ROI）則比較難以衡量。智能體解決了多少工單？它節省了多少工程時間？它是否真的減少了平均故障修復時間（MTTR），還是只是轉移了工作量？這些數字更難以收集，也更難以讓人信服。如果你只能做成本方面的展示而不能清晰地展示 ROI，那么這會是一個糟糕的對話。

4. 如何向智能體反饋它們的工作？

這是反饋循環。

當智能體生成一個 PR、解決一個工單或編寫一個根本原因分析（RCA）報告時，負責審查輸出結果的人類是接受了輸出還是進行了更正？這通常用贊成或不贊成來管理，但有時候，人類的回應本身就是反饋（比如“不，再試一次，但改為 X”）。

這對于改進智能體至關重要，比評估更重要。處于演示階段的智能體要么不收集這些信號，要么不采取相應的行動。

在度量方面，隱性技術債務可能像下面這樣：

• 不知道智能體性能是隨著時間提高還是下降，以及與什么相比

• 當提示或模型變化時，無法衡量發生了什么

• 領導層要求 ROI，但你給不出明確的答案

• 未能收集使用智能體的人類的反饋

人機回環

在完全手動和完全自動化之間有一個區域。在一端，人類做所有事情。在另一端，智能體不做詢問就采取行動。大多數有用的智能體處于中間的某個地方，它們的確切位置取決于行動、環境和風險。

人機回環是讓你可以安全地將智能體趨近自動化的機制之一。它讓你定義檢查點：這個行動需要批準，那個不需要，這個取決于環境。智能體自動運行，但人類要在執行前確認高風險決策。

例如，系統部署智能體在測試環境中可以自由運行，但在生產環境中需要批準。它可以在營業時間內完全自主，但在凌晨 3 點則需要人類參與。規則是有條件的，因智能體、行動、環境和團隊的不同而不同。

當你的演示中有一個智能體時，你可以將批準檢查點硬編碼為一個 if 語句，部署前由它在 Slack 上發出通知。當 20 個團隊中有 100 個智能體時，硬編碼的批準邏輯將無法擴展。每個團隊都實現了自己的版本。一個團隊的智能體在沒有經過批準的情況下回滾生產。另一個團隊的智能體需要三次批準才能做同樣的事。沒有一個集中式的定義，沒有人知道哪些智能體可以獨立行動，哪些不能。

然后是對審批本身的編排。誰會收到通知？通過什么渠道？如果沒人回應，超時時間是多少？如果審批人在度假怎么辦？如果一個智能體的審批通過 Slack，另一個通過電子郵件，第三個通過自定義 UI，那么你現在就有三個審批系統需要維護。圍繞審批的邏輯變成了獨立于智能體存在的主要技術債務。

如果我們擴大視野，人機回環也關乎了解智能體內部發生了什么。隨著工程師進入更偏管理性的角色，他們將需要一個控制平面來查看正在進行的工作，啟動智能體的工作，識別哪些智能體需要關注，并在需要時采取行動。

這很重要，因為人機回環是你大規模應用變化所依賴的方法（如今的公司都是要么改變，要么消亡）。為了在新工作中取得成功，工程師們需要能夠看到智能體的工作，就像過去可以看到他們的代碼如何工作一樣。如果一個團隊能夠觀察智能體如何處理其前十個部署（可以看到每一步，審查每個決策，并在需要時進行干預），他們便會信任那個智能體；如果不能，就不會。

人機回環中的隱性技術債務可能像下面這樣：

• 硬編碼的審批代碼無法從一個集中的地方進行更改

• 一些智能體在不需要審批的情況下運行，其他智能體則需要經過太多的批準

• 通過電子郵件、Slack 和自定義 UI 進行審批的多個審批系統，相互之間不兼容

• 沒有一個共享工作區，讓團隊可以看到他們的智能體在做什么，并在必要時進行干預

治 理

當人類工程師需要訪問生產數據庫時，需要經過一個流程。他們提交請求，有人批準，然后訪問范圍被限定和記錄。這個過程可能需要一個小時或一天，但誰有權訪問什么以及誰做了什么，都有審計日志記錄。

當工程師在本地創建智能體時，它在運行時使用的通常是其創建者設置的憑據：他們的 API 令牌、他們的服務賬戶、他們的云權限。這個范圍很有可能沒人審查。

智能體的治理規則要具體：

• “回滾服務，但只有在出現高嚴重性事件時。”

• “部署到生產環境總是需要手動批準，不管是什么智能體觸發的�！�

• “從外部系統拉取數據的 RCA 報告應該只對那個服務的所有者可見�！�

平臺團隊需要在一個地方集中定義這些規則并應用于所有智能體。

治理的另一面是執行。假設你發現了一個內部 API 的漏洞，需要立即阻止所有智能體調用它。你能嗎？一個安全工程師應該能夠在一個地方禁用一個工具，并讓它自動在所有智能體中被禁用。大多數公司并不具備這種能力。

你不能總是從一開始就把訪問權限搞得嚴絲合縫。事情可能會出錯，一旦出錯，你就需要知道發生了什么：哪個智能體采取了行動，它訪問了什么數據，使用了什么憑證，以及誰觸發了它。如果是在本地創建的話，大多數智能體設置都不會產生這樣的審計跟蹤記錄。在本地運行的智能體會繼承其創建者的憑證，它所采取的每一項行動看起來都是工程師的個人工作。如果三個智能體共享一個服務賬戶，你就無法判斷是哪個智能體發起的調用。如果一個代智能體在修改生產配置之前需要經過另外兩個智能體，那么審計日志可能會只顯示最終的寫入操作，而不顯示推理、上下文或導致這一行為的決策鏈。

治理的另一個方面是成本治理。智能體往往會繼續工作，而不管它們累積了多少成本。當工程師們在本地創建智能體時，他們可能不會考慮設置成本限制。

一個陷入重試循環或循環推理的智能體會持續消耗 Token 達數小時之久，直到有人手動終止它，或者直到從月度賬單上看到了因此造成的損失。大多數團隊都可以告訴你他們的 LLM 總支出，但幾乎沒有哪個團隊能夠按智能體、團隊或用例進行成本分解。而且，團隊也應該能夠很容易地看到他們的成本狀況。因為當領導層詢問智能體的運行成本時，工程部門需要能夠給出一個答案。

在智能體治理方面，隱性技術債務可能像下面這樣：

• 一個不應該在生產環境中運行的智能體訪問了生產數據

• 一個 RCA 智能體將敏感的服務數據發布到了共享頻道

• 一個智能體在公共論壇發布 PII（Personal Identifiable Information）

• 無法從一個地方禁止所有智能體使用一個工具

• 沒有智能體做了什么或為什么做的審計跟蹤信息

編 排

大多數智能體工作流不僅僅涉及智能體。它們混合了智能體、工具和人。債務不在于個別步驟，而在于發生在它們之間的事情：路由、故障處理和所有權。

節點之間有什么出了問題

以上述事件響應工作流為例。一個警報被觸發，一個分診智能體接手調查，并確定根本原因是部署問題。它把事件移交給一個部署智能體，后者回滾所做的更改。然后由一個驗證智能體檢查修復是否有效。

想象一下，分診智能體出錯了。真正的原因是數據庫超時，而不是糟糕的部署。部署被不必要地回滾，而數據庫問題仍然存在，警報繼續被觸發。最終，工程師介入進來，從頭開始調試，不過現在，他們還得處理不應該發生的回滾。這次故障并非悄無聲息。工作流自信滿滿地執行了錯誤的操作，而無人能查明錯誤決策究竟是在哪里做出的。

實踐中的編排債務可能就是這個樣子。不一定是工作流停止，而是做了錯誤的事情并且難以追蹤。

你后來新增的每個問題類型，比如安全事件、配置漂移或依賴關系錯誤，都會使路由更難測試和解釋。這些更改本身都不難。但當沒有人能決定它們如何連接時，它們每次的連接方式都會有所不同。

與傳統工作流編排的不同之處

工作流編排并不新鮮。多年來，團隊一直在 CI/CD 管道、Airflow 和 Step Functions 中將多個步驟串聯在一起。那為什么智能體編排是一個不一樣的問題呢？

傳統工作流是確定性的。步驟 A 產生已知的輸出，步驟 B 消耗它。你可以測試每條路徑，因為你知道每條路徑。智能體工作流在鏈路中引入了以前沒有的非確定性。當你用一個可以進行問題推理的智能體替換運行手冊時，下游每個步驟都變得不可預測。你不能測試每條路徑，因為你不知道每條路徑。

智能體之間也沒有契約。服務 API 有模式和通過版本進行管理的端點。兩個智能體相互傳遞信息時使用的是提示和自然語言�！敖涌凇笔悄：摹Ｒ粋�智能體的模型更新或提示更改可能會改變其輸出，從而對鏈路中的下一個智能體造成破壞。

舉例來說，部署管道應該是完全確定性的。觸發器被觸發，系統識別出問題嚴重程度，將內容部署到預發布環境，經人工審批后，再部署到生產環境，最后由驗證智能體檢查系統狀態。這些步驟是預先定義好的，順序是固定的，而且風險很高，因此你需要采用這種方式。

本質上，事件響應工作流是非確定性的。根本原因可能是糟糕的部署、數據庫問題、配置錯誤或沒有人見過的東西。智能體必須調查并決定接下來會發生什么。

大多數工程團隊都需要這兩種工作流。問題在于沒有一個通用的規則來決定何時使用哪一種。一個團隊會將所有分診結果直接發送給編碼智能體；另一個團隊則要求在進行任何自動化修復之前必須經過人工審核。這兩種做法原本各自為政，直到某次事件需要跨團隊協作時，兩種方法才發生了沖突。

誰擁有工作流？

即使每個智能體都有一個所有者，那也是不夠的。編排本身還需要一個所有者。

當一個智能體修改服務，并且出現問題時，誰負責？是智能體的所有者還是服務的所有者？當一個工作流程跨越三個團隊時，哪個團隊對結果負責？當鏈路中的一個步驟失敗時，是失敗的智能體負責去重試，還是工作流負責重新規劃路線？

這些都不是單純的理論問題。凌晨 2 點，當一個由智能體驅動的工作流走錯了方向，三個團隊在會議室里試圖弄清楚，問題是誰的智能體在做什么操作時出現的。單個步驟的故障很容易排查。但要找出三步之前哪個決策導致工作流走上了錯誤的路徑——這需要一種追蹤機制，而大多數組織尚未建立這種機制。

在智能體編排方面，隱性技術債務可能像下面這樣：

• 工作流中的一個智能體中途失敗，直到下游影響顯現出來才有人發現

• 沒有辦法從一個跨智能體的決策追蹤到原始觸發器

• 一個工作流跨三個團隊，但沒有團隊對結果負責

• 一個智能體中的模型或提示更改悄無聲息地破壞了鏈路下游的一個智能體

當債務來襲

這種隱性技術債務在特定的時候被觸發會變得讓人頭疼。

在探索階段，無所謂債務。一個工程師，一個智能體，很有效。然而，當一個團隊開始真正使用智能體時，集成和上下文會是首先出問題的地方。一個智能體訪問了它不應該看到的客戶數據，因為沒有人限制訪問憑證。一個智能體對服務所有者做出了猜測，因為它沒有相關的上下文。

當多個團隊獨立運行智能體時，債務積累會更快。智能體注冊、度量和人機回環等需求會同時出現。在這個階段，團隊大約 50% 的精力將用于構建周邊基礎設施。

在達到生產規模（智能體嵌入到工程組織的大部分工作流）時，治理和編排成為優先事項。有些公司看到了這一點。一位架構師告訴我，“根據經驗，我們知道混亂將在所難免。我們將從第一天起就設法避免它�！庇行┤藙t是吃一塹長一智：一位平臺工程副總裁發現，各團隊在各自為政地開發相同的智能體程序，待系統變得雜亂無章后，才不得不回過頭來建立治理機制。兩者最終都會構建相同的基礎設施，但其中一方卻要為此付出雙倍的代價。

這種情況以前在微服務中出現過

這似乎和微服務的發展歷程類似。每個團隊選擇自己的技術，做自己的基礎設施，最終有人不得不站出來創建標準。如今，圍繞智能體程序，又一場平臺工程的變革正在上演。

平臺工程曾經是一個以速度為導向的舉措：自助服務、減少工單量以及為新服務搭建框架。對于智能體，速度仍然是重點，平臺團隊正在疲于追趕。工程師們不會等待。他們會在需要時隨時在 Cursor 或 Claude Code 中啟動新的智能體。平臺團隊的第一項工作是確定已經存在哪些智能體，并將它們置于控制之下。只有這樣，他們才能做他們一直在做的事：使其他人能夠更快、更安全、更容易地創建和使用它們。

有一個 DevEx 團隊向我描述了他們的新角色：“我們不會是設計和創建智能體的人。我們所做的是確保開發人員知道如何使用它們，能夠適當地交互，并幫助更多團隊創建自己的智能體�！�

我們該做些什么

從可見性開始。審計 GitHub 組織，查找與 AI 相關的工作流和操作。檢查你的團隊在 Claude、OpenAI 或 Bedrock 上有多少活躍的 API 令牌。查看你的工作流工具，看看是否有任何帶有 AI 節點的組件。目標不是創建一個完美的清單，而是做一個初步統計。

更棘手的問題在于如何就“什么是智能體”達成共識。GitHub Actions 自動化 是智能體嗎？Claude Code 的定時任務是智能體嗎？包含 AI 節點的 n8n 工作流是智能體嗎？在對它們進行分類之前，你需要先制定一個可行的定義。這個定義不必完美無缺，但你的組織必須就此達成一致。

還有集中化與民主化的問題。平臺團隊應該構建一切，然后開發人員消費嗎？還是說平臺團隊應該提供護欄，而由各團隊構建自己的智能體？這兩種模式都存在。這可能取決于你的企業文化能容忍多少管控。

你現在就可以構建這個基礎設施，或者等智能體泄露客戶數據、一夜之間燒掉 300 美元的 Token，或者悄無聲息地回滾沒有人要求它處理的生產服務之后再構建它。無論如何你都會構建，唯一的問題是在痛苦之前構建，還是在痛苦之后。

https://thenewstack.io/hidden-agentic-technical-debt/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。