给开源模型加「修复层」：DeepSeek也能超越Claude Opus

一个被误解的问题：不是模型不行，是工具调用出了错

在最新一期 AI 前沿访谈中，独立开发者、连续开源贡献者 Ahmad Awais（旗下产品 Command Code）分享了一个反直觉的洞察：很多人抱怨开源大模型"不听话、又慢又笨"，但真正的元凶往往不是模型能力，而是**工具调用（Tool Calling）**层面的系统性缺陷。

工具调用是现代大语言模型从"对话系统"进化为"自主Agent"的关键跨越。从技术演进角度看，这一能力的实现并非简单的提示词工程，而是依赖模型在预训练和微调阶段学习到的「停止生成→构造调用→等待结果→继续生成」的元能力——这是一种需要专门训练数据才能稳定涌现的复合技能。在技术实现层面，工具调用通常以JSON Schema的形式定义每个可调用函数的名称、参数类型和描述，模型在推理时决定是否调用某个工具，并以结构化JSON输出调用参数。它允许LLM在对话过程中"暂停"生成，调用预定义的外部函数（如文件系统操作、网络请求、代码执行），再将结果纳入上下文继续推理。OpenAI在2023年6月率先在GPT-3.5/4中引入Function Calling标准，随后Anthropic（Claude的Tool Use）、Google（Gemini的Function Calling）等相继跟进，但各家实现细节存在差异，形成了事实上的碎片化生态。

值得注意的是，这种碎片化不只是API格式的差异——它深入到模型训练层面。OpenAI的Function Calling使用tool_calls字段包裹JSON参数；Anthropic的Tool Use则采用XML风格的<tool_use>标签；而许多开源模型在微调时往往参考了多个闭源模型的数据，导致输出格式存在混合特征，在边界情况下容易产生格式错乱。工具调用的可靠性直接决定了Agent的实用价值——一个无法稳定调用工具的Agent，无论底层模型多强大，在实际工作流中都会频繁"卡死"。

Ahmad 的背景颇具分量——他在 WordPress 核心社区活跃了 13 年，曾任 RapidAPI 的 DevRel VP，2020 年 7 月就拿到了 GPT-3 的早期访问权限（比 GitHub Copilot 早了一年多），并发布过 300 多个开源项目。正是基于每天处理数十亿 token 的真实推理数据，他发现了一个他称之为**"工具混乱"（Tool Confusion）**的确定性模式。

"我发现了为什么 DeepSeek 能够超越 Claude Opus——问题从来不在模型本身。"

这个发现的价值在于：它可以被确定性地修复，而且方法完全开源，任何编码 Agent 框架都能直接采用。

什么是"工具混乱"？

DeepSeek 的"钢铁直男"性格

Ahmad 用一个生动的比喻描述了 DeepSeek V4 Pro 的行为特征：它有一种"alpha male（雄性支配）能量"——它坚信自己发出的一切都是正确的。

当模型发起工具调用时（比如列出目录、读取文件、执行 shell 命令），如果它发送了错误的参数 schema，系统会返回一个 Zod 校验错误。按理说，一个足够聪明的 LLM 应该读懂错误并修正。但 DeepSeek 不会——它会固执地重复同样的错误调用，平均在十亿 token 中会出现 6 次这样的死循环，每次卡住约 50 秒。

这里值得解释一下 Zod 的角色：Zod 是 JavaScript/TypeScript 生态中最流行的运行时数据校验库，广泛用于验证 LLM 输出的结构化数据是否符合预期 Schema。在 Agent 框架中，开发者通常用 Zod 定义每个工具的参数格式（如"path 必须是字符串、offset 必须是数字"），当模型传入不符合规范的参数时，Zod 会抛出详细的错误信息。然而，将原始 Zod 错误直接返回给模型往往效果不佳——错误信息的格式对人类工程师友好，却未必符合模型的"思维习惯"。Ahmad 的修复层本质上是在 Zod 错误与模型之间增加了一个翻译加容错层。

