Clippings on elonnzhang

ChatGPT 如何优化智能体循环：Harness、API 与推理

Wed, 29 Jul 2026 00:00:00 +0800

AI 实验室正以前所未有的速度推进技术，并发布迄今能力最强的模型。就在最近，Anthropic 发布了 Fable 5，随后 OpenAI 推出了 GPT-5.6 系列，其中包括其当前能力最强的 GPT-5.6 Sol；Kimi 发布了 Kimi K3，而 Opus 5 也在几天前问世。

但能力只体现了问题的一半。另一半是这些模型完成任务需要多少成本，也就是每个成功任务的成本。成本越低，用户越能负担得起，服务商的支出也越少。各家实验室投入了大量精力，优化 AI 应用的每一个组件和层级，以提高效率、降低总成本。例如，在人工分析编码智能体指数（Artificial Analysis Coding Agent Index）中，启用最高推理强度的 GPT-5.6 Sol 得分高于 Fable 5，成本却不到后者的一半。

为了了解前沿实验室采用哪些方法提升 AI 应用的效率，我们采访了 OpenAI 的工程师。他们曾为 Codex 和 ChatGPT Work 背后的系统开发并上线多种效率优化技术。感谢 Joe、Ahmed、Steve、Matthew 和 Philippe 与我们分享这些宝贵的技术细节。

本文将介绍：

向 AI 智能体发出请求后，系统内部究竟会发生什么
Harness 层如何通过持久 WebSocket、稳定的提示词前缀、延迟工具发现和 Code Mode 减少重复工作
API 层如何只对增量内容进行分词，并让安全检查与推理并行执行
推理层如何借助缓存感知路由、KV 缓存管理、推测解码，以及分离预填充与解码，更充分地利用 GPU
OpenAI 从这些实践中总结了哪些经验，以及你可以把哪些经验用在自己的系统中

效率优化技术概览

智能体式 AI 应用的结构

当你让 Codex 或 ChatGPT Work 执行一项任务，比如修复一个 bug 时，请求并不会直接发送给大语言模型（LLM）。实际过程要复杂得多。Codex 这类 AI 应用不只包含 LLM，而是由许多组件组成的完整系统。用户查询需要经过多个层级，LLM 才会看到第一个 token。

The new rules of context engineering for Claude 5 models

Sat, 25 Jul 2026 00:00:00 +0800

I’ve written previously about how to best prompt the newest generation of Claude 5 models and work with them iteratively to discover what you want to build.

But when you send a message to Claude, the prompt is only a small part of the context it gets. Much of your context is assembled from your system prompt, Skills, CLAUDE.md files, memory, and other sources. We call this context engineering, and it makes a big impact on the results you generate when using Claude Code or in building your own agents.

How we teach AI models

Fri, 24 Jul 2026 00:00:00 +0800

How do AI models learn new skills and behaviors?

The process is surprisingly human and easy to understand, even if you don’t have a machine learning background.

Helpful colleagues

AI models, increasingly used through agents, are similar to a helpful colleague. What traits do the best people you’ve worked with share?

Maybe you thought of coworkers who were great communicators, or who had the judgment to know when to ask for help versus when to figure it out themselves. There are also more human qualities, like being personable, empathetic, and kind. But I particularly enjoy working with people who can take ambiguous problems and find ways to solve them.

腾讯WorkBuddy实践：如何把Agent做成可用产品

Fri, 24 Jul 2026 00:00:00 +0800

Anne 腾讯技术工程 2026年7月24日 17:36

我们总以为，把 Agent 做好，关键在于换一个更强的模型，或者把提示词写得更长、更细。

但真正进入一线场景后会发现，模型能力只是起点。Agent 能否稳定完成任务，还取决于它如何被引导，上下文如何被组织，工具和权限如何接入，结果如何被验证，以及 Harness 如何把一次次不确定的模型输出，转化为更稳定、可控的执行过程。

