从谈判对话到零售经营：AiMai OCL 接入 RetailBench 与 CoffeeBench 的多宿主适配实战

如果你想知道如何让 AI 智能体在"谈判对话"之外，还能安全地管理一家真实的小店，这篇文章会带你完整走一遍AiMai OCL（组织控制层，Organizational Control Layer）的多宿主适配实践。项目aimai_ocl研究的问题是：当语言智能体执行经济交互任务时，能否通过一层显式控制平面，在动作真正执行前进行审批、改写、拦截或升级，从而提升可靠性与约束满足性。仓库中的integrations/目录正是答案所在——它把同一套 OCL 核心分别接入RetailBench（零售经营）和CoffeeBench（咖啡烘焙经营）两个宿主基准，实现"一套控制平面，多个宿主环境"。

为什么需要多宿主适配 🧩

在 README.md 中，项目把研究问题归纳为三条：

• 如何把原始语言动作映射为可执行的经济动作？
• 系统应当在什么情况下批准、改写、阻断或升级一个动作？
• 在部分可观测、多轮交互条件下，平台侧控制应如何被评估？

早期 OCL 只在 AgenticPay 的交易对话边界上做检查（"这轮报价是否越界"）。而零售和咖啡经营场景更复杂：智能体要跨越多天做补货、调价、结算、生产等运营动作。如果每个基准都重写一遍控制逻辑，经验就无法积累。

因此项目采用分层架构：

aocl_core（环境无关的 OCL 核心） ├── retailbench_ocl → RetailBench 宿主适配 ├── coffeebench_ocl → CoffeeBench 宿主适配 └── agenticpay_ocl_v2 → 谈判对话宿主适配

核心模块 integrations/aocl_core/ 的设计原则是：核心永远不 import 任何基准、永远不执行宿主动作。宿主适配器只负责把原生工具边界归一化为四份契约：

ProposedAction + ObservableContext → IntegrationOCLRuntime → ControlDecision 宿主执行 → ObservedOutcome

这意味着换一个宿主，只需要新写一个薄适配器，控制和"约束库学习"能力全部复用。

RetailBench 实战：把 OCL 接到零售下单入口 🛒

RetailBench 提供了一个零售模拟环境：智能体需要查看供应商报价、库存、资金和销量，然后决定是否下单（place_order）或调价（modify_sku_price）。适配入口在 integrations/retailbench_ocl/src/retailbench_ocl/adapter.py，它是一个"代理层"——不修改 RetailBench 上游任何代码，只包裹exec_tools调用：

最小策略：证据先行

默认策略文件 data/policies/minimal_v1.json 声明了一条很直白的规则——没看够信息就不许动手：

• 下单前必须先查看：供应商报价、库存、资金、SKU 销量、在途订单；
• 调价前必须先查看：当前售价、库存、销量、供应商报价；
• 另含 3 天租金储备金、库存容量上限（含在途）、以及"调价幅度超过 50% 触发警告"等经营规则。

官方冒烟测试（见 integrations/retailbench_ocl/README.md）完整演示了这个闭环：

1. 智能体查看供应商报价后直接下单 →被 OCL 拦截（缺库存和资金证据）；
2. 智能体补齐查看库存、资金等工具 →再次提交相同订单被放行；
3. RetailBench 真实生成订单并扣减资金，全程无 LLM 调用，仅验证控制边界。

10 天真实 LLM 经营实验

用retailbench-ocl-v2入口可以让 Qwen 智能体跑 10 天真实经营。V2 流程为：

RetailBench LLM → 硬约束 → 约束库检索 → OCL 决策 → RetailBench exec_tools → 审计轨迹

仓库中留存的运行报告 outputs/retailbench_ocl/v2_full_teacher/run-20260916T234102Z/report.json 展示了结果：10 天内 20 个受控经营动作，OCL 拦截 14 次、放行 6 次，执行的策略违规为 0，且没有出现"无违规却被误拦"的情况。每次运行还会写出policy_feedback.json、learning_trace.json、每日 checkpoint 和 SQL 记录，便于事后审计。

