免费 · 系统 · 可实践
搜索 EN 从第 1 课开始
课程/他们会这样考你/Grok Build 专题 · 30 道灵魂拷问
专题篇章 · 拆开一只生产级 Coding Agent

Grok Build 专题 · 30 道灵魂拷问

每题附考察意图、答题框架与加分点：运行时循环 / Compaction / 工具权限 / 记忆检索 / 沙箱安全 / MCP 集成

本页解决的问题

先给结论

「Grok Build 专题 · 30 道灵魂拷问」要解决的关键问题是什么？

每题附考察意图、答题框架与加分点：运行时循环 / Compaction / 工具权限 / 记忆检索 / 沙箱安全 / MCP 集成

判断标准

让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。

下一步

写下一个问题：试完这个方法后，你能用什么证据回答它？

常见误区

结论听起来很完整，却没有检查最关键的假设。

怎么用这一页
每道题都标注了提问者。这一章偏底层工程，技术同事的问题也最不留情面。
🎙 面试官想验证你是真懂，还是在背名词
👔 老板要的是解释和承诺
🛠 技术同事在试探你值不值得信任
每题给出三层：对方在考察什么 → 答题框架 → 加分点。答不上来的环节，点末尾的课程页回去补。
Q1技术同事
「你天天说 Coding Agent，它一轮循环里到底发生了什么？别拿 PPT 那套糊弄我。」
🎯 对方在考察什么
试探你是把 Agent 当黑盒，还是真的理解运行时。答「大模型加工具循环呗」这种一句话就露馅了。对方想听你顺着调用链，把几个关键组件的分工讲清楚。
🧭 答题框架
  1. 从入口讲起：用 Grok Build 举例，真实入口在 main()，按运行分支分发（headless、stdio、leader、交互 TUI），最后都汇到同一个 Agent 宿主。
  2. 三个 Actor 分工：SessionActor 负责 turn 编排，接收命令、启动待处理 turn、处理完成通知；ChatStateActor 独占对话状态；SamplerActor 负责流式的模型请求。
  3. 隔离单位：每个 Session 跑在独立 OS 线程上，带自己的 current-thread Tokio runtime 和 LocalSet。会话之间天然隔离，一个卡死拖不垮别人。
  4. 收尾机制：用户点停止靠 CancellationToken 协作式终止，各 Actor 有序退出，这就是取消边界。
⭐ 加分点能说出「对话状态由 ChatStateActor 通过消息队列串行独占，所以不需要共享锁」这一句，技术同事会立刻知道你真读过架构，后面的合作态度都会不一样。
用这些课程页组织答案 → 从 main() 到第一轮采样 Session Actor 与取消边界 79 个 Workspace 成员
Q2面试官
「Coding Agent 动不动跑几十轮，上下文很快就满了。生产级产品是怎么扛住的？」
🎯 对方在考察什么
考你对上下文预算的工程化理解。只会说「把历史压缩一下」的人露馅：对方想听触发阈值、判断逻辑、预算控制这些能落地的机制，这是 demo 和产品的分水岭。
🧭 答题框架
  1. 先给触发机制：以 Grok Build 为例，默认在上下文使用率达到 85% 时允许自动压缩。判断公式是 used × 100 >= context_window × threshold_percent，纯整数比较。
  2. 压缩本身要限时：单次压缩有 300 秒的墙钟预算。压缩是为了救会话，自己耗时失控就本末倒置了。
  3. 讲可选能力：memory flush 和 two-pass 默认都关闭。two-pass 开启后，接近阈值时先在后台投机摘要历史前缀，正式压缩时再把摘要和近期尾部合并总结。
  4. 拔高一层：这些都收在 CompactionPolicy 一个显式配置对象里，阈值、压缩模型、预算全部可调。生产级系统把策略做成配置，demo 把策略写死在代码里。
⭐ 加分点主动指出 Token 用量是估算值，阈值比较用饱和乘法防溢出、窗口为 0 时直接返回 false。能讲到这种边界处理，说明你看过真实实现，这在 PM 里凤毛麟角。
用这些课程页组织答案 → Compaction：85% 阈值与 two-pass 估算、百分比与严格阈值
Q3面试官
「让你给 Coding Agent 规划工具集，几十个工具怎么管？哪些能直接跑，哪些要用户点头？」
🎯 对方在考察什么
考工具系统的设计能力。张口就说「每个工具单独配一遍权限」的人露馅了，几十个工具根本配不过来。对方想听分类学、默认语义和分层控制这套体系化思路。
🧭 答题框架
  1. 先给分类学：Grok Build 用 ToolKind 枚举给工具定语义种类。读文件、搜索、网页抓取这类种类默认只读；编辑、删除、执行命令这类默认有副作用。
  2. 默认值可覆盖：is_read_only() 只是种类层的默认语义，具体工具可以用自己的元数据覆盖，分类和个体解耦。
  3. 说清关键边界：只读分类推不出「自动执行」。最终放行还要过命令规则、沙箱、Hook 和用户交互批准这几层，分类只是决策的第一个输入。
  4. 补上注册机制：内置工具走静态注册表，外部 Toolset 走进程级 Preset 注册，MCP 工具运行时动态发现。三类来源统一收口，管理成本才不会爆炸。
⭐ 加分点举 Task 这个反例：子任务听起来无害，源码把它标为非只读，因为子 Agent 可以执行写操作。能讲出这种边界 case，说明你真的过了一遍分类表。
用这些课程页组织答案 → ToolKind 与只读语义 Toolset Preset 注册表 实现族、注册表与动态 MCP
Q4技术同事
「Agent 的记忆，说白了就是把聊天记录存文件里，用的时候 grep 一下吧？」
🎯 对方在考察什么
挑衅式提问，试探你懂多少检索工程。顺着说「差不多」就掉坑里了。对方想听召回路径、降级策略和排序细节，这些决定记忆系统好不好用。
🧭 答题框架
  1. 先纠正前提：生产级记忆是一条检索流水线。以 Grok Build 为例，查询前先同步脏文件：watcher 监听 Markdown 变更，搜索开始时重建对应索引，外部修改才不会丢。
  2. 双路召回：FTS5 BM25 关键词检索始终可用，向量 KNN（sqlite-vec）在 embedding 可用时叠加。embedding 失败只记 warning，自动降级成 FTS-only，整次搜索照常返回。
  3. 排序有讲究：双路分数各自归一化后加权合并，再乘时间衰减（session 记忆按半衰期衰减，global 和 workspace 视为长青）、来源权重和访问增益。
  4. 多样性可选：MMR 重排默认关闭，开启后按相关性与 snippet 差异度做贪心重排，最后截断到 max_results。
