生产执行：SKILL与Agent如何安全稳定地跑在真实业务中

昨天我们聊了AgentTeam多人协同——Spec规范、CR审核、测试回归、变更留痕，解决的是"一群人怎么管理AI"的问题。

但还有一个场景没深入：当SKILL和Agent真正跑在生产流程中，面对真实的业务、真实的用户、真实的风险，怎么保证安全稳定？

这是一个跟"写SKILL"完全不同维度的问题。写SKILL是设计体验，生产执行是运营体验。设计不当顶多重写，运营不当可能影响线上。

一、用户第一：别只当"看客"，要当"驾驶员"

问题

大部分SKILL的设计视角，是从开发者出发的——AI在后台跑，用户在前端等结果。整个过程像一个黑盒：你触发了SKILL，然后盯着屏幕等，不知道AI在做什么、做到哪了、还要多久。

这种设计的致命问题：用户成了看客，而不是驾驶员。

用户的心理模型是："我交给你一件事，你得让我知道进展，关键决策别替我做。"

但当前很多SKILL的交互模型是："我替你全做了，你看结果就行。"

用户的真实诉求

先搞清楚：你的SKILL面向谁？他们最关心什么？

• 角色1：一线研发
• 场景：用AI排查线上问题、生成技术方案
• 核心诉求：
• 执行过程透明：AI正在做什么、为什么这么做
• 关键节点可干预：AI的判断我不认，我要能改

• 结果可解释：为什么得出这个结论，依据是什么

• 角色2：技术负责人

• 场景：用AI做变更风险评估、生成变更方案
• 核心诉求：
• 风险点前置展示：不要等做完了才告诉我有风险
• 决策留痕可审计：每个决策的依据要记录

• 影响范围可量化：具体影响了哪些模块、接口、用户

• 角色3：产品/运营

• 场景：用AI生成数据报告、分析用户反馈
• 核心诉求：
• 结果可信度标注：哪些是确认的、哪些是推断的
• 数据来源可追溯：结论基于哪些数据
• 输出直接可用：格式不要二次加工

重新设计交互：从"黑盒执行"到"透明可控"

关键转变：不应该是"AI做完给你看"，而应该是"AI做到关键节点时，展示进展、征求确认、解释决策"。

旧模式（黑盒执行）：
 用户触发 → AI静默执行 → 输出结果 → 用户被动接受

新模式（透明可控）：
 用户触发
 → AI展示执行计划（"我准备做这3步，预计5分钟"）
 → 用户确认/调整
 → AI执行第1步
 → AI展示中间结果 + 下一步意图（"发现了3个风险点，准备逐个分析"）
 → 用户确认继续
 → AI执行第2步
 → AI展示关键发现（"第2个风险点需要你决策：A方案安全但慢，B方案快但有风险"）
 → 用户做决策
 → AI按用户决策继续执行
 → 输出最终结果 + 决策过程摘要

具体设计：用户在执行过程中应该看到什么

1. 进度信息（持续展示）
- 当前执行到哪一步（进度条/步骤清单）
- 预计剩余时间
- 已完成步骤的简要结果
- 设计原则：让用户有"掌控感"，而不是干等

2. 决策信息（需要交互）
- AI的判断依据是什么
- 有几个选项，各自优劣
- AI推荐的选项及原因
- 设计原则：给用户选择权，而不是替用户做决策

3. 风险信息（前置告警）
- 发现了什么风险
- 风险等级和影响范围
- 建议的应对措施
- 设计原则：风险前置，不要等做完才说

4. 异常信息（实时通知）
- 执行过程中遇到了什么意外
- AI的自动降级策略是什么
- 是否需要人工介入
- 设计原则：异常不可怕，不知道异常才可怕

关键洞察：用户不是来看"AI多厉害"的，是来解决自己的问题的。整个过程应该让用户觉得"我在用AI做事"，而不是"AI在替我做事"。驾驶员握着方向盘，才敢放心上路。

二、用好Claude工具：/loop调度 + 主从Agent架构

