DeepSeek Harness创造模式：插件扩展先守边界

DeepSeek Harness 最值得关注的地方，并不是增加了一套新的文件工具或者重新设计了一种交互界面，而是在 Agent 运行环境中引入了一种更开放的能力扩展方式：创造模式。

在这一模式下，Agent 不仅可以完成既定任务，还能够检查当前运行的 Cordis 环境，理解已有能力结构，并在受控范围内尝试创建新的插件或专用 Agent，再将新增能力接入当前工作流。

从使用体验来看，这种机制容易让人产生“Agent 会自己进化”的感觉。但从工程实现角度来看，更准确的理解是：系统提供了一套可组合的运行环境，让 Agent 能够扩展自身工具链和任务能力。

能力扩展带来的问题同样明显。随着 Agent 可以调用更多工具、加载更多插件、连接更多外部系统，权限控制、依赖管理、日志记录和版本回退就不能再依靠简单约定完成，而需要建立更加明确的治理机制。

对于企业和开发者来说，真正需要关注的问题并不是“Agent 能不能创造更多东西”，而是“如何让新增能力保持可控”。

一、创造模式究竟改变了什么？

创造模式包含标准模式中的核心能力，同时增加了对 Cordis 插件运行环境的检查和实验能力。

简单来说，它主要支持两类扩展：

创建新的专用 Agent。

创建、调整当前运行环境中的插件能力。

例如，一个团队可能希望构建一个专门用于代码审计的 Agent：

只能读取代码文件；
禁止修改任何内容；
不能执行危险命令；
输出风险位置和分析结果。

又或者创建一个内部研究 Agent：

连接企业内部搜索系统；
固定调用指定模型；
拥有专属 Skills；
根据内部资料完成分析任务。

这些需求并不是简单修改 Prompt 就能实现。

一个安全审计 Agent 涉及文件访问范围、Shell执行权限、网络访问能力以及工具调用限制。

一个企业研究 Agent 则需要考虑：

数据来源是否可信；
模型调用方式是否统一；
内部资料权限如何划分；
Skills 是否经过审核；
输出结果如何追踪。

创造模式提供的是一个实现空间，而不是自动替用户完成所有安全决策。

Agent 可以帮助生成能力，但最终哪些能力可以开放、开放到什么范围、由谁负责维护，仍然需要人为定义。

二、创建插件之前，先定义能力边界

在 Agent 环境中增加新插件时，一个容易被忽视的问题是：很多需求描述只说明了“希望它做什么”，却没有说明“不允许它做什么”。

例如：

> 创建一个企业资料搜索插件。

这个描述看起来明确，但实际上仍然存在大量未知：

可以搜索哪些资料？
是否允许访问客户文件？
是否可以读取个人信息？
是否允许保存搜索结果？
使用什么身份执行？
出错后如何停止？

因此，在创建插件之前，可以先设计一张简单的能力卡。

例如：

# 插件能力卡

用途：
为研究 Agent 提供内部资料搜索能力

输入：
关键词、资料范围、最大返回数量

输出：
来源 ID、内容摘要、权限标签

允许数据：
已授权的内部资料

禁止数据：
客户受限资料、个人信息、密钥和私人空间

执行身份：
受限服务账号

副作用：
只读，不修改数据

日志：
记录任务、调用原因、结果数量、来源 ID

停止条件：
发现权限异常、来源缺失或返回异常数据量

Owner：
资料负责人、技术负责人

能力卡的意义并不在于文档格式，而是在创建能力时同步定义：

插件负责什么；
插件不负责什么；
它可以访问什么；
它必须拒绝什么。

如果一个插件只有“功能描述”，没有权限、身份和停止条件，那么它实际上只是给 Agent 增加了一扇没有边界的入口。

三、插件化不意味着可以随意安装

DeepSeek Harness 的插件生态展示了一种可扩展方向：通过社区插件增加更多能力。

例如：

插件	主要用途
dsh-at-file	在输入框中通过 `@` 调用文件
dsh-genui	渲染图表、表格、表单、Diff、Mermaid和交互面板
dsh-automation	增加自动化能力
DSH-better-sidebar	提供工作台式侧边栏、文件管理、终端、Git和任务状态
ModLens	为文本模型补充图片输入和视觉能力

这些插件解决的问题不同，对运行环境产生的影响也不同。

例如：

文件引用类插件主要涉及：

本地文件访问范围；
文件读取权限；
数据暴露风险。

自动化插件可能涉及：

后台任务执行；
外部系统调用；
自动化操作权限。

