加州大学伯克利分校重磅研究：AI Agent生产环境度量实证分析

加州大学伯克利分校（UC Berkeley）最新发布了一篇具有深远影响的论文：《Measuring Agents in Production》。

（论文地址：https://arxiv.org/pdf/2512.04123）

该研究基于全球范围内的真实数据：对306位从业者进行了深入调研，分析了20个企业级部署案例，涉及26个不同行业。 

这标志着AI Agent领域迄今为止规模最大的实证研究。 

研究揭示了三大核心发现： 

• 提升生产效率成为企业部署Agent的首要驱动力；
• 闭源模型、人工提示工程与受控流程构成当前主流实践范式；
• 可靠性问题依然是主要障碍，人工审核环节不可或缺；

这份报告信息量巨大，接下来我们将详细解读。 

73%为效率买单，金融行业成Agent应用主战场

先看一组关键数据：

73%的受访者表示，部署Agent的核心目标是“提升生产效率”。 

其他动机同样务实：63.6%希望减少人工工时，50%寻求自动化常规劳动。 

相比之下，那些难以量化的质性收益，如“风险规避”(12.1%)和“加速故障响应”(18.2%)，排名相对靠后。 

这表明，Agent的落地优先选择能带来直接、可量化回报的场景，而价值难以估量的质性改进暂时被置于次要位置。 

从应用领域来看，Agent早已超越代码生成或聊天机器人，深入至更严肃的商业流程。 

其中，金融与银行业占比最高，达到39.1%，其次是科技（24.6%）和企业服务（23.2%）。 

除此之外，Agent还在一些意想不到的领域落地： 

保险理赔流程自动化：代理人负责处理从保单查询到风险识别的序列化流程。 

生物医学工作流自动化：在科学发现领域，Agent用于自动化执行复杂的实验和数据分析流程。 

企业内部运营支持：涵盖人力资源信息搜索、站点故障事件诊断等多个方面。 

这些跨行业的成功案例证明，AI Agent已具备解决真实世界复杂问题的能力，并正在创造切实的商业价值。 

在实际业务场景中，Agent目前的角色更像是人类的“超级实习生”。 

92.5%的Agent直接服务于人类用户，其中52.2%服务于企业内部员工。 

为何大部分是内部员工在使用？因为在组织内部，错误后果可控，且有人实时监督。只有7.5%的Agent服务于其他软件系统，Agent之间的全自动交互仍遥不可及。 

与许多人的想象不同，Agent的响应速度并非客户最优先考虑的因素。在生产环境中，66%的系统允许分钟级甚至更长的响应时间。 

原因在于：相较于人类完成任务所需的数小时或数天，Agent花费几分钟仍是巨大的效率提升。这意味着开发团队可将重心放在提升输出质量和可靠性上，而非牺牲能力去追求极限低延迟。 

生产级Agent的“极简主义”：拒绝微调，死磕Prompt

与学术界对复杂自主Agent的探索形成对比，生产级AI Agent的构建哲学是“大道至简”。

从业者优先选择简单、可控、可维护的技术路径，以最大化系统的可靠性。这种务实的工程选择贯穿于模型选型、技术实现、核心架构和框架使用的方方面面。 

在模型选择上，闭源是绝对主流。 

在20个深度案例中，85%（17个）使用了闭源模型，Anthropic的Claude系列和OpenAI的GPT系列是首选。 

选择闭源的核心逻辑是效率。对于辅助专家（如医生、高级工程师）的Agent而言，推理成本相比人力成本几乎可忽略不计，因此团队倾向于选择最强的模型。 

开源模型更多被视为特定场景下的补充。只有在满足严格约束条件时，团队才会选择开源模型，通常有两种情况： 

成本效益：对于需要大规模、高推理的场景，自托管开源模型的成本优势凸显。 

数据隐私：受法规或企业政策限制，当敏感数据无法突破外接环境时，开源模型成为唯一选择。 

与模型选择一样，从业者在技术路径上也倾向于更简单、迭代更快的方法：拒绝微调，死磕Prompt。 

学术界热衷的微调（Fine-tuning）和强化学习（RL），在实际应用场景中极少使用。其中70%的案例直接使用现成模型，完全不进行权重微调。 

大家的精力都花在哪了？花在写Prompt上。 

78%的系统采用全手动或手动+AI辅助的方式构建Prompt。生产环境中的Prompt可能非常长，12%的Prompt超过10,000个Token。 

这也说明，从业者更相信自己手写的规则，而非自动优化工具（如DSPy）。 

为了降低Agent的不可控性，生产级Agent的自主性被严格限制在可控范围内。 

68%的系统在需要人工干预前，执行步骤不超过10步，甚至有47%的系统少于5步。 

为何要限制？主要有三个原因： 

保证可靠性：步数越多，错误越容易累积； 

控制成本：API调用并非免费； 

