AI Agent的Real Identity：为什么不能只是一个Prompt盒子

这次我们不聊具体模型也不聊某个 ComfyUI 工作流而是聊一个更底层的问题AI Agent 为什么不能只是一个 Prompt 盒子。标题里的 Real Identity 和刷脸无关它指的不是用户的身份证而是 Agent 自己在系统里的真实身份我是谁、能干什么、不能干什么、什么情况下应该把问题交给人。很多团队做 Agent 的方式是在系统提示词里写一句“你是一个贴心的客服”然后把模型接口一接就上线。短期看没问题进入生产后就会遇到同一批问题角色漂移、越权调用工具、多轮对话后忘记边界、同一个 Prompt 换个场景就失效。先说结论Real Identity 不是一个玄学概念它由五件具体的事情组成角色定义、主题边界、记忆策略、工具权限、响应协议。把这五件事固化下来Agent 才从 Prompt Box 变成可测试、可审计、可批量部署的工程实体。这篇文章会先梳理 Prompt、Skill、Identity 三者的关系再给一个用 JSON 配置文件加通用模型 API 组装 System Prompt 的最小实现最后讨论多 Agent 协同里的身份隔离、Token 成本、常见异常排查。适合正在做客服 Agent、知识库助手、多 Agent 系统或者准备把 Agent 接入生产环境的开发者。1. 核心能力速览Identity 层到底管什么维度说明目标让 Agent 在不同任务、不同会话、不同工具调用中保持稳定且可控的行为边界核心组成角色声明、主题边界、记忆策略、工具白名单、升级/响应协议主要解决的问题角色漂移、越权工具调用、多轮上下文污染、Prompt 复用性差、Agent 行为不可审计不解决的问题不解决模型本身的能力上限也不替代 RAG、微调、工作流引擎落地载体System Prompt 模板、JSON Profile 配置、Agent 路由规则、记忆存储策略评估指标角色保持率、工具命中率、越权拦截率、上下文 Token 增量、人工升级率从工程角度看Identity 层更像是 Agent 的“应用层协议”。模型负责生成文本工具负责执行动作而身份层负责约束这一整条链路。没有身份层的 Agent本质上是一个裸模型加一段 Prompt有身份层的 Agent才是一个完整的业务系统。2. 适用场景与使用边界2.1 适合谁如果你在开发客服机器人、知识库问答助手、企业内部流程 Agent或者在做多 Agent 协同系统Identity 层是刚需。客服场景里Agent 需要知道自己只能查订单、只能退换货、不能承诺赔偿金额知识库场景里Agent 需要知道自己只能基于已入库文档回答不能拿训练记忆里的旧知识来混答多 Agent 场景里每个子 Agent 必须有独立的身份文件否则很容易互相串台。2.2 不适合什么场景如果只是做一次性的文本生成 Demo用 Prompt 就够了不需要单独设计 Identity 层。如果 Agent 完全在一个封闭的工作流里执行固定脚本没有自由对话也没有模型自主决策空间身份层能提供的价值也有限。Identity 层的价值出现在“模型需要自己做判断”的场景里判断越多约束越重要。2.3 合规与安全边界这里需要反复强调三点。第一Agent 的身份不能冒充真人。任何面向用户的 AI Agent都应该在适当位置告知用户它是由 AI 驱动的不能伪装成人类客服、人类医生或人类顾问。第二涉及用户数据时记忆策略必须明确哪些字段可以存储、哪些字段禁止存储账号密码、身份证号、支付账户这类敏感信息不能进 Agent 的记忆。第三涉及肖像、声音、品牌形象的场景必须确认授权。这不是额外负担而是 Agent 上生产前的基本条件。3. Prompt、Skill、Identity 三者到底差在哪不少开发者问过一个问题Skill 是不是就是高级版的 Prompt从使用体验上看两者有点像Skill 看起来像是把多个 Prompt、示例和工具调用封装成了一个可复用单元。但本质上它们处于不同的抽象层级。Prompt 是单次会话指令解决的是“这一次让模型做什么”。比如“把这段文字总结成三条要点”这是一个 Prompt。它没有跨会话的稳定性也没有跨任务的约束力。Skill 是程序化技能单元解决的是“一类任务怎么做”。它可能包含 Prompt 模板、Few-Shot 示例、参数校验逻辑甚至包含对工具调用的编排。Skill 可以被多个 Agent 复用但它本身不定义“谁在使用它”。Identity 则是跨会话、跨技能、跨工具的稳定框架解决的是“模型在整个系统里以什么身份、按什么规则行动”。Identity 决定一个 Skill 能不能被调用、记录什么样的记忆、回复采用什么风格。概念作用范围典型载体是否可复用是否定义主体Prompt单次输入一段文本通常不可直接复用否Skill一类任务模板 示例 校验逻辑可以跨 Agent 复用否Identity整个 Agent 的生命周期Profile 配置 记忆策略 工具白名单可模板化但需按场景定制是所以把 Agent 做强不等于把 Prompt 写长。真正的做法是先把 Identity 固定下来再挂载对应的 Skill最后才谈单次 Prompt 怎么写。4. 设计 Real Identity 的最小工程前置开始写代码之前先回答五个问题。缺一个身份层都是残缺的。第一Agent 的职责边界是什么。一个客服 Agent 能做到的最精确描述不是“你是一个贴心的客服”而是“你只能处理订单查询、退换货、物流跟踪不能承诺赔偿”。第二用户是谁。面向 C 端消费者的语言风格和面向企业内部运维人员的语言风格完全不同。第三哪些工具能用、哪些工具绝对不能用。工具白名单是最容易被忽略的一块很多 Agent 越权出问题不是模型的问题是工具列表给得太宽。第四记忆怎么存。哪些信息只在当前会话内有效哪些信息可以长期保留哪些信息完全禁止采集。第五模型回答不了时怎么办。身份层应该给一条明确的升级路径而不是让模型硬编。这些问题形成一份设计文档后你的 Agent 就不再是“Prompt 盒子”而是一个有边界、有记忆、有工具权限、可审计的系统。5. 最小实现把 Identity 从 Prompt 里拆出来5.1 写一份 identity.json 配置先不要急着写 System Prompt先把身份内容写进一个结构化配置文件。这样做的核心好处是可读、可测试、可批量生成不同 Agent 共用同一套加载逻辑。{ agent_id: support-bot-v1, name: 售后助手, description: 面向电商场景的售后客服 Agent, role: { identity_statement: 你是售后助手只处理订单、退换货、物流问题。你不是人类客服。, audience: 购买本店商品并需要售后帮助的消费者, persona: 耐心、直接、不编造承诺, language: zh-CN }, boundaries: { allowed_topics: [订单查询, 退换货, 物流跟踪], blocked_topics: [价格谈判, 医疗建议, 法律咨询, 政治评论, 情感陪伴], escalation: 如果用户要求退款且金额超过500元转人工不自行承诺 }, 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: 告知用户需要人工确认并收集订单号转交 } }这里的字段名可以根据项目改但职责划分建议保留角色、边界、记忆、工具、回复风格五块独立配置尽量不要写成一坨 Prompt。5.2 写一个 System Prompt 组装器配置文件写好后需要把它渲染成真正的 System Prompt。通用做法是写一个加载函数把 JSON 里的字段拼成一段结构清晰的文本。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服务对象{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(升级规则 boundaries.get(escalation, 转人工)) parts.append(回复风格 style.get(persona, 简洁)) return \n.join(parts)5.3 把组装后的 Prompt 发给模型下面是一个通用的模型 API 调用示例用 Python requests 完成。实际接入时把 URL 和模型名替换成你正在使用的服务即可。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])一个更严格的工程化设计还会把工具定义也带进请求里。模型只有在身份层的白名单范围内才能在回复中触发工具调用。不要把所有工具都塞给模型模型不需要知道它不能调用的工具。5.4 验证这个最小链路启动后先跑一次最简单的对话确认两个点System Prompt 是否被正确加载模型回复是否符合身份声明。如果回复里出现了和身份完全无关的内容先检查配置文件再检查组装函数。链路跑通后再往里面加工具、加记忆、加多轮对话。6. Identity 层功能测试与效果验证6.1 角色一致性测试用同一组问题分别问三次观察回答口径是否稳定。提问示例“你叫什么名字你能帮我查订单吗你能给我赔钱吗”预期结果是Agent 会报出自己的身份名称会引导用户提供订单号拒绝承诺赔偿但给出升级路径。判断标准是角色保持率如果第一次回答和第三次回答在关键承诺上不一致说明身份约束还没生效。6.2 工具边界测试把白名单外的一个工具名放进用户问题里例如“立即帮我退款”。一个合格的 Identity 层会在两个位置拦截模型不生成对应工具调用或者系统在工具执行前做白名单校验。更稳妥的方案是双重校验既在 Prompt 里约束又在工具调度器里强制校验。6.3 记忆边界测试先做多轮对话然后主动询问 Agent 是否记得刚才的细节。这里重点验证的不是模型的记忆能力而是记忆策略是否生效会话摘要有没有正常写入已经声明禁止采集的字段有没有被动进入长期记忆。敏感字段的测试必须做比如让用户说出银行卡号然后查看日志里存了什么。这个测试不应该跳过。6.4 Token 成本测试把身份配置文件逐步增大观察每次请求的输入 Token 增量。这里的判断标准不是“越短越好”而是“每一段身份描述都必须在实际对话里产生约束作用”。如果某段描述写了很多次Agent 的行为却没有变化这段就是在浪费 Token。7. 多 Agent 协同中的身份隔离与批量路由当你开始做多 Agent 系统时Identity 的价值会放大。客服 Agent、财务 Agent、数据 Agent 如果共用一个裸 Prompt 框架风险极高。每个 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 } }路由层根据用户输入先判断交给哪个 Agent再把对应 Agent 的 System Prompt 注入到请求里。这里最容易踩的坑是模型在对话中串了身份比如财务 Agent 突然用客服口吻说话。解决办法不是加一句“你必须记住你是财务 Agent”而是在每次请求时都重新注入该 Agent 的完整身份配置模型本身不负责跨请求记忆身份。批量任务场景下不同任务最好带上各自的 agent_id。这样日志、回调、错误追踪都会更容易定位。8. 资源占用与性能观察Identity 不是免费的Identity 层的每一项约束都会消耗输入 Token。一个常见的估算方式是以中文为例1000 个汉字大约对应 1000 到 2000 Token具体要按模型分词器实测。如果身份配置写得非常长再加上 RAG 检索片段、历史摘要和工具定义一次请求的输入 Token 会被快速推高。在实际项目中建议从三个维度观察成本首轮请求 Token身份配置 工具描述 用户问题这是基础消耗。多轮请求 Token历史摘要的增长方式决定了长会话的成本曲线。工具调用 Token每次工具调用会把结果带回对话这个增量容易被忽略。降低开销的方法包括身份配置保持精简只保留能改变模型行为的描述工具描述控制在两三行内历史记忆用一个摘要加最近几轮的形式而不是全部拼进上下文对长对话做会话截断超过阈值后压缩转人工或新开会话。9. 常见问题与排查方法问题现象可能原因排查方式解决方案多轮对话后角色漂移身份约束只体现在首轮后续请求没有重新注入查看后续请求的 System Prompt 是否包含完整身份配置每次请求都重新组装 System PromptPrompt 被平台内容策略拦截身份或指令里拼入了敏感/攻击性内容检查 System Prompt 原文定位被拦截的片段拆分测试每段字段删除可能触发策略的表述模型调用了白名单外的工具工具列表传得太宽只靠 Prompt 约束检查请求体里的 tools 参数在调度器层做硬校验白名单外直接拒绝上下文越来越长响应变慢历史消息全部拼接看每次请求的 messages 长度采用摘要 最近几轮记忆策略跨会话丢失用户信息长期记忆没有落库检查记忆写入流程把关键信息写入结构化存储按 user_id 读取多 Agent 串身份多个 Agent 共用一份 System Prompt查看路由日志里的 agent_id每个 Agent 独立 identity 文件路由前加载API 返回超时上下文过长或工具调用过多观察单次请求耗时和 Token 数截断上下文减少工具次数这里特别说明一下 Prompt 被拦截的问题。在 Agent 开发中如果把攻击性、歧视性、诱导越狱的内容直接写进 System Prompt很多模型的 API 会返回类似“prompt was flagged as potentially violating our usage policy”的提示。这不是模型坏了而是内容策略拦住了请求。排查手段很简单把身份配置拆成小段逐段测试找到触发拦截的那一段改写或删除。10. 最佳实践与使用建议第一身份配置当代码管。identity.json 要纳入版本管理变更要留记录。两个版本的 Agent 行为差异往往就藏在某一行身份描述的变化里。第二先硬约束后自由发挥。不要一上来就追求“人设生动”先把 allowed_topics、blocked_topics、tools 白名单定死再慢慢加 persona 风格。人设是加分项边界是保命项。第三工具权限最小化。不要一次性把 20 个工具全部传给模型。模型只需要知道当前任务能用的工具给得越多误用概率越大。第四把“转人工”作为一等公民。一个好的 Identity 层应该明确告诉模型什么情况下必须转人工什么话不能说死。让模型硬编不确定性信息比它直接承认不知道要危险得多。第五做成模板但保留定制空间。你可以做一个标准身份模板但每个业务场景都要人工 review 一遍 allowed_topics 和 escalation不要直接套用。第六评估指标要上线前定好。角色保持率、越权拦截率、人工升级率、首轮 Token 数这四个指标建议作为最低评估集。第七涉及用户隐私和版权的数据先确认授权再进记忆系统。这是一个不可妥协的底线。第八注意长会话的分层记忆临时摘要、可检索的长期记忆、禁止采集字段三者必须分开存储不能都塞进同一个向量库。11. 下一步从 Prompt Box 到 Identity Box如果你手头已经有一个能跑的 Agent第一步不是继续优化 Prompt而是把它的身份层拆成配置文件职责边界写清楚、工具白名单收窄、升级路径写明确。这半天的工作量能明显减少后续的角色漂移和工具误用问题。跑通身份层之后再去挂 Skill、接 RAG、加 MCP 工具顺序不要反。回到开头那个问题AI Agent 到底是不是一个 Prompt 盒子如果只是做演示是如果要进生产不是。Real Identity 不是让 Agent 更像人而是让它在业务边界内更可控。先把身份层固定下来再去堆 Prompt 和 Skill这个顺序值得每个做 Agent 的团队认真对待。