视觉相关插件可能涉及：

图片上传；
数据传输；
多模态模型调用。

工作台类插件通常会接触更多本地工具，因此权限范围更复杂。

因此，安装插件之前，至少需要检查以下问题：

代码来源是否可信？
维护者是谁？
需要哪些文件、网络和环境变量权限？
是否会执行安装脚本？
是否会下载额外依赖？
增加了哪些工具入口？
卸载后是否残留配置或后台任务？
升级后如何验证？

社区使用量并不能替代安全检查。

一个插件进入 Agent 环境后，影响的不只是界面功能，还可能改变：

工具调用范围；
数据流转路径；
模型访问方式；
自动执行能力。

四、让 Agent 创建插件时，需要限制四个核心边界

创造模式最大的风险之一，是任务目标描述过于宽泛。

例如：

> 帮我创建一个更强大的研究 Agent。

对于人类开发者来说，这句话可能意味着很多不同方向：

增加搜索能力；
增加数据分析；
接入数据库；
使用更强模型；
自动生成报告。

但对于 Agent 来说，如果没有明确约束，它需要自行判断：

应该连接什么工具；
应该使用什么模型；
应该拥有哪些权限；
应该保存哪些状态。

因此，一个更可靠的创建任务，需要明确四类边界。

边界	需要说明的内容
任务	目标用户、输入、输出以及明确不做什么
权限	文件、网络、外部系统和执行身份
运行	是否允许后台任务、子Agent、自动重试和持久化
验收	什么情况下算完成，异常如何停止

例如：

创建一个只读代码审计 Agent。

它只能读取当前工作区；
禁止修改文件；
禁止执行联网命令；
禁止安装依赖；
禁止访问外部系统。

输出必须包含：
文件路径、风险等级、问题位置以及人工确认项。

先在隔离项目中运行固定测试任务，
验证通过后再申请扩大使用范围。

相比“创建安全审计插件”，这种描述更接近工程需求。

Agent 的创造能力越强，对任务边界的要求就越高。

五、只追加事件日志的价值：让 Agent 行为变得可追踪

DeepSeek Harness 素材中提到，会话可以采用只追加事件日志（append-only event log）的方式记录运行过程。

这种设计思路与传统聊天记录不同。

普通对话通常只保留：

用户输入；
模型输出。

但在 Agent 工作流中，一次任务可能经历多个阶段：

系统提示加载；
用户需求解析；
上下文准备；
工具调用；
工具返回；
权限变化；
插件加载；
子 Agent 调度；
任务交付。

如果只保存最终回答，很难判断 Agent 为什么走到了当前结果。

例如，一个 Agent 执行代码分析任务失败：

表面现象可能是：

任务失败
工具超时
输出结果异常

但真正原因可能来自：

某个插件返回错误数据；

某次权限调整导致工具不可访问；

上下文压缩丢失关键要求；

模型选择发生变化；

外部工具返回空结果。

事件日志的意义，就是保留这些过程节点，让开发者能够回溯：

> 哪一步开始偏离预期？

一个典型事件链可以类似：

task_received

-> context_prepared

-> tool_called

-> tool_returned

-> permission_changed

-> plugin_loaded

-> subagent_started

-> subagent_finished

-> task_completed

这种结构有助于定位问题来源。

不过，需要注意的是，事件日志并不天然等于完整安全审计系统。

仍然需要明确：

哪些字段可以保存；
哪些信息需要脱敏；
谁可以访问日志；
日志保存多久；
如何关联任务、插件和执行身份。

如果将完整密钥、客户数据或者敏感代码直接写入日志，只是把风险从运行环境转移到了日志系统。

六、从事件记录回到问题复现

Agent 系统出现异常时，仅查看最终回答通常不足以定位问题。

更有效的方法，是沿着事件链逐步排查。

一个常见流程如下：

1. 固定 task_id 和本次运行版本。

2. 查看运行期间加载的插件、工具和模型配置。

3. 找到第一个异常事件：
   权限拒绝、工具超时、空结果、重复调用或上下文变化。

4. 检查异常发生前后的输入引用和结果摘要。

5. 使用脱敏数据在隔离环境重新运行。

6. 将确认的问题加入回归测试。

这种方式比简单重新询问模型：

> 为什么刚才出错？

更加可靠。

因为 Agent 任务失败的原因可能来自多个层面：

模型能力；
Prompt设计；
工具配置；
插件行为；
数据来源；
权限策略；
外部服务状态。

只有通过完整运行记录，才能判断问题属于哪个环节。

