论衡长文流水线 zuoyunlai/lunheng-article-pipeline-dsh

论衡（lunheng-article-pipeline）—— 一个 DeepSeek Harness bundle，用于多智能体长篇写作

🌐 English（本文件）｜ ｜ Español ｜ Português ｜ हिन्दी

版本：v19.27.15（DSH bundle：package.json + cordis.patch.yml + lib/index.js）

一个 DeepSeek Harness（DSH）bundle，注册 两个按需加载的智能体技能：
- lunheng-article-pipeline —— 主流水线，共 9 个角色（T1–T9，见下文）。
- lunheng-commands —— 一层薄封装，暴露 13 个 /lunheng- 斜杠命令（draft / resume / cite / audit / journal / ppt / history / rollback / status / stats / gate / abort / help）。
不新增角色，不新增 M-gate 条目；详见 skills/lunheng-commands/SKILL.md。

主技能把长篇内容生产 —— 学术论文、行业分析、商业评论、长篇文章 —— 变成一条 9 角色流水线，并保留人工介入环节。

这是什么

论衡是写作流水线，不是文本生成器。它把一份长篇交付物拆成 9 个独立角色（T1–T9），分布在 6 个阶段，用 DSH subagent 调用编排，产出的内容带有证据库、反方论证审阅、独立审计和人工检查点。

这九个角色彼此独立，不能与其他角色互换：T1 文献侦察、T2 数据侦察、T3 案例侦察、T4 分析师、T5 写作者、T6 批判性伴读、T7 审计员、T8 定稿人（由协调者自己执行）、T9 同行评审。

什么时候用

- 你需要一篇长篇内容（超过 2000 字），要经得起推敲，而且你能等上几个小时（流水线刻意 不给出小时数范围 —— 见 skills/lunheng-article-pipeline/SKILL.md §边界）。
- 主题涉及事实、数字或多个观点，因此需要证据库，不能只靠观点。
- 你想要人工检查点：起草前确认大纲，定稿前审阅终稿。

什么时候不要用

论衡主动收集 已发表 的证据，并整合你提供的证据。以下这些它自己产不出来；请先提供材料，或改用其他工具：

- 一手数据采集 —— 实验、问卷、访谈、田野调查。
- 统计分析 —— 它能引用结果，但不运行 SPSS/R/Python。
- 原始图表数据采集 —— 它负责渲染数据可视化；抓取、OCR、语音转文字需要专门工具。
- 原创图片或视频 —— DSH 没有内置文生图。封面回退到本地 SVG 或你提供的文件。
- 代码执行 —— 流水线只运行白名单脚本；其他任何脚本都需要你明确批准。

判断标准：先问证据是否已经 发表。是，论衡就收集它。不是，请先提供。

你会得到什么

