奔驰如何用 AI Agent 改造缺陷管理：企业 AI 的关键不是模型，而是上下文

过去几年，基础模型的发展速度令人震惊。

本世纪初，AI 还只能简单搜索网络信息；而今天，它已经能够完成一些过去需要工程师投入一个多小时才能完成的工作。尤其是在过去 18 个月里，AI 能力正在快速跃迁。

但与此同时，一个看似矛盾的现象正在发生。当你问个人用户：“AI 工具有没有帮助你提高效率？”超过 50% 的人会回答“有”。他们认为 AI 确实帮助自己节省了时间和精力。但当你把视角扩大到企业层面，结果却完全不同。96% 的企业表示，他们还没有看到 AI 对业务产生显著改善。技术已经存在，但企业级价值却迟迟没有真正释放。

奔驰最近的一次 AI 实践说明了一个关键问题：企业 AI 的难点，从来不只是 AI 能不能生成内容，而是 AI 能不能连接真实工作的复杂环境——包括工具、团队、数据和决策。

企业 AI 的真正瓶颈，不是模型能力

很多企业在部署 AI 时，都默认一个逻辑：更强的模型 = 更高的效率。

但真实情况并没有这么简单。企业里的工作，本质上是协作。如果 AI 只把工作理解为一个人的任务，它永远无法发挥真正的价值。大型企业平均使用超过 367 个 SaaS 应用。

原因很简单：不同团队有不同工具，不同流程，也有不同工作习惯。

当团队需要协作时，员工经常需要：在不同系统之间切换；理解不同团队的规划方式；寻找散落在不同工具中的背景信息；重新确认过去做过的决策。

最终，一个团队制定目标，另一个团队可能正在执行完全不同的方向。不是因为大家不努力，而是因为信息没有真正连接起来。

奔驰产品经理 Tobias Langjahr 这样描述：

“完成一个任务，你可能至少需要使用 11 个以上的工具。甚至在公司里，需要维护、使用和理解的数据工具可能达到 100 个、300 个以上。你需要不断从这些系统中获取数据，再用于下一项工作。这真的非常痛苦。”

AI 加入之后，并不会自动消除这种复杂性。甚至可能进一步放大问题。例如：一个代码 Agent 如何获得足够的项目背景，而不会给团队增加额外沟通成本？一个设计 Agent 如何和另一个平台上的开发 Agent 协同？如果没有统一的上下文层，最终得到的只是：更快生成内容，但仍然需要大量人工检查和返工。

奔驰如何重新思考汽车缺陷管理？

对于奔驰来说，质量一直是品牌核心。但现代汽车的竞争已经不仅仅取决于机械制造，而越来越依赖运行在汽车中的软件系统。如今，一辆智能汽车每天都会产生大量数据：车辆传感器数据；测试环境数据；开发系统数据；软件运行日志。

真正的挑战不是有没有数据，而是如何让这些数据进入工程师真实工作的流程。

和很多大型工程组织一样，奔驰发现：工程师完成一个任务，需要使用 11 个甚至更多工具，而整个公司内部正在使用超过 300 个工具。大量时间消耗在：寻找信息；切换系统；复制上下文；确认负责人。

这些时间，本应该用于真正重要的事情：制造更好的产品。

奔驰希望改变缺陷管理流程。过去，当测试工程师发现车辆问题时，整个流程高度依赖人工。工程师需要：记录问题；填写缺陷信息；描述发生环境；提交 ticket。之后，缺陷管理员还需要人工判断：这个问题属于哪个团队？谁应该负责？是否已经存在类似问题？很多时候，仅仅找到正确负责人，就需要经过多轮沟通。而问题解决之后，相关经验和背景信息又往往停留在孤立系统中，其他团队无法复用。

用 Teamwork Graph 连接工程世界

奔驰意识到：如果能够把不同数据源连接起来，就可以重新设计整个缺陷管理生命周期。于是，他们通过 Atlassian Teamwork Graph 连接：IBM Doors 中的需求数据；代码仓库；发布管理信息；零件和资产数据；测试车辆产生的实时日志数据。

当这些信息通过 Teamwork Graph 被连接后，一个缺陷背后的完整关系链开始形成：这个问题对应哪个需求？哪个代码实现了相关功能？在哪辆车、哪种配置中出现？之前是否发生过类似问题？这些信息不再是分散的数据点，而成为一个可以被 AI 理解的上下文网络。

“Norris 家族”：奔驰的 AI Agent 团队

有了数据连接之后，奔驰进一步解决一个非常实际的问题：工程师如何更方便地提交缺陷？

