連Claude Code都搞不定的巨型代碼庫，我們靠一個“自愈循環”給盤活了

編譯｜宇琪

策劃 | Tina

想象一下，你手里有幾百個跑在舊架構上的業務指標，每個指標背后都有一堆 5 到 10 年前寫的、文檔不全、寫代碼的人早已離職的遺留代碼。你知道必須把它們遷移到新平臺，但過去每一次嘗試都像在翻一座山——幾百個 Jira 工單、幾百個工程師周、工期從季度到年，而且項目走到半路發現走不通的情況比比皆是。怎么辦？

日前，ServiceTitan 首席 AI 工程師 David Stein 在 QCon 的分享中，給出了一個反常識的解法：處理大規模的遺留代碼問題，你不需要讓 AI 變得多聰明，只需要把任務分解到它能獨立完成并驗證的粒度，然后用一條自動化“組裝線”，像玩游戲管理“旅鼠”一樣等待驗收。實際結果顯示，85% 的遷移工作能夠由 AI 自主完成，剩余 15% 的復雜案例才需要人類工程師介入，整個項目周期從幾個季度壓縮到幾周。本文基于該分享整理，經 InfoQ 編輯。

核心觀點如下：

• 作為高級工程師或架構師，我們每天都在做這件事：把一個大問題拆解成可執行的子任務。但真正的新變化是：我們可以把時間線反轉過來。

• 當你用 agent 來加速執行大型遷移項目時，驗證器變得至關重要。尤其是在你需要短時間內并行跑完大量遷移任務時，你必須知道每一步都運行良好，否則你會很快偏離軌道。

• 你只需要給 Cursor 一個非常簡單的事情去做，把復雜性盡可能隱藏在驗證步驟和工具背后，確保它擁有解決問題所需的所有上下文。

• 擁有能寫代碼的 Agent 所帶來的巨大變革之一——它不只是讓單個任務跑得更快，而是讓你能以前所未有的速度完成那些曾經不可能的任務，從而去嘗試新東西，去做那些你原本不會去做的事。

被忽視行業的 AI 落地實錄

今天我想和大家聊聊軟件工程里每個人最愛的話題——代碼遷移。遷移就是那些大家都知道必須做的事：把一堆遺留代碼從老系統搬到某個好得多、快得多、強得多的新系統上。通常，這類項目會規劃數月、一個季度、甚至一年。我想講講在 ServiceTitan，我們如何用 AI 徹底改變這件事的玩法，讓我們能夠以前所未有的速度進行遷移，以及這對我們意味著什么。

先給不熟悉 ServiceTitan 的朋友一點背景知識。ServiceTitan 是為承包商和技工行業打造的技術平臺，覆蓋住宅、商業、建筑服務、施工、電工、管道、暖通空調、屋頂、車庫門……我們為之提供端到端的技術平臺。技工行業是一個一個長期被忽視的行業，大量工作還停留在紙筆和 Excel 表格的階段，迫切需要遷移到更高效、更數字化的方式上來，而 ServiceTitan 正在引領這場變革。

現在人人都在談 AI 用例，在整個行業中，我們看到很多用例已經近乎噱頭，就是各種人展示 AI 能做什么。能真正聚焦于這些接地氣、關乎核心服務的 AI 場景，真的非常棒。這包括工作價值預測，以便安排承包商，知道該把哪些人分配到哪些車輛，哪天派往哪些住宅和樓宇，從而實現效率和營收的優化，這是我們的客戶喜歡我們產品的一個非常重要的功能。還有其他場景，比如能夠聽取通話錄音或者語音留言。如果你經營一家技工公司，錯過一個重要電話，這可能會錯失一個能帶來大量收入的重要線索，你肯定希望 AI 不停地給你的手機發提醒：“快給那個人回電話！”雖然有點過于簡單化，但這大致就是“二次機會線索”的一點概念。還有其他一些我們構建和銷售的產品，例如語音 Agent。我們有一項 AI 接聽服務，可以幫助我們的客戶 7×24 小時全天候為他們的顧客預約工作。以上這些只是我們在 ServiceTitan 構建部分用例。

