DeepSeek‑Harness 实测：Agent 自己写代码自己评测，得分只有 23 分

当下不少观点认为，AI Agent 已经可以接手软件开发工作。为了实际验证它的真实能力，我做了一组自指实验：让 Agent 实现一套代码规范检测工具，再拿这个工具，去扫描 Agent 自身产出的代码。实验得出的结果，令人深思。

一、DeepSeek‑Harness：「一切皆插件」的工程向 Agent 运行时

DeepSeek‑Harness（简称 dsh）不是一个新模型，而是一套 Agent 运行时与宿主框架------简单说，就是让大模型真正「动手干活」的那层骨架：读写文件、跑命令、调工具、拆任务、派子代理，全由它组织和管控。模型负责思考推理，Harness 负责对接真实环境、工具调用闭环、任务调度、权限管控、会话追踪。

它最有辨识度的设计是 Everything is a Plugin（一切皆插件），整个架构建立在 Cordis 微内核之上。

1.1 底层：Cordis 微内核

Cordis 是 dsh 的插件总线，本身不具备任何 Agent 能力，只负责插件的注册、生命周期管理、依赖注入和事件流转。所有功能全部通过插件挂载，不存在「特权核心」。模型适配器是插件、工具注册表是插件、Agent 主循环本身也是插件、WebUI 也是插件。

这种设计的好处是：开发者不需要改框架源码，通过配置就能替换、扩展任意模块。想换模型？换模型插件就行。想换 Shell 执行后端？换工具插件就行。

1.2 插件体系：主要插件类型

插件类型	代表插件	作用
模型插件	deepseek‑model（支持 V4 Pro/Flash）、openai‑model	提供 LLM 调用能力，支持多模型适配
工具插件	file‑system、shell、api‑gateway	让 Agent 操作文件、运行命令、调用接口
会话插件	session	管理会话状态、上下文、日志持久化
技能插件	skill‑registry	加载 Skill/技能包，扩展 Agent 能力
沙箱插件	sandbox	进程隔离、权限管控、文件系统策略
循环插件	agent‑loop	控制 Agent 的思考‑行动循环逻辑
UI 插件	web‑ui	提供 Web 界面交互

安全层面，dsh 通过沙箱插件做进程隔离与文件系统策略管控------Agent 只能操作指定工作目录下的文件，不能越权访问系统其他路径；Shell 命令执行也有权限白名单限制。这对企业内部使用很关键，避免 Agent 误操作破坏环境。

1.3 四种运行模式

dsh 内置四种 Agent 预设，预设本质是一套预定义插件组合，决定会话可用工具集，新建会话选定后不可中途切换：

• Standard（标准模式）：全能力默认预设，包含文件编辑、Shell、检索、Skills、计划、子 Agent、工作流，绝大多数开发任务使用该预设。
• Code（PTC，代码模式）：继承 Standard 全部能力；区别是允许模型编写 TypeScript，将多轮工具调用编排为一段脚本一次性执行，减少模型往返轮次，适合批量复杂工程任务。
• Minimal（极简模式）：仅保留持久 Shell 与文件编辑器，工具集合最小，多用于模型基准评测、可控测试场景。
• Creator（创造模式）：基于 Standard，增加运行时自省、内存插件调试、自定义预设编写能力，面向插件与框架二次开发。

⚠️ 区分两个容易混淆概念

1、Agent 预设 Preset：Standard / Code / Minimal / Creator，决定 Agent 会话拥有哪些工具能力，在新建会话时选择。

2、启动 Profile：web / headless，决定程序启动形态；web启动 Web 图形界面；headless为无头批处理，无界面，任务执行完成进程退出。 本次实验组合：Code (PTC) 预设 + headless Profile

1.4 可追溯会话日志

dsh 有一个很重要的工程特性：append‑only session log（只追加的会话日志）。系统提示词、模型推理过程、工具调用与结果、子 Agent 调度、每一次上下文注入，全部记录在案，每一次运行都可追溯、可回放。这对调试 Agent 行为、排查问题非常关键。

很多人会把 dsh 理解成「带工具调用的大模型」，其实不对。普通的多轮工具调用只是「模型 + 循环」，状态和上下文容易丢失；dsh 是完整的运行时：具备持久化会话、沙箱隔离、插件化扩展、可追溯日志，相当于给 Agent 装了一套「操作系统」。

用官方的话说：Model + Harness = Agent。

