本文档由 AI 自动翻译。如有任何不准确之处，请参考 英文原版。
查找应用
运行difyctl get console_app 列出你的应用。只有开启了服务 API 访问的应用才会列出，也只有这些应用能运行。
id 传给 --app-id。mode 是应用的类型，决定了用哪条命令运行它：
difyctl 不会列出或运行用新 Agent 构建的应用。这类应用要改为通过 服务 API 调用。查看应用的输入变量
运行difyctl describe console_app 查看应用的变量：名称、类型，以及哪些是必填的。
运行 Workflow 应用
用--inputs 把应用的变量传给 difyctl run console_app workflow，格式为以变量名为键的 JSON。应用的答案在结果的 outputs 中，键名对应输出节点的变量。
必填变量名拼错时，运行会失败，报
topic is required in input form 之类的错误。可选变量名拼错则不会报错，运行会直接略过这个变量。变量名可用 describe console_app 核对。发送消息或生成文本
按 查找应用 中的应用类型，选用对应的run console_app 命令。消息放在 --query 中，变量（如有）放在 --inputs 中。文本生成应用通常只需要 --inputs。回复在结果的 text.answer 中。
继续会话
用--conversation-id 传回结果中的 conversation_id。
每轮对话都要重新传入应用的必填变量。漏传时，消息会发送失败。
发送文件
任何运行命令都可用--files 为每个文件变量指定一个本地路径。文件列表变量则指定一组路径。网络上的文件改为通过 --inputs 传入。每个文件变量只能通过 --files 或 --inputs 中的一个传入，不能两处都传。
跟踪耗时较长的运行
要边运行边查看进展，就加上--stream。每个事件一发生就会打印出来，每行一个 JSON 对象。Workflow 应用运行时，最后一个事件 workflow_finished 会在 data.outputs 中给出结果。只想打印部分事件时，用 --only 逐个指定事件名。
停止运行
要想之后能停止某次运行，就得用--stream 启动它。停止时，把它第一个事件中的 task_id 传给 difyctl stop run：
workflow_finished 事件结束，事件中的 data.status 为 stopped。流式命令以退出码 1 退出。在脚本中，要根据 data.status 判断运行是否已停止，不要看退出码。
传给
stop run 的应是 task_id，而不是每个事件中都有的 workflow_run_id。传错 ID 时，命令仍会打印 {"result": "success"}，但运行会继续进行。填写人工介入表单
只有人工介入节点的提交方式为 Webapp 时，才能在
difyctl 中填写表单。status 为 suspended 的结果，每个操作按钮各对应一条提示。找到你要执行的操作对应的提示，把其中 inputs 里的每个 null 换成你的回答，再 运行这条提示。
也可先看看表单有哪些字段再填写：从任一提示中取出 form_token，用 describe run form 查看，再用 submit run form 提交回答。
无论用哪种方式，之后都用 get run event 跟踪恢复后的运行。别被标志名误导：--task-id 要传的是暂停时返回结果中的 run_id。一定要带上 --include-state-snapshot，否则该命令可能长达 5 分钟没有任何输出。
排查运行失败的原因
Workflow 或 Chatflow 应用运行失败时，可从失败结果中的run_id 入手，也可用 difyctl get run 列出失败的运行。然后用 describe run 查看这次运行，用 get run node 查看它的各个节点。
一定要带上
--triggered-from app-run。不带的话，列表只显示草稿的测试运行。故障排查
任何命令都可能遇到的错误，详见「结果、错误与退出码」中的 故障排查。