生产里的智能体怎么建：20 个案例和 86 个已部署系统

生产环境里的智能体实测：MAP 对 20 个案例和 86 个已部署系统的记录

Melissa Z. Pan、Negar Arabzadeh（通信 {melissapan,negara,mme}@berkeley.edu）、Riccardo Cogo、Yuxuan Zhu、Alexander Xiong、Lakshya A Agrawal、Huanzhi Mao、Emma Shen、Sid Pallerla、Liana Patel、Shu Liu、Tianneng Shi、Xiaoyuan Liu、Jared Quincy Davis、Emmanuele Lacavalla、Alessandro Basile、Shuyi Yang、Paul Castro、Daniel Kang、Koushik Sen、Dawn Song、Joseph E. Gonzalez、Ion Stoica、Matei Zaharia、Marquita Ellis。

单位：加州大学伯克利分校、Intesa Sanpaolo、伊利诺伊大学厄巴纳-香槟分校、斯坦福大学、IBM Research。星号在原文表示项目共同牵头。

摘要

基于大语言模型的智能体已经在多个行业的生产环境里运行，但哪些技术做法让部署成功，仍然缺少记录。本文给出第一项系统研究 MAP（Measuring Agents in Production，测量生产中的智能体），数据来自智能体开发者本人。作者做了 20 个深度访谈案例，并调查了 26 个领域里 86 个已部署系统的实践者。

研究问四件事：组织为什么建智能体，怎么建，怎么评测，以及开发中最大的困难是什么。

生产智能体用的是简单、可控的做法：68% 在人工介入前最多执行 10 步；70% 依赖对现成模型做提示，而不是改模型权重；74% 主要靠人来评测。可靠性（在一段时间内、在指定环境里持续给出正确行为）仍是首要开发挑战。实践者目前用系统层设计来处理它。

MAP 记录生产智能体的现状，让研究社区看见部署现实，以及还没被充分研究的方向。

1 引言

大语言模型使一类新软件成为可能。智能体把基础模型与工具、记忆和推理结合起来，自主执行多步任务（Wang 等，2024b）。研究里，这类系统已经出现在药物发现和科学发现等方向（Huang 等，2025；Novikov 等，2025；Lu 等，2024）。产业也开始把智能体放到金融、医疗和教育等社会核心领域（IACPM 与 McKinsey，2025；UHS, Inc.，2025；Linsenmayer，2025）。

与此同时，已有研究指出智能体部署常常失败或达不到预期（Xue 等，2025；Reuters Staff，2025；Shome 等，2026）。潜力与失败之间的反差，引出一个基本问题：什么让智能体部署成功。公开材料里几乎没有生产智能体是怎么建出来的。

MAP 是对生产中人工智能智能体的第一项大规模系统研究。四个研究问题是：

• RQ1：智能体用在什么应用上？
• RQ2：用什么模型、架构和方法？
• RQ3：智能体如何被评测？
• RQ4：部署中最主要的挑战是什么？

数据来自两部分。一是 20 场深度访谈，对象从自有人工智能研究实验室的大型技术公司到智能体创业公司（图 15）。二是调查，306 名正在建智能体的实践者，覆盖 26 个领域（图 2）。调查时间是 2025 年 4 月到 11 月。主文把回答筛到 86 个处于生产或试点阶段的系统（图 14(b)），日活从数百到数百万（图 14(c)）。这些生产和试点系统在文中称为已部署智能体。未筛选的全部调查数据放在附录 D。

各研究问题的主要结果：

RQ1：采用智能体的动力是生产率。80% 的实践者主要为了提高生产率，服务对象主要是人而不是其他系统。已部署智能体多在能容忍时延的应用里：66% 允许响应时间为分钟级或更长。即便如此，它们仍能超过人工基线。

RQ2：生产智能体偏向简单和可控。团队用现成模型而不是改权重（70%），手工构造提示词（79%），并用静态工作流（68% 在人工介入前执行不超过 10 步）。组织有意用能力换可控性，以维持可靠性。

RQ3：人在回路的评测占主导。74% 的已部署智能体主要靠人在回路评测（人在回路指领域专家、操作者或最终用户核对输出是否正确）。大语言模型当裁判等其他方法是补充。由于现成基准少、自建又难，75% 的团队放弃正式基准，改用 A/B 测试或专家反馈来提高可靠性。A/B 测试指把两个版本分给不同用户、比较结果。

RQ4：可靠性是首要开发挑战。评测也难，难在基准稀缺和反馈滞后。安全则靠运行约束来缓解。

作者归纳出一条原则：实践者靠系统层设计的常规做法获得可靠性，而不是靠模型层或算法进展。例如，尽管强化学习在研究和基准上很常见，实践者默认提示闭源模型，因为这种做法对模型升级更稳，也更省样本。团队选择简单、可控的方法，不是因为不会用复杂方法，而是因为它们给出更可靠的智能体表现和更快的开发周期。

贡献有三项：

1. 第一项大规模生产智能体实证：20 场部署团队访谈，调查 306 名实践者，其中 86 个处于部署阶段。
2. 在 17 个设计维度上的刻画：模型、架构、提示、评测、应用和运行约束。
3. 由数据支持的判断：可靠性来自系统层设计，而不是算法进展。