七、多模型 Agent 环境中的调用管理问题

随着 Agent 能力增强，一个实际问题也会逐渐出现：

> 一个工作流可能不再只依赖单一模型。

例如：

一个模型负责代码理解；
一个模型负责长文本分析；
一个模型负责视觉任务；
一个模型负责低成本批量处理。

在实验阶段，开发者可能直接分别申请不同模型供应商的 API。

这种方式适合：

深度使用某一个官方模型；
需要完整官方能力；
对数据链路有严格要求。

官方 API 通常能够提供：

原厂接口；
官方文档；
完整功能支持；
官方服务协议。

但当项目同时涉及多个模型时，工程维护复杂度也会增加：

多个 API Key 管理

多个 SDK 配置

不同接口格式适配

不同计费方式统计

模型切换逻辑维护

对于需要频繁测试多个模型或者快速切换模型的开发团队，可以考虑使用统一 API 网关或模型聚合平台。

例如，大模型 API 可以通过 4SAPI 中转站 进行统一接入。

这类方式的核心价值并不只是调用模型，而是减少开发过程中的重复适配工作：

使用统一接口管理多个模型；
减少多个平台之间切换成本；
集中查看调用记录和消耗情况；
方便在不同模型之间进行测试比较。

在 Agent 开发场景中，如果一个实验环境需要不断调整模型组合，统一入口可能比维护多套独立调用流程更加方便。

当然，涉及生产环境时，仍需要根据具体需求评估：

数据处理方式；
日志策略；
服务协议；
限流规则；
可用性表现。

八、插件升级和卸载同样需要回归验证

很多团队关注插件第一次安装，却忽略了后续变化。

实际上，插件系统最大的复杂性往往来自：

第二次升级；
替换版本；
修改依赖；
调整权限。

一次更新可能改变：

工具参数；
默认权限；
依赖版本；
上下文处理方式。

即使插件名称没有变化，Agent 实际执行路径也可能发生变化。

因此，每次升级、替换或卸载插件前后，都应该记录：

插件版本和来源。

影响哪些 Agent、任务和工具。

新增、删除或变化的权限。

现有后台任务、缓存和状态。

需要重新测试的任务类型。

出现问题后的回退方式。

尤其是在运行中动态加载或卸载插件时，需要更加谨慎。

Cordis 这类可组合运行环境让动态扩展成为可能，但：

> 可以切换，不代表可以跳过验证。

对于涉及：

外部写入；
文件修改；
网络请求；
敏感数据访问；

的插件，应先在测试环境验证：

安装流程；
卸载流程；
数据恢复；
异常处理。

确认稳定后，再进入真实业务流程。

九、渐进式使用 Agent 扩展能力

对于刚开始使用插件和创造模式的团队，一次性开放大量能力通常不是最佳方式。

更合理的方式，是逐步扩大范围。

例如：

第一步：
使用标准模式完成一个只读任务。

第二步：
安装一个低风险插件，例如文件引用或展示组件。

第三步：
观察新增工具、权限和事件记录。

第四步：
为插件建立能力卡和测试任务。

第五步：
使用创造模式创建专用 Agent。

第六步：
根据运行记录决定是否扩大权限。

这种方式虽然看起来更慢，但更容易理解：

新能力解决了什么问题；
增加了什么风险；
哪些权限是真正需要的。

如果第一天就同时加入：

自动化插件；
文件操作；
网络检索；
视觉能力；

那么任何异常都会变得难以定位。

变量越少，问题越容易复现。

十、插件需要完整生命周期管理

插件并不是安装完成之后就结束。

它实际上同时引入：

代码；
依赖；
工具；
权限；
状态。

因此，更合理的管理方式，是将插件视为一个长期维护组件。

一个简单生命周期可以包括：

提出需求

↓

定义能力边界

↓

隔离环境测试

↓

运行正常、异常和拒绝场景

↓

审核权限和日志

↓

小范围上线

↓

持续记录版本

↓

异常时停用或回退

其中最容易被忽略的是“拒绝测试”。

例如：

如果插件声明：

> 只能读取当前工作区。

那么测试不能只验证：

“它能读取文件”。

还需要验证：

“它是否会拒绝读取工作区之外的文件”。

如果插件声明：

> 不允许联网。

则需要验证：

“网络调用失败时是否留下记录”。

真正可靠的插件，不只是完成目标任务，也必须正确拒绝不应该完成的任务。

十一、事件日志设计：记录过程，而不是堆积数据

