news 2026/8/15 23:38:02

一文读懂DeepSeek最适合的Harness核心基础知识:Pi如何把缓存、上下文与工具循环做成生产力

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
一文读懂DeepSeek最适合的Harness核心基础知识:Pi如何把缓存、上下文与工具循环做成生产力

写在前面

欢迎大家关注Rocky的公众号:WeThinkIn
欢迎大家关注Rocky的知乎:Rocky Ding
《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源:【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book,欢迎大家Star~

Rocky最新撰写的10万字AI Agent(AI智能体)深入浅出全维度解析文章:深入浅出完整解析AI Agent(AI智能体)的核心基础知识

AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群(涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识)欢迎大家加入:https://t.zsxq.com/33pJ0


大家好,我是Rocky。

核心导读

最近一篇文章把一个很容易被忽略的事实推到了台前:同一个 DeepSeek,换一个 Harness,成本和稳定性可能完全不是一回事。原文标题中的“缓存命中率 99.93%”“平均成功任务成本约 0.028 美元”和“GitHub 约 8.6 万 Star”,都是微信文章或第三方测试口径,不能直接当成本次复现实验;但它们确实指向了一个更重要的问题:Coding Agent 的价格,不只由模型单价决定,也由 Harness 每一轮如何组织上下文决定。

Rocky的核心判断是:DeepSeek 最适合的 Harness,不一定是功能最多的 Harness,而是能让前缀尽量稳定、让 reasoning 状态可回放、让工具协议保持不变,并把长任务历史变成可复用缓存的 Harness。Pi 的价值不在于“少做几个功能”,而在于把模型、工具循环、会话状态和扩展外壳拆开,让开发者重新获得这些控制权。

这不是“DeepSeek 官方推荐 Pi”的结论。DeepSeek 官方文档目前给出了 API、reasoning、tool call 和多种 Agent 接入方式,官方模型卡在评测中使用的是 DeepSeek Harness minimal mode;Pi 则是一个独立开源项目。两者之间成立的是架构适配关系,而不是品牌背书关系。

1. 为什么同一个 DeepSeek 换 Harness,成本会差很多

很多人计算 Coding Agent 成本,只看一次请求的输入、输出价格。真实任务却不是一次请求:模型先读目录,再读文件,修改代码,运行测试,看到错误后继续推理,最后再回顾变更。每一步请求都会携带一部分共同前缀:系统提示、工具定义、项目约束、之前的对话和工具结果。

可以把第t tt轮请求写成:

C t = P i n ( U t − K t ) + P c a c h e K t + P o u t O t C_t = P_{in}(U_t - K_t) + P_{cache}K_t + P_{out}O_tCt=Pin(UtKt)+PcacheKt+PoutOt

其中U t U_tUt是输入总 token,K t K_tKt是被服务端识别为缓存命中的 token,O t O_tOt是输出 token。模型便宜,只能降低P i n P_{in}PinP o u t P_{out}Pout;Harness 能影响的,是U t U_tUt的增长方式和K t K_tKt能否持续出现。

如果 Harness 每次都重新排列工具、改变系统提示、压缩历史时引入随机格式,服务端看到的前缀就会不断变化。即使语义完全相同,缓存也可能失效。反过来,一个工具数量少、字段顺序稳定、会话 ID 固定、消息回放严格的 Harness,能把“已经付过的钱”变成下一轮的低价输入。

因此,99.93% 这个数字真正值得看的不是小数点后的精度,而是它提醒我们把缓存命中率当成 Agent 的系统指标。它需要和任务集合、模型版本、工具集、会话长度、缓存 TTL、是否包含重试一起报告。没有这些边界,单独的命中率不能证明任何生产成本。

2. Harness 到底控制了什么

Harness 不是把 prompt 发送给模型的薄薄一层胶水。它至少控制六件事:

  1. 上下文形状。哪些 system、user、assistant、tool 消息被保留,如何排序,压缩后用什么摘要替代。
  2. 工具协议。工具名字、JSON Schema、参数默认值、错误格式以及多个工具调用的执行顺序。
  3. 推理状态。reasoning 内容是否保留,下一轮是否能与 tool call 成对回放。
  4. 会话身份。是否给同一任务稳定的 session ID,使提供商可以关联 prompt cache。
  5. 副作用边界。写文件、删文件、执行命令失败后是否可恢复,工具是否可能被重复执行。
  6. 观测和验收。记录输入、命中 token、工具耗时、失败原因,并判断“代码能运行”而不是“模型说完成了”。

