工具调用入门：AI Agent如何连接浏览器、表格、数据库、邮箱和API

摘要： 让AI安全接上工具

关键词： AI工具调用、Function Calling、Agent工具、MCP、SP-API、跨境电商AI

系列定位： AI Agent完整教程，第 05 篇

核心观点： 工具调用不是让 AI 随便操作你的电脑，而是把浏览器、表格、数据库、邮箱、ERP 和 API 做成有名称、有参数、有权限、有返回值、有日志、有人工确认的可控接口。

---

很多卖家用 AI 用到一定阶段，都会遇到同一个瓶颈：

AI 会写，但不知道真实数据。

它能帮你写 Listing，但不知道你产品的真实尺寸、材质和禁用词。

它能分析广告，但不知道你过去 30 天的 Search Term 报表和毛利底线。

它能写客服回复，但不知道订单状态、保修规则和当前站点的售后 SOP。

它能给你一堆“优化建议”，但这些建议很容易变成漂亮废话。

问题不在于模型不会表达。

问题在于模型没有接上工具。

工具调用的本质，是让 AI 从“只能回答”变成“可以在受控范围内读取数据、调用系统、生成文件、发起待确认动作”。

但这里有一个关键前提：

工具调用不是给 AI 一把万能钥匙。

不是让它直接登录卖家后台乱点。

不是把 API key 放进提示词。

不是让它自动调价、自动否词、自动发邮件。

工具调用真正成熟的做法，是把每个工具设计成一个受控接口：能做什么、需要哪些参数、返回什么结果、是否只读、是否需要审批、失败怎么处理、日志怎么记录。

这篇文章不讲空泛概念，只讲卖家团队怎么设计第一套 Agent 工具清单。

一句话理解工具调用

你可以把工具调用理解成“AI 填工单”。

普通聊天 AI 只能说：

“你应该查一下库存。”

有工具调用的 Agent 可以说：

“我要调用 query_inventory 工具，参数是 SKU=A123，站点=US，时间=今天。”

系统执行这个查询，把结果返回给 Agent。

Agent 再根据结果继续判断：

库存充足，就分析广告。

库存不足，就提醒运营不要加预算。

库存数据缺失，就停止并要求人工补资料。

OpenAI Function calling 文档把这个机制讲得很清楚：function calling 让模型连接外部系统和训练数据之外的数据，模型可以请求调用工具，应用执行工具后把结果回传给模型。

这就是 Agent 能“做事”的基础。

但注意：模型本身不是在你的数据库里直接乱查。

模型只是提出一个结构化工具请求。

真正执行的是你控制的应用、后端、连接器或 MCP server。

所以工具调用的安全性，取决于你怎么定义工具。

工具调用和普通提示词有什么区别

普通提示词是自然语言。

比如：

帮我查一下 SKU A123 的库存，如果低于 20 件就提醒我。

这句话对人来说很好懂，但对系统来说不稳定。

它不知道库存在哪个表。

不知道 SKU 字段叫什么。

不知道“低于 20”是 FBA 可售库存、总库存，还是含在途库存。

也不知道提醒发到哪里。

工具调用会把这件事拆成结构化接口：

{
  "tool": "query_inventory",
  "arguments": {
    "sku": "A123",
    "marketplace": "US",
    "inventory_type": "fba_available"
  }
}

工具返回：

{
  "sku": "A123",
  "marketplace": "US",
  "fba_available": 16,
  "inbound": 80,
  "last_updated": "2026-07-07 09:00:00"
}

Agent 再判断：

“FBA 可售库存 16，低于阈值 20；但在途 80，需要确认预计入仓时间。建议暂停加预算，只保留品牌词投放。”

这就是工具调用和普通提示词的差别。

普通提示词靠模型自由理解。

工具调用靠结构化接口拿真实结果。

工具调用不是一种工具，而是一套连接方式

截至 2026-07-07，官方资料里常见的工具调用形态包括几类。

OpenAI tools 文档把能力扩展分成内置工具、function calling、tool search、remote MCP servers 等方式。内置工具可以包括 web search、file search、computer use、code interpreter 等；function calling 可以连接你自己的函数；MCP 和 connectors 可以连接外部服务。

