TDK CLI 如何改變 AI 智能體的本機多服務堆疊管理

Trend: Local Stacks for AI Agents

Developers are asking one question more often: how do you let an AI agent start and check a multi-service stack on your own machine without it guessing at config? The answer keeps coming back to three things: generated infrastructure, machine-readable output, and a tool interface the agent can call.

TDK CLI is one project built around that combination. This article looks at what it does, and what it does not.

Key areas of focus

How do you stop an agent from guessing at infrastructure?

Agents write application code well. They are less reliable at Dockerfiles, Tiltfiles, and proxy configs that must agree on ports and service names.

TDK CLI generates those files from one service.json per service. Each service gets its runtime files under .autogenerated/, including the Dockerfile, the nginx or routing config, and the Tilt wiring. An agent changes the manifest, not the generated output.

Generated files are protected by drift checks. tdk up compares them with saved snapshots before Tilt starts, and a hand edit blocks startup and names the file. That gives an agent a clear rule: edit the source, then regenerate.

How does an agent know the stack is actually up?

Every key command has a --json form. tdk status --json reports readiness and URLs. tdk up --json reports ok: false with errors when a resource fails, so an agent can branch on a result instead of parsing terminal text.

tdk up does not block until everything is ready. It starts Tilt and returns, so the agent polls status until readiness is true. That is a usable success check, and it avoids tool calls that time out during a long build.

How do agents connect without a hosted service?

tdk mcp runs a Model Context Protocol server over stdio on your machine. It exposes doctor, up, down, status, logs, and resource_list. There is no network endpoint to expose.

Clients such as Codex connect with a project-scoped config entry that points command at tdk, args at mcp, and cwd at the project folder. The working directory matters, because the server looks for .tdk/project.json from there.

What happens when the host cannot run the stack?

tdk doctor reports the host type and whether a container runtime is reachable. canUp is false when tdk up cannot work, for example on a WebContainer or on native Windows without the opt-in flag. An agent that reads canUp: false should stop and report, not retry.

Where it stops

• It is for local development. Deployment stays with Helm, Argo CD, or Kustomize. TDK does not generate cluster manifests by default.
• It needs Docker. Without a reachable container runtime, there is no local stack to manage.
• It does not decide what to build. The agent or the developer decides the change. TDK runs it and reports the result.
• Destructive actions stay with people. Stopping a stack is low-risk. Deleting data or changing production configuration is not, and nothing in TDK makes those safe to hand to an agent alone.

Try it

npm install -g @tdk-landscape/tdk-cli-core
tdk doctor --json

If canUp is true, start a project with tdk up and watch tdk status --json until readiness is true. The TDK CLI repo has the full command reference.

The trend is real: agents need stable infrastructure they can check. TDK is one way to get there on a laptop.