2026年6月15日，Salesforce Summer ‘26正式上线。在随附的新闻稿中，有一句话值得反复品读：”Agentforce’s Multi-Agent Orchestration enables agents to work together as a unified team to solve complex, end-to-end workflows.”（来源：Salesforce Summer ‘26官方发布公告，2026-06-15，https://www.salesforce.com/news/stories/summer-2026-product-release-announcement/）

这句话不长，但它回答了过去18个月企业AI市场一个最棘手的问题：当你有了50个各自运转的AI代理，谁来负责让它们协同工作？

一、企业AI部署的「最后一公里」困境

回到2024年9月，Salesforce CEO Marc Benioff在Dreamforce大会上宣布Agentforce的时候，全场掌声雷动。代理（Agent）被包装成企业AI的下一个革命：不只是问答，而是自主行动；不只是建议，而是执行。

但随后的现实给出了不同的答案。

一个典型的大企业场景是这样的：IT部门有一套IT服务代理，用于处理员工的技术支持请求；销售部门有销售支持代理，用于追踪客户线索和合同进展；客户服务部门有FAQ代理，用于回答标准化问题。这三套系统各自独立运转，互不感知，也无法协同。

当一个企业客户的请求横跨三个领域——”我的账单有问题需要退款，同时想升级服务计划，另外系统登录遇到了技术故障”——这三个代理都无法独立解决，用户也不知道该找哪一个，只能在客服热线和不同系统之间来回转接，不断重复解释背景。这不是用户体验问题，这是企业AI架构的结构性缺陷。

这个困境有一个技术名词：orchestration gap（编排缺口）。在技术层面，单个代理的能力已经相当成熟——每个代理都能处理自己领域内的标准任务。在组织层面，让多个代理作为统一系统协同运作，使它们共享上下文、无缝交接任务、对用户呈现一致的体验，仍然是大多数企业面临的核心挑战。

Salesforce Summer ‘26的多代理编排（Multi-Agent Orchestration），正是在直接攻克这个orchestration gap。

二、多代理编排的技术实现：协调层、共享上下文与信任壁垒

从技术架构上看，多代理编排本质上是一个「主代理 + 专家代理」的层级结构，加上一套共享的上下文机制。

统一入口层：客户不需要知道自己的问题应该由哪个代理处理。无论通过网页、移动应用还是Slack，请求都进入同一个接触点，由协调代理（Orchestrator Agent）负责理解意图和分发任务。

意图理解与路由：协调代理分析请求，将复合任务分解成子任务，并路由到相应的专家代理。账单问题去财务代理；服务升级去销售代理；技术故障去IT代理。路由决策需要理解任务优先级和依赖关系——退款先于升级，升级先于账单信息更新。

上下文共享：这是Summer ‘26多代理编排最关键的技术突破。官方表述是”shared context across all channels”（跨渠道共享上下文）——客户不需要在每个代理那里重新解释背景。当财务代理处理完退款后，销售代理接手时已经知道这个客户刚刚经历了账单问题，从而调整话术和优先级；当IT代理修复了登录故障，它可以主动告知协调代理这个阻碍已消除，销售升级流程可以继续推进。这种上下文的连续性，是让代理体验接近人类助手的关键。（来源：Salesforce Summer ‘26官方发布公告，2026-06-15，https://www.salesforce.com/news/stories/summer-2026-product-release-announcement/）

Trust Layer：Salesforce的Agentforce Trust Layer承担了数据权限和安全的职责——在确保数据隔离和合规的前提下，允许代理之间共享必要的上下文信息。一个代理不能随意访问另一个代理的完整对话记录；它只能获得协调代理明确传递的必要信息。这个层是多代理编排能够进入企业生产环境的必要条件——在没有严格权限控制的情况下，跨代理的数据流转会立即触发数据合规问题。

Summer ‘26同时发布的IT Service Domain Pack，是多代理编排的一个典型垂直应用案例。50+个专业IT服务代理开箱即用，覆盖从密码重置、软件授权、硬件申请到网络故障排查的完整IT服务场景，在Slack、Teams和IT服务台中部署，能够”检测意图并主动跨专业角色解决员工需求”。对于一个拥有10000名员工的企业，IT支持团队每天可能处理数百至数千张工单，其中大量是可以被规则化处理的标准请求。多代理系统将这类工单的解决时间从小时级压缩到分钟级，同时将人工工程师的精力释放到真正需要判断力的复杂问题上。

三、Agentforce Self-Service：把配置门槛降到6步

