DeepSeek Harness 生产级最佳实践

文档定位

本文面向已跑通本地 Harness、准备上生产或长期运维的工程师。内容覆盖 Profile 分离、Teardown 纪律、审批矩阵、沙箱边界声明、Creator 隔离、Session Log 保留、OpenTelemetry 指标、上下文压缩、多实例部署、密钥管理、变更回滚、Code Review 检查表与 Token 成本控制。配套实战见七天学会子站与开发指南。

一、生产级 Harness 运行时全景

DeepSeek Harness（以下简称 DSH）的生产部署，核心不是「把 Web UI 跑起来」，而是把 Agent = Model + Harness 这一等式在可控边界内长期稳定运行。Harness 侧负责 Cordis 插件生命周期、工具管道、Session 事件溯源与安全审批；Model 侧负责推理。生产事故往往发生在 Harness 层：Profile 混用、Teardown 遗漏、审批矩阵空洞、Session 磁盘打满、Token 预算失控。

平面	生产关注点	常见失误
控制面	Bundle / Profile / Patch 版本锁定	生产误用 Creator 或评测 Minimal
数据面	Session Log 保留与压缩	无归档策略导致磁盘满
执行面	工具审批、沙箱路径	审批矩阵只有「允许/拒绝」两档
观测面	OTel trace + 业务指标	只看模型延迟不看工具失败率

二、Profile 分离：评测 Minimal vs 生产 Standard

2.1 为什么要分离 Profile

DSH 提供 Standard、Code、Minimal、Creator 四种预设 Bundle。它们不是「UI 皮肤」，而是不同的工具图谱、审批策略与 Token 预算默认值的集合。生产环境最常见的架构失误是：用 Minimal 做线上对话（工具不足导致任务失败），或用 Creator 做批量评测（权限过大且不可复现）。

原则：评测路径与生产路径必须使用不同 Profile，且通过 Patch 显式声明差异，而非在运行时手工切换。

2.2 Minimal 评测 Profile 设计要点

Minimal 预设的设计目标是低 Token、少工具、可重复。适用于：回归基准、插件挂载 smoke test、CI 中的 Harness 集成测试。生产级 Minimal Profile Patch 建议：

配置项	评测 Minimal 建议值	说明
工具集	仅保留 `read_file`、`list_dir` 等只读工具	避免写操作污染评测环境
审批	全自动通过（仅评测机）	减少人工变量
Session 保留	7 天或 CI 产物归档	评测 Session 可丢弃
模型	固定型号与 temperature	保证基准可比
并发	单 Session 串行	避免资源争抢扭曲指标

实操步骤：

在仓库中维护 profiles/eval-minimal.patch.yaml，与 profiles/prod-standard.patch.yaml 分目录存放。
CI 流水线只加载 eval-minimal；staging / production 加载 prod-standard 或 prod-code。
在预设对比实验室录制同一任务的 Minimal vs Standard 对比截图，作为团队 onboarding 材料。

2.3 生产 Standard Profile 设计要点

Standard 是大多数对话与轻量工具场景的默认生产 Profile。生产 Patch 应明确：

工具白名单：按业务域分组（文件、网络、MCP 外部工具）。
审批默认值：写操作、网络出站、子 Agent Spawn 需分级审批。
上下文压缩阈值：长会话触发 summarization 的 token 水位线。
Creator 插件禁用：生产 Standard Bundle 不得挂载 Creator 高权限插件。

2.4 Code Profile 的边界

Code Profile 面向仓库操作与开发辅助。生产上建议独立实例或独立命名空间，与面向终端用户的 Standard 隔离，避免开发工具（如 shell、git push）进入用户会话图谱。

2.5 常见误区

误区	后果	纠正
「Minimal 更省 Token，生产也用」	任务完不成，用户反复追问	生产用 Standard，Minimal 仅评测
「Creator 功能多，staging 也用 Creator」	staging 成为权限突破口	Creator 仅隔离沙箱 + 人工监督
Profile 切换不写 Patch	配置漂移、无法回滚	一切差异进版本库 Patch

三、Teardown 纪律：可逆副作用的生产契约

Cordis 插件通过 ctx.effect() 注册可逆副作用。生产环境中 Teardown 遗漏 会导致：内存泄漏、文件句柄耗尽、重复注册工具、幽灵 MCP 连接。这是 DSH 与「一次性脚本」框架的本质区别之一。

