Grok Build 与 Claude Code：上下文、记忆与主循环 • BemoDB 2.0

xai-org/grok-build ↗ 是 SpaceXAI 开源的终端 Coding Agent harness（产品名 Grok Build，CLI 为 grok）。仓库用 Rust 实现终端界面、agent 运行时、工具、工作区与会话状态，Apache-2.0，从 monorepo 定期同步，不接受外部贡献。

Claude Code 是 Anthropic 的同类产品：模型负责决策，工具负责改世界，外面再包一层能撑住长任务的执行框架（harness）。两边表面功能高度重合——读改文件、跑 shell、Skills、MCP、子 Agent、压缩、记忆——但分层和取舍不同。

这篇文章盯三块：主循环（Agent Loop）、上下文怎么腾、跨会话记什么。Grok 侧依据公开源码与 shell 自带说明；Claude Code 侧对照公开行为与既有拆解（含 BemoCode 一类可读的小 harness）。

两边都在做同一件事：context window 有限，却要让模型连续改代码。差别在于窗口怎么腾、跨会话记什么、以及 loop 被拆成几层。

各自是什么#

Grok Build：三种入口，同一套 runtime#

官方定位：全屏终端 UI，理解代码库、改文件、跑命令、搜网页、管长任务。同一套 agent 能力有三种壳：

入口	你怎么启动	实际在干什么
交互 TUI	`grok`	人在终端里多轮对话，有完整界面
Headless	`grok -p "修这个测试"`	不开全屏 UI，跑完把结果打到 stdout 就退出
ACP Agent	编辑器拉起 `grok agent stdio`	当子进程服务端，把能力嵌进编辑器

Headless 解决的是自动化：CI、脚本、批处理里没有人盯着 TUI。模型仍然可以多轮读文件、改代码、跑命令（完整 tool loop），只是交互壳没了。输出可以是纯文本，也可以是 json / streaming-json，方便下游解析。常见约束参数包括：自动批准工具（--always-approve）、限制最多跑几轮（--max-turns）、只开放部分工具（--tools）。文档里示范过把它包成 OpenAI 风格的 chat 封装——本质是 spawn 子进程再解析 JSON，不是另起一套 HTTP Agent 服务。

ACP 是 Agent Client Protocol ↗。类比：

协议	标准化的是
LSP	编辑器 ↔ 语言服务器（补全、跳转、诊断）
MCP	Agent ↔ 外部工具 / 数据源
ACP	编辑器 / IDE ↔ Coding Agent（会话、发话、权限、流式输出、diff）

没有 ACP 时，每个编辑器要给每个 Agent 写专用插件。有了之后，编辑器实现 Client，Agent 实现 Agent 端，可以组合。Grok 本地最常见形态：编辑器 spawn grok agent stdio，双方用 stdin/stdout 上的 JSON-RPC 通信；用户仍在编辑器里操作，权限确认和流式 UI 可以画在编辑器侧。文档点名的方向包括 Zed、Neovim、Emacs 等，以及自定义 ACP 库。另有 WebSocket 中继一类远程形态：浏览器连中继，Agent 出站连同一中继。

和 headless 的分界：headless 偏「一句 prompt → 结果 → 进程结束」；ACP 偏「长会话 + 编辑器 UI 上的权限与流式反馈」。

仓库按 crate 切开职责（名字保留，职责用白话）：

Crate	干什么
`xai-grok-pager`	终端 UI：滚动区、输入框、渲染
`xai-grok-shell`	Agent 运行时：会话主体、headless / ACP 入口
`xai-grok-agent`	Agent 定义：人设、system prompt 拼装、压缩策略
`xai-chat-state`	会话消息状态：历史、估 token、发请求前裁剪
`xai-grok-memory`	跨会话记忆：Markdown 文件 + 本地检索 + 巩固（dream）
`xai-grok-tools`	具体工具实现（读改文件、shell 等）
`xai-grok-workspace`	工作区：文件系统、版本控制、执行、检查点
`xai-grok-compaction`	「整段摘要后重建历史」的压缩引擎，可被上层复用

工具侧 THIRD_PARTY 写明：一部分实现移植自 openai/codex（如 patch / 列目录 / 读文件），一部分移植自 sst/opencode（如 bash / edit / read）。README 另有 Claude Code 兼容：会自动发现 .claude/skills、agents、plugins、MCP、CLAUDE.md、权限 settings 等，降低从 Claude Code 迁过来的成本。