⭐ 加分点补一句后台还有 Dream 机制：空闲门控触发，用 DreamLock 防并发，后台整理记忆再写回。说明记忆系统有读也有写维护，你看到的是完整闭环。
用这些课程页组织答案 → 从文件变更到混合排序 Dream 的真实机制 Token 估算与阈值
Q5老板
「你要推全员用 Coding Agent？它要是把代码库删了，或者把源码传出去，这责任谁来担？」
🎯 对方在考察什么
考期望管理加机制理解。拍胸脯说「绝对安全」的人最危险；只会说「有沙箱」也不够。对方想听分层防护的具体方案，以及你敢不敢诚实交代边界。
🧭 答题框架
  1. 先给结论：风险可控，核心是内核级沙箱。Grok Build 内置五种 Profile：workspace（默认）、devbox、read-only、strict、off，各自定义文件读写和子进程网络的能力集合。
  2. 讲机制：约束落在操作系统层，macOS 走 Seatbelt、Linux 走 Landlock。真实边界看解析后的能力集合，Profile 名字只是方向。
  3. 给推广方案：按人群配 Profile。代码审查用 read-only，高敏感仓库用 strict，还能配 custom profile 额外 deny 掉 ~/.ssh 这类目录。项目配置无法悄悄覆盖全局同名策略，安全底线握在管理员手里。
  4. 诚实交底：平台不支持或应用失败时，沙箱会记录警告继续运行。所以要叠加权限审批和 Hook 审计做分层防护，没有单点银弹，责任靠制度加机制共担。
⭐ 加分点主动分清两层：Hook 是 fail-open 的，Hook 自己崩了工具照跑，所以它只适合提醒和审计；强制性保证必须放在权限层和沙箱。能把这两层说清楚的人很少。
用这些课程页组织答案 → 五种沙箱 Profile 从工具请求到受限执行 Hooks：明确 deny 才阻断
Q6技术同事
「接个 MCP Server 不就是加两行配置的事？这活你怎么还给排了一个迭代？」
🎯 对方在考察什么
反向试探你对生态集成工程量的判断。以为「协议通了就完了」的 PM，排期一定翻车。对方想听协议外围那一堆脏活，你说得越具体，排期越有说服力。
🧭 答题框架
  1. 先对齐角色：Grok Build 是 MCP 客户端，要同时支持 stdio 和 Streamable HTTP 两种传输，外加 OAuth：凭据存本地 JSON 文件，文件锁配合原子写防多进程冲突。
  2. 命名与冲突：工具注册名是 server__tool，双下划线恰好出现一次。两个 Server 各有一个同名工具时，各自拿到不同 ToolId，模型侧才不会打架。
  3. 可见性分流：工具多了不能全塞提示词。禁用的、只给 UI 用的、模型可见的分三路处理，快照加 BM25 索引让模型按需搜索工具。
  4. 断线恢复：状态事件在 50 毫秒窗口内合并，stdio 重启按 1 秒、4 秒、16 秒退避，还要靠 client_id 护栏防止旧连接的断线事件误删新连接。
⭐ 加分点一句话收尾：MCP 集成的工程量集中在协议外围，命名、可见性、身份、状态合并和恢复策略决定连接能否长期稳定。这就是排一个迭代的原因，技术同事听完会主动帮你补细节。
用这些课程页组织答案 → MCP 连接、发现与恢复 动态 MCP 工具 Plugin Marketplace 与信任
Q7面试官
「你研究过 Grok Build 的源码？那你告诉我，xAI 为什么选 Rust？给我一个确定的答案。」
🎯 对方在考察什么
这题埋了陷阱：「确定的答案」根本不存在。对方在看你有没有证据边界意识，会不会把合理解释包装成官方事实。张口就替 xAI 代言动机的人，做竞品分析也一定掺水。
🧭 答题框架
  1. 先立规矩：把结论分成「源码事实」和「课程推断」两套标签。源码能证明的：edition 设为 2024、Tokio 1 开启 full feature、名为 xai-grok-pager 的原生 bin target、release-dist 里的 LTO 和 panic 配置。
  2. 再给推断：原生二进制方便把 CLI 和运行时一起交付，所有权和 Send 边界有助于管理多线程会话，强类型适合复杂协议和状态转换。这些是基于代码形态的解释，要标明是推断。
  3. 直接说破：选型背后的组织动机没写进源码。「xAI 为了性能选 Rust」这种话拿不出仓库证据，我不会说。
  4. 拔高一层：本章对照表用四级证据分级：源码、仓库文档、官方公开文档、本地快照观察。证据不够的格子保留空白，不用推测补齐。
⭐ 加分点面试官要的正是第 3 步。敢在压力下说「这个问题源码回答不了」，比编一个漂亮答案值钱得多，这就是产品经理的证据素养。
用这些课程页组织答案 → Rust 选型：事实与推断 证据化对照 工程复盘与证据边界
Q8技术同事
「用 Rust 写 Agent 图什么？编译半天，招人还难。我拿 TypeScript 两周就糊一个出来。」
🎯 对方在考察什么
试探你是跟风吹 Rust，还是能说出可验证的工程收益。同时看你敢不敢承认代价，只会捧不会讲取舍的 PM，技术团队不会真心配合。
🧭 答题框架
  1. 先认账：编译时间、生命周期约束、学习门槛都是真实代价，源码课也是这么标注的，没必要嘴硬。
  2. 给可验证收益：每个 Session 跑独立 OS 线程加 current-thread runtime，所有权和 Send 边界让多线程会话状态不靠自觉来管；enum 加 Result 把 Agent、Session、Sampler 的领域边界建在类型上。
  3. 举个硬例子：ALL_TOOL_KINDS 有编译期断言，长度和 ToolKind 枚举数量对不上直接编译失败。新增工具种类必须重新过一遍权限分流决策，这种约束靠 code review 很难兜住。
  4. 收口：原生二进制把 CLI 和运行时一起分发，用户不用装依赖。两周糊出来的是 demo，这套是产品。
