深度体验了几天 DeepSeek Harness，一个卡了我们很久的问题，终于有了更好的解法。我们是 Workbuddy 的深度用户，用了很久，它很香。但用得越深越清楚，有一类事它做不了。不是产品做得不好，是形态上就很难做到。8月13日晚上，DeepSeek-V4-Pro 正式版发布，跟着一起发布的还有 DeepSeek Harness，简称 DSH。这篇讲讲我们拿它做了什么。一、零代码 AI 办公平台的天花板Workbuddy 这类平台在企业全员普及 AI 理念的阶段很香，对没有技术背景的同学尤其友好：
不需要写代码就能生成一份很漂亮的网页版分析报告
不需要写一堆函数就能把一个海量数据的 Excel 整理清楚
不需要绞尽脑汁去思考内容排版，就能生成一份内容丰富的 PPT
……
在一个企业推广 AI 应用的初级阶段，这很有价值。但随着场景用得越来越深，会发现一个问题：这些平台生成的深度分析报告，大部分都偏离业务现实。原因也简单，它只有通用的推理能力，没有你的业务上下文。它不知道你上周做了什么活动，不知道昨天哪个版本在灰度，更不知道这个数据的关联数据变化是什么。下一个阶段要探索的，就是如何让 AI 结合业务自身的知识和数据，做更深度、且真正服务业务需要的分析和洞察。到了这个阶段，就离不开这三个维度的东西：
企业内部业务知识库
企业内部数据平台取数接口
可实现内部共享的 skill 体系
几家 AI 办公平台其实都在努力做这些事。但真做下来你会发现，知识库和 skill 分发都很容易解决，卡住所有人的，始终是取数接口这一步。企业核心经营数据的接口，不是不想开放，是不敢随便开放。这些接口大部分都需要在内网高可控的环境中获取，一旦要经过外部 SaaS 中转，法务、安全、审计，甚至是你心理那关，都很难过去。这个痛点一直存在。过去也不是没有解法，自研一套 AI Agent 平台就是了。但真要立项，成本、周期、维护、模型适配全是坑，大部分企业只是不敢随便启动。二、DeepSeek Harness 到底解决了什么DSH 的核心理念是"一切皆插件"（Everything is a Plugin）。模型、工具、技能、UI等等，所有 Agent 能力都是插件组合出来的，可以自由替换重组。底层是 Cordis 插件系统，官方的说法是：不改 DSH 源码，就能选、换、扩其中任何一项能力。但插件化本身，其实解决不了企业的数据问题。Dify 是插件化的，n8n 也是插件化的，市面上大部分 Agent 平台都是插件化的。DSH 在企业内网这个场景里能成立，真正靠的是这三条：一、全开源，能私有化。DSH 用 MIT 协议开源，可以整个拉进内网自己部署，模型层本身也是插件，敏感场景可以换成内部私有部署的模型（如果有的话）。数据链路从头到尾不出内网，这是任何 SaaS 形态的平台结构性做不到的。二、你写的取数插件，是挂在框架旁边的，不是打在源码里的补丁。DSH 后续怎么迭代都不会冲掉你的东西，卸载的时候注册效果也能干净回滚。三、有强大社区在替你维护这个底座。DSH 发布 12 小时 GitHub star 就破了 5 万，四天冲到 15 万以上，插件生态几天之内冒出来一大批。这意味着底座本身会有人持续维护和升级，而你挂在旁边的那些企业插件，又不会因为它升级而返工。自研平台最大的隐性成本从来不是第一版，是后面几年的跟进，这部分现在有社区替你分担了。这三条叠在一起，"自研一套企业 Agent 平台"这件事，就被简化成了"写几个可插拔的插件"。可落地性完全不是一个量级。网上这几天对 DSH 的插件机制争论很激烈，但在企业 AI 落地这个具体场景里，这几乎是目前最优解。三、一个具体的企业场景落地案例背景和目标：让 AI 每天对各业务板块的收款数据做汇总分析，涨了跌了，都要结合用户数据、系统状态、运营活动、产品发版做深度归因。过去的做法：每周由各业务部门人工从运营后台取数分析，每周集中汇报一次，讨论过程中遇到问题，再让业务负责人回头补相关数据分析。结合DSH，我们是这么做的：第一步：把内部运营后台的数据接口整理出来，让 DSH 基于这些接口生成一个数据调用插件。团队有自己成熟的后台运营系统，本身就有内部的调用接口和用户授权体系，大部分做过数字化的企业，这部分都是现成的。要做的只是把这块稍微整理一下，开放给 AI 调用。第二步：把研发的发版日志和运营的上线记录作为内部知识库，生成一个知识库调用插件。这一步的价值被严重低估。归因质量的上限，几乎完全由这个知识库的颗粒度决定。只有数据没有事件，AI 只能告诉你"涨了 8%"；有了事件，它才能告诉你"涨了 8%，大概率和前天那个版本的某个改动有关"。第三步：各业务团队基于自身业务特点，写各自的数据分析 Skill。这个 Skill 可以同时调用数据插件和知识库插件。关键在于 Skill 必须由业务方自己维护——因为口径、季节性、影响因素这些东西，只有业务负责人知道。不用担心业务同学不会写，在DSH中跟AI对话就能完成一个skill的构建。第四步：建一个公司级业务分析 Skill，调用各业务端 Skill 做汇总和交叉分析。这一层最容易出幻觉，也最需要防守。我们的做法是要求它的每一条结论都必须标注数据来源和对应的事件依据，凡是无法归因的波动，宁可写"未找到明确原因"，也不允许编一个听起来合理的解释。中立和可靠比漂亮重要得多。跑通之后，报告每日自动生成并推送到公司及各业务负责人的 OA，有疑问随时对话下探。这个模式跑下来，效果非常好！并且很快就能跑通demo方案，不需要经历漫长的系统研发流程。四、DSH 更有意思的地方，是让 Agent 参与扩展自己的能力DSH 有个很有意思的用法：你可以让它给自己写插件。改的是配置和插件，不是源码，所以下次升级不会被覆盖——这一点比"AI 能写代码"本身有意思得多。觉得写插件很难？没有任何技术也可以，如果你安装了DSH，试试给它发送这条prompt：请帮我修改 DeepSeek Harness 的网页 Logo。使用插件的方式实现，避免下次更新应用后被覆盖，Logo 文件见附件。从把它的鲸鱼换成你公司的 Logo 开始，那一刻，你就已经写完第一个插件了。后面无论是取数插件、知识库插件，还是各业务线的 Skill，路子完全一样，只是挂上去的东西不同而已。从这里开始，构建属于你自己的企业版 DSH～一些必须特别关注的点：第一，这是 v0.1 开发者预览版。 官方明确表示，当前仍有大量细节有待打磨，核心插件与底层接口还会快速迭代。现在阶段更适合结合场景做探索实现。第二，插件生态爆发得很快，但质量参差。 GitHub 上打 dsh-plugin 标签的公开仓库已经超过 700 个，什么都有。企业环境引入第三方插件，必须有审核机制，关键的插件最好自己来实现。什么是Harness？举个容易理解的说法：模型是脑子，Harness 是手脚——模型负责想，Harness 负责让它真的把事干成。更官方的定义是：大模型 + Harness = Agent
夜雨聆风
