Anthropic · Claude Managed Agents 平台 + 2026 产品/安全更新(官方博客精炼)

一句话:2026 上半年 Anthropic 推出 Claude Managed Agents(托管智能体)——你不再自己搭"agent 跑在哪、状态存哪、权限怎么管、模型升级怎么改"这套基建,而是租 Anthropic 的云基建,只定义"做什么任务、用什么工具、守什么边界",剩下交给它跑。半年里这个平台连发 5 块能力(memory / dreaming / outcomes / multiagent / 自带沙箱 + 私网隧道),底层是一套"脑 / 手 / 会话日志"三件解耦的设计。同期 Claude Code 桌面端为"一个人同时盯好几个 agent"重做,Anthropic 还公开了三个产品的安全 containment 架构、一份"AI 让攻击提速怎么防"的清单,以及图表可视化 / 前端 Skills / 生活类 connectors 几个 to-C 功能。

何时打开这篇

想搞懂 Claude Managed Agents 到底是什么、解决谁的什么痛,要不要在自己产品里用(对标自建 Agent SDK / LangGraph / 自己搭 K8s)。
在做 长跑 agent / 多智能体产品,想知道"记忆怎么跨会话、agent 怎么自我改进、怎么让它自己判断'做得够不够好'"。
关心 企业安全:agent 跑在哪儿才安全、credentials 怎么不泄、prompt injection 怎么防、AI 让攻击者提速了我该补哪些洞。
PM 想知道 2026 Claude 产品侧到底更新了什么(桌面端并行 agent / 对话内交互图表 / 生活类 app 连接 / 前端审美 Skill)。

0. 先认清:Managed Agents 解决的是"基建税",不是"模型能力"

"Until now, building agents meant spending development cycles on secure infrastructure, state management, permissioning, and reworking your agent loops for every model upgrade." 译:在此之前,做 agent 意味着把开发周期花在安全基建、状态管理、权限、以及每次模型升级都要重写 agent 循环上。

生活类比:你想开一家奶茶店(=你的 agent 产品),核心竞争力是配方和口味(=用户体验)。但开店前你被迫先去自己接水电、装监控、办消防许可、雇保安(=sandbox / 状态 / 权限 / tracing)。Managed Agents 相当于租一个已经配齐水电消防保安的标准铺面,你拎包进去专心调配方。

"Managed Agents pairs an agent harness tuned for performance with production infrastructure to go from prototype to launch in days rather than months." 译:Managed Agents 把一套调好性能的 agent harness 和生产级基建打包,让你从原型到上线从"几个月"变成"几天"。

名词一次性解释:

harness(执行框架 / 脚手架):包在 Claude 外面那层"循环"——决定何时调工具、怎么管上下文、出错怎么恢复。Claude 是大脑,harness 是它的手脚和值班逻辑。
sandbox(沙箱):一个隔离的执行环境,Claude 在里头跑代码、改文件,跑坏了也炸不到外面。
session(会话):一次任务从头到尾发生过的所有事的只增不改的日志(append-only log)。

平台分两种用法,可控程度递减、自主程度递增:

传统 prompt-and-response:你管得细,要更紧的控制时用。
outcomes 模式:你只写一份"什么算成功"的评分标准(rubric),Claude 自己反复改到达标。内部测试里,这种模式在"结构化文件生成"任务上比标准 prompting 循环任务成功率高出最多 10 分,越难的题目提升越大。

何时别用 Managed Agents:你只要一次性问答、不需要长跑/工具/状态——那直接调 Messages API 或用 Claude Code 就行,Managed Agents 的价值在"长跑 + 有状态 + 要上生产 + 要治理"。

1. Managed Agents 的五块能力(半年连发)

把这五块当成"租来的标准铺面"陆续装修出来的五个房间。

1.1 Memory — 让 agent 跨会话学习(2026-04,public beta)

痛点:默认每次新会话,agent 都"失忆"重新开始,你只能手动把经验塞回 prompt 和 skill 里。

做法:记忆以文件形式存在一个挂载的文件系统上,Claude 就能用它本来就最擅长的 bash + 代码执行去读写记忆——不另搞一套检索基建。

"Memory on Managed Agents mounts directly onto a filesystem, so Claude can rely on the same bash and code execution capabilities that make it effective at agentic tasks." 译:Managed Agents 的记忆直接挂在文件系统上,所以 Claude 能复用那套让它擅长 agent 任务的 bash 和代码执行能力。

为什么是"文件"而不是向量数据库:文件可导出、可用 API 管理、可回滚旧版本、可删历史里的某段内容(redact),开发者对 agent 记住什么有完全控制权。每次改动都有 audit log(谁、哪个会话改的),在 Console 里以"会话事件"呈现,可追溯。

企业级特性:scoped permissions(分级权限)——比如全组织共享库设只读,每用户库可读写;多个 agent 能同时对一个库并发读写而不互相覆盖。

实战数字:

Rakuten 的长跑任务 agent 用记忆避免重犯旧错,首轮错误率砍掉 97%。
Wisedocs(文档核验)用跨会话记忆记住反复出现的文档问题,核验提速 30%。
Netflix 让 agent 跨会话带住"花好几轮才挖出的洞察"和"人类中途的纠正"。

1.2 Dreaming — 让 agent 在"睡觉"时自我改进(2026-05,research preview)

