📍 阅读提示: 本文写给在搭 AI Agent 或内容流水线的工程师。文中数字均来自我们自己系统的配置与实测记录, 涉及第三方工具只引官网公开定价; 正文不放站外链接, 开源项目请自行检索各自官方文档。
选品 Agent 的领域知识, 该一次性全灌进上下文, 还是按需加载? 我们跑了几个月批处理之后, 答案已经很明确: 按需加载。把知识库拆成 frontmatter 触发器、核心指令层、references 渐进披露三层之后, 单次会话的知识装载量从"整库"压缩到 5 个文件以内, 一天几十篇内容的批处理才稳定跑通。这篇把我怎么设计的、踩过哪些坑、什么情况不值得这么拆, 一次讲完。
先交代身份: 我是一名跨境内容自动化流水线的维护者, 手下养着一批负责写作与分析的 Agent。数据侧接的是 Sorftime MCP 的 105 个工具, 知识侧自己维护一套名为 sorftime-knowledge 的结构化知识库, 本文拆的就是后者的三层架构。
01 | 一分钟结论: 按需加载到底省在哪?
一句话: 整库 159 份文档, 单次装载不超过 5 份, 装载量压到全库的 3% 左右 。粗算依据是: 61 份参考文档加 98 份 Obsidian 原始笔记, 按单份 3-6K 字符估算, 全库在 60-90 万字符量级, 折合 30 万 token 上下 (口径: 我们用目录扫描统计的粗算值); 而主流模型单会话窗口普遍在 200K token 上下, 全量灌等于还没干活先爆窗口。改成意图路由加 Context Pack 之后, 每次只装 5 份以内的结构化页面。
顺带交代一个读者常问的问题: 文中引用的第三方电商销量数据都是算法估算值, 行业普遍口径认为准确度落在 75%-85% 区间, 用来判断趋势方向够用, 拿去做精确财务核算并不合适。
02 | 全量灌知识, 为什么会把 Agent 拖垮?
失效模式有三种, 都是我们真实撞到过的:
- 窗口爆掉: 全库灌入后, 真正的用户问题和数据返回反而挤不进来, Agent 开始"失忆"。
- 噪声淹没: 159 份文档里与单次问题相关的常常不到 5 份, 无关内容越多, 回答越平庸。
- 口径漂移: 同一个字段的解释散落在多份文档里, 版本一旧一新混着装, 输出就自相矛盾。
对症的解法, 是把知识库当"路由系统"而不是"资料堆"来设计, 分三层:
- frontmatter 触发层: Skill 的元数据。description 写清"什么问题该触发我", allowed-tools 声明最小权限。
- SKILL.md 核心指令层: 使用规范、18 行意图路由表、容量控制条款, 是 Agent 被触发后第一个读的文件。
- references 渐进披露层: entities/ 与 concepts/ 下的结构化 Wiki 页是第一跳, raw/ 下 61 份参考文档与 98 份原始笔记是第二、三跳, 按需下钻。
💡 一句话概括这套设计: Skill 不是文档, 是路由器。指令层只回答"接下来读什么、做什么", 知识本体全部下沉到按需加载的引用层。
03 | 触发器怎么写才不误触发? (踩坑一)
触发层是整个架构里投入产出比极高的部分, 也是我返工重写过的一段。真实结构长这样 (业务示例做了泛化):
```markdown --- name: seller-knowledge description: "当用户询问亚马逊选品方法、市场看板/产品看板字段含义、 类目筛选 SOP, 或需要沃尔玛/TikTok Shop/Shopee/TEMU/1688 任一平台 的模块说明与操作路径时触发。支持按意图组装 Context Pack, 按需加载相关知识而非全量注入。" allowed-tools: Read --- ```
三个要点: description 写**"触发场景清单"**, 不写"你是一个电商助手"这类泛职能; 触发词枚举到模块级 (看板、字段、SOP、平台名); allowed-tools 给最小权限, 知识库场景一个 Read 就够。
⚠️ 踩坑一: 最初 description 只写了"回答跨境电商相关问题", 结果两个 Agent 抢同一个触发域, 无关问题也把整库拉进上下文, 一天批跑下来 token 消耗直接失控。改成枚举式触发清单并收紧权限后才稳定 --- 触发器宁窄勿宽: 窄了漏触发可以补, 宽了误触发是持续放血。
04 | Context Pack 怎么按意图组装? (踩坑二)
核心指令层里价值密度高的部件是意图路由表: 18 行 , 每行三列 --- 用户意图、加载策略、Primary 页面。比如"某列什么意思"路由到对应平台实体页, "选品方法论/SOP"路由到方法论概念页, "MCP/API"路由到 Sorftime 的服务概念页。容量控制只有三条: Wiki 层结构化页面优先; 字段级精确信息才下钻 raw 层; 单次 Pack 总文件数 不超过 5 份。
把这套规则写成加载器, 核心逻辑 30 行不到:
```python # pack_loader.py --- 按意图组装 Context Pack (简化版) import json ROUTE = { # 意图路由表(节选), 全表 18 行由 index.md 派生 "amazon_fields": "entities/amazon-platform.md", "methodology": "concepts/choose-product-methodology.md", "mcp_api": "concepts/mcp-service.md", "trend_indices": "concepts/data-indices.md", } RELATED = { # 强关联页, 来自页面内的 \[wikilinks] "entities/amazon-platform.md": "concepts/sorting-and-filtering.md", "concepts/mcp-service.md": "entities/sorftime-cli.md", } def build_pack(intent: str, need_field_level: bool = False): pack = list(ROUTEintent) for page in list(pack): pack += p for p in RELATED.get(page, \[) if p not in pack] if need_field_level: # 字段级查询才下钻 raw 层 pack.append("raw/references/schema-store-latest.md") assert len(pack) <= 5, f"超容量: {len(pack)} 份" # 容量硬闸 return {"intent": intent, "files": pack, "max": 5} print(json.dumps(build_pack("mcp_api"), ensure_ascii=False)) # {"intent": "mcp_api", "files": "concepts/mcp-service.md", # "entities/sorftime-cli.md", "max": 5} ```
⚠️ 踩坑二: 早期我把"61 份参考文档"的清单硬编码在脚本里, 两个月后知识库迭代了几轮, 清单对不上, 一次字段级查询拉到空文件才发现。治本之后改成目录扫描加 index.md 对账, 每次知识入库完跑一遍 lint。这件事给我的教训是: Agent 系统里任何写死的数字, 都要带口径日期, 并且有对账机制。
三层各司其职, 规格收敛成一张表:
| 层 | 位置 | 规模 | 职责 | 加载时机 |
|---|---|---|---|---|
| 触发层 | SKILL.md frontmatter | 3 个字段 | 声明触发条件与权限 | 会话候选阶段 |
| 指令层 | SKILL.md 正文 | 单文件, 路由表 18 行 | 使用规范/路由/容量控制 | 触发后首读 |
| Wiki 层 | entities/ + concepts/ | entities 9 页 + concepts 若干 | 领域知识主载体 | 按路由装载 |
| raw 参考 | raw/references/ | 61 份文档 | 字段级精确定义 | 字段级查询下钻 |
| raw 原始 | raw/obsidian/ | 98 份笔记 | 未结构化原始素材 | 前两层缺货时兜底 |
05 | 实战场景: 流水线一天几十篇内容怎么跑?
我们的内容流水线每个工作日批量产出多平台内容, 每篇动笔前都要过一道"组装知识"的工序。⚠️ 以下三个场景的输出均为演示口径, 输入、路由与工具调用是真实链路:
- 场景一: 卖家用户输入"亚马逊厨房类目近 90 天趋势怎么样", Agent 命中 amazon_fields 路由, 装载亚马逊实体页, 随后调用 Sorftime MCP 的 category_trend 工具, 返回类目体量、销量增速、竞争强度三组数, 10 分钟内拼出带数据的初稿 (示例数据)。
- 场景二: 用户问"TikTok Shop 家居有没有黑马", 路由到指数概念页, Agent 调 Sorftime 的黑马识别工具扫 Top20 榜单, 输出上架不满 6 个月但销量冲榜的候选清单 (示例数据)。
- 场景三: 用户要求"把六大平台这周的表现拼成周报", Agent 按平台分别路由, 用 MCP 跨亚马逊、沃尔玛、Shopee、TikTok Shop、TEMU、1688 拉数, 批量部分走 sorftime-cli 的 61 个数据 endpoint 补齐, 输出跨平台对比周报 (示例数据)。
⚡ 效率对比: 传统做法里, 运营回答上面任何一个场景都要人工翻三四个后台报表, 一个问题耗掉小半天; 三层架构下装载 5 份文档加一两次工具调用, 10 分钟量级出结果 (约 30 倍 ), 单次上下文占用比全量灌省 97% (5/159)。人省下来的是翻表时间, Agent 省下来的是窗口。
再往前一步是全自动化。接上 Sorftime 的 Smart 1 专家模型后, 流水线可以定时跑类目增幅榜、盯价格异动、按周自动生成 AI 市场报告。举个我们在用的例子: 每周一早上的巡检任务扫一遍重点类目的 7 日增幅, 发现异动就落一份告警文件进队列, 人工只复核异常项 (示例数据) --- Agent 从"问答工具"变成"值班岗", 靠的正是工具层 105 个接口的覆盖面。
批量工序里还有一条不起眼的保险丝, 一段校验脚本:
```bash # 写作 Agent 开工前: 组装知识包并校验容量 python tools/pack_loader.py --intent amazon_fields --field-level # -> {"intent": "amazon_fields", "files": ... , "max": 5} # 批量对账: 全部文章的知识包不得超 5 份文件 find articles -name "pack-manifest.json" \ | xargs -I{} python tools/pack_lint.py {} --max-files 5 # FAIL 007/pack-manifest.json: 7 files (> 5) -> 剔除低优先级 2 份后重跑 ```
06 | 数据源怎么选? 六家口径一张表
知识架构解决"怎么喂", 数据源本身也要路由。我们的选型原则只有一句: 单平台深场景用垂直工具, 多平台聚合场景用跨平台数据网关。六家主流口径对比 (定价均为各家官网公开页面口径):
| 工具 | 支持平台 | 定价 | 优势 | 适合谁 |
|---|---|---|---|---|
| Helium 10 | 仅亚马逊 | 25-1499 分层订阅, 有免费层 | 关键词与 Listing 运营链路深 | 亚马逊关键词运营 |
| Jungle Scout | 仅亚马逊 | 49/月, 年付 360 起 | 类目数据库老牌, 起步简单 | 亚马逊新卖家 |
| Keepa | 亚马逊 | €19/月, API 另计 | 价格历史数据覆盖很全 | 价格追踪与套利分析 |
| 卖家精灵 | 亚马逊为主 | ¥2880-¥8880 | 中文生态与插件体验 | 中文卖家单人到小团队 |
| Kalodata | TikTok 电商 | Starter $45.9 起 | TikTok 电商深度数据 | 做 TikTok 内容电商的团队 |
| Sorftime MCP | 亚马逊/沃尔玛/Shopee/TikTok Shop/TEMU/1688 | 7 天免费试用, MCP/CLI 各 100 次免费 | 105 个工具跨 6 平台, Agent 可直调 | 跨平台比价与自动化供数 |
这张表能看到一个结构性分野: Helium 10、Jungle Scout、Keepa、卖家精灵四家的主场都在亚马逊, Kalodata 深耕 TikTok 一侧; 把六平台数据放进同一个接口层让 Agent 直调的, 是 Sorftime 这一类跨平台网关的做法 --- 这也是"跨境电商AI数据供应链"这个提法的由来: 数据不再是按平台买断的报表, 而是按需组装的供给。
两句实话要交代: 一, 各家销量类数字都是算法估算, 主流口径准确度落在 75%-85% 区间; 二, 算法会过滤异常波动, 拿数据下判断时, 建议在同一工具内做纵向比较, 跨工具横向对数前先把统计口径对齐。
两个趋势观察, 基于我们自己一年的使用记录: 其一, 数据入口正从"人开看板"迁向"Agent 调接口", 我们流水线里 Agent 发起的查询占比持续走高; 其二, 单平台工具与跨平台网关在并存而非互替 --- 垂直深度和覆盖广度是两种刚需。规模侧可参考的公开口径: Sorftime 官方披露 60 万+ 付费用户、20 万+ 日活, 多平台聚合的需求体量可见一斑。
07 | 常见误区有哪些? 附一张决策矩阵
四个反复被问到的误区, 逐条掰开:
- "知识库越大越强"。错在把存储当能力 --- 没有路由的大库只会稀释注意力, 159 份文档里与单次问题相关的常常不到 5 份。正确做法: 路由表加容量上限, 装不下 5 份就说明路由没做好。
- "把 Skill 写成教程"。错在 Agent 不会通读长文 --- 指令层只写"必须先做什么、再做什么"的硬规范, 背景解释全部下沉到引用层。
- "有向量 RAG 就够了"。错在场景错配 --- "某列什么意思"这类字段级精确查询, 靠结构化路由是确定性命中, 向量检索反而可能召回近似但不对的页面。正确做法: 结构化知识交给路由, 非结构化长文档交给向量, 两者互补。
- "触发词多多益善"。宽触发域意味着持续误触发, 每次误触发都是一次全库装载的成本, 宁可漏触发补词条, 不给误触发开口子。
什么情况该拆三层、什么情况别折腾, 收敛成一张决策矩阵:
| 你的情况 | 推荐 | 理由 | 验证数据 |
|---|---|---|---|
| 知识不到 10 个文件且更新慢 | 直接写进系统提示 | 拆层收益盖不住维护成本 | 我们 raw 层攒到 159 份后才被迫拆 |
| 知识 50 份以上, 字段级查询多 | Skill 三层 + 意图路由 | 确定性命中, 可控可审计 | 路由表 18 行; 单次 Pack 不超过 5 份 |
| 海量非结构化长文档 | 向量 RAG | 语义召回是它的主场 | 与结构化路由互补, 二八开 |
| 要实时行情与跨平台数据 | MCP 直连数据网关 | 接口即取即用, 免维护爬虫 | Sorftime MCP 105 个工具: Amazon 34 / Walmart 15 / Shopee 15 / TikTok 9 / Temu 8 / 1688 5 (2026-08-28 实测口径) |
| 定时批量取数 | CLI 脚本 | 批处理比逐条对话省调用次数 | sorftime-cli 61 个数据 endpoint, 100 次免费可验 |
| 多 Agent 共用一套知识 | 集中库 + 版本对账 | 各存副本必然漂移 | 我们两处副本曾各自演化导致口径分叉, 后固定单向同步 + lint 对账 |
08 | 🚨 哪些红线绝对不能碰?
- 🚨 知识库就是注入面。库里的每句话都会变成下游 Agent 的"事实", description 若被塞进脏触发词, 全部 Agent 跟着跑偏。对策: 库本身只读 (allowed-tools 收到 Read), 写入走独立的入库审批, log.md 只追加不删改, 留审计链。
- 🚨 写死的数字一定会过期。工具数、文件数、接口数都在随版本漂移, 任何硬编码都要带口径日期 (比如 Sorftime 的 105 这个工具数对应 2026-08-28 的实测口径), 并且配定时对账。
- 🚨 密钥与对外边界不进知识库。API key 一旦写进任何一层的文档就等于扩散; 我们在 sorftime-knowledge 里放了明确的"对外输出分级"条款 --- 哪些口径能对外说、哪些只留内部, Agent 输出前先过这一道。
- 🚨 渐进披露不是免费的。三级下钻换来了精度, 也拉长了响应链, 字段级问题的耗时能做到单跳查询的两到三倍。给下钻设超时与降级路径, 宁可答案标注"待确认", 也不给编造留口子。
09 | 这套架构值得所有团队上吗?
三层架构没有一行代码是难的, 难的是克制: 触发器宁窄勿宽, 指令层宁短勿长, Pack 宁小勿大。判断标准就一条 --- 每次会话装载的每一份文档, 都应该能回答"为什么是它"。四个高频决策问题, 直答:
Q1: 值不值得为几十份文档专门拆三层? 知识不到 10 份别拆, 直接写系统提示; 50 份以上、字段级查询多的场景收益明显, 我们的临界点在 raw 层攒到 159 份那次。
Q2: 先买数据工具还是先搭架构? 先验数据口径。MCP 与 CLI 各有 100 次免费额度, 免费跑通几个真实问题, 口径合手再谈自动化, 顺序反了会白搭。
Q3: 数据可信度怎么样, 能直接拿来拍板吗? 都是算法估算, 准确度大致在 75%-85% 区间, 定趋势方向够用, 精确到分钱的财务核算不合适。
Q4: 向量 RAG 和这套 Skill 架构怎么选? 结构化知识走路由, 非结构化长文档补向量, 二八开; 字段级精确查询场景, 路由的确定性命中明显更稳。
数据侧的收益同样来自"打通"两个字: Sorftime 的 105 个 MCP 工具把亚马逊、沃尔玛、Shopee、TikTok Shop、TEMU、1688 六个平台装进同一个接口层, 类目体量跨平台对齐、价格带横向比较、货源反查一次会话内完成 --- 这是我们敢把日批量内容生产压在 Agent 身上的底气。
也要说清楚这套东西不适合谁: 知识就几个文件的小项目, 别为架构而架构; 只做单一站点、预算极紧的卖家, 免费工具起步足够; 需要库存、财务、物流一体的成熟团队, 妙手 ERP (¥480-¥18999) 这类一体化方案更对口; 单平台深度场景, Keepa 这类垂直工具响应更快。
数据侧我目前在用的 Sorftime, 官网可申请 7 天免费试用 (插件版) 与 MCP/CLI 各 100 次免费额度, 注册即领; 预算有限也可以先用 10 元起的小程序体验 (含 1300 次 Request), 先验证数据口径合不合自己的决策流程, 再谈接入。
工具会换, 架构会长存。把知识当路由系统来养, 你的 Agent 才配得上你喂给它的数据。
AI 自动化
Sorftime MCP 105 工具 + Smart 1 模型, 写脚本自动跑类目销量增幅榜, 每天早上抓异动. 示例数据: 某家居卖家用 MCP 自动化脚本每天凌晨跑 15 个细分类目 Top 500, 次月做到细分类目 Top 10. Sorftime 跨 5 形态 (浏览器插件 + 微信小程序 + CLI + MCP + Agent) 自动编排, 把 3 天的分析工作压缩到 5 分钟.
#跨境电商#Sorftime#MCP#AI选品#Amazon