跨工具时序冲突

在自动化办公场景中，跨工具时序冲突（Cross-Tool Temporal Conflicts） 是最常见的问题之一。

例如：Agent 需要“先生成 Excel 报表（工具 A），再发送邮件（工具 B）”。如果 Agent 在 Excel 生成完毕之前就调用了发送邮件工具，或者尝试并行执行这两个本该串行的任务，就会导致发出的邮件没有附件，或者程序报错。

在 LangChain 生态中，解决这个问题的核心在于从“概率性预测”转向“确定性约束”。以下是 4 种分层级的解决方案：

1. 架构层：使用 LangGraph 强制状态流转 (最佳实践)

LangChain 官方目前主推 LangGraph 来解决此类问题。传统的 Agent (如 AgentExecutor) 是基于循环的，容易出现逻辑跳跃；而 LangGraph 允许你构建状态机（State Machine）。

• 原理： 将工作流定义为图（Graph）。节点（Node）是工具或 LLM，边（Edge）是依赖关系。
• 如何解决冲突： 你可以显式定义 Node A (生成报表) 完成后，才能流转到 Node B (发送邮件)。这在物理层面上禁止了乱序执行。

实施思路：

• 定义 State (状态)：包含 report_path 字段，初始为 None。
• 定义条件边 (Conditional Edge)：检查 State.report_path 是否存在。如果存在，流向“邮件节点”；如果不存在，强制流回“报表节点”或报错。

2. 工具定义层：参数强依赖 (Hard Constraints)

利用 Pydantic 对工具参数的验证机制，在工具定义层面制造“逻辑锁”。

• 原理： LLM 只有在填满所有必填参数时才能调用工具。如果我们将前序任务的产出物（Artifact）设为后序任务的必填参数，LLM 就被迫先执行前序任务。
• 代码策略：
  • 工具 A (generate_report)：返回输出不是简单的 “Done”，而是一个明确的 ID 或路径，例如 {"status": "success", "file_id": "rpt_12345"}。
  • 工具 B (send_email)：定义其输入参数 attachment_file_id 为必填项。
• 效果： Agent 试图调用 send_email 时，发现缺少 file_id，它会“意识到”必须先调用 generate_report 来获取这个 ID。

3. 提示工程层：思维链与依赖声明 (Prompt Engineering)

如果架构不能动，可以通过强化 System Prompt 来引导 Agent 的规划能力。

• 显式依赖声明 (Dependency Declaration):在 Prompt 中加入“工具使用协议”部分：”PROTOCOL: You MUST follow strict sequential order.
  1. Use search_data first.
  2. ONLY after search_data returns output, use analyze_data.
  3. NEVER call email_result until analyze_data is finished.”
• 强制 CoT (Chain of Thought):强制 Agent 在行动前输出规划：”Before calling any tool, output a plan:Plan:
  1. [Step 1]
  2. [Step 2 (Dependent on Step 1)]”

4. 运行时层：人工介入与检查点 (Human-in-the-loop)

对于关键的办公任务（如群发邮件、删除文件），依靠 LLM 的自律是不够的。

• 机制： 使用 LangGraph 的 interrupt_before 功能。
• 流程：
  1. Agent 执行完生成报表。
  2. Agent 准备执行发送邮件。
  3. 系统暂停（Suspend）。
  4. 人类用户看到界面提示：“检测到即将发送邮件，附件为 report.xlsx，确认继续吗？”
  5. 人类确认后，系统恢复运行。这不仅解决了时序问题，还解决了安全问题。

方案对比与推荐

总结建议

针对您的“自动化办公 Agent”，强力推荐使用 LangGraph + 参数强依赖 的组合。

1. 用 LangGraph 编排宏观流程（先做 Excel，后发邮件）。
2. 用 参数传递 确保微观数据的正确流转（Excel 的文件路径必须传给邮件工具）。