店员家企业级智能体基座方案 V3

01 · 项目背景

项目背景与现状

1.1 当前期现状

随着「店员家」客户使用规模不断扩大，灵工数量上升，「客户越成功，管理越复杂」的结构性矛盾日益突出。

问题反馈（N=6,563）

对 2025.11—2026.03 期间真实用户反馈的深度分析：打卡与排班（28.9%）、人员与账号（27.5%）、结算与佣金（21.2%）、签约与协议（16.3%）四类核心问题合计占比 94%。

问题处理链路

问题从灵工/店长反馈后，需经 400 客服 → 大区运营 → 招聘顾问 → 店员家运营 → 研发 多层流转（4–6 层），链路长、效率低。

1.2 底层三大核心矛盾

①人力成本高：大量高频问题需多角色重复承接，无效人力成本持续攀升。运营 30%+ 工时消耗在重复答疑，且随灵工规模扩大线性增长，无法靠人力持续对冲。
②用户体验差：问题处理依赖转述和等待，灵工咨询平均响应时长 2 小时以上，灵工/店长/HR 获取结果慢、满意度低，直接影响客户续费意愿。
③需求响应慢：从问题发现到产品能力沉淀周期数天到数周，难以匹配客户业务变化节奏，高频问题反复出现、反复人工承接，无法从根本上收口。

1.3 外部窗口与竞品态势

灵工 SaaS 主要竞品（青团社等）在传统功能维度具备先发优势，按传统资源功能堆砌方式追赶边际效益递减。与此同时，大模型与 Agent 工程化能力成熟，行业出现 2–3 年的技术窗口期——率先完成 AI 原生重构的企业，将以「对话即服务」重新定义客户体验，建立非传统功能维度的差异化。

为什么是现在

窗口期已开启（大模型工程化拐点 + 竞品尚未完成 AI 原生重构）。晚启动 6–12 个月，单位投入产出差距将拉大数倍。

为什么是我们

店员家业务线场景密度最高、客户反馈数据最完整、问题分布最具代表性，是验证企业级智能体可行性的最优首发场景；天然具备多业务线复用属性。

1.4 项目定位

核心定位

本项目不是「为店员家做一个聊天机器人」，而是建设君润企业级智能体基座，并以店员家为首发业务场景验证可行性。基座具备三大基本特征：

多租户数据隔离做到架构层，不依赖 prompt 提醒模型
高敏感业务（薪酬/出勤/签约）的回答可追溯到真实查询，不是模型编造
跨业务域 Skill 资产复用——首发跑通后，可按统一架构快速复制到其他业务线，形成「基座统一、Skill 沉淀、多业务线共享」的能力资产体系

02 · 需求分析

客户触点与需求分析

按「谁与智能体对话」统一维度切分，4 类客户触点互斥穷尽，覆盖平台全部服务角色。

客户触点	问题量占比	现状痛点	触点升级	量化效果目标
灵工 C 端使用者	约 60%	工资/打卡/排班/签约问题需等 2 小时 + 多层转述，体验差、流失率高	自然语言对话即可查询工资、考勤、排班、签约状态，秒级响应	自助解决率 ≥85%，平均响应 <1 分钟，7×24 在线
店长 / HR B 端管理者	约 25%	门店用工/异常诊断需逐条手工处理，月均 20+ 小时用于答疑和协调	一句话获取门店用工、异常诊断、人员状态，减少重复答疑与培训成本	答疑工作量降低 30%+，新人上岗培训从 5 天缩至 1 天
企业管理层 B 端决策者	约 10%	报表、预警、异常解释等个性化诉求响应周期数天	通过 Skill 快速配置交付，支持经营分析、用工趋势、成本诊断等决策辅助	个性化需求响应周期从数天缩至 1 天内
平台运营内部	约 5%	高频标准问题人工承接，运营 30%+ 工时消耗在重复答疑	标准问题前置到智能体处理，人工仅承接复杂/异常场景	人工承接压力降 50%+，释放运营精力投入高价值工作

2.2 高频问题分布（N=6,563）

打卡与排班

28.9%

灵工 / 店长

人员与账号

27.5%

灵工 / HR

结算与佣金

21.2%

灵工

签约与协议

16.3%

灵工 / 店长

四类合计占比约 94%，数据来源：2025.11—2026.03 期间真实用户工单

2.3 非功能需求

维度	指标	目标值
性能	对话首字符响应时间	< 3 秒
性能	支持并发用户数	≥ 1,000
性能	Skill 触发延迟	< 500ms
准确性	意图识别准确率	≥ 85%（抽样人工标注）
安全	跨租户数据串通	零容忍，P0 级防护
安全	跨角色越权读取	零容忍，P0 级防护
可用性	系统可用性	≥ 99.9%，7×24 在线
成本	Phase 1 月 Token 成本	< ¥1,000

03 · 解决方案

解决方案概览

3.1 核心答案：让 AI 在确定性轨道上工作

核心设计哲学

