开篇：我的Agent"痴呆"了

去年9月份正式做AtomStorm 之前，4个月烧了2万刀Token，全球首款Skills Vibe Agent终于开启邀请内测，我也终于敢说：Sam Altman预言的超级个体，可能真的来了，我用LangChain搭过三版原型，每版都让我怀疑人生。

第一版是标准的ReAct模式，Demo阶段看起来挺聪明，能跑，但稍微聊深一点，超过10轮就开始胡说八道。第二版我天真地加了Memory模块，好了一点，但一遇到复杂的多步骤任务就扛不住。第三版咬牙上了LangGraph，流程倒是可控了，但Context管理依然是一塌糊涂。

一开始我以为是Prompt写得不够好。为了修正它，我加了大量的角色设定，甚至在System Prompt里用大写字母强调"你要记住上下文"，折腾两天，完全没用。

后来我硬着头皮把完整的对话日志拉出来，逐行分析，才发现问题根本不在Prompt——

Context Window撑爆了。

我算了一笔细账：系统提示占3000 token，工具描述4000，前面稍微聊个30轮，对话历史就累积了近10万 token。等轮到处理用户当前这句话时，模型的"注意力"早被稀释成渣了。

以一个典型的PPT生成任务为例。用户和Agent交互20轮，光对话历史就累积了6万 token。再加上系统提示、工具描述、RAG检索结果，轻松突破10万。

很多人看到Claude 4.5 Opus支持200K、GPT-5.2有400K，觉得"够用，随便塞"。

这简直是天大的误区。

Context Window不是硬盘，它是内存。它不存储记忆，它分配注意力。你塞进去的每一段文字，都在抢模型的注意力资源。塞得越多，每个部分分到的注意力就越少。

到了后期，模型名义上"知道"前面的信息，但实际上根本没在"关注"。

这就是为什么现在圈内开始提Context Engineering。它关注的不是"单次输入怎么写"，而是"在整个对话周期里，怎么分配和管理模型的注意力资源"。

这就是我想在本文中分享的核心：怎么通过Context Engineering，把一个"痴呆"的Agent救回来，并最终演变成我在AtomStorm里实现的Skills Vibe Agents。

Part 1：为什么你的Agent会"变傻"？

大模型的Context Window更像是一个"注意力预算"。

举个真实的例子。你主持一个只有1小时的紧急会议。为了让所有人充分表达，你让20个人轮流发言，每人说了3分钟。会议结束后，你能精准复述出谁说了什么？

大概率你只记得最后两三个人的重点，前面的全糊了，甚至开始混淆谁说了哪句话。

大模型也一样。它不是像电脑那样"记住"你给的所有信息，而是通过Attention机制在进行"即时关注"。受限于算力和架构，它只能重点处理一部分，其他的就会自动退化为背景噪音。

我管这个现象叫"上下文腐烂"（Context Rot）。

在AtomStorm早期的内测中，我们观察到几个典型症状，大家看看眼不眼熟：

• • Agent开始重复问你之前明明答过的问题（比如"用户偏好什么风格？"问了三遍）；
• • 明明工具列表里挂着，Agent却说"我无法执行这个操作"；
• • 输出质量肉眼可见下滑，从逻辑严谨的策略级变成东拉西扯的敷衍级；
• • 最离谱的是，它开始一本正经地"编"之前根本没提过的约束条件。

模型不是不聪明，是我们把它的注意力搞散了。

刚才算过那个账：3000 token的系统提示，聊100轮就是被读100次。光是这几千字就吃掉了30万 token的预算。如果每个轮次还塞进一堆无用的RAG检索结果，真正的"当前指令"能分到的注意力几乎为零。

所以，Context Engineering的核心任务，就是在一个实时的、动态的、有限的窗口里，决定哪些信息必须留，哪些必须丢。

Part 2：Context Engineering四大实战策略

搞清楚问题，解法就清晰了。以下是我在AtomStorm开发过程中摸爬滚打出来的四条路子，每一条都是真金白银换来的教训。

策略一：系统提示别写小作文

很多人写System Prompt有"小作文情结"。角色设定、行为规范、输出格式、注意事项...一股脑全塞进去。我见过最夸张的，光System Prompt就写了5000字，看着挺专业，模型直接懵了。

