Meta 的超级智能实验室周一发布了两款新的顶尖模型：Muse Wonder 与 Muse Wonder Full，标志着该公司首次尝试推出前沿大模型。

如果说 Muse Spark 的目标是打造一款能够以低时延运行的轻量级模型，那么 Wonder 系列模型体量更大，据称能力也更强，在编码（coding）等复杂任务上的基准测试得分更高、表现更好。

根据 Meta 在模型卡中展示的测试结果，Wonder 与 Wonder Full 在基准测试中取得的分数与 Fable 5.1 和 GPT-6 Astra 相当。

Meta 在介绍这两款模型的博客文章中写道：「它们共同标志着我们扩展阶梯上的下一步，也是迈向个人超级智能的重大飞跃。」

这一规模也反映在了定价上：通过 Meta 模型 API 调用 Wonder 的价格为每百万输入 token 4 美元、每百万输出 token 20 美元，成本大致与 GPT-6 Sol 或 Opus 5.5 相当。

值得注意的是，Wonder Full 仅向 Muse Code 订阅用户开放，并不会通过 API 提供服务。此外，这两款模型都将被用于驱动 Muse 智能体。

为了延续其开发能够在长时间跨度上执行任务的个人助理这一方向，Meta 特别强调了新模型在保留与综合用户提供的信息方面的能力，Meta 将这一特性称为「主动记忆」（active memory）。

为了实现更好的记忆能力，Meta 重点提到了 MemoryBench 基准测试，该基准用于挑战持续学习与记忆构建框架。根据 Meta 的测试，Muse Wonder 在 MemoryBench 上的得分现已高于 Fable、Opus 和 Astra。

研究科学家 Kavya Kopparapu 在随发布同步上线的视频中表示：「我们投入了巨大的精力，确保你的模型能够在数天、数周、数月乃至更长的时间里记住对你而言重要的内容。」

这两款新模型是自去年 8 月 Scale AI 创始人 Alexandr Wang 重整 Meta 人工智能业务以来的首款前沿大模型。此后，Meta 发布过轻量级的 Muse Spark 模型以及 Muse 智能体，但一直未推出 OpenAI 和 Anthropic 所擅长的那种顶尖模型。

根据该文章所述，这些模型在 Meta 位于俄亥俄州中部的 Prometheus 数据中心进行训练，该数据中心已于今年早些时候上线。

生成式AI

一、GPT-6.1 Sol默认上下文扩至500k，订阅不收长上下文费

1. OpenAI把Codex和ChatGPT Work中GPT-6.1 Sol的默认上下文从272k扩至500k，增幅约80%，可手动调至上限1M；
2. Tibo称，用订阅额度运行不收长上下文附加费，任务照常消耗额度；API调用仍按价格表计费；
3. 今年7月曾为GPT-5.6 Sol提至372k，因反复读取缓存致用量超预期退回272k；Claude Code中Opus 5.5与Sonnet 5.5默认为1M。

https://mp.weixin.qq.com/s/82GYLfd5_-xO_yuQf9MTRw

二、开发者疑Claude后台接入未发布模型，身份尚未证实

1. 多位开发者晒出实测，称选的是Opus 5.5、效果却像换了模型，怀疑后台已路由至新模型，猜测含Opus 5.6、Fable 5.5，有人称其"Claude Next"；
2. 开发者Chetaslua称用4行提示词、运行2小时、耗2700万Token，由JS逐帧画出30秒动画；
3. 网友以不联网问答VoxelBench作测试，文章称这还不能独自验明模型身份。

https://mp.weixin.qq.com/s/K2QI8P_MYg563wmoT9og8Q

三、OpenClaw发布v2026.10.1，智能体可主动检索已装Skills

1. OpenClaw发布v2026.10.1，官方称汇集402位贡献者、2425个PR、3055次提交；
2. 新增skills_search与skills_read，Agent可按需检索并读取已装Skills；兼容的MCP Apps可在聊天区旁打开，完整备份可存至Cloudflare R2；
3. Reddit有用户称频繁更新带来兼容性问题，GitHub有从v2026.9.5升级失败的报告。

https://mp.weixin.qq.com/s/bNfaQyThKpijj-B7yBgDnw

四、千问提出QwenGyre框架，面向超长程任务做在线强化学习

