工信部“AI+软件”行动计划划定2028目标：2万家企业、100个智能体应用如何转化为商业机会？

工信部于2026年9月发布的人工智能赋能软件和信息技术服务业行动计划，释放出的关键信号不是“所有软件都要加一个AI入口”，而是推动人工智能进入软件开发、行业应用、开源协作和关键软件系统升级等更具体的业务环节。按照计划提出的安排，到2028年将覆盖2万家重点软件企业，建设100个重点行业智能体应用，并培育至少5个高质量开源项目。对企业而言，真正需要回答的问题是：哪些能力应当优先改造，哪些项目具备交付条件，以及如何把政策目标转化为可验证的产品和经营动作。

先区分政策事实与企业判断

目前能够明确提取的政策目标包括三项：覆盖2万家重点软件企业、建设100个重点行业智能体应用、培育至少5个高质量开源项目。这些是行动计划提出的方向和数量安排，不等同于每家企业都会获得项目、订单或资金支持，也不能直接推导出具体企业名单、市场规模和采购结果。

企业据此形成的产品路线、客户机会和商业模式，则属于经营判断。政策目标可以帮助企业识别优先方向，但不能替代客户需求验证、技术评估和交付验收。尤其是在智能体应用领域，“进入重点行业”不意味着完成一个演示原型就具备行业应用资格；在开源领域，“参与项目”也不等同于形成可持续的商业收入。

因此，企业落地时应将信息拆成三层：

1. 政策事实：行动计划提出了哪些目标、面向哪些方向。
2. 业务假设：企业认为哪些产品、流程或客户场景存在升级机会。
3. 交付证据：是否有可复现的效果、稳定的系统能力和明确的责任边界。

只有第三层得到验证，政策方向才可能转化为商业机会。

第一类机会：把AI编程工具嵌入开发流程

软件企业最容易启动的方向，通常不是立即开发一个面向外部客户的通用智能体，而是先改造自身的研发流程。AI编程工具可以进入代码生成、代码补全、测试用例编写、缺陷定位、文档维护和知识检索等环节。

但“使用AI编程工具”不应只看开发人员是否安装了工具，更应关注它是否嵌入现有工程流程。企业可以优先检查以下环节：

• 重复性较高、规则相对清晰的代码开发；
• 单元测试、接口测试和测试数据生成；
• 历史缺陷检索与相似问题定位；
• 技术文档、接口说明和变更记录维护；
• 企业内部代码、组件和规范的知识检索。

这类改造的重点不是追求代码生成量，而是建立审核、测试和追责机制。由模型生成的代码仍需经过代码审查、自动化测试和安全检查；涉及核心算法、敏感数据和关键业务逻辑时，还要明确哪些内容不得直接交给外部模型处理。

对软件企业管理者而言，较可执行的评估方式是选择一个边界清晰的研发团队或产品模块，比较引入工具前后的需求交付周期、缺陷率、测试覆盖情况和返工情况。若只能展示“模型写出了多少代码”，却无法说明软件质量和交付效率是否改善，这类项目仍停留在概念验证阶段。

第二类机会：围绕行业流程建设智能体应用

100个重点行业智能体应用的目标，意味着智能体机会更可能集中在具体行业流程，而不是无边界的聊天机器人。企业需要从“模型能做什么”转向“一个业务角色在什么授权范围内完成什么任务”。

一个可交付的智能体应用，至少应当明确五个要素：

1. 服务对象：面向采购人员、客服、运维人员、财务人员，还是管理者。
2. 任务边界：负责查询、分析、生成建议，还是可以调用系统执行操作。
3. 数据来源：使用哪些业务系统、知识库和实时数据，数据是否经过授权。
4. 操作权限：哪些动作可以自动完成，哪些动作必须由人工确认。
5. 验收标准：准确率、响应时间、任务完成率、人工复核率和异常处理如何衡量。

例如，企业可以从售后工单分派、内部制度问答、设备运维辅助、合同条款初筛或供应链异常提醒等流程切入。这些场景通常具有相对清晰的输入、输出和责任人，比“做一个全能企业助手”更容易验证。

智能体项目的商业价值，不在于对话界面是否流畅，而在于能否稳定连接企业已有系统，并在异常情况下停止、转人工或留下完整记录。对于采购者来说，演示时能够完成一次任务并不充分，还应要求供应商说明数据权限、工具调用日志、失败处理、版本变更和人工接管机制。

第三类机会：把开源项目作为能力和生态入口

行动计划提出培育至少5个高质量开源项目。对企业而言，开源不只是发布代码，也不是把现有产品简单删减后放到公共仓库。真正有价值的开源项目，需要具备清晰的使用边界、持续维护能力和可验证的技术贡献。

软件企业可以考虑从三种方式参与：

• 将通用组件、开发工具或评测工具开源，吸引开发者使用；
• 围绕智能体编排、模型调用、数据连接或安全治理贡献项目；
• 参与已有社区，通过代码、文档、测试和问题修复形成长期影响。

