豆包千问同日关停自建智能体：从工程视角拆解确定性需求与概率性系统

事件速览

2026年7月4日，字节豆包与阿里通义千问同日宣布：7月15日前全面下线用户自建智能体功能。已创建的智能体停止运行，人设、记忆、知识库数据无法完整保留。

这不是一次简单的产品迭代。它暴露了智能体工程落地中最核心的矛盾——确定性需求与概率性系统的不可调和冲突。

一、概率性系统的工程困境

大模型生成天然具有概率性。即使通过提示词反复约束，输出格式错误仍频繁出现。

企业智能体大量故障的根因并非模型能力不足，而是输出格式不符合下游接口标准。工程体系要求输入输出固定、全流程可预判，但智能体行为浮动大，两者的匹配阈值极低。

多智能体协作模式下问题更复杂：

• 不同Agent之间的状态同步存在时序不一致
• 权限管控在跨Agent调用时频繁断裂
• 通信内耗叠加，故障排查难度远超传统软件
• 一个Agent的异常输出会沿调用链级联扩散

行业实测表明，经过针对性微调的单一模型架构，在多数工程场景中反而更稳定——少即是多。

二、责任归属：谁对概率性输出负责

控制权与责任分离是深层矛盾。平台握有系统的生杀大权，用户掌握行为的定制权限，双方都不愿为最终结果独立担责。

平台担心的核心是开放提示词带来的不可预测性。用户修改一句系统提示词，推理路径就会发生剧烈变化。当智能体输出违规内容时，是模型基座问题还是用户指令问题？这个责任边界目前无解。

从工程视角看，缺三样东西：

1. 全链路审计日志——无法回溯Agent的完整决策链路
2. 不可篡改的追责存证——难以区分模型原因与指令原因
3. 责任分层机制——开发者、部署者、用户的责任未按链式分配

2026年4月五部门联合发布的《人工智能拟人化互动服务管理暂行办法》7月15日正式施行，要求情感陪伴类AI进行角色备案与内容审核。平台选择一刀切关停而非分级治理——本质上是技术架构不足以支撑精细化的安全管控。

三、Harness：新一代智能体治理架构

传统工程手段试图用刚性约束去限制概率性行为——这条路走不通。根本原因在于：传统软件的错误空间是离散的、可枚举的，而大模型的错误空间是连续的、不可枚举的。

需要全新的治理架构：Harness（智能体安全管控层）。

Harness在架构层面显式定义智能体的行为边界，而非靠事后追责。包含四个层次：

1. 行为边界层

为每个智能体定义可执行操作的白名单。不允许超出权限范围的工具调用、API访问或数据读取，与微服务零信任原则一致——最小权限、默认拒绝。

2. 输出校验层

输出到达下游系统前，经过格式校验、内容过滤、合规检测三层关卡。不符合规范的输出被拦截并触发重试或降级，相当于面向概率性数据流的API网关。

3. 审计追溯层

记录每次推理的完整上下文——输入提示词、模型原始输出、后处理日志、调用链路追踪。形成不可篡改的审计链，支持事后精确归因。

4. 熔断降级层

当行为超出预设安全阈值（如连续输出违规内容），自动触发熔断机制，将智能体切换至安全模式或暂停运行。

IBM在2026年2月发布的《智能体安全指南》提出了四条一致原则：持续人类监督、最小权限与隔离、默认安全设计、透明可追溯。行业正在此基础上形成统一的Harness标准。

四、从架构看行业趋势

字节与阿里的同日调整并非巧合。监管合规是直接推手——上海「清朗」专项行动累计下架违规智能体1.4万余个。在缺乏统一Harness体系的情况下，海量自建内容的安全审核压力让平台不得不结构性调整。

算力成本是隐藏账单。持续的内容审核、对话过滤、未成年人保护投入在算力资源日趋紧张的背景下不可持续。

值得注意的是，两家企业在C端关停的同时，B端Agent服务都在加码——火山引擎和阿里云的Agent服务平台投入不降反增。C端通用智能体收缩，B端垂直Agent扩张，是工程架构可行性的必然选择。

谁先建立起可控的Harness体系，谁就能在下一阶段的Agent竞争中占据先机。

五、工程团队的应对建议

1. 建立输出校验层——在下游接口前增加格式校验与异常兜底，防止概率性错误穿透到生产环境
2. 引入全链路追踪——记录每次推理的上下文与决策路径，支持事后精确归因
3. 实施最小权限原则——为智能体定义严格的操作边界，禁止超出范围的工具调用
4. 设计熔断机制——设定安全阈值，异常行为自动降级或暂停

本文信息整理于2026年7月6日。事件动态变化，请以平台官方公告为准。