企业级 AI Skill 的本质是业务履约生产线

企业级 AI 真正要沉淀的，不是一个越来越像人的 Agent，而是一组可复现、可审计、可替换执行器的 Skills。

但这个判断还可以再往下走一步：

高质量 Skill 的本质，不是 prompt，也不只是 workflow，而是一个被模型化的业务履约单元。

为了让例子统一，下面都用同一个场景来讲：薪酬 SaaS 的月度薪资结算 Skill。

场景是这样的：每月结薪时，HR 或薪酬专员发起本月薪资结算。系统需要根据员工主数据、劳动合同、考勤记录、调薪审批、奖金政策、社保公积金基数、个税规则和发薪日历生成薪资快照。如果员工应发工资波动超过阈值，需要核查审批；如果考勤、奖金或社保基数材料不足，需要中断并要求补充；如果所有校验通过，才能生成可提交财务发放的薪资包。

这个场景看起来只是“让 AI 帮 HR 看薪资异常”，但真正的企业级问题不是说明写得像不像，而是：谁发起结薪？依据是什么？工资怎么算？奖金谁批准？社保基数从哪来？哪条政策生效？薪资包凭什么可以发放？出了错谁负责？这些问题如果没有被 Skill 固化，就会被塞进 Agent 的临场判断里。

Skill 不是 Prompt

一个高质量 Skill 至少要钉死六件事：

• Workflow：任务怎么拆，哪些步骤先后执行，哪里需要暂停确认。
• Context：上下文从哪里来，不能靠 Agent 自己记得。
• Script：确定性部分应该交给脚本、schema、校验器，而不是交给 LLM 猜。
• Constraint：哪些不能越权，哪些不能补，哪些必须有来源。
• Reasoning Contract：什么时候需要推理，走直接回答、链式分解、并行探索还是迭代验证，最多消耗多少预算，何时停止或升级。
• Validator：结果是否合格，要靠 checklist、test、schema、audit report 或人工确认点。

套到薪资结算 Skill 里，这六件事分别是：

• Workflow：读取本月结薪任务、拉取员工范围、同步考勤和薪资项、计算薪资、检测异常、核查审批、生成薪资快照、提交 HR 确认、生成财务发放包。
• Context：员工主数据、劳动合同、薪资档案、考勤记录、调薪审批、奖金审批、社保公积金基数、个税规则、发薪日历、历史薪资快照。
• Script：工资项计算、考勤扣款、奖金合并、社保公积金计算、个税计算、涨幅阈值判断、薪资包 schema 校验、银行代发文件生成。
• Constraint：Agent 不能自行发明薪资项，不能跳过审批，不能使用过期政策，不能跨租户或跨员工误用证据，不能把未确认快照当作正式发薪包。
• Reasoning Contract：发薪日查询这类简单问题不启动深推理；薪资涨幅异常、政策版本冲突、审批记录缺失时进入结构化推理；证据不足或验证失败时停止并升级人工。
• Validator：薪资项完整、计算口径一致、政策版本有效、审批记录匹配、异常处理闭环、HR 或薪酬负责人确认完成。

如果这些只是写在 prompt 里，比如“请严格按照薪酬政策生成工资单”，那仍然是在赌模型听话。企业级 Skill 要做的是把这些规则变成状态、脚本、权限、凭证和校验器。

用履约建模法重新定义 Skill

履约建模法的核心不是对象，也不是流程图，而是从合同和权责关系理解业务。

放在薪资结算场景里，可以这样看：

• 劳动合同和薪酬制度，是企业向员工履行薪酬支付义务的依据。
• 每月薪资快照，是本次薪酬履约的计算结果和确认对象。
• 发薪包一旦提交财务或银行，就进入实际支付和后续对账。
• 薪资过程中涉及员工、直属主管、HR、薪酬专员、财务、审批人等责任主体。
• 薪资能否发放，不取决于 Agent 解释得是否流畅，而取决于它是否满足合同、考勤、政策、审批、税务和审计要求。

所以，一个薪资结算 Skill 不应该被理解为“生成薪资异常说明的提示词包”，而应该被理解为：

为了完成月度薪酬支付这个业务履约项，而封装的一条可审计、可复现、可校验的微型生产线。

对应关系可以这样看：

