Origin of Ray

从 go-tiny-claw 当前源码出发，设计终端可用、渠道可替换的工具审批协议，并完成先审批后并发执行。

逐层分析 go-tiny-claw 如何监听 os.Interrupt，并通过 Context 取消模型流、工具进程和审批等待。

基于 go-tiny-claw 当前源码，实现连续 Terminal 的 REPL、流式事件协议、ToolCall 聚合和实时输出。

以 go-tiny-claw 提交 47452b38c047ba8e614369a099a04c2bbad90c83 为起点，规划连续对话、流式输出、中断、审批及生产级 Agent Harness 的完整建设路线。

接续上下文预处理：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）架构。