先关注后阅读，娇姐怕失去上进的你

本文记录一次真实踩坑：用 OpenClaw 做公众号批量处理任务，上下文持续累积导致 422 报错，改用 Sub-Agent 隔离后彻底解决。

先说说 OpenClaw 的 Agent 是什么

在讲问题之前，先把几个概念说清楚，不然后面的解法看不懂。

Agent 是什么

OpenClaw 里的 Agent，简单说就是一个有记忆、有工具、能持续运行的 AI 实例。

它跑在你自己机器上的一个后台进程里，这个进程叫 Gateway。Gateway 是整个系统的单一事实来源，负责管理 session、路由消息、维持各个通讯渠道的连接——WhatsApp、Telegram、飞书发来的消息全都经过它。

每个 Agent 有自己的工作目录，里面放着几个关键文件：

每次新 session 开始时，OpenClaw 把这些文件的内容直接注入到 agent 的上下文里。这就是 agent "记得"你的原因——不是真的有持久记忆，是每次都把记录重新读进去。

Session 和上下文是什么

一次 session，就是一段连续的对话历史。session 会从文件系统加载历史记录，上次的对话内容下次还在。

上下文（context） 是模型在一次推理里能"看到"的所有内容：系统提示、对话历史、工具调用和返回结果、附件，全部计入，受模型 context window（token 上限）约束。

注意：每一次工具调用的输入和输出，都会留在上下文里。调一个 API，请求体和响应体都进上下文。读一个文件，文件内容进上下文。这些都在吃 token，而且一直累积，不会自动清理。

Agentic Loop 是什么

你发一条消息

↓

Agent 思考

↓

调工具（结果留在上下文）

↓

再思考 → 再调工具 → ……

↓

最终回复你

处理简单任务，这个循环跑几步就完了。但如果任务需要处理几十条数据、每条都要调多个 API，上下文会越来越大。

Sub-Agent 是什么

Sub-agent 是从主 agent 的一次运行中派生出来的后台 agent，运行在自己独立的 session 里，完成后把结果 announce 回发起方。

重点：Sub-agent 有自己的上下文，从零开始，和主 agent 完全隔离。跑完之后，这个 session 可以直接销毁。

Sub-Agent 怎么配置

这里有个很多人会误解的地方，值得单独说清楚。

重点：Sub-agent 不是在 openclaw.json 里注册的独立 agent，而是主 agent 在运行时通过 sessions_spawn 工具动态创建的临时会话。不需要提前配置，不需要独立 workspace，不需要配置任何通讯渠道。

主 agent 正常注册（在 openclaw.json 的 agents.list 里）：

{  "id": "my-agent",  "name": "公众号整理师",  "workspace": "~/.openclaw/workspace",  "model": {    "primary": "provider/claude-opus-4-6",    "fallbacks": ["provider/claude-haiku"]  },  "skills": ["weixin-reader", "feishu-doc", "web-fetch"]}

主 agent 收到命令，直接调用 sessions_spawn，sub-agent 就动态创建了：

