作者 | Zohar Einy

譯者 | 平川

策劃 | Tina

本文最初發(fā)布于 THENEWSTACK 博客。

Milhad 為 Unsplash+ 供稿

如今，任何人都可以很容易地在本地構(gòu)建一個智能體。通過一些 LLM 調(diào)用、提示和幾個工具定義，這個智能體就能在幾分鐘內(nèi)為他們完成實(shí)際的工作。但是，當(dāng)這個智能體投入生產(chǎn)并被整個工程部門使用，涉及到真實(shí)的數(shù)據(jù)和實(shí)際的后果時，會發(fā)生什么呢？

2015 年，谷歌發(fā)表了“機(jī)器學(xué)習(xí)系統(tǒng)中的隱性技術(shù)債務(wù)”。那篇論文為機(jī)器學(xué)習(xí)工程師指明了方向，并一針見血地指出了他們所面臨的所有問題。文中分享的那張圖片也成了經(jīng)典：一個標(biāo)有“ML Code”的小方框，被龐大的基礎(chǔ)設(shè)施模塊所包圍。

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

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

我們將智能體定義為任何具有動態(tài)決策能力的進(jìn)程，它們能夠通過推理和反思自主確定工具使用和執(zhí)行路徑。決策、推理和反思需要所有輔助性的基礎(chǔ)設(shè)施。

構(gòu)建智能體很容易。但在生產(chǎn)環(huán)境中，智能體代碼只占系統(tǒng)最小的一部分。周邊的一切才是真正復(fù)雜的。

在過去的幾個月里，根據(jù)與工程領(lǐng)導(dǎo)者的對話和我們自己的經(jīng)驗，我們繪制出了圍繞智能體的七個基礎(chǔ)設(shè)施模塊。每個模塊是一類工作，都是人們構(gòu)建演示系統(tǒng)時沒有計劃在內(nèi)的。

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

讓我們逐一了解下。

集 成

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

如果不集中管理集成，那么每個團(tuán)隊都會自己設(shè)置智能體連接。

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

那將是數(shù)百個集成點(diǎn)，每個都需要單獨(dú)配置、單獨(dú)調(diào)試，并且都有自己的有效時間表。

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

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

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

現(xiàn)在，MCP 是大多數(shù)團(tuán)隊將智能體連接到工具時采用的方式。但我們不要將 MCP 與集成混淆。MCP 為智能體提供了一種標(biāo)準(zhǔn)的工具調(diào)用方式。它并不管理調(diào)用的憑證，返回數(shù)據(jù)的范圍，或者當(dāng)另一端的 API 發(fā)生變化時會發(fā)生什么。

集成方面的隱性技術(shù)債務(wù)可能像下面這樣：

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

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

• 當(dāng)一個集成升級其 API 時，每個團(tuán)隊都要分別調(diào)試其連接。

上下文湖

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

運(yùn)行時上下文：如何在智能體執(zhí)行期間向它們提供準(zhǔn)確的上下文？

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

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

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

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

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

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

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

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

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

• 上下文陳舊過時、支離破碎且無人負(fù)責(zé)。

• 公司標(biāo)準(zhǔn)存在于維基中，而智能體基于 agents.md 文件運(yùn)行。

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

智能體注冊表

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

組織結(jié)構(gòu)圖在動態(tài)變化?，F(xiàn)在不僅僅是人，還有數(shù)量為 5-10 倍的智能體。它們是由所有的人類員工在每天的工作中創(chuàng)建的。它們運(yùn)行在沒有護(hù)欄的環(huán)境中，它們可以訪問關(guān)鍵基礎(chǔ)設(shè)施，它們正在做決策。它們也分布在 Claude Code、Cursor、n8n、zapier、Notion、AWS、GCP 等工具中。

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

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

向智能體傳達(dá)指令

在實(shí)現(xiàn)了智能體的可見性之后，你還需要為它們提供相當(dāng)于員工手冊的東西：標(biāo)準(zhǔn)、技能以及期望它們?nèi)绾尾僮鞯闹噶睢?/p>

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

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

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

• 公司范圍內(nèi)適用的標(biāo)準(zhǔn)（安全編碼、提交規(guī)范）

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

• 或者針對工程師子集的團(tuán)隊級規(guī)則

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

智能體創(chuàng)建

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

現(xiàn)在，這個責(zé)任落在了平臺團(tuán)隊身上。

就像軟件目錄中的服務(wù)一樣，智能體應(yīng)該有標(biāo)準(zhǔn)化的屬性，并且應(yīng)該與公司的其他實(shí)體建立連接，比如其他智能體、團(tuán)隊、服務(wù)、部署等。

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

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

