薪资与雇佣税智能体

请把界划在引擎上，并且划成架构而不是一条政策。

每个薪资平台里都有一台计算引擎，它的输出可审计、可复现，而且——这才是要紧的那部分——站得住脚。当某个州的机构对一笔代扣金额提出异议时，答案是引擎的税率表版本加上它那份逐项计算，而不是一段理由。你的智能体必须在这台引擎的输入一侧、以及它输出的阅读一侧，而绝不在两者之间。

# the only three write paths an agent should have
INPUT     propose a change to source data (address, exemption,
          deduction, work location) -> staged, human-confirmed
DRAFT     assemble a return, a notice reply, an amendment packet
          -> unsigned draft in the filing queue
NOTE      annotate a case, a variance, a reconciliation item
          -> free text, never read back as a number

# everything else is read-only, including:
the calculated number   the deposit amount   the filed return
the pay statement       the GL journal       the agency portal

这件事之所以必须在 schema 里而不是在提示词里被强制，原因在于失效的不对称。一个提出了错误输入的智能体，会被确认环节和 STEP 3 里的「毛额到净额」方差检查抓住。而一个被允许直接写数字的智能体，会产出一笔错了、且没人能重建其成因的缴存——而重建恰恰是罚款核定会要的东西。这与消费信贷智能体把评分留在智能体够不着的、经申报的模型里是同一个论证，而且它可以推广：凡是已经存在一个确定性权威的地方，智能体的活就是喂它、并审计它。

首要的控制是一个计时器，不是一条置信度阈值。

在多数领域里，一个不确定就上报的智能体表现良好。在薪资里，等待本身就是错误，因为义务是带日期的，而罚款是迟到时长的函数、而不是金额大小的函数。美国联邦缴存罚款按阶梯走：迟 1 到 5 个日历日为 2%，迟 6 到 15 日为 5%，超过 15 日为 10%，而一旦「立即付款通知」发出后十日仍未回应即为 15%——这是一个用高档取代低档、而不是层层相加的阶梯，并且它不在乎这次延误来自一个难题还是一条没人读的消息。

• 每个智能体任务都带一个由义务导出的截止时间，而不是由队列策略导出的。一个「半周缴存者」的义务、一份季度申报、1 月 31 日的申报单截止日、某个州自己的新雇报告窗口。任务的 SLA 是义务日期减去你内部的复核时间，并且在任务创建时就定下来。
• 「我不知道」要转交，绝不阻塞。不确定性要产出一次给具名个人的上报，带上截止时间，并写明默认动作。一次没人接手的上报在计时器到点时向上重转。这个模式就是智能体产出的复核队列，只不过这里的队列带一个时钟，而这个时钟有后果。
• 请倒着推日历，并且早到足以允许自己错一次。智能体应当在期间的早段就把登记缺口、缺失的税表和未对上的方差打开，因为它们多数的补救都要占用别人好几天时间。一个在缴存截止日当天才抛出「缺一个州登记」的智能体，技术上成功了，实际上失败了。
• 定时运行需要它自己的失败警报。一个没有跑起来的薪资智能体，与一个什么也没发现的薪资智能体无从区分，而这正是失败趋开放最贵的那种形态。请按定时与触发式智能体对心跳做断言，并把一段沉默的时期当成一次事故、而不是一个平静的星期。

有一点值得明说，因为它与通常的直觉相反：在这个领域里，你应当更偏好一个「照着一条有据可查的默认动作行动、并把它标出来」的智能体，而不是一个为了等人而暂停的智能体。一笔按时做出、下一期再更正的默认缴存，代价是利息；而一笔漏掉的缴存，代价是一级阶梯罚款、一封通知，以及接下来三个月里每个月占用财务主管一小时的注意力。

请把能力花在对账与例外上——那里的事实基准本来就已经存在。

真正把一个薪资团队吃掉的活不是计算。而是一条长尾：在那些「本该一致却并不一致」的系统之间做比对，每一项都需要有人读两条记录加一张税率表，然后判定哪一条是错的。那是一项近乎理想的智能体任务：量大、创造性低，而且每个答案都有一道确定性检查可用。

• 「毛额到净额」的期间同比方差。按员工、按收入代码、按税种。凡是出现了变化却没有对应的输入变化——一项新扣款、一次税率表更新、一次辖区变更——就标出来，并点名候选成因。仅这一道检查就能抓住大部分原本会变成 W-2 更正的东西。
• 薪资与总账的对账。那项周期性的、枯燥的、可以往后拖的任务，同时也是一次没被注意到的错误记账会累积整个季度的地方。与应付账款智能体里的匹配工作是同一形状，而它想要的处理也一样：提出那笔更正分录，绝不过账。
• 机构通知分拣。通知以扫描 PDF 的形式抵达，几十种格式、几十个机构，而多数只是告知性的。请分类、抽取截止时间与金额、关联到对应期间，并把带上支持性明细表的回复起草好。抽取准确率应当在要紧的那个样本上测量——也就是带截止时间的那些通知——而不是在整个邮箱上，后者正是消费信贷智能体在它自己那条长尾上犯的错。
• 申报与明细表的对账要在报出前做，而不是报出后。报出的季度工资额对上各期间明细表之和；年度申报单对上四份季度申报。在提交前发现的不一致是编辑；提交后发现的，是更正申报。
• 登记与账户覆盖。对本期数据里出现的每一个工作地点，这个地点触发的每一个税种，是否都存在一个有效的雇主账户？这是抓住远程办公漂移的那道检查，而它纯粹是查表——智能体的贡献在于它每一期都跑，而不是一年跑一次。

