ERP 不该是黑箱子，OpenMRP 把整座工厂变成一套能敲代码的 API！
一座工厂的全部秘密，竟然藏在一串代码指令里！
摘要： 传统 ERP 是买来的黑箱，改不动、连不上、自动化全靠人工敲单据。OpenMRP 反着来——API 优先、AI 代理原生、每个仪表盘按钮背后都有一模一样的公开接口。这套开源制造平台用四年时间从一家圆形针织厂的库存追踪长成了覆盖物料、工程、生产、库存、采购、销售、定价、财务、分析、通讯的全栈系统。但它真正颠覆的，不是功能列表的长度，而是一个根本问题：工厂的“操作系统”到底该由谁来编程？
你以为 ERP 是买的，其实你是租了个慢性病！
买过 ERP 的工厂老板都懂那种感觉。花几十万上一套系统，实施团队进场三个月，蓝图会议开了二十场，最后上线那天你发现连新增一个自定义字段都要等供应商排期。改个报表模板？加钱。接个电商平台？加钱。想让自己家的程序员写几行脚本自动对账？对不起，接口文档不公开。
这不是软件，这是慢性病。你每年交维护费，换来的不是进化，而是维持“勉强能用”的姿势。
传统 ERP 的底层逻辑是“卖成品”。供应商把功能打包好，你拆开用就行，别问里面怎么装的，也别想着自己动手改。这套逻辑在三十年前管用——那时候工厂的信息化需求就是记账和算料。但现在呢？你的客户在网上下单，你的机器在跑 IoT 数据，你的仓库在用扫码枪实时更新库存，你的销售要随时查可承诺量——所有这些系统之间需要实时对话，而不是每个月导一次 Excel。
问题出在哪？出在“可编程性”这三个字上。传统 ERP 不可编程，就像一台焊死了盖子的机器，你只能按那几个按钮，按错了还得找厂家来修。
可编程工厂不是科幻片，是一套 API 的事！
OpenMRP 的哲学只有一句话：ERP 应该是可编程基础设施。
翻译成十岁小孩都能听懂的话——工厂的这套系统，应该像你手里的手机一样，想装什么 App 就装什么，想写什么脚本就写什么，而不是每次想干点新事都得求着厂商给你开权限。
怎么做到的？API 先行。
OpenMRP 的所有功能，从物料管理到生产排程，从库存盘点到客户门户，全部通过公开的 REST API 暴露出来。你打开仪表盘点一个按钮，背后调的是这套 API；你用 AI 代理发一条指令，背后调的也是这套 API；你自己写一个 Go 或 TypeScript 脚本干同样的事，调的还是一模一样的 API。
这意味着什么？意味着工厂的操作系统不再是黑箱。你能写代码驱动生产计划，你能用脚本自动生成采购订单，你能把 ERP 和你的 MES 系统、你的电商平台、你的仓库管理系统全部打通。不是靠“集成商”收你几十万做一次性的对接，而是你自己家的程序员拿着官方 SDK 就能干。
注意，官方提供了 Go 和 TypeScript 两种 SDK。你不需要读懂复杂的 SOAP 协议，不需要逆向工程，直接 import 包、填 API Key、调方法，完事。
别被骗了，API 网关背后藏着六支独立部队！
光有 API 不够，关键是 API 背后怎么长。
OpenMRP 的后端不是一个巨大的单体应用，而是六个独立运行的微服务。这六个服务各管一摊：核心服务管物料、生产、库存、订单；认证服务管身份、JWT、API Key；通知服务管邮件和消息；计费服务管订阅和支付；平台服务管审计日志和幂等性；代理服务管 AI 代理的运行、工具和记忆。
六个服务之间通过 gRPC 通信，通过 RabbitMQ 传递异步消息。每个服务都遵循相同的五层架构：传输层只负责接请求，不做业务逻辑；服务层写业务逻辑和事务边界；中介层放可复用的业务步骤；仓储层管数据持久化，SQL 用 sqlc 编译；领域层定义模型和接口。
这五层架构听着复杂，但道理很简单——每一层只管自己的事，不越界。传输层不知道业务怎么算，服务层不知道数据怎么存，仓储层不知道请求从哪来。各司其职，换掉任何一层都不影响其他层。
而且每个服务的数据存储是分离的。核心服务用 MySQL，代理服务用 PostgreSQL。更狠的是，项目文档里明确写着：目前几个服务共享一个 MySQL 数据库，但这只是过渡状态，等旧 API 迁移完就彻底拆开。
这不是做表面功夫，这是真要把“微服务”三个字落到实处。
仪表盘点的每一个按钮，你都能用代码点一遍！
OpenMRP 有一个设计原则特别狠：仪表盘调用的每一个接口，都是你可以调用的公开 API。
这句话反过来说就是——OpenMRP 团队自己在“吃自己的狗粮”。他们开发仪表盘的时候，不是开内部后门，不是走特权通道，而是跟外部开发者用同一套 API、同一套认证、同一套版本控制。
这意味着什么？意味着 API 的完备性是被“逼”出来的。任何内部功能如果 API 不支持，仪表盘就做不出来。任何 API 的变更如果破坏了兼容性，仪表盘自己先挂。这种设计倒逼出来的 API，不会缺胳膊少腿，不会藏着掖着。
你调用 API 的时候，请求头里要带三样东西：Bearer Token 做认证，OpenMRP-Account 指定你要操作哪个账户，OpenMRP-Version 锁定 API 版本。版本控制这件事，OpenMRP 做得特别死板——每次对公 API 的破坏性变更，都必须新增一个 API 版本，并且写一个转换器来保持旧版本客户的兼容性。文档里原话是“follow it, don't approximate it”——照着做，别差不多就行。
一个开源项目，对 API 兼容性要求这么苛刻，说明他们真把“可编程基础设施”当回事，而不是当营销口号。
生产排程靠“求解器”算出来，不是靠老师傅拍脑袋！
OpenMRP 的功能模块覆盖了制造业的完整链条。但有两个模块值得单独拎出来说——因为它们是真正拉开差距的地方。
第一个是生产排程。OpenMRP 里有一个“求解器”，把预测需求转成每周每个 SKU 的生产计划——运行小时数、设备利用率、什么时间锁什么工序，全部算出来。算出来之后不是直接执行，而是先以草稿形式存在，等你确认发布。
注意这里的逻辑：系统帮你算，但决定权在你手里。这不是“自动化取代人”，这是“自动化辅助人”。机器做它擅长的计算，人做它擅长的判断。
第二个是物料清单和工艺路线的统一建模。传统 ERP 里，BOM（物料清单）和工艺路线是两套东西，分开维护、分开计算。OpenMRP 把它们合并成同一个图——物料进入生产步骤，步骤产出零件，每条边都带着消耗或产出的数量，成本沿着这个图自动滚上去。
这个设计看起来只是数据结构的小调整，但实际影响巨大。BOM 和工艺路线一旦统一，成本核算就不再是“算完 BOM 再算工艺”的两步走，而是一步到位。变更一处，全部自动更新。
AI 代理能替你干活，但写操作必须有人点头！
OpenMRP 最反常识的设计，藏在 AI 代理模块里。
现在很多软件都在吹“AI 原生”，但大部分只是加了个聊天窗口，让你用自然语言问问题。OpenMRP 的代理不一样——它能在任何对话线程里被 @ 提及，然后代理会调用跟你一模一样的 API 去执行任务。
代理能读数据、能查库存、能生成报表。但有一个硬边界：所有写操作——创建订单、修改 BOM、发布生产计划——都必须经过人工批准。代理执行到写操作那一步会停下来，等人实名确认，确认之后才继续往下走。
这个设计妙在哪？妙在它把“自动化”和“自主化”划了一道清晰的红线。代理可以帮你跑完 95% 的流程，但最后那 5% 的决策权永远在人手里。不是技术做不到全自动，而是设计者有意保留了这道门。
更有意思的是代理调用 API 的方式。代理跑在 agent-service 里，当它要调用工具时，不是直接访问其他服务，而是绕一圈回到 API 网关。这一圈绕得很有讲究——代理的写操作走的是跟人类用户完全相同的认证、版本控制、幂等性和审计日志。换句话说，代理在系统里被当作一个“特殊用户”来对待，而不是一个特权后门。
这就保证了每一笔由代理发起的变更，都能追溯到具体哪个代理、哪次运行、哪个账号。
开源不是送温暖，Apache 2.0 背后是四年真功夫！
OpenMRP 整个项目以 Apache 2.0 许可证开源。但开源不等于“随便写写”。这个项目分了五个仓库：API 仓库放 Go 微服务和 OpenAPI 规范；仪表盘仓库放 Next.js 前端；UI 仓库放共享组件库；TypeScript SDK 和 Go SDK 各占一个仓库。
代码规范极其严格。贡献代码之前必须先读模式文档——分层规范、API 版本管理、可空字段处理、授权检查、审计事件、实体 ID、日志规范、注释规范，全部写成文档。文档里有一句话特别扎眼：“模仿你旁边那个文件是最常见的被拒方式”。
也就是说，你不能靠“看别人怎么写我就怎么写”混过去，你得先理解规范再写。
发布流程也高度自动化。用 release-please 管理版本和更新日志。提交信息遵循 Conventional Commits 规范——fix 打补丁，feat 发小版本，feat! 发大版本。PR 合并后自动生成 Release PR，合并 Release PR 自动切版本、自动部署。
本地开发环境用 Tilt + minikube 一键拉起。六个微服务、两个数据库（MySQL 和 PostgreSQL）、消息队列、对象存储，全部在本地跑起来。make local-db 起数据库，make dev 起全部服务，make teardown 一键销毁。
这不是玩具项目，这是一套能跑在 AWS EKS 上的生产级系统。
但你敢把整座工厂的命脉交给一套开源代码吗？
到这里，OpenMRP 的故事听起来很完美。开源、API 优先、微服务、AI 原生、四年实战打磨。但问题来了——你敢用吗？
不是技术问题。代码在那，文档在那，你可以自己部署、自己审计、自己改。但“敢不敢”从来不是技术问题，是信任问题。
传统 ERP 卖的是“保险”。你花大价钱买 SAP 或者 Oracle，买的不是软件，是“出事有人兜底”的安全感。出了问题可以打电话骂供应商，可以起诉，可以索赔。开源软件呢？Apache 2.0 许可证里写得清清楚楚——不提供任何担保。
OpenMRP 的 README 里有一句话：“Pull requests are welcome — including on the parts of this README that are wrong”。翻译过来就是“欢迎挑错，包括这份 README 里写错的部分”。这种坦诚在开源社区很常见，但对于一个要管理工厂物料、生产、库存、财务的系统来说，这种坦诚到底让人放心还是让人揪心？
还有一个细节值得玩味。OpenMRP 的 GitHub 仓库里，所有 sk_test_、mrp_sk_test_、whsec_ 开头的密钥都是伪造的测试数据。文档里专门加了一句：“如果你发现哪个密钥能连上真实服务，那才是真正的漏洞”。这句话读起来像玩笑，但细想一下——他们真检查过每一个样本密钥。这种级别的 paranoid，到底是严谨还是过度？
OpenMRP 说“ERP 应该是可编程基础设施”。这个命题本身没错。但“可编程”意味着你可以改，也意味着你可能改坏。“基础设施”意味着它很关键，也意味着它一旦出事谁都扛不住。
所以问题回来了：你愿意让一套开源代码掌管你工厂的命脉吗？
我愿意。但我想先看看，第一个敢把整条产线跑在 OpenMRP 上的工厂，出了事之后怎么收场。