关于 DeepSeek Harness 的这套插件逻辑，可以用这个例子来理解：
你在开会时，突然想“公司要是有个内容运营能一起参与讨论下该多好啊”，如果想要实现这个想法：过去，你得安排 HR 招人，招到了重新开会，开完讨论完还不能随便裁掉；现在，你可以直接“捏”一个内容运营加入到会议，讨论完直接把他优化掉。
过去，Agent 会话一旦启动，我们就不能往里塞工具了，那些 Agent 客户端也不允许我们修改它的核心逻辑、主流程。
dsh 这套“一切皆插件”，是把模型之外的一切(即 Harness)，包括 Agent 循环、Tool、HOOKS、记忆管理全部做成了插件，你可以用官方提供的 100+个“插件”作为 Agent 的 Harness，也可以自己随时 Vibe 一个更趁手的 插件把其中一个实现替换掉。
插件可以作为核心能力常驻，也可以作为“轮抛”的临时工具。
本篇后面所述场景及论述，由 dsh 根据 `cordis-plugin-development` skill 和我的几轮任务总结生成。
如有 slop，请见谅。
引子：一次普通的发布任务
假设你是产品经理，让 Agent 准备一个软件的发布包：- 把项目里 60 多张截图压缩成 WebP 格式，放进发布目录；
听起来平平无奇。真正有意思的，是 Agent 接下来怎么做——以及它做决定的那一刻。Agent 先确认了图片数量：60 张，共 83 MB。选择：用蛮力，还是现造一件趁手的工具？
方案 A：用常规方式硬做。让 Agent 一张一张地处理——这意味着 60 次操作调用，或者一条超长的命令；每次处理的结果都灌进对话里。做完之后，这段对话里会留下 60 份冗长的中间输出，像噪音一样污染后面所有的讨论轮次。任务完成了，对话也「脏」了。方案 B：现场给自己造一件一次性的工具。Agent 写一小段能力定义——「把某个目录下的图片批量转格式、压缩、输出到目标目录」——把这个能力现场注册成自己的一个新工具，激活它、调用它、看着进度条走完，然后用完即销毁。全程只需要一次调用、一份紧凑的总结。对话干净如初。DeepSeek Harness 的答案是：方案 B，而且这是系统性地支持的。这就是今天要讲的最佳实践——Agent 为自己构建工具。核心机制：能力不是出厂配置，而是现场装配
大多数 AI 助手的工具集是「出厂配置」：能做哪些事，在会话开始时就被定死了。能力缺口要么等平台升级，要么把代码硬塞进提示词里，要么靠用户手动配置。DeepSeek Harness 换了一种哲学：一切皆插件，插件即插即用。能力可以现场长出来：Agent 在对话中途发现自己缺一个能力，它可以当场把这段能力「写」成一个插件，加载进当前会话。加载完成后，这个插件提供的工具就凭空出现在 Agent 的工具列表里，模型下一步就能像调用自带工具一样调用它——不需要重启、不需要改配置、不需要等发布。能力可以现场消失：任务做完，插件被销毁，工具列表恢复原样。对话里只留下「用过一次」的痕迹，没有任何常驻负担。整个过程，就像给 Agent 一双可以随时戴上、随时摘下的手套。
一个完整的故事线
把开头那个发布任务完整走一遍，你会看到这条清晰的弧线：- 识别缺口：Agent 发现「批量转换 60 张图 + 实时进度 + 紧凑结果」是一个一次性的需求——不值得永久占着工具集。
- 先查后写：动手之前，Agent 先查一下当前环境里有哪些能力可以用、哪些接口是真的——不猜，先查。这是第一原则。
- 写插件：Agent 把能力写成一段插件定义。这段定义当场展示在界面上，用户能看到它到底要做什么。
- 激活：插件被加载进当前会话。因为插件里包含要在你浏览器里运行的界面部分，激活前需要你授权——你点一下「允许」，它才上岗。授权只针对当前这个版本。
- 调用：Agent 像调用普通工具一样调用它。界面上出现一张实时进度卡片：⏳ 转换中 37/60 · screenshot-36.png，进度条从 0 走到 100%。一次调用，60 张图，一个紧凑总结：「完成，共节省约 91% 的体积」。
- 继续主线：Agent 切回常规能力：抽查产物、写资源清单、打包 zip。全程不再需要那个插件。
- 销毁归零：任务完成，插件被停止、被彻底移除。再查工具列表：它消失了。对话里只留下一次调用、一个总结。
先澄清一个问题：这和「写个脚本跑一下」有什么区别？看到这里，你可能会问：Agent 本来就能写一段 Python 脚本、用命令行执行，插件多出来的到底是什么？这是最值得回答的问题。对模型来说，脚本是「一段文本」，插件是「一件工具」写脚本执行，对模型来说是一次性的「动作」：它把代码塞进对话，执行一次，拿到结果。脚本跑完就「死」了——下次想再用，得把代码重新拿出来、重新放回对话、重新执行。脚本的存在，不改变模型「会做什么」，只改变「这一次做了什么」。造插件，对模型来说是注册了一件「工具」：插件被加载的那一刻，这个能力就进了模型的工具箱——它有名字、有说明、有参数，之后模型像使用自带工具一样反复调用它，不需要再把实现代码放回对话。插件被销毁的那一刻，它又从工具箱里消失，模型再也看不到它。一句话：脚本是往对话里塞了一段代码；插件是往模型手里递了一把螺丝刀。一张表看全区别
一个类比
写脚本 = 临时叫一辆货拉拉：拉一趟货，付钱走人。效率高、直接，但每趟都要重新叫，你既看不到车在路上的实时位置，它也和你的日常工作没有任何关系。造插件 = 在园区里建一个配送站：先申请建站（激活，要审批）、挂上招牌（界面卡片）、配好人员（工具入列）。之后你可以反复下单（反复调用）、实时看进度（浏览器里的进度条）、甚至让站点自动巡检（定时任务）。不需要了，关站注销（销毁），人员设备全部撤走，园区恢复原样。脚本是「把活干一次」，插件是「把一个能力安置下来」。脚本是消耗品，插件是资产。
为什么这对产品很重要：五条最佳实践
理解了「脚本是消耗品、插件是资产」的区别，接下来这五条就不是技术细节了——它们直接决定用户体验和产品边界。这套机制不只是「很酷」，它解决了产品设计里几个真问题。1. 能力按需，工具集永不膨胀
如果每次遇到新需求就往工具列表里加一个常驻工具，Agent 的工具箱迟早会变成一个臃肿的瑞士军刀——工具越多，模型每次决策的负担越大，误选的概率越高。最佳实践是：常驻工具保持精炼，临时能力随用随造、用完即焚。工具列表是一个有生命的东西：需要时增长，完成后收缩，始终与当前任务匹配。2. 对话复杂度恒定
长对话最大的敌人是上下文污染：中间过程塞得越多，后面每一轮的推理质量越差。插件方式的精髓在于结果压缩：60 张图的处理过程，被压缩成一次调用、一个紧凑总结进入对话；插件销毁后，模型在后续轮次里甚至看不到这个工具的存在——没有选择负担，没有历史噪音。对话的复杂度，不会因为中途干了一件大事而永久上涨。3. 出错可回滚，迭代无成本
代码总有写错的时候。插件体系里，每一次修改都是一个新的版本，旧版本永远保留、随时可回滚。第一次激活失败了？没关系——看报错、修正、生成新版本、重新激活，旧版本还在原地待命。这给了产品一个非常实用的保障：试错是廉价的，能力演化是有迹可循的。4. 安全是设计出来，不是事后补的
「现场加载代码」听起来危险？Harness 把它变成了一个显式的信任流程：插件里要跑在你浏览器里的部分，激活前必须经过你的授权；授权是针对当前版本的——下次它升级了，需要你再次确认（也可以选择信任后续版本）；插件的所有副作用都是可逆的——停止、移除之后，界面、工具、监听，一切恢复原样，零残留。5. 一个插件，同时扩展 Agent 和界面
这可能是产品经理最该记住的一点：一个插件可以同时改变「它能做什么」和「你看到什么」。后端的能力（批量处理、文件操作、进度状态）和前端的表现（进度卡片、结果可视化、交互按钮）是同一个插件的两个面，它们天然配对、一起上岗、一起离职。这意味着第三方生态可以交付「完整的小功能」，而不是零散的接口——这对产品生态的想象力是决定性的。给产品经理的三句话
不要问「Agent 会不会用某个工具」，要问「Agent 能不能给自己造一个工具」。前者是配置，后者是能力进化。能力是资产，不是消耗品——但按需装配、用完可收。插件版本化、可回滚、可复用；需要时上岗，任务结束退场，系统永远保持轻盈。信任是流程的一部分。任何「会动」的能力都要过授权这一关，用户看到的不只是结果，还有控制权。结尾：一双随时可戴、随时可摘的手套
回到开头的发布任务。如果 Agent 只能用出厂配置，它会把对话搞得一团糟，或者干脆告诉你「这活儿我干不了」。而在 DeepSeek Harness 里，它做了一件更有趣的事：先给自己造一件工具，用它把活干完，然后把工具收起来，继续若无其事地工作。能力按需锻造，用完即焚，零残留——这不是一个演示技巧，而是一种关于 Agent 能力的全新工作方式：Agent 的成长，不再依赖平台的每次升级，而是发生在每一次对话里。
粤ICP备14082021号
免费POC，
零成本试错
