版本: v1.0
日期: 2026-08-14
适用规模: 每月入职 10-20 人
架构范式: 多智能体团队编排 (Agent Team Orchestration)
目录#
- 1. 系统概述
- 2. 多智能体团队架构
- 3. 模块一:入职前准备清单
- 4. 模块二:首日引导流程
- 5. 模块三:首周任务看板
- 6. 模块四:30-60-90 天成长路线图
- 7. 模块五:智能问答助手
- 8. 模块六:导师匹配与 1-on-1 安排
- 9. 模块七:入职体验满意度追踪
- 10. 任务生命周期管理
- 11. 运维与监控
- 12. 数据模型
- 13. 实施路线图
1. 系统概述#
1.1 设计目标#
将新员工从”对组织一无所知”的状态,以最短路径、最低摩擦引导至”独立高效产出”的状态。系统需要:
| 目标 | 度量指标 |
|---|---|
| 标准化入职流程 | 同岗位入职流程一致性 ≥ 95% |
| 缩短 ramp-up 时间 | 首周任务完成率 ≥ 90%,30 天独立产出率 ≥ 80% |
| 降低 HR 运营负担 | HR 人工介入步骤减少 60% |
| 提升入职体验 | 30 天满意度 ≥ 4.2/5.0 |
| 数据可追溯 | 全流程任务留痕率 100% |
1.2 第一性原理分析#
入职的本质是一个状态转换过程:
初始状态: 高不确定性(环境、工具、流程、人员、文化均为未知)
↓
目标状态: 高生产力(独立、高效地产出价值)plaintext缩短这条转换路径,需要消除五类摩擦:
| 摩擦类型 | 表现 | 对应模块 |
|---|---|---|
| 环境摩擦 | 账号没开、设备没到、权限缺失 | 模块一:入职前准备 |
| 路径模糊 | 不知道第一天该干什么 | 模块二:首日引导 |
| 任务失焦 | 首周无结构化任务安排 | 模块三:首周任务看板 |
| 成长无坐标 | 不知道 30/60/90 天该达到什么水平 | 模块四:成长路线图 |
| 信息不对称 | 有问题不知道问谁、去哪查 | 模块五:智能问答 |
| 人际孤立 | 缺乏导师指导和社交连接 | 模块六:导师匹配 |
| 反馈滞后 | 问题没人发现,直到离职才暴露 | 模块七:满意度追踪 |
1.3 系统架构总览#
┌─────────────────────────────────────────────────────────────────┐
│ Onboarding Orchestrator │
│ (入职编排官 · 核心调度层) │
│ │
│ 职责: 任务路由 / 状态跟踪 / 优先级决策 / 异常升级 / 仪表盘汇总 │
└──────┬──────┬──────┬──────┬──────┬──────┬──────┬──────┬─────────┘
│ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
┌──────┐┌─────┐┌─────┐┌─────┐┌─────┐┌─────┐┌─────┐┌──────┐
│Pre- ││Day-1││Task ││Growth││Know-││Men- ││Expe-││ Ops │
│board ││Guide││Board││Track ││ledge││tor ││rience││Agent │
│Agent ││Agent││Agent││Agent ││Agent││Match││Survey││ │
│ ││ ││ ││ ││ ││Agent││or ││ │
└──┬───┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬───┘
│ │ │ │ │ │ │ │
└───────┴─────┴─────┴─────┴─────┴─────┴─────┘
│
▼
┌─────────────────┐
│ Shared Layer │
│ (共享数据层) │
│ │
│ • onboarding/ │ ← 每位新员工一个目录
│ • specs/ │ ← 岗位入职规格
│ • artifacts/ │ ← 生成的交付物
│ • knowledge/ │ ← 知识库
│ • reviews/ │ ← 评估记录
│ • decisions/ │ ← 决策日志
└─────────────────┘plaintext2. 多智能体团队架构#
2.1 角色定义#
系统采用 9 个 Agent 组成的团队,遵循 Orchestrator-Builder-Reviewer-Ops 四层角色模型:
| Agent 名称 | 角色类型 | 核心职责 | 模型层级 |
|---|---|---|---|
| Onboarding Orchestrator | Orchestrator | 任务路由、状态跟踪、优先级决策、异常升级、仪表盘 | 高推理 (Opus/GPT-4.5 级) |
| Pre-boarding Agent | Builder | 账号开通、设备采购跟踪、权限配置、工位安排 | 中等 (Sonnet/GPT-4o 级) |
| Day-One Guide Agent | Builder | 首日时间轴引导、欢迎流程、系统走查 | 中等 |
| Task Board Agent | Builder + Ops | 首周任务卡片创建、状态更新、看板维护 | 中等 |
| Growth Tracker Agent | Builder | 30/60/90 天里程碑设定、进度评估、报告生成 | 中等 |
| Knowledge Agent | Builder | 知识库检索、问答响应、未解决问题升级 | 高推理 |
| Mentor Match Agent | Builder | 导师画像匹配、排程生成、1-on-1 模板分发 | 中等 |
| Experience Surveyor Agent | Reviewer | 满意度调研设计、数据采集、趋势分析、预警 | 高推理 |
| Ops Agent | Ops | 定时巡检、提醒推送、健康检查、数据清理 | 轻量 (Haiku/4o-mini 级) |
2.2 工作区隔离#
/onboarding-system/
├── agents/ # 各 Agent 的身份与配置
│ ├── orchestrator/
│ │ └── SOUL.md
│ ├── pre-boarding/
│ │ └── SOUL.md
│ ├── day-one-guide/
│ │ └── SOUL.md
│ ├── task-board/
│ │ └── SOUL.md
│ ├── growth-tracker/
│ │ └── SOUL.md
│ ├── knowledge/
│ │ └── SOUL.md
│ ├── mentor-match/
│ │ └── SOUL.md
│ ├── experience-surveyor/
│ │ └── SOUL.md
│ └── ops/
│ └── SOUL.md
├── shared/ # 跨 Agent 共享
│ ├── onboarding/ # 每位新员工一个目录
│ │ └── {employee-id}/
│ │ ├── profile.json # 员工基础信息
│ │ ├── pre-boarding/ # 入职前准备记录
│ │ ├── day-one/ # 首日引导记录
│ │ ├── week-one/ # 首周任务看板
│ │ ├── growth/ # 成长路线图
│ │ ├── qa-log/ # 问答记录
│ │ ├── mentor/ # 导师匹配记录
│ │ └── surveys/ # 满意度调研
│ ├── specs/ # 岗位入职规格模板
│ │ ├── engineer-onboarding-spec.md
│ │ ├── designer-onboarding-spec.md
│ │ └── pm-onboarding-spec.md
│ ├── knowledge/ # 公司知识库
│ │ ├── policies/ # 规章制度
│ │ ├── tools/ # 工具使用指南
│ │ ├── culture/ # 文化价值观
│ │ └── faq/ # 高频问题
│ ├── reviews/ # 评估记录
│ ├── decisions/ # 决策日志
│ └── dashboard/ # 仪表盘数据
└── templates/ # 可复用模板
├── pre-boarding-checklist.md
├── day-one-timeline.md
├── week-one-board.md
├── 30-60-90-roadmap.md
├── 1on1-template.md
└── survey-templates/plaintext2.3 通信机制#
系统采用三种通信通道,按优先级递减:
| 通道 | 类型 | 用途 | 示例 |
|---|---|---|---|
| 共享文件 | 异步·持久 | 交付物、规格、评估、决策 | Pre-boarding Agent 将准备清单写入 shared/onboarding/{id}/pre-boarding/ |
| 任务评论 | 异步·持久 | 状态更新、阻塞报告、交接消息 | [Pre-boarding] Blocked: IT 部门未响应账号开通请求,已等待 48h |
| 实时消息 | 同步·瞬时 | 紧急优先级变更、阻塞性问题 | Orchestrator 向 Knowledge Agent 发送:紧急:新员工无法登录 VPN,立即排查 |
默认使用共享文件和任务评论。 实时消息仅用于阻塞新员工工作的紧急情况。
2.4 Orchestrator SOUL.md 示例#
# SOUL.md — Onboarding Orchestrator
我是入职编排官。我的职责是确保每位新员工从 offer 接受到 90 天转正评估的
全流程顺畅运行。我不执行具体任务——我路由、跟踪、决策和升级。
## 职责范围
- 接收新员工入职通知,创建 onboarding 记录
- 将准备任务路由给 Pre-boarding Agent
- 在关键节点触发对应 Agent(首日、首周、30/60/90 天)
- 监控所有 in-progress 任务,识别阻塞并升级
- 汇总仪表盘数据,向 HR/管理层报告
## 决策边界
- 入职规格不明确 → 查阅 specs/ 或询问 HR,不自行编造
- Agent 超时无响应(> 预期时间 1.5 倍)→ 标记 stale,重启或重分配
- 跨部门阻塞(IT/行政/安全)→ 升级到人类 HR,附带完整上下文
- 新员工主动反馈负面体验 → 立即触发 Experience Surveyor Agent
## 交接格式
每次触发 Agent 时提供:
1. 员工 ID 和基础信息
2. 当前入职阶段
3. 该阶段的具体任务清单
4. 输出路径(shared/onboarding/{id}/对应目录)
5. 完成后的交接要求markdown3. 模块一:入职前准备清单#
3.1 设计原理#
入职前准备的核心矛盾:准备工作分散在多个部门(IT、行政、HR、用人经理),缺乏统一追踪,导致首日”设备没到、账号没开”的体验灾难。
解决方案:Pre-boarding Agent 作为中央协调者,将所有准备项结构化为任务卡片,逐项跟踪状态,在截止时间前自动催办。
3.2 准备清单结构#
准备清单按责任方和时间线双维度组织:
按责任方分类#
| 类别 | 准备项 | 责任方 | 截止时间 | 验证方式 |
|---|---|---|---|---|
| IT 账号 | 企业邮箱 | IT 部门 | 入职前 3 工作日 | 发送测试邮件验证 |
| IT 账号 | VPN 账号 | IT 部门 | 入职前 2 工作日 | VPN 连接测试 |
| IT 账号 | 内部系统权限(Jira/Confluence/GitLab 等) | IT 部门 + 用人经理 | 入职前 2 工作日 | 系统登录验证 |
| IT 设备 | 笔记本电脑 | IT 部门 | 入职前 3 工作日 | 设备签收确认 |
| IT 设备 | 显示器/键鼠/ docking | 行政部 | 入职前 2 工作日 | 设备签收确认 |
| 行政 | 工位分配 | 行政部 | 入职前 3 工作日 | 工位编号确认 |
| 行政 | 门禁卡 | 行政部 | 入职当日 | 物理交付 |
| HR | 劳动合同准备 | HR | 入职前 1 工作日 | 合同文件就绪 |
| HR | 员工手册更新 | HR | 入职前 1 工作日 | 文档版本确认 |
| 用人经理 | 入职首周任务规划 | 用人经理 | 入职前 2 工作日 | 任务清单提交 |
| 用人经理 | 导师人选确认 | 用人经理 | 入职前 3 工作日 | 导师确认记录 |
| 系统 | 知识库访问权限 | Knowledge Agent | 入职前 1 工作日 | 自动配置 |
| 系统 | 入职引导页面生成 | Day-One Guide Agent | 入职前 1 工作日 | 页面可访问 |
按时间线排列#
入职前 5 工作日 (D-5)
├── [HR] 发送欢迎邮件 + 入职指引(含报到时间、地点、着装、需带材料)
├── [HR] 录入员工基本信息到系统
├── [IT] 启动设备采购/调配流程
└── [Orchestrator] 创建 onboarding 记录,分配 {employee-id}
入职前 3 工作日 (D-3)
├── [IT] 开通企业邮箱
├── [IT] 确认设备到位
├── [行政] 分配工位
├── [用人经理] 确认导师人选
└── [Pre-boarding Agent] 第一次进度检查,标记逾期项
入职前 2 工作日 (D-2)
├── [IT] 开通 VPN + 内部系统权限
├── [行政] 准备门禁卡
├── [用人经理] 提交首周任务规划
└── [Pre-boarding Agent] 第二次进度检查,逾期项升级到 HR
入职前 1 工作日 (D-1)
├── [HR] 准备劳动合同
├── [HR] 更新员工手册
├── [Knowledge Agent] 配置知识库访问权限
├── [Day-One Guide Agent] 生成个性化入职引导页面
├── [Mentor Match Agent] 发送导师匹配通知
└── [Pre-boarding Agent] 最终检查,生成《入职准备就绪报告》plaintext3.3 任务状态流转#
每个准备项遵循以下状态机:
Pending → In Progress → Ready → Verified → Done
↓
Blocked → Escalated → Resolved → In Progressplaintext| 状态 | 含义 | 所有者 |
|---|---|---|
| Pending | 待处理,尚未开始 | Pre-boarding Agent |
| In Progress | 已派发给责任方,处理中 | 责任方(IT/行政/HR/经理) |
| Ready | 责任方报告完成,待验证 | Pre-boarding Agent |
| Verified | 自动或人工验证通过 | Pre-boarding Agent |
| Done | 完成,归档 | Orchestrator |
| Blocked | 阻塞,需要干预 | Orchestrator |
| Escalated | 已升级到人类 HR | HR |
3.4 Pre-boarding Agent 工作流#
触发条件: Orchestrator 创建 onboarding 记录(D-5)
1. 读取新员工 profile.json(岗位、部门、入职日期)
2. 根据岗位匹配入职规格模板 (specs/{role}-onboarding-spec.md)
3. 生成个性化准备清单 → 写入 shared/onboarding/{id}/pre-boarding/checklist.md
4. 逐项创建任务卡片,派发给对应责任方
5. 定时检查(D-3, D-2, D-1):
a. 扫描所有任务状态
b. 标记逾期项(超过截止时间仍未 Ready)
c. 逾期项自动发送催办通知给责任方
d. D-2 仍有逾期的 → 升级到 HR
6. D-1 生成《入职准备就绪报告》:
- 全部准备项状态汇总
- 逾期/风险项标注
- 首日注意事项
→ 写入 shared/onboarding/{id}/pre-boarding/readiness-report.md
7. 交接给 Orchestrator: "准备清单执行完毕,N 项就绪,M 项风险,详见报告"plaintext3.5 交付物#
| 交付物 | 路径 | 格式 |
|---|---|---|
| 个性化准备清单 | shared/onboarding/{id}/pre-boarding/checklist.md | Markdown 表格 |
| 准备进度看板 | shared/onboarding/{id}/pre-boarding/progress.json | JSON |
| 催办记录 | shared/onboarding/{id}/pre-boarding/reminders.log | 日志 |
| 入职准备就绪报告 | shared/onboarding/{id}/pre-boarding/readiness-report.md | Markdown |
4. 模块二:首日引导流程#
4.1 设计原理#
首日的核心矛盾:信息过载与体验断裂。 新员工第一天同时面对合同签署、系统配置、团队认识、环境熟悉等大量事项,如果没有结构化引导,会陷入”不知道下一步干什么”的焦虑。
解决方案:Day-One Guide Agent 生成个性化时间轴,将首日拆解为可控的时段,每个时段有明确的目标、行动和预期产出。
4.2 首日时间轴#
┌─────────────────────────────────────────────────────────────┐
│ Day 1 Timeline │
├──────────┬──────────────────────────────────────────────────┤
│ 时间段 │ 活动内容 │
├──────────┼──────────────────────────────────────────────────┤
│ 09:00 │ 【报到迎接】 │
│ - 09:30 │ • HR/前台迎接,领取门禁卡 │
│ │ • 引导至工位,确认设备就绪 │
│ │ • 签署劳动合同(HR 主持) │
│ │ • 领取员工手册 │
├──────────┼──────────────────────────────────────────────────┤
│ 09:30 │ 【系统配置】 │
│ - 10:30 │ • 首次登录企业邮箱 │
│ │ • 配置 VPN 连接 │
│ │ • 登录内部系统(Jira/Confluence/GitLab 等) │
│ │ • 配置开发环境/工作工具 │
│ │ • Day-One Guide Agent 实时辅助 │
├──────────┼──────────────────────────────────────────────────┤
│ 10:30 │ 【公司介绍】 │
│ - 11:30 │ • 公司历史、愿景、价值观 │
│ │ • 组织架构与部门职责 │
│ │ • 规章制度要点(考勤、报销、请假) │
│ │ • 安全合规要求 │
│ │ • Knowledge Agent 推送相关文档链接 │
├──────────┼──────────────────────────────────────────────────┤
│ 11:30 │ 【团队破冰】 │
│ - 12:00 │ • 用人经理带领介绍团队成员 │
│ │ • 导师正式见面 │
│ │ • 确认首周 1-on-1 时间 │
├──────────┼──────────────────────────────────────────────────┤
│ 12:00 │ 【午餐】 │
│ - 13:30 │ • 导师/团队成员陪同午餐 │
│ │ • 非正式交流 │
├──────────┼──────────────────────────────────────────────────┤
│ 13:30 │ 【岗位认知】 │
│ - 15:00 │ • 用人经理 1-on-1:岗位职责详解 │
│ │ • 团队当前项目概览 │
│ │ • 首周期望与目标对齐 │
│ │ • Review 首周任务看板 │
├──────────┼──────────────────────────────────────────────────┤
│ 15:00 │ 【环境探索】 │
│ - 16:00 │ • 代码仓库 clone & 本地构建 │
│ │ • 文档库浏览(团队规范、技术栈文档) │
│ │ • Knowledge Agent 引导式知识库走查 │
│ │ • 标记待学习文档 │
├──────────┼──────────────────────────────────────────────────┤
│ 16:00 │ 【首日总结】 │
│ - 17:00 │ • 填写首日检查清单 │
│ │ • 提交首日反馈(Experience Surveyor Agent) │
│ │ • 确认 Day 2-5 任务安排 │
│ │ • 导师简短 check-in:今日感受、明日计划 │
└──────────┴──────────────────────────────────────────────────┘plaintext4.3 Day-One Guide Agent 工作流#
触发条件: 入职前 1 工作日 (D-1)
1. 读取新员工 profile.json + 岗位入职规格
2. 读取 Pre-boarding Agent 的就绪报告
3. 生成个性化首日时间轴:
- 根据岗位调整活动内容(工程师侧重开发环境,设计师侧重设计工具)
- 根据就绪报告标注风险项(如"VPN 未就绪,10:30 前需 IT 协助")
→ 写入 shared/onboarding/{id}/day-one/timeline.md
4. 生成首日检查清单(新员工自助勾选)
→ 写入 shared/onboarding/{id}/day-one/checklist.md
5. 推送首日引导页面到新员工终端
入职当日:
6. 实时辅助模式:
- 新员工遇到问题 → Knowledge Agent 优先响应
- 系统配置问题 → Day-One Guide Agent 提供步骤指引
- 无法解决的问题 → 升级到 IT/HR
7. 16:00 触发首日检查清单填写
8. 16:30 触发 Experience Surveyor Agent 采集首日反馈
9. 17:00 生成的首日总结报告
→ 写入 shared/onboarding/{id}/day-one/summary.md
10. 交接给 Orchestrator: "首日引导完成,N/M 项检查通过,反馈分数 X/5"plaintext4.4 交付物#
| 交付物 | 路径 | 格式 |
|---|---|---|
| 个性化首日时间轴 | shared/onboarding/{id}/day-one/timeline.md | Markdown |
| 首日检查清单 | shared/onboarding/{id}/day-one/checklist.md | Markdown |
| 首日引导页面 | 推送到新员工终端 | HTML |
| 首日总结报告 | shared/onboarding/{id}/day-one/summary.md | Markdown |
5. 模块三:首周任务看板#
5.1 设计原理#
首周的核心矛盾:“被动等待任务”与”主动探索学习”之间的张力。 新员工如果不知道这周该做什么,就会陷入无所适从;但如果任务过于细碎,又会丧失主动性。
解决方案:Task Board Agent 维护一个结构化看板,将首周任务分为”必做/建议/探索”三个优先级,新员工可以自主拖拽、标记完成,系统自动追踪进度并触发提醒。
5.2 看板列设计#
┌─────────┬──────────┬──────────┬──────────┬──────────┐
│ Backlog │ To Do │ In Prog. │ Done │ Blocked │
│ (待规划) │ (待开始) │ (进行中) │ (已完成) │ (阻塞) │
├─────────┼──────────┼──────────┼──────────┼──────────┤
│ │ ▣ Day 1 │ ▣ 配置开 │ ▣ 签署合 │ ▣ 仓库权 │
│ │ 检查清单 │ 发环境 │ 同 │ 限申请中│
│ │ │ │ │ │
│ │ ▣ 阅读 │ │ ▣ 领取 │ │
│ │ 团队规范 │ │ 设备 │ │
│ │ │ │ │ │
│ │ ▣ 首次 │ │ │ │
│ │ 1-on-1 │ │ │ │
└─────────┴──────────┴──────────┴──────────┴──────────┘plaintext5.3 任务卡片结构#
每张任务卡片包含以下字段:
{
"task_id": "WB-{employee-id}-W1-001",
"title": "配置本地开发环境",
"priority": "MUST", // MUST | SHOULD | EXPLORE
"category": "ENVIRONMENT", // ENVIRONMENT | LEARNING | SOCIAL | DELIVERABLE
"assigned_by": "Task Board Agent",
"estimated_hours": 2,
"due_day": "Day 1", // Day 1-5
"status": "TODO", // BACKLOG | TODO | IN_PROGRESS | DONE | BLOCKED
"dependencies": ["WB-{id}-W1-000"],
"checklist": [
"安装 Node.js / Python / Java(按技术栈)",
"配置 Git 全局用户名和邮箱",
"Clone 主仓库到本地",
"成功运行项目构建命令",
"运行测试套件确认通过"
],
"resources": [
{"type": "doc", "title": "开发环境配置指南", "url": "knowledge/tools/dev-setup.md"},
{"type": "person", "name": "导师", "role": "答疑"}
],
"completion_criteria": "本地能成功构建项目并运行测试",
"notes": ""
}json5.4 首周任务模板(以工程师为例)#
Day 1-2: 环境搭建#
| 优先级 | 任务 | 预计耗时 | 验收标准 |
|---|---|---|---|
| MUST | 配置本地开发环境 | 2h | 项目成功构建 |
| MUST | Clone 代码仓库并了解项目结构 | 1h | 能画出模块依赖图 |
| MUST | 首次 1-on-1 with 导师 | 0.5h | 确认首周学习计划 |
| SHOULD | 阅读团队编码规范 | 1h | 完成阅读确认 |
Day 3-4: 业务理解#
| 优先级 | 任务 | 预计耗时 | 验收标准 |
|---|---|---|---|
| MUST | 阅读核心业务文档 | 2h | 能口述业务流程 |
| MUST | 跑通本地开发环境完整流程 | 1h | 成功提交一个 hello-world PR |
| MUST | 参加团队站会/周会 | 1h | 了解团队工作节奏 |
| SHOULD | 阅读最近 3 个 Release Notes | 1h | 了解近期变更 |
| EXPLORE | 浏览团队 Confluence 空间 | 1h | 收藏 3 篇有价值文档 |
Day 5: 首周总结#
| 优先级 | 任务 | 预计耗时 | 验收标准 |
|---|---|---|---|
| MUST | 提交首周总结 | 0.5h | 填写模板 |
| MUST | 导师 1-on-1: 首周回顾 | 0.5h | 导师确认签字 |
| MUST | 填写首周满意度调研 | 0.25h | 提交完成 |
| MUST | Review 下周任务规划 | 0.5h | 确认 Week 2 计划 |
| SHOULD | 与 2 位团队非直属成员 coffee chat | 1h | 完成交流 |
5.5 Task Board Agent 工作流#
触发条件: 入职前 2 工作日 (D-2),由 Orchestrator 触发
1. 读取员工 profile + 岗位入职规格 + 用人经理提交的首周任务规划
2. 根据模板生成个性化首周任务卡片集
→ 写入 shared/onboarding/{id}/week-one/board.json
3. 生成看板视图
→ 写入 shared/onboarding/{id}/week-one/board.md
4. 推送到新员工看板界面
入职首周期间:
5. 每日 09:00 (Ops Agent 触发):
a. 扫描看板状态
b. 检查是否有任务应于今日完成但仍在 TODO
c. 发送每日提醒给新员工
6. 每日 18:00:
a. 统计当日完成情况
b. 检查是否有 BLOCKED 任务超过 4h 未解决
c. BLOCKED 任务 → 通知导师协助
7. Day 5 17:00:
a. 生成首周任务完成报告
b. 标记未完成任务,滚动到 Week 2
→ 写入 shared/onboarding/{id}/week-one/summary.md
8. 交接给 Orchestrator: "首周看板: N 项完成, M 项进行中, K 项阻塞"plaintext5.6 交付物#
| 交付物 | 路径 | 格式 |
|---|---|---|
| 首周任务看板数据 | shared/onboarding/{id}/week-one/board.json | JSON |
| 首周任务看板视图 | shared/onboarding/{id}/week-one/board.md | Markdown |
| 每日进度报告 | shared/onboarding/{id}/week-one/daily-day{N}.md | Markdown |
| 首周总结报告 | shared/onboarding/{id}/week-one/summary.md | Markdown |
6. 模块四:30-60-90 天成长路线图#
6.1 设计原理#
30-60-90 计划的核心矛盾:“统一标准”与”个性化成长”的平衡。 同岗位的新员工需要达到类似的能力基线,但每个人的起点、学习速度和兴趣方向不同。
解决方案:Growth Tracker Agent 为每位新员工生成个性化路线图,基于岗位模板 + 个人背景调整,设定明确的里程碑和评估节点,在 30/60/90 天分别触发评估。
6.2 阶段设计#
Phase 1: Day 1-30 — 学习与融入#
阶段目标: 理解业务、熟悉工具、建立关系、完成首个交付
┌─────────────────────────────────────────────────────────┐
│ 30 天里程碑: "能独立完成简单任务" │
├─────────────────────────────────────────────────────────┤
│ │
│ 维度 │ 30 天目标 │
│ ────────────┼──────────────────────────────────────── │
│ 业务理解 │ 能完整口述核心业务流程,理解团队在流程中 │
│ │ 的位置和职责 │
│ │ │
│ 技术能力 │ 熟练使用团队技术栈,能独立完成 1-2 个 │
│ │ 小型任务/bug 修复 │
│ │ │
│ 团队融入 │ 认识所有直属团队成员,参加至少 2 次团队 │
│ │ 活动,建立日常沟通节奏 │
│ │ │
│ 流程规范 │ 熟悉代码评审、发布、值班流程,完成首次 │
│ │ 代码评审参与 │
│ │ │
│ 文化认同 │ 理解公司价值观,能举例说明价值观在日常 │
│ │ 工作中的体现 │
└─────────────────────────────────────────────────────────┘plaintext30 天里程碑检查清单:
- 完成首个独立 PR 并合并
- 参与至少 1 次代码评审(作为 reviewer 或 author)
- 完成业务流程知识测试(Knowledge Agent 出题,≥ 80 分)
- 与导师完成 4 次 1-on-1(每周 1 次)
- 与用人经理完成 1 次 30 天回顾
- 提交 30 天自我评估
- 导师提交 30 天评估
Phase 2: Day 31-60 — 贡献与扩展#
阶段目标: 独立承担中等复杂度任务,开始参与团队协作
┌─────────────────────────────────────────────────────────┐
│ 60 天里程碑: "能独立承担中等任务" │
├─────────────────────────────────────────────────────────┤
│ │
│ 维度 │ 60 天目标 │
│ ────────────┼──────────────────────────────────────── │
│ 业务理解 │ 深入理解所负责模块的业务逻辑,能识别 │
│ │ 潜在风险和改进点 │
│ │ │
│ 技术能力 │ 独立完成 1 个中等复杂度需求(跨模块/ │
│ │ 涉及设计决策),参与 1 次技术方案评审 │
│ │ │
│ 团队融入 │ 主动参与团队讨论,提出至少 1 个改进建议 │
│ │ 开始与新员工分享入职经验 │
│ │ │
│ 流程规范 │ 独立完成 1 次发布流程,参与 1 次值班 │
│ │ │
│ 文化认同 │ 参与至少 1 次跨团队协作 │
└─────────────────────────────────────────────────────────┘plaintext60 天里程碑检查清单:
- 独立完成 1 个中等复杂度需求并上线
- 主导至少 1 次代码评审
- 完成 1 次独立发布
- 与导师完成 4 次 1-on-1(每两周 1 次调整为每周 1 次可选)
- 与用人经理完成 1 次 60 天回顾
- 提出 1 个团队改进建议
- 提交 60 天自我评估
- 导师提交 60 天评估
Phase 3: Day 61-90 — 独立与展望#
阶段目标: 完全独立工作,开始规划下一个成长周期
┌─────────────────────────────────────────────────────────┐
│ 90 天里程碑: "能独立工作并规划未来" │
├─────────────────────────────────────────────────────────┤
│ │
│ 维度 │ 90 天目标 │
│ ────────────┼──────────────────────────────────────── │
│ 业务理解 │ 全面理解业务全貌,能独立处理业务咨询 │
│ │ │
│ 技术能力 │ 独立完成 1 个复杂需求或主导 1 个小型 │
│ │ 技术改进项目 │
│ │ │
│ 团队融入 │ 成为团队可靠贡献者,能指导更新的员工 │
│ │ │
│ 流程规范 │ 熟练掌握所有团队流程,能独立处理突发 │
│ │ 事件 │
│ │ │
│ 文化认同 │ 主动参与文化建设,价值观践行获团队认可 │
│ │ │
│ 未来规划 │ 与经理共同制定下季度个人发展计划 (IDP) │
└─────────────────────────────────────────────────────────┘plaintext90 天里程碑检查清单:
- 独立完成 1 个复杂需求或主导 1 个改进项目
- 完成 90 天转正评估(自评 + 导师评 + 经理评)
- 与用人经理共同制定 IDP(个人发展计划)
- 完成最终满意度调研
- 导师关系正式过渡到日常 mentorship 模式
- 知识库贡献至少 1 篇文档(沉淀入职期间学到的知识)
6.3 Growth Tracker Agent 工作流#
触发条件: 入职当日 (Day 1),由 Orchestrator 触发
1. 读取员工 profile + 岗位规格 + 用人经理输入
2. 生成个性化 30-60-90 路线图:
- 根据员工经验级别调整目标难度
- 根据团队当前项目调整具体任务
- 标注每个里程碑的评估方式和评估人
→ 写入 shared/onboarding/{id}/growth/roadmap.md
持续运行:
3. 每周 (Ops Agent 触发):
a. 检查里程碑进度
b. 标记临近截止但未完成的里程碑
c. 发送进度提醒给新员工和导师
4. Day 30 触发 30 天评估:
a. 生成评估问卷(自评 + 导师评 + 经理评)
b. 收集评估结果
c. 对比里程碑目标,生成差距分析
d. 如差距显著 → 触发调整建议(延长 ramp-up、调整任务难度等)
e. 生成 30 天评估报告
→ 写入 shared/onboarding/{id}/growth/day30-review.md
5. Day 60 触发 60 天评估 (流程同上)
6. Day 90 触发 90 天转正评估:
a. 汇总 30/60/90 三次评估数据
b. 生成入职全周期成长报告
c. 触发 IDP 制定流程
d. 生成知识库贡献提醒
→ 写入 shared/onboarding/{id}/growth/day90-final-review.md
e. 交接给 Orchestrator: "入职周期完成,转正评估: 通过/需延长"plaintext6.4 评估维度与评分#
每个阶段评估采用 5 维度评分(1-5 分):
| 维度 | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| 业务理解 | 仅了解表面 | 理解核心流程 | 深入理解,能识别风险 |
| 技术能力 | 需大量指导 | 能独立完成中等任务 | 能独立解决复杂问题 |
| 团队协作 | 被动参与 | 主动协作 | 主动推动,帮助他人 |
| 流程规范 | 需要提醒 | 基本遵守 | 熟练掌握,能优化 |
| 文化认同 | 不了解 | 理解价值观 | 主动践行,影响他人 |
评估决策矩阵:
| 30 天平均分 | 决策 |
|---|---|
| ≥ 4.0 | 按计划进入 Phase 2 |
| 3.0 - 3.9 | 按计划进入 Phase 2,但增加 1-on-1 频率 |
| < 3.0 | 触发预警,用人经理 + HR 讨论:调整计划/延长 ramp-up/导师加强辅导 |
6.5 交付物#
| 交付物 | 路径 | 格式 |
|---|---|---|
| 个性化成长路线图 | shared/onboarding/{id}/growth/roadmap.md | Markdown |
| 30 天评估报告 | shared/onboarding/{id}/growth/day30-review.md | Markdown |
| 60 天评估报告 | shared/onboarding/{id}/growth/day60-review.md | Markdown |
| 90 天转正评估报告 | shared/onboarding/{id}/growth/day90-final-review.md | Markdown |
| IDP (个人发展计划) | shared/onboarding/{id}/growth/idp.md | Markdown |
7. 模块五:智能问答助手#
7.1 设计原理#
问答助手的核心矛盾:新员工问题的高频性、重复性与知识库的分散性。 新员工每天可能问 10-20 个问题,从”Wi-Fi 密码是多少”到”这个 API 的认证机制是什么”,如果每次都要找人问,既消耗团队时间,又让新员工感到不好意思问。
解决方案:Knowledge Agent 作为 7×24 在线问答助手,基于公司知识库提供即时回答,无法回答的问题自动升级到导师/团队,并将答案沉淀回知识库。
7.2 知识库架构#
shared/knowledge/
├── policies/ # 规章制度
│ ├── attendance.md # 考勤制度
│ ├── reimbursement.md # 报销流程
│ ├── leave.md # 请假流程
│ ├── security.md # 安全合规
│ └── remote-work.md # 远程办公
├── tools/ # 工具使用指南
│ ├── dev-environment.md # 开发环境配置
│ ├── git-workflow.md # Git 工作流
│ ├── ci-cd.md # CI/CD 流程
│ ├── vpn-setup.md # VPN 配置
│ └── communication.md # 沟通工具(IM/邮件/会议)
├── culture/ # 文化价值观
│ ├── values.md # 核心价值观
│ ├── stories.md # 文化故事
│ └── norms.md # 团队约定
├── faq/ # 高频问题(自动积累)
│ ├── day1-faq.md # 首日高频问题
│ ├── week1-faq.md # 首周高频问题
│ └── general-faq.md # 通用高频问题
├── onboarding/ # 入职专属知识
│ ├── glossary.md # 公司术语表
│ ├── org-chart.md # 组织架构
│ └── team-intro/ # 各团队介绍
└── index.json # 知识库索引(向量检索)plaintext7.3 问答流程#
新员工提问
│
▼
┌─────────────┐
│ 意图识别 │ ← Knowledge Agent
│ │
│ 分类: │
│ A. 事实型 │ → "Wi-Fi 密码是什么"
│ B. 流程型 │ → "怎么申请报销"
│ C. 技术型 │ → "这个 API 怎么调用"
│ D. 人际型 │ → "谁负责 XXX 模块"
│ E. 文化型 │ → "公司的晋升机制是什么"
└──────┬──────┘
│
▼
┌─────────────┐ 置信度 ≥ 0.85 ┌──────────────┐
│ 知识库检索 │ ──────────────────→ │ 直接回答 │
│ (向量+关键词)│ │ + 附带来源链接 │
└──────┬──────┘ └──────────────┘
│ 置信度 < 0.85
▼
┌─────────────┐ 找到相关文档 ┌──────────────┐
│ 文档推荐 │ ──────────────────→ │ 推荐文档 │
│ │ │ "你可能需要 │
│ │ │ 查看这篇" │
└──────┬──────┘ └──────────────┘
│ 未找到相关文档
▼
┌─────────────┐ 能识别应答人 ┌──────────────┐
│ 路由到人 │ ──────────────────→ │ 转发给导师/ │
│ │ │ 相关负责人 │
│ │ │ + 记录问题 │
└──────┬──────┘ └──────────────┘
│ 无法识别应答人
▼
┌─────────────┐
│ 升级到 Orchestrator │
│ → 转发给用人经理 │
│ → 记录为新知识缺口 │
│ → 答案获得后沉淀到 FAQ │
└───────────────────────────────────┘plaintext7.4 问答记录与知识沉淀#
每次问答都被记录,用于持续优化知识库:
{
"qa_id": "QA-{employee-id}-0001",
"timestamp": "2026-08-14T10:23:00+08:00",
"employee_id": "{employee-id}",
"question": "VPN 连接不上怎么办?",
"intent": "PROCESS",
"confidence": 0.72,
"resolution_path": "DOC_RECOMMEND",
"answer_source": "knowledge/tools/vpn-setup.md",
"resolved": true,
"resolution_time_seconds": 15,
"followup_needed": false,
"knowledge_gap": false
}json知识沉淀规则:
- 同一问题被 3+ 人提问 → 自动进入 FAQ 候选队列
- 置信度 < 0.5 的问答 → 标记为知识缺口,通知知识库管理员
- 升级到人的问答 → 答案获取后,Knowledge Agent 自动生成 FAQ 条目
7.5 Knowledge Agent 工作流#
触发条件: 持续运行(7×24 在线)
初始化:
1. 加载知识库索引 (shared/knowledge/index.json)
2. 向量化所有知识文档
3. 建立意图分类模型
运行时:
4. 接收新员工提问
5. 意图分类 + 知识库检索
6. 按置信度选择回答路径(直接回答/文档推荐/路由到人/升级)
7. 记录问答日志
8. 每日 (Ops Agent 触发):
a. 分析高频问题
b. 识别知识缺口
c. 生成 FAQ 候选
d. 更新知识库索引
→ 写入 shared/knowledge/faq/auto-generated-{date}.md
交接规则:
- 无法解决的问题 → 升级到 Orchestrator,附带问题原文和检索记录
- 识别到新员工情绪负面(如"好难""想放弃")→ 立即通知导师plaintext7.6 交付物#
| 交付物 | 路径 | 格式 |
|---|---|---|
| 问答日志 | shared/onboarding/{id}/qa-log/{date}.json | JSON |
| 高频问题分析 | shared/knowledge/faq/auto-generated-{date}.md | Markdown |
| 知识缺口报告 | shared/knowledge/gaps-{date}.md | Markdown |
| 知识库索引 | shared/knowledge/index.json | JSON |
8. 模块六:导师匹配与 1-on-1 安排#
8.1 设计原理#
导师匹配的核心矛盾:“最优技术匹配”与”人际化学反应”不可兼得。 纯算法匹配可能找到技术最相关的导师,但性格不合反而有害;纯人工分配则依赖经理主观判断,缺乏数据支撑。
解决方案:Mentor Match Agent 采用算法推荐 + 经理确认的双层模式——算法基于多维度生成 Top-3 候选,用人经理做最终决策。同时自动安排 1-on-1 日程,确保沟通节奏落地。
8.2 导师画像维度#
导师匹配基于以下维度计算相似度:
| 维度 | 权重 | 数据来源 | 匹配逻辑 |
|---|---|---|---|
| 技术栈 | 30% | 员工技能标签 | 技术栈重叠率 |
| 岗位路径 | 20% | 岗位序列 | 同岗位序列优先 |
| 性格互补 | 15% | 性格测评结果 | 互补型匹配(如内向新员工配外向导师) |
| 时区/办公地 | 15% | 办公位置 | 同地点优先,同楼层加分 |
| 工作负载 | 10% | 当前带人数量 | 当前带人 ≤ 2 优先 |
| 入职时间 | 5% | 司龄 | 司龄 1-3 年优先(既有经验又不过于资深) |
| 兴趣重合 | 5% | 兴趣标签 | 非工作话题有交集加分 |
8.3 匹配算法#
def match_mentor(new_hire, mentor_pool):
"""
计算新员工与候选导师池的匹配分数,返回 Top-3
"""
scores = []
for mentor in mentor_pool:
# 排除条件
if mentor.current_mentee_count >= 3:
continue
if mentor.department == new_hire.direct_department:
# 同部门导师降权(避免直接上级兼任导师)
dept_penalty = 0.8
else:
dept_penalty = 1.0
# 各维度分数 (0-1)
tech_score = jaccard_similarity(new_hire.tech_stack, mentor.tech_stack)
role_score = 1.0 if new_hire.role_family == mentor.role_family else 0.3
personality_score = personality_complement(new_hire.personality, mentor.personality)
location_score = 1.0 if new_hire.location == mentor.location else 0.5
workload_score = 1.0 - (mentor.current_mentee_count / 3)
tenure_score = tenure_weight(mentor.tenure_years) # 1-3年最优
interest_score = jaccard_similarity(new_hire.interests, mentor.interests)
# 加权总分
total = (
tech_score * 0.30 +
role_score * 0.20 +
personality_score * 0.15 +
location_score * 0.15 +
workload_score * 0.10 +
tenure_score * 0.05 +
interest_score * 0.05
) * dept_penalty
scores.append({
"mentor": mentor,
"total_score": total,
"breakdown": {
"tech": tech_score,
"role": role_score,
"personality": personality_score,
"location": location_score,
"workload": workload_score,
"tenure": tenure_score,
"interest": interest_score
}
})
# 返回 Top-3
scores.sort(key=lambda x: x["total_score"], reverse=True)
return scores[:3]python8.4 匹配流程#
触发条件: 入职前 3 工作日 (D-3)
1. Mentor Match Agent 读取新员工 profile
2. 从导师池中筛选可用导师
3. 运行匹配算法,生成 Top-3 候选
4. 生成匹配报告(含各维度得分和推荐理由)
→ 写入 shared/onboarding/{id}/mentor/match-report.md
5. 发送给用人经理确认:
- 展示 Top-3 候选及匹配理由
- 经理选择 1 人或提出其他人选
6. 经理确认后:
a. 向导师发送邀请(含新员工信息、匹配理由、导师职责说明)
b. 导师确认接受
c. 向新员工发送导师介绍
d. 记录匹配结果
→ 写入 shared/onboarding/{id}/mentor/assignment.md
7. 自动安排 1-on-1 日程 (见 8.5)plaintext8.5 1-on-1 排程逻辑#
排程频率#
| 入职阶段 | 频率 | 时长 | 形式 |
|---|---|---|---|
| Week 1 (Day 1-5) | 每日 15min | 15 分钟 | 面对面/视频 |
| Week 2-4 (Day 6-30) | 每周 1 次 | 30 分钟 | 面对面/视频 |
| Day 31-60 | 每两周 1 次 | 45 分钟 | 面对面/视频 |
| Day 61-90 | 每两周 1 次 | 45 分钟 | 面对面/视频 |
| Day 90+ | 每月 1 次 | 45 分钟 | 转入日常 mentorship |
1-on-1 模板#
每次 1-on-1 前自动推送给导师的模板:
# 1-on-1 记录: {新员工姓名} × {导师姓名}
**日期**: {date}
**阶段**: {Week 1 / Day 30 / Day 60...}
**时长**: {minutes}
## 导师检查清单(会前预览)
- [ ] 查看新员工本周任务看板完成情况
- [ ] 查看新员工问答记录(是否有反复追问的领域)
- [ ] 查看新员工满意度调研趋势
- [ ] 准备 1 个具体反馈(正面或改进)
## 建议议程
### 1. 开场 (3min)
- 最近感觉怎么样?(开放性问题,让新员工先说)
### 2. 进度回顾 (10min)
- 本周完成了哪些任务?有什么收获?
- 遇到了什么困难?需要什么帮助?
### 3. 反馈与指导 (10min)
- 导师观察反馈(基于本周看板、问答、评估数据)
- 新员工对导师/团队/流程的反馈
### 4. 下一步规划 (5min)
- 下周重点任务确认
- 需要提前准备什么?
### 5. 开放话题 (2min)
- 有没有其他想聊的?(不限工作)
## 记录
### 关键讨论点
-
### 行动项
| 行动项 | 负责人 | 截止日期 |
|--------|--------|----------|
| | | |
### 风险信号(如有)
-
### 下次 1-on-1 时间
{next_date}markdown排程自动化#
Mentor Match Agent 排程逻辑:
1. 读取导师和新员工的日历
2. 查找双方都可用的时间段:
- Week 1: 每日 16:00-16:15 优先(避开站会和午休)
- Week 2+: 每周/每两周固定时段
3. 创建日历邀请(含 1-on-1 模板链接)
4. 会前 1 小时推送提醒给导师(含检查清单)
5. 会前 15 分钟推送提醒给新员工
6. 会后自动推送记录模板
7. 记录完成后归档:
→ shared/onboarding/{id}/mentor/1on1/{date}.md
异常处理:
- 导师请假 → 自动重新安排或寻找临时替代
- 连续 2 次取消 → 通知 Orchestrator,考虑更换导师
- 1-on-1 记录连续 2 次未提交 → 提醒导师plaintext8.6 交付物#
| 交付物 | 路径 | 格式 |
|---|---|---|
| 导师匹配报告 | shared/onboarding/{id}/mentor/match-report.md | Markdown |
| 导师分配确认 | shared/onboarding/{id}/mentor/assignment.md | Markdown |
| 1-on-1 排程表 | shared/onboarding/{id}/mentor/schedule.json | JSON |
| 1-on-1 记录 | shared/onboarding/{id}/mentor/1on1/{date}.md | Markdown |
| 导师评估汇总 | shared/onboarding/{id}/mentor/mentor-evaluation.md | Markdown |
9. 模块七:入职体验满意度追踪#
9.1 设计原理#
满意度追踪的核心矛盾:“事后问卷”太晚,“实时监控”太重。 传统的离职面谈或转正问卷只能事后发现问题,而频繁的调研会让新员工感到被打扰。
解决方案:Experience Surveyor Agent 采用脉冲式调研 (Pulse Survey) ——在关键节点投放极短的微调研(1-3 题),结合被动信号(问答情绪、任务完成速度、1-on-1 记录关键词)构建实时体验画像。
9.2 调研触点设计#
入职时间线:
Day 1 ──── Day 3 ──── Day 7 ──── Day 14 ──── Day 30 ──── Day 60 ──── Day 90
│ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼
首日 首日 首周 两周 30天 60天 90天
即时 回顾 回顾 脉冲 评估 评估 总评
(1题) (2题) (3题) (1题) (5题) (5题) (8题)plaintext调研内容#
| 触点 | 时机 | 题目 | 类型 |
|---|---|---|---|
| T1: 首日即时 | Day 1, 16:30 | “今天的第一天体验如何?” (1-5 分) | NPS 式 |
| T2: 首日回顾 | Day 1, 21:00 | ①”今天有什么超出预期的?” ②”今天有什么低于预期的?” | 开放式 |
| T3: 首周回顾 | Day 5, 17:00 | ①”首周整体体验” (1-5 分) ②”你觉得自己准备好开始独立工作了吗?” (1-5 分) ③”有什么想说的?” | 混合 |
| T4: 两周脉冲 | Day 14 | “过去一周,你在工作中遇到的最大阻碍是什么?” | 开放式 |
| T5: 30天评估 | Day 30 | ①工作内容匹配度 ②导师支持满意度 ③团队融入度 ④工具/流程满意度 ⑤开放反馈 | 5 维度 + 开放 |
| T6: 60天评估 | Day 60 | 同 T5 + “你对当前的工作节奏满意吗?” | 6 维度 + 开放 |
| T7: 90天总评 | Day 90 | ①整体入职体验 ②推荐意愿 (NPS) ③各模块满意度 ④最有价值的环节 ⑤最需改进的环节 ⑥导师评价 ⑦对后续新员工的建议 ⑧开放反馈 | 综合 |
9.3 被动信号采集#
除主动调研外,系统持续采集被动信号,构建实时体验画像:
| 信号源 | 采集方式 | 指标 | 预警阈值 |
|---|---|---|---|
| 问答记录 | Knowledge Agent 日志 | 日均提问数、提问情绪倾向 | 日均 < 1 题(可能不敢问)或情绪负面率 > 20% |
| 任务看板 | Task Board Agent 数据 | 任务完成速度、BLOCKED 时长 | BLOCKED 超过 24h 未解决 |
| 1-on-1 记录 | 导师记录文本分析 | 情绪关键词、风险信号词 | 出现”困难""迷茫""跟不上”等词 |
| 系统活跃度 | 登录日志、代码提交 | 日均活跃时长、首次提交时间 | 连续 2 天无系统活动 |
| 考勤 | 门禁/打卡数据 | 迟到/早退频率 | 非常规考勤模式 |
9.4 体验画像模型#
体验画像 = f(主动调研分数, 被动信号指标, 时间衰减加权)
实时体验分数计算:
ExperienceScore = w1 * SurveyScore + w2 * SignalScore
其中:
SurveyScore = 最近一次调研的标准化分数 (0-100)
SignalScore = 被动信号的加权汇总:
- 问答活跃度: 25% (正常提问 = 高分)
- 任务完成率: 25%
- 1-on-1 情绪: 25%
- 系统活跃度: 25%
权重:
w1 = 0.6 (主动调研更可靠)
w2 = 0.4 (被动信号补充)plaintext9.5 预警机制#
┌─────────────────────────────────────────────────────────┐
│ 预警等级 │
├──────────┬──────────────────────────────────────────────┤
│ 等级 │ 触发条件 │ 响应动作 │
├──────────┼──────────────────────────────────────────────┤
│ 🟢 绿色 │ ExperienceScore ≥ 75 │ 正常,无需干预 │
│ │ 无负面信号 │ │
├──────────┼──────────────────────────────────────────────┤
│ 🟡 黄色 │ 60 ≤ Score < 75 │ 通知导师加强关注 │
│ │ 或出现 1 个负面信号 │ 增加一次 1-on-1 │
├──────────┼──────────────────────────────────────────────┤
│ 🟠 橙色 │ 45 ≤ Score < 60 │ 通知用人经理 │
│ │ 或出现 2 个负面信号 │ 经理安排 1-on-1 │
│ │ 或调研分数骤降 > 20% │ Experience │
│ │ │ Surveyor 深入调研 │
├──────────┼──────────────────────────────────────────────┤
│ 🔴 红色 │ Score < 45 │ 立即通知 HR + │
│ │ 或连续 2 次调研 < 3 分 │ 用人经理 │
│ │ 或出现"想离开"类信号 │ HR 介入面谈 │
│ │ │ 制定干预计划 │
└──────────┴──────────────────────────────────────────────┘plaintext9.6 Experience Surveyor Agent 工作流#
触发条件: 持续运行 + 关键节点触发
调研管理:
1. 在 T1-T7 触发点自动推送调研问卷
2. 24h 未填写 → Ops Agent 发送提醒
3. 48h 未填写 → 通知导师提醒
4. 收集调研结果 → 写入 shared/onboarding/{id}/surveys/
被动信号采集:
5. 每日 (Ops Agent 触发):
a. 从 Knowledge Agent 拉取问答日志
b. 从 Task Board Agent 拉取任务状态
c. 从 1-on-1 记录中分析情绪
d. 从系统日志拉取活跃度数据
e. 计算当日 ExperienceScore
→ 写入 shared/onboarding/{id}/surveys/daily-score.json
预警处理:
6. 计算预警等级
7. 🟡 → 通知导师
8. 🟠 → 通知用人经理 + 触发深入调研
9. 🔴 → 通知 HR + 用人经理,生成《风险预警报告》
→ 写入 shared/onboarding/{id}/surveys/alert-{date}.md
周期报告:
10. Day 30/60/90 生成阶段体验报告:
- 体验分数趋势图
- 调研结果汇总
- 被动信号分析
- 预警历史
- 改进建议
→ 写入 shared/onboarding/{id}/surveys/phase-{N}-report.md
11. Day 90 生成全周期体验报告:
- 跨阶段趋势对比
- 各模块满意度排名
- NPS 分数
- 高频改进建议汇总
→ 写入 shared/onboarding/{id}/surveys/final-report.md
→ 同时写入 shared/reviews/(供 Orchestrator 汇总到仪表盘)plaintext9.7 交付物#
| 交付物 | 路径 | 格式 |
|---|---|---|
| 各触点调研结果 | shared/onboarding/{id}/surveys/touchpoint-{N}.json | JSON |
| 每日体验分数 | shared/onboarding/{id}/surveys/daily-score.json | JSON |
| 风险预警报告 | shared/onboarding/{id}/surveys/alert-{date}.md | Markdown |
| 阶段体验报告 | shared/onboarding/{id}/surveys/phase-{N}-report.md | Markdown |
| 全周期体验报告 | shared/onboarding/{id}/surveys/final-report.md | Markdown |
10. 任务生命周期管理#
10.1 全局任务状态机#
系统中所有任务(准备项、首日活动、看板任务、里程碑、1-on-1、调研)统一遵循以下状态机:
┌──────────┐
│ Inbox │ ← 新任务创建
└────┬─────┘
│ Orchestrator 分配
▼
┌──────────┐
│ Assigned │ ← 已分配 Agent
└────┬─────┘
│ Agent 开始执行
▼
┌──────────┐
┌────────→│ In Prog. │←───────┐
│ └────┬─────┘ │
│ │ Agent 完成 │ Reviewer 退回
│ ▼ │
│ ┌──────────┐ │
│ │ Review │────────┘
│ └────┬─────┘
│ │ Reviewer 通过
│ ▼
│ ┌──────────┐
│ │ Done │
│ └──────────┘
│
│ 阻塞
▼
┌──────────┐ ┌──────────┐
│ Blocked │────────→│ Escalated│
└──────────┘ 升级 └──────────┘
│ 解决
▼
┌──────────┐
│ In Prog. │
└──────────┘
任何状态 ──→ Failed (放弃,附带原因)plaintext10.2 状态转换规则#
| 当前状态 | 目标状态 | 执行者 | 条件 |
|---|---|---|---|
| Inbox | Assigned | Orchestrator | 选择合适的 Agent |
| Assigned | In Progress | Orchestrator | Spawn Agent 或发送任务 |
| In Progress | Review | Agent | 完成工作,提交交付物 |
| Review | Done | Orchestrator | Reviewer 批准 |
| Review | In Progress | Reviewer | 退回,附反馈 |
| In Progress | Blocked | Agent | 遇到无法解决的阻塞 |
| Blocked | Escalated | Orchestrator | 超时或需要人类干预 |
| Escalated | In Progress | Orchestrator | 阻塞解决 |
| Any | Failed | Orchestrator | 放弃,附文档化原因 |
10.3 任务评论规范#
每次状态变更必须附带评论,格式:
[Agent名] [动作]: [详情]plaintext示例:
[Pre-boarding] Starting: 开始处理员工 EMP-001 的入职准备清单。读取岗位规格: engineer-onboarding-spec.md。共 13 项准备任务。
[Pre-boarding] Blocked: IT 部门未响应 VPN 账号开通请求,已等待 48h。需要 HR 协助催办。任务: VPN-001。
[Pre-boarding] Handoff: 准备清单执行完毕。13 项中 12 项 Done,1 项 Escalated (VPN 账号)。就绪报告: shared/onboarding/EMP-001/pre-boarding/readiness-report.md。已知风险: VPN 可能影响首日开发环境配置。下一步: Orchestrator 确认是否需要 IT 紧急处理。
[Experience Surveyor] Alert: 员工 EMP-003 体验分数降至 42 (红色预警)。触发条件: 连续 2 次调研 < 3 分 + 1-on-1 记录出现"跟不上"关键词。已通知 HR 和用人经理。报告: shared/onboarding/EMP-003/surveys/alert-2026-08-14.mdplaintext10.4 多步骤任务拆分#
复杂任务自动拆分为子任务,保持父子关系:
Task #ONB-2026-08-EMP001: 员工 EMP-001 入职全流程
├── #PRE-001: 入职前准备清单 (Assigned: Pre-boarding Agent)
│ ├── #PRE-001a: 开通 IT 账号 (Assigned: IT 部门)
│ ├── #PRE-001b: 准备设备 (Assigned: IT + 行政)
│ └── #PRE-001c: 生成就绪报告 (Assigned: Pre-boarding Agent)
├── #DAY1-001: 首日引导 (Assigned: Day-One Guide Agent)
├── #WK1-001: 首周任务看板 (Assigned: Task Board Agent)
├── #GRW-001: 30-60-90 成长路线图 (Assigned: Growth Tracker Agent)
│ ├── #GRW-001a: Day 30 评估
│ ├── #GRW-001b: Day 60 评估
│ └── #GRW-001c: Day 90 转正评估
├── #MEN-001: 导师匹配与 1-on-1 (Assigned: Mentor Match Agent)
└── #EXP-001: 满意度追踪 (Assigned: Experience Surveyor Agent)plaintextOrchestrator 跟踪父任务,所有子任务完成后才标记父任务 Done。
11. 运维与监控#
11.1 Ops Agent 定时任务#
| 任务 | 频率 | 时间 | 动作 |
|---|---|---|---|
| 每日巡检 | 每日 | 08:30 | 扫描所有活跃 onboarding 记录,检查逾期任务、stale 任务、阻塞任务 |
| 每日报告 | 每日 | 09:00 | 向 Orchestrator 提交《入职每日简报》 |
| 任务提醒 | 每日 | 09:00, 14:00 | 向新员工推送当日待办任务 |
| 进度检查 | 每日 | 18:00 | 统计当日任务完成情况,检查 BLOCKED 任务 |
| 体验监控 | 每日 | 20:00 | 计算 ExperienceScore,检查预警等级 |
| 催办推送 | 按需 | 截止前 24h/4h | 向责任方推送催办通知 |
| 健康检查 | 每周 | 周一 08:00 | 检查知识库索引完整性、Agent 可用性、共享目录可写性 |
| 周报生成 | 每周 | 周五 17:00 | 生成本周入职汇总报告 |
| 月报生成 | 每月 | 月末 | 生成月度入职分析报告 |
| 数据清理 | 每月 | 月末 | 归档 90 天前完成的 onboarding 记录 |
11.2 每日简报模板#
# 入职每日简报 — {date}
## 今日活跃入职
| 员工 | 阶段 | 体验分 | 预警 | 阻塞任务 |
|------|------|--------|------|----------|
| 张三 | Day 3 | 82 🟢 | 无 | 0 |
| 李四 | Day 15 | 58 🟡 | 导师已通知 | 1 (权限申请) |
| 王五 | Day 45 | 41 🔴 | HR 已通知 | 2 |
## 今日待办
- [ ] EMP-001: 首日引导(Day-One Guide Agent)
- [ ] EMP-002: 30 天评估触发(Growth Tracker Agent)
- [ ] EMP-003: HR 介入面谈跟进
## 逾期任务
| 任务 | 员工 | 逾期天数 | 责任方 | 状态 |
|------|------|----------|--------|------|
| VPN 开通 | EMP-001 | 2 | IT | Escalated |
## Stale 任务(24h+ 无更新)
- 无
## 本周入职预告
- 08/16: 赵六 (前端工程师)
- 08/18: 钱七 (产品经理)markdown11.3 仪表盘#
Orchestrator 维护实时仪表盘,向 HR 和管理层展示:
┌─────────────────────────────────────────────────────────┐
│ 入职引导仪表盘 │
├──────────────────────┬──────────────────────────────────┤
│ 在入职人数 │ 12 │
│ 本月新入职 │ 8 │
│ 本月即将入职 │ 5 │
│ 平均体验分 │ 76 🟢 │
│ 红色预警人数 │ 1 🔴 │
│ 90 天转正率 │ 94% │
│ 平均 ramp-up 天数 │ 28 天 │
├──────────────────────┴──────────────────────────────────┤
│ 各阶段体验分数趋势 │
│ │
│ 90 ┤ ●─────●─────● │
│ 80 ┤ ●─┘ ● │
│ 70 ┤● ● │
│ 60 ┤ ●● │
│ 50 ┤ │
│ └──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──→ │
│ D1 D3 D7 D14 D30 D60 D90 │
├─────────────────────────────────────────────────────────┤
│ 模块满意度排名 (90 天数据) │
│ 1. 智能问答助手 4.6/5 │
│ 2. 入职前准备 4.3/5 │
│ 3. 首日引导 4.2/5 │
│ 4. 导师匹配 4.0/5 │
│ 5. 首周任务看板 3.8/5 │
│ 6. 成长路线图 3.7/5 │
│ 7. 满意度追踪 3.5/5 │
├─────────────────────────────────────────────────────────┤
│ 高频改进建议 (Top 5) │
│ 1. "VPN 配置太复杂,希望有视频教程" (8 票) │
│ 2. "导师太忙,1-on-1 经常被取消" (6 票) │
│ 3. "希望首周有更多和团队非正式交流的机会" (5 票) │
│ 4. "30 天评估可以更早一些" (4 票) │
│ 5. "知识库部分内容已过时" (3 票) │
└─────────────────────────────────────────────────────────┘plaintext12. 数据模型#
12.1 核心实体#
Employee (新员工)
├── id: string (EMP-YYYY-MM-NNN)
├── name: string
├── email: string
├── department: string
├── role: string (engineer | designer | pm | ...)
├── level: string (junior | mid | senior)
├── start_date: date
├── manager_id: string
├── mentor_id: string (nullable)
├── profile: json (技能标签、性格测评、兴趣)
├── status: enum (PRE_BOARDING | ONBOARDING | PROBATION | CONFIRMED)
└── created_at: datetime
OnboardingRecord (入职记录)
├── id: string (ONB-YYYY-MM-NNN)
├── employee_id: string
├── current_phase: enum (PRE | DAY1 | WEEK1 | DAY30 | DAY60 | DAY90 | DONE)
├── experience_score: float (0-100)
├── alert_level: enum (GREEN | YELLOW | ORANGE | RED)
├── tasks: Task[]
├── surveys: Survey[]
├── qa_logs: QALog[]
└── created_at: datetime
Task (任务)
├── id: string
├── onboarding_id: string
├── parent_id: string (nullable)
├── title: string
├── category: enum (PRE_BOARDING | DAY1 | WEEK1 | GROWTH | MENTOR | SURVEY)
├── status: enum (INBOX | ASSIGNED | IN_PROGRESS | REVIEW | DONE | BLOCKED | ESCALATED | FAILED)
├── assigned_agent: string
├── assigned_human: string (nullable)
├── priority: enum (MUST | SHOULD | EXPLORE)
├── due_date: datetime
├── completed_at: datetime (nullable)
├── comments: Comment[]
└── artifacts: string[] (文件路径列表)
MentorAssignment (导师分配)
├── id: string
├── employee_id: string
├── mentor_id: string
├── match_score: float
├── match_breakdown: json
├── confirmed_by: string (manager)
├── confirmed_at: datetime
└── schedule: 1on1Schedule[]
Survey (调研)
├── id: string
├── employee_id: string
├── touchpoint: enum (T1-T7)
├── triggered_at: datetime
├── submitted_at: datetime (nullable)
├── questions: SurveyQuestion[]
└── score: float (nullable)plaintext12.2 数据存储#
| 数据类型 | 存储方式 | 位置 |
|---|---|---|
| 结构化数据(任务状态、分数、匹配结果) | JSON 文件 | shared/onboarding/{id}/ |
| 文档型数据(报告、评估、记录) | Markdown 文件 | shared/onboarding/{id}/ |
| 知识库 | Markdown + 向量索引 | shared/knowledge/ |
| 仪表盘聚合数据 | JSON | shared/dashboard/ |
| 决策日志 | Markdown | shared/decisions/ |
13. 实施路线图#
13.1 分阶段实施#
Phase 0: 基础设施 (Week 1-2)
├── 搭建 shared/ 目录结构
├── 编写岗位入职规格模板(先做工程师岗位)
├── 初始化知识库(从现有文档迁移)
├── 部署 Orchestrator + Ops Agent
└── 验证: 创建测试 onboarding 记录,确认目录结构正确
Phase 1: 核心流程 (Week 3-5)
├── 部署 Pre-boarding Agent
├── 部署 Day-One Guide Agent
├── 部署 Task Board Agent
├── 部署 Knowledge Agent(基础问答)
├── 端到端测试: 模拟 1 位新员工完整首周流程
└── 验证: 首日检查清单 100% 可执行
Phase 2: 成长与匹配 (Week 6-8)
├── 部署 Growth Tracker Agent
├── 部署 Mentor Match Agent
├── 建立导师池(从现有员工中招募和画像)
├── 1-on-1 排程集成日历系统
└── 验证: 导师匹配 Top-3 合理性经经理确认
Phase 3: 体验监控 (Week 9-10)
├── 部署 Experience Surveyor Agent
├── 部署被动信号采集管道
├── 配置预警规则和通知通道
├── 仪表盘上线
└── 验证: 模拟预警场景,确认通知链路正常
Phase 4: 试点运行 (Week 11-14)
├── 选择 3-5 位真实新员工试点
├── 全流程运行,收集反馈
├── 每周 Review: 体验分数、Agent 表现、流程卡点
├── 迭代优化
└── 验证: 试点新员工 30 天体验分数 ≥ 75
Phase 5: 全面上线 (Week 15+)
├── 所有新员工纳入系统
├── 扩展岗位模板(设计师、产品经理、运营等)
├── 建立持续优化机制(月度复盘)
└── 长期目标: 90 天转正率 ≥ 95%,平均体验分 ≥ 80plaintext13.2 风险与缓解#
| 风险 | 概率 | 影响 | 缓解措施 |
|---|---|---|---|
| 知识库内容过时/不完整 | 高 | 高 | Knowledge Agent 自动识别知识缺口,建立知识库维护 SLA |
| 导师池不足 | 中 | 高 | 提前招募导师,设定每导师最多带 2 人的上限 |
| Agent 响应延迟 | 中 | 中 | Ops Agent 健康检查,超时自动重启或升级 |
| 新员工对 AI 引导抵触 | 低 | 中 | 保持人类导师和经理的关键介入点,AI 是辅助而非替代 |
| 隐私顾虑(被动信号采集) | 中 | 高 | 明确告知采集范围,仅采集工作相关信号,数据仅 HR 可见 |
| 跨部门协作不畅 | 高 | 高 | Orchestrator 升级机制 + HR 作为最终协调人 |
13.3 成功度量#
| 指标 | 基线 | 3 个月目标 | 6 个月目标 |
|---|---|---|---|
| 90 天转正率 | 85% | 92% | 95% |
| 平均 ramp-up 天数 | 45 天 | 35 天 | 28 天 |
| 首周任务完成率 | 70% | 85% | 90% |
| 30 天体验分数 | 68 | 75 | 80 |
| 90 天 NPS | 30 | 45 | 55 |
| HR 人工介入时长/人 | 8h | 4h | 2h |
| 知识库 FAQ 自助解决率 | 30% | 60% | 75% |
附录 A: Agent SOUL.md 模板汇总#
Pre-boarding Agent#
# SOUL.md — Pre-boarding Agent
我是入职前准备专员。我的职责是确保每位新员工在报到前一切就绪。
## 职责范围
- 根据岗位规格生成个性化准备清单
- 逐项派发任务给 IT/行政/HR/用人经理
- 定时检查进度,标记逾期,自动催办
- 生成《入职准备就绪报告》
## 决策边界
- 清单内容基于岗位规格模板,不自行添加或删除项目
- 逾期项先催办,D-2 仍逾期才升级到 HR
- 设备/账号的具体配置由 IT 决定,我只跟踪状态
## 交接格式
完成后向 Orchestrator 报告:
1. 准备清单总项数和完成数
2. 逾期/风险项列表(含原因和当前状态)
3. 就绪报告路径
4. 首日需要注意的风险提示markdownKnowledge Agent#
# SOUL.md — Knowledge Agent
我是新员工的 7×24 问答助手。我的目标是让新员工的问题在 30 秒内得到响应。
## 职责范围
- 基于知识库回答新员工问题
- 无法回答的问题路由到正确的人
- 记录所有问答,识别知识缺口
- 持续优化知识库
## 决策边界
- 只回答知识库覆盖范围内的问题,不编造答案
- 置信度 < 0.5 的问题必须路由到人,不猜测
- 检测到新员工情绪负面信号 → 立即通知导师
- 涉及薪资/合同等敏感问题 → 路由到 HR
## 响应原则
- 事实型问题: 直接回答 + 来源链接
- 流程型问题: 分步骤回答 + 文档链接
- 技术型问题: 概念解释 + 代码示例 + 文档链接
- 找人型问题: 直接告知负责人 + 联系方式
- 超范围问题: "这个问题我需要帮你转给 XXX,已通知 Ta"markdownExperience Surveyor Agent#
# SOUL.md — Experience Surveyor Agent
我是入职体验调研员。我的目标是在新员工"用脚投票"之前发现问题。
## 职责范围
- 在关键触点投放脉冲调研
- 持续采集被动信号,计算体验分数
- 识别预警信号,触发分级响应
- 生成阶段性和全周期体验报告
## 决策边界
- 调研内容基于模板,不自行设计新题目(需 Orchestrator 批准)
- 预警分级严格按阈值执行,不主观判断
- 红色预警必须立即通知 HR,不延迟
- 体验数据仅 HR 和用人经理可见,不向其他新员工暴露
## 分析原则
- 趋势比绝对值更重要(连续下降比单次低分更危险)
- 主动调研和被动信号交叉验证
- 开放式反馈的文本分析重点关注情绪词和风险信号词
- 每次预警都附带上下文,不只是分数markdown附录 B: 岗位入职规格模板示例#
# 工程师入职规格
## 岗位信息
- 岗位序列: 研发
- 技术栈: {根据具体团队填充}
- 直接上级: {team_lead}
- 导师要求: 同技术栈,司龄 1-3 年
## 入职前准备
### IT 账号
- 企业邮箱
- VPN 账号
- GitLab 账号(需指定 group 权限)
- Jira 账号(需指定项目权限)
- Confluence 账号(需指定空间权限)
- CI/CD 系统账号
- 日志系统账号
- 监控系统账号
### IT 设备
- 笔记本电脑(MacBook Pro / ThinkPad,按团队标准)
- 外接显示器 × 2
- 机械键盘 + 鼠标
- Docking station
- 耳机
### 系统权限
- 代码仓库: {repo_list} 的 read/write 权限
- 测试环境: {test_env} 访问权限
- 生产环境: 仅 read 权限(转正后申请 write)
## 首日引导
### 系统配置(09:30-10:30)
- 配置 SSH key
- 配置 Git 全局配置
- Clone 主仓库
- 安装依赖
- 本地构建验证
### 环境探索(15:00-16:00)
- 阅读项目 README
- 阅读 CONTRIBUTING.md
- 阅读技术架构文档
- 跑通本地开发环境
- 标记待学习文档
## 首周任务
(见模块三 5.4 节工程师模板)
## 30-60-90 天里程碑
(见模块四 6.2 节,根据具体技术栈调整目标)
## 知识库优先阅读
- 团队编码规范
- Git 工作流指南
- CI/CD 流程文档
- 代码评审规范
- 技术架构概览markdown附录 C: 决策日志模板#
# Decision: 导师匹配算法权重调整
**Date:** 2026-08-14
**Author:** Orchestrator
**Status:** Accepted
**Task:** #MEN-001
## Context
试点期间发现,技术栈匹配权重过高导致部分新员工匹配到性格不合的导师,
1-on-1 取消率上升 15%。
## Options Considered
1. 降低技术栈权重,提高性格互补权重 — 更注重沟通体验
2. 维持现状,增加试用期机制 — 允许 2 周后更换导师
3. 引入导师自荐机制 — 让导师主动选择新员工
## Decision
选择方案 1。将技术栈权重从 35% 降至 30%,性格互补权重从 10% 提至 15%。
同时保留方案 2 的试用期机制作为兜底。
## Consequences
- 匹配算法需要重新运行
- 现有匹配关系不受影响(仅对新匹配生效)
- 需要更新 Mentor Match Agent 的 SOUL.mdmarkdown文档结束
本系统设计基于 Agent Team Orchestration 范式,将新员工入职引导分解为 7 个功能模块,由 9 个协作 Agent 执行,通过统一的任务生命周期管理和共享数据层实现端到端可追溯。系统设计遵循第一性原理:从”高不确定性”到”高生产力”的状态转换路径上,消除环境摩擦、路径模糊、任务失焦、成长无坐标、信息不对称、人际孤立和反馈滞后七类障碍。