问题是，这些内容每一轮都要被模型读一遍。这就像开会时，每发言一个人，主持人都要把公司章程从头读一遍，效率极其低下。

我现在在AtomStorm里用的是分层注入法。

代码逻辑大概是这样的（示例）

# 核心层 (常驻内存 < 500 tokens)
core_identity: |
  你是AtomStorm主Agent。你的职责是理解用户意图，并将任务分发给对应的Skills。
  约束：只做规划，不执行具体细节。

# 场景层 (动态加载)
scenarios:
  ppt_generation: |
    当前任务涉及PPT生成。
    - 风格：默认商务极简风，除非用户指定。
    - 结构：封面 -> 目录 -> 正文(3-5页) -> 结尾
    - 工具优先级：outline_generator > slide_writer

# 示例层 (用完即删)
few_shots:
  - user: "帮我做个AI汇报PPT"
    agent_thought: "检测到'PPT'关键词，触发ppt_generation场景..."

核心层只放身份和关键约束，500 token以内，必须常驻。场景层放具体任务的详细指引，只有识别到相关场景才加载。至于Few-shot例子，只在第一轮用来校准口味，后面直接删掉。

这招下来，System Prompt的实际消耗从平均4000 token降到了800 token左右，对话轮数却反而提升了。

策略二：工具不是越多越好

用过Function Calling或MCP的兄弟应该都知道，工具描述也是要吃Context的。

我见过一个 Agent，给上面挂了40多个工具，光工具描述（Description + Parameters Schema）就吃了8000 token。开发者还在纳闷："为什么老是调用错工具？"

工具太多，模型自己也面临"选择困难症"。

我现在的原则非常严格：单个场景下，暴露给Agent的可视工具不超过7个。

这真不是拍脑袋，这是经典的米勒定律——人类的工作记忆广度大概就是7±2。看起来模型比人强，但在处理工具语义时，这个规律依然适用。

除此之外，我还加入了一个"工具意图预判"机制。

伪代码逻辑：

def get_relevant_tools(user_input, full_tool_registry):
    # 第一步：轻量级模型预判意图
    intent = lightweight_model.classify(user_input) 
    # 返回如：["image_gen", "web_search"]
  
    # 第二步：从全量库(100+)中只取相关工具
    active_tools = [t for t in full_tool_registry if t.tag in intent]
  
    # 限制数量：只返回置信度最高的Top 5
    return sorted(active_tools, key=lambda x: x.score)[:5]

这样每一轮Agent看到的工具列表，都是"刚刚好"那几个。skills同理处理，描述精准，触发率也远高于claude code的skill触发。

如果你是claude code老司机，必然遇到，纳闷为什么skill不触发，解法是采用hooks，通过脚本来处理强制激活，而这些，有些水货自媒体是不会教你的，这个话题我们回头聊。

策略三：RAG别一股脑塞

这条是针对检索增强场景的。很多人做RAG喜欢"检索了就全塞"。召回了10个文档片段，不管相关度是0.9还是0.5，一股脑扔给模型。

结果Context里一大半都是"可能有用"的废话，真正需要的那个金句反而被淹没了。

我的做法是Just-in-Time Retrieval（即时检索） + Re-ranking（重排序）。

像狙击手一样，先让模型判断"当前问题是否需要外部信息"，如果需要，再针对性检索。检索回来的结果（比如10条），必须过一轮相关性打分，最后只把分数最高的前1-2个片段塞进Context。

这会让Agent稍微"慢"一点点（多了个重排序步骤），但准确率提升了不止一个量级。让Agent说"我需要更多信息"并精准检索，比一开始就喂撑它强一百倍。

策略四：长任务要分而治之

那种需要聊几十轮甚至上百轮的长任务，光靠上面三条还不够。我总结了"三板斧"。

第一斧：压缩。
每隔一定轮次（比如每10轮，后端可配置），后台自动生成一份语义摘要，替换掉原始的对话日志。
前20轮的原始对话（6000 token）  压缩摘要（500 token）
摘要保留关键决策、已确定的参数、用户的否定反馈。如果Agent后续需要细节，再去存档库里调取原文。