只追加事件日志的优势，在于它能够将一次 Agent 运行拆分成多个可排序、可关联的过程节点。

但日志系统设计的重点，并不是记录越多越好，而是确保发生问题时能够回答几个关键问题：

谁执行了任务？
使用了什么能力？
调用了哪些工具？
权限是否发生变化？
返回结果是否符合预期？
对应哪个版本环境？

一个通用的事件结构可以参考：

{
  "event_id": "evt_01",
  "task_id": "task_20260814_01",
  "run_id": "run_01",
  "event_type": "tool_returned",
  "plugin_id": "internal-search",
  "tool_name": "search_documents",
  "actor": "agent",
  "permission_scope": "approved-internal-docs-read",
  "outcome": "success",
  "timestamp": "2026-08-14T10:30:00+08:00"
}

需要说明的是，这类结构只是日志设计思路，并不代表某个具体 Agent 框架的固定 API 协议。

实际生产环境中，还可以增加：

工具执行时间；
重试次数；
插件版本；
错误分类；
结果摘要；
模型调用信息。

但日志字段越多，并不意味着系统越安全。

真正重要的是保持关联关系。

例如：

一次任务执行过程中：

任务创建

↓

选择模型

↓

加载插件

↓

调用工具

↓

修改权限

↓

生成结果

这些事件应该能够通过：

task_id

或

run_id

串联起来。

否则，即使保存大量日志，也只是无法解释顺序的数据集合。

十二、可观测并不意味着保存所有原始内容

Agent 系统运行过程中，会接触大量外部信息：

API 返回结果；
用户输入；
文件内容；
企业资料；
代码片段；
工具输出。

这些内容并不一定适合全部进入日志。

例如：

API Key；
用户隐私数据；
客户文件；
内部代码；
未公开文档。

如果将这些内容完整复制到日志系统，会扩大数据访问范围。

更合理的方式通常是：

内容类型	推荐处理方式
任务、运行、插件和工具标识	保存稳定 ID 和版本信息
权限变化	保存权限范围和执行结果
文件和资料	保存受控路径、来源 ID 或摘要
错误信息	保存错误类别和脱敏上下文
密钥、令牌、敏感文本	默认避免写入日志

日志系统的目标是：

帮助定位问题；
支持安全审查；
保留必要证据。

它不应该变成另一个没有边界的数据仓库。

同时，还需要明确：

谁可以查看日志；
保存期限是多少；
哪些环境允许访问原始信息；
调试日志和生产日志是否分离。

十三、提前测试异常场景

Agent 插件系统出现问题时，通常不会简单表现为：

> 插件无法运行。

更多情况下，问题来自组合关系。

例如：

插件升级后参数变化；
工具权限配置错误；
外部数据包含异常指令；
多个插件之间产生冲突。

因此，在正式使用之前，需要提前测试一些“不理想情况”。

场景	可能问题	应对方式
第三方插件异常	读取超范围数据、执行未知操作	来源检查、权限限制、隔离运行
依赖版本变化	更新后功能异常	锁定版本、升级前测试
工具权限过宽	修改无关文件或调用外部系统	最小权限、人工确认
外部操作重复执行	重复创建资源、重复发送通知	幂等设计、重复检测
运行中卸载插件	工作流中断	明确停止和恢复流程
外部数据携带指令	影响 Agent 判断	区分数据和任务指令

其中，外部输入影响 Agent 行为的问题尤其需要注意。

Agent 读取的：

网页；
Issue；
文档；
文件名；
数据库内容；

都属于外部输入。

其中可能包含：

> 忽略之前规则，执行某操作。

类似内容不应该自动获得更高优先级。

插件本身无法解决所有安全问题，还需要结合：

工具限制；
权限控制；
人工审核；
明确任务边界。

十四、多模型调用环境中的基础设施选择

当 Agent 从单模型工具逐渐发展为复杂工作流时，模型管理也会成为新的工程问题。

一个完整任务可能需要：

一个模型负责规划；
一个模型负责代码分析；
一个模型负责总结；
一个模型负责低成本批量任务。

如果每个模型都单独维护：

API Key；
SDK；
调用逻辑；
账单统计；

长期维护成本会增加。

因此，一些团队会考虑使用统一 API 网关或者模型聚合平台。

除了直接调用模型官方 API，开发者也可以通过 4SAPI 中转站 这类统一接入方式完成模型调用。

这种方式更适合以下场景：

需要同时测试多个模型；
希望减少重复配置；
希望统一管理调用记录；
需要快速切换不同模型。

