一种简单的代理网络访问模式：搜索、获取、浏览，但将原始页面保留在主上下文之外

我见过的大多数代理网络访问设置将三个不同的任务合并为一个模糊的“网络工具”。通常演变成： - 搜索内容 - 获取页面 - 将页面倾倒入主代理上下文 - 希望代理提取有用部分 这种方法可行，但很浪费。问题不仅在于 token 成本，还在于上下文污染。原始页面包含导航栏、Cookie 横幅、脚本、页眉、页脚、分析工具、重复布局以及大量代理无需继续携带的文本。 更清晰的模式是将网络访问分为三个通道： 1. **搜索** 搜索应仅查找候选 URL，不应负责读取完整页面。 良好行为：返回 URL、返回标题/摘要、缓存重复查询、除非必要避免昂贵的扇出。 搜索解答：“我应该看哪里？”它不应将五个完整页面倾倒入主上下文。 2. **获取** 获取应读取已知 URL 并在模型看到之前将其转换为干净的 Markdown。 这是节省上下文最大的地方。在一次测试中，同一页面： - 原始 HTML：9,541 token - 干净 Markdown：1,678 token 在未更改提示或模型的情况下减少了 82%。 规则：除非有特定原因，否则不要将原始 HTML 交给主代理。 获取解答：“这个页面说了什么？” 3. **浏览器** 浏览器自动化应保留给有状态交互。仅在任务确实需要时使用：点击、滚动、登录、填写表单、处理动态 UI、与实时应用交互。 不要仅仅为了阅读普通文档页面而使用浏览器。 浏览器解答：“当我与这个网站交互时会发生什么？” ### 主要界限 最重要的部分不是工具选择，而是读取发生的位置。不要让主代理直接摄取获取的页面，而是在一个封闭的读取器/子代理中运行页面读取。读取器/子代理获取嘈杂的内容，主代理仅获取提炼后的结果： - 答案 - 相关摘录 - 引用/来源 URL - 没有完整页面转储 因此流程变为： ```text 主代理 → 搜索 URL → 获取 URL 为 Markdown → 读取器子代理提取相关片段 → 主代理仅接收干净结果 ```