2026-05-29 回顾
今天的工作
从昨天开始尝试改进延续的问题，今天找到了可以更好地进行网页搜索的 MCP 工具。
确认的工具是 bing、brave、duckduckgo 浏览器搜索以 MCP 形式提供的 web-search-mcp。
以后会 fork 并根据当前工作流程进行定制。
Qwen 3.6 使用感想
Qwen 3.6 模型的判断比预期更迟钝。
qwen-code 中的 .github 路径的工作流被要求直接同步推送并应用，但实际上它只想把部分文件复制到 .qwen 路径。这是核心问题。
最终只能手动克隆后，将 .github 与 .qwen 路径调整得与原始保持一致后再继续。其实只是“把原始结构保持一致”的问题，但模型把路径和目的混在一起解释，导致不必要的折腾延长。
对 Qwen 本身的洞察
Qwen 并不是没有能力的模型，而是能力存在但可控性较弱的模型。
信息检索、代码修改、文件操作、长任务执行本身都相当出色。问题在于它保持用户意图的持续性较弱。尤其是“直接复制”“不要修改”“不要推理”“只按官方标准”“不要触碰这个路径”等限制条件，往往在工作中被忘记或自行覆盖。
也就是说 Qwen 并不是不能工作，而是会在执行过程中自行重新解释方向。
这次工作的原始问题其实很简单。
官方 .github 完整复制
.qwen 排除
推送
测试不过，Qwen一直把这个问题扩展到其他问题。
MCP 是问题吗？
workflow_call 是问题吗？
需要添加 push 触发器吗？
需要创建 .qwen/commands 吗？
stderr JSON 是问题吗？
empty review 是问题吗？在解决问题之前，实际上已经把问题放大了。在基于代理的 LLM 中，这一点是致命的。任务单元越大，就越会开始解决自己产生的子问题，而不是原始请求。
即使加入网页搜索，这个问题也没有完全解决。好的流程是先查看官方文档或源码，了解结构后，再与用户请求对比，只执行必要的操作。但 Qwen 先进行推理，构建假设，然后进行搜索以验证假设，随后又把搜索结果套回自己的假设中。
因此，网页搜索更像是用于强化假设的工具，而不是基于证据的工作工具。我们发现，处理搜索结果的方式比搜索能力本身更为重要。
对失败状态的解释也很薄弱。例如，git ls-files .qwen/ 的结果为空时，应该立即得出 .qwen 并未被跟踪的结论。但它却不断重复执行 git rm -r --cached .qwen/ 等命令。虽然具备执行命令的能力，却在根据执行结果调整后续行为、解释状态以及跳出循环的能力上不稳定。
此外，Qwen 对“完全按照官方”这类保留工作也很薄弱。它在生成和修改时积极，但在保留原始内容并同步时却不断尝试改进。虽然官方文档没有说明，但它可能会认为需要创建 .qwen，或者因为没有触发器而需要手动添加，或者因为推送时不生效而需要自行执行，这些都会破坏原始结构。
因此，与其让 Qwen “完全复制官方”，不如像下面这样将任务拆分，安全性更高。
官方文件列表输出
我的文件列表输出
差异 diff 输出
仅复制用户批准的文件给 Qwen 过大的自主权也是危险的。文件修改、git add、commit、push、workflow 修改、自动测试后再进行修改等权限，一旦判断错误，就会把这个判断推向执行。
因此，Qwen 的角色应更接近候选生成器、日志摘要器、命令结果解释辅助，而不是工作管理员或最终执行者。
Qwen = 候选生成器 / 日志摘要器 / 命令结果解释辅助
用户或脚本 = 最终执行者结构化输出也要小心。Qwen 并不是完全不会 JSON，但如果让它负责复杂的 schema 或 workflow 状态管理，整体的可靠性会下降。Markdown 评论编写、代码说明、日志摘要、原因候选整理、修订草案生成是可以的。相反，精确的 JSON schema 输出、复杂的 workflow 状态管理、工具调用顺序管理、GitHub API 操作、文件路径保留、commit/push 判断则不适合。
综上所述，Qwen 作为生成器还算可以，但作为编排器则不够稳定。
关键就在这一行。
Qwen 是一个聪明的生成模型，但作为可靠的任务管理者或自动化代理使用时，其可控性、状态解释和指令保留能力较弱。
实际结论如下。
Qwen可以让它思考。
Qwen可以负责草案。
不要让 Qwen 操作最终的仓库。如果以后继续使用 Qwen，运营原则最好这样设定。
禁止自主操作
一次只能执行一个命令
在修改前输出 diff
禁止 commit/push
官方原始保存工作需经人工批准
LLM 输出仅用于 Markdown/text在网页搜索 MCP 中的感受
将网页搜索加入后，搜索性能相较于原来的网页抓取方式明显提升。寻找所需资料的速度和搜索范围都变好了，收集候选链接也更有帮助。
但也出现了对通过网页搜索获得的信息进行奇怪解释的倾向。虽然搜索能力很强，但将搜索结果判断为代码工作上下文的能力仍不稳定。
因此，我感觉将编码 LLM 与搜索 LLM 分离可能更好。把搜索交给擅长搜索的模型或工具，而把编码判断单独验证的结构会更稳妥。
反思
今天的部分埋头苦干其实是已经知道答案的简单问题。
只需要把 .github 和 .qwen 与原始保持一致，但在模型的中间尝试中被带偏，使问题看得更复杂。以后要先确认模型给出的工作结果是否符合需求的结构，再在初期通过 diff 直接验证路径/文件层面的同步工作。
尤其需要养成先确认“是否复制了正确的内容”，再确认“原始与目标是否形成相同结构”的习惯。
工作中断问题
今天下午 2 点以后，网络中断导致 RunPod 上运行的 Qwen 服务器宕机。此后模型调用不可用，工作难以继续。
本地的工作和整理还能进行，但基于 Qwen 服务器的自动评审/搜索/验证流程高度依赖网络状态，这一点再次得到确认。
接下来的行动
- Fork
web-search-mcp，自定义所需的搜索引擎和输出格式。 - 为了减少 Qwen 解释网页搜索结果时产生的错误，将搜索结果摘要与编码判断阶段分离。
- 对
.github、.qwen等目录结构同步重要的工作，首先以diff为基准进行验证。 - 不要直接给 Qwen 赋予仓库操作权限，而是一次只执行单条指令并检查 diff。
- Qwen 的输出先以 Markdown/text 草稿形式获取，JSON schema 或 GitHub API 编排交由脚本或人工处理。
- 为 RunPod Qwen 服务器故障准备 fallback 模型或本地确认流程。