Agent2025年终报告来了，UC伯克利、斯坦福和IBM联合发布

2025就要过去了。UC Berkeley、Stanford和IBM联手做了一件大事。他们调研了306份在一线“造 Agent”的从业者问卷，并深度访谈了20个已经成功落地并产生价值的一线企业案例（涵盖金融、科技、医疗等领域）。试图回答一个最朴素的工程问题：一个能用的、赚钱的Agent，到底是用什么架构搭出来的？

这篇名为 《Measuring Agents in Production》 的论文，是一份来自学术+工业界的“诚实报告”。它可能会打破您对Agent的很多幻想，但能给您指一条真正通往落地的路。

我们为什么需要Agent？

企业费尽周折开发Agent，到底图什么？

1.核心驱动力：简单粗暴的“生产力”

数据非常直观。在那些已经将Agent上线的团队中，72.7%的人表示，首要动机是“提高生产力”（Increasing Productivity）。紧随其后的是“减少人工工时”（63.6%）和“自动化常规劳动”（50.0%）。

相比之下，那些听起来很高级的理由，比如“风险缓解”（12.1%）或“快速故障响应”（18.2%），并不是企业采用Agent的主要动力。

现实是：企业引入Agent，主要是为了帮人干脏活、累活，或者是解决人手不足的问题。

2.它们在哪里工作？（各行各业）

您可能认为Agent主要是在帮程序员写代码，但调查结果让人意外。虽然“技术”领域确实占了一席之地（24.6%），但占比最高的是“金融与银行业” (39.1%)。

Agent的身影已经遍布了26个不同的领域，包括：

• 企业服务 (23.2%)：比如HR助手、法务合规。
• 数据分析 (13.0%)。
• 医疗服务 (8.7%)：比如帮护士审核保险单。

3.用户是谁？（人机协同是主流）

这一点非常关键。92.5%的生产级Agent是直接服务于人类用户的，而不是服务于其他机器或软件系统。

(a) 用户类型：92.5% 的 Agent 服务于人类用户（内部员工+外部客户），只有极少数服务于其他软件。(b) 延迟容忍度：绝大多数系统允许“分钟级” (41.5%) 的响应时间，只有7.5%要求亚秒级响应。

• 内部员工 (52.2%)：这是最大的用户群。企业更倾向于先在内部部署Agent，因为这样“容错率”更高，即使出错了，也有员工在旁边盯着。
• 外部客户 (40.3%)：直接面向C端用户的也有，但比例略低。

这也解释了为什么Agent能落地：它们并不是完全替代人，而是作为“工具”增强人的能力。人类用户本身就是最后一道防线。

成功的Agent是怎么做出来的？

这是论文最硬核、也最颠覆认知的部分。学术界推崇的“全自动、自我进化、复杂规划”在工业界几乎没人用。

工业界的信条是：简单、可控、有效。

1. 模型选择：这笔经济账怎么算？

尽管开源社区非常活跃，但在真正的生产环境中，企业做出了非常现实的选择。

左图：17个案例使用闭源模型（No Open Source），只有3个用开源。右图：14个案例没有进行后训练（Post-training/Fine-tuning），直接用现成模型。

• 闭源模型主导：在20个深度案例中，17个团队使用的是闭源的“前沿模型”（Frontier Models），如GPT-4或Claude 3.5 Sonnet系列。
• 为什么“贵”的模型反而是最经济的？ 这里有一个常被忽视的经济学逻辑。许多团队明确表示，尽管前沿模型的API调用成本比开源模型高，但与它们所辅助的人类专家（如资深工程师、医疗专业人员）的时间成本相比，这点API费用几乎可以忽略不计。
• 如果一个Agent能帮医生节省10分钟，哪怕API调用花了几美金，ROI（投资回报率）也是极高的。因此，企业在选型时，“能力上限”的权重远高于“推理成本”。
• 因此，除非有极端的成本压力（如高频次大规模调用）或监管要求，否则大家都会默认选择能力最强的模型。

2. 拒绝“微调”，拥抱“提示词”

