在 AI 2.0 时代，简单的“问答机器人”已无法满足企业复杂的业务需求。如何让 AI 不仅“能聊”，还能“干活”——比如查询数据库、分析报表、处理文件？本文将以一个基于飞书（Feishu）+ LangGraph 构建的 企业级数据分析 Agent 为例，深度复盘从需求定义、产品架构到技术落地的全过程。

一、 痛点与机会：为什么我们需要 Agent？

在 B 端产品设计中，我们经常遇到这样的场景：

• 数据孤岛：业务数据躺在 MySQL/Excel 里，一线销售、财务想要看数据，必须找技术提数，流程长、效率低。
• 交互割裂：员工日常工作在飞书/钉钉，查询数据却要登录 BI 系统、ERP 系统，体验断层。
• 传统 Chatbot 的局限：传统的问答机器人只能回复预设话术，无法理解复杂的业务逻辑（比如“帮我查一下上个月华东区的财务回款，并和去年同期做个对比”）。

为了让大家更有体感，我们来看几个真实的业务场景：

场景一：销售总监的“即时看板”

痛点：周一晨会想看“上周华东区 Top5 产品的销售占比”，以前得找数据分析师提需求，排期半天。

Agent 解法：直接在群里 @Agent 提问，Agent 自动生成 SQL 查询数仓，30秒后甩出一张饼图和简报。

场景二：财务预算的“实时问答”

痛点：业务总监审批差旅费时，不确定部门预算还剩多少，得去翻 ERP 或问财务。

Agent 解法：问一句“市场部 Q4 差旅预算还有多少余额？”，Agent 校验权限后直接返回：“总预算 100 万，已用 85 万，剩余 15 万，建议预警。”

场景三：供应链的“库存预警”

痛点：大促期间，某个 SKU 爆单，仓库没来得及补货。

Agent 解法：Agent 监控到销量激增，主动发飞书消息提醒：“SKU-8823 销量环比暴增 300%，按当前流速预计 2 天后断货，建议立即补货。”

这就催生了 AI Agent（智能体） 的需求。与 Chatbot 不同，Agent 具备 感知（Perception）、规划（Planning）、行动（Action） 的能力。

本项目的产品目标很明确：打造一个 24/7 在线的“AI 数据分析师”，嵌入员工最常用的飞书 IM 中。

二、 产品架构：从线性思维到“图”思维

1. 核心能力拆解

为了实现上述目标，这个 Agent 需要具备以下核心能力：

• 意图识别：听得懂人话。知道用户是在问“财务数据”还是“交账进度”，或者是想“上传文件”。
• 工具调用：手脚麻利。能自动写 SQL 查询数据库，能做 OCR 识别图片。
• 多任务并发：效率至上。如果用户问的问题涉及多个领域，能同时开工，而不是排队等待。
• 结果聚合：逻辑清晰。能把查到的那一堆冷冰冰的数据，翻译成有观点、有结论的研报。

2. 为什么选择 LangGraph？

在技术选型上，我们放弃了传统的 LangChain Chain（链式结构），选择了 LangGraph（图结构）。

产品视角的解释：

• Chain（链） 就像是“单行道”，流程只能 A -> B -> C 走到底。一旦中间出错，或者需要根据情况分叉（比如 A 之后可能去 B，也可能去 D），就很难处理。
• Graph（图） 就像是“城市交通网”，有十字路口（路由节点），有环岛（循环重试），有立交桥（并行处理）。

对于复杂的企业业务，流程往往是非线性的。例如：用户上传了一个文件，Agent 需要先判断文件类型，如果是图片走 OCR，如果是 Excel 走 Pandas，处理完之后再汇合。这种逻辑，只有“图”能完美表达。

三、 关键功能设计复盘

1. 智能路由与意图分发 (The Brain)

我们设计了一个 Route Node（路由节点）。它不像传统的关键词匹配，而是利用大模型理解语义。

• 用户问：“上个月赚了多少钱？” -> 路由到 Finance（财务） 节点。
• 用户问：“那几个订单发货了吗？” -> 路由到 Delivery（交付） 节点。
• 用户问：“帮我解锁一下这个账号。” -> 路由到 Unlock（解锁） 节点。

2. Scatter-Gather 并行模式 (Efficiency)

体验痛点：如果用户问了一个复杂问题，涉及财务、交付等多个系统，串行查询可能需要 10 秒以上，用户早关窗口了。

解决方案：采用 Scatter-Gather（分发-聚合）模式。

• Scatter：路由节点一声令下，财务查询、交付查询同时开始跑（并行执行）。
• Gather：聚合节点在终点等待，所有任务都跑完后，统一打包结果。
• 效果：总耗时取决于最慢的那个任务，而不是所有任务之和。响应速度提升 50% 以上。

3. “人机协同”的交互设计 (UX)

• 富文本卡片：输出的不是干巴巴的文字，而是飞书的富文本卡片（Lark Markdown）。有标题、有加粗、有数据高亮，阅读体验对齐专业研报。
• 透明度设计：在回复中，我们不仅仅给结论，还可以选择性展示生成的 SQL 语句。对于懂业务的 PM 或分析师，这是一种“可解释性”，建立了人对 AI 的信任。
• 菜单与状态管理：利用飞书机器人的菜单功能，设计了“清空记忆”按钮。用户可以随时重置上下文，避免旧话题干扰新任务。

四、 落地挑战与应对

1. 权限控制 (Security)

风险：AI 如果太聪明，把老板的工资查出来怎么办？

对策：我们在 Graph 中增加了一个 Permission Filter（权限过滤） 节点。在查询执行前/后，校验当前用户的 open_id 是否有权限查看相关数据。这是企业级应用必须守住的红线。

2. 幻觉问题 (Hallucination)

风险：大模型一本正经地胡说八道。

对策：

• Prompt Engineering：在 System Prompt 中严格约束，“只读不写”，禁止执行 DELETE/UPDATE。
• Few-Shot Learning：给模型提供几个标准的 SQL 查询示例，让它照猫画虎，大幅提高准确率。

五、 结语：Agent 是企业数字化的新基建

通过这个项目，我们不仅实现了一个“查数机器人”，更验证了一套 LLM + Graph + IM 的企业级应用开发范式。

未来的 B 端产品，可能不再是有着复杂菜单和按钮的 Web 系统，而是一个个 24 小时待命的 Agent。它们潜伏在飞书/钉钉的对话框里，随时准备响应你的呼唤，连接业务系统，释放数据价值。

对于产品经理而言，学会用“Agent 的逻辑”去重构业务流程，将是 AI 时代的核心竞争力。