Anthropic 一周三连发：Cowork 多端、Fable 5 按需付费、J-space 论文的技术解读

7 月 7 日前后，Anthropic 在三个方向同时释放信号：

• Claude Cowork 从桌面端扩展到网页端和移动端，并披露超过 90% 的使用场景不在软件开发。
• Fable 5 从订阅权益中移除，改为按积分消耗付费。
• J-space 论文 提出 Claude 模型内部存在类似人脑全局工作空间的结构。

三件事分别对应产品形态、商业模式和底层能力。对开发者来说，理解它们的关联，有助于更合理地设计基于 Claude API 的工作流。

---

一、Cowork 多端上线：AI 代理的工程化方向

1.1 核心变化

Claude Cowork 的核心变化可以归纳为四点：

• 新增网页端和移动端入口
• 跨设备任务延续
• 后台定时任务
• 关键决策人工确认

其中对开发者最有参考价值的是「任务状态持久化 + 后台异步执行 + 关键节点确认」这套模式。

1.2 任务状态模型

任务状态不应跟设备会话绑定，而应跟用户账号绑定。最小状态模型可以设计为：

from datetime import datetime
from enum import Enum

class TaskStatus(str, Enum):
    PENDING = "pending"
    RUNNING = "running"
    AWAITING_CONFIRMATION = "awaiting_confirmation"
    COMPLETED = "completed"
    FAILED = "failed"

class Task:
    def __init__(self, user_id: str, task_id: str, scenario: str, payload: dict):
        self.user_id = user_id
        self.task_id = task_id
        self.scenario = scenario
        self.payload = payload
        self.status = TaskStatus.PENDING
        self.result = {}
        self.created_at = datetime.utcnow()
        self.updated_at = datetime.utcnow()

    def save(self):
        # 写入 PostgreSQL / Redis
        pass

1.3 异步任务执行

把 Claude API 调用放在 worker 里执行，不要阻塞前端请求。下面是一个简化示例：

import os
from celery import Celery
import anthropic

celery_app = Celery("cowork", broker="redis://localhost:6379/0")

client = anthropic.Anthropic(
    api_key=os.getenv("CLAUDE_API_KEY"),
    base_url="https://gw.claudeapi.com"
)

@celery_app.task(bind=True, max_retries=3)
def run_cowork_task(self, task_id: str):
    task = db.get_task(task_id)
    task.status = TaskStatus.RUNNING
    task.save()

    try:
        context = collect_context(task.payload)
        response = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=4096,
            system=get_scenario_prompt(task.scenario),
            messages=build_messages(task, context),
            timeout=120  # 显式设置超时
        )
        result = parse_response(response)

        if needs_confirmation(result):
            task.status = TaskStatus.AWAITING_CONFIRMATION
            send_push_notification(task.user_id, task_id, result)
        else:
            task.status = TaskStatus.COMPLETED
        task.result = result
        task.save()

    except anthropic.APIError as exc:
        task.status = TaskStatus.FAILED
        task.result = {"error": str(exc)}
        task.save()
        raise self.retry(exc=exc, countdown=60 * (2 ** self.request.retries))

1.4 关键决策确认

涉及以下场景时应暂停任务并推送确认：

CONFIRMATION_THRESHOLD = 10.0  # USD

def needs_confirmation(result: dict) -> bool:
    return any([
        result.get("action") in ["send_email", "publish", "sign_contract"],
        result.get("cost_usd", 0) > CONFIRMATION_THRESHOLD,
        result.get("compliance_risk") == "high"
    ])

---

二、使用数据：90% 以上不在写代码

Anthropic 披露的数据如下：

场景	占比	典型任务
业务运营	33.4%	支出核对、差异备忘录、合同续签追踪
内容创作	约 16-17%	客户材料整理、文档起草
业务运营 + 内容创作合计	约 50%	知识型工作中的高频任务
软件开发	8.7%	代码相关任务

这组数据说明，当前 AI 代理的高频落地场景不是编程，而是结构化、可分解的办公任务。开发者在设计 AI 代理时，应该把集成对象从 IDE 扩展到 ERP、CRM、邮件系统、文档协作平台等企业内部系统。

---

