企业 AI Agent 从 0 到 1|01:别先做万能助手,先把业务数字管住

很多企业做 AI Agent，第一步就想做一个“万能助手”。

能问制度，能查数据，能写报告，能建工单，最好还能进群自动推进流程。

听起来完整，落地时却很容易卡住。

我这次做自己的企业 AI 落地项目时，反而先把范围砍得很小：

第一版不做万能助手，只做一个企业数据查询里的指标闸门。

也就是先解决一个最容易出事故的问题：

当用户问“上个季度销售额是多少”时，AI 不能自由写 SQL，也不能自由报数字。它必须穿过一个已经定义好的指标口径、权限范围和回归测试。

这就是我现在用 MetricGate 做的第一步。

这篇还是讲“怎么选第一个不会翻车的业务闭环”，但不再泛泛讲概念。

我会拿自己的本地项目跑一遍：我选了什么场景，为什么选它，跑出了什么结果，哪些地方我写文章前先改了。

第一版不要证明 AI 什么都能做

企业 AI 第一版最容易犯的错，是把目标定得太大。

比如：

• 做一个全公司都能用的 AI 助手。

• 让 AI 自动查所有经营数据。

• 让 AI 进群回答所有业务问题。

• 让 AI 自动改系统、发通知、建工单。

这些不是永远不能做。

但它们不适合做第一版。

因为第一版真正要证明的，不是“AI 能不能覆盖所有场景”，而是：

它能不能在一个边界清楚的小闭环里，稳定、可控、可复盘地做完一件事。

我这次选的闭环是：

用户问一个经营指标问题，AI 只能通过受治理的指标定义查询结果；如果指标不存在、口径废弃、参数错误、权限不够，就明确拒答。

这个闭环很小。

但它非常适合做企业 AI Agent 的第一步。

因为企业里最怕的，不是 AI 答不上来。

而是它给出一个看起来很真的错数。

为什么我先选经营数据查询

很多人会觉得，企业 AI 第一版应该先做制度问答。

制度问答当然适合起步，但我这次没有先选它。

原因很简单：我现在要验证的不是“AI 能不能查到原文”，而是“AI 能不能安全地回答业务数字”。

经营数据查询有几个特点：

1. 问题高频。

2. 结果看起来简单。

3. 一旦错了，影响很大。

4. 很容易被 text-to-SQL demo 包装得很漂亮。

比如用户问：

Q1 确认收入是多少？

AI 如果直接自由写 SQL，可能会有很多隐性错误：

• 把 confirmed、draft、refunded 混在一起算。

• 把“收入”理解成旧口径。

• 没有按用户权限过滤区域。

• 上游数据变了，旧测试没有发现。

• 不知道指标已经废弃，还继续回答。

这些错误最麻烦的地方是：答案不一定离谱。

它可能只是差一点。

但在老板、财务、经营会上，一个“差一点”的数字就可能误导判断。

所以我第一步没有去做一个更大的 Agent。

我先做了一个更小的闸门：

AI 可以提问，可以组织语言，但不能自由生产业务数字。

我在项目里做的第一个闭环

这个项目叫 MetricGate。

它现在不是完整企业 AI Agent，也不是聊天框。

它只做一件事：

让企业数据 Agent 的业务数字，必须通过受治理的指标定义。

当前本地 demo 里，我放了 4 个指标定义：

这 4 个指标不是为了覆盖所有业务。

它们是为了验证企业数据 Agent 第一版最关键的 4 个问题：

1. 正式指标能不能稳定返回。

2. 草稿指标能不能明确标记。

3. 废弃指标能不能拒答并指向新指标。

4. 越权查询能不能明确拒绝，而不是偷偷缩小结果。

我先跑了一遍校验：

这行输出很重要。

它说明第一版不是靠一句 prompt 管口径，而是已经有了 4 个指标文件和 6 个 golden cases。

也就是说，指标定义和测试样例是放在一起被检查的。

这个闭环里，AI 能做什么，不能做什么

我希望第一版把边界说得非常死。

AI 能做的是：

