从研发增效到流程优化——企业私有化 Agent 架构方案与推演

当多数企业还在纠结选豆包、千问还是WorkBuddy时，这家千人研发企业却选择自建Agent底座。本文完整拆解其技术架构：以OpenViking为上下文核心，通过虚拟文件系统、分层加载与目录级ACL，实现记忆、资源、技能的统一管理与权限映射，并给出可落地的算力估算模型。

背景：Agent赋能的三期战略

这是一家千人规模、以研发为主的中型企业，Agent 底座建设启动前，基础设施已经就位：

• 研发人员约 350 人，是 Agent 的第一使用人群；
• 自建权限中台：已做到最小颗粒度的操作权限（谁能执行什么动作）和数据权限（谁能访问哪些数据），是公司统一的鉴权权威；
• 私有化网盘：第三方网盘已私有化部署，沉淀了大量业务文档、SOP、技术资料，是现成的知识库资源层；
• 自有机房：算力统一规划、自主掌控；
• IM 双轨：研发和全员以钉钉为主，企业微信仅销售条线使用，本次研发侧以钉钉为准。

在路线确定阶段，决策层也评估了豆包工作、千问办公、WorkBuddy 等成熟的办公 Agent 方案。按 2026 年下半年的实际格局：

WorkBuddy（腾讯）3 月上线后规模领跑，10 月数字生态大会上宣布开放平台，已支持接入第三方 IM 与企业自研 Agent；

千问办公（阿里）8 月公测，以钉钉生态为主，也已宣布接入企业微信；豆包工作（字节）与飞书深度打通。

9 月起以「豆包工作伙伴」的形态做团队级智能体。

开放程度确实在快速提升，但三家对私有化部署的支持均不完整、无法挂载私有化网盘作为知识层——数据、上下文与算力难以全部留在自有机房。结合已有基础设施与长期演进规划，最终确定走自建路线。

决策层同时定下了清晰的三期战略，能力逐级跃迁：

一期，把 Agent 当工具，为研发增效；

二期，让 Agent 介入并串联研发流程；

三期，用 Agent 沉淀的运行数据，反哺和优化研发流程。

需要说明的是，本文定位为方案设计与推演：三期为规划中的路线，文中算力与并发数字均为推导值而非实测值，落地节奏以试点数据为准。

一、技术选型

关于开源协议：OpenViking 服务端采用 AGPLv3（CLI 与示例代码为 Apache 2.0）。合规策略是不改其源码、仅通过 MCP/REST/CLI 标准接口调用原生能力——进程外的接口调用不构成派生作品，应用侧代码不触发 AGPL 第 13 条的网络交互源码披露义务；即使未来需要深度定制，也优先以独立插件、独立服务的方式扩展，不修改其进程内代码。该结论在上线前交法务复核备案。

二、技术架构

整套系统分六层，自上而下依次为接入层、编排层、鉴权层、记忆/上下文层、资源层、算力调度层：

必须坚持的三条原则：

1. 权限中台是唯一鉴权权威，OpenViking 的目录 ACL 只做映射，不另起一套权限；
2. 网盘以挂载方式接入，不改变原有存储、不另建知识库；
3. 模型经网关统一接入，记忆层定位为可替换组件，任何一层都不被单一方案锁死。

三、OpenViking 为什么是整个架构的核心

如果说 Dify 是流程的「大脑」，OpenViking 就是让 Agent 真正具备长期记忆、能消费企业知识的「上下文底座」。这一层做不好，Agent 就永远停留在「一问一答、用完即忘」的阶段，无法支撑二期串联、三期优化。它的能力可以从五个机制看清。

3.1 viking:// 虚拟文件系统：把记忆、资源、技能统一成文件

OpenViking 用一个虚拟文件系统（VFS），把三类东西统一抽象为文件：

• Memory（记忆）：情景记忆、语义记忆；
• Resource（资源）：网盘文档、资料；
• Skill（技能）：可复用的流程与能力，即程序记忆。

Agent 用 ls / tree / read / write 这样的文件操作来导航和调用，保留了文档原本的层级与上下文，而不是把知识切成黑盒里的向量碎片。这意味着 Agent 对知识的理解是「有结构、可追溯」的，而不是模糊的语义命中。

3.2 L0/L1/L2 分层加载：长任务不爆 Token

长流程最怕上下文撑爆窗口。OpenViking 把每份资源做成三层，按需下钻：