3.1 Teardown 检查清单

每个 ctx.effect() 必须回答以下问题：

注册了 event listener？→ Teardown 中 removeListener
打开了 MCP 连接？→ Teardown 中 close() / disconnect()
创建了定时器？→ Teardown 中 clearInterval
写入了临时目录？→ Teardown 中清理或使用 scoped temp
向全局工具表注册？→ Teardown 中注销
修改了 process 级 handler？→ Teardown 中恢复

// 生产级插件 Teardown 示例
export default {
  name: "prod-mcp-bridge",
  apply(ctx) {
    const clients: MCPClient[] = [];
    ctx.effect(() => {
      const client = connectMCP(process.env.MCP_URL!);
      clients.push(client);
      ctx.provide("externalTools", client.listTools());
      return () => {
        clients.forEach((c) => c.close());
        clients.length = 0;
      };
    });
  },
};

3.2 热重载与滚动升级

生产滚动升级时，旧实例卸载插件必须完整 Teardown，否则新旧版本可能同时持有 MCP 连接。建议：

优雅关闭：SIGTERM 时先停止接受新 Session，等待进行中工具完成，再卸载 Bundle。
健康检查：卸载后检查连接数、内存是否回落（见技能实验室泄漏调试）。
Code Review：见本文第十二节插件检查表。

3.3 Teardown 与 Session 的关系

Session Log 记录的是对话与工具调用事件，不替代插件 Teardown。即使 Session 已归档，泄漏的 MCP 连接仍占用进程资源。运维告警应同时看 Session 数 与 进程级连接数。

四、审批矩阵设计：从二元到分级

工具执行管道支持审批策略。生产级审批不是「全开」或「全关」，而是分级矩阵：按工具类型、路径前缀、命令模式、用户角色四维决策。

4.1 审批矩阵模板

工具 / 操作	风险等级	默认策略	生产 override	审计字段
`read_file` 沙箱内	低	自动通过	自动通过	path, session_id
`write_file` 沙箱内	中	首次确认	白名单路径自动	path, hash
`write_file` 沙箱外	高	拒绝	拒绝	—
`shell` 只读命令	中	模式匹配	allowlist regex	cmd
`shell` 写/网络	高	人工审批	双人或工单	cmd, approver
`spawn_agent`	高	人工审批	配额 + 审批	parent, child_profile
MCP 外部工具	中-高	按 server 分级	server 级策略	mcp_server, tool

4.2 设计原则

默认拒绝出站网络：仅 MCP 白名单 server 可访问外网。
命令 allowlist 优于 blocklist：rm -rf 类 blocklist 永远不全。
审批结果写入 Session Log：满足合规审计与 Replay 复盘。
与 Creator 隔离：Creator Profile 的审批矩阵应更严而非更松。

在安全与审批模拟器中预演矩阵变更，再推生产 Patch。

4.3 常见误区

误区：「内部系统不需要审批。」→ 模型幻觉可能构造危险工具参数，审批防的是模型而非用户。
误区：「审批通过一次就永久信任。」→ 应 Session 级或 time-boxed 授权，见 Session 策略。

五、沙箱边界：诚实声明而非营销话术

DSH 文件系统沙箱限制 Agent 工具的读写路径。生产文档与对用户承诺必须诚实声明边界：沙箱防的是误操作与模型越界，不是防恶意插件或已攻破的运行时。

5.1 沙箱能做什么、不能做什么

能力	沙箱内	沙箱外 / 需知
限制 read/write 路径	✅ 可配置根目录	符号链接、挂载绕过需额外加固
隔离多租户 Session	✅ 每 Session workspace	共享卷需 OS 级权限
阻止任意 shell	⚠️ 依赖工具注册与审批	Creator + shell 可突破
防恶意 npm 插件	❌ 非沙箱职责	供应链审查 + 镜像签名
防 API Key 泄露	❌ 需密钥管理	环境变量 + Vault

诚实声明示例（可放入对外 SLA 附录）：

本服务 Agent 文件操作默认限制在 /data/sessions/{id}/workspace。不包含对宿主机其他路径的强安全保证。Creator 模式与 shell 工具未启用。如需更高隔离级别，请联系开通独立容器实例。

5.2 生产沙箱加固清单

