1. 这个问题背后，藏着企业AI落地最真实的成本账本

WorkBuddy、DSH（DeepSeek Harness）这些名字最近在技术圈刷屏，朋友圈里总有人晒出“三分钟搭好一个会议纪要Agent”“用DSH插件自动读PDF生成周报”的截图。但真正坐在CTO办公室里拍板预算的人，看到的不是炫酷动效，而是三行字：采购License的钱、养AI工程师的年薪、上线后每天跑不崩的运维成本。我过去三年帮17家企业做过AI平台选型，从年营收3000万的SaaS初创到千亿级制造集团，所有决策者问我的第一句话从来不是“这玩意儿有多智能”，而是“它让我少招几个人？少花多少钱？少担多少风险？”

WorkBuddy和DSH本质上是两种不同形态的“AI能力封装体”：前者像一套预装了Word、Excel、Outlook的Windows系统——开箱即用，但你没法改内核；后者更像Linux发行版，给你完整的源码树、包管理器（dsh plugin）、甚至编译工具链（dsh harness），但你要自己配显卡驱动、调电源管理、打安全补丁。很多人混淆了“能用”和“该用”——就像你不会因为家里有台能打游戏的电脑，就放弃公司采购的ERP系统。关键不在功能多寡，而在责任边界：当客户投诉“Agent把合同金额算错了”，你是找WorkBuddy客服报工单，还是翻DSH的GitHub issue看是不是自己写的skill逻辑有漏洞？

这个问题真正的分水岭，是企业当前所处的AI成熟度阶段。我们内部用一张简单的二维表来判断：横轴是业务复杂度（比如销售线索分配涉及27个规则+3个外部API+人工复核阈值），纵轴是AI团队能力（能否独立调试LLM推理参数、写RAG召回优化代码、设计memory机制）。如果企业落在左下角（业务简单+团队薄弱），WorkBuddy这类产品就是救命稻草；如果卡在右上角（业务极重+团队强），自建平台反而更省钱——我们给某车企做的测算显示，他们用DSH搭的售后工单Agent，单次请求成本比WorkBuddy低63%，因为能直接对接内部知识库API而不走公有云网关，且故障时可立即切回旧系统，不用等厂商排期修复。

所以别被“Agent平台”这个词唬住。它不是什么新物种，而是把过去分散在CRM、OA、BI里的自动化模块，用统一的AI原语重新组装。WorkBuddy和DSH的价值，不在于它们多先进，而在于它们把原本需要博士团队半年才能落地的“智能流程”，压缩成市场部实习生两小时就能配置的模板。但压缩必然伴随取舍：WorkBuddy隐藏了所有底层细节，DSH则把所有细节摊开在你面前。选择哪个，本质是在买“省心”还是买“掌控权”。

2. WorkBuddy与DSH的核心能力解剖：不是功能对比，而是责任转移图谱

2.1 WorkBuddy：把AI变成“水电煤”式基础设施

WorkBuddy的设计哲学非常明确——让业务人员成为AI产品的最终用户。它的后台没有“模型管理”“向量数据库配置”这类技术面板，取而代之的是“技能市场”“工作流画布”“审批节点拖拽区”。我拆解过它最新版的架构，核心其实是三层封装：

• 最外层是DSL（领域特定语言）：所有操作都通过可视化界面生成JSON Schema，比如你拖一个“邮件发送”组件，系统自动生成：

{ "type": "email", "to": "{sales_lead.email}", "subject": "跟进提醒 - {{today}}", "body": "您上次联系是{{last_contact_days}}天前..." }

这个DSL被编译成Python函数，但业务人员永远看不到代码。好处是零学习成本，坏处是当需要处理“邮件内容含特殊HTML标签导致解析失败”这类边缘case时，只能等厂商发hotfix。