• L0 目录概览：先看整体结构，判断去哪找；
• L1 文档摘要：读摘要，确认是否相关；
• L2 原文：只在真正需要时加载完整内容。

这种「先概览、再摘要、后原文」的加载方式，让 Agent 在跨环节的长任务里始终保持轻量上下文，是二期串联长流程的前提。

3.3 原生目录级 ACL：检索全程鉴权

这是 OpenViking 最关键的能力，也是它能直接对接自建权限中台的原因。它的目录天然带 ACL，检索全程同步鉴权：

• 发起任务时，权限中台先校验身份；
• 检索时按权限裁剪目录，无权限的内容在源头就不进结果；
• OpenViking 的 ACL 与权限中台做映射，不另起一套权限；
• 权限中台的变更以事件驱动实时同步到目录 ACL；同时保留兜底——检索命中后回源权限中台二次校验，同步滞后的窗口内一律按无权限处理（fail-closed），宁可误挡、不可越权。

检索与鉴权是耦合的，从机制上保证「Agent 只能看到这个人本来就有权看的东西」，这是企业级数据安全的底线。

3.4 会话归档与记忆自迭代

会话结束时，OpenViking 会自动完成一条记忆沉淀链路：

commit 归档 → 按类型抽取结构化条目（时间、主体、诉求、承诺、分歧、未决问题）→ LLM 合并去重 → 写回记忆目录。

长期来看，它还会对同主题的情景记忆聚类归纳，达到一定门槛（跨多个场景、积累足够条目）才升级为语义记忆，或沉淀为可复用的 Skill（程序记忆），并保留来源链接。这让记忆库不是静态堆积，而是能自我进化、长期保鲜。

记忆的权限继承同样有明确规则：个人会话沉淀的记忆写入个人命名空间（viking://user/{id}/），不进入共享检索面；员工离职时，其岗位相关的记忆可由接手的新员工继承，保证知识不随人走；个人沉淀出的 Skill 默认私有，经审批发布后才进入公共 Skill 目录，供团队复用。

3.5 开放接入：可被编排层和外部工具调用

OpenViking 同时提供 MCP、REST、CLI 三种接入方式，Dify 可以通过标准接口调用它，外部 IDE、工具也能接入。正因为接口开放，它在整个分层架构里是一个可替换、可演进的组件，而不是新的锁定点。

小结：OpenViking 不是一个简单的存储，而是同时承载「记忆组织、分层加载、权限映射、知识挂载、记忆进化」的上下文底座。三期战略里，一期靠它消费网盘知识，二期靠它维持跨流程上下文，三期靠它沉淀结构化运行数据——它是贯穿三期的那一层。

四、算力规划与资源估算

4.1 估算模型

关键假设：

• 研发 350 人，日活率 60%，峰值并发率 15%；
• 本地部署 32B 量级量化模型（Qwen / DeepSeek 蒸馏版），配合 vLLM 连续批处理；
• 单卡承载约 10 个活跃 Agent 会话；
• 靠优先级队列削峰，不按瞬时峰值满配。

推导：

• 峰值并发 = 350 × 60% × 15% ≈ 32 个并发会话；
• 推理卡 = 32 ÷ 10 ≈ 3.2，加上 N+1 高可用冗余 → 5 张；
• 需要说明：32 个并发会话不等于 32 路同时解码。Agent 任务是「生成—调用工具—等待—再生成」交替进行，真正同时处于解码状态的大约 8–12 路；而 32B 量化模型在 L20 上的单卡聚合输出受显存带宽约束，vLLM 连续批处理下典型约 30–45 tokens/s，五卡合计约 200 tokens/s——覆盖 8–12 路并发解码是自洽的，代价是单流输出被压到 8–10 tokens/s 量级。对以异步产出为主的 Agent 任务（报告、用例、代码建议初稿）可接受；交互式问答的高峰期则交给 5.3 的优先级队列消化，并给出预期等待时间，而不是为极端峰值满配算力。

4.2 配置清单

推理卡选择英伟达 L20 48G 商用卡：一是 48G 显存对 32B 量化模型足够，二是 L20 为推理专用卡、国内有现货采购渠道；不采用消费级显卡（如 RTX 4090），以规避稳定性与驱动适配问题。

4.3 分阶段扩容

一期试点 250 人，峰值约 23 并发，推理卡先配 3–4 张即可；全量 350 人、任务变重后再扩到 5 张。先按「平均负载 + 可接受等待」配置，用队列吸收峰值，而不是一上来就为极端峰值买单。

