最近在做一個自動化文檔處理的內(nèi)部小項目發(fā)現(xiàn)一個很有意思的轉(zhuǎn)變。以前用大模型是“我問一句它答一句”現(xiàn)在把模型接進一個帶工具調(diào)用的循環(huán)里它開始自己決定下一步調(diào)用哪個函數(shù)、拿到結(jié)果后再判斷下一步走哪條路。這種變化不是模型變聰明了那么簡單而是整套使用方式從“伸手要答案”變成了“布置一個目標”。所以當“AI不再聽命令了它開始自己干活”這句話出現(xiàn)在眼前時我第一反應(yīng)是這說的不是某個新工具而是 AI Agent 這個概念終于從演示走向了工程實踐。但真正落地時你會發(fā)現(xiàn)AI 自己干活并不是魔法而是一套需要目標拆解、工具調(diào)用、狀態(tài)管理、失敗恢復(fù)、權(quán)限控制共同支撐的工程系統(tǒng)。這篇文章想聊的就是這件事。1. 先搞清楚“自己干活”到底指什么1.1 Chatbot 是在回答Agent 是在執(zhí)行很多人會把“能對話的 AI”和“會干活的 AI”搞混。你打開一個聊天窗口讓它生成一段文案、寫一段代碼、解釋一段報錯它都能做到。但這是“回答”不是“干活”。干活意味著你給一個目標它自己規(guī)劃路徑、調(diào)用外部工具、檢查中間結(jié)果、修正下一步動作最后交付一個結(jié)果。比如“幫我把這個 GitHub 倉庫的最近 10 條 commit 整理成一份周報并按模塊分類再生成一個 Markdown 文件”Chatbot 只能給你一段建議或者一段示例文本剩下的復(fù)制粘貼、獲取數(shù)據(jù)、生成文件都要你自己做。而 Agent 會嘗試通過工具調(diào)用去拉取 commit 列表、調(diào)用模型總結(jié)、寫文件最后給你輸出一個真實存在的文件。核心差異不在模型能力而在系統(tǒng)邊界。Chatbot 的邊界是“對話”Agent 的邊界是“任務(wù)”。這是“自己干活”的第一層含義。1.2 核心變化從“每一步都告訴它”到“我只給目標”過去用自動化腳本是人把每一步邏輯寫死。比如用 Python 拉取數(shù)據(jù)、寫文件流程是固定的。現(xiàn)在用 Agent人不需要把每一步都寫死只需要描述目標、提供工具清單讓模型自己決定調(diào)用順序。這聽起來很像“把控制權(quán)交給 AI”但工程上更準確的表述是把任務(wù)拆解從“寫代碼時確定”變成了“運行時動態(tài)決定”。舉個例子同樣是生成周報傳統(tǒng)腳本先 git log再分詞再套模板每一步都是 if-else。Agent模型先判斷“哦我需要獲取 commit 列表”于是調(diào)用git_log工具拿到列表后又判斷“內(nèi)容太長了我需要先過濾掉 merge commit”于是再調(diào)用git_parse最后判斷“生成 Markdown”然后調(diào)用write_file。這個流程不是預(yù)先寫死的而是模型根據(jù)工具返回結(jié)果動態(tài)生成的。這才叫“自己干活”。不過要注意這里的“自己”不是完全自主。Agent 的每一步行動仍然受系統(tǒng)設(shè)計約束能調(diào)用哪些工具、最多走多少步、哪些操作需要人工確認這些都是我們預(yù)先定義的。所以更準確地說它是在我們劃定的軌道里自主決策。2. 為什么是現(xiàn)在大模型和工程底座同時到位2.1 模型能力從“能對話”到“能遵循指令并調(diào)用工具”兩三年前想讓模型穩(wěn)定地給出一個“我要調(diào)用某個工具及參數(shù)”的 JSON都不是一件容易事。你構(gòu)想的 Agent 循環(huán)早就存在但模型經(jīng)常理解錯工具參數(shù)、忘記上下文、在復(fù)雜任務(wù)里跑偏?，F(xiàn)在的情況好了一些但也不是完全成熟。這里有兩個關(guān)鍵能力指令遵循能力模型能更準確地按照系統(tǒng)提示輸出結(jié)構(gòu)化指令比如{tool: get_commits, params: {repo: foo}}。工具調(diào)用能力平臺層面把“模型決定調(diào)工具”和“執(zhí)行工具返回結(jié)果”做成了標準協(xié)議比如 Function Calling、Tool Use開發(fā)者不用自己拼 prompt 解析文本模型直接返回結(jié)構(gòu)化調(diào)用請求。這兩個能力加在一起Agent 循環(huán)才變得可工程化。不是說模型已經(jīng)完美而是“容錯成本”降到了可以接受的范圍內(nèi)。2.2 工程底座任務(wù)編排、日志、消息隊列逐步補齊模型能力只是其中一半。另一個被很多人忽略的推動力是工程基礎(chǔ)設(shè)施的成熟。一個真正“自己干活”的 Agent背后需要像任務(wù)調(diào)度系統(tǒng)一樣的循環(huán)控制什么時候調(diào)用大模型什么時候調(diào)工具工具超時怎么辦模型返回格式不對怎么辦任務(wù)失敗要不要重試每一步的狀態(tài)記錄在哪里如何讓用戶看到中間進度任務(wù)中止邏輯是什么。這些不是模型解決的問題而是工程問題。以前這些都要從零搭很繁瑣。現(xiàn)在不少框架和平臺把循環(huán)控制、工具注冊、日志 trace、人工審核節(jié)點做成了現(xiàn)成模塊開發(fā)者只需要聚焦業(yè)務(wù)本身。這也是為什么最近一年 AI Agent 開發(fā)突然從“玩具”變成了“可落地項目”的原因之一。但我的經(jīng)驗是不要因為框架多就急著套用。先把最小循環(huán)跑通再逐步替換組件遠比一開始引入一個復(fù)雜編排系統(tǒng)要穩(wěn)。3. 從零搭一個“自己干活”的 Agent最小可運行示例3.1 場景定義自動生成項目周報我們用最經(jīng)典的場景來拆解讓 Agent 自動獲取倉庫 commit生成周報寫入本地文件。這個場景足夠小但覆蓋了 Agent 的核心問題感知外部數(shù)據(jù)、模型決策、調(diào)用工具、檢查結(jié)果、生成最終輸出。首先需要定義兩個工具get_commits(since_date, repo_path)拉取指定日期之后的提交列表。write_report(content, file_path)把內(nèi)容寫入 Markdown 文件。Agent 要做的就是根據(jù)用戶目標自己決定先調(diào)用哪個、怎么處理中間結(jié)果。從代碼結(jié)構(gòu)看核心是一個循環(huán)def agent_loop(user_goal, tools, max_steps10): messages [{role: user, content: user_goal}] for step in range(max_steps): response model_decision(messages, tools) # 情況一模型認為任務(wù)已完成返回最終答案 if response.is_final_answer: return response.final_content # 情況二模型決定調(diào)用某個工具 tool_result execute_tool(response.tool_name, response.tool_arguments) messages.append({ role: tool, tool_call_id: response.tool_call_id, content: tool_result }) raise Exception(f超過最大步數(shù)任務(wù)未完成)這個循環(huán)并不復(fù)雜但它背后藏著幾個關(guān)鍵設(shè)計決策。3.2 工具注冊告訴模型“你能用什么”模型并不知道系統(tǒng)里有哪些函數(shù)你需要通過工具描述把能力暴露給它。比如[ { name: get_commits, description: 獲取指定 Git 倉庫某日期之后的提交列表, parameters: { type: object, properties: { since_date: {type: string, description: 起始日期YYYY-MM-DD}, repo_path: {type: string, description: 本地倉庫路徑} }, required: [since_date, repo_path] } }, { name: write_report, description: 把周報內(nèi)容寫入 Markdown 文件, parameters: { type: object, properties: { content: {type: string, description: 完整 Markdown 內(nèi)容}, file_path: {type: string, description: 輸出文件路徑} }, required: [content, file_path] } } ]工具描述不要太含糊也不要太啰嗦。模型會根據(jù)這段描述判斷“我現(xiàn)在應(yīng)該調(diào)哪個工具、傳什么參數(shù)”。如果描述不清晰Agent 很容易在工具選擇上繞圈。3.3 關(guān)鍵參數(shù)最大步數(shù)、超時、輸出校驗最小循環(huán)跑通容易但真正要穩(wěn)定運行需要給 Agent 設(shè)邊界。最大步數(shù)防止模型在循環(huán)里空轉(zhuǎn)。通常是 5 到 15 步具體取決于任務(wù)復(fù)雜度。超過步數(shù)就終止并在日志里記錄。單次工具超時比如 git 命令可能因為倉庫過大卡住要給每個工具單獨設(shè)置超時。輸出校驗?zāi)Ｐ头祷氐?JSON 不總是合法代碼里要做異常捕獲解析失敗時可以重試一次或者把錯誤信息返回給模型讓它自行修正。注意不要一上來就把步數(shù)設(shè)到 50 或 100先設(shè) 10 步以內(nèi)確保能穩(wěn)定完成后再逐步放寬。這個最小示例跑通以后才算真正理解了“AI 自己干活”的技術(shù)底層它是一個由模型決策驅(qū)動的執(zhí)行循環(huán)而不是一個單純的對話服務(wù)。4. 別高興太早真正能穩(wěn)定跑起來的工程細節(jié)4.1 工具邊界Agent 能調(diào)什么不能調(diào)什么要寫清楚這是我在實際項目里踩過的坑。如果工具列表里只有g(shù)et_commits和write_report那 Agent 最多也就是讀 Git 和寫文件風險可控。但一旦加上“發(fā)送郵件”“執(zhí)行 shell 命令”“刪除文件”“推送遠端倉庫”這類高風險工具就必須在系統(tǒng)層面對 Agent 做權(quán)限收斂。具體做法是對工具做分級只讀工具默認允許寫操作需要確認刪除/推送類操作直接禁用或要求人工審批。在工具描述里明確約束比如“只有用戶明確要求時才能調(diào)用刪除功能”。在代碼層面強制校驗工具參數(shù)不能完全依賴模型自律。Agent 以為自己很聰明但真正決定風險下限的是工具暴露面。工具給得越寬意外越多。4.2 失敗重試不是所有錯誤都該重試很多 Agent 框架里都有自動重試機制但錯誤類型不一樣對策也不一樣。常見的失敗分三類臨時失敗網(wǎng)絡(luò)超時、API 限流、Git 倉庫鎖占用等待幾秒后重試通常有效。輸入錯誤模型傳錯了參數(shù)比如日期格式不對、文件路徑不存在。此時盲目重試只會得到同樣的錯誤應(yīng)該把報錯信息返回給模型讓它自己修正。不可恢復(fù)錯誤比如目標倉庫不存在、工具權(quán)限不足。這種情況應(yīng)該直接終止任務(wù)并告訴用戶原因。最簡單的排查順序是先看環(huán)境再看輸入再看模型決策。如果模型連續(xù)三次選擇了同一個錯誤工具大概率不是偶然而是工具描述有歧義。4.3 日志回放每一步的思考、調(diào)用、結(jié)果都要留痕“AI 自己干活”最怕什么不是它干不好而是你不知道它為什么干不好。所以 Agent 的日志要比普通腳本詳細得多。每一步至少記錄當前是第幾步。模型本輪說什么也可以記錄思考過程如果平臺支持。模型調(diào)用了哪個工具傳了什么參數(shù)。工具返回了什么內(nèi)容耗時多久。模型根據(jù)工具結(jié)果做了什么判斷。最終終止原因是什么。這套日志就是 Agent 的“黑匣子”。遇到問題先回放不是靠猜。5. 什么場景適合讓 Agent“自己干活”什么場景最好別5.1 適合的場景流程固定但步驟多結(jié)果可驗證從我的經(jīng)驗看合適的 Agent 任務(wù)通常有三個特點有明確目標比如“把 A 目錄下所有 PDF 轉(zhuǎn)成 Markdown”“從數(shù)據(jù)庫導(dǎo)出最近 30 天訂單并生成匯總表”。步驟雖然多但路徑相對清晰不需要太多天馬行空的創(chuàng)造更多是重復(fù)性操作。結(jié)果可驗證生成的文件能不能打開、數(shù)據(jù)有沒有缺失、格式對不對都可以用程序檢查。這類任務(wù)交給 Agent 之后省下的不是思考時間而是“人來回切換系統(tǒng)”的成本。真正縮短的是流程鏈路不是模型輸出。5.2 不適合的場景不可逆、高風險、價值觀判斷凡是“錯一次代價很高”的任務(wù)我都建議保守處理。舉幾個例子自動刪除生產(chǎn)環(huán)境數(shù)據(jù)。自動對外發(fā)送不可撤回的消息。自動修改核心系統(tǒng)配置。自動生成法律、醫(yī)療、金融領(lǐng)域的正式建議。這些場景不是模型能力不夠而是錯誤容忍度太低。Agent 即使只錯一次代價也可能非常大。安全起見可以讓 Agent 負責“準備工作”和“草稿生成”最終決策和關(guān)鍵操作仍然由人完成。5.3 一個通用判斷清單可以拿下面這份清單快速判斷一個任務(wù)適不適合 Agent判斷維度適合不適合目標是否明確是一條話能說清楚模糊、需要反復(fù)澄清流程是否穩(wěn)定固定但有分支每次都不一樣完全無規(guī)律結(jié)果是否可驗證可以用程序檢查只能靠人憑經(jīng)驗判斷風險高低低錯了改一下就行高錯了代價大是否需要人類價值觀基本不需要需要大量主觀判斷如果命中“不適合”列超過兩條建議不要上 Agent至少不要全自動。6. 從我自己的經(jīng)驗看先跑通、再優(yōu)化、最后才談自動化6.1 階段一單任務(wù)跑通別先談復(fù)雜編排第一次做 Agent千萬別直接設(shè)計一個多智能體協(xié)作系統(tǒng)。先把“一個模型 少量工具 一個循環(huán)”做到穩(wěn)定。比如上面那個周報生成示例先手動跑 5 次確認每次都能正確生成文件。這期間不用追求速度、不用追求復(fù)雜功能重點是把異常處理、日志、邊界參數(shù)打磨好。單次跑通只能說明流程沒有斷。真正的問題會在重復(fù)執(zhí)行和多場景覆蓋時浮出來。6.2 階段二加批量和并發(fā)觀察限流與資源占用單任務(wù)穩(wěn)定后下一個挑戰(zhàn)是批量和并發(fā)。假設(shè)你要同時為 10 個倉庫生成周報就要考慮并發(fā)調(diào)用大模型 API 時是否觸發(fā)限流。本地命令執(zhí)行是否占用過多 CPU、內(nèi)存。輸出目錄是否沖突文件會不會被覆蓋。如果中途某幾個任務(wù)失敗是整體重跑還是只重跑失敗項。這時候再回頭看“AI 自己干活”你會發(fā)現(xiàn)干活的不只是 AI還有一堆工程細節(jié)。批處理和并發(fā)控制就是最常見的第一道坎。6.3 階段三加入監(jiān)控、權(quán)限、審核才能長期用長期可用的 Agent 系統(tǒng)和一次性腳本之間的區(qū)別在于可觀測、可干預(yù)、可審計?？捎^測有指標看板能看到 Agent 今天的成功率、平均步數(shù)、平均耗時。可干預(yù)任務(wù)執(zhí)行中支持人工暫停、修改參數(shù)、駁回某一步操作。可審計所有執(zhí)行記錄都能回溯出了問題能定位到具體某一步。這三個能力不是一開始就要做全但在 Agent 進入真實業(yè)務(wù)之前至少要有一個能讓現(xiàn)場人員介入的“急停按鈕”。實際落地時建議每周復(fù)盤一次 Agent 日志從失敗樣本里反推工具描述是否需要優(yōu)化、步數(shù)上限是否合理、哪些工具權(quán)限太寬。這不是一次性的調(diào)參而是持續(xù)迭代。7. 最后AI 自己干活但先得知道哪條路不能省回到一開始那個判斷AI 不再聽命令了它開始自己干活。這話沒錯但“自己干活”不是模型單獨完成的而是模型、工具、工程邊界、日志審計共同完成的一件事。模型負責的是“決策”真正對結(jié)果負責的還是人。我們給 Agent 規(guī)劃目標、劃定工具邊界、定義驗證方式、設(shè)置失敗兜底它才能在一個可控范圍內(nèi)“自己干活”。所以如果你正準備做一個 Agent 項目我的建議是先從最小流程開始不急著給工具開權(quán)限不盲目追求多智能體、復(fù)雜規(guī)劃。把單任務(wù)跑通把日志埋好把失敗路徑想清楚再把任務(wù)范圍一點一點擴大。這條路看著慢但到了生產(chǎn)環(huán)境會發(fā)現(xiàn)它其實是最快的路。