OpenClaw 的 ClawHub 市场已有 1w+ Skills，每天还在疯涨——听起来很美，直到大量恶意 Skills 被扒了出来。有个“邮件清理”Skill，装上第一次运行就把你的 .env、SSH 密钥打包发出去了。ClawHub 下载的是裸 zip 包，没签名、没校验、没沙箱，Skill 一加载就继承了 Agent 的全部权限——能读你的文件，能 rm -rf，为所欲为。这就好比你雇了个实习生，没做背调，第一天就给了 root 权限。所以也就有了“ClawHub 一半是毒药”的说法，企业要用 OpenClaw 或其他 Agent，必须要解决好安全问题，Skills 安全就是 OpenClaw 企业落地一个核心问题。 私有化 Skills Registry 要做的，就是在 Agent 和 Skill 之间加一道安检门——发布前扫描、签名验证、沙箱隔离、权限最小化，让每个 Skill 从“我信你”变成“我验过你”。
每次对话结束，AI agent 就会忘记一切。这不是比喻。OpenClaw 的默认 memory-core 把记忆写进本地 .md 文件，当文件积累到上百个，agent 没有能力在每次对话前全部扫描——记忆变成了需要你主动提示才能检索的档案馆。更根本的问题是：记忆无法跨 agent 共享。你告诉过主 agent 的偏好，coding agent 从零开始；每个 agent 都活在自己的信息孤岛里。理想的 agent 记忆系统应该满足四点：自动注入、跨 agent 共享、新记忆实时可用、数据留在本地。带着这四个要求，我开始寻找答案。这篇文章 介绍了 mem9 作为 AI agent 记忆方案的思路，给了我很大启发。但原文使用的是 mem9.ai 云服务——记忆数据存在远端。考虑到 agent 的记忆里沉淀着大量个人习惯、工作偏好和私人决策，这些数据不应该离开本机。因此本文在此基础上进一步，把整套系统搬到本地自托管。
Agent 能写代码、能调工具，但它不了解你团队的规范、流程和质量标准，每次对话都从零教起，既低效又不稳定。Skill 机制正是为解决这个问题而生：把你的经验和流程结构化地交给 Agent，让它像拿到工作手册一样自主执行。本文从设计原理、编写方法到评测迭代，梳理 Skill 的实践路径，帮助开发者打造高效易用的Agent Skill。
本文将分享阿里集团在 AI 代码评审方向“历时一年半”、“数万亿 Token 真实场景打磨”的探索现状，以及我们联合南京大学研发效能实验室开源的、汇聚 80 多位资深工程师进行多轮交叉标注的业界首个多语言、具备存储库上下文感知的 CodeReview Benchmark，旨在为行业提供更精准的质量评估标准。
近期 OpenClaw 在开发者社区中备受瞩目。它赋予了 Agent “看见”和“操作”的能力，开启了自动化复杂任务的想象空间。 但随着交互加深，一个普遍的“上下文管理困境”也随之浮现：Agent 常常遗忘之前交代过的信息，正如一些开发者在深入体验后指出的，尽管 OpenClaw 备受赞誉，但在长期使用中，“它完全忘记了我给它的API密钥”。这种不稳定的“记忆”不仅影响了 Agent 的自主性，也暴露了当前 AI Agent 在长周期任务中管理海量、动态上下文的普遍难题。
在搜索系统中， C++ 引擎长期扮演着底层核心基础设施的角色：性能敏感、逻辑复杂、变更频繁，同时承载着大规模线上流量的稳定运行。随着业务持续发展和技术架构不断演进，我们逐步意识到：在高频迭代背景下，回归能力也需要同步升级。 过去一年，我们围绕搜索 C++ 引擎展开了一次系统性的回归能力工程化建设。本文将介绍这次能力升级的背景思考、核心设计思路以及落地实践。
建议有打算深入了解OpenClaw的同学优先看OpenClaw源码和官方文档，目前该项目正在高频迭代中。本文重点从核心框架、通信机制进行介绍，争取让你看完本文后知道OpenClaw是怎么运作的，以及其能力边界在哪里。以及尤其希望大家注意的，是OpenClaw的安全风险，如果选择部署OpenClaw，就按最坏的打算(数据全Open)去对待自己机器上的数据。
写在前面，由于现在LLM生成内容千篇一律，作者尽量自行撰写核心内容，LLM仅限于润色优化，争取把整个开发迭代历程完整呈现出来供学习交流。
