# 自主智能体侦察税：读码黑洞 ## 概述 当我们把一个自主智能体（Autonomous Agent）丢进一个未知代码库、未知 API 或未知浏览器环境时，它的第一反应几乎总是**"先看个遍"**——递归列目录、批量读文件、加载全部工具定义、反复 probe 接口。2026 年的多份生产级基准报告揭示了一个被忽视的硬成本结构：**自主智能体消耗的 token 是普通 chatbot 的 10–50 倍，而其中 40%–80% 并未产生任何动作，只用于"理解环境"**。这种"读而不做"的开销，我们称之为**侦察税（Reconnaissance Tax）**。更致命的是，侦察阶段塞进来的上下文不会自动消失，反而随循环累积，触发**上下文膨胀（Context Bloat）**——一个开局 2K token 的会话跑到第 20 步可能膨胀到 40K，而模型在臃肿上下文里的推理质量会显著退化：**越读越笨**。本文拆解侦察税的六种形态、上下文黑洞的二次伤害，以及 2026 年主流自主智能体栈（Claude Code、Cursor、OpenHands、SWE-agent、Devin、Cline、Codex）的克制策略。 --- ## 一、侦察税的根源：从 Push 到 Pull 的范式代价 传统 RAG 流水线是 **Push 架构**：检索器一次性把最相关的 N 个片段推进上下文，模型直接作答，token 成本是固定的。自主智能体彻底转向了 **Pull 架构**：模型在一个 loop 里自己决定"现在该读哪个文件、调哪个工具"，每次循环都把新的观测结果追加进上下文。这种"按需拉取"的代价是**累积性**的——第 1 步读的 `README.md`、第 5 步读的 `auth.py`、第 12 步读的 `tests/` 全都赖在上下文里，因为模型"可能待会儿还要参考"。 这就是侦察税的本质：它不是单次调用贵，而是**循环让每一次廉价的读取都变成了永久的上下文租金**。一个 chatbot 回答一个问题用 2K token；同一个智能体去"修这个 bug"会先花 30K token 把代码库摸一遍，真正写代码只占末尾的 3K。开发者社区已经出现一个共识性比喻：**长程智能体的上下文压缩之于智能体，就像垃圾回收之于长期运行的服务器**——不做就会内存泄漏，只是这里的"泄漏"你 grep 不到。 ```python # 典型的"无脑侦察"loop：每一轮都把全量观测塞进 messages messages = [system] for step in range(max_steps): # ❌ 历史观测永不清理，上下文单调膨胀 messages += agent.step(messages) # step() 内部 read_file/read_dir 全量返回 # 结果：step 1 context=2K → step 20 context=40K，推理质量随膨胀下降 ``` --- ## 二、代码库侦察：50 文件仓库的上下文塌方 代码型自主智能体是侦察税的重灾区。基准报告记录了一个典型场景：**一个智能体要理解一个 50 文件的代码库，会把这些文件依次加载进上下文**。即使每份文件平均只有 300 行，整体也轻易突破 30K–50K token，而其中真正与当前任务相关的可能不到 5K。 各家栈的侦察哲学差异巨大。**Claude Code** 默认鼓励用 sub-agent（子智能体）做隔离侦察——主 agent 派一个子进程去"读完这个目录总结给我"，子进程的臃肿上下文在返回时被丢弃，主链只保留摘要。**Cursor** 依赖 IDE 层的代码索引（类 repomack 的全仓库符号化），把"侦察"前置到离线索引阶段，运行时只拉取符号摘要。**OpenHands（原 OpenDevin）** 默认偏激进，读文件直接进主上下文，所以它后来引入了 `condenser`（压缩器）模块作为标配。**SWE-agent** 则是最早把"侦察"工程化的：它的 ACI（Agent-Computer Interface）强制一个**有限的文件视图窗口（file_view）**——一次只显示 100 行，用 `scroll` 翻页，从机制上禁止"一次读全文"。 | 智能体栈 | 默认侦察策略 | 上下文管理机制 | 侦察税严重度 | |---|---|---|---| | SWE-agent | 有界窗口（100行/屏） | ACI 强制视图 | ★ 低（专为限侦察设计）| | Cursor Composer 2.5 | IDE 离线索引 + 符号摘要 | 索引层过滤 | ★★ 低-中 | | Claude Code | sub-agent 隔离侦察 | /compact + 子任务隔离 | ★★ 中 | | Devin | 知识库 + 规划先行 | KB 缓存 | ★★ 中 | | OpenHands | 直接读入主上下文 | condenser 压缩器 | ★★★★ 高 | | Cline | 逐步 read，无全局视图 | 自动压缩（阈值触发）| ★★★★ 高 | SWE-agent 的数据最能说明问题：它的核心贡献不是"更聪明"，而是**通过 ACI 限制每步可见信息量，从而把侦察税压到最低**，在 SWE-bench Verified 上以极低的 token/任务比拿下了早期的 SOTA。 --- ## 三、工具定义税：MCP 的 60–80% 上下文黑洞 侦察税不只是"读代码"，还包括"读工具"。2026 年企业级 MCP（Model Context Protocol）部署暴露了一个反直觉的数据：**企业 MCP 部署经常在智能体开始任何真正工作之前，就把 60%–80% 的上下文预算烧在了工具定义上**。一个接入了数据库、Jira、Slack、知识库、CRM 的企业智能体，光是把这些工具的 JSON Schema 塞进 system prompt 就要 20K+ token，留给实际任务推理的窗口被压到极小。 ```json // 单个工具定义轻易 200-800 token，企业栈动辄 50+ 工具 { "name": "search_tickets", "description": "Search Jira tickets by JQL query. Supports ...", "input_schema": { /* 嵌套 4 层，含枚举、示例、约束 */ } } // 50 个这样的工具 ≈ 30K token，全部常驻上下文 ``` 克制的做法是**工具检索（tool retrieval / progressive discovery）**：不把全部工具定义常驻，而是用一个轻量检索器按当前任务召回 top-k 工具，只把这些注入上下文。OpenClaw 这类"上下文节省器"报告能把工具数据膨胀砍掉约 98%。这与"千工具箱召回塌方"是同一枚硬币的两面——当工具少时常驻更省事，当工具上百时检索是唯一出路，分界线大致在 **15–25 个工具**。 --- ## 四、目录递归爆炸：`ls -R` 式侦察的瀑布 第三种侦察税形态是**目录递归爆炸**。当一个智能体面对陌生仓库，最朴素的策略是 `ls` 看顶层 → 看到子目录 → 进去再 `ls` → 看到 src → `ls src`……这种贪心的广度优先扫描在没有护栏时会一直递归到把整个仓库结构灌进上下文。更糟的是很多智能体在不确定时**重复列目录**——同一个 `ls` 在不同步骤被调用三到五次，因为模型忘了自己已经看过，或者上一次的输出已经滚出上下文窗口。 ```bash # 真实事故链：一次"摸清结构"演变成上下文洪水 ls # 8 行 ls src/ # 22 行 ls -R src/ # ❌ 480 行，瞬间灌入 ~6K token find . -name "*.py" # ❌ 又 320 行，且与上一步大量重叠 ``` **症状识别**：如果一个智能体的 trace 里 `ls`/`find`/`tree` 类只读侦察工具的调用占比超过 30%，基本可以判定它在"侦察瘫痪"——花了大半预算摸环境却迟迟不动手。**对策**是结构化约束：用 `.agents/` 目录这类约定把仓库的"侦察摘要"（架构图、入口文件、关键模块）固化成静态文件，让智能体读一个 1K token 的摘要而不是递归扫 50K token 的真实目录。`bgreenwell/dotagents` 提出的正是这种**标准化的环境契约**。 --- ## 五、上下文膨胀的二次伤害：越读越笨 侦察税最阴险的部分不在"贵"，而在**累积侦察会主动降低推理质量**。这就是上下文膨胀（Context Bloat）。一份广泛引用的分析记录：**一个以 2K 上下文开局的长期会话，最终要为 40K token 中大部分已经无关紧要的内容付费**，而模型的注意力被稀释——这就是所谓的 **context rot（上下文腐烂）**。学术上，arXiv 2601.07190《Active Context Compression》明确指出：**LLM 智能体在长程软件工程任务上的退化，主因不是能力不足，而是无关上下文的累积挤占了有效注意力**。 这意味着侦察税是一个**正反馈恶循环**：读得越多 → 上下文越臃肿 → 模型越抓不住重点 → 越倾向于"再多读一点确认一下" → 上下文更臃肿。很多开发者观察到智能体在任务后期开始"重复读已读过的文件""反复确认同一事实"，这不是模型变蠢了，而是**上下文里的关键信息被淹没在侦察噪音里**，模型不得不重新检索。SWE-bench 上的失败 case 复盘里，相当一部分是"智能体其实找到了正确文件，但因为上下文太臃肿在第 30 步忘记了第 5 步的发现，绕回了起点"。 --- ## 六、克制策略一：渐进式发现（Progressive Discovery） 第一副解药是**渐进式发现**——让智能体按需展开，而非一次性铺开。核心理念：**初始上下文只放任务描述 + 最少的入口指针，把更深的信息推到工具调用时才拉取**。这与 SWE-agent 的有界窗口、sub-agent 隔离、工具检索都是同源的：**延迟绑定、按需拉取、用完即弃**。 ```python # 渐进式发现：先拿"摘要/索引"，命中后才读"全文" # 第1层：仓库地图（1K token，常驻） layout = read(".agents/REPO_MAP.md") # 固化的结构摘要 # 第2层：模块摘要（按需，子agent读，主链只收摘要） api_summary = subagent.summarize("src/api/") # 第3层：具体函数（只在确定要改时才读） if needs_edit(auth_login): code = read_lines("src/auth.py", 40, 90) # 只读相关区间 ``` **优点**：上下文始终精简，推理质量稳定；token 成本可降一个数量级。 **缺点**：需要前期投入——要么人工维护 `.agents/` 摘要，要么写索引管线；摘要过期会误导智能体。 **变现评估**：这是 2026 年训练营和咨询的高价值赛道——"给你的代码库做一次 agent-ready 索引化改造"是可以打包成 2–5 万元企业服务的产品，因为它直接降本且可量化（token/任务下降百分比）。 --- ## 七、克制策略二：上下文压缩作为 GC 第二副解药是**主动上下文压缩（Active Context Compression / Compaction）**。把长程会话当成一个需要垃圾回收的进程：定期把"已经用完、不再相关"的旧观测压缩成摘要，腾出窗口给新工作。Claude Code 的 `/compact`、Cline 的阈值自动压缩、OpenHands 的 condenser 都是这个范式。Anthropic 在 2026 年初推出的官方压缩机制被业界视为"把上下文膨胀当作基础设施问题来治"。 压缩不是无脑截断。关键区分是**保留什么、丢弃什么**： | 保留（高价值） | 丢弃/压缩（低价值） | |---|---| | 任务目标、验收标准 | 已读过的文件原文 | | 关键决策与理由 | 目录列表、`ls` 输出 | | 已建立的事实/约束 | 失败的尝试 trace | | 当前正在编辑的代码 | 探索性 probe 的原始返回 | **优点**：能把会话从几十步延长到上百步而不退化，是长程任务能跑通的前提。 **缺点**：压缩本身有损——摘要可能丢掉"看似无关实则关键"的信息；压缩时点是门艺术，太频繁增加延迟，太稀疏已经退化。 **变现评估**：压缩策略调优是"长程智能体稳定性"咨询的核心交付物，适合面向做客服/运维/数据分析这类**长会话场景**的 B 端客户。 --- ## 八、克制策略三：Pull→Push 的有限回归与 `.agents/` 契约 第三副解药最具结构性：**在最不确定的开局，主动回归 Push**。完全的 Pull 架构让智能体从零摸索环境，这正是侦察税的温床。一个更稳的混合范式是——**用 Push 提供"环境契约"，用 Pull 处理"任务执行"**：通过 `.agents/` 目录这类约定，仓库/系统主动向智能体声明"我是谁、入口在哪、约束是什么、别去碰什么"，把本该由智能体花 30K token 摸清楚的东西，用 1K token 的静态摘要交付。 ``` .agents/ ├── REPO_MAP.md # 架构与模块入口（替代 ls -R） ├── CONVENTIONS.md # 代码规范与禁忌（替代踩坑式试错） ├── ENTRYPOINTS.md # 关键函数/接口指针（替代 find/grep） └── DO_NOT_TOUCH.txt # 危险区/只读区（替代事故性侦察） ``` 这与 SWE-agent 的有界窗口、Cursor 的离线索引殊途同归：**把侦察成本从运行时（按 token 计费、且累积）转移到构建时（一次性、固定）**。 ```mermaid flowchart TD A[自主智能体进入未知环境] --> B{有 .agents/ 契约?} B -- 是 --> C[Push: 读 1K 摘要
跳过侦察] B -- 否 --> D[Pull: 递归 ls/find/read
触发侦察税] D --> E[上下文膨胀
2K → 40K] E --> F[context rot
越读越笨] F --> G{有压缩机制?} G -- 否 --> H[循环退化/超预算] G -- 是 --> I[Active Compression
摘要旧观测] C --> J[有限 Pull: 仅读相关区间] I --> J J --> K[执行动作 + 写代码] K --> L[交付] style D fill:#ffd6d6 style E fill:#ffd6d6 style F fill:#ffd6d6 style C fill:#d6ffd6 style I fill:#d6f0ff ``` --- ## 推荐方案：按场景对症下药 **1. 个人/小团队单仓库开发（Claude Code / Cursor）** 侦察税可控，重点是**养成 sub-agent 隔离侦察 + 定期 `/compact` 的习惯**。把"摸结构"这类任务派给子进程，主链保持精简。投入产出比最高的一招：**给常驻仓库写一份 `.agents/REPO_MAP.md`**，立竿见影。 **2. 开源/研究型长程任务（OpenHands / 自建栈）** 务必**默认开启 condenser/压缩器**并校准保留策略。OpenHands 裸跑的侦察税偏高，不配压缩在长任务上必退化。建议同时引入工具检索，控制 MCP 工具数过 20 就切检索。 **3. 企业多系统集成（MCP + 多数据源）** 工具定义税是头号杀手。**强制走渐进式工具发现**，绝不把全部工具 Schema 常驻。设定"侦察预算上限"——只读工具调用占比超过 30% 即告警熔断，防止侦察瘫痪。 **4. 成本敏感的批量任务（SWE-bench 类）** 直接借鉴 **SWE-agent 的有界窗口 ACI**：从机制层面禁止"一次读全文"，用 100 行/屏 + scroll 把侦察税压到最低。这是已验证的最低 token/任务比路径。 **5. 垂直行业落地（金融/医疗/法务知识库）** 这类场景的"环境"是文档而非代码，侦察税表现为**检索爆炸**——模型反复 RAG 拉文档却抓不住重点。对策是**两层渐进发现**：先检索"文档地图/目录级摘要"，命中后再拉具体段落，避免把整篇长文档灌进上下文。 --- ## 核心结论 侦察税是自主智能体从 chatbot 升级到 autonomous 时被普遍低估的**结构性成本**：它让 token 消耗暴涨 10–50 倍，并经由上下文膨胀反噬推理质量，形成"越读越笨"的恶性循环。2026 年的成熟解法已经收敛到三条主线——**有界侦察（窗口/ACI）、渐进发现（按需拉取）、主动压缩（GC 式清理）**，以及最具杠杆的一条：**用 `.agents/` 这类环境契约把侦察成本从运行时转移到构建时**。判断一个自主智能体栈是否"生产就绪"，不再只看它解不解决得了问题，而要看它**能不能控制住自己读环境的冲动**。 --- ## 参考来源 1. [AI Agent Cost Benchmarks 2026: What Teams Are Actually Spending](https://tokenfence.dev/blog/ai-agent-cost-benchmarks-2026-real-numbers) — 真实生产部署成本数据，含"50 文件代码库加载进上下文"的 token 测算 2. [How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption (arXiv 2604.22750)](https://arxiv.org/abs/2604.22750) — 智能体 token 消耗的分解建模与预测，揭示 10–50 倍 chatbot 开销来源 3. [Context Bloat: The AI Memory Leak You Cannot Grep For](https://tianpan.co/blog/2026-05-09-context-bloat-ai-memory-leak-cannot-grep-for) — 长程会话 2K→40K 上下文膨胀与 context rot 现象分析 4. [MCP's Context Bloat Crisis: Why Loading 1,000+ Tool Definitions Is…](https://agentmarketcap.ai/blog/2026/04/08/mcp-context-bloat-enterprise-scale-tool-definitions-agent-context-budget) — 企业 MCP 部署 60–80% 上下文预算被工具定义吞噬的实证 5. [Active Context Compression: Autonomous Memory Management in LLM Agents (arXiv 2601.07190)](https://arxiv.org/html/2601.07190v1) — 长程软件工程任务中无关上下文累积导致退化的学术论证 6. [dotagents: A proposed standard for the .agents/ directory](https://github.com/bgreenwell/dotagents) — 以 `.agents/` 目录契约防止上下文膨胀的标准化提案 7. [Taming Autonomous LLM Agents: Infinite Loops and Context Bloat](https://sergioazevedo.me/taming-the-pull-infinite-loops-context-bloat-and-the-blessing-of-free-tiers/) — Push vs Pull 架构与侦察/循环失控的工程视角 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。