公司级智能体发展趋势与永辉建设参考调研报告

写作边界：本报告用于外部学习和认知对齐，不作为永辉建设定案。未公开/未披露的信息不做推断；供应商宣称的数据必须标注来源主体。

补充阅读：治理控制面、工具注册、权限边界、业务对象语义层、可调用工具目录和评估用例集的落地拆解，见：公司级智能体治理与落地方法补充调研原文。

1. 执行摘要

公司级智能体正在从“问答助手”进入“流程执行与系统操作入口”阶段。外部领先公司不再只讨论模型能力，而是在争夺企业知识、业务流程、数据权限、系统工具、员工入口和现场交付能力。

对永辉来说，现阶段最重要的不是马上确定一个大平台方案，而是学习外部公司如何把智能体落到企业内部效率场景：供应链计划、库存可得性、履约异常、门店任务、采购协同、财务/结算、员工支持、研发提效。真正的壁垒不是单个模型，而是企业自己的业务上下文、系统连接能力、流程治理、权限审计和运行评估。

外部玩家大致分为四类：

• 大模型公司在建设 Agent 运行时、工具调用、长程任务、企业 SDK 和多智能体能力，试图成为企业智能体的大脑和执行环境。
• 软件与云厂商把 Agent 嵌入 ERP、CRM、ITSM、SCM、数据平台和办公套件，试图控制企业流程入口和治理控制面。
• 咨询、FDE 与交付型公司把 AI 平台带到业务现场，负责流程梳理、系统集成、原型验证和持续运营。
• 供应链与零售企业正在把 Agent 用于供应链、门店、采购、履约和员工效率，但大量信息仍处于试点、产品发布或厂商披露阶段。

永辉当前更适合的学习方式是：先理解外部方案，识别可学习机制，再选 1-2 个内部流程做验证。核心供应链、门店和采购流程不宜完全依赖外部黑盒能力。可以采购模型和通用平台能力，但业务流程理解、系统工具封装、知识库治理、权限审计、评估体系和场景运营能力需要逐步形成自有能力。

2. 玩家格局：外部公司正在争夺什么

2.1 大模型公司

大模型公司正在把能力从“模型 API”推进到“Agent 运行环境”。OpenAI、Anthropic、Google、阿里、百度、华为、腾讯、DeepSeek、Kimi 等都在强化工具调用、文件/代码执行、长程任务、多智能体、SDK、企业知识和开发者生态。

它们争夺的是企业智能体的底层能力入口：模型选择、工具协议、执行环境、上下文管理、开发框架和运行时。对永辉的启发是，不能只比较模型效果，还要比较模型是否能安全接入企业工具、是否支持可审计执行、是否能控制成本和失败回退。

2.2 软件与云厂商

Microsoft、Google Cloud、AWS、Salesforce、ServiceNow、SAP、Oracle、Blue Yonder、Snowflake、Databricks 等正在把 Agent 放进已有企业软件和云平台中。它们的优势不是模型本身，而是已经掌握了企业身份、权限、数据、流程、工单、报表和业务对象。

这类玩家争夺的是企业流程入口和治理控制面。对永辉的启发是，公司级智能体需要资产台账、权限、日志、评估、成本、人工确认、灰度和回滚，不能只做几个聊天机器人。

2.3 咨询、FDE 与交付型公司

Accenture、BCG、McKinsey、Palantir、Lenovo、神州控股、神州数码、01.AI 等把智能体落地包装成现场交付能力。它们强调的不只是平台，而是进入业务现场后做流程拆解、系统/接口梳理、数据语义建模、原型构建、评估和持续运营。

这类玩家争夺的是“最后一公里”：谁能把模型和平台变成企业现场可运行的流程能力。对永辉的启发是，如果内部要自建能力，也需要类似 FDE 的小队机制，而不是只靠中心平台团队远程开发。

2.4 供应链与零售企业

Walmart、Amazon、Tesco、JD、Alibaba/Tmall、Intime 等公开资料显示，零售和供应链企业的智能体方向集中在内部效率：供应链计划、履约中心调度、门店员工助手、商家/采购经营工具、线下经营分析、门店任务和研发效率。

这类案例最贴近永辉，但公开资料也最需要谨慎。很多案例只披露了方向、试点或厂商宣称，未披露真实架构、成本、失败率、人工接管率和 ROI。永辉应学习它们的场景选择和组织方式，而不是直接复制产品口号。

3. 重点公司案例

3.1 大模型公司案例

OpenAI Frontier + Responses API Agent Runtime