| 项目 | 内容 |
| 文献卡片 [Lxx] | 已发表来源，带 A/B/C 置信度分级，以及用于原创性核查的先驱列表 |
| 数据卡 [Dxx] | 图表，附来源、年份、新鲜度分级、可信级别，冲突数字并排展示 |
| 案例卡 [Cxx] | 事件结构（谁/何时/何事/各方说法），或显式 [C-空] 空标记 |
| 分析大纲 | 论证主线、论点与证据的对应关系、反方论证方案、承重证据清单 |
| 草稿 | 逐版迭代，含 AI 痕迹清理，每次由独立写作者运行产出 |
| 评审报告 | 批判报告（C1–C7）、审计报告（G0–G14）、同行评审报告（6 个维度 + 期刊匹配）、AI 痕迹报告 |
| 最终交付物 | final/定稿.md、图表、证据包、交付说明、M 门报告 |
| DSH 集成（bundle install） | 四个只读工具 —— lunheng_m_gate（M-gate 机械预检）、lunheng_char_count（纯中文字符计数）、lunheng_handoff_check（角色交接边界上的交接报告形状 / 版本 / 配对 / agents 日志校验）、lunheng_ethics_sanitize（伦理脱敏：遮蔽访谈转录与田野笔记中的 ID / 电话 / 邮箱 / 银行卡 / 人名 / 地名；返回脱敏后的文本，由调用方决定写到哪里；v18.60.1）；如果你的会话没有暴露这些工具，就像以前一样用 pwsh 调用同一批脚本（同一份事实来源）。人工命令 /lunheng-status（读取 run/<project>/status.md；不产生模型消息）和 /lunheng-stats（跨项目遥测面板；启动宿主进程 scripts/lunheng-stats.mjs，仅白名单放行 --json；输出截断到 8000 字符；不产生模型消息）。机制文件写保护：全局守卫会拒绝针对技能包的 write/edit 类工具调用，会话无法悄悄改写流水线自身的规则。边界说清楚：守卫只看工具调用 —— pwsh 和任何子进程都不在这道门后面；所有者的逃生通道是 LUNHENG_ALLOW_MECH_EDIT=1（或 config: { allowMechanismEdit: true }）。插件 Config（部署开关，即你的配置档里本插件那一行）覆盖 quiet、allowMechanismEdit、scriptTimeoutMs、scriptMaxOutputBytes、handoffLevel、hookRewriteContent、hookMaxBlockChars、hookMaxTotalChars 和 ethicsHook，以及 panel（v18.90.0；自 v18.93.0 起默认开启 —— 只读运行面板在宿主已有的 web 载体上注册只读路径前缀，让 Web GUI 能实时展示某个项目的阶段 / 角色 / 门禁 / 产物；要关闭用 LUNHENG_PANEL=0 或 panel: false，见 SECURITY.md）—— handoffLevel 切换交接检查的严格程度（basic = 仅 A1/A2/B1；strict = 加上结构 / 版本 / 配对 / agents 日志）；hookRewriteContent 默认 false（H2 监听器只注入元数据，不改动 result.content —— 推荐）；hookMaxBlockChars 默认 262144（256 KB），限制单文本块脱敏的规模，让监听器在超大负载下不占热路径（分页请用 lunheng_ethics_sanitize 工具）；前两项和 panel 由 LUNHENG_QUIET / LUNHENG_ALLOW_MECH_EDIT / LUNHENG_PANEL 环境变量镜像，而 scriptTimeoutMs / scriptMaxOutputBytes / handoffLevel / hookRewriteContent / hookMaxBlockChars / hookMaxTotalChars / ethicsHook 是 仅 Config（没有环境变量路径） —— 十项都能在配置档里审阅；配置无效会在加载时大声报错，不会悄悄回退到默认值。 |

流水线概览

Phase 0 Topic Confirm topic, length, citation format; external-service consent
Phase 1 Retrieval T1 literature ∥ T2 data ∥ T3 cases (true parallel, independent)
Phase 1.5 补缺口 定向 T1 重新检索（可选；重点复查 [Dxx] + 补缺口论证，Permanent Gap 标签） Gate T2.5 数据条目 ≥ 简报要求；信任等级完整 Phase 2 分析 T4 分析师 → 分析大纲 Phase 2.5 大纲 人工审核（人在环） Phase 3 写作 T5 写作者 → 草稿 v1 Phase 3.5 洞察 人工提供第一手上下文（人在环）→ 草稿 v2 Phase 3.6 批判 T6 批判性伙伴 → C1–C7 报告 Phase 4 审计 T7 审计员 → G0–G14 审计报告与修订任务清单 Phase 4.2 修订 写作者修订 + 修订说明（≤2 轮，独立写作者） Phase 4.5 图表 在门禁前生成图表（SVG） Phase 4.6 G14 门禁 G14 中文 AI 痕迹门禁（串行；通过后冻结正文） Phase 4.7 评审 T9 同行评审 Gate T7.5 最新审计 + P0/P1 清单 + M 门禁退出码 0 + 报告隔离 Phase 5 定稿 T8 定稿员（由协调者运行）→ 最终草稿、证据包、交付说明

三角证据基础（[L] + [D] + [C]）——每条主张都必须对应文献、数据，事件类主张还要对应案例证据。独立审计——审计员从不改稿，只出报告。四道人工检查点——Phase 0、2.5、3.5、5。

