AMZ
用户中心
AI 与自动化

AI Agent的基本架构：大模型、工具、记忆、计划器、执行器怎么协作

关键词： AI Agent架构、Agent原理、LLM Agent、工具调用、RAG、Agent护栏、跨境电商AI

公众号文章库2026/7/722 分钟阅读

摘要： 搭一个可用Agent架构

关键词： AI Agent架构、Agent原理、LLM Agent、工具调用、RAG、Agent护栏、跨境电商AI

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

核心观点： 一个可商用的 AI Agent 不是“一个大模型加几个工具”这么简单，而是一套由模型、指令、上下文、知识库、工具、计划器、执行器、状态、护栏、日志和人工确认组成的任务系统。

很多卖家第一次搭 AI Agent，最容易犯的错误是：先选模型，先接工具，然后期待它自己变聪明。

结果通常是这样：

让它做广告分析，它不知道毛利、库存、活动和新品阶段。

让它写 Listing，它把竞品差评写成了你产品已经具备的功能。

让它做客服回复，它没有查退换货 SOP，就直接给买家承诺。

让它监控竞品，它抓到一个页面价格变化，就推断对手在打价格战。

这些问题表面上像“模型不够强”，但更深层的原因往往是架构没搭好。

Agent 不是一个模型，而是一套围绕目标运转的任务系统。模型只是判断层，工具、资料、权限、流程和日志同样重要。

对跨境卖家来说，理解 Agent 架构不是为了写代码炫技，而是为了知道：

  • 哪些数据要先准备。
  • 哪些工具可以给 AI。
  • 哪些动作必须人工确认。
  • 为什么同一个模型，在不同团队里效果差别很大。
  • 怎么把一个想法变成可复用的运营 Agent。

这篇文章用一个卖家能听懂的方式，把 Agent 架构拆开。

先用一个比喻：Agent 像一个小型运营组

一个可用的 Agent，不像一个单独员工，更像一个小型运营组。

大模型是组长。

它负责理解目标、阅读资料、做判断、解释结果。

指令和 SOP 是岗位说明书。

它告诉组长这个任务怎么做、不能做什么、什么算好结果。

知识库和记忆是资料柜。

里面放产品参数、品牌规则、客服 FAQ、广告复盘、竞品资料。

工具是手和脚。

浏览器、表格、数据库、文件、邮件、API、MCP server，都让 Agent 能读数据、算结果、生成文件或发起待确认动作。

计划器像项目经理。

它把大目标拆成步骤，决定先查什么、后分析什么、什么时候停下来问人。

执行器像运营助理。

它按照计划调用工具，读取结果，继续下一步。

护栏像权限和审批制度。

哪些数据能看，哪些工具能用，哪些动作必须人工确认，哪些内容不能输出。

日志和评估像复盘表。

记录每一步做了什么、用了什么工具、得到什么结果、哪里错了、下次怎么改。

这个比喻很重要。

如果你只给模型，不给资料，它只能凭经验猜。

如果你只给工具，不给规则，它可能乱用工具。

如果你不给日志，出了错也不知道错在哪里。

如果你不给人工确认点，它可能把建议变成真实业务风险。

官方资料怎么解释 Agent 架构

截至 2026-07-07，主流官方文档对 Agent 架构的描述已经有共同方向。

LangChain 文档把 Agent 概括为：模型在循环中调用工具，直到任务完成。它还强调 Agent 不只是模型，而是 model、prompt、tools、middleware 组成的 harness。这个 harness 的工作，是在合适时间把合适上下文交给模型。

OpenAI API 文档把工具分成内置工具、function calling、tool search、remote MCP servers 等方式，让模型能搜索网页、检索文件、调用自定义函数或访问第三方服务。OpenAI Agents SDK 文档也把 turns、tool execution、guardrails、handoffs、sessions、tracing 等列为运行 Agent 时需要管理的部分。

MCP 官方文档则把 Model Context Protocol 描述为连接 AI 应用与外部系统的开源标准，可连接数据源、工具和工作流。MCP tools 规范里也明确说，tools 能让模型与外部系统交互，例如查询数据库、调用 API 或执行计算。