• 所属类型：大模型公司。
• 方向：从模型问答转向可执行工作流，让模型在受控环境中读写文件、运行代码、调用工具、生成交付物。
• 策略：把模型、API、工具、容器运行时、状态管理、技能复用和企业部署放在一起，而不是只提供聊天入口。
• 落地手段：OpenAI 公开资料显示，其通过托管容器、shell tool、Responses API orchestration、WebSocket agent loop 等能力支持 Agent 执行环境。
• 公开进展：2026 年 OpenAI 连续发布 Frontier、Responses computer environment、WebSocket agent loop 优化。Frontier 页面披露了匿名企业客户案例，但客户名称、完整架构和成本收益细节未公开。
• 可学习点：永辉若做公司级智能体，应先定义“执行环境、工具边界、文件/数据交付物、日志审计、失败回退”标准，而不是只堆提示词。
• 不可照搬点：OpenAI 的基础模型、API 生态、企业客户基础和全球基础设施是其前提；永辉不能把匿名客户效果直接套到零售和物流流程，需要先验证内部系统工具调用、权限审计和人工确认边界。
• 来源：Responses computer environment、OpenAI Frontier、WebSockets in Responses API。

Google Gemini Enterprise Agent Platform

• 所属类型：大模型公司/云平台。
• 方向：企业级 Agent 平台，覆盖构建、部署、治理、优化，以及 Google-made、自建、伙伴 Agent 统一管理。
• 策略：用 Gemini Enterprise 做员工入口，用 Vertex AI/ADK 做技术构建，用 A2A 等协议做互操作，用生态伙伴扩展能力。
• 落地手段：公开资料显示，Gemini Enterprise 提供 Deep Research、Data Insights、NotebookLM Enterprise、Gemini Code Assist 等 Agent；业务用户可用 Agent Designer，技术团队可用 ADK。
• 公开进展：Google Cloud Next 2026 将 agentic enterprise 作为主线，官方产品页披露 Agent Gallery、Agent Designer、ADK、A2A、第三方 Agent 发现等能力。
• 可学习点：公司级智能体需要“Agent 资产目录 + 权限治理 + 自建/外采并存”的平台观，不能只有一个聊天入口。
• 不可照搬点：Google 的 Workspace、BigQuery、Vertex AI、Marketplace 生态是其前提；永辉内部系统如果不在 Google Cloud，不能直接照搬其集成路径，需要先验证自身系统和数据源能否被统一授权、索引和审计。
• 来源：Gemini Enterprise Agent Platform、Google Cloud Agents、Google Cloud Next 2026。

Anthropic Claude Agent SDK + Enterprise Partnerships

• 所属类型：大模型公司。
• 方向：以 Agent SDK 和高可信模型进入软件开发、受监管行业和企业知识工作。
• 策略：通过 IDE、SaaS 平台和咨询集成商进入企业既有工作流，而不是只卖模型 API。
• 落地手段：Claude Agent SDK 支持 subagents、background tasks、plugins；Anthropic 与 ServiceNow、Infosys、Apple Xcode 等公开合作。
• 公开进展：2026 年 Anthropic 已公开 ServiceNow、Infosys、Apple Xcode 等合作。ServiceNow 相关效果指标属于官方合作披露口径。
• 可学习点：永辉推进公司级智能体时，应优先选择已有业务平台嵌入式落地，例如工单、研发、采购、财务、客服，而不是新建孤立入口。
• 不可照搬点：Anthropic 的海外企业合作网络、Claude Code 生态和 SDK 成熟度是其前提；永辉不能直接复制其合作模式，需要验证国内模型、开发工具、权限体系和已有业务平台的嵌入可行性。
• 来源：Xcode supports Claude Agent SDK、Anthropic and Infosys、ServiceNow chooses Claude。

阿里云通义/百炼/Agentic OS/Agentic SOC

• 所属类型：大模型公司/云平台。
• 方向：从模型平台扩展到云、OS、安全、运维等可执行环境。
• 策略：用通义千问/Qwen 做模型底座，用阿里云数据、日志、SOAR、云原生组件承接企业 Agent 场景。
• 落地手段：百炼提供零代码智能体、插件、知识库；Agentic OS 提供 Copilot Shell、OS Skills、AgentSecCore；Agentic SOC 用 Team Leader 调度多个安全 Agent。
• 公开进展：2026 年官方文档已披露 Agentic OS、百炼智能体、Agentic SOC 的结构和能力。
• 可学习点：行业场景 Agent 需要绑定真实数据域和执行系统。例如物流调度、异常诊断、库存稽核不能停留在问答。
• 不可照搬点：阿里云 SLS、Flink、SOAR、安全大模型、云 OS 是其前提；永辉不能直接假设自身日志、消息、接口、权限已经达到同等状态，需要先验证一个内部数据域能否形成可调用、可审计、可回滚的工具集合。
• 来源：百炼智能体应用、Alibaba Cloud Linux 4 Agentic Edition、Agentic SOC Agent 架构。

3.2 软件与云厂商案例

Microsoft Copilot Studio + Agent 365

