企业级 AI 架构 · 番外：生产化深度（能跑，不等于能上线）

企业级 AI 架构 · 番外：生产化深度（能跑，不等于能上线）

系列第二篇番外。"Pi 和 DSH 都是单用户本地，Admin / OneID / 审计 / 信创那一层要自己补"；评测生产化番外把"评测"推进了生产。这一篇补上四短板最后一块，生产化深度，把"企业级"拆成可用性 / 韧性 / 审计 / 数据治理四根支柱，并用 harness-demo 诚实对照"开源单 Agent 工程到生产还差多远"。

呼应 00 总览的中央论点：可用性、韧性、审计、数据治理这四根支柱，没有一根是模型自己能给的——它们全是"控制平面"在企业级的展开，也正是开源单 Agent 工程最需要自行补齐之处。

---

开篇：能跑 ≠ 能上线

评测生产化那篇末尾我们说：15 命中只能证明规则引擎没错，证明不了"质量退步时有人拦"。这一篇再升一档——就算你的 Agent 逻辑全对、评测全绿，把它从"我本地跑通一次"推到"生产环境 7×24 扛故障"，中间还隔着一整层东西。

这层东西，"Pi 和 DSH 都是单用户本地，Admin / OneID / 审计 / 信创那一层要自己补。"本篇不重复那句结论，而是把它拆开，可用性、韧性、审计、数据治理，每根支柱，我们都用 harness-demo 诚实对照：它做到了哪一步，又明确没做哪一步。因为开源单 Agent 工程的尽头，从来不是"能跑"，而是"能扛"。

---

图：从 demo 到上线的四件事——CI 门禁 / 监控观测 / 回滚预案 / 容量压测。

一、WorkBuddy 的权威主张：生产化的四根支柱

把 WorkBuddy Enterprise 的 Admin 拆成六模块：运行观测（调用链路 Trace / 性能 / 质量）、评估测评（量化 Agent 能力）、AI 资产管理（智能体 / 模型 / Skills / 知识库）、成本用量（Credits 统一度量）、组织权限（OneID 统一登录）、安全审计（全程留痕）。再往下还有一套运行时概念：Runtime（独立云端沙箱 + 完整 Linux 环境）、Session（独立上下文，超时自动休眠）、Checkpoint / 版本追溯（崩溃后从检查点续上、版本可回溯）、凭据管理（加密存储 + 代理层注入，不落沙箱）。硬指标是隔离容器 100ms 冷启动、7×24 长周期异步 Session。

把这套翻译成"生产化"的通用语言，就是四根支柱：

1. 可用性（Availability）：服务得一直在线——多副本、健康检查、故障自动转移；
2. 韧性（Resilience）：出错了别雪崩——超时 / 重试 / 熔断 / 降级，且崩溃后能恢复；
3. 审计（Auditability）：谁、何时、用哪条数据、调了什么，全程可回溯、可举证；
4. 数据治理（Data Governance）：租户隔离、留存策略、脱敏、合规（PII / 跨境 / 信创 / 等保）。

视角提醒（详见 00 总览 §六）：WorkBuddy 是单一厂商，以上请当作方法论之尺，而非跨厂商标准答案；落地请以你自家的多源验证为准。另，WB 生产化的结构能力（Admin 六模块、Harness 五层、WMA 托管 + 100ms 冷启动 + 7×24 异步 Session、凭据平台托管注入）已有公开官方文档佐证；文中凡涉及更深处（具体 SLA、审计落库格式、租户隔离实现细节），公开资料有限，以 Enterprise 最新官方文档核对为准。

---

二、可用性 & 韧性：从"本地单进程"到"托管多副本"

先看"扛故障"三方差在哪。

Pi：能恢复，但单点。 它的 session 是 ~/.pi/ 下的 JSONL 事件流（user / assistant / tool / compaction 四类 entry），崩了靠 session 文件 + compaction 摘要把进度捞回来。但这只是"单机进程内的可恢复"——没有多副本、没有健康检查、没有自动故障转移。harness-demo 的 README 自己写明：包内 Pi / DSH 均为"单用户本地形态"。一次进程被杀，恢复的是你那一个会话，不是服务的可用性。

DSH：能重放，同样单点。 它把"完整记录"做成运行时不变量"模型可见即已记录"，所有上下文注入落进同一条 append-only log，支持 resume / fork 重放，还有配套的回放 / 检查视图（以你使用当日为准）逐帧回看。这比 Pi 更"架构化"——新增一项模型能看到的输入，就必须新增一个会话事件，没有后门。但 developer preview 仍是你装在本机跑的单 runtime，没有托管冗余。

WB：生产级韧性（待核验细节）。 WMA 托管 7×24 + 100ms 冷启动 + Checkpoint / 版本追溯，意味着崩溃后能从检查点续上、版本可回溯——这是"平台级"的可用性，不是"进程级"的。

把三方的差距落成一份韧性清单，你就能照着自查：