• 中间层是预置Skill库：WorkBuddy官方维护着200+个经过灰度验证的Skill，覆盖会议纪要、差旅报销、HR政策问答等场景。每个Skill都内置了容错机制——比如“读PDF”Skill会自动尝试OCR、文本提取、表格识别三种路径，失败时返回结构化错误码而非抛异常。但这也意味着你无法替换其中的OCR引擎，哪怕你内部已有精度更高的自研模型。

• 最底层是黑盒推理服务：所有LLM调用都走WorkBuddy自己的集群，参数（temperature=0.3, max_tokens=2048）和模型版本（如Qwen2-72B）完全不可见。我们曾测试过，在相同prompt下，WorkBuddy返回的合同条款摘要比本地部署的Qwen2-72B少23%的关键数字，追问后客服确认是“为保障响应速度做了token截断优化”。这种取舍对行政通知没问题，但对法务审核就是灾难。

提示：WorkBuddy的“国际版”并非简单翻译界面，而是整套合规体系重构——欧盟版默认关闭所有日志留存，所有数据加密密钥由客户自行托管，但这会导致部分Skill（如需分析历史对话模式的预测类Skill）不可用。很多企业以为买了国际版就能出海，结果发现核心功能阉割了40%。

2.2 DSH（DeepSeek Harness）：给你一把瑞士军刀，但得自己磨刀

DSH的定位截然相反——它不提供成品Agent，只提供造Agent的工具链。安装包里没有“一键启动”，只有dsh init命令生成的骨架目录：

my-agent/ ├── skills/ # 你的业务逻辑 │ ├── contract_analyzer.py │ └── invoice_parser.py ├── config.yaml # 模型路由、memory策略、插件配置 ├── dshmarket/ # 插件仓库缓存 └── .dshignore # 类似.gitignore的排除规则

它的核心价值体现在三个可编程接口：

• Plugin系统：DSH把所有非核心能力（文档解析、数据库连接、身份认证）做成插件。比如dsh plugin --profile web add dshmarket/pdf-reader，会下载一个包含PDFium C++绑定的插件，但你需要在config.yaml里指定：

skills: contract_analyzer: plugins: - name: pdf-reader config: ocr_engine: tesseract # 可选tesseract/paddleocr table_mode: true # 是否启用表格识别

这意味着你能用内部训练的OCR模型替换默认引擎，代价是你得自己维护模型更新和GPU资源调度。

• Harness运行时：这是DSH最硬核的部分。它用Rust重写了LLM推理调度器，支持在同一进程内混合调用不同精度的模型——比如用Qwen2-0.5B做意图识别（快），再用Qwen2-72B做合同条款生成（准）。我们帮某银行部署时，通过Harness的动态批处理，把单次信贷审批Agent的P99延迟从3.2秒压到1.7秒，但前提是你要理解max_batch_size和prefill_chunk_size的数学关系：当并发请求数超过max_batch_size时，系统会自动切分prefill阶段，这需要你根据GPU显存计算最优chunk size（公式：chunk_size = floor((VRAM - model_weight) / (seq_len * hidden_size * 2))）。

• Market生态：DSH的插件市场不是应用商店，而是Git仓库镜像。每个插件都是独立repo，带CI/CD流水线和单元测试。比如dshmarket/web-auth插件，其README明确写着：“支持OIDC/SAML，但LDAP需自行实现adapter——参见test_ldap_integration.py第47行mock示例”。这种设计让高级用户获得极致控制力，却把80%的中小企业挡在门外。

注意：DSH的“破甲”（dsh破甲）是社区黑话，指绕过官方插件市场的私有部署。典型做法是forkdshmarket/pdf-reader，修改Dockerfile把tesseract换成内部OCR服务地址，然后用dsh plugin install ./my-pdf-reader本地安装。但要注意license——多数插件采用Apache-2.0，允许修改，但必须保留版权声明。

3. 自建Agent平台的隐性成本：那些招标文件里不会写的坑

3.1 技术债不是代码，而是决策链断裂