第二斧：笔记。
我给Agent设计了一个专门的<field_notes>区域。就像探案记笔记一样，让Agent主动把重要信息记下来。
比如用户说"我不喜欢红色封面"，这句如果不记，20轮后模型可能又给你推个红色的。但有了Note机制，模型会主动写入：User_Preference: color = NOT red。这个Note块会在每一轮被高亮读取。

第三斧：拆分。
把大任务拆成多个子任务，每个子任务用独立的子Agent处理，各自维护独立的Context。主Agent只负责分发和拼装。

Part 3：在AtomStorm里怎么落地的

方法论讲了一堆，回到产品。讲讲我在AtomStorm里的实际落地——也就是我称之为Skills Vibe Agents的架构。

这套架构的设计理念其实很简单：用户只管用自然语言说需求，Agent自动匹配和组合不同"技能"（Skills）来完成。

比如用户说："帮我做一套介绍Claude Skills技术的PPT，要深度研究搜集最新数据"。

AtomStorm的执行流大概是这样的：

1. 1. 主Agent 听到需求，判断这是复合任务。
2. 2. 触发两个个Skills：

• • skill_deep_research (负责搜索和爬取数据)
• • skill_ppt_creation_code (负责做PPT)

• 3. skill_deep_research 在自己的Context里进行深度研究，把数据整理好传给主Agent。
• 4. skill_ppt_creation_code 拿到数据生成大纲，与用户确认需求，生成最终PPT。

这里的核心优势在于渐进式披露、按需加载技能提示。

AtomStorm接入了Model Context Protocol (MCP)，目前挂载了20多个MCP工具。但这里有个坑，我一开始直接全量挂载，结果主Agent直接"瘫痪"了——光是理解每个工具的权限就耗尽了它的脑力。

现在的做法是二级分发。

主Agent手里只捏着"元技能"（Meta-Skill）。比如它只知道"有一个能做PPT的技能"，但它不知道这个技能底下连接了文档解析、搜索、slide创建等细碎的MCP服务。

只有当任务真正分发到skill_ppt_creation_code时，这个Skill才会去连接具体的MCP端点。

做PPT的设计Skill，根本不需要知道深度研究Skill具体是怎么做的，那些复杂的中间结果和过程深度研究自己消化就行。

等它执行完，只把"最终数据"这个结果传回来。主Agent的Context会卸载掉深度研究的skill，加载PPT制作的skill，始终保持着清爽，只包含skill任务状态和任务的产出。

流式渲染的取舍

还有个细节。AtomStorm支持实时渲染，用户能边聊边看PPT、架构图像魔法一样一点点长出来。

这背后也有Context Engineering的考量。如果等全部生成完再渲染，体验是割裂的——你等半天，"啪"一下结果全出来了。但如果每一步的中间结果都塞进Context，token会指数级暴涨。

我的最终方案是渲染状态与对话状态分离。



渲染相关的中间数据（比如SVG代码、DraftJS的JSON状态）走独立管道存储，根本不进LLM的Context Window。Agent只在Context里保留极简的状态摘要，比如："第三页PPT已完成，主题是市场分析，包含3个数据图表"。

这样既保住了那种"看着东西生长出来"的爽感，又把Context开销压到了最低。

---

写在最后

Context Engineering这事儿，说玄乎也玄乎，说简单也简单。本质就四句话：

1. 1. 把Context当预算管，每个token都是真金白银的成本。
2. 2. 动态优于静态，信息用完就清，别占着茅坑不拉屎。
3. 3. 复杂任务拆开干，各自维护干净上下文，别让一家之主管所有家务。
4. 4. 给当前任务留够注意力带宽，让模型时刻保持"满血"状态。

说起来容易，落地的时候坑还是很多的。我在AtomStorm里也是反复踩、反复调参数，到现在也不敢说是最优解，只能说是"目前能跑通的最优解"。

但有一点我越来越确信：Agent开发的下半场，拼的绝对不是谁Prompt写得花哨，而是谁对Context的理解更深，谁更懂得如何像管理团队一样管理模型的注意力。



这条路才刚刚开始，如果你也在做Agent开发，不管是用LangChain、LlamaIndex还是自己手搓，欢迎找我聊。

本文配图均由AtomStorm产品生成，AtomStorm现在开放少量内测名额，现已不再通过其他渠道发放，感兴趣的私信（评论区留言），一起交流下踩坑心得，或者单纯骂骂LLM的不靠谱也可以。