图 1：实践者建设和部署人工智能智能体的原因（N=66）。本题可多选，比例加总不为 1。误差线是 1,000 次有放回自助抽样得到的第 95 百分位区间。本图为原文 PDF 对应页的渲染，格内数字以原图为准。

2 相关工作

据作者所知，这是第一份从技术上刻画生产中智能体如何被建造的工作。各类相关工作的补充见附录 F。

商业智能体调查从相邻角度看采用情况。Challapally 等（2025）从尝试接入智能体的公司高管视角看经济可行性。Shome 等（2026）分析营销材料并做用户研究，指出能力缺口。LangChain（2024）调查了 1,300 名专业人士的动机和挑战。咨询报告则侧重组织准备度（PwC，2025；Sukharevsky 等，2025）。MAP 的范围是生产系统，焦点是实践者给出的工程级技术数据。

学术综述综合已发表研究，概述智能体架构和分类（Wang 等，2024b；Liu 等，2025），也有专门的评测综述。它们不提供一手生产数据。应用演示展示单个系统的能力，但不做跨组织的现场刻画。表 4 把文献分成这三类。

3 研究方法

要理解哪些技术方法让智能体进入生产，作者在 2025 年 4 月到 11 月做了 20 场深度访谈，并调查了 306 名实践者。这类研究有两个困难：带真实用户、且成功的智能体部署很少；生产智能体通常是专有的，公司不一定愿意参加。

应对办法是系统抽样，并写明选择标准和限制。研究优先多样（领域和组织规模）和透明。本研究经所在机构审查委员会豁免。

3.1 数据收集一：深度案例

20 个案例来自对机器学习和软件工程师的访谈。

参与者不是一次选完。作者按滚雪球抽样，随出现的发现扩大样本（Naderifar 等，2017）。起点是职业网络里、大型技术公司中有相当人工智能研究的智能体团队，再按应用多样性、组织成熟度和全球覆盖扩展。案例跨五个板块（表 3），组织从创业公司到全球企业（图 15），部署规模从数百用户到数百万用户，跨多个大洲。

按案例计：11 个来源覆盖五到六个大洲，4 个覆盖二到四个，5 个只在一个大洲；按国家覆盖，13 个跨数十个国家，1 个跨数百个国家，5 个只在一个国家（图 16、图 17，附录 C.2）。全部案例都是经核实的生产（14 个）或试点（6 个），服务真实用户。案例匿名，在结果里记为 C01、C02 等（表 3）。

访谈是半结构化的，每次 30 到 90 分钟，由 2 到 5 名与参与组织无隶属关系的研究者进行。提纲覆盖系统架构、评测和部署挑战（附录 C.3）。半结构化是为了既能追意外主题，又保持一致。每次访谈按同一协议记录。

分析上，每次访谈后研究者除笔记外还记下观察到的模式，供抽主题。然后用扎根理论（Glaser 与 Strauss，1967）对全部访谈做开放编码，找出反复出现的主题，再用聚焦编码归成更大的类。开放编码全部由人完成：每份访谈笔记至少由三名研究者独立编码，分歧通过同行讨论解决。

表 3：按应用领域分组的案例。共 20 个案例，相近案例为清晰和保密做了合并。

3.2 数据收集二：公开在线调查

问卷有 47 题，用来确认案例里的定性观察，并在更大尺度上看部署，对应四个研究问题。作者先拿研究外的智能体开发团队试填，按反馈改题。最终问卷在 Qualtrics 里做动态分支：后续题目随先前回答变化，以便深入又维持完成率。所有题目可选，以尊重参与者。完整题目在附录 G。

问卷经 Berkeley RDI Agentic AI Summit（UC Berkeley RDI，2025）、AI Alliance Agents-in-Production Meetup（The AI Alliance，2025）、UC Berkeley Agentic AI MOOC（Berkeley RDI，2025），以及 LinkedIn、Discord、X 等职业网络发放，时间是 2025 年 7 月 28 日到 10 月 29 日，对象是正在建智能体系统的实践者。收到 306 份有效回答，角色多样（图 14(a)），领域 26 个（图 2）。

处理时筛到明确处于生产或试点的 86 条。第 4 到 7 节的结果都指这些已部署智能体；未筛选数据在附录 D。这些不是小型试点：许多服务真实用户，规模从数十到超过一百万（第 4.3 节，图 14(c)）。作者认为，接触生产智能体本身就是瓶颈，86 个已部署系统和 20 个深度案例已经提供有意义的覆盖。

多数题目是结构化的（单选、多选、数值）。领域分类（图 2）是唯一自由文本题。作者用 LOTUS（Patel 等，2025）做语义聚合，得到候选领域类，再由三名独立标注者标注。Cohen’s κ 为 0.636。κ 衡量标注者之间的一致程度，0.636 属于中等一致。细节在附录 B.1.2。分类比较报告 95% 置信区间，由 1,000 次有放回自助抽样计算。

3.3 研究限制

样本覆盖再努力，范围和抽样仍有固有限制。地理上，案例团队集中在美洲，欧洲只有少数。两种数据都有参与偏差：访谈能否成行取决于公司政策；尽管多渠道发放，调查回答仍可能偏向作者的职业网络。

跨数月收集扩大了系统覆盖，也可能引入时间偏差。作者用在这段时间里保持稳定的主题来部分缓解。窗口是 2025 年 4 月到 11 月，领域变化很快。细粒度比例以后可能变。作者把 MAP 看成这段时间里实践者如何做部署的定性证据，而不是这段有限时期的固定流行率估计。

