工信部“人工智能+软件”方案全文拆解：AI编程与Agent团队要做什么？

摘要： 工业和信息化部于 2026 年 9 月印发《“人工智能+软件”专项行动实施方案》（工信部信发〔2026〕209号）。这不是一份单纯鼓励企业购买代码助手的文件，而是围绕软件生产变革、关键软件智能化、智能体软件、智能服务、基础能力和产业环境建立的系统路线图。对 AI 编程与 Agent 团队而言，最重要的变化是：能力评价将从“能否生成代码”转向“能否完成项目级全流程开发、交付可校验的智能体软件，并满足数据、权限、安全、审计和标准要求”。本文逐项拆解政策目标，给出软件企业、开发工具厂商、Agent 创业团队及企业技术部门可立即执行的 90 天行动方案。

核心结论

《“人工智能+软件”专项行动实施方案》给 AI 编程和 Agent 团队的直接答案是：不要再把产品停留在聊天框、代码补全或单点演示层面，而应尽快建设面向真实项目的智能开发平台、可复用 Skills 与知识库、可验证的 Agent 执行链，以及覆盖权限、测试、审计和人工审批的工程体系。

• AI 编程要从“辅助写代码”升级为“项目级、全流程自主开发”：需求理解、设计、编码、测试、修复、文档和交付都要纳入统一工作流。
• Agent 要从“模型套壳”变成可交付的软件产品：具备明确身份、工具权限、状态管理、错误恢复、结果验证和审计证据。
• Skills、知识库和组件会成为新资产：方案明确提出建设智能体软件应用商店和技能包（Skills）资源库，高质量专业技能将具备复用与交易价值。
• 安全可靠、行为可校验是准入门槛：尤其是工业、政务、金融等高风险场景，不能只看任务成功率，还要证明执行过程可控、结果可追溯。
• 建议立即行动，但不建议一开始就追求全自动：先选择低风险、高频、结果可验证的流程，用“Agent执行、人类批准、系统留痕”的方式完成首个闭环。

文件背景：这项政策究竟改变了什么

结论是：政策讨论的不是某一个模型或某一种代码助手，而是软件产业从生产方式到产品形态、服务模式的整体智能化。

根据公开发布信息，《实施方案》提出两个阶段性目标：到 2028 年，软件和信息技术服务业智能化水平显著提升，智能编程工具和智能开发平台推广应用覆盖 2 万家规模以上软件企业，累计实施 100 项软件企业智能化技改项目，在重点行业打造 100 个智能体软件标杆应用，并孵化 5 个以上优质开源项目；到 2030 年，关键软件全面实现智能化升级，智能编程、智能体软件和智能服务成为产业新增长极。

政策部署可以归纳为六条主线：

1. 推进软件生产变革；
2. 加快软件产品智能化升级；
3. 培育智能体软件新业态；
4. 拓展智能软件服务；
5. 夯实软件智能化发展基础；
6. 优化软件产业发展环境。

这六条主线说明，AI 编程只是入口。真正的产业目标是让软件开发由“人工编写”转向“人机协同”，让软件产品由“被动响应”转向“主动执行”，让软件服务由一次性交付转向持续产生可衡量价值。

需要特别区分三个层次：代码补全解决一段代码怎么写；Coding Agent 解决一个 Issue 或一个项目任务怎样完成；智能体软件则作为长期运行的软件产品连接数据、知识库和业务工具，并对真实业务结果负责。政策重点明显指向后两个层次。

两阶段目标：数字背后的团队机会

结论是：2 万家企业、100 项技改、100 个标杆应用和 5 个以上开源项目不是对单个企业的硬性考核指标，但它们清楚标出了未来项目、案例、生态和标准建设的方向。

政策目标	对 AI 编程团队的含义	对 Agent 团队的含义	可准备的成果
覆盖 2 万家规模以上软件企业	工具要支持企业代码库、内网和主流研发平台	Agent 必须适配企业身份与权限体系	私有化方案、企业连接器、试点报告
实施 100 项智能化技改	不能只卖席位，要能改造研发流程	需要嵌入工单、审批、运维等流程	改造前后指标、流程图、验收材料
打造 100 个智能体软件标杆	Coding Agent 需证明项目级交付能力	行业 Agent 要可复制、可验证、可运营	场景方案、评测集、审计记录
孵化 5 个以上优质开源项目	核心工具链和标准接口可能迎来机会	Skills、协议适配器、评测工具适合开源	仓库、文档、治理规范、路线图
2030 年关键软件全面智能化升级	要适配基础软件、工业软件等复杂对象	智能体成为软件的新交互与执行层	行业解决方案与长期服务体系

