Article body
正文
一份销售日报看似只是每天更新几张图。交给 Agent 执行时，数据团队先要回答三个问题：销售额按下单日还是支付日统计，退款算在哪一天，谁有权看到区域明细。答案没确定，定时运行只会把口径分歧按时送到更多人面前。
先把日报的业务定义落到平台里
以“昨日各区域净销售额”为例，业务负责人要确认统计周期、退款处理方式和区域归属；数据团队再核对数据源、数据集及指标计算。HENGSHI SENSE 支持数据接入、建模、指标管理和仪表盘交付。团队可以用原子指标表达基础计算，再把限定条件、分析维度和时间轴配置到业务指标中。这样，日报引用的是有明确业务含义的指标，后续讨论也能回到具体定义。
指标定义之外，还要检查数据何时更新、迟到订单如何处理，以及不同角色能看哪些数据。报表中的数字可复用，不代表所有人都应看到同一范围的明细；发布前应按实际用户权限验证结果。
先用样本把“正确”说具体
把指标交给 Agent 前，团队可以拿一小组已知订单做试算。样本不用大，却要覆盖最容易引起争议的边界：跨日支付、部分退款、取消订单、区域调整和数据延迟。业务负责人先写预期数字，数据团队再用目标数据集算出结果；两边一致后，才把计算口径用于正式日报。这样做的价值在于留下可复核的订单和规则，下一次数字变化时能判断是数据变了，还是定义变了。
| 验收项 | 样本要回答的问题 | 通过时留下的证据 |
|---|---|---|
| 时间口径 | 昨日按哪种事件时间与时区截取？ | 起止时刻、跨日订单明细 |
| 金额口径 | 退款、取消与部分退款怎样影响净额？ | 样本订单及人工预期值 |
| 组织口径 | 区域按下单时归属，还是按当前归属？ | 区域映射版本与汇总对账 |
| 可见范围 | 区域经理能否看到其他区域明细？ | 实际角色下的看板检查结果 |
还要给“昨日”规定一个数据截止点。例如日报每天早上运行，就明确凌晨补录的订单是否进入当期，以及源表未刷新时是等待、告警还是推迟发送。团队不必追求所有数据永远没有迟到，但必须让接收人知道这份日报截至何时、哪些数字可能在下一次运行中调整。对有结算意义的报表，可以把运营日报与月结报表分别命名和验收，避免用同一名称承载两种用途。
让 CLI 执行确定的动作
HENGSHI CLI 的公开命令入口是 hbi。它覆盖应用与数据集查询、HQL 查询、仪表盘配置和授权等资源域，并可返回结构化结果。Agent 接到日报任务后，应先读取目标实例、应用和数据集，再验证查询与报表所用对象。下面是官方文档支持的只读检查路径；具体 ID、字段和表达式由实施团队在目标实例中确认。
hbi auth status --output json
hbi dataset list --app <app-id> --output json
hbi data-model query --app <app-id> --dataset <dataset-id> "SUM({amount})"这些命令不会自行决定“净销售额”该怎么算。Agent 负责按任务顺序调用已确认的能力，HENGSHI SENSE 负责执行查询和资源操作，业务与数据负责人负责验收口径及结论。授权等变更应先查看当前状态，并在支持预演的命令上使用 dry-run；不能把读数成功当成发布许可。
把验收写进日报流程
团队可以先人工跑通一份日报：核对指标与时间范围，比较样本结果，打开最终看板检查筛选、图表和权限。之后再由企业现有的调度系统或 Agent 运行环境触发重复任务，保留命令输出和异常记录。遇到数据未更新、查询失败或结果偏离预期时，流程应提示负责人复核，而不是继续推送一份看似完整的报告。
交接时可以把日报任务写成一张验收卡：列出数据集、指标名称、统计时区、运行时间、目标看板和接收人，并附上一天正常数据、一笔退款及一笔跨日订单的预期结果。业务负责人确认这些样本代表的业务规则，数据团队记录对应查询与报表位置。Agent 每次运行时按同一清单检查，发现指标定义或数据集变更，就把差异交回负责人确认。
发送前还应设定清晰的停发条件。例如，昨日数据尚未完成更新、区域明细合计与总额不一致，或某个接收人只能看到空白页面，流程都应记录检查项、实际结果和发生时间，并通知对应负责人。负责人处理后再重跑受影响的步骤，避免重复发送多个版本。若业务允许先发送带说明的日报，也应由业务负责人预先写明适用条件和标注方式。
验收记录最好能追到一次具体运行：谁确认了口径，查询使用哪个时间范围，报表何时生成，异常由谁关闭。月末复盘时，团队就能区分指标口径变化、源数据延迟和权限调整造成的差异，也能判断哪些检查值得加入下一次自动执行。
把失败处理写成运行规则
自动运行不等于自动发出。Agent 完成对象检查和查询后，应先比较本次结果与验收卡：数据更新时间是否达标，分区域合计是否与总额一致，关键区域是否缺失，接收人是否具备查看权限。阈值由业务负责人结合波动情况设定；例如节假日的销售额与工作日差异很大，单凭“环比下降”就停发会制造噪声。团队可以把硬性错误与需要解释的异常分开处理。
读取任务定义与已确认的指标口径
检查数据更新时间、查询结果、看板与接收范围
若有硬性错误：记录证据，通知负责人，不发送日报
若有待解释异常：附上异常说明，交业务负责人复核
复核通过后：发送指定版本，并保存运行时间与验收结果一份可追溯的日报还应标出报表版本、统计区间和生成时间。接收人反馈“今天的数字与昨天看到的不一样”时，团队先核对两次运行是否使用相同的筛选条件和权限，再看源数据是否回补；无需让每个人重做整套查询。异常修复后若要重发，负责人应在新版本说明里标明修正原因，让接收人知道该以哪份结果为准。
流程稳定后再扩展到其他区域或其他指标。每增加一个指标，都复用同一套样本、权限和停发规则，同时单独确认业务定义。Agent 能减少机械操作，却不能替业务负责人签收口径。日报真正省下来的时间，来自把日常核对变成可重复执行的检查，让人集中处理例外。
一次运行怎样留下可复核的记录
假设日报约定每天 9 点向各区域负责人发送昨日净销售额。某天 8 点 50 分，Agent 发现订单源表已更新，但退款表仍停留在前一晚。此时应记录两个数据源各自的更新时间和查询条件，把“退款数据未达到约定截止点”作为具体异常交给数据负责人，而不是笼统标记为任务失败。负责人确认刷新完成后，流程重新查询并对照样本；若最终结果改变，记录新旧差额。
再如华东区域的合计与总表差了 500 元，数据团队应先找出差额涉及的订单，再检查区域归属与退款规则。若原因是上游订单刚被调整归属，应在运行记录里注明调整发生时间和采用的映射版本。业务负责人据此决定是否发送日报，并给接收人写清变化。这个过程把“数字不对”的口头反馈变成能核查的记录。
日报上线后的第一周，团队可以让人工结果与 Agent 结果并行核对。若连续几次都能解释差异，再减少人工操作；仍频繁出现无法归类的异常，就先补足样本和规则。判断是否扩大自动化范围，应看问题能否被定位和处理，而不只看运行是否成功。
当多个分析任务共用这套流程，HENGSHI JARVIS 可作为咨询赋能方案，帮助团队整理指标说明、任务路由、执行边界和复核要求。它解决的是 Agent 如何依据团队知识与工作规约开展协作；实际数据、指标和分析资产仍由 HENGSHI SENSE 及使用方共同管理。