企业级场景需要的是确定性——谁能看什么数据、查到的结果是否准确、操作能否被追溯。AI 天然是概率性的、不可预测的。我们的方案不是消灭 AI 的不确定性，而是把不确定性限制在语言表达层，把确定性还给业务逻辑层。

传统聊天机器人让 AI 决定一切——查什么数据、用什么权限、输出什么结论，结果是不可控的黑盒。我们走的是反方向：服务端负责所有关键决策（实体解析、权限边界、Tool 调用、结果过滤），AI 只做最后一公里——把服务端已经确认的事实，用用户听得懂的语言说出来。

这意味着：AI 说错了，最多是表达不好；AI 无法越权查数据，因为数据层根本看不到；AI 无法编造结果，因为回答必须基于本轮真实查询。不确定性被收进了一个安全的盒子里。

维度	通用聊天机器人	君润对话式智能体
谁来决定查什么数据	模型自己决定	服务端先确定，模型不参与
谁来决定能看什么数据	靠 prompt 提醒模型	服务端在数据层强制隔离
错了怎么办	模型继续猜	优先停下来澄清或拒绝
能否解释为什么这么答	难，黑盒	每一步都有结构化记录
跨企业数据混淆风险	高	架构层杜绝

3.2 九大业务 Agent：替代 30 位人工角色

基于灵工 SaaS 全业务链路，按「角色 × 场景」MECE 分解，规划 9 个专项 Agent，每个 Agent 替代一个真实业务角色，从人力招聘到经营诊断形成完整业务闭环。所有 Agent 共享同一套双 Agent 运行时基座，各自拥有独立的 Skill、Tool Catalog 和业务操作手册。

Agent 01 · Phase 2

招聘引导 Agent

替代 · 引导候选人

C 端入驻引导：登记、实名认证、入驻认证、简历完善等全流程。

Agent 02 · Phase 2

签约 Agent

替代 · 辅助签约专员

签约 C 端排班/考勤/验收引导，智能提醒未签合同，自动推送电子签约。

Agent 03 · Phase 1

灵工助手 Agent

替代 · 400 客服（C 端）

灵工日常自助查询：打卡异常、工时核算、佣金明细、证件到期，7×24 在线。

Agent 04 · Phase 1

薪酬 Agent

替代 · 结算/出纳岗

佣金计算核验、工资条解释、结算异常诊断、扣款明细查询。

Agent 05 · Phase 2

合规 Agent

替代 · 风控岗

签约合规检测（D1+E1+期限校验）、用工风险预警、工时超限检测。

Agent 06 · Phase 1

客服 Agent

替代 · 400 客服（B 端）

各企业标准化 FAQ、政策咨询、出勤异常、参保咨询等多企业共性问题。

Agent 07 · Phase 2

经营分析 Agent

替代 · 产业分析师

SOP 自动报告、人效分析、出勤趋势、佣金波动等分析场景。

Agent 08 · Phase 2

经营诊断 Agent

替代 · 诊断师/巡查

员工流失率异常、营业额/成本异常、排班效率低等经营问题根因诊断。

Agent 09 · Phase 3

顾问 Agent

智能导购 Agent

帮助客户理解系统功能、推荐最佳实践、引导新功能使用。

覆盖范围

5 个角色（灵工、店长/HR、运营、产品/研发、企业管理层）× 25 个核心问答场景，覆盖灵工 SaaS 约 94% 的全部服务需求。每个使用者只需学会一招——对话。

04 · 系统设计

系统是怎么工作的

4.1 为什么不能让模型自由发挥

灵工 SaaS 的对话不是普通问答，它同时涉及身份、权限、租户隔离和高敏业务数据。模型可以负责理解语言，但不能直接决定“能不能查、查谁的数据、返回哪些结果”。因此，系统必须把模型约束在服务端安全边界内工作。

①多角色访问：君润运营、企业管理员、门店负责人、灵工本人都会在同一套系统中提问，但不同角色可见的数据、可执行的操作和回答口径完全不同。
②多租户隔离：A 企业的 HR 绝不能看到 B 企业的员工、薪资、排班或结算信息。租户隔离必须由架构层和服务端权限体系保证，不能依赖 prompt 提醒模型“不要越权”。
③高敏业务数据：工资、结算、出勤、合同、人事等数据都属于高敏信息。任何一次错答、越权查询或模型幻觉补全，都可能引发客户投诉、合规风险，甚至法律风险。
④强上下文依赖：用户常说“他这个月工资多少”“上次那个人安排了吗”这类省略表达。系统必须结合身份、会话历史、业务实体和权限范围进行确认，不能让模型自行猜测。

基于这些约束，纯规则方案会在复杂表达下变得僵硬，完全自由的模型方案又会带来越权和数据泄露风险。因此，本方案采用中间路线：双 Agent 架构 + 服务端安全主干，让模型负责理解和推理，让服务端负责权限、校验、执行和兜底。

4.2 双 Agent 架构设计

核心决策是：LLM 负责语义理解，服务端负责安全边界。采用完全双 Agent 模式，在两个 Agent 之间建立服务端硬校验主干，确保即使 Agent 判断错误，也最多退化为体验问题，不能演化为越权或数据泄露。