大規模遷移如同高山

不過，我今天要聊的重點，其實不是這些具體的 AI 產品。我想說的是一個更普遍的挑戰：當你手里有一堆跑在舊架構上的遺留代碼，你知道必須動它，但你也知道動起來會非常痛苦。在座各位如果在公司待過超過兩年，一定懂我在說什么。遺留代碼就是那種你越積越多、存在時間越長，就越拖慢你添加新功能、做變更的速度的東西。

整個行業的人，或多或少都參與過某種遷移項目。如果你在領導層或參與規劃，你也知道這類項目風險極高。當你決定把一大堆遺留代碼遷移到新平臺時，你不可能只完成 25% 或 50% 就收手，在很多情況下，你必須走完全程。這個“必須走完”本身就制造了巨大的風險。你絕對不想走到半路，才發現自己卡住了，進退兩難。

我先澄清一下，我說的不是那種早就被自動化解決了的遷移，比如把數據庫從一種格式遷移到另一種格式，寫個腳本一鍵轉換就行。那是簡單問題，早就被解決了。我討論的是那種真正的硬骨頭：幾十萬行遺留代碼，其中有些是 5 到 10 年前寫的，寫代碼的人早就不在公司了，文檔可能不全，單元測試覆蓋率堪憂。這種代碼，我們很多人都見過。把這些龐然大物搬進新的抽象層，簡直是赫拉克勒斯式的任務。（注：一個源自希臘神話的比喻，通常用來形容極其艱巨、困難重重，甚至看似不可能完成的任務。）

案例分析：遷移 ServiceTitan 的報告指標

為了把問題講具體，我接下來要分享一個案例——ServiceTitan 的報告指標遷移項目。

ServiceTitan 很大一部分應用都跟報告相關，我們讓客戶能夠下載、查看、做各種復雜的運營、財務和其他業務指標的分析，涉及工單、發票、技術人員、客戶等等。支撐這一切的底層代碼，就是典型的遺留代碼。有些技術組件接入生產數據庫的方式，跟我們今天從頭構建時會采用的方式完全不同，這是極其常見的困境。

但真正棘手的是規模問題。在我們這個場景里，有海量的業務指標，每一個指標背后都有一大塊遺留代碼在驅動，而每一塊代碼又可能有一堆隱藏的依賴關系。有些依賴是架構層面的，有些是隱性的，比如對數據庫表結構的隱含假設，或者對數據形態的默認依賴。要理清所有東西，需要大量時間。按照傳統方式，你會看到一個龐大的項目：需要成百上千張 Jira 工單，耗費數百個工程師周的時間，這就是數個季度乃至數年的光景。

還有一個關鍵問題，在 AI 出現之前，遷移項目并不總能成功。在 ServiceTitan 的報告系統上，已經有過不止一次嘗試，想要重構部分遺留代碼并遷移到更好的架構。這個案例就源于這樣一種局面：團隊花了一段時間試圖拆解遺留代碼，將其遷移到基于數據湖倉的新架構中，過程中遇到了重重挑戰，時間線一再掙扎。最糟糕的是，當你投入了幾個月甚至幾年，卻發現項目進展和最初的預期完全不一樣。

那時你就會開始問自己：這個方向真的對嗎？這種處境很糟糕，而且會讓很多人在規劃這類項目時徹夜難眠。在我們這個案例中，我們當時正盯著一個掙扎中的項目，一個團隊在挖掘遺留代碼時遇到了困難。于是我們開始用當時最前沿的編碼 LLM 來審視他們正在處理的那些代碼，想看看有沒有可能用不同的方式、更好的方式來推進，從而在遷移到新架構的過程中獲得更好的進展，這就是我們接下來要講的故事背景。

