给 DeepSeek Harness 做一次极限试探：Linux 上的可用性记录

　　DeepSeek Harness 刚发布没几天，我就把它装到了一台 Linux 服务器上，目的只有一个：用最大可能，去试探它的可用性。不是用它干活，而是逼它出问题。插件自由拼接、自我修改、快照备份随便蹬——这些宣传里最诱人的词，恰恰是最需要被怀疑的词。测完一圈，我的总结很朴素：架构是对的，但生成效率很低，它还是个雏形，后续需要大量版本迭代。

一、为什么是 Linux 服务器

　　装到 Linux 上不是偶然。这类 harness 天生适合干净、透明、权限可控的环境：插件即文件、配置即代码，改一处配置热加载、重启服务，都比桌面系统顺手得多。更重要的是隔离——用独立用户加 systemd 约束，或干脆丢进容器，把 agent 能碰的目录、端点、权限先焊死，再放开让它跑。快照备份之所以"随便蹬"，也是因为 Linux 下 LVM、btrfs、zfs 的回滚足够快，蹬坏了一键回到原点。

自由的前提是可控。不怕它乱来，怕的是它乱来时你拉不住。

二、测试矩阵：先定维度，再动手

　　真开始测才意识到，‘用到极限’也需要章法。我给自己列了一张矩阵，六个维度：功能覆盖、稳定性、并发、容错、副作用控制、一致性。每个维度对应一组高压操作：

• 极限拼接：把尽可能多彼此无关的插件一次性挂全，跑一个跨插件任务，看它们协同还是打架；
• 长时稳定：跑 6 到 12 小时的长任务，盯内存曲线有没有泄漏、磁盘增长正不正常；
• 红队容错：任务跑到一半 kill 掉进程，看它会不会自己拉起、状态丢不丢；磁盘写满、断网，看它怎么报错；
• 自我修改回滚：故意让它改错自己的配置，再测快照回滚是否干净，有没有残留的僵尸进程和脏文件。

　　这一套跑下来，可用性基本就现形了。复现性才是关键——崩一次不可怕，怕的是不知道它怎么崩的、能不能复现。

三、测出来的感受：架构对，效率低

　　绕了一大圈，最直观的感受浓缩成一句话：架构是对的，但生成效率很低。 这两个判断要分开看。

　　说架构对，是说它的方向没走偏。插件化把组装 Agent 的方式开源出来，模型适配器可换，连 Agent 的核心循环都能改——这在同类里是维度上的领先。自我修改、快照、沙箱这套机制设计得也自洽，说明骨架是经过思考的，不是拼出来的。

　　说效率低，是说工程化远没到位。工具调用经常串行等结果，长任务缺少增量处理，中间产物反复序列化，该有缓存的地方没有缓存。这些瓶颈不用动架构，纯优化就能提效，恰恰是雏形期最典型的欠账。更隐蔽的是另一种慢：生成质量一般，导致返工率高，单次速度再快，总成本都被放大。

「架构对」是方向值得押注；「效率低」是雏形期的正常债，关键看团队自己有没有在还债。

四、怎么判断值不值得继续跟

　　对这样一个雏形，我不急着下"好用还是不好用"的结论，而是看两个信号。一是迭代节奏：是不是高频发版、issues 反馈响应快不快；二是优化有没有动到核心路径：如果 release note 里频繁出现"并行化、缓存、性能提升"这类字眼，说明团队自己也觉出瓶颈在工程化，方向就对。

　　还有一个更实际的动作：把测出来的每个"效率低"场景，落成一个可复现的最小用例，整理成清单反馈给项目方。一个能复现的 bug 报告，比十句"感觉慢"有价值得多，也更能推动它迭代。

收束 · 当观察者，别当绑定者

　　这一圈测下来的结论是：它值得跟进，但别急着当作生产底座依赖。 现在最好的位置是当观察者——把快照打好，一次测一个维度，让每个测试的结论互不污染。等它再磨几个版本，等插件的杂草被真实世界剪过一轮，认真入手并不算迟。

　　架构对，是最值钱的判断，意味着这个方向值得押注；效率低，是雏形期的正常债，关键看还债的速度。把这两件事分开想，就不会因为"它现在还慢"而错过一个方向，也不会因为"它方向对"就盲目梭哈。工具会变，你攒下的测试结论和复盘，才真正跟着你走。