编辑判断是：接下来更受重视的不是“模型排行榜第一”，而是能否进入企业开发现场、完成旧系统改造、连接国产软硬件生态、提供量化成效并通过安全验收。团队应把产品路线图从模型功能表改造成“场景—流程—权限—指标—验收”的交付矩阵。

全文主线一：软件生产方式如何变化

结论是：智能编程工具将沿着“代码补全—任务执行—项目级自主开发”演进，企业采购也会从个人效率工具转向组织级研发基础设施。

方案提出优化智能编程工具链条，发展智能体驱动的智能编程工具，面向软件开发场景深度优化，提升项目级、全流程的自主开发能力。这里有三个值得关注的关键词。

项目级

项目级意味着 Agent 不能只读取当前打开的文件。它要理解仓库结构、依赖关系、接口契约、历史 Issue、测试规则和部署环境；修改完成后还要解释影响范围，生成可审查的差异，而不是直接把大量代码推到主分支。

全流程

全流程至少包括需求澄清、任务拆分、方案设计、代码实现、自动测试、安全扫描、代码审查、部署准备和文档更新。模型可以参与每一步，但责任不能模糊。高风险操作仍应设置人类批准。

自主开发

自主不等于无限权限。可靠的自主开发应当被约束在清晰的任务、仓库、分支、工具和预算范围内。Agent 可以循环尝试，但必须受到最大步数、超时、Token 预算、网络访问范围和升级人工规则的控制。

对企业而言，可参考 AI Stack Nav 的 AI 编程教程 按任务复杂度选择工具，不要用“生成了多少行代码”衡量效果。更合理的指标包括 Issue 首次解决率、测试通过率、代码审查返工次数、缺陷逃逸率、平均交付时间和人工接管率。

全文主线二：关键软件智能化不是加一个聊天框

结论是：基础软件、工业软件和行业软件的智能化，核心是把 AI 嵌入产品的数据、控制和决策流程，同时保留确定性规则与安全边界。

传统软件升级常见误区，是在界面右下角增加一个问答助手，就宣称完成 AI 化。真正的智能化至少有四层：自然语言交互、知识理解、任务执行和持续优化。越接近任务执行，风险越高，对权限、验证和追溯的要求也越强。

以工业设备运维软件为例，第一层只解释报警代码；第二层结合设备手册和历史工单给出原因；第三层调用系统生成检修任务、查询备件并安排人员；第四层根据反馈更新诊断策略。前两层的错误主要影响效率，后两层可能影响生产，因此必须使用规则校验、权限隔离和人工审批。

软件企业在改造存量产品时，应先列出所有“可建议、可草拟、可执行、不可自动执行”的动作，并为每类动作设计不同的授权级别。不要让模型凭自然语言直接拼接 SQL、Shell 或任意 API 参数；应通过受控工具层暴露有限能力。

全文主线三：智能体软件将成为独立产品类别

结论是：Agent 产品竞争将从“能聊天”转向“能执行、能验证、能运营”，通用智能体、垂直专业智能体和工业智能体会形成不同产品路线。

方案明确提出培育通用、专用、垂直、工业等各类智能体软件，并强调工业智能体要安全可靠、行为可校验。这意味着团队不能只提供提示词和模型 API 封装，而要形成完整的软件运行时。

一个可交付的 Agent 至少应包含以下组件：

• 身份层：明确这是哪个 Agent、代表哪个用户或岗位执行；
• 规划层：把目标拆成有限步骤，并能在信息不足时停下来询问；
• 工具层：通过白名单调用 API、数据库、浏览器、代码执行或 MCP 工具；
• 状态层：保存任务状态、证据和重试信息，而不是依赖聊天上下文；
• 验证层：用规则、测试、第二模型或人工复核判断结果；
• 治理层：控制权限、预算、超时、数据边界和审批；
• 观测层：记录输入、工具调用、输出、错误、人工干预和最终结果。

