DeepSeek V4 系列发布之后，关于它能不能用、好不好用的讨论很多，但大部分评测还停留在普通对话或编码上。CowAgent 作为一个中立的 Agent 框架，则更关心模型在 Agent 链路中的真实表现，包括工具调用、长上下文、长期记忆、浏览器自动化、知识组织，本文用这 6 个真实场景在 CowAgent 中对 DeepSeek V4 模型做了全面测试。
新发布的 DeepSeek V4 模型系列分 Flash 和 Pro 两档，本次评测主要关注 deepseek-v4-flash。它的价格大约是 Pro 的 1/10、Claude Sonnet/Opus 的几十分之一、MiniMax M2.7 的三分之一，响应速度也更快。如果 Flash 已经能够覆盖大部分 Agent 任务，那 Pro 自然会更好。这次测试也是为了决定是否要把 CowAgent 的默认推荐模型切换到 V4 Flash 模型。
测试在 CowAgent 的 Web 端进行。CowAgent 是一个开源的 AI Agent 框架，内置任务规划、工具、技能、长期记忆、知识库等模块，并支持多种接入渠道。每个测试场景在独立 session 中 运行，互不干扰。关键参数：
| 配置项 | 值 |
|---|---|
| 模型 | deepseek-v4-flash |
| 深度思考 | 开启，reasoning_effort 参数使用默认的 high，需要更深思考强度时可设置为 max |
| 单任务最大步数 | 50 |
| 历史对话保留 | 20 轮 |
| 上下文 token 上限 | 100 万 |
| 工具 | 13 个内置工具（bash / edit / read / write / web_search / web_fetch / browser 等） |
| 技能 | 30+ Skills（frontend-engineer / image-generation / video-gen / pptx-creator 等） |
6 个场景的设计原则是：每个场景对应 Agent 的一个核心能力维度，且尽量贴近真实使用
| 场景 | 测试关注点 | 任务复杂度 |
|---|---|---|
| 任务规划与技能调度 | 多工具/Skill 协同、长链路规划 | 高 |
| 复杂交互式编程 | 单文件零依赖前端、视觉冲击 | 高 |
| 长期记忆（高难度） | 跨 session 记忆检索 + 推理 | 中 |
| 浏览器自动化（小红书） | 真实站点多步操作、登录态处理 | 高 |
| 知识库自动构建 | 联网调研 + 知识图谱组织 | 高 |
| 超长上下文处理 | 网络长文档消化 + 大海捞针 | 高 |
任务：下周要做一场关于「AI Agent 在企业中的落地实践」的内部分享，让 Agent 全程接管：1) 调研客服 / 营销 / 研发三大场景下的 AI Agent 落地案例；2) 生成一份 8 页的 PPT 文件；3) 把分享要点沉淀到知识库。
关注点：在 13 个工具和 30+ 个 Skill 的工作空间里，能不能精准选择并组合执行，这是最考验规划能力的场景。
实测数据：
| 指标 | 数值 |
|---|---|
| 总耗时 | 229.5s |
| 工具调用次数 | 35 次 |
| 联网搜索 | 7 次 |
| 文件读写 | 12 次 |
| 产物 | 一份 8 页的分享 PPT + 一篇知识库沉淀文档 |
| 状态 | 成功 |
观察：Flash 的执行路径基本是 拆解 → 逐场景调研 → 沉淀文档 → 生成 PPT → 更新知识库，整个链路一次跑通，没有出现重复执行或漏步骤。35 次工具调用都用得很克制，没有冗余动作，说明它的多工具规划在 Agent 框架的提示词约束下是稳定的。
Web 端对话：
生成结果：
最终生成的 PPT（样式和美观性还要取决于安装的 Skill，这里用了一个比较基础的 PPT 生成技能，整体文字、排版基本没有问题）：
任务：做一个「ATLAS AI · 全球运营中心」实时大屏（单 HTML 文件），包含实时核心指标、双 Y 轴 QPS/延迟折线图、全球节点地图、5 维能力雷达、GPU 集群柱状图、实时事件流、Top 模型排行榜。要求视觉冲击 + 单文件 + 数据全前端模拟。
关注点：复杂前端代码生成 + 视觉品味 + 单文件零依赖约束。
实测数据：
| 指标 | 数值 |
|---|---|
| 总耗时 | 381.7s |
| 工具调用次数 | 28 次 |
| 文件分次写入 | 6 次（避免单次 token 截断） |
| 自我验证 | 调用浏览器多次打开 + 截图回看 |
| 产物 | 一个零外部依赖的单 HTML 文件 |
| 状态 | 成功 |
观察：
网页展示效果：
模型自己调用浏览器打开页面、截图回看的过程：
任务：分两个 session 做。第一阶段 Setup 在 session A 中分三轮聊天，把「迟到的春天」咖啡品牌的零散信息（品牌定位、视觉、供应链、首店选址、店长候选人）灌给 Agent；第二阶段 Query 用一个全新的 session B，要求 Agent 基于"它对我品牌的所有了解"，写一份 30 天运营计划 + 给店长选择建议。
关注点：跨 session 记忆能否被精准检索 + 多条记忆能否综合推理。
实测数据：
| 指标 | 数值 |
|---|---|
| Setup 总耗时 | 49s（3 轮） |
| Query 耗时 | 142.4s |
| Query 阶段工具调用 | 2 次（记忆检索 + 记忆读取） |
| 检索到的相关记忆条目 | 14 条 |
| 状态 | 成功 |
观察：在全新 session 里，Flash 只用 2 次工具调用就把品牌的全部细节拿出来了，视觉色（雾霾蓝 #6B8FA8）、供应商（普洱孟连老黑寨合作社）、租金、店长候选人薪资全部一字不差，并且基于这些信息给出了结构化建议：
「精品咖啡调性优先 → 推小林 → 但可以谈到 1.6~1.7 万作折中 → 用股权/分红预期补一点薪资差距」
第一个会话中进行了多轮问题咨询：
新会话中的回复，可以看到模型主动触发了记忆检索：
长期记忆中沉淀下来的品牌信息：
任务：分三步走：1) 打开小红书 explore 页搜「DeepSeek」，提取前 6~8 篇笔记的标题、点赞、互动量，总结爆款套路；2) 基于调研写一篇标题、正文、话题标签的笔记草稿，保存到本地；3) 打开发布页，未登录时截图二维码让用户扫码，扫码完成后填入草稿，停在最终发布按钮前等用户确认。
关注点：真实有反爬的网站、登录态处理、知道什么时候应该停下来求助用户。
实测数据：
| 指标 | 数值 |
|---|---|
| 总耗时 | 124.4s（不含用户扫码等待时间） |
| 浏览器工具调用 | 8 次 |
| 主要动作 | 打开页面 / 读取 DOM / 点击 / 填写 / 截图 |
| 关键交互节点 | 遇到登录页主动截图二维码并暂停 |
| 状态 | 成功 |
观察：
搜索结果页和模型总结的爆款套路：
模型在登录页主动请求用户协助：
登录后自动填写表单内容，模型停在发布按钮前等待用户确认：
任务：从零构建 Model Context Protocol (MCP) 主题的知识库，要求联网调研、整理 4 个主流 MCP Server + 2 个客户端，按索引页 + 分类目录 + 交叉链接的方式组织，最后更新知识库顶层索引。
关注点：联网 + 文件操作 + 知识组织能力的综合，最终能正确构建出知识图谱
实测数据：
| 指标 | 数值 |
|---|---|
| 总耗时 | 210.6s |
| 工具调用次数 | 26 次 |
| 联网搜索 | 6 次 |
| 写入文档数 | 13 篇 |
| 目录结构 | 索引页 + 概念目录 / Server 目录 / 客户端目录 |
| 状态 | 成功 |
观察：Flash 真正做出了图谱的样子，不是把所有内容写成一篇大文档，而是遵循知识库 wiki 技能的设定，切成「概念页 / Server 实现页 / 客户端集成页」并且互相 link，每篇结尾都有"相关阅读"区域指向兄弟节点。这个分层组织能力对知识库类任务非常重要。
知识库构建过程：
生成的知识库目录结构：
索引页渲染后的效果：
任务：让 Agent 拉取 Project Gutenberg 上的《战争与和平》英文全本（约 56 万词，3.36MB），全部消化后回答：1) 一句话主题；2) 4 条主要叙事线；3) 4 个细节问题（要求引用原文 + 标注卷章）。其中细节题包括 Pierre 第一次出场场景、Natasha 第一次舞会舞伴、Andrei 在 Austerlitz 战场看到的天空原文、最后一章的哲学主题。
关注点：超长文档的全局理解 + 大海捞针式的精确定位 + 原文引用准确度。
实测数据：
| 指标 | 数值 |
|---|---|
| 总耗时 | 156.3s |
| 实际拉取字符数 | 3,359,613（≈ 3.36MB） |
| 工具调用次数 | 50 次 |
| 网络抓取 | 1 次（一次性下载全本到本地） |
| 终端命令（grep / wc 等） | 30+ 次 |
| 文件分段读取 | 10+ 次 |
| 状态 | 成功 |
实测下来模型并没有试图把 3.36MB 全部塞进 context，而是：先一次性把全文落到本地，只在 context 里保留前 5 万字符；后续通过终端命令在本地文件里搜索关键词（"Austerlitz"、"lofty sky"、"Natasha"、"waltz" 等）拿到行号；再按行号区间分段读取，把关键段落带回 context。
最后给的答案：
整个过程 50 次工具调用都没出错，也没有陷入死循环。先把全文落盘，再用搜索一步步定位、分段读，这种处理路径才是 Agent 在长文档场景下真正实用的能力。
在 Agent 场景里，发生一次性把 1M token 塞进 prompt 的概率其实很低，真到了几十万 token 的文档，更好的做法就是先落盘再搜索，而不是一次性加载全部内容。所以这个场景测的不是模型能装多大，而是模型够不够聪明知道什么时候该装入上下文、什么时候该走工具，这才是 Agent 真正需要的长上下文能力。
模型的工具调用过程（先获取全文落盘，再用 grep 定位、按行号区间分段读取）：
最终回答中带章节引用的原文段落：
6 个场景全部跑完的汇总数据：
| 场景 | 状态 | 耗时 | 工具调用 |
|---|---|---|---|
| s1 任务规划 | 成功 | 229.5s | 35 |
| s2 复杂编码 | 成功 | 381.7s | 28 |
| s3 长期记忆 | 成功 | 142.4s | 2 |
| s4 浏览器自动化 | 成功 | 124.4s | 8 |
| s5 知识库构建 | 成功 | 210.6s | 26 |
| s6 超长上下文处理 | 成功 | 156.3s | 50 |
几个数据观察：
整体看下来，DeepSeek V4 Flash 在 6 个场景里的稳定性已经足以做默认模型来用，最复杂的 s1（35 次工具调用）和 s6（50 次工具调用）也能稳定跑完，比 V3 时代有非常明显的改善。规划、编码、记忆、浏览器、知识库、长上下文这几项基础能力都没有明显短板，长期记忆和长上下文这两块的表现甚至有些超出预期。再加上价格优势，Agent 一次任务往往要几十次 LLM 调用，模型成本是选型里很关键的一项。Flash 在这个价位上能做到这种水准，作为日常使用的默认选择性价比很高。
当然 Flash 也不是没短板，复杂约束的执行偶尔会打折扣，比如 s2 里要求"零外部依赖"，模型还是引用了 echarts CDN。遇到真正复杂的任务，直接切到 Pro 配合 reasoning_effort=max 能拿到更深的思考深度。后们也会继续补充批量任务测试和不同模型的横向对比，并形成一套可复用的 Agent 能力评测框架。
基于这次评测的结果，CowAgent 开源项目（GitHub）在最新版本中已经将 deepseek-v4-flash 设置为默认模型。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。