章节 1：简介与五层内存架构

📝 本节摘要：

本节引出了关于 Claude Code 内存架构的探讨。Hesam 提出问题并引入了 Himanshu 的深度解析。Himanshu 指出内存对智能体（Agent）的身份与表现至关重要，并详细解析了 Claude 精密设计的“五层内存架构”，包括：对话历史、会话内存（后台压缩）、CLAUDE.md（用户手动配置）、自动内存（Auto-memory）以及团队内存，其中自动内存是全文的探讨核心。

[原文] [Hesam]: Claude Code's Memory System Explained how does Claude Code keep track of user preferences, manage it's memory or choose what to keep and what to forget?

[译文] [Hesam]: Claude Code 的内存系统原理解析：Claude Code 是如何追踪用户偏好、管理其内存，或者选择保留什么以及忘记什么的？

[原文] [Hesam]: the leaked source code is here to tell us.

[译文] [Hesam]: 泄露的源代码在这里为我们揭晓了答案。

[原文] [Hesam]: yesterday, @himanshustwts wrote a post about the overall architecture of Claude Code's memory system.

[译文] [Hesam]: 昨天，@himanshustwts 写了一篇关于 Claude Code 内存系统整体架构的帖子。

[原文] [Hesam]: I'm here to go more into detail about it.

[译文] [Hesam]: 我今天在这里要对它进行更详细的探讨。

[原文] [Himanshu]: Based on everything explored in the source code, here's the full technical recipe behind Claude Code's memory architecture:

[译文] [Himanshu]: 基于对源代码中探索到的所有内容，以下是 Claude Code 内存架构背后的完整技术配方：

[原文] [Himanshu]: Claude Code’s memory system is actually insanely well-designed.

[译文] [Himanshu]: Claude Code 的内存系统实际上设计得好到令人发指。

[原文] [Himanshu]: It isn't like “store everything” but constrained, structured and Show more Why Memory?

[译文] [Himanshu]: 它不是那种“存储所有内容”的设计，而是受约束的、结构化的。（展开更多）为什么需要内存（Memory）？

[原文] [Himanshu]: because it's a critical part of a an agent's both identity and performance.

[译文] [Himanshu]: 因为它是智能体（agent）的身份（identity）和表现（performance）的至关重要的一部分。

[原文] [Himanshu]: a great deal of my work at @CamelAIOrg has been about memory, so naturally I'm curious to know if Claude's approach to memory is fundamentally different.

[译文] [Himanshu]: 我在 @CamelAIOrg 的大量工作都与内存有关，所以我自然很好奇 Claude 处理内存的方式是否有根本上的不同。

[原文] [Himanshu]: Claude's five-layer Memory Architecture

[译文] [Himanshu]: Claude 的五层内存架构（five-layer Memory Architecture）

[原文] [Himanshu]: Claude doesn't have a memory system. it has five, each operating with a different purpose, cost, and end-user.

[译文] [Himanshu]: Claude 并没有一个单一的内存系统。它有五个，每一个都以不同的目的、成本（cost）和终端用户（end-user）来运作。

[原文] [Himanshu]: The conversation history is the most trivial one.

[译文] [Himanshu]: 对话历史（conversation history）是最基础的一个。

[原文] [Himanshu]: it's a jsonl of all the user prompts and Claude's responses in a conversation which you can export this memory by the /export command.

[译文] [Himanshu]: 它是包含对话中所有用户提示词（user prompts）和 Claude 响应的一个 jsonl 文件，你可以通过 /export 命令导出这个内存。

[原文] [Himanshu]: it's capped at 100 entries per project.

[译文] [Himanshu]: 它在每个项目中的上限是 100 条记录。

[原文] [Himanshu]: Large pastes are hashed and stored separately to keep the log lean.

[译文] [Himanshu]: 大型粘贴文本会被哈希处理（hashed）并单独存储，以保持日志的精简。

[原文] [Himanshu]: COST: ZERO.

[译文] [Himanshu]: 成本：零。

[原文] [Himanshu]: Session memory is a structured markdown memory that's built and updated by a background agent WHILE your conversation is growing.

