《智能体规范应用与创新发展实施意见》明确技术底座方向：企业部署要补齐规划、工具与长期记忆能力

5月8日，中央网信办、国家发展改革委、工业和信息化部联合发布《智能体规范应用与创新发展实施意见》，将智能体的发展重点从单一模型能力，进一步延伸到任务理解、任务规划、工具使用、长期记忆、互认互通和群体协同等系统能力。对准备部署智能体的企业而言，评估重点不应再只是“模型能不能回答”，而应转向“系统能不能理解目标、制定步骤、调用工具并在约束下持续执行”。（中国政府网）

文件释放的核心信号：智能体是系统，不只是模型

《实施意见》提出，智能体应具备自主感知、记忆、决策、交互与执行能力，并从夯实发展基础、推动规范应用、强化技术创新和促进场景落地等方面作出部署。文件重点涉及基础模型、数据集、任务理解、任务规划、工具使用、长期记忆、互认互通和群体协同等技术底座能力。

这意味着，企业部署智能体时，基础模型只是能力链条中的一环。模型负责理解和生成，真正决定系统能否进入业务流程的，还包括数据是否可用、任务是否可拆解、工具是否可控、记忆是否可管理，以及多个智能体和外部系统能否安全协作。

从政策导向看，企业的技术评估可以先回答三个问题：

1. 模型是否能理解业务任务，而非只处理自然语言问题？
2. 系统是否能把目标拆解为可执行步骤，并根据执行结果调整计划？
3. 每一次工具调用、数据访问和持续记忆，是否都有明确权限、记录和边界？

从“模型能回答”转向“系统能持续执行”

基础模型与数据集：先确认能力来源

基础模型决定智能体的通用理解、推理和生成能力，但企业不能把模型参数规模直接等同于业务可用性。部署前需要区分模型能力与企业工程能力：

其中，数据集不是简单的资料仓库。企业需要明确哪些数据可以被检索，哪些数据只能由特定角色访问，哪些信息需要脱敏，以及数据发生变化后如何同步到智能体。对于财务、人力、客户服务和生产管理等场景，数据权限应与原有业务系统保持一致，不能因为接入智能体就形成新的越权入口。

任务理解与任务规划：从问答进入业务流程

任务理解解决的是“用户真正要完成什么”，任务规划解决的是“系统准备如何完成”。两者不能用一次问答的准确率替代。

例如，企业让智能体“整理一份客户续约风险报告”，系统至少需要识别客户范围、时间区间、风险指标、数据来源和输出格式，并进一步安排数据查询、信息比对、风险分类和结果审核。如果智能体只能生成一段分析文字，却不能说明使用了哪些数据、哪些步骤由工具完成，就还没有形成完整的任务执行能力。

企业在评估任务规划时，可重点检查：

• 能否把复杂目标拆成有先后关系的子任务；
• 能否识别任务中的权限、时间和业务规则；
• 某个工具调用失败时，能否重试、改用替代路径或请求人工介入；
• 执行结果与原定目标不一致时，能否暂停并重新规划；
• 能否保留任务状态，使中断后的流程可以恢复，而不是从头开始。

这里需要注意，规划能力不等于完全放权。对于涉及付款、合同变更、客户权益、生产控制等高影响操作，企业应当把“生成建议”和“执行动作”分开设计，并设置人工确认或分级授权。

工具调用和长期记忆是落地难点

工具调用：关键不在“会调用”，而在“可控调用”

文件将工具使用列为智能体技术底座的重要能力。企业部署时，工具不应被理解为简单的API集合，而应当是带有身份、权限、参数校验和执行结果反馈的业务接口。

一个可供核查的工具调用链条应至少包括：

1. 工具登记：说明工具用途、输入参数、输出结果和适用范围；
2. 权限校验：确认智能体、用户和具体任务是否具备调用权限；
3. 参数检查：防止错误对象、超范围金额或不完整指令进入业务系统；
4. 执行留痕：记录调用时间、调用主体、参数摘要和执行结果；
5. 异常处置：对超时、失败、重复执行和结果冲突设置处理规则；
6. 人工介入：对高风险操作保留审批、确认或回滚机制。

这也是区分演示型智能体和生产型智能体的重要标准。演示场景可以展示模型如何调用工具；生产系统则必须回答调用是否被授权、结果是否可验证、出错后谁来负责以及能否追溯。

长期记忆：不是无限保存用户信息

长期记忆能力能够帮助智能体保留稳定偏好、任务状态和业务上下文，但企业不能将其设计为无边界的个人信息存储空间。

部署前应明确三类边界：

• 记忆什么：哪些信息对后续任务确有必要，哪些只属于一次性上下文；
• 保存多久：不同类型信息的保留期限、更新规则和删除机制；
• 谁能使用：用户本人、团队、部门或企业级智能体分别具有什么访问范围。

此外，长期记忆还需要支持纠错和追溯。用户应能够知道智能体依据了哪些历史信息，企业也应能发现错误记忆、过期记忆或不应继续使用的内容。否则，记忆越丰富，错误被持续放大的风险也越高。

互认互通与群体协同：提前考虑系统边界

文件同时提到智能体互认互通和群体协同。对企业来说，这一要求并不意味着立即搭建多个智能体，而是提示技术架构不能只围绕单个智能体封闭建设。

企业可以从三个层面做准备：

• 身份互认：明确智能体的身份、所属组织、责任主体和授权范围；
• 能力互通：用清晰的描述方式说明智能体能够完成什么任务、调用什么工具、接受什么输入；
• 协同规则：定义任务如何分派、结果如何交接、冲突如何处理以及最终由谁负责。

在多个智能体协同的场景中，最容易被忽略的是责任链。一个智能体负责检索，另一个负责分析，第三个负责执行时，企业需要保留完整的任务上下文和交接记录，不能因为流程由多个系统共同完成，就无法定位错误来源。

企业部署可采用“四层核查框架”

围绕文件提出的技术底座要求，企业可以在立项、选型和试运行阶段使用以下核查框架：

第一层：能力核查

确认模型、数据集、任务理解、任务规划、工具使用和长期记忆是否覆盖目标场景。不要只测试标准问答，还应测试复杂任务、异常输入、数据缺失和流程中断。

第二层：工程核查

确认系统是否具备工作流编排、状态管理、接口管理、评测体系和运行监控。模型供应商提供的能力，不等于企业已经拥有可持续运行的系统。

第三层：安全核查

确认数据权限、身份认证、敏感信息处理、工具调用授权、日志审计、人工介入和应急停用机制是否前置建设。安全可控不是上线后的补充模块，而应成为技术选型和流程设计的一部分。

第四层：应用核查

确认智能体是否服务于真实业务目标，是否能够量化任务完成质量、执行效率和风险变化。企业应优先选择边界清晰、数据基础较好、结果可验证的场景，避免为了展示“自主性”而让智能体直接进入高风险流程。

编辑观察：选型重点将从模型参数转向系统责任

《实施意见》对基础模型、数据集和智能体关键能力的并列部署，传递出一个清晰方向：智能体竞争不只是模型回答质量的竞争，也包括规划、调用、记忆、互联和治理能力的系统竞争。

对企业管理者而言，最实际的做法不是先问“哪一个模型最强”，而是先画出目标任务的完整链路：智能体要理解什么、读取什么、规划什么、调用什么、记住什么，哪些步骤必须由人确认，最终结果如何审计。只有把这些问题落实到架构、接口和责任制度中，智能体才可能从试验性问答工具进入可控的业务执行系统。