过去一年，企业谈 AI 落地时，一个明显变化是：大家已经不满足于让 AI 写材料、查知识、回答问题，而是希望它进入采购、财务、合同、经营分析、物料治理这些更核心的业务环节。企业开始期待 Agent 不只是“帮人做”，而是能够理解问题、调用系统、形成判断，甚至推动后续动作。

沿着这个方向继续走，很容易产生一种产品想象：过去的软件按照固定规则运行，未来的 Agent 更聪明、更灵活，所以越来越多业务规则也可以交给 AI 自己理解。

但最近在设计几个企业 AI 应用时，我反复碰到一个问题：

当 AI 越来越会判断以后，我们会不会把那些原本应该保持确定的事情，也一起交给了概率性的判断？

这件事在 Demo 里不明显，到了正式业务系统里却非常重要。企业运行并不是所有事情都需要智能，有些事情恰恰需要无论谁处理、模型怎么理解、上下文怎么变化，都得到同一个结果。

所以我现在更愿意把企业 AI 的设计问题换一种问法：

什么必须由程序确定，什么可以交给 AI 判断，什么最终必须由人负责？

这三件事如果分不清，Agent 越强，系统反而越容易失去边界。

一、一个物料名称，让我重新意识到“确定性”的价值

最近在设计物料数据治理应用时，我碰到一个很典型的场景。

业务人员申请新物料时，可能输入：

“SKF轴承6205”

也可能写成：

“6205进口轴承”

或者：

“深沟球轴承 SKF 6205 25×52×15”

人基本能够看懂这些描述，但进入 ERP、SRM、WMS 以后，系统需要回答的事情马上多起来：它属于哪个分类，标准名称是什么，SKF 是品牌还是名称的一部分，6205 是型号还是规格，25×52×15 应该怎样拆成属性，历史库里是否已经存在相同物料，最后究竟应该复用已有编码还是新增编码。

这些问题当然非常适合 AI。模型可以理解非结构化描述，识别品牌型号，补充分类，拆解规格，也可以从历史库里找到几个最相似的候选物料。

但继续往下走，边界就出现了。

假设历史库里同时存在：

“6205”

“6205-2RS”

“6205 ZZ”

这三个名称文本相似度都很高，但在某些采购和技术场景里，它们未必可以被当成同一种物料。如果只依赖模型做语义相似判断，很容易把“语言相近”误判成“业务相同”。

这时候最合理的设计并不是让 AI 给出一个最终概率：

“96%可能属于重复物料。”

而是把任务拆开。

AI 负责理解描述、提取关键属性、找到历史候选；程序按照企业已经确认的关键属性规则做硬校验；如果关键属性仍然存在冲突，再交给主数据责任人处理。

于是系统形成的不是“AI替代规则”，而是：

AI处理模糊性，程序守住一致性，人处理规则覆盖不了的例外。

这个案例让我越来越确定，企业 AI 做得越深，越不能把“智能”理解成所有事情都让模型说了算。

二、企业每天处理的，其实是两类完全不同的问题

很多企业 AI 产品设计一开始就容易混淆一件事：有些业务问题需要判断，有些业务问题根本不需要判断。

第一类是确定性问题。

超过预算不能提交，没有供应商准入资格不能参与询价，合同金额超过某个额度必须进入指定审批层级，同一关键属性组合不能存在两个有效物料编码，付款金额不能超过已确认应付，某类敏感数据只能由特定角色访问。

这类问题的核心不在于系统是否“理解得足够聪明”，而在于企业已经明确决定了怎样处理，并希望每一次都得到相同结果。

第二类是判断性问题。

供应商这次涨价是否合理，一个看起来相似的物料到底是不是同一种技术对象，某个区域利润下降究竟是经营异常还是战略投入导致的阶段性结果，合同里某项责任安排虽然偏离模板，但在当前交易条件下是否值得接受。

这些问题很难提前穷举所有条件，需要结合事实、证据、上下文、专业经验和当前目标形成判断。

所以企业 AI 并不是简单从“规则系统”升级成“智能系统”。

更准确的分工是：