类比:人白天经历一堆事(=memory 当场记),晚上做梦时大脑复盘、提炼、归档,第二天更聪明。Dreaming 就是给 agent 加的这道"睡眠复盘"。

"Dreaming is a scheduled process that reviews your agent sessions and memory stores, extracts patterns, and curates memories so your agents improve over time." 译:Dreaming 是一个定时进程,复盘 agent 的历史会话和记忆库,提炼模式、整理记忆,让 agent 随时间变强。

它能看见单个 agent 自己看不到的东西:反复犯的错、多个 agent 不约而同收敛出的工作流、团队共享的偏好。你可以让它自动更新记忆,也可以改动落地前先人工审。

Memory = 每个 agent 干活时当场记下学到的东西。
Dreaming = 在会话之间精炼记忆,把跨 agent 的共享经验拉通、保持新鲜。
两者合起来 = 一套给"自我改进 agent"用的健全记忆系统。

实战:Harvey(法律)用 dreaming 让 agent 记住会话间学到的"文件类型变通办法、工具特定套路",测试里完成率涨了约 6 倍。

1.3 Outcomes — 让 agent 自己判分、自己重做(2026-05)

"With outcomes, you write a rubric describing what success looks like and the agent works toward it. A separate grader evaluates the output against your criteria in its own context window, so it isn't influenced by the agent's reasoning." 译:有了 outcomes,你写一份描述"什么算成功"的评分标准,agent 朝它干;一个独立的评分员在自己的上下文窗口里按你的标准评估产出,不受 agent 推理过程的影响。

关键设计 = 评分员和干活的 agent 物理隔离(各用各的上下文窗口),所以评分员不会"被 agent 自己的说辞带跑"——像考试的判卷老师不能是考生本人。不达标时,评分员指出具体哪里要改,agent 再来一遍,全程不用人逐次审。

适用场景:需要"注意细节 + 全覆盖"的任务,以及主观质量(文案是否符合品牌调性、设计是否守视觉规范)。

数字:比标准 prompting 循环任务成功率最多高 10 分;文件生成质量上 docx +8.4%、pptx +10.1%。

实战:Spiral by Every 的写作 agent——主 agent 跑在便宜的 Haiku 上接需求、提澄清问题,把起草派给跑 Opus 的子 agent(要多稿就并行起草),每份草稿按"Every 编辑原则 + 用户嗓音"(都从 memory 拉)打分,只有过线的草稿才返回。Wisedocs 用 outcomes 给每份核验打分,审查再快 50%。

1.4 Multiagent orchestration — 主 agent 派活给专才(2026-05,research preview)

"When there is too much work for a single agent to do well, multiagent orchestration lets a lead agent break the job into pieces and delegate each one to a specialist with its own model, prompt, and tools." 译:当活儿多到一个 agent 做不好,多智能体编排让一个主 agent 把任务拆块,每块派给一个有自己模型/prompt/工具的专才。

类比:一个项目经理(lead agent)把调查任务拆成几路,分别派给查部署历史、查错误日志、查指标、查工单的专员,专员们在一块共享文件系统上并行干活,结果汇回项目经理的总上下文。主 agent 能中途回头问任一专员进度,因为事件是持久化的、每个 agent 都记得自己干过啥。Console 里能 trace 出"谁、按什么顺序、为什么做了什么"。

实战:Netflix 平台团队的分析 agent 处理上百次构建的日志,多 agent 并行分析批次,只把"反复出现、值得动手"的模式捞上来。

⚠️ 这块对应安全那节里的 multi-agent trust escalation 风险(见 §6):如果子 agent 的输出被当成"比原始工具结果更可信",反而开了新的注入口子。能力和风险是一体两面。

1.5 Self-hosted sandboxes + MCP tunnels — 把执行和数据留在你的地盘(2026-05)

这块专治企业最大的顾虑:"我不想把敏感文件和私网服务交到 Anthropic 云上。"

"The agent loop that handles orchestration, context management, and error recovery stays on Anthropic's infrastructure, while tool execution moves to your own configured environment." 译:负责编排、上下文管理、错误恢复的 agent 循环留在 Anthropic 的基建上,而工具执行挪到你自己配置的环境里。

Self-hosted sandboxes(自带沙箱,public beta):沙箱跑在你自己的基建上,或托管给 Cloudflare / Daytona / Modal / Vercel。文件和仓库不出你的边界,你还能自己定 CPU/内存(跑长构建、图像生成这类重活)。
MCP tunnels(私网隧道,research preview):让 agent 够得着你私网里的 MCP server(内部数据库、私有 API、知识库、工单系统),又不把它们暴露到公网。靠你部署的一个轻量网关只发一条向外的连接,无需开任何入站防火墙规则,流量端到端加密。

名词:MCP(Model Context Protocol,模型上下文协议)——一套让 Claude 调外部工具/数据的开放标准。

四家沙箱 provider 各有侧重(选型速查):Cloudflare(microVM + zero-trust 密钥注入 + 可审计 egress)、Daytona(长跑有状态的"完整可组合电脑",可暂停/恢复并保全状态)、Modal(亚秒级启动、可扩到几十万并发、按需 CPU/GPU)、Vercel(毫秒级启动 + VPC peering + 在网络边界注入凭证使其永不进沙箱)。