[译文] [Himanshu]: 会话内存（Session memory）是一种结构化的 markdown 内存，它在你的对话不断增加的同时（WHILE），由一个后台智能体（background agent）构建并更新。

[原文] [Himanshu]: its end-consumer isn't the user, but it's a compaction strategy.

[译文] [Himanshu]: 它的最终消费者不是用户，而是一种压缩策略（compaction strategy）。

[原文] [Himanshu]: currently when the conversation grows, once it reaches ~85% of the context window, your conversation gets summarized.

[译文] [Himanshu]: 目前，当对话增长，一旦达到上下文窗口（context window）的 ~85% 时，你的对话就会被总结。

[原文] [Himanshu]: with the session memory, this would happen on the go.

[译文] [Himanshu]: 有了会话内存，这将会实时进行。

[原文] [Himanshu]: however, this is gated behind tengusessionmemory, one of the many mysterious Claude tengu flags.

[译文] [Himanshu]: 然而，它被限制在 tengusessionmemory 之后，这是 Claude 众多神秘的 tengu 标志（flags）之一。

[原文] [Himanshu]: i'm not sure this is a released feature, or a future one. however, it exists in the code.

[译文] [Himanshu]: 我不确定这是一个已发布的功能，还是未来的功能。不过，它存在于代码中。

[原文] [Himanshu]: CLAUDE.md which you must be familiar with.

[译文] [Himanshu]: CLAUDE.md 你一定很熟悉。

[原文] [Himanshu]: this is the human-controlled level of coding style, preferences, things to keep in memory, etc.

[译文] [Himanshu]: 这是一个由人类控制的层级，包含编码风格（coding style）、偏好，以及需要保存在内存中的事物等。

[原文] [Himanshu]: When you start a session with Claude, the contents of your Claude.md files get added right away.

[译文] [Himanshu]: 当你与 Claude 开始一个会话时，你的 Claude.md 文件的内容会立即被添加进去。

[原文] [Himanshu]: multiple Claude.md files can be loaded as Claude traverses the hierarchical folder structure to discover them.

[译文] [Himanshu]: 随着 Claude 遍历层级文件夹结构来发现它们，多个 Claude.md 文件可以被同时加载。

[原文] [Himanshu]: Auto-memory is what we mean when talking about Claude Code's memory.

[译文] [Himanshu]: 自动内存（Auto-memory）就是我们在谈论 Claude Code 内存时所指的东西。

[原文] [Himanshu]: This is where Claude Code learns about users from multiple conversations, things like their role, preferences, project context, and pointers to external systems.

[译文] [Himanshu]: 这是 Claude Code 从多次对话中学习关于用户信息的地方，比如他们的角色（role）、偏好、项目上下文（project context）以及指向外部系统的指针。

[原文] [Himanshu]: These are stored in ~/.claude/projects/<slug>/memory/.

[译文] [Himanshu]: 这些数据被存储在 ~/.claude/projects/<slug>/memory/ 中。

[原文] [Himanshu]: Team memory. boring. won't get into it.

[译文] [Himanshu]: 团队内存（Team memory）。很无聊。不打算深入探讨。

[原文] [Himanshu]: The focus of this article is on Auto-memory.

[译文] [Himanshu]: 本文的重点是自动内存（Auto-memory）。

[原文] [Himanshu]: These are pretty much all of the memory modules Claude keeps on you, all local and visible to the user.

[译文] [Himanshu]: 这基本上就是 Claude 在你身上保留的所有内存模块，全部都是本地的（local），且对用户可见。

章节 2：自动内存的管理与每轮提取机制

📝 本节摘要：

本节剖析了 Claude 自动内存（Auto-Memory）的写入和管理方式。它依赖于“分叉子智能体（forked subagent）”在后台进行“每轮提取”，将记忆归类为四种类型（用户、反馈、项目、参考）并在 MEMORY.md 形成索引。此设计利用了父对话缓存，不仅不拖慢主系统运行，还通过严格的沙箱机制与去重逻辑保证了执行的安全与高效。

[原文] [Himanshu]: Writing Memory for better understanding, I separated what's related to writing memory and retrieving + using memory.