因此 MAP 是把生产智能体实践的前沿记下来供公开研究，不是全球所有智能体开发的完整覆盖。访谈和调查适合回答：团队为什么选择有界工作流，如何评测模型变更，哪些约束塑造部署。直接审计已部署系统是互补视角，作者正在作为后续工作推进。

4 RQ1 结果：智能体用在什么应用上

本节说明组织为什么建智能体、哪些应用进入部署、谁在用，以及什么要求塑造设计。

4.1 为什么建智能体

已部署智能体主要追求可测量的生产率。在有已部署智能体的受访实践者中，80% 提到提高生产率，72% 提到减少人工工时（图 1，N=66，可多选）。更难量化的收益出现得少：风险缓解 12%，减少跨学科专业知识需求 18%。生产率应用的成功指标直接：访谈团队通常比较智能体与替代系统的总完成时间。风险缓解这类运营改进，要经过更长的验证期，收益才测得到。在为同一目标评过替代系统的实践者中，83% 更愿意选智能体，而不是非智能体方案（软件或人工执行）。

发现 1：实践者建智能体，主要是用自动化换生产率；风险缓解这类更难量化的用途较少。

4.2 应用领域

69 个已调查的已部署智能体里，有 26 个不同应用领域，远超出软件工程。图 2 显示金融与银行 44%，科技 48%，企业服务 42%，是采用较早的一类。零售、医疗和其他服务业构成长尾。表 1 列出被记为“其他”的领域，包括化工、专有网络、电信、市场进入运营、供应链、食品饮料、建筑、汽车、旅行、广告、美妆健康、隐私、娱乐与游戏、影视、社交媒体、涂料。

本题可多选，一个系统可以落入多个类，比例加总不为 1。作者认为，许多传统基准（编码、数学推理）之外的真实任务，已经是可行的智能体应用。

发现 2：金融、科技和企业服务领先，但 26 个领域里正在出现的部署，说明智能体应用在更多真实场景里有空间。

4.3 谁在用

已调查的已部署智能体主要服务人：92.5% 的主要用户是人，而不是其他软件（图 3，N=67）。内部员工占 52%，外部客户占 40%，非人系统只占 8%。斜线柱表示主要服务人类用户，实心柱表示主要服务非人用户（内部服务或其他自动智能体）。发现 3 把这一比例写成 93%。

访谈表明，以人为中心可能是有意的。实践者报告先在内部部署，以降低可靠性和安全风险：出错后果较小，人工监督也更容易。即便面向外部，系统通常是增强领域专家，而不是替换人工；人是智能体输出的最终核对者。部署规模不一：43% 服务数百用户，26% 服务数万到超过 100 万日活用户（图 14(c)）。附录 C 对同一图给出 42.9% 与 25.7%，与正文的四舍五入一致。

发现 3：93% 的已调查已部署智能体服务人类用户，从而可以直接人工监督。

4.4 时延要求

生产智能体能容忍的时延比常见优化目标松：66% 允许响应时间为分钟级或更长，17% 没有明确上限（图 4，N=53）。附录把“没有上限”写成 17.0%。这与机器学习系统研究里以降低时延为主的目标不一致。

访谈说明，容忍来自一种主要用法：在后台自动化人的工作流。分钟级智能体仍比人工基线快约 10 倍。这在人手不足、且被自动化的任务不是用户主业时尤其重要。例如，C01 用智能体做临床人员的保险预审和获批准备，C02 协助销售人员做客服，C16 帮助软件工程师分诊事件。20 个案例中有 15 个可以异步运行，有的按小时或隔夜批处理。对这些应用，分钟级时延仍然短于人工完成时间。

只有 5 个案例要求实时响应，包括按人类对话速度运行的语音智能体（C04、C05）。对这些系统，时延是首要部署挑战（附录 B.4.2）。对其余系统，宽松的时延让实践者优先输出质量和可靠性，而不是时延优化。

在 15 个可延长处理的案例里：7 个有人工复核、时间宽松；5 个是异步后台；3 个是混合。访谈里还有一个具体说法：即便智能体花五分钟，仍比把任务交给团队里的人快 10 倍以上。

发现 4：已部署智能体容忍分钟级时延，异步系统成为常见的智能体应用。

5 RQ2 结果：用什么模型、架构和技术

本节看五项设计决定：模型选择、权重调整、提示构造、智能体架构、开发框架。

5.1 模型选择

案例显示，已部署智能体严重依赖专有前沿模型。20 个案例中有 17 个使用闭源模型（图 5）。其中 10 个团队明确报告使用访谈当时的前沿模型：Anthropic Claude（Sonnet 4、Opus 4.1）或 OpenAI GPT（o3）。开源出现在 3 个案例，用来处理特定约束：推理成本在高流量下不可接受（C09 用公司已有 GPU 微调了一个基础设施维护模型），或监管不允许共享敏感数据。

选型靠实测。工程师评估能拿到的最强模型，按下游表现选择。这些团队报告，运行成本相对替代的专家人工成本（医疗专业人员、资深工程师）仍然可以忽略，因此用昂贵的前沿模型是说得通的。

发现 5：案例数据显示，已部署智能体依赖专有前沿模型（17/20）；开源用来处理成本或监管约束。

