生产环境中的智能体评估 | Measuring Agents in Production

1. 引言

大语言模型（LLM）催生了一类新的软件系统：AI 智能体。我们将 AI 智能体定义为结合基础模型与可选工具、记忆和推理能力的系统，用于自主执行多步骤任务。近期研究展示了 AI 智能体在从药物发现、算法创新到通用 AI 科学家等领域的令人兴奋的潜力。这种兴奋不仅限于研究原型，还延伸到生产系统。企业报告智能体正活跃运行在远超最初编程焦点的多个领域，包括金融、保险和教育。

图 1. 从业者构建和部署 AI 智能体的原因（N=66）：相比之前的非智能体系统（人工或非 LLM 自动化），提高任务完成速度（提升生产力）被最常选择（73%），而改善运营稳定性（降低风险和加速故障恢复）被最少选择。

然而，尽管对智能体潜力充满广泛的热情，许多人质疑其在生产中的真正价值和成功：智能体能否兑现承诺，其未来在哪里。例如，一项近期研究报告称 95% 的智能体部署失败。智能体的承诺与其高失败率之间的鲜明对比引发了关于什么区分成功部署和失败部署的根本问题。

遗憾的是，关于生产环境智能体如何构建的公开信息很少。为什么有些智能体成功而其他的失败？智能体必须满足什么要求才能进行生产部署？我们缺乏对什么方法能够在现实世界中实现成功智能体的系统性理解。研究人员对现实世界的约束和实践几乎没有可见性。智能体失败是因为模型能力不足，还是存在其他因素？如果不了解智能体在生产中的实际工作方式，研究人员可能会解决错误的问题。与此同时，从业者缺乏关于如何构建可靠智能体的共识，他们将从了解行业如何处理这些快速发展的系统中受益。

为了填补这一知识空白，我们呈现了 生产环境中的智能体评估（MAP），这是首个关于生产环境 AI 智能体的大规模系统性研究。我们通过四个研究问题（RQ）研究成功现实世界系统背后的开发者和团队的实践：

我们通过 306 份回复的在线调查和 20 次与智能体开发团队的深度访谈来回答这些问题，捕捉生产环境智能体开发的技术细节。我们的调查受访者是在 26 个领域（从金融和医疗保健到法律）积极构建 AI 智能体的从业者（图 4a）。我们将调查数据筛选为 86 份明确报告系统处于生产或试点阶段的回复，我们将其称为 已部署智能体，用于正文中的结果。完整的 306 份回复数据集见附录 A。对于深度访谈，我们研究了来自构建拥有真实用户的已部署智能体团队的 20 个案例，涵盖从全球企业到初创公司的各种组织（图 3）。我们的案例研究和调查捕捉了服务于从数百到数百万日活用户的已部署智能体系统（图 4c），提供了对高影响力部署的可见性。这种双重方法提供了首个基于实证的视角，揭示了生产环境 AI 智能体背后的技术方法、架构模式和运营实践。

为了提供关于工作实践和现实世界约束的第一手数据，我们的研究聚焦于积极构建已部署到生产环境的智能体、服务用户并提供可衡量价值的从业者（图 1）。这自然偏向于成功的部署和有经验的从业者。我们的数据捕捉了当今有效的方法，提供了对该领域发展方式的洞察。

我们的研究揭示了每个研究问题的关键发现：

图 2. 从业者构建和部署智能体 AI 系统的应用领域（N=69）。部署横跨广泛的行业，其中金融、技术（包括但不限于软件开发）和企业服务领域的集中度最高。其他低频领域（"其他"）列于表 2，总计约 26 个不同领域。

我们的发现揭示，可靠性担忧驱使从业者走向具有高可控性的简单而有效的解决方案，包括受限环境、有限自主权和人工监督。例如，开发者选择人工在环评估而非完全自动化技术，选择手动提示工程而非自动化方法，因为这些方法提供控制力、透明度和可信赖性。从业者有意权衡额外的智能体能力以换取生产可靠性，这种设计模式已经使广泛的应用程序能够提供现实世界价值。

生产环境智能体代表一门新兴的工程学科。我们的研究记录了当前的实践状态，并弥合了研究与部署之间的差距：我们为研究人员提供了对现实世界约束和机遇的可见性，同时为从业者提供了来自各行业成功部署的经验证模式。

2. 相关工作

据我们所知，我们提供了关于生产环境运行的智能体如何构建的首个技术特征描述。

商业智能体调查

此前的几项研究从相邻角度检视了 AI（智能体）在生产中的采用情况。MIT 媒体实验室和 NANDA 倡议以及 Challapally 等人研究了试图整合智能体的公司的经济可行性和高管对投资回报的看法。Shome 等人分析了 102 个商业智能体的营销材料，并对 31 名参与者进行了用户研究，揭示了承诺能力与实现能力之间的差距。行业报告侧重于组织准备度和市场趋势。LangChain 对超过 1,300 名专业人士进行了关于智能体动机、特征和挑战的调查。

我们的工作在两个关键方面有所不同：(i)  范围：我们研究正在生产中活跃运行的智能体；(ii)  焦点：我们从从业者那里收集工程级别的技术数据。我们的研究补充了这些先前的工作，并提供了对成功智能体的新视角，提供了该领域发展方向的见解。

研究智能体文献综述

许多先前的工作从学术角度审视了 LLM 驱动的智能体，提供了有价值的智能体设计分类法并追踪了关键技术的演变。其他智能体综述侧重于特定方面：评估方法论、安全问题和多智能体系统。相比之下，我们的工作是一项实证研究，直接从构建和运营已部署智能体的从业者那里收集原始数据。我们不通过文献综述综合已发表的研究；相反，我们进行原始调查数据收集和深度案例研究访谈来记录生产实践。

单系统研究

企业发布关于智能体系统的论文和技术博客，并开源智能体实现，提供了对生产相关智能体的一瞥。每篇论文自然侧重于单一系统或领域，造成信息空白：我们缺乏对跨部署的共同模式、共享挑战和设计原则的理解。我们通过调查不同行业的专业人士来解决这一空白，以识别反复出现的工程实践、架构决策和挑战。

3. 研究方法

为了理解生产环境 AI 智能体是如何构建和部署的，我们进行了两项互补研究：一项大规模公开调查和 20 项深度案例研究访谈。我们在第 3.1 节详细介绍调查设计和分发，在第 3.2 节描述访谈协议和案例研究选择，在第 3.3 节概述数据处理流程。

3.1 公开在线调查

我们设计并进行了一项针对构建 AI 智能体的从业者的调查，重点关注其系统的技术细节。调查涵盖系统架构、评估、部署和运营挑战，共 47 个问题。为了按从业者理解的方式捕捉 AI 智能体，我们邀请受访者描述他们称之为 AI 智能体或智能体 AI 的系统，而不强加规定性定义。