这六件事决定了 Agent 是一个可重复的生产系统,还是一个每次都从零开始的聊天机器人。模型能力越强、上下文越长,Harness 的差异反而越大,因为每一次组织失误都会被放大成更多 token、更长延迟和更难调试的失败。

3. Pi 的核心设计:极简工具面与可扩展外壳

Pi 的仓库把系统拆成几个边界清晰的包。pi-ai负责统一多提供商 LLM API,pi-agent-core负责 tool calling 和状态管理,pi-coding-agent提供交互式 Coding Agent CLI,pi-tui负责终端界面,pi-telemetry则定义供应商中立的遥测契约。这种拆分的意义,是让 Harness 的核心循环不被某个 UI、某个模型 SDK 或某个工作流绑死。

Pi 的默认核心工具面保持克制:读文件、写入或编辑文件、执行命令,以及按需加入图像读取等能力。扩展、Skills、MCP、计划模式、子 Agent、沙箱和权限策略可以在外层添加。工具越少并不自动意味着效果越好,但会带来一个直接工程收益:系统提示和工具 schema 更容易稳定,缓存前缀更容易连续,模型也更少面对互相重叠的动作入口。

上图来自 DeepSeek 官方技术资料体系中的 KV cache 讨论。它说明缓存不是一个“开关”,而是和消息前缀、注意力布局、服务端调度一起工作的资源。Harness 不能替代推理引擎,但可以决定哪些 token 有机会稳定地留在缓存路径上。

4. DeepSeek 为什么需要原生 Provider 适配

把 DeepSeek 当成普通 OpenAI-compatible 模型直接调用,通常能得到文本,但未必能得到可靠的 Coding Agent。reasoning 模型的 assistant 消息可能同时包含最终文本、reasoning_content和 tool call。下一轮如果只回放最终文本,模型会失去前一轮的推理上下文;如果把 reasoning 当普通文本拼进去,又可能破坏服务端期待的消息结构。

Pi 当前openai-completions.ts的处理体现了这种差异:流式响应会识别reasoning_contentreasoningreasoning_text等字段,增量聚合工具调用,并把 thinking block 和 tool call 转换成统一的内部消息。发送下一轮时,它还会把 reasoning 签名或内容按 provider 能接受的格式放回 assistant 消息。

DeepSeek 官方接口也把 reasoning effort 做成可配置参数。对于 Agent 任务,官方模型卡给出的 0731 评测口径是maxreasoning effort、temperature=1.0top_p=0.95。这意味着 Harness 应该把推理档位作为任务策略,而不是在每个工具循环里随意改动。普通文件检索不必开最大推理;复杂重构、跨模块测试和失败恢复才值得付出更高的推理预算。

推理历史的核心不是“把模型的内心独白展示给用户”,而是保持可验证的状态边界:哪些思考结果是下一轮工具调用的前提,哪些内容可以压缩,哪些签名必须原样保留。Pi 把这一责任放在 provider 和 agent loop 的接口之间,而不是让上层 UI 自己拼字符串。

5. 缓存命中率背后的上下文工程

DeepSeek 的 prompt cache 只有在服务端看到足够稳定的前缀时才有意义。一个 Coding Agent 的前缀通常长这样:

固定系统提示 固定工具定义 项目级规则 已经确认的任务目标 历史 assistant reasoning/tool call/tool result

真正变化的部分,往往只是最后一条用户指令或最新的工具结果。Pi 的会话循环把sessionId传给 provider,并在请求构造时保留缓存策略;这比每次创建一个无关的新客户端更接近“一个任务就是一个缓存会话”的工程语义。

但缓存不是越多越好。把巨大的源码树、重复日志和无关工具输出永久塞进上下文,会让命中 token 看起来很高,却让模型在错误信息里迷路。好的 Harness 要做三件事:

  • 稳定固定部分。系统规则、工具 schema、项目约束使用确定顺序和确定格式。
  • 限制变化幅度。工具结果按大小和相关性截断,避免一次命令输出让整段前缀失效。
  • 在可预测的节点压缩。Pi 的 compaction 会生成摘要并保留最近消息;摘要请求本身设置为不写入可复用缓存,避免把一次性压缩请求误计为长期前缀。

