开发者如何跨客户端和项目管理 AI 代理上下文

这个 Hacker News 线程中的大多数开发者并不会用一个通用的记忆产品来解决 AI 代理上下文问题。他们通过紧邻代码的纯 Markdown 文件、决策记录、可搜索的会话日志，以及在文件系统或命名空间级别对客户端进行严格隔离来解决。这个线程是 Michel_Aventin 发布的一个 Ask HN 帖子，有 29 条评论，是对 Claude Code、Codex、Gemini 和本地模型中实际日常使用情况的实用调查。

主导模式是仓库中的文件，而不是新的数据库

对于“如何在会话开始时为代理提供上下文”这个问题，最常见的答案是代理首先读取的项目级 Markdown 文件。AGENTS.md 和 CLAUDE.md 是典型的例子。

“这就是 agents.md / claude.md 的用途，它是 Claude Code 和 Codex 读取的第一个文件。” — @giancarlostoro

几位评论者更进一步，刻意保持文件较小。@spike021 表示，他们已经不再使用大型的 AGENTS.md 或 CLAUDE.md，而是维护一个或多个针对当前工作范围的项目 Markdown 文件，其中引用特定的模块、命令和数据库模式。所述目标是避免给代理提供它不需要的上下文。

@mceachen 描述了一个更简化的入口点：有时只有一个链接、一个 Sentry ID 和一个技能名称。对于重要的任务，上下文会保存在一份保持最新的“技术项目计划”文档中。同一位评论者认为，给代理的宽松度越大，会话工作被丢弃的可能性就越大，而在实施前审查计划可以防止会话偏离方向太远。

决策记录和规范文档承载了代理会忘记的决策

第二个反复出现的模式是以持久、结构化的形式记录决策，而不是依赖聊天历史。格式各不相同，但功能是一样的：给代理一个查找为什么做某事的地方。

@charlesabarnes 在每个仓库中都保留一个被 git 忽略的架构决策记录（ADR）目录，以及一个被 git 忽略的状态文档，用于从上次中断的地方继续。评论者指出，不需要额外的工具，因为模型通常原生理解这种格式。

@lp92 描述了一种更重的文档制度：每个功能和 bug 修复都有 TDD、FDD、实施计划或根本原因分析文档，以 Markdown 格式分组到逻辑子文件夹中，同时还有一份主系统架构和设计文档。一个主索引文件列出了每份文档并附有简要概述。根据评论者的说法，这个索引减少了冷启动会话中的扫描工作。

“索引文件确实有助于减少冷启动新会话中的扫描工作。” — @lp92

@murillians 指出，规范驱动开发工具，如 OpenSpec、Git SDD Kit 和 GitShipDone，是处理先前决策和设计上下文的一种方式，并指出这些工具位于项目仓库中，因此不会相互污染。

Wiki 和守门脚本强制上下文确实被写入

一种更复杂的模式是项目 wiki，代理必须在完成一轮工作之前更新它。@mapontosevenths 描述使用“Karpathys LLM wiki with QMD”以及一个小型 gatekeeper.py 脚本，代理必须运行该脚本才能完成一轮或开始新一轮。该脚本记录状态、进行 lint 检查，并验证 wiki 是否已更新了发现、经验教训和文档。代理在完成之前无法继续。然后 AGENTS.md 告诉代理在开始重要工作之前使用 QMD 对 wiki 进行语义搜索。

“这在 token 方面很昂贵，但非常值得。如果我愿意，我可以重现项目的任何阶段。我总是知道他们为什么做他们做的事（如果他们做了），而且代理不会真正忘记任何重要的事情。” — @mapontosevenths

权衡是明确的：这种方法消耗 token，但它产生了可审计的决策记录，并使项目可重现。

会话索引和搜索工具填补了聊天历史的空白

几位评论者构建了本地工具来索引过去的会话，以便代理可以搜索它们。共同的想法是聊天记录已经包含决策，但没有供应商以可搜索、跨提供商的形式公开它们。

  • @matthewslotkin 构建了一个工具，在本地索引所有过去的会话以供搜索，并持续构建和维护一个 wiki。
  • @hyldmo 构建了 Farero，它将每次聊天（无论 AI 提供商是谁）存储在 Mac 上的索引 SQLite 数据库中，并将 MCP 工具和一个小提示注入 Codex、Claude 和 OpenCode，以便代理可以搜索每个决策和聊天。
  • @anyonecancode 构建了一个使用 SQLite 存储元数据、使用 XDG 目录约定存储内容的 localhost 工具。它将工作组织成主题，每个主题都有工单、工件和 Claude Code 会话。一个持续的 topic.md 在每次会话结束时更新，压缩会定期将完整内容移至存档，以保持工作上下文较小。
  • @synapsomorphy 从同一个 localhost Web 服务器运行 Claude 和 Codex，将聊天日志以 JSONL 格式存储在每个项目的一个永不推送的 git 分支中，并在 Podman 容器中运行代理。

