4 个以上关注点？不做显式分解只有 38% 被完整处理

客户天然会打包相关请求：“查一下我的订单状态，还有我被扣了两次费，而且我的积分好像不对。“不做显式分解，agent 处理了第一个关注点就忘了其余的。消息中的关注点越多，遗漏率越高。

完成率数据

下降的完成率和”最后一个被遗漏”的模式说明 agent 识别并处理了前面的关注点，但丢失了后面的。这是工作流设计问题，不是能力问题——agent 有处理所有关注点的工具。

修复：显式分解步骤

在工作流开始时加一个分解步骤：在采取任何行动之前，解析完整消息识别所有独立的关注点，列出来，然后逐一处理。这把”回应我看到的第一件事”变成”先列出所有事，然后逐个回应”。

某系统通过加这一步把多关注点错误从 40% 降到了 10% 以下。分解创建了一个隐式检查清单，防止关注点被遗忘。

独立 vs 依赖的关注点

独立的（退货 + 地址更新）：并行处理更快。不同的 agent 或工具调用，没有顺序约束。最后统一响应。

依赖的（退货 → 退款 → 用积分购买）：按依赖链顺序处理。退货没批准就不能退款。积分还不存在就不能用来购买。Agent 管理链条并在每一步沟通状态——客户不应该自己追踪依赖关系。

混合解决和升级

客户提了 3 个关注点：物流状态（可解决）、策略例外（需要升级）、地址更新（可解决）。

正确：立即解决关注点 1 和 3，然后升级关注点 2，交接摘要中包含已提供的解决方案。客户立刻得到 agent 能处理的答案。人工客服收到已解决内容的上下文——他们不需要重新调查已完成的项目。

错误：因为一个关注点需要升级就升级整个交互。这浪费人工时间在 agent 已经解决的关注点上。

也是错误的：只处理可解决的关注点而忽略需要升级的那个。即使 agent 解决不了它，也应该承认它并正确路由。

分解准确度

分解质量的生产数据：

• 78% 正确（所有关注点被正确识别和分离）
• 8% 过度分解（一个关注点被拆成两个）
• 14% 分解不足（两个关注点被合并为一个 → 部分解决）

14% 的分解不足是更大的问题。修复：few-shot 例子展示如何正确分离出现在同一句话中的关注点。“我被扣了两次费而且物流也很慢”= 两个关注点，不是一个。例子教会 agent 同一句话中共现的关注点仍然是独立项目。

统一响应，不是三条消息

所有关注点解决后，综合成一条统一响应——不是三条单独消息。统一响应：

• 展示 agent 理解了完整请求
• 让客户一次性验证所有关注点都被处理了
• 避免聊天中令人困惑的交叉消息

自然叙述，不是机械清单

响应应该全面且自然。保留分解做完整性追踪，但综合成对话式叙述：

“您提到的三件事我都查了。您的订单明天送达。关于重复扣费，我已发起 $45.50 的退款，3-5 个工作日到账。另外，您的配送地址已经更新了。”

不要：“关注点 1：订单状态 - 正常。关注点 2：重复扣费 - 已退。关注点 3：地址 - 已更新。“两种都完整，但第一种读起来像一个贴心的人，第二种像打印出来的表单。

一句话总结： 不做显式分解，4 个以上关注点只有 38% 被完整处理（最后一个最常遗漏）——加分解步骤，独立关注点并行处理，依赖链按顺序，能解决的解决、该升级的升级，综合成自然的统一响应。