为确保相关性，我们在 Qualtrics 中实施了带有动态分支逻辑的调查，其中某些问题仅根据先前回答显示。例如，关于使用智能体的已实现收益的问题仅向确认选择智能体而非非智能体解决方案的受访者显示。这种自适应结构，加上所有问题的可选性质，意味着每个问题收到不同数量的回复。我们在第 4-7 节的图表说明中报告了每个结果的具体样本量（N）。我们要求参与者在贡献多个智能体系统时将回复集中在单一系统上。完整的问卷详情见附录 E，包括图 26 和图 27 中的分支逻辑。

我们通过多个渠道分发调查，以覆盖 AI 智能体生态系统中的从业者：伯克利 RDI 智能体 AI 峰会、AI 联盟生产智能体聚会、UC 伯克利 Sky 静修会，以及包括 LinkedIn、Discord 和 X 在内的专业网络。我们于 2025 年 7 月 28 日发布调查，本文的数据收集截止于 2025 年 10 月 29 日。

我们收到了 306 份有效回复。294 名参与者表示他们直接参与了至少一个智能体系统的构建和设计。我们的调查受访者主要是软件和机器学习工程师等技术专业人员。在报告其系统部署阶段的 111 名受访者中，82% 表示其系统处于生产或试点阶段，表明从实验原型到现实世界部署的快速转变。

图 4(a). 调查参与者按主要贡献领域划分的角色（N=108）。

图 4(b). 调查参与者所贡献的智能体 AI 系统的部署阶段（N=111）。

图 4(c). 调查参与者所贡献的智能体系统的最终用户数量（N=35）。

图 3. 深度访谈案例研究中来源机构成熟度的分布。少数（5/20）来自种子期初创公司（验证产品市场契合度）、早期初创公司（证明可扩展商业模式）和成长期初创公司（快速扩大市场份额和运营）。大多数（15/20）来自后期和成熟机构（具有稳固的市场地位）。

为保持对生产系统的关注，我们将数据筛选为 86 份明确报告其系统处于生产或试点阶段的回复。生产系统是完全部署并由目标最终用户在实时运营环境中使用的系统，而试点系统是部署到受控用户群组进行评估、分阶段推出或安全测试的系统。此筛选排除了开发原型、研究产物和已退役系统，以及未报告其部署阶段的参与者。所有部署阶段的定义见附录 E.2 N5。我们将生产和试点系统称为已部署智能体。除非另有说明，本文中呈现的所有调查统计数据均指已部署智能体。所有部署阶段的 306 份有效回复的完整数据见附录 A。

3.2 深度案例研究

为了给调查发现增加定性深度，我们通过对来自不同组织构建已部署智能体的团队的访谈，进行了 20 项深度案例研究。

我们仔细选择了 20 个案例，以在应用多样性、组织成熟度和全球覆盖范围方面实现代表性样本。我们只访谈拥有真实用户的系统：14 个案例处于完全生产状态，6 个案例处于最终试点阶段。案例涵盖五个关键领域：业务运营（3 个案例）、软件开发和运营（7 个案例）、集成业务和软件运营（5 个案例）、科学发现（3 个案例）和通信服务（2 个案例）。值得注意的是，这些部署远远超出了众所周知的编程智能体或通用聊天机器人，展示了生产智能体应用的广度。系统同时针对内部员工（5 个案例）和外部企业消费者（15 个案例）。我们的选择包括从种子期初创公司到拥有全球足迹的大型企业的各种成熟度级别的组织（图 3）。对于拥有多个智能体部署的公司，我们仅呈现不同的用例以最大化应用多样性。匿名化的案例研究及其应用领域见表 1，更多详情见附录 D。

表 1. 20 个案例研究的应用概述及其领域。为保持清晰和保密，相似的用例被汇总为代表性描述。

每次访谈持续 30 到 90 分钟，由 2 到 5 名组织中立的访谈者团队进行。我们遵循涵盖 11 个主题领域的半结构化访谈协议，包括系统架构、评估机制、部署挑战、运营需求和可衡量的智能体价值。我们根据参与者偏好进行匿名化和录音，由人工记录员捕捉见解。为确保准确性，我们在所有访谈者之间交叉验证最终摘要。根据保密协议，我们匿名化所有数据并以汇总形式呈现发现。

3.3 数据处理

大多数调查问题使用结构化格式（单选、多选或数值），需要最少的后处理。对于图 2 中使用的自由文本领域关键词回复，我们使用 LOTUS（一种最先进的非结构化数据处理工具）来识别常见领域类别并执行分类。这使我们能够将调查回复中的短语规范化为代表性标签集。例如，我们将"医疗保健"、"医疗"和"患者监测"等回复归入统一的"医疗保健"类别。此规范化过程的详情见附录 B.1。所有其他图表呈现结构化调查问题或访谈数据的结果，无需自动处理。

如第 3.1 节所述，本文正文中的调查数据筛选为已部署（生产和试点）智能体，我们的访谈专门选择构建已部署智能体的团队。第 4-7 节中呈现的所有结果均指来自调查回复或访谈的已部署智能体，我们在全文中明确标注。完整数据请参见附录 A。

对于所有包含误差线的图表，我们报告使用 1,000 次有放回自助法样本计算的 95% 置信区间。

4. RQ1 结果：智能体的应用、用户和需求是什么？

我们现在呈现来自调查和案例研究访谈的四个核心研究问题的发现。我们从检视智能体采用的动机（第 4.1 节）开始，哪些智能体应用成功达到部署（第 4.2 节），谁使用这些系统（第 4.3 节），以及什么延迟需求影响其设计（第 4.4 节）。理解这些模式揭示了智能体系统在哪里提供实际价值，以及它们如何改变现实世界应用。

4.1 选择智能体的动机

在评估了替代方案的已部署智能体从业者中，82.6% 偏好将智能体解决方案用于部署。我们将非智能体替代方案定义为现有软件系统、传统方法或人工执行。图 1 详细说明了这些从业者报告的具体收益。

前三大驱动因素都针对减少人力投入：提高生产力和效率（72.7%）、减少人工工时（63.6%）和自动化日常劳动（50.0%）。相反，定性收益排名较低。提高用户满意度排在中间层（37.9%），其次是减少所需的人力专业知识和培训（34.8%）以及实现新技术（33.3%）。加速故障响应时间（18.2%）、减少跨学科知识需求（18.2%）和风险缓解（12.1%）排名最后。