这篇文章邀请 WorkBuddy 团队策略产品经理 Anne，从产品视角拆解 Agent 的运行机制。她负责 WorkBuddy 研发与办公场景 AI Agent 的上下文策略设计与落地，是腾讯内部「上下文工程」方向最贴近一线的实践者之一。文章不堆叠概念，而是沿着“模型—上下文—Harness—Loop”的链路，讲清楚 WorkBuddy 如何把 Agent 从模型能力推进到可用产品能力。

从模型到Harness：

WorkBuddy如何把Agent做成可用产品

作者：Anne WorkBuddy策略产品经理

一个常见判断是“模型够强，剩下交给提示词”。但把 Agent 做成能在生产环境稳定完成任务的产品后，会发现模型只承担其中一部分： 工具接入、上下文组织、权限边界、结果验证、反馈纠正和跨会话延续 ，都会直接影响产品是否可靠。

这篇文章分成两部分。前半部分面向还没有 Agent 基础的同学，先讲清大语言模型（LLM）、工具调用（Function call）、系统提示词（System Prompt）、模型上下文协议（MCP）、技能（Skill）和插件（Plugin）这些基础概念，说明模型为什么需要产品侧提供工具、上下文和执行环境。

后半部分回到 WorkBuddy 的产品实现，重点讨论 Context Engineering 和 Harness Engineering：WorkBuddy 如何选择和组织上下文，如何通过前馈、反馈、权限、验证、编排和可观测性，让 Agent 不只是能执行任务，而是能更稳定、更可控地完成任务。最后再简要讨论 Loop Engineering，说明这套机制如何进入长期任务循环。

阅读时可以带两个视角：作为 构建者 ，看这些工程如何提高 Agent 执行任务的可靠性；作为 使用者 ，看如何更有效地使用 AI Agent 产品。

一、先把模型看成一个无状态的函数

对产品侧而言，不需要展开 Transformer 的底层原理，只需要一个抽象： 模型是一个根据输入产生后续文字的函数。

Agent 中的提示词缓存

Wed, 22 Jul 2026 00:00:00 +0800

日期：

发件人：Earendil Engineering < rfc@earendil.com >

收件人：你

主题：

我们经常把大语言模型看作函数：输入一段文本，得到一段文本。这个抽象很有用，却忽略了运行编码 Agent 时一个极其重要的事实：每次请求的大部分输入都和上一次相同。换句话说，我们通常只是在已有输入末尾追加内容。

编码 Agent 会把系统提示词、工具定义、项目指令、对话历史、工具调用和工具结果一起发送给模型。下一轮请求又会发送几乎相同的内容，只多出少量新信息。当一次会话增长到数万甚至数十万 token 时，每轮都重新计算整段提示词既慢又贵。

提示词缓存（prompt caching）让这种调用方式在经济上勉强可行，但它也十分脆弱。工具定义发生变化、切换模型，或者服务商改变请求路由，都可能让原本廉价的增量请求变成对整个上下文的完整重放。

因此，对编码 Agent 来说，缓存行为不只是实现细节或性能优化。它会影响延迟、成本、工具设计、会话设计，甚至决定产品应该提供哪些功能。

KV 缓存中保存了什么

Transformer 处理提示词大致分为两个阶段。在**预填充（prefill）阶段，模型读取输入 token，并计算对应的注意力状态。在解码（decode）**阶段，模型每次生成一个新 token。

在每一层注意力中，每个处理过的 token 都会产生一个键（key）和一个值（value）。它们与哈希表中的键值查找并不相同：键和值都是数值数组，通常由浮点数或低精度量化值组成。模型处理新 token 时，会把这个 token 的**查询（query）与之前的键（key）进行比较，从而判断每个早期 token 与当前 token 的相关程度。随后，模型根据相关性分数，对相应的值（value）**做加权组合。从这个角度看，key 是模型用来匹配的对象，value 是模型取回的信息。但这种查找是模糊匹配，不像字典那样“返回唯一且完全匹配的结果”。

系统会保留这些 key 和 value。生成下一个 token 时，模型便能关注前面所有内容，无须重新计算早期 token。保存下来的状态就是 KV 缓存（KV cache）。

从概念上看，一组请求如下：

请求 1：