不同模型的数量。调查里，41% 的已部署智能体只用一个模型，59% 协调多个模型。图 7(b) 的样本量是 N=22。案例中有一半团队（10/20）组合多个模型，原因既有功能需要，也有运行约束。

功能需要包括：（1）成本，简单子任务走小模型，复杂推理走强模型（C16）；（2）模态，把语音合成和语言模型合在一起（C04、C05），或把领域模型（化学）和通用推理模型配对（C06 到 C08，图 13）。

运行约束是模型升级带来的脆弱。智能体脚手架、提示词和评测会锁在特定模型行为上。换更新的模型可能弄坏工作流，团队于是让旧模型和新模型一起跑（C10）。在生产里，更新或更强的模型并不保证智能体表现更好。

发现 6：生产智能体使用多个模型（59%），既反映功能需要（成本、模态），也反映运行约束（模型迁移）。

5.2 是否改模型权重

案例里，已部署智能体压倒性地偏向提示，而不是改权重。20 个案例中有 14 个（70%）使用现成模型，不做监督微调（SFT，用标注数据继续训练）或强化学习（RL，按奖励更新模型）（图 5）。两个团队明确说基础模型已经满足任务，不必再训练。

5 个案例使用 SFT：两个团队持续使用，针对业务特有上下文（例如 C17）；三个团队有选择地用，在有训练数据、成本划得来的企业客户上（例如 C14）。这 5 个里有 4 个把微调模型和现成大语言模型一起用，而不是只靠微调。只有 1 个案例使用 RL 训练的模型（C06，科学发现）。三个团队计划将来在复杂多系统环境里采用 RL。

访谈给出偏向提示的实际理由。SFT 和 RL 实现成本高，而且对模型升级脆弱：版本一变就要昂贵地重训。团队更想降低开发和维护开销。

时延要求也可能把团队推向模型适配。4 个有明确有界时延要求的案例里，3 个做了权重调整（C02、C04、C14），1 个把专有模型和缓存等系统层技术一起用（C05）。样本小，作者只当作观察，不当作流行率：对时延敏感的团队会改模型或改系统设计，而不是只靠前沿专有接口。

发现 7：部署里后训练较少（6/20）。访谈团队主要用前沿模型做提示工程。

图 5：20 个案例（N=20）上的模型来源开放程度，以及是否做后训练。“有时”表示选择性使用，例如成本说得通时才用。原文这一图在 HTML 中没有独立图片文件，数字见本节。

5.3 提示词怎么写

尽管已有自动方法，人仍处在提示构造的中心。已部署智能体中，34% 使用手工硬编码提示，45% 由人起草再用大语言模型增补（图 6，N=53）。只有 9% 使用提示优化器（例如 DSPy，Khattab 等，2024）。DSPy 是把提示写成可优化程序的框架。案例确认这一模式：20 个团队里只有 1 个试过自动优化，其余靠人来写，有时再用大语言模型打磨。实践者优先可控、可解释、能快速迭代的方法。作者推测，黑盒优化会带来额外工程开销。

提示长度随系统成熟度变化很大。多数已部署智能体（52%；附录按图 9(b) 写成 51.5%，N=33）使用 500 token 以内的短提示。token 是模型计费和上下文长度的基本单位。长尾是：24.2% 在 500 到 2,500 token，12.1% 在 2,500 到 10,000 token，另有 12.1% 超过 10,000 token。案例表明，很长的提示通常出现在面向外部客户、需要大量护栏的智能体上。长提示往往是逐步加上护栏、例外处理、政策和领域指令，而不是一次设计出来的。

发现 8：调查显示人主导提示构造（79% 为纯手工或手工加大语言模型）；自动优化仍然少见（9%）。

5.4 智能体架构

预定义的结构化工作流主导生产部署。80%（16/20）的案例使用结构化工作流，而不是开放式自主规划。这些智能体在实践者事先划定的动作空间里运行。9 个案例实现了较复杂的智能体检索增强流水线：单个智能体通过工具调用检索，或在流水线的 20 个以上子任务里逐步配置检索。例如 C01 按固定顺序做保障查询、医疗必要性审查和风险识别。智能体自主完成每个子任务，但高层目标是固定的。这是把已有业务流程改成智能体工作流，而不是建造完全自主的人工智能工人。

工作流占主导，是为了可控性，以及让人类专家留在回路里以保证可靠。团队有意为生产稳定而限制自主性。只有 1 个案例使用不受约束的探索，而且只在带严格持续集成与交付核验的沙箱里（C09）。

人工介入前的步数。调查把这种受约束的自主量化了：68% 的已部署智能体在需要人工介入前执行少于 10 步，47% 少于 5 步（图 7(a)，N=60）。作为对照，研究原型的步数高得多（图 21(a)），反映部署前更激进的自主探索，到部署时收束。访谈表明，问题复杂度、规划的非确定性，以及时延，推动了有意的步数上限。

发现 9：两项数据都显示结构化工作流占主导；68% 的智能体在人工介入前执行少于 10 步，可靠性优先于自主性。

图 7：已部署智能体的架构与模型选择。（a）用户介入前的自主执行步数（N=60）；（b）系统中使用的模型数（N=22）。原文这一图在 HTML 中没有独立图片文件。

5.5 智能体框架