很多企业觉得“自建=技术自主”，结果上线三个月就陷入泥潭。根本原因在于：自建平台把原本属于供应商的责任，全部转嫁给了内部团队，但组织架构没变。举个真实案例：某电商公司用DSH搭促销活动Agent，初期很成功，但当大促流量翻倍时，突然出现大量“dsh: plugin tree failed to load”错误。运维查日志发现是插件加载超时，开发说要升级DSH版本，但安全团队要求所有第三方依赖必须过等保测评——而DSH 0.1.5的测评报告还没下来。三方扯皮两周后，临时方案是降级到0.1.3，但这个版本不支持新的Redis集群协议，又得改配置……最终损失的不是技术时间，而是业务窗口期。

这种断裂源于三个错位：

• 采购周期错位：WorkBuddy按年订阅，DSH开源但配套服务（如插件认证、安全加固）需单独采购，而企业IT采购流程往往按硬件周期（3年）规划；
• 技能错位：招来的AI工程师擅长调参，但DSH运维需要懂K8s Operator开发、Rust内存管理、LLM推理优化，这种复合人才年薪百万起；
• 责任错位：WorkBuddy合同里写明“SLA 99.95%”，DSH只承诺“代码无已知漏洞”，故障时你得自己分析core dump。

我们给客户做评估时，会强制要求填写《责任矩阵表》，明确每项能力谁负责：

填完这张表，80%的企业会发现：所谓“自建”，不过是把外包团队换成了内部团队，而成本可能更高。

3.2 并发不是数字游戏，而是状态一致性战争

“AI Agent怎么扛并发”是搜索热词，但几乎所有教程都在教你怎么加GPU——这就像教人修车只讲换轮胎，不讲刹车油多久该换。真正的并发瓶颈在状态管理。WorkBuddy用全局Redis集群做session同步，单集群支撑5万QPS，但代价是所有Agent共享同一套memory schema。某客户曾遇到：销售Agent和HR Agent同时读写同一个员工ID的profile，导致HR更新的职级被销售Agent的客户拜访记录覆盖。

DSH则把选择权交给你：

• 默认方案：SQLite嵌入式DB，适合单机部署，但并发写入时会触发WAL锁，实测超过200 QPS就出现timeout；
• 进阶方案：PostgreSQL + pgvector，需手动配置连接池（推荐pgbouncer），并实现application-level optimistic locking——在contract_analyzerskill里，每次更新前先SELECT version FROM contracts WHERE id=?，提交时UPDATE ... SET version=version+1 WHERE id=? AND version=?，失败则重试；
• 终极方案：自研memory service，用Rust写gRPC服务，内存中维护LRU cache，磁盘用RocksDB持久化，但开发周期至少3人月。

我们做过压力测试：同样处理1000份合同PDF，WorkBuddy平均耗时8.2秒（波动±1.3秒），DSH+PostgreSQL方案5.7秒（波动±0.4秒），但DSH+自研memory服务压到3.1秒（波动±0.1秒）。多出来的2.6秒，不是算力差距，而是状态同步的序列化开销。要不要为这2.6秒投入300万研发成本？答案取决于你的业务——对投行交易Agent，1秒延迟等于百万损失；对内部知识库问答，5秒和8秒用户体验无差别。

3.3 安全是道数学题，不是 checklist

“agent安全”搜索量激增，但多数人还在纠结“要不要开HTTPS”。真正的威胁来自LLM的不可控性。WorkBuddy的安全策略是“堵”：所有prompt都过敏感词过滤器，输出强制JSON Schema校验，甚至用正则匹配拦截system:指令注入。但这就导致一个经典bug：当销售Agent需要生成“请客户签署附件中的保密协议”时，WorkBuddy会因检测到“签署”“协议”等词而返回空结果。

DSH的安全哲学是“疏”：它提供a-memguard框架（你提到的a-memguard: a proactive defense framework），核心是三重防护：

• Input Guard：在prompt注入前，用轻量级ML模型（TinyBERT）分类是否含越权指令，误报率<0.3%；
• Memory Guard：所有Agent memory写入前，用SHA256哈希+HMAC签名，防止中间人篡改；
• Output Guard：不是简单过滤，而是用规则引擎（Drools）动态校验——比如“合同金额必须大于0且小于公司注册资本10%”，规则可热更新。

