戰(zhàn)：讓Agent自主開(kāi)發(fā)RAG問(wèn)答機(jī)器人的全記錄)
1. “AI造AI”到底在造什么1.1 先厘清概念A(yù)I造AI不等于AI自我進(jìn)化最近半年“AI能不能自己造AI”這個(gè)問(wèn)題在開(kāi)發(fā)者圈子里被反復(fù)吵上熱搜吵架的雙方經(jīng)常根本不是在聊同一件事。有人理解的“造AI”是“讓AI設(shè)計(jì)出比自身更聰明的下一代AI”這是AGI層面的問(wèn)題現(xiàn)階段確實(shí)做不到而有人理解的“造AI”是“讓AI去寫AI應(yīng)用、訓(xùn)練腳本、推理服務(wù)、部署配置”這個(gè)事不僅已經(jīng)有人做出來(lái)了而且做出來(lái)的效果已經(jīng)可以進(jìn)生產(chǎn)環(huán)境用了。我自己最近就干了一件挺有儀式感的事扔給一個(gè)AI Agent一份任務(wù)簡(jiǎn)報(bào)讓它從零開(kāi)始開(kāi)發(fā)一個(gè)“產(chǎn)品文檔RAG問(wèn)答機(jī)器人”——包含后端接口、向量檢索、模型接入、前端頁(yè)面、Docker部署最后Agent自己跑測(cè)試、自己修bug、自己把服務(wù)拉起來(lái)我用瀏覽器訪問(wèn)時(shí)發(fā)現(xiàn)頁(yè)面都能正常出來(lái)。整個(gè)過(guò)程里我只做了三件事寫清楚需求、盯著它別偏、最后做驗(yàn)收。所以你看如果我們把“AI造AI”定義成“AI作為工程師完成AI應(yīng)用的設(shè)計(jì)、開(kāi)發(fā)和部署”那這個(gè)標(biāo)題沒(méi)什么可吵的答案就是“能”。它不是科幻是工程效率的一次實(shí)實(shí)在在的突破。1.2 為什么爭(zhēng)議這么大能力邊界與想象力的錯(cuò)位爭(zhēng)議大的核心原因是“造AI”這個(gè)詞太容易被過(guò)度解讀。網(wǎng)上討論AI自我復(fù)制、AI自行進(jìn)化天然自帶流量但落到工程現(xiàn)場(chǎng)我們關(guān)心的其實(shí)是更具體的問(wèn)題AI能不能把一份模糊需求變成可運(yùn)行的代碼能不能在編譯報(bào)錯(cuò)時(shí)自己定位問(wèn)題能不能把一個(gè)模型推理服務(wù)完整部署上線從我自己實(shí)操以及身邊團(tuán)隊(duì)的使用情況看答案是明確的“能”只是有條件。條件是任務(wù)邊界要清晰執(zhí)行環(huán)境要給足反饋回路要完整人工審核不能缺位。AI Agent不是神仙它更像一個(gè)執(zhí)行力極強(qiáng)但需要環(huán)境配合的初級(jí)工程師。給它一臺(tái)能跑命令的電腦、一套能回傳報(bào)錯(cuò)信息的工具鏈、一份夠具體的需求說(shuō)明它就能像人一樣一個(gè)文件一個(gè)文件把項(xiàng)目搭起來(lái)再通過(guò)運(yùn)行結(jié)果倒逼自己修正。這篇文章我就把自己做“AI自己造AI”的完整過(guò)程、技術(shù)選型、踩坑記錄和邊界思考全部攤開(kāi)。適合誰(shuí)看想用AI Agent提升開(kāi)發(fā)效率的工程師、正在評(píng)估“AI能否承擔(dān)部分研發(fā)工作”的技術(shù)管理者以及單純好奇AI能力邊界的產(chǎn)品和測(cè)試同學(xué)。2. 工具選型讓AI“自己動(dòng)手”需要怎樣的底座2.1 核心組件大模型 Agent框架 執(zhí)行環(huán)境想讓AI Agent真正完成開(kāi)發(fā)任務(wù)光有一個(gè)聊天窗口遠(yuǎn)遠(yuǎn)不夠。你需要三個(gè)東西協(xié)同工作一個(gè)會(huì)思考的大模型、一套能調(diào)度工具的Agent框架、一個(gè)允許Agent動(dòng)手操作的真實(shí)環(huán)境。大模型是“大腦”。最好選代碼生成能力強(qiáng)的模型同時(shí)要求支持長(zhǎng)上下文和工具調(diào)用。我這次的主力模型是支持Function Calling的版本規(guī)劃任務(wù)時(shí)用它的強(qiáng)推理能力寫代碼時(shí)用它的代碼補(bǔ)全能力。如果你的環(huán)境允許也可以考慮本地部署的開(kāi)源模型比如用Ollama跑Qwen系列這樣簡(jiǎn)單模塊可以交給本地模型執(zhí)行復(fù)雜規(guī)劃和設(shè)計(jì)再交給云端模型成本會(huì)更可控。Agent框架是“手和腳”。常見(jiàn)的開(kāi)源方案有LangGraph、AutoGPT也有偏應(yīng)用層的DifyJava生態(tài)里還有Spring AI。它們本質(zhì)都是給AI提供文件讀寫、終端執(zhí)行、網(wǎng)頁(yè)訪問(wèn)、工具調(diào)用等能力并維護(hù)“規(guī)劃—執(zhí)行—觀察—再規(guī)劃”的循環(huán)。如果你只是做一個(gè)快速驗(yàn)證用LangGraph搭一個(gè)最小循環(huán)就夠了如果是企業(yè)內(nèi)部落地我更推薦Dify或自研一套輕量框架便于控制權(quán)限和審計(jì)。這次演示我用的就是基于LangGraph改的極簡(jiǎn)Agent總共就兩層主Agent負(fù)責(zé)任務(wù)拆解工具層負(fù)責(zé)讀寫文件和執(zhí)行shell命令。執(zhí)行環(huán)境是“工地”。這也是新手最容易低估的部分。AI Agent必須能真正跑在沙箱環(huán)境里能夠執(zhí)行pip install、運(yùn)行pytest、讀取報(bào)錯(cuò)輸出才能形成“寫代碼—看結(jié)果—改代碼”的閉環(huán)。我用的是一臺(tái)帶Docker的Linux服務(wù)器所有操作都在容器里進(jìn)行宿主機(jī)只掛載了一個(gè)工作目錄。這樣既給了Agent足夠的自由度又不至于讓它碰到系統(tǒng)關(guān)鍵目錄。注意給Agent的“工地”一定要隔離。它會(huì)在里面執(zhí)行任意命令所以絕不能和生產(chǎn)環(huán)境、密鑰文件混在一起。用容器隔離是底線不是可選項(xiàng)。2.2 為什么不是“一句提示詞”就能完成現(xiàn)在很多人習(xí)慣在ChatGPT里發(fā)一句“幫我寫一個(gè)RAG機(jī)器人”然后復(fù)制粘貼代碼。這不算AI造AI這只是AI當(dāng)百度用。真正的AI Agent開(kāi)發(fā)要求AI自己管理整個(gè)項(xiàng)目生命周期它要知道該建哪些文件、依賴裝什么、程序怎么跑、報(bào)錯(cuò)怎么修。我嘗試過(guò)一個(gè)對(duì)比場(chǎng)景。同一個(gè)小型情感分析API讓普通聊天模型“一次輸出”和讓Agent“自主迭代開(kāi)發(fā)”是兩種完全不同的結(jié)果。前者會(huì)給你一個(gè)看起來(lái)完整、但大概率跑不起來(lái)的代碼片段后者會(huì)自己創(chuàng)建虛擬環(huán)境、安裝依賴、啟動(dòng)服務(wù)、用curl打接口驗(yàn)證最后交付的是一個(gè)實(shí)際上線可用的服務(wù)。差別在哪差別就在于有沒(méi)有“運(yùn)行反饋”。所以我把這次實(shí)踐的關(guān)鍵總結(jié)成一句話AI造AI的本質(zhì)不是AI一口氣寫出完整程序而是AI在一個(gè)能自我驗(yàn)證的環(huán)境里通過(guò)多輪試錯(cuò)把程序改到能跑。這就意味著工程約束比模型本身的智商更重要。你得把任務(wù)目標(biāo)量化、把驗(yàn)收標(biāo)準(zhǔn)寫清楚、把迭代輪次卡住AI才能真正為你創(chuàng)造價(jià)值而不是給你制造一堆需要返工的半成品。3. 實(shí)操記錄我是怎么讓AI Agent從0到1做一個(gè)RAG問(wèn)答機(jī)器人3.1 第一步給AI寫一份“任務(wù)簡(jiǎn)報(bào)”這次我選了一個(gè)很典型的AI應(yīng)用場(chǎng)景產(chǎn)品文檔問(wèn)答機(jī)器人。用戶傳入一段問(wèn)題系統(tǒng)從本地文檔庫(kù)里檢索相關(guān)資料然后讓大模型基于檢索結(jié)果生成回答。這類應(yīng)用是RAG檢索增強(qiáng)生成的經(jīng)典落地形態(tài)也是AI應(yīng)用開(kāi)發(fā)里最有代表性的“AI工程”活。我先把任務(wù)簡(jiǎn)報(bào)寫好簡(jiǎn)報(bào)里寫明了技術(shù)棧、目標(biāo)接口、驗(yàn)收標(biāo)準(zhǔn)和約束條件。如果你也想復(fù)現(xiàn)可以直接參考這份結(jié)構(gòu)項(xiàng)目目標(biāo)基于產(chǎn)品文檔構(gòu)建一個(gè)RAG問(wèn)答API支持上傳文檔、檢索、問(wèn)答三個(gè)接口。技術(shù)棧要求Python 3.11、FastAPI、Chroma向量數(shù)據(jù)庫(kù)、一個(gè)Embedding模型、一個(gè)LLM接口我用的是兼容OpenAI格式的本地模型服務(wù)。功能范圍上傳PDF/Markdown時(shí)自動(dòng)切分問(wèn)答接口先檢索top-k相關(guān)片段再讓大模型生成答案結(jié)果返回引用來(lái)源。明確“不要做”不要做用戶登錄、不要做前端復(fù)雜交互、不要做權(quán)限管理。驗(yàn)收標(biāo)準(zhǔn)/upload接口能上傳并檢索/ask接口能基于文檔內(nèi)容回答問(wèn)題/health接口返回200每個(gè)模塊都要有測(cè)試。運(yùn)行約束所有命令必須在項(xiàng)目虛擬環(huán)境內(nèi)執(zhí)行目錄結(jié)構(gòu)遵循FastAPI官方最佳實(shí)踐。你可能會(huì)問(wèn)為什么非要寫這么細(xì)因?yàn)锳I Agent在面對(duì)模糊任務(wù)時(shí)最大的風(fēng)險(xiǎn)是自由發(fā)揮。它會(huì)給你加一堆花哨但沒(méi)用的功能也會(huì)忽略你真正關(guān)心的細(xì)節(jié)。任務(wù)簡(jiǎn)報(bào)的價(jià)值就是給Agent劃定邊界讓它把精力集中在核心交付上。這個(gè)步驟花了我大概半小時(shí)但它決定了后面幾小時(shí)的輸出質(zhì)量。3.2 第二步Agent從規(guī)劃到動(dòng)手任務(wù)簡(jiǎn)報(bào)寫好之后我把Agent啟動(dòng)它會(huì)先輸出一份項(xiàng)目規(guī)劃。這一步真的很有意思它產(chǎn)生了這樣一個(gè)目錄結(jié)構(gòu)doc-qa/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI入口 │ ├── models.py # 數(shù)據(jù)模型 │ ├── ingest.py # 文檔加載與切分 │ ├── retriever.py # 向量檢索 │ ├── generator.py # LLM生成回答 │ └── config.py # 配置管理 ├── tests/ │ ├── test_health.py │ ├── test_ingest.py │ ├── test_retriever.py │ └── test_api.py ├── docs/ # 測(cè)試用文檔 ├── requirements.txt └── README.md它沒(méi)有問(wèn)我任何問(wèn)題直接按照任務(wù)簡(jiǎn)報(bào)給的約束搭好了骨架然后開(kāi)始逐文件寫代碼。這里我截取一段它生成的檢索模塊核心代碼# app/retriever.py import chromadb from app.config import settings class Retriever: def __init__(self) - None: self.client chromadb.PersistentClient(pathsettings.CHROMA_PATH) self.collection self.client.get_or_create_collection( namedoc_snippets, metadata{hnsw:space: cosine} ) def add_snippets(self, ids: list[str], documents: list[str], metadatas: list[dict]) - None: self.collection.upsert( idsids, documentsdocuments, metadatasmetadatas ) def search(self, query: str, top_k: int 4): result self.collection.query( query_texts[query], n_resultstop_k, include[documents, metadatas, distances] ) return result這段代碼雖然不是多復(fù)雜但它用到了持久化向量存儲(chǔ)、cosine距離、upsert操作基本是當(dāng)前RAG工程的標(biāo)準(zhǔn)寫法。Agent能夠生成這種代碼不稀奇稀奇的是它接下來(lái)知道自己要去跑測(cè)試而不是把代碼丟給我就完事。3.3 第三步自主運(yùn)行與調(diào)試Agent寫完第一批文件后自動(dòng)在終端里執(zhí)行了這么一串命令cd /workspace/doc-qa python -m venv .venv source .venv/bin/activate pip install -r requirements.txt pytest tests/ -v --tbshort第一次運(yùn)行不出意外地掛了。測(cè)試失敗信息顯示test_retriever.py里調(diào)用的get_or_create_collection和已安裝的Chroma版本行為不一致舊版本需要傳embedding_function參數(shù)新版本默認(rèn)用了某個(gè)內(nèi)置模型導(dǎo)致維度不匹配。這里我發(fā)現(xiàn)一個(gè)很關(guān)鍵的設(shè)計(jì)Agent能讀取終端返回的完整輸出流包括stderr里的紅色traceback然后根據(jù)這些報(bào)錯(cuò)信息去改代碼或調(diào)整依賴版本。它幾秒后給出了解決方案把依賴版本鎖定到兼容區(qū)間chromadb0.4.15,0.5然后重新執(zhí)行了安裝和測(cè)試。經(jīng)過(guò)三輪“寫代碼—跑測(cè)試—看報(bào)錯(cuò)—改代碼”的循環(huán)測(cè)試全部通過(guò)。我全程沒(méi)有碰鍵盤。這個(gè)自主調(diào)試的過(guò)程說(shuō)真的比看到它一次寫出完美代碼更令我震撼因?yàn)檫@才是真實(shí)工程開(kāi)發(fā)的狀態(tài)沒(méi)有人能一次寫對(duì)但能做到快速定位、快速修正就是生產(chǎn)力。3.4 第四步部署上線測(cè)試通過(guò)后Agent沒(méi)有停。它自動(dòng)生成了Dockerfile和docker-compose.yml把模型服務(wù)也編排了進(jìn)去。最終部署后我用到這幾個(gè)文件也沒(méi)改Agent生成的docker-compose長(zhǎng)這樣services: embedding: image: ghcr.io/ollama/ollama:latest command: serve volumes: - ollama_data:/root/.ollama api: build: . ports: - 8000:8000 environment: - CHROMA_PATH/data/chroma - LLM_BASE_URLhttp://embedding:11434/v1 - LLM_MODELqwen2.5:7b volumes: - ./data:/data depends_on: - embedding部署完成后Agent自己執(zhí)行了冒煙測(cè)試用curl請(qǐng)求了/health接口又向/ask接口提了一個(gè)和測(cè)試文檔內(nèi)容相關(guān)的問(wèn)題驗(yàn)證返回結(jié)果里包含預(yù)期內(nèi)容。我是在它全部完成之后才打開(kāi)瀏覽器輸入http://服務(wù)器IP:8000/docs看到了FastAPI自動(dòng)生成的Swagger文檔頁(yè)面。那一刻我是真的有點(diǎn)恍惚這個(gè)應(yīng)用雖然不算復(fù)雜但它是AI從零到一自己構(gòu)建、自己調(diào)試、自己部署上線的這就是“有人做出來(lái)了”最直觀的證明。4. 一路上踩過(guò)的坑與排查技巧實(shí)錄4.1 AI“自嗨式開(kāi)發(fā)”怎么防我實(shí)操中第一個(gè)遇到的坑是Agent很容易陷入“自嗨式開(kāi)發(fā)”。什么意思就是它不停寫代碼、不停生成文件但從不主動(dòng)運(yùn)行驗(yàn)證最后交給你一堆根本跑不起來(lái)的東西。這在早期的Agent框架里特別常見(jiàn)OpenAI的Codex和AutoGPT都有這個(gè)問(wèn)題。解決辦法是在任務(wù)簡(jiǎn)報(bào)里寫死循環(huán)規(guī)則每完成一個(gè)模塊必須運(yùn)行對(duì)應(yīng)的測(cè)試不通過(guò)就不允許進(jìn)入下一個(gè)模塊所有命令必須在終端里真實(shí)執(zhí)行不允許模擬任何依賴變更后都要重新跑全量測(cè)試。我后來(lái)就給Agent加了一個(gè)“強(qiáng)制驗(yàn)證”工具所有寫文件操作之后都要跟著執(zhí)行一個(gè)狀態(tài)檢查做不到就報(bào)錯(cuò)逼它遵守紀(jì)律。另一個(gè)細(xì)節(jié)是輪次上限。Agent一旦陷入反復(fù)改同一個(gè)bug的情況會(huì)無(wú)限消耗token。我會(huì)在框架里設(shè)定最大迭代次數(shù)比如20輪。超過(guò)之后Agent會(huì)被要求停下來(lái)輸出“問(wèn)題摘要”和“建議人工介入點(diǎn)”由我來(lái)決定是繼續(xù)還是換思路。實(shí)測(cè)下來(lái)大多數(shù)問(wèn)題在10輪內(nèi)都能解決20輪基本是兜底。4.2 依賴地獄與版本飛鏢RAG相關(guān)的Python生態(tài)版本沖突是重災(zāi)區(qū)。Chroma、pydantic、fastapi、embedding模型之間經(jīng)常出現(xiàn)“明明前幾天還能跑今天重新安裝就報(bào)錯(cuò)”的情況。Agents自動(dòng)裝依賴時(shí)往往會(huì)選擇最新版本結(jié)果往往觸發(fā)各種兼容性問(wèn)題。我踩過(guò)一個(gè)特別典型的坑Chroma對(duì)pydantic的版本要求很嚴(yán)格如果系統(tǒng)里已經(jīng)裝了一個(gè)較新的pydanticChroma導(dǎo)入時(shí)直接拋出“無(wú)法從pydantic導(dǎo)入字段”之類的錯(cuò)誤。第一次跑的時(shí)候Agent傻傻地試了五六種解決方法最后才意識(shí)到應(yīng)該用虛擬環(huán)境并鎖定版本。這個(gè)坑我現(xiàn)在已經(jīng)有了一套標(biāo)準(zhǔn)動(dòng)作盡量用uv pip compile生成鎖文件鎖定所有傳遞依賴版本。所有依賴安裝都在項(xiàng)目自己的虛擬環(huán)境或容器內(nèi)進(jìn)行絕不使用全局環(huán)境。涉及AI應(yīng)用時(shí)優(yōu)先讓Agent參考項(xiàng)目模板里的requirements版本而不是自己盲猜最新版。遇到版本沖突先讓Agent檢查所有依賴的聲明約束再?zèng)Q定升級(jí)還是降級(jí)不要一次改多個(gè)包。有個(gè)細(xì)節(jié)值得單獨(dú)提一句chromadb在0.4.x和0.5.x之間的存儲(chǔ)格式不兼容如果你中途升級(jí)了版本舊的持久化數(shù)據(jù)可能直接沒(méi)法讀取。所以一旦項(xiàng)目開(kāi)始跑就不要頻繁改向量庫(kù)的主版本這個(gè)教訓(xùn)我?guī)痛蠹也冗^(guò)了。4.3 成本與時(shí)間失控AI Agent的token消耗非常驚人尤其是讓它“想清楚了再干”的模式。有一次我扔給它一個(gè)中等復(fù)雜度的任務(wù)讓它先做詳細(xì)設(shè)計(jì)再寫代碼結(jié)果光設(shè)計(jì)階段就花了接近兩萬(wàn)token最后寫代碼反而只用了八千。這種消耗不完全是浪費(fèi)但規(guī)劃部分過(guò)長(zhǎng)了確實(shí)是一種成本失控。我的控制策略是這樣的把任務(wù)拆分不要一次性讓Agent完成整個(gè)大項(xiàng)目而是分模塊、分階段提交。簡(jiǎn)單但重復(fù)的工作比如生成單元測(cè)試模板、寫DTO類可以切到本地小模型執(zhí)行復(fù)雜規(guī)劃和重構(gòu)才用云端大模型。在Agent框架的每次調(diào)用里都設(shè)置max_tokens上限防止一次生成超長(zhǎng)但不必要的內(nèi)容。監(jiān)控token消耗設(shè)一個(gè)硬預(yù)算比如“整個(gè)任務(wù)最多消耗30萬(wàn)token”到了以后強(qiáng)制停止并輸出階段性成果。時(shí)間失控也值得注意。Agent在等待模型返回時(shí)如果遇到網(wǎng)絡(luò)超時(shí)很多框架會(huì)直接判定失敗導(dǎo)致整個(gè)任務(wù)反復(fù)從頭開(kāi)始。我一般會(huì)讓Agent框架內(nèi)置重試機(jī)制但重試次數(shù)不要超過(guò)3次避免在一個(gè)僵死的請(qǐng)求上無(wú)限等待。4.4 安全與合規(guī)底線現(xiàn)在市面上有一些打著“無(wú)限制”“無(wú)審核”旗號(hào)的AI工具我個(gè)人是不推薦把這類工具引入工程環(huán)境的。Agent本身就是高風(fēng)險(xiǎn)組件它既能寫代碼又能執(zhí)行命令如果再用“無(wú)限制”的思路去使用跟把生產(chǎn)服務(wù)器的鑰匙掛在門口沒(méi)有區(qū)別。我在實(shí)踐中總結(jié)出幾條安全紅線希望在工程化AI Agent時(shí)能守住Agent運(yùn)行環(huán)境與生產(chǎn)環(huán)境嚴(yán)格隔離Agent只能操作指定的工作目錄不能訪問(wèn)系統(tǒng)目錄、密鑰、數(shù)據(jù)庫(kù)地址。所有Agent生成的代碼在合并到主分支前必須有真人評(píng)審。這是流程底線不是效率問(wèn)題。Agent執(zhí)行任何安裝類命令前要彈出“執(zhí)行確認(rèn)”鉤子尤其是在非容器環(huán)境里。日志記錄Agent的每一步操作方便事后審計(jì)。你永遠(yuǎn)不知道它會(huì)在第幾輪迭代里做出什么奇怪操作。對(duì)接企業(yè)數(shù)據(jù)時(shí)要提前給Agent配置最小權(quán)限不能因?yàn)椤八茿I”就讓它接觸所有數(shù)據(jù)。說(shuō)得直接一點(diǎn)AI造AI要想進(jìn)生產(chǎn)環(huán)境“有審核、有護(hù)欄”是基本前提這不應(yīng)該成為妥協(xié)項(xiàng)。一個(gè)能自己跑代碼的Agent必須有比人類員工更嚴(yán)格的權(quán)限管控因?yàn)槲覀冞€無(wú)法完全預(yù)測(cè)它在邊界條件下的行為。5. 冷靜看待“AI造AI”邊界、收益與工程師的新角色5.1 現(xiàn)階段能做什么、不能做什么這次實(shí)踐跑通之后我并沒(méi)有整天喊“AI要替代程序員了”反而對(duì)這件事的邊界更清楚了?，F(xiàn)階段AI Agent能做的是那些需求明確、驗(yàn)證方式清晰、技術(shù)棧成熟的開(kāi)發(fā)任務(wù)。比如開(kāi)發(fā)一個(gè)CRUD管理后臺(tái)、寫一個(gè)模型推理服務(wù)、生成單元測(cè)試、修復(fù)編譯錯(cuò)誤、編寫部署腳本這些事它做得又快又穩(wěn)效率普遍是純?nèi)斯さ暮脦妆?。但它目前還做不好的事情也很明確。第一它不理解模糊的業(yè)務(wù)意圖。你跟它說(shuō)“給客戶做一個(gè)更好的體驗(yàn)”它不知道“更好”具體指什么需要你把需求翻譯成可驗(yàn)證的指標(biāo)。第二它在做架構(gòu)權(quán)衡時(shí)經(jīng)常給出平庸的方案。它不是不會(huì)選型而是缺乏對(duì)業(yè)務(wù)生命周期的判斷容易選擇短期寫著爽但長(zhǎng)期維護(hù)困難的方案。第三它對(duì)自己的輸出質(zhì)量有過(guò)度自信如果不強(qiáng)制驗(yàn)證你拿到手的東西質(zhì)量是完全不可控的。所以我的判斷是AI造AI在工程層面已經(jīng)是真命題但它造的更多是“能工作的AI應(yīng)用”而不是“高瞻遠(yuǎn)矚的AI架構(gòu)”。工程師的價(jià)值不在于和AI比寫代碼速度快而在于定義邊界、做出取舍、判斷什么叫“足夠好”。5.2 工程師如何與AI協(xié)同既然AI能承擔(dān)越來(lái)越多的開(kāi)發(fā)執(zhí)行那工程師的新定位是什么我的觀察是工程師正在從“實(shí)現(xiàn)者”變成“驗(yàn)收者架構(gòu)師安全閘門”。我們不再需要把每個(gè)接口都手敲一遍但我們需要設(shè)計(jì)清楚系統(tǒng)邊界、任務(wù)流程和驗(yàn)收標(biāo)準(zhǔn)。幾個(gè)實(shí)戰(zhàn)建議供參考任務(wù)拆解粒度要小。我建議把一個(gè)大項(xiàng)目拆成“每個(gè)子任務(wù)能在30分鐘內(nèi)驗(yàn)證結(jié)果”的粒度。任務(wù)越小AI的失控概率越低。驗(yàn)收標(biāo)準(zhǔn)一定要可執(zhí)行。不要寫“性能要好”這種話要寫“首頁(yè)接口在100并發(fā)下P95延遲低于300ms”。強(qiáng)制AI先生成測(cè)試再寫實(shí)現(xiàn)。測(cè)試即需求說(shuō)明書對(duì)AI的約束作用立竿見(jiàn)影。用Git管理AI的所有產(chǎn)出。每次Agent修改代碼都生成獨(dú)立分支方便回溯和評(píng)審。其中“先生成測(cè)試再寫實(shí)現(xiàn)”這個(gè)技巧我特別想強(qiáng)調(diào)。讓AI自己寫測(cè)試實(shí)際上是逼它先思考“這段代碼該怎么定義正確”而不是急著堆功能。實(shí)測(cè)下來(lái)用這個(gè)流程能讓AI交付代碼的通過(guò)率提升一半以上而且返工次數(shù)明顯減少。5.3 下一步可以延伸的方向這次跑通的是單Agent完成一個(gè)小型AI應(yīng)用。再往下延伸有幾個(gè)方向我判斷會(huì)很快成熟。第一個(gè)是多Agent協(xié)作。讓一個(gè)Agent專門寫代碼另一個(gè)Agent專門做代碼評(píng)審和測(cè)試設(shè)計(jì)兩個(gè)Agent相互制約質(zhì)量會(huì)明顯高于單Agent。已經(jīng)有團(tuán)隊(duì)用這種方式跑通了中等復(fù)雜度的項(xiàng)目效果很可觀。第二個(gè)是AI Agent與AutoML的結(jié)合?，F(xiàn)在的Agent能寫訓(xùn)練腳本但超參搜索、模型選擇、效果評(píng)估這些還是靠人工在管。如果把主動(dòng)學(xué)習(xí)和Agent結(jié)合起來(lái)讓AI自己去看指標(biāo)曲線、自己調(diào)整訓(xùn)練參數(shù)那才是真正意義上的“AI訓(xùn)練AI”。第三個(gè)是Agent接入企業(yè)級(jí)AI應(yīng)用開(kāi)發(fā)平臺(tái)。比如Spring AI目前已經(jīng)在Java生態(tài)里提供了一套成熟的AI應(yīng)用抽象如果你所在團(tuán)隊(duì)是Java技術(shù)?？梢曰赟pring AI構(gòu)建自己的AI服務(wù)再讓Agent利用這些組件做開(kāi)發(fā)。這比從零搭建一套Agent工具鏈要省事得多。第四個(gè)是把Agent用于AI測(cè)試。我們團(tuán)隊(duì)已經(jīng)在用Agent自動(dòng)生成AI應(yīng)用的測(cè)試用例、生成badcase數(shù)據(jù)、做回歸驗(yàn)證。這個(gè)方向非常實(shí)用因?yàn)锳I應(yīng)用的不確定性很高人工測(cè)試根本覆蓋不過(guò)來(lái)讓AI測(cè)試AI閉環(huán)剛好。我個(gè)人看法是AI Agent會(huì)先從“完成獨(dú)立小任務(wù)”進(jìn)化到“參與復(fù)雜項(xiàng)目的完整生命周期”但這個(gè)過(guò)程需要大量的工程注入不是模型越強(qiáng)就自動(dòng)發(fā)生的。它需要工具鏈、流程、評(píng)估體系、安全機(jī)制一起跟上這也是接下來(lái)一兩年AI infra方向最值得投入的地方。最后再分享一個(gè)我在這次實(shí)踐里發(fā)現(xiàn)的小技巧如果條件允許讓Agent在寫代碼之前先把項(xiàng)目的README寫到一半只描述完項(xiàng)目定位和快速開(kāi)始然后逼它自己把剩余部分補(bǔ)完。這個(gè)辦法看似繞路但效果出奇的好因?yàn)樗艿贡艫I在動(dòng)手編碼前就建立起項(xiàng)目整體的邏輯地圖。你也不妨在自己團(tuán)隊(duì)的Agent工作流里試試這一手。 AI造AI實(shí)戰(zhàn)：讓Agent自主開(kāi)發(fā)RAG問(wèn)答機(jī)器人的全記錄
1. “AI造AI”到底在造什么1.1 先厘清概念A(yù)I造AI不等于AI自我進(jìn)化最近半年“AI能不能自己造AI”這個(gè)問(wèn)題在開(kāi)發(fā)者圈子里被反復(fù)吵上熱搜吵架的雙方經(jīng)常根本不是在聊同一件事。有人理解的“造AI”是“讓AI設(shè)計(jì)出比自身更聰明的下一代AI”這是AGI層面的問(wèn)題現(xiàn)階段確實(shí)做不到而有人理解的“造AI”是“讓AI去寫AI應(yīng)用、訓(xùn)練腳本、推理服務(wù)、部署配置”這個(gè)事不僅已經(jīng)有人做出來(lái)了而且做出來(lái)的效果已經(jīng)可以進(jìn)生產(chǎn)環(huán)境用了。我自己最近就干了一件挺有儀式感的事扔給一個(gè)AI Agent一份任務(wù)簡(jiǎn)報(bào)讓它從零開(kāi)始開(kāi)發(fā)一個(gè)“產(chǎn)品文檔RAG問(wèn)答機(jī)器人”——包含后端接口、向量檢索、模型接入、前端頁(yè)面、Docker部署最后Agent自己跑測(cè)試、自己修bug、自己把服務(wù)拉起來(lái)我用瀏覽器訪問(wèn)時(shí)發(fā)現(xiàn)頁(yè)面都能正常出來(lái)。整個(gè)過(guò)程里我只做了三件事寫清楚需求、盯著它別偏、最后做驗(yàn)收。所以你看如果我們把“AI造AI”定義成“AI作為工程師完成AI應(yīng)用的設(shè)計(jì)、開(kāi)發(fā)和部署”那這個(gè)標(biāo)題沒(méi)什么可吵的答案就是“能”。它不是科幻是工程效率的一次實(shí)實(shí)在在的突破。1.2 為什么爭(zhēng)議這么大能力邊界與想象力的錯(cuò)位爭(zhēng)議大的核心原因是“造AI”這個(gè)詞太容易被過(guò)度解讀。網(wǎng)上討論AI自我復(fù)制、AI自行進(jìn)化天然自帶流量但落到工程現(xiàn)場(chǎng)我們關(guān)心的其實(shí)是更具體的問(wèn)題AI能不能把一份模糊需求變成可運(yùn)行的代碼能不能在編譯報(bào)錯(cuò)時(shí)自己定位問(wèn)題能不能把一個(gè)模型推理服務(wù)完整部署上線從我自己實(shí)操以及身邊團(tuán)隊(duì)的使用情況看答案是明確的“能”只是有條件。條件是任務(wù)邊界要清晰執(zhí)行環(huán)境要給足反饋回路要完整人工審核不能缺位。AI Agent不是神仙它更像一個(gè)執(zhí)行力極強(qiáng)但需要環(huán)境配合的初級(jí)工程師。給它一臺(tái)能跑命令的電腦、一套能回傳報(bào)錯(cuò)信息的工具鏈、一份夠具體的需求說(shuō)明它就能像人一樣一個(gè)文件一個(gè)文件把項(xiàng)目搭起來(lái)再通過(guò)運(yùn)行結(jié)果倒逼自己修正。這篇文章我就把自己做“AI自己造AI”的完整過(guò)程、技術(shù)選型、踩坑記錄和邊界思考全部攤開(kāi)。適合誰(shuí)看想用AI Agent提升開(kāi)發(fā)效率的工程師、正在評(píng)估“AI能否承擔(dān)部分研發(fā)工作”的技術(shù)管理者以及單純好奇AI能力邊界的產(chǎn)品和測(cè)試同學(xué)。2. 工具選型讓AI“自己動(dòng)手”需要怎樣的底座2.1 核心組件大模型 Agent框架 執(zhí)行環(huán)境想讓AI Agent真正完成開(kāi)發(fā)任務(wù)光有一個(gè)聊天窗口遠(yuǎn)遠(yuǎn)不夠。你需要三個(gè)東西協(xié)同工作一個(gè)會(huì)思考的大模型、一套能調(diào)度工具的Agent框架、一個(gè)允許Agent動(dòng)手操作的真實(shí)環(huán)境。大模型是“大腦”。最好選代碼生成能力強(qiáng)的模型同時(shí)要求支持長(zhǎng)上下文和工具調(diào)用。我這次的主力模型是支持Function Calling的版本規(guī)劃任務(wù)時(shí)用它的強(qiáng)推理能力寫代碼時(shí)用它的代碼補(bǔ)全能力。如果你的環(huán)境允許也可以考慮本地部署的開(kāi)源模型比如用Ollama跑Qwen系列這樣簡(jiǎn)單模塊可以交給本地模型執(zhí)行復(fù)雜規(guī)劃和設(shè)計(jì)再交給云端模型成本會(huì)更可控。Agent框架是“手和腳”。常見(jiàn)的開(kāi)源方案有LangGraph、AutoGPT也有偏應(yīng)用層的DifyJava生態(tài)里還有Spring AI。它們本質(zhì)都是給AI提供文件讀寫、終端執(zhí)行、網(wǎng)頁(yè)訪問(wèn)、工具調(diào)用等能力并維護(hù)“規(guī)劃—執(zhí)行—觀察—再規(guī)劃”的循環(huán)。如果你只是做一個(gè)快速驗(yàn)證用LangGraph搭一個(gè)最小循環(huán)就夠了如果是企業(yè)內(nèi)部落地我更推薦Dify或自研一套輕量框架便于控制權(quán)限和審計(jì)。這次演示我用的就是基于LangGraph改的極簡(jiǎn)Agent總共就兩層主Agent負(fù)責(zé)任務(wù)拆解工具層負(fù)責(zé)讀寫文件和執(zhí)行shell命令。執(zhí)行環(huán)境是“工地”。這也是新手最容易低估的部分。AI Agent必須能真正跑在沙箱環(huán)境里能夠執(zhí)行pip install、運(yùn)行pytest、讀取報(bào)錯(cuò)輸出才能形成“寫代碼—看結(jié)果—改代碼”的閉環(huán)。我用的是一臺(tái)帶Docker的Linux服務(wù)器所有操作都在容器里進(jìn)行宿主機(jī)只掛載了一個(gè)工作目錄。這樣既給了Agent足夠的自由度又不至于讓它碰到系統(tǒng)關(guān)鍵目錄。注意給Agent的“工地”一定要隔離。它會(huì)在里面執(zhí)行任意命令所以絕不能和生產(chǎn)環(huán)境、密鑰文件混在一起。用容器隔離是底線不是可選項(xiàng)。2.2 為什么不是“一句提示詞”就能完成現(xiàn)在很多人習(xí)慣在ChatGPT里發(fā)一句“幫我寫一個(gè)RAG機(jī)器人”然后復(fù)制粘貼代碼。這不算AI造AI這只是AI當(dāng)百度用。真正的AI Agent開(kāi)發(fā)要求AI自己管理整個(gè)項(xiàng)目生命周期它要知道該建哪些文件、依賴裝什么、程序怎么跑、報(bào)錯(cuò)怎么修。我嘗試過(guò)一個(gè)對(duì)比場(chǎng)景。同一個(gè)小型情感分析API讓普通聊天模型“一次輸出”和讓Agent“自主迭代開(kāi)發(fā)”是兩種完全不同的結(jié)果。前者會(huì)給你一個(gè)看起來(lái)完整、但大概率跑不起來(lái)的代碼片段后者會(huì)自己創(chuàng)建虛擬環(huán)境、安裝依賴、啟動(dòng)服務(wù)、用curl打接口驗(yàn)證最后交付的是一個(gè)實(shí)際上線可用的服務(wù)。差別在哪差別就在于有沒(méi)有“運(yùn)行反饋”。所以我把這次實(shí)踐的關(guān)鍵總結(jié)成一句話AI造AI的本質(zhì)不是AI一口氣寫出完整程序而是AI在一個(gè)能自我驗(yàn)證的環(huán)境里通過(guò)多輪試錯(cuò)把程序改到能跑。這就意味著工程約束比模型本身的智商更重要。你得把任務(wù)目標(biāo)量化、把驗(yàn)收標(biāo)準(zhǔn)寫清楚、把迭代輪次卡住AI才能真正為你創(chuàng)造價(jià)值而不是給你制造一堆需要返工的半成品。3. 實(shí)操記錄我是怎么讓AI Agent從0到1做一個(gè)RAG問(wèn)答機(jī)器人3.1 第一步給AI寫一份“任務(wù)簡(jiǎn)報(bào)”這次我選了一個(gè)很典型的AI應(yīng)用場(chǎng)景產(chǎn)品文檔問(wèn)答機(jī)器人。用戶傳入一段問(wèn)題系統(tǒng)從本地文檔庫(kù)里檢索相關(guān)資料然后讓大模型基于檢索結(jié)果生成回答。這類應(yīng)用是RAG檢索增強(qiáng)生成的經(jīng)典落地形態(tài)也是AI應(yīng)用開(kāi)發(fā)里最有代表性的“AI工程”活。我先把任務(wù)簡(jiǎn)報(bào)寫好簡(jiǎn)報(bào)里寫明了技術(shù)棧、目標(biāo)接口、驗(yàn)收標(biāo)準(zhǔn)和約束條件。如果你也想復(fù)現(xiàn)可以直接參考這份結(jié)構(gòu)項(xiàng)目目標(biāo)基于產(chǎn)品文檔構(gòu)建一個(gè)RAG問(wèn)答API支持上傳文檔、檢索、問(wèn)答三個(gè)接口。技術(shù)棧要求Python 3.11、FastAPI、Chroma向量數(shù)據(jù)庫(kù)、一個(gè)Embedding模型、一個(gè)LLM接口我用的是兼容OpenAI格式的本地模型服務(wù)。功能范圍上傳PDF/Markdown時(shí)自動(dòng)切分問(wèn)答接口先檢索top-k相關(guān)片段再讓大模型生成答案結(jié)果返回引用來(lái)源。明確“不要做”不要做用戶登錄、不要做前端復(fù)雜交互、不要做權(quán)限管理。驗(yàn)收標(biāo)準(zhǔn)/upload接口能上傳并檢索/ask接口能基于文檔內(nèi)容回答問(wèn)題/health接口返回200每個(gè)模塊都要有測(cè)試。運(yùn)行約束所有命令必須在項(xiàng)目虛擬環(huán)境內(nèi)執(zhí)行目錄結(jié)構(gòu)遵循FastAPI官方最佳實(shí)踐。你可能會(huì)問(wèn)為什么非要寫這么細(xì)因?yàn)锳I Agent在面對(duì)模糊任務(wù)時(shí)最大的風(fēng)險(xiǎn)是自由發(fā)揮。它會(huì)給你加一堆花哨但沒(méi)用的功能也會(huì)忽略你真正關(guān)心的細(xì)節(jié)。任務(wù)簡(jiǎn)報(bào)的價(jià)值就是給Agent劃定邊界讓它把精力集中在核心交付上。這個(gè)步驟花了我大概半小時(shí)但它決定了后面幾小時(shí)的輸出質(zhì)量。3.2 第二步Agent從規(guī)劃到動(dòng)手任務(wù)簡(jiǎn)報(bào)寫好之后我把Agent啟動(dòng)它會(huì)先輸出一份項(xiàng)目規(guī)劃。這一步真的很有意思它產(chǎn)生了這樣一個(gè)目錄結(jié)構(gòu)doc-qa/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI入口 │ ├── models.py # 數(shù)據(jù)模型 │ ├── ingest.py # 文檔加載與切分 │ ├── retriever.py # 向量檢索 │ ├── generator.py # LLM生成回答 │ └── config.py # 配置管理 ├── tests/ │ ├── test_health.py │ ├── test_ingest.py │ ├── test_retriever.py │ └── test_api.py ├── docs/ # 測(cè)試用文檔 ├── requirements.txt └── README.md它沒(méi)有問(wèn)我任何問(wèn)題直接按照任務(wù)簡(jiǎn)報(bào)給的約束搭好了骨架然后開(kāi)始逐文件寫代碼。這里我截取一段它生成的檢索模塊核心代碼# app/retriever.py import chromadb from app.config import settings class Retriever: def __init__(self) - None: self.client chromadb.PersistentClient(pathsettings.CHROMA_PATH) self.collection self.client.get_or_create_collection( namedoc_snippets, metadata{hnsw:space: cosine} ) def add_snippets(self, ids: list[str], documents: list[str], metadatas: list[dict]) - None: self.collection.upsert( idsids, documentsdocuments, metadatasmetadatas ) def search(self, query: str, top_k: int 4): result self.collection.query( query_texts[query], n_resultstop_k, include[documents, metadatas, distances] ) return result這段代碼雖然不是多復(fù)雜但它用到了持久化向量存儲(chǔ)、cosine距離、upsert操作基本是當(dāng)前RAG工程的標(biāo)準(zhǔn)寫法。Agent能夠生成這種代碼不稀奇稀奇的是它接下來(lái)知道自己要去跑測(cè)試而不是把代碼丟給我就完事。3.3 第三步自主運(yùn)行與調(diào)試Agent寫完第一批文件后自動(dòng)在終端里執(zhí)行了這么一串命令cd /workspace/doc-qa python -m venv .venv source .venv/bin/activate pip install -r requirements.txt pytest tests/ -v --tbshort第一次運(yùn)行不出意外地掛了。測(cè)試失敗信息顯示test_retriever.py里調(diào)用的get_or_create_collection和已安裝的Chroma版本行為不一致舊版本需要傳embedding_function參數(shù)新版本默認(rèn)用了某個(gè)內(nèi)置模型導(dǎo)致維度不匹配。這里我發(fā)現(xiàn)一個(gè)很關(guān)鍵的設(shè)計(jì)Agent能讀取終端返回的完整輸出流包括stderr里的紅色traceback然后根據(jù)這些報(bào)錯(cuò)信息去改代碼或調(diào)整依賴版本。它幾秒后給出了解決方案把依賴版本鎖定到兼容區(qū)間chromadb0.4.15,0.5然后重新執(zhí)行了安裝和測(cè)試。經(jīng)過(guò)三輪“寫代碼—跑測(cè)試—看報(bào)錯(cuò)—改代碼”的循環(huán)測(cè)試全部通過(guò)。我全程沒(méi)有碰鍵盤。這個(gè)自主調(diào)試的過(guò)程說(shuō)真的比看到它一次寫出完美代碼更令我震撼因?yàn)檫@才是真實(shí)工程開(kāi)發(fā)的狀態(tài)沒(méi)有人能一次寫對(duì)但能做到快速定位、快速修正就是生產(chǎn)力。3.4 第四步部署上線測(cè)試通過(guò)后Agent沒(méi)有停。它自動(dòng)生成了Dockerfile和docker-compose.yml把模型服務(wù)也編排了進(jìn)去。最終部署后我用到這幾個(gè)文件也沒(méi)改Agent生成的docker-compose長(zhǎng)這樣services: embedding: image: ghcr.io/ollama/ollama:latest command: serve volumes: - ollama_data:/root/.ollama api: build: . ports: - 8000:8000 environment: - CHROMA_PATH/data/chroma - LLM_BASE_URLhttp://embedding:11434/v1 - LLM_MODELqwen2.5:7b volumes: - ./data:/data depends_on: - embedding部署完成后Agent自己執(zhí)行了冒煙測(cè)試用curl請(qǐng)求了/health接口又向/ask接口提了一個(gè)和測(cè)試文檔內(nèi)容相關(guān)的問(wèn)題驗(yàn)證返回結(jié)果里包含預(yù)期內(nèi)容。我是在它全部完成之后才打開(kāi)瀏覽器輸入http://服務(wù)器IP:8000/docs看到了FastAPI自動(dòng)生成的Swagger文檔頁(yè)面。那一刻我是真的有點(diǎn)恍惚這個(gè)應(yīng)用雖然不算復(fù)雜但它是AI從零到一自己構(gòu)建、自己調(diào)試、自己部署上線的這就是“有人做出來(lái)了”最直觀的證明。4. 一路上踩過(guò)的坑與排查技巧實(shí)錄4.1 AI“自嗨式開(kāi)發(fā)”怎么防我實(shí)操中第一個(gè)遇到的坑是Agent很容易陷入“自嗨式開(kāi)發(fā)”。什么意思就是它不停寫代碼、不停生成文件但從不主動(dòng)運(yùn)行驗(yàn)證最后交給你一堆根本跑不起來(lái)的東西。這在早期的Agent框架里特別常見(jiàn)OpenAI的Codex和AutoGPT都有這個(gè)問(wèn)題。解決辦法是在任務(wù)簡(jiǎn)報(bào)里寫死循環(huán)規(guī)則每完成一個(gè)模塊必須運(yùn)行對(duì)應(yīng)的測(cè)試不通過(guò)就不允許進(jìn)入下一個(gè)模塊所有命令必須在終端里真實(shí)執(zhí)行不允許模擬任何依賴變更后都要重新跑全量測(cè)試。我后來(lái)就給Agent加了一個(gè)“強(qiáng)制驗(yàn)證”工具所有寫文件操作之后都要跟著執(zhí)行一個(gè)狀態(tài)檢查做不到就報(bào)錯(cuò)逼它遵守紀(jì)律。另一個(gè)細(xì)節(jié)是輪次上限。Agent一旦陷入反復(fù)改同一個(gè)bug的情況會(huì)無(wú)限消耗token。我會(huì)在框架里設(shè)定最大迭代次數(shù)比如20輪。超過(guò)之后Agent會(huì)被要求停下來(lái)輸出“問(wèn)題摘要”和“建議人工介入點(diǎn)”由我來(lái)決定是繼續(xù)還是換思路。實(shí)測(cè)下來(lái)大多數(shù)問(wèn)題在10輪內(nèi)都能解決20輪基本是兜底。4.2 依賴地獄與版本飛鏢RAG相關(guān)的Python生態(tài)版本沖突是重災(zāi)區(qū)。Chroma、pydantic、fastapi、embedding模型之間經(jīng)常出現(xiàn)“明明前幾天還能跑今天重新安裝就報(bào)錯(cuò)”的情況。Agents自動(dòng)裝依賴時(shí)往往會(huì)選擇最新版本結(jié)果往往觸發(fā)各種兼容性問(wèn)題。我踩過(guò)一個(gè)特別典型的坑Chroma對(duì)pydantic的版本要求很嚴(yán)格如果系統(tǒng)里已經(jīng)裝了一個(gè)較新的pydanticChroma導(dǎo)入時(shí)直接拋出“無(wú)法從pydantic導(dǎo)入字段”之類的錯(cuò)誤。第一次跑的時(shí)候Agent傻傻地試了五六種解決方法最后才意識(shí)到應(yīng)該用虛擬環(huán)境并鎖定版本。這個(gè)坑我現(xiàn)在已經(jīng)有了一套標(biāo)準(zhǔn)動(dòng)作盡量用uv pip compile生成鎖文件鎖定所有傳遞依賴版本。所有依賴安裝都在項(xiàng)目自己的虛擬環(huán)境或容器內(nèi)進(jìn)行絕不使用全局環(huán)境。涉及AI應(yīng)用時(shí)優(yōu)先讓Agent參考項(xiàng)目模板里的requirements版本而不是自己盲猜最新版。遇到版本沖突先讓Agent檢查所有依賴的聲明約束再?zèng)Q定升級(jí)還是降級(jí)不要一次改多個(gè)包。有個(gè)細(xì)節(jié)值得單獨(dú)提一句chromadb在0.4.x和0.5.x之間的存儲(chǔ)格式不兼容如果你中途升級(jí)了版本舊的持久化數(shù)據(jù)可能直接沒(méi)法讀取。所以一旦項(xiàng)目開(kāi)始跑就不要頻繁改向量庫(kù)的主版本這個(gè)教訓(xùn)我?guī)痛蠹也冗^(guò)了。4.3 成本與時(shí)間失控AI Agent的token消耗非常驚人尤其是讓它“想清楚了再干”的模式。有一次我扔給它一個(gè)中等復(fù)雜度的任務(wù)讓它先做詳細(xì)設(shè)計(jì)再寫代碼結(jié)果光設(shè)計(jì)階段就花了接近兩萬(wàn)token最后寫代碼反而只用了八千。這種消耗不完全是浪費(fèi)但規(guī)劃部分過(guò)長(zhǎng)了確實(shí)是一種成本失控。我的控制策略是這樣的把任務(wù)拆分不要一次性讓Agent完成整個(gè)大項(xiàng)目而是分模塊、分階段提交。簡(jiǎn)單但重復(fù)的工作比如生成單元測(cè)試模板、寫DTO類可以切到本地小模型執(zhí)行復(fù)雜規(guī)劃和重構(gòu)才用云端大模型。在Agent框架的每次調(diào)用里都設(shè)置max_tokens上限防止一次生成超長(zhǎng)但不必要的內(nèi)容。監(jiān)控token消耗設(shè)一個(gè)硬預(yù)算比如“整個(gè)任務(wù)最多消耗30萬(wàn)token”到了以后強(qiáng)制停止并輸出階段性成果。時(shí)間失控也值得注意。Agent在等待模型返回時(shí)如果遇到網(wǎng)絡(luò)超時(shí)很多框架會(huì)直接判定失敗導(dǎo)致整個(gè)任務(wù)反復(fù)從頭開(kāi)始。我一般會(huì)讓Agent框架內(nèi)置重試機(jī)制但重試次數(shù)不要超過(guò)3次避免在一個(gè)僵死的請(qǐng)求上無(wú)限等待。4.4 安全與合規(guī)底線現(xiàn)在市面上有一些打著“無(wú)限制”“無(wú)審核”旗號(hào)的AI工具我個(gè)人是不推薦把這類工具引入工程環(huán)境的。Agent本身就是高風(fēng)險(xiǎn)組件它既能寫代碼又能執(zhí)行命令如果再用“無(wú)限制”的思路去使用跟把生產(chǎn)服務(wù)器的鑰匙掛在門口沒(méi)有區(qū)別。我在實(shí)踐中總結(jié)出幾條安全紅線希望在工程化AI Agent時(shí)能守住Agent運(yùn)行環(huán)境與生產(chǎn)環(huán)境嚴(yán)格隔離Agent只能操作指定的工作目錄不能訪問(wèn)系統(tǒng)目錄、密鑰、數(shù)據(jù)庫(kù)地址。所有Agent生成的代碼在合并到主分支前必須有真人評(píng)審。這是流程底線不是效率問(wèn)題。Agent執(zhí)行任何安裝類命令前要彈出“執(zhí)行確認(rèn)”鉤子尤其是在非容器環(huán)境里。日志記錄Agent的每一步操作方便事后審計(jì)。你永遠(yuǎn)不知道它會(huì)在第幾輪迭代里做出什么奇怪操作。對(duì)接企業(yè)數(shù)據(jù)時(shí)要提前給Agent配置最小權(quán)限不能因?yàn)椤八茿I”就讓它接觸所有數(shù)據(jù)。說(shuō)得直接一點(diǎn)AI造AI要想進(jìn)生產(chǎn)環(huán)境“有審核、有護(hù)欄”是基本前提這不應(yīng)該成為妥協(xié)項(xiàng)。一個(gè)能自己跑代碼的Agent必須有比人類員工更嚴(yán)格的權(quán)限管控因?yàn)槲覀冞€無(wú)法完全預(yù)測(cè)它在邊界條件下的行為。5. 冷靜看待“AI造AI”邊界、收益與工程師的新角色5.1 現(xiàn)階段能做什么、不能做什么這次實(shí)踐跑通之后我并沒(méi)有整天喊“AI要替代程序員了”反而對(duì)這件事的邊界更清楚了?，F(xiàn)階段AI Agent能做的是那些需求明確、驗(yàn)證方式清晰、技術(shù)棧成熟的開(kāi)發(fā)任務(wù)。比如開(kāi)發(fā)一個(gè)CRUD管理后臺(tái)、寫一個(gè)模型推理服務(wù)、生成單元測(cè)試、修復(fù)編譯錯(cuò)誤、編寫部署腳本這些事它做得又快又穩(wěn)效率普遍是純?nèi)斯さ暮脦妆?。但它目前還做不好的事情也很明確。第一它不理解模糊的業(yè)務(wù)意圖。你跟它說(shuō)“給客戶做一個(gè)更好的體驗(yàn)”它不知道“更好”具體指什么需要你把需求翻譯成可驗(yàn)證的指標(biāo)。第二它在做架構(gòu)權(quán)衡時(shí)經(jīng)常給出平庸的方案。它不是不會(huì)選型而是缺乏對(duì)業(yè)務(wù)生命周期的判斷容易選擇短期寫著爽但長(zhǎng)期維護(hù)困難的方案。第三它對(duì)自己的輸出質(zhì)量有過(guò)度自信如果不強(qiáng)制驗(yàn)證你拿到手的東西質(zhì)量是完全不可控的。所以我的判斷是AI造AI在工程層面已經(jīng)是真命題但它造的更多是“能工作的AI應(yīng)用”而不是“高瞻遠(yuǎn)矚的AI架構(gòu)”。工程師的價(jià)值不在于和AI比寫代碼速度快而在于定義邊界、做出取舍、判斷什么叫“足夠好”。5.2 工程師如何與AI協(xié)同既然AI能承擔(dān)越來(lái)越多的開(kāi)發(fā)執(zhí)行那工程師的新定位是什么我的觀察是工程師正在從“實(shí)現(xiàn)者”變成“驗(yàn)收者架構(gòu)師安全閘門”。我們不再需要把每個(gè)接口都手敲一遍但我們需要設(shè)計(jì)清楚系統(tǒng)邊界、任務(wù)流程和驗(yàn)收標(biāo)準(zhǔn)。幾個(gè)實(shí)戰(zhàn)建議供參考任務(wù)拆解粒度要小。我建議把一個(gè)大項(xiàng)目拆成“每個(gè)子任務(wù)能在30分鐘內(nèi)驗(yàn)證結(jié)果”的粒度。任務(wù)越小AI的失控概率越低。驗(yàn)收標(biāo)準(zhǔn)一定要可執(zhí)行。不要寫“性能要好”這種話要寫“首頁(yè)接口在100并發(fā)下P95延遲低于300ms”。強(qiáng)制AI先生成測(cè)試再寫實(shí)現(xiàn)。測(cè)試即需求說(shuō)明書對(duì)AI的約束作用立竿見(jiàn)影。用Git管理AI的所有產(chǎn)出。每次Agent修改代碼都生成獨(dú)立分支方便回溯和評(píng)審。其中“先生成測(cè)試再寫實(shí)現(xiàn)”這個(gè)技巧我特別想強(qiáng)調(diào)。讓AI自己寫測(cè)試實(shí)際上是逼它先思考“這段代碼該怎么定義正確”而不是急著堆功能。實(shí)測(cè)下來(lái)用這個(gè)流程能讓AI交付代碼的通過(guò)率提升一半以上而且返工次數(shù)明顯減少。5.3 下一步可以延伸的方向這次跑通的是單Agent完成一個(gè)小型AI應(yīng)用。再往下延伸有幾個(gè)方向我判斷會(huì)很快成熟。第一個(gè)是多Agent協(xié)作。讓一個(gè)Agent專門寫代碼另一個(gè)Agent專門做代碼評(píng)審和測(cè)試設(shè)計(jì)兩個(gè)Agent相互制約質(zhì)量會(huì)明顯高于單Agent。已經(jīng)有團(tuán)隊(duì)用這種方式跑通了中等復(fù)雜度的項(xiàng)目效果很可觀。第二個(gè)是AI Agent與AutoML的結(jié)合?，F(xiàn)在的Agent能寫訓(xùn)練腳本但超參搜索、模型選擇、效果評(píng)估這些還是靠人工在管。如果把主動(dòng)學(xué)習(xí)和Agent結(jié)合起來(lái)讓AI自己去看指標(biāo)曲線、自己調(diào)整訓(xùn)練參數(shù)那才是真正意義上的“AI訓(xùn)練AI”。第三個(gè)是Agent接入企業(yè)級(jí)AI應(yīng)用開(kāi)發(fā)平臺(tái)。比如Spring AI目前已經(jīng)在Java生態(tài)里提供了一套成熟的AI應(yīng)用抽象如果你所在團(tuán)隊(duì)是Java技術(shù)?？梢曰赟pring AI構(gòu)建自己的AI服務(wù)再讓Agent利用這些組件做開(kāi)發(fā)。這比從零搭建一套Agent工具鏈要省事得多。第四個(gè)是把Agent用于AI測(cè)試。我們團(tuán)隊(duì)已經(jīng)在用Agent自動(dòng)生成AI應(yīng)用的測(cè)試用例、生成badcase數(shù)據(jù)、做回歸驗(yàn)證。這個(gè)方向非常實(shí)用因?yàn)锳I應(yīng)用的不確定性很高人工測(cè)試根本覆蓋不過(guò)來(lái)讓AI測(cè)試AI閉環(huán)剛好。我個(gè)人看法是AI Agent會(huì)先從“完成獨(dú)立小任務(wù)”進(jìn)化到“參與復(fù)雜項(xiàng)目的完整生命周期”但這個(gè)過(guò)程需要大量的工程注入不是模型越強(qiáng)就自動(dòng)發(fā)生的。它需要工具鏈、流程、評(píng)估體系、安全機(jī)制一起跟上這也是接下來(lái)一兩年AI infra方向最值得投入的地方。最后再分享一個(gè)我在這次實(shí)踐里發(fā)現(xiàn)的小技巧如果條件允許讓Agent在寫代碼之前先把項(xiàng)目的README寫到一半只描述完項(xiàng)目定位和快速開(kāi)始然后逼它自己把剩余部分補(bǔ)完。這個(gè)辦法看似繞路但效果出奇的好因?yàn)樗艿贡艫I在動(dòng)手編碼前就建立起項(xiàng)目整體的邏輯地圖。你也不妨在自己團(tuán)隊(duì)的Agent工作流里試試這一手。