Grok Build 与 Claude Code 证据化对照
按源码、仓库文档和公开产品行为完成多维比较，保留未知项
本页解决的问题
先给结论「Grok Build 与 Claude Code 证据化对照」要解决的关键问题是什么？
按源码、仓库文档和公开产品行为完成多维比较，保留未知项
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
完整对照：先校准证据，再谈取舍
Grok Build 一侧可以下钻源码，Claude Code 一侧只记录官方公开行为。两列证据分辨率不同，因此空白项保留空白，不用推测补齐。
课程目标
建立证据等级
区分源码、仓库文档、官方公开文档与本地快照观察。
完成多维对照
从运行时、工具、上下文、安全、恢复与生态比较公开能力。
输出选型条件
把「谁更好」改写为约束、团队能力与交付场景的匹配。
同一问题，两种证据视角
完整证据化对照
| 维度 | Grok Build | Claude Code 公开行为 |
|---|---|---|
| 实现与分发 | Rust Cargo workspace，功能拆成多个 crate；README 给出源码构建入口。 R1 · S1 | 官方提供终端 CLI、IDE、Desktop 与 Web 使用入口。内部语言与模块边界不在本课结论范围。 P1 |
| 状态与并发 | SessionActor 持有会话历史和工具上下文，运行在 Tokio LocalSet；后台任务可独立回传消息。S2 | 公开文档描述会话、后台任务、subagent 与 agent teams 的用户行为；不据此推断内部并发模型。 P5 |
| 工具合约 | ToolKind 枚举进入 capability 过滤，新增 variant 有编译期同步断言；MCP 工具映射为 Other。S3 | 公开权限规则按 Read、Edit、Write、Bash、WebFetch、MCP 等工具名和参数模式控制 allow、ask、deny。 P6 |
| 工具发现 | 内建工具直接注册；MCP 元数据进入快照和 BM25 索引，通过 search_tool / use_tool 延迟发现。S4 | 官方文档说明 Tool Search 可按需加载 MCP 工具，支持延迟连接等待与失败信息反馈。 P3 |
| 上下文压缩 | 源码包含 compaction 配置、分段、two-pass、full-replace 与 recap 辅助路径，可测试自动压缩与恢复。 S5 | 官方行为包括自动压缩、/compact 与 compact instructions；本课不描述其内部算法。P4 |
| 长期记忆 | xai-grok-memory 实现 SQLite 存储、FTS、embedding、MMR 与 Dream 整理流程，并由 session memory state 集成。S6 | 公开机制包含分层 CLAUDE.md 指令与 auto memory，作用域和加载规则由官方文档说明。P4 |
| Hooks | 源码枚举 15 个事件；PreToolUse 可阻断。明确 deny 阻断，Hook 崩溃、超时与失败输出走 fail-open。配置使用 JSON。S7 · R2 | 官方 Hooks reference 公开多类事件、matcher、if 条件及 command、HTTP、MCP tool、prompt、agent 处理器；PreToolUse 可返回拒绝。P2 |
| MCP | 源码确认客户端角色，支持 stdio 与 Streamable HTTP、OAuth、server__tool、动态能力刷新、状态合并与重启。未确认通用 MCP Server 入口。S8 · R3 | 官方文档公开远程 HTTP、本地 stdio、WebSocket、OAuth、动态 list_changed、Tool Search 与连接管理。P3 |
| 权限与沙箱 | ToolKind capability 过滤、权限提示与平台沙箱代码共同组成多层控制；Hook 失败策略不承担强制安全保证。S3 · S7 | 官方公开 allow、ask、deny 规则、managed settings、sandboxed Bash 与文件系统、网络隔离配置。 P6 |
| Subagent | 源码包含 fork、任务、工作树池与 completed subagent worktree snapshot 配置，可将分支任务放入隔离工作树。 S9 | 官方 subagents 具有独立上下文、工具与权限，可前台或后台运行，也可按配置使用 worktree isolation。 P5 |
| 插件生态 | Marketplace 支持索引与目录回退，安装 registry 保存来源；运行时按 scope、enabled 与 plugin-root trust 控制组件。 S10 · R4 | 官方插件与 marketplace 文档公开 skills、agents、hooks、MCP servers、LSP servers 和安装作用域。 P7 |
| 恢复与可观测 | 源码包含会话持久化、MCP 状态通知、50 ms 事件合并、重启退避、telemetry enums 与结构化事件。 S11 | 官方可见行为包含 session resume、verbose / debug、Hooks 状态、MCP 面板与权限诊断；内部持久化拓扑不作推断。 P1 · P3 |
| 源码与治理 | 仓库快照公开源码；README 说明定期从 monorepo 同步，根 Cargo.toml 由生成流程产出，外部贡献不接收。R1 · R5 | 本列依据官方公开产品文档，不将不可见内部实现作为比较事实。 P1 |
两段 Grok 源码锚点
SessionActor 的状态所有权
/// An actor representing an ACP session
/// with its own chat history and tool context.
pub struct SessionActor {
pub(super) agent: RefCell<Agent<ThreadedMvpAgent>>,
...
}新增 ToolKind 强制分流
const _: () = assert!(
ALL_TOOL_KINDS.len() == ToolKind::VARIANT_COUNT,
"ALL_TOOL_KINDS is out of sync"
);这类断言将「新增工具后补权限决策」变成编译期约束。
crates/codegen/xai-grok-workspace/src/capability.rs从对照表走向选型
- 团队愿意阅读 Rust 与多 crate 边界
- 需要追踪故障、状态和本地数据落点
- 能接受公开仓库与实际产品可能存在同步边界
- 团队主要按官方能力和配置完成集成
- 重视终端、IDE、Desktop、Web 的一致工作入口
- 内部实现不可见不影响采购与治理要求
这两组条件可以同时出现。实际方案也可以按项目、数据等级或团队角色组合使用。
课堂练习：证据化选型备忘录
提交物
两页选型 Memo
- 从表中选择六个维度，分别抄录一个 Grok 源码证据和一个 Claude 官方行为证据。
- 标注证据等级，并将所有「更强、更先进、更安全」改为可验证条件。
- 定义项目约束：数据等级、可执行权限、团队栈、恢复目标、扩展需求。
- 给出主方案、备选方案与触发切换的阈值。
- 列出三项未知信息，说明如何通过 PoC 补齐，禁止用架构猜测填空。
证据索引
- R1/R5 README.md、CONTRIBUTING.md、根 Cargo 说明
- S2 acp_session.rs、summary.rs
- S3/S4 capability.rs、tool_index.rs
- S5/S6 compaction 目录、xai-grok-memory
- S7/S8 xai-grok-hooks、xai-grok-mcp、mcp_dispatcher.rs
- S9/S10/S11 fork/worktree、plugins、persistence/telemetry
本篇 24 节最终要留下的能力，是把实现事实、产品行为、推断和未知项分开。证据等级清楚之后，架构取舍才有可复核的基础。
源码快照说明：Grok 一侧依据本地 grok-build-main 快照；Claude 一侧依据 2026 年 7 月可访问的官方公开文档，仅陈述用户可见行为。源码片段经过教学截取。表格中的空白边界是刻意保留的未知项。
「完整对照： 先校准证据，再谈取舍」为什么能找到相关内容
「Grok Build 一侧可以下钻源码，Claude Code 一侧只记录官方公开行为。两列证据分辨率不同，因此空白项保留空白，不用推测补齐」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「这两组条件可以同时出现。实际方案也可以按项目、数据等级或团队角色组合使用」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
- 团队愿意阅读 Rust 与多 crate 边界
- 重视终端、IDE、Desktop、Web 的一致工作入口
- 从表中选择六个维度，分别抄录一个 Grok 源码证据和一个 Claude 官方行为证据
先区分找得到和找得准
把「源码快照说明： Grok 一侧依据本地 grok-build-main 快照；Claude 一侧依据 2026 年 7 月可访问的官方公开文档，仅陈述用户可见行为。源码片段经过教学截取。表格中的空白边界是刻意保留的未知项」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「完整对照： 先校准证据，再谈取舍」走到「建立证据等级」
「完整对照： 先校准证据，再谈取舍」先把问题落在「Grok Build 一侧可以下钻源码，Claude Code 一侧只记录官方公开行为。两列证据分辨率不同，因此空白项保留空白，不用推测补齐」上；到了「建立证据等级」，讨论继续推进到「区分源码、仓库文档、官方公开文档与本地快照观察」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「完整对照： 先校准证据，再谈取舍」：Grok Build 一侧可以下钻源码，Claude Code 一侧只记录官方公开行为。两列证据分辨率不同，因此空白项保留空白，不用推测补齐
- 「建立证据等级」：区分源码、仓库文档、官方公开文档与本地快照观察
- 「最后的要点」：定义项目约束：数据等级、可执行权限、团队栈、恢复目标、扩展需求
最后的「最后的要点」把讨论落到「定义项目约束：数据等级、可执行权限、团队栈、恢复目标、扩展需求」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。