三种执行方式

一句话理解：Agent 作用于世界有三条路：调接口、操作界面、在沙箱里写代码跑。能走接口就不点界面，能写代码算就不让模型心算。

前面几个模块讲了模型怎么“想”、工具怎么“定义”。但当 Agent 真要动手时，还有一个经常被忽略的问题：它在哪里、通过什么方式动手？ 同样是“查一下这个客户的账号为什么没开通”，可以调用户系统的 API，可以打开 SaaS 后台一页页点，也可以把导出的数据丢进沙箱写段 Python 算。三种做法的速度、稳定性、成本和风险差别巨大。

不懂这一课，常见的坑有两个：一是明明有 API，却因为“Computer Use 看起来更酷”而让 Agent 去点网页，结果慢十倍、错误率高；二是让模型直接“读”几万行数据得出结论，而不是让它写代码去算，结果数字全是编的。

先用一张全景图把本模块串起来：任务中的每一步从哪条路动手、每条路要防什么，以及 Agent 在哪里运行、如何与脚本分工。

三种执行方式

方式	Agent 怎么动手	优势	劣势	典型场景
API / 工具调用	调用结构化接口（REST、MCP、SDK），拿回 JSON	快、稳定、可校验、易审计	需要对方提供接口，覆盖面有限	查 CRM 客户、查库存、发通知、建工单
浏览器与计算机操作	读取页面或截图，模拟点击和输入	能覆盖没有 API 的系统	慢、脆弱、易受页面变化与注入影响	老旧的后台管理系统、只有网页端的订票网站
沙箱中的代码执行	写代码，在隔离环境中运行，读回输出	精确计算、处理大数据、可复现	需要隔离环境，代码本身可能出错或越权	销售数据分析、日志排查、Coding Agent 改代码跑测试

这三种方式不是互斥的，一个成熟的 Agent 往往同时具备，并且在每一步 选最合适的那一种。

用一个比喻：API 是“打电话给对方的系统直接下单”，浏览器操作是“派个人去对方柜台排队填表”，沙箱代码执行是“在自己的草稿纸上用计算器算清楚”。

同一个任务，三种做法

任务：诊断公司官网上周自然流量下降的原因（SEO 诊断场景）。

• API 方式：调用搜索平台的数据接口，拉取过去四周的曝光、点击、排名数据；调用站点监控接口，拿到上周的 5xx 错误数与发布记录。
• 浏览器方式：打开几个关键落地页，检查页面标题、canonical、结构化数据是否在最近一次发布后被改坏；这些信息在渲染后的页面上最直观。
• 沙箱代码方式：把几万行关键词数据导入沙箱，用 Python 按页面分组、计算环比、找出跌幅最大的 20 个 URL，并画出趋势图。

一个好的 Agent 会这样组合：先用 API 拉数据 → 在沙箱里算出跌幅集中在哪些页面 → 再用浏览器打开这几页确认页面本身出了什么问题 → 最后生成报告。反过来，如果让它用浏览器翻几十页报表、再让模型“目测”环比，结论几乎不可信。

把这条组合路线画出来：

选择顺序：从最精确到最宽泛

一个实用的默认顺序是：

这不是纸上谈兵。以 Claude Code 的官方文档为例，它在说明计算机操作能力时明确写道：有对应的 MCP Server 就用 MCP，是 Shell 命令就用 Bash，是浏览器任务且配置了浏览器扩展就用浏览器，只有这些都不适用时才去控制屏幕，因为屏幕操作是 覆盖面最广、也最慢 的方式。

背后的原则是：越往下，覆盖面越大，但确定性越低、成本越高、攻击面越大。

维度	API	沙箱代码	浏览器	Computer Use
单步速度	毫秒到秒	秒	秒到十几秒	每个动作都要截图、推理一轮
结果可校验性	高（结构化返回）	高（程序输出）	中	低（要靠截图判断）
对界面改版的敏感度	无	无	高	高
暴露给不可信内容的程度	低	取决于输入数据	高（整个网页）	高（整个屏幕）

执行方式决定了安全要求

选定执行方式，其实也就选定了要防什么：

• API：重点是工具设计与权限——Agent 能调哪些接口、参数能不能被篡改、令牌作用域多大。见 安全的工具设计 与 最小权限与凭据管理。
• 沙箱代码：重点是隔离——代码能读写哪些文件、能不能联网、能不能拿到宿主机上的凭据。见 沙箱。
• 浏览器 / Computer Use：重点是不可信内容和真实后果——网页上的一段隐藏文字可能诱导 Agent，点下“提交”可能就是一笔真实的付款。见 浏览器 Agent 与 Prompt 注入。

以一个「客户续约跟进 Agent」为例：查询 CRM 里的客户与合同状态走内部 API；分析一个季度的续约率分布走沙箱代码；某个第三方采购系统只提供网页后台、没有接口，这一步才用浏览器——而且只读，不允许在后台里提交任何表单。

常见误区

• “Computer Use 能做一切，所以统一用它。” 能做不等于该做。它是兜底方案，用在没有其他路可走的地方。
• “让模型直接读数据，省得写代码。” 模型擅长决定“算什么”，不擅长亲自算。数量一大，就该交给沙箱里的程序。
• “执行方式是工程细节，产品不用管。” 执行方式直接决定任务耗时、成功率、单次成本和需要的审批强度，这些都是产品指标。

产品经理检查清单

• 任务里的每一步，涉及的系统有没有 API？没有的话，能不能推动对方提供，或者先用导出文件替代？
• 哪些步骤本质是计算或批量处理，应该交给代码而不是模型？
• 哪些步骤不得不操作界面？这些步骤是只读还是会产生真实后果？
• 每种执行方式对应的失败率和耗时，有没有在 Demo 之外测过？
• 如果界面改版或接口下线，Agent 的哪一步会先坏？

练习

选一个你熟悉的业务任务（比如“核对本月 SaaS 订阅账单与 CRM 里的合同金额是否一致”），用 30 分钟完成：

1. 把任务拆成 5–8 步。
2. 给每一步标注执行方式：API、沙箱代码、浏览器、Computer Use。
3. 对标注为浏览器或 Computer Use 的步骤，写下“如果有 API，这一步会变成什么样”。

步骤	涉及系统	执行方式	为什么	替代方案
例：下载 SaaS 供应商月度账单	供应商后台（无 API）	浏览器（只读）	只有网页端	推动对方提供 SFTP 每月推送

延伸阅读

• Claude Code：Let Claude use your computer from the CLI——其中“When computer use applies”一节说明了工具的选择顺序。

下一步

下一课「沙箱」会打开第三种执行方式的黑盒：Agent 写的代码到底跑在哪里，为什么 Coding Agent 离不开隔离。