到了 2025 年，任何問題的默認解決方案都是：能不能直接問 AI？你有幾百個指標要遷移，直接扔進 Cursor 里就行了，聽起來很美好，對吧？但現實是，你不能直接讓 Cursor 或 Claude Code 把你的整個遺留代碼庫遷移到你描述的新架構中。我確實試過，結果非常糟糕。原因和一個工程師無法獨自完成這件事是一樣的——這個任務太大了。

就算你是非常優秀的工程師，你也不可能直接去修復幾十萬行代碼，把它們全部遷移到最新的架構里去。你可能會取得一些初步進展，但很快你就會發現自己面對著一座大山，根本無法理解所有遺留代碼背后的上下文。隊友離職了，文檔缺失了，你只能一點一點地挖掘，進展極其緩慢。

而換成 LLM 來寫代碼呢？它會幻覺，會誤解任務，會發明新的指標而不是遷移舊的，做了五個然后說“剩下的我會這么做：”就停了，而那做出來的五個還是錯的。哪怕用上最先進的模型，你看到的全是這種問題。

所以關鍵洞察是什么？把問題分解成可以逐個驗證的小步驟。這不是什么新想法，作為高級工程師或架構師，我們每天都在做這件事：把一個大問題拆解成可執行的子任務。但真正的新變化是：我們可以把時間線反轉過來。

加速原則

幾年前，規劃一次大型遷移意味著要進行大量的前期調查。你得做概念驗證（POC），評估可用方案，看看它們如何映射到現有技術棧，是否能滿足所有需求，然后做決策，購買商業軟件或選定開源方案，組建團隊，再開始那個耗時極長的批量遷移過程，最終價值要到項目結束時才能完全實現。這些項目天生就極難排期。

但現在不一樣了，我們可以在初期多做一些額外工作，在驗證環節變得極其嚴格，嚴格到每個增量步驟都能被精確驗證是否完成了該做的事。這就像并行化一樣，你可以把原本需要幾百個步驟的苦差事壓縮到更短的時間窗口內，從而更早地實現全部價值，同時也能獲得關于架構敏捷性的信號，能在幾周內而不是幾個季度后就知道新方案是否行不通。

先看遷移一個指標的場景。假設我團隊里的工程師要把一個特定指標從舊系統遷移到新的指標存儲系統，比如我們用的 DBT MetricFlow 和 Semantic Layer。要完成這個任務，他需要一些上下文：需要知道舊代碼在哪里，需要知道它依賴哪些數據庫表，需要知道數據的真實樣貌，甚至需要知道數據的分片信息。還需要了解目標模式是什么，架構師已經決定如何在新平臺上下文中應用它。然后才能規劃哪些文件需要改動，如何改動。接著才是編寫代碼，再驗證這些代碼工作良好，編寫測試。最后才能發布工作成果。

如果把視野拉遠到整個任務，不管它是 5 個步驟還是 500 個步驟，架構遷移的范疇其實都一樣：架構目標會展開成這些子任務和子目標。這很簡單，在 AI 時代之前我們也是這么做的，以前我們會用腦暴想出這些步驟，然后丟進 Jira 里。（如果你喜歡 Jira 的話。）

但現在，如果你能把標準化的上下文獲取、標準化的提示詞以及強大的驗證機制做到極致，確保每一步都能以足夠高的確定性判斷是否真的完成，你就可以把所有這些任務分配給機器人，然后以快得多的速度推進。

我把這個模式命名為“組裝線”（assembly line），當然這不是什么新名字。關鍵在于，我們其實早就能夠做第一步和第二步了，只是方式略有不同。而我們現在有了 2025 年水平的編碼 LLM，就能真正自動化第三步。核心思路是：你構建一條組裝線，不再把這些任務分配給工程師們花很長時間去完成，而是把它們分解、標準化、自動化。

