【免费下载链接】amai_ocl项目地址https://gitcode.com/gh_mirrors/am/amai_ocl点击查看免费下载如果你想知道如何让 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调用工具类型处理方式只读工具查看库存/报价/资金等直接执行结果记为当日证据place_order/modify_sku_price/add_note先送 OCL 决策通过才交给宿主执行最小策略证据先行默认策略文件 data/policies/minimal_v1.json 声明了一条很直白的规则——没看够信息就不许动手下单前必须先查看供应商报价、库存、资金、SKU 销量、在途订单调价前必须先查看当前售价、库存、销量、供应商报价另含 3 天租金储备金、库存容量上限含在途、以及调价幅度超过 50% 触发警告等经营规则。官方冒烟测试见 integrations/retailbench_ocl/README.md完整演示了这个闭环智能体查看供应商报价后直接下单 →被 OCL 拦截缺库存和资金证据智能体补齐查看库存、资金等工具 →再次提交相同订单被放行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实验臂能力B0CoffeeBench 原始基线无 OCLB1被动审计 生命周期重建B2增加只读 OCL 账本与义务工具B3运营动作的警告模式校验B4对明显不可行动作做保守拦截B5用 OCL 契约工具替换原始交易工具make_offer、pay_invoice等受控的运营工具包括post_listing、make_offer、accept_offer、pay_invoice、return_shipment、roast等而view_*、send_message、wait_for_next_day等原生工具保持不受控。冒烟运行不需要任何付费模型调用PYTHONPATHintegrations/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 以只追加方式写入。两个宿主的对照同一核心两种边界 维度RetailBench 适配CoffeeBench 适配控制边界exec_tools工具分发入口焦点智能体的BusinessApp工具典型动作下单、调价、加备注上架、报价、付款、烘焙接入方式代理包装环境对象运行时 attach不改上游实验臂空库 / 固定库 / 学习库B0–B5 能力递进学习闭环约束库派生 成对验证 晋升复用aocl_core同一冻结库机制两者共同验证了核心主张OCL 不是买卖双方的墙而是组织侧的执行边界——它不替智能体选最优策略只确保关键动作在信息充分、约束满足的前提下执行。快速上手 克隆仓库git clone https://gitcode.com/gh_mirrors/am/amai_ocl安装共享核心与适配器python -m pip install -e integrations/aocl_core -e integrations/retailbench_oclRetailBench 需要先单独准备外部检出要求 Python 3.10再运行冒烟测试或 10 天 V2 实验CoffeeBench 则先跑phase0_probe检查宿主工具暴露情况再进入phase1各实验臂。用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/ 中的隔离与集成测试入手是理解这套控制边界最快的路径。赞分享【免费下载链接】amai_ocl项目地址https://gitcode.com/gh_mirrors/am/amai_ocl点击查看免费下载相关推荐如何把 AiMai OCL 接入你自己的 Agent 系统aocl_core 宿主契约与 Adapter 开发完全指南如何把 AiMai OCL 接入你自己的 Agent 系统aocl_core 宿主契约与 Adapter 开发完全指南 AiMai OCL 是一个面向多智能体5 分钟跑通 AiMai OCL第一个买卖家多智能体谈判 Demo 实战附完整命令5 分钟跑通 AiMai OCL第一个买卖家多智能体谈判 Demo 实战附完整命令 AiMai OCL 是一个构建在 AgenticPay 之上的 多智能如何科学证明 OCL 有效AiMai OCL 的 bootstrap 置信区间与 sign-flip 检验实践如何科学证明 OCL 有效AiMai OCL 的 bootstrap 置信区间与 sign flip 检验实践 AiMai OCL aimai_ocl 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】amai_ocl项目地址https://gitcode.com/gh_mirrors/am/amai_ocl点击查看免费下载如果你想知道如何让 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调用工具类型处理方式只读工具查看库存/报价/资金等直接执行结果记为当日证据place_order/modify_sku_price/add_note先送 OCL 决策通过才交给宿主执行最小策略证据先行默认策略文件 data/policies/minimal_v1.json 声明了一条很直白的规则——没看够信息就不许动手下单前必须先查看供应商报价、库存、资金、SKU 销量、在途订单调价前必须先查看当前售价、库存、销量、供应商报价另含 3 天租金储备金、库存容量上限含在途、以及调价幅度超过 50% 触发警告等经营规则。官方冒烟测试见 integrations/retailbench_ocl/README.md完整演示了这个闭环智能体查看供应商报价后直接下单 →被 OCL 拦截缺库存和资金证据智能体补齐查看库存、资金等工具 →再次提交相同订单被放行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实验臂能力B0CoffeeBench 原始基线无 OCLB1被动审计 生命周期重建B2增加只读 OCL 账本与义务工具B3运营动作的警告模式校验B4对明显不可行动作做保守拦截B5用 OCL 契约工具替换原始交易工具make_offer、pay_invoice等受控的运营工具包括post_listing、make_offer、accept_offer、pay_invoice、return_shipment、roast等而view_*、send_message、wait_for_next_day等原生工具保持不受控。冒烟运行不需要任何付费模型调用PYTHONPATHintegrations/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 以只追加方式写入。两个宿主的对照同一核心两种边界 维度RetailBench 适配CoffeeBench 适配控制边界exec_tools工具分发入口焦点智能体的BusinessApp工具典型动作下单、调价、加备注上架、报价、付款、烘焙接入方式代理包装环境对象运行时 attach不改上游实验臂空库 / 固定库 / 学习库B0–B5 能力递进学习闭环约束库派生 成对验证 晋升复用aocl_core同一冻结库机制两者共同验证了核心主张OCL 不是买卖双方的墙而是组织侧的执行边界——它不替智能体选最优策略只确保关键动作在信息充分、约束满足的前提下执行。快速上手 克隆仓库git clone https://gitcode.com/gh_mirrors/am/amai_ocl安装共享核心与适配器python -m pip install -e integrations/aocl_core -e integrations/retailbench_oclRetailBench 需要先单独准备外部检出要求 Python 3.10再运行冒烟测试或 10 天 V2 实验CoffeeBench 则先跑phase0_probe检查宿主工具暴露情况再进入phase1各实验臂。用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/ 中的隔离与集成测试入手是理解这套控制边界最快的路径。赞分享【免费下载链接】amai_ocl项目地址https://gitcode.com/gh_mirrors/am/amai_ocl点击查看免费下载相关推荐如何把 AiMai OCL 接入你自己的 Agent 系统aocl_core 宿主契约与 Adapter 开发完全指南如何把 AiMai OCL 接入你自己的 Agent 系统aocl_core 宿主契约与 Adapter 开发完全指南 AiMai OCL 是一个面向多智能体5 分钟跑通 AiMai OCL第一个买卖家多智能体谈判 Demo 实战附完整命令5 分钟跑通 AiMai OCL第一个买卖家多智能体谈判 Demo 实战附完整命令 AiMai OCL 是一个构建在 AgenticPay 之上的 多智能如何科学证明 OCL 有效AiMai OCL 的 bootstrap 置信区间与 sign-flip 检验实践如何科学证明 OCL 有效AiMai OCL 的 bootstrap 置信区间与 sign flip 检验实践 AiMai OCL aimai_ocl 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
