先问"能不能做"：把模糊判断拆成 6 个工程信号
大多数 Agent 项目的立项会议，最后拍板靠的是两样东西：一段跑得很顺的演示，和供应商一句"这个场景我们做过"。这两样都不假，但都回答不了真正该问的问题——这个任务交给 Agent，工程上能不能稳定收敛。把"值不值得做"直接当成商业问题来谈，往往是把后面三个月的返工提前埋进了合同里。
问题的根子在评估这一端还没收口。如今衡量 Agent 的基准遍地都是，从偏学术的推理题到贴近产业的端到端任务，光是成体系的大类就有十几种，彼此口径不一、覆盖场景各异。结果是同一个 Agent 拿不同基准去测，分数可以差出一截，而决策者手上并没有一把能横向对齐的尺子。基准多不等于有标准，恰恰因为缺一个公认坐标系，选型才更容易被漂亮的单点数字带偏。
更要紧的是，演示态和生产态之间隔着一道很陡的台阶。在受控的、步骤不长的样例里，今天的强模型确实能给出令人信服的表现；可一旦换到需要多轮规划、跨工具调用、状态会累积的复杂流程，哪怕是第一梯队的模型，能把整条链路一次走通的比例也会掉得很厉害——远没到能闭眼托付给终端用户的程度。这不是某个模型的短板，而是当前这代技术在长程任务上的共同天花板。它给决策者的提示很直接：不要用一次成功的 demo，去推断一万次执行的稳定性。
所以我们把"能不能做"拆开，落到六个可以逐项核验的工程信号上。它们不是打分表，而是一串前置闸门——任何一道关不上，后面投多少资源都是在赌运气：
- 数据可得性：任务的对错能不能被明确"断言"，有没有足够的真实样本去定义成功与失败。这一关决定了你后面有没有东西可测。
- 流程稳定性：除了最终的 success_rate，中间每一步是否可观测、可复现。整体成功率高，未必代表过程不靠运气。
- 确定性边界：同一个输入反复跑，结果分布有多散。这直接决定它能不能直接面向用户，还是只能放在人工兜底之后。
- ROI 边界：能力天花板在哪，评估会不会过早饱和。投入产出不是看峰值，而是看那条能力曲线还有没有继续抬升的空间。
- 风险可治理性：错误发生时有没有 Guardrail 能拦住。没有可落地的护栏，再高的平均表现也不该上线。
- 评估可补建：现在没有现成评测集，并不意味着项目要否决。它是 Go/No-Go 前最后补齐的一勾，而非阻塞立项的硬条件。
这六个信号的次序是有讲究的。前两个回答"任务本身可不可被工程化"，中间两个回答"做到什么程度算够用"，后两个回答"出了问题收不收得住"。一个值得做的 Agent 项目，不是六项都满分，而是清楚自己卡在哪一项、缺口有多大、补这个缺口要花多少代价。接下来我们逐个拆解，先从最容易被跳过、却最致命的那一条说起——任务的成败，到底能不能被明确地断言出来。
信号一：任务能否被"断言"——数据与样本可得性
很多团队在评估 Agent 项目时,第一句话就问错了:"现在的模型够不够强?"这个问题排在后面。立项阶段真正卡住你的,是一个更朴素的事实——你能不能把这个任务写成一组可被检验的"断言"。也就是说,给定某个输入,你能否清楚说出"正确的结果应该长这样",并且找出几十个真实场景把这句话填满。如果连这一步都做不到,模型再强也没有抓手。
所谓"断言",落到工程上就是一条样本:一个输入、一个期望行为、一个判定标准。把任务拆成断言的过程,本质是在逼问自己——这件事到底有没有明确的对错。能拆出来,说明业务逻辑是收敛的;拆不出来,往往不是技术问题,而是需求本身还停在含糊地带。这一道闸门拦掉的,常常是那些"听起来很值得做、但谁也说不清做成什么样算成功"的项目。
样本量不必吓人。一个常见的误区是觉得评估集要上千条才有意义,于是迟迟不敢动手。实际上,Anthropic 在其 2024 年发布的 Agent 评估实践中给出的起点是 30 到 50 条高价值样本即可启动;另有面向 Agent 开发的工程指引(2024 年)也提到,从 20 到 50 个真实失败案例出发就能跑起有效评估,不必等攒够几百个任务。背后的道理很直接:早期 Agent 每改一次系统,行为差异往往是肉眼可见的量级,这种粗颗粒的变化,小样本就足以分辨。等到后期需要区分 92% 和 93% 的细微差距时,再扩充样本量也不迟。换句话说,样本规模应该跟着你要回答的问题精度走,而不是一上来就追求统计学上的好看。
真正决定样本质量的,是覆盖面而非数量。一组只有正常路径的样本,等于在演示"一切顺利时它能跑",这对判断可行性几乎没有价值。值得攒的样本必须横跨几类截然不同的路径:
- 正常路径:输入规范、流程通畅,任务该怎么完成就怎么完成。这是基线,但只是基线。
- 边界路径:信息不全、参数缺失、上下文模糊。Agent 是会追问、会合理兜底,还是会硬着头皮编一个答案出来。
- 故障路径:依赖的工具调用失败、接口超时、返回了非预期结构。这一类直接检验它在不确定环境下的鲁棒性。
- 风险路径:涉及不可逆操作、敏感动作或高代价决策的场景。它该停下来请示,还是会自作主张地往前冲。
这套四类划分,和业界一些更细的分法是一脉相承的。有评估方法(2024 年)进一步把任务拆成正常完成、信息缺失、工具失败、高风险动作、干扰噪音五类,建议初期构建 50 到 100 个任务。粒度不同,内核一致——你要主动去构造那些"不顺利"的情形,因为 Agent 的真实价值恰恰体现在它如何处理意外,而不是它在理想条件下的表现。
这里藏着一个比"凑不齐样本"更值得警惕的信号。当你试图为某一类路径构造样本,却发现根本写不出来——比如说不清楚"信息缺失时正确的行为是什么",或者无法定义"哪些算高风险动作"——这通常不是样本难找,而是业务规则压根没想透。这种情况下,缺的不是数据,是对问题本身的理解。强行上马,只会把模糊的需求外包给一个无法被检验的系统,最后谁也说不清它到底有没有做对。
所以这一节的判断很干脆:凑不齐样本,比模型不够强更应该叫停。模型能力会随时间提升,接口会升级,成本会下降,这些都是可以等的变量。但如果一个任务无法被断言、无法被构造成可检验的样本,那它在工程意义上就是个黑箱——你既无法判断它现在能不能做,也无法在做了之后知道它做得对不对。立项前花一两天时间,认真攒 30 到 50 条覆盖四类路径的样本,本身就是最便宜的一次可行性测试。攒得出来,后面的信号才值得继续往下看;攒不出来,省下的可能是几个月的返工。
信号二：流程稳定性——success_rate 之外的中间层
很多项目立项时只盯着一个数：任务最终做对了多少。这个数高，团队就觉得稳；低，就觉得不能上。问题是，这个数把整条执行链路压成了一个二元结果，所有发生在中间的事故都被它吞掉了。一个 Agent 可以在规划阶段把步骤排错顺序、却因为后续步骤恰好纠正回来而蒙对最终答案；也可以在调用工具时传了不合 schema 的参数、靠重试三次才侥幸通过；还可以把检索到的证据截断了一半，最后输出却碰巧落在正确区间。这些情况下最终成功率看着没问题，但你部署到生产、换一批输入分布，它们立刻原形毕露。
所以判断一个 Agent 任务值不值得做，第二个信号是：你能不能看见它"怎么完成的"，而不只是"完成了没有"。如果现在的评估只能产出一个总成功率，那这个项目的真实稳定性对你是黑箱，立项时给出的任何稳定性承诺都是猜的。
要把黑箱打开，得把观测拆成四个独立的层，每一层回答一个不同的问题，并且必须同时看，不能只挑顺眼的那层：
- 任务层——最终结果对不对。这是大家熟悉的那个成功率，是结论，不是过程。
- 证据层——结论站不站得住。Agent 给出的答案背后有没有对应的检索引用，证据是否被完整保留。一个没有证据支撑的"正确答案"，在合规和可追溯场景里等于没答。
- 执行层——工具有没有被正确驱动。工具调用的成功率、schema 校验的失败率，直接反映 Agent 和外部系统的接口是否稳。这一层崩了，任务层的成功往往是靠重试堆出来的，不可复制。
- 风险层——有没有踩线。越权操作被拦截的比例、预算/配额超限的比例。这一层是底线，哪怕前三层都漂亮，这层有漏，系统就不能面向真实用户。
这四层的价值在于互相印证。任务层告诉你结果，另外三层告诉你结果是不是可信、可复制、可控。只看任务层，等于只验收了一栋楼的外立面，墙里的钢筋有没有偷工你一无所知。我见过不少团队在 demo 阶段任务层很漂亮，一进灰度执行层的 schema 失败率就飙起来，原因是测试集里工具返回格式太规整，真实环境一变就崩——这种问题，单看成功率永远暴露不了。
四层框架解决了"看见故障"的问题，但还有一个更隐蔽的维度：效率。两个 Agent 都能把任务做对，一个走五步，一个走二十步外加七次重复调用，从任务层看它们一模一样，工程意义上却是天壤之别。步数多意味着延迟高、token 成本高、出错面更大，长期跑下来稳定性必然更差。所以过程指标要单独拎出来观测——平均步数、无效调用率（调了但对任务没贡献的那些）、重复调用率（同一个工具用几乎相同的参数反复打）。这几个数能帮你区分"勉强做对"和"干净利落地做对"，前者上线就是定时炸弹。
效率之外，工具调用本身的质量也得拆开看，因为"调用失败"和"调用成功但用错了"是两类完全不同的问题，混在一个成功率里就废了。具体拆成四个维度：
- 选择正确——该用哪个工具就用哪个，没有拿查询接口去做写操作这类错配。
- 参数正确——传进去的字段、类型、取值合规，不靠下游容错兜底。
- 时机正确——在该调用的步骤调用，没有过早（信息还没齐）或过晚（已经能答了还在查）。
- 结果理解正确——拿到工具返回后能正确解析，不会把报错当数据、把空结果当有效内容继续往下走。
这四个维度里，时机和结果理解最容易被忽略，也最容易在生产里出事。参数错了通常会立刻报错、有迹可循；但时机错了、结果理解错了，Agent 往往不会报错，它会带着错误的前提一路往下走，直到最终输出才暴露，而那时你已经很难定位是哪一步出的问题。所以这两个维度值得单独统计，不要并进笼统的工具成功率里。另外，对那些高风险工具——能改数据、能花钱、能对外发请求的——它们的违规调用次数必须单独计数，而不是和普通调用混在一起算比例。一个普通查询工具偶尔调错无伤大雅，一个支付或删除工具调错一次就是事故，二者的容忍度不在一个量级，评估口径也不该一样。
把这些放在一起，信号二的判断标准就清楚了：如果你现在只能拿到一个最终成功率，那这个项目的流程稳定性是不可知的，立项时应该把"建立四层观测 + 过程指标 + 工具调用分维度统计"列为前置工作，而不是上线后再补。能把这套观测建起来，你才有资格说这个 Agent 流程"稳"；建不起来，所谓的稳定就只是一句没有数据支撑的乐观判断。
信号三：确定性边界——pass^k 决定它能不能面向用户
很多团队在验证 Agent 时只看一个数字：跑一遍，成了没有。成了就觉得"这事能做"，于是排期、立项、对外承诺。问题是，给单次结果背书，和给"每次都对"背书，是两件完全不同的工程承诺。前者只需要运气配合一次，后者要求系统在连续调用里都不掉链子。把这两件事混为一谈，是 Agent 项目上线后口碑崩盘的常见起点。
区分它们，业内用两个指标：一个回答"在 k 次尝试里至少成功一次"，另一个回答"连续 k 次每一次都成功"。前者衡量能力上限，对探索类、可重试的任务有意义；后者衡量交付下限，决定一个 Agent 能不能直接面对真实用户。决策的关键在于：你的业务吃的是哪一个。如果终端用户每次交互都期待正确结果，那就只有后者算数，前者再漂亮也是自欺。
这里有个反直觉的算术，值得每个决策者算一遍。假设单次任务的成功率是 75%——听起来已经相当不错，四次里只错一次。但如果一个完整业务流程需要连续三步都成功，按独立事件估算，整条链路走通的概率是 0.75 的三次方，大约只剩四成出头。也就是说，单看一步你觉得"基本靠谱"，串起来用户实际拿到正确结果的概率，还不到一半。这个塌陷不是线性的，而是随步数指数级恶化。链路越长、串联节点越多，单点的小瑕疵被放大得越狠。
把这个规律倒过来看更有用：当你发现一个面向用户的 Agent 上线后投诉率高得离谱，但单步抽查又"看起来还行"，多半不是某个环节坏了，而是你从一开始就用单次成功率给多步链路做了背书。指数衰减不会因为每一步都"差不多"就放过你，它只会把每一步的"差不多"乘起来，变成用户眼里的"经常出错"。
更要命的是基础能力本身的天花板。行业评测普遍显示，在足够复杂的真实场景里，即便是当前最强的模型，单次任务成功率也可能低到只有三成左右。把 30% 代入上面的连乘逻辑：两步串联剩不到一成，三步几乎归零。这意味着，在强一致性、面向用户、不容许出错的场景里，一个基础成功率只有三成的方案根本不是"再优化优化就能上"，而是结构上就不具备交付资格。再多的提示词调优也救不回数量级的差距。
那是不是说成功率不够高就一律枪毙？也不是。这条边界的松紧，取决于业务能不能容忍兜底。我的判断框架是这样分的：
- 可以人工兜底的场景：Agent 输出先进人工审核或人工修正环节，错了有人接得住。这类场景对"每次都对"的要求可以放宽，单次成功率达到能显著降低人力的水平就值得做，重点变成衡量节省了多少人工，而不是追求零错误。
- 可以异步重试的场景：任务不要求实时返回，失败了能自动重跑或换路径再试。这时候真正该看的是"几次尝试内至少成一次"的概率，而不是单次的确定性，重试本身就是把成功率往上抬的工程手段。
- 既不能兜底也不能重试的场景：用户实时拿到结果、结果直接生效、错了就是事故。支付、合规判定、对外自动回复都属于这类。这条线必须在立项文档里标红——它要求的是连续成功的确定性下限，而不是某次跑通的能力上限。
所以这一节给决策者的动作很具体：先确认你要做的 Agent 落在哪一类，再决定用哪个口径去验收。把任务拆成它实际要走的步数，对每一步估一个保守的成功率，连乘一遍，看看链路末端剩下多少。如果这个数字撑不起业务对一致性的要求，而场景又恰好不能兜底、不能重试，那么无论单步演示多惊艳，结论都应该是缓做或不做。这不是悲观，是把上线后必然暴露的成本提前算清楚——立项阶段多算这一次乘法，省下的是事故复盘时一整个团队的时间。
信号四：ROI 边界——能力天花板与评估饱和陷阱
立项会上最容易被采信的，是一条向上的曲线。有人会拿出公开基准的进步速度说事：在 SWE-bench Verified 这类编码评估上，前沿模型一年之内把得分从四成左右推到了八成。这个斜率确实陡，足以让会议室里的人相信「再等半年就能落地」。但把这条曲线直接当成自己项目的 ROI 预期，是我见过最常见的误判。
问题出在分数和能力之间并不是线性对应。当一个基准接近饱和，留在榜单上没被解决的那批任务，恰恰是难度最高、最反直觉、最依赖长链推理的部分。模型能力即便有实打实的跃升，反映到分数上也只是几个百分点的挪动。换句话说，越接近天花板，每一分的含金量越高、获取成本越陡，而你从曲线斜率推算出来的「进步速度」却在系统性地高估后续收益。决策者看到的是平滑外推，工程上对应的却是边际收益急剧递减的那一段。把演示阶段的乐观斜率当作落地后的增长假设，ROI 模型从第一步就偏了。
更隐蔽的失真，发生在你只盯着一个指标的时候。我手上有一个企业知识库 Agent 的真实例子，能说明单指标视角会怎样骗人。团队改了一版 Prompt，在离线 20 条样本上跑下来，任务成功率从 71% 抬到了 83%。单看这一个数，提升十二个点，立项材料里写「显著优化」毫无压力。
但把同一批样本的其他维度摊开看，画面完全变了：
- 引用准确率（citation_rate）从 88% 塌到 61%——成功率涨上去的代价，是模型开始编造或张冠李戴引用来源，而这在知识库场景里几乎是致命缺陷；
- 平均工具调用次数从 2.1 次涨到 3.8 次——成功更多是靠「多试几次」堆出来的，每一次调用都是真金白银的 token 和接口成本；
- p95 延迟直接翻倍——头部用户体验到的等待时间翻了一番，在交互式场景里这往往就是流失的分水岭。
这就是关键：成功率这一个数字孤立地看是涨的，综合算下来收益可能是负的。多出来的两次工具调用乘以日活和单次成本，是一笔持续支出；翻倍的延迟意味着要么扩容、要么牺牲体验；而引用准确率的崩塌，会把人工复核的工作量重新加回来——你以为 Agent 替人省下的那部分活，又因为不可信的引用被退回到人工核对的环节。这三项叠加，很可能把那十二个点的成功率红利全部吃掉，甚至倒贴。
所以 ROI 判断不能锚在任何单一指标的乐观读数上，要锚在两件事上。第一是能力天花板：这类任务在公开基准上是处于陡升段还是已经接近饱和？如果你的核心场景对标的恰好是榜单上那批最难任务，那就别指望短期内靠模型迭代白捡收益，该投入的工程兜底一分都省不掉。第二是综合成本账：把延迟、调用次数、token 开销、以及最容易被忽略的人工复核成本，全部折算进同一张表，再去和成功率的提升做净额对冲。一个只在某个指标上变好、却在其余维度集体劣化的方案，工程上不叫优化，叫成本转移——你只是把代价从一个看得见的地方挪到了几个看不见的地方。
给决策者的可操作判断是：要求任何「成功率提升」的结论，都必须附带同一批样本上的引用准确率、调用次数和 p95 延迟三项配套数据；缺其中任何一项，这个 ROI 结论就不成立，不能作为 Go 的依据。演示阶段挑一个好看的数字很容易，能把整张成本表摊开还为正的，才值得往下走。
信号五：风险可治理性——没有 Guardrail 不要上
前四个信号回答的是"做不做得出来"，这一节回答另一个问题：做出来之后，它失控时你拦不拦得住。一个 Agent 一旦能调工具、能写数据，它的每次决策就不再只是文本生成，而是带副作用的动作。判断一个项目值不值得上线，最现实的标准不是它平均表现多好，而是它出错时的代价你能不能兜住。如果答案是"不能"，那这个项目的优先级应该往后排，先把治理层补齐再谈上线。
我习惯把治理拆成三层来看：能不能挡住、能不能恢复、能不能看见。三层缺一层，风险就不可控。
第一层：动作发生前能不能挡住
最小可用的线上防护，落到实处其实就是几道硬卡点，每一道都对应一类已经踩过的坑。模型输出的结构体如果通不过 schema 校验，就不该进入下游执行，直接阻断比"尽力解析"安全得多——下游拿到半个字段的 JSON，往往比直接报错更难排查。任何写操作都要先过一遍策略校验，把"能不能写、写到哪、谁授权"从模型的自由发挥里拿出来，交给确定性的规则。单次任务的 token 或工具调用一旦逼近预算上限，立刻降级而不是硬扛，否则一个陷入循环的 run 能把成本和延迟同时拉爆。还有一类容易被忽略的：当模型在没有检索到任何证据的情况下仍然给出结论，这种回答要被打上高风险标记，而不是和正常回答混在一起返回给用户。
这些卡点的共同点是，它们都不依赖模型自己"想清楚"，而是把判断权收回到工程侧。这正是 Guardrail 的意义：模型可以犯错，但犯错的边界由你画。
第二层：出错之后能不能恢复
挡住只是第一步，更能区分项目成熟度的是错误恢复能力。这里我不建议用一个笼统的"恢复成功率"来衡量，因为不同错误类型的正确恢复姿势完全不同，混在一起算反而看不出问题。
- 缺参数：正确的反应是停下来向用户追问，而不是拿默认值蒙一个。能不能识别"信息不足"并主动发问，是一个很硬的能力分水岭。
- 工具超时：要做的是有限次重试加退避，而不是无脑重试到把对方服务打挂，也不是一次失败就直接放弃。
- 权限不足：唯一正确的反应是停止并上报，绝不能让 Agent 学会"绕过权限"。一个会想办法绕权限的 Agent，比一个会报错的 Agent 危险得多。
按错误类型分别统计恢复行为，你才能看清模型是真的会处理异常，还是只是在顺境里表现良好。
第三层：线上能不能看见
前两层做得再好，看不见也等于没有治理。关键的 run 要全量保留 trace——不是抽样，是全量，因为出问题的往往恰好是你没采样到的那一条。在指标层，仅靠任务完成率远远不够，它只告诉你"成了多少"，不告诉你"怎么成的、差点出了什么事"。
一套能真正支撑判断的线上监控，大致需要十来个维度协同：工具调用次数、任务完成率、平均执行步数、用户追问率、工具失败率、超时率、重复调用率，这几项刻画"跑得顺不顺"；而高风险动作确认率、用户取消率、人工接管率、用户差评率、安全拦截次数，这几项才真正刻画"风险大不大"。后半组里，人工接管率和安全拦截次数尤其值得盯——前者反映系统在多少比例的情况下还得靠人兜底，后者反映防护层到底有没有在干活。如果这些指标在你现有的可观测体系里根本采不上来，那风险可治理性这一项就应该判定为不达标。
把这三层连起来看，结论很直接：能挡、能恢复、能看见，三者齐备，项目才具备上线条件；缺任何一层，这个 Agent 就还不该面向真实用户和真实数据。Guardrail 不是上线后再补的优化项，而是决定"能不能上"的前置条件。
信号六：评估可补建——它不是立项的阻塞项，而是 Go/No-Go 的最后一勾
前面五个信号谈的都是"这件事本身能不能做"，到了第六个信号，关注点转向"我们有没有能力知道自己做得对不对"。很多团队卡在这里：现成的评估体系一个都没有，于是判断陷入停滞，要么因为"测不了"而否决一个本该上马的项目，要么因为"先跑起来再说"而上线一个无法回看的黑箱。这两种都是误判。评估体系的价值毋庸置疑，但它的建设时机和立项决策是两件事。
真实工程里的常见路径，是先有产品、有了真实流量之后，再回头把评估补齐。已经积累了相当规模用户的 agent 团队，在产品跑起来之后才系统性地搭建评估，把静态分析打分、浏览器端的真实任务测试、模型充当裁判这三层组合起来，整个过程花的是数月而非数年。另一类做法是让评估随产品一起长大：早期靠人工逐条打分，等到积累了足够的判断样本，再把人的判断蒸馏成 LLM 评分器，围绕"不破坏原有内容、确实完成了指令、产出质量过关"这几个维度建立打分逻辑，并保留定期人工校准的环节，最终演进成两套互相独立的套件——一套盯质量基线，一套防回归。这两条路径说明同一件事：评估能补，而且补建的成本是可控的、可预期的。所以在立项阶段，它不该是一票否决的硬门槛，而应该是上线前必须勾完的最后一项。
反过来，更值得警惕的不是"没有评估"，而是"评估本身有缺陷"。一个设计粗糙的评估，会系统性地低估你的 agent，进而让你亲手砍掉一个其实跑得很好的项目。在某个代码与科研类基准上，一个能力很强的模型最初只拿到四成出头的分数，看上去差得离谱；后来研究者逐条排查才发现，问题出在评估侧：评分器把数值近似当成了错误（一个理应判对的答案因为小数尾数被算成错），任务描述本身含糊，还有部分随机任务根本无法稳定复现。把这些坑填平、换用更合理的判定口径之后，同一个模型的分数直接逼近满分。差距不在 agent，而在尺子。
另一个例子更微妙。在一个航班预订类的对话基准里，agent 钻研了规则、为用户找到了一个比标准答案更划算的方案，结果因为这个方案不在评估脚本预先写死的"正确路径"里，被判定为失败。它做得比评估期望的更好，却因此扣了分。这类错误的可怕之处在于，它惩罚的恰恰是真正有创造力、有能力的 agent——如果你只看分数，就会得出"这条路走不通"的结论，然后转身投入一个看起来分数漂亮、实则平庸的方案。
所以第六个信号的真正含义是：评估必须建，但更要建对。把前面六个信号收敛下来，立项时不必要求评估体系到位，上线前却必须满足一份发布清单——至少三十条带明确断言的离线样本，让"对不对"有客观依据；指标按数据、单步、流程、业务四个层次拆开，避免用一个笼统的成功率掩盖真正的故障层；关键失败样本支持原样回放，否则你修了 bug 也无从验证；所有高风险的写操作必须接入线上 Guardrail，把不可逆的动作挡在闸门之后；每次版本变更都留下前后对比结果，让每一次改动都能说清楚是变好了还是变坏了。六个信号全部过关，并不保证项目成功，但任何一个长期亮红灯，都值得你在投入之前停下来重新算账。
这六个信号有优先级吗？哪个不过关就该直接否决？
有先后，但不是简单排序。前三个信号——数据与样本能不能拿到、流程稳不稳、确定性边界够不够——属于"地基级"，任何一个长期不达标，项目基本不成立，应当直接否决或推迟。后三个是"可治理级"：ROI 边界帮你判断值不值得做，风险可治理性决定能不能面向真实用户，评估可补建则是上线前的最后一道勾。地基级不过关是硬否决，可治理级不过关往往是"先解决再上"，而不是"放弃"。
成功率只有 30% 是不是意味着企业 Agent 现在都不值得做？
不是。单看一个笼统的成功率得出否决结论，恰恰是这套框架要避免的错误。三成的端到端成功率，可能意味着流程里某一个具体环节在拖后腿，把指标按四层拆开之后，你常常会发现数据层和单步层都不差，问题集中在流程衔接或某类边界输入上——这些是可修的。更何况，正如前面那两个评估缺陷的例子，低分本身也可能是尺子的问题。先定位失败发生在哪一层，再决定值不值得做，比盯着一个总分拍板要可靠得多。
立项阶段还没有评估体系，是不是就不能做判断？
恰恰相反。评估体系是可以在产品成熟阶段补建的工程资产，数月即可成型，不该成为立项的前置条件。立项阶段你真正需要确认的，是"任务能不能被断言"——也就是结果有没有客观的对错标准、样本能不能拿到。只要这一点成立，评估就是早晚能补上的；如果连这一点都不成立，那才是真正该停下来的信号，而且补建评估也救不了。
如何避免被漂亮的 demo 或评测分数误导？
对 demo，看的是它能不能稳定重放——同一个场景跑十次有几次成功，而不是剪辑过的一次成功。对评测分数，先去读评分逻辑本身：它是怎么判对错的，有没有把数值近似算成错误，任务描述是否含糊，更优的非标准解会不会被误杀。一个能力很强的 agent 被低分埋没的情况是真实存在的。把"分数"和"分数怎么来的"分开看，再叠加前后对比和失败回放，你才不会被一个单一数字牵着走。