确定的事情，让程序保证一致性；不确定的事情，让 AI 帮助形成判断；涉及授权与责任的事情，再交回组织。

问题的难点从来不是二选一，而是如何划清边界。

三、但“程序说了算”也不是天然正确，因为边界本身是人画出来的

这里必须进一步追问一个问题：

如果程序负责确定性，那么这些规则是谁定义的？

答案当然不是程序自己。

假设企业规定：

同一租户、同一物料分类、同一品牌、同一型号、同一关键规格组合，不允许存在两个有效编码。

这条规则本身，其实也是企业过去做过的一次管理判断。

企业先判断“哪些字段足以定义同一种物料”，再把这个判断固化成系统规则，之后程序才可以稳定执行。

所以所谓“程序说了算”，并不是把判断权交给了程序，而是：

把企业已经形成共识、希望反复得到同样结果的判断固化下来。

这点很重要。

因为规则不是客观真理，它只是组织过去判断的制度化结果。业务环境变化以后，原来的规则也可能失效。

比如某类物料过去只需要型号和尺寸就能够判断是否重复，后来由于质量等级、认证标准或应用场景发生变化，原来的唯一性规则可能已经不够用了。

这时候程序不能自行修改规则，AI也不能偷偷绕过规则。

合理的机制应该是：

人形成规则 → 程序稳定执行 → AI发现异常和例外 → 人重新判断 → 必要时修改规则

所以确定性需要被固化，但固化不能变成不可修改。

这也把企业 AI 里的一个重要治理问题说清楚了：

边界必须由组织定义，程序负责执行边界，AI可以帮助发现边界失效的地方，但没有权力自行改写边界。

四、如果把“确定性”和“复杂性”放在一起，企业任务大致可以分成四类

前面讨论过判断链，解决的是一个问题怎样从事实、证据、解释走向判断和行动。这里讨论的是另外一个问题：

有哪些事情根本不应该进入开放式判断，而应该在进入判断链以前就被规则截住。

把“确定性”和“复杂性”放在一起，企业任务可以粗略分成四个区域。

第一类是高确定、低复杂。

例如字段完整性、金额校验、权限控制、状态流转、唯一性检查。这类事情没有必要调用大模型，普通程序更便宜、更快、更稳定，也更容易审计。

第二类是高确定、高复杂。

企业知道规则是什么，但判断输入是否满足规则并不简单。

合同就是一个很好的例子。企业可以明确规定：

出现无限责任条款，必须升级法务负责人。

规则本身非常确定，但一份几十页合同里，某段自然语言到底有没有构成“无限责任”，并不是普通 if-else 可以轻易完成的。

这时候合理分工是：

AI负责理解条款，程序负责执行升级规则。

物料治理也是一样。AI可以理解描述、识别候选和判断相似，但“哪些关键属性冲突时禁止自动合并”“什么条件触发人工复核”，应该由规则控制。

第三类是低确定、低复杂。

例如会议摘要、材料整理、邮件草拟。这些任务存在一定不确定性，但业务风险低，可以让 AI 大量自动完成。

第四类是低确定、高复杂。

供应商涨价合理性、经营异常归因、战略客户政策调整、重大合同风险是否值得接受，都属于这一类。

这里没有一条确定规则可以直接给出答案，AI可以帮助寻找事实、组织证据、补充上下文、提出竞争解释、寻找反证，再形成当前判断。

但到了资源承诺、正式授权和责任承担，系统仍然需要重新进入人的制度体系。

所以一个成熟的企业 AI 应用，很少会是“全部交给 AI”，也不应该是“全部写成规则”。

它更像三种能力协作：

程序固化确定性，AI处理不确定性，人定义并修改边界，同时承担最后责任。

五、这也解释了为什么很多 Agent Demo 很漂亮，上线却很困难

Demo 天然喜欢连续性。

用户输入一句话，Agent 理解问题、查数据、调工具、分析原因、生成方案，最后直接执行。整条链越长，展示出来越聪明。

但企业正式系统关心的是另一组问题。

