工信部“人工智能+软件”专项行动落地：企业采购软件应核验智能体能力与交付模式

工业和信息化部近日印发《“人工智能+软件”专项行动实施方案》，并于9月11日举行专场新闻发布会介绍有关情况。对于正在做软件选型和采购预算的企业来说，这份文件的价值不在于政策口号，而在于它重新定义了“什么样的软件值得买”。方案明确到2028年，智能编程工具和智能开发平台推广应用覆盖2万家规模以上软件企业，累计组织实施100项软件企业智能化技改项目，在重点行业打造100个智能体软件标杆应用；到2030年，关键软件全面实现智能化升级，智能编程、智能体软件及智能服务等新业态成为产业新增长极。

这些数字背后是一条清晰的判断：软件的产品形态和交付方式正在被改写。采购方如果继续沿用“功能清单比对+一次性买断”的旧框架，很可能在合同签署的那一刻就已经落后。

从“功能交付”到“价值交付”，采购标的变了

方案提出信息技术服务要向智能化、价值化跃升，这一表述直接指向交付模式的转变。

传统软件采购的标的相对清晰：模块数量、并发数、部署方式、验收用例。而智能体软件的核心能力是自主规划、调用工具、完成多步骤任务，它的价值高度依赖具体业务场景和数据环境。同一套智能体，接入不同的知识库和系统权限，效果可能相差数倍。这意味着采购方很难再用静态的功能清单锁定交付物。

更现实的做法是把采购标的从“软件产品”调整为“可度量的业务结果”。例如，合同可以约定智能体在特定场景下的任务完成率、人工接管率、平均处理时长等指标，并按阶段验收。方案中“形成一批行业深度应用解决方案和典型场景”的表述，也说明政策层面鼓励的是场景化落地，而非通用能力的堆砌。

供应商评估清单：五个必须核验的维度

从采购与验收视角看，方案提出的目标可以翻译成一组可执行的尽调问题。

智能体工程化能力。 方案强调培育高水平智能编程工具和智能开发平台，采购方应追问供应商：智能体是基于自研框架还是套壳调用？是否具备任务分解、工具编排、失败重试、上下文管理等工程能力？有没有可复现的评测集和版本迭代记录？只会演示对话效果的供应商，通常不具备工程化交付能力。

交付模式与责任边界。 方案提及发展“模型即服务”“智能体即服务”等新业态。采购方需要明确：供应商交付的是模型调用额度、智能体运行时，还是包含数据治理、系统集成、持续调优的整体服务？模型更新导致行为漂移时，由谁负责回归测试？服务等级协议是否覆盖智能体特有的失效模式？

数据与安全可控性。 方案将“安全可控”列为基本原则之一。采购方应核验供应商的数据隔离方案、是否支持私有化或专有云部署、训练数据是否可追溯、智能体调用外部工具时是否有权限收敛机制。对于金融、能源、制造等敏感行业，这一项的权重应显著高于价格。

与基础软件、工业软件的适配能力。 方案明确关键软件智能化升级是重点任务。企业现有ERP、MES、PLM等系统能否被智能体安全调用，接口是否标准化，供应商是否有同类系统的集成案例，直接决定项目周期和隐性成本。

开源治理与长期维护。 方案提出孵化5个以上优质开源项目，开源社区建设取得积极进展。采购方可以关注供应商是否参与相关开源项目、核心组件是否依赖单一上游、许可证是否存在商用风险。这关系到系统三到五年后的可维护性。

验收标准需要重写

交付模式变了，验收方式也必须跟着变。过去验收看的是“功能是否可用”，现在至少需要补充三类测试。

一是场景回归测试。选取若干真实业务任务，在版本更新前后分别运行，观察任务完成质量和稳定性是否退化。二是边界与安全测试。验证智能体在权限不足、数据缺失、指令冲突等异常条件下的行为是否符合预期，是否会越权调用或产生不可控输出。三是人机协作测试。测量业务人员从“提出需求”到“确认结果”的实际耗时，以及需要人工干预的比例。方案提出信息技术服务向智能化、价值化跃升，价值最终要体现在这些可量化的运营指标上。

企业现在可以做的三件事

政策窗口期通常伴随供应商的能力包装冲动。建议采购方在近期项目中先做三件事：在招标文件中增加智能体工程化能力的评分项，要求供应商提供可验证的评测数据；在合同中明确模型更新、数据使用和服务连续性的责任条款；对存量软件合同进行梳理，识别哪些系统需要预留智能体接入的接口和权限。

《“人工智能+软件”专项行动实施方案》给出的时间表是到2028年、到2030年，但企业采购决策的调整不能等到那时。把政策目标翻译成评估清单和验收标准，才是这一轮软件智能化升级中采购方最实际的准备。