问题

生产场景下，Agent需要做的事情往往是一个持续循环：定期检查状态、发现问题、执行处理、验证结果、反馈进展。不是一个跑完就结束的单次任务。

但很多人把Agent设计成"一次性执行"：触发→跑完→结束。下一轮需要重新触发。这种模式有两个问题：

1. 上下文丢失：每次重新触发，之前的执行上下文没了，又要重新加载。
2. 实时性差：问题发生后，等到人手动触发才处理，响应延迟大。

解法：用/loop实现循环调度

Claude Code的/loop命令天然适合这个场景——它可以让Agent以固定间隔持续执行，保持上下文连贯性：

基础用法：
 /loop 5m 执行变更风险巡检
 → 每5分钟自动执行一次风险巡检
 → 上下文持续保持，每轮构建在上一轮结果之上

进阶用法——携带状态的循环：
 第1轮：收集当前状态 → 发现2个风险点
 第2轮：基于上一轮的2个风险点 → 深入分析根因
 第3轮：基于根因分析 → 生成处置建议
 第4轮：验证处置效果 → 风险点是否消除
 第5轮：风险消除 → 输出总结报告 → 循环结束

 关键：每轮不是从零开始，而是继承上一轮的上下文

主从Agent架构：Master管调度，Worker管执行

当任务复杂度提升，一个Agent既要调度又要执行，上下文会急剧膨胀。正确做法是Master Agent负责调度和判断，Sub Agent负责具体执行：

Master Agent（调度者）：
 职责：
 - 接收用户指令，拆解为子任务
 - 分配子任务给Worker Agent
 - 收集Worker返回的结果
 - 做全局判断和决策
 - 与用户交互（展示进展、征求确认）
 上下文管理：
 - 只保留：任务列表、执行状态、关键结论
 - 不保留：代码细节、日志原文、中间数据
 - 保持精简，避免上下文膨胀

Worker Agent（执行者）：
 职责：
 - 执行Master分配的单个子任务
 - 返回结构化的执行结果
 - 不负责全局决策
 上下文管理：
 - 只关注当前子任务
 - 执行完毕后返回精炼结果
 - 不向上传递冗余信息

为什么避免多Agent协同

当前一个现实问题：Agent Team的多Agent协同，可用率会随着Agent数量增加而衰减。

• 1个Agent：可用率 95% → 只有自己的幻觉风险
• 2个Agent协同：可用率 ≈ 90%（0.95 × 0.95）→ 两个Agent都要靠谱，结果才靠谱 → 加上Agent间信息传递的损耗，实际更低
• 3个Agent协同：可用率 ≈ 86% → 任何一个出错都可能级联影响
• N个Agent：可用率 ≈ 0.95^N → 指数级衰减

当前阶段的务实策略：

1. Master Agent + 少量Worker Agent
2. Master只有1个，Worker根据需要动态创建
3. Worker之间不直接通信，全部通过Master协调
4. Worker生命周期短
5. 创建 → 执行 → 返回结果 → 销毁
6. 不让Worker长期存活，减少状态管理复杂度
7. 结果在Master层聚合
8. Worker返回的结构化结果是唯一的通信接口
9. 不允许Worker之间共享上下文

前期避免的设计：
- 多个Agent互相调用、递归嵌套
- Agent之间共享大段上下文
- 长生命周期的Worker Agent
- → 这些在Agent Team基础设施成熟后再考虑

关键洞察：Agent架构不是越复杂越好。Master调度 + Worker执行的两层模型，在当前阶段是最务实的选择。等可用率和稳定性验证充分了，再考虑更深层的多Agent编排。

三、长上下文危机：影响面分析正在吃掉你的上下文

问题

这是目前生产环境中最棘手的问题之一。

Agent在执行变更风险评估时，需要做影响面分析——读取代码仓库、分析调用链、评估变更影响。这个过程会产生大量中间数据：