在过去两年，企业AI部署面临一个隐性门槛：大多数代理系统需要专业的AI工程师或顾问来配置和维护。这意味着只有财力充裕的大型企业才能从中受益，中型企业要么等待成本下降，要么依赖云服务商的预配置解决方案。

Summer ‘26的Agentforce Self-Service直接攻击这个门槛：”Setup now takes 6 clicks or less”（设置只需6步或更少）。伴随这个声明的是一个全新的Portal体验和一套”新的动态、个性化、对话式UI”，让最终用户可以通过自然语言直接与代理交互，而不需要学习特定的命令语法。（来源：Salesforce Summer ‘26官方发布公告，2026-06-15，https://www.salesforce.com/news/stories/summer-2026-product-release-announcement/）

这个「6步配置」的意义不只是技术上的简化。它代表了Salesforce在市场策略上的重要转向：从只有专业服务团队才能交付的高端企业产品，向中型企业和自助部署模式的规模化扩展。这种策略转向在Salesforce的历史上有迹可循——2010年代初，Salesforce通过降低CRM配置门槛将客户群从大企业扩展到中小企业；这次的「6步配置」可能在AI代理领域复制同样的扩张路径。

对竞争对手的含义是直接的。Zendesk、Freshworks等在客户服务领域深耕中小企业市场的平台，将面临来自Agentforce Self-Service的直接竞争。当配置只需6步，销售对话的框架就会从”我们的系统你们的IT团队能不能维护”变成”这套系统的ROI到底有多高”——而这个问题的答案，正在快速向AI倾斜。

四、Tableau MCP：让AI代理的答案有据可查

企业AI的最大可信度风险之一，是代理基于通用训练数据而不是企业真实数据回答业务问题。”你们公司Q2的销售转化率是多少？” 一个没有接入实际业务数据的代理只能给出基于行业平均值的模糊估计；一个接入了Salesforce CRM和Tableau数据的代理，可以给出精确到具体产品线和地区的实时数据。

Summer ‘26引入的Tableau MCP（Model Context Protocol集成），是解决这个可信度问题的关键技术。MCP是由Anthropic提出并被业界广泛采用的上下文协议标准，允许AI模型直接查询外部数据源，而不是依赖上下文中粘贴的静态数据。通过Tableau MCP，Salesforce平台上的AI代理可以实时查询Tableau的分析引擎，获取”grounded in your business context”（基于你的业务上下文）的准确答案，同时通过Agentforce Trust Layer确保数据安全。（来源：Salesforce Summer ‘26官方发布公告，2026-06-15，https://www.salesforce.com/news/stories/summer-2026-product-release-announcement/）

这个集成的战略意义远超技术层面。Salesforce的Data Cloud中汇聚了大量企业客户的业务数据——销售记录、客户交互历史、产品使用数据、服务工单记录。这些数据本身是Salesforce的核心护城河：当Amazon的代理在通用API层运行，当OpenAI的代理依赖互联网知识，Salesforce的代理可以基于这家企业真实发生过的业务数据来做决策。这种「情境接地性」（contextual grounding）不只是功能优势，而是基于数据积累的可信度护城河，是通用AI系统短期内无法复制的差异化因素。

Customer Engagement Agent的发布同样体现了这个逻辑：代理的功能是”从不错过一次转化机会”（Never miss a moment to convert），其决策基础来自对Salesforce Data Cloud中特定客户历史行为数据的实时查询——购买历史、服务互动频率、上次联系时间、已知偏好。这不是通用AI能做到的，这是CRM数据积累的变现。

五、竞争地图：Summer ‘26对企业软件格局的冲击

Salesforce Summer ‘26不是在真空中发布的。要理解它的战略含义，需要在竞争地图中定位它。

对ServiceNow：Summer ‘26的IT Service Domain Pack直指ServiceNow的核心市场。ServiceNow在企业IT服务管理（ITSM）领域长期占据领导地位，根据其2025年财报，年度经常性收入（ARR）超过100亿美元，企业客户超过8500家。（来源：ServiceNow FY2025年报，2026-02，https://investor.servicenow.com/）Salesforce的反击策略不是与ServiceNow在同一维度竞争——而是利用数据联通优势攻击一个ServiceNow相对薄弱的场景：当IT问题与客户服务问题相互关联时，Salesforce的多代理系统可以同时调用IT服务代理和CRM数据，而ServiceNow在这个跨系统联动场景中需要昂贵的定制集成。对于已经深度采用Salesforce CRM的企业，这是一个「从现有投资中获得更多」的路径，而不是「替换已有系统」的项目，降低了切换摩擦。

