AI Agent Demo Acceptance Script：项目演示验收脚本怎么写
这篇文章解决什么问题
很多 AI Agent 项目演示时只展示“能聊天”，但面试官、评审或业务方真正关心的是：任务能不能跑通、失败时怎么处理、权限是否安全、引用是否可信、成本和延迟是否可控、你是否真的做过工程化闭环。
Demo Acceptance Script 的目标是把演示变成可验收流程，而不是临场自由发挥。
演示脚本结构
一个成熟的 Agent Demo 建议按 8 个环节组织：
- 背景和用户任务；
- 输入数据和权限边界；
- Agent Workflow 执行；
- RAG / Tool / MCP 调用证据；
- Trace 和状态展示；
- 失败、审批或人工接管场景；
- 评测、成本、延迟和安全指标；
- 总结项目价值和个人贡献。
5 分钟演示模板
| 时间 | 内容 | 重点 |
|---|---|---|
| 0:00-0:30 | 项目背景 | 谁的什么问题，为什么需要 Agent |
| 0:30-1:00 | 架构总览 | Runtime、RAG、Tool、Trace、Eval、Ops |
| 1:00-2:30 | 主路径演示 | 用户输入、任务状态、工具调用、最终结果 |
| 2:30-3:20 | 可信证据 | 引用、Trace、工具参数、审批记录 |
| 3:20-4:10 | 异常场景 | 无权限、工具失败、低置信度、人工接管 |
| 4:10-4:40 | 指标结果 | task success、latency、cost、feedback |
| 4:40-5:00 | 贡献总结 | 自己负责的模块、难点和改进空间 |
验收用例清单
1. 主路径用例
- 上传文档或选择知识库；
- 发起业务问题；
- Agent 拆解任务；
- 检索证据；
- 调用必要工具；
- 输出结构化结果；
- 展示引用和 Trace。
2. 权限用例
- 普通用户请求无权限文档；
- 系统拒答或只返回允许范围；
- citation 不暴露不可访问来源；
- 缓存不会跨用户命中。
3. 工具风险用例
- 低风险查询工具自动执行；
- 高风险工具生成审批卡片；
- 审批前不能执行；
- 审批后参数 hash 不一致则拒绝执行；
- 工具失败能进入回放和错误分类。
4. 失败恢复用例
- 工具超时；
- RAG 无证据；
- 模型输出格式错误；
- 任务进入 WaitingApproval；
- 人工接管后可重跑或关闭。
5. 评测和运营用例
- 展示 golden set 或回归样本；
- 展示本次 demo 的 run_id；
- 展示 cost / latency / token；
- 展示用户反馈入口；
- 展示线上问题如何进入 eval set。
演示前检查表
| 检查项 | 要求 |
|---|---|
| 数据准备 | 示例数据不含真实敏感信息，权限标签完整 |
| 环境准备 | 后端、前端、数据库、向量库、工具服务可用 |
| 账号准备 | 至少有 admin、普通用户、无权限用户 |
| 主路径 | 关键用例能稳定跑通 |
| 异常路径 | 至少准备 2 个失败或审批场景 |
| Trace | 能定位 run、step、tool_call、citation |
| 指标 | 能说清成功率、成本、延迟、质量或安全结果 |
| 兜底 | Demo 失败时有截图、录屏或静态报告 |
面试表达模板
我演示 Agent 项目时不会只展示聊天效果，而是按验收脚本展示主路径、权限边界、工具审批、失败恢复、Trace 证据和评测指标。这样面试官能看到我做的不只是 Prompt Demo，而是一个有状态、有权限、有观测、有回归的工程系统。
常见误区
误区一：只演示成功路径
真实项目一定会被追问失败怎么办。必须主动展示无权限、无证据、工具失败或审批场景。
误区二：只讲技术栈
面试官更关心你如何设计边界、如何验证质量、如何定位问题、如何证明收益。
误区三：没有证据链
如果没有 Trace、引用、工具参数、评测结果和指标，演示就容易变成“看起来能用”。