空缺的博客

生命不息，折腾不止。上一篇我们亲手写了一个插件，这一篇反着来——不写代码，一条命令把别人写好的插件搬进来，五分钟把 Agent 武装起来。 上个月我们搞定了 DeepSeek Harness（下称 dsh）的基础安装和「写第一个插件」，算是把「一切皆插件」的骨架摸了一遍。但说实话，什么都自己写太累了，一个能用的 Agent 要的插件堆起来能绕地球半圈。好在 dsh 的生态起得飞快，社区已经攒了一堆现成插件，还有专门的插件市场帮你挑。这篇就讲清楚：去哪儿找插件、怎么一条命令装上、装完怎么验证、以及装第三方代码时安全这条线怎么守住。 一、先想清楚：你在「用插件」还是「写插件」dsh 的插件机制上一回已经讲过核心——每个能力都是插件，插件通过一个 dsh.bundle 清单告诉 Harness 自己贡献了什么。落到使用上，就有两个完全不同的动作： 写插件：自己在本地写代码、打包成 bundle 再挂上去（上一篇文章干的活）； 用插件：从 npm 或 GitHub 把别人打包好的 bundle 拉下来，装进某个 profile，重启就能用。 这篇专注第二个动作。你只需要记住两个名...

生命不息，折腾不止。上一篇把「权限」和「沙箱」两个旋钮盘明白了，这一篇钻进去看沙箱本身——dsh 到底靠什么把命令关进笼子，又是怎么靠一条命令就能验出这笼子是铁的、还是纸糊的。 上一篇聊到最后，我留了一句挺关键的话：dsh 的沙箱不是「绝对安全边界」。这话只说了一半，今天把它补完整——沙箱这条链路上，ctx.sandbox.confine 到底在做什么，三套后端（Linux 的 bwrap / Landlock、macOS 的 Seatbelt、Windows 的 ACL）各自怎么落地文件隔离，为什么有的地方只能「部分生效」，以及最要命的：文件被锁死了，沙箱就真的安全了吗？ 一、先破除一个错觉：dsh 的沙箱，只管「文件写」这一件事一提「沙箱」，很多人脑子里浮现的是 Docker 那套——网络隔离、进程隔离、文件系统隔离全套。但 dsh 的 ctx.sandbox 不是这么回事，它的官方定义窄得有点反直觉： SandboxMode 只管 filesystem effects（文件系统的写入效果），三个档：read-only（只读，只放行 /dev/null 这一个...

生命不息，折腾不止。上一篇让 Agent 学会「给自己造工具」，这一篇补上最关键的那道闸：造出来的工具、跑起来的命令，到底谁能写文件、谁得先问你一句——两个旋钮，一个叫沙箱、一个叫审批，今天就把它俩彻底盘明白。 接上一篇的尾。Creator 模式聊到最后，收在了一句挺吓人的话：「沙箱 ≠ 安全边界，信任这套工具集，等价于信任 bash」。那句话其实只讲了 cordis_* 那七个工具自带的 node:vm 沙箱。今天要聊的，是 dsh 每个 Agent 每次跑命令都会过的那道文件边界——权限系统（Permissions）。 这套东西看着简单，其实最容易被两拨人同时误解：一拨人以为「开了 danger-full-access 就百无禁忌」，另一拨人以为「开了沙箱就刀枪不入」。两个都是错的。咱们一层层拆。 一、先分清：权限（Permission）和沙箱（Sandbox）不是一回事这是官方文档开篇就警告的点，但 90% 的人会把它俩混成一个词。它俩的分工清清楚楚： 权限（Permission） 沙箱（Sandbox） 管什么 操作的「模式档」+ 要不要批准 命令执行那...