Intent Agent（意图识别层）

使用低成本模型，输出结构化 JSON：turn_type、domain、intent、实体引用、时间范围、缺槽、歧义和置信度。只输出结构化数据，不回答用户，不调用业务 Tool，不直接决定权限。

Reasoning Agent（推理执行层）

基于已校验的 BusinessRequest 和注入的 Skill 上下文，使用主模型推理、调用 Tool、组织最终回答。在 Tool Guard 和 Result Guard 双重保护下工作，无法接触到敏感信息。

服务端安全主干（两个 Agent 之间的护栏）

Entity Resolver（实体绑定）→ Request Validator（请求硬校验）→ Runtime Assembly（Skill 注入）→ Tool Guard（调用拦截）→ Result Guard（结果过滤）。即使双 Agent 都判断错误，安全主干也必须拦截非法调用。

4.3 五大业务域（domain）

业务域是 Intent Agent 对每个请求的「业务归类」，也是 Runtime Assembly 做 Skill eligibility 校验的第一道过滤器——domain 不匹配，后面六项校验根本不用看。目前规划五个业务域，覆盖灵工 SaaS 全部核心场景：

业务域	关注的核心问题	典型问题示例
people 人员域	跟「人」有关——入职信息、身份认证、账号状态、合规资质、证件到期	「查一下张三的入职信息」「这个手机号绑定的是哪个员工」
work 排班/出勤域	跟「干活」有关——排班查看、打卡记录、出勤统计、工时核算、打卡异常诊断	「为什么打不上卡」「马燕婷这个月出勤多少天」
money 结算/薪酬域	跟「钱」有关——佣金计算、工资条解释、结算异常、扣款明细、发薪时间	「我这个月工资为什么少了」「结算批次什么时候到账」
compliance 合规域	跟「风险」有关——签约状态、合同合规性、用工风险预警、工时超限检测	「这个员工合同签了吗」「哪些员工本月工时超限」
analytics 分析域	跟「趋势和洞察」有关——出工趋势、人效分析、成本波动、门店对比、经营诊断	「25 组织 18 门店 01 上个月人效怎么样」「近三个月佣金波动原因是什么」

domain 在运行时的作用

Intent Agent 识别出 domain 后，Runtime Assembly 精准筛选该域下的 Skill 和 Tool，不会把「查工资」的 Tool 暴露给「查排班」的请求。domain 是 Tool 暴露面裁剪的第一道过滤器，让 Reasoning Agent 始终只在当前业务域的最小 Tool 集合里工作。

4.4 七大设计原则

1权限和范围由服务端决定，不由 LLM 决定——LLM 可以建议候选实体，但 Entity Resolver 才是实体绑定的正式入口
2LLM 不直接决定关键业务对象（企业、门店、员工、批次），服务端 Entity Resolver 负责正式解析和绑定
3Tool 只接收业务参数，不接收 SQL，不暴露底层表结构——LLM 不得直接生成 SQL
4所有有价值的对话先收敛成结构化业务请求（BusinessRequest / ExecutionPlan），再进入推理执行
5不确定就澄清或拒绝（fail-closed）——Intent 低置信、实体多候选、缺必要槽位时，一律澄清，不猜
6回答必须基于本轮真实查询到的数据，不能无依据生成
7敏感信息（enterprise_id、SQL、表结构）物理上不在模型 prompt 里——这是多租户隔离的物理保障，不是 prompt 提醒

4.5 对话运行流程（九步链路）

每一轮用户对话，背后都会经历一套完整的确定性链路。下图展示从用户发起对话到系统完成回答的完整九步流程，清晰呈现每一个决策点的归属——哪些由服务端控制，哪些由 LLM 完成。

图 1 君润智能体对话流程卡片（九步链路）

图示说明：步骤 1-2 为会话管理层（接收原话 + 恢复上下文）；步骤 3-6 为服务端确定性区（意图识别 → 生成业务请求 → 注入权限 → 裁剪 Tool）；步骤 7-9 为 LLM 工作区（服务端参数把关下的 Tool 执行 → LLM 组织回答 → 守卫落库）。核心原则：即使双 Agent 都错，也只退化为体验问题，不演化为越权或数据泄露。

三类典型场景

明确查询

「马燕婷 2026 年在 25 组织 18 门店 01 的出工趋势」→ 服务端解析门店和员工，调用唯一允许的「趋势分析」工具，LLM 拿到结果后画图、写摘要。

需要澄清

「查一下张三的入职信息」（系统里有 5 个张三）→ 系统不让模型猜，直接进入澄清状态，让用户从候选人里选一个，选完后再继续执行。

诊断类问题

「为什么打不上卡」→ 系统识别缺少关键坐标（哪个员工？哪一天？哪个门店？）→ 先要求补充信息，不让模型直接编「可能的原因」。

4.6 技术架构

