20个企业级案例揭示Agent落地真相：闭源模型吃掉85%，手搓代码替代LangChain
加州大学伯克利分校（UC Berkeley）刚刚发布了一份重磅论文：《Measuring Agents in Production》。
（论文地址：https://arxiv.org/pdf/2512.04123）
这份论文，基于来自全球的真实请求：306名从业者深度调研，20个企业级部署案例，覆盖 26 个行业。
这是AI Agent 领域，迄今最大规模的实证研究。
最核心的三个信息：
- 生产力提升是Agent 落地的第一推动力；
- 闭源模型、人工Prompt 和受控流程是当前的“通行公式”；
- 可靠性是最大的拦路虎，人工审核依然不可或缺；
这份报告信息非常多，容我慢慢道来。
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，就能通过实际将现有技术确定明确的、提升范围可控的业务问题，就能够获得显著的生产力。
本文来自微信公众号“硅基观察Pro”，作者：林白，36氪经授权发布。
