# Coding Agent 的常见误区 (/docs/common-misconceptions)



## 上下文污染（Context Poisoning） [#上下文污染context-poisoning]

**常见误区**

* **以为"规则越多越好"**：把各语言编码规范、依赖库使用说明等统统塞进上下文。
* **以为"AGENTS.md 越详细越好"**：把各模块实现细节、注意事项全部写进 AGENTS.md / CLAUDE.md。
* **在单次对话里灌大量文件和日志**：一次性粘贴大段 log、配置、代码，希望模型"全都记住"。
* **在一个会话里无限叠加功能**：担心开启新会话后 Agent 不再了解项目背景，于是所有事都往一个 session 里堆。

这些做法直接导致的结果是：上下文被打满或长期处于接近上限的状态。

**核心结论（有点反直觉）**

* 上下文占用**不是越多越好**，塞入的内容越多，并不等于 Agent 越了解你的项目。
* 过大的上下文会让模型的**推理质量明显下降**，表现为答非所问、抓不住重点等。
* 模型存在"上下文召回率"问题：并不是所有放进去的内容都会被有效利用，被"看见"和被"用上"只是部分。

**相关文章：**

* [Augment Blog | Your agent's context is a junk drawer](https://www.augmentcode.com/blog/your-agents-context-is-a-junk-drawer)
* [Fiction liveBench April 29 2025](https://fiction.live/stories/Fiction-liveBench-April-29-2025/oQdzQvKHw8JyXbN87)

![](https://r2.unono.app/2026/05/f416781fe310cfab2567ae722450b6e0.png)

***

## 误信「超级 IDE 插件」是银弹 [#误信超级-ide-插件是银弹]

**代表工具**: super claude、superpowers、oh-my-opencode，以及各种号称「一键扫仓库」「自动改代码」的 Coding Agent 插件。

**常见误区**

* 以为「装上插件 = 多了个高级 AI 搭档」，可以不做需求拆解和设计。
* 把「全仓库扫描」「一键重构」当成银弹，期待它像资深架构师一样一针见血。
* 默认接受长篇大论回答，把啰嗦解释误当成「全面、专业」。

**实际情况**

* 本质还是「聊天 + 代码索引」，上限由模型本身、索引质量和你的提问方式共同决定，**远不是银弹**。
* 默认输出往往很啰嗦：重复项目背景、解释常识、给一堆模糊建议。
* 仓库一大、约束一弱，就容易「泛泛而谈」——看起来很聪明，落地价值却不高。

**额外风险：System Prompt / Prompt Cache 被插件污染**

* 部分实现粗糙的插件（典型如 oh-my-opencode 这一类草台班子）会把「当前时间」「随机标识」甚至无关环境信息塞进 system prompt。
* 这些字段看似无害，实际上会导致 **Prompt Cache 频繁失效**：
  * 每次调用的 prompt 都略有不同（时间戳、UUID 等），缓存命中率接近 0。
  * 模型费用大幅上涨：同一类请求反复全量计费，完全吃不到缓存红利。
  * 响应时间明显变慢：本来可以从缓存秒回的请求，被迫每次都重新推理。
* 叠加前面说的上下文污染问题，结果就是：贵、慢、还啰嗦。

> [oh-my-openagent commit - 50112b9](https://github.com/code-yeongyu/oh-my-openagent/commit/50112b97eacea074376978748d1f5b853feb83cf)

![](https://r2.unono.app/2026/05/c6d889193117b46c7c028cf299ba3cfe.png)

**正确姿势：用好内置的 plan → build 流程**

* Claude Code / OpenCode / Codex 等主流 Coding Agent 的 **plan mode 本身就是精心调教过的**。
* 在大多数功能迭代场景里，遵循「先 Plan 再 Build」的标准流程，已经足够：
  * 先用 plan 模式收敛需求、列出改动点、拆分步骤。
  * 再按计划逐步生成代码，对单个文件或小范围改动进行验证。
* 相比把希望寄托在「超级插件能一口吃掉全仓库」上，**有意识地驱动 plan → build 流程，更可靠也更可控**。

**使用建议**

* 把超级插件当作「快捷入口 + 重复劳动加速器」，而不是替你做架构决策的上帝视角。
* 尽量了解插件的 prompt / 权限策略，避免被不透明的 system prompt 暗中带偏，尤其是要警惕那些每次都往 prompt 里塞时间戳、随机 token 的实现。
* 一旦发现回答异常啰嗦、费用异常上涨或响应明显变慢，优先排查：是不是插件在暗改上下文、导致 Prompt Cache 失效，而不是一味怪「模型不行」。

***

## 误判「Haiku 这种小模型都是垃圾」 [#误判haiku-这种小模型都是垃圾]

**常见误区**

* 觉得"小模型= 智商低"，只要是 Agent 就必须上 Opus / GPT-5.4 这种超大杯大模型。
* 在一个 Agent 里既做探索、又做规划、又写代码，所有检索结果、文档、日志一股脑丢进 Main Agent 的 Context。
* 把「推理质量差」简单归因于"小模型不行"，而不是反思：是不是让它在一堆垃圾 Context 里工作。

**实际情况**

* 在 AI Agent 的探索阶段，如果直接让 Main Agent 去「到处乱翻」，很容易把大量**无关信息**一起塞进它的上下文，后续每一步推理都在「垃圾堆里找答案」，效果只会越来越差。
* 正确的做法是引入一个专门的 **explore subagent**：只负责「去各处探索 → 过滤噪音 → 收敛出一小块高价值 Context」，再把这块精炼后的上下文交给 Main Agent 做严肃推理。
* 在这个阶段，**Haiku 这类小模型反而非常适合**：
  * 推理速度快，可以高频试错、快速遍历多种检索路线和问题拆解方式。
  * 费用极低，可以大胆多开几个 explore subagent 做并行探索，而不用心疼 token。
  * 任务本身偏「筛选、归纳、剔除垃圾」，对极致推理深度的要求没那么高。

**核心结论**

* 不是「Haiku 这种小模型是垃圾，狗都不用」，而是**用错了模型的角色**。
* 把 Haiku 放在 explore subagent 上做「广度探索 + 垃圾过滤」，再把干净的高价值 Context 交给 Opus / GPT-5.4 之类的大模型去深度推理，整体效果通常会比「全程一把梭大模型」更好、更便宜也更快。
* 真正的误区不是"小模型不行"，而是**所有事情都丢给 Main Agent 和大模型做，既耗费上下文预算，又浪费钱**。

***

免责声明(有问题就让 AI 背锅)：以上内容由人类提出想法，AI 员工(Dia Browser)帮忙整理成文。