下图展示君润企业级智能体的完整技术架构，涵盖接入层、核心引擎（双 Agent）、基础能力层三大区块，以及它们之间的数据流转与安全守卫关系。

图 2 君润企业级智能体技术架构图

架构解读（自上而下三层）

接入层：统一所有渠道入口（钉钉/飞书/企业微信/小程序/Web/开放 API），无论用户从哪个端进来，都规范化成同一个 AgentRequest 对象（含 session_id、user_id、tenant_id、role）。渠道细节在这一层完全隔离，后面的引擎不感知用户从哪里来。

核心引擎（数据流顺序）：

① Intent Agent：低成本小模型，每轮对话先跑这一步，输出结构化 JSON（turn_type / domain / intent / entity_refs / slots / confidence）。只输出结构化数据，不回答用户，不调 Tool。

② 服务端安全主干（四模块并行）：Context Snapshot 恢复上一轮已确认实体和权限 scope；Domain Retrieval 本地检索召回术语/实体/别名候选（只是候选，不做正式解析）；Entity Resolver 将 Intent Agent 输出的实体引用校验存在性和权限范围后正式绑定；Request Validator 对 Intent Agent + Entity Resolver 的联合输出做硬约束校验（schema 有效性、必填槽位、实体权限、scope 合法性、写操作风险等级），校验通过后生成 BusinessRequest / ExecutionPlan，作为后续 Skill 注入和推理执行的唯一合法凭据。

③ Runtime Assembly（行动包打包器）：在 BusinessRequest 已经合法的前提下，决定 Reasoning Agent「能用什么、知道什么、怎么工作」。具体做三件事：
  · Skill 注入（最核心）：不是所有 Skill 都给 Reasoning Agent 看，而是根据当前请求做 eligibility 七项校验（domain 匹配、capability 匹配、实体类型满足、scope 合法、企业启用、Tool 可用、风险允许），七项全过才注入，任何一项不过就排除——让 Reasoning Agent 做判断题，不做选择题。
  · 企业知识注入：把这家企业的 SOP、计薪规则、特殊排班规定等 Enterprise Context Assets 按需注入，让 Reasoning Agent 理解「这家企业的具体业务规则」，而不是用通用常识瞎猜。
  · 权限上下文注入（_ctx）：把当前用户的 enterprise_id、shop_ids、role 等敏感信息以不可见方式注入 Tool 调用链，Reasoning Agent 看不到这些值，但 Tool 执行时服务端会自动带上——这是多租户隔离的物理保障。
  · 一句话总结：Request Validator 决定「这个请求合不合法」，Runtime Assembly 决定「合法的请求用什么工具、带什么上下文去执行」——前者是入场券，后者是装备包。

④ Reasoning Agent：主模型在此工作，基于行动包推理、选 Tool、调用、组织回答。明确约束：不生成 SQL，不编造事实。

⑤ 三类 Tool：Skill Tools（SKILL.md 驱动，支持 Query / Diagnose / Action）、MCP Tools（标准化协议封装业务 API）、Business Tools（直接访问业务库，scope 由服务端注入，不暴露给模型）。

⑥ Tool Guard + Result Guard（双层护栏）：调用前校验权限/参数/scope/确认 token → APPROVE / DENY；返回后行级过滤、字段过滤、脱敏、截断、剔除内部 ID。

⑦ 全链路 Diagnostics & Audit：每轮对话的 Intent 输入输出、Resolver 结果、Tool 调用、写操作 token 全量记录，出问题能精确定位到哪一步。

⑧ Session 管理 + Token 费用控制：硬编码上限（max_iters=15，max_tokens=50000），Intent 每次约 0.005 元，Reasoning 约 0.05 元，费用可控可预期。

⑨ 三层数据隔离：接入层 JWT + _ctx 注入 → 执行层 build_scope_clause 自动拼 WHERE 条件 → 校验层黑白名单 + 脱敏 + 审计，三道防线任何一层都能独立拦截越权。

基础能力层（8 个模块）：Enterprise Context（术语表/实体索引/别名库/企业知识）、Skill Registry（元数据/capability/版本）、Tool Catalog（调用契约/schema/敏感字段）、数据安全（JWT/_ctx/多租户/审计）、Golden Cases（意图回归测试集）、Provider（Qwen/DeepSeek 主备切换）、资产蒸馏引擎（高频模式识别 → 自动封装 → Publish 为新 Skill）、Config & Storage（session 配置/token 配额）。

未来探索：最底部是长期方向——沉淀的 Skill 资产走向开放：Skill 沉淀 → 市场上架 → 开放 API → 三方调用 → 客户自建 → 形成灵工行业 AI Skill 生态闭环。本期不作为目标，但架构从第一天就为这条路留好了接口。

4.7 产品架构与记忆体系

下图展示包含双记忆体系（个人记忆 + 企业记忆）的完整产品架构，从多渠道入口，到双 Agent 运行时，到 Skill 应用市场，再到 L6 资产蒸馏闭环。

图 3 君润企业级智能体产品架构图 v3（含双记忆体系）