workspace 根目录按 Session ID 隔离，禁止 ../ 逃逸（路径规范化）
只读挂载系统配置与插件目录
禁止或严格审批 shell、git push、网络 fetch（非 MCP）
容器以非 root 运行，readOnlyRootFilesystem where possible
定期扫描 Session workspace 异常大文件或外传模式

详见开发指南 · 工具与安全。

六、Creator 隔离：高权限模式的生产禁令

Creator 预设提供更高权限的工具集，适合受控创作环境。生产默认应禁用 Creator，或仅在独立集群 + 网络隔离 + 人工监督下短期开启。

6.1 Creator 隔离架构

控制项	用户生产	Creator 隔离区
网络 egress	MCP 白名单	更严或完全离线
文件系统	Session workspace	专用卷，定期 wipe
审批	分级矩阵	全人工
日志保留	标准策略	延长 + 不可篡改存储
实例生命周期	长期	短生命周期 VM

6.2 误用 Creator 的事故模式

批量任务脚本挂载 Creator Bundle → 模型一次调用删除大量文件
「为了方便调试」在生产 Profile Patch 中启用 Creator 插件 → 权限持久化
Creator Session 与用户 Session 共用存储 → 横向数据泄露

规范：Creator 相关 Patch 文件命名必须含 creator，CI 禁止将该 Patch 部署到 production 命名空间。

七、Session Log 保留策略

Session Log 是 append-only 事件流，支撑 Resume、Fork、Replay 与审计。生产必须定义保留周期、归档格式、删除合规三要素。

7.1 分级保留建议

Session 类型	热存储	温归档	冷删除	备注
普通用户对话	30 天	180 天 S3/OSS	按合规	含 PII 需脱敏
Code 开发辅助	14 天	90 天	可更短	可能含代码片段
评测 Minimal	7 天	可选	30 天	无 PII 优先
Creator / 高敏	90 天	1-3 年	法务审批	WORM 存储

7.2 磁盘与性能

Compaction：历史事件段合并，保留 fork 指针
索引：按 session_id、user_id、created_at 建索引，避免全目录扫描
配额：单 Session 大小上限，超限触发压缩或拒绝新工具大 payload
监控：磁盘使用率 >80% 告警，>90% 自动归档最旧热数据

7.3 Fork 与合规

Fork 产生新 Session 分支，保留策略应继承源 Session 分类。Replay 用于事故复盘时，只读挂载归档，避免重放时再次执行写工具（Replay 沙箱模式）。

八、OpenTelemetry 指标：生产可观测性基线

DSH 可集成 OpenTelemetry 导出 trace 与 metrics。生产至少应采集以下信号，并接入现有 Prometheus / Grafana / Jaeger 栈。

8.1 推荐指标清单

指标名	类型	标签	用途
`dsh.session.active`	Gauge	profile, instance	活跃 Session 数
`dsh.tool.calls.total`	Counter	tool, result, profile	工具调用量与成功率
`dsh.tool.latency.ms`	Histogram	tool	工具延迟 P99
`dsh.model.tokens`	Counter	model, direction	Token 消耗
`dsh.model.latency.ms`	Histogram	model	模型 RTT
`dsh.approval.pending`	Gauge	—	待审批积压
`dsh.plugin.mount.errors`	Counter	plugin	插件挂载失败
`dsh.session.log.bytes`	Gauge	—	Log 体积

8.2 Trace 跨度设计

一次用户消息处理链建议 span：session.message → model.completion → tool.execute（可多个）→ context.compress。在 trace 中标注 profile、session_id（哈希）、tool_name，便于定位「哪类 Profile 工具失败率高」。

8.3 告警规则示例

rate(dsh.tool.calls.total{result="error"}[5m]) / rate(dsh.tool.calls.total[5m]) > 0.05 → 工具错误率超 5%
dsh.approval.pending > 100 持续 10m → 审批积压
dsh.session.log.bytes 增长率异常 → 可能 Log 膨胀攻击或压缩失效

九、上下文压缩策略

长 Session 中历史消息与工具输出累积导致 Token 成本上升与上下文窗口溢出。DSH 支持上下文压缩策略，生产需显式配置而非依赖模型默认。

9.1 压缩触发条件

策略	触发条件	行为	适用
水位线压缩	token > 70% 窗口	摘要早期轮次	Standard 对话
工具输出裁剪	单次 tool output > N KB	保留摘要 + 哈希	Code Profile
滑动窗口	保留最近 K 轮	丢弃更早	Minimal 评测
结构化归档	检测到 plan 完成	将 plan 存 Session 元数据	多 Agent

