多步代理：在生产中存活的编排架构
执行8个顺序步骤的代理会以新方式失败。Vertex AI Agent Builder的编排模式——规划、重试、补偿和可观测性——经过生产环境验证。
Fabiano Brito
CEO & Founder
员工完整入职、财务对账、监管流程申报——这些场景中代理执行包含中间决策的5–15步链。这里有最高的ROI，也有最棘手的复杂性。
为什么多步不同
- 每步都有延迟 → 总流程变长（10s–2min很常见）。
- 每个外部调用都可能失败 → 需要显式处理。
- 中间状态必须持久化 → 检查点是强制的。
- 第4步失败可能需要撤销第1–3步 → Saga模式。
- "下一步"决策是动态的 → 真正的规划，不是固定DAG。
- 简单的可观测性不够 → 结构化追踪。
显式规划模式
执行前，代理声明计划。伪代码：
1. 输入: "开启监管流程 X"
2. 计划生成: Gemini 2.5 Pro 产生包含预期步骤的 JSON
3. 验证: schema + 依赖 + 每步权限
4. 执行循环: 对每步, 执行 → 验证 → 检查点
5. 失败时: 重新规划（以失败上下文决定下一步）
6. 成功时: 报告 + 审计日志为何重要：显式规划支持（a）高风险案例执行前人工审查，（b）重新规划而非无限循环，（c）审计代理尝试过的事。
默认幂等性
每个工具和每一步必须幂等——用相同参数重新执行不产生双重效果。
如何保证：
- 资源创建时使用幂等键（从意图+步骤派生的UUID v4）。
- 创建前检查："如果此案例已有ticket，链接而非创建"。
- 尽可能用PUT/upsert操作代替POST。
- 用相同幂等键重试。
没有这个，超时后重试会重复记录——ERP/CRM中的噩梦。
Saga模式（补偿）
当步骤1..N-1已产生实际效果而第N步失败时，代理必须按反序撤销。每步声明对应的补偿。
员工入职示例：
| 步骤 | 操作 | 补偿 |
|---|---|---|
| 1 | 在AD中创建用户 | 禁用用户 |
| 2 | 开通Workspace | 暂停许可证 |
| 3 | 创建SAP访问权限 | 撤销访问权限 |
| 4 | 添加到组 | 从组中移除 |
| 5 | 通知经理 | 通知回滚 |
如果第4步失败，代理执行补偿 3 → 2 → 1 并报告。状态一致，无"孤儿用户"。
状态检查点
在每个完成步骤后持久化状态，可以（a）失败后无需重做一切即可恢复，（b）跨进程重启继续，（c）实时审计进度。
模式：Firestore/Spanner中的agent_executions表，包含：
- execution_id、agent_name、user_id、started_at。
- plan_json（版本化）。
- steps[]，含status、input、output、timestamp、latency。
- 已执行的compensations[]。
- final_status、final_output。
Cloud Workflows也适用于显式编排；动态逻辑场景保留在代码+自有状态中。
可观测性：追踪而非日志
多步场景中，线性日志不够。使用：
- 分布式追踪（OpenTelemetry → Cloud Trace）：每步是一个span，父级=执行。
- 属性：调用的工具、模型、tokens in/out、延迟、成本。
- 事件（非散日志）："plan_generated"、"step_started"、"step_failed"、"compensation_started"。
- 每代理仪表板：每步p50/p95/p99延迟、每工具失败率、每次执行成本。
- 告警：延迟>X、失败率>Y、平均成本超基准线。
动态决策：ReAct vs DAG
固定DAG：步骤在设计时确定。更可预测、更可审计、灵活性较低。适合稳定流程（KYC、标准入职）。
ReAct（reason-act循环）：代理在每次迭代中根据上一步结果决定下一步。更灵活、更不可预测，需要循环和成本guardrails。
Autenticare模式：从DAG开始。仅在案例证明需要高变异性时迁移到ReAct。混合方案可行——DAG骨架在定义节点配置ReAct子代理。
max_iterations、max_tool_calls、token预算和循环检测（同一工具同一参数运行两次），代理会进入循环，在有人注意到之前已花费大量token。硬上限写在代码中，不是提示词中。
循环限制
无限制的ReAct会变成无限循环代理（或消耗token的"agent loop"）。始终设置：
- 最大迭代次数硬上限（例如：12步）。
- 每次执行的最大工具调用数。
- 每次执行的最大成本（token预算）。
- 循环检测：同一工具同一参数运行2次时，告警+升级。
人工交接
任何步骤中，如果置信度低或歧义高，代理必须能够暂停并请求人工输入：
- 持久化完整状态。
- 通知人工（Slack、邮件、队列）。
- 带超时等待回复。
- 根据决定恢复或取消。
这是区分"什么都尝试的代理"与"足够成熟懂得求助的代理"的标志。
Autenticare项目使用的技术栈
- Vertex AI Agent Builder：代理定义+工具。
- Cloud Run jobs：稳定的长运行编排。
- Firestore：执行状态。
- Pub/Sub：异步交接和通知。
- Cloud Trace + Looker：可观测性。
- BigQuery：历史分析和审计。
常见错误
- 无幂等性 → 重试重复记录。
- 无补偿 → 状态不一致。
- 无最大迭代数 → 无限循环。
- 无检查点 → 基础设施故障后重新执行一切。
- 无交接 → 代理在超出范围的决策上"卡死"。
- 无追踪 → 调试变成日志考古。
求助的代理比什么都尝试的代理更成熟。低置信度时的人工交接不是弱点——而是架构设计。