[译文] [Himanshu]: 写入内存（Writing Memory），为了更好地理解，我把与写入内存以及检索+使用内存相关的内容分开了。

[原文] [Himanshu]: How is Auto-Memory managed

[译文] [Himanshu]: 自动内存（Auto-Memory）是如何管理的

[原文] [Himanshu]: Claude's auto-memory isn't sloppy or append-only, it's pretty well-managed. it goes through three management phases.

[译文] [Himanshu]: Claude 的自动内存并不是草率的，也不是仅追加（append-only）的，它被管理得非常好。它经历了三个管理阶段。

[原文] [Himanshu]: 1. Per-turn extraction

[译文] [Himanshu]: 1. 每轮提取（Per-turn extraction）

[原文] [Himanshu]: a background agent goes through the last N messages, decides what's worth remembering, and then decides either to add new memory files or update existing ones.

[译文] [Himanshu]: 一个后台智能体（background agent）会检查最近的 N 条消息，决定哪些值得记住，然后决定是添加新的内存文件还是更新现有的文件。

[原文] [Himanshu]: it receives all the memories before it starts its work, this is to make sure it updates the existing memories rather than create new duplicate ones and explore the local memory.

[译文] [Himanshu]: 它在开始工作之前会接收所有的内存，这是为了确保它更新现有的内存，而不是创建新的重复项并探索本地内存。

[原文] [Himanshu]: the writing procedure is also strict, as a new topic file is created for memory, a reference/index of them is recorded in a MEMORY.md. markdown

[译文] [Himanshu]: 写入程序也非常严格，因为为内存创建了新的主题文件，它们的参考/索引被记录在 MEMORY.md 中。

[原文] [Himanshu]:

-- MEMORY.md (the index):

tests

deadline 2026-04-15

INGEST

-- feedback_testing.md (one memory file):

name: Testing policy

description: Integration tests must use real database connections, never mocks

type: feedback

[译文] [Himanshu]:

-- MEMORY.md（索引）：

-- feedback_testing.md（一个内存文件）：

name: 测试策略

description: 集成测试必须使用真实的数据库连接，绝不 mocks

type: 反馈（feedback）

[原文] [Himanshu]: This is a good approach if you have multiple local files for context, to keep a table of content + a one line summary, this would halp the agent to later find the right memory file.

[译文] [Himanshu]: 如果你有多个本地文件作为上下文（context），保持一个目录（table of content）+ 单行摘要是一个好方法，这将有助于智能体稍后找到正确的内存文件。

[原文] [Himanshu]: → There are Four memory types 'user' | 'feedback' | 'project' | 'reference' these would help the agent to later retrieve the right memory, essentially a label for the selection agent.

[译文] [Himanshu]: → 这里有四种内存类型（memory types）'user' | 'feedback' | 'project' | 'reference' 这些将帮助智能体稍后检索出正确的内存，这本质上是提供给选择智能体（selection agent）的一个标签。

[原文] [Himanshu]: user: who you are (role, expertise, preferences)

[译文] [Himanshu]: 用户（user）：你是谁（角色，专长，偏好）

[原文] [Himanshu]: feedback: how you want Claude to work (corrections and confirmed approaches)

[译文] [Himanshu]: 反馈（feedback）：你希望 Claude 如何工作（纠正和已确认的方法）

[原文] [Himanshu]: project: what's happening that code/git can't tell you (deadlines, decisions, motivations)

[译文] [Himanshu]: 项目（project）：代码/git 无法告诉你的那些正在发生的事（截止日期，决策，动机）

[原文] [Himanshu]: reference: where to look outside the repo (Linear boards, Slack channels, dashboards)

[译文] [Himanshu]: 参考（reference）：去仓库外哪里查看（Linear 看板，Slack 频道，仪表板）

[原文] [Himanshu]: The Forked Agent Pattern

[译文] [Himanshu]: 分叉智能体模式（The Forked Agent Pattern）

[原文] [Himanshu]: "doesn't all this background work slow things down?" no.

[译文] [Himanshu]: “这些所有的后台工作不会拖慢速度吗？” 不会。

