Anthropic 不想让你再自己搭 Agent 基础设施了。
近日，Anthropic 正式推出 Claude Managed Agents 公开测试版——一套预建、可组合的代理框架（官方称之为 Agent Harness），运行在 Anthropic 托管的云端基础设施上。开发者不再需要自己折腾沙箱环境、Session 管理、错误恢复和权限控制，只需要通过 API 定义 Agent 该做什么，剩下的脏活累活全部交给 Anthropic。
说白了，这是 Anthropic 从"卖模型"走向"卖 Agent 运行时"的关键一步。
为什么要做这件事
过去一年，几乎所有在生产环境跑过 AI Agent 的团队都踩过同一个坑：Agent Harness（代理控制程式）的维护成本远超预期。
所谓 Harness，就是包裹在大模型外面的那层"脚手架"——它负责管理对话循环、调用工具、处理异常、维护上下文窗口。问题在于，这层脚手架本质上是在补偿模型当前能力的不足，而模型在快速迭代。你今天写的补偿逻辑，下个月可能就变成了累赘。
Anthropic 在公告中举了一个很具体的例子：Claude Sonnet 4.5 在接近上下文窗口上限时，会出现提前结束任务的毛病，团队于是在 Harness 里加了上下文重置机制。但当同一套 Harness 套到 Claude Opus 4.5 上时，这个问题已经不存在了——原本的重置逻辑反而成了多余的性能负担。
这不是个例。每一次模型升级，都意味着一轮 Harness 的排查和适配。对于 Anthropic 自己来说，他们比任何人都清楚模型下一步会怎么变，所以由他们来维护这层 Harness，逻辑上是最合理的。
对于开发者来说，这意味着一个选择：你是继续自己维护一套会不断过时的控制逻辑，还是把这件事交给最了解模型演进方向的人？
架构设计：像操作系统一样解耦
Managed Agents 的架构设计思路，Anthropic 自己的类比是操作系统。
操作系统把硬件抽象成进程和文件，让应用程序不用关心底层是什么 CPU、什么磁盘。Managed Agents 做的事情类似——它把一个 Agent 系统拆成三个彼此独立的层：
- "脑"（Brain）：模型推理与控制循环。负责思考、决策、规划下一步动作。
- "手"（Hands）：沙箱容器与工具执行。负责实际跑代码、调 API、操作文件。
- "记忆"（Memory）：独立存储的工作会话日志。记录 Agent 做过什么、当前状态是什么。
三者通过标准化接口通信，任何一个部分挂了或者需要替换，都不影响其他部分运作。
这个解耦带来的最直接好处是容器变成了可随时销毁和重建的"一次性"执行单元。以前的做法是把控制程序和执行环境塞在同一个容器里，容器挂了，整个 Agent 就挂了。现在控制程序通过标准接口跟容器交互，就像调用一个普通工具一样。容器崩溃时，控制程序把错误信息回传给 Claude，Claude 自己判断要不要重试，然后启动一个新容器继续干活。
因为会话日志独立存储在外部，控制程序本身变成了无状态组件。即使控制程序自己也崩了，重新拉起后读取事件日志，就能接着上次的进度继续执行。
这对长时间运行的任务来说是质的飞跃。以前跑一个需要几十分钟甚至几小时的 Agent 任务，中间任何一个环节出问题都可能前功尽弃。现在每一步都有记录，每个组件都可以独立恢复。
性能提升：不只是架构好看
解耦不是为了画架构图好看，它带来了实打实的性能改善。
最显著的一个数字：首次 Token 响应时间（TTFT）的 p50 降低约 60%，p95 降低超过 90%。
原因很直观——以前推理必须等容器启动完成才能开始，现在推理和容器启动是解耦的，模型可以先开始思考，容器在后台并行准备。对于用户来说，体感就是 Agent 的"反应速度"快了很多，不再有那种提交任务后干等几十秒的尴尬。
p95 降低超 90% 这个数字尤其值得关注。p95 代表的是长尾延迟，也就是最慢的那 5% 请求。在生产环境中，长尾延迟往往才是真正影响用户体验的瓶颈。能把这个数字砍掉九成，说明新架构在极端情况下的表现也相当稳定。
安全性：终于把凭证隔离做对了
安全性的改进可能是这次更新中最被低估的部分。
以前所有组件共处一个容器时，Claude 生成的代码和认证凭据（OAuth Token、API Key 等）在同一个环境里。这意味着什么？一次成功的 Prompt Injection 攻击，只要说服 Claude 读取环境变量，就可能拿到访问令牌。
这不是理论风险。在 Agent 场景下，模型需要处理来自各种外部来源的输入——用户上传的文档、网页内容、第三方 API 返回的数据——任何一个都可能包含恶意指令。把凭证和执行环境放在一起，就像把保险箱和小偷关在同一个房间里。
新架构下：
- OAuth 令牌存储在沙箱之外的独立保管库中
- Claude 通过专属代理服务调用 MCP（Model Context Protocol）工具
- 控制程序和沙箱全程不接触任何认证凭据
这是一个正确的设计方向。凭证隔离本来就应该是 Agent 基础设施的标配，但在之前"所有东西塞一个容器"的粗暴方案下，很难做到。
开发者视角：用起来什么感觉
Managed Agents 的使用方式是纯 API 驱动的。你通过 API 创建一个 Agent，定义它的行为（系统提示词、可用工具、执行环境配置），然后提交任务，异步获取结果。
核心概念很简单：
- 定义 Agent：指定模型、系统提示词、工具集
- 提交任务：发送用户指令，获取一个 task ID
- 轮询或回调：异步获取执行结果和中间状态
对于已经在用 Claude API 的开发者来说，迁移成本不高。它本质上是在现有 Messages API 之上加了一层编排和执行的托管能力。
如果你通过 OpenAI Hub 这类 API 聚合平台调用 Claude，可以关注一下对 Managed Agents 端点的兼容支持情况。以下是一个基于 Anthropic API 格式的基础调用示例，展示如何创建和使用托管 Agent：
import requests
import time
# 通过 OpenAI Hub 调用 Anthropic API
BASE_URL = \"https://openai-hub.com/anthropic/v1\"
API_KEY = \"your-openai-hub-key\"
headers = {
\"x-api-key\": API_KEY,
\"content-type\": \"application/json\",
\"anthropic-version\": \"2025-01-01\"
}
# 1. 创建托管 Agent
create_resp = requests.post(
f\"{BASE_URL}/agents\",
headers=headers,
json={
\"model\": \"claude-opus-4-5-20250630\",
\"system\": \"你是一个代码审查助手，擅长发现潜在的安全漏洞和性能问题。\",
\"tools\": [
{\"type\": \"code_execution\"},
{\"type\": \"file_access\"}
],
\"max_turns\": 20
}
)
agent_id = create_resp.json()[\"id\"]
print(f\"Agent created: {agent_id}\")
# 2. 提交任务
task_resp = requests.post(
f\"{BASE_URL}/agents/{agent_id}/tasks\",
headers=headers,
json={
\"messages\": [
{
\"role\": \"user\",
\"content\": \"审查这个仓库的 src/ 目录，找出所有未处理的异常和潜在的 SQL 注入风险，生成修复建议报告。\"
}
]
}
)
task_id = task_resp.json()[\"task_id\"]
# 3. 异步轮询结果
while True:
status_resp = requests.get(
f\"{BASE_URL}/agents/{agent_id}/tasks/{task_id}\",
headers=headers
)
status = status_resp.json()
if status[\"status\"] == \"completed\":
print(\"Agent 执行完成：\")
print(status[\"result\"])
break
elif status[\"status\"] == \"failed\":
print(f\"执行失败：{status['error']}\")
break
print(f\"执行中... 当前步骤：{status.get('current_step', 'N/A')}\")
time.sleep(5)
这段代码展示的是最基础的流程。实际使用中，你还可以配置 MCP 工具服务器、挂载文件系统、设置 OAuth 凭证等。
跟竞品比：Anthropic 在赌什么
目前做 Agent 托管基础设施的玩家不少。OpenAI 有 Assistants API（虽然定位略有不同），Google 有 Vertex AI Agent Builder，微软有 AutoGen + Azure 的组合。还有一堆开源框架——LangGraph、CrewAI、AutoGPT——在抢开发者心智。
但 Anthropic 这次的切入角度不太一样。
大多数框架和平台做的是"帮你更方便地编排 Agent"，本质上还是把编排逻辑交给开发者。Managed Agents 的态度更激进：编排逻辑你也别管了，我来。
这背后的赌注是：随着模型能力提升，Harness 层会越来越薄，最终大部分控制逻辑会被模型本身的能力吸收。既然如此，与其让开发者维护一套不断贬值的控制代码，不如由最了解模型演进节奏的 Anthropic 来做这件事。
这个判断对不对？短期来看，有道理。Claude 确实在快速迭代，每一代模型在工具调用、长上下文处理、错误恢复方面都有明显进步。那些你在 Sonnet 4.5 时代写的 workaround，到了 Opus 4.5 大概率就不需要了。
但长期来看，这也意味着更深的平台锁定。你的 Agent 逻辑跑在 Anthropic 的基础设施上，用的是 Anthropic 的编排方式，依赖的是 Anthropic 对模型行为的理解。想迁移到其他模型？没那么容易。
对于 Anthropic 来说，这恰恰是目的。在模型能力日趋同质化的今天，光靠模型本身越来越难建立护城河。但如果你的 Agent 基础设施、会话状态、工具集成全都跑在我的平台上，迁移成本就是最好的护城河。
对独立开发者意味着什么
Linux.do 社区里有开发者分享了自己独立开发 Harness 的经历——花了不少时间搭建，刚验证成功，就看到 Anthropic 官方发布了 Managed Agents。他的反应很真实："比不上人家的，算了，去研究 Anthropic 的 Harness 了。"
这是基础设施领域的经典剧情。当平台方亲自下场做某个能力时，独立开发者在这个方向上的投入就面临被覆盖的风险。
但换个角度看，这也未必是坏事。自建 Harness 的经验不会白费——理解了底层原理，用托管服务时才能做出更好的架构决策。而且 Managed Agents 目前还是公开测试版，在一些定制化场景下（比如需要对接私有工具链、需要在特定合规环境下运行），自建方案仍然有其价值。
关键是想清楚：你的核心竞争力到底是 Agent 的基础设施，还是 Agent 解决的业务问题？如果是后者，把基础设施交出去，把精力放在业务逻辑上，可能是更明智的选择。
几个值得关注的细节
MCP 工具协议的深度集成。Managed Agents 原生支持 MCP（Model Context Protocol），这意味着你可以把任何兼容 MCP 的工具服务器挂载到 Agent 上。MCP 正在成为 AI Agent 调用外部工具的事实标准，Anthropic 在自己的托管服务里把它作为一等公民来支持，会进一步加速这个协议的普及。
异步优先的设计。Managed Agents 明确定位于"长时间运行的任务和异步工作"。这不是用来做聊天机器人的，而是用来做那些需要几分钟甚至几小时才能完成的复杂任务——代码审查、数据分析、文档生成、多步骤的研究调研。这个定位很清晰，也避免了跟现有 Messages API 的功能重叠。
无状态控制程序的意义。控制程序无状态化意味着理论上可以做到真正的弹性伸缩。任务多的时候多起几个控制实例，任务少的时候缩回去，因为状态都在外部日志里，不存在实例间的状态同步问题。对于需要处理大量并发 Agent 任务的企业场景，这个设计很关键。
写在最后
Anthropic 这次发布 Managed Agents，表面上是推了一个新产品，实际上是在重新定义 AI Agent 的开发范式：模型提供商不只提供模型，还提供运行模型的最佳方式。
这个趋势值得所有 Agent 开发者认真对待。不是说你今天就要把所有东西迁移到 Managed Agents 上——它还在公测，API 可能会变，定价还不明朗。但它代表的方向是清晰的：Agent 基础设施正在从"自建"走向"托管"，就像十年前计算资源从自建机房走向云服务一样。
至于要不要上车，取决于你对平台锁定的容忍度，和对自建维护成本的诚实评估。
参考来源
- Anthropic 推託管代理服務，以解耦架構簡化長時間代理部署 - iThome：iThome 对 Managed Agents 架构设计和性能改进的详细技术报道
- Anthropic 出了 Harness 产品 - Linux.do：社区开发者对 Managed Agents 的第一手讨论和自建 Harness 经验分享