这可能违背了很多人的直觉。我们常以为要把Agent做好，必须得用私有数据去微调（Fine-tuning）模型。但事实是：

• 70% 的生产级Agent完全没有进行微调。它们直接使用现成的模型（Off-the-shelf）。
• 原因很简单：微调不仅贵，而且很难维护。一旦基座模型升级（比如从GPT-4到GPT-4o），微调过的模型可能就废了，必须重新训练。相比之下，现成模型的能力已经足够覆盖大部分需求。

那么，怎么让模型听话呢？靠Prompt Engineering（提示工程）。

• 人工手写：79%的团队主要靠人手写Prompt，或者人写完后再用AI润色一下。自动化优化工具的使用率极低（仅5% 的案例尝试过）。
• 超长Prompt：工业界的Prompt非常复杂。虽然半数Prompt在500 token以内，但有12.1%的Prompt长度超过了10,000 token。这意味着开发者在Prompt里塞入了大量的规则、示例和上下文。

3.架构：朴素的“推理时扩展”与写死的流程

在学术论文里，Agent通常是“这就给你解决问题”，然后自己去思考步骤。但在公司里，Agent是被“管”得死死的。

Agent核心组件配置：(a) 模型数量：大多数Agent只用1-2个模型。(b) Prompt 长度：存在一个“长尾”，有12%的Prompt超过了1万个token。(c) 自主步骤：46.7%的Agent只能自主执行1-4步。这张图是论文核心观点“Reliability Through Constrained Deployment”（通过受限部署实现可靠性）的最有力数据支撑，Agent不是无限思考的，而是被限制在很短的步骤内。

• 朴素的推理时扩展 (Inference-time Scaling)： 虽然大家都听过OpenAI o1这种通过复杂搜索（Search）来提升推理能力的模型，但工业界目前的做法要“朴素”得多。
• 31%的生产级Agent已经使用了推理时扩展技术。
• 但它们用的不是复杂的蒙特卡洛树搜索（MCTS），而是更简单的策略，比如“路由” (Routing)：把简单的任务分给小模型，难的任务分给大模型；或者是“多模型投票”：让几个模型一起跑，然后选最好的结果。
• 步骤限制：68%的Agent在需要人类介入之前，执行的步骤不超过10步。

• 流程写死：80%的案例使用了结构化的控制流。业界偏爱定义好的工作流 (Workflows)，而不是让Agent自己去漫无目的地“思考和规划”。这也解释了为什么它们能上线，因为行为可预测。
• 例子：一个处理保险索赔的Agent，它的流程是被钉死的：第一步查保额，第二步看医疗必要性，第三步查风险。它不能自己决定“跳过第一步”。

4.开发框架：LangChain真的好用吗？

这是一个非常有趣的“罗生门”现象。

• 问卷数据：在所有受访者中，60.7% 的人使用了第三方框架（如LangChain, LangGraph, CrewAI）。
• 深度访谈（成功上线的系统）：在20个真正跑通了业务流程的团队中，85%（17个团队）选择自研架构，完全不使用第三方框架。

为什么高手都不用框架？原因： 框架太重、抽象层太厚，难以调试，比如Langchain的源代码就有一万多行。为了控制力和稳定性，工程师宁愿自己写简单的循环代码。

何况LLM框架本质上就是一个简单的有向图，这一观点出自Pocket Flow的作者Zachary Huang博士，感兴趣您可以看下：

真的好用吗？如何评估Agent？

软件工程里我们有单元测试，但在Agent开发中，评估（Evaluation）是一个巨大的痛点。

(a) 基线对比：61.3% 的团队没有进行基线对比。(b) 评估方法：74.2%依靠人工（Human-in-the-loop），51.6%使用 LLM-as-a-judge。(c) 共现矩阵：显示了不同评估方法的重叠，人工评估是连接所有方法的中心。

如果不知道 Agent 对不对，怎么敢上线？

1. 没有任何公开基准能用