[原文] [Himanshu]: the extraction agent runs as a "forked subagent" that shares the parent conversation's prompt cache.

[译文] [Himanshu]: 提取智能体（extraction agent）作为一个“分叉子智能体（forked subagent）”运行，它共享父级对话的提示词缓存（prompt cache）。

[原文] [Himanshu]: the system prompt prefix is between parent and fork, so most input tokens are cache hits.

[译文] [Himanshu]: 系统提示词前缀（system prompt prefix）在父级和分叉级之间是相同的，因此大多数输入 token 都是缓存命中（cache hits）的。

[原文] [Himanshu]: the user never waits for memory operations.

[译文] [Himanshu]: 用户永远不需要等待内存操作。

[原文] [Himanshu]: the fork is also sandboxed.

[译文] [Himanshu]: 分叉机制也是置于沙箱中（sandboxed）的。

[原文] [Himanshu]: it can read anything on the filesystem, but it can only write to memory paths (isAutoMemPath()).

[译文] [Himanshu]: 它可以读取文件系统上的任何内容，但它只能写入内存路径（isAutoMemPath()）。

[原文] [Himanshu]: MCP tools, the Agent tool, and write-capable Bash are all denied.

[译文] [Himanshu]: MCP工具（MCP tools）、智能体工具（Agent tool）以及具有写入权限的 Bash 全都被拒绝访问。

[原文] [Himanshu]: it's capped at 5 turns to prevent rabbit-holes, and the prompt explicitly tells it: "Do not waste turns attempting to verify content. No grepping source files, no reading code."

[译文] [Himanshu]: 它的上限被限制在 5 轮，以防止陷入无底洞（rabbit-holes），并且提示词明确告诉它：“不要浪费轮次尝试验证内容。不要 grep 源文件，不要读取代码。”

[原文] [Himanshu]: there's also a deduplication mechanism.

[译文] [Himanshu]: 此外还有一个去重机制（deduplication mechanism）。

[原文] [Himanshu]: if you tell Claude "remember that we use bun, not npm" and Claude writes the memory directly during conversation, the background extraction agent detects this (hasMemoryWritesSince()) and skips entirely.

[译文] [Himanshu]: 如果你告诉 Claude “记住我们使用的是 bun，而不是 npm”，并且 Claude 在对话期间直接写入了内存，后台提取智能体会检测到这一点（hasMemoryWritesSince()）并直接完全跳过。

[原文] [Himanshu]: the main agent and the background agent are mutually exclusive per turn window. they never double-write.

[译文] [Himanshu]: 在每一轮窗口中，主智能体和后台智能体是互斥的（mutually exclusive）。它们绝不会重复写入（double-write）。

章节 3：定期整合与内存删除规则

📝 本节摘要：

本节阐述了内存的整合与清除机制。Claude 会通过名为 autoDream 的后台进程，在积累一定时间和会话后，执行四阶段的内存整合任务（涵盖读取、收集信号、合并验证和修剪内容）。值得注意的是，内存没有定时删除的机制，它仅依靠智能体自主判断冲突或失效时才会予以清除。

[原文] [Himanshu]: 2. Periodic consolidation

[译文] [Himanshu]: 2. 定期整合（Periodic consolidation）

[原文] [Himanshu]: this is handled by a feature called autoDream.

[译文] [Himanshu]: 这是由一个名为 autoDream 的功能处理的。

[原文] [Himanshu]: it's a background process that fires when enough time and sessions have accumulated (defaults: 24 hours and 5 sessions since the last consolidation)

[译文] [Himanshu]: 这是一个后台进程，当积累了足够的时间和会话时便会触发（默认：距离上次整合已过 24 小时和 5 次会话）。

[原文] [Himanshu]: when triggered, it runs a four-phase pass over the entire memory directory.

[译文] [Himanshu]: 当被触发时，它会对整个内存目录运行一个四阶段的遍历（four-phase pass）。

[原文] [Himanshu]: First, it reads MEMORY.md and skims existing topic files.

[译文] [Himanshu]: 第一步，它读取 MEMORY.md 并略读现有的主题文件。

