企业评估智能体软件时，最容易犯的错是把传统软件的功能清单原样搬过来。功能表可以逐项打勾，但智能体真正决定成败的，是它在没人盯着的时候做了什么、做错之后能不能收回来。成熟度评估的重点因此要从“有没有这个能力”，转向“这个能力的边界在哪里”。
先看它在不确定场景里怎么停
智能体与流程执行型软件的根本差别，在于前者要在信息不完整、路径不唯一的情况下自行决策。供应商演示时通常只展示顺利走通的路径，采购方需要追问的是失败路径：哪些条件下它会停下来请求人工确认，哪些动作它被禁止自主执行，出错后有没有可回退的状态。
这一维度很难靠概念验证（POC）得出结论。原文提到的政策导向是重点行业培育标杆应用，这意味着案例本身是可以被追问的对象——问清楚落地场景的确定性程度、上线后人工介入的比例、出现偏差时的处理方式，比看演示视频有用得多。
再看它和现有体系咬不咬得合
智能体的价值依赖上下文，而上下文来自企业的数据、权限和既有流程。一个在供应商环境里表现良好的智能体，接入企业数据治理体系后可能因为权限颗粒度不匹配而退化。所以要看的不只是模型能力，还有它对现有技术栈的适配方式，以及会不会成为一个新的孤岛。
另一个常被忽略的判断是场景选型是否合理。确定性高、需要精确计算的环节，用流程执行型软件更稳妥；智能体更适合智能决策和自主执行的场景。供应商如果对所有需求都给出智能体方案，恰恰说明它没有认真做场景切分。同理，智能编程类能力的覆盖深度也要核验：是全流程辅助，还是只做了局部环节的包装。
责任边界必须写进合同
智能体一旦自主执行，责任归属就变得模糊。数据权限如何界定、流程执行偏差由谁承担、服务中断时的运维支持到什么程度，这些不能停留在方案书里。
比较务实的做法是在续约或首次签约前，把交付责任边界逐条写入合同条款，并优先选择能与现有数据体系对接的方案。成熟度不高的供应商往往在这个环节回避细节，用“我们会配合”之类的表述带过。
评估不该是一次性的选型动作。智能体软件迭代快，供应商能力也在变，企业需要定期核验方案与自身流程、数据、权限体系的匹配度。把成熟度当成一个持续校准的过程，比在采购阶段打一个总分更接近真实风险。