Ahmad 推测这背后的原因很微妙：许多开源模型是从"更强的模型"蒸馏训练而来。这一训练范式带来了一个鲜少被讨论的系统性问题：训练数据的分布偏移。知识蒸馏（Knowledge Distillation）最初由 Hinton 等人在2015年提出，其核心思想是让小型"学生模型"模仿大型"教师模型"的输出分布（软标签），而非直接从原始标注数据学习。在当前主流实践中，开发者收集GPT-4、Claude等闭源模型的输出作为「偏好数据」，通过RLHF（人类反馈强化学习）或DPO（直接偏好优化）进行对齐训练。这种方式虽然高效，却埋下了一个隐患：当开源模型大量学习闭源模型的「成功输出」时，实际上是在学习一个经过高度过滤的、几乎不包含失败和纠错过程的数据分布——教师模型的输出本身极少包含「我犯了错误并自我纠正」的示例，闭源模型在内部已做了大量错误过滤，展示给外界的永远是最终的「正确」结果。学生模型因此学到的隐性信念是「强模型不犯错」，进而泛化为「我也不应该犯错」，在遇到校验失败时选择重复而非修正。这与真实推理场景中必然出现的错误和迭代过程存在根本性差异，也正是DeepSeek等开源模型在工具调用错误时不愿自我纠正的深层原因——训练范式告诉它们"你被告知的一切都是对的"，于是模型形成了"我说的也都是对的、别纠正我"的固有性格。

隐藏在 Claude Code 背后的陷阱

更糟的是，许多开发者会 hack Claude Code——直接替换 base API endpoint 和 API key，用它来跑开源模型。但 Claude Code 把大量错误藏在了 Ctrl+O 后面，用户根本看不到一次会话里发生了 50 多次工具调用失败。于是大家只感觉到"DeepSeek 好慢"，却不知道慢在哪里。

"这符合他们的既得利益，" Ahmad 直言，"Claude Code 从来不是为开源模型设计的。"

"修复层"是如何工作的

先救人，再讲道理

Ahmad 的解决方案是引入一套修复逻辑（Repair Logic）。他把它类比成数据库迁移文件——每一种错误模式对应一个修复文件。最初只有 3200 行、涵盖 4 种修复，如今已经积累了 16000 多种修复变体，覆盖数千亿 token 的失败数据。

这套修复层的工程哲学，与软件工程中的经典容错设计一脉相承——类似于TCP协议在不可靠的IP层之上构建可靠传输，或编译器的错误恢复机制（error recovery）允许在遇到语法错误后继续解析后续代码。它体现了「防御性编程」与「渐进式容错」思想的现代AI化应用：传统软件中，我们通过try-catch、重试机制、断路器模式等手段处理不确定性；在LLM Agent场景中，修复层扮演了类似「智能断路器」的角色，但其独特之处在于它不仅处理了当前错误，还通过上下文注入完成了对模型后续行为的隐性校正。大多数Agent框架（LangChain、AutoGen等）直接将工具错误抛回给模型，依赖模型自身的「智能」来理解并修复——但这恰恰是对模型训练盲点的错误假设。修复层的核心机制非常巧妙：当模型发送了错误格式的数据（比如本该是数组却发了 JSON 字符串，或本该是数组却发了空对象/null），系统不会简单地把错误抛回去，而是：

1. 先确定性地修复——把错误数据转换成正确格式，直接返回结果；
2. 再附上一条修复提示（Repair Hint）——告诉模型"你本该发这种格式的数据，但结果我已经帮你处理好了"。

「先修复再提示」策略的精妙之处在于：它将「正确示范」嵌入到上下文中，利用模型强大的in-context learning能力来完成行为校正，从而绕开了训练层面固有的「过度自信」偏差。Ahmad 用了一个绝妙的比喻："就像教人开车，当他即将撞上另一辆车时，你会先救他一命，再解释他刚才应该怎么做。"

效果立竿见影：一旦返回结果附上修复提示，第三次工具调用往往就自动修复了，模型突然"变聪明"，理解了自己该做什么。

智能判断的补全

修复层还能做智能推断。比如模型要读取文件却没提供偏移量（读前 100 行还是后 100 行？），系统会主动判断："这是第一次读，先给它前 100 行"，模型很快会意识到"哦我其实需要日志文件的最后 100 行"，从而避免那 50 多次的失败循环。

从单一模型到通用规律