1. 千问团队提出在线强化学习框架QwenGyre，面向持续数小时、累计处理百万级token的超长程智能体任务；
2. 以弹性调度把空闲GPU逐步转入训练且不中断任务，以轨迹树和轨迹预算减少分叉执行的重复计算；
3. Qwen3.8-2.4T训练48步，NL2RepoBench通过率由52.48%升至58.54%；总耗时由Async的134.55小时降至75.42小时，加速1.78倍。

https://mp.weixin.qq.com/s/sl8sxECkV7YzuOJ3QTrmNw

五、智谱GLM-5.3-Highspeed曝光，网友晒出490 tokens/s

1. 据网友爆料，GLM-5.3-Highspeed已在Zcode 3.15.1灰度，订阅用户随机获得，晒出速度达490 tokens/s；
2. Pi模型目录显示其上下文100万token、最大生成131,072 token，设三档思考强度，与普通版一致；
3. 上月发布的GLM-5.3-FlashX最高200 tokens/s，5月的GLM-5.1-highspeed为400 tokens/s。

https://mp.weixin.qq.com/s/lxjRkCAIQVFUopmHRI-81Q

前沿科技

六、上海AI实验室开源书生SCP-Lab，统一调度异构实验设备

1. 上海AI实验室基于科学智能上下文协议SCP推出实验设备访问与协同协议书生SCP-Lab并开源，供科研智能体统一发现设备能力、提交任务并获取反馈；
2. 提出L1至L5五级控制粒度，从整套实验流程细到机械臂原子动作；安全管控仍由本地系统负责；
3. 已在化学合成、药物筛选等9个场景验证；清华张数一团队借此完成上海、北京、苏州三地四节点的Cas12a定向进化协同。

https://mp.weixin.qq.com/s/jYnGPKKJm6jZuntWfR3PuQ

报告观点

七、Meta首席AI官亚历山大·王：个人Agent是消费软件终局

1. Meta首席AI官亚历山大·王在David Senra播客称，Meta不与同行拼编程Agent，押注面向35亿日活用户的个人Agent，超级智能体是C端软件终点；
2. Muse从2月原型打磨7个月，100多项指标全部达标才发布，核心团队不到200人；官方只称用户"数以百万计"；
3. 他称模型研发像"采钻石"，收益呈幂律分布，TBD团队研究员全部直接向他汇报。

https://mp.weixin.qq.com/s/D6ZpSpSyv7cRn4Ze4gwFJg

八、Karpathy估算：全球仅约5000人能用上最前沿内部AI

1. Karpathy发推估算，全球约5000人（约0.00006%）可在内部直接使用最前沿系统，约60亿人（约75%）几乎没接触过LLM；
2. 另有10亿至20亿人偶尔使用免费版产品，约2000万人（约0.2%）在数学和编程领域专业使用前沿级LLM；
3. 他把差距归因于任务规模与时间跨度、能力集中在可验证且经济价值高的领域，以及免费版、付费版与内部系统的访问权限不同，并称人类审查能力已开始跟不上。

https://mp.weixin.qq.com/s/oCdv3qGiBee4KM5eZBuRQw

九、王兴兴工博会谈具身智能：临界点最快一两年内到来

1. 宇树科技创始人王兴兴10月12日在第26届中国工博会圆桌对谈称，具身智能临界点快的话一两年都有可能，今年8月他的判断是快则两到三年；
2. 他称过去十几年最大的错误是对AI相信不够，并预计明年ChatGPT-7发布很可能击穿具身智能目前的瓶颈；
3. 宇树内部在尝试"物理AI自进化"系统，把代码编写、训练、部署、测试和反馈做成自循环，目前仍需人参与评价。

https://mp.weixin.qq.com/s/T714yLS3esyfFF6RBxcpJA

👇加入AGI数据库，AI智能问答

👇订阅下方合集，获取每日推送

2026-10-12 · 研究

- 法律咨询- 试用 AutoClaw

大语言模型正从单轮代码生成转向更广泛的"专业协作"（Professional Cowork）。现实世界中的知识工作提出了独特要求：模型必须在明确的目标和紧迫的交付期限下，处理碎片化的源文件，将专业知识整合为连贯的分析，并在整个执行生命周期中保持领域严谨性。法律工作集中体现了这些挑战，是训练模型在高风险专业环境中运行的理想压力测试。

