Agent 解决了什么业务问题，如何证明实际提效？

核心回答

以下以电商问数为例说明业务问题与验证方法。

Agent 解决的是业务同学想查数据，却要依赖分析师反复确认指标、找表和写 SQL，数据获取链路长的问题。它把自然语言理解、元数据检索、SQL 生成与校验、执行结果返回串成流程，让口径明确的常见查询更容易自助完成，减少分析师的重复劳动。

证明提效，要比较达到同等交付质量的一整条流程，不能只比较 SQL 生成速度：

1. 建立人工基线：明确哪些查询属于目标范围，记录原流程的人工操作时间、等待时间、正确交付率和返工情况。
2. 记录接入后的变化：看查询是否正确完成、每单还需要多少人工确认和修改、用户多久拿到可用结果，同时统计模型、工具、维护及兜底成本。
3. 做可比较的验证：先用同类历史任务比较人工流程与 Agent 辅助流程；有真实流量时做合理分组的对照实验，按任务难度和用户类型看结果，检查节省时间是否以质量下降为代价。
4. 说明收益落在哪：是缩短用户等待、减少人工投入、提高处理量，还是扩大自助覆盖。节省的工时与实际财务降本要分开描述。

先讲清楚原流程为什么慢

“提升效率”应落到谁做什么、在哪一步受阻。问数场景中，业务方提出需求，分析师确认“销售额”的口径、时间与地区，定位表字段，编写并调试 SQL，核对结果，再回复业务方。耗时可能来自沟通和排队，也可能来自找表、查取值、修查询。

Agent 的作用要和这些环节对应：元数据检索帮助找到字段、指标定义和合法取值；SQL 生成减少重复编写；校验与错误反馈减少部分调试工作；统一入口减少需求在多人之间反复传递。只有实际减少了这些工作的耗时，才能支持相应的提效结论。SQL 能执行也不代表业务正确，仍要核对指标口径、过滤条件和结果。

任务范围也影响收益。口径固定、数据齐备、可验证的查询适合先覆盖；信息含糊时先澄清，复杂分析交给人工继续处理。如果问题用固定报表或参数化查询就能稳定解决，也应把这类简单方案放进比较，判断 Agent 额外的灵活性是否值得复杂度与成本。

换成自动建单，痛点可能是从多处材料提取字段、查询主数据、反复录入与核对；换成代码 Agent，痛点可能是理解上下文、定位修改点、生成测试和整理变更。都应说明被减少的是哪种工作，而不是把“使用了大模型”本身当作收益。

同时衡量质量、人工投入和交付速度

建议围绕一个主要业务目标，配上必要的质量和成本指标。

• 正确交付率：在约定时限内，满足业务验收条件的任务数，占进入试验的目标任务数多少。问数看结果与业务口径，建单看实际单据，代码看需求与回归；失败、放弃和兜底任务也要保留。
• 人工投入：每条任务从澄清、操作到审阅、改错、接管，一共花了多少人工时间。多人参与时统计合计人时，并观察长尾任务是否消耗了大部分收益。
• 端到端交付时间：从用户提交到拿到可用结果的实际时长，包括排队、模型执行、工具等待和人工处理。它与人工操作分钟数分别记录，不能把并行执行的时间简单相加。
• 处理能力和覆盖：单位人时完成多少合格任务，目标需求中多少能够自助处理，以及真实用户是否持续使用。注册量、调用量或生成代码行数只能说明活动程度。
• 质量与成本约束：关注错误率、返工率、投诉、异常操作，以及每个合格交付的总成本。反馈和转人工都要结合原因解释，合理澄清或接管可能正是保证质量的方式。

数据最好通过同一任务标识串起提交、模型与工具记录、人工接管、最终验收和后续修正。满意度调查能补充体验，但主观感觉更快不等于实际交付更快。METR 对早期 AI 编程工具的实测专门区分了两者；这类研究提供的是验证方法与场景边界，不能直接代替当前项目的结论。

用完整口径计算节省了多少

下面是说明计算方法的假设例子：两种流程都完成 100 条同类需求，并按相同规则验收。人工流程总共投入 1,500 分钟；Agent 辅助流程加上审阅、修改和失败任务接管，总共投入 500 分钟。

人工投入减少比例为：

(1,500 - 500) / 1,500 × 100% ≈ 66.7%。

这批需求释放的人工时间约为 (1500 - 500) / 60 = 16.7 小时。它说明人工工作量减少，不表示用户等待也减少了 66.7%，更不直接等于工资支出降低。还需要观察这些时间是否转化成更多合格交付、缩短积压或承担其他工作。

核算成本时，可以采用：

每个合格交付的成本 =（人工成本 + 模型与工具费用 + 基础设施及分摊维护成本）/ 合格交付数量。

分子应包含试验范围内失败尝试、重试、人工兜底和返工所花的成本；研发接入成本若按预期使用期分摊，要说明口径。比较新旧流程时使用相同的成本边界。如果另行估算业务损失或新增收入，应独立说明依据，避免把同一项价值重复相加。

怎样判断改善来自 Agent

离线阶段，选择覆盖正常、复杂和异常情况的历史任务，固定数据快照和验收要求，比较人工、简单自动化和 Agent 辅助方案。由熟悉业务的人检查交付是否合格，先发现明显质量问题和成本瓶颈。

线上条件允许时，设置对照组继续原流程，实验组采用新流程。随机化单位可以是任务、用户或团队，应根据共享上下文、协作和学习效应选择，尽量避免两组互相影响；同时固定实验周期、主要指标、版本和统计口径。Google 的企业开发实验把是否使用指定 AI 功能作为随机分配条件，并明确任务完成标准，这种设计有助于减少人员能力差异造成的混淆，但其具体收益也受工具、任务和受试人群限制。

分析时既看改善幅度，也看样本量和置信区间。总体变快，可能是简单查询占比提高，或熟练用户更愿意使用新入口，因此要按任务难度、用户经验等切片。已经分到实验组但最后放弃或转人工的任务也要统计，不能只选成功使用 Agent 的记录。

样本少或暂时无法随机分组时，可以做同类任务匹配、分批试点和前后对照，并记录人员、流程与业务量变化。这能提供初步证据，但归因强度弱于设计合理的随机实验。刚上线时可能有学习成本，也可能有新鲜感，后续还需持续观察质量和投入是否稳定。

追问：成功率上升，却没有省时间，怎么办？

先拆开时间花在哪里：新增审核是否抵消了生成收益，低成功率长尾是否频繁转人工，工具等待是否拉长交付，用户是否需要反复补充上下文。再决定缩小自动处理范围、改善输入收集、复用确定性工具，还是调整审阅方式。目标不是让每个任务都自动完成，而是让适合的任务在可接受质量和成本下更容易完成。

讲项目结果时，把承担的模块与变化连起来。例如元数据召回减少了哪类 SQL 错误，错误处理减少了哪类人工接管，再给出相同口径下的结果和仍需人工处理的范围。任务成功如何定义和计数，可继续看如何量化评估 Agent 输出质量或任务成功率？。

对应教程

参考资料