想象这样一个场景：一名工程师正在德国高速公路 Autobahn 上测试车辆。车辆屏幕突然出现错误提示。此时，他不可能安全停车，打开电脑，填写一份详细缺陷报告。但如果等回到办公室，他又可能忘记关键细节。于是奔驰构建了一组 Rovo AI Agent，被团队内部称为“Norris 家族”。其中包括：

• Defect Norris负责缺陷入口处理，帮助整理和结构化问题。

• Analyze the Snores连接中央数据平台，获取车辆日志和遥测数据。

• 第三个 Agent负责跨车型分析，判断一个车型的问题是否可能影响其他共享组件的软件。

• Main Norris负责法规和安全相关上下文。

这些 Agent 共同改变了缺陷管理方式。

从填写表单，到直接说出来

奔驰解决的一个关键摩擦点，是缺陷录入本身。他们开发了一套车载语音应用。工程师只需要在驾驶过程中，用自然语言描述问题。系统会：将语音转换成文字；关联车辆识别编号；直接发送到 Jira。随后，Defect Norris 接管流程。它会把最初简单的一句话描述，转化成完整的缺陷记录：补充元数据；识别相关组件；关联车辆数据；生成结构化信息。

过去需要人工整理的信息，现在由 AI 自动完成。

结果：缺陷处理周期降低 70%

奔驰最终取得了明显效果。通过衡量“发现缺陷”到“完成修复”的周期，他们实现了相比过去流程减少 70% 的处理时间。他们从新一代 S-Class 开始测试这一模式，并在正式上线前建立了清晰基准。

背后的逻辑其实很简单：让提交缺陷变得越容易，发现的问题就越多。而这是一件好事。

因为过去企业害怕大量问题进入系统，是因为人工处理成本太高。但当 AI 可以自动完成：信息补充；重复检测；责任分配；优先级判断。工程师就可以把精力集中在真正需要专业判断和创新的问题上。

企业 AI 真正需要什么？

奔驰案例说明了一件重要事情：企业 AI 的价值，不在于让个人更快完成任务，而在于让整个组织更聪明地协作。

要实现这一点，AI 至少需要三个条件。

1. 更丰富的上下文

提供给 AI 的上下文越完整，结果越准确。比如，你让 AI 帮你准备一次客户会议。它不仅需要知道客户名字，还需要了解：过去类似客户的决策模式；当前合作状态；团队目标；历史沟通记录。上下文决定 AI 能否真正理解问题。

2. AI 不只是回答问题，而要参与工作流

真正有价值的 AI，不只是告诉你答案。它应该能够：生成周报；创建页面；通知相关人员；处理进入系统的任务。

这些动作，才能真正释放人的时间，让人专注于更高价值的判断工作。

3. 企业必须拥有安全和权限控制

当 AI 开始代表员工行动时，权限非常重要。如果一个员工没有权限查看某个 Jira ticket，那么 AI 也不应该知道它存在。企业 AI 的未来，不只是能力问题，也是治理问题。

为什么 Atlassian 构建 Teamwork Graph？

这也是 Atlassian 推出 Teamwork Graph 的原因。

每个行业都有自己的工具和流程。一家金融企业可能需要连接贷款审批系统；一家航空企业可能需要连接项目管理平台；一家互联网企业可能需要连接自研销售系统。因此，企业需要的不只是一个 AI 模型，而是一层能够连接各种业务上下文的基础设施。

目前，Atlassian 平台已经提供超过 100 个开箱即用的连接器。企业也可以构建自己的连接器，把专有系统和旧系统中的数据接入 Teamwork Graph。一旦数据进入这个图谱，它就可以：被搜索；被分析；被 Agent 调用；支持企业自定义应用。

未来的企业 AI，不是替代人，而是减少寻找

奔驰的案例揭示了一个趋势：未来企业 AI 的竞争，不只是模型能力的竞争。真正重要的是：谁拥有更完整的组织上下文；谁能连接更多工作系统；谁能让 AI 理解真实业务。未来的 AI Agent，不应该只是一个聊天机器人。它应该知道：事情为什么发生；谁参与其中；过去做过什么决定；下一步应该如何推进。

Mike Cannon-Brookes 曾提出一个公式：加速能力 = 上下文 × 智能

智能是发动机，但上下文才是燃料。AI 时代，企业真正需要建设的，不只是更强的模型能力，而是让 AI 能够理解组织运行方式的上下文能力。因为最终，AI 的价值不是生成更多内容。而是帮助企业减少寻找信息、协调人员、连接工具的时间，把更多精力投入真正重要的工作。