1. 棕地 Agent 工程到底在解決什么問題1.1 從“白地”到“棕地”一個被忽視的戰(zhàn)場過去兩年大部分關于 AI Agent 的討論都集中在一個理想化的場景里你有一個全新的項目干凈的代碼庫清晰的架構然后你從零開始搭建一個 Agent 系統(tǒng)。這種場景我稱之為“白地 Agent 工程”——綠地項目沒有歷史包袱想怎么設計就怎么設計。但現(xiàn)實是絕大多數(shù)開發(fā)者面對的并不是白地。你手里有一個跑了五年的 Spring Boot 單體應用或者一個 Django 項目里面塞滿了各種歷史遺留的 service 層、工具類、定時任務測試覆蓋率不到 30%文檔停留在三年前。這時候老板跟你說“給咱們系統(tǒng)加個 AI Agent 吧讓用戶能用自然語言查數(shù)據(jù)、觸發(fā)流程?！边@就是“棕地 Agent 工程”要解決的問題。棕地Brownfield這個詞來自城市規(guī)劃指的是那些已經(jīng)被開發(fā)過、可能存在污染或基礎設施老化的地塊。對應到軟件領域就是那些已經(jīng)存在、有技術債務、但仍在承載核心業(yè)務的代碼庫。你不可能推倒重來只能在現(xiàn)有基礎上做增量改造。我過去一年在三個不同規(guī)模的遺留系統(tǒng)上落地過 AI Agent踩過的坑比想象中多得多。這篇文章不講那些“從零搭建 Agent”的教程而是聚焦一個更現(xiàn)實的問題當你面對一個幾十萬行代碼、依賴關系錯綜復雜的遺留系統(tǒng)時怎么讓 AI Agent 真正跑起來而不是變成一個演示完就沒人用的玩具。1.2 棕地 Agent 工程的三個核心約束在動手之前你必須先認清棕地場景的三個硬約束這決定了你后續(xù)所有技術選型和架構決策。約束一不能大改現(xiàn)有代碼結構。遺留系統(tǒng)的代碼可能很爛但它能跑而且在承載真實業(yè)務。你沒有權限也沒有時間去做大規(guī)模重構。Agent 必須作為一個“外掛層”存在通過接口調(diào)用現(xiàn)有能力而不是侵入式地修改核心邏輯。約束二現(xiàn)有接口的語義不清晰。白地項目里你設計接口時會考慮語義化和可組合性。但遺留系統(tǒng)里的接口往往是“歷史堆積”的產(chǎn)物——一個processData()方法可能做了七八件事參數(shù)是一個巨大的 DTO返回值是一個 Map。Agent 要調(diào)用這些接口首先得理解它們到底在干什么。約束三沒有完整的測試覆蓋。這是最要命的一點。你想改任何東西都擔心會不會把某個隱藏的業(yè)務邏輯搞崩。特征測試Characterization Test在這里不是可選項而是必選項。你得先給現(xiàn)有系統(tǒng)“拍照”記錄它當前的行為才能在后續(xù)改造中有底氣。理解了這三個約束你就能明白為什么棕地 Agent 工程需要一套完全不同的方法論。下面我拆成七個反直覺的法則來講每一條都是我在實際項目中驗證過的。2. 法則一先寫特征測試再碰 Agent 代碼2.1 為什么特征測試是棕地 Agent 的地基很多人拿到一個遺留系統(tǒng)第一反應是“我先搭個 Agent 框架跑通一個 demo 再說”。這個思路在白地項目里沒問題但在棕地場景里是致命的。原因很簡單Agent 要調(diào)用現(xiàn)有系統(tǒng)的接口而你對這些接口的實際行為可能并不完全了解。文檔寫的是 A代碼實現(xiàn)是 B線上跑出來的結果是 C。如果你不先把現(xiàn)有行為固化下來后面 Agent 出了 bug你根本分不清是 Agent 的邏輯問題還是底層接口本來就有坑。特征測試的核心思路是不關心代碼“應該”怎么跑只記錄它“實際”怎么跑。你給一個輸入記錄輸出把這個輸入輸出對作為測試用例。這些測試不驗證業(yè)務正確性只驗證行為一致性。后續(xù)你改任何東西只要這些測試還過就說明你沒有破壞現(xiàn)有行為。2.2 特征測試的實操步驟具體怎么做我以一個有十年歷史的 Java 后端系統(tǒng)為例。第一步找出 Agent 將要調(diào)用的核心接口。不要貪多先圈定 Agent 需要用到的那 10 到 20 個方法。這些方法通常集中在幾個 service 類里比如訂單查詢、用戶信息獲取、庫存檢查等。第二步為每個方法構造典型輸入。這里有個技巧從生產(chǎn)日志里撈真實請求。把過去一周的接口調(diào)用日志導出來按方法名分組每個方法取 50 到 100 個真實輸入樣本。這比你自己拍腦袋構造的輸入靠譜得多。第三步記錄輸出并生成測試。寫一個簡單的腳本遍歷這些輸入調(diào)用方法把輸入和輸出序列化成 JSON然后自動生成 JUnit 測試。下面是一個簡化的示例// 自動生成的特征測試骨架 Test public void characterize_queryOrder() { // 輸入來自生產(chǎn)日志樣本 OrderQueryRequest request new OrderQueryRequest(); request.setOrderId(ORD-2023-001); request.setUserId(12345L); // 調(diào)用實際方法 OrderResult result orderService.queryOrder(request); // 斷言實際輸出首次運行時從實際結果復制 assertEquals(PAID, result.getStatus()); assertEquals(3, result.getItems().size()); assertEquals(new BigDecimal(299.00), result.getTotalAmount()); }第四步跑通所有特征測試確保全綠。這時候你就有了一個“行為基線”。后續(xù)任何改動只要這些測試還過就說明底層行為沒變。注意特征測試不是單元測試不要試圖去 mock 依賴。讓它跑真實邏輯哪怕慢一點。你追求的是行為快照的準確性不是測試執(zhí)行速度。2.3 特征測試的常見坑第一個坑是數(shù)據(jù)依賴。遺留系統(tǒng)的接口往往依賴數(shù)據(jù)庫里的特定數(shù)據(jù)狀態(tài)。你今天跑測試是綠的明天數(shù)據(jù)庫被人改了一條記錄測試就紅了。解決辦法是給測試準備獨立的數(shù)據(jù)集或者在測試前用腳本重置數(shù)據(jù)。第二個坑是時間依賴。很多接口的行為跟當前時間有關比如“查詢最近 30 天訂單”。這種測試你沒法直接斷言輸出需要把時間參數(shù)化或者用固定時鐘注入。第三個坑是外部服務依賴。如果接口調(diào)用了第三方支付、短信等服務特征測試會變得不穩(wěn)定。我的做法是先用擋板Stub把外部依賴隔離掉只測試本地邏輯的行為。3. 法則二Agent 不是替代者是翻譯層3.1 重新理解 Agent 在遺留系統(tǒng)中的角色很多團隊在引入 Agent 時潛意識里把它當成一個“更聰明的接口”。用戶說一句話Agent 理解意圖然后調(diào)用對應接口返回結果。這個理解不算錯但太淺了。在棕地場景里Agent 的真正價值是翻譯層。它翻譯的不是語言而是語義鴻溝。遺留系統(tǒng)的接口是給程序員用的參數(shù)是技術化的返回值是結構化的。但用戶的需求是業(yè)務化的、模糊的、帶有上下文依賴的。Agent 要做的是把“幫我看看上個月那個大單子到哪了”翻譯成queryOrder(orderId..., userId...)這樣的技術調(diào)用。這個翻譯過程涉及三個層次的理解意圖識別、參數(shù)映射、結果解釋。意圖識別是基礎參數(shù)映射是難點結果解釋是加分項。3.2 參數(shù)映射棕地 Agent 最臟最累的活參數(shù)映射為什么難因為遺留系統(tǒng)的接口參數(shù)往往不是為自然語言設計的。我見過一個查詢接口需要傳一個sceneCode參數(shù)取值是01、02、03分別代表不同的業(yè)務場景。用戶說“查一下我的訂單”Agent 怎么知道該傳哪個 sceneCode解決辦法是建一個語義映射表。把接口參數(shù)的業(yè)務含義顯式地寫出來作為 Agent 的知識庫。這個表不需要很復雜一個 YAML 文件就夠了queryOrder: description: 查詢訂單詳情 parameters: sceneCode: type: enum values: 01: 普通商城訂單 02: 團購訂單 03: 預售訂單 default: 01 orderId: type: string description: 訂單編號通常以 ORD- 開頭 userId: type: long description: 用戶ID從當前登錄態(tài)獲取有了這個映射表Agent 在解析用戶意圖時就有了依據(jù)。用戶說“查一下我的團購訂單”Agent 就能推斷出 sceneCode 應該是 02。3.3 結果解釋讓 Agent 說人話遺留系統(tǒng)的返回值往往是給程序看的不是給人看的。一個訂單查詢可能返回幾十個字段包含各種狀態(tài)碼、時間戳、內(nèi)部標識。用戶只想知道“我的訂單到哪了”。Agent 的結果解釋層要做的是從結構化數(shù)據(jù)中提取關鍵信息用自然語言組織成用戶能理解的回答。這里有個原則寧可少說不要亂說。如果某個字段的含義不確定寧可不提也不要瞎猜。我通常會在映射表里加一個responseTemplate字段定義每種意圖的返回格式queryOrder: responseTemplate: | 您的訂單 {{orderId}} 當前狀態(tài)是{{statusDesc}}。 下單時間{{createTime}} 訂單金額{{totalAmount}} 元 包含 {{itemCount}} 件商品。這樣 Agent 只需要做字段填充不需要自己組織語言既保證了準確性又降低了幻覺風險。4. 法則三遷移盲區(qū)比技術債務更危險4.1 什么是遷移盲區(qū)遷移盲區(qū)Migration Blind Spot是我自己造的一個詞指的是那些在遺留系統(tǒng)中“看起來能用但實際上已經(jīng)腐爛”的部分。它們不在你的技術債務清單上因為沒人覺得它們是問題直到 Agent 調(diào)用它們時炸了。舉個例子。你有一個用戶信息查詢接口返回用戶的基本信息。這個接口跑了五年一直沒問題。但當你讓 Agent 去調(diào)用它時發(fā)現(xiàn)返回的userLevel字段有時候是數(shù)字有時候是字符串有時候是 null。為什么因為五年前有個實習生寫了一段代碼在某些分支下直接返回了原始數(shù)據(jù)庫值沒有做類型轉換。這個 bug 一直存在但因為前端做了兼容處理沒人發(fā)現(xiàn)?，F(xiàn)在 Agent 直接消費這個接口就踩坑了。4.2 如何發(fā)現(xiàn)遷移盲區(qū)發(fā)現(xiàn)遷移盲區(qū)的方法論是用 Agent 的調(diào)用方式去壓測現(xiàn)有接口。具體來說做三件事。第一邊界值測試。把每個參數(shù)推到極端值——空字符串、超長字符串、負數(shù)、零、最大整數(shù)——看接口怎么反應。很多遺留接口在邊界條件下會返回意料之外的結果。第二并發(fā)測試。Agent 的調(diào)用模式跟人類用戶不同它可能在短時間內(nèi)發(fā)起大量請求。遺留系統(tǒng)里那些依賴單例狀態(tài)、靜態(tài)變量、線程不安全集合的代碼在并發(fā)場景下會暴露問題。第三時序測試。Agent 可能會在非工作時間調(diào)用接口或者以人類不會采用的順序調(diào)用接口。比如先查訂單再查用戶而正常流程是先查用戶再查訂單。這種時序變化可能觸發(fā)隱藏的狀態(tài)依賴問題。4.3 遷移盲區(qū)的處理策略發(fā)現(xiàn)遷移盲區(qū)后你有三個選擇修復、繞過、或者隔離。修復是最徹底的但成本最高。如果這個盲區(qū)影響面大而且修復方案清晰那就修。但更多時候我建議繞過。在 Agent 層加一個適配器把臟數(shù)據(jù)洗干凈再返回給 Agent。這樣既不影響現(xiàn)有系統(tǒng)又能讓 Agent 正常工作。隔離是最保守的策略。如果某個接口的盲區(qū)太多修不動也繞不過那就干脆不讓 Agent 調(diào)用它。在映射表里把這個接口標記為deprecated讓 Agent 走別的路徑。我的經(jīng)驗是遷移盲區(qū)的處理優(yōu)先級應該是“繞過 隔離 修復”。因為你的首要目標是讓 Agent 跑起來而不是借這個機會重構遺留系統(tǒng)。重構的事等 Agent 穩(wěn)定運行三個月后再考慮。5. 法則四Agent 的并發(fā)能力取決于最慢的那個接口5.1 為什么 Agent 并發(fā)是個偽命題“AI Agent 怎么扛并發(fā)”是最近被問得最多的問題之一。很多人的思路是Agent 框架本身要支持高并發(fā)要用異步、要用協(xié)程、要用消息隊列。這個思路在白地項目里成立但在棕地場景里Agent 的并發(fā)能力根本不取決于 Agent 框架而取決于它調(diào)用的最慢的那個遺留接口。我做過一個測試Agent 框架本身用異步 IO單機能扛 5000 QPS。但它調(diào)用的訂單查詢接口底層是一個沒有索引的數(shù)據(jù)庫查詢平均響應時間 800ms并發(fā)超過 50 就開始排隊。結果整個 Agent 系統(tǒng)的實際吞吐量被卡在 50 QPS 左右。5.2 棕地 Agent 的并發(fā)優(yōu)化策略既然瓶頸在遺留接口優(yōu)化就要從接口層入手。但你不能直接去改數(shù)據(jù)庫索引或者重寫查詢邏輯那超出了 Agent 項目的范圍。你能做的是在 Agent 層做請求合并和結果緩存。請求合并的思路是如果多個 Agent 請求在短時間內(nèi)查詢同一個數(shù)據(jù)把它們合并成一個底層調(diào)用。比如用戶 A 和用戶 B 同時查同一個訂單Agent 層只發(fā)一次查詢請求然后把結果分發(fā)給兩個請求。結果緩存的思路更直接對于讀多寫少的數(shù)據(jù)在 Agent 層加一層緩存。緩存的有效期不需要很長5 到 10 秒就夠了。這能擋住大部分重復請求。下面是一個簡單的請求合并實現(xiàn)思路class RequestCoalescer: def __init__(self): self.pending {} async def query(self, key, fetch_func): if key in self.pending: return await self.pending[key] future asyncio.ensure_future(fetch_func()) self.pending[key] future try: result await future return result finally: del self.pending[key]這段代碼的核心邏輯是如果同一個 key 的請求已經(jīng)在處理中就復用那個 future而不是發(fā)起新的調(diào)用。5.3 并發(fā)場景下的降級策略即使做了合并和緩存遺留接口在高峰期仍然可能扛不住。這時候你需要一個降級策略當?shù)讓咏涌陧憫獣r間超過閾值時Agent 自動切換到“簡化模式”。簡化模式的意思是不查完整數(shù)據(jù)只返回最核心的信息。比如訂單查詢正常模式返回訂單詳情、商品列表、物流信息簡化模式只返回訂單狀態(tài)。這樣底層接口的負載能降低一個數(shù)量級。降級策略的觸發(fā)條件需要根據(jù)實際壓測結果來定。我的經(jīng)驗值是當 P99 響應時間超過 2 秒或者錯誤率超過 5%就觸發(fā)降級。6. 法則五Agent 的提示詞要寫進代碼倉庫6.1 提示詞不是配置是代碼很多團隊把 Agent 的提示詞當成配置文件放在數(shù)據(jù)庫里或者配置中心運行時動態(tài)加載。這個做法在白地項目里可以但在棕地場景里會帶來嚴重問題。原因很簡單棕地 Agent 的提示詞跟遺留系統(tǒng)的接口語義強耦合。接口改了提示詞必須跟著改。如果提示詞在配置中心代碼在 Git 倉庫兩者的版本就對不上了。你改了一個接口的參數(shù)名忘了同步更新配置中心的提示詞Agent 就開始胡言亂語。我的做法是提示詞必須跟代碼在同一個倉庫同一個分支同一個提交里。提示詞文件用 Markdown 或者 YAML 格式放在代碼目錄下跟調(diào)用它的代碼放在一起。6.2 提示詞的版本管理策略提示詞進倉庫后版本管理就變得很重要。我通常采用三層結構第一層是基礎提示詞定義 Agent 的角色、能力邊界、輸出格式。這部分相對穩(wěn)定變更頻率低。第二層是接口提示詞每個遺留接口對應一段提示詞描述這個接口的功能、參數(shù)、返回值。這部分跟接口代碼強綁定接口改了就改它。第三層是場景提示詞針對特定業(yè)務場景的補充說明。比如“查詢訂單時如果用戶沒有指定訂單號優(yōu)先查詢最近一筆訂單”。這部分最靈活可以頻繁調(diào)整。三層提示詞在運行時拼接成完整的 prompt。這樣既保證了穩(wěn)定性又保留了靈活性。6.3 提示詞的測試與回歸提示詞進倉庫的另一個好處是可以做回歸測試。你可以像寫單元測試一樣為提示詞寫測試用例給定一個用戶輸入斷言 Agent 的輸出包含某些關鍵信息。def test_query_order_prompt(): user_input 幫我查一下上個月那個大單子 context {userId: 12345} result agent.process(user_input, context) assert 訂單 in result assert ORD- in result # 應該包含訂單號 assert 元 in result # 應該包含金額這些測試跑在 CI 里每次改提示詞都會觸發(fā)。如果某個改動導致測試失敗你立刻就知道有問題。7. 法則六不要追求全自動人機協(xié)同才是終點7.1 全自動 Agent 的幻覺陷阱很多團隊對 Agent 的期望是“全自動”——用戶說一句話Agent 從頭到尾搞定不需要人工介入。這個目標在演示環(huán)境里很容易實現(xiàn)但在生產(chǎn)環(huán)境里尤其是棕地場景里幾乎不可能。原因在于遺留系統(tǒng)的不確定性。接口可能返回臟數(shù)據(jù)業(yè)務規(guī)則可能有例外情況用戶輸入可能模糊不清。Agent 在這些情況下如果強行“自動處理”結果往往是災難性的。我見過一個案例Agent 自動幫用戶提交了一個退款申請因為用戶說“這個訂單我不想要了”。但用戶的實際意思是“我想修改訂單地址”只是表達得比較隨意。結果退款流程走了一半用戶收到退款通知才發(fā)現(xiàn)問題。7.2 人機協(xié)同的三種模式在棕地 Agent 工程里我推薦三種人機協(xié)同模式根據(jù)場景風險等級選擇。模式一確認式協(xié)同。Agent 完成意圖理解和參數(shù)映射后把結果展示給用戶確認用戶點“確認”后才執(zhí)行。這種模式適合高風險操作比如退款、刪除、修改關鍵數(shù)據(jù)。模式二建議式協(xié)同。Agent 給出建議但由人工決定是否采納。比如 Agent 說“我建議查詢 sceneCode02 的團購訂單是否正確”用戶可以選擇“是”或者手動指定其他值。這種模式適合中等風險操作。模式三靜默式協(xié)同。Agent 自動執(zhí)行但記錄完整日志人工可以事后審計。這種模式適合低風險操作比如查詢類請求。7.3 協(xié)同模式的選擇標準怎么判斷一個操作該用哪種模式我通常看三個維度可逆性、影響范圍、用戶預期?？赡嫘圆僮髂懿荒艹蜂N查詢可以退款不行。影響范圍操作影響一個用戶還是所有用戶影響越大越需要確認。用戶預期用戶是否期望這個操作自動完成如果用戶說“幫我查一下”他期望立刻看到結果如果用戶說“幫我處理一下”他可能期望有人工介入。把這三個維度畫成一個矩陣就能快速判斷該用哪種協(xié)同模式。8. 法則七Agent 的日志比 Agent 本身更重要8.1 為什么棕地 Agent 需要超詳細日志在白地項目里Agent 出問題了你可以看代碼、看測試、看監(jiān)控。但在棕地場景里Agent 出問題往往是因為底層遺留系統(tǒng)的某個隱藏行為。如果你沒有詳細的日志根本無從排查。我要求棕地 Agent 的日志必須包含以下信息用戶原始輸入、Agent 解析后的意圖、映射到的接口和參數(shù)、接口的實際調(diào)用時間和返回值、Agent 生成的最終回復。這五段信息缺一不可。8.2 日志的結構化與可查詢?nèi)罩静荒苁羌兾谋颈仨毷墙Y構化的 JSON。每個字段都有明確的含義方便后續(xù)查詢和分析。{ traceId: abc-123, timestamp: 2024-01-15T10:30:00Z, userInput: 幫我查一下上個月那個大單子, parsedIntent: queryOrder, mappedParams: { sceneCode: 01, userId: 12345, timeRange: last_month }, apiCall: { endpoint: /api/order/query, durationMs: 850, responseCode: 200 }, agentResponse: 您的訂單 ORD-2023-1234 當前狀態(tài)是已發(fā)貨... }有了這樣的日志排查問題就簡單了。用戶說“Agent 回答錯了”你拿 traceId 一查立刻能看到是意圖解析錯了還是參數(shù)映射錯了還是接口返回了臟數(shù)據(jù)。8.3 日志驅動的持續(xù)優(yōu)化日志不僅是排查工具還是優(yōu)化依據(jù)。我每周會做一次日志分析看三件事第一意圖解析失敗率。哪些用戶輸入 Agent 無法正確理解把這些輸入收集起來補充到提示詞的示例里。第二參數(shù)映射錯誤率。哪些參數(shù)經(jīng)常映射錯檢查映射表是不是寫得不清楚或者接口本身有歧義。第三接口異常率。哪些接口經(jīng)常返回錯誤或超時這些接口就是遷移盲區(qū)的候選需要重點處理。這個日志驅動的優(yōu)化循環(huán)是棕地 Agent 工程能持續(xù)迭代的關鍵。沒有日志你就是在盲人摸象。9. 棕地 Agent 工程的工具選型與團隊配置9.1 工具選型的核心原則棕地 Agent 工程的工具選型跟白地項目完全不同。白地項目可以追求最新最酷的框架棕地項目必須追求穩(wěn)定、可觀測、易集成。Agent 框架方面我傾向于選擇那些對遺留系統(tǒng)友好的方案。比如 LangChain 和 LangGraph 提供了豐富的工具集成能力可以很方便地包裝現(xiàn)有 HTTP 接口。Spring AI 對于 Java 技術棧的團隊來說是個不錯的選擇它能直接復用 Spring 生態(tài)的依賴注入和配置管理。如果你追求極致的性能和并發(fā)Rust 生態(tài)的 Agent 框架也值得考慮但前提是你的團隊有 Rust 經(jīng)驗。否則學習成本會拖慢整個項目。9.2 團隊配置建議棕地 Agent 工程不需要很大的團隊但需要角色搭配合理。我的建議配置是一個架構師負責整體方案設計和遷移盲區(qū)的判斷。這個人必須對遺留系統(tǒng)有深入了解知道哪些地方能碰、哪些地方不能碰。一個后端工程師負責 Agent 層的開發(fā)和接口適配。這個人要熟悉 Agent 框架同時也要能讀懂遺留代碼。一個測試工程師負責特征測試和回歸測試。這個人要有耐心愿意寫大量的行為快照測試。如果條件允許再加一個業(yè)務分析師負責梳理接口語義和編寫映射表。這個角色往往被忽視但在棕地場景里非常重要。9.3 項目推進的節(jié)奏棕地 Agent 工程不能搞“大爆炸”式上線。我的建議是分三個階段推進。第一階段是單點驗證選一個最簡單的查詢場景把 Agent 跑通。這個階段的目標不是功能完整而是驗證技術路線可行。第二階段是場景擴展把 Agent 的能力擴展到 5 到 10 個核心場景。這個階段會暴露大量的遷移盲區(qū)和接口問題是工作量最大的階段。第三階段是穩(wěn)定運行重點做日志分析、性能優(yōu)化、降級策略。這個階段的目標是讓 Agent 在生產(chǎn)環(huán)境里穩(wěn)定跑三個月以上。每個階段之間留出至少兩周的緩沖期用來處理意料之外的問題。棕地項目的問題總是比預想的多。10. 一些踩坑之后的個人體會棕地 Agent 工程最反直覺的一點是技術不是最大的障礙對遺留系統(tǒng)的理解才是。我見過太多團隊Agent 框架玩得很溜但一碰到遺留系統(tǒng)的臟數(shù)據(jù)、隱藏邏輯、 undocumented 行為就束手無策。我的建議是在寫第一行 Agent 代碼之前先花兩周時間做三件事讀遺留系統(tǒng)的核心代碼跑特征測試跟業(yè)務方聊接口的實際使用場景。這三件事做完你對系統(tǒng)的理解會超過過去半年的總和。另一個體會是不要試圖用 Agent 去解決遺留系統(tǒng)的所有問題。Agent 是一個增量能力不是重構工具。它的價值在于讓用戶用更自然的方式使用現(xiàn)有系統(tǒng)而不是讓現(xiàn)有系統(tǒng)變得更好。把這兩個目標混在一起項目一定會失控。最后分享一個實用技巧在 Agent 的映射表里給每個接口加一個confidence字段表示你對這個接口語義理解的置信度。置信度低的接口Agent 在調(diào)用時自動觸發(fā)人工確認。這個簡單的機制能擋住大部分因為接口理解錯誤導致的問題。棕地 Agent 工程沒有標準答案每個遺留系統(tǒng)都是獨特的。但上面這七條法則是我在三個項目里反復驗證過的。它們不一定全對但至少能讓你少走一些彎路。