Agent 选型评估与评审 | 从零理解如何构建 AI Agent
帮助你快速判断本章定位、前置要求与学习目标。
POC 不是演示
Agent POC 的目标不是证明"模型能回答"，而是证明这条技术路径能稳定解决一类真实任务。
一个合格的 POC 至少要说清楚：
- 解决哪类任务；
- 不解决哪类任务；
- 成功标准是什么；
- 失败时怎么定位；
- 成本和延迟是否可接受；
- 上线前还缺什么。
如果 POC 只挑最顺的 5 个例子演示，结论通常没有工程价值。
POC 要验证哪种不确定性
| POC 类型 | 验证什么 | 不应该验证什么 |
|---|---|---|
| 需求 POC | 用户是否真的需要这个 Agent | 不要过早做复杂架构 |
| 检索 POC | 知识是否能被稳定召回 | 不要用全量权限绕过 |
| 工具 POC | 工具能否被正确选择和调用 | 不要开放写操作 |
| 工作流 POC | 状态、暂停、恢复是否可行 | 不要覆盖全部流程 |
| 安全 POC | 注入、越权、高风险动作是否可控 | 不要只测正常样本 |
先说清楚 POC 类型，才能定义正确指标。
POC 范围
| 范围问题 | 推荐做法 |
|---|---|
| 任务类型 | 选 1-2 类高频任务，不要覆盖全部业务 |
| 数据来源 | 明确内部知识、外部网页、用户输入分别来自哪里 |
| 工具动作 | 先只读，再逐步加入写操作 |
| 用户权限 | POC 阶段也要模拟权限，不要默认全量可见 |
| 输出形式 | 固定格式、引用、置信度和下一步建议 |
| 失败处理 | 明确拒答、转人工、降级或重试策略 |
最小 POC 应该窄，但不能假。
样本集怎么做
样本集要覆盖四类问题：
| 样本类型 | 目的 | 建议比例 |
|---|---|---|
| 正常样本 | 验证主流程是否稳定 | 50% |
| 边界样本 | 验证信息缺失、版本冲突、权限不足 | 25% |
| 安全样本 | 验证注入、越权、错误工具调用 | 15% |
| 真实噪声 | 验证业务语言和真实噪声 | 10% |
20-50 条高质量样本通常比 500 条随便拼的样本有价值。如果业务高风险，安全样本比例应该更高。
指标不要只看准确率
Agent 系统至少要分层评估：
| 层 | 指标 |
|---|---|
| 检索 | Recall、Precision、TopK 命中、引用正确率 |
| 搜索 | 来源可信度、时间正确性、冲突识别 |
| 工具调用 | 工具选择正确率、参数正确率、失败恢复率 |
| 生成 | 事实一致性、格式合规、拒答正确率 |
| 体验 | 延迟、成本、转人工率、用户修正率 |
| 安全 | 权限绕过率、注入成功率、高风险动作拦截率 |
不要把所有问题压成一个"回答对不对"。
分层验收示例
| 场景 | 必须达标 |
|---|---|
| 企业知识库 | 检索前权限过滤、引用正确率、拒答正确率 |
| 研究型 Agent | 来源时间、引用、冲突识别 |
| 代码库 Agent | 相关文件命中、测试通过、diff 可审查 |
| Text-to-SQL | SELECT-only、权限内 schema、查询成本限制 |
| 工具执行 Agent | 工具选择、参数正确、高风险确认 |
通过标准
POC 通过标准应该提前写死：
核心任务成功率 >= 目标值
引用正确率 >= 目标值
高风险动作误执行 = 0
权限越权 = 0
平均延迟 <= 目标值
单次成本 <= 目标值
失败时能给出明确降级路径安全和权限类指标不能用平均值掩盖。一次越权就足够说明方案不能上线。
POC 结论写成三档：
通过：关键指标达标，进入工程化实现
有条件通过：技术路径可行，但必须补齐指定缺口
不通过：核心任务、权限、安全或成本不可接受常见假阳性
| 现象 | 问题 |
|---|---|
| Demo 很顺 | 样本太少，没覆盖失败场景 |
| 准确率很高 | 没测引用、权限和拒答 |
| 用户觉得好用 | 没测成本、延迟和稳定性 |
| 框架跑通了 | 没证明业务流程可恢复、可审计 |
| 搜索结果不错 | 没处理来源冲突和结果漂移 |
POC 通过不等于能上线。POC 只是在回答"值得继续投入吗"。
上线前缺口
从 POC 到上线，通常还要补：评测集版本管理、trace 和 replay、权限系统接入、成本和延迟监控、工具失败降级、文档更新流程、高风险操作审批、人工兜底流程。
评审模板
Agent 选型评审不要从"用哪个框架"开始。先把下面问题写清楚。
评审材料的目标不是展示技术栈，而是让团队能判断：
这个方案为什么需要这些层？
每一层输入输出是什么？
出错后怎么定位？
上线后怎么评估和降级？如果材料只列框架名，没有数据流和失败路径，评审应该退回。
任务边界
本方案解决：[具体任务]
本方案不解决：[明确排除]
成功输出：[答案 + 引用 / 操作结果 + 数据来源]"不解决什么"比"解决什么"更能保护第一版范围。
技术组合
| 能力 | 是否需要 | 理由 |
|---|---|---|
| 普通模型调用 | 是/否 | 是否已有足够上下文 |
| RAG | 是/否 | 是否依赖稳定私有知识 |
| Search | 是/否 | 是否依赖实时外部信息 |
| Tools | 是/否 | 是否需要执行动作 |
| Agent Framework | 是/否 | 是否需要状态、分支、恢复 |
| Human Approval | 是/否 | 是否涉及高风险动作 |
每一层都要回答"不用它会坏在哪里"。答不上来就先删掉。建议在评审材料里写出被删除的能力，这比只列"采用 RAG + Tools"更有价值。
数据流和控制流
必须画清楚两条线：
数据流：用户输入 -> 检索/搜索/工具 -> 上下文 -> 输出
控制流：意图 -> 路由 -> 状态 -> 确认 -> 降级很多 Agent 方案失败，是因为把数据流和控制流都塞进一个 Prompt。如果方案涉及多步执行，必须补充状态字段、持久化位置、每步输入输出、中断恢复方式、高风险审批方式和 trace 保留策略。
风险和权限
把所有工具动作分级：
| 风险 | 例子 | 要求 |
|---|---|---|
| 低 | 只读查询 | 自动执行，记录 trace |
| 中 | 创建草稿、生成待审批记录 | 可批量确认 |
| 高 | 发送、删除、发布、付款 | 单次确认 |
| 极高 | 权限变更、批量改生产数据 | 双人审批或禁止 |
权限后置过滤不能通过评审。必须写清楚数据来自哪里、谁能访问、权限在哪里过滤、输出是否需要脱敏。
评估与降级
至少定义：样本集（正常/边界/安全）、通过标准、引用正确率、工具调用正确率、成本和延迟上限、安全红线。
降级矩阵：
| 失败 | 降级 |
|---|---|
| 检索不到资料 | 拒答或转人工 |
| 搜索失败 | 使用缓存或说明无法确认 |
| 工具调用失败 | 重试、回滚或人工处理 |
| 模型不可用 | fallback 模型 |
| 权限不足 | 明确拒绝 |
| 高风险动作 | 暂停等待确认 |
架构取舍
| 取舍 | 选择 | 为什么 |
|---|---|---|
| RAG vs Search | 例如 RAG | 知识稳定且私有 |
| Tool loop vs Framework | 例如轻量 loop | 第一版没有恢复执行 |
| 自研 vs 平台 | 例如自研工具网关 | 权限和审计必须自控 |
| 强模型 vs 路由 | 例如模型路由 | 控制成本和 fallback |
每个取舍都要写被放弃方案。
退回条件
出现下面任一情况，评审应该退回：任务边界说不清、权限过滤放在生成后、高风险工具没有确认、没有评测样本、没有 trace 或审计方案、成本和延迟没有预算、供应商锁定没有退出路径。
可复制评审模板
项目名称：
本阶段解决：
本阶段不解决：
采用能力：模型调用 / RAG / Search / Tools / Agent Framework / Human Approval
明确删除的能力：
数据流：
控制流：
权限过滤位置：
风险动作和审批方式：
评估样本和通过标准：
失败降级策略：
上线结论：通过 / 有条件通过 / 不通过
必须补齐的缺口：模板的价值不是填满字段，而是逼团队删掉讲不清的能力。Agent 系统一旦涉及权限和工具执行，模糊就是风险。