法律实践要求事实、制定法原则、分析推理和面向客户的交付成果之间保持不间断的链条。当接到一项专业任务时，智能体必须从源文件中提取核心问题，建立可辩护的论点，并按照精确的任务规范对结论进行格式化。同时满足所有这些约束，才是衡量领域专用模型的真正基准。

我们从复杂任务执行、专业法律推理和真实法律工作流三个维度对 GLM-Legal 进行了评估。GLM-Legal 在 Harvey LAB 上达到了 19.2% 的全通过率，同时在 LegalBench 和 PLawBench 上与前沿闭源模型持平，尽管其参数量显著更小。

基准测试亮点

在复杂执行、法律推理和真实场景起草两个维度上，GLM-Legal 在保持高推理效率的同时，达到了前沿级别的性能：

• Harvey LAB（全通过率 19.2%）： 在覆盖 24 个执业领域的真实律所工作流中，GLM-Legal 得分为 19.2%，相比其基座模型提升了 12.5 个百分点。在 Harvey 严格的全通过评分标准下，这证实了端到端任务执行的可靠性，不存在中间环节的性能下降。
• LegalBench（领域推理持平）： 在参数量显著更小的前提下，对专业合同、并购文件和司法意见的解析精度可与顶级闭源前沿模型媲美。
• PLawBench（中文本地化实务）： 在细粒度评分标准下，中文法律咨询、案件分析和文书起草方面，与领先前沿系统表现持平。

训练方法

GLM-Legal 优先考虑训练效率。它基于轻量化的 GLM-5.3-Flash 基座构建，通过专业化中期训练和高效率的后训练来扩展领域能力。我们将基础预训练与下游任务执行直接挂钩，训练模型解析源记录、适用法律原则、组织论证结构，并在最终交付阶段保持输出质量。

1. 中期训练：夯实领域基础

中期训练建立了系统的法律基础。我们扩充了高质量法律语料的规模，使模型能够在密集的领域语境中学习法律概念、制定法规则和解释框架。此阶段强化了事实、规则与结论之间的演绎联系，为复杂下游执行提供了所需的知识基底。

2. 后训练（Post-training）：模型与智能体框架的协同演化

后训练通过在数万个贴近真实场景的法律环境中开展强化学习，把领域知识转化为任务执行能力。模型在这些具体约束条件下，学习规划分析思路、推进工作流程，并产出最终交付物。

在该设定中，框架（Harness）充当运行时编排底座，负责管理任务上下文、连接工具集并路由执行反馈：

• 协同迭代优化： 框架结构与模型训练同步迭代。任务结构化、上下文摄入与运行时反馈回路共同决定智能体的探索行为。
• 双向学习： 模型训练中浮现的边缘案例会精确定位框架中的架构瓶颈；反之，框架的改进也让模型接触到更真实的执行约束，从而训练它检索相关上下文、依据中间执行信号自适应调整，并在从提示接收到最终签发的全流程中达到生产级标准。

3. 生产反馈闭环

真实业务流与一线从业者的反馈为我们的优化路线图指明方向。在生产环境中，法律专业人士依照具体标准来评估产出：

• 关键问题与边缘案例是否都被覆盖？
• 论证是否充分、引用是否在法律上站得住脚？
• 交付物是否严格贴合案情摘要（matter brief）？
• 下游团队能否直接复用成果、无需返工？

这些要求把主观质量转化为具体的工程损失信号。当排查漏掉事实、分析浅尝辄止、格式偏离规范等问题时，我们会审视整条执行链路，分离出原始模型能力、上下文预编排与工作流逻辑各自的贡献。

随后把这些发现直接反馈进下一轮训练的任务环境、评估量表与框架设计之中，并对照生产基准验证改进效果。这样一条贯穿"实际需求—任务环境—框架—模型训练"的紧密闭环，确保算法进展能直接转化为生产侧的可靠性。

把 GLM-Legal 带入 AutoClaw

不久后，你就能在我们的桌面原生智能体平台 AutoClaw 中实际使用这些能力。下面的示例展示了 GLM-Legal 如何帮助处理三类常见法律任务：合同审阅、案件准备与跨境项目筹划。

1. 合同审查：让退出条款真正保护客户