Claude Code（对照基准）#

宿主以 CLI / IDE 为主，主循环与 Anthropic Messages API 绑得紧
上下文侧强调 prompt cache 友好，以及从轻到重的多级压缩
记忆偏「只记代码里读不出来的事实」；项目规则大量在 CLAUDE.md 与 Skills
实现体量大，截断、超长、压缩失败等恢复路径很细

Agent Loop#

Grok：会话独立持有状态，外层收命令，内层反复「问模型 / 跑工具」#

Grok 把一次会话做成独立的 actor（源码里是 SessionActor）：自己持有状态，通过消息和上层通信，而不是谁都能直接改同一份 history。它手里主要是两样东西：

chat history：到目前为止的对话与工具结果
tool context：这轮能调用哪些工具、权限与执行通道

终端 UI、无界面 grok -p、编辑器 ACP 都不直接改这两样。它们只发命令——常见是用户发话、取消、关闭会话。会话做完一步，再把流式文本、工具进度、结束原因推回上层。

好处是：同一时刻只有会话自己在改历史；UI 重绘、编辑器客户端、后台任务完成通知，都不会和「正在跑的一轮」并发写坏 messages。

源码怎么拆#

会话逻辑主要在 xai-grok-shell，按职责拆文件：

位置	干什么
会话主循环（`run_session`）	收命令、空闲时处理队列、后台任务结束后把会话叫醒
处理用户这一句（`handle_prompt` / `process_conversation_turn`）	进入「问模型 → 跑工具」循环；顺带强制收尾、首轮记忆注入
调一次模型（`run_turn_via_sampler`）	刷新鉴权、备好工具列表、发补全请求；若要先压缩或 token 过期，返回「处理完再请求一次」
会话消息状态（`xai-chat-state`）	存 conversation、估 token、发请求前裁剪过长的工具结果

术语对齐：

turn：用户发一句（或队列里弹出一句）到这句彻底结束。一 turn 里可以多次调用模型。
sample：对模型做一次补全请求（通常带上可用工具定义）。
tool call：模型返回「请执行某某工具」；框架执行后把结果写回 history，再 sample。

用户说一句话之后，内层在干什么#

核心是「处理这一句」的内层 loop。下面按源码顺序说 每一步在解决什么问题（括号里是对照仓库用的符号）。

1. 首轮记忆注入
新会话第一轮、且 history 里还没有记忆块时，用当前用户问题去记忆库检索，把命中片段塞进系统提醒。寒暄类问题会换更泛的查询。若 resume 或压缩前已经注入过，则跳过——避免为了重搜打乱 prompt cache 前缀。

2. 可选：压缩预热（two-pass 的第一段）
上下文快到自动压缩阈值时，在后台先把 历史前半段 摘要掉，结果放进缓存。真正触发压缩时，只需再摘要「前半摘要 + 最近几轮」。用户感知是：真正卡住的时间更短，因为重活提前做了。

3. 采样前自动压缩检查
估计占用是否已到约 85% 等阈值。到了就先做整段摘要重建，再问模型。失败默认只记日志并暂时抑制自动压缩，避免每一轮都对同一次失败重复重试。

4. 组装发给模型的请求
从会话消息状态取出 history，做轻量裁剪：旧图片过大则丢、旧工具结果过长则裁或硬删并留占位句，再附上本轮可用工具与可能的记忆注入。这里还不调模型，只是定好「窗口里该有什么」。

5. 调模型
三种结果：

结果	含义	循环怎么走
正常响应	拿到模型输出	继续看有没有工具调用
需要先压缩再采	上下文仍超 / 必须先压	同一 turn 内压完再 sample，不把错误直接抛给用户
需要先刷鉴权再采	token 过期一类 401	刷新后再 sample

6. 没有工具调用
模型这轮只说话。可能直接结束 turn；也可能再走 todo 续跑、强制收尾、或「最终答案必须符合 JSON schema」等 harness 逻辑——都是 turn 尚未真正结束时的补处理。

7. 有工具调用 → 执行工具
真正读文件、改代码、跑 shell。用户取消则结束；否则把工具结果写回 history，回到 loop 顶部，准备下一轮 sample。

8. 工具跑完后再看窗口
有时模型输出不大，但工具 stdout / 大文件内容把 token 估高了。下一轮 sample 前若已超过窗口，先压缩再继续，避免发出注定失败的请求。