我來詳細講講每一步。就像我之前說的，你絕對不想做的事情就是直接問“怎么把整座山搬走”，那太大了。你要做的是，精確地知道“怎么從山上搬走一塊石子”。把任務分解到這樣一個粒度：通過實驗能夠證明，一個 agent 確實可以成功完成這個子任務。當然，也有可能“石子”這個粒度并不合適，你可以通過實驗來調整，直到找到正確的分解粒度。

分解任務只是第一步。最關鍵的是第二步：為每個子任務建立一個可以程序化判斷“通過 / 失敗”的腳本、環境或平臺，你要能精確地驗證 bot 的每一次嘗試。你可能覺得這聽起來理所當然，但說實話，回過頭來看，我在想，為什么以前我們把這些任務分配給高級軟件工程師的時候，沒有堅持用這么嚴格的方式？當 Joe 或 Alice 提交 PR 時，我們本應有一個清晰、可編程的驗證機制，確保他們的產出完全符合預期，但過去我很少看到有人這么做。然而，當你用 agent 來加速執行大型遷移項目時，驗證器變得至關重要。尤其是在你需要短時間內并行跑完大量遷移任務時，你必須知道每一步都運行良好，否則你會很快偏離軌道。

在我們的案例中，我們構建了一個小型模擬器，它能夠生成和保存后端報表系統相同的報告，但使用的是新的指標平臺來構建這些報告。聽起來可能很簡單，但里面其實有很多細節。你要確保格式正確，數據可以直接比較，要能輕松地判斷“通過”：數據正確嗎？你能掃過整個分布嗎？數字對嗎？格式對嗎？這個“物理引擎”，讓你能實際測試編碼 agent 產出的環境，是整個流程的關鍵部件。

另一個要點是，你要強制讓所有這些任務彼此相似。這意味著你知道某些上下文信息對很多甚至大部分任務都是必需的，比如訪問 staging Snowflake 集群中的真實數據。很多人都在談論 MCP（Model Context Protocol），但實際上我們在這次遷移中完全沒有使用 MCP。我們是在 CLI 層面工作的，就像工程師如何獲取他們需要的上下文來修改代碼一樣。工程師用 CLI，CLI 能很好地展示測試數據在 Snowflake 中是什么樣子，我們給 agent 配備的就是這些 CLI 工具。根據我們的經驗：你不能只告訴 AI“把這個指標的公式在新平臺上重寫一遍”，而不提供關于表中數據實際樣子的詳細上下文，這樣它寫不出正確的代碼，就像人類一樣。

我們做的另一件事是，把整個項目的最終目標狀態非常清晰地定義在一個文本文件中，定義“單個任務的成功”意味著什么，“整個遷移的成功”意味著什么，這樣 bot 就擁有了所有正確的上下文，尤其是如何用驗證工具來測試自己的工作。我們要讓組裝線上的每個 bot 都擁有它需要的工具和上下文，以便能夠自主推進。

自愈循環

這樣，你就建立起了一個自愈循環：對于單個任務，agent 使用你提供的工具獲取所需上下文，然后編寫代碼，接著運行驗證器來檢查代碼是否滿足任務要求。如果不滿足，agent 會查看不匹配的細節，然后重試，重復這個過程。這就是驗證器與上下文獲取共同驅動的自愈循環，是整個遷移飛輪能夠持續運轉的核心動力。

但我們最初幾次嘗試啟動這個遷移飛輪時，碰到的最大問題是——如果沒有足夠好的驗證，事情會以驚人的速度失控。核心教訓非常清楚：自動化中的所有環節都很重要，如果你不給 bot 提供足夠的上下文來解決任務，結果就是 bot 卡在某個任務上；如果你用的 LLM 不夠聰明，無法理解你那堆寫于很久以前、文檔殘缺不全的遺留代碼，結果就是 agent 在特定任務上掙扎。