最初 Ahmad 以为这只是 DeepSeek 的问题。但翻查过去 30 天的日志后，他发现 Kimi 模型完全在做同样的事，随后又修复了 MiniMax 模型。这说明"工具混乱"是开源模型的普遍规律，而非个案——其根源可能正是蒸馏训练范式在整个开源模型社区的广泛应用所带来的系统性偏差。从更宏观的视角看，这一现象揭示了AI工程中一个重要的层次问题：当训练数据本身存在「过度自信」的分布偏移时，修复必须发生在推理时的中间件层，而非等待下一轮模型训练——因为重新训练成本高昂且周期漫长，而推理时的修复层可以随时迭代、立即生效。

修复的威力有多大？Ahmad 举例：原本几乎完全不可用的 DeepSeek V4 Flash，经过修复后可以直接与旗舰模型竞争。投资人、GitHub 创始人 Tom Preston-Werner 甚至专门发问："你到底做了什么？为什么 DeepSeek V4 Flash 突然这么稳？"

更有意思的是权限模式的隐性影响：当你开启权限确认（每次都要 yes/yes/yes）时，模型反而更"笨"；而完全 bypass 权限时，模型探索更自由、创造力更强、能持续运行更久。有一位用户在 Command Code 上跑 DeepSeek 单次会话长达 12 小时以上，累计消耗 700 亿 token——正是因为工具错误极少，模型才能持续深入。

同一套哲学：修复"设计废料"

从工具调用到 Design Slop

Ahmad 最令人惊喜的发现是：这套"确定性修复"哲学可以迁移到设计领域。所有 LLM 都有一种"设计废料（Design Slop）"倾向——最典型的就是那种"靛蓝紫渐变"配色（他特意强调是 indigo slop 而非单纯的紫色）。

他与多位顶尖设计师交流后发现，设计师能在 1.5 秒内判断一个页面是 AI 生成还是人类设计的。而他们指出的差异，同样是一组可确定性修复的模式。团队最终整理出：

• 24 份参考文档
• 10 种"设计异味"（Design Smells）
• 7 种设计模式（Patterns）

意图优先与 OK LCH

其中两个关键洞察：

第一是意图优先（Intent-first）。当你让模型"设计一个 dashboard"，它不会思考背后的意图，直接甩给你三张并排卡片。但如果给它一个框架——"这是什么类型的界面？dashboard 是用于监控（monitor surface）的"——它就能设计得好得多。

第二是颜色空间 OK LCH。OK LCH（Oklab Lightness-Chroma-Hue）是2020年由图形工程师 Björn Ottosson 提出的感知均匀颜色空间，2022年起被主流浏览器原生支持（CSS Color Level 4标准）。与传统 HSL 相比，OK LCH 最大的优势是"感知均匀性"——在 OK LCH 中调整亮度值时，人眼感知到的亮度变化是线性的，而 HSL 的亮度调整会因色相不同产生明显的视觉不一致（比如黄色在 HSL 中看起来比蓝色亮得多，即使 L 值相同）。

这一问题的根源在于：传统HSL/HSB是针对人类设计工具（如Photoshop色轮）优化的表示方式，在数值层面并非感知线性的。这与模型的「颜色理解」之间存在一个根本性的映射断层：LLM在训练数据中学习到大量HSL颜色代码，但由于HSL的感知非线性，模型难以建立「数值差异」与「视觉差异」之间的可靠映射关系——模型「知道」#7B68EE和#6A5ACD都是紫色，却无法从数值层面准确预测人眼感知到的亮度和饱和度差异。OK LCH的感知均匀性则意味着，在这个空间中，L值差10的任意两个颜色，人眼看起来亮度差距就是「差不多10」——这为模型提供了一个在数学上「诚实」的颜色描述语言，使得「调亮一点」「降低饱和度」等指令能够产生可预期的视觉效果。这与工具调用修复层的哲学如出一辙：不是模型不行，而是给模型的"契约"本身存在缺陷。

"这不是能力差距（capability gap），而是契约差距（contract gap），" Ahmad 总结，"用户永远只会说'帮我修一下设计、让它更炫'，如果你给模型一个'优秀设计师是怎么思考的'框架，就能修复 90% 的设计废料。"

Taste：自动学习你的编码品味

