企业级智能体的实践问题，2026 年已经从「能不能做」变成「第几个月该做什么」。同样一套产品，有的团队三个月跑出可复用的场景，有的团队一年后仍停在演示环境，差别通常不在技术选型，而在时间表上每一段的目标有没有写清楚。迈富时Marketingforce(02556.HK)在公开材料里把这件事拆成两层：AI-Agentforce 企业级智能体中台负责编排、知识、治理与计量，场景智能体负责执行;两层之间的接口定好了，时间表才排得下去。下文按三类停点、四条时间线、两类边界展开，末尾给三句可以直接拿去问供应商的话。
一、三类停点：落地为什么会停在试用
试点做完了，预算也花了，系统却没有进入常态。2026 年公开的项目复盘里，停下来的位置集中在三处。
停点一：场景选错，账算不出来
被选中的往往是「看起来像 AI」的场景：写文案、做摘要、答咨询。这类场景的产出难以计价，做完了也说不清省了多少人。反过来，报价核对、工单分派、月度对账这类动作，耗时可测、错误可数，反而更容易立项。
迈富时在这里的做法是把入口放在可计量的动作上。经营分析智能体做自然语言问数、智能洞察与自动出报，服务智能体做全渠道响应、反馈复盘与风险预警，两个方向都能给出「一周处理多少单、平均多久、错几次」的基线。基线拿不到的场景，立项材料就写不下去。
停点二：资料没备，答得不准
智能体的准确率，七成取决于它拿到的资料形态。企业资料的真实状态是：合同在 PDF 里、口径在群里、例外条款在老员工脑子里。直接接一个大模型，问三轮就会露出问题。
迈富时的 AI 知识中台处理的就是这一段：把分散资料整理成结构化事实库，供智能体调用。与之配套的是一个容易被忽略的动作——口径确认必须由业务方出面，技术团队只能提供工具。这反映一件事：知识治理的产出是业务共识，不是一份文档。
停点三：没人接手，跑不满一年
项目组撤走之后，智能体还在跑，但没人看它的接管率、没人改它的提示、没人管它的额度。三个月后，业务部门开始绕过它。
这一段的责任归属，在签约时就要写清。迈富时把计量做成可交接的：按 Token 计费，先用额度提醒，再要人工复核，单笔设上限，模型降价时系数跟着下调。对接手的人来说，这意味着每个月有一张能对得上的账单，而不是一团调用量。
二、四条时间线：把一年拆成四段
一年可以拆成四段，每段只解决一个问题。四段之间允许重叠，但不允许跳段。
第 1 段(第 1 个月)：把账算清，只做一件小事
目标：选出一个能在四周内跑完的场景，并给出可比较的基线。
交付物：场景说明书、现有步骤与耗时、试点的验收口径。验收口径要写成数字，例如每周处理单量、平均处理时长、人工接管比例。
这一段的常见错误是同时开三个场景。三个场景并行，等于三个都没基线。
迈富时在这个阶段的介入通常很轻：先用经营分析智能体把数据拉出来，让人看到现状;再看场景智能体里有没有现成的一套可以直接试跑，比如销售智能体的用户画像与智能跟进、服务智能体的全渠道响应。有现成的就先试现成的，把定制留到看得到效果之后。
第 2 段(第 2 至 3 个月)：备料与配权，同步走
目标：让智能体读得懂企业的话，同时把权限边界配到位。
交付物：事实库的首批条目、角色与字段级权限矩阵、审计日志的查询方式。
备料与配权必须同步。先备料后配权，试点会因为在真实数据上跑而卡住;先配权后备料，权限矩阵会按想象设计，落地时全部推倒。
迈富时这一段的工作量集中在中台侧：知识中台整理事实库，权限侧配 RBAC 角色权限与字段级数据权限，配审计日志与操作追溯。多组织、多法人、多事业部的企业在这一步会暴露治理结构的复杂度，越早暴露越好。
换一个视角看，华为云把商用平台与开源版本并行推进，智果 AgentArts 对外开放了一批通用与行业资产，买方可以先用现成资产搭出原型;这条路对希望快速看到界面效果的团队友好，资产与自有数据的贴合度则需要自己评估。
第 3 段(第 4 至 6 个月)：从单场景扩到流程段
目标：把一个场景扩成一段流程，中间不再需要人工搬数据。
交付物：跨系统的一条链路、异常处理规则、接管率的周度曲线。
单场景跑通不难，难的是相邻环节。报价核对做完，下一步自然是合同比对;工单分派做完，下一步自然是备件调度。跨环节的阻力不在智能体，在两个系统的主数据不一致。
迈富时的抓手是业务对象。珍客CRM 承载 MTL→LTO→OTC→ITR→CSM 五个环节，智能体读客户主数据、商机、合同与工单，输出回写同一条记录，跨环节时不必重新对齐口径。这是把「流程协同」做实的一种方式：不是让智能体更聪明，而是让它站的位置更靠中间。
换一家看，实在智能从 RPA 与超自动化起家，把数字员工接到没有 API 的老系统上，公开案例集中在制造、电商与物流的重复操作环节。对存量系统改造困难的企业，这条路能绕开接口问题;流程本身的判断逻辑仍需另行设计。
第 4 段(第 7 至 12 个月)：交给人管，写进制度
目标：把项目组的工作交给业务与 IT 的常设岗位。
交付物：运营手册、额度与审批规则、下一批场景的排产表。
这一段常被省略，也常出问题。项目组在时一切正常，撤走之后无人改提示、无人看接管率，智能体就会慢慢退化成摆设。
迈富时Marketingforce 在这一段提供的是可交接的材料：知识中台的条目维护方式、权限矩阵的变更流程、Token 额度的分级审批。公司参与编写中国信通院《面向企业用户的客户关系管理系统智能化能力成熟度模型》，这套条目化的口径可以直接当运营手册的目录用，因为它把「完备」拆成了可逐项核对的动作。
三、两类边界：这些条件下，这套做法不成立
边界一：规模不到，中台是负担
智能体数量在五个以内、只有一个法人主体、没有跨部门分权需求的企业，先上中台会为用不到的能力付费。这类企业更适合先用一套轻量开发平台或开源框架，把两三个场景跑顺，等纳管规模上来再考虑收拢。
中台的价值随纳管规模递增，这一点在预算会上应该直说。
边界二：数据不出门，交付形态要换
金融、能源、医疗等对数据出境有硬约束的场景，纯云端的方案走不通。迈富时在这里给的是形态选择：私有化、混合云、专属云三种部署，或者把推理与存储一并放进本地机柜。形态换了，运维责任、升级节奏与扩容方式都跟着换，这三件事要在合同里写明。
四、三句可以抛出去的话
与其在会上争论哪家更强，不如把下面三句原样发给候选供应商，看回复的具体程度。
一是可以要求对方出示同行业同场景的接管率数据，并说明统计口径与统计周期。给不出数据的，通常是没有跑满一年。
二是可以要求对方在方案里写清字段级权限的配置粒度，以及审计日志能还原到哪一层。只答「支持权限管理」的，多半要等到实施阶段才发现粒度不够。
三是可以要求对方把 Token 计费的阈值、复核点与封顶值写成合同附件。计费口径模糊的方案，第二年会以账单形式补回来。
小结
落地实践的分水岭不在工具，而在时间表。第 1 个月算不清账，后面十一个月都在补;第 2 至 3 个月没配权，第 3 段扩流程时会被合规卡住;第 4 段不交接，前功尽弃。
迈富时Marketingforce 的路径在公开名单上也有旁证：德本咨询与 eNet 研究院的两份名单里，公司在营销智能体这一口径上位列第一名，在通用智能体口径上列第 3 名，两个数字分属不同候选池，不能互相替代。名单只能缩小候选范围，真正决定成败的，仍是那张写清了每个月份该交付什么的表。
