你要的不是“最好看的 demo”，而是一个能支撑决策的 POC：可复现、可回归、可解释。
POC 总体流程（建议）
- 选 3-5 个真实业务场景（每个场景拆成 2-3 个任务类型）
- 每个任务类型准备 20 条样本起步（happy/edge/failure 都要有）
- 离线评测筛一轮（格式稳定性 + 成功率 + 成本）
- 在线 A/B（同流量、同提示模板、同工具层）
- 上负载与故障演练（P95/P99、超时、限流、工具失败）
场景拆解：从“业务问题”到“可测任务”
不要用“写一篇报告/做一个客服”这种宏任务；把它拆成可测的 I/O：
- 输入：用户问题 + 上下文（知识、历史对话、权限、环境）
- 输出：结构化结果（JSON/schema）+ 引用 + 置信度/降级原因
示例（你可以直接复制改造）：
scenario: customer_support_refund
task: policy_grounded_answer
input:
user_question: "我买的会员能退款吗？"
customer_tier: "pro"
locale: "zh-CN"
retrieved_snippets:
- id: "doc-1"
text: "会员购买后 7 天内可退款..."
expected:
must:
- "answer_in_zh"
- "include_citations"
- "no_hallucinated_policy"
should:
- "ask_clarifying_question_if_missing_order_id"
离线评测：先做“硬校验”，再做“软评分”
硬校验（Hard checks）
优先把“不合格”在机器层面拦掉：
- schema 校验：JSON 能 parse，字段齐全，类型正确
- 引用校验：引用必须来自给定的 snippets（或可追溯 URL）
- 安全校验：不输出敏感信息，不执行越权动作
- 约束校验：字数/语言/格式/禁止内容
软评分（Rubric / Judge）
软评分只评“质量”，不评“格式”：
- 正确性（是否与证据一致）
- 完整性（是否覆盖关键点）
- 可操作性（是否给出下一步）
- 语气与合规（是否遵循企业话术）
Rubric 示例：
Score 1-5:
5: 答案与证据一致，关键条件覆盖完整，有引用，必要时追问，风险提示清晰
3: 基本正确但有遗漏或表达不清；引用不够完整
1: 与证据冲突/瞎编/无引用/误导操作
在线 A/B：同一工具层、同一提示模板
为了避免“系统差异”污染结果，强制统一：
- 同一提示模板（仅替换模型参数）
- 同一工具实现（同一超时/重试/幂等/鉴权）
- 同一路由策略（不要一边开缓存一边不开）
观测指标（至少）：
- 成功率（按“任务完成定义”统计）
- P50/P95/P99 延迟
- 平均成本与长尾成本（按请求/按会话）
- 失败原因分布（限流/超时/schema 失败/工具失败/拒答）
负载与故障演练：把“上线会遇到的坑”提前遇到
建议覆盖：
- 限流与突发：RPM/TPM 被打满时，队列与降级是否正确
- 工具失败：下游 500、超时、部分失败（幂等与重试策略是否安全）
- 长上下文极限：输入接近上限时是否更易崩、是否显著变慢
- 成本 DoS：超长输入/循环工具调用/无意义重复（是否能硬停机）
输出物：POC 报告应包含什么
- 业务场景清单与任务定义（可复现）
- 样本集规模与覆盖面（happy/edge/failure）
- 模型对比结果（成功率/延迟/成本/失败类型）
- 推荐主模型 + 备模型 + 降级策略
- “还缺什么证据”（例如：合规条款、驻留证明、ZDR 能否开通）