• 所属类型：软件与云厂商。
• 方向：企业内部 Agent 构建、工作流自动化、统一治理。
• 策略：把 Agent 管理类比为员工或账号管理，接入 Microsoft Admin Center、Defender、Entra、Purview 等治理体系。
• 落地手段：Copilot Studio 构建 Agent 与工作流；Agent 365 做清单、权限、行为、活动治理；支持 MCP 工具和多 Agent 编排。
• 公开进展：Microsoft 官方博客显示 Agent 365 在 2026 年进入 GA，Copilot Studio 2026 Wave 1 覆盖评估、治理、MCP 工具和工作流。
• 可学习点：公司级智能体需要“Agent 资产台账、权限、成本、日志、评估”控制面，不能只有散落在各系统里的机器人。
• 不可照搬点：微软方案强依赖 Microsoft 365、Entra、Power Platform、Dynamics 生态；永辉主系统多为自研和多微服务，直接照搬会造成平台入口与核心业务系统脱节，需要先验证身份、权限、日志和工具注册能否统一。
• 来源：Copilot Studio updates、Copilot and agents。

AWS Amazon Bedrock AgentCore

• 所属类型：软件与云厂商。
• 方向：Agent 生产运行基础设施。
• 策略：不绑定单一 Agent 框架或模型，提供 Runtime、Gateway、Identity、Observability、Evaluations 等可组合能力。
• 落地手段：AgentCore Runtime 承载长任务与会话隔离；Gateway 把 API/Lambda 转成 MCP 工具；Evaluations 做线上抽样评分和 CI/CD 回归评估。
• 公开进展：AWS 官方公告显示，AgentCore Evaluations 于 2026 年 GA，AgentCore 进入 AWS GovCloud，面向合规工作负载。
• 可学习点：研发侧需要把评估、观测、权限委托、工具网关作为 Agent 工程化底座，而不是依赖人工调 prompt。
• 不可照搬点：AWS 的 IAM、Lambda、Bedrock、GovCloud 是其云原生前提；永辉如果多云、本地和自研系统并存，不能照搬服务名，需要抽象出等价能力：工具网关、权限委托、运行隔离、评估和日志。
• 来源：AgentCore Evaluations GA、AgentCore GovCloud。

Salesforce Agentforce

• 所属类型：软件与云厂商。
• 方向：CRM、客户服务、ITSM、公共服务中的数字劳动力。
• 策略：围绕 Salesforce CRM、Data 360、Slack、Teams-ready 工作流，把 Agent 嵌入既有业务对象和服务流程。
• 落地手段：Agentforce IT Service、Agentforce Public Sector、Agentforce Contact Center 等产品化场景，支持人机协作、升级人工、联络中心触点。
• 公开进展：Salesforce 官方投资者新闻称 Agentforce IT Service GA 四个月内已有 180 个组织选择，美国劳工部相关部门正在 rolling out Agentforce。selected 和 rolling out 不等于全部稳定生产上线。
• 可学习点：永辉可优先选择高频、标准化、可审计的服务流程，如 IT 服务台、门店支持、供应商问答，而不是一开始挑战全业务自主决策。
• 不可照搬点：Agentforce 价值建立在 Salesforce CRM/Data Cloud 数据模型上；永辉订单、仓配、门店、采购和主数据并不天然在 Salesforce 内，直接照搬会变成外围客服工具，需要先验证核心业务对象是否能被统一建模。
• 来源：Agentforce IT Service、DOL Agentforce。

ServiceNow Autonomous Platform + AI Control Tower

• 所属类型：软件与云厂商。
• 方向：IT、HR、客服、企业运营流程中的自主工作与治理。
• 策略：ServiceNow 将自身定位为 AI control tower，强调跨模型、跨云、跨数据源的发现、观测、治理、安全和度量。
• 落地手段：AI Control Tower、AI Gateway、Context Engine、Service Graph、Knowledge Graph、Data Inventory 支撑 Agent 在流程系统中执行。
• 公开进展：2026 年 ServiceNow 发布多项 Agentic AI 治理能力，并与 Google Cloud、NVIDIA 深化 Agent 互操作和评估/观测合作。
• 可学习点：Agent 必须进入流程编排、审批、工单、权限、度量体系，不能孤立运行。
• 不可照搬点：ServiceNow 的优势来自 ITSM/ESM 流程平台存量；永辉流程入口分散，若直接采购类似平台，可能只覆盖 IT 工单，无法触达供应链和门店动作，需要先明确哪些流程有统一入口。
• 来源：Autonomous Platform、AI Control Tower。

Blue Yonder Agentic Supply Chain

