智能体运维手册：监督不可见的系统

运维自主 AI 智能体是一门全新的学科——既非工程，也非管理，亦非传统运维，而是三者兼备的混合体。 当智能体运行时间足够长，监督而非代码生成成为瓶颈时，运维者的角色便应运而生。五项职责定义了这一角色，一套监督体系将其落地实施，一个干预框架决定何时采取行动。

没有人接受过这份工作的培训。没有大学院系教授这门课程。没有职位描述能精准概括它。上个月你还在写Python，下个月你就要管理一个自主系统——它自己写Python、调用API、修改你的文件系统，还在你睡觉时做出架构决策。Ralph 循环在我的基础设施中催生了这个角色：一个 shell 脚本重启Claude Code并注入新上下文，读取文件系统状态，在多个夜间会话间延续工作。每个自主运行智能体的团队都独立发现了同一角色，因为只要智能体运行时间超过单次交互会话，相同的问题就会浮现。

这个角色还没有公认的名称。有些团队称之为”AI 运维”，有些将其归入平台工程，还有一些把它交给从未写过 hook 的工程经理。这种模糊性不容忽视，因为错误识别角色会导致错误分配工作。缺乏系统知识的工程经理无法调试损坏的智能体状态；缺乏产品判断力的平台工程师无法评估智能体的输出是否符合需求规格的意图。运维者角色需要兼具两种能力：规格决策（智能体应该构建什么、施加什么约束）和执行运维（监控会话、从故障中恢复、维护基础设施）。

运维者的五项职责

1. 委派

委派是指在执行开始前编写约束智能体行为的规格说明。委派的质量比任何其他因素都更能决定自主输出的质量。

CLAUDE.md 文件就是一种委派产物。它将项目约定、禁止模式、必需行为和质量标准编码到智能体在会话开始时读取的文档中。¹ PRD也是委派产物，它指定验收标准，智能体在报告完成前需据此验证。任务描述同样是委派产物，其具体程度界定了智能体的决策空间。

低质量的委派会导致捷径螺旋：智能体跳过步骤，因为规格说明没有将它们列为必需。高质量的委派让必需步骤清晰明确。我的PRD包含编号的验收标准，每条标准都映射到可观察的产物（文件路径、测试结果或特定行为）。智能体若不产出对应产物，就无法将某一标准标记为完成。指定可观察结果的委派从根源上消除了一整类虚假完成。

这项技能的关键在于知道什么该明确指定，什么该留有余地。过度指定会产生脆弱的智能体，面对意外代码时无法适应。指定不足会让智能体做出你未授权的架构决策。边界随信任度移动：经过充分测试且配备完善 hook 的智能体可以获得更大的自由度，而首次运行夜间会话的新配置则需要更严格的约束。

2. 监督

监督是指监控活跃会话、审查差异，并在偏移累积前及时发现。

偏移是核心风险。智能体起初与规格保持一致，做出了一个看似合理但略有偏差的微观决策，随后基于这一偏差做出后续决策。到第八次迭代时，智能体解决的已经不是你委派的问题了。每个单独的决策在孤立看来都合情合理，但累积轨迹已偏离目标。

我通过两种机制捕捉偏移。第一，hooks 执行硬性边界：阻止命令、要求模式、禁止文件修改。Hook 实时捕捉违规行为，在智能体继续之前就已介入。第二，定期日志审查捕捉 hook 无法检测的软性偏移：智能体选择了不必要的复杂方案，或构建了规格未要求的功能，或优化了并非瓶颈的代码路径。软性偏移需要人类判断，因为没有自动化检查能确定智能体的运行轨迹是否匹配运维者的意图。

监督难以随智能体数量扩展。一个智能体每晚产生一个会话，喝杯早咖啡就能审完。五个智能体各运行八次迭代，就会产生四十个上下文窗口的工作量。排定优先级势在必行：先审查失败案例，再看涉及关键路径的会话，最后是低风险任务上的干净完成。

3. 干预

干预是指知道何时应该停止、重定向或重启正在执行任务的智能体。

四种模式需要干预：

