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

DeepSeek Harness（简称 DSH）是 DeepSeek 于 2026 年 8 月以 MIT 协议开源的 Agent Harness。单人使用门槛不高，但推到部门时，多人各自部署会带来互不相通的会话日志、插件与凭证，缺少统一的身份、网络、数据与运维支撑。在 AgentCore 上，DSH 与 Qoder、Codex、Pi、QwenPaw 并列可选，托管要补齐的正是这层缺口。本文将按三部分展开：为何需要托管、如何接入业务、接入后如何管理，供评估团队在决策前参考。

DSH 一个人能用，沉淀不了部门资产

Cloud Native

▍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 包一层界面，而是把它接进企业已有的身份、网络、数据与运维体系。这层接进去之后，同一个 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 企业从托管到底获得了什么

算力和人力第一个月就能看到效果：机器利用率更高，新人上手更快。风险与资产要等具体的事发生才显现：用过这个 Agent 的同事离职或转岗，任务要由别人接手；审计或合规部门第一次来要材料；团队第一次换模型或换 Harness 版本。也正是在这些时刻，单机方案的成本会集中出现。企业采购时常说先小范围试试，该覆盖的其实是这三件事，而不是机器数量和上手时间。机器和上手时间随时能补，接入方式选错了要重做。

▍1.4 同一套托管机制，验收标准不同

这套接入方式值不值，不同的人判断标准不一样。

试点最容易失败的方式，是只让研发觉得好用。平台拿不到数据，主管看不到账，下一期预算很难批下来。反过来，一次试点如果同时给出当天可用、出事可查、花钱有账，推广时的阻力会小很多。

怎么把 DSH 接进业务

Cloud Native

AgentCore 是阿里云的智能体构建和治理平台。构建负责把 Agent 组装出来：选 Harness、绑模型、挂 Skill 与 MCP、配沙箱与规格。治理负责它上线之后怎么运行、怎么合规：实例与 Session 调度、企业身份与凭证代签、VPC 与网络出口、会话与 Trace、评测与版本管理、按 Agent 与部门核算的用量。

托管只是治理中的一部分：平台替你维护运行环境，但它的范围比运行时更大。DSH 决定 Agent 怎么思考、能调哪些工具，AgentCore 决定它用什么搭起来、跑在哪里、以什么身份跑、出了问题从哪里看。

上述能力对每种 Harness 一致：选 QwenPaw、Qoder、Codex、Pi 还是 DSH，接入方式、身份体系、观测口径与用量核算都是同一套，换 Harness 不必重做这些对接。

接下来两件事定下来，其余配置才有落点：选形态，Agent 跑在哪里、由谁维护；定入口，员工从哪里用上它。

▍2.1 DSH 接入 AgentCore 的三种形态

三条路径可以并存。同一个部门里，编码团队可能用自定义镜像保留自己的插件集，业务团队直接用配置化托管，运维团队先把存量机器纳管起来看数据。先跑通一条，再扩到第二条，比一次规划三条路径更现实。

配置化托管在控制台上就是一次创建，配置按四块组织：模型与提示词，绑定平台兼容的模型连接并选定模型，填系统提示词，或选模板复用角色文件；资产，添加 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 身份通知。启动超时、运行超时、会话失联与终态归档都由平台处理，不靠人盯。配置前建议先用一个真实任务走通一遍。

接进来之后怎么管

Cloud Native

接入完成之后，管理才真正开始：从身份、凭证与网络，到观测与评测，再到落地的先后顺序，最后是需要提前知道的边界。

▍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验证。数据进入平台后按三层组织：

一条 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 一份可复制的落地顺序

时间上可以这样切：第一周跑通一个场景，第二到第四周把工具、账号与入口接上，第五周开始固定任务集、记录第一版基线。前三步决定能不能跑，后四步决定跑起来之后能不能管、能不能换。常见的卡点在第 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

文章来自于微信公众号 “阿里云云原生”，作者 “阿里云云原生”