对Microsoft Copilot生态：微软在企业AI领域的优势是Office生态的深度集成。但Microsoft Copilot的主要场景是以个人生产力为中心的——帮助一个员工写邮件、总结文档、准备会议纪要。Salesforce的多代理编排是以客户体验和业务流程为中心的——帮助企业处理复杂的、跨部门的客户请求。两者的应用场景有重叠但不完全竞争，但随着Salesforce向员工工作流延伸（IT Service Domain Pack + Slack集成），这个边界正在模糊。

对ARD标准的协同：同在6月下旬，Google、微软和Salesforce联合支持的ARD（Agentic Resource Discovery）开放标准发布。ARD标准建立跨平台的代理发现机制，Salesforce Summer ‘26提供具体的多代理编排实现。两者共同构成了企业AI基础设施层的双轮：ARD负责让代理能够「发现」和连接企业软件栈中的各类工具；Salesforce的多代理编排负责让这些代理能够「协同」完成复杂任务。这一协同不是巧合，而是一个蓄谋已久的战略布局，其核心目标是建立企业AI生态中不依赖OpenAI或Anthropic专有API的自主基础设施。（来源：VentureBeat, 2026-06-21, https://venturebeat.com/ai/google-microsoft-and-salesforce-back-new-ai-software-standard-to-counter-openai-and-anthropic/）

六、实施挑战：多代理编排的暗礁区

在这次发布中几乎没有被讨论的问题，恰恰是最重要的：多代理编排的实施挑战。任何新范式的真正考验都在生产环境中，而不是演示舞台上。

代理冲突问题。当多个代理同时处理一个复合请求时，如何避免指令冲突？一个典型场景：客户投诉账单问题，财务代理倾向于要求核实身份信息以防止欺诈，而客户体验代理倾向于立即道歉并给出补偿。这两个代理的终极目标都是「解决客户问题」，但短期行动是矛盾的。协调代理如何在两者之间仲裁？当仲裁出错时，谁负责？Salesforce的Summer ‘26文档目前没有提供充分的冲突解决机制说明，这将是企业部署时首先遭遇的实战挑战。

可观察性缺口（Observability Gap）。在单代理系统中，当AI给出错误答案，调试路径相对清晰：查看输入、检查模型输出、检查上下文。在多代理系统中，一个最终错误可能是三层代理调用链中某一个环节的失误导致的，而每一层都可能引入新的错误。传统的日志系统无法追踪多代理决策链。企业IT团队需要全新的监控工具——不只是「系统是否运行」，而是「代理做了什么决策，基于什么信息，为什么」。

成本累积问题。多代理系统的每一次代理间交互都有token消耗。一个复杂的客户请求，可能触发协调代理、财务代理、IT代理和销售代理之间的多轮交互，每轮都有输入输出的token计算。对于日均处理数万个请求的大型企业，多代理系统的运营成本可能比单代理系统高出数倍，需要仔细计算ROI。精简代理数量、优化交互次数、设计高效的上下文传递机制，将成为企业AI运营的新核心技能。

数据治理的新复杂性。跨代理的上下文共享带来了新的数据治理问题。当财务代理将客户的账单信息传递给销售代理，这个传递行为是否需要客户明确授权？在GDPR和中国PIPL等数据保护法规下，代理间的数据流转如何留存合规审计日志？Salesforce的Trust Layer提供了技术框架，但法律合规实践仍需要每个企业的法务和IT团队共同建立。

七、大多数分析没有触碰的问题：代理记忆与组织遗忘的博弈

在所有关于多代理编排的技术讨论之外，有一个几乎没有人在谈的深层问题：当AI代理系统具有了跨会话、跨部门的完整记忆和上下文共享能力，组织原有的「遗忘机制」还能正常运作吗？

这听起来是哲学问题，但它有非常实际的管理含义。

人类组织的运转依赖大量有意识或无意识的遗忘。旧的客户投诉在解决后被归档放置，不再主动影响后续决策；某次内部会议中的分歧在会后逐渐消散，团队继续前进；一个服务失误在赔偿后被双方默契地放下。这种组织遗忘不是记忆力缺陷，而是维持组织灵活性和人际关系修复能力的必要机制。