• 所属类型：软件与云厂商/供应链软件。
• 方向：供应链计划、可视化、决策辅助。
• 策略：把 Agent 放进供应链软件中，服务计划员、调度员、补货和异常处理。
• 落地手段：公开资料主要是 2026.1 release 和 agentic supply chain 方法论，强调将供应链数据、计划和决策过程与 Agent 结合。
• 公开进展：2026 年 Blue Yonder 发布 1H 2026 release，并公开讨论 agentic supply chain 架构方向。具体客户成效未充分披露。
• 可学习点：对永辉最贴近的是“供应链 Agent 应服务计划、补货、库存可得性、异常决策”，而不是通用办公问答。
• 不可照搬点：Blue Yonder 面向的是其自有供应链软件客户，默认已有统一计划数据和流程模块；永辉存在多套自研系统和不同业务口径，直接照搬会卡在数据口径、接口速度和流程责任边界，需要先选一个供应链子流程验证。
• 来源：Blue Yonder 1H 2026 release、Architecting the agentic supply chain。

3.3 咨询、FDE 与交付型公司案例

OpenAI Frontier Alliances + Accenture/BCG/McKinsey

• 所属类型：咨询/FDE 与交付型公司。
• 方向：企业级 Agent 从模型能力转向战略、系统集成、流程重塑和全球部署。
• 策略：咨询公司补齐行业、组织、变革管理和交付规模；OpenAI 提供产品、研究和 FDE 支持。
• 落地手段：OpenAI FDE 与咨询公司全球交付团队共同工作。BCG、McKinsey 偏战略、操作模型和流程嵌入，Accenture 偏端到端系统、数据、安全和长期运营。
• 公开进展：OpenAI 2026 年公告显示 Frontier 对 limited customers 可用；公开资料未披露完整客户名单和落地周期。
• 可学习点：智能体落地需要把流程重塑、系统接入、变革管理、治理和长期运营放在与模型同等重要的位置。
• 不可照搬点：OpenAI 的前沿模型、认证资源、roadmap access、全球 SI 网络是其前提；永辉内部如果要学习，只能学习“FDE + 业务流程 + 系统集成”的工作方式，不能假设外部联盟能直接理解永辉所有自研系统。
• 来源：OpenAI Frontier Alliance Partners、Accenture and Google Cloud、BCG and Google Cloud、McKinsey and Wonderful。

Palantir AIP AgentCamp / AI FDE

• 所属类型：咨询/FDE 与交付型公司。
• 方向：把 FDE 方法产品化，让 Agent 直接作用于数据管道、Ontology、函数、应用和治理。
• 策略：以客户真实数据和实际问题为中心，短周期现场构建，强调安全、权限、审计、可解释。
• 落地手段：AgentCamp 宣称现场构建运行系统；AI FDE 文档显示可通过自然语言执行 Foundry 操作，变更通过 branch/PR 审查。
• 公开进展：Palantir 2026 页面和文档持续更新。AIP Bootcamp 公开说法可作为背景，但具体客户成效需另证。
• 可学习点：FDE 交付物不应只是 PPT，应包括业务语义层、可运行 Agent、评测、权限/审计、可审查变更。
• 不可照搬点：Palantir 的 Ontology、Foundry、AIP、Apollo 一体化平台和政府/工业客户基础是其前提；永辉若没有统一业务语义层，直接复制会卡在“系统有接口但没有统一业务对象”的问题，需要先验证订单、库存、门店、商品等对象能否被建模。
• 来源：AIP AgentCamp、AI FDE overview、AIP Bootcamp。

神州数码/神州控股/01.AI 国内 FDE 与流程重构样本

• 所属类型：咨询/FDE 与交付型公司。
• 方向：国内服务商开始把 AI agent 与流程重构、现场 FDE、业务结果交付绑定。
• 策略：强调“流程”是 AI 落地核心；FDE 深入业务一线，把行业 know-how、流程和数据资产转为可复用智能体。
• 落地手段：神州控股公开说法包括进场前行业价值链提炼、现场可交互看板、真实业务 POC、交付端到端业务任务的数字智能体；01.AI 提到 FDE 承接“一把手工程”，深入一线。
• 公开进展：2026 年均有公开发布，但客户、周期、验收指标多未公开。
• 可学习点：永辉可以重点学习“业务流程解构、现场原型、看板/智能体/评测作为交付物”的表达方式。
• 不可照搬点：公开材料偏战略和营销，不能直接把“交付业务结果”“解决标准化工作”等表述当作事实；永辉要先验证一个具体流程的现场调研、接口梳理、原型交付和验收指标能否跑通。
• 来源：神州数码 AI for Process、神州控股燕云 AI First FDE、01.AI 万智2.5。

3.4 供应链与零售企业案例

Walmart Super Agents + 供应链/门店/员工工具