这些官方说法合在一起，说明一件事：

真正的 Agent 架构，不是“模型 + 聊天框”，而是“模型 + 上下文 + 工具 + 控制系统”。

下面我们把它拆成 10 个模块。

模块一：目标层，先定义 Agent 到底为谁完成什么任务

很多 Agent 失败，不是技术失败，而是目标失败。

“帮我运营亚马逊店铺”不是目标。

“帮我提升广告表现”也不是目标。

这太大，模型无法判断边界。

可执行的目标应该像这样：

“每周读取美国站广告 Search Term 报表、Campaign 报表和库存表，识别高花费无转化词、低曝光高转化词、预算异常 Campaign，并输出待运营确认的动作清单。”

这个目标里有几个关键元素：

  • 时间频率：每周。
  • 数据范围：Search Term、Campaign、库存表。
  • 分析对象：关键词、Campaign、预算。
  • 输出结果：待确认动作清单。
  • 风险边界：不是直接自动调广告。

如果目标不清楚，后面的模型、工具、知识库都会失焦。

卖家搭 Agent 的第一步，不是选模型，而是写清楚：

这个 Agent 的岗位是什么？

它服务谁？

它输入什么？

它输出什么？

它不能做什么？

模块二：指令层，把隐性经验写成 SOP

指令不是普通提示词。

对 Agent 来说，指令更像岗位 SOP。

它要告诉 Agent：

  • 你是谁。
  • 当前业务目标是什么。
  • 做事顺序是什么。
  • 什么情况必须停下来问人。
  • 什么字段不能编。
  • 输出格式是什么。
  • 哪些动作禁止执行。

比如 Listing Agent 的指令不能只写：

“帮我写一条高转化 Listing。”

这会鼓励模型自由发挥。

更好的指令应该写：

“所有产品参数必须来自我提供的产品资料；评论中出现的问题只能作为买家痛点，不得直接写成我方产品已有功能；涉及安全、医疗、认证、官方兼容等表达必须标注需要人工确认。”

这就是 SOP。

对跨境团队来说，Agent 指令最好由业务负责人写，而不是只交给技术。

技术可以实现工具调用，业务必须定义判断标准。

模块三：模型层，负责理解、判断和生成，不负责凭空拿数据

大模型是 Agent 的判断层。

它擅长：

  • 理解自然语言。
  • 总结资料。
  • 归类评论。
  • 比较方案。
  • 判断下一步该查什么。
  • 生成报告和草稿。

它不擅长：

  • 天然知道你的库存。
  • 天然知道今天广告花费。
  • 天然知道供应商成本。
  • 天然知道你产品真实参数。
  • 稳定做精确计算。
  • 替你承担合规责任。

所以，模型在架构里的定位要摆正。

模型不是数据库。

模型不是 ERP。

模型不是财务系统。

模型也不是最终审批人。

它更像一个聪明但必须看资料、用工具、守规则的运营分析员。

如果你让模型凭空判断“这个产品有没有机会”，它会给你一堆看似合理的结论。

如果你让模型读取关键词数据、评论样本、价格带、毛利、供应链约束，再按评分规则输出机会清单，它才有商业价值。

模块四：上下文层，决定模型当下能看到什么

上下文是 Agent 的工作台。

它包括当前任务目标、用户输入、历史对话、临时变量、已调用工具结果、知识库检索片段、业务规则和输出要求。

LangChain 文档提到 harness 的工作，是在合适时间给模型合适上下文。这个说法对卖家很关键。

因为 Agent 不是资料看得越多越好。

资料太少，它会猜。

资料太多，它会乱。

资料过期，它会错。

比如客服 Agent 回复买家问题时，不应该把全公司所有文档都塞进去。

它应该只看到：

  • 当前买家问题。
  • 当前产品型号。
  • 对应产品 FAQ。
  • 当前站点售后 SOP。
  • 禁止承诺清单。
  • 是否需要人工升级的规则。

这叫上下文工程。

卖家团队可以先用一个简单规则：

每个 Agent 只给它完成当前任务所需的最小资料。