仓库结构

lunheng-article-pipeline/ # 包即仓库 ├── package.json # 声明 main（lib/index.js）+ dsh.bundle.patch ├── cordis.patch.yml # bundle 层：自注册行 + 3 个模型档位子代理工具（仅当设置 LUNHENG_ 时挂载） ├── lib/index.js # 插件入口：技能 + 原生工具（m_gate report 写门禁报告）+ 机制写入守卫 + /lunheng-status ├── skills/lunheng-article-pipeline/ # 主技能主体（单目录） │ ├── SKILL.md # 技能入口（角色、门禁、执行边界） │ ├── AGENTS.md # 操作手册 │ ├── QUICKSTART.md # 五分钟上手 │ ├── README.md # 技能级 readme（中文） │ ├── references/ # 9 张角色卡、模板、共享门禁算法、期刊数据库 │ └── scripts/ # 零依赖 .mjs 校验脚本（数量见技能的白名单行） ├── skills/lunheng-commands/ # 配套技能：13 个 /lunheng-* 斜杠命令（draft / resume / cite / audit / journal / ppt / history / rollback / status / stats / gate / abort / help） │ ├── SKILL.md # 命令入口（命令清单、分发模型） │ ├── README.md # 命令级 readme │ ├── scripts/ # 命令处理器（如 lunheng-stats.mjs） │ └── tests/ # 命令级测试（不自动运行；手动 npm test 范围） ├── scripts/ # 仓库门禁：打包面 + 机械卫生 + 打包冒烟 ├── tests/ # node --test 套件（脚本 + 插件入口冒烟） ├── docs/ # 安装、使用、架构、常见问题、故障排查 ├── examples/preset/ # 模型档位说明与安装指南 ├── README.md # 本文件（英文源） ├── README-zh.md README-es.md README-pt.md README-hi.md ├── SECURITY.md CHANGELOG.md CONTRIBUTING.md LICENSE

插件入口把 skills/lunheng-article-pipeline/SKILL.md 注册为技能，其 resourceBase 指向该目录，因此无论从哪个工作目录出发，references/ 和 scripts/ 都能相对它解析。

补丁层做两件事：为本包插入一行（- id: lunheng-article-pipeline / name: lunheng-article-pipeline）——正是这一行让加载器导入 lib/index.js，而技能注册就发生在那里；同时插入三个模型档位子代理工具，这三个工具默认不挂载（设置任意 LUNHENG_{RETRIEVAL,STRONG,AUDIT}_{PROVIDER,MODEL} 或 LUNHENG_TIERING=on 即可挂载，设为 off 则强制关闭）。这一行自身是承重的：没有它，入口永远不会被导入，也就不会出现任何技能（v18.0.0 的缺陷，已在 18.0.1 修复；由 tests/bundle-contract.test.mjs 守护）。

文档

| 文件 | 内容 |
| docs/installation.md | 安装与验证 |
| docs/usage.md | 使用流程（阶段与产物结构） |
| docs/architecture.md | 架构（9 个角色、三角证据、G0–G14 审计、M-gate） |
| docs/introduction.md | 插件介绍 |
| docs/faq.md | 常见问题 |
| docs/troubleshooting.md | 安装/验证故障排查（现象 → 原因 → 修复） |
| SECURITY.md | 安全策略与信任边界 |
| CHANGELOG.md | 版本历史 |
| CONTRIBUTING.md | 维护与发布指南 |

发布（维护者）

发布只走打标签；禁止在本地执行 npm publish（这会绕过 CI 关卡和 OIDC 来源证明，而且已发布的 npm 版本永远无法覆盖）。
sh
git tag v19.27.15 && git push origin v19.27.15 # push one tag at a time (GitHub: >3 tags in one push triggers no workflow)

publish.yml then runs gate 1 consistency → gate 2 packaging surface → gate 3 hygiene → gate 4 pack smoke → script tests

→ tag/version equality → idempotency guard → OIDC publish --provenance --tag dsh → post-publish audit

安装

