工单与工时统计

工单在一个系统、工时在另一个、项目计划在第三个。想回答"这个季度谁超载了、哪些工单卡住了"，得先把三边导出来，对人名、对项目编码、对时间口径。

一轮下来大半天，而且下个月还得再来一遍。更糟的是每次手工对齐的规则都在经办人脑子里，换个人做，数就对不上了。

Jira、禅道这类已提供 MCP 服务的系统，直接接入 MCP 工具——标准化协议下的工具集，比为每个查询单独封装接口省事得多。

没有 MCP 的系统再用插件封装具体 API。工时系统、人力系统这类可以直连数据库的，用数据库节点只读取数，SQL 里用 {{变量}} 引用统计周期。

三种方式并存是正常的。按系统实际能力选，比统一成一种接入方式的工程量小得多。

人员标识、项目编码、工时单位在各系统里往往不一致：一个用工号、一个用邮箱、一个用姓名拼音。

把映射关系做成结构化知识库（源系统、源编码、统一编码几个字段），代码执行节点按映射表做归一。

关键在于映射表独立维护：新增一个系统、改一次编码规则，只改表，不动流程。把映射硬编码进代码或提示词里，是这类跨系统统计项目最常见的技术债。

人均负载、工单流转时长、积压天数用代码执行节点计算。这些是有明确定义的统计量，跨期比较的前提是每次算法完全一致。

放在模型里生成，数会飘——上个月和这个月的口径微妙地不同，趋势图就失去了意义。

输出分两部分：常规统计报表，以及需要处理的异常清单——超常工时、长期滞留工单、负载显著失衡的人。

报表是给存档用的，异常清单是给行动用的。配定时任务按周自动跑，周一早上收到的应该是后者。