<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[wshzd的博客]]></title><description><![CDATA[专注于机器学习和深度学习]]></description><link>https://blog.csdn.net/wshzd</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; wshzd]]></copyright><item><title><![CDATA[LLM之Agent（108）｜DeepSeek-Harness（十六）上下文压缩 Compaction 与 Checkpoint 持久化]]></title><link>https://blog.csdn.net/wshzd/article/details/167377837</link><guid>https://blog.csdn.net/wshzd/article/details/167377837</guid><author>wshzd</author><pubDate>Fri, 09 Oct 2026 11:51:16 +0800</pubDate><description><![CDATA[这套设计让"绝大多数普通事件追加"走一条便宜的、批量摊销的路径,只有真正需要 durability 保证的那几个关键时刻才付出"立刻写入"的代价——,否则派生出的历史会出现一次没有结果的裸调用,模型看到会困惑,更严重的是会破坏 provider 侧对"assistant 消息紧跟工具结果"这类格式的强约束。如果生成的摘要本身比被压缩的原文还长（模型偶尔会这样),整个压缩事务直接判定失败——压缩存在的意义就是"变小",一个不变小的压缩没有任何价值,不应该被接受。,而不是"先执行,再想办法补记一条日志"。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（107）｜DeepSeek-Harness（十五）流式输出管道：从 StreamChunk 到 UI]]></title><link>https://blog.csdn.net/wshzd/article/details/166896639</link><guid>https://blog.csdn.net/wshzd/article/details/166896639</guid><author>wshzd</author><pubDate>Wed, 30 Sep 2026 14:12:36 +0800</pubDate><description><![CDATA[同时负责"实时转发给 UI"和"落盘一份可无损重放的紧凑记录"这两件事（但两条路径彼此独立，见下），Host/Client 之间的传输层负责把数据搬到浏览器，Client 只管"把收到的数据再折叠成可渲染的 UI 状态"。分支），之前已经发给 UI 的帧也不会被撤回——UI 展示的是"这一刻模型说了什么"的事实，会话日志记的是"这次请求最终、经得起回放验证的结果"，两者故意不耦合。来兜底 adapter 层面的各种抛异常方式——这也是为下一篇的重试机制铺路：重试判断的输入永远是一条结构化的。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（106）｜如何写出好的 Skill]]></title><link>https://blog.csdn.net/wshzd/article/details/166842860</link><guid>https://blog.csdn.net/wshzd/article/details/166842860</guid><author>wshzd</author><pubDate>Tue, 29 Sep 2026 15:02:46 +0800</pubDate><description><![CDATA[比如你要做一个"PDF 处理"技能：SKILL.md 里写了处理流程，但旋转 PDF 的代码每次都一样，每次让 AI 重写既浪费时间又可能出错——不如直接放一个写好的 Python 脚本。那正确的写法是什么样的？它是一个"创建 skill 的 skill"，它自己的 SKILL.md 就是一份关于"如何给 AI 写指令"的最佳实践。技能文件夹里，可能有一份"怎么处理 PDF"的操作指令、一个旋转 PDF 的 Python 脚本、一份 API 参考文档——AI 不需要从外部再找任何东西，这个文件夹里全有了。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（105）｜DeepSeek-Harness（十四）会话事件溯源：Session Event Log 与 Surface]]></title><link>https://blog.csdn.net/wshzd/article/details/166838255</link><guid>https://blog.csdn.net/wshzd/article/details/166838255</guid><author>wshzd</author><pubDate>Tue, 29 Sep 2026 11:09:00 +0800</pubDate><description><![CDATA[这让"没有压缩发生的正常对话"每次调用的开销只有 O(新增节点数)，而不是每次都要把整份历史重新投影一遍——对一个可能有几千条事件的长会话来说，这个差别是数量级的。被截断，模型这一步什么内容都没产出、只携带了一份 usage 统计,这类事件被记录下来（为了 usage 账目完整）,但绝不能在派生历史里插入一条空的 assistant 轮次——那会让下一次请求的消息序列出现语义上没有意义的空发言。本身是一个纯粹的"去重"判断：只有当渲染出来的当前上下文文本和已经记住的上一条快照不同时，才返回一条新的。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（104）｜DeepSeek-Harness（十三）ReactLoopAgent 总览：kick → turn → step]]></title><link>https://blog.csdn.net/wshzd/article/details/166788248</link><guid>https://blog.csdn.net/wshzd/article/details/166788248</guid><author>wshzd</author><pubDate>Mon, 28 Sep 2026 15:08:00 +0800</pubDate><description><![CDATA[是"一次模型调用 + 它触发的工具执行"，是 ReAct 循环的最小单元。不是运行中的循环会产生的：它是 fork 种子构造时给"源会话在 fork 边界处还没收尾的 turn"事后补记的标记，只出现在 fork 出来的子会话日志里。四类事件在会话日志里天然形成了一个可以精确回放、精确定位"崩溃发生在哪个 turn 的哪个 step"的树状结构——这也是下一篇要讲的"会话事件溯源"的直接基础。依然是"一次模型调用 + 它触发的工具执行"的最小单元，工具调用不产生新 turn的判断逻辑（下面这段）完全没变。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（103）｜当「快思考」遇上「深理解」：Laya 和 BERT 到底有什么区别？]]></title><link>https://blog.csdn.net/wshzd/article/details/166785038</link><guid>https://blog.csdn.net/wshzd/article/details/166785038</guid><author>wshzd</author><pubDate>Mon, 28 Sep 2026 11:57:11 +0800</pubDate><description><![CDATA[在 arXiv 上发表了一篇论文，提出了"非自回归决策模型"的概念——基于强化学习和严格proper scoring rules，在encoder架构上做端到端的决策输出。Laya-multilingual 走得是另一条路——它专门针对决策场景优化，支持100+语言，而且在很多语言上的决策准确率远超 BERT 的多语言版本。代表的是"大一统"思路——一个模型学习通用表示，所有的任务都建立在这个表示之上。RLCD 训练出来的模型，概率输出是经过数学校准的，不是语言模型那种"听起来自信的文本"]]></description><category></category></item><item><title><![CDATA[LLM之Agent（102）｜DeepSeek-Harness（十二）Profile、Bundle、Preset：dsh 的装配语言]]></title><link>https://blog.csdn.net/wshzd/article/details/166595157</link><guid>https://blog.csdn.net/wshzd/article/details/166595157</guid><author>wshzd</author><pubDate>Thu, 24 Sep 2026 15:51:56 +0800</pubDate><description><![CDATA[至此，本章从"一个插件长什么样"（第一篇），到"插件之间怎么通信"（第二篇），到"卸载怎么保证干净"（第三篇），再到"这些插件在系统和会话两个粒度上怎么被组装起来"（本篇），构成了理解 dsh 运行时架构所需要的完整 Cordis 基础——后续章节里出现的任何一个具体子系统，都是在这套基础之上长出来的一棵插件树。记录了决策始末——替换的理由正是"目录 preset 复制了 Cordis 的配置所有权，独立的那套 API 无法用一个普通的 profile 补丁表达同样的组合"）——]]></description><category></category></item><item><title><![CDATA[LLM之Agent（101）｜DeepSeek-Harness（十一）Cordis Typed Events：五种派发模式与 waterfall 语义]]></title><link>https://blog.csdn.net/wshzd/article/details/166590718</link><guid>https://blog.csdn.net/wshzd/article/details/166590718</guid><author>wshzd</author><pubDate>Thu, 24 Sep 2026 14:12:49 +0800</pubDate><description><![CDATA[表面上什么错误都不会抛出，但它背后的默认行为、以及注册在它之后的所有监听器都会被静默吞掉——这在生产环境里排查起来非常痛苦，因为现象只是"某个功能诡异地不生效了"，看不到任何报错。这段代码印证了本章的核心论点：所谓"钩子系统"，在 Cordis 里根本不需要一套专门的 hook 协议或者外部命令通道——它就是一个普普通通的插件，里一个更完整的端到端测试展示了它在真实调用链路里的效果——注册一个"危险工具"，再挂一个监听器拒绝它，断言模型最终看到的是一条。挂上去的这些监听器，插件被卸载的时候去哪儿了？]]></description><category></category></item><item><title><![CDATA[LLM之Agent（一百）｜DeepSeek-Harness（十）Cordis核心概念：Context、Service、Plugin]]></title><link>https://blog.csdn.net/wshzd/article/details/166576133</link><guid>https://blog.csdn.net/wshzd/article/details/166576133</guid><author>wshzd</author><pubDate>Thu, 24 Sep 2026 10:41:07 +0800</pubDate><description><![CDATA[下一篇《Typed Events 与五种派发模式》会讲清楚：当插件之间不需要"直接调用对方方法"、只需要"通知对方发生了什么、或者请对方决定要不要拦截"时，Cordis 提供的另一套通信机制——Typed Events——是怎么工作的。如果"用 SQLite 存会话"和"用本地文件系统存会话"是两份分别写死在初始化代码里的实现，想要换一个持久化后端，就得去改调用方的每一处引用。——这不是随手设计的返回值，而是本章第三篇要讲的"注册即副作用"原则在最底层的体现：谁提供了服务，谁就自动获得了收回它的手柄。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十九）｜DeepSeek-Harness（九）Vendoring 策略与供应链治理]]></title><link>https://blog.csdn.net/wshzd/article/details/166489925</link><guid>https://blog.csdn.net/wshzd/article/details/166489925</guid><author>wshzd</author><pubDate>Wed, 23 Sep 2026 18:19:26 +0800</pubDate><description><![CDATA[这个取舍在业界并不罕见——大型项目普遍会对某些特别核心、特别需要深度定制、或者信任边界特别敏感的依赖采取类似策略,常见形态包括:把编译器/运行时的某个关键子系统整个拷进主仓库并保留同步脚本、对安全敏感的加密库做"vendor + 定期人工审计差异"而不是自动升级、或者像很多大型单体仓库那样对整个第三方生态做"snapshot + 内部 fork"处理,理由几乎都指向同一句话——如果不改名,直接用上游的包名发布,就等于在公共 registry 上"抢注"了别人的包名——这是必须避免的供应链事故。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十八）｜DeepSeek-Harness（八）测试策略与 CI 门禁]]></title><link>https://blog.csdn.net/wshzd/article/details/166485993</link><guid>https://blog.csdn.net/wshzd/article/details/166485993</guid><author>wshzd</author><pubDate>Wed, 23 Sep 2026 15:52:01 +0800</pubDate><description><![CDATA[DeepSeek Harness 的测试体系用七层 Vitest 配置(课程写作时是五层,后来新增了 expected 和 bench 两层)分别验证"代码区域自身正确"(unit)、"逐文件真的被跑过"(coverage)、"对着真实模型真的能用"(e2e)、"构建产物的确定性输出没有偏差"(expected)、"关键路径的性能预算没有退化"(bench)、"外部契约没有意外变化"(snapshot)、"浏览器渲染出来的真实效果没有回归"(web),每一层都对应。环境变量可覆盖并发度)。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十七）｜DeepSeek-Harness（七）构建体系:Host 与 Client 双面构建]]></title><link>https://blog.csdn.net/wshzd/article/details/166484474</link><guid>https://blog.csdn.net/wshzd/article/details/166484474</guid><author>wshzd</author><pubDate>Wed, 23 Sep 2026 15:13:23 +0800</pubDate><description><![CDATA[加载,TypeScript 会把二者做接口合并——合并结果既不是 Host 期望的类型,也不是 Client 期望的类型,而是两者字段的并集(遇到同名同结构字段会合并、遇到冲突签名可能直接报错或产生令人费解的联合类型)。——因为类型系统"看得到"这个键,反而会编译通过,直到打包阶段才因为找不到对应的运行时实现而崩溃,甚至更糟——悄悄地把一份不该在浏览器里出现的 Node 依赖打进产物。里读出来)——也就是说,原来"哪些模块能被外部化"是一份仓库级别的全局清单,现在下放成了"每个客户端包在自己的。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十六）｜DeepSeek-Harness（六）Monorepo 结构与包职责地图]]></title><link>https://blog.csdn.net/wshzd/article/details/166365560</link><guid>https://blog.csdn.net/wshzd/article/details/166365560</guid><author>wshzd</author><pubDate>Tue, 22 Sep 2026 15:24:21 +0800</pubDate><description><![CDATA[一个就占了 16 个包,基本对应"Agent Teams 多智能体协作"和"浏览器/computer-use 自动化"这两个还在快速迭代中的方向——如果你在别的章节看到"多智能体""浏览器自动化"相关的新概念,大概率源码就在。DeepSeek Harness 用"54 个一级分类 + 291 个二级叶子包"(数字仍在快速变化)的两级目录,把"给人浏览的能力地图"和"给工具消费的发布单元"彻底分离;则是两个"依附但独立"的顶层目录:前者是本地进程沙箱相关原生启动器的构建产物(有自己的。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十五）｜DeepSeek-Harness（五）权限预设与个性化配置]]></title><link>https://blog.csdn.net/wshzd/article/details/166363025</link><guid>https://blog.csdn.net/wshzd/article/details/166363025</guid><author>wshzd</author><pubDate>Tue, 22 Sep 2026 14:24:38 +0800</pubDate><description><![CDATA[一个编码 Agent 能执行 shell 命令、改写文件，如果"允许它做什么"和"要不要在做之前问一下人"被绑在同一个开关上，产品能提供的组合就会非常有限——要么完全信任、要么完全不信任，中间状态很难表达（比如"允许它随便读写工作区文件，但涉及工作区之外的路径必须先问我"）。这一行只是声明了三个"名字 → 组合"的映射表，供用户在运行时切换,并不参与"进程刚启动时默认用哪个组合"的决策——那件事完全是前两行各自独立算出来的。里按部署环境变量重新声明。的应答者来决定"允许一次"还是"拒绝"；]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十四）｜DeepSeek-Harness（四）Provider 与模型配置]]></title><link>https://blog.csdn.net/wshzd/article/details/166348886</link><guid>https://blog.csdn.net/wshzd/article/details/166348886</guid><author>wshzd</author><pubDate>Tue, 22 Sep 2026 10:55:10 +0800</pubDate><description><![CDATA[是适配器自己填的默认值而不是用户显式选择的，那么在征询"是否要切换模型/参数"时就不应该把这个隐式默认值当成"用户锁定的值"再传回去——否则切换模型之后，上一个模型的隐式默认反而会被误当成显式配置继续沿用。逐字段比较来判定，只有真正变化时才会在会话日志里追加一条新的请求头快照，这也是"Model-visible ⟺ logged"这条工程规则的一处具体落地——任何影响模型请求的配置都必须能从日志里重建。"优先级链条是两套完全独立的机制，一套管"这个值是多少"，一套管"这个密钥的真实内容是什么"。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十三）｜DeepSeek-Harness（三）CLI 命令与 Profile 机制]]></title><link>https://blog.csdn.net/wshzd/article/details/166253146</link><guid>https://blog.csdn.net/wshzd/article/details/166253146</guid><author>wshzd</author><pubDate>Mon, 21 Sep 2026 19:04:21 +0800</pubDate><description><![CDATA[字段本身没变，只是留出了给"模板"未来附加其他元数据（而不只是 bundle 列表）的空间——这个接口的注释"Installation-owned defaults used when a shipped profile is first opened"也透露了新的用途：模板不仅用于装配补丁栈，还被用来判断"一个已存在的 Profile 是不是恰好等于某个官方模板"（下一节会看到这一点如何支撑。，这正是"用一个新名字 + 一个官方模板，创建并启动一个全新 Profile"这条路径的入口，下一节展开讲。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十二）｜彻底颠覆Agent架构！ChatGPT核心大佬重磅发布“System One”决策模型 Jev，提速200倍的底层逻辑是什么？]]></title><link>https://blog.csdn.net/wshzd/article/details/166238637</link><guid>https://blog.csdn.net/wshzd/article/details/166238637</guid><author>wshzd</author><pubDate>Mon, 21 Sep 2026 11:03:52 +0800</pubDate><description><![CDATA[大模型的“幻觉”是怎么来的？Jev 这个名字，来源于经济学中著名的**“杰文斯悖论”（Jevons paradox）**：19世纪的经济学家威廉·斯坦利·杰文斯发现，提高煤炭使用效率的技术非但没有减少煤炭的消耗，反而因为使用成本大幅降低，导致煤炭的整体消耗量呈指数级暴涨。在不久的将来，当我们惊叹于某个 AI 助理能在一分钟内帮我们抢完票、订好酒店、规划好完美行程时，在这个助理不可见的底层黑盒里，正有成百上千个 Jev 决策节点，在以几十毫秒的速度，默默进行着无数次确定的、精准的二进制跳动。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十一）｜DeepSeek-Harness（二）快速开始：CLI 与 Web UI]]></title><link>https://blog.csdn.net/wshzd/article/details/166137618</link><guid>https://blog.csdn.net/wshzd/article/details/166137618</guid><author>wshzd</author><pubDate>Sun, 20 Sep 2026 17:38:54 +0800</pubDate><description><![CDATA[这条路径本质上仍然是"装配出前面讲的同一棵插件树"，只是把"谁来托管 Web UI 的浏览器窗口"从系统浏览器换成了 Electron 自带的 Chromium——对理解"CLI 装配 Profile"这条主线没有影响，值得知道的是它的存在，具体的打包与更新机制不在本课程的讨论范围内（这是一个 2026-08-28 之后才出现的能力，本课程后续章节的源码解读仍以。只是两个内置的 Profile 名字，CLI 层只负责"选中哪个 Profile、传哪些参数"，剩下的装配逻辑完全共享。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（九十）｜DeepSeek-Harness（一）安装与环境准备]]></title><link>https://blog.csdn.net/wshzd/article/details/166134596</link><guid>https://blog.csdn.net/wshzd/article/details/166134596</guid><author>wshzd</author><pubDate>Sun, 20 Sep 2026 15:56:11 +0800</pubDate><description><![CDATA[一个 229 个 leaf 包的 monorepo，如果对 Node/pnpm 版本、git hooks、凭证来源不做任何约束，会出现的典型问题是：贡献者 A 用 Node 20 装出来的依赖树和贡献者 B 用 Node 24 装出来的不一致；也就是说 CI 会在三条 Node 版本线上跑（22.19、24、26），22.19 是一条被刻意选中的下限（而不是随便一个当时的最新小版本），这背后往往是某个 Node 22 补丁版本修复了一个 harness 依赖的运行时问题。下一篇会在装好环境之后，正式跑起。]]></description><category></category></item><item><title><![CDATA[LLM之Agent（八十九）｜PI（二十八）测试策略：Faux Provider 与 Evals]]></title><link>https://blog.csdn.net/wshzd/article/details/165888260</link><guid>https://blog.csdn.net/wshzd/article/details/165888260</guid><author>wshzd</author><pubDate>Fri, 18 Sep 2026 18:57:32 +0800</pubDate><description><![CDATA[evals 问的是"这套提示词/工具/模型的组合，在真实模型的不确定性下，完成任务的成功率有多高"，是概率性的、需要用对照组和评分机制来衡量的。这是一个跳出"人写断言、代码跑断言"传统思路的用法：与其靠人工 review 保证文档不过时,不如让 Agent 本身（既然它就是要去读这些文档来理解自己怎么用）充当审计员，用它自己的阅读理解能力去比对"文档说的"和"代码实际做的"是否一致，再用一个。这与前面单元测试"绝不使用真实密钥"的原则形成了鲜明对比——evals 存在的意义就是观察真实模型的真实行为。]]></description><category></category></item></channel></rss>