9.2 压缩质量保障

压缩后保留系统指令与最新用户目标不可摘要
工具失败的 stderr 保留完整片段便于调试
压缩事件写入 Session Log，支持 Replay 对比压缩前后行为
A/B：在 staging 对比「压缩 vs 不压缩」的任务完成率

9.3 Token 成本关联

压缩降低 input token，但摘要本身消耗 output token。监控 dsh.model.tokens 中 compression 前后差值，找到业务最优水位线（通常 60%-75% 窗口触发）。

十、多实例与多 Profile 部署

水平扩展 Harness 时，需解决 Session 亲和、配置一致性与 Profile 路由。

10.1 部署拓扑

模式	Session 存储	适用
粘性会话	本地卷 + IP hash	小规模
共享存储	NFS / S3 兼容 + 锁	中规模
Session 服务化	独立 Session API	大规模

10.2 配置一致

Bundle 版本通过镜像 tag 锁定，禁止实例间手工改 Patch
滚动升级：先升 Pool 中一个 canary，对比 OTel 错误率再全量
多 Region：Profile Patch 同步，Session 数据 residency 合规

10.3 多 Profile 路由

按 URL 路径、Header 或租户 ID 路由到不同 Pool。评测流量不得与用户流量共用 Pool，避免 Minimal 资源被挤占或配置串扰。

十一、密钥管理

API Key、MCP token、Webhook secret 不得进入 Session Log 或插件源码。

11.1 分层 secrets

秘密类型	存储	注入方式	轮换
模型 API Key	Vault / K8s Secret	启动时 env	90 天
MCP OAuth	Vault 动态凭据	插件 init	按 IdP
Session 加密密钥	KMS	侧车注入	年
OTel exporter token	Secret	env	按需

11.2 实践清单

.env 在 .gitignore，CI 用 sealed secrets
日志脱敏：拦截 Authorization header 打印
Creator 区禁止 printenv 类工具或严格审批
密钥轮换演练每季度一次，验证 Harness 热重载或滚动重启流程

十二、变更与回滚

Harness 生产变更包括：Bundle 升级、Profile Patch、审批矩阵、插件版本。回滚必须可重复、可审计。

12.1 变更流程

变更单：描述 Profile/Bundles diff、影响面、回滚命令
Staging 验证：自动化基准 + 人工抽检 Creator 未误开
Canary：单实例 10% 流量 30 分钟，盯 OTel
全量 / 回滚：Git tag 对应镜像，一键回滚上一 tag

12.2 Patch 版本化

# profiles/prod-standard/v3.patch.yaml
apiVersion: dsh/v1
profile: standard
version: "3.1.0"
changes:
  - approval: shell 策略收紧
  - tools: 移除 deprecated_mcp_v1
rollbackTo: "3.0.2"

Session Log 格式升级需向后兼容或提供迁移 job；不可兼容时必须维护双读期。

十三、Code Review 插件检查表

合并插件 PR 前，Reviewer 使用本检查表（可粘贴到 PR 模板）。

13.1 功能与安全

插件 name 唯一，无与 Bundle 内置冲突
所有 ctx.effect() 有 Teardown，并在 lab 泄漏调试中验证
工具 Schema 准确，无过度宽泛的 any 参数
文件/网络操作走沙箱与审批，无 bypass 捷径
不 log 密钥、PII、完整 session 内容
Creator 能力未混入 Standard 插件

13.2 性能与可靠性

MCP 连接有超时与重连上限
大 payload 流式或分块，避免 OOM
错误向 Agent 返回可行动消息，非裸 stack
依赖版本 pinned，无 latest

13.3 可观测

关键路径有 OTel span 或结构化 log
指标名符合 dsh.* 前缀规范

13.4 文档

README 说明 Profile 要求与 env 变量
变更日志条目
若发布社区，含 dsh-plugin topic 说明（见从零到一毕业作业）

十四、容量规划与 Token 成本控制

14.1 容量维度

维度	估算方法	扩容信号
并发 Session	峰值 QPS × 平均 Session 时长	CPU >70% 或排队
磁盘	日均 Session 数 × 平均 Log 大小 × 保留天	磁盘告警
模型 QPS	工具轮次 × 模型调用	429 率上升
内存	插件数 × MCP 连接 × 缓存	OOMKilled

