从一则 FDE 招聘开始：我做了一套酒店 AI 排班助手
上一篇拆完 AgentScope Java 的模型抽象层，我在结尾说：拆框架是手段，搭东西才是目的。 下一站，要拿酒店客房部排班做一次实战。
现在，第一版已经跑起来了。
这套助手叫「栖班」。目前可以查看运营情况、管理人员和规则、生成周排班方案，再让 AI 结合门店上下文提出建议。后端用 AgentScope Java 组织 AI 能力，用 Timefold 负责排班求解，业务数据和确认后的方案保存在 MySQL。
本文截图来自项目实际操作录屏，使用的是模拟业务数据。它展示的是一套可独立运行的 MVP，目前还没有接入酒店生产系统。
这一篇先交第一份项目作业：为什么选酒店排班，AI 放在哪一层，哪些功能已经做出来，以及从这个版本继续往真实业务走，还要补什么。
一、为什么一个 AI 岗位，偏偏要求酒店经验？
这个项目的起点，是我刷招聘软件时看到的一条岗位。
岗位叫 AI 应用工程师，做的是偏 FDE 的业务落地工作。吸引我的却是另一条要求：需要有 1～3 年酒店或连锁餐饮行业经验。
我以前基本没接触过酒店业务。当时就有点好奇：一个开发岗位，为什么把行业经验放得这么靠前？如果没有这个背景，能不能通过调研和需求拆解，先把一个具体场景做出来？
于是，我对照 JD 里的“人力与组织赋能”方向，给自己做了一次模拟入职练习。范围没有铺到整个酒店管理系统，而是收在客房部排班：哪些房需要清扫，什么时候需要人，哪些员工能承担任务，最后怎么安排班次。
这个范围不大，但很适合检验 AI 应用的成色。你做出一张漂亮班表，业务人员还会继续问：上午退房高峰够不够人？请假的人有没有被排进去？新人能不能接这些任务？为了补缺口，要改动多少人的原班次？
这些问题回答不了，页面再完整，也很难进入工作流程。
二、先把“需要多少人”算清楚，再谈智能排班
一开始说“做个智能排班系统”，其实还是太笼统。继续拆下来，我发现至少要先回答两件事：今天有多少工作量，这些工作必须在什么时间完成。
客房清扫也不能只拿一个房间总数来算。退房清扫、续住清扫、VIP 房间、提前入住准备，各自的工作量和完成时限可能不同。
所以，我在后端先做了一个需求引擎：把业务快照拆成具体清扫任务，再根据单项任务耗时和时间窗口，计算总工作量、逐小时人力需求，以及 FTE（全职当量）。
这里的 FTE，是把工作量折算成标准工作日的人力需求。它回答“这些活大致需要多少标准工时的人力”；具体由谁、在哪个班次完成，还要继续求解。
这也让我意识到，一天的总人数够用，不代表每个时段都够用。 如果退房任务集中在上午，下午再补人，也解决不了上午的清扫缺口。
当前需求曲线采用按任务时间窗分摊工作量的方式，便于把计算过程讲清楚、查清楚。后续接入真实数据，再校准不同房型的耗时、员工熟练度和高峰分布。
在这一步里，我没有让大模型估算工时、编造覆盖率。任务工时、供需和成本由代码计算；AI 可以帮助解释这些数字。
三、AI 最有价值的位置，是业务人员和排班模型之间
经理会说：“小王周三请假”“上午清扫高峰多安排人”“新人别一下接太多退房任务”。但求解器需要的是明确的规则类型、员工、日期、数量和约束强度。
这中间正好有一层工作适合 AI：理解业务描述，把它整理成系统能识别的规则候选。
我给这条链路加了两个边界。
第一，AI 要先查系统支持什么。 规则建模 Agent 可以调用工具查询规则目录、员工名单和已有规则，再提交候选。涉及员工时，名字要和实际名单对得上；涉及规则时，参数要通过后台校验。
如果经理提出目录之外的要求，系统可以留下待扩展提案。新业务语义仍然需要开发对应的约束能力，不能因为 AI 写出一句规则，后台就默认已经会执行。
第二，候选需要人工确认。 AI 提交的规则先处于候选状态，业务人员核对参数、确认后，才进入相应求解流程。
例如“员工不能在请假日上班”，属于必须满足的要求；“尽量让大家的工作量接近”，属于需要权衡的偏好。把两者分开，模型才知道发生冲突时先保什么。
确认后的规则由后台转换层变成求解器可用的参数。求解完成后，再让 Agent 读取结果，解释人力缺口、任务安排和调整方向。
这张图对应后端的单日客房任务链路。当前周班表有独立的周求解路径，两条链路的规则范围需要分别核对。
我的分工就这样逐渐清楚了：AI 帮人表达和理解，后台负责规则转换、计算与求解，业务人员负责确认。
这里也不能把求解器写成“永远给出唯一正确答案”。排班通常有多种可行方案，服务、成本和公平性之间还会有取舍。Timefold 在设定的约束和时间限制内搜索方案；是否满足已建模的硬约束，要看实际结果和诊断。这个边界也与 Timefold 的约束与评分文档一致。
四、第一版做到了哪里？看一遍实际操作
为了让这套能力能被操作，我把前端做成了六个页面：运营总览、智能排班、人员管理、排班规则、AI 排班顾问和运营分析。
但这一版最值得讲的，是经理如何从“看见问题”走到“确认方案”。
1. 先看业务和可用人员
运营总览把入住、退房、在岗人数和班次概览放到一起，方便经理先了解当前情况。人员管理可以查看员工的部门、技能、状态和工时，支持新增成员、调整时薪。
这些信息决定排班模型的输入。员工处于休假状态、某类任务需要熟练员工，都应该来自明确的数据，而不是让 AI 临时猜。
目前 PMS 快照支持 JSON 导入。Excel 解析工具是下一步：先识别字段、处理格式，再校验、预览和入库。第一版先把后面的计算链路跑通。
2. 在周班表里选策略、看结果
智能排班页可以查看整周班表，区分早班、中班、晚班、弹性班、休息和请假，也能查看周工时。
生成优化方案前，可以选择综合平衡、服务优先或成本优先。这些选项在后台对应不同的求解权重。
当前周求解会保留请假安排、限制一周工作天数，并权衡人力覆盖、原班表改动、工作量分布和成本偏好。它从现有班表出发，搜索一份更适合当前目标的方案。
方案生成后先供预览，经理可以查看变化、调整具体班次，再确认保存。覆盖率、最大人力缺口和周人工成本，由后台根据班表与需求数据计算。
我觉得这里有个很实际的取舍：优化也要考虑原班表被改了多少。 一份指标更漂亮的方案，如果把很多人的安排都打乱，未必更容易被门店接受。
3. 用大白话咨询，让顾问结合上下文回答
AI 排班顾问可以接收“明天重点保障退房清扫高峰”这样的需求，再结合当前运营情况给出建议。
录屏里的一次真实回复，就引用了系统提供的入住率、待清扫房间数和可排班人数，提出早、中、晚班的人力分配思路。
这是一段顾问建议，不代表这些班次已经写入班表；具体安排仍需在排班模块里查看、调整和确认。
后端另外有结果解释 Agent，可以通过工具读取单日求解结果，把缺口和工作量等指标转成业务语言。我在提示词里要求它只引用工具返回的数字，不凭空承诺“调整后能省多少钱”。
五、为什么用 AgentScope？长期记忆又是怎么做的？
这次项目的技术栈并不复杂：
| 层 | 实际选型 | 在项目里负责什么 |
|---|---|---|
| 业务后端 | Java 21、Spring Boot 3.5.4 | 规则校验、需求计算、接口和流程 |
| Agent | AgentScope Java 2.0.2 | 规则工具调用、候选生成、结果解释和顾问建议 |
| 排班引擎 | Timefold Solver 1.34.0 | 按约束和策略搜索排班方案 |
| 数据层 | MyBatis-Plus 3.5.17、MySQL | 人员、业务快照、规则、班表和门店记忆 |
| 前端 | Vue 3.5、TypeScript、Vite、Element Plus、ECharts | 业务操作、班表查看与图表展示 |
当前模型通过兼容通道接入 GLM，模型配置集中管理。上一篇拆的模型层，在这里变成了项目的一项实际依赖。
选择 AgentScope，也和前面七篇的积累有关。我已经熟悉它的 ReAct 工具循环、工具注册和结构化输出，可以把“查目录—查名单—提交候选”组织成一段受控的 Agent 工作。
不能把这个选择理解成“Spring AI 只能做单次对话”。Spring AI 同样有工具调用和聊天记忆能力。我选择 AgentScope，是为了沿着已有的技术积累，继续验证它在业务项目里的使用方式。
长期记忆则需要项目自己设计。我想保留下来的，是这家门店的业务上下文：最近的经营画像，经理已经接受的方案，以及明确表达过的管理偏好。
改造后的方案有两条写入路径。
一条来自系统：导入业务快照时记录经营画像，确认周方案时记录覆盖率、缺口、成本等摘要。这些内容有业务数据和确认动作作为来源。
另一条来自对话：AI 提炼可能值得保留的偏好或事实，先放进候选。经理检查后启用，才进入后续顾问的上下文；过时的内容也可以停用或删除。
这些记忆由应用层保存在 MySQL。下次咨询时，系统把有效记忆和本次运营信息一起提供给顾问。当前采用有数量上限的直接注入方式，还不需要先搭一套复杂的检索系统。
它的价值很具体：经理已经确认过的安排和偏好，可以在下一次咨询时继续被参考。
记忆目前只影响建议。 如果某条偏好需要成为排班的强制要求，还要由人把它转成系统支持的规则并确认。门店记忆不能悄悄改掉排班约束。
六、从可运行 MVP 到门店使用，还要做哪些验证？
这个版本让我先跑通了数据、求解、建议和人工操作。接下来最关键的工作，是让输入、规则和使用习惯都经得起真实门店的检验。
首先是数据。PMS 提供客房和入住业务，人员、考勤、请假等信息则可能来自其他管理系统。对接之前要先确定数据口径、更新时间和异常处理，不能只把接口连上就算完成。
其次是规则范围。目前，单日客房任务求解和周班表求解各有自己的模型。后续要把规则适用范围说明得更清楚，逐步统一接入，避免出现“规则页有这条规则，当前引擎却没有执行”的情况。
真实交付还要核验工时制度、跨周连续工作、班次间休息，以及门店自己的岗位和服务要求。一个求解器只能执行已经建模的约束；它不会自动补齐业务规则。
最后，要让客房经理实际使用：看不看得懂缺口提示，改班顺不顺手，建议是不是符合现场经验，以及临时请假时该怎么处理。
等这些问题有了真实反馈，才适合讨论节省了多少排班时间、减少了多少临时调班。当前页面上的演示指标，先用于观察功能，不拿来证明经营收益。
写在最后
回头看那条招聘，我更能理解为什么企业会看重行业经验。
AI 辅助开发，让我更快做出了第一版。但它不会主动告诉我：客房部实际怎么交接，清扫高峰为什么出现，经理愿意接受怎样的班表改动。
这些问题，要靠调研、拆解和使用反馈继续回答。
对没有行业背景的开发者来说，我觉得可以先从一个足够具体的场景开始。把业务数据和约束摸清楚，让 AI 帮上它擅长的那一段，再拿可运行的成果去验证。
这次我交出的，是酒店客房部 AI 排班助手的第一版。之后每完成一次真实的改造、数据对接或场景验证，我会继续沿着这个项目写下去。
我是亦暖筑序，一个在 Java AI 应用方向持续挖源码、搭东西的程序员。前面七篇拆框架，从这一篇开始，我们把它放进业务里。
系列导航（相关文章在公众号）
本文是「AgentScope Java 实战」第 08 篇，也是酒店 AI 排班项目的第一章。
- AgentScope Java 实战：Tool 和 Service 到底怎么划分边界？
- AgentScope Java 实战：AgentStateStore 到底怎么用？
- AgentScope Java 实战：一次回复背后，ReActAgent 到底跑了哪几步？
- AgentScope Java 实战：Workspace 文件全拆解——AGENTS.md 是怎么跑进 system prompt 的？
- AgentScope Java 实战：SubAgentTool 全拆解——一个 Agent 是怎么把另一个 Agent 当工具使的？
- AgentScope Java 实战：Middleware 全拆解——5 个切点、16 个内置护栏，是怎么织进 Agent 的
- AgentScope Java 实战：模型抽象层全拆解——一个接口、九家模型，是怎么做到即插即用的
- 本文：从一则 FDE 招聘开始：我做了一套酒店 AI 排班助手