图示说明：渠道接入层：企微、钉钉、H5、App 多端统一接入，API Gateway 统一鉴权与 _ctx 注入。双记忆体系：个人记忆（用户历史偏好、角色上下文）与企业记忆（企业 SOP、知识资产、Skill 规则）独立存储、分权访问。Skill 应用市场：各 Skill 有独立 Tool Catalog 和风险等级（Query/Diagnose/Action/Analytics），通过 eligibility 七项校验决定是否注入当前会话。L6 资产蒸馏层：高频问题经治理流程封装为新 Skill，实现平台能力复利增长。

4.8 对话时序与 Skill 注入机制

下图以泳道时序图形式，展示从用户发起对话到最终回答的完整时序，包含 Skill 匹配注入与蒸馏闭环。

图 4 君润智能体对话时序图 v2（含 Skill 完整体现）

图示说明：5 个泳道的协作关系：用户发起自然语言请求 → Intent Agent 输出结构化意图 JSON → 服务端安全主干完成实体解析/权限验证/BusinessRequest 生成/Skill 注入 → Reasoning Agent 基于已校验请求调用 Tool（每次经 Tool Guard 拦截）→ Result Guard 过滤后组织回答 → L6 蒸馏层将高价值对话封装为新 Skill 资产。关键约束：敏感信息物理隔离于模型 prompt 之外；写操作需双重确认 token 和审批流。

4.9 Skill 体系

Skill 的定义为「一个业务域 × 一种能力类型的最小自治单元」——内部通过多个 Tool 协作完成任务，对外通过 Handoff 与其他 Agent/Skill 联动。

能力类型	风险等级	说明	示例
Query	L0 零风险	只读查询，无副作用	查工资、查排班、查入职信息
Diagnose	L0 零风险	只读 + 推理诊断	打卡异常诊断、结算差异分析
Analytics	L0 零风险	只读 + 聚合分析	出工趋势、人效分析、成本波动
Action	L1–L3 需确认	写入操作，需审批流	补卡申请、排班调整、审批触发

4.10 数据安全：三层隔离 + 四角色权限

角色	_ctx 必须含	数据范围	特殊限制
灵工 (worker)	user_id, id_card_no	只能查/操作自己	忽略用户传入的 worker_ref
店长 (store_manager)	shop_ids: [int]	限本店	表无 store_id 时拒绝
企业 HR	enterprise_id, company_ids	限本企业	enterprise ≠ company，1:N
运营 (operator)	is_operator: true	全可见	代码里显式 skip_scope

4.11 数据库设计

智能体基座独立建库（junrun_agent），与业务库（jr_yh_portal）物理分离，对业务库只读访问，防止 LLM 越权写入。应用自有库共 40 张表，按功能划分为 7 个群组，每个群组对应智能体运行时的一个核心关切。

设计核心思想

租户/用户

多租户隔离是物理约束，不是 prompt 提醒

tenants → users → user_identities → user_sessions，每张表都带 tenant_id，_ctx 由框架注入且不可篡改。user_identities 存储跨系统身份（钉钉/企微/手机号），一个用户可有多个 identity，scope_snapshot 记录当次登录的权限快照，确保权限判断与身份绑定而非实时查询。

对话/计费

每一步都有结构化记录，回答必须可追溯

conversations → messages → tool_calls 三层链路完整记录每轮对话；token_usage 关联到 tenant/user/conversation/message 四级，支持按任意粒度核算费用；audit_logs 全量记录用户操作，满足合规审计要求。

写操作

写操作必须经过确认+审批，支持回滚

write_action_runs 记录每次写操作的完整上下文（risk_level / scope_snapshot / idempotency_key），写操作不直接执行，需经 Tool Guard 校验后才进入执行队列；internal_followup_tasks 关联异步后续任务，支持失败重试与回滚追踪。

模型治理

多模型灵活切换，凭据与 scope 解耦

llm_providers → llm_models / llm_model_credentials → llm_model_scopes，同一模型可绑定多套凭据，通过 scope_type（tenant/global/agent）灵活分配；llm_model_test_runs 支持切换前的延迟与可用性测试，保障主备模型平滑切换。

领域知识

让通用模型理解灵工业务语境的语义底座

business_terms 维护业务术语及其 canonical 标准形式；business_entities → entity_aliases 支持「马燕婷」「马总」「15030…」等多种指代解析到同一实体；managed_tools / managed_skills 是 Tool Catalog 和 Skill 注册表，Runtime Assembly 据此做 eligibility 校验和注入。

企业资产

企业知识资产版本化管理，支持多版本回滚

enterprise_context_assets 作为主表，带 5 张子表：revisions（版本历史）、usage（使用记录）、conflicts（冲突检测）、promotions（审批发布）、search_terms（检索词）。企业 SOP、计薪规则等知识每次修改都留版本，发布前需经 Review → Test → Approval 治理流程。

诊断治理

诊断链路可观测，支持按企业/门店级别定制规则

