企业为何敢把任务交给智能体：评《北京市关于加快智能体引领发展的若干措施》之二
洪延青 2026-08-04 09:00 北京
安全的基础性作用
编者按
关于智能体，本公号发表过以下文章：
《北京市关于加快智能体引领发展的若干措施》将“全面提升安全治理能力”列为第七条，提出探索智能体分级分类监管、开展恶意滥用常态化整治、加快人工智能产业立法，并建设安全服务平台、靶场、可信沙箱和安全检测能力。这些安排方向明确，也体现出北京对智能体安全问题的高度重视。
但从智能体产业发展的内在逻辑看，安全治理不能只被理解为十项措施中的一项，也不能主要交由第七条集中承担。第一条提出的在线学习、自主进化和长期记忆，第二条提出的工具调用、任务持久化和技能市场，第三条提出的行业流程重构，第四条提出的智能终端和物理设备，第五条提出的人工智能增强型创业模式，第六条提出的智能体服务和结果付费，第八条提出的数据飞轮和公共算力，第九条提出的开源社区和智能体出海，实际上都以安全治理为基本前提。
原因在于，企业采用智能体，并不只是购买一种能够生成内容的软件，而是在一定范围内将任务、数据、系统权限乃至对外行动能力委托给一个技术系统。智能体能否持续获得这种委托，取决于它能否证明：行动边界可以限定，运行状态可以观察，异常行为可以中止，错误结果可以补救，关键过程可以追溯，最终责任可以确定。
⚡ 共同基础
从这个意义上说，安全治理不是智能体产业发展到一定阶段后再附加的限制，而是模型能力、应用场景、商业模式、数据利用和开放生态能够成立的共同基础。
一、智能体使安全问题从“生成什么”扩展到“代表谁做什么”
智能体建立在生成式人工智能基础之上，但其产业意义不止于生成。
一般的生成式人工智能主要提供文字、图像、代码或者方案，用户看到结果以后，通常还可以决定是否采用。智能体则进一步进入任务执行过程。它可以分解目标、制定计划、读取数据、调用工具、连接多个系统，并根据运行状态连续采取行动。生成内容只是其中一个环节，真正重要的是智能体随后是否会发送文件、修改账户、提交材料、安排生产、发起支付或者控制设备。
这意味着安全治理的对象已经发生变化。
•第一，安全问题从模型输出扩展到现实行动。判断一个智能体是否安全，不能只看它会不会生成违法有害或者错误内容，还要看它是否有权实施相应操作，以及操作是否仍在用户或者企业授权范围内。
•第二，安全问题从单次交互扩展到持续运行。普通生成工具通常在用户提出一次请求后返回一次结果；智能体则可能持续数小时甚至更长时间，经过多个步骤完成一项任务。运行时间越长，中间状态越多，实际行动偏离原始目标的可能性也越大。
•第三，安全问题从模型本身扩展到整个系统。智能体的实际行为不仅由基础模型决定，还取决于上下文、长期记忆、工作流、外部工具、身份权限、插件组件、业务规则和终端环境。仅仅证明模型本身通过了测试，并不能证明智能体系统进入真实流程以后仍然安全。
•第四，安全问题从事后纠错扩展到运行中控制。对于一段错误文本，用户通常可以选择不用；对于一次错误付款、错误数据传输或者设备操作，事后发现可能已经无法完全恢复。智能体治理必须把控制点前移到行动之前和运行过程中。
因此，智能体安全的核心不是笼统地要求“人在回路”，也不是要求用户对每一个中间步骤反复点击确认，而是建立一套可信委托机制：明确智能体代表谁、承担什么任务、可以取得哪些数据和工具、能够产生何种影响、哪些行为可以自动执行、哪些情况必须重新批准、何时应当暂停或者终止，以及由谁对最终结果负责。
只有这种委托关系可以被清晰界定和持续执行，智能体才可能从生成工具转化为企业真正可以依赖的生产工具。
二、第一、二条中的技术能力，只有可以被控制才能成为生产能力
《若干措施》第一条提出提升模型在线学习、持续学习和自主进化能力，优化超长程任务、复杂推理和规划算法，发展世界模型、群体智能、长上下文、工具调用、多智能体协同和记忆等能力。第二条进一步提出实施驾驭层工程，强化上下文工程、任务持久化、多智能体协作、系统可扩展和长程任务执行稳定性，并建设智能体开发平台、技能市场、软件商店和安全可控技术栈。
这些方向准确抓住了智能体技术发展的重点，但也说明安全已经进入智能体技术能力本身，而不是位于技术体系之外。
例如，在线学习、持续学习和自主进化能够使智能体根据新数据和运行反馈不断调整行为，但也意味着已经测试和批准的系统可能在部署后发生变化。如果缺少数据审查、版本管理、回归测试和回滚机制，企业很难确认今天运行的系统是否仍然是此前接受评估的系统。对于医疗、政务、金融、工业控制等高风险场景，持续更新不能等同于未经治理地直接改变生产系统行为。
超长程任务和任务持久化能够让智能体处理中断、等待和跨阶段任务，但也会带来目标偏移、异常循环、重复执行和资源失控等问题。智能体可能因工具调用失败而不断重试，可能在任务条件已经变化以后仍按照原计划执行，也可能在长期运行中逐渐突破最初设定的成本、时间和操作边界。因此，任务持久化必须同时配置状态观察、预算限制、重试上限、终止条件、人工接管和恢复机制。
长期记忆能够提高服务连续性和个性化程度，但记忆本质上也是一种数据处理和数据驻留。哪些信息可以写入记忆、保存多长时间、是否涉及与用户交互的第三人、用户能否查看和纠正、撤回授权后能否删除，都不能只依赖模型自行判断。没有记忆治理，所谓数据飞轮很容易演变为无限积累和不透明利用。
工具调用使智能体真正具备执行能力，也使身份和权限成为核心问题。智能体调用搜索工具和调用支付、邮箱、数据库或者生产设备，风险显然不同。对工具的控制不能停留在一张静态白名单上，而应当结合当前用户、具体任务、调用对象、数据范围、金额额度和操作类型作出判断。低风险、可逆行为可以在预先授权范围内连续执行；高风险、不可逆或者超出原计划的行为，应当触发重新批准。
多智能体协作和技能市场则进一步延长了责任链条。一个任务可能经过规划智能体、检索智能体、执行智能体和多个第三方技能共同完成。系统需要知道每一个组件分别取得了什么数据、调用了什么工具、对最终结果产生了何种影响。否则，一旦发生错误，就可能出现所有参与者都只对局部组件负责、却无人对完整任务负责的局面。
因此，第二条所说的“驾驭层工程”，不应只解决模型如何被调用和编排，还应当同时承担身份管理、权限控制、运行监测、异常中止、证据记录和版本治理等功能。跨模型、跨芯片、跨框架的互通，也不能只实现功能和接口兼容，还应保证授权边界、安全规则和审计信息不会在模型切换、组件替换和跨平台调用中丢失。
对于智能体而言，不能被有效控制的能力，还不能算作可以进入生产环境的成熟能力。安全治理由此构成第一、二条技术攻关能否转化为现实生产力的内在组成部分。
三、第三、四条中的场景和终端，只有形成可信行动才能真正扩大需求
《若干措施》第三条提出发展原生人工智能软件、科学智能助手、“智能科学家”和自主实验室，推动人工智能操作系统建设，并在科学、医疗、教育、政务、制造、文化等领域打造标杆场景。第四条进一步提出将智能体能力深度嵌入智能手机、智能眼镜、智能耳机、可穿戴设备、机器人和智能汽车等终端产品。
这些安排将智能体从软件环境推向企业核心流程、公共服务和物理世界。智能体所处场景越真实，承担的任务越重要，安全治理就越不能被留到系统建成之后再行补充。
医疗、教育、政务、制造和文化虽然都可以称为智能体应用场景，但它们涉及的行动类型和风险后果并不相同。智能体辅助检索科研文献、自动整理会议材料，与其参与医疗处置、教育评价、行政审批或者生产设备控制，不能适用同一种评测和监管方式。
智能体应用的分类，应当重点考察它在流程中做什么，而不能仅按照所属行业或者产品名称判断。一个系统是生成信息、提出建议、形成待审批方案，还是直接实施操作；能否改变账户、业务系统或者现实设备状态；其后果是否对外发生效力，是否可以撤回和恢复；这些因素比“是否使用大模型”“是否采用多智能体”更能反映真实风险。
第三条提出通过前沿部署工程师驻场共创、持续迭代推动应用落地。这种模式适合复杂企业流程，但驻场共创不能只完成技术适配，还应同步完成安全和责任适配。服务商需要与企业共同识别业务流程中的数据边界、权限节点、审批要求、异常情形和责任主体，而不是先让智能体尽可能多地连接系统，再由安全部门在项目末端补充限制。
标杆场景的验收也不宜只看系统是否上线、接入多少模型、配置多少智能体或者能否完成演示。真正的标杆应当能够证明：系统在真实业务中持续运行，任务成功率和人工复核成本可以接受，权限边界得到执行，异常操作能够停止，系统更新后可以重新验证，错误发生后能够恢复并查明责任。缺少这些条件的项目，可能是技术展示，但还不是可以复制推广的生产级应用。
第四条中的智能终端使这一问题更加突出。手机、眼镜、耳机、汽车和机器人能够持续感知环境，可能接触摄像头、麦克风、定位、通讯录、屏幕内容和设备控制权限。终端采集到的信息也不一定只属于设备使用者本人，还可能包括身边没有主动参与交互的第三人。
因此，智能体与终端的软硬联合定义，不能只优化模型性能、芯片功耗和响应速度，还应当同步设计权限提示、物理状态指示、敏感能力开关、本地与云端数据边界、异常中止和安全更新机制。文件提出将符合条件的新产品纳入数码和智能产品购新支持范围，未来“符合条件”的判断也不应只有技术先进性和产品销量，还应包括数据保护、权限管理、持续更新和事故处置能力。
从需求侧看，企业和消费者是否采用智能体，取决于它能创造多少便利和价值；但他们是否愿意持续开放数据、系统和终端权限，则取决于风险能否得到控制。安全治理不是压缩场景，而是使智能体能够从检索、总结、起草等外围辅助任务，进一步进入核心流程和执行环节的前提。
四、第五、六条中的新组织和新商业模式，需要以安全建立交易信用
《若干措施》第五条支持以OPC为代表的创新创业新模式，提出围绕算力、孵化、科技金融、知识产权和政策咨询建设公共服务平台，并推动智能体支持下的轻量化创业。第六条则提出发展Token经济，培育Token即服务、智能体即服务和结果即服务，推动从Token消耗量计费转向价值计费。
这两条实际上涉及智能体对企业组织和市场交易方式的重构。越是新型的组织和商业模式，越需要安全治理提供稳定的信用基础。
人工智能增强型单人创业可以大幅降低企业运营成本。一个创业者可以借助智能体完成市场研究、内容生成、客户服务、财务整理、合同审阅、软件开发和日常管理。但传统企业中由不同人员分别承担的执行、复核和监督功能，也可能因此集中到一个自然人和一组技术系统之中。
如果多个智能体共享同一组账户和长期凭证，如果付款、签约、报送和客户沟通均由系统连续完成，如果创业者一时无法介入，错误就可能在缺少人工制衡的情况下持续扩散。第五条所提出的公共服务平台和OPC全周期服务站，因此不应只提供注册、算力和创业辅导，还应提供适合轻量化经营主体的权限管理、数据治理、合规审查、责任保险、安全检测和业务连续性服务。
对于依法必须由具备相应资格的自然人作出的专业判断、法定签署和责任承担，也不能因为企业规模较小或者智能体能力较强而被技术系统替代。智能体可以辅助律师、会计师、医生和其他专业人员，但不能成为规避法定资格和责任要求的工具。
第六条提出的结果即服务和价值计费，同样以安全和可验证性为前提。按Token计费时，服务商主要证明模型资源已经被调用；按结果计费时，则必须进一步说明任务是否真正完成，完成结果是否符合质量要求，行动是否在授权范围内，是否产生未经约定的风险和损失。
因此，从Token消耗量转向价值计费，不只是改变价格单位，而是要求建立新的任务定义、质量评价、过程证据和责任分配机制。一个系统即使以较低成本完成了任务，如果依靠过度开放数据权限、跳过必要审批或者将高风险错误转嫁给企业，也不能称为有效的价值创造。
文件提出探索Token服务质量评估和计费规范，并建立以智能质量、调用量和转化效率为核心的评价体系。未来的质量指标不能只包含响应速度、调用数量和任务完成率，还应纳入人工接管率、异常重试、错误损失、权限违规、数据外发和系统恢复能力。Token可以作为推理投入和成本分析指标，但不宜直接作为产业价值和政策绩效指标。
服务券、Token券和财政支持也应遵循同样逻辑。政策资金不宜因企业产生了大量调用量而自动兑现，而应当与真实业务任务、可验证结果、稳定运行和安全表现挂钩。这样才能避免企业为了获得补贴而增加无效调用，也能推动服务商从出售计算消耗转向交付可靠结果。
安全治理由此不只是新业态的约束，而是结果付费、专业服务、保险赔偿和风险定价得以成立的市场基础。没有可验证过程和可归责结果，智能体服务就难以形成长期交易。
五、第八、九条中的数据、算力和开源，只有具备共同安全基线才能形成规模生态
《若干措施》第八条提出建立多层次算力供给体系，建设低成本、标准化的公共算力服务，支持“Token工厂”，并鼓励汇聚行业知识和智能体执行数据，构建数据飞轮。第九条提出建设开源社区和技术平台，支持开源互联协议、开发框架、终端操作系统及硬件公版，并推动智能体产品和服务出海。
这些要素能够降低智能体开发和使用成本，但要素越开放、参与主体越多，越需要共同安全规则降低市场识别和交易成本。
首先，智能体执行数据不能被笼统理解为可以自由汇聚和反复利用的生产资料。执行轨迹可能包含个人指令、企业业务信息、操作凭证、客户材料、审批记录、错误过程和第三人信息；长期记忆、检索索引、嵌入向量、推理缓存等派生对象，也可能继续保留原始信息的敏感性。
因此，第八条所说的数据飞轮，应当建立在分类、授权和可追踪利用基础之上。项目需要明确哪些数据仅用于完成当前任务，哪些数据可以用于改进服务，哪些数据可以进入后续训练；原始数据删除以后，相关记忆、向量和缓存是否同步处理；在线学习形成的新版本是否经过验证并可以回滚。没有这些规则，数据飞轮可能在短期内增加数据规模，却会削弱企业和用户继续提供数据的意愿。
其次，公共算力和规模化推理服务不仅是资源供给设施，也是多主体共同使用的运行环境。算力池化、虚拟化和弹性供给能够降低中小企业成本，但不同用户、模型、数据和智能体任务集中运行，也会增加数据隔离、权限配置、模型资产保护和跨租户访问风险。公共算力服务需要同步建设身份认证、资源隔离、访问审计、数据清理、事件响应和服务连续性机制。
对所谓“Token工厂”的评价，也不能只看名义算力和Token产出规模，而应当看可稳定调度的真实能力、单位有效任务成本、运行可靠性和安全隔离水平。算力规模只有转化为可靠、可用的任务结果，才构成智能体产业能力。
再次，开源开放并不意味着降低安全要求。一个智能体系统可能同时依赖开源模型、开发框架、插件、技能、外部接口和终端组件。开放组件越多，企业越需要知道其开发者、版本、许可证、权限范围、第三方依赖和漏洞响应机制。
第九条提出建设开源贡献度评价体系和开源项目孵化机制。未来对开源项目的支持，不宜只看代码量、下载量和开发者数量，还应当关注维护持续性、版本管理、依赖透明度、漏洞修复和紧急撤回能力。智能体技能市场和软件商店中的组件，还应明确其所需数据和权限，发生重大权限变化时重新审核，出现严重风险时能够及时禁用并通知用户。
智能体出海同样需要安全能力支撑。文件提出“一国一策”研究智能体出海路径，并提供合规培训、知识产权和风险预警服务。智能体出海不仅是模型和软件出口，还可能涉及跨境访问企业数据、调用境外工具、远程执行任务和持续更新。安全、数据、权限和供应链证据将直接影响境外客户是否愿意采用中国智能体产品，也会影响产品能否进入当地高价值行业。
因此，安全治理与数据利用、算力共享和开源开放并不是相互抵消的关系。统一的身份、权限、版本、日志和漏洞响应规则，反而能够降低企业对每个组件重复开展审查的成本，使中小服务商更容易进入市场，也使开放生态能够在可预期条件下持续扩大。
六、第七条应当成为横向治理中枢，而不是安全工作的唯一承载条款
《若干措施》第七条提出分级分类监管、行业自律、恶意滥用治理、产业立法、安全基础设施、可信沙箱和“以模治模”等安排。这些内容具有重要基础作用，但主要集中于监管方式、公共平台和外部检测，尚不足以单独承载智能体从研发到运行的全部安全问题。
真正有效的智能体安全治理，不能只在系统上线前进行一次检测，也不能主要依靠安全平台在系统外部发现问题。它需要分别进入第一条至第九条所支持的技术、场景、终端、创业、计费、数据、算力和开源活动之中。
•第一、二条支持的技术攻关项目，应当把身份、权限、记忆治理、运行观察、异常中止和回滚能力作为智能体工程的一部分。
•第三、四条支持的标杆场景和智能终端，应当根据智能体的行动类型和后果确定安全要求，并将真实运行、人工接管和事故恢复纳入验收。
•第五条支持的创业模式，应当配套轻量化但不能缺位的权限、财税、数据、保险和业务连续性服务。
•第六条支持的Token和智能体服务，应当以安全、可靠的任务结果而不是单纯调用量作为质量和财政评价依据。
•第八条支持的数据飞轮、公共算力和Token工厂，应当同步建立数据来源、用途控制、租户隔离和运行审计机制。
•第九条支持的技能市场、软件商店和开源社区，应当建立组件身份、权限声明、版本管理、漏洞响应和退出规则。
•第十条提出统筹财政资金、政府投资基金和重点项目支持，则为安全要求进入产业政策提供了最直接的实施工具。安全不应只是一项原则性申报承诺，而应当成为项目遴选、分阶段拨款和最终验收的证据条件。
北京下一步可以围绕这一横向治理逻辑，重点建立四项基础制度。
•第一，建立以行动权限和后果为核心的分类机制。每个智能体项目都应说明其在工作流中的位置，是生成、推荐、请求批准还是直接执行，能够访问哪些数据和工具，是否改变系统或者现实状态，后果是否可逆。风险越高，授权、评测、记录和人工监督要求越严格；低风险应用则应允许快速开发和部署。
•第二，建立生产级智能体的可信委托基线。项目应明确智能体代表谁、完成什么任务、使用哪些数据和工具、哪些行为可以自动执行、哪些行为需要重新批准、谁能够暂停和接管，以及谁对业务结果和技术运行分别负责。
•第三，将安全能力建设为公共基础设施。第七条所提出的靶场、可信沙箱、安全检测和认证平台，不宜只是提供一次性检测，而应进一步形成统一测试方法、参考架构、事件信息共享和面向中小企业的公共安全服务。政府最适合提供的，正是单个市场主体难以中立建设的共性能力。
•第四，将安全证据纳入财政支持、政府采购和标杆项目验收。评价项目不能只看平台是否建成、模型是否接入和调用量是否增长，还要看系统能否持续稳定运行，权限是否得到有效限定，异常是否能够停止和恢复，关键行为是否可以追溯，系统更新后是否重新验证，发生问题后是否具备迁移和退出能力。
这样，第七条就不再是与产业发展并列的一项安全措施，而会成为贯穿其他各条的治理中枢。
七、安全治理本身也是一种生产能力
传统产业政策中，安全往往被理解为发展需要承担的合规成本。但在智能体产业中，安全治理具有明显的生产性。
•它能够降低企业采用成本。统一的分类、测试和安全标准，可以减少企业对每一家智能体服务商重复开展审查和谈判。
•它能够扩大企业授权范围。当数据访问可以限定、工具调用可以控制、行动过程可以追踪、异常操作可以中止时，企业才可能把更多核心任务交给智能体。
•它能够支持新的商业模式。结果付费、智能体即服务和轻量化企业组织，都需要明确的任务定义、责任分配和运行证据。
•它还能够促进开放竞争。当第三方智能体能够按照统一标准证明自身安全能力，平台、软件和终端就不必以抽象的安全风险为由维持完全封闭的生态。
因此，安全治理不是智能体发展的外部约束，而是智能体从技术能力转化为可交易产品、从试点项目转化为生产工具、从单点应用转化为开放生态的制度基础设施。
《若干措施》已经对北京智能体产业的技术、场景、终端、创业、计费、算力、数据和开源作出较为完整的布局。下一步真正需要做的，不只是继续扩展第七条的安全工作，而是把安全要求分别嵌入每一种技术支持、场景建设、公共平台和财政工具之中。
归根到底，智能体发展的真正门槛，不只是模型能否完成任务，而是企业和社会是否愿意把任务交给它。企业愿意交出多少数据、开放多少系统、授予多大行动权限，决定了智能体能够在多大程度上成为现实生产力。
而安全治理所要建立的，正是这种委托得以发生和持续的信任条件。
安全不是智能体产业发展之后需要补上的一道防线，而是北京政策所提出的模型能力、应用场景、商业模式、数据飞轮和开放生态能够真正落地的共同基石。
END
文章索引
数据保护官（DPO）社群主要成员是个人信息保护和数据安全一线工作者。他们主要来自于国内头部的互联网公司、安全公司、律所、会计师事务所、高校、研究机构等。在从事本职工作的同时，DPO社群成员还放眼全球思考数据安全和隐私保护的最新动态、进展、趋势。2018年5月，DPO社群举行了第一次线下沙龙。沙龙每月一期，集中讨论不同的议题。目前DPO社群已超过400人。关于DPO社群和沙龙更多的情况如下：
DPO线下沙龙的实录见：
域外数据安全和个人信息保护领域的权威文件，DPO社群的全文翻译：
传染病疫情防控与个人信息保护系列文章
关于数据与竞争政策的翻译和分析：
健康医疗大数据系列文章：
网联汽车数据和自动驾驶的系列文章：
网络空间的国际法适用问题系列文章：
《网络数据安全管理条例（征求意见稿）》系列文章：
《数据安全法》的相关文章包括：
赴美上市的网络、数据安全方面的两国监管乃至冲突方：
个性化广告或行为定向广告（behavioral targeting advertising）系列的文章：
内容安全方面的文章如下：
第29条工作组/EDPB关于GDPR的指导意见的翻译：
数字贸易专题系列：
关于中国数据出境安全管理制度的文章
美国方面的个人信息保护立法的文章：
关于印度的数据保护和数据治理政策和技术文件的文章有：
关于数据的安全、个人信息保护、不正当竞争等方面的重大案例：
关于保护网络和信息系统安全的相关文章包括：
围绕着TIKTOK和WECHAT的总统令，本公号发表了以下文章：
关于我国数据跨境流动监管体制变革的系列文章：
针对审计在数据安全、个人信息保护、AI安全的作用与落地实操，本公众号发布过的文章：
关于中国的网络安全审查制度，本公号发表过的文章：
关于个人信息安全影响评估的文章如下：
围绕供应链安全，本公众号发表文章：
关于AI与标准化工作，本公号发表的文章：
关于新加坡数字化（包括个人信息、网络安全、人工智能等）方面的改革，本公号发表的文章：
关于健康医疗数据方面的文章有：
关于欧盟技术主权相关举措的翻译和分析：
美国利用法律和政策工具单边化地维护或强化美国的安全和经济利益，本公众号曾发表文章：
关于AI技术的系列读书笔记：
本公号发表过的关于数据执法跨境调取的相关文章：
地缘政治与跨国科技公司运营之间的互动影响：
关于AI“情感交互”和“拟人化互动”，本公号发布过以下文章：
关于业务场景中数据跨境流动的文章如下：
关于欧洲的人工智能监管方面的立法、政策和实践方面的文章：
关于我国对人工智能技术和应用的监管发展，本公号发布过以下文章：
关于人工智能安全和监管，本公号发布过以下文章：
本公号曾发表的人脸识别系列文章：
针对美国的人工智能监管政策发展，本公众号发表过如下文章：
关于我国《个人信息保护法》的立法、标准化和执法等内容，本公号发表的相关文章包括：
通过技术增强对个人信息的保护，例如匿名化、假名化技术，隐私增强技术，以及通过技术手段或模式强化个人信息主体的权利实现和意思表达，越来越成为值得关注的主题。本公号曾经发表的文章包括：
关于域外在数据、电信、外国投资方面所建立的国家安全相关的审查机制，本公号发布过以下文章：
本公号发表过的关于数据要素治理的文章有：
关于数据抓取和公开数据保护，本公号发布过以下文章：
关于AI能力扩散议题，本公号发表过以下报告：
关于AI风险治理和数据保护的交叉，本公号发表过的文章：