[返回全部研究]() 词元映射研究模型实测 # 编程智能体的代码修复轨迹与 Harness 对照 昨天看到一个图，就觉得搞笑又真实： ![图片是一幅漫画，上方有“忒修斯的船板”及“@Arcadia_Bao”字样。画面中，四只不同颜色的长条形生物站在一排，分别标注“K-3”“GPT-5.6-sol”“Fable-5”，其中Fable-5较大且标注“fable级”。画面右侧有一个橙色的球体，标注“Fable-5”。该漫画位于文档中对国产模型更新情况的讨论之后，可能是用来幽默地表达国产模型在某些方面已达到较高水平，与文档中提到的模型更新快、能力提升等内容相呼应。]() 最近模型更新快的，确实有点看不过来。 DeepSeek V4 Pro、GLM-5.3 接连更新，豆包推出了 Seed-Evolving，DeepSeek 还发布了自己的 Harness。模型能力在涨，给模型提供工具和执行环境的 Harness 也在进化。 而且还都说很强，我们要是再让模型做一个前端页面然后做对比。 说真的，已经很难看出它真实表现了，一个页面真的太简单了，做的好或差，也反映不出来真实的解决问题的能力。 为了既能够直观，又反映出真实能力，我们这样做了一个测试，下面这段录屏是回放了一轮完整测试过程： [视频]() 我给大家说清楚，这到底是个啥。 我把 5 个国产编程模型、放进 5 份完全相同的真实代码仓库，让它们修同一个 Bug，每款模型连续跑 3 次。 然后把它整个过程全部记录下来：它读了哪些文件、搜了什么代码、什么时候开始修改、运行了什么命令、哪里报错、失败后有没有回退、又是怎么换方向的。 这就像是把 5 位程序员分别请进 5 间独立办公室，给他们同一张工单，然后全程录屏。 最后，我们会拿到两份东西。 一份是结果表，看 Bug 到底有没有修好。 另一份是轨迹日志，看程序员到底是怎么修的。 有的人会先把相关文件和文档查一遍，找到关键位置后再动手；有的人上来就改，边报错边调整；还有的会同时探索很多方向，在不同文件之间反复切换。 人是如此，体现到模型上也是同样，是先调研解决方案，看一遍文档，还是不管三七二十一上来就干，是有很大差异的。即使最后的结果都是修好了，但背后的稳定性、执行成本和需要人工盯着的程度，也可能完全不同。 这就是这次测试的价值：**结果表告诉我们它有没有到达终点，轨迹图把它一路怎么走也展示了出来。** 通过轨迹图，我们能了解这个模型的脾气、性格、犯错次数，甚至，，能看出是否够“聪明”。 ## 这次测试是怎么做的 这几个模型执行的任务，来自拥有 40k stars 的开源协作文档项目 Outline。 ![图片展示的是一个基于React和Node.js构建的知识库Outline的界面。界面左侧有导航栏，包含Home、Documentation等选项。右侧显示“Documentation”下的“Integration & API”内容，介绍了Webhooks的概念，即在更大集成中收集通知和反应系统元素的组合，如新客户创建、银行账户付款等。还说明了何时使用Webhooks，如异步事件发生时。图片与上下文关系紧密，上下文提到这些模型执行的任务来自Outline开源协作文档项目，图片展示了Outline软件界面，直观呈现了文档内容。]() 每个模型都从同一份代码开始，彼此不共享记忆，也看不到其他模型留下的结果。每款模型分别运行 3 次，主测试一共 15 次。我们在做测试时 GLM-5.3 还没有发布，所以这次使用的是 GLM-5.2。 这些模型主要在 Oh My Pi 中执行。可以把它理解成模型的工作台：模型通过它读取文件、搜索代码、修改内容和运行测试。 另外，我还放入了一条 DeepSeek Harness + DeepSeek V4 Pro 的对照轨迹，用来观察同一个模型换了一套工作台后，执行方式会不会变化。 下边是结果评分，这个结果表只能反映完成情况怎么样，大家可以先记住这个评分： 模型 | 本任务最终评分 | DeepSeek V4 Pro | 93 | Kimi K3 | 92.5 | DeepSeek V4 Flash | 79.7 | GLM-5.2 | 78 | Doubao-Seed-Evolving | 73.3 | DeepSeek Harness + DeepSeek V4 Pro | 82 | 毕竟模型是小心谨慎得这么多分，还是一顿操作猛如虎后的得分，这是完全不同的概念。 模型在动手前看了多少东西，中间走过多少弯路，失败后能不能自己调整，这些都藏在执行日志里。下边是完整日志轨迹图： ![图片为模型执行日志轨迹图，展示了不同模型在完成任务过程中的表现。图中有多个线条和点，线条代表不同时间点的评分变化，点则表示模型在特定时间点的评分。图中还标注了模型名称，如DeepSeek V4 Pro、Kimi K3等。该图与上下文紧密相关，通过这些轨迹图可直观了解模型在执行任务时的评分变化情况，辅助分析模型完成任务的表现。]() 这个轨迹图中，有很多的颜色、点点、甚至红叉，其实只需要先认清几个符号： - **彩色点**：一次可观察动作，例如读文件、搜索、改代码、运行命令或测试。 - **方框**：程序按规则识别出的路线转折，例如失败后回退、改换方向，或者走到这里后没有继续行动。 - **红叉**：日志中识别到的一次失败事件，可能来自输出、调试或测试。 ![图片是关于执行轨迹读取的说明，对应文档中“执行轨迹怎么读”部分。图中分为三部分：01部分介绍彩点，即一次可观察动作，如读取、搜索、命令、修改、测试调用等；02部分介绍方框，即路线转折，分为随后出现测试调用、随后继续编辑、未观察到后续动作三种情况；03部分说明红叉，是日志中识别到的一次失败事件，其输出看起来失败，但彩点、方框和红叉都记录了可观察动作，不是模型的隐式思考。]() 图的纵向从下往上，代表这轮操作从开始走到结束。 横向是接口、更新逻辑、协作代码和测试等九个工程区域。轨迹左右跳动，说明模型正在不同区域之间切换。 普通读者不用数每个点，先看四件事就够了： 它什么时候开始改代码？ 前半段是在调查，还是已经上手尝试？ 红叉出现得多不多，失败后有没有调整路线？ 整条路线是在逐渐收敛，还是一直来回跳？ **这样再看几条轨迹，模型之间的“做事习惯”就很直观了。** 比如看最底下这一点，这是任务最开始时候模型的动作： ![图片展示了5个国产模型在任务最开始时的动作情况。1号模型动作频繁，有彩色点；2号模型动作也较多；3号模型动作相对较少，有彩色点；4号模型动作较少，先确定方向；5号模型动作较少，有彩色点。这与上下文提到的模型在开始阶段频繁来回转折、探索路线方法等内容相呼应，直观呈现了各模型的行动特点。]() 其实打眼一看，可以发现这几个模型，都在开始阶段频繁的来回转折，也有点多彩色点，这就意味着：模型基本都会读取文档、搜索相关代码、梳理背景，然后也会探索和思考不同的路线方法，「1、2、3、5」都明显的会不同程度的调研，再行动。（因为折线很频繁，代表着不断思考不同的方法、查看了很多的文件） 只有4号的K3模型，一开始先笃定了一个方向，没有过多的步骤点在执行。（前几步，是较少的转折） 好，相信你已经看懂了，学会看这个图了，下边就好说了。 ## 5 个模型加一条 Harness 对照，我看到的四个差异 ### DeepSeek Pro 相比 Flash 提升非常明显 无论在 Oh My Pi 还是 DeepSeek Harness 的代表轨迹里，DeepSeek V4 Pro 出现的红叉都比 Flash 少。 结合三轮最终结果看，Pro 在这次任务里的稳定性也有明显提升。 ![图片展示了DeepSeek V6 Flash、DeepSeek V6 Pro和DeepSeek V6 Pro（第41次迭代）三个模型在不同测试场景下的红叉数量变化情况。横轴为测试调用次数，纵轴为红叉数量。三条曲线分别对应不同模型，曲线上的红叉数量变化直观呈现了模型在不同测试调用次数下的表现。该图与上下文紧密相关，通过对比三个模型的红叉数量变化，辅助分析模型在测试过程中的表现差异。]() 红叉数量会受到测试调用次数影响，单独拿它无法排出一个通用榜单。但它和最终结果放在一起看，能够帮助我们判断：模型是比较顺利地完成任务，还是在反复试错后勉强走到终点。 ### Kimi K3：前半段先读、先搜，动手最晚 Kimi 是几款模型里开始修改最晚的。 我们在最初期看到K3就是比较少的执行落点，这也提现到了整体任务上，Kimi K3表现的更加谨慎，相比其他模型，K3发出查看文件的指令甚至都会谨慎些。 它在前半段做了大量阅读、搜索和检查。整轮可观察动作走到约 48% 时，它才先修改测试文件；22 次修改中，有 21 次发生在整条轨迹的后半段。三轮运行首次修改位置的中位数是 48.5%。 基本都是在确保测试无误后，才开始修改代码文件，表现的非常谨慎。 ![图片展示了Kimi和deepseek-v4-flash在任务执行过程中的代码文件修改情况。左侧为deepseek-v4-flash修改代码文件的流程图，右侧为Kimi修改代码文件和测试文件的流程图。Kimi在修改代码文件和测试文件时，有多个节点被红色框突出显示，且有箭头指向，表明其修改操作。该图与上下文紧密相关，直观呈现了Kimi在本次任务中执行风格谨慎，前期调查多，修改更集中的特点。]() 它很像那种接到任务后先把资料和边界查清楚，再集中写代码的人。这个数字不能直接证明结果一定更好，但它清楚地展示了 Kimi 在本次任务里的执行风格：谨慎，前期调查多，修改更集中。 ### Doubao：动作最多，工程区域切换也最频繁 Doubao 的一条代表轨迹里共有 293 个动作，在不同工程区域之间切换了 184 次，都是几条模型轨迹里最多的。作为对比，GLM 的代表轨迹共有 180 个动作。 所以 Doubao 的轨迹看起来最密、最碎：搜索一个方向，试一下，遇到问题再切到另一个区域继续尝试。 ![图片展示了Doubao模型在修复任务中的轨迹图，对比了GLR - S、GLR - M、GLR - L三种模型的搜索情况。图中以不同颜色线条表示各模型的搜索轨迹，左侧为GLR - S，中间为GLR - M，右侧为GLR - L。轨迹图中还标注了搜索区域、搜索方向等信息。该图与上下文紧密相关，直观呈现了Doubao模型在工程区域切换频繁、动作多等方面的特性，与上下文对Doubao模型探索和试错能力强的描述相呼应。]() 动作多不等于能力更强，它体现的是更高频的探索和试错。这样的路线能不能带来更好的结果，还要结合最终修复情况、Token 消耗和执行时间一起判断。 这和我日常使用豆包时感受到的“短平快、愿意多试几个方向”能对上。不过这次测试只覆盖了一个代码任务，也没有涉及 VLM，因此无法用它评价豆包的全部能力。 ### 同一个 DeepSeek V4 Pro，换了 Harness 后路线也变了 换到 DeepSeek Harness 后，DeepSeek V4 Pro 明显更加**偏向先读、先搜。** 这条代表轨迹的前 41% 基本都在调查。首次修改前共有 96 个动作，其中 92 个是阅读或搜索，直到后半段才逐渐开始修改和测试。 这说明真实 Agent 的表现，需要把模型和 Harness 放在一起看。Harness 会影响模型能使用哪些工具、拿到什么上下文、按什么节奏推进任务。模型相同，工作台和执行规则变了，最后呈现出来的做事方式也会改变。 ![这张图片呈现的是两个版本的DeepSeek V6 Pro相关的折线数据图表，分别为标注「DeepSeek V6 Pro」的左侧内容与标注「DeepSeek V6 Pro Harness」的右侧内容。图表的折线分布于不同比例刻度区间，还带有蓝色、红色方框及红色叉形标记以标识关键数据节点，对应文档中提及的DeepSeek Harness处于预览阶段且支持定制的内容，用于直观对比该模型对应不同版本下的数据表现差异。]() 目前 DeepSeek Harness 仍处于预览阶段，也支持进一步定制。对企业 Agent 和 Workflow 来说，这一部分和模型本身同样重要。 ## 最后，给这 5 个模型定个调 如果只根据这次任务给它们做一个定位，我会这样记： ### DeepSeek V4 Pro：稳健主力 多次运行的情况下执行最稳定。它通常会先花时间把问题看清楚，再集中完成修改。遇到内容比较多、需要同时调整多个地方的任务，我会优先让它先试一轮。 ### Kimi K3：谨慎派 Kimi 动手最晚，前半段阅读和检查更多，修改集中在后半程。适合要求清楚、结果容易核对的任务。 ### DeepSeek V4 Flash：快攻手 Flash 上手很快，很早就开始修改，倾向于边改边检查，能较快产出第一版，适合想尽快拿到第一版的任务，不过质量上需要更多把关。 ### GLM-5.2：状态型选手 整体路线相对均衡，但是并不稳定，其中一轮表现亮眼，另外两轮属于平均水平，在有现成资料可以参考时，能很快找到方向。日常写方案、整理资料、修改已有内容，都可以先让它多跑两版。 ### Doubao-Seed-Evolving：高频探索派 动作最密，探索方向多，区域切换频繁，整个过程也最忙。这个特点也让他非常适合搜索场景，所以我觉得豆包APP 能火，符合大众的使用习惯，跟豆包模型在执行上一个劲尝试也有关系，这就非常适合短平快的任务，硬着头皮也得尝试各个方向去解决、回答用户问题。。。 它更适合目标清楚、步骤可以拆开、结果方便逐项检查的短任务。 这份定位只对应本次真实代码任务，覆盖不了写作、搜索和多模态等全部能力。 但它已经让一个问题变得很清楚： 同样是把 Bug 修好，有的模型先调查再动手，有的快速试错，有的不断换方向。最终得分相同，背后的可靠性和监督成本可能差得很远。 更有意思的是，同一个 DeepSeek V4 Pro 换到 DeepSeek Harness 后，执行路线也发生了变化。 做 Agent 时，模型决定基础能力，Harness、工具、上下文和反馈机制共同决定最终表现。以后企业选择 Agent，也不能只问用了哪个模型，还要看它被放进了一套什么样的工作环境。 结果表回答它能不能做完。 轨迹图回答你敢不敢把更长、更贵、更难回退的任务交给它。 ## 继续探索 [全部研究]() [!\[图片\]() 模型实测 ### DeepSeek、GLM 与 Kimi 的真实任务对比 说实话，现在的大模型已经多到让人有点选择困难了。]() [!\[图片\]() 模型实测 ### Doubao Seed 2.1 Pro 工程任务实测 6 月 23 日，火山引擎在北京举办 2026 夏季 FORCE 原动力大会，正式发布豆包大模型 2.1。]() [!\[图片\]() 模型原理 ### 语言模型的知识表示与生成机制 “AI 的那些知识，是存储在模型里的吗？”答案是：AI（大语言模型）不存储任何知识。]()