DeepSeek Harness实测：权限拦截≠结果正确

在观看 Agent 产品演示时，很多人容易被最后一句“任务完成”吸引。

但对于真正参与 Agent 开发和评估的人来说，更值得关注的问题通常不是结果页面显示了什么，而是整个任务过程中到底发生了什么：

Agent 发起了多少次模型请求？
工具调用是否真正执行？
权限拒绝发生在哪一层？
文件或外部状态是否真的发生变化？
最终回答是否与实际执行结果一致？

用户提供的 DeepSeek Harness 素材记录了一次非常简单的本地实验：

让 Agent 创建 result.txt 文件，写入指定内容，然后通过 Shell 命令确认文件是否存在。

这个实验没有选择一个复杂项目，也没有试图证明某个模型“有多聪明”，而是通过一个确定性测试任务，将模型能力与 Harness 运行能力拆开观察。

这种测试思路对于 Agent 开发具有参考价值。

因为在实际应用中，一个 Agent 任务是否可靠，并不只取决于模型生成能力，还取决于：

工具是否正确连接；
权限是否合理控制；
执行状态是否可追踪；
验收机制是否独立存在。

本文不会通过一次简单实验推导整个产品能力，而是借助这条最小执行链路，分析 Harness 如何将模型意图转换为真实动作，以及开发者如何建立更加可靠的 Agent 测试流程。

一、理解模型意图与系统执行之间的区别

直接调用模型 API 时，模型可能返回类似这样的工具调用请求：

{
  "tool": "write",
  "path": "result.txt",
  "content": "harness-test-ok"
}

从模型角度看，它已经完成了任务规划。

但实际上，文件系统并不会因为收到一段 JSON 就自动发生变化。

模型输出的是：

希望执行什么动作。

而真正改变环境的是：

运行时系统是否允许并执行这个动作。

完整流程通常需要多个环节配合：

模型请求：
选择 write 工具，并生成调用参数。

↓

Harness：
读取当前工作区状态、权限规则和工具配置。

↓

工具执行：
尝试创建文件或写入内容，返回成功或错误。

↓

Harness：
将工具执行结果重新加入上下文。

↓

模型请求：
根据工具返回决定下一步动作。

↓

工具执行：
在受限 Shell 环境中执行验证命令。

↓

模型：
结合执行结果生成最终说明。

因此，评估一个 Agent 系统时，不能只看：

最终回复；
工具列表；
演示界面。

至少需要同时观察：

模型请求；
工具调用；
权限判断；
工具返回；
实际环境变化。

缺少其中任何一环，出现问题时都只能依靠猜测。

二、为什么最小实验比复杂项目更适合验证 Agent

很多 Agent 演示喜欢直接展示：

自动开发完整项目；
修改大型代码仓库；
完成复杂业务流程。

但对于测试系统本身来说，复杂任务往往会引入大量变量。

一次任务失败，可能来自：

模型理解错误；
Prompt设计问题；
工具参数异常；
权限限制；
项目环境问题；
依赖缺失；
外部服务异常。

如果所有因素同时存在，很难判断真正原因。

因此，最小实验的价值在于减少变量。

例如：

工作区：
一个全新的测试目录。

输入：
固定文件名和固定文本。

动作：
一次文件写入，一次 Shell 检查。

验收：
文件存在，并且内容完全一致。

权限：
分别测试可写环境和只读环境。

用户素材中采用本地确定性测试端点，目的并不是比较模型速度或者生成质量，而是观察：

Harness 如何处理一次真实工具调用。

即使没有完全相同的测试环境，也可以采用类似方式：

一个空目录；
一个明确任务；
一个固定结果；
一个可验证状态。

关键是不要将：

“模型回答正确”

和：

“系统执行正确”

混为一谈。

三、设计一个可复现的 Agent 测试任务

一个好的实验任务应该尽可能减少歧义。

例如：

只允许在当前测试工作区执行任务。

1. 创建 result.txt。

2. 写入：
harness-test-ok

3. 使用受限 Shell 检查文件是否存在，并读取内容。

4. 最终回复必须说明：
文件路径、实际内容、验证命令结果。

如果任一步失败，
必须报告失败，不得标记任务完成。

这个任务包含几个关键设计：

