标签: 企业AI

作者：zhanbo · 2026-10-10 声明：本文为独立方法论沉淀，基于公开资料与个人实践整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。 tl;dr 做什么：让业务人员用自然语言完成问数、异常诊断、监控与决策建议。首期只落地一个专业域（如 ROI 异常诊断），不做"全公司什么都能问"的超级 Agent。 为什么是现在：临时取数淹没数据团队、问题到决策链路长、口径各执一词；而主流厂商路线已全部收敛到"语义层 + Agent + 行动"，开源组合已足以支撑 PoC。 成功标准不是"能回答很多问题"，而是在目标场景里业务人员少找一轮分析师：一次解决率、诊断耗时、建议采纳率与可量化的业务结果。 首期严格只读：不自动改预算、不调生产写 API，建议必须人工确认。 权限、行列级安全、审计第一天内置，不能上线后补。 一、为什么大多数 Data Agent 会失败 三个常被数据验证的事实： 对 4,602 条错误 SQL 的分析显示，81.2% 的错误发生在 schema / 语义层，语法错误只占 18.8%（arXiv 2501.09310）。 企业真实查询在没有语义层时准确率仅 10–31%，补齐 context stack 后可达 94–99%。 MIT NANDA 研究：95% 的 GenAI pilot 拿不到可衡量的损益影响，根因是没有嵌入业务流程，而不是模型差；LinkedIn SQL Bot 嵌入现有工具后，采用率比独立聊天框高 5–10 倍。 结论很直接：瓶颈在数据与语义、在运营，不在模型。 只采购一个模型、做一个聊天 UI，几乎注定得到"demo 惊艳、上线僵尸"。 二、六件事，而不是一个聊天框 Data Agent 的产品边界覆盖六件事，聊天 UI 只是最表层： [1] 入口层 Chat / BI / IM / 内嵌面板 —— 入口必须在现有工作流里 [2] Agent 运行时 意图 → 计划 → 工具调用 → 检查 → 解释 → 建议 [3] 语义/上下文层 指标 / 实体 / 维度 / join / 同义词 / 规则案例 [4] 工具层 metric_query / 新鲜度 / 异常检测 / 贡献拆解 … [5] 治理层 RBAC / 行列级安全 / 审批 / 审计 / 限流 [6] 评测与证据层 trace / 引用 / 黄金问题 / 用户反馈 / 业务结果 └──→ 失败聚类 → 修复语义 → 离线评测 → 发布门禁 → 再发布 三条关键架构原则： ...