一次影响面分析产生的上下文消耗：
 步骤1：读取变更文件列表 → 约5000 token
 步骤2：分析每个文件的调用链 → 约20000 token
 步骤3：识别下游依赖 → 约15000 token
 步骤4：评估风险等级 → 约5000 token
 步骤5：生成风险报告 → 约3000 token
 总计：约48000 token

 → 这还只是一个中等规模的变更分析
 → 大型变更可能消耗100K+ token

问题在于：影响面分析通常在流程的最前面。它做完之后，后续的风险判断、方案生成、用户交互都在同一个上下文中——但前面已经被代码分析占了大半，留给后续环节的上下文空间严重不足。

结果：前置分析节点不稳定，后续执行跟着一起崩。

解法一：把影响面分析拆成独立Agent

调整前：
 Master Agent
 ├── 代码分析（消耗大量上下文）
 ├── 风险判断（上下文已不足）
 ├── 方案生成（上下文进一步压缩）
 └── 用户交互（几乎没空间了）

调整后：
 Master Agent（只做调度和判断）
 ├── 调用 代码分析Agent → 返回结构化结论
 │ （独立上下文，不受Master上下文限制）
 ├── 收到分析结论 → 做风险判断
 ├── 基于风险判断 → 生成方案
 └── 与用户交互

 代码分析Agent（独立上下文窗口）
 ├── 读取代码
 ├── 分析调用链
 ├── 生成结构化分析报告
 └── 只返回精炼结论给Master

关键：Master Agent不读代码原文，只获取代码分析Agent的结构化结论。

代码分析Agent返回给Master的精炼结论
（控制在2000 token以内）：

变更文件: [文件列表，每行一个]
影响接口: [接口列表，含调用方向]
影响下游: [下游服务列表，含影响方式]
风险点:
 - 风险1: 描述 + 等级 + 建议处置
 - 风险2: 描述 + 等级 + 建议处置
复杂度评级: 高/中/低
建议执行策略: [分步/灰度/直接变更]

这样Master的上下文始终干净——不管代码分析有多复杂，Master只需要读一份2000 token的结论报告。

解法二：上下文的分阶段管理

不仅仅是代码分析，整个执行流程都应该做上下文的分阶段管理——每个阶段结束后，把中间信息压缩，只保留结论：

阶段1：信息收集
 上下文：原始数据、日志、代码片段
 结束时：压缩为结构化摘要
 压缩比：约10:1（1万token → 1千token摘要）

阶段2：分析判断
 上下文：阶段1的摘要 + 分析推理过程
 结束时：压缩为结论列表
 压缩比：约5:1

阶段3：方案生成
 上下文：阶段2的结论 + 方案设计
 结束时：输出最终结果

每个阶段的上下文 = 上一阶段的压缩结论 + 本阶段的工作内容
不会无限膨胀

解法三：按需加载而非全量注入

另一种降低上下文消耗的思路：不要一开始就把所有信息塞进上下文，而是按需加载。

不要这样做：
 一开始就加载完整代码仓库、全部调用链、所有历史变更

应该这样做：
 1. 先加载变更文件名列表（判断哪些文件可能受影响）
 2. 根据判断结果，只加载相关文件的代码
 3. 根据代码分析结果，只加载相关调用链
 4. 根据调用链，只加载相关下游信息

 每一步只加载"下一步决策需要的信息"
 像剥洋葱一样，一层一层展开

 这就是Progressive Disclosure在执行层面的应用
 分层加载不只是SKILL的加载策略，更是执行过程的上下文管理策略

关键洞察：上下文是Agent最稀缺的资源。像管理内存一样管理上下文——及时释放不用的信息，按需加载需要的信息，压缩保留关键结论。上下文管理的水平，直接决定了Agent能处理多复杂的任务。

四、我的补充：生产执行的四个关键设计

上面三个问题是你在实战中已经遇到的。我再补充四个从工程经验出发的关键设计，帮你把生产执行的稳定性再提一个台阶。

补充一：执行状态机——让Agent的行为可预测

