当Agent不再孤立AgenttoAgent协作如何重构企业AI应用架构20260727

从工程优化到Agent经济体：企业级AI落地范式转移与组织重构 摘要 ●多智能体协作正从封闭式工程问题转向开放式经济学问题，核心在于建立动态准入、交易与合约机制，构建Agent经济体(Agent Economy)。·北美编程领域Agent落地极快，手写代码时代基本结束；但企业整体效率受限于传统组织架构产生的信息壁垒与跨部门决策瓶颈，尚未实现财务指标层面的传导。●AI原生组织(AI-native)的范式应从“人为主、AI辅助”转向“默认Agent完成、人负责授权”,通过消除人为干预壁垒提升Agent在线执行时长。·Palantir的FDE模式是解决B端落地“最后一公里”的关键，通过深度整合业务逻辑建立数据飞轮，形成极高的供应商更换成本与护城河。·Agent演进路径：工具->24小时运行的协作者(Co-worker)->互联网络；Co-worker模式将带动Token消耗量实现10-100倍增长。·Agent互联网(InternetofAgents)将替代传统Web搜索，实现毫秒级信息共享与资源交易，Agent将作为代理主体重塑现有基础设施与经济体系。 Q&A 您曾于2025年年中离开AWSAI实验室并创立仙台AI,请问当时是什么样的行业变化或判断，使您认为多智能体协作是下一阶段的核心发展方向? 我在亚马逊负责的最后一个产品是多智能体协作平台，这是当时北美市场首个托管在云端、专注于多智能体协作的平台。在此期间，我们观察到强烈的企业需求，尤其来自中大规模的金融相关企业。然而，当时平台存在一个核心问题：其协作模式是封闭的。一个产品上线后，其内部的智能体数量是固定的，这种模式难以适应高复杂度或实时变化的需求。例如，要组建一个能分析标普500中任何一家公司的多智能体团队，封闭式协作或许能处理对单一特定公司(如星巴克)的分 析，但无法应对任意公司的动态分析需求，因为市场条件和需要考量的因素每天都在变化。这引出了开放式协作的必要性。与封闭式协作不同，开放式协作无法预先设定固定的工作流，因为协作的参与者是动态变化的，就像一个交易所，无法预测明天的交易对手是谁。因此，其核心不再是定义工作流，而是建立协作规则或运作机制。这包括准入和退出机制，即决定哪些智能体可以在特定时间加入或离开团队。这种转变将多智能体协作从一个工程问题(定义工作流)提升到一个经济学问题(定义协作规则)。我们认为，未来的多智能体协作将涉及成百上千个智能体，而通往这种超大规模协作的必经之路，正是构建一个开放式的协作体系。这是我决定创业的最主要原因。 从封闭式协作到开放式协作，其核心难点是什么?为何AWS当时未能构建一个更开放的系统? 封闭式与开放式协作的区别并非简单的复杂度差异，而是范式上的根本不同。封闭式协作本质上是一个工程问题：在成员和目标都确定的前提下，通过优化工作流来更高效地解决某一类特定问题，例如处理客户投诉。而开放式协作则旨在构建一个由智能体构成的经济体(AgentEconomy)。在这个体系中，不仅可以调度公司内部的智能体，还可以引入外部公司甚至竞争对手的智能体，从而形成竞争机制。这就需要设计交易和合约机制，让参与协作的智能体能够根据其贡献获得相应报酬。因此，开放式协作解决的是如何定义这个经济体系的范式与规则。一旦这个范式得以建立，我们就能创建一个自由度极高且系统健全的协作体系，它不会因为单个智能体能力的缺失而崩溃。 当前企业在规模化落地Agent应用方面似乎进展相对缓慢，您认为主要的瓶颈在于模型能力、工程化水平、商业激励机制还是基础设施? 关于企业Agent落地速度缓慢的结论，我认为需要分情况看待。在北美市场，许多公司的Agent落地速度非常快，甚至超过了以往任何技术的应用速度。尤其在编程领域，Agent的应用已相当普及。无论是初创公司还是大型企业，许多工程师的日常工作已经从手写代码转向以AI辅助编程为主。例如，我们公司内部禁止工程师手写代码，必须使用AI编写。AI的辅助也推动了像Rust这类对人类不友好但安全性高的底层编程语言的普及，工程师可以通过与AI对话的方式完成编码。可以说，手写代码的时代基本已经过去。然而，从更高层面来看，尽管工程师个体每天都在使用Agent完成工作，但这对于提升企业整体的日常运营效率，其影响确实还存在较大局限。 尽管AI模型在编程方面展现出强大的能力，但为何在企业层面，这种效率提升似乎并未完全传导至整个公司的运营流程? 当前AI模型在编程方面确实能力很强，但并不能解决所有问题。企业整体的执行速度并非完全由工程师的编码速度决定，其中包含了许多复杂的因素，甚至包括外部依赖。例如，一个软件开发完成后需要通过Windows的官方签名认证才能 上架，这个流程的速度是AIAgent无法加速的。更深层次的原因在于，即使工程团队的编码速度因AI Agent而大幅提升，他们也常常在流程中遇到瓶颈。这主要是由公司组织架构决定的。许多公司的架构并非以工程团队为核心，而是按地区、产品线等维度划分。在产品线下，又细分为产品、设计、测试、工程、市场等多个团队。因此，一个产品的开发、推广及数据反馈流程是由多个团队共同决定的。单纯提升工程团队的编码速度，并不能实质性地加速整个公司的产品周期，除非对现有组织架构进行彻底重构，以一种AI原生的方式重新调整。然而，鉴于当前模型的能力边界尚不完全清晰，这种重构的风险非常高。此外，组织架构的问题也导致了AI Agent在应用中缺乏必要的上下文。一个Agent在封闭的工程环境内可能拥有所有技术上下文，但它无法获取市场、法务或决策层的上下文信息。当任务推进到某个节点需要跨部门决策时，Agent就会被卡住，无法独立做出有效决策，这使得人依然必须作为信息传递和决策的中间件。因此，组织架构的限制和由此导致的上下文缺失，是制约AI Agent效率向上层传导的主要原因。 根据您的观察，当前AI模型的编程能力是否已经足够，或者说其潜力尚未被充分发掘? 从编程的角度来看，当前模型的能力是足够使用的。然而，问题在于，即便我们假设推翻现有公司架构，将与某一产品相关的所有人员和信息流打通，AI Agent是否能真正实现产品开发效率的巨大飞跃，目前仍缺乏有力的实践证明。尚未有公开案例表明，通过这种方式重构后确实取得了预期的成功。这其中存在许多未知数。即便是我们这样规模的公司进行了成功的尝试，其数据点对于大型企业而言，也仅能作为有限的参考，不足以促使它们为了一个尚不明确的回报，而去承担打破现有成熟组织架构所带来的可预见的巨大风险。 大型企业在何种条件下才可能愿意尝试调整其组织架构以适应AI,或者它们是否会选择其他非组织架构调整的方式来落地企业级Agent? 预测大型企业何时会进行组织架构调整非常困难，这在很大程度上取决于决策层的决心。如果决策层对AI持非常积极的态度，他们可能会愿意承担风险进行尝试，例如在某个产品线上进行试点。这种尝试最坏的结果是组织调整失败，但如果成功，其经验便可以推广到其他产品组。要促使这种转变，可能需要两个关键要素的成熟。第一，模型能力的进一步提升，尤其是在处理多样化、跨领域上下文、长期记忆以及抑制幻觉方面的能力。编程任务具有很高的容错性，因为代码开发通常使用版本控制系统(如git),错误可以被回滚或修复，其影响是可控的。然而，当AI Agent参与到市场定位、产品宣传、用户策略等非编程决策时，其行为的影响可能是永久且不可逆的。一个错误的决策可能对产品造成无法挽回的损害。因此，这类任务对模型的准确性和无幻觉能力的要求远高于编程场景，对错误的容忍度极低。目前模型是否能达到如此高的可靠性，还很难说。第二，需要一个强有力的行业标杆。如果有一家大型公司公开宣布，他们通过采用AI原生的组织架构(这可能伴随着一定的人员调整),成功地将产品落地周期 从数月缩短至数周，并提供了确凿的数据支持，那么这很可能会引发众多公司的效仿和尝试。 从近期观察来看，企业在采纳AI方面是否出现了积极的变化? 在北美市场，变化非常显著。首先，在技术人员层面，我所认识的工程师、机器学习工程师和科学家几乎都在使用AI进行编程。工程团队对AI的采纳进度非常快，手写代码的情况已大幅减少。不过，在基础设施层面，例如AWS的底层云服务，由于对代码稳定性有极高的要求(如99.996%),其开发速度主要由严格的代码审核流程决定，而非编写速度，因此AI的介入相对谨慎。除这类岗位外，尤其是在创业公司中，工程团队对AI的采纳速度极快。至于决策层，虽然难以准确判断整体情况，但我了解到有多位CEO会经常使用ChatGPT来探讨各种商业想法。这表明AI在一定程度上已经进入了高层管理者的视野。 鉴于当前行业对AI模型在编程领域的信赖度普遍较高，企业管理层对于在更广泛业务中落地AIAgent的态度是否有所转变?具体而言，企业主(无论是大型、中型还是小型公司)是否比以往更愿意进行尝试，还是依然普遍处于观望状态? 能够接触到的CEO样本虽然有限，但观察到的趋势显示，他们对于推进Agent落地的意愿非常强烈，尽管在此过程中确实遇到了许多阻力。例如，上周与一家约3,000人规模公司的CEO交流后，次日便与该公司的CTO开会探讨了具体的落地尝试。这表明企业领导层有很强的意愿，但也存在迷茫。他们清楚地看到了AI在编程领域的成效，但对于如何将Agent更广泛地应用于业务逻辑乃至团队运作，并产生可量化的效果，尚缺乏明确的路径。尽管如此，企业界也展现出积极的一面，尤其体现在愿意在特定团队中承担风险，进行各类AI工具的实验。一个例子是，许多团队开始采用Langfuse等工具整合所有数据。虽然这尚未达到全自动化的程度，但企业已认识到数据整合是发挥Agent作用的先决条件，并开始在所有系统中推行。总体来看，市场情绪是积极的。然而，要达到能够将AI应用反映在公司整体运营成本降低或效率提升等财务指标上的阶段，还需要行业共同探索出一些成熟的模式。这或许解释了为何Palantir的FDE(ForwardDeployedEngineer)模式如此有效。FDE模式弥补了企业在AI落地过程中缺失的一环：Palantir提供平台，其FDE则深入了解不同企业的业务逻辑，利用AI工具优化其特定流程。虽然这种模式难度较高，但预计会有更多公司探索出如何让更多团队使用AI并将其与KPI挂钩。一旦行业内形成可复制的模板化经验，其传播速度将会非常快。 您如何看待大型模型公司(如OpenAI、Anthropic)效仿Palantir的FDE模式，亲自下场推动企业级AI解决方案的尝试?这种由模型公司主导的、旨在提供系统性解决方案的趋势，是否预示着一股新力量的崛起，并可能加速B端企业AI的落地进程? FDE模式在当前阶段确实有效弥补了企业AI落地过程中存在的断层。每个企业的核心产品、盈利逻辑、组织架构和生产流程都各不相同，不存在一个可以适用于所有企业的标准化AI应用公式。因此，拥有平台(无论是模型还是云服务)的公司，通过FDE团队去探索下游企业的具体业务逻辑，并据此进行最优化的部署与应用，是当下非常务实的一种做法。然而，FDE模式不一定是长期(例如五到十年)必须存在的模式。在推行FDE模式的一到几年内，平台方必然会摸索并沉淀出一些可复制的模板。例如，针对To C产品公司或特定场景(如呼叫中心),可以形成一套标准化的业务逻辑和应用模板，从而最大化特定类型事务的AI处理效率。以优化客服中心为例，这不仅涉及更换底层AI技术和产品线，甚至可能需要改变客服人员的日常工作方式，使其在处理客户投诉的同时，也承担起辅助或训练AI的职责。一旦在不同行业和领域中摸索出这些成型的模式，无论是面向消费者(To C)、企业(To B)还是政府(To G)的公司，其AI落地速度都将大幅加快。FDE模式可以类比于亚马逊在电商领域解决“最后一公里”配送的优势。亚马逊在北美市场的核心竞争力并非其线上商店，而是其无与伦比的末端配送能力。当前的FDE模式正是在解决AI落地的“最后一公里”问题，一旦这个环节被彻底打通并总结出规律，就能够