更可怕的是驗證器失效的場景。如果驗證器工作得不夠精確，你會讓 agent 長時間運行，任務一個接一個地跑，最終得到一堆看起來合理但實際上就是“垃圾”的東西。沒有真正好用的驗證器，你根本無法推進，你可能會浪費一整天甚至一整周的計算資源，然后發現根本沒達到目標。

我們在實際遷移幾百個指標的過程中，多次改進了驗證器。讓驗證器精確工作這件事本身就不簡單，很多遺留系統天生就不容易被觀測，就像不是所有代碼都容易做單元測試一樣。理想情況下，你應該能輕松看到系統內部發生的一切，能在正確的時間點訪問到正確的數據，但實際中你會有時序問題、數據對齊問題等等。這些原本在以前可能只是“錦上添花”的能力，現在變成了“生死攸關”的必要條件。

像管理“百戰小旅鼠”一樣管理 AI

這就引出了一個關鍵問題：LLM 到底需要多聰明？能像小黃人那樣，只會執行簡單指令就行嗎？能用去年那種短上下文窗口的模型嗎？答案是：它不需要像人類工程師那么聰明。關鍵不在于 LLM 的智商有多高，而在于你構建的自愈工作流。最壞的情況不過是 LLM 不理解任務，導致無法推進，這時候你需要反過來優化上下文呈現的方式。但這本身就是一個可控的迭代過程，而不是不可控的賭博。我經常聽到這類說法：“AI 會幻覺，它不懂怎么正確寫代碼，它經常犯低級錯誤，它寫出來的代碼你根本不敢放到生產環境。”這些擔心正在變少，但依然存在。我的回應是：它們根本不需要那么聰明。

為了讓你更直觀地理解成功的形態，我分享一個類比。不知道有多少人是跟我一樣在 90 年代長大的？當時有一款游戲叫《百戰小旅鼠》（Lemmings）。那些小旅鼠笨得要命，但你只要在它們的行進路線上放一些路障，就能確保它們全都到達目的地，這就是組裝線架構的本質。

那具體到代碼層我們到底做了什么？我們有一個`migration_goals.txt`文件。Goal State 定義了“完成”的標準：整體遷移在什么條件下才算成功？你需要在文件中明確寫出這個定義，并且用你配備的工具能檢測到的狀態來描述，包括整體狀態和每個步驟的進度。這就像給那些笨笨的小旅鼠畫好了路線圖，你只需要確保它們沿著路障走，最終就能到達終點。

在我們的例子里，我們大量使用了 SnowSQL，是一個從命令行運行 SQL 并連接 Snowflake 的工具。我們給 LLM 配備了正確的憑證，讓它能訪問暫存數據，這樣它就能直接運行命令，查看指標底層表中的數據長什么樣。我們還給它提供了如何找到已有遷移構件的信息，讓它能尋找復用的機會。然后我們告訴它如何檢查自己的工作，檢查方式必須和我們工程師驗證時用的方法一致。我們還限定了它的驗證范圍：只檢查自己的工作，不能去干后面的任務，只能做當前任務。

我們還維護了一個`migration_tasks.txt`文件，里面是任務的詳細拆解。我們把它分成多個階段，給工程師提供方便的檢查點，確保遷移過程中一切正常。剛開始的前 10、20、30 個任務，我們反復重做了很多次，直到把驗證腳本、上下文和工具都打磨到位之后，我們就放手讓它跑了。在短短幾周內，它幾乎完成了所有剩余的任務。LLM 每完成一個指標，就會在文件中標記為已完成。我們通過每次提交來觀察這個文件，能看到遷移進度逐步推進。

