伯克利2025智能体深度调研报告，揭秘AI智能体在真实生产环境中生存状态

加州大学伯克利分校（UC Berkeley）、斯坦福大学（Stanford University）等机构的研究团队联合进行了一项大规模研究。

发布了一份关于AI智能体在真实生产环境中生存状态的深度调查报告。

他们调研了306位在一线构建智能体的从业者，并对20个已经成功部署或处于试点阶段的团队进行了深度访谈。

这些案例覆盖了金融、医疗、软件开发等26个领域，用户规模从数百人到百万人不等。

这项研究并未停留在理论层面，而是直接切入代码和架构的细节。

通过这份报告，我们得以窥见那些真正活下来的智能体是如何被构建、评估和维护的。

效率提升是企业部署智能体系统的核心驱动力，而为了在生产环境中确保可靠性，开发者往往选择限制智能体的自主权并保留大量人工介入。

过去一年，大语言模型催生了AI智能体这一全新软件形态。

从药物发现到自动编程，从全自动AI科学家到各行业的垂直应用，智能体的潜力被无限放大。

但在光鲜亮丽的演示视频和高达95%的项目失败率之间，行业缺乏对成功落地的系统性认知。

智能体落地的核心动力

企业决定引入智能体并非为了追逐技术潮流，而是出于极其务实的考量。

在所有已部署智能体的受访者中，有73%的人表示，核心动机是提高任务完成速度和效率。

大多数团队的目标非常明确：减少手动任务的时间，降低人力成本。

相比之下，那些听起来更高大上的理由，如提高运营稳定性、降低风险或加速故障恢复，反而排在末位。

这种优先级排序反映了残酷的生产现实。

计算生产力的提升是容易的，只需对比引入智能体前后的人工工时即可。

而要验证智能体是否降低了业务风险，则需要漫长的周期和复杂的数据支持。

因此，绝大多数落地的智能体都在干着脏活累活，旨在解决专家资源昂贵或人手不足的问题。

智能体的应用领域早已超越了单纯的代码辅助。

金融与银行（Finance & Banking）、技术（Technology）和企业服务（Corporate Services）是部署最密集的三个领域。从保险索赔处理到人力资源咨询，智能体正在渗透进各行各业的毛细血管中。

在这个过程中，一个有趣的现象是：落地的智能体主要服务于人类，而非其他机器系统。

数据显示，92.5%的已部署系统直接面向人类用户，其中内部员工占比超过一半（52.2%）。这种内部消化的策略是一种风险控制手段。

在企业内部环境中，即使智能体犯了错，后果往往也更可控，且更容易获得人类专家的纠正。

关于响应速度，现实也比预想的宽容。

虽然我们习惯了即时通讯的秒回，但在生产环境中，66%的系统允许分钟级甚至更长的响应时间。

原因很简单：如果一个智能体需要5分钟来完成一项原本需要人类花费两小时的任务，那么这5分钟的等待就是完全可以接受的。

除了语音交互等实时性极强的场景外，大多数企业应用并不追求毫秒级的极致响应。

我们可以清晰地看到，那些不需要实时互动的后台任务，为智能体的推理和工具调用留出了宝贵的时间窗口。

简单直接是工程落地的首选

在学术界，研究者热衷于探索复杂的训练方法和自我进化的架构。

但在生产一线，简单、可控、可维护才是王道。

调研发现，工程团队普遍倾向于使用成熟的、简单的技术手段，而非那些带有随机性或需要大量训练的复杂技术。

关于模型选择，闭源模型占据了绝对统治地位。

在20个深度案例研究中，有17个团队依赖Anthropic的Claude系列或OpenAI的GPT系列等前沿闭源模型。

仅有3个案例使用了开源模型，且通常是出于极其严格的成本控制或数据隐私法规限制。

工程团队的逻辑非常直接：对于大多数应用场景，尤其是辅助专家工作的场景，模型推理的成本相对于人力成本几乎可以忽略不计。

因此，他们会毫不犹豫地选择能力最强、智商最高的模型，以确保任务完成的质量。

更令人惊讶的是，微调（Fine-tuning）在生产环境中并不流行。

70%的深度访谈案例完全没有对模型权重进行任何调整，而是直接使用预训练模型。

即使是那些使用了微调的团队，也往往只是针对特定客户或特定子任务进行小范围应用，且通常与通用大模型配合使用。

开发者普遍认为，现有的前沿模型能力已经足够强大，通过提示工程（Prompt Engineering）就能满足大部分需求。

相比之下，微调不仅成本高昂，而且维护困难——每当基础模型升级，微调的工作就可能付诸东流。

在提示词的构建上，人工手写依然是主流。

79%的已部署智能体严重依赖人工构建提示词，或者由人工起草后再用大模型进行润色。

自动化提示优化技术（如DSPy）虽然在研究中很火，但在实际部署中仅有极少数人在尝试。

开发者更相信自己写出的、逻辑清晰的指令，因为这对他们来说是白盒，出了问题容易调试。

随着系统成熟度的提高，提示词的长度也在惊人地增长。

虽然半数系统的提示词在500 token以内，但也有一条长长的尾巴——约12%的生产环境提示词超过了10,000 token。

这些超长提示词往往包含了复杂的业务规则、边缘案例处理逻辑和详细的输出格式要求。

