OpenClaw 实战：Anthropic 三种 Agent 架构选型指南

本文首发于微信公众号「Wesley AI 日记」，更多 AI Agent 实战系列请微信搜索关注。

---

48小时内，Anthropic 悄悄把自家的 Agent 生态搭成了三层楼：Agent SDK、Agent Teams、Managed Agents。

一句话概括：你可以自己搭骨架、你可以让几个 Agent 手拉手干活、你也可以干脆把整条流水线托管给 Anthropic。三条路，三种成本曲线，三种权力交接比例。

我用 OpenClaw 带着 6 个 AI 员工跑一人公司的这半年，每一种架构都真金白银踩过。这篇文章把三种架构的核心机制、适用场景、优缺点讲清楚，再给出一个可以照着选的决策树。

Anthropic 48 小时内发了什么

动作一：Managed Agents 公开发布。 开发者只需要定义工具和目标，harness、memory、子 Agent 编排全部由 Anthropic 接管。Hacker News 当天讨论量破千。

动作二：Agent Teams 在 Claude Code 里上线。 多个 Agent 通过共享 task list 实时通信。和传统"子 Agent 并行"最本质的区别是：传统子 Agent 是 fire-and-forget，各干各的；Agent Teams 是共享状态协作，多个 Agent 能实时看到对方进度。

动作三：Claude Agent SDK 继续演进。 开发者自己掌控 harness、memory、工具调用、prompt 设计。完全自由，但所有工程量都在你头上。

三种架构核心差异对比

维度	Agent SDK	Agent Teams	Managed Agents
谁管 agent loop	你自己	你自己	Anthropic
谁管 memory	你自己	你自己	Anthropic
谁管子 Agent 编排	你自己	共享 task list 自动同步	Anthropic
状态共享	各 Agent 独立	实时共享	对使用者透明
控制粒度	最细（到 prompt 字节）	中（到任务项）	最粗（到 goal）
初期工程量	最高	中	最低
成本可预测性	最高	中	低
锁定程度	最低	中	最高

滑动条的两端：SDK 是"全自己来"，Managed Agents 是"全托管"，Agent Teams 是"我还想管，但别让我写状态同步"的折中档。

Agent SDK：最自由也最累

SDK 是一套"你自己搭 loop"的工具箱。你要亲手写 agent loop、亲手设计 memory 结构、亲手做工具注入、亲手处理错误恢复。

骨架大概长这样：

from anthropic import Anthropic

client = Anthropic()
messages = []
tools = [my_tool_schema]

while True:
    response = client.messages.create(
        model="claude-opus-4",
        messages=messages,
        tools=tools,
    )
    if response.stop_reason == "end_turn":
        break
    if response.stop_reason == "tool_use":
        tool_result = run_my_tool(response.content)
        messages.append({"role": "user", "content": tool_result})

这个 loop 看着简单，实际写起来要处理：token 超限截断、工具调用失败重试、中间结果持久化、长对话的 summary 压缩、错误恢复……每一项都是坑。

我写第一版 Agent loop 时的真实体验：真正的业务逻辑只占 30%，剩下 70% 全是 harness 的防御性代码。而且每次 Anthropic 更新模型、更新 tool use 协议，你都得跟着改。

适合场景：

• 你在做 Agent 产品，harness 本身就是你的核心差异化
• 需要在特定领域做 prompt 调优（法律、医疗、代码）
• 需要深度定制 memory 结构（向量数据库+知识图谱混合检索）
• 要接的工具很多 API 是私有的，不可能上托管层

不适合：你只是想让 Agent 跑个内容流水线，或者团队没有专门维护 harness 的 AI 工程师。

Agent Teams：共享状态协作，长任务的"项目管理视角"

Agent Teams 的关键词：共享 task list 实时通信。

传统子 Agent 并行是 fire-and-forget 模型：主 Agent 派任务 → 子 Agent 各干各的 → 主 Agent 收集结果。子 Agent 之间互相不知道对方在干什么。

Agent Teams 做法是：所有 Agent 看同一个 task list，同一个状态面板。任何一个 Agent 更新了任务状态，其他 Agent 立刻能看到。

概念代码：

# 主 Agent 创建共享 task list
team_state = create_shared_state([
    {"id": "t1", "task": "抓数据", "status": "pending"},
    {"id": "t2", "task": "分析", "status": "pending"},
    {"id": "t3", "task": "生成报告", "status": "pending"},
])

# 多个 Agent 同时接入同一个 state
agent_a = create_agent(role="data-collector", state=team_state)
agent_b = create_agent(role="analyst", state=team_state)
agent_c = create_agent(role="writer", state=team_state)

# Agent A 完成 t1 → state 更新 → Agent B 立刻看到 → 开始 t2

和传统子 Agent 的关键区别：Agent A 发现数据有坑，可以直接改 task list 加一项"先清洗"，Agent B 立刻能看到并跳过原来的分析步骤等清洗完成。动态协调能力是传统子 Agent 做不到的。

