FY27 S1 复盘：高德本地生活分析 Agent 建设实践
（本文阅读时间：约 30 分钟）
FY27 的 S1 已过去。回顾这半年，如同经历了一场拉长的复盘：旧问题刚理清，新挑战又至。本阶段，作者主要负责建设高德本地生活分析 Agent。起初以为打通分析流程即可大步向前，实则发现口径、知识、推理和交付各环节均需重新审视。这段历程虽艰辛，却让作者逐渐厘清了两件事：系统应如何构建，以及 BI 在 AI 时代应将精力聚焦何处。
全文约 1.2 万字，预计阅读 30 分钟，可按需选读。
想了解背景与架构，请参阅第 1—3 节；关注具体实现与避坑经验，可直接阅读第 4 节；探讨 AI 时代 BI 的定位与个人成长，建议从第 5—6 节开始。
本文全景式整理了这段实践经验：涵盖整体架构、分析流程、知识与语义治理、经营分析智能体的具体建设，记录了过程中的取舍与踩坑，以及这些经历对 BI 认知的重塑。至 S1 末，该体系已支撑本地生活多个业务单元的例行经营诊断，实现全行业经营简报一小时内产出。期望这些经验能为同行提供借鉴。
01 背景与项目缘起：报告交付之后，经营问题仍在继续
BI 常面临这样的场景：收入下降，经过查数、核对、拆解完成分析报告后，业务方随即追问：是否需要处理？优先调整哪个环节？现有动作是否有效？报告交付往往只是深入讨论的开始。
这些问题正是作者希望深度参与的领域。然而日常工作中，大量时间耗费在澄清需求、确认口径、取数核对上。每次面对新问题，都需重新协调人员与材料，既往积累的经验难以复用。
自 S1 起，高德推进 BI AI 化，旨在让业务更自主地获取可信数据，让分析更深入地参与决策。作者负责其中面向本地生活业务的数据分析智能体。核心思路是将已验证的业务关系和分析方法沉淀下来：业务知识入库，分析方法封装为 Skills，由 Agent 调用数据与工具完成分析。从而释放人力，回归到报告背后那些亟需人类智慧参与的深层问题。
图1 AI时代的BI工作与协同边界 vs 传统时代
以下将分享这段建设经历：哪些环节已跑通，哪些经历了返工，以及这些反复如何重塑了对 BI 的理解。
02 L0–L4 能力分级：从回答一个数，到支撑一个判断
为明确建设进度，团队结合行业调研与业务场景，制定了BI 能力的 L0–L4 分级标准，用以对齐当前能力及后续缺口。
早期团队主要处于 L2 智能问数阶段：用户询问“上周收入是多少”，系统能准确理解口径、查找数据并返回结果，解决了 30% 以上的基础需求。
但当追问“为什么下降”时，所需能力发生质变。按照分级标准，目前绝大部分任务已具备 L3 特征，即能够沿业务链路排查并给出支持解释的证据。部分场景已迈向 L4，将分析接入决策与行动。需注意，L4 并非完全无人化，而是系统自主分析并给出建议，人类参与关键取舍并反馈执行结果。本地生活分析 Agent 目前主攻 L3 分析建设，并逐步向经营研判延伸。
从 L2 跨越至 L3 的关键在于：让系统真正理解具体生意中“下降”的含义。这是本地生活数据分析 Agent 建设的第一步。
图2 智能分析演进路线
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 会重跑已有案例，作者审阅分析及业务表达，以验证改动是否影响原有能力。
4.1.4 反馈驱动的能力迭代：一句“没有继续下钻”，要改到哪一层？
审阅中曾收到反馈：“报告定位到某个转化环节便停住，没有继续下钻”。此次问题并非材料缺失，而是分析路径不足。作者将分析拆解为对象状态和使用过程：从纳入统计对象追至实际使用对象，区分“尚未开始”与“开始后未能持续”。
此前“归因算出未写出”需修补证据传递，此次则需补充分析路径。面对“分析不够好”的反馈，作者坚持先看问题发生在哪一层，再决定补方法、补知识还是改实现，最后拿案例重跑。
图7 开发过程中的反馈循环；业务决策与执行的闭环，还需要后续建设
经过多次返工，作者严格检查证据传递和分析路径，材料齐备后，将综合与表达留给模型判断。
回头看，这一段让我重新理解了“跑通”的含义：跑通不是流程走完，是证据传递和分析路径由工程兜底，深度推理、综合与表达留给模型判断。工程把确定性做满，模型把判断力放开。
（为保证数据准确性，在垂直分析Agent中做了特定分析路径的工程兜底）
4.1.5 Demo：一份经营诊断月报，怎样组织分析
经过上述优化，一份标准的诊断报告应包含增长质量判断、原因比较和策略取舍。
图8 能力展示示例，内容经改编（业务信息与数值以脱敏占位展示）
4.2 知识库与语义治理：让经验跨业务复用
为构建语义库，作者整理了线上分析师知识库、业务规划和复盘文档。要让 Agent 有效利用这些原本为人编写的材料，需解决知识提炼（蒸馏）、存储结构、持续更新（保鲜）三大问题。
4.2.1 知识蒸馏与按需加载：文档收齐了，为什么分析还是用不好？
原始复盘文档混合了现象、判断、策略和口径，压缩后的摘要虽能告知“发生了什么”，却难以指导“下一步查什么”。为此，作者将内容拆解为事实、机制、策略与口径，并按用途整理为三个层次：
- 行业知识：涵盖业务模式、核心公式、口径和诊断起点，区分稳定规律与当期情况。
- 分析框架：按业务经营框架组织问题，形成分析路径，将结果性指标拆解至影响因子。
- 分析方法：将 20 多种方法归并为 9 类（定义、诊断、校验、复盘等），写清前置信息、执行步骤和常见陷阱。
关键在于补全经验中省略的步骤。例如使用率下降，需细化为：统计对象总量是否扩张、实际使用对象绝对量变化、各群体占比及使用率变化，进而区分构成变化与群体自身变化。
图9 按问题组合知识，无需每次读完所有材料
存储结构上，最终采用“稳定行业文件＋时效主题文件”模式，大幅缩减行业文件大小，变化内容转入主题文件。同时同步修订检索指引，确保 Agent 能读取正确材料。
4.2.2 共享知识建模：每个 Skill 都存一份，知识怎么保持一致？
为解决多应用间指标定义分散、修订不同步的问题，作者将知识从具体 Skill 中独立出来，建立共享底座维护定义、关系和来源。按支撑业务判断的需求，归纳为三层：
- 业务语义：明确对象（如商品门店、商家）及数字含义（如分母、公式）。
- 诊断知识：包含经营机制、拆解规则和比较基准，用于提出假设并验证。
- 策略与经验：记录目标、行动、执行记录与历史案例，说明适用条件。
图10 上方是知识的支撑关系，下方是构建过程；业务范围、来源与版本贯穿各层
落实细节包括：
- 对象可独立修订：指标、公式、业务对象拥有稳定编号与别名，属性保留来源位置。
- 关系有类型与身份：编译时检查端点、引用与来源，固定版本。
- 读取时恢复业务上下文：按业务单元与任务，沿相关关系取回定义、机制和证据。
曾因编译未保留关系记录自身的身份，导致上百条业务关系无法通过原材料编号查询。补上独立关系节点和原始编号后，问题得以解决。
图11 三处知识按各自范围展示，内容可以继承与复用
4.2.3 指标血缘与语义更新：看板口径变了，Agent 怎样跟上？
针对看板取数逻辑变更而 Agent 口径滞后的问题，构建了指标口径更新 Pipeline，以 FBI 业务顶层看板口径为权威源，反向追踪：
- 追到计算来源：解析 SQL 语法结构，追踪临时查询、别名、聚合与表达式，直至来源表和字段。
- 按技术口径识别指标：基于表达式、来源字段、聚合方式等生成稳定标识，区分同名不同口径指标。
- 生成可查询的知识包：形成 Markdown 节点，保存公式、血缘、证据及确认状态。
表达式 |
实际计数对象 |
|
非空记录；一单多行时会重复计数 |
|
去重后的订单编号 |
图12 实线为已实现的提取与知识包生成；人工确认及共享库同步仍需衔接
表达式变化需分析师判断业务含义是否改变。目前候选与证据提取已完成，自动比对与同步仍在建设中。
能否找回、会不会用，单看入库结果并不知道。入库不算完成，被分析任务正确用上才算。到这一步，知识才从文档变成资产。
4.3 经营分析智能体：让分析支撑业务取舍
前两段实践解决了口径和知识复用问题，第三段实践聚焦于：数字正确的报告，能否支撑业务一号位作出判断？为此，作者将经营背景带入分析，并给予模型更多综合判断空间。
4.3.1 经营上下文与输入建模：指标之外，业务正在做什么？
早期上下文缺乏对团队动作的描述。为此，补充经营事实，记录结果与诊断；用经营卡片记录进展、目标偏差和阻塞；用策略账本串联行动、投入与反馈。明确输入边界：经营简报验证策略动作的结果（Facts），策略简报证明策略身份与执行（Facts），诊断结论基于 Agent 定期体检数据（Insights）。
4.3.2 Skill 驱动的经营推理：规则越来越多，分析为什么没有更好？
早期为保证报告稳定性，施加了大量硬约束（固定议题、卡片配额、句长限制等），导致报告规整但判断力未提升，甚至出现因果词黑名单误拦正常表述的情况。
于是做减法，移除硬约束，聚焦 Skill 中的分析方法：
- 先看经营全貌：联看收入、规模、订单和收益，分析增长质量。
- 再沿适用机制展开：由商业模式选择经营链路，结合结构寻找解释。
- 让策略参与判断：分析行动回应的约束、执行与指标变化的支持关系。
4.3.3 事实绑定、语义审阅与成稿分工：数字引用没错，为什么结论仍然错了？
开放判断空间后，错误更加隐蔽。例如将“全部纳入统计对象”误认为“尚未开始使用对象”，导致转化不足的错误推断。此类错误光靠核对数字无法发现。
为此，建立与判断空间匹配的质量工程，分为三层检查：
- 事实绑定：防止引用错。数值、单位等由上游提供，模型引用标识，程序还原核验。
- 分析与业务审阅：检查理解。模型形成结论，程序检查覆盖度与可追溯性，人工审阅对象混用等逻辑错误。
- 成稿保真：防止交付变样。成稿模型按 ID 编排已确认内容，二次检查确保判断未变。
针对返修成本高的问题，采取两项措施：
- 输入做减法：最大引用深度由 13 层降至 4 层，返修时按需选取上下文，样本返修来源由 731 条收敛至 179 条。
- 按影响半径决定重跑范围：判断改变则重跑分析，仅改版式则保留原判断，工程误报则修程序。
实际运行中，一份月报需经过 3 次分析、1 次成稿，累计模型调用约 11.1 分钟。设计时需将“出错以后怎么办”作为重点，明确保留依据、改动影响及重做检查的范围。
给模型判断空间的前提，是质量工程兜得住——每类错误有对应的一层检查，每次修正知道改到哪一层为止。判断空间决定报告的上限，这套工程决定报告的下限。
4.4 知识和能力沉淀：三段实践，留下了哪些成果？
- 覆盖范围：本地生活业务单元全部接入，适配各自的商业模式与分析路径。
- 产出时效：全行业一轮报告 ≤1 小时，效率约为人工逐份完成的 22 倍。
- 知识资产：从文档积累转向关系化维护，共享底座连接业务对象、机制与经验。
- 指标语义：连接定义、计算依据与来源，指标口径更新 Pipeline 提供变更证据。
图18 知识和语义规模
05 AI时代重新理解 BI 的定位：从场景能力到经营大脑
现有能力主要围绕单个业务单元的经营体检。然而，供需匹配、供给质量、客户变化等问题相互关联。若每个 Agent 孤立运作，联系仍需人工整理。
作者思考：能否让 Agent 围绕同一经营问题协作，发现单份报告中未见的规律？这正是“经营大脑”的出发点。
BI 应持续理解业务现状，判断优先关注的问题，并组织相应的知识与分析能力。
作为 BI，应重点关注：
- 眼前究竟该查什么？根据业务背景确定是诊断问题还是提出新策略，再选择分析能力。
- 局部调整够不够？若市场变化影响原有假设，需将问题路由回战略环，重新审视方向。
- 这次选择能留下什么？除了事实与方法，还应留下业务记忆，供未来参考。
在此过程中，AI 扩大信息处理范围，BI 结合商业模式判断轻重，业务负责人作出取舍并推动行动。
最近对于经营大脑框架的设计和持续思考，让我重新想了一遍：BI 应该站在经营的什么位置。
AI 时代的 BI，是经营判断能力的设计者，也是判断质量的守门人。
1. 设计者的这一面，是把对生意的理解沉淀成知识、方法和校验，让 AI 能稳定地产出可信的分析，让这一次的经验被下一次直接用；
2. 守门人的这一面，是守住那些无法委托给 Agent 的环节——判断什么问题值得优先查，审阅系统的理解有没有偏离业务，在资源与策略的取舍上拿出专业意见。
06 实践之后，我开始用不同的标准看待自己的工作
6.1 交付：从这一份报告，到下一次分析
最初审报告关注归因深度、文字清晰度及数字准确性。后来发现，“分析太浅”往往源于证据或路径缺失。现在，作者顺着反馈往前找，将修正带回方法、知识或实现，并用案例复查。下一次同类分析能否做好，比单次报告修改次数更能体现能力进步。
6.2 经验：从自己会做，到能够讲清适用条件
要让经验复用，必须讲清适用条件。编写 Skill 和知识库时，需明确判断针对的对象、经营阶段及反向信号。知识库写得越具体，越能暴露业务理解中的缺口。
6.3 价值：从亲自控制细节，到判断哪里需要控制
讲清经验不代表每一步都规定死。过度控制反而限制报告质量。现在，作者将计算和引用交给程序核验，让模型尝试不同解释，再结合业务知识检查判断。重点在于判断哪些地方不能错、哪些地方可探索，以及如何评估探索价值。
6.4 下一步，把反馈接回来
下一步重点补齐反馈闭环：
- Agentic loop：从一个经营问题出发，按发现补充证据、检查反证、调整路径，使分析能持续深入。
- Human in the loop：让业务补充背景、参与取舍，并将动作和效果带回知识与后续分析。
07 结语
“报告写完了，讨论才刚刚展开。”这句话不仅是 BI 的日常处境，也是这套系统致力抵达的目标——问题被接着查清，动作被验证效果，经验长成下一次判断的底气。那些报告之后仍在继续的问题，正是 BI 持续前行的动力。