[原文] [Himanshu]: Second, it gathers recent signal from daily logs and session transcripts (via narrow grep, never full reads).

[译文] [Himanshu]: 第二步，它从每日日志和会话记录中收集最近的信号（通过小范围的 grep 检索，从不进行全量读取）。

[原文] [Himanshu]: Third, it continues to merging new information into existing files, converting relative dates to absolute, and deleting facts that contradict the current codebase.

[译文] [Himanshu]: 第三步，它继续将新信息合并（merging）到现有文件中，将相对日期转换为绝对日期，并删除与当前代码库（codebase）相冲突的事实。

[原文] [Himanshu]: Fourth, it prunes the memory by removing stale pointers, shortening verbose entries, and resolving contradictions between files.

[译文] [Himanshu]: 第四步，它通过移除陈旧的指针（stale pointers）、缩短冗长的条目以及解决文件之间的矛盾来修剪内存。

[原文] [Himanshu]: The consolidation prompt is explicit: "if two files disagree, fix the wrong one."

[译文] [Himanshu]: 整合的提示词（consolidation prompt）非常明确：“如果两个文件不一致，修复那个错误的。”

[原文] [Himanshu]: AutoDream is itself gated behind a flag (tenguonyxplover).

[译文] [Himanshu]: AutoDream 本身被限制在一个标志之后（tenguonyxplover）。

[原文] [Himanshu]: It runs as a forked subagent with the common read/write tools and a lock file that prevents concurrent consolidation across sessions.

[译文] [Himanshu]: 它作为一个分叉子智能体（forked subagent）运行，配备通用的读写工具，并设有一个锁文件（lock file）以防止跨会话的并发整合。

[原文] [Himanshu]: 3. Memory Deletion: not Automatic

[译文] [Himanshu]: 3. 内存删除（Memory Deletion）：非自动化（not Automatic）

[原文] [Himanshu]: there's no expiration or scheduled cleanup.

[译文] [Himanshu]: 没有过期时间或定时清理计划。

[原文] [Himanshu]: the only way for a memory to be deleted, is through an agent deciding if it's no longer relevant to the codebase, contradicts with other memories, etc.

[译文] [Himanshu]: 删除内存的唯一方式，是通过智能体判断它是否与代码库不再相关、是否与其他内存相冲突等。

[原文] [Himanshu]: memories are continuously refined but never silently removed unless done by Claude Code agents.

[译文] [Himanshu]: 内存不断被完善，但绝不会被默默移除，除非是由 Claude Code 智能体执行的。

章节 4：利用 Sonnet 的内存检索过滤器

📝 本节摘要：

本节解释了 Claude 如何检索并调用内存。由于将所有内存加载至上下文不仅昂贵且缺乏效率，系统采用了一个更轻量级的模型（Sonnet）作为相关性过滤器。主模型响应前，Sonnet 仅依靠内存文件前言（frontmatter）的描述字段，挑选出相关度最高的5个文件投入上下文，以此兼顾效率与针对性。

[原文] [Himanshu]: Retrieving Memory

[译文] [Himanshu]: 检索内存（Retrieving Memory）

[原文] [Himanshu]: how does Claude decide which memories to load, and how does it treat what it finds?

[译文] [Himanshu]: Claude 是如何决定加载哪些内存的，以及它是如何对待它所找到的内容的？

[原文] [Himanshu]: How memories are recalled

[译文] [Himanshu]: 内存是如何被调取出的（How memories are recalled）

[原文] [Himanshu]: obviously, Claude doesn't load all memories into the context; that would defeat the whole purpose of the intricacies of memory writing.

[译文] [Himanshu]: 显然，Claude 并没有将所有内存都加载到上下文（context）中；这会完全破坏内存写入复杂设计的初衷。

[原文] [Himanshu]: MEMORY.md (the index, capped at 200 lines / 25KB) is always loaded into the system prompt but individual memory files are not.

[译文] [Himanshu]: MEMORY.md（索引，上限为 200 行 / 25KB）总是被加载到系统提示词（system prompt）中，但单独的内存文件并不会被加载。

