本文档由 AI 自动翻译。如有任何不准确之处，请参考 英文原版。
difyctl 专为脚本化设计：数据写入 stdout，其余内容写入 stderr，-o 全局标志 用于选择输出格式，失败时以可预期的退出码退出。
输出格式
-o <format> 决定命令在 stdout 上如何呈现结果。每个命令支持五种格式中的一部分，具体见其 --help 输出及参考页上的标志表。
不带
-o 时，get app 等列表命令打印对齐的文本表格，其他命令打印文本。
JSON 结构是稳定的：get app 等列表命令打印一个 JSON 对象，各行放在数组中，同一命令运行两次返回相同的顶层结构。命令的确切 JSON 结构见其参考页。
输出通道
编写脚本时值得依据的几条规则：
- 失败时 stdout 保持为空。你无需从捕获的数据中过滤错误文本。
- 成功时，
get和describe命令的 stderr 为空；run app和resume app可能在此处打印提示。 - 进度旋转图标仅在终端中出现，输出到 stderr，并在
-o json、-o yaml和-o name下被抑制。 - 管道输出不携带 ANSI 颜色代码。
- 若管道的下游提前退出（
difyctl get app -o name | head -2），difyctl以0退出，而非因管道中断而失败。
错误
错误输出到 stderr。在默认的人类可读格式下，一条错误是一行code: message，外加可选的详情行：
request: <METHOD> <url> 和 http_status: <n> 行。
当服务器的响应携带 Dify 标准错误体时，首行显示服务器更具体的错误码（not_found、invalid_param），而非 CLI 的传输层错误码。
随后是逐字段的校验详情，以缩进行的形式列出；当 difyctl 自身没有提示时，则显示服务器给出的提示。
在 -o json 下，同一条错误会变成 stderr 上的单行 JSON 对象：
-o json 会切换错误的呈现方式：-o yaml 失败时打印人类可读格式。
各错误码的含义及修复方法，详见 故障排查。
退出码
对严格脚本而言有一处细节：解析器层面的错误（未知命令、未知标志、标志缺少取值）以
1 退出并附带纯文本消息，而已知标志的无效取值则以 2 退出。
因等待人工介入而暂停的工作流运行退出 0
Workflow 或 Chatflow 应用可在运行中途暂停以收集人工输入。这一暂停是成功的结果，而非失败：run app 和 resume app 以 0 退出，并向 stdout 打印暂停负载。
要在脚本或 Agent 中检测暂停，使用 -o json 运行并检查 stdout 中是否有 "status": "paused"，不要依据退出码分支判断。
负载结构及恢复协议，参见 Apps 参考页的 工作流暂停时。