⭐ 加分点补一句「多线程一定更快」这类话缺少仓库证据，属于要标注的推断。技术同事看到你连自己立场的证据边界都守，态度会立刻不一样。
用这些课程页组织答案 → Rust 选型：事实与推断 Session Actor 与取消边界 工程复盘与证据边界
Q9面试官
「同一个读文件工具，你们代码里居然有好几套实现。这也叫架构？改一个 bug 要改几遍？」
🎯 对方在考察什么
考多协议兼容的代码组织。对方故意把「实现族」说成重复代码，看你能不能讲清这是命名空间隔离，以及一条工具从定义到执行的完整流水线。
🧭 答题框架
  1. 先正名：这是按协议划分的实现族。xai-grok-tools 里平行放着 grok_build 主产品族、grok_build_concise 精简族、grok_build_hashline、codex 和 opencode 兼容族，memory、lsp、skills 按能力单独拆模块，namespace 枚举里还有 MCP 留给运行时外部工具。
  2. 组装有流水线：ToolRegistryBuilder 负责实现选择和参数重命名，finalize(config, context) 产出 FinalizedToolset，里面装着 definitions、resources 和 dispatch。
  3. 会话接入一个口：ToolBridge 持有 registry，把工具定义提供给模型，调用结果以 ToolOutput 交回会话。MCP 工具运行时经 register_mcp_tools 注册进同一个 registry，和内置工具共用执行通道。
  4. 回应质疑：兼容另一套 harness 是换一族实现的配置问题。真要所有协议共用一份代码，兼容逻辑会把每个工具都搅成 if 森林，那才是改一个 bug 要改几遍。
⭐ 加分点提炼一句分层：实现族解决多套协议的代码组织，registry 负责组合与运行时注册，ToolBridge 连接会话。三层各管一事，新加一族协议支持时，执行链路一行不用动。
用这些课程页组织答案 → 实现族与动态 MCP ToolKind 与只读语义
Q10老板
「订阅费一年好几万，要不咱们自己写一个 Coding Agent？你评估一下，两个月能上线吗？」
🎯 对方在考察什么
考工程量判断和期望管理。拍胸脯说能和一口回绝都不合格，老板要的是一个有数字、有维度、有替代方案的评估。
🧭 答题框架
  1. 先给量级：Grok Build 光 Cargo Workspace 就有 79 个成员，其中 62 个在 codegen 目录。这是 xAI 做到生产级的真实体量，两个月能做出来的只有 demo。
  2. 拆九个维度：结课工作台列了九维决策：入口、状态并发、模型流、工具合约、上下文记忆、安全、恢复、可观测、扩展生态。每一维都要给出合约、故障路径和验证方式。
  3. 给判断标准：五条硬约束里挑两条问自己：崩溃后能可解释地恢复吗？敏感数据落点说得清吗？答不上来就不该上线。
  4. 给建议：先用成熟产品跑半年，沉淀出我们真实的权限、审计和恢复需求，再评估自研哪一层。全栈自研很难划算，自研某一层可能值。
⭐ 加分点主动提 Grok Build 仓库是 Apache 2.0 的，可以拿来研究和构建。但它定期从内部 monorepo 单向同步、不收外部 PR，别把它当成现成的社区底座。
用这些课程页组织答案 → 79 个 Workspace 成员 Coding Agent 设计工作台 工程复盘与证据边界
Q11面试官
「你们产品的 system prompt 是怎么管理的？线上出了怪行为，怎么排查是哪段指令惹的祸？」
🎯 对方在考察什么
考 prompt 的工程化管理。答「维护一个大字符串模板」的人还停在作坊阶段，对方想听结构化、可检查、可回放的方案。
🧭 答题框架
  1. 给结构化答案：Grok Build 用 PromptContext 结构体保存全部渲染输入，带 Serialize 和 Deserialize derive，能整体序列化下来检查。排查看的是数据，猜的成分就少了。
  2. 字段分三组：版本与模板（version、prompt_mode、audience、build_timestamp_utc），配置与身份（agents_md_files、persona_summaries、role_instructions、memory_enabled），用户运行环境（os_name、shell_path、working_directory、current_date）。
  3. 渲染分工：TemplateOverride 决定基础模板，ToolBridge 提供工具状态和描述，TemplateRenderer 合成各个 section，输出最终 system prompt。
  4. 更新边界：Agent 构建后源码注释称「effectively immutable」，但保留 finalize_prompt 这个显式入口，更新构建时间戳后重新渲染。
⭐ 加分点点出「可序列化的渲染输入」是排查 prompt 事故的关键：任何一次会话的 prompt 都能还原成一份结构化数据，回放和 diff 都有抓手。
用这些课程页组织答案 → PromptContext 渲染输入 Agent 的字段边界
Q12面试官
「主会话一套提示词，子 Agent 一套，还要兼容别家工具格式。模板体系怎么设计才不失控？」
🎯 对方在考察什么
考多模板的产品化方案。答「多写几个模板文件」的人没想过失控问题，对方想听一个有限枚举加逃生门的收敛设计。
🧭 答题框架
  1. 给枚举：Grok Build 的 TemplateOverride 只有三个变体：None、Codex、Custom(String)，默认 None。模板选择被收敛成一个枚举字段。
  2. None 也有两套：Primary 会话用标准 base template，Subagent 用对应的紧凑模板，给子会话省 token。
  3. Codex 是兼容位：源码注释定义为 apply-patch profile 模板，配合 codex 实现族里的 apply_patch、read_file、list_dir 这些兼容实现，服务另一套工具协议。
  4. Custom 是逃生门：调用方直接提供完整模板字符串，覆盖枚举照顾不到的场景。
