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 相关能力值得跟进但跟进方式要能解释、能回放、能停下来。