智能體創(chuàng)建應(yīng)該遵循標(biāo)準(zhǔn)模板。這并不是說人類員工創(chuàng)建智能體時應(yīng)該放慢速度。恰恰相反，與他們單獨(dú)創(chuàng)建相比，一個標(biāo)準(zhǔn)化的智能體創(chuàng)建過程，可以幫助他們更快地達(dá)成高質(zhì)量的工作。

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

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

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

• 智能體不可見

• 團(tuán)隊正在創(chuàng)建重復(fù)的智能體

• 上下文過時

• 當(dāng) CISO 要求進(jìn)行智能體審計時，卻沒有一個列表可以入手

• 沒有一個明確的將智能體提升到生產(chǎn)應(yīng)用狀態(tài)的方法

• 沒有版本控制、回滾或過渡環(huán)境

度 量

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

SRE 想知道智能體做了什么。機(jī)器學(xué)習(xí)工程師或產(chǎn)品經(jīng)理想知道它是變得更好還是更糟了。工程副總裁想知道它是否值得花錢。最終用戶想知道智能體是否根據(jù)他們的反饋進(jìn)行了學(xué)習(xí)。

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

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

這是可觀測性。

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

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

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

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

這就是評估。

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

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

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

3. 怎么知道智能體是否真的做出了業(yè)務(wù)貢獻(xiàn)？

這是業(yè)務(wù)影響。

在今年的每次財報電話會議上都會有人問：“AI 對你的業(yè)務(wù)有什么貢獻(xiàn)？”

大多數(shù)工程領(lǐng)導(dǎo)者都回答不了，最終，他們是負(fù)責(zé)度量智能體成本和 ROI 的人。

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

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

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

這是反饋循環(huán)。

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

這對于改進(jìn)智能體至關(guān)重要，比評估更重要。處于演示階段的智能體要么不收集這些信號，要么不采取相應(yīng)的行動。

在度量方面，隱性技術(shù)債務(wù)可能像下面這樣：

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

• 當(dāng)提示或模型變化時，無法衡量發(fā)生了什么

• 領(lǐng)導(dǎo)層要求 ROI，但你給不出明確的答案

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

人機(jī)回環(huán)

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

人機(jī)回環(huán)是讓你可以安全地將智能體趨近自動化的機(jī)制之一。它讓你定義檢查點(diǎn)：這個行動需要批準(zhǔn)，那個不需要，這個取決于環(huán)境。智能體自動運(yùn)行，但人類要在執(zhí)行前確認(rèn)高風(fēng)險決策。

例如，系統(tǒng)部署智能體在測試環(huán)境中可以自由運(yùn)行，但在生產(chǎn)環(huán)境中需要批準(zhǔn)。它可以在營業(yè)時間內(nèi)完全自主，但在凌晨 3 點(diǎn)則需要人類參與。規(guī)則是有條件的，因智能體、行動、環(huán)境和團(tuán)隊的不同而不同。

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

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

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

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

人機(jī)回環(huán)中的隱性技術(shù)債務(wù)可能像下面這樣：

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

• 一些智能體在不需要審批的情況下運(yùn)行，其他智能體則需要經(jīng)過太多的批準(zhǔn)

• 通過電子郵件、Slack 和自定義 UI 進(jìn)行審批的多個審批系統(tǒng)，相互之間不兼容

• 沒有一個共享工作區(qū)，讓團(tuán)隊可以看到他們的智能體在做什么，并在必要時進(jìn)行干預(yù)

治 理

當(dāng)人類工程師需要訪問生產(chǎn)數(shù)據(jù)庫時，需要經(jīng)過一個流程。他們提交請求，有人批準(zhǔn)，然后訪問范圍被限定和記錄。這個過程可能需要一個小時或一天，但誰有權(quán)訪問什么以及誰做了什么，都有審計日志記錄。

當(dāng)工程師在本地創(chuàng)建智能體時，它在運(yùn)行時使用的通常是其創(chuàng)建者設(shè)置的憑據(jù)：他們的 API 令牌、他們的服務(wù)賬戶、他們的云權(quán)限。這個范圍很有可能沒人審查。

智能體的治理規(guī)則要具體：

• “回滾服務(wù)，但只有在出現(xiàn)高嚴(yán)重性事件時?！?/p>

• “部署到生產(chǎn)環(huán)境總是需要手動批準(zhǔn)，不管是什么智能體觸發(fā)的。”

• “從外部系統(tǒng)拉取數(shù)據(jù)的 RCA 報告應(yīng)該只對那個服務(wù)的所有者可見。”

平臺團(tuán)隊需要在一個地方集中定義這些規(guī)則并應(yīng)用于所有智能體。