sessions_spawn({  task: `你是公众号整理子代理，负责执行一次整理任务。执行步骤：1. 登录内容源服务获取 token2. 获取文章列表（48小时内）3. 按用户订阅过滤4. 生成结构化笔记5. 追加到飞书文档  `,  label: "公众号整理任务",  mode: "run",           // 一次性执行，不保留会话  cleanup: "delete",     // 完成后自动删除  runTimeoutSeconds: 300,  model: "provider/claude-haiku"  // 覆盖成便宜的模型})

Sub-agent 默认继承主 agent 的 workspace、skills、tools——所以 weixin-reader、feishu-doc 这些 skill 直接可用，不用重新配置。唯一需要显式指定的是 model，因为你通常不想让执行层也跑 Opus。

提示：Sub-agent 的配置 = sessions_spawn 的参数，不需要其他任何东西。

我遇到的问题

我在用 OpenClaw 做一个公众号学习笔记 agent，具体任务是：每天抓取订阅的公众号文章（48小时内），过滤掉已处理的，获取全文，用固定格式整理成结构化笔记，最后追加到飞书文档里。

整理后的笔记长这样，每篇格式固定，覆盖技术解读、产品发布、观点评论各种类型：

## 大白话讲清楚OpenClaw的记忆术来源：娇姐话AI圈 · 2026-03-14 | 类型：技术解读一句话概括OpenClaw 通过"精简索引 + 按需读取"架构，token 消耗降低 88%（从 50 万+ 降到 6 万）核心内容- 两层记忆架构：每日日志（自动加载当天和昨天）+ 长期记忆 MEMORY.md- memory_search 和 memory_get 两个按需读取工具，平时不消耗 token- MEMORY.md 只存储索引，详细内容存放在独立的 memory/*.md 文件中- 传统方法消耗 50 万+ tokens，OpenClaw 降到 6 万，节省 88%关键数据- 传统方法每次对话基础消耗 ≈ 12,500 tokens- OpenClaw 方法 ≈ 500 tokens，降幅约 88%- 每天节省约 110,000 tokens---## 安全版 OpenClaw 小龙虾也来了，支持 10000+ Skills来源：逛逛GitHub · 2026-03-14 | 类型：产品发布一句话概括讯飞推出 AstronClaw，采用沙箱隔离技术的安全版 OpenClaw，云端一键部署，支持 10000+ Skills核心内容- 采用 Sandbox 沙箱隔离技术，数据全程被守护，不用担心敏感信息泄露- 云端部署，点击"立即部署"后 1-2 分钟即可使用，无需折腾环境配置- 支持企业微信、钉钉、飞书三大办公 IM，接入配置简单- 自带 Skills 市场，官方精选 130+ 高质量 Skills 已预装，总计支持 10000+ Skills- 汇聚多款旗舰级大模型：星火 X2、MiniMax-M2.5、Kimi-K2.5、GLM-5关键数据- 10000+ Skills 支持，130+ 官方精选 Skills- 1-2 分钟完成部署- 基础版 16.8 元/月（新用户 1 折）---## 未来软件的用户将不是人来源：小互AI · 2026-03-14 | 类型：观点评论一句话概括Box CEO 认为未来软件最大的用户群是 AI Agent，一家公司里 Agent 数量可能是员工的 100 到 1000 倍核心内容- Agent 已不只是聊天机器人，有计算环境、能写代码跑代码、能调 API、有长期记忆- 没有 API 的软件对 Agent 来说就是不存在的，Agent 只会用最好的工具- 按人头收费的时代要结束，83% 的 AI 原生 SaaS 公司已在用消耗制- 知识工作者的角色正在转变：从执行者变成 Agent 的管理者关键数据- 全球将有数万亿个 Agent- 70% 的企业到 2026 年将转向使用量计费- OpenClaw 上线一个多月，日活 300 万- 企业里 80% 的工作没有文档化，完全替代企业应用至少还要 5 年

格式固定，逻辑清晰，跑完自动追加到飞书文档里。

问题是：每次任务要处理的文章不止一两篇，是几十篇。每篇都要经过完整流程：登录内容源服务拿 token → 拉文章列表 → 用 weixin-reader 抓全文 → 去重判断 → 用 feishu-doc 写入飞书。每篇文章至少三四次 API 调用。

就这样，跑着跑着就挂了。

各种上下文报错，422，context too long，日志一堆。我当时第一反应是不是哪里写错了，翻了半天，逻辑没问题。

然后开始瞎试：

• 用 /new 开新会话——跑几篇又挂
• 调 agent 配置限制输出长度——没用
• 把处理数量从 50 篇减到 20 篇——挺久了才挂，但还是挂
• 各种优化参数全试了一遍——全没用

根本原因

后来才搞清楚，问题出在上下文的累积方式上。

处理一篇文章的流程：登录拿 token（请求+响应进上下文）→ 拉文章列表（几百条记录进上下文）→ 抓全文（每篇几千字进上下文）→ 写飞书（请求+响应进上下文）。

这些数据处理完之后，不会从上下文里消失，全部留着：

处理第 1 篇：   上下文 +3,000 tokens处理第 5 篇：   上下文 +15,000 tokens处理第 20 篇：  上下文 +60,000 tokens处理第 50 篇：  上下文爆炸 → 422

用 /new 能暂时缓解，是因为它重置了 session，上下文清零了。但下次继续跑，上下文又开始累积，早晚还是挂。减少处理数量也是同理，只是推迟了爆炸的时间点。

注意：问题不在任务逻辑，在于所有文章的处理过程都堆在同一个 session 里，没有任何隔离。

解法：Sub-Agent 隔离

改造思路很简单：不让主 agent 直接处理文章，而是 spawn 一个子代理去处理，子代理跑完销毁，主 agent 上下文始终干净。

# 旧方案：主 agent 直接跑for article in articles:    fetch_token()                # 上下文 +响应    fetch_article_list()         # 上下文 +几百条记录    fetch_full_content(article)  # 上下文 +几千字全文    write_to_feishu(article)     # 上下文 +API 响应# 跑到第 20 篇左右：context 超限，422，整个任务中断# 新方案：spawn 子代理sessions_spawn({    task: "处理文章列表，整理笔记后写入飞书：\n" + article_list,    label: "公众号整理任务",    mode: "run",           # 一次性执行    cleanup: "delete",     # 跑完自动销毁    runTimeoutSeconds: 300,    model: "claude-haiku"  # 执行层用便宜的模型})# 主 agent 上下文：只增加了 spawn 调用本身，几乎不变

子代理在自己的独立会话里处理所有文章，所有 API 调用、全文内容、中间状态全部留在子代理上下文里。处理完，子代理销毁，垃圾一并清空。主 agent 只看到一个 spawn 调用和最终结果摘要。

参数说明：

改造前后对比

Token 消耗降这么多，原因是两个：主 agent 不再累积执行中间数据；执行层换成了 Haiku，单价差了好几倍。

什么时候该用 Sub-Agent

不是所有任务都需要 Sub-Agent，用错了反而增加复杂度。

小结

问题的本质是职责没有分离。

主 agent 既做调度，又做执行，上下文里混了所有中间状态。任务一多，自然撑不住。

Sub-Agent 把执行层隔离出去，主 agent 只负责调度和决策，上下文始终轻量。子代理跑完销毁，干净利落。

重点：主 agent 做大脑，子代理做手。改造完之后，50 篇文章跑得稳稳的，那些莫名其妙的 422 报错再也没出现过。