智能體工程的隱形技術(shù)債：10分鐘造出一個(gè) Agent，公司卻要為它養(yǎng)一個(gè)平臺(tái)團(tuán)隊(duì)

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

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

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

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

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

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

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

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

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

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

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

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

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

治 理

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

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

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

• “回滾服務(wù)，但只有在出現(xiàn)高嚴(yán)重性事件時(shí)。”

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

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

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

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

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

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

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

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

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

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

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

• 無(wú)法從一個(gè)地方禁止所有智能體使用一個(gè)工具

• 沒(méi)有智能體做了什么或?yàn)槭裁醋龅膶徲?jì)跟蹤信息

編 排

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

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

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

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

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

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

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

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

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

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

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

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

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

誰(shuí)擁有工作流？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們?cè)撟鲂┦裁?/p>

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

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

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

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

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

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

會(huì)議推薦

世界模型的下一個(gè)突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過(guò)？研發(fā)體系不重構(gòu)，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來(lái)：世界模型與多模態(tài)智能突破、Agent 架構(gòu)與工程化實(shí)踐、Agent 安全與可信治理、企業(yè)級(jí)研發(fā)體系重構(gòu)。14 個(gè)專題全面開(kāi)放征稿。

誠(chéng)摯邀請(qǐng)你登臺(tái)分享實(shí)戰(zhàn)經(jīng)驗(yàn)。AICon 2026，期待與你同行。

今日薦文

你也「在看」嗎？