最受信任的智能体任务与最不受信任的任务之间相差 46 分（满分 100）——而这其中没有一分来自能力差距。在 2026 年 6 月 29 日发布的一份报告中，MIT Technology Review Insights 与 Microsoft 在 0 到 100 的信任量表上对 101 项智能体 AI 任务进行了排名，调查了来自 12 个行业的 300 位技术高管、团队负责人和一线贡献者（MIT Technology Review Insights, 2026）。自动报告生成得分 83.5，样板代码（boilerplate）得分 82.5。灾难恢复测试落在 43，服务网格（service mesh）配置为 37.5。执行这四项任务的模型是同一批。区分它们的，是人能否干净利落地验证输出——而这一个变量，本季度就应当重新排定你的 AI 智能体部署顺序。
大多数中端市场的部署都按照一个看似直觉、却在无声中错误的代理指标来排序：先部署那些看起来最简单的任务。该指数指出，运营层面的问题不是「这个任务对模型有多难」，而是「我能多容易地验证结果」。这是两条不同的轴，把它们混为一谈，正是一场资金充裕的部署在半年后陷入停滞的方式——留下一批没人足够信任、不敢放手无人监督的智能体。
该指数究竟测量了什么
方法论很重要，因为正是它让结论可用，而非只是轶事。研究团队于 2026 年 2 月和 3 月调查了 300 位从业者——高管、团队负责人和个人贡献者——覆盖 12 个行业、从初创公司到年营收超过 100 亿美元的企业（Microsoft Cloud Blog, 2026）。随后，他们在 0 到 100 的信任量表上，对 AI、数据和云工作流中的 101 项独立任务打分，分数反映从业者愿意把该任务交给智能体的程度。
结果并非 AI 能做什么的排名。它是操作者愿意放手让其在无人监督下完成什么的排名——而这两者之间的差距，就是全部要义。报告本身的措辞很直白：聚在顶部的任务共享可验证性和完整的业务上下文，而底部的任务两者皆缺（MIT Technology Review Insights, 2026）。能力不是那个区分变量。可验证性才是。
为什么「最简单」是错误的排序键
看看顶部的两项任务。自动报告生成（83.5）和样板代码（82.5）受信任，并非因为它们微不足道——从杂乱输入生成一份连贯的报告，是一个实实在在困难的建模问题。它们受信任，是因为各自都有单一的、客观的评分信号。样板代码要么通过测试并被合并，要么没有；合并率（merge rate）是一个干净的通过/失败指标，人在几秒内即可审核。生成的报告可以与其所摘要的源数据核对。智能体的工作是可读的。
再看底部。服务网格配置（37.5）和灾难恢复测试（43）之所以不受信任，并非因为模型在这些任务上更差（Forbes, 2026）。它们不受信任，是因为没有一个干净的单一指标告诉你智能体做对了——而且做对与否取决于智能体并不掌握的业务上下文：哪些服务是承载性的、你真实的故障切换（failover）容忍度是多少、哪些依赖是未记录的部门内隐知识。你无法在不重建那个当初使任务变难的上下文的情况下验证输出。其失败模式不是一个错误答案；而是一个你无法自信评判、直到生产环境中某处崩溃才知晓的答案。
这正是大多数部署搞反的排序键。「看起来简单」的任务和「可验证」的任务，感觉上是同一批。它们不是。一个任务可以描述起来简单，验证起来却近乎不可能——协调两个相互矛盾的数据源、起草一项政策例外、对一张模棱两可的工单分类。该指数说：别再按表面简单度排序，改按一个更难、更诚实的问题排序：当这个智能体完成后，告诉我它成功了的那个唯一指标是什么——而我能否在不重做工作的情况下读到它？
指标才是你部署顺序的真正闸门
把部署排序重新界定为「指标可得性」问题，整个部署计划就会自行重排。
对每个候选工作流，准入测试不是「智能体能否做到」，而是「这上面是否附有一个干净的成功信号」。凡是存在合并率、通过或失败的对账检查、模式校验结果，或与基准真值（ground truth）比对的地方，智能体便可在轻度监督下运行，你就获得了真正的杠杆。凡是唯一得知智能体做对的方式，是让一位有经验的人从头到尾重新审视情形，你就没有把任务自动化——你只是在仍然必须完成的工作前面加了一道草稿步骤。这仍可能值得。但这是一个根本不同的经济命题，而假装这两类是同一类，正是「生产力收益」蒸发为审查开销的方式。
务实的做法，是审计你的目标工作流，并恰好沿这条线把它们一分为二。拥有原生、客观成功指标的任务排到部署队列的前面。其正确性取决于智能体所没有的业务上下文——因而人为了检查必须完整重新推导——的任务排到后面，排在为构建这种可验证性而进行的刻意工作之后：埋点一个指标、编码缺失的上下文，或收窄任务直到存在一个干净的检查。可验证性不是任务的固定属性。它是你可以工程化的东西——而工程化它，才是规模化智能体的真正前提，而非模型选择。
问责制才是藏在数字背后的约束
该指数还揭示了为什么这种排序并非可选。当被问及智能体部署中令他们担忧之处时，受访者把问责制（48%）和幻觉（47%）列为首要顾虑——而 59% 表示他们已在规划永久性的人工监督，而非将其视为一个临时的辅助阶段（MIT Technology Review Insights, 2026）。把这三个数字放在一起读，机制便清晰了。问责制要求：当出错时，一位被指名的人本可以将其拦截。这只有在输出可验证时才有可能。在一项不可验证的任务上，「人工监督」是表演——一个人在为其实际上无法检查的工作签字。
所以，那 59% 规划永久监督的人——无论他们是否如此表述——正在承认：他们相当大一部分的智能体工作流位于该指数的低可验证性一端。对此的诚实回应，不是更多的审批步骤。而是这样排定部署：让监督落到能做真实工作之处——落到有干净指标的高价值任务上——并把那些监督无法证伪的任务先按下不表，直到你构建出让问责制有意义的那个指标。那 48% 提到问责制的人，并非在要求更慢的 AI。他们在要求可验证的 AI，而部署顺序正是此事的决断之处。
先部署什么——又该按下什么
以上没有一条是主张放慢。它主张改变排序。以下是该指数支持的具体重排：
先部署： 拥有原生客观成功指标的任务——对照源数据评分的报告生成、以测试并合并（test-and-merge）评分的代码、以模式一致性评分的数据校验、对照基准真值评分的匹配与对账。这些是你 80 分以上的任务。它们累积信任，因为每一次成功都可见。
先埋点，再部署： 有价值但当前不可验证、而你能添加一个指标的任务——定义一个验收检查、记录一次对基准真值的比对、收窄范围直到存在一个通过/失败信号。大部分未被开采的 ROI 就住在这里，而若你只按表面难度排序，它便隐而不见。
按下不表： 上下文密集、判断密集、验证意味着完整重建情形的任务——你自身运营中灾难恢复与服务网格的对应物。先自动化它们，正是你制造出该指数所测量的那种问责焦虑的方式。
还有一层定位，大多数部署会跳过。对未经验证的智能体输出的容忍度，在团队内部并不均匀——某些角色和行为画像会过度信任一个低可验证性的智能体，另一些则连高可验证性的智能体都拒绝使用。按任务可验证性来排定智能体，是问题的结构性一半；把谁运行哪一类智能体，与人们实际如何校准信任相匹配，是人性的一半。两者都做对，就是「逐个任务累积信任的部署」与「头两个季度都耗在制造自己维持不了的监督的部署」之间的差别。
本季度唯一的一次排序
你无需重新架构任何东西来据此行动。你需要重新排序一份清单。拿出你当前的智能体部署顺序——你本季度打算自动化的工作流序列——并按向每项任务发出的唯一一个问题重新排名：当智能体完成后，是否有一个干净的单一指标告诉我它成功了，而我能否在不重做工作的情况下读到它？ 每一个「是」上升。每一个「否」下降，排在为构建那个指标而做的明确工作之后。然后观察哪些智能体赢得了稳固的信任，哪些则在无声中累积起一队不可检查的输出，终于有人不再去审阅。
MIT–Microsoft 指数已在 101 项任务上替你标好了价：你能安全委派之事的边界，不是由能力划定的。它由可验证性划定。按错误的轴给部署排序，你就会先自动化那些你无法检查的任务——而只有当其中之一在生产环境中出错时，你才会发现代价。按正确的轴排序，你部署的每一个智能体，都会让下一个更易被信任。
