从入口到 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 的目标与边界，给出整体架构与后续文章路线图。

ECS架构：AI Game Agent最好的Harness工程范式

引言

2026年，AI Game Agent正在彻底改变游戏开发。

从智能NPC到程序化内容生成，从动态难度调整到真实玩家模拟——AI正在让游戏世界变得前所未有的鲜活。但真正让游戏AI跑起来的，不是模型本身的智能，而是Harness Engineering——那个包裹在模型周围、让AI能在游戏环境中执行任务的执行骨架。

而在众多Harness架构设计中，**ECS（Entity-Component-System）**是游戏领域最成熟、最强大的选择。本文深入解析为什么ECS是AI Game Agent Harness最好的工程范式。

深入解析 Mem0 v1.0.11 记忆系统的完整架构，包括核心数据结构、增删查改流程、图存储集成及设计优势。