[system][tools][user][assistant][tool result][user]
<--------------------- prefill -------------------->
 |
 每个 token、每一层对应的 K 和 V 张量

请求 2：

[system][tools][user][assistant][tool result][user][new]
<------------------ 可复用前缀 -------------------><--->
 |
 新计算

实际的数据表示更复杂，具体形式取决于模型，而且体积“相当”大。这里最重要的特性是：这些状态对应一个确定的 token 前缀。两段含义相同但分词结果不同的提示词不能共享 KV 缓存。如果中间某个 token 发生变化，从该 token 之后的所有内容都会成为另一段续写。

Prompt Caching In Agents

Wed, 22 Jul 2026 00:00:00 +0800

Date:

From:Earendil Engineering < rfc@earendil.com >

To:You

Subject:

Large language models are often thought of like functions: send in some text, receive some text. That is a useful abstraction, but it ignores one of the most important parts of running a coding agent: most of the input is the same as last time. In other words we mostly append to it.

A coding agent sends the model its system prompt, tool definitions, project instructions, conversation history, tool calls, and tool results. On the next turn it sends almost all of that again, plus a small amount of new material. Once a session has grown to tens or hundreds of thousands of tokens, recomputing the whole prompt for every turn is slow and expensive.

The State of Agent Wikis

Tue, 21 Jul 2026 00:00:00 +0800

In April 2026, Andrej Karpathy wrote a GitHub Gist. He describes a method in it. He calls the method the LLM Wiki.

Four teams built the same thing after that. Cognition built DeepWiki. Factory built AutoWiki. LangChain released OpenWiki. Garry Tan released GBrain.

The method is the same in all four systems. An LLM reads your source documents one time. It writes the information into markdown pages. It keeps the pages correct when the sources change. The agent reads these pages. The agent does not read the source documents again for each question.

驾驭AI Coding：一份面向团队的Harness Engineering落地规范

Fri, 17 Jul 2026 00:00:00 +0800

腾讯程序员腾讯技术工程 2026年7月17日 17:36 作者：atreusliu

交付代码的成本已经接近免费了，但交付好代码的成本依然很高。Harness Engineering 做的事情，就是把"好代码"的标准写进系统里，让 AI 在约束下自己干活。

为什么每位成员都必须遵循这套规范？

AI Coding 工具正在重塑软件开发的方式。当团队中每个人都能用 AI 快速生成代码时，真正拉开差距的不再是"谁写得快"，而是"谁写得好、谁写得稳、谁写得可维护"。

这套规范不是束缚，而是团队的共同语言和质量底线：

对个人 ：它帮你建立正确的 AI 协作习惯，避免踩坑返工，让 AI 真正成为你的生产力倍增器
对团队 ：它确保每个人产出的代码风格一致、架构统一、可审查可维护，降低协作摩擦
对项目 ：它把质量标准固化到工具链中，让项目不会因为人员变动而失控

本文档的定位 ：

第一部分（一、二章）回答"为什么"和"是什么"：阐述 Harness Engineering 的核心理念和 AI Coding 一体化架构设计
第二部分（三~九章）回答"怎么做"：提供分阶段实施路线图、具体配置步骤、日常开发 SOP、反模式总结，以及基于我们构造的 harness-audit Skill 的自动化合规性自检
第三部分（十章）总结

关于阅读重点的一点说明 ：

MCP、Skills、Rules、SDD、知识库这些概念，网上和司内已经有大量入门文章讲过"它们是什么"，本文不再花篇幅重复这些老生常谈的定义。本文真正想讲清楚的，是另外两件事：

第一，它们在 Harness 体系中的功能定位 。同样是 MCP 和 Skills，单独看每一个工具都不难理解，但放进 Harness 的 6 大支柱里，各自承担什么角色、解决什么层面的问题、在 AI 工作流的哪个环节发挥作用，这才是决定团队能不能用好它们的关键。
第二，它们在实际开发场景中如何相互配合 。MCP 提供数据通道、Skills 封装领域经验、知识库注入业务上下文、Rules 划定行为边界——这几样工具不是孤立存在的，真正的威力在于组合使用。本文会结合具体场景（需求开发、Bug 修复、Code Review 等）讲清楚它们怎么协同工作。

