Origin of Ray

接续上下文预处理：API 报错后的 reactive compact 全链路——withhold、collapse drain、tryReactiveCompact、媒体恢复，以及 staged queue / commit 语义（非 Git）。

在过去的几个模块中，我们如同打造一辆超级跑车般，为 go-tiny-claw 组装了强大的 V8 引擎（Main Loop）、防抱死刹车（Safety Middleware）、甚至是能自动寻路的“副驾驶”（Subagent）。但是，如果这辆跑车没有“仪表盘（Dashboard）”，你敢把它开上真实的赛道吗？

想象一下，你把 go-tiny-claw 部署到了公司的生产环境中，团队的 10 个开发人员每天都在飞书里唤醒它去做代码 Review 和 Bug 排查。月底结算时，老板拿着一张高达几万元的 API 账单质问你：为什么这个月的大模型费用这么高？到底是哪一个任务、调了哪个工具消耗了最多的 Token？Agent 每次回复都要等 30 秒，到底是网络慢、还是它在本地执行 go test 慢、还是大模型推理慢？

如果你无法回答这些问题，你的 Agent 依然只能是一个“玩具”，老板不会批准你将其投入到日常生产，也无法成为企业级的数字资产。

我们将通过极简的代码，在 Harness 层（而非业务层）拦截大模型的返回包，精确记录 Token 消耗、金钱成本和执行耗时。

深入 queryLoop Phase 1 上下文预处理：boundary 切片、tool result budget、snip、microcompact、context collapse、autocompact，以及 preview 生成与 cache editing 机制。

queryLoop 各 phase 详解，以及 Tool 执行、checkPermissionsAndCallTool、并发策略、流式拼接、canUseTool 权限链与 normalizeMessagesForAPI。

梳理 Claude Code 五层 Memory 的存储、读写注入路径、与 Message/UI/API 的关系，以及 session memory、relevant recall 等机制。

如果你的 Agent 只有一条命（一个 Main Loop 线程），它可能最终会陷入“崩溃”。哪怕我们有 Compactor 机制，大模型依然需要在一轮轮的 ReAct 循环中，使用 read_file 翻阅成百上千个文件，使用 bash 调用 grep 搜索关键词。

在这个漫长的“探索”阶段，主线程的上下文会被海量的尝试、报错、无关的代码片段塞满。最终，当它终于找到关键代码，准备开始“写代码”时，它可能早就忘记了你最初要求它“翻译成 Go 语言”的那个小细节了。

在 Harness 驾驭工程中，突破单体大模型能力天花板的解法，就是向现代企业管理学习：任务委派（Delegation）与多智能体（Multi-Agent / Subagent）架构。

在前面的模块中，我们已经为为Agent赋予了一定的稳定性和自驱力：它有了一颗带“慢思考”的心脏（Main Loop），能操作底层操作系统的手脚（极简工具集），还能在 Plan 模式下利用文件系统（PLAN.md / TODO.md）进行超长记忆和规划。甚至学会了在遇到底层报错时通过系统注入的模板协助 Agent 进行“错误自愈（Error Recovery）”。

从入口到 query 主循环，梳理 Claude Code 的仓库结构、Message 类型系统、REPL 交互链路与 getToolUseContext 上下文工厂。

从本系列的博客一开始，我们就讲过，LLM就是新的OS的CPU，传统CPU的输入和输出是电信号，进行的运算是布尔运算，那么LLM的输入和输出是token，进行的运算是token预测。

为什么传统软件比Agent的输出给人的感觉更可靠，除了布尔运算可靠以外，布尔运算的输入也是绝对按照程序员的意志来的，是从高级的逻辑语言一步步严格逻辑等价的转换成电信号这种低级的逻辑语言的，故而每次布尔运算的输入无论是信息的相关性和准确性都是完全按照人的意志来的，如果有问题，一定是人出错了，debug就行了。

而如果要Agent也给人这种可靠感，作为软件开发者，正如我们没办法改动CPU的布尔运算逻辑一样，我们也没办法改动LLM的token生成逻辑，我们能做的就是提高LLM输入的相关性和准确性。整个Agent Harness核心宗旨也是这个：为当前的任务目标提供相关且准确的输入，这个就是上下文工程。

在真实的工业级开发场景中，效率同样是极其重要的指标。

试想这样一个场景：你对 Agent 说：“请帮我分析一下 handler.go、model.go、router.go 和 config.yaml 这四个文件，找出它们在鉴权逻辑上的关联。”

由于我们底层接驳的前沿大模型（如 Claude 4.x Sonnet 和 GLM-5.x）都原生支持 Parallel Tool Calling（并行工具调用） 功能，模型在经过思考后，非常聪明地在一次 API 返回中，同时吐出了 4 个 read_file 的调用请求。