简单对比一下普通对话大模型和 dsh 的差异：

• 普通 Chat‑AI：只输出文本，本身没有本地运行环境，不能直接读写磁盘、执行命令，调试工作全部交给人。
• DeepSeek‑Harness：有完整的运行时环境，加载 YAML 任务配置后，自动完成新建文件、编写源码、执行 pytest、安装依赖、读取报错、修改代码，循环迭代直到任务完成或触发终止。

⚠️ 前置说明：DeepSeek‑Harness 目前为 v0.1 开发者预览版，MIT 协议开源，基于 TypeScript 编写，运行依赖 Node 环境与 DeepSeek API Key，会产生一定的 API 调用费用。接口仍在快速迭代，不建议直接用于生产环境。

二、实验设计：让 Agent 开发巡检工具，再扫描自己的代码

凭借上面这套完整插件化架构、沙箱隔离、工具调用闭环，DeepSeek‑Harness 理论上可以驱动 Agent 独立完成不少工程任务。

然而架构纸面能力，不等于真实的输出质量。Agent 常常会出现「评判别人代码头头是道，轮到自己写却频频违规」的现象。 为了直观探测真实能力边界，我设计了一个有点「自指」意味的实验：让 dsh 的 code 模式独立开发一套 Python 工程健康巡检工具，然后用这个工具扫描 Agent 自己产出的源代码，看看它给自己打多少分。

这个实验巧妙之处在于：巡检工具的检测规则完全由 Agent 自己实现，相当于它既是规则制定者，又是被检测对象。倘若它生成的代码无法通过自己制定的规则，便可以直观体现 Agent 当前的能力边界。

2.1 实验约束配置

本次实验设置了严格的任务约束，全部通过 YAML 配置传递给 Agent：

• 工作模式为Code (PTC) 预设，最大迭代 20 轮，防止无限死循环；
• 定制任务终止规则：连续 3 次修改无进展，输出失败反思、更换实现路线，4 次失败强制终止；
• 强制使用 pytest 单元测试，要求 PEP8 规范、类型提示、Docstring；
• 优先使用 Python 标准库 ast 实现静态分析，减少重型第三方依赖；
• Agent 必须主动执行 pip install 安装依赖，不假设运行环境就绪。

实验执行命令：

harness run --config harness-auto-py-health-check.yaml --no-interactive

⚠️ 该命令仅克隆本地 dsh 源码仓库内部可用，npm 安装发布包npx @deepseek-ai/dsh没有 harness 二进制，不支持该参数，属于源码开发调试接口。--no‑interactive代表全自动模式，不需要人工中途输入提示词。

三、实验全过程：AI 全自动开发 py_health_check

全程没有手动编写业务代码，全部交由 Agent 自动执行，完整流程如下：

第一阶段：项目初始化与核心逻辑开发

1. 初始化项目目录：Agent 自动创建标准化项目结构，区分源码目录、测试目录，生成依赖声明文件。
2. 编写静态分析核心逻辑：基于 Python 内置 ast 语法树模块，实现 5 类工程质量检测规则：缺失单元测试、魔法数字/硬编码、废弃 API、裸 except、缺失 Docstring。
3. 实现 CLI 与 Markdown 报告：处理目录不存在、权限不足等边界情况，输出带风险分级、百分制加权健康评分的报告。

第二阶段：测试闭环与依赖安装

4. 编写 pytest 测试夹具：生成缺陷样例、正常样例，验证检测逻辑，规避误报。

5. 自动安装依赖 + 迭代修复 Bug：生成 requirements.txt 自动执行安装，运行 pytest 读取真实输出，测试失败定位代码反复修改。

第三阶段：文档交付

6. 编写 README 文档：写明安装、运行示例，强制加入免责声明。

高光名场面：工具扫描自己的源码

全部开发完成后，调用刚刚生成的 py_health_check，扫描 Agent 产出的整套源代码。得到自巡检报告，健康分数仅有 23/100。

一个很有意思的现象：Agent 可以严格按照规则审查别人的代码；但轮到自己产出代码，却会忽略自己亲手定义的编码约束。

报告关键统计信息：扫描文件：10 个，总代码行数：575 行，发现问题：23 个。高风险：2 个，中风险：5 个，低风险：16 个。