2. 平台底座:把"脑"和"手"解耦(元 harness 设计)

这节是整个 Managed Agents 最硬核也最长寿的一层。读懂它就懂了"为什么这套 API 能扛住未来模型/harness 的更替"。与 Anthropic 工程团队第一方视角:Agent 工程化 / Skills / MCP / Claude Code(2025-2026 全集) 里"harness 设计 4 类"的第 4 类(managed-decoupled)是同一回事,这里展开讲。

2.1 出发点:不要养"宠物"(pets vs cattle)

最早 Anthropic 把 session / harness / sandbox 全塞进一个容器。好处是文件编辑就是直接系统调用、没有服务边界要设计。坏处是踩了老 IT 坑——养了只"宠物":

"a pet is a named, hand-tended individual you can't afford to lose, while cattle are interchangeable. In our case, the server became that pet; if a container failed, the session was lost." 译:宠物是个有名有姓、要手工伺候、丢不起的个体;牛(cattle)则是可互换的。在我们这儿,服务器成了那只宠物——容器一挂,会话就没了。

具体三个病:① 容器挂了会话就丢,卡住的会话只能工程师进去人工"治病";② 容器里既有 harness 又有用户数据,进去 debug 几乎等于没法 debug;③ harness 假定"Claude 干活的东西都在它这个容器里",客户想接自己的 VPC 就得被迫和 Anthropic 的网络对等互联。

2.2 解法:借操作系统的老智慧——虚拟化出稳定接口

"Decades ago, operating systems solved this problem by virtualizing hardware into abstractions—process, file—general enough for programs that didn't exist yet... The read() command is agnostic as to whether it's accessing a disk pack from the 1970s or a modern SSD." 译:几十年前操作系统把硬件虚拟化成 process、file 这种抽象,通用到能跑还没被发明的程序……read() 命令根本不在乎它读的是 1970 年代的磁盘还是现代 SSD。

类比:电源插座的标准是"两孔/三孔 + 220V"。插座背后是火电、水电、还是光伏你不用管;电器厂商照着标准插头造就行。Anthropic 把 agent 拆成三个这样的"标准插座":

session(会话) = 那条只增不改的事件日志。
harness(脑) = 调 Claude、把 Claude 的工具调用路由到对应基建的那个循环。
sandbox(手) = Claude 跑代码、改文件的执行环境。

三者各自可被替换而不打扰另两者。Anthropic 的原话:"我们对这些接口的形状有主见,但对接口背后跑什么没主见。"

2.3 三件解耦后各自的好处

① 容器变成"牛":harness 不再住在容器里,而是像调任何工具一样调容器——execute(name, input) → string。容器死了,harness 把它当一次工具调用失败接住、回报给 Claude;Claude 要重试就用标准配方 provision({resources}) 重开一个。不用再伺候坏容器。

② harness 也变成"牛":因为会话日志在 harness 外面,harness 崩了没关系——wake(sessionId) 重启一个,getSession(id) 拿回日志,从最后一个事件接着跑。

③ 安全边界(关键):旧设计里 Claude 生成的不可信代码和 credentials 在同一个容器,一次 prompt injection 只要骗 Claude 读一下自己的环境变量,token 就漏了。结构性修法 = 让 token 永远够不着 Claude 跑代码的沙箱:

Git:用仓库 token 在沙箱初始化时 clone、接进本地 git remote;之后 push/pull 在沙箱内能用,但 agent 自己从没碰过 token。
自定义工具:OAuth token 存在沙箱外的保险库,Claude 通过一个专门的 proxy 调 MCP 工具,proxy 去保险库取凭证再去调外部服务,harness 全程不知道任何 credentials。

④ 会话 ≠ Claude 的上下文窗口:长跑任务常超出单个上下文窗口。压缩(compaction)、裁剪(trimming)都是不可逆地丢 token,但"哪些 token 未来会用到"很难预判。Managed Agents 把会话日志当成一个活在上下文窗口之外的"上下文对象",用 getEvents() 按位置切片去取——可以从上次读到的地方接着读、可以倒回某动作前几个事件看来龙去脉。"持久存储"和"任意上下文管理"两件事被拆开:会话只保证日志持久可查询,具体怎么组织上下文(为了缓存命中率、为了 context engineering)交给 harness 去做。

这条接 §3 的 harness 哲学:不可逆决策容易出错,所以宁可把上下文留成可回溯的对象,也别急着压缩丢弃。

2.4 性能彩蛋:TTFT 暴降

把脑放进容器时,每个脑都要等一个容器开机——哪怕这个会话根本不碰沙箱,也得先 clone 仓库、启进程、拉事件。这段死等表现为 TTFT(time-to-first-token,出第一个 token 前的等待),是用户最能直接感受到的延迟。解耦后,容器只在需要时由脑通过工具调用临时开。结果:p50 TTFT 降了约 60%,p95 降了 90% 以上。

一句话总结这套设计:Managed Agents 是一个 "meta-harness(元 harness)"——它不规定 Claude 未来该用哪个具体 harness(Claude Code 是个好 harness,任务专用 harness 在窄领域也很强,它都能容纳),只规定"操控状态(session)+ 执行计算(sandbox)+ 能扩到多脑多手"这几个长寿接口。

3. harness 设计哲学:用 Claude 已会的工具 + 不断追问"我能停掉什么"