团队还要建立失败语义：哪些错误可以自动重试，哪些需要回滚，哪些必须升级人工，哪些会立即终止任务。没有失败处理的 Agent，只是演示程序，不是生产软件。

全文主线四：Skills资源库会改变Agent生态

结论是：Skills 可能成为连接模型能力与专业工作的关键资产，未来不仅要“开发 Agent”，还要持续开发、测试、上架和维护技能包。

公开解读显示，方案提出建设智能体软件应用商店和技能包（Skills）资源库，规范上架审核与运营管理，并鼓励开发高质量专业技能包、知识库和面向智能体的功能组件。这与传统插件市场相似，但 Skills 的输入输出、权限和副作用更需要标准化。

一个企业级 Skill 不应只有一段提示词，而应包含：

skill:
  name: generate_release_note
  version: 1.0.0
  purpose: 根据已合并PR生成发布说明草稿
  inputs:
    repository: string
    release_tag: string
  permissions:
    repository: read
    issue_tracker: read
    publish: none
  output_schema:
    type: markdown
  validation:
    - all_pr_links_exist
    - no_unreleased_secret
  approval:
    required_before_publish: true
  audit:
    retain_tool_calls: true

这份示例配置体现了五个基本原则：用途明确、输入结构化、权限最小化、结果可验证、发布需审批。真正上架到企业技能市场时，还要增加维护者身份、依赖版本、数据去向、风险等级、评测结果、适用模型和下架机制。

对于 AI Stack Nav 的读者，这也意味着可以从“出售提示词”升级为交付 Agent Skills 与 MCP 实战资料：提供 Skill 定义、连接器、评测集、权限清单、部署文件和验收文档，形成更难被复制的工程化产品。

全文主线五：软件服务从卖产品转向交付结果

结论是：“模型即服务”和“智能体即服务”会扩大软件服务边界，但服务商必须能为结果、成本和持续运营负责。

传统软件项目常以许可证、席位或功能上线作为交付节点。Agent 服务则需要持续处理变化的业务数据、模型版本、工具接口和异常情况。客户真正关心的是工单是否减少、故障是否更快恢复、报告是否准确、销售线索是否及时跟进，而不是调用了哪个模型。

因此，报价和合同需要新增四类内容：任务口径、质量指标、资源预算和责任边界。例如，自动生成代码可以按已验收 Issue 计量，知识库客服可以按有效解决会话计量，文档 Agent 可以按通过抽检的文档计量。涉及第三方模型费用时，要说明输入、输出、工具调用和重试成本由谁承担。

“Agent 即服务”也不等于服务商可以无限读取客户数据。应在合同和技术系统中明确数据分类、使用目的、保存期限、跨境限制、模型训练选择、子处理方和删除流程。

全文主线六：基础能力与产业环境决定能否规模化

结论是：开源、算力、数据集、标准、人才、就业和安全不是配套附录，而是 Agent 能否进入企业生产环境的底座。

政策提出促进开源协同创新、强化算力服务支撑、建设高质量数据集，同时推进智能编程、智能体接口、智能服务等关键标准研制，并强化复合型人才培养、安全保障和就业友好发展。

这给团队提出了几项现实要求：

• 不要把所有业务都绑定到单一闭源模型，应保留模型路由和替换能力；
• 建立企业数据集版本、授权来源、质量抽检和删除记录；
• 接口尽量结构化，避免依赖不可控的自然语言约定；
• 评测不仅测回答质量，还应测工具成功率、越权率、回滚能力和成本；
• 培训开发者从单纯编码转向需求、架构、验证、安全和 Agent 运营；
• 明确 AI 生成代码和决策的责任人，不用“模型自动完成”掩盖责任空白。

关于就业，政策公开解读强调就业友好、人机协同、岗位改造和技能培训。它并未承诺 AI 不会影响基础编码岗位，也没有给出具体岗位增减数字。因此，更稳妥的判断是：重复性编码工作会承压，而需求理解、系统架构、集成交付、安全治理、评测和现场工程能力的重要性会上升。