这解释了“极简”为什么可能带来成本优势:它降低了上下文形状的熵。工具越多、插件越多、自动注入的提示越多,前缀变化的可能性越高。少不是目的,低熵才是目的。

6. 工具循环:从聊天回复到可恢复操作

Coding Agent 最危险的地方,不是模型会犯一个语法错误,而是工具副作用可能已经发生。Pi 的 Harness 文档把会话建模为不可变 entry、可变 register 和追加式 usage ledger;操作状态保存当前阶段、队列和恢复信息。一次 provider 请求或工具调用可以采用“意图提交—执行—结算提交”的 effect sandwich:先记录即将执行的动作和预留结果 ID,执行外部效果,再把结果、usage 和下一状态一次性提交。

这套设计解决的是“进程在工具执行中崩溃怎么办”,而不是“模型永远不会错”。读文件这类操作可以安全重放;删除文件、部署服务这类操作则要标记为不可重放,恢复时生成中断结果而不是再次执行。生产 Harness 还应叠加权限确认、沙箱、补丁检查、测试门禁和回滚。

Pi README 明确提醒:默认没有内置的文件、进程、网络或凭据权限系统,运行权限就是启动它的用户权限。这个边界非常重要。Pi 是一个可组合的 Harness 基础设施,不是开箱即用的企业安全产品。把“极简”误读成“无需治理”,会把成本优势换成事故成本。

7. Pi 与 DeepSeek 的适配关系

可以把适配拆成四层:

DeepSeek 的要求Pi 能提供的控制点仍需补齐的工程
Providerreasoning、tool call、流式字段DeepSeek provider、reasoning_content解析针对具体部署端点的回归测试
上下文稳定前缀、session、长历史sessionId、统一消息转换、compaction项目级缓存策略和 TTL 监控
工具循环结构化参数、失败可恢复agent loop、并行/串行工具策略、hooks权限、沙箱、回滚、幂等
产品交付任务级成功而非回答级成功CLI、扩展、遥测契约评测集、人工验收、审计与告警

因此,Pi 更像是 DeepSeek 的“低熵运行时候选”,而不是一个神奇的成本优化按钮。它把 provider 特殊性、上下文状态和工具执行边界暴露出来,方便团队根据自己的任务调整。对于一次性问答,这些设计可能是过度工程;对于持续数十轮的代码任务,它们就是成本和可靠性的主要来源。

8. 成本数字应该怎样读

微信文章引用的 99.93% 缓存命中率和约 0.028 美元平均成功任务成本,最适合作为“值得测量的方向”,而不是作为产品承诺。至少要追问四个问题:

  1. 测试任务是修复小 bug、实现新功能,还是包含长时间运行的真实仓库?
  2. 成功的定义是测试通过、补丁被人工接受,还是模型自己输出了完成文本?
  3. 统计是否包含失败重试、压缩请求、工具输出和 reasoning token?
  4. 参与比较的 Harness 是否使用了相同模型版本、相同工具定义和相同上下文窗口?

“8.6 万 Star”也应放在正确的位置。Star 是传播和兴趣的信号,不是活跃用户、任务成功率或商业收入。真正需要观察的是版本更新、问题修复、扩展生态、真实 session 数据和团队是否持续维护核心接口。Pi README 对遥测、会话分享和测试的强调,至少说明项目把“可观察的真实任务”当成长期建设方向;但这仍不等于任何具体业务的成功证明。

上图还有一个容易被忽略的细节:模型卡将 Code Agent 结果与具体 Harness 模式、reasoning effort 和采样参数绑定在一起。这恰恰说明 Harness 不是评测中的无关变量。一个严谨结论不应该从“某模型在某榜单得分”直接跳到“任意 Agent 产品都会得到同样结果”,而要保留模型、Harness、工具集、推理预算和验收器这条完整实验链。

为了让不同 Harness 的成本对比可复现,至少应记录每个任务的原始仓库提交、任务描述、允许工具、模型精确版本、请求参数、缓存冷热状态、总轮数、重试次数、最终补丁和测试日志。评价指标也不应只有美元成本,还需要成功率、首次通过率、墙钟时间、人工介入次数和危险副作用次数。一个系统如果靠频繁重试得到低平均单次调用价格,最终任务成本反而可能更高。

Rocky更建议用“每个被验收成功任务的总成本”作为主指标:

