如图 1 个帖子 - 1 位参与者 阅读完整话题
我的华为云的Flexus L 实例IP被 墙了, 上面部署了一个hiddify, 现在没办法使用了. 谁能救救我. 2 个帖子 - 2 位参与者 阅读完整话题
新加坡乌龟抢到了4c24g的VM.Standard.A1.Flex和两个1c1g的VM.Standard.E2.1.Micro，先挂个 探针 玩玩 4 个帖子 - 3 位参与者 阅读完整话题
单例设计模式 什么是单例模式 所谓单例设计模式，就是在软件系统中，某个类只存在一个实例对象，并且也只有一个获得该实例的方法 单例模式有两种方式 饿汉式 懒汉式 步骤如下 构造器私有化 类的内部创建对象 对外暴露一个静态的public方法，用于返回唯一实例（getInstance） 饿汉式 饿汉式是在类加载时就创建并且初始化单例对象，这可能造成资源浪费 package com.hspedu.single; public class Test { public static void main(String[] args) { GirlFrind instance = GirlFrind.getInstance(); instance.show(); } } class GirlFrind{ private String name; private static final GirlFrind gf = new GirlFrind("小花"); private GirlFrind(String name) { this.name = name; } public static GirlFrind getInstance() { return gf; } public void show() { System.out.println(this.name); } } 可以看出，gf在类被加载的时候就已经初始化 懒汉式 懒汉式是在类首次调用获取实例的方法时，才创建对象的单例模式 package com.hspedu.single; public class Test { public static void main(String[] args) { System.out.println(GirlFrind.n1); } } class GirlFrind{ private String name; public static int n1 = 10; private static GirlFrind gf = null; private GirlFrind(String name) { System.out.println("构造器被调用"); this.name = name; } public static GirlFrind getInstance() { if (gf == null) { gf = new GirlFrind("小花"); } return gf; } public void show() { System.out.println(this.name); } } 只有当getInstance被调用时，才会创建gf。 执行可以发现，由于只调用了静态成员，因此只加载了类，因此没有调用构造器。 懒汉式和饿汉式的区别 饿汉式 懒汉式 线程安全 安全 不安全，需要额外处理 资源加载时机 类载入就创建实例 调用getInstance才创建 适用场景 单例对象简单、一定被使用 单例对象开销大 潜在问题 可能造成资源浪费 多线程环境下可能创建多个实例 懒汉式的线程安全版本后期补充 2 个帖子 - 2 位参与者 阅读完整话题
探针提示离线以为是杀龟了，结果是实例再次停止了，重新启动还报错，这种情况只能重建实例了吗？之前就停止重建的… 4 个帖子 - 3 位参与者 阅读完整话题
直接贴命令，这是我的配置，原理发给AI分析 open -n –env CODEX_HOME=$HOME/你的目标文件夹 /Applications/Codex.app –args --user-data-dir=$HOME/你的目标文件夹/electron-user-data 参考： Open Two Codex Accounts on Mac Without Logging Out 1 个帖子 - 1 位参与者 阅读完整话题
都能自动开救援实例去救援了。就是不知道费用多少。 2 个帖子 - 2 位参与者 阅读完整话题
最近把 AWS 网络架构重构了，加了一台 t4g.nano 实例作为核心 Router ，用来管理所有服务器的进出网络。 核心玩法是直接把 sing-box 当成路由器来用，跑下来发现体验超级强大。 实现的功能： 统一进出： 所有服务器的进出网络流量、转发，全部由这台 t4g.nano 托管。 精细控制： 实现了域名过滤、IP 过滤、黑白名单以及端口转发。 安全架构： 整个服务的后端内网全部实现了彻底隔离。 总共进 5000 行 bash 脚本，一键启动实例并配置。极致轻量，t4g.nano 的性能配合 sing-box 绰绰有余，成本极低，功能远超实例安全组+gateway 云上有多台服务器需要做网络隔离和分流或者安全组规则不够的朋友，强烈推荐试试这个组合！
最近把 AWS 网络架构重构了，加了一台 t4g.nano 实例作为核心 Router ，用来管理所有服务器的进出网络。 核心玩法是直接把 sing-box 当成路由器来用，跑下来发现体验超级强大。 实现的功能： 统一进出： 所有服务器的进出网络流量、转发，全部由这台 t4g.nano 托管。 精细控制： 实现了域名过滤、IP 过滤、黑白名单以及端口转发。 安全架构： 整个服务的后端内网全部实现了彻底隔离。 总共进 5000 行 bash 脚本，一键启动实例并配置。极致轻量，t4g.nano 的性能配合 sing-box 绰绰有余，成本极低，功能远超实例安全组+gateway 云上有多台服务器需要做网络隔离和分流或者安全组规则不够的朋友，强烈推荐试试这个组合！
最近把 AWS 网络架构重构了，加了一台 t4g.nano 实例作为核心 Router ，用来管理所有服务器的进出网络。 核心玩法是直接把 sing-box 当成路由器来用，跑下来发现体验超级强大。 实现的功能： 统一进出： 所有服务器的进出网络流量、转发，全部由这台 t4g.nano 托管。 精细控制： 实现了域名过滤、IP 过滤、黑白名单以及端口转发。 安全架构： 整个服务的后端内网全部实现了彻底隔离。 总共进 5000 行 bash 脚本，一键启动实例并配置。极致轻量，t4g.nano 的性能配合 sing-box 绰绰有余，成本极低，功能远超实例安全组+gateway 云上有多台服务器需要做网络隔离和分流或者安全组规则不够的朋友，强烈推荐试试这个组合！
最近把 AWS 网络架构重构了，加了一台 t4g.nano 实例作为核心 Router ，用来管理所有服务器的进出网络。 核心玩法是直接把 sing-box 当成路由器来用，跑下来发现体验超级强大。 实现的功能： 统一进出： 所有服务器的进出网络流量、转发，全部由这台 t4g.nano 托管。 精细控制： 实现了域名过滤、IP 过滤、黑白名单以及端口转发。 安全架构： 整个服务的后端内网全部实现了彻底隔离。 总共进 5000 行 bash 脚本，一键启动实例并配置。极致轻量，t4g.nano 的性能配合 sing-box 绰绰有余，成本极低，功能远超实例安全组+gateway 云上有多台服务器需要做网络隔离和分流或者安全组规则不够的朋友，强烈推荐试试这个组合！
最近把 AWS 网络架构重构了，加了一台 t4g.nano 实例作为核心 Router ，用来管理所有服务器的进出网络。 核心玩法是直接把 sing-box 当成路由器来用，跑下来发现体验超级强大。 实现的功能： 统一进出： 所有服务器的进出网络流量、转发，全部由这台 t4g.nano 托管。 精细控制： 实现了域名过滤、IP 过滤、黑白名单以及端口转发。 安全架构： 整个服务的后端内网全部实现了彻底隔离。 总共进 5000 行 bash 脚本，一键启动实例并配置。极致轻量，t4g.nano 的性能配合 sing-box 绰绰有余，成本极低，功能远超实例安全组+gateway 云上有多台服务器需要做网络隔离和分流或者安全组规则不够的朋友，强烈推荐试试这个组合！
最近把 AWS 网络架构重构了，加了一台 t4g.nano 实例作为核心 Router ，用来管理所有服务器的进出网络。 核心玩法是直接把 sing-box 当成路由器来用，跑下来发现体验超级强大。 实现的功能： 统一进出： 所有服务器的进出网络流量、转发，全部由这台 t4g.nano 托管。 精细控制： 实现了域名过滤、IP 过滤、黑白名单以及端口转发。 安全架构： 整个服务的后端内网全部实现了彻底隔离。 总共进 5000 行 bash 脚本，一键启动实例并配置。极致轻量，t4g.nano 的性能配合 sing-box 绰绰有余，成本极低，功能远超实例安全组+gateway 云上有多台服务器需要做网络隔离和分流或者安全组规则不够的朋友，强烈推荐试试这个组合！
最近把 AWS 网络架构重构了，加了一台 t4g.nano 实例作为核心 Router ，用来管理所有服务器的进出网络。 核心玩法是直接把 sing-box 当成路由器来用，跑下来发现体验超级强大。 实现的功能： 统一进出： 所有服务器的进出网络流量、转发，全部由这台 t4g.nano 托管。 精细控制： 实现了域名过滤、IP 过滤、黑白名单以及端口转发。 安全架构： 整个服务的后端内网全部实现了彻底隔离。 总共进 5000 行 bash 脚本，一键启动实例并配置。极致轻量，t4g.nano 的性能配合 sing-box 绰绰有余，成本极低，功能远超实例安全组+gateway 云上有多台服务器需要做网络隔离和分流或者安全组规则不够的朋友，强烈推荐试试这个组合！
接楼，接好运~ 16 个帖子 - 11 位参与者 阅读完整话题
佬友们，我甲骨文升级后想在首尔开一台实例作为vps，但是我前天开实例的时候开了一台4h24g的arm,现在我想给它降为2h12g的，我保存里原来的映像，然后用映像开了一个2h12g的实例，但我看引导券的时候发现旧的150g还在，所以我就删了旧的引导券，但是现在显示没有free了，那我下个月会扣费吗，我现在就只有一个150g的可用 5 个帖子 - 3 位参与者 阅读完整话题
上下文治理（ Context Governance ）是上下文工程（ Context Engineering ）中的一个部分。但我觉得，上下文治理是上下文工程里最有意思的部分。 光这么说，你肯定会像我一开始一样，觉得这个概念很抽象。但是，如果你跟我一样，了解了几种主流智能体（ Agent ）的上下文治理之后，你一定会对"上下文治理"有一个非常直观的理解。 接下来，我会通过比较 4 种智能体的上下文治理方式，让你直观地理解什么是上下文治理。以下四种工具的上下文治理，从简单到复杂、从低级到高级。 Codex 首先是 OpenAI 的 Codex 。虽然 OpenAI 是第一个做出 LLM 的公司，但是它们的智能体产品反而最年轻。 虽然它最年轻，但它的上下文治理也是最简单的。在 .codex/ 目录下，有一个叫 AGENTS.md 的文件。这是一个简单的 AGENTS.md 文件示例： # 仓库规范 ## 项目结构 - `src/` 存放应用代码 - `tests/` 存放测试代码 ## 常用命令 - 运行测试：`npm test` - 运行代码检查：`npm run lint` ## 编码规范 - 优先使用 TypeScript - 避免使用 default export （默认导出） - 使用 async/await ，而不是直接使用原始 Promise Codex 在开始工作之前，会先读取这个文件的内容。这个文件需要你手动维护，不断往里面添加规则。 除了这个文件以外，还有一个文件夹： ~/.codex/memories/ 顾名思义，就是"记忆"。Codex 会自动往里面写文件。 大概的结构如下： 类型 可能内容 summaries session 摘要 durable 长期稳定记忆 recent 最近上下文 evidence 来源证据 可以看到，Codex 的上下文治理其实非常轻量。 它本质上还是： 一个规则文件 一个自动记忆目录 仅此而已。 Claude Code Claude Code 的上下文治理很特别。 官方支持的其实跟 Codex 差不多： CLAUDE.md ~/.claude/projects/<project>/memory/ 就这两个东西。你一看名字基本就懂了。但是，Claude Code 的社区自己增强了它的上下文治理，逐渐演化成了这样： 名字 类型 作用 人工/自动 CLAUDE.md 文件 项目规则、Agent 行为规则 人工 MEMORY.md 文件 长期记忆、长期偏好、长期经验 半自动 NOTES.md 文件 临时工作笔记、scratchpad 人工 DECISIONS.md 文件 关键架构/技术决策历史 人工 ARCHITECTURE.md 文件 系统结构、模块关系、数据流 人工 LEARNINGS.md 文件 踩坑经验、经验总结 半自动 TASKS.md 文件 当前任务列表、待办事项 人工 SESSION.md 文件 当前 session 工作记录 半自动 docs/ 文件夹 长文档上下文来源 人工 memory/ 文件夹 memory 分类存储 半自动 prompts/ 文件夹 prompt 模板、workflow prompt 人工 .cursorrules 文件 Cursor 兼容规则 人工 这下就比 Codex 复杂很多了。但是你会发现，这里面有大量文件都需要人工维护。而且整个结构特别像我们以前做项目时写的 Wiki 文档结构。 其实，为了让 Agent 更好地工作，它也应该像我们一样，先看看项目 Wiki 。人们现在只是把 Wiki 文档，变成了上下文 Markdown 文件而已。这样理解就很容易了。Claude Code 在这些上下文文档的基础上，工作的方式越来越像一个真正的程序员。 Open Claw Open Claw 的定位跟 Claude Code 不太一样。它更偏向生活助手。而且 Claude Code 社区版的上下文治理，需要管理的文件太多了。不同于 Claude Code ，Open Claw 的用户更多是普通人。很多用户其实并不会直接编辑 Open Claw 的上下文文件，甚至都不知道这些文件需要人工维护。 但是，Open Claw 的上下文设计其实比 Claude Code 社区版更"Agent 化"。因为 Claude Code 社区版的上下文结构，还是带有很强的人类项目管理思维。但在 Agent 面前，其实并不一定需要拆成那么多文档。 Open Claw 的上下文治理更偏向"角色"和"人格"。它有这些上下文文件： 核心指令层（静态，你手动维护） SOUL.md — 人格、价值观、边界。回答"你是谁"。定义语气、性格、不可违反的约束。 AGENTS.md — 操作流程和规则。回答"你做什么、怎么做"。最大也最重要的文件，放复杂工作流和步骤化指令。 USER.md — 用户信息。你的名字、时区、偏好、工作背景。相当于个性化层。 IDENTITY.md — 结构化身份档案（名称、角色、目标、语气）。用于一致性地重新应用已知身份。（其实我觉得这个有点多余。） TOOLS.md — 工具文档。不控制权限（权限是 config 管的），而是告诉 Agent 如何使用已有工具。 自动化层 HEARTBEAT.md — 定时任务，相当于用自然语言写的 cron 。比如"每 30 分钟检查一次""每周一 8 点生成报告"。 BOOTSTRAP.md — 首次运行的初始化脚本。setup 完成后会自动删除。 BOOT.md — 每次启动时执行的 hook 。 记忆层 MEMORY.md — 长期记忆。持久化的事实、偏好、决策摘要，跨周跨月生效。 memory/ YYYY-MM-DD.md — 每日笔记。当天和昨天的笔记自动加载，更早的内容通过 memory_search 检索。 DREAMS.md — dreaming 系统的日记，记录从短期记忆向长期记忆的"晋升过程"，供人类审阅。这是一个实验性功能。 可以看出，Open Claw 已经比前两个系统复杂很多了。所以你在使用 Open Claw 的时候，会明显觉得它"更聪明"。 Hermes Agent 接下来就是重头戏了。如果你不理解上下文治理，你可能会觉得 Hermes Agent 跟 Open Claw 没什么区别。但不知道你有没有发现：Open Claw 里仍然有很多文件需要你手动维护。 甚至就算是我，用了这么久 Open Claw ，也是最近才知道这些文件需要人工维护。这就导致 Open Claw 设计的很多上下文，其实一直都没有真正被使用起来。Hermes Agent 的上下文治理跟 Open Claw 和 Claude Code 都不太一样。它的核心设计理念是： "自我进化"——Agent 自己写自己的记忆和技能。 整个体系住在 ~/.hermes/ 目录下。 身份层（静态） SOUL.md — system prompt 的第一个 slot ，定义人格、语气、价值观、行为边界。这是全局的，从 HERMES_HOME 加载。这个文件你仍然可以手动编辑。 项目上下文层（按优先级，只加载第一个匹配的） .hermes.md AGENTS.md CLAUDE.md .cursorrules 先找到谁就用谁。 这意味着 Hermes 同时兼容 Claude Code 和 Cursor 的项目配置文件。 记忆层（三层，Agent 自己维护） MEMORY.md — 长期记忆。存环境信息、项目惯例、工具使用经验。 USER.md — 用户档案。存你的名字、沟通偏好、技能水平。注意，这回 USER.md 已经变成自动维护了。 state.db — SQLite 数据库，带 FTS5 全文索引，存所有历史消息。Agent 不会默认全部加载，而是在需要时通过 session_search 按需检索。 这时候，记忆已经开始进入数据库时代了。因为只有数据库，才能真正支撑长期上下文检索。 技能层（ Hermes 最独特的部分） skills/ 目录 — 每个技能都是一个文件夹，里面包含一个 SKILL.md （带 YAML frontmatter ），以及可选的模板和脚本。 关键区别在于： 技能不是人类写的。Agent 在完成非平凡任务之后，会通过 skill_manage 工具自己创建技能。同样，记忆也不再主要依赖人类维护。Agent 会在对话间隙，自己编辑 MEMORY.md 和 USER.md 。而且技能是按需加载的。不用的技能不会进入上下文。这其实已经开始接近真正的"上下文自动治理"了。 调度层 cron jobs — 定时任务，类似 Open Claw 的 HEARTBEAT.md 。 到了这一步，上下文治理不仅变复杂了，还开始自动化了。 总结 AI 是否真的能干活、干得好不好，已经不仅仅是模型之间的区别了。很多时候，更好的上下文治理，对智能体工作效率的提升，甚至比你换一个更强的模型还明显。 电子脑 随之而来的，还有一个很有意思的问题：上下文，其实就是智能体的"电子脑"。一个 Agent 用久了，那份上下文就会逐渐变成独一无二的它。只要上下文还在，就算换了一个"壳"，你的小助手还是你的小助手。如果智能体坏了需要重装，或者你想迁移到另一个智能体平台，只要把上下文迁移走，你的助手理论上就还能继续存在。 于是，一个新的问题出现了： 如何安全地迁移上下文？ 但现在的问题是： 各家之间的文件名、结构、格式都完全不同。这就导致上下文迁移非常麻烦。我相信，未来一定会出现更统一、更标准化的上下文协议。而"上下文治理"，也会逐渐成为 AI Agent 最核心的能力之一。
上下文治理（ Context Governance ）是上下文工程（ Context Engineering ）中的一个部分。但我觉得，上下文治理是上下文工程里最有意思的部分。 光这么说，你肯定会像我一开始一样，觉得这个概念很抽象。但是，如果你跟我一样，了解了几种主流智能体（ Agent ）的上下文治理之后，你一定会对"上下文治理"有一个非常直观的理解。 接下来，我会通过比较 4 种智能体的上下文治理方式，让你直观地理解什么是上下文治理。以下四种工具的上下文治理，从简单到复杂、从低级到高级。 Codex 首先是 OpenAI 的 Codex 。虽然 OpenAI 是第一个做出 LLM 的公司，但是它们的智能体产品反而最年轻。 虽然它最年轻，但它的上下文治理也是最简单的。在 .codex/ 目录下，有一个叫 AGENTS.md 的文件。这是一个简单的 AGENTS.md 文件示例： # 仓库规范 ## 项目结构 - `src/` 存放应用代码 - `tests/` 存放测试代码 ## 常用命令 - 运行测试：`npm test` - 运行代码检查：`npm run lint` ## 编码规范 - 优先使用 TypeScript - 避免使用 default export （默认导出） - 使用 async/await ，而不是直接使用原始 Promise Codex 在开始工作之前，会先读取这个文件的内容。这个文件需要你手动维护，不断往里面添加规则。 除了这个文件以外，还有一个文件夹： ~/.codex/memories/ 顾名思义，就是"记忆"。Codex 会自动往里面写文件。 大概的结构如下： 类型 可能内容 summaries session 摘要 durable 长期稳定记忆 recent 最近上下文 evidence 来源证据 可以看到，Codex 的上下文治理其实非常轻量。 它本质上还是： 一个规则文件 一个自动记忆目录 仅此而已。 Claude Code Claude Code 的上下文治理很特别。 官方支持的其实跟 Codex 差不多： CLAUDE.md ~/.claude/projects/<project>/memory/ 就这两个东西。你一看名字基本就懂了。但是，Claude Code 的社区自己增强了它的上下文治理，逐渐演化成了这样： 名字 类型 作用 人工/自动 CLAUDE.md 文件 项目规则、Agent 行为规则 人工 MEMORY.md 文件 长期记忆、长期偏好、长期经验 半自动 NOTES.md 文件 临时工作笔记、scratchpad 人工 DECISIONS.md 文件 关键架构/技术决策历史 人工 ARCHITECTURE.md 文件 系统结构、模块关系、数据流 人工 LEARNINGS.md 文件 踩坑经验、经验总结 半自动 TASKS.md 文件 当前任务列表、待办事项 人工 SESSION.md 文件 当前 session 工作记录 半自动 docs/ 文件夹 长文档上下文来源 人工 memory/ 文件夹 memory 分类存储 半自动 prompts/ 文件夹 prompt 模板、workflow prompt 人工 .cursorrules 文件 Cursor 兼容规则 人工 这下就比 Codex 复杂很多了。但是你会发现，这里面有大量文件都需要人工维护。而且整个结构特别像我们以前做项目时写的 Wiki 文档结构。 其实，为了让 Agent 更好地工作，它也应该像我们一样，先看看项目 Wiki 。人们现在只是把 Wiki 文档，变成了上下文 Markdown 文件而已。这样理解就很容易了。Claude Code 在这些上下文文档的基础上，工作的方式越来越像一个真正的程序员。 Open Claw Open Claw 的定位跟 Claude Code 不太一样。它更偏向生活助手。而且 Claude Code 社区版的上下文治理，需要管理的文件太多了。不同于 Claude Code ，Open Claw 的用户更多是普通人。很多用户其实并不会直接编辑 Open Claw 的上下文文件，甚至都不知道这些文件需要人工维护。 但是，Open Claw 的上下文设计其实比 Claude Code 社区版更"Agent 化"。因为 Claude Code 社区版的上下文结构，还是带有很强的人类项目管理思维。但在 Agent 面前，其实并不一定需要拆成那么多文档。 Open Claw 的上下文治理更偏向"角色"和"人格"。它有这些上下文文件： 核心指令层（静态，你手动维护） SOUL.md — 人格、价值观、边界。回答"你是谁"。定义语气、性格、不可违反的约束。 AGENTS.md — 操作流程和规则。回答"你做什么、怎么做"。最大也最重要的文件，放复杂工作流和步骤化指令。 USER.md — 用户信息。你的名字、时区、偏好、工作背景。相当于个性化层。 IDENTITY.md — 结构化身份档案（名称、角色、目标、语气）。用于一致性地重新应用已知身份。（其实我觉得这个有点多余。） TOOLS.md — 工具文档。不控制权限（权限是 config 管的），而是告诉 Agent 如何使用已有工具。 自动化层 HEARTBEAT.md — 定时任务，相当于用自然语言写的 cron 。比如"每 30 分钟检查一次""每周一 8 点生成报告"。 BOOTSTRAP.md — 首次运行的初始化脚本。setup 完成后会自动删除。 BOOT.md — 每次启动时执行的 hook 。 记忆层 MEMORY.md — 长期记忆。持久化的事实、偏好、决策摘要，跨周跨月生效。 memory/ YYYY-MM-DD.md — 每日笔记。当天和昨天的笔记自动加载，更早的内容通过 memory_search 检索。 DREAMS.md — dreaming 系统的日记，记录从短期记忆向长期记忆的"晋升过程"，供人类审阅。这是一个实验性功能。 可以看出，Open Claw 已经比前两个系统复杂很多了。所以你在使用 Open Claw 的时候，会明显觉得它"更聪明"。 Hermes Agent 接下来就是重头戏了。如果你不理解上下文治理，你可能会觉得 Hermes Agent 跟 Open Claw 没什么区别。但不知道你有没有发现：Open Claw 里仍然有很多文件需要你手动维护。 甚至就算是我，用了这么久 Open Claw ，也是最近才知道这些文件需要人工维护。这就导致 Open Claw 设计的很多上下文，其实一直都没有真正被使用起来。Hermes Agent 的上下文治理跟 Open Claw 和 Claude Code 都不太一样。它的核心设计理念是： "自我进化"——Agent 自己写自己的记忆和技能。 整个体系住在 ~/.hermes/ 目录下。 身份层（静态） SOUL.md — system prompt 的第一个 slot ，定义人格、语气、价值观、行为边界。这是全局的，从 HERMES_HOME 加载。这个文件你仍然可以手动编辑。 项目上下文层（按优先级，只加载第一个匹配的） .hermes.md AGENTS.md CLAUDE.md .cursorrules 先找到谁就用谁。 这意味着 Hermes 同时兼容 Claude Code 和 Cursor 的项目配置文件。 记忆层（三层，Agent 自己维护） MEMORY.md — 长期记忆。存环境信息、项目惯例、工具使用经验。 USER.md — 用户档案。存你的名字、沟通偏好、技能水平。注意，这回 USER.md 已经变成自动维护了。 state.db — SQLite 数据库，带 FTS5 全文索引，存所有历史消息。Agent 不会默认全部加载，而是在需要时通过 session_search 按需检索。 这时候，记忆已经开始进入数据库时代了。因为只有数据库，才能真正支撑长期上下文检索。 技能层（ Hermes 最独特的部分） skills/ 目录 — 每个技能都是一个文件夹，里面包含一个 SKILL.md （带 YAML frontmatter ），以及可选的模板和脚本。 关键区别在于： 技能不是人类写的。Agent 在完成非平凡任务之后，会通过 skill_manage 工具自己创建技能。同样，记忆也不再主要依赖人类维护。Agent 会在对话间隙，自己编辑 MEMORY.md 和 USER.md 。而且技能是按需加载的。不用的技能不会进入上下文。这其实已经开始接近真正的"上下文自动治理"了。 调度层 cron jobs — 定时任务，类似 Open Claw 的 HEARTBEAT.md 。 到了这一步，上下文治理不仅变复杂了，还开始自动化了。 总结 AI 是否真的能干活、干得好不好，已经不仅仅是模型之间的区别了。很多时候，更好的上下文治理，对智能体工作效率的提升，甚至比你换一个更强的模型还明显。 电子脑 随之而来的，还有一个很有意思的问题：上下文，其实就是智能体的"电子脑"。一个 Agent 用久了，那份上下文就会逐渐变成独一无二的它。只要上下文还在，就算换了一个"壳"，你的小助手还是你的小助手。如果智能体坏了需要重装，或者你想迁移到另一个智能体平台，只要把上下文迁移走，你的助手理论上就还能继续存在。 于是，一个新的问题出现了： 如何安全地迁移上下文？ 但现在的问题是： 各家之间的文件名、结构、格式都完全不同。这就导致上下文迁移非常麻烦。我相信，未来一定会出现更统一、更标准化的上下文协议。而"上下文治理"，也会逐渐成为 AI Agent 最核心的能力之一。
上下文治理（ Context Governance ）是上下文工程（ Context Engineering ）中的一个部分。但我觉得，上下文治理是上下文工程里最有意思的部分。 光这么说，你肯定会像我一开始一样，觉得这个概念很抽象。但是，如果你跟我一样，了解了几种主流智能体（ Agent ）的上下文治理之后，你一定会对"上下文治理"有一个非常直观的理解。 接下来，我会通过比较 4 种智能体的上下文治理方式，让你直观地理解什么是上下文治理。以下四种工具的上下文治理，从简单到复杂、从低级到高级。 Codex 首先是 OpenAI 的 Codex 。虽然 OpenAI 是第一个做出 LLM 的公司，但是它们的智能体产品反而最年轻。 虽然它最年轻，但它的上下文治理也是最简单的。在 .codex/ 目录下，有一个叫 AGENTS.md 的文件。这是一个简单的 AGENTS.md 文件示例： # 仓库规范 ## 项目结构 - `src/` 存放应用代码 - `tests/` 存放测试代码 ## 常用命令 - 运行测试：`npm test` - 运行代码检查：`npm run lint` ## 编码规范 - 优先使用 TypeScript - 避免使用 default export （默认导出） - 使用 async/await ，而不是直接使用原始 Promise Codex 在开始工作之前，会先读取这个文件的内容。这个文件需要你手动维护，不断往里面添加规则。 除了这个文件以外，还有一个文件夹： ~/.codex/memories/ 顾名思义，就是"记忆"。Codex 会自动往里面写文件。 大概的结构如下： 类型 可能内容 summaries session 摘要 durable 长期稳定记忆 recent 最近上下文 evidence 来源证据 可以看到，Codex 的上下文治理其实非常轻量。 它本质上还是： 一个规则文件 一个自动记忆目录 仅此而已。 Claude Code Claude Code 的上下文治理很特别。 官方支持的其实跟 Codex 差不多： CLAUDE.md ~/.claude/projects/<project>/memory/ 就这两个东西。你一看名字基本就懂了。但是，Claude Code 的社区自己增强了它的上下文治理，逐渐演化成了这样： 名字 类型 作用 人工/自动 CLAUDE.md 文件 项目规则、Agent 行为规则 人工 MEMORY.md 文件 长期记忆、长期偏好、长期经验 半自动 NOTES.md 文件 临时工作笔记、scratchpad 人工 DECISIONS.md 文件 关键架构/技术决策历史 人工 ARCHITECTURE.md 文件 系统结构、模块关系、数据流 人工 LEARNINGS.md 文件 踩坑经验、经验总结 半自动 TASKS.md 文件 当前任务列表、待办事项 人工 SESSION.md 文件 当前 session 工作记录 半自动 docs/ 文件夹 长文档上下文来源 人工 memory/ 文件夹 memory 分类存储 半自动 prompts/ 文件夹 prompt 模板、workflow prompt 人工 .cursorrules 文件 Cursor 兼容规则 人工 这下就比 Codex 复杂很多了。但是你会发现，这里面有大量文件都需要人工维护。而且整个结构特别像我们以前做项目时写的 Wiki 文档结构。 其实，为了让 Agent 更好地工作，它也应该像我们一样，先看看项目 Wiki 。人们现在只是把 Wiki 文档，变成了上下文 Markdown 文件而已。这样理解就很容易了。Claude Code 在这些上下文文档的基础上，工作的方式越来越像一个真正的程序员。 Open Claw Open Claw 的定位跟 Claude Code 不太一样。它更偏向生活助手。而且 Claude Code 社区版的上下文治理，需要管理的文件太多了。不同于 Claude Code ，Open Claw 的用户更多是普通人。很多用户其实并不会直接编辑 Open Claw 的上下文文件，甚至都不知道这些文件需要人工维护。 但是，Open Claw 的上下文设计其实比 Claude Code 社区版更"Agent 化"。因为 Claude Code 社区版的上下文结构，还是带有很强的人类项目管理思维。但在 Agent 面前，其实并不一定需要拆成那么多文档。 Open Claw 的上下文治理更偏向"角色"和"人格"。它有这些上下文文件： 核心指令层（静态，你手动维护） SOUL.md — 人格、价值观、边界。回答"你是谁"。定义语气、性格、不可违反的约束。 AGENTS.md — 操作流程和规则。回答"你做什么、怎么做"。最大也最重要的文件，放复杂工作流和步骤化指令。 USER.md — 用户信息。你的名字、时区、偏好、工作背景。相当于个性化层。 IDENTITY.md — 结构化身份档案（名称、角色、目标、语气）。用于一致性地重新应用已知身份。（其实我觉得这个有点多余。） TOOLS.md — 工具文档。不控制权限（权限是 config 管的），而是告诉 Agent 如何使用已有工具。 自动化层 HEARTBEAT.md — 定时任务，相当于用自然语言写的 cron 。比如"每 30 分钟检查一次""每周一 8 点生成报告"。 BOOTSTRAP.md — 首次运行的初始化脚本。setup 完成后会自动删除。 BOOT.md — 每次启动时执行的 hook 。 记忆层 MEMORY.md — 长期记忆。持久化的事实、偏好、决策摘要，跨周跨月生效。 memory/ YYYY-MM-DD.md — 每日笔记。当天和昨天的笔记自动加载，更早的内容通过 memory_search 检索。 DREAMS.md — dreaming 系统的日记，记录从短期记忆向长期记忆的"晋升过程"，供人类审阅。这是一个实验性功能。 可以看出，Open Claw 已经比前两个系统复杂很多了。所以你在使用 Open Claw 的时候，会明显觉得它"更聪明"。 Hermes Agent 接下来就是重头戏了。如果你不理解上下文治理，你可能会觉得 Hermes Agent 跟 Open Claw 没什么区别。但不知道你有没有发现：Open Claw 里仍然有很多文件需要你手动维护。 甚至就算是我，用了这么久 Open Claw ，也是最近才知道这些文件需要人工维护。这就导致 Open Claw 设计的很多上下文，其实一直都没有真正被使用起来。Hermes Agent 的上下文治理跟 Open Claw 和 Claude Code 都不太一样。它的核心设计理念是： "自我进化"——Agent 自己写自己的记忆和技能。 整个体系住在 ~/.hermes/ 目录下。 身份层（静态） SOUL.md — system prompt 的第一个 slot ，定义人格、语气、价值观、行为边界。这是全局的，从 HERMES_HOME 加载。这个文件你仍然可以手动编辑。 项目上下文层（按优先级，只加载第一个匹配的） .hermes.md AGENTS.md CLAUDE.md .cursorrules 先找到谁就用谁。 这意味着 Hermes 同时兼容 Claude Code 和 Cursor 的项目配置文件。 记忆层（三层，Agent 自己维护） MEMORY.md — 长期记忆。存环境信息、项目惯例、工具使用经验。 USER.md — 用户档案。存你的名字、沟通偏好、技能水平。注意，这回 USER.md 已经变成自动维护了。 state.db — SQLite 数据库，带 FTS5 全文索引，存所有历史消息。Agent 不会默认全部加载，而是在需要时通过 session_search 按需检索。 这时候，记忆已经开始进入数据库时代了。因为只有数据库，才能真正支撑长期上下文检索。 技能层（ Hermes 最独特的部分） skills/ 目录 — 每个技能都是一个文件夹，里面包含一个 SKILL.md （带 YAML frontmatter ），以及可选的模板和脚本。 关键区别在于： 技能不是人类写的。Agent 在完成非平凡任务之后，会通过 skill_manage 工具自己创建技能。同样，记忆也不再主要依赖人类维护。Agent 会在对话间隙，自己编辑 MEMORY.md 和 USER.md 。而且技能是按需加载的。不用的技能不会进入上下文。这其实已经开始接近真正的"上下文自动治理"了。 调度层 cron jobs — 定时任务，类似 Open Claw 的 HEARTBEAT.md 。 到了这一步，上下文治理不仅变复杂了，还开始自动化了。 总结 AI 是否真的能干活、干得好不好，已经不仅仅是模型之间的区别了。很多时候，更好的上下文治理，对智能体工作效率的提升，甚至比你换一个更强的模型还明显。 电子脑 随之而来的，还有一个很有意思的问题：上下文，其实就是智能体的"电子脑"。一个 Agent 用久了，那份上下文就会逐渐变成独一无二的它。只要上下文还在，就算换了一个"壳"，你的小助手还是你的小助手。如果智能体坏了需要重装，或者你想迁移到另一个智能体平台，只要把上下文迁移走，你的助手理论上就还能继续存在。 于是，一个新的问题出现了： 如何安全地迁移上下文？ 但现在的问题是： 各家之间的文件名、结构、格式都完全不同。这就导致上下文迁移非常麻烦。我相信，未来一定会出现更统一、更标准化的上下文协议。而"上下文治理"，也会逐渐成为 AI Agent 最核心的能力之一。
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 (29种README的"Community Support"章节均含链接) 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 否（不包含） 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 很高兴向大家宣布，WSL Dashboard v0.8.0 正式发布！这是一个功能丰富的重大更新版本，带来了众多令人期待的新功能和体验优化。 核心功能亮点 VHDX 压缩功能 全新引入的虚拟磁盘压缩功能，可以帮助您回收宝贵的物理磁盘空间。 技术实现： 支持两种压缩策略： 快速优化 ：快速释放已删除空间（使用 optimize-vhd ） 完整重建 ：彻底压缩，获得最大空间节省（使用 convert-vhd ） 压缩前自动清理系统缓存，确保获得最佳压缩效果 全程可视化进度指示，实时显示压缩进度和预估时间 支持压缩中断和恢复 稀疏 VHD 模式 开启稀疏模式后，VHDX 将采用按需磁盘分配机制，实际磁盘占用远小于标称大小。 技术实现： 新安装发行版时根据配置自动启用稀疏模式 克隆发行版时自动保留稀疏设置 通过 Set-VHD 设置稀疏标志 彩色图标系统 每个功能图标现在都拥有独特的语义色彩，支持一键切换回单色风格，满足不同视觉偏好。 设置页面全新设计 设置页面现已拆分为三个独立标签页： 常规设置 ：启动行为、更新策略、默认终端 高级设置 ：WSL 配置、网络代理、实验性功能 界面设置 ：主题模式、图标样式、侧边栏选项 分类清晰，支持独立保存，并新增快速"停止 WSL"操作入口。 体验升级 终端体验优化 优先使用 Windows Terminal，仅在不可用时回退到传统命令行。自动检测系统安装的终端程序，提供更现代的终端体验。 标准安装程序 新增标准化 Windows 安装向导： 支持 29 种语言（简体中文、英文、日文、韩文、法文等） 一键创建桌面快捷方式 创建开始菜单条目 可选创建定时任务 关于页面重新设计 采用可滚动布局，整合官方网站、公告、讨论和文档的快速链接，新增版权和开源许可证信息。 更新体验改进 更新和过期通知现在包含发布日期和直接下载链接，无需手动访问 GitHub。 可配置侧边栏切换 侧边栏折叠按钮支持显示/隐藏，满足不同使用偏好。 底层优化 应用架构重构 启动流程已模块化，提升代码可维护性和启动稳定性。 统一 API 服务 后端 API 已迁移至自建服务，更新检查和数据获取更加稳定可控。 构建与分发改进 双通道发布 ：便携版和安装版同时发布 CDN 加速 ：通过 Cloudflare CDN 扩展分发 Gitee 镜像 ：新增 Gitee 镜像仓库，方便中国用户访问 开源合规性 所有源文件已采用 SPDX 开源许可证声明，达到 REUSE 规范合规要求。 UI/UX 改进 所有对话框统一了 UI 设计和交互体验，操作更加流畅直观。 下载方式 GitHub Release : Releases · owu/wsl-dashboard · GitHub Gitee 镜像 : https://gitee.com/bye/wsl-dashboard/releases 项目官网 : https://www.wslui.com 为爱发电 如果您觉得这个项目对您有所帮助，我将不胜感激您能在 GitHub 上点亮一颗星。您的认可将帮助项目触及更广泛的用户群体，我也深表谢意。正是这种鼓励激励着我不断前行。 感谢所有用户的支持！期待您的使用体验反馈。 WSL Dashboard - 让 WSL 管理更简单 1 个帖子 - 1 位参与者 阅读完整话题