AI Agent 交接跑偏怎么办：从意图检查到交接摘要一步步排查

多 Agent 系统刚接入业务时，经常会出现一个很隐蔽的问题：主 Agent 看起来已经把任务交给了“更专业”的 Agent，但最终答案却偏离了用户真实诉求。比如用户说“帮我分析上个月销售下降的原因，并提出改进建议”，主 Agent 判断这是数据分析任务，于是交给数据分析 Agent；结果对方只拿到一句简短描述，没有时间范围、指标口径、渠道维度和成功标准，最后给出一堆泛泛建议。

这篇文章我们不讲抽象概念，而是按一次排查过程来走。先看交接跑偏的现场，再定位到底是意图、边界、上下文还是复查出了问题，最后把修复流程收拢成一套可以放进项目里的做法。

摘要

AI Agent 交接跑偏通常不是某个模型单独“不聪明”，而是交接边界和上下文传递不稳定。稳定方案是：先做意图检查，再按边界规则选择目标 Agent，交接时带上任务目标、关键数据、约束条件和成功标准，最后对结果做完整性复查，高风险建议再进入人工确认。

适合人群

• 正在做 AI 助手、客服辅助、运营分析 Agent 的开发者。
• 已经接入多 Agent 编排，但经常遇到任务分发不稳的团队。
• 想把 AI 自动化从“能跑”改造成“可控、可复查”的工程负责人。

问题现场：主 Agent 明明交接了，答案却偏了

我们先还原一个后台分析场景。用户输入：

帮我分析上个月销售下降的原因，并提出改进建议。

主 Agent 做了一个看似合理的判断：这是销售数据分析任务，应该交给“数据分析 Agent”。问题是，交接时只传了原始用户问题，没有把业务背景补齐。接收方拿不到这些信息：

• “上个月”对应哪个自然月，是否按北京时间统计。
• 销售下降指 GMV、订单数、客单价，还是转化率下降。
• 需要按渠道、地区、品类还是活动维度拆解。
• 最终输出是给运营复盘，还是给管理层决策。

于是接收方只能猜。它可能会给出“增加投放、优化页面、提升客服响应”这类通用建议，看起来完整，但和真实原因没有建立关系。

这张图展示的是典型链路：用户问题进入主 Agent，主 Agent 选了一个专业 Agent，但中间缺了上下文卡片，接收方只能基于猜测继续处理，最后答案方向偏了。

第一步：先看意图是否判断准确

我们先不要急着改提示词。第一轮排查应该看主 Agent 的意图判断是否稳定。用户说“销售下降”，主 Agent 是否能区分下面几类任务：

这一步可以用一个很小的调试输出验证：

{
  "intent": "sales_drop_analysis",
  "target_agent": "data_analysis_agent",
  "confidence": 0.82,
  "missing_fields": ["time_range", "metric", "dimension"]
}

如果 target_agent 经常跳来跳去，说明路由规则还没稳住；如果目标 Agent 选对了，但 missing_fields 总是很多，说明问题更可能出在交接内容。

第二步：检查交接边界是否写清楚

接着验证第二个猜测：主 Agent 也许知道该交给谁，但不知道什么时候不能交。多 Agent 不是越多越好，交接边界必须写成可判断的规则。

一个可用的边界规则至少包含四件事：

• 能力范围。 这个 Agent 解决什么问题，不解决什么问题。
• 输入要求。 至少需要哪些字段，缺字段时是追问还是拒绝交接。
• 风险等级。 只是分析建议，还是会改数据、发消息、创建任务。
• 成功标准。 输出到什么程度才算完成。

例如数据分析 Agent 的边界可以这样描述：

{
  "agent": "data_analysis_agent",
  "can_handle": [
    "趋势分析",
    "维度拆解",
    "异常指标定位"
  ],
  "need_fields": [
    "time_range",
    "metric",
    "dimension",
    "data_source"
  ],
  "cannot_handle": [
    "直接修改投放预算",
    "自动通知客户",
    "替用户下发任务"
  ]
}

