最近在一个 Agent 项目里看到一句很有意思的 prompt“You are an AI Assistant, but what am I? Why I always tell my Agent Im an expert.”翻译过来就是你是一个 AI 助手那我是什么为什么我总是要告诉我的 Agent 我是专家这句话表面上像个段子但其实是很多大模型应用开发者都会遇到的问题。System Prompt 里我们能非常清楚地定义“Assistant 是谁、应该怎么说话、不能做什么”但很少能回答另一个问题正在跟 Assistant 对话的 User到底是一个什么样的人他现在的知识水平如何他希望得到什么粒度的回答于是很多人的解法就成了在对话里反复声明身份我是专家、我工作十年了、我对这个领域非常熟悉。这个技巧在 prompt 工程里流传很广但它到底有没有用为什么有用会不会产生反效果在生产环境里我们又该如何处理用户身份信息而不是靠用户自己往对话里“喊话”这篇文章会围绕这个问题展开。我会先讲清楚模型视角下“用户身份”是什么再做一组可复现的对比实验最后给出 Agent 工程里的身份建模思路和常见踩坑点。不管你是刚开始接触 prompt 的新手还是已经在做 Agent 应用的开发者都应该能从里面找到一些实际可用的东西。1. 背景与核心概念用户身份在 Agent 里到底算什么1.1 从 Chat Completion 的消息结构看身份缺失如果你调用过大模型 API一定见过这种消息结构一个数组里包含若干条 message每条消息都有一个角色比较常见的是 system、user、assistant。System 消息用来定义 AI 助手的人设、能力和限制User 消息是用户的输入Assistant 消息是模型的历史回复。以 OpenAI 兼容接口为例一个最简单的请求长这样messages [ {role: system, content: You are a helpful AI assistant.}, {role: user, content: 请解释一下什么是 Transformer 的自注意力机制。} ]在这个结构里模型被明确告知了“你是助手”但没有任何一个字段用来告诉模型“这个用户是谁”。模型只能从 user 消息里的文字去猜测用户的知识水平、身份背景和表达意图。于是用户为了获得更合适的回答只能主动在 prompt 里加入自己的身份信息比如“我是机器学习工程师”“我是刚入门的学生”“我是 CEO请讲结论”。这种信息对模型来说并不是“事实”它只是上下文中的一段文本但它会影响模型后续生成的内容风格和质量。1.2 “我是专家”到底改变了什么很多开发者会误以为模型能像人一样“识别出”对面是一个专家然后调整回答。实际上更准确的理解是身份声明改变了模型生成时的条件分布。Transformer 架构的模型在生成下一个 token 时会基于全部输入上下文做概率预测。当上下文里出现“用户是专家”这类描述时模型会对后续回复产生一种先验倾向调用更专业的术语、使用更复杂的句式、省略基础解释、直接进入高级讨论。换句话说模型并不是“知道”你是专家而是“顺着你的说法”生成了一段更像是在跟专家说话的内容。这本质上是一种上下文条件下的风格迁移。这也解释了为什么有时候“告诉 Agent 我是专家”的效果非常明显因为你不只是给它一个标签而是给了它整个对话的语境设定。反过来说如果你只是加了一句“我是专家”但问题本身写得模糊模型也没办法真的猜透你的水平最后输出还是会四不像。1.3 为什么“你是什么”和“我是什么”不对称我们再来看标题里的另外半句“You are an AI Assistant, but what am I?” 这其实点出了一个很现实的设计缺口。在大多数 Agent 框架里系统层面定义了 Assistant 的能力边界却没有一套通用的 User Profile 概念。用户可能会在注册页面填写自己的职业、偏好、经验等级但这些信息并没有被结构化地注入到每一轮对话上下文中。结果就是模型天然更了解自己却不了解用户。为了让对话更精准用户只能靠每次手动补充“经验等级”。这在小规模 demo 里是可行的但在生产环境里就很有问题。试想一下一个企业级客服 Agent 每天要面对成千上万用户如果每个用户都要自己在 prompt 里写“我是专家”才能拿到专家级回复那产品体验一定是很糟糕的。正确的做法是在应用层把用户身份建模成数据再动态拼进 message。2. 环境准备与版本说明2.1 技术栈与版本范围本文实验的核心是调用大模型 API 做 prompt 对比因此环境要求并不高。推荐的验证环境如下操作系统Windows 10 / macOS / Linux 均可Python3.9 及以上API 方式OpenAI 兼容接口或者你正在使用的任何国产大模型 Chat API关键依赖openaiPython SDK1.x 版本或requests这里需要说明大模型服务商的接口一直在变化文中代码以 OpenAI 兼容接口为例。如果你的服务商使用不同的鉴权方式或接口地址请根据官方文档调整base_url和api_key的传入方式。2.2 创建虚拟环境和安装依赖为了不污染全局 Python 环境建议先创建虚拟环境python -m venv venv source venv/bin/activate # Linux/macOS venv\Scripts\activate # Windows然后安装依赖pip install openai python-dotenv如果你不想安装 SDK也可以直接用requests调用 HTTP 接口核心原理是一样的。本文后面会用openaiSDK 编写示例因为它的消息结构更直观便于理解身份注入的过程。2.3 项目结构规划为了更好地演示我们先规划一个轻量级项目结构agent-identity-demo/ ├── .env ├── experiment.py ├── identity_agent.py └── README.md.env用来保存 API Key 和接口地址OPENAI_API_KEYsk-xxxx OPENAI_BASE_URLhttps://api.openai.com/v1注意不要把真实 API Key 提交到 Git 仓库。设置了.gitignore后再写.env文件。experiment.py负责做身份提示对比实验identity_agent.py负责演示如何把用户画像动态注入 Agent。接下来我们就一步步完成这两个文件。3. 身份提示背后的生成原理拆解3.1 先看一个最小示例在进入完整实验之前我们先理解一句话在 message 里的位置。理论上身份声明可以出现在三个地方第一System 消息里。这个是应用开发者控制的系统级设定优先级最高。比如你可以在 System Prompt 里写“The user is an expert in machine learning.”让模型对所有用户统一按专家对待。第二User 消息开头。也就是用户自己手动输入“我是专家”这是最原始的做法。第三Few-shot 示例里。你在示例对话中展示“专家用户问了什么、助手如何回复”让模型模仿这种交互模式。下面这段代码演示了三种写法的 message 结构差异# 写法1身份写在 system 里 messages_v1 [ {role: system, content: You are a helpful assistant. The user is an expert in deep learning.}, {role: user, content: 请对比 Transformer 和 LSTM 的优缺点。}, ] # 写法2身份写在 user 消息开头 messages_v2 [ {role: system, content: You are a helpful assistant.}, {role: user, content: 我是深度学习专家请对比 Transformer 和 LSTM 的优缺点。}, ] # 写法3在 few-shot 示例中体现身份 messages_v3 [ {role: system, content: You are a helpful assistant.}, {role: user, content: 我是深度学习专家。请对比 Transformer 和 LSTM 的优缺点。}, {role: assistant, content: 从理论建模和工程部署两个维度看Transformer 的优势在于全局依赖建模……}, {role: user, content: 那么在实际推理性能上两者如何取舍}, ]从效果上看System 消息里的身份声明最稳定因为它不会随多轮对话被冲淡。User 消息里的身份声明则会随着上下文增长逐渐被更多内容覆盖。Few-shot 示例最直观但会占用较多 token成本也更高。3.2 身份声明如何影响模型输出大模型在生成时本质上是在计算“当前上下文中下一个 token 的概率分布”。身份声明并不会开启某个特殊开关它只是改变概率分布的形状。举个例子如果模型默认认为用户是普通人在解释“注意力机制”时可能会写成“让模型每次看输入时关注重点部分”当上下文声明“用户是专家”后模型更可能输出“通过 Query、Key、Value 的线性变换计算注意力权重并加权求和”。你可能会发现让模型“认为”用户是专家后输出内容中的术语密度、缩写使用率、公式出现概率都会上升。这是因为模型在大量专业问答文本中学习到了一种模式当对话双方都是领域专家时解释通常是简洁、抽象、高密度的不需要过多铺垫。但这同时也是双刃剑模型越相信对面是专家越可能跳过必要的前提条件说明也越容易在某些不熟悉的话题上生成过度自信的论断。后面我们会专门讲这个问题。3.3 身份信息的强度与边界身份声明也不是越强越好。同样是“专家”你可以写成The user is an expert experienced in machine learning.也可以写成The user is a world-class senior expert with 20 years of experience.后者会明显拉高输出的“专业感”但也可能让模型产生一种“对方不需要我再解释”的错觉。如果真实用户其实只是中级水平这种设定反而会造成理解障碍。在生产环境里我建议把身份信息当作一种可调节的“风格参数”而不是一种绝对事实。比如设计一个人物画像时不仅写“用户是专家”还要加上约束The user is an expert in machine learning, but prefers clear explanations and practical code examples.这样既保留了专业深度又限制了模型不会把回答写得过于空泛抽象。3.4 为什么“我总是告诉 Agent 我是专家”会成为一种习惯很多人习惯每次对话都强调自己的专家身份是因为在早期大模型产品中System Prompt 是看不见也改不了的。用户只能通过 User 消息去影响模型。这种做法确实有一定效果尤其是面对复杂问题时一句“我是专家”能显著拉升回答的深度。但它也有明显问题靠用户手动维护身份很不可靠。比如同一用户切换对话后可能忘记再次声明身份模型就“掉回”一般模式模型如果坚持认为每个用户都是专家又会牺牲掉面向新手的可读性。所以更合理的做法是让应用层记住“这个用户是专家”而不是让用户每次重复一遍。4. 完整实战用实验量化“我是专家”的影响4.1 实验目的与设计现在我们用代码来验证一个具体问题同一条专业问题在不做身份声明、声明“我是专家”、声明“我是初学者”三种情况下模型回答有什么差异为了避免主观判断我选择了一个比较适合区分水平的问题请解释 Transformer 中的自注意力机制并给出三个可以优化的方向。然后构造三种不同的 Prompt 风格。你可以把这段脚本直接复制到本地运行用的是你自己的 API Key结果也能直接复现。4.2 编写实验脚本创建文件experiment.py# 文件路径agent-identity-demo/experiment.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) question 请解释 Transformer 中的自注意力机制并给出三个可以优化的方向。 base_prompt f请回答下面的问题{question} expert_prompt ( 我是一个在深度学习领域工作了十年的专家 正在与你讨论模型架构细节。 f请用专业且简洁的方式回答{question} ) beginner_prompt ( 我是一个刚入门深度学习的学生 很多专业术语还不熟悉。 f请用最通俗易懂的方式解释{question} ) def ask(prompt: str, system: str | None None) - str: messages [] if system: messages.append({role: system, content: system}) messages.append({role: user, content: prompt}) response client.chat.completions.create( modelos.getenv(OPENAI_MODEL, gpt-4o-mini), messagesmessages, temperature0.3, ) return response.choices[0].message.content if __name__ __main__: print( 无身份声明 ) print(ask(base_prompt)) print(\n 我是专家 ) print(ask(expert_prompt)) print(\n 我是初学者 ) print(ask(beginner_prompt))这段脚本的逻辑很简单通过拼接字符串构造不同 Prompt调用同一个模型使用相同的 temperature。注意temperature0.3是为了降低随机性让对比更接近稳定结果但它只能降低随机性并不能完全消除。4.3 实验结果的常见观察我用自己的 API Key 运行时观察到一种很典型的结果趋势你可以把它当作参考不一定完全一致无身份声明的回答往往中规中矩。模型会先解释注意力机制是什么然后列出几个常见优化方向语气相对中立术语密度偏低。声明“我是专家”之后回答会明显变得更“硬核”。解释部分会直接使用 Query、Key、Value、缩放点积注意力等概念优化方向也偏学术比如稀疏注意力、线性注意力、低秩分解、KV Cache 优化等。措辞更肯定省略了很多背景说明。声明“我是初学者”之后模型会刻意避免使用复杂公式更多用类比解释“注意力就像给每个词分配关注度”。优化部分也变成了更贴近工程实践、更容易上手的描述。这里有一个关键提醒不要把这三种回答当成模型真的理解了你的身份本质上是模型根据上下文调整了生成风格。真实用户水平未必和声明一致因此这类 Prompt 只能作为软约束。4.4 如何评估“专家模式”是否有效只看文字感受还不够在工程上我们需要一套评估维度。你可以从这几项来分析输出第一信息密度。即每句话里包含的有效专业信息有多少。专家模式通常信息密度更高但可读性可能下降。第二术语解释率。输出中出现的专业缩写是否都给了解释。专家模式常常默认读者知道因此解释率更低。第三事实错误率。这是最重要的指标。越激进的专家模式越可能出现“听起来很专业但实际不严谨”的表述。第四用户满意度。最终判断必须回到真实使用者身上。如果用户说自己不是专家但 AI 却按专家模式输出体验就很差。建议在实际项目中把以上维度做成评分表对不同类型的 Prompt 版本进行离线评测而不是凭感觉上线。4.5 把用户画像做成可配置的 Agent实验验证之后我们再看一个更实用的场景如何让 Agent 动态识别用户身份而不是等用户手动声明。创建文件identity_agent.py# 文件路径agent-identity-demo/identity_agent.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) class UserProfile: 用户画像的最小模型。 def __init__(self, user_id: str, level: str intermediate, domain: str general): self.user_id user_id self.level level self.domain domain def build_identity_block(self) - str: level_map { beginner: a beginner who needs simple explanations and examples, intermediate: an intermediate developer who knows basic concepts, expert: an expert with deep experience in the related domain, } level_desc level_map.get(self.level, level_map[intermediate]) return ( fThe user is {level_desc}. fTheir current interest domain is {self.domain}. Please adapt the depth and style of your response accordingly. ) class IdentityAgent: def __init__(self, profile: UserProfile, system_prompt: str | None None): self.profile profile self.system_prompt system_prompt or ( You are a professional AI assistant. You should help users solve problems efficiently and honestly. ) def _build_messages(self, user_input: str, history: list | None None): identity_block self.profile.build_identity_block() system_content ( f{self.system_prompt}\n\n[User Profile]\n{identity_block} ) messages [{role: system, content: system_content}] if history: messages.extend(history[-6:]) # 只保留最近几轮避免上下文过长 messages.append({role: user, content: user_input}) return messages def chat(self, user_input: str, history: list | None None) - str: messages self._build_messages(user_input, history) response client.chat.completions.create( modelos.getenv(OPENAI_MODEL, gpt-4o-mini), messagesmessages, temperature0.3, ) return response.choices[0].message.content if __name__ __main__: expert_user UserProfile( user_idu_1001, levelexpert, domaindeep learning, ) agent IdentityAgent(expert_user) answer agent.chat(请解释什么是自注意力机制并给出优化建议。) print(answer)这个实现里我们不再依赖用户手动输入“我是专家”而是通过UserProfile对象存储用户身份。Agent 在拼装 System Prompt 时会自动注入用户画像。这样做有三个好处身份信息稳定不会因为用户换了一个对话框就丢失。身份信息可配置同一个 Agent 可以为不同用户提供不同风格回答。身份信息可更新用户通过学习逐渐升级时只需改level字段不需要改任何业务代码。4.6 动态身份注入时的上下文压缩问题上述实现里有一个细节history[-6:]。为什么要只保留最近几轮因为身份信息主要写在 System Prompt 中但历史消息过长时模型注意力会被大量历史内容稀释。尤其是当用户聊了十几轮之后新输入与旧身份信息之间的关联会变弱。在真实项目中你需要在“保留历史上下文”和“避免输入过长”之间做平衡。方法不止一种可以定期把关键身份信息压缩进最新一条 System Message也可以使用专门的上下文压缩模块。总之不要让身份信息只出现一次就再也不管。5. 常见问题与排查思路5.1 高频问题对照表我们把实际开发中容易遇到的问题整理成一张表方便快速排查问题现象常见原因解决思路告诉 Agent 我是专家后回答术语太多看不懂身份声明拉高了专业风格但没有约束可读性在身份信息后追加“需要解释缩写”等输出约束回答听起来很自信但出现了事实错误模型为了迎合专家身份生成了更激进的断言增加“不确定时明确说明”的约束关键内容接入检索或人工复核多轮对话后身份信息失效回答风格回到默认身份信息只放在某一条 user 消息中被后续上下文冲淡将身份信息放入 system prompt或定期重新注入有的模型对“我是专家”不敏感提示表述太弱或模型指令遵循能力有限使用 few-shot 示例构造“专家-助手”对话或换用更强模型System 里写“用户是新手”User 却说自己是专家两处身份信息冲突模型不知道该信谁统一从用户画像生成身份信息避免用户手动覆盖系统设定输出长度越来越不稳定身份声明同时触发了“更详细回答”的先验设置max_tokens并在 prompt 中明确长度要求用户画像更新后模型还是按旧身份回答应用层没有重新拼接 System Prompt检查消息构建逻辑确认每次聊天都从最新 profile 生成5.2 排查思路详解当身份提示效果不符合预期时不要只调整关键词。按下面顺序排查第一步检查身份信息是否出现在模型实际收到的请求里。有些框架会在内部修改 System Prompt你在业务代码里传入的字符串未必原样到了模型侧。可以先加日志打印完整 messages。第二步检查是否有其他 Prompt 与身份信息冲突。比如系统默认提示词是“请用通俗语言回答所有问题”那么你再声明“我是专家”也没用。第三步检查是否设置了过低的 temperature。虽然 temperature 影响的是随机性但某些模型在低温度下更容易跟随最常见的模式身份提示的作用可能被淡化。第四步检查模型版本。部分模型的风格跟随能力差异很大。同一个身份声明在旧版模型和新版模型上的表现可能完全不一样。遇到这种情况最好的办法是换模型或调整 Prompt 写法。第五步如果要在生产环境中长期使用身份提示强烈建议做 A/B 测试。把用户随机分成两组一组用专家身份 Prompt一组用标准 Prompt然后比较用户满意度、任务完成率和输出质量。6. 最佳实践与工程建议6.1 把身份信息当配置而不是当对话内容我在很多项目里看到过这样的代码用户在客户端输入框里手动输入“我是公司总监”然后 Agent 就真的按“总监”级别来回答。这种方法最大的问题是身份不一致。用户这次记得写了就有专家效果下次忘了写就什么都没有。正确的做法是把用户身份建模成一份结构化的配置由应用层统一维护。user_profile { user_id: u_1001, role: developer, level: senior, domain: backend-system, response_style: concise, forbidden_topics: [], }构建 Prompt 时从这份配置里生成一段身份描述再注入 System Message。这样身份信息不会再依赖用户的主观输入。6.2 身份声明要搭配任务边界身份声明应该回答三个问题用户是谁用户想完成什么任务模型应该以什么方式帮助用户。举个例子一个 Agent 的 System Prompt 可以这样组织You are a professional AI assistant. [User Identity] The user is an expert in backend development. They are familiar with Java, Spring Boot, and MySQL. [Task Context] The user is currently debugging a production issue related to database connection pool exhaustion. [Response Guidance] Provide concrete code examples and troubleshooting checklists. Do not over-simplify. If you are unsure about the root cause, state your assumptions clearly.这段 Prompt 比简单写“用户是专家”更稳定因为它把身份、目标和输出要求绑定在了一起。模型知道对方是谁知道对方当前在做什么也知道自己应该输出什么风格。6.3 不建议用身份声明压制安全校验身份声明不应该成为功能权限或安全边界的一部分。也就是说不能因为 Prompt 里写了“用户是管理员”就让 Agent 开放更高权限。真实系统的权限必须由业务后端控制模型输出只能作为参考。尤其涉及删除操作、生产环境变更、资金操作、医疗建议等高风险场景时不管用户声明自己是什么身份Agent 都应当执行最小权限原则并通过二次确认、人工审批等方式控制风险。关于这一点文中实验和示例代码都只用于演示 Prompt 生成逻辑真正的生产落地必须结合实际业务的安全规范。6.4 警惕“伪专家”输出身份声明之所以有效本质上是因为模型喜欢在一个明确的对话语境中生成更符合该语境的文本。但这不代表模型在专家模式下就更严谨。相反它可能为了满足语境而生成“听起来很专业”的错误内容。为了减少这种情况建议在 Prompt 中加入不确定性引导If you do not have enough information or are not confident about a claim, clearly say so and provide supporting reasoning.同时在应用层接入检索工具让模型基于可靠内容回答。即使面对专家用户也不能让模型完全自由发挥。6.5 建立 Prompt 版本管理与评测机制身份提示不是写一次就结束的。同一个用户画像在不同模型版本上效果会有差异同一个 Prompt 模板在调整几个词之后输出质量也可能明显变化。建议项目中引入简单的 Prompt 版本管理。每次调整身份描述、任务边界或输出约束时都记录版本号、修改内容、评测结果。这样可以快速定位“为什么这周输出风格变了”。评测维度至少包括回答是否准确、是否满足用户预设水平、是否足够可操作、是否存在错误信息。如果条件允许把评测过程接入 CI 流程大幅减少回归风险。6.6 从 Prompt 技巧走向产品化如果你是一个产品经理或技术负责人应该思考的不只是“如何在 Prompt 里写我是专家”而是“如何让用户不需要写出这句话也能获得专家级体验”。一种产品化方案是提供“专业模式”。用户在界面上选择自己是新手、中级还是专家后台把这些信息存到UserProfile中生成请求时自动注入 System Prompt。另一种方案是让 Agent 主动判断用户的水平。比如在对话开头问一个问题或通过用户历史行为推断。这种方案更智能但需要额外的用户建模能力。无论哪种方案目标是一致的把用户身份从“用户自己喊出来的临时咒语”变成“系统主动维护的结构化数据”。这才是标题里那句 “what am I” 的真正答案。7. 总结与后续学习路线写到这里我们再回头看标题里那句话“You are an AI Assistant, but what am I?” 现在已经很好回答了在 API 的消息结构里Assistant 的身份由 System Prompt 定义而 User 的身份原本是缺失的。你告诉 Agent“我是专家”并不是向模型传递一个客观事实而是在给它一个生成上下文。模型会顺着这个上下文调整回答风格让它看起来更像是在和一个专家对话。这个技巧在临时试验中非常有效但它不该成为生产系统的长期方案。真正的工程做法是设计可持久化的用户画像构建动态 System Prompt把身份信息、任务边界和输出约束绑定在一起并且配合评测机制持续优化。当身份信息能够稳定、准确地传递给模型时用户自然不需要反复强调自己是谁。如果你对这部分内容感兴趣下一步可以继续研究三个方向一是 System Prompt 的系统化设计包括少样本提示和思维链提示二是 Agent 的上下文管理比如如何压缩长期对话、如何动态注入用户画像三是大模型输出的安全评测尤其是如何识别模型在“专家模式”下产生的过度自信错误。这篇文章只是一个起点。建议你把自己常用的三个问题分别用“无身份声明”“我是专家”“我是初学者”跑一遍亲自对比模型输出的差异。你会发现同样一个模型只是改了一句话生成风格就可能完全不同。而这种对 Prompt 细节的敏感度恰恰是大模型应用开发的乐趣所在。