14.2 Token 成本控制

Profile 级预算：Standard 单 Session 日 token 上限，超限降级 Minimal 或拒绝
模型路由：简单意图用小模型，复杂任务才调大模型
工具轮次上限：防止 Agent 循环调用工具
缓存：相同 system prompt、重复 MCP schema 缓存 embedding 若适用
账单分账：OTel label tenant_id 导出到成本报表

14.3 成本复盘会议议程（每月）

Top 10 高 token Session 抽样：是否压缩失效或工具输出过大
Profile 分布：Code 是否占用过高比例
评测 Minimal 是否误连生产模型 endpoint（贵）

十五、生产上线总清单

上线前逐项勾选：

十六、生产事故响应与 Harness 特有故障模式

16.1 故障分类

类别	典型现象	首要动作
插件挂载失败	实例启动 error loop	回滚 Bundle tag，查 `dsh.plugin.mount.errors`
工具风暴	Token spike、延迟飙升	降并发、临时收紧审批、查 Agent 循环
Session 存储满	写入失败	紧急归档、扩容、临时缩短保留期
MCP 上游不可用	工具大面积 timeout	熔断 MCP 插件、降级工具集
审批积压	用户任务卡住	扩容审批人力或临时 auto-deny 非关键写

16.2 Postmortem 模板

时间线：从 OTel trace 与 Session Log Replay 提取
根因：区分 Model 幻觉、工具 bug、Profile 配置、基础设施
Harness 改进：Patch 变更、审批矩阵、Teardown 修复
验证：Minimal 基准是否新增回归 case

16.3 与模型供应商故障的边界

模型 429/5xx 时，Harness 应熔断重试并给用户明确提示，而非无限 tool-model 循环。在 Profile Patch 中配置 model.maxRetries 与 model.fallback（若支持）。

十七、多租户与配额（生产扩展）

若一套 Harness 服务多租户，必须在 Profile 之上增加租户 Patch：

租户级工具白名单（禁止 A 租户调用 B 租户的 MCP server）
租户级 Session 命名空间与磁盘 quota
租户级 OTel label 用于成本与审计分账
Creator 能力按租户 feature flag，默认 off

常见误区：仅在前端区分租户，后端共用 Creator Profile —— 任何租户突破前端即全站沦陷。

十八、合规与数据驻留

PII 最小化：Session Log 不存 unnecessary 用户字段；导出前脱敏
删除权：用户请求删除时，热温冷三层 Session 均需 purge，含 Fork 子树
跨境：Session 存储 Region 与模型 API Region 策略一致，在 Profile 文档声明
审计：审批记录与工具写操作不可篡改；WORM 或 append-only 对象锁

十九、与 CI/CD 集成最佳实践

阶段	Harness 动作	门禁
PR	Minimal Profile 集成测试	插件 mount + 样例 tool call
Merge main	构建镜像 tag	CR 检查表
Staging	Standard Profile soak	OTel 对比 baseline
Prod canary	10% 流量	错误率
Prod full	滚动	Session 无中断

CI 中 Harness 应用 CONVEX_AGENT_MODE=anonymous 类隔离模式（若适用云 Agent）避免污染开发者本地 Session 存储 —— 参见团队 Agent 开发规范。

二十、Benchmark 与 SLO 定义

建议对生产 Standard Profile 定义 SLO：

SLO	目标	测量
消息端到端延迟 P95	< 15s（无长工具）	trace
工具调用成功率	> 99%	metrics
Session 可 Resume 成功率	> 99.9%	合成探测
计划外 Creator 暴露	0	配置 drift 检测

每月用 Minimal 基准任务集回归，确保 Bundle 升级未退化工具轮次与完成质量。

二十一、Profile Patch 编写规范详解

生产 Patch 文件必须可读、可 diff、可回滚。推荐结构：

metadata:
  name: prod-standard
  version: "4.2.1"
  owner: platform-team
  reviewed: "2026-03-01"
spec:
  bundle: standard@2.0.0
  tools:
    include: [read_file, write_file, search_repo]
    exclude: [creator_shell]
  approval:
    inherit: base-standard
    overrides:
      - match: { tool: write_file, pathOutsideSandbox: true }
        action: deny
  compression:
    triggerRatio: 0.72
    strategy: summarization
  observability:
    otel:
      serviceName: dsh-prod-standard

