工信部“人工智能+软件”专项行动释放哪些信号：企业采购应关注智能体应用与实施能力

工业和信息化部印发《“人工智能+软件”专项行动实施方案》后，软件行业的智能化建设开始从单点试用转向产品、开发、服务和治理协同推进。方案提出，到2028年推广应用覆盖2万家规模以上软件企业，培育一批高水平智能编程工具和智能开发平台，并在重点行业打造100个智能体软件标杆应用。对企业管理者和软件采购方而言，这释放出的核心信号是：评估人工智能项目，不能只看模型能力或演示效果，还要看能否嵌入业务流程、连接企业数据、稳定交付并接受持续治理。

从政策目标看软件行业的变化重点

《实施方案》将“人工智能+软件”拆分为相互关联的几个方向：推动软件生产方式变革，加快软件产品智能化升级，培育智能体软件新业态，拓展智能软件服务，同时夯实软件智能化发展的基础。

其中，软件企业被放在智能化转型的核心位置。政策解读提出，企业可以沿着“做强开发能力、做优产品供给、做活服务模式”三个路径推进转型。这意味着人工智能不再只是软件厂商内部的研发工具，也不只是产品中增加一个对话入口，而是可能同时改变研发流程、产品形态和服务交付方式。

对采购方来说，政策目标并不等于某一种产品会被统一采购，也不意味着所有企业都需要立即建设复杂的智能体平台。更现实的变化是，企业在制定软件规划时，需要把智能编程、行业智能体、数据基础和安全治理放在同一张评估表中。

智能编程将从效率工具进入工程体系

方案提出培育高水平智能编程工具和智能开发平台，并在需求分析、代码生成、测试验证等研发环节推动工具应用。这对软件企业的影响，首先体现在研发过程的重新组织。

过去，企业引入开发工具时，常以代码补全、自动生成或开发效率提升作为主要评价标准。随着应用范围扩大，智能编程平台需要回答更多工程问题：

• 能否接入企业现有的代码仓库、需求管理和测试体系；
• 是否支持权限控制、操作留痕和结果审查；
• 生成代码能否纳入现有的评审、构建和发布流程；
• 能否覆盖需求分析、编码、测试验证等多个阶段，而不是只提供单点生成；
• 当生成结果出现缺陷、漏洞或版权争议时，是否有明确的责任和处置机制。

政策解读还提到，要强化人工智能生成代码安全，指导企业建立生成代码安全审查机制，并推动重点行业新上线软件在上线前开展安全检测。由此看，智能编程采购的验收标准不能只设定“节省多少人力”或“生成多少代码”，还应纳入缺陷率、测试覆盖、人工复核、漏洞发现和上线质量等工程指标。

对于产品与技术团队，比较稳妥的路径是先选择边界清晰、风险可控的研发环节开展试用，再根据实际效果扩展到更长的研发链路。智能编程的价值不在于完全替代开发人员，而在于能否提升团队处理重复性工作、知识检索和测试验证的效率，同时保持研发质量可控。

智能体软件采购，重点不应停留在“会不会对话”

《实施方案》将智能体软件视为大模型与软件深度融合形成的新形态。相较于传统问答应用，智能体软件具备感知、记忆、决策、交互与执行能力，有望推动应用功能重组和跨系统协作。

这对企业采购提出了更高要求。一个能够回答问题的模型，并不等于一个可以承担业务任务的智能体。企业需要进一步确认，供应商是否能够把智能体嵌入具体流程，例如业务查询、工单处理、知识检索、运营分析、研发辅助或跨系统任务协同。

采购评估可以围绕五个问题展开：

1. 场景是否具有明确价值。

项目应对应可识别的业务问题，如缩短处理时间、减少重复操作、提高信息检索效率或改善服务响应，而不是以“建设智能化能力”作为唯一目标。

1. 任务边界是否清晰。

智能体可以执行哪些动作，哪些环节必须由人员确认，出现异常时如何暂停或回退，都应在方案中明确。

1. 系统集成是否可行。

智能体如果无法连接业务系统、主数据、权限体系和流程引擎，往往只能停留在演示层面。采购时应核查接口能力、身份认证、数据调用范围和系统兼容性。

1. 输出结果是否可验证。