任务：为一位更换服务商的客户审查一份软件服务合同，重点关注解除（终止）与交接条款。

GLM-5.3-Flash

解除与交接

合同允许客户提前 60 天通知解除，并为重大违约设置了 30 天的补救期。建议缩短通知期，以便客户获得更大灵活性。合同解除时，应要求服务商返还客户数据以及客户已付款的已完成交付物。增加一项与替代服务商合作的义务，包括合理提供文件查阅权限，并协助交接。确认未结款项以及任何过渡支持费用。

GLM-Legal

解除与交接

将客户便利性解除（convenience-termination）的通知期从 60 天缩短至 30 天。针对知识产权（IP）、保密或数据安全义务方面的违约，取消补救期，以便客户能够 立即解除合同。合同第 4 节已将工作成果（work product）归属于客户：要求返还所有交付物及在制工作成果，无论是否已付款。增加 最长 90 天的过渡协助期，内容涵盖源代码、文档、数据以及向客户或其继任服务商的知识转移，费用按服务商届时现行的费率计算。

更换服务商时，你的团队需要一份能够保护交接的退出条款。

GLM-Legal 将这一目标转化为具体条款：在发生严重违约后立即解除、返还工作成果，并提供最长 90 天的过渡支持。AutoClaw 会把这些修订以 Word 文档中的「修订」（tracked changes）和批注（comments）的形式呈现，供你的团队审议与谈判。

2. 证据分析：把文档与案件思路（case theory）连接起来

任务：分析一份软件项目纠纷中的 40 份文档，找出服务商进度报告之间的矛盾。

GLM-5.3-Flash

外部报告与内部记录

9 月 30 日的客户报告称项目进展顺利、完成度达 60%（BR-000024），而内部快照记录的完成度约为 41%（BR-000027）。内部邮件中还讨论了架构风险以及与客户沟通的指示（BR-000014；BR-000015）。这些文件可能支持客户关于「进度被夸大」的主张。需审查报告历史、开票记录及合同条款，以判断上述陈述是否构成误导，以及还需要哪些进一步证据。

GLM-Legal

外部报告与内部记录

9 月 30 日那份「进展顺利——完成度 60%」的报告（BR-000024），应与 9 月 8 日关于 该里程碑客观上无法达成 的预警（BR-000014），以及内部约为 41% 的快照（BR-000027）放在一起阅读。CEO 关于 压下风险并继续开票 的指示（BR-000015），将上述内部认知与披露决策联系起来。主服务协议（MSA）第 2 条和第 5 条规定 付款不放弃权利、保证义务不因付款而消灭（BR-000001），因此仅凭持续付款本身并不能解决纠纷。这些关联支持一项「隐瞒」（concealment）主张；在得出最终结论之前，应先核对完成度的口径，并对其余请求权要件进行检验。

在项目纠纷中，关键在于把对外的进度报告与服务商内部所掌握的情况对接起来。

GLM-Legal 把外部陈述与相互矛盾的内部记录配对，标注文件来源，并解释其潜在的法律意义。这份「矛盾图谱」能帮助你的团队评估证据，并决定下一步调查方向，同时区分事实与推论。

在 AI Engineer New York 大会上，Anthropic 借鉴 Unix 和 Linux 的经验，阐释智能体如何在不压垮开发者的前提下承接更大规模的项目。

Richard MacManus2026 年 10 月 12 日514 次分享

AI Engineer New York 2026 大会于今早开幕，带来了一系列工作坊，其中 Anthropic 介绍了如何编排其 Claude 托管智能体（Managed Agents）。最引人关注的是一项全新功能——上周五刚刚发布 的动态工作流（dynamic workflows），演讲者反复简称为"flows"。

Flows 被定义为"一种全新的多智能体编排方式，专为最具雄心的负载而打造"。

CJ Avilla 和 Harrison Stall 均是 Anthropic 的技术成员（Members of Technical Staff），他们开篇援引了一些过往的操作系统项目——从 Ken Thompson 构建最初的 Unix 操作系统，到 Linux 由 Linus Torvalds 一人起步演变为多层受信维护者体系。演讲者想传达的启示是：智能体需要同等程度的组织化，才能承接 Anthropic 为动态工作流设想的那种宏大、有野心的项目。

由 Union.ai 赞助