Agent在生产环境中最大的风险不是"做错了"，而是"不知道在做什么"。你可能遇到过这种情况：Agent突然卡住了，或者做了一件你没预期的事，但你不知道它处于什么状态、为什么这么做。

解法：给Agent设计明确的状态机，每个状态都有清晰的边界和转换条件：

状态定义：
 IDLE → 空闲，等待触发
 PLANNING → 正在规划执行步骤
 EXECUTING → 正在执行子任务
 WAITING → 等待用户确认/决策
 VERIFYING → 正在验证执行结果
 ROLLBACK → 执行失败，正在回滚
 DONE → 执行完成
 ERROR → 异常状态，需人工介入

状态转换规则：
 IDLE → PLANNING（用户触发）
 PLANNING → WAITING（计划需要确认）
 PLANNING → EXECUTING（简单任务直接执行）
 EXECUTING → VERIFYING（执行完毕进入验证）
 EXECUTING → WAITING（需要用户做决策）
 VERIFYING → DONE（验证通过）
 VERIFYING → ROLLBACK（验证失败）
 ROLLBACK → DONE（回滚完成）
 任何状态 → ERROR（遇到不可恢复的异常）
 ERROR → IDLE（人工处理后重置）

关键设计：

1. 每个状态对外暴露的信息不同
2. IDLE → "等待任务"
3. EXECUTING → "正在执行第2/5步：xxx"

4. WAITING → "需要你确认：xxx"

5. 每个状态的超时机制

6. PLANNING → 超时3分钟 → 提示用户重新输入
7. EXECUTING → 超时10分钟 → 自动降级或回滚

8. WAITING → 超时30分钟 → 自动保存进度，回到IDLE

9. 每个状态的错误处理

10. 不是所有异常都进ERROR
11. 可恢复的异常 → 自动重试（最多3次）
12. 不可恢复的异常 → 进ERROR，通知人工

补充二：降级策略——当AI不行时怎么办

生产环境必须回答一个问题：AI执行失败或不可用时，流程怎么继续？

L1 自动降级（AI自救）
- 场景：AI输出质量下降，但不完全失败
- 策略：
- 切换到更保守的执行策略（减少自主决策，增加确认步骤）
- 缩短单次执行范围（大任务拆小，每步验证）
- 降低输出承诺（从"精确答案"降级为"参考建议"）
- 示例：影响面分析不确定时
→ 降级为"范围可能包含以下模块，建议人工确认"
→ 而非给出一个不确定的精确名单

L2 人机协同降级（AI辅助+人工接管）
- 场景：AI无法独立完成任务，但能提供辅助
- 策略：
- AI完成信息收集和初步分析
- 关键判断和决策由人工完成
- AI辅助执行人工确认的方案
- 示例：风险等级判断不确定时
→ AI列出所有风险因素和可能的等级
→ 由人工做最终评级
→ AI按人工评级生成后续方案

L3 全人工降级（AI退出）
- 场景：AI完全不可用（API故障、模型崩溃）
- 策略：
- 流程回退到AI介入前的手动流程
- AI已完成的中间结果保留，人工可参考
- 关键数据不丢失，人工可接续
- 设计原则：
- AI是增强工具，不是单点依赖
- 任何AI参与的流程，都必须保留人工通路

补充三：执行沙盒——高风险操作必须隔离

生产执行中，有些操作是不可逆的——删数据、改配置、发布上线。这些操作如果让Agent直接在生产环境执行，任何幻觉都可能导致严重后果。

原则：先试后做，dry-run先行

沙盒分级：

Level 1：只读沙盒（默认）
 所有信息查询类操作
 → 可以直接在生产环境执行
 → 只读不写，风险可控

Level 2：预演沙盒（中等风险操作）
 配置变更、代码修改等
 → 先在沙盒环境预演（dry-run）
 → 预演通过 → 展示diff给用户确认
 → 用户确认 → 在生产环境执行

Level 3：隔离沙盒（高风险操作）
 数据库变更、发布上线等
 → 先在隔离环境完整验证
 → 验证通过 → 生成执行计划
 → 执行计划需两人确认
 → 执行过程中关键节点checkpoint
 → 每个checkpoint通过后才继续下一步