对关键业务，不能只验收回答是否流畅，还要验证事实准确性、引用依据、任务完成率、异常识别能力和人工接管机制。

1. 运行成本是否可持续。

除初始建设费用外，还要考虑模型调用、数据治理、知识库维护、系统运维、版本迭代和人员培训等长期成本。

数据基础决定智能体能否从试点走向规模化

智能体项目经常在演示阶段表现良好，但进入真实业务后效果下降，原因通常不只在模型本身，也与企业数据质量和业务流程有关。

企业在启动项目之前，应先梳理数据来源、数据权属、更新频率、质量状况和访问权限。对于分散在不同系统中的客户、产品、订单、设备或项目数据，需要明确主数据口径，避免智能体在不同系统之间读取到相互矛盾的信息。

知识库建设也不能简单理解为“上传一批文件”。文档是否过期、内容是否重复、权限是否分级、专业术语是否统一，都会影响检索和执行结果。对于需要调用实时数据的场景，还应区分静态知识检索与业务系统实时查询，避免把过期文档当成当前状态。

因此，企业软件采购中的数据评估，应从“供应商能否提供知识库”进一步转向“企业是否具备可持续维护知识和数据的机制”。如果数据基础尚未达到要求，先做数据治理和流程标准化，可能比直接扩大智能体应用范围更重要。

项目验收要从功能交付转向业务结果

智能体软件和传统软件的验收逻辑存在差异。传统项目通常围绕功能清单、页面流程、接口数量和性能指标验收；智能体项目还涉及概率性输出、复杂任务链和持续优化，因此需要建立分层指标。

可以将验收内容分为四类：

对于涉及核心业务或外部客户的项目，还应在合同和实施方案中约定测试样本、评测周期、问题整改、版本变更和持续服务责任。不能只在项目上线前进行一次性验收，而应考虑试运行、复盘和正式推广三个阶段。

供应商竞争将从模型展示转向综合实施能力

政策推动下，软件企业既可能升级现有产品，也可能向人工智能应用服务商转型。对采购方而言，供应商的竞争重点将逐步从“接入了什么模型”转向“能否解决什么业务问题”。

企业可以重点考察以下能力：

• 是否理解所在行业的业务流程和监管要求；
• 是否具备产品化能力，而非依赖一次性定制开发；
• 是否能够完成数据梳理、流程改造和系统集成；
• 是否提供可复用的评估方法、测试工具和运维机制；
• 是否有清晰的安全责任、问题响应和版本管理安排；
• 是否能支持从单一部门试点扩展到多组织、多系统应用。

这并不意味着供应商规模越大越合适。对于场景较窄、流程较明确的企业，专业化服务商可能更容易完成快速落地；对于系统复杂、组织规模较大的企业，则需要重点验证平台开放性、交付资源和长期运维能力。最终判断仍应回到企业自身场景、数据条件和治理能力。

企业现在应如何调整软件决策流程

从政策目标转向企业行动，首先要改变立项方式。企业不宜把人工智能单独作为一个与业务割裂的技术项目，而应由业务部门、信息化部门、技术团队、法务与安全人员共同参与。

一个较为清晰的推进顺序是：

1. 选择业务价值明确、风险边界可控的试点场景；
2. 梳理相关数据、系统接口、权限和人工流程；
3. 明确智能体的任务边界、人工接管条件和安全要求；
4. 通过小范围测试验证效果，而不是直接进行大规模采购；
5. 根据业务指标评估是否扩大应用范围；
6. 建立上线后的监控、审计、培训和持续优化机制。

对于软件企业，则需要同步审视自身产品规划：智能编程是否真正进入研发体系，产品是否具备智能化升级空间，智能体功能是否能形成稳定的业务闭环，服务团队是否具备数据治理、模型应用和系统集成能力。

《“人工智能+软件”专项行动实施方案》释放的并不是“所有软件都必须智能化”的简单信号，而是软件产品、研发方式和交付服务正在被放到同一套智能化升级框架中。对企业采购方而言，真正值得关注的不是概念热度，而是供应商能否把智能体能力落实到场景价值、数据基础、系统集成、项目交付和安全治理之中。只有这些条件同时具备，智能体软件才更有可能从试点应用走向可持续的规模化使用。