LangSmith回滚实战:三种机制灵活应对版本危机
在 LangSmith 里回滚不是一键按钮而是通过三种机制组合实现把更早的 commit重新 Promote到目标环境最常用把环境标签tag移回旧的 commit在代码里直接指定旧 commit hash拉取另外如果你是在 LangGraph Studio / Agent Server 里做运行时回滚还可以用Time Travel检查点分叉。下面逐一讲清楚。一、最常用的方式重新 Promote 一个旧 commit场景你在 Production 上跑了 commitabc123今天又 Promote 了def456发现线上效果变差想回到abc123。步骤全部在 UI 完成打开该 Prompt 的详情页左侧 Prompts → 点击目标 Prompt。左侧会看到完整的commit 历史以及 Staging / Production 两个环境。找到你想回滚到的那个旧 commit比如abc123悬停 → 点击 Promote。在弹窗中选择目标环境例如 Production确认。这样 Production 的标签就指向了旧的abc123等效于回滚。def456仍然保留在 commit 历史里不会丢失。要点回滚本身 把某个旧 commit 重新 Promote 到目标环境。不影响 Staging如果 Staging 也在新版本上可以单独再 Promote 旧版到 Staging。可以随时在任意两个环境之间来回 Promote没有只能向前的限制。二、用标签Tag回滚把 Tag 移回旧 commit场景你不用 Staging/Production 预置环境而是自己打了v1.0、v2.0等标签现在想把v2.0移回旧的 commit。步骤打开 Prompt 详情页在 commit 列表中找到旧 commit。悬停 → 选择“Add tag”或“Move tag”如果标签已存在于另一个 commit 上。选择要移动的标签例如v2.0确认。之后代码里client.pull_prompt(my-prompt:v2.0)拿到的就是旧版本。与 Promote 的区别Promote移动 Tag操作对象Staging / Production 预置标签任意自定义标签谁能用需要 Owner/编辑权限需要 Owner/编辑权限典型用途环境级别的发布/回滚自定义版本号管理三、在代码里直接指定旧 commit hash最灵活场景不想改 UI 上的环境/标签配置临时在代码里回退到已知的好版本。做法fromlangsmithimportClient clientClient()# 正常用 tag 拉取跟环境/标签绑定promptclient.pull_prompt(joke-generator:production)# 回滚直接指定某个 commit hashpromptclient.pull_prompt(joke-generator:abc12345)# 回滚到 stagingpromptclient.pull_prompt(joke-generator:staging)适用情况紧急回滚来不及改 UI。A/B 测试不同请求拉不同 commit。调试对比两个 commit 的效果。四、LangGraph Studio / Agent Server 里的运行时回滚Time Travel如果你用的是 LangGraph Agent Server回滚还有一个维度从某个历史检查点重新执行。1) 在 Studio 中 Time Travel打开一个 Thread对话线程右侧可以看到完整的状态时间线。点击任意一个历史检查点状态快照可以Fork从该点分叉出新线程继续执行。Re-run从该点重新执行后续节点。这等效于回滚到某个中间状态再重新走一遍。2) 在 SDK 中用检查点回滚fromlanggraph_sdkimportget_client clientget_client(urlhttp://localhost:8123)# 获取某个 thread 的历史状态historyawaitclient.threads.get_history(thread_idxxx)# 拿到某个旧状态的 checkpoint_idold_checkpointhistory[5].checkpoint_id# 从该检查点重新执行或 fork 一个新线程awaitclient.runs.create(thread_idxxx,assistant_idmy-agent,input{messages:[{role:user,content:继续}]},checkpoint_idold_checkpoint,# 从这个检查点开始)与 Prompt 回滚的关系回滚维度回滚对象粒度Prompt 回滚上面三种Prompt 模板内容整个 Prompt 的版本Time TravelAgent 运行状态某次执行的某个节点两者可以组合先 Prompt 回滚到旧版模板再对受影响的 Thread 做 Time Travel 重新执行。五、最佳实践建议的回滚流程┌──────────────────────────────────────────────────┐ │ Prompt 发布流程 │ │ │ │ Playground 编辑 ──保存── commit_1 │ │ │ │ │ ├── Promote commit_1 ── Staging │ │ │ │ │ │ │ 测试通过? │ │ │ │ │ │ │ 是 ├── Promote commit_1 ── Production│ │ │ │ │ │ │ 否 └── 继续编辑 ──保存── commit_2 │ │ │ │ │ │ │ └── Promote commit_2 ── │ │ │ Staging覆盖 │ │ │ │ │ ─── 线上发现异常需要回滚 ────┐ │ │ │ │ │ 方式1: Promote commit_1 ── Production覆盖 │ │ 方式2: 把 production tag 移回 commit_1 │ │ 方式3: 代码里临时指定 commit_1 的 hash │ └──────────────────────────────────────────────────┘几个关键建议每个 commit 都有唯一 hash永远不会丢——即使你 Promote 了新版本旧版本随时可以再 Promote 回来。用 tag 而不是 hash 做代码引用——代码里写my-prompt:production而不是my-prompt:abc123回滚时只需改 tag 指向不需要改代码。重大变更前先打一个自定义 tag 做快照比如v1.0-golden方便随时回退。回滚后记得跑一次 Eval——用 LangSmith 的离线评测对比新旧版本确认回滚确实修复了问题。