AI编程团队要做什么：从个人助手到研发平台

结论是：AI 编程团队应优先补齐代码库上下文、任务编排、验证门禁、企业集成和组织治理，而不是继续堆叠聊天功能。

建立仓库级上下文工程

为每个代码库准备项目说明、架构约束、编码规范、测试命令、禁止修改区域、依赖策略和验收标准。Agent 每次任务只加载必要上下文，并记录引用了哪些文件，减少错误信息和敏感代码暴露。

把任务拆成可验证单元

不要给 Agent “重构整个系统”这类模糊目标。任务应包含输入、允许修改范围、必须通过的测试、不可改变的行为和完成定义。复杂任务先由规划 Agent 生成方案，经人类确认后再进入实现。

建立独立验收层

编写代码的 Agent 不应是唯一验收者。至少用确定性测试、静态分析、安全扫描和独立代码审查共同判断。生产部署、合并受保护分支、修改权限等动作必须由人类或独立控制面批准。

支持企业环境

产品需要考虑私有仓库、内网运行、代理服务器、单点登录、国产代码托管平台、审计日志以及模型可替换。若源代码不能发送到外部模型，应提供本地模型或受控网关方案，而不是让员工自行复制代码到公共聊天工具。

Agent团队要做什么：从Demo到可验收产品

结论是：Agent 团队应该为每一个自动动作准备权限、证据、验证、回滚和责任人，让客户能够验收，而不是只展示一次成功演示。

建议建立一张“Agent 准入卡”：

准入项	最低要求	验收证据
身份	Agent、用户、服务账号可区分	身份映射和登录日志
权限	默认拒绝、按任务临时授权	工具白名单和授权记录
数据	明确来源、用途和保存期限	数据清单与删除测试
执行	有超时、重试、幂等和回滚	故障注入测试报告
输出	使用结构化格式并校验	Schema 和失败样本
审批	高风险动作必须人工确认	审批记录与拒绝测试
审计	可还原关键输入与工具调用	任务追踪 ID 和日志
评测	覆盖正常、异常、攻击场景	评测集、通过率与版本

在技术实现上，可给所有工具调用加统一策略门：

HIGH_RISK_ACTIONS = {
    "deploy_production",
    "merge_protected_branch",
    "delete_data",
    "change_permission",
    "send_external_message",
}

def authorize(action: str, context: dict) -> dict:
    if action not in context["allowed_actions"]:
        return {"allowed": False, "reason": "not_in_task_scope"}

    if action in HIGH_RISK_ACTIONS and not context.get("human_approval_id"):
        return {"allowed": False, "reason": "human_approval_required"}

    if context.get("estimated_cost", 0) > context["remaining_budget"]:
        return {"allowed": False, "reason": "budget_exceeded"}

    return {"allowed": True, "audit_id": context["task_id"]}

示例只表达治理逻辑，实际系统还需要验证审批签名、处理并发、避免重放、保护日志中的敏感信息，并把策略执行放在模型无法绕过的独立服务中。

可立即执行的90天落地路线

结论是：用三个月做出一个低风险但完整的生产闭环，比同时启动十个 Agent 演示更符合政策所强调的技改、标杆与可复制方向。

1. 第 1—10 天：选择场景。 从高频、规则清晰、数据可得、结果可验证且可人工回退的任务中选一个，例如测试生成、发布说明草拟、内部知识检索或工单分类。
2. 第 11—20 天：完成基线测量。 记录当前处理时间、错误率、返工率、人工成本和风险事件，没有基线就无法证明技改成效。
3. 第 21—35 天：设计受控架构。 明确 Agent 身份、可用工具、数据范围、预算、超时、重试、审批点、日志字段和回滚方式。
4. 第 36—50 天：建设 Skills 与评测集。 把业务能力拆成版本化 Skill，同时准备正常、边界、异常和 Prompt Injection 测试样本。
5. 第 51—65 天：影子运行。 Agent 生成建议但不执行真实动作，与人工结果对比，统计准确率、漏报、误报和成本。
6. 第 66—75 天：有限执行。 只开放低风险工具，高风险动作保持人工批准；进行超时、接口失败和权限越界演练。
7. 第 76—85 天：独立验收。 由未参与开发的人员完成安全、业务、性能和可恢复性验收，避免开发 Agent 自证成功。
8. 第 86—90 天：形成可复制材料。 输出架构图、操作手册、权限矩阵、评测报告、成本报告、故障清单和下一阶段计划。

