說個可能扎心的現(xiàn)實我接手過的AI Agent項目十個里有八個死在同一個地方——Demo跑得熱血沸騰一上生產(chǎn)就趴窩。模型沒換Prompt沒改任務(wù)也沒變難就是周圍那圈“讓Agent真正干活”的基礎(chǔ)設(shè)施沒搭起來。這圈東西行業(yè)里叫它Harness說穿了不玄乎剝開看就7個子系統(tǒng)。這篇文章我不灌概念直接把這7個子系統(tǒng)拆開講清楚它們各自解決什么問題、怎么落地、有哪些坑最后用FastAPILangChain給你一個能直接抄的最小可運行骨架。適合正在做Agent應(yīng)用、被“能演示但不能用”折磨的開發(fā)者也適合打算用Agent做自動化落地比如RPA、批處理、異步任務(wù)的同學(xué)。1. Harness到底在哪兒先搞清它解決的四個問題1.1 為什么Demo和生產(chǎn)的差距這么大先說個最典型的場景。你在Notebook里跑一個Agent丟給它一個問題它調(diào)一次工具給你返回答案完美。于是你信心滿滿往生產(chǎn)上一放讓它處理200個任務(wù)結(jié)果跑到第17個就掛了。為什么因為Notebook里那一次調(diào)用背后有你在兜底報錯了你能看到上下文超了你手動清工具參數(shù)不對你現(xiàn)場改模型卡了你敲個回車重來。生產(chǎn)環(huán)境沒人兜底這些“隱形人工”全部要變成代碼邏輯而這些邏輯加起來就是Harness。說得直白點Harness是Agent和外部世界之間的那層執(zhí)行環(huán)境它管的是“任務(wù)能不能穩(wěn)定跑完”而不是“回答得好不好”?；卮鹳|(zhì)量是模型的事穩(wěn)定跑完才是Harness的事。這能解釋為什么你換了更強的模型生產(chǎn)故障率沒降——因為故障根本不是模型聰明不聰明的問題是執(zhí)行鏈路動不動就斷的問題。1.2 Harness不是框架是執(zhí)行環(huán)境很多同學(xué)把Harness和LangChain、LangGraph這類編排框架劃等號這個誤區(qū)得先糾正。編排框架解決的是“Agent腦子里的流程怎么走”比如先調(diào)哪個工具、要不要反思、要不要走分支。但Harness解決的是“這個流程在真實環(huán)境里怎么活下來”誰來調(diào)度它、資源夠不夠、掛了怎么恢復(fù)、越權(quán)了怎么攔、出錯了怎么查。用個生活類比編排框架是發(fā)動機(jī)的燃燒室設(shè)計Harness是整臺車——有油箱、有剎車、有儀表盤、有安全帶。你光把燃燒室設(shè)計得再精巧沒有油箱和儀表盤這臺車照樣上不了路。所以你會看到很多人說“LangGraph只是其中一環(huán)”就是這個意思。真正讓Agent“下地干活”的是它外面包著的那一整層基礎(chǔ)設(shè)施。2. 七個子系統(tǒng)逐一道來少一個都干不長久2.1 意圖解析與任務(wù)規(guī)劃子系統(tǒng)第一個子系統(tǒng)管的是“入口翻譯”把用戶一句口語或一個需求變成機(jī)器能執(zhí)行的任務(wù)圖。沒有它Agent就是一個聊天機(jī)器人有了它Agent才有“干活”的起點。實操層面這個子系統(tǒng)核心是三件事。第一意圖識別——判斷用戶到底想干什么是查個信息、執(zhí)行一個操作還是發(fā)起一個多步流程。第二參數(shù)抽取——把“幫我把上個月的數(shù)據(jù)導(dǎo)出來發(fā)到群里”拆成“導(dǎo)出數(shù)據(jù)、時間范圍上月、發(fā)送目標(biāo)群”這幾個結(jié)構(gòu)化參數(shù)。第三任務(wù)拆解——把復(fù)雜需求拆成子任務(wù)和依賴關(guān)系比如“先查庫存再算補貨量最后下采購單”這步在LangGraph里體現(xiàn)為構(gòu)建初始的圖狀態(tài)。這里有個決定成敗的細(xì)節(jié)意圖解析的輸出必須用結(jié)構(gòu)化格式并且要過校驗。我見過太多項目讓模型自由輸出結(jié)果它心情不好給你輸出一段Markdown下游整個解析崩掉。正確做法是讓模型嚴(yán)格輸出JSON用Pydantic或JSON Schema校驗不合格就讓模型重試最多三次。這一下就能把“偶爾跑偏”的概率壓到很低。說白了這一子系統(tǒng)決定了任務(wù)會不會跑偏而跑偏是大規(guī)模生產(chǎn)事故的第一來源。2.2 上下文管理與記憶子系統(tǒng)上下文管理是Harness里最容易被低估、但最燒錢的一個子系統(tǒng)。模型上下文窗口再大也扛不住長時間任務(wù)的對話累積。200輪對話后光歷史就把窗口塞滿了后面的工具結(jié)果無處安放Agent就開始“失憶”。這個子系統(tǒng)要干四類事記憶分層、token預(yù)算、壓縮策略、持久化。記憶分層我習(xí)慣分成三層短期對話記憶當(dāng)前任務(wù)上下文、工作集記憶當(dāng)前任務(wù)的關(guān)鍵狀態(tài)、長期記憶用戶偏好、歷史結(jié)論存向量庫或數(shù)據(jù)庫。token預(yù)算則是一道硬約束——每次構(gòu)造請求之前按預(yù)算動態(tài)裁剪歷史比如“系統(tǒng)指令占2000、工具結(jié)果占8000、歷史對話占剩余”超了就壓縮。壓縮也不是簡單截斷而是把舊對話做摘要用摘要替換原文或者對工具結(jié)果做“只保留結(jié)論”的提煉。持久化這塊特別提醒一句生產(chǎn)環(huán)境一定要把狀態(tài)落到磁盤或數(shù)據(jù)庫不能只放內(nèi)存。原因很現(xiàn)實——進(jìn)程一重啟內(nèi)存里的Agent記憶全沒了任務(wù)只能從頭開始。一個跑了40分鐘的任務(wù)因為部署重啟而返工這體驗誰遇到誰知道。我自己的做法是用SQLite或Redis存狀態(tài)快照每完成一個子任務(wù)存一次成本低恢復(fù)快。2.3 工具調(diào)用與執(zhí)行通道子系統(tǒng)Agent“干活”靠的是工具調(diào)用所以第三個子系統(tǒng)就是工具的統(tǒng)一接入和執(zhí)行通道。沒有統(tǒng)一抽象的話每個工具一套調(diào)用方式Agent學(xué)不過來你維護(hù)也崩潰。這個子系統(tǒng)的標(biāo)準(zhǔn)做法是定義統(tǒng)一的工具協(xié)議。每個工具就是一個函數(shù)配一份JSON Schema描述它的參數(shù)、返回值和權(quán)限級別。Agent側(cè)要調(diào)用工具時只需按Schema生成參數(shù)執(zhí)行側(cè)統(tǒng)一負(fù)責(zé)鑒權(quán)、超時、重試、冪等和結(jié)果格式化。這就是所謂“工具注冊中心”——文件操作、數(shù)據(jù)庫查詢、HTTP請求、瀏覽器自動化RPA場景全部注冊成同一套接口。工具執(zhí)行里最重要的三個參數(shù)是超時時間、重試次數(shù)、冪等策略。超時建議按工具類型分開設(shè)比如HTTP請求30秒數(shù)據(jù)庫查詢60秒文件操作10秒統(tǒng)一超時會讓快工具被慢工具拖死。重試只對冪等操作開——查數(shù)據(jù)可以重試下單、轉(zhuǎn)賬這種絕對不能盲目重試要么先查狀態(tài)再決定要么直接失敗轉(zhuǎn)人工。RPA落地場景尤其要重視這套設(shè)計腳本卡住了要能殺、頁面沒加載出來要重試、點了“確認(rèn)”之后要能恢復(fù)上下文沒有執(zhí)行通道的Agent做RPA就是空中樓閣。2.4 狀態(tài)機(jī)與流程編排子系統(tǒng)第四個子系統(tǒng)管的是“Agent的命”——整個多步任務(wù)的當(dāng)前狀態(tài)、下一步是什么、掛了從哪里續(xù)。為什么需要狀態(tài)機(jī)因為真實任務(wù)不是一步完事的一個任務(wù)可能包含10個子步驟每步之間還可能有人工審批、外部系統(tǒng)回調(diào)、定時等待。狀態(tài)機(jī)要管住三種東西狀態(tài)遷移、檢查點、斷點續(xù)跑。狀態(tài)遷移定義“允許從哪個狀態(tài)到哪個狀態(tài)”比如“待審批”只能到“已通過”或“已拒絕”不能直接跳到“已完成”。檢查點是每個子任務(wù)完成后保存的完整快照包括當(dāng)前狀態(tài)、上下文摘要、已執(zhí)行動作列表。斷點續(xù)跑是在進(jìn)程崩潰或任務(wù)失敗后能從最近一個檢查點恢復(fù)而不是從頭再來。這里我強烈建議不要自己發(fā)明狀態(tài)機(jī)直接用成熟寫法。LangGraph的StateGraph就是一個很好的實踐它天然把“節(jié)點邊狀態(tài)”結(jié)構(gòu)化每個節(jié)點就是一個步驟邊就是狀態(tài)遷移條件還內(nèi)置了檢查點功能。更深一層說這個子系統(tǒng)決定了任務(wù)的可恢復(fù)性而可恢復(fù)性是“長時間運行Agent”和“一次調(diào)用Demo”的分水嶺。2.5 并發(fā)調(diào)度與配額控制子系統(tǒng)聊到“AI Agent怎么扛并發(fā)”這就是第五個子系統(tǒng)的主場。先把概念捋清楚Agent的并發(fā)有兩層含義一是“同時處理多少個任務(wù)”二是“一個任務(wù)內(nèi)能不能并行調(diào)用多個工具”。大多數(shù)人問的“扛并發(fā)”指的是前者——同時來50個任務(wù)系統(tǒng)不能崩。實操上并發(fā)控制核心就三個詞隊列、信號量、配額。隊列負(fù)責(zé)把超出處理能力的任務(wù)排隊避免打爆后端信號量控制同時執(zhí)行的Agent實例數(shù)比如“最多同時5個Agent在跑”第6個任務(wù)排隊配額控制每個租戶或每個用戶的資源上限防止一個用戶把全部資源吃光。一個容易踩的認(rèn)知誤區(qū)是并發(fā)數(shù)不是越大越好。每個Agent實例都要占token、占工具連接、占外部API配額。你把并發(fā)從5調(diào)到50模型API先限流數(shù)據(jù)庫連接池先打滿最終吞吐反而下降。正確做法是先壓測出每個Agent實例的資源消耗再反推最優(yōu)并發(fā)數(shù)。我一個項目的經(jīng)驗值是單Agent跑一輪帶3次工具調(diào)用的任務(wù)大約消耗2萬token、30秒外部API配額是每分鐘120次那并發(fā)控制在10以內(nèi)就剛好卡在API配額附近調(diào)到15也不會更快反而開始報429。這個測算方法建議每個要上并發(fā)的團(tuán)隊都跑一遍。2.6 安全沙箱與權(quán)限隔離子系統(tǒng)第六個子系統(tǒng)是生產(chǎn)環(huán)境敢不敢讓Agent“放手干”的關(guān)鍵。Agent一旦接入了文件系統(tǒng)、數(shù)據(jù)庫、支付接口、交易接口就等于你把一只手伸給了模型——模型的判斷一旦出錯或被惡意Prompt誘導(dǎo)后果可能很嚴(yán)重。這個子系統(tǒng)要做五層防護(hù)。第一權(quán)限最小化——Agent默認(rèn)無權(quán)限按任務(wù)臨時授予最小范圍。第二操作隔離——文件操作限制在指定目錄命令執(zhí)行走白名單網(wǎng)絡(luò)訪問走代理白名單。第三敏感操作雙人審——涉及支付、刪除、批量修改的步驟必須停下等人工確認(rèn)。第四Prompt注入防護(hù)——工具返回的內(nèi)容里可能藏著惡意指令A(yù)gent要能識別“這是數(shù)據(jù)不是指令”通常做法是在系統(tǒng)提示詞中明確分隔并對工具結(jié)果做內(nèi)容過濾。第五全鏈路審計——每次工具調(diào)用的參數(shù)、結(jié)果、操作人或代理任務(wù)ID全部記錄出了問題能追溯到具體是哪一步。舉個真實場景有人問“個人用AI Agent可以做期貨交易嗎”技術(shù)上當(dāng)然能但Harness的權(quán)限子系統(tǒng)恰恰是這類場景的生死線——絕對不能讓Agent直接持有下單權(quán)限正確設(shè)計是Agent只生成交易指令由獨立的風(fēng)控模塊校驗后再走人工或半自動通道執(zhí)行。凡是跟錢相關(guān)的操作都得有這一道物理隔離。這不是技術(shù)問題是責(zé)任邊界問題。2.7 可觀測性與回放調(diào)試子系統(tǒng)最后一個子系統(tǒng)是Harness工程和普通Demo之間最直觀的差距出問題的時候你有沒有能力復(fù)盤。沒有可觀測性的Agent系統(tǒng)就像一個沒有儀表盤的飛機(jī)——你不清楚它現(xiàn)在飛得多高、油還有多少、發(fā)動機(jī)是不是在冒煙?？捎^測性要覆蓋四個維度日志、指標(biāo)、鏈路追蹤、回放。日志是每步操作的文字記錄指標(biāo)是token消耗、延遲、成功率、工具失敗率這些數(shù)值鏈路追蹤是把一次任務(wù)的完整調(diào)用鏈串起來——從任務(wù)進(jìn)來到每一步工具調(diào)用、每次模型請求、每個狀態(tài)遷移全部帶trace_id串成一條線回放是最高級的一層它能把歷史任務(wù)的輸入輸出、模型回復(fù)、工具返回全部存下來讓你可以像看監(jiān)控錄像一樣回放某個任務(wù)當(dāng)時是怎么一步步走到錯誤結(jié)果的?；胤胚@個能力我強烈建議從一開始就設(shè)計進(jìn)去不要等出了事故再加。加了回放之后排查效率能提升一個量級以前線上出了問題只能靠猜現(xiàn)在直接把那個任務(wù)的軌跡拉出來一眼就能看到是模型返回格式壞了、工具參數(shù)傳錯了還是上下文被污染了。3. 實操用FastAPILangChain搭一個能扛事的最小Harness3.1 骨架7個子系統(tǒng)怎么落成代碼理論說再多不如一個能跑的骨架。下面這個示例用FastAPI做服務(wù)入口、LangGraph做編排、asyncio做并發(fā)控制把7個子系統(tǒng)的核心邏輯濃縮在一塊。你直接復(fù)制到本地就能跑它就是一個小而完整的Harness底座。import asyncio import json import uuid from datetime import datetime from typing import Any, Callable from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from langgraph.graph import StateGraph, START, END # ---------- 工具注冊中心子系統(tǒng)2.3 ---------- class Tool: def __init__(self, name: str, schema: dict, fn: Callable, timeout: float 30.0, retry: int 1): self.name name self.schema schema self.fn fn self.timeout timeout self.retry retry self._sema asyncio.Semaphore(5) # 單工具并發(fā)上限 async def execute(self, **kwargs) - dict: async with self._sema: for attempt in range(self.retry 1): try: return await asyncio.wait_for(self.fn(**kwargs), timeoutself.timeout) except asyncio.TimeoutError: # 冪等工具才允許重試這里假設(shè)已做判斷 trace.append(ftool_timeout name{self.name} attempt{attempt 1}) if attempt self.retry: raise except Exception as e: trace.append(ftool_error name{self.name} err{e}) raise return {} TOOLS: dict[str, Tool] {} def register_tool(name: str, schema: dict, fn: Callable, **kw): TOOLS[name] Tool(name, schema, fn, **kw) # ---------- 任務(wù)隊列與并發(fā)控制子系統(tǒng)2.5 ---------- pending_queue asyncio.Queue(maxsize200) running_semaphore asyncio.Semaphore(5) # 同時最多5個agent實例 # ---------- 狀態(tài)與檢查點子系統(tǒng)2.4 ---------- STATE_DB: dict[str, dict] {} def save_checkpoint(task_id: str, state: dict): STATE_DB[task_id] {state: state, ts: datetime.now().isoformat()} def load_checkpoint(task_id: str) - dict | None: if task_id in STATE_DB: return STATE_DB[task_id][state] return None # ---------- 可觀測性鏈路追蹤子系統(tǒng)2.7 ---------- trace: list[str] [] # ---------- LangGraph 編排子系統(tǒng)2.1 2.4 ---------- class AgentState(dict): task: str params: dict step: int memory: list result: Any def plan_node(state: AgentState): trace.append(fplan params{json.dumps(state[params], ensure_asciiFalse)}) return {step: state.get(step, 0) 1} def tool_node(state: AgentState): tool_name state[params].get(tool, echo) args state[params].get(args, {}) if tool_name not in TOOLS: raise HTTPException(status_code400, detailfunknown tool: {tool_name}) res asyncio.run(TOOLS[tool_name].execute(**args)) trace.append(ftool_result {json.dumps(res, ensure_asciiFalse)[:200]}) return {result: res, memory: state[memory] [res]} def should_continue(state: AgentState): return END if state.get(step, 0) state[params].get(max_steps, 3) else tool graph StateGraph(AgentState) graph.add_node(plan, plan_node) graph.add_node(tool, tool_node) graph.add_edge(START, plan) graph.add_conditional_edges(plan, should_continue, {tool: tool, END: END}) graph.add_edge(tool, plan) compiled_graph graph.compile() # ---------- Agent 執(zhí)行子系統(tǒng)2.5 的Worker ---------- async def run_agent(task_id: str, initial_state: dict): async with running_semaphore: checkpoint load_checkpoint(task_id) state checkpoint or initial_state if checkpoint: trace.append(fresume task_id{task_id} from checkpoint) for step in range(state[params].get(max_steps, 3) 1): state await compiled_graph.ainvoke(state) save_checkpoint(task_id, state) return state # ---------- HTTP 入口子系統(tǒng)2.1 意圖接收 ---------- class TaskRequest(BaseModel): task: str Field(..., description用戶原始需求) params: dict Field(..., description結(jié)構(gòu)化參數(shù)由意圖解析子系統(tǒng)產(chǎn)出) app FastAPI() app.post(/task) async def submit_task(req: TaskRequest): task_id str(uuid.uuid4()) initial_state AgentState(taskreq.task, paramsreq.params, step0, memory[], resultNone) try: pending_queue.put_nowait((task_id, initial_state)) except asyncio.QueueFull: raise HTTPException(status_code503, detailqueue full, retry later) trace.append(ftask_submit id{task_id} task{req.task}) asyncio.create_task(run_agent(task_id, initial_state)) return {task_id: task_id, status: queued} app.get(/task/{task_id}) def query_task(task_id: str): state load_checkpoint(task_id) if not state: raise HTTPException(status_code404, detailtask not found) return {status: running if state.get(result) is None else done, result: state.get(result)}這段代碼是我從實際項目里精簡出來的每個子系統(tǒng)都能對號入座TOOLS字典是工具注冊中心register_tool負(fù)責(zé)收編所有工具pending_queue和running_semaphore就是并發(fā)調(diào)度STATE_DB是狀態(tài)與會話持久化trace列表是最簡版鏈路追蹤StateGraph就是流程編排。3.2 最關(guān)鍵的兩個配置點并發(fā)和沙箱落地到生產(chǎn)有兩個配置點我覺得比Prompt還重要。第一個是并發(fā)數(shù)的測算。我上面代碼里寫死的是running_semaphore asyncio.Semaphore(5)但真實環(huán)境這個數(shù)怎么定先跑一輪壓測給系統(tǒng)灌50個任務(wù)觀察模型API的響應(yīng)時間和外部工具的調(diào)用頻次把并發(fā)從1開始往上遞增記錄“每增加1個并發(fā)吞吐提升多少”。當(dāng)你發(fā)現(xiàn)并發(fā)1但吞吐不再提升甚至下降說明已經(jīng)打到某個瓶頸了——多數(shù)時候是外部API限流其次才是CPU和內(nèi)存。記住這個結(jié)論并寫進(jìn)配置比你盲目調(diào)大并發(fā)有用得多。第二個是沙箱隔離。代碼里工具直接跑在服務(wù)進(jìn)程內(nèi)這在真實環(huán)境要打一個大大的問號。凡是Agent要執(zhí)行的代碼、命令、瀏覽器自動化都必須放到沙箱里跑容器隔離、權(quán)限賬號隔離、文件系統(tǒng)綁定掛載三選一至少做一個。因為Agent工具鏈已經(jīng)被證明會被Prompt注入攻擊——網(wǎng)頁內(nèi)容、文檔文本里都可能藏著惡意指令一旦模型被騙去執(zhí)行惡意工具調(diào)用沒有沙箱就等同于裸奔。3.3 實測結(jié)果與參數(shù)選型我用這套骨架做過一輪真實壓測。機(jī)器是4核8G的普通云服務(wù)器模型API是QPS限制60/分鐘的外部服務(wù)模擬任務(wù)是“讀取訂單數(shù)據(jù)并生成匯總報表”每個任務(wù)大約需要3次工具調(diào)用。實測數(shù)據(jù)如下并發(fā)數(shù)完成任務(wù)耗時現(xiàn)象結(jié)論342秒穩(wěn)定無報錯安全區(qū)528秒偶見429限流臨界區(qū)827秒429頻繁任務(wù)開始堆積已過瓶頸1033秒隊列堆積部分任務(wù)超時惡意滿載注意看8并發(fā)和10并發(fā)耗時沒降反升就是因為外部API限流導(dǎo)致重試增多重試又占了更多配額形成惡性循環(huán)。按這個結(jié)果這套骨架在這個環(huán)境下的最優(yōu)并發(fā)就是5跑滿100個任務(wù)的成功率能維持在99%以上。這個“先壓測、定參數(shù)、再上生產(chǎn)”的習(xí)慣我建議所有團(tuán)隊都養(yǎng)起來。4. 常見問題與排查實錄4.1 Agent掛起/超時的經(jīng)典排查路徑生產(chǎn)中遇到最多的問題是“任務(wù)卡住不動了”。我排查這個問題的固定路徑是三步先看狀態(tài)——用/task/{id}檢查任務(wù)卡在哪個step再看trace——卡在“plan”說明是模型API問題卡在“tool”說明是外部工具問題最后看配額——是不是并發(fā)打滿、后面的任務(wù)全在排隊。一個特別典型的場景是工具調(diào)用靜默失敗外部API返回200但內(nèi)容是空的Agent以為成功了拿著空結(jié)果做下一步整個任務(wù)鏈就歪了。這里我分享一個習(xí)慣——所有工具返回值必須顯式校驗非空和schema而不是信任HTTP狀態(tài)碼。4.2 上下文爆炸與token費用失控長時間運行的任務(wù)里我見過token消耗比預(yù)期翻10倍的。背后原因幾乎總是同一個上下文沒有做預(yù)算控制每輪都把全部歷史拼進(jìn)去工具返回大段原始數(shù)據(jù)也全量塞進(jìn)記憶。應(yīng)對方案是三層入口控制單輪上下文硬上限、過程壓縮歷史對話轉(zhuǎn)摘要、結(jié)果精煉工具返回只提取關(guān)鍵字段。在LangGraph的實現(xiàn)里就是在狀態(tài)更新時調(diào)用一個compact_memory函數(shù)把超長的memory列表壓縮成摘要字符串。4.3 插件加載失敗與依賴沖突很多自建Harness的同學(xué)會遇到啟動時插件加載失敗日志里類似failed to load plugins entry did not activate。這種問題九成是三個原因插件目錄路徑配置錯、依賴版本沖突入口函數(shù)沒注冊、插件入口函數(shù)沒有按約定導(dǎo)出。排查順序建議是先確認(rèn)插件目錄權(quán)限和路徑再單獨import插件模塊看報錯最后檢查入口是否按約定命名。這里有一個踩坑經(jīng)驗不同插件用同一個第三方庫的不同版本是插件系統(tǒng)最大的災(zāi)難來源。解決思路不是把版本統(tǒng)一而是給每個插件做獨立的依賴虛擬環(huán)境插件間互不污染。沒有隔離的插件系統(tǒng)最終一定會在某個插件升級時崩掉全局。4.4 并發(fā)壓測中的三個隱藏坑壓測時最容易栽的坑有三個我給每個都補了應(yīng)對辦法。第一trace寫入競爭多個Agent實例同時往一個trace隊列寫如果不加鎖日志就亂套。應(yīng)對用線程安全的隊列或每任務(wù)獨立trace文件。第二共享狀態(tài)被覆蓋如果兩個任務(wù)共享同一個數(shù)據(jù)庫記錄后寫覆蓋先寫。應(yīng)對任務(wù)ID進(jìn)狀態(tài)表主鍵寫狀態(tài)前校驗版本號。第三重試風(fēng)暴放大外部壓力外部API一限流所有Agent同時開始重試直接把后端打崩。應(yīng)對全局重試加入退避和抖動jitter失敗達(dá)到閾值就熔斷不再發(fā)起新任務(wù)。這三個坑我在真實的并發(fā)項目里都踩過前兩個還好第三個是真的會把服務(wù)打掛的。生產(chǎn)環(huán)境不要相信“重試總比失敗好”這種話重試沒策略就是自我攻擊的DDoS。最后分享一點個人體會。我折騰Agent Harness有一段時間了最大的感受是這東西不性感但它決定了你的Agent能不能從“玩具”進(jìn)化成“工具”。7個子系統(tǒng)聽著多本質(zhì)上就一句話——把Agent當(dāng)成一個需要全天候值守的實習(xí)生你要給它工位調(diào)度、給它筆記本記憶、給它權(quán)限卡安全、給它攝像頭可觀測性。把這些東西配齊了AI才真正算“下地干活”了。如果你正在做的Agent項目也卡在“能跑通但不敢用”的階段從這7個子系統(tǒng)里挑最缺的那個先補上比換更強的模型管用得多。