74%技术用户要求AI代理行动前确认：自主与控制的边界在哪？

一项小型调查揭示的AI代理行为偏好

开源AI代理运行时项目HugiMuni的实习生、慕尼黑工业大学（TUM）硕士生Anastasia最近在其技术人脉圈中做了一次小型调查，样本量仅27-28人（视问题而定），并非随机抽样，因此结果只能作为早期信号而非代表性研究。但其中几个数据点仍然值得关注。

当被问及"如果AI认为用户的请求是个坏主意，它应该怎么做"时，74%（20/27）的受访者选择了先请求确认；33%（9/27）选择"继续执行但提示风险"；30%（8/27）选择"提出反对并建议更好的方案"；仅有7%（2/27）选择"直接执行"。该题允许多选。

这组数据勾勒出一个清晰的倾向：技术用户并不排斥AI的自主判断，但希望在AI偏离用户预期时保留一个确认环节。

用户最想塑造的是判断力，而非说话方式

调查还询问了受访者最想塑造AI行为的哪些方面。56%的人优先关注判断力——即AI如何做决策、何时该问、何时该做、以及应该有多大胆。44%选择了坦诚度，即AI以多诚实的方式挑战用户。33%关注代码质量标准。只有4%选择了沟通风格。

另一个值得注意的结果是：56%的受访者更倾向于自己撰写指令，而不是从预设的AI人格中选择。

这组偏好反映出一个深层需求：技术用户把AI代理当作需要精细调校的工具，而非需要挑选"性格"的消费产品。他们关心的是决策逻辑和质量底线，而不是AI说话是否讨喜。

自主执行不等于无限制授权

HugiMuni团队在帖子中提出了一个核心矛盾：我们既希望代理能自主调查问题、运行测试、持续工作而不需要时刻监督，又不想给它不受约束的权限。

代理修复一个有良好测试覆盖的小bug是一回事；代理决定重构生产数据库是另一回事。真正困难的工程问题是：这条边界应该划在哪里？

是通过持久化的用户指令来定义？还是显式权限？工具级别的策略？自动化验证？还是某种组合？这些边界又该如何在会话之间、项目之间、不同AI模型之间延续？

这些问题目前没有标准答案。不同代理产品（如Claude Code、Codex、Cursor）在权限模型上各有取舍，而用户的实际容忍度也因任务风险等级而异。

代理运行时（Agent Runtime） 指的是支撑AI代理持续运行、调用工具、维持状态并执行多步任务的底层基础设施。与单次对话的聊天机器人不同，代理运行时需要管理会话生命周期、工具权限、资源访问和错误恢复。具体到HugiMuni这类开源项目，运行时通常包含沙箱环境、文件系统访问控制、命令执行白名单以及跨会话的状态持久化机制。正是这些组件决定了"代理能做什么"与"代理被允许做什么"之间的实际边界，也是权限模型落地的技术载体。理解运行时的职责划分，才能理解为何权限边界难以简单定义——它同时涉及基础设施层、策略层和用户体验层的权衡。

工具级别策略（Tool-level Policy） 是代理权限控制的一种粒度选择：不按会话或用户整体授权，而是对每个可调用工具（如读写文件、执行shell命令、发起网络请求）单独设定规则。例如可以允许代理自由读取代码库，但对写入生产配置文件要求显式确认，对执行数据库迁移命令则完全禁止。这种方式的优势在于边界清晰、可审计，但缺点是工具数量增多时策略会变得复杂，且难以覆盖工具组合产生的风险（如先读取密钥再外发）。因此工具级策略通常需要与自动化验证（如命令白名单、差异审查）结合使用，才能形成可操作的防护体系。

从假设偏好转向真实经验

HugiMuni团队明确表示，这项调查是聚合匿名结果，仅作为早期信号，不构成对更广泛市场偏好的证据。他们下一步的研究方向是从"假设性偏好"转向"真实使用经验"，尤其关注那些日常使用Claude Code、Codex、Cursor等代理的开发者：哪些操作你乐意让代理直接做而不需要询问？哪些操作它绝不应该在没有确认的情况下执行？是否有代理真正越界的实例？

对于正在构建代理运行时的团队来说，这些真实案例比问卷数据更有指导价值。自主与控制的平衡点，最终要在具体的工作流和风险场景中被反复校准。