MCP 官方文档则把 MCP 描述为连接 AI 应用与外部系统的开源标准，能连接数据源、工具和工作流。

对卖家来说，不需要一开始记住所有技术名词。

你只要先分清四种连接：

1. 内置工具

比如网页搜索、文件检索、代码解释器、浏览器、计算环境。

适合：

• 查公开资料。
• 读 PDF。
• 分析 CSV。
• 生成报告。
• 处理临时文件。

风险：

• 公开网页可能变化。
• 文件可能包含敏感信息。
• 浏览器行动可能触发登录、提交、付款等高风险动作。

2. 自定义函数

你自己定义工具，例如：

• query_inventory
• read_ads_report
• get_product_specs
• classify_reviews
• create_weekly_report

适合：

• 查询内部数据。
• 调用 ERP。
• 读取数据库。
• 生成固定格式报告。

风险：

• 参数定义不清会误调用。
• 权限过大可能造成数据泄露或错误写入。

3. MCP / Connector

把外部系统用统一协议或连接器暴露给 AI 应用。

适合：

• 文件系统。
• 数据库。
• 内部工具。
• 第三方 SaaS。
• 多工具统一接入。

风险：

• 接入方便也意味着权限管理更重要。
• MCP server 配置错误，可能暴露不该暴露的资源或工具。

4. 业务 API

比如 Amazon SP-API、广告 API、ERP API、CRM API、客服系统 API。

适合：

• 查询订单。
• 查询库存。
• 读取报表。
• 获取 Listing 状态。
• 创建或上传文件。

风险：

• API 通常有角色、授权和速率限制。
• 写入类 API 可能直接影响店铺。
• 密钥和 token 不能交给模型。

卖家最该先接的 6 类工具

第一次做 Agent，不要把所有工具都接上。

先从只读工具开始。

第一类：产品资料工具

作用：

读取产品参数、材质、尺寸、包装、适配范围、说明书、认证资料。

适合 Agent：

• Listing Agent。
• 客服 Agent。
• A+ 文案 Agent。
• 图片脚本 Agent。

工具设计示例：

{
  "name": "get_product_specs",
  "description": "根据 SKU 查询产品基础资料，只读。",
  "input": {
    "sku": "string",
    "marketplace": "string"
  },
  "output": {
    "title": "string",
    "dimensions": "string",
    "materials": "string",
    "compatible_models": "array",
    "warnings": "array",
    "last_updated": "datetime"
  },
  "permission": "read_only",
  "human_approval": false
}

关键要求：

产品参数必须来自工具返回。

Agent 不能自己编。

第二类：广告报表工具

作用：

读取 Search Term、Campaign、Targeting、Placement 等报表。

适合 Agent：

• 广告周报 Agent。
• 关键词诊断 Agent。
• 预算异常 Agent。

工具设计示例：

{
  "name": "read_ads_report",
  "description": "读取指定时间范围的广告报表，只读。",
  "input": {
    "marketplace": "string",
    "date_start": "date",
    "date_end": "date",
    "report_type": "search_term | campaign | targeting"
  },
  "output": {
    "rows": "array",
    "fields": "array",
    "generated_at": "datetime"
  },
  "permission": "read_only",
  "human_approval": false
}

关键要求：

Agent 负责解释异常。

计算指标最好由脚本或报表工具完成。

第三类：库存工具

作用：

查询 FBA 可售库存、在途、预留、补货周期。

适合 Agent：

• 广告 Agent。
• 选品 Agent。
• 补货提醒 Agent。

为什么广告 Agent 需要库存？

因为一个关键词 ACOS 高，不一定是广告问题。

如果 SKU 快断货，系统表现、转化率和投放策略都要重新判断。

工具返回必须区分：

• FBA 可售。
• 在途。
• 预留。
• 本地仓。
• 更新时间。

第四类：评论和客服工具

作用：

读取评论导出、客服工单、退换货原因、FAQ、售后 SOP。

适合 Agent：