智能体陷入循环。 连续迭代中出现相同错误。智能体用微小变化尝试相同的修复方案。每次迭代消耗一整个上下文窗口却毫无进展。干预措施：停止会话，手动诊断根因，用诊断结果更新交接文档，然后重启。

智能体产出了通过测试但不正确的结果。 代码能编译，测试全绿，但行为不符合规格意图。证据门能捕捉部分实例，但智能体也能为错误行为生成看似合理的论证。干预措施：编写一个能捕捉正确行为的失败测试，然后重启。

智能体即将触及生产环境或外部系统。 任何具有不可逆后果的操作（部署到生产环境、发送邮件、修改数据库、调用付费API）都需要设置关卡。我的 hook 会阻止破坏性 bash 命令和外部网络调用。运维者决定何时开启哪些关卡。²

智能体在进展，但方向错误。 工作本身质量合格，但与目标不一致。干预措施：停止，在交接文档中澄清规格，然后重启。不要试图在会话中途通过对话重新引导。智能体已经围绕错误理解建立了心智模型，在同一上下文窗口内的中途纠正只会产生不一致的输出。

无需干预的模式：智能体缓慢但稳步地朝正确目标推进。让它继续运行。

4. 恢复

恢复是指在故障发生后处理后果：损坏的状态、错误的分支、中断的构建和数据丢失。

智能体故障会留下痕迹。崩溃的会话可能写入了不完整的文件、提交到了错误的分支、在工作目录中留下了临时文件，或修改了后续会话会继承的配置。恢复要求在重启前消除这些痕迹。

我的恢复流程：清点损失（git status、git log、git diff），保留会话日志作为诊断数据，回退到上一个已验证的正确提交，用失败原因更新交接文档，然后用修正后的约束条件重启。除非部分工作明确正确且可隔离，否则不要试图从失败会话中抢救半成品。交接文档跨会话边界传递失败上下文，确保下一个智能体不会重蹈覆辙。

最危险的恢复场景是看似成功的失败。智能体报告完成，测试通过，构建正常，但实现存在微妙错误。信心幻象失败模式正是这种情况。恢复需要阅读代码，而非仅看完成报告。

5. 治理

治理是指制定适用于所有智能体会话的策略、预算、权限和审计要求。

策略定义智能体可以和不可以做什么。我的治理层包括：衍生预算（每次夜间运行的最大迭代次数）、成本上限（每次会话的最大API支出）、允许的 bash 命令白名单、禁止的文件模式黑名单，以及一组必需的完成标准。³ 每项策略都源于一次具体的失败。衍生预算的存在是因为早期一次会话跑了 47 次迭代都未收敛。成本上限的存在是因为一次调试会话在追踪无关线索时烧掉了 200 美元的API调用费。每条策略都是花费高昂代价后留下的教训。

权限遵循最小特权原则。生成博客内容的智能体不需要内容目录以外的文件系统写入权限。运行测试的智能体不需要网络访问权限。我的 hook 在工具调用层面强制执行这些边界，阻止超出会话权限范围的操作。²

审计要求完善了治理层。每次会话都生成结构化日志：执行的命令、修改的文件、运行的测试、评估的完成标准。七种失败模式分类法正是通过审查六个月的日志、对每次需要人工干预的故障进行分类而形成的。

监督体系

五个基础设施组件实现了五项职责。

Hook 实现自动化监督。 Claude Code的生命周期事件（PreToolUse、PostToolUse、Notification）触发 shell 脚本，实时执行策略。² 阻止 rm -rf 的 hook 是编码为 PreToolUse 检查的治理策略。要求在完成前执行测试的 hook 是编码为 PostToolUse 检查的委派约束。我系统中的 95 个 hook 编码了 95 项关于智能体可以和不可以做什么的决策，每一项都追溯到该 hook 现在所防止的特定故障。

证据门实现结构化验证。 六项标准（遵循模式、最简方案、边缘情况已处理、测试通过、无回归、解决了问题）必须产出具体产物，智能体才能将工作标记为完成。⁴ 证据门将监督从”智能体做得好吗？”（主观、不可验证）转化为”智能体是否为全部六项标准提供了证据？”（客观、可审计）。完成报告中出现的每一个含糊措辞都会触发重新验证。