[原文] [Himanshu]: the system uses Sonnet (even if your main model was Opus) as a faster relevance filter.

[译文] [Himanshu]: 系统使用 Sonnet（即便你的主模型是 Opus）作为一个更快速的相关性过滤器（relevance filter）。

[原文] [Himanshu]: when you fire a request, before the main model starts thinking, a non-blocking process: scans all memory file frontmatter (up to 200 files, sorted newest-first) formats a manifest: [type] filename (timestamp): description sends this manifest + your query to Sonnet Sonnet returns the top 5 most relevant filenames only those 5 files get loaded into context

[译文] [Himanshu]: 当你发出一个请求时，在主模型开始思考之前，一个非阻塞进程（non-blocking process）会：扫描所有的内存文件前言/元数据（frontmatter）（最多 200 个文件，以最新优先排序），格式化生成一份清单：[类型] 文件名 (时间戳): 描述字段，将这份清单 + 你的查询请求发送给 Sonnet。Sonnet 返回相关度排名前 5 的文件名。仅这 5 个文件会被加载进入上下文（context）中。

[原文] [Himanshu]: this is why the description field in frontmatter matters so much as it's the only thing Sonnet sees when deciding relevance.

[译文] [Himanshu]: 这就是为什么前言（frontmatter）中的描述字段（description field）如此重要，因为这是 Sonnet 决定相关性时看到的唯一内容。，

[原文] [Himanshu]: the selector is prompted: "if you are unsure if a memory will be useful, do not include it."

[译文] [Himanshu]: 挑选器收到的提示词是：“如果你不确定某个内存是否有用，就不要包含它。”

[原文] [Himanshu]: this would eliminate the false-positives, only allowing the most relevant memories to be fetched.

[译文] [Himanshu]: 这将消除假阳性（false-positives），只允许提取最相关的内存。

[原文] [Himanshu]: it also filters out documentation for tools Claude is already using but selecting warnings and gotchas about those tools.

[译文] [Himanshu]: 它还会过滤掉 Claude 已经在使用工具的那些文档，但会专门挑选关于这些工具的警告和暗坑（warnings and gotchas）。

[原文] [Himanshu]: files already shown in prior turns are excluded too, to keep the 5-slot budget on fresh memories that matter more.

[译文] [Himanshu]: 在先前轮次中已经展示过的文件也会被排除，以确保把这 5 个槽位的预算留给更重要的新鲜内存。

章节 5：怀疑机制、路径安全与外围约束的意义

📝 本节摘要：

本节讨论了内存的时效性警告与路径安全防护。对于超过一天的旧内存，系统会在加载时注入“核实警告”；同时通过强制全局配置与沙箱机制防御遍历攻击或违规篡改。最后，作者总结，即便像 Opus 这样强大的模型，也不被完全信任管理自己的内存。内存系统每一个步骤所施加的外围控制（harness），彰显了对大语言模型进行约束和设定边界的重要性。

[原文] [Himanshu]: Older memories are added with skepticism

[译文] [Himanshu]: 旧内存是在抱有怀疑（skepticism）态度的情况下被添加的。

[原文] [Himanshu]: memories older than one day get an explicit warning injected alongside their content: "This memory is 47 days old. Memories are point-in-time observations, not live state. claims about code behavior or file:line citations may be outdated. Verify against current code before asserting as fact."

[译文] [Himanshu]: 早于一天的内存会在其内容旁边被注入一条明确的警告：“此内存已有 47 天历史。内存是某个时间点的观察记录，并非实时状态。关于代码行为的声明或 文件:行数 的引用可能已过时。在断言为事实之前，请先对照当前代码进行验证。”

[原文] [Himanshu]: the system prompt also reinforces this with a section titled "Before recommending from memory": if a memory names a file path, check the file exists; if it names a function, grep for it; if the user is about to act on the recommendation, verify first.

[译文] [Himanshu]: 系统提示词（system prompt）也通过一个标题为“基于内存提出建议之前（Before recommending from memory）”的章节来强化这一点：如果一条内存命名了一个文件路径，检查该文件是否存在；如果它命名了一个函数，用 grep 检索它；如果用户准备针对该建议采取行动，需先进行验证。