• 评论归因 Agent。
• 客服草稿 Agent。
• 产品改良 Agent。

风险：

客服数据可能包含个人信息。

应先脱敏，至少去掉姓名、地址、电话、邮箱、订单号等敏感字段，除非在企业受控环境里处理。

第五类：文件和知识库工具

作用：

读取 SOP、说明书、品牌规则、图片规范、历史复盘。

OpenAI file search 文档说明，模型可以在生成回答前，从上传文件知识库中检索相关信息。MCP resources 也提供了标准方式让服务器暴露文件、数据库 schema 或应用上下文等资源。

适合 Agent：

• SOP 问答。
• Listing 审核。
• 客服回复。
• 培训材料生成。

关键要求：

知识库资料必须有版本。

过期 SOP 不要混在默认检索里。

第六类：通知和待办工具

作用：

把 Agent 的结果发给负责人，创建待确认任务。

适合：

• 广告异常待处理。
• 客服升级。
• Listing 修改审核。
• 竞品异常提醒。

注意：

通知工具可以自动执行。

但“真正业务动作”不要自动执行。

比如可以自动创建“请确认是否否定关键词”的任务，但不要自动否定关键词。

工具要分级：只读、草稿、待确认写入、禁止

工具调用最大的风险，不是工具不够强，而是权限分级不清。

卖家团队可以把所有工具分成四级。

级别	工具类型	例子	默认策略
L1	只读工具	读取产品资料、广告报表、库存表、知识库	可以先开放
L2	草稿工具	生成 Listing 草稿、客服回复草稿、周报	自动生成，人工审核
L3	待确认写入	创建任务、提交待审批广告调整、生成后台修改草稿	必须人工确认
L4	禁止自动执行	改价、退款、补发、删除文件、直接提交 Listing、直接发客服邮件	默认禁止

这个分级比“要不要用 AI”更重要。

例如广告 Agent 可以读取广告报表，这是 L1。

它可以生成否词建议，这是 L2。

它可以创建待确认任务，这是 L3。

但它不应该默认直接否词，这是 L4。

除非你已经有非常严格的规则、日志、审批和回滚机制。

工具参数怎么设计：少而清楚

一个工具是否好用，关键看参数。

参数太少，Agent 无法准确调用。

参数太多，Agent 容易填错。

好的工具参数应该满足 5 条。

1. 字段名称清楚

不要用 id、type、value 这种模糊字段。

用：

• sku
• asin
• marketplace
• date_start
• date_end
• report_type
• approval_required

2. 枚举值明确

比如 report_type 不要让模型自由写。

应该限定为：

• search_term
• campaign
• targeting
• placement

3. 时间范围必须明确

不要让 Agent 默认“最近”。

写清：

• 过去 7 天。
• 过去 30 天。
• 上周自然周。
• Prime Day 活动期。

4. 返回值带来源

工具返回不要只有结果。

还要有：

• 数据来源。
• 生成时间。
• 字段说明。
• 是否完整。
• 缺失字段。

5. 错误要结构化

工具失败时不要让模型猜。

返回：

{
  "ok": false,
  "error_code": "MISSING_FIELD",
  "message": "Search Term report 缺少 Orders 字段",
  "suggested_action": "请重新导出包含 Orders 字段的报表"
}

Agent 看到错误后，应该停止并提醒人补数据。

不是继续编结论。

一个完整工具说明应该包含什么

每个工具都应该写成一张工具卡。

下面是模板。

字段	要写什么
工具名称	英文短名，例如 read_ads_report
工具用途	一句话说明用来做什么
使用场景	哪些 Agent 可以用
输入参数	字段、类型、是否必填、枚举范围
返回字段	返回什么数据，是否带来源
权限等级	只读、草稿、待确认写入、禁止自动执行
是否需要人工确认	是/否，什么情况下需要
失败处理	缺字段、超时、无权限、数据为空时怎么办
日志字段	记录谁调用、参数、结果、时间、错误
安全注意	是否涉及隐私、密钥、客户数据、财务数据

一个没有工具卡的工具，不要给 Agent 用。

