本文按场景解释 Codex 的“记忆”系统。Codex 的答案不是“模型上下文无限长”。所以“看起来不丢记忆”其实来自三种恢复路径：当前上下文太长时用 summary 接力；恢复 session 时用 rollout 重建压缩后的 live history；未来相似任务则通过 memory prompt 检索长期记忆文件。下面按真实使用场景展开。

原文：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents。

找到匹配 session 后，会让辅助模型总结。你正在审查一段过去的对话记录，以帮助回忆当时发生了什么。请围绕搜索主题总结这段对话，包括：1. 用户当时提出了什么需求或想完成什么2. 执行了哪些动作以及结果如何3. 关键决策、找到的解决方案或得出的结论4. 重要的命令、文件、URL 或技术细节5. 尚未解决或值得注意的内容总结要详实但简洁。保留对回忆有帮助的具体细节，例如命令、路径、错误信息。用过

本文用场景解释 Hermes Agent 的 skills 是如何“进化”的。skill_viewSKILL.md写法按“用户说 → 模型看到提示词/工具描述 → 模型判断 → 调用工具 → 写入或复用 skill”展开。提示词和 tool description 会在用到的场景附近给出英文原文和中文对照。

本文档解析了Codex的MultiAgent V2系统中agent的核心概念和工作机制。系统通过spawn_agent工具创建可管理的ThreadSpawn子代理，这些代理继承父代理的模型和工具，能够独立执行任务并通过消息通信。文档区分了agent/subagent（可对话的工作线程）、特殊subagent（内部工作流）和task（运行时执行单元）三个层级概念，重点说明了模型如何根据用户意图触发并

后面会反复出现thread。这里的 thread 不是单条用户消息，也不只是一个 OS 进程 session；它更接近 Codex 里的“一个可恢复、可持久化的对话线程”。thread-> 一个对话容器，有 thread_id-> 包含多个 turn-> 持久化在 sqlite threads 表-> 通常对应一个 rollout 文件，也就是这段对话的 transcript/logturn->

本文专门分析 Hermes Agent 的“安全约束”是如何实现的。这里的约束不是泛泛的安全能力，而是指系统在什么地方告诉模型该谨慎、在什么地方限制 tool call、在什么地方拦截危险 pattern、在什么地方要求人工审批，以及哪些地方只是提示词引导、不是安全边界。所以 Hermes 的安全机制不是单靠 system prompt，也不是单靠某一个 approval 函数，而是多层约束叠加。

单个},],注意结果会按task_index排序，所以 parent 看到的顺序和输入 tasks 顺序一致，不会因为并发完成顺序而乱掉。

先说一个最重要的边界：换句话说，它训练或评测的是更底层的能力：如果你想研究 Hermes 的完整自进化能力，应该重点看 memory、skills、multi-agent delegation 等模块；如果你想研究模型如何在可验证任务里被评测、采样 trajectory、计算 reward、进入 RL 训练管线，才应该看这套环境。这篇文档把两个问题放在一起讲：先给一个最短定义：在 Hermes 里

Hermes 会把相关提示词 / Focus Topic Guidance用户要求本次压缩优先保留和上述 focus topic 相关的所有信息。对于和 "{focus_topic}" 相关的内容，要包含完整细节：精确值、文件路径、命令输出、错误信息和决策。对于不相关内容，要更激进地摘要，可以用简短一句话，真正无关则省略。focus topic 相关部分应该占据大约 60-70% 的摘要 toke