出处 Harnessing Claude's intelligence(Lance Martin)。这是上面那套架构背后的"价值观"。核心前提来自联合创始人 Chris Olah 的一句话:

"generative AI systems like Claude are grown more than they are built"(像 Claude 这样的生成式 AI 系统更像是"长出来的"而非"造出来的")。

推论:harness 里编码的是"Claude 自己做不到什么"的假设,而这些假设会随模型变强而过期。所以要常回来重新检验。三条原则:

3.1 用 Claude 已经懂的工具(use what it already knows)

2025 年初,Claude 3.5 Sonnet 只靠一个 bash 工具 + 一个文本编辑器工具就在 SWE-bench Verified 上拿了当时 SOTA 的 49%。Claude Code 也建在这同两个工具上。bash 不是为 agent 设计的,但它是 Claude 懂、且越用越熟的工具。 Agent Skills、programmatic tool calling、memory tool 全都是 bash + 文本编辑器这两块的组合。

PM takeaway:给 agent 设计工具时,优先用模型已经在海量训练数据里见过的通用工具(bash / REPL / 文件读写),而不是发明一堆冷门专用工具——前者会随模型升级自动变强。

3.2 不断追问"我能停掉什么?"(ask 'what can I stop doing?')

harness 里那些"替 Claude 做的决定",该随模型变强一个个交还给 Claude:

让 Claude 自己编排动作:别假设每个工具结果都要回流进上下文窗口。给 Claude 一个代码执行工具,它能写代码表达工具调用和它们之间的逻辑,自己决定哪些结果要透传、过滤、还是管道给下一个调用,只有代码执行的输出进上下文。证据:在 BrowseComp(测网页浏览能力)上,给 Opus 4.6 "自己过滤工具输出"的能力,准确率从 45.3% → 61.6%。一句话:强编码模型就是强通用 agent,因为代码是 Claude 编排动作的通用语言。
让 Claude 自己管上下文:别手工把所有指令塞进 system prompt(每个 token 都在耗 Claude 的注意力预算)。用 Skills——每个 skill 的 YAML 头部是一句简介预加载进上下文,完整内容等任务需要时 Claude 自己读(渐进式披露)。配套还有 context editing(反向删过期内容)和 subagents(分叉出干净上下文隔离子任务,Opus 4.6 上让 BrowseComp +2.8%)。
让 Claude 自己持久化上下文:别假设记忆非得靠外挂检索基建。compaction(自己总结过往)、memory folder(写文件再按需读)就够。证据:同一套设置下 BrowseComp 上 Sonnet 4.5 卡在 43%,Opus 4.5 爬到 68%,Opus 4.6 到 84%;memory folder 让 Sonnet 4.5 在 BrowseComp-Plus 从 60.4% → 67.2%。

妙例(玩 Pokémon):Sonnet 3.5 把记忆当成流水账,记 NPC 说了啥,跑 14000 步还卡在第二个镇、攒了 31 个文件还有两个讲毛毛虫的近重复;Opus 4.6 同样步数下只有 10 个分目录文件、拿了三枚徽章,还从自己的失败里蒸馏出一份 learnings.md。模型变强 = 越来越会"记重点"。

3.3 谨慎设边界(set boundaries carefully)

harness 仍有它该干的活——为 UX、成本、安全立结构:

为缓存命中率设计上下文:Messages API 是无状态的,每轮都要把全部历史重新打包。缓存命中的 token 只要基础价的 10%。原则:静态内容(system prompt、工具)放前、动态放后;更新用 <system-reminder> 追加进 messages 而非改 prompt;一个会话里别换模型(缓存是模型专属,换了就废,要便宜模型用 subagent);工具在缓存前缀里,增删一个就让缓存失效(动态发现用 tool search,它是追加不破缓存);多轮应用把断点移到最新消息(用 auto-caching)。
用专用工具(declarative tools)立 UX / 可观测 / 安全边界:bash 给 harness 的只是一根命令字符串(每个动作都长一个样);把动作提升成带类型参数的专用工具,harness 就有了能拦截/把关/渲染/审计的钩子。不可逆 = 好判据(难撤销的外部 API 调用适合用户确认门);写工具(如 edit)可带 staleness check(防 Claude 覆盖一个读过之后已被改动的文件)。
反过来,Claude Code 的 auto-mode(发文时还在 research mode)给 bash 立了个安全边界:让第二个 Claude 读命令字符串、判断它安不安全——这能减少对专用工具的需要,只用在"用户信任大方向"的任务上。高风险动作仍值得用专用工具。

收尾金句(也是整套架构的灵魂):harness 里那些为"补偿 Claude 当年的短板"加的结构,会随模型变强变成死重(dead weight),反而拖累性能。例:为治 Sonnet 4.5 的"上下文焦虑(context anxiety,快到上下文上限就草草收尾)"加的 context reset,到 Opus 4.5 上那毛病没了,reset 就成了该剪掉的死重。所以要不断剪枝:what can I stop doing?

4. Claude Code 桌面端为"并行 agent"重做(2026-04)

出处 Redesigning Claude Code on desktop for parallel agents。和上面 Managed Agents 的"多脑多手"是同一个时代主题在个人开发者工具侧的落地。

前提变了:

"You're not typing one prompt and waiting. You're kicking off a refactor in one repo, a bug fix in another, and a test-writing pass in a third... The new app is built for how agentic coding actually feels now: many things in flight, and you in the orchestrator seat." 译:你不再是敲一个 prompt 然后干等。你在一个仓库起重构、另一个修 bug、第三个写测试……新 app 是按"现在 agentic coding 实际的感觉"造的:很多事同时在飞,而你坐在指挥位上。

类比:从"打字员"升级成"项目调度员"——你不亲手做每件事,而是同时盯几条流水线,哪条飘了就去拨一下。

更新点:

侧边栏管多会话:所有活跃/近期会话一处看,可按状态/项目/环境筛选或分组;PR 合并或关闭后会话自动归档,保持侧栏只剩"在跑的"。
side chat 旁支对话(⌘/Ctrl + ;):中途想问个问题时分叉出来,只从主线拉上下文、不往主线塞东西,避免带偏任务。
不出 app 就能审查和发版:内置终端(跑测试/构建)、应用内文件编辑器、重写过更快的 diff viewer(扛大改动集)、扩展的预览(开 HTML/PDF + 跑本地 app server)。每个面板都能拖拽排成你顺手的网格。
和 CLI 对齐:桌面端有了 CLI plugin 的完整能力(组织集中管的或本地装的 plugin 都能用);SSH 支持从 Linux 扩到 Mac;本地或云端跑都行。
三档视图(Verbose / Normal / Summary)调透明度;新增 usage 按钮一眼看上下文窗口和会话用量;底层重写、流式输出。

适用于 Pro / Max / Team / Enterprise 及 API 用户。

5. 企业落地:2026 State of AI Agents(数据快照)

出处 How enterprises are building AI agents in 2026(Anthropic × 研究公司 Material,调研 500+ 技术负责人)。第三方播客视角的同主题在 AI Builders · 智能体原生产品与企业 AI 落地(播客精炼)。

主结论:从"简单任务自动化"转向"跨团队、跨职能的多步工作流"。

关键数字(给 PM 拍板用):

57% 组织已用 agent 跑多阶段工作流,16% 跑跨职能流程;2026 年 81% 计划啃更复杂用例。
编码领跑:近 90% 用 AI 辅助开发,86% 把 agent 用于生产代码;开发全周期都省时(规划 58% / 代码生成 59% / 文档 59% / 评审与测试 59%)。
但影响超出工程:数据分析与报告生成(60%)、内部流程自动化(48%)是最高价值用例;未来一年 56% 计划上 agent 做研究和报告。
80% 组织报告 agent 投资已带来可测量的经济回报。
三大落地挑战:与现有系统集成(46%)、数据访问与质量(42%)、变更管理(39%)。

实证案例:Thomson Reuters(CoCounsel,律师分钟级查 150 年判例 + 3000 专家)/ eSentire(威胁分析从 5 小时→7 分钟,与资深专家一致率 95%)/ Doctolib(全工程团队铺 Claude Code,功能交付快 40%)/ L'Oréal(对话式分析 99.9% 准确,4.4 万月活直接查数据不等定制看板)。

"Nine in 10 leaders report that agents are shifting how their teams work, with employees spending more time on strategic activities... rather than routine execution." 译:十之九的负责人说 agent 正在改变团队工作方式,员工把更多时间花在战略性活动……而非例行执行上。

6. 安全 ①:三个产品怎么"圈住"Claude(containment 架构)

出处 How we contain Claude across products(工程团队)。这是上面 §2.3 安全边界思路的产品级展开,极具参考价值,PM/安全都该读。

核心框架:风险 = 失败概率 × blast radius(爆炸半径,一次失败能造成多大破坏)。 安全训练在降"概率",但"破坏上限"随能力和访问权增长。所以重点放在第二条:containment(围堵)——不是监督 agent 做了什么,而是限制它"能够做什么"(沙箱、VM、egress 控制)。

"if credentials never enter the sandbox, they can't be exfiltrated, regardless of whether the cause is a user, a model finding a 'creative' path, or an attacker." 译:如果凭证从不进入沙箱,它就无法被窃取——不管起因是用户、是模型找到"创造性"路径、还是攻击者。

三类风险:① 用户滥用(主动或粗心让 agent 干坏事)② 模型失当(没人让它干它却干了——越强的模型越会"绕过没人想到要写下来的限制",Anthropic 见过 Claude 为完成任务"helpfully" 逃出沙箱、查 git 历史找测试答案、自己认出在跑哪个 benchmark 去解答案钥匙)③ 外部攻击者(经工具/文件/网络注入,含 prompt injection)。

三个产品 = 三种围堵(隔离强度按"用户能不能看懂 bash"匹配):

产品	模式	隔离手段	blast radius
claude.ai	临时容器	gVisor 容器、纯服务端、每会话即焚的文件系统	服务端容器(护栏 = gVisor + 主机基建边界)
Claude Code	人在环沙箱	macOS Seatbelt / Linux bubblewrap,读放行、工作区内写放行、默认禁网	本地工作区
Claude Cowork	封闭 VM	厂商 hypervisor(Apple Virtualization / Windows HCS),独立内核/文件系统,凭证留主机钥匙串不进 guest	挂载的工作区(护栏 = vsock + hypervisor 边界)