⭐ 加分点点破模板和工具是配套切换的：切到 Codex 模板的同时，工具也换成对应的兼容实现。只换提示词那半边，兼容出来的是个缝合怪。
用这些课程页组织答案 → TemplateOverride 三变体 实现族与动态 MCP
Q13技术同事
「我照文档注册了个自定义 toolset preset，当前会话里死活找不到。你们这平台设计有 bug 吧？」
🎯 对方在考察什么
甩锅式提问。考你懂不懂注册表的时序语义和可见性设计，能不能把对方眼里的「bug」讲成有明确理由的设计，并给出排查路径。
🧭 答题框架
  1. 先给结构：注册表是进程级的，OnceLock 加 Mutex 包住一个 HashMap，存「名称到构建函数和可见性」的映射。builder 是 fn() 返回 ToolServerConfig 的函数指针，解析时才调用生成配置。
  2. 解释时序：已经解析过的配置不会回写。会话配置解析完成之后再注册，这个会话看不到新 preset；之后新解析的配置才查得到。源码注释明确建议在第一次解析前完成注册。
  3. 检查可见性：register_toolset_preset 注册的是 Public，会进 preset_names 公开枚举；register_internal_toolset_preset 是 Internal，只能按名解析，枚举里看不到。用枚举去验证 Internal preset 会误判成「没注册上」。
  4. 给结论：这是启动一致性设计。晚注册要是能悄悄改掉已解析的会话配置，那才是真 bug。
⭐ 加分点直接给排查口诀：先确认调的是哪个注册函数，再确认注册发生在配置解析之前还是之后，九成问题出在这两处。技术同事最吃这种「你比我还熟」的回答。
用这些课程页组织答案 → Toolset Preset 注册表
Q14面试官
「不同工具的参数名五花八门，file_path、path、directory 混着来。你要做跨工具的展示和数据分析，怎么办？」
🎯 对方在考察什么
考归一化合约的设计能力。答「写个映射表」只是开始，对方想听稳定投影和原始数据怎么分工，以及合约怎么演进。
🧭 答题框架
  1. 给方案：Grok Build 把少量稳定语义投影进 x.ai/tool 元数据。canonical fields 只有八个：path、offset、limit、command、description、cwd、directory、pattern。
  2. 给合约：CanonicalToolMeta 七个字段：version、name、kind、namespace、label、read_only、input，TOOL_META_VERSION 是数字 1。展示、遥测和跨工具分析共用这套词汇。
  3. 说清边界：input 是投影，可以缺字段甚至整体省略。grep flags、replace_all 这类非共享字段会被丢掉，编辑前后文本这种大字段不进投影，完整数据留在 raw_input。
  4. 讲取舍：投影层追求稳定轻量，宁可少字段也要保证语义跨工具一致；要全量就回 raw_input 拿。
⭐ 加分点version 字段是给合约演进留的门：今天是 1，字段语义将来要变时，消费方能按版本区分处理。这是做数据合约的基本功，说出来就是降维打击。
用这些课程页组织答案 → Canonical input 稳定投影 ToolKind 与只读语义
Q15面试官
「85% 才触发压缩，万一一轮工具输出直接把上下文打爆呢？你的预算机制拿什么兜底？」
🎯 对方在考察什么
考阈值之外的边界思维。只记得 85% 这个数的人答不了这题，对方想听预留空间、估算来源和防御性细节。
🧭 答题框架
  1. 先给三个原语：xai-token-estimation 提供 usage_percentage（total 为 0 返回 0，结果封顶 100）、exceeds_threshold（整数交叉相乘，used × 100 >= window × percent，等号即触发）和 exceeds_threshold_with_headroom。
  2. headroom 是兜底：在百分比阈值之前预留固定 token 空间。窗口 100,000、阈值 85%、headroom 4,000 时，触发点从 85,000 提前到 81,000，给大输出留缓冲。
  3. 估算来源分两路：请求前用本地粗估，UTF-8 字节数除以 4，单张低分辨率图片固定按 765 token；请求完成后用服务端 usage 校准。百分比函数不管来源，只算调用方传进来的数。
  4. 防御性细节：乘法用饱和乘法防溢出，headroom 的减法用 saturating_sub，窗口为 0 一律返回 false。
⭐ 加分点当场手算：窗口 128,000、阈值 85%，无 headroom 最早 108,800 触发；headroom 4,000 时提前到 104,800。算得出来，对方就信你真懂这个公式。
用这些课程页组织答案 → 估算、百分比与严格阈值 Compaction 85% 阈值
Q16面试官
「Agent 的长期记忆越攒越乱，你打算什么时候整理？做个定时任务半夜跑一遍？」
🎯 对方在考察什么
考后台维护任务的工程设计：触发条件、并发控制、幂等和失败恢复。「定时任务跑一遍」恰好是最容易翻车的答案。
🧭 答题框架
  1. 触发讲准确：Grok Build 的 Dream 把近期 session 日志和 MEMORY.md 合并成长期记忆。入口有三个：会话结束、/dream 手动命令、可选的周期检查。check_interval_secs 默认是 None，周期检查默认不开，不能说成「空闲必然自动运行」。
  2. 三道门控：enabled 默认 true 但子 Agent 会话直接跳过；min_hours 默认 4，用锁文件 mtime 记上次成功时间；min_sessions 默认 3，统计上次整理后修改的 session 文件并排除当前会话。
  3. 并发与预算：DreamLock 用 .dream-lock 存 PID，是最佳努力锁，源码注释明说它不保证严格互斥，所以整理过程必须容忍重复。输入截 32K，模型调用 30 分钟超时。
  4. 失败恢复：模型返回空或没有 Markdown 标题就不写不删；写 MEMORY.md 失败调 rollback 恢复旧锁状态；写成功才清理 session，5 分钟内还活跃的文件跳过；索引只移除真删掉的路径。
