7.7
深览指数
科技人人都是产品经理·杨衡··AI 生成
从研发增效到流程优化——企业私有化 Agent 架构方案与推演
一家350人研发规模的企业放弃WorkBuddy、千问办公等成熟方案，选择自建Agent底座，理由是三家对私有化部署支持不完整、无法挂载私有化网盘作为知识层。文章给出六层架构（OpenViking为上下文核心）、5张L20卡的算力推导模型与优先级队列治理机制，并把三期路线定义为「工具→流程节点→参谋」。定位为方案推演，算力与并发数字为推导值。原文 ↗
核心观点
- ▍企业自建Agent底座而非采购成熟办公Agent，核心卡点是私有化：WorkBuddy、千问办公、豆包工作虽在2025年下半年纷纷开放生态，但对私有化部署支持不完整，无法把私有化网盘挂载为知识层，数据、上下文与算力难以全部留在自有机房。
- ▍OpenViking是贯穿三期战略的上下文底座：一期靠它消费网盘知识，二期靠它维持跨流程上下文，三期靠它沉淀结构化运行数据；它同时承载记忆组织、分层加载、权限映射、知识挂载、记忆进化五种能力。
- 01OpenViking的viking://虚拟文件系统把Memory（情景/语义记忆）、Resource（网盘文档）、Skill（程序记忆）统一抽象为文件，Agent用ls/tree/read/write导航，保留文档层级与上下文，而非切成向量碎片。
- 02L0/L1/L2分层加载（目录概览→文档摘要→原文）按需下钻，解决长流程上下文撑爆窗口的问题，是二期串联跨环节长任务的前提。
- 03原生目录级ACL与自建权限中台做映射而非另起一套权限：检索时按权限裁剪目录，无权限内容源头不进结果；并以事件驱动实时同步，同时保留fail-closed兜底——同步滞后窗口内一律按无权限处理，宁可误挡不可越权。
- 04会话归档链路为commit归档→按类型抽取结构化条目（时间、主体、诉求、承诺、分歧、未决问题）→LLM合并去重→写回记忆目录；同主题情景记忆聚类积累到门槛后才升级为语义记忆或Skill，并保留来源链接。
- 05算力估算：350人×60%日活×15%峰值并发≈32个并发会话，单卡承载约10个活跃会话，需3.2张卡，加N+1冗余配5张L20 48G；但真正同时解码的仅8–12路，32B量化模型五卡合计约200 tokens/s，单流被压到8–10 tokens/s，靠异步产出场景与优先级队列消化。
- 06AGPLv3合规策略：不改OpenViking源码，仅经MCP/REST/CLI进程外接口调用，主张不构成派生作品、不触发第13条网络交互源码披露义务；深度定制优先做独立插件或独立服务，该结论上线前交法务复核备案。
- 07GPU治理保留人工干预入口：管理员可手动插队、调整任意任务优先级、暂停运行中任务释放算力、手动终止失控任务，所有操作记录操作人与原因并纳入审计。
反方 / 局限
- — 作者自述本文为方案设计与推演：三期是规划中路线，文中算力与并发数字均为推导值而非实测值，落地节奏以试点数据为准——单卡承载10个活跃会话、32B量化模型30–45 tokens/s等关键假设缺乏实测支撑。
- — 把成熟办公Agent的生态开放趋势与自建方案对立起来时，文章未评估采购方案加定制开发的总拥有成本，也未讨论自建后持续的模型迭代、上下文工程与运维人力投入。
- — 单流输出被压到8–10 tokens/s、峰值靠排队而非满配算力，意味着交互式问答高峰期用户体验会明显劣化；作者承认这一点但只给出预期等待时间与队列削峰的缓解，未量化可接受的等待上限。
OpenVikingviking:// 虚拟文件系统L0/L1/L2 分层加载AGPLv3DifyWorkBuddy（腾讯）千问办公（阿里）豆包工作（字节）钉钉企业微信英伟达 L20 48GvLLMQwen / DeepSeek 蒸馏版 32BMCP杨衡
13 分钟 · 5 卡片 · 11 资料
读原文 →