因为你后面一定会不知道它为什么调用错。

跨境电商里的典型工具清单

下面给一个卖家团队的第一版工具清单。

Listing Agent 工具

只读工具：

• get_product_specs：读取产品参数。
• get_brand_rules：读取品牌口径和禁用词。
• read_keyword_list：读取关键词清单。
• read_review_summary：读取评论归因结果。
• retrieve_listing_sop：检索 Listing SOP。

草稿工具：

• draft_listing_copy：生成标题、五点、描述草稿。
• draft_image_script：生成图片文案脚本。

禁止工具：

• 自动提交 Listing。
• 自动使用竞品商标。
• 自动写未经证实的认证和功效承诺。

广告 Agent 工具

只读工具：

• read_ads_report
• query_inventory
• read_margin_table
• read_promotion_calendar
• read_listing_change_log

草稿工具：

• draft_ads_actions
• create_weekly_ads_report

待确认写入：

• create_approval_task

禁止工具：

• 自动调预算。
• 自动调竞价。
• 自动否定关键词。

客服 Agent 工具

只读工具：

• retrieve_customer_service_sop
• get_product_faq
• get_order_status_masked
• get_return_policy

草稿工具：

• draft_customer_reply

待确认写入：

• create_escalation_task

禁止工具：

• 自动退款。
• 自动补发。
• 自动引导评价。
• 自动承诺超出政策的赔偿。

竞品监控 Agent 工具

只读工具：

• read_competitor_snapshot
• read_price_history
• read_review_export
• read_keyword_rank_snapshot

草稿工具：

• create_competitor_weekly_report
• draft_listing_response_plan

禁止工具：

• 照抄竞品文案。
• 基于单次抓取直接做长期结论。

Amazon SP-API 接入时要特别谨慎

很多卖家听到工具调用，第一反应是：

能不能直接接 Amazon SP-API？

可以，但要谨慎。

Amazon SP-API 官方文档明确有角色、授权、用量计划和速率限制。Reports API 教程也要求获得 selling partner 授权，并且 developer profile 和应用注册页面要具备对应角色。也就是说，SP-API 不是随便给 AI 一个 token 就能用。

对卖家团队来说，SP-API 工具设计要遵守几条原则。

1. 密钥不进提示词

API key、refresh token、access token、seller ID，不要写进提示词、文章、共享文档。

这些应该放在后端、环境变量或受控密钥管理系统里。

Agent 只能请求工具。

工具由后端带着授权去执行。

2. 先接 Reports，后接写入

第一阶段更适合接只读报表：

• 广告报表。
• 库存报表。
• 订单汇总。
• Listing 状态。

先让 Agent 读数据、做分析、出建议。

不要一开始就让它调用写入接口。

3. 尊重速率限制

SP-API 有 usage plans 和 rate limits。

如果 Agent 在循环中频繁调用 API，可能触发限制，也可能增加成本和失败率。

所以工具要设置：

• 最大调用次数。
• 缓存策略。
• 重试规则。
• 超时处理。
• 批量查询限制。

4. 写入动作必须审批

涉及 Listing、库存、订单、配送、价格、广告调整的动作，都要进入人工审批。

Agent 可以生成 JSON 草稿或待办任务。

但正式提交前必须有人确认。

工具调用流程：一次完整调用应该怎么跑

一个成熟工具调用流程，应该像这样：

1. 用户提出任务。
2. Agent 判断需要哪些工具。
3. Agent 输出计划。
4. 系统检查工具权限。
5. 低风险只读工具自动执行。
6. 工具返回结构化结果。
7. Agent 判断结果是否足够。
8. 如果缺资料，停止并要求补充。
9. 如果需要高风险动作，生成待确认清单。
10. 人工确认后，系统执行写入工具。
11. 全程记录日志。
12. 最终输出报告。

这个流程看起来麻烦，但它能避免最常见的事故：

• Agent 调了不该调的工具。
• 参数填错。
• 工具返回失败后模型继续编。
• 没有人知道它用了什么数据。
• 高风险动作被自动执行。

失败处理比成功调用更重要