选择开源方向时，企业需要先判断项目是否与自身产品和客户需求相连。如果开源内容无法形成开发者使用、客户集成或商业服务的延伸，项目可能只能带来短期曝光，难以沉淀为业务能力。

开源项目还涉及许可证、代码来源、依赖组件和安全漏洞管理。企业不能将“发布仓库”视为项目完成，而应提前安排维护者、版本节奏、问题响应和贡献者管理。对创业公司来说，开源可以降低生态进入门槛，但也会增加长期维护成本，必须明确哪些能力免费开放，哪些能力通过托管服务、技术支持或行业解决方案实现商业化。

第四类机会：升级关键软件系统，而不是只增加AI功能

“AI融入软件业”的另一条主线，是对关键软件系统进行智能化升级。这里的重点不是增加一个单独的AI模块，而是重构系统中的数据、规则、权限和操作流程，使人工智能能够在可靠边界内发挥作用。

企业可以优先检查四类基础能力：

数据是否能够被理解和调用

如果业务数据分散在不同系统，字段定义不一致、权限关系不清晰，智能体就很难稳定工作。系统升级应先解决数据目录、接口标准、知识库更新和访问权限等基础问题。

业务流程是否允许机器参与

有些系统虽然数据完整，但关键流程高度依赖线下审批或个人经验。企业需要明确哪些步骤可以自动执行，哪些步骤只能提供辅助建议，哪些步骤必须由特定岗位确认。

系统是否能够记录和追溯

在财务、生产、运维、客户服务等场景中，AI输出需要能够追溯到数据来源、调用工具和操作结果。没有日志、版本和审计能力的智能功能，难以满足复杂业务的长期使用要求。

失败时是否能够安全退出

模型可能出现误判、信息过时或无法处理异常。系统必须具备权限限制、人工接管、错误回滚和风险提示机制。对关键业务来说，允许智能体“什么都能做”并不是优势，能够在不确定时停止，反而更接近可交付能力。

企业应如何判断一项机会是否值得投入

面对政策目标，企业不宜先问“我们能不能做一个智能体”，而应先问“客户愿意为哪个可验证结果付费”。可以采用四步筛选法。

第一步，确认场景是否具有明确责任人。没有具体使用者和业务负责人，项目往往会停留在展示层。

第二步，确认场景是否有可获得的数据和系统接口。只有模型能力、没有数据和工具连接，通常无法完成真实任务。

第三步，确认收益是否能够测量。效率提升、人工复核减少、错误率下降或响应时间缩短，都应在项目启动前定义口径。

第四步，确认风险是否可控。涉及隐私、知识产权、生产安全、财务决策和客户权益的场景，需要提前设计权限、审计与人工复核机制。

满足这四项条件后，再决定采用自研、采购、联合开发还是基于开源项目二次集成。不同企业不必追求同一种技术路线，关键是让技术选择服从业务责任和交付目标。

采购者应警惕“演示成功”替代“项目可交付”

企业采购AI软件或智能体应用时，最容易被一次顺畅演示影响判断。演示通常选择了准备充分的数据和理想流程，无法代表长期运行效果。

采购评估至少应加入以下测试：

• 使用未提前提供给供应商的样例数据；
• 测试数据缺失、冲突和格式变化时的表现；
• 检查模型是否能引用来源并区分事实与推测；
• 验证权限、日志、人工接管和异常回滚；
• 评估系统在高并发、接口故障和模型版本变化下的稳定性；
• 明确交付范围、验收指标和后续维护责任。

供应商如果只强调模型参数、对话效果或概念展示，却无法说明系统接口、数据治理和故障处理，采购者应谨慎推进。对于软件企业自身，也同样不能把客户现场的“看起来有效”当作产品完成，必须把可重复部署、可观测运行和可持续维护纳入产品定义。

编辑观察：政策目标提供方向，商业机会仍取决于交付能力

覆盖2万家重点软件企业、建设100个重点行业智能体应用、培育至少5个高质量开源项目，分别对应企业广泛参与、行业场景落地和生态能力建设三个层面。它们为软件企业提供了方向，但没有替企业完成客户选择、产品定义和风险控制。

更现实的行动顺序是：先用AI编程工具和内部知识能力改造研发流程，再选择一个数据、权限和验收标准较清晰的行业任务建设智能体，同时评估是否有适合长期维护的开源项目，最后将成熟能力嵌入关键软件系统。

对管理者来说，政策窗口期最值得投入的不是概念包装，而是把人工智能能力变成可测试、可审计、可复制的产品能力。对技术负责人来说，模型只是系统的一部分，数据连接、权限管理、工程质量和异常处理同样决定项目能否上线。对采购者来说，判断AI项目的核心标准也应从“演示是否惊艳”转向“真实流程是否稳定完成”。