这种优先级分布反映了实际的部署现实。组织采用智能体来解决直接的运营问题，例如需要专家的昂贵手工工作和人员不足的问题。生产力提升可以通过人工工时减少直接量化，而安全改进和风险缓解则更难验证。这种关注点与我们关于内部部署的发现一致（第 4.3 节），组织通过保持人工监督来容忍更高的错误率，以便发现错误。

报告最多的原因揭示了一个趋势：某些目标更易于验证和衡量。例如，完成任务的时间（生产力）是具体且可量化的，而风险缓解的收益则需要更长时间来验证。我们在第 7.1 节中检视这种衡量差距及其对已部署智能体的影响。

4.2 应用领域

我们发现智能体在远超软件工程的多个行业中运行。图 2 显示调查中报告部署数量最多的三个领域是金融与银行（39.1%）、技术（24.6%）和企业服务（23.2%）。我们还观察到数据分析（13.0%）、研发（11.6%）和其他专业领域（15.9%）的长尾应用。这种分布表明智能体系统在根本不同的行业中提供实际价值。

4.3 智能体的用户

我们发现已部署智能体主要直接服务于人类用户。调查数据表明 92.5% 的已部署系统服务于人类而非其他智能体或软件系统。如图 5a 所示，内部员工是主要用户群（52.2%），其次是外部客户（40.3%）。只有 7.5% 的已部署系统服务于非人类消费者。

对内部用户的关注是一种刻意的部署选择。详细案例研究揭示，组织将部署限制在内部环境中，以缓解未解决的可靠性和安全问题。内部用户在组织边界内运行，智能体错误的后果较低，人工专家随时可以纠正错误（第 4.3 节）：例如，用于内部工单的 Slack 机器人响应自动化。

此外，大多数系统——包括面向外部的应用程序——都需要特定领域的知识才能操作。例如，保险授权智能体支持护士，事件响应智能体支持站点可靠性工程师。这反映了一种模式，即智能体作为增强领域专家的工具而非取代他们。这种范式也使人类用户能够作为智能体输出的最终验证者，我们在第 6.2 节进一步讨论这一点。

除用户类型外，我们还考察了用户群的规模。我们发现已部署系统的最终用户数量差异显著。如图 4c 所示，42.9% 的部署服务于数百用户。然而，我们也观察到高流量部署（25.7%）每日服务数万到超过一百万用户，代表着重大的用户影响或可能是成熟的系统。

即使在面向外部的部署中，人类专业知识仍然至关重要。这些系统作为增强专家的工具而非独立替代品，保留了人类决策权并在必要时实现实时错误纠正。

图 5(a). 主要最终用户分布（N=67），其中斜线条形表示人类最终用户，实心条形表示非人类最终用户。

图 5(b). 已部署系统报告的可容忍端到端响应延迟（N=53）。超过 92% 的已部署智能体主要服务于人类用户，大多数系统容忍分钟级的响应时间，而非要求严格的实时响应性。

4.4 延迟需求

宽松的延迟需求在已部署智能体中很常见。图 5b 显示了最大允许端到端延迟的分布。分钟级是最常见的目标，其次是秒级。值得注意的是，17.0% 报告尚未定义限制，1.9% 允许数小时到数天。

延迟容忍度反映了第 4.1 节中的生产力焦点。智能体通常用于自动化人类通常需要数小时才能完成的任务。因此，智能体即使需要多分钟才能响应，仍比非智能体基准快数个数量级。访谈参与者强调了这一优势：即使智能体需要五分钟，这仍然比将任务分配给团队成员快 10 倍以上，特别是在存在人员短缺且任务对用户核心职责而言是次要的情况下。例子包括护士审查保险详情和软件工程师响应内部值班呼叫。一些来自案例研究的已部署智能体甚至按小时或隔夜批量处理请求，进一步表明延迟不是主要约束。

然而，这种模式在实时交互式应用中会被打破。例如，构建语音驱动系统的从业者在详细案例研究中报告延迟是他们的首要挑战（第 7.2 节）。这些系统与人类对话速度竞争，而非与任务完成基准竞争。在我们 20 个详细案例研究中，只有 5 个需要实时响应性。其余 15 个案例容忍延长的处理时间：7 个涉及时间宽松的人工审查，5 个作为异步后台进程运行，3 个具有混合操作模式。对于这些系统，分钟级的处理时间仍然可以接受，因为替代方案是数天的人工工作。

5. RQ2 结果：使用什么模型、架构和技术来构建智能体？

在确定从业者用智能体系统解决什么问题之后，我们现在讨论这些系统是如何构建的。我们考察五个关键的实施决策：模型选择、模型权重调优、提示构建、智能体架构和开发框架。

总体而言，从业者偏好成熟、直接的方法，而非随机或训练密集型技术。我们发现，在研究中流行的方法——如微调、强化学习和自动化提示优化——在部署中仍然不常见。相反，团队优先考虑控制性、可维护性和迭代速度。

5.1 模型选择

我们发现已部署的智能体严重依赖专有模型。在 20 个详细案例研究中，只有 3 个使用开源模型（LLaMA 3、Qwen 和 GPT-OSS），而其余 17 个依赖闭源前沿模型（图 6）。在使用闭源模型的团队中，10 个明确确认使用 Anthropic Claude 或 OpenAI GPT 系列。访谈中提到的具体模型包括 Anthropic Claude Sonnet 4 和 Opus 4.1，以及 OpenAI o3，每个都代表访谈时各提供商的最先进模型。虽然其他参与者没有透露具体模型，但大多数受访者遵循使用每个模型系列中最大和最有能力的最先进模型作为其智能体主要模型的模式。

我们发现开源采用很少见，这是由特定约束而非一般偏好驱动的。在使用开源模型的三个案例中，动机包括大规模推理成本过高的高容量工作负载，以及阻止与外部提供商共享数据的监管要求。例如，一个来自详细案例研究的团队服务于连续基础设施维护智能体，利用公司现有的内部计算资源（如 GPU）来服务微调的开源模型以满足成本约束。

对于大多数案例，模型选择遵循务实的、以经验为导向的方法，专注于下游性能。受访者报告说，他们测试每个任务的顶级可访问最先进模型，并根据性能进行选择。与高容量开源用例不同，这些团队注意到运行时成本与智能体增强的人类专家（如医疗专业人员、高级工程师）相比微不足道。因此，他们默认使用性能最佳的闭源模型，而不考虑推理成本。此外，20 个详细案例研究中有 4 个将 LLM 与专门的现成模型（如文本转语音、化学基础模型）结合使用来处理特定模态。

图 6. 来自访谈的案例研究系统的模型特征分布（N=20）。左侧条形图显示模型来源的开放性；"是"表示使用开源模型，"否"表示使用闭源或未披露的模型。右侧条形图显示是否使用后训练（如微调、强化学习）（"是"）；"否"表示未使用或未披露。