9. 超过最大轮数
自动化或防失控上限：达到配置的最大 agentic 轮数就强制停。

串起来：

用户一句 prompt
  └─ turn 开始
       loop:
         记忆？压缩预热？该自动压？
         组装 request → sample
         无工具 → 结束或 harness 补逻辑
         有工具 → 执行 → 必要时再压 → 继续 loop

text

压缩失败或窗口爆掉，优先在 loop 内消化，而不是把 raw API 错误直接抛到 TUI / CI。

两处 harness 级闭环#

强制收尾
Agent 定义文件（.grok/agents/*.md）可以写：结束前必须调用某工具（例如「标记任务完成」），并配置未调用时的提醒文案、最大重试与退避。内层 turn「看起来结束」时检查本轮调过的工具；没调到指定工具，就往 history 塞一条提醒，按指数退避再跑。这是框架强制，不依赖模型自觉。

Prompt 队列与后台唤醒
用户可以连发多句，或后台子任务结束需要把结果接回主会话。队列由会话侧做权威排序，而不是客户端各写各的；任务完成与用户取消的准入要串行，避免两头抢状态。定时 /loop 一类触发也走相关路径。

Agent 定义本身#

xai-grok-agent 用 Markdown 描述 Agent：frontmatter 写工具白名单 / 黑名单、权限模式、预载 Skills、prompt 模式等。
默认模式是「人设接在框架 base template 后面」；也可以改成「正文就是完整 system prompt」，用模板引擎注入工具名等占位符，并避开正文里普通 {{ }} 的冲突。

Claude Code：两层循环#

公开拆解里常见两层结构，名字不同，问题类似：

负责一次用户交互的生命周期
  └─ 单次循环
        压缩检查
        → 调 Messages API（流式）
        → 解析工具调用
        → 执行工具（可并行）
        → 结果写回 messages
        → 继续 / 停止 / 进入某条恢复路径

text

外层循环：从用户提交开始，管到这次交互结束；多个入口最后汇到同一条路径。
内层循环：真正做「压缩 → 调模型 → 跑工具 → 再决定」；出错按类型分支（输出截断、context 过长、可恢复的接口错误等），不是「失败就整段重来一次」。

流式路径上的工具调度、恢复分支都更多，这是体量差异的一部分来源。

Loop 对照#

维度	Grok Build	Claude Code
状态怎么放	会话 actor 独占 history；消息状态模块另管裁剪与估算	以 messages 列表为中心的生成器循环
人怎么接上	TUI / headless / ACP 都是正式入口	CLI 为主，IDE 集成并行
压缩何时插进来	问模型前、问模型失败后、工具跑完后都可能	内层每轮前走多级压缩流水线
如何强制结束	配置「必须调用某工具」并自动补跑	停止钩子 / 任务系统 / 产品策略
兼容别人生态	主动读 Claude Code 目录与 MCP	自有配置体系为主

两边都是「下一步由模型现场决定」，不是预先连好的 workflow。Grok 更强调会话边界清晰与编辑器协议；Claude Code 更强调流式恢复点与 Anthropic 协议细节。

上下文管理#

压力同源：工具输出、源码片段、搜索命中不断往窗口里塞。处理分三层：

发请求前先裁一点（尽量少动整体语义）
快满时做摘要（会丢细节，但能腾出窗口）
摘要之后细节从哪读回来

Grok：以「整段摘要后重建」为主#

1. 发请求前的轻量裁剪#

会话消息状态在组装「发给模型的那一包」时大致会：

内嵌图片总体积接近大约 50MB 时，丢掉最旧的图片——故意不每轮都做，免得总打断前缀缓存（prompt cache / KV cache 前缀）。
占用超过大约一半窗口时，对旧的工具结果做软裁剪或整段删掉，删掉处留一句占位（大意是「旧工具结果已省略」）。
需要时注入记忆提醒（可只影响当次请求，也可写进持久 history）。
再拼成最终请求。

长度用「字节数 ÷ 4」快速估 token，和真实分词器有偏差，但够用来判断该不该动手；压缩引擎与消息状态共用同一套计数口径。

组装前还会先修消息合法性：例如工具调用与工具结果必须成对。压缩和裁剪都假设序列已经合法，否则先修再 clone。

2. 自动压缩：默认大约 85%，但不止这一种触发#

压缩策略写在 Agent 配置里，默认大致是：

用量到窗口的约 85% 就自动压
摘要可以用当前模型，也可以指定更便宜的摘要模型
可选：压之前先让模型把要点写入记忆（memory flush）
可选：两阶段压缩（见下）
摘要本身有墙钟上限（默认约 5 分钟），防止摘要任务跑飞

「到 85%」只是最常见的触发。实现上还会在这些时候动手：

什么时候	在解决什么问题
用户手动 `/compact`	人主动要求压缩；不受「自动压缩暂时关掉」限制
问模型时已经超窗 / 需要靠压缩从错误里恢复	同一 turn 内压完再采，而不是直接失败给用户
工具刚跑完、下一问之前窗口被结果撑满	避免发出注定失败的请求
中途换成 context 更小的模型	新窗口装不下旧历史时主动压
快到阈值时的两阶段预热	后台先摘要历史前半段；真正压缩时只再压「前半摘要 + 最近几轮」，缩短用户可见等待

若自动压缩 确定性失败（不是偶发超时），系统会暂时抑制自动压缩，避免每一轮都重试注定失败的路径。成功压完、用户 rewind、或换成更大窗口后，再解除。手动 /compact 走另一条，不被这套抑制挡住。

Memory flush：压之前可选先让模型把「值得留下的决策 / 事实」写入记忆子系统，再做摘要。摘要会丢细节，这一步用来减轻「关键结论也被摘要掉」的损失。需要记忆功能打开且策略开启。

3. Full-replace：不单独保留尾部原文，整段重写历史#

Grok 的默认做法不是「只删中间、尽量保留最近几轮原文」。共享压缩引擎的注释写得很直：它不挑选要保留的 tail，而是 把整段对话拿去摘要，再重建一份新 history。

流水线可以想成：

准备摘要提示
  → 让模型写摘要（可重试；太短/退化的摘要会判失败）
  → 清洗
  → 按固定骨架拼回新历史

text

分工：

上层 shell：决定何时触发、收集并清洗 turns、准备不同完整度的输入（尽量保留 → 压缩适配 → 只留摘要）、真正调 LLM、渲染 system reminder、落盘
压缩引擎：吃上述输入，返回重建后的 history，不负责写回会话

拼回来之后，大致还在的是：

系统提示
用户侧前缀（环境 / 布局一类，不含当条用户问题正文）
项目指令（如 AGENTS.md 注入块，若有）
最后一条真实用户问题（尽量原样）
当前 turn 刚产生的工具 / 子任务结果（可保留）
中间漫长历史 → 一段摘要
可选：告诉模型「细节在某个文件路径，需要时再读」
可选：压缩后的系统提醒（改过的文件、还在跑的任务等）

4. 摘要之后怎么找回细节#

默认压缩会丢细节。Grok 允许配置摘要之后还留什么回指：

模式	模型事后能做什么
仅摘要（默认）	只看摘要，没有回指
附完整流水路径	摘要里带一句：完整记录在某个 `updates.jsonl`，需要细节去读
附分段文件	摘要外还有按段拆好的 Markdown + 索引；可用读文件 / 搜索找回代码和报错，并约定不要改这些归档文件

产品含义：默认用摘要腾窗口，但可把「还能找回细节」做成可选的外存指针，而不是假装摘要没有信息损失。

5. 用户消息特别长时#

超长输入先落到会话目录下的文件，上下文里只留截断文本 + 本地路径，模型需要时再 read_file。工具结果过大时也是同一类思路：窗口里留指针，磁盘上留全文。

Claude Code：尽量晚做强摘要，并优先保护缓存#

公开拆解里更常被强调的是：

结构分层：系统提示尽量固定，利于 prompt cache；易变环境信息放消息侧
多级压缩：从轻量清理 → 清掉旧工具结果 → 可逆折叠 → 最后才是整段自动摘要
缓存感知：清理会不会打断还热着的缓存；轻量清理甚至按 cache 冷热走不同路径
压缩后接回当前任务：摘要之后主动把当前在改的文件、任务目标接回上下文
消息必须合法：无论崩溃、中断还是压缩，发给接口的工具调用与结果必须成对

默认自动摘要阈值同样常见在约 85% 有效窗口。两边在「何时该摘要」上高度一致；差别在于摘要前做了多少几乎不丢信息的步骤，以及是否把 cache 稳定当作一等约束。

上下文对照#

维度	Grok Build	Claude Code
主压缩形态	整段摘要后重建历史	多级压缩，整段摘要是最后手段
轻量裁剪	旧图片、旧工具结果	轻量清理、旧工具结果、结果长度预算
阈值	默认约 85%	常见约 85%
后台预热	两阶段：先压历史前半段，再压最近几轮	更多在线流水线内完成
摘要后找回细节	可选：完整流水 / 分段文件	压缩后接回当前任务，细节仍可读盘
缓存	避免无谓打断前缀（如图片不每轮淘汰）	系统性的缓存友好清理
协议完整性	消息状态侧先修悬空工具结果再压	规范化管道贯穿崩溃与压缩

一句话：Grok 把「摘要替换」做深（两阶段、压缩后回指、压前写入记忆）；Claude Code 把「尽量晚做强摘要」做深（多级光谱 + 缓存）。

记忆模块#

两边都区分：

本会话历史：这一次 turn 里发生了什么（在 chat history 里）
跨会话仍值得知道的事：下次开新会话还想带着的偏好、结论、坑

差别在落盘形态、检索，以及谁在什么时机写入。

Grok 记忆：Markdown 当真源，本地库做索引（实验特性）#

默认关。打开方式：命令行开关、环境变量，或配置文件里打开记忆。实现 crate 是 xai-grok-memory。

存在哪#

~/.grok/memory/
├── MEMORY.md                         # 全局：跨项目都适用的偏好
└── 项目名-短哈希/
    ├── MEMORY.md                     # 这个仓库的约定和结论
    └── sessions/
        └── 日期-短名-会话id.md       # 某次会话的日志 / 摘要

text

人能直接改：记忆就是 Markdown；会话里可追加，也可用 grok memory edit
不污染仓库：写在用户主目录
同一远程仓库共享：短哈希让不同 clone / worktree 共用一份记忆

怎么搜#

文件会切成 chunk 进 SQLite，检索是 混合的：

关键词全文检索（FTS5 / BM25）——永远可用
若配置了 embedding，再加向量近邻
两路结果按 chunk 合并、分数归一
丢掉空模板、自动生成的脚手架
时间衰减：写在全局 / 项目 MEMORY.md 里的策展内容不衰减；某次会话日志会随时间变「不重要」（half-life 指数衰减）
按来源加权、过滤最低分，可选 MMR 去掉太相似的重复结果
截断到返回条数上限

向量挂了就退回纯关键词。默认量级大约是：最多 6 条、最低分 0.35、向量权重高于关键词；首轮自动注入可以用更低门槛，以免什么都注不进来。

什么时候写#

路径	写什么	为什么这样设计
会话结束自动	轻量元数据：消息数量、前几条用户话题、工具用量、动过哪些路径	可搜、可回顾，但不记 shell 原文，防密钥进日志
用户 `/flush`	让模型写更丰富的会话摘要进 session 日志	「这一次我要沉淀」的显式操作
用户 `/memory …`	直接往全局或项目 MEMORY 加一句	策展事实，长期有效
压缩前 memory flush	压窗口前先让模型把要点写入记忆	减少摘要把关键决策一并丢掉

自动保存 可搜 ≠ 完整推理轨迹。要「决策 / 调试路径」级别内容，靠 /flush 或手写 MEMORY。

什么时候读#

新会话第一轮：按当前问题检索，塞进系统提醒；寒暄用更泛的查询
刚压缩完：窗口被摘要冲掉后，再检索一轮补回来
模型主动查：提供「搜索记忆 / 读某个记忆文件」的工具

若对话里 已经有过 记忆块，就不再重搜重注——为了保住 prompt cache 前缀，而不是为了省一次检索。

Dream：源码里的巩固管线#

「巩固」在源码里就叫 dream，不是比喻。它解决的问题是：session 日志会越积越多，检索噪声变大；需要把近期会话合成进更稳的长期 MEMORY.md。

何时触发（便宜条件先判）：

配置打开了 dream
距上次巩固已经过了足够小时数
自上次巩固以来，session 文件数量够多
再抢锁，避免两个进程同时巩固

不满足就直接返回（太早 / 会话太少 / 未开启 / 出错），不调模型。

跑的时候做什么：

用固定的系统提示让模型做一轮 reflective pass：合并相关主题、用新事实覆盖旧矛盾、相对日期改成绝对日期、丢掉寒暄和临时噪声。输入会带上近期 session 日志，以及（若有）现有 MEMORY，要求 merge 而不是推倒重来。输出写回策展层 MEMORY，并更新「上次巩固时间」。原始 session 文件仍在；dream 改的是长期记忆文档的质量，不是简单删日志。

对外仍标 experimental。和 /flush 的分工：

flush：用户说「这一次先沉淀」
dream：「攒够了，后台合并进长期记忆」

Claude Code 记忆：约束优先#

公开原则更偏：

只记代码读不出来的东西（偏好、约束、已知坑）；路径与架构以仓库为准——防记忆与代码现实打架
与 CLAUDE.md / Skills 分工：静态规则进文档，动态个人知识进 memory
召回常与主循环解耦（异步预取），避免拖慢第一段输出
产品上更强调便签式辅助，而不是完整的本地混合搜索引擎

BemoCode 会把记忆分成用户 / 反馈 / 项目 / 参考等类型并做语义索引——是对 Claude 系习惯的简化复刻，不是官方源码。

记忆对照#

维度	Grok Build	Claude Code
默认开关	实验特性，默认关	产品内建（形态随版本变）
真源	Markdown 文件树	记忆条目 + 项目指令文档
检索	关键词 + 向量 + 时间衰减 + 去重	语义 / 规则召回为主
自动写入	会话元数据；shell 明文不进自动保存	提炼「推不出来」的事实
用户写入	手动追加、flush、直接改文件	记忆命令 / 自动抽取
与压缩	可选压前写入；压后再注入	压缩流水线与接回工作面协同
巩固	dream：门控 + 锁 + 模型合并 session→MEMORY	较少公开「做梦」式批处理

Grok 记忆更像 home 下的第二知识库：结构透明、可搜、可巩固。Claude Code 更像防漂移便签：能少记就少记，代码优先。

长任务里三块如何串起来#

以「修跨多文件 bug，开两小时」为例。

Grok（示意）

新开会话：按问题注入相关长期记忆和旧会话片段
多轮读改跑；工具结果太大就裁掉旧的
占用接近 85%：后台预热摘要；必要时整段摘要重建历史
若打开压前写入记忆：先写入决策再压
压完：留下可选外存指针，并再注入一轮记忆
会话结束：写轻量会话日志；关键节点用户可 flush 成更丰富摘要
数日后：dream 把多份会话日志合并进项目 MEMORY

Claude Code（示意）

系统提示 + 项目指令 + 选择性记忆
工具循环中持续轻量清理和结果预算收紧
仍不够再抬高级别压缩，尽量保住缓存和最近在改的内容
整段自动摘要后，把当前任务焦点接回来
跨会话主要靠记忆原则和项目指令，而不是整库会话语料

周边差异#

安全：Grok 有操作系统级沙箱档位（工作区可写、只读、严格隔离等，Linux Landlock / macOS Seatbelt）；Claude Code 更常见权限模式、规则和危险命令检测
工具血统：明确移植 Codex / OpenCode 的一部分，并兼容 Claude 生态目录
Agent 定义：带 frontmatter 的 Markdown 描述人设、工具集合、是否强制收尾
工程：Grok 公开大规模 Rust workspace；Claude Code 核心不开源，公开认知来自行为、文档和社区拆解

收尾#

Grok Build 与 Claude Code 同属终端 Coding Agent harness：主循环推进任务，上下文工程避免窗口爆掉，记忆减少跨会话重复劳动。

Loop：Grok 用会话 actor、消息状态、采样器分清边界，并补上强制收尾、消息排队和编辑器协议；Claude Code 把两层循环与细粒度恢复点打磨更深。
上下文：Grok 主打整段摘要重建，外加可选外存回指和两阶段预热；Claude Code 主打多级压缩和缓存优先。
记忆：Grok 给出 Markdown + 混合检索 + flush / dream 的完整子系统；Claude Code 更克制，只留代码里推不出来的知识。

从源码学 harness，grok-build 的价值是：模块切开可读，压缩与记忆实现公开。对照产品策略，Claude Code 仍是「缓存与多级压缩」最常被引用的参照。两边互读更清楚：Coding Agent 的上限，往往不在模型会不会写代码，而在窗口满了之后，系统还记不记得自己在干什么。