运行、调试与追踪

运行面板会流式展示节点状态、模型消息、工具输入输出、脚本日志与轨迹。失败时先定位具体节点和事件，再决定是修改提示、代码、Schema、工具权限还是模型配置。每次运行保留执行计划、最终状态和关键事件。

读懂运行面板

区域	用来回答的问题
节点时间线	卡在哪个节点？是失败、等待输入还是已完成？
模型消息	Agent 收到了什么、调用了什么工具、最终如何回答？
工具输入与输出	参数是否映射正确？工具是否返回了预期结构？
stdout / stderr	Python App 是否因环境、依赖或业务异常失败？
最终状态	哪些字段真正被写回工作流？是否有敏感字段脱敏？
运行诊断	模型 Token、模型调用和工具调用次数是否在预期内？

建议的排查顺序

1. 确认输入和上游状态是否符合预期；
2. 检查 Agent 的模型消息、工具调用参数和结构化输出；
3. 检查 Process App 的 stdout、stderr 与返回结果；
4. 对暂停或失败运行，从检查点重试；
5. 需要跨系统诊断时，将 Trace 导出至配置好的 OTLP/gRPC collector。

运行历史会保留执行计划、最终状态和关键事件。不要只看最终答案：可观察性是让自动化可以长期维护的基础。

素材占位 · 截图 runs/01-run-workspace.png
画面：运行工作区，节点时间线与 Agent 事件展开，标出模型消息、工具调用和最终状态。
用途：为“读懂运行面板”表中的每个区域提供视觉对应。

导出 Trace

需要在团队现有观测系统中联查时，可配置 OTLP/gRPC collector。先在隔离环境验证 collector 地址和网络策略，再确认 Trace 中不包含不应离开设备的敏感内容。遥测用于诊断，不应代替运行面板中的逐次结果检查。