小七下面这个问题比较通用。DeepChat 的 Skills、MCP还有 Agent Memory分别解决什么问题夕阳针我来讲下 MCP 和 Skills。先说 MCP。我们认为 MCP 是一个资源包。通过一个 MCP可以提供一堆资源包括工具、prompt还有一些 resource比如一张图或者一段代码片段都可以通过 MCP 这个协议提供给模型。一个比较有意思的例子是 MiniMax。他们在 Coding Plan 里面提供了一个 MCP 服务。早期 MiniMax 的模型没有视觉能力它就通过 MCP 里一个 understand image 工具调用识图能力给模型补充视觉能力。所以 MCP 就是一个扩充工具包让你把原先的能力往外拓一层让模型能操作更多相对稳定的东西。Skills 更有意思。它比 MCP 更复杂一点更主要作用的是说明书。当然它可能也会带上一些额外产物比如脚本但很多时候它就是大模型的说明书。它会告诉你怎么完成一件事怎么用一个工具甚至怎么用一个 MCP。我自己做很多东西时会用 Skills MCP 的形式提供能力。比如我用 JS 写一个 MCP Server里面包含一些工具。然后我再给这个 MCP Server 写一个 Skill把两个东西打包在一起发出去。模型拿到 Skill 之后会自动安装这个 MCP装完之后就拥有了这个能力可以跑起来。DeepChat 里的 Computer Use 就是这样的方案。它背后真正接到电脑上的桥是通过 Cua 项目提供的驱动来实现的。在它前面有一个 MCP Server这个 MCP Server 怎么启动、怎么接到 DeepChat、DeepChat 对它有什么要求其实是通过一个 Skill 来完成的。所以当用户在 DeepChat 里启用了 Computer Use 这个插件之后Agent 会先看一个 Skill叫 How to use computer use。看完之后Agent 就明白每个工具应该干什么。这比在 MCP 上写工具描述要精准得多。工具描述只能告诉你这个工具是扳手这个工具是锤子。但 Skills 可以讲清楚你要完成这个事情得先用锤子锤钉子再用扳手拧螺母。这样最后做出来的事情会更可靠。小七那灰灰来分享下 Memory灰灰对我讲一下记忆这边。以前的 Agent简单来说可以理解成金鱼记忆7 秒钟就忘了。每开一个新会话它都对你一无所知。你最多只能在 system prompt 里写一段人设或规则而且聊着聊着随着上下文扩大有时候还会被冲淡。我们想要的是它能记住我上周跟它讲过的东西我的博客用什么框架我讨厌什么样的代码注释。这样我再开一个新会话它还能知道我的偏好。做 Memory 之前我调研了一段时间。核心的结论是记忆不等于 RAG。很多人会理所当然地把外挂知识库当成记忆。但如果只是把聊天记录塞到向量库里再检索那只是搜索性的日志意义没那么大。真正的记忆要走完一个完整闭环什么时候应该记什么时候应该巩固什么时候应该遗忘需要的时候才召回最后还要能从一堆事实里长出洞察。检索仅仅只是其中的一个步骤而已。这个“长出洞察”其实是我目前还没做的内容。我希望后面可以通过一些手段对以往 Memory 进行总结长出新的 Skill或者更新已有 Skill。这部分我跟 PsiACE 沟通时感觉意义是最大的。但无法避免的是它会带来越来越多 token 消耗。回到 DeepChat现在整个 Memory 架构用一句话概括就是Tape 是账本记忆层是大脑。Session Tape 是原始事实的流水账。我做什么事情都给它记下来就像小时候写流水账日记一样。结构化消息、工具调用/结果、运行时事件和关键 anchor 会进入 session tape。Memory 是从账本里蒸馏出来的耐久结论。它不是把完整上下文都拿下来而是结论性的东西。账本是证据大脑是认知。数据从账本流向大脑。每条记忆都能反查它到底是从哪几个句子、哪几个片段提炼出来的。怎么避免它变成杂乱历史记录这其实是 Memory System 的灵魂问题。首先入口要收紧。不是所有东西都应该记下来。闲言碎语、聊家常这些不应该抽取成记忆。即便进来了也应该快速筛选只保留稳定偏好、项目事实、任务结局、经验教训这几类信息。我设计记忆系统的时候有一个规则只记住最小的、耐久性的结论把过程留在 Tape 上。等需要用记忆时再通过这个结论去找 Tape 里的原始上下文。接下来是写入时的对质。每条新记忆入库之前应该先跟库里最相近的 10 条记忆对质一遍。拿一个便宜的小模型来裁决看是新增、更新旧的、取代旧的还是重复不记。如果和现有记忆有矛盾冲突就应该把这条记忆记录下来不能盲目覆盖。这个过程可能还需要和人互动这部分的交互我还在思考。再接下来是遗忘。记忆会有衰减有半衰期。长期没有用、从来没有被召回的记忆会被软归档。注意是软归档不是直接删除。因为未来某一天它可能又有用了那时可以重新激活。出口也应该有限制。召回时只取最相关的几条有严格 token 预算。注入的也是相关记忆不会把整个 Tape 完整塞进来。最近我在完善 Memory 可视化补了健康快照报表。因为一开始设计时我没有把 Memory 的可视化展示给用户。用户可能感知不到这个黑匣子是真的存在还是随便乱抽取。所以我把它变成一个可以量化监控的图表有多少条记忆从来没有被访问过有多少条挂着冲突有多少条没有做向量化处理。这些都可以一目了然。这就是目前 DeepChat Memory System 的实现闭环。Agent 安全机制的设计小七刚刚也提到安全问题。Agent 会接触各种文件你们是怎么设计安全机制的夕阳针现在还是比较常规。一方面一些函数会尽量遵循项目的 gitignore以及你设定的 workspace 范围。除非用户特定说去读某个工作区之外的文件否则默认会在提示词里强调不要乱跑。但这个只是很小的限制。第二个是权限系统。我们做了三个权限模式。一个是最标准的什么都问你。一个是大家也用得很多的“油门踩死”所有都不问自动执行。还有一个新加的叫 Approve for meCodex 也有类似功能。模型会帮你 review 一下这个工具有没有风险是不是访问了不该访问的东西。它会判断这个事情要不要做。如果不确定再来问你。此外我还在看另外一个方向。Codex 开源了一套沙盒系统它的 「CLI 是开源的」里面那套沙盒系统其实可以拿来用也可以移植到其他 Agent 里。但我试过之后发现这套沙盒系统有个问题太严格了。如果真的打开你很可能连自己系统里装的一些全局包都没法正常运行。比如 npm 安装的某个工具或者 Homebrew 装的工具因为沙盒限制执行沙盒之外的命令就不正常。这块我现在还没想好。引进来之后对模型限制太大暂时没有考虑太多。还有一个我现在也在做、也在推动其他人做的方向把 Agent 里的敏感信息做加密。不管是数据库还是 key。加密不是不让用户访问或导出而是当其他 Agent 或 AI 来读取你的敏感信息时你能够感知到让用户去授权。这一步很重要。如果每个 Agent 客户端都能保护用户敏感信息那即便不小心读到也不会有太大泄露风险。现在最怕的是我的 AI 读了一下 secret或者读了一下某个 key它不光发给模型服务还存在本地数据库里。又来了一个 AI把它再读一遍。每个 AI 的数据库里都存了一份你的密码最后全世界都知道你的密码了。这是现在我们做的一些限制。但我觉得还不够好。现在很多做安全或攻击研究的人已经在用很先进的模型拼命找漏洞。所以我们的防御肯定远远不够。但如果沿着这个方向继续走又很可能让 Agent 客户端变成一个限制非常多的东西模型可能会笨得令人发指。所以这块我没有想得特别好。我觉得现阶段能做到最基本的围栏让用户先正常把事情跑下去。后面希望像开头说的客制化键盘一样有更多安全领域的人或者有更好想法的人把这些能力加入到 DeepChat 或其他 Agent 里。灰灰Memory 这一边的一些安全机制主要有这些Agent 隔离不同 Agent 有不同记忆。像我的研究生朋友可能有好几个不同角色的 Agent不同 Agent 在专注某件事情时它们的记忆应该不一样。这也在一定程度上起到了安全隔离。还有审计日志和事件广播我都刻意做成没有正文内容只有编号、动作、数量。这样不会有任何记忆正文泄露。