85.5% 的人信任智能体，41.1% 的人每天都在给它擦屁股

报告到底说了什么

Temporal 在 8 月下旬发布了它 2026 年关于 AI 智能体的《开发现状报告》。调查于 2026 年 4 月 29 日至 5 月 25 日在美国与英国进行，剔除低质量作答后覆盖 554 名软件工程师、架构师、基础设施贡献者与工程负责人。头条是采用率，而它确实陡峭。

先照单全收报告自己的框架，因为它站得住。它的论点是：采用跑赢了基础设施——工程师上手智能体的速度，快过他们所在的组织把运行这些智能体的系统建起来的速度；而领先的团队是那些把状态、成本与可靠性解决掉的团队。这是一个自洽的故事，阻碍那组数据也支持它。它同时恰恰是一家持久化执行公司靠讲它吃饭的故事，而这份问卷是由本就相信它的人设计的。这并不让它变错，只是让它值得拿那些没上头条的数字来对一对。

「信任」是错的变量，而这份调查继承了这个错误

「你信任智能体的产出吗？」把智能体可能采取的每一种动作都聚合了进去，而这个聚合几乎没有任何可操作的含义。信任一段调用栈的摘要，和信任一次数据库迁移，是两个撤销成本完全不同的决定；一个答「某种程度上」的工程师，描述的是对一整个类别的感觉。真正管住爆炸半径的那个决定压根不是标量：它是一份清单，列出哪些具体动作可以不经复核就跑、哪些需要审批、哪些永不授权——也就是 自主级别 铺开的那道阶梯，以及大多数团队从没写下来过的那份东西。

这很要紧，因为只有在标量读法下，那两个数字才看起来矛盾。在逐动作的读法下它们完全自洽，也远为令人不安：工程师对他们会复核的那一类产出信任很高，交付速度前所未有地快，而他们每天遇到的故障，出在那些他们已经不再复核的动作上。这份调查分不开这两者；一个只把信任当成一种情绪来讨论的团队，同样分不开。

这个问题在实践中的替代物，是运行记录里的两行。对智能体能执行的每一类动作：在动作落地之前，有多大比例的运行经过了人工复核？在被复核的动作里，又有多大比例被改动了？高复核率配上接近零的改动率，是一道你可以安全放松的控制。低复核率配上高改动率，就是你那 41.1% 的住处。

工程师点名的是他们看得见的那个阻碍

状态追踪 35.7%，其后是调试，再其后是成本。把它读作一份「可见度」排名，而不是一份「成因」排名。状态是你在调试器里盯着的东西——一次运行跑到一半失败、又续不上；它清晰、叫得出名字，而且背后还挂着一个产品品类。那正是问卷最容易问出来的那种答案，也是「状态追踪」为什么会赢过「我们从没定义过这个任务怎样才算做完」这类答案的原因——后者在上游，更难塞进一个勾选框，而且相当可能才是真正的缺陷。

状态确实是个难题，而持久化执行引擎也确实解决了其中一部分；本站关于 智能体的对话记录住在哪里 的比较，讲的就是它们修好了什么、没修好什么。但请注意，一次可恢复的运行给你买到了什么、又没买到什么。它买到的是「让崩掉的运行继续下去」的能力。它并不告诉你这次运行是否本就该继续、它此前已经做完的活儿是否正确，也不告诉你恢复之后会不会把某个副作用再做一遍。那些是评测与幂等的问题，而每日故障率通常正是由它们构成的——参见 幂等与重试：四层叠加的重试来源意味着，除非你刻意把「恰好一次」构造出来，否则每一个写操作工具都会触发两次。

那份阻碍排名其实关乎可见度，还有一个破绽：在一个 41.1% 的人报告每日故障的人群里，成本排到了第三位。每日故障率就是一笔成本——重跑的那次运行、被丢掉的产出、工程师的一个下午——而它排在成本之后，是因为这一切都不会作为账目上的一行抵达。供应商的账单是可见的；吸收掉这些故障的那份劳动不是。

错误处理器是个人

让 41.1% 变得可以扛下去的机制在这里。在一个常规服务里，故障会撞上一条代码路径——重试、降级、告警——并终止于一份事件记录和一份有人会在迭代末尾复盘的错误预算。而在智能体工作流里，故障通常被坐在它面前的那个工程师接住：他改写提示词、重跑任务，或者干脆手动把活儿干了，路径就到此为止。什么也没被发出去。没有告警响起，因为人已经处理掉了——那正是「已处理错误」的定义，也正是它永远不会变成数据的原因。

