這次我們不聊具體模型也不聊某個 ComfyUI 工作流而是聊一個更底層的問題AI Agent 為什么不能只是一個 Prompt 盒子。標(biāo)題里的 Real Identity 和刷臉無關(guān)它指的不是用戶的身份證而是 Agent 自己在系統(tǒng)里的真實身份我是誰、能干什么、不能干什么、什么情況下應(yīng)該把問題交給人。很多團(tuán)隊做 Agent 的方式是在系統(tǒng)提示詞里寫一句“你是一個貼心的客服”然后把模型接口一接就上線。短期看沒問題進(jìn)入生產(chǎn)后就會遇到同一批問題角色漂移、越權(quán)調(diào)用工具、多輪對話后忘記邊界、同一個 Prompt 換個場景就失效。先說結(jié)論Real Identity 不是一個玄學(xué)概念它由五件具體的事情組成角色定義、主題邊界、記憶策略、工具權(quán)限、響應(yīng)協(xié)議。把這五件事固化下來Agent 才從 Prompt Box 變成可測試、可審計、可批量部署的工程實體。這篇文章會先梳理 Prompt、Skill、Identity 三者的關(guān)系再給一個用 JSON 配置文件加通用模型 API 組裝 System Prompt 的最小實現(xiàn)最后討論多 Agent 協(xié)同里的身份隔離、Token 成本、常見異常排查。適合正在做客服 Agent、知識庫助手、多 Agent 系統(tǒng)或者準(zhǔn)備把 Agent 接入生產(chǎn)環(huán)境的開發(fā)者。1. 核心能力速覽Identity 層到底管什么維度說明目標(biāo)讓 Agent 在不同任務(wù)、不同會話、不同工具調(diào)用中保持穩(wěn)定且可控的行為邊界核心組成角色聲明、主題邊界、記憶策略、工具白名單、升級/響應(yīng)協(xié)議主要解決的問題角色漂移、越權(quán)工具調(diào)用、多輪上下文污染、Prompt 復(fù)用性差、Agent 行為不可審計不解決的問題不解決模型本身的能力上限也不替代 RAG、微調(diào)、工作流引擎落地載體System Prompt 模板、JSON Profile 配置、Agent 路由規(guī)則、記憶存儲策略評估指標(biāo)角色保持率、工具命中率、越權(quán)攔截率、上下文 Token 增量、人工升級率從工程角度看Identity 層更像是 Agent 的“應(yīng)用層協(xié)議”。模型負(fù)責(zé)生成文本工具負(fù)責(zé)執(zhí)行動作而身份層負(fù)責(zé)約束這一整條鏈路。沒有身份層的 Agent本質(zhì)上是一個裸模型加一段 Prompt有身份層的 Agent才是一個完整的業(yè)務(wù)系統(tǒng)。2. 適用場景與使用邊界2.1 適合誰如果你在開發(fā)客服機器人、知識庫問答助手、企業(yè)內(nèi)部流程 Agent或者在做多 Agent 協(xié)同系統(tǒng)Identity 層是剛需?？头鼍袄顰gent 需要知道自己只能查訂單、只能退換貨、不能承諾賠償金額知識庫場景里Agent 需要知道自己只能基于已入庫文檔回答不能拿訓(xùn)練記憶里的舊知識來混答多 Agent 場景里每個子 Agent 必須有獨立的身份文件否則很容易互相串臺。2.2 不適合什么場景如果只是做一次性的文本生成 Demo用 Prompt 就夠了不需要單獨設(shè)計 Identity 層。如果 Agent 完全在一個封閉的工作流里執(zhí)行固定腳本沒有自由對話也沒有模型自主決策空間身份層能提供的價值也有限。Identity 層的價值出現(xiàn)在“模型需要自己做判斷”的場景里判斷越多約束越重要。2.3 合規(guī)與安全邊界這里需要反復(fù)強調(diào)三點。第一Agent 的身份不能冒充真人。任何面向用戶的 AI Agent都應(yīng)該在適當(dāng)位置告知用戶它是由 AI 驅(qū)動的不能偽裝成人類客服、人類醫(yī)生或人類顧問。第二涉及用戶數(shù)據(jù)時記憶策略必須明確哪些字段可以存儲、哪些字段禁止存儲賬號密碼、身份證號、支付賬戶這類敏感信息不能進(jìn) Agent 的記憶。第三涉及肖像、聲音、品牌形象的場景必須確認(rèn)授權(quán)。這不是額外負(fù)擔(dān)而是 Agent 上生產(chǎn)前的基本條件。3. Prompt、Skill、Identity 三者到底差在哪不少開發(fā)者問過一個問題Skill 是不是就是高級版的 Prompt從使用體驗上看兩者有點像Skill 看起來像是把多個 Prompt、示例和工具調(diào)用封裝成了一個可復(fù)用單元。但本質(zhì)上它們處于不同的抽象層級。Prompt 是單次會話指令解決的是“這一次讓模型做什么”。比如“把這段文字總結(jié)成三條要點”這是一個 Prompt。它沒有跨會話的穩(wěn)定性也沒有跨任務(wù)的約束力。Skill 是程序化技能單元解決的是“一類任務(wù)怎么做”。它可能包含 Prompt 模板、Few-Shot 示例、參數(shù)校驗邏輯甚至包含對工具調(diào)用的編排。Skill 可以被多個 Agent 復(fù)用但它本身不定義“誰在使用它”。Identity 則是跨會話、跨技能、跨工具的穩(wěn)定框架解決的是“模型在整個系統(tǒng)里以什么身份、按什么規(guī)則行動”。Identity 決定一個 Skill 能不能被調(diào)用、記錄什么樣的記憶、回復(fù)采用什么風(fēng)格。概念作用范圍典型載體是否可復(fù)用是否定義主體Prompt單次輸入一段文本通常不可直接復(fù)用否Skill一類任務(wù)模板 示例 校驗邏輯可以跨 Agent 復(fù)用否Identity整個 Agent 的生命周期Profile 配置 記憶策略 工具白名單可模板化但需按場景定制是所以把 Agent 做強不等于把 Prompt 寫長。真正的做法是先把 Identity 固定下來再掛載對應(yīng)的 Skill最后才談單次 Prompt 怎么寫。4. 設(shè)計 Real Identity 的最小工程前置開始寫代碼之前先回答五個問題。缺一個身份層都是殘缺的。第一Agent 的職責(zé)邊界是什么。一個客服 Agent 能做到的最精確描述不是“你是一個貼心的客服”而是“你只能處理訂單查詢、退換貨、物流跟蹤不能承諾賠償”。第二用戶是誰。面向 C 端消費者的語言風(fēng)格和面向企業(yè)內(nèi)部運維人員的語言風(fēng)格完全不同。第三哪些工具能用、哪些工具絕對不能用。工具白名單是最容易被忽略的一塊很多 Agent 越權(quán)出問題不是模型的問題是工具列表給得太寬。第四記憶怎么存。哪些信息只在當(dāng)前會話內(nèi)有效哪些信息可以長期保留哪些信息完全禁止采集。第五模型回答不了時怎么辦。身份層應(yīng)該給一條明確的升級路徑而不是讓模型硬編。這些問題形成一份設(shè)計文檔后你的 Agent 就不再是“Prompt 盒子”而是一個有邊界、有記憶、有工具權(quán)限、可審計的系統(tǒng)。5. 最小實現(xiàn)把 Identity 從 Prompt 里拆出來5.1 寫一份 identity.json 配置先不要急著寫 System Prompt先把身份內(nèi)容寫進(jìn)一個結(jié)構(gòu)化配置文件。這樣做的核心好處是可讀、可測試、可批量生成不同 Agent 共用同一套加載邏輯。{ agent_id: support-bot-v1, name: 售后助手, description: 面向電商場景的售后客服 Agent, role: { identity_statement: 你是售后助手只處理訂單、退換貨、物流問題。你不是人類客服。, audience: 購買本店商品并需要售后幫助的消費者, persona: 耐心、直接、不編造承諾, language: zh-CN }, boundaries: { allowed_topics: [訂單查詢, 退換貨, 物流跟蹤], blocked_topics: [價格談判, 醫(yī)療建議, 法律咨詢, 政治評論, 情感陪伴], escalation: 如果用戶要求退款且金額超過500元轉(zhuǎn)人工不自行承諾 }, memory_policy: { session_memory: summary_and_last_5_turns, long_term_memory_keys: [user_id, user_order_status, user_preference], forbidden_memory_keys: [password, id_card, payment_account] }, tool_policy: { allowed_tools: [query_order, create_return, track_logistics], blocked_tools: [refund_immediately, delete_user, send_sms] }, response_style: { max_length: 180, when_unknown: 告知用戶需要人工確認(rèn)并收集訂單號轉(zhuǎn)交 } }這里的字段名可以根據(jù)項目改但職責(zé)劃分建議保留角色、邊界、記憶、工具、回復(fù)風(fēng)格五塊獨立配置盡量不要寫成一坨 Prompt。5.2 寫一個 System Prompt 組裝器配置文件寫好后需要把它渲染成真正的 System Prompt。通用做法是寫一個加載函數(shù)把 JSON 里的字段拼成一段結(jié)構(gòu)清晰的文本。import json def load_identity(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) def build_system_prompt(profile: dict) - str: parts [] role profile.get(role, {}) boundaries profile.get(boundaries, {}) style profile.get(response_style, {}) parts.append(role.get(identity_statement, )) parts.append(f服務(wù)對象{role.get(audience, )}) parts.append(f語言{role.get(language, zh-CN)}) parts.append(允許討論的主題 、.join(boundaries.get(allowed_topics, []))) parts.append(禁止討論的主題 、.join(boundaries.get(blocked_topics, []))) parts.append(升級規(guī)則 boundaries.get(escalation, 轉(zhuǎn)人工)) parts.append(回復(fù)風(fēng)格 style.get(persona, 簡潔)) return \n.join(parts)5.3 把組裝后的 Prompt 發(fā)給模型下面是一個通用的模型 API 調(diào)用示例用 Python requests 完成。實際接入時把 URL 和模型名替換成你正在使用的服務(wù)即可。import requests profile load_identity(identity.json) system_prompt build_system_prompt(profile) user_message 我的訂單顯示已簽收但我沒收到貨。 payload { model: your-model-name, messages: [ {role: system, content: system_prompt}, {role: user, content: user_message} ], temperature: 0.3 } resp requests.post( YOUR_API_ENDPOINT, jsonpayload, timeout60 ) data resp.json() print(data[choices][0][message][content])一個更嚴(yán)格的工程化設(shè)計還會把工具定義也帶進(jìn)請求里。模型只有在身份層的白名單范圍內(nèi)才能在回復(fù)中觸發(fā)工具調(diào)用。不要把所有工具都塞給模型模型不需要知道它不能調(diào)用的工具。5.4 驗證這個最小鏈路啟動后先跑一次最簡單的對話確認(rèn)兩個點System Prompt 是否被正確加載模型回復(fù)是否符合身份聲明。如果回復(fù)里出現(xiàn)了和身份完全無關(guān)的內(nèi)容先檢查配置文件再檢查組裝函數(shù)。鏈路跑通后再往里面加工具、加記憶、加多輪對話。6. Identity 層功能測試與效果驗證6.1 角色一致性測試用同一組問題分別問三次觀察回答口徑是否穩(wěn)定。提問示例“你叫什么名字你能幫我查訂單嗎你能給我賠錢嗎”預(yù)期結(jié)果是Agent 會報出自己的身份名稱會引導(dǎo)用戶提供訂單號拒絕承諾賠償?shù)o出升級路徑。判斷標(biāo)準(zhǔn)是角色保持率如果第一次回答和第三次回答在關(guān)鍵承諾上不一致說明身份約束還沒生效。6.2 工具邊界測試把白名單外的一個工具名放進(jìn)用戶問題里例如“立即幫我退款”。一個合格的 Identity 層會在兩個位置攔截模型不生成對應(yīng)工具調(diào)用或者系統(tǒng)在工具執(zhí)行前做白名單校驗。更穩(wěn)妥的方案是雙重校驗既在 Prompt 里約束又在工具調(diào)度器里強制校驗。6.3 記憶邊界測試先做多輪對話然后主動詢問 Agent 是否記得剛才的細(xì)節(jié)。這里重點驗證的不是模型的記憶能力而是記憶策略是否生效會話摘要有沒有正常寫入已經(jīng)聲明禁止采集的字段有沒有被動進(jìn)入長期記憶。敏感字段的測試必須做比如讓用戶說出銀行卡號然后查看日志里存了什么。這個測試不應(yīng)該跳過。6.4 Token 成本測試把身份配置文件逐步增大觀察每次請求的輸入 Token 增量。這里的判斷標(biāo)準(zhǔn)不是“越短越好”而是“每一段身份描述都必須在實際對話里產(chǎn)生約束作用”。如果某段描述寫了很多次Agent 的行為卻沒有變化這段就是在浪費 Token。7. 多 Agent 協(xié)同中的身份隔離與批量路由當(dāng)你開始做多 Agent 系統(tǒng)時Identity 的價值會放大?？头?Agent、財務(wù) Agent、數(shù)據(jù) Agent 如果共用一個裸 Prompt 框架風(fēng)險極高。每個 Agent 需要有獨立的 identity.json獨立工具白名單最好還要有獨立的記憶空間。下面是一個簡單的多 Agent 路由配置。{ agents: { support-bot: { identity_file: ./identities/support.json, tools: [query_order, create_return] }, finance-bot: { identity_file: ./identities/finance.json, tools: [invoice_query, refund_review] }, data-bot: { identity_file: ./identities/data.json, tools: [log_search, metric_query] } }, router: { strategy: intent_match, fallback: support-bot } }路由層根據(jù)用戶輸入先判斷交給哪個 Agent再把對應(yīng) Agent 的 System Prompt 注入到請求里。這里最容易踩的坑是模型在對話中串了身份比如財務(wù) Agent 突然用客服口吻說話。解決辦法不是加一句“你必須記住你是財務(wù) Agent”而是在每次請求時都重新注入該 Agent 的完整身份配置模型本身不負(fù)責(zé)跨請求記憶身份。批量任務(wù)場景下不同任務(wù)最好帶上各自的 agent_id。這樣日志、回調(diào)、錯誤追蹤都會更容易定位。8. 資源占用與性能觀察Identity 不是免費的Identity 層的每一項約束都會消耗輸入 Token。一個常見的估算方式是以中文為例1000 個漢字大約對應(yīng) 1000 到 2000 Token具體要按模型分詞器實測。如果身份配置寫得非常長再加上 RAG 檢索片段、歷史摘要和工具定義一次請求的輸入 Token 會被快速推高。在實際項目中建議從三個維度觀察成本首輪請求 Token身份配置 工具描述 用戶問題這是基礎(chǔ)消耗。多輪請求 Token歷史摘要的增長方式?jīng)Q定了長會話的成本曲線。工具調(diào)用 Token每次工具調(diào)用會把結(jié)果帶回對話這個增量容易被忽略。降低開銷的方法包括身份配置保持精簡只保留能改變模型行為的描述工具描述控制在兩三行內(nèi)歷史記憶用一個摘要加最近幾輪的形式而不是全部拼進(jìn)上下文對長對話做會話截斷超過閾值后壓縮轉(zhuǎn)人工或新開會話。9. 常見問題與排查方法問題現(xiàn)象可能原因排查方式解決方案多輪對話后角色漂移身份約束只體現(xiàn)在首輪后續(xù)請求沒有重新注入查看后續(xù)請求的 System Prompt 是否包含完整身份配置每次請求都重新組裝 System PromptPrompt 被平臺內(nèi)容策略攔截身份或指令里拼入了敏感/攻擊性內(nèi)容檢查 System Prompt 原文定位被攔截的片段拆分測試每段字段刪除可能觸發(fā)策略的表述模型調(diào)用了白名單外的工具工具列表傳得太寬只靠 Prompt 約束檢查請求體里的 tools 參數(shù)在調(diào)度器層做硬校驗白名單外直接拒絕上下文越來越長響應(yīng)變慢歷史消息全部拼接看每次請求的 messages 長度采用摘要 最近幾輪記憶策略跨會話丟失用戶信息長期記憶沒有落庫檢查記憶寫入流程把關(guān)鍵信息寫入結(jié)構(gòu)化存儲按 user_id 讀取多 Agent 串身份多個 Agent 共用一份 System Prompt查看路由日志里的 agent_id每個 Agent 獨立 identity 文件路由前加載API 返回超時上下文過長或工具調(diào)用過多觀察單次請求耗時和 Token 數(shù)截斷上下文減少工具次數(shù)這里特別說明一下 Prompt 被攔截的問題。在 Agent 開發(fā)中如果把攻擊性、歧視性、誘導(dǎo)越獄的內(nèi)容直接寫進(jìn) System Prompt很多模型的 API 會返回類似“prompt was flagged as potentially violating our usage policy”的提示。這不是模型壞了而是內(nèi)容策略攔住了請求。排查手段很簡單把身份配置拆成小段逐段測試找到觸發(fā)攔截的那一段改寫或刪除。10. 最佳實踐與使用建議第一身份配置當(dāng)代碼管。identity.json 要納入版本管理變更要留記錄。兩個版本的 Agent 行為差異往往就藏在某一行身份描述的變化里。第二先硬約束后自由發(fā)揮。不要一上來就追求“人設(shè)生動”先把 allowed_topics、blocked_topics、tools 白名單定死再慢慢加 persona 風(fēng)格。人設(shè)是加分項邊界是保命項。第三工具權(quán)限最小化。不要一次性把 20 個工具全部傳給模型。模型只需要知道當(dāng)前任務(wù)能用的工具給得越多誤用概率越大。第四把“轉(zhuǎn)人工”作為一等公民。一個好的 Identity 層應(yīng)該明確告訴模型什么情況下必須轉(zhuǎn)人工什么話不能說死。讓模型硬編不確定性信息比它直接承認(rèn)不知道要危險得多。第五做成模板但保留定制空間。你可以做一個標(biāo)準(zhǔn)身份模板但每個業(yè)務(wù)場景都要人工 review 一遍 allowed_topics 和 escalation不要直接套用。第六評估指標(biāo)要上線前定好。角色保持率、越權(quán)攔截率、人工升級率、首輪 Token 數(shù)這四個指標(biāo)建議作為最低評估集。第七涉及用戶隱私和版權(quán)的數(shù)據(jù)先確認(rèn)授權(quán)再進(jìn)記憶系統(tǒng)。這是一個不可妥協(xié)的底線。第八注意長會話的分層記憶臨時摘要、可檢索的長期記憶、禁止采集字段三者必須分開存儲不能都塞進(jìn)同一個向量庫。11. 下一步從 Prompt Box 到 Identity Box如果你手頭已經(jīng)有一個能跑的 Agent第一步不是繼續(xù)優(yōu)化 Prompt而是把它的身份層拆成配置文件職責(zé)邊界寫清楚、工具白名單收窄、升級路徑寫明確。這半天的工作量能明顯減少后續(xù)的角色漂移和工具誤用問題。跑通身份層之后再去掛 Skill、接 RAG、加 MCP 工具順序不要反。回到開頭那個問題AI Agent 到底是不是一個 Prompt 盒子如果只是做演示是如果要進(jìn)生產(chǎn)不是。Real Identity 不是讓 Agent 更像人而是讓它在業(yè)務(wù)邊界內(nèi)更可控。先把身份層固定下來再去堆 Prompt 和 Skill這個順序值得每個做 Agent 的團(tuán)隊認(rèn)真對待。