上个月和一位做内部智能体平台的负责人聊选型他说团队连续两周都在争论“用哪个大模型”结果真正把 agent 稳定跑起来、跑完一轮回归、拿到一个可信的通过率又花了两周。这个现象我见了太多次智能体基础设施选型大家默认先把目光落在模型却忽略了把 agent“跑起来”的这套运行壳以及决定“改得好不好”的评测闭环。今天想聊的 dsh就是围绕这个问题出现的。dsh 是一个偏工程向的智能体运行框架业内常直接叫它 harness核心不是教你写 agent而是把 agent 放进几种标准化的运行模式里命令行、服务、桌面、评测。它最打动我的一点是把评测闭环内建成了“第四种运行模式”而不是事后外挂一个评测平台。这篇内容适合正在选型智能体基础设施、想搭评测回归、或者纠结“要不要自研 agent runner”的团队。我会先讲清楚 dsh 在基建里的位置再逐一拆四种运行模式然后落到评测闭环怎么真正跑进日常迭代最后给一份我自己的选型建议。1. 先想清楚智能体基础设施选型选的根本不是模型1.1 智能体基建的四个必要组件缺哪个都跑不动很多团队理解的“智能体基础设施”就是模型API网关接一个key、换一个base_url、完事。真把一个agent放到产品里你会发现自己面对的是四层东西模型接入层多模型切换、密钥管理、成本控制、上下文长度处理。这一层通常由API网关或统一SDK解决。插件与工具层浏览器操作、代码执行、文档解析、HTTP请求。agent能不能“动手做事”取决于工具层是否丰富。运行层harnessagent循环感知-决策-行动、多步上下文累积、中断与恢复、会话状态管理。这一层决定agent能不能稳定跑完一个长任务是自研成本最高的一块。评测层离线评测集、自动评分、回归对比、质量趋势。没有这一层每次改prompt或换插件都靠“感觉”判断产品就永远是玄学。我用一个表格总结它们的核心问题和常见解法组件核心问题常见方案自研成本模型接入层怎么用上各种模型API网关、OpenAI兼容协议低插件工具层agent 能调用什么能力函数调用、插件市场中运行层长任务怎么稳定跑完harness/运行时框架高评测层改动了怎么知道变好还是变坏评测集自动评分高所以“智能体基础设施选型”这句话真正的重心应该放在运行层和评测层。这两个地方恰好是dsh这类harness型产品的主场。1.2 dsh 的定位它是个轻量 harness不是大而全的平台dsh 从设计上就刻意避开“编排平台”这个坑。它不强迫你学习一套可视化画布也不绑定某个模型厂商它做的事更朴素把你配置好的agent放进一个可运行、可重复、可观测的执行环境中跑。这个执行环境业内一般叫harness。dsh的harness层解决了三件具体的事标准化的agent循环把“调用模型-拿到工具调用请求-执行工具-把结果回填给模型”这个循环抽象好你只需要关注业务逻辑和工具实现。统一的profile概念模型、插件、参数都放在profile里。同一个dsh可以同时存在code、web、local等多个profile不同项目、不同运行模式都从同一个profile读取配置不会出现“CLI里能用、桌面上不能跑”的分裂。评测闭环的一等公民地位评测不是独立产品而是dsh内置的一种运行模式。这个设计让评测像run一样随手可用团队没有理由拖着不搭回归。我自己比较反感一类agent框架文档很漂亮但跑一个真实任务要写一堆胶水代码。dsh的路数更接近工程队——先给定一个能跑的壳再让你往里填业务。对大多数需要把agent用起来的团队这是更务实的选型路径。1.3 最小部署从一个 profile 开始把 dsh 跑起来安装方面dsh提供了多种渠道官方文档里列出了各平台的安装方式macOS上可以通过Homebrew安装Windows/Linux可以直接用官方安装脚本也可以在Release页面下载对应平台的二进制或桌面版安装包。装完CLI后第一步不是急着问“模型接谁”而是初始化一个profile。这里我以dsh 0.8以上版本的实际命令语法为例细节可能随版本微调但思路完全一致# 初始化默认配置 dsh init --profile code # 在配置里指定模型服务商 dsh config set provider.api_base https://api.openai-compatible.example-host.com/v1 dsh config set provider.api_key $DASH_API_KEY dsh config set provider.model gpt-4o-mini这里我用了环境变量的方式传密钥避免写死在配置文件里。dsh的provider层兼容OpenAI的接口协议所以绝大多数模型服务商都可以直接接入后面4.2会细讲。配置完成后跑第一条最简单的对话dsh run 帮我用一句话解释什么是harness会看到dsh输出agent的完整思考轨迹和最终回复。到这里你的第一个可用agent就已经跑起来了而它从始至终只依赖一个profile。后续server模式、桌面版、评测模式全都复用这一份配置。这也是我为什么说dsh选型的核心不是某个炫酷功能而是这套profile贯穿四种运行模式的一致性设计。2. 四种运行模式拆解dsh 如何把一个 agent 跑出四种姿势2.1 命令行模式交互式调试与无交互执行的混合体命令行模式是dsh最基础、也是我日常用得最多的一种运行模式。它有两种形态。第一种是交互式对话。直接在终端里跑dsh run进入多轮会话。调试阶段我会开两个终端一个跑dsh看agent每一步在想什么另一个改代码或改配置。dsh会实时打印工具调用的输入输出、模型返回的中间消息排查“agent为什么突然调用了一个不存在的工具”这类问题非常直观。第二种是无交互执行对应dsh exec这个入口也就是搜索词里常提到的harness。它不进入对话界面把一条任务直接丢给harness执行执行完退出返回结构化结果。比如# 无交互执行适合脚本里调用 dsh exec 把data/report.md里的所有链接整理成表格退出的状态码、标准输出、错误输出都可以被外部脚本捕获所以它能很方便地进定时任务、进pipeline。我经常把它和cron配合每天早上让agent自动汇总一批信息结果写进一个固定的文件。这个形态看起来朴素但它解决了一个关键问题agent不再需要人盯。这也是后面评测模式的执行底座。命令行模式还有一个典型价值方便做日志和审计。调试的时候打开--verbose输出的就是一条完整的agent轨迹。这份轨迹既是排查依据也能直接当作评测样本用于后续回归。2.2 Server模式把智能体封装成内部服务当agent不再只属于开发者而要开放给业务系统调用时就到了Server模式。dsh提供了dsh server命令启动后暴露一组HTTP接口调用方不用关心agent内部逻辑只要按接口协议传消息、拿结果。我通常建议团队把dsh Server放在内网作为“智能体网关”使用。与直接暴露模型API相比它有两个区别会话管理dsh server会维护多轮会话状态调用方只需传一个session_id就能延续之前的上下文。这点很实用因为很多业务方的调用习惯是“一轮一请求”如果让他们自己拼历史消息马上就乱。并发和超时控制同一时刻允许多少任务并发、单个任务最长跑多久、超时是重试还是返回失败这些都可以在server配置文件里设置。长任务我建议直接走异步模式提交任务返回task_id侧边轮询结果避免HTTP长连接把网关拖垮。Server模式下底层的agent运行还是复用harness。也就是说你在命令行模式下调好的prompt、插件、工具服务化之后行为不变。这种一致性是运维最看重的东西本地能复现线上才有救。2.3 桌面版模式让业务角色直接使用dsh桌面版是这个项目里容易被忽略的一块。很多工程师会想“桌面版不就是套了个壳的聊天框吗”实际用过之后我改变了看法。桌面版的价值不是替代命令行而是把agent带给那些不写代码、但真实需要它的人。比如我们团队里运营同学需要收集一批竞品公开资料。他不用打开终端直接在桌面版里选好web profile拖一个包含链接清单的文档进去让agent依次访问、提取要点、汇总成本地表格。整个过程用的是图形界面但对agent能力的调用方式和CLI完全一致因为桌面版读取的也是同一份profile、同一套插件。桌面版模式下建议额外关注两件事插件可见性桌面上要让用户能直观看到当前profile启用了哪些插件避免“agent说它不能读文件”这种体验尴尬。配置管理桌面版上的改动不要和CLI各改各的。把profile文件纳入git管理桌面端和CLI指向同一份配置目录否则同一个人在两套界面上跑出不同结果排查起来非常痛苦。2.4 评测模式带评分器的流水线运行评测模式是dsh四种模式里最特别的一种。你可以把它理解为“无交互执行自动判定”。普通harness执行完任务就结束了评测模式还会多一步把执行结果和期望行为交给评分器得出一个可量化的得分。具体使用上dsh提供dsh eval命令# 跑一个评测集 dsh eval --suite smoke --profile code # 跑完输出详细报告 dsh eval --suite all --report json评测模式为什么值得被当作一等公民因为我见过太多团队agent做得出来但说不清“到底做得好不好”。没有评测模式就只能靠人工一条条点改一次prompt重新点一遍时间全耗在重复劳动上。把评测做成运行模式之后它成了和run、server一样普通的操作团队执行回归的心理门槛大大降低。四种模式之间的关系我习惯用下面这个表格来向团队解释运行模式入口交互方式典型场景主要输出命令行dsh run / dsh exec交互/无交互调试、批处理、定时任务文本、结构化结果Serverdsh serverHTTP接口业务系统调用、多端接入JSON响应桌面版图形界面图形交互非工程师使用、可视化会话记录、文件评测模式dsh eval无交互自动评分回归、质量监控评测报告、分数这张表也是我做选型沟通时的第一张图先把四种模式画出来再确认每种模式的使用者、场景和输出最后才决定用不用dsh。多数团队对照这张表走一遍基本上就清楚自己卡在哪一层了。3. 评测闭环落地从一条用例到一套回归体系3.1 评测集设计先把“期望”说清楚评测闭环的第一步是评测集。很多团队第一次写评测用例时会把“期望输出”写成一句死答案“输出必须等于xxx”。这在大多数agent任务上都是错的因为agent的输出天然有波动。我推荐把期望写成行为特征而不是逐字答案。每条用例的结构大致是这样- id: web_001 desc: 从给定链接中提取产品定价信息 input: 请访问 https://example-product.com/pricing 并提取该产品的月付价格 tags: [web, smoke] priority: high expected: should_contain: [$, 月付] should_not_contain: [无法访问, 需要登录] match_schema: price: number currency: string这里should_contain和should_not_contain是规则校验match_schema是对结构化输出的约束。故意不写死价格数字是因为我们真正想检验的是“agent能访问页面、能识别价格字段、以合理格式输出”而不是检验它是否记得某个具体数字。评测集建议按三个层级组织冒烟用例smoke最基本的连通性比如“能够正常调用配置的模型”“插件能加载”。这类用例必须全部通过否则直接阻断发布。功能用例function覆盖核心业务流程比如文档解析、网页访问、代码执行。回归用例regression从历史真实问题中沉淀。线上用户报过一个bug先把这个场景写成用例下次改动就自动守护住。3.2 三种评分方式怎么搭配评分是评测闭环里最容易翻车的地方。dsh评测模式支持三种评分方式实际项目中我会把它们混用。第一种规则校验。用JSON Schema、关键字、正则等硬性条件判断。适合结构化输出比如“必须返回合法JSON”“必须包含日期字段”。它的优点是可解释、零成本缺点是无法评价内容质量。第二种LLM Judge。拿一个模型当裁判给agent的输出打分。适合开放性问题比如“总结是否准确”“回答是否有帮助”。但要给裁判一个评分卡rubric否则同一个输出换两次提问措辞可能得到不同分。我一般会在评分卡里写明评分的几个维度并把判定模型固定住不随上游模型版本漂移。第三种人工抽检。机器定不了的事定期抽人类来定。每周从全量结果中随机抽10到20条人工标一遍作为评测集质量的参照。这个环节不是可选项——LLM judge和规则校验只能保证“系统不退化”人工抽检才能保证“方向没跑偏”。这三种方式的取舍我建议按下面这张表来方式优点缺点适用场景规则校验稳定、可解释、快只能管结构输出是JSON、字段固定LLM Judge能评质量、自动不稳定、有幻觉总结、问答、开放任务人工抽检最准慢、贵抽样监控、标定评测集3.3 把评测嵌进开发循环而不只是跑一次评测闭环能落地靠的不是评测工具本身而是把它嵌进工程师的日常动作。我的做法有三步。第一步本地快速回归。每次改完prompt或工具先跑冒烟用例dsh eval --suite smoke --profile code通过再进下一步。这比手工试对话快得多因为同一组用例每次都会执行。第二步CI全量回归。在GitHub Actions或类似CI里加一个job对关键分支push自动跑全量评测。这一步可以挡住“本地跑得好、合并后发现别人的改动影响了我的agent”这类回归问题。一个简化的CI片段- name: Run agent eval regression run: dsh eval --suite all --profile staging --report json - name: Upload eval report uses: actions/upload-artifactv4 with: name: eval-report path: eval-report.json第三步趋势看板与基线对比。评测报告不是跑完就完我习惯把多份报告汇总成趋势通过率、各tag的得分均值。每次改动前先记录基线改动后再跑一轮dsh eval diff baseline.json latest.json直接看差异。如果发现某个用例从通过变失败就说明这次改动引入了回归需要立刻定位。3.4 我在评测闭环里踩过的三个坑这些坑基本每个团队都会踩一遍写出来帮你提前绕开。坑一评测集变成了背题集。有一段时间我们固定用同一批输入去测模型在评测集上的通过率很高但用户真实场景里表现依然不稳定。原因很简单agent把评测用例当成了训练样例。解法是在评测集里加入大量同义改写、参数变换并且每两周人工更新一批用例让模型没法“背题”。坑二LLM judge不稳定导致评分波动大。有一次同一个改动跑了三遍LLM judge给出的分数从85分到91分不等根本无法作为合入标准。后来把judge的模型版本从“浮动”改为“固定”并给出更细的评分维度波动才降下来。LLM judge要用但必须把它当成一个普通模型来管理固定版本、固定温度参数。坑三只盯通过率用例越加越简单。团队为了指标好看会不自觉地降低用例难度。通过率慢慢变成95%但真实问题没有减少。我现在要求评测报告里必须展示失败用例原文每次迭代先读失败的原因而不是只看分数。评测闭环的意义不是得到一个漂亮的通过率而是获得一份诚实的问题清单。4. 插件与接入细节四种模式能跑起来靠的是这些“小零件”4.1 插件管理dsh plugin 与插件市场前面说模式现在说让模式真正能干活的插件体系。dsh的插件通过dsh plugin子命令管理每个插件绑定到特定profile。我举个例子如果你想在web这个profile下启用 dshmarket 插件市场里的能力命令行是这样# 在 web profile 下添加 dshmarket 插件源 dsh plugin --profile web add dshmarket # 从市场安装具体插件 dsh plugin install browser --profile web dsh plugin install doc-parser --profile webdshmarket是dsh社区维护的插件市场里面收录了大量通用工具浏览器操作、代码执行、文档解析、HTTP请求等。我的经验是优先装三类插件浏览器插件让agent能访问网页、做搜索、抓取信息。做信息收集类任务几乎必备。文档解析插件让agent能读取PDF、Word、Excel等格式。这个痛点特别普遍后面4.3单独展开。代码执行插件给agent一个隔离的执行环境让它能跑Python等脚本。适合数据处理和自动化场景。插件和运行模式的关系需要特别强调插件在profile层配置所以同一个插件可以被CLI、Server、桌面版、评测模式共用。这意味着你为某个模式调试好的工具链路其他模式直接复用不需要重复配置。4.2 第三方API接入以硅基流动这类聚合服务为例dsh的provider层兼容OpenAI的接口协议所以接第三方模型服务很直接。国内用得比较多的是硅基流动这类聚合平台配置方式和官方API几乎一样只是base_url和key不同。一个典型的profile配置provider: api_base: https://api.siliconflow.cn/v1 api_key: ${SILICONFLOW_API_KEY} model: deepseek-ai/DeepSeek-V3两个细节值得注意。密钥一定要放到环境变量里不要直接写进profile文件尤其profile文件要提交到git的时候先用gitignore排除否则分分钟泄露。一个profile配一个服务商换模型就是切换profile不要在一个profile里反复改base_url。这其实是dsh里管理和成本核算的基础。顺带提一个Windows环境的高频问题。有朋友在Windows上用dsh跑命令时遇到商店版PowerShell的各种报错比如执行策略拦截、PATH识别不全、模块加载失败。我的建议是三个方向排查第一检查ExecutionPolicy必要时对当前用户放开为RemoteSigned第二确认执行命令的终端是传统PowerShell或Windows Terminal而不是商店版那个受限环境第三如果还不行优先考虑在WSL里跑dsh稳定性会好很多。这个坑本身不复杂但会浪费不少时间值得提前注意。4.3 文档读取让agent真正能处理Word、PDF搜索词里有一类高频问题dsh怎么实现读取Word、PDF等文档内容。这个问题几乎每个做知识库的团队都会遇到。首先要明确一个前提模型本身读不了文件二进制必须先把文档内容抽取成文本再交给模型。dsh的doc-parser插件就是干这件事的。实际使用中我会按文档类型区分处理PDF文档先判断是文本型PDF还是扫描件。文本型PDF直接抽取文字层速度快、准确率高扫描件需要OCR成本高一些但doc-parser插件也会自动降级处理。Word文档本质是docx的XML结构。解析时要注意保留段落和表格结构直接抽纯文本会把表格信息弄丢。好的解析器会把内容转成Markdown让agent既看到文字也看到结构。超长文档抽取出来的文本可能远超上下文窗口必须先分块再按块检索。不要一次性把整本书塞进上下文。一个常见错误是在prompt里写“请读取data/example.pdf”但没配文档解析插件agent只会回复“我无法访问本地文件”。正确做法是先确认doc-parser已经装到当前profile然后执行文档解析命令把文件加入可访问的上下文dsh docs add data/example.pdf --profile knowledge dsh run 总结 example.pdf 的核心观点 --profile knowledge把“读取文档”拆成“解析投喂生成”是这类任务能不能稳定完成的关键。不要在prompt层面期望模型自己学会解析文件工具链的事交给工具链。5. 选型建议什么时候选dsh什么时候别选5.1 适合选dsh的三种团队根据实际接触的项目我觉得下面三类团队最值得把dsh放进候选清单有明确模型接入、但缺稳定运行壳的团队。模型API已经选好了hack一个agent跑起来不难但要做到多轮稳定、可服务化、可回归需要一个harness。dsh能省掉自研agent runner的大部分工作。需要让非工程师角色用上agent的团队。开发、运营、产品都要碰agent又不想给每个人教命令行。dsh的桌面版模式正好和其他模式共享profile业务侧用桌面版工程师用CLI和Server大家在同一个配置体系下工作。在反复改prompt和插件、却说不清效果的团队。今天觉得模型A好明天觉得插件B好全凭感觉。这类团队最需要评测模式把“好”变成可对比的分数和报告。5.2 不适合dsh的情况也要直说dsh不是银弹有几类场景我会建议绕道。底层并发模型需要完全自控如果agent运行时的调度、内存、并发策略都要自己手搓一个现成harness反而碍事。要做低代码产品卖给外部客户自助搭建这种产品需要完整的租户隔离、权限体系和可视化编排dsh的定位不在这个层面。完全离线且插件生态不满足内网隔离环境下如果现有插件覆盖不了需求自研工具链的接入成本可能超过直接自研整个运行壳。不过这些场景也不是完全不能碰dsh。我见过有人拿dsh当内部原型工具先把agent流程验证清楚再照着这个流程写自研方案反而省了不少反复。5.3 以“运行模式”为锚做选型而不以“功能列表”做选型最后分享一个我自己比较坚持的选型方法论。面对任何一个“智能体基础设施”时我都会先画四行谁会用它开发者 / 业务系统 / 非工程角色 / CI机器人它以什么形式接入终端 / HTTP / GUI / 评测任务它产出什么交互答案 / JSON结果 / 会话记录 / 评测报告它怎么被度量人工观察 / 接口监控 / NPS / 通过率把这张表画完工具选型几乎自己就浮出水面了。dsh的优势正好是这四种模式天然对应了四类典型角色命令行给开发者Server给业务系统桌面版给非工程角色评测模式给CI和质量管理。它不是功能最多的框架但它是把“如何运行agent”这件事想得最清楚的一类框架。最后分享一个我在团队里落地的小技巧把四种模式的入口统一写进任务清单大家不用记命令。比如在Makefile里加几个aliasdev: ## 进入交互式调试 dsh run --profile code serve: ## 启动服务模式 dsh server --profile staging eval: ## 跑全量回归 dsh eval --suite all --profile staging ui: ## 启动桌面版 dsh-desktop团队统一入口之后评测闭环才真正变成日常动作。我个人这一年多最大的体会是选型最值钱的不是找到一个“功能最多”的工具而是找到一个能让agent的调试、服务化、可视化和评测都拥有同一套心智模型的底座。dsh恰好把这件事缝在它的四种运行模式里。如果你正在做智能体基础设施选型建议先别急着比功能直接把四种模式对应到自己团队的真实角色和场景里走一遍答案会清楚很多。