绝不要让模型去推断辖区；让它去调用查表，并在查不到时停下。

美国有七千四百多个地方征税辖区，而且每年新增约两百个。仅宾夕法尼亚一州，就有两千五百多个市镇与将近五百个学区依据 Act 32 征收劳动所得税；俄亥俄有 649 个市镇与 199 个学区征所得税，还有把某市的税延伸到市界之外的联合区。没有哪个模型正确地记住这些，而那些大致记住的才是危险的情形，并且这些边界并不遵循邮政地址。

• 「地址到辖区代码」是一次工具调用，而它的失败是终态。智能体不得对某条街属于哪个市镇做推理、不得挑最近的匹配、不得退回州级默认值。一个未能解析的地址要变成一项带截止时间的例外——见重试放大里「终态对可重试」的那条区分，它在这里完全适用。
• 居住地与工作地是两个答案，而两个都需要。互惠协定、居民抵免与地方分摊，全都取决于这一对。一个只收集了其中一个、把另一个当然地假定了的智能体，会产出一笔看似合理却错误的代扣——而这是最糟的那一类，因为它能活过复核。
• 一个新的工作地点是一条登记工作流，不是一个数据字段。一名员工跨州搬迁，可能触发一个所得税代扣账户、一个失业保险账户、新雇报告、一个地方账户，有时还有一个带薪休假计划。智能体的活是在地址变更那天就把那份检查清单打开，并且一路追下去——这是个案办理模式向内的应用。
• 税率表版本属于记录的一部分。请把智能体推理过的每一次计算所用的表版本钉住，并把它记在决定旁边。当两年后某个机构对一笔金额提出异议时，问题是当时生效的是哪一版表，而只记了结论、没记表版本的审计轨迹答不出来。

这个实例所体现的一般规则值得留着：在任何有已公布权威表格的领域里，智能体的价值在于知道「这里必须查表」、以及注意到「有一次没查」——而绝不在于记住表的内容。编造出来的税率很少见；编造出来的辖区可不少见，因为一个地址看起来确实像是「足以据此推理」的信息。

面向员工的那个界面用量最大，也最容易搞错。

「我这个月的工资为什么不一样」是每家公司最常见的薪资问题，而把它答好，对员工的价值超过本页上的任何别的东西。它也是「一张正确的工资单」与「一段错误的解释」合起来造成真实伤害的地方：员工改掉了一个代扣选项、对一笔扣款提出争议，或者对一个本来是对的数字失去了信任。

• 请从引擎的逐项明细来解释，绝不重算。答案是两份逐项明细的 diff，加上造成它的那处输入变化。如果智能体指不出一处输入变化，答案就是「我还不知道，这是正在查的人」，而不是一段恰好落得很近的算术重建。
• 在「帮忙就等于有害」的那些类别上，请转交而不要作答。扣发工资令与法院命令、移民身份、休假与伤残工资、离职与最终工资规则，以及任何触及福利选择截止日的事。每一项都有一位专员和一份法律暴露，而一段自信的转述就是那个失效模式。这是人在环中里那条「称呼与权限」的切分，只不过按主题而不是按风险分来施用。
• 请把工资单当作一份有法律效力的文件。在若干辖区里，那份逐项明细是一项有自己罚则的强制披露，所以任何与它并列呈现的智能体生成摘要，必须在观感上明显是一份摘要，并且不得复述任何它没有从那份明细里读到的数字。
• 绝不要去问你已经握着的东西，也绝不要回声出超过被问的部分。一个薪资智能体能拿到薪酬、扣发工资令、福利选择与被抚养人信息。对员工本人提问的检索范围就是这名员工，由查询来强制，而不是由提示词来强制。

更正会层层波及，所以请把第一次申报当成唯一便宜的那一次。

一次薪资错误的经济学是不对称的，而这种不对称应当改变你买多少复核。更正一份季度申报是一次单独的更正申报；更正一份工资申报单意味着一份更正单、一份汇总表，而且——如果年度已经关闭——还会波及到员工本人的个人所得税申报，那个你修不了、必须他们去修。每一次都消耗专员的时间，而那位专员正是你的智能体本该腾出来的那个人。

• 请把「准备」与「提交」永久分开。智能体来拼装；一位有资质的人来签。申报上的签名是一份个人的法律确认，而你自己组织内部的任何授权都改变不了这一点——这使它成为整个系统里唯一一道不能交给策略引擎的批准。绑定机理在批准与确认 UX 里。
• 请按不可撤销性、而不是按金额给复核加权。一笔可以下一期更正的大额付款，比一处二月才被发现的小额工资单错误更便宜。请按「更正路径有多贵」给复核队列排序，而对多数薪资对象而言这意味着：申报单第一、申报第二、缴存第三。
• 请把智能体的证据留得比它的轨迹更久。一次在两年后被争辩的更正，需要智能体当时用过的明细表、税率表版本和输入 diff——那是一份体量小、有结构的记录，它应当按一条有意设定的策略活过完整轨迹，见留存与法律保留。
• 请按「避免掉的更正数」而不是「完成的任务数」来衡量这个智能体。每千名员工每季度的更正申报数，上线前与上线后。这是唯一一个能把「在做对账工作的智能体」与「在生成看起来像对账的笔记的智能体」区分开的数字，而且它正是一位薪资经理本来就在跟踪的数字。