Skill 要素	履约建模来源	薪资结算 Skill 中的体现
Workflow	合同生命周期、履约项、违约项	从结薪发起、数据同步、工资计算、异常核查到发放确认
Context	合同上下文、参与方、标的物、凭证	员工、合同、薪资档案、考勤、政策、审批、薪资快照
Script	领域系统中可确定化的能力	薪资计算器、个税引擎、社保公积金计算、schema 检查
Constraint	合同条款、权限边界、合规要求、违约责任	不得越权改薪、不得跳过审批、不得跨员工误用证据
Reasoning Contract	履约判断、风险分流、证据标准、停止条件	决定是否深推理、走哪种推理拓扑、如何升级人工
Validator	履约确认、验收凭证、审计报告、人工确认	薪资快照、审批记录、计算明细、HR 确认
Exception Handling	违约履约项、补偿履约项、人工升级	考勤缺失则补充，涨幅超阈值则核审，校验失败则中断

尤其要注意异常处理。考勤缺失、调薪审批不存在、奖金政策版本冲突、社保基数变更无凭证、工资项重复发放，都不应该让 Agent 自己“想办法补一下”。这些异常应该触发明确的补充材料、审批、回退、重算或人工确认流程。

这样一来，Skill 的稳定性就不再依赖 Agent 是否聪明，而依赖薪资结算这条业务履约链是否清楚。

Agent 不应该拥有责任链

企业主流程最怕的不是 Agent 不够强，而是责任链被 Agent 吃掉了。

如果让 Agent 自己读历史邮件、判断员工薪资档案、推测奖金口径、生成薪资快照并解释原因，看起来很自动化，但责任链完全黑箱化了：

• 员工薪资档案是谁确认的？
• 考勤缺失是谁确认的？
• 调薪依据来自哪张审批单？
• 奖金政策是不是当前生效版本？
• 社保基数变更是谁提交和复核的？
• 超过涨幅阈值时谁审批？
• 生成结果凭什么可以提交财务发放？

如果答案是“Agent 会综合判断”，这就不是企业级流程，而是把 HR、薪酬、财务、主管、审批人的责任压缩进了一个会说话的黑箱。

用履约视角设计薪资结算 Skill，结构会完全不同：

• 结薪请求来自发薪日历、租户配置或薪酬专员发起的结薪任务。
• 员工范围来自 HRIS、组织架构和劳动合同状态。
• 考勤数据来自考勤系统和主管确认。
• 薪资项来自薪资档案、调薪审批、奖金审批和福利政策。
• 薪资计算由确定性脚本完成。
• 超阈值涨幅触发异常核查或审批履约项。
• 发薪确认必须生成薪资快照、计算明细、异常处理记录和确认凭证。
• Agent 只负责从邮件、工单或会议纪要中抽取非结构化补充材料，不能自行决定薪资政策。

这时 Agent 仍然有价值，但它不再拥有流程。流程属于 Skill，责任属于业务履约关系。

推理也要成为 Skill 的一部分

这里需要补上推理模块的视角。企业级 Skill 不能只约束工具调用和流程状态，还要约束 Agent 如何做判断。

原因是：薪资结算流程里确实存在需要推理的节点。例如，小冰缺 2 天考勤是否能自动顺延处理，咖哥本月应发比上月高 18% 是否有审批支撑，小雪社保基数变更应该适用哪一版政策，奖金政策是否与审批记录匹配。这些判断不能简单写成“让 Agent 分析一下”，也不能把一段自然语言 CoT 当成审计证据。

更稳的做法，是把推理本身纳入 Skill Runtime：

• 先定义推理契约：这个判断是否需要深推理，采用直接回答、链式分解、并行探索还是迭代验证，允许多少模型调用和工具调用，由什么验证，达到什么条件停止。
• 再定义可验证命题链：每一步只表达一个可验证命题，例如“咖哥 6 月应发工资比 5 月高 18%”“18% 的增量主要来自季度奖金”“该租户规则要求涨幅超过 15% 时核查审批”“审批单金额、审批人和生效月份均匹配”。
• 然后把命题绑定证据、依赖和验证器：证据来自薪资快照、考勤表、薪资政策、审批系统、员工档案或合同记录；验证器来自规则引擎、权限系统、薪资计算器、schema 校验或人工确认。
• 最后保存推理追踪：记录选择了什么推理模式、引用了哪些证据、执行了哪些工具动作、哪个验证器放行、为什么停止或升级，而不是长期保存模型的脑内独白。

