
OpenClaw:深度解读OpenClaw上下文工程架构OpenClaw 是一个开源的个人 AI 助手平台,支持通过 WhatsApp、Telegram、Slack、Discord 等多种消息渠道与用户交互。该项目在提示词工程、系统架构和工具集成方面展现了成熟的工程实践,为构建生产级 AI Agent 系统提供了宝贵的参考范式。 [图片] 核心架构概览 OpenClaw 采用了"Gateway + Agent Runtime"的分层架构: * Gateway 控制平面: WebSocket 服务器,统一管理所有消息渠道、会话状态、工具调用和事件分发 * Pi Agent Runtime: 基于 RPC 模式的 Agent 执行引擎,负责与 LLM 交互和工具执行 * 多渠道适配层: 支持 10+ 种消息平台的统一接入和路由 * 工具生态系统: 70+ 个内置工具,涵盖文件操作、Shell 执行、浏览器控制、跨会话通信等 提示词架构的层次化设计 动态组装机制 OpenClaw 的提示词系统采用模块化、分层注入的设计,核心函数 buildAgentSystemPrompt 负责根据运行时上下文动态组装完整的系统提示词。
聊聊关于上下文工程的Agent Skills开源项目上下文工程的Agent Skills来了,CC、Codex直接用 GitHub上最近出现了一个非常火的项目Agent-Skills-for-Context-Engineering,发布不到一周就斩获了2.3k Stars。为什么它能瞬间引爆社区?因为站在2025年末的节点上,我们已经受够了那些只存在于大厂白皮书里的Context Engineering(上下文工程) 理论。 [图片] 对于每天在终端里使用AI编程的极客来说,我们不需要另一篇教我们“什么是上下文”的论文,我们需要的是能直接装进Claude Code里的武器。这个项目正是填补了这一空白!它将晦涩的上下文管理策略,封装成了即插即用的10个Agent Skills。利用Claude的自动按需加载与模型自行触发机制,它让AI终于学会了像资深工程师一样自己管理“内存”。这就是一套Context Engineering的最佳实践工具库,爽点就在于:你只管提问,剩下的脏活累活,让Skill自动替你完成。用之前先把今天这篇文章看完,对每一个SKILL.md有一个大致了解。 项目地址:github.com [图片] Skill的解剖学:一个“能力包”长什么样? 以下是一个Skills的文件结构,不熟悉的朋友可以了解一下。 my-skill/ ├── SKILL.md # 核心:包含元数据(YAML)和指令(Markdown) ├── scripts/ # 可选:Python/Bash脚本,供Agent调用 ├── references/ # 可选:长文档、API手册、参考资料 └── assets/ # 可选:模板文件、静态资源 以此构成了Agent的技能包。 重新定义上下文:Agent的注意力预算 上下文是稀缺资源,是Agent的全部世界。 上下文的结构 项目作者在第一个skill context-fundamentals 中将上下文拆解为五个核心组件。这种分类法能帮您清晰地识别出“Token究竟花在哪了”: * 系统指令 (System Prompts):Agent的灵魂,规定了行为边界和任务目标。 * 工具定义 (Tool Definitions):Agent与外部世界交互的API规范。 * 检索文档 (Retrieved Documents):通过RAG引入的外部知识。 * 消息历史 (Message History):对话的上下文流。 * 工具输出 (Tool Outputs):最危险的部分。研究显示,原始的工具返回结果往往占据了上下文80% 以上的体积。 渐进式披露:按需加载的艺术 如果您有100项专业技能,全部塞进系统提示词会瞬间耗尽Agent的注意力。项目作者提出的“渐进式披露”策略,是解决该问题的金钥匙: * 元数据检索:初始状态下,Agent只读取所有Skill的 name 和 description。 * 基于语义的动态路由:这是最性感的部分。Agent会根据你的Prompt(例如“帮我分析一下这个财报”),在后台自动进行语义匹配。如果发现某个Skill的 description 描述了相关能力(“提取财务关键指标”),它就会自动“调包”——将该Skill的详细 SKILL.md 加载到上下文中。 * 优势:这就像操作系统的页交换机制,确保模型始终在处理与其当前任务最相关的“高信号”Token。 诊断退化:为什么模型会越聊越笨? context-degradation 是第二个Skill,在这个skill中,项目作者总结了长对话中性能下降的必然规律。理解这些模式,能帮您在调试时少走弯路。 迷失在中间 (Lost-in-the-Middle) 这是最著名的衰减现象。模型对上下文两端的信息记忆清晰,但对中间部分的信息召回率极低: * 数据支撑:研究表明,信息放在中间位置时,召回准确率可能比放在两端低10-40%。 * 工程建议:永远将最重要的约束条件放在开头,将当前最紧急的任务目标放在结尾。 原理解析:用Python模拟注意力衰减项目中的 degradation_detector.py 脚本包含了一个有趣的函数 _estimate_attention,它用代码量化了这种“U型曲线”:def _estimate_attention(position, total, is_beginning, is_end): if is_beginning: return 0.8 + np.random.random() * 0.2 # 开头:高关注 elif is_end: return 0.7 + np.random.random() * 0.3 # 结尾:次高关注 else: # 中间:注意力塌陷区 # 模拟了一个从两端向中间递减的U型谷底 middle_progress = (position - total * 0.1) / (total * 0.8) base_attention = 0.3 * (1 - middle_progress) + 0.1 * middle_progress return base_attention 这段代码直观地说明:任何放在 else 分支(中间区域)的关键信息,都有70%的概率被模型忽略。 上下文中毒 (Context Poisoning) 一旦Agent在某一步产生了幻觉或错误,如果不及时清理,后续所有的推理都会基于这个错误前提。 * 连锁反应:错误1 -> 基于错误的决策A -> 错误2 -> 逻辑崩塌。 * 识别信号:如果Agent突然开始坚持执行错误的指令,或者反复调用一个错误的参数,这就是中毒的征兆。 常见的其他退化模式 * 上下文干扰 (Distraction):无关信息过多,消耗了模型的注意力配额。 * 上下文混淆 (Confusion):模型无法区分不同任务阶段的相似指令。 * 上下文冲突 (Clash):多份检索文档中的过时信息与实时事实产生矛盾。 压缩与优化:每一Token都要物尽其用 context-compression和context-optimization是第三和第四个skill,当您的上下文水位达到70%时,优化就不再是选项,而是必须。 观察掩码 (Observation Masking) 这是项目作者极力推荐的高级技巧。当Agent读取一个几万字的日志或文件时,不要让这些原文留在上下文中: * 处理流程:读取全文 -> 提取核心结论 -> 将原文从上下文抹除 -> 替换为引用ID。 * 效果:上下文体积骤降90%,同时保留了“回溯能力”。 锚定迭代摘要 (Anchored Iterative Summarization) 传统的“全量总结”会随着次数增加而丢失细节。项目作者提出的方案是维护一个结构化的状态块: * 会话意图:用户最终要解决什么问题? * 状态清单:哪些文件已修改?哪些测试已通过? * 决策记录:为什么我们不使用旧方案? * 下一步:清晰的Action Item。 原理解析:结构化摘要的Prompt模板传统的摘要是“请总结以上对话”,而Context Engineering的摘要指令是填空题。在 context-compression Skill中,定义了这样的强制结构: ## Session Intent [用户原本想解决什么问题?] ## Files Modified - auth.controller.ts: Fixed JWT token generation - config/redis.ts: Updated connection pooling ## Decisions Made - Using Redis connection pool instead of per-request connections ## Next Steps 1. Fix remaining test failures 2. Run full test suite 这种结构的妙处在于,它迫使模型把“非结构化的对话流”转换成了“结构化的状态快照”。当上下文重置时,Agent读到的是这份快照,而不是模糊的回忆。 KV-Cache命中率优化 在生产环境中,延迟和成本是绕不开的。项目作者指出,优化KV-Cache命中率能带来10倍以上的性能提升: * 保持前缀稳定:系统提示词和工具定义应放在最前方且保持不变。 * 避免动态干扰:不要在系统提示词开头放每秒都在变化的“当前时间戳”,这会让所有Cache瞬间失效。 架构设计:多Agent协作的底层逻辑 项目作者在第五个skill multi-agent-patterns 中反复强调:多Agent不是为了排场,而是为了“上下文隔离”。 为什么要进行上下文隔离? * 干净的窗口:每个子Agent只关心自己的那一小块任务,不受其他分支信息的干扰。 * 专用的工具:减少候选工具数量,提高模型调用工具的准确率。 * 故障阻断:一个子Agent的中毒不会直接传染给整个系统。 实战案例分析:X-to-Book系统 项目中的这个案例完美展示了上下文如何有序流动: [图片] * 抓取代理 (Scraper):任务是高并发抓取。它只拥有抓取工具,其上下文在任务结束后立即清空,数据存入物理文件系统。 * 分析代理 (Analyzer):任务是提取主题。它从文件读取数据,通过小窗口分批处理,只输出精炼的摘要。 * 编排代理 (Orchestrator):它不需要看到任何推文原文!它只看到摘要,负责在各阶段间“接力”。 解决“传声筒问题” 主管Agent在转述子Agent的结论时容易产生偏差。项目作者提供的解决方案是: * 直连模式:允许子代理直接向用户或最终文档写入结果。 * 结构化输出:强制要求子代理返回JSON格式,由程序而非模型进行合并。 原理解析:Supervisor的路由逻辑实现在 multi-agent-patterns 技能中,Supervisor的核心并不是一个复杂的Prompt,而是一个基于状态机的路由函数。以下是基于