从失败中学到第一条"防重复下单"经验 📚

更关键的是 bank_experiment 实验：系统从一次"重复采购失败"中自动派生候选约束，并在独立的风险/正常场景上做成对验证后才晋升进约束库。留存的实验报告 outputs/retailbench_ocl/bank_experiment/run-20260917T002244Z/report.json 显示，LLM 派生出了avoid_duplicate_sku_orders规则（同一 SKU+供应商已有未交付订单时拒绝新订单），成对验证通过：执行违规从 1 降到 0，有效成功从 1/2 升到 2/2，正常场景零误拦。

注意：这不是重新训练模型，而是一套"总结经验 → 独立验证 → 冻结版本 → 按需调用"的经验管理机制。

CoffeeBench 实战：控制一家烘焙店的日常经营 ☕

CoffeeBench 的宿主适配在 integrations/coffeebench_ocl/。它附着在焦点智能体roaster_A（一家烘焙店）的BusinessApp工具边界上，不重写基准的市场、账务、配送和账本机制。

与 RetailBench 不同，CoffeeBench 的适配更强调能力递进，定义了 B0–B5 六个实验臂（见 src/coffeebench_ocl/runtime.py）：

受控的运营工具包括post_listing、make_offer、accept_offer、pay_invoice、return_shipment、roast等，而view_*、send_message、wait_for_next_day等原生工具保持不受控。冒烟运行不需要任何付费模型调用：

PYTHONPATH=integrations/aocl_core/src:integrations/coffeebench_ocl/src \ python -m coffeebench_ocl.phase1 \ --arm B3 --model passive --models roaster_A:heuristic_roaster \ --max-days 3 --output-dir outputs/coffeebench_ocl/b3_smoke

运行后会在输出目录生成run.events.jsonl、run.ocl.jsonl、run.ocl.summary.json和run_report.json，审计日志由 src/coffeebench_ocl/audit.py 以只追加方式写入。

两个宿主的对照：同一核心，两种边界 🎯

两者共同验证了核心主张：OCL 不是买卖双方的"墙"，而是组织侧的执行边界——它不替智能体选最优策略，只确保关键动作在信息充分、约束满足的前提下执行。

快速上手 🚀

1. 克隆仓库：git clone https://gitcode.com/gh_mirrors/am/amai_ocl
2. 安装共享核心与适配器：

python -m pip install -e integrations/aocl_core -e integrations/retailbench_ocl

3. RetailBench 需要先单独准备外部检出（要求 Python 3.10+），再运行冒烟测试或 10 天 V2 实验；CoffeeBench 则先跑phase0_probe检查宿主工具暴露情况，再进入phase1各实验臂。
4. 用pytest跑对应测试目录，如pytest -q integrations/coffeebench_ocl/tests。

各适配器的完整命令与参数说明，建议直接阅读 integrations/retailbench_ocl/README.md、integrations/coffeebench_ocl/README.md 与 integrations/aocl_core/README.md；阶段性中文进展可参考 integrations/PROGRESS_UPDATE_ZH.md。

总结与展望

这篇文章带你走完了 AiMai OCL 从"谈判对话安全控制"走向"可积累经营经验"的关键一步：

• 架构上：aocl_core提供环境无关的决策契约，宿主适配器保持极薄，换环境不重写核心；
• 效果上：RetailBench 10 天实验中执行违规归零，且从真实失败中学到并验证了第一条可复用约束；
• 方法上：约束库只增不改、成对验证后才晋升，评估期间库版本冻结，保证实验可复现。

项目官方也明确提示：当前数字属于"最小闭环验证"而非最终统计结论，后续方向包括更多攻击类型、更多模型与重复实验、经验跨场景迁移，以及"多日经营中能否减少重复犯错"这一核心问题。对于想研究多智能体治理的读者，从 tests/ 中的隔离与集成测试入手，是理解这套控制边界最快的路径。