三、Fable 5 按需付费：模型分层策略

从 7 月 7 日起，Fable 5 不再包含在订阅权益中，改为按积分消耗付费。这对用 Claude API 的团队有直接影响。

3.1 按场景选择模型

不同任务应该调用不同模型。高端模型只用在关键判断环节，日常任务用成本更低的模型。

MODEL_ROUTER = {
    "topic_analysis": "claude-sonnet-4-6",
    "content_writing": "claude-sonnet-4-6",
    "compliance_review": "claude-fable-5",  # 关键判断
    "final_polish": "claude-fable-5",        # 最终定稿
    "data_cleanup": "claude-haiku-4",        # 轻量整理
}

def select_model(scenario: str) -> str:
    return MODEL_ROUTER.get(scenario, "claude-sonnet-4-6")

3.2 调用时指定模型

response = client.messages.create(
    model=select_model(task.scenario),
    max_tokens=4096,
    system=get_scenario_prompt(task.scenario),
    messages=build_messages(task, context)
)

3.3 成本控制策略

• 组织级总量：整个团队每月/每周的调用预算上限。
• 场景级上限：不同场景的独立预算，防止单一场景异常消耗。
• 80% 预警：在预算达到 80% 时触发告警。
• Prompt Caching：对高频重复上下文使用缓存，降低 token 成本。

BUDGET_LIMITS = {
    "topic_analysis": {"monthly": 50, "currency": "USD"},
    "content_writing": {"monthly": 100, "currency": "USD"},
    "compliance_review": {"monthly": 30, "currency": "USD"},
    "data_cleanup": {"monthly": 20, "currency": "USD"},
}

def check_budget(scenario: str, current_cost: float) -> bool:
    limit = BUDGET_LIMITS.get(scenario, {}).get("monthly", 0)
    if current_cost > limit * 0.8:
        send_budget_alert(scenario, current_cost, limit)
    return current_cost < limit

---

四、J-space 论文：对 Prompt 设计的启发

Anthropic 的论文提出，Claude 模型内部存在 J-space 结构，类似人脑的全局工作空间。信息需要先进入这个「广播区」，才能被模型的其他部分使用和推理。

这个发现对 Prompt 设计有几个启发：

• 明确目标和约束：在 System Prompt 中把任务目标、判断标准、红线约束写清楚，帮助模型把关键信息拖入 J-space。
• 任务分步输出 ：把复杂任务拆成多个步骤，每步输出一个清晰
  的中间结果，减少信息在后台计算中的丢失。
• 关键节点提醒：在对话中适时重复关键约束，确保模型在后续推理中仍能访问这些信息。

SCENARIO_PROMPTS = {
    "compliance_review": """你是一名合规审查助手。
目标：检查文章是否违反品牌红线。
判断标准：
1. 不得出现竞品贬低性表述
2. 不得承诺未经验证的功能
3. 涉及数据必须有来源标注
请按以下步骤输出：
1. 列出发现的问题
2. 给出修改建议
3. 说明每条建议的依据
"""
}

---

五、架构映射：Cowork 能力如何落地

Cowork 能力	后端组件	关键设计点
跨设备任务延续	PostgreSQL / Redis	任务状态与用户账号绑定
后台定时任务	Celery / Rq / Temporal	worker 中异步调用 Claude API
关键决策确认	推送服务 / 邮件 / IM	状态停在 awaiting_confirmation
按场景拆分模型	Model Router	按任务重要性选择模型
审计与成本控制	日志表 / 预算告警	记录谁、在什么场景、调用了什么模型

建议的系统架构如下：

┌─────────────┐     ┌─────────────┐     ┌─────────────────┐
│  桌面端     │     │  网页端     │     │  移动端         │
└──────┬──────┘     └──────┬──────┘     └────────┬────────┘
       │                   │                     │
       └───────────────────┼─────────────────────┘
                           │ HTTP / WebSocket
                           ▼
                   ┌───────────────┐
                   │   API Gateway │
                   └───────┬───────┘
                           │
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
    ┌────────────┐  ┌────────────┐  ┌────────────┐
    │ Task Store │  │   Queue    │  │  Audit Log │
    │ (PG/Redis) │  │  (Celery)  │  │   (PG)     │
    └─────┬──────┘  └─────┬──────┘  └────────────┘
          │               │
          │               ▼
          │        ┌──────────────┐
          │        │ Claude API   │
          │        │   Worker     │
          │        └──────┬───────┘
          │               │
          ▼               ▼
    ┌─────────────────────────────┐
    │   Notification Service      │
    │  (Email / Slack / WeCom)    │
    └─────────────────────────────┘

