Agent 用例评估

从业务损失和用户任务开始

把诉求改写成可观察任务：哪个角色在什么触发条件下，要依据哪些信息完成什么决定或操作，当前结果如何进入业务系统。以“让客服更智能”为题无法建立基线；“退款专员在收到争议单后查订单、核政策、给出处置建议，并由工单终态确认结果”才可以测量。

基线至少包含任务量、端到端周期、有效人时、返工与错误、升级比例、用户放弃和当前成本。节省人时只有在人员容量被重新配置或吞吐真实增加时才成为价值，不能把模型生成速度直接等同于业务收益。瓶颈若来自审批排队、数据不可得或职责冲突，增加 Agent 只会更快地产生待处理项。

评估 Agent 适配度

Agent 更适合路径难以穷举、环境会变化、需要在多步中选择工具且中间状态可观察的任务。可接入的数据与 Tool 是硬前提，模型“知道怎么做”不等于系统拥有身份、权限、幂等和回执。若关键行动无法回读结果，系统连失败都无法确认。

每个候选用例都应与确定性 Workflow、搜索加表单、规则引擎、传统自动化和人工增强方案同表比较。输入稳定、路径固定、错误代价高的流程默认使用确定性编排；只需要找到依据时优先检索；只有开放式判断带来的增量价值足以覆盖不确定性，才引入 Agent 决策。

把价值拆成可验证假设

价值模型应写成因果链，而不是一个 ROI 百分比。采用率决定多少任务进入系统，任务成功率决定多少输入产生有效结果，人工复核与返工决定节省是否被吃掉，业务吸收率决定释放容量是否真的转化为吞吐、周期或服务覆盖。

单位成本按成功任务核算：模型与检索、Tool 调用、平台摊销、观测与评测、人工审批、失败恢复和风险准备都进入分子，业务终态成功数进入分母。FinOps Unit Economics 强调把技术支出与业务单位连接；若团队只能报告 Token 成本，仍无法判断一项用例是否值得规模化。

每成功任务净价值 = 可验证业务收益
  -（模型 + 工具 + 平台 + 人工复核 + 运营 + 失败损失）/ 成功任务数

期望组合价值 = 任务量 × 采用率 × 成功率 × 每成功任务净价值
  - 固定建设与迁移成本

高价值不等于可立即自治

风险由影响强度、暴露范围、可发现性和可恢复性共同决定。同样一次错误，内部草稿、对客户发信和执行资金动作的后果完全不同。NIST AI RMF Core 要求结合使用情境持续执行 Map、Measure 和 Manage；这支持按具体用例定控制强度，而不是给所有 Agent 一张统一检查表。

自治范围应逐级扩大：离线分析只产生证据；只读助手给出建议；受审批执行把参数绑定到授权；限额自治只处理低风险、可逆动作；高影响动作继续由人承担最终责任。升级条件必须量化到风险事件、未知结果率、复核抽检和权限范围，不能以“用户反馈不错”替代。

PoC 验证最关键的不确定性

PoC 的任务是消除最可能推翻投资的未知，而不是压缩版上线。先列假设：模型能否处理长尾输入，权限过滤是否正确，Tool 能否给出可对账回执，用户是否愿意改变工作流，单位成本是否随任务复杂度失控。每轮只投入足以区分继续与停止的成本。

测试集要覆盖常见分布、高风险边界、无答案、依赖故障和恶意输入，并尽量使用真实或等价的数据、权限和 Tool 契约。提前写质量、延迟、成本、安全、人工负担和采用阈值，也写停止条件，例如高风险违规不可接受、未知副作用超过上限或增量价值不足以覆盖复核。

在用例组合中排序

组合排序不能只看单项 ROI。还要看技术可行性、风险、共享依赖、复用性和学习期权。一个价值中等但能验证身份、Trace 与评测底座的用例，可能比孤立的高价值 Demo 更值得先做；反之，复用性只是未经验证的口号时，不应提前建设万能平台。

Scorecard 应保留原始变量和置信度，不要用一个总分掩盖否决项。高风险不可恢复、缺合法数据来源或没有业务 Owner 可以直接阻断；其余项目按价值兑现速度、依赖成熟度和学习价值排序。探索额度要有期限和预算，到期必须转 Pilot、收缩或归档。

输出有约束的投资结论

Go 表示基线、增量价值和核心控制已有证据；Conditional Go 只授权指定切片并列出前置条件；Hold 表示价值可能成立但依赖未就绪；No-Go 表示 Agent 不是合适手段或风险收益不成立。No-Go 是有效架构产出，不是创新失败。

结论必须绑定 Owner、预算、自治范围、下一里程碑、验收与到期日，并记录 Why Not、残余风险和反转条件。评审后若没有谁负责取得下一份证据，项目会自动滑入无止境 Demo；若没有退出门槛，历史投入会取代未来价值成为继续理由。