除了修复层，Command Code 的另一核心是 Taste（品味）——一个 Ahmad 称为"元神经符号（meta neuro-symbolic）"的模型架构。

它的工作方式是：在每个代码仓库里自动学习你的偏好。比如它观察到你安装依赖时偏好 pnpm，但本地 link CLI 时用 npm global link；比如你总是从 0.0.1 开始版本号——这些重复出现的微决策会被自动记录成"taste 文件"（类似 skill 文件，但更精简）。

关键设计原则：

• 透明可见：这些文件存在你的 Git 仓库里，而非藏在模型内部，每次 PR 都能审查；
• KL 散度去重：KL 散度（Kullback-Leibler Divergence）是信息论中衡量两个概率分布差异程度的指标，由 Solomon Kullback 和 Richard Leibler 于1951年提出。在 Taste 系统中，这一指标被创造性地用于实现一种精细化的上下文管理哲学。其计算公式 D_KL(P||Q) 衡量的是：如果用户真实偏好分布是P，而模型先验知识分布是Q，用Q来近似P会损失多少信息。KL 散度低意味着这个偏好与模型的通用知识高度重合（如「变量命名要有意义」），写入上下文是对稀缺窗口空间的浪费；只有 KL 散度较高的偏好（真正个性化、偏离通用惯例的习惯，如「我偏好pnpm而非npm」）才值得被记录。随着LLM上下文窗口扩展到百万token级别，填入什么、不填入什么本身就成为需要量化指标的工程决策——上下文窗口是稀缺资源，应该只填入模型「不知道」但「需要知道」的信息，而KL散度正是量化这种「信息价值」的理想工具；
• 可移植：npx taste pull 就能拉取，任何编码 Agent 都能直接使用。

在一项 70+ 开发者参与的研究中，使用 Taste 后开发者"手动纠正/编辑"的次数明显下降。社区里还流行一种玩法：先用 Claude Opus 或 GPT 等高质量模型建立 taste 文件，再用便宜的开源模型基于它持续开发——用低成本换来高质量输出。

走向开源，做"编码 Agent 界的 Apple"

访谈最后，Ahmad 透露了路线图：Command Code 即将开源（他希望能在 AI Engineering 大会上宣布）。这个项目源自 2020 年 COVID 期间他做的一个爆火 Corona CLI，历经六年演进而来。

他对产品哲学有个清晰比喻——业界有三种模式：

• Windows：什么模型都能跑（如 OpenCode）；
• Linux：什么都能自己 hack（如 Pi）；
• Apple：只提供最优模型（开源与闭源皆有），但完全可 hack。

Command Code 选择了 Apple 路线：不做"1500 个模型的大杂烩"，而是精选最优模型，同时保持全面可修改。值得一提的是，WordPress 之父 Matt Mullenweg 听说要开源后主动成为了天使投资人。

结语：一套普适的方法论

无论你用哪个编码 Agent，Ahmad 的核心洞察都值得借鉴：很多所谓的"模型能力问题"，本质是框架与模型之间的"契约问题"。通过确定性修复 + 修复提示的组合，不仅能解决工具调用失败，还能推广到 UI 设计、安全代码审查等更多场景。

这一发现的普适性在于，它揭示了一个被忽视的工程层次：在模型能力和应用效果之间，存在着一个可以被系统化优化的**「中间件」空间**。工具调用修复层解决了模型与工具契约之间的偏差；OK LCH 颜色空间提供了模型与视觉感知之间的准确映射；KL 散度驱动的 Taste 文件实现了模型先验知识与个人偏好之间的精准补全。这三者本质上都是对同一空间的填充与塑造——它们共同指向一个工程哲学：与其等待更强的模型，不如先把模型与现实世界之间的「翻译层」做对。这一哲学的深层意涵在于，AI应用工程师的核心价值正从「选择更好的模型」向「构建更好的中间件」迁移：模型能力的边际提升愈发依赖数百亿美元的算力投入，而中间件层的系统性优化往往只需要对失败数据的深度分析和工程智慧的巧妙运用。

正如 Ahmad 所说："你不必非得用 Command Code，你可以把这个思路用在任何编码框架里——只要我们都在进步。"

核心要点