---

六、完整端到端示例

把上面的片段串起来，一个简化但完整的任务流如下：

import os
from datetime import datetime
from celery import Celery
import anthropic

celery_app = Celery("cowork", broker="redis://localhost:6379/0")
client = anthropic.Anthropic(
    api_key=os.getenv("CLAUDE_API_KEY"),
    base_url="https://gw.claudeapi.com"
)

CONFIRMATION_THRESHOLD = 10.0  # USD

class Task:
    def __init__(self, user_id, task_id, scenario, payload):
        self.user_id = user_id
        self.task_id = task_id
        self.scenario = scenario
        self.payload = payload
        self.status = "pending"
        self.result = {}

    def save(self):
        # 实际项目中写入数据库或 Redis
        print(f"[{self.task_id}] status={self.status}")

@celery_app.task(bind=True, max_retries=3)
def run_cowork_task(self, user_id: str, task_id: str, scenario: str, payload: dict):
    task = Task(user_id, task_id, scenario, payload)
    task.status = "running"
    task.save()

    try:
        # 1. 检查预算
        if not check_budget(scenario, get_current_cost(user_id, scenario)):
            task.status = "failed"
            task.result = {"error": "budget exceeded"}
            task.save()
            return

        # 2. 收集上下文
        context = collect_context(payload)

        # 3. 调用 Claude API
        response = client.messages.create(
            model=select_model(scenario),
            max_tokens=4096,
            system=get_scenario_prompt(scenario),
            messages=build_messages(task, context),
            timeout=120
        )
        result = parse_response(response)

        # 4. 记录成本
        log_cost(user_id, scenario, response.usage)

        # 5. 判断是否需要确认
        if needs_confirmation(result):
            task.status = "awaiting_confirmation"
            send_push_notification(user_id, task_id, result)
        else:
            task.status = "completed"
            if result.get("action") == "send_email":
                execute_email(result)

        task.result = result
        task.save()

    except anthropic.APIError as exc:
        # 重试策略：API 错误时指数退避
        task.status = "failed"
        task.result = {"error": str(exc)}
        task.save()
        raise self.retry(exc=exc, countdown=60 * (2 ** self.request.retries))

这个示例覆盖了状态流转、异步执行、预算检查、确认节点和错误重试。生产环境中还需要补上权限校验、输入校验、审计日志和幂等控制。

---

七、常见错误与排障

7.1 任务状态丢失

表现 ：用户刷新页面后任务进度消失。

原因 ：任务状态存在内存或单次会话里，没有持久化。

解决：把状态写入 Redis / PostgreSQL，前端通过 task_id 轮询或 WebSocket 拉取。

# 错误做法
tasks = {}  # 进程内存，重启即丢

# 正确做法
import redis
r = redis.Redis(host='localhost', port=6379, db=0)
r.set(f"task:{task_id}", json.dumps(task.to_dict()))

7.2 API 调用超时导致任务卡住

表现 ：任务长时间停留在 running，没有结果也没有报错。

原因 ：Claude API 调用没有设置超时和重试。

解决 ：给 client.messages.create 加 timeout，在 Celery 任务里配置 max_retries 和 retry_backoff。

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    messages=messages,
    timeout=120  # 秒
)

7.3 确认通知被忽略

表现 ：任务到了 awaiting_confirmation，但用户没收到或没看到通知。

原因 ：通知渠道单一，或者确认内容太长。

解决：多通道通知（企业微信 + 邮件），确认内容压缩成一句话摘要，附上直接确认的链接。

def send_push_notification(user_id, task_id, result):
    summary = f"任务 {task_id} 需要确认：{result.get('summary', '')}"
    wecom.send(user_id, summary)
    email.send(user_id, "任务确认", summary)