diagnosis_log_events → diagnosis_event_subjects 记录原始诊断事件及涉及主体；diagnosis_plan_publications → diagnosis_runs → diagnosis_feedback 完整记录诊断计划发布、执行和反馈三段；diagnosis_condition_overrides / plan_overrides 支持按 scope（tenant/enterprise/store）覆盖默认诊断规则，实现客户级差异化配置。

ER Junrun 应用自有库 ER 图（40 张表 · 逻辑外键 · Phase 1 无物理约束）

租户 / 用户 / 会话对话 / 消息 / 计费写操作 / 任务模型治理领域知识 / Skill企业上下文资产诊断治理

⚠️ 所有连线均为逻辑外键，Phase 1 无物理 ForeignKey 约束

05 · 实施路径

里程碑与实施路径

总体目标

建设君润企业级智能体基座，以店员家为首发场景，分四个里程碑完成从「内部工具」到「行业生态基础设施」的演进。采用「架构一次性切换、能力分层落地」的策略——主链路直接切到双 Agent，不做线上 A/B，旧 parser 中可复用的结构化标识抽取迁移为候选召回辅助，安全校验逻辑迁入 Validator 和 Tool Guard。

M1 · 内部 MVP

2026 Q2

05-01 → 07-01

M2 · 种子客户

2026 Q3

06-01 → 09-01

M3 · 全面开放

2026 Q4

09-01 → 11-01

M4 · 项目结项

2027 Q1

11-01 → 12-31

里程碑 1

内部 MVP + 内部验证

2026-05-01 → 2026-07-01

双 Agent 引擎（Intent Agent + Reasoning Agent）搭建完成并跑通主流程
Skill 覆盖「查询 / 诊断 / 分析」三大意图领域，60% 的日常咨询场景，回答准确率 ≥ 80%
首批上线 Agent：灵工助手 Agent（03）、薪酬 Agent（04）、客服 Agent（06）

内部测试版MVP 验收报告Token 成本基线报告安全验证报告golden cases ≥300 条

里程碑 2

企业级治理 + 种子客户落地

2026-06-01 → 2026-09-01（与 M1 尾端并行推进）

完整企业级治理上线（企业知识治理 / 审批审计 / 权限矩阵 / 风险边界）——更懂企业业务的核心
2 家试点企业落地，Skill 覆盖「查询 / 诊断 / 分析」三大意图领域，80% 的日常问题场景
试点期间无 P0 故障，客户满意度 ≥ 4.5/5
新增上线：招聘引导 Agent（01）、签约 Agent（02）、合规 Agent（05）、经营分析 Agent（07）、经营诊断 Agent（08）

企业版智能体产品安全审计报告种子客户试点报告客户培训材料运营管理手册

里程碑 3

全场景覆盖 + 写操作上线，对所有客户开放

2026-09-01 → 2026-11-01

9 个 Agent 完整矩阵就绪，嵌入从企业入驻到结算全流程；顾问 Agent（09）上线
对话即操作上线（审批 / 排班等低风险写操作），配套审批流 + 回滚 + 审计，写操作高风险误推进 = 0
Skill 覆盖「查询 / 诊断 / 分析 / 操作」四大意图领域，90% 的日常咨询场景
对所有客户正式开放，系统可用性 ≥ 99.9%

全场景产品正式版Skill 治理流程文档通用 Skill 资产库全量客户上线方案

里程碑 4

项目结项

2026-11-01 → 2026-12-31

对照 PRD 完成全功能验收测试，无遗留 P0/P1 问题
运营数据达标：AI 自助解决率 ≥ 80%，客户满意度 ≥ 4.5/5，系统可用性 ≥ 99.9%
Token 成本完成全周期决算，在预算范围内
Skill 资产库、golden cases、架构文档、运营 SOP 完整移交运营团队
完成项目复盘，输出下阶段演进建议书

项目验收报告全功能测试报告运营数据决算报告Skill 资产移交清单架构与运营 SOP 文档包项目复盘报告下阶段演进建议书

完成态验收标准（8 条）

①高价值请求都能通过 Intent Agent 识别并在服务端产出 BusinessRequest 和 ExecutionPlan
②Reasoning Agent 基于已校验的 BusinessRequest 推理，不再自由选择全量 Tool
③所有关键歧义（同名实体、缺槽、低置信）都进入统一澄清流程，不猜
④查询、分析、诊断都能给出可解释的同轮执行证据
⑤同一类问题的回归测试通过 golden cases 驱动，不依赖 prompt 文案微调
⑥新增一个业务域或 Agent 时，主要工作变成「补 Skill、Tool 和领域知识」，而不是「再调一套 prompt」
⑦高风险写操作误推进为 0，实体解析误绑定率低于人工确认阈值
⑧p95 延迟和 token 成本在预算内，9 个 Agent 的运行数据持续反哺领域知识底座

06 · 价值与 ROI

项目价值与投资回报

6.1 构建了什么

可无限复用的服务能力基础设施

9 个 Agent + N 个 Skill 构成的能力矩阵，新客户接入即可用，边际成本趋近于零。传统模式下服务一个新客户需要配一批客服、做一轮培训——本项目让这件事变成基础设施。

