Levi's Store App: 17 AI Agents Reduce 9 Months of Work to 2.5 Months

多个 AI 代理同时修改同一份代码，难道不会彼此冲突导致一片混乱吗？企业能够安全引入此类系统，其关键并非在于代理的“智能”，而在于防止冲突的“结构”。实际上，Levi Strauss & Co.（利惠公司）在其门店应用开发中投入了 17 个专业化 AI 代理，将原本耗时 9 个月的开发周期缩短至约 2.5 个月。所有拉取请求（Pull Request, PR）均由 5 至 11 个独立代理进行审查并自动提交修改，同时设定最终合并（Merge）必须由人工批准。

要安全地同时运行多个代理，需要三重安全装置：隔离、权限分离以及人工批准。GitHub 正通过“Git 工作树（Git Worktree）”将这一原则应用于 Copilot 应用的并行会话，并通过“Safe Outputs（安全输出）”将其应用于代理化工作流。本文将具体探讨这三项机制如何避免混乱并确保并行工作的可靠性。

代理并非服务器，而是“文本指令”

人们通常容易将 AI 代理想象成在高规格服务器上独立运行的复杂程序。然而，Levi Strauss 高级总监 Jenny Patchen 在 2026 年 10 月的 GitHub Universe 2026 大会上分享的实际案例比这更简单、更透明 ¹, ²。在 Levi 的开发环境中，代理并非可执行文件，而是存在于 Git 仓库特定文件夹中的 Markdown (.md) 文本文件。

这些 Markdown 文件中包含了告诉代理应该做什么的指令。开发人员可以直接编辑这些文本文件来改变代理的行为。就像修改普通应用程序代码一样调整代理的特性，并且变更通过 PR 由同事审查，从而进行版本控制，流程与修改现有代码完全相同 ²。换句话说，代理不是黑盒，而是可通过文本进行控制开发工具，这使得企业能够精细地管理 AI 的行为。

第一重装置：通过工作树阻断物理冲突

当多个代理开始运行时，最先令人担忧的是文件冲突。如果代理 A 修改文件后，代理 B 紧接着覆盖同一文件，代码必然会变得一团糟。为了解决这个问题，GitHub 在 Copilot 应用的并行会话中应用了“Git 工作树（Git Worktree）”功能。

在 GitHub 官方博客介绍的“tailspin-toys”示例中，这种方式被比喻为“在自助洗衣店里同时运行多台洗衣机” ³。这意味着可以按所需设置分别运行每台洗衣机（会话），而无需等待一台洗衣机完成即可立即启动另一台 ³。

即使多台洗衣机同时洗涤，每台洗衣机都使用其独立的物理空间，因此不会相互干扰。因此，即使代理们同时执行功能开发、代码审查和测试运行，也不会发生物理文件冲突。此外，开发人员在切换上下文时可以直接续接每个会话所保持的最后状态，从而减少等待时间 ³。

第二重装置：通过 Safe Outputs 实现权限分离

即使工作空间隔离且没有物理冲突，如果多个代理可以随意向仓库写入和修改文件，仓库仍可能迅速陷入混乱。因为 AI 可能会失控，生成大量无意义的文件。为了防止这种情况，GitHub 引入了名为“Safe Outputs（安全输出）”的精细权限分离结构。

在 Safe Outputs 结构中，代理本身不能拥有直接向 Git 仓库写入文件或执行命令的“写入权限” ⁴。当代理在工作中发现问题或需要修改代码时，它仅以结构化输出的形式向系统留下“请注册此问题”或“请修改此代码”之类的“请求” ⁴。实际的文件生成或代码修改等“执行”操作，则由被赋予严格单独权限的后台任务代为完成 ⁴。

这一体系充当了防止不可控 AI 失控的安全网。即使在默认设置中代理可以自动访问“create-issue（创建议题）”功能，也严格设置了执行次数上限（max: 1），以防止陷入无限循环 ⁴。此外，利用“depends-on（依赖）”条件，还可以进行顺序控制，如果前序任务未完成，则使后续任务进入等待状态 ⁴。

第三重装置：保留人类的决策权

即使通过技术隔离和权限控制建立了安全机制，对最终结果的责任仍应归于人类。Levi Strauss 在进行门店应用改版时，部署了 17 个专业化代理，分别负责需求编写、测试执行、安全扫描等任务 ²。这些代理承担了开发生命周期中整体的“执行”工作。

然而，该流程的核心原则是“代理执行，人类决策” ²。尽管这 17 个代理与外部工具联动修改代码并完成提交，但在应用于生产环境的最终“合并（Merge）”阶段，设计上要求必须经过人的确认和批准 ²。

通过消除原有流程中 6 种角色之间多达 12 次的任务交接和等待时间，提升了开发速度，同时明确地将项目最终批准这一决策权和责任保留给开发人员 ²。

跟随实际工作流

可以将这三项装置结合起来，通过一个功能添加过程来观察它们在实际开发环境中是如何协同工作的。观察这一过程可以看出，AI 并非仅仅通过快速打字来节省时间。

首先，需求代理确认新功能请求，并以 Markdown 格式编写供开发人员审查的规格草案。当人确定该规格的优先级并批准后，构建代理基于此编写实际代码并创建 PR ²。

5 到 11 个独立的审查代理同时访问生成的 PR，发现问题时直接在代码行上留下评论或修改代码并提交到分支 ²。在最后阶段，开发人员一目了然地查看多个代理留下的评论和自动修改的结果，然后最终点击合并按钮。

最终，Levi Strauss 的 Back Pocket 应用开发周期从约 9 个月缩短至 2.5 个月 ²。这并非因为 AI 提高了人类编写代码的速度。相反，这是通过让各专业代理消除等待时间并行处理任务，从而在结构上压缩了整个流程所需时间的结果。在复杂的多代理协作时代，与其仅相信 AI 的自主性，不如铺设受控的轨道，这才是保护企业环境安全的实际方法。