最近几年我们一直聚焦于研发 AI 产品，也一直在账号里给大家分享高价值的 AI 开源项目。
这两年我们见证了大模型应用从「简单问答」走向「Agent 执行」，也看着企业知识库从「纯检索 RAG」迭代到结构化知识沉淀。但当两条线交汇到真实业务里，一个新的困境很快浮现：绝大多数 Agent 依然是「会话式临时工」------每次启动都要重新交代背景、重新检索知识、单线程推进任务；而知识库依然是「被动藏书楼」------等人来问才输出答案，不会主动把知识送到业务流程里。
一线团队的体感最为强烈：
- 为了同时推进 Bug 修复、文档更新、工单回复三件事，运营人员要开三个 Agent 会话，分别上传上下文、反复同步进度；
- 同一个设备故障问题，客服问一遍、运维问一遍、车间工人再问一遍，系统每次都从零开始走 RAG 检索链路，Token 花了不少，答案质量还忽高忽低。
我们系统研究了 DeepSeek Harness 团队 10 月底开源的 Super-agent 架构设计与原型实现，结合企业知识库的落地实践，发现它恰恰戳中了当前行业的核心痛点：把「会话管理、任务调度、知识复用」这些本该由系统承担的工作，从用户身上卸下来，交给一层常驻的智能调度体系。
它不是一个新模型，也不是一款开箱即用的成品，而是一套面向下一代企业智能体的架构方法论。
今天这篇文章，从设计思想、核心架构、工作闭环、知识库融合、成本测算、落地方案六个维度做深度拆解，同时讲清楚：什么样的企业值得落地，什么样的场景反而应该再等等。
一、先聊聊 Agent 为什么「记不住、管不好」
很多企业已经完成了第一步：搭好 RAG 知识库，上线了对话式 Agent，员工可以提问查制度、查手册、查工单。上线之初体验惊艳，但运行三个月后，共性问题几乎一模一样。
第一，会话孤岛，上下文断裂。 每个 Agent 会话彼此独立，员工在飞书群里聊过的方案，在工单系统里提问还要再说一遍；上周刚确认过的参数，这周换个入口查询，系统又给了一套新旧混杂的答案。知识和上下文散落在各个会话窗口里，无法形成全局积累。
第二，单线程执行，调度全靠人。 传统 Agent 一次只能做一件事，一个耗时的故障排查任务跑起来，新的咨询就只能排队。员工不得不开多个会话并行推进，自己充当项目经理。行业普遍数据是，一个人最多同时有效管理 3-5 个活跃 Agent 会话。
第三，知识重复检索，算力浪费严重。 同一个高频问题，不同人问十遍，系统就完整走十遍「文档切片 - 向量检索 - 上下文拼装 - 生成答案」的全流程。知识没有被沉淀成可复用的结构化单元，每次查询都从零开始，Token 成本居高不下，答案一致性还无法保障。
第四，始终被动响应，不会主动行动。 现有的知识库和 Agent 全是「触发式」------有人提问才工作，没人提问就闲置。工单系统里堆了新的故障反馈、群聊里反复出现同类疑问、文档里出现了新旧参数冲突，系统永远不会主动发现、主动跟进、主动沉淀。
回过来审视整个架构就会发现：这不是某款产品的问题，而是当前主流 Agent 设计的底层惯性------以单会话为核心的解释执行模式。会话是临时的，执行是同步的，知识是随用随取的，任务结束一切归零。就像传统 RAG 是「每次把原料现做成菜」，传统 Agent 就是「每次开工都重新搭一次临时作坊」。
企业智能体要真正走进生产系统，核心矛盾已经从「能不能调用工具」，变成了「能不能持续积累、并行调度、主动交付」。继续在单会话框架里调 Prompt、加工具，解决不了根本问题。
二、范式转移：从「会话执行」到「常驻调度」
DeepSeek Super-agent 的本质，是把经典的系统设计思想引入了 Agent 领域。它的核心设计哲学可以概括为四个字：常驻调度。
打个最通俗的比方：传统单会话 Agent 像是上门兼职的临时工，你每次找他都要重新说一遍背景、交代一遍要求，他干完这单就走；而 Super-agent 像是企业里常驻的部门主管------他一直在岗，记得所有历史上下文，收到需求后自己拆分任务、分派给对应的执行专员、跟进全流程进度，最后统一给你交付结果。你全程只需要跟他一个人对接。
处理的主体从「单次会话」变成了「常驻系统」，四个核心特性随之发生了本质变化：
- 连续：全局上下文不中断。跨平台、跨会话、跨时间的信息保持一致。你在飞书群里提了初步方案，转头在 GitHub Issue 里补充修改意见，系统能完整承接上下文。会话不再是用户可见的单元，而是系统内部的实现细节。
- 高效 ：多任务并行不阻塞。一个 Router 调度多个 Worker，不同任务在隔离的会话里同时推进。官方实验数据显示：在 300 条消息、20 项工作请求的模拟场景中，Super-agent 任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟；而带子 Agent 工具的单会话方案 p95 达到 29.5 分钟，效率提升接近一倍。
- 主动：从「等指令」到「找事做」。系统持续监听外部事件流------群聊消息、工单更新、代码提交、CI 结果，先通过规则过滤无关信息，再由模型判断是否值得行动。不需要人时刻盯着发指令。
- 持久：离线不中断，异常可自愈。计算、状态、执行环境三者分离，Agent 不会因为用户合上电脑就停止工作。云端负责推理调度，状态独立存储在数据库，本地只保留执行环境。再加上独立的 Watchdog 监督机制，任务死循环、程序故障都能被自动检测并尝试修复，实现 7×24 小时在线运行。
一句话总结：传统 Agent 是「你吩咐一句，它动一下」的工具；Super-agent 是「给它目标和规则，它自己推进落地」的常驻系统。
三、双层核心架构：调度与执行严格分离
Super-agent 的骨架是经典的「Router-Worker 双层分离架构」，再辅以事件驱动、存算分离、监督保障三大支撑机制。
第一层：Router 调度层 ------ 只做总管，不亲手干活
Router 是整个系统的唯一对外接口，所有渠道的消息、事件、请求都先汇聚到这里。核心职责有三项：
- 全局上下文维护：记住所有历史任务、人员偏好、业务规则，保持跨会话、跨平台的记忆连续性；
- 任务分派与路由：理解用户意图，判断任务类型，创建对应的 Worker 实例并下发任务；
- 统一交互交付：汇总 Worker 的执行进度与结果，以统一身份向用户反馈，避免多 Worker 同时说话造成混乱。
最关键的设计原则是：Router 不执行具体任务，甚至可以不配 Bash 等执行工具。就像项目经理不用自己写代码，Router 只做高层决策与协调，因此用轻量级模型就能跑通，大幅降低核心调度链路的成本。它越「轻」，系统的响应速度就越快，并发承载能力就越强。
第二层：Worker 执行层 ------ 隔离并发，专事专办
Worker 是真正干活的执行单元，每个 Worker 对应一个独立的 Agent 会话、独立的工作目录、完整的工具链和专属的上下文。设计遵循三个规则：
- 上下文隔离：不同任务的 Worker 互不干扰，一个任务出错不会影响其他任务；
- 能力差异化：不同类型任务可加载不同的模型、工具集和知识包。比如代码类 Worker 配最强的推理模型和开发工具，知识问答类 Worker 加载专属知识库和检索工具；
- 不直接对外：Worker 不直接和用户对话，所有输出都回传给 Router，统一整理后交付。
这里有一个极易被忽略的精妙设计：模型成本的分层优化。贵的强模型只放在 Worker 层，用在真正需要深度推理的执行环节；而大量的路由、过滤、分类工作，用便宜的轻量模型在 Router 层完成。这和企业知识库「把算力从查询侧转移到沉淀侧」的思路异曲同工------把算力花在真正产生价值的地方。
三大支撑机制
1. 事件驱动与订阅直通 外部所有的消息、通知、状态变更都被统一视为「触发器（Trigger）」。系统采用两级过滤机制：一级过滤用程序规则硬过滤，直接筛掉明显无关的通知、重复消息，减少模型调用量；二级过滤用大模型语义判断，确认事件是否需要响应、属于哪类任务，再交由 Router 分派。
对于已经分配给 Worker 的任务，后续相关的事件会通过订阅直通机制直接发送给对应 Worker，不需要每次都经过 Router 转发。这既降低了 Router 的负载，也减少了中间链路的 Token 消耗。
2. 存算分离与状态持久化 传统本地 Agent 把「计算推理、会话状态、执行环境」三样东西绑在同一台设备上，电脑一休眠全部停摆。Super-agent 把三者彻底拆开：计算层在云端容器运行、可弹性扩缩容；状态层独立存储在数据库，容器重启、设备上下线都不丢失；执行环境层保留在用户设备或企业内网，通过轻量代理和云端通信。这带来两个核心价值：任务可以 24 小时持续推进；状态可追溯、可迁移，任何节点故障都能快速恢复。
3. Watchdog 监督与自愈 作为独立的监督模块，Watchdog 不参与业务执行，只做两件事：故障检测 （监控进程崩溃、接口超时、网络中断并自动尝试恢复）和任务纠偏（判断任务是否陷入无效循环、重复调用工具、偏离原始目标，发现异常时介入打断）。它相当于系统里的安全监理，是持久化运行必不可少的保障机制。
四、六阶段闭环：任务从触发到沉淀的全流程
把「常驻调度」落到工程上，是一个完整的任务生命周期闭环，一共分为六个阶段：
① 事件捕获 Ingest 多渠道事件统一接入，打上来源标签与时间戳，先经过一级规则过滤，剔除垃圾信息、重复通知和明确无关的事件。这一步纯程序执行，不消耗大模型 Token，是成本控制的第一道关口。
② 意图路由 Route 过滤后的事件交给 Router 层，由轻量模型做语义理解：判断事件意图、所属业务领域、是否需要启动任务、分派给哪类 Worker。确认处理后，Router 创建专属 Worker 会话，注入初始上下文、对应工具集和知识权限。
③ 并行执行 Execute Worker 接收任务后，在独立会话内运行异步 ReAct 循环：思考 - 调用工具 - 观察结果 - 下一步行动。多个 Worker 可同时执行不同任务，互不阻塞。这里的关键是异步 ReAct 机制：Worker 执行耗时任务时，Router 依然可以接收新指令、分派新任务，整个系统不会被单个长任务卡住。
④ 状态同步 Sync Worker 定期把执行进度、中间结果、遇到的问题回传给 Router，由 Router 更新全局状态。用户随时可以向 Router 查询所有任务的进度，不需要逐个访问 Worker。
⑤ 冲突校验 Verify 任务执行完成后，结果不会直接交付，而是先经过校验：答案与知识库结论冲突时，不直接覆盖旧知识，而是标记冲突、标注双方来源，生成待审核条目；操作类任务先做合规校验。这是企业级系统的核心设计原则：机器负责发现差异，人负责最终裁定。
⑥ 沉淀迭代 Iterate 任务交付不是终点。系统会把本次任务的有效结论、解决方案、新增知识点自动同步回企业知识库：高频问题的标准答案更新到核心知识页；新的故障案例补充到对应知识条目；低召回、高重复的问题标记为知识缺口。这一步让 Agent 的每一次执行都变成知识库的一次增量更新，形成「执行 - 沉淀 - 复用」的正向循环。
值得细说的两个关键设计：
- 链式召回（Chain of Recall） ：通过 Trigger、Thread、Worker Session 之间的引用关系，让模型沿着关联 ID 逐步找回历史任务的完整信息，不需要把所有历史都塞进上下文窗口。近期高频信息放在上下文里，低频历史按需读取，兼顾效果与成本。
- 事件订阅直通：任务启动后 Worker 直接订阅对应事件流的后续消息。官方测试数据显示，如果取消直通机制，Router 决策次数会增加约 30%，读取缓存的 Token 增加约 37%，成本和延迟都会明显上升。
五、与知识库深度融合：让 Super Agent 拥有企业大脑
Super-agent 解决了「会不会干活、能不能并行」的问题，但企业场景里，决定 Agent 输出质量的核心，依然是它能不能精准、合规地使用企业内部知识。我们推荐采用「核心 - 边缘」分层知识架构，同时适配 Super-agent 的双层调度体系：
核心层：结构化标准知识（高频高价值知识） 把企业最核心、最高频、最稳定的知识------核心产品参数、标准 SOP、常见故障解决方案、制度规范，提前梳理成结构化、带关联、可溯源的标准知识页面，每页带标准元数据头（来源映射、更新时间戳、标签、关联列表），页面之间双向交叉引用。Worker 启动时按任务类型预加载对应领域核心知识，执行时直接读取，无需临时检索；知识带完整溯源链接，输出答案时自动标注来源，满足合规与审计要求。
边缘层：RAG 向量检索（海量低频知识） 海量的历史工单、零散文档、非结构化记录，保留传统 RAG 向量索引作为兜底检索。当核心知识层没有命中答案时，自动降级到向量库补充信息。
调度层：Router 统一知识路由 由 Router 层判断当前任务应该优先用哪类知识、是否需要启动检索，对 Worker 屏蔽底层细节。
在此基础上可以做到三路混合知识召回：标准知识页精准召回（基于实体、概念精准匹配）、知识图谱关联召回（沿预构建关联网络跨文档推理）、向量语义兜底召回（覆盖长尾内容）。
这种「核心沉淀知识 + 检索兜底长尾」的模式，相比纯 RAG 检索，答案准确率提升 20% 以上，同时 Token 消耗减少 60%-80% ------因为绝大多数高频查询都直接复用了预沉淀知识。更重要的是形成了闭环：Agent 执行产生的新经验自动回写到核心知识层，经审核后成为新的可复用知识。
六、拆两段配置：看看落地产物长什么样
下面两段是企业知识库场景下 Super-agent 的典型配置示例。
第一段：Router 层规则配置（AGENTS.md 简化示例）
# Super-agent Router 运行规则
## 事件过滤规则
1. 所有非工作时间的非紧急事件，统一缓存到工作时间处理
2. 包含 [自动通知] [系统日志] 标签的系统消息，直接过滤不进入模型判断
3. 仅白名单内成员的 @ 消息和指定工单事件，可触发任务创建
## 任务分派规则
1. 知识咨询类问题 → 分派给 FAQ-Worker，预加载对应部门核心知识库
2. 故障报修类工单 → 分派给 Ops-Worker，加载运维知识库 + 工单系统工具
3. 文档更新类请求 → 分派给 Doc-Worker，加载文档知识库 + 版本管理工具
4. 无法分类的通用问题 → 先调用知识库检索，再判断是否需要创建专项 Worker
## 回复规范
1. 所有知识类回答必须标注来源知识页面，可点击跳转溯源
2. 任务进度每日同步一次，异常情况立即上报
3. 知识冲突场景必须明确标注不同说法的来源，提示人工审核
大白话解读：这个文件定义了 Router 的所有行为边界。它的价值在于把业务规则和代码解耦------业务流程变了、知识分类改了，只需要更新这份配置。对企业落地来说，可配置的规则体系，比功能多少更重要。
第二段：Worker 知识库对接 Schema（简化示例）
---
worker_type: ops-fault-worker
model: deepseek-v4-pro
knowledge:
core_knowledge:
- entities/空压机机组全系列.md
- concepts/轴承故障诊断标准.md
- entities/二线运维班组.md
rag_scope: 运维工单库-2025~2026
recall_strategy: 核心知识优先 → 图谱关联 → 向量兜底
tools:
- 工单系统查询
- 设备监控数据读取
- 知识页回写提交
rules:
- 故障诊断结论必须引用至少 2 条独立来源
- 新旧参数冲突时，默认展示最新版本，同时标注旧版链接
- 任务完成后，有效解决方案自动提交至知识待审核区
sources:
- 设备运维手册V3.2.pdf
- 2026年Q3故障工单汇总.xlsx
related:
- pending/转速参数冲突-20260827.md
---
大白话解读：这个配置相当于给每个 Worker 配好了「专属工具书 + 操作规范 + 作业权限」。Worker 启动即获得对应领域的核心知识，不用每次从零检索；输出有明确规则约束；产生的新结论会自动回流知识库，完成沉淀。
七、关键共识：不是替代，而是分层协同
必须明确：Super-agent 不是要替代现有的 Agent 产品，也不是要推翻 RAG 知识库，而是在现有体系之上增加一层常驻调度与知识运营能力。
- 与传统单会话 Agent 的关系 ：传统对话 Agent、代码 Agent 是执行工具，擅长单点任务的深度执行；Super-agent 是调度系统，负责管理多个执行单元、维护全局上下文、串联业务流程。前者是「手」，后者是「脑」。落地时完全可以把现有 Agent 作为 Worker 接入。
- 与传统 RAG 知识库的关系 ：RAG 解决「知识能不能被找到」，本质是被动检索；Super-agent 解决「知识能不能被用好」，本质是主动应用。没有好的知识库，Agent 就是无源之水；没有 Agent 的主动调用，知识库就是沉睡的资产。
- 与结构化知识沉淀的关系 ：结构化沉淀做「知识生产侧」的优化，把算力花在摄入整理阶段；Super-agent 做「知识应用侧」的优化，把算力花在调度执行阶段。两者结合形成「原始资料 → 结构化沉淀 → Agent 调度执行 → 结论回写更新」的完整闭环。
采用这种「核心结构化知识 + Super-agent + RAG 兜底」的混合架构，企业可以同时获得三重收益：高频知识复用的成本下降、常驻调度的效率提升、知识沉淀的长期资产增值。行业项目初步测算显示，相比纯对话式 RAG 方案，混合架构的综合运营成本可下降 40% 以上，任务处理效率提升 50% 以上。
八、算一笔企业最关心的账：落地成本与 ROI
分两种主流部署模式算一笔细账，也讲清楚成本的前提和可调旋钮。
模式一：API 调用模式（中小团队首选）
所有模型推理走云端 API，企业只需部署调度服务和知识库，不需要自建 GPU 集群，门槛最低、试错成本最小。
- 模型 Token 成本：Router 层用轻量模型（如 DeepSeek-V3-Flash），单月消耗通常数百万 Token 级别，成本约几十美元；Worker 层用强模型（如 DeepSeek-V4-Pro），得益于核心知识预沉淀，单次任务 Token 消耗比纯 RAG 模式降低 60% 以上。
- 参考公开定价 ：DeepSeek 缓存命中输入仅 0.0028/1MToken，非缓存输入0.14 / 1M Token，输出 $0.28 / 1M Token。中等规模团队（日均 50 个任务）月度模型成本通常在 100-300 美元，仅为纯强模型单会话方案的 1/3 到 1/5。
- 服务与存储成本：调度服务月度约 20-50 美元；状态存储 + 向量库月度约 10-30 美元。
- 总投入：中小团队 API 模式落地，月度综合成本约 130-380 美元（约人民币 900-2700 元）。
模式二：私有化部署模式（中大型企业 / 强数据合规要求）
模型推理全部在企业内网完成，数据不出域，适合金融、制造、政务等对数据安全要求高的行业。
- 硬件算力投入：入门级（10 人以内、并发 5 个 Worker 以内）单张 RTX 4090（24GB 显存）可承载 7B-14B 量化模型，约 2 万元人民币；部门级（50 人、并发 20 个 Worker）2 张 A100 80GB 或等效算力，约 30-50 万元；企业级（百人以上）GPU 集群方案，百万级起步。
- 运维与开发成本：需要 1-2 名技术人员负责部署运维，1 名专职运营人员负责知识治理与人工审核。
- 隐性成本 ：Agent 任务是脉冲式的，高峰并发、低谷闲置，纯本地部署算力利用率通常不足 40%。建议核心敏感知识 + 轻量路由模型本地化，非敏感长尾任务弹性调用云端 API。
成本的三个可调旋钮
- 核心知识沉淀比例：标准化的核心知识越多，运行时检索和 Token 消耗越低，但前期整理成本越高；
- 事件主动程度：主动监听的事件源越多、判断越频繁，算力消耗越高；可以从「仅响应显式指令」起步；
- 人工审核范围：全量审核人力成本高，仅审核高风险操作和知识冲突，性价比最高。
核心前提：这笔账成立的基础是「任务复用率」。同类任务被反复执行、同类知识被反复调用时，预沉淀知识和常驻调度的成本才会被摊薄。如果业务场景极其分散、每个任务都是一次性的，传统单会话 Agent 反而更划算。
九、哪些企业适合落地 Super Agent 知识库
制造与运维企业：运维知识库、设备手册、故障工单是核心资产。落地价值：自动监听工单系统，新故障工单自动匹配知识库、生成诊断方案、同步给运维人员；故障解决后方案自动沉淀。设备维修平均耗时可缩短 30% 以上。
科技研发企业：文档、Issue、代码、方案散落各处。落地价值：自动监听代码仓库和研发群，Issue 自动检索历史方案、生成修复建议，研发结论自动同步更新知识库，知识沉淀效率可提升 80% 以上。
客服与运营企业：FAQ、工单体系庞大，重复咨询占比高。落地价值：7×24 小时监听咨询渠道，高频问题自动回复，复杂工单自动流转跟进，客服人均处理量可提升 40% 以上。
职能与行政企业：制度繁多，员工反复咨询同类问题。落地价值：作为统一智能入口承接制度咨询、流程办理，制度更新自动同步知识库，落地门槛低、见效快。
反过来，如果业务符合以下特征，暂时不建议仓促上车：知识更新极快、每天大量全新内容；任务高度个性化、几乎没有重复；团队没有技术运维能力，也没有持续运营知识库的人力。技术选型从来不是选「最先进」，而是选「最匹配」。
十、落地实践：四种开源方案的优缺点对比
方案一：官方原型直接用 ------ dsh-superagent-prototype DeepSeek 官方同步开源的研究原型，基于 DeepSeek Harness 构建，MIT 协议。优点：架构最贴合官方设计思想，Router-Worker 双层结构、事件订阅、Watchdog 等核心机制都有实现，代码轻量、易于学习；局限：明确标注为研究原型、非生产级，仅支持 GitHub + 飞书两个事件源，没有企业级权限、审计、多租户能力，沙箱安全机制不完善。适用：技术预研、小范围试点验证，不建议直接用于核心生产环境。
方案二：基于 DeepSeek Harness 二次开发 DeepSeek Harness 是官方推出的插件化 Agent 框架，一切能力皆插件。优点：插件化架构灵活度极高，可扩展企业微信、钉钉、工单系统等内部事件源；模型无关，可切换 DeepSeek、Qwen 等；可定制知识库对接逻辑。局限：框架仍处快速迭代期，部分接口可能变动；企业级特性需自行开发。适用：有自有技术团队、定制化需求高的中型企业，是目前性价比最高的落地路径。
方案三：基于通用 Agent 框架自建双层架构 利用 LangGraph、Dify 等成熟框架，自行实现 Router + Worker 双层架构。优点：生态成熟、文档完善、周边工具丰富，Dify 自带可视化界面与 RAG 能力，LangGraph 有完善的状态持久化与 checkpoint 机制。局限：需自行实现 Router 路由、事件订阅直通、Watchdog 等核心机制，架构贴合度不如原生方案。适用：已经在用这些框架、希望逐步升级的企业。
方案四：一体化知识库产品 + Agent 平台 选用自带 Agent 能力的企业知识库产品，在产品内配置常驻调度任务，开箱即用。优点：知识库能力成熟，可视化配置、技术门槛低，自带权限、审计、多租户等企业级特性。局限：架构深度绑定产品，定制化空间有限。适用：没有充足技术开发资源、需要快速落地验证的中小团队。
实践建议：小团队先从方案四起步验证业务价值；有技术能力的团队用方案二做深度定制；已经有 Agent 体系的企业用方案三逐步升级；方案一更适合技术调研和原型验证，不直接上生产。
最后复盘一下
回到开头那个核心问题：「Agent 为什么记不住、管不过来？」
Super-agent 给出的答案是：让系统学会常驻------把会话管理从用户侧移到系统侧，把知识处理从查询时移到沉淀时，把任务执行从单线程改成并行调度，把被动响应变成主动推进。
它不是银弹，不能解决所有问题，也替代不了高质量的知识内容和持续的运营投入。但它代表了一个清晰的趋势：企业智能体正在从「以对话为中心」转向「以任务为中心」，企业知识库正在从「以检索为中心」转向「以知识沉淀与应用为中心」。
未来的企业知识系统，不会是一个等着人来提问的静态仓库，而是一套 7×24 小时运行、主动发现问题、自动调度执行、持续沉淀资产的智能协作体系。知识库是它的大脑，Super-agent 是它的神经，二者结合，才能让知识真正变成生产力。
如果你也在探索下一代企业知识库与智能体的落地路径，不妨从一个小场景、一个部门开始试点------这条路越早走，知识资产的复利效应就越明显。如果对这套「常驻调度 + 核心-边缘知识架构」有想交流的实现细节，欢迎一起探讨。