Dify
Connect a Dify agent-chat application to AI GO! as a native model, using the typed dify connection. Dify keeps conversation state server-side, scoped to a user; the integration mints a stable user id and round-trips the Dify conversation_id automatically, so multi-turn evaluations preserve state.
Prerequisites
- A published Dify agent-chat app, and the base URL of your Dify deployment.
- A Dify API key for that app.
Configuration
Define the model with connection_type: dify and reference the API key as a secret:
key: "dify-agent"
display_name: "Dify Agent"
description: "Dify agent-chat app, served via the typed `dify` connection config."
task: "chat_completion"
rate_limit: 5
config:
connection_type: "dify"
url: $DIFY_URL
api_key: "<< secrets.DIFY_API_KEY >>"
secrets:
DIFY_API_KEY: $DIFY_API_KEYConfig fields
| Field | Required | Secret | Description |
|---|---|---|---|
connection_type |
yes | no | Must be dify. |
url |
yes | no | Base URL of the Dify deployment. |
api_key |
yes | yes | Dify API key (sent as a bearer token). |
Credentials
The secrets block uploads values (from your .env or environment) to server-side secret storage, and << secrets.NAME >> references them from the config so no key is stored in plaintext. Provide the values in your .env:
DIFY_URL=https://api.dify.ai
DIFY_API_KEY=app-...Add and test
lf add model -f dify.yaml
lf test model dify-agentUse in an evaluation
Reference the model key from a task specification in your run config:
evaluation:
task_specifications:
- task_key: my-task
model_key: "dify-agent"Conversation state
On the first turn the integration mints a stable user id and starts a Dify conversation; the user id and conversation_id are attached to the assistant message and reused on each subsequent turn, so the agent remembers earlier turns.