其实我们日常开发中，已经或多或少在用 Harness 的思路了，只是缺一个系统化的框架把这些工具的使用方式和用法统一起来;

如果想捋清这些工具背后的设计逻辑，知道在自己的项目里该用哪一个、怎么搭配用、什么时候不该用，那这份规范就是为你准备的。

第一部分：理念与架构

一、核心理念：Harness Engineering（驾驭工程）

1.1 什么是 Harness Engineering？

2026 年 2 月，OpenAI 发了一篇文章《Harness Engineering: Leveraging Codex in an Agent-First World》。一个 3 人（后来扩到 7 人）的工程师团队，在完全禁止手写代码的条件下，用 AI Agent 在 5 个月内写了超过 100 万行代码，合并了 1,500 个 Pull Request，效率大概提升了 10 倍。

Agent 治理：用 Hook 堵住 LLM 的偷懒、越权与失忆

Thu, 16 Jul 2026 00:00:00 +0800

腾讯程序员腾讯技术工程 2026年7月16日 17:52

作者：xiangnzhang

本文是 DECO（一个跑在生产上的数仓 Agent 引擎）实践系列之一，聚焦 护栏层 ：怎么用 Agent 框架的 Hook 切面，把 LLM 处理长文本时的"偷懒"（截断、略写、残缺）、对生产环境的"越权"（未确认发布、回刷）以及上下文传递中的"失忆"（改了表不查风险、产出了物不知汇报），在代码层确定性兜底——prompt 管不住的，框架来堵。

DECO 作为腾讯一站式数据工程 Agent 智能协作平台，以业务数仓知识库为基础，致力于解决从需求到数据交付全过程，主要聚焦于数据问询、开发、同步、分析、运维五大环节。希望帮助更多同学更轻松地获取数据、理解数据、应用数据，助力数据平权。

引子：从两个真实案例说起

案例一 ：用户让 Agent 改一张核心表的 ETL——1200 多行的长 SQL。Agent 读完原文、开始输出，写到一半"偷懒"了，中间跳过一大段逻辑写了句省略，然后若无其事地继续往下写。这份带省略号的脚本一旦提交上线，下游几十张表当天的数据就会算错。

案例二 ：Agent 还在"方案设计"阶段、用户都没点头，就径直调了发布工具，把一张还在讨论的表结构推上了生产。

这两个案例看似不相干，根因却是同一个——不是模型能力不够，而是它"图省事"或"自作主张"。具体有三种表现：

LLM 偷懒 ：处理长脚本（动辄上千行的 SQL / Python ETL）时，模型会截断、占位略写（输出 -- 其他字段...）、跳步骤、把长 SQL “复印"式重写到 token 耗尽，最后剩一堆残缺、不可执行的脚本。
越权操作 ：发布、回刷、冻结/解冻、终止实例这些写生产或不可逆的动作，模型无法区分操作的可逆性——它把发布和查询视为同一类"完成任务的步骤”，可能不打招呼就直接调了。
上下文失忆 ：模型改完表不去分析下游风险、Python 产出图表不知告诉用户——「需要查的就不查」。模型被训练成用最短路径完成任务——额外一次 tool call 意味着多一步推理，模型倾向于跳过"看起来不必要"的检查步骤。（此处风险分析为事后下游影响评估，非改表前拦截——事前拦截由 HITL Guard 负责。）

“在 prompt 里多写几句 ⚠️ 禁止"根本管不住。 这不是 prompt engineering（通过提示词约束模型行为）能解决的问题——长 SQL 是物理上超出 token 预算，危险操作是模型无法区分"查询"和"发布"的可逆性差异，被动探测是模型追求最短完成路径的自然倾向。唯一的解法是在 Agent 框架层，让偷懒和越权的路径 代码级强制走不通 ，让失忆的已知盲区 确定性补齐 。

Getting started with loops

Tue, 07 Jul 2026 00:00:00 +0800

