观测评测平台 × 阿福 · 接入对齐

目标：让阿福获得「上线前有门禁、上线后有观测」的质量能力
2026-11-13 · 与阿福研发 & 测试团队沟通

1我们看到的基础：阿福已经具备的

基于对引擎代码的核对，这些能力已经就绪——接入的大部分地基已经有了。
已具备意味着什么
Langfuse 已深度接入（环境标识、版本号、脱敏、Prompt 管理）观测数据的管道是通的
每次工具调用、检索、模型调用的输入输出都有完整记录能定位到「哪一步」出的错，不是黑盒
会话与用户标识全链路透传能按会话/用户还原完整对话
已有每晚核心场景测试（约百题）与测试题库评测资产的种子已经存在
我们说「阿福接入成本低」，不是客套——是逐行核对代码后的结论。今天想对齐的，只是剩下的少量信息与配合项。

2想向测试同学请教的

关于现有的每晚测试体系（核心场景抽题 + 预期答案 + 自建评估器打分）：
  • 这套体系跑在哪里、由谁维护？
  • 评估器是什么形态——规则、LLM 裁判，还是混合？（题库里预期答案列为空，想了解期望存在哪里）
  • 分数有历史留存吗——能否作为接入前的质量基线？
  • 运行方式是程序直调内部接口，还是模拟用户走对话入口？
问这些是为了判断现有资产如何转化复用：题干可变用例、预期可变判据输入、历史分数可变基线——目标是转化，不是重做。若运行方式是「模拟用户走对话接口」，与平台评测引擎同构，可以直接对接。

3需要的信息与权限（四件）

① UAT（开发/测试）环境的 Langfuse 实例 / Project 信息 + API Key

接入验证与评测全部在 UAT 环境进行，不碰生产。只读、不写入、不驱动。生产环境的接入后续按需两议。

② UAT 评测链路（四点）

  • UAT 环境的 Langfuse 数据上报到哪里（与生产是否同实例）
  • 可被程序驱动的对话端点（URL / 协议 / 消息格式 / 鉴权方式）
  • 1~N 个测试账号
  • 网络可达性：UAT 需要校园 VPN / 内网权限，还是公网可直接访问？
发版门禁的评测在 UAT 驱动 Agent 跑题库（不在生产）——需要能打进去、也要能看到评测产生的 trace。网络可达性决定评测服务的部署位置：若需 VPN/内网权限，需要提前安排开通（属配合项）。

③ 一个决定：质量报告要不要按「技能」切分需求决策

阿福有几十个技能（考勤、商品、文档…）。按技能分别出报告，能看清「哪个技能弱」；不切分，先出应用整体报告。两种平台都支持——前者只需在埋点里多带一个技能标识，后补也不迟。

④ 一份文档：工具授权边界清单需产出

越权红线判据（如：员工 A 不能查员工 B 的考勤）是程序可判的——前提是知道每个工具的合法授权边界（限本人 / 可代理 / 审批权限）。代码里已有实现，需要的只是一份清单文档。

4配合事项：以零开发为主

我们的设计原则：能不改动就不改动。

评测专用账号零开发

一举两得：评测流量与真实员工流量天然分开；测试中的对话也不会写进任何真实用户的记忆。只需要建账号这一个管理动作。

评测流量标记中间件可选项 · 由你们决定

技术上：Langfuse 不读取任何 HTTP header，评测流量的标记需要在埋点层转写一次。做了以后，评测数据在 Langfuse 统计里天然隔离（环境过滤直接切走），不依赖账号名单。实现是引擎埋点层一处钩子，全部技能自动继承、业务代码零感知——如果决定做，SDK 落点我们可以提供到具体接口。

商品展示口径确认零开发

商品检索的 trace 里已记录命中的模号列表——只需确认它与「最终展示给用户的款」一致。一致则零改动；若前端展示另有过滤，补一个口径说明即可。

5之后的路

① AI Sales 先跑通 第一个试点：出题 → 判据 → 门禁 → 观测 → 回流，完整闭环验证
② 阿福接入（当前对齐） 同一套底座，换阿福自己的考纲；现有测试题库转化为种子资产
③ 持续观测 上线后真实会话判分、红线告警、每周质量报告；失败自动回流成新考题
平台从第一天就为多 Agent 设计：一套底座 × 每个 Agent 一份考纲。阿福的接入复用 AI Sales 验证过的全部机制，只换业务标准。