企业级智能体架构：常驻调度与知识复用实践

一、从”会话式临时工”到”常驻调度体系”

过去两年，大模型应用经历了从简单问答到 Agent 执行的演进，企业知识库也从纯检索 RAG 迭代到结构化知识沉淀。但当两条技术线交汇到真实业务场景中，一个结构性困境逐渐浮现：

智能体侧，绝大多数 Agent 仍是”会话式临时工”——每次启动都要重新交代背景、重新检索知识、单线程推进任务。运营人员要同时推进缺陷修复、文档更新、工单回复三件事，就得开三个独立会话，分别上传上下文、反复同步进度。

知识库侧，系统仍是被动”藏书楼”——等人来问才输出答案，不会主动把知识送到业务流程里。同一个设备故障问题，客服问一遍、运维问一遍、现场人员再问一遍，每次都要从零走一遍完整的检索链路，Token 消耗居高不下，答案质量还忽高忽低。

这两个问题的本质是：本该由系统承担的会话管理、任务调度、知识复用工作，被转嫁给了用户。要解决它，需要的不是更强的模型，而是一层常驻的智能调度体系。

二、核心架构：三层解耦设计

常驻式智能体架构的核心思想是将系统拆分为三个解耦层：

┌─────────────────────────────────────────┐
│           接入层（多渠道入口）            │
│   即时通讯 / 工单系统 / 内部知识门户      │
└────────────────────┬────────────────────┘
                     │
┌────────────────────▼────────────────────┐
│         调度层（常驻智能调度器）          │
│  · 会话生命周期管理                      │
│  · 任务队列与优先级调度                  │
│  · 上下文快照与跨会话继承                │
│  · 知识主动推送触发器                    │
└────────────────────┬────────────────────┘
                     │
┌────────────────────▼────────────────────┐
│         知识层（结构化知识底座）          │
│  · 向量检索 + 结构化查询混合             │
│  · 知识版本管理与时效标注                │
│  · 实体关系图谱                          │
│  · 检索结果缓存与复用                    │
└─────────────────────────────────────────┘

2.1 调度层：常驻进程与任务编排

调度层是整个架构的中枢，它以常驻服务的形式运行，不随单次会话的结束而销毁。核心模块包括：

会话管理器：为每个用户或业务实体维护长期会话状态。当用户在即时通讯工具中讨论过的方案，后续在工单系统中提问时，调度器能够将相关上下文注入新会话，避免重复交代背景。

任务队列：支持多任务并行推进。运营人员提交”修复缺陷””更新文档””回复工单”三个任务后，调度器将其放入不同优先级的队列，分别调度执行，并定期汇总进度。

上下文快照：在关键决策点自动保存上下文状态，形成可回溯的快照链。当新任务与历史任务相关时，调度器按需加载快照，实现跨会话的知识继承。

一个简化的任务调度伪代码示意：

class ResidentScheduler:
    def __init__(self, knowledge_base):
        self.kb = knowledge_base
        self.session_store = SessionStore()
        self.task_queue = PriorityQueue()
    def submit_task(self, user_id, task_desc, context_hint=None):
        # 恢复用户历史上下文
        history = self.session_store.load_recent(user_id)
        # 检索相关知识（带缓存）
        knowledge = self.kb.query_with_cache(
            task_desc, 
            context=history + (context_hint or [])
        )
        # 创建任务并投入队列
        task = Task(
            desc=task_desc,
            context=history,
            knowledge=knowledge,
            priority=self._infer_priority(task_desc)
        )
        self.task_queue.put(task)
        return task.id
    def run_forever(self):
        while True:
            task = self.task_queue.get()
            result = self._execute(task)
            self.session_store.append(task.user_id, result)
            # 触发知识主动推送
            self._maybe_push_knowledge(task, result)

2.2 知识层：从被动检索到主动服务

知识层的关键升级在于两点：

检索结果缓存与复用。同一设备故障问题被不同角色反复询问时，系统不必每次都走完整的向量检索链路。调度层在首次检索后，将结果按语义指纹缓存；后续相似查询直接命中缓存，仅做少量增量检索。这能显著降低 Token 消耗。

知识主动推送。当调度器检测到某个业务事件（如工单创建、设备告警）时，可以主动触发知识检索，将相关文档、历史处置方案推送到对应流程中，而不是等人来问。

2.3 接入层：多渠道统一入口

接入层负责将来自即时通讯、工单系统、内部知识门户等不同渠道的请求统一标准化，交给调度层处理。用户在不同入口的操作共享同一套会话状态和知识上下文。

三、工作闭环：一次设备故障的完整流转

以”某设备故障”为例，展示常驻架构下的工作闭环：

1. 客服提交工单：调度器接收请求，从知识层检索该设备型号的历史故障记录与处置方案，生成初步回复建议。
2. 运维介入：运维人员在另一渠道查看同一工单时，调度器已将客服会话中的关键信息（设备编号、故障现象）注入当前上下文，无需重复描述。
3. 现场人员确认：现场人员通过移动端查看处置步骤时，系统推送的是经过运维确认的最新版本，而非知识库中的旧版文档。
4. 知识沉淀：处置完成后，调度器将本次故障的新增信息（实际原因、有效步骤）写回知识层，更新实体关系与文档版本。

整个过程中，知识只被完整检索一次，后续均为增量复用；上下文在角色间无缝传递；知识库在服务过程中自动完成更新。

四、成本测算与落地评估

4.1 成本结构变化

传统会话式 Agent 的成本主要集中在重复检索和上下文重建上。常驻架构通过缓存复用和上下文继承，可将这两部分开销显著降低。实际降幅取决于业务场景的重复度——重复度越高，收益越明显。

4.2 适合落地的场景特征

• 多角色协作频繁：同一问题需要多个角色先后处理
• 知识重复查询率高：相似问题在不同时间、不同入口被反复提出
• 任务并行度高：单个用户需要同时推进多项工作
• 知识更新频繁：需要确保各渠道获取的信息一致且最新

4.3 建议暂缓的场景

• 业务问答高度一次性、无重复模式
• 知识库规模极小，检索成本本身很低
• 组织尚未完成基础 RAG 知识库建设
• 对实时性要求极高、无法接受调度层引入的少量延迟

五、总结

常驻式智能体架构不是一个新模型，而是一套面向企业智能体的架构方法论。它的核心价值在于：把会话管理、任务调度、知识复用这些本该由系统承担的工作，从用户身上卸下来，交给一层常驻的智能调度体系。

对于已经完成 RAG 知识库建设、且业务中存在明显多角色协作与知识重复查询的企业，这套架构值得认真评估。落地时建议从单一高频场景切入，先验证调度层与知识层的协同效果，再逐步扩展到更多业务流程。