系统成熟并扩大之后，团队更愿意自己实现，而不是用第三方框架。生产部署的案例中，85%（17/20）用直接接口调用做内部定制实现；只有 3 个使用外部框架（LangChain/LangGraph、DSPy）。附录写明这 3 个里 2 个用 LangChain/LangGraph，1 个用 DSPy。

调查呈现不同的画面。主文写 61% 目前使用框架，LangChain/LangGraph 占 25%。附录 B.2.1 按图 9(a)（N=29）写成：已部署智能体中 60.7% 使用第三方框架；LangChain/LangGraph 25.0%，CrewAI 10.7%，LlamaIndex 与 OpenAI Swarm 各 3.6%。另有 2 个团队明确从框架（例如 CrewAI）迁到定制方案，以便生产部署。还有两个团队在原型阶段用过 CrewAI，上生产时迁走，以减少依赖开销。

为什么定制。三个原因。第一，灵活：生产智能体要和专有基础设施、数据流水线垂直集成，刚性框架支持不了（C14：为不同客户环境做专门编排）。第二，简单：核心智能体循环可以直接实现，避免依赖膨胀（C12：自己实现 ReAct。ReAct 是边推理边调用工具的循环）。第三，安全：企业政策禁止某些外部库，只能做合规的内部方案。

发现 10：生产智能体偏向定制实现（案例 85%），以便在规模上获得灵活、简单和控制。调查里的框架使用率更高，深度案例则明显偏向内部实现。

6 RQ3 结果：部署前如何评测

本节看实践者如何判断智能体能否上生产、运行中是否正确，包括和什么比、用什么核验。

6.1 基线与基准

多数团队在开发期间没有标准化评测框架。只有 39% 把智能体系统与非智能体基线（已有软件、人工执行）比较；26% 报告不存在有意义的基线（图 10(a)）。附录把做过比较的比例写成 38.7%。访谈说明，即便基线存在，比较也难：非智能体系统常常是多组件拼起来的（人工规程、旧软件、文档系统），很难做孤立的技术比较（例如 C17：人力资源智能体替换的是人机混合工作流）。

正式基准更少见。案例中 75% 不用基准集评测，而靠 A/B 测试、用户反馈和生产监控。这里的基准指带期望输出、用于系统评测的整理过的任务集。五个团队自建基准：一个从头建、由专家标注标准答案，四个从已有数据合成（测试用例、日志、支持工单）。这些基准因任务而异，不容易跨部署复用。不同领域（人力资源、基础设施、分析）出现了收敛的做法：建立黄金问答集，收集用户交互，再由专家复核着扩充。这一模式通过大语言模型当裁判延伸到运行时（第 6.2 节）。

发现 11：两项研究都显示评测缺少标准化。75% 的案例不用基准，而靠 A/B 测试和直接用户反馈。

6.2 评测方法

尽管有自动替代，人的核验仍占主导。74% 依赖人在回路，由领域专家、操作者或最终用户核对输出是否正确（图 8，N=31，可多选）。附录把这一比例写成 74.2%，把大语言模型当裁判写成 51.6%；主文的对应数字是 52%。

案例表明，人在开发和生产中都核验。开发团队和领域专家一起建基准、核对回答（例如 C15：线上系统的事件配置）。生产中，人是最终核对者：智能体建议动作，专家批准执行（C10：工程师按站点可靠性智能体的建议执行）。有一个团队放弃全部自动方法，按每个客户的反馈手工调配置。

基于模型的评测是第二常见（52%），但调查显示 39% 把它和人的核验一起用（图 10(b)）。所有使用大语言模型当裁判的案例团队都配人工复核：裁判给每条回答打置信度，低置信度交给专家，并随机抽查一部分高置信度输出（C01、C15）。

人在回路（74%）和大语言模型当裁判（52%）都高于基于规则的方法（42%）。案例认为，这是因为任务复杂：客服、人力资源和合规需要句法检查抓不住的判断。方法说明和共现模式见附录 B.3。

发现 12：人的判断主导评测（74%），大语言模型当裁判（52%）是补充。智能体处理的任务需要规则核验覆盖不了的专门判断。

图 8 与图 10(b) 的原图：已部署智能体的评测方法（图 8，N=31，可多选），以及各评测策略的成对重叠。人在回路与其他策略的重叠最高。热图原图入库，格内数字以原图为准。

7 RQ4 结果：部署中最大的挑战

可靠性仍是首要开发瓶颈。作者采用 IEEE（1990）的标准定义，并参照先前工作（Yao 等，2025）：可靠性是在指定环境、指定时期内无故障运行的概率。

38% 的实践者把“核心技术表现”排为智能体开发的第一优先。这一类包含可靠性、稳健性和可扩展性，远高于治理（3%）或合规（17%）（附录 B.4）。附录按图 11 把排第一的比例写成 37.9%，样本量 N=29。

发现 13：可靠性仍是首要瓶颈。

7.1 可靠性挑战

这里有一个表面矛盾：如果可靠性是首要瓶颈，系统如何进入生产？作者观察到，团队用严格的环境和自主性约束来降低可靠性风险。

访谈里反复出现三种失败模式。第一，评测覆盖不全，团队一边靠专家复核，一边从零建任务专用测试集（C01、C03、C05、C09、C14、C15、C17）。第二，正确性失败随任务复杂度上升，尤其当系统混合异构或多模态数据时，这常常触发人工核验（C03、C06、C07、C10、C14）。第三，与遗留系统集成，再加上已有的安全与合规要求，会限制功能或收窄部署范围（C03、C04、C10、C15、C16）。

