AgentCore 支持 DeepSeek Harness 托管,加速企业生产化验证
原创 世如 2026-11-12 20:12 浙江

加速企业生产化验证。
DeepSeek Harness(简称 DSH)是 DeepSeek 于 2026 年 8 月以 MIT 协议开源的 Agent Harness。单人使用门槛不高,但推到部门时,多人各自部署会带来互不相通的会话日志、插件与凭证,缺少统一的身份、网络、数据与运维支撑。在 AgentCore 上,DSH 与 Qoder、Codex、Pi、QwenPaw 并列可选,托管要补齐的正是这层缺口。本文将按三部分展开:为何需要托管、如何接入业务、接入后如何管理,供评估团队在决策前参考。
一、DSH 一个人能用,沉淀不了部门资产
1.1 DSH 一个人能用,沉淀不了部门资产
DSH 作为一款优秀的开源 Agent Harness,它把模型适配器、工具、会话、沙箱、界面乃至 Agent Loop 都拆成插件,注册在 Cordis 微内核上;会话日志是唯一权威事件源,轨迹可回放、可分叉;Team 以根会话为边界,子 Agent 之间可以互相发消息,共享一块带依赖关系的任务板;子 Agent 可以进程内启动,可以经 ACP(Agent Client Protocol)在独立子进程中驱动,也有直接对接 Claude Code 与 Codex 的后端;后两类各自拥有运行时、会话与工具。
这些设计让一个人很快就能跑出效果:装一份 DSH,写几个 Skill,把常用工具接上,就能跑通一个真实任务。推到部门时,人数增加并不改变这一点,十个人装十份,就是十套互不相通的会话、插件与凭证,没人能接着别人的会话往下做。DSH 的 Team 解决的是同一个操作者在根会话里带多个子 Agent,不解决多人共用一份环境。所以问题不在 Agent 够不够聪明,而在它周围缺了下面几样东西:
部门会上被问到的事 | DSH 单机形态 |
|---|---|
谁在用它 | 只有 DeepSeek 个人账号,没有组织、角色、部门 |
跑在哪里 | 官方写明未经安全审计,建议在一次性环境中运行;插件包校验不构成代码沙箱 |
数据去了哪里 | 会话日志默认随官方 API 请求上传,含提示词快照与工具参数,可在配置里关闭 |
记忆由谁维护 | DSH 不带长期记忆,要靠第三方 MCP 插件接入,示例默认关闭 |
经验留给谁 | 会话、插件、Skill 都在 ~/.dsh 个人 Profile,换人即失 |
托管做的不是给 DSH 包一层界面,而是把它接进企业已有的身份、网络、数据与运维体系。这层接进去之后,同一个 Harness 才能从个人工具变成部门可以依赖的基础设施。
1.2 云上托管带来哪些工作方式变化
下面四个场景是按平台现有能力搭出来的示例,用来说明工作方式的变化,不是客户案例。
场景一:研发改一个老服务
一个 2019 年的订单服务要补幂等。工程师让 Agent 读仓库、定位入口、改三处调用、补测试。单机形态下,他要自己把仓库拉到本地,把团队的提交规范贴进提示词,跑测试时还要处理本机依赖。
托管之后,Agent 在 VPC 内访问代码库与制品库,MCP 接内部代码检索与构建平台,Skill 里带团队的分支、提交与评审规范,访问制品库的凭证由保管库代签。任务跑到夜里也不受笔记本合盖影响;一次没做对,失败会话留在平台上,改完配置可以重跑。
团队规范从一份文档变成可执行的 Skill,环境从每个人各自搭变成一份配置,代码不出 VPC。上线后值得盯的三个数:改动一次过测试的比例、完成任务的平均轮次、回归集通过率。
场景二:月结分析从群里发起
主管在飞书群里提需求:把上月的渠道费用按区域拆开,和预算对比,出一版 20 分钟的汇报材料。以往这件事由分析师手工取数、对账、套模板。
托管之后,Agent 通过 MCP 连接数仓取数,按 OSS 里挂载的模板出稿,把口径写进 Skill,关键结论由记忆保留;财务在群里补两项数据,Agent 在原任务上更新。第二天接着做时,口径与上次的结论从记忆里取回,上一轮的取数与修改记录在会话与 Trace 里能翻到;会话按 TTL 回收,跟着跨天推进的部分交给 Team 的 Task 继续。
入口留在员工本来就在用的软件里,口径从个人经验变成团队资产,过程有记录可查。值得看的数:从提出到初稿的时间、返工次数、因口径不一致产生的返工占比。
场景三:值班排障
告警进来后,值班同学在群里让 Agent 查一下。Agent 先看服务拓扑与关联资源,再查日志与最近的变更记录,给出三个根因假设和验证步骤。涉及重启、扩容这类动作时,Agent 只给建议,执行由值班同学确认。
托管之后,排障过程留在 Trace 里:查了哪些服务、看了哪段日志、依据什么排除了一条假设。第二天复盘用同一条轨迹,不必靠口头交接;常见的排障套路可以写成 Skill,下一个人直接复用。
值得看的数:平均恢复时间、转人工处理的比例、诊断结论与事后确认根因一致的比例。
场景四:一套 Agent 服务多个客户
交付团队给不同客户做同一类助手:政策问答、工单分流、报表解读。单机形态下,每个客户复制一份配置,凭证散在各人机器上。
托管之后,每个客户一个 Workspace,凭证与 OSS 目录分开,FAQ 与交付文档做成 MCP,对外只暴露 Endpoint 与 API Key。差异放在配置与资产里,不用复制代码;客户问起数据边界,能按 Workspace 与凭证回答。
值得看的数:新客户上线时间、单客户需要改的配置项数量、审计材料一次备齐的比例。
四个场景的共同点:都不是让 Agent 更聪明,而是让它的输入可达、输出可审、过程可复用。输入是代码、数据、日志、知识,输出是改动、报告、处置、交付物,过程是会话与轨迹。
1.3 企业从托管到底获得了什么
方面 | 单机形态下的实际开销 | 托管提供的机制 | 看哪些数 |
|---|---|---|---|
算力 | 每人一台机器常开,峰值靠加机器 | 一个实例承载多个 Session,Session TTL 回收空闲会话,自动扩缩容按负载调整 | 峰值并发会话数、单会话 CPU 与内存、扩容触发次数 |
人力 | 每人自己装环境、自己排障、自己记配置 | Agent 模板、Skill 与 MCP 的版本、平台侧观测 | 新人跑通第一个任务的时间、重复配置的次数 |
风险 | 日志随请求上传,操作没有统一留痕 | 平台兼容模型连接与网关出口、三层身份、会话与 Trace | 能否回答谁在什么时候让 Agent 做了什么 |
资产 | 会话、插件、Skill 都在个人 Profile | Skill 与 MCP 的版本管理、知识库与记忆托管、在 Workspace 内共享、评测集 | 同事离职或转岗后,同一任务能否接着做 |
算力和人力第一个月就能看到效果:机器利用率更高,新人上手更快。风险与资产要等具体的事发生才显现:用过这个 Agent 的同事离职或转岗,任务要由别人接手;审计或合规部门第一次来要材料;团队第一次换模型或换 Harness 版本。也正是在这些时刻,单机方案的成本会集中出现。企业采购时常说先小范围试试,该覆盖的其实是这三件事,而不是机器数量和上手时间。机器和上手时间随时能补,接入方式选错了要重做。
1.4 同一套托管机制,验收标准不同
这套接入方式值不值,不同的人判断标准不一样。
角色 | 关心什么 | 托管给什么 | 试点期能看到什么 |
|---|---|---|---|
研发 | 配置少、能改、跑得快 | 配置化托管开箱用,自定义镜像保留改动,MCP 与 Skill 接内部系统 | 当天建出 Agent 并完成一轮真实任务 |
平台与运维 | 可控、可查、可追溯 | 规格与配额、VPC、身份、观测、会话留存 | 一次失败请求能定位到具体 Step |
业务主管与财务 | 花在哪、值不值 | 按 Agent 与部门归因的用量、Token 配额 | 月度用量与完成的任务量能对上 |
试点最容易失败的方式,是只让研发觉得好用。平台拿不到数据,主管看不到账,下一期预算很难批下来。反过来,一次试点如果同时给出当天可用、出事可查、花钱有账,推广时的阻力会小很多。
二、怎么把 DSH 接进业务
AgentCore 是阿里云的智能体构建和治理平台。构建负责把 Agent 组装出来:选 Harness、绑模型、挂 Skill 与 MCP、配沙箱与规格。治理负责它上线之后怎么运行、怎么合规:实例与 Session 调度、企业身份与凭证代签、VPC 与网络出口、会话与 Trace、评测与版本管理、按 Agent 与部门核算的用量。
托管只是治理中的一部分:平台替你维护运行环境,但它的范围比运行时更大。DSH 决定 Agent 怎么思考、能调哪些工具,AgentCore 决定它用什么搭起来、跑在哪里、以什么身份跑、出了问题从哪里看。
上述能力对每种 Harness 一致:选 QwenPaw、Qoder、Codex、Pi 还是 DSH,接入方式、身份体系、观测口径与用量核算都是同一套,换 Harness 不必重做这些对接。
接下来两件事定下来,其余配置才有落点:选形态,Agent 跑在哪里、由谁维护;定入口,员工从哪里用上它。
2.1 DSH 接入 AgentCore 的三种形态
形态 | 做什么 | 适合的团队 |
|---|---|---|
配置化托管 | 控制台填写配置,运行、扩缩容、观测与配额由平台负责 | 多数团队,先用它跑通 |
自定义镜像或代码包 | 把 DSH 运行时连同自己的 Profile、插件、改动打成镜像或代码包,平台注入模型连接、MCP、Skill 与凭证 | 已经改过 DSH 配置、有存量插件的团队 |
本地或远端纳管 | DSH 继续跑在员工机器或客户环境,由 LoongSuite Pilot 采集并纳入平台观测 | 暂时不搬运行时,先解决观测与成本 |
三条路径可以并存。同一个部门里,编码团队可能用自定义镜像保留自己的插件集,业务团队直接用配置化托管,运维团队先把存量机器纳管起来看数据。先跑通一条,再扩到第二条,比一次规划三条路径更现实。
配置化托管在控制台上就是一次创建,配置按四块组织:模型与提示词,绑定平台兼容的模型连接并选定模型,填系统提示词,或选模板复用角色文件;资产,添加 Skill、Subagent、MCP、知识库与凭证,并按需启用记忆插件;会话管理,选实例规格、单个实例的最大 Session 数、Session TTL 与自动扩缩容;网络配置与存储,按需开公网、接 VPC,需要读 OSS 数据时按挂载点接入。内置 Shell 与文件工具无需添加。
另外两条路径不走这个页面:自定义镜像或代码包上传后由平台注入模型连接、MCP、Skill 与凭证,纳管则在目标机器上装 Pilot 完成采集。
实例、Session 与上下文的关系值得单独说清:实例是运行 Agent 的计算环境,Session 是一组连续交互,上下文包含此前对话与工具执行结果。一个 Agent 可以跑多个实例,一个实例可以承载多个 Session。Session 从入口产生:直接调用 Endpoint、IM 渠道,以及协作实例中的聊天与 Task。这里的协作实例指加入 Team 后以 Leader 或 Worker 身份工作的 Agent 实例,它与人在任务房间里的每一轮交互各算一个 Session。
已有 Session 继续使用原实例,扩容时新 Session 优先分配给已就绪且未达上限的实例,多个可选时优先选择已有 Session 更多的实例。Session TTL 决定空闲会话的回收时机,也影响缩容节奏。
修改配置后,模型、提示词、Skill、Subagent、MCP 与凭证支持热更新;实例规格、镜像与挂载点需要重启,建议在任务结束后改。
还有一条与选型有关的前提要提前确认:三条路径共用平台提供的模型连接,而 DSH 的上下文缓存优化依赖 DeepSeek 官方 API 契约,换到其他模型提供方会失效,模型连接需要与所选 Harness 兼容。走官方 API 换缓存效果时,会话日志上传要显式关闭或按字段剥离,这一步要单独配置,托管不会默认关掉。
2.2 入口:Endpoint、IM 与 Team
入口不只是 Web。托管 Harness 支持直接访问 Endpoint、钉钉、飞书、企业微信,以及协作实例中的聊天与 Task。员工在原工作软件里提问,Agent 在平台上运行,账号、权限与审计留在平台侧。
外部应用按 AG-UI 协议接入,回复以事件流逐条返回,续聊沿用同一个 threadId。接入只需要 Endpoint 与 API Key,应用侧不必为每个 Agent 单独改造。
需要跨会话、跨天推进的工作,交给 TeamHarness:Agent 加入 Team 后被赋予 Leader 或 Worker,Leader 创建任务并向 Worker 分派子任务,执行转入任务房间;任务创建后用户不必保持原对话连接,状态变化由平台以 Bot 身份通知。启动超时、运行超时、会话失联与终态归档都由平台处理,不靠人盯。配置前建议先用一个真实任务走通一遍。
三、接进来之后怎么管
接入完成之后,管理才真正开始:从身份、凭证与网络,到观测与评测,再到落地的先后顺序,最后是需要提前知道的边界。
3.1 身份、凭证、网络与审计
采购评审会问的几件事,托管之后由平台侧承担,不需要每个部门自己搭。
资源按 Workspace 划分,跨部门不混在一起。在这个边界内,身份分三层:业务身份记录代表谁(uid、租户、云账号),执行身份记录在哪个会话与运行,资源身份记录可以调用哪些工具、Skill、沙箱与子 Agent。入站走 IAM 或 OAuth,出站凭据由保管库代签,应用侧不持有长期密钥。1.2 里的四个场景落到三类权限:取数、查日志对应查询,改代码对应修改,对外交付对应外部访问,这些能力最后都要落到上面三层身份上,三层对不上,权限就说不清。
网络默认收紧:公网访问要显式打开;访问 VPC 内的服务,除平台侧放通外,目标服务自己也要放通;需要读 OSS 里的数据时按挂载点接入。
用量与限流在平台侧计数:Token 配额与 Agent 维度的并发限流都在平台上设置和执行,不依赖应用自己记账。
会话日志与配置变更都留在平台侧,审计要材料时按 Agent 与会话取出。自定义镜像按版本保留,跨版本回滚与按插件粒度的版本管理仍在补齐。
3.2 从观测到评测,再到调优
DSH 的会话日志天然适合做观测:系统提示词、工具 schema、模型请求、流式输出、工具调用结果、权限切换与取消原因都追加在同一条日志里,轨迹被拆成 Turn、Step 与工具调用三层。短板在采集端,原生 OTLP Logs 插件默认关闭,单机使用要自己把采集插件注入 $DSH_HOME/cordis.patch.yml。
接入之后,这一步由 Pilot 完成:托管形态下平台侧代做,纳管形态下装在运行 DSH 的机器上。Pilot 发现 DSH 实例后注入采集插件,不改 DSH 源码,接入状态可用 loongsuite-pilot status 与 info 验证。数据进入平台后按三层组织:
层次 | 对应什么 | 用来回答什么 |
|---|---|---|
Session | 一段多轮会话 | 这次问题属于哪个任务、谁发起的 |
Trace | 其中一轮请求 | 这一轮慢在哪、错在哪 |
Span | 模型调用、工具调用等具体操作 | 参数、返回、耗时、重试次数 |
一条 Trace 是否可用,按三条验收:步骤齐全,模型调用与每次工具调用都有 Span 且输入输出可读;嵌套正确,子 Agent 与异步任务不丢父 Span;染色正确,业务字段在传播中不丢且挂在对应 Span 上。企业已有基于 OTel Context 的自建链路系统时,需要给两套链路独立的上下文键,否则子 Agent 的 Span 会挂错父级。
评估不只靠模型打分。平台支持 Code、LLM 与 Agent-as-a-Judge 三类评估器;AgentCore 团队公开的评测实践以 terminal-bench 2.1 的 10 个任务做载体,另建三个正交的确定性评估器:任务完成度、红线规则判定与执行过程可靠性,全部用规则化脚本实现,不引入 LLM 打分的方差与宽松偏差。这样得到的结论度量的是 Harness 与模型的组合能力,换一个 Harness 也能用同一套口径比较。
四个场景里提到的那些数,之所以能算,是因为每一步都有落点:失败会话能找到 Trace,能定位到 Step,能加入回归集,改完配置或换模型之后能用同一批任务重跑。观测、评测、调优三件事就是靠这条链路接起来的:先看 Trace 找到问题出在哪一步,再用同一个评估器把改动前后的分数算出来,分数涨了才保留这次改动。任何一环缺了,效果就只能靠印象。
3.3 一份可复制的落地顺序
步骤 | 做什么 | 完成标志 |
|---|---|---|
1 选形态 | 先用配置化托管跑通,再决定是否打自定义镜像 | 控制台能创建 DSH Agent 并完成一轮真实任务 |
2 接模型 | 绑定平台兼容模型连接,明确用量与配额口径 | 请求经平台出口,用量可按 Agent 或部门归因 |
3 接账号 | 把员工、Agent、服务账号映射到企业身份 | 每个动作能回答代表谁、在哪个会话 |
4 装工具 | 把内部 API 发布为 MCP,Skill 按版本发布;知识库与记忆启用平台托管的能力 | 会话内工具表与资产版本一致,知识库与记忆都能检索到最新内容 |
5 接入口 | 按需接入钉钉、飞书、企业微信或 AG-UI,跨天交付的配 Team 与 Task | 用户在原工作软件里发起,状态能通知到人 |
6 接观测 | 打开上报,进平台做评估 | 失败会话能定位到 Step 并加入回归集 |
7 立基线 | 固定一批真实任务、模型与配置 | 换版本或换模型时有可比的分数 |
时间上可以这样切:第一周跑通一个场景,第二到第四周把工具、账号与入口接上,第五周开始固定任务集、记录第一版基线。前三步决定能不能跑,后四步决定跑起来之后能不能管、能不能换。常见的卡点在第 4 步和第 6 步:工具资产没有版本,观测装了但没人看分数。
3.4 需要知道的边界
托管解决运行与治理,不改变 DSH 的成熟度。DSH 目前所有 tag 为 alpha 或 rc,官方明确建议在一次性环境中运行;托管提供会话级隔离与平台侧留存,但不承诺每个版本都可直接进生产主链路。
知识库、记忆、TeamHarness 与观测评估的接入按 Harness 的能力矩阵逐项开放,未列明的项以控制台实际可配为准。评估与回归能力已经可用;平台侧推送的 Harness 版本更新按灰度批次放量。
如果只是单人使用、追求 DSH 缓存带来的极致单价,或者没有合规与协作诉求,单机部署加一键脚本仍然更省成本。托管的价值要到多人共用、多任务并行、有审计要求时才显现。
判断托管是否值得,有一个简单口径:一个新人接手同一个任务,能不能接着上一个人的会话、工具、权限与评测基线继续做。能做到,Harness 才算真正进入组织。
如您对 AgentCore 感兴趣,欢迎加入“AgentCore 用户支持群”获取更多信息。钉钉群号:185130001370。
AgentCore 官网:https://www.aliyun.com/product/agentcore
AgentCore 快速入门:https://help.aliyun.com/zh/agentcore/agentcore-quick-start-1
本文转载自微信公众号「阿里巴巴中间件」,查看原文。版权归原作者所有,如有侵权请联系删除。