• 根据用户问题选择一个已治理指标。

• 提供参数，比如日期范围、区域。

• 调用 query_metric。

• 把返回结果解释成人话。

AI 不能做的是：

• 自由写 SQL。

• 自己编一个指标口径。

• 绕过权限查别人的区域。

• 把废弃指标继续当成正式指标回答。

• 在没有命中指标时硬猜。

我跑 metricgate demo 时，里面有几个结果很适合解释这个边界。

正式指标可以回答：

草稿指标可以回答，但必须带标记：

废弃指标必须拒答：

越权查询也必须拒答：

这就是我说的“不会翻车”的第一层含义：

不是永远不错。

而是该答的时候有口径地答，不该答的时候明确拒绝。

写文章前，我先改了项目文档

这一步其实挺真实。

我准备写这篇文章时，发现项目里有几个地方会影响信任：

• README 顶部有 PyPI badge，但包还没正式发 PyPI。

• DESIGN 里写了 list_metrics(query?)，但当前实现是 list_metrics()。

• DESIGN 里写 metricgate serve --mcp，但当前 CLI 是 metricgate serve metrics/ --duckdb ...。

• 文档里说 “computes aggregates in code”，但当前 SQL resolver 的聚合实际发生在受治理 SQL 模板里。

这些都不是大功能 bug。

但它们会让读者产生一个问题：

你这个项目，到底是已经实现了，还是文档先吹出去了？

所以我先做了一轮 P0 对齐。

我没有急着加新功能，而是先把 README 和 DESIGN 改成更诚实的说法：

• 包还没上 PyPI，就写 source install。

• 当前 MCP 工具是什么，就写什么。

• 当前 CLI 怎么跑，就写真实命令。

• 数字来自受治理的 resolver，不说成 LLM 或 Gate 神奇地产生数字。

• DESIGN 里区分 v0.1 已实现和 next cut。

这件事看起来不大，但对企业 AI 落地很重要。

因为项目文档本身也是一种承诺。

如果文档和代码对不齐，文章就会变成概念包装。

我不想这么写。

用 4 个标准筛你的第一闭环

如果你也想做企业 AI Agent，第一版可以先用这 4 个标准筛。

这张表套到我这次的项目里，就是：

• 输入稳定：经营指标问题。

• 规则清楚：MetricSpec 里定义指标口径和参数。

• 结果可验收：golden cases 能回放。

• 风险可兜底：没有 execute_sql，越权和未知指标直接拒答。

所以我认为，经营数据查询里的指标闸门，是一个适合第一版的业务闭环。

它不大。

但足够真实。

第一个闭环的一句话模板

你也可以把自己的第一版场景写成一句话：

当【谁】询问【哪类业务数字】时，AI 只能通过【哪些已治理指标】查询结果，并按【哪些权限范围】返回；如果指标不存在、口径未验证、参数错误或越权，就【明确拒答/给出可选指标】，所有关键问题用【golden cases】定期回放。

套到我这次的项目里：

当业务用户询问 Q1 收入、订单数、平均订单金额时，AI 只能通过 revenue_confirmed、orders_count、avg_order_value 等已定义指标查询结果，并按 region 做权限封顶；如果指标废弃、未知或越权，就明确拒答并给出建议，所有关键问题用 golden cases 回放。

这句话能写清楚，说明第一闭环基本立住了。

如果写不清楚，先不要急着做 Agent。

先把场景收窄。

本课成功标准

这一课结束，你不需要马上写代码。

你只要能回答 5 个问题，就算过关：

1. 你的第一版企业 AI 场景，是不是足够小？

2. 用户输入是否稳定？

3. 规则是否能写成文件，而不是只写进 prompt？

4. 结果是否能用样例或报表回放验证？

5. 不该回答的时候，系统能不能明确拒答？

如果答案都比较清楚，就可以进入下一步。

下一课不急着搭聊天框。

我会继续沿着这个真实项目往下拆：

怎么把“销售额”这种模糊业务词，写成一个可审查、可测试、可权限封顶的指标文件。

也就是 MetricSpec。