• 所属类型：供应链与零售企业。
• 方向：公司级 AI Agent 操作系统，覆盖供应链、门店运营、员工支持、开发者效率。
• 策略：按 customers、associates、partners、developers 四类角色构建 super agents，并把 Agent 与库存、履约、门店任务和开发工具连接。
• 落地手段：Walmart 官网提到供应链 agentic systems 可参与需求预判、库存位置、配送协调；门店侧有数字货架标签、员工 AI 工具、任务管理等效率工具。
• 公开进展：FY26 继续投资供应链自动化；数字货架标签约 2,300 家美国门店使用；Walmart 技术页面已把 Agent 作为公司级能力表达。
• 可学习点：永辉可以学习按业务角色组织 Agent 能力，例如总部计划、门店员工、供应商协同、研发/数据团队分别定义 Agent，而不是泛化为一个大助手。
• 不可照搬点：Walmart 的全球门店规模、数据资产、自动化仓网和自研平台基础是其前提；永辉直接照搬会忽略国内商超、生鲜供应链和区域运营差异，需要先验证一个角色型 Agent 是否能在门店或供应链一线产生稳定动作建议。
• 来源：Walmart Technology、Digital shelf labels、Walmart FY26 earnings。

Amazon Project Eluna 履约中心运营 Agent

• 所属类型：供应链与零售企业。
• 方向：履约中心运营调度、瓶颈识别、人力/资源调整建议。
• 策略：把 Agent 放在运营控制塔位置，减少经理查看多套 dashboard 的负担，由系统读取历史与实时数据并给出行动建议。
• 落地手段：Project Eluna 在履约中心试点，初始场景是 sortation optimization，可回答应把人调到哪里以避免瓶颈等问题。
• 公开进展：Amazon 明确称 Eluna 是 agentic AI，并计划在 Tennessee fulfillment center 试点。Blue Jay 机器人项目在同一资料中标注不再用于运营，说明外部项目也存在调整。
• 可学习点：永辉可学习“异常、建议、人工确认”的仓配 Agent 形态，先服务班组长、仓库调度、运输协调，而不是直接自动执行关键动作。
• 不可照搬点：Amazon 仓内自动化、机器人、实时数据采集密度远高于普通商超供应链；永辉若直接照搬，会在实时数据、设备联动和现场执行上遇到断点，需要先验证仓内异常数据是否足够实时且可信。
• 来源：Project Eluna、Amazon Supply Chain Services、Amazon fulfillment network tech。

JD 采购/供应链智能体与 AI 库存分仓候选

• 所属类型：供应链与零售企业。
• 方向：采购、库存、分仓备货、履约效率。
• 策略：以京东“供应链技术与服务提供商”定位为基础，把 AI 嵌入采购和履约链路。
• 落地手段：公开媒体资料称京东政企采购 AI 智能体覆盖寻源、选品、议价、下单、履约、结算、客服、售后；AI 年货地图面向商家展示库存分布、周转、履约时长并给出分仓备货建议。
• 公开进展：京东 Q1 2026 财报确认其供应链技术服务定位、零售经营利润与履约投入；采购智能体和年货地图细节主要来自媒体转载。
• 可学习点：永辉可学习把采购、履约、结算作为一个完整闭环，让 Agent 面向采购员和供应链计划员输出可审核建议，而不是只做问答。
• 不可照搬点：京东自营电商、开放物流和工业品采购平台的数据结构与永辉生鲜商超不同；媒体披露的效率指标需要官方或客户案例二次核验，永辉落地前要验证生鲜短保、损耗、库存口径和采购规则能否被稳定表达。
• 来源：JD Q1 2026 results、京东政企采购 AI 智能体报道、AI 年货地图报道。

Alibaba / Tmall 商家经营 AI Agent Team

• 所属类型：供应链与零售企业。
• 方向：商家运营效率、店铺分析、广告投放、客服、售后、新品开发。
• 策略：把平台经营工具 Business Advisor 升级为 24/7 AI Agent team，让商家获得一组自动化运营能力。
• 落地手段：Agent 能力与本地文件、CRM 数据、店铺巡检、销售分析、素材生成、客服需求等连接；TMIC 使用 Qwen 与淘宝商品知识库提升新品开发效率。
• 公开进展：阿里集团官网 2026-03-27 披露该路线；2026-05 股东信和财报新闻显示阿里把 agent services 作为云和企业 AI 的重点。
• 可学习点：永辉可借鉴“经营驾驶舱 + 多角色 Agent team”的概念，用于门店店长、品类经理、采购、营运督导，而不是只给管理层看报表。
• 不可照搬点：天猫案例面向平台商家，不是自营商超内部供应链；其广告、客服、售后链路与永辉线下生鲜运营不同，永辉需要先验证门店经营数据、商品数据和促销规则是否能支撑多角色建议。
• 来源：Tmall agentic capabilities、Alibaba Cloud AI strategy、Alibaba shareholder letter。

Intime MOS-AI 线下零售经营 Agent

