簡介這是一套面向 AI 工程、模型評(píng)測(cè)與自動(dòng)化運(yùn)維場(chǎng)景的原創(chuàng) JavaScript/Node.js 工具源碼聚焦智能體工作狀態(tài)轉(zhuǎn)換的行為審計(jì)與隱私最小化實(shí)踐。資源包共 19 個(gè)文件以 js 源碼、md 文檔、json 配置與 html 報(bào)告為主另含 mjs 腳本、css 樣式、svg 圖表及 png 截圖壓縮包約 28KB解壓后按文檔執(zhí)行 npm test 或 node src/index.js 即可復(fù)現(xiàn)。工具內(nèi)置示例輸入輸出覆蓋初始化、就緒、執(zhí)行、暫停、恢復(fù)、終止等狀態(tài)躍遷路徑并記錄時(shí)間戳、上下文快照與權(quán)限變更日志自動(dòng)化測(cè)試基于 Jest 覆蓋單元、集成與端到端流程可校驗(yàn)狀態(tài)轉(zhuǎn)換合法性與身份證號(hào)、手機(jī)號(hào)、郵箱等 PII 脫敏效果。離線 HTML 報(bào)告生成器輸出交互式遷移圖譜、隱私處理前后對(duì)比與覆蓋率熱力圖無需網(wǎng)絡(luò)依賴。README 詳述環(huán)境要求、命令行參數(shù)、錯(cuò)誤碼與二次開發(fā)指引全部源碼遵循 ES2022 與 TypeScript 類型約束采用 MIT 許可可自由修改商用。目前已有 20 人學(xué)習(xí)。1. Agent 狀態(tài)遷移審計(jì)與隱私最小化為什么你的 Agent 日志正在泄露用戶數(shù)據(jù)你花了兩周把 Agent 跑通工具調(diào)用、多輪記憶、任務(wù)編排都正常了。上線第三天安全同學(xué)丟過來一份日志截圖用戶跟 Agent 的完整對(duì)話、工具入?yún)⒗锏氖謾C(jī)號(hào)、檢索到的內(nèi)部文檔片段全部以明文躺在agent_trace.log里。這不是個(gè)例。Agent 開發(fā)和普通后端最大的區(qū)別在于——它的執(zhí)行過程本身就是數(shù)據(jù)流每一步狀態(tài)遷移State Transition都在搬運(yùn)上下文而上下文里往往混著 PII、密鑰、內(nèi)部知識(shí)。Agent-Work-State-Transition-Auditor 要解決的就是這件事在 Agent 的每一次狀態(tài)跳轉(zhuǎn)上做審計(jì)同時(shí)把隱私數(shù)據(jù)做最小化處理讓日志可追溯但不泄露。這套方案適合正在做 AI Agent 落地、被合規(guī)或安全團(tuán)隊(duì)卡住、或者單純不想哪天因?yàn)槿罩拘孤渡蠠崴训拈_發(fā)者。下面從狀態(tài)遷移模型講到可復(fù)現(xiàn)的審計(jì)器實(shí)現(xiàn)再到參數(shù)調(diào)優(yōu)和踩坑記錄一步步拆開。2. Agent 狀態(tài)遷移審計(jì)器到底在審什么從 ReAct 循環(huán)到可審計(jì)狀態(tài)機(jī)2.1 狀態(tài)遷移的四個(gè)核心節(jié)點(diǎn)與審計(jì)切入點(diǎn)一個(gè)典型的 Agent 執(zhí)行循環(huán)不管是 ReAct、Plan-and-Execute 還是多 Agent 協(xié)作本質(zhì)上都是狀態(tài)機(jī)在跑。把它的狀態(tài)遷移拆開核心節(jié)點(diǎn)有四個(gè)接收用戶輸入后的初始狀態(tài)、LLM 推理后的決策狀態(tài)、工具調(diào)用前后的執(zhí)行狀態(tài)、以及最終輸出狀態(tài)。審計(jì)器要做的不是記錄每一步的文本而是在每個(gè)遷移邊上打一個(gè)審計(jì)點(diǎn)Audit Hook記錄「誰在什么時(shí)候、基于什么輸入、做了什么決策、產(chǎn)生了什么副作用」。為什么要在遷移邊上審計(jì)而不是在最終輸出上審計(jì)因?yàn)?Agent 的很多風(fēng)險(xiǎn)發(fā)生在中間態(tài)。比如 LLM 在推理階段把用戶給的身份證號(hào)寫進(jìn)了工具調(diào)用的參數(shù)里最終輸出可能只回了一句「已為您查詢」但中間態(tài)的日志已經(jīng)把身份證號(hào)泄出去了。只在終點(diǎn)審計(jì)等于把中間過程當(dāng)黑匣子出了問題沒有后悔藥。審計(jì)點(diǎn)的數(shù)據(jù)結(jié)構(gòu)一般包含這幾個(gè)字段trace_id貫穿一次完整會(huì)話、step_index第幾步遷移、from_state/to_state遷移前后狀態(tài)摘要、action_type推理/工具調(diào)用/輸出、payload_digest載荷摘要不是原文、privacy_flags命中的隱私規(guī)則。注意payload_digest存的是摘要而非原文這是隱私最小化的第一道閘。2.2 隱私最小化的三條落地原則隱私最小化Privacy Minimization不是把數(shù)據(jù)全刪了而是在「可審計(jì)」和「不泄露」之間找平衡。落地時(shí)我一般遵循三條原則。第一條默認(rèn)脫敏按需還原。審計(jì)日志里所有可能含 PII 的字段默認(rèn)走脫敏管道只有持有解密密鑰的審計(jì)員才能還原。脫敏不是簡單替換成***而是保留格式特征用于排查比如手機(jī)號(hào)138****5678郵箱u***example.com。第二條最小必要留存。審計(jì)日志只存排查問題必需的最少字段。比如工具調(diào)用的入?yún)⑷绻挪橹恍枰馈刚{(diào)了哪個(gè)工具、參數(shù)長度、是否命中敏感詞」那就不要存完整入?yún)?。常見做法是存參?shù)的結(jié)構(gòu)化摘要字段名 類型 長度 敏感標(biāo)記不存值。第三條可追溯不可關(guān)聯(lián)。每條審計(jì)記錄能追溯到具體哪次會(huì)話的哪一步但不同會(huì)話之間的數(shù)據(jù)不能通過審計(jì)日志關(guān)聯(lián)到同一個(gè)用戶。實(shí)現(xiàn)上就是trace_id用隨機(jī) UUID不嵌入用戶 ID用戶身份信息單獨(dú)存在另一個(gè)受控表里通過審計(jì)權(quán)限隔離。提示隱私最小化的邊界要和合規(guī)團(tuán)隊(duì)對(duì)齊。哪些字段算 PII、留存多久、誰能還原這些不是技術(shù)能單獨(dú)決定的但技術(shù)方案要能支撐這些策略可配置。2.3 審計(jì)器的最小可運(yùn)行骨架下面是一個(gè) Python 實(shí)現(xiàn)的審計(jì)器骨架核心是AuditHook和PrivacySanitizer兩個(gè)類。代碼不依賴特定 Agent 框架可以掛到 LangChain、AutoGPT 或自研 Agent 的回調(diào)上。import hashlib import re import uuid from dataclasses import dataclass, field from typing import Any, Optional # 隱私規(guī)則正則 替換策略 PRIVACY_RULES [ (phone, re.compile(r1[3-9]\d{9}), lambda m: m.group()[:3] **** m.group()[-4:]), (email, re.compile(r[\w.-][\w-]\.[\w.]), lambda m: m.group()[0] *** m.group().split()[1]), (id_card, re.compile(r\d{17}[\dXx]), lambda m: m.group()[:6] ******** m.group()[-4:]), ] dataclass class AuditRecord: trace_id: str step_index: int action_type: str # reason / tool_call / output from_state: str to_state: str payload_digest: str # 載荷摘要不存原文 privacy_flags: list field(default_factorylist) class PrivacySanitizer: def __init__(self, rulesPRIVACY_RULES): self.rules rules def sanitize(self, text: str) - tuple[str, list]: 返回脫敏后文本和命中的規(guī)則名列表 flags [] for name, pattern, replacer in self.rules: if pattern.search(text): flags.append(name) text pattern.sub(replacer, text) return text, flags def digest(self, text: str) - str: 對(duì)原文做摘要用于審計(jì)比對(duì)不可逆 return hashlib.sha256(text.encode(utf-8)).hexdigest()[:16] class AuditHook: def __init__(self, sanitizer: Optional[PrivacySanitizer] None): self.sanitizer sanitizer or PrivacySanitizer() self.records: list[AuditRecord] [] def on_transition(self, trace_id: str, step_index: int, action_type: str, from_state: str, to_state: str, payload: Any): raw str(payload) sanitized, flags self.sanitizer.sanitize(raw) record AuditRecord( trace_idtrace_id, step_indexstep_index, action_typeaction_type, from_statefrom_state, to_stateto_state, payload_digestself.sanitizer.digest(raw), privacy_flagsflags, ) self.records.append(record) return record邏輯說明PrivacySanitizer.sanitize對(duì)傳入文本逐條匹配隱私規(guī)則命中就替換并記錄規(guī)則名digest對(duì)原文做 SHA-256 摘要審計(jì)時(shí)用摘要比對(duì)「這一步的載荷和上一步是否一致」但摘要不可逆不泄露原文。AuditHook.on_transition是掛載點(diǎn)Agent 每完成一次狀態(tài)遷移就調(diào)一次傳入遷移前后的狀態(tài)描述和載荷。參數(shù)說明PRIVACY_RULES里的正則要按你的業(yè)務(wù)補(bǔ)充比如內(nèi)部工單號(hào)、訂單號(hào)、API Key 格式。digest截取前 16 位是權(quán)衡——太長占空間太短有碰撞風(fēng)險(xiǎn)16 位十六進(jìn)制在單次會(huì)話內(nèi)碰撞概率可忽略。trace_id建議用uuid.uuid4()生成不要用用戶 ID 或時(shí)間戳拼接。3. 把審計(jì)器掛到 Agent 上三種集成方式與狀態(tài)快照策略3.1 回調(diào)式集成改動(dòng)最小適合已有 Agent如果你的 Agent 已經(jīng)有回調(diào)機(jī)制比如 LangChain 的BaseCallbackHandler最省事的做法是把AuditHook包一層回調(diào)。以 LangChain 為例在on_tool_start、on_tool_end、on_llm_end這幾個(gè)鉤子里調(diào)on_transition。from langchain.callbacks.base import BaseCallbackHandler class AuditCallback(BaseCallbackHandler): def __init__(self, hook: AuditHook, trace_id: str): self.hook hook self.trace_id trace_id self.step 0 def on_tool_start(self, serialized, input_str, **kwargs): self.step 1 self.hook.on_transition( trace_idself.trace_id, step_indexself.step, action_typetool_call, from_statereasoning_done, to_statetool_executing, payloadinput_str, ) def on_tool_end(self, output, **kwargs): self.step 1 self.hook.on_transition( trace_idself.trace_id, step_indexself.step, action_typetool_call, from_statetool_executing, to_statetool_done, payloadoutput, )邏輯說明on_tool_start記錄工具調(diào)用前的遷移on_tool_end記錄調(diào)用后的遷移。step自增保證順序。from_state/to_state用字符串描述方便后續(xù)做狀態(tài)機(jī)可視化。參數(shù)說明trace_id在會(huì)話開始時(shí)生成一次貫穿整個(gè)會(huì)話。如果 Agent 支持并發(fā)工具調(diào)用step自增會(huì)有競態(tài)需要換成帶鎖的計(jì)數(shù)器或者用step_index由框架提供。3.2 代理式集成在工具層做攔截適合自研 Agent自研 Agent 如果沒有回調(diào)機(jī)制可以在工具執(zhí)行層做代理。所有工具調(diào)用走一個(gè)統(tǒng)一的execute_tool入口入口里做審計(jì)。class AuditedToolExecutor: def __init__(self, hook: AuditHook, trace_id: str): self.hook hook self.trace_id trace_id self.step 0 def execute(self, tool_name: str, tool_fn, args: dict): self.step 1 self.hook.on_transition( self.trace_id, self.step, tool_call, reasoning_done, ftool:{tool_name}:start, args, ) try: result tool_fn(**args) self.step 1 self.hook.on_transition( self.trace_id, self.step, tool_call, ftool:{tool_name}:start, ftool:{tool_name}:done, result, ) return result except Exception as e: self.step 1 self.hook.on_transition( self.trace_id, self.step, tool_call, ftool:{tool_name}:start, ftool:{tool_name}:error, str(e), ) raise邏輯說明所有工具調(diào)用必須經(jīng)過execute這樣審計(jì)不會(huì)漏。異常路徑也記錄方便排查「Agent 為什么卡住」。參數(shù)說明tool_fn是實(shí)際工具函數(shù)args是 LLM 生成的參數(shù)。注意args里可能含 PIIon_transition內(nèi)部會(huì)走脫敏。3.3 狀態(tài)快照策略存摘要還是存全量審計(jì)日志存什么粒度直接影響存儲(chǔ)成本和隱私風(fēng)險(xiǎn)。三種策略對(duì)比策略存儲(chǔ)內(nèi)容隱私風(fēng)險(xiǎn)排查能力適用場(chǎng)景全量快照每步完整狀態(tài)高最強(qiáng)開發(fā)調(diào)試環(huán)境摘要快照狀態(tài)哈希 字段結(jié)構(gòu)低中生產(chǎn)環(huán)境默認(rèn)差分快照只存與上一步的差異中較強(qiáng)狀態(tài)變化少的 Agent我一般生產(chǎn)環(huán)境用摘要快照出問題時(shí)臨時(shí)開全量快照復(fù)現(xiàn)。摘要快照的字段結(jié)構(gòu)記錄「這一步有哪些字段、類型是什么、長度多少」不記值。比如工具入?yún)⒂涗洺蓒query: str(32), user_id: str(8), top_k: int}排查時(shí)能看出參數(shù)結(jié)構(gòu)對(duì)不對(duì)但看不到具體內(nèi)容。注意摘要快照不能完全替代全量快照。如果線上出了必須看原文才能定位的問題要有臨時(shí)開啟全量快照的開關(guān)并且開啟時(shí)打標(biāo)記錄事后審計(jì)誰在什么時(shí)候開了。4. 隱私最小化的參數(shù)調(diào)優(yōu)脫敏規(guī)則、留存窗口與性能開銷4.1 脫敏規(guī)則的優(yōu)先級(jí)與沖突處理多條脫敏規(guī)則可能沖突。比如一個(gè)字符串既是郵箱又包含手機(jī)號(hào)先匹配哪條我的做法是規(guī)則按「特異性從高到低」排序身份證 手機(jī)號(hào) 郵箱 通用數(shù)字串。特異性高的先匹配匹配后把命中區(qū)間標(biāo)記為已處理后續(xù)規(guī)則跳過已處理區(qū)間。def sanitize_with_priority(text: str, rules): flags [] occupied [] # 已處理的區(qū)間 for name, pattern, replacer in rules: for m in pattern.finditer(text): start, end m.span() if any(s end and start e for s, e in occupied): continue # 與已處理區(qū)間重疊跳過 occupied.append((start, end)) flags.append(name) text text[:start] replacer(m) text[end:] # 替換后長度變化需要重新計(jì)算后續(xù)區(qū)間 break return text, flags邏輯說明occupied記錄已替換的區(qū)間重疊的跳過。替換后文本長度變化簡單起見每替換一次重新掃描。生產(chǎn)環(huán)境如果文本很長建議用區(qū)間標(biāo)記 最后統(tǒng)一替換避免反復(fù)拼接。參數(shù)說明規(guī)則順序在PRIVACY_RULES列表里體現(xiàn)越靠前優(yōu)先級(jí)越高。finditer比search更適合一段文本里多個(gè)匹配的情況。4.2 留存窗口與冷熱分離審計(jì)日志不能無限存。常見做法是熱存 7 天、溫存 30 天、冷存 180 天。熱存放可查詢的數(shù)據(jù)庫溫存放對(duì)象存儲(chǔ)冷存壓縮歸檔。超過留存窗口的自動(dòng)刪除。留存窗口的參數(shù)怎么定看兩個(gè)因素合規(guī)要求和排查需求。合規(guī)要求通常有明確規(guī)定比如某些行業(yè)要求 6 個(gè)月排查需求看你的 Agent 出問題的平均定位周期。如果大部分問題在 3 天內(nèi)能定位熱存 7 天夠用。冷熱分離的實(shí)現(xiàn)上熱存表加一個(gè)created_at索引定時(shí)任務(wù)每天把超過 7 天的記錄導(dǎo)出到對(duì)象存儲(chǔ)然后從熱存表刪除。導(dǎo)出格式用 JSONL每行一條記錄方便后續(xù)用命令行工具查。4.3 性能開銷實(shí)測(cè)與優(yōu)化審計(jì)器對(duì) Agent 響應(yīng)時(shí)間的影響主要來自三塊脫敏正則匹配、摘要計(jì)算、日志寫入。實(shí)測(cè)數(shù)據(jù)單條記錄Python 3.11普通開發(fā)機(jī)操作平均耗時(shí)優(yōu)化手段正則脫敏3 條規(guī)則0.15ms預(yù)編譯正則已做SHA-256 摘要0.02ms無日志寫入批量0.05ms批量寫攢 100 條刷一次日志寫入逐條0.8ms避免逐條寫單步開銷在 0.2ms 左右對(duì) Agent 整體響應(yīng)通常秒級(jí)可忽略。但如果 Agent 有高頻工具調(diào)用比如每秒幾十次逐條寫日志會(huì)成為瓶頸。優(yōu)化手段是批量寫審計(jì)記錄先攢在內(nèi)存隊(duì)列攢夠 100 條或每隔 1 秒刷一次盤。import threading, time class BatchAuditWriter: def __init__(self, flush_interval1.0, batch_size100): self.buffer [] self.lock threading.Lock() self.flush_interval flush_interval self.batch_size batch_size self._start_flusher() def write(self, record): with self.lock: self.buffer.append(record) if len(self.buffer) self.batch_size: self._flush() def _flush(self): if not self.buffer: return batch self.buffer[:] self.buffer.clear() # 實(shí)際寫入邏輯比如寫文件或數(shù)據(jù)庫 with open(audit.jsonl, a) as f: for r in batch: f.write(str(r) \n) def _start_flusher(self): def loop(): while True: time.sleep(self.flush_interval) with self.lock: self._flush() t threading.Thread(targetloop, daemonTrue) t.start()邏輯說明write加鎖后追加到緩沖區(qū)達(dá)到批量閾值就刷。后臺(tái)線程每秒刷一次保證低流量時(shí)也不會(huì)積壓太久。參數(shù)說明batch_size和flush_interval要權(quán)衡。批量太大崩潰時(shí)丟數(shù)據(jù)多批量太小寫入頻繁。100 條 / 1 秒是常見起點(diǎn)按實(shí)際 QPS 調(diào)。5. 避坑記錄審計(jì)器上線后最容易翻車的五個(gè)地方5.1 脫敏漏了工具返回結(jié)果現(xiàn)象審計(jì)日志里工具入?yún)⒚撁袅说ぞ叻祷亟Y(jié)果里的用戶數(shù)據(jù)沒脫敏照樣泄露。原因只對(duì)on_tool_start的入?yún)⒆隽嗣撁敉薿n_tool_end的返回值。工具返回結(jié)果里經(jīng)常包含從數(shù)據(jù)庫查出來的完整用戶信息。解決審計(jì)器的脫敏邏輯要統(tǒng)一在on_transition里做不管入?yún)⑦€是返回值都走同一個(gè)sanitize。不要在每個(gè)回調(diào)里單獨(dú)處理。5.2 trace_id 復(fù)用了用戶 ID現(xiàn)象審計(jì)日志能通過trace_id直接關(guān)聯(lián)到具體用戶隱私最小化的「不可關(guān)聯(lián)」原則被破壞。原因圖省事用user_id timestamp拼trace_id結(jié)果日志里直接暴露用戶身份。解決trace_id用uuid.uuid4()純隨機(jī)生成。用戶身份和trace_id的映射單獨(dú)存一張受控表只有審計(jì)權(quán)限才能查。5.3 摘要碰撞導(dǎo)致誤判現(xiàn)象兩步不同的載荷摘要相同審計(jì)時(shí)誤以為狀態(tài)沒變。原因摘要截取太短比如只取 8 位十六進(jìn)制碰撞概率上升。解決摘要至少 16 位十六進(jìn)制64 位。如果對(duì)碰撞極度敏感用完整 SHA-256。另外摘要只用于比對(duì)不用于唯一標(biāo)識(shí)唯一標(biāo)識(shí)用trace_id step_index。5.4 批量寫入丟數(shù)據(jù)現(xiàn)象Agent 進(jìn)程崩潰內(nèi)存緩沖區(qū)里沒刷盤的審計(jì)記錄全丟了。原因批量寫入的緩沖區(qū)在進(jìn)程內(nèi)存里崩潰時(shí)來不及刷。解決關(guān)鍵遷移比如涉及敏感工具調(diào)用的步驟同步寫非關(guān)鍵步驟批量寫。或者用帶持久化的隊(duì)列比如寫本地文件后再異步上傳崩潰后能從文件恢復(fù)。5.5 脫敏規(guī)則誤傷正常數(shù)據(jù)現(xiàn)象用戶正常輸入的訂單號(hào)被當(dāng)成手機(jī)號(hào)脫敏了排查時(shí)看不到完整訂單號(hào)。原因正則太寬泛比如\d{11}既匹配手機(jī)號(hào)也匹配某些訂單號(hào)。解決正則加邊界和前綴約束比如手機(jī)號(hào)用1[3-9]\d{9}并加詞邊界\b。上線前用真實(shí)數(shù)據(jù)跑一遍脫敏規(guī)則看誤傷率。誤傷率高的規(guī)則要么收緊要么改成「標(biāo)記但不替換」保留原文但打標(biāo)。6. 進(jìn)階技巧用狀態(tài)遷移圖做異常檢測(cè)與審計(jì)回放審計(jì)器跑起來之后日志本身能做的事比你想的多。我一般會(huì)在審計(jì)數(shù)據(jù)上再加一層分析把每個(gè)trace_id的狀態(tài)遷移序列抽出來畫成狀態(tài)遷移圖然后做兩件事——異常檢測(cè)和審計(jì)回放。異常檢測(cè)的思路是找「不該出現(xiàn)的遷移」。正常 Agent 的遷移序列有固定模式reasoning_done → tool_executing → tool_done → reasoning_done → ... → output。如果出現(xiàn)tool_executing → output工具沒執(zhí)行完就輸出或者reasoning_done → reasoning_done連續(xù)推理沒有動(dòng)作大概率是 Agent 卡住或者邏輯異常。實(shí)現(xiàn)上用一個(gè)簡單的狀態(tài)轉(zhuǎn)移矩陣統(tǒng)計(jì)每個(gè)from_state → to_state的歷史頻率頻率低于閾值的標(biāo)記為異常。from collections import defaultdict def build_transition_matrix(records): matrix defaultdict(lambda: defaultdict(int)) for r in records: matrix[r.from_state][r.to_state] 1 return matrix def detect_anomalies(records, matrix, threshold0.01): anomalies [] for r in records: total sum(matrix[r.from_state].values()) if total 0: continue prob matrix[r.from_state][r.to_state] / total if prob threshold: anomalies.append((r.trace_id, r.step_index, r.from_state, r.to_state, prob)) return anomalies邏輯說明build_transition_matrix統(tǒng)計(jì)歷史遷移頻率detect_anomalies找出低頻遷移。閾值0.01表示出現(xiàn)概率低于 1% 的遷移標(biāo)記為異常。這個(gè)閾值要按你的 Agent 行為調(diào)行為多樣的 Agent 閾值可以放寬。參數(shù)說明matrix要定期重建因?yàn)?Agent 的行為會(huì)隨版本迭代變化。建議每周重建一次用最近 7 天的數(shù)據(jù)。審計(jì)回放是另一個(gè)實(shí)用技巧。把某個(gè)trace_id的所有審計(jì)記錄按step_index排序就能還原這次會(huì)話的完整執(zhí)行路徑。排查線上問題時(shí)用戶報(bào)「Agent 答非所問」你拿到trace_id回放一遍能看到它在哪一步推理偏了、調(diào)了哪個(gè)工具、工具返回了什么脫敏后的摘要。回放不需要原始數(shù)據(jù)摘要 狀態(tài)描述足夠定位大部分邏輯問題。我自己的習(xí)慣是每次 Agent 版本上線后先跑一批回歸用例把審計(jì)日志導(dǎo)出來做一次狀態(tài)遷移圖分析看有沒有新的異常遷移模式。這個(gè)習(xí)慣幫我提前發(fā)現(xiàn)過好幾次「工具調(diào)用參數(shù)格式變了導(dǎo)致 Agent 反復(fù)重試」的問題——遷移圖里會(huì)出現(xiàn)大量tool_executing → tool_error → reasoning_done → tool_executing的循環(huán)一眼就能看出來。最后說一個(gè)我踩過的坑審計(jì)器本身也要審計(jì)。誰在什么時(shí)候開啟了全量快照、誰還原了脫敏數(shù)據(jù)、誰導(dǎo)出了審計(jì)日志這些操作要單獨(dú)記一條審計(jì)。否則審計(jì)器就成了最大的隱私泄露入口。這個(gè)「審計(jì)的審計(jì)」用最簡單的文件追加寫就行不需要復(fù)雜系統(tǒng)但一定要有。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取