字段说明：bundle 锁定主版本，避免 minor 自动漂移。tools.exclude 显式优于依赖默认。approval.overrides 按 match specificity 从高到低排序。compression.triggerRatio 需与模型窗口联合调优。

Review Patch 时问：若新同事仅读 Patch 能否理解生产权限边界？若不能，补注释与链接到审批矩阵文档。

二十二、Teardown 代码审查实例（正反例）

反例：注册全局 process.on('uncaughtException') 无 Teardown → 卸载插件后仍劫持进程。

正例：在 effect 内注册并在 Teardown 移除；或使用 Cordis 提供的 scoped lifecycle API（以仓库最新文档为准）。

反例：MCP client 懒连接，首次 tool call 才 connect，Teardown 在 mount 时执行 → client 泄漏。

正例：connect 与 close 对称；或使用 weak ref 表在 Teardown 统一关闭。

团队在技能实验室建立「挂载 fifty 次循环」自动化测试，内存曲线应平坦。

二十三、审批矩阵版本演进案例

假设 v1 矩阵对 write_file 沙箱内自动通过。事故：模型生成路径 workspace/../../etc/passwd 若规范化不足可能越界。v2 增加路径规范化 middleware + 仍自动通过。v3 对首次 write 每 Session 弹一次确认。v4 对 >1MB 文件 write 人工审批。

每次演进在 Session Log 标记 policy_version，Replay 旧 Session 时用当时版本策略（可选）或现策略（调试）需文档说明。

二十四、Session Log 存储格式与归档流水线

热存储：本地 SSD 或低延迟块存储，支持随机 append。温存储：按日打包 gzip JSONL 上传对象存储，保留索引 manifest。冷删除：lifecycle policy 自动删除超过 retention 的对象。

归档 job 必须幂等：重复运行不产生 duplicate 段。Fork 指针在 manifest 中维护，避免归档后无法 Resume。

监控：archive.job.duration、archive.job.failures、hot.storage.bytes。

二十五、OpenTelemetry 与现有栈集成步骤

部署 OTel Collector，配置 receiver OTLP gRPC/HTTP。
Harness Patch 注入 OTEL_EXPORTER_OTLP_ENDPOINT 与 OTEL_SERVICE_NAME。
Collector exporter 指向 Prometheus + Jaeger。
Grafana 导入 DSH 仪表盘模板（社区或自建）。
告警规则接入 PagerDuty / 飞书。

注意采样率：生产 trace 可 head sample 10%，但 tool error span 100% 保留。成本与可观测平衡。

二十六、上下文压缩算法选型讨论

在生产环境中，上下文压缩算法选型讨论是 Harness 运维经常面对的主题。以下从原理、配置与实践三方面展开，并与开发指南中的架构描述保持一致。

原理：Harness 作为 Agent 运行时，任何配置变更都会影响 Cordis 插件图谱与 Session 行为。运维团队应把变更视为对「执行面」的修改，而非简单的环境变量调整。

配置：通过 Profile Patch 显式声明策略，避免依赖隐式默认。所有默认值应在 staging 与 production 文档中有对照表。

实践：在七天学会子站实验室验证相关行为，再推生产。每次推生产前运行 Minimal 基准，确保核心 tool call 路径未回归。

常见误区：认为「staging 测过就等于生产安全」而忽略数据规模、并发与 Session 历史长度差异。生产环境的长 Session、大工具输出、多 MCP 连接会放大 staging 未覆盖的问题。

检查项：(1) Patch 已版本化；(2) OTel 能反映变更前后差异；(3) 回滚 tag 可用；(4) on-call runbook 已更新；(5) 用户可见 changelog 若涉及行为变化。

下表汇总该主题下的推荐责任分工：

角色	职责
平台工程	Patch 维护、实例部署
安全	审批矩阵、Creator 隔离审计
SRE	OTel、容量、事故响应
应用团队	插件 CR、业务工具 Schema

二十七、多实例 Session 锁机制

在生产环境中，多实例 Session 锁机制是 Harness 运维经常面对的主题。以下从原理、配置与实践三方面展开，并与开发指南中的架构描述保持一致。

下表汇总该主题下的推荐责任分工：

二十八、密钥轮换零停机实践

在生产环境中，密钥轮换零停机实践是 Harness 运维经常面对的主题。以下从原理、配置与实践三方面展开，并与开发指南中的架构描述保持一致。