五、任务调度与算力治理

350 人共享 9 张卡，必须有一套治理机制，否则算力会被无序抢占。

5.1 GPU 池化与负载均衡

把所有 GPU 抽象成一个统一资源池，任务不绑定具体卡，由调度层动态分配。单卡故障时任务自动迁移到其他卡，配合 N+1 冗余保证高可用。

5.2 任务重要度打分与领导层权重

每个任务进入队列前先打分，分数由两类因子决定：

• 任务重要度：业务影响面、是否关键路径、是否涉及生产；
• 身份权重：关键岗位、领导层发起的任务给予加权。

判据要明确：权重只影响「排队顺序」，不意味着可以无限制占用资源——高权重任务优先，但仍受配额约束，防止个别任务长期霸占算力。

5.3 优先级排队、等待与抢占

不追求所有请求即时响应，而是用优先级队列削峰：

• 高优先级任务插队，低优先级任务进入等待；
• 资源紧张时，允许高优先级任务抢占低优先级任务，但被抢占的任务要保存现场、断点续跑，而不是直接失败；
• 对等待中的任务给出可见的预期排队时间，避免发起方无感知地干等。

5.4 配额、限流与成本可观测

• 按团队/个人设置配额和限流，防止单个入口把池子打满；
• 全链路记录每个任务的 token 消耗、卡时占用、排队时长，成本可归因到具体团队；
• 有了可观测数据，后续扩容和配额调整才有依据，而不是凭感觉加卡。

5.5 人工干预：插队、暂停与终止

自动调度之外，必须保留运维和管理员的人工干预入口，以应对紧急任务和异常情况：

• 手动插队：管理员可将指定任务直接提到队首，或调整任意任务的优先级，不受自动打分限制；
• 暂停与恢复：可对运行中的任务执行暂停，释放其占用的算力，待需要时再恢复，现场保留、不丢进度；
• 手动终止：对失控或误发起的任务可立即终止，并释放全部资源；
• 操作留痕：所有人工干预动作记录操作人和原因，纳入审计，避免人工调度变成无序操作。

一期：研发增效，把 Agent 当「工具」

一期的目标很克制——只做增效，不碰流程。 典型场景：

• 代码问答与技术检索：基于网盘里的技术文档和代码库，回答「这个模块怎么用」「这个报错怎么解」。代码库不走网盘挂载，而是以只读资源方式经 OpenViking resources 导入（其本身支持 add-resource 直接拉取 Git 仓库）；
• 知识检索：快速定位 SOP、规范、历史方案，减少重复问人；
• 测试用例生成：根据代码和需求描述，辅助生成测试用例初稿；
• 代码评审辅助：检查常见问题、给出修改建议，作为评审的补充而非替代。

边界必须守住：一期以只读、建议为主，Agent 不直接改代码、不触发任何流程动作，所有产出由人确认后采用。衡量效果看具体效率指标——检索耗时、重复提问减少、用例编写时间等，用数据说话。

二期：串联研发流程，Agent 从「工具」变「流程节点」

二期让 Agent 真正嵌入研发全链路，串联需求→开发→评审→测试→发布→运维各个环节，跨系统调用工具、传递上下文。

这一阶段最关键的是人机审批边界，要逐环节定义清楚：

• 哪些动作 Agent 可以自主完成（如信息汇总、草稿生成、环境检查）；
• 哪些动作必须人工审批后才能执行（如合并代码、触发发布、变更生产配置）。

同时要解决状态管理与断点续跑：一个跨环节的长流程会持续几十分钟到数小时，中间可能等人审批、可能遇到工具调用失败，必须持久化流程状态，支持从断点继续，而不是一中断就从头再来。

三期：反哺优化流程，Agent 从「流程节点」变「参谋」

前两期 Agent 在跑流程的同时，会沉淀下大量运行数据：每个环节的耗时、返工次数、阻塞点、审批等待时长、缺陷分布。

这些数据过去散落在各个系统里没人分析，现在可以从中发现流程的真实瓶颈——比如某个环节平均等待过长、某类需求返工率异常高。然后形成优化闭环：

运行数据 → 瓶颈洞察 → 优化建议 → 小范围验证 → 固化为新流程。

边界同样要明确：Agent 是「参谋」不是「决策者」。它负责发现问题、给出建议和数据支撑，但是否调整流程、怎么调整，最终由人来拍板。