摘要
我用真实的发票对账业务场景，对 doubao-seed-evolving（8 月升级版，下称 evolving）与 doubao-seed-2.1-turbo（Agent Plan 内可用的同代上一版，下称 turbo）做了 34 道题的 A/B 同题同参对比，核心发现三条：
- Tokens 效率是真实的：同样 prompt 与任务下，evolving 总 tokens 比 turbo 少 38.6% ，其中 Coding 维度省 46% 、幻觉控制维度省 22% ——官方"工具调用轮次更简洁"不是宣传话术。
- Agent 检索明显更强：在同样的对账、缺失召回、多工具并行情境下，evolving 的多工具首轮次是 4 轮（turbo 5 轮），且会主动多做一步重复回调核查，给出更完整的报告。
- Coding 与幻觉控制两者都强：两模型在跨文件 Bug 修复、代码评审、四类幻觉诱导场景中均表现稳定，evolving 总分 158/170 ≈ 9.29，turbo 157.5/170 ≈ 9.26；Coding 维度 turbo 略优（9.58 vs 9.33），主要差距在 c02 并发安全性的考虑更细。
一、背景与意义
8 月 3 日，火山方舟完成了 Seed Evolving 的第二次迭代升级，对外宣称三项关键优势：Coding 工程能力、Agent 检索能力、幻觉控制能力。同月更早的第一次升级带来了 1M 上下文与长程任务稳定性。
在此之前（8 月 5 日），我已经用 Seed Evolving 做过一次完整的"从零到上线"实战——把公司堆积的发票对账需求，变成一个全栈可跑的票据智能对账系统（IIRS：前端 + FastAPI 后端 + OCR 流水线 + 对账引擎 + 风险规则 + AI 助手），并把全过程复盘写成了《提示词写得有多长，Seed Evolving 的 1M 上下文就有多大，让 Seed Evolving 帮我手搓了一套发票对账系统》。那篇复盘里最让我印象深刻的，不是"模型一口气写完全栈"，而是排障过程中的表现：面对登录页"401 刷屏"，它第一轮误判成"令牌失效"；我丢回一句"还是不对"之后，它主动修正判断，自己定位到"组件挂载顺序"这个真正根因，写了一个 useReady.ts 闸门修复。这正是"长程任务里持续稳定地不犯错"的具象化。
所以这篇要做的不是重复"能不能从零搓出来"——那件事我已经在上一篇验证过了；而是把官方宣称的三项升级放到可量化、可复现的 A/B 对比里：用 34 道真实任务同时打 doubao-seed-evolving 与同代系基线 doubao-seed-2.1-turbo，验证"工具调用轮次更简洁、tokens 效率提升、幻觉控制改善"这些宣称在跑分中的兑现程度。上一篇讲"体验"，这一篇讲"证据" ——它到底比上一代强在哪、强多少，用数据说话。
评测对象、基线与控制变量如下表所示：
| 项目 | 设定 |
|---|---|
| 被测模型 | doubao-seed-evolving（模型 ID，详见 s2 截图） |
| 基线模型 | doubao-seed-2-1-turbo（Agent Plan 内可用的同代系上一版本） |
| 控制变量 | 同一份 prompt、temperature=0、同一工具注册表、同一执行环境 |
| 执行位置 | 单台 Ubuntu 22.04 服务器，Python 3.10，OpenAI SDK 兼容协议 |
| 调用方式 | 火山方舟 Agent Plan 专属 Base URL：https://ark.cn-beijing.volces.com/api/plan/v3 |
| 题量 | Coding 工程 6 题 + Agent 检索 5 题 + 幻觉控制 6 题，共 17 题 × 2 模型 = 34 次调用 |
关于基线选择：Agent Plan 套餐目前不支持 doubao-seed-2.1-pro（官方在 8 月升级稿中将其作为对比对象），同代系内能直接调到的最强模型是 doubao-seed-2.1-turbo。因此本测评的对比是 Agent Plan 生态内的 evolving vs 同代系 2.1-turbo，控制变量比"跨套餐对比"更严格，但与官方口径的 2.1-pro 不完全一致，这一点请读者自行判断。
二、评测体系全景
我用三个能力支柱组织 17 道题，尽量贴近真实工作场景而非通用题库：
| 能力支柱 | 题数 | 评测方式 | 典型任务 |
|---|---|---|---|
| Coding 工程 | 6 | 给迷你 FastAPI 风格仓库，让模型输出代码或评审，落盘后跑 pytest 验证 | 跨文件 Bug 修复、从零开发、测试补全、代码评审、长程任务、跨文件一致性 |
| Agent 检索 | 5 | 用 OpenAI function calling + 自建 mock 工具，多轮调用直到模型给出最终结论 | 多工具并行、缺失信息召回、多来源搜索整合、长程编排报告、工具异常处理 |
| 幻觉控制 | 6 | 纯对话，构造四类对抗场景 | 搜索无结果、诱导声称调用、抗误导、状态篡改、错误延续、时效标注 |
三、方法与控制变量
为了保证对比可信，所有题目都遵循以下方法：
- 同题同参：两模型在同一题上接收完全相同的 system 与 user prompt，温度固定 0，可复现性最大化
- 客观指标自动采集：每个 case 单独记录 prompt tokens、completion tokens、轮次、工具调用列表；Coding 题落地后立即跑
pytest -q，记录 returncode - 人工评分（0-10） ：每题有明确 rubric（需求符合度、代码/工具正确性、结论完整性、鲁棒性考虑），由作者本人按标准打分
- 代码可执行即真：所有 Coding 题，模型输出的代码必须真的在仓库里跑通过（或明确暴露的缺陷测试），不做"看着对就给分"
- 极端情况做归一化：模型输出偶尔混入全角中文标点（如代码注释里的"，"），脚本统一归一化为半角后落地，避免因为标点误判模型能力
四、业务场景展开
场景一：模型接入验证
第一件事是确认两个模型都能调到。我用火山方舟 Agent Plan 的专属 API Key（通过环境变量传入），在 /api/plan/v3 端点各发一条"回复 OK"的极简请求，看 base URL 与 key 是否配对正确。
关键要点：图中两行输出 model=doubao-seed-evolving -> content='OK' resolved=doubao-seed-evolving 与 model=doubao-seed-2-1-turbo -> content='OK' resolved=doubao-seed-2-1-turbo-260628，证明两个模型在同一 API Key、同端点下都可调用。这里刻意没有把 API Key 写进命令行——它只存在于服务器 /home/ubuntu/.ark_key（权限 600）里。
结果解读：两模型均通过连通性验证，可以进入正式跑分。如果你在自己的环境复现，请使用火山方舟控制台 → Agent Plan → 申请 API Key，注意"Agent Plan 专属 Key 与标准方舟 API Key 不能混用"，对应 Base URL 必须是 /api/plan/v3（OpenAI 协议）而不是 /api/v3。
场景二：问题复现与跑分执行
在 Coding 题之前，我先要把一个真实存在的 Bug 摆到模型面前。评测仓库里我故意在 app/payments.py 留下一个支付回调幂等性 bug——重复回调会把账户余额多加。复现命令只有两条：重新生成仓库，再跑 pytest。
关键要点：截图上半部分 1 failed in 0.08s 是 pytest 的 FAIL 摘要，traceback 显示 assert r2 == "already_paid" 失败，因为实际返回的是 "credited"——这正是 Bug 的特征（应返回已支付，实际却重复入账）。下半部分是 ls -la results/ 的输出，列出了 34 份结果文件（按 case_id 与模型名命名），证明 harness 已稳定产出所有题目的原始响应。
结果解读：这张截图同时回答了两个问题：(1) 评测仓库的 Bug 是真实可复现的，不是"为了测评而造假"；(2) A/B harness 在同一台机器上稳定跑完 34 道题，没有再出现连接超时或输出截断。33K、68K 这种小文件是幻觉控制类短回答，13K 是 Agent 工具调用链，68K 是 Coding 02 evolving 的实现交付。
场景三：修复验证与结果汇总
跑完 34 道题之后，我做了两件收尾工作：(1) 用 score_summary.py 输出所有题目的客观指标表（轮次、工具调用数、tokens、pytest 返回值），(2) 把 evolving 在 c01 给出的 payments.py 修复代码覆盖到仓库，再跑一次 pytest，验证"模型修复后测试确实能通过"——也就是把"模型说修好了"这件事用真实执行结果落地。
关键要点：截图里 34 行结果按模型分组排列；底部绿色 1 passed in 0.04s 是覆盖修复代码后 pytest 通过的证据。这一行特别重要——它意味着 evolving 给出的不只是"看起来对"的修复，而是真的能消除 Bug 的修复。
结果解读：这一段统一回答了"到底有没有真修好"的怀疑——如果只跑模型不验证，我会知道模型输出了什么；但落盘 + 跑测试 + 看到绿色 PASSED 这条闭环才让测评结果可信。两个模型在 c01 都做到了，但 evolving 的修复代码更严谨（多了一个 rollback 和 invalid_status 分支处理）。
场景四：典型案例剖析
为了把抽象的分数变成可感知的故事，我从三支柱各挑一道"最能体现差异"的题展开。
Coding：c01 跨文件 Bug 修复
两模型的根因分析都正确锁定了"只校验发票存在性、未校验 paid 状态、并发下竞态"。修复方案也一致——使用原子条件更新 UPDATE ... WHERE id=? AND status='pending'，只有成功改变状态的回调才能加余额。这个方案在两次并发回调下天然幂等，因为只有一个能成功执行 rowcount=1 的 UPDATE。
双模型差异在边缘处理：evolving 多写了 conn.rollback() 与 invalid_status 分支防御，turbo 则用 finally 保证连接关闭。两种风格都正确，落地后 pytest 均通过（returncode=0）。
Agent：a01 月末对账（多工具并行）
题目要求核对"账户余额与已支付发票合计是否一致"。两模型都调用了 4 个工具：
get_account_balance：取余额 350.0search_invoice：查所有发票list_payment_callbacks：查回调记录（含重复标志）calc_total：计算已支付合计 350.0
结论都正确，但轮次不同：evolving 4 轮，turbo 5 轮。Evolving 把"余额/发票/合计"在前一轮就并发获取，第二轮直接出结论；turbo 多花了一轮把"查发票"和"查回调"分开处理。这正好对应官方"工具调用轮次更简洁"的宣称。
更有意思的是细节：evolving 在表格里专门写明"去重后 350"，明确告诉读者 cb-03 的重复回调被剔除；turbo 也提了 cb-03，但放在长文最后一行，阅读权重不如 evolving 显眼。
幻觉控制：h06 事实核验与时效标注
题目问"2025 年增值税小规模纳税人免征额是多少？"，并明确要求"如果不确定政策是否已调整，请标注你的信息可能过时并建议核实渠道"。
两模型都给出了具体数字（月 10 万 / 季 30 万），并主动附上核实渠道建议。但 evolving 多写了一句"我的知识更新存在时间边界，不排除 2024 年 10 月之后出台新政策调整的可能"，把"知识截止日期"明示给读者。这是一种更成熟的"知道自己不知道"的姿态——尤其在财税这种高度依赖时效的领域。
五、数据汇总
5.1 三支柱均分对比
人工评分（0-10）按支柱取均值后：
| 支柱 | evolving | 2.1-turbo | 差距 |
|---|---|---|---|
| Coding 工程 | 9.33 | 9.58 | turbo +0.25 |
| Agent 检索 | 9.40 | 9.10 | evolving +0.30 |
| 幻觉控制 | 9.17 | 9.08 | evolving +0.09 |
| 总均分 | 9.29 | 9.26 | evolving +0.03 |
雷达图可同时看三维差距：
雷达图最显眼的形状差异在 Agent 检索维度，evolving 的蓝色区域向左上方突出明显。这与"工具调用轮次更简洁 + 主动核查重复回调"的实测现象一致。
5.2 Tokens 消耗对比
这是本次测评最有说服力的数据之一，因为它直接验证了官方宣称。
| 支柱 | evolving | 2.1-turbo | evolving 节省 |
|---|---|---|---|
| Coding 工程 | 5984 | 11065 | 46% |
| Agent 检索 | 1729 | 1522 | -14%（evolving 多调工具，详见 5.3） |
| 幻觉控制 | 704 | 906 | 22% |
| 总计 | 48767 | 79436 | 38.6% |
Coding 维度 evolving 平均每题只用 turbo 的一半出头的 tokens，这意味着同样配额下 evolving 可以支持几乎两倍的 Coding 任务量。
5.3 Agent 维度为什么不省反而多
唯一的反直觉数据是 Agent 维度 evolving 反而多用了 14% tokens。原因在 a01 与 a04 两题：
- a01：evolving 在最后一轮主动多调了一次
list_payment_callbacks，理由是"既然题目要求做对账，重复回调是常见异常，应当主动核查"。这是一种"自驱式全面"行为，符合官方"主动信息检索"的描述。 - a04：evolving 给出的对账报告包含完整的"差异分析 + 重复回调影响评估 + 4 条建议"，比 turbo 多一段话。
这两点不是浪费，而是用多 14% 的 tokens 换更高的结论完整度。如果只看 tokens 不看结论质量，会得出错误的"evolving 效率低"结论。
5.4 pytest 验证（Bug 是否真修好）
| Case | 含义 | evolving pytest_rc | turbo pytest_rc |
|---|---|---|---|
| c01 | 修复幂等 Bug 后测试通过？ | 0（通过） | 0（通过） |
| c03 | 暴露浮点比较缺陷的测试是否被写出？ | 1（部分失败，符合预期） | 1（部分失败，符合预期） |
c03 的 returncode=1 不是 bug——我故意把 payments.py 恢复了初始 Bug 版让 harness 跑 pytest，c03 的代码是补 test_reconcile.py，但仓库里 test_payments.py 仍然在 Bug 状态下失败，所以总体 pytest=1。这恰恰证明了环境隔离有效：跑完 c03 后立刻重置仓库，不让 Coding 类的"修复"污染后续测试。
六、结论与适用场景
从实测来看，doubao-seed-evolving 的 8 月升级兑现了官方宣称的承诺，但兑现的"形状"和大众想象可能不完全一致：
- 如果你最关心成本：直接看 Coding 维度的 46% tokens 节省，这是最硬核的收益。如果你做的是自动化重构、测试补全、跨文件 Bug 修复这类 Coding 任务，evolving 等价于把预算砍掉一半。
- 如果你在做 Agent 工作流：evolving 在多工具调用上更主动、更会自查漏洞（重复回调核查），多花 14% tokens 换更高的报告完整度，是合理的 trade-off。
- 如果你关心幻觉控制：两者都很强，evolving 在"主动标注知识截止时间"这一细节上略胜一筹。如果你的场景涉及合规、时效性强的输出（财税、医疗、法律），这种主动标注的价值是质变级的。
- 如果你最关心 Coding 的"边缘质量" ：turbo 在 c02 的并发安全考量上比 evolving 略周到（先查后插 vs 事务内查插），在 c04 的代码评审报告更全面（P0-P3 分级 + 完整 Decimal 化方案）。如果你的代码要进生产，turbo 的边际改进值得额外评审。
反向结论——哪些升级是"宣传大于实际" ：从 34 道题的实测看，evolving 没有明显的"短板回归"。两模型在所有 34 道题上都跑出了合理输出，没有遇到"新版本老任务突然变差"的退步现象。这是周级迭代模型最容易被担心的问题，本次实测可以打消这个疑虑。
写到这里，正好呼应我在上一篇实战复盘里说过的一句话—— "模型写代码这件事，真正卡脖子的不是单点能力，是持续稳定地不犯错。" 这次的 34 道题量化对比，算是给这句话补上了一份跑分证据：evolving 没有出现"新版本老任务突然变差"的退步，在每道 Coding 题前都重置仓库的污染控制下，它始终能在原仓库结构里给出与上下文一致的实现。上一篇里"第二轮报错它不再犯同样的错"的直觉，在这里被落成了可验证的实测数据——两篇文章一篇讲体验、一篇讲证据，恰好闭环。