竹子AI代理

build & run from the workspace

cargo run --bin bamboo -- serve

or install then run

cargo install --path . bamboo serve ```

Arguments supported by bamboo serve (all override the config file): --port, --bind, --data-dir, --static-dir, --workers. The other subcommand, bamboo config [--path] [--show-secrets], is used to inspect configuration.

Defaults (verified against code):

• HTTP API: http://127.0.0.1:9562/api/v1 (port defaults to 9562, bind defaults to 127.0.0.1)
• Health: GET /api/v1/health
• Data dir: BAMBOO_DATA_DIR or ${HOME}/.bamboo
• Default provider: anthropic

Docker

cd docker && docker compose up -d --build
curl http://localhost:9562/api/v1/health

docker-compose.yml maps 9562:9562 and sets BAMBOO_DATA_DIR=/data, BAMBOO_PORT=9562, BAMBOO_BIND=0.0.0.0.

Quick Start & Development

token usage, and completion.

curl -N http://127.0.0.1:9562/api/v1/stream ```

message and model are the only required fields. Useful optionals: session_id (continue a conversation), system_prompt, selected_skill_ids, workspace_path, provider, images. The chat call returns right away and the loop runs in the background; the stream endpoint (SSE, resumable via ?since=<seq> or the Last-Event-ID header) is where the assistant's reasoning, tool calls, and final answer arrive as they happen.

Example configuration

${HOME}/.bamboo/config.json:

{
  "provider": "anthropic",
  "server": {
    "port": 9562,
    "bind": "127.0.0.1"
  },
  "providers": {
    "anthropic": {
      "api_key": "sk-ant-...",
      "model": "claude-sonnet-4-6"
    }
  }
}

Config precedence: file < environment variables < CLI arguments. Environment variables include BAMBOO_DATA_DIR, BAMBOO_PORT, BAMBOO_BIND, BAMBOO_PROVIDER, BAMBOO_WORKERS, BAMBOO_CORS_ALLOW_ORIGINS.

Use it as a Rust SDK (in-process)

No server needed — the same agent loop runs in-process. The bamboo_agent crate is an ergonomic facade over the engine: you supply a model and an instruction, .with_defaults_for_data_dir wires the eight runtime dependencies (storage, persistence, attachment reader, skills, metrics, config, provider, default tools) from ~/.bamboo, and then agent.run(&mut session, input) drives one turn (draining events internally) while agent.run_stream(session, input) streams AgentEvents back over an mpsc channel. Every call funnels into the engine's single canonical execution path — the facade never forks the loop. The ergonomic types live in bamboo_agent::agent (Agent, AgentBuilder, ExecuteRequestBuilder, plus re-exported AgentEvent, Session, …).

use bamboo_agent::agent::{Agent, Session};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let home = dirs::home_dir().unwrap().join(".bamboo");

    // Build the agent. One call assembles storage, persistence, skills,
    // metrics, the provider (from ~/.bamboo/config.json), and the default
    // built-in tool set — no manual dependency wiring.
    let agent = Agent::builder()
        .model("claude-sonnet-4-6")
        .instruction("You are a helpful coding agent.")
        .with_defaults_for_data_dir(home)
        .await
        .expect("wire runtime deps")
        .build()
        .expect("agent fully configured");

    // Stream one turn: `run_stream` appends the user message, runs the loop on
    // a background task, and hands back a receiver of AgentEvents.
    let session = Session::new("demo-session", "claude-sonnet-4-6");
    let mut rx = agent.run_stream(
        session,
        "List the files here and tell me what this project does.",
    );
    while let Some(event) = rx.recv().await {
        println!("{event:?}"); // assistant text, tool calls, tool results, token usage, completion
    }
    Ok(())
}

Don't need the event stream? agent.run(&mut session, input).await? drives the turn to completion and leaves the answer as the last message on session. For full control over per-request overrides (split fast/background/summarization models, skill selection, provider handles, …) drop one layer down to bamboo_engine's ExecuteRequest / ExecuteRequestBuilder and agent.execute(&mut session, req) — the same path the facade calls.

Add the facade crate as a dependency (path or git):

[dependencies]
bamboo-agent = { git = "https://github.com/bigduu/Bamboo-agent" }
tokio = { version = "1", features = ["full"] }
dirs = "5"
anyhow = "1"

Prefer not to manage these dependencies yourself? Run bamboo serve and use the HTTP API above — it drives the exact same loop. The full type reference lives in docs/guides/API.md.

Selected API routes

REST prefix /api/v1: chat, execute/{session_id}, stream, sessions, skills, tools, tools/execute, models, commands, workflows, metrics/*, mcp, servers, stop/{session_id}, health. There are also provider-compatible endpoints: /openai/v1, /anthropic/v1, /gemini/v1beta, /v1/{chat/completions,responses,messages}.

Tools, Workflows, Schedules, MCP

• Tools (bamboo-tools, 22 built-in, registered in executor.rs::register_builtin_tools): Bash, BashOutput, KillShell, Read, Write, Edit, NotebookEdit, Glob, Grep, GetFileInfo, Workspace, WebFetch, WebSearch, JsRepl, Task, Sleep, EnterPlanMode, ExitPlanMode, RequestPermissions, SessionNote, ConclusionWithOptions, and more. Tools come with usage guides injected at runtime, a permission/policy-aware execution path, and parallel execution support (parallel.rs).
• Workflows — declarative loading (bamboo-server/src/workflow/loader.rs), exposed via /bamboo/workflows.
• Schedules — a cron-style trigger engine and store (bamboo-server/src/schedules/: manager, trigger_engine, session_factory, store).
• MCP — Model Context Protocol client (bamboo-engine/src/mcp/: manager, protocol, transports, tool_index), managing external tool servers via the /mcp, /servers routes.

---