不同模型的数量。虽然相当一部分依赖单一模型，但大多数协调多个模型以满足功能或运营需求。调查结果显示，40.9% 的已部署智能体恰好使用一个模型，而 27.3% 使用两个，18.2% 使用三个，13.6% 使用四个或更多。在详细案例研究中，20 个中有 10 个（50%）组合模型以满足特定的功能需求。我们识别出两个驱动因素：成本优化和模态。首先，团队组合不同大小的模型以平衡延迟、成本和质量。例如，一个来自案例研究的智能体工作流将简单的子任务（如模式识别）路由到较小的模型，而为需要更高推理能力的子任务保留较大的模型。其次，团队整合模型以处理不同的数据模态。通信智能体在 LLM 之外利用文本转语音模型，而科学智能体在通用推理模型之外采用特定领域的基础模型（如化学）。

运营约束也推动多模型采用。我们发现多模型架构可能源于生命周期管理需求，而不是智能体任务的复杂推理要求。详细案例研究揭示，团队维护多个模型来管理模型迁移带来的智能体行为变化。组织经常同时运行遗留模型和新版本，因为智能体脚手架和评估套件依赖于旧模型的特定行为，突然更新可能会降低输出质量。此外，治理政策强制团队根据用户或开发者访问级别将子任务路由到不同的模型端点。因此，架构复杂性通常反映战略运营而非任务难度。

有趣的是，未部署的实验性智能体显示出更倾向于使用多个模型的集中度。这表明团队在初始开发期间探索更丰富的多模型组合，但在向生产过渡时会整合到更少的模型集上，这可能反映了运营维护负担。

5.2 模型权重调优

我们观察到已部署智能体中对提示而非模型权重更新有强烈偏好。我们发现 20 个详细案例研究中有 14 个（70%）仅依赖现成模型，没有监督微调（SFT）或强化学习（RL）（图 6）。此外，来自详细案例研究的 2 个团队明确报告基础模型能力已经满足其目标用例，使微调变得不必要。

20 个详细案例研究中只有 5 个积极使用 SFT。这些团队针对业务特定企业环境中的部署，利用高度上下文信息可以提高下游性能。例如，客户产品支持智能体受益于针对特定产品服务和政策的微调。然而，性能收益并不总是能证明开发开销的合理性。在积极使用微调模型的 5 个详细案例研究中，3 个认为 SFT 必不可少，而 2 个有选择地将其应用于定制要求证明额外成本合理的企业客户。来自访谈案例研究的另外三个团队表达了出于类似原因对未来采用的强烈兴趣。值得注意的是，我们发现采用 SFT 的 5 个详细案例研究中有 4 个将其与现成 LLM 结合使用，而不是专门依赖微调模型。

关于强化学习（RL），我们访谈的只有 1 个科学发现案例使用 RL 后训练模型。另外三个团队表示有兴趣在未来开发周期中探索 RL 用于软件测试。

然而，这些数据并不削弱后训练模型对智能体应用的价值。访谈表明 SFT 和 RL 实施起来具有挑战性，且对模型升级很脆弱。鉴于现成基础模型已经可以完成智能体应用所需的大部分工作，团队更喜欢集成开销较低、不会增加本已很高的开发和维护负担的方法。

5.3 提示策略

我们发现人类主导生产系统中的系统提示构建。我们的调查数据显示，33.9% 的已部署智能体使用完全手动的方法，使用硬编码字符串。另外 44.6% 使用混合方法，人类手动起草提示，然后使用 LLM 来增强或完善它们，3.6% 依赖使用预定义的提示模板。只有 8.9% 的受访者使用提示优化器（如 DSPy）来改进他们的智能体系统，只有 3.6% 报告让智能体自主生成自己的提示。

我们的详细案例研究证实了这一模式。20 个详细案例研究中只有 1 个（5%）探索了自动化提示优化。其余案例依赖于主要由人类构建，有时使用 LLM 进行增强。虽然最近的研究提出将提示自动化为参数优化，但我们发现这些方法在部署中很少见。我们从与从业者的访谈对话中推测，他们优先考虑可控、可解释的方法，这些方法允许快速迭代和调试，而不是需要额外工程开销的自动化或"黑盒"方法。

图 7. 已部署智能体 AI 系统的提示构建策略分布（N=53）。总体而言，提示模式表明人类仍是提示制作的核心。这是一个多选问题，因此受访者可以选择所有适用的提示构建策略。

我们发现提示复杂性随系统成熟度增加。在来自调查的已部署智能体中，我们观察到广泛的分布：虽然 51.5% 的系统使用 500 个 token 以下的短指令，但存在大量提示的长尾（图 8b）。具体而言，24.2% 的已部署智能体使用 500 到 2,500 个 token 之间的提示，12.1% 使用 2,500 到 10,000 之间。值得注意的是，另有 12.1% 甚至超过 10,000 个 token。

5.4 智能体架构

我们探索支持生产部署的核心架构模式。为确保清晰，我们采用图 22 中可视化的术语：智能体完成高级任务，任务分解为逻辑子任务，由粒度原子步骤（如模型调用、工具使用）组成。

步骤数量。我们发现生产智能体倾向于遵循具有有限自主权的结构化工作流程。我们询问调查参与者，他们部署的系统在需要人工输入之前在子任务中执行多少步骤。大多数系统在紧密的边界内运行：46.7% 的已部署调查智能体仅完成 1-4 步，另外 21.7% 执行 5-10 步（图 8c）。较小的子集（16.7%）扩展到数十步，而只有 6.7% 报告系统没有明确的步骤限制。有趣的是，当我们扩展分析以包括所有智能体（包括已部署和尚未部署的智能体）时，分布向更高的步骤数显著偏移。这表明原型和研究系统更可能运行数十步或没有明确的自主周期限制，反映了早期开发过程中对开放式自主权的更积极探索。

实际约束驱动这一设计选择。案例研究参与者将问题复杂性、智能体自规划中的非确定性以及延迟要求确定为关键限制因素。从业者有意对推理步骤施加限制以维持可靠性并管理计算时间和成本。这种简单性反映了对可预测、可控工作流程的更广泛偏好，而非生产环境中的实验性开放式自主权。

模型调用数量。虽然与逻辑步骤（通常包括工具执行等非推理动作）不同，我们专门分析模型调用以衡量部署系统的推理强度。我们观察到，在单个子任务中，部署系统通常执行数十个或更少的模型调用。大多数（66.7%）已部署调查智能体每个子任务使用少于 10 次调用，其中 46.7% 使用少于 5 次调用。其次是 33.3% 使用数十次调用，9.0% 使用数百次，6.1% 使用数千次。有趣的是，另有 12.1% 没有设置明确限制。这与我们的详细案例研究一致，其中 3 个团队确认每个子任务执行数十次模型调用（最多 40-50 次调用）。实验系统更可能处于长尾，许多智能体经常进行数十次调用。相比之下，已部署智能体集中在较低调用数量区间，表明团队在从实验转向部署时积极限制或重构调用预算，可能是为了控制成本、延迟和故障放大。