工具调用在演示里通常很顺。

真实业务里，失败才是常态。

常见失败包括：

• 文件不存在。
• 报表字段缺失。
• API 超时。
• 无权限。
• 数据为空。
• 日期范围错误。
• SKU 不存在。
• 工具返回格式变化。
• 速率限制。

一个好的 Agent，必须知道失败时该停。

例如广告 Agent 读取报表失败，不能继续说：

“根据经验，高 ACOS 可能来自关键词不精准。”

它应该说：

“Search Term 报表读取失败，缺少 Orders 字段，无法计算转化和 ACOS。请重新导出包含 Orders 字段的报表。”

这才是商业可用。

AI 最危险的不是不知道。

最危险的是不知道还继续说。

可复制提示词：设计一个 Agent 工具清单

你是我的跨境电商 AI Agent 工具架构顾问。

我要设计一个业务 Agent。

业务场景：
[例如：广告周报 / Listing改版 / 客服回复 / 竞品监控 / 选品研究]

目标：
[一句话写清楚这个 Agent 最终要输出什么]

可用数据：
1. [数据1]
2. [数据2]
3. [数据3]

可能涉及的系统：
[例如：表格、文件夹、ERP、Amazon SP-API、广告报表、客服系统、邮箱、飞书/企业微信]

风险限制：
[例如：不能自动改价、不能自动发邮件、不能自动提交Listing、不能读取客户隐私]

请帮我设计工具清单，按以下格式输出：

1. 工具总览表。
2. 每个工具的名称、用途、输入参数、返回字段。
3. 权限等级：只读 / 草稿 / 待确认写入 / 禁止自动执行。
4. 是否需要人工确认。
5. 工具失败时怎么处理。
6. 日志需要记录什么。
7. 哪些密钥或敏感数据不能暴露给模型。
8. 第一版 MVP 只接哪些工具。
9. 后续什么时候可以增加写入工具。

要求：
- 不要建议一开始全自动。
- 所有高风险动作只生成待确认清单。
- 如果某个工具参数不清楚，请先列出需要我补充的字段。

第一周落地 SOP：给广告 Agent 接第一批工具

第 1 天：定义只读工具

先接：

• read_ads_report
• query_inventory
• read_margin_table
• read_promotion_calendar

不要接：

• 调预算。
• 调竞价。
• 否词。

第 2 天：定义参数和返回值

把每个工具写成工具卡。

特别注意：

• 日期范围。
• 站点。
• SKU / ASIN。
• 报表类型。
• 字段说明。
• 数据更新时间。

第 3 天：写失败处理

规定：

• 缺字段就停止。
• 无权限就提醒负责人。
• API 超时最多重试 2 次。
• 数据为空要说明原因，不许猜。
• 速率限制时进入等待或缓存。

第 4 天：设计输出模板

广告 Agent 输出必须包括：

• 异常类型。
• 触发数据。
• 可能原因。
• 建议动作。
• 证据字段。
• 人工确认点。

第 5 天：用历史报表测试

拿 4 周历史广告报表测试。

看 Agent 是否：

• 正确读取字段。
• 正确引用数据。
• 没有编造原因。
• 没有直接输出“自动执行”。

第 6 天：加入通知工具

可以加入：

• create_approval_task
• send_internal_notification

但通知内容只能是“请确认”，不能直接执行业务动作。

第 7 天：复盘并固化

记录：

• 哪些工具调用成功。
• 哪些参数经常填错。
• 哪些报表字段容易缺。
• 哪些建议需要人工否决。
• 下一版是否需要接知识库或更多报表。

工具调用验收标准

一个工具调用型 Agent，至少要满足 10 条。

1. 每个工具都有工具卡。
2. 工具有权限分级。
3. 参数字段清楚，有类型和枚举。
4. 返回值带数据来源和更新时间。
5. 工具失败时返回结构化错误。
6. 密钥和 token 不进入提示词。
7. 高风险动作默认人工确认。
8. 调用过程有日志。
9. Agent 输出引用工具结果。
10. 下次可以复用，不是一次性演示。

如果做不到这些，就不要把工具接进真实业务。