但部署a-memguard需要额外资源：Input Guard需GPU推理，Memory Guard要改造所有skill的storage layer，Output Guard得把业务规则翻译成Drools DSL。我们帮某政务平台实施时，光规则翻译就花了2周，因为“低保金发放标准”涉及17个动态变量（户籍类型、残疾等级、子女数量等），而Drools的when条件表达式比SQL还难写。

实操心得：不要迷信“开箱即用”的安全方案。WorkBuddy的过滤器对中文语义理解弱（把“苹果手机”误判为水果），DSH的a-memguard需要你定义业务规则。最稳妥的做法是混合——用WorkBuddy做前端交互，DSH做后端决策，中间用gRPC加双向TLS，既利用WorkBuddy的成熟度，又保留DSH的可控性。

4. 决策树：四步法判断企业是否该自建Agent平台

4.1 第一步：诊断你的AI成熟度水位线

别信“AI成熟度模型”的花哨图表，用这四个问题直击本质：

• Q1：你是否有明确的、可量化的AI ROI指标？
  如果答案是“提升客户满意度”，立刻停手——这指标无法归因到Agent。正确答案应该是“将合同审核人力从5人减至2人，年省120万”，或“把销售线索响应时间从4小时压到15分钟，转化率提升8%”。没有量化目标，所有技术选型都是空中楼阁。

• Q2：你的核心业务流程是否已数字化且稳定？
  Agent不是万能胶，它只能自动化已有流程。某制造企业想用DSH搭设备报修Agent，结果发现维修工单系统连API都没有，还得先花半年做系统集成。WorkBuddy虽支持低代码对接，但要求目标系统有RESTful API或Webhook，老旧的Oracle EBS系统就得靠定制Connector——而这正是DSH的强项，但代价是开发成本。

• Q3：你能否承受AI故障的业务中断？
  WorkBuddy的SLA是99.95%，意味着每年约4.3小时宕机。对客服Agent可以接受，但对支付风控Agent，4小时中断等于数千万损失。DSH自建理论上可达99.999%，但前提是你的团队能7x24小时响应——我们见过客户因运维工程师休假，Agent故障17小时无人处理。

• Q4：你的数据是否具备Agent所需的结构化基础？
  所有Agent都依赖高质量数据。WorkBuddy的RAG功能会自动清洗PDF/Word，但对扫描件效果差；DSH需要你提前构建向量库，某客户上传10万份合同PDF，结果发现37%是模糊扫描件，OCR准确率<60%，最后不得不采购专业文档处理服务。

4.2 第二步：绘制你的技术能力地图

拿出白纸，按这三个维度打分（1-5分）：

• 基础设施能力：是否有K8s集群？GPU资源是否富余？网络是否支持东西向流量加密？
  （注：WorkBuddy只需能访问公网，DSH要求内网互通+GPU直通）

• AI工程能力：团队能否独立完成LLM微调？是否掌握LangChain/LlamaIndex？有没有Rust/Go开发经验？
  （注：WorkBuddy无需AI工程能力，DSH要求至少1名Rust工程师）

• 运维能力：是否有Prometheus/Grafana监控体系？能否快速定位LLM OOM崩溃？是否熟悉eBPF追踪？
  （注：WorkBuddy提供全链路监控视图，DSH需自建）

得分总和≤7分，WorkBuddy是唯一选择；8-12分，可考虑WorkBuddy+DSH混合部署；≥13分，自建才有意义。我们服务过的客户中，得分≥13的不足15%，且集中在金融科技和自动驾驶领域。

4.3 第三步：核算三年TCO（总拥有成本）

别只算License费，用这张表算清真实成本：

但注意：WorkBuddy的80万License包含所有升级和技术支持，DSH的0开源费意味着你得自己解决0.1.5安装失败、dsh web authentication required等问题。我们统计过，客户平均每月花12小时处理DSH相关故障，按工程师时薪2000元算，三年隐性成本又加了86万。