我們在 Cursor 中運行這個流程，但不再像之前那樣簡單告訴 Cursor“做這個”，而是說：“熟悉一下`migration_goals`和`migration_tasks`，然后實現階段 2.3。”Cursor 會自己生成待辦列表，尤其是最新版本。它本質上采用了我們總結出的相同原則：當你用它作為工具執行任務時，它會分解出若干子任務來完成一兩項指標的遷移，關鍵是要把握好粒度。設置好遷移機制后，你只需要給 Cursor 一個非常簡單的事情去做，把復雜性盡可能隱藏在驗證步驟和工具背后，確保它擁有解決問題所需的所有上下文。

遷移不再是高山

我們為報告平臺的大量指標運行了這個流程，結果非常令人振奮。作為工程師，這種感覺很爽，在我的職業生涯中，很多時候因為遷移太難、成本太高，很難證明做正確的事（比如采用更好的架構、使用更新的工具）是值得的。現在，基于這個原則，我們可以做很多以前根本做不了的事情，因為你能夠將時間線中漫長的那一段壓縮到一個非常短的時間窗口，因為我們現在可以把第三步，也就是對代碼的理解，自動化掉，這就是這項能力所開啟的可能性。

在我們搭建這一切的過程中，我們從最初的一般性分析階段（只是想弄清楚什么是可能的），一路做到在我們的真實新指標平臺上針對真實指標實際運行，也遇到了不少有趣的問題，我總結了幾類常見的“翻車”場景。

第一個大麻煩是：Agent 以為自己成功了，但實際上失敗了。你給它一個任務，它跑完了，報告“完成”，結果驗證腳本一查，發現邏輯根本不對。解決方案就是把驗證工具做得極其扎實，我們項目中大部分工程精力都花在了讓模擬驗證腳本跑得完美上。

Agent 卡住不動，也是常見問題，這通常是因為它找不到合適的測試數據來覆蓋某個指標背后微妙的邏輯。比如某個指標的計算邏輯依賴一個特殊的時間段或數據密度，而 Agent 從示例里扒不出來這些細節，這本質上就是信息不夠用。我們的應對方式是：回到源頭，找“黃金清單”——那些包含優質測試數據的 ID、數據密度已知的時間范圍的清單。把這些信息寫進`migration_goals`上下文文件里。這就像你以前需要隔著工位問同事：“嘿，你測試那個指標用的什么 ID？”現在把這些“部落知識”（tribal knowledge）文檔化，Agent 的成功率就能大幅提升。

完全靠自動化能覆蓋多少？大約 15% 的指標實在太復雜，必須工程師親自介入。也就是說，85% 的臟活累活可以被自動化覆蓋。當你有幾百個指標需要遷移時，這個比例的意義就完全不同了。

另一個有意思的點是：遷移做到一半，你發現架構設計得不好，想推倒重來。在過去的 Jira 工單模式下，這意味著巨大的時間成本和團隊士氣打擊。但“旅鼠們”并不在乎，你改好規則，重新跑一遍就完了。

我希望我傳達清楚的是：有一類項目，我們以前會想“這太費時間了、太難了”，所以干脆不做。現在，我們有了全新的敏捷性。原則和過去一樣，就像你組織一批初級工程師或實習生來幫忙做項目。但不同的是，現在你需要把這些流程標準化：寫好驗證腳本、提供清晰的上下文和工具。一旦這些就緒，你就可以搭起一條“組裝線”，讓所有任務像那些“旅鼠”一樣自動流過，它讓我們能做以前根本做不到的事。

回顧我的職業生涯，在加入 ServiceTitan 之前，我從 2012 年到 2023 年在 LinkedIn 工作。那段時間里，我親眼目睹了好幾次巨型遷移，有些項目需要幾十甚至上百名工程師，連續工作多個季度，去實現一些極其復雜的目標。比如實現跨地理位置的 safe active-active 架構，以及為此需要做的種種架構變更；或者拆解巨大的單體代碼庫，進行微服務化改造，這些項目背后是巨大的辛勞和復雜性。我經常在想，如果我們當時就擁有今天這種能理解代碼的“旅鼠”，那些項目會走向何方？我認為，這就是擁有能寫代碼的 Agent 所帶來的巨大變革之一——它不只是讓單個任務跑得更快，而是讓你能以前所未有的速度完成那些曾經不可能的任務，從而去嘗試新東西，去做那些你原本不會去做的事。