生命不息，折腾不止。DeepSeek Harness 最反直觉的一招：Agent 不只能「用」工具，还能在运行时给自己「造」工具——Creator 模式配七个 cordis_* 工具，就是这套「自进化」的总开关。 前两篇我们把 dsh 跑起来、接上了自定义 Provider（想接 Claude/GPT 的话，中转站 ai.aklibk.com 国内直连、免绑卡、人民币按量付费，上一篇文章有完整步骤）。今天聊点更野的：让 Agent 在跑的时候，自己查运行时、自己写插件、自己热插拔。这就是 Creator 模式。 一、Creator 模式到底是什么dsh 一共四个运行模式，切模式切换的不是模型，而是「这台 Agent 被允许拥有什么手脚」： Standard（标准）：完整工具组合——文件编辑、shell、搜索，默认的编码 Agent 就是它。 Code（代码，也叫 PTC）：让模型生成一段代码来编排多轮工具调用，而不是一次只吐一个工具调用。 Minimal（极简）：只留一个 shell + 一个文件编辑工具，专给模型做基准测试用，是最诚实的「框架本身贡献了多少」的测...

生命不息，折腾不止。dsh 自己就是 DeepSeek 的模型，但它偏偏设计成「谁都能接」——这集把自定义 Provider 讲透，一个框架通吃所有 OpenAI 兼容的大模型。 前两集咱们把 Harness 装起来了、也写了第一个插件让 Agent 会调工具。但这套框架真正香的地方，在于它默认就是个「多模型挂载台」：DeepSeek 自己的模型只是其中一个插件，Claude、GPT、Gemini、本地 Ollama，只要走的是 OpenAI 兼容接口，都能塞进来，而且不换工具、不重装、只换一个 key 的事。今天就把「自定义 Provider」这条进阶路线一次说清。 一、先分清：目录供应商 vs 自定义 Provider打开 Settings → Models，点「添加供应商（Add provider）」时，你会看到两条路： 目录供应商（catalog provider）：Anthropic、OpenAI、Google 这类官方渠道，dsh 已经把 SDK 和字段模板给你备好了（默认安装里甚至把 @anthropic-ai/sdk、@google/genai 这些依赖都拉...

生命不息，折腾不止。上一课给 Claude Code 装好了「手脚」和「习惯」，这一课再给它立「规矩」——用 Hooks 在它每次动手前后自动挂上检查，改代码先跑测试、提交前先过 lint，把「人盯着才放心」变成「代码自己把关」。 上篇结尾我把话说在前头了：第一课聊 MCP 和自定义命令，第二课聊 Hooks。今天就来兑现。这玩意儿是 Claude Code 里最容易被忽略、又最能让它「上生产」的能力——不靠模型记性，靠写死的代码，每次触发、无一例外。 一、为啥要 Hooks：那 5% 的翻车，靠「记得提醒」防不住Claude Code 平时是真能干，问题是它偶尔会自信地犯错：把改动推到 main、跳过格式化、提交没过 lint 的代码、顺手 rm -rf 掉不该删的目录。这类事故概率不高，可一旦发生就伤筋动骨。 有人觉得「我在 system prompt 里写一句『提交前先跑测试』不就完了吗」。现实是这一句不靠谱： 模型会忘，prompt 越写越长，它抓不住重点； 模型会糊弄，觉得「这次改动很小不用测」； 换个人、换个模型，这句提示词就跟着换，约束力全看运气。 Hook...

生命不息，折腾不止。Claude Code 光会聊天可不够——今天给它接上 MCP 外部工具、再存几条自定义命令，把它从「会说话的助手」调成「能自己把活干完的工程师」。 RAG 实战六课收官之后，咱们开个新系列：Claude Code 实战。上一课结尾也把话说死了——第一课不聊安装，那个基本盘早就铺好了，直接上两个进阶玩法：MCP 和 自定义 Slash Command。 这俩东西，一个解决「手脚问题」，一个解决「习惯问题」。搞明白它俩，你才算是真的会用 Claude Code，而不是把它当个高级聊天框。 一、先看清短板：Claude Code 到底缺啥Claude Code 本身其实已经挺能干：读你项目里的文件、改代码、跑 bash、写测试，这些它天生就会。但真拿到生产上用，你会很快发现它有两个卡脖子的问题。 第一个，手不够长。 它默认只能碰「你自己仓库里的东西」。GitHub 上的 issue、数据库里的数据、网页上的内容、Notion 里的文档——这些都在它够不着的地方。你想让它「去 issue #123 看看需求再改」，结果只能你自己打开 issue 页面、复制粘贴给...

