工资算错一次，代价不是改个数字。钱已经发出去，重发要走一遍审批、补一遍银行流水、跟每个人解释一遍，还得考虑退不退回、要不要在工资条上留痕。月底那三天窗口里，考勤还没锁、入离职还没同步、调薪还没生效、计件产量还在补录，任何一处出错，最后都落在那个算工资的人头上。
这篇讲的是用 OpenClaw 把工资核算这条线搭起来：口径怎么钉死、数据从哪四张源表来、五步计算顺序、五种最容易错的场景、保密怎么做，以及哪些事必须留给人。它是请假与年假余额管理的下游——那边管额度，这边管因为这些额度产生的钱；也是绩效考核与 OKR 复盘的下游——绩效系数定完，才轮到算钱。
一、先把口径钉死：六个数字，写进配置不写进提示词
工资算错，八成不是算错，是口径不统一。同一个月，HR 说按 21.75 天折算，财务说按当月实际工作日，车间说按出勤天数，三个数都不算错，但对不上。所以第一步不是让 Agent 算，是把六个口径一条一条写成配置项。
- 计薪天数：用固定值还是当月实际工作日，全公司必须一个。用固定值算得快、跨月可比；用实际工作日更贴近考勤，但每月要维护。
- 出勤口径：迟到几分钟内不扣、旷工怎么认、调休优先抵加班还是抵事假，这些是制度问题，必须先写死。
- 加班倍数：工作日、休息日、法定节假日三档，各自是 1.5、2、3 还是另有约定，按当地规定和公司制度取一个，别混着用。
- 事假病假扣法：按日扣还是按小时扣，病假是否按比例发，比例多少。
- 社保公积金基数：上下限每年由当地公布，基数取上年度月平均工资还是当月应发，公积金比例单位和个人各多少。
- 个税专项附加扣除：子女教育、房贷、赡养老人等，以员工在税务系统的申报为准，Agent 只读汇总数，不自行推算。
这里有一条必须守住的工程原则：税率表、社保基数上下限、公积金比例这类会变的数字，绝不写进提示词。写进提示词的后果是每年政策一调，你得去改 prompt，改完还未必记得改过。正确做法是把它们放在一个独立的配置文件里，带生效日期字段，Agent 每次计算前读当期版本。这一点和权限管理里的思路一样——规则要能被审计，不能藏在自然语言里。
二、四张源表：数据不准，算得再对也没用
工资核算的输入只有四张表，但这四张表每一张都有「截止时点」的问题。
花名册：谁在职、入职日期、离职日期、部门、岗位、基本工资、各项固定津贴、调薪记录（含生效日期）。这张表最大的坑是「生效日期」——调薪从 16 号生效，当月要按天折算，而不是整月按新标准。
考勤表：出勤天数、迟到早退、旷工、各类请假天数、加班时长（区分三档）。截止时点建议定在次月 2 号，并且要求考勤系统「锁定」后才允许取数，否则算到一半数据被人改了，前后两次跑出来的结果不一样。
计件产量表：按人按工序的合格产量，以及单价。这里只能取「合格数」，不良品的工费怎么算要单独定，混在一起算必然扯皮。
上月工资表：看起来是输出，其实是输入。因为个税用累计预扣法，本月要用的「本年累计收入、累计扣除、累计已缴税额」全在上月表里。这张表缺字段，个税一定算错。
四张表都到位之后，还要做一次交叉校验：花名册在职人数 vs 考勤表人数 vs 计件表人数，三个数不一致就先停下来查。人数都对不上，后面的计算全是无用功。
三、五步计算顺序：顺序反了，结果一定偏
工资的计算有严格的先后，跳步就会错。建议固定成五步，每一步都落一张中间表。
第一步，算应发。应发 = 固定工资（按出勤折算）+ 计件/绩效 + 各类津贴 + 加班费 + 补发。折算的关键是当月入离职、事假病假、无薪假这几种情况，每一种都要有明确的折算公式。
第二步，算扣款。迟到早退、旷工、事假、代扣项（借款、罚款、餐费）。扣款必须有依据单据，不能凭口头。这一步的产物是一张「扣款明细」，逐人逐项，方便事后解释。
第三步，算社保公积金。个人部分从应发里扣，单位部分进成本不进工资表。每年调基的那个月要单独标记，因为会出现「本月社保额和上月不一样」的情况，不标记就会被当成错误。
第四步，算个税。累计预扣法：本月应预扣税额 = （本年累计收入 − 累计减除费用 − 累计专项扣除 − 累计专项附加扣除 − 累计其他扣除）× 适用税率 − 速算扣除数 − 本年累计已预扣税额。结果是负数就按零处理，不退税。这一步最容易漏的是「累计」两个字——只按当月算，年底一定对不上。
第五步，算实发。实发 = 应发 − 扣款 − 社保公积金个人部分 − 个税。实发出现负数必须拦截，这不是正常业务，是数据错了。
每一步之间要有勾稽：应发合计 = 各分项之和，实发合计 = 应发合计 − 各项扣除合计。这两个等式跑不平，就不要往下走。
四、五种最容易错的场景，做成固定检查项
工资的错法高度集中，把高频场景固化成检查清单，比事后复核有效得多。
- 入离职当月按天折算：入职在月中、离职在月中，都要按实际计薪天数折算固定工资。最常见的错是整月发或者整月不发。
- 调薪生效日在月中：前后两段按不同标准折算。系统里如果只存了「当前工资」，历史就查不到了，所以调薪必须是追加记录而不是覆盖。
- 请假与加班同月互抵：有人这个月请了三天事假又加了两个周末，是先抵再算还是各算各的，制度里必须写清楚，否则同一个人两个月能算出不同结果。
- 补发与补扣跨月：上月漏发的补贴这月补，要单独列「补发」项并注明所属月份，不能混进当月应发，否则个税累计和社保基数都会被带偏。
- 离职结算：未休年假折算、当月工资、经济补偿，三笔性质不同。经济补偿通常不进工资表、单独计个税口径，混进工资表会让当月个税异常跳高。
这五条建议直接变成 Agent 的硬检查：命中任何一条，就在输出里打标记并要求人工确认，而不是自己决定怎么处理。
五、工资条怎么发：一条一条发，别发一张总表
工资条最容易出事的不是算错，是发错人。解决方案很简单但很少人做：永远不要生成一张包含全员的表往外发，而是按人生成单条，一人一份，只包含本人的项目和本部门的对比基准。
OpenClaw 的做法是建一个定时任务，每月工资审批通过后触发：读取定稿的工资表 → 按人拆成单条 → 每个人只拿到自己的应发、扣款、社保、个税、实发五项，加一句说明（比如「本月含补发 8 月餐补」）→ 走企业微信或邮件点对点推送 → 记录推送结果。
推送失败要能重试，员工说没收到要能补发，这两点必须做。同时保留一个「已发送清单」，谁什么时候收到的可查——这不是为了追责，是为了避免「我没收到所以不知道扣了什么」这种无解的争执。
六、保密与权限：工资数据的四条硬规矩
工资是全公司最敏感的一张表，Agent 接进来之前，这四条先立住。
- 不落地明文：中间表加密存储，用完即删，不要在工作目录里留一堆 payroll_202610.xlsx。
- 按人取数：Agent 回答「我工资多少」时，只能读当前登录人那一行，不能先读全表再过滤。前者是权限，后者是运气。
- 日志脱敏：审计日志记「谁在什么时候查了工资表」，不记具体金额。日志本身泄露，等于表泄露。
- 输出留痕：任何一次导出、推送、修改，都要有记录，字段设计可以参考审计查询字段那套思路——时间、主体、动作、对象、结果，五个字段就够用。
还有一条实操建议：工资相关的会话不要和历史对话混在一个上下文里。算工资的 Agent 应该是一个独立实例，只挂载必要的工具，不接浏览、不接外部搜索。这属于最小权限的基本操作，具体做法在Agent 权限管理里讲过，工资场景只是把它执行得更严格一点。
七、Agent 能做四件事，做不了三件事
能做：四张源表的导入与交叉校验（人数、工号、部门对不对得上）；按固定口径逐人计算并输出中间表；生成异常清单（折算、补发、负数、跳档）；工资条的分发与回执记录。
做不了：定口径——计薪天数、加班倍数这些是制度和合规问题；批准发放——涉及资金的动作必须有人签；解释争议——员工问「为什么我这个月少了 300」，最终答复要由人给出，Agent 只能提供计算过程和依据。
把这条边界划清楚，比让 Agent 多算几个数重要得多。工资这件事，可解释性比自动化率更值钱。
八、落地三步，每步都有验收标准
第一步，只做校验，不做计算。把四张表导进来，跑人数一致性、字段完整性、异常值检查，输出一张问题清单给 HR。这一步不碰钱，风险最低，但能立刻发现数据源的真实质量。
第二步，做试算比对。用同一份数据，Agent 算一遍、人工算一遍，逐人比对差异。差异率降到千分之一以内，才算口径对齐了。这一步通常要跑两到三个工资周期。
第三步，接管计算与分发。试算稳定后再让 Agent 出正式表，但发放仍由人审批。工资条分发可以更早自动化，因为它不涉及金额决策。
三步走完，一个月的工资核算 workload 通常能从三四天压到半天，但前提是前面两步真的做扎实了。跳过校验直接上计算，等于把错误放大到全公司。
九、一句话总结
工资核算的难点从来不是公式，是口径、时点和责任。口径写进配置、时点写成硬约束、责任留给签字的人——Agent 负责把四张表对齐、把五步算完、把异常挑出来、把工资条发到每个人手上，剩下的判断一步也别替。