1. 限定执行范围

明确：

只能在当前测试工作区操作。

避免 Agent 自行寻找其他路径。

2. 固定输出结果

例如：

harness-test-ok

方便后续自动验证。

3. 加入验证步骤

不是：

创建文件后直接回复完成。

而是：

创建文件，再通过 Shell 检查。

这样可以观察：

文件是否真实存在；
Shell 是否读取真实状态；
模型是否基于工具结果判断。

4. 明确失败状态

这一点非常重要。

很多 Agent 系统的问题，并不是工具没有报错，而是：

工具失败后，模型仍然生成：

已完成。

因此：

“不能把失败说成成功”

应该成为任务验收的一部分。

不过，即使写入 Prompt，也不能完全依赖模型遵守。

实验结束后，仍需要：

测试脚本；
外部检查；
人工确认。

来判断最终状态。

四、成功执行路径应该观察哪些信息

在可写工作区中，一个正常执行流程大致如下：

task_received

↓

workspace_loaded

↓

write_requested

↓

permission_allowed

↓

file_written

↓

bash_requested

↓

bash_returned

↓

task_completed

开发者观察时，可以重点检查：

write 请求的路径是否位于测试目录？

写入内容是否与参数完全一致？

Shell 是否真的读取文件？

模型是否在收到工具结果后才宣布完成？

最终回复是否包含实际验证信息？

如果 Harness 提供：

事件轨迹；
工具调用记录；
调试日志；

建议保存完整执行记录。

因为相比截图：

“任务完成”

一次完整运行轨迹更有价值。

未来修改：

插件；
模型；
权限策略；
工具配置；

都可以通过相同任务重新运行，对比行为变化。

五、为什么一次成功实验不能证明 Agent 很强

一个文件写入测试能够证明的范围其实非常有限。

它可以帮助确认：

工具是否能够调用；
权限是否有效；
执行状态是否可观察；
验收流程是否存在。

但它不能证明：

模型适合复杂软件开发。

Agent 可以稳定理解大型代码仓库。

所有插件都能安全运行。

Shell 沙箱覆盖所有外部风险。

任务失败后一定能够自动恢复。

系统已经具备完整企业级审计能力。

这些问题需要单独设计评估方法。

例如：

模型能力：

需要通过固定任务集、多次运行观察。

复杂代码能力：

需要结合：

上下文理解；
测试结果；
人工修正次数。

插件安全：

需要检查：

权限范围；
代码来源；
依赖风险。

生产能力：

需要评估：

身份管理；
日志体系；
数据处理；
恢复机制。

不要让一次简单 Demo，承担它无法证明的结论。

六、只读环境下，权限拦截发生在哪里

将同一个任务放入只读工作区，是验证 Agent 权限边界的重要方式。

在可写环境中：

模型请求 write

↓

权限允许

↓

文件创建成功

而在只读环境中：

模型请求 write

↓

执行层检查权限

↓

拒绝文件写入

↓

返回错误结果

这两个过程最大的区别在于：

权限控制发生在执行层，而不是模型层。

模型可能知道：

“我要创建 result.txt。”

也可能按照任务要求生成正确的工具调用。

但最终是否真的修改文件，并不由模型决定。

真正控制动作能否发生的是：

文件系统权限；
沙箱规则；
工具执行策略。

例如，实验中可能出现类似：

FS_SANDBOX_DENIED

这样的权限错误。

但需要注意：

不同版本、不同实现环境中的错误名称可能不同，不能将某个具体字符串理解为所有 Harness 环境固定协议。

重要的是理解背后的机制：

模型提出动作，执行层决定动作是否落地。

这也是 Agent 系统与普通聊天模型的重要区别。

七、权限控制和结果验收是两个独立问题

很多人在测试 Agent 时容易混淆两个概念：

权限：

决定：

Agent 能不能做某件事。

例如：

能不能写文件；
能不能执行 Shell；
能不能访问网络。

验收：

决定：

Agent 声称完成后，结果是否真的符合要求。

例如：

文件是否存在；
内容是否正确；
测试是否通过；
外部状态是否变化。

这两个过程需要分开设计。

可以简单理解为两条流水线：

权限线：

路径
↓
身份
↓
工具权限
↓
执行限制
↓
允许或拒绝