这就是为什么聚合起来会显得如此古怪。单看每一次故障都很便宜——一分钟、一次重跑、一句略微不同的提示词——而「便宜且频繁」正是那种永远不会被上报的画像。它同时也是那种悄悄给你团队的产能设了上限的画像，因为那些分钟是真实的，而花掉它们的那个人是这个循环里最昂贵的部件。经济学那一页 人工复核的成本 从另一头讲的是同一件事：复核者的成本是令牌成本的十到五十倍，而且是唯一一条不会随着模型变好而缩水的账目。

解法不是消灭这些故障——那不在选项里。解法是让「处理」这件事变得可见，而这几乎不花什么钱：在运行记录上加一个字段「有人介入过」，由介入实际发生的那个界面来写。一旦一周的运行都带上它，你就能按介入率给任务类别排序，并会发现每日故障率并不是均匀分布的——它是两三类任务贡献了其中大部分。那是一个可以下手的发现，也是一份调查永远不可能替你的系统给出的那件事。

吞吐上去了，复核没有

报告里最少被讨论的数字是：51.3% 的人现在能在数小时以内把原型变成可上生产的代码，26.9% 的人在数分钟以内。把它摆在每日故障率旁边，风险的形状就清楚了：生成那一步快了一大截，而它下游的一切都没有。复核容量没变，因为它受限于人的注意力；而抵达它的变更数量翻了好几倍。

这和 后台编码智能体 那份手册就 pull request 讲的是同一个瓶颈——一个每天开十二个 PR 的智能体，如果团队只合得进四个，就什么也没增加——只是被搬到了整个组织的层面上来说。一个到达率翻倍而服务率持平的队列不会优雅地退化：它要么无界地增长，要么服务率悄悄下降；而在一个复核队列里，后者意味着审批变浅。没有人决定要少认真一点，它之所以发生，只是因为另一个选项是一个永远清不空的队列。

与此并列的招聘数据显得别扭，值得用一段来提醒：56.7% 的人认为初级工程师会更难找到工作，45.5% 的人对资深工程师作同样判断，而只有 26.4% 的公司报告放缓或停止招聘。工程师的预期，比他们雇主的行为走得远得多。这两个数字都出自同一人群的自述，所以这道落差是一个关于情绪的事实，不是一个关于劳动力市场的事实，应当照这样来读。

这些该信几分

那些提醒很寻常，而且都要紧。这是一份厂商调查，这既塑造了它的框架，也塑造了它问了什么。人群是自选的，554 名受访者、两个国家，每一个数字都是自述的——包括「生产力提升」，它没有对照基线，且由那些主动来答一份关于智能体的问卷的人给出。「智能体相关问题」没有定义，所以它同时涵盖一个凭空捏造的 import 和一次生产事故。而在一份面向软件工程师的调查里，「每日使用智能体」很大程度上指的是编码助手——那和一个在生产环境里采取行动的自主智能体是两种动物；别把那 80.8% 读成部署率。

能扛过这一切的是那个内部比较，因为两个数字来自同一份工具、同一批受访者。任何抬高了信任数字的偏差，也会同样抬高故障数字，而故障数字无论如何都是高的。一个报告「每天都在出故障、但照样信任」的人群，正在告诉你一件关于「智能体带来的工作眼下是如何被吸收掉的」的真事——那也正是从一份以采用率为头条的报告里值得带走的那项发现。

唯一值得你为自己团队偷走的数字，报告里根本没有。取一周的运行，数一数其中有多大比例是以「有人介入」告终的，然后按任务类别拆开。如果答案接近 41%，你现在知道该修哪两三类了——而且不像信任分数，这个数字会随着你把它们修好而移动。

延伸阅读

本站相关：

• 自主级别——把信任当成一道逐动作的阶梯，而不是一个标量。
• 幂等与重试——为什么恢复后的运行会重复副作用，除非你把「恰好一次」造出来。
• 人工复核的成本——那条不会随模型变好而缩水的账目。
• 后台编码智能体——吞吐上升，撞进一个持平的复核队列。
• 生产反馈信号——把「介入」变成数据。
• Temporal、Restate、Inngest 与 DBOS——报告框架背后那些持久化执行引擎究竟修好了什么。

来源：

• Temporal——《2026 开发现状报告》——554 名受访者，调查期为 2026 年 4 月 29 日至 5 月 25 日。