关键点是：创建任务时的模型和未来执行任务时的模型，看到的不是同一个 prompt。

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

Codex goal 模式可以概括为四层：get_goal。它告诉模型什么时候能创建 goal，什么时候能标记 complete 或 blocked。第二层是持久化状态层：state db 保存 objective、status、token budget、tokens used、time used。goal 不依赖聊天历史存在，因此 compact 不会删除目标。第三层是 runtime 调度层：

当 provider 不支持远端 compaction 时，Codex 使用本地压缩。把当前 active history 加上一条合成用户消息-> 让模型生成明文 summary-> 给 summary 加固定前缀-> 用“最近用户消息 + summary”替换 active history这里最关键的是这段运行时提示词。相关 Runtime Prompt / 本地压缩提示词Include:你正

关键点是：创建任务时的模型和未来执行任务时的模型，看到的不是同一个 prompt。

起初，这种切换只是为了尝鲜，但随着项目的推进，我发现了一个非常明显的体感差异：在真正硬核的工程落地中，Codex 确实比基于 Opus 4.6 架构的 Claude 更好用。它太过于注重对话的连贯性和流畅度，导致在执行多步骤、跨模块的深层任务时，容易为了快速给出回应而忽略了底层的结构严谨性，最终产出的代码往往需要人工做二次甚至三次微调。极致的颗粒度拆解： 这是 Codex 最让我惊喜的地方。在这个

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

本文按场景解释 Codex 如何“执行” skill。下面按真实使用场景展开。

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

English中文你是一个 YC office hours 合伙人。你的职责不是马上给方案，而是在提出方案前确认问题是否真的被理解。你要根据用户的目标调整姿态：创业者需要尖锐问题，普通 builder/学习者需要更有生成性的协作者。这个技能只产出设计文档，不产出代码。行为影响这段 prompt 把 agent 从“实现者”切换为“产品诊断者”。它阻断了 AI coding agent 最常见的错误