治理的另一面是執(zhí)行。假設(shè)你發(fā)現(xiàn)了一個內(nèi)部 API 的漏洞，需要立即阻止所有智能體調(diào)用它。你能嗎？一個安全工程師應(yīng)該能夠在一個地方禁用一個工具，并讓它自動在所有智能體中被禁用。大多數(shù)公司并不具備這種能力。

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

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

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

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

• 一個不應(yīng)該在生產(chǎn)環(huán)境中運(yùn)行的智能體訪問了生產(chǎn)數(shù)據(jù)

• 一個 RCA 智能體將敏感的服務(wù)數(shù)據(jù)發(fā)布到了共享頻道

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

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

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

編 排

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

節(jié)點(diǎn)之間有什么出了問題

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

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

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

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

與傳統(tǒng)工作流編排的不同之處

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

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

智能體之間也沒有契約。服務(wù) API 有模式和通過版本進(jìn)行管理的端點(diǎn)。兩個智能體相互傳遞信息時使用的是提示和自然語言。“接口”是模糊的。一個智能體的模型更新或提示更改可能會改變其輸出，從而對鏈路中的下一個智能體造成破壞。

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

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

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

誰擁有工作流？

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

當(dāng)一個智能體修改服務(wù)，并且出現(xiàn)問題時，誰負(fù)責(zé)？是智能體的所有者還是服務(wù)的所有者？當(dāng)一個工作流程跨越三個團(tuán)隊時，哪個團(tuán)隊對結(jié)果負(fù)責(zé)？當(dāng)鏈路中的一個步驟失敗時，是失敗的智能體負(fù)責(zé)去重試，還是工作流負(fù)責(zé)重新規(guī)劃路線？

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

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

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

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

• 一個工作流跨三個團(tuán)隊，但沒有團(tuán)隊對結(jié)果負(fù)責(zé)

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

當(dāng)債務(wù)來襲

這種隱性技術(shù)債務(wù)在特定的時候被觸發(fā)會變得讓人頭疼。

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

當(dāng)多個團(tuán)隊獨(dú)立運(yùn)行智能體時，債務(wù)積累會更快。智能體注冊、度量和人機(jī)回環(huán)等需求會同時出現(xiàn)。在這個階段，團(tuán)隊大約 50% 的精力將用于構(gòu)建周邊基礎(chǔ)設(shè)施。

在達(dá)到生產(chǎn)規(guī)模（智能體嵌入到工程組織的大部分工作流）時，治理和編排成為優(yōu)先事項。有些公司看到了這一點(diǎn)。一位架構(gòu)師告訴我，“根據(jù)經(jīng)驗，我們知道混亂將在所難免。我們將從第一天起就設(shè)法避免它。”有些人則是吃一塹長一智：一位平臺工程副總裁發(fā)現(xiàn)，各團(tuán)隊在各自為政地開發(fā)相同的智能體程序，待系統(tǒng)變得雜亂無章后，才不得不回過頭來建立治理機(jī)制。兩者最終都會構(gòu)建相同的基礎(chǔ)設(shè)施，但其中一方卻要為此付出雙倍的代價。

這種情況以前在微服務(wù)中出現(xiàn)過

這似乎和微服務(wù)的發(fā)展歷程類似。每個團(tuán)隊選擇自己的技術(shù)，做自己的基礎(chǔ)設(shè)施，最終有人不得不站出來創(chuàng)建標(biāo)準(zhǔn)。如今，圍繞智能體程序，又一場平臺工程的變革正在上演。

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

有一個 DevEx 團(tuán)隊向我描述了他們的新角色：“我們不會是設(shè)計和創(chuàng)建智能體的人。我們所做的是確保開發(fā)人員知道如何使用它們，能夠適當(dāng)?shù)亟换ィ椭鄨F(tuán)隊創(chuàng)建自己的智能體。”

我們該做些什么

從可見性開始。審計 GitHub 組織，查找與 AI 相關(guān)的工作流和操作。檢查你的團(tuán)隊在 Claude、OpenAI 或 Bedrock 上有多少活躍的 API 令牌。查看你的工作流工具，看看是否有任何帶有 AI 節(jié)點(diǎn)的組件。目標(biāo)不是創(chuàng)建一個完美的清單，而是做一個初步統(tǒng)計。

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

還有集中化與民主化的問題。平臺團(tuán)隊?wèi)?yīng)該構(gòu)建一切，然后開發(fā)人員消費(fèi)嗎？還是說平臺團(tuán)隊?wèi)?yīng)該提供護(hù)欄，而由各團(tuán)隊構(gòu)建自己的智能體？這兩種模式都存在。這可能取決于你的企業(yè)文化能容忍多少管控。

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

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

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。