人机共治 (Human-in-the-Loop)¶
OLAV 建立在一个明确的设计原则上：LLM agent 不替代工程师，而是放大工程师。人始终在回路里、拥有决策权、为每个有后果的动作签字。Agent 是工具，不是替代品。
本页解释为什么这点重要、平台哪里体现了它、它如何塑造了 OLAV 暴露的每一个接口。
原则¶
工程师决策。Agent 辅助。
OLAV 的每条工作流都围绕三个角色展开：
| 角色 | 做什么 | 权限 |
|---|---|---|
| Sim agent | 从 intent + 结构化上下文起草变更（TCF、计划、查询） | 无 — 输出是提案 |
| Lab agent | 用规则、vendor parser、数字孪生验证草稿 | 无 — 输出是证据 |
| 工程师（你） | 读 sim 的草稿、看 lab 的证据、决定改什么、何时部署 | 唯一决策者 |
OLAV 的契约：没有任何 agent 在没拿到工程师同意时执行有后果的操作。草稿、findings、lab 结果——这些都是工程师阅读的产物。部署、批准、升级——这些是工程师做出的决策。
为什么 LLM 不能替代工程师¶
三条原因，今天成立、可预见的未来仍成立：
1. LLM 看不到工程师默认带的上下文¶
每个生产环境都有未明说的 baseline 假设："我们所有路由器都已配置 AS 号"、"接口 IP 在 baseline 模板里设置好了"、"这个客户有特定的 export-policy 约定"。LLM 不知道这些今天对你的设备群是不是真。工程师知道。
2. 责任落在人头上，不是模型上¶
如果一个变更在凌晨 3 点搞掉一个数据中心，事后总结会问"谁批准的？"——这个答案不能是"一个 70B 参数模型说 yes"。合规框架（SOC 2、ISO 27001、PCI）、变更审查会、监管环境都要求一个有名有姓的人为决策负责。OLAV 是为这个现实建的，不是为反对它建的。
3. LLM 的置信度没有校准¶
LLM agent 不管对错都用同样自信的语气输出文本。工程师能读一条 finding 然后判断"这是真问题还是模型在瞎编？"。一个信任 LLM verdict 的自动循环会跳过这个判断——也跳过工程师带来的真正价值。
OLAV 的设计结论：不要建自动循环。把产物建好、清晰暴露、让工程师驾驶。
"共治"在实践中是什么样¶
一个典型例子是 netops 变更计划流程 —— analyzer 起草计划，工程师批准后才实施 —— 但同样的模式贯穿整个 OLAV：
模式：共享产物 + 按需 agent¶
OLAV 定义一份共享、持久化的产物（TCF spec、审计报告、runbook），每个 agent 都是工程师按需 invoke 来变更或注释这份产物。
工程师让 sim → sim 在产物里写草稿
工程师读产物
工程师让 lab → lab 在产物里加 findings + 证据
工程师读产物
工程师决策:
• 直接改产物
• 让 sim 做定向修订
• 让 lab 重新验证
• 批准并继续
没有 cab_iterate(spec, max_iter=3) 这种 composite。没有收敛检测器。没有"agent 决定何时停"。每一步都是一次工程师触发的 call，工程师读完结果再决定下一步。
模式：建议性，不是强制性¶
当一条 lab finding 说"Junos eBGP 需要 set routing-options autonomous-system <N>"时，那是建议性的。Lab 不会阻塞流程。它把 finding 写在证据旁边，让工程师决定：
- "好，修" → 让 sim 加这行。
- "不，我们环境里这是 baseline 假设" → 接受并继续。Finding 留在产物里作为审计记录。
- "我想想" → 不动；finding 下次还在那里耐心等着。
工程师永远不会被 finding 的 severity 强迫行动。severity=blocker 是个强信号，不是可执行指令。
模式：能确定性就不用 LLM¶
OLAV 只在需要模糊推理的地方用 LLM（意图提取、文本解释）。底层逻辑是规则形态的——协议检查表、schema 强制、IP 分配、命令翻译——OLAV 用确定性 Python 替代。这让 agent 的行为可预测、可审计。
在 CAB 工作流里，prod-CLI 审查是基于正则的规则匹配，不是 LLM 调用。把 prod 命令映射到 lab 命令的翻译器是确定性的。只有最初的草稿生成涉及 LLM 判断，而这个草稿在任何动作之前都先由工程师读一遍。
这给你换来什么¶
可预测的行为¶
因为 agent 是工具不是自主行动者，你能推理每次调用会做什么、不会做什么。OLAV 里没有"agent 失控乱跑"这种 failure mode——只有"工程师让 agent 做 X，agent 做了 X"。
满足合规的审计链路¶
每个产物都追踪 revision_count、last_revised_at、last_revised_by。每次 lab run 写一份带时间戳的 journal。每个 operator 决策都是离散事件。CAB 审批人、审计员、事后总结读这条链路就能精确还原发生了什么。
安全推到生产¶
采用 OLAV 的团队不需要先"信任 AI"才让它碰真实基础设施。他们用 OLAV 就像用任何工具：坐在椅子上的工程师还是那个本来就要手动敲命令的人，只是因为 agent 在起草和验证而变快了。
这要你付出什么¶
OLAV 不是"自动部署的 ChatOps"。如果你的目标是"AI 运营网络无人监管"，OLAV 是错的选择。平台刻意不会走那条路。
权衡是：
| 你得到 | 你放弃 |
|---|---|
| 可预测、可审计的 agent 行为 | "设置好就不用管"的自治 |
| 合规友好的责任归属 | "100% AI 驱动"的漂亮营销话术 |
| 通过透明换来工程师的信任 | 不审就秒部署 |
| 有用的草稿和验证 | LLM 能接管的幻想 |
对于大多数在真实变更管理下运营真实基础设施的团队，这是对的权衡。对于偏好赌博的团队，OLAV 不是合适的平台。
参见¶
- NetOps Analyzer — HITL 的端到端典型例子：analyzer 起草变更计划（每台设备 CLI + 回滚 + 事后检查 + 风险），工程师审查，任何实施步骤都在明确批准后才进行。
- 安全模型 — OLAV 如何在权限层强制"没有工程师 go-ahead 就没有有后果操作"的契约。
- 自我改进循环 — agent 如何在不破坏 HITL 原则的前提下从历史使用中学习（memory 是建议性的，永不替代决策）。