套回薪资结算 Skill，可验证 CoT 不是这样写：

综合工资组成、奖金政策和审批记录后，可以判断本次薪资异常合理。

而应该拆成类似这样的履约判断链：

1. 观察：咖哥 6 月应发工资比 5 月高 18%。
2. 推导：18% 的增量主要来自季度奖金，而不是基本工资或补贴。
3. 验证：该租户规则要求“单月应发涨幅超过 15% 时核查审批”。
4. 验证：季度奖金审批单 BONUS-18472 存在，金额、审批人和生效月份均匹配。
5. 决策：在工资差异计算、政策版本和审批记录均通过验证后，本次异常可以自动放行；否则中断并进入补充材料、重新审批或人工复核。

这会改变本文对 Skill 的定义：Skill 不只是“Workflow + Tools + Validator”，还应该包含一套受控的推理运行时。Agent 可以提出候选命题、解释验证结果、整理给人的说明，但不能自己宣称“证据充分”或“可以放行”。证据充分性、依赖是否通过、何时停止，都应该由 Skill 的推理契约和验证闸门控制。

区分业务 Skill 和领域能力

薪资结算 Skill 还需要区分业务履约和领域能力。

在这个场景里，领域能力包括：

• 员工主数据查询；
• 劳动合同和薪资档案查询；
• 考勤记录查询；
• 工资项计算；
• 奖金和调薪审批查询；
• 社保公积金计算；
• 个税计算；
• 银行代发文件生成；
• 审批流状态查询。

这些能力都应该尽量做成稳定工具、脚本、API 或服务，不要交给 Agent 自由发挥。

业务 Skill 负责的是另一件事：把这些领域能力组织进薪资履约链里。它要决定什么时候拉员工范围、什么时候同步考勤、什么时候算工资、什么时候触发异常核查、什么时候生成正式发薪包、什么时候中断并要求补充材料。

换句话说：

领域系统提供薪资结算所需的确定性能力，业务 Skill 组织薪酬履约，Agent 只在材料抽取、异常归因、说明生成等语义不确定节点介入。

如果把三者混在一起，Agent 就会同时承担员工判断、工资项计算、政策适用、审批判断和责任确认。系统看起来更自动化，实际上更不可控。

“换 Agent 不变性”来自履约结构

换 Agent 不变性，是判断 Skill 是否成熟的一个很好标准。

一个成熟 Skill 的标志，不是某个 Agent 跑得特别好，而是换一个合格 Agent，薪资结算结果也不该差太多。

在薪资结算场景里，如果换一个 Agent 就出现工资项口径变化、审批路径变化、社保基数适用变化、异常放行标准变化，说明真正的薪酬规则还没有沉淀到 Skill 里，而是藏在 Agent 的隐性推理里。

一个成熟薪资结算 Skill 应该做到：

• 员工范围由 HRIS 和劳动合同状态提供，不靠 Agent 从邮件里猜。
• 考勤和请假记录由考勤系统和主管确认提供，不靠 Agent 自行推断。
• 工资、社保、公积金、个税由脚本计算，不靠 Agent 推理。
• 政策版本由规则引擎或配置中心决定，不靠 Agent 选择。
• 可行动作由状态机暴露，不靠 Agent 猜接口。
• 合格标准由薪资快照 schema、审批记录和人工确认定义，不靠 Agent 自评。
• 推理路径由 Reasoning Contract、Claim Trace 和 Decision Gate 定义，不靠 Agent 自由展开 CoT。
• 异常路径由补充材料、重新计算、审批或终止流程定义，不靠 Agent 临场补洞。

这样 Agent 才能被替换，企业薪酬能力才真正沉淀成 Skill。

用 HATEOAS 让 Agent 只走被允许的路

HATEOAS 可以补上实现层。

HATEOAS 的核心是：客户端不需要提前知道所有业务 API，而是由服务端在当前资源状态下返回下一步允许的动作。客户端沿着服务端给出的链接和表单前进。