90 天后，如果质量和风险指标达标，再扩大任务范围或并发量；如果 Agent 频繁需要人工救场，应先重构工具接口和验证流程，而不是简单更换更大的模型。

如何申报或争取标杆机会

结论是：方案本身没有在公开正文中给出统一申报入口、补贴金额或具体评分表，团队不应把政策目标误读为已经开放资金申请；但可以提前准备可被地方主管部门、产业园区或客户验收的材料。

建议准备五类证据：第一，真实企业应用证明，而非内部 Demo；第二，改造前后可核验指标；第三，智能体的安全、权限和审计设计；第四，适配国产软硬件或行业系统的能力；第五，可复制的部署与服务手册。

同时关注所在地工业和信息化主管部门后续通知、案例征集、揭榜挂帅、智能化技改和开源项目申报。任何补贴比例、截止日期、申报条件都应以具体通知为准，不能从国家层面目标自行推断。

风险、限制与注意事项

结论是：政策鼓励不等于技术免责，Agent 一旦接入生产工具，风险来自错误输出、越权执行、数据泄露、供应链依赖和责任失焦。

不把政策目标当成强制采购指标

“覆盖 2 万家”“100 项技改”“100 个标杆”和“5 个以上开源项目”是行动目标，不能据此宣称某款产品得到官方推荐，也不能承诺客户一定能获得项目或补贴。

防止Prompt Injection进入工具链

代码、网页、邮件、工单和知识库都可能包含诱导 Agent 泄露数据或调用危险工具的指令。系统必须把外部内容视为不可信数据，工具参数应经过 Schema 与策略校验，敏感动作设置二次确认。

控制数据和代码外发

源代码、合同、客户信息、生产日志和凭据应分级分类。团队要核对模型提供商的数据保留、训练使用、地域和子处理方政策，并用内容排除、脱敏、私有网络和最小权限减少暴露。

设置成本和循环上限

Agent 可能因错误重试、搜索扩散或多 Agent 对话产生不可控成本。每个任务应设置最大步骤、Token、工具调用次数、运行时间和金额预算，并在到达阈值时停止或升级人工。

保留确定性控制面

支付、删除数据、生产部署、外发邮件、修改账户和权限等动作，不应由模型自行决定。模型可以生成计划和参数，但最终授权、约束和审计必须由独立系统完成。

对不同团队的选型建议

结论是：软件企业、工具厂商、Agent 创业团队和企业 IT 部门面临的任务不同，不能复制同一份产品路线图。

团队类型	近期优先项	暂缓事项	关键指标
软件企业	改造一个研发流程和一个存量产品功能	全公司无差别开放自动执行	交付周期、缺陷率、接管率
AI 编程工具厂商	项目级上下文、验证门禁、私有部署	单纯增加模型数量	Issue 完成率、回滚率、安全事件
Agent 创业团队	垂直场景、Skills、审计和验收材料	追求万能 Agent	业务完成率、单位任务成本、续费率
企业 IT 部门	统一入口、模型网关、权限与日志	员工自行采购和上传数据	活跃场景、风险事件、投资回报
开源团队	标准接口、可复现评测、社区治理	只发代码不维护文档	贡献者、版本稳定性、生态适配

对于资源有限的小团队，最稳妥的切入点不是自研基础模型，而是行业知识、Skills、受控工具、评测和交付。它们更接近客户愿意付费的结果，也更符合智能体软件与智能服务的发展方向。

事实依据与来源

本文的政策名称、文号、两阶段目标、六方面部署，以及智能编程、智能体软件、Skills 资源库、开源、数据集、标准、人才、就业与安全等信息，依据工信部公开发布内容及中央媒体报道核验。

