Zane/obsidian-notes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

11

Browse Source
This commit is contained in:
Zane
2026-04-14 15:04:12 +08:00
parent a6eaa690d8
commit 0702eb2a89
7 changed files with 12 additions and 181 deletions
Download Patch File Download Diff File Expand all files Collapse all files

115
3Resources/AI/Agent上下文管理策略.md Normal file
View File

@@ -0,0 +1,115 @@
# 万字长文解析Agent框架中的上下文管理策略
**来源**: [知乎](https://zhuanlan.zhihu.com/p/2012088406826562496)
**收录时间**: 2026-04-09
**标签**: #Agent #上下文管理 #LLM #ClaudeCode
---
## 0x00. 写在前面
今年春节前后，至少9家国内的厂商密集地发布了他们旗舰版本的模型（比如GLM5、MiniMaxM2.5、Qwen3.5），可以发现大模型领域的竞争焦点从通用能力转向了Agent落地、编程能力这两大方向。
随着Claude Code、OpenClaw等Agent Scaffold的爆火，各大厂商也纷纷将自己的定位锁定在Agentic Engineering上，从"chatbots that respond" 转向 "agents that act"。
---
## 0x01. 背景
### （1）什么叫上下文工程（Context Engineering）？
"上下文工程"简单来说，就是在一些LLM的约束下（如上下文窗口大小、注意力长度的限制），优化上下文token的效用，从而持续获得理想输出的工程实践。
一个好的context engineering追求用最少的、信号最强的token集合，最大化期望输出的概率。
如果说之前早期的"Prompt Engineering"适用于单轮文本生成任务；那么"Context Engineering"就适用于需要多轮推理、长时间运行的智能体，需管理不断演变的上下文状态。
### （2）为什么Context Engineering对构建一个强大智能体来说至关重要？
Agent 每调用一次工具，就会返回一个工具的Observation，这个结果会被追加到聊天记录中。生产环境中的 Agent 可能会进行长达数百轮的对话，因此随着时间的推移，历史记录message会越来越长。
**上下文腐败（context rot）**：虽然现在的LLM能够接受越来越长的序列了，但它们和人类一样，会随着上下文增长而出现注意力涣散的现象，模型准确回忆信息的能力会下降，而且推理也会变慢。
导致这种现象的原因包括：
- **注意力分散**：每个token都关注上下文中的所有其他token，形成了 n^2 级别的两两关系
- **训练数据偏差**：模型在训练时接触的长序列远少于短序列
- **位置编码插值**：可以让模型适应更长的序列，但通常会牺牲一定的精度
---
## 0x02. 上下文工程
### （1）上下文卸载与检索（Context Offload & Retrieval）
#### (a) 将上下文卸载到文件系统（紧凑化, Compaction）
Manus提出了一个核心理念：**将文件系统视为终极上下文**。这是因为文件系统天然具有无限容量、持久化、可随机访问的特性。
这种"可逆压缩"确保上下文长度缩减的同时，信息并未真正丢失——它们只是被卸载到文件系统中了，随时可以重新加载进来。
#### (b) 检索：推理前检索 vs "Just-in-time"检索
**RAG（Retrieval-Augmented Generation）**：预先对知识库的文本进行向量化，然后在推理前预先检索相关片段。
**Just-in-time检索**：让 LLM 自己生成搜索命令，像人类一样主动探索大文件或者代码库。
Claude Code 在处理大型的数据时，会生成一些复杂的 Bash 命令进行查询（如ripgrep、jq、find等），利用自己对代码的深刻理解，使用精细而复杂的正则表达式定位相关代码块。
### （2）上下文摘要(Context Summarization)
当上下文窗口即将被填满，且没有办法进一步做紧凑化的时候，我们不得不采用另一种手段：摘要化。这是一种有损压缩，它会将对话历史浓缩成一段摘要，从而释放空间。
**Claude Code的压缩流程**：
- 自动触发：监控当前上下文的 token 使用量，接近上限时自动触发
- 手动触发：用户可通过/compact命令主动执行压缩
摘要包含：主要请求和意图、关键技术概念、文件和代码段、错误和修复、问题解决、用户所有消息、待办任务、当前工作、可选下一步
### （3）上下文隔离（多智能体架构）
面对一个复杂的任务，我们可以将任务分解，然后由主智能体协调多个专门化的子智能体（sub-agents）来处理具体任务。
**多智能体架构的好处**：
- **节省主Agent的上下文**：subagent的上下文和主agent是隔离的
- **权限控制**：限制 subagent 可用的工具
- **特定领域专业化**：为特定领域编写专门的系统提示
- **节约调用成本**：可以把某些简单的任务路由到更快、更便宜的模型
**Claude Code的subagent分类**：
- **Explore**：只读 agent，专门用于搜索和分析代码库（使用 Haiku）
- **Plan**：负责理解代码库并进行规划（使用 Sonnet/Opus）
- **General-Purpose**：全能型 agent（使用 Sonnet/Opus）
**运行模式**：
- **前台运行模式**：subagent 运行时阻塞主对话，用户实时决定要不要accept操作
- **后台运行模式**：subagent 在后台运行，启动前收集权限，运行中自动拒绝未批准的操作
**调用关系**：
- **并行调用**：多个 subagent 同时独立运行
- **链式调用**：多个 subagent 顺序执行，后一个依赖于前一个的输出
### （4）上下文缓存
**KV Cache（KV缓存）**：Transformer 模型在生成每个 token 时，需要计算所有之前 token 的Key和Value向量，用于注意力机制的计算，这些 KV 向量就构成了上下文的状态。KV Cache就是将这些中间计算结果保存下来，当后续请求包含相同的前缀时，可以直接复用。
**Prefill（预填充）**：只在生成第一个输出 token 之前，模型对所有输入 token 进行并行处理的阶段。
**为什么缓存对 agent 来说至关重要？**
- Agent 的工作流程是多轮工具调用的重复
- 平均Agent的输入输出 token 比高达 100:1
- 以 Claude Sonnet 为例，缓存的输入 token 价格为 0.30 美元/百万 token，而未缓存的则高达 3 美元/百万 token，相差 10 倍！
**Claude Code的缓存策略**：
- **核心原则**：上下文只追加，不修改
- **自动缓存**：在请求顶层添加cache_control字段，系统自动将最后一个可缓存的内容块作为缓存断点
- **手动缓存**：对稳定性极高的内容（如system prompt、工具定义）使用显式断点
- 最多4个缓存断点（包括显式和自动缓存）
---
## 参考链接
- https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- https://minusx.ai/blog/decoding-claude-code/#21-use-claudemd-for-collaborating-on-user-context-and-preferences
- https://manus.im/en/blog/Context-Engineering-for-AI-Agents-Lessons-from-Buliding-Manus
- https://platform.claude.com/docs/

223
3Resources/AI/AutoHarness-论文解读.md Normal file
View File

@@ -0,0 +1,223 @@
---
原文发布链接: https://zhuanlan.zhihu.com/p/2016839356833341880
tags:
- AutoHarness
- AI
- 论文解读
- AutoHerness
- LLM
- Agent
- ProgramSynthesis
- GRPO强化学习
---
## 一句话总结
用小模型（Gemini-2.5-Flash）自动写一段"规则检查代码"包裹在 LLM 外面，让它不再犯"非法操作"的低级错误，结果小模型+代码 > 大模型裸跑。
---
## 这篇论文到底在解决什么问题？
### LLM 做 Agent 时的尴尬现实
你可能已经知道，现在很多人在用 LLM 做 agent——让模型去完成一些需要"行动"的任务，而不是简单地回答问题。比如让 LLM 下棋、玩游戏、操控机器人等。
**问题来了：LLM 经常做出"非法操作"。**
论文举了一个非常生动的例子：在 Kaggle GameArena 的国际象棋比赛中，Gemini-2.5-Flash 78% 的失败不是因为下棋策略差，而是因为走了不符合规则的棋。比如让马走直线、让兵倒着走之类的。
这就好比你请了一个非常聪明的人来帮你下棋，他对棋局分析得头头是道，但就是经常把棋子摆到不合法的位置上。
### 为什么会这样？
LLM 本质上是一个文本生成模型。它"知道"国际象棋的规则（因为训练数据里有大量棋谱），但它没有一个硬编码的规则引擎来确保输出的每一步都合法。它的"知道"是概率性的、模糊的，不是精确的。
### 现有解决方案及其问题
| 方案 | 怎么做 | 问题 |
|------|--------|------|
| Fine-tuning | 用大量合法游戏轨迹去微调模型 | 成本极高；可能降低模型在其他任务上的能力 |
| 手写 Harness | 人工为每个游戏写一个规则检查器 | 费时费力，每换一个游戏就要重写 |
**这篇论文的创新点是：让 LLM 自己写这个规则检查器。**
---
## 核心概念：什么是 "Harness"？
### Harness 的直觉理解
"Harness" 这个词在英文里是"挽具/马具"的意思，用来控制和约束马的行为方向。在这篇论文里，Harness 就是包裹在 LLM 外面的一层"安全壳"，确保 LLM 输出的动作是合法的。
用工程的话说，这就是一个 wrapper / middleware / interceptor：
```
传统做法：
用户请求 → LLM → 输出动作（可能非法）→ 环境报错
加了 Harness 之后：
用户请求 → LLM → Harness检查 → 合法? → 执行
↓ 不合法
告诉LLM"这步不行" → LLM重新生成 → 再检查...
```
### 三种 Harness 变体
论文提出了三种不同"约束力度"的 harness：
#### ① Harness-as-Action-Verifier（动作验证器）— 论文主要聚焦的方案
```python
while True:
action = LLM.generate(observation) # LLM 提出一个动作
if code_harness.is_legal_action(obs, action): # 代码检查是否合法
break # 合法就执行
else:
# 不合法，告诉 LLM 这步不行，让它重新想
observation += f"\n警告：{action} 是非法操作，请重新选择"
return action
```
类比：就像你写代码时 IDE 的实时语法检查——你写了不合法的代码，红线提示你改。
#### ② Harness-as-Action-Filter（动作过滤器）
```python
legal_actions = code_harness.propose_action(obs) # 代码先列出所有合法动作
best_action = LLM.rank(legal_actions) # LLM 从中选最好的
return best_action
```
类比：就像下拉菜单——用户只能从合法选项中选，不可能输入非法值。
#### ③ Harness-as-Policy（代码即策略）— 最激进的方案
```python
action = code_harness.propose_action(obs) # 完全由代码决定动作
return action # 根本不需要 LLM
```
类比：你直接写了一个规则引擎/算法来玩游戏，LLM 只在"开发阶段"用来写这个算法。运行时零 LLM 调用，零成本。
---
## 核心方法：怎么让 LLM 自动写出 Harness？
这是论文最核心的技术贡献。如果你熟悉 GRPO，你可以把这个过程理解为：用环境反馈来优化代码，而不是优化模型权重。
### 整体流程
```
1. 初始化：LLM 写一版 harness 代码（propose_action + is_legal_action）
2. 测试：用这个代码在游戏环境里跑 rollout
3. 评估：记录哪些动作被判为非法，收集错误信息
4. 反馈：把错误信息喂给 LLM（Critic 模块整理错误）
5. 优化：LLM 基于错误反馈生成改进版代码（Refiner 模块）
6. 重复 2-5，直到合法率达到 100% 或超时
```
### 和 GRPO 的对比
| 维度 | GRPO | AutoHarness |
|------|------|-------------|
| 优化的对象 | 模型权重 θ | 代码文本（程序） |
| 搜索空间 | 参数空间（连续） | 程序空间（离散） |
| 反馈信号 | reward（标量） | 执行反馈（错误日志+reward） |
| 优化方法 | 梯度下降 | LLM 当"突变算子"改代码 |
| 探索策略 | 采样多个 response 对比 | Thompson sampling 做 tree search |
| 类比 | 调参让模型更好 | 让 AI 写更好的代码 |
**关键区别**：GRPO 改的是模型内部的权重，AutoHarness 改的是模型外部的代码。一个改"大脑"，一个改"工具"。
### Tree Search + Thompson Sampling
#### 为什么要用 Tree Search？
简单的迭代优化（写代码 → 测试 → 改代码 → 测试…）有个问题：容易陷入局部最优。比如 LLM 沿着一个思路改了 5 版代码，发现这个方向走不通了，但已经回不去了。
Tree search 的思路是：同时维护多个版本的代码，像一棵树一样分叉发展。
```
初始代码 v0
/ \
v1a v1b ← 两个不同的改进方向
/ \ |
v2a v2b v2c ← 继续分叉
|
v3a ← 这个方向成功了！合法率100%
```
#### Thompson Sampling 是什么？
你面对这棵树上的多个节点，每次迭代应该选哪个节点来继续优化？这就是经典的 exploration-exploitation（探索-利用）问题：
- **利用（Exploitation）**：选当前表现最好的代码版本继续改进
- **探索（Exploration）**：试试那些还没被充分优化的代码版本，也许潜力更大
Thompson sampling 是一种概率性的选择策略：
```
对每个节点：
1. 根据它历史的"合法率"数据，建一个概率分布（Beta 分布）
2. 从这个分布中随机采样一个值
3. 选采样值最高的节点来优化
效果：表现好的节点被选中的概率更高（利用），
但表现差的节点也有机会被选中（探索）
```
工程类比：这和你做 A/B testing 时的 Multi-Armed Bandit 问题几乎一模一样。Thompson sampling 就是一种 bandit 算法。
### Critic 和 Refiner 的分工
**Critic（批评者）**：
- 输入：rollout 中失败的步骤（最多 5 个）
- 工作：整理和归纳各种错误类型
- 输出：结构化的错误摘要
- 类比：Code Review 时给你提 bug 的同事
**Refiner（优化者）**：
- 输入：当前代码 + Critic 的错误摘要
- 工作：基于反馈生成改进版代码
- 输出：新版本的 harness 代码
- 类比：你根据 code review 意见改代码
一个关键细节：如果 `is_legal_action()` 返回 True 但环境说动作非法（漏判），则两个函数都要改；如果 `is_legal_action()` 返回 False 且动作确实非法（检查器工作正常，只是 `propose_action` 提出了错误动作），则只改 `propose_action()`。这个区分很重要，避免了"改了不该改的代码"。
---
## 实验结果解读
### 训练效率：多快能学会？
- 平均 **14.5 次迭代**就能学会（即 LLM 改代码 14.5 次）
- **19/32 个游戏**不到 10 次就搞定了
- 最难学的游戏：GermanWhist（43次）、Chess（64次）、Othello（62次）
直觉理解：简单游戏（如猜数字、骰子）规则简单，几次就能写对检查器；复杂游戏（如国际象棋）规则多样（王车易位、吃过路兵等），需要更多轮迭代。
最终结果：**全部 145 个游戏都达到了 100% 合法动作率。**
### 双人游戏：小模型+Harness vs 大模型
| 对阵 | 我们的方法胜率 | 对手胜率 |
|------|--------------|----------|
| Flash+Harness vs Gemini-2.5-Pro | **56.3%** | 38.2% |
| Flash+Harness vs Flash（原始） | **64.8%** | — |
这意味着什么？**一个小模型（Flash）配上自动生成的规则检查代码，可以打败一个大几倍的模型（Pro）。**
---
## 核心启示
1. **"代码即策略"可能是 LLM Agent 的终局形态** — 让 LLM 写代码，然后运行时零 LLM 调用
2. **小模型+好代码 > 大模型裸跑** — 这打破了"模型越大越好"的迷信
3. **Program Synthesis + RL 的结合** — 这可能是下一代 AI 系统的核心范式
---
## 标签
#论文解读 #AutoHarness #LLM #Agent #ProgramSynthesis #GRPO #强化学习