• 超时：每个工具调用有没有上限？Pi / DSH 默认靠模型/运行时，demo 未显式设；
• 重试：失败有没有指数退避？demo 的 reviewClause 是纯函数、无网络，无所谓；但凡是调 LLM / 外部 API 的，必须有；
• 熔断：下游持续失败时，有没有降级而非疯狂重试？demo 未含；
• 降级：LLM 挂了，能不能退到规则引擎硬判（恰好是 04 篇"计算型优先"的范本）？engine.js 这层纯函数就是天然的降级底座——这反而是 demo 做对的一点；
• 崩溃可恢复：session 不丢。Pi 的 JSONL、DSH 的 append-only 都做到了；
• 幂等：同一条请求重发，会不会双扣费 / 双写？demo 未涉及。

一句话：开源 Harness 给你崩溃可恢复的地基，但跨节点恢复 + 弹性伸缩这栋楼，它明确不盖（呼应 Octo / Avernet 治理层）。

事件驱动的主动服务：上面讲的「韧性」还偏「被动扛故障」。书以 OpenClaw 的 Hooks / Cron / Heartbeat / Channel 说明事件驱动机制，并指出「真正的主动服务不仅需要定时检查，更需要事件主动通知 Agent」。落到企业级，建议把「轮询式可用性」升级为「事件驱动的韧性架构」——Agent 不被定时轮询驱动，而由事件（新工单、新邮件、状态变更）主动唤醒——这是可用性 / 韧性之上更进一步的架构议题；本系列侧重调度侧，此处仅作边界提示。

Computer Use 与机器人操作：GUI 自动化（Computer Use）、VLA、机器人操作，这些属模型 / 设备能力边界议题，超出本系列「企业级 AI 架构（调度、护栏、治理）」的范畴，此处仅作边界提示，不展开。

附：把 04 的「计算型控制优先」落成可跑范式

04 反复强调"权限/控制在模型外执行、计算型控制优先"。在harness-demo 里，我们把它从原则变成了代码。

给纯函数引擎 reviewClause 套一层 composeReview([piiRedact, audit]) 中间件链——PII 脱敏、审计每一项都是确定性函数，挂在引擎之外、彻底走在 LLM 之外（代码见 pi/skills/contract-review/rules/middleware.js，编排见 review.js）。humanReviewGate（命中一条 MUST/HIGH 红线 或 命中数超阈值 → 触发人工复核门）已真正接入 Pi 与 DSH 两个适配器的执行路径，护栏不再是提示词里的"请不要"，而是会被实际计算的布尔。

更进一步，把"护栏"写成代码：humanReviewGate = anyOf(maxRisk("MUST"), hitCountAtLeast(3))——阈值取 3（低于单条款最大命中数上限，否则计数门成死分支），表达"多条非 MUST 风险累积也应升级人工复核"。这正是对 04 核心"先算，再判"的运行态落地，也是本篇前文"降级退到规则引擎硬判"的同一套思想。

---

三、审计：取证链落到哪

"可观测"和"可审计"差一个字，差一层责任。可观测是"我自己能翻记录"，可审计是"出了事能向监管 / 客户 / 法庭举证，且记录改不了"。

Pi：本地 session 即审计日志。 05 篇讲过，那棵 JSONL 树就是它的"审计素材"——可读、可回放、可迁移。但它是落你本地的普通文件：无集中留存、无防篡改（任何人能改 ~/.pi/ 下的内容）、无"这是谁的操作"身份标注。对单人也够用，对企业级不够。

DSH：本地 append-only + 回放视图。 同样本地、同样无集中审计库；回放视图（以当日 UI 为准）解决的是"开发者逐帧回看"，不是"组织级合规取证"。

WB：企业级全程留痕（待核验机制）。 Admin 的「安全审计」格写的是"全程留痕"——配合 OneID，意味着操作能归因到具体人、跨会话可回溯、且（理论上）不可随意篡改。这是 demo 两级都缺的"身份 + 集中 + 防篡改"三件套。

harness-demo 的诚实缺口就在这：它的审计只进本地 session，没有 OneID 身份、没有跨会话归因、没有 tamper-proof。合同审查这种敏感场景，一旦结果被质疑，"谁在什么时候审的、用的哪版规则"答不上来，就是合规硬伤。

---

四、数据治理：租户隔离、留存、脱敏、合规

这是开源 demo 最容易翻车、也最该提前想的一块。

租户隔离。 Pi / DSH 都没有多租户——README 明写缺 OneID / 审计 / 信创。多用户共用一份本地状态，等于数据可能串户。企业里 A 客户的合同被 B 客户的会话读到，是事故。

留存策略。 session / log 留多久？谁有权删？满了怎么办？开源侧没默认。合同类数据往往有法定留存期，不能"想删就删"，也不能"永远不删"。

脱敏。 合同里全是 PII——主体名称、金额、签署人、甚至身份证号。demo 把原文全量落进 session 与规则引擎，落库前没有任何脱敏一层。这恰好呼应 04 篇"权限在模型外执行"——但 04 讲的是"调用权限"，没讲"数据落盘前的脱敏"，而后者是企业级必须的。