潜在问题：

• 共享状态 = 状态冲突的可能（两个 Agent 同时改同一项怎么办）
• 对模型理解力要求高（Agent 要会读懂 task list）
• 并行度受限于共享状态的读写瓶颈

适合场景：长任务（跨小时/跨天级别）、多 Agent 之间有依赖关系、需要人类随时查看进度并调整。

Managed Agents：Anthropic 当包工头，代价是锁定

你告诉 Anthropic 两件事：有哪些工具（tool schema）、要完成什么目标（goal）。剩下全部由 Anthropic 平台层搞定。

概念代码：

from anthropic import Anthropic

client = Anthropic()

managed_agent = client.managed_agents.create(
    tools=[search_tool, database_tool, email_tool],
    goal="每天早上 8 点扫描行业新闻，挑出 3 条最相关的，写成简报发给我",
    memory_policy="persistent",
)

result = managed_agent.run()

没有 while loop，没有错误重试，没有 memory 管理。你只描述"是什么"和"要什么"。

真实的缺点清单：

1. 锁定——迁移成本极高，Agent 深度依赖 Anthropic 平台层
2. 黑盒——harness 怎么跑、memory 怎么存，你看不到也改不了
3. 成本不透明——托管层自己决定开几个子 Agent，账单拿到手已是既成事实
4. 调试困难——出 bug 只能看到输入/输出，中间发生了什么要靠 Anthropic 给你看

战略意图：PYMNTS 那篇报道说得不客气——"挤压 Agent 创业公司赛道"。过去一年靠"帮你搭 Agent 架构"活着的创业公司，现在 Anthropic 直接把这件事做成了基础设施。

决策树：照着选就行

┌─ 你的 Agent 是产品本身还是内部工具？
│
├── 是产品本身 → harness 是护城河 → 选 Agent SDK
│
└── 是内部工具 / 流程自动化
    │
    ├─ 任务是单次还是长流程？
    │
    ├── 长流程，需要多 Agent 协作 + 人类可干预
    │   → 选 Agent Teams
    │
    └── 短平快，一次性任务
        │
        ├─ 有 AI 工程师团队吗？
        │
        ├── 有 → 自己写 SDK（更可控）
        │
        └── 没有 / 想快速上线 → Managed Agents

我的 OpenClaw 混搭方案

我不是用一种架构走到底，而是混搭：

场景一：日常内容流水线 → SDK 风格 harness。 写长文 → 质检 → 配图 → 推送 → 复盘。这条流水线是核心业务，需要控制每一步的 prompt、脱敏检查、防回退逻辑（踩过"草稿改动被旧快照覆盖"的坑之后更是）。Managed Agents 无法给这个控制粒度。

场景二：跨平台分发 → 子 Agent 并行 fire-and-forget。 一篇文章分发到 6 个平台，6 个子 Agent 并行跑，互相不需要通信。共享状态反而是负担。

场景三：长任务复盘 → Agent Teams 共享 task list。 数据抓取、趋势分析、竞品对比、策略建议，中间经常要插进去改方向。多个 Agent 共享 task list，随时能查看进度、改任务。

场景四：Master Scheduler 架构解决配额限制。 踩过的最大坑：远程触发平台只给 3 个 scheduled tasks 配额，不够分配给 6 个 Agent。最后搞了一个 master scheduler Agent 来调度其他 5 个 Agent。这恰恰证明了 Managed Agents 最大的风险：托管层的硬限制是你改不了的。

三个实战教训

教训一：不要一开始就上最重的架构。 第一次搭 Agent team 直接选了最复杂的共享 state 方案，两周后发现 80% 的任务根本用不上共享状态。砍掉共享状态层，改回子 Agent fire-and-forget，系统反而跑得更快、更稳。架构复杂度要匹配任务复杂度。

教训二：托管层的配额是你改不了的。 前面说的 master scheduler 的由来。如果用 Managed Agents，连"自己搭 master scheduler"这个 workaround 都做不了，因为调度逻辑是平台层的。选架构前，先看清楚托管层的硬限制。

教训三：控制力和工作量是一个滑动条。 完全自由 = 工作量爆炸 = 你根本做不完。完全托管 = 自由度归零 = 产品没有独特性。真正好的选择是"在最需要控制的地方自己写，在不需要控制的地方直接托管"。

---

关注公众号获取更多 AI Agent 实战

本文首发于微信公众号「Wesley AI 日记」

AI Agent 实战系列（微信搜索关注）：

• OpenClaw 实战：Anthropic 三种 Agent 架构选型指南
• Anthropic 封杀事件复盘：一人公司 AI Agent 的风险管理
• Agent Harness 工程实战：70% 时间写防御代码的真相

微信搜索「Wesley AI 日记」关注，不错过每篇更新。

知识星球「光锥之内」—— Agent 实战交流、工具推荐、问题讨论，微信搜索加入。

---

标签：Claude Anthropic Agent AI Agent LLM 多智能体 一人公司 Claude SDK