⭐ 加分点提炼一句「成功边界决定清理边界」：没确认写入成功之前，原始 session 一个都不删，失败之后随时能重来。这是所有后台整理任务的通用设计准则。
用这些课程页组织答案 → Dream 的真实机制 从文件变更到混合排序
Q17老板
「上周让 Agent 跑的那个重构断在一半，重来一遍又是一遍钱和时间。就不能接着干吗？」
🎯 对方在考察什么
考恢复机制的产品理解和期望管理。老板要的是「能接、怎么接、什么情况接不了」三段式，含糊说「应该可以」下次翻车还是你背锅。
🧭 答题框架
  1. 先给结论：能接。子 Agent 支持从已完成的任务恢复，ContextSource::Resumed 会复制原始 transcript 和工具状态，改到一半的 worktree 优先复用；目录被清了也没关系，有 snapshot_ref 能从持久 git ref 重建。
  2. 讲身份保护：恢复有校验，subagent_type 必须和原来一致，Persona 显式给出时也要一致。模型直接 pin 回原模型，中途换模型的请求会被软忽略，避免上下文错位。
  3. 交代接不了的情况：原 transcript 超过目标模型上下文窗口的 80% 会拒绝恢复；transcript 复制失败也会失败关闭，系统不会给你一个假装恢复了的会话。
  4. 管理预期：plan 状态和信号不在复制范围内，接手后计划要重新确认，这是可靠续跑，不是无缝续播。
⭐ 加分点解释 80% 上限的用心：恢复回来还要继续干活，上下文一开始就快满的话，跑两轮又得压缩，体验反而更差。拒绝是在保护任务质量。
用这些课程页组织答案 → 子 Agent 四个隔离维度
Q18面试官
「子 Agent 的隔离，你们分几级？低、中、高？」
🎯 对方在考察什么
陷阱题。顺着「分几级」答下去就输了，对方在看你会不会把正交的维度捏成一根轴。真读过源码的人会先纠正问题本身。
🧭 答题框架
  1. 先纠正模型：隔离是四个正交维度，一根「低中高」轴装不下：上下文来源、身份连续性、工作目录、文件改动空间，要分开判断。
  2. 逐个给枚举：上下文是 ContextSource 的 New 或 Resumed；改动空间是 SubagentIsolationMode 的 None 或 Worktree，枚举里没有「sandbox」这个成员；工作目录按 worktree、override、父目录的优先级解析。
  3. 举组合反例：Resumed 加 None 完全合法，继承上下文但用父工作区；New 也推不出独立文件空间，新会话默认还在父 cwd 里改文件。
  4. 补充边界：公开枚举只有 New 和 Resumed，shell 内部另有 Forked 分支用于从父会话镜像上下文，不能把它说成公开枚举成员。
⭐ 加分点点破最常见的混淆：None 描述的是文件工作空间，跟对话历史无关。None 模式的子 Agent，上下文窗口照样是独立的。能分清这两件事的人非常少。
用这些课程页组织答案 → 子 Agent 四个隔离维度 AgentDefinition 与 Persona 合并
Q19面试官
「spawn 参数、role 默认值、persona 默认值都能设置模型，最后听谁的？」
🎯 对方在考察什么
考配置合并的精确理解。给一个笼统的整体优先级排序就露馅了，真实设计是逐字段级联，还要先确认字段在那种结构里存不存在。
🧭 答题框架
  1. 给级联顺序：逐字段级联：spawn 显式 override 最高，然后 role 默认值，再到 persona 默认值，都没有就留 None 交给父级继承。
  2. 强调「逐字段」：这套优先级按字段各自走。model 听 spawn 的同时，reasoning_effort 可以来自 persona。还要先问字段存不存在：persona 就不提供 capability_mode。
  3. 给结果结构：解析产物是 EffectiveRuntimeConfig，字段有 model、reasoning_effort、capability_mode、persona、persona_instructions、role_prompt、isolation 这些。源码里没有 temperature、max_tokens 和 tools 字段。
  4. 补 fallback：解析完 shell 还有一层：reasoning_effort 仍为空会读 AgentDefinition.effort。model 的完整顺序是 runtime override、per-agent pin、AgentDefinition.model、父模型继承。
⭐ 加分点把方法论说出来：「按字段问优先级之前，先问字段存不存在」。很多人背了一套整体排序，一追问 capability 从哪来就当场露馅。
用这些课程页组织答案 → AgentDefinition 与 Persona 合并
Q20技术同事
「我配了个 PreToolUse hook 拦危险命令，昨天脚本自己崩了，结果命令照跑！你们这安全机制是摆设？」
🎯 对方在考察什么
考 fail-open 语义。你要能解释这是有意的取舍，说清阻断的准确条件，再给出强制保证该放在哪一层。慌着道歉的 PM 会被判定不懂系统。
🧭 答题框架
  1. 先讲清语义：这是设计好的 fail-open。Hook 崩溃、超时、退出码非 0 非 2、stdout 无效，dispatcher 都记警告后放行。源码注释明确要求 Hook 故障不能破坏工具可用性。
  2. 阻断只有两条路：返回有效 JSON 且 decision 为 deny；或者没有有效 JSON 但退出码是 2。注意 JSON 优先：有效 JSON 写了 allow，就算退出码是 2 也拦不住，只记一条冲突警告。
  3. 给正确用法：Hook 适合提醒、审计和可恢复的前置检查。要强制保证，规则放权限层（deny > ask > allow），系统边界放沙箱，这两层不走 fail-open。
  4. 帮他排查：15 个事件里只有 PreToolUse 的 is_blocking 为真；matcher 是正则加兼容别名，配置里写 Bash 能命中内部名 run_terminal_command。先确认 matcher 真的命中了。
