早间简报 · 08:00
智能体获得执行权，验证机制随之跟上
随着交给AI智能体执行的范围不断扩大，验证和限制这些执行的机制也在同步产品化。今天，OpenAI公布了从发现漏洞到生成补丁全程无人介入的成果。AWS、NVIDIA和NetEase则相继介绍了对智能体行为进行审批、评估和监控的功能。
执行与管控首先在安全领域显现
安全是智能体执行能力与其风险最先交汇的领域。OpenAI利用一条无需人工介入的流水线，发现了948个Linux内核本地权限提升（LPE）漏洞，并表示随后确认了其实际可利用性，还生成了补丁草案1。它没有止步于发现，而是把验证和修复连成一条流程，这表明智能体承担的工作已从单个任务扩展到整个工序。不过，公开资料中没有说明使用了哪个模型，也没有说明补丁是否已被上游合并。
在推出强大的安全模型时，访问控制被放在设计的前面。OpenAI在AWS GovCloud（US-East）推出了网络安全服务Daybreak Red。只有获得批准的客户，才能通过Amazon Bedrock将GPT-5.6 Cyber用于经授权的安全工作4。能力越强，越需要事先确定谁可以用于何种用途。
同一天也出现了反方向的案例。GitBook通报称，11月2日部分基础设施凭据遭到未经授权的访问。公司称这是一次利用AI智能体的定向攻击，在轮换全部密钥后作废了所有客户API令牌9。随着智能体同时出现在攻防两端，集成令牌和权限管理的分量也变得与执行能力同样重要。
在运营现场，监督成为一项功能
安全领域中执行与管控相伴的模式，在企业运营现场也以同样的形态出现。马来西亚运营商U Mobile在Amazon Bedrock AgentCore上构建了智能体运营平台AiDaH，交由其负责6个部门的150余个运营场景。AWS和U Mobile表示，由此故障工单最多减少了84.5%11。NVIDIA也介绍了Factory Operations Blueprint：当生产线出现问题时，多个智能体分工调查根因13。
智能体直接执行的范围越大，把人工监督放在哪里就越成为设计课题。AWS在Amazon Quick的Smart Approvals中，由策略设定允许范围，由分类器判断单个行为，只把影响重大的决策交给人处理12。如果对每个行为都要求审批，人会习惯性地批准。这一功能试图通过按风险程度分配监督力度来解决该问题。NetEase易盾的Agent Guard检查的不是智能体的输出，而是其意图、权限和工具调用，并扫描Skill和MCP（Model Context Protocol）供应链18。
管控在部署之后仍在继续。NVIDIA介绍了用NeMo将运行中积累的智能体失败记录整理为带优先级的问题和定制评估，再落实到提示词、工具和测试框架代码修改的方法14。AWS则公开了将范围狭窄、重复出现的评估问题交给决策模型，作为AgentCore Evaluations基于代码的评估器使用的方法，并说明了在将这些检查用作发布门槛之前验证检查本身的流程22。审批、行为监控和失败回归测试正在不同层面处理同一个问题。
仍存在的空白
但现在就说管控机制正在取代能力竞争还为时过早。在开发工具市场，让更多智能体、更贴近开发环境的竞争依然激烈。TechCrunch报道称，Meta收购了Conductor，这家公司开发的工具可让工程师同时启动多个智能体，分别负责同一项目的不同部分2。GitHub Copilot已可在Xcode内置的编程助手中以公开预览形式使用3。并行智能体和原生IDE集成都在增加执行量，而监督机制仍在追赶这一速度。
另一个局限是，许多成效数据仍是当事方的发布。U Mobile的工单降幅是AWS和U Mobile公布的数值。OpenAI发现的漏洞能否经过内核维护者审查并被合并，目前也尚未确认。Ricursive Intelligence声称Ripple-65B Preview在智能体编程基准上超越了大得多的模型，但目前还没有独立验证6。除了管控智能体行为的机制，还需要从外部核实智能体成效的机制。
正在评估引入智能体的企业，应在关注性能指标的同时，审视其处理审批策略、权限范围和失败记录的体系。集成令牌以及MCP等外部工具连接也应纳入检查范围。接下来需要确认：OpenAI发现的内核漏洞补丁是否被上游合并并分配CVE，以及第三方能否复现Ripple-65B Preview的数据。