模块五：知识库和检索层，让 Agent 先查资料再回答

知识库解决的是“模型不知道你公司事实”的问题。

对跨境团队来说，知识库可以包括：

  • 产品参数表。
  • 说明书。
  • 品牌词库。
  • 禁用词和合规规则。
  • Listing 模板。
  • 客服 FAQ。
  • 售后 SOP。
  • 广告命名规则。
  • 历史复盘。
  • 竞品评论归因结果。

OpenAI 的 file search 文档把文件搜索描述为让模型在生成回答前从已上传文件知识库中检索相关信息。这个能力本质上就是让模型先查资料，再生成。

但知识库不是把文件堆进一个文件夹。

知识库要能被 Agent 正确检索，需要做到：

  • 文档命名清楚。
  • 按产品、站点、时间、流程分类。
  • 标注更新时间。
  • 旧版 SOP 归档。
  • 敏感数据脱敏。
  • 检索结果能引用来源。

如果知识库质量差，Agent 只会更快地产生错误。

比如把欧洲站售后规则用到美国站，把旧版产品尺寸写进新版 Listing，把 A 产品兼容型号写到 B 产品里。

这不是模型问题，是资料治理问题。

模块六：工具层，让 Agent 从“会说”变成“会做”

工具是 Agent 架构里最容易被高估，也最容易被低估的部分。

没有工具，Agent 只能说。

有工具，它才可以读文件、查表格、搜索网页、调用 API、运行代码、生成报告、发起待确认动作。

OpenAI tools 文档列出 web search、file search、computer use、function calling、remote MCP servers 等方式。MCP tools 规范也说明，tools 可以让模型查询数据库、调用 API 或执行计算。

对卖家来说，工具可以分成三类。

只读工具

风险最低，最适合先接。

例如：

  • 读取广告报表。
  • 读取库存表。
  • 读取评论导出。
  • 读取产品资料。
  • 读取客服 SOP。
  • 搜索公开网页。

只读工具让 Agent 能分析真实资料，但不会直接改业务系统。

草稿工具

中等风险，需要审核。

例如：

  • 生成 Listing 草稿。
  • 生成客服回复草稿。
  • 生成广告调整建议。
  • 生成周报。
  • 生成图片脚本。

草稿工具可以大幅提高效率，但发布前必须人工检查。

写入工具

风险最高，默认不要自动执行。

例如：

  • 改价。
  • 调预算。
  • 否定关键词。
  • 发客服邮件。
  • 提交 Listing。
  • 退款补发。
  • 删除文件。

这些工具如果要接，必须有审批、日志、权限、回滚和成本控制。

一个成熟 Agent 的工具设计，不是“能接多少就接多少”，而是：

先只读，再草稿，最后才是有限写入。

模块七：计划器，把大任务拆成可检查步骤

计划器决定 Agent 怎么拆任务。

简单任务可以边做边想。

复杂任务必须先给计划，再执行。

例如“竞品监控 Agent”不能直接开始写结论。

它应该先给出计划：

  1. 读取竞品 ASIN 列表。
  2. 检查本周和上周数据字段。
  3. 对比价格、Coupon、评分、评论数、主图、标题、五点。
  4. 找出变化最大的竞品。
  5. 判断变化可能属于价格策略、页面优化、活动促销还是评论波动。
  6. 输出证据表。
  7. 生成我方应对建议。
  8. 标注需要人工截图确认的页面。

计划器的价值是让复杂任务可见。

如果 Agent 的计划一开始就错了，你可以马上改。

如果没有计划，它可能跑完一堆步骤后才暴露方向错误。

卖家团队可以规定：

超过 3 个步骤的 Agent 任务，先输出计划。

涉及后台数据或客户信息的任务，计划必须人工确认后再执行。

模块八：执行器和状态层，记录每一步做了什么

执行器负责真正调用工具。

它会把计划变成动作：

  • 读取某个文件。
  • 调用某个 API。
  • 执行某段计算。
  • 检索某个知识库。
  • 生成某个报告。

状态层记录当前任务进行到哪里。