另一类常被忽视的落盘风险是明文凭证：本地配置（如 settings.json / models.json）以明文存令牌与密钥，备份时若按普通文件处理就会泄露。所以企业级数据治理应是双线——落盘前脱敏（护 PII）+ 凭证库级保护（护 key），两条都不能少。

合规。 跨境传输（呼应 nda 规则里的"跨境传输合规"那条）、信创适配（麒麟 / 统信、达梦 / 人大金仓、鲲鹏 / 飞腾）、等保三级 / 四级——WB 一体机已覆盖，开源侧要自建。

harness-demo 的 DSH 部分已经示范了扩展点在哪里。make-patch.mjs 生成的 cordis.patch.yml 就是往运行时插工具的钩子——工具插入行用本机绝对路径指向插件入口：

# harness-demo/dsh/contract-review/make-patch.mjs 生成的 patch 形态
- insert:
  - id: contract-review-tool
    name: '/abs/path/to/dsh/contract-review/index.js'
# ── 以下为对照示意模板（需用 dump-config 查得真实行 id 替换）──
# - patch:
#   - id: '<session 行 id>'     # 01/08 上下文：compaction 权衡
#     config: { contextPolicy: { compaction: true, reserveTokens: 16384 } }
# - patch:
#   - id: '<sandbox 行 id>'     # 04 安全：沙箱三档
#     config: { level: 'medium' }

这机制本身就是"注入治理工具"的天然位置：你完全可以照 contract-review-tool 的写法，再插一个 redact-tool（落盘前脱敏）或一个 audit-tool（每次调用写一条带 OneID 的审计事件）。也就是说，开源 Harness 把"插治理"的能力给了你，但"治理规则本身"要你自己写，这正应了 09 那句"地基之上还有一栋叫平台治理的楼要盖"。

顺带一个供应链视角的提醒：第三方插件 / 技能往往以规则文件常驻在每次请求里，装之前要读它的规则与技能文件、来源从严，否则一个"好心"插件可能在每次会话里悄悄改写 Agent 的行为边界（这和风险即代码的思路同源：装前审计，胜过事后追责）。

---

图：内部 → 金丝雀 → 全量，回滚闸（任一红即回退）是生产化及格线。

图：四支柱 × L1 入门 / L2 可演示 / L3 生产级——起步建议先升可用性 + 审计。

五、把"生产化深度"变成检查清单 + 三方对照 + 收官

把四根支柱落成一张可照着自查的清单：

支柱	关键自查项
可用性	跨节点恢复？健康检查？滚动发布？长周期会话超时 / 休眠策略？
韧性	超时 / 重试 / 熔断 / 降级？崩溃可恢复？幂等？
审计	有身份（OneID）？操作留痕？防篡改？可跨会话回溯？
数据治理	租户隔离？留存策略？落盘前脱敏？合规（信创 / 等保）？

三方并排，差距一目了然：

维度	WorkBuddy Enterprise	Pi（harness-demo）	DSH（dev preview 示范）
可用性	WMA 托管 7×24 + 多副本	单进程，无	单 runtime，无
韧性	Checkpoint 版本追溯 + 100ms 冷启动	session 文件恢复	append-only 重放
审计	安全审计全程留痕（企业级）	本地 session.jsonl	本地 append-only + 回放视图（以当日 UI 为准）
数据治理	OneID + 信创 + 等保	无租户 / 无脱敏	无租户 / 无脱敏
扩展点	Admin 平台	AGENTS / 容器	cordis.patch.yml

速记一句话：生产化深度的本质，是把"我本地能跑"升级为"它在生产里能扛、能举证、能合规"。WorkBuddy 用 Admin + 托管运行时把它产品化，Pi 用 JSONL 留痕给地基，DSH 用运行时不变量 + patch 钩子给地基和扩展点，但多副本、OneID、集中防篡改审计、租户隔离与脱敏，这栋楼开源侧不替你盖（用 Octo / Avernet 或 Enterprise 补）。

至此，系列四短板，单一厂商透镜（00 总览 §六）/ FinOps（09 企业级落地 §二）/ 评测生产化（番外）/ 生产化深度（本篇），全部补齐，与 00–09 共同构成一份完整的"企业级 AI 架构素养框架"。剩下的，是把这份框架，连同 harness-demo，真正落进你自己的生产。

---

相关阅读（系列互链）

本篇是【企业级 AI 架构】技术深轨，与公众号《AI思想的东方注脚》哲学引子、本体智能 / FDE 系列同源联动——同一观点不重复讲，按兴趣深潜：

• 《安全与权限边界：持有 API Key 的是 Agent，不是模型》（企业级 AI 架构·篇4）——能跑 ≠ 能上线，第一道坎就是权限
• 《范式革命还是又一个热词？本体智能的未来十年》（本体智能·篇8）——生产化之后，往哪走

---

生产化 #可用性 #审计 #企业级AI

关注公众号「农夫三拳有点癫」，第一时间读到本系列更新。