1. 為什么是 DeepSeek Harness 而不是“直接調(diào) API”這段時間一直在折騰一件事把 DeepSeek Harness 接進公司的后臺管理系統(tǒng)讓它以 Agent 形態(tài)輔助日常運營。先說結(jié)論這套組合跑通以后原來每天要花半個多小時手動做的數(shù)據(jù)匯總、異常訂單篩選、周報素材整理現(xiàn)在只要在后臺里給 Agent 發(fā)一句話它自己就能完成大半。如果你正打算給公司內(nèi)部系統(tǒng)接入智能體但又不確定該從哪一步下手這篇文章應該能幫你省掉幾個晚上的摸索時間。1.1 后臺管理系統(tǒng)里的智能體落地場景先聊聊我為什么會盯上這個方向。公司后臺管理系統(tǒng)是典型的 Vue3 管理端訂單、庫存、用戶、財務各種模塊堆在一起數(shù)據(jù)量不大但特別碎。運營同事每天干得最多的不是決策而是把系統(tǒng)里的數(shù)據(jù)導來導去從訂單列表導出 Excel、把退款異常的單子篩出來、統(tǒng)計最近七天的轉(zhuǎn)化趨勢、再按模板填周報。這些事情有個共同點操作路徑固定、重復性高、又很費人工。如果只是在后臺里接一個“聊天機器人”用戶問一句它答一句那頂多算個高級搜索框價值有限。真正能提升效率的形態(tài)是 Agent它不只回答問題而是能自主調(diào)用系統(tǒng)里的工具把“查數(shù)據(jù)—做統(tǒng)計—生成文件—給結(jié)論”這條鏈路完整跑下來。所以在動工之前我給這次集成定了幾個核心場景都是可以直接量化收益的銷售看板自動生成Agent 讀取訂單接口數(shù)據(jù)計算環(huán)比、同比生成圖表所需的 JSON 結(jié)構(gòu)。異常訂單分析按預設規(guī)則篩選超時未發(fā)貨、退款申請、風控攔截的訂單輸出摘要和處置建議。庫存補貨提醒結(jié)合近 30 天銷量和當前庫存給出補貨清單和預估售罄日期。日志檢索與初步定位接入系統(tǒng)錯誤日志線上出問題時運營或開發(fā)可以直接讓 Agent 查關(guān)鍵字并概括異常。這些場景聽起來都不復雜但如果你直接用裸 API 調(diào)大模型馬上會遇到一堆工程問題模型是無狀態(tài)的你得自己拼上下文模型不能直接調(diào)系統(tǒng)接口你要寫一堆函數(shù)封裝任務執(zhí)行到一半斷了你無法恢復更別說權(quán)限控制、審批流、操作留痕這些后臺系統(tǒng)必須有的東西了。1.2 Harness 層到底解決了什么問題我第一次看到 DeepSeek Harness 時也有同樣的疑問不就是個本地運行大模型智能體的殼子嗎真用起來才發(fā)現(xiàn)我之前的理解太淺了。Harness 這層抽象解決的核心問題是把“模型”和“工具”之間那堆臟活累活接住了。打個比方大模型像是發(fā)動機本身只有動力沒有方向Agent 像是整車有了方向盤和輪子而 Harness 就是駕駛艙里那套儀表盤和控制系統(tǒng)讓你能真正駕駛這輛車而不是抱著發(fā)動機干瞪眼。具體到工程層面Harness 至少幫我們解決了四件事第一是對話狀態(tài)管理。后臺管理系統(tǒng)里經(jīng)常會遇到多輪交互比如“幫我看下華東區(qū)的訂單”“再按支付方式分一下”。如果沒有狀態(tài)管理每次請求都要把前面所有上下文打包發(fā)給模型又費 token 又容易崩。Harness 在本地維護了完整的會話上下文后端只管發(fā)新的消息進去就行。第二是工具調(diào)度協(xié)議。Agent 需要一個標準方式告訴系統(tǒng)“我要調(diào)用哪個工具、參數(shù)是什么、結(jié)果怎么處理”。Harness 內(nèi)置了一套工具注冊與調(diào)用機制支持技能編排。我只需要按照插件規(guī)范寫工具函數(shù)Harness 會自動讓模型學會在合適的時機調(diào)用它們不需要我手寫復雜的原因分析鏈路。第三是長任務處理能力。后臺管理里的任務有時需要跑幾分鐘比如批量導出大量訂單。直接用 API 請求會有超時風險Harness 則以本地任務形式管理這種長時操作執(zhí)行到一半時系統(tǒng)重啟了還能從事件日志里續(xù)跑。第四是插件化架構(gòu)。官方提供了插件機制我可以用 Python 或相關(guān)語言寫獨立技能包注冊進 Harness 后就能被 Agent 使用。這一點對后臺系統(tǒng)集成特別關(guān)鍵因為每個公司的后臺接口都不一樣必須有可擴展的插件體系才能匹配業(yè)務。當然Harness 不是萬能的它不是拿來就能和后臺管理系統(tǒng)打通的神器。實際集成時還需要自己寫一層“橋接服務”把 Harness 的事件、任務狀態(tài)轉(zhuǎn)發(fā)到后臺管理系統(tǒng)的數(shù)據(jù)庫和前端界面里。這部分后面會詳細講。1.3 先確定邊界Agent 能做和不能做的事動手寫代碼之前我花了不少時間定邊界。很多團隊做 Agent 集成翻車不是因為技術(shù)不行而是沒有在立項階段劃清楚“Agent 到底能不能做這件事”。后臺管理系統(tǒng)里全是業(yè)務數(shù)據(jù)和操作入口一旦 Agent 誤操作刪了訂單或者改了價格損失可能非常大。我最終定下來三條鐵律只讀操作可以直接執(zhí)行查詢訂單、查庫存、讀取日志這類不改數(shù)據(jù)的動作Agent 可以自主完成但結(jié)果必須展示給用戶。寫操作必須先審批創(chuàng)建補貨單、批量修改訂單狀態(tài)、生成并發(fā)送報表等操作Agent 只能生成“執(zhí)行方案”等人工在后臺確認后才能真正落庫。危險操作默認禁止刪除數(shù)據(jù)、修改價格、導出敏感客戶信息等除非在技能配置里顯式開啟否則 Agent 連請求入口都不應該有。這三條邊界直接影響后續(xù)架構(gòu)設計。比如 Harness 工具注冊時每個工具都要帶上一個權(quán)限級別字段后臺管理系統(tǒng)的 RBAC 模型也要同步擴展確保“人不能操作的Agent 也不能繞過”。說白了Agent 不是新的管理員它只是幫管理員更快地按下按鈕至于按鈕能不能按必須由后臺系統(tǒng)的權(quán)限體系說了算?，F(xiàn)在回看先花半天時間把邊界定義清楚是整個項目里最劃算的一筆投入。后續(xù)開發(fā)、測試、上線幾乎所有需求沖突和安全隱患都能用這三條鐵律快速判斷。2. 環(huán)境準備與 Harness 的本地化接入邊界定完之后第二步就是把 DeepSeek Harness 跑起來然后打通和后臺管理系統(tǒng)的通信鏈路。這一節(jié)的內(nèi)容適用性比較強不管你的后臺管理系統(tǒng)是 Vue3 還是 React后端是 Java、Go 還是 Python思路都差不多。2.1 安裝 DeepSeek Harness 桌面端我用的方式是下載 DeepSeek Harness 桌面端安裝包裝在一臺內(nèi)網(wǎng) Windows 服務器上。為什么不用個人電腦因為后臺管理系統(tǒng)跑在公司的內(nèi)網(wǎng)環(huán)境Harness 需要和系統(tǒng)接口互通放在同一內(nèi)網(wǎng)段可以減少很多網(wǎng)絡策略上的麻煩也方便做進程守護和日志集中采集。安裝本身沒什么難度一路下一步就行但有三個細節(jié)值得注意安裝路徑不要帶中文和空格否則后續(xù)加載插件時容易出現(xiàn)編碼問題。首次啟動后它會在系統(tǒng)托盤運行需要在設置里確認本地服務端口已經(jīng)監(jiān)聽。默認情況下Harness 會啟動一個本地服務端口后臺管理系統(tǒng)后續(xù)要連的就是這個端口。模型配置建議先用官方默認配置跑通不要一上來就折騰自定義模型或外部模型網(wǎng)關(guān)等核心鏈路穩(wěn)定了再優(yōu)化。安裝完以后我做的第一件事不是急著寫代碼而是先在 Harness 自帶界面里建一個測試 Agent讓它執(zhí)行一個最簡單的技能比如“總結(jié)一段文本”。確認 Harness 自身能正常工作后才開始往外面接系統(tǒng)。很多人喜歡直接一步到位但分層驗證能讓你在后面的排錯中節(jié)約大量時間。2.2 后臺管理系統(tǒng)與 Harness 進程的橋接方案接入之前要想清楚一個問題后臺管理系統(tǒng)和 Harness 之間到底誰主動連誰最簡單的方案是讓后臺管理系統(tǒng)直接調(diào)用 Harness 的本地 HTTP API發(fā)送用戶問題、輪詢?nèi)蝿諣顟B(tài)。但我在實測中發(fā)現(xiàn)光是輪詢還不夠因為 Harness 在執(zhí)行任務過程中需要向后臺系統(tǒng)請求“工具調(diào)用結(jié)果”比如查詢訂單、讀取庫存它不能只靠輪詢感知這類回調(diào)事件。這個溝通模型用術(shù)語說就是“事件驅(qū)動”兩邊都需要有主動推送能力。所以我最終采用了一個輕量級橋接服務架構(gòu)大概是這樣的后臺管理系統(tǒng)前端(Vue3) ↓ WebSocket/HTTP 后臺管理系統(tǒng)后端(REST API WebSocket Server) ↓ HTTP/WebSocket Harness 本地服務(端口監(jiān)聽 Agent 運行時) ↓ HTTP 工具調(diào)用 后臺管理系統(tǒng)后端(REST API - 工具執(zhí)行入口)橋接服務就是后臺管理系統(tǒng)后端本身。它一方面向 Harness 提供工具調(diào)用的 REST 接口另一方面向前端提供任務狀態(tài)查詢和審批操作接口。Harness 產(chǎn)生的任務狀態(tài)變更通過 WebSocket 推送到前端頁面用戶就能實時看到 Agent 在做什么。這里面最關(guān)鍵的決策是不要把 Harness 直接暴露給前端。也就是前端不直接連 Harness 端口所有交互都走后臺系統(tǒng)后端中轉(zhuǎn)。這樣權(quán)限校驗、參數(shù)校驗、操作日志都能在統(tǒng)一入口完成不會出現(xiàn)繞過安全體系的情況。我見過一些人圖省事讓前端直連本地的 AI 服務端口結(jié)果權(quán)限校驗完全失控后面根本沒法上線。2.3 連接驗證與最小可用鏈路架構(gòu)定了之后先不要急著開發(fā)復雜技能一定要先打通一條最小可用鏈路。我當時寫了一個最簡單的工具功能是讓 Agent 獲取后臺系統(tǒng)的“當前時間”。這個工具毫無業(yè)務價值但能驗證整條鏈路是否通暢用戶提問 → Harness 收到 → Agent 決定調(diào)用工具 → 后臺系統(tǒng)接口被觸發(fā) → 結(jié)果返回 → Agent 生成回答 → 前端展示。Harness 插件工具的核心代碼簡寫如下from harness import Tool Tool.register(namesystem_current_time, description獲取后臺服務器當前時間) def get_current_time(): from datetime import datetime return {time: datetime.now().isoformat()}啟動后我在 Harness 技能配置里把這個問題映射到這條工具鏈上然后在后臺管理系統(tǒng)的 Agent 面板發(fā)了一句“現(xiàn)在幾點”。第一次看到前端頁面彈出服務器時間時心里一塊石頭落了地從模型決策到系統(tǒng)調(diào)用這條路通了。最小鏈路跑通后我才開始往里面加業(yè)務工具。這一步走得很慢但非常值得后面所有復雜功能的排錯都能回到這條鏈路上來復現(xiàn)和驗證。3. Agent 技能開發(fā)從模型調(diào)用到可控執(zhí)行鏈路通了之后真正的重頭戲才剛開始開發(fā)能被業(yè)務真正使用的 Agent 技能。這一節(jié)我會把技能模型、權(quán)限模型和審批機制講透這些都是后臺管理系統(tǒng)集成 Harness 時最容易踩坑的地方。3.1 技能與工具的權(quán)限模型先引入兩個概念工具是原子能力技能是業(yè)務場景。比如“查詢訂單列表”是一個工具“生成銷售日報”是一個技能它內(nèi)部會按順序調(diào)用多個工具、處理中間結(jié)果、最終輸出一份日報。在 Harness 的技能配置里我用 JSON 聲明了一個技能文件里面包含提示詞模板、可用的工具列表、輸入輸出格式說明。這里有個設計要點技能里的工具列表一定要寫得很收斂只聲明它真正需要的那幾個不要圖省事把全部工具都掛上去。因為技能一經(jīng)發(fā)布Agent 就可能在這個范圍內(nèi)自由組合工具調(diào)用工具暴露面越大誤操作風險越高。權(quán)限模型上我給每個工具標了三個級別權(quán)限級別行為類型示例執(zhí)行策略read_only只讀查詢查訂單、查庫存、查日志Agent 自主執(zhí)行write_approved寫操作補貨單創(chuàng)建、訂單狀態(tài)修改生成執(zhí)行方案人工審批后執(zhí)行high_risk高風險操作批量刪除、價格修改、敏感數(shù)據(jù)導出默認關(guān)閉需要顯式開啟這個三級模型和前面的邊界是一致的。實現(xiàn)上Harness 工具注冊時會將級別寫入元數(shù)據(jù)橋接服務的工具執(zhí)行入口收到請求后先校驗技能聲明的級別再判斷當前會話用戶是否有對應權(quán)限。雙重校驗避免只依賴某一層。3.2 技能配置示例數(shù)據(jù)匯總與 Excel 導出拿“銷售日報生成”這個技能舉例。它的業(yè)務目標是讀取指定日期的訂單數(shù)據(jù)按商品分類匯總銷售額生成一份 Excel 文件最后把文件存到后臺系統(tǒng)的附件目錄并返回下載地址。技能配置文件大致長這樣{ name: sales_daily_report, description: 生成指定日期的銷售日報包含分類匯總和 Excel 文件, tools: [orders.query_by_date, report.excel_export, file.upload], permission: write_approved, input_schema: { date: string, 格式Y(jié)YYY-MM-DD, channel: string, 可選值:all/online/store }, output_schema: { summary: object, 每個商品分類的銷售額和訂單量, file_url: string, Excel 文件下載地址, tips: string, 用于提醒運營關(guān)注的異常點 } }配置里的三個工具需要分別在 Harness 插件層實現(xiàn)。特別是report.excel_export這個工具實際是后臺管理系統(tǒng)里的一個文件生成服務它接收匯總數(shù)據(jù)后生成 Excel并存入文件存儲模塊。為什么不讓 Harness 直接生成文件因為后臺管理系統(tǒng)的附件通常需要權(quán)限控制、過期清理和審計放在統(tǒng)一文件服務里更安全。關(guān)于 Excel 文件還有一個高頻需求是“在線預覽”。Agent 生成 Excel 后用戶往往不想下載到本地再打開而是希望后臺頁面直接點開看。我采用的方案是文件生成時同時輸出一份 HTML 預覽版本或者讓前端用表格插件解析下載到的文件內(nèi)容并渲染。也就是說預覽功能不是端到端自動的需要后臺管理系統(tǒng)在前端做一次表格式展示的適配。實踐下來用現(xiàn)成的前端表格插件渲染服務端吐出的 JSON 數(shù)據(jù)最穩(wěn)定本來就不建議讓前端直接解析二進制 Excel 文件。3.3 人工審批環(huán)節(jié)讓操作過程“可回滾”所有寫操作前面提到必須走審批。但審批不能簡單理解成“彈個窗確認”它要設計成一套完整的事件流否則很容易在網(wǎng)絡抖動或任務中斷時產(chǎn)生不一致。我設計的審批流程是Agent 在執(zhí)行帶write_approved權(quán)限的技能時先生成一份“執(zhí)行方案”包含要調(diào)用的工具、參數(shù)和預期影響范圍。橋接服務把這個方案寫入后臺管理系統(tǒng)的agent_approval表狀態(tài)為pending并通過 WebSocket 通知前端。用戶在后臺頁面看到審批卡片可以一鍵通過或拒絕也可以修改參數(shù)后通過。用戶通過后橋接服務再回調(diào) Harness 的接口告訴它繼續(xù)執(zhí)行如果拒絕則 Harness 收到終止指令標記任務為rejected。整個流程的每一步都寫入審計日志誰審批的、什么時候?qū)徟?、原始方案是什么全部留痕。這套流程最大的好處是“可回滾”。即使 Agent 生成的方案有誤只要用戶不點通過不會產(chǎn)生任何實際影響即使審批通過后執(zhí)行出錯審計日志里也有完整鏈路可以追溯。后臺系統(tǒng)要的是可控不是智能。再聰明的 Agent如果沒有人工兜底在后臺管理系統(tǒng)里就是定時炸彈。4. 后臺管理系統(tǒng)的改造點菜單、權(quán)限、消息流把 Agent 能力和后臺管理系統(tǒng)真正融合不只是多一個接口的事而是要在前端界面、后端權(quán)限、消息通知這三個層面做一次系統(tǒng)性改造。下面按改造順序展開講。4.1 前端菜單與操作面板設計我在 Vue3 后臺管理系統(tǒng)的側(cè)邊導航里加了一個“AI 助手”的入口點開后是一個抽屜式操作面板。這個面板不是簡單的聊天框它分三個區(qū)域上方是任務輸入?yún)^(qū)用戶可以直接輸入自然語言指令比如“生成本周華東區(qū)訂單匯總”。中間是任務流狀態(tài)區(qū)展示 Agent 當前執(zhí)行到哪一步、調(diào)用了哪些工具、是否等待審批。數(shù)據(jù)來自后端 WebSocket 推送。下方是歷史任務列表用戶可以重新查看之前的任務結(jié)果、下載生成的文件也能一鍵復跑相似任務。前端和后端約定了一套統(tǒng)一的任務狀態(tài)機created → running → pending_approval → approved/rejected → completed/failed。前端每個狀態(tài)都有對應的 UI 展示避免用戶面對一個黑盒干等。開發(fā)這個面板時有個容易忽略的點頁面刷新后WebSocket 連接會斷開任務狀態(tài)展示會丟失。我的做法是在前端增加一個“恢復現(xiàn)場”機制進入 AI 助手動面板時先調(diào)用后端接口拉取當前會話最近的未完成任務再重新訂閱事件。這樣即使刷新了頁面用戶依然知道剛才的任務跑到了哪一步。4.2 服務端接口與 RBAC 權(quán)限收斂后臺管理系統(tǒng)原本就有 RBAC 權(quán)限體系角色、菜單、按鈕三級控制。接入 Harness 后我沒有另搞一套權(quán)限系統(tǒng)而是把 Agent 的工具調(diào)用映射到原有的權(quán)限點上。具體做法是每個 Harness 工具對應后端一個服務方法方法方法體一開始就做權(quán)限校驗判斷當前調(diào)用是否來自已授權(quán)的角色或用戶。橋接服務收到 Harness 的工具調(diào)用請求時會綁定一個“虛擬用戶”這個虛擬用戶關(guān)聯(lián)的權(quán)限集合由會話發(fā)起人的權(quán)限實時計算得出。也就是說管理員發(fā)起的 Agent 任務和管理員本人操作系統(tǒng)具備相同的權(quán)限。普通運營發(fā)起的任務就按運營的角色權(quán)限走。工具執(zhí)行方法內(nèi)部不再信任外部傳入的角色字段而是重新從數(shù)據(jù)庫加載會話用戶的權(quán)限列表。這套設計核心就一句話Agent 只是操作發(fā)起方權(quán)限校驗必須回到服務端原有的 RBAC 體系里去。我見過一些團隊在 Harness 技能配置里寫死“管理員權(quán)限”那等于給所有能訪問 AI 面板的人發(fā)了一套超級權(quán)限非常危險。還有一個細節(jié)后臺管理系統(tǒng)后端早期在做接口時很多寫操作接口沒有嚴格拆分一個 update 接口可能既允許修改部分字段也允許修改敏感字段。Agent 工具一旦調(diào)用了這種寬接口權(quán)限邊界就很模糊。我把這些寬接口做了收斂給 Agent 調(diào)用單獨定制了細粒度接口只允許傳白名單里的字段。4.3 審批、日志與 Excel 在線預覽打通前面審批機制講了流程這里補一下和現(xiàn)有后臺功能的融合。我在原有的“操作日志”模塊里增加了一個新分類專門記錄 Agent 觸發(fā)的所有動作。日志內(nèi)容包括任務 ID、技能名稱、調(diào)用的工具、輸入?yún)?shù)、輸出摘要、審批人、審批時間、執(zhí)行耗時、錯誤信息。這個日志不僅是審計用途也是 Agent 排錯的第一手資料。Excel 在線預覽的打通更多是在文件服務層做適配。Agent 生成 Excel 文件后文件服務會同時生成一個預覽用的 HTML 版本。后臺管理系統(tǒng)的“報表中心”頁面原本就支持在詳情頁展示文件我復用了這一套展示邏輯讓 Agent 生成的文件也走同一個預覽入口。用戶不需要下載文件直接在頁面上就能看到表格內(nèi)容還能按列排序、搜索。實測下來運營同事對這個改動尤其滿意因為他們最煩的就是下載、打開、關(guān)掉這個循環(huán)。審批流和文件預覽還有一個聯(lián)動場景Agent 生成 Excel 后如果技能標記為write_approved文件本身不會直接對用戶可見而是等審批通過后才會出現(xiàn)在附件列表里。這樣既保證了敏感信息不泄漏又不影響審批人先預覽內(nèi)容做決策。5. 上線前排錯與性能調(diào)優(yōu)記錄任何系統(tǒng)都是測出來的不是設計出來的。Harness 集成這種跨進程、跨端點的項目真實環(huán)境里會遇到很多文檔里沒寫的坑。這一節(jié)記錄三個我踩得最重的坑以及對應的排查過程。5.1 連接不穩(wěn)定Harness 進程存活與自動重啟內(nèi)網(wǎng)服務器跑了兩天后突然發(fā)現(xiàn) Agent 面板上的任務全部卡在created狀態(tài)前端怎么刷新都不動。第一反應是網(wǎng)絡問題但后臺管理系統(tǒng)本身一切正常。后來排查發(fā)現(xiàn)Harness 的桌面端進程在前一天晚上被系統(tǒng)更新彈窗干擾后異常退出了但窗口圖標還在任務欄殘留看起來好像活著實際上服務端口已經(jīng)不再響應。這個問題暴露了一個盲區(qū)我一開始把 Harness 當成普通桌面軟件忘了它是一個需要長期穩(wěn)定運行的服務進程。修復方案有兩步。第一步是做進程守護。我在服務器上給 Harness 進程注冊了一個系統(tǒng)服務設置失敗后自動重啟。如果服務器環(huán)境允許還可以用 Docker 把 Harness 服務化但我這邊的內(nèi)網(wǎng)環(huán)境有限制所以用了輕量級的方式。第二步是讓橋接服務具備心跳感知。橋接服務每隔 15 秒輪詢一次 Harness 的健康檢查接口連續(xù)兩次沒有響應就標記為“Agent 服務不可用”同時在前端面板頂部顯示告警橫幅避免用戶提交任務后像之前一樣石沉大海。任務提交時如果檢測到 Harness 不可用直接返回“AI 服務正在維護中請稍后再試”。這個優(yōu)化雖然不起眼但省掉了大量“任務到底跑沒跑”的困惑。5.2 長任務超時與任務取消機制第二個坑是長任務超時。銷售日報生成這個技能在處理單日訂單時只花了幾秒但一旦用戶指定“生成本季度日報”工具鏈里要查詢的訂單數(shù)據(jù)量劇增整個任務跑了兩三分鐘還沒結(jié)束。而橋接服務當初給 Harness 回調(diào)超時時間設的是 60 秒結(jié)果前端直接報錯用戶以為功能壞了。我把超時策略改成了分層設計工具調(diào)用級別的超時仍然保留單次查詢超過 60 秒就會中斷并給 Agent 返回“查詢超時請縮小數(shù)據(jù)范圍”的提示。任務級別的超時放寬到 30 分鐘Harness 側(cè)支持任務持續(xù)執(zhí)行橋接服務只負責狀態(tài)轉(zhuǎn)發(fā)不再強制中斷整個任務。前端增加了一個“取消任務”按鈕用戶發(fā)現(xiàn) Agent 跑偏了可以主動終止。取消動作會同步發(fā)給 HarnessHarness 的運行時負責停止正在執(zhí)行的工具鏈。這個改動背后有個思考后臺管理系統(tǒng)里的任務既有毫秒級的查詢也有分鐘級的報表任務不能一刀切。超時策略要圍繞任務類型來定而不是所有任務共用一套配置。5.3 權(quán)限繞過的排查與修復最讓我緊張的一個坑發(fā)生在權(quán)限校驗上。測試同事發(fā)現(xiàn)在 AI 面板里用普通運營賬號發(fā)起一個“導出客戶信息”的任務按道理技能配置里沒有這個功能會被系統(tǒng)拒絕但實際跑出來的結(jié)果里居然包含了一條客戶記錄的導出鏈接。排查鏈路是這樣的先看審計日志發(fā)現(xiàn)任務確實觸發(fā)了customers.query_detail工具但會話用戶權(quán)限里并沒有這個工具的對應權(quán)限。再看技能配置發(fā)現(xiàn)這個工具是通過“匯總報表”技能的report.excel_export工具間接被調(diào)用的因為該技能的工具列表里漏掉了對內(nèi)部依賴的聲明Harness 運行時生成了新的工具組合。最后定位到根因我在工具實現(xiàn)里默認信任了技能聲明的權(quán)限級別而沒有在服務端執(zhí)行前重新做會話級權(quán)限越權(quán)校驗。修復方案是雙管齊下一是補全技能工具依賴聲明不讓模型在技能聲明之外自由引入額外工具二是在服務端工具執(zhí)行方法的最前面增加一個“權(quán)限預檢”邏輯無論 Harness 認為這個請求屬于什么技能服務端都會加載會話用戶的真實權(quán)限再判斷該工具是否可以執(zhí)行。權(quán)限預檢通過才真正調(diào)用業(yè)務方法。這個坑讓我強烈意識到外部系統(tǒng)傳來的任何元信息包括技能權(quán)限級別都不能當作安全邊界。真正的邊界必須收斂在自己這邊的服務端代碼里。后來我在代碼評審里定了一條規(guī)則所有需要對外的工具接口禁止在方法內(nèi)部使用調(diào)用方傳入的權(quán)限判斷結(jié)果必須重新取數(shù)、重新判斷。整個項目上線后回過頭看最有價值的其實不是某個具體的技能寫得多聰明而是這套“Harness 后臺管理系統(tǒng)”的組合終于把大模型的能力裝進了可控的企業(yè)應用框架內(nèi)?，F(xiàn)在同事們每天在系統(tǒng)里自然語言發(fā)任務權(quán)限不會越界審批有跡可循文件統(tǒng)一沉淀在后臺附件庫。后續(xù)如果有精力我還想把更多日常重復操作拆成更細粒度的工具讓 Agent 能覆蓋更多工作流。但前提永遠不變先守住邊界再談智能。