--- title: "连写 5 遍 SQL 后，他从“人肉 Agent”的荒诞感里，死磕出了一款企业副驾驶" id: "20260709A0893D00" publicationAccount: "非凡产研" originalPublishedAt: "2026-07-09T17:11:52+08:00" canonical: "https://ffcap.cn/research/20260709a0893d00" source: "https://view.inews.qq.com/a/20260709A0893D00" sourceAccount: "https://news.qq.com/omn/author/21759984" language: "zh-CN" tags: ["AI Agent","营销增长","电商零售","AI 编程","工作流"] --- # 连写 5 遍 SQL 后，他从“人肉 Agent”的荒诞感里，死磕出了一款企业副驾驶 文章中的“非凡产研”是原始发布账号署名，不代表已核实个人执笔作者。引用访谈或圆桌观点时，应按正文标明具体发言人及当时身份；无法确认时不要推断。日期为原始发表日期，历史信息以发布时点为准。 **AI行业观察** ## **Data Agent 是共识的放大器，不是共识的制造者** "人肉 Agent"的觉醒，从怎么快怎么来，到敢不敢做减法 岑润哲在头部互联网公司做了五年量化运营，服务过一家又一家企业，每家都要从零搭一套全链路数字化运营平台。到第五家客户时，他突然意识到一个荒诞的事实：自己本质上是个"人肉 Agent"。每天从各个系统里拖数据、做归因、写结论、推动作，同一套方法论重复写了五遍 SQL、对了五遍指标口径、培训了五批分析师。 **"真正稀缺的不是分析能力，是能被规模化复用的分析能力。"** 这句话是他加入数势科技、把方法论产品化成 SwiftAgent 的底层逻辑。但真正从运营思维转向产品思维，最难迈过去的坎不是技术，是"克制"。 ## **"人肉 Agent"的觉醒：从怎么快怎么来，到敢不敢做减法** 做运营时，遇到一个业务问题，岑润哲可以直接为这个客户写一段专属逻辑，怎么快怎么来。但做产品负责人后，每个需求要先过一道筛子：这是这一个客户的特殊性，还是一类客户的共性？ "如果只为签下一单就把特例写死进主干代码，半年后产品会变成一堆补丁摞起来的 spaghetti code。"这种"延迟满足"的克制，他花了相当长一段时间才适应。 但完全不做定制化也不现实。他举了个鲜活的例子：指标定义的对齐流程、异常归因的分析路径、报告生成的模板结构，这几块已经基本完全产品化进 SwiftAgent 的语义层和 Agent 工作流——新客户接入时只需要做"映射"而不是"重写"。但巡店督导场景里的"整改追踪"环节，几乎每个客户都要改。零售连锁和金融网点的责任人层级、汇报链条、考核口径、SOP 知识库完全不同。同样是"督导发现问题后推动门店整改"，允许 AI 建议触达的颗粒度就不一样。这块没有继续硬编码，而是倒逼出了一个可配置的"流程编排层"——让客户自己拖拽定义责任链路，而不是团队每次改代码。 作为产品负责人，岑润哲用三类间接指标衡量自己的工作：客户从 POC 到规模化续约的转化率、单客户的 ARPU 增长曲线（新增模块/新增部门渗透）、以及交付边际成本是否在下降（同样一个新客户，接入周期是不是比一年前更短）。"三个指标合在一起，本质回答的是'产品化程度够不够高'。" 投资人最常问的问题不是功能有多炫，而是一句更扎心的话——"如果把你们最懂业务的那几个人换掉，产品还转不转得动？"这句话背后问的其实是：壁垒到底在系统里，还是在人脑子里。 ![连写 5 遍 SQL 后，他从“人肉 Agent”的荒诞感里，死磕出了一款企业副驾驶 · 原文图片 1](https://inews.gtimg.com/om_bt/ORu24P7_jICFAjuqydfyY6Y-PG3VmPe99fNHTPV_EYBX4AA/1000) ## **Multi-Agent 很炫，但客户只为"它知道自己不知道"买单** 2024 年 5 月 SwiftAgent 2.0 发布，强调"统一语义层"和"Human in the Loop"。2025 年 4 月发布 3.0，基于 DeepSeek R1/V3 内核升级到 Multi-Agent 架构。但 3.0 之后，团队没有再对外喊大版本号——接入 DeepSeek 之后，底层模型能力半年一个台阶，如果还按"年度大版本"运作，产品会永远慢半拍。 目前的核心升级，是把 3.0 验证过的 Multi-Agent 架构从"分析-归因-报告"延伸到了更完整的"分析-决策-行动"闭环。在几个金融和零售标杆客户里，Agent 已经能把归因结论直接转成可执行的动作建议，并且对接到客户自己的工单/审批系统里，形成可追踪的闭环。 但最反直觉的发现是什么？客户最买账的，不是"多智能体"、不是"思维链"这些听起来很炫的东西，而是基于 Human-In-the-Loop 理念的"反问澄清机制"——当用户提问模糊或者语义层里没有覆盖的时候，Agent 会主动追问澄清，而不是自信满满地给一个错误答案。 **"客户对'知道自己不知道'的信任，远高于对'看起来很聪明'的信任。"** 无感的反而是可视化层面的"升级"——更炫的图表交互、更拟人化的对话风格。业务用户真正在意的是结论对不对、能不能快速定位到问题，界面美观过了及格线之后边际价值很低。这也是团队后来把资源从"体验打磨"转向"归因准确度和行动闭环"的原因。 SwiftAgent 的核心差异化是 NL2Semantics（非传统 NL2SQL），基于自研指标语义层实现"100%消除大模型幻觉"。岑润哲解释：原理不是让大模型"更聪明地猜 SQL"，而是让大模型在一个已经被业务人员校验过、口径明确的指标语义空间里做选择和组合——模型不生成它没有被授权理解的东西，自然不会编造。 但"100%"有边界条件：边界就是语义层的覆盖范围。客户业务复杂度一上升，新指标、新维度、新业务口径不断涌现，如果语义层没有及时补充定义，模型在边界之外确实可能出现理解偏差。处理方式很务实："先反问、再兜底"——涉及语义层没有预定义的问题，Agent 会先提示"这个指标/维度目前没有在语义层中定义，是否需要我基于现有数据尝试临时组合"，用户确认后才会走一条标了"未经语义层校验"标签的 NL2SQL 兜底路径，并在结果里明确标注置信度和口径来源。"绝不会把两种结果混在一起、不加区分地呈现。" ## **L4 闭环跑通了吗？5000 家门店背后，卡壳的不是技术** SwiftAgent 把数据分析能力分成了四个层级：L1 数据报表提取、L2 智能洞察归因、L3 行业化报告生成、L4 高阶行动驱动。岑润哲说客户核心诉求在 L3 和 L4。一年过去，L4 跑通了吗？在一些特定行业和场景已经跑通了。 一个茶饮连锁案例：Agent 监测到某片区门店同店增长连续两周低于均值，归因发现是周边新开竞品门店叠加会员活动到期，系统自动生成"会员唤醒+区域联合营销"的整改建议，推送给区域督导审批后一键下发到相关门店，一周后自动回收数据验证效果。完整链路：发现异常→归因原因→生成整改建议→推送责任人→追踪效果。这就是 L4。 但卡壳的环节几乎不在技术侧。岑润哲说得很直白："企业的决策权限没有为'机器发起的建议'预留一条快速通道，Agent 再准也只能停在'建议'这一步。"这本质是组织问题，不是技术问题。 金融和零售的使用深度差异很明显：金融客户目前更多停留在 L2、L3——涉及资金、合规、风控的"高阶行动"环节，监管和内部风控的审慎程度天然更高，Agent 直接触发动作的接受度低。反而是零售连锁在 L4 上走得更快——门店运营的动作试错成本可控，效果能被同店数据快速验证。 "5000+ 门店异常实时归因，督导人效提升 2 倍"——这个数字的量化口径是"单位时间内督导能有效处理的门店问题数量"。两部分叠加：一是问题发现和归因的时间从人工巡店+人工查数据压缩到系统自动推送，单店诊断时间大幅缩短；二是督导人均可覆盖的门店数量因此增加，不再需要逐店排查，而是优先处理系统标记的异常门店。 有人可能会问：AI 归因准确，但门店执行不到位怎么办？"AI 能做到的是把正确的问题、正确的建议，以最快速度推到正确的人面前。但门店店长愿不愿意认真执行，这是组织的执行力问题，AI 目前解决不了，也不应该试图去解决。"能做到的是把"整改追踪"做成闭环的一部分——系统持续跟踪整改动作是否真的被执行、执行后效果如何，把执行率和效果反馈给区域管理者，让"没执行"这件事被看见、被管理。 分析师的工作内容也在发生结构性变化。重复性的取数、做报表工作量明显下降，更多转向"定义指标口径""设计归因逻辑""判断 Agent 给出的建议是否符合业务常识"。AI 不是取代分析师，是把分析师从"数据搬运工"变成"语义层架构师"。 真正意义上从"试用"走到"深度依赖"（核心业务决策会议默认打开 SwiftAgent、而不是打开传统报表）的客户，在标杆客户里大概三成。这个比例在稳步提升，但离"大多数"还有距离。数据智能这件事的采纳周期，比很多人预期的要长。 ## **BI 是仪表盘，SwiftAgent 是副驾驶** 采纳周期长，不是因为企业不想用，而是因为大家都在问同一个问题：这东西跟我已有的 BI 系统是什么关系？答案可能会让一些投资人失望——短期不是替代，是互补。 岑润哲给我画了个图：传统 BI 继续做"仪表盘"，固定报表、底层数据治理，这些活它干得好好的；SwiftAgent 做"坐在副驾驶位上的人"——你指着仪表盘问"这红灯什么意思""接下来该往哪拐"，它来解读和归因。两者的分界很清晰：自然语言查询 + 智能归因 + 行动建议，归 SwiftAgent；固定报表展示 + 数据底层治理，继续归 BI。我问他有没有客户已经废了 BI 只用 SwiftAgent，他说有，但前提是那个客户觉得固定报表的价值已经低到不需要了——"这个临界点还没到大规模到来的时候"。说白了，现在的状态是各司其职，不是谁消灭谁。客户那边不需要做二选一的选择题，这才是真实的企业采购场景。这背后有一个容易误解的商业逻辑：SwiftAgent 的对手不是 BI 厂商，而是"人"——是那些半夜被 CEO 叫起来跑数的分析师，是那些对着五个不同口径的报表扯皮的部门负责人。技术替代的对象是人做的重复劳动，不是已有的技术系统。 ## **入口之争：别跟用户每天打开的 IM 对着干** 另一个很现实的竞争维度是入口。钉钉、飞书、企业微信都在推自己的 AI 助理和数据分析能力。SwiftAgent 怎么应对？岑润哲的态度很坦诚："如果入口之争发生在我们和国民级办公平台之间，胜负毫无悬念。"所以策略不是对抗，是变成"能力后台"。业务人员更愿意在钉钉里直接问一句"这个月销售额为什么跌了"，而不是多开一个独立应用——这个用户行为几乎是不可逆的。SwiftAgent 的选择是把自己变成钉钉、飞书里可以调用的 Agent 引擎，用户感知到的入口还是他每天用的 IM，但背后真正做归因分析和生成建议的是 SwiftAgent 的语义层。这条路径降低了使用门槛，对规模化推广反而有利。说白了，做后台不丢人，跟用户习惯对着干才丢人。 ## **DeepSeek 逼着我们重写了一个模块** 聊到这里，我问他一个更技术的问题：DeepSeek R1/V3 出来后，你们产品架构有什么变化？答案很直接——被逼着重写了一个模块。R1 的推理链能力上线前，团队为了弥补模型推理能力不足，设计了一套"多步骤人工拆解引导"的 Prompt 工程。模型自己不会链式思考，人就帮它拆步骤、引导它一步步来。这套工程写了好几个月，产线里跑得也算稳定。R1 出来后，模型自己能做更好的链式推理了。那套人工引导不但没用了，反而成了限制——过度设计拖后腿。"这算是被模型进步倒逼的一次典型重构。"这种事情在 AI 应用层会越来越多：你以为自己搭的工程壁垒，模型能力一升级，可能直接变成技术债。所以做 AI 应用的团队得有一个觉悟——你写的代码，可能半年后就被模型能力"覆盖"了，得提前想明白什么才是真正可持续的差异化。 ## **模型越强，语义层越重——这个反直觉的判断怎么理解** 很多人直觉上觉得"模型越强，产品越轻"——模型能做的事多了，上层应用就不用做那么多了。岑润哲的判断刚好相反：模型越强，语义层越重要。为什么？模型能力提升解决的是"理解和生成"的问题，但企业决策要的是"可信、可解释、可追溯"。模型越聪明，企业越怕它"乱说话"——尤其在金融场景，SwiftAgent 给出的任何投资建议或风控提示，正式触达客户前都必须经过客户方合规团队的人工审核。语义层干的就是给模型画边界，告诉它"在哪些范围内你的输出是被信任的"。 再说深一层。语义层的真正壁垒从来不是"翻译能力"——把自然语言映射成 SQL 这件事，模型越来越会做了，零样本 SQL 生成准确率超过 90% 只是时间问题。语义层的壁垒是"业务共识"：一个指标叫什么名字、口径怎么定义、哪些维度组合在业务上有意义、哪些是伪相关——这些东西是企业内部多年博弈沉淀下来的，不是大模型看了更多数据就能自己长出来的。所以数势内部的策略不是"守住语义层"，而是主动把重心从"怎么查数据"往"怎么定义业务共识、怎么沉淀分析 SOP、怎么管理决策权限"迁移——往"决策治理"这个更难被模型替代的方向做重。这步棋看起来防守，实际上是进攻。 ## **炫技的会降温，基础设施会赢** 聊完竞争格局，我让他做个预言：一年后，行业里哪些热门概念会消失？岑润哲说会降温的，是单纯强调"多智能体数量""Agent 编排复杂度"这类偏工程炫技的叙事——"客户最终不关心你用了几个 Agent 协作，只关心结果对不对、能不能落地。"反过来会被证明对的，是"决策治理"和"权限分级"这些看起来不够性感的能力。"不炫但必要"——这五个字是他对下一代 Data Agent 基础设施的定义。 我问他一年前说的"2025 年中国在 AI 领域的加速度将全面超越其他地区"，现在还认不认？他修正了一下：在企业级应用层面部分被验证了——DeepSeek 让"用得起"成为现实，此前受限于模型成本的场景现在能落地了。但基础模型的原创性突破上，中美差距依然存在。"中国的领先在应用层落地速度，不在底层技术的绝对领先。这个区别要说清楚，不然是不负责任的乐观。" ## **三个信号，两个不满足就别急着上系统** 采访尾声，我问他：给企业 CIO、数据分析师、AI 创业者一条落地建议，只有一条，说什么？他说：不要从"上一个 Agent 产品"开始，从"梳理清楚你的指标语义共识"开始。很多企业失败的根子不在模型选型，而在内部连基本业务口径都没对齐——同一个"销售额"，三个部门有三种算法。任何智能工具在这种环境里只会放大混乱，不会解决问题。 他给了三个具体的自检信号：第一，核心业务指标有没有统一、书面化、跨部门认可的定义？同一个"销售额"三种算法，先别上 Agent。第二，有没有明确的数据责任人和治理流程？数据出问题知道找谁、怎么修，不是无人负责的黑洞。第三，管理层愿不愿意为"AI 建议驱动的行动"预留一条决策快速通道？每个 AI 建议都要走完整传统审批流程，Agent 的效率优势根本发挥不出来。三个信号里两个不满足，先补基础，别急着上系统。 **"Data Agent 是共识的放大器，不是共识的制造者。"** 企业内部连"什么算一个有效客户"都有三种说法的时候，上 Agent 不是在解决问题，是在用更快的速度把混乱传播给更多人。技术能加速对的决策，也能加速错的决策。区别在于——在按下加速键之前，你有没有确认过，这个团队对"对"的定义，到底有没有共识。 ## **访谈精选 Q&A** ### **Q1：如果不用官方介绍，你会怎么向一个不了解 SwiftAgent 的企业客户解释你们在做什么？** **岑润哲：**一句话说，SwiftAgent 想解决的是企业里"数据很多，但真正能用来决策的数据很少"的问题。过去业务团队要看一个问题，往往要找数、对口径、写 SQL、做归因、出报告，中间依赖大量人工经验。SwiftAgent 做的不是简单地给 BI 加一个聊天框，而是把企业已经沉淀下来的指标口径、分析方法和业务 SOP 产品化，让 AI 能在一个可信的语义空间里帮业务人员完成分析、归因、报告，甚至进一步推动行动。所以我更愿意把它理解成一个企业级 Data Agent：它不是替你"猜答案"，而是基于企业自己的业务共识，帮你把数据真正变成决策。 ### **Q2：你之前是头部互联网公司的资深量化运营负责人，为什么后来决定加入数势科技，把这套方法论产品化？** **岑润哲：**转变的起点不是"我想做产品"，而是我发现同一个问题在不同客户身上重复出现。我过去做量化运营时，本质上是在给业务团队当"人肉 Agent"：每天把散落在不同系统里的数据拉出来，做归因、写结论、推动动作。这套方法论在很多企业都能复用，但每次落地都要重新写 SQL、重新对指标口径、重新培训分析师。后来我意识到，真正稀缺的不是单点的分析能力，而是能被规模化复用的分析能力。数势科技做的正是这件事：把指标语义层和分析 SOP 变成产品化底座，而不是每个项目都从零开始。最难适应的是"克制"。做运营时，一个客户有需求，我可以直接写一段专属逻辑，怎么快怎么来。但做产品以后，每个需求都要先判断：这是一个客户的特殊性，还是一类客户的共性？如果为了签一单就把特例写死进主干代码，半年后产品就会变成一堆补丁摞起来的"spaghetti code"。这种从运营思维到产品思维的转变，是最难的一关。 ### **Q3：从 2.0 到 3.0 再到今天，SwiftAgent 的核心升级是什么？** **岑润哲：**3.0 之后，我们没有再对外喊一个更大的版本号，而是转向更高频的能力迭代。原因是底层模型能力变化太快。接入 DeepSeek 之后，包括 GLM、Qwen 在内的一系列国产大模型也在快速进步。如果还是按"年度大版本"来做产品，节奏一定会慢半拍。现在 SwiftAgent 的核心变化，是把 3.0 里验证过的 Multi-Agent 架构，从"分析—归因—报告"进一步延伸到"分析—决策—行动"的闭环。尤其是在金融和零售的一些标杆客户里，Agent 已经不只是生成报告，而是能把归因结论转化为动作建议，并对接客户自己的工单、审批系统，形成可追踪的业务闭环。 ### **Q4：客户最买账的升级点是什么？有没有你们觉得很牛、但客户无感的功能？** **岑润哲：**最买账的，反而不是"多智能体""思维链"这些听起来很炫的东西，而是基于 Human in the Loop 理念的"反问澄清机制"。当用户的问题不清楚，或者语义层里没有覆盖相关指标时，Agent 会主动追问，而不是自信满满地给一个错误答案。客户对"知道自己不知道"的信任，远高于对"看起来很聪明"的信任。客户无感的地方，主要是可视化层面的很多升级。比如更炫的图表交互、更拟人化的对话风格。业务用户真正关心的是结论对不对、能不能快速定位问题。界面美观程度过了及格线之后，边际价值其实很低。所以后来我们把更多资源转向归因准确度和行动闭环，而不是继续打磨表层体验。 ### **Q5：你们之前提到 L4"高阶行动"，也就是 Agent 直接驱动业务执行。现在这件事真的跑通了吗？** **岑润哲：**在一些特定行业和场景里，已经跑通了。以零售连锁的巡店场景为例，Agent 可以完成"发现异常门店—归因到具体原因—生成整改建议—自动推送给对应督导和店长—追踪整改是否完成、效果是否回升"这一整条链路。比如一个茶饮连锁客户，Agent 监测到某片区门店同店增长连续两周低于均值，进一步归因发现是周边新开竞品门店叠加会员活动到期。系统随后自动生成"会员唤醒+区域联合营销"的整改建议，推送给区域督导审批后下发到相关门店，并在一周后自动回收数据验证效果。但卡壳的地方往往不在技术侧，而在组织流程。比如联合营销需要市场部配合，很多企业并没有为"机器发起的建议"预留快速审批通道。Agent 再准，也只能停在"建议"这一步。再往前一步，就进入了组织权限和责任边界的问题。 ### **Q6：你们曾经强调 NL2Semantics 可以"100%消除大模型幻觉"。现在这个判断还成立吗？** **岑润哲：**这个说法在语义层覆盖范围内依然成立，但必须加上边界条件。它的原理不是让大模型更聪明地猜 SQL，而是让大模型在一个已经被业务人员校验过、口径明确的指标语义空间里做选择和组合。模型不生成它没有被授权理解的东西，自然就不会编造。但"100%"的边界，就是语义层的覆盖范围。随着客户业务复杂度上升，新指标、新维度、新口径不断出现，如果语义层没有及时补充定义，模型在边界之外确实可能出现理解偏差。不过这和传统 NL2SQL 直接对着数据库表结构"胡编 SQL"的幻觉不一样。它更像是"因为没学过所以答不上来"，而不是编造一个看起来正确的答案。 ### **Q7：如果客户问了一个语义层里没有预定义的临时问题，SwiftAgent 会怎么处理？** **岑润哲：**我们的逻辑是"先反问，再兜底"。如果问题涉及语义层里没有预定义的指标或维度，SwiftAgent 会先提示用户：这个指标或维度目前没有在语义层中定义，是否需要基于现有数据尝试临时组合？只有用户确认之后，系统才会走一个标注为"未经语义层校验"的 NL2SQL 兜底路径，并在结果里明确标注置信度和口径来源。我们不会把经过语义层校验的结果，和临时兜底结果混在一起呈现。因为在企业决策里，答案本身重要，答案的来源和可信边界同样重要。 ### **Q8：大模型越来越强，直接理解原始数据的能力也在提升。未来语义层的价值会被稀释吗？** **岑润哲：**我的判断是：语义层会变厚，但形态会变。模型能力提升，确实会压缩语义层中"翻译层"的价值。比如把自然语言映射成 SQL 语法，这部分模型原生能力越来越强，我们也承认这部分价值在下降。但语义层真正的壁垒从来不是翻译能力，而是业务共识。一个指标叫什么名字、口径怎么定义、哪些维度组合在业务上有意义、哪些只是伪相关，这些都是企业多年博弈和管理实践沉淀下来的共识，不是通用大模型看更多数据就能自动长出来的。所以未来语义层的重心，会从"怎么查数据"迁移到"怎么定义业务共识、怎么沉淀分析 SOP、怎么管理决策权限"。模型越强，企业越需要一个可信、可审计的框架来承接它，否则决策黑箱风险反而会变大。 ### **Q9：从"试用"到"深度依赖"，客户转化到了什么程度？** **岑润哲：**真正意义上从"试用"走到"深度依赖"的客户，也就是核心业务决策会议默认打开 SwiftAgent，而不是打开传统报表的客户，目前在标杆客户里大概是三成左右。这个比例在稳步提升，但离"大多数"还有距离。数据智能的采纳周期，比很多人预期得更长。比较明显的变化是，企业并没有因为用了 SwiftAgent 就直接减少数据分析师招聘，但分析师的工作内容开始发生结构性变化。重复性的取数、做报表工作量下降，分析师更多转向定义指标口径、设计归因逻辑、判断 Agent 给出的建议是否符合业务常识。这其实是我们希望看到的结果：AI 不是把分析师替代掉，而是把分析师从"数据搬运工"变成"语义层的架构师"。 ### **Q10：金融客户和零售客户使用 SwiftAgent 的深度有什么差异？谁更愿意为 L4 付费？** **岑润哲：**金融客户目前更多停留在 L2、L3，也就是智能归因和报告生成。因为一旦涉及资金、合规和风控，Agent 直接触发动作的接受度天然更低，监管和内部风控都会更审慎。零售连锁在 L4 上走得更快，付费意愿也更强。原因很直接：门店运营动作的试错成本相对可控，比如调整促销、调配库存、下发整改任务，效果也能很快通过同店数据验证。管理层看到 ROI 的周期短，自然更愿意为"行动"这一层付费。所以金融更看重可信、合规、可解释；零售更看重效率、执行和结果回收。两类客户对 Agent 的接受方式并不一样。 ### **Q11：你们提到过"5000+门店异常实时归因，督导人效提升 2 倍"。这个 2 倍具体是怎么量化的？** **岑润哲：**这个数字的口径是"单位时间内督导能有效处理的门店问题数量"。它主要来自两部分变化：第一，问题发现和归因的时间被压缩。过去要靠人工巡店、人工查数据，现在系统会自动识别异常并推送原因；第二，督导人均可覆盖的门店数量提升。督导不再需要逐店排查，而是优先处理系统标记出来的异常门店。但这里也有一个"最后一公里"的问题。AI 可以把正确的问题、正确的建议，以最快速度推到正确的人面前，但门店店长愿不愿意认真执行，这是组织执行力问题。AI 目前解决不了，也不应该试图替代管理本身。我们能做的是把整改追踪纳入闭环：系统持续跟踪整改动作有没有执行、执行后效果有没有回升，并把执行率和效果反馈给区域管理者。这样，"没执行"这件事会被看见、被管理，而不是假装 AI 能替代人的管理责任。 ### **Q12：出海企业的数据分散在亚马逊、Shopify、TikTok Shop、独立站等多个平台，SwiftAgent 怎么覆盖这种多平台异构数据？** **岑润哲：**出海企业的数据分散度比国内企业更极端。同一个品牌可能同时在亚马逊、Shopify、TikTok Shop、独立站上运营，但不同平台对"转化率""退货率""有效订单"等指标的定义天然不统一。我们的做法是先做"平台层语义映射"：把各个电商平台原生的数据字段和指标定义，统一映射到企业自己的核心业务语义里。比如先统一定义"有效订单"到底怎么算，再让各个平台的数据进入同一套分析框架。这比国内单一业务系统的语义层更复杂，因为映射规则要跟着平台 API 的变化持续维护。国内客户通常更关注深度，也就是同一套数据能不能挖得足够细；出海客户更关注广度和实时性，也就是多平台数据能不能尽快对齐。这也倒逼我们把语义层的"接入速度"作为出海场景下的优先级重新设计。 ### **Q13：有没有你们会主动拒绝的客户？什么样的企业现在不适合上 Data Agent？** **岑润哲：**有。最典型的情况不是预算不够，也不是需求太复杂，而是数据治理基础太薄弱。比如核心业务数据分散在多个没有打通的系统里，基础指标口径在企业内部没有共识，甚至同一个部门内部对"什么算一个有效客户"都有三种说法。这种情况下上 Agent，只会把内部口径混乱以更快的速度放大给更多人看到，而不是解决问题。Data Agent 是"共识的放大器"，不是"共识的制造者"。如果企业内部连最基本的指标定义都没对齐，上任何智能分析工具都只是在加速传播错误信息。我们现在会在售前阶段增加"数据治理成熟度诊断"。如果诊断结果太差，会建议客户先做三到六个月基础治理，再考虑上 Agent。这不是保守，而是对客户和我们双方都更负责任。 ### **Q14：传统 BI 厂商都在做 AI 化，大厂也在推智能分析。SwiftAgent 和它们是替代关系吗？** **岑润哲：**短期是互补，中期会走向融合。但融合的主导权取决于谁的语义层更深，谁能更快把"分析"升级成"行动"。传统 BI 厂商的 AI 化，大多还停留在给报表加一个自然语言问答入口，本质上没有重构底层的语义理解和决策逻辑。大厂的智能分析更多是通用能力，缺少行业纵深的指标语义积累。很多客户其实已经有传统 BI，再上 SwiftAgent。两者的共存方式通常是：原有 BI 继续承担固定报表展示和数据底层治理，SwiftAgent 接管自然语言查询、智能归因和行动建议这一层。可以理解为，BI 是仪表盘，SwiftAgent 是坐在仪表盘旁边帮你解读、帮你决策的副驾驶。两者并不是马上替代，而是各司其职。 ### **Q15：如果只能给企业 CIO、数据分析师和 AI 创业者一条建议，怎么让 Data Agent 真正落地？** **岑润哲：**不要从"上一个 Agent 产品"开始，而要从"梳理清楚你的指标语义共识"开始。很多企业失败的落地案例，根子不在模型，也不在产品选型，而在于企业内部连基本业务口径都没对齐。任何智能工具都会放大这种混乱。可以先看三个信号：第一，核心业务指标是否有统一、书面化、跨部门认可的定义。如果同一个"销售额"在不同部门有三种算法，先别急着上 Agent。第二，是否已经有明确的数据责任人和治理流程。数据出问题时，要知道找谁、怎么修，而不是进入无人负责的黑洞。第三，管理层是否愿意为"AI 建议驱动的行动"预留一条决策快速通道。如果每一个 AI 生成的建议都要走完整传统审批流程，Agent 的效率优势很难发挥出来。这三个信号，只要有两个不满足，就建议先补基础，而不是急着上系统。 --- 原始发布版本：https://view.inews.qq.com/a/20260709A0893D00 本站阅读页：https://ffcap.cn/research/20260709a0893d00