DeepSeek Harness 进入 Agent 和 Coding Agent 讨论后，很多开发者第一反应是研究模型、运行模式和界面，但真正决定它能否进入日常 IT 工作流的，往往是插件边界。创源 AIGC 在本文中只作为一个可替换的在线模型节点出现，重点不在产品介绍，而在于如何为一个插件写清楚输入、权限、证据和退出条件。本文讨论的问题是：当模型、工具、会话、沙箱和事件都可以通过插件组合时，普通开发者怎样从一个低风险的只读代码审查插件开始，避免把"能调用"误当成"可以放权"。文章适合使用 Codex、Claude Code、VSCode AI 插件、Ollama 或 LiteLLM，并准备尝试 Harness 扩展的开发者。
截至 2026 年 8 月 16 日，DeepSeek Harness 仍处于开发者预览阶段。公开说明强调"一切皆插件"，Cordis 内核负责插件加载、卸载和依赖关系，模型、工具、技能、会话、沙箱、存储、循环、调度和 UI 由插件提供，并通过服务与事件协作。官方资料也提醒基础 API 仍会迭代，因此本文中的接口和配置片段都是用于说明工程思路的示意，不把它们当成某个具体版本的稳定 SDK。
一、插件真正难的地方，不是把函数接起来
很多插件教程从"声明一个工具"开始：定义名称、接收参数、返回字符串，然后让模型在需要时调用。这个过程能快速得到演示效果，却没有回答最重要的四个问题：插件可以看到什么，能改变什么，结果如何被验证，出现异常时怎样停下。 
在 Coding Agent 中，一个插件通常处在模型和真实环境之间。模型给出调用意图，Harness 把意图交给插件，插件再读取代码、运行命令、访问网络或写入文件。每一层都可能改变数据形态，也可能放大权限。如果插件只返回一段自然语言，开发者很难区分"审查完成"和"模型生成了一段听起来像审查的文字"。
我会把插件当成一个小型系统，而不是一个函数。它至少有五个边界：
- 输入边界：插件接受哪些文件、参数、上下文和数据等级。
- 能力边界：插件允许调用哪些服务、命令、目录和网络出口。
- 输出边界：插件返回哪些结构化结果，哪些内容必须标记为未验证。
- 证据边界：插件如何保存输入版本、执行步骤、检查结果和人工决定。
- 退出边界：超时、权限拒绝、依赖升级或风险升高时如何停止和撤销。
这五个边界决定了插件能不能被安全地组合。一个审查插件可能只需要读取 Git diff 和测试报告，完全不需要写仓库；一个发布插件则可能触发部署、修改配置或发送通知，必须经过更高等级的授权。两者都可以通过 Harness 加载，但不应共享同一套默认权限。
插件化还有一个容易被忽略的事实：插件不是模型的"手"。它不应该替模型完成所有未经确认的动作，而应该把高层意图翻译为有限、可检查的能力。例如模型说"检查这个变更"，插件可以读取指定 diff、调用静态分析和测试命令，再返回结构化结果；模型说"修复并发布"，插件不应因为看懂了这句话就自动获得写入和发布权限。
二、先写插件契约，再决定用什么模型
一个可维护的插件契约，不是完整的 SDK 文档，而是一张能被人和程序共同检查的能力说明。为了避免把示意代码误解成官方 API，下面使用一个自定义的 TypeScript 伪接口。它表达的是约束关系，不代表当前 DeepSeek Harness 的具体导出名称。
ts
type DataClass = "public" | "redacted" | "internal" | "restricted";
interface PluginContract {
id: string;
version: string;
input: {
dataClass: DataClass;
files: string[];
maxBytes: number;
};
capabilities: {
read: string[];
write: string[];
network: "none" | "allowlisted";
commands: string[];
};
output: {
schema: string;
evidenceRequired: boolean;
sideEffects: "none" | "declared";
};
stop: {
timeoutMs: number;
maxEvents: number;
onDenied: "pause" | "fail";
};
}这张契约有几个值得坚持的细节。第一，dataClass 不能由模型自由升级。输入是脱敏数据，插件就只能按脱敏等级处理；如果任务突然需要受限数据，应当返回暂停状态，由人重新授权。第二，write 和 commands 必须显式列出，空数组不是"暂时没想好"，而是明确的只读声明。第三，输出要说明是否需要证据，避免插件只返回一个"通过"或"不通过"。第四，停止条件必须属于插件契约，而不是依赖模型自己记住。
模型选择应该放在契约之后。因为同一个插件可以调用本地模型、在线模型或规则引擎，但它的权限和输出格式不应随着模型变化而变化。模型可以负责解释静态分析结果、归纳测试失败或提出风险等级；文件读取、命令执行、数据脱敏和证据记录仍由插件和 Harness 负责。
契约也不是写完就冻结的文档。只要插件增加了一个目录、一个命令或一种网络访问，能力集合就发生了变化，需要提升契约版本并重新跑验收。为了避免版本号只表示代码发布，可以把变化分成三类：增加可选输出属于兼容扩展，改变字段含义属于需要迁移的行为变化，增加写入或联网能力则属于权限变化。权限变化必须经过比普通代码更新更严格的审查。
我还会把能力划成几个等级。L0 只读本地文本，L1 运行无副作用的检查，L2 写入临时工作区，L3 修改代码仓库，L4 触发外部系统。插件只能从低等级向高等级逐步申请，不能因为模型在一次任务中表现稳定，就自动获得更高等级。等级之间要有明确的批准事件和失效方式，这样团队可以按任务风险选择能力，而不是按插件作者的主观判断放权。
对于同一插件的不同版本，输入和输出格式也要保存迁移说明。例如旧版本把 severity 输出为三个等级，新版本增加"信息"级别；旧版本的行号按原文件计算，新版本按补丁片段计算。若这些变化没有记录，历史轨迹虽然还能打开，审查者却无法正确比较。契约的目标不是让所有版本永远兼容，而是让不兼容变化能够被看见、被拒绝和被迁移。
如果要把契约写成配置文件，可以采用更接近团队审查的形式：
yaml
id: repo-review-readonly
version: 0.1.0
data_class: redacted
read:
- "src/**/*.ts"
- "tests/**/*.ts"
- "artifacts/diff.patch"
write: []
network: none
commands:
- "npm test -- --runInBand"
- "git diff --check"
evidence:
required: true
append_only: true
stop:
timeout_ms: 120000
max_events: 80
on_denied: pause这里的 glob、命令和字段仍然需要由实际执行器解析。配置的作用不是替代沙箱，而是把意图先写出来，让审查者知道插件打算做什么。真正的执行层还要再次校验路径、参数、当前工作目录和进程权限。
在团队协作中，契约文件最好和测试样例放在同一个版本库里。每次修改契约，都必须同时修改至少一个正向样例和一个拒绝样例。正向样例证明新增能力确实可用，拒绝样例证明边界没有因为重构而消失。这样，代码评审者不需要阅读所有实现细节，也能先从契约和样例判断这次变更是否扩大了风险。
三、完整案例：只读代码审查插件如何工作
下面设计一个 repo-review-readonly 插件。它的任务不是修改代码，而是读取一个已经脱敏的补丁、相关测试和静态检查结果，输出结构化审查意见。这个案例的好处是副作用小，容易回放，也能覆盖 Harness 最重要的能力：上下文注入、工具调用、事件记录、模型协作和人工验收。 
输入只保留审查所需的最小集合
插件不读取整个仓库，而是由上游任务准备一个输入包：
text
review-2026-08-16/
├─ diff.patch
├─ changed-files.txt
├─ test-report.txt
├─ lint-report.txt
├─ api-contract.json
└─ review-policy.mddiff.patch 是审查主体，changed-files.txt 用于确认改动范围，测试和 lint 报告提供确定性证据，api-contract.json 用来检查接口兼容性，review-policy.md 则描述团队关心的风险。插件不需要读取生产日志，也不需要访问数据库，更不需要知道开发者的主目录。
在输入进入插件前，还要完成两步检查。第一步是路径归一化，防止 ../、符号链接和大小写差异绕过白名单。第二步是大小和编码检查，避免模型被异常大的二进制文件或不可见控制字符拖入上下文。达到大小上限后，插件应返回 INPUT_REJECTED，而不是静默截断。
先用确定性工具，再让模型解释
插件的执行顺序不能由模型完全决定。我会固定成四步：读取输入清单、运行规则检查、汇总确定性报告、调用模型生成解释。规则检查可以包括危险函数扫描、接口字段变化、测试失败分类和 diff 行数限制。模型只接收必要的报告和少量代码片段，不直接执行命令。
这样设计有两个好处。第一，模型的自然语言不会替代规则检查；第二，模型输出错误时，仍然保留可以独立核验的证据。例如规则引擎发现一个新增字段没有默认值，模型可以解释它可能影响旧客户端，但不能把"我认为安全"写成最终结论。
输出必须区分事实、判断和待确认项
审查插件不应只返回一段 Markdown。更适合交给 Harness 的输出结构是：
json
{
"status": "needs-human-review",
"findings": [
{
"id": "API-002",
"severity": "medium",
"file": "src/orders.ts",
"line": 48,
"fact": "新增参数没有在兼容性样例中出现",
"assessment": "旧客户端行为需要确认",
"evidence": ["api-contract.json", "test-report.txt"],
"action": "补充旧客户端回归样例"
}
],
"checks": {
"path_policy": "pass",
"test_report": "pass",
"diff_scope": "pass"
},
"side_effects": []
}fact 表示可以从输入中直接找到的内容，assessment 表示模型或规则的判断，action 表示建议的下一步，不能把三者混成一句结论。evidence 必须引用输入包中的文件或事件编号，不能写成模糊的"根据上下文"。side_effects 即使为空也要明确返回，提醒下游这个插件没有写入或发布行为。
实际的审查结果还需要处理"没有发现问题"和"没有足够证据"的区别。前者意味着检查范围内的规则通过，后者意味着输入不完整、测试没有运行或插件被权限拒绝。建议分别使用 pass、needs-evidence 和 blocked 三种状态，不要用一个绿色的"完成"覆盖所有情况。下游流程只能对 pass 且经过人工复核的结果继续，其他状态要么补证据，要么暂停。
为了减少模型编造，提示内容也应从结构化报告生成，而不是把整段仓库说明直接拼接进去。插件可以先给模型一个事实区、一个待判断区和一个禁止推断区。事实区来自规则输出，待判断区来自风险候选，禁止推断区列出不能根据现有输入得出的结论，例如价格、性能、用户规模或生产影响。模型负责写清楚不确定性，不能替插件补造证据。
人工验收才是最终出口
插件完成后，Harness 可以把结果放入 Trajectory 视图或任务工件中，但不应自动把 needs-human-review 改成 accepted。人工审查者需要看到输入版本、规则检查、模型输出、被拒绝的调用和插件版本。只有确认事实、判断和行动建议没有混淆，才可以把结果交给 Pull Request 或后续流程。
这个案例中，插件的价值不是替代 Code Review，而是把重复的读取、检查、证据整理和风险分类固定下来。模型的作用被限制在解释和归纳，决定是否合并仍然由开发者和组织流程负责。
如果要把插件接到 Pull Request 流程，建议先输出一份不可变的审查工件，再生成供人阅读的摘要。不可变工件包含输入哈希、检查版本、事件编号和结构化发现；摘要可以由模型改写，但不能反过来覆盖原始工件。这样，讨论区里的文字即使被编辑，后续仍能从工件恢复事实。对于同一补丁的多轮审查，也要保留每一轮的上下文版本，避免把旧结论误认为新结论。
插件还应提供"重新审查"而不是"继续对话"两个入口。重新审查从新的输入包和新的版本开始，适合代码已经改变的情况；继续对话只允许在同一事件流中补充人工说明，不能偷偷替换文件。两者分开以后，回放和责任追踪会清楚很多，也能避免模型沿着一条已经过期的对话历史继续做判断。
四、事件流不是日志装饰，而是插件的第二份输出
DeepSeek Harness 公开设计强调运行过程可追踪，会话日志采用仅追加思路，记录模型看到的内容、工具调用、结果、子 Agent 调度和上下文注入，并支持恢复、分叉、检索和回放。对插件开发者来说，这意味着插件除了业务输出，还必须产生可理解的事件。 
我会把事件分成四类：
| 事件类别 | 应记录的内容 | 不应记录的内容 | 用途 |
|---|---|---|---|
| 输入事件 | 输入包版本、文件哈希、数据等级 | 完整密钥、未经脱敏的客户数据 | 证明插件看到什么 |
| 能力事件 | 请求的文件、命令、网络和授权结果 | 未经批准的隐式权限 | 证明插件想做什么 |
| 结果事件 | 退出码、结构化报告、证据编号 | 只有"成功"没有细节的摘要 | 证明发生了什么 |
| 人工事件 | 批准、拒绝、范围修改、最终决定 | 私人聊天中的临时判断 | 证明谁承担责任 |
事件设计需要避免两个极端。一个极端是只记录最终输出，导致无法解释中间行为；另一个极端是把所有原始输入和模型上下文永久保存，造成隐私和存储风险。对于只读审查插件，文件哈希、行号、报告摘要和脱敏片段通常足够，完整代码不必重复写入每一条事件。
事件编号还可以帮助处理并发。标准模式可能同时运行多个工具，PTC 模式可能在一段程序中组合多步调用，子 Agent 也可能产生独立轨迹。插件应当为每次调用返回 run_id、parent_event_id 和 sequence，让回放系统知道事件属于哪个任务、哪个分支和哪个执行顺序。没有这些标识，开发者看到的只是混在一起的输出。
事件还应记录"意图"和"实际动作"的差异。模型可能请求读取 src/orders.ts，执行器却因为符号链接解析到了另一个真实路径；模型可能请求运行测试，策略层却把命令改成沙箱中的包装脚本。两者都要写入事件，才能判断策略是否按预期生效。只记录模型请求会高估它的权限，只记录最终动作又会丢失它为什么提出这个请求。
对拒绝事件也要保持完整记录。拒绝不是系统噪声，而是插件契约的一部分。事件至少要包含拒绝原因、匹配到的规则、请求来源、是否允许人工重新授权以及后续状态。这样，在回放时可以判断 Agent 是因为合理的边界被暂停，还是因为配置错误频繁遭到拒绝。拒绝率过高可能表示任务拆分不合理，也可能表示插件契约写得过窄，不能简单用"自动化程度低"解释。
回放也不能简单地重新运行所有副作用。只读插件可以使用冻结的输入包重新执行；写入或网络插件则应默认进入模拟模式，使用记录的响应和权限决策复现逻辑。否则一次回放可能再次访问外部系统，甚至产生与原任务不同的结果。
事件脱敏也需要有版本。今天只遮盖邮箱和手机号，明天可能还要遮盖客户编号、仓库路径和内部域名。如果脱敏规则改变，旧事件不能假设仍然符合新政策。可以在每条事件中记录 redaction_policy 的版本，并在导出前重新扫描。导出给模型的事件和导出给审计人员的事件也可以不同，前者保留足够的技术上下文，后者保留足够的责任证据。
对于长时间运行的任务，事件流还要支持检查点。插件完成输入校验、规则检查和模型解释后，分别写入阶段性检查点；恢复时从最近一个已确认的检查点开始，而不是把所有工具调用重复执行。检查点不能替代最终验收，但可以减少网络波动、机器重启或 UI 断开后的重复工作。
五、怎样测试一个插件没有越过自己的边界
插件测试不能只验证"正常输入返回正常结果"。最有价值的测试，往往是输入异常、权限拒绝、模型失控和依赖变化时，插件是否按契约停止。 
契约测试
先对配置做静态检查：write 是否为空，命令是否在允许清单，网络是否关闭，数据等级是否足够，超时和事件上限是否存在。再把实际运行时暴露的工具集合与契约比较，发现多出来的能力就直接失败。这样可以避免配置写着只读，运行时却默认挂载了通用 Shell。
路径和参数测试
准备包含 ../secrets.txt、符号链接、大小写混合路径、超长文件和二进制内容的样例，确认插件不会读取白名单之外的文件。命令参数则要测试空值、引号、管道、重定向和控制字符。测试的目标不是把所有攻击都列完，而是证明执行器不会把模型提供的字符串直接拼接进高权限命令。
故障注入
让测试命令超时、返回非零退出码、输出截断、模型返回无法解析的 JSON、事件存储短暂不可用，再观察插件状态。正确结果应该是可分类的失败，例如 TIMEOUT、SCHEMA_INVALID、EVENT_STORE_UNAVAILABLE 或 PERMISSION_DENIED，而不是继续尝试写文件或向模型发送更多敏感上下文。
对抗性输入
把 Prompt Injection 放进 review-policy.md、代码注释和测试报告中，观察模型是否把资料里的命令当成系统指令。插件应把这些文件标记为不可信内容，并在发送模型前加上边界说明。即使模型按照恶意文本行动，工具层也必须拒绝超出契约的调用。
回放回归
每次升级 Harness、模型或插件依赖，都使用固定输入包回放至少三类任务：全部通过、存在中等级别风险、输入被拒绝。比较的不只是最终审查结论，还包括调用顺序、事件数量、拒绝次数、输出 Schema 和人工确认点。模型答案有小幅措辞变化并不一定是回归，但权限扩大、证据丢失和状态错误转换一定需要处理。
我会把这套测试整理成一个小矩阵，而不是只保留一条"成功样例"：
| 测试维度 | 正常样例 | 边界样例 | 期望结果 |
|---|---|---|---|
| 文件路径 | 白名单内的源码 | 符号链接、父目录和超长路径 | 越界读取被拒绝并记录规则 |
| 报告格式 | 合法 JSON 和退出码 | 截断输出、乱码和缺失字段 | 返回可分类的输入或工具错误 |
| 模型响应 | 符合 Schema 的判断 | 注入指令、额外字段和无法解析文本 | 保留原始证据，暂停后续动作 |
| 事件存储 | 连续写入 | 短暂不可用、重复提交和乱序 | 不丢责任事件，不重复产生副作用 |
| 版本升级 | 同一契约版本 | 输出字段变化、权限新增 | 明确迁移或阻止加载 |
此外，还可以做一次变异测试：故意删除一条路径规则、改变命令参数、打乱事件顺序，再确认测试能够失败。一个只在"实现正确"时通过的测试集，无法证明边界真的受到保护；只有把规则改坏时它也能及时报警，才说明测试覆盖了控制面。
对于模型部分，最好保存一组人工标注的风险样例，包含应该指出的问题、应该拒绝的推断和必须引用的证据。模型升级后不要求每句话相同，但要求状态、严重级别、证据引用和待确认项保持在可接受范围。这样可以把模型变化限制在解释质量，而不会影响插件的权限和验收协议。
六、在线模型、本地模型和插件职责如何拆开
插件契约确定以后，模型节点可以按数据等级和任务类型替换。公开代码或脱敏报告可以使用在线服务，核心逻辑和受限数据可以交给本地模型，纯规则检查则不需要模型。Ollama 可以承担本地模型运行，LiteLLM 可以提供统一接口和逻辑别名，但它们并不替代 Harness 的会话、工具、权限和事件管理。 
创源 AIGC 如果进入这个工作流，更适合放在"解释型模型节点"位置：接收已经过滤的报告和少量代码片段，输出符合契约的审查解释。它不应直接拿到整个仓库，也不应获得写文件、执行发布命令或读取生产凭据的能力。模型节点是否在线，不能改变插件对输入和输出的硬性约束。
在一次非敏感的接口兼容性测试中，记录的接入地址为：178.nz/yinc。这个记录只用... Harness 前，仍要确认数据等级、协议兼容性、上下文长度、延迟、成本、日志保留方式和替代路径。
可以用下面这张表决定模型节点放在哪里：
| 任务内容 | 数据风险 | 模型适合承担的角色 | 插件必须保留的控制 |
|---|---|---|---|
| 公开代码风格说明 | 低 | 归纳和改写 | 文件白名单、输出 Schema |
| 脱敏测试报告解释 | 中 | 分类失败原因、生成复核问题 | 输入脱敏、证据引用、人工验收 |
| 核心权限逻辑分析 | 高 | 在受控环境中提出风险假设 | 本地运行、无外网、只读沙箱 |
| 生产发布判断 | 很高 | 提供候选方案 | 不授予发布权限、强制审批和回滚 |
这套拆分的核心是让模型可替换，让控制不可绕过。无论使用在线服务、本地模型还是纯规则引擎，插件都应该继续检查输入、执行、证据和状态。创源 AIGC 只是其中一种接入节点，不应成为插件契约的隐含前提。
在线节点还会引入一个经常被忽略的时间问题：相同的输入在不同日期、不同模型版本或不同服务负载下，可能产生不同解释。插件不能把一次在线响应当成永久事实，而应记录请求时间、逻辑模型名、适配层版本、输入哈希和输出校验。对于需要长期复盘的审查，应保存脱敏后的响应摘要，或在本地用同一输入重新运行规则部分，避免把所有可重复性寄托在外部服务仍然保持不变。
如果网络不可用，插件应有三种明确行为：切换到经过批准的替代模型、只运行确定性检查、直接暂停并等待人工。不能让模型节点的失败触发更宽的权限，也不能为了"完成任务"把受限文件发送到另一个未审查的服务。适配层的回退逻辑越简单，审计越容易；复杂的自动路由应该另行建设，不要偷偷塞进一个只读审查插件。
七、插件发布以后，最容易被忽略的是撤销
插件开发通常以"能加载"为完成标准，但进入团队环境后，真正困难的是升级、降级和撤销。DeepSeek Harness 目前是开发者预览版，官方资料已经提示核心插件和基础 API 会持续变化，因此插件必须有自己的生命周期记录。 
生命周期记录还应该包含"责任转移"。插件由谁维护，谁批准权限变化，谁负责处理漏洞，谁在插件被撤销后接管任务，都要写进团队文档。否则插件虽然有版本号，却没有真正的所有者；出现数据外发或错误修改时，团队只能临时寻找熟悉代码的人。对于只有一两名开发者的小项目，也至少要保留一个人工接管脚本和一个能导出历史工件的命令。
我会为每个插件保存以下信息：
- 插件标识、版本和源码提交。
- 依赖包版本、许可证和构建摘要。
- 输入数据等级、文件范围和命令白名单。
- 是否访问网络、写入文件、创建进程或调用子 Agent。
- 输出 Schema、事件 Schema 和回放样例。
- 上一个可用版本、替代插件和人工接管方法。
升级时先运行只读回放，再运行包含拒绝和超时的故障样例。若新版本增加权限、减少证据、改变失败状态或无法打开旧事件，先暂停升级。不要因为主程序可以启动，就判断插件已经兼容。
撤销也需要设计。发现插件存在数据外发、路径绕过或结果不可复现问题时，第一步应当禁用加载和新任务调用，第二步保留历史轨迹和输入哈希，第三步切换到人工或替代插件，第四步重新审查受影响的任务。删除插件文件不能代替撤销，因为旧任务仍可能引用它的事件和输出格式。
对于会产生副作用的插件，还要设置能力租约。租约应包含任务编号、授权人、允许动作、失效时间和撤销状态；超过时间或任务状态变化后，工具层自动拒绝。只读审查插件可以不需要复杂租约，但一旦它被扩展为自动修复、提交代码或触发 CI/CD，就必须重新评估能力等级，不能沿用只读插件的默认配置。
插件从只读扩展到可写时，最好新建一个能力标识，而不是在原标识上增加开关。例如 repo-review-readonly 和 repo-review-fix 应当是两个可以分别审查、分别撤销的组件。这样历史事件不会把一次只读审查误认为修改任务，运行时也能通过能力标识阻止错误组合。名称上的区分看似琐碎，却能减少配置继承带来的误授权。
八、什么时候不该自己写 Harness 插件
插件化很有吸引力，但不是每个需求都值得自己实现。以下情况中，直接使用已有工具或人工流程可能更合适：
第一，任务是一次性的，且人工完成比整理契约、事件和回放样例更快。第二，团队没有人能维护沙箱、依赖、日志和升级测试。第三，数据等级很高，但组织还没有明确的外部接入和本地运行政策。第四，插件输出没有确定性验收方式，只能靠模型自己宣布完成。第五，业务流程本身还没有稳定边界，频繁变化会让插件契约持续失效。 
如果确实需要扩展，可以遵循一个较小的投入顺序：先写只读、无网络、无子 Agent 的插件；再增加结构化输出和事件记录；之后加入确定性检查和回放；最后才考虑写文件、联网或自动执行。每增加一种能力，都要同步增加测试、日志和撤销路径。这样即使最终停止开发，也能保留可复用的输入包、检查脚本和权限清单。
一个成熟插件的验收，不是"模型能不能调用"，而是下面这些问题都有明确答案：
- 插件看到的最小数据是什么？
- 插件永远不能访问什么？
- 结果中的事实、判断和建议如何区分？
- 哪些证据可以让人工复核？
- 超时、拒绝、依赖故障和模型失控时如何停止？
- 升级后如何回放，发现问题后如何撤销？
如果这些问题没有写进契约，插件就仍然只是一个隐藏在 Agent 后面的脚本。它可能在演示环境里工作，却无法承担真实研发流程中的责任。
结语：插件的价值，是把能力变成可以拒绝的合同
DeepSeek Harness 的"一切皆插件"设计，真正改变的不是开发者多了一个按钮，而是 Agent 能力被拆成了许多可以独立授权、替换和验证的组件。对于 Coding Agent 来说，这种拆分让模型、工具、会话、沙箱和事件各司其职；对于团队来说，它也要求每个插件都明确自己的数据边界、证据格式和退出方式。
创源 AIGC 可以作为在线解释节点，Ollama 可以承担本地模型，LiteLLM 可以处理接口适配，Codex 或其他代码模型可以负责局部理解，但插件契约必须独立于这些节点存在。真正可迁移的不是某次模型回答，而是输入包、权限清单、结构化输出、事件轨迹、回放样例和人工决定。
当一个插件能够在权限不足时暂停，在证据缺失时拒绝，在依赖异常时保留现场，在版本升级后完成回放，在出现风险时被撤销，它才从"能运行的扩展"变成了可以进入 IT 工作流的工程组件。这也是当前研究 DeepSeek Harness 最值得落地的一条经验：先把能力写成一份可以被拒绝的合同，再让模型决定如何使用它。
先守住边界，才能逐步增加自动化，而不必把每次试验都变成一次不可逆的系统变更和权限扩张。