• 所属类型：供应链与零售企业。
• 方向：线下门店经营、会员运营、内容生产、智慧客流、物业/合同管理。
• 策略：公开表述为感知、决策、执行闭环，围绕线下百货/购物中心经营，把数据分析转成经营方案。
• 落地手段：媒体披露包括深象感知系统、韬略决策引擎、银泰精灵 Agent 市场、OPC 组织模式；MOS-AI 用品牌画像、用户行为、历史活动效果做经营归因、趋势推理与策略生成。
• 公开进展：2026 年供应商大会发布；媒体称 AI 参与并提升的销售额占比 17%，该指标为媒体报道口径。
• 可学习点：线下经营 Agent 不只做库存，也要结合客流、活动、商品、人员和门店动作，适合永辉门店营运场景参考。
• 不可照搬点：银泰是百货/商业体，永辉是商超和生鲜供应链；来源主要为媒体报道，缺少官方白皮书和系统架构。永辉若学习，应先验证客流、商品、促销和门店任务是否能形成可执行 SOP。
• 来源：界面新闻 MOS-AI、CCFA2026 报道。

Tesco 员工 AI 助手 + 供应链 AI 风险识别

• 所属类型：供应链与零售企业。
• 方向：员工支持、门店/客服效率、供应链风险识别、门店订货与损耗。
• 策略：从员工助手试点切入，同时在供应链和门店订货中扩大 AI 使用。
• 落地手段：Tesco 内部 app、数据科学、工程团队与 Tomoro AI 合作开发同事 AI assistant；财报披露供应链使用 AI 识别外部风险与机会；可持续报告披露 AI 用于优化门店订单。
• 公开进展：2026 年启动大规模 colleague trial；2025/26 初步业绩和可持续报告均出现 AI 供应链/门店订货表述。
• 可学习点：永辉可学习低风险路径：先做员工助手和流程知识入口，再逐步接供应链数据与门店订货建议。
• 不可照搬点：Tesco 未公开助手具体场景、权限边界、效果指标；英国零售流程、数据治理和劳动组织与国内商超不同。永辉落地前需要验证一线员工是否愿意使用、回答是否符合本地 SOP、是否能接入内部知识库。
• 来源：Tesco colleague AI assistant、Tesco preliminary results 2025/26、Tesco sustainability report 2026。

4. 横向对比矩阵

说明：“是否依赖现场交付”是本报告基于公开资料做的阅读判断，用于帮助理解落地方式，不等同于厂商披露的合同模式。判断标准：公开资料明确强调 FDE、咨询、现场共创、联合交付时记为“是”；主要以 SaaS、API、产品页、平台能力交付时记为“否/部分”；资料不足时记为“未披露”。

5. 各类方案的典型落地步骤

说明：本节是基于公开资料归纳的“典型落地路径”，不是每家公司完整项目计划。公开资料未披露的内部步骤不做推断。

5.1 大模型公司方案：先给企业可控执行环境

代表公司：OpenAI、Google、Anthropic、阿里云通义。

典型步骤：

1. 先提供模型、工具调用、文件处理、代码/脚本执行、多轮任务和上下文管理能力。
2. 再提供 Agent SDK、API、运行时、托管容器、工作台或低代码构建器，让企业能把模型变成可执行任务。
3. 接入企业知识、文件、数据库、应用 API 或工具协议，让 Agent 不只回答问题，而能读取上下文和调用工具。
4. 增加权限、日志、评估、成本控制、失败回退和人工确认，降低企业试点风险。
5. 通过咨询伙伴、软件平台、开发者生态或行业方案进入企业实际流程。

对永辉的启发：

• 不能只选模型，要看模型背后的执行环境、工具调用、安全边界和评估能力。
• 大模型公司更适合作为底层能力来源，不应直接替代永辉对业务流程、接口和权限的治理。
• 试点时可以先验证“一个 Agent 能否安全读取资料、调用 3-5 个工具、输出可审计结果”，再谈规模化。

5.2 软件与云厂商方案：先占住流程入口和治理控制面

代表公司：Microsoft、AWS、Salesforce、ServiceNow、Blue Yonder。

典型步骤：

1. 从已有软件入口切入，例如办公套件、ITSM、CRM、ERP、SCM、数据平台或云平台。
2. 把 Agent 放进既有业务对象和流程里，例如工单、客户、订单、供应链计划、知识库、审批流。
3. 提供 Agent Builder、工作流编排、工具网关、知识连接、评估和运行监控。
4. 建立统一治理控制面，管理 Agent 资产、权限、行为、成本、日志、风险和版本。
5. 逐步从单场景 Copilot 扩展到多 Agent 协作和跨系统流程执行。

对永辉的启发：

• 企业智能体平台不能只有对话入口，必须有 Agent 台账、权限、日志、评估和工具治理。
• 如果采购软件厂商方案，要先判断它覆盖的是办公/IT/CRM，还是能真正触达永辉供应链、门店、采购、物流系统。
• 对自研系统多的环境，关键不是接入多少接口，而是把少量关键接口封装成稳定、可理解、可审计的业务工具。

5.3 咨询、FDE 与交付型方案：先到现场拆流程

代表公司：Accenture、BCG、McKinsey、Palantir、神州控股、01.AI。

典型步骤：

