产业观察｜企业限制Agent自治边界，反而更稳落地

「给Agent越多自由越好」的默认假设，在规模化部署中被改写。越来越多企业发现：真正决定上线成败的，往往不是Agent能不能一口气跑一百步，而是第37步错了时，系统能不能刹车、回滚、说清楚。

这条产业观察没有单一厂商发布，而是对近期多条线索的归纳：Salesforce关于自改进Agent方差上升的研究、Guidelight对containment公开披露不足的评估、以及企业侧Agent试点从Demo走向生产的共同教训。所谓Agent自治边界，白话是明确Agent能调用哪些工具、能花多少钱、能接触哪些数据、在哪一步必须人类点头；所谓护栏，白话不是削弱能力，而是把失败模式限制在可恢复范围内——就像自动驾驶不会一上来取消方向盘。

公开讨论指出，限制Agent单独能做什么、保留清晰规则的企业，往往比追求最大自治的团队更稳；完全自主的多步工作流常在长链条上失败，赢家做法是给Agent划职责、设护栏，人类在关键节点保留否决权。落地清单收敛为角色边界、支出上限、工具白名单、审计日志与人工升级路径；平台竞争从「能自动100步」转向「第37步错了能否回滚并说清楚」。

CIO验收可收敛为四问：

1. 单位成功工作流：同样任务下，Agent方案是否比纯人工更省、更稳？
2. 紧急刹车：权限撤销、会话冻结与人工接管路径是否演练过？
3. 审计回放：失败时能否定位「哪一步、哪个工具、哪条记忆」出错？
4. 场景化阈值：金融、客服、IT运维的自治等级是否分开配置，而非一刀切？

产业观察上，自治是旋钮，不是道德高地。CIO验收应看「单位成功工作流」与「紧急刹车」，而非单次Demo最高分。可以把它想成：自动驾驶不会一上来取消方向盘——企业Agent亦应先定义L2/L3时人必须盯哪里。

需要把边界读清楚。「限制自治」须场景化配置；金融、客服、IT运维阈值不同。下一观察点是行业是否形成可引用的「自治等级」标准与保险条款是否纳入护栏要求。