一家做化肥经销的企业，客户在 WhatsApp 上用夹杂母语的口语下订单——「兄弟，要两袋 DAP 肥料，明天送到」。系统要的是结构化 ERP 订单。当它用大模型把这句话抽成行项、用模糊匹配对齐商品目录后，没有立刻写库，而是先弹回一句：「您是要 2×DAP、1×尿素对吗？」——这句几乎零成本的确认，挡住了 90% 需要回滚的错单。
这个来自真实生产管线（对接 Oracle ERP）的开源项目 multichannel-order-to-erp-agent，道出了本周开源 ERP+AI 社区一个正在收敛的共识：AI 可以读、可以查、可以建议，但凡要往核心业务系统里写一笔，必须有人点头。翻看 10 月下旬陆续浮出水面的一批开源项目——OpenMRP、Ever Gauzy、Odoo Atlas、Raven AI——它们出身不同、协议各异，却几乎在同一周把"人工确认写操作"和"权限内嵌检索"做成了架构的默认设置，而不是可选项。
一、从"加个聊天框"到"把治理做成架构一等公民"
过去一年，太多厂商把"AI 原生 ERP"做成了在老系统旁边挂个聊天窗口：你用自然语言问问题，它答得挺漂亮，但真要干活时，写操作要么被绕开、要么被悄悄放行。开源社区这波项目反其道而行，把治理链路直接焊进了骨架。
OpenMRP（Apache 2.0，Go 微服务 + OpenAPI 规范）的设计最"反常识"：它的 AI 代理能在任何对话线程里被 @ 提及，调用和你一模一样的 API 去执行任务——读数据、查库存、生成报表都没问题，但所有写操作（创建订单、修改 BOM、发布生产计划）都会在提交前停下，等人实名确认。更讲究的是，代理跑在独立的 agent-service 里，写操作不是直连数据库，而是绕回 API 网关，走与人类用户完全相同的认证、版本控制、幂等性和审计日志。换句话说，代理在系统里被当成一个"特殊用户"，而不是一个特权后门。每一笔由代理发起的变更，都能追溯到哪个代理、哪次运行、哪个账号。
multichannel-order-to-erp-agent 把防护做成三层递进：第一层用大模型提取行项（因为客户消息非正式、多语言、结构不稳定）；第二层用 RapidFuzz 做分层模糊匹配，≥88 分自动接受、70–88 分标记人工复核、低于 70 分绝不瞎猜；第三层在每次 ERP 写入前强制人工确认。它的 README 里那句"为什么每次写入前都要确认"，值得所有做"AI 对接生产系统"的人反复读：提取和匹配都是概率性的，ERP 里写错订单的回滚代价很高，问一句几乎零成本。
Ever Gauzy 的 Ever Works（AGPL，GitHub Trending 2026-09-14 推荐）走得更激进——号称 24/7 自主运营的 AI 代理系统，能独立研究、交付和维护完整业务。但即便如此，社区讨论的焦点仍是：先 fork 看它的 agent 架构怎么对接现有模块，而不是直接上生产。AGPL 的传染性对商业化也有法务约束。
这一批项目的共同潜台词是：自动化 ≠ 自主化。AI 可以帮你跑完 95% 的流程，但最后那 5% 的决策权，永远应该留在人手里。不是技术做不到全自动，而是设计者有意保留了这道门。
二、把权限检查"焊"进检索层：两种更细的解法
如果说 OpenMRP 解决的是"写之前要确认"，那么另两个项目解决的是更隐蔽的坑——权限。企业 ERP 上 AI 助手最大的陷阱不是答不准，而是提权：一个用管理员连接直读数据库的聊天机器人，等于给所有人发了全库查看权限。
Odoo Atlas（LGPL-3.0）给 Odoo 社区版配了一个 AI 助手引擎，用"三段式检索"把 ERP 记录规则完整保留。它的权限设计分三段：先在向量库里做候选检索并按公司与可见性过滤；然后把候选发回 Odoo，以提问用户的身份执行 search，让记录规则原样生效；只有幸存的行才进入提示词。关键是第二段不可通过配置关闭——作者明确说砍掉第一段只会变慢、不会变不安全，这正是安全设计想要的属性。整个仓库 180 个代码文件，用六份 ADR 文档记录架构决策，CI 里用 import-linter 强制三条架构规则。它把"大模型 20 秒调用挪出 Odoo 同步进程池"的"边车拓扑"也写进了规范。
Raven AI（AGPL-3.0，最近更新 2026-10-20）则基于 Frappe 框架，直接同步 ERPNext、Frappe HR，在聊天界面里就能创建 ERPNext 单据、运行工作流、打印文档；AI bots 无代码搭建，能提取文件图片、串联多源信息、调用 ERPNext 函数。它把"沟通"和"业务操作"合进同一个工作区，但权限仍走 Frappe 原生的角色与记录规则。
| 开源项目 | 许可证 | 治理机制亮点 | 最近动态 |
|---|---|---|---|
| OpenMRP | Apache 2.0 | 写操作实名确认，代理走 API 网关同权审计 | 2026 多仓库工程化 |
| multichannel-order-agent | 开源（泛化自生产管线） | 三层防护：提取/匹配/确认，模糊匹配三档阈值 | 对接 Oracle ERP 真实管线 |
| Ever Gauzy / Ever Works | AGPL | 24/7 自主运营代理，headless 可深度定制 | GitHub Trending 2026-09-14 |
| Odoo Atlas | LGPL-3.0 | 权限三段式，第二段不可关闭，边车拓扑 | 180 文件 + 6 份 ADR |
| Raven AI | AGPL-3.0 | Frappe/ERPNext 原生角色与记录规则 | 更新 2026-10-20 |
| AiNativeERP（10-30 已述） | MIT | 7 领域智能体/28 工具/草稿确认/审计回放 | 参考实现 |
三、为什么这道红线是"默认设置"而非"可选项"
把这几条线连起来，会发现开源社区和闭源厂商的思路有本质差异。不少闭源 Agent 默认追求"全自动"，治理往往靠厂商的承诺白皮书；而开源项目把"护栏、审计、确认"做成了可以直接读源码、可以 fork、可以审计的代码路径。当智能体开始往 ERP 里写单子，企业最该问的不是"它聪不聪明"，而是"它写的那笔，能不能追溯到人、能不能回滚、出事谁兜底"——开源把这三点前置到了架构里。
这恰好呼应了本周另一则被广泛引用的治理警示：在一份关于"AI 智能体接管 ERP"的分析中，一家财富 500 强保险公司的月末结账智能体，因为继承了为人类点击设计的权限模型，在单一身份下既制作分录又处理异常，把"职责分离"这一内控铁律变成了虚设——每笔分录都挂着主计长的 ID，但她两件事都没做。问题不在模型故障，而在控制模型没跟上。
5%
开源项目主动保留给"人"的最后决策权占比——其余 95% 流程可由代理跑完，但写操作红线不越
3 段
Odoo Atlas 权限检查的最小切片：候选过滤 → 以用户身份回查 → 幸存行才进提示词，第二段不可关闭
模糊匹配双阈值：低于 70 分绝不猜测，70–88 分人工复核，≥88 分才自动接受——开源项目用工程手段把"概率性输出"关进了笼子
四、CIO 实操建议：把"人工确认"写进你的 Agent 采购清单
聊了这么多项目和阈值，落到采购与落地，我建议 CIO 把下面三条当成 Agent 类项目的硬性验收项，写在合同附录里，而不是等上线后才补：
第一，写操作必须"可拒绝、可确认、可回放"。任何要创建/修改/删除业务单据的智能体，都先生成草稿，由具名用户确认后落库，并且全程留痕、可审计回放。OpenMRP 的"代理走 API 网关同权审计"和 AiNativeERP 的"写操作草稿确认"都可作为验收样板。
第二，代理以"具名用户"身份跑，且走与人类相同的认证与审计。绝不能给代理开特权后门。Odoo Atlas 的"以提问用户身份回查"是底线思维：代理能查到的，绝不能超过该用户本来就能查到的。
第三，高风险动作强制人工闸，低风险动作才放行自动化。参照 multichannel-agent 的三档阈值和金蝶"100 万元以下、风险低或中的采购可授权代审批"的思路，把自动化程度与风险等级绑定，而不是一刀切全自动。
两个常被忽略的坑。其一，别被"全自动"demo 迷惑：厂商在 PPT 上跑通的全自动，往往避开了真实权限与回滚；验收时要拿生产级权限矩阵去测。其二，AGPL/LGPL 等协议的传染性需要法务评估——Ever Gauzy、Raven AI 都是 AGPL，若要做商业化 SaaS 需先过合规关。
开源 ≠ 生产就绪。包括 10-30 我们介绍过的 AiNativeERP 在内，多数项目都明确标注"参考实现"定位：企业直接用需要替换业务模型、接入真实主数据。它的最大价值是把"AI 治理链路"从概念变成可运行的代码路径，而不是开箱即用的生产系统。先有可审计的治理骨架，再谈智能体上岗，顺序不能反。
写到最后，一句话总结这周的观察：当闭源厂商还在比"我的 Agent 能自动干多少活"，开源社区已经集体把标尺换成了"我的 Agent 写每一笔前，是不是人都确认过、是不是都能追溯"。这道红线，看似保守，实则是最快的规模化路径——因为能让财务总监睡得着觉的 AI，才推得动。
本文基于公开信息整理分析：jdon.com《OpenMRP 开源 ERP》（2026）、jxxy.net（觉醒AI知识库）OpenMRP / multichannel-order-to-erp-agent / Odoo Atlas 技术分析（2026）、amazingindex.com GitHub Trending 2026-09-14、caimpare.ai Raven AI（更新 2026-10-20）、AiNativeERP（MIT，github.com/Edison0621/AiNativeERP，10-30 本号已述）、企业网 D1Net《当 AI 智能体接管 ERP：CIO 为何必须重构权限模型》（2026-10-08）。数据截至 2026-10-31。
众谛信息 · 专注 Odoo 与企业管理数字化解决方案