智能体部署在能把失败影响压到最小的受控环境里：只读模式，站点可靠性智能体生成缺陷报告供工程师看，但不改生产（C16）；沙箱核验，有写权限的系统在进生产前做基于规则的检查（C09、C11、C12）；内部部署，服务员工，出错后果较小、专家监督即时（第 4.3 节）；包装接口，把智能体限制在隐藏生产细节的抽象层（C16）；基于角色的访问控制，权限与用户一致（C15）。

调查显示团队有意限制自主性。68% 在人工介入前执行少于 10 步（第 5.4 节）。访谈团队用提示词和有限工具来约束行为。面向外部的系统限制更严：信任和经济后果要求控制。具体做法包括预先配置只检索指定文档库、关键步骤必须人工批准、动作序列固定。

7.2 评测挑战

第 6.2 节看到的模式，正式基准少、人的评测占 74%，来自访谈里的技术困难。

基准稀缺有三点。受监管领域没有公开数据，只能花高成本让专家做数据集（C01、C16：数月的收集和标注）。按客户定制使标准化基准不可行（C04：每次部署有专有工具集和本地化对话），团队于是默认做 A/B 测试和迭代的客户反馈。

真实任务也难核验。稳健的核验机制并不总有。编码智能体是少见的例外，可以用编译和测试套件核验（C09、C12），迭代更快。多数智能体没有快速的自动信号。例如保险智能体的反馈，要等到延迟的真实后果，如财务损失或患者获批延误（C01）。这一核验缺口既可以解释对人的评测的依赖，也可以解释应用集中在生产率上（第 4.1 节）：端到端时间好量化，更难测的收益仍少被探索。

7.3 安全与隐私

访谈显示，实践者目前把质量和正确性放在安全前面。安全被隐含地通过系统层设计实现，例如只读智能体，与第 7.1 节同类。当前部署也符合这一点：52% 服务内部员工（第 4.3 节；附录写成 52.2%）。随着部署扩到风险更高的外部场景，系统性安全机制仍是开放问题。

调查显示智能体经常处理敏感数据。例如 69% 检索机密数据（附录 B.4.1 写成 69.0%）。访谈里，团队用与模型提供方的合同来处理隐私，约定不用用户数据训练（C01：医疗记录）。

表 2：参与者报告的主要挑战类别。

图 11：已部署智能体遇到的主要挑战（N=29）。（a）排第一的挑战分布。排名靠后表示相对其他挑战优先级较低，不是问题已解决。例如合规与治理。（b）每个挑战类别被分到各难度名次的频率，1 最难，5 最不难。热图原图入库。

8 讨论与结论

通过 20 个深度案例和对 86 个已部署系统的调查，作者把通常专有的知识交给研究社区。中心观察是：部署技术与流行的研究方法分叉，这标出尚未充分研究的机会。13 条发现被收成三个主题。

作者既记录确认性发现（例如生产率是首要动机，发现 1），也记录与常见研究叙述相反的发现（简单工作流、有界自主、频繁的人工监督）。团队最常用来衡量生产率的，是端到端完成时间，而不是以模型为中心的指标（第 4.1 节）。

部署里令人意外的模式。提供方更新下的模型脆弱，使实践者离开后训练（发现 7），尽管研究里后训练结果强。这指向省样本的后训练，以及在基座模型更新时能迁移已学行为或保住表现的学习方法。能容忍时延的应用（发现 4）说明，推理时扩展可以满足智能体的时延要求，从而鼓励演化搜索、测试即核验的架构，以及面向智能体的批推理调度。多模型协调（发现 6）则需要高效的多模型推理、编排和路由。

可靠性来自系统层设计。实践者偏好简单、可控的方法（发现 7、9、10），而不是黑盒优化，这与传统软件工程一致。访谈还揭示生产可靠性的一项独特要求：在开发和运行时持续核验正确性。由此产生的研究方向包括可观测性（运行时监控、失败检测）、评测（正确性指标、真实任务基准）和失败恢复。面向机器学习的机会还包括：训练对系统规格有响应的模型，在正确性规格下学习，以及带约束的优化（可核验的动作、有界规划）。

人在回路是设计原则。实践者有意把人在回路做成架构的一部分，智能体在人工介入前只执行有限步数（发现 3、9、12）。这目前用来补评测的不足（第 7.2 节）和领域知识。数据暗示，它不一定只是要被克服的临时约束，而可能作为有意的设计原则留下来。许多研究强调提高单个智能体的自主性；这里的发现指向增强人类工作者的智能体，包括带人工监督的工作流、协调界面，以及在人监督系统里的有界自主。

随着“智能体工程”成为一门新的做法，MAP 把部署现实的实证交给研究社区，以便一起推进能在真实任务上可靠交付社会价值的智能体。

致谢与影响说明

作者感谢匿名参与者。研究得到 Accenture、Amazon、AMD、Anyscale、Broadcom Inc.、Google、IBM、Intel、Intesa Sanpaolo、Lambda、Mibura Inc、Samsung SDS 和 SAP 的赠予支持。Alex Dimakis、Aditya Parameswaran、Drew Breunig、Tian Xia、Bhavya Chopra 和 Shishir Patil 提供了反馈。

