DeepSeekHarness的新范式：让Agent为自己构建工具

关于 DeepSeek Harness 的这套插件逻辑，可以用这个例子来理解：

你在开会时，突然想“公司要是有个内容运营能一起参与讨论下该多好啊”，如果想要实现这个想法：过去，你得安排 HR 招人，招到了重新开会，开完讨论完还不能随便裁掉；现在，你可以直接“捏”一个内容运营加入到会议，讨论完直接把他优化掉。

过去，Agent 会话一旦启动，我们就不能往里塞工具了，那些 Agent 客户端也不允许我们修改它的核心逻辑、主流程。

dsh 这套“一切皆插件”，是把模型之外的一切(即 Harness)，包括 Agent 循环、Tool、HOOKS、记忆管理全部做成了插件，你可以用官方提供的 100+个“插件”作为 Agent 的 Harness，也可以自己随时 Vibe 一个更趁手的 插件把其中一个实现替换掉。

插件可以作为核心能力常驻，也可以作为“轮抛”的临时工具。

本篇后面所述场景及论述，由 dsh 根据 `cordis-plugin-development` skill 和我的几轮任务总结生成。

如有 slop，请见谅。

引子：一次普通的发布任务

假设你是产品经理，让 Agent 准备一个软件的发布包：

1. 把项目里 60 多张截图压缩成 WebP 格式，放进发布目录；

2. 生成一份资源清单文档；

3. 把全部文件打包成 zip。

听起来平平无奇。真正有意思的，是 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 的成长，不再依赖平台的每次升级，而是发生在每一次对话里。

补课吧，产品经理！

对产品经理来说，如果你不知道 Agent 如何调用工具，你几乎不可能设计出能被 Agent 调用的工具。

初次之外，还有一部分更重要、但更容易被忽略的：要像过去研究用户心理和用户行为一样，研究 LLM 的基本特性。

比如：

• • AI 拥有大量知识，但反倒更不可靠

• • 它为什么会把“听起来合理”当成“正确”

• • 哪些任务适合完整交给它，哪些环节用程序更合适？

• • 需要提供什么上下文，它才能把事情做对？

• • 怎么拆任务、加约束、设检查点，减少它一路错下去？

• • 产品要提供哪些工具、权限和反馈，Agent 才能稳定工作？

• • 一百万超长上下文，注意力机制为什么反倒更重要了？

• • ……

将来做产品，可能不只是研究“用户想怎么操作”，还得研究“Agent 要怎样才能完成操作”(这两个对象的特性差异其实挺大，应该会冒出不少新的产品方法)。

这些 Agent 时代产品经理需要掌握的基本功，我都压缩到《AI 产品经理转型实战营》线下课了。

两天课程，包括：

• • 大模型的基本原理、缺陷和使用边界（顺便学会用 AI 做市场调研、写 PRD、画高保真原型）

• • Workflow、RAG 和上下文工程（掌握 AI 赋能&Agent 赋能的关键能力原子化拆解）

• • API 调用、Tool Use 和 Agent 循环（上手开发一个真能干活的 Agent 程序）

• • MCP、Skill、CLI，以及怎样让产品对 Agent 更友好

• • Vibe-Coding 实战，从想法到可运行应用（三个 AI 赋能场景，交付完整作品）

第一期已经在过去的 1 个月完成交付，广受好评：

第二、三期开始招募，安排如下：

城市

时间

状态

上海-2期

8月22-23日

招募中

北京-3期

9月05-06日

招募中

深圳-3期

10月17-18日

招募中

课程原价 3999 元，限时早鸟价 2999 元将在二期开营前结束。

扫码可以查看课程详细内容、上课方式与详细安排。