比如：

  • 已读取哪些文件。
  • 哪些字段缺失。
  • 哪些工具调用成功。
  • 哪些工具失败。
  • 哪些结论已经有证据。
  • 哪些动作等待人工确认。

没有状态，Agent 很容易重复做事或忘记做事。

这也是为什么很多早期 Agent 看起来很忙，却产出不稳定。

它没有清楚的任务状态和停止条件。

对卖家来说，状态层可以很简单。

比如在周报里写：

  • 数据检查：通过。
  • 缺失字段：无。
  • 已读取报表：Search Term、Campaign、库存表。
  • 待确认动作：12 条。
  • 已自动执行动作：0 条。
  • 失败工具调用：无。

这比一篇漂亮但无法追溯的 AI 报告更有价值。

模块九：输出层，让结果变成可复核的表格、清单和报告

Agent 输出不能只是一段顺滑文字。

可商用的 Agent 输出必须结构化。

LangChain structured output 文档强调，结构化输出能让 Agent 返回特定、可预测的格式，而不是只能解析自然语言。

对卖家来说，结构化输出至少要包含：

  • 结论。
  • 证据。
  • 数据来源。
  • 建议动作。
  • 风险等级。
  • 人工确认点。
  • 下一步。

比如广告 Agent 不应该只说：

“建议优化高 ACOS 关键词。”

它应该输出：

异常类型关键词花费订单ACOS可能原因建议动作需要确认
高花费无转化example keyword42.30无法计算新品测试或相关性差先降竞价观察是否新品期

这才方便运营审核。

同样，Listing Agent 应该输出：

  • 标题草稿。
  • 五点草稿。
  • 图片文案。
  • 对应证据。
  • 涉及产品参数的来源。
  • 需要人工确认的合规表达。

模块十：护栏、日志和评估，让 Agent 能被商业使用

护栏不是锦上添花。

护栏决定 Agent 能不能进入真实业务。

OpenAI Agents SDK 文档把 guardrails、human review、tracing、observability 放在 Agent 工作流的重要位置。OpenAI Agents SDK tracing 文档也说明，tracing 会记录 LLM generation、tool calls、handoffs、guardrails 等事件，方便调试、可视化和监控。

对跨境卖家来说，护栏至少包括 7 类。

1. 权限护栏

客服 Agent 不能随便读毛利表。

广告 Agent 不应该访问客户地址。

Listing Agent 不应该直接改价格。

2. 工具护栏

每个工具都要标注：

  • 只读还是写入。
  • 访问哪些数据。
  • 是否需要审批。
  • 调用失败怎么办。

3. 内容护栏

禁止编造产品参数。

禁止使用竞品商标。

禁止写未经证实的认证、医疗、安全承诺。

禁止引导评价。

4. 成本护栏

限制最大运行时间、最大工具调用次数、最大文件数量、最大 token 成本。

5. 人工确认护栏

改价、调预算、发邮件、退款、补发、提交 Listing，必须进入待确认清单。

6. 日志护栏

每次执行记录：

  • 谁发起。
  • 目标是什么。
  • 读了哪些资料。
  • 调用了哪些工具。
  • 输出了什么建议。
  • 谁确认了动作。

7. 评估护栏

定期抽样检查 Agent 输出：

  • 是否编造。
  • 是否漏掉关键字段。
  • 是否引用过期资料。
  • 是否建议了高风险动作。
  • 是否真正节省时间。

没有这些护栏，Agent 只是演示。

有了这些护栏，Agent 才能成为团队流程。

用一个“竞品监控 Agent”完整串起来

下面把架构落到一个具体例子。

目标：每周监控 20 个竞品 ASIN，输出变化摘要和我方应对建议。

1. 目标层

每周对比竞品页面变化，识别价格、Coupon、评分、评论数、主图、标题、五点、卖点表达的变化，并输出对我方 Listing、广告和图片的影响。

2. 指令层

规则：

  • 只分析公开页面和已保存快照。
  • 不把单次价格变化直接判断为长期策略。
  • 所有结论必须引用页面字段或截图编号。
  • 页面数据异常时标注“需要人工确认”。
  • 不生成涉及侵权、抄袭竞品文案的建议。

