做了一年多 AI Agent 开发，我逐渐形成了一个核心观点：让 Agent 更准确更高质量地完成任务，最关键的不是换一个更强的模型，而是给它一个正确的执行环境。
具体来说，这个"正确的执行环境"包含四个要素：干净的执行环境、充足且正确的上下文、允许自我探索的空间、以及学会使用工具解决问题的能力。
一个类比：为什么同一个人在不同环境里表现截然不同
想象你让一个能力很强的员工去完成一项任务。但是：
- 你给了他一张堆满杂物的桌子（环境混乱）
- 任务说明书只有半页，关键信息缺失（上下文不足）
- 你要求他每一步都必须请示你才能继续（没有探索空间）
- 他只有一支笔，而任务需要计算器、尺子和电脑（缺乏工具）
结果可想而知。不是他能力不行，是你没给他把事做好的条件。
AI Agent 的情况一模一样。同一个 Claude Opus 4.6，在不同的环境配置下，任务完成质量可以天差地别。模型能力是地基，但环境设计才是决定建筑高度的上层结构。
第一根支柱：干净的执行环境
问题：噪声会杀死准确率
大模型的注意力机制决定了它会对上下文中的所有信息分配注意力权重。当你的执行环境"脏"了——充斥着无关信息、历史残留、冲突的指令——模型的注意力就会被稀释，推理质量随之下降。
我在实践中见过最常见的"脏环境"问题：
典型的脏环境：
├── System Prompt 中塞了 50 个工具的描述（大部分用不到）
├── 对话历史累积了 30 轮无关的闲聊
├── 上下文中有过时的错误信息没有被清除
├── 多个来源的指令相互矛盾
└── 历史工具调用的完整输出（包括大量不需要的中间结果）全部保留
解法：最小化噪声，最大化信噪比
只加载当前任务需要的工具。如果任务是写代码，不要同时加载邮件工具、日历工具、部署工具。工具列表越长，模型选错工具的概率越高。在之前的文章中我提到，工具数量和参数复杂度直接影响 Tool Use 准确率。环境的干净程度也是同理。
及时压缩和清理上下文。对话历史不是越长越好。旧的、不再相关的对话轮次应该被压缩或丢弃。OpenClaw 的 compaction 机制就是这个思路——在压缩前把重要信息写入持久记忆，然后放心地丢弃旧上下文。
隔离不同任务的执行环境。每个任务应该在一个干净的沙盒中运行。Claude Code 的 worktree 机制就是一个好例子——每个任务在独立的 Git worktree 中执行，不会被其他任务的文件变更干扰。
干净的环境：
├── 只有本任务相关的 3-5 个工具
├── 精简的对话历史（只保留相关轮次）
├── 明确无矛盾的指令
├── 隔离的文件系统空间
└── 中间结果已被筛选和精炼
这就像给员工一张整洁的桌子，上面只放当前任务需要的东西。效率立刻提升。
第二根支柱：充足且正确的上下文
问题：模型不知道的事情，再聪明也做不出来
这是一个看似显而易见但经常被忽略的事实：LLM 的推理质量上限由输入信息决定。模型不会凭空创造它不知道的事实。如果你让 Agent 修一个 bug 但没给它看相关的代码文件，或者让它写一篇技术文档但没提供系统架构信息，结果只能是猜测和幻觉。
“充足"和"正确"同样重要：
- 充足：关键信息不能缺失。该给的代码、文档、配置、历史决策记录，都得给到位
- 正确：过时的文档比没有文档更危险。如果上下文中包含错误信息，模型会基于错误信息做推理，产出的结果可能看起来很"自信"但完全跑偏
解法：精准投喂，不多不少
主动检索而不是被动堆砌。与其把所有可能相关的文档塞进上下文，不如让 Agent 主动检索它需要的信息。好的 Agent 框架会提供文件搜索、代码搜索等工具，让 Agent 按需拉取上下文。
以 Claude Code 为例，它的工作流程是：
收到任务 → 先用 Glob/Grep 搜索相关文件 → 用 Read 工具读取必要文件
→ 理解代码结构后再动手修改
而不是把整个代码仓库一股脑塞进去。这种"先理解，再行动"的模式，本质上就是让 Agent 自己构建充足且精准的上下文。
CLAUDE.md / MEMORY.md 是上下文的锚点。项目级别的 CLAUDE.md 提供了稳定的项目上下文——架构约定、代码规范、关键路径。这些信息不会随对话变化，是 Agent 每次执行任务时的基础认知。OpenClaw 的 MEMORY.md 则提供了个性化的长期记忆，让 Agent 记住你的偏好和历史决策。
区分"需要知道"和"有用但不急”。并非所有上下文都同等重要。核心的应该直接放在 System Prompt 或对话开头；辅助的可以通过工具按需检索；不相关的则坚决不放。
上下文分层：
┌─────────────────────────────────────┐
│ 第一层：System Prompt / CLAUDE.md │ ← 始终存在，项目级别常识
├─────────────────────────────────────┤
│ 第二层：任务相关的具体文件/代码 │ ← Agent 主动检索后加载
├─────────────────────────────────────┤
│ 第三层：历史记忆和偏好 │ ← MEMORY.md + memory_search
├─────────────────────────────────────┤
│ 第四层：按需的外部知识 │ ← Web 搜索、文档查询等
└─────────────────────────────────────┘
第三根支柱：允许 Agent 自我探索
问题：过度约束会扼杀智能
有一种常见的 Agent 设计误区：为了"可控"，把 Agent 的每一步都锁死。每次只能调一个工具，调完必须汇报，收到确认才能继续。
这种设计的初衷是安全，但代价巨大。它把一个有推理能力的智能体降格成了一个需要逐步指令的脚本执行器。就像你请了一个高级工程师，但要求他写每一行代码之前都要请你审批——他的能力被流程完全封印了。
解法：给自由但设护栏
正确的做法是：给 Agent 足够的探索空间，同时在关键节点设置不可逾越的护栏。
Claude Code 的设计是一个典范。它允许 Agent 自由地：
- 搜索和阅读代码（探索性操作，零风险）
- 编辑文件和运行测试（可逆操作，低风险）
- 在沙盒中执行命令（受限操作，可控风险）
但在关键节点需要确认：
- 推送代码到远端
- 执行不可逆的破坏性操作
- 影响共享状态的变更
探索自由度的设计光谱：
完全锁死 完全放开
(每步审批) (无任何限制)
│ │
│ ┌──────────────────────┐ │
│ │ Claude Code 的设计 │ │
│ │ 读/搜索：自由 │ │
│ │ 编辑/测试：自动 │ │
│ │ 推送/删除：需确认 │ │
│ └──────────────────────┘ │
│ ↑ 最佳平衡点 │
允许试错和自我修正。好的 Agent 应该能在发现错误时自主调整方向。当一次搜索没有找到想要的结果时，Agent 应该能换个关键词再搜；当一次代码修改导致测试失败时，Agent 应该能分析错误信息并修复，而不是立刻停下来等待人类介入。
在之前关于 Claude Code 的文章中，我详细分析过 Claude Code 的自动纠错循环——写代码、跑测试、看错误、修代码、再跑测试——这个循环可以自动运行多次直到通过。这种"允许犯错但能自我修正"的设计，远比"不允许犯错"更有效。
子 Agent 模式扩展探索空间。对于复杂任务，可以让 Agent 创建子 Agent 并行探索不同方向。子 Agent 在独立的上下文中运行，避免主 Agent 的上下文被探索过程中的噪声污染。探索完成后，只把有价值的结果汇总给主 Agent。
第四根支柱：学会使用工具解决问题
问题：裸模型的能力天花板
LLM 本质上是一个语言模型——它的原生能力是生成文本。但现实世界的任务需要的远不止文本生成：需要读文件、搜索代码、执行命令、查数据库、调 API。没有工具的 Agent 就像一个只会说不会做的顾问。
更重要的是，工具不仅扩展了 Agent 的能力边界，还提供了与真实世界交互的反馈回路。Agent 可以执行一个操作、观察结果、调整策略——这个"行动-观察-思考"循环是 Agent 真正"做事"而非"说事"的基础。
解法：让 Agent 在实践中学会用工具
工具设计要对 Agent 友好。这一点在我之前的文章中反复强调：工具接口要简单、参数要扁平、描述要清晰。一个 Agent 友好的工具，模型调用准确率可以达到 99%；一个反人类的工具接口，准确率可能跌到 80% 以下。
提供丰富但不过量的工具集。既要给 Agent 足够的能力覆盖任务需求，又不能给太多以至于选择困难。一般来说，5-15 个核心工具覆盖一个领域的大部分需求。
从基础工具到组合使用。最强大的 Agent 行为往往不是单次工具调用，而是多个工具的编排组合。就像上一篇文章讨论的 PTC 一样，Agent 可以用代码把基础工具组合成更复杂的操作。这要求基础工具被设计成可组合的构建块。
工具能力的进化路径：
Level 1: 单工具调用（搜索一次，返回结果）
Level 2: 顺序编排（搜索 → 读取 → 分析）
Level 3: 条件分支（搜索结果不够 → 换关键词 → 重新搜索）
Level 4: 程序化编排（PTC：写代码组合工具，中间结果不回模型上下文）
Level 5: 自造工具（根据需要动态创建新工具）
真正优秀的 Agent 系统会让 Agent 在这些层级之间自如切换，根据任务复杂度选择最合适的工具使用模式。
四根支柱的协同效应
这四个要素不是独立的，它们之间有强烈的协同效应：
┌───────────────┐
│ 干净的环境 │
│ （减少噪声干扰） │
└───────┬───────┘
│
提高上下文的信噪比
│
┌───────▼───────┐
│ 充足的上下文 │
│ （提供正确信息） │
└───────┬───────┘
│
让探索更有方向性
│
┌───────▼───────┐
│ 探索空间 │
│ （允许自我调整） │
└───────┬───────┘
│
通过工具获得真实反馈
│
┌───────▼───────┐
│ 工具能力 │
│ （连接真实世界） │
└───────────────┘
- 干净的环境让上下文的信噪比更高，Agent 能更准确地从上下文中提取有用信息
- 充足的上下文让 Agent 的探索更有方向性，不会在黑暗中盲目摸索
- 探索空间让 Agent 能充分利用工具进行试错和迭代
- 工具能力为 Agent 提供了与环境交互的手段，让探索产生真实的反馈
缺少任何一根支柱，整个系统都会显著退化。没有干净的环境，再多的上下文也会被噪声淹没；没有探索空间，再好的工具也只能按固定脚本执行；没有工具能力，再大的探索空间也只是在做思想实验。
实践检查清单
如果你正在构建或优化一个 Agent 系统，可以用下面这个清单做自检：
环境干净度
- 当前任务是否只加载了必要的工具？
- 上下文中是否存在过时或矛盾的信息？
- 不同任务是否在隔离的环境中执行？
上下文充足度
- Agent 是否有获取任务相关信息的途径？
- 项目常识是否以 CLAUDE.md 等形式持久化？
- 历史决策和偏好是否被记忆系统保留？
探索自由度
- Agent 是否能自主进行搜索和阅读操作？
- Agent 犯错后是否能自主修正？
- 破坏性操作是否有适当的确认机制？
工具完备度
- Agent 是否有覆盖任务需求的工具集？
- 工具接口是否足够简单（扁平参数、清晰描述）？
- 工具是否支持组合使用？
结论
回到最开始的观点：让 Agent 更准确更高质量地完成任务，关键不在模型，而在环境。
这不是说模型不重要。模型的基础能力决定了下限——一个太弱的模型在再好的环境中也做不了复杂任务。但在今天主流模型（Claude Opus 4.6、GPT-4.5 等）的能力水平下，环境设计是更大的杠杆。
同一个模型，在一个嘈杂的环境中可能表现平平，在一个精心设计的环境中却能交出惊艳的结果。这就像同一个棋手，在一个安静的对弈室里和在一个嘈杂的菜市场里，下棋的水平是不一样的。
给 Agent 一个干净的执行环境，提供充足且正确的上下文，允许它自我探索和试错，让它学会使用工具解决问题——做到这四点，你就已经释放了当前模型能力的 80%。剩下的 20%，等下一代模型来解决。