当多代理系统完美记住了每一次客户交互、每一个内部决策、每一次服务失误，并将这些记录实时纳入当前决策上下文，组织的信息生态将发生根本性变化。对客户来说，这可能是福利：代理记得你三个月前投诉过账单问题，在你下次接触时主动提升服务优先级。但对企业内部来说，代理的「全记忆」意味着每一次服务失误都永久影响系统对该客户的行为模式，且这种影响可能随着时间积累变得越来越难以重置。

更深的问题是：谁有权让代理「遗忘」特定信息？在GDPR框架下，公民有「被遗忘权」（Right to Erasure），可以要求企业删除其个人数据。但当这些数据已经被多个代理作为上下文「内化」进了决策模式，单纯删除数据库记录是否足以清除代理的「记忆影响」？目前没有明确的答案，监管机构也尚未建立针对AI代理系统的被遗忘权实施标准。

一个具体的场景说明这个问题的现实性：一名欧盟客户在2024年向某家使用Agentforce的在线零售商提出了GDPR删除请求。按照传统数据处理流程，企业删除了数据库中的客户记录。但基于该客户历史行为数据训练的代理模型的「行为偏好」是否被完全清除？当Salesforce的多代理系统在服务其他客户时，是否还会受到已删除数据的间接影响？欧洲数据保护委员会（EDPB）在其2024年关于生成式AI的指引中承认这个问题的存在，但尚未提供具体的合规路径。（来源：EDPB, “Opinion 28/2024 on certain obligations resulting from the GDPR for controllers using AI systems”, https://www.edpb.europa.eu/）这不是一个遥远的监管话题——它在今天企业部署多代理系统时就已经需要面对。Summer ‘26的发布节奏意味着企业的窗口期正在收窄。

八、历史类比：企业软件的「平台化」轨迹

每一轮企业软件的技术升级，都经历了从「功能工具」到「平台操作系统」的演进。

1990年代，第一波CRM软件是独立的联系人管理工具，与财务系统、邮件系统各自为政。Salesforce在2000年代将CRM从安装软件变成云服务，并通过Force.com平台引入第三方应用生态，完成了从「工具」到「平台」的第一次跨越。

2010年代，ERP系统（SAP、Oracle）通过API集成将原本孤立的模块连接成更大的数据流，但集成成本依然高昂，主要由大型企业承担。这催生了以MuleSoft（被Salesforce收购）为代表的中间件市场，专门解决企业软件孤岛之间的集成问题。

现在，多代理编排是第三次跨越：从「工具集合」到「代理操作系统」。这次跨越的核心技术不是更好的API连接，而是共享上下文的代理协同。代理不只是通过API交换数据，而是共享意图理解、任务分配和用户上下文，形成一个统一的行动智能体。

Salesforce的历史证明，每次成功完成这种平台化跨越的企业，都会在随后5到10年内享受显著的竞争优势——不是因为它们的技术最先进，而是因为它们将正确的时机与足够的生态基础相结合。Summer ‘26是否是Salesforce在代理平台化时代的正确时机入场？这个问题的答案需要18个月后来验证。但它正在发出的信号，已经足够清晰。

结语：六月十五日，操作系统范式开始成形

Salesforce Summer ‘26不只是一个季度性产品发布。在更大的历史尺度上，它是企业AI从「功能市场」走向「平台市场」的一个标志性节点。

当多代理编排从概念变成可以6步配置的标准产品，当50个IT代理开箱即用，当Tableau的业务数据可以实时注入代理决策，企业AI的核心竞争轴已经发生了位移——从「谁有最聪明的模型」转向「谁有最好的编排基础设施和最完整的数据护城河」。

在这个新游戏中，Salesforce凭借其30年的CRM数据积累和遍布企业软件栈的生态整合，具备了其他参与者短期内难以复制的复合优势。但优势不等于必然的胜利。多代理编排的真正考验在于：它能否在生产规模下稳定运作，能否解决代理冲突和可观察性难题，能否在数据治理合规要求下保持灵活性。

技术层面的成熟和组织层面的成熟之间，永远存在一个时差。谁能帮助企业缩短这个时差，谁就是下一个企业AI周期的真正赢家。

参考资料

  1. Summer ‘26 Release: 10 Innovations Bringing the Agentic Enterprise to Life — Salesforce, 2026-06-15

  2. Amazon Bedrock AgentCore GA: Top Announcements of the AWS Summit in New York 2026 — AWS, 2026-06-17

  3. Google, Microsoft, and Salesforce Back New AI Software Standard to Counter OpenAI and Anthropic — VentureBeat, 2026-06-21

  4. MCP Protocol Specification — Model Context Protocol, 2024