验收线：

实际结果
↓
状态检查
↓
规则验证
↓
是否交付

例如：

权限允许 Agent 修改代码，并不代表：

修改一定正确；
测试一定通过；
代码符合规范。

同样：

权限拒绝一次 Shell 调用，也不代表：

Agent 可以直接回复任务完成。

因此，在可靠 Agent 工作流中，需要建立独立验收机制。

八、不同任务需要不同验收标准

不同类型的 Agent 任务，验收方式并不相同。

例如：

任务类型	最低验收标准
创建文件	文件存在、路径正确、内容匹配
修改代码	diff范围正确、测试执行成功、无新增失败
生成报告	来源存在、数据口径一致、标记待确认内容
调用外部系统	返回有效ID、状态可查询、避免重复操作

对于文件写入实验：

不能只判断：

Agent 回复“文件已经创建”。

应该检查：

文件是否存在？

路径是否正确？

内容是否匹配？

Shell 是否真实读取？

最终状态是否符合要求？

对于代码开发任务：

不能只看：

Agent 输出了一份代码。

还需要关注：

是否真正修改目标文件；
修改范围是否合理；
测试是否通过；
是否引入新的错误。

九、把一次实验转化为回归测试

一个最小实验真正有价值的地方，不在于第一次跑成功，而在于后续能否重复验证。

完成一次实验后，可以保存：

测试任务文本。

工作区初始化方式。

模型版本。

Harness版本。

插件和配置版本。

允许权限配置。

拒绝权限配置。

预期事件顺序。

关键工具参数。

最终文件状态。

异常处理方式。

之后每次修改：

模型；
插件；
权限；
运行环境；

都重新执行。

至少保留两组测试：

第一组：正常路径

可写工作区

↓

write执行成功

↓

bash验证成功

第二组：限制路径

只读工作区

↓

write被拒绝

↓

任务进入失败或人工处理状态

如果两次结果发生变化，需要进一步分析：

变化来自：

模型行为；
工具变化；
权限变化；
Harness版本变化。

而不是简单认为：

模型变差了。

十、不要从一个成功Demo推导整个Agent能力

Agent演示最大的误区，是容易把局部能力扩大理解。

例如：

一次文件写入实验成功，只能说明：

当前环境可以完成受限文件操作。

不能说明：

Agent可以稳定开发大型软件。

Agent能够处理复杂企业流程。

所有工具组合都可靠。

所有插件都可以动态加载。

所有错误都能够自动恢复。

系统已经适合生产部署。

这些结论需要不同类型测试。

例如：

模型能力测试

需要：

多任务；
多轮运行；
不同难度。

工具可靠性测试

需要：

成功调用；
参数错误；
超时；
返回异常。

权限安全测试

需要：

越权访问；
错误路径；
恶意输入。

生产环境测试

需要：

并发；
状态管理；
数据隔离；
日志审计。

一个好的Agent评估体系，应该避免：

用一个漂亮Demo证明所有能力。

十一、实际异常排查顺序

当 Agent 任务出现异常时，不建议第一时间更换模型。

很多问题实际上来自：

工具没有加载；
工作区错误；
权限限制；
验收缺失。

更合理的排查顺序：

1. 检查工作区。

确认目标路径是否正确。

↓

2. 检查当前运行环境。

确认工具、Skill和插件是否加载。

↓

3. 检查权限。

确认拒绝是否发生在执行层。

↓

4. 检查工具参数和返回结果。

确认模型看到的信息是否完整。

↓

5. 检查模型行为。

是否忽略失败结果？

是否错误判断任务完成？

↓

6. 检查最终状态。

文件、测试或外部系统是否真正符合要求。

这种顺序可以减少误判。

例如：

表面看起来：

模型没有完成任务。

但实际原因可能是：

write工具没有开放；
Shell权限不足；
文件路径错误。

只有基础链路正常后，才有必要比较不同模型效果。

十二、将测试结果记录成结构化对照表

单纯记录：

成功 / 失败

对于Agent测试来说价值有限。

更好的方式，是拆分：

工具请求；
执行结果；
实际状态；
最终判断。

例如：

