OpenMakeOpenMake 是什么
面向需要掌控自身数据、模型与智能体的组织的开源权重 AI 基础设施。组织自选模型、接入自有数据、让员工用上 AI、把真实工作交给智能体，并自行治理权限、对外通信、成本、执行与审计。
本地部署不是产品本身，它只是若干部署方式之一——与客户 VPC、私有云、自建 GPU 集群、封闭网络并列。产品是那套在所有环境中保持一致的平台，所以说法不是“我们给你搭一台服务器”，而是“我们在你的安全边界内立起属于你自己的 AI 平台”。
- 开源权重：Qwen、EXAONE、Llama、Mistral，以及任何兼容 OpenAI 的端点都可互换，因而没有任何商业厂商能占有该组织的 AI
- 私有：无论运行在哪种环境，数据边界都归组织所有
- 智能体化：工作不止于一问一答——检索、分析、查询内部系统、研究、写入文件、校验、获取批准、存储结果
- 开源：运行时以 MIT 许可证发布，运营方可以审计到底执行了什么、可以修改它、可以运行私有分叉而无须征询任何人
OpenMake 处在什么位置
自托管企业市场已经存在，并且已经有人在为之付费。Dify Enterprise 销售 VPC、本地部署与封闭网络部署，配 SSO、RBAC、审计日志和数据主权。Open WebUI 把自托管、本地部署与气隙运行，连同 SSO、LDAP、RBAC、审计和数据驻留一起作为其企业价值呈现。OpenHands 在 2026 年把企业产品重新定义为智能体控制平面。价值已经从“让 AI 答得好”转向“让组织安全地运营 AI”。
这是个好信号，但照抄其中任何一家都不是计划。私有版 ChatGPT 会与 Open WebUI 争，智能体工作流构建器会与 Dify 争，编码智能体会与 OpenHands、Claude Code、Codex 正面相撞。OpenMake 选了另一条轴：普通公司里的通用知识工作，跑在组织自己拥有的开源权重模型上。
Open WebUI
自托管 AI 界面。
Dify
AI 应用与工作流构建器。
OpenHands
软件智能体控制平面，聚焦软件开发。
Ollama / vLLM
模型运行时。
OpenMake
开源权重私有 AI 加上一个通用智能体运行时，服务于一家普通组织真正在做的知识工作。
五个运营层
缺了这些层，产品就更接近一个多智能体框架，而非一套组织能够运营的平台。因此路线图是按运营职责组织的，而不是按目录里专家人设的数量。
智能体运行时
把智能体任务作为持久状态机来运行、暂停、恢复、取消、重试和恢复。
控制平面
身份、RBAC、策略、审批、预算、机密、组织设置与审计规则。
执行平面
模型、工具、浏览器、代码、文件、API、MCP 与沙箱的实际执行。
状态与记忆
任务状态、检查点、会话、产物、RAG 以及有作用域的长期记忆。
可观测性
执行时间线、日志、追踪、成本、失败原因、评估分数与审计报告。
为什么这是正确的方向
方向正确，是因为它强化了 OpenMake 本已是的东西：开源、本地、运营方所有、对开源权重友好、具备工具能力、执行过程透明。靠智能体数量竞争很容易被复制；靠“在别人边界内可靠、受治理的执行”竞争则更难、也更有价值。
它也让新模型成为机会而非威胁。组织不是为 Qwen 付费，而是为那层把 Qwen 变成企业系统的管理与执行能力付费。当更好的开源权重模型问世时，那一层是增值而不是贬值。
它守住了本地优势
OpenMake 可以拥有信任边界：本地模型路由、本地工作台桥接、Docker 沙箱，以及由运营方掌控的外部提供方。
它解决了真正的瓶颈
难点已不再是调用模型，而是保存状态、强制权限、安全重试，并证明发生过什么。
它让技能成为生态单元
外部贡献者可以打包工作流、工具、提示词、策略、评估器、模式和测试，而无须把每个功能都变成核心代码。MIT 许可证正是让这种贡献回路一开始就成为可能的前提。
它给了 A2A 更清晰的角色
多智能体辩论成为高风险工作的校验者与评审层，而不是压在每个简单请求上的默认开销。
openmake_llm 已经走到了哪里
作为一个聊天与本地大模型平台来衡量，OpenMake 已经相当完整。作为一个受治理的智能体运行时来衡量，持久执行内核已不再是缺失的那块：截至 1.40.0，智能体任务是七状态机上的持久化行，在每一轮结束时写检查点，会为审批而暂停，进程重启后自动恢复，并记录各自的 token 总量。
这一说法要附带两点限定。这套运行时的大部分是藏在默认关闭的开关后面的——任务沙箱、并发队列、本地执行器和自动派发都需要显式开启，所以全新安装并不等同于我们实际运行的那套部署。而且其持久性是以轮为粒度的：一轮中途崩溃会重放整轮，工具副作用也一并重放，因为目前还没有逐工具调用的日志。
剩下的缺口更窄也更具体——亚轮级持久性、一张真正的执行图、有作用域的记忆，以及组织控制平面。
模型网关与本地路由：高
本地优先的网关、按角色的模型路由、外部提供方适配器、token 计量与回退行为ï¼已经很接近平台所需的模型运行时层。按用户配额是失败即放行ï¼所以今天它是计量而非强制执行点。
持久任务运行时：高
持久化任务行、带 queued 与 paused 的七状态机、轮末检查点、能自动恢复具备有效检查点任务的启动恢复、步级事件日志、调度ï¼以及沙箱或本地执行器的选择ï¼全都在运行。并发队列需显式开启ï¼存活于单个 API 实例的进程内存中ï¼只有 queued 状态被持久化。
本地执行面：高
在用户自有机器上运行工具的桥接ï¼如今是单一实现——packages/local-bridge-core——背后有三个客户端ï¼桌面伴侣、openmake-code CLI 和一个 SwiftUI 菜单栏应用。路径作用域、执行禁止清单、不可绕过的确认ï¼以及操作系统沙箱配置都在该核心里ï¼创建本地任务这一动作会写入审计日志。
工具、沙箱、审批：中
MCP 工具、Docker 隔离的外部服务器、任务沙箱工具、文件与浏览器执行、人工审批闸门ï¼以及针对浏览器容器的网络级出站白名单都存在ï¼但还不是一个完整的、由策略强制的工具运行时。审批等待是一个内存中的 promiseï¼只有 paused 状态能在重启后留存。
执行图：早期
存储下来的计划是一份带状态和备注的扁平步骤列表ï¼每个执行步骤按索引归属回它。它还不是一张持久的 DAG——那种每个节点各自拥有依赖、权限、成本上限、重试策略、输出与完成标准的图。
记忆：部分建成
过程性记忆是真实存在的ï¼一个成功任务的浏览器或脚本过程会被保存为过程性技能ï¼并在相似目标上重放而无须再次询问模型。情景性回忆是派生而非存储的——过去的相似任务是从任务行与步骤行中重建、并作为一段压缩块注入的。语义记忆才是真正的缺口ï¼没有向量库ï¼用户记忆是靠三元组匹配来检索的。
可观测性：中
OpenTelemetry 追踪、步级事件日志、审计日志、指标ï¼以及一份每周门禁报告——它把每道“先测量”门禁背后的证据渲染出来。黄金数据集路由与响应评估作为 CI 门禁运行ï¼已有一道路由门禁因测量结果不支持而被撤下。仍然缺的是一份组织可以直接交给审阅者的一等公民审计报告。
企业控制平面：早期
JWT、三种角色、携带桥接与聊天作用域的 API 密钥、用量、管理界面与运营方设置都已具备。多租户尚未起步——模式里没有租户、项目或工作台列——而预算策略、数据出站控制与部署审批仍是未来工作。
开发力量投向何处
约七成的开发产能属于企业基座。软件项目与可售产品之间的差距不是某个缺失的功能ï¼而是上一节称之为“早期”的那个控制平面。以下四个梯队就是这个差距被填平的顺序。
P0 — 必需
组织与租户、RBAC、项目、模型策略、数据出站策略、审计、机密管理、用量与预算。
P1
执行图、智能体策略、沙箱策略、审批工作流、可观测性、有作用域的记忆。
P2
基于 OIDC 与 SAML 的 SSO、LDAP、SIEM 集成、备份与恢复、高可用、Kubernetes 部署。
P3
气隙安装、离线模型注册表、离线技能注册表、企业更新通道。
社区版与企业版，同一套代码库
OpenMake 采用开放核心模式ï¼因为一个强大的社区版正是让企业业务成为可能的东西ï¼而非与之竞争的东西。技能是生态单元ï¼一名贡献者应当能打包一条工作流ï¼而无须理解整个运行时。
OpenMake 社区版 — MIT，免费
单一组织、本地模型、智能体运行时、MCP、技能、基础 RAG 与基础沙箱。强到人们装上后会一直用下去。
OpenMake 企业版 — 付费
多组织、进阶 RBAC、SSO 与 LDAP、策略引擎、模型治理、数据出站控制、审计、预算、企业部署、高可用、气隙与支持。这些都还没建成ï¼模式里没有租户或项目列ï¼今天的每一次安装都是单一组织。
OpenMake Code 作为执行节点
桌面与本地工具不再是一个独立项目ï¼而是成为执行节点——在同一个控制平面下运行本地文件、源码、终端与内网工作。这一整合已经开始ï¼Electron 外壳在其桥接迁入共享核心后被退役ï¼执行节点如今是一个原生伴侣、一个 CLIï¼以及驱动它们的 Web。
有哪些东西会沿用下来
OpenMake 1.40.0 已经有一些好用的部件ï¼本地优先的模型路由、按角色的编排、智能体任务、技能、22 个内置 MCP 工具、带证据的深度研究、NotebookLM 接地、产物、运营方控制ï¼以及一个如今由桌面伴侣、openmake-code CLI 和原生菜单栏应用共享的本地工作桥接。这些应当被重新定位ï¼而不是丢弃。
- 大模型网关仍是网关ï¼提供方鉴权、流式、token 计量、超时、回退与参数归一化
- 消息流水线保留请求处理ï¼而规划则拆出去ï¼成为一个存储式规划器ï¼产出可复用的执行图、所需权限、审批点、成本估算与完成标准
- A2A 讨论从默认路径中移出ï¼进入高风险规划、代码评审、事实交叉核对、结果校验与复杂决策
- RAG 仍是知识检索层ï¼而工作记忆、情景记忆、语义记忆、过程性记忆与产物记忆各自成为独立的运行时关切
有哪些必须作为核心来构建
缺失的基座不是又一个智能体人设。持久执行——那些能在进程重启后存活、在每轮结束时写检查点、为审批而等待、并从已知状态恢复的任务——如今已在产品中。仍然缺的东西压在它之上ï¼一张运行时能执行的图、一层不住在提示词里的策略ï¼以及带作用域的记忆。
持久任务运行时 — 已建成
任务模型、状态机、worker、事件日志、检查点、取消、暂停、恢复与重试。这是下面一切如今赖以站立的一层。两块仍未合上ï¼幂等重放ï¼因为中途崩溃的一轮会重跑它的工具调用ï¼以及一个能比进程活得更久的队列ï¼因为今天的队列需显式开启且在进程内。
执行图 — 计划中
带输入、输出、智能体、模型、工具、权限、超时、重试策略、成功标准、成本上限与审批要求的 DAG 节点。今天存储下来的计划是一份扁平的步骤列表。
策略与审批 — 部分建成
由服务器强制的权限级别ï¼从只读工作到对外影响、部署、支付、安全、法务与财务动作。审批闸门今天覆盖了其中一部分ï¼它背后那个声明式策略引擎还不存在。
工具运行时 — 部分建成
一个带模式、权限元数据、执行模式、超时、重试策略、遥测与标准化结果信封的注册表。工具本身能跑ï¼22 个内置加上外部 MCPï¼但并不是跑在这样一个注册表背后。
工作台沙箱 — 已建成
按任务隔离的工作台、只挂载指定文件夹、进程或容器隔离、资源上限、网络白名单与保留输出。这一块已经在运行ï¼列在这里ï¼是因为上面那一层仍通过临时调用而非策略去触达它。
记忆与审计 — 部分建成
带来源、置信度、敏感度、过期的作用域记忆ï¼外加对计划、模型选择、工具调用、成本、审批、失败、重试与产物的追踪。过程性记忆和这些追踪存在ï¼作用域元数据和语义存储不存在。
构建顺序
前两个阶段大体已经交付ï¼所以下一个站得住脚的步骤是执行图。任务状态如今已可靠ï¼它仍缺的是一份按节点点名依赖、权限与完成标准的计划ï¼而不是线性的轮序。
- 01
持久任务运行时 — 已交付
任务数据模型、状态机、作业队列、worker、存储式执行计划、检查点、取消、暂停、恢复与事件日志都已在产品中ï¼token 总量在终止态转换时聚合。剩下的是亚轮级持久性ï¼一份逐工具调用的日志ï¼好让崩溃的一轮不再重放其副作用ï¼以及一个比进程活得更久的队列。
- 02
工具、审批、沙箱 — 大体已交付
工具注册表、MCP 网关、审批收件箱、工作台隔离、Docker 沙箱、机密、文件 diff 与浏览器出站白名单都已就位。剩下的部件是一个带服务器强制权限级别的声明式策略引擎ï¼以及一个能在重启后存活、而不只是活在进程内存里的审批等待。
- 03
执行图 — 下一步
各自拥有依赖、所需权限、成本上限、重试策略、输出与完成标准的 DAG 节点ï¼取代线性轮循环成为规划的单元。
- 04
智能体与技能清单 — 进行中
把 Supervisor、Planner、Worker、Researcher、Reviewer 与 Recovery 各角色标准化ï¼让技能成为工作流、提示词、策略、工具、评估器、模式与测试的打包单元。清单驱动的技能注入与过程性技能抽取已经开始。
- 05
有作用域的记忆与组织控制平面
带来源与过期的工作记忆、情景记忆、语义记忆、过程性记忆与产物记忆ï¼而后是多租户、组织、项目、RBAC、token 与成本预算、外部模型策略、部署审批与运营仪表盘。
接下来的十二个月
下面的时间表关乎的是在一家真实组织里验证产品ï¼而不是交付更多能力。一家把 OpenMake 装到自己工作网络上、每天都在用的公司ï¼价值胜过成千上万个 GitHub star。
第零个月是 2026 年 8 月ï¼即这份路线图敲定之时。因此第一个梯队是在进行中而非在我们前方ï¼其中已经完成的部分标注在下面。
- 0–3 月
厘清产品定位 — 进行中
已完成ï¼私有 AI 定位与企业架构就是本页如今所陈述的ï¼上一节点名了三个代表性用例ï¼审计日志也已运行了一段时间。尚未完成ï¼组织与项目在模式里还不作为概念存在ï¼RBAC 止步于三种角色、没有租户或项目作用域ï¼模型策略也尚未起步——不过将来为其接地的模型测量已经在 OpenMake Bench 上开始了。
- 3–6 月
把它装进真实组织里
三家设计伙伴、私有 VPC 部署、本地部署、SSO、数据策略与技能打包。
- 6–9 月
让它成为产品，而非一次构建
企业安装器、升级与备份、监控、管理仪表盘、Kubernetes 与企业定价。
- 9–12 月
证明它不止卖出一次
生产环境中的真实客户、案例研究、合作伙伴、系统集成协作与企业支持。
第一个用例，刻意收窄
第一个企业示范是一个私有研究与文档智能体ï¼面向大约三十到五百人、无法把内部材料放进外部生成式 AI 的知识密集型组织。协会、研究机构、准公共机构、制造业研发部门、中型企业、咨询公司ï¼以及会计或法务组织ï¼都排在大型金融或国防之前——后者在产品之前先要求认证、采购与系统集成能力。
一名员工要求把过去三年的合同及相关法规拿来分析ï¼找出可能成为问题的条款ï¼并以报告形式返回。这次运行会搜索内部文档、检索、在一个开源权重模型上作答、在任何外部查找之前先核对策略、进一步研究、校验其证据、写出报告、等待责任人批准、生成 PDF、DOCX 或电子表格ï¼并存下一条审计记录。没有任何内部文档离开组织的掌控。
- 文档分析ï¼上传、结构分析、抽取、交叉核对、报告、存下的产物
- 研究工作ï¼检索计划、来源收集、来源评估、冲突证据核对、报告
- 重复性工作自动化ï¼定时运行、数据采集、阈值比较、异常检测、报告、经批准的后续动作
- 开发工作仍受支持ï¼但不是切入点ï¼因为那个市场已被专门的编码智能体争夺
- 不要一上来就堆专家智能体、把每个请求都变成 A2A、靠提示词控权限、把 ChatService 越养越大ï¼或在受控半自动跑通之前就承诺完全自主