控制延迟：每多一步，用户就得多等一会； 

因此，80%的案例采用了预定义的静态工作流。例如，一个保险Agent的流程是固定的：查询保障 -> 审查必要性 -> 识别风险。Agent只能在已有流程内做决定，不能自己发明新步骤。 

另一个有趣的现象是，在问卷调查中，60%的人表示愿意用第三方框架（如LangChain），但在实际案例中，85%的团队选择完全自研，直接调用模型API。 

为什么？为了减少依赖臃肿（dependency bloat），为了获得对系统的完全控制权。 

这种对定制化解决方案的强烈偏好揭示了企业级Agent系统的一个关键成熟度指标：从通用框架向深度集成、定制编排引擎演进，使得这些系统正成为关键任务基础，需要现有工具无法提供的控制水平。 

学术榜单“失灵”，75%的团队放弃基准测试

基准测试几乎没有任何参考价值。

其中，75%的团队完全不使用基准测试。因为每个企业的业务都太特殊了，公开的学术榜单毫无参考价值。 

剩下25%的团队，选择从零开始构建自己的自定义基准。 

在这种情况下，人工循环验证（Human-in-the-loop）是主导的评估方法，被74.2%的从业者采用。 

在开发阶段，领域专家直接审查和验证系统输出的正确性、安全性和可靠性。例如，医疗专家逐一验证医疗保健代理生成的诊断建议是否符合临床标准。 

在运行阶段，人类作为最终决策者，基于Agent提供的建议和分析采取行动，充当最后一个安全护栏。例如，站点修复工程师根据代理生成的故障分析报告，最终决定执行哪些修复操作。 

还有另一种评估方法：自动化评估（LLM-as-a-Judge）。其典型工作流程如下： 

1. Agent生成一个输出。 

2. 一个“裁判”LLM对输出进行评估，并给出一个置信度分数。 

3. 高分输出被自动接受，低分输出则被路由给人类专家进行审查。 

4. 同时，专家会定期抽查那些被自动接受的高分输出，以监控“裁判”LLM的表现，形成一个人类持续介入的闭环反馈。 

虽然这种方法也有不少人使用，但没人敢完全信任它。 

51.6%的团队使用了LLM当裁判，但所有这些团队都结合了人工验证。一个典型的做法是：LLM给个分，高分的自动通过，低分的转人工；同时人工还会定期抽查高分样本。 

核心挑战：可靠性，可靠性，还是可靠性

可靠性是头号大敌：37.9%的人把“核心技术问题”（可靠性、鲁棒性）列为头号挑战，远超合规性（17.2%）和治理问题（3.4%）。

为什么这么难？ 

基准难建：数据稀缺、成本高昂、高度定制化； 

测试难做：Agent的非确定性让传统的单元测试失效； 

反馈太慢：很多时候，你不知道Agent错了，结果直到几个月后才显现； 

与可靠性相比，安全与合规性问题被认为是次要问题。原因是，它们通常可以通过“约束设计”解决。常见的“约束设计”有以下四种： 

1.复杂修改操作：严格限制Agent只能读取数据，不允许其修改生产环境的状态。例如，一个站点可靠性（SRE）Agent可以分析日志并生成报告，但最终的修复操作必须由人类工程师执行。 

2.沙盒环境：将Agent部署在与生产系统隔离的沙盒环境中。Agent在沙盒内生成并测试代码或配置变更，只有在通过所有验证后，结果才会被同步到生产系统。 

3.限制抽象层：在Agent和生产工具之间构建一个API封装层。这个抽象层只公开必要的功能，并隐藏内部实现细节，限制了Agent的潜在破坏范围。 

4.控制：尝试让Agent继承发起请求的用户的访问权限。然而，实践表明这仍是一个挑战，因为Agent在调用工具时可能会绕过或遇到与用户权限不一致的细粒度控制。 

总结：约束性部署的胜利

这份报告揭示了一个核心悖论： 

可靠性明明是最大挑战，为什么这些系统还能上线？ 

答案是：“约束性部署”（Constrained Deployment）。实现“约束性部署”的具体模式包括： 

环境约束：将Agent部署于复杂模式、内部网络或与生产隔离的沙盒环境中，从源头上杜绝了Agent对关键系统的直接破坏风险。 

自主性约束：将Agent的行为限定在少于10个步骤的构成、预定义工作流程内，避免了因长期自主探索而导致的不可预测行为和错误累积。 

人工监督：将专家安置在决策回路的关键节点，使其成为代理输出的最终验证者和执行者，构成了最后一个、也是人类最加固的一道安全防线。 

另一个重要的启示是，仅利用现有的前沿大模型和相对简单的提示工程技术，就足以在超过26个不同行业中创造出可观的、可量化的商业价值。 

这意味着，企业无需等待AGI，就能通过将现有技术应用于明确、范围可控的业务问题，获得显著的生产力提升。