构建主权 AI 工厂

最优秀的工程团队正在构建 AI 工厂，在那里他们不仅拥有并掌控数据、算力与基础设施，还拥有云端持久化的运行时。

Union.ai 让你的工作流具备持久性，能够自适应调整、合理配置基础设施资源，并在不重跑已完成工作的前提下从失败中恢复。

通过 AWS Marketplace 即可开始，并免费试用 Union.ai 30 天。

想了解更多，欢迎莅临 AI Engineer New York 大会的 48 号展位。

"我觉得我们当中很多人，现在在编排和管理大量智能体，可能已经开始感到自己就是瓶颈，就是那个崩塌的临界点——因为有一大堆智能体源源不断地贡献着大量的 PR（Pull Request），"Avilla 说道。"而我们就坐在 GitHub 前，试图审批这些 PR，确保一切都按预期运转。"

从智能体花名册到动态工作流

两位演讲者指出，动态工作流最初以"为每项任务准备一套工具环境（a harness for every task）"的概念在 Claude Code 中诞生。但 flows 的运行时长可以超过单一智能体或花名册的工作周期。其核心理念是：由 Claude 自己决定智能体的组织结构。

"Flows 本质上就是多智能体编排的下一代版本，"Stall 表示，"你可以让 Claude 完全自主地编排整个多智能体拓扑结构。"

其运作机制是这样的：主智能体先制定一份完成任务的计划。随后 Claude 会编写一段编排程序，由它启动智能体、收集结果，并管理信息流。

在此之前，Claude 托管智能体要求开发者自行配置一个协调者和一份子智能体花名册。而借助动态工作流，Claude 自己决定如何拆分与编排工作。

"在多智能体编排的多个不同阶段，它都能完成离散的、可验证的工作单元，而无需你亲自管理这些单元之间的任何衔接，"Stall 说道。

不过 Avilla 也补充道，用户如果愿意，也可以引入自己定义的专家子智能体。

"在智能体配置中也可以传入预先配置好的子智能体，"他说道。

所有这些能力都可以在 Claude Console 中使用——该控制台是开发者通过 API 访问 Claude 时所使用的界面，也是 Claude 托管智能体的核心载体。

随后演讲者演示了一个相对简单的工作流：一支股票关注列表扫描器。虽然这与 Anthropic 真正期望推动的宏大项目相去甚远，但它清晰地展示了基本模式：一个扫描阶段把单只股票分派给拥有各自独立上下文的智能体，随后的审查阶段则检视这些发现并生成报告。

问答环节：预算与自我改进的边界

观众提问环节暴露出了一系列潜在问题。有一位听众问道 Claude 如何决定一项任务需要多少个智能体，以及一次简单的股票扫描是否会触发成百上千个子智能体？

"答案其实就在于评测与较低的默认值，"Stall 回应道，并指出有野心的任务通常需要显式地鼓励更高程度的并行化。

智能体编排中一个长期存在的担忧是对令牌预算（token budget）的掌控。有人提问：主智能体是否知道自己有多少可用资金？

Stall 回答说，模型在运行时并不知道自己的预算，但开发者可以设置会话级别的预算。他还补充道，让模型知道预算反而会让智能体"稍显焦虑"，这句话引来现场一阵笑声。

另一个相关问题是：开发者如何让反复运行的 flows 随着时间推移变得更便宜、更高效？

Avilla 建议除了让 Claude 去审视已发生的开销之外，还可以使用另一项较新的功能：dreaming（梦过程）。官方文档将"dreaming"定义为一个研究预览（research preview）功能。一个 dream 会"读取现有的记忆存储以及过往的会话记录，然后产出一个新的、经过重新组织的记忆存储"——重复条目会被合并，"陈旧或互相矛盾的内容"会被替换，并"提炼出新的洞察"。

Avilla 把流程上下文中的 dreaming 描述为能够"把这些会话相关的记忆存储沉淀下来，并实现本质性的改良"。

针对股票关注列表这个示例，有人问道：这支关注列表 flow 能否自我改进？比如，意识到它所使用的扫描模型不够合适，并自动调整下一次定时运行的配置？

Stall 回答说目前还没有内置这一能力，但他和 Avilla 都建议可以借助爬山算法（hill-climbing）和 dreaming 来改进这一循环。

