算得出来，为什么我们还是没用 Agent 算薪

技术上，我们有办法让 Agent 协助算薪，项目交付时却没有采用。客户的员工经常临时调往其他城市，适用规则跟着变，写进代码的逻辑也得反复修改。功能做出来以后，谁来接着管这些变化，成了我们必须考虑的事。

这是 2026 年 6 月至 8 月的一次企业飞书 AI 运营与管理自动化项目。团队两个人，我负责需求、产品设计，以及部分周报和运营 Agent 搭建。项目在 8 月交付，最后聚焦于会议、周报和项目协作。

算薪原本考虑的分工很清楚：脚本按明确规则计算，Agent 整理信息、衔接步骤。这条技术路径仍然可以讨论。不过，回头看“规则一变就改程序”这句话，会发现里面混着几种不同的工作。

员工换了城市，究竟要改什么

先设想几种情况，看看一次调动可能让工作停在哪里。它们用来说明问题，并非还原项目中的某次调动。

假如各城市的规则都已确定，员工只是换了所在城市和起止日期，主要要改的就是输入。记录补齐，程序可能就能按已有规则重算。人调得频繁，代码未必需要跟着频繁修改。

麻烦一些的情况是，业务已经确定新口径，程序却还不支持。得有人把规则写进配置或代码，再核对是否表达准确。决定已经有了，这时请业务重新讨论一遍“到底该怎么算”，反而可能耽误实现。

也可能组织还没说清楚，这类临时调动究竟适用哪套规则。那就需要先作出业务决定。

在使用者眼里，后两种情况都可能是“系统暂时算不了”。一个要找维护者更新程序，另一个要请业务先确定口径。混在一起处理，维护者就可能一边改代码，一边替业务作了决定；也可能只是输入填错了，却把事情送回去重新讨论制度。

程序停在哪里，还不足以告诉我们应该先找谁。

把规则放进表格以后

既然硬编码总要改，把规则做成配置表，是很自然的想法。版本、适用范围、生效时间与计算代码分开，已经明确的变化就有机会通过改配置完成，不必次次找开发者。

接着还得弄清楚：谁更新，按哪个版本更新，改完以后，旧记录要不要重算？负责维护的人要及时拿到明确口径，把它正确地写进系统，也让接手的人知道改了什么。

如果业务还没决定，配置界面再方便，也只是多了一个容易填写的空格。做产品的人有时会有这种期待：字段都准备好了，组织大概也能顺便把意见统一好。可表格安排得了答案放在哪里，安排不了大家什么时候有答案。

Agent 可以帮忙找依据、比较版本，把有疑问的地方整理出来。需要人确认，就把差异和材料一并交给他。否则，界面看着很简单，只剩一个“确认”按钮，按钮背后的人却得把整件事重新查一遍。

Bainbridge 在《Ironies of Automation》（1983）中提醒，自动化之后留给人的异常处理等工作，也需要得到支持。^[1] 她讨论的是工业控制。我借用这个角度来看这次方案：程序接走一部分工作以后，剩下的事，人是不是更容易做了？

条件变了，决定也要重看

如果规则来源明确，变化能够准确配置，更新和核对也有人持续负责，我不会再因为“业务经常变化”就否定这套方案。经常改一张口径明确的配置表，和每次先找人确定口径、再改程序，要花的力气很不一样。

只做到“能配置”还不够。规则虽然明确，却没有人在使用前更新；或者改完以后，接手的人不知道哪些计算受了影响，我仍不会建议把整条算薪流程交给 Agent。少做几步操作，还不足以让人放心使用结果。

可以先缩小范围：明确的计算交给脚本，整理资料、比较差异请 Agent 帮忙，未定的口径继续由业务处理。若脚本已经足够，Agent 就得有额外帮得上的地方。不必为了方案里有 AI，再给它安排一份工作。

我没有完整测量过这个项目的维护成本，不能说它证明了自动化得不偿失。能够确认的是，临时跨城调动带来了硬编码的反复调整。两个人的团队，交付时要考虑的不只是现在能实现哪些功能，还有交付以后能支持到什么程度。

我认可当时没有采用的决定，也愿意在规则和维护条件改善后重新评估。那次选择有它的具体原因，不能据此推断 AI 不适合算薪。

下次演示，走完一次变更

再遇到类似需求，我会更早请业务拿出近期的一次真实变更，跟着走完：口径怎么定，信息怎么进系统，哪里要更新，结果由谁核对。也看看关键的人暂时不在时，工作会停在哪儿。

程序无法表达已定规则，就改实现；口径没有确定，就先处理业务决定。如果每一步都走得通，只是还不清楚是否省事，就把确认、等待、修改和复核的时间记下来，再作比较。

演示结束后，下一次又有人临时换城市，我希望接手的人知道自己要做什么、遇到问题可以找谁。那时再来看这套方案，比只看它算出一个结果，要踏实一些。