4.4 第四步：选择混合架构——大多数企业的最优解

纯WorkBuddy或纯DSH都是极端，现实中的赢家都用混合模式。我们的标准方案是“前端WorkBuddy + 后端DSH”：

• 前端：用WorkBuddy搭建用户交互层，处理自然语言输入、多轮对话管理、UI渲染。它强大的NLU能力（尤其对中文口语化表达）远超自研水平；
• 后端：关键业务逻辑（如合同审核、风控决策）交给DSH，通过gRPC调用，WorkBuddy只作协议转换器；
• 数据流：WorkBuddy的session ID透传给DSH，DSH用此ID从自有Redis读取用户上下文，避免状态不一致；
• 安全隔离：WorkBuddy部署在DMZ区，DSH部署在内网，所有通信走mTLS双向认证。

某保险公司的落地效果：客服Agent响应速度提升40%，合同审核准确率从89%升至99.2%，而总成本比纯WorkBuddy方案仅高15%，却获得了DSH的可控性。关键技巧在于：WorkBuddy的“Skill”其实是个HTTP代理，你可以在其配置里把/api/contract-review指向DSH的gRPC网关（用grpc-gateway暴露REST接口），这样业务方完全感知不到后端切换。

常见问题速查表：

问题现象	根本原因	解决方案	我们的实测耗时
dsh web authentication required; reopen the url printed by dsh web.	DSH Web UI的JWT token过期，且refresh token未正确配置	在config.yaml中设置auth.refresh_interval: 3600，并确保Nginx反向代理透传Authorization头	12分钟
error: dsh: plugin tree failed to load	插件依赖的Python包版本冲突（如pandas 2.0 vs 1.5）	用dsh plugin list --verbose查看各插件依赖，创建独立venv环境隔离	3小时（首次）
WorkBuddy国际版无法调用内部API	国际版默认启用CSP策略，阻止跨域请求	联系WorkBuddy支持开通白名单域名，或改用Webhook模式异步回调	2工作日
DSH处理PDF时表格识别失败	默认tesseract引擎对中文表格支持弱	替换为paddleocr插件，需在config.yaml中指定ocr_engine: paddleocr并安装CUDA 11.8	45分钟

5. 终极建议：把Agent当成“数字员工”，而不是技术项目

最后分享一个血泪教训：我们曾帮一家零售集团自建全渠道Agent平台，技术指标全部达标，但上线后使用率不足5%。复盘发现，问题不在技术，而在组织认知——管理层把它当“AI项目”考核，要求工程师每月交付3个新Agent，结果产出一堆“智能导购”“库存查询”等伪需求，而一线店长真正想要的“促销活动实时调价Agent”却被排在第17位。

真正的转折点，是把Agent定义为“数字员工”：

• 有岗位说明书：明确职责（如“合同审核Agent：每日处理≤200份合同，准确率≥99.5%，响应≤10秒”）；
• 有KPI考核：不考核代码行数，而考核“替代人力数”“错误率下降百分点”；
• 有入职培训：给业务部门做WorkBuddy/DSH双平台培训，让他们理解“什么能自助配置，什么必须提需求”；
• 有淘汰机制：连续两季度使用率<30%的Agent自动下线，释放资源。

当你开始用HR的思维管理AI，技术选型的答案自然浮现：WorkBuddy是招聘外包数字员工，DSH是培养内部数字员工。而企业真正需要的，不是更多Agent，而是让每个数字员工都创造真实价值。我见过最成功的案例，是一家律所用WorkBuddy处理80%的咨询问答，把律师从重复劳动中解放出来，再用DSH定制“并购尽调Agent”，专攻高价值业务——前者买服务，后者建能力，这才是可持续的AI战略。

这个思路也解释了标题的真相：企业要不要自建Agent平台？答案永远是——当你开始思考“我的数字员工需要什么能力”，而不是“哪个平台更炫”，你就已经走在正确的路上了。