1. 进场前先做业务访谈和资料收集，明确业务目标、痛点、流程边界和验收指标。
2. 到现场梳理人工流程、系统路径、数据来源、接口清单、异常分支和人工判断点。
3. 选一个高频、跨系统、规则相对清楚、风险可控的流程做真实 POC。
4. 把流程拆成可执行工具、知识库、规则约束、人工确认节点和评估集。
5. 做出可交互原型或可运行 Agent，让业务在真实数据或脱敏数据上试用。
6. 根据试用结果调整流程、工具、权限、提示词、评估集和交付边界。
7. 上线后持续运营，跟踪使用率、准确率、人工接管率、异常关闭时长、成本和业务反馈。

对永辉的启发：

• FDE 的核心不是“外部专家驻场”这个形式，而是把业务流程、系统接口、数据口径和可运行原型放在同一张桌上解决。
• 永辉如果有自研团队，应建立内部 FDE 小队：业务专家、产品、架构、后端、数据、AI 工程、安全/运维一起进场。
• FDE 交付物不应只是方案文档，还应包括流程地图、接口地图、工具清单、知识库范围、评估集、原型和上线风险清单。

5.4 供应链与零售企业方案：先做内部效率闭环

代表公司：Walmart、Amazon、JD、Alibaba/Tmall、Intime、Tesco。

典型步骤：

1. 先选择企业内部效率场景，而不是直接从面向消费者销售开始。
2. 从角色出发定义 Agent，例如门店员工、店长、采购员、供应链计划员、仓库调度、供应商、研发人员。
3. 把角色每天跨系统查询、判断、协调、填报、跟进的任务列出来，找出高频痛点。
4. 先做建议型 Agent：识别异常、归因、推荐动作、生成任务或话术，由人工确认后执行。
5. 逐步接入库存、订单、商品、门店、履约、供应商、客服、财务等系统能力。
6. 用真实业务指标评估，例如异常关闭时长、缺货处理时长、门店任务响应时长、采购处理效率、人工查询次数。
7. 在单区域、单业态、单流程稳定后，再复制到更多业务线。

对永辉的启发：

• 最适合先学的是供应链、门店、采购、物流、客服和研发提效，不是 C 端销售助手。
• 零售企业的智能体不应只做“查资料”，而要围绕“人货场”的日常动作给出可执行建议。
• 生鲜、短保、损耗、区域运营和门店 SOP 是永辉的特殊复杂度，外部案例只能提供方法，不能直接给出答案。

5.5 永辉可借鉴的最小落地路径

结合四类外部方案，永辉更现实的起步路径可以压缩为七步：

1. 选场景：从供应链、门店、采购、物流中选 1 个高频、跨系统、风险可控的流程。
2. 画流程：梳理人工步骤、涉及系统、关键字段、异常分支、人工判断点。
3. 列工具：只挑 5-10 个关键业务能力封装工具，不直接暴露上百个复杂接口。
4. 建知识：把 SOP、规则、口径、禁用动作、人工确认条件做成可版本化知识。
5. 做原型：先做建议型 Agent，不自动改库存、订单、财务和履约结果。
6. 设评估：用真实问题集评估准确率、人工接管率、节省时间、错误类型和业务接受度。
7. 再扩展：试点通过后，再沉淀工具规范、知识规范、权限规范和 Agent 运行规范。

6. 公司级智能体的共同演进路线

6.1 从问答助手到流程执行者

外部公司正在把智能体从“回答问题”推向“完成任务”。OpenAI 的执行环境、AWS 的 AgentCore、ServiceNow 的流程平台、Amazon 的履约中心 Eluna 都说明，智能体的价值在于读数据、判断状态、调用工具、生成动作建议或执行受控动作。

永辉后续判断一个智能体场景是否有价值，不应只问“能不能回答”，还要问“能不能减少跨系统查找、能不能形成可审核建议、能不能沉淀为流程动作”。

6.2 从单点助手到多系统协同

Google、Microsoft、ServiceNow、Salesforce 等方案都强调统一入口和跨系统连接。单点机器人容易停留在知识问答，真正难点是身份、权限、业务对象、工具、日志和审批。

永辉的系统数量多、微服务复杂，不能把上万接口一股脑转成工具。更现实的做法是按业务流程选择少量关键能力，先做工具瘦身和业务语义封装。

6.3 从模型能力到企业上下文能力

模型能力会快速扩散，企业差异会体现在上下文能力上：业务规则、SOP、商品和库存口径、门店动作、供应商协同、组织权限、异常处理经验。这些内容不是外部模型自带的。

永辉要形成自己的智能体能力，重点应放在企业知识库、流程版本、接口语义、评估集、人工确认和运行数据上。

6.4 从软件销售到平台 + FDE + 持续运营

咨询和 FDE 公司给出的信号很明确：企业智能体不是一次性交付，而是现场诊断、流程梳理、原型验证、系统接入、评估、上线、运营迭代的连续过程。