生命不息，折腾不止。RAG 最怕的不是答不上来，是检索错了还一本正经地胡编——今天给它装个「质检员」，检索结果不合格就自动纠错。 前五课咱们从零手搓了一条文档问答链路：向量检索加混合检索（第二课）、reranker 精排加打分（第三课）、答案带出处加评测（第四课）、多轮记忆加 query 改写（第五课）。这条线越走越顺，但有个致命前提一直没点破：检索返回的东西，咱们默认它是对的。 可问题是，向量召回出来的 top-k 里，经常混着几条跟问题八竿子打不着的文档。传统 RAG 不管这个，捡到啥就往 prompt 里塞，模型一看上下文里全是杂音，就开始一本正经地胡说八道。这不是模型笨，是咱们把垃圾喂给了它。 今天收官这一课，就把这个洞补上：给 RAG 装一个「质检员」，先检查检索结果质量，合格才用，不合格就纠正。这套玩法有个正经名字，叫 CRAG（Corrective RAG，纠错式检索增强），2024 年初中科大、UCLA 和 DeepMind 的作者在一篇论文里提出来的（arXiv:2401.15884，官方代码 github.com/HuskyInSalt/...

生命不息，折腾不止。前四课把 RAG 做成了「能查、能测、能信」的一问一答机，但你一问「那它的增长率呢」，它当场装死——今天给链路装上「多轮记忆 + query 改写」，让知识库从问答机升级成记得住上下文的对话助手。 上一课收尾时留了个话头：检索、精排、生成三层其实已经闭环了，但有一个更贴生产的高频场景一直没碰——多轮对话。用户第一句问「承德奇聚 2024 年的营收是多少」，第二句顺嘴追问「那它的增长率呢」。第一句还好，第二句里那个「它」指的啥？没有任何上下文的话，纯靠字面根本没法检索。这种「残缺追问」，恰好是现实里最常见、也最让单轮 RAG 翻车的场景。 今天这一课，就在前四课手搓的那条管线上，加两块新零件：一个多轮记忆（把每轮对话攒起来），一个 query 改写（把「它」补全成完整 query）。还是老规矩，不引框架，纯手写 Python，代码复制下来就能跑。 一、先看清死穴：追问进来的那一刻，就翻车了回想前四课的检索链路，本质是「用户问题 → 向量化 → 相似度检索 → 喂给大模型」。这套链路默认一个前提：用户每次问进来的，都是一句完整、自洽的话。可现实里的对话根本不是...

生命不息，折腾不止。前三课把「召回 + 精排」做得能查能测了，但用户拿到手的是一段没有出处、不知道靠不靠谱的文字——这课给答案装上「引用出处」和「生成层打分」两样东西，让回答不光有据可依，还能摊开给你看它凭啥这么说。 上一课收尾时留了个口子：检索端你已经能做「召回 → 精排」，但那套 recall / MRR / hit 指标只证明「该捞的捞回来了」，没回答用户真正关心的两件事： 这答案哪来的？ 大模型吐出的话，用户想问一句「依据呢？」，你答不上来，信任就崩了。 这答案编没编？ recall 再高，生成那一步照样可能满嘴跑火车——而且 RAG 的失败往往「不报错」，只会给你一段流畅、自信、但错得离谱的文字，没有任何异常日志，你连它错了都不知道。 这就是这一课要补的最后一块：生成层。干两件活——让答案带内联引用 [1][2][3]，再用 faithfulness（忠实度）、答案正确性这些指标给生成这一步打分。做完，「召回 → 精排 → 生成」这条链路才算真正闭环。 一、先分清：检索层指标 vs 生成层指标，测的不是一回事很多人评测 RAG 会犯一个错——...