C a c c e p t e d = ∑ C m o d e l + ∑ C t o o l + ∑ C i n f r a + C h u m a n N a c c e p t e d C_{accepted}=\frac{\sum C_{model}+\sum C_{tool}+\sum C_{infra}+C_{human}}{N_{accepted}}Caccepted=NacceptedCmodel+Ctool+Cinfra+Chuman

其中C h u m a n C_{human}Chuman不一定能精确换算,但至少要记录人工接管和修复次数。Agent 的商业价值不在于让 API 账单看起来便宜,而在于以更低的整体交付成本,稳定产出可以合并、可以部署、可以追责的结果。

9. 如何构建一套面向 DeepSeek 的生产级 Harness

Rocky建议按以下顺序落地,而不是先堆插件:

9.1 先定义任务和验收

建立一个包含真实仓库、缺陷、重构和测试失败恢复的任务集。每个任务定义可机器检查的验收条件,例如测试通过、变更文件白名单、静态检查无新增错误、命令副作用在沙箱内完成。

9.2 再固定上下文协议

给 system prompt、工具 schema、项目规则和错误格式做版本化。固定字段顺序,禁止插件在每轮随机注入自然语言说明。记录每次请求的输入 token、cache read/write token、reasoning token、工具耗时和最终验收结果。

9.3 将推理档位变成策略

为“检索、局部修复、跨模块重构、故障恢复”设定不同 reasoning effort。不要因为模型支持max就把所有步骤都开到最大。推理预算应和失败风险、代码影响面、剩余时间共同决定。

9.4 将工具分为读、改、执行三类

读工具默认可重放;改工具必须生成补丁并可回滚;执行工具按命令风险分级,网络、凭据和部署操作需要人工或策略门禁。每个工具返回结构化状态,包括 exit code、修改文件、标准输出截断信息和可重试性。

9.5 最后做故障注入

在 provider 流中断、工具执行中断、缓存失效、上下文压缩、进程重启和重复提交等位置杀掉进程。验收标准不是“能继续聊天”,而是:不重复危险副作用、每个 tool call 都有结果、usage 账本可对账、最终代码满足任务契约。

9.6 建立四层可观测性

第一层是模型层,记录模型版本、输入/输出/reasoning/cache token、首 token 延迟和停止原因。第二层是工具层,记录参数摘要、权限判定、exit code、输出截断和变更文件。第三层是任务层,记录计划变更、失败恢复、验收器结果与人工接管。第四层是业务层,记录一次修复是否真正减少工程师时间、是否引入回归、是否能在相似仓库复用。

只有四层打通,团队才知道成本上涨来自模型推理、缓存失效、工具噪声,还是任务本身定义不清。否则“换一个更便宜的模型”只是把问题移动到别处。Pi 的遥测契约和 usage ledger 提供了合适的接入点,但每家公司仍要把它们连接到自己的仓库、CI、权限和交付指标。

10. 这套 Harness 的边界与跨周期价值

Pi 的“更简单”不是把复杂性消灭,而是把复杂性放到可以被组合、替换和验证的位置。它不会替你解决企业权限、多人协作、代码审计、部署回滚,也不能保证 DeepSeek 在每个仓库都比其他模型更强。它真正提供的是一组可观察的控制面:模型请求如何形成、推理如何保留、工具如何执行、会话如何恢复。

在 AI Agent 的中场阶段,最容易被吸收的是表面工具:一个聊天 UI、一套漂亮的 prompt、一组没有验收的插件。更可能跨周期留下来的,是低熵上下文协议、可恢复操作状态、工具权限边界、任务级评测和成本账本。这些东西不依赖某个模型品牌。今天接 DeepSeek,明天换别的模型,仍然需要同一套工程判断。

结语

DeepSeek 最适合的 Harness,答案不是“功能最多”,也不是“Star 最高”,而是能把模型的长上下文、推理输出和低价缓存转化为稳定工作流的系统。Pi 提供了一个有启发性的实现方向:核心保持小而确定,provider 原生适配,工具循环可插拔,会话和恢复状态显式持久化。

99.93% 命中率值得关注,但更值得复制的是它背后的方法:让每一轮请求尽量复用已经确认的前缀,让每一个工具动作都有明确的副作用边界,让“完成”由测试和验收定义。模型会继续迭代,Harness 的判断力才是更难被替代的生产力。

推荐阅读

