Commit Graph
2 Commits
Author SHA1 Message Date
lzf_0626 8283f6ab69 feat(customer-service): 把闲聊提示词补回生效版本,并修掉发布脚本的两个坑
**背景**:提示词配过(挂在 release 174),但 174 已被取代,而 load_active_prompt 是先定位
active 版本、再按 release_id 查的 —— 于是读不到,Agent 回落到代码默认值。功能看着正常
(_chitchat_prompt 有逐字段兜底),所以一直没人发现,也没有任何告警。

发布脚本原先有两个坑,这次一并修掉:

1. **version 写死为 1**。prompt_template_version 的唯一键是 (prompt_code, version),
   客服那条已经占了 v1,照搬旧行会主键冲突。改为取现有最大值 +1(本次自动分到 v2)。
2. **继承只读 platform_config_item**。改用 ConfigReleaseService.effective_snapshot(),
   它覆盖全部三张受管表;并且做**字段名映射**(库的 config_key → API 的 item_key、
   value_json 归一化)—— 快照行是库的形状,直接 POST 会 422。

实测:
- 发布走路径二(路径一如预期被状态机拒:409 RUN_NOT_CANCELLABLE「只能修改草稿发布版本」)
- 新版本 201 继承 9 条配置项、一条没丢;提示词 v2 随之生效
- load_active_prompt 现在返回 release_id=201 / version=2(此前为 None)
- 闲聊链路:status=succeeded、intent=chitchat,回答「您好,我是南方科技智能客服,
  想了解基金、理财还是账户服务?」—— 简洁、自然引导到业务,符合提示词要求

提示词正文与代码默认值**刻意保持一致**:发布前后行为不变,变的只是"能不能改"
(改话术从此要经审核并留痕)。Agent 侧仍保留代码默认值作为兜底。

ruff / mypy(136 文件) / 612 unit+contract / 29 integration 全绿。
2026-09-11 13:26:43 +08:00
lzf_0626 20a3a2f249 feat: 客服闲聊提示词发布为可配置版本(提示词接入发布配置闭环)
业务方选定提示词走发布配置而不是写死在代码里:改话术要经过审核并留痕,符合金融场景
对口径变更的要求。Agent 侧读取上一批已实现(runtime_config_service.load_active_prompt),
本次补上发布侧,形成闭环。

脚本处理两条路径,实测第一条被拒、自动走了第二条:
1. 直接挂到当前生效版本 → 实测 409「只能修改草稿发布版本」,生效版本不可追加;
2. 新建发布版本,先**原样继承现有全部配置项**再追加提示词。原因:config_release 是
   整版本替换语义,不继承就会把其他 Agent 的工具白名单清空(发布客服白名单时已踩过
   一次这个坑,这次直接带上了继承逻辑)。

结果:新发布版本 174 生效,含 4 条 agent_tools 白名单 + 1 条 prompt_template_version
(prompt_code=customer_service_chitchat、task_type=chat、agent_type=customer_service)。

验证:load_active_prompt 能读到该提示词(release_id=174、version=1、checksum 已生成);
闲聊功能正常(意图 chitchat 置信 0.95,回答带免责声明)。

顺带记录一处错误码语义问题(本次不改):对「生效版本不可追加」这种资源状态冲突,
服务端返回的错误码是 RUN_NOT_CANCELLABLE,与场景不符。原因是 docs/05 §3.6 的码表里
没有表示「资源状态不允许该操作」的码,于是被复用了语义最近的运行类错误码。
建议后续在码表里补一个状态类错误码,而不是继续复用无关的码。
2026-09-10 20:41:09 +08:00