从真实 main() 到第一轮采样
追踪入口、会话创建、提示词渲染、模型采样与流式返回的完整调用链
本页解决的问题
先给结论「从真实 main() 到第一轮采样」要解决的关键问题是什么？
追踪入口、会话创建、提示词渲染、模型采样与流式返回的完整调用链
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
能准确说出四种运行分支，并沿
connect_or_spawn、MvpAgent、spawn_session_on_thread、SessionActor、SamplerActor 定位第一轮对话。run_headlessAgent 无头模式
grok agent headless 进入 Shell 提供的无头宿主。
run_stdio_agentStdio Agent
通过 ACP stdio 收发请求，适合外部客户端驱动。
run_leaderLeader 进程
承载长生命周期 Agent，并通过连接通道服务客户端。
app::run交互 TUI
默认交互分支进入 pager 应用，TUI 可经 leader 建立连接。
run_headless, run_leader, run_stdio_agent
};
let runtime = tokio::runtime::Builder
::new_multi_thread()
.enable_all()
.build()?;
/// with its own tokio runtime and `LocalSet`.
pub(crate) async fn spawn_session_on_thread(...) {
let rt = tokio::runtime::Builder
::new_current_thread()
.enable_all().build()?;
let local = tokio::task::LocalSet::new();
}
.git 元数据，因此不声称对应某个 commit 版本。画出一次交互请求的边界
标注哪些节点属于 xai-grok-pager-bin、xai-grok-pager、xai-grok-shell、xai-grok-sampler。说明 TUI 和 Agent 宿主为何是两个 crate。
xai-grok-pager-bin/src/main.rs。它负责分发模式，随后由 pager 承担界面、Shell 承担 Agent 与 Session 宿主、Sampler 承担模型请求。「核心视觉 · 教学化调用图」怎样变成可执行的指令
「grok agent headless 进入 Shell 提供的无头宿主」强调的不是某句神奇咒语，而是信息是否足够让模型判断“为谁做、要完成什么、什么结果算合格”。
背景决定方向，限制决定边界
从「默认交互分支进入 pager 应用，TUI 可经 leader 建立连接」可以看出，一个有效请求至少要把任务、受众、输入材料、输出形式和限制条件分开。少了背景，模型只能猜；少了验收标准，即使文字流畅也无法判断是否完成任务。
继续加字不一定继续变好
把「标注哪些节点属于 xai-grok-pager-bin 、 xai-grok-pager 、 xai-grok-shell 、 xai-grok-sampler 。说明 TUI 和 Agent 宿主为何是两个 crate」变成一个小练习：只改背景、要求、限制中的一项，保留其他内容不动，观察哪一层真正改变了结果。
从「核心视觉 · 教学化调用图」走到「Agent 无头模式」
「核心视觉 · 教学化调用图」先把问题落在「main() PagerArgs run_headless agent headless run_stdio_agent ACP stdio run_leader leader 宿主 xai_grok_pager::app::run 交互 TUI connect_or_spawn 连接或启动 leader ACP channels MvpAgent 会话宿主 SessionActor turn loop ChatSt…」上；到了「Agent 无头模式」，讨论继续推进到「grok agent headless 进入 Shell 提供的无头宿主」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
写请求时也应逐层补齐：先说任务和受众，再给材料和输出要求，最后加上限制与验收方式；一次只改变一层，才能知道哪项信息起了作用。
- 「核心视觉 · 教学化调用图」：main() PagerArgs run_headless agent headless run_stdio_agent ACP stdio run_leader leader 宿主 xai_grok_pager::app::run 交互 TUI connect_or_spawn 连接或启动 leader ACP channels MvpAgent 会话宿主 SessionActor turn loop ChatSt…
- 「Agent 无头模式」：grok agent headless 进入 Shell 提供的无头宿主
- 「画出一次交互请求的边界」：标注哪些节点属于 xai-grok-pager-bin 、 xai-grok-pager 、 xai-grok-shell 、 xai-grok-sampler 。说明 TUI 和 Agent 宿主为何是两个 crate
最后的「画出一次交互请求的边界」把讨论落到「标注哪些节点属于 xai-grok-pager-bin 、 xai-grok-pager 、 xai-grok-shell 、 xai-grok-sampler 。说明 TUI 和 Agent 宿主为何是两个 crate」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。