当“工作即学习“成为趋势，AI 架构师该写什么代码？

IT阿瑞

445人浏览 · 2026-05-21 15:49:31

IT阿瑞 · 2026-05-21 15:49:31 发布

最近读到一份 2025 年的 L&D 趋势报告，里面有句话让我停下来——目标不再是把学习"加进"工作流，而是让工作和发展融为一体。

这句话对 HR 是愿景，对 AI 架构师是一个非常具体的工程问题。如果"工作即学习"，那员工每一次提交代码、写文档、解工单、做决策，都是一次技能演进——这些信号怎么采、怎么结构化、怎么反馈回去？如果"AI 当实时教练"，那 Agent 怎么知道现在该不该介入、介入到什么程度？

这不是 LMS 升级，是一套嵌入式智能系统。这篇不讲趋势，只讲——如果接到这个需求，该写什么代码。

把命题拆成两个工程子问题

抽象命题落到工程上，至少要先回答两个问题：

技能从哪儿来：怎么从员工真实的工作行为里反推技能等级，而不是依赖自报或考试
AI 怎么教：怎么设计一个不烦人、不越界的教练型 Agent

后面每个子问题给一段可读的代码骨架。语言用 Python，不绑定具体 LLM 厂商。

子问题 1：从工作行为反推技能

为什么自报数据不可信。 大企业里到处都是这种数据：LMS 里"已完成 Python 中级"，Git 里三个月没提交过一行非脚手架代码。报告里说要"超越自报数据走向技能验证"，但没说怎么验证。

一个最小的 Skill Signal Pipeline。 思路是把员工在各业务系统里的真实产出转换成结构化的技能信号，再聚合到一张随时间衰减的技能图谱上。

from dataclasses import dataclass
from datetime import datetime
from typing import List

@dataclass
class SkillSignal:
    skill_id: str          # 对齐到 ESCO/O*NET 等技能本体的 ID
    proficiency: float     # 本次信号反映的熟练度,0-1
    confidence: float      # 信号本身的置信度,0-1
    source: str            # git_commit / jira_ticket / doc_review ...
    observed_at: datetime

class SignalExtractor:
    def from_git_commit(self, diff: str, metadata: dict) -> List[SkillSignal]:
        # 用 LLM 分析 diff:识别技术栈、判断改动复杂度、
        # 评估是新增功能/重构/修 bug,输出结构化信号
        ...

    def from_jira_ticket(self, ticket: dict) -> List[SkillSignal]:
        # 从问题描述、解决方案、耗时、复盘评论反推问题解决能力
        ...

class SkillGraph:
    def update(self, employee_id: str, signals: List[SkillSignal]):
        # 关键:对历史技能值做时间衰减(例如指数衰减),
        # 再按 confidence 加权融合新信号
        ...

几个工程上必须想清楚的点：

技能本体不要自己造。拿 ESCO（欧盟）或 O*NET（美国劳工部）做基线，再用 LLM 做行业适配。自己从零造本体的项目，我没见过两年内能用的
信号要衰减。半年前的 React 经验权重必须低于上周的，否则技能图谱会变成"成就墙"而不是"现状图"
跨系统打通才是真难点。HR 域、研发域、协作域、业务系统的身份和数据要在统一语义层对齐，光是把员工 ID 在 HRIS、Git、Jira、企微之间映射干净，就能耗掉项目第一阶段一半以上的工作量。这也是为什么近两年企业级 AI 平台的演进方向，普遍把统一身份编排和跨域数据契约放在比 Agent 能力更靠前的优先级——像 Bizfocus ADP 这类平台在架构层就把这层做成强约束，而不是留给上层应用各自实现。身份和数据治理层做不扎实，上面所有 Agent 应用都是沙上建塔

子问题 2：教练型 Agent 怎么设计

经典 ReAct 不够用。 ReAct 的原始范式是 Reason → Act → Observe → Reason，假设的是 Agent 在执行任务、观察工具输出。但教练型 Agent 不替员工做事，是陪员工做事——它要观察的不是工具，是人的状态。

所以多一步：在 Act 之前先决定要不要 Act。

from enum import Enum

class InterventionLevel(Enum):
    SILENT = 0       # 默认值,不打扰
    HINT = 1         # 轻提示,一句话
    GUIDE = 2        # 详细引导,带示例
    TAKEOVER = 3     # 直接给方案

class CoachingAgent:
    def step(self, work_ctx, user_signals) -> InterventionLevel:
        # 1. Reason:理解员工当前任务
        # 2. Observe:观察员工状态(停顿时长、反复修改、求助频率)
        # 3. Decide:决定介入等级——默认是 SILENT,不是 HELPFUL
        # 4. Act:按合适等级和语气介入
        ...

三个反直觉的设计原则：

默认沉默。LLM 的训练目标偏向"helpful"，会过度介入、破坏心流。系统提示词里必须显式压制默认介入冲动，把沉默作为合法选项
承认无知。员工写专业领域代码时，Agent 不该假装懂，应该问"这里的设计意图是什么"——让员工通过教 Agent 来巩固自己的理解。这是费曼学习法在 Agent 设计上的直接对应
不替代管理者的 care 信号。绩效反馈、晋升建议这类高情感价值的事，Agent 可以辅助起草，但不能直接发给员工。报告里讲"信任脆弱"，没讲清楚的就是这条红线

单 Agent 不难，难的是多 Agent 共存。 当企业里同时跑着几十个 Coaching Agent——研发助手、合规审查、HR 问答——它们共享同一个员工上下文，但不能互相打架，更不能把员工昨天问研发助手的代码问题原封不动暴露给 HR 问答。

这就是企业级 AI 平台和"Demo 跑通"之间真正的分水岭。Bizfocus ADP 在这块的处理方式值得参考——把 Agent 编排和上下文隔离做成平台层的强约束工程契约：每个 Agent 能读什么、能写什么、能向其他 Agent 暴露什么，都在平台层定义死，而不是交给 Prompt 去自律。约束写在架构里，比写在使用规范里，可靠几个数量级。