⭐ 加分点反问一句「要是 Hook 故障就阻断所有工具，一个写坏的脚本能让全公司的 Agent 停摆，你选哪种故障模式」。把两边风险摆上台面，对方自然明白这是取舍。
用这些课程页组织答案 → Hooks：明确 deny 才阻断 从工具请求到受限执行
Q21面试官
「Persona 文件读不到，spawn 直接中止；role 的 prompt 文件读不到，却继续跑。为什么区别对待？」
🎯 对方在考察什么
超细节题，考你有没有读到失败语义的差异设计。背功能列表的人根本不知道这两条路径存在，能讲出设计理由的人才算真吃透了。
🧭 答题框架
  1. 给事实：请求了 Persona 之后，找不到、内容为空、读文件失败都会写入 persona_error，spawn 侧看到错误直接中止创建，失败关闭。
  2. 对照 role：role 的 prompt_file 读取失败只产生 role_prompt_warning，model、reasoning、capability、isolation 照常解析，软降级。
  3. 讲设计理由：Persona 是用户显式点名的行为合同，带 instructions 和输入输出契约，静默丢掉等于换了个人格干活，风险大；role prompt 是类型层的增强指令，缺了它子 Agent 还是那个类型。
  4. 补合并细节：Persona 的 inline instructions 会合并在文件内容之前，最终作为 persona 块进入 prompt。
⭐ 加分点抽象成可迁移的方法论：失败语义要跟着用户意图的强度走。显式指定的东西失败要响，默认兜底的东西失败可以柔。这一句能用在你自己的任何产品评审里。
用这些课程页组织答案 → AgentDefinition 与 Persona 合并
Q22面试官
「主会话下面挂十几个子 Agent 并行跑，你怎么管它们的生死和结果？」
🎯 对方在考察什么
考多 Agent 协调层的具体机制。「开多个就行了」是消费者视角，对方想听生命周期登记、结果等待和取消路径这套生产者视角。
🧭 答题框架
  1. 给组件：Grok Build 有真实的协调组件 SubagentCoordinator。start_subagent_coordinator 只启动一次 drain task，所有协调事件收口到一处。
  2. 给事件面：SubagentEvent 有 Spawn、Query、Cancel、ListActive、Completions、Outstanding。每个 Spawn 各自进 spawn_local 异步任务调 handle_subagent_request，协调器登记 pending、active、completed 三种状态。
  3. 结果与取消：Query 可以拿即时快照，也可以注册 block wait slot 等完成；Completions 会 drain 待通知完成项并按 suppress_ids 过滤；Cancel 支持按 subagent ID 或 parent prompt ID，过期的 completed 记录会被淘汰。
  4. 拔高到组织策略：并行能力来自异步任务。选单 Agent、主会话加 subagents 还是多成员共享任务，看任务图：并行收益、依赖关系、上下文复制成本、文件冲突和汇总责任。
⭐ 加分点提炼模式：「协调器是事件驱动的单一收口」。生死状态只有一个 owner，查询和取消都走消息，从根上避免多处改状态的竞态。
用这些课程页组织答案 → 多 Agent 的组织方式 子 Agent 四个隔离维度
Q23技术同事
「权限检查不就是看第一个命令吗？我 ls && rm -rf 一把梭，你那套拦得住？」
🎯 对方在考察什么
半开玩笑半挑衅，考命令解析的深度。知道逐段检查的人不多，能说出解析器和保守回退的人更少。答好了他以后不会再拿这类问题逗你。
🧭 答题框架
  1. 正面接招：拦得住。Grok Build 用 tree-sitter-bash 把可安全分解的脚本拆成一个个 plain command，识别 &&、||、分号和管道。每个非 setup 段都要独立通过安全命令、策略或授权检查，ls 放行救不了后面的 rm。
  2. wrapper 也算过：解析会递归剥离包装层拿到实际命令，危险前缀名单里有 rm、chmod、chown、kill 和 git push。
  3. 拆不动就保守：命令替换、复杂控制流这类没法可靠分解的脚本，整体进保守 prompt，用户对完整脚本确认一次。
  4. 补后手：就算批准执行，沙箱的能力集合还在。read-only profile 下 workspace 不可写，rm 到了操作系统那层也写不动。
⭐ 加分点点出这套设计最容易被低估的地方：按脚本结构做权限决策。用正则匹配命令字符串的方案在 shell 语法面前全是洞，语法树解析才是正解。
用这些课程页组织答案 → 从工具请求到受限执行 五种沙箱 Profile
Q24面试官
「用户批准了一次 rm，这个会话之后是不是就能随便删文件了？把你们的授权模型完整讲一遍。」
🎯 对方在考察什么
考授权链全貌和两层边界。只答「弹窗确认」的人对安全的理解停在 UI 层，对方想听决策输入、规则优先级和沙箱兜底怎么叠起来。
🧭 答题框架
  1. 先答问题本身：批准只放行本次请求。授权决策的输入是 AccessKind，工具输入被解析成 Read、Edit、Bash、MCPTool 这类带具体路径和命令的访问意图，比 ToolKind 更细。
  2. 走一遍链路：plan gate 先拦编辑，PreToolUse hook 可以显式 deny，然后 permission manager 评估合并后的规则。规则优先级是 deny > ask > allow，和配置来源顺序无关。
  3. 决策快速路径有序：管理策略的 deny 最先短路，随后才轮到 yolo pin、session grants、Auto 判定、sandbox Bash auto、只读安全项，都没结论才弹窗问用户。
  4. 补第二层：权限层的 Allow 不扩大操作系统能力。沙箱 active 时，进程仍被能力集合和子进程网络策略框着。权限层决定「能否尝试」，沙箱层限制「能做到什么」，叠加才是完整边界。
⭐ 加分点主动纠正一个流传很广的说法：「沙箱内所有写操作自动批准」是错的。sandbox fast path 只检查 Bash，还受 policy_forced_prompt 和 auto_forced_prompt 约束。
用这些课程页组织答案 → 从工具请求到受限执行 ToolKind 与只读语义 五种沙箱 Profile
Q25面试官
「安全团队要全公司统一沙箱策略，项目组又想自己加规则。配置系统怎么设计才不打架？」
🎯 对方在考察什么
考配置分层治理：谁能改什么、冲突听谁的、怎么防止项目组悄悄放宽安全底线。这是企业产品绕不开的设计题。
🧭 答题框架
  1. 给合并规则：Grok Build 先读全局 ~/.grok/sandbox.toml，再读项目 .grok/sandbox.toml，合并用 entry.or_insert。项目只能新增 profile 名称，声明了和全局同名的 profile，全局定义保持生效，项目改不动。
  2. 给扩展方式：项目自定义走 custom profile，默认从 workspace 起步，extends 只能选 workspace、devbox、read-only、strict 四个内置基类，read_only、read_write、deny 往基类上追加。
  3. 给两条禁令：不能 extends off 和 none，也不能 extends 另一个 custom。禁掉链式继承，安全审计才能沿一条线看清最终能力。
  4. 提醒默认值：custom 要限制子进程网络得显式写 restrict_network 为 true，别指望从基类想当然地继承。
