装之前先量三笔账：上下文、热重载、卸载
0次浏览0条评论0个赞
给写作流程加意图门时，我把三种形态摆在一起算了一遍：做成插件工具，6 个声明守在每一步；做成命令行，只在发布链里出现，带着 46 个测试。
写给准备自己动手加能力的个人开发者。先说三笔账，再给五个落点：上下文管每步成本，热重载管改动成本，卸载管退出成本。判断标准是三个数字：每个工具每步占多少字符、改一次要不要重启、删掉要留多少尾巴。
上下文账：一个工具算 200–400 字符，每一步都重发
工具声明不是写在文件里就完了。名字、描述、参数结构会进每一次请求的清单[2]，本机一个工具按 200 到 400 字符估。92 个工具就是两三万字符，占掉固定文本的三分之一[4]。
换算一下：按 50 步的会话算，一个 300 字符的工具累计占 15,000 字符的输入量。它值不值，取决于这 50 步里它被调用了几次。
固定文本里工具只占三分之一，另外两块是系统提示与每轮注入；注入块一旦写进去就永久留在历史里，删不掉。
所以装之前的第一个动作是记数，不是写代码。跑一次预算检查，记下工具数与固定文本字符数；装完再跑一次，差值就是这次扩展的每步成本。数字变大不是错，讲不出为什么变大才是错。
工具输出也要计入。返回值整段进入上下文，一个把构建日志原样吐回来的工具，一次调用就能顶掉几万字符；让工具只回摘要与路径，是这笔账里最容易被忘掉的一半。
工具数也不是唯一变量，描述写得多详细同样计入。同一个工具，描述从 40 字扩到 120 字，每步就多付两倍；描述该写清「何时用」，不该复述实现细节。
有一种写法会让这笔账看起来消失。PTC 模式把 47 个工具的声明搬进系统消息，工具列表只剩一个入口，合计约 11.3k token 仍在每一步里[3]。只量工具列表的检查会报假绿，量固定文本才不会。
还有一种量法看目录：按需组的组目录一次注入 13,090 字符，模型平时只看见组名与组内工具数量。目录越长，选组越难，开错组的概率越高；这属于间接成本，不体现在工具数里。
热重载账：一次改动换来一次重启，迭代成本按天一算
第二笔账决定改一行代码要付多少。bundle 插件的客户端部分要重启进程才会重新扫进启动清单，重载命令对它无效[1]；运行时注入的插件才能热重载与自重载。
验证方法很直接：改一个页面上可见的字，刷新；没变就是要重启。把这个动作乘以当天的改动次数，就是热重载账。选形态时还有一个更快的替代：这个能力改十次和改一次，代价差多少倍？
这不是理论差别。写插件的头几天，一天改十次界面很正常；如果每次都要重启进程、重开会话、重新加载上下文，迭代成本按小时算。反之，一个逻辑很稳、改动很少的能力，重启成本可以忽略。
重启的代价不只是几十秒。会话中断意味着上下文重建，刚才读到一半的文件、刚试出来的参数都要再来一遍；改十次就重建十次。能热重载的形态把这份代价降到一次刷新。
判据可以写成一句：一天要改几次？ 十次以上，优先选能热重载的形态，或者先写成命令行；一周改一次，重启就不构成理由。
卸载账：删目录只要一秒，删干净要看三处残留
第三笔账最容易被忽略，因为装的时候一切顺利。删之前先确认目标目录不是符号链接：依赖目录里的链接不会出现在依赖声明里，删错一边会留下悬空引用。
回滚点要在装之前准备好。本地链接型插件不能用会重建产物的备份工具，它的准备步骤会先清理再构建，构建一失败就把产物一起删掉；用 tar 做快照更稳[4]。
删完按顺序查三处：工具名是否还挂在按需组目录里，配置层是否还留着整段，依赖目录有没有悬空链接。配置覆盖按 id 整段替换，不做深合并，所以删掉插件不等于删掉它留下的整段配置。一个卸不掉的能力，比一个装不上的能力更贵。
插件的残留还会写进配置层。本机把停用项列在插件 exclude 清单里，每条附一行理由；删插件时若只删目录、不删这一行，下次排查会看到一条永远不生效的排除项。配置与目录要一起删。
回滚点也要验证：快照之后在临时目录里解一次，确认文件齐全再动手。删除的顺序建议反过来：先摘配置，再删目录，最后清依赖链接；反过来做，中间状态会留下指向不存在目录的配置。
图 1：三笔账的判据与失败后果；三笔都能落到数字或命令上。
三笔账算完，需求只剩五个落点
| 落点 | 触发时机 | 每步成本 | 改一次 | 删干净 |
|---|---|---|---|---|
| 脚本 / CLI | 人、构建脚本、定时任务 | 零 | 改完即用 | 删包与配置 |
| Skill | 模型按需加载 | 目录一次 | 下一轮生效 | 删目录 |
| 按需组 | 模型偶尔需要，但不必每步在 | 开组一步 | 改完需重启 | 从组里摘掉 |
| 常驻工具 | 模型必须自主决定何时用 | 每步声明 | 要重启进程 | 摘插件与配置 |
| MCP | 已有服务，或跨客户端复用 | 每步声明，可会话启用 | 服务侧重启 | 断开连接 |
把三笔账套在意图门上：上下文账为零，命令不占清单；热重载账为零，改完即用；卸载账只有一处，删包与 Skill 里的一行命令。三项全过，选它。
套在视觉记忆上：上下文账每步都在场，七个工具；热重载账要重启，改的是 bundle 客户端；卸载账两处，插件与配置。三项都付得起，因为它必须由模型在写作中途自主调用。
量法可以更省：不必为每个能力都跑完整三笔。先用一句话筛，触发时机是流程还是模型；前者直接进命令行或脚本，剩下少数几个再量上下文与卸载。
同一套账，两个相反的结论，差别不在能力大小，在触发时机与调用频率。
这两个例子也解释了为什么不要一上来就写插件：意图门的调用时机是发布流程，视觉记忆的调用时机是模型自己；前者写成工具，每次发布都要多背 6 个声明，后者写成命令行，模型永远不会想起它。
结论：先从最轻的形态起步，升级只看频率
个人开发最容易犯的错是一步到位：需求刚出现就写插件，结果每周只用一次，却让声明守在每一步。
可行的顺序是五级台阶：先写一个 .mjs 跑通，一周调用三次以上再包成命令行；方法需要被模型提醒时，加一份 Skill；一周调用多次但不必每步在场，放进按需组；只有在「模型必须自己决定何时调用」时，才升级成常驻工具。
升级的触发条件是频率与决策归属，不是「插件看起来更正式」。反过来，降级也该果断：一个工具两周没被调用过，或者调用它的其实是脚本而不是模型，就说明它站错了位置。
一个人维护的能力，最常见的死法是装上去之后再没人动它。三笔账的作用，是逼你在装之前想清楚它会怎么被改、被删。
图 2：五级台阶，每升一级换来一点能力，也多付一点每步成本。
反例与边界：三种装法会把迭代拖慢
为每周一次的功能加常驻工具。 声明每步都在，调用却一周一次。它错在把一次性成本摊到了每一步，不在功能。
把需要模型自主判断的能力做成命令行。 模型看不见它，就不会主动调用。判据是：如果「什么时候用」需要模型决定，它必须进上下文，哪怕先进一个按需组。
把没有形态需求的一次性脚本做成任何形态。 迁移脚本、一次性校验、临时采样，写完就删最省事。给它设计插件结构，只是把明天的删除成本提前到今天。
把长任务塞进工具。 一个跑十分钟的构建做成工具调用，模型只能等，超时与断连都算工具失败；放进程外跑，工具只回一个任务号，进度另外查。
把个人插件当团队默认。 一个人装，所有人的清单都变长；共享能力要走团队流程，那是下一篇的内容。
边界也要说清。单机自用、没有第二个人依赖时，三笔账都可以放宽：上下文不紧张就先用着，删不干净也能手动收拾。团队场景不成立，因为第三个人会替你付这笔账，下一篇专门算它。
还有一种情况不用量：能力只服务一次判断，比如某次排版取舍，写进文章就够，不必变成系统能力。反过来，已经在用的能力如果每周被调用超过五次、又经常需要临时改，就值得把三笔账重新算一遍，看看是不是站错了位置。
动手清单：5 行问答 + 3 条命令，装前先走一遍
先把三笔账写成一张纸，留在文章目录里，下次装东西前直接改，再动手：
- 它一周被调用几次？少于三次，先写脚本。
- 调用时机由谁决定？模型决定才需要进上下文。
- 我一天会改它几次？超过十次，优先热重载或命令行。
- 删掉它要动几处？超过两处，先补一条回滚命令。
- 它崩了会拖垮谁？会拖垮主进程，就放进程外。
# 装前：记录工具数与固定文本
node deploy-dsh/tool-budget-gate.mjs
# 装后：再跑一次，差值是每步成本
# 回滚点：先快照，再动手
tar -czf plugin-backup-$(date +%F).tgz <插件目录>
# 卸载后：查残留
grep -rn "<工具名前缀>" ~/.dsh/profiles/web/cordis.patch.yml ~/.dsh/config.yaml预算检查会输出三样东西：工具总数、固定文本字符数、缓存尖峰次数。装前记下来，装后对比；尖峰变多说明安装动作本身在打断缓存。
四步里，第一步给出成本，第三步给出退路，第四步确认退干净。缺任何一步，装的时候就该停一下。
下一篇：个人账算完，团队账多出 3 个维度
个人只要对自己负责，三笔账算完就能动手。团队不行：谁能装、崩了谁修、走了谁退，三件事都要有名字。所以团队要回答的不是「装不装」，而是「每一行有没有回滚动作」；准入、失败、退出看起来是三张表，实际是同一张表的三个列。
参考文献
[1] DeepSeek Harness. 插件与生命周期[EB/OL]. 开发文档, 2026. https://deepseek-harness.github.io/deepseek-harness/develop/framework/
[2] DeepSeek Harness. 开发一个 Tool[EB/OL]. 开发文档, 2026. https://deepseek-harness.github.io/deepseek-harness/develop/basic/tool
[3] Anthropic. Code execution with MCP[EB/OL]. 2025. https://www.anthropic.com/engineering/code-execution-with-mcp
[4] 本站. 从字节数账：上下文预算到底花在哪[EB/OL]. 2026-10-17. https://xiciyang.com/blog/token-audit-from-bytes/
评论
填个昵称就能发，不需要注册或登录