用 LoopAgent 把 Agent 从 Demo 推上生产：沙箱执行 + 技能懒加载 + 提示词版本化

不要跳过这步——绝大多数 Agent 事故源于边界没定清楚：

1. 这个 Agent 允许碰什么？
   - 可读：订单表、产品文档
   - 可写：工单系统的备注字段
   - 绝对禁止：财务库、用户密码、对外发件

2. 什么叫「做完了」？
   - 明确的成功判据，例如「工单状态更新为已处理且备注非空」
   - 不能是「AI 觉得自己做完了」

3. 失败怎么办？
   - 重试上限是多少
   - 超限后转给谁
   - 中间产生的副作用如何回滚

LoopAgent 允许 Agent 在隔离的 Bash 沙箱中运行代码，从而在不牺牲系统安全的前提下完成需要脚本的自动化任务：

沙箱应该限死的四件事：
· 文件系统：只挂载本次任务所需目录，其余不可见
· 网络：默认禁出网，白名单放行必需域名
· 资源：CPU / 内存 / 执行时长上限，防死循环烧钱
· 生命周期：任务结束即销毁，不留残留状态

典型用法：
让 Agent 写一段脚本清洗 CSV、生成图表、调用内部 API，
脚本在沙箱里跑，只把结果文件带回来。

LoopAgent 的 Skills 是按需加载的，而非一次性全部载入——这在高并发场景下直接决定账单：

反面教材：
系统提示词里塞了 40 个工具定义，每轮对话都要重发一遍。
假设每个工具定义 200 Token，40 个就是 8000 Token，
一天 10 万次调用 = 8 亿 Token 白白烧在「自我介绍」上。

正确做法：
1. 常驻层：只放 3-5 个高频核心工具
2. 按需层：其余技能写清楚触发描述，命中才加载
3. 分组：按业务域分技能包（售前 / 售后 / 技术支持），
   会话开始时根据入口判断加载哪一组

这是 LoopAgent 里最被低估的能力：团队可以对定义 Agent 行为的提示词做版本控制、跨版本比较变更，并精确追溯每个决策由哪个提示词版本管辖：

为什么重要（两个真实痛点）：

痛点一：客户投诉「上周 AI 说的和这周不一样」。
        没有版本记录，你根本查不出中间谁改了哪句话。

痛点二：合规审计问「这条自动决策依据是什么」。
        你需要拿出当时那个版本的完整提示词，而不是现在这版。

落地要求：
· 每次提示词变更走类似代码 PR 的流程，写清变更理由
· 每条执行日志记录 prompt_version 字段
· 大改前先灰度：新版本先跑 10% 流量，对比关键指标

当任务需要人工介入时，LoopAgent 会生成一份私有的对话与任务状态摘要，人工坐席接手时已掌握完整上下文：

一份合格的交接摘要应包含：
1. 客户是谁、诉求一句话概括
2. Agent 已经做了什么（调了哪些工具、改了哪些数据）
3. 卡在哪一步、为什么触发转人工
4. 已经向客户承诺过什么（这条最容易漏，也最容易翻车）
5. 建议的下一步动作

触发转人工的时机：
· 连续 N 轮未推进目标
· 命中高风险动作（退款、销户、对外发送）
· 客户情绪识别为强烈不满
· 置信度低于阈值

持续执行意味着持续花钱，生产级引擎必须提供步骤级审计追踪与成本护栏：

成本护栏（三层）：
· 单次任务上限：超过 X Token 强制中止并告警
· 单用户日上限：防止个别账号刷爆
· 全局熔断：日消耗超预算 80% 时降级到便宜模型

审计追踪（每步都要记）：
timestamp | step_id | tool_name | input_hash |
output_summary | token_cost | prompt_version | 耗时

用途：
出问题时能定位到具体哪一步、哪个版本、花了多少钱，
而不是对着一坨对话记录抓瞎。