持续增值的行业 Skill 资产库

每一次真实业务对话都在沉淀资产。一个 Skill 在第一家客户场景里打磨成型后，自动服务于后续所有客户。Skill 数量和质量只增不减——这不是一次性项目交付，而是一台越转越快的资产引擎。

从架构层建立的信任门槛

企业客户敢把薪酬、人事、合规数据交给我们处理，是因为多租户隔离、权限矩阵、操作审计做到了架构层。这不是功能点，是客户信任的基础，也是通用 AI 平台无法快速补齐的。

6.2 对不同角色意味着什么

对平台：从「人力服务」到「能力飞轮」

94% 的高频问题由智能体前置处理，运营从「逐条接单」转为「管理 Skill 质量」。同样的团队规模，可以支撑 3–5 倍的客户数量。每蒸馏一个 Skill，就永久减少一类人工介入。

传统 SaaS 竞争是功能军备赛——你出一个排班优化，竞品三个月就能跟上。但 Skill 资产是在真实业务里验证过的行业经验，需要客户、场景、数据三者同时积累。每多服务一家客户，Skill 库就更丰富，新客户体验就更好，获客效率就更高——这个飞轮竞品无法通过「抄功能」追上。

对企业客户：管理能力上限被拉高了

店长不再需要记住「排班在第几个菜单、考勤异常怎么导出」——说一句话就有结果。新人上岗即用，培训周期从 5 天压缩到 0。问题响应从小时级变为秒级，7×24 不间断。

企业真正获得的不是一个 AI 功能，而是管理灵工的能力上限被拉高了——同样的 HR 团队，能管住比以前多 3 倍的灵工。

对灵工：问题不再需要「求人」

工资少发了不用找店长转达，自己问就知道原因和到账时间。打卡异常不用等两天才有人回复，当场就能定位问题。补卡、换班、签约状态——过去要经过 4–6 层流转的事情，现在一轮对话闭环。

灵工体验直接影响留存率，留存率直接影响企业的招聘成本——这是客户续费意愿的底层逻辑。

6.3 直接产出

产出	说明
9 个业务 Agent	覆盖灵工 SaaS 94% 的服务场景，替代 30 个人工角色的核心能力
N 个可复用 Skill	每个 Skill 开发一次，服务所有客户，首期目标 ≥30 个
企业级治理体系	多租户隔离 + 四角色权限 + 操作审计 + 写操作审批，通过安全审计
领域知识底座	业务术语表 + 实体索引 + 别名库 + golden cases ≥300 条
双 Agent 运行时基座	可复制到其他业务线的标准化架构，新增业务域只需「补 Skill 和 Tool」

6.4 ROI 测算

预计年降本价值

¥80 万

运营人力 10 万 + 交付效率 20 万 + 客户侧节流 50 万

全期研发投入

¥30 万

含人力、API、安全审计全部费用

收益项	年化金额	推导依据
运营/客服人力降本	¥10 万/年	AI 替代重复答疑，减少 ≥2 名客服/运营岗承接工作
客户交付效率提升	¥20 万/年	客户 40% 需求 Skill 化后可配置交付，交付周期从数天缩至 1 天
客户侧节流（降低流失）	¥50 万/年	帮客户企业的店长/HR 减少 30%+ 答疑工作量，降低客户流失风险
合计年收益	¥80 万/年	基准回本周期 ≈ 4–5 个月（全期投入 30 万 ÷ 年收益 80 万）

客户侧 ROI 参考

店长月薪 8,000 元 × 节省 20 小时 = 省 920 元/月；智能体约 1,500 元/月，每家门店 3–5 个店长净省 1,500–3,000 元/月，客户 ROI 约 100%–200%。

6.5 对竞品意味着什么

竞品如果想追平，需要同时做到三件事：搭一套企业级治理的双 Agent 架构、在真实客户场景里积累足够的 Skill 资产、建设一个覆盖灵工全业务链的领域知识底座。这三件事都需要时间，不是钱能解决的。先发 6 个月意味着数千轮真实对话的资产积累——这个时间差就是壁垒。

6.6 后续商业化方向（本期不作为目标）

本期目标为内部工具验证和种子客户试点，不涉及商业化。后续可探索订阅制增值服务模式（基础版 ¥1K–3K/月、专业版 ¥5K–15K/月、企业版定制），以及向多业务线开放 Skill 生态接口，最终形成灵工行业的 AI Skill 基础设施。

07 · 团队与预算

团队组织与预算

7.1 核心团队配置