在智能体的控制流设计上，大多数生产系统选择了带着镣铐跳舞。

为了保证可靠性，68%的智能体在需要人工干预前，最多只执行10个步骤。

47%的系统甚至在5步以内就会停下来。这种对自主性的限制是刻意的，旨在防止智能体陷入死循环或产生幻觉。

我们可以看到，生产环境倾向于短步骤、少模型调用。这与实验环境中的智能体形成了鲜明对比，后者往往被赋予了无限的探索空间。

在真实世界里，不可预测的自主性被视为一种Bug，而不是Feature。

在开发框架的选择上，出现了一个有趣的背离。

虽然问卷显示60%的受访者使用了LangChain等第三方框架，但在20个深度访谈的成功落地案例中，85%的团队选择了自研架构，完全不依赖外部框架。

对于真正将系统推向生产的团队来说，控制力至关重要。

第三方框架往往带来了过多的抽象层和不必要的依赖，导致调试困难。

相比之下，直接调用模型API并编写精简的逻辑代码，不仅更灵活，也更符合企业对安全和合规的要求。

评估回归人工校验

评估是智能体落地的最大拦路虎。

在传统软件工程中，我们有单元测试和确定的输入输出。

但在智能体领域，面对开放域的问题，如何判断一个回答是好的，变得异常困难。

令人意外的是，61.3%的受访者表示，他们的智能体并没有与非智能体的基线系统进行过严格对比。

很多时候，智能体解决的是全新的问题，或者原有流程过于复杂（混合了人工、文档、旧软件），根本无法进行公平的技术对标。

更棘手的是基准测试集（Benchmark）的缺失。

生产任务通常具有高度的领域特异性，公共榜单上的分数对业务毫无意义。

因此，25%的团队选择从零开始构建自己的基准测试集，但这需要耗费大量专家资源。

剩下的75%的团队甚至放弃了构建正式的测试集，直接依靠A/B测试或用户反馈来迭代系统。

在这种情况下，人工校验（Human-in-the-loop）成为了最后的防线。

74.2%的已部署系统主要依赖人工评估。无论是开发阶段的离线测试，还是上线后的在线监控，人类专家的判断依然是金标准。

模型评估模型（LLM-as-a-judge）作为一种自动化手段，虽然被51.6%的团队采用，但它从未独立存在。

所有接受访谈的团队都表示，他们会用大模型来做初步筛选或评分，但最终的决定权或抽检工作必须由人来完成。

这是一种人机共治的评估模式：模型负责处理大规模数据，人类负责校准模型的标准。

可靠性的工程解法

尽管面临诸多挑战，智能体依然在各行各业落地生根。

这背后的秘密在于：从业者不再追求构建全知全能的通用智能体，而是通过严格的约束来换取系统的可靠性。

可靠性是所有开发者的头号心病。

在问卷中，核心技术挑战（包括可靠性、鲁棒性、扩展性）被列为首要难题，远超合规性或治理问题。

为了解决这一问题，开发者们在环境和行为上给智能体套上了双重枷锁。

在环境方面，许多智能体被限制在只读模式下运行。

它们可以分析数据、生成报告、提出建议，但绝不允许直接修改生产环境的数据。

例如，一个运维智能体可以诊断故障并生成修复代码，但执行这段代码的必须是人类工程师。

还有一些团队利用沙盒环境，让智能体在隔离的系统中自由发挥，经过验证确信无误后，再将结果同步到生产环境。

在行为方面，严格限制自主步骤数和模型调用次数是通用做法。

虽然只有14.8%的团队认为延迟是阻碍部署的致命问题，但大部分团队还是通过限制步数来间接控制延迟和成本。

这种有限自主的设计哲学，使得智能体在当前的技术水平下就能产生巨大的商业价值。

通过将复杂的任务拆解为标准化的工作流，并配以严格的护栏，企业成功地将大模型的能力转化为生产力。

89.7%的系统需要访问数据库，69%涉及敏感数据。

因此，尽管从业者将功能实现放在首位，但数据隐私和安全始终是底线。

通过法律协议限制模型提供商使用数据训练，以及在架构上进行物理隔离，是目前最常见的应对措施。

当前，智能体工程正在从早期的野蛮生长走向规范化。

从业者们不再迷信模型的神奇能力，而是通过扎实的工程手段——限制范围、增加校验、人工兜底——来弥补模型本身的不足。

虽然目前的智能体主要处理文本，但对图像、视频等非文本模态的支持正在被提上日程。

一旦现有的文本智能体在可靠性上站稳脚跟，更丰富、更多维的智能体应用将接踵而至。

生产环境中的智能体并非无所不能的科幻产物，它们是受限的、专注的、甚至有时显得笨拙的数字化劳动力。

但正是这些戴着镣铐起舞的智能体，正在实实在在地改变着我们的工作方式。

对于研究者而言：与其追求在基准测试上刷分，不如关注如何提高智能体的可验证性、如何设计更好的容错机制、以及如何在保证可靠性的前提下逐步释放其自主性。

对于从业者而言：那些简单甚至原始的方法并非落后，恰恰是当前通往成功的最佳路径。

参考资料：

https://arxiv.org/pdf/2512.04123v1

END