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来了，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，而是一个基于状态机的路由函数。以下是基于