AgentCore 支持 DeepSeek Harness 托管,加速企业生产化验证

· 2026-11-12 20:12 · 1 阅读

原创 世如 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。

阅读原文

跳转微信打开

本文转载自微信公众号「阿里巴巴中间件」,查看原文。版权归原作者所有,如有侵权请联系删除。