小七：下面这个问题比较通用。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 me，Codex 也有类似功能。模型会帮你 review 一下这个工具有没有风险，是不是访问了不该访问的东西。它会判断这个事情要不要做。如果不确定，再来问你。
此外，我还在看另外一个方向。Codex 开源了一套沙盒系统，它的 「CLI 是开源的」，里面那套沙盒系统其实可以拿来用，也可以移植到其他 Agent 里。
但我试过之后发现，这套沙盒系统有个问题：太严格了。如果真的打开，你很可能连自己系统里装的一些全局包都没法正常运行。比如 npm 安装的某个工具，或者 Homebrew 装的工具，因为沙盒限制，执行沙盒之外的命令就不正常。
这块我现在还没想好。引进来之后，对模型限制太大，暂时没有考虑太多。
还有一个我现在也在做、也在推动其他人做的方向：把 Agent 里的敏感信息做加密。不管是数据库，还是 key。
加密不是不让用户访问或导出，而是当其他 Agent 或 AI 来读取你的敏感信息时，你能够感知到，让用户去授权。这一步很重要。
如果每个 Agent 客户端都能保护用户敏感信息，那即便不小心读到，也不会有太大泄露风险。
现在最怕的是：我的 AI 读了一下 secret，或者读了一下某个 key，它不光发给模型服务，还存在本地数据库里。又来了一个 AI，把它再读一遍。每个 AI 的数据库里都存了一份你的密码，最后全世界都知道你的密码了。
这是现在我们做的一些限制。但我觉得还不够好。现在很多做安全或攻击研究的人，已经在用很先进的模型拼命找漏洞。所以我们的防御肯定远远不够。
但如果沿着这个方向继续走，又很可能让 Agent 客户端变成一个限制非常多的东西，模型可能会笨得令人发指。
所以这块我没有想得特别好。我觉得现阶段能做到最基本的围栏，让用户先正常把事情跑下去。后面希望像开头说的客制化键盘一样，有更多安全领域的人，或者有更好想法的人，把这些能力加入到 DeepChat 或其他 Agent 里。
灰灰：Memory 这一边的一些安全机制主要有这些：Agent 隔离，不同 Agent 有不同记忆。像我的研究生朋友可能有好几个不同角色的 Agent，不同 Agent 在专注某件事情时，它们的记忆应该不一样。这也在一定程度上起到了安全隔离。
还有审计日志和事件广播，我都刻意做成没有正文内容，只有编号、动作、数量。这样不会有任何记忆正文泄露。