以 bundle 方式安装（推荐；入口会注册技能和 C 组能力，补丁层可以挂载模型档位工具——默认关闭，见模型路由）： sh
dsh plugin --profile web add lunheng-article-pipeline
dsh --profile web --dump-config # shows the "# == lunheng-article-pipeline" layer

新版 dsh 一旦看到 dsh.bundle 声明，就会自动把依赖加进 dsh.profile.bundles——装完重启 dsh web 即可。只有纯 npm/pnpm 安装或旧版本才需要手动添加 dsh.profile.bundles 条目。
作为普通技能目录（无需安装；宿主会监听技能根目录，内容变化时自动刷新——模式一的 SKILL.md 是进入 apply 时读取的快照，所以改内容后需要重载插件或新开会话）： sh

Copy the SKILL directory (not the repository root) into any DSH skill root:

$DSH_HOME/skills/lunheng-article-pipeline (user scope, rank 400)

<project>/.dsh/skills/lunheng-article-pipeline (project scope, rank 100)

普通目录不带 dsh.bundle 声明，所以 dsh plugin add 只会把它当作依赖安装，不会激活任何层。要安装，请复制技能目录。

环境要求

| 项目 | 要求 |
| DSH（产品版本） | 需要可用的 dsh 命令行；bundle 里的 - insert: 增量补丁行要求 DSH 5.5.0+ 产品发布版——注意：dsh 有两条并行的版本线，一条是产品发布线（semver，例如 5.5.0），另一条是 npm 包线 @deepseek-ai/dsh（预发布标签，例如 0.1.7-rc.2）；两者不能互换 |
| @deepseek-ai/dsh（npm 包版本） | peerDependencies 中声明 >=0.1.2-rc.1 <0.3.0；CI 实测 0.1.7-rc.2 和 0.2.1-rc.2（见 ci.yml 里的 install-smoke 矩阵）；范围内的其他版本（例如 0.2.0-rc.x、0.1.3–0.1.6）只声明，未验证 |
| Node | ^22.19.0 \|\| >=24.0.0（DSH 运行时下限；见 package.json 的 engines） |
| pnpm | 安装/卸载需要（dsh plugin 会转交给 pnpm） |
| 平台 | Windows / macOS / Linux（脚本零依赖，跨平台可运行） |

卸载 sh
dsh plugin --profile <profile> remove lunheng-article-pipeline

移除 bundle 会删掉 4 行 - insert:（自注册行 + 三行分层行）以及入口注册的技能，不留残留。如果你还把技能目录复制进了某个技能根目录，需要单独删掉那份副本。

模型路由

DSH 通过 settings.yaml 路由模型；subagent 继承会话模型，所以单模型配置无需任何设置就能用。要按角色分层，bundle 可以挂载三个分层工具——默认关闭（各层都继承时，它们和内置 subagent 完全一样，无条件挂载只会白白多占三个工具 schema）：

| 工具 | 角色 | 能力 |
| subagent_retrieval | T1 文献 / T2 数据 / T3 案例 | 便宜、快 |
| subagent_strong | T4 分析 / T5 写作 | 强推理 |
| subagent_audit | T6 批判 / T7 审计 / T9 评审 / G14 检测 | 顶配，不为省钱降级 |
用 LUNHENG_{RETRIEVAL,STRONG,AUDIT}_PROVIDER 和 LUNHENG_{RETRIEVAL,STRONG,AUDIT}_MODEL 覆盖——设置其中任意一个，也会挂载这三行（这样已有的分层配置不用改动就能继续用）。服务商和模型是两个独立字段；跨服务商要两个都设。LUNHENG_TIERING=on 只挂载这三行，不固定任何模型（用来确认它们可见）；LUNHENG_TIERING=off 强制三个层级都退回继承，并卸载这三行。某个层级的工具没挂载时，调度会回退到内置的 subagent。见 examples/preset/README.md 和 docs/installation.md。

数据与外部服务

流水线会向第三方发送以下内容：