7.4 场景权限混乱

表现 ：内容运营场景的 AI 调用了合规审查才能访问的数据源。

原因 ：System Prompt 里没有明确限制可访问数据源，或者权限校验在模型层之外缺失。

解决：每个 scenario 配独立的 System Prompt 和允许访问的数据源白名单，调用前在业务层校验。

ALLOWED_DATA_SOURCES = {
    "content_writing": ["cms", "brand_guidelines"],
    "compliance_review": ["cms", "legal_kb", "brand_guidelines"],
}

def collect_context(payload: dict) -> list:
    scenario = payload["scenario"]
    allowed = ALLOWED_DATA_SOURCES.get(scenario, [])
    return [load_source(s) for s in payload["sources"] if s in allowed]

7.5 费用失控

表现 ：某个场景一夜之间花了远超预期的额度。

原因 ：只有组织级预算上限，没有按场景拆分。

解决：组织级总量 + 场景级上限 + 80% 预警，metadata 里带 scenario 标签便于统计。

7.6 模型选择没有分层

表现 ：所有任务都用 Fable 5，成本失控。

原因 ：没有按任务重要性选择模型。

解决 ：建立场景级模型路由和预算上限，参考本文 3.1 节的 MODEL_ROUTER 示例。

7.7 幂等性缺失导致重复执行

表现 ：同一个任务被触发多次，产生重复邮件或重复内容。

原因 ：任务提交没有幂等控制。

解决：用 task_id + idempotency_key 去重，worker 执行前先检查状态是否已经是 running 或 completed。

@celery_app.task(bind=True, max_retries=3)
def run_cowork_task(self, user_id, task_id, scenario, payload):
    existing = db.get_task(task_id)
    if existing and existing.status in ("running", "completed"):
        return  # 已经执行过，直接返回
    # ... 继续执行

7.8 Prompt 注入导致输出不可控

表现 ：用户输入的内容改变了 System Prompt 的意图。

原因 ：用户输入和系统指令没有清晰分隔。

解决 ：明确使用 system、user、assistant 角色分隔，对用户输入做长度和关键词过滤。

---

八、性能优化建议

8.1 使用 Prompt Caching 降低重复上下文成本

对于高频重复场景，比如每天生成类似的报告，可以把固定上下文缓存起来：

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    system=get_scenario_prompt(scenario),
    messages=[
        # 固定上下文使用 cache_control
        {"role": "user", "content": fixed_context, "cache_control": {"type": "ephemeral"}},
        {"role": "user", "content": variable_context}
    ]
)

8.2 流式输出提升前端体验

对于需要实时反馈的场景，使用流式输出：

stream = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    messages=messages,
    stream=True
)
for event in stream:
    if event.type == "content_block_delta":
        yield event.delta.text

8.3 任务结果缓存

对于重复性高的查询，可以缓存任务结果：

import hashlib

def get_task_cache_key(scenario, payload):
    payload_str = json.dumps(payload, sort_keys=True)
    return f"task_result:{scenario}:{hashlib.md5(payload_str.encode()).hexdigest()}"

---

九、总结

Anthropic 这一周的三件事，分别回答了 AI 代理落地中的三个关键问题：

• 产品形态：Cowork 让 AI 代理从桌面工具变成跨设备、可持续运行的任务执行者。
• 商业模式：Fable 5 按需付费说明高端模型需要分层定价。
• 底层能力：J-space 论文为复杂推理能力提供了研究层面的解释。

对开发者来说，这套组合意味着：设计 AI 工作流时，要同时考虑任务状态持久化、模型分层、成本控制、人工确认、审计日志和幂等控制，而不是只写一个好 Prompt。

---

十、数据与事实声明

• Claude Cowork、Fable 5、J-space 论文的事实均来自 Anthropic 官方披露及公开媒体报道。
• 本文关于技术实现、工作流设计、模型分层策略的建议为 ClaudeAPI 独立观点，不代表 Anthropic 官方立场。代码示例为简化演示，生产环境需完善错误处理、权限控制和审计机制。

本文的持续更新版本可查看：Anthropic 一周三连发：Cowork 多端、Fable 5 按需付费、J-space 论文