Rocky一直在运营技术交流群(WeThinkIn-技术交流群),这个群的初心主要聚焦于技术话题的讨论与学习,包括但不限于算法、开发、竞赛、科研以及工作求职等。群里有很多人工智能行业的大牛,欢迎大家入群一起学习交流~(请添加小助手微信Jarvis8866,拉你进群~)

1. 深入浅出完整解析AI Agent(AI智能体)的核心基础知识

2025年可以说是AI Agent全面落地应用的元年,因此Rocky在持续撰写对AI Agent的全维度解析文章:

深入浅出完整解析AI Agent(AI智能体)的核心基础知识

2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

Rocky对扩散模型的本质原理与和核心基础知识进行了全面系统的深入浅出分析讲解,同时不断跟进补充扩散模型的最新技术发展,希望能给大家带来帮助:

深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

3. 入浅出完整解析FLUX.2、Seedream(即梦)、Z-image、GLM-Image核心基础知识

Rocky对AIGC时代“中场时刻”之后的主流AIGC创作大模型的核心基础知识进行了全面系统的深入浅出分析讲解,力求让大家通俗易懂理解AIGC时代的技术浪潮的本质价值:

入浅出完整解析FLUX.2、Seedream(即梦)、Z-image、GLM-Image核心基础知识

4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

Rocky对FLUX.1 Kontext和FLUX.1 Krea的核心基础知识作了全面系统的梳理与解析:

深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

5. 深入浅出完整解析DeepSeek系列核心基础知识

Rocky对DeepSeek系列模型的核心基础知识作了全面系统的梳理与解析:

深入浅出完整解析DeepSeek系列核心基础知识

6. 深入浅出完整解析Stable Diffusion 3(SD 3)和FLUX.1系列核心基础知识

Rocky对Stable Diffusion 3和FLUX.1的核心基础知识作了全面系统的梳理与解析:

深入浅出完整解析Stable Diffusion 3(SD 3)和FLUX.1系列核心基础知识

7. 深入浅出完整解析Stable Diffusion XL(SDXL)核心基础知识

Rocky对Stable Diffusion XL的核心基础知识作了全面系统的梳理与解析:

深入浅出完整解析Stable Diffusion XL(SDXL)核心基础知识

8. 深入浅出完整解析Stable Diffusion(SD)核心基础知识

Rocky对Stable Diffusion 1.x-2.x系列模型的核心基础知识做了全面系统的梳理与解析:

深入浅出完整解析Stable Diffusion(SD)核心基础知识

9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

Rocky对Stable Diffusion中最为关键的U-Net结构进行了深入浅出的全面解析,包括其在传统深度学习中的价值和在AIGC中的价值:

深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

10. 深入浅出完整解析LoRA(Low-Rank Adaptation)模型核心基础知识

对于AIGC时代中的“ResNet”——LoRA模型,Rocky进行了深入浅出的全面讲解:

深入浅出完整解析LoRA(Low-Rank Adaptation)模型核心基础知识

11. 深入浅出完整解析ControlNet核心基础知识

AIGC图像创作开源社区已经形成以Stable Difffusion/FLUX为核心,ConrtolNet和LoRA作为首要AI辅助工具的变化万千的AIGC图像创作工作流。

ControlNet正是让AI图像创作社区无比繁荣的关键一环,它让AIGC图像创作过程更加的可控,更有助于广泛地将AIGC算法解决方案应用到各行各业中

深入浅出完整解析ControlNet核心基础知识

12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

AI绘画和AI视频是两个互相促进、相互交融的领域,2024年无疑是AI视频领域的爆发之年,Rocky对AI视频领域核心的Sora、Seedance、Keling等大模型进行了全面系统的梳理与解析

深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

13. 深入浅出完整解析AIGC时代Transformer核心基础知识

在AIGC时代中,Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向,成为AI技术架构大一统与多模态整合的关键核心基座,大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析:

深入浅出完整解析AIGC时代Transformer核心基础知识

14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

AIGC创作框架正是AIGC算法工作流的运行载体,目前主流的AIGC创作框架有ComfyUI、Diffusers、Stable Diffusion WebUI等。在传统深度学习时代,PyTorch、TensorFlow以及Caffe是传统深度学习模型的基础运行框架,到了AIGC时代,Rocky相信ComfyUI就是AIGC时代的“PyTorch”、Stable Diffusion WebUI就是AIGC时代的“TensorFlow”、Diffusers就是AIGC时代的“Caffe”

