Prompt 版本管理

从草稿到可运维

早期 Prompt 写在代码字符串里，改一句就要发版，且无法对比效果。版本管理把 Prompt 当作配置资产：有 ID、版本号、变更说明、关联评测结果，支持回滚与灰度。

目录与元数据

建议每条 Prompt 记录：

• prompt_id：业务含义，如 support_agent_system
• version：语义化 1.2.0 或递增 v12
• content：正文（Markdown/YAML frontmatter）
• model：推荐模型与参数快照
• changelog：改动原因

# prompts/support_agent/v1.3.0.yaml
id: support_agent_system
version: 1.3.0
model: gpt-4o
temperature: 0.2
template: |
  你是客服助手。当前用户等级：{{tier}}。
  仅使用已注册工具，不得编造订单号。
variables:
  - tier

代码层只负责注入变量与选择版本，不把业务规则散落在 if-else。

评测驱动迭代

每次 bump 版本前跑固定评测集（输入 → 期望工具/关键词/结构化字段）：

| 指标 | 含义 | |---|---| | 工具选择准确率 | 是否调对工具 | | 参数 JSON 合法率 | schema 校验通过 | | 任务成功率 | 端到端是否完成 | | 平均 Token / 延迟 | 成本与体验 |

劣化则阻断发布；小幅提升可灰度 5% → 20% → 全量。

Git 与运行时

• Git：Prompt 文件进仓库，PR review 像改代码。
• 运行时：从配置中心或 DB 拉取，带缓存 TTL；紧急回滚切 active_version 指针。
• 日志：每条 LLM 请求打 prompt_id + version，便于追溯「为何昨天答得更好」。

反模式

• 在 Prompt 里堆过多 few-shot，却不版本化示例。
• 多环境共用同一版本却无环境后缀，导致 staging 测的是 prod 文案。
• 只改模型不改 Prompt 版本，无法解释行为漂移。

Prompt 版本化是 Agent 工程成熟度标志：可复现、可对比、可回滚，与 CI 里的单元测试同一逻辑。