角色	人数 / 人月	AI 辅助后变化	核心职责
产品经理	1 人 · 3.0 人月	原 5.0 → 压缩 40%	需求梳理、Skill 定义、路线图管理、客户反馈闭环
后端/全栈研发	2 人 · 6 人月（共 12 人月）	原 9.0 → AI 辅助架构/逻辑代码生成	双 Agent 引擎、MCP 协议层、业务 API 对接、权限系统、数据存储
前端研发	1 人 · 1.0 人月	原 2.5 → AI 生成大量组件代码	对话交互界面、管理后台、数据可视化
UI 设计	0.5 人 · 0.5 人月	原 0.8 → 设计系统复用	产品视觉设计、交互规范
测试工程师	1 人 · 1.0 人月	原 2.5 → AI 辅助用例生成	功能测试、安全审计、跨租户隔离验证
业务运营	1 人 · 2.5 人月	原 4.7 → 聚焦种子客户	种子客户对接、Skill 运营、反馈收集
中台技术支持	0.8 人月	原 1.6 → AI 辅助运维脚本	监控/日志/安全评审/运维

7.2 预算概览

科技人力（全期）

≈ ¥24 万

17.5 人月 × 均摊约 14k/月（内部人员）

全期总预算
≈ ¥30 万
含人力、API、安全审计全部费用

LLM API 费用

¥1–2 万

Phase 1 内部试用量级，含开发期调用

成本项	原估算	AI 辅助后	说明
科技人力	¥51.7 万	¥24 万	17.5 人月（产品 3.0 + 研发 12.0 + 前端 1.0 + UI 0.5 + 测试 1.0）× 均摊 14k
业务投入	¥9.4 万	¥3.5 万	运营 2.5 人月 + 中台 0.8 人月 × 均摊 12k
LLM API 费用	¥3–8 万/年	¥1–2 万	Phase 1 内部试用量级；开发期 Claude Code 等工具另计入工具订阅
安全审计	¥3–5 万	¥1–2 万	以内部自查为主，外部渗透测试仅针对跨租户隔离核心路径
合计	¥70.8 万	≈ ¥30 万	AI 辅助编码整体压缩约 58%

08 · 风险评估

风险评估与应对措施

风险项	等级	应对措施
跨租户数据串通	P0	三层隔离模型（接入层/执行层/校验层）+ 租户 ID 全链路传递 + 数据库行级隔离 + 自动化安全扫描；enterprise_id 物理隔离于模型 prompt 之外
Token 费用失控	P1	三层漏斗控本（规则→小模型→大模型）+ 后端硬编码 session 上限（max_iters=15、max_tokens=50,000）+ 企业级月度配额管理
意图识别准确率不足	P1	双 Agent 架构 + golden cases 回归评测（≥300 条）+ Entity Resolver 实体校验 + Intent JSON schema 强约束 + 灰度发布
Intent Agent 黑盒误判	P1	强 JSON schema 输出、固定枚举值、golden cases 回放、全链路 diagnostics 可追溯，服务端安全主干兜底拦截
多轮对话上下文丢失	P2	Redis 存储会话上下文 + Profile Memory 持久化用户画像 + 关键信息摘要压缩；模糊候选不能自动继承为已确认实体
大模型服务稳定性	P2	多模型备选（千问 + DeepSeek）+ 降级模式 + 自动重试；Phase 3 评估私有化部署选项
试点客户不愿付费	P2	LOI 签约时写明「试点→续约」路径，试点期免费但写明商用门槛；提前准备客户 ROI 量化报告

09 · 附录

核心术语速查

术语	通俗解释
Intent Agent	意图识别层。使用低成本模型，将用户自然语言转化为结构化 JSON（意图/实体/槽位/置信度），不直接回答用户，不调用业务工具。
Reasoning Agent	推理执行层。使用主模型，基于已校验的 BusinessRequest 推理、调用 Tool、组织最终回答。
服务端安全主干	两个 Agent 之间的护栏，由 Entity Resolver → Request Validator → Runtime Assembly → Tool Guard → Result Guard 组成，确保即使 Agent 出错也不越权。
Skill	一个业务域 × 一种能力类型的最小自治单元。不是一个问题的答案，而是用户在某业务领域内某种意图下的「能力容器」。
Tool	服务端暴露给模型的业务函数（如查工资、查排班）。只接收业务参数，不接收 SQL，不暴露底层表结构。
_ctx	服务端注入的权限上下文，包含 enterprise_id、role、shop_ids 等。模型看不到，Skill/Tool 无法篡改。
BusinessRequest	对话内容经服务端校验后生成的结构化业务请求对象，是 Reasoning Agent 工作的唯一合法输入。
fail-closed	不确定就停下来澄清/拒绝，绝不让模型猜。与「fail-open（尽量猜）」相对。
golden cases	意图识别回归测试集，由真实业务问题人工标注而来。用于评测 Intent Agent 准确率，目标 ≥300 条。
L6 资产蒸馏	将高频人工服务经验自动封装为标准 Skill 的机制。闭环路径：真实问题 → 运营人工处理 → 识别重复模式 → 治理审核 → 发布为 Skill，全租户复用。
MCP	Model Context Protocol，标准化工具调用协议。让 Agent 可以调用排班、结算、签约等业务系统 API，同时保持接口解耦。
Domain Knowledge Center	领域语义底座。统一维护业务术语表、实体索引库、实体别名库、企业知识资产，让通用模型能理解灵工业务语境。