来源

• 原始链接：https://www.youtube.com/watch?v=lLypHkIVLqc
• 来源类型：视频逐字稿
• 来源标题：访谈 Anthropic 克劳德产品&工程负责人：解析 Claude Managed Agents 产品定位、设计哲学与 AI 平台演进方向

Claude Managed Agents 产品定位与 AI 平台演进

这期访谈最值得看的地方，是 Anthropic 团队没有把 Claude Managed Agents 讲成一个新 API，而是在讲 AI 平台抽象层的迁移：从一次性的补全文本，迁移到持续运行、可部署、可拥有身份、可被组织接管的执行基础设施。

AI 平台正在从模型接口变成结果交付层

背景：早期平台提供的是 completion endpoint。用户提交 prompt，平台返回 response。随着模型开始调用工具、保存状态、运行更长的任务，平台需要承担更多执行环境职责。

平台最终可能是一组 primitives 和 infrastructure，让你用尽可能少的工作，尽快得到想要的 outcome。

一年后，Claude 可能足够理解自己，能判断该使用哪个模型，能启动所需的 sub-agents。用户不必过多思考具体架构，因为 Claude 能在运行中即时生成适合当前任务的系统形态。

兴趣匹配度高。这个判断把问题从“怎么调 prompt”推进到“AI 平台到底负责什么”。真正的竞争点开始落在状态、工具、运行循环、沙箱、部署和可观察性上。

Managed Agents 的来源：把反复搭过的 Agent 基础设施下沉为平台

背景：Anthropic 说他们内部已经多次为产品搭建能够在云端自主运行的 agent infrastructure。重复搭到一定程度后，它就不该继续停留在每个应用自己的脚本里。

Claude Managed Agents 的动机，是把 Anthropic 自己多次搭过的云端 agent infrastructure 产品化。外部开发者不该继续靠几台机器临时跑循环，而应该拿到一套可规模化的基础设施。

他们希望 Managed Agents 保持模块化，但在某些地方会非常有主见：比如鼓励 Claude 使用文件系统，也重度押注 Skills。这些 primitives 和 Claude 的模型特性高度匹配。

兴趣匹配度高。这里给了一个实用判断标准：如果 loop、state、sandbox、filesystem、skills、tooling 在多个 agent 产品里反复出现，它们就应该下沉为平台层能力。

模型无关化被高估了，真正有效的 Agent 是 model-shaped

背景：过去很多工程师会搭一个通用 harness，然后在里面热切换不同模型。但 Anthropic 的判断是，下一代模型会越来越分化，抽象层会从切换模型变成切换一整套 agent。

对上一代模型，通用 harness 加模型热切换还算合理。但下一代模型会越来越分化。为了交付结果，你不再只是切换底层模型，而是把 harness 和 model 作为一个整体 agent 来切换。

同一个 memory 功能，不同 harness 的 eval 差异非常大。只要把正确组件组合起来，表现就能继续 hill climb。因此，harness engineering 里面仍然有大量 alpha。

兴趣匹配度高。这里的核心不是模型更强，而是模型在什么结构里更强。Agent 系统的性能来自模型、记忆、文件系统、工具、循环和 eval suite 的共同塑形。

Agent 产品真正撞墙的地方，是生产基础设施

背景：很多人以为做 Agent 最难的是 prompt caching、context window、模型调用策略这些 harness engineering。访谈里更强的判断是：原型跑通后，真正难的是生产环境。

客户常常是原型跑通后，想进入生产环境时撞上基础设施墙：要不要常驻服务器，如何 spin up 和 spin down，如何保存 transcript，如何安全沙箱化。如果 sandbox 掉线，整个 agent 就死了。

越有趣的 agent，越会变成长时间运行、异步、远程、自主的东西。只要你想让它持续运行，生产化就会变成主要问题。

兴趣匹配度高。这是判断 Agent 平台是否真实有价值的关键尺度：它能否处理持久状态、远程执行、权限、沙箱、失败恢复和异步协作。一次性 demo 距离组织流程改造还差一个 production substrate。

Agent identity 和组织 owner，会决定自动化能否长期活着

背景：当 Agent 从个人效率工具进入团队流程，它就需要身份、凭证、权限和责任结构。否则自动化会随着业务变化迅速失效。

更成熟的形态，是 agent 可以非常容易地部署。比如 vaults 作为保存 credentials 的 primitive，再把 agent identity 相关 primitive 安全封装起来。未来你可能只要告诉 Claude 加上 Slack，它就自动处理所有事情，然后 bot 已经在 Slack 里 ping 你了。

如果一个 agent 没有明确的人类 owner，它很快就会过时，变成一个还在外面做事、但实际已经不好用的僵尸自动化。

兴趣匹配度高。这里把 Agent 从技术对象推进到组织对象。可持续的 Agent 需要 owner、权限边界、反馈通道和维护责任。它更像一个小型产品，而不是一个部署完就结束的脚本。

团队层 Agent 不是个人 Copilot，而是 AI software factory

背景：个人层面的 AI 工具已经能提升单人效率。但在团队层面，多个人、多个流程和多个 agent 需要协作，单个聊天窗口无法承载端到端自动化。

到了团队层，agent 不能只坐在某个人的笔记本上。多个人可能需要几个 agent 相互接口、协作，自动化一个端到端流程。复杂流程要被 AI 真正改造，需要比单个 agent 更高一层的团队抽象。

把公司内部看成一个 AI software factory，会创造很高杠杆。它提升的不只是个人效率，而是公司里的每一个流程。

兴趣匹配度高。这和汉松的管理身份也贴得很近。未来 AI 原生组织的关键，不是每个人都打开一个助手，而是流程本身被一组可部署、可控制、可协作的 agent 重构。

Skill 和 Agent 的边界：能力包不等于运行单元

背景：访谈里专门讨论了 managed agent 是否只是一个 skill。答案很明确：不是。真实业务有审批、授权、多人协作、多阶段执行，这些都超出了单个 skill 的范围。

Managed agent 不只是一个 skill。真实业务里需要 human-in-the-loop：人要审核、确认、授权。要自动化完整流程，就需要启动独立的 agent session，并把多个 session 串起来。

业务团队可以拥有自己的 agent，但更多是通过 Claude 和 agent 对话。Claude 再判断应该怎么处理。最终用户看到的是在和 Claude 说话，底层其实是多个 Claude 彼此协作，完成复杂工作。

兴趣匹配度高。这给了一个清晰边界：Skill 是能力封装，Agent 是跨时间、跨权限、跨会话运行的编排单元。对设计内部 AI 工作流很有参考价值。

多 Agent 编排的可复用模式

背景：访谈后半段提到了几类多 Agent 架构，不是泛泛地说让很多 Agent 一起跑，而是把编排拆成可迁移的模式。

Multi-agent orchestration 的有趣用途之一，是把执行和建议分开；让一个 agent 生成，另一个 agent 对抗审查；把任务拆成许多小块再重组；或者做类似 best-of-N 的策略。不同架构适合不同场景：深度研究、广度研究、bug hunting 等。

Agent 平台的终局可能是把一切压缩成 outcome 和 budget。人类定义一个可验证 outcome，再给出预算，其他东西由系统自己推导。

兴趣匹配度高。这里值得沉淀成自己的 agent pattern library。长期看，人的主要工作可能从设计固定 harness，转向定义可验证结果、预算、约束和评估方式。