Claude Agent 终于能交付了：Computer Use、Skills API、Files API 怎么组合

2026 年 8 月 20 日，Anthropic 宣布 Computer Use、Skills API 和 Files API 在 Claude Platform 全面可用，同时新增 Browser Use 工具。

如果只看功能列表，这像是一次常规的平台更新：Claude 会点鼠标了、能加载 Skill 了、也能保存文件了。但把它们放到同一条业务链路里，意义就不一样了——Claude 开始具备一套相对完整的“接任务、按规则执行、操作外部环境、产出可交付文件”的能力。

这才是很多企业真正缺的部分。模型会回答问题，并不等于 Agent 能把工作交付出来。

本文不做发布会式功能复述。我们直接用一个“竞品研究 Agent”拆解：四项能力分别负责什么，如何组合成生产流程，怎样控制权限，以及 Apito 应该放在架构中的哪一层。

先把四项能力分清：它们解决的不是同一个问题

可以用一句话理解：

• Computer / Browser Use 负责“动手”；
• Skills API 负责“按什么方法做”；
• Files API 负责“拿什么做，以及交付什么”；
• Claude 模型负责理解目标、判断下一步和组织结果。

Anthropic 在公告中还提到，更新后的 Computer Use 与新的 Browser Use 支持在一次模型回合中规划多个动作。过去一次点击可能对应一次模型调用，现在可以把连续操作组合起来，减少来回请求和等待时间。不过，“调用更少”不等于任何任务都会更便宜，实际成本仍取决于页面复杂度、失败重试、截图数量和输出规模。

为什么这次更新更接近“生产级 Agent”

过去搭一个 Agent，最常见的尴尬是这样的：

1. 模型能写出一份很漂亮的计划；
2. 真正执行时，找不到业务模板，也不知道公司的格式要求；
3. 它能打开网页，却无法稳定保存资料和中间产物；
4. 最后输出一段聊天文本，还得由人手动整理成报告。

这套新组合补上了中间三段。

Skill 把隐性经验变成可版本化的规则；Computer / Browser Use 把文字计划变成外部操作；Files API 则让输入材料和输出文件不必反复塞进对话。它们组成的不是一个“更聪明的聊天框”，而是一条可以审计、复用和逐步自动化的交付链路。

图中的 Apito 只承担第三方模型访问层：统一 API Key、请求地址、模型选择、调用记录和成本观察。Skills API、Files API、Computer Use 与 Browser Use 是否能直接使用，仍取决于具体上游通道和当前接口支持情况，不能把第三方模型网关等同于 Anthropic 官方平台能力。

实战：搭一个能交付报告的竞品研究 Agent

我们把目标定得具体一些：

用户上传一份产品资料和竞品名单，Agent 按固定研究方法访问公开网页，记录证据，生成一份结构化报告；涉及登录、提交或发送的动作必须停下来等人确认。

整个流程可以拆成六步。

第一步：先写 Skill，不要先写一个巨型提示词

一个可维护的 Skill 至少应该包含：任务边界、执行步骤、证据标准、输出模板和失败处理。目录可以这样组织：

market-research-skill/
├── SKILL.md
├── references/
│   ├── source-quality.md
│   └── competitor-fields.md
├── templates/
│   └── report-template.md
└── scripts/
    └── normalize_links.py

market-research-skill/
├── SKILL.md
├── references/
│   ├── source-quality.md
│   └── competitor-fields.md
├── templates/
│   └── report-template.md
└── scripts/
    └── normalize_links.py

SKILL.md 不要写成口号。它应该告诉 Agent 什么时候用、先做什么、什么算完成。例如：

---
name: market-research
description: Research public product information and produce a cited comparison report.
---

# Market research workflow

1. Read the provided product brief and competitor list.
2. Prefer official product pages, documentation, pricing pages, and release notes.
3. Record the URL and access date for every material claim.
4. Separate verified facts from inference.
5. Do not log in, submit forms, send messages, or purchase anything without approval.
6. Produce the final report with templates/report-template.md.

---
name: market-research
description: Research public product information and produce a cited comparison report.
---

# Market research workflow

1. Read the provided product brief and competitor list.
2. Prefer official product pages, documentation, pricing pages, and release notes.
3. Record the URL and access date for every material claim.
4. Separate verified facts from inference.
5. Do not log in, submit forms, send messages, or purchase anything without approval.
6. Produce the final report with templates/report-template.md.

Skills API 的价值不是让提示词变长，而是把方法独立出来。以后更换模型、复用到另一条工作流，或者调整报告结构时，不需要把几千字系统提示词到处复制。

根据官方文档，自定义 Skill 可以作为包含 SKILL.md 和相关资源的目录上传，并创建版本。生产环境应固定具体版本，而不是永远引用 latest，否则一次无意的模板修改就可能改变所有任务的输出。

第二步：资料只上传一次，用 file_id 在任务里复用

产品白皮书、历史报告、CSV 清单和模板都可能很大。如果每次调用都把原始文件重新上传，不仅浪费时间，也会让任务难以追踪。

Files API 的合理用法是：

