提示 Agent 优先使用 Playwright 搜索模式

[Ebola-Chan-bot]

此PR主要解决智能体出于性能考虑优先采用request模式的问题。request模式容易触发反爬，导致搜索返回低相关性结果。但是智能体并不知道这件事，不会自动改用playwright模式重试。因此需要将此信息明示写入 MCP search 工具对外可见的描述和参数 schema。

本次提交包括：

• 在 search 工具描述中说明显式指定搜索模式时优先使用 searchMode=playwright
• 解释 request 模式更容易触发反爬并产生低相关度结果，因此通常只应在 Playwright 不可用时使用
• 为 searchMode 参数补充 describe 文案，确保调用 MCP 工具的 Agent 在读取 inputSchema 时也能看到该建议
• 更新 MCP adapter 测试，断言工具描述中包含 Playwright 优先和 request 兜底的说明

这样可以让上游调用方在选择 searchMode 参数时获得更清晰的默认决策依据，减少误用 request 模式导致的低质量搜索结果。

[Copilot]

Pull request overview

该 PR 通过在 MCP search 工具的对外描述与 searchMode 参数 schema 中显式提示“优先使用 Playwright 模式”，来减少上游 Agent 因默认/性能偏好而误用 request 模式导致的反爬触发与低相关性结果问题。

Changes:

• 更新 search 工具描述：明确建议在可用时优先 searchMode=playwright，并说明 request 更易触发反爬、应作为兜底。
• 为 searchMode 的 Zod schema 增加 .describe(...) 文案，让读取 inputSchema 的调用方也能看到同样建议。
• 更新 MCP adapter 测试断言，验证工具描述中包含上述提示。

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/tools/setupTools.ts	在工具 description 与 searchMode 参数 schema 描述中加入 Playwright 优先、request 兜底的说明文案
src/test/test-mcp-adapter.ts	增加断言以确保 search 工具描述包含 Playwright 优先与 request 兜底提示

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Aas-ee]

我理解这个 PR 想解决的问题：希望 Agent 不要因为默认偏向 request 模式，导致 Bing 搜索质量变差或者触发反爬。

不过我现在对这个改动有点保留。searchMode=playwright 的前提是当前环境已经安装并配置好了 Playwright / 浏览器。如果 Agent 有能力确认当前环境 Playwright 可用，那它本身也可以被提示或要求主动使用 searchMode=playwright；

但如果 Agent 无法确认，直接在 MCP tool 描述里强调“优先使用 playwright”，可能会让它在用户环境未安装 Playwright 时主动传searchMode=playwright，反而把原本可用的 auto/request 路径变成失败。

也就是说，这个提示可能会适得其反：它提升了 Playwright 的优先级，但没有同时提供可靠的可用性判断机制。

所以这个 PR 我暂时不打算直接合并。如果你有更具体的场景，能说明为什么把 “优先 playwright” 写进 tool schema 会比让 Agent 根据环境/用户指令选择更好，也欢迎继续讨论。

[Ebola-Chan-bot]

其实我觉得最好的方法是不允许智能体指定用谁，一律以环境变量设置为准。如果用户折腾了半天手动配置了Plawright，我觉得他大概率是不会希望智能体仍然走request（或者单独加一个环境变量，是否允许智能体使用其它请求方案？这种场景我觉得非常罕见，可以等有人提了再说）。这种方案我认为是最能完美匹配用户需求，并且也最省token的。

本PR是一个折中改进，它的确不保证playwright成功，但也说明了如果失败就退回request，这对智能体工作流来说无非就是多费一点token重试一下，不会导致任务失败或结果质量下降。

而我实际遇到的问题是，智能体可能会一直request，从不考虑playwright，并且接受返回低相关性结果。如果用户不持续监视这个过程，仔细检查每次搜索的返回结果，是很难发现问题的，导致任务结果静默下降，这种难以观测的错误我认为是非常致命的。用户如果要纠正这个问题就只能打断任务重新要求智能体必须用playwright，或者写成常驻提示词，无论哪种都会造成token浪费。