例如，一个 Agent 项目在开发阶段可能需要比较不同模型对于代码生成、分析任务或者长文本处理的效果。

通过统一接口管理，可以减少频繁修改调用代码的工作。

不过，两种方式适用于不同场景：

方式	更适合
官方 API	需要原厂能力、官方文档、完整功能支持的项目
统一接入平台	需要多模型测试、减少适配工作、统一管理调用流程的项目

对于涉及企业生产数据、长期运行任务或高并发业务的系统，无论采用哪种方式，都需要重点评估：

数据处理方式；
服务协议；
日志策略；
限流机制；
可用性表现；
故障处理流程。

十五、上线范围越小，指标越容易判断

插件和 Agent 能力上线后，不建议只关注：

> 使用体验是否不错。

更重要的是建立可以衡量的运行指标。

例如：

任务完成率：
是否达到预设目标。

人工接管率：
多少任务需要人工继续处理。

工具错误率：
插件、工具和依赖是否稳定。

重复调用次数：
是否存在异常循环。

权限异常请求：
是否频繁申请额外能力。

插件加载失败率：
版本和运行环境是否匹配。

异常副作用：
是否产生预期外文件、网络请求或操作。

这些指标不一定需要复杂监控系统。

在早期阶段，一张任务记录表也可以满足需求。

关键是：

每一次运行都应该能够关联：

使用版本；
使用插件；
执行过程；
最终结果。

如果没有边界控制，“所有人自由试用”反而很难判断 Agent 是否真正带来了价值。

十六、出现问题时，先控制影响范围

当 Agent 出现：

异常权限请求；
敏感数据风险；
重复外部操作；
无法解释的工具调用；

第一步不是继续运行任务，而是控制影响范围。

一个基础处理流程可以包括：

1. 停止当前任务，限制相关插件权限。

2. 保存 task_id、run_id、插件版本和脱敏事件摘要。

3. 判断是否产生文件修改、外部请求或数据暴露。

4. 在隔离环境重新复现。

5. 修复或回退后补充测试。

6. 人工确认后恢复使用。

这里保存运行信息，并不代表复制所有原始数据。

应该优先保护：

任务链路；
版本信息；
权限变化；
错误节点。

如果涉及真实生产环境或者客户数据，则需要按照企业已有安全流程处理。

十七、检查清单：让 Agent 扩展保持可维护

在正式开放创造模式和插件能力之前，可以进行以下检查：

[ ] 插件是否明确用途、输入输出和数据范围。

[ ] 是否记录插件来源、版本和依赖。

[ ] 是否限制文件、网络和外部系统权限。

[ ] 是否避免直接提供生产密钥。

[ ] 是否能够查询工具调用和权限变化。

[ ] 是否保存必要事件记录。

[ ] 是否测试正常和拒绝场景。

[ ] 是否准备升级和回退方案。

[ ] 是否在隔离环境验证高风险能力。

[ ] 是否设置人工审核节点。

对于模型调用部分，也需要建立类似原则：

[ ] 明确哪些任务使用官方模型接口。

[ ] 明确哪些任务适合统一网关管理。

[ ] 检查调用记录和费用统计方式。

[ ] 验证模型切换是否符合预期。

[ ] 在生产环境前进行实际测试。

如果团队需要同时管理多个大模型 API，可以将统一接入方式作为基础设施方案之一，例如通过4SAPI等多模型 API 中转平台减少重复配置。

但最终选择仍应结合：

项目规模；
数据敏感程度；
模型需求；
运维能力；
成本结构。

十八、结论：Agent 能力扩展需要配套治理体系

DeepSeek Harness 创造模式和插件机制展示了一种新的 Agent 使用方向：

Agent 不再只是执行固定任务的聊天工具，而可以逐渐成为具备扩展能力的运行环境。

但能力增加之后，管理方式也必须同步升级。

插件不是简单安装一个功能，它同时改变：

工具体系；
权限范围；
数据流向；
运行状态；
后续维护成本。

更可靠的实践方式是：

从低风险插件开始；

建立能力边界；

保留事件记录；

设计回归测试；

逐步扩大权限。

对于模型调用基础设施来说，官方 API 和统一接入平台并不是互相替代的关系。

需要原厂能力、完整支持和直接控制链路的项目，可以优先考虑官方接口。

需要同时测试多个模型、减少重复适配、统一管理调用流程的团队，也可以评估4SAPI中转站等聚合接入方式。

无论采用哪种方案，正式投入生产环境前，都应该根据实际模型、调用规模、数据安全要求和稳定性需求进行验证。