1. 上传文件；
2. 在自己的任务数据库里保存 file_id、文件名、用途、版本和过期时间；
3. 后续调用引用 file_id；
4. 任务完成后下载 Agent 生成的结果；
5. 按数据保留策略删除或等待过期。

下面是一个有意简化的 Python 结构示例。它展示的是工程分层，不应被当成某个 SDK 版本的完整可运行代码：

from dataclasses import dataclass

@dataclass
class ResearchJob:
    source_file_ids: list[str]
    skill_id: str
    skill_version: str
    allowed_domains: list[str]
    require_approval_for: set[str]

job = ResearchJob(
    source_file_ids=["file_product_brief", "file_competitor_list"],
    skill_id="skill_market_research",
    skill_version="3",
    allowed_domains=["example.com", "docs.example.com"],
    require_approval_for={"login", "submit", "send", "delete", "purchase"},
)

result = run_agent(
    model="your-supported-claude-model",
    files=job.source_file_ids,
    skills=[{"id": job.skill_id, "version": job.skill_version}],
    tools=["browser_use", "computer_use"],
    policy={
        "allowed_domains": job.allowed_domains,
        "approval_required": sorted(job.require_approval_for),
        "max_steps": 40,
    },
)

save_audit_log(result.events)
download_generated_files(result.output_file_ids)

from dataclasses import dataclass

@dataclass
class ResearchJob:
    source_file_ids: list[str]
    skill_id: str
    skill_version: str
    allowed_domains: list[str]
    require_approval_for: set[str]

job = ResearchJob(
    source_file_ids=["file_product_brief", "file_competitor_list"],
    skill_id="skill_market_research",
    skill_version="3",
    allowed_domains=["example.com", "docs.example.com"],
    require_approval_for={"login", "submit", "send", "delete", "purchase"},
)

result = run_agent(
    model="your-supported-claude-model",
    files=job.source_file_ids,
    skills=[{"id": job.skill_id, "version": job.skill_version}],
    tools=["browser_use", "computer_use"],
    policy={
        "allowed_domains": job.allowed_domains,
        "approval_required": sorted(job.require_approval_for),
        "max_steps": 40,
    },
)

save_audit_log(result.events)
download_generated_files(result.output_file_ids)

接入时应以当前 Anthropic 文档和 SDK 为准。官方在 8 月 20 日宣布 Files API 正式可用、组织存储上限提高到 1 TB，并加入自动过期；但部分旧文档或旧 SDK 仍可能显示 Beta 命名、旧请求头或旧配额。迁移期间不要机械照抄历史示例。

第三步：Browser Use 优先处理网页，Computer Use 兜底

如果目标是网页应用，优先使用 Browser Use。它能利用页面结构定位字段和按钮，通常比只依赖截图坐标更稳。遇到桌面软件、远程环境或缺少结构化页面信息的场景，再使用 Computer Use。

一个实用的选择顺序是：

1. 有正式 API：优先调用 API；
2. 没有 API，但有结构化网页：使用 Browser Use；
3. 只能通过视觉界面操作：使用 Computer Use；
4. 涉及不可逆动作：转人工确认。

这能避免一个常见误区：因为模型“能点”，就让它用鼠标完成所有事情。界面自动化比直接 API 更脆弱，页面改版、弹窗、网络延迟和权限变化都会导致失败。

第四步：证据与结论必须分开保存

研究型 Agent 最容易犯的错误，不是不会浏览，而是把看到的内容、自己的推断和最终建议混在一起。

建议为每条关键结论保存以下字段：

报告正文只引用经过校验的证据；无法确认的内容放入“待验证”部分。这样即使网页后来变化，也能知道当时依据是什么。

第五步：让 Agent 交付文件，而不只是输出聊天文本

报告可以先以 Markdown 或 JSON 作为中间格式，再由 Skill 中的模板转换为 DOCX、PDF、XLSX 或演示文稿。最终文件通过 Files API 返回并下载。

这里有两个工程建议：

• 把事实数据与版式模板分开，避免改一个标题样式就重新跑完整研究；
• 对最终文件做自动检查，例如是否包含来源、是否缺少章节、表格是否为空、日期是否过期。

第六步：在不可逆动作前停住

“能完成”不是“可以自动完成”。研究 Agent 读取公开资料与生成草稿，和替用户提交表单、发送邮件、删除文件，风险完全不同。

建议把动作至少分为三档：

审批界面不要只放一个“同意”按钮。至少要显示：将执行什么动作、作用于哪个对象、会写入什么内容、是否可撤销，以及失败后如何恢复。

上生产前必须补齐的 8 个护栏

1. 最小权限

研究任务不需要支付权限，生成报告不需要删除整个目录。按任务发放最小权限和短期凭证。

2. 域名白名单

Browser Use 只访问明确允许的站点。外链跳转、短链接和下载域名需要单独检查。

3. 步数与时间上限

为单次任务设置最大步骤、最长执行时间、最大截图数和最大重试次数，防止 Agent 在异常页面循环。

4. 幂等设计

提交、写入、创建记录等动作应带唯一任务 ID。即使重试，也不能创建两份订单或发送两次消息。