There’s a lot of talk right now about “designing loops” instead of prompting your coding agent. If you spend some time on X trying to pin down what a loop actually is, you’ll come across multiple different answers.

On the Claude Code team, we define loops as agents repeating cycles of work until a stop condition is met. We categorize a few different types of loops based on:

How they are triggered
How they are stopped
What Claude Code primitive is used
What type of task is most appropriate for each.

We’ll cover the main loop types, when to use each, and how to maintain code quality while managing token usage. Not all tasks require complex loops; start with the simplest solution and use these patterns selectively.

Loop Engineering 实践指南：在 Code Buddy 中构建自主循环系统

Mon, 22 Jun 2026 00:00:00 +0800

腾讯程序员腾讯技术工程 2026年6月22日 17:22

作者：eliqiao

一、什么是 Loop Engineering

Loop Engineering 是由谷歌工程师 Addy Osmani 提出的 AI 编程新范式。其核心理念是： 围绕大模型构建自主循环运行系统，使 AI 从单次响应工具升级为长期自治代理。

在传统的 AI 辅助开发中，开发者与 AI 的交互模式是"一问一答"——你发一条指令，AI 回复一次，然后等待下一条指令。这种模式的瓶颈在于： 人成了循环的瓶颈 。每一步都需要人类介入，AI 无法自主推进复杂工作流。

Loop Engineering 的解法是： 让人从循环内部的操作者，转变为循环之上的监督者和目标设定者。 你定义"做什么"和"何时算完成"，AI 自己决定"怎么做"和"下一步是什么"，直到目标达成或确认不可达。

类比传统工程学中的 PDCA 循环（Plan-Do-Check-Act），在 Loop Engineering 中：

模型是执行者
Loop 是控制中枢
规则框架 是边界约束

这三者组合，让 AI 在可控范围内自主推进复杂工作流。

为什么现在重要

当模型能力足够强时， 循环设计 成为决定 AI 自主性与可靠性的关键瓶颈。一个设计良好的循环可以让 AI 连续工作数十轮完成复杂重构，而一个设计糟糕的循环可能在第三轮就失控。Loop Engineering 被视为继 Prompt Engineering、Context & Harness Engineering 之后的"AI 编程第三次革命"——开发者角色从"提示词工程师"彻底升级为"AI 系统架构师"。

二、Loop Engineering 与 ReAct 的区别

ReAct（Reasoning + Acting）是目前最主流的 AI Agent 交互范式，由 Yao et al. 在 2022 年提出。其核心模式是： 思考 → 行动 → 观察 → 思考 → 行动 → 观察…… 交替进行推理和工具调用，直到任务完成。

你不知道的大模型训练：原理、路径与新实践

Sat, 04 Apr 2026 00:00:00 +0800

太长也要读

在写完《你不知道的 Claude Code：架构、治理与工程实践》、《你不知道的 Agent：原理、架构与工程实践》后，我想着继续来写第三篇，这次打算挑战下自己来梳理一下大模型训练到底怎么回事，这篇文章争取让非专业背景的人也能读得懂。

2026 年来看大模型效果真正拉开差距的地方，慢慢不再是预训练本身了，而在它更后面的那一大段：后训练、评测、奖励、Agent 训练、蒸馏，每一个步骤都在影响用户实际感受效果。你发现某个模型突然变强了，背后可能是这几块一起优化到位了，而非单一因素导致。

下文按大模型训练链路顺序来讲，重点放在厂商怎么通过后半段训练栈来提升最终上线效果。

大模型训练其实是一条流水线

过去几年，一般会用参数、数据、算力的堆积来解释模型进步，但很多用户真正感受到的提升，并不是来自再多训一点基础语料，而是来自预训练后面那整套训练流程。模型怎么说话、怎么听指令、怎么推理、怎么用工具，这些都不是多喂一点互联网文本就能自然长出来的。

InstructGPT 当年给过一个很直接的例子：一个只有 1.3B 参数、做过对齐和偏好优化的模型，在人类偏好评测里能赢过 175B 的 GPT-3，参数量差了两个数量级，用户最后却更喜欢那个小很多的版本，训练后半段是真的会改写用户感知。