[原文] [Himanshu]: Memory Path Security

[译文] [Himanshu]: 内存路径安全（Memory Path Security）

[原文] [Himanshu]: this is an interesting security detail.

[译文] [Himanshu]: 这是一个有趣的安全细节。

[原文] [Himanshu]: the autoMemoryDirectory setting lets you customize where memories are stored.

[译文] [Himanshu]: autoMemoryDirectory 设置允许你自定义内存存储的位置。

[原文] [Himanshu]: but it can only be set in the global claude settings ~/.claude/settings.json and not project-level settings .claude/settings.json.

[译文] [Himanshu]: 但它只能在全局的 claude 设置 ~/.claude/settings.json 中进行设定，而不能在项目级设置 .claude/settings.json 中设定。

[原文] [Himanshu]: the reason is that if a malicious repo has this path set to a directory with sensitive files (such as ~/.ssh), it would give silent write access to those files.

[译文] [Himanshu]: 原因是，如果一个恶意仓库（malicious repo）将这个路径设定为一个包含敏感文件（比如 ~/.ssh）的目录，它就会获得对这些文件的静默写入权限（silent write access）。

[原文] [Himanshu]: paths are also validated against traversal attacks (.. segments), root paths, and null bytes.

[译文] [Himanshu]: 路径还会被验证以防范遍历攻击（traversal attacks）（.. 片段）、根路径访问和空字节（null bytes）。

[原文] [Himanshu]: the extraction agent's sandbox adds another layer.

[译文] [Himanshu]: 提取智能体的沙箱（sandbox）增加了另一层防护。

[原文] [Himanshu]: even if something weird happens, it can only write to paths that pass isAutoMemPath(). everything else gets denied.

[译文] [Himanshu]: 即便发生了一些奇怪的事情，它也只能向那些通过 isAutoMemPath() 检验的路径写入。其他所有请求都会被拒绝。

[原文] [Himanshu]: Wrap-up: The Harness Matters

[译文] [Himanshu]: 总结：外围控制（Harness）至关重要

[原文] [Himanshu]: It was interesting to see that even for managing the memory of a powerful model such as Opus 4.6, there are strict limitations and boundaries set.

[译文] [Himanshu]: 有趣的是可以看到，即使是为了管理像 Opus 4.6 这样强大模型的内存，这里也设定了严格的限制和边界。

[原文] [Himanshu]: the model isn't left to decide how to format the memory, or to retrieve it.

[译文] [Himanshu]: 并没有把如何格式化内存或如何检索它这件事情留给模型自己去决定。

[原文] [Himanshu]: the format is enforced (YAML frontmatter, one-line index entries, four fixed types).

[译文] [Himanshu]: 格式是被强制执行的（YAML 前言，单行索引条目，四种固定类型）。

[原文] [Himanshu]: retrieval is handled by a separate, cheaper model (Sonnet) that the main model doesn't even control.

[译文] [Himanshu]: 检索交由一个独立的、更便宜的模型（Sonnet）来处理，而主模型根本控制不了它。

[原文] [Himanshu]: deletion has no automatic trigger.

[译文] [Himanshu]: 删除操作没有自动触发机制。

[原文] [Himanshu]: staleness warnings are injected by the harness to emphasize their date.

[译文] [Himanshu]: 陈旧警告（staleness warnings）是由外围控制（harness）系统注入的，以强调它们的日期。

[原文] [Himanshu]: the sandbox restricts where the extraction agent can write.

[译文] [Himanshu]: 沙箱限制了提取智能体可以写入的位置。

[原文] [Himanshu]: even the decision of what NOT to save is hardcoded into the prompt.

[译文] [Himanshu]: 甚至连决定“不保存什么”的逻辑也是被硬编码进提示词（prompt）里的。

[原文] [Himanshu]: the model is powerful, but the harness doesn't trust it to manage its own memory unsupervised. every step has constraints.

[译文] [Himanshu]: 模型很强大，但外围控制系统并不信任它能在没有监督的情况下管理自己的内存。每一个步骤都有着约束（constraints）。