所以我想把問題拋給你們：有什么項目是你一直在想，但因為需要太多 Jira 工單、太多季度的開發周期，所以一直拖著、無限期推遲的？現在，借助這些思路，你是不是真的能去做了？

Q&A

Q：如果現在讓你再做一遍這件事，通往成功的最短路徑是什么？有沒有什么已經投入生產環境的工具，能夠真正加速這個過程？比如僅僅利用 Copilot、Cursor 這些工具現有的能力，能不能把整個工作流壓縮到極致？

David Stein：你問題的意思是：基于我們現在能做到的事情，這套工作流還能繼續簡化嗎？當初為了遷移那幾百個指標，我們做了很多工作，比如用 `goal_state.txt` 這樣的思路。現在 Cursor、Claude Code 這類工具，其實正在引導大家采用類似的方法，只不過未必像我這樣，把驗證器和類似物理引擎的機制做得那么正式。

我相信未來某一天，你完全可以直接把這個問題丟給 Cursor。到那時，它應該能夠自己分析你的遺留代碼，理解其中的各種細節，然后幫你構建合適的驗證器、合適的模擬引擎，把這些事情自動完成。因為它能夠處理整個代碼庫，理解全局上下文。

所以從長期來看，我預計大家不需要再做這么多結構化設計。但在那一天到來之前，我并不認為存在更簡單的方法。現階段，你還是需要認真地把問題拆解成 Claude 4.5 Opus，或者其他頂級模型能夠完成的任務；把任務定義得足夠清晰；搭建一個可靠的驗證器；然后按照我剛才描述的流程啟動它，讓系統自己運行。

Q：我覺得我們大家面對的其實都是同一個問題：怎么把自己從這些枯燥、繁瑣的工作里解放出來。那么，你如何保證這些 agents 在工作時的安全性和隱私性？我有些比較有創造力的 agents 會嘗試主動連接 AWS，或者執行一些危險操作，比如格式化機器之類的事情。面對這種情況，你怎么確保它們在編碼過程中不會做出高風險行為？

David Stein：出于這方面的考慮，我們實際采用的方法很簡單：嚴密監控，并且只給它們 staging 數據。我們不會把能夠造成嚴重后果的權限交給 agents，你肯定不希望它們拿到生產數據庫的密鑰，也不希望它們掌握那些能夠刪除線上數據的控制權限，這種做法非常危險。與此同時，我認為即使是 Cursor 這樣的工具，在安全隔離能力方面也仍然處于不斷成熟的階段。

現階段，我們必須足夠謹慎：不要給它不該擁有的密鑰，也要在它工作時持續觀察它到底在做什么。我覺得未來一定會有越來越多關于這個話題的討論，關于如何把更多安全機制直接內置到這些系統里。因為如果你面對的是極其敏感的應用場景，那么你必須非常謹慎地決定給 agents 配置哪些工具，以及這些 agents 應該運行在什么樣的環境里。好消息是，這套安全體系的嚴格程度其實可以不斷提高，最終達到你的業務場景所需要的安全等級。

演講視頻原鏈接：

https://www.infoq.com/presentations/refactoring-ai-agents/#

聲明：本文為 InfoQ 原創，不代表平臺觀點，也不構成投資建議，未經許可禁止轉載。

會議推薦

年中技術充能，盛夏 8 折赴約！AICon 深圳站集結華為、騰訊、阿里等全明星講師陣容，前沿方向 + 實戰干貨雙在線，承包你一夏的 AI 技術成長。大會限時早鳥票享 8 折專屬優惠，現在報名立減 1160，更多詳情可掃碼或聯系票務經理 13269078023 進行咨詢。