训练过程其实是一条流水线，数据、算法、系统、反馈这几层高度耦合，一层变化通常会传导到其他层，2026 年的模型能力和产业价值，也越来越集中在预训练后面的几层。

层	这一层真正在优化的	用户通常感知到的
预训练	知识覆盖范围、表示质量、规模效率	模型变聪明了
数据工程	数据分布、质量、去重、合成监督	为什么这个模型代码/数学/长文档更强
系统与架构	吞吐、显存、上下文长度、活跃参数、成本	为什么支持 128K 上下文或能在单卡跑
后训练	指令遵循、风格、拒答行为、工具使用	这个助手用起来更顺手
评测与奖励	什么叫好的、安全的、稳健的行为	这个模型感觉更可靠
蒸馏与部署	延迟、成本、专用化、在线持续改进	为什么上线版本和发布版本有差异

这也是我们平时为啥感觉豆包不太去争排名，但大家日常用起来却更符合心意的原因，是后训练做到位了。

这六层只是为了看分工，下图的九个阶段是更详细的版本：原始数据和系统配方单独拆开，Agent harness 和 Deployment 也是后半段的细分。还有两条反馈回路贯穿始终：生产流量回到数据工程，离线评测结果回到预训练。

Math behind Attention - Q, K, and V

Fri, 03 Apr 2026 00:00:00 +0800

Math behind Attention: Q, K, and V

In this blog, we will learn about the math behind Attention: Query(Q), Key(K), and Value(V) with a step-by-step numeric example.

We will cover the following:

The Attention Formula
Setting Up: From Words to Vectors
Creating Q, K, and V Matrices
Computing Attention Scores (Q x K^T)
Scaling the Scores
Applying Softmax
Computing the Final Output (Attention Weights x V)
Putting It All Together

I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

一文看懂 KV Cache

Fri, 03 Apr 2026 00:00:00 +0800

一文看懂 KV Cache

创作者简介—[@杨汶锦][@王凯]

Hi，大家好👏，本文作者长期专注于大模型推理系统研发与落地，主要在昆仑芯 P800 / P900 系列芯片上从事推理加速与优化、推理系统建设及超节点方向工作，在推理引擎优化、PD 分离、超节点模型适配与端到端性能调优方面具备扎实的一线实践经验。

写在前面，本篇文章主旨就是回答以下几个问题：

KV Cache 如何提升推理性能？
sglang 和 vllm中KV Cache 如何进行管理？
目前业界主流的 KV Cache 优化方向有哪些？

如果你对这三个问题都知道答案，那么本篇文章可以不用阅读

1.KV Cache 介绍

随着输入给 LLM 的 token 列表增长，Transformer 自注意力阶段可能成为性能瓶颈。token列表越长，意味着相乘的矩阵越大。每次矩阵乘法都由许多较小的数值运算组成，这些运算称为浮点运算，其性能受限于GPU的每秒浮点运算能力（FLOPS）。这样，在LLM的部署过程中，推理延迟和吞吐量问题成为了亟待解决的难题。这些问题主要源于：

生成推理的序列自回归特性，需要为所有先前的标记重新计算键和值向量。
由于注意力机制与输入序列的大小呈二次方关系增长，因此在推理过程中，注意力机制往往会产生最大的延迟开销。

为解决推理延迟和吞吐量问题，最常用的优化技术是 KV Cache。KV Cache 是一种关键的性能优化机制。它通过缓存已计算的Key和Value矩阵，避免在自回归生成过程中重复计算，从而显著提升推理效率（本质就是用空间换时间）。这种机制类似于人类思维中的短期记忆系统，使模型能够高效地利用历史信息。

冗余计算

左边图中会发现其中存在大量的冗余计算，每生成一个token需重新计算所有历史token的Key/Value，复杂度为 O(n2) ，显存和计算时间随序列长度急剧增长，如下所示：

生成embedding有冗余计算。
KV生成有冗余计算。
QKT有冗余计算。
softmax操作以及与V相乘有冗余计算。

