高德本地生活分析 Agent 的 AI Native 实践全景

原创 钟雨洁 2026-09-30 18:08 浙江  从整体架构，到分析流程、知识与语义治理、经营分析智能体的具体建设，本文或许能提供一些经验和参考  这是2026年的第 66 篇文章 （ 本文阅读时间：约 30 分钟 ） FY27 的 S1 过去了。回头看这半年，像一场拉长的复盘：一个问题刚以为讲清楚了，下一个问题又摆到桌上。这个 S1，作者主要在建设**高德本地生活分析 Agent**。原以为分析流程跑通，就能往前迈一大步，后来才发现，**口径、知识、推理和交付**，每一处都有需要重新想清楚的问题。这半年确实不轻松，但也正是在这些反复里，慢慢看清了两件事：系统应该怎么建；作为 BI，应该把精力放在哪里。 💡 全文约 1.2 万字，预计阅读 30 分钟，可按需选读。 想了解背景与架构，看第 1—3 节；想看具体实现和踩坑经验，直接进入第 4 节；关心 AI 时代 BI 的定位与个人成长，可以从第 5—6 节读起。 这篇文章整理了这段实践的全景：从**整体架构，到分析流程、知识与语义治理、经营分析智能体**的具体建设，也记录了踩过的坑、做过的取舍，以及这些经历怎样改变了作者对 BI 的理解。到这个 S1 末，这套体系支撑了本地生活多个业务单元的例行经营诊断，全行业经营简报一小时内产出。希望其中一些经验，能帮正在做类似探索的同行少绕一点路。 01 背景与项目缘起： 报告交付之后，经营问题还在继续 作为 BI，会很熟悉一种场景：收入下降了，查数、核对、拆解，终于把分析交了出去。业务接着会问，这个变化要不要处理，先动哪个环节，手头正在做的事情有没有用？报告写完了，讨论才刚刚展开。 这些问题也是我想参与的。但日常工作里，大量时间花在澄清需求、确认口径、取数和核对上。业务、BI 和数据开发一起完成一份分析；换个问题，又要重新找人、找材料。许多经验明明积累下来了，下一次还是得再讲一遍。 自 S1 起，高德推进 BI AI 化，方向正好对着这些问题：**让业务能更自主地获取可信数据，让分析更深入地参与决策**。我负责的，是其中**面向本地生活业务的数据分析智能体**。 在这个项目里，我的做法是把已经弄清楚的业务关系和分析方法留下来，下一次直接用：**业务知识整理进知识库，分析方法写成 Skills，让 Agent 调用数据和工具完成分析**。省下的时间，可以回到那些报告之后还没谈完但却最需要人参与的问题上。  图1 AI时代的BI工作与协同边界 vs 传统时代 下面想分享的，就是这段建设经历：*哪些地方跑通了，哪些地方返过工，以及这些返工怎样改变了我对 BI 的理解*。 02 L0–L4 能力分级：  从回答一个数，到支撑一个判断 要交代这段建设，得先说明白我们手里这件事做到了哪一步。团队内部讨论“为什么下降”这类问题时，需要一把对齐能力的尺子：结合行业调研和业务场景，**我们形成了****BI 能力的 L0–L4 分级**，用它来对齐进展——现在能做到哪一步，下一步还缺什么。 团队早期主要处于 **L2 智能问数阶段**。用户问“上周收入是多少”，系统准确理解口径、找到数据并返回结果，就已经能解决30%以上的需求了。 再追问一句“为什么下降”，需要的能力就不同了。  图2 智能分析演进路线 按这套分级看，我认为我们现在**绝大部分任务已具备 L3 的特征**，开始回答“收入为什么下降”。系统要沿业务链路排查，并拿出支持解释的证据。 组织内**部分场景已经走到了 L4**，把分析接到决策与行动上。这里的 **L4 不等于无人化：****系统自主完成分析并给出建议，人参与关键取舍，并带回执行反馈**。本地生活分析 Agent 的实践主要在做 L3 的分析建设，也开始向经营研判延伸。至于自主执行、业务反馈怎样回到下一次分析，还在后面的建设计划里。 而从 L2 跨向 L3，首先要填的就是这个坑：**让系统真正理解一门具体生意里的“下降”在说什么**。这也是本地生活数据分析 Agent 的第一步。 03 三层能力框架总览： 把经营问题带进建设选择里 我最初从广告经营分析切入，后来扩展到休娱丽人、生活服务等到店行业。第二个行业的接入比预想中更费力：例如同样是“收入下降”，收入逻辑、指标口径和分析路径都可能不同，已有经验不能直接搬过去。  图3 同一个变化，可能对应不同的经营问题 每接一个行业都重新做一遍，也不现实。我的主要设计和建设，**把共用方法与行业差异整理进三层框架****。**  图4 整体建设框架：当前重点是知识、分析与主动触达；追问权限、跟踪复盘和反馈闭环仍在完善 ### 3.1 基础底座：让经验能被下一次分析用上 **先从最底下这层说起，从基础底座看分析依据。**分析师看到指标，已经知道它在说谁、按什么口径计算、和哪些动作有关，数字本身并不包含这些理解。我需要把它们整理成共享知识，连上指标与数据来源，供 Agent 每次分析读取。 知识还会变。一次分析用了哪版口径、哪份材料，出了分歧得能找回来，所以我让任务使用**固定版本的知识快照**。后续修订知识、管理权限，也需要能追溯影响。 ### 3.2 分析能力：顺着经营问题组织方法 **底座解决“分析依据什么”，中间这层要解决“怎么分析”。**比如，定位到某个城市贡献了较大降幅，还不能解释原因。系统得知道接着查什么，怎样结合已有动作研判。我用 Skills 写分析方法，用 Pipeline 连接步骤，先做经营状态识别、归因诊断和策略研判，再向跟踪复盘延伸。 这里一直有个取舍：哪些步骤写进工程化程序，哪些交给模型判断？**我的做法是****让程序负责计算和明确规则，模型结合知识解释业务，人参与关键取舍****。**具体的边界，是在返工中逐渐划清的。 ### 3.3 产品交互：先把重要发现送到人面前 分析做出来，还要考虑业务会怎样用。我选择**先做主动触达**，因为业务负责方需要及时看到重要变化，省去查找和筛选。因此，**推送摘要先给判断，完整报告再展开解释****（展示什么、以什么样的形式展示，真的很重要）**。 如果面向一线业务人员和分析师，我会作不同的选择。他们常常带着具体问题来，查完还要补条件、比数据、验证想法，**交互问答与自助分析**则会更适合这类工作角色。  图5 按主要任务选择入口，主动触达与按需探索可以衔接 当然，业务负责方收到推送也会追问。但问答能力目前卡在**权限衔接**：用户从一个行业追问到另一个行业，或从全国总盘追问到某个城市时，系统都要确认他能看哪些知识、数据和结果。我们打算先支持已授权报告内的追问，再扩展到新的取数和分析。 框架搭好，只是建设的开始。真正动手之后，最费力的部分常出在那些看起来已经做完的环节里——下一节讲的三段返工，都从这个框架里长出来。 04 三段实践，三次重新理解 S1 做了很多尝试，我想挑三段相互交叉且最重要的经历来讲：**分析执行、知识复用、经营判断**。 每一段都从一次返工开始，也以一次对框架的重新理解收尾。 | | | | | --- | --- | --- | | **实践** | **最初遇到的问题** | **调整后的建设重点** | | 分析执行 | 归因算出来了，报告仍然浅 | 保留证据、明确分析路径、用案例回归 | | 知识复用 | 文档有了，换个任务还是用不好 | 按需加载、独立修订、追溯指标口径 | | 经营判断 | 数字正确，业务判断仍可能出错 | 补齐背景、释放推理空间、审阅语义 | 三段实践在框架里的位置并不相同：**分析执行主要落在分析能力层，知识复用落在基础底座，经营判断则由二者共同支撑**。 ### 4.1 分析流程与工程化：让分析跑起来 **最先要解决的，是让经营状态识别和深入归因诊断跑起来。**分析师平时顺手完成的检查，交给 Agent 后都得重新说清楚。第一个很具体的麻烦，就出在一个简单的除法上。 ### 4.1.1 指标校验与分析规则设计： 同一指标差了 12% ，先回到取数环节 一次行业接入中，用总量除以对象数量，得到的平均值与直接查询结果相差约 **10%**。追查发现，分子与分母来自两套数据源，统计范围没有对齐。我们统一来源与口径，核验“总量＝对象数量×平均值”，闭合后才继续归因。 数字对齐后，归因才能继续。但算出平均值是主要下降因子，还得解释它为什么下降。我也开始检查，扫描规则有没有把不同的业务情况混为一谈： * **目标与趋势。** 达标仍要检查趋势和内部因子；未达标但趋势稳定，不能直接判为经营恶化。 * **变化与节奏。**跨月周报除比较上周，还看上月同一周和去年同期，避免把月末到月初的正常变化当成异常。 这些区别，分析师通常会结合背景判断。交给系统后，计算口径和判断条件都得明确，否则后面的解释很容易跑偏。 ### 4.1.2 上下文设计与报告质量校验：归因已经算出来，为什么报告还是浅？ 后来遇到的一个问题更隐蔽：Agent已经算出了单维度和组合维度归因，报告却没有呈现。沿着“引擎输出→报告组装→写作输入”查下去才发现，一处只留前三项，另一处把组合分析移进了备查区。写作模型只读正文，它根本没见到这些证据。 找到原因后，我在输入里保留重要组合的贡献度、异常判断和定位线索，再用关键证据清单核对成稿，遗漏就退回修改。至于模型怎样综合这些组合、怎样组织表达，我留了空间，没有要求每条材料都套同一句式。 沿着写作输入，还查出了“报告像分析日志”的原因。程序会先生成带内部标签的草稿，模型润色时也把“机制已坐实”这样的措辞带进了报告。后来我让模型**直接读取结构化事实与归因结果完成诊断写作，再用业务表达样例（Golden Cases）校准措辞**，检查标签残留。  图6 计算完成、进入上下文、出现在成稿中，是三个需要分别检查的位置 ### 4.1.3 Agent Handoff 设计：两个开发 Agent 接力，交接文件也会成为负担 前面这些修改，开发过程本身也在用 Coding Agent。考虑数据敏感性，行业接入的一段开发中，我让两个 Agent 交替承担方案审查、实现和验证，通过共享文件交接。“场域枚举用英文，不能直接传中文”这样的接口细节也会记下来，免得换个会话又踩一次坑。 问题是，交接文件越写越长，当前状态和历史过程混在一起。接手的 Agent 要先从中找出哪些决定还有效。我把入口收拢成几十行当前摘要，留下**有效决策、待办和验证状态**，历史过程另外归档，需要时再读。 **交接之后还要检查改动有没有影响原有能力**。接入新行业时，Agent 会重跑已有广告案例，我再审阅分析和业务表达。审阅意见不只是验证，也会暴露新的缺口——下一小节的能力补齐，就从其中一条开始。 ### 4.1.4 反馈驱动的能力迭代：一句“没有继续下钻”，要改到哪一层？ 审阅中就有这样一条反馈：报告定位到某个转化环节便停住了，没有继续下钻。这次材料没有丢，缺的是后续分析路径。我把分析继续拆到对象状态和使用过程：从纳入统计的对象追到实际使用对象，再分别检查首次使用与持续使用，区分“尚未开始”和“开始后未能持续”。 前一次“归因算出来却没写出来”，要修**证据传递**；这次则要补**分析路径**。再收到“分析不够好”的反馈，我会**先看问题发生在哪一层，再决定补方法、补知识还是改实现，最后拿案例重跑**。  图7 开发过程中的反馈循环；业务决策与执行的闭环，还需要后续建设 几次返工下来，我会严格检查证据有没有传到、该查的路径有没有走到；材料齐了以后，怎样综合和表达，就让模型多作判断。 💡 回头看，这一段让我重新理解了“跑通”的含义：跑通不是流程走完，是证据传递和分析路径由工程兜底，深度推理、综合与表达留给模型判断。工程把确定性做满，模型把判断力放开。 （为保证数据准确性，在垂直分析Agent中做了特定分析路径的工程兜底） ### 4.1.5 Demo：一份经营诊断月报，怎样组织分析 一路补到这里，一份诊断报告怎么组织，才算有了样子。读者最终看到的报告，大致是下面的样子。这份改编示例呈现了增长质量判断、原因比较和策略取舍。  图8 能力展示示例，内容经改编（业务信息与数值以脱敏占位展示） 要让这样的分析换个行业也能做，还得补上业务前提。哪些对象被纳入统计，怎样算开始使用，怎样算持续使用——这些分析师默认知道的区别，Agent 得从哪里获得？ ### 4.2 知识库与语义治理：让经验跨业务复用 为了建语义库，我回头去整理线上分析师知识库、业务规划和复盘文档。材料里有收入机制、指标口径，也有分析师的经验，但它们原本是写给人看的。**要让 Agent 用得上，先得处理知识怎么提炼（蒸馏），再考虑放在哪里（结构）、怎样持续更新（保鲜）**。 ### 4.2.1 知识蒸馏与按需加载：文档收齐了，为什么分析还是用不好？ 拿一份复盘来说，里面可能同时写着经营现象、原因判断、当期策略和历史口径。压缩成摘要，Agent 能知道这次发生了什么；下一次遇到类似问题，具体先查什么，摘要未必说得清。 所以我先把**事实、机制、策略与口径**拆开，再按分析时的用途整理成三个层次，输出规范另外维护： * **行业知识：读懂这门生意。**行业文件保留业务模式、核心公式、口径和诊断起点；季度策略、事件和口径变更另放主题文件，区分稳定规律与当期情况。 * **分析框架：知道沿什么顺序排查。**根据业务经营框架组织问题，形成分析路径，收入、交易规模等结果性指标按照业务指标树拆解到影响因子。 * **分析方法：把判断落实为步骤。**将 **20 多种方法按任务归并为 9 类**——定义、诊断、校验、复盘等——细粒度方法放到适用场景下，写清前置信息、执行步骤和常见陷阱。 这里面最需要花心思的，是**把经验里省略的步骤补出来并让 Agent 持续理解和学习**。比如某项使用率下降，“按对象分层”还不够具体：先看纳入统计的对象总量是否扩张，再看实际使用对象的绝对量；比较各群体的占比和使用率，区分构成变化与群体自身变化，必要时再追查新增对象为什么没有开始使用。这样写，Agent 才知道下一步查什么。  图9 按问题组合知识，无需每次读完所有材料 把内容写清楚后，怎么存放又成了问题。最初按知识、分析、表达分别存，一次任务要跨十几个文件；改成按行业收拢，文件又随着事件追加越写越长。最后我**拆成“稳定行业文件＋时效主题文件”**，一次重组将行业文件缩减大半，变化内容转入主题文件。问口径读行业概要，追问原因时再追加框架和方法。 文件搬完，还不能算完成。评测时发现，入口仍指引 Agent 去旧章节找口径。我又**同步修订检索指引，检查旧值残留，用同一批问题复测。内容、入口和评测问题都得跟着改，Agent 才能读到正确材料**。 ### 4.2.2 共享知识建模：每个 Skill 都存一份，知识怎么保持一致？ 整理单个应用的知识时，还能靠逐项检查解决问题。但上一节做的只是单应用内部的组织，指标定义仍散在各 Skill 的实现里；应用多了，同一指标在不同 Skill 里各存一份，修订一处，其他地方未必跟着变。我于是**把知识从具体 Skill 中独立出来，用共享底座维护定义、关系和来源**。 前面**按模型阅读的需要分层，解决的是“分析时读什么”**；这里**按维护的需要分层，解决的是“改了影响什么”**。两套分层视角不同，指向的是同一批知识。按知识支撑的业务判断，我归纳为三层： * **业务语义：把对象和数字认对。**有商品门店、广告投放商家分别是谁，广告转化渗透率用什么分母，连接哪些公式和数据来源。 * **诊断知识：把变化转成可验证的问题。**经营机制、拆解规则和比较基准帮助提出假设，再用当次数据验证。 * **策略与经验：把判断放回业务背景。**目标、行动、执行记录与历史案例，说明已有动作回应了什么约束、经验在什么条件下适用。  图10 上方是知识的支撑关系，下方是构建过程；业务范围、来源与版本贯穿各层 要让这样的结构真正可用，还得**把几个细节落实到存储和读取里**： 1. **对象可独立修订。**指标、公式、业务对象各有稳定编号与别名，形成可查询的节点；每项属性保留来源位置。“项目名称”应归为维度，不能因为出现在表里就当成指标。 2. **关系有类型，也有身份。**指标连接公式和来源字段，经营关系连接业务对象。编译时检查端点、引用与来源，再固定版本。 3. **读取时恢复业务上下文。**先确定业务单元与任务，再沿相关关系取回定义、机制和证据。各分析应用按绑定版本读取，便于复现当次分析；共享底座与各入口的更新衔接，是下一步要补的。 关系的身份就曾经丢过一次：上百**条业务关系**和两端对象都进了图谱，用原材料的关系编号查询，却 **0 条命中**。编译保留了连接，没保留关系记录自身的身份。补上独立关系节点和原始编号后，这些业务关系才全部能唯一找回。只看“关系已经入库”，发现不了这个问题。 共享底座、业务诊断和经营判断逐步积累了这些知识，彼此有继承与导入关系，按各自范围统计。  图11 三处知识按各自范围展示，内容可以继承与复用 ### 4.2.3 指标血缘与语义更新：看板口径变了，Agent 怎样跟上？ 还有一种变化发生在知识库外面：看板的取数逻辑改了，Agent 读的口径却可能没变。看板中文名、数据集字段别名和 SQL 表达式又不总是一一对应，单看名称找不出差别。为此我构建了**指标口径更新 Pipeline**，**以 FBI 业务顶层看板口径为权威源，从看板和 SQL 反向追踪**： * **追到计算来源。**从组件找到数据集，解析 SQL 的语法结构，追踪临时查询结果、别名、聚合与表达式，直到来源表和字段，并回查物理表与字段真实存在；保留筛选条件与解析缺口。 * **按技术口径识别指标。**表达式、来源字段、聚合方式、时间粒度和筛选范围共同生成稳定标识。同名但口径不同的指标分别保留，等待核对。 * **生成可查询的知识包。**数据集、指标、来源表各自形成 Markdown 节点，由索引连接；保存公式、血缘、证据及确认状态，供分析任务重复读取。 例如，一单可能有多条明细时，两个都叫“订单量”的字段就有不同含义： | | | | --- | --- | | 表达式 | 实际计数对象 | | `COUNT(order_id)` | 非空记录；一单多行时会重复计数 | | `COUNT(DISTINCT order_id)` | 去重后的订单编号 |  图12 实线为已实现的提取与知识包生成；人工确认及共享库同步仍需衔接 重新提取后，公式或筛选范围的变化就能被找出来。但表达式变了，业务含义是否也变了，新旧口径应并存还是替代，**还需要分析师判断**。目前候选与证据提取已经做出来，自动比对历史版本、确认后同步共享库，仍在建设中。 做过这部分以后，我会把入库的知识再放回能否找回、会不会用，单看入库结果并不知道。分析任务里检查。 💡 能否找回、会不会用，单看入库结果并不知道。 入库不算完成，被分析任务正确用上才算。到这一步，知识才从文档变成资产。 ### 4.3 经营分析智能体：让分析支撑业务取舍 前两段实践解决了口径和知识的问题：数字能算对，经验能复用。但还有第三个问题，比前两个更靠近业务——数字正确的报告，交到业务一号位手里，能不能支撑他作判断？这段实践就从这里开始。 业务一号位读报告，会把分析放回正在做的事情里：增长靠什么维持，已有策略有没有回应真正的约束？如果系统只看指标变化，不知道业务正在改变哪个环节，就很难参与这样的讨论。我开始**把经营背景带进分析，也给模型更多综合判断的空间**。 ### 4.3.1 经营上下文与输入建模：指标之外，业务正在做什么？ **先补输入。**早期上下文主要是业务映射、收入分类和指标清单，对团队正在做什么交代得不够。因此我补入经营事实，记录结果与诊断；**用经营卡片记录业务经营进展、目标偏差和阻塞；再用策略账本串联业务行动、投入与反馈**。稳定商业模式和年度规划从知识库读取。输入之间也要划清边界：**经营简报只做关联业务策略动作的经营结果验证（Facts），策略