下表汇总该主题下的推荐责任分工：

二十九、插件供应链安全

在生产环境中，插件供应链安全是 Harness 运维经常面对的主题。以下从原理、配置与实践三方面展开，并与开发指南中的架构描述保持一致。

下表汇总该主题下的推荐责任分工：

三十、Token 预算告警与降级用户体验

在生产环境中，Token 预算告警与降级用户体验是 Harness 运维经常面对的主题。以下从原理、配置与实践三方面展开，并与开发指南中的架构描述保持一致。

下表汇总该主题下的推荐责任分工：

生产深化：把清单变成可执行机制

P1. 变更窗口的可观测性协议

变更开始前记录基线：每分钟 tool calls、token、审批 ask 率、MCP up。变更后 30 分钟内这些曲线应可对比。若只看 CPU，你会错过「deny 变多导致任务假成功」。

P2. 审批矩阵的演进方式

从「全 ask」起步会不可用；从「全 auto」起步会出事。推荐：只读 auto → 工作区写 ask → 工作区外与密钥路径 deny → 网络默认 deny 白名单。每次放宽必须有 Incident 回顾或明确收益证明。

P3. Session 保留与法务

定义热/温/冷存储：热用于 Resume；温用于审计查询；冷加密归档。删除权（用户请求删除）与审计留存冲突时，走法务例外流程，而不是工程师口头决定。

P4. 多租户隔离检查

租户 A 的 Patch 不得影响租户 B 的 Host 单例状态。测试：交替高压会话，检查工具注册表与沙箱 workdir 是否串扰。

P5. Token 成本治理

预算按 Profile 分配；对超长 Session 强制 compaction；对工具输出做截断与外置存储（日志存对象存储，模型只看摘要）。成本异常告警应能下钻到 tool name。

P6. 供应链

锁文件、镜像扫描、插件签名或 checksum、禁止生产 npx latest。Bundle pin 是供应链策略的一部分，不是口味问题。

P7. Creator 专区

独立集群、无共享卷、短 TTL、强审计、默认无公网。教学可在子站模拟，生产必须物理/虚拟隔离。

P8. 回滚演练

每季度一次：把 Bundle 回退一版，验证 Session Replay 套件与 MCP 兼容。没演练过的回滚按钮等于装饰。

P9. 插件 Code Review 强制问题

每个副作用是否 effect 化？
inject 是否完整？
是否引入模型可控的 URL/路径？
卸载后集成测试是否通过？
是否更新兼容矩阵？

P10. SLO 示例

指标	目标
会话启动成功率	≥ 99%
审批等待 P95（不含人工思考）	系统侧 < 2s 展示
工具执行错误率	分类告警
Effect 泄漏检测	零容忍进生产

一、生产级 Harness 运行时全景​

二、Profile 分离：评测 Minimal vs 生产 Standard​

2.1 为什么要分离 Profile​

2.2 Minimal 评测 Profile 设计要点​

2.3 生产 Standard Profile 设计要点​

2.4 Code Profile 的边界​

2.5 常见误区​

三、Teardown 纪律：可逆副作用的生产契约​

3.1 Teardown 检查清单​

3.2 热重载与滚动升级​

3.3 Teardown 与 Session 的关系​

四、审批矩阵设计：从二元到分级​

4.1 审批矩阵模板​

4.2 设计原则​

4.3 常见误区​

五、沙箱边界：诚实声明而非营销话术​

5.1 沙箱能做什么、不能做什么​

5.2 生产沙箱加固清单​

六、Creator 隔离：高权限模式的生产禁令​

6.1 Creator 隔离架构​

6.2 误用 Creator 的事故模式​

七、Session Log 保留策略​

7.1 分级保留建议​

7.2 磁盘与性能​

7.3 Fork 与合规​

八、OpenTelemetry 指标：生产可观测性基线​

8.1 推荐指标清单​

8.2 Trace 跨度设计​

8.3 告警规则示例​

九、上下文压缩策略​

9.1 压缩触发条件​

9.2 压缩质量保障​

9.3 Token 成本关联​

十、多实例与多 Profile 部署​

10.1 部署拓扑​

10.2 配置一致​

10.3 多 Profile 路由​

十一、密钥管理​

11.1 分层 secrets​

11.2 实践清单​

十二、变更与回滚​