还有一位听众提问道子智能体行为的可见性问题。

Avilla 回答说当然可以——开发者随时可以通过 Claude Console 内部的图形化功能来检视这一切。

"你能看清主智能体到底向子智能体传递了什么？ 你可以在此查看实际载荷，深入理解整张图中每一次迁移背后究竟发生了什么。"

另一个有意思的问题是：子智能体之间能否彼此通信？

Stall 表示这些智能体会共享一个文件系统

Claude AI 对费城警方说：“我可能有与本案相关的情况。”

Anthropic 公司和费城警方于周五确认：Anthropic 的一款 AI 模型向费城警方提交了一条关于一桩未破凶杀案的虚假线索。

事件发生在 7 月 18 日，一款 Claude 模型向费城警察局的"未破凶杀案信息提交"网站发送了这条虚假线索，但被垃圾信息过滤器拦截。Anthropic 据称在 9 月 28 日发现了这一事件，并于 10 月 8 日通报给了警方。

在内部测试中，Claude Haiku 4.5 被指示去填写各类表单，一直填到最终提交前的最后一步，并在提交前停下。Anthropic 在一份描述"我们在评估和内部使用 Claude 过程中观察到的非预期模型行为"的报告中写道："Claude 多次误将表单直接提交了，因为它以为后面还会有一个确认页面。"

Anthropic 表示，这条虚假的凶案线索发生在 Claude Haiku 4.5 被指示在随机选中的网页上完成任务的过程中：

在某一次运行中，模型进入了一个提及未破凶杀案的页面；该页面包含一张由警察部门管理的线索表单。Claude 收到的指令是不得登录、不得创建账户、不得填写个人数据、不得进行购买，也不得提交任何具有破坏性的内容，但指令并未明确排除表单提交。于是 Claude 用以下内容填写了表单："我可能有与本案相关的情况。我记得在那段时间，在[页面中提到的街道]附近见过一名与描述相符的人。如果这条信息有用，请与我联系。"

Anthropic 表示，公司还发现了 Claude 在州一级和联邦一级机构网站上发生的事件。据报道，在其中一起事件中，Claude 向美国国务院提交了"申根及美国签证申请"相关表单共 20 份。

警方称长达两个月的延迟"不可接受"

Anthropic 确认，这条虚假的凶杀案线索确实发给了费城警察局，而该局就此事向费城的 ABC 电视台发布了一份长篇声明。该条虚假线索的姓名和联系信息栏均为空白。警方称，由于提交线索时生成的电子邮件最终进入了垃圾邮件文件夹，因此该线索未经过任何人工审阅。

警方称："Anthropic 告诉费城警方（PPD），公司在 9 月 28 日发现了这一事件，已终止负责此次提交的自动化测试流程，并为今后的测试新增了一道验证机制。"在 10 月 8 日的通报会之后，警方"在网站的线索记录中找到了这次提交，并确认对应的电子邮件仍处于垃圾邮件中。"

Anthropic 表示，公司是在"技术审查一完成就立即"通报了警方。警方则批评 Anthropic 没有更早发现并上报这条虚假线索。

费城警方声明称："费城市政府高度重视此次事件。该公司必须加强其安全防护，以防止类似事件在市政府不知情的情况下影响到城市系统。从发现到向市政府报告长达两个月的延迟是不可接受的。"

Claude 向美国国务院提交了 20 份签证申请

Anthropic 表示，这条虚假的凶案线索只是多起事件中的一起，涉及“由联邦、州和地方政府机构运营的网站。我们已就这些案例向白宫进行了汇报，并通知了涉及的每一个机构”。

《纽约时报》援引匿名消息源的报道称，Anthropic 的 AI 智能体“通过美国国务院网站上的一份表格提交了 20 份签证申请。所有这些申请都不完整，也未被受理”。

费城警方表示，其常规调查流程“要求在任何线索被分发以供调查跟进之前，必须经过人工审查与甄别……这些 PPD 的安全措施限制了本次事件的影响。但它们并不减轻一个 AI 系统将捏造的信息伪装成来自凶案知情者所带来的严重性”。

Anthropic 表示，公司是在一次对话记录审查工作中发现了这条虚假线索以及其他事件的，该审查工作始于 7 月。也正是在 7 月，Anthropic 披露 Claude 构建并发布了一个恶意的 Python 包，并对其他公司实施了几起攻击。

