本文为工程实践复盘，客户信息已脱敏，文中数据均为项目复盘口径的脱敏示意值。

一、项目背景

营销、风控、定价这些策略原来散落在代码和散落的配置里，改一条规则要走发版流程，业务那边等不及，就偷偷在数据库里改值，出过好几次线上事故。我们想让策略可配置，同时让智能体在画定的边界内自动执行，而不是每次都等人点。但这两者叠加，风险也成倍放大：策略一旦能自动执行，错的代价比以前高得多。

这件事的张力在于，业务要快、要自动化，风控要稳、要可控。我们得在中间找平衡点，既不能回到发版两周的慢节奏，也不能把执行权完全交给机器，否则一次坏策略就能在分钟级扩散到全量用户。

最让我们警醒的是一次手工改库的事故。某业务同学为了赶活动，直接在数据库改了定价参数，没走任何评审，结果字段类型不一致导致整批 SKU 的到手价算错，大半天之后才被财务对账发现。那次之后我们达成一个共识：策略必须收口到统一中心，任何改动都要留痕、可回退，不能再有数据库里的暗箱操作，智能体自动执行只是把收口后的策略跑起来，而不是放开管控。

二、落地场景

我们建了可视化策略编排，运营拖拽就能配规则，规则加模型混合决策。智能体在策略约束下行动，比如自动圈选人群、自动发券，但额度、频次、品类都受策略沙箱管着。策略走灰度，小流量验证后再全量，效果可回看。

落地后运营配策略从求研发变成自己拖。智能体负责执行那些重复、可标准化的动作，人只做审核和兜底。每次策略变更都有版本和审批留痕，出了问题能精确追责到哪次改动。

为了让业务方敢用，我们设计了策略的预览和模拟能力：一份新策略在发布前，可以先在历史流量上跑一遍影子模拟，看到预计触达人数、预估成本和可能的风险点，确认没问题再进灰度。这个前置环节把很多明显有问题的策略挡在了生产之外，也减少了运营因为看不懂自己配的策略而出错的概率。

三、关键技术挑战与解决思路

策略与代码解耦靠的是把决策逻辑外置成规则加模型的两段式，代码只做执行引擎。规则模型混合决策时，硬规则优先，模型做软性排序和建议，互不越界。智能体边界约束是关键，我们给智能体的每个动作都挂了策略校验，超额度、超频次直接拦下。灰度与回滚靠策略版本化，出问题一键回退到上一版。

这里有个真教训：早期我们把执行权几乎全交给智能体，策略沙箱只拦了额度，没拦频次，结果一次配置失误让它对同一批用户连发了好几轮券。后来沙箱补齐了频次、品类、时间窗多维度约束，并且所有智能体动作前强制过校验，才把风险真正关进笼子。

还有个容易忽略的点是策略之间的冲突。运营各自配策略，营销发券和风控拉黑可能在同一批用户上打架，出现过一边发券一边把人限掉的情况。我们后来建了策略优先级和互斥关系表，冲突时按业务排序裁决，并在编排界面把潜在冲突直接标红提示，避免运营配出互相矛盾的组合。策略中心管的不只是单条策略，更是策略之间的秩序。

案例片段（已脱敏）：策略沙箱与约束配置。

yaml policy:  sandbox:    max_amount: 5000    max_freq_per_user: 1    max_window_hours: 24  agent_action: validated_before_run  rollback: one_click

一段回滚记录：某次新策略灰度 5% 后发现转化异常，运营一键回退到上一版，从发现到恢复不到三分钟，没扩散到全量，影响被控制在极小范围。

四、效果数据

策略上线周期从发版的数天压到小时级，策略命中准确率约 93%。人工干预率从约四成降到一成。灰度回滚时长中位数约 3 分钟。这些数字为示意口径。

五、可复用经验总结

策略中心不能把执行权全交给智能体，那等于把钥匙给了不睡觉的员工。我们灰度期一次策略配置失误，智能体在没护栏的情况下刷了一波错券，财务追了半天才平掉。后来所有智能体动作前都强制过策略沙箱，额度频次卡死，才敢把自动化程度往上提。

可视化编排降低了业务的使用门槛，但越是好用越要把护栏做厚，方便和失控之间只差一道校验。灰度千万别省，哪怕是看起来很稳的小改，我们也坚持先 5% 再全量，几次险些翻车的都靠灰度兜住了。

结语

策略中心跑下来，业务侧最满意的是上线周期从天级变小时级，我们最满意的是再没出过那次错券事故。护栏和灰度是两根支柱，少一根都不行，护栏管住单次动作不越界，灰度管住变更不扩散。我们后来把常见策略做成模板，运营拖拽即可，几乎不用研发介入。如果重来，我会在沙箱里更早加入时间窗约束，那次连发多轮券的教训够深刻，频次这个维度当初确实想简单了，同时也会把策略冲突检测做成标配，免得营销和风控在同一批人身上打架。