⭐ 加分点点出 entry.or_insert 一行代码就是治理模型：先加载的赢。把「全局优先」做成合并语义，比做成审批制度可靠得多，这是用机制代替流程的范例。
用这些课程页组织答案 → 五种沙箱 Profile
Q26老板
「团队想从插件市场装一堆社区插件提效。万一里面藏了个恶意的，把咱们代码偷跑了怎么办？」
🎯 对方在考察什么
考插件生态的信任设计。只会说「装之前审核一下」的人扛不住追问，老板想听系统层面有几道闸，以及闸门失效时会发生什么。
🧭 答题框架
  1. 给三道门：装了不等于能跑。第一道是来源与路径，MarketplaceRelativePath 拒绝绝对路径和父目录穿越，远程条目能用 git ref 或 SHA 锁定内容；第二道是启用状态，项目和用户范围发现的插件默认进 disabled 列表；第三道是执行信任，按插件根目录逐个授权，记录写进 ~/.grok/trusted-plugins。
  2. 讲未信任的待遇：skills 和 agents 只能露元数据，hooks 不加载、MCP server 不启动、scripts 不执行。最危险的可执行面全被按住。
  3. 给失败语义：插件根目录 canonicalize 失败直接按未信任处理，失败关闭，路径出问题也不会误放行。
  4. 落到流程：高危插件先在 read-only 沙箱里审阅内容再授信，远程安装用 SHA 固定版本，防止上游偷偷换包。
⭐ 加分点给老板一句能记住的总结：发现、安装、执行是三层，每层有独立门槛。恶意插件要连闯三关，而且第三关默认是关着的。
用这些课程页组织答案 → Plugin Marketplace 与信任 五种沙箱 Profile
Q27面试官
「用户接了几百个 MCP 工具，全塞进提示词，上下文直接炸了。你怎么设计？」
🎯 对方在考察什么
考工具规模化的方案。答「做个开关让用户少开点」是在甩锅给用户，对方想听延迟发现这套系统解法。
🧭 答题框架
  1. 给核心思路：工具元数据进 ToolMetadataSnapshot（tools、servers、mcp_initialized 三个字段），配 BM25 索引，不让几百个定义常驻提示词。
  2. 给两个稳定入口：模型侧只暴露 SearchTool 和 UseTool。SearchTool 按关键词搜，参数是 query 加 limit（默认 5），结果按 server 分组，带描述和 input_schema；UseTool 收 tool_name 和 tool_input，按发现到的 schema 分发执行。
  3. 讲稳定性收益：模型的工具列表跨轮次不变，几百个工具的增删不冲刷上下文，提示词缓存也友好。
  4. 补分发细节：UseTool 收到合格工具名后走 InnerDispatch 或 managed gateway 调用 MCP。模型的用法是先搜到 input_schema，照着 schema 构造 tool_input 再调用，发现和执行彻底分开。
⭐ 加分点提 mcp_initialized 这个小字段：能力发现还没完成时，搜索层知道「搜不到」和「还没准备好」是两回事，不会给模型一个错误的空结果。细节到这一层，没人再怀疑你。
用这些课程页组织答案 → 实现族与动态 MCP MCP 连接、发现与恢复
Q28老板
「既然 xAI 把源码开出来了，咱们 fork 一份改成内部版，省得从头写。行不行？」
🎯 对方在考察什么
考开源治理边界的判断。只看 license 不看发布模式的人会把公司带进坑，老板要的是「可以做什么、代价是什么」的完整账。
🧭 答题框架
  1. 先给可以的部分：Apache 2.0 许可，阅读、构建、内部改造都有空间，README 也给了源码构建入口。
  2. 给三个边界：仓库定期从 xAI 内部 monorepo 单向同步，公开树可能落后于内部主干；CONTRIBUTING 明确不收外部 PR，我们改的东西合不回上游；根 Cargo.toml 是生成的只读文件，直接改会被下次同步覆盖，要改就改各 crate 自己的清单。
  3. 给平台账：受支持的构建主机是 macOS 和 Linux，Windows 属于 best-effort 且当前未从这个源码树测试过。公司要是 Windows 开发机为主，成本得重估。
  4. 给结论：fork 可行，但要按「长期维护一个分叉」计价，每次上游同步都是一笔合并成本。这和白捡一个产品是两码事。
⭐ 加分点补一句本地快照没有 .git 元数据，连「我们拿到的是哪个 commit」都无法核对。技术尽调里如实写「无法确认」，这个严谨度老板会记很久。
用这些课程页组织答案 → 工程复盘与证据边界 证据化对照
Q29面试官
「换你当面试官，别人交上来一份 Coding Agent 设计方案，你怎么评分？」
🎯 对方在考察什么
反向考察。你的评审标准暴露你自己的知识结构：看重什么、忽略什么、有没有体系。只会挑功能毛病的人，评分体系撑不过三个追问。
🧭 答题框架
  1. 给量表：用结课评审的 100 分权重：边界与 ADR 20 分、合约与状态机 20 分、安全与恢复 25 分、测试与可观测 20 分、演示与证据 15 分。安全与恢复权重最高。
  2. 给否决项：四条一票否决：敏感数据落点没说明、高风险工具缺权限路径、声称崩溃可恢复但没有测试、引用源码给不出文件路径。分再高踩了也不过。
  3. 给检查方法：拿九维决策卡过一遍：入口、状态并发、模型流、工具合约、上下文记忆、安全、恢复、可观测、扩展。每个维度要有明确决定、合约、故障路径和验证方式。
  4. 说明权重理由：功能是平时能看见的，安全与恢复是出事才看见的。评审就该把权重压在「出事才看见」的地方。