5. 完整审计日志

记录模型版本、Skill 版本、文件 ID、工具调用、关键截图、审批人和最终结果。不要只保存最终回答。

6. 敏感信息处理

上传文件前做数据分类和脱敏。API Key、Cookie、身份证号、客户名单不应直接出现在提示词、截图或日志里。

7. 失败恢复

每个阶段保存检查点。网页操作失败时从最近的安全步骤重试，而不是从头执行整条流程。

8. 结果验收

对交付物设置机器可检查的标准：必填章节、来源数量、格式、文件可打开性、数字一致性以及人工抽查项。

这套组合能省多少钱？先别急着给固定比例

这次更新确实提供了几个明确的降本方向：

• 多动作回合减少 Computer / Browser Use 的模型往返；
• Skill 按任务加载，避免把所有说明永久塞进上下文；
• 文件上传一次后按 ID 复用，减少重复传输和处理；
• 标准化模板减少人工整理和返工。

Anthropic 在公告中引用客户案例称，某理赔工作流最长处理时间从 32 分钟降到 13 分钟，单任务成本下降约 30%，并在不修改提示词的情况下达到 100% 完成率。这是特定客户与工作流的结果，不能直接外推成所有项目的收益承诺。

你自己的成本应该按下面的公式评估：

单任务总成本 = 模型输入 + 模型输出 + 工具调用与执行环境
             + 文件处理 + 失败重试 + 人工审核时间

单任务总成本 = 模型输入 + 模型输出 + 工具调用与执行环境
             + 文件处理 + 失败重试 + 人工审核时间

真正应该跟踪的不是“单次 API 价格”，而是成功交付一份合格结果的总成本。

Apito 在这套架构里负责什么

Apito 可以作为第三方模型访问与成本管理层，用于统一请求地址、API Key、模型选择和调用记录。对于已经配置好的兼容客户端，通常只需要按平台说明调整 Base URL 与凭证。

但边界要说清楚：

• Apito 不是 Anthropic 官方服务；
• 它不替代 Skills API、Files API 或执行沙箱；
• Computer Use、Browser Use 等工具能力是否可用，要以所选模型、上游通道和控制台实时支持为准；
• 涉及企业数据时，仍需单独评估数据处理、日志保留、权限和合规要求。

比较合理的方式，是把模型访问层做成可替换组件。业务编排、Skill、文件治理和审批策略不要与某个单一网关写死。

从 Beta 迁移到正式版：不要漏掉这张清单

• 盘点代码中的 Beta 请求头、旧 SDK 命名和旧端点；
• 对照当前控制台确认 Computer Use、Browser Use、Skills 和 Files 的实际可用性；
• 固定 Skill 版本，并为升级保留回滚版本；
• 核对 Files 的自动过期策略、组织存储上限和数据删除流程；
• 用真实页面重新测试多动作回合，而不是只跑旧录屏；
• 检查截图、文件和工具日志是否含敏感信息；
• 为发送、发布、删除、付款和权限变更加入强制审批；
• 建立成功率、平均步骤、重试率、人工接管率和单次成功成本指标。

FAQ

1. Computer Use 和 Browser Use 应该选哪个？

网页应用优先 Browser Use；桌面软件、视觉界面或缺少结构信息的环境再考虑 Computer Use。如果目标系统有稳定 API，API 通常仍是第一选择。

2. Skills API 和普通系统提示词有什么区别？

系统提示词适合全局规则；Skill 更适合按任务加载的说明、脚本、模板和参考资料。Skill 可以单独版本化和复用，减少巨型提示词的维护成本。

3. Skills API 能代替 Files API 吗？

不能。Skill 保存的是方法和相关资源，Files API 负责业务输入、输出文件及其生命周期。两者的治理对象不同。

4. Files API 里的文件会永久保存吗？

不要默认永久保存。Anthropic 最新公告提到自动文件过期，而部分旧文档仍可能显示此前的保留逻辑。上线前应以当前账户控制台和最新文档为准，并在业务侧保存过期时间。

5. Agent 能否自动登录、提交和发布？

技术上可能可以，但不应默认授权。登录、提交、发送、删除、付款和改权限等动作应放到人工审批之后，并保留审计记录。

6. 使用 Apito 后就能直接调用全部官方工具吗？

不一定。Apito 是第三方模型访问层，具体工具支持取决于当前模型、通道与接口实现。接入前需要用最小测试任务逐项验证。

7. 第一条适合落地的 Agent 流程是什么？

从“高频、低风险、结果可验收”的任务开始，例如公开资料整理、日报生成、文档分类或报告初稿。不要第一天就让 Agent 自动付款、删除数据或向客户发送内容。

参考资料

• Anthropic：Computer Use、Skills API 与 Files API 正式可用
• Anthropic Files API 文档
• Anthropic Agent Skills 文档
• Anthropic Skills API 使用指南

如果你准备把现有 Claude 应用从“能回答”升级到“能交付”，可以先在 Apito 验证模型访问、调用记录和成本，再按本文的 Skill、工具、文件与审批四层逐步搭建；上线前务必逐项确认所选通道对官方工具的实际支持情况。