尽管模型调用有限的模式存在，31% 的已部署调查智能体已经使用各种推理时间扩展技术，而实验系统中为 44%。虽然这个数字目前包括使用多个模型组合输出等较简单的方法，但未来的工作可能会确定高级技术——如自规划、基于搜索的推理和自验证——在生产中的表现如何，因为这些方法可能会导致在人工干预之前有更多的模型调用和步骤。

图 8(a). 用于解决单个逻辑任务的不同模型数量（N=22）。

图 8(b). 提示长度分布（以 token 计）（N=33）。

图 8(c). 用户干预前的自主执行步骤数（N=60）。

智能体控制流。我们观察到生产智能体偏好预定义的静态工作流程而非完全开放式自主权。我们发现 80% 的详细案例研究使用结构化控制流。这些智能体在明确界定的动作空间内运行，而不是自由探索环境以自我确定目标。

详细案例研究提供了对这些控制流模式的洞察。九个案例使用各种形式的智能体检索增强生成（RAG）管道，从通过工具调用检索信息的单个智能体到具有超过 20 个子任务的复杂管道，这些管道在某些步骤明确配置检索。例如，一个保险智能体遵循固定序列：保险范围查找、医疗必要性审查和风险识别。虽然智能体拥有完成每个子任务的自主权（如决定某个案例是否需要人工干预进行风险识别），但每个子任务的高级目标和预期输出保持固定。

开放式自主权仍然很少见。我们只观察到一个案例，智能体以无约束探索运行。值得注意的是，该系统专门在沙盒环境中运行，对最终输出进行严格的 CI/CD 验证，避免与生产环境直接交互。

然而，我们识别出对扩展自主权日益增长的兴趣。四个详细案例研究采用规划和路由智能体来分解输入请求并将它们分派给任务专门智能体。另一个团队将智能体专门化为生成器和验证器，通过自动验证实现更大的自主权。几个团队分享说他们正在尝试灵活工作流程，允许智能体对下一步做出自主决策，或使用规划和编排智能体。

5.5 智能体框架

我们发现调查受访者和访谈案例研究之间在框架采用方面存在分歧。在来自调查的已部署智能体中，三分之二（60.7%）使用第三方智能体框架。依赖集中在三个主要框架：LangChain/LangGraph 以 25.0% 领先，其次是 CrewAI 占 10.7%，LLaMAIndex 和 OpenAI Swarm 均为 3.6%（图 9）。

相比之下，我们的详细案例研究揭示了对定制内部智能体实现的强烈偏好。20 个详细案例研究中只有 3 个（15%）依赖外部智能体框架（2 个使用 LangChain，1 个使用 BeeAI）。其余 17 个团队（85%）完全使用直接模型 API 调用在内部构建他们的智能体应用。例如，一个访谈案例明确分享说他们的智能体是他们自己的 ReAct 循环实现。值得注意的是，另外两个团队报告在实验原型阶段开始使用 CrewAI 等框架，但为了减少依赖开销而迁移到定制内部解决方案用于生产部署。

我们从详细案例研究中识别出构建定制解决方案的三个核心动机。首先，灵活性和控制至关重要。已部署智能体通常需要与专有基础设施和定制数据管道进行垂直集成，而僵化的框架难以支持。例如，一家智能体原生公司在各种客户环境中部署面向客户的智能体，需要定制编排层。其次，简单性推动决策。从业者报告说，核心智能体循环使用直接 API 调用很容易实现。他们更喜欢构建最小化的、目的明确的脚手架，而不是管理大型框架的依赖膨胀和抽象层。第三，安全和隐私政策有时禁止在企业环境中使用某些外部库，迫使团队在内部开发合规解决方案。

图 9. 在使用开放框架进行生产系统的受访者中，报告支持关键功能的框架（N=29）。调查中提供了其他框架选项。

6. RQ3 结果：智能体如何进行部署评估？

评估实践决定了哪些智能体系统能够进入生产环境，以及团队如何迭代已部署的系统。我们调查了从业者如何评估和测试他们的智能体以满足生产部署要求，检验了开发期间的离线评估和生产环境中的在线评估。具体而言，我们检验了两个方面：从业者将他们的系统与什么进行比较（基准线和基准测试），以及他们使用什么方法来验证系统输出（评估方法）。

我们的发现揭示，生产智能体的评估实践差异很大，即使在同一应用领域内也是如此，这取决于每个部署场景的具体要求和真实数据的可用性。值得注意的是，从业者目前关注智能体输出质量和正确性，而非传统软件可靠性指标。根据 20 个详细案例研究，没有团队报告对其智能体系统应用标准生产可靠性指标如五个九的可用性。相反，评估集中在智能体是否产生正确、高质量的响应。

6.1 基准线和基准测试

在开发期间，团队进行离线评估以在部署前评估智能体性能。图 10a 显示 38.7% 的调查受访者将其已部署的智能体系统与非智能体基准线（如现有软件系统、传统方法或人工执行）进行比较。剩余的 61.3% 不进行基准线比较。其中，25.8% 报告他们的系统是真正新颖的，没有有意义的基准线可供比较。虽然我们不知道剩余 35.5% 不进行比较的原因，但深度访谈揭示，即使存在替代方案，基准线比较通常也很困难。原因之一是非智能体基准线经常组合多个组件，使得系统性技术比较变得困难。人力资源支持智能体开发团队说明了智能体解决方案取代了一个结合公司文档查找、人工程序和非 LLM 人力资源软件的基准线流程。虽然任务完成时间等结果是可衡量的，但隔离技术性能进行比较具有挑战性。

除了基准线比较，团队还采用基准测试评估。我们这里所说的基准测试是指一组具有已知正确答案的精选任务或问题。在 20 个团队中，5 个构建了定制基准测试。一个团队从零开始构建基准测试，通过与领域专家合作收集真实标签。四个团队综合现有数据来策划基准测试，从过去的测试用例、系统日志、拉取请求和支持工单中提取。一个团队还在早期开发中利用了公共基准测试。剩余的 15 个团队（75%）不使用基准测试集来评估其智能体，而是使用替代方法如 A/B 测试、用户反馈和生产监控。

