元数据即 Prompt、BPM 状态机护栏、SAGA 补偿、GenUI 在企业级软件的深水区，纯 AI Agent 很容易死在两个字：幻觉、不可控。所以这篇文章只讲一个务实结论：用确定性的系统，去承载概率性的智能。
你可以把 Oinone 理解成一层“工程翻译器”：把非结构化的 AI 能力，翻译成结构化业务能执行、能审计、能回滚的动作——靠的是 Metadata（元数据）、BPM（流程/状态机）、GenUI（生成式界面） 这三套“确定性骨架”。
Demo 体验
0. 一个反直觉的立场：不要让 LLM 解决所有问题
- LLM 负责：意图识别、信息抽取、方案生成、交互表达（“会说、会想”）
- 确定性系统负责：校验、权限、交易、流程推进、审计、回滚（“能做、可控”）
思考一下：如果你的 Agent 今天就能直连数据库写入，你敢不敢把它当“生产写权限用户”？如果不敢，那你缺的不是 Prompt，而是“边界”。
1. 神经-符号混合架构：用确定性把不确定性“框起来”
为什么企业里 Agent 总卡在 Demo？ 因为 AI 擅长“识别意图”，但不擅长“精准执行”。一旦涉及资金、库存、权限这类核心业务，你不能把“概率”当成“可靠性”。
所以我们需要一个混合架构（你可以把它当成“分层责任制”）：
用户意图（自然语言）
↓
LLM：识别意图 / 提取槽位 / 生成计划（不确定性）
↓
结构化翻译层：Metadata → Schema / Rules（把话翻译成“合同”）
↓
确定性执行层：API + BPM + State Machine + Guardrails（可控可审计）
↓
反馈层：文本 + GenUI（把执行变成“所见即所得”）
一句话：LLM 是“意图引擎”，BPM/状态机是“执行引擎”，元数据是“契约”，GenUI 是“交互的最后一公里”。
![]()
2. 数据层：别再把 Prompt 当文案了，把它当“接口契约”
2.1 痛点：文档给人读，系统给机器跑，中间断层
企业里有海量 Word/PDF 文档和数据库记录，但直接丢给 RAG 往往效果一般：
- 文档是“给人读的”，大量隐含逻辑
- 数据库是“死的”，缺语义上下文
2.2 解法：Metadata 即 Prompt，把元数据编译成 Schema
元数据不是“提示词素材库”，而是 Agent 的结构化世界模型。 你可以把 Oinone 的模型定义、字段约束、枚举值“转译”为 Agent 的 System Prompt / Tool Schema，从源头减少 AI 理解偏差。
// 伪代码：将 Oinone 模型定义转换为 Function Call Schema
function generateSchemaFromModel(modelName: string) {
const model = Oinone.getModel(modelName);
return {
name: "create_" + modelName,
description: `创建${model.label}，需遵循业务规则`,
parameters: {
type: "object",
properties: model.fields.reduce((acc, field) => {
acc[field.name] = {
type: field.type,
description: field.description + (field.required ? " [必填]" : ""),
enum: field.options ? field.options.map(o => o.value) : undefined
};
return acc;
}, {}),
required: model.fields.filter(f => f.required).map(f => f.name)
}
};
}
2.3 规则显性化：别在 Prompt 里“祈祷正确”，要让系统“拦得住”
原文这个对比非常值钱，建议突出成一个小结论：
- 静态结构：Schema/字段约束
- 动态规则：把“金额 > 1 万需审批”这种逻辑变成机读规则，而不是一句模糊自然语言
例如（原文例子）：
- “手机号 11 位” → 正则约束
^1[3-9]\d{9}$（平台自动拦截）
- “VIP 打八折” → 计算字段/触发器
price * 0.8 if vip
思考一下：你希望系统的正确性来自“模型很聪明”，还是来自“聪明也越不过规则”？ 前者是祈祷，后者是工程。
2.4 工程风险：模型变了、业务变了、Prompt 没变 —— 你会“悄悄变错”
原文点到一个非常真实的坑：业务模型新增字段，但 Prompt 生成器没同步，Agent 就会“看不见新属性”。
建议把对策写得更像工程制度：
- 把 Prompt 当产物：由元数据编译生成，不允许人工手改成为“真相来源”
- 把变更纳入 CI/CD：任何元数据变更必须触发 Schema/Priority Prompt 的自动重建与测试
- 加一层契约测试（Contract Test）：测试 Agent 输出是否仍符合 Schema、关键规则是否仍被触发（这一步是我在原文基础上的增强建议）
3. 逻辑层：用 BPM/状态机给 Agent 装“工业级护栏”
一句话总结原文：AI 负责“想”，流程引擎负责“做”。 当 Agent 识别到“发起报销”，它不该直接改库，而是调用 BPM 启动流程；审批、校验、转账都交给确定性的流程引擎接管。
原文这段“意图 → 执行动作”的结构非常适合做成标准协议（建议你把它命名为 Intent Contract）：
{
"intents": [
{
"name": "submit_expense",
"action_type": "start_process",
"target": "process_expense_v2",
"mapping": {
"amount": "context.money",
"reason": "context.description",
"receipts": "context.files"
},
"guardrails": ["check_budget_limit", "verify_auth"]
}
]
}
护栏不是一句口号，它至少包含四类“硬约束”：
- 输入护栏：Schema 校验 + 必填字段补齐策略
- 权限护栏：谁能发起、谁能审批、谁能付款（RBAC/ABAC 都可以，关键是落在确定性层）
- 状态护栏：只能从 A 状态走到 B 状态，不能“跨级跳转”
- 审计护栏：每一步谁发起、系统做了什么、为什么通过/驳回，都可追溯
思考一下：如果你的 Agent 能在对话里“跳过审批”，那它不是智能，是绕过控制点的漏洞。
4. 稳定性：长链路任务别赌运气，要能回滚——SAGA 给 Agent“后悔药”
原文指出：长链路里如果第 3 步理解错导致失败，系统必须可回滚；可以用 SAGA 设计补偿事务。
把它写得更“可落地”，建议用这种结构呈现：
- 正向：扣库存 → 创建订单 → 发起支付
- 失败：支付失败 → 取消订单 → 回补库存（补偿自动触发）
关键洞察：SAGA 不是“异常处理”，它是把失败当成正常路径来设计。 Agent 越聪明，越需要这套“失败也能优雅收场”的工程底盘。
5. 敏捷篇：影子 IT 的根因，是“需求太小不配排期”
原文说得很直白：传统排期过滤掉大量低 ROI 但高频槽点需求，最后就长出 Excel/微信群这类影子 IT。
Generative App：把“吐槽”变成应用
- 结构化拆解：表单（人员/餐品）+ 流程（统计/通知）
- DSL 生成：Agent 输出 Oinone XML/JSON 配置
- 热部署：引擎解析配置，生成 H5/PC 页面链接
- 响应：2 周 → 5 分钟
- 成本：> 10,000 元/单 → Token 成本 < 5 元
- 维护：遗留代码 → 平台统一托管（元数据治理）
思考一下：真正的敏捷不是“写得快”，而是让 80% 不值得立项的需求也能被“系统性解决”。
6. 交互篇：企业软件的下一代不是更聪明的 Chatbot，是 GenUI
原文观点很明确：现在很多 Copilot 还停留在聊天框，但下一代是 GenUI：界面由 AI 按任务动态装配。
原文对比（我建议你把这段做成文章里最“画面感”的部分）：
- Chat-based：文本反馈，缺少直观确认，复杂表单很难搞
- GenUI：直接渲染权限配置卡片，所见即所得
落地关键：组件原子化 + UI 协议化
前端不再写“页面”，而是写“组件库 + 渲染器”。
// AI 返回的 UI 描述指令
{
"type": "render_ui",
"layout": "step_form",
"components": [
{ "widget": "UserSelector", "props": { "default": "zhangsan" } },
{ "widget": "RoleCheckbox", "props": { "options": ["Admin", "Editor"] } }
]
}
// Oinone 前端引擎根据上述 JSON 动态渲染界面
思考一下：如果你的交互仍然只能“对话”，那你永远绕不开“确认/编辑/可视化”这些企业刚需。 GenUI 的价值，不是炫技，而是把“执行”变得可被人类监管。
7. 工程落地速查表：把“愿景”压成“最小可跑闭环”
关键术语对齐
- Metadata = System Prompt（数据上下文）
- User Intent = BPM Trigger（执行入口）
- DSL = GenUI Protocol（界面描述）
最小闭环路线（建议你就按这个顺序推进）
- 数据层：完善元数据，生成 Schema
- 逻辑层：定义 API 与 BPM 边界
- 交互层：不仅返回文本，也返回 UI 组件
度量指标（KPI）
- 提示词一致性 > 95%：元数据变更后 Prompt 自动同步率
- 规则覆盖率 100%：核心业务必须走 BPM/API 校验
加两类工程指标（增强项）：
- 回滚/补偿触发率（SAGA 是否真在起作用）
- “一次通过率”（用户意图 → BPM 成功完结的比例） 这样你能把“智能”变成可运营的生产指标，而不是 demo 演示效果。
最后的话：把 Agent 当“人”管，还是当“系统”造？
如果你把 Agent 当人，你会天天教它“注意点”“别犯错”。 如果你把 Agent 当系统，你会给它：契约、流程、状态、权限、审计、回滚。
这就是神经-符号混合架构的本质： 让 AI 负责聪明，让系统负责可靠。
