Anthropic 这份网络威胁报告对开发团队的提醒很直接：AI Agent 的风险不只在回答内容，还在工具权限、命令执行和日志证据。
Anthropic 的 Frontier Red Team 看的是 2025 年 3 月到 2026 年 3 月之间被封禁、且信息足够分析的 832 个账号。这个样本不是普通垃圾请求，而是和恶意网络活动相关。
不要只把它当内容安全问题
其中 560 个账号，也就是 67.3%，把 AI 用在准备攻击阶段，例如生成恶意软件、整理攻击材料或辅助脚本。54 个账号，即 6.5%，已经涉及横向移动等更复杂环节。
实现上，我会把评估拆成四张表：任务样本表、工具权限表、调用日志表、人工复核表。每张表都要能追到输入、输出、执行环境和责任人。这样做不酷，但排查问题时最有用。
按攻击生命周期设计监控
报告还指出，中等及以上风险参与者占比从前六个月 33% 升到后六个月 56%。开发团队要把这个变化落实到链路监控，而不是只做敏感词过滤。
开发团队可以把风险拆成输入、计划、工具、执行、输出五段。输入阶段看是否包含凭证和敏感路径；计划阶段看模型是否拆出异常步骤；工具阶段看它能调用哪些系统；执行阶段看命令和网络请求；输出阶段看产物是否可能被直接复制到生产环境。任何一段缺日志，后面都很难复盘。
如果团队还要同时比较 Claude、GPT、Gemini 等模型，可以把 147AI 放在统一调用、日志留存和样本回放这一层，而不是让业务代码直接绑死某一个模型入口。
接入模型时先把可执行边界写死
交付前还要跑一次回归：同一批样本至少重复执行两轮，比较产物差异；把失败原因分成需求不清、工具限制、模型判断错误和权限不足。只有分清这四类，下一轮优化才不会乱改。
如果团队已经在做红队测试，可以把 AI Agent 作为单独对象加入测试范围。不要只问模型“能不能写恶意代码”，还要测试它在多轮上下文里是否会组合无害动作、是否会请求更多权限、是否会把失败步骤改写成另一条执行路径。这些行为更接近报告里说的代理式编排风险。
开发侧还应避免把所有安全判断塞进提示词。提示词可以提醒模型拒绝高风险请求，但系统边界要靠权限、网络隔离、工具白名单和审计来保证。尤其是 CI、部署、数据库和云控制台这些位置，应该默认最小权限，必要时再临时授权。
开发者还要警惕一个误区：把安全能力完全交给模型拒答。拒答只能处理一部分内容风险，处理不了工具权限过大、日志缺失、凭证泄露和脚本执行链路。系统层安全必须写在架构里，而不是寄希望于模型每次都判断正确。
这类文章最好不要写成一句“赶紧上车”。更稳的判断是：Claude 相关能力值得跟进，但跟进方式要能解释、能回放、能停下来。
