原来卡在哪
一家美国前三大电信运营商：网络数据分析（哪个基站坏了、为什么坏、影响多大）高度依赖人工——分析师自己写 SQL、甚至建机器学习模型，一个新需求要一两个人甚至两三个人按天计算；SQL 写到上百行中间可能取错数据（项目中真实发现过）；传统仪表盘只能回答预先定义好的问题，而管理层要的是围绕数据持续追问的交互式分析。
具体怎么做的
先搞清楚三个问题：客户到底要什么输入、最后需要什么输出、中间到底发生了什么——三个问题没搞清楚，Agent 写得再漂亮也没有意义。
重新梳理原来的分析流程：拆成较细的组件，逐一考虑每个环节的方法与结构，再重新组合。
把 Agent 定位成可以反复运行的业务系统：不是「会聊天的分析师」——数据对不对、分析可不可靠、输出格式是否符合要求、同一问题重复执行结果是否稳定，每一步都要考虑。
考虑可扩展：客户有几十上百个分析师，Agent 上云统一控制、监督和使用，用户共同产生的数据和经验反哺系统（记忆、语义层）。
尽量不改变客户原来的工作习惯：让 AI 进入客户已存在的工作流——本案例客户继续以聊天方式使用，也可嵌入 Teams/Slack 等已有框架。
效果 · Before → After
踩过的坑
- 稳定性与准确性——通过系统设计把模型随机性放进可控流程（「汽油本身不稳定，但汽车工程让它安全、稳定地驱动车辆」）
- 成本——不懂行的团队调一个东西花几千美元，有经验的人十几二十美元；架构不好像漏油的车，长期运行成本失控
- 只懂一个工具就会「拿着锤子看什么都是钉子」——要同时理解 AI、数据、云和软件工程
义道点评 · 放到制造企业里怎么做
义道财务 · 2026-09 ｜ 以下是义道的观点，不属于原案例内容；原案例不是义道的项目。
看点
「汽油本身不稳定，但汽车工程让它安全、稳定地驱动车辆」——把模型的随机性放进可控的流程里，是这个案例最好的一句话。
放到制造企业里
制造企业的老板要的也是「围绕数据持续追问」，而不是看固定报表。但财务数字不能有随机性：同一个问题问两次，毛利必须一样。义道做经营看板（M05）时，口径和计算都由确定的程序完成，AI 只负责理解问题、解释结果。几百行 SQL 取错数据，在制造企业里的对应物就是成本口径不统一。
动手前先核对
- 毛利、单件成本的口径有没有书面定义
- 同一个数，不同部门报出来一不一样
- 谁对这个数字负责
文中 M01–M16 是义道的成品模块，说明见 义道官网 · 十六个成品模块 ↗；想聊自己工厂的情况，联系义道 ↗。