在构建定制基准测试的 5 个团队中，我们的访谈揭示了尽管领域和组织各异（例如人力资源、云基础设施和业务分析），却呈现出一种普遍的评估模式。团队建立一个黄金问答集，收集用户交互和反馈数据，然后与主题专家合作检查质量并扩展黄金集。这个过程延伸到生产运行时，实现 LLM 作为评判者的在线评估管道。根据我们的分析，几乎相同的管道在不同上下文中的趋同表明，可复用的数据摄取管道、黄金集策划方法和评估数据集合成生成技术存在研究和开发机会。

6.2 评估方法

我们询问参与者他们采用哪些评估策略，允许多选。这些方法适用于开发期间的离线评估和生产环境中的在线评估。四种方法主导响应：人工在环评估、基于模型的评估、基于规则的评估（启发式或语法检查）和交叉引用评估（针对知识库或参考数据集的验证）。确切问题和方法描述见附录 E。

人工在环验证。大多数（74.2%）依赖手动、人工在环评估（图 10b）。这些评估通常涉及领域专家、操作员或最终用户直接检查、测试或验证系统输出以确保正确性、安全性和可靠性。

人类专家在开发期间的离线评估中发挥关键作用。智能体开发者直接与领域专家或目标用户合作验证系统响应。例如，在测试和评估医疗智能体系统的正确性时，医学专业人员直接参与。在一个案例中，一家公司甚至完全放弃自动化评估方法，而是依靠人类专家提供反馈来手动调整每个客户部署环境的智能体配置。

人类专家还在智能体执行期间作为在线评估的验证者。团队通常让人类专家根据智能体输出执行最终操作，作为护栏层。例如，一个站点可靠性工程智能体根据跨系统堆栈的分析建议操作，但人类专家对执行什么做出最终决定。智能体不直接修改生产环境。

基于模型的评估。基于模型的评估方法如 LLM 作为评判者是第二常见的方法，被 51.6% 的受访者使用（图 10b）。虽然这种评估方法适用于离线开发时间和在线运行时评估，但 20 个访谈案例研究中有 7 个在智能体执行期间使用 LLM 评判者进行在线评估。

基于模型的评估不能消除人工参与。图 10c 显示了不同评估策略的共现情况，揭示在使用基于模型评估的 51.6% 调查受访者中，相当大一部分（38.7%）也采用人工在环验证。在详细案例研究中，所有使用 LLM 作为评判者的受访团队都将其与人工审核结合。具体而言，这些团队使用 LLM 评判者评估每个最终响应的置信度，结合人工抽样。LLM 评判者持续评估每个智能体的最终响应。如果评判者评分高于预设置信度阈值，输出自动被接受。否则，请求路由到人类专家。此外，即使 LLM 评判者表达高置信度，人类专家也会抽取预设百分比（例如 5%）的生产运行进行验证正确性，以确保运行时一致对齐。开发团队根据这种生产反馈更新提示指令和智能体配置。

其他方法。基于规则的评估方法和交叉引用策略显示出可比的采用率（分别为 41.9% 和 38.7%）。基于规则的评估包括简单的逻辑检查，如语法和句法验证或领域特定规则。例如，编码智能体通过编译检查和测试套件验证输出，而分析智能体可能应用领域特定的评分标准来评估输出质量。交叉引用评估使用外部来源进行基础和事实核查，以验证生成答案或解决方案的准确性和质量。这包括从可信知识库检索支持证据或将输出与参考数据集进行比较。

评估方法模式。共现分析揭示，人工在环评估是与其他评估策略一起使用最常见的方法（图 10c）。从业者将自动化、基于规则和交叉引用方法锚定在人工判断周围，而非孤立依赖它们。

值得注意的是，人工在环（74.2%）和 LLM 作为评判者（51.6%）相比基于规则的验证（42.9%）占主导地位。根据我们的分析，这种模式可能表明生产智能体已经处理超越分类、实体解析或模式匹配的复杂任务。这些智能体在需要细致判断的领域运行，基于规则的方法不足以应对。例如，客户支持语音助手和人力资源运营需要超越模式匹配的专业知识，这解释了为什么从业者需要人工和 LLM 验证来评估输出正确性。

图 10(a). 与替代方案的比较：显示参与者是否将其已部署的智能体与非智能体基准线进行明确比较。

图 10(b). 评估方法分布：从业者报告的评估方法分布（N=31）。该问题为多选题，因此受访者可以选择多种方法。

图 10(c). 评估策略共现：可视化评估策略之间的成对重叠。

7. RQ4 结果：构建生产智能体的主要挑战是什么？

AI 智能体已大规模部署，但重大挑战依然存在。我们调查了从业者在构建生产智能体时面临的主要摩擦点。我们的调查和详细案例研究揭示， 可靠性仍然是主要瓶颈。所有智能体阶段的调查受访者将"核心技术焦点"列为首要挑战（37.9%），远超治理（3.4%）或合规性（17.2%）（见附录 B.3）。核心技术焦点涵盖可靠性、健壮性和可扩展性。这种优先排序表明从业者目前专注于使智能体一致且正确地工作。

我们详细介绍这些挑战的三个具体维度：评估（第 7.1 节）、延迟（第 7.2 节）和安全性（第 7.3 节）。这一差距突出了将智能体从有限用例推进到更广泛应用的研究机遇。

7.1 评估挑战

创建基准测试的困难。如第 6.1 节所定义，基准测试是用于开发期间离线评估的、包含已知正确答案的任务或问题集合。在受访团队中，5 个团队构建了定制基准测试。然而，基准测试创建面临三方面挑战。首先，特定领域缺乏可访问的公共数据。在保险承保等受监管领域，公共数据的缺失迫使团队通过与领域专家和目标用户合作从零开始手工制作基准数据集。其次，大规模创建高质量基准测试需要大量资源和时间。一个受访团队报告花费数月创建了约 40 个独特的环境-问题-解决方案场景的初始集，随后又花费六个月将数据集扩展到约 100 个示例。第三，对于专注于高度定制客户集成的智能体应用，基准测试创建几乎不可行。一个受访语音智能体团队阐述了这一挑战：虽然核心功能无需大量数据即可直接测试，但主要工程工作涉及客户特定的定制，如专有工具集、产品供应和本地化对话调优。为每种可能的客户配置创建标准化基准测试是不切实际的。鉴于这些挑战，75% 的受访团队完全放弃基准测试创建，转而依赖 A/B 测试或直接客户协作，根据人类反馈迭代直到满足期望。

智能体行为打破传统软件测试。三个案例研究团队报告尝试但难以将智能体集成到现有 CI/CD 流水线中。挑战源于智能体的非确定性以及程序化判断输出的困难。尽管这些团队拥有来自基线系统的各种形式的现有回归测试，但他们尚未找到有效方法来适应非确定性智能体行为，以创建覆盖不同细微差别的充分运行时场景的测试集。