| 操作 | 发送内容 | 接收方 |
| web_search / web_fetch | 搜索关键词、目标 URL | DSH 配置的搜索与抓取服务商 |
| 模型推理 | 文献、数据、案例卡片；大纲；草稿 | 当前生效的模型服务商 |
| 文生图（可选，默认关闭） | 主题与品牌提示词 | 图像 MCP，仅在你启用并配置后才会调用 |

协调者必须在 Phase 0 披露这些内容并取得明确同意。涉密选题：改写措辞、封面保留为本地 SVG（零外部调用）、选用本地模型端点。拒绝任何一项，运行都会退回 Phase 0。

验证状态

| 文章 | 规模 | 关键结果 |
| 品牌一致性文章（2026-08） | 约 7900 字，15 个来源 + 54 个数据点 | 证据包；8 项审计发现全部关闭 |
| 原创性悖论文章（2026-08） | 约 9500 字，12 个来源 + 34 个数据 + 6 个案例 | 全程共 4 轮修订，A- 评级，已发布 |
| 教师场域隔离论文（2026-08） | 约 12000 字，18 个来源 + 47 个数据 + 9 个案例 | 审计第 2 轮通过；首次一致性审计 |
| 生成式 AI 学生写作评论（2026-08） | 约 2000 字，12 个来源 + 26 个数据 | 三路并行检索；M-gate 退出码 0 |
| 甲醛白菜文章（2026-08） | 约 4200 字，12 个来源 + 29 个数据 + 4 个案例 | M-gate 退出码 0；合并 6 条回灌规则 |
| Notion 与理念哲学论文（2026-09） | 约 6280 字，18 个来源 + 15 个数据，0 个案例 | 2 轮审计，23/30 小修，M-gate 真 P0 = 0 |

本表互引：本表 6 案例的代表性深入剖析见 docs/introduction.md §实战验证（甲醛白菜事件 ~4200 字 v2.3.7-dsh.8 全流程详解 + v18.x 期间 6 案例一览）；v2.x 完整字段与产物路径见 references/case-studies.md §历史快照。

新主人口径（v18.78.0 §7.2 立项）：硬数字（版本 / 角色 / 阶段 / 闸门 / 脚本 / 命令 / 退出码族）单一真源 = docs/quick-facts.md，本表不再复述。
怎么读这张表（两个容易混淆的口径）：①「修订轮次」统计的是那次运行里所有写作者轮次（Phase 3.5 → v2、critique/T6 修复、G14 轮次、审计循环）——流水线自己设的上限 ≤2 轮只针对 Phase 4.2 审计循环，所以这两个数字量的不是一回事；② 结果是每次运行时按当时的脚本版本记录下来的历史值——用现在的脚本复现不出来。今天拿打包好的脚本去跑归档项目，比如甲醛白菜那篇会得到 exit 2 和 5 个 P0（M-Form-6/10、M-Exist-7/9、M-Integrity-1）：其中三道门是在那次运行之后才加的。这张表要读成「流水线当时产出了什么」，而不是「当前的门集能通过这些项目」。

本地门禁（只针对仓库源码——npm 包里不带 scripts/ 和 tests/；下面这条命令通过 pack-smoke 在刚下载的 tarball 上跑等价的一套）：node skills/lunheng-article-pipeline/scripts/consistency-check.mjs、node scripts/plugin-surface-check.mjs、node scripts/repo-hygiene-check.mjs、node scripts/pack-smoke.mjs、node --test "tests/*/.test.mjs"。

已知限制

- 中文优先。 角色提示词、交付物、文件名和工作流默认用中文。
- 默认不做联网核验。 数字层面的来源核查经常停在「待人工复核」，因为付费墙内和离线的来源取不到。
- 审计独立性有代价。 完整跑一次要派发 15 个以上子代理；token 大头花在上下文读取上，不是生成。
- M 门可能误报。 脚本可能把合法写法标出来；finalizer 必须记下 script_exit_raw，并为 exit 判定给出理由，而不是改文档硬凑 exit 0。
- 不能替代同行评审。 T9 报告只是投稿前的模拟。

License

MIT，见 LICENSE。