参与者数据在保密协议下收集，以汇总、去标识的形式报告。论文目标是推进机器学习。作者认为除此以外不必单独强调的社会后果，不在此展开。

附录 A 附录如何组织

附录 B 补充主文结果。附录 C 说明调查与案例的数据细节。附录 D 给出未筛选的全部调查结果。附录 E 定义任务、子任务和步。附录 F 说明文献综述的范围和分类。附录 G 是问卷。

附录 B 补充结果

全文和附录里，涉及分类比较的调查题，在适用时用 1,000 次有放回自助抽样报告 95% 置信区间。

B.1 应用要求

已部署智能体里，92.5% 把人作为主要用户。内部员工是其中最大的一组。领域跨 26 类，从企业和软件运营到长尾行业，表 1 的“其他”已在第 4.2 节列出。领域标签由 LOTUS 产生候选类，三名标注者独立标注，Cohen’s κ=0.636。

时延方面，分钟是最常见的目标，其次是秒。17.0% 尚未设上限。智能体常用来自动化人要花数小时的任务，因此多花几分钟仍然比非智能体基线快数量级。实时交互是例外：语音系统要和人的对话速度比，而不是和任务完成基线比。20 个详细案例里只有 5 个要求实时。其余 15 个可以延长处理。

B.2 架构

框架采用在调查和案例之间分叉，数字已写入第 5.5 节。定制的三个动机是灵活与控制、简单、安全与隐私。提示长度的长尾已写入第 5.3 节。

B.3 评测

图 10(a)：38.7% 的回答者把已部署智能体与非智能体基线做过比较，多数没有。原因包括任务没有清楚的既有替代，或基线是多种工具和人工步骤混在一起，难以做系统的技术比较。团队于是按任务成功、用户结果或定性改进来评，而不是相对单一基线报性能差。

图 10(b)：人在回路最常与其他方法一起用。实践者通常把基于规则的核验、交叉对照和大语言模型判断，锚在人工标注上。许多生产智能体的正确性不能由确定性规则或简单模式匹配完全决定，例如客服语音或人力资源。自动检查是补充。

在包含原型和研究系统的全部数据里，明确与替代方案比较的比例略低：全部数据 34%，已部署子集 38.7%。作者认为实验原型在评测上投入较少。

B.4 挑战

图 11(b) 给出每个类别被分到各名次的频率。核心技术表现被 37.9% 的回答者排为最显著的挑战（第 1 名），远高于其他类。紧随的第二层摩擦是数据与模型完整性、系统集成与验证。透明与治理、合规与用户信任排名更低。作者强调，排名低表示相对其他挑战优先级较低，不是问题已解决或不重要。

#### B.4.1 安全与隐私

安全和隐私在两项研究里都是次级关切。图 11(a) 里，合规与用户信任排第四。第 4.3 节显示 52.2% 的系统服务内部员工，且许多系统有人工监督，因此这一排序反映的是当前部署环境，而不是认为安全不重要。

数据进入系统的方式（图 12(a)，N 约 27 到 29，可多选）：89.7% 从数据库取数，65.5% 接收实时用户输入，51.7% 接收其他实时信号。69.0% 检索机密或敏感数据，只有 34.5% 检索持久的公开数据。医疗智能体案例依靠常规数据处理，以及与模型提供方的严格合同，防止用用户数据训练。

访谈描述四种用约束设计管理安全风险的做法。第一，六个团队把智能体限制为只读，防止改状态。例如一个站点可靠性案例生成缺陷报告和行动计划，最终执行留给工程师。第二，三个团队把智能体放在沙箱或仿真环境，隔离线上系统。一个代码迁移智能体在镜像沙箱里生成并测试改动，软件核验之后才合并。第三，一个团队在智能体和生产环境之间建抽象层，用包装接口挡住内部函数细节。第四，一个团队实施与用户权限一致的基于角色的访问控制。该团队报告这仍然难：当工具或文档的权限互相冲突时，智能体可以绕过这些配置。

#### B.4.2 时延

图 12(b)：只有 14.8% 的已部署调查智能体把时延标成必须立刻解决的关键阻断；多数（59.3%）认为它是边缘问题，当前时延不理想但够部署。作者推测，这与 15/20 的详细案例采用异步执行、以及调查中 52.2% 的内部用户有关。包含实验系统的全量调查里，时延分布一致（图 24(b)）。作者认为这指向更广泛的、建造离线智能体的偏好。

对实时交互智能体，时延仍是关键瓶颈。两个做语音智能体的访谈团队持续投入工程，以匹配人的对话速度。延迟会打断轮流说话。超出僵硬的轮流、做到流畅的实时响应，仍是开放问题。

管理时延的两种做法。一是对最大步数或模型推理调用设硬上限，通常来自经验。二是有一个团队预先建请求类型和智能体动作（工具调用）的数据库，运行时用语义相似度检索相似请求，直接给出预建动作，把响应时间相对“推理再生成新回答”降低数量级。这些变通说明，实践者目前用系统层工程绕过基础模型固有的时延成本。

#### B.4.3 模态