验证机制和收益量化。基于访谈案例研究，我们观察到智能体面临两个更广泛的评估挑战。首先，健壮的验证机制并不总是存在。与编码相关的智能体通过编译和测试套件受益于强正确性信号，如软件迁移智能体和站点可靠性智能体。然而，许多智能体在没有健壮且快速验证的环境中运行。例如，保险智能体只能通过真实后果（如财务损失或患者审批延迟）接收真实信号。这些信号到达缓慢且形式难以自动化评估。其次，使用智能体的最终收益并不总是容易衡量。第 4.1 节显示智能体以生产力收益为目标，因为端到端时间和人工工时可以直接量化。具有更难衡量收益的应用仍较少探索。例如，我们观察到较少的智能体减少跨领域知识需求或降低风险的案例，可能是因为收益间接显现或需要更长时间框架。

图 11. 延迟对智能体 AI 系统部署造成问题的程度（N=27）。这些响应表明延迟很少成为部署大多数智能体 AI 系统的严格阻碍。

7.2 延迟挑战

我们检查智能体执行延迟在多大程度上阻碍部署。调查结果表明，延迟对大多数团队来说是可管理的摩擦而非硬性阻碍。图 11 显示只有 14.8% 的已部署调查智能体将延迟识别为需要立即解决的关键部署阻碍，而大多数（59.3%）报告这是边际问题，当前延迟不是最优但足以部署。我们推测这种容忍度可能与异步智能体执行范式的普遍性（详细访谈案例研究中的 15/20）和内部用户群（调查中的 52.2%）相关。值得注意的是，我们观察到完整调查数据集中（包括实验系统）一致的延迟分布（图 19b）。我们认为这种一致性表明对构建离线智能体的更广泛偏好，如第 4.4 节所讨论。

交互式智能体延迟要求。虽然延迟对大多数智能体应用不是关键挑战，但对于实时交互式智能体仍是关键瓶颈。两个受访团队正在构建语音和专业聊天智能体，报告持续进行工程努力以匹配人类对话速度。与异步工作流不同，这些系统需要无缝轮换，延迟会破坏用户体验。实现超越刚性轮换交换的流畅实时响应仍是开放的研究问题和开发挑战。

实用延迟管理。访谈参与者描述了两种管理延迟的方法。首先，团队通常实施对最大步骤或模型推理调用的硬性限制，通常基于启发式规则。其次，一个团队采用创造性解决方案，预先构建请求类型和智能体动作（工具调用）的数据库，然后在运行时使用语义相似性搜索来识别类似请求并提供预构建的动作，与推理和生成新响应相比将响应时间降低了数量级。这些变通方案表明从业者目前依赖系统级工程来绕过基础模型固有的延迟成本。

7.3 安全和隐私挑战

安全和隐私在我们的调查和访谈中始终被列为次要关注点，从业者优先考虑输出质量和正确性。图 21a 显示合规性和用户信任在挑战类别中排名第四。鉴于第 4.3 节显示 52.2% 的系统服务于内部员工且许多系统有人工监督，这种优先排序反映了当前的部署环境和要求，而非忽视安全的重要性。

数据摄入和处理。图 12 中的调查结果显示 89.7% 的系统从数据库摄入信息，65.5% 摄入实时用户输入，51.7% 摄入其他实时信号。值得注意的是，69.0% 的系统检索机密或敏感数据，而只有 34.5% 检索持久性公共数据。鉴于敏感数据使用和用户输入的高普遍性，保护隐私至关重要。我们的访谈案例研究揭示团队通过法律方法解决这一问题。例如，一个构建医疗智能体的团队报告依赖标准数据处理实践和与模型提供商的严格合同协议，以防止在其用户数据上进行训练。

图 12. 数据处理能力概览：已部署智能体系统中的数据摄入和处理类型与模式（N=29）。该问题为多选题，允许参与者指出其已部署智能体系统中当前集成的所有数据处理方法。数据显示智能体如何获取信息，表明对内部基础设施的强烈依赖而非公共来源。

安全实践。深度访谈参与者描述了四种通过 受约束智能体设计管理安全风险的方法。首先，六个团队将智能体限制为"只读"操作以防止状态修改。例如，一个 SRE 智能体案例研究生成错误报告并提出行动计划，但将最终执行留给人类工程师。其次，三个团队在沙箱或模拟环境中部署智能体以隔离实时系统。在一个实例中，代码迁移智能体在镜像沙箱中生成和测试更改，仅在软件验证后合并代码。第三，一个团队在智能体和生产环境之间构建抽象层。该团队围绕生产工具构建包装器 API，将智能体限制在这个中间层并隐藏内部函数细节。最后，一个团队尝试实施镜像智能体用户权限的基于角色的访问控制。然而，智能体团队报告这仍然具有挑战性，因为智能体在访问具有冲突细粒度权限的工具或文档时可以绕过这些配置。

8. 讨论

基于第 4-7 节的定量发现，我们讨论三个关键趋势，这些趋势表征了智能体工程的当前状态。我们首先研究从业者如何通过架构约束实现生产可靠性（第 8.1 节）。接下来，我们强调当前模型能力已经如何驱动实质性价值，揭示额外的采用机会（第 8.2 节）。最后，我们概述智能体开发的具体开放研究方向（第 8.3 节）。

8.1 通过受约束部署实现可靠性

我们的数据中出现了一个悖论：虽然近 40% 的从业者将可靠性、健壮性和可扩展性确定为他们的主要开发关注点（第 7 节），但这些系统已成功达到生产或试点阶段的部署（第 4 节）。这引发了一个关键问题：如果可靠性仍然是一个未解决的挑战，智能体如何能够投入生产？我们观察到，从业者通过部署对执行环境和智能体自主权都有严格约束的智能体来确保可靠性，通常结合密切的人工监督。

我们的深度案例研究揭示了几种部署环境模式。一些智能体以只读模式运行，从不直接修改生产状态。例如，SRE 智能体执行调试然后生成详细的错误报告，由工程师审查并采取行动。其他智能体服务于内部用户，在这种情况下错误的后果较低，人类专家可以随时纠正错误（第 4.3 节）：例如，用于内部工单的 Slack 机器人响应自动化。具有写入权限的系统通过沙箱环境部署，在生产集成之前对输出进行基于规则的验证。一些团队将只读访问与镜像生产环境的沙箱相结合，以进一步降低风险。我们观察到，这些模式将可靠性挑战从确保每一步正确的自主智能体行动转移到验证最终输出是否满足可接受的质量阈值。

