本项目面向中小微企业建设一个整体智能体。灵活用工与用工税筹只是其中一个业务子模块,不是整个产品。
当企业用户提出用工、临时工、合规用工、用工成本、结算、保险、发票等相关问题时,主智能体会调用该子模块。该子模块负责理解用户意图、生成办理草稿、做成本对比、识别风险、生成提交前数据,并在用户确认后交给后端流程继续处理。
当前计划增加一个微信小程序,作为企业主和临时工使用的轻量前台。
中小微企业用户通常不希望先回答大量问题。产品体验应当是:
智能体先帮用户生成草稿 -> 用户确认或修改 -> 后端继续办理
默认逻辑:
例如企业已有一批临时工时,不应一开始要求企业主逐个填写名单。更好的方式是先生成登记批次和二维码,让临时工扫码自行登记。
前台用户体验中,不应频繁出现“第三方 API”“连接器 payload”“某某平台接口返回”等技术表达。
用户看到的是:
我已帮你生成这批临时工规范办理草稿。
确认后,将继续进入登记、保险、打卡、结算等流程。
内部系统可以记录:
provider = partner_platform
action = create_requirement
audit_required = true
只有在用户授权、合同、保险、结算、发票、支付、法律合规或用户明确询问时,才需要披露外部服务方或第三方处理信息。
企业主最关心的不是复杂费率,而是三个结果:
企业总支出
平均每人成本
员工到手金额
灵活用工模块需要展示:
三种方案的真实名称、费率、适用条件后续应从正式方案目录中配置。当前测试阶段可以使用测试默认值,但必须清楚标注为测试数据。
微信小程序只作为轻前台,不承载核心智能体逻辑。
小程序负责:
小程序不负责:
flowchart LR
A["微信小程序"] --> B["业务后端 API"]
B --> C["主智能体 / LangGraph"]
C --> D["灵活用工与用工税筹子模块"]
D --> E["模块私有 RAG"]
D --> F["成本测算服务"]
D --> G["审计与确认模块"]
D --> H["第三方连接器模块"]
H --> I["合作平台 API"]
J["临时工扫码登记页"] --> B
B --> K["业务数据库"]
B --> L["文件/图片/附件存储"]
sequenceDiagram
participant U as 企业主
participant MP as 微信小程序
participant API as 业务后端
participant Agent as 主智能体
participant FE as 灵活用工子模块
participant Worker as 临时工
participant Conn as 连接器模块
U->>MP: 我现在有一批临时工,想规范一下
MP->>API: 提交用户消息
API->>Agent: 请求意图识别和处理
Agent->>FE: 调用灵活用工子模块
FE->>FE: 生成登记草稿和默认字段
FE->>FE: 生成成本对比
FE-->>API: 返回草稿、成本方案、待确认项
API-->>MP: 展示草稿和成本对比
U->>MP: 确认或修改,选择方案
MP->>API: 提交确认结果
API->>FE: 生成临时工登记批次
API-->>MP: 返回二维码/登记链接
Worker->>MP: 扫码填写个人信息
MP->>API: 提交临时工登记资料
API-->>MP: 企业主查看登记进度
U->>MP: 确认提交
API->>Conn: 内部提交办理请求
企业主输入自然语言需求
-> 智能体生成用工需求草稿
-> 展示成本对比和风险提示
-> 企业主确认或修改
-> 进入审计与确认
-> 后端提交办理
-> 小程序展示状态进度
第一版小程序建议只做最小闭环。
首页 / 对话页
用工草稿页
成本对比页
确认提交页
登记进度页
临时工通过二维码进入轻量登记页。
需要支持:
临时工端不需要看到企业主的成本测算和方案选择。
负责:
建议技术:
负责:
当前已规划技术:
负责:
注意:连接器细节不直接暴露给用户。
负责:
所有模块必须有接收层和输出层。
外部上下文
-> 接收层转换为模块内部标准格式
-> 模块内部处理
-> 输出层转换为目标方需要的格式
小程序不直接适配灵活用工模块内部结构。推荐路径是:
小程序
-> 业务后端 API
-> 主智能体
-> 灵活用工子模块
-> 输出给业务后端
-> 小程序展示
这些接口用于技术沟通,不是最终定稿。
POST /api/v1/agent/messages
请求:
{
"enterprise_id": "ent_001",
"conversation_id": "conv_001",
"message": "我现在有一批临时工,想规范一下"
}
返回:
{
"reply": "我先帮你生成一份临时工规范办理草稿。",
"next_action": "show_employment_draft",
"draft_id": "draft_001"
}
GET /api/v1/flexible-employment/drafts/{draft_id}
返回:
{
"draft_id": "draft_001",
"scenario": "existing_worker_regularization",
"work_location": {
"value": "企业注册地址",
"source": "enterprise_registered_address",
"editable": true
},
"insurance_required": true,
"check_in_required": true,
"qr_valid_days": 7,
"missing_fields": ["主要工作内容"],
"risk_prompts": []
}
GET /api/v1/flexible-employment/drafts/{draft_id}/cost-comparison
返回:
{
"rows": [
{
"plan_id": "current",
"plan_name": "当前处理方式",
"employer_total_outflow": 48000,
"employer_average_cost_per_worker": 6000,
"worker_take_home_per_worker": 6000
},
{
"plan_id": "plan_1",
"plan_name": "测试方案一",
"employer_total_outflow": 51705.6,
"employer_average_cost_per_worker": 6463.2,
"worker_take_home_per_worker": 6000,
"status": "test_only"
}
],
"notice": "当前方案数据为测试默认值,正式费率以后端方案目录为准。"
}
POST /api/v1/flexible-employment/drafts/{draft_id}/confirm
请求:
{
"selected_plan_id": "plan_1",
"confirmed_fields": {
"work_location": "某某工业园 3 号仓",
"work_content": "仓库搬运"
}
}
返回:
{
"batch_id": "batch_001",
"registration_url": "https://example.com/register/batch_001",
"qr_code_url": "https://example.com/qrcode/batch_001.png"
}
POST /api/v1/worker-registration/{batch_id}/submit
请求:
{
"name": "张三",
"mobile": "13800000000",
"id_card_no": "encrypted_value",
"bank_account": "encrypted_value",
"confirmed_work_type": "仓库搬运"
}
返回:
{
"status": "submitted",
"message": "登记已提交,请等待企业确认。"
}
第一版就需要重视:
第一版不建议上复杂跨端框架,先验证核心业务闭环。
建议使用后端模型路由:
模型调用必须放在后端,不在小程序前端直连。
第一阶段目标是做最小闭环 Demo,而不是一次性做完整系统。
建议范围:
暂不做:
需要后续确认:
推荐路线:
微信小程序做轻前台
FastAPI 做业务后端
LangGraph 做主智能体和模块编排
Pydantic 做模块间标准数据契约
灵活用工模块负责草稿、成本、风险、结构化
连接器模块负责合作平台 API
审计确认模块负责用户确认和留痕
核心体验不是让企业主填写复杂系统,而是:
智能体先生成方案,企业主确认,临时工扫码补资料,后端继续办理。