Estars的博客 
Agent超大结果面试题整理版
Agent 工具调用返回超大结果的处理策略
面试题：Agent 调用工具可能返回超大结果（比如代码搜索返回 50KB），这会带来什么问题？你会怎么处理？OpenClaw 是怎么做的？
一、超大结果带来的三个问题
| 问题 | 说明 |
|---|---|
| Token 爆炸 | 50KB 文本 ≈ 12000+ token，一条结果就干掉 128K 窗口的近 10% |
| 挤占上下文空间 | 对话历史、系统提示、用户消息全被挤压，模型理解质量直线下降 |
| 延迟飙升 | API 按 token 计费，多塞进去的大部分是噪声，等于花钱买垃圾 |
二、处理思路：限额 + 截断
核心原则：给每条 tool result 设一个字符上限，超了就砍。
截断策略：head + tail 截断
- 保留开头：让模型知道内容是什么
- 保留尾部：抓住错误信息（错误堆栈、诊断信息往往在末尾）
- 中间砍掉 + 加省略标记
📌 类比：看日志时，最后几行的报错信息通常最关键。
三、OpenClaw 的两层防护
第一层：单条截断
| 参数 | 值 |
|---|---|
| 字符上限 | context window 的 30% |
| 硬上限 | 400K 字符 |
| head 占比 | 约 70%（最少保留 2000 字符） |
| tail 占比 | 约 30%（上限 4000 字符） |
智能检测：hasImportantTail() 检测尾部是否包含关键词（error/exception/failed/traceback 等）或 JSON 闭合结构，只有检测到才走 head+tail 分割，否则默认只保留开头。
截断后附加提示：告诉模型内容不完整，可以用 offset/limit 重新获取。
第二层：全局预算守卫
每次发 LLM 请求前，通过 transformContext 管线自动执行全局预算检查：
- 先把每条 tool result 按单条上限裁一遍
- 估算所有消息的总字符开销
- 如果超过全局预算（context window 的 75%），从最早的 tool result 开始逐条替换为占位提示
📌 核心思路：越早的 tool result 对当前决策影响越小，优先牺牲给新内容让路。这是一种抢占式策略——不等 context overflow 报错，主动腾空间。
字符预算计算公式
字符预算 = context window tokens × 每 token 字符数 × 比例系数以 128K token 模型为例：
| 预算类型 | 计算 | 结果 |
|---|---|---|
| 单条上限 | 128000 × 0.3 × 4 | ≈ 150K 字符 |
| 全局预算 | 128000 × 4 × 0.75 | ≈ 384K 字符 |
⚠️ OpenClaw 对 tool result 用 token 换算系数 2（而非 4），因为代码和结构化文本的 token 密度比自然语言高，估算更保守准确。
四、扩展知识
为什么不能只保留前 N 个字符？
最简单的方案 result.substring(0, maxLen) 会丢关键信息：
- grep 搜索返回 200 个匹配，最相关的那条可能在中间或末尾
- 命令执行失败，stdout 里一堆正常输出，真正的 error 在最后几行
📌 只保留开头 → 模型拿到的全是无用信息，还以为执行成功了。
head+tail 策略虽然不完美，但至少能兜住两头。
多 block 内容处理
truncateToolResultMessage() 对多 block 内容会按比例分配字符 budget，每个 block 都能分到一份额度，避免某个 block 独占所有空间。
其他 Agent 框架怎么处理
| 框架 | 处理方式 |
|---|---|
| LangChain | ToolMessage 默认不截断，社区实践通常在 tool 的 output parser 层加限制 |
| Anthropic Claude | 建议单条 tool result 不超过 100K 字符 |
| AutoGPT | 早期版本没做截断，文件读取返回太大直接撑爆 context，后来才加了 max_length 参数 |
五、面试官追问
Q1：截断后模型根据不完整信息做了错误判断，怎么处理？
答：
- 在截断标记里告诉模型内容被截断了，让它自己决定要不要重新获取
- 附上原始内容的字符数和行数，模型就能判断丢了多少信息
- 如果模型觉得关键信息可能在被截断的部分，可以发起更精确的二次查询（缩小搜索范围或指定行号范围）
OpenClaw 的截断后缀会明确告诉模型
Content truncated，并建议使用 offset/limit 参数。
Q2：head+tail 截断的比例怎么定？
答：没有通用最优比例，看 tool 的类型。
| 工具类型 | 推荐比例 | 原因 |
|---|---|---|
| 搜索类工具 | head 70% / tail 30% | 结果按相关性排序，head 更重要 |
| 命令执行类工具 | head 40% / tail 60% | 关键信息往往在末尾（错误堆栈） |
OpenClaw 的做法：
- tail 拿 budget 的 30%（上限 4000 字符）
- head 拿剩余大部分空间（最少保留 2000 字符）
- 只有
hasImportantTail()检测到尾部含 error/exception/traceback 等关键词时才走 head+tail，否则默认只保留开头
Q3：除了截断，还有没有其他方式处理超大 tool result？
答：有三种思路：
| 方式 | 说明 |
|---|---|
| 工具端过滤 | 代码搜索只返回最相关的 top 10 结果，不吐全量 |
| 摘要压缩 | 用摘要模型先把大结果压缩成摘要再喂给主模型（Anthropic 内部有类似 sub-agent） |
| 分页 | 把大结果拆成多页，模型可以选择翻页获取更多内容 |
📌 截断是最简单粗暴的兜底方案，理想情况下应该在工具端就控制好输出量。
六、总结思维导图
Agent 工具返回超大结果怎么办？├── 带来的问题│ ├── Token 爆炸│ ├── 挤占上下文空间│ └── 延迟飙升├── 处理思路：限额 + 截断│ └── head + tail 截断（保留开头+尾部）├── OpenClaw 两层防护│ ├── 1. 单条截断（context window 30%，硬上限 400K）│ └── 2. 全局预算守卫（context window 75%，抢占式压缩）├── 关键设计│ ├── hasImportantTail() 智能检测│ ├── 多 block 按比例分配│ └── 截断后附加提示（支持 offset/limit）└── 其他方案 ├── 工具端过滤（top N） ├── 摘要压缩（sub-agent） └── 分页来源：面试鸭 · 2026最新AI大模型原理和应用面试题 整理时间：2026-05-29
Share Article
If this article helped you, please share it with others!
Music
No playing