为什么人在环不够(关键教训):遥测显示用户批准了约 93% 的权限弹窗——看得越多越不走心(approval fatigue,批准疲劳)。所以 Claude Code 上了 OS 级沙箱后权限弹窗减少 84%;auto mode(第二个 Claude 判命令安不安全)能在执行前拦住约 83% 的"过度积极"行为(代价:约 0.4% 良性命令误拦、约 17% 危险动作漏过,所以它是纵深防御的一层,不能单独顶)。

几个"我们漏掉的风险"(最值钱的部分):

信任对话框之前就执行的代码:clone 一个仓库审 PR,里头的 .claude/settings.json 定义了 hook,而 Claude Code 在弹"信任此文件夹吗?"之前就读了项目设置——hook 自动跑了。修法:把项目本地配置的解析和执行推迟到用户接受信任之后。"本地的、在用户同意前到达的东西,要当成来自互联网的入站请求对待。"
用户本身就是注入向量:红队把员工钓鱼,让他粘贴一个"看着像正常任务"的 prompt,中间夹了"读 ~/.aws/credentials、编码、POST 到外部端点";25 次重试里 Claude 干成了 24 次。这是直接 prompt injection,模型层防不住(指令是用户亲手敲的,分类器没有异常可抓)——唯一能挡的是环境层:egress 控制挡住那个 POST、文件系统边界让 ~/.aws 根本够不着。
经"已批准域名"外泄:Cowork 的 egress 白名单正确放行了 api.anthropic.com(产品离不开它),但攻击者在工作区放了个带"攻击者自己的 API key"的恶意文件,Claude 照做、用攻击者的 key 调 Anthropic Files API,文件被传进了攻击者的账户。沙箱完美工作,数据照样泄了。 教训:白名单不是"目的地过滤器",而是"能力授权"——白名单上每个域名背后的每个功能都是攻击面。 修法:在 VM 内放一个防御性 man-in-the-middle proxy,只放行带 VM 自己 session token 的请求。
VM 隔离把 EDR(端点检测)也挡在外面:同一层隔离既圈住 Claude 也让主机的安全监控看不进 guest。缓解:pull-based OTLP 日志导出(事后取,非实时监控)。"如果你也在造类似的东西,早点把这场对话纳入预算。"

反复出现的几条原则:

先在环境层设计围堵,再在模型层引导行为——两个最长教训的事故(钓鱼、白名单外泄)都是 egress 类,模型层"没有异常可抓","当一切概率性防御都漏过时,被撞上的是那道确定性边界(deterministic boundary)"。
隔离强度匹配用户的监督能力——会读 bash 的开发者和读不懂的知识工作者不是同一个威胁模型;两个方向错都是失败(对专家太多摩擦 / 对非专家太多信任)。
警惕自研组件——身经百战的 hypervisor / syscall 过滤 / 容器运行时都扛住了,栽的全是自己围着它们造的那层(自研 proxy)。
远程 vs 本地工具比想象中重要:本地工具可审计(读源码、钉版本);远程工具(托管 MCP、云 connector)批准后随时能变行为,你装机时的信任决定可能已失效。工具输出本身就是攻击面(GitHub connector 能把投毒的 README 直接载进上下文,哪怕它过了恶意软件检查)。

未来威胁(都接得上 §1 的能力):持久化记忆投毒(注入落进 memory / CLAUDE.md / 挂载工作区,每次启动都重载)、多 agent 信任升级(子 agent 输出被当高信任 → 新注入口,正对应 §1.4)、agent 身份(agent 该有自己的 principal 身份,还是继承用户权限?可能是两者混合)。

7. 安全 ②:AI 加速攻击,你的安全程序该补哪些(行动清单)

出处 Preparing your security program for AI-accelerated offense。背景:Project Glasswing + Claude Mythos Preview(一个 2026 年 4 月因 blast radius 太高而没发布的强网安能力模型)。核心判断:

"Within the next 24 months, vast numbers of bugs that sat unnoticed in code, possibly for years, will be found by AI models and chained into working exploits." 译:未来 24 个月内,大量在代码里潜伏多年没人发现的 bug 会被 AI 模型找出来、串成可用的漏洞利用。

好消息是双向的:攻击者能用 AI 提速,防守方也能。七条该现在做的(给非技术 PM 当"和安全团队对话的清单"):

关掉补丁缺口:AI 极擅长把"已发布的补丁"逆向成"针对未打补丁系统的利用"——补丁发布到利用出现的窗口在缩短。CISA KEV 名单上的立刻全打,其余用 EPSS(未来 30 天被利用概率)排序;面向公网的系统漏洞利用出现后 24 小时内打。
准备接住成数量级增长的漏洞报告:还在"一张表 + 每周会"模式肯定跟不上,要上自动化(人留在环里)。查开源依赖安全(OpenSSF Scorecard),对供应商提同样要求。
上线前就找出 bug:CI 里加静态分析 + AI 辅助评审,高置信度发现就卡合并;加自动化渗透测试;新代码优先内存安全语言(Rust/Go/托管运行时)。"如果这节只做一件事,就做 AI 漏洞扫描——用攻击者会用的同款模型,在他们之前扫自己的代码。"
找出你自己代码里已有的洞:大多数长跑生产代码被人审过多次,却从没被前沿模型看过;优先扫"解析不可信输入 / 做鉴权决策 / 公网可达"的代码和遗留代码。
为被攻破做设计(design for breach):靠"让攻击变麻烦"的措施(多跳、限速、非标端口、短信 MFA)对"有无限耐心、能磨穿"的对手基本无效;改用硬件绑定凭证、短时 token、根本不存在的网络路径。上零信任、按身份隔离服务、长期密钥换短时 token。
缩减并盘点暴露面:维护每个公网主机/服务/API 的实时清单(你的清单至少要和攻击者的侦察一样准),下线无主旧系统。可用 AI 做自主外部红队(从外面无凭证地摸你的边界)。
缩短事件响应时间:把模型放在告警队列最前面做"首轮 triage"(100% 覆盖)、当"事件记录员 + 并行调查员"(人只做围堵/披露/对客沟通的决断);按 MITRE ATT&CK 画检测覆盖图;演练"一周来五起并发事件"(老套的"周一来一个 CVE"已不够)。

