Title: 连写 5 遍 SQL 后，他从“人肉 Agent”的荒诞感里，死磕出了一款企业副驾驶 | BestBlogs.dev
URL Source: https://www.bestblogs.dev/article/1dddd134?amp%3Butm_medium=feed&%3Butm_campaign=resources&%3Bentry=rss_article_item
Published Time: 2026-07-09 17:11:00
Markdown Content: 岑润哲在头部互联网公司做了五年量化运营，服务过一家又一家企业，每家都要从零搭一套全链路数字化运营平台。到第五家客户时，他突然意识到一个荒诞的事实：自己本质上是个"人肉 Agent"。每天从各个系统里拖数据、做归因、写结论、推动作，同一套方法论重复写了五遍 SQL、对了五遍指标口径、培训了五批分析师。 "真正稀缺的不是分析能力，是能被规模化复用的分析能力。"
这句话是他加入数势科技、把方法论产品化成 SwiftAgent 的底层逻辑。但真正从运营思维转向产品思维，最难迈过去的坎不是技术，是"克制"。
"人肉 Agent"的觉醒：从怎么快怎么来，到敢不敢做减法
做运营时，遇到一个业务问题，岑润哲可以直接为这个客户写一段专属逻辑，怎么快怎么来。但做产品负责人后，每个需求要先过一道筛子：这是这一个客户的特殊性，还是一类客户的共性？
"如果只为签下一单就把特例写死进主干代码，半年后产品会变成一堆补丁摞起来的 spaghetti code。"这种"延迟满足"的克制，他花了相当长一段时间才适应。
但完全不做定制化也不现实。他举了个鲜活的例子：指标定义的对齐流程、异常归因的分析路径、报告生成的模板结构，这几块已经基本完全产品化进 SwiftAgent 的语义层和 Agent 工作流——新客户接入时只需要做"映射"而不是"重写"。但巡店督导场景里的"整改追踪"环节，几乎每个客户都要改。零售连锁和金融网点的责任人层级、汇报链条、考核口径、SOP 知识库完全不同。同样是"督导发现问题后推动门店整改"，允许 AI 建议触达的颗粒度就不一样。这块没有继续硬编码，而是倒逼出了一个可配置的"流程编排层"——让客户自己拖拽定义责任链路，而不是团队每次改代码。
作为产品负责人，岑润哲用三类间接指标衡量自己的工作：客户从 POC 到规模化续约的转化率、单客户的 ARPU 增长曲线（新增模块/新增部门渗透）、以及交付边际成本是否在下降（同样一个新客户，接入周期是不是比一年前更短）。"三个指标合在一起，本质回答的是'产品化程度够不够高'。"
投资人最常问的问题不是功能有多炫，而是一句更扎心的话——"如果把你们最懂业务的那几个人换掉，产品还转不转得动？"这句话背后问的其实是：壁垒到底在系统里，还是在人脑子里。
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 不是在解决问题，是在用更快的速度把混乱传播给更多人。技术能加速对的决策，也能加速错的决策。区别在于——在按下加速键之前，你有没有确认过，这个团队对"对"的定义，到底有没有共识。