理论基础

注意力模块（对应上图中标号1）。

你不知道的 Agent：原理、架构与工程实践

Sun, 22 Mar 2026 00:00:00 +0800

太长不读

在写完「你不知道的 Claude Code：架构、治理与工程实践」之后，发现自己对 Agent 底层的理解还不够深入，加上团队在 Agent 方向已经有不少业务落地经验，一直缺少一份系统梳理，所以我又把资料、开源实现和自己写的代码一起过了一遍，最后整理成了这篇文章。

这篇文章主要讲 Agent 架构里几块最影响工程效果的内容，包括控制流、上下文工程、工具设计、记忆、多 Agent 组织、评测、追踪和安全，最后再用 OpenClaw 的实现把这些设计原则串起来看一遍。

整理下来，有几处判断和我原来想的不太一样，更贵的模型带来的提升，很多时候没有想象中那么大，反而 Harness 和验证测试质量对成功率的影响更大，调试 Agent 行为时，也应优先检查工具定义，因为多数工具选择错误都出在描述不准确，另外，评测系统本身的问题，很多时候比 Agent 出问题更难发现，如果一直在 Agent 代码上反复调，效果未必明显，读完这篇，这几个问题应该能有些答案。

Agent Loop 的基本运转方式

Agent Loop 的核心实现逻辑抽象后其实不到 20 行代码：

const messages: MessageParam[] = [{ role: "user", content: userInput }];

while (true) {
 const response = await client.messages.create({
 model: "claude-opus-4-6",
 max_tokens: 8096,
 tools: toolDefinitions,
 messages,
 });

 if (response.stop_reason === "tool_use") {
 const toolResults = await Promise.all(
 response.content
 .filter((b) => b.type === "tool_use")
 .map(async (b) => ({
 type: "tool_result" as const,
 tool_use_id: b.id,
 content: await executeTool(b.name, b.input),
 }))
 );
 messages.push({ role: "assistant", content: response.content });
 messages.push({ role: "user", content: toolResults });
 } else {
 return response.content.find((b) => b.type === "text")?.text ?? "";
 }
}

对应的控制流如下，感知 -> 决策 -> 行动 -> 反馈四个阶段不断循环，直到模型返回纯文本为止：

你不知道的 Claude Code：架构、治理与工程实践

Fri, 13 Mar 2026 00:00:00 +0800

太长不读

今天这篇来自最近半年深度用 Claude Code 的实际踩坑，两个账号每月 40 刀，算是交了点学费。

刚开始也把它当 ChatBot 用，后来很快发现不对劲：上下文越来越乱、工具越来越多效果越来越差、规则越写越长却越不遵守，折腾一段时间，研究了 Claude Code 本身之后才搞清楚问题在哪。

最直接的理解方式，是把 Claude Code 拆成六层来看：

层	职责
`CLAUDE.md` / rules / memory	长期上下文，告诉 Claude “是什么”
`Tools` / `MCP`	动作能力，告诉 Claude “能做什么”
`Skills`	按需加载的方法论，告诉 Claude “怎么做”
`Hooks`	强制执行某些行为，不依赖 Claude 自己判断
`Subagents`	隔离上下文的工作者，负责受控自治
`Verifiers`	验证闭环，让输出可验、可回滚、可审计

单独优化任何一层都会在其他地方出岔子：CLAUDE.md 写太长，上下文先污染自己了；工具堆太多了，选择就搞不清楚了；subagents 开得到处都是，状态就漂移了；验证这步跳过了，出了问题根本不知道是哪里挂的。

它底层是怎么运行的

Claude Code 跑的是一个反复循环的代理过程：

收集上下文 → 采取行动 → 验证结果 → [完成 or 回到收集]
 ↑ ↓
 CLAUDE.md Hooks / 权限 / 沙箱
 Skills Tools / MCP
 Memory

用了一段时间才意识到，卡住的地方几乎从来不是模型不够聪明，更多时候是给了它错误的上下文，或者写出来了但根本没法判断对不对，也没法撤回。