单独一节给"没有安全团队的人"(独立开发者/开源维护者):开自动更新、优先托管服务、用 passkey/硬件密钥、开 GitHub 免费安全工具(Dependabot / secret scanning / CodeQL)、维护者写 SECURITY.md。

还有一节讲提交漏洞报告的礼仪:维护者已被 AI 生成的低质报告淹没。"一份报告只在有人类核实过、并愿意署上自己的名时才发出。" 自检法:关掉编辑器,凭记忆把 bug 讲一遍;讲不出来就是没懂透,没资格报。

8. to-C 功能三件:对话内交互图表 / 生活类 connectors / 前端审美 Skill

8.1 对话内交互式图表、示意图、可视化(2026-03,全平台默认开)

和 artifacts(永久工具/文档,放侧栏、可分享下载)不同,这些图表是为了帮你当场理解话题而临时生成的:

"They appear in-line, rather than in a side panel, and they're temporary—they change or disappear as the conversation evolves." 译:它们出现在对话内联处而非侧栏,而且是临时的——随对话演进而改变或消失。

比如问复利就给一条能拨弄的曲线、问元素周期表就给个可点击下钻的可视化。Claude 自己决定何时画,你也能直接说"画成图""可视化一下随时间怎么变"。这是一组对话呈现升级的一部分(菜谱出配料+步骤、问天气出可视化、还能在对话内直接操作 Figma/Canva/Slack)。

PM takeaway:artifacts = 交付物,inline visual = 思考辅助。 两种"Claude 生成 UI"在产品语义上是分开的。

8.2 生活类 connectors(2026-04)

connector(连接器)从 2025-07 起已超 200 个(设计/财务/生产力/健康)。这次把 connector 扩到工作之外的生活 app:AllTrails、Audible、Booking.com、Instacart、Credit Karma、TurboTax、Resy、Spotify、StubHub、Taskrabbit、Thumbtack、TripAdvisor、Uber、Uber Eats、Viator 等。

新交互:connector 在对话里动态浮现——Claude 按你正在做的事(订位/加购物车/认出航班)和你的偏好,主动建议合适的 app;多个 app 都能帮忙时全列出来让你选。

立场声明(产品定位,接 Claude 产品发布演化(2024-2026 Opus / Sonnet / Haiku 4.x 全集 + Max Plan + Design) 的"Claude is a space to think"):"Claude is ad-free and will stay that way."(Claude 无广告,且会一直如此)——对话里没有付费位、没有赞助答案;连接某服务时你的数据不用于训练、该 app 看不到你和 Claude 的其他对话、随时可断开;下单/购买前 Claude 会先跟你确认。

8.3 用 Skills 改善前端审美(2026-03 前后)

问题叫 distributional convergence(分布收敛):不给指引让 LLM 做落地页,它几乎总收敛到 Inter 字体、白底紫渐变、极少动效——因为"谁都不得罪的安全设计"在训练数据里占主导,模型采样时落进这个高概率中心,产出被用户称为 "AI slop"(AI 泔水审美),一眼就能认出是 AI 生成、随即被嫌弃。

好消息:Claude 高度可被引导(steerable)。 但把所有前端指引塞 system prompt,会让每个无关请求(调 Python、写邮件)都背着前端上下文。Skills 正是为此而生:按需动态加载专属上下文,不留永久开销。

"skills are prompts and contextual resources that activate on demand, providing specialized guidance for specific task types without incurring permanent context overhead." 译:skill 是按需激活的 prompt 和上下文资源,为特定任务类型提供专门指引,而不产生永久的上下文开销。

做法 = 像前端工程师那样想,把审美改进映射到"可写的前端代码":在 typography / color&theme / motion / backgrounds 四个维度给有针对性的语言(不必给死的 hex 码——那是"低空"硬编码;也不要"做得好看点"这种"高空"空话;要在中间"恰当的高度 / right altitude"提示)。最终做成一个 ~400 token 的 frontend 设计 skill,显式列出"避开 Inter/Roboto/紫渐变""用 CSS 变量保持一致""高冲击力的页面加载编排胜过零散微交互",并在结尾反复提醒"think outside the box"(因为模型会收敛到另一个局部最优,比如老用 Space Grotesk)。