实现方式：
 - Claude Code的沙盒模式（--sandbox）
 - Docker容器隔离执行
 - Git worktree隔离修改
 - 数据库事务包裹（可回滚）

补充四：执行度量——不度量就没法优化

最后一点：生产执行需要可度量。你不知道Agent执行的成功率、平均耗时、幻觉频率，就无法有针对性地优化。

效率指标：
- 平均执行时长（按SKILL分类统计）
- 首次成功率（一次执行就正确完成任务的比例）
- 人工干预率（执行过程中需要人工介入的比例）

质量指标：
- 幻觉发生率（输出中包含虚假信息的比例）
- 约束遵守率（硬约束被遵守的比例）
- 输出一致性（同一输入多次执行的输出稳定性）

成本指标：
- Token消耗（按SKILL、按阶段统计）
- 上下文利用率（有效信息 / 总上下文）
- 降级触发率（自动降级+人工降级的比例）

运营指标：
- SKILL使用频率（哪些常用、哪些闲置）
- 用户满意度（主观评分 or 再次使用率）
- 知识沉淀速率（每次执行产生的新经验条目数）

使用方式：
1. 每周Review效率和质量指标
2. 幻觉率 > 10%的SKILL优先优化
3. 人工干预率 > 30%的流程需重新设计交互
4. 上下文利用率 < 40%的环节需做compact

关键洞察：生产执行不是"写完SKILL就完事"，是一个持续的运营过程。像运维线上服务一样运维你的AI——有监控、有告警、有降级、有度量，才能在真实业务中稳定运行。

五、生产执行全景

把今天所有内容串起来：

用户侧（让用户是驾驶员不是看客）：
 ├── 透明执行：进度、决策、风险、异常四类信息持续展示
 ├── 关键节点可干预：AI征求确认而非替人决策
 └── 结果可解释：每个结论有依据，每个决策有记录

调度侧（用好工具、用对架构）：
 ├── /loop循环调度：保持上下文连贯，持续执行
 ├── Master-Worker架构：调度和执行分离
 └── 避免多Agent协同：当前阶段两层模型最务实

上下文侧（最稀缺的资源要最精细地管理）：
 ├── 独立Agent拆分：代码分析独立部署，只返回精炼结论
 ├── 分阶段压缩：每个阶段结束压缩中间信息
 └── 按需加载：像剥洋葱一样逐层展开

工程侧（四个关键设计）：
 ├── 状态机：Agent行为可预测、可追踪
 ├── 降级策略：AI不行时流程不中断
 ├── 执行沙盒：高风险操作先试后做
 └── 执行度量：不度量就没法优化

六、结语：从"能用"到"敢用"

30天进阶走到这里，我们覆盖了一个完整的进化路径：

• Week 1：学会写SKILL——让AI按你的规则输出
• Week 2：MCP + Agent——让AI连接世界、多步协作
• Week 3：Harness + 安全——让AI在约束中可靠运行
• Week 4：源码机制——理解AI决策的底层逻辑
• Day 26：四个乘数——构建不可替代性
• Day 27：知识复利——Harness的终极价值
• Day 28：防幻觉——六个实战策略
• Day 29：多人协同——团队如何管理AI
• Day 30：生产执行——从"能用"到"敢用"

"能用"是你的SKILL跑通了、AI能出结果了。

"敢用"是你信任AI在生产环境稳定运行、你设计了降级和兜底、你知道出问题怎么回退、用户觉得过程透明可控。

从"能用"到"敢用"的这步跨越，靠的不是更强大的模型，而是更完善的工程。

这也是30天进阶最想传递的一个信念：AI时代最重要的能力，不是会用最强的模型，而是能用工程化的方法，让AI在你设计的框架内可靠地工作。

掌握这套方法论，你就拥有了在AI时代和AI共同进化的能力。

不是被AI替代，而是驾驭AI，共同创造。