客户端隔离通常由文件系统或命名空间强制执行

对于顾问和代理机构来说，关键要求是一个客户端的上下文永远不会泄漏到另一个客户端。线程中最简单的答案是分离操作系统身份。

“如果你有单独的客户端，我会为每个客户端使用不同的用户名/登录名，这样会话记录（如 ~/.claude/... 中的）就会被隔离。” — @mceachen

@MadBrad-Develop 将客户端上下文保存在不同的目录中。@cpinto 专门构建了 Estratos 来强制隔离，使用分层命名空间，如 root.agent_name.client-a.project-a1。指令从根、代理、客户端和项目层连接起来，系统防止模型甚至知道存在兄弟客户端子树。评论者表示，这针对的是会计师事务所，在这些事务所中，客户端之间共享上下文是不可接受的。

多代理工作需要共享账本和提交大小的进度单元

运行多种代理类型的开发者通常不会尝试在它们之间同步完整的对话状态。他们通过文件、提交或共享数据库进行同步。

@MadBrad-Develop 构建了一个以 IBM 1401 打孔卡为模型的数据库，通过 IDE 的 MCP 暴露唤醒短语，因此状态保持在几百个 token 中。多个代理读写同一个数据库，这允许根据任务在代理之间切换。

@akst 告诉多个代理维护只写账本以协调并避免重叠工作，并认为当项目被拆分为自包含组件且通信边界在 protobuf 中定义时，这更容易。

@synapsomorphy 提供了一个更明确的规则：

“最小的增量是提交。每个实施轮次必须以一个或多个提交结束，并保持工作树干净。” — @synapsomorphy

同一位评论者建议使用简短的、与提交关联的聊天，以避免昂贵的缓存写入，并跟踪随时间变化的代码行数，作为何时使用更强模型的信号。

失败通常很快被发现，但风险随代理自主性增长

线程中的失败报告成本适中，但形式一致：代理声称完成，人工检查发现工作实际上不正确。

@MadBrad-Develop 报告了一个代理说任务已完成并验证通过，但实际上并未按计划工作。在开发者提出可能的原因后，代理在下次运行时修复了它。成本约为七分钟。评论者将低成本归因于密切关注代理所做的一切。

@mceachen 提出了更大的风险：给代理的宽松度越大，会话工作被丢弃的可能性就越高。在实施前审查技术项目计划被提出作为缓解措施。

构建与购买：许多人自己构建，至少有人说不要

线程中明显分为构建自定义工具的开发者，和一位认为问题已经解决的开发者。

@jwilliams 强烈鼓励构建一些东西，但将真正的问题定义为管理开发者自己的注意力和心理负担，而不是存储文本。建议是构建一个适合一个人工作流程的工具，期望它是可丢弃的，并准备在更好的工具出现时放弃它。

@jen729w，Johnny.Decimal 编号系统的创建者，持相反观点：

“我真的不会[构建东西]。我每周收到 10 封来自已经在构建的人的电子邮件，我不明白这有什么意义。这是一个已经解决的问题。” — @jen729w

提出的解决方案是精心命名的 Markdown 文件和文件夹，每个都有稳定的 ID、Obsidian 库中的索引条目，以及磁盘上对应的文件夹。在同一个文件夹中为特定工作启动代理，既给它人类可读的共享记忆，也给它自己的会话记录，并可使用 --resume 进行过去的对话。评论者说设置大约需要半小时，并且可以免费完成。

实用基线

线程汇聚到一小套无需购买任何东西即可采用的做法：

  1. 在每个仓库中放置一个简短、精选的上下文文件，并保持其范围针对当前工作。
  2. 在 ADR、规范或持续的项目文档中记录决策，而不是依赖聊天历史。
  3. 维护文档索引，以便冷启动会话不必扫描所有内容。
  4. 在操作系统或命名空间级别分离客户端，而不仅仅是通过提示指令。
  5. 对于多代理工作，通过提交、账本或共享数据库进行协调，而不是尝试合并对话。
  6. 在实施前审查计划，因为糟糕会话的成本随着授予代理的自主性而上升。

SUMMARY: 回答 Ask HN 线程的开发者主要通过版本化的 Markdown 文件、决策记录、会话索引以及严格的按客户端目录或命名空间隔离来管理 AI 代理上下文，而不是使用单一的通用记忆产品。

TITLE: 开发者如何跨客户端和项目管理 AI 代理上下文

Sources