报告暴露出一个值得关注的现实：该工具检测规则明确要求公共函数写 Docstring，业务模块要有配套单元测试。但 Agent 产出的核心代码并未遵守：reporter.py、__main__.py、__init__.py 缺少单元测试；analyzer.py 大量 AST 回调函数、公共方法缺失文档字符串。

而测试夹具 bad_code.py 预埋缺陷：硬编码密钥、裸 except、废弃 API、魔法数字，全部被精准命中。说明检测逻辑本身有效，只是 Agent 在生成自身代码时，会忽略自己制定的编码约束。

Agent 读取这份 Markdown 报告，回头尝试修复自身代码。但受最大 20 轮迭代上限约束，并不能一次性把 23 个问题全部解决，不少缺陷依旧遗留，这正是当前 Agent 真实能力的写照。

注：23 分是本次 Demo 任务结果；调整任务提示词、迭代轮数，分数会发生变化，不代表框架能力上限。

四、实验暴露的现实局限：AI Agent 并不是万能

不少市场宣传给人造成一种错觉：Agent 可以完美完成全部开发任务。本次实验同样出现不少真实问题。

• AST 静态分析天然存在误报、漏报 ：魔法数字很难做到 100% 精准区分，代码自定义的 deprecated 装饰器无法识别；工业级 SAST 工具同样无法完全规避误报和漏报问题。
• 迭代轮次上限触发任务终止：20 轮迭代耗尽，框架主动触发终止规则。终止后 Agent 输出失败反思，给出人工接手修改建议。这不是实验失败，属于框架保护机制。
• 路径兼容小 Bug：Windows 环境生成报告，会混杂绝对路径与相对路径；生产版本需要做路径归一化。
• 评分规则偏严苛：本次 Demo 扣分权重很高，少量问题就会压低分数，适合学习演示，不建议直接用于生产项目打分。
• 生成与评审行为不一致：这是本次实验最值得关注的发现------Agent 能用规则严格检查别人的代码，自己生成时却频繁违反同一套规则。本质是生成阶段与评审阶段模型行为不一致，也是当前 Agent 系统亟待解决的问题。

总结：Agent 可以完成脚手架、基础检测逻辑、测试用例；但复杂静态分析距离商用工具还有很大差距。

五、工具能力边界与重要免责

✅ py_health_check 可以做什么

• 快速扫描中小型 Python 项目，做工程质量初筛；
• 快速发现缺少单元测试、裸 except、明显硬编码等问题；
• 输出结构化 Markdown 报告与健康评分，作为人工 Code Review 的辅助参考。

❌ py_health_check 不能做什么

• 它不是专业安全漏洞扫描器，不能替代商用 SAST 工具；
• 报告存在误报、漏报，绝对不能替代人工代码评审；
• 不适合大型超大规模项目，原生 AST 静态分析性能有限。

📢 重要声明：py_health_check 属于 AI Agent 实验室 Demo，仅供学习研究，禁止直接在生产环境使用。DeepSeek‑Harness 目前为开发者预览版，不建议作为生产环境依赖。

六、如何复现本次实验

⚠️ 注意：文中实验执行命令 harness run --config 为源码仓库内部调试接口，仅克隆源码本地可用；通过npm安装的正式发布包不支持该命令。

DeepSeek‑Harness 已经开源，开发者可以自行部署复现本次实验。 前置条件：Node.js 环境，配置环境变量 DEEPSEEK_API_KEY。

方式1：源码仓库（本文实验实际执行环境）

拉取完整源码仓库，项目目录内执行：

# 仅源码仓库内部可用，npm全局安装不支持
harness run --config harness-auto-py-health-check.yaml --no-interactive

方式2：普通用户 NPM 标准安装方式

1、Web UI交互式调试（适合观察会话全过程）

npx @deepseek-ai/dsh web

访问 http://127.0.0.1:3080，新建会话选择 Code(PTC) 预设，粘贴任务指令交互运行。

2、headless 无头批处理执行

npx @deepseek-ai/dsh --profile headless --patch ./harness-auto-py-health-check.yaml "完成Python工程巡检工具开发实验"

参数说明：

• --profile headless：无头批处理模式，不启动Web界面
• --patch：属于配置叠加，YAML 顶层 agent 配置（max_iterations 等）不会生效，仅 system_prompt、user_prompt、tools 配置会被合并；想要完整加载全部 agent 参数，只能源码环境使用harness run --config
• 引号内为顶层任务指令

项目扫描示例命令（实验产出巡检工具运行）