图 13（N=29）对比已经支持的模态（红）和计划支持的模态（蓝）。虚线左侧是预期支持会增加的模态，右侧是已经广泛支持、计划扩展有限的模态。文本主导当前部署：93% 的受访生产智能体接受自然语言文本。非文本模态今天相对有限，但预期增长最大的正是这些还不成熟的模态，例如图像、视频、时空数据和科学数据，全部是非文本。

访谈说明，早期部署优先容易测量、核验和调试的模态。文本智能体有现成评测流程、人工核验和较快的迭代。多模态智能体的正确性信号更弱，基础设施更复杂，数据流水线更贵。团队往往等以文本为中心的部署足够可靠之后，才扩展模态。

附录 C 数据细节

调查共 306 份有效回答，加上 20 场深度访谈，构成这项生产智能体研究的经验基础。

C.1 调查

图 14 概括全部调查数据里的回答者角色、所贡献的系统，以及终端用户数。在报告了部署阶段的人里，82% 表示系统处于文中所讨论的阶段划分之内。部署规模差异大：42.9% 的报告部署服务数百用户，25.7% 服务数万到超过 100 万日活。主文第 4.3 节对已部署子集使用 43% 与 26%。

C.2 深度案例

图 15：基于访谈的深度案例里，来源机构的成熟度。少数（5/20）来自种子期（验证产品与市场契合）、早期（证明可扩展的商业模式）和成长期（快速扩大市场份额和运营）。多数（15/20）来自晚期和成熟机构。

图 16：案例来源出现在一个到数百个国家。图给出按国家覆盖和按大洲覆盖的分布。原图中的国家分布条已入库。

图 16 的国家覆盖原图。横轴为案例来源覆盖的国家范围，具体分档以原图为准。

组织成熟度、地理和大洲覆盖的数字已写入第 3.1 节。案例团队集中在美洲，欧洲较少。

C.3 访谈

访谈程序标准化。每次 30 到 90 分钟，2 到 5 名与参与组织无隶属的研究者，同一协议。提纲覆盖系统架构、评测和部署挑战。开放编码由至少三名研究者独立完成。

招募时间线写在附录里：初始调查和访谈设计始于 3 月，随后 4 月中到 5 月中访谈上游相关方，之后通过面向智能体的技术活动做了三轮招募。主文把研究窗口定为 2025 年 4 月到 11 月，调查发放是 7 月 28 日到 10 月 29 日。

附录 D 全部调查数据

附录 D 把原型和研究阶段系统加回来，对应主文各图，但样本量更大。生产率在全量数据里仍是被选最多的收益（图 18，N=101）。应用领域在全部开发阶段上为 N=105（图 19），仍是多类题，比例加总不为 1。与替代方案的比较率是全部数据 34%，已部署 38.7%。模态上，增长仍集中在非文本；与只看已部署子集相比，全量数据里这一趋势一致，但尚未部署的系统在模态计划上可以不同（图 25，对应图 13）。其余全量图（模型、步数、评测共现、挑战）与已部署子集的方向一致，主文分析以生产和试点为准。

附录 E 术语

为保持一致，作者给智能体执行建立了分层术语。图 26 把第 5 节用的概念和调查定义对齐，说明高层用户目标与智能体细粒度自主动作之间的关系。任务、子任务和步是不同层级，不能混用。

图 26：第 5 节术语的概念图，以及它如何对应调查定义。原图入库。

附录 F 文献综述的范围与分类

表 4 按证据类型组织文献综述中的代表工作。

这三类与 MAP 的差别是：MAP 提供跨组织的、关于技术方法、架构模式和运行实践的系统证据。

附录 G 问卷

问卷经早期实践者讨论迭代修改。为便于广泛参与，作者限制了长度、技术深度和需要披露的深度。题目可选，参与自愿。但越过某些题必须作答或输入。例如，不确认已阅读并理解参与同意声明，就不能继续。图 28 和图 29 分别是核心题和附加题的控制流。

题目面向正在建人工智能智能体的实践者。若回答者对多于一个系统有技术贡献（核心题 N1），后续回答必须聚焦自选的一个系统（确认 G.1）。若本人并不把所贡献的系统称为人工智能智能体或智能体式人工智能，问卷提供术语评论或说明为何开始作答等选项，然后可以提前结束。

G.1 确认

对多于一个智能体系统作答的人，必须先确认：为保持一致，请选择一个智能体系统贯穿全卷；可以选最熟悉的，或最接近生产、用户最多的；欢迎为每个熟悉的系统另交一份。

G.2 题目类型

题型分布见表 5。设计时刻意避免引导回答，并便于后续定量分析。

核心题问这些事，编号与原文一致：

附加题继续问评测、挑战、基线、模型、数据和部署。与主文数字直接对应的几题是：

问卷其余附加题覆盖模型来源、是否后训练、框架、提示长度分档、数据进入方式、时延是否阻断部署、已支持与计划支持的模态。选项与第 5 到 7 节及附录 B 的图一致。图 28、图 29 是分支流程，HTML 中没有独立图片文件。

G.3 每人贡献了几个系统

图 27（N=306）显示多数回答者只贡献一个智能体系统，报告参与多个系统的人较少。因此调查的广度来自不同部署，而不是少数人重复填写。

13 条发现对照

出处：Melissa Z. Pan，Negar Arabzadeh，Riccardo Cogo 等，Measuring Agents in Production，2026-06-04（v4，投稿 2025-12-02），https://arxiv.org/abs/2512.04123，CC BY 4.0。