深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

在AIGC时代中,如何快速转身,入局AIGC产业?如何成为AIGC/LLM/AI Agent算法/开发工程师?如何在学校中系统性学习AIGC/LLM/AI Agent知识,斩获心仪的AIGC/LLM/AI Agent算法/开发offer?

Don‘t worry,Rocky为大家总结整理了全面的AIGC/LLM/AI Agent算法/开发工程师成长秘籍,为大家答疑解惑,希望能给大家带来帮助:

手把手教你成为AIGC/LLM/AI Agent算法/开发工程师,斩获AIGC/LLM/AI Agent算法/开发offer!

16. AIGC产业的深度思考与分析

2023年3月21日,微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示,自从1980年首次看到图形用户界面(graphical user interface)以来,以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。

Rocky也认为,AIGC及其生态,会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期,未来随着AIGC的全面落地和深度商用,会深刻改变我们的工作、生活、学习以及交流方式,各行各业都将被重新定义,过程会非常有趣。

那么,在此基础上,我们该如何更好的审视AIGC的未来?我们该如何更好地拥抱AIGC引领的革新?Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点,希望能帮助各位读者对AIGC有一个全面的了解:

深入浅出全面解析AIGC时代核心价值与发展趋势(2025年版)

17. AI算法工程师的独孤九剑秘籍

为了方便大家实习、校招以及社招的面试准备,同时帮助大家提升扩展技术基本面,Rocky将符合大厂和AI独角兽价值的算法高频面试知识点撰写总结成《三年面试五年模拟》之独孤九剑秘籍:

【三年面试五年模拟】AIGC时代的算法工程师的求职面试秘籍(持续更新中)

18. 深入浅出完整解析AIGC时代中GAN(Generative Adversarial Network)系列模型核心基础知识

GAN系列模型作为传统深度学习时代的最热门生成式Al模型,在AIGC时代继续繁荣,作为Stable Diffusion/FLUX系列大模型的“得力助手”,广泛活跃于AlGC图像创作的产品与工作流中:

深入浅出完整解析AIGC时代中GAN(Generative Adversarial Network)系列模型核心基础知识

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/8/15 23:35:37

第二十五章 个体理解工程

第二十五章 个体 第二十五章 个体理解工程 📅 2026年08月14日👤 东塬一老翁📂 第一卷 个体人工智能理论基础 第二十五章 个体理解工程 ——Individual Understanding Model 25.1 个体理解的本质 在个体人工智能中,理解不是对…

作者头像 李华
网站建设 2026/8/15 23:29:33

Chrome Network面板全解析:从HTTP请求到性能优化的前端调试实战

1. 从“黑盒”到“透视”:为什么我们必须懂Network面板做前端开发或者网站性能优化,最怕的就是线上出问题。用户反馈“页面打不开”、“加载太慢了”,你这边代码看着一切正常,服务器日志也风平浪静。这时候,如果你还只…

作者头像 李华
网站建设 2026/8/15 23:18:55

基于Gemini API构建AI对话应用:从环境配置到生产部署的工程实践

在实际 AI 应用开发领域,谷歌的 Gemini 模型系列正成为一个无法绕开的技术选项。从最初的 Bard 到如今整合了多模态能力的 Gemini,其 API 和 SDK 的易用性、性能表现以及背后的技术栈,是许多开发者在构建智能应用时评估的重点。虽然官方会公布…

作者头像 李华
网站建设 2026/8/15 23:15:39

Playwright官方文档样例报错解决:从环境配置到工程化实践

1. 项目概述:当官方文档也“不靠谱”时 做自动化测试或者网页爬虫的朋友,最近几年肯定绕不开 Playwright 这个工具。它确实强大,微软出品,跨浏览器支持,API 设计也现代。但不知道你有没有遇到过这种情况:兴…

作者头像 李华
网站建设 2026/8/15 23:06:13

2030年算力能耗预测:8000亿度电背后的技术挑战与绿色算力实践

这次我们来看一个关于未来算力与能源消耗的预测:到2030年,全国算力用电量预计将达到8000亿千瓦时。这个数字背后,是近6万亿度的绿电需求将涌入电网。这不仅仅是能源消耗的预测,更是对数据中心、AI算力、云计算基础设施乃至整个数字…

作者头像 李华