harness.yaml, which the CLI builds and deploys as a runtime. The whole loop revolves around that one file — initialize, configure, deploy, invoke, then return to configuration to iterate.
Configure AK/SK credentials first, or obtain short-lived STS credentials through SSO login.
harness deploy requires control-plane credentials; harness invoke uses control-plane credentials to resolve the Runtime and can pass an additional user token for custom_jwt Runtimes. See the Authentication section of the Quickstart.1
Initialize the harness
Create a harness directory containing
harness.yaml and .env.example.2
Configure the agent
Write fields with
harness set. Only the flags you pass are modified, so you can build up the configuration across several calls.3
Check cloud settings and component access
Replace
your-model-name with a model or endpoint ID available to your account. Default direct model calls require suitable model access on the Runtime role; a successful deployment does not grant model access. Verify a minimal reply without external tools before adding knowledge bases, MCP services, or memoryThis example uses Volcengine Beijing. For BytePlus, initialize with agentkit --provider byteplus harness init my-harness --region ap-southeast-1 and keep deployment and query regions consistent. Reference database passwords and MCP credentials as ${VAR} in harness.yaml, with actual values in an uncommitted .env4
Build and deploy
Build the image in the cloud from
harness.yaml and create or update the runtime.5
Invoke the runtime
Call the runtime you just deployed by name. The CLI resolves the endpoint and authentication automatically, using configured AK/SK credentials or valid STS credentials from the active SSO login profile.
6
Iterate
Change the configuration and redeploy to publish a new version; when the runtime misbehaves, read the instance logs to diagnose it.