网信办实施意见提出完善智能体工具链：企业采购如何从模型评测转向任务闭环

中央网信办、国家发展改革委、工业和信息化部联合印发《智能体规范应用与创新发展实施意见》，将智能体定义为具备自主感知、记忆、决策、交互和执行能力的智能系统，并提出夯实技术基础、完善智能体工具链、强化安全治理和推动场景应用。对企业而言，这一政策信号意味着，智能体采购不能再只比较模型参数、通用问答效果或单轮评测分数，而应转向验证一个系统能否围绕真实业务完成“理解任务—制定计划—调用工具—执行反馈—长期记忆—风险控制”的完整闭环。

政策信号：智能体采购对象正在从模型变成系统

根据中国政府网英文版对相关文件的报道，相关实施意见由中央网信办、国家发展改革委和工业和信息化部联合发布，目标是推动人工智能智能体规范应用与创新发展。文件提出，智能体正加快与网络空间和物理世界融合，并将其作为人工智能产品和服务的重要形态。

这一定义本身就改变了企业的采购视角。传统模型评测通常关注准确率、延迟、上下文长度、推理能力和调用成本；智能体采购则必须继续追问：它能否正确理解业务目标？能否把复杂目标拆成可执行步骤？能否选择合适的工具并处理异常？能否在权限范围内完成操作？能否记住经授权的业务上下文，同时避免错误保留或越权调用？

因此，企业采购的最小评测单元不应再是一道题，而应是一项任务。模型仍然是底座，但决定项目是否产生业务价值的，往往是模型、任务规划器、工具连接层、记忆模块、权限系统、审计系统和业务应用之间能否协同工作。

一、技术选型：从模型排行榜转向智能体工具链

文件提出完善智能体工具链，并强调安全可控、规范有序、创新驱动和应用牵引。落到企业选型层面，所谓工具链，至少应覆盖以下几类能力：

其中，任务理解和任务规划是最容易被单轮问答评测掩盖的部分。一个模型可能能够生成逻辑通顺的方案，却无法识别业务流程中的前置条件；也可能能够列出多个步骤，却不知道哪些步骤需要审批、哪些操作不得自动执行。企业应把真实流程中的规则、例外和责任边界纳入测试，而不是只提供理想化的标准问题。

工具使用也不能只看“能不能调用”。采购方需要验证智能体是否会在调用前确认工具适用范围，是否能使用结构化参数，是否能识别工具返回的错误信息，以及在外部系统超时、数据缺失或权限不足时是否会停止并请求人工处理。

二、场景试点：先验证任务闭环，再扩大覆盖范围

企业不宜一开始就建设覆盖全公司的通用智能体。更稳妥的路径，是选择一个流程边界清晰、数据可控、结果可衡量的场景进行试点，例如内部知识检索、售后工单分派、采购信息整理或研发资料归档。

试点任务应当具备四个条件：

1. 目标可以量化。 例如处理时长、一次完成率、人工转交率、错误率和重复操作次数。
2. 工具调用范围明确。 先接入少量、低风险、可回滚的系统，避免一开始就开放核心生产权限。
3. 异常样本足够真实。 测试数据不能只有标准输入，还应包括缺字段、冲突信息、过期资料和恶意指令。
4. 人工接管路径清楚。 智能体无法判断或不具备权限时，应能及时转交人员，而不是继续尝试。

任务闭环的验收，不应只看最终答案是否正确，还要检查过程是否合规。例如，智能体最终生成了一份正确的采购建议，但如果它在没有授权的情况下读取了敏感供应商数据，或者绕过审批直接修改订单，这个任务仍然不能算作成功。

企业可以将验收结果拆成三层：第一层是结果质量，判断任务是否完成；第二层是过程质量，判断规划、工具调用和信息引用是否正确；第三层是治理质量，判断权限、日志、人工接管和数据处理是否符合要求。只有三层同时达标，才适合进入扩大部署阶段。

三、权限控制：把“能执行”与“可执行”分开

