01
需求Requirement
业务目标、成功指标、适用范围与风险初判。
产出：立项提案、团队任命From Practice to Platform · 40 min
从数据 Agent
到企业 Agent 平台
先把共用运行底座做深，再让各 BU 用自己的 Skills 和 MCP 长出业务 Agent。能力统一建设，场景分布式生长。
七成
公共底座的叙事判断，不是精确进度
6
幕 · 一条主线
1
套 ARK Engine 共用底座
验收
权限、回归与人审通过才上线
公司管理层 · 各业务部门负责人 · 业务落地 × 平台治理
内部分享 · 架构材料为 2026-06-23 快照 · 不把架构图当成当前生产进度
开场 · 3 min
The Destination · 先讲终局，再讲落地
高净值客户服务的多 Agent 终局，长什么样
主链路：触点 → 入口 → 协作引擎 → 岗位 Agent模型层与数据层向上支撑目标态示意 · 非当前生产进度
难点 ① · Agent 间协调任务分解之后，谁在什么时机调用谁、结果如何汇总交接，不能靠 Prompt 碰运气。→ 后文：ARK Engine 统一建设运行与编排
难点 ② · 任务分配每个岗位的能力要标准化、可复用、可审计，而不是写死在某次对话里。→ 后文：Skill + MCP 货架 · 66 个 Skill 有契约全文
难点 ③ · LLM 幻觉对客场景里，没有凭据的数字一个都不能出现。→ 后文：七维证据核对 · 无成功取数不得报数
这一页只交代一件事：画这张图不难，难的是让它可信地跑在生产里。上面三个难点的解法，就是接下来 40 分钟的内容。
目标态示意 · 高净值客户智能服务 · Agent 出证据和建议，方案由理财师决策
第一幕 · 5 min
111 秒 · Skills 看板 + 三问下钻 + 完整任务交接
先看一个真实数据 Agent怎么工作
看完就知道怎么运作
三问下钻
本月哪个产品分类募集最多？和上个月相比结构有没有明显变化？
定存保近12周，是脉冲还是趋势？
7月峰值由哪一天、哪笔订单驱动？
记住一件事：它不是在写 SQL，而是在完成一次完整的业务判断：锚定目标、找到缺口、定位根因、形成行动。
变的是前端界面，不是另一套 Agent。左边是已上线的第一版小诺，右边是接下来要给业务用的进化版。
同一套问数能力 · 第一版已在现网 · 进化版是下一版界面
第二幕 · 4 min
Act 02 · Context · Why Not Yet
为什么 Agent 发展至今，还没有现象级的新一代 BI 产品？
AI 在数据领域用得已经很多，但现象级产品仍然偏少——先看结构性原因，再看实践里为什么走不通。
① 通用性
业务场景极其多样
不同公司的业务过程、指标体系、分析框架都不一样——这不是靠一套通用模板能抹平的。
② 业务理解
人在重度参与
优秀数据从业者要先沉淀业务框架与业务过程，才能设计好指标体系、分析框架和数据宽表；大厂落地具体公司也绕不开这一步。
③ 所以
用 AI 提效，不是疯狂开人
要提效的不是编制，而是「业务问题发现 → 数据落地应用」这条链路。AI 放大的是人已经沉淀的业务理解，不是把人从链路里拿掉。
行业都在走，走通的仍然很少。实践里卡住的是这三件事：
① 缺 AI 应用框架员工拿着企业发的 token 自由发挥，形不成规模。
② Leader 看不到效果没有机制追踪 agent 效果和 token ROI，花没花在刀刃上无从知晓。
③ 追炫酷、忽略底层注意力放在快速上线小工具上，前端再花哨，数不对结论就错。
这三件事，刚好可以由我们做了十年的系统来托住——下一页就是 DataATM。
三个实践痛点 · 下一页用十年系统托住：DataATM
第二幕 · 6 min
Act 02 · DataATM 底座
DataATM 底座：让 Data Agent 避免幻觉、真正实现业务自助洞察的强大工具
Plugin 把业务方法与受控数据工具装进 Agent：先选对 Skill，再由 Skill 组合 MCP 工具完成取数、分析与交付。
主调用链三层反思闭环Agent 平台内建敏感数据脱敏；DataATM 负责权限、执行与历史审计
① 运行时 ↔ Skill：口径 / 路径反思检查是否选对业务范围、指标口径、View 和分析路径。
② Skill ↔ MCP：工具 / 参数 / View 反思根据 schema、空结果、字段错误、权限错误调整工具、参数或 View，再次执行。
③ 任务外循环：检查 → 回答 → 下一轮追问校验结果后返回用户，必要时利用新上下文继续下钻。
第二幕 · 4 min
Act 02 · DataATM 底座 · 十年自研
DataATM：让取数像取钱一样的爽
十年自研的自助取数系统——AI 时代之前就在做数据平权：把业务从 Tableau / Quick BI 的高门槛里解放出来，让每个前端都能自己查到数。
亮点 ①
操作极简 · 业务可自助
摆脱「只有 BI 专业人员才会用」的困境；看板低效工作交给系统，业务直接取数、直接下钻。
亮点 ②
长在宽表上 · 以日迭代
自助逻辑沉淀回宽表优化；不是先规划排期再等数月，而是边建设、边使用、边发现问题，以天为单位迭代。
01 · 够宽
一张表铺出几百个维度
客户基础信息不是窄表。业务想点的字段，宽表里已经在。
02 · 预计算
常用加和、分层先做好
点 AUM，系统知道这是加和；再拉客户等级，自动按维聚合。
03 · 业务沉淀口径
自定义字段写成计算语言
凡是沉淀进来的口径，一定是业务在用、被验证过的。
现场看第一版：客户基础信息表
点字段自动聚合 → 说到自定义字段就回来 → 四层需求与门户故事在系统里讲
打开系统看第一版 · 下一页收回：留下的三件事
第二幕 · 2 min
Act 02 · DataATM 底座 · 留下的三件事
AI 替代了门户，替代不了这三件事
取数、告警、数据准备。Agent 可以加速建设，但生成之后必须落在平台上——可观测、可编辑、可评估。17 个 MCP 工具，就是这三件事的接口。
能力为什么 Agent 单独不够DataATM 怎么承接MCP 公开工具
01取数读路径 · 7 tools
Text-to-SQL 快，但没有权限、口径路由、查询日志，业务不敢用
权限管控 + 查询日志 + 可审计。先发现口径，再查询分析，最后把结果交出去——每一行都可追溯。
发现解释
listexplain
查询分析
querysplitrankcompare
结果交付
download
02AI 业务告警Plugin 编排 · 复用取数
持续监控要把指标口径、基线、阈值、频率与通知范围沉淀为可审核规则
Plugin 把自然语言生成
monitor_spec。先用真实查询校验，再创建 Data Prep 草稿；用户确认后才发布。Plugin 按需 Skill
atm-anomaly-monitormonitor_spec
MCP 校验 / 草稿
querycomparedraftconfirm
03手工数据准备写路径 · 7 tools
与手工数据相关的脏活，Agent 无法凭空完成
清洗、映射、入库由底座承接。Agent 只编排：先草稿确认，再回写记录，协议与反馈闭环。
数据准备
draftconfirm
数据回写
addupdatedelete records
协议 / 反馈
sheet protocolfeedback
04 · 17 PUBLIC TOOLSOAuth 身份权限继承审计写入非只读
AI 可以生成，但交付物是画布；画布是谁提供的？还是平台。Agent 长在这个底座上面，而不是反过来。
17 个公开工具是这三件事的接口
第三幕 · 4 min
72 秒 · 图解口播 · 真实 Langfuse 页面
我们踩过的坑：Data Agent 上线很惊艳，不足一个月出现瓶颈
先看运行，再讲闭环
会话 → 链路 → 趋势
01 Session — 多轮请求串在同一会话
02 Trace — 下钻模型、Skill、工具与 Token
03 根因 — 上下文、工具返回、重试分开看
04 Dashboard — 七日 Token 与质量趋势对上 Trace
图解口播版 v2 · 真实页面 + 分镜旁白 · 不自动播放
第三幕 · 质量闭环
Act 03 · Lessons Learned
蜜月只有一个月：自动评估，人工改进
上线惊艳，复杂业务一上就幻觉。业务退回 DataATM 取数，再把 Excel / 截图喂给个人 Agent，很快又撞墙。半年 token 烧了很多，洞察没有质变——不追踪、不评估，知识沉淀不下来，Agent 也就不会越用越聪明。
自动化边界：质量 Agent 只做取证、七维评分、入队和写回；它不改代码、不升级 Skill、不自动发版。
1,367TRACE3,144SCORE11人审候选151REGRESSION责任边界：质量 Agent 找问题并举证；工程师人工修复，Owner 审批后再发版。
第三幕 · 质量规则
7 Deterministic Checks · Evidence First
不是“感觉答得好”，而是逐项核对证据
每条 Trace 都按同一规则产出 Pass / Fail / Unknown，并保留判定依据；Unknown 与业务真值问题进入人审，不让模型替自己打分。
质量维度检查什么主要证据与典型失败
01路由准确
场景是否加载了正确的 Skill / View / 分析路径
看 usedSkills 与调用链；应走客户主数据却误走产品分析，或未加载必要 Skill，判失败
02参数对齐
时间、组织、指标、粒度是否与用户问题一致
对照原问题、工具参数和 schema；问“上月香港”却查本月全公司，判失败
03筛选完整
声明的业务条件是否真正进入 applied filters
核对 View 内层与 Data Prep 外层筛选；漏客户范围、状态或权限条件，判失败
04结果完整
工具是否成功返回、数据是否足以回答问题
空结果、权限拒绝、字段缺失或只返回部分分组时，不得输出完整业务结论
05回答忠实
每个数字和结论是否能回指工具结果，失败是否披露
无成功取数却报 AUM、把推测写成事实、忽略冲突统计，均判失败
06重试效率
重试是否因错误反馈而调整，还是重复空转
看 Observation 序列；相同参数重复调用、无效换工具或达到上限仍不降级，判失败
07时延健康
端到端与关键步骤是否满足该场景配置的时延门槛
按 Trace / Observation 定位模型、Skill 或工具瓶颈；不使用虚构的统一阈值
确定性规则负责：能从 Trace、参数、筛选和结果直接验证的事实；每个 Fail 都带证据位置与可能责任组件，形成问题清单。
人工负责：业务口径真值、证据冲突、用户纠正、新场景，以及 Silver / Gold 的最终确认。
第三幕 · 真实案例
Trace b7e84… · 讲清飞轮就够了
一次真实失败，如何变成下一版能力
案例问题：「总结我名下客户的 AUM 和持仓产品风格。」路由是对的，但取数被拒绝后，回答仍给出了确定性数字。
01 Data Agent调用 DataATM 时被权限策略拒绝
→
02 留证Trace 记下拒绝、调用链与最终回答
→
03 质量 Agent独立判定：无取数却输出确定数字
→
04 入 Regression同一问题，修复后再测
错在哪里
编造了确定性结论
所有查询被权限策略拒绝，最终回答却仍给出 AUM、客户分层和投资建议。
质量 Agent 输出
不是一句「效果不好」
路由通过，不必误改路由。结果完整性失败、回答忠实度失败。权限交给数据权限负责人。
门禁
无成功取数不得报数
Regression 防复发；Silver 是人审经验；Gold 才是发布标准，质量 Agent 永不自动晋级。
第四幕 · 8 min
架构图是地图，平台是站点
最关键的不是多做 Agent，而是共用一个底座
公司统一建设运行、工具、模型和治理 · BU 只加业务 Skills、MCP 和入口
第四幕 · ARK Engine
约 90 秒 · 登录后的操作台 · 2026-08-22
一个 Agent，怎样真正走上线
先看操作台，再看结构
创建 → 装配 → 上线
创建与配置：角色、场景和模型一次定好
MCP / Skill / 知识库装配进同一个 Agent
接入真实业务入口，上线后仍可管、可查
记住一件事：不是只把模型配好，而是把数据、方法和业务入口一次接通。
默认不自动播放 · 下一页再看运行时结构
第四幕 · ARK Engine
Build · Run · Operate
从创建 Agent，到发布、运行与排障
产品层管建设、接入和运营。统一入口之下，是两类运行时与会话池。
01 建设与发布提示词结构化填写 · 发布到诺 Chat · 打包 Plug-in · 合规提示词维护
02 运行配置模型 Auto 路由 · 能力按需勾选 · 打通企微数字人 · Run / Session / Event
03 运营与排障企微群告警 · 问题总览与追踪 · 全链路日志 · 运行状态管理
结构看图 · 能力看三列小字 · 现场以操作台为准
第四幕 · Skill Hub
约 90 秒 · 货架回读 · 2026-08-21
66 个 Skill 在货架上，点开能看到契约全文
先看货架，再看门禁
规划 → 检测 → 上架
66 个已发布，点开就是契约全文
stock-analyst 385 次调用，热门会上浮
分发到 CRM Claude / ARK Engine
记住一件事：人走了，方法论还在货架上。
演示计数勿当实时生产 · 现场以工作台回读为准
第四幕 · 技能资产
Act 04 · Skill Hub
个人经验要变成公司的可信资产
Skill Hub 不是技能下载站。每个 Skill 有编号、版本、Owner、质检报告、调用计量和分发渠道。人走了，方法论还在货架上。
01规划
何时该用，完美输出长什么样
02评审
价值真伪、判重归口、防重复建设
03提交
SKILL.md + 基准输出 + Owner
04检测
静态查形，动态隔离真跑
05上线
分发 Engine / 诺Chat / CRM
06运营
热门上浮，零调用预警下架
静态门禁
先查「形」
命名、后缀、SKILL.md、frontmatter。格式不过，进不了动态检测。
动态门禁
再查「神」
Mock 环境真跑：敏感数据进出、Token、降级、与基准输出对比。合规一票否决。
TRACE 标尺
信任 · 可靠 · 适用 · 规范 · 有效
五维可比；动态质量分加权 ≥70 才通过。Hub 管上下架，OPS 管调用量。
2026-08-21：66 个已发布 · 28 个零调用 · 官网演示数据勿读，以工作台为准
第四幕 · Skill 治理
全生命周期 · 分档决策 · 证据进化
Skill 全生命周期：从一次优化到持续治理
Skill 不是上传一个 SKILL.md 就结束。它是一项有 Owner、有门禁、可运营、可回滚、可退役的平台资产。
需求评审业务价值
KCP 1立项评审
KCP 2开发准入
KCP 3验证通过
KCP 4发布准入
KCP 5季度评审
KCP 6关闭评审
02
计划Plan
确定 Owner、分档路径、版本、预算和上线时间。
产出：需求规格、方案设计03
开发Development
编写 SKILL.md 与执行文件，完成扫描和单元测试。
门禁：品控自检、重叠查询04
验证Verify
UAT、前期试用、L1-L4 品控及合规安全检查。
门禁：不通过不得上架05
发布Release
Hub 受控发版，递进灰度，Registry 自动注册。
结果：多平台受控加载06
运维/运营Operate
Langfuse 留证，监控质量、调用、成本与用户反馈。
保障：告警、Kill Switch、进化飞轮07
变更/下线Change & Retire
版本回滚、配置冻结、权限清理、归档与审计留痕。
重大变更：回流 KCP 2责任闭环AI 平台部运营，Skill Owner 对全生命周期质量负责
质量门禁L1/L2 能力与调用，L3/L4 性能与安全
发布控制Hub 版本留痕，Registry 注册，Engine 受控加载
OA 电子流权限申请、应急下线、退役申请贯穿全程
BU 专属轻量档单 BU、无 C 端、无跨境；BU ST 决策，目标 1 周内上线
跨 BU 严格档跨 BU、C 端或跨境；控股 ST 联签，严格灰度与全程审计
进化飞轮：Langfuse Trace 证明问题发生 → 根因归层 → 修改 Skill 契约 → Hub 品控与 Regression → 新版本受控发布。严重问题可秒级熔断，能力扩展必须回到 KCP 2 重走评审。
第四幕 · AI OPS
约 90 秒 · 登录后的驾驶舱 · 2026-07 / 2026-08-22
费用、模型和 MCP，都在同一套驾驶舱
先看驾驶舱，再看治理
费用 → 安全 → 质量
2026-07 费用 $69,861，526 亿 Token
368 个 MCP 工具里，8 个被运行时阻断
费用落到 BU × 模型 × 产品 × 用户
记住一件事：不可计量就无法管理。
7 月费用为平台快照 · MCP 为 2026-08-22 回读 · 不替代实时账单
第四幕 · 运营中枢
Act 04 · ARK AI OPS
AI 要从项目堆，变成可运营的资产
不是又一个看板。它不做模型、不做应用、不替代网关——而是横跨整栈，让所有 AI 能力可计量、可治理、可优化、可汇报。
费用失察
这个月到底花了多少
多云、网关、席位、实收四条管道统一折算 USD。2026-07：$69,861，526 亿 Token。
安全失控
不该放行的必须拦住
368 个 MCP 工具里 8 个被运行时阻断。审核不是文档，是系统能证明拦过。
质量失准
上线了，不等于用得好
31 个 Agent 已登记；28 个 Skill 连续 30 天零调用。既有热门榜，也有淘汰预警。
投入失据
哪个 BU 值得加预算
费用落到 BU × 模型 × 产品 × 用户。没有统一口径，就没有投入决策。
一句话：不可计量就无法管理。治理必须落到运行时阻断和限额追踪；周报每周一 08:30 进企微，AI 运营才算进入公司节奏。
数字为 2026-07 平台快照 · 现场以驾驶舱回读为准 · 不替代实时账单
第五幕 · 治理
让业务安全地快
平台不是为了管慢，而是让业务安全地快
三个最常见的失控点：Token 黑箱、经验不回流、小工具直接上线。
Token 消耗失控只看月底总账，找不到哪个场景、模型或步骤在烧钱处理：按 BU / 用户 / Skill 计量，再用 Trace 下钻到 Prompt、历史、检索、工具循环与输出。
业务经验流失纠错和隐性规则留在聊天、个人文档或某个开发者脑中处理：批注 → 提案 → Owner 审核 → 黄金题集 → 版本发布，不自动把对话写成真理。
Vibe 工具蔓延一个需求一个应用，重复登录、密钥、数据连接和运维处理：建立台账；无 Owner 或重复工具退役；共性能力收回平台；新增需求先搜索复用。
写完直接上线把「能运行」误当成「能生产」，没有测试、回滚、审计和运营处理：L0 个人试验 → L1 团队试用 → L2 生产应用；级别越高，门禁越完整。
第六幕 · 组织
Two Roles · Not More Job Titles
组织在发生变化，会出现两类人
不是多出一堆「会写提示词」的岗位。平台铺开之后，人收敛成两种定位：把事情做成可判定的人，和必须对方向负责的人。
01 · AI Builder
懂业务，并能和 AI 做成闭环
设定标准、验证结果、把方法沉淀下来。模型可以给草稿，Builder 负责把它推到能判定对错。
和 AI 协作走完一次任务：取数、核对、改口径、再跑通
把标准答案、例外和降级写进 Skill，而不是留在聊天里
核心价值：把事情推到可判定。
02 · Decision Maker · 决策者
在可判定输入上做更好的决策
领导者要把 AI 放到该放的地方。该做什么、往哪里做，必须由人来决定，并对后果负责。
在可判定的输入上做选择：做不做、做到哪、谁来验收
对客户、合规、预算和方向担责，而不是替模型打分
核心价值：决定该做什么、往哪里做。
两者缺一不可：没有 Builder，场景无法验收；没有决策者，Agent 没有人担责。模型可以建议，不能承担组织责任。
第六幕 · 组织先分清两类人，再把高价值场景交进来
Call to Action
认可统一平台，
把高价值场景交进来
不鼓励每个部门重新建设一套 Agent 平台。平台统一建设底座；AI Builder 把场景推到可判定，决策者决定该做什么、往哪里做。
下一步
提交一个值得孵化的场景
它应当高频、有价值、可验收，并且有明确业务 Owner。我们从真实场景开始，共同把它孵化成正式 Agent。
统一建设底座，让业务能力分布式生长。Agent 可以不同，运行、工具、模型和治理不再重复建设。
方向键 / 空格翻页 · 内部分享材料