3. 上下文层

给 Agent 的资料：

  • 竞品 ASIN 列表。
  • 本周页面快照。
  • 上周页面快照。
  • 我方当前 Listing。
  • 我方广告主推关键词。
  • 品牌差异化卖点。

4. 知识库层

长期资料：

  • 类目卖点词库。
  • 禁用词。
  • 图片规范。
  • 品牌调性。
  • 历史竞品复盘。

5. 工具层

只读工具：

  • 读取页面快照。
  • 读取评论导出。
  • 读取关键词表。
  • 检索知识库。

草稿工具：

  • 生成周报。
  • 生成 Listing 改版建议。
  • 生成图片脚本草稿。

禁止工具：

  • 不自动提交 Listing 修改。
  • 不自动调整广告预算。
  • 不自动抓取需要登录的敏感数据。

6. 计划器

先输出计划：

  1. 检查 20 个 ASIN 的快照是否齐全。
  2. 对比字段变化。
  3. 找出变化幅度最大的 5 个竞品。
  4. 分析变化类型。
  5. 评估对我方影响。
  6. 输出建议和人工确认点。

7. 执行器和状态

执行过程中记录：

  • 成功读取 20 个 ASIN。
  • 2 个 ASIN 快照缺失。
  • 5 个竞品价格变化超过 10%。
  • 3 个竞品更换主图。
  • 1 个竞品标题新增关键词。

8. 输出层

输出包括：

  • 竞品变化总览表。
  • 重点变化详情。
  • 对我方 Listing 的影响。
  • 对广告关键词的影响。
  • 需要人工确认的截图。
  • 下周继续观察清单。

9. 护栏和评估

护栏：

  • 所有页面数据必须带日期。
  • 单次抓取不做长期判断。
  • 竞品文案只能用于结构分析，不能照抄。
  • 所有修改建议都进入人工审核。

评估：

  • 每周抽查 5 个竞品变化是否正确。
  • 每月复盘建议是否被采纳。
  • 记录误判原因。

这就是一个可落地的 Agent 架构。

它不神秘，但很清楚。

最小可用 Agent 架构：不要一开始做太大

如果你现在想做第一个 Agent，不要把 10 个模块全部做满。

先做最小可用版本。

版本 1：只读分析 Agent

能力：

  • 读取你上传的文件。
  • 按固定提示词分析。
  • 输出结构化报告。
  • 标注需要人工确认的问题。

适合：

  • 评论归因。
  • 广告周报。
  • Listing 草稿。
  • 竞品监控。

不要接：

  • 后台写入。
  • 自动发信。
  • 自动调价。

版本 2：知识库 Agent

增加：

  • 产品资料库。
  • SOP 检索。
  • 品牌规则。
  • 输出引用来源。

适合：

  • 客服回复草稿。
  • Listing 改版建议。
  • 培训材料生成。

版本 3：工具调用 Agent

增加：

  • 表格读取。
  • API 查询。
  • MCP 工具。
  • 文件生成。
  • 任务状态记录。

适合：

  • 广告诊断。
  • 库存异常分析。
  • 竞品监控周报。

版本 4：团队流程 Agent

增加：

  • 权限分级。
  • 审批流。
  • 执行日志。
  • 成本上限。
  • 定期评估。

适合：

  • 多人运营团队。
  • 涉及敏感数据的场景。
  • 需要长期运行的流程。

可复制提示词：设计一个业务 Agent 架构

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

我要设计一个业务 Agent。

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

业务目标：
[用一句话写清最终交付物]

可用资料：
1. [资料1]
2. [资料2]
3. [资料3]

可能使用的工具：
[例如：读取表格、检索知识库、搜索网页、调用API、生成报告]

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

请按以下结构输出 Agent 架构方案：

