不要从Agent开始：微软44页企业AI剧本，以及它揭示的真正竞争护城河
不要从Agent开始：微软44页企业AI剧本，以及它揭示的真正竞争护城河
先说结论：微软是全球最大的AI平台供应商之一，但它在一份最新的44页报告里告诉你——你的竞争护城河不应该是你用的是哪个AI模型。
这句话，值得反复思考。
2026年9月17日，微软发布了一份44页的文件，名字叫《Becoming a Frontier Firm: Our Frontier Playbook》（成为前沿企业：我们的前沿剧本）。
它是微软研究了内部100多个AI转型案例后写出来的。
但这份文件最反直觉的地方，不是它揭示了多少成功——而是它承认了多少错误。
第一个错误：把AI当成另一次技术推广
微软首席战略与转型官Kathleen Hogan在配套博文里写了一句话，让我反复读了好几遍：
“我们最初把AI当成一次传统的软件推广——部署技术，培训员工，推动采用——只是发现，访问和使用不一定能产生商业影响。”
这是微软在说自己。
这也是目前市场上99%的企业AI项目正在做的事。
给100000名员工发Copilot许可证，不等于企业转型。这份剧本说得非常直接：”一个授权并向10万名员工推广的工具，并不会改变工作的完成方式。”
我见过太多AI项目的失败，表面原因是”员工不用”或者”准确率不够高”，但真正的原因往往一致：企业在一个”为人类设计的流程”里塞了一个AI，然后期待奇迹发生。
微软把这个陷阱称为”在错误的流程上部署AI”——你自动化的只是一段本不该存在的低效。更可怕的是，AI会让这段低效以更快的速度运行，让组织更难发现问题的根源。
三种方式，谁才是真正的转型
这份剧本把企业AI转型分成了三个层级：
第一层：Persona Acceleration（角色加速）
给特定岗位配备量身定制的AI工具。这是最常见的做法——产品经理用Copilot写PRD，销售用AI总结会议纪要。这层有价值，但它不改变流程的底层逻辑。当AI只是帮你在同样的流程里跑得更快，你改变的只是执行速度，不是竞争位置。
第二层：AI-Powered Process Redesign（AI驱动的流程重设计）
在引入AI之前，先拆解并重建整个工作流。微软认为这是绝大多数企业在”AI代理化”阶段应该专注的层级。它要求企业先问一个很难回答的问题：这个流程，如果重新设计，应该长什么样？
第三层：AI-First Possibility（AI优先的可能性）
从一张白纸开始，假设AI从一开始就嵌入其中，重新发明业务流程。这是最激进的一层，适合新业务或愿意彻底颠覆现有流程的团队。
微软的核心建议是一句话，他们叫它”先精简再代理”（Lean before agents）：
在部署Agent之前，先把底层流程图绘出来，去掉不必要的审批和交接，建立共享数据基础，明确哪些决策该由人类做，哪些可以交给代理——然后才考虑引入Agent。
这个顺序很重要。大多数企业跳过了”精简”，直接到了”代理”。这是2026年企业AI项目最普遍的失败模式：还没弄清楚流程应该长什么样，就开始选择Agent框架了。
供应链：从10天到2.5天（第二层转型的典型案例）
这是第二层转型——AI驱动的流程重设计——在实践中的样子。
微软在云供应链组织里部署了111个专用Agent，覆盖计划、采购、履行和物流四个环节。
这不是突然发生的。在部署Agent之前，一个跨职能团队先花时间梳理并简化了工作流，建立了一个单一的”真相来源”（single source of truth），让Agent在推理时有可靠的数据基础。
这些Agent可以调查需求变化、建模产能、比较陆运/空运/海运的多维度成本和时效，在设定的权限范围内直接帮助规划人员更新或取消采购订单。
结果：
- 选定供应链工作流的平均周期时间缩短了75%——从约10个工作日降至不足2.5天
- 过去5个月（2026年4月至8月），每月20多次需求计划调查：之前需要5至7天产出一份人工验证的解释，现在不到几小时，部分调查在20分钟内完成
微软自己也强调这些数字来自特定工作流和测量周期，不代表通用企业基准。但背后的架构经验比百分比更有价值：
当底层共享数据、编排、遥测和治理层做对了，Agent本身反而变成了最不重要的那部分。可见的Agent只是整个系统的前端；支撑它的数据基础和编排能力，才是决定成败的地方。
9人团队，35天，18600次提交
剧本里有个更极端的案例。
微软产品开发组织里，一个9人团队被放进了一个”沙盒”，被告知从零开始以AI优先的方式构建产品Copilot Cowork——而不是在已有工程流程上加AI。
这个团队建立了一套规格驱动工作流，由三个要素构成：
- 规格（Specs）：描述意图——你想让Agent做什么
- 评估（Evals）：定义什么是好的输出——Agent什么时候算做对了
- 上下文（Context）：提供给Agent的信息——它需要什么背景才能正确推理
团队成员逐渐演变成微软所谓的”元工程师（meta-engineers）”、”元设计师（meta-designers）”和”元产品经理（meta-PMs）”——他们的主要工作是设计Agent、编写规格和评估标准，而不是亲自写功能代码。
35天内的产出：
- 18600次代码提交，平均每天123次
- 930万行代码
- 完成初始产品发布
微软随后补充说，提交数量不应与产品质量直接等同。但这套规格驱动架构本身传递了一个清晰的信号：当人类的角色从”写代码”转向”定义意图和评估标准”，工程组织的生产力曲线会有质的变化。
最重要的洞察：你的护城河不应该是模型
现在到了这份剧本最有战略价值的部分。
微软说，企业应该避免将任何特定基础模型置于架构核心。
相反，企业的持久竞争优势应该来自于：
- 私有评估框架（Private Evals）：你如何判断模型输出的好坏，以及如何量化”好”的标准
- 专有上下文（Proprietary Context）：只有你的企业才有的数据和知识——客户历史、内部流程文档、行业专有数据
- 工作流编排（Workflow Orchestration）：你如何把AI嵌入业务流程，以及如何协调多个Agent协作
- 反馈循环（Feedback Loops）：你如何从每次Agent运行中学习并改进系统
- 机构知识（Institutional Knowledge）：可以在更换底层模型时存活下来的核心资产
这是微软在说：你绑定的不应该是GPT-6 Astra，也不应该是Claude Fable。这些模型半年后都会有新版本，甚至会被后继者取代，定价可能大幅下降。
你真正应该投资的，是那些在任何模型下都能让你比竞争对手跑得更快的能力体系。
这对于一家出售Azure OpenAI服务和Microsoft 365 Copilot的公司来说，是一个相当反直觉的建议。但它是正确的。
如果你的竞争优势依赖于你比竞争对手更早拿到GPT-6 Astra的访问权，那这个优势会在所有人都能访问它的那一天消失。真正的护城河，是你那套别人无法复制的私有评估标准和领域上下文。
“人类主导、Agent执行”的三层自主模型
微软提出了企业内部AI自主性的三级模型，用来描述人类与Agent的协作关系如何随时间演进：
第一级（Level 1）：员工与AI助手协作。人类主导，AI提供建议和加速。
第二级（Level 2）：Agent成为人机团队的成员，在人类指导下承担特定任务，有明确的问责边界。
第三级（Level 3）：微软称之为”人类主导、Agent执行（human-led, agent-operated）”——人类设定方向和边界，Agent执行整个业务流程，必要时才向人类汇报或请求批准。
向上一级移动需要的不只是更好的模型，还需要：
- 更强的数据和基础设施准备度（Agent需要可信赖的数据才能做好判断）
- 明确定义的风险边界（哪些决策Agent可以自主做，哪些必须人工审核）
- 人类角色的主动重新设计（人类需要适应从”执行者”到”监督者”的转变）
软件工程这个领域可以同时跨越三个层级——开发者可能用AI助手做代码补全，同时将整个测试流程委托给自主测试代理，同时又在需求拆解环节保留人工决策权。
这个三级模型的价值不在于”我们要达到第三级”，而在于它迫使企业的每个业务部门思考：我们目前在哪一级？我们应该在哪一级？从当前到目标需要什么条件？
这份剧本在说什么
让我换一种方式总结：
微软告诉你，它在AI转型上走过的弯路，正是大多数企业今天还在走的路。把AI当成工具推广，不叫转型。测量许可证数量和使用率，不叫ROI。在错误的流程里加速，只会更快地到达错误的结果。
真正的转型是在引入AI之前先回答三个问题：
- 这个流程本身应该存在吗？
- 如果重新设计，它长什么样？
- 在这个重新设计的流程里，哪些决策应该由人来做？
然后，才是Agent。
这份剧本有一个更深的层面，是微软没有直接说出来但字里行间都在传递的信息：AI转型的失败，通常不是技术问题，是架构决策问题。
你把Agent放在哪里，它就会自动化那里。如果那里的流程本来就是错误的，AI会以更快的速度放大那个错误。
对中国企业的额外启示
微软的案例有一个特别值得关注的细节：111个专用Agent，覆盖计划、采购、履行和物流——这是真实生产环境部署，不是POC。
对比国内目前绝大多数企业AI项目的现状：大量停留在POC阶段，无法规模化，原因几乎总是”数据孤岛”和”流程不标准”。
微软给出的答案不是”先解决数据，再做AI”，而是”在引入AI的同时重新设计流程和数据架构“。这两件事是同步发生的，而不是顺序发生的。先等数据治理完再做AI，意味着永远不会开始。
此外，微软的模型无关（model-agnostic）视角对国内企业尤为重要：在国内同时面对境外顶级模型的访问限制和国内模型的快速迭代的背景下，把护城河建在私有评估框架和领域上下文上，而不是绑定任何单一模型，是更具韧性的策略。
一个值得追问的问题：微软为什么这样说？
这是这份报告里最耐人寻味的地方。
微软出售的是Azure OpenAI服务、Microsoft 365 Copilot许可证、以及所有与AI相关的云基础设施。从商业角度说，微软最符合利益的建议应该是：”快买更多的AI许可证，快部署更多的Agent。”
但它说的恰好相反：别急着部署Agent，先精简流程；不要把某个模型作为架构核心，要把自己的私有评估和工作流编排作为护城河。
有两种解读方式：
悲观解读：这是更高明的锁定策略。当企业把私有评估框架和工作流编排都建在Azure之上，迁移成本会比仅仅锁定在某个模型API上高出一个数量级。微软在用”model-agnostic”包装一个更深层的平台锁定。
乐观解读：微软确实看到了自己在内部AI转型中走过的弯路，选择了真诚地分享。毕竟100多个内部案例不是虚构的，75%的供应链效率提升是可验证的。
两种解读并不互斥。最可能的答案是，这两者同时为真：微软有真实的转型经验值得分享，同时这份分享也巧妙地指向了它希望企业深度使用的那层基础设施（编排、数据、评估框架）。
即使如此，这份建议的内容仍然是正确的。
结语：44页剧本的核心就是一句话
当所有人都在问”你们用的是哪个模型？”的时候，微软在说：这是错误的问题。
正确的问题是：”你的流程值得被自动化吗？”
然后，才是模型的问题。
如果这份44页的剧本要浓缩成一条可执行的行动建议，我认为是这样的：
今天就在你的组织里找一个流程，不是”如何用AI做这件事”，而是”这件事如果重新设计，应该长什么样”——然后才考虑AI的角色。
这比买任何模型许可证，都更值钱。
参考资料
- Microsoft releases new AI playbook for enterprises with real-world examples — VentureBeat, 2026-09-17
- What AWS’s chief AI and technology officer told employees about the future of AI — About Amazon, 2026-09-17
- Microsoft Blog: Kathleen Hogan, Chief Strategy and Transformation Officer — “Why Microsoft is becoming a frontier firm”, 2026-09-17（通过VentureBeat引用）