智能体会自己判断后，企业该把规则写进哪一层？

一个智能体给出“建议改签这趟航班”“应该补这批货”时，真正难的往往不是它能不能想出方案，而是：谁来保证它没有越过业务红线？AWS在9月14日展示的多智能体航班改签流程，给出的答案很朴素：让智能体负责提出选项，把真正决定能否执行的判断交给确定性的工作流校验。这个分工，正在把企业AI从“提示词写得够不够细”推向一个更具体的问题：哪些规则必须被写成机器能执行的闸门？

会推理，不等于可以直接落单

语言模型擅长在不完整信息中综合线索、生成候选方案；但库存阈值、合同价格、客户等级、审批额度、禁运地区这些条件，不应靠模型“记住”。AWS的案例把推理与验证拆开：专长智能体处理方案生成，Step Functions 用确定性代码检查规则，再允许后续动作。9月14日另一篇AWS方案也把需求预测接到采购订单，但在下单前需与供应商可用量及业务规则核对；无法覆盖的需求交给人工升级。这里没有把智能体变笨，而是承认业务中存在一类不该由概率决定的事实。

模型可以负责“提出什么”，规则闸门应负责“能不能做”。两者混在一段提示词里，才是生产环境最脆弱的地方。

规则不是备注，应是一段可运行的业务资产

这件事在工厂和供应链里尤其直观。Google 9月10日披露，GE Appliances 的员工已创建800多个定制智能体；其中供应商协同智能体连接600多家服务零件供应商，并帮助减少25%的缺货订单。数字是厂商案例披露，不能当作行业平均值，但它提醒我们：智能体数量增加后，真正会被反复调用的不是某个员工的提示词，而是“什么情况下可催单、何时允许改安全库存、异常由谁接手”这些业务规则。

我建议企业先找出三类应当从提示词中“编译”出来的规则：第一类是硬约束，例如金额上限、库存下限、合规名单；第二类是条件路由，例如客户投诉达到何种程度转人工、预测偏差多大暂停自动下单；第三类是留痕要求，例如每次拦截应记录用了哪版规则、哪个字段不满足、由谁处理。前两类防止错误动作，第三类让规则本身可以被复盘和更新。

别把“可解释”留在事后

很多团队遇到一次异常，才回头追问智能体为什么这么做。但若规则只存在于自然语言提示词，事后通常只能得到“它当时这样理解”的解释；若关键条件已进入确定性闸门，则系统可以直接回答：是哪条规则、哪版阈值、哪个输入触发了放行或拦截。前者是模型叙述，后者才是业务可用的处置依据。

对STARBOX而言，这也是“组织 → BOX → 智能体”三层架构该承担的分工。组织层决定哪些规则属于不可协商的红线，以及谁有权改；BOX不只保存知识，还应保存规则版本、适用场景、输入字段和异常处理；智能体层则在这些已知闸门内完成推理、调用工具和交付。DDABC里的Define不只是定义任务，也要定义哪些判断必须可执行；Analyze和Benchmark再用拦截率、人工升级量、返工率检验规则是否合适，Calibrate才有依据把它升级到下一版。

智能体越能自己完成多步工作，企业越不能把全部业务判断塞进提示词。把会变化、需要权衡的问题留给智能体，把必须一致、必须追责的条件写成可执行规则——这不是给AI加一道束缚，而是让它真正进入业务流程的前提。下一次评审智能体项目时，不妨少问一句“它还能做什么”，多问一句：它准备跨过哪一道规则闸门？

来源：AWS《Validating multi-agent decisions with Step Functions and Bedrock AgentCore》（2026-09-14）；AWS《Automate replenishment with MMF, Databricks Genie, and Amazon Quick》（2026-09-14）；Google Cloud《Inside the agentic factory》（2026-09-10）。文中企业成效均按发布方公开案例表述。