⭐ 加分点引用一条评审哲学收尾：每项设计决定要能回到一个真实的失败分支。说不出失败默认值（停止、降级还是问用户）的设计，都还停在 PPT 阶段。
用这些课程页组织答案 → Coding Agent 设计工作台
Q30老板
「你花这么多时间啃一个别家的源码，说说看，最值钱的收获是什么？给我一句话。」
🎯 对方在考察什么
考提炼能力。从两万行细节里拿得出可复用的产品判断，这段投入才算有回报。罗列技术名词等于承认自己白学了。
🧭 答题框架
  1. 先给一句话：生产级 Agent 和 demo 的差距不在模型调用，在失败语义。这套源码每一层都明确回答了「这里坏了怎么办」。
  2. 展开三个例子：Hook 故障 fail-open 保工具可用性，Persona 缺失失败关闭保用户意图，插件路径解析失败按未信任处理保安全。三种失败三种答案，全按风险选的，没有一刀切。
  3. 第二个收获：策略全部做成显式配置对象。CompactionPolicy 五个字段带默认值，沙箱是可解析的 Profile，阈值、预算、压缩模型都可调。demo 把策略写死在代码里，产品把策略交给配置。
  4. 落到自己的工作：以后评审任何 Agent 功能，我加两个必答题：这个功能的失败默认值是什么？这条策略改起来要不要发版？
⭐ 加分点用具体数字收尾：85% 压缩阈值、300 秒压缩预算、1 秒 4 秒 16 秒的重连退避，这些数值全在配置和常量里躺着，随时可查可调。魔法数字可审计，本身就是工程成熟度的标志。
用这些课程页组织答案 → Coding Agent 设计工作台 Compaction 85% 阈值 Hooks：明确 deny 才阻断 Plugin Marketplace 与信任
最后一个建议
这 30 题的正确用法是开口讲一遍，对着同事、朋友或者录音讲。这一章的问题最容易检验真假：细节说得出来就是真懂，说不出来就是在背结论。讲不顺的地方，点关联课程页回去补上。

「Grok Build 专题 · 30 道灵魂拷问」为什么能找到相关内容

「每题附考察意图、答题框架与加分点：运行时循环 / Compaction / 工具权限 / 记忆检索 / 沙箱安全 / MCP 集成」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。

相似度不是答案，召回之后还要核对

在「每题附考察意图、答题框架与加分点：运行时循环 / Compaction / 工具权限 / 记忆检索 / 沙箱安全 / MCP 集成」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。

  • 从入口讲起： 用 Grok Build 举例，真实入口在 main()，按运行分支分发（headless、stdio、leader、交互 TUI），最后都汇到同一个 Agent 宿主
  • 三个 Actor 分工： SessionActor 负责 turn 编排，接收命令、启动待处理 turn、处理完成通知；ChatStateActor 独占对话状态；SamplerActor 负责流式的模型请求
  • 隔离单位： 每个 Session 跑在独立 OS 线程上，带自己的 current-thread Tokio runtime 和 LocalSet。会话之间天然隔离，一个卡死拖不垮别人

先区分找得到和找得准

把「每题附考察意图、答题框架与加分点：运行时循环 / Compaction / 工具权限 / 记忆检索 / 沙箱安全 / MCP 集成」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。

从这个例子继续往下看

这篇内容先从「从入口讲起： 用 Grok Build 举例，真实入口在 main()，按运行分支分发（headless、stdio、leader、交互 TUI），最后都汇到同一个 Agent 宿主」展开，再把问题推进到「三个 Actor 分工： SessionActor 负责 turn 编排，接收命令、启动待处理 turn、处理完成通知；ChatStateActor 独占对话状态；SamplerActor 负责流式的模型请求」。把这两个片段放在一起看，可以更清楚地分辨：哪些是文章给出的事实，哪些是需要结合条件才能成立的判断。

把这条判断带到下一个场景

检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。

  • 「Grok Build 专题 · 30 道灵魂拷问」：从入口讲起： 用 Grok Build 举例，真实入口在 main()，按运行分支分发（headless、stdio、leader、交互 TUI），最后都汇到同一个 Agent 宿主
  • 「继续往下看」：三个 Actor 分工： SessionActor 负责 turn 编排，接收命令、启动待处理 turn、处理完成通知；ChatStateActor 独占对话状态；SamplerActor 负责流式的模型请求
  • 「最后的要点」：先给触发机制： 以 Grok Build 为例，默认在上下文使用率达到 85% 时允许自动压缩。判断公式是 used × 100 >= context_window × threshold_percent，纯整数比较

最后的「最后的要点」把讨论落到「先给触发机制： 以 Grok Build 为例，默认在上下文使用率达到 85% 时允许自动压缩。判断公式是 used × 100 >= context_window × threshold_percent，纯整数比较」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。

标记为已学完 阅读进度会自动记录
← 上一篇下一篇 →

继续阅读

同一条线上的下一篇。

超越源码 · 收官Coding Agent 设计工作台围绕九个系统维度输出架构决定、故障路径、验证方式和结课成果超越源码 · 收官Grok Build 工程复盘与证据边界用类型、状态机、测试和仓库政策复盘工程优点与适用限制超越源码 · 汇总Grok Build 与 Claude Code 证据化对照按源码、仓库文档和公开产品行为完成多维比较，保留未知项MCP 与生态 · 架构Plugin Marketplace 的发现与信任区分目录、安装、运行时发现、启用状态与插件根信任

文章讨论

读到这里，留下一个判断。

把刚想明白的地方、还没想通的问题，留给下一位一起学习的人。

↗
正在讨论 Grok Build 专题 · 30 道灵魂拷问 拆开一只生产级 Coding Agent
3条讨论文章讨论 · 与共学社区同步
在共学社区查看
AM
Asha Morgan内容编辑
观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。

文章讨论7 有帮助
LH
Lin Harper独立开发者
观点观点

读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助
KM
Kiki Moore产品运营
问题问题

如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。

文章讨论4 有帮助