Anthropic 最近把 Computer Use、Skills API、Files API 一起推向正式可用，并新增 Browser Use。单看功能并不难理解：Agent 可以读取文件、按需加载流程、识别页面结构并操作软件，最终返回文件或系统结果。

真正难的是下一步：团队应该先把什么任务交给它？

如果一开始就让 Agent 做战略判断、复杂审批或不可逆操作，系统很容易陷入一个怪圈：自动化做了一半，人工为了核对上下文和补救异常，反而投入更多时间。

1. 先把“Agent 会什么”拆成四个运行时组件

Anthropic 官方给出的理赔示例是一个很好的最小闭环：

Files API 读取材料
  -> Skill 加载团队处理流程
  -> Browser Use 填写保险门户
  -> 保存确认文件

这段流程里至少包含四类状态：

输入状态：任务资料是否完整
过程状态：步骤和规则是否明确
环境状态：页面、权限和登录态是否可用
完成状态：文件或页面能否证明任务完成

模型推理只负责其中一部分。生产级 Agent 还需要把上下文、方法、工具和验收串起来。否则“调用成功”并不等于“业务完成”。

官方资料：https://claude.com/blog/computer-use-skills-api-files-api

2. 首批任务的四个筛选条件

我会用四个条件做第一轮过滤。

2.1 高频

每周甚至每天发生的任务，才值得为它建立稳定流程。低频任务可以继续让通用 Agent 临时辅助，没必要过早工程化。

2.2 有边界

输入、步骤和输出能写成一页工作说明。比如“根据产品资料生成三个平台的差异化稿件，并预填标题、正文、摘要、标签和封面”，边界就比“把账号运营好”清楚得多。

2.3 可回读

执行后必须能重新读取页面或文件确认状态。浏览器自动化尤其不能把“click 没报错”当成发布成功。更可靠的验收是成功页、作品管理记录、文章链接或明确的审核状态。

2.4 可撤销

首批任务优先选择草稿、预填、整理、汇总等可修改操作。公开发布、付款、删除、权限变更等高风险动作应设置人工确认或单独授权。

3. 用“任务合同”替代一句自然语言指令

生产任务不要只传一句“帮我发文章”。至少应该包含下面这份任务合同：

goal: 将一个母题改写并预填到三个内容平台
inputs:
  - 产品资料
  - 事实来源
  - 历史文章
rules:
  - 三个平台不得原样复制
  - 动态事实发布当天核验
  - 标题与标签遵守平台限制
approval:
  - 公开发布前确认
acceptance:
  - 标题、正文、两张图片、摘要、标签均可回读
  - 提交后取得成功页或作品记录
fallback:
  - 验证码或风控出现时保留草稿并停止

这份合同把“怎么做”和“何时算完成”从模型的临场猜测里拿出来。Skill 可以承载稳定流程，Files 可以保存材料和产物，Computer/Browser Use 负责与真实软件交互；应用层还要负责权限、重试、日志与人工闸门。

4. 五类适合小团队先落地的工作

1. 资料归档：整理产品资料、历史内容、FAQ，保留来源。
2. 固定格式加工：会议纪要、商品字段、平台稿件适配。
3. 跨系统预填：把已审核字段填写到后台，等待最终确认。
4. 周期巡检：定时收集数据和异常，输出候选事项。
5. 发布前准备：研究、写作、配图、排版、标签和封面检查。

这些任务共同点不是“简单”，而是可描述、可观察、可回退。它们更容易建立评测集，也更容易算清 Agent 到底节省了什么。

5. 岗位化不是限制模型，而是限制上下文污染

一个通用 Agent 可以临时调用大量工具，但如果同一个上下文同时承载内容运营、视频制作、数据分析和电脑维护，工具选择、权限和规则都会变复杂。

这也是我们做 Tipkay 时采用岗位化助手的取舍。博客发布、内容运营、视频制作等助手分别配置自己的流程、Skill/MCP、品牌资料和素材；需要时可以复制成专属版本，再用定时任务持续运行。通用能力仍然存在，但稳定任务由对应岗位负责。

从工程角度看，这不是为了让模型“变笨”，而是缩小每次执行的状态空间：更少的无关工具、更明确的输入、更固定的检查项，以及更可控的权限。

6. 第一周应该测什么

不要先看一次演示是否顺利，至少记录：

• 任务完成率，而不是工具调用成功率；
• 人工接管次数与接管位置；
• 每次失败是否能保留中间产物；
• 结果回读能否发现误填和漏填；
• 同类任务重复运行时，风格与字段是否稳定。

模型更强当然重要，但生产 Agent 的分水岭往往不是又多会了一个功能，而是能否把一段工作变成可验证、可恢复、可持续运行的交付链。