第 5.4 节显示 68% 的生产智能体在需要人工干预前执行少于十个步骤。组织通过提示和有限的工具故意将智能体行为限制在特定的行动空间内。面向外部的系统使用特别受限的智能体工作流程，因为客户信任和经济后果要求更严格的控制。例如，与其允许智能体自主决定是否以及在哪里通过工具调用进行搜索，团队采用具有预定检索步骤的智能体 RAG 架构，将智能体限制在特定的文档存储中。我们相信这种模式揭示了一种深思熟虑的工程权衡。生产团队平衡能力与可控性，使这些系统通过良好范围的自动化提供价值，同时保持可靠性保证。

一个开放问题仍然存在：未来的智能体如何在保持生产级可靠性的同时扩展自主权？该领域尚未建立在保持安全保证的同时系统性地放松这些约束的明确路径。我们观察到一种新兴模式来实现这一目标，即将不同的子任务合并为单一任务。例如，商业编码助手通过将编码和测试合并到统一的智能体执行流程中来采用测试驱动开发。我们相信这种将逻辑任务抽象与智能体执行步骤解耦的模式有潜力扩展到其他领域。人类将任务分解为子任务的方式可能不是组织智能体控制流的正确方式（图 22）。进展需要两个领域的进步：智能体评估必须超越正确性指标，在不同自主权级别下评估可靠性的其他方面（例如：五个 9），以及系统性地指定和验证不同抽象级别有界操作的工程实践。

8.2 丰富的智能体应用机会

我们的研究揭示了一个令人鼓舞的发现：生产智能体已经在超过 26 个领域运营（图 2），远远超出了编码相关智能体和聊天机器人。我们发现从业者从当前模型和智能体能力中提取真正的价值（图 1）。

我们的详细案例研究表明，当前的前沿模型仅使用提示策略就已经具备足够的能力来涵盖各种生产用例。第 5.1 节显示 70% 的已部署调查智能体依赖现成的模型而不进行任何微调。这一数据模式表明，从业者通过在良好范围的应用中利用现有模型能力来实现实质性部署，而不是等待模型改进。我们已经看到智能体支持医疗保健工作流程、管理业务运营和加速生产中的科学发现的多样化实现（表 1）。

图 5a 和我们的案例访谈揭示，相对较少的关注被给予将智能体应用于面向软件而非面向人类的问题。大多数生产智能体通过聊天、语音或交互式工作流程直接与用户交互。我们观察到较少的直接软件操作、维护和优化任务的部署。我们相信改进这些软件集成系统自动化的机会仍未得到充分探索，尽管实现这一潜力需要解决第 8.1 节中讨论的可靠性挑战。

8.3 开放研究问题

除了我们在前面章节中强调的方向之外，我们根据 RQ1-4 中的部署模式确定了额外的研究问题。

我们展示了智能体在现实世界中通常没有干净和快速的正确性信号运行（第 7.1 节）。我们观察到与静默故障的类比，其中在运行时捕获错误具有挑战性，成功信号通过财务损失或客户不满等真实后果到达。工程师通过密切的人工监督来确保智能体质量，投入大量精力，展示了使当前部署成为可能的有效实践。然而，该领域尚未就识别 什么以及 何时发生错误或低质量响应的有效方法达成共识。我们相信，除了基准测试和 CI/CD 集成（第 7.1 节）之外，理解智能体故障模式、开发智能体可观察性工具和推进运行时故障缓解技术代表了重要的开放研究方向。

大量证据表明对智能体后训练的兴趣，然而第 5.1 节显示微调和强化学习尽管有潜在的好处，在部署中仍然不常见。我们的访谈揭示，开发工作目前优先考虑使智能体可靠地工作，而不是为偏好优化、专业化或成本权衡改进模型能力。我们推测这种模式出现有两个原因：首先，监督微调和强化学习施加了进入门槛，需要大量代表性数据或环境以及专业的 ML 专业知识；其次，当微调模型必须适应新的基础版本时，模型升级引入复杂性。我们相信该领域需要更多样本高效的后训练方法，这些方法对模型升级保持健壮，并转化为可重复的工程实践。

我们在第 5.4 节中发现 30% 的已部署调查智能体已经采用推理时扩展技术，其中使用多个模型最为流行。从详细案例研究中，我们发现这些通常是简单的方法，例如将不同的子任务路由到专门的模型。我们相信生成-验证-搜索方法的最新进展对非科学智能体应用也具有重大潜力，因为它们提供更强的可靠性保证，同时保持可控性和可解释性。然而，实现这一潜力可能需要基础设施支持和重新设计，例如构建模拟器和设计验证器。如何调整智能体运行时环境以支持这种推理时搜索技术，以及如何在在线执行设置中有效地利用它们，都是开放的研究问题。

我们在图 13 中显示 93% 的当前生产智能体以自然语言中的文本或语音作为输入。我们的调查趋势和访谈都显示对扩展智能体模态以包括图像、时空序列、视频和科学数据的高度兴趣。访谈参与者表示，团队目前专注于易于衡量和验证的应用。我们相信，一旦这些初始部署可靠地工作，智能体功能和能力将扩展以处理更丰富的输入模态。

图 13. 数据模态：已支持的模态（红色）与调查参与者报告的计划支持模态（蓝色）对比。结果显示当前强烈偏好自然语言输入（文本和语音），同时对扩展到图像、时空序列、视频和科学数据等多模态输入有着广泛的未来兴趣。

9. 结论

我们呈现了 MAP，这是首个大规模系统性研究，特征描述了在生产环境中活跃部署的 AI 智能体背后的工程实践和技术方法。我们分析了来自 26 个领域的智能体从业者的数据，以回答关于现实世界智能体开发状态的四个研究问题：

• RQ1：为什么构建智能体？生产力驱动采用。组织部署智能体主要是为了自动化日常任务和减少人工任务工时，优先考虑可衡量的效率收益而非新颖能力。
• RQ2：智能体如何构建？简单性和可控性占主导地位。生产系统偏好使用手动提示而非权重调优的闭源模型。在架构上，这些系统依赖具有有限自主权的结构化工作流程，通常在人工干预前执行有限的步骤。
• RQ3：智能体如何评估？人工验证仍是主要方法。从业者严重依赖人工在环评估，因为干净的基准和真实数据集稀缺。LLM 作为评判者等自动化技术补充而非替代人工审核。
• RQ4：挑战是什么？可靠性是核心开发焦点。确保正确性和评估非确定性智能体输出的困难驱动了这种摩擦。延迟和安全性通常作为可管理的约束而非硬性阻碍，因为工程变通方案和受限环境目前管理它们。

随着"智能体工程"成为一门新兴学科，MAP 为研究人员提供了对现实世界约束和机遇的关键可见性，同时为从业者提供了来自各行业的经验证部署模式。