陌陌开源了 LinkWork灵工一个企业级 AI Agent 平台。本文从技术架构一岗位一镜像、三层能力边界、MCP 工具总线、部署方式Docker Compose / K8s、与 Dify 和 DeerFlow 的对比、适用场景等角度做深度解读。适合正在调研企业 AI Agent 方案的技术团队。目录前言一、灵工到底做了什么1.1 定位1.2 核心特性二、技术架构拆解2.1 整体架构2.2 六大组件2.3 一岗位一镜像2.4 三层能力边界2.5 安全机制三、部署指南3.1 Docker Compose开发环境3.2 Kubernetes生产环境3.3 踩坑记录四、跟 Dify 和 DeerFlow 对比五、适用场景六、总结七、参考资料前言上周刷 GitHub 的时候看到陌陌科技momotech开源了个新项目叫 LinkWork,中文名叫灵工。一开始以为是什么灵活用工的SaaS点进去一看是个企业级 AI Agent 平台。Apache 2.0 协议6个核心组件全部开源。看了半天文档和代码发现它跟目前市面上的Dify、DeerFlow这些走了条完全不同的路。一、灵工到底做了什么1.1 定位用官方的话说“让 AI 像员工一样工作”。不是让 AI 回答问题,而是让 AI 交付成果。你在系统里定义岗位、分配技能、设定权限,AI 就按岗位职责干活。干完的东西直接推到 Git 仓库或者对象存储里跟真实员工的产出管理是同一套逻辑。1.2 核心特性特性说明岗位模板化管理统一定义职责、人设、Skills 与工具权限容器级隔离运行每个 AI 员工在独立 K8s 容器中运行Skills 版本锁定声明式能力模块,构建时注入岗位镜像MCP 工具总线兼容 MCP 协议,统一代理、鉴权、计量Git/OSS 双通道交付结果直接进入研发流程或归档全链路审计LLM 调用、命令执行、工具请求统一留痕定时排班基于 cron 的无人值守执行二、技术架构拆解2.1 整体架构用户 / API │ ▼ linkwork-webReact 前端 │ REST / WebSocket ▼ linkwork-server核心调度引擎 ├──→ Skills Engine声明式 · 版本锁定 · 构建时内嵌 ├──→ linkwork-mcp-gateway → MCP 工具生态 ├──→ K8s 集群 │ ├── linkwork-agent-sdkAgent 运行时→ LLM │ └── linkwork-executor安全执行器 └──→ 任务分发 → 容器内执行 → 结果交付Git/OSS2.2 六大组件// 组件清单typeLinkWorkComponentsstruct{Serverstring// 核心后端: 任务调度、岗位管理、审批Executorstring// 安全执行器: 容器内命令执行、策略引擎AgentSDKstring// Agent运行时: LLM引擎、Skills编排、MCP集成MCPGatewaystring// MCP工具网关: 发现、鉴权、用量统计Backendstring// 后端应用: Spring Boot, 镜像构建、任务编排Webstring// 前端: React, 任务面板、岗位配置、Skills市场}2.3 一岗位一镜像这是灵工最核心的设计。跟大部分 Agent 平台运行时动态加载不同,灵工的做法是# 岗位构建流程伪代码build_workstation:step_1:注入 Skills 包# 版本锁定step_2:生成 MCP 工具描述# 静态化step_3:打包安全策略# 不可运行时修改step_4:版本快照# 可回溯step_5:构建 Docker 镜像# 固化# 运行时runtime:mode:read-only# 镜像只读fail_fast:true# 任一步骤失败则中断这意味着Skills 在构建时就锁死版本,运行时不能临时装新的安全策略也是构建时打包,不能绕过每个岗位的运行环境完全隔离、完全可复现2.4 三层能力边界岗位 (Workstation) └── Skills (声明式技能模块) └── 工具 (MCP Tools)灵工不是管AI能不能调工具而是管这个岗位的AI有没有资格用这个工具。三层嵌套的权限模型让你可以精确控制每个 AI 员工的能力边界。2.5 安全机制# 灵工的安全架构简化示意classSecurityArchitecture:# 1. 默认网络关闭 - 要用得开白名单network_defaultdeny_all# 2. 执行与安全进程分离executor_processsandboxedsecurity_proxyindependent# AI对此无感知# 3. 高风险操作审批dangerous_commands[rm -rf,DROP TABLE,...]approval_requiredTrue# 4. 深度命令解析# 不是简单的字符串匹配而是解析命令树command_parserast_basedAI 员工对安全代理完全无感知——从架构层面压缩了骗AI绕过安全检查的空间。这个设计比大部分开源方案都硬核。三、部署指南3.1 Docker Compose开发环境# 克隆仓库gitclone https://github.com/momotech/LinkWork.gitcdLinkWork/deploy/docker# 配置环境变量cp.env.example .env# 编辑 .env: 设置数据库密码、JWT 密钥等# 启动dockercompose up-d访问http://localhost:3003打开管理界面。3.2 Kubernetes生产环境# 开发集群Kindkubectl apply-kdeploy/k8s/overlays/dev# 生产集群kubectl apply-kdeploy/k8s/overlays/prod生产环境要求依赖版本用途Kubernetesv1.33容器编排Volcano-GPU 调度Harbor-镜像仓库NFS-共享存储3.3 踩坑记录坑描述解决K8s 版本v1.33 以下某些 API 不支持确认版本,必要时升级Volcano 安装Helm chart 依赖关系复杂按官方文档顺序来,别跳步镜像构建慢第一次构建岗位镜像很慢Harbor 做好缓存,base image 提前拉MCP 工具超时外部工具响应慢导致任务失败gateway 层设置合理的 timeout四、跟 Dify 和 DeerFlow 对比维度DifyDeerFlow 2.0LinkWork定位AI 工作流平台超级 Agent 框架AI 员工管理平台隔离方式进程级Docker 沙箱K8s 容器 镜像锁定能力管理运行时动态加载技能动态注册构建时固化 版本锁定审计基础日志执行记录全链路审计留痕交付方式API 返回文件输出Git/OSS 工程化交付定时任务有有cron 排班 无人值守部署难度低Docker中DockerPython高K8sVolcanoHarbor适合快速搭原型复杂长任务企业规模化管控它们不是互相替代的关系。如果你只是想快速搭个 AI 工作流原型,Dify 更合适。如果你要做复杂的多步骤任务编排,DeerFlow 更对口。如果你的需求是在企业里大规模部署AI、需要严格的权限管控和审计追溯灵工是目前开源方案里做得最完整的。五、适用场景场景适合度原因金融/政务 AI 落地很适合全链路审计、构建时锁定、安全架构硬核大型企业 AI 中台很适合多团队多岗位并行、统一管控研发团队 AI 辅助适合Git 交付、代码审查集成中小团队快速试水不太适合部署门坎高,K8s 运维成本大个人开发者不适合杀鸡用牛刀了六、总结灵工做对了几件事把 AI 的使用方式从工具拉到了人力资源管理维度、用一岗位一镜像解决了运行时安全的根本问题、用 Git/OSS 双通道让 AI 产出真正进入工程流程。不足也很明显部署门坎高、社区早期、陌陌自身的业务状况让长期维护成了个问号。如果你的团队已经有 K8s 基础设施,并且正在调研企业级 AI Agent 方案,灵工值得花半天时间跑一遍 Docker Compose 版试试。七、参考资料GitHub: momotech/LinkWorkLinkWork README 中文版2026年AI智能体平台深度横评 - 知乎企业级AI Agent平台怎么选国内外12家方案对比你们公司在用什么 Agent 平台Dify、DeerFlow 还是自建的评论区聊聊踩过什么坑觉得有用点赞 收藏 关注,后面会出灵工的实际部署踩坑报告