这一步说明了一个关键点：交接不是简单转发聊天记录，而是一次带规则的任务分配。规则越模糊，接收方越容易拿着不完整信息继续猜。

第三步：用交接摘要补齐上下文

现在可以定位到主要原因：主 Agent 交接时没有带上稳定摘要。交接摘要不是把全文压缩一下，而是把接收方完成任务必须知道的信息结构化传过去。

推荐的交接摘要包含这些字段：

{
  "task_goal": "分析上个月销售下降原因并给出改进建议",
  "time_range": "2026-05-01 到 2026-05-31",
  "metric": "GMV",
  "dimensions": ["渠道", "品类", "地区"],
  "data_source": ["订单明细表", "投放渠道报表"],
  "constraints": ["不自动修改预算", "只输出分析建议"],
  "success_criteria": [
    "指出下降最明显的维度",
    "给出数据证据",
    "列出可落地动作"
  ]
}

这里的重点不是字段越多越好，而是每个字段都能减少一次猜测。接收方看到 constraints，就知道不能直接改预算；看到 success_criteria，就知道只给宽泛建议不算完成。

上图把修复链路拆成五段：先确认用户意图，再检查边界规则，接着生成交接摘要，收到结果后做复查，高风险动作进入人工确认。

第四步：结果复查和人工确认

交接摘要能减少跑偏，但不能替代结果复查。我们要在接收方返回后，再检查它有没有满足原始目标。最简单的做法是让主 Agent 或一个复查模块对照成功标准打勾。

{
  "review": {
    "has_main_reason": true,
    "has_data_support": true,
    "has_action_plan": true,
    "risk_level": "medium",
    "need_human_confirm": true
  }
}

为什么这里需要人工确认？因为“提出改进建议”本身风险不高，但如果建议会触发预算调整、客户通知、任务下发，就已经从分析进入业务动作。此时最好先给用户展示摘要，让人确认以后再进入后续流程。

最终返回给用户的结果可以分成三段：

• 结论：销售下降主要集中在哪些渠道或品类。
• 证据：对应的指标变化、对比周期和数据来源。
• 建议：哪些动作可以立刻做，哪些需要人工确认。

这样做的好处是，用户能看见 Agent 不是“随口建议”，而是按目标、数据和约束完成了一次可复查的分析。

常见坑：不要把交接当成万能路由

第一个坑是只靠 Agent 名称做路由。比如看到“销售”就交给销售 Agent，看到“报表”就交给数据 Agent。真实业务里一句话可能同时包含分析、写作、通知和任务创建，必须先拆意图。

第二个坑是把完整聊天记录全部传给接收方。看起来信息很多，实际会把噪音、过期结论和未确认猜测一起传过去。更稳的是传交接摘要，并明确哪些信息是已确认，哪些只是候选线索。

第三个坑是缺少结果复查。接收方输出一段流畅文字不代表任务完成。要回到成功标准检查：有没有覆盖目标、有没有引用关键数据、有没有说明限制条件、有没有识别风险动作。

第四个坑是把人工确认放得太晚。等系统已经创建任务、发送通知或调整配置以后再让人复核，成本会很高。高风险动作应该在真正落地前停下来。

总结

AI Agent 交接跑偏，表面看是“专业 Agent 答得不好”，实际经常是主 Agent 没有把任务边界和上下文交清楚。我们按排查顺序看：先确认意图判断是否稳定，再检查交接边界，随后用交接摘要补齐上下文，最后用结果复查和人工确认兜住风险。

落地时可以记住一个简单清单：意图要可解释，边界要可判断，摘要要能减少猜测，结果要能复查，高风险动作要有人确认。做到这五点，多 Agent 系统才更像一个可控的工作流，而不是多个模型在互相转发问题。