Anthropic 表示，审查并未发现“任何与我们今年夏天所报告的网络安全事件同等严重的事件”。随后，审查范围扩展到涉及“较低风险”的测试场景，例如影响到费城警方的那一起。

Anthropic 表示：“尽管这些行为的影响很小，并且我们已经对部分高风险与网络安全评估关闭了实时联网访问，但我们现在决定将这一举措扩展到所有内部评估，直至我们确认我们的安全与监控措施……能够可靠地拦截此类行为。”

Anthropic 表示新工具可拦截非预期行为

Anthropic 表示，公司已停止运行部分评估，并将其他评估迁移到离线版本，“或者重建它们，使任务不会触及真实的网站”。公司“更新了部分联网工具的安全护栏，例如网页获取工具，以严格限制模型能够借助它们执行的操作”。

Anthropic 表示，公司还构建了新工具，“用于自动检测并阻止上述行为……当我们针对本帖中所描述的案例进行测试时，它成功拦截了所有这些案例”。

白宫人工智能工作组（其自称“超级智能工作组”）发表声明称，已告知 Anthropic“我们要求其立即向涉及的机构及公众保持完全透明”。

据 Axios 报道，白宫人工智能工作组还要求 Anthropic 必须“立即向受影响的机构以及任何受到伤害的美国人提供补救服务”，并要求所有 AI 公司“必须立即披露涉及其模型的事件，并迅速、果断地采取行动补救任何及所有伤害”。

纳德拉：企业应该像防范内部风险一样防范 AI 模型

微软 CEO 纳德拉（Satya Nadella）的长文。他主张企业把 AI 模型当成“内部风险”来防范，像对待一个权限很大的员工那样，给它设身份、限权限、留记录，并且随时能叫停。

“内部风险”（insider risk）是安全行业的说法，指来自公司内部员工、承包商的风险。这些人手里有权限，可能恶意搞破坏，更常见的是操作失误，或者账号被人盗用。纳德拉认为模型也适用这套逻辑：它未必有恶意，但任何能力够强、又能碰到核心系统的角色，都可能出错或被攻破。

他的出发点是可追溯性。传统软件出了问题，工程师能顺着代码找到是哪一段导致的。大模型做不到这一点，没人说得清某个输出来自哪部分训练数据、哪组参数。可企业已经在让 AI 智能体读取最敏感的数据，替人执行关键操作，模型厂商的保证不能替企业承担责任。

方案可以概括为一句话：把“提供智能”和“管控智能”分开。模型负责干活，但它能访问什么、能做什么，由模型之外的系统决定，模型自己改不了。

这条原则在信息安全领域上世纪 70 年代就有了：程序不能绕过或篡改约束它权限的机制。放到今天，就是把模型、调度模型干活的外层程序、模型能执行的操作范围三者拆开，安全控制放在外面。

他也要求模型的思维链（模型给出答案前写出的推理过程）必须公开，不能拿“模型用人类看不懂的方式思考”当理由藏起来。但光看思维链还不够，因为目前没法保证模型写出来的推理就是它真实的思路。让模型互相检查也有局限：一个看不透的模型，被另一个看不透的模型盯着，等于黑箱套黑箱。

他列了七条原则：

1. 模型多样性：关键结果不能只依赖一个模型，也不能让模型检查自己的活。

2. 全程可观测：模型每个重要操作都要留下防篡改、人能看懂的记录，事后能复现过程，不靠模型自己作证。

3. 可验证：持续测试整个系统，包括失败、攻击、边界情况和系统变更，不能只测成功的任务。

4. 独立控制：企业能自己决定模型能访问什么、能执行什么操作。

5. 独立审计：审核要独立于被审核的模型，同一个模型不能既控制系统行为，又掌握判断这些行为是否合规的证据。

6. 隔离控制：默认模型已经被攻破，从一开始就把它关在边界里。授权的人随时能在任务中途暂停或关掉它，相当于紧急刹车。

7. 事故披露：出了问题要及时告知受影响的人，说明哪道防线失效了、以后怎么避免，并在全行业共享经验，包括那些会改变智能体运行时行为的实现细节。

