凌晨三点，我在追一个“幽灵”Bug
那天晚上，线上Agent突然开始胡言乱语。用户问“今天天气怎么样”，它回答“根据您的位置，建议您带伞，因为您昨晚的睡眠质量评分是72分”。这明显是把天气查询和健康建议两个模块的上下文串了。
我第一反应是“代码回滚”。但翻Git log发现，过去48小时没人动过代码。再查，是Prompt里一个标点符号被改了——团队里有人把“请用中文回答”改成了“请用中文回答。”，多了一个句号。就是这个句号，让模型对指令的权重分配产生了偏移，把后一个系统指令的优先级压低了。
这就是Agent开发的残酷现实：代码没变，但行为变了。因为你的“代码”里，有一半是自然语言。
Prompt 版本控制：别把它当配置文件
很多团队把Prompt写在代码里，或者塞进一个JSON配置文件。这很危险。Prompt不是配置，它是可执行的自然语言代码。它和代码一样需要版本管理、diff、回滚、分支。
我踩过的坑：把Prompt写在代码字符串里
# 别这样写！这是灾难defget_weather_agent_prompt():return""" 你是一个天气助手。 请用中文回答。 如果用户问天气，请查询API。 """问题在哪？你没法diff。哪天模型抽风了，你都不知道是Prompt变了还是模型变了。更可怕的是，不同分支的Prompt可能不一样，合并时冲突了，你都不知道该保留哪个版本。
正确的做法：Prompt即代码，但独立管理
我现在的做法是：每个Prompt是一个独立的.py文件，用函数返回，函数名就是版本号。
# prompts/weather_agent_v2_1.pydefget_prompt()->str:""" 这里踩过坑：v2.0版本把"请用中文回答"放在了最后， 结果模型优先执行了前面的指令，忽略了语言要求。 v2.1把语言指令提前到第二行，解决了。 """return""" 你是一个天气助手。 请用中文回答。 # 注意：语言指令必须在前三行内 你的职责是： 1. 查询用户所在位置的天气 2. 用简洁的语言描述天气状况 3. 如果用户没有提供位置，主动询问 重要规则： - 不要猜测用户位置 - 不要回答非天气相关的问题 - 如果API返回错误，告诉用户“暂时无法获取” """然后在主代码里，通过一个版本管理器来加载：
classPromptManager:def__init__(self):self._prompts={}self._load_prompts()defget_prompt(self,agent_name:str,version:str)->str:# 这里踩过坑：直接import会污染命名空间# 改用importlib动态加载module_path=f"prompts.{agent_name}_v{version.replace('.','_')}"try:module=importlib.import_module(module_path)returnmodule.get_prompt()exceptModuleNotFoundError:# 回滚到上一个稳定版本logger.warning(f"Prompt{version}not found, falling back to stable")returnself._get_stable_prompt(agent_name)这样，每个Prompt版本都有独立的文件，Git可以追踪每一次修改。回滚时，只需要改版本号，不需要动代码。
模型切换：不是换个API Key那么简单
很多人觉得模型切换就是改个model="gpt-4"变成model="claude-3"。天真了。不同模型的“性格”差异，比你想的大得多。
同一个Prompt，不同模型的表现天差地别
我做过一个实验：同一个Agent，同一个Prompt，分别跑GPT-4和Claude-3。
- GPT-4：严格按照指令执行，但偶尔会“过度推理”，把简单问题复杂化
- Claude-3：更倾向于“理解意图”，但有时会忽略细节指令
这意味着什么？切换模型时，Prompt必须跟着调。你不能指望一个Prompt在所有模型上表现一致。
我的模型适配层设计
classModelAdapter:""" 每个模型一个适配器，负责： 1. 将通用Prompt转换为该模型偏好的格式 2. 处理模型特有的参数（如temperature范围不同） 3. 解析模型返回的格式差异 """def__init__(self,model_name:str):self.model_name=model_name self._load_config()defadapt_prompt(self,base_prompt:str,context:dict)->str:if"gpt"inself.model_name:# GPT系列：喜欢明确的角色设定和结构化指令returnself._gpt_style(base_prompt,context)elif"claude"inself.model_name:# Claude系列：喜欢对话式的引导，讨厌重复指令returnself._claude_style(base_prompt,context)elif"qwen"inself.model_name:# 国产模型：对中文指令更敏感，但需要更明确的格式returnself._qwen_style(base_prompt,context)def_gpt_style(self,prompt:str,context:dict)->str:# 这里踩过坑：GPT对System Message和User Message的权重不同# 关键指令必须放在System Message里system_msg=f"你是一个{context.get('role','助手')}。\n{prompt}"return[{"role":"system","content":system_msg},{"role":"user","content":context.get("user_input","")}]def_claude_style(self,prompt:str,context:dict)->str:# Claude对Human/Assistant格式更敏感# 别这样写：把指令放在Human消息里，Claude会忽略returnf"Human:{prompt}\n\n{context.get('user_input','')}\n\nAssistant:"这样，切换模型时，只需要改ModelAdapter的实例化参数，Prompt会自动适配。但注意：适配层不能解决所有问题，核心逻辑还是要针对目标模型单独调优。
A/B 测试：别信直觉，信数据
做Agent优化最怕什么？“我觉得这样更好”。你的直觉大概率是错的。我做过一个测试：把Prompt里的“请”字去掉，我觉得更简洁，结果用户满意度下降了12%。因为模型觉得“不礼貌”，回答也变得生硬。
我的A/B测试框架
classAgentABTest:""" 轻量级A/B测试，不需要第三方服务 注意：这里踩过坑，不要用随机数做分流，要基于用户ID哈希 """def__init__(self,experiment_name:str,variants:list):self.experiment_name=experiment_name self.variants=variants# [{"name": "A", "prompt_version": "2.1"}, ...]self._init_metrics()defget_variant(self,user_id:str)->dict:# 基于用户ID的稳定分流，同一个用户始终看到同一个版本hash_val=hash(f"{self.experiment_name}_{user_id}")%100idx=hash_val//(100//len(self.variants))returnself.variants[idx]defrecord_metric(self,user_id:str,variant_name:str,metric:str,value:float):# 记录关键指标：响应时间、用户满意度、任务完成率、错误率self._metrics[variant_name][metric].append(value)defanalyze(self)->dict:# 简单的统计分析，别搞太复杂results={}forvariantinself.variants:name=variant["name"]results[name]={"avg_response_time":np.mean(self._metrics[name].get("response_time",[0])),"completion_rate":np.mean(self._metrics[name].get("completion",[0])),"error_rate":np.mean(self._metrics[name].get("error",[0])),"sample_size":len(self._metrics[name].get("response_time",[]))}returnresults什么该测，什么不该测
该测的：
- Prompt措辞的微小变化（语气词、标点、顺序）
- 模型参数（temperature、top_p）
- 上下文窗口大小
- 工具调用格式
不该测的：
- 核心业务逻辑（这个应该用单元测试）
- 安全相关的Prompt（风险太高）
- 用户隐私相关的指令
一个真实的A/B测试案例
我们曾经测试过两种Prompt风格：
版本A（指令式）：
你是一个客服助手。请按以下步骤操作： 1. 确认用户问题 2. 查询知识库 3. 给出答案版本B（角色扮演式）：
你是一个经验丰富的客服专家。用户来找你帮忙，请用专业且友好的态度： - 先理解用户的需求 - 再查找相关信息 - 最后给出清晰的解答结果出乎意料：版本B的任务完成率高了8%，但平均响应时间慢了1.2秒。因为模型在“角色扮演”上花了更多时间。最后我们选择了版本B，但加了一个“如果用户连续追问，切换到简洁模式”的规则。
版本管理的终极方案：Prompt Registry
经过多次踩坑，我最终设计了一个集中式的Prompt注册中心。它不是一个数据库，而是一个版本化的文件系统。
prompts/ ├── weather_agent/ │ ├── v1.0.py │ ├── v1.1.py │ ├── v2.0.py │ └── stable -> v2.0.py # 符号链接，指向当前稳定版本 ├── customer_service/ │ ├── v1.0.py │ ├── v1.1.py │ └── experimental/ │ ├── v2.0_ab_test_a.py │ └── v2.0_ab_test_b.py └── registry.json # 记录每个Agent的版本历史、测试结果、回滚记录每次修改Prompt，都创建一个新文件，而不是修改旧文件。这样，你可以随时回滚到任意历史版本，而且可以并行维护多个实验版本。
registry.json的内容：
{"weather_agent":{"current_version":"2.0","history":[{"version":"1.0","date":"2025-01-10","author":"张三","change":"初始版本"},{"version":"1.1","date":"2025-02-15","author":"李四","change":"修复语言指令位置"},{"version":"2.0","date":"2025-03-20","author":"王五","change":"重构为模块化Prompt"}],"ab_tests":[{"test_id":"ab_001","variants":["1.1","2.0"],"winner":"2.0","metrics":{"completion_rate":"+5%"}}],"rollback_count":2}}个人经验性建议
永远不要在生产环境直接改Prompt。哪怕只是加一个空格，也要走版本管理流程。我见过最离谱的事故，是有人在生产环境的热加载配置里改了一个字，导致整个Agent集群崩溃。
Prompt的测试要比代码测试更严格。代码有类型检查、单元测试、集成测试。Prompt呢？至少要有“回归测试”——用一组固定的测试用例，每次改Prompt都跑一遍，看输出是否稳定。
模型切换的成本比你想象的高。不要因为新模型便宜就盲目切换。适配、测试、调优，至少需要两周。而且，你永远不知道新模型会在哪个边界条件下“抽风”。
A/B测试的样本量要足够大。我见过有人测了100个样本就下结论。对于Agent这种高方差系统，至少需要1000个样本才能看到统计显著性。而且，要关注长尾效应——有些Prompt在90%的情况下表现很好，但在10%的边界情况下会出大问题。
建立“Prompt Review”机制。就像Code Review一样，每次Prompt变更都要有人审核。审核的重点不是语法，而是“这个Prompt在极端情况下会怎么表现”。
最后，记住一句话：Agent的版本管理，本质上是管理“不确定性”。代码是确定的，但自然语言不是。你越早接受这个事实，越早建立相应的工程规范，你的Agent就越稳定。