放到薪资结算 Skill 里，可以这样理解：

• Skill Runtime 是服务端。
• Agent 是客户端。
• 当前薪资批次或员工薪资快照是资源状态。
• 服务端根据薪资状态返回当前允许的动作。
• Agent 只能在这些动作里选择。
• 每一步执行后，服务端重新计算新的动作空间。

例如：

• 当薪资批次处于 missing_attendance 状态时，只暴露“补充考勤材料”“重新同步考勤”。
• 当员工薪资快照处于 delta_calculated 状态时，暴露“核查涨幅原因”“提交异常审批”。
• 当薪资快照处于 approval_required 状态时，只暴露“提交审批”“退回重算”，不暴露“生成发薪包”。
• 当薪资批次处于 ready_for_release 状态时，才暴露“生成财务发放包”“提交 HR 确认”。

这就把 Agent 从“自由规划者”降级成“受状态机约束的执行者”。

它不需要知道全量 API，也不应该自己拼工具调用。它只需要回答：在当前薪资状态下，服务端给我的这些合法动作里，哪个最适合下一步？

这不是让 Agent 更聪明，而是让系统每一步都只暴露它此刻能走、该走、被授权走的路。当然，超媒体隐藏的是交互入口，不是安全边界。即使没有暴露“生成发薪包”，服务端也必须在真正执行发放动作前再次校验薪资状态、审批记录和操作者权限。

一个设计薪资结算 Skill 的检查表

如果要把履约建模法用到薪资结算 Skill 设计里，可以从这组问题开始：

1. 这次结薪服务于哪个租户、哪个薪资批次、哪个发薪周期？
2. 结薪请求是谁发起的，依据是哪条发薪日历、租户配置或薪酬工单？
3. 员工范围、劳动合同状态、薪资档案从哪里来？
4. 考勤、请假、加班、补贴和扣款由谁确认，是否存在缺失或冲突？
5. 使用哪一版薪酬政策、奖金政策、社保公积金规则和个税规则？
6. 应发、应扣、实发、社保公积金、个税由哪个脚本或系统计算？
7. 当前薪资波动是否超过阈值，是否需要审批或人工复核？
8. 审批人是谁，审批结果以什么凭证留存？
9. 薪资快照生成后由谁确认，什么状态下才能生成财务发放包？
10. 考勤缺失、政策版本冲突、审批缺失、工资项重复、计算失败时分别怎么处理？
11. 哪些判断需要直接回答，哪些需要链式分解、并行探索、迭代验证或人工复核？
12. 每个关键判断能不能拆成观察、推导、验证、决策这些可验证命题？
13. 每个命题的证据引用、依赖项、验证器、停止条件和升级条件是什么？
14. Agent 可以在哪些节点做材料抽取、异常归因、摘要和说明生成？
15. 审计时能不能复盘：谁发起、谁授权、用了什么政策版本、谁审批、为什么可以发放，以及每个关键判断为什么被放行？

这组问题比“请写一个薪资 Agent prompt”更慢，但它得到的是企业薪酬能力，而不是一次 AI 表演。

结论

“让 Agent 变得不重要”不是否定 Agent，而是不要让 Agent 承担它不该承担的责任。

在薪资结算场景里，Agent 可以处理考勤异常说明、审批材料归纳、薪资波动解释和异常工单整理。但薪资主流程的稳定交付，不能依赖它的自由发挥。

真正值得沉淀的是以履约为核心的薪资结算 Skill：

• 用结薪任务确定责任链；
• 用员工、合同、薪资档案、考勤、政策和薪资快照定义上下文；
• 用薪资计算器、个税引擎和社保公积金规则承接确定性能力；
• 用 Reasoning Contract 定义什么时候该想、怎么想、想到哪里必须停；
• 用 Claim Trace 记录关键判断的证据、依赖、验证器和停止原因；
• 用审批记录和 HR 确认定义 validator；
• 用补充材料、重算、审批、终止和人工确认定义异常路径；
• 用 HATEOAS 约束 Agent 的行动空间。

这样，Agent 才从“像人的黑箱薪酬助理”变成“可替换的薪资流程执行器”。企业 AI 的成熟，也就从追逐更聪明的 Agent，转向沉淀更稳定的业务生产线。