质量循环实现迭代打磨。 七个步骤（实现、审查、评估、打磨、全局审视、重复、报告）迫使智能体对自身工作进行多轮检视。⁵ 该循环弥补了单次生成的结构性局限：模型产出的初稿看似合理，但往往包含只有重新阅读才能发现的错误。质量循环强制要求这种重新阅读。

会话日志实现事后审计。 系统以结构化形式捕获每次工具调用、文件修改和完成报告。六个月的会话日志催生了失败分类法。没有这些日志，每次故障都只会是孤立的轶事。

成本关卡实现预算管控。 衍生预算设置迭代次数上限。API成本上限设置 token 消耗上限。在衍生预算内未能收敛的智能体很可能已经陷入困境，更多迭代无济于事。预算迫使运维者去诊断和干预，而非寄望下一次迭代能自行解决问题。

何时干预，何时放手

干预决策是运维者最关键的判断。过早干预浪费智能体的工作成果，过晚干预则任由偏移累积。以下框架可供参考。

元原则：基于信息不对称进行干预，而非基于速度。当你掌握智能体不知道的信息（正确的代码路径、真实的需求、上次会话的失败模式）时，干预就是在传递这些知识。当智能体掌握的信息和你一样多，只是在解决问题的过程中时，让它继续工作。

运维者清单

启动前

• [ ] 规格已审查：验收标准明确、可观察且完整
• [ ] Hook 已激活：策略 hook 已针对任务类型启用并测试
• [ ] 预算已设定：衍生限制和成本上限已配置
• [ ] 沙盒已确认：智能体无法访问生产环境、发送外部请求或修改范围外的文件
• [ ] 交接文档已更新：如继续先前工作，交接文档已反映最新修正
• [ ] 分支整洁：工作目录在正确分支上且无未提交的更改

运行中

• [ ] 按设定间隔检查日志（夜间运行每 2-3 次迭代检查一次）
• [ ] 验证运行轨迹是否符合规格意图，而非仅符合规格字面
• [ ] 监控资源使用：token 消耗、迭代次数、文件系统变更
• [ ] 关注权限升级：任务不应需要的访问权限请求
• [ ] 记录任何软性偏移，留待会话后审查

完成后

• [ ] 审查所有文件变更，而非仅看完成报告
• [ ] 独立运行完整测试套件（不要信任智能体报告的测试结果）
• [ ] 检查智能体未明确修改的相邻代码是否存在回归
• [ ] 验证证据门：每项标准都有具体产物，而非笼统保证
• [ ] 用会话结果和任何修正更新交接文档
• [ ] 记录会话：遇到的失败模式、触发的 hook、干预决策
• [ ] 更新治理：如出现新的失败模式，编写 hook 或策略加以防范

运维者即匠人

智能体运维者的角色处于工程技能与产品判断力的交汇点。编写 hook 需要系统知识，编写规格需要产品理解力，审查智能体输出则两者兼需——既要评估代码是否正确，又要判断正确的代码是否解决了正确的问题。

聊天是错误的界面——对于运维工作的操作层面而言尤其如此。翻阅对话记录来监督自主工作，在单个智能体运行单个会话之后就无法扩展了。上文描述的监督体系（hook、证据门、质量循环、会话日志、成本关卡）通过将监督编码到基础设施中来弥补界面的不足。基础设施不会取代运维者，而是放大运维者的触达范围。

品味是一套技术体系描述了判断力的一面。知道什么该委派、什么该验证、什么该否决，需要从经验中积累的模式识别能力。每次会话都让运维者对智能体行为有更深入的认知。运维者的能力通过刻意练习、反思以及将教训永久编码到基础设施中而不断复利增长。

暗工厂代表理论上的终点——Level 5，无需人工阅读代码。当前大多数团队的实践处于 Level 3 或 Level 4：智能体完成工作，运维者监督并干预。Level 4 到 Level 5 之间的差距是验证层。Level 2 到 Level 4 之间的差距是运维者。

每个运行自主智能体的团队都会发展出运维者。问题在于他们是主动培养这一角色（定义职责、提供基础设施支持、进行明确的培训），还是被动地发展——把工作推给夜间会话失败时恰好还醒着的那个人。匠艺由此开始。