12.1 变更流程​

12.2 Patch 版本化​

十三、Code Review 插件检查表​

13.1 功能与安全​

13.2 性能与可靠性​

13.3 可观测​

13.4 文档​

十四、容量规划与 Token 成本控制​

14.1 容量维度​

14.2 Token 成本控制​

14.3 成本复盘会议议程（每月）​

十五、生产上线总清单​

延伸阅读​

十六、生产事故响应与 Harness 特有故障模式​

16.1 故障分类​

16.2 Postmortem 模板​

16.3 与模型供应商故障的边界​

十七、多租户与配额（生产扩展）​

十八、合规与数据驻留​

十九、与 CI/CD 集成最佳实践​

二十、Benchmark 与 SLO 定义​

二十一、Profile Patch 编写规范详解​

二十二、Teardown 代码审查实例（正反例）​

二十三、审批矩阵版本演进案例​

二十四、Session Log 存储格式与归档流水线​

二十五、OpenTelemetry 与现有栈集成步骤​

二十六、上下文压缩算法选型讨论​

二十七、多实例 Session 锁机制​

二十八、密钥轮换零停机实践​

二十九、插件供应链安全​

三十、Token 预算告警与降级用户体验​

生产深化：把清单变成可执行机制​

P1. 变更窗口的可观测性协议​

P2. 审批矩阵的演进方式​

P3. Session 保留与法务​

P4. 多租户隔离检查​

P5. Token 成本治理​

P6. 供应链​

P7. Creator 专区​

一、生产级 Harness 运行时全景

二、Profile 分离：评测 Minimal vs 生产 Standard

2.1 为什么要分离 Profile

2.2 Minimal 评测 Profile 设计要点

2.3 生产 Standard Profile 设计要点

2.4 Code Profile 的边界

2.5 常见误区

三、Teardown 纪律：可逆副作用的生产契约

3.1 Teardown 检查清单

3.2 热重载与滚动升级

3.3 Teardown 与 Session 的关系

四、审批矩阵设计：从二元到分级

4.1 审批矩阵模板

4.2 设计原则

4.3 常见误区

五、沙箱边界：诚实声明而非营销话术

5.1 沙箱能做什么、不能做什么

5.2 生产沙箱加固清单

六、Creator 隔离：高权限模式的生产禁令

6.1 Creator 隔离架构

6.2 误用 Creator 的事故模式

七、Session Log 保留策略

7.1 分级保留建议

7.2 磁盘与性能

7.3 Fork 与合规

八、OpenTelemetry 指标：生产可观测性基线

8.1 推荐指标清单

8.2 Trace 跨度设计

8.3 告警规则示例

九、上下文压缩策略

9.1 压缩触发条件

9.2 压缩质量保障

9.3 Token 成本关联

十、多实例与多 Profile 部署

10.1 部署拓扑

10.2 配置一致

10.3 多 Profile 路由

十一、密钥管理

11.1 分层 secrets

11.2 实践清单

十二、变更与回滚

12.1 变更流程

12.2 Patch 版本化

十三、Code Review 插件检查表

13.1 功能与安全

13.2 性能与可靠性

13.3 可观测

13.4 文档

十四、容量规划与 Token 成本控制

14.1 容量维度

14.2 Token 成本控制

14.3 成本复盘会议议程（每月）

十五、生产上线总清单

延伸阅读

十六、生产事故响应与 Harness 特有故障模式

16.1 故障分类

16.2 Postmortem 模板

16.3 与模型供应商故障的边界

十七、多租户与配额（生产扩展）

十八、合规与数据驻留

十九、与 CI/CD 集成最佳实践

二十、Benchmark 与 SLO 定义

二十一、Profile Patch 编写规范详解

二十二、Teardown 代码审查实例（正反例）

二十三、审批矩阵版本演进案例

二十四、Session Log 存储格式与归档流水线

二十五、OpenTelemetry 与现有栈集成步骤

二十六、上下文压缩算法选型讨论

二十七、多实例 Session 锁机制

二十八、密钥轮换零停机实践

二十九、插件供应链安全

三十、Token 预算告警与降级用户体验

生产深化：把清单变成可执行机制

P1. 变更窗口的可观测性协议

P2. 审批矩阵的演进方式

P3. Session 保留与法务

P4. 多租户隔离检查

P5. Token 成本治理

P6. 供应链

P7. Creator 专区