# 进入项目目录
cd py-health-check
# 使用 python -m 运行包
python -m py_health_check --dir . --ignore venv,.git --output self_check_report.md

提示：实际运行路径随你的本地工作目录变化，仅作参考。

核心任务设计思路

1. 给 Agent 完整工程约束：目录规范、异常处理、测试规范；
2. 强制闭环：写完代码必须真实执行单元测试，读取测试报错迭代；
3. 设置迭代终止策略，防止无限循环；
4. 强制输出文档与风险免责，不允许跳过约束。

📎 完整的 system_prompt、任务需求全部在下方折叠YAML配置中。
📄 点击展开完整 harness-auto-py-health-check.yaml 实验配置

# 粘贴你的全部yaml内容
# 说明：
# 1.源码仓库：harness run --config 可完整加载全部配置
# 2.npm dsh包：作为--patch补丁，agent顶层字段不会生效，仅prompt/tools生效  
agent: 
  mode: code
  max_iterations: 20
  system_prompt: |
    ## 任务终止规则（必须严格遵守）
    你拥有自主终止任务的权限，出现下面任意一种情况，必须主动结束任务，禁止继续循环尝试修复：

    1. 迭代轮次已经接近设置的 max_iterations 上限（剩余不足2次），不要耗尽全部轮次才停止。
    2. 连续3次修改后问题依旧，没有实质进展。此时必须先输出一次"失败反思"，分析当前卡点原因并尝试更换技术路线（更换第三方库、改变算法、改变实现思路）。若第4次修改依然失败，则强制终止。
    3. 遇到外部环境限制：依赖版本冲突、系统环境缺失、第三方API限制，你无法在当前沙箱解决。
    4. 需求本身模糊、缺少关键信息，继续尝试也无法达成目标。
    5. 发现任务目标技术上不可实现，存在底层硬限制。

    终止任务输出格式：
    - 状态：【任务完成 / 任务终止，无法完全达成】
    - 当前已经做到的成果
    - 阻塞障碍根因，明确说明为什么不能继续解决
    - 给出可供人类接手的方案建议：需要补充什么信息、需要人工修改的代码位置、外部环境需要调整什么
    - 列出未解决风险与遗留问题，严禁伪装成全部完成。

    禁止行为：
    - 不要无限循环做无效小修改，假装在推进任务。
    - 不要掩盖报错，不要把未解决问题标记为完成。
    - 不要编造测试通过的虚假结果。

    只有同时满足下面全部条件，才允许标记【任务完成】：
    1. 核心业务功能运行正常
    2. 全部新增/原有单元测试执行通过
    3. 边界异常场景有对应处理
    4. README文档同步更新
    5. 明确写明工具现存局限与风险点