智能体的执行能力越强，权限设计越不能依赖模型自身判断。企业需要在系统层面建立工具白名单、数据分级、操作分级和审批机制，把“模型认为应该做什么”与“系统允许做什么”严格区分开。

对于查询、摘要、分类等只读任务，可以在限定数据范围内提高自动化程度；对于发起付款、修改合同、删除数据、对外发送信息等操作，则应设置二次确认、人工审批或双人复核。权限还应与用户身份、业务角色、任务上下文和操作时间关联，不能因为智能体拥有某个接口，就默认获得该接口背后的全部数据。

长期记忆尤其需要单独验收。企业应明确哪些内容可以保存、保存多久、由谁访问、如何纠正和删除。客户偏好、员工信息、项目资料和内部规则的敏感程度不同，不能用一个统一的“记住一切”策略处理。记忆模块还应区分事实、推断和临时上下文，避免智能体把一次错误判断长期固化为业务事实。

四、责任划分：模型供应商不应承担全部落地责任

智能体系统通常由多个主体共同构成，采购合同和项目治理应避免责任模糊。

模型供应商主要负责基础模型的服务稳定性、版本变更说明、基础安全能力、接口规范和已知限制披露。模型供应商可以提供通用推理和生成能力，但通常无法替企业保证具体业务流程的正确性。

智能体平台或工具链供应商主要负责任务编排、工具接入、记忆管理、日志记录、运行监控和多模型适配。其责任重点是保证组件之间能够协同工作，并让企业能够查看和控制关键过程。

应用集成商需要对业务流程映射、数据接入、权限配置、系统适配和场景验收负责。一个智能体在通用测试中表现良好，并不意味着接入企业的财务、供应链或客户系统后仍然可靠。

企业自身则不能把数据治理、权限审批和最终业务责任外包出去。企业应指定业务负责人、技术负责人和安全负责人，明确哪些任务可自动执行、哪些必须人工确认，以及出现错误后的追责、回滚和补救机制。

采购文件中应将这些责任写成可验收条款，而不是只写“支持智能体”“支持多工具调用”或“具备长期记忆”等功能描述。

五、风险验收：从“模型安全”扩展到“系统性风险”

实施意见强调安全、可靠、可信和分类分级治理。对企业而言，风险验收至少包括四个方面。

一是数据风险。需要确认输入数据是否被用于训练，跨租户隔离是否有效，敏感信息是否脱敏，日志是否包含不应留存的内容。

二是执行风险。需要测试越权调用、重复执行、错误参数、工具返回异常和外部系统中断等情况，并验证系统能否暂停、回滚或转人工。

三是内容与决策风险。智能体输出的事实、建议和自动决策应区分处理。涉及法律、财务、人力、医疗、安全生产等高影响领域时，不能仅凭生成结果直接完成最终决策。

四是供应链风险。模型版本、插件、外部知识库和第三方接口发生变化，都可能改变智能体行为。企业应要求供应商提供版本记录、变更通知、回归测试和应急降级机制。

互认互通也属于风险治理的一部分。接口兼容并不等于业务互信。企业需要关注身份认证、权限语义、任务状态、数据格式和审计记录能否跨系统一致，否则智能体在多个系统之间流转时，可能出现重复执行、责任无法追踪或权限被放大的问题。

编辑观察：采购评分表需要增加“失败时怎么停”

这份政策对企业最直接的影响，不是要求所有公司立即部署智能体，而是推动采购评价标准发生变化。过去的核心问题是“哪个模型回答得更好”，现在更应追问“哪个系统在真实任务中更可靠”。

企业可以将采购流程改为四步：先以业务任务定义需求，再以工具链能力筛选供应商；随后通过小范围试点验证闭环，最后以权限、安全、数据治理和人工接管完成风险验收。模型效果仍然重要，但它只是系统能力的一部分。

尤其需要加入一项经常被忽略的指标：失败时能否安全停止。在企业环境中，一个能够承认不确定、保留现场、提交人工处理并完整记录过程的智能体，往往比一个偶尔给出更漂亮答案、却会越权执行的系统更有采购价值。智能体工具链的竞争，最终也将从功能展示转向可控交付和持续运营。