一家 170 年老牌企业的速度焦虑
Levi Strauss & Co. 已有超过 170 年历史，长期处于文化、工艺与商业进步的交汇点。近年来，公司将战略重心转向直面消费者（DTC）零售模式，这意味着从产品设计到门店运营的每一个环节都需要更快的信息流转和更短的决策周期。
然而，内部现实与战略目标之间存在明显落差。团队的数据分散在多个来源中，查找信息和完成复杂工作流变得困难。设计师需要综合多年的消费者研究，财务团队需要从复杂数据集中提取洞察，HR 需要理解员工体验的深层趋势——这些需求分别依赖不同的系统和流程，没有统一的入口。
公司首席数字与技术官 Jason Gowans 将问题归结为速度："作为一流的直面消费者零售商，对我们来说最大的变化是我们需要运营的速度。这不仅仅是一个工具的问题——这是一场全面的工作方式变革。"这句话揭示了决策层的核心判断：问题不在于缺少某一个系统，而在于系统之间的割裂拖慢了整个组织。
从 Copilot 到专用智能体：分阶段的技术路径
Levi Strauss 的 AI 路径并非一步到位。公司首先在全企业部署了 Microsoft 365 Copilot，让员工在日常办公工具中接触 AI 能力。Copilot 被用于帮助设计师综合多年研究、帮助财务团队提取复杂数据洞察，并帮助 HR 探索员工体验。与此同时，工程团队将 GitHub Copilot 与 Foundry 构建的智能体配合，用于系统现代化、加快开发和提升人才技能。
这种分阶段路径的逻辑值得注意：先让员工在熟悉的办公环境中建立对 AI 的使用习惯，再引入连接后端系统的专用智能体。高级总监 Jennifer Patchen 评价 GitHub Copilot 时说："我们知道它真的会以一种丰富而强大的方式增强我们的工程师，并成为他们的力量倍增器。"但随着越来越多的专用智能体被引入，一个新问题浮现：员工面对的入口太多了。
编排层的设计选择：为什么不微调
Levi Strauss 在技术路线上做了一个明确的取舍：优先采用编排而非微调。公司使用由结构化提示、意图检测和推理工作流引导的专用智能体，Microsoft Foundry 充当编排层，让团队设计、测试和演进能够理解意图并连接企业系统的智能体。
这一选择的含义是：公司不为每个业务场景训练定制模型，而是通过编排多个专用智能体来覆盖不同领域。智能体按用户身份安全连接 SAP、HR 和零售系统，并访问实时、受治理的数据，不创建重复的影子数据存储。后端执行层运行在 Azure Functions 上，以支持可扩展、事件驱动的智能体工作流。
源文将支撑 Super Agent 体验的平台描述为由三个基础层共同构成：企业系统连接层负责安全访问实时数据；智能体编排层通过 Foundry 和 Agent Framework 协调意图路由与工具选择；后端执行层在 Azure Functions 上运行事件驱动的工作流。这种分层设计的意图是让新智能体可以在同一基础上扩展，而不需要为每个场景重建基础设施。
Super Agent 的计划逻辑与实施边界
Levi Strauss 已提出在 Microsoft Teams 内创建统一 Super Agent 的计划。按源文的描述，员工将通过单一入口用自然语言提问并立即获得结果。Super Agent 的计划职责包括理解员工意图、路由到底层智能体、连接跨系统数据工作流并交付结果。
源文给出了一个具体的使用场景：一位财务负责人可以通过一条 Teams 提示请求去年预算支出的分类视图，Super Agent 会将请求路由到对应的领域智能体，从记录系统拉取实时数据，并返回一个可信答案。Azure 基础使智能体能够跨地区和角色一致运行。
需要说明的是，源文对 Super Agent 的描述始终使用计划时态（"will provide""will route""will pull"）。这意味着截至官方材料发布时，Super Agent 可能仍处于规划或早期试点阶段，而非全面生产部署。官方材料未披露 Super Agent 当前覆盖了多少员工、地区和业务角色，也未说明自然语言查询的准确率、延迟或拒答率。
对于任何希望复现此类项目的团队，以下实施细节是必须验证但 Levi Strauss 官方材料未披露的：当多个数据源对同一查询返回冲突结果时，系统如何选择"一个可信答案"？是否存在人工审批或升级节点？智能体在查询失败或返回低置信度结果时的回退方式是什么？答案是否附带来源引用以供用户验证？ESS、SAP 和 Retail Agent 的权限边界、审计日志和版本控制如何实施？这些问题不影响 Levi Strauss 方案的方向价值，但决定了实际落地的可靠性。
没有数字的结果：如何理解这个案例的证据边界
与许多 AI 案例不同，Levi Strauss 的官方材料没有披露任何量化业务结果。没有搜索准确率、响应时间、采用率、节省时间或决策周期的数值。源文提供的是定性的流程描述——"减少复杂性""加速决策""实时访问洞察"——但这些表述没有附带基线对比、观察窗口或统计口径。
这并不意味着案例没有参考价值。Levi Strauss 的价值在于它展示了一家大型传统企业如何从"先部署通用 Copilot"过渡到"用 Foundry 编排专用智能体"，再规划"统一入口的 Super Agent"。这个三阶段路径本身就是一种可参考的实施策略。但读者需要清楚：目前无法从官方材料中判断这条路径已经产生了多大的实际效果。
迁移判断：谁可以参考这条路径
Levi Strauss 的路径适合已经完成云基础设施迁移（尤其是 SAP on Azure）、拥有多个独立业务系统、且员工日常使用 Microsoft Teams 的大型企业。其"编排优先于微调"的策略降低了模型训练的前期投入，但对企业数据治理的成熟度要求很高——智能体需要按用户身份访问受治理的实时数据，这意味着权限体系、数据质量和 API 接口必须在智能体上线前就绑定到位。
对于中小型企业或数据治理尚未成熟的组织，直接复制"Super Agent 统一入口"的方案风险较高。更务实的起点可能是 Levi Strauss 路径的第一阶段：先在办公工具中部署通用 Copilot，观察哪些场景的使用频率和用户反馈最强，再决定是否为这些场景构建专用智能体。
最后，由于官方材料未提供任何量化结果，任何基于此案例的投资决策都不应以"已验证的效率提升"为依据，而应将其视为一种架构参考和阶段规划参考。在 Super Agent 的生产数据和独立评估出现之前，"一个可信答案"仍然是一个承诺而非一个已证实的能力。
补充信息与证据说明（1）
本文基于 Microsoft 客户案例页面（2025 年 6 月发布）的单一官方来源撰写。所有企业事实、引语和技术描述均可追溯至该来源。
官方材料未披露任何量化业务结果（搜索准确率、响应时间、采用率、节省时间、决策周期等）。正文中的定性效果描述（"减少复杂性""加速决策"）保留了源文原始表述，不代表 DataHub 对实际效果的判断。
Super Agent 在源文中以计划时态描述（will provide / will route / will pull），其当前部署状态（规划、试点或生产）未明确。正文中所有涉及 Super Agent 的段落均保留了这一时态区分。
文中标注为"官方材料未披露"的内容（权限机制、审计日志、回退方式、来源冲突处理、答案可追溯性等）是 DataHub 基于实施可理解性要求提出的验证清单，不代表 Levi Strauss 未实施这些机制。