对正在部署智能体的企业，这几条可以直接拿来对照：模型的权限由谁管，操作日志存在哪，出问题能不能立刻叫停，是不是只押了一家模型。

对开发者来说，权限控制和审计日志要写进智能体外层的程序里，靠提示词约束模型行为是不够的。

微软自己的 Copilot 和 Azure 都接入了 OpenAI、Anthropic 等多家模型，“模型多样性”这条和它的做法一致。

纳德拉最后的总结写挺好：“最值得信任的超级智能系统，是那个让我们可以最不信任模型的系统。”

GitHub 高级开发者布道师（Senior Developer Advocate）

在把 GitHub Copilot 接入真实项目时，很多开发者都会遇到同一个问题：默认情况下，Copilot 只能看到当前打开文件以及同包内相邻的几个文件。它对你的代码库缺乏整体认知，因此给出的补全建议往往显得「只见树木，不见森林」。

本文介绍几种实用做法，帮助 Copilot 真正理解你的整个代码库，从而给出更贴合项目实际情况的建议。

一、为什么 Copilot 理解代码库很重要

代码补全的质量，取决于模型能获得的上下文。上下文越完整，建议越准确。Copilot 的默认上下文窗口有限，如果你不主动提供信息，它只能基于局部文件推测，这容易导致：

• 命名风格不一致
• 重复造轮子，明明项目里已有现成工具函数
• 忽略了项目特有的架构约定

二、把相关文件同时打开

最直接的办法：在 Copilot Workspace 中，把当前任务涉及的所有相关文件都打开，让 Copilot 在补全时自然看到它们。例如：

• 修改一个被多个模块调用的工具函数时，打开它的全部调用方
• 新增一个服务层文件时，打开同目录下的姊妹文件
• 调试接口时，打开路由定义、控制器、数据模型三件套

打开的文件越多，Copilot 抓取的上下文就越丰富，建议质量随之提升。

三、为 Copilot 提供项目说明（Copilot Instructions）

在仓库根目录添加一份 .github/copilot-instructions.md，描述项目的技术栈、目录结构、命名约定、重要架构决策等。Copilot 在生成补全时会参考这份说明，从而给出更一致、更符合本项目风格的建议。

例如：

# 项目说明

## 技术栈

## 命名约定

## 目录结构

四、使用 #codebase 引用整个仓库

在 Copilot Chat 中，使用 #codebase 关键字可以让 Copilot 把整个代码库纳入上下文，从而基于全局信息回答问题或生成建议。适合用来：

五、使用自定义命令（Custom Instructions / Slash Commands）

为了让 Copilot 的输出更贴合团队习惯，可以为常见任务定义自定义指令，例如：

• 「生成单测」：要求使用项目既有的测试框架与目录结构
• 「写文档」：要求按既定模板输出，包含必需章节
• 「重构」：要求保留对外 API，向内做实现替换

这些指令既可以写在 copilot-instructions.md 里，也可以做成独立的 slash 命令文件。

六、结合 Chat 提问与补全

不要把 Copilot 只当作补全工具。主动在 Copilot Chat 里向它提问，让它先理解上下文，再去补全：

1. 先粘贴或引用关键代码片段
2. 用自然语言描述你想完成的事情
3. 让 Copilot 先复述它理解的上下文，再请求补全或重构

这种「先沟通、后补全」的方式能显著减少返工。

七、避免上下文污染

提供更多信息并不等于越多越好。如果把无关文件都打开，或者说明文档里堆满了与当前任务无关的历史信息，反而会稀释有效上下文。建议：

• 每完成一个任务就关闭不再需要的标签页
• 定期整理 copilot-instructions.md，只保留对当前开发有指导意义的内容
• 为不同子项目或模块维护各自的说明，避免相互干扰

八、检验效果：让 Copilot 解释自己的答案

拿到建议后，可以让 Copilot 反向解释：「请说明你为什么这样写？」如果它给出的理由与项目实际架构一致，说明上下文传递是有效的；如果理由含糊或明显不符合项目情况，就该回头检查上面几步。

九、小结

让 GitHub Copilot 真正理解你的代码库，并不需要什么高深技巧，核心就是：给它足够、相关、整洁的上下文。从打开相关文件、编写项目说明、合理使用 #codebase 与自定义指令这几件事做起，Copilot 的建议质量就会有明显提升。