永辉如果只采购平台，不建设内部 FDE 式小队，就容易出现“平台能用，但没人知道接哪个流程、怎么验收、怎么运营”的问题。

6.5 从 API 接入到权限、审计、评估和灰度治理

Microsoft Agent 365、AWS AgentCore、ServiceNow AI Control Tower 都把治理放在核心位置。智能体可以调用系统，就必须有权限、审计、评估、成本、失败回退和人工接管机制。

对永辉来说，任何能改库存、改订单、触发财务、影响履约的智能体，都不能绕过权限和审批。

7. 对永辉的学习方向

7.1 观察项

• 哪些外部能力已经被厂商包装成产品或平台能力：Agent 运行时、工具网关、Agent 台账、权限治理、评估、工作流编排、知识库。这不等于已经被大量客户验证出稳定 ROI。
• 哪些能力仍主要停留在发布和营销：完整 ROI、客户真实失败率、上线周期、人工接管率、成本收益。
• 哪些公司更接近永辉场景：Walmart、Amazon、Tesco、JD、Alibaba/Tmall、Intime、Blue Yonder。
• 哪些公司更适合作为平台能力参考：Microsoft、AWS、ServiceNow、Google、OpenAI、Anthropic、阿里云。

7.2 可学习点

• 从角色出发组织能力：总部计划、采购、门店店长、仓库调度、供应商协同、研发团队分别定义 Agent。
• 从建议型 Agent 开始：先提供异常识别、原因归因、动作建议和人工确认，不直接自动改关键业务数据。
• 从一个流程切入：优先选择高频、跨系统、规则相对清楚、风险可控的流程，例如缺货救单、履约异常、门店任务问答、采购寻源辅助。
• 建立工具治理：每个工具要有用途、参数、权限、超时、日志、幂等、回滚和负责人。
• 建立业务知识治理：SOP、规则、口径、变更记录、审批记录和过期机制要能被智能体引用。

7.3 待验证假设

• 永辉是否能选出 1-2 个跨系统但风险可控的内部效率流程，作为智能体试点。
• 这些流程是否已有稳定 SOP，还是业务规则经常变化。
• 关键接口是否能被瘦身成少量业务能力，而不是暴露几十上百个复杂参数。
• 现有主数据、库存、订单、门店、供应商数据口径是否足够一致。
• 一线业务是否接受“智能体建议 + 人工确认”的工作方式。
• 内部研发团队是否能承担 FDE 式角色：现场调研、流程拆解、工具封装、原型和评估。

7.4 下一步调研清单

• 选择 3 个永辉内部候选流程，画出人工流程、系统调用链、数据口径和异常分支。
• 对每个流程列出 5-10 个关键系统能力，判断哪些适合封装为工具，哪些需要先改造接口。
• 访谈采购、物流、门店、客服、财务、研发代表，确认痛点和验收指标。
• 建立一个小型评估集：真实问题、标准答案、允许动作、禁止动作、人工确认条件。
• 对 2-3 家外部供应商或开源平台做 POC，不比较“演示效果”，只比较工具调用、权限、审计、评估和接入成本。

8. 风险边界与下一步调研清单

8.1 风险边界

• 不要把全部接口直接转成 MCP 或工具。复杂、慢、大参数、强状态接口需要先抽象为业务能力。
• 不要把供应商宣称的指标当成永辉可实现指标。公开案例多缺少客户成本、失败率、人工接管率。
• 不要让智能体绕过审批。库存、订单、财务、履约等关键动作必须保留权限、审计和人工确认。
• 不要把知识库当成静态文档库。业务流程变化时，需要版本、来源、审批、废弃和回放测试。
• 不要一开始建设大而全智能体平台。先验证流程、工具、知识、评估和组织协作是否成立。

8.2 建议的近期动作

1. 建立一个“外部案例学习表”，持续跟踪本报告中的重点公司，字段包括能力、场景、来源、可信度和永辉可学习点。
2. 启动一次内部流程摸底，优先找供应链、门店、采购、物流中高频跨系统流程。
3. 组建小型 FDE 式小队：业务专家、产品、架构、后端、数据、AI 工程、运维/安全。
4. 选一个建议型智能体试点，目标不是自动化率最大，而是验证数据、工具、权限、评估和人工确认能否闭环。
5. 把试点结果沉淀成永辉自己的智能体建设规范，再决定平台化范围。

9. 来源

完整来源清单保留在本地原始文档目录：/Volumes/DevSSD/dev/workspace/yh/logistics-apps/docs/research/公司级智能体发展趋势与永辉建设参考调研来源清单.md。

本报告引用的资料以 2026 年公开信息为主。2025 年及以前资料只作为背景或演进说明。对厂商自述指标、媒体转载指标、未公开架构和未披露客户效果，报告均保留来源限制，不作为永辉可直接实现的结论。