场景	工具请求	执行结果	文件状态	正确终态
可写工作区	write、bash	成功	文件存在且内容正确	completed
只读工作区	write被拒绝	bash验证失败	文件不存在	failed
错误路径	write目标越界	沙箱拒绝	文件不存在	failed
工具超时	write无返回	状态未知	待确认	waiting
重复执行	再次写入	需检查规则	不应产生异常副本	completed或skipped

这种记录方式可以明确区分：

工具有没有执行。

和：

任务是否应该完成。

在测试过程中，还可以加入故意错误场景：

例如：

让模型在工具失败后输出：

已完成。

然后观察系统是否能够通过外部检查发现问题。

这种反向测试，往往比正常成功路径更能暴露系统缺陷。

十三、误报完成不能只靠提示词解决

一个常见问题：

工具执行失败。

模型收到错误信息。

但最终仍回复：

任务已经完成。

很多团队第一反应是修改系统提示词：

如果失败不要说完成。

但这种方式并不可靠。

更合理的方式，是增加外部状态判定。

例如：

文件任务

检查：

文件路径；
文件内容；
文件哈希。

代码任务

检查：

diff；
测试退出码；
新增错误。

外部系统任务

检查：

返回ID；
服务端状态；
幂等记录。

模型可以负责：

解释结果；
生成说明。

但不应该单独决定：

任务是否完成。

最终状态应该由：

工具结果；
测试脚本；
业务规则；

共同决定。

十四、测试不能只覆盖工具调用，还需要覆盖运行状态变化

文件写入和 Shell 验证只是 Agent 测试中的第一类场景。

在实际使用过程中，Agent 运行环境还会面对更多状态变化：

页面关闭后恢复会话；
任务中途取消；
权限动态调整；
插件加载和卸载；
工具执行超时；
重复提交任务。

这些情况往往更能体现系统可靠性。

因此，在基础实验通过后，可以逐步扩展测试矩阵。

例如：

关闭页面后恢复会话，
确认任务状态是否一致。

↓

在工具执行前取消任务，
确认不会留下未完成文件。

↓

运行过程中撤销写权限，
确认后续调用是否被阻断。

↓

让 Shell 返回非零退出码，
确认模型不会忽略失败。

↓

加载新增插件，
确认旧任务工具集合没有异常变化。

↓

重复提交相同任务，
确认不会产生重复外部副作用。

这些测试关注的不是：

Agent 能不能完成一次任务。

而是：

Agent 在异常、中断和变化环境中是否仍然保持边界。

真正可靠的 Agent 系统，不只是成功路径表现良好，更重要的是：

失败是否可解释；
状态是否可恢复；
权限是否持续有效；
外部影响是否可控制。

十五、不要把界面轨迹等同于完整审计能力

很多 Agent 工具会提供类似：

执行轨迹；
工具调用记录；
思考过程展示；
操作历史。

这些内容对于开发调试非常有价值。

但需要注意：

界面中的运行轨迹，并不一定等于企业级审计日志。

一个调试页面可能只展示：

最近几步操作；
工具调用摘要；
最终结果。

但企业环境通常需要关注更多信息：

谁发起任务；
使用哪个模型；
调用了哪个插件；
权限是否变化；
修改了哪些资源；
是否产生外部影响。

正式部署前，需要确认：

事件是否可以查询，而不是只能查看当前页面。

任务、运行、插件、模型、工具是否拥有稳定ID。

敏感数据是否经过脱敏处理。

日志访问权限是否明确。

删除、发送、部署等外部操作是否单独记录。

如果这些能力还没有建立，那么更适合将 Harness 作为：

开发环境；
测试环境；
实验平台。

而不是直接认为已经具备完整生产审计能力。

十六、一次运行应该保存哪些关键字段

为了让未来的问题可以复现，测试记录需要保留足够的信息。

下面是一种通用设计示例：

{
  "task_id": "write-file-readonly-001",
  "run_id": "run-001",
  "workspace_scope": "test-readonly",
  "runtime_version": "recorded-locally",
  "model_provider": "test-endpoint",
  "tool_name": "write",
  "permission_decision": "denied",
  "tool_outcome": "failed",
  "verification_outcome": "file_absent",
  "final_state": "failed"
}

这里记录的是：

任务编号；
运行编号；
环境范围；
模型来源；
工具行为；
权限结果；
验证状态。