user_prompt: |
  你的任务：基于我的需求，完整实现一个可独立运行的工具，全程自主完成编码、安装依赖、运行调试、bug修复、自测，直到工具可以正常工作。

  必须严格遵守下面全部工程约束，不能省略：
  1. 项目结构规范：自动创建合理项目目录，区分源码、测试、配置；生成 requirements.txt / pyproject.toml 等依赖声明文件。
  2. 健壮性要求：
     - 所有外部输入、文件IO、网络调用全部增加异常捕获，友好错误提示，不直接抛出原始堆栈给终端用户。
     - 处理边界情况：空输入、非法参数、文件不存在、权限不足、超时。
     - 参数校验，禁止未校验直接使用外部输入。
  3. 测试要求：
     - 强制使用 pytest 框架编写单元测试，禁止使用原生 unittest 或自定义测试脚本。测试文件需放置在独立的 tests/ 目录下。
     - 必须调用 shell 真实执行 pytest，读取真实 stdout/stderr，禁止脑补测试结果；测试失败则定位问题、修改代码，反复迭代直到测试全部通过。
  4. 代码规范：
     - 遵循 PEP8 规范，核心函数必须包含类型提示（Type Hints）和 Docstring，关键逻辑需有行内注释。
  5. 依赖安装闭环：
     - 生成依赖文件后，必须主动使用 shell 执行 pip install -r requirements.txt，确保当前运行环境具备所有必需依赖，禁止假设环境已就绪。
  6. 文档要求：
     - 生成 README.md，写明功能说明、安装步骤、运行示例、参数说明、已知限制。
  7. 执行闭环：
     - 写完代码后主动运行程序，观察 stdout/stderr 报错，根据报错自动修复，不要等待我反馈错误。
  8. 安全约束：
     - 只允许操作当前工作目录下文件，禁止删除、修改项目目录以外的文件。
     - 禁止执行任何高危系统命令（如 rm -rf /、mkfs 等）。在执行涉及批量删除、强制重置的 shell 命令前，必须在思考过程中说明风险，并尽量使用更安全的替代方案。
  9. 任务完成判定条件：
     - 代码可运行 + 单元测试全部通过，输出运行成功示例，明确列出当前工具的局限性，不要虚假标记完成。

  我的业务需求：
  实现一个 Python 项目工程健康巡检 CLI 工具（建议命名 py-health-check）。
  功能清单：
  1. 递归扫描指定源码目录下的全部 .py 文件，检测以下五类工程质量问题：
     - 缺少单元测试：项目不存在 tests/ 目录或测试文件，或源码模块没有对应的测试文件；
     - 硬编码常量：代码中的魔法数字、硬编码字符串（如直接写死 URL、密钥、Token、绝对路径等）；
     - 废弃函数：调用了已明确标记废弃（deprecated）的函数与常见过时 API；
     - 缺少异常捕获：裸 except（未指定异常类型）、捕获后仅 print 不记录、文件 IO 与网络调用未加 try 保护；
     - 注释缺失：公共函数与类缺少 Docstring，复杂逻辑段落缺少注释。
  2. 输出 Markdown 巡检报告：
     - 报告内容包含：巡检概览（文件数、代码行数、问题数统计）、问题明细列表（文件路径 + 行号 + 问题类型）、风险分级（高 / 中 / 低）、每条问题的优化建议；
     - 输出项目健康评分（百分制，采用加权扣分制，评分规则需在报告中写明）。
  3. CLI 参数：
     - --dir 扫描目录（必填）；
     - --ignore 忽略目录（可选，支持传入多个，用英文逗号分隔；默认忽略 .git、__pycache__、venv、.venv、build、dist 等常见目录）；
     - --output 报告输出路径（可选，默认在当前工作目录生成 health_report.md）。
  4. 边界情况处理：扫描目录不存在、目录读取权限不足、空项目（无任何 .py 文件）、单个文件语法解析失败（跳过该文件并在报告中记录，不中断整体巡检）。
  5. 技术路线建议：优先使用 Python 标准库 ast 模块实现静态分析，避免引入重型第三方依赖；确需依赖的必须在 requirements.txt 中声明。
  6. 测试夹具要求：在 tests/ 目录下生成"正常代码样例"与"缺陷代码样例"两类测试夹具，逐条验证各项检测规则的命中能力与误报情况。
  7. README 特别声明：必须写明"本工具仅工程质量参考，不能替代人工代码评审"。

  完成之后，输出总结：项目结构、如何运行、测试结果、现存风险点。

tools: 
  enable: 
    - file_system
    - shell
    - lsp
    - git
  disable: 
    - browser
    - web_search
  shell: 
    timeout: 120

七、结尾思考

普通对话 AI 的模式是：人主导，AI 输出片段，人负责调试。 DeepSeek‑Harness 这类本地 Agent，构建了写代码 ➔ 执行 ➔ 看报错 ➔ 修复的完整闭环。

从架构层面看，dsh 的「一切皆插件」设计思路很有启发性：它不试图做一个大而全的 Agent 平台，而是提供一个可组合的运行时底座，让开发者按需装配自己的 Agent 系统。模型可以换、工具可以换、循环策略可以换，甚至 UI 也可以换------这种解耦设计，对企业级 Agent 落地非常友好。

但我们必须认清现实：Agent 擅长脚手架、简单工具、重复机械工作；面对复杂业务逻辑，幻觉、逻辑漏判、迭代轮次上限都是现阶段绕不开的天花板。

为什么 Agent 在评审代码时标准严苛，自己编码却频频违背相同规范？这就是本次实验暴露出的生成‑评审行为不一致，也是现阶段 Agent 难以绕过的痛点。

未来不是 AI 取代程序员，而是程序员把大量重复机械的基础工作交给 Agent，人聚焦业务逻辑、架构设计、最终评审。

你是否也遇到过类似现象：AI 做代码评审逻辑严谨，可自己生成代码却频频违反规范？你觉得造成「生成‑评审行为不一致」的主要原因是什么？欢迎在评论区交流。

作者：延君