• 官方已确认事实： 文件文号为工信部信发〔2026〕209号；到 2028 年覆盖 2 万家规模以上软件企业、实施 100 项智能化技改、打造 100 个智能体软件标杆应用、孵化 5 个以上优质开源项目；到 2030 年关键软件全面智能化升级。
• 官方口径： 推动软件开发由人工编写向人机协同、软件产品由被动响应向主动执行、软件服务由产品交付向价值交付转变；建设智能体软件应用商店与 Skills 资源库。
• 第三方测试： 本文没有引用任何厂商或第三方的模型性能测试，也没有编造生产率提升百分比。
• 编辑判断： “竞争从模型能力转向工程交付”“Skills 将成为可交易工程资产”等判断，是基于政策方向作出的产业分析，不代表官方结论。
• 实施建议： 90 天路线、Agent 准入卡、独立验收层和示例代码属于可操作的工程建议，并非政策强制模板。
• 待后续核实： 具体地方申报入口、资金支持、评审标准、标准编号和案例征集时间，应以主管部门后续通知为准。

FAQ

这份方案什么时候发布，文件号是什么？

工业和信息化部于 2026 年 9 月对外发布《“人工智能+软件”专项行动实施方案》，文件号为工信部信发〔2026〕209号。公开报道显示文件成文日期为 2026 年 9 月 2 日，并在 9 月 11 日集中发布和解读。

方案是不是要求企业必须购买AI编程工具？

不是。方案提出产业发展目标和重点任务，并不等于每一家企业都被要求购买某个具体产品。企业应根据数据安全、研发流程、投入产出和人员能力选择试点，任何厂商都不应借政策名义宣称获得指定采购资格。

到2028年的核心量化目标有哪些？

公开信息明确列出：智能编程工具和智能开发平台推广应用覆盖 2 万家规模以上软件企业，累计组织实施 100 项软件企业智能化技改项目，在重点行业打造 100 个智能体软件标杆应用，并孵化 5 个以上优质开源项目。

“项目级、全流程自主开发”是不是意味着Agent可以直接上线代码？

不是。项目级自主开发描述的是能力范围，不等于取消工程控制。生产环境仍应通过测试、静态分析、安全扫描、独立审查、分支保护和部署审批。模型可以自动执行低风险步骤，但合并受保护分支和生产部署应保留明确授权。

普通程序员会不会被完全替代？

政策没有给出“程序员将被完全替代”的结论或岗位减少数据。公开解读强调就业友好、人机协同、岗位改造和技能培训。更现实的变化是基础重复编码承压，而需求理解、架构、验证、集成、安全和 Agent 运营能力更重要。

Skills资源库与传统插件市场有什么不同？

传统插件通常面向人类点击调用，Agent Skill 还要被模型自动选择和组合，因此必须更清晰地声明用途、输入输出、权限、副作用、依赖和验证方式。企业级 Skills 资源库还需要上架审核、版本管理、风险分级、评测和下架机制。

小团队最适合从哪里切入？

优先选择一个垂直、高频、可验证的业务任务，开发完整的 Skill、受控连接器、评测集和验收文档。小团队不必自研基础模型，行业知识、系统集成、安全治理和现场交付更容易形成差异化。

如何判断一个Agent已经具备生产准入条件？

至少检查身份、权限、数据、执行、输出、审批、审计和评测八类能力。它不仅要在正常样本上完成任务，还要通过越权、接口失败、超时、重复执行、恶意输入和人工拒绝等测试。

现在是否已有统一的标杆项目申报入口？

本文核验到的国家层面公开信息没有给出统一申报入口和补贴标准。团队应持续关注工信部、所在地工业和信息化主管部门及相关产业平台的后续通知，不能根据目标数字自行推断申报资格。

企业现在最应该先买工具还是先做治理？

两者应同步，但先明确场景和治理底线。没有任务边界、数据清单、权限策略和验收指标时，直接大规模购买席位往往难以证明价值。建议先用小范围工具完成一个可测量闭环，再决定扩容。

参考来源

• 数字中国建设峰会：推动智能化升级，工信部印发《“人工智能+软件”专项行动实施方案》
• 中国青年网：人工智能如何“+”软件，工信部印发方案
• 证券时报转引报道：专项行动实施方案目标与政策解读
• 新京报：关于印发《“人工智能+软件”专项行动实施方案》的通知

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包