1. 目标层：这个 Agent 的岗位是什么。
2. 指令层：它必须遵守的 SOP。
3. 模型层：模型负责哪些判断，不负责哪些事情。
4. 上下文层：每次任务需要给它哪些资料。
5. 知识库层：哪些资料需要长期沉淀。
6. 工具层：只读工具、草稿工具、禁止工具分别是什么。
7. 计划器：任务拆成哪些步骤。
8. 执行器和状态：每一步要记录什么。
9. 输出层：最终报告或清单格式。
10. 护栏：权限、内容、成本、人工确认、日志、评估。
11. 第一版 MVP：7 天内怎么做出来。
12. 验收标准：怎样判断这个 Agent 可用。

要求：
- 不要给抽象概念。
- 每一层都要能落到运营动作。
- 涉及高风险动作时，只能生成待确认清单。
- 如果资料不足，先列出缺失资料，不要编造。

第一周落地 SOP：搭一个只读竞品监控 Agent

第 1 天：定义岗位

写清楚：

  • 它监控哪些竞品。
  • 每周输出什么。
  • 不允许做什么。
  • 谁审核结果。

第 2 天：准备资料

至少准备：

  • 竞品 ASIN 列表。
  • 上周页面快照。
  • 本周页面快照。
  • 我方 Listing。
  • 品牌卖点和禁用词。

第 3 天：写 SOP 指令

要求：

  • 所有结论引用字段。
  • 单次变化不做长期判断。
  • 竞品文案只做结构分析，不照抄。
  • 修改建议进入人工审核。

第 4 天：设计输出模板

输出模板包括：

  • 变化总览。
  • 重点竞品。
  • 变化证据。
  • 可能原因。
  • 我方建议。
  • 人工确认点。

第 5 天：跑 10 个历史样本

找历史快照测试。

看 Agent 是否：

  • 找到了真实变化。
  • 引用了证据。
  • 没有夸大推断。
  • 没有建议高风险动作。

第 6 天：补护栏

根据错误补规则。

比如：

  • 价格变化小于 5% 不解读。
  • 无截图不下结论。
  • 标题变化只做关键词结构分析。
  • 需要人工打开页面复核的情况单独列出。

第 7 天：固定流程

保存：

  • 输入文件模板。
  • 提示词。
  • 输出模板。
  • 检查清单。
  • 复盘表。

这就是一个能继续迭代的最小 Agent。

验收标准：架构可用不等于文章画得漂亮

一个 Agent 架构能不能用，至少看 10 条。

  1. 目标一句话说得清。
  2. 输入资料有固定格式。
  3. 知识库资料有版本和来源。
  4. 工具权限分成只读、草稿、写入。
  5. 超过 3 步的任务先给计划。
  6. 每个关键结论有证据。
  7. 高风险动作进入人工确认。
  8. 执行过程有日志。
  9. 失败时知道停在哪里。
  10. 输出可以被运营复核和复用。

如果缺少这些，不管用了多强模型，都还只是试验。

不要误读 Agent 架构

第一，不是组件越多越高级。

第一个 Agent 最好简单。

先只读，先出报告，先让人审核。

第二，不要把模型当数据库。

库存、毛利、订单、广告花费、产品参数都必须来自真实资料或工具。

第三，不要把工具权限一次全开。

工具越多，错误影响越大。

第四，不要把记忆当万能。

记忆过期、混乱、来源不明，会让 Agent 更危险。

第五，不要没有日志。

没有日志，就没有排错、复盘和治理。

结论

AI Agent 的基本架构，真正要解决的是一个商业问题：

怎样让 AI 在正确资料、正确工具、正确权限和正确流程里完成任务。

大模型负责理解和判断。

指令负责 SOP。

知识库负责事实。

工具负责动作。

计划器负责步骤。

执行器负责调用。

状态负责记住进度。

输出层负责可复核。

护栏和日志负责把风险关住。

卖家搭 Agent，不要从“我要一个很强的 AI”开始，而要从“我要一个边界清楚、资料可靠、工具受控、输出可复核的小流程”开始。

这才是 AI Agent 从概念走向商用的第一步。

资料来源与事实边界

本文核验日期为 2026-07-07。以下来源用于校准 Agent 架构、工具调用、MCP、结构化输出、护栏和追踪等官方说法；跨境电商部分为基于卖家运营场景的业务推演和实操建议。