做企业 AI 系统这几年我见到的演示级系统远比生产级系统多。两者的差距不在功能列表——功能谁都写得出来PPT 上人人都是满级号。差距在工程细节安全是前端隐藏还是服务端强制数据有没有隔离边界AI 能力是拼盘还是编排操作有没有留痕这些细节藏不住一眼就能判断系统是做给客户看的还是真的在跑业务的。下面 6 条全部用我们 XEAOS 企业系统的真实代码说话。一、看权限是前端隐藏还是服务端强制这是专业与否的第一道分水岭也是最多系统翻车的地方。很多系统的权限只是前端隐藏菜单里不显示按钮、页面上藏掉入口。但前端隐藏是假安全——懂点技术的人直接调 API 就能绕过。专业系统必须在服务端强制过滤。我们的实现每个数据请求进来服务端先解析请求者角色默认受限再判断路径是否命中敏感前缀命中即拒绝# server.py真实代码精简 # 说明前端隐藏只是表象服务端必须过滤——员工可直接调 /vault-api/read 读取敏感文件 SENSITIVE_PREFIXES ( classtok-str00~02_ Foundation基础层/02_Li_Senior_Brother, # 创始人个人经历 classtok-strXEAOS/Config/, # 凭据管理员/员工密码 classtok-strXEAOS/Audit/, # 登录审计日志含 IP/归属地 classtok-str10_Operations运营层/Hermes/Chats/, # 对话存档 classtok-str10_Operations运营层/经营决策规则库.md, # 内部决策依据 ) def get_request_role(handler, params): classtok-strclasstok-str从请求头 X-XEAOS-Role 读取角色默认受限 guestclasstok-str role handler.headers.get(classtok-strX-XEAOS-Role, classtok-str) if not role: role params.get(classtok-strrole, [classtok-str])[0] role str(role).strip().lower() return role if role in (classtok-strsuper_admin, classtok-stremployee, classtok-strguest) else classtok-strguest def is_sensitive_rel(rel_path): classtok-strclasstok-str判断路径是否命中敏感前缀含子路径classtok-str norm rel_path.replace(classtok-str\\, classtok-str/).lstrip(classtok-str/) for prefix in SENSITIVE_PREFIXES: p prefix.replace(classtok-str\\, classtok-str/).rstrip(classtok-str/) if norm p or norm.startswith(p classtok-str/) or norm.startswith(p): return True return False注意几个工程细节角色从请求头解析、无角色默认 guestfail-closed、前缀匹配含子路径、写死的敏感目录清单可审计。这套逻辑保证即使前端被完全绕过敏感数据也拿不到。判断标准问对方权限在哪层做前端还是后端答前端隐藏的可以直接扣分答不上来服务端如何校验角色的专业度存疑。二、看数据是唯一真相源还是各管一段企业 AI 系统的正确性前提是数据一致性。很多系统的数据是散的文档在 A、客户在 B、内容在 CAI 问客户情况怎么样只能拼凑记忆回答。我们的做法是把所有业务数据收口到 Obsidian 知识库AI 智能体统一走一个数据入口读写classclasstok-strtok-com// 统一数据入口真实代码 const resp await fetch(classtok-str/vault-api/read?path${encodeURIComponent(planPath)}); classclasstok-strtok-com// 写回同一入口全模块可见 await fetch(classtok-str/vault-api/write?path${encodeURIComponent(planPath)}, { ... });不是技术洁癖是正确性前提AI 的记忆来自数据数据不统一AI 回答就不靠谱。路径本身承载业务结构10_Operations运营层/Content/每日自媒体计划-{date}.md任何模块读数据都走同一套路径规范——这是唯一真相源在代码层的落地。判断标准各模块读写的是不是同一份数据有没有统一数据入口说每个模块自己存的系统性还差得远。三、看隔离多租户/多工作区有没有数据边界企业系统必然多用户、多部门、甚至多工作区。数据隔离不是能不能的问题是边界怎么画的问题——没隔离 一个部门的客户数据能被另一个部门看到这在企业场景是事故。我们在 Runtime 调度层做统一隔离每个请求都注入工作区上下文所有 Runtime 通过它感知自己属于哪个隔离域classclasstok-strtok-com// src/runtime/RuntimeManager.ts真实代码精简 classclasstok-strtok-com// P2-3当前工作区上下文数据隔离用 classclasstok-strtok-com// 所有 Runtime 通过 params._workspaceId 获取该上下文 async query(name: RuntimeName, params?: Recordstring, any, workspaceId?: string) { classclasstok-strtok-com// 注入 workspaceId 到 params不修改 dispatcher 实现 const effectiveWorkspaceId workspaceId ?? this.currentWorkspaceId; const paramsWithWorkspace { ...params, _workspaceId: effectiveWorkspaceId }; classclasstok-strtok-com// 交给分发器执行 const data await this.dispatcher.execute(runtime, command, paramsWithWorkspace); return { success: true, data, runtime: name }; }关键在_workspaceId注入这一行隔离是横切关注点放在调度层统一做而不是每个业务模块各自实现——业务代码不用关心自己属于哪个域调度层保证数据出不了边界。判断标准数据隔离是架构层做的还是每个模块自己写的后者在多租户下必然漏。四、看能力组织是工具拼盘还是运行时编排演示系统里 AI 是一个个孤立工具写内容找内容工具、跟客户找客户工具每个都要人手动切。专业系统里 AI 是一张编排网。我们把它抽象成 Runtime运行时 事件总线EventBus两层。Runtime 统一接口classclasstok-strtok-com// src/types/runtime.ts真实代码精简 export interface IRuntime { readonly name: RuntimeName; readonly status: RuntimeStatus; initialize(): Promisevoid; classclasstok-strtok-com// 生命周期 query?(params?: unknown): Promiseany; classclasstok-strtok-com// 只读操作 execute?(command: string, params?: unknown): Promiseany; classclasstok-strtok-com// 写操作 onEvent?(event: RuntimeEvent): void; classclasstok-strtok-com// 事件订阅 }Runtime 之间不互相硬调通过事件总线解耦协作。事件总线有完整的工程细节——事件 ID、监听器快照防遍历时修改、优先级排序classclasstok-strtok-com// src/runtime/EventBus.ts真实代码精简 emit(event: RuntimeEvent): void { const eventWithId { ...event, id: (event as any).id || this.generateEventId() }; classclasstok-strtok-com// 记录历史 this.recordHistory(eventWithId); classclasstok-strtok-com// 获取监听器快照防止遍历时修改 const typeSnapshot this.listeners.get(eventWithId.type) ? [...this.listeners.get(eventWithId.type)!] : []; const wildcardSnapshot [...this.wildcardListeners]; classclasstok-strtok-com// 按优先级排序高 → 低 const priorityOrder: RecordListenerPriority, number { high: 0, normal: 1, low: 2 }; classclasstok-strtok-com// ... 按序派发 }三个工程点值得注意事件带全局 ID可追踪、快照遍历并发安全、优先级调度关键链路优先。有这层才能做到内容工厂生成完 → 事件触发 CRM 跟进 → 成交写回知识库的自动化链路而不是人肉在两个工具间搬运。判断标准AI 能力之间能不能互相调用有没有事件/消息机制各干各的的还停留在拼盘阶段。五、看留痕操作有没有全链路审计专业系统不是不犯错而是出错可追溯。审计要做到三层谁操作了什么操作审计、谁登录过登录审计、权限怎么变的变更审计。我们每条关键操作都落审计表配登录审计面板独立呈现。出问题能一路查到根谁、何时、改了哪个文件、结果如何。判断标准登录背后有没有审计表关键操作有没有留痕没有 出事只能靠猜、靠回忆。六、看部署与进化数据主权 系统会不会越用越懂你最后两条放一起说因为它们共同决定系统能不能长期用。部署企业数据是资产也是风险。必须能回答三个问题数据存在哪谁能碰走了怎么销毁我们支持私有化部署数据落在企业自己服务器知识库 Git 双向同步防丢失可回滚。进化系统用三个月会不会比第一天更懂你我们的做法是经验沉淀 → 规则库 → 决策依据闭环每天的经营复盘产出新经验进入规则库指导明天的动作。系统不是静止的是持续自学习的。判断标准数据主权能书面确认吗系统有没有自我进化的机制两者都含糊的别碰。最后一张表维度演示级专业级XEAOS 做法权限前端隐藏服务端强制过滤无角色默认 guestfail-closed数据各工具割裂唯一真相源统一 vault-api 读写隔离无边界调度层注入_workspaceId数据出不了域能力孤立工具拼盘Runtime 编排 事件总线ID/快照/优先级审计无留痕操作 登录 变更全链路审计部署/进化数据上云、系统静止支持私有化经验沉淀反哺一句话收尾专业的企业 AI 系统不是功能多是工程对——安全服务端强制、数据有唯一源头、隔离有边界、能力有编排、操作有留痕、系统会进化。这 6 条全中才敢说专业。