• 现实： 你的业务是独特的（比如“某公司内部代码迁移”），市面上的 MMLU或HumanEval测试集对此毫无意义。
• 对策： 75%的团队没有任何正式的基准测试集 (Benchmarks)，直接靠 A/B 测试或用户反馈。剩下的25%团队被迫花费数月时间，自己一条一条地构建“黄金数据集”。

2. “LLM-as-a-judge” 的真实用法

• 混合模式： 虽然52%的团队使用大模型来评估大模型（LLM-as-a-judge），但在访谈中发现，没有一个团队敢只用AI评估。
• 黄金组合： 生产环境的标准动作是：AI 裁判对所有输出打分 + 人类专家对高置信度结果进行抽检 (Sampling)。AI是用来过滤显而易见的错误的，最终的质量把关必须是人。

最大的挑战：还是可靠性

当问到“开发Agent最难的是什么”时，“可靠性” (Reliability)毫无悬念地排在第一位。

1. 难以捉摸的“正确性”

传统的软件，Bug是可复现的。Agent的Bug是随机的。

• 验证困难：对于代码生成的Agent，还可以跑一下代码看报不报错。但对于医疗、保险Agent，你很难快速知道它生成的建议是不是“有毒”。这种反馈往往滞后很久（比如病人出问题了、公司赔钱了）。

2. 延迟 (Latency) 其实没那么重要

这可能是另一个反直觉的发现。

• 只有14.8%的受访者认为“响应慢”是阻碍上线的关键问题。
• 60%的系统允许分钟级甚至更长的响应时间。
• 为什么？因为它们替代的是人类工作流。比如一个任务，人类做需要2小时，Agent跑5分钟虽然比传统软件慢，但比人快了20倍，用户完全可以接受。

3.安全性

我们常认为安全就是“把Agent关在沙盒里”。但这远远不够，因为Agent必须接触企业的核心数据。

• 数据暴露风险：调查显示，89.7%的生产级Agent需要访问内部数据库，69%需要处理保密或敏感数据。
• 如果技术防不住，就靠法律：虽然有些团队尝试用“基于角色的访问控制”（RBAC）来限制Agent，但经常发现Agent会绕过这些限制。
• 最终防线：因此，很多企业依赖法律和合同手段来兜底。比如，与模型提供商签署严格的协议，保证企业数据不被用于模型训练，从而在法务层面规避风险。

未来展望：不只是聊天

虽然目前的Agent大多是“聊天机器人”的形态，但论文中的数据预示了未来的进化方向。

• 现状：文本为主。目前93%的Agent处理的是自然语言文本。
• 未来：多模态爆发。企业对非文本模态的需求正在激增。例如，对视频处理的支持计划从目前的6.9% 激增至30.4%，对图像的支持计划从37.9%增加到47.8%。
• 未来的Agent将不再只是“读写”文字，它们将拥有“眼睛”和“耳朵”，能处理视频流、复杂的科学数据和时空数据，成为真正的全能助手。

总结与启示

读完这篇论文，我们可以勾勒出当前工业界AI Agent的真实画像：

它们不是科幻电影里全知全能的超级AI，而是被工程师们用无数规则、人工审核、特定流程以及法律合同“精心包裹”起来的实用工具。

研究者将这种模式总结为：“通过受限部署实现可靠性” (Reliability Through Constrained Deployment)。

如果您正准备开发Agent，这篇论文给了您几条非常务实的建议：

AI Agent的时代确实已经到来，但它不是以“魔法”的形式，而是以“工程”的形式，一步一个脚印地走进我们的生产环境。

1. 提示工程：先用最好的闭源模型API（GPT-4/Claude 3.5）国内的（Qwen3/DeepSeekV3.2）把流程跑通。如果Prompt搞不定，大概率微调也救不了。
2. 写死流程：不要指望Agent自己规划出一条完美的路径。把业务逻辑拆解成确定的步骤（SOP），让Agent在每一步里发挥作用。
3. 一定要让人介入：不要追求100%自动化。把Agent当作副驾驶，让人类专家做最后的“把关人”。
4. 容忍它的慢：只要它比人快，且结果准确，分钟级的延迟完全不是问题。

文章来自于“AI修猫Prompt”，作者 “AI修猫Prompt”。