而不是保存：

完整密钥；
全部文件内容；
敏感业务数据。

对于调试来说，最重要的是回答：

哪一次运行，在什么环境下，调用了什么能力，为什么失败。

而不是复制所有原始数据。

如果需要更强的审计能力，可以继续增加：

插件版本；
执行身份；
工具参数摘要；
时间信息。

但仍需要遵循数据最小化原则。

十七、多模型 Agent 工作流中的 API 接入问题

随着 Agent 从简单任务执行器发展为复杂工作流，模型调用方式也会逐渐变得复杂。

一个实际任务可能同时涉及：

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

如果每个模型都单独接入，开发者可能需要维护：

多个API Key。

多个SDK。

不同接口格式。

不同调用参数。

不同账单统计方式。

对于只使用单一模型、重视官方能力完整性的项目，直接调用模型官方 API 通常更合适。

官方接口能够提供：

原厂模型能力；
官方文档支持；
完整功能路径。

但对于需要频繁测试不同模型组合的 Agent 项目，统一接入方式也具有实际价值。

例如：

除了直接申请模型官方 API，开发者也可以通过 4SAPI中转站 等统一接入平台调用相关大模型。

这种方式主要解决的是工程管理问题：

减少多个接口重复配置；
降低模型切换时的适配成本；
统一管理调用入口；
方便测试不同模型效果。

在 Agent 开发阶段，如果需要比较 GPT、Claude、Gemini、DeepSeek 等不同模型在某项任务中的表现，统一接口可以减少修改代码和维护多套调用逻辑的工作量。

当然，不同接入方式适用于不同需求：

接入方式	更适合场景
官方 API	需要原生能力、官方支持、直接控制链路的项目
统一接入平台	需要多模型测试、减少重复适配、统一管理调用流程的项目

对于涉及企业数据、长期生产运行或者高并发任务的 Agent 系统，仍需要进一步评估：

数据处理方式；
服务协议；
日志策略；
限流规则；
稳定性表现；
故障处理流程。

十八、实验结果如何转化为工程实践

一次简单的文件写入实验，真正有价值的地方并不是证明：

Agent 可以创建文件。

而是建立一套验证方法：

从：

模型提出动作

到：

工具执行

再到：

权限判断

最后：

状态验收

整个链路都能够被观察。

对于开发团队来说，可以按照以下方式逐步推进：

第一阶段：验证基础执行

测试：

文件创建；
工具调用；
权限拒绝。

第二阶段：验证复杂状态

增加：

插件；
多工具；
中断恢复；
错误处理。

第三阶段：验证生产能力

关注：

日志；
身份；
数据隔离；
回滚机制。

在模型调用基础设施方面，也可以根据项目阶段选择不同方式：

开发实验阶段：

可能更关注快速切换模型和降低适配成本。

生产部署阶段：

可能更关注：

数据链路；
合规要求；
稳定性；
运维能力。

因此，模型官方 API 与统一接入平台并不是互相替代的关系。

十九、结论：Agent 可靠性来自可验证的执行链路

DeepSeek Harness 这类 Agent 运行环境的价值，并不只是让模型能够调用更多工具。

更重要的是，它让开发者能够看到：

模型提出了什么；
系统执行了什么；
权限阻止了什么；
最终状态是什么。

一次简单的 result.txt 文件实验已经说明：

模型负责提出动作。

Harness 负责连接动作和环境。

权限系统负责限制边界。

验收机制负责判断结果。

任何一层缺失，都可能导致：

错误执行；
错误完成；
难以复现的问题。

如果准备开发自己的 Agent 工作流，建议从最小实验开始：

建立一个可写环境；

建立一个只读环境；

观察工具调用；

记录事件变化；

设计失败测试。

不要从：

页面显示任务完成。

开始判断 Agent 是否可靠。

应该从：

实际发生了什么，失败后是否能够解释。

开始评估系统。

在模型接入层面，直接调用官方 API 和通过统一接入方式完成调用，都有对应适用场景。

需要完整原厂能力和直接控制链路的项目，可以优先评估官方接口。

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

正式投入生产环境前，仍需要结合实际模型需求、调用规模、数据安全要求和运行稳定性进行测试。