如果你的 Agent 只有一条命（一个 Main Loop 线程），它可能最终会陷入“崩溃”。哪怕我们有 Compactor 机制，大模型依然需要在一轮轮的 ReAct 循环中，使用 read_file 翻阅成百上千个文件，使用 bash 调用 grep 搜索关键词。
在这个漫长的“探索”阶段，主线程的上下文会被海量的尝试、报错、无关的代码片段塞满。最终，当它终于找到关键代码，准备开始“写代码”时，它可能早就忘记了你最初要求它“翻译成 Go 语言”的那个小细节了。
在 Harness 驾驭工程中，突破单体大模型能力天花板的解法，就是向现代企业管理学习：任务委派（Delegation）与多智能体（Multi-Agent / Subagent）架构。
从入口到 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 的调用请求。
上一篇博客我们介绍了Harness推崇的极简工具集的原则，现在就让我们简单实现一下4个Agent系统的原子能力
之前的博客我们已经通过ReAct的架构为Agent赋予了一个大脑，但是只有大脑是不够的，也就是说现在的Agent只能做token的预测，但是还需要一些感官，能够将现实世界中与完成任务有关的各种信息整理成token，以及能够将token重新变成能够影现实世界的操作，这些操作就是我们这篇博客的重点——tool
记录一次 App Store 更新后用户被强制登出的问题排查过程，涉及 Auth0 配置、iOS Keychain 持久化、Token 刷新机制以及并发 401 去重方案。
所有顶级的 Agent 引擎（无论是早期的 AutoGPT，还是如今最先进的 Claude Code、OpenClaw），它们表面上看起来像魔法一样能在你的本地项目里来回穿梭、修改代码、执行测试。但在代码的最底层，
它们都在跑着一个极其朴素、但极其强健的无限循环。这个循环，在学术界通常被称为 ReAct (Reason + Act) 范式，而在工程界，我们通常称之为 Agent Loop 或 Main Loop。
系列开篇：界定 Agent Harness 的目标与边界，给出整体架构与后续文章路线图。