一份关于用 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 和实用工程的交叉处做工具。博客：lennney.com。项目主页：GitHub / npm。