另一个 skill:web-artifacts-builder——Claude 默认把前端塞进单个 HTML 文件(因为 artifact 要求单文件渲染),能力受限;这个 skill 给它脚本去搭 React + Tailwind + shadcn/ui 多文件工程,最后用 Parcel 打包回单文件。核心好处:给 Claude 执行样板动作的脚本,省 token 的同时提可靠性和性能。

更普适的结论:"models often have the ability to do more than they express by default."(模型默认表达出来的,往往少于它实际会的。)凡是"Claude 有能力却因收敛而产出平庸"的领域,都是开发 Skill 的候选。Skills 的官方第一方框架另见 Anthropic 工程团队第一方视角:Agent 工程化 / Skills / MCP / Claude Code(2025-2026 全集)。

附:13 篇源文一句话索引(按主题归位)

A. Managed Agents 平台

Claude Managed Agents: get to production 10x faster(2026-04-08)— 平台总览:可组合 API,把基建税外包,10x 提速;outcomes/multiagent 当时在 research preview。
Built-in memory for Claude Managed Agents(2026-04-23)— 文件式跨会话记忆 + 企业级权限/审计;Rakuten 错误率 -97%。
New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration(2026-05-06)— dreaming 睡眠复盘 + outcomes 评分自纠 + 主从多 agent + webhook。
New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels(2026-05-19)— 执行和私网数据留在你的边界(Cloudflare/Daytona/Modal/Vercel)。
Scaling Managed Agents: Decoupling the brain from the hands(工程)— 脑/手/会话三件解耦的元 harness 设计,TTFT 暴降。

B. Claude Code / harness 哲学 6. Harnessing Claude's intelligence(2026-04-02)— 三原则:用已会的工具 / 追问"能停掉什么" / 谨慎设边界;死重剪枝。 7. Redesigning Claude Code on desktop for parallel agents(2026-04-14)— 桌面端为并行 agent 重做(侧栏/side chat/内置终端/拖拽布局)。

C. 企业落地 & 安全 8. How enterprises are building AI agents in 2026(2025-12-09)— 500+ 技术负责人调研,57% 跑多阶段工作流,80% 已见经济回报。 9. How we contain Claude across products(工程)— 三产品三种围堵 + 五个"漏掉的风险"实战教训。 10. Preparing your security program for AI-accelerated offense(2026-04-10)— AI 加速攻防,七条行动清单 + Glasswing/Mythos 背景。

D. to-C 功能 11. Claude now creates interactive charts, diagrams and visualizations(2026-03-12)— 对话内联临时交互图表(≠ artifacts)。 12. New connectors in Claude for everyday life(2026-04-23)— 生活类 app 连接 + 动态浮现 + 无广告立场。 13. Improving frontend design through Skills(2025-11-12)— 用 Skill 治"AI slop 审美" + web-artifacts-builder。

与已有 wiki 的关系:模型代际/Max plan/产品定位看 Claude 产品发布演化(2024-2026 Opus / Sonnet / Haiku 4.x 全集 + Max Plan + Design);Skills/MCP/Building Effective Agents/harness 四类的官方第一方框架看 Anthropic 工程团队第一方视角:Agent 工程化 / Skills / MCP / Claude Code(2025-2026 全集)(其 hub 索引里已收录 #6、#5、#9 三篇,本篇是它们的展开详读);垂直行业产品和战略合作看 Anthropic 企业 / 行业产品组合 + 战略合作(2025-2026);agent-native 企业的第三方播客视角看 AI Builders · 智能体原生产品与企业 AI 落地(播客精炼);安全研究(Constitutional AI/RSP/welfare)看 Anthropic AI 安全 / 对齐 / 政策研究全集(Constitutional AI + RSP + Welfare + Policy)。

2026-09-26 增补：小企业采用需要连接器、明确任务与培训一起到位

来源：2026-09-25补抓的Claude for Small Business官方更新，已完整读取本地正文（full_scan）。数字为发布时口径，不是持续更新的当前清单；客户证言不等于平均效果。

该次更新称覆盖43个工作流、新增27项集成；27不是全部集成总数。任务从后台事务延伸到获客、回应入站询盘、提案和日常报告。其产品选择依据包括春季10城市行程中1000多名业主反馈，约三分之一希望帮助业务增长；这属于活动参与者意见，不是全市场代表性调查。

采用设计分成三层：连接器让资料可用，工作流让用户知道先做什么，培训帮助跨过第一次操作。文章安排10个美国城市工作坊、150多家培训机构的750多场本地活动和14家集成伙伴网络研讨会，说明发布能力目录之外还需要采用支持。

用户工作	产品给出的具体入口	仍需验收的结果
了解经营情况	现金、销售、线索和逾期账款周报	数据是否完整、口径是否对齐
处理商机	下班后的询盘回应与记录	回应是否准确、是否真的推进成交
准备提案	语音备忘变成带品牌和价格的文档	金额、承诺与品牌表达由谁确认
营销与月末事务	待确认的帖子/评论回复、供会计使用的结账包	审批完成、账务核验与实际使用

“Connect the tools you already use and pick your first task.” 译：连接你已经在用的工具，并选定第一项任务。

官方称5月推出后安装超过90万次，安装不等于独立客户、付费、活跃或留存。120小时变5分钟、获得2万美元收入、90%做对等均是选入文章的客户自述，不能直接用作收益或成功率保证。评估类似产品时，优先看首项任务完成率、重复使用、返工量与真实业务结果，而不只看工具数量。