我给 GPT‑5.6 Sol 一个 2500 行的项目，让它全重构。261 个文件后……

一份关于用 GPT‑5.6 Sol 重写生产级 MCP 项目的实录。不是 benchmark，不是测评。就是我有 2500 行 TypeScript 和一个能打的模型，然后发生了这些事。

我没想到能这么好用

我维护了一个开源项目叫 Agent Search MCP——给 AI Agent 用的搜索路由器。十二个引擎适配器、零强制 API Key、MCP 协议。挺实用的，但代码是六个月里自然生长出来的。错误处理随缘、入口文件啥都干、每次加新引擎就是复制粘贴一模一样的 HTTP 模板。

我一直想整理。但重写一个正在用的项目很难说服自己——你会搞坏正常工作的东西、花好几周、用户根本不关心你的抽象层。

后来我拿到了 GPT‑5.6 Sol。

我没让它加功能。我让它重构整个项目：统一引擎接口、提取公共基础设施、修类型、补测试、别搞坏现有工具。Sol 上下文里塞了整个代码库——源码、测试、文档、全都有。

回来的东西是我审过的最大的 PR：261 个文件变更、29,186 行增、14,289 行删。

下面是我学到的东西。

Sol 真正让我吃惊的地方

1. 它看见的是架构，不是代码

旧的 src/index.ts 120 行，什么都干——创建 server、注册工具、搭 HTTP、解析 CLI 参数。每个项目都有这个文件，每个开发者都知道该拆开。但没人拆因为"能用"。

Sol 把它拆成了五个职责清晰的文件：

文件	职责
`src/index.ts`	仅入口——选模式、启动传输层
`src/server.ts`	工厂函数——构建已配置的 `McpServer` 实例
`src/tools/registry.ts`	统一工具注册——一次调用一个工具
`src/infrastructure/config.ts`	配置加载、环境变量解析、校验
`src/infrastructure/protocol.ts`	MCP 协议层辅助函数

这个结构我想了几个月。Sol 一遍写完了。

2. 它真的懂 TypeScript 类型

之前搜索 provider 类型是手写联合类型：

type SearchProvider = 'duckduckgo' | 'sogou' | 'brave' | ...

加引擎没问题，但要同时更新五个下游类型守卫。

Sol 改成了 const 数组 + 推导类型：

const SEARCH_PROVIDERS = ['duckduckgo', 'sogou', …, 'serper'] as const;
type SearchProvider = typeof SEARCH_PROVIDERS[number];

单一数据源。所有引擎适配器、工具注册、fallback 链都从同一个地方读。加 Wiby、Bocha、Serper、腾讯搜索就是往数组里加四个字符串。

3. 它自己设计了一套错误分类体系

旧代码到处抛泛泛的 Error('timeout') 或 Error('HTTP 429')。新代码有一个结构化错误类，10 种失败类型：

class EngineAdapterError extends Error {
  readonly failureType: 'validation_error' | 'parse_error' | 'timeout' 
    | 'upstream_4xx' | 'upstream_5xx' | 'rate_limited' 
    | 'bot_challenge' | 'permission_denied' | 'budget_exhausted' | 'unknown';
  readonly retryable: boolean;
  readonly cooldownMs?: number;
  readonly suggestion: string;
}

每个适配器现在返回结构化错误。编排器知道哪些可以重试、哪些引擎应该冷却（搜狗 CAPTCHA 页面冷却 60 分钟）、返回什么建议给 AI Agent。这些不是我给的 prompt 里写的——Sol 从代码使用模式里推理出来的。

4. 它给所有东西都写了测试

测试文件从 44 个涨到 73 个——66% 的增长。不只是新基础设施的单元测试，是每个引擎独立一个测试文件：

之前: tests/engines.test.ts  (单片文件，测 2-3 个引擎)
之后: tests/engines/  (21 个文件，每个引擎独立)

基准评测框架完全是新的——9 个文件覆盖 pooled comparison、quality metrics、runner qualification、relevance calibration。Sol 把它设计成 capture/replay 管线，结果可重现。

5. 它删代码没有感情

54 个文件被删。过时的计划、没用的 Python 脚本、过期文档、一个从没稳定工作过的新闻搜索工具、一个声明了但从未调用的 dedupByProvider() 函数。

大部分模型不愿意删代码。Sol 不是。它识别死代码、干净地标记废弃、然后删文件。光这一点就让项目认知负荷大幅下降。

Sol 翻车的地方

不是魔法。有几件事需要我来修：

问题	发生了什么
网络依赖的测试	Sol 写了实时网络的集成测试，在自己那能跑，进 CI 就挂。我必须加环境变量门禁。
Hono 告警噪音	它正确解析了已修补的 `@hono/node-server` 1.19.15，但 npm audit 的过期元数据仍然标记漏洞。Sol 没发现元数据偏差和实际攻击面的区别。
Bing News RSS	Sol 建议保留新闻工具用 Bing News RSS。我测试后删了——Bing News RSS 就是不可靠。有些事需要真实世界验证。
stdout 里的 console.log	一条断路器消息最初被路由到 stdout（破坏 MCP JSON-RPC）。指出后 Sol 修了，但这是经典的"模型没想协议边界"错误。

结论：Sol 处理代码结构很出色。它搞不定需要真实网络测试和协议层面安全的运行时行为。

数字说话

指标	v3.1（之前）	v3.2（之后）	变化
源文件 (src/)	49	72	+47%
测试文件	44	73	+66%
测试通过数	~510	742	+45%
引擎适配器	14	21	+7
基础设施模块	12	22	+83%
Python 运行时依赖	可选 (ddgs)	零	已移除
死文件	—	54 个已删	清理
npm 周下载	~650	~1,950	3×

不是每个指标都往"更好"的方向走。源文件更多不是自动变好。但结构性质量——类型安全、测试覆盖、错误处理——确实提升了。

这对 AI 辅助编码意味着什么

一个数据点，不是结论。

Sol 擅长的：

跨文件一致性——261 个文件没有一个类型断裂。人类一次过做这个真的很难。
架构提取——从运行中的代码库找到正确的抽象边界。
规模化测试生成——不只是覆盖 happy path，而是搭建一整套基准框架。
删除代码——比大部分模型更果断，比人类更不恋旧。

仍然需要人类的：

真实网络条件的运行时测试。
协议级别的安全性（stdio、HTTP 边界）。
伪装成技术选择的产品决策（"这个功能该不该留？"）。

Agent Search MCP v3.2 今天带着这些改进上线：

$ pnpm dlx agent-search-mcp

不需要 API Key。八台免费搜索引擎。Provider Routing 模式控制成本。以及一个不会突然坑你的类型系统。

我是 lennney，一个产品思维驱动的 AI 工程师。在 AI Agent 和实用工程的交叉处做工具。博客：take-a-deep-breath0.com。项目主页：GitHub / npm。