通用内置工具
搜索、代码执行、文件读写、浏览器与计算机操作。
一句话理解：搜索、网页抓取、代码执行、文件读写、终端、浏览器与计算机操作，是几乎所有 Agent 都需要的“通用手脚”。平台往往直接提供，你要做的是选对、配好边界，而不是从零再造。
前几课讲的都是自定义工具：get_order、get_payment 这类连接你自家业务系统的能力。但一个真正好用的 Agent 往往还需要一些通用能力：查一下最新资料、跑一段 Python 算个数、读写文件、打开网页看看。
这些能力有两个特点：通用（几乎每个 Agent 都用得上），难做好（搜索要处理引用，代码执行要沙箱，浏览器要处理登录态与反自动化）。所以主流模型平台都把它们做成了内置工具。
内置工具的全景
| 类别 | 解决什么问题 | 典型场景 | 主要风险 |
|---|---|---|---|
| 网页搜索 | 获取训练截止之后的信息，带来源引用 | 竞品动态、SEO 关键词趋势、政策变化 | 搜到低质量或被投毒的页面 |
| 网页抓取 | 读取指定 URL 或 PDF 的完整内容 | 读官方文档、分析竞品落地页 | 页面里的间接注入 |
| 代码执行 | 在沙箱里运行代码做计算、数据分析、生成文件 | 销售数据透视、画图表、清洗 CSV | 资源滥用、数据外泄 |
| 文件读写 / 文本编辑 | 查看、创建、修改文件 | Coding Agent 改代码、生成报告 | 误改、误删文件 |
| 终端（Shell） | 执行命令行 | 跑测试、装依赖、Git 操作 | 破坏性命令、越权访问 |
| 浏览器操作 | 导航、点击、填表、读取页面状态 | 没有 API 的后台系统、网页流程 | 登录态滥用、误提交 |
| 计算机操作 | 截屏、移动鼠标、敲键盘 | 只有桌面客户端的老系统 | 速度慢、可靠性低、误操作 |
| 工具搜索 | 从大量工具中按需加载相关工具 | 连接了几十个系统的企业 Agent | 检索不到该用的工具 |
| 记忆 | 跨会话存取信息 | 记住用户偏好、项目约定 | 记错、隐私 |
后四类的执行环境问题（沙箱、登录态、可靠性、成本）在 执行环境 模块里有专门的课时，记忆见 长期记忆。本课关注“作为工具”该怎么选、怎么配。
关键区别：工具在哪里执行
同样叫“内置工具”，执行位置可能完全不同。以 Claude API 为例，官方文档把工具分为两类：
OpenAI 的平台同样提供网页搜索、文件搜索、Shell、计算机操作、图片生成、工具搜索、远程 MCP 等内置工具，其中 Shell 既可以跑在托管容器里，也可以跑在你自己的运行环境中。
执行位置决定了三件事：
| 维度 | 平台执行 | 你来执行 |
|---|---|---|
| 开发量 | 声明即用 | 要实现执行逻辑，但 Schema 由平台定义，模型已经训练过 |
| 数据位置 | 数据经过平台基础设施 | 数据留在你的环境里 |
| 控制力 | 能配的参数有限（如搜索次数上限、域名过滤） | 完全掌控：沙箱、权限、审计、确认 |
| 计费 | Token 之外可能按次收费（如每次搜索） | 只付 Token，但执行成本自担 |
“平台定义 Schema、你来执行”的工具很有意思：模型针对这些工具做过专门训练，调用质量往往比你自定义一个同类工具更高，而执行权仍在你手里。Coding Agent 普遍采用这种模式。
怎么选：内置、自定义还是 MCP
判断顺序可以是：
- 这是通用能力还是业务能力？ 查订单、查支付是业务能力，只能自己做（自定义工具或 MCP Server）。搜索、执行代码是通用能力，优先考虑内置。
- 数据能不能离开你的环境？ 涉及客户隐私或内部代码时，优先选择客户端执行的工具，或部署在自己环境里的方案。
- 需要多强的控制？ 需要细粒度权限、审计、审批的，自己执行更合适。
- 要不要跨多个 Agent 产品复用？ 要复用就做成 MCP Server，见 为什么需要 MCP。
三个贯穿场景的组合示例：
| Agent | 内置工具 | 自定义 / MCP 工具 |
|---|---|---|
| SEO 诊断 | 网页搜索、网页抓取、代码执行（分析抓取结果） | audit_page、get_ranking_change（对接站长数据） |
| 销售分析 | 代码执行（透视与画图） | query_sales（只读视图，限定字段） |
| Coding Agent | 文件读写、终端、网页抓取 | 连接工单系统、CI 的 MCP Server |
| 订单售后诊断 | 基本不需要 | get_order、get_payment、search_tickets |
注意最后一行：不是每个 Agent 都需要搜索和代码执行。 订单售后诊断的事实全部来自内部系统，开放网页搜索只会引入噪音，还多了一个注入入口。工具的原则是按需开放。
配置边界：内置工具同样要管
内置工具开箱即用，不代表可以不设边界：
- 搜索与抓取：限制次数上限，必要时配置允许或屏蔽的域名；要求回答带引用；把网页内容当作不可信数据（见 Prompt 注入）。
- 代码执行：在隔离沙箱中运行，限制网络访问、运行时长与资源，见 沙箱。
- 文件与终端：限定工作目录；删除、强制推送、安装依赖等命令需要确认；危险命令列入黑名单。Coding Agent 的权限模式就是在做这件事，拆解见 Claude Code。
- 浏览器与计算机操作：只在没有 API 时使用；提交、支付、发送类操作必须确认；尽量不要让 Agent 持有高权限账号的登录态，见 浏览器 Agent 与 Computer Use。
一个经验法则：能用 API 就不用浏览器，能用浏览器就不用计算机操作。 越往后越通用，也越慢、越贵、越不可靠。
三种方式的取舍可以放在一条轴上看：
常见误区
- “内置工具越多，Agent 越聪明。” 每多开放一个工具，就多一份工具定义的 Token、多一个选错的可能、多一个攻击面。
- “有了浏览器操作，就不用对接 API 了。” 浏览器操作适合补位。高频、核心的业务动作，一定要有稳定的 API 或 MCP 工具。
- “平台执行的工具，安全问题归平台管。” 平台负责执行环境的隔离，但搜到什么内容、这些内容如何影响后续动作，仍然是你的产品要负责的。
产品经理检查清单
- 这个 Agent 真的需要搜索、代码执行、浏览器这些能力吗？各自服务哪一步？
- 每个内置工具在哪里执行？数据会不会离开我们的环境？合规上是否允许？
- 按次计费的工具设置了次数上限吗？单任务成本估算过吗？
- 文件、终端、浏览器类工具的操作范围和确认规则是什么？
- 外部内容（网页、搜索结果）进入上下文后，能不能触发发送、写入类工具？
练习
为一个“竞品 SEO 周报 Agent”做工具选型（30 分钟）：
- 列出它每周要完成的步骤：找竞品新页面、抓取页面内容、分析标题与关键词变化、生成图表、写周报。
- 为每一步选择工具：内置（写明是平台执行还是自己执行）、自定义，还是不需要工具。
- 为你选中的每个内置工具写一条边界规则，比如“网页抓取仅限竞品域名列表”。
延伸阅读
- Tool use with Claude：客户端工具与服务端工具的区别，以及内置工具目录与计费说明。
- Using tools（OpenAI）：OpenAI 平台可用的内置工具总览。
下一步
概念都齐了，下一课「实操：做一个 Tool Agent」动手写一个天气 Agent，完整走一遍工具定义、调用、回填与回答。