同一个问题明天为什么会得到不同答案？业务规则修改以后，哪些 Agent 会受影响？为什么这次可以直接执行，上次却必须人工确认？审计人员能不能重建当时发生了什么？制度里已经明确写死的要求，为什么最后变成了 Prompt 里的自然语言？

这些问题一出现，就会发现：

企业系统追求的不是每个环节都智能，而是该确定的地方足够确定，该判断的地方足够聪明。

这两种目标并不相同。

模型追求适应性，规则追求一致性；模型擅长理解例外，规则负责控制例外；模型能够随着上下文变化判断，制度却要求某些边界不因上下文改变。

如果产品设计没有把两种机制分开，最终就容易出现一种很危险的系统：

什么都能理解，但没人说得清它究竟按照什么运行。

所以企业 Agent 上线难，并不只是因为模型准确率还不够。

很多时候，是因为 Demo 把所有事情都设计成了“智能判断”，正式系统却必须重新把其中一部分还原成确定性的制度边界。

六、企业 AI 的 PRD，未来需要多一张“决策机制表”

这也是为什么最近做企业 AI 产品设计时，我越来越不愿意只列功能。

“供应商报价分析”“物料智能查重”“合同风险识别”“经营异常分析”这些名称只能说明系统要做什么，却没有回答：

做到某一步以后，到底谁说了算？

我更建议在企业 AI PRD 里增加一张决策机制表。

这张表看起来一点都不“炫技”，但它比很多 Agent 流程图更接近企业是否敢上线的核心。

因为它逼着产品团队回答：

我们到底把什么权力交给模型？

模型可以建议，但有没有决定权？

模型可以识别异常，但有没有权改变状态？

模型可以生成方案，但有没有权直接执行？

技术能力不能偷偷变成组织授权。

这也是企业 Agent 与消费级 AI 最不同的地方之一。

七、小企业也不需要把这件事做得很复杂

对规模不大的企业来说，这套方法不需要一开始就建设复杂的治理体系。

完全可以从最简单的一张表开始。

把准备交给 AI 的十几个关键任务列出来，每一项只回答三个问题：

这件事有没有明确规则？AI可以判断到哪一步？最后谁承担责任？

如果企业已经能清楚回答这三个问题，大部分边界其实就已经出现了。

真正危险的不是没有复杂框架，而是所有事情最后都变成一句：

“让 Agent 自己判断。”

因为这句话背后经常隐藏着三种没有被明确说出来的东西：

规则没有被定义，授权没有被设计，责任没有被分配。

企业规模越小，反而越应该把这三件事说简单、说清楚，而不是为了“智能化”把原来清楚的规则重新变模糊。

八、成熟的企业 AI，未必看起来那么“智能”

我越来越怀疑，未来真正成熟的企业 Agent，界面上未必会像今天很多 Demo 那么神奇。

它不会每件事都自己决定。

有些地方它会直接告诉你：

这是明确规则，我没有判断空间。

有些地方它会说：

我可以分析，但最后需要责任人确认。

有些地方它会主动停止：

当前证据不足，还不能进入下一步。

有些地方甚至根本不会调用大模型，因为一个 SQL、一个规则表达式或者普通校验程序已经能够百分之百解决。

从展示效果看，这种系统没有“一个 Agent 包办一切”那么刺激。

但从企业运行看，它反而更成熟。

因为企业需要的不是软件表现得越来越像一个无所不能的人，而是让不同类型的问题进入合适的机制。

程序负责重复执行已经形成共识的规则，AI负责处理规则无法覆盖的复杂情境，人负责定义边界、修改边界，并对重大结果承担责任。

边界也不会一次画死。

业务变化会让旧规则失效，AI可能发现新的例外，人的经验也会不断改变组织判断。企业需要做的，是让这张边界图能够被持续验证和修正，却始终保持清楚。

所以企业 AI 下一阶段值得建设的，也许并不是更多 Agent。

而是一张越来越清晰的边界图：

为什么这件事必须由程序确定，为什么那件事可以交给 AI 判断，又为什么到了某一步必须重新交给人。

当这张图逐渐清楚以后，企业拥有的才不只是更多智能。

而是一套知道哪里需要确定，哪里允许判断，哪里必须有人负责的运行机制。