不要误读工具调用

第一，工具越多不等于 Agent 越强。

工具越多，权限越复杂，错误影响越大。

第二，能调用 API 不等于能自动执行。

读取报表和提交修改是两件完全不同的事。

第三，不要让模型直接持有密钥。

模型只提出请求，密钥由后端管理。

第四，不要忽视失败处理。

真实系统里，工具失败比工具成功更常见。

第五，不要用工具调用掩盖数据质量问题。

报表字段不完整、SOP 过期、SKU 命名混乱，Agent 只会更快地放大混乱。

结论

AI Agent 想真正进入跨境电商业务，必须接工具。

但接工具不是把后台权限全部交给 AI。

正确路线是：

先接只读工具，让 Agent 读真实资料。

再接草稿工具，让 Agent 生成可审核交付物。

再接通知和待办工具，让流程流转起来。

最后，在有权限、日志、审批和回滚机制的前提下，才考虑有限写入。

工具调用的价值，不是让 AI 更自由，而是让 AI 在可控接口里做更具体、更可复核的事。

卖家第一版 Agent，不要追求全自动。

先把工具做小、做清楚、做安全。

这才是从“AI 会说”走向“AI 能做”的关键一步。

资料来源与事实边界

本文核验日期为 2026-07-07。以下来源用于校准工具调用、Function calling、MCP、SP-API 权限和速率限制等官方说法；跨境电商部分为基于卖家运营场景的业务推演和实操建议。

• OpenAI API Docs：Using tools。文档说明构建 responses 或 agents 时，可通过内置工具、function calling、tool search、remote MCP servers 扩展模型能力。链接：https://developers.openai.com/api/docs/guides/tools
• OpenAI API Docs：Function calling。文档说明 function calling 让模型连接外部系统和训练数据之外的数据，开发者可通过 JSON schema 定义函数工具。链接：https://developers.openai.com/api/docs/guides/function-calling
• OpenAI API Docs：Structured outputs。文档说明结构化输出可通过 function calling 或 json_schema response format 实现，function calling 适合把模型和应用功能连接起来。链接：https://developers.openai.com/api/docs/guides/structured-outputs
• OpenAI API Docs：MCP and Connectors。文档说明除 function calling 外，也可通过 connectors 和 remote MCP servers 给模型新能力，并可要求开发者显式审批工具调用。链接：https://developers.openai.com/api/docs/guides/tools-connectors-mcp
• OpenAI API Docs：File search。文档说明 file search 可让模型在生成回答前，从上传文件知识库中检索相关信息。链接：https://developers.openai.com/api/docs/guides/tools-file-search
• OpenAI Agents SDK：Tools。文档说明 tools 让 agents 获取数据、运行代码、调用外部 API 或使用计算机，并建议用 namespace 或 hosted MCP server 管理工具集合。链接：https://openai.github.io/openai-agents-python/tools/
• Model Context Protocol Docs：Introduction。MCP 官方文档称 MCP 是连接 AI 应用与外部系统的开源标准，可连接数据源、工具和工作流。链接：https://modelcontextprotocol.io/docs/getting-started/intro
• Model Context Protocol Spec：Tools。MCP tools 规范说明工具能让模型与外部系统交互，例如查询数据库、调用 API 或执行计算。链接：https://modelcontextprotocol.io/specification/2025-06-18/server/tools
• Model Context Protocol Spec：Resources。MCP resources 规范说明 resources 可让服务器向客户端暴露文件、数据库 schema 或应用上下文等数据。链接：https://modelcontextprotocol.io/specification/2025-06-18/server/resources
• Amazon SP-API：Usage Plans and Rate Limits。Amazon 文档说明多数操作的 rate limits 与 selling partner 和 application pair 相关。链接：https://developer-docs.amazon.com/sp-api/docs/usage-plans-and-rate-limits